GPT-6 の使い方

はじめに

GPT-5.6 は、複雑な本番ワークフローで得られる品質と処理効率の水準を引き上げます。特にトークン効率に優れています。フロントエンドのデザインでも、レイアウトや情報の視覚的な優先順位を適切に判断できるようになり、見栄えが向上しました。

GPT-5.6 では、モデルの命名規則も新しくなりました。gpt-5.6 は、最上位の性能を備えた gpt-5.6-sol にリクエストを送るエイリアスです。コストを抑えながら高い性能を得たい場合は gpt-5.6-terra、大量のリクエストを効率よく処理したい場合は gpt-5.6-luna を使用してください。

GPT-5.5 または GPT-5.4 から移行する場合は、まず現在の推論強度を引き継ぎ、代表的なタスクでその設定と 1 段階低い設定を比較してください。GPT-5.6 では、多くの場合、より少ないトークンで同等以上の品質を得られますが、最適な設定はワークロードによって異なります。

新機能と改善点

• プログラムによるツール呼び出し： GPT-5.6 は JavaScript を記述し、ホストされたランタイムで対象ツールを呼び出し、呼び出し間で結果を受け渡し、中間出力を処理できます。処理範囲が明確で、ツールを多用し、ステップごとにモデルが改めて判断する必要のないワークフローには、プログラムによるツール呼び出しを使用してください。この機能はゼロデータ保持（ZDR）に対応しており、コンテナの追加料金はかかりません。
• マルチエージェント［ベータ版］： マルチエージェントを使用すると、1 つの GPT-5.6 インスタンスが複数のサブエージェントの作業を並行して進め、その結果をまとめられます。Codex の Ultra モードと同様に、独立した作業に分割しやすい複雑なタスクでは、完了までの時間を短縮し、性能を向上させられます。マルチエージェントは Responses API のベータ機能として提供しており、開発者のフィードバックをもとに改善を続けています。
• 明示的なプロンプトキャッシュ： GPT-5.6 では、繰り返し使用するプロンプトの先頭部分のうち、どこまでを OpenAI がキャッシュするかを正確に指定できます。暗黙モードでは、引き続き自動キャッシュを利用できます。キャッシュへの書き込みには、キャッシュを使用しない入力の 1.25 倍の単価が適用されます。読み取りには引き続き割引単価が適用されます。詳しくは、プロンプトキャッシュの設定方法を参照してください。
• ターンをまたいだ推論の保持： GPT-5.6 は、利用可能な推論項目を後続のターンで再利用し、複数ターンにわたる応答の品質とキャッシュ効率を向上させられます。動作は reasoning.context で指定します。詳しくは、呼び出し間で推論を保持する方法を参照してください。
• 最大の推論強度： GPT-5.6 では、より広い探索と入念な検証が必要な難しいタスク向けに、推論強度 max を使用できます。現在 xhigh を使用している場合は、代表的なワークロードで両方の設定を比較してください。
• Pro モード： GPT-5.6 は、モデルによる処理を増やすことで難しいタスクでの信頼性を高め、最終回答を 1 つ返すことができます。レイテンシやトークン使用量よりも品質を重視する場合は、reasoning.mode: "pro" で有効にしてください。詳しくは、Pro モードの使い方を参照してください。
• トークン効率： GPT-5.6 は、より少ない出力トークンで最上位モデルに匹敵する性能を発揮します。
• フロントエンドデザイン： GPT-5.6 は、レイアウトや情報の視覚的な優先順位についてより的確に判断し、洗練された使いやすいウェブサイトやアプリケーションを作成できます。
• 意図の理解： GPT-5.6 は、ユーザーが本来達成したい目標や、どこまで作業してほしいかをコンテキストからより正確に読み取れるため、多くの場合、すべての手順を指定する必要はありません。引き続き、対象分野の背景、必ず守る制約、承認が必要な範囲、成功基準を明示してください。重要な点が曖昧な場合は、どのようなときに質問すべきかも伝えてください。
• 元の解像度での画像入力： GPT-5.6 は、画像の詳細レベルが original または auto の場合、元の画像サイズを保持します。ただし、幅または高さが 65,535 ピクセルを超える画像は、この上限に収まるように縮小します。それでも上限の 30,000 パッチを超える場合、API は画像をさらに縮小せず、入力を拒否します。大きな画像では、入力トークンが増え、レイテンシが高くなることがあります。詳しくは、画像の詳細レベルの選び方を参照してください。

