プロダクションAIエージェントをGPT-5.6に移行して壊れたものとその修正方法

PloyのAIエージェントは、実際のマーケティングサイトを構築・編集する——ページの計画、コードベースの読み取り、コンポーネントの作成、画像の生成、完了の判断までを行う。数ヶ月間、Claude Opusがデフォルトのスロットを占めていた。そこにGPT-5.6 Solが登場し、その数字は無視できないほど良かった：実時間の半分以下でビルドが完了し、コストは27%低く、品質スコアは同等かそれ以上だった。しかし、VercelのAI SDKのような汎用LLM SDKを使っていても、モデルを切り替えることはプロバイダ固有の振る舞いの地雷原であることが判明した。

ステップ0：まず評価ハーネスを修正せよ

Ployの評価スイートは、実際のエージェントを数百のフィクスチャワークスペースに対して実行し、ビジュアルチェック、コンテンツチェック、ツールの軌跡でビルドをスコアリングする。同じスイートを2つのモデルファミリーで実行した結果、痛い真実が明らかになった：あなたのハーネスは現行モデルにチューニングされており、それに気づいていないのだ。Opusの逐次的なスタイルに合わせたツールコール予算は、GPT-5.6の並列呼び出しで吹き飛んだ。評価実行エンジンはバッチファイル読み取りをサポートしておらず、GPT-5.6はそれを頻繁に使用する。最初のクロスモデル実行での生の障害の約3分の1は、モデルの振る舞いではなく、ハーネスの前提に起因していた。合格率を信頼する前に、トレースをトリアージせよ。

ステップ1：ツールコールスキーマ——静かなる破壊者

Ployのcodeツールには25のトップレベルパラメータがあり、1つが必須で残りはオプションである。Claudeは使用する2〜3個だけを送信する。GPT-5.6は毎回25個すべてを送信し、未使用のパラメータにももっともらしい値をでっち上げる：offset: 0、timeout: 120000、siteId: "00000000-0000-0000-0000-000000000000"。問題は冗長さではなく、でっち上げられた値が意図された値と区別がつかないことだ。offset: 0により、ファイル読み取りの52%から64%が空で返ってきた。プロンプトでは修正できない。プロパティごとに「OPTIONAL, omit if unused」というヒントを与えても、GPT-5.6は依然として25個すべてを送信した。修正方法：プロバイダ境界でスキーマ変換を行い、すべてのオプションプロパティを必須だがnullableに書き換え（anyOf: [T, null]を使用）、検証前にnullを除去する。空のファイル読み取りは52%から0%に低下し、エージェントのツール呼び出しは約30%減少した。

ステップ2：プロンプトキャッシュの再構築

表面的には、両プロバイダとも「プロンプトキャッシュ」を提供しているが、実装はまったく異なる。Ployのエージェントは29Kトークンの静的プレフィックスで始まり、Claudeでは組織全体で92〜96%のヒット率でキャッシュされていた。GPT-5.6は部分プレフィックス一致を廃止し、暗黙のキャッシュは最新メッセージをキーとする全体プロンプトエントリのみを作成する。同じ静的プレフィックスを共有する新しい会話では、その0%がキャッシュされた。意図されたメカニズムは、明示的なprompt_cache_breakpointマーカーと必須のprompt_cache_keyを使用し、各キーは1分あたり約15リクエストを維持するキャッシュノードにマッピングされ、それを超えるとトラフィックはコールドキャッシュに分散される。これにより、「キャッシュを有効にする」は、キーのスコーピングに関する実際の設計上の決定となる。これを修正する前は、GPT-5.6はOpusよりも約50%高く見えた——モデルの価格設定ではなく、キャッシュ設定の問題だった。

まとめ

Ployの移行ストーリーは、「モデル」とは実際には、スタック全体が静かに特化してきたプロバイダ固有の振る舞いの束であることを思い出させる。ツール引数の埋め込み、プロンプトキャッシュ、推論の再生はすべてプロバイダ間で異なる。挑戦的なモデルを評価するなら、まずハーネスを修正し、次にこれらの違いに合わせて再設計することを期待せよ。パフォーマンスの向上は確かだが、それにはエンジニアリングコストが伴う。