Claude Codeで「Prompt is too long」が出て詰んだ時の対処法——「usage limit reached」と誤表示される罠も含めて整理した
Claude Codeの「Prompt is too long」エラーの原因と復旧手順を解説。200kトークン制限との違い、「usage limit reached」への誤表示問題、MCPツール肥大化などの原因別チェックリスト、GitHub Issue実例つきでまとめた。
エンジニアのゆとです。
Claude Codeで長時間作業していたら、ある瞬間から何を打ってもPrompt is too longとしか返ってこなくなった——という経験をした人は、たぶん僕だけじゃないと思う。しかも厄介なのは、このエラーが素直に「コンテキストが満杯です」と教えてくれないケースがあること。usage limit reached（利用制限に達しました）という別のメッセージに化けて出てくることがあって、プラン変更ページを開いてしまった人も実際にいる。
この記事では、Prompt is too longエラーの正体、なぜ自動コンパクション機能があるのに発生するのか、そして今まさに詰んでいる人がやるべき復旧手順を、GitHub Issueの実例つきで整理する。
まず結論——今すぐやるべきこと
パニックにならなくていい。順番にこれをやる。
/contextを実行して、本当にコンテキストが埋まっているのか確認する（後述するが、埋まっていないのに出るケースもある）- 埋まっているなら
/compactに焦点を指定して実行する。例:/compact 直前のバグ修正の要点だけ残して /compact自体が通らないほど詰まっている場合、Escを2回押して数ターン前まで会話を巻き戻し、そこから/compactを試す- それでもダメなら
/clearで会話をリセットする。ただし会話ログ自体は消えないので、後から/resumeで過去セッションを一覧して必要な情報だけ拾い直せる - VS Code拡張やデスクトップアプリで発生してCLIに逃げられない場合は、ターミナル版の
claude --resumeから同じプロジェクトディレクトリでセッション一覧を確認する
これで大半のケースは復旧できる。以下、なぜこのエラーが起きるのか、なぜ自動対策があるのに詰むのかを掘り下げる。
そもそも「Prompt is too long」って何のエラーなのか
Claude Codeが投げてくる実際のエラーメッセージはこういう形をしている。
Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"prompt is too long: 209375 tokens > 200000 maximum"},"request_id":"req_..."}invalid_request_errorという種類で、HTTPステータスは400。これは「1回のリクエストに含まれるトークン数が、モデルの上限を超えた」ことを意味するエラーだ。Claude Codeは会話を送るたびに、これまでの会話履歴・読み込んだファイル・ツールの実行結果・CLAUDE.mdやメモリファイル・接続中のMCPツールのスキーマまで、全部まとめて1つのリクエストとしてAPIに送っている。だから画面に見えている自分の一言はごく小さくても、裏側で送られているリクエスト全体は巨大になっていることがある。
標準的なモデルのコンテキストウィンドウは20万トークン。Opus/Sonnetの一部モデルでは100万トークン（1Mコンテキスト）まで拡張されているが、こちらは追加料金が発生する条件があったり、プランによって使えなかったりする。自分がどちらの上限で動いているのかは /context を打てば内訳付きで確認できる。
「usage limit reached」に化けて出てくる罠
ここが一番の落とし穴だと思っている。
本来Prompt is too longはHTTP 400（リクエスト単位の制限超過）で、実際の利用制限（レートリミット）を示すHTTP 429とは全く別物だ。ところがClaude Codeのエラーハンドラーがこの2つを区別せず、どちらも「利用制限に達しました」という表示にまとめてしまうケースがあることがGitHub Issueで報告されている。
このIssueが指摘している通り、実際に困るのは「ユーザーは利用制限に達していないのに、待機したりプランのアップグレードを検討したりしてしまう」ことだ。しかも一度200kトークンを超えたセッションは、以降のメッセージすべてで同じエラーを繰り返すため、「待てば直る」と勘違いしたまま何も解決しないまま時間だけ溶ける。
見分け方はシンプルで、エラーメッセージにprompt is too longという文字列と具体的なトークン数（209375 tokens > 200000 maximumのような）が含まれていたら、それはコンテキスト超過であって利用制限ではない。プランのステータスページを確認する前に、まず/contextを叩く方が早い。
自動コンパクションがあるのに、なぜ発生するのか
Claude Codeの公式ドキュメントには、こう書かれている。
Claude Code はコンテキストウィンドウの制限に近づくと自動的にコンパクションを実行するため、コンテキストウィンドウがいっぱいになってもセッションが終了することはありません。
理屈の上ではその通りで、コンテキスト使用率が一定のしきい値に近づくと自動で古いターンを要約し、空き容量を確保する仕組みが用意されている。ただ、実際のGitHub Issueを見ていくと、この自動対策をすり抜けて詰むパターンが存在する。
このIssueで報告されているのは、自動コンパクションが間に合わず、警告もなく突然セッションがロックされたケースだ。報告者いわく「Windowsとプロジェクトのコンテキストを台無しにする、非常に不快なバグ」で、一度発生すると同じセッション内では何を打っても回復しない。セッションデータ自体は~/.claude/projects/[プロジェクト名]/[セッションID].jsonlに残っているので、最悪の場合はそこから必要な情報を手動で拾い直すしかない。
自動コンパクションは「使用率が徐々に上がっていくケース」には強いが、「1回のツール実行やファイル読み込みで一気にトークンが跳ね上がるケース」には対応しきれないことがある、というのが実態に近い。
原因は主に4パターンに分かれる
GitHub Issueを横断して見ていくと、原因はだいたい4つに分類できる。
1. 巨大ファイルの一括読み込み
数千行のログファイルや生成されたJSON、巨大なCSVをそのままReadツールで読ませると、1回のツール結果だけで数万トークンを消費する。offsetとlimitを指定して部分読み込みするか、grepで必要な行だけ抽出させた方が安全だ。
2. MCPツールのスキーマ肥大化
意外と見落とされがちなのがこれ。接続しているMCPサーバーが多いと、各ツールのスキーマ定義だけでコンテキストをかなり消費する。
このIssueでは、コンテキスト全体のうちMCPツールのスキーマだけで22.5%を占めていた。空き容量は表示上まだ40%以上あったにもかかわらず拒否されている点が興味深く、/contextの内訳表示と実際のリクエスト送信タイミングとの間にズレがある可能性を示唆している。使っていないMCPサーバーは思い切って切っておいた方がいい。
3. --resumeでの大量履歴読み込み
過去の長いセッションを--resumeで再開すると、その時点の会話履歴がまるごと読み込まれる。前回のセッションが既にコンテキストをかなり使っていた場合、再開直後から上限に近い状態でスタートすることになる。
4. Skills・CLAUDE.mdの肥大化
Skillsは使う時だけSKILL.mdが読み込まれる設計になっているが、頻繁に呼び出すSkillが多いと、実行のたびにコンテキストへの負荷が積み重なる。CLAUDE.mdについても同様で、プロジェクトルールを詰め込みすぎると常駐コストが上がる。
実際に詰まった時の復旧手順（決定木）
冒頭の結論をもう少し具体的にする。
① /context を実行
→ 使用率が90%以上 → ②へ
→ 使用率に余裕があるのにエラーが出る → MCPツールの数を確認、不要なものを無効化してから再試行
② /compact に焦点を指定して実行
例: /compact 現在のプランと変更したファイル一覧だけ残して
→ 通った → 作業続行
→ /compact自体が「Prompt is too long」で弾かれる → ③へ
③ Esc を2回押して数ターン前まで巻き戻す
→ 巻き戻した状態で /compact を再試行
→ それでもダメ → ④へ
④ /clear で会話をリセット
→ 直近の作業内容をメモしてから実行するのが安全
→ 後で /resume を叩けば、過去セッションの一覧からjsonlファイル単位で内容を確認できる/clearしても会話ログそのものは消えない、という点は覚えておいて損はない。パニックになって闇雲に/clearを連打する前に、最低限「直前まで何をしていたか」だけメモに残しておくと、復旧後の手戻りがかなり減る。
二度と詰まらないための予防策
- 200+メッセージを超える見込みの長時間タスクは、区切りのいいところで能動的に
/compactしておく（自動コンパクションを待たない） - 使っていないMCPサーバーは
claude mcp listで洗い出して無効化する - ログファイルやCSVは
Readで全文読ませず、grepやoffset/limitで必要な範囲だけ渡す - CLAUDE.mdは定期的に棚卸しして、使っていないルールを削る
- 関係のないタスクに切り替える時は
--resumeで古いセッションを引きずらず、/clearか新規セッションで始める
FAQ
Q. Claude Codeのコンテキストの容量はどれくらい?
標準的なモデルで20万トークン。Opus/Sonnetの一部モデルでは100万トークン（1Mコンテキスト）まで拡張されている。どちらで動いているかは/contextで確認できる。
Q. コンテキストの上限に達すると必ずセッションが壊れる?
理屈の上では自動コンパクションが働くため壊れないはずだが、巨大ファイルの一括読み込みなど「一気にトークンが跳ね上がるケース」では自動対策が間に合わず、Prompt is too longのまま固まることがある。
Q. 「usage limit reached」と表示されたらプランをアップグレードすべき?
エラーメッセージに具体的なトークン数（○○ tokens > 200000 maximumなど）が含まれている場合はコンテキスト超過であって、実際の利用制限ではない。プラン変更の前に/contextを確認した方がいい。
Q. /clearすると会話が完全に消える?
表示上の会話はリセットされるが、セッションログ自体は~/.claude/projects/配下のjsonlファイルに残る。/resumeから過去セッションを辿れば内容を確認できる。
まとめ
Prompt is too longは「コンテキストウィンドウが埋まった」だけのシンプルなエラーに見えて、実際は「usage limit reached」への誤表示や、自動コンパクションをすり抜けるケースが絡んで厄介になる。詰まった時は慌てず/context→/compact(焦点指定)→巻き戻し→/clear+/resumeの順で対応すれば、大抵は作業を大きく失わずに復旧できる。予防策としては、長時間セッションでの能動的な/compactと、不要なMCPサーバーの整理が地味に効く。
