For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
メインナビゲーション

おすすめ

モデルの選び方

テキストとコード

プロンプト

推論

画像と動画

リアルタイムと音声

特化型モデル

API Dashboard
ChatGPT を試す

リーズニングモデル

リーズニングモデルの仕組みと効果的な使い方を学びます。

リーズニングモデル は、応答を生成する前に内部の推論トークンを使用します。これにより、モデルは計画を立て、ツールを効果的に使い、複数の選択肢を検討し、曖昧な状況を乗り越え、複数のステップを要する難しいタスクを解決できます。リーズニングモデルは、複雑な問題解決、コーディング、科学的推論、複数のステップからなるエージェント型ワークフローに特に適しています。また、OpenAI の軽量なコーディングエージェントである Codex CLI にも最適なモデルです。

ほとんどの推論ワークロードでは、まず gpt-6-astra を使用してください。コストを抑えるには gpt-5.6-terra を、コストとレイテンシを最小限に抑えるには gpt-5.6-luna を検討してください。GPT-5.6 モデルを使用している場合、pro オプションについては推論モードを参照してください。

リーズニングモデルは Responses API を使うことで、より高い能力を発揮します。Chat Completions API も引き続きサポートされていますが、 Responses を使用すると、 モデルの知的能力とパフォーマンスが向上します。

推論の利用開始

Responses API を呼び出し、リーズニングモデルと推論強度を指定します。

Responses API でのリーズニングモデルの使用
from openai import OpenAI

client = OpenAI()

prompt = """
Write a bash script that takes a matrix represented as a string with
format '[1,2],[3,4],[5,6]' and prints the transpose in the same format.
"""

response = client.responses.create(
    model="gpt-6-astra",
    reasoning={"effort": "low"},
    input=[{"role": "user", "content": prompt}],
)

print(response.output_text)

推論強度

reasoning.effort パラメーターは、タスクの実行時にどの程度深く考えるかをモデルに指示します。

サポートされる値はモデルによって異なり、none、minimal、low、medium、high、xhigh、max などがあります。推論強度を低くすると、速度とトークン使用量の削減が優先されます。高くすると、モデルがより十分に考え、質の高い応答を生成します。また、どの推論強度でも、モデルはタスクに応じて推論を調整します。単純なタスクでは使用するトークンを減らし、複雑なタスクではより深く考えます。

GPT-6 Astra は、推論強度の none をサポートしていません。 reasoning.effort（Responses）または reasoning_effort（Chat Completions）を none に設定すると、HTTP 400 が返されます。

Function Calling には Responses API を使用してください。 Chat Completions は、GPT-6 Astra での Function Calling をサポートしていません。

デフォルト値も一律ではなく、モデルによって異なります。gpt-5.5 のデフォルトの推論強度は medium です。gpt-5.5 の品質、信頼性、パフォーマンスを総合的にバランスよく引き出すには、この設定から始めるのが最適です。

推論強度最適な用途
none推論や連鎖的なツール呼び出しの恩恵がなく、レイテンシの短さが極めて重要なタスクに適しています。gpt-5.5 を使い、レイテンシを重視するユースケースでは、まず low を試し、必要に応じて none に切り替えることをお勧めします。

主なユースケースには、音声、高速な情報取得、分類があります。
lowレイテンシの増加を抑えながら、効率よく推論します。速度とコストを最適化しつつ、ツールの使用、計画、検索、複数のステップにわたる意思決定が必要なユースケースに最適です。

主なユースケースには、データ分析、下書き作成、実装中心のコーディング、カスタマーサポートやチャットアシスタントのワークフローがあります。
medium品質と信頼性が重要で、計画、複雑な推論、判断を伴うタスクに適しています。ほとんどのワークロードでのデフォルト設定であり、レイテンシ、パフォーマンス、コストのパレート曲線上でバランスのよい位置にあります。

主なユースケースには、エージェント型コーディング、リサーチ、スプレッドシートやスライドを使った作業、長期にわたる作業の委任があります。
high難しい推論、複雑なデバッグ、綿密な計画、レイテンシよりも品質と知的能力が重視される価値の高いタスクに適しています。複雑なワークフローやエージェント型タスクにお勧めします。

