OpenAI、GPT-5.5の利用法とプロンプトガイドを公開　——達成条件と停止条件の明確化を重視

OpenAIは2026年4月24日、OpenAI DevelopersでGPT-5.5の開発者向けガイド「Using GPT-5.5」とプロンプトガイド「Prompt guidance」を公開した。

これらのガイドは、GPT-5.5をGPT-5.2やGPT-5.4からの単純な差し替えとして扱わず、新しいモデルファミリーとしてプロンプトや設定を調整するよう案内している[1]。特にプロンプト設計では、必要以上に手順を固定するよりも、達成すべきことや停止条件を先に明確にする書き方（outcome-first）を重視している。

この記事では、そうしたプロンプト設計の考え方と、APIで利用する際に注意すべきパラメータや状態管理の要点を整理する。

GPT-5.5は差し替えではなく新しい前提で調整する

OpenAIはGPT-5.5について、実運用で使う複雑なワークフローの実行品質を高めるモデルとして説明している。例として、コーディング、ツールを多用するエージェント、根拠を示して回答するアシスタント、長いコンテキストからの検索、製品仕様を実行計画に落とし込む作業、顧客向け回答の仕上がりが重要な場面などを挙げる。

GPT-5.2やGPT-5.4から移行する場合は、モデル名だけを置き換えるのではなく、GPT-5.5向けにプロンプトや設定を見直すことを勧めている。たとえば、アプリケーションとして必ず守りたい挙動を保てる最小限のプロンプトを基準にし、代表的な入力例を使って、推論の強さ（APIではreasoning.effort⁠）⁠、回答の詳しさ、ツール説明、出力形式を調整していくことを紹介している。

プロンプトは達成すべきことと守るべきルールを先に書く

プロンプトガイドでは、順番が重要でない場面で「まずAを調べ、次にBを比較し、最後にCを判断する」と細かく指定すると、モデルの探索範囲を狭め、機械的な回答につながる場合があると説明している。

こうした書き方の一つとして、プロンプトガイドは以下のような項目を先に整理する例を示している。

何が達成されれば成功か
どの制約や安全上のルールを守るべきか
どの根拠やデータを使えるか
どのような出力形式で返すべきか
どの時点で追加調査を止め、回答または質問に移るべきか

なお、正確な順番や手順が必要な作業では、その順番や手順をプロンプトで明示する。

以下では、プロンプトガイドのうち「達成すべきことを先に置くプロンプトと停止条件」「⁠根拠、引用、検索の止め方」「⁠作業後の検証」に対応する3つの例を取り上げる。

例1⁠：達成条件と停止条件を先に定義する

顧客対応や社内ワークフローのように「最後に何が完了していればよいか」が重要な作業では、手順を細かく固定する前に成功条件を書く。たとえば、次のように「目的」「⁠成功条件」「⁠根拠が足りない場合の扱い」を分けておく。

# 目的
顧客の問い合わせを最後まで解決する。

# 成功条件
- 利用できるポリシーとアカウント情報から適格性を判断する。
- 実行が許可されている対応は、回答前に完了する。
- 最終回答には、完了した対応、顧客向けメッセージ、残る障害要因を含める。

# 根拠が足りない場合
判断に必要な最小限の項目だけを質問する。

この例では、「⁠最初に何を調べ、次に何を比較するか」は固定していない。代わりに、最終的に満たすべき状態と、途中で情報が足りない場合の振る舞いを指定している。

例2⁠：根拠付き回答では検索の止めどころを決める

調査や事実確認では、検索を増やすほどよいとは限らない。必要な根拠を確保しつつ、不要な検索を続けないため、検索を続ける条件と止める条件をあらかじめ決める。ガイドではこれをretrieval budgetと呼んでいる。たとえば、次のように「最初の検索」「⁠追加検索する条件」「⁠追加検索しない条件」を分ける。

# 最初の検索
通常のQ&Aでは、まず判別しやすい短いキーワードで広めに検索する。

# 追加検索する条件
- 上位結果だけではユーザーの中心的な問いに答えられない。
- 必要な事実、日付、ID、所有者、一次資料が欠けている。
- ユーザーが網羅的な比較や包括的な一覧を求めている。
- 特定の文書、URL、メール、会議記録、コードなどを読む必要がある。
- 追加検索しないと、重要な事実主張を根拠なしに含めることになる。

# 追加検索しない条件
上位結果でユーザーの中心的な問いを引用付きで支えられる場合は、追加検索せず回答する。

