OpenAI(GPT 系)特化プロンプティングガイド

この記事の目的

OpenAI の GPT ファミリーに対して、公式ガイドが推奨する具体的なプロンプトの書き方を根拠を持って選べるようになります。汎用の基礎技法と上級パターンがモデル中立の原理を扱うのに対し、本記事は「developer メッセージの指示階層・推論内蔵モデルへの書き分け・Structured Outputs」といった、このモデル固有の作法に踏み込みます。

本記事は鮮度管理型です。 モデル世代・機能名(効果や API 仕様)は変化が速いため、本文冒頭の最終確認日と各公式ページを必ず確認してください。

対象読者

• GPT 系を使ったアプリ・エージェントを実装し、そのモデルに合わせてプロンプト品質を上げたいエンジニア
• 推論内蔵モデル(reasoning)と軽量モデルで書き方を使い分けたい、または世代交代に追従したいエンジニア

前提知識

• プロンプトエンジニアリングの基礎技法 — 汎用技法(本記事はその OpenAI 具体)
• 主要 LLM の全体像(モデルカタログ) — GPT ファミリーの顔ぶれ・選び方

本文

最終確認日: 2026-10-03 — Structured Outputs の例外処理と Sol / Luna の EU 条件を確認しました。GPT-6 内の設定差・キャッシュ・設定更新・対象 ID 別の退役予定は 2026-09-28、非同期ツールは 2026-09-10 の確認です。従来の設計指針は各参考資料の確認日を参照し、未取得の現行原文は TODO に分けます。

部分再確認: 2026-10-08 — GPT-6.1 Sol の effort・API 制約と旧 gpt-6-sol / gpt-6-luna との違いを確認しました。EU 条件・共通プロンプト指針・全モデルの互換性を一括再確認したものではありません。

概要: 汎用記事との分担

Claude・Gemini との横並び比較と移行は モデル間の違いと移行 が扱います。

モデルファミリーの前提(プロンプトに効く差分だけ)

顔ぶれ・価格・選び方は モデルカタログ が正本です。プロンプト設計に効く差分だけを押さえます(従来の設計指針は 2026-08、退役日程は 2026-09-28 確認)。

• 推論は本体に統合された: かつての推論特化「o シリーズ」は縮小し、GPT 本体の reasoning effort で思考量を制御する形が標準です。2026-09-28 確認の API 退役表では o4-mini の対象 ID は 2026-10-23、o3 / o3-pro の対象 ID は 2026-12-11 終了予定です。モデル別の日程と移行先は モデルカタログ と公式退役表で照合します
• モデルは「同僚」で例える: 公式は推論内蔵モデルを「ゴールを渡せば任せられる上級同僚」、軽量モデルを「明示的な指示で最も動く新人同僚」と説明します。書き方の粒度を変える指針です
• 一部の作法は不要になった: 出力スキーマの強い言い回しや「ステップバイステップで考えて」は、Structured Outputs と推論内蔵化により不要・逆効果になりました(後述)

Astra へ移行する場合

2026-09-28 確認の gpt-6-astra では次を確認します。他モデルの有効な設定まで一律に削除するのではなく、モデル別にリクエストを組み立てます。

委任の条件、必要な検証の範囲、完了基準も明示します。自律化の指示は、実行権限や必要な承認を省略する根拠にはしません。

旧 gpt-6-sol / gpt-6-luna は none / low / medium / high / xhigh / max に対応し、既定は medium です。Chat Completions の関数呼出し(function calling)は none の場合に限られるため、推論を有効にしたツール処理には Responses API を使います。Astra の none 非対応と区別して実装します。

2026-09-29 公開の gpt-6.1-sol は low / medium / high / xhigh / max に対応し、既定は medium、none / minimal は非対応です。ツール呼出しは Responses API のみで、Chat Completions はツールなしに限られます。旧 Sol での none と関数呼出しの組合せを 6.1 Sol に移植しません(2026-10-08 確認)。

旧 gpt-6-sol / gpt-6-luna の EU データレジデンシーは、2026-10-03 に取得したモデルページと Your data が Standard / Flex / Batch 対応を案内します。Pricing の当時の取得本文では、以前の Standard 限定記述の残存を確認できませんでした。取得範囲と過去の観測は 調査メモ  に記録しました。利用前に対象モデル・アカウント・プロジェクト・API の適格条件を Your data と管理画面/公式サポートで確認し、全アカウントでの利用を保証しません。Fast の EU 非対応と、地域内保存(regional storage)・地域内処理(regional processing)は別の条件です。保存対応だけで処理対応とは判断しません。6.1 Sol の適格条件も対象モデルの資料で個別に確認します。

メッセージ構造と指示階層

