Context Length Exceeded：リクエストを減らし、結果を検証する方法
コンテキストの各要素を計測し、重複と不要な履歴を除去し、出力用の余地を残して必須情報が失われていないか確認します。
目次
Context Length Exceeded：リクエストを減らし、結果を検証する方法
Context length exceeded は、プロンプトの半分を無作為に削除して直すものではありません。まず総予算を把握し、モデルを特定して、リクエストを構成する各要素を計測します。その後で機械的な重複、無関係な履歴、大きなツール結果を取り除きます。再送後は、エラーが消えたことだけでなく、必須情報と回答の完全性が維持されていることも確認してください。
コンテキストウィンドウを埋めるもの
コンテキストは、最後のユーザープロンプトだけではなく、1 回のリクエスト全体の作業記憶です。単純化すると次のようになります。
system instructions
+ conversation history
+ current message
+ images and documents
+ tool definitions
+ tool results
+ output / thinking budget
= total context usageAnthropic のコンテキストウィンドウ文書には、システムプロンプト、すべてのメッセージ、画像、文書、ツール定義、ツール結果、生成される回答が含まれると明記されています。プロンプトキャッシュは再利用トークンの費用を変えますが、ウィンドウからトークンを消すものではありません。
「万能の上限」をコードに固定しないでください。コンテキストウィンドウの大きさと超過時の動作は、選択したモデルと API に依存します。設定する当日に最新のモデルカードを確認します。
最も重い要素を見つける
| 要素 | 計測するもの | 安全な削減方法 |
|---|---|---|
| システム指示 | 繰り返された規則、長い例 | 重複を統合し、必須の制約を残す |
| 履歴 | メッセージごとのトークン、古い分岐 | 無関係な分岐を削除するか、検証可能な要約に置き換える |
| ファイルと RAG 断片 | 各文書のサイズ、重複、関連性の低い断片 | top_k を下げ、重複除去し、必要な節だけ渡す |
| ツール定義 | 未使用ツール、長い説明 | 現在の手順に必要なツールだけ渡す |
| ツール結果 | 完全な JSON、ログ、HTML、base64、重複した応答 | 必要なフィールド、リンク、ID だけ残し、大容量データはプロンプト外に置く |
| 出力予算 | max_tokens と思考予算 | 現実的な余地を確保するか、大きな結果を段階に分ける |
Claude には送信前にメッセージとツールを数えられる Token Counting API があります。他のプロバイダーでは、利用できるならそのプロバイダーのカウンターを使ってください。ローカル tokenizer は早期警告には便利ですが、別モデルのサーバー側計算を保証するものではありません。
BetterTokenの現行APIドキュメントを開き、短いtest requestを実行してDashboardで見つけます。context削減前後のinput、output、cache tokensを比較し、input tokensの減少で修正が実際のcallに届いたことを確認してください。Dashboardは完全なpromptを表示せず、送信前のtoken countingも代替しません。
意味を失わずにサイズを減らす
1. 機械的な重複を削除する
繰り返されたシステム規則、複数のメッセージに入った同じファイル、重複した RAG 断片、何度も貼られたスキーマ、完全なログの再掲を探します。タスク自体を変えずに量を減らせるため、最も安全な段階です。
2. 無関係な履歴を除く
長期的に必要な事実と、一時的な会話の流れを分けます。目標、採用済みの決定、必須制約、未解決の質問は残します。古い推論、却下した案、すでに処理済みのツール結果は削除するか、構造化した要約に圧縮できます。
悪い要約は「統合について話した」とだけ書きます。良い要約には、選んだ endpoint、スキーマのバージョン、採用済みの制約、確認済みの事実、次の手順が入ります。
3. ファイル、RAG、ツール結果を圧縮する
文書全体ではなく関連する節を渡します。ツール結果には HTTP 応答やログ全体ではなく、次の手順に必要なフィールドを残します。収めるためだけに出典や必須データを捨ててはいけません。作業を検証可能な複数の段階に分けてください。
4. 回答のための余地を残す
入力と出力は同じ予算を共有します。リクエストがウィンドウをほぼ埋めると、完全な回答のための余地が足りなくなることがあります。任意の入力を減らし、現実的な出力予算を設定するか、結果を分割します。機械的な重複より先に重要な事実を削らないでください。
5. 計測してからモデルを替える
安全に分割できない文書には、より大きなコンテキストを持つモデルが適する場合があります。しかし重複を除かずに大きなウィンドウへ移ると、次のエラーを先送りするだけで、情報密度も下がり得ます。
送信前の最小チェック
components = count_by_section(request)
estimated_input = sum(components)
reserved_output = requested_output_budget
if estimated_input + reserved_output approaches current_model_window:
remove exact duplicates
drop irrelevant history
compact tool results and retrieved chunks
count again
send only after required facts and constraints remain presentapproaches を固定比率に置き換えていないのは意図的です。必要な余裕は、カウンターの精度、モデル、思考、対象 API の動作に左右されます。
修正を検証する方法
新しいリクエストを次のチェックリストと照らし合わせます。
- API が
context length exceededまたはprompt is too longを返さなくなった。 - 出力予算による途中終了ではなく、回答が正常に完了した。
- 回答に必須の事実、制約、要求された形式がすべて含まれている。
- 引用やリンクが、渡した出典に依然対応している。
- ツール呼び出しが正しい引数を使い、圧縮で重要な結果が失われていない。
- 新しい入力使用量が元より実際に少ない。
エラーが消えてもモデルが重要な制約を忘れたなら、修正は失敗です。必須ブロックを戻し、関連性の低い履歴または大きなツール結果を除いて空きを作ります。回答が途中で切れる場合は、出力予算を別に確認してください。これも同じ総ウィンドウの一部です。
まとめ
実用的な順序は、モデルを特定する → 要素を数える → 完全に重複する部分を削除する → 無関係な履歴を外へ出す → ファイルとツール結果を圧縮する → 回答の余地を残す → 再送する → 品質を確認する、です。この順序なら、コンテキストを無作為に切り詰めた情報の集合にせず、原因を解決できます。
