はじめに
GPT-5.5向けのプロンプト設計では、従来の考え方をそのまま流用しないことが重要です。
OpenAI公式の Prompt guidance では、GPT-5.5について、短く、成果物を先に定義するプロンプトのほうが、手順を細かく積み上げたプロンプトより有効な場合が多いと説明されています。特に、過去モデル向けのプロンプトをそのまま持ち込むと、ノイズが増えたり、モデルの探索範囲を狭めたり、機械的な回答につながる可能性があるとされています。(OpenAI Developers)
つまり、GPT-5.5ではプロンプトの考え方を次のように変える必要があります。
従来:
AIに作業手順を細かく命令する
GPT-5.5向け:
AIにゴール・成功条件・制約・成果物の形を伝える
この記事では、GPT-5.5本人とエンジニアの対話物語形式で、従来型プロンプトの悪い例と、GPT-5.5向けの良い書き方を説明します。
登場人物
GPT-5.5
新しいプロンプト設計に適したAI。
長すぎる手順プロンプトよりも、目的・成功条件・制約・成果物を明確に伝えてもらうほうが力を発揮しやすい。
エンジニア
これまでのモデル向けに作った長いプロンプトを、そのままGPT-5.5にも使っている。
最初は「細かく指示したほうがAIはうまく動く」と考えている。
第1話：GPT-5.5、長すぎるプロンプトに困る
エンジニア：
GPT-5.5、コードレビューをお願いします。プロンプトはかなり丁寧に作りました。
GPT-5.5：
見せてください。
エンジニア：
あなたは優秀なシニアエンジニアです。
まず差分を確認してください。
次に変更ファイルをすべて列挙してください。
次に各ファイルの変更内容を説明してください。
次に命名を確認してください。
次に責務分離を確認してください。
次にパフォーマンスを確認してください。
次にセキュリティを確認してください。
次にテスト観点を確認してください。
次に改善案を3つ出してください。
最後にまとめを書いてください。
必ずこの順番で実行してください。
必ずすべての観点を詳細に説明してください。
絶対に省略しないでください。
GPT-5.5：
これは、以前のモデル向けには有効だったかもしれません。
しかし、GPT-5.5向けとしては少し重すぎます。
エンジニア：
えっ。詳しく書いたほうがいいんじゃないんですか？
GPT-5.5：
詳しく書くこと自体は悪くありません。
問題は、目的よりも手順が目立っていることです。
エンジニア：
目的よりも手順？
GPT-5.5：
はい。私は、細かい作業順序よりも、次の情報をもらったほうが動きやすいです。
- 最終的にほしい成果物
- 成功条件
- 守るべき制約
- 判断してよい範囲
- どこで作業を止めるか
第2話：従来型プロンプトは「作業手順」を縛りすぎる
エンジニア：
でも、手順を細かく書かないと、AIが抜け漏れしそうで不安です。
GPT-5.5：
その考え方は自然です。
ただし、GPT-5.5では、すべての作業手順を固定するよりも、良い成果物の条件を伝えたほうがうまくいく場面が増えています。
OpenAI公式ガイドでも、GPT-5.5は、目標となる成果・成功条件・制約・利用可能な文脈を定義し、そのうえでモデルに解決経路を選ばせるとよい、と説明されています。(OpenAI Developers)
悪い例1：コードレビューの手順を細かく縛る
次のコード差分をレビューしてください。
手順:
1. 変更ファイルをすべて列挙する
2. 各ファイルの変更内容を説明する
3. 命名を確認する
4. 責務分離を確認する
5. パフォーマンスを確認する
6. セキュリティを確認する
7. テスト観点を確認する
8. 改善案を3つ出す
9. 最後にまとめる
必ずこの順番で実行してください。
必ずすべての項目を詳細に説明してください。
何が問題か
このプロンプトは、一見すると丁寧です。
しかし、問題は AIが「本当に重要な指摘」よりも「指定された手順を消化すること」を優先してしまう可能性がある ことです。
たとえば、差分が小さなUI文言修正だけだった場合でも、セキュリティやパフォーマンスについて長々と書いてしまうかもしれません。
逆に、設計上の重要な問題がある場合でも、チェックリスト消化に意識が寄りすぎて、重要なリスクの説明が薄くなる可能性があります。
良い例1：GPT-5.5向けに「成果物」を定義する
次のコード差分をレビューしてください。
目的:
本番投入前に、実装リスク・設計上の懸念・テスト不足を見つけること。
成功条件:
- 重大な不具合につながる可能性がある点を優先して指摘する
- 問題がない観点は無理に広げない
- 指摘には理由と修正方針を添える
- テストで確認すべき観点を最後に整理する
判断余地:
- レビュー観点の順番は、重要度に応じて最適化してよい
- 軽微な問題は短く扱ってよい
- 実害が小さい指摘は、重要な指摘と分けてよい
出力:
- 総評
- 重要な指摘
- 軽微な改善案
- テスト観点
エンジニア：
かなり短くなりましたね。
GPT-5.5：
はい。ただし、レビューとして必要な条件は明確になっています。
エンジニア：
「全部見る」ではなく、「重大な不具合につながる可能性がある点を優先する」と書いているのがポイントですね。
GPT-5.5：
その通りです。
GPT-5.5向けには、細かい作業手順よりも、成果物の品質基準を渡すほうが効果的です。
第3話：「必ず」「絶対に」を増やすほど良くなるわけではない
エンジニア：
では、「必ず」「絶対に」は使わないほうがいいんですか？
GPT-5.5：
使ってはいけないわけではありません。
ただし、本当に守るべきルールにだけ使うべきです。
エンジニア：
たとえば？
GPT-5.5：
次のようなものです。
- 個人情報を出さない
- 事実確認できない内容を断言しない
- 破壊的な操作は確認なしに実行しない
エンジニア：
なるほど。安全性や事実確認に関わるものは強く指定してよいんですね。
GPT-5.5：
はい。
一方で、次のような使い方は注意が必要です。
悪い例2：「必ず」を乱用する
必ず最初に質問してください。
必ず3案出してください。
必ず詳しく説明してください。
必ず表にしてください。
必ず最後にまとめを書いてください。
必ず改善案を5つ出してください。
何が問題か
このプロンプトでは、AIが状況に合わせて判断しにくくなります。
たとえば、ユーザーがすでに十分な情報を渡しているのに、AIが「必ず最初に質問してください」という指示に従うと、不要な確認が発生します。
また、改善案が2つで十分な場合でも、無理に5つ出そうとして、質の低い案が混ざる可能性があります。
良い例2：「判断基準」として書く
不足情報によって結論が大きく変わる場合のみ、最初に質問してください。
それ以外は、合理的な前提を置いて回答してください。
改善案は、実用性があるものだけ出してください。
数を増やすための案は不要です。
前提を置いた場合は、最後に「置いた前提」として簡潔に書いてください。
エンジニア：
「必ず質問」ではなく、「必要な場合のみ質問」にするんですね。
GPT-5.5：
はい。
GPT-5.5には、絶対命令を増やすよりも、判断ルールを渡すほうが自然です。
第4話：GPT-5.5には「どこで止まるか」も伝える
エンジニア：
AIに調査を頼むと、情報が多すぎることがあります。
GPT-5.5：
それは、停止条件がないからです。
エンジニア：
停止条件？
GPT-5.5：
「どの状態になったら作業完了か」という条件です。
OpenAI公式ガイドでも、複雑なプロンプトの構成要素として、Stop rules、つまり、いつ再試行し、いつ質問し、いつ止めるかを書く考え方が示されています。(OpenAI Developers)
悪い例3：調査範囲を広げすぎる
このAPI仕様について詳しく調べて説明してください。
関連情報もできるだけ多く含めてください。
何が問題か
このプロンプトだと、AIはどこまで調べれば十分なのか判断しにくくなります。
結果として、次のような回答になりがちです。
- 背景説明が長い
- 結論が遅い
- 実装に必要ない情報まで含まれる
- 重要な判断ポイントが埋もれる
良い例3：完了条件を明確にする
このAPI仕様を、実装判断に必要な範囲で整理してください。
目的:
既存のiOSアプリに組み込むべきか判断できる状態にすること。
成功条件:
- 実装に必要なパラメータがわかる
- エラーハンドリングの注意点がわかる
- 既存実装への影響がわかる
- 不明点は不明点として分ける
停止条件:
- 実装判断に必要な情報がそろったら、それ以上は背景説明を広げない
- 仕様が確認できない点は推測で埋めず、不明点として列挙する
出力:
- 結論
- 実装に必要な情報
- 注意点
- 不明点
- 次に確認すべきこと
エンジニア：
これなら、AIが「実装判断に必要な範囲」で止まれますね。
GPT-5.5：
はい。
GPT-5.5には、作業量ではなく、完了条件を渡すのが重要です。
第5話：出力形式は明確にする。ただし重くしすぎない
エンジニア：
出力形式は細かく指定してもいいんですか？
GPT-5.5：
はい。出力形式は明確にしたほうがよいです。
OpenAI公式ガイドでも、複雑なプロンプトでは、出力のセクション、長さ、トーンを指定する構造が示されています。(OpenAI Developers)
エンジニア：
では、毎回JSONにしたほうがいいですか？
GPT-5.5：
いいえ。
JSONが必要なのは、システム連携や機械処理を前提にする場合です。
人間が読むだけなら、Markdownや箇条書きのほうが使いやすいこともあります。
悪い例4：不要に重いフォーマットを強制する
以下の不具合について分析してください。
必ずJSONで出力してください。
必ず以下のキーをすべて含めてください。
{
"summary": "",
"background": "",
"cause_1": "",
"cause_2": "",
"cause_3": "",
"impact": "",
"risk": "",
"solution_1": "",
"solution_2": "",
"solution_3": "",
"test_case_1": "",
"test_case_2": "",
"test_case_3": "",
"conclusion": ""
}
何が問題か
システム連携が目的なら、JSON指定は有効です。
しかし、単に不具合原因を理解したいだけなら、構造が重すぎます。
AIは空欄を埋めるために、重要でない情報まで作ろうとする可能性があります。
良い例4：目的に合う出力形式だけ指定する
以下の不具合について、原因調査の初動に使える形で整理してください。
目的:
原因の当たりをつけ、次に確認すべきログ・コード箇所を明確にすること。
出力:
- 現象
- 可能性が高い原因
- 確認すべきログ・コード箇所
- 暫定対応
- 恒久対応
- 追加で必要な情報
制約:
- 根拠がない原因は断定しない
- 可能性が低い原因は優先度を下げる
- すぐ確認できる順に並べる
エンジニア：
実務でそのまま使いやすいですね。
GPT-5.5：
プロンプトは、AIを縛るためではありません。
成果物の品質を安定させるために書くものです。
第6話：GPT-5.5向けプロンプトの基本形
エンジニア：
では、GPT-5.5向けには、どういう型で書けばいいですか？
GPT-5.5：
まずは、この型で十分です。
目的:
何を達成したいか
成功条件:
どんな状態なら良い回答か
制約:
守るべきルール、避けるべきこと
判断余地:
AIに任せてよい範囲
出力:
最終的にほしい形
停止条件:
どこまでやったら終わりか
エンジニア：
「判断余地」があるのが、従来と違いますね。
GPT-5.5：
そこが重要です。
GPT-5.5では、AIに全部の手順を渡すのではなく、AIが効率的な解決ルートを選べる余白を残します。
実務で使えるGPT-5.5向けテンプレート
以下のタスクを実行してください。
目的:
{最終的に達成したいこと}
成功条件:
- {満たすべき条件1}
- {満たすべき条件2}
- {満たすべき条件3}
制約:
- 事実確認できない内容は断言しない
- 推測する場合は「推測です」と明記する
- 不明点は不明点として分ける
- 不要な背景説明は増やさない
判断余地:
- 目的達成に必要な範囲で、構成や説明順序は最適化してよい
- 重要度が低い観点は短く扱ってよい
- 不足情報があっても結論に大きく影響しない場合は、合理的な前提を置いて進めてよい
出力:
- 結論
- 重要ポイント
- 具体例
- 注意点
- 次にやること
停止条件:
- 目的を満たす十分な情報がそろったら、それ以上話を広げない
- 追加情報がないと判断が大きく変わる場合のみ、最後に質問する
従来プロンプトとGPT-5.5向けプロンプトの違い
| 観点 | 従来プロンプト | GPT-5.5向けプロンプト |
|---|---|---|
| 基本思想 | 手順を細かく指定する | 成果物と成功条件を指定する |
| 指示の長さ | 長くなりがち | 短く、要点中心 |
| AIの役割 | 指示通りに作業する実行者 | 目的達成のために判断する協力者 |
| 書き方 | 「まずA、次にB、最後にC」 | 「こういう成果物にして」 |
| リスク | 機械的、冗長、柔軟性が低い | 目的に合わせて最適化しやすい |
| 向いている場面 | 厳密な手順が必要な作業 | 調査、レビュー、設計、文章作成、分析 |
ただし、長いプロンプトがすべて悪いわけではない
ここで誤解してはいけないのは、長いプロンプトが常に悪いわけではないということです。
たとえば、次のような場面では、詳細な指示が必要です。
- 厳密な出力スキーマが必要な場合
- 法務・医療・金融など、誤りの影響が大きい場合
- 社内ルールや業務フローを正確に反映する必要がある場合
- ツール実行や外部API操作のルールを明確にする必要がある場合
- 評価基準や禁止事項を明示する必要がある場合
重要なのは、長く書くこと自体ではなく、不要な手順指定を減らすことです。
GPT-5.5向けには、次の考え方が有効です。
不要な手順は削る。
必要な制約は残す。
成果物の条件は明確にする。
AIが判断してよい範囲を渡す。
まとめ
GPT-5.5では、プロンプト設計の考え方を変える必要があります。
従来のように、
まずこれをして
次にこれをして
必ずこの順番で
すべて詳しく
絶対に省略せずに
と書くよりも、
目的は何か
成功条件は何か
守るべき制約は何か
どんな成果物がほしいか
どこで止まればよいか
どこまでAIに判断を任せるか
を明確にするほうが、GPT-5.5の特性に合っています。
GPT-5.5は、今までのモデルと同じ感覚で「長く細かく命令すればよい」モデルではありません。
これからのプロンプト設計では、AIを細かく縛るのではなく、
ゴールを渡し、成功条件を示し、判断余地を残す
ことが重要になります。
参考
OpenAI公式の Prompt guidance では、GPT-5.5について、短く成果物重視のプロンプトが有効であり、古いプロンプトスタックをそのまま持ち込むべきではないと説明されています。(OpenAI Developers)