Claude Code が API Error: 400 due to tool use concurrency issues を出したら、最初に見るべきなのは key、quota、障害、プロバイダーではありません。まず「ツール呼び出しの履歴が壊れていないか」を疑います。Claude Code の利用者は、現在の作業内容とエラー文を保存し、/rewind または Esc を2回押して壊れた tool turn の前に戻ります。Anthropic Messages API を自分で扱う開発者は、直前の assistant が出した tool_use と、次の user message に入る tool_result がすべて対応しているか、さらに tool_result が通常テキストより前に置かれているかを確認します。
| 利用面 | 先に見る所有者 | 最初の安全な対応 |
|---|---|---|
| Claude Code CLI | tool / thinking 履歴の不整合 | コンテキストを保存し、/rewind または Esc 2回、その後小さなツール操作で検証 |
| VS Code、Cursor、IDE 拡張 | 拡張やクライアントが保存した履歴 | 同じ小さな操作を CLI と IDE で比較し、すぐ再インストールしない |
| 自作 Anthropic API クライアント | tool_result の返し方 | すべての tool_use_id に結果を返し、同じ user message にまとめ、テキストより前に置く |
| 別の 400 文面 | schema、role、system、extra input の検証 | 実際の validation error に沿って直す |
| 429、529、500、接続、認証、請求 | 別系統の Claude エラー | rate、overload、server、network、account の分岐へ送る |
この段階で key を回す、quota を買う、プロバイダーを変える、障害と決めつける、という動きは早すぎます。Claude Code では、巻き戻し後に「1つのファイルを読む」「1つのディレクトリを列挙する」程度の小さな操作で復旧を確認します。API クライアントでは、秘密情報を除いた message shape を見て、role、block type、ID、結果数、順序を確認します。
この 400 が本当に示すもの
“tool use concurrency issues” という語感だけを見ると、同時に多くのツールを呼んだから失敗したように見えます。しかしこのエラーでは、並列数よりも「次のリクエストに載っている会話状態が正しいか」が重要です。Claude Code のエラー参照はこの文面を tool use または thinking block mismatch の文脈に置いており、Claude API の 400 は request format / content の invalid_request_error に属します。
つまり、モデルがあなたの作業目的を拒否しているのではありません。次のリクエストに含まれるツール履歴を API が続行できない、ということです。Claude Code では、長いセッション、途中停止した tool run、IDE 拡張の保存状態、手動編集、履歴圧縮などが原因になります。自作クライアントでは、tool_result の欠落、複数 message への分割、テキストを先に置く実装、ID の取り違えがよくある原因です。
この見方をすると、通常チャットがまだ動くのにファイル操作だけ失敗する理由も説明できます。テキストだけの会話は tool/result のペアを必要としません。一方で Read、Edit、Bash、Search などは、tool call と result の対応、順序、role、content block type に依存します。
Claude Code の作業を失わずに戻す
最初の行動は、壊れた履歴を持ち歩くことではなく、人間が使える作業状態を保存することです。現在の目的、触っているファイル、直前の操作、完全なエラー文、時刻、CLI か IDE か、通常チャットが動くかをメモします。これは transcript の丸ごと保存ではありません。後で新しいセッションに移る場合にも安全に持ち込める情報を作るためです。
次に利用面を分けます。CLI で出たなら Claude Code のバージョンを確認し、古ければ更新を検討します。VS Code や Cursor で出たなら、同じ小さな tool action を CLI で試します。CLI で動くなら、急ぎの作業は CLI に戻し、IDE 側のエラー、拡張バージョン、再現操作を別に記録します。CLI でも同じ会話が失敗するなら、まず会話履歴を戻します。
/rewind は、壊れた tool turn の前に戻るための最小破壊の手段です。Esc を2回押す操作も、会話の前段階に戻る手段として扱えます。戻した直後は、大きな複合指示を出さないでください。複数ファイルの修正、テスト、検索、調査を同時に投げるのではなく、1つの小さな tool action で検証します。
それでも同じ exact error が出るなら、新しいセッションを検討します。ただし、古い transcript を丸ごと貼らないことが重要です。持ち込むのは、作業要約、必要なファイル名、最後に信頼できた状態、脱機密化したエラー証拠だけです。壊れた tool history を貼ると、新しい会話でも同じ問題を再現します。
IDE、Cursor、VS Code では surface を切り分ける
IDE 経由のエラーでは、通常の返答は続くのにファイル操作だけ落ちることがあります。これは「ユーザーが多すぎるツールを同時に使った」とは限りません。IDE 拡張が途中の状態を保持している、CLI との bridge が古い履歴を再送している、remote environment のバージョンが違う、あるいは拡張側だけが壊れた tool turn を持っている、という場合があります。
順番は明確です。まず surface を記録します。Claude Code CLI、VS Code、Cursor、remote SSH、WSL、terminal multiplexer、または別の wrapper か。次に、同じ小さな操作を CLI と IDE で比べます。3番目にバージョンを見ます。再起動、更新、再インストール、過去バージョンへの戻しは、証拠を保存してからで十分です。
IDE が失敗し CLI が動くなら、作業の継続は CLI に逃がせます。CLI と IDE の両方が同じセッションで失敗するなら、IDE だけを原因にせず、会話の巻き戻しを優先します。新しいセッションでも同じ小操作が失敗する段階で、初めて issue や support に出す材料が揃います。
日本語の説明では「再起動」「ログアウト」「認証し直し」が先に出やすいですが、この exact 400 の中心は tool history です。認証や課金の文面が出ていない限り、ログインし直しは補助確認であって主修復ではありません。
自作 API クライアントでは messages の形を見る
Anthropic Messages API を直接使う agent、IDE integration、backend runner では、エラーの原因が人の prompt ではなく messages 配列にあります。assistant が1つまたは複数の tool_use を出したら、クライアントはそれらを実行し、次の user message で結果を返します。このとき実行は並列でも順番でも構いませんが、返し方は厳格です。
守るべきことは3つです。各 tool_use.id に対応する tool_result.tool_use_id があること。同じ assistant turn の結果を次の user message にまとめること。結果ブロックを通常テキストより前に置くことです。tool_result の前に「結果を取得しました」と書く実装は、人間には自然でも API には壊れた形になります。
| 実装ミス | なぜ壊れるか | 修正 |
|---|---|---|
1つの tool_result が欠ける | assistant の tool request が閉じない | 各 ID に結果を返すか、壊れた tool turn 全体を replay history から外す |
| 結果を複数 user message に分ける | 1つの assistant turn の結果集合が途切れる | 次の user message にまとめる |
文字を tool_result より前に置く | 結果 block が先でなければならない | 先に全結果、その後に必要な説明を書く |
| history compaction が tool block を消す | ペアや thinking 連続性が壊れる | tool_use / tool_result を丸ごと残すか丸ごと外す |
ログに残すべきなのは shape です。role の順番、block type、tool ID、結果数、結果の置き場所を見ます。API key、token、私有ファイル、顧客データ、機密 transcript はログに入れません。serializer の validator を tool runner の近くに置くと、API に送る前に壊れた request を止められます。
並列実行は可能、ただし結果の返却は一括
並列 tool use 自体は禁止されていません。Claude は一度の assistant message で複数の tool call を出すことがあります。クライアントはそれらを同時に実行しても、順番に実行してもよいです。厳しいのは戻す形です。同じ assistant turn から出た結果は、ID を合わせて、次の user message にまとめて返します。
したがって「今後は並列にしない」だけでは不十分です。実行を逐次にしても、serializer が ID を落とす、結果を分ける、テキストを前に置く、古い history を壊す、という動きをすれば同じ 400 が出ます。逆に結果を正しく集められるなら、並列実行は有効な実装です。
disable_parallel_tool_use は、外部システムが side effect に弱い、複数 tool の aggregator が未完成、順次実行しか安全に扱えない、といった実装上の制限があるときに使います。これは順序ルールの代替ではありません。単一 tool call でも、matching result を正しい場所に返す必要があります。
production runner では、assistant tool_use.id ごとの matching result、余分な result の有無、同一 turn の result 集合、tool_result が text より前にあること、replayed history が必要な tool/thinking block を消していないことを送信前に確認します。
長いセッション、停止、履歴圧縮で再発する理由
Claude Code の長い会話は、普通のテキストだけでなく機械的な状態も持っています。tool run を途中停止した、stream を切った、IDE が半端な state を保存した、手動で history を編集した、agent framework が messages を圧縮した、という出来事があると、次の request は見た目より壊れていることがあります。
再発したときは「また同時実行したのか」よりも「直前に transcript がどう変わったか」を見ます。停止した tool call はあったか。古い transcript を新しい会話に貼ったか。compaction が tool result を消したか。tool set を途中で変えたか。user message の先頭に通常テキストを挿入していないか。
| 状況 | リスク | 安全な戻し方 |
|---|---|---|
| tool run を停止した | 半端な tool state が残る | その tool turn の前へ戻し、小操作で検証 |
| history を編集または圧縮した | 必要な tool / thinking block が消える | 人間向け要約から始め、transcript をコピーしない |
| IDE だけ失敗する | extension state または bridge が壊れる | CLI と比較し、version と最小操作を保存 |
| アプリが stored messages を replay する | serializer が順序や ID を変える | API call 前の exact message array を検証 |
「もう一度試して」「並列を避けて」と言うだけでは、壊れた history は直りません。安定した解決は、壊れた turn の前に戻るか、API request の tool result protocol を正しい形に戻すことです。
別の 400 と別の Claude エラーは混ぜない
同じ HTTP 400 でも、文面が違えば分岐も違います。extra inputs、unsupported role、invalid system、malformed JSON、model parameter error などは request validation の問題であり、tool/result history mismatch とは限りません。API Error: 400 due to tool use concurrency issues という exact phrase があるかどうかを見てください。
| 症状 | 適切な分岐 |
|---|---|
| extra inputs、unsupported role、invalid system、malformed JSON を含む 400 | schema / parameter validation |
| tool call、edited history、long session の後に出る 400 | tool/result または thinking-block mismatch |
| 429 または rate limit reached | account、workspace、model pressure、quota |
529 overloaded_error | capacity と bounded retry |
| 500 または 504 | server error、timeout、request_id、status check |
API Error: Connection error | network、VPN、proxy、DNS、TLS、SDK timeout |
| auth、billing、credits | account、project、organization、payment、credential |
Claude Status は確認してよいですが、この exact 400 の主証拠ではありません。2026年7月4日に保存した status snapshot では Claude API と Claude Code は operational でした。それは当時の全体障害の有無を見る材料であって、あなたの IDE state や messages array が正しい証明ではありません。
issue や support の前に証拠を整理する
使える証拠は、秘密を含まなくても作れます。Claude Code version、IDE extension version、実行面、正確なエラー文、時刻と timezone、操作種別、通常チャットの動作、/rewind や Esc 2回の結果、CLI と IDE の比較、自作 API クライアントなら脱機密化した message shape をまとめます。
送ってはいけないものは明確です。API key、token、私有ファイル、顧客データ、完全な機密 transcript は不要です。serializer 問題では、assistant turn にどの tool_use ID があり、次の user message にどの tool_result ID が返り、結果が分割されていないか、文字より前にあるかが分かれば十分です。
この整理は再発予防にもなります。古い tool turn を手で削らない。tool_result の前に自然文 summary を挿入しない。1つの assistant turn の results を複数 message に分けない。status が green だから request shape も正しい、とは考えない。新しい会話に移るなら、壊れた履歴ではなく人間向け要約を持ち込んでください。
FAQ
/rewind、Esc 2回、/clear、新規セッションのどれを使うべきですか？
まず /rewind または Esc 2回です。壊れた tool turn の前へ戻りつつ、作業コンテキストを多く残せるからです。/clear や新規セッションは、小さな検証操作がまだ失敗するときに使います。
普通の会話は動くのに、ファイル操作だけ失敗するのはなぜですか？
普通の会話は tool/result pairing を必要としません。ファイル読み取り、編集、bash、検索は tool state に依存します。ID、順序、block type が壊れると tool action だけが失敗します。
本当にツールを同時に使いすぎたという意味ですか？
必ずしもそうではありません。実際の multi-tool turn の後にも起きますが、停止、編集、履歴圧縮、拡張 state、欠けた result、分割 result、text before tool_result でも起きます。
API key を変えるべきですか？
この exact error では最初に変えるべきではありません。新しい key は malformed message history を直しません。auth や credential を示す文面が出たときだけ、その分岐に進みます。
parallel tool use を無効化すれば解決しますか？
クライアントが複数結果を安全に集められない場合や side effect がある場合には有効です。ただし、無効化しても tool_result の対応と順序は必要です。
Claude Status は見なくてよいですか？
見る価値はあります。複数の経路が同時に失敗するなら status を確認してください。ただし exact 400 が続くなら、復旧の中心は会話の巻き戻しと message shape の修正です。
GitHub issue や support ticket には何を書くべきですか？
version、surface、正確な error text、time、operation type、ordinary chat の状態、/rewind の結果、CLI と IDE の比較、脱機密化した message shape を書きます。key、token、私有ファイル、完全な transcript は出しません。
いつ現在のセッションを諦めるべきですか？
/rewind 後、同じ小さな tool action が1回から2回連続で同じ exact error を出すなら、証拠を保存して clean session に移ります。持ち込むのは要約であり、壊れた tool history ではありません。