安全対策

GPT-5.6 モデルでは、出力の生成と並行して、サイバーセキュリティや生物学の分野での悪用を検知する分類器がリアルタイムで動作します。そのため、安全対策によって一部のリクエストがブロックされたり、モデルが回答を拒否したりすることがあります。また、分類器が同期的に出力を確認する間、ストリーミングの途中で生成が数秒間停止し、応答に時間がかかることもあります。特に、防御目的の活動と攻撃目的の活動を初期段階で見分けにくいデュアルユースの分野では、正当な作業にも安全対策が適用される場合があります。

個々のエンドユーザーにアプリケーションを提供する場合は、ユーザーごとに一貫した、プライバシーを保護できる safety_identifier を各リクエストに含めてください。実装方法は、安全識別子の実装を参照してください。

OpenAI は、安全対策を意図的に回避しようとする試みにも対処できるよう、これらの対策を継続的に改善しています。同時に、コードレビュー、脆弱性の研究、パッチの開発、デバッグ、セキュリティ教育、防御目的のテストといった正当な作業に引き続きモデルを利用できるようにしています。

移行クイックスタート

Codex を使った移行

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

$openai-docs このプロジェクトを GPT-5.6 モデルファミリーに移行してください。

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

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

• ワークロードに応じて移行先のモデルを選んでください。最上位の性能が必要な場合は gpt-5.6-sol、性能とコストのバランスを重視する場合は gpt-5.6-terra、大量のリクエストを効率よく処理する場合は gpt-5.6-luna を使用してください。gpt-5.6 エイリアスはリクエストを gpt-5.6-sol に送ります。
• 推論、ツール呼び出し、複数ターンのやり取りを含むワークフローには Responses API を使用してください。
• reasoning.effort は目的に合わせて設定してください。GPT-5.6 では none、low、medium、high、xhigh、max を使用できます。
  • GPT-5.5 または GPT-5.4 から移行する場合は、現在の推論強度を基準とし、1 段階低い設定と比較してください。
  • none を使用している場合は、その設定でのレイテンシを基準としてください。推論やツールの使用が役立つワークフローでは、low も試してください。
  • 性能とレイテンシのバランスを取るには medium から始めてください。レイテンシを重視するワークロードには low を使用してください。
  • 推論を増やすことで品質が向上することを測定で確認できた場合は、high または xhigh を使用してください。
  • max は、品質を最優先する特に難しいワークロードに使用してください。max と xhigh を比較し、用途に合った品質、レイテンシ、コストのバランスを見つけてください。
• Pro モードを使用するには、選択した GPT-5.6 モデルのまま、Responses API で reasoning.mode を pro に設定してください。別の Pro モデルのスラッグには切り替えないでください。reasoning.effort は独立して設定できます。省略した場合、GPT-5.6 のデフォルトは標準モードでも Pro モードでも medium です。リクエストの例と料金の詳細は、推論モードを参照してください。
• 過去の推論が現在のタスクにどの程度関係するかに応じて、推論の保持方法を設定してください。GPT-5.6 モデルのデフォルトは all_turns、それ以前のモデルのデフォルトは current_turn です。
  • reasoning.context を省略するか auto に設定すると、GPT-5.6 のデフォルトである all_turns が使用されます。実際に適用されたモードは、レスポンスの reasoning.context フィールドで確認してください。
  • ターンが変わってもタスクの目標、前提、優先順位が変わらない場合は、reasoning.context を all_turns に設定してください。
  • all_turns を使用する場合は、次のリクエストに previous_response_id を指定し、以前のレスポンスの推論をモデルが利用できるようにしてください。
  • 履歴を手動で管理する場合は、過去のユーザー入力と、各レスポンスのすべての出力項目を保持し、再送してください。store: false またはゼロデータ保持を使用する場合は、API がデフォルトで返す暗号化された推論項目を再送してください。
  • 以前の推論が現在のタスクに関係しなくなった場合は、reasoning.context を current_turn に設定してください。
