Claude Code Monitor ツール

問題: 今月まで、バックグラウンドで実行されているものは Claude Code に対して不透明だった。run_in_background で開始されたコマンドは、終了時に1回だけ通知を送るだけだった。途中は何もなかった。回避策は /loop かスケジュールタスクで、数分ごとに新しいプロンプトを発行し、何か動きがあったかどうかを確認するだけのために完全な API コールを支払っていた。

クイックウィン: Claude に開発サーバーを指定して、エラーを監視させる。一文で済む:

Start my dev server and monitor it for errors

Claude はサーバーを起動し、その出力をバックグラウンドウォッチャーにラップし、何かが実際に壊れるまで静かにしている。何も起きていない間はトークンを消費しない。

何が変わったか

Anthropic は 2026年4月9日に Monitor ツールをリリースした。Claude Code PM の Noah Zweben はこう発表した。「Claude はログのエラーを追跡したり、スクリプト経由で PR をポーリングしたりできるようになった。大きなトークン節約効果があり、エージェントループでのポーリングから脱却する素晴らしい方法だ。」

根本的な変化は、タイマートリガーからイベントトリガーへの移行だ。古いモデルはタイマーで Claude が状態を確認していた。新しいモデルは Claude が出力の側に座り、何かが現れたときに反応する。数秒ごとにデータベースをポーリングするのをやめて、その変更ストリームを購読し始めるときに行うのと同じジャンプだと思ってほしい。タイマーモデルは何もないのにコンピューティングを消費する。ストリームモデルは変更が届いた瞬間に反応する。

仕組みはシンプルだ。Claude はシェルコマンドを実行し、その stdout をイベントのフローとして扱う。各行がメインセッションを起こす。静かなコマンドは何もコストがかからない。フィルターが行に一致した瞬間、その行が会話に落ちてきて、Claude が取り組み始める。基底のプロセスは並行して実行され続ける。

仕組み

すべてのモニターは4つのパラメータを取る:

command にロジックが入る。stdout の1行が1つの通知に相当する。200ミリ秒のウィンドウ内に複数の行が出てきた場合、それらは1つのアラートにグループ化されるため、1つの実際のイベントからの複数行の出力が1つのものとして読める。Stderr はファイルにリダイレクトされ、後で読める。Claude を起こすことはない。

モニターがセッションと同じ期間存続するべき場合は persistent: true を使う。開発サーバーのウォッチャー、ログテーラー、PR モニター。単一デプロイや1回のテスト実行など、有界のものには timeout_ms を渡して、ウィンドウが閉じるときにモニターが終了するようにする。

2つのモニターの形

ストリームフィルターは継続的な出力を監視し、一致する行を表示する:

# Watch application logs for errors
tail -f /var/log/app.log | grep --line-buffered "ERROR"
 
# Watch file system changes
inotifywait -m --format '%e %f' /watched/dir
 
# Node script that emits events from a WebSocket
node watch-for-events.js

ポーリング・条件フィルターは一定間隔でソースをチェックし、条件が変化したときに出力する:

# Poll GitHub PR for new comments every 30 seconds
last=$(date -u +%Y-%m-%dT%H:%M:%SZ)
while true; do
  now=$(date -u +%Y-%m-%dT%H:%M:%SZ)
  gh api "repos/owner/repo/issues/123/comments?since=$last" \
    --jq '.[] | "\(.user.login): \(.body)"'
  last=$now; sleep 30
done

どちらの形も同じ契約に従う。Stdout はイベントのストリームだ。沈黙は報告するものがないことを意味する。Claude はモニターがバックグラウンドで動き続ける間、次に頼まれたことに取り組み続ける。

トークンの計算

/loop が10分間のテストスイートの実行中に2分ごとにチェックする場合を想像してほしい。5回の完全な API コールになる。コンテキストのリロード、プロンプト処理、レスポンス生成、毎回だ。5回のラウンドトリップを支払い、そのうち4回は何も有用なものを返さない。

