GPT-6 の使い方

はじめに

GPT-5.5 は、本番環境の複雑なワークフローで得られる成果の水準を引き上げます。コーディング、ツールを多用するエージェント、根拠に基づいて回答するアシスタント、長いコンテキストからの情報検索、製品仕様から計画を作成するワークフローに適しています。処理を正確に完遂し、読みやすく洗練された回答を返すことが重要な顧客向けワークフローにも適しています。

GPT-5.5 の性能を引き出すには、gpt-5.2 や gpt-5.4 をそのまま置き換えるのではなく、新しいモデルファミリーに合わせて調整してください。移行時には、従来のプロンプトに含まれる指示をすべて引き継がず、評価の基準を新たに設定します。まず、製品として保証すべき動作を維持できる最小限のプロンプトを用意し、代表的な例で結果を確認しながら、推論強度、回答の詳しさ、ツールの説明、出力形式を調整します。

GPT-5.5 は、GPT-5.4 で利用できたすべての API 機能に対応しています。これには、プロンプトキャッシュ、ホスト型ツール、ツール検索、コンパクション、アシスタントの出力項目を手動で再送する際の phase の処理が含まれます。

効果的なプロンプトの例は、プロンプト作成のベストプラクティスを参照してください。

新機能と改善点

• 推論の効率向上： GPT-5.5 は、同じ推論強度でも、従来のモデルより少ない推論トークンで優れた結果を出せます。特に、複雑なワークフローや、ツールを多用するワークフロー、複数のステップを含むワークフローでは、トークンの削減効果が積み重なります。
• 成果を明示したプロンプトによるタスク遂行能力の向上： GPT-5.5 は、明確な目標に沿って制約を守りながら、製品で実現したいことを具体的な次のアクションに落とし込む能力が向上しています。期待する成果、成功基準、許容する副作用、根拠の扱い方、出力形式を記述してください。特定の手順を踏む必要がある場合を除き、手順を逐一指定するのは避けてください。
• ツールの選択と使用の精度向上： GPT-5.5 は、利用可能なツールが多い環境、複数のステップを含むサービスのワークフロー、長時間実行されるエージェントタスクで特に有効です。適切なツールを選び、引数を正確に指定できる傾向があります。
• より洗練された語り口： GPT-5.5 は、プロンプトで細かく指示しなくても、温かみのある読みやすい回答を生成する傾向があります。一方で、表現がより率直になることもあります。

動作の変更点

1. 推論強度のデフォルトが medium に変更： GPT-5.5 のデフォルトの推論強度は medium です。品質、信頼性、レイテンシ、コストのバランスを取るには、まず medium から始めることをおすすめします。レイテンシを抑えたいワークフローでも、ツールの使用、計画、検索、複数ステップでの意思決定が重要な場合は、low を評価してから none を検討してください。none は、短いやり取りで済む音声対話、高速な情報検索、分類など、レイテンシが最優先で、推論やツールの連続呼び出しが不要なタスクに限って使用してください。high または xhigh に上げるのは、レイテンシとコストの増加に見合う品質向上を評価で定量的に確認できた場合に限ります。推奨設定の詳細は、リーズニングモデルのドキュメントを参照してください。

   推論強度を上げれば必ず良い結果が得られるわけではありません。指示が矛盾している場合、終了基準が曖昧な場合、ツールの使用範囲を限定していない場合は、推論を重ねすぎたり、不要な検索が増えたり、出力品質が低下したりすることがあります。推論強度を上げるのは、評価で品質向上を定量的に確認できた場合に限ってください。

2. 画像入力で保持される細部の増加： GPT-5.5 では画像入力のデフォルトの処理が変わり、画像の細部がより多く保持され、コンピューターの使用時の性能が向上します。image_detail が未設定、または auto の場合は、original と同じ動作になります。総画素数が 10,240,000 ピクセル以下で、各辺が 6,000 ピクセル以下の画像はリサイズされません。high を使用するには、値を明示的に指定してください。総画素数が 2,500,000 ピクセル以下で、各辺が 2,048 ピクセル以下の画像はリサイズされません。low ではコンテキストの効率的な使用を優先し、いずれかの辺が 512 ピクセルを超える画像を従来のモデルよりも積極的に縮小します。画像とビジョンのドキュメントを参照してください。

