7月9日、ploy.aiが「Migrating a production AI agent to GPT-5.6」と題した記事を公開した。本番稼働中のAIエージェントをClaude Opus 4.8からGPT-5.6 Solへ移行した実体験をもとに、2.2倍の高速化・27%のコスト削減・ビジュアルスコアの向上という結果に至るまでに踏んだ3つの落とし穴と、その解決策を詳しく解説した記事だ。

4ヶ月間、Opusを超えるモデルはなかった

PloyはAIエージェントがマーケティング用のWebサイトを自動で設計・実装・公開するサービスだ。エージェントはページ構成の計画、コードベースの読み取り、コンポーネントの実装、画像生成、スクリーンショット撮影、完了判断まで一貫して行う。要求水準が高く、毎回のフロンティアモデルリリースをこの実タスクで評価してきた。

Claude Opus 4.7、4.8と4ヶ月間にわたりOpusがデフォルトの座を守り続けた。それを初めて超えたのがGPT-5.6 Solだった。

評価結果（リデザインスイート、実際のホームページ再構築タスク）は以下の通りだ：

2.2倍速く、27%安く、ビジュアルスコアは上回る。出力トークン数の少なさはコードの簡潔さに直結していた。ある対応ケースで比較すると、Opusが174個のCSS変数を含む17,957文字のglobals.cssを生成したのに対し、GPT-5.6は45変数・2,508文字で同等以上のページを描画した。

ただし、最初のeval実行は完璧ではなかった。移行には3つの本質的な問題を一つずつ潰す作業が必要だった。

Step 0：評価ハーネス自体が壊れていた

最初の教訓は、評価環境が既存モデルに無意識に最適化されているという点だ。

ツール呼び出しの上限回数はOpusの逐次スタイルに合わせて設定されていた。GPT-5.6は並列呼び出しを積極的に行うため、正答しているケースでも予算を超えてしまった。最初のクロスモデル実行で発生した「失敗」のおよそ3分の1がハーネス側の問題であり、モデルの能力とは無関係だった。

また、minScore閾値の設定漏れにより、GPT-5.6がスコア0.98を取ったヒーロー画像が「失格」扱いされ、Opusは全チェックをパスしながら失敗扱いされるケースもあった。チャレンジャーモデルを評価するときは、合格率を信じる前にトレース（実際のツール呼び出しとモデル出力）をトリアージすることが不可欠だ。

Step 1：ツール引数の「発明」問題

最も影響が大きかった問題だ。

Ployのエージェントが使うcodeツールは25個のトップレベルパラメータを持ち、必須はactionのみで残りはオプションだ。Claudeは使うものだけを送り、残りは省略する。GPT-5.6は毎回全25パラメータを送信し、不要なものにはoffset: 0、timeout: 120000、siteId: "00000000-0000-0000-0000-000000000000"といった「もっともらしい値」を自動で埋める。

3日間の本番トレースから得たデータ：

発明された値は意図的な値と区別がつかないのが問題だ。offset: 0はファイル読み取りの位置指定として有効な引数に見える。実装はそう解釈し、GPT-5.6のファイル読み取りの52〜64%が空のレスポンスを返していた。ツールはsuccess: trueを返すため、モデルは空ファイルを読んでいることに気づかず、より多くの呼び出しを重ねてしまう。

プロンプトで指示しても効果はなかった。「未使用パラメータは省略してください」という記述も、各プロパティへの「OPTIONAL, omit if unused」の注釈も、OpenAIのstrictモードも、いずれも結果は変わらなかった。これはモデルのfunction call生成に組み込まれた挙動であり、指示で変えられるものではない。

採用した解決策はスキーマ変換だ。OpenAIファミリー向けに、オプションのプロパティをanyOf: [T, null]形式の「required but nullable」に書き換える。モデルには「使わない」と明示できる手段を提供し、ツール実装の手前でnullを除去することでツール側の変更は一切不要にする。

// Before: 25キー、全てに「発明された値」
{ "action": "read", "file_paths": [...], "offset": 0, "timeout": 120000, ... }

