「prompt is too long」でHTTP 400が出る原因と解決策：トークン上限超過を確実に潰す実践ガイド

コード解析やレビューをAIに投げた瞬間、突然の HTTP 400 Bad Request。ログを見ると「INVALID_ARGUMENT」「invalid_request_error」「prompt is too long」といった文言が並び、何が悪いのか分からないまま作業が止まる——。この手のエラーは、たいてい入力（プロンプト＋添付文脈）がモデルの最大トークン数を超えたことが原因です。この記事では、なぜ起きるのか、そして同じ事故を繰り返さないための具体的な分割・圧縮・設計パターンまでまとめて解説します。

「prompt is too long」でHTTP 400が出る原因と解決策：トークン上限超過を確実に潰す実践ガイド

起きていること：HTTP 400の正体は「長すぎる入力」

このエラーの核心はシンプルで、モデルに渡した入力が許容量を超えています。多くのAPIでは、以下が合算されて上限チェックされます。

システム指示（system）
ユーザー入力（user）
これまでの会話履歴（messagesの過去分）
参照として埋め込んだコードやログ全文
ツール呼び出し結果や返答の蓄積

つまり「今回の質問」だけが長いとは限らず、会話を続けた蓄積や、まるごと貼り付けたソースコード、巨大ログが原因で簡単に上限に到達します。APIは処理に入る前に弾くので、結果が返る前に400で止まります。

典型パターン：コード解析で一気にトークンが爆発する理由

コードは自然言語よりもトークンが増えやすい傾向があります。特に次の要素が揃うと危険です。

依存ライブラリや自動生成コードを含む巨大ファイルを丸ごと投入
ビルドログ・スタックトレース・HTTPヘッダ等を全文添付
「このリポジトリ全体を解析して」型の依頼でファイル群を全貼り
会話が長く、履歴を削らないまま追加投入

AIにとっては「全部入力」＝「全部トークン」。上限を超えた瞬間に、どれだけ内容が正しくても失敗します。

解決の基本方針：削る・分ける・要約する

対策は3系統に整理できます。結論から言うと、一度に全部を渡さない設計に変えるのが最短です。

1) まず削る：入力の最小化チェックリスト

以下をやるだけで、かなりの確率で通ります。

エラーメッセージに関係ないログ（ヘッダ・タイムスタンプ・ビュー数など）を削除
コードは「該当関数＋呼び出し元＋関連型定義」程度に絞る
期待する挙動・実際の挙動・再現手順を短く書き、全文貼り付けを避ける
会話履歴が長い場合は、新しいスレッドに切り替えるか履歴を要約してから続ける

「必要なのは原因の手がかり」だけです。AIにとっても、人間にとっても、ノイズは精度を下げます。

2) 分ける：チャンク分割で安全に解析する

どうしても量が多いなら、分割して段階的に処理します。おすすめは次の流れです。

Step A：全体概要（目的・構成・主要モジュール）だけを入力し、解析方針を作らせる
Step B：問題箇所の候補を絞る（関連ファイル名・関数名・依存関係）
Step C：該当箇所のコードだけを投入して深掘り
Step D：修正案と差分（パッチ）を生成

この形にすると、1回のリクエストが軽くなり、上限超過だけでなく回答品質も上がりやすいです。

3) 要約する：長文は「一度圧縮してから」使う

ログやコードの全文が必要な場面では、いきなり解析に投げず、先に圧縮します。

ログ全文 → 「エラー部分の前後50行」＋「発生頻度」＋「環境情報」だけ抽出
コード全文 → 「公開API面（外部I/F）」＋「例外が出る関数」＋「データ構造」だけ抽出
会話履歴 → 「決定事項」「未解決点」「制約条件」だけに要約して再投入

ポイントは、要約の粒度を落としすぎないこと。AIが推測で補い始めると、誤った修正案が出ます。「必要十分な情報」に整えるのがコツです。

実装設計で再発防止：入力制御のベストプラクティス

運用で毎回手作業だと再発します。アプリ側で次を入れると堅牢になります。

トークン予算を先に決める

「入力は最大の◯%まで」「出力は◯トークンまで」など、予算を固定します。
会話履歴が増えるほど入力が膨らむので、一定以上は履歴を要約して置換する運用が鉄板です。

履歴は“全部保持”ではなく“要点保持”

古い会話は要約に置換
重要な制約や要件だけを「固定メモ」として別枠で保持
直近のやりとりだけ生ログで残す

これで長期セッションでも上限に当たりにくくなります。

RAG（検索）で「必要な断片だけ」を取り出す

大量のソースコードを丸ごと投げる代わりに、リポジトリから関連箇所だけ検索して投入します。
ベクトル検索でもキーワード検索でもよく、重要なのは「常に部分投入」になることです。

すぐ使えるテンプレ：短くても精度を落とさない依頼文

最後に、トークンを節約しつつ解析精度を上げる依頼の型を載せます。

目的：何を達成したいか（例：例外原因の特定、修正案、テスト追加）
環境：言語／実行環境／バージョン（必要最小）
期待：本来どう動くべきか
実際：何が起きたか（エラー1つ＋要点）
添付：該当コード（最小範囲）＋再現手順（短く）

この型に沿って情報を削るだけで、「長すぎて通らない」問題は激減します。

まとめ：400は故障ではなく設計課題。入力を制御すれば解決できる

「prompt is too long」によるHTTP 400は、モデルや環境の不調というより、入力の出し方の問題です。
削る・分ける・要約するを徹底し、履歴を要点管理に変え、必要なら検索で断片投入に切り替える。これだけで、上限超過は実務レベルでほぼ防げます。

次に同じ場面が来たら、「全文を貼る」より先に「最小化して渡す」へ。エラーを消すだけでなく、回答の質も上がって作業が速くなります。