3. 指示に従う能力の向上： GPT-5.5 はプロンプトを文面に忠実に、細部まで解釈するため、製品の要件に応じて具体的で詳しい指示を与えられます。特に、長時間実行されるワークフロー、ツールを多用するワークフロー、根拠を収集するワークフローでは、成功基準と終了条件を定義してください。成果を明示したプロンプトの書き方と指示の具体性の調整を参照してください。

4. デフォルトの文体がより簡潔で率直に： GPT-5.5 は、デフォルトでは無駄を省き、タスクに即して率直に回答する傾向があります。多くの本番ワークフローで役立つ一方、顧客向けの製品や対話型の製品では、個性や温かみ、判断理由の説明、書式について明示的な指示が必要になることがあります。目的に合わせて text.verbosity を設定してください。デフォルトは medium ですが、簡潔な回答を求める場合は low から始める方が適していることがよくあります。プロンプト作成のベストプラクティスを参照してください。

5. コーディングワークフローにおける処理の連携： GPT-5.5 は、計画、ツールの使用、コードベースの調査、検証、複数ステップの実行を伴う複雑なコーディングタスクに、より適しています。こうしたタスクでは処理の連携がいっそう重要になります。コーディングエージェントには、既存コードの再利用、サブエージェントへの委任、求めるテスト、受け入れ基準、自力で作業を続ける条件と支援を求める条件を明示してください。

移行クイックスタート

Codex による移行の自動化

Codex は、OpenAI Docs スキルを使って、このガイドで推奨する変更を適用できます。

$openai-docs このプロジェクトを gpt-5.5 に移行してください。

他のコーディングエージェントでこのスキルを使用するには、OpenAI のスキルリポジトリからダウンロードしてください。

API とモデルのパラメーター

• モデルのスラッグを gpt-5.5 に更新してください。
• 推論、ツール呼び出し、複数ターンのやり取りのいずれかを伴うユースケースには、Responses API を使用してください。
• reasoning.effort を調整してください。効率よく推論するには low、レイテンシと性能のバランスを取るには medium を使用します。高度な推論を要し、レイテンシの優先度が低い複雑なエージェントタスクには high を、最も難しい非同期のエージェントタスクやモデルの能力の限界を測る評価には xhigh を使用します。リーズニングモデルのドキュメントを参照してください。
• 回答をより簡潔にするには、text.verbosity を low に設定してください。GPT-5.5 では、同じ low 設定の GPT-5.4 に比べて、回答がより短くまとまります。
• ツールを多用するワークフローや長時間実行されるワークフローでは、アプリケーションが phase、冒頭の進捗メッセージ、アシスタントの出力項目の再送を正しく処理することを確認してください。
• 正確性、トークン消費量、エンドツーエンドのレイテンシを測定し、他のモデルと比較してください。

プロンプトの作成

• 期待する成果と成功基準を明示してください。
• 手順を逐一指定する指示は減らすか削除してください。製品の要件で手順が決まっている場合を除き、進め方は GPT-5.5 に任せてください。
• 可能な限り、プロンプトから出力スキーマの定義を削除してください。代わりに構造化出力を使用してください。
• キャッシュを活用できるよう、プロンプトでは固定部分を先頭に、可変部分を末尾に配置してください。
• 現在の日付は省いてください。モデルは UTC の現在の日付をすでに把握しています。
• プロンプト作成のベストプラクティスに沿ってプロンプトを見直し、改善してください。

リーズニングモデルの活用

このガイドの内容は GPT-5 シリーズのモデルに適用できます。ワークロードをリーズニングモデルに移す際は、その都度見直すことをおすすめします。GPT-5.5 は、以前のモデルで導入された機能の多くを引き継いでいます。以前の GPT-5 モデル、GPT-4.1、または o3 などのリーズニングモデルから移行する場合も、これらの機能を改めて確認してください。

これらの機能の一部は、プロンプトではなく API の設定や処理の連携に関わるため、見落とされがちです。Responses API、推論の設定、回答の詳しさ、構造化出力、プロンプトキャッシュ、ツールの設計、ホスト型ツール、状態管理を組み合わせることで、リーズニングモデルの能力と信頼性を最大限に引き出し、レイテンシとコストを最適化できます。