この例では、検索回数を増やすのではなく、追加検索が必要な条件と不要な条件を切り分けている。上位結果で中心的な問いを支えられるなら回答に移り、根拠が欠けている場合だけ追加で検索する。表現を整える、例を足す、重要でない詳細に引用を付けるといった目的だけでは再検索しないことを指定する。

例3⁠：コード変更後の検証方法を指定する

コード関連の利用では、コードを書かせるだけでなく、変更後に何を確認するかまで指定しておくとよい。コーディングエージェントに対しては、変更内容に応じた検証を実行するよう促す。たとえば、次のように「実行する検証」と「実行できない場合の説明」を分けておく。

# 変更後の検証
変更後は、実行できる中で最も関連性の高い検証を実行する。

# 優先する確認項目
- 変更した挙動に対応する単体テスト
- 必要に応じた型チェックまたはLint
- 影響範囲に応じたビルドチェック
- 完全な検証が高コストな場合は、最小限のスモークテスト

# 検証できない場合
検証を実行できない場合は、その理由と次善の確認方法を説明する。

この例では、単に「確認して」と頼むのではなく、検証の候補と、検証できない場合の報告方法を指定している。これにより、モデルはコード変更後にどのチェックを優先すべきか判断しやすくなる。

Codexでの実践例として、OpenAIのGabriel Pettersson氏はXへの投稿で、Codexに加える指示として「add to codex that it should always run the exact code that it touches to make sure it knows the exact behavior」（⁠意訳：Codexには「変更したコードの実際の挙動を把握するため、変更対象のコードそのものを実行してください」という指示を加えるとよい）と述べている。さらに、必要な関数を使うか、関連コードを検証用スクリプトに取り込み、本番での実際の挙動を確認させることも提案している。

つまり、関連する関数やコードを必要に応じて検証用スクリプトに取り込み、本番で実際に起きる挙動を確認するところまでCodexに指示する形になる。なお、検証用スクリプトは/codex-scriptsに置き、Git管理から除外する運用も示している。

そのほかの調整ポイント

ここで取り上げた3つの例は、いずれも細かな思考手順を必要以上に固定せず、達成すべきこと、制約、停止条件、確認方法を明示している。

プロンプトガイドではこのほかにも、応答スタイル、途中経過の伝え方、出力形式、根拠の扱い、検証ルールを用途に応じて指定する例を示している。

応答スタイル

GPT-5.5の標準的な応答スタイルは、効率的で直接的であり、依頼された作業に集中する傾向がある。顧客に直接応答する用途では、必要に応じて語り口や質問のタイミング、どこまで自律的に進めるかを短く指定する。ただし、語り口を指定するだけでは不十分で、目標、成功条件、ツールの使い方、停止条件も明確にする必要がある。

# Personality
有能な協力者として、親しみやすく、落ち着いて、直接的に対応する。

# Collaboration style
依頼が十分明確なら、確認で止まらず前に進める。質問は判断に影響する場合だけに絞る。

途中経過の伝え方

長い作業やツール利用では、最初の応答が見えるまでに時間がかかる場合がある。その場合は、作業前に出す短いステータス更新（preamble）を使い、依頼を理解したことと最初の作業内容を短く伝えるよう指定すると、待ち時間中の不安を減らしやすい。

複数ステップの作業では、ツール呼び出し前に短いユーザー向け更新を出す。
依頼を理解したことと最初の作業だけを1〜2文で伝える。

出力形式

出力形式は、読みやすさやUI上の安定性のために指定する。通常の回答では自然な段落構成を基本にし、比較や一覧性が必要な場合に見出しや箇条書きを使う。編集、要約、顧客向け文章の書き換えでは、改善を求める前に、維持すべき長さ、構成、ジャンル、トーンを伝えるとよい。

上級ビジネス読者向けに400語以内で書く。
短い段落を使い、箇条書きは読みやすさが増す場合だけ使う。
結論、理由、注意点の順にする。

根拠の扱い

根拠が必要な回答では、どの主張に引用が必要か、どの程度の根拠で十分か、根拠がないときにどう振る舞うかを決めておく。事実と表現上の工夫が混ざる下書きでは、製品仕様や数値、日付などの具体的な主張を根拠で裏付ける。引用できる根拠が少ない場合は、事実を補って強く見せるのではなく、仮置きや前提を明示した汎用的な下書きにとどめる。

製品、顧客、数値、ロードマップ、日付、競合比較の主張は根拠に基づける。
根拠が少ない場合は、具体的な主張を足さず、プレースホルダーや明示した前提を使う。

作業後の検証

