OpenAIは開発者向けドキュメントに、GPT-5.6 Sol向けのプロンプトガイドを公開しています（本記事末の参考を参照。元URLは2026年7月17日時点でアクセス環境によって表示状況が異なることを確認しているため、本記事では2026年7月16日時点のアーカイブ版を主な出典としています）。本記事は、その内容をもとに、プロンプトの書き方に生じている考え方の変化を整理します。ガイドが直接述べていることと、そこから読み取れる考察とは区別して書きます。

結論 — 手順ではなく「成果・制約・根拠・完了基準」を書く

ガイドの前提は、次の一文に集約されています。

GPT-5.6 works best when prompts define the outcome, important constraints, available evidence, and completion bar, then leave room for the model to choose an efficient path.

（GPT-5.6は、プロンプトが成果・重要な制約・利用可能な根拠・完了基準を定義し、そのうえで効率的な経路の選択をモデルに委ねたときに、最もよく機能する）

これは、手順を一切書かないという意味ではありません。正確性に必要な前提の取得手順、ツールの利用条件、検証方法、再試行・停止条件、並列処理と逐次処理の使い分けなど、正確性や安全性に不可欠な手順は引き続き明示するようガイドも求めています。変わるのは、モデルが自ら判断できるはずの作業経路まで人間が細かく固定しない、という重心の置き方です。

ガイド後半の「Suggested prompt structure（推奨されるプロンプト構成）」は、Role・Personality・Goal・Success criteria・Constraints・Tools・Output・Stop rulesの8項目からなるテンプレートを示しています。このうちGoal・Success criteria・Constraints・Stop rulesの4項目は、冒頭で挙げられた成果・完了基準・制約という要素をほぼそのまま具体化したものと読めます。残る「根拠（evidence）」は独立した項目としては立てられておらず、ConstraintsやTools、Success criteriaの記述に分散するかたちで具体化されていると読めます（この対応づけはガイドが明示しているものではなく、本記事による整理です）。

なぜ「手順」ではなく「成果」なのか — 内部評価で示された効果

「Simplify prompts first」の節は、削るべきものと残すべきものを次のように挙げています。

削るべきもの:

  • 同じルールの重複した記述
  • 挙動を変えない冗長な例
  • すでに安定して実行できている挙動についての手順指示
  • タスクに無関係なツールとその説明

残すべきもの:

  • ユーザーに見える成果
  • 成功基準と停止条件
  • 安全性・業務・根拠・権限に関する制約
  • 文脈依存のツール選択ルール
  • 求められる出力の形式と検証方法

そのうえでガイドは、この整理を実施した結果として次の数値を示しています。

In a sample of internal coding-agent eval runs, configurations with leaner system prompts improved evaluation scores by roughly 10–15% while reducing total tokens by 41–66% and cost by 33–67%. Results will vary by workload, so treat these ranges as directional and validate changes on representative tasks from your own application.

（内部のコーディングエージェント評価の一部サンプルにおいて、システムプロンプトを簡潔にした構成は、評価スコアを約10〜15%向上させると同時に、総トークン数を41〜66%、コストを33〜67%削減した。結果はワークロードによって異なるため、これらの数値は方向性を示す参考値として扱い、自分のアプリケーションを代表するタスクで検証すべきである）

ガイド自身が明記しているとおり、この数値はコーディングエージェント向けの内部評価の一部サンプルによるものであり、チャットや文章作成、調査タスクなど他の用途でも同程度の改善が実証された結果ではありません。そのうえで、少なくともこの評価においては、指示を増やすことが精度に直結するわけではなく、むしろ削ることで評価スコアが上がったという結果が示されています。理由についてガイドは次のように述べています。

GPT-5-class models follow prompt contracts closely, so conflicting rules can create more instability than missing detail.

（GPT-5系のモデルはプロンプトの契約に忠実に従うため、矛盾したルールは、詳細の不足以上に不安定さを生みかねない）