• Responses API： GPT-5.5 の性能を最も引き出せるのは Responses API です。複数ターンにわたって状態を管理するには previous_response_id を使用してください。ステートレスな処理やゼロデータ保持が必要な処理では、各ターンで、返された出力項目のうち関連するものを再送してください。詳細は、前の応答からのコンテキストの引き継ぎを参照してください。
• 推論強度： reasoning.effort で low、medium、high、xhigh のいずれかを選択します。デフォルトは medium ですが、多くのワークロードでは low でも良好な結果が得られます。none は、モデルの推論能力よりも低レイテンシが重要なユースケースに限って使用してください。詳しい推奨事項は、リーズニングモデルを参照してください。
• 回答の詳しさ： text.verbosity で出力の長さを調整します。最終回答の長さと推論の品質は分けて考え、必要に応じて語数の上限、セクション数、表の幅、JSON のみの出力などを指定してください。
• 構造化出力： 期待する出力スキーマをプロンプトに記述するのは避けてください。構造化出力を使用すると、自動検証が可能になり、精度も向上します。
• プロンプトキャッシュ： プロンプトキャッシュは条件を満たす長いプロンプトに自動的に適用され、レイテンシと入力トークンのコストを削減できます。キャッシュヒットを増やすには、リクエストの先頭に固定の内容を配置し、ユーザーごとに変わるコンテキストは末尾付近に置いてください。usage.prompt_tokens_details.cached_tokens を追跡すると、再利用されたトークン数を測定できます。再利用可能な先頭部分を共有するリクエストには、同じ prompt_cache_key を使用してください。このキーは関連するリクエストを同じキャッシュに振り分けるのに役立ち、GPT-5.5 のキャッシュヒット率を最適化するうえで重要です。リクエストが集中するグループについては、より多くのキーにトラフィックを分散するためのガイドに従ってください。
• ツール呼び出し： GPT-5.5 は GPT-5.4 と同じツール呼び出しのパターンに対応しており、関数ツールやツールを多用するエージェントのワークフローを利用できます。個々のツールに関する指示の大半は、そのツール自体の説明に記載してください。機能、使うタイミング、必須の入力、副作用、安全に再試行できる条件、よく発生するエラーを明記します。ツール固有の情報をシステム指示に追加するのは、複数のツールに共通する場合や、エージェントの動作方針に実質的な影響を与える場合に限ってください。
• ホスト型ツールとツール検索： ワークフローに適している場合は、OpenAI がホストするツールを優先してください。ウェブ検索、ファイル検索、Code Interpreter、画像生成、コンピューターの使用などが該当します。ホスト型ツールを使うと、ツール間の連携を独自に実装する負担を減らし、一般的な利用パターンを Responses API や Agents SDK に合わせられます。自社システムを呼び出す場合、操作に伴う業務固有の状態変更を確実に実行する必要がある場合、社内の業務ワークフローをエージェントから利用できるようにする場合は、カスタム関数ツールを使用してください。ツールのカタログが大きい場合は、ツール検索を使って定義の読み込みを遅らせ、関連するツールだけを読み込むことを検討してください。
• ツール使用前の進捗メッセージ： モデルが最終回答を生成する前に、ユーザーが最初の進捗状況を確認できるため、チャットの使い勝手が向上します。ツールを使う過程も追いやすくなります。モデルはこれから確認する内容や実行する操作を伝え、ツールの結果を受け取った後、同じアシスタントの状態から処理を続けられます。
• phase の処理： アプリケーションが previous_response_id を使わず、各ターンで出力項目を再送して Responses API の状態を手動で管理する場合は、返されたアシスタントの出力項目の phase パラメーターを保持し、変更せずに再送してください。推論強度を設定している場合、冒頭の進捗メッセージを使う場合、ツールを繰り返し呼び出す場合は特に重要です。phase パラメーターを参照してください。
• コンパクション： 長時間実行されるエージェントでは、目的に合わせて会話と状態のコンパクションを使用してください。完了したアクション、現在有効な前提、ID、ツールの実行結果、未解決の問題、次に達成すべき具体的な目標を保持してください。
• Agents SDK： 新しいエージェントシステムでは、連携の仕組みを一から構築せず、ツールの連携、トレース、ハンドオフ、状態管理に最新の Agents SDK のパターンを使用してください。
• 現在の日付： GPT-5.5 は UTC の現在の日付を把握しているため、システム指示に現在の日付を追加する必要はありません。日付やタイムゾーンを明示するのは、業務で使用するタイムゾーン、ポリシーの発効日、ユーザーの現地日付など、UTC の現在の日付以外の基準がアプリケーションで必要な場合に限ってください。

