Monitor（モニター）

長時間走るログやCI・dev serverをClaudeに裏で見張らせて、何か起きたら即対応してほしい人向け

Monitor は、Claude Code が「何かが起きるまで裏で見張り続けて、変化があった瞬間に会話に割り込んでくる」ための内蔵ツールです。ログを流しっぱなしにして待つ、CIの状態を一定間隔で見に行く、フォルダの中身が変わるのを待つ。こういう「いつ起きるか分からないイベント」を Claude 側に任せられる仕組みで、v2.1.98 以上で使えるようになりました。

ユーザーが直接「Monitor」と打って叩くものではありません。「dev server の出力を見張ってて、エラーが出たらすぐ言って」と頼むと、Claude が裏で小さな見張りスクリプトを書いて走らせる。これが Monitor の発火パターンです。

噛み砕くと

Monitor は「Claude 専属の見張り役」みたいなものです。会議室で打ち合わせしてる横で、誰かが入口に立って「来客があったら知らせます」と言ってくれてる状態に近い。会議は止めずに進めて、来客があった瞬間だけその人が割り込んで報告してくれる。

Bash の run_in_background:true も裏で走らせる仕組みですが、こちらは「実行が終わったあとにまとめて結果を取りに行く」スタイル。Monitor は違って、出力が1行来るたびに Claude がそれを読んで反応します。リアルタイムに反応してほしいか、終わってから結果を見ればいいか、で使い分けます。

大事な前提：使えない環境がはっきり決まっている

Monitor は Anthropic 公式の Claude Code v2.1.98 以上が前提です。それ以前のバージョンには入っていません。さらに、下記の環境では Monitor 自体が呼び出せません。ここを知らずに「動かない」と詰まる読者が多そうなので最初に書いておきます。

• Amazon Bedrock 経由で Claude を使っている場合
• Google Vertex AI 経由で Claude を使っている場合
• Microsoft Foundry 経由で Claude を使っている場合
• DISABLE_TELEMETRY がセットされている場合
• CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC がセットされている場合

クラウドベンダー経由で Claude を呼んでいる読者は Monitor が出てこないので、別ルートを考える必要があります。公式ドキュメントの記述ママです。

「Next.js の dev server を裏で見張らせる」を例に、実際の手順を見る

具体的な題材で動きを追います。題材は「Next.js で作っている Web アプリの dev server を起動した状態で、TypeScript のエラーが出たら Claude がすぐ修正案を出してくれる」状態を作ること。Monitor を使う典型例なので、ここの流れを覚えると他の見張り用途にも応用できます。

ステップ1: プロジェクトを開いて Claude Code を起動

普通に Claude Code を起動するだけです。プロジェクトのフォルダに入って claude と打ちます。

$ cd ~/projects/my-next-app
$ claude

ステップ2: Claude に「dev server を見張ってて」と頼む

ここがポイントです。ユーザーが「Monitor」と直接打つことはありません。日本語で意図を伝えると、Claude 側が裏で Monitor を発火させます。

You: npm run dev を起動して、TypeScript のエラーが出たらすぐ教えて。
     エラーが出たらそのファイルを見て修正案を出してくれていい。

ステップ3: Claude が見張りスクリプトを書いて、許可を求めてくる

Claude は内部で見張り用の小さなスクリプトを作って、Monitor 経由で走らせようとします。このとき Bash と同じ許可ルールが効くので、初回は「npm run dev を裏で走らせていい？」みたいな許可ダイアログが出ます。許可すると見張りが開始されます。

ステップ4: ユーザーは別の作業を続ける

ここが Monitor の独特なところで、見張りを走らせたまま会話を続けられます。「ついでにこのコンポーネントのスタイル直して」とか別の依頼ができる。dev server は裏で動き続けています。

ここで初心者がやりがちな勘違い、Monitor を起動した直後の Claude は「ぼーっと黙って待ってる」わけではありません。普通に他の指示を聞きながら、裏で来る出力行を1行ずつチェックし続けています。

ステップ5: TypeScript エラーが出ると、Claude が会話に割り込む

あるタイミングで dev server が Type error: Property 'price' does not exist on type 'Fish'. みたいな出力を出すと、Monitor 経由でその1行が Claude に届きます。Claude は会話の流れを止めて「いま dev server からエラーが出ました。src/data/fishes.ts の型定義を見直す必要があります」と割り込みます。

ステップ6: 見張りを止めたいときは、頼んで止める

「もう dev server の見張りは止めていい」とか「セッションを終わる」のどちらかで Monitor は止まります。プロセスが消えるので置きっぱなしの心配は要りません。

You: dev server の見張り止めていいよ。
Claude: 了解です。Monitor を停止しました。

つまり Monitor は何をしてくれるのか

• やってくれる: 裏で走る長いプロセスの出力1行1行を Claude が即時に読んで、エラーや状態変化が起きた瞬間に会話に割り込んでくれる
• やってくれる: ログ tail、CI/PR の状態 poll、フォルダ watch、長時間スクリプトの出力 track の4種が代表的な用途として公式に挙がっている
• やってくれない: 出力が来ないと何も反応しない。完全に静かなプロセスを見張らせても発火点が無い
• やってくれない: 結果をまとめて1回だけ受け取る使い方には向かない。それは Bash の run_in_background:true の領域
• 意味が薄い場面: 数秒で終わる短いコマンド。Monitor を立てるより素直に Bash で叩いて待った方が早い

