GPT-5.5 Prompt 移行ガイド：古いプロンプトはまず削ってから直す

Fri, 15 May 2026 01:25:27 +0800

OpenAI は API ドキュメントで GPT-5.5 prompting guide を更新しました。このガイドで最も価値があるのは、さらに長いプロンプトテンプレートを示していることではありません。GPT-5.5 へ移行するとき、多くの古い prompt はむしろ短くすべきだ、と示している点です。

公式ドキュメント：https://developers.openai.com/api/docs/guides/prompt-guidance

一言でいうと、GPT-5.5 の prompting の方向性は次の通りです。プロセスを減らし、結果を書く。ルールを積み上げるより、受け入れ条件を定義する。always や must を乱用せず、いつ止めるか、いつ検証するか、いつ証拠を補うかを書く。

古い prompt をなぜ書き直す必要があるのか

多くの本番システムの prompt は、層を重ねるように作られています。モデルが不安定ならルールを 1 つ足す。ツール呼び出しで失敗したら禁止事項を足す。出力が長すぎたらフォーマット指定を足す。時間が経つと、system prompt は重い運用マニュアルになります。

この書き方は古いモデルでは役に立つこともありました。モデルが逸れないように、より細かい手順制約が必要だったからです。しかし GPT-5.5 では、OpenAI の推奨は明確です。古い prompt stack をそのまま持ち込まないことです。

プロセスを指定しすぎると、いくつかの副作用があります。

ノイズが増え、モデルが大量の古いルールから本当に重要な制約を探す必要がある。
探索空間が狭くなり、モデルがより効率的な解法を選びにくくなる。
出力が機械的になり、問題解決というよりスクリプト実行のように見える。
古いルール同士が衝突し、ツール呼び出しも最終回答も悪くなる。

GPT-5.5 には、各手順を固定するより、目標状態、制約、利用可能な証拠、最終出力を説明する prompt のほうが向いています。

outcome-first：まず完了条件を定義する

公式ドキュメントは、GPT-5.5 には outcome-first prompt が向いていると繰り返し強調しています。

つまり、prompt ではまず次を明確にすべきです。

目標とする結果は何か。
何をもって成功とするか。
どの制約を破ってはいけないか。
現在利用できるコンテキストは何か。
最終回答にどのフィールドやセクションが必要か。
証拠が不足しているときにどうするか。

あまり推奨されない書き方：

まず A を確認し、次に B を確認し、その後すべてのフィールドを比較し、すべての例外を考え、どのツールを呼ぶか決め、ツールを呼び、最後に完全な過程を説明する。

GPT-5.5 により向いた書き方：

ユーザーの問題を解決する。成功条件：
- 利用可能なポリシーとアカウントデータに基づいて判断する
- 操作が許可される場合は、返信前に操作を完了する
- 最終出力には completed_actions、customer_message、blockers を含める
- 重要な証拠が不足している場合は、最小限必要なフィールドだけ質問する

これは prompt を曖昧にすることではありません。制御点を「手順の順番」から「結果と境界」へ移すことです。モデルは検索、推論、ツール呼び出しの経路を自分で選べますが、成功条件には責任を持つ必要があります。

絶対ルールを減らし、判断ルールを書く

古い prompt では ALWAYS、NEVER、must、only が大量に出てきがちです。これらの言葉は使ってはいけないわけではありません。ただし、安全ルール、必須フィールド、禁止アクションのように、本当に破れない制約にだけ残すべきです。

「いつ検索するか」「いつユーザーに聞くか」「いつ続けるか」「いつ止めるか」のような判断には、GPT-5.5 では decision rule のほうが向いています。

たとえば、こう書くだけでは不十分です。

`1`	`常に最初に 3 回検索する。`

こう書くほうがよいです。

まず中核問題をカバーする検索を 1 回行う。最初の数件の結果で重要事実を支えられるなら、検索を止めて回答する。証拠が矛盾している、不足している、または結論を支えられない場合だけ、検索を続ける。

