Claude Code「Tool Use Concurrency」エラーの原因と対処法
「due to tool use concurrency issues」400エラーの原因、GitHub issueに共通する発生条件、/rewindでの復旧手順、バージョン別の修正経緯をまとめます。
Claude CodeでAPIエラー400とともに「due to tool use concurrency issues」という文言が出ると、そのターンの応答が止まります。原因は会話履歴に含まれるtool_useとtool_resultの対応関係が崩れ、Anthropic APIがリクエストを受け付けなくなった状態です。何がこの崩れを引き起こすのか、Claude Code側の修正はどこまで進んでいるのかを、GitHub issueの報告と公式changelogを突き合わせて確認します。
「Tool Use Concurrency」エラーとは
エラーメッセージの全文は次のとおりです。
API Error: 400 due to tool use concurrency issues. Run /rewind to recover the conversation.公式のエラーリファレンスは、このメッセージを「tool use or thinking block mismatch」という区分の1パターンとして扱っています。会話履歴の中でtool_useブロックとそれに対応するtool_resultブロックの並び順が、APIの想定と食い違った状態です。多くはツール呼び出しの途中でセッションが中断されたり、送信済みのターンを編集して巻き戻したりしたときに起きます。
同じ区分には表記の異なる2つのエラーもあります。
unexpected tool_use_id found in tool_result blocksthinking blocks ... cannot be modified
公式ドキュメントは3つとも同じ原因の別表現として扱っており、対処法も共通です。拡張思考(thinking)ブロックが絡むケースと、Opus 4.7/4.8のバージョン起因のケースはthinking block mismatchエラーの原因とrewindでの直し方で個別に扱っています。tool_use/tool_resultの整形ルールそのもの(なぜ並列呼び出しが崩れるか)はtool_resultとtool_useの400エラー — 正しい整形ルールにまとめました。ここではClaude Code CLIで「concurrency issues」という文言とともに出るケースの発生条件と復旧手順に絞ります。
発生条件 — 複数のissueに共通するパターン
GitHub issueの報告(#9002、#8004、#8903、#8931など)を突き合わせると、発生条件は大きく3パターンに分かれます。
| きっかけ | 具体的な状況 |
|---|---|
| Stop hookのブロック中に発言する | 具体的な状況decision: "block"で継続を要求しているStop hookの処理中に、新しいメッセージを送るか新しいツール呼び出しが割り込む |
| 複数ファイルの並列読み込みを中断する | 具体的な状況PDFなど複数のファイルを並列で読み込んでいる最中に、ほかの操作が割り込むか処理が長引く |
| 中断が効かずセッションが分岐する(#8004) | 具体的な状況中断がうまく反映されず、実行中の処理と中断後の処理の両方が並行して進み、メッセージが混線する |
WajahatMubashir氏はissue #9002で、複数のPDFファイルを並列で読み込みながら別の作業も並行させていたときにエラーが出たと報告しています。PDFを1つずつ順番に読ませるよう指示を変えたところ、再発しなくなったとのことです。werdnum氏はissue #8004で、Stop hookの完了前にユーザーがメッセージを送ると、実行中のスレッドと中断後のスレッドが分岐し、両方の発言が混ざり合うと説明しています。issue #8903ではVS Code拡張(Windows 11、Claude Code 2.0.5)でPDFファイルとJavaファイルを同時に解析している最中に同じエラーが報告されており、特定の環境や作業内容に限らず起きることがうかがえます。
会話ログを直接調べた利用者の報告は、原因の現れ方が一様でないことも示しています。knail1氏がissue #8004で共有した自己診断では、tool_useとtool_resultの対応自体はすべて揃っていました。それでもアシスタントの発言だけが18件連続するなど、本来交互になるはずのメッセージ順そのものが崩れていました。いずれのケースでも共通するのは、ツール呼び出しが完了する前に別の入力が会話へ割り込む点です。
Stop hookでdecision: "block"を使い、テストが通るまで終了させないといった継続の仕組みを組んでいる場合は注意が必要です。400エラーでターンが終わったときに発火するのは通常のStop hookではなく、継続の仕組みを持たないStopFailureフックです。Stop hook側のdecisionやadditionalContextはそこでは働かないため、このエラーからの自動復旧をStop hookの継続ロジックだけに頼る構成は機能しません。kcindric氏はissue #9002で、pre/postの各hookをすべて無効にしたところ発生しなくなったと報告しています。ただし本人も「今のところの回避策であって根本解決ではない」と付け加えており、hooks自体が原因というより、hooksがツール呼び出しへの割り込みの機会を増やす分だけ発生条件に近づく、という位置づけです。
今すぐ復旧するには
公式ドキュメントが挙げる対処は2段階です。
- Opus 4.7またはOpus 4.8を使っている場合は、まず
claude updateでバージョンを更新します。v2.1.156より前はこのエラーを通常のツール利用中にも引き起こすことがあり、/rewindを実行しても状態がクリアされません。 /rewindを実行するか、プロンプト入力欄が空の状態でEscを2回押して、壊れる前のチェックポイントまで会話を巻き戻します。
Opus 4.7/4.8の場合、崩れているのは会話履歴そのものではなく、当時のClaude Code側の実装がAPIとのやり取りを誤って不整合にしていた点です。/rewindで巻き戻しても同じ不整合が再現されるため、まずバージョンを上げてから操作をやり直す必要があります。
/rewindGitHub issueの報告では、/rewindが効かない場合の代替策も複数出ています。セッションを終了して-cや--resumeで再開する方法は、壊れたtool_use/tool_resultの並びを含む会話履歴を丸ごと復元するため、同じエラーが再発したという報告がありました。一方、-cを付けずに完全に新しいセッションを起動し、そこから会話をやり直したところ復旧したという報告もあります。同じ「再開」でも、既存の履歴を引き継ぐか引き継がないかで結果が分かれます。反対に/compactで会話を要約したところ症状が収まったという報告もあります。最終手段は/clearで会話を打ち切ることですが、これは巻き戻しではなく削除なので、それまでの文脈が失われます。
バージョン別に見る修正の経緯
「concurrency issues」の報告が集中したのは2025年10月、Claude Code 2.0系のリリース直後でした。issue #9002には自動応答のbotが「重複候補」として#8004・#8903・#8931の3件を提示しており、同じ時期に同種の報告が複数のissueへ分散していたことがわかります。公式changelogを遡ると、この系統のエラーに関わる修正は複数のバージョンに分かれて入っています。
| バージョン | 公開日 | 修正内容 |
|---|---|---|
| v2.1.7 | 公開日2026年1月14日 | 修正内容ストリーミング実行中に一部のツールが失敗したときの、対応先を失ったtool resultエラーを修正 |
| v2.1.9 | 公開日2026年1月16日 | 修正内容長時間セッションで並列ツール呼び出しが、対応先を失ったtool resultブロックのAPIエラーで失敗する不具合を修正 |
| v2.1.69 | 公開日2026年3月5日 | 修正内容ツールバッチの途中で中断したセッションを再開したときの、フォーク済みエージェントのAPI 400エラーを修正 |
| v2.1.218 | 公開日2026年7月22日 | 修正内容中断されたツール呼び出し後の偽の割り込みメッセージと、応答が中断で終わったときに履歴へ残る対応先なしのtool_useブロックを修正 |
issue #9002が報告されたのはv2.0.8で、上の修正が入るより前のバージョンです。複数回にわたって修正が重ねられてきた経緯から、単発のバグではなく、ツール呼び出しの中断や並行実行にまつわる問題が繰り返し表面化してきたことが分かります。issue #8903は報告者自身が「症状が自然に消えた」として完了扱いで閉じました。issue #8004は無活動を理由に自動クローズされています。いずれも特定の修正コミットへの直接の紐づけは公開されていません。
紛らわしい「concurrency」がつく別の設定
Claude CodeにはCLAUDE_CODE_MAX_TOOL_USE_CONCURRENCYという、名前が似た環境変数があります。読み込み専用のツールとサブエージェントが並列実行できる最大数を決める設定で、既定値は10です。
ただし公式ドキュメントがこの環境変数を対処として挙げているのは、今回の400エラーではなくRequest rejected (429)というレート制限エラーの節です。並列実行数が多すぎてAPIキーやBedrock/Vertexプロジェクトのレート制限に達したときに、この値を下げる対処が案内されています。既定値の10を超える並列実行が必要な自動化スクリプトでは値を上げることもできますが、上げるほどレート制限に達しやすくなる点は変わりません。
| エラー | ステータスコード | 原因 | 対処 |
|---|---|---|---|
due to tool use concurrency issues | ステータスコード400 | 原因会話履歴のtool_use/tool_resultの対応関係が崩れた | 対処/rewind(Opus 4.7/4.8は先にclaude update) |
Request rejected | ステータスコード429 | 原因並列実行数がAPIのレート制限を超えた | 対処CLAUDE_CODE_MAX_TOOL_USE_CONCURRENCYを下げる |
どちらも「concurrency」という語が絡みますが、崩れているものと対処はまったくの別物です。エラーメッセージのステータスコードで見分けます。
よくある質問
/rewindを使うと作業内容は消えますか
チェックポイントを選ぶときに「Restore conversation」を選べば、コードの変更は維持したまま会話だけを巻き戻せます。ファイル編集も含めて戻したい場合は「Restore code and conversation」を選びます。操作の詳細はClaude Code rewindコマンドで/clear前まで戻るにまとめています。
まとめ
「Tool Use Concurrency」エラーは、ツール呼び出しの中断やStop hookのブロック中の割り込みによって会話履歴の対応関係が崩れたときに、Claude Codeが返す400エラーです。まず/rewindで壊れる前のチェックポイントに戻り、Opus 4.7/4.8を使っているならその前にclaude updateを済ませます。Anthropicはv2.1.7からv2.1.218にかけてこの系統の不具合を段階的に修正しており、報告が集中していたころとは状況が変わっています。