さて、今日も実験ログを整理します。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モデルで安定運用する
- 障害時に戻せる状態を作る
- その後に多層化する