GPT 系のプロンプトは役割の階層で設計します。

• 役割は developer / user / assistant: developer(アプリ開発者の指示)は user(エンドユーザーの指示)より優先されます。推論モデル応答の前に中間の思考(推論トークン)を生成してから答える LLM。多段推論・検証可能な問題で精度が上がる一方、単純タスクでは遅く高くなる(overthinking)。思考量は努力パラメータ等で制御する。では developer メッセージが従来の system メッセージを置き換えます(Responses API では instructions パラメータが input 内のプロンプトより優先)
• 指示は重要度で階層化する: 上から (1) 安全・プライバシー等の譲れない制約、(2) 必須の出力項目・真の不変条件、(3) 判断が要る場面の決定ルール、(4) 人格・文体(最下位)。ユーザー指示は文体は上書きできても上位の制約は拘束されたままです(この 4 層の定式化は 2026-07 確認分。現行ガイドの原文は再確認できていません。後述の TODO 参照)
• 矛盾・曖昧を残さない: GPT-5 系は矛盾した指示の解消に推論トークン推論モデルが答える前に生成する中間の思考のトークン。通常コストとして課金され、生成時間を延ばす。「考える時間」はタダではなく、思考量とコスト・レイテンシは直結する。を浪費し、特に脆弱です。判断が要る箇所への ALWAYS / NEVER の乱用も避け、真の不変条件にだけ使います

構造化の推奨記法

• Markdown 見出しと XML タグの併用: 節分けには Markdown 見出し・リスト、内容ブロックの境界明示には XML タグ、というように使い分けます(Claude ほど XML を前面に出さない立場です)
• 既定は素のパラグラフ: 見出し・太字・箇条書きは控えめに。入れ子の箇条書きは避け、リストはフラットに保ちます。整形は理解のためであり、過剰な装飾は逆効果です
• Markdown は意味的に正しい箇所だけ: ファイル名・関数名などはバッククォートで囲みます。プロンプトを JSON で組み立てる方式は積極推奨されていません

例示(few-shot)

• zero-shot を先に、足りなければ few-shot: 推論内蔵モデルは例なしで足りることが多く、まず例なしで試します
• 例と指示を厳密に整合させる: 例が指示と矛盾すると、特に推論モデルで害になります(前述の矛盾脆弱性)
• 軽量モデルには「流れ」を見せる: 小型モデル(mini / nano)には最終フォーマットだけでなく、正しい処理の流れを 1 例示すのが効きます

思考の制御: reasoning effort と reasoning.mode

GPT-5.x は推論を内蔵し、reasoning effort で思考とツール使用LLM が外部機能の呼び出し要求を出し、アプリケーションまたはプロバイダーの実行基盤が検証・権限に従って実行し、結果をモデルへ返す仕組み。実行主体と制御点を区別する Agent の中核機構。の労力を制御します(2026-08 時点)。

• effort は none / minimal / low / medium / high / xhigh / max(集合はモデル依存。GPT-5.6 世代は minimal 非対応で none / low / medium / high / xhigh / max)。既定は世代で変わります(例: GPT-5.6 / 5.5 は medium、GPT-5.2 は none)。移行時は先行世代のプロファイルに合わせて明示ピン留めします
• 高コンピュート実行は reasoning.mode で指定する: かつての専用 pro モデル(o3-pro / gpt-5-pro)は、reasoning.mode(standard / pro)のパラメータ指定に置き換わりました(公式の移行先は gpt-5.6-sol + reasoning.mode: "pro")。effort とは独立したパラメータで、数分かけてでも最高品質の回答が要る難問にだけ使います
• effort は品質の主ノブではなく最後の微調整ノブ: 「上げれば品質が上がる」は誤りです。矛盾した指示・弱い停止条件・自由なツールアクセスがあると、高 effort は過剰思考(overthinking)や無駄な探索、品質の退行を招きます。上げるのは評価で正当化できるときだけです(この警告の定式化は 2026-07 確認分。max 追加後の現行原文は再確認できていません。後述の TODO 参照)
• 推論内蔵モデルには手順を細かく書かない: 「ステップバイステップで考えて」は不要です。ゴール・強い制約・明示的な出力契約を与え、中間手順は内部推論に任せます(上級パターンの思考制御の GPT 版)
• 生の思考は API から見えない: 推論トークンは可視化されません。ステートレスで推論を跨ぐには暗号化済み推論内容を差し戻す必要があります

出力の制御: Structured Outputs