使いどころ3シナリオ

シナリオ1: 料理ブログの dev server をつけっぱで書きながら直したいとき

料理ブログを Next.js で作っていて、画面を確認しながら少しずつコードを書き替える局面。npm run dev を立てっぱなしにして Claude に「TypeScript エラーが出たら教えて」と頼むと、ブラウザに「Type Error」の赤画面が出る前に Claude が拾って修正案を提示してくれます。エラー画面が出てから自分で対応する流れと比べて、ロスが目に見えて減ります。

シナリオ2: GitHub Actions の CI 結果を待ちながら別作業したいとき

PR を上げた直後、CI が走り終わるまで5〜10分くらいかかる。この間ぼーっと待つのは時間の無駄なので、Claude に「この PR の CI、終わったら結果教えて。落ちてたらログ見て原因も」と頼んでおけば、Monitor が裏で gh pr checks を一定間隔で叩いて状態変化を見張ってくれます。終わった瞬間に Claude から「Lint で2件落ちてます、原因は◯◯」と通知が入る。CI 待ちの間に別タスクに移れます。

シナリオ3: 家計簿アプリのテストを watch モードで回しながら書き直したいとき

家計簿アプリの計算ロジックを書き直していて、npm run test -- --watch でテストを回しっぱなしにしてある状態。ファイルを保存するたびにテストが走り直す。Monitor に「テストが失敗したら止めて知らせて」と頼んでおくと、赤くなった瞬間に Claude が割り込んで「calcMonthlyTotal の小数点処理がおかしい」と原因まで指摘してくれます。テスト結果のターミナルを別ウィンドウで見続けなくていい。

初心者が踏みやすい落とし穴

• Bedrock / Vertex AI / Foundry では使えない。クラウドベンダー経由の Claude では Monitor 自体が呼び出せません。同じ用途を叶えるなら、ローカルから Anthropic 直接で叩く構成に切り替えるか、Bash の run_in_background:true で代用する流れになります
• DISABLE_TELEMETRY が立っていると無効化される。プライバシー重視で OFF にしている読者は、Monitor を頼んでも「使えません」と返ってきます。一旦外して試すか、別手段を選ぶか
• Bash の許可設定がそのまま Monitor にも効く。Bash(npm run *) を許可していれば Monitor の中で npm run dev を走らせるのも通る一方、Bash を deny していると Monitor も止まる。「Monitor だけ別途許可」みたいな概念は無いので、Bash の許可をきっちり管理すれば Monitor 側も自然に制御できます
• 静かなプロセスを見張らせても意味が無い。出力1行ごとに反応するのが Monitor の動作なので、何も標準出力に吐かないプロセスを見張らせても発火点が無くて何も起きません。「ログを吐く設定」が前提
• 停止のかけ忘れに注意。セッションを終われば一緒に止まりますが、長いセッションで Monitor を何本も立てっぱなしにすると Claude 側の注意リソースを食い続けます。要らなくなったら「もう止めていいよ」と明示的に頼むのが安全
• plugin 経由の自動起動と取り違えない。plugin が自分の中で monitor を宣言しておくと、ユーザーが頼まなくても plugin が有効になった瞬間に勝手に走るルートが別に存在します（公式の plugins-reference 参照）。「自分は何も頼んでないのに見張りが立っている」状態に遭遇したら plugin 側を疑います
• Bash の run_in_background:true と混同しない。Bash の background は「裏で走らせて最後にまとめて結果を取りに行く」スタイル、Monitor は「裏で走らせて出力1行ごとに即反応する」スタイル。リアルタイム反応が要らない用途で Monitor を使うのは過剰、結果だけ欲しいなら素直に Bash background が軽い

書き方

（ユーザーが直接叩く書式はありません。Claudeへ「○○を見張って、××が起きたら教えて」と頼むとClaudeが内部でMonitorを発火させます）

やってみるとこうなる

入力

You: npm run dev を起動して、TypeScript のエラーが出たらすぐ教えて。エラーが出たそのファイルを見て修正案を出してくれていい。

出力例

Claude: 了解です。npm run dev を裏で起動して出力を見張ります。

（しばらく経過、他の作業を進める）

Claude: いま dev server から TypeScript エラーが出ました。
  src/data/fishes.ts:12 - Property 'price' does not exist on type 'Fish'.
  Fish 型の定義に price フィールドが無いので、型定義を追加するか、price を使っている画面側の参照を直すかの2択になります。

関連項目

• Bash（バッシュ）
• TaskCreate / TaskList / TaskStop（タスククリエイト・タスクリスト・タスクストップ）
• CronCreate / CronList / CronDelete（クロンクリエイト・クロンリスト・クロンデリート）
• SessionEnd（セッションエンド）
• /plugins（準備中）

公式ドキュメント

https://code.claude.com/docs/en/tools-reference#monitor-tool