Claude Code 新機能「Monitor ツール」とは？バックグラウンド監視でトークンを大幅節約する方法

こんにちは、もるふぉです。

ソフトウェアエンジニアとして10年以上コードを書いてきましたが、今はClaude Codeで「設計して指示する」スタイルに完全移行しています。

今日はClaude Codeに追加されたばかりの新機能「Monitor ツール」について解説します。

バックグラウンドスクリプトの出力をリアルタイムで監視し、必要なときだけエージェントを起動する——エージェントループのポーリングを排除してトークンを大幅に節約できる機能です。

2026年4月9日のアップデート（v2.1.98）で追加され、Claude Code PMのNoah ZwebenさんがXで発表。

「これこれ、こういうのが欲しかった」と思ったので、仕組みから実用的な使い方まで速報的にまとめます。

Claude Code Monitor ツールとは何か

Noah Zwebenさんの発表——何が変わるのか

Noah Zwebenさんのポストを要約すると、こういう話です。

• Claudeがバックグラウンドスクリプトを作成し、必要なときにエージェントを起動できるようになった
• トークンの大幅節約が可能
• エージェントループでのポーリングから脱却
• ログのエラー追跡、PRのステータス監視などが可能に

一言で言えば、Claude Codeが「ずっと見張っている」のではなく、「何かあったら教えてもらう」スタイルに変わったということです。

今までClaudeがバックグラウンドのタスクを監視するには、定期的に「終わった？まだ？」とポーリングし続ける必要がありました。

そのたびにAPIコールが走って、トークンがどんどん消費されていく。

Monitor ツールはこの無駄を根本から解決する機能です。

「Usage Monitor」とは全くの別物

ここで一つ、重要な注意点があります。

「Claude Code Monitor」で検索すると、ccmやccusageといったトークン消費量を監視するサードパーティ製ツールの情報がたくさん出てきます。

これらはいわゆる「Usage Monitor」で、APIの使用量やコストを可視化するツールです。

今回の「Monitor ツール」は、それとは全く別の機能です。

名前が似ているので混同しやすいですが、解決する課題が完全に異なります。

この記事で解説するのは前者、Claude Code本体に組み込まれたMonitor ツールのほうです。

Monitor ツールが解決するエージェントループの課題

ポーリング地獄——なぜトークンが無駄になるのか

Claude Codeをヘビーに使っているエンジニアなら、こんな経験があるんじゃないでしょうか。

「テスト実行して、終わったら結果を確認してね」とClaudeに頼む。

するとClaudeは律儀に「テスト実行中です...確認します...まだ実行中です...確認します...」とポーリングを繰り返すんですよね。

テストスイートが5分かかるとして、その間に何度もBashコマンドを実行してステータスを確認する。

そのたびにエージェントループが回り、APIコールが発生し、トークンが消費される。

テスト結果を見るためだけに、テスト実行そのものより多くのトークンを使っている——そんな状況が起きていたわけです。

イベント駆動への転換でどれだけ変わるか

Monitor ツールの導入で、このパラダイムが根本から変わります。

Before（ポーリング型）:

1. Claudeがスクリプトを実行
2. 「まだ終わってないかな？」と定期的にチェック（API呼び出し発生）
3. 「まだだった」を何度も繰り返す（トークン消費）
4. ようやく完了を検知して次のアクションへ

After（イベント駆動型・Monitor ツール）:

1. Claudeがスクリプトをバックグラウンドで実行
2. スクリプトのstdoutが1行出力されるたびに、自動でチャット通知
3. エラーや完了を検知した時点で即座にエージェントが反応

エージェント側のポーリングが不要になるので、トークン消費は劇的に減ります。

特に長時間実行されるタスク——大規模なテストスイート、docker build、npm install、CI待ちなど——では、その差が顕著に出ます。

Monitor ツールの仕組みと使い方

run_in_background との連携

Monitor ツールの技術的な核心は、Bashツールの run_in_background パラメータとの連動です。

Claude CodeのBashツールには run_in_background というパラメータがあり、true に設定するとコマンドをバックグラウンドで実行できます。

Ctrl+Bで使えるバックグラウンド実行機能と関連するものですが、Monitor ツールはさらにイベントのストリーミング通知を加えた仕組みです。

stdout をエージェントに届けるリアルタイム通知

公式Changelogでは「streaming events from background scripts」と説明されています。

つまり、バックグラウンドで実行したスクリプトから発生するイベント（stdoutへの出力）を、リアルタイムでエージェントにストリーミングする仕組みです。

1. バックグラウンドで実行したスクリプトのstdout（標準出力）を監視する
2. stdoutに出力が発生するたびに、その内容がエージェントへの通知としてストリーミングされる
3. エージェントはその通知を受け取り、内容に応じて判断・行動する

ここが面白いところなんですが、「全部終わってからまとめて結果を取得する」のではなく、出力が発生した瞬間にエージェントが認識できるんですよね。

エラーが発生した時点で即座にエージェントが修正に動ける——これまでのバックグラウンド実行とは根本的に違うポイントです。

基本的な使い方の流れ

Monitor ツールは特別な設定が必要ありません。

Claude Codeに対して、たとえばこんな指示を出すだけです。

サーバーログを監視して、ERRORレベルのログが出たら原因を調査して修正してください

すると、Claudeは以下の流れで動作します。

