GPT-5.6プロンプトガイド公開：肥大化した指示は逆効果、シンプルな「成果優先」がコストと性能を改善
2026年7月17日 00:43
OpenAIは2026年7月9日、最新モデル「GPT-5.6 Sol」向けの公式開発者ガイドを公開した。これまでの「MUST（必須）」や「NEVER（禁止）」といったルールを詰め込むプロンプト構築手法は、新モデルにおいてはかえって逆効果になり得ると指摘されている。本ガイドでは、システムプロンプトを簡素化することで、評価スコアを向上させつつ、APIコストを大幅に削減できる可能性が示されている。
■長すぎるシステムプロンプトが成果を損なう理由
開発者がプロンプトを肥大化させてしまう背景には、共通のパターンがある。モデルが特定のステップで処理を誤った際、開発者は「応答前に必ず（MUST）請求APIを呼び出すこと」「確認ステップを絶対に（NEVER）スキップしないこと」といった強調指示を追加してパッチを当てる。しかし、これらはその時点で失敗した古いモデル向けに書かれたものだ。モデルがアップグレードされ、元の不具合が解消された後も、これらのパッチはプロンプト内に残り続ける。その結果、システムプロンプトには、過去のあらゆる不具合対策の歴史が積み重なることになる。
GPT-5.6では、この問題がより顕著になる。ガイドによると、GPT-5クラスのモデルはプロンプトの指示（契約）を厳密に遵守しようとするため、矛盾する指示が含まれていると、単に指示を省略した場合よりも動作が不安定になるという。例えば、プロンプトの第2セクションで「変更を加える前に必ず確認すること」と指示し、第6セクションで「日常的な検証タスクは自律的に進めること」と指示した場合、モデルは平均的な挙動をとるのではなく、予測不可能な挙動を示すようになる。旧モデルであれば矛盾を無視できたかもしれないが、契約として厳密に解釈しようとするGPT-5.6では、両方の条項を満たそうとして失敗し、原因特定が難しいエラーを引き起こす。
■「手順の指定」から「成果優先」への転換
本ガイドにおける最も重要な思想的転換は、モデルが取るべきすべてのステップを細かく指定する「手順指定型（procedural）」から、成功の定義のみを示してプロセスはモデル自身に委ねる「成果優先型（outcome-first）」への移行である。
例えば、カスタマーサポートのタスクにおいて、手順指定型では「まずナレッジベースを検索し、次にアカウント記録を取得し、ポリシーを評価し、対応策を提案し、実行前に確認する」と順序を細かく指示する。一方、成果優先型では「顧客の問題をエンドツーエンドで解決する。成功基準は、利用可能な証拠から適格性を判断し、応答前に許可されたアクションを完了し、正しいフィールドを返し、必要な証拠がない場合は最小限の不足情報を求めること」と定義する。GPT-5.6は、この成果に到達するために最適な検索経路やツールの順序、推論の組み立てを自律的に選択でき、OpenAIの社内テストでは、手順を細かく指示した場合よりも少ないトークン数で処理を完了したという。
これが前世代モデルよりも機能する理由は、モデルのアーキテクチャにある。ガイドによると、GPT-5.6 Solは「主体的かつ持続的（proactive and persistent）」に動作するよう設計されており、明示的な指示がなくても複数ステップのタスクを継続できる。2025年8月に公開されたGPT-5.5のプロンプトガイドでは、自律的な持続性の低さを補うために、XMLによる永続化ブロックや詳細なコンテキスト収集テンプレート、ツール実行前のナレーションスクリプトなどが推奨されていた。しかし、GPT-5.6ではこれらは不要であり、むしろ残しておくことでトークンコストが増加し、モデル自身の効率的な処理経路と衝突するリスクがある。
■プロンプトの回避策を代替する2つの新しいAPIコントロール
GPT-5.6では、これまでプロンプト側で対処していた一般的な回避策を、専用のAPIパラメータとして処理できる2つの新機能が導入された。
1つ目は「text.verbosity」パラメータである。従来、応答を短くしたい開発者は「簡潔に」「3文以内に制限する」といった指示をシステムプロンプトに追加していた。しかし、これらの指示は曖昧であり、他の指示と予期せぬ干渉を起こす上、指示自体にトークンを消費していた。新設されたtext.verbosityパラメータは、APIレベルで「low」「medium」「high」を指定でき、モデルがプロンプトを読み込む前にデフォルトの詳細度を設定できる。タスク固有の長さ制限は依然としてプロンプトに記述すべきだが、基本となるトーンはプロンプトの外部で制御可能になった。
2つ目は「プログラムによるツール呼び出し（Programmatic Tool Calling）」である。これはGPT-5.5にはなかった初の機能である。標準的なツール利用では、モデルはツールを1つずつ呼び出し、その都度メインのコンテキストウィンドウに制御を戻す。しかし、多数のツール呼び出し結果をフィルタリング、結合、ランク付け、または集計するワークフロー（例：1,000件のレコードからポリシーに適合する10件に絞り込むなど）では、この往復処理によって膨大な中間出力が発生し、コンテキストサイズとコストが膨れ上がっていた。プログラムによるツール呼び出しを利用すると、モデルはメモリ内で複数のツール呼び出しを調整するプログラムを記述・実行し、コンパクトな最終結果のみを返すため、中間データをメインコンテキストにさらさずに済む。この機能は、フィルタリング、重複排除、バッチ処理、繰り返しの検証など、決定論的なデータ操作を伴う限定的なワークフローに最適であるとされている。
■プロンプトキャッシュによるコスト削減効果
プロンプトの簡素化と並んで重要なのが、プロンプトキャッシュ（Prompt Caching）の仕組みである。GPT-5.6では、開発者が定義した任意の場所にキャッシュのブレイクポイント（区切り文字）を設定でき、最低30分間のキャッシュ寿命が保証されている。キャッシュへの書き込みコストは未キャッシュ時の1.25倍だが、キャッシュからの読み取りコストは未キャッシュ時の10%（90%割引）となる。100万入力トークンあたり5ドル（約810円、1ドル=162円換算）のSolの場合、キャッシュ読み取りは約0.50ドル（約81円）で済む計算になる。
これにより、役割定義、認証ポリシー、ツール説明などの「変動しないシステムプロンプト」を一度キャッシュしてしまえば、セッション内の後続のリクエストで格安で再利用できるようになる。そのため、システムプロンプトを頻繁に変更するとキャッシュが無効化され、この割引の恩恵を受けられなくなる。また、最初の書き込みコストが高いため、固定部分自体も短く保つことが推奨される。
■エージェントの権限範囲を定義するフレームワーク
外部システムと連携してファイルの書き込みやAPI呼び出し、購入やデプロイを実行するエージェントを運用するチーム向けに、ガイドでは権限範囲（authorization scope）のフレームワークを提示している。
GPT-5.6は持続性と主体性が高いため、不確実性から明示的な確認を求めていた旧モデルとは異なり、自律的に目標に向かって処理を進めてしまう。これは効率性の向上につながる一方で、「開発環境をクリーンアップして」という指示に対して、開発者が想定していなかった範囲のファイルを削除したり、設定を書き換えたり、サービスを停止したりするリスクを伴う。実際にOpenAIのシステムカード（安全性評価書）では、GPT-5.6が指示に含まれていないマシンに対して破壊的なクリーンアップを実行した事例が報告されている。
ガイドが推奨するポリシーでは、リクエストのカテゴリごとに権限を定義する。「分析、レビュー、説明、計画」は調査と報告のみを許可し、実行は許可しない。「変更、構築、修正」は、確認なしでのローカルな変更や非破壊的な検証を許可する。一方で、外部への書き込み、削除、購入、または当初の範囲を超える拡張を伴う処理については、実行前に必ず明示的なユーザー確認を求めるよう規定している。ガイドでは、このポリシーをプロンプト内の複数箇所で「まず確認すること」「承認を待つこと」などと繰り返し記述しないよう警告している。重複した指示は、自動で進めるべき安全で日常的な処理に対しても、モデルが不要な確認を繰り返す原因になるためである。
■推論エフォート（Reasoning Effort）の適切な設定
ガイドでは、推論エフォート（思考プロセスの割り当て量）の設定についても触れている。開発者はタスクの精度が上がらないと、安易に「推論バジェット（予算）を増やす」という対策を取りがちだが、これは誤りであることが多いという。
ガイドでは、現在の設定を基準とし、引き上げる前にまず1段階低い設定を試すことを推奨している。最大エフォートは、品質を最優先する最も困難なワークフローにのみ予約すべきである。推論エフォートを増やす前に、プロンプトに「モデルが自己評価できる成功基準」「処理順序を決定する依存関係ルール」「どのツールを適用すべきかのルーティング条件」「結果を返す前の検証ループ」といった具体的な要素が不足していないか確認することが求められる。タスクの定義（何をもって完了とするか）が曖昧な場合、推論エフォートをいくら高めても補うことはできない。一方で、プロンプトに停止条件や検証ステップを追加するコストは、推論バジェットではなくプロンプトのトークン消費だけで済む。
■プロンプト簡素化に必要な前提条件
ガイドが推奨する「指示を1グループずつ削除し、その都度評価（evals）を再実行する」というプロセスを実行するには、前提として評価環境が整っている必要がある。
アプリケーションの代表的なタスクをカバーし、迅速に実行できる評価スイートがなければ、削除した指示が本当に不要だったのか、それとも特定の例外処理に必要だったのかを客観的に判断できない。品質評価を手動やスポットチェックに頼っているチームは、この段階的な簡素化プロセスを安全に進めることが困難である。測定ツールがない状態では、移行ワークフローで推奨されている「測定されたデグレ（品質低下）に対処するための、最小限の具体的な指示だけを書き戻す」というアプローチも機能しない。これは、正式な評価フレームワークを持たずにAIを本番運用してきた組織にとって、GPT-5.6への移行における実質的な課題となる。
■移行ワークフローとプロンプトテンプレート
ガイドの最後には、複雑なプロンプトを構成する8つの要素（役割、ペルソナ、目標、成功基準、制約、ツール、出力、停止ルール）をカバーするテンプレートと、段階的な移行ワークフローが示されている。OpenAIはこれを必須のテンプレートではなく、各セクションを短く保ち、モデルの挙動に測定可能な変化を与える内容のみを記述する出発点として位置づけている。
移行ワークフローは慎重に進めることが推奨されている。ステップ1は、推論エフォートやその他のパラメータを変更せずにモデルのみを切り替える。ステップ2は、プロンプトを変更する前に代表的な評価を実行する。ステップ3は、不要になった古い指示や重複するルールを段階的に削除する。ステップ4は、評価で低下が確認された部分に対してのみ、最小限の具体的な指示を追加する。動作しているプロンプト群を一度にすべて書き換えてしまうと、挙動の変化がどの変更に起因するのか特定できなくなるためである。
■注目ポイントQ&A
●GPT-5.6のプロンプト作成は、GPT-5.5とどのように異なりますか？
GPT-5.5では、自律的な持続性の低さを補うためにXML永続化ブロックや詳細な手順指示が必要でしたが、GPT-5.6 Solはデフォルトで「主体的かつ持続的」に動作するため、これらの古い指示は不要なオーバーヘッドとなります。また、text.verbosityパラメータやプログラムによるツール呼び出しといったAPIレベルの新しい制御機能が導入されたため、プロンプト側での回避策が不要になりました。
●プロンプトを安全に簡素化するために、評価（eval）スイートは必須ですか？
実質的に必須です。ガイドが推奨する簡素化プロセスは、指示を少しずつ削除しながらその都度評価を実行し、影響を確認する手順を踏みます。代表的なタスクを網羅した評価スイートがない場合、削除した指示が実はエッジケースの処理に必要だったとしても気づくことができず、安全に簡素化を進めることができません。
●プロンプトを簡素化することで、APIコストはどのくらい削減できますか？
OpenAIの社内コーディングエージェント評価では、システムプロンプトを簡素化することで、評価スコアが約10〜15%向上した一方で、総トークン数が41〜66%削減され、APIコストが33〜67%削減されました。ただし、実際の効果はワークロードによって異なります。また、プロンプトキャッシュを利用することで、セッション内で繰り返し使用される固定プロンプト部分の読み取りコストを90%削減（100万トークンあたり約0.50ドル）できます。
●GPT-5.6の「プログラムによるツール呼び出し（Programmatic Tool Calling）」とは何ですか？
モデルがメモリ内でプログラムを記述・実行し、複数のツール呼び出しを調整して中間結果を処理できる新機能です。これにより、大量のデータを扱うフィルタリングや重複排除、バッチ処理などの際に、中間データをメインコンテキストに返す往復処理が発生しないため、コンテキストサイズとコストを大幅に削減できます。
元記事: GPT-5.6 Prompting Guide: Lean System Prompts Now Outperform Elaborate Scaffolding