「指示を足せば安定する」は逆だった。GPT-5.6で変わるプロンプト設計

AIの出力がズレるたびに、僕はプロンプトへ注意書きを足していました。

「必ず最後まで実行してください」

「不明点があっても作業を止めないでください」

「ただし、勝手に変更しないでください」

「変更が必要な場合は必ず確認してください」

失敗するたびにルールを増やすと、最初は数十行だったAGENTS.mdやSkillが、いつの間にか何百行にもなります。

しかも、過去に追加した「必ず確認する」と、後から追加した「確認せず進める」が同じファイルに残っていました。

長いだけならまだしも、ルール同士が衝突していたんです。

OpenAIがGPT-5.6向けに公開したプロンプティングのベストプラクティスは、こうした指示に対して、かなりはっきり「削る」ことを勧めています。

ただし、短いプロンプトを作れば終わりという話ではありません。

回答の詳しさはAPI設定へ移し、自律実行と承認の条件は権限ポリシーとして分け、大量の定型処理はProgrammatic Tool Callingへ渡す。

GPT-5.6のプロンプト設計は「上手な頼み方」から、AIへ仕事を渡す仕組み全体の設計へ進んでいます。

プロンプトを削ると評価結果が上がった

OpenAI社内のコーディングエージェント評価では、システムプロンプトを簡素化した構成によって、評価スコアが約10〜15%向上し、総トークン数が41〜66%、コストが33〜67%減少した例が紹介されています。

もちろん、これは特定の評価環境で得られた結果です。

OpenAIも、同じ改善幅を期待するのではなく、自分たちの代表的なタスクで検証するよう注意しています。

それでも、指示を増やすことが常に安全側へ働くわけではないと分かります。

重複した指示や使わないツールの説明は、入力を長くするだけではありません。

何を優先すべきかを曖昧にし、本来なら自律実行できる作業でAIを止める原因にもなります。

僕は以前、プロンプトエンジニアリングの記事で、AIへ任せる一回の仕事を目的、入力、制約、手順、出力、例、評価基準へ分ける方法を書きました。

GPT-5.6でも、この作業仕様は必要です。

変わったのは、AIの振る舞いをすべてプロンプトの文章だけで制御しようとしない点です。

プロンプトだけで解決しない

GPT-5.6へ渡す情報は、役割ごとに置き場所を分けられます。

プロンプトへ何でも書くのではなく、設定で表現できるものは設定へ、権限で守るものは権限へ、検証すべきものは評価セットへ移します。

これはハーネスエンジニアリングで扱う、モデルの外側の設計と重なります。

プロンプトは不要になるのではなく、担当範囲が明確になります。

必要な仕様を残して重複を消す

OpenAIは、すでに機能しているプロンプトとツール構成から始め、指示、例、ツールを一度に全部変えないよう勧めています。

一つのグループを削るたびに、同じ評価セットを実行します。

削除する候補は次のとおりです。

1. 同じ意味を言い換えた指示
2. 現在は使っていない例
3. 今回の仕事に関係しないツール
4. 過去の一件だけに対応した古い注意書き
5. 長い会話の途中で重複して追加されたコンテキスト

反対に、目的、制約、完了条件まで消すわけにはいきません。

短いだけのプロンプト

記事を書いてください。
わかりやすくしてください。

これでは、何を完成させればよいのか分かりません。

対象読者、必要な根拠、記事の目的、禁止事項、出力形式がないため、AIは空欄を推測して埋めます。

重複のない作業仕様

# ゴール

OpenAI GPT-5.6のPrompting best practicesを、
AIエージェントを業務で利用する人向けに解説する。

# 読者

- ChatGPTやCodexを業務で利用している
- 長いプロンプトやAGENTS.mdを管理している
- APIの実装経験は初級から中級

# 必須内容

- プロンプトの簡素化
- 自律実行と承認の条件
- text.verbosity
- Pro mode
- Programmatic Tool Calling