• 機械処理する出力は Structured Outputs を使う: 対応モデル・対応 JSON Schema・strict: true などの条件を満たす正常完了した構造化応答で形式を保証します。拒否や打切りの応答までスキーマに従う保証ではなく、業務上の正しさも別途検証します。JSON モードの JSON 妥当性と区別し、基本設計は 構造化出力 を参照します
• 状態を先に分岐する: Responses API では出力中の refusal は停止・通知し、status == "incomplete" は incomplete_details.reason を確認します。max_output_tokens は予算内・回数上限内の再生成を検討できますが、安全制約や理由不明の打切りは停止します。strict: true に非対応スキーマを渡した設定エラーは設定訂正へ渡し、正常完了だけを構造・業務検証へ進めます
• 出力スキーマをプロンプト本文から外す: 「一貫した書式のための強い言い回し」は不要になりました。スキーマは Structured Outputs 側に置きます
• 応答の長さは verbosity で制御する: 最終回答の長さは推論品質とは別物として、verbosity(low / medium / high)や語数・セクション数の明示で制御します
• prefill は前提にしない: OpenAI は Anthropic 型の自由な応答書き出し指定(prefill)を主要技法として扱いません。出力形式は Structured Outputs、前置き除去は指示で行います

長文・長コンテキスト

• 必要な文脈は検索で供給する: 長大な資料を丸ごと詰めるより、RAG外部の知識ソースを検索し、結果を LLM の入力に加えて回答の根拠にする手法。検索の判断を Agent に任せる構成は Agentic RAG と呼ばれる。 やビルトインの file search で必要箇所を供給します
• 長時間タスクはコンパクションコンテキスト上限に近づいた際に、会話履歴を要約・圧縮して容量を確保する仕組み。トリガ設計と「必ず残す情報」の定義が要で、決定の消失は議論のループを招く。で状態を圧縮する: Responses API のコンパクションで、圧縮後もプロンプトが機能的に同一であるように保ちます(コンテキスト管理の一般設計は 圧縮と隔離)
• 検索バジェットと停止規則を設ける: 「今の証拠でユーザーの要求に答えられるか」を各段で問わせ、無駄な探索の暴走を防ぎます

ツール使用・エージェント文脈

• ツール固有の指示はツール記述(description)に置く: 何をする・いつ使う・必須入力・副作用・リトライ安全性・よくあるエラーを、プロンプト本文でなくツールの description に 1〜2 文で書きます
• 独立したステップは並列化する: 独立した取得・参照は並列ツール呼び出しでレイテンシを削ります
• 永続性と早期停止のバランスを明示する: 「別のツール呼び出しで正確性が上がるなら早く止めない」と「成功基準を満たしたら止める」を両方指定します
• 推奨は Responses API + Agents SDK: エージェント/ツール連携はこの構成が公式の推奨です

非同期ツールと実行中の指示変更

Astra の非同期ツール使用(async tool calling)では、function / custom tool に async: true を指定し、アプリが処理を実行して元の call_id に結果を返します。モデルは待機中にも独立した作業を進められます。WebSocket 経由の実行中の指示変更(mid-turn steering)を使う場合は、処理中のツールと遅れて届く結果を管理し、変更後の目的に不要な結果を新しい判断へ混ぜません。実行の永続化や外部操作の取り消しを API が保証するという意味ではありません。設計例は ストリーミングと Agent UX を参照してください。

キャッシュを保った設定変更

GPT-5.6 以降は prompt_cache_options.ttl: "30m" を使います。キャッシュ境界までの書込量を usage.input_tokens_details.cache_write_tokens、読取量を cached_tokens で分けて記録します。30 分は最短保持期間で、必ず 30 分後に削除されるという意味ではありません。

GPT-6 ファミリーの standard・単一エージェントのリクエストでは、元の request-level reasoning.effort を変えず、{"type":"configuration_update","reasoning":{"effort":"high"}} を input の次の user メッセージより前に追記して、以後の effort を変えられます。pro mode・複数エージェントには非対応です。連続する configuration_update、自動 compaction / truncation、単独の /responses/compact との併用もできません。これは許可された設定更新の仕組みで、過去の system / developer 本文や動的な日付を書き換えてもキャッシュが残るという仕様ではありません。

明示的に履歴を圧縮する場合は、/responses のリクエストに compaction_trigger item を含められます。圧縮後は次の user メッセージより前に、希望する effort の configuration_update を再追加します。自動圧縮との非互換と、明示圧縮後の再設定を分けて実装します。

世代交代で見直すこと

GPT-5.6 のような新世代はドロップイン置換ではなく、再チューニング前提です(2026-08 時点)。