主なユースケースには、エージェント型コーディング、長期にわたるリサーチ、知識労働があります。タスクの複雑さに応じて、medium と high の両方を評価してください。
xhighdeep research、非同期ワークフロー、長時間の実行が必要なエージェント型タスクに適しています。レイテンシとコストの増加に見合う明確な利点が評価で確認できた場合にのみ使用してください。

主なユースケースには、セキュリティレビューとコードレビュー、企業の生産性向上、より深いリサーチタスク、難易度の高いコーディングワークフローがあります。
max最も複雑なタスクに対して、最大限の推論を行います。現在 xhigh を使用している場合は、max でパフォーマンスが向上するか評価してください。

レイテンシを重視するアプリケーションで、最初の可視トークンが出力されるまでの時間を短縮するには、深い推論を続ける前に短い前置きを生成するようモデルに指示してください。

これらの値の一部しかサポートしていないモデルもあるため、設定を選ぶ前に該当するモデルのページを確認してください。

推論モード

GPT-5.6 モデルは、Responses API で standard と pro の推論モードをサポートしています。デフォルトは standard です。モデルによる処理をより多く必要とし、レイテンシとトークン使用量の増加を許容できる難しいタスクでは、reasoning.mode を pro に設定してください。

推論モードと推論強度は独立しています。モードでは標準または pro での実行を選択し、reasoning.effort ではそのモード内でモデルが行う推論の量を制御します。reasoning.effort を省略すると、GPT-5.6 はどちらのモードでもデフォルトで medium を使用します。

pro 推論モードの使用
curl https://api.openai.com/v1/responses \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -d '{
    "model": "gpt-5.6",
    "reasoning": {
      "mode": "pro",
      "effort": "medium"
    },
    "input": "Review this database migration plan and identify potential failure modes."
  }'

Pro モードでは、最終回答を生成するためにモデルが行った処理を合算し、そのトークンに対して、選択したモデルの標準のトークン料金で課金します。Pro モードは標準モードよりもモデルの処理量が多く、トークン使用量とコストが増加します。既存の Pro モデル ID の動作と料金は変わりません。

推論の仕組み

リーズニングモデルは、入力トークンと出力トークンに加えて、 推論トークン を使用します。モデルは推論トークンを使って「考え」、プロンプトを分解し、応答を生成するための複数のアプローチを検討します。gpt-5.5 や gpt-5.4 などの OpenAI のリーズニングモデルは、推論と出力を交互に行う仕組みをサポートしています。これにより、推論の前や合間に可視出力トークンを生成したり、ツール呼び出しの合間に推論したりできます。

GPT-5.6 より前にリリースされたモデルでは、複数のステップからなる会話において、各ステップの入力トークンと出力トークンを引き継ぎ、以前のターンの推論は次の生成時のコンテキストに組み込まないのがデフォルトの動作です。一方、GPT-5.6 モデルは、以前のターンの利用可能な推論を組み込むのがデフォルトです。対応モデルでは、reasoning.context を使っていずれかの動作を選択できます。

現在のターンのコンテキストを使用する場合の推論トークン

推論トークンは API 経由では確認できませんが、 モデルのコンテキストウィンドウ内の容量を消費し、出力トークン として課金されます。

コストの制御

リーズニングモデルのコストを管理するには、 max_output_tokens パラメーターを使用して、 モデルが生成するトークンの総数を制限できます。これには、推論トークン、可視出力トークン、非表示の書式設定トークンが含まれます。 生成されたトークンが使用量や出力上限にどのように反映されるかについては、 出力トークン数を参照してください。

コンテキストウィンドウの管理

応答を生成する際は、コンテキストウィンドウに推論トークン用の容量を十分に確保することが重要です。問題の複雑さに応じて、モデルは数百から数万の推論トークンを生成することがあります。使用された推論トークンの正確な数は、レスポンスオブジェクトの usage オブジェクト内の output_tokens_details で確認できます。

{
  "usage": {
    "input_tokens": 75,
    "input_tokens_details": {
      "cached_tokens": 0
    },
    "output_tokens": 1186,
    "output_tokens_details": {
      "reasoning_tokens": 1024
    },
    "total_tokens": 1261
  }
}

