LLM APIのトークン予算の決め方：入力・出力・履歴に上限を割り当てる

まず押さえる3つの仕様（プロバイダ別）

予算の式は共通ですが、上限に達したときの挙動や計測場所は違います。以下は、記事執筆日（2026-10-27）に各公式ページで確認できた範囲です。モデル名や数値は変わりやすいので、実装時に最新のページを見てください。

• 出力上限のパラメータ、Claude：max_tokens。思考トークンもこの内数、OpenAI（推論モデル）：max_output_tokens。推論トークンと可視の出力の合計を制限、Gemini：max_output_tokensなど。上限はモデルごとに確認
• 上限到達時、Claude：入力＋max_tokensがウィンドウを超えても、Claude 4.5以降ではリクエストは受理され、生成が窓に達するとmodel_context_window_exceededで停止。以前のモデルは検証エラー、OpenAI（推論モデル）：statusがincomplete、reasonがmax_output_tokensになる。可視の回答が出ないまま入力・推論分の料金が発生しうる、Gemini：Gemini 4は入力・思考・出力で単一の枠を共有し、Gemini 3と2.5は入力枠と出力枠が別
• 事前の見積り、Claude：トークンカウントAPI、OpenAI（推論モデル）：返却されるoutput_tokens_detailsのreasoning_tokensで事後確認、Gemini：count_tokens（入力のみ）およびモデル情報のトークン上限

出典：Claude: Context windows、OpenAI: Reasoning models、Gemini API: トークン。

OpenAIのガイドは、推論モデルを試し始める段階では、推論と出力のために少なくとも25,000トークンを確保することを勧めています。出力上限を小さく絞ると、推論で使い切って回答が空になるリスクがあるためです。推論モデルでは「出力上限＝回答の長さ」ではない点が、予算設計で最も外しやすい部分です。

予算の式と、決める順番

1機能あたりの式は次のとおりです（これは編集上の設計案です）。

機能の予算 ＝ 固定入力 ＋ 履歴 ＋ 今回の入力 ＋ 出力上限（思考・推論を含む）＋ 余白

この予算は、モデルのコンテキスト長以下であれば足ります。実際にはコスト、応答時間、品質の面から、窓よりずっと小さい値で止めることが多いはずです。

1. 出力上限を先に決める

出力は「欲しい回答の長さ」から逆算します。説明文なら日本語で何文字まで許すか、JSON抽出ならスキーマが埋まった時の最大長はどれくらいか、を考えます。推論や思考を有効にする機能は、回答分とは別に推論分を上乗せします。最初は広めに取り、usageの実測から詰めます。

2. 固定入力を数える

システムプロンプトとツール定義は毎回送られるので、最初に実測します。ClaudeならトークンカウントAPI、Geminiならcount_tokensが使えます。ツールを増やすほど固定入力が膨らむため、使わないツール定義は載せない運用が効きます。Claudeには、ツール定義を後から読み込むtool searchの仕組みもあります。

3. 履歴に上限と切り方を決める

履歴は会話が進むほど毎ターン積み上がります。前のターンの出力は次の入力になります。上限は「直近N往復」か「履歴にXトークンまで」のどちらかで持ち、超えた分は捨てるか、要約に置き換えます。Claudeでは新しめのモデル向けにサーバー側のcompaction（ベータ）もありますが、使うかどうかに関わらず、自前の上限は別に決めておくと安全です。

なお、Claudeでは、モデルによって前のターンの思考ブロックが履歴に残り、入力として数えられます。思考を使う機能では、履歴の見積りに思考分が入るかをモデルごとに確認してください。

4. 今回の入力に上限を置く

ユーザー入力、検索結果、添付文書は、機能ごとに上限を決めて、超えたら切り詰めるか断るかを選びます。文書の上限は文字数ではなくトークンで管理します。Geminiのページでは、トークンは約4文字が目安とされていますが、これは英語での目安です。日本語や画像は別に計測してください。

5. 余白と超過時の動作を決める

見積りと実測はずれます。表の合計には出力上限まで含め、さらに利用モデルの仕様に沿った余裕を残します。合計の1〜2割を余白にするのは設計上の目安で、必要な余白は実測で調整します。超過時の動作は、切る、要約する、エラーを返す、より大きなモデルへ回す、のどれかを機能ごとに表に書いておきます。