この書き方はモデルに判断余地を与え、同時に停止条件も与えます。Web 検索、retrieval、ファイル検索、データベース問い合わせを使うプロダクトでは重要です。ツール呼び出しが 1 回増えるたびに、遅延とコストが増えるからです。

retrieval budget を設定する

GPT-5.5 prompt に単独で追加する価値があるルールの 1 つが retrieval budget です。

これは金額の予算ではありません。検索をいつ止めるかのルールです。証拠がいつ十分なのか、いつ探し続けるべきか、いつ証拠不足を認めるべきかをモデルに伝えます。

実用的な書き方：

通常の Q&A では、短く識別しやすいキーワードでまず広めに 1 回検索する。最初の数件の結果が中核リクエストを支えられるなら、その結果に基づいて回答し、検索を続けない。結果が矛盾する、重要事実が欠けている、または結論を支えられない場合のみ追加検索する。

このルールは、よくある 2 つの問題を減らします。

検索不足で、証拠のない回答を出す。
検索しすぎて、ツールループで時間を浪費する。

さらに重要なのは、証拠が見つからないことを、事実上の「いいえ」として扱うべきではないという点です。正しい挙動は、証拠不足を明示すること、またはより小さい問いに分けて確認することかもしれません。

reasoning effort を最初から上げない

GPT-5.5 は推論効率が高いため、OpenAI は low と medium を再評価することを勧めています。品質が足りないと感じたときに、すぐ reasoning effort を上げるべきではありません。

より安定した順序は次の通りです。

まず prompt が目標、出力形式、停止条件を明確にしているか確認する。
テスト、引用、レビュー、レンダリング確認などの検証ループを追加する。
ツール呼び出しに持続性ルールと完了基準を追加する。
それでも足りない場合に reasoning effort を上げる。

言い換えると、reasoning.effort は最後の調整つまみに近いものです。明確な prompt 設計の代わりにすべきではありません。

短い分類、フィールド抽出、サポートチケット振り分け、形式変換なら、低い推論コストから始められます。長文書の統合、複数ソースの衝突判断、戦略作成、複雑な調査では、medium 以上を検討します。

text.verbosity は出力を制御するが、思考を制御するわけではない

GPT-5.5 は出力形式をかなり制御できます。公式ドキュメントは、prompt 内の出力要件と合わせて text.verbosity を使うことを勧めています。

デフォルトの text.verbosity は medium です。より短く、よりすっきりした返信が必要なプロダクトでは low を使えます。ただし、すべてを短くすべきという意味ではありません。

典型的な使い方：

ユーザー向けの状態更新と最終要約は短くする。
コード、設定、構造化結果では、引き続き可読性を求める。
「短くする」ために、フィールドの完全性、引用、必要な caveat を犠牲にしない。

これはコード系プロダクトで特に有用です。チャット返信は短くしつつ、生成コードには読みやすい変数名、明確な構造、必要なコメントを求められます。

preamble と phase：長いタスクを見えるようにする

GPT-5.5 は複雑なタスクで、可視テキストを出す前に推論、計画、ツール呼び出し準備を行うことがあります。ストリーミングプロダクトでは、ユーザーは最初の token までの待ち時間を感じます。

公式の推奨は、多段階、ツール密集、長時間実行のタスクでは、モデルに短い preamble を先に出させることです。完全な計画を説明する必要はありません。「まず何をするか」だけを伝えれば十分です。

例：

`1`	`まず関連ファイルと既存設定を確認し、その後で変更案を出します。`

Responses API の長いタスクやツール密集ワークフローでは、assistant item の phase にも注意が必要です。アプリが previous_response_id を使う場合、API は前の assistant 状態を自動で保持します。アプリが assistant 出力を手動で再生する場合、元の phase 値を保持する必要があります。

一般的な約束：

phase: "commentary"：中間状態の更新。
phase: "final_answer"：最終回答。
user message には phase を付けない。