プロンプト作成のベストプラクティス

GPT-5.5 の性能を最も引き出せるのは、プロンプトで成果を定義し、効率的な解決方法をモデルが選べるようにした場合です。従来のモデルよりも短く、成果に焦点を当てたプロンプトで十分なことがよくあります。何をもって良い結果とするか、どの制約が重要か、どのような根拠を利用できるか、最終回答に何を含めるべきかを記述してください。

従来のプロンプトに含まれる指示をすべて引き継ぐのは避けてください。以前のモデルでは作業が本筋から外れないよう細かく指示する必要があったため、従来のプロンプトは手順を過剰に指定しがちです。GPT-5.5 では、こうした指示がかえってノイズになり、モデルが検討できる選択肢を狭めたり、回答が機械的になりすぎたりすることがあります。

以下のパターンを出発点に、製品の利用場面、ツール、評価方法、目指すユーザー体験に合わせて調整してください。

個性と振る舞い

GPT-5.5 は、デフォルトでは無駄を省き、タスクに即して率直に回答します。本番システムでは、回答が本題に集中し、振る舞いを調整しやすく、不要な会話が増えにくいという利点があります。

顧客向けアシスタント、サポート業務、コーチングなどの対話型製品では、個性と協働スタイルの両方を定義してください。

• 個性は、アシスタントの語り口を決めます。口調、温かみ、率直さ、丁寧さ、ユーモア、共感の示し方、表現の洗練度が含まれます。
• 協働スタイルは、アシスタントの仕事の進め方を決めます。いつ質問するか、いつ前提を置いて進めるか、どこまで先回りして対応するか、背景をどこまで説明するか、いつ作業を検証するか、不確実性やリスクをどう扱うかが含まれます。

どちらの指示も短くまとめてください。個性に関する指示はユーザー体験を、協働に関する指示はタスクの進め方を方向づけます。どちらも、明確な目標、成功基準、ツールの使用ルール、終了条件の代わりにはなりません。

落ち着いてタスクに取り組むアシスタントの個性を定義する例：

# 個性
あなたは、気軽に相談でき、落ち着いて率直に対応する、頼りになる協力者です。ユーザーには判断力があり、誠実に行動していることを前提にしてください。辛抱強く、敬意を持って接し、実際に役立つ回答を返してください。

依頼が着手できる程度に明確なら、確認のために作業を止めず、文脈と妥当な前提をもとに進めてください。情報が足りないことで回答が大きく変わる場合や、無視できないリスクが生じる場合に限り、確認したい点を絞って質問してください。

そっけなくならないよう、簡潔に答えてください。ユーザーが回答を理解し、信頼するのに十分な背景を伝えたら、そこで説明を終えてください。要点が伝わりやすくなる場合は、例や比較、簡単なたとえを使ってください。ユーザーの誤りを指摘するときや意見が異なるときは、率直かつ建設的に伝えてください。自分の誤りを指摘されたら、はっきり認め、修正に集中してください。

専門家としてふさわしい範囲で、ユーザーの口調に合わせてください。絵文字や乱暴な言葉は、ユーザーがその文体を明示的に求めた場合や、これまでのやり取りからその場にふさわしいことが明らかな場合を除き、使わないでください。

表現力があり、ユーザーと一緒に考えるアシスタントの個性を定義する例：

# 個性
知性と好奇心が伝わる、生き生きとした語り口で対話してください。場に応じて遊び心を交え、ユーザーの考えに注意を向けてください。何が問題なのか曖昧なときは、要点を探る質問をし、判断に必要な情報がそろったら、はっきりと方針を示してください。

