まず評価フレームワークが公平かを見て、それからモデルの強さを見る

2つのモデルのスコアを単純比較する前に、まず問うべきことがある――評価フレームワーク自体は公平なのか。Ploy は同一の評価スイートを2つのモデルファミリーにまたがって走らせ、最も意外だった発見は、評価フレームワークがすでに旧モデル向けに調整されていたのに、チーム自身がそれに気づいていなかったことだった。

初めて異なるモデル間で走らせたとき、具体的には次の点に偏りが見つかった。

• ツール呼び出しの予算は Opus の逐次呼び出しスタイルに合わせて設定されていた。GPT-5.6 は多数の呼び出しを並列に展開するため、実際には正解している問題でも予算を使い切ってしまう。
• 評価エグゼキューターがバッチファイル読み込みに対応しておらず、この手法は Opus はほとんど使わないが GPT-5.6 は常用していた。
• あるデータセットで minScore の閾値記入が漏れており、既定値の1.0を暗黙に継承していた。その結果、0.98点を取った GPT-5.6 の hero が「不合格」と判定される一方、個別チェックすべて通過した Opus の問題も「失敗」扱いになった。どちらも成立するデザインの方向性だったが、見えない閾値がそれを阻んでいた。

この回の元の失敗を掘り下げると、およそ3分の1は実は評価フレームワーク側の前提が原因であり、モデルの挙動とは無関係だった。しかも2つのモデルが踏んだ数もそれぞれ違っていた。

左：Opus のグラデーション hero は満点1.0で合格。右：GPT-5.6 のカラーブロック案は0.98を取ったが、明記されておらず既定値1.0の隠れた閾値に引っかかって不合格と判定された。出典：Ploy Blog

結論はシンプルだ。挑戦者モデルを評価する際は、まず一件ずつトレースを見てから通過率を信じること。さもないと、新モデルを「どれだけ旧モデルに似ているか」で採点していることになる。

デザインスタイル：クリーンで見栄えは良いが、画一化しやすい

GPT-5.6 のデザイン能力に対する Ploy の全体的な判断はこうだ――クリーンでモダン、グリッドがきっちり整ったレイアウトが得意だが、うまく誘導されないと、その方向に一直線に収束していく。Opus 4.8 向けに設計された旧評価フレームワークの下では、GPT-5.6 は既存のデザインシステムを無視しがちで、洗練され抑制の効いた、しかし一目で汎用的だとわかるページを作りがちだった。

左：Opus は Clay のブランドビジュアルシステムを再現した。右：GPT-5.6 は旧モデル向けに設計された評価フレームワークの下で、クリーンだが汎用的なページを出力した。出典：Ploy Blog

どうやってそれを世界トップクラスのブランド再現度へと誘導するかは、別記事の範囲だ。ここでは実際にある能力の特徴として記録するにとどめる。落とし穴というほどのものではない。

モデルは使わないパラメータにまで偽の値を作ってしまう

Ploy の code ツールにはトップレベルのパラメータが25個あり、必須なのは action だけで、残りはすべて任意だ。Claude は必要な2、3個だけを送り、それ以外は省略する。GPT-5.6 は毎回25個すべてを埋めてしまい、使わないものにはそれらしく見える値をでっち上げる――offset には0、timeout には120000、siteId にはすべて0で埋まった UUID を入れる、といった具合だ。

3日間の本番トラフィックで、code(read) 呼び出しのうち25個のパラメータすべてを携えている割合を見ると、同じ事象とは思えないほどの差があった。

絶対数に換算すると：GPT-5.6 の6,635回の呼び出しは6,635回すべてがフル装備、Opus 4.8 の2,898回のうちわずか4回のみ、Sonnet 5 は1,933回のうち1回もなかった。

プロンプトではこれは治せない。Ploy は「説得」できそうな道をひと通り試したが、すべてそのまま失敗に終わった。

これはモデルが関数呼び出しを生成する方式に組み込まれた根本的な挙動であり、指示で説得できるものではない。回避策を設計するしかない。

本当に効いた修正方法は、provider の境界で一度 schema 変換を行うことだった。OpenAI 系のモデルに対してだけ、任意のプロパティをすべて「必須だが null を許容する」（anyOf: [T, null] を使う）形に書き換える。こうすればモデルは「これは使いません」とはっきり表明できる正式な手段を手に入れる。そして、すべてのツール呼び出しが必ず通過する関門で、その null を剥がしてしまえばよい。ツール側のコードは1行も変更する必要がない。まとめると、モデルが目にするのは正直さを表現できる schema であり、ツールが受け取るのは相変わらずこれまでと同じ入力だ。

// Before: 25 keys, every one carrying an invented value
{ "action": "read", "file_paths": [...], "offset": 0, "timeout": 120000, ... }

// After: 25 keys, 4 real values, 21 explicit nulls (stripped before the tool runs)
{ "action": "read", "file_paths": [...], "offset": null, "timeout": null, ... }

両社の prompt キャッシュはそもそも根本的に別物の設計だ

表面上はどちらも prompt キャッシュと呼ばれているが、「キャッシュ」という言葉の下にはまったく異なる2つのアーキテクチャが隠れている。移行の中で最も慎重に扱うべきだったのはまさにこの点だ。正しく移行する前は、GPT-5.6 は Opus よりも約50%割高に見えていたが、その割高分は Ploy 自身のキャッシュ設定に起因するもので、モデルの価格設定とは関係がなかった。

Ploy の prompt の冒頭には約29Kトークンの静的プレフィックス（ツール schema とコアシステムプロンプト）があり、どの会話でもまったく同じものだ。この部分をどうキャッシュするか、両社では大きく違っていた。

OpenAI が用意している正式な仕組みは明示的なものだ――prompt_cache_breakpoint でマークし、必須の prompt_cache_key を合わせて指定する。そしてこの key こそが設計を本当に分岐させる場所であり、これがキャッシュの識別子の一部だからだ。prompt がまったく同じでも key が違えば、ヒット率は0になる。key ごとに1つのキャッシュノードが対応し、そのノードは1分あたりおよそ15リクエストしか捌けず、それを超えると OpenAI は別の未ウォームなキャッシュノードにトラフィックを振り分けてしまう。

そのため「キャッシュを使うかどうか」は実質的な設計判断になる――この key をどの階層に紐づけるか、という判断だ。3通りの紐づけ方には、それぞれ違う末路が待っている。

Ploy が最終的に本番投入したのは workspace 単位の key で、リクエストはハッシュによってスループットの限られたキャッシュノードに振り分けられる。これは各顧客ワークスペースに専用レーンを1本ずつ割り当てるようなものだ。

key だけでは不十分で、Ploy はさらにシステムプロンプトを3層のブレークポイントに分割し、各層に1つの役割だけを持たせ、Anthropic 向けに使っている構造と揃えた。

この改修が終わると、GPT-5.6 の評価スイートあたりのコストは Opus を下回るところまで落ちた。それまでチームが注視していた価格差は、そのすべてがキャッシュ設定の誤りによるもので、モデルの価格設定とは関係がなかった。

もう一つ、避けられない構造的な制約がある：OpenAI 上では、その静的プレフィックスをワークスペースをまたいで共有することは構造上できない。Anthropic で共有できるのは、そのキャッシュが組織単位で区切られており、key 単位で区分されていないからだ。GPT-5.6 上では、各ワークスペースのキャッシュがいったんアイドル状態で期限切れになると、次の呼び出しでは29Kの冷たい書き込みを約0.18ドルで払い直すことになる。これは実質的なコストだが、上限があり予測可能だ。

前ターンの推論記録が突然取り出せなくなる問題は、スイッチ1つで解決する

最後の落とし穴は最も短いが、会話を実際に壊してしまうものだ。GPT-5.6 の Responses API はデフォルトで、前ターンの推論プロセスを「サーバー側 item 参照」として保存する――サーバーが番号を記録し、次のターンは直接その番号を問い合わせる。Ploy の会話は、途中で断続的にエラーを出すようになった：Item 'rs_...' not found。

store: false — 让 SDK 改为请求「加密推理内容」，把推理重放做成自包含的数据块，
而不是指向服务器状态的指针引用；否则中途可能报错 Item 'rs_...' not found

さらに Ploy が丸一日調査に費やしたことがもう一つある：一度サーバー側の推論状態が回路に組み込まれると、たとえ自分が送信したバイト列が厳密に末尾追加のみで一つも変更していなくても、上流の有効な prompt が変わってしまう場合があるのだ。

移行が完了して――最終成績表と、同種のチームへ向けたチェックリスト

4つの落とし穴を一つずつ埋めていった結果、冒頭で示した数字はすべて実現した。所要時間は約2.2倍速くなり、コストは27%下がり、視覚評価スコアは横ばいからやや上昇。キャッシュを再構築した後は初回ヒット率が0%から83.7%まで上がり、ヒットしなかった入力トークンは28%減少、評価スイートあたりのコストは Opus を下回る水準まで落ちた。schema を改修した後は空ファイル読み込みがゼロになり、ツール呼び出しは約30%減った。

この4つのステップには順序があり、まずフレームワークを直さない限り、それ以降のどの数字も信用できない。

同じagent、同じ開発ツール一式のまま、デフォルトの頭脳だけを入れ替えた。Ploy自社の評価では、agentに参考デザインどおりブランドのホームページを再構築させたところ、平均して次のようになった。

チームはさらに、GPT-5.6にはある癖があることに気づいた。特に誘導しないと、デザインがきれいだが没個性になりがちで、既存のブランドスタイルを見落としやすい（これは能力上の特徴で、本文で詳しく展開する）。だが本当に結果を狂わせるのは、他の見えない4つの落とし穴のほうだ。最も陰湿な一つは、こっそり空のファイルを読んでおきながら、自分では成功したと思い込んでしまうことだ。

GPT-5.6にはある癖があり、ツールを呼び出すたびに、全パラメータ欄を埋め尽くそうとし、使わない項目にはそれっぽい値をでっち上げる。厄介なのは、でっち上げた値と本物の値が、インターフェース上ではまったく見分けがつかないことだ。

「約2.2倍速い」を同じサイト構築タスクに置き換えて、実際どれくらい待つのか換算してみる。