GPT-5.5の公式プロンプトガイドが従来と真逆に｜長く書く人より「成果と制約だけ書く人」が強くなる3原則

この記事はChatGPTやAPIで毎日プロンプトを書いている実務者向け（プロンプトの基本構造が分かれば読めます）。

そもそも何が変わった？「短く・成果と制約・任せる」の3原則

OpenAIが公開した 公式プロンプトガイド のトップに、こう書かれています。

"Shorter, outcome-first prompts usually work better than process-heavy prompt stacks."

（短く、
成果を先に書くプロンプトのほうが、
手順を積み重ねたプロンプトより精度が出ることが多い）

― OpenAI Prompt guidance（GPT-5.5）

核は3つ。私はこれを「3原則」と呼んでいます。

• 短く（process-heavyな積み上げをやめる）
• 成果と制約を先に書く（outcome-first）
• 経路はモデルに任せる（細かい順序指定をしない）

3つ目が一番きつい変更です。
「ステップ・バイ・ステップで考えて」「必ず5段階で分析せよ」がGPT-5.4まではベストプラクティスでした。
これがGPT-5.5では「ノイズ」「探索空間を狭める」「機械的な答えを誘発する」とOpenAI自身が断言しています。

はい、ハシゴを外されました。

注目すべき理由は何？「長く書ける人＝強い」が逆転する

私がこのガイドを最重要扱いしているのは、
機能アップデートではなく「プロンプトを書く人の評価軸が逆転した」点です。

2024〜2025年のプロンプトエンジニアリングは、
長く・厳密に・全パターン網羅で書ける人が優位でした。
だからこそ「完全性契約」「検証ループ」「ツール永続性ルール」のような長いフレームワークが流行ったわけです。

このトレンドが終わりました。

OpenAI公式は、旧来の長いプロンプトについてこう書いています。

"Treat GPT-5.5 as a new model family to tune for, not a drop-in replacement for gpt-5.2 or gpt-5.4."

（GPT-5.5は新しいモデルファミリーとして調整せよ。
GPT-5.2やGPT-5.4の置き換えとして扱うな）

― OpenAI Prompt guidance

Simon Willisonも公式ガイドの解説記事で、
要点を以下のようにまとめています。

"The headline is: shorter prompts, less hand-holding, fewer ALWAYS/NEVER directives. The model is trusted to do more on its own."

（要点はこうだ：短いプロンプト、
過剰な手取り足取りをやめる、
ALWAYS/NEVER 指示を減らす。
モデル側により多くを任せる）

― Simon Willison: GPT-5.5 prompting guide

個人的にはこの「モデルに任せる」が今回の話の中心です。
GPT-5.4以前で必要だった防御的記述、
これをGPT-5.5は不要にした、
ということです。

悪い例 vs 良い例：何がそんなに違う？

公式ガイドが提示している対比は刺さります。
同じカスタマーサポートの業務を例にした、
悪い例と良い例の英文をそのまま引用します。

悪い例（公式記載）

"First inspect A, then inspect B, then compare every field, then think through all possible exceptions, then decide which tool to call..."

（まずAを調べ、
次にBを調べ、
すべてのフィールドを比較し、
考えられる例外を全部考え抜いて、
どのツールを呼ぶか決めて……）

― OpenAI Prompt guidance

良い例（公式記載）

"Resolve the customer's issue end to end. Success means: the eligibility decision is made from available policy and account data; any allowed action is completed before responding..."

（顧客の課題を最後まで解決すること。
成功条件: 利用可能なポリシーとアカウントデータから資格判定がなされていること、
許容されたアクションは応答前に完了していること……）

― OpenAI Prompt guidance

違いは1つだけ。
前者は「順序」を書いている、
後者は「成果（=何を達成すれば成功か）」を書いている。

表で並べるとこうなります。

正直、
5.4以前のテンプレを大量に持ってる人ほどダメージが大きいです。
長く書く能力＝価値、
という前提が崩れたので、
今までの努力の一部が「むしろ邪魔」に変わります。

既存プロンプトをどう書き換える？3ステップ手順

OpenAIは旧プロンプトの後方互換性を保ちつつ「ベストプラクティスではない」と明記しました。
実務者が今やる作業は、
社内に溜まったテンプレを段階的に書き換えることです。
公式ガイドが示している7項目テンプレートと、
書き換えの流れを整理します。

STEP1. 7項目に分解して捨てるブロックを決める

公式が推奨する7項目テンプレートはこれです。
各項目が何を担当するかを1行ずつ添えます。

