OpenAI、GPT-5.6のプロンプトガイドラインを公開。内部テストでは、冗長なsystem promptを簡潔にしたところ、スコアは下がるどころか10%〜15%上昇し、さらにトークン使用量も41%〜66%節約できたという。ガイドラインでは、開発者はモデルに提示するのは「モデル結果」「制約」「停止基準」だけにし、毎ステップどう進めるかを規定する必要はないと提案している。 （前情提要：GPT-5.6の秘密テストが拡散中：ChatGPTが突然賢くなり、ユーザーテストでFable 5を圧倒） （背景補足：Harness Engineering（AI駕馭工学）入門編：OpenAI最新のプログラミング基準。気軽にLv.1を達成する方法）
この記事の目次
Toggle
OpenAIの内部テストによると、もともと長々としていたsystem promptを大幅に簡潔化した後、スコアは落ちるどころか、10%〜15%上昇した。加えて、トークン使用量も41%〜66%節約できた。言い換えると、モデルに「準備動作を少し減らせ」と頼むほど、むしろより速く動き、答えもより正確になる。
これはOpenAI公式が公開したGPT-5.6のプロンプトガイドラインで説明されている要点で、以下では筆者が3つのポイントに整理する。なぜ指示を簡潔にするほど効果があるのか、OpenAIが推奨する新しい書き方は何か、そして開発者は実際にどう変えるべきか。
これまでエンジニアがプロンプトを書くときの直感は「細かく説明するほど、モデルは言うことを聞く」というものだった。各ステップ、各例外状況をすべて書き込み、モデルが何かを漏らさないか恐れていた。しかしOpenAIはガイドラインで、この直感がGPT-5.6では機能しないと明言している。開発チームの実測では、system promptとは端的に言えば、ユーザとの対話が始まる前に開発者がモデルに先回りして埋め込む隠し設定指示のこと。そこに、繰り返しのルール、行動に実質的な影響がないのに多いだけの“スタイルの念押し”、不要な例、そしてモデルが元々できるプロセスの指導まで詰め込んでしまうと、取り除いた後の方がモデルのパフォーマンスがむしろ良くなるという。
ガイドラインが示す具体的な方法は「動くバージョンから段階的に削る」だ。まず、現在有効なプロンプトを残したまま、疑わしい部分を一つずつ削除しながら、eval（AIの定量評価スコア）を注視する。簡単に言えば、固定の一連のタスクでモデルを走らせ、点数で回答の良し悪しや落ち込みの有無を測るということだ。
本当に残すべきなのは、ユーザに見える結果、成功と停止の判断基準、安全面および商業面での制限、状況に応じたツール選定ルール、そして要求される出力形式である。それ以外の多くは、エンジニアが安心のために書いているだけの冗長な文言だ。
ガイドラインは同時に、見落とされがちな要素も指摘している。ツールの説明自体もプロンプトの一部だという点だ。モデルに与えるツールが多く、説明が曖昧であるほど、モデルが「どのツールを使うべきか」を判断するコストが高くなる。OpenAIは、タスクに関連するツールだけを与え、各ツールの説明には「何をするのか」「いつ使うべきか」「失敗したらどう振る舞うか」を明確に書くよう推奨している。言い換えると、簡潔化は単に「指示」だけでなく、「ツールボックスそのもの」も一緒にスリム化すべきだということだ。
ガイドラインで最も核心的な一文は、「結果、重要な制限、利用可能な根拠、完了基準を定義し、その上で、モデルが自分で効率的な経路を選べる余白を残す」だ。要するに、モデルには“どこへ行くか”と“何を踏んではいけないか”という赤線だけを伝え、毎ステップどう動くかは指示しない。
OpenAIが挙げる例は、「最小限の有用なツールのループでリクエストを解決する。ただし、ループ回数を減らすことによって正確性、必要な根拠、引用を犠牲にしてはいけない」というもの。これは「もしXならY」という意思決定ルールであって、「絶対にこう命令せよ」という固定命令ではない。
もう一つ見落とされやすい細部は、GPT-5.6のデフォルト回答は比較的簡潔だという点だ。以前はエンジニアがプロンプトに「簡潔に答えて」などの念押しを書いていたが、今はそれが不要どころか有害になる可能性がある。ガイドラインでは、引数text.verbosityを使って変更することを推奨している。簡単に言えば、回答の長さをコントロールするための“長さ専用の引数”を単独で用意し、語調は別途分けて扱い、low・medium・highの3段階で長さを専門管理する。語調やフォーマルさの個性は別で記述し、いずれも短く書くということだ。
本当にもっと短い答えが必要なら、ガイドラインは「何を残し、何を削るか」を明確に書けと提案し、「短くして」とだけ曖昧に投げるな、としている。さらに、モデルがどれだけ思考に力を使うか、つまりreasoning effortについては、low・medium・high・xhigh・maxの5段階に分ける。引き上げる前にOpenAIは、まずプロンプト自体に成功基準と検証のためのループがきちんと書かれているかを確認すべきだと述べている。多くの場合、「話をはっきりさせる」方が「考えるようにもっと指示を足す」よりも効果的だからだ。
開発者にとっていちばん実際的な影響は、ガイドラインに付随する一連のプロンプト移行ワークフローだ。
OpenAIは非常に率直にこう言っている。モデルを入れ替えるとき、プロンプト一式を書き直すのは一度にやるな。理由は、モデル変更・推論設定・プロンプト・ツールセットを同時に変えてしまうと、どの変更が挙動の差を生んだのか後から判別できなくなるからだ。正しい順序は、まずモデルを切り替え、元の推論強度設定は維持したまま代表的なevalを1回走らせて基準を作る。次に、時代遅れの足場（鷹架）や重複した指示を外し、「evalで本当に退歩が見えた」箇所にだけ最小限の修正を加える。そして再度測定する。1つ変因を変えるたびに毎回計測し、同時にあれこれ動かしてはいけない。
ガイドラインはまた、開発者が「モデルが自分で決められる範囲」を曖昧にせず書き切ることも求めている。OpenAIが提示する例のポリシーはこうだ。回答、説明、確認（検視）といった依頼では、モデルは確認して報告するだけで、実際に手を動かして変更してはならない。変更や修復が絡む依頼では、範囲内でローカルの変更を行い、非破壊的な検証を回すことは可能。だが、対外的な書き込み、破壊的な操作、あるいはタスク範囲の拡大を伴う場合は、必ずいったん止めて問い合わせるべきだ。
指令が増えるほど、ときには安心するものだった。だが、今の見方ではそれがモデルを遅くし、ひいては請求額にも響く可能性がある。モデルが賢くなるほど、人間側はむしろ少し話すことを学び、力を計測と検証に振り向けるべきだ。
1.14M 人気度
227.04K 人気度
72.05K 人気度
3.93M 人気度
1.82M 人気度
OpenAI が GPT-5.6 のプロンプト指針を公開：「結果とレッドラインだけを出し、それ以外はモデルに任せる」
OpenAI、GPT-5.6のプロンプトガイドラインを公開。内部テストでは、冗長なsystem promptを簡潔にしたところ、スコアは下がるどころか10%〜15%上昇し、さらにトークン使用量も41%〜66%節約できたという。ガイドラインでは、開発者はモデルに提示するのは「モデル結果」「制約」「停止基準」だけにし、毎ステップどう進めるかを規定する必要はないと提案している。
（前情提要：GPT-5.6の秘密テストが拡散中：ChatGPTが突然賢くなり、ユーザーテストでFable 5を圧倒）
（背景補足：Harness Engineering（AI駕馭工学）入門編：OpenAI最新のプログラミング基準。気軽にLv.1を達成する方法）
この記事の目次
Toggle
OpenAIの内部テストによると、もともと長々としていたsystem promptを大幅に簡潔化した後、スコアは落ちるどころか、10%〜15%上昇した。加えて、トークン使用量も41%〜66%節約できた。言い換えると、モデルに「準備動作を少し減らせ」と頼むほど、むしろより速く動き、答えもより正確になる。
これはOpenAI公式が公開したGPT-5.6のプロンプトガイドラインで説明されている要点で、以下では筆者が3つのポイントに整理する。なぜ指示を簡潔にするほど効果があるのか、OpenAIが推奨する新しい書き方は何か、そして開発者は実際にどう変えるべきか。
指示は少ないほど、モデルは正確？
これまでエンジニアがプロンプトを書くときの直感は「細かく説明するほど、モデルは言うことを聞く」というものだった。各ステップ、各例外状況をすべて書き込み、モデルが何かを漏らさないか恐れていた。しかしOpenAIはガイドラインで、この直感がGPT-5.6では機能しないと明言している。開発チームの実測では、system promptとは端的に言えば、ユーザとの対話が始まる前に開発者がモデルに先回りして埋め込む隠し設定指示のこと。そこに、繰り返しのルール、行動に実質的な影響がないのに多いだけの“スタイルの念押し”、不要な例、そしてモデルが元々できるプロセスの指導まで詰め込んでしまうと、取り除いた後の方がモデルのパフォーマンスがむしろ良くなるという。
ガイドラインが示す具体的な方法は「動くバージョンから段階的に削る」だ。まず、現在有効なプロンプトを残したまま、疑わしい部分を一つずつ削除しながら、eval（AIの定量評価スコア）を注視する。簡単に言えば、固定の一連のタスクでモデルを走らせ、点数で回答の良し悪しや落ち込みの有無を測るということだ。
本当に残すべきなのは、ユーザに見える結果、成功と停止の判断基準、安全面および商業面での制限、状況に応じたツール選定ルール、そして要求される出力形式である。それ以外の多くは、エンジニアが安心のために書いているだけの冗長な文言だ。
ガイドラインは同時に、見落とされがちな要素も指摘している。ツールの説明自体もプロンプトの一部だという点だ。モデルに与えるツールが多く、説明が曖昧であるほど、モデルが「どのツールを使うべきか」を判断するコストが高くなる。OpenAIは、タスクに関連するツールだけを与え、各ツールの説明には「何をするのか」「いつ使うべきか」「失敗したらどう振る舞うか」を明確に書くよう推奨している。言い換えると、簡潔化は単に「指示」だけでなく、「ツールボックスそのもの」も一緒にスリム化すべきだということだ。
もう手順を書かず、「終点」を書くだけ
ガイドラインで最も核心的な一文は、「結果、重要な制限、利用可能な根拠、完了基準を定義し、その上で、モデルが自分で効率的な経路を選べる余白を残す」だ。要するに、モデルには“どこへ行くか”と“何を踏んではいけないか”という赤線だけを伝え、毎ステップどう動くかは指示しない。
OpenAIが挙げる例は、「最小限の有用なツールのループでリクエストを解決する。ただし、ループ回数を減らすことによって正確性、必要な根拠、引用を犠牲にしてはいけない」というもの。これは「もしXならY」という意思決定ルールであって、「絶対にこう命令せよ」という固定命令ではない。
もう一つ見落とされやすい細部は、GPT-5.6のデフォルト回答は比較的簡潔だという点だ。以前はエンジニアがプロンプトに「簡潔に答えて」などの念押しを書いていたが、今はそれが不要どころか有害になる可能性がある。ガイドラインでは、引数text.verbosityを使って変更することを推奨している。簡単に言えば、回答の長さをコントロールするための“長さ専用の引数”を単独で用意し、語調は別途分けて扱い、low・medium・highの3段階で長さを専門管理する。語調やフォーマルさの個性は別で記述し、いずれも短く書くということだ。
本当にもっと短い答えが必要なら、ガイドラインは「何を残し、何を削るか」を明確に書けと提案し、「短くして」とだけ曖昧に投げるな、としている。さらに、モデルがどれだけ思考に力を使うか、つまりreasoning effortについては、low・medium・high・xhigh・maxの5段階に分ける。引き上げる前にOpenAIは、まずプロンプト自体に成功基準と検証のためのループがきちんと書かれているかを確認すべきだと述べている。多くの場合、「話をはっきりさせる」方が「考えるようにもっと指示を足す」よりも効果的だからだ。
「指令を積む」から「計測にもとづく調整」へ
開発者にとっていちばん実際的な影響は、ガイドラインに付随する一連のプロンプト移行ワークフローだ。
OpenAIは非常に率直にこう言っている。モデルを入れ替えるとき、プロンプト一式を書き直すのは一度にやるな。理由は、モデル変更・推論設定・プロンプト・ツールセットを同時に変えてしまうと、どの変更が挙動の差を生んだのか後から判別できなくなるからだ。正しい順序は、まずモデルを切り替え、元の推論強度設定は維持したまま代表的なevalを1回走らせて基準を作る。次に、時代遅れの足場（鷹架）や重複した指示を外し、「evalで本当に退歩が見えた」箇所にだけ最小限の修正を加える。そして再度測定する。1つ変因を変えるたびに毎回計測し、同時にあれこれ動かしてはいけない。
ガイドラインはまた、開発者が「モデルが自分で決められる範囲」を曖昧にせず書き切ることも求めている。OpenAIが提示する例のポリシーはこうだ。回答、説明、確認（検視）といった依頼では、モデルは確認して報告するだけで、実際に手を動かして変更してはならない。変更や修復が絡む依頼では、範囲内でローカルの変更を行い、非破壊的な検証を回すことは可能。だが、対外的な書き込み、破壊的な操作、あるいはタスク範囲の拡大を伴う場合は、必ずいったん止めて問い合わせるべきだ。
指令が増えるほど、ときには安心するものだった。だが、今の見方ではそれがモデルを遅くし、ひいては請求額にも響く可能性がある。モデルが賢くなるほど、人間側はむしろ少し話すことを学び、力を計測と検証に振り向けるべきだ。