• プロンプトキャッシュの設定を確認してください。暗黙的なキャッシュを引き続き使用する場合、コードを変更する必要はありません。GPT-5.6 ではキャッシュへの書き込み単価が、キャッシュを使用しない入力の 1.25 倍になるため、cached_tokens と cache_write_tokens を追跡して実質的なコストを把握してください。明示的なブレークポイントまたは prompt_cache_options.mode: "explicit" を使用して不要な書き込みを避け、prompt_cache_retention を prompt_cache_options.ttl に置き換えてください。
• プログラムによるツール呼び出しを使用するには、programmatic_tool_calling ツールを追加し、対象ツールの allowed_callers で呼び出しを許可してください。アプリケーションを更新して、program 項目、プログラムが発行する関数呼び出し、program_output 項目を処理できるようにしてください。その際、各呼び出しの call_id と caller の対応関係を維持してください。リクエストの例と処理を継続する例は、プログラムによるツール呼び出しのガイドを参照してください。
  • プログラムによるツール呼び出し（PTC）を有効にしたワークフローを代表的なタスクでベンチマークしてください。タスクの成否、最終回答の網羅性、必要な根拠の有無、総トークン数、レイテンシ、コストを比較します。呼び出し回数、ターン数、中間出力が減っても、改善とみなせるのは、最終回答が引き続き必要な品質基準を満たす場合に限られます。

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

プロンプトの簡素化

重複する指示や例を削除し、ツールの説明を簡潔にすると、タスクの実行性能とトークン効率が向上することがあります。社内で実施したコーディングエージェントの評価の一部では、システムプロンプトを簡素化した構成で、評価スコアが約 10～15% 向上し、総トークン数が 41～66%、コストが 33～67% 減少しました。結果はワークロードによって異なります。これらの数値は目安とし、自分のアプリケーションを代表するタスクで変更の効果を検証してください。

重要な指示を残しながらプロンプトを簡素化するには、次の方法を使用してください。

• すでに機能しているプロンプトとツールの組み合わせから始めます。指示、例、ツールを一度に 1 グループずつ取り除き、その都度同じ評価を実行してください。
• 各指示は一度だけ記載してください。
• タスクに関係するツールだけをモデルに提供し、説明は簡潔かつ正確に記載してください。
• 例や文体の指示が製品要件を表している場合や、評価で確認された不足を補っている場合は、残してください。
• 実行開始時と、その後会話が長くなる過程の両方で、コンテキストの量を追跡してください。セッションが長くなるほど、繰り返し含まれるプロンプトやツールの説明が占める量は大きくなります。

自律的に進める範囲と承認が必要な範囲

GPT-5.6 は、複数ステップのタスクに自ら取り組み、完了まで作業を続けることができます。各リクエストがどこまでの操作を許可するかを定めてください。そうすれば、モデルは依頼の範囲内で安全に進められる作業を無用に中断せず、外部への操作、破壊的な操作、費用が発生する操作、作業範囲を広げる操作の前で停止できます。

通常は、次のような簡潔な方針で十分です。

回答、説明、レビュー、診断、計画の作成を求められた場合は、関連資料を確認し、結果を報告してください。変更を加えるのは、その実施も依頼された場合に限ります。

変更、構築、修正を求められた場合は、事前確認を求めず、依頼された範囲内でローカル環境に変更を加え、関連する非破壊的な検証を実行してください。

外部への書き込み、破壊的な操作、購入、作業範囲の大幅な拡大のいずれかを行う場合は、実行前に必ずユーザーの確認を得てください。

ファイルの読み取り、ログの確認、依頼範囲内のコード編集、テストの実行など、安全なローカル操作を具体的に挙げてください。方針は 1 か所にまとめ、各ルールは一度だけ記載します。「先に確認する」「変更を加えない」「承認を待つ」といった指示を繰り返すと、安全で想定どおりの操作についても、モデルが不要な承認を求めることがあります。

