🔀 本番AIエージェントをOpus 4.8からGPT-5.6に移し替えた実録 — 2.2倍速・27%減の裏にある3つの互換性地獄

「モデルを乗り換えれば速くなる」という話は毎月流れてくる。でも本番エージェントで実際に乗り換えて、壊れた箇所を全部書いた記事は少ない。

サイト自動生成サービスのPloyが、企画から実装・画像生成・自己評価まで行う本番エージェントを、Claude Opus 4.8からGPT-5.6 Sol(2026年7月9日リリース)へ移行した記録を公開した。結果は1ビルドあたりウォールクロックが8分00秒から3分42秒へと2.2倍の高速化、コストは$3.06から$2.22へ27%減。入力トークンは35%減(2.6Mから1.7M)、出力は48%減(33kから17.1k)、生成物のビジュアルスコアも0.936から0.970へ上がったという。

数字はすべてPloyの自己申告で第三者検証はなく、自社製品の宣伝を兼ねた記事だ。それを差し引いても読む価値があるのは、成功談ではなく移行で壊れた3箇所の記録のほうだと思う。モデル移行を検討したことがある人なら、全部身に覚えがあるはずだ。

壊れた箇所その1: ツール呼び出しの「善意の埋め合わせ」

一番厄介だったのがこれ。GPT-5.6はツール呼び出しで、未使用のオプションパラメータにも推測値を埋めてくる。Claudeは使わないパラメータを省略するので、同じツールスキーマでも呼ばれ方が変わる。

Ployのケースでは25個のパラメータを毎回全部送ってきて、余計な値が入ったせいでファイル読み込みの52〜64%が空振りした。対処はスキーマ側で、オプション項目をnullableとして再定義すること。ツールスキーマはモデル非依存のつもりで書いていても、「省略」と「null」の扱いという地味な方言差で壊れる。

壊れた箇所その2と3: キャッシュと推論の持ち越し

プロンプトキャッシュの仕様もプロバイダで別物だ。OpenAI側の部分一致キャッシングの廃止に合わせてキャッシュ戦略を組み直し、ワークスペーススコープのキーで**初回呼び出しのキャッシュヒット率を0%から83.7%**まで持っていっている。ちなみにこの設定ミスはシミュレーションでは出ず、本番で初めてエラーとして露出したという。キャッシュはワークロードの形に依存するので、ステージングでは再現しないんですよね。

3つめは推論(reasoning)の持ち越し。サーバー側の状態参照でリプレイが失敗するため、store: false で自己完結型に切り替えて解決している。

この記事の本当の教訓はロックインの形

HNの議論で一番刺さったのは「この記事自体が、モデル乗り換えのスイッチングコストの見積書になっている」という視点だ。プロンプトもツールスキーマもキャッシュ戦略も、運用するうちに特定モデルの癖に最適化されていく。乗り換えは可能だが、配管工事とeval整備の工数を払える組織だけの選択肢になる。

もうひとつ、2.2倍という数字の帰属も慎重に読みたい。移行と同時にスキーマもキャッシュも作り直しているので、どこまでがモデルの功績でどこからが実装最適化の功績か、この記事からは切り分けられない。GPT-5.6とGPT-5.5の実力差を疑う声もあった。

それでも、evalを持っていたから移行の判断ができた、という構造は揺らがない。ビジュアルスコアのような自前の物差しがなければ、「速くなったが質が落ちた」を検知できず、そもそも移行に踏み切れない。モデルの乗り換え可能性は、契約ではなくevalへの投資で買うものなのだろう。あなたのエージェント、明日別のモデルに変えろと言われたら、何が壊れるか言えますか。