1. Role（役割定義、1〜2文） － 「あなたはカスタマーサポート担当者」「あなたはコードレビュアー」のようにAIの立場を1〜2文で固定
2. Personality（口調・温度感） － 丁寧／フランク／毒舌など、AIが「どう話すか」のキャラ設定。出力の見た目を決める部分
3. Goal（達成目的） － 何のためにこの対話をするのか、最終的な目的を1文で書く
4. Success Criteria（成功条件・合否判定軸） － 「成功とは○○が満たされた状態」と合否判定軸を3〜5個。outcome-firstの心臓部
5. Constraints（法律・セキュリティ等の制約） － 個人情報を出力しない・特定APIを呼ばない・社内秘情報を書かない等の絶対ルール
6. Output（成果物形式） － JSON / Markdown / 箇条書き等、出力フォーマットの指定
7. Stop Rules（中止条件） － 「権限を超える操作が必要になったら止まれ」「3回試して解決しなければユーザーに確認せよ」等の停止条件

2のPersonalityは「どう話すか」（話し方の見た目）、
4のSuccess Criteriaは「どこまで達成すれば終わるか」（合否の中身）。
混同しがちですが、
別物です。
Personalityをいくら盛っても合否軸にはならない、
というのが公式の整理。

既存プロンプトをこの7枠に振り分けて、
どの枠にも入らない記述（「ステップ・バイ・ステップで考えて」「全例外を列挙せよ」等）は削除候補。
OpenAI公式は「すべてを埋める必要はなく、
実際に動作を変える情報に絞る」と注釈しています。

STEP2. process-heavyな手順記述を「成果＋制約」に置換する

具体的には、
「First inspect A, then inspect B…」型の文を、
「Resolve X end to end. Success means: …, …, …」型に書き直します。
やることは2つだけ。

• 動詞を「inspect / compare / decide」から「resolve / deliver / produce」に変える
• 「Success means:」のセミコロン区切りリストで合否判定軸を3〜5個書く

STEP3. ABテストで段階的に切り替える

本番投入前に旧プロンプトと新プロンプトを並行運用し、
品質指標（正答率・トークン消費・遅延）で評価する流れが安全です。
私の感覚値ではテンプレ1本のABテストは1日、
テンプレ書き換えは半日もあれば回ります。
社内テンプレが10〜20本ある組織でも、
評価環境さえ整っていれば1週間以内に切り替えは終わるはずです。

逆に評価環境を持たないチームが「短くしただけ」で本番投入すると、
合否判定軸を残せていない箇所で精度が落ち、
結局2〜3日のリファクタリングを抱えます。
短く書くことと、
合否軸を残すことはセットです。

「削りすぎ事故」をどう防ぐ？短くすれば良い、ではない

ここが一番見落とされがちな部分です。
「短く書け」を真に受けて制約まで削ると、
モデルが暴走します。

公式は ALWAYS / NEVER について、こう書いています。

"Use those words for true invariants, such as safety rules, required output fields, or actions that should never happen. For judgment calls...prefer decision rules instead."

（安全規則・必須出力・絶対に起きてはならないアクションには ALWAYS / NEVER を使え。
判断が必要な場面では decision rule を使え）

― OpenAI Prompt guidance

つまり「絶対指示を全廃しろ」ではなく「真の不変量にだけ残せ」という話です。
具体的には次のものは削ってはいけません。

• セキュリティ・コンプライアンス上の禁止事項（個人情報の出力禁止など）
• 必須出力項目（JSON形式・特定フィールドの存在）
• 絶対にやってはいけないアクション（外部API呼び出しの権限境界など）

削っていいのは「プロセス記述」「ムダに長い思考誘導」「過剰な例示」「全例外列挙」。
ここの線引きを誤ると、
社内テンプレで確実にされていた安全性が一気に外れます。

OpenAI公式自身も、過度な指示追従について自己注意を出しています。

"GPT-5.5 follows instructions more literally than previous models. Overly aggressive ALWAYS/NEVER directives can cause the model to ignore reasonable judgment calls."

（GPT-5.5は従来モデルより指示をリテラルに受け取る。
攻撃的すぎるALWAYS/NEVER指示は、
モデルが妥当な判断を無視する原因になる）

― OpenAI Prompt guidance

だからこそ、
短く書くと同時に「真の不変量」と「判断ルール」の切り分けが必須になります。
短ければ短いほど偉い、
ではありません。

料金は2倍だけど実効コストはどう動く？

API料金はGPT-5.4比で2倍に上がりました。
ここは触る前に押さえておきたい数字です。

単価だけ見ると2倍ですが、
ここで効いてくるのが「短く書く」の3原則です。
OpenAI公式ガイドは「process-heavyな積み上げをやめる」と明示しているので、
入力トークンは構造的に減ります。
出力側もtext.verbosityパラメータで制御できるようになり、
過剰な装飾出力が減る方向です。