温かみのある洗練された言葉で、ユーザーと一緒に考えてください。会話は気軽で活気のあるものにし、話を続けること自体を目的にしないでください。ユーザーの目標や制約を踏まえながら、相手の意見を繰り返すだけで終わらず、自分の見解を示してください。

情報をまとめたり助言したりするときは、根拠を踏まえてよく考えてください。十分な情報があれば、何を勧めるかを明言し、重要なトレードオフを説明してください。不確かな点も、言葉を濁さず具体的に示してください。

より表情豊かなやり取りを目指す製品では、温かみ、好奇心、ユーモア、独自の視点などを明示しつつ、指示は短くまとめてください。個性は体験を形づくるために使い、曖昧な目標や不足しているタスク指示を補う手段にしないでください。

冒頭の進捗メッセージによる最初のトークン表示までの時間短縮

ストリーミングを使うアプリケーションでは、最初の応答が表示されるまでの待ち時間がユーザーに伝わります。GPT-5.5 は、画面にテキストを出力する前に、推論、計画、ツール呼び出しの準備に時間をかけることがあります。

時間がかかるタスクやツールを多用するタスクでは、冒頭に短い進捗メッセージを表示するようモデルに指示してください。依頼を受けたことと最初に行う作業を簡潔に伝えます。タスク自体を変えずに、ユーザーが感じる応答速度を改善できます。

タスクに複数のステップやツール呼び出しが必要になる可能性がある場合、または長時間実行されるエージェントのワークフローを伴う場合に、このパターンを使用してください。

複数のステップを含むタスクでは、ツールを初めて呼び出す前に、ユーザーに短い進捗メッセージを送ってください。依頼を受けたことと、最初に何をするかを 1～2 文で伝えてください。

メッセージのフェーズを区別して扱えるコーディングエージェントには、より明確に指示できます。

ツールの呼び出しが必要なタスクでは、analysis チャネルに何かを書き込む前に、必ずユーザーに進捗メッセージを送ってください。依頼を受けたことを伝え、最初に行う作業を説明してください。

成果を明示したプロンプトと終了条件

GPT-5.5 が最も力を発揮するのは、プロンプトで目標とする成果、成功基準、制約、利用可能なコンテキストを定義し、進め方をモデルに任せた場合です。

多くのタスクでは、すべての手順を指定するよりも、到達点を記述する方が効果的です。モデルはタスクに合った検索方法、ツール、推論の進め方を選べます。

推奨する例：

顧客の問題を最後まで解決してください。

成功基準：
- 利用可能なポリシーとアカウントデータに基づいて、顧客が適用条件を満たすか判断すること
- 必要な対応のうち、許可されている操作だけを実行し、それらをすべて完了してから返信すること
- 最終回答に completed_actions、customer_message、blockers を含めること
- 判断の根拠が足りない場合は、不足を補うのに必要な最小限の 1 項目だけを尋ねること

必要のない絶対的なルールは避けてください。 従来のプロンプトでは、モデルの振る舞いを制御するために ALWAYS、NEVER、must、only などの強い表現がよく使われていました。こうした表現は、安全上のルール、必須の出力フィールド、決して実行してはならない操作など、例外を認めない要件に使ってください。検索するか、追加の説明を求めるか、ツールを使うか、作業を続けるかなど、状況に応じた判断が必要な場合は、判断基準を示す方が適しています。

すべての手順が本当に必要な場合を除き、次のような指示は避けてください。

まず A を調べ、次に B を調べてください。その後、すべてのフィールドを比較し、考えられる例外をすべて検討してください。それから呼び出すツールを決め、そのツールを呼び出し、最後に一連の手順をすべてユーザーに説明してください。

終了条件を明示してください。

ツールを呼び出して結果を確認する回数は、ユーザーの問いを解決するのに必要な最小限にしてください。ただし、回数を減らすことよりも、回答の正確さ、利用できる代替の根拠の確認、必要な計算、事実を述べる際に必須の出典タグを優先してください。

結果を受け取るたびに、「今ある根拠を使い、事実には出典を示したうえで、ユーザーの依頼の核心に答えられるか」と確認してください。答えられるなら、その時点で回答してください。