回答の長さと文体

GPT-5.6 は、デフォルトでは GPT-5.5 よりも簡潔に回答する傾向があります。移行する際は、「簡潔に答えてください」「短くまとめてください」といった一律の指示が引き続き役立つかを確認してください。タスクによっては不要で、回答が短くなりすぎることもあります。こうした指示によってアプリケーションに必要な出力が安定して得られる場合は、残してください。

リクエスト間で回答の詳しさを一貫して制御するには、text.verbosity でデフォルトの詳細度を設定し、タスク固有の要件はプロンプトで指定してください。

text.verbosity によるデフォルトの設定

リクエストのデフォルトの詳細度として low、medium、high のいずれかを選択してください。タスクに応じた長さ、構成、必須の内容はプロンプトで指定します。API の使用例は、text.verbosity の設定を参照してください。

短い回答に含める必須事項

短い回答が求められるタスクでは、必ず残す情報と省略してよい詳細を指定してください。たとえば、次のように指示できます。

まず結論を述べてください。結論を裏付けるために必要な根拠、判断に影響する注意点、次に取るべき行動を示してください。枝葉の説明や繰り返しは省いてください。

必要な事実、決定事項、注意点、今後の手順はすべて残してください。短くする際は、前置き、繰り返し、相手を安心させるための定型句、必須ではない背景説明から削ってください。

これにより、モデルはタスクの完了に必要な内容を優先して残し、重要度の低い詳細から削ることができます。

語調の指定

「親しみやすく」「共感を示して」といった表現は、解釈が分かれることがあります。回答をどの程度直接的に伝えるか、どのようなときにユーザーが報告した問題に言及するか、安心を促す言葉や結びの挨拶が適切かなど、製品に合った語調を具体的な書き方で示してください。

答えを端的に伝えてください。ユーザーから問題の報告があった場合は、まず報告された問題に具体的に触れてから、次の手順を示してください。相手を安心させる言葉は、状況に即している場合にだけ使ってください。型どおりの称賛や不要な結びの挨拶は省いてください。

Pro モード

品質を最優先する場合の Pro モードの選択

Pro モードは、1 つの最終回答を返す前にモデルがリクエストに対してより多くの処理を行う Responses API の実行モードです。難しいタスクでの信頼性が向上することがありますが、レイテンシは高くなります。使用量には、その処理で使用したトークンが合算され、選択したモデルの標準トークン単価で課金されます。

わずかな品質向上でも結果に大きく影響し、追加の処理が役立つほど難しいタスクでは、Pro モードを使用してください。たとえば、複雑な最適化、成果の価値が高いコーディングやレビュー、明確な評価基準に基づく詳細な分析などが該当します。定型的な作業、低レイテンシが求められる作業、大量のリクエストを処理する作業には標準モードが適しています。評価で Pro モードの明確な効果を確認できない場合も、標準モードを選んでください。

推論モードと推論強度は独立した設定です。Pro モードは、どの GPT-5.6 モデルでも、そのモデルがサポートするすべての推論強度で使用できます。まず、比較の基準となる標準モードと同じモデルと推論強度を使用してください。最も高い推論強度が常に最適だと考えず、代表的なタスクで各構成を比較してください。

API での Pro モードの設定

Pro モードは API リクエストで有効にしてください。プロンプトには、標準モードと同じく、得たい結果に焦点を当てて、目標、関連するコンテキスト、制約、必要な根拠、成功基準、出力形式を記載してください。モデルに「Pro モードを使ってください」「もっとよく考えてください」と指示したり、複数の回答候補を生成するよう求めたりする必要はありません。

たとえば、次のように指示できます。

このデータベース移行計画をレビューし、どの手順で何が起きるとデータの損失や長時間の停止につながるかを特定してください。指摘ごとに、該当する手順を引用し、影響の大きさと発生の可能性を見積もり、具体的な軽減策を提案してください。最も重要なリスクを 5 件、深刻度の高い順に示してください。