私の見方では、
単価2倍を実効コストの2倍と見るのは雑です。
プロンプトを3原則に沿って書き直したテンプレなら、
トークン量が下がる分だけ単価増を吸収できます。
逆に、
長いプロンプトを温存したまま5.5に投げると、
料金だけ素直に2倍になります。
書き換えしないと損する構造、
と理解するのが妥当です。

ChatGPTプラン側はPlusが$20/月、
Proが$200/月、
Businessが$25/ユーザー/月。
Plusで触るならまずReasoningパラメータを意識した短いプロンプトから入るのが妥当です。

リリース後の評価をどう読む？「日常タスクには影響薄」論の意味

すべての論者が前向きなわけではありません。
Simon Willisonも、
ベンチマーク勝利と日常タスクの体感差を分けて語っています。

"The benchmark numbers are real, but most users running everyday chat tasks won't feel a dramatic step-change. The big wins are in agentic flows and structured prompting."

（ベンチマークの数字は本物だが、
日常的なチャットタスクを回しているほとんどのユーザーは劇的な変化を感じない。
大きな勝ちはエージェント的フローと構造化プロンプトにある）

― Simon Willison: GPT-5.5 prompting guide

私はこの整理に同意です。
プロンプトを「ふわっと使う」層には体感差が出ない、
「業務フローに組み込んでいる」層には深刻な書き換え圧、
という二極化です。

カスタマーサポート・エージェント設計・構造化出力（JSON生成等）を仕事で扱っている人は、
書き換え遅延がそのまま品質遅延につながります。
一方、
ChatGPT Plusで雑にブレストしてるだけの層は、
別に急がなくていい。
立場で温度差が割れる、
それが今回の正体です。

結局、誰にとって今がやり時なのか

3つのタイプに分かれます。

• 社内テンプレ運用者：今すぐ7項目分解→3原則書き換え→ABテストの流れに入る。遅らせると競合に先行される。
• カスタマーサポート設計者：公式の「悪い例→良い例」がカスタマーサポート文脈そのまま。outcome-first書き換えの効果が一番分かりやすい領域です。
• ChatGPTカスタム指示を作り込む個人：500語超の指示文を持っているなら見直し時。ただし削りすぎ事故防止のために、安全制約だけは残すこと。

逆に「Plusで月数回しか触らない」層は、わざわざ大改修する必要は薄いです。

FAQ

GPT-5.5用の新ルールは、GPT-4系やGPT-5.4以前にも適用していい？

いいえ。
OpenAIは公式に「treat as a new model family to tune for, not a drop-in replacement for gpt-5.2 or gpt-5.4」と明示しており、
GPT-5.5専用のチューニングが必要だと書いています。
GPT-4系・GPT-5.4向けには従来の書き方の方が有効です。

「短く書け」を徹底すると、品質が下がりませんか？

「短くする」と「制約を削る」は別の話です。
削ってよいのはプロセス記述・ムダに長い思考誘導・全例外列挙。
安全規則・必須出力・絶対にやってはいけないアクションは ALWAYS/NEVER で残す、
と公式が明示しています。

「ステップ・バイ・ステップで考えて」と書くのは完全にダメ？

プロンプト本文での明示記述は推奨されません。
GPT-5.5では推論の深さを reasoning.effort パラメータ（low/medium/high）で指定する設計に変わっています。
プロンプト内に書く代わりにAPIパラメータで制御するのが新しい流儀です。

移行作業の所要時間はどのくらいかかる？

テンプレ1本あたり、
ABテストは1日、
書き換え自体は半日が目安です。
社内テンプレが10〜20本ある組織でも、
評価環境さえ整っていれば1週間以内に切り替えは終わります。
評価環境を持たずに「短くしただけ」で本番投入すると、
合否軸が抜け落ちて2〜3日のリファクタリングが発生します。

GPT-5.5 と Claude のどちらを使えばいい？

領域で使い分けるのが現実的です。
OpenAI公式は GPT-5.5 を「新しいモデルファミリーとして調整せよ」と位置づけており、
過去のGPT系プロンプトをそのまま流用しないこと、
構造化プロンプトとエージェント的フローで真価を出すことを推奨しています。
Claude側との比較は Artificial Analysis の総合評価が参考になります。

参考リンク

• OpenAI 公式プロンプトガイド（GPT-5.5）
• OpenAI 公式 GPT-5.5 モデルページ
• Simon Willison: GPT-5.5 prompting guide 解説
• Artificial Analysis: モデル総合評価

※この記事の内容は執筆時点のものです。AIは進化が速い分野のため、最新の仕様は公式サイトでご確認ください。