これは低レベル実装の細部に見えますが、ツール呼び出し、状態更新、最終回答を持つプロダクトでは重要です。手動再生時に phase を失うと、モデルが途中経過と最終結論を混同しやすくなります。

モデルに自分の作業を検証させる

GPT-5.5 guide には非常に実用的な点があります。検証可能なタスクでは、モデルに検証ツールと検証ルールを与えることです。

コード Agent には、明確に次を要求できます。

変更後に関連する単体テストを実行する。
必要なら type check や lint を実行する。
影響するパッケージが大きい場合は build を実行する。
全量検証が高コストなら、少なくとも最小の smoke test を行う。
検証できない場合は、理由と次善の確認方法を説明する。

視覚やページ成果物では、まずレンダリングし、レイアウト、切り抜き、余白、欠落内容、視覚的一貫性を確認するよう求められます。

エンジニアリング計画では、要件との対応、関連ファイル/API/システム、状態遷移、検証コマンド、失敗時の挙動、プライバシーとセキュリティ、実装に影響する未決事項を含めるよう求められます。

この種のルールは「もっと注意して」よりずっと効果的です。「注意」を実行可能なチェックに変えるからです。

GPT-5.5 に向いた prompt 骨格

OpenAI ドキュメントの構造は、簡略化すると次のようになります。

Role:
あなたの役割と、作業する文脈。

# Personality
口調、協力スタイル、温度感や視点が必要かどうか。

# Goal
ユーザーに見える目標結果。

# Success criteria
最終回答前に満たすべき条件。

# Constraints
安全、ビジネス、証拠、権限、コスト、副作用の境界。

# Output
出力構造、長さ、口調、必須フィールド。

# Stop rules
いつ続けるか、再試行するか、降格するか、質問するか、停止するか。

この骨格のポイントは、すべての prompt が同じ見出しを持つべきということではありません。複雑なタスクの prompt は、モデルに目的地、境界、成果物を伝えるべきであり、すべての手順をハードコードすべきではないということです。

古い prompt を移行する実際の順序

GPT-4.1、GPT-4o、GPT-5.2、GPT-5.4 向けの古い prompt がある場合、一度に大きく変えるのはおすすめしません。

より安定した移行順序：

まずモデルだけ切り替え、現在の reasoning effort と出力パラメータを固定する。
既存 eval または実例を実行し、挙動の変化を見つける。
明らかに古い、重複する、衝突するプロセスルールを削除する。
「手順要求」を「成功基準」と「停止条件」に変える。
retrieval budget、引用ルール、証拠不足時の挙動を追加する。
ツールタスクに検証ループを追加する。
最後に reasoning.effort と text.verbosity を調整する。

eval がない場合でも、少なくとも代表的なタスクを用意します。簡単な Q&A、複雑な検索、ツール呼び出し、フォーマット出力、拒否/降格、長いタスクの完了です。1 つの demo case だけで prompt の良し悪しを判断しないことです。

古い prompt 移行チェックリスト

実際に移行するときは、まずこのチェックリストを通します。目的は単に prompt を短くすることではなく、無効な制約を削除し、重要な制約を検証可能な形にすることです。

チェック項目	よくある問題	推奨対応
重複ルール	同じ指示が複数箇所にあり、表現が一致しないこともある	1 つの明確なルールに統合し、最終版だけ残す
絶対語	`ALWAYS`、`NEVER`、`must`、`only` が everywhere	安全、コンプライアンス、権限、必須フィールドにだけ残す
停止条件なし	検索、分析、修正を続けるよう要求するが、いつ止めるかがない	証拠十分、検証成功、ターン数やコスト上限など stop rules を追加
検証コマンドなし	「正しくする」と書くだけで、テスト、lint、引用、確認方法がない	テスト、型チェック、build、引用、smoke test など具体化
プロセスが細かすぎる	すべての手順を固定し、モデルがよりよい経路を選べない	目標、成功基準、境界、出力要件に書き換える
古いモデル用補丁	古いモデルの弱点向け制限が残っている	まず削除し、eval で本当に必要か判断する
ツールルールが曖昧	「必要ならツールを使う」だけ	いつ呼ぶか、いつ止めるか、失敗時にどう降格するかを書く
出力形式が漂う	形式指定はあるが、フィールド完全性のルールがない	必須フィールド、任意フィールド、証拠不足時の出力を定義