# 制約

- OpenAI公式ドキュメントを原典にする
- 数値には条件と注意点を付ける
- ChatGPTの使い方とAPI固有の設定を混同しない
- 未検証の効果を実体験として書かない

# 完了条件

読者が既存プロンプトを点検し、
何を削り、何を設定や権限へ移すか判断できる。

# 出力

Markdownの記事本文。
各機能に実務例を付ける。

こちらの方が長く見えますが、同じ指示を繰り返していません。

プロンプトを短くするとは、情報量を雑に減らすことではありません。

AIが仕事を完了するために必要な仕様だけを、一度ずつ置くことです。

自律実行と承認の条件を一か所に置く

GPT-5.6は、複数工程の仕事を自発的に進められるようになっています。

その反面、どこまで進めてよいかが曖昧だと、二つの問題が起きます。

一つは、ファイルを読む、ログを見る、テストを実行するといった安全な作業でも、人間へ何度も確認して止まることです。

もう一つは、メール送信、公開、購入、削除など、本来は止まるべき操作まで実行することです。

OpenAIは、この違いを短いポリシーとして一か所に定義するよう勧めています。

# 実行ポリシー

回答、説明、レビュー、診断、計画を依頼された場合:
- 関係する資料を読み、結果を報告する
- 明示的に変更を依頼されていない限り、実装や変更は行わない

変更、実装、修正を依頼された場合:
- 依頼範囲内のローカル変更を行う
- 読み取り、ログ確認、編集、テストなど、
  非破壊的な検証は確認せず実行する

次の操作は実行前に確認する:
- 外部サービスへの書き込み
- データやファイルの削除
- 公開、送信、購入
- 費用が発生する操作
- 依頼範囲を大きく広げる変更

「必ず確認してください」を何度も書くのではなく、安全なローカル操作と確認が必要な操作を具体的に分けます。

「自律的に動いてほしい」だけでは、どこで止まるのかが分かりません。

自律性は性格の指定ではなく、操作ごとの権限として設計します。

回答の長さはtext.verbosityで決める

GPT-5.6はGPT-5.5よりも、標準状態で簡潔に答える傾向があります。

モデル移行前から使っていた「簡潔に答えて」「短くしてください」という指示を残すと、必要な説明まで削られる場合があります。

OpenAIは、回答の標準的な詳しさをtext.verbosityで制御するよう勧めています。

Responses APIでは、次のように指定します。

const response = await openai.responses.create({
  model: "gpt-5.6",
  text: {
    verbosity: "medium",
  },
  input: `
    障害報告を分析し、原因、影響、対応状況、
    未解決リスク、次のアクションを整理してください。
  `,
});

text.verbosityは、回答全体の標準的な詳しさを決める設定です。

今回の仕事で絶対に残してほしい情報は、プロンプト側で指定します。

結論から書く。

短くする場合でも、次の情報は残す:
- 結論を支える根拠
- 重要な注意点
- 未確定事項
- 次のアクション

先に削るもの:
- 長い導入
- 同じ内容の繰り返し
- 一般的な背景説明
- 根拠のない励まし
- 不要な締めの挨拶

文字数を減らすことが目的ではありません。

読者が判断するために必要な情報を残し、判断に使わない情報から削ります。

文体は形容詞ではなく編集ルールで伝える

「friendly」「empathetic」のような広いラベルは、人によって解釈が変わります。

必要以上に謝る、毎回ユーザーを褒める、回答の前後へ長い励ましを付けるといった文章も、モデルにとっては「親切」の候補です。

文体を揃えたいなら、人格を形容するのではなく、文章上の判断を指定します。

# 文体

- 回答は結論から直接書く
- 問題が報告されたら、具体的な問題を一文で認識してから対応を書く
- 安心させる表現は、不安を軽減できる根拠がある場合だけ使う
- 一般的な称賛や、内容のない励ましは入れない
- 次の行動がある場合は明示する
- 不要な締めの挨拶は省く

