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は進化が速い分野のため、最新の仕様は公式サイトでご確認ください。