根拠が不足している場合の振る舞いを定義してください。

正しく答えるのに必要な最小限の根拠を使い、その出典を正確に示したら、そこで作業を終えてください。

書式

GPT-5.5 は、出力形式や構成に関する指示に柔軟に従います。内容が理解しやすくなる場合や、製品に適した形で提示できる場合に活用してください。

text.verbosity を設定し、期待する出力形式を記述してください。細かな構成を指定するのは、理解を助ける場合や、製品の UI で一定の形式の成果物が必要な場合に限ります。API での text.verbosity のデフォルトは medium です。短く簡潔な回答が望ましい場合は low を使用してください。

通常の会話に適したシンプルな書式の例：

内容を理解しやすくするために書式を使ってください。普段の会話、説明、報告書、ドキュメント、技術解説では、通常の段落を基本とします。内容に対して構成が大げさにならないようにし、すっきりと読みやすく整えてください。

見出し、太字、箇条書き、番号付きリストは控えめに使ってください。ユーザーから指定がある場合、違いや順位を明確に示す必要がある場合、段落だけでは必要な情報を見つけにくい場合に使います。それ以外は短い段落で書き、話題を自然につないでください。

ユーザーが希望する書式を尊重してください。手短な回答、装飾を抑えた書式、箇条書きなし、見出しなし、特定の構成などの希望があれば、よほどの理由がない限り、その希望に従ってください。

想定読者と長さについても明示してください。

経営幹部に向けて、400 語未満で回答してください。段落は短くし、要点を拾い読みしやすくなる場合だけ箇条書きを使ってください。最初に結論を述べ、次に理由を説明し、最後に留意点を示してください。

編集、リライト、要約、顧客向けメッセージの作成では、文体の改善を求める前に、何を維持すべきかを伝えてください。分量を増やさずに文章を整えたい場合に有効です。

依頼された成果物の種類、長さ、構成、ジャンルを維持することを優先してください。修正自体をことさらに説明せず、文章のわかりやすさ、流れ、正確さを改善してください。明示的に求められない限り、新しい主張やセクションを追加したり、宣伝色を強めたりしないでください。

グラウンディング、出典の明示、検索の上限

根拠に基づく回答を求める場合は、出典の示し方をプロンプトに含めてください。何に裏付けが必要か、どの程度の根拠があれば十分か、根拠が不足しているときにどう対応するかを定義します。根拠が見つからないというだけで、「該当しない」と事実のように断定しないでください。詳細と例は、出典の表記ガイドを参照してください。

検索の上限の明示

検索の上限は、検索を打ち切るためのルールです。どの時点で回答に十分な根拠がそろったと判断するかをモデルに伝えます。

通常の質疑応答では、対象を絞り込める短いキーワードを使い、まず広い範囲を 1 回検索してください。上位の結果に、依頼の核心に答えるのに十分な根拠があり、その出典を示せるなら、再検索せずにその結果を使って回答してください。

追加の検索を行うのは、次のいずれかに該当する場合に限ります。
- 上位の結果だけでは、中心となる問いに答えられない場合
- 必要な事実、パラメーター、担当者、日付、ID、出典のいずれかが不足している場合
- ユーザーが網羅的な調査、比較、または漏れのない一覧を求めている場合
- 特定の文書、URL のリンク先、メール、会議の内容、記録、またはコードを読む必要がある場合
- 検索しないと、回答に含まれる重要な事実を裏付けられない場合

表現を整えたり、例を追加したり、本筋に関係しない細部に出典を付けたりするために再検索しないでください。一般的な表現にしても差し支えない箇所は、具体的な言い回しを裏付けるために再検索する必要はありません。

創作を伴う文章作成のルール

文章作成を依頼する際は、どの主張に出典が必要で、どの部分は自由に表現してよいかをモデルに伝えてください。スライド、製品発表のコピー、顧客向けの要約、説明用のトークスクリプト、経営層向けの短い紹介文、ストーリーの組み立てでは特に重要です。

スライド、経営層向けの短い紹介文、社外向けの案内文、共有用の要約、説明用のトークスクリプト、ストーリーの組み立てなど、創作を伴う依頼では、出典に裏付けられた事実と、自由に工夫できる表現を区別してください。