コンテキストウィンドウの長さは、モデルのリファレンスページに記載されています。長さはモデルのスナップショットによって異なります。

推論用の容量の確保

生成されたトークンがコンテキストウィンドウの上限、または設定した max_output_tokens の値に達すると、status が incomplete となり、incomplete_details 内の reason が max_output_tokens に設定されたレスポンスが返されます。これは可視出力トークンが生成される前に起こる場合もあります。その場合、目に見える応答を受け取れなくても、入力トークンと推論トークンの料金が発生する可能性があります。

これを防ぐには、コンテキストウィンドウに十分な空き容量を確保するか、max_output_tokens の値を大きくしてください。OpenAI では、これらのモデルを試し始める際に、推論と出力のために少なくとも 25,000 トークンを確保することをお勧めします。プロンプトに必要な推論トークン数が把握できてきたら、それに応じて確保する容量を調整できます。

不完全なレスポンスへの対応
from openai import OpenAI

client = OpenAI()

prompt = """
Write a bash script that takes a matrix represented as a string with
format '[1,2],[3,4],[5,6]' and prints the transpose in the same format.
"""

response = client.responses.create(
    model="gpt-6-astra",
    reasoning={"effort": "medium"},
    input=[{"role": "user", "content": prompt}],
    max_output_tokens=300,
)

if (
    response.status == "incomplete"
    and response.incomplete_details.reason == "max_output_tokens"
):
    print("Ran out of tokens")
    if response.output_text:
        print("Partial output:", response.output_text)
    else:
        print("Ran out of tokens during reasoning")

呼び出し間での推論の保持

会話の状態と推論状態は、それぞれ異なる役割を持ちます。呼び出し間でメッセージを渡すと、モデルはユーザーに見える会話履歴を受け取ります。対応モデルでは、推論を保持することで、以前のターンの互換性のある推論項目も次のコンテキストに組み込めます。

推論の保持によって処理の継続性が得られますが、モデルの生の推論が公開されるわけではありません。推論項目の内容を直接確認することはできず、API はその推論テキストを返しません。利用可能な推論項目のうち、どれをモデルが使用できるかは、reasoning.context を設定して制御します。

GPT-5.6 モデルファミリーは、 all_turns をサポートし、デフォルトで使用します。 それ以前のモデルのデフォルトは current_turn です。 選択したモデルのデフォルトを使用するには、reasoning.context を省略するか、 auto に設定してください。

値動作
auto選択したモデルのデフォルトを使用します。reasoning.context を省略した場合も、auto と同じ動作になります。
current_turn現在のターンの推論を利用可能にしますが、以前のターンの推論は次の生成時のコンテキストに組み込みません。
all_turns以前のターンの利用可能な推論項目のうち、互換性のあるものを次の生成時のコンテキストに組み込みます。GPT-5.6 モデルはこの値をサポートしています。

レスポンスの reasoning.context フィールドには、実際に適用されたモードとして current_turn または all_turns が含まれます。モデルが使用したモードを確認するには、各レスポンスのこのフィールドを確認してください。この設定によって、まだ存在しない推論項目が新たに作成されることはありません。

all_turns が効果を持つのは、リクエストから以前のレスポンス項目にアクセスできる場合のみです。previous_response_id を使用するか、レスポンスを会話に関連付けるか、完全なレスポンス履歴を手動で再送してください。最初のリクエストでは以前の推論が存在しないため、current_turn と all_turns は同じように動作します。

保持された推論を再利用できるのは、同じモデルファミリー内のみです。たとえば、gpt-5.6-sol、gpt-5.6-terra、gpt-5.6-luna は互いの推論を再利用できますが、GPT-5.6 と GPT-5.5 のファミリー間では推論を引き継げません。

モデルファミリーを切り替えると、reasoning.context が all_turns であっても、API は互換性のない推論をモデルのコンテキストから除外します。

保存済みレスポンスを使った推論の継続

最小限の実装で状態を維持するには、previous_response_id を使用します。

前のレスポンスを利用した推論の保持
from openai import OpenAI

client = OpenAI()
model = "gpt-5.6"

first = client.responses.create(
    model=model,
    input="Inspect this repository and identify the likely bug.",
    reasoning={"context": "current_turn"},
)

second = client.responses.create(
    model=model,
    previous_response_id=first.id,
    input="Now patch the bug and explain the change.",
    reasoning={"context": "all_turns"},
)

print(second.output_text)

モデルがすでに必要としなくなった古いレスポンス項目を再送する場合は、current_turn を使用します。継続性を保つために、これらの推論項目を API ペイロードに残すことはできますが、サービスは新しいサンプルのコンテキストには組み込みません。これにより、長時間にわたるワークフローでモデルに渡すコンテキストを減らせます。

レスポンスを保存せずに行う推論の保持

ステートレスモードでレスポンスを作成すると、レスポンスの output 配列にある推論項目には、デフォルトで encrypted_content プロパティが含まれます。ステートレスモードは、store が false の場合、または組織がゼロデータ保持（ZDR）を使用している場合に適用されます。互換性のため、API では引き続き include に従来の値 reasoning.encrypted_content を指定できますが、必須ではありません。

次のリクエストでは、include を指定せずに暗号化された推論内容を取得できます。

curl https://api.openai.com/v1/responses \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -d '{
    "model": "gpt-6-astra",
    "store": false,
    "reasoning": {"effort": "medium"},
    "input": "What is the weather like today?",
    "tools": [ ... function config here ... ]
  }'

output 配列の推論項目には、暗号化された推論トークンを格納する encrypted_content プロパティが含まれます。これらのトークンは、後続の呼び出しに渡せます。

store: false で all_turns を使用するには、すべての出力項目を保持し、次のユーザーメッセージを追加して、履歴全体を再送します。

レスポンスを保存せずに行う推論の保持
from openai import OpenAI

client = OpenAI()
model = "gpt-5.6"

history = [
    {
        "role": "user",
        "content": "Inspect this repository and identify the likely bug.",
    }
]

first = client.responses.create(
    model=model,
    store=False,
    input=history,
    reasoning={"context": "current_turn"},
)

# Keep every output item, including encrypted reasoning and assistant phase.
history.extend(item.model_dump() for item in first.output)
history.append(
    {
        "role": "user",
        "content": "Now patch the bug and explain the change.",
    }
)

second = client.responses.create(
    model=model,
    store=False,
    input=history,
    reasoning={"context": "all_turns"},
)

print(second.output_text)

コンテキスト内での推論項目の保持

Responses API でリーズニングモデルを使って Function Calling を行う場合は、関数の出力に加えて、最後の関数呼び出しで返された推論項目もすべて渡すことを強くお勧めします。モデルが複数の関数を連続して呼び出す場合は、最後の user メッセージ以降の推論項目、関数呼び出し項目、関数呼び出しの出力項目をすべて渡してください。これにより、モデルは推論プロセスを継続し、トークンを最大限効率よく使いながら、より良い結果を生成できます。

最も簡単な方法は、前のレスポンスに含まれるすべての推論項目を次のレスポンスの生成時に渡すことです。システムが関数に関係のない推論項目を適切に無視し、関連する項目だけをコンテキストに保持します。過去のレスポンスの推論項目は、previous_response_id パラメータを使って渡すか、過去のレスポンスの output 項目をすべて、新しいレスポンスの input に手動で渡すことができます。

次のレスポンスに渡す前にコンテキストウィンドウの一部を切り詰めたり最適化したりする高度なユースケースでも、最後のユーザーメッセージから関数呼び出しの出力までのすべての項目は、変更せずに次のレスポンスに渡してください。これにより、モデルに必要なコンテキストがすべて揃います。

コンテキストを手動で管理する方法については、こちらのガイドをご覧ください。

会話途中での推論の変更

configuration_update を使用すると、難しい作業では推論強度を上げ、定型的な追加対応では下げることができます。リクエストレベルの reasoning.effort は変更せず、レスポンスとレスポンスの間に更新を追加します。これにより、プロンプトキャッシュに使う元のプロンプトのプレフィックスが保持されます。

構成の更新に対応しているのは、標準のシングルエージェントモードで動作する GPT-6 Astra（gpt-6-astra）のみです。 変更できるのは推論強度だけです。

HTTP の Responses リクエスト、または WebSocket の response.create リクエストの input 配列で、次のユーザーメッセージの前に以下の項目を追加します。

{
  "type": "configuration_update",
  "reasoning": {
    "effort": "high"
  }
}

たとえば、リクエストレベルの推論強度を low に設定して会話を開始した場合、この更新によって次のレスポンスから high が選択されます。別の更新で上書きされるまで、後続のレスポンスにも適用されます。

追加の依頼に対する推論強度の引き上げ
from openai import OpenAI

client = OpenAI()
model = "gpt-6-astra"

response = client.responses.create(
    model=model,
    reasoning={"effort": "low"},
    input="Draft a database migration plan.",
    store=True,
)
print(response.output_text)

response = client.responses.create(
    model=model,
    previous_response_id=response.id,
    reasoning={"effort": "low"},
    input=[
        {
            "type": "configuration_update",
            "reasoning": {"effort": "high"},
        },
        {
            "role": "user",
            "content": "Analyze the failure modes and propose rollback steps.",
        },
    ],
    store=True,
)
print(response.output_text)

previous_response_id を使用して更新を保持するか、会話履歴を手動で管理する場合は、元の位置に更新を含めて再送してください。レスポンスの reasoning.effort が示す値は、更新で選択された推論強度ではなく、引き続きリクエストレベルの設定です。

会話履歴内で、2 つの configuration_update 項目を連続して配置しないでください。API は隣接する更新を拒否します。

構成の更新を、自動コンパクションや自動切り詰めと併用しないでください。単独で使用する /responses/compact エンドポイントも、これらの更新を含む履歴を拒否します。

ただし、/responses リクエストに compaction_trigger 項目を含めることで、履歴のコンパクションを明示的に実行できます。コンパクション後は、次のユーザーメッセージの前に、必要な推論強度を指定した新しい configuration_update を追加してください。

通常のプロンプトキャッシュの要件は引き続き適用されます。レスポンスの生成中にユーザーの指示を送信するには、ターン途中の指示変更を使用してください。

推論の要約

モデルが生成する生の推論トークンは公開されませんが、summary パラメータを使用すると、モデルの推論の要約を確認できます。要約に対応しているリーズニングモデルについては、モデルのドキュメントをご覧ください。

推論の要約で使用できる設定は、モデルによって異なります。たとえば、コンピューターの使用に対応する OpenAI のモデルは concise の要約に対応し、o4-mini は detailed に対応しています。モデルで利用できる最も詳細な要約を取得するには、このパラメータの値を auto に設定します。現在、ほとんどのリーズニングモデルでは auto は detailed と同じですが、今後はより細かな設定が追加される可能性があります。

推論の要約は、reasoning 出力項目の summary 配列に含まれます。推論の要約を含めることを明示的に指定しない限り、この出力は含まれません。

以下の例では、推論の要約を含める API リクエストの作成方法を示します。

API レスポンスへの推論の要約の追加
from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-6-astra",
    input="What is the capital of France?",
    reasoning={"effort": "low", "summary": "auto"},
)

print(response.output)

この API リクエストは、アシスタントのメッセージと、そのレスポンスを生成する際にモデルが行った推論の要約の両方を含む出力配列を返します。

[
  {
    "id": "rs_6876cf02e0bc8192b74af0fb64b715ff06fa2fcced15a5ac",
    "type": "reasoning",
    "summary": [
      {
        "type": "summary_text",
        "text": "**Answering a simple question**\n\nI\u2019m looking at a straightforward question: the capital of France is Paris. It\u2019s a well-known fact, and I want to keep it brief and to the point. Paris is known for its history, art, and culture, so it might be nice to add just a hint of that charm. But mostly, I\u2019ll aim to focus on delivering a clear and direct answer, ensuring the user gets what they\u2019re looking for without any extra fluff."
      }
    ]
  },
  {
    "id": "msg_6876cf054f58819284ecc1058131305506fa2fcced15a5ac",
    "type": "message",
    "status": "completed",
    "content": [
      {
        "type": "output_text",
        "annotations": [],
        "logprobs": [],
        "text": "The capital of France is Paris."
      }
    ],
    "role": "assistant"
  }
]

最新のリーズニングモデルで要約機能を使用するには、安全なデプロイを確保するため、 組織の確認 を完了する必要がある場合があります。 プラットフォームの設定ページ から確認手続きを開始してください。

phase パラメータ

Responses API で GPT-5.5 や GPT-5.4 を使用し、処理が長時間にわたる場合やツールを多用する場合は、アシスタントメッセージの phase フィールドを使用して、処理の早期終了などの誤動作を防いでください。 phase は API 上では省略可能ですが、OpenAI は使用を推奨しています。ツール呼び出し前の前置きなど、アシスタントによる途中経過の報告には phase: "commentary" を使用し、完成した回答には phase: "final_answer" を使用します。ユーザーメッセージには phase を追加しないでください。 previous_response_id を使用すると、それまでのアシスタントの状態が保持されるため、通常はこれが最も簡単な方法です。アシスタントの履歴を手動で再送する場合は、それぞれの元の phase の値を保持してください。 これらのワークフローでは、phase が欠落したり削除されたりすると、前置きが最終回答として扱われることがあります。モデル固有のプロンプトのガイダンスについては、GPT-5.5 のプロンプトをご覧ください。

アシスタントの phase 値の受け渡し

アシスタントの phase 値の受け渡し
from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-6-astra",
    input=[
        {
            "role": "assistant",
            "phase": "commentary",
            "content": "I’ll inspect the logs and then summarize root cause and remediation.",
        },
        {
            "role": "assistant",
            "phase": "final_answer",
            "content": "Root cause: cache invalidation race.",
        },
        {
            "role": "user",
            "content": "Great—now give me a rollout-safe fix plan.",
        },
    ],
)

print(response.output_text)

プロンプト作成のヒント

リーズニングモデルにプロンプトを与える際は、以下の違いを考慮してください。推論機能を備えた GPT-5 モデルでは、通常、途中の手順を一つひとつ指定せず、明確な目標、厳密な制約、明示的な出力要件を与えることで、最も良い結果が得られます。

  • タスク、制約、希望する出力形式をモデルに伝えてください。
  • reasoning.effort は調整用の設定として扱い、品質を回復するための主な手段にはしないでください。
  • エージェント型のワークフローやリサーチを多く伴うワークフローでは、完了の条件と、モデルが作業結果を検証する方法を定義してください。

リーズニングモデルを使用する際のベストプラクティスについては、こちらのガイドをご覧ください。

プロンプトの例

OpenAI の o シリーズモデルは、複雑なアルゴリズムの実装やコードの生成ができます。このプロンプトでは、特定の条件に基づいて React コンポーネントをリファクタリングするよう o1 に依頼します。

コードのリファクタリング
import OpenAI from "openai";

const openai = new OpenAI();

const prompt = `
Instructions:
- Given the React component below, change it so that nonfiction books have red
  text.
- Return only the code in your reply
- Do not include any additional formatting, such as markdown code blocks
- For formatting, use four space tabs, and do not allow any lines of code to
  exceed 80 columns

const books = [
  { title: 'Dune', category: 'fiction', id: 1 },
  { title: 'Frankenstein', category: 'fiction', id: 2 },
  { title: 'Moneyball', category: 'nonfiction', id: 3 },
];

export default function BookList() {
  const listItems = books.map(book =>
    <li>
      {book.title}
    </li>
  );

  return (
    <ul>{listItems}</ul>
  );
}
`.trim();

const response = await openai.responses.create({
  model: "gpt-6-astra",
  input: [
    {
      role: "user",
      content: prompt,
    },
  ],
});

console.log(response.output_text);

ユースケースの例

リーズニングモデルを実際のユースケースに活用する例は、Cookbookで紹介しています。

推論によるデータ検証

合成医療データセットを評価し、不整合がないか確認します。
推論による手順の生成

ヘルプセンターの記事を使って、エージェントが実行できるアクションを生成します。