「やさしく書く」ではなく、どういう順番で、何を言い、何を言わないかまで分けます。

この方法は、記事、カスタマーサポート、営業メール、社内AIのどれにも使えます。

Pro modeを使う仕事

GPT-5.6では、Responses APIのreasoning.modeにstandardとproが用意されています。

標準はstandardです。

proは、一つの最終回答を返す前にモデルがより多くの作業を行う実行モードです。

難しい仕事で信頼性が上がる可能性がある一方、待ち時間とトークン使用量は増えます。

const response = await openai.responses.create({
  model: "gpt-5.6",
  reasoning: {
    mode: "pro",
    effort: "medium",
  },
  input: `
    このデータベース移行計画をレビューしてください。

    データ消失または長時間停止につながる失敗要因を探し、
    各項目について該当する手順、影響、発生可能性、
    具体的な対策を示してください。

    重要度が高い順に5件返してください。
  `,
});

reasoning.modeとreasoning.effortは別の設定です。

modeは標準実行かPro実行かを選び、effortはそのモード内で推論へかける量を決めます。

reasoning.effortを省略すると、GPT-5.6はどちらのモードでもmediumを使います。

Pro modeを使うときも、プロンプトへ「もっと深く考えて」と追加する必要はありません。

ゴール、関連する文脈、制約、必要な根拠、成功条件、出力形式を中心にした同じプロンプトを使います。

同じ代表タスクをstandardとproで実行し、成功率、完全性、根拠、トークン数、待ち時間、コストを比較します。

評価できない仕事へPro modeを付けても、品質が上がったのか判断できません。

Programmatic Tool Callingを使う仕事

**Programmatic Tool Calling（PTC）**は、モデルがJavaScriptを書き、Responses APIリクエスト内のツールを組み合わせて実行する仕組みです。

プログラムは並列呼び出し、条件分岐、ループを使い、大きな中間出力から必要な情報だけを小さくまとめられます。

OpenAIのPTCガイドは、処理方法をあらかじめ限定できる仕事を主な用途に挙げています。

• 絞り込み
• 結合
• ランキング
• 重複除去
• 集計
• バリデーション
• 大量結果の構造化と圧縮

ツールを複数回呼ぶという理由だけで、PTCを使うわけではありません。

たとえば、毎朝の競合コンテンツ調査なら、次のように分けられます。

PTCへ渡す範囲は、プロンプトでも具体的に指定します。

<tool_orchestration>

Programmatic Tool Callingを使う範囲:
- 取得済み記事のURL正規化
- 重複除去
- 公開日による絞り込み
- 媒体別の件数集計

使用してよいツール:
- search_articles
- get_article_metadata

出力:
- canonical_url
- title
- published_at
- source
- duplicate_group_id

独立した呼び出しは安全な範囲で並列実行する。
一時的な失敗は最大2回まで再試行する。
同じ呼び出しを重複実行しない。
不足データを推測で補完しない。

次の処理は直接ツール呼び出しで行う:
- 記事本文の意味評価
- 引用の確認
- 最終レポートの検証
- 外部サービスへの書き込み

</tool_orchestration>

PTCのprogram_outputと、最後にユーザーへ返すassistantのmessageは別の出力です。

プログラムが正しいデータを取得しても、最終回答で必要な項目、引用、注意点を落とす可能性があります。

ツール処理だけでなく、ユーザーが実際に受け取る最終回答まで評価します。

GPT-5.6向けの最小プロンプト

ここまでの内容は、次の形にまとめられます。

# ゴール

この作業によって、最終的に何を達成するか。

# コンテキスト

今回の判断に必要な事実、資料、対象読者、現在の状態。
情報が競合した場合に優先する原典。

# タスク

今回実行する具体的な作業。

# 実行範囲