- 製品、顧客、指標、ロードマップ、日付、機能、競合について具体的に述べる場合は、検索で得た事実または提供された事実を使い、出典を示してください。
- 草案に説得力を持たせるために、具体的な名前、自社データに基づくとする主張、指標、ロードマップの進捗、顧客が得た成果、製品の機能を作り上げないでください。
- 引用できる根拠がほとんどない場合や、まったくない場合は、裏付けのない詳細を加えず、プレースホルダーを使うか、仮定であることを明示して、汎用的でも役に立つ草案を作成してください。

フロントエンド開発とビジュアルデザイン

フロントエンド開発では、UI の品質を高める具体的な指示の出し方について、指示の例を参照してください。製品とユーザーの背景、デザインシステムとの整合性、最初に表示される画面の使いやすさ、馴染みのある操作要素、考慮すべき画面状態、画面サイズに応じた動作を扱っています。また、ありきたりなヒーローセクション、カードの入れ子、装飾的なグラデーション、画面に露出した指示文、レイアウト崩れなど、UI の生成時に生じやすく、避けたいパターンも取り上げています。

モデル自身による成果物の検証

出力を検証できる場合は、検証に必要なツールを GPT-5.5 が使えるようにしてください。

コーディングエージェントには、具体的な検証コマンドを実行するよう求めてください。

変更を加えたら、実行できる検証のうち、変更内容に最も適したものを実行してください。
- 動作を変更した箇所に絞ったユニットテスト
- 該当する場合は型チェックまたは lint チェック
- 影響を受けるパッケージのビルドチェック
- すべてを検証する負荷が大きすぎる場合は、最小限のスモークテスト

検証を実行できない場合は、その理由を説明し、代わりにできる最善の確認方法を示してください。

視覚的な成果物については、レンダリング後の確認を求めてください。

成果物を確定する前にレンダリングしてください。レンダリング結果を見て、レイアウト、表示の見切れ、余白、内容の欠落、デザインの一貫性を確認してください。レンダリング結果が要件を満たすまで修正してください。

開発や計画のタスクでは、実装計画の各項目と要件の対応を追跡できるようにしてください。

実装計画には次の項目を含めてください。
- 要件と、各要件に対応する計画上の箇所
- 関連するリソース、ファイル、API、システムの具体的な名前
- 該当する場合は状態遷移またはデータの流れ
- 検証コマンドまたは確認方法
- 失敗時の動作
- プライバシーとセキュリティに関する考慮事項
- 実装に大きく影響する未解決の疑問点

フェーズパラメーター

GPT-5.4 以降では、長時間実行される、またはツールを多用する Responses API のワークフローで、アシスタントの出力項目の phase 値を使い、途中の進捗メッセージと最終回答を区別できます。GPT-5.5 でも同じ方法を使用します。

previous_response_id を使用すると、API がそれまでのアシスタントの状態を自動的に保持します。アプリケーションが次のリクエストでアシスタントの出力項目を手動で再送する場合は、各項目の元の phase 値を保持し、変更せずに渡してください。冒頭の進捗メッセージがある場合、ツールを繰り返し呼び出す場合、アシスタントが途中経過を伝えてから最終回答を返す場合に特に重要です。

アシスタントの出力項目を手動で再送する場合は、次のルールに従ってください。
- アシスタントの `phase` の値をそのまま保持してください。
- ユーザーに表示する途中の進捗メッセージには `phase: "commentary"` を使用してください。
- 最終回答には `phase: "final_answer"` を使用してください。
- ユーザーのメッセージに `phase` を追加しないでください。

推奨するプロンプト構成

複雑なプロンプトを作成する際は、次の構成を出発点にしてください。各セクションは短くまとめ、詳細を追加するのは、それによって振る舞いが変わる場合に限ってください。

役割：[1-2 sentences defining the model's function, context, and job]

# 個性
[tone, demeanor, and collaboration style]

# 目標
[user-visible outcome]

# 成功基準
[what must be true before the final answer]

# 制約
[policy, safety, business, evidence, and side-effect limits]

# 出力
[sections, length, and tone]

# 終了条件
[when to retry, fallback, abstain, ask, or stop]