1 つだけやるなら、「停止条件なし」と「検証コマンドなし」を優先します。この 2 つは、GPT-5.5 を無限ツールループにしたり、証拠なしで整った回答を出させたりしやすいからです。

GPT-5.5 prompt 例：旧 vs 新

以下は完全な system prompt ではなく、移行時によくある部分的な書き換えです。

例 1：検索 Q&A

旧：

`1`	`回答前に必ず 3 回以上検索する。関連するすべての結果を読む。完全な説明を出す。`

新：

まず中核問題をカバーする検索を 1 回行う。最初の数件の結果で重要事実を支えられるなら、検索を止めて回答する。結果が矛盾する、または重要事実が不足している場合は追加検索する。最終回答では根拠を説明し、証拠不足なら明確にそう述べる。

新しい書き方では、「検索回数」を「証拠が十分か」に変えています。モデルに続ける理由と止める理由の両方を与えます。

例 2：コード変更

旧：

`1`	`慎重にコードを修正する。既存ロジックを壊さない。完了後に変更点を教える。`

新：

ユーザー要求に対する最小限必要なコード変更を行う。成功基準：
- タスクに関係するファイルだけを変更する
- ユーザーが明示しない限り、既存の公開 API 互換性を保つ
- 変更後に関連単体テストを実行する。実行できない場合は理由と次善の検証方法を説明する
- 最終要約には変更点、検証結果、残るリスクを含める

新しい書き方は、ただ「慎重に」と言うのではなく、ファイル範囲、API 互換性、テストコマンド、リスク説明に慎重さを落とし込んでいます。

例 3：構造化出力

旧：

`1`	`JSON を出力する。余計な内容は出さない。フィールドは完全にする。`

新：

Markdown なしの厳密な JSON を出力する。必須フィールド：
- status: "ok" | "needs_more_info" | "blocked"
- answer: string
- evidence: string[]
- missing_info: string[]
証拠が不足している場合、status は "needs_more_info" にし、evidence を捏造しない。

新しい書き方は JSON を求めるだけでなく、証拠不足時の合法的な出力経路も定義しています。モデルは「完全なフィールド」と「証拠不足」の間で情報を作る必要がなくなります。

パラメータの組み合わせ

reasoning.effort と text.verbosity は別々に考えるべきではありません。前者はモデルがどれだけ推論するか、後者は出力の詳しさを左右します。よくある誤解は、品質が足りなければ reasoning.effort を上げ、出力が長ければ prompt を強く書くことです。より安定するのは、タスク種別で組み合わせることです。

場面	reasoning.effort	text.verbosity	説明
フィールド抽出、分類、短い形式変換	`none` または `low`	`low`	低遅延を重視し、schema を明確にする
サポート振り分け、簡単なツールルーティング	`low`	`low` または `medium`	ルールが明確なら高推論は不要
通常 Q&A、軽い検索要約	`low` または `medium`	`medium`	判断は必要だが、高推論をデフォルトにしない
複数文書統合、衝突判断	`medium`	`medium`	まず証拠ルールと引用を整え、その後 effort を検討
複雑なコード変更、長い Agent タスク	`medium` または `high`	ユーザー返信は `low`、コード出力は明確に	チャット更新は短く、コードと diff は可読に
戦略、計画、リスク分析	`medium` または `high`	`medium` または `high`	トレードオフ、リスク、仮定の説明が必要