機能別トークン予算の配分表テンプレート

次の表は説明用の例です。数値は実測ではなく、構造を示すための仮置きです。コピーして自分のサービスの機能名と実測値に置き換えてください。

• 問い合わせ回答チャット、固定入力：2,500、履歴上限：3,000、今回の入力上限：4,500、出力上限：800、合計：10,800、超過時の動作：古い履歴から削除。検索結果は上位件のみ残す
• 長文要約、固定入力：500、履歴上限：0、今回の入力上限：30,000、出力上限：1,500、合計：32,000、超過時の動作：章ごとに分割して要約し、最後に統合
• 構造化抽出（JSON）、固定入力：1,200、履歴上限：0、今回の入力上限：3,000、出力上限：600、合計：4,800、超過時の動作：入力を超えたら422相当のエラーを返す
• 推論モデルでの難問分析、固定入力：800、履歴上限：2,000、今回の入力上限：6,000、出力上限：25,000、合計：33,800、超過時の動作：出力側がincompleteなら上限を上げず、入力を減らして再実行

「合計」は、その機能に許す最大値です。これが利用モデルの入力・出力上限を満たすことを、まず確認します。表の合計には出力上限も含め、さらに合計の1〜2割を目安に余白を残した値を、機能の「ハードリミット」としてコードに持たせます。

設定に落とすときの項目例

設定ファイルに持つ場合の項目は次の程度で足ります（説明用の構造で、実行は確認していません）。

{
  "feature": "support_chat",
  "fixed_input": 2500,
  "history_max": 3000,
  "user_input_max": 4500,
  "output_max": 800,
  "margin_ratio": 0.15,
  "on_overflow": "drop_oldest_history"
}

実測で表を直す手順

最初の数値は仮置きでかまいません。次の手順で更新します。

1. 各リクエストのusage（Claude、Gemini）やoutput_tokens_details（OpenAI）を、機能名と一緒にログへ残す。
2. 機能ごとに、入力・出力・推論の分布を見る。平均ではなく、上位の値（95パーセンタイルなど）に注目する。
3. 出力が上限で打ち切られた回数を数える。OpenAIならincomplete、Claudeならstop_reasonを見る。
4. 打ち切りが多い機能は出力上限を上げ、逆に実使用が上限の半分にも届かない機能は下げる。
5. 履歴の上限は、打ち切りよりも回答品質のレビューで決める。長くしても品質が上がらないなら、短くしたほうがコストも応答時間も有利です。

表づくりをAIに手伝わせる依頼文

ログの集計値を渡して、たたき台を作らせることもできます。実数値は自分で用意し、機密を含むログは説明用の値に置き換えて渡してください。

次の機能別の実測値から、トークン予算の配分表を作ってください。
列は「機能／固定入力／履歴上限／今回の入力上限／出力上限／合計／超過時の動作」です。
- 上限は各項目の95パーセンタイルに1.2倍を掛けて丸める
- 推論や思考を使う機能は、出力上限に推論分を含める
- 合計がモデルのコンテキスト長（機能ごとに別途指定）を超える場合は警告する
- 計算根拠を各行の下に1行で書く

[ここに機能名と、固定入力・履歴・入力・出力の実測値を貼る]

AIが返す数値は計算ミスを含みうるので、合計と各行の足し算は人が検算してください。1.2倍という係数は例で、実際の値は自分のサービスの許容度で決めます。

運用でつまずきやすい点

• 出力上限を絞りすぎる：推論モデルでは回答が空になることがあります。OpenAIのincomplete状態は、入力と推論の分だけ料金が発生しうると明記されています。
• 窓を超えても受理される場合がある：Claude 4.5以降では、入力＋max_tokensが窓を超えてもリクエストが通り、生成が窓に達すると途中で停止します。以前のモデルは検証エラーになります。モデルごとの挙動を確認し、自前の上限チェックを行います。
• 画像や文書の大きさ：Claudeでは、画像やPDFを多く送ると、トークン上限より先にリクエストサイズの上限に当たる場合があります。
• 仕様の更新：モデルごとの上限や挙動は変わります。配分表の冒頭に、確認した日付とモデル名を書いておくと、後で見直しやすくなります。