モデルがプロンプトの記述に忠実であるほど、書き手が無意識に埋め込んでしまう矛盾がそのまま不安定な挙動として現れやすくなります。手順を書き込むほど安全になるという直感は、この関係のもとでは必ずしも成り立ちません。

「成果を書く」とは具体的にどういうことか

「Outcome-first prompts and stopping conditions」の節は、この考え方を次のように説明しています。

Describe the destination rather than prescribing every step. GPT-5.6 can usually choose an efficient search, tool, or reasoning path when the prompt states what good looks like.

（すべての手順を規定するのではなく、目的地を記述する。プロンプトが「何をもって良しとするか」を述べていれば、GPT-5.6は多くの場合、効率的な検索・ツール・推論の経路を自ら選べる）

完了基準を具体化するのが停止条件（stopping conditions）で、いつ答え、いつ再試行し、いつ確認を挟むかを定義するものです。ガイドが挙げる例は次の通りです。

After each result, ask whether the core request can now be answered with useful evidence. If yes, answer.

（各結果の後、核心的な要求に有用な根拠をもって答えられる状態かを問う。答えられるなら、答える）

あわせてガイドは、ALWAYS・NEVERのような絶対規則の多用を避け、ツールを使うかどうかや反復を続けるかどうかといった判断が必要な場面では、絶対規則ではなく判断基準を書くことを勧めています。

この記事自体を題材に、2通りの書き方を比べてみます（OpenAIの例ではなく、比較のために本記事が作成したものです）。

手順型:

まず公式サイトを検索してください。次に関連ページを3件開き、
それぞれを要約してください。その後、共通点を抽出して……

成果型:

OpenAI公式情報だけを用いて、GPT-5.6のプロンプト設計の変更点を
説明してください。重要な主張には根拠を付け、公式情報で確認でき
ないことは推測として区別してください。読者が既存のプロンプトを
修正できる状態になれば完了です。

後者は、検索回数や閲覧するページの順序を固定していません。決めているのは成果（変更点の説明）・根拠（重要な主張への裏付け）・完了基準（読者が自分のプロンプトを直せる状態）です。ただし「公式情報のみを根拠とする」という制約は、前者と同じく残っています。

自律性の境界とツールの絞り込み

「成果を書いて経路を委ねる」という設計は、モデルがどこまで自分の判断で動いてよいかという線引きとセットになります。「Define autonomy and approval boundaries」の節は、承認なしに進めてよい行動と、承認を要する行動を次のように分けています。

  • 承認不要（安全な範囲内の行動）: ファイルの読み取り、ログの確認、範囲内のコード編集、破壊的でないテストの実行、依頼された範囲内でのローカルな変更
  • 承認が必要な行動: 外部への書き込み、破壊的な操作、購入、対象範囲の実質的な拡大

Define what level of action each request authorizes so the model can continue safe, in-scope work without unnecessary pauses while stopping before external, destructive, costly, or scope-expanding actions.

（それぞれの依頼がどの水準の行動を許可しているかを定義し、モデルが安全で範囲内の作業を不要な中断なく続けられるようにする一方で、外部への影響・破壊的・高コスト・範囲拡大を伴う行動の手前では止まるようにする）

「Tool routing」の節では、タスクに関係のあるツールだけを渡すこと、正確さが取得手順に依存する場合はその前提手順を省略できないと明記することが挙げられています。また「Programmatic Tool Calling」（PTC）は、フィルタリング・重複排除・集計・バッチ処理のような、まとまった範囲の処理に限って使うべきものとされ、1回の呼び出しで済む場面や、結果をもとに次の判断が変わる場面、最終回答に引用が必要な場面では、直接の呼び出しの方が向くとされています。

長時間タスクにおける振る舞い

「Long-running workflows and state」の節は、複数ステップにわたるタスクでの報告のしかたを扱っています。最初のツール呼び出しの前に短い前置きを示し、以降は局面が大きく変わったときだけ更新するという方針で、次のように述べています。

