context_length_exceeded / prompt is too long — アプリを機能不全にしない修正方法

すべてのモデルにはコンテキストウィンドウがあり、この 400 エラーはプロンプトと要求した出力が収まらなかったことを意味します。プロンプトを無差別に切り詰めるという単純な修正は、RAG アプリを気付かないうちに愚かにします。文脈を失わずにウィンドウへ収める方法を説明します。

エラー

response (HTTP 400)

// Anthropic:
{"type":"error","error":{"type":"invalid_request_error",
 "message":"prompt is too long: 214481 tokens > 200000 maximum"}}

// OpenAI-compatible:
{"error":{"type":"invalid_request_error","code":"context_length_exceeded",
 "message":"This model's maximum context length is 128000 tokens..."}}

原因と対処法の概要

原因	対処法
無制限のチャット履歴	ローリングウィンドウと継続的な要約を使い、毎回トランスクリプト全体を再生しないでください。
RAG が多すぎる、または大きすぎるチャンクを取得している	より少なく、より小さく、再ランキングしたチャンクを取得します。ウィンドウが埋まるずっと前から、量より品質が重要です。
残りに対して max_tokens が大きすぎる	ウィンドウは入力と出力の両方を含みます。予算 = ウィンドウ − 入力です。max_tokens は残りに合わせて設定します。
ワークロードが本当により多くのコンテキストを必要としている	厳しい上限を回避する設計をするのではなく、長いコンテキストのモデル階層（例：1M ウィンドウモデル）へ移行します。

削る前に測定する

API と同じ方法でトークンを数えます（Anthropic には count_tokens エンドポイントがあり、tiktoken は OpenAI 形式のモデルを近似します）。リクエストごとの数を記録してください。1.05倍超過の場合と5倍超過の場合では、修正方法が異なります。

指示ではなく検索結果と履歴を削る

次の順序で削ります。(1) 古いチャットターン → 要約、(2) 検索したチャンク → 再ランキングして上位 k 件を保持、(3) 冗長な few-shot 例 → 少なく、簡潔に。システム指示は最後です — 動作はそこに存在します。

構造的な問題なら、より長いウィンドウへ移行する

正当な入力が毎週ウィンドウを超えるなら、それはモデル選択の問題です。長いコンテキスト階層（200K〜1M）は、契約分析、コードベース Q&A、複数文書の処理のために存在します。トリミングに費やしているエンジニアリング時間とアップグレード費用を比較してください。

Kunavo経由で呼び出している場合

Kunavo のカタログは、1M ウィンドウの Claude 5 ファミリーモデルを含む複数のコンテキスト階層を1つのキーで提供します。そのため、ワークロードを200Kから1Mのウィンドウへ移行する場合もモデル文字列を変更するだけです。各モデルページには、トレードオフを予算化できるよう、1トークンあたりの価格と並べてウィンドウが記載されています。

よくある質問

max_tokens はコンテキストウィンドウに加算されますか？

はい。ウィンドウは入力と生成された出力の合計を制限します。195K のプロンプトを持つ200Kウィンドウモデルは、max_tokens: 8000 を実行できません。残りを計算し、max_tokens をその値に制限してください。

プロンプトキャッシュはコンテキスト超過の修正になりますか？

いいえ。キャッシュは繰り返される長いプロンプトのコストを削減するものであり、サイズを削減するものではありません。キャッシュの有無にかかわらず、ウィンドウに対して数えられるトークン数は同じです。