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

おすすめ

モデルの選び方

テキストとコード

プロンプトの書き方

推論

画像

リアルタイム処理とオーディオ

特化型モデル

API ダッシュボード
ChatGPT を試す

リーズニングモデル

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

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

ほとんどの推論ワークロードでは、まず gpt-6-astra をお試しください。コストを抑えるには gpt-5.6-terra を、コストとレイテンシを最小限に抑えるには gpt-5.6-luna を検討してください。GPT-5.6 または GPT-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 が返ります。GPT-6.1 Sol は none と minimal をサポートしておらず、デフォルトは medium です。

Function Calling には Responses API を使ってください。Chat Completions では、GPT-6 Astra および GPT-6.1 Sol での Function Calling はサポートされていません。

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

推論強度 適した用途
none レイテンシが最優先で、推論や複数のツールを連続して呼び出す利点がないタスクに適しています。レイテンシが重要な用途で gpt-5.5 を使う場合は、まず low を試し、必要に応じて none に切り替えることをお勧めします。

代表的な用途には、音声、高速な情報取得、分類があります。
low レイテンシの増加を抑えながら効率的に推論できます。ツールの使用、計画、検索、段階的な意思決定が必要で、速度とコストも重視する用途に最適です。

代表的な用途には、データ分析、草案の作成、実装を中心としたコーディング、カスタマーサポートやチャットアシスタントのワークフローがあります。
medium 品質と信頼性が重要で、計画、複雑な推論、判断を伴うタスクに適しています。ほとんどのワークロードのデフォルト設定で、レイテンシ、パフォーマンス、コストのパレート曲線上でバランスの取れた選択肢です。

代表的な用途には、エージェント型コーディング、調査、スプレッドシートやスライドを使った作業、長期にわたる作業の委任があります。
high 難度の高い推論、複雑なデバッグ、綿密な計画のほか、レイテンシよりも品質やモデルの問題解決能力を重視する価値の高いタスクに適しています。複雑なワークフローやエージェントが実行するタスクにお勧めします。

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

代表的な用途には、セキュリティレビューやコードレビュー、企業の生産性向上、掘り下げた調査、難度の高いコーディングワークフローがあります。
max 最も複雑なタスクに最大限の推論を適用します。現在 xhigh を使っている場合は、max でより良い結果が得られるか評価してください。

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

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

推論モード

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

推論モードと推論強度は独立した設定です。モードでは標準または Pro の実行方式を選び、reasoning.effort では選んだモードでモデルがどの程度深く推論するかを調整します。reasoning.effort を省略すると、GPT-5.6 はどちらのモードでも medium を使います。GPT-6.1 Sol、GPT-6 Sol、GPT-6 Luna のデフォルトの推論強度も medium です。

Pro 推論モードの使用
curl https://api.openai.com/v1/responses \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -d '{
    "model": "gpt-6.1-sol",
    "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 などのリーズニングモデルでは、推論と出力を交互に行えます。推論を始める前や推論の合間にユーザーに見える出力トークンを生成したり、ツール呼び出しの合間に推論したりできます。

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 です。GPT-6.1 Sol も all_turns をサポートしています。選択したモデルのデフォルトを使うには、reasoning.context を省略するか、auto に設定してください。

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

応答の 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-6.1-sol"

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 は従来どおり reasoning.encrypted_content を include の値として受け付けますが、この指定は必須ではありません。

次のリクエストでは、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 プロパティが含まれます。このプロパティには暗号化された推論トークンが格納され、以降の呼び出しに渡せます。

all_turns を store: false と組み合わせて使うには、すべての出力項目を保持し、次のユーザーメッセージを追加して、履歴全体を再送します。

応答を保存せずに推論を保持する方法
from openai import OpenAI

client = OpenAI()
model = "gpt-6.1-sol"

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.to_dict() 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)

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

リーズニングモデルで Function Calling を Responses API から使う場合は、関数呼び出しとともに返された推論項目を、ツールの出力と一緒にモデルに渡してください。これにより、モデルはツール呼び出し後も推論を続けられます。

previous_response_id を使うと、推論項目を次のリクエストに引き継げます。会話履歴を自分で管理する場合は、元の入力と、各応答に含まれるすべての出力項目を、次のリクエストの入力に含めてください。これらの項目は元の順序を保ち、新しい項目は末尾に追加してください。

新しいフロンティアモデルでは、推論項目より前の履歴を変更すると、API がその推論をコンテキストから除外する場合があります。指示やツールの出力を変更する方法、長い会話を管理する方法については、プロンプトの先頭部分を変更せずに保持する方法を参照してください。

会話中の推論強度の変更

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

GPT-6 以降の対応モデルでは、標準モードで単一のエージェントを使う場合に、推論強度と応答形式を更新できます。

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

{
  "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 には、更新で選択した推論強度ではなく、引き続きリクエストレベルの設定が表示されます。

reasoning.effort と text.format は、同じ configuration_update 項目で設定できます。どちらか一方だけを更新した場合、もう一方の設定は保持されます。

設定の更新と自動コンパクションまたは自動切り詰めを併用しないでください。単独で使う /responses/compact エンドポイントも、これらの更新項目を含む履歴を受け付けません。

compaction_trigger 項目を /responses リクエストに含めれば、履歴のコンパクションを明示的に実行できます。コンパクションの後は、次のユーザーメッセージの前に新しい configuration_update を追加してください。変更した設定の値をすべて再指定してください。応答形式も変更した場合は、その形式も再指定してください。

プロンプトキャッシュには通常どおりの要件が適用されます。応答の生成中にユーザーの指示を送信するには、ターン途中での指示を使ってください。

推論の要約

モデルが生成した推論トークンそのものは公開されませんが、summary パラメーターを使うと、モデルの推論の要約を確認できます。要約をサポートしているリーズニングモデルは、モデルのドキュメントで確認してください。

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

推論の要約は、summary 配列に格納されます。この配列は reasoning 出力項目の一部です。推論の要約を含めるよう明示的に指定した場合にのみ出力されます。

次の例は、応答に推論の要約を含める 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 フィールドを使ってください。 API では phase は任意ですが、OpenAI は使用を推奨しています。ツール呼び出し前の前置きなど、アシスタントによる途中経過の報告には phase: "commentary" を、完成した回答には phase: "final_answer" を使ってください。ユーザーメッセージには phase を追加しないでください。 previous_response_id を使うと、それまでのアシスタントの状態が保持されるため、通常はこれが最も簡単な方法です。アシスタントの履歴を手動で再送する場合は、各メッセージの元の phase 値を保持してください。 phase が指定されていなかったり、再送時に抜け落ちたりすると、これらのワークフローで前置きが最終回答として扱われる場合があります。モデルに合わせたプロンプトの書き方は、GPT-5.5 のプロンプト作成を参照してください。

アシスタントのフェーズ値の引き継ぎ

アシスタントのフェーズ値の引き継ぎ
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 は微調整に使い、品質が十分でないときに改善を図る主な手段にしないでください。
  • エージェントが実行するワークフローや調査が中心のワークフローでは、完了条件と、モデルが作業結果を検証する方法を定めてください。

リーズニングモデルを使う際のベストプラクティスについて詳しくは、こちらのガイドを参照してください。

プロンプトの例

リーズニングモデルは、複雑なアルゴリズムを実装したり、コードを生成したりできます。このプロンプトでは、指定した基準に沿って React コンポーネントをリファクタリングするようモデルに指示します。

コードのリファクタリング
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);

活用例

リーズニングモデルを実際のタスクに活用する例は、OpenAI Cookbook で確認できます。

推論を使ったデータ検証

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

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