Do not ask the model to narrate routine tool calls.

（日常的なツール呼び出しについて、逐一実況させてはならない）

1つの更新は「何が確定したか」と「次に何をするか」を1つずつ述べるにとどめ、会話の履歴を圧縮する際も、節目ごとにまとめることが勧められています。

このガイドの本文（2026年7月16日時点のアーカイブ）では、CodexやChatGPT Agentを対象とした説明は行われていませんでした。ただし、この節が定めている「日常的な呼び出しは逐一実況しない」「局面が変わったときだけ報告する」という振る舞いは、人が逐一介入しなくても長時間動き続けるタイプの自律実行に共通して必要になる設計だと考えられます。なお、OpenAIのドキュメントはその後更新されており、関連する現行のModel guidanceには「Migrate with Codex」という節が設けられ、Codexが明示的に扱われています。

「成果を書く」への転換をどう見るか

ここまで見てきた設計は、要求を細かな手順として書き下し、ステップごとにモデルを誘導する実践とは対照的です。ただし本ガイド自体はそうした実践と名指しで比較しているわけではなく、この対比は本記事による整理であることを断っておきます。

本ガイドが比較対象として挙げているのはGPT-5.5です（reasoning effortの移行については、GPT-5.4も基準として並記されています）。たとえば「Personality, collaboration, and response length」の節は、次のように述べています。

GPT-5.6 tends to be more concise by default than GPT-5.5.

（GPT-5.6は、GPT-5.5と比べて既定でより簡潔になる傾向がある）

そのうえで、詳細さの既定値はtext.verbosityパラメータ（low・medium・high）で設定し、タスク固有の要求はプロンプト側に書くという役割分担が推奨されています。あわせて「Prompt migration workflow」の節は、モデルを切り替える際にまず既存のreasoning effortの設定を保ったまま基準評価を取り、足場となっていた指示を段階的に取り除きながら、測定された劣化にだけ的を絞った修正を加える、という手順を挙げています。プロンプトの書き換えとモデルの挙動変化を同時に動かさないための順序です。

これらを総合すると、本ガイドが示しているのは単なる文章術の変更ではなく、成果・制約・根拠・完了基準というタスクの外枠を定義し、そこに至る経路の選択と細部の判断をモデルに委ねるという役割分担です。人間が担う作業の重心は、「AIへの指示を書く」ことから、「AIに任せる仕事の枠組みを設計する」ことへ移りつつあるように見えます。

まとめ

  • GPT-5.6のプロンプトガイドは、成果・制約・根拠・完了基準を定義し、モデルが判断できる作業経路は固定しない設計を推奨している
  • OpenAI内部のコーディングエージェント評価では、簡潔にした構成が評価スコアを約10〜15%向上させ、トークン数を41〜66%、コストを33〜67%削減したという結果が示されている（ガイド自身、結果はワークロードにより異なり方向性の参考値として扱うよう注記している）
  • 自律性の境界（承認不要な行動と承認が必要な行動の線引き）、ツールの絞り込み、長時間タスクでの報告頻度も、この設計思想の延長として整理されている
  • ガイドが比較対象として挙げているのはGPT-5.5（reasoning effortの移行ではGPT-5.4も並記）。CodexやChatGPT Agentを対象とした説明は、2026年7月16日時点のガイド本文には見当たらなかった。関連する現行のModel guidanceにはCodexを扱う節がある
  • 人間が担う作業の重心が「指示を書く」ことから「タスクを設計する」ことへ移りつつあるという見立ては、本記事による考察である

追記（2026年7月18日）: 本記事が主な出典とした2026年7月16日時点のアーカイブ版の記述のうち、冒頭の定義文・プロンプト契約に関する理由づけ・停止条件の節・長時間タスクの節に相当する内容は、2026年7月18日時点で確認した現行ページには見当たりませんでした。現行ページは単体のガイドではなく、より広い範囲を扱う「Model guidance」ページに統合されています。詳しい照合は続編記事で整理しています。

参考