品質とコストの比較

同じ代表的なタスクで標準モードと Pro モードを比較してください。タスクの成否、回答の網羅性、必要な根拠の有無、総トークン数、レイテンシ、コストを測定します。追加の処理に見合うだけの品質や信頼性の向上が得られるタスクを選んで Pro モードを使用してください。

詳しくは、推論モードのガイドを参照してください。

プログラムによるツール呼び出し

タスクの特性に応じたプログラムによるツール呼び出しの選択

プログラムによるツール呼び出し（PTC）は、処理範囲が明確で、複数のツールの結果や大きな中間出力をコードで処理し、元の出力よりも大幅に小さい構造化された結果を返せるワークフローに最適です。フィルタリング、結合、順位付け、重複の除去、集計、検証など、手順をあらかじめ定められる処理に使用してください。

呼び出しが複数あること、並列実行できること、呼び出し間に依存関係があることだけでは、プログラムによるツール呼び出しを選ぶ理由にはなりません。次の場合は、PTC を使わずにツールを直接呼び出してください。

• 1 回の呼び出しで足りる場合
• 中間出力がもともと小さい場合
• 個々の結果によってモデルの次の判断が変わり得る場合
• 操作に承認が必要な場合
• 最終出力に引用元や元の形式の成果物を保持する必要がある場合

タスクに応じた呼び出し方法の指定

利用できるツールを示すだけでは、適切な呼び出し方法が選ばれるとは限りません。「プログラムによるツール呼び出しを効率よく使ってください」といった一般的な指示だけに頼ることも避けてください。直接呼び出す方法とプログラムから呼び出す方法の両方が使える場合は、次の点を明示してください。

• プログラムによるツール呼び出しを使う工程と、その範囲
• その工程で呼び出してよいツール
• 厳密な出力スキーマと必要な根拠
• 同時実行数と再試行回数の上限、および停止条件
• 引き続き直接呼び出しで行う作業

ツールの説明には、返されるフィールド、その型、エラー時の動作を記載してください。モデルがプログラムを書く前に戻り値の構造を把握できない場合は、ツールを直接呼び出し、結果を確認してからその使い方を判断できるようにしてください。

両方の呼び出し方法が必要な場合は、処理を引き継ぐ箇所を 1 つ明示してください。モデルが独自に呼び出し方法を切り替えたり、完了した作業を繰り返したりしないよう指示してください。

たとえば、次のように指示できます。

<tool_orchestration>
[bounded stage] ではプログラムによるツール呼び出しを使用し、呼び出すツールは [eligible tools] に限定してください。互いに独立した呼び出しは、安全に実行できる場合に並行して進めてください。ツールの入出力には、ドキュメントに記載されたフィールドだけを使用してください。

中間結果を処理して必要な情報に絞り込んでください。そのうえで、最終回答に必要な根拠を含め、[output schema] に厳密に従って出力してください。

[condition] を満たした時点で停止してください。一時的な障害が発生した場合、再試行は最大 [R] 回までとしてください。完了した呼び出しを繰り返したり、副作用を伴う操作を実行したりしないでください。それでも必要な結果がそろわない場合は、失敗したことを明示する構造化された結果を返してください。

[semantic judgment, approval, or final validation] では、ツールを直接呼び出してください。
</tool_orchestration>

最終回答の評価

program_output 項目とアシスタントの最終 message は別々の出力なので、必ず両方をテストしてください。プログラムが正しいレコードを返していても、メッセージでは必須フィールド、引用元、注意事項が抜ける可能性があります。

同じ代表的なタスクで、直接呼び出す場合とプログラムから呼び出す場合を比較してください。まず、最終回答が正しく、必要な内容を網羅し、求められた根拠を含んでいるかを確認します。そのうえで、総トークン数、レイテンシ、コスト、呼び出し回数、ターン数、再試行回数を比較してください。リソース使用量の削減を改善とみなせるのは、回答が引き続き既存の評価に合格する場合に限られます。

詳しくは、プログラムによるツール呼び出しのガイドを参照してください。