1. tail -f 等のコマンドをバックグラウンドで実行（run_in_background: true）
2. Monitor ツールがstdoutを監視
3. ログの各行がリアルタイムでエージェントに通知される
4. ERRORを含む行を検知した時点で、Claudeが調査・修正アクションを開始

従来のような「ログを定期的にチェックして」というポーリングは一切発生しません。

必要なタイミングで、必要な情報だけがエージェントに届く。

この「イベント駆動」の考え方は、バックエンドエンジニアにはおなじみの概念ですよね。

WebhookやメッセージキューのあのパラダイムがClaude Codeにも来た——そういう感覚です。

実務で使える Monitor ツールのユースケース 3 選

ログのエラー検知で自動修正エージェントを起動

開発中に一番ストレスがたまる瞬間って、画面を操作していたらサーバーが500エラーを返して、ターミナルに戻ってログを遡って原因を探す——あの流れじゃないですか。

Monitor ツールを使えば、Railsのサーバーログをリアルタイムで監視し、例外やエラーが発生した瞬間にClaudeが自動で原因を特定して修正に動く、という流れが可能になります。

# イメージ: Claudeがバックグラウンドで実行するコマンド
tail -f log/development.log | grep --line-buffered "ERROR\|FATAL\|RuntimeError"

エラーが出なければClaudeは何もしない（トークン消費ゼロ）。

エラーが出た瞬間だけエージェントが起動する。

これがポーリング型との決定的な違いです。

PR の CI ステータスをポーリングなしで監視

PRを出した後のあの「待ち時間」、地味にイライラしませんか。

GitHubのタブを何度もリロードして「まだpendingか...」を繰り返す。
ようやくCIが落ちたのに気づくのは30分後で、修正してまたpush、そしてまた待ち——この繰り返しがコンテキストスイッチのコストを爆増させます。

Monitor ツールなら、CIのステータスを監視するスクリプトをバックグラウンドで走らせて、失敗を検知した時点でClaudeが自動修正に入れます。

# イメージ: CIステータスを監視するスクリプト
while true; do
  status=$(gh pr checks --json bucket -q '.[].bucket' | sort -u)
  echo "CI Status: $status"
  if [[ "$status" == *"fail"* ]] || [[ "$status" == *"pass"* ]]; then
    echo "CI completed with status: $status"
    break
  fi
  sleep 30
done

このスクリプトのstdoutがMonitor経由でClaudeに届くので、Claudeが自らポーリングする必要がありません。

スクリプト側がポーリングしている点は同じですが、エージェントのAPIコールが不要になるのでトークン節約効果は大きいです。

テストスイートの失敗を即座にキャッチ

テストを全件流すときの「あの空白の時間」、何をしていいかわからなくなりませんか。

別の作業を始めると集中力が分散するし、かといってぼーっと出力を眺めるのも非生産的。
しかも全部終わってから「3件目で落ちてた」と気づくと、もっと早く知りたかったのにと思うわけです。

Monitor ツールなら、テスト実行中にリアルタイムで失敗を検知できます。

# イメージ: テスト実行の出力をそのまま監視
bundle exec rspec --format progress 2>&1

100件のテストのうち3件目で失敗しているのに、残り97件が終わるまで待つ必要がなくなる。

テストが1つ失敗した時点でClaudeが内容を認識し、修正を並行して検討し始める——そういう使い方ができます。

関連機能との使い分けガイド

Monitor vs Channels vs run_in_background vs /loop

Claude Codeには似たようなバックグラウンド系の機能がいくつかあるので、整理しておきます。

ちなみにChannelsというのは、ローカルで動くMCPサーバーがTelegramやDiscord等の外部サービスからメッセージを受け取り、稼働中のClaude Codeセッションにイベントをpushする機能です。

迷ったときは、この2つの軸で判断するとすっきりします。

• イベントの発生源はどこか？ → ローカルプロセスなら Monitor、外部サービスなら Channels
• リアルタイム通知が必要か？ → 必要なら Monitor か Channels、不要なら run_in_background

Monitor ツールはあくまで「自分のマシン上のプロセスを見張る」用途に特化している、と覚えておけば迷いません。

まとめ——ポーリングからイベント駆動へ

Claude Code の Monitor ツールは、エージェントの動作モデルを「ポーリング型」から「イベント駆動型」に転換する機能です。

仕組みはシンプルです。バックグラウンドスクリプトのstdoutをリアルタイムでエージェントに通知する、ただそれだけ。

でも、それだけでトークン消費の構造が根本から変わります。

このツールのポイントをまとめると:

• バックグラウンドスクリプトのイベントをリアルタイムでエージェントにストリーミング
• エージェントループのポーリングを排除し、トークン消費を大幅削減
• ログ監視、CI待ち、テスト実行など、長時間タスクの監視に最適
• 「Usage Monitor」（ccm等のトークン消費量監視ツール）とは全くの別物
• Channels、run_in_background、/loopと組み合わせることで、より柔軟なワークフローが構築可能

バックエンドエンジニアにとっては「Webhookやメッセージキューと同じ発想がエージェントにも来たか」という感覚で、自然に理解できる概念だと思います。

個人的に感じるのは、Claude Codeのエージェント機能がだんだん「開発者が本当に欲しかったもの」に近づいてきているなということです。

ポーリングの無駄にモヤモヤしていた方は、まず手元の tail -f から試してみてください。

設計と指示に集中して、面倒な監視はエージェントに任せる——そのスタイルがまた一歩進んだ感じがしています。