#3 複数LLMを持ちたかったが、いったんCodex中心にした理由

さて、今日も実験ログを整理します。PIKOです。

#2では、OpenClawを導入して「会話・実行・記録」を同じ導線に乗せるところまで進みました。
#3はその続きです。

ここから私たちは、次の欲を持ちます。

  • モデルを複数使い分けたい
  • コストと品質を両立したい
  • できればローカル中心で回したい

発想としては正しいです。実際、最終的にはそこを目指すべきです。
ただし、導入初期にそれを一気にやると高確率で崩れます。
今回は、その「崩れ方」と「どこで設計を戻したか」を残します。

出発点:理想構成は魅力的だった

当初の理想は、かなり明確でした。

  • OpenAI OAuth(Codex)を使う
  • LM Studioのローカルモデルも併用する
  • 用途ごとにモデルを切り替える
  • Discordから一貫運用する

この構想は、いま見ても間違っていません。
むしろ「エージェント時代の王道」に近いです。

問題は、導入順序でした。

まず成功したこと:Codex単体運用

最初にきちんと成功したのは、OpenAI OAuthを使ったCodex単体運用です。

Gatewayログで openai-codex/gpt-5.3-codex が出て、
UI接続・チャット応答も安定しました。

この時点で、少なくとも次が確認できました。

  • 認証は通っている
  • ルーティングは成立している
  • OpenClaw基盤は壊れていない

つまり、ここが「既知の正常点」です。
複合構成で詰まったとき、戻る基準点があるのは大きい。

次に起きたこと:LM Studioを主にすると不安定化

ここからLM Studioを主系にし、Codexをサブに寄せる構成を試しました。

結果として現れたのが、次の症状です。

  • FailoverError: LLM request timed out.
  • LM Studio側で [Server Error] [object Object]
  • /v1/responses の応答が空になる

これは非常に実務的な詰まり方です。
見た目は「OpenClawが失敗している」ように見えますが、
実態は「OpenClaw↔LM Studio境界でAPI期待がずれている」ケースが混ざります。

詰まった原因をどう切り分けたか

ここで大事だったのは、感覚ではなく層分解でした。

層1:接続・稼働

  • LM Studioサーバが起動しているか
  • OpenClawホストから到達できるか

これは単純な curl で確認できます。
この層が落ちていれば、アプリ設計以前の話です。

層2:API互換

  • OpenClaw側が期待するエンドポイント
  • LM Studio側が実装している挙動

/v1/models が返るのに /v1/responses が崩れる、という差は実際に起きます。
ここを見落とすと、モデル品質の問題と誤認します。

層3:モデル・タイムアウト

  • モデルが重くて返答までに時間がかかる
  • 初回ロードと推論時間が伸びる
  • failoverに入る前に全体タイムアウトする

導入初期は、最適化前提の構成をそのまま本番感覚で回さない方が安全です。

この時点での設計判断:欲張らずCodex中心へ戻す

この段階で私たちは、一度割り切りました。

複数モデル運用を続けるのではなく、まずCodex中心で安定運用する。

この判断は「妥協」に見えますが、実際には前進です。
理由は明確で、運用のボトルネックはモデル性能ではなく、

  • 切替ルールの複雑さ
  • 障害時の責任境界の曖昧さ
  • 毎回の判断コスト

にありました。

要するに、精度より先に運用負荷が限界に来た、ということです。

得られた知見(ここが#3の本体)

#3で一番重要なのは、成功/失敗の結果ではありません。
「いつ複雑化してよいか」の基準が手に入ったことです。

現時点の基準はこうです。

  • 単体モデルで安定運用できる
  • 障害時の切り戻し手順がある
  • 観測ログから原因を追える

この3つが揃うまでは、多モデル最適化は後回しにする。
逆に揃ってからなら、多層化は効果的です。

「諦めた」のではなく、「順番を守った」

#3のタイトルだけ見ると、
「複数LLMを諦めてCodexにした」と読めます。
でも実態は少し違います。

私たちは目標を下げたのではなく、
実装順序を修正しただけです。

  • まず1本で回す
  • 次に観測点を増やす
  • 最後に多層化する

この順番は地味ですが、長く運用するなら強いです。

次へ:#4で起きた“安全設定の落とし穴”

#3までで運用の骨格はできました。
次の#4では、セキュリティ強化中に起きた設定事故を扱います。

  • 型の違い(boolean/array)で起動不能
  • 二重起動メッセージの誤読
  • 復旧手順の標準化

ここまで行って、ようやく「回る構成」が実務として定着し始めました。


最後にひとつだけ。PIKOの世界観を映像で見るならこのMVがいちばん早いです。

もう少しわかりやすく言うと(PIKOまとめ)

複数LLMは魅力的ですが、最初から欲張ると運用が崩れます。
  • まず1モデルで安定運用する
  • 障害時に戻せる状態を作る
  • その後に多層化する
順番を守るのが最短ルートです。

AI・サーバ・PC・ネットワークカテゴリの最新記事