モニターはその方程式を逆転させる。Claude はテストランナーのフィルタリングされた出力を追跡する。テスト #23 が4分目に失敗すると、失敗の行がすぐにセッションに届く。Claude はテスト 24 から 47 がまだ実行中の間に修正に取り掛かれる。無駄なし。遅延なし。ワークフローが長いほど節約が大きくなる。何時間も続く CI 実行、デプロイジョブ、一晩のビルドを含め、長時間実行されるものすべてがここで利益を得る。

実用的なユースケース

開発サーバーのエラーキャッチ。 Next.js や Vite の開発サーバーを監視して、ビルドエラーやクラッシュループが発生した瞬間に通知を受け取る。古いターミナル出力をスクロールして障害ポイントを探すことがなくなる。

テストスイートのトリアージ。 失敗したテストは失敗した瞬間に浮上する。Claude は残りのスイートがまだ実行中の間に修正を開ける。

デプロイパイプラインの監視。 CI/CD ストリームにフィルターを付けて、失敗時、警告時、または特定のデプロイステージが完了したときに Claude を起こす。

PR レビューポーリング。 GitHub プルリクエストに座って、新しいコメント、レビューリクエスト、ステータスチェックが届いたときに反応する。各新しいコメントが Claude がすぐに取り組めるものになる。

ログ監視。 本番またはステージングのログにフィルターを向ける。行がパターンに一致するたびに、イベントとしてセッションに届き、Claude がすぐに応答できる。

良いモニターのための3つのルール

1. grep を --line-buffered なしでパイプしない。 このフラグがないと、パイプのバッファリングがイベントを数分間保持することがある。これが最も頻繁なつまずきだ。

2. ポーリングループ内で一時的な失敗を飲み込む。 各 API コールに || true を追加して、1回のネットワーク往復の失敗でモニター全体が落ちないようにする。

3. stdout をタイトに保つ。 出力するすべての行が会話の中のメッセージになる。イベントを出力しすぎるウォッチャーは Claude Code によって自動停止される。パイプに入れる前に常に生のログをフィルタリングする。フィルタリングなしでフルストリームをダンプしない。

# Good: selective filter
tail -f app.log | grep --line-buffered "ERROR\|WARN\|FATAL"
 
# Bad: firehose that will auto-stop
tail -f app.log

ポーリング間隔も重要だ。レート制限が適用されるため、リモートのものには30秒以上。ローカルチェックには0.5〜1秒で十分だ。

Monitor vs. Hooks vs. スケジュールタスク

Claude Code には現在3層の自動化があり、それぞれが異なる種類のトリガーを監視する。

Hooks は Claude 自身のアクション (ファイル編集やコミットなど) で起動する。Scheduled tasks はクロックで起動する。Monitor は外の世界で起動する。最も強力なセットアップはこれらを3つ重ね合わせる。ガードレールは hooks に、定期メンテナンスはスケジュールタスクに、その他すべての実時間観測は monitor に。

Monitor vs. run_in_background

これらを混同する人がいる。両方ともバックグラウンドで実行する。違いはフィードバックモデルだ。

run_in_background は火忘れ型だ。コマンドが終了したときに1回だけ通知を受け取る。途中は何もない。「このビルドを実行して、完了したら教えて」に適している。

モニターは代わりにライブストリームだ。一致するすべてのイベントに対して通知が発火する。「このビルドを実行して、何かおかしくなった瞬間に教えて」に適している。Claude はプロセスが終了した後だけでなく、実行中もリアクティブに動き続ける。

次のステップ

• hooks が Claude 自身のアクションを検証することでモニターを補完する方法を学ぶ
• モニターがフィードバックシグナルを提供する自律エージェントループを探索する
• 長期モニタリングセッションを効率的に保つためのコンテキスト管理について読む
• イベント駆動監視と組み合わせる時間ベースの自動化のためのスケジュールタスクを参照する
• コードを書くことと問題を検出することのサイクルを縮めるフィードバックループを試す

Monitor ツールは「Claude が実行する」と「Claude が監視する」の間の欠けていたスロットに収まる。バックグラウンド作業はかつて最後にだけ開く封印されたボックスだった。今日、Claude はプロセスの隣に座り、注意が必要なものに反応しながら、不要なものには手を触れない。真に異なる形のペアプログラミングだ。