推論モデル reasoning_effort Extended Thinking OpenAI API Claude API

推論モデルのAPIパラメーター、プロバイダー間で比較

OpenAIのreasoning_effort、Anthropicのthinking、GeminiのthinkingBudgetはいずれも出力として課金される隠れた推論トークンを制御する。各つまみの仕組みと相違点。

AveMujica API 2026年7月15日 2 分で読めます

推論モデルは目に見えないステップを追加します。回答を書く前に、モデルは隠れた推論トークンを生成し、それらのトークンはお金がかかり、コンテキストウィンドウを消費し、レイテンシを増やします。すべてのプロバイダーはこれがどれだけ起こるかを制御するダイヤルを提供しますが、3つのダイヤルは異なる名前、異なる値のスケール、異なるデフォルトを持ちます。OpenAIでは reasoning_effort、Anthropicでは thinking、Geminiでは thinkingConfig です。推論モデルを正しく扱うことは、主にその3つのつまみと、1つの共有された事実を理解することに尽きます。推論トークンは、あなたが決して読まなくても、出力トークンとして課金されるのです。この記事では、各プロバイダーのパラメーター、隠れたコストを露わにする使用量フィールド、そして抽象化が整列しなくなる箇所を歩いていきます。

共有されるメンタルモデル

プロバイダーに関係なく、推論リクエストは同じ構造を持ちます。入力トークンが入ります。モデルは2種類の出力を生成します。隠れた推論トークンと、可視の回答トークンです。両方とも出力レートで課金され、両方ともモデルのコンテキストウィンドウにカウントされ、あなたに返ってくるのは可視のものだけです（多くのモデルでは、生の推論そのものではなく、任意で推論のサマリーが伴います）。各プロバイダーが公開するダイヤルは、モデルが喜んで費やす隠れたトークンの数を変えます。難しい問題やマルチステップのエージェント的ループのためには上げ、レイテンシに敏感で浅いタスクのためには下げます。以下はすべてそのテーマのバリエーションです。

OpenAI：`reasoning_effort` と `reasoning` オブジェクト

OpenAIの推論モデルではeffortを設定します。Chat Completionsはトップレベルの reasoning_effort 文字列を取り、Responses API は reasoning オブジェクトを取ります。その effort フィールドが同じ仕事をし、サマリーとコンテキスト制御の余地を追加します。

from openai import OpenAI
client = OpenAI(base_url="https://your-gateway.example.com/v1", api_key="AVE_GATEWAY_API_KEY")

# Responses API
resp = client.responses.create(
    model="gpt-5.6",
    input="Prove there are infinitely many primes p with p mod 4 == 3.",
    reasoning={"effort": "high", "summary": "auto"},
)

effort値はモデル依存で、none、minimal、low、medium、high、xhigh を含みうります。デフォルトはモデルによって異なります。低いeffortは速度と少ないトークンを優先し、高いeffortはより多くのコストでより徹底した出力をもたらします。隠れた作業は計測されます。推論トークンは usage の output_tokens_details の下に reasoning_tokens として現れるため、トークンそのものは差し控えられていても、目に見えない支出を観察できます。モデルがなぜ何かを結論したかを見るには、サマリー（summary: "auto" または "detailed"）を要求します。これは要約された推論トレースを reasoning 出力アイテムに返します。オプトインが必要で、デフォルトでは含まれません。

ステートレスおよびエージェント的なセットアップにとって2つの機能が重要です。ゼロ保持の運用には、store: false を送り、include 配列に reasoning.encrypted_content を追加します。APIは暗号化された推論を返し、それを次のターンに渡し返すことで、サーバーが何も保存せずに継続性を保てます。そして reasoning.context（auto、current_turn、または all_turns）は、連鎖した会話にわたってモデルがどの以前の推論アイテムを引き出せるかを制御します。

忘れてはならないパラメーターは max_output_tokens です。これは合計の生成トークン、すなわち推論に加えて可視の回答に上限を設けるため、低く設定しすぎると予算全体が隠れた推論に消費されかねず、incomplete の status（max_output_tokens を引き合いに出す incomplete_details を伴う）と可視のテキストなしを受け取りながら、入力と推論のトークンの代金は依然として払うことになります。OpenAIは、始めるにあたって推論と出力のために寛大な余地（数万トークンのオーダー）を確保することを推奨しています。その余地を予算化することは、LLMコンテキストウィンドウ管理で説明されている同じ規律です。