// After: 25キー、実際の値4つ、明示的なnull 21個（ツール実行前に除去）
{ "action": "read", "file_paths": [...], "offset": null, "timeout": null, ... }

結果：空ファイルの読み取りは52%から0%に、同じ作業に必要なツール呼び出し数は約30%減少した。

Step 2：プロンプトキャッシュの設計思想が根本的に異なる

表面上は両プロバイダーとも「プロンプトキャッシュ」を提供しているが、設計が全く違う。これを見落とすと、GPT-5.6がOpusより約50%割高に見えるという計測ミスが起きる。

Claudeはcache_controlでキャッシュブレークポイントを指定し、そのキャッシュは組織全体で共有される。どのワークスペースのどの会話からでも同一エントリにヒットし、Ployでは92〜96%のキャッシュヒット率が出ていた。

GPT-5.6はキャッシュモデルを刷新した。以前のGPTモデルにあった暗黙的なプレフィックスマッチングが廃止され、新規会話では29Kトークンの静的プレフィックスがキャッシュ率0%になった。さらに、元記事によれば、GPT-5.6では未キャッシュのプロンプトに1.25倍のキャッシュ書き込みサーチャージが加算される（詳細は元記事の該当箇所およびOpenAI Prompt Caching公式ドキュメントを参照）。

新しいキャッシュ機構の核心はprompt_cache_keyだ。同一プロンプトでもキーが異なればキャッシュヒットはゼロになる。各キーは毎分約15リクエストを捌くキャッシュノードにマッピングされ、それを超えるとコールドなノードに分散されてしまう。

スコープ選択の設計判断：

• 会話単位のキー：新規会話の初回ヒット率0%（実測済み、高コスト）
• グローバル単一キー：本番トラフィックが15rpm上限を超え、コールドノードに溢れる
• ワークスペース単位のキー：各ワークスペース内で共有され、per-keyトラフィックは低く抑えられる

ワークスペースキーを採用し、システムプロンプトをブレークポイント付きのレイヤーに分割した結果、初回呼び出しのキャッシュヒット率は約0%から83.7%に向上、未キャッシュ入力トークンは28%削減、コストはOpusを下回った。コスト差の全額がキャッシュ設定ミスによるものであり、モデルの価格差ではなかった。

なお構造的な制約として、静的プレフィックスのクロスワークスペース共有はOpenAIでは不可能だ。Anthropicは組織スコープのキャッシュで実現できるが、OpenAIではワークスペースごとに29Kトークンのコールドライトが発生する（約$0.18）。

Step 3：Reasoning Replayの自己完結化

GPT-5.6のResponses APIはデフォルトで、前ターンの推論をサーバー側アイテムの参照として再生する。これにより会話の途中でItem 'rs_...' not foundエラーが断続的に発生していた。

修正はstore: falseの指定だ。これによりSDKが暗号化された推論コンテンツをリクエストし、サーバー状態へのポインタではなく自己完結したblobを再生するようになる。他の2ステップと比べると修正の規模は小さいが、断続的なエラーが本番での信頼性を損なっていたため、放置できない問題だった。付随する注意点として、サーバー側reasoning stateが絡む場合、送信バイト列がappend-onlyであっても実効的なプロンプトが上流で変化しうる点は頭に入れておく必要がある。

まとめ

VercelのAI SDKのような統一LLM SDKを使っていても、モデルを切り替えると「モデルの挙動」と思っていたものがプロバイダー固有の実装であることが露呈する。今回のケースでは、ツール引数の埋め方、プロンプトキャッシュの設計、Reasoningの再生方式、いずれも全面的な見直しが必要だった。

一方で数字は明確だ。ハーネスを整理し、スキーマ変換を入れ、キャッシュを正しく設計した後のGPT-5.6 Solは、2.2倍速く、27%安く、ビジュアルスコアで上回った。これらの落とし穴はいずれもGPT-5.6固有の設計に起因しており、「どのモデルに乗り換えるべきか」を判断する前に、評価ハーネスとプロバイダー固有の挙動を先に把握することが前提条件になる——本記事はその具体的な手順書として機能する。

詳細はMigrating a production AI agent to GPT-5.6を参照していただきたい。