結論：v2.1.186以降のシェルモードは「! npm test を叩いた瞬間に、失敗ログをClaudeが勝手に読んで解説してくれる」。テスト→失敗→解説→修正のループから、人間がエラーをコピペして貼る手間が消えます。
- シェルモード（
!プレフィックス）の出力に、Claudeが自動で応答する挙動が追加された（コストは通常プロンプトと同じ） - 旧来の「出力をコンテキストに足すだけで返答しない」挙動に戻すには
respondToBashCommandsをfalseにする - テスト・lint・型チェックを
!で回すだけで、デバッグ駆動の開発ループが回り始める
対象読者：Claude Codeでテスト・デバッグを回すエンジニア／PM。今日できること：1コマンド設定を確認して、! npm test 1回で「失敗の自動解説」を体験する。
正直、これまでのClaude Codeでのデバッグって、地味に二度手間だったんですよね。ターミナルで ! npm test を叩いて、赤いスタックトレースが出る。それをClaudeに読ませたいから、結局「このエラー直して」ともう一度プロンプトを打つ。出力はコンテキストには入っているのに、Claudeは黙って待っている――この「もう一回聞く」のひと手間が、1日に何十回も積もると地味にストレスでした。
2026年6月22〜26日（公式のWeek 26ダイジェスト、v2.1.186）で、ここがアップデートされました。!で実行したコマンドの出力が会話に流れ込んだ瞬間に、Claudeがそのまま応答してくれる。! npm test を打つだけで、追加のプロンプトなしに失敗の原因解説が返ってくるようになったんです。この記事では、この新挙動を軸に「テストを回す＝デバッグが進む」フローの作り方を、実際のコマンドと設定キーつきで解説します。
そもそもシェルモード（!プレフィックス）とは何か
Claude Codeのプロンプト入力欄で、行頭に ! を付けると「シェルモード」になります。これはClaudeを経由せず、直接シェルコマンドを叩ける入力モードです。公式のInteractive modeリファレンスでは、シェルモードの挙動が次のように定義されています。
# プロンプト入力欄でそのまま打てる
! npm test
! git status
! ls -laシェルモードがやってくれることは、ざっくりこうです。
- コマンドとその出力を会話のコンテキストに追加する
- 進捗・出力をリアルタイム表示する
- Claudeに解釈・承認させる必要がない（自分で叩く前提なので許可ダイアログが出ない）
Ctrl+Bで長時間コマンドをバックグラウンド化できる（普通のBashツール呼び出しと同じ）- 空のプロンプトで
Escape/Backspace/Ctrl+Uを押すとシェルモードを抜ける
ポイントは「Claudeの会話履歴を保ったまま、自分の手でコマンドを叩ける」こと。普段の対話の流れを切らずに、その場で git status を確認したり、テストを回したりできる窓口だと思ってください。
v2.1.186で何が変わったのか：出力にClaudeが「自動応答」する
ここが今回の本題です。公式ドキュメントには、はっきりこう書かれています。
As of v2.1.186, Claude responds to the command output automatically once it lands in the transcript, so you can run
! npm testand get an explanation of the failures without a second prompt.（v2.1.186以降、出力がトランスクリプトに入った時点でClaudeが自動的にそのコマンド出力へ応答する。! npm testを打てば、二度目のプロンプトなしに失敗の解説が得られる）
つまり、v2.1.186より前は「シェルモードの出力はコンテキストに足すだけで、Claudeは返答しなかった」。v2.1.186以降は「出力が記録された瞬間に、Claudeが勝手に読んで解説する」に変わったわけです。
具体的な流れはこうなります。
> ! npm test
FAIL src/utils/parseDate.test.ts
x returns null for invalid input (12 ms)
Expected: null
Received: Invalid Date
# ↓ ここで「直して」と打たなくても、Claudeが自動で続ける
parseDate が不正な入力に対して Invalid Date を返しています。
null を返す前に isNaN(d.getTime()) のチェックを足すと…
テストの失敗ログが出た瞬間に、Claudeが原因を読み解いて次の一手を提案してくれる。エラーをコピペして「これ直して」と打ち直す動作が、まるごと不要になりました。
コストの注意：公式ドキュメントいわく、この自動応答は「通常のプロンプトを送るのと同じコスト（The response costs the same as sending a normal prompt）」です。!を叩くたびにLLM呼び出しが1回走る、と理解しておきましょう。! ls -la のような確認系まで毎回Claudeに解説させたくない場合は、後述の respondToBashCommands で挙動を切り替えます。
旧挙動に戻す：respondToBashCommands 設定キー
「!を叩くたびに毎回Claudeが喋るのはうるさい」「確認コマンドにまで課金されたくない」――そういうケースのために、公式settingsドキュメントに respondToBashCommands が用意されています。settings.json に次を書くと、v2.1.186より前の「出力をコンテキストに足すだけ・返答しない」挙動に戻ります。
{
"respondToBashCommands": false
}判断軸はシンプルです。
true（デフォルト）が向く人：テスト・lint・型チェックを!で回して、失敗をその場で解説させたい。デバッグ駆動でゴリゴリ進める使い方falseが向く人：!は「コンテキストに事実を流し込む窓口」として使い、解説させたい時だけ明示的に普通のプロンプトを打つ。コスト・ノイズを抑えたい使い方
settings.json の置き場所や優先順位（ユーザー設定とプロジェクト設定の上書き関係）が曖昧な人は、Claude Codeのsettings.json設定ガイドを先に読んでおくと、このキーを安全に効かせられます。
デバッグ駆動フローの組み立て方：3ステップ
自動応答を前提に、僕が実際に使っているデバッグループを紹介します。難しい設定は要りません。
ステップ1：失敗するテストを!で回す
修正対象のテストだけを絞って回します。全テストを回すとログが膨らんでコンテキストを食うので、まずは対象ファイルだけに絞るのがコツです。
! npm test -- src/utils/parseDate.test.ts出力が流れた瞬間、Claudeが失敗の原因を解説してくれます。ここで「どこをどう直すか」の仮説が立ちます。
ステップ2：修正させて、また!で回す
解説を読んで方針に納得したら、普通のプロンプトで「その方針で直して」と指示。修正が入ったら、もう一度同じテストを!で回します。
! npm test -- src/utils/parseDate.test.tsグリーンになれば、Claudeが「通りました」と確認してくれる。赤のままなら、また自動で次の原因を解説してくれる。この「回す→読む→直す→回す」の往復で、エラーログを人間が貼り直す動作がゼロになります。
ステップ3：lintと型チェックも同じループに乗せる
テストが通ったら、同じ要領でlintと型チェックを!で流します。
! npm run lint
! npx tsc --noEmitどれも失敗時にはClaudeが原因と直し方を返してくれるので、「テスト・lint・型」の3点セットを、対話を切らずに一気通貫で潰せます。テスト自動化そのものをClaude Codeで設計したい人は、Claude Codeのテスト自動化ガイドも合わせて読むと、ループの前段（テストをどう書かせるか）が固まります。
地味に効く小ワザ：シェルモードは履歴ベースのオートコンプリートに対応しています。コマンドの一部を打って Tab を押すと、同じプロジェクトで過去に打った ! コマンドから補完されます（公式Interactive mode記載）。! npm test -- src/utils/... みたいな長いコマンドを毎回打たずに済むので、ループの回転が速くなります。
つまずきポイントと回避策（NG→OK）
便利な一方で、「思ってたのと違う」が起きやすいポイントもあります。実際にハマったものを挙げておきます。
NG：全テストを!で回してコンテキストを溶かす
つい ! npm test で全件回したくなりますが、失敗が多いプロジェクトだとログが巨大になり、コンテキストを一気に消費します。
OK：対象ファイル・対象スイートだけに絞る。! npm test -- <file> や -t "テスト名" で範囲を狭めてから回す。
NG：確認コマンドにまで毎回課金されてモヤる
! ls -la や ! git status のような「ただ見たいだけ」のコマンドにまでClaudeが解説を返すと、コストもノイズも増えます。
OK：用途で設定を切り替える。デバッグ集中セッションは respondToBashCommands: true、普段の確認多めのセッションは false にして、解説が欲しい時だけ普通のプロンプトを打つ。
NG：長時間コマンドでセッションがブロックされる
ビルドや開発サーバー起動を!で叩くと、終わるまで待たされることがあります。
OK：Ctrl+B でバックグラウンド化する。シェルモードは普通のBashツールと同じく Ctrl+B での背面実行に対応しています（tmux環境では2回押し）。
NG：試行錯誤で会話を /clear して、直前の文脈を失う
デバッグでガチャガチャ試した後に /clear して、「あの解説どこいった」となるパターン。
OK：/rewind で /clear 前の会話に戻れるようになりました（同じくWeek 26のアップデート）。チェックポイントと巻き戻しの詳しい使い方はClaude Code rewindで巻き戻す｜会話とコード復元にまとめています。
v2.1.186前後で挙動を比較する
| 項目 | v2.1.186より前 | v2.1.186以降（デフォルト） |
|---|---|---|
!コマンドの出力 |
コンテキストに追加するだけ | コンテキストに追加＋Claudeが自動応答 |
| 失敗の解説を得るには | もう一度プロンプトを打つ必要あり | 追加プロンプト不要（その場で解説） |
| コスト | 出力追加のみ（応答課金なし） | 応答1回ぶん＝通常プロンプトと同コスト |
| 旧挙動への戻し方 | ― | respondToBashCommands: false |
この差分を頭に入れておくと、「なんで急にClaudeが喋るようになったの？」「課金が増えた気がする」という戸惑いの正体がすぐ分かります。デバッグやトラブルシュート全般のワークフローを底上げしたい人は、Claude Codeでデバッグ・障害調査を効率化する実践ガイドと、保存・通知まで自動化するClaude Code Hooksでフォーマット・テスト・通知を自動化する方法を組み合わせると、ループ全体が自走し始めます。
今日からできる3アクション
- バージョンを確認する：
! claude --versionを叩いて、v2.1.186以降になっているかチェック。古ければ更新する。 ! npm testを1回だけ体験する：失敗するテストがあるプロジェクトで!を叩き、「追加プロンプトなしで解説が返る」感覚を確かめる。- 自分の運用に合わせて
respondToBashCommandsを決める：デバッグ集中ならtrue、確認多めならfalse。settings.jsonに1行足すだけ。
次回予告：このデバッグループに autoMode.classifyAllShell（Week 26で追加された、Bash/PowerShellを自動モード分類器に通す設定）や sandbox.credentials（サンドボックス実行のクレデンシャル保護）を組み合わせて、「安全に・自動で回るデバッグ環境」を作る方法を掘り下げます。
Claude Codeの実装フローを、チームの現場に落とし込みたい方へ
「機能は分かったけど、自社の開発フローにどう組み込むか」でつまずく方が多いです。Uravationでは、Claude Codeの個別指導・導入支援を通じて、テスト駆動・デバッグ駆動のワークフロー設計を現場ごとに伴走しています。まずは無料相談からどうぞ。
著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援を手がける。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載7回執筆。
出典：
Anthropic「Week 26 · June 22-26, 2026（What’s new）」／
Anthropic「Interactive mode – Shell mode with ! prefix」／
Anthropic「Settings（respondToBashCommands）」。バージョン・コマンド・設定キーは2026年6月時点の公式ドキュメントに基づく。