コーディング以外の成果物でも、作業後の検証をプロンプトに含めると品質を安定させやすい。視覚的な成果物では、レンダリング後に表示崩れや欠落を確認し、要件に合うまで修正する指示が有効になる。

完成前に成果物をレンダリングする。
レイアウト、クリッピング、余白、欠落、一貫性を確認し、要件に合うまで修正する。

複雑なプロンプトは各要素を短く組み合わせる

複雑なプロンプトでは、役割（Role⁠）⁠、文体・振る舞い（Personality⁠）⁠、目標（Goal⁠）⁠、成功条件（Success criteria⁠）⁠、制約（Constraints⁠）⁠、出力（Output⁠）⁠、停止ルール（Stop rules）などを分けて書く方法もある。

Role: モデルの役割、文脈、仕事を1〜2文で定義する

# Personality
トーン、態度、協働スタイル

# Goal
ユーザーから見える到達点

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

# Constraints
ポリシー、安全性、ビジネス、根拠、副作用に関する制限

# Output
セクション構成、長さ、トーン

# Stop rules
再試行、フォールバック、辞退、質問、停止の条件

ただし、すべての項目を埋める必要はない。実際にモデルの振る舞いを変える情報に絞り、何を目指し、どこまで進め、何を守り、いつ止まるかを短く書く。

既存プロジェクトでGPT-5.5へ移行する場合

既存プロジェクトをGPT-5.5へ移行する開発者向けに、OpenAIはCodexでOpenAI Docs Skillを使う具体例も示している。

$openai-docs migrate this project to gpt-5.5

Codexの自動変更を使って、移行作業を始められる。適用後はそのまま完了とせず、代表的な入力例で期待どおりに動くかを確認し、必要に応じてプロンプトやAPI設定を調整する。

APIで利用する場合は設定と状態管理を見直す

APIでGPT-5.5を利用する場合も、OpenAIはモデルIDの変更だけでなく、プロンプト外の設定や状態管理を見直すことを勧めている。gpt-5.2やgpt-5.4を使っている実装から移行する場合は、Responses API、reasoning.effort、text.verbosity、Structured Outputs、プロンプトキャッシュ、ツール説明、長時間ワークフローでの状態管理などもあわせて確認する。

OpenAIは、推論、ツール呼び出し、複数ターンの会話を伴う用途ではResponses APIの利用を勧めている。決まった形式の出力が必要な場合は、出力スキーマをプロンプト内で細かく説明するより、Structured OutputsでJSON Schemaを指定する。具体的な指定方法は、Structured Outputsのドキュメントを参照のこと。

回答の長さや詳しさは、text.verbosityで調整する。GPT-5.5ではtext.verbosityのdefaultがmediumで、簡潔な応答を優先する用途ではlowを評価するようOpenAIは案内している。

推論の強さはreasoning.effortで指定する。GPT-5.5ではreasoning.effortのdefaultがmediumで、品質、信頼性、レイテンシ、コストのバランスを見ながら調整する。低レイテンシが重要な用途でも、ツール利用、計画、検索、多段階の判断が必要なら、OpenAIはnoneの前にlowを評価することを勧めている。highやxhighは、評価で品質向上が確認でき、追加のレイテンシやコストに見合う場合に使う。

そのほか、プロンプトキャッシュでは安定した指示を前半に置き、ユーザーごとに変わる情報を後半に置く。画像入力では、image_detailの既定の扱いが変わり、未指定またはautoの場合にこれまでより画像の詳細を保持する。

長時間稼働するエージェントでは、短いステータス更新（preamble⁠）⁠、アシスタント項目の手動再送、phaseの扱いも確認していく。また、ツール固有の使い方は、システムプロンプトに詰め込むより、各ツールの説明に持たせることをOpenAIは推奨している。

なお、プロンプト設計を見直す際には、次の関連ドキュメントも参照できる。

プロンプトの形式や判断基準を例で示したい場合は、Prompt engineeringドキュメントのFew-shot learningを参照できる。Few-shot learningでは、少数の入力例と望ましい出力例をプロンプトに含め、モデルにパターンを伝える。

外部ページ、ファイル、ツール出力など信頼できない入力を扱うエージェントでは、外部データに含まれる悪意ある文が本来の指示を上書きしようとするプロンプトインジェクション対策も重要になる。Safety in building agentsでは、OpenAIがこのリスクへの備えを説明している。

品質確認やプロンプト改善まで進める場合は、既存の評価・改善手段も使える。Working with evalsではテスト入力と評価基準を使ってモデル出力を評価でき、Prompt optimizerではデータセット、アノテーション、grader結果などを使ってプロンプトの改善を検討できる。