確認せず実行してよい操作。
実行前に確認が必要な操作。
今回変更してよい範囲。

# 制約

禁止事項。
推測してはいけない情報。
守るべき形式、法律、セキュリティ、業務ルール。

# 完了条件

何が確認できれば作業完了か。
どのテスト、根拠、成果物が必要か。

# 出力

結論、根拠、注意点、未解決事項、次のアクション。
必要な形式と順番。

以前のプロンプトテンプレートと比べると、「役割」は必須項目から外しています。

役割や例が製品要件を表す場合や、実測した品質差を直す場合には残します。

一方で「あなたは世界最高の専門家です」のように、判断基準を増やさない役割は、最初から入れなくても構いません。

モデルに手順をすべて教える必要は減りました。

それでも、責任範囲と合格条件を伝える必要はなくなりません。

既存プロンプトを直す7つの手順

既存のシステムプロンプト、AGENTS.md、CLAUDE.md、Skillを一気に書き換えるのはおすすめしません。

全部を同時に変えると、何を削ったことで改善したのか、どこを消したことで失敗したのか分からなくなるからです。

1. 代表的な入力と合格条件を固定する

普段よく使う入力、失敗しやすい入力、境界ケースを用意します。

プロンプトの長さではなく、出力が合格したかどうかを比較できる状態にします。

2. 重複したルールを探す

同じ意味の指示が、複数の見出し、ファイル、ツール説明へ書かれていないか確認します。

「推測しない」「確認する」「最後まで実行する」は重複しやすいルールです。

3. 一度しか使わない注意書きを外す

過去の一件に対応するために追加したルールが、現在も必要かを見ます。

必要なら全体ルールではなく、その作業専用のSkillやテストケースへ移します。

4. 関係ないツールを外す

今回使わないツールの説明まで、毎回モデルへ見せないようにします。

ツールカタログが大きい場合は、必要なツールだけを動的に読み込む設計も検討します。

5. プロンプト、設定、権限を分ける

回答の詳しさはtext.verbosity、推論量はreasoning.effort、高品質モードはreasoning.mode、実行可能な操作はツール権限へ移します。

プロンプトには、今回のゴール、判断材料、制約、完了条件を残します。

6. 自律実行と承認の条件を一か所へまとめる

安全なローカル操作と、外部、破壊的、有料の操作を分けます。

同じ承認ルールを複数箇所へ書かないようにします。

7. 同じ評価セットで再実行する

変更前と変更後で、次の項目を比べます。

短くなった、ツール呼び出し回数が減った、処理時間が短くなったというだけでは改善と判断できません。

最終回答が既存の評価に合格したうえで、トークン、時間、コストが減った場合に改善と判断します。

プロンプトをハーネスの一部として設計する

GPT-5.6のプロンプティングで中心になっているのは、文章をうまく書くテクニックだけではありません。

指示の重複を消す。

自律実行と承認の条件を決める。

回答の詳しさをAPI設定へ移す。

難しい仕事だけにPro modeを使う。

大量の定型ツール処理をPTCへ分ける。

最終回答まで評価する。

この流れを見ると、プロンプトはAIへ渡す仕様の一部になっています。

AIが止まったとき、僕もこれからはいきなり注意書きを足さないようにします。

まず、ゴールが曖昧なのか、必要な資料がないのか、権限の分け方がないのか、出力量の設定が合っていないのか、ツールの実行経路が間違っているのかを確認します。

それでも必要な場合だけ、プロンプトへ一行を追加します。

良いプロンプトは、すべてが書かれた長い指示書ではありません。

ほかの設定では表現できない仕事の目的と条件だけが、明確に残った指示書です。

それではまた！

情報元

• OpenAI「Model guidance：Prompting best practices」
• OpenAI「API deployment checklist：Set up text.verbosity」
• OpenAI「Reasoning models：Reasoning mode」
• OpenAI「Programmatic Tool Calling」