• 最小プロンプトから始める: 製品契約を保つ最小のプロンプトから始め、代表例で effort・verbosity・ツール記述・出力形式を微調整します。旧プロンプトスタックを丸ごと持ち込まないこと
• 移行時のプロンプト掃除: 現在日付を消す(モデルが UTC 日付を把握済み)、出力スキーマを消して Structured Outputs へ、キャッシュ最適化(静的を先・動的を後)
• 既定 effort の変化に注意: 既定の reasoning effort は世代で変わります(例: 5.2 は none、5.5 / 5.6 は medium)。無指定のままだとレイテンシ・コストのプロファイルが変わります
• 逐語的な解釈: 新世代はプロンプトを字義通り・網羅的に解釈します。既定文体は簡潔・直接なので、温かみや特定の人格が要るなら明示します

移行作業の運用(回帰評価・段階リリース)は バージョニングとモデル更新追従 が正本です。

効かない・不要になった俗説

以下は OpenAI 公式が非推奨・不要とするものです(2026-08 時点)。

• 推論モデルへの「ステップバイステップで考えて」: 内部で推論するため不要
• 一貫した JSON のための「強い言い回し」の書式指示: 正常完了時の形式は対応スキーマと strict 設定で制御します。拒否・打切りへの処理は別に必要です
• 出力スキーマをプロンプト本文に書き込む: 外して Structured Outputs へ
• 現在日付をプロンプトに入れる: 新世代は UTC 日付を把握済み
• 判断が要る箇所への ALWAYS / NEVER 乱用: 真の不変条件にだけ使う
• reasoning effort を上げれば品質が上がるという思い込み: 過剰思考で退行しうる
• 入れ子箇条書き・重い整形での構造化: フラットなリスト・素のパラグラフが既定
• 再利用プロンプトオブジェクト(v1/prompts)への依存: 非推奨化(v1/prompts は 2026-11-30 停止予定)。instructions / input を直接 Responses API に渡す

実務での注意点

アンチパターン

チェックリスト

関連トピック

• プロンプトエンジニアリングの基礎技法 — 汎用技法(本記事の前提)
• プロンプトエンジニアリングの上級パターン — なぜ効くかの中立な原理
• モデル間の違いと移行(横断比較) — Claude・Gemini との横並びと乗り換え
• Claude 特化プロンプティングガイド — 対になるベンダー別ガイド
• Gemini 特化プロンプティングガイド — 対になるベンダー別ガイド
• モデル選定ガイド / モデルカタログ — GPT 系の選び方
• 構造化出力 — Structured Outputs の設計
• バージョニングとモデル更新追従 — 世代交代への追従運用

参考資料

• GPT-6.1 Sol  — effort・API 制約(アクセス日: 2026-10-08)
• OpenAI API Changelog  — GPT-6.1 Sol の公開日(アクセス日: 2026-10-08)
• GPT-6 Sol  — 旧モデルの effort・API 制約(アクセス日: 2026-10-08。EU 条件は 2026-10-03 の確認範囲)
• Luna  — 旧モデルの effort・API 制約(アクセス日: 2026-10-08。EU 条件は 2026-10-03 の確認範囲)
• 最新モデルガイド  — 世代内の effort・API 制約の違い / 移行・設定の条件 / 最新世代への移行考慮点(アクセス日: 2026-09-28)
• Reasoning models  — GPT-6 の設定更新・保持条件・対象 ID 別の終了予定 / compaction_trigger と圧縮後の configuration_update 再追加 / 推論モデルへの書き方・effort・reasoning.mode(アクセス日: 2026-09-28)
• Prompt caching  — GPT-6 の設定更新・保持条件・対象 ID 別の終了予定 / 世代別の保持・課金・設定更新(アクセス日: 2026-09-28)
• Deprecations  — GPT-6 の設定更新・保持条件・対象 ID 別の終了予定(アクセス日: 2026-09-28)
• Astra model  — 移行・設定の条件(アクセス日: 2026-09-10)
• Async tool calling  — 非同期処理の契約(アクセス日: 2026-09-10)
• Mid-turn steering  — 非同期処理の契約(アクセス日: 2026-09-10)
• Prompt engineering(OpenAI)  — 構造化・階層・整形の指針(アクセス日: 2026-07-08)
• Prompt guidance(OpenAI)  — 構造化・階層・整形の指針(アクセス日: 2026-07-08)
• Reasoning best practices(OpenAI)  — 推論モデルへの書き方・effort・reasoning.mode(アクセス日: 2026-07-08)
• Structured Outputs(OpenAI)  — strict設定と正常完了・拒否・打切り・設定エラーの区別(アクセス日: 2026-10-03)
• Your data  — EU条件の参照先と取得範囲(アクセス日: 2026-10-03)
• Pricing  — EU条件の参照先と取得範囲(アクセス日: 2026-10-03)
• GPT-5 prompting guide(OpenAI Cookbook)  — エージェント・ツール文脈の実例(アクセス日: 2026-07-08)

TODO・未確認事項

変わりやすい項目(定点観測)