多くのアプリでは、まず low または medium から始めます。prompt が成功基準、停止条件、検証ルールをすでに明確にしていて、それでも重要制約を落とす場合にだけ、reasoning.effort を上げます。

text.verbosity も低ければよいわけではありません。低 verbosity は状態更新、短いサポート返信、操作結果要約に向いています。一方、コード、設定、移行計画、監査説明では、短すぎる出力はレビューしづらくなります。

残すべきルール

GPT-5.5 へ移行することは、古い prompt をすべて削ることではありません。次のルールは通常残すべきであり、より明確に書くべきです。

安全ルール：実行できないアクション、生成できない内容、拒否または降格すべき場面。
コンプライアンスルール：業界ポリシー、地域制限、年齢制限、監査要件、承認要件。
プライバシールール：個人情報処理、機密データのマスキング、ログ制限、データ外部送信の制限。
出力フィールド：API 応答、JSON schema、表フィールド、フロントエンドコンポーネントが必要とする固定構造。
業務境界：返金ルール、アカウント権限、サービスレベル、契約範囲、有人サポートへのエスカレーション条件。
ツール権限境界：呼べるツール、確認が必要なツール、禁止ツール。
引用と証拠ルール：いつ出典が必要か、証拠が衝突したときにどうするか。

これらは古い荷物ではなく、プロダクト契約です。違いは、移行時には長いスローガンから実行可能な制約へ書き換えることです。

例：

`1`	`ユーザーのプライバシーを漏らさない。`

これは次のようにできます。

最終回答に完全な電話番号、身分証番号、access token、API key、内部ユーザー ID を出力しない。参照が必要な場合は、電話番号の下 4 桁だけを残すなど、マスク済み形式だけを表示する。

誤って削ってはいけないもの

prompt を削るときに一番危険なのは、不要な文章を削ることではなく、本物のシステム境界を一緒に削ることです。次の内容は、古く見えても軽く消すべきではありません。

プライバシーとデータ処理要件：特にログ、エクスポート、システム間転送、第三者ツール呼び出しに関するルール。
安全と権限制限：データ削除、送金、メール送信、権限変更、shell コマンド実行など高リスク操作の確認ルール。
引用形式：プロダクトが citation、脚注、出典一覧、監査チェーンに依存しているなら、場所を取るだけで削らない。
ツール呼び出し境界：読み取り専用ツール、書き込み可能ツール、ユーザー確認が必要なツール。
失敗時の挙動：API タイムアウト、データ欠落、検索失敗、権限不足時の降格方法。
業務上の厳格ルール：価格、返金、停止、リスク管理、コンプライアンス審査など、モデルが自由に判断すべきでないルール。

簡単な判断方法は、削っても出力スタイルが少し変わるだけなら削除候補にする。削ると越権、漏えい、誤操作、誤った約束、監査断絶につながるなら残し、より精密に書き換える、というものです。

まとめ

GPT-5.5 prompting guide の核心は、「より高度なプロンプトを書く」ことではありません。古い prompt にある、プロセスを指定しすぎた部分を削ることです。

GPT-5.5 に向いた prompt は次を満たすべきです。

手順ではなく目標を優先する。
「うまくやる」ではなく成功基準を明確にする。
無限検索や無限ツールループではなく停止条件を持つ。
証拠なしに答えたり検索し続けたりせず、証拠予算を持つ。
モデルの自覚だけでなく検証ルールを持つ。
最初から reasoning effort を上げず、パラメータ調整は後にする。

古い system prompt がすでに長いなら、GPT-5.5 への移行の第一歩は内容を追加することではなく、削ることかもしれません。本当に破れないルールを残し、プロセスの細部を結果、境界、チェック項目へ変えるほうが、さらに prompt を積み上げるより効果的です。

参考資料

OpenAI Prompt guidance：https://developers.openai.com/api/docs/guides/prompt-guidance
OpenAI Using GPT-5.5：https://developers.openai.com/api/docs/guides/latest-model

Prompts on KnightLiブログ