Anthropic：`budget_tokens` から適応的思考へ

Anthropicのextended thinkingは歴史的に明示的なトークン予算を使っていました。type: "enabled" の thinking オブジェクトと budget_tokens の上限で有効にします。

import anthropic
client = anthropic.Anthropic(base_url="https://your-gateway.example.com", api_key="AVE_GATEWAY_API_KEY")

msg = client.messages.create(
    model="claude-sonnet-4-5-20250929",
    max_tokens=16000,
    thinking={"type": "enabled", "budget_tokens": 10000},
    messages=[{"role": "user", "content": "Are there infinitely many primes p with p mod 4 == 3?"}],
)

3つのルールが budget_tokens を統べます。それは内部推論の最大トークンを設定し、max_tokens より小さくなければなりません（ツールとのインターリーブド思考が上限をコンテキストウィンドウ全体にできる場合を除く）。モデルは特に大きな値では予算全体を使わないことがあります。そして推論は text ブロックの前に thinking コンテンツブロック（それぞれ thinking テキストと signature を運ぶ）として表面化します。短いサマリーではなく生成された完全な思考トークンの代金を請求されるため、請求される出力カウントは可視で見えるものと一致しません。

計画すべき重要なバージョンの分岐があります。budget_tokens は廃止されつつあります。一部の現行モデルでは非推奨で、最新のものでは400を返します（たとえばOpus 4.8/4.7およびSonnet 5世代）。これらは代わりに適応的思考を使います。type: "adaptive" の thinking オブジェクトをeffort設定と組み合わせるもので、Anthropicを概念的にOpenAIのeffortダイヤルへ近づけます。構築するときは、モデルで分岐しましょう。まだ受け付けるモデルには budget_tokens を送り、要求するモデルには適応的/effort形式を送ります。ゲートウェイはこれの一部を隠せます。次のセクションで示すとおりです。

譲れないツール使用のルールが1つあります。ツールループの間、続くassistantメッセージでモデルの thinking ブロックを変更せずに渡し返さなければなりません。さもなければAPIは400でリクエストを拒否します。ブロックはツール呼び出しに至った推論をエンコードしており、それらを並べ替えたり編集したりすると継続性が壊れます。これは関数呼び出しとともに推論アイテムを返すというOpenAIの助言を反映しており、だからこそプロバイダー間でのポータブルなツール呼び出しは推論ブロックの保存を正しいツールループの一部として扱うのです。

Gemini：`thinkingConfig` と `thinkingBudget`

Geminiは generationConfig の内側の thinkingConfig を通じて推論を制御します。鍵となるフィールドは thinkingBudget で、思考のためのトークン割り当てであり、2つの特別な値を持ちます。-1 はモデルに動的に決めさせ、（無効化を許すモデルでは）0 は思考をオフにします。includeThoughts フラグはAPIに思考サマリーを返すよう求めます。消費された推論は usageMetadata に思考トークン数として現れ、これもまた出力として課金されます。

from google import genai
from google.genai import types

client = genai.Client()
resp = client.models.generate_content(
    model="gemini-3.5-flash",
    contents="Are there infinitely many primes p with p mod 4 == 3?",
    config=types.GenerateContentConfig(
        thinking_config=types.ThinkingConfig(thinking_budget=-1, include_thoughts=True),
    ),
)

どのモデルが思考の無効化を許すか、そして正確な予算範囲は、モデルのティアによって異なります。値が世代をまたいで通用すると仮定するのではなく、モデルページを確認してください。

ゲートウェイが正規化するもの、そしてどこで止まるか

1つのOpenAI互換エンドポイントの背後で、ゲートウェイは各プロバイダーの推論パラメーターを、それを理解する上流へ転送します。reasoning_effort と reasoning オブジェクトはOpenAIへ、thinking はAnthropicへ、thinkingConfig はGeminiへです。また、3つの異なる隠れトークンカウントを統一された使用量ビューにまとめるため、推論リクエストの本当の出力コストが、どのベンダーが処理したかに関係なくログで見えるようになります。

このゲートウェイはさらに知っておく価値のある便利機能を提供します。モデル名のeffortサフィックスをパースし、それをプロバイダー自身の推論パラメーターに変換できるのです。モデルIDに -high、-medium、-low、-minimal、-xhigh、または -max を付加する（たとえば claude-opus-4-8-high や -thinking バリアント）ことで、モデル文字列しか設定できないクライアントでもeffortレベルを選べるようになり、ゲートウェイがそのサフィックスをターゲットプロバイダーの正しいつまみにマッピングします。登録済みのモデル/effortバリアントとモデルごとの料金は、公開料金ページに掲載されます。

