- Ployは、本番マーケティングWebサイトを計画・構築・検証するエージェントをClaude Opus 4.8からGPT-5.6 Solへ切り替え、すべてのワークスペースのデフォルトモデルに設定した
- 評価ハーネスのモデル別前提を修正した後、ホームページ再構築タスクで平均実行時間は8分から3分42秒に短縮され、コストは$3.06から$2.22へ27%低下し、視覚スコアも0.970に向上した
- GPT-5.6はツール呼び出しの任意パラメータ25個をすべて任意の値で埋めてしまい、ファイル読み取りの52〜64%が空結果を返していたが、任意フィールドを必須・nullableに変更すると空読み取りは0%に減り、ツール呼び出しも約30%減少した
- OpenAIとAnthropicのキャッシュ範囲・スループット構造の違いにより、GPT-5.6は当初約50%高く計測されたが、ワークスペース単位のキャッシュキーと階層ごとのbreakpointを適用し、初回呼び出しヒット率を0%から83.7%に引き上げ、未キャッシュ入力トークンを28%削減した
- モデル切り替えのコストと性能はモデル自体だけでなく、評価予算、ツールスキーマ、キャッシュ構造、推論リプレイ方式にも左右されるため、既存モデル向けに最適化されたプロバイダー別前提を先に見つけて修正してこそ、信頼できる比較と安定運用が可能になる
Claude Opusを置き換えたGPT-5.6 Sol
- Ployエージェントは、本番マーケティングWebサイトのページを計画し、コードベースを読み、コンポーネントや画像を生成し、結果をスクリーンショットで確認したうえで、作業完了かどうかを判断する
- 数か月のあいだClaude Opusを置き換える基準を満たしたモデルはなく、デフォルトモデルは4か月間、Opus 4.7、4.8の順で維持されていた
- GPT-5.6 Solは、同一タスクを対象とした1対1評価で初めてOpusを上回り、すべてのPloyワークスペースのデフォルトモデルになった
- 初期評価でも、完了したビルドの実行時間は半分未満、コストは27%低く、既存モデルと同等またはそれ以上のスコアを記録し、移行を進める根拠となった
- PloyはVercel AI SDKを使っているが、モデル切り替えの過程で、ツール引数の構成、プロンプトキャッシュ、ターン間の推論リプレイに関するプロバイダー別前提がスタック全体に残っていることを発見した
- 移行は、評価ハーネス、ツールスキーマ、プロンプトキャッシュ、推論リプレイの順に修正しながら進められた
評価数値を信じる前にまずハーネスを修正
- 評価スイートは、本番エージェントを固定テストワークスペースで実行し、ホームページをゼロから構築するタスクから、複製リクエストを安全に実行できるかを判定するタスクまで、数百件のケースを扱う
- ビルドケースでは、視覚判定器が基準デザインと比較して10個の二値チェックを実施する
- hero領域が画面全幅を満たす写真シーンかを検査する
- 主要CTAがpill形ではなく、角の丸い長方形かを確認する
- コンテンツ検査、ツール実行経路検査、ファイルアサーションもあわせて行い、失敗時にはツール呼び出しとモデルテキストを含む完全な実行トレースを確認する
-
既存モデルの呼び出し方式に合わせられていた制約
- 既存のツール呼び出し予算はOpusの逐次呼び出し方式に合わせていたが、GPT-5.6は並列呼び出しを使うため、正しく問題を解いたケースでも予算超過になった
- 評価ランナーは、Opusがほとんど使わなかった一括ファイル読み取りをサポートしていなかったが、GPT-5.6はこれを頻繁に使った
- 初回実行で発生した生の失敗の約3分の1はモデルの挙動ではなくハーネスの前提に起因しており、モデル間で均等に分布してもいなかった
- 挑戦モデルと既存モデルの実行トレースを先に分類しなければ、新モデルが既存モデルらしく振る舞うほど有利な評価になる
-
暗黙のスコアしきい値
minScoreが欠けているデータセットは、警告なしにデフォルト値1.0を引き継ぐ- そのためGPT-5.6はheroスコア0.98を得ても失敗扱いされ、Opusもすべての個別チェックに合格したケースで失敗と判定された
- どちらの結果も十分成立するデザインだったが、モデルではなく暗黙のしきい値のために脱落した
修正後のベンチマーク結果
- ハーネス修正後、ブランドのホームページを基準デザインどおりに再構築する評価スイートを再実行した
| 完了ビルドあたりの平均 | Claude Opus 4.8 (n=11) |
GPT-5.6 (n=10) |
|---|---|---|
| コスト | $3.06 | $2.22 |
| 実行時間 | 8分00秒 | 3分42秒 |
| 入力トークン | 260万 | 170万 |
| 出力トークン | 33,000 | 17,100 |
| 視覚スコア | 0.936 | 0.970 |
- GPT-5.6はページを2.2倍高速で完成させ、コストは27%低く、出力トークンも約半分しか使わなかった
- 生成したコード量も少なかった
- 比較事例の1組では、Opusはほとんど使われない色系統まで含め、CSS変数174個と17,957文字の
globals.cssを生成した - GPT-5.6はCSS変数45個、2,508文字で、同等かそれ以上のレンダリング結果を出した
- 比較事例の1組では、Opusはほとんど使われない色系統まで含め、CSS変数174個と17,957文字の
-
デザイン品質と一貫性
- GPT-5.6は、クリーンでグリッドの詰まったレイアウトに強い一方、強く誘導しないとそのスタイルに収束しやすい傾向がある
- Opus 4.8向けに設計された既存ハーネスでは、既存デザインシステムを無視したクリーンだが無難な成果物をしばしば生成した
- デザインチームとエンジニアリングチームがモデルの誘導方法を改善した後は、本番で必要なブランド準拠基準を満たした
ツール呼び出しにおける任意パラメータ処理
- エージェントの
codeツールには最上位パラメータが25個あり、必須なのはactionだけで、残りは任意項目だった - Claudeは使う2〜3個のパラメータだけを送るが、GPT-5.6は呼び出しごとに25個すべてを送り、未使用フィールドも
offset: 0,timeout: 120000,siteId: "00000000-0000-0000-0000-000000000000"のようなもっともらしい値で埋めた - 3日間収集した本番の
code(read)実行トレースでも同じパターンが現れた
| モデル | 呼び出し数 | 25個の属性をすべて含む呼び出し |
|---|---|---|
gpt-5.6 |
6,635 | 6,635件、100% |
claude-opus-4.8 |
2,898 | 4件、0.1% |
claude-sonnet-5 |
1,933 | 0件 |
-
空のファイル読み取りが発生した原因
- 問題は単に引数が冗長だということではなく、ファイル読み取り実装がモデルの任意生成値とユーザー意図の値を区別できない点にあった
- 実装は
offset: 0を実際の引数として扱い、GPT-5.6のファイル読み取りの52〜64%が空結果を返した - ツールは有効な読み取りと空読み取りの両方に
success: trueを返したため、モデルは空ファイルを読んでいることを認識できなかった - 空結果を補おうとして呼び出し回数が増え、その結果品質まで悪化した
-
プロンプトとstrictモードでは解決しなかった問題
- ツール説明に未使用パラメータを省略するよう指示を入れても、25個すべてが生成された
- 各属性に
OPTIONAL, omit if unusedを付けても挙動は変わらなかった - OpenAIの
strictモードでも同じ結果になり、これを導入するには全スキーマからpattern、format、配列サイズ検証を削除する必要があった - この挙動はモデルの関数呼び出し生成方式に起因するため、プロンプトではなくスキーマを変更した
-
プロバイダー境界でのスキーマ変換
- OpenAI系モデルに対しては、すべての任意属性を
anyOf: [T, null]形式の必須・nullable属性に書き換えた - モデルは未使用パラメータを明示的な
nullで埋め、共有ツール呼び出し境界で検証する前にnullを除去する - ツール実装は変更せず、モデル向けスキーマだけで未使用値を表現できるようにした
// 変更前: 25個のキーがすべて任意の値で埋まる { "action": "read", "file_paths": ["..."], "offset": 0, "timeout": 120000 } // 変更後: 実際の値4個とnull 21個を送り、ツール実行前にnullを除去する { "action": "read", "file_paths": ["..."], "offset": null, "timeout": null }- 変更後、空のファイル読み取りは**52%から0%**に低下した
- 同じタスクに必要なツール呼び出し回数も約30%減り、空結果を繰り返し読む挙動が消えた
- OpenAI系モデルに対しては、すべての任意属性を
OpenAI方式に合わせたプロンプトキャッシュ
- 両プロバイダーともプロンプトキャッシュを提供しているが、実装方式は異なる
- この違いを反映する前は、GPT-5.6がOpusより約50%高く見えたが、原因はモデル価格ではなくキャッシュ構成だった
-
Anthropicの組織単位キャッシュ
- エージェントのプロンプトは、ツールスキーマと中核システムプロンプトから成る約29,000トークンの静的プレフィックスで始まり、すべての会話で同一である
- Claudeでは
cache_controlでキャッシュbreakpointを示し、プレフィックスを組織全体で共有する - どのワークスペースの会話でも1つの共有エントリを使え、キーごとのスループット制限もない
- キャッシュヒット率は92〜96%である
-
GPT-5.6で変わったキャッシュ挙動
- 従来のGPTモデルは暗黙的に部分プレフィックス一致をキャッシュしていたが、GPT-5.6は部分プレフィックス一致を廃止した
- 暗黙キャッシュは最新メッセージを基準に完全なプロンプト項目を作るため、同じ29,000トークンの静的プレフィックスを共有する新しい会話でも、初回呼び出しではキャッシュヒット率が0%になる
- その結果、会話ごとにプレフィックス全体が未キャッシュ料金で再請求される
- アプリケーションがキャッシュを使うかどうかにかかわらず、GPT-5.6はすべての未キャッシュプロンプトに1.25倍のキャッシュ書き込みサーチャージを適用する
-
明示的キャッシュキーの制約
- 明示的キャッシュには
prompt_cache_breakpointと必須のprompt_cache_keyが必要である - キー自体もキャッシュ識別性に含まれるため、同一プロンプトでもキーが違えばヒットしない
- 各キーは毎分約15リクエストを処理するキャッシュノードにマッピングされ、これを超えるとOpenAIは独立したコールドキャッシュを持つ別ノードへトラフィックを分散する
- そのため、どの単位でキーを切るかが重要な設計判断になる
- 会話ごとのキー: 新しい会話が共有プレフィックスにヒットできず、初回呼び出しヒット率は0%だった
- グローバルキー1つ: すべてのリクエストが1ノードにハッシュされ、本番トラフィックが15 rpmを超えるとコールドノードへ流された
- ワークスペースごとのキー: 顧客ワークスペース内の全会話がエントリを共有しつつ、キーごとのトラフィックは低く保てた
- 明示的キャッシュには
-
ワークスペース単位の階層型キャッシュ
- 実際の構成では、
ws:{workspaceId}形式のワークスペース単位キーを使い、システムプロンプトをbreakpoint階層に分割した - 項目Aにはツールと静的プレフィックスを入れ、セッション初回呼び出しのコストを下げた
- 項目Bには静的プレフィックスにワークスペースコンテキストを追加した
- 項目Cは初回ターンから最新メッセージまで連なる、セッションごとの完全なプロンプトチェーンである
- ワークスペースメモリが変わると項目Bはミスするが、項目Aは引き続きヒットするため、29,000トークン全体ではなく変更されたコンテキスト分だけを書き直せばよい
- 項目Cはプロンプトが厳密な追記専用構造になっているため、セッション内ではOpenAIの暗黙的な完全プロンプトチェーンを活用する
- OpenAIのキー分割のため、静的プレフィックスをワークスペース間で共有することはできない
- 一方Anthropicはキー分割のない組織単位キャッシュを使うため、プレフィックス共有が可能である
- GPT-5.6では、各ワークスペースがアイドル時間帯ごとに29,000トークンを1回コールド書き込みし、そのコストは約**$0.18**である
- このコストは範囲が限定されており、予測可能である
- 実際の構成では、
-
キャッシュ修正の結果
- 初回呼び出しのキャッシュヒット率は約0%から**83.7%**へ上昇した
- 全体の未キャッシュ入力トークンは28%減少した
- GPT-5.6の評価スイートあたりのコストはOpusより低くなり、初期のコスト差全体は誤ったキャッシュ構成に起因していた
- 片方のモデルだけがコールドキャッシュから始まる状態で行ったモデル間コスト比較は有効ではない
推論リプレイを自己完結型に変更
- GPT-5.6 Responses APIはデフォルトで前ターンの推論をサーバー側アイテム参照でリプレイするため、本番会話で断続的に
Item 'rs_...' not foundエラーが発生した store: falseを設定すると、SDKは暗号化された推論コンテンツを要求し、サーバー状態を指すポインタではなく自己完結型blobをリプレイする- アプリケーションが送るバイト列が追記専用構造でも、サーバー側の推論状態が有効プロンプトを変えることがある
- 評価ハーネス、ツールスキーマ、プロンプトキャッシュ、推論リプレイをすべて修正したGPT-5.6 Solは、現在Ployの本番デフォルトモデルとして運用されている
1件のコメント
Hacker Newsのコメント
「その程度の数値なら、実際にモデルを移行する価値がある」のような文句はあまりに滑稽だ。この記事を書かせた人には、せめて典型的なLLM文体だけでも手直ししてほしかった
コロン・読点・句点で短い句をつないでいく書き方もひどく、読んでいて息苦しい。部分接頭辞一致キャッシュがGPT-5.6で消えたというような良い洞察はあるが、読みやすい文章ではない
不要なコロン、長いダッシュ、強調に見せかけた文の断片、それに自分がよくやってしまう文法ミスを避けるよう規則を書き、技術文は明快で会話調、気取りのない Brian Kernighan と Rob Pike も参考対象に入れた。文書は読みやすいだけでなく、読みたくなるものであるべきだ
文書を頻繁に生成するなら、エージェントに WRITING.md を参照させる価値は大きい。最新モデルに替えるより、可読性がはるかに大きく改善することが多いし、モデルを変えても文体を一貫して保てる
以前は 5.4-nano と mini で回していた多様で小さく単純なワークフローを 5.6 に移したところ、全体として記事に書かれている程度の改善があり、一部の分類タスクでは品質も向上した
多くの会社では、こうしたモデルのアップグレードは実質的にコード1行の変更だ。重要なワークフローには優れたモデルルーターアーキテクチャを使っているが、単純なタスクまでそう構成する価値はなく、安定性の問題も考える必要がある
おおむね宣伝どおりに動いている。現在は作業の大半を terra に送っており、コストは半分になり、応答時間も 50% 改善した。luna は OpenCV の検出結果を補完する用途で使っていて、機能は非常に限定的だが高速で、ほとんど無料同然だ。Sol は我々のタスクでは terra より少し良い程度だった
Sol ultra は評価そのものにも優れていた。妥当な推奨とともに、直接確認・比較すべき出力の一覧、元データと加工データ、クエリごとの CPM を含む大きな資料を作ってくれた。Pro サブスクリプション料金以外は追加費用なしで数時間回した結果、コスト基準は 50% 下がり、スループットは 100% 増えた
私の経験も似ている。OpenRouter のようにフェイルオーバーを売りにするサービスは、サンドボックステスト以外ではほとんど役に立たない。本番モデルは実際には相互交換可能ではなく、本格的なエージェント作業をこなす実行環境は、予想以上に多くのモデル固有の特性に依存している
別のモデルがエラーなく動いたとしても、性能と効率は別問題だ。Claude 系のように、学習過程で慣れた表現に合わせてシステムプロンプトを調整すべきモデルもあれば、別の区切り記号でよりよく動くモデルもある。最適性能が重要なら、実行環境・プロンプト・モデルを1つのシステムとして見るべきで、部品のように自由に差し替えられると考えるべきではない
model -> {{prompts}, {tools descriptions}, ...}という対応表を作るケースも見たことがあるが、あまりに極端だ。ある時点からはモデルのほうが我々のプロンプトに適応すべきで、そうできないモデルはフェイルオーバー候補から外し、APIリクエストを送らなければよい深いインフラ洞察に満ちた記事の下で、コメントの半分が不自然な文体ばかり批判しているのは皮肉だ。Claude が文章を整えるのを手伝ったとしても、API 予算を 30% 削減し、空ファイル読み込みを修正する、すぐ使える青写真が含まれているなら、その方が重要ではないか
個人的には、文体に文句を言うのは滑稽に見える。自分は文法やスペルが苦手だからか、伝え方よりも概念、事実、議論といった中身そのものに集中する。文法やスペルは木であり、森こそが要点だ
自分の文章に誤りがあまり多くないのは、音声入力と自作ショートカットのおかげだ。選択したテキストをローカル LLM で校正してから置き換えてくれるが、この2つの道具ほど生活の質と文章品質を高めてくれたものはない
「今日からPloyエージェントは、今朝公開されたGPT-5.6 Solを使う」とのことだが、たった半日試しただけで切り替えたのか？ 会社はティーンエイジャーが運営しているのか？
評価ジョブはGitHub CIで実行され、ploy.aiが得意とするWebデザイン・マーケティング作業について、115件超の評価セットを約15分で一通り回せる。PostHogの機能フラグでモデルを有効化した後は、失敗を積極的に監視した
インターネットの1%以上を支えるWebflowを運営していた知見をPloyにできる限り移し、より多くのインターネットを支えようとしている
Ployエージェントは実際のマーケティングWebサイトを作成・修正し、計画立案、コードベースの読解、コンポーネント作成、画像生成、自身の結果の撮影と完了判定まで行うというが、厳密なテストをしていなくても、FableはOpusよりマーケティングサイト制作がはるかに得意だと予想する。プレゼン資料作成では確実にかなり優れている
OpenAI系モデルに対してだけ、選択属性をすべて必須にしつつ
anyOf: [T, null]でnullを許容するよう変更するという解決策は、どこか嫌な感じがする。変形版のMCPしか使ったことはないが、TypeScriptの型定義が、エージェントから推論バックエンドに送るJSON Schemaになぜ影響するのかははっきりしないMCP仕様には任意パラメータを表すフィールドが明示的にあるので、TypeScript層と実際に送信されるツール記述の間のどこかにバグがあるように見える。推論バックエンドが「有効なツール応答を生成する」から「任意パラメータのないJSON Schemaに適合する有効な応答を生成する」に変わった可能性もあるが、実際のリクエストを見ないと判断できない
required配列になくても値を埋めようとする原因の一部は、制約デコーディングを使うと知能が低下する現象に関係しているようだ。スキーマ妥当性は保証されるが能力が大きく落ちるため、分類・要約・プロンプト改善には向いていても、エージェントの反復実行では注意が必要だ
Claude Codeのような実行環境は前処理、復旧、後始末などを多く行っているが、通常は表に出ない。完全な正確性を前提に強制するより、実行環境をもっと緩くしてモデルごとの特性に合わせたほうが、実運用ではより簡単で良い。モデルも1〜2か月ごとに変わる。これが雰囲気で作る応用AIだ
OpusとSolでサイトを1つ作るとき、実際のコストがそれぞれどれくらいかかるのか、概算額を知りたい
ワークフローをReasonixに移し、DeepSeekでキャッシュヒットを活用したところ、補助金を受けていない米国プロバイダを使っても、リクエストコストは事実上ほぼ無料に近くなった
すべてのPloyワークスペースでGPT-5.6 Solをデフォルトにするより、実際にツールを扱う一部の作業ではLunaを検討する価値がある。驚くほど有能で高速だ
Solは人との対話やエージェント呼び出しのオーケストレーションには優れているが、すべての作業に使うには高すぎる。Sol1回分の価格でLunaを5回走らせられ、統計的にはサンプルが1つから5つに増える差はかなり大きい
0.9^5 = 0.59、つまり**59%**だ。Sol1回の精度は95%程度かもしれない。実際の数値は違うだろうが、最後にSolで検証するほうが安く済む可能性があるどの作業にどれだけ多くエージェントを使うかによっては、コストが増える一方で結果はむしろ悪化することもある