結論から言うと、Escキーを2回押して会話を巻き戻すだけで復旧した。
Claude Codeを長時間使っていたら、何を送っても「input is too long」系のエラーしか返ってこなくなった。慌てて/compactを打ったところ、今度は要約そのものが失敗。完全に詰んだ状態である。
この記事では、そのときの症状、自動compactが効かなかった理由、試せる対処法3つ、再発防止策をまとめる。Claude Code(特にAmazon Bedrock経由で従量課金している人)で同じエラーに当たった人の参考になればと思う。
症状:何を送ってもエラー、/compactも失敗
普通に指示を出しても、返ってくるのはリクエストが長すぎるという趣旨のエラーだけ。そこで会話を要約して軽くする/compactを実行すると、次のエラーが出た。
Error during compaction: API Error: 400 Input is too long.
何度/compactを打っても結果は同じだった。1Mコンテキストのモデルに切り替えてから/compactしても、やはり同じエラーで通らなかった。
要約しようとしても、要約のために会話全体を送る時点で上限を超えているため、どうにもならない状態だ。
原因:一発で溢れると自動compactは間に合わない
Claude Codeには、コンテキスト(会話の記憶量)が多くなると自動で要約する自動compactがある。それなのになぜ詰んだのか。
自動compactは、応答の合間に「そろそろ多いな」と判定して動く仕組みである。なので、1回の操作で一気に膨らむと判定が間に合わない。
- 上限の8割くらいで、まだ自動compactのラインに届いていない
- 大きいファイルや長いログを読む、サブエージェントが長い報告を返す、などで一度に大量に追加される
- 判定のタイミングが来る前に上限を超える
- 超えた後は、要約するにも全体を送る必要があるので
/compact自体が失敗する
つまり、じわじわ増えたなら自動で助かるが、一発で溢れると詰むということだ。
対処法3つ
上から順に試すのがおすすめだ。
| 対処法 | やること | コスト | 会話の文脈 |
|---|---|---|---|
| 1. 巻き戻して要約 | Escを2回押し、溢れる前のメッセージに戻ってから/compact |
追加なし | ほぼ残る |
| 2. 要約の時だけ1Mモデル | /model sonnet[1m]で切り替え→/compact→元のモデルに戻す |
要約1回分の割増 | 残る(私の環境では通らなかった) |
| 3. 仕切り直し | /clearして新しいセッションで再開 |
なし | 消える |
1. 巻き戻して要約:溢れさせた一手(大きいファイルの読み込みなど)を取り消せるので、一番効く。戻った後は限界ぎりぎりなので、すぐ/compactしておくこと。
2. 要約の時だけ1Mモデル:理屈の上では、1Mコンテキスト対応モデルなら全体を送れるので要約が通るはずである。ただし私の場合は、1Mモデルに切り替えても/compactは通らなかった(症状の節の画面)。確実な手ではないので、巻き戻しが使えないときに試す程度に考えておくのがよい。20万トークンを超えた分は割増料金になるため、試すなら要約が終わったらすぐ戻すこと。
3. 仕切り直し:作業結果がgitやファイルに残っているなら、新セッションで「リポジトリの状態を確認して続きをやって」と頼めば十分続けられる。
実際に直った手順
私の場合は、対処法1の巻き戻しで復旧した。
- Claude Codeの入力欄でEscキーを2回押す
- 過去のメッセージ一覧が出るので、エラーが出始める前のメッセージを選ぶ
- その地点から普通に応答が返るようになった
- 限界ぎりぎりなので、すぐに
/compactを実行
Escを2回押すと、次のような「巻き戻し」の画面が出る。ここに過去に送ったメッセージが並ぶので、戻りたい地点を選ぶ(メッセージの中身はぼかしている)。
溢れさせた原因は画像の読み込みだった
巻き戻して会話が動くようになったところで、Claude自身に原因を調べさせた。答えは、資料の見た目を確かめるために読み込んだ画像が多すぎたというものだった。
- この会話には画像が49枚(合計約28MB)入っていた。どれも資料を6ページずつ並べた大きな画像である
- 画像は1枚で数千トークン分になり、一度読み込むと会話から消えない
/compactも画像を含めた会話の全部を送ってから要約するので、要約の依頼そのものが上限を超えていた- その前の会話も、画像が86枚入ったところで同じエラーで止まっていた
資料作りでは、出来上がりをClaudeに画像で見せて確認させることが多い。1枚ずつは小さくても、確認を繰り返すうちに会話の中に画像が積み上がり、ある時点で一気に上限を超える。まさに「一発で溢れる」パターンだった。
再発防止
- タスクの区切りごとに
/clear:1つの会話を延々と使い続けない - 大きいログやファイルは丸ごと読ませない:「エラー部分だけ抽出して」「該当箇所だけ見て」と範囲を絞る
/configで自動compactがオンか確認:オフになっていると、じわじわ増えた場合も助からない- 調べ物はサブエージェントに任せる:サブエージェントは結果を要約して返すので、メインの会話が膨らみにくい
画像で確認するときの決まり
今回の原因だった資料の見た目確認は、次の順番でやるようにClaudeに覚えさせた。
- まずプログラムで調べる:字の大きさ、はみ出し、重なり、罫線の有無など、数値で測れるものは画像を見なくても検出できる
- 全ページを目で見るのはサブエージェントに任せる:1ページずつ見させ、「ページ番号・どこが・どうおかしいか」を決まった形で返させる。メインの会話に画像が溜まらない
- 問題と言われたページだけ、メインのClaudeが自分で見る:縮小せず、1ページを1枚で見る
- 最後に人が見る
画像を減らすと確認の精度が落ちないか気になったが、むしろ上がると考えている。理由は2つある。
- 6ページを1枚に並べた画像は、もともと粗かった:Claudeに渡した画像は自動で縮小される。今回は2000×1688で表示されていたので、1ページあたりは幅1000px程度しかなく、8〜9ptの字はほぼ潰れていた。1ページを1枚で見るほうが細かいはみ出しを見つけやすいし、1枚あたり約2,200トークンなので、数ページ見るくらいなら軽い
- サブエージェントの「問題なし」を鵜呑みにしない:要約だけ返されると、そのまま信じてしまう。場所と中身まで返させれば、見落としに気づける
一方で、プログラムで拾えるのは測れるものだけだ。今回いちばん厳しく指摘されたのは「何を言いたいか分からない」「色がごちゃごちゃ」といった読みやすさの問題で、これは機械では判定できない。最後に人が見る工程は外せない。
なお、画像が溜まってしまったチャットは、巻き戻して動くようになっても上限ぎりぎりのままで、/compactもできない。続けるとまた詰まるので、引き継ぎメモ(今の版のファイル名、終わったこと、残りの作業、決めたこと)をファイルに書かせてから新しいチャットに移るのがよい。記憶に書いた決まりは新しいチャットにも引き継がれるが、作業の進み具合は引き継がれないからだ。
おまけ:マルチエージェントにしたら請求が2.5倍になった話
実はこのトラブルの少し前、並行作業させたくて「リーダー1名＋メンバー3名」のチーム構成でClaudeを動かしてみた。結果、Bedrockの請求が普段の月の2.5倍以上に膨らんだ。
膨らんだ理由はシンプルで、メンバーは毎回まっさらな状態で始まるため、同じコードをそれぞれ読み直す。さらにリーダーが報告を読んで指示を書く、そのやり取り自体もトークンを使う。
マルチエージェントが効くのは、幅広い調べ物を並行で集めるような、互いに独立した作業だ。コーディングのように各パートが密に絡む作業では、品質はあまり上がらない。
今の結論はこうである。
- 並行作業したいなら、独立したタスクを別々のセッションに渡し、自分がリーダーになる
- 1つの作業は1セッションに任せる(必要なら勝手にサブエージェントを使ってくれる)
- サブエージェントは安いモデル(Sonnet等)に指定してコストを抑える
まとめ
- 「input is too long」で
/compactまで失敗したら、まずEsc 2回で巻き戻し - 1Mモデルに切り替えても
/compactは通らなかった。巻き戻しが使えなければ/clearで仕切り直し - 原因は「一発で溢れる」こと。大きいログやファイルを丸ごと読ませない、区切りごとに
/clearする、で予防できる - 私の場合は資料確認用の画像の溜めすぎが原因だった。画像での確認は問題のあるページだけにする
AIに任せる作業が増えるほど、こういう地味なトラブルとコスト管理が効いてくる。
コメント