限界については明確にしておきましょう。抽象化は本当に整列しないからです。

スケールが異なる。 OpenAIの effort はenum、Anthropicのレガシーな budget_tokens は絶対的なトークン数、Geminiの thinkingBudget はセンチネル値を持つトークン数です。「high effort」と「10,000 budget tokens」は互いの翻訳ではありません。一方を他方にマッピングするのはヒューリスティックであって等価ではありません。
デフォルトが異なる。 デフォルトで推論するモデルもあれば、しないモデルもあり、デフォルトのeffortはモデル固有です。沈黙が「推論なし」を意味すると仮定しないでください。
機能のカバレッジが異なる。 暗号化された推論の継続性、思考サマリー、思考の無効化は、プロバイダー間で不均一にサポートされています。ゲートウェイはフィールドを通せますが、プロバイダーが提供しない能力を尊重させることはできません。

ゲートウェイは、1つの課金ビューと1つのパススルー経路を与える層として扱い、本当の能力ギャップがあるところにはプロバイダー固有のロジックを残しましょう。

実践的なデフォルト

いくつかの出発点のルールがお金とレイテンシを節約します。

重要度ではなくタスクの深さにeffortを合わせる。 難しい抽出は、長いが浅い要約よりも多くの推論を必要とします。effortは利害ではなく問題の構造に関するものです。
常に出力の余地を確保する。 どの推論モデルでも、隠れた推論が可視の回答を飢えさせないよう、最大出力の上限を十分高く設定しましょう。さもなければ推論に払って何も受け取らないことになります。
隠れたトークンを測る。 使用ログで reasoning_tokens / 思考トークンを観察しましょう。推論トークンが回答トークンを圧倒するタスクは、より低いeffortか非推論モデルの候補です。この決定は適切なLLMモデルの選択で扱っています。

FAQ

推論トークンは、私が決して見なくても課金されますか？

はい。隠れた推論トークンは3つすべてのプロバイダーで出力トークンのレートで課金され、コンテキストウィンドウも占有します。だからこそ請求される出力カウントは可視の回答が示唆するより大きくなり、使用ログで推論トークンのフィールドを観察することが重要なのです。それは応答本文では見えない、本物の支出です。

なぜ推論モデルから空または不完全な応答を受け取ったのですか？

通常、出力の上限が低すぎて推論が予算全体を消費したためです。OpenAIは max_output_tokens を引き合いに出す incomplete の status を返します。Anthropicは budget_tokens が max_tokens より小さいことを要求します。隠れた推論が可視の回答を飢えさせないよう合計出力の上限を上げ、推論ルートには寛大な余地を確保しましょう。

Anthropicの `budget_tokens` はOpenAIの `reasoning_effort` と同じですか？

同じ目的を果たしますが、等価ではありません。reasoning_effort はenum（low/medium/high および関連する値）で、budget_tokens は絶対的なトークン数です。Anthropicの最新モデルでは budget_tokens はサポートされず、effort設定を伴う適応的思考が置き換えます。ゲートウェイはeffortラベルをプロバイダーのパラメーターにマッピングできますが、そのマッピングは近似であって1対1の翻訳ではありません。

クライアントがモデル名しか送れない場合、推論レベルをどう設定しますか？

ゲートウェイのeffortサフィックスを使います。モデルIDに -high、-medium、-low、-minimal、-xhigh、または -max を付加すると、ゲートウェイがそれをパースし、ターゲットプロバイダーに合った推論パラメーターを適用します。これによって薄いクライアントが、プロバイダー固有のフィールドを自分で送ることなくeffortレベルを選べます。

自分のタスクでeffortの屈曲点を見つける

同じ難しいプロンプトを、low、medium、highのeffortでゲートウェイ経由で3回実行し、毎回使用ログから2つの値を記録してください。推論トークン数と、あなた自身の評価基準による回答品質です。たいてい、effortを増やしても回答は改善しなくなる一方で、トークンだけは消費し続ける屈曲点が見つかります。ルートをその少し下に固定してください。自分のタスクで得たこの1回の測定は、どのプロバイダーのデフォルト値よりも役立ちます。