Claude Code の「Monitor tool」 調査

バックグラウンドで動いている処理のイベント標準出力を、チャット通知として表示してくれる「Monitor tool」というツールが追加されたとのことなので調べてみた。

（注）本記事の内容は正確性を保証するものではない。

（2026年4月10日 追記）YouTube動画を追加しました。　https://youtu.be/JKXDdlnbK-c

「Monitor tool」の概要

以下、Claude Sonnet 4.6との質疑応答

情報が集まりました。整理してお伝えします。

Claude Code の「Monitor tool」（Background monitor）について

どのバージョンで追加されたか

v2.1.98（2026年4月9日リリース）で導入されています。

何ができるツールか

Tool Description: Background monitor (streaming events)（668トークン） — バックグラウンドで動いているスクリプトのstdoutイベントをチャット通知としてストリーミングする「バックグラウンドモニター」ツールを説明するもの。スクリプトの品質、出力量、選択的フィルタリングに関するガイドラインを含む。

つまり、長時間動作するスクリプトやプロセスの標準出力を、Claude Codeのチャット画面にリアルタイム通知として流し込む仕組みです。

v2.1.98で追加された主な文脈

v2.1.98のリリースノートによると、Monitor toolは「Enhanced Development Workflows」の一環として追加されています。説明としては「バックグラウンドスクリプトのイベントをストリーミングし、デバッグを改善するための新しいMonitorツール」とされています。

同時リリースされた関連機能

v2.1.97〜v2.1.98あたりは機能の大型追加が続いており、Monitor toolと関係の深い機能が一緒に追加されています：

• Focus view（Ctrl+O）：NO_FLICKERモードでのフォーカスビュー切り替え（v2.1.97）
• refreshInterval：ステータスラインを定期的に再実行する設定
• ● N running インジケーター：/agentsでサブエージェントの稼働数を表示

また同じv2.1.98では、LinuxでのPID名前空間分離によるサブプロセスサンドボックス強化や、CLAUDE_CODE_SCRIPT_CAPS環境変数（セッションごとのスクリプト呼び出し数制限）も追加されました。

まとめ

Monitor toolの位置づけは、長時間タスクの「可視化レイヤー」です。たとえば：

• テストスイートやビルドスクリプトをバックグラウンドで実行しつつ、その出力をClaudeのチャット画面でリアルタイムに受け取る
• Claudeが自律的にスクリプトを走らせながら、ユーザーはその進捗を逐一確認できる

以前の--channels（MCP経由でセッションにメッセージを押し込む仕組み）と方向性は似ていますが、Monitor toolはよりスクリプトのstdout監視に特化した設計になっています。

公式のより詳細な説明は code.claude.com/docs/en/changelog のv2.1.98セクション、もしくは Piebald-AIのリポジトリ で実際のツール説明文（プロンプト）を確認できます。

---

Claude Code「Monitor tool」の具体的な使い方

ツールの公式ドキュメントページを直接確認します。公式のリリースノートから必要な情報が揃いました。整理してお伝えします。

一言でいうと

Monitor toolは「バックグラウンドで動くスクリプトのstdoutイベントをストリーミングするツール」として、v2.1.98（2026年4月9日）に追加されました。

つまり「長時間かかるスクリプトを走らせながら、その出力をClaudeのチャット画面にリアルタイム通知として届ける」仕組みです。

どういう場面で使うか

従来の問題は、たとえば「テストを全部走らせて。終わったら教えて」という指示を出しても、Claudeはスクリプトを起動した後、終わるまで応答を返せないか、ターミナルを見続けるしかなかった点にありました。

Monitor toolはこれを解決します。

実際の指示文の例

① テストの進捗をリアルタイムで見たい

テストスイートをバックグラウンドで実行して、
MonitorツールでストリーミングしながらProgressを教えて。
エラーが出たらすぐ通知して。

② ビルドを監視しながら別の作業をしたい

npm run buildをバックグラウンドで走らせて、Monitorで出力を
ストリーミングしてください。完了またはエラーが出たらここに通知してください。
その間にREADMEを更新する作業を進めましょう。

③ 長時間のデータ処理を監視したい

python process_data.py をバックグラウンドで実行してMonitorツールで
進捗ログを流してください。進捗が止まったり異常があればすぐ教えてください。
出力が多すぎる場合は「エラー」「完了」「%」が含まれる行だけフィルタしてください。

ツールの仕様上のポイント

ツール説明（668トークン）によれば、Monitor toolは「バックグラウンドスクリプトのstdoutイベントをチャット通知としてストリーミングする」もので、スクリプトの品質・出力量・選択的フィルタリングに関するガイドラインを内包しています。

これを踏まえると、指示文を書く際の実用的なコツは：

ポイント	例
フィルタ条件を明示する	「ERROR / WARNINGを含む行だけ通知して」
出力量を制限する	「1秒ごとに最新行だけ表示して」
完了条件を指定する	「”Done”または”exit 0″が出たら教えて」

関連して同時追加された機能

同じv2.1.98では「バックグラウンドのBashタスクがインタラクティブプロンプトで止まっていると約45秒後に通知が出る」機能も追加されています。

つまり Monitor tool と合わせて使うと：

• スクリプトが進んでいる → stdout が流れてくる
• スクリプトが入力待ちで止まっている → 45秒後に自動通知

という二重のフォールバックが機能します。

まとめ図

あなたの指示
  ↓
Claude がスクリプトを起動 (バックグラウンド)
  ↓
Monitor tool がstdoutをストリーミング監視
  ↓
チャット画面にリアルタイム通知が届く
  ↓
あなたは別の作業をしながら結果を把握できる

公式のより深い仕様は code.claude.com/docs/en/changelog のv2.1.98セクションで確認できます。
今後詳細ドキュメントが整備される可能性もあります。

---

Monitor toolの「通知手段」について — 正確な整理

検索結果を見ると、「Monitor tool自体の通知手段」ではなく「Claude Codeの通知全般（hooksシステム）」の情報が多く出てきています。Monitor tool固有の通知仕様を確認します。重要な手がかりが得られました。Monitor tool固有の通知仕様と、v2.1.98の関連変更を確認します。これで全体像が見えてきました。Monitor tool固有の通知と、Claude Code全体の通知システムの整理ができます。正直に整理してお伝えします。

率直に言うと、Monitor tool固有の通知チャンネルが何種類あるかという情報は、公式ドキュメントにも詳細が明記されていません。ただし、検索で集まった情報から次のように整理できます。

Monitor tool自体が届ける通知：チャット画面へのストリーミング（1種類）

v2.1.98のリリースノートには「Added Monitor tool for streaming events from background scripts」とのみ記載されています。

ツール説明（668トークン）によれば、Monitor toolは「バックグラウンドスクリプトのstdoutイベントをチャット通知としてストリーミングする」ものです。

つまりMonitor tool自身が直接届ける通知手段は、Claude Codeのチャット画面内への通知（インライン通知）のみです。「チャット画面に流れてくる」というのが基本の動作です。

---

Claude Code全体の通知システム（Monitor toolと組み合わせられるもの）

Monitor toolの出力をトリガーにして、以下の通知手段をhooksやChannels経由で追加できます：

① macOSデスクトップ通知 公式ドキュメントのhooksガイドでは、Notificationイベントでosascriptを使ってmacOSのシステム通知を出す設定が標準的なパターンとして紹介されています。

② Linuxデスクトップ通知 notify-sendコマンドを使ったLinux向けの設定も公式ドキュメントに記載されています。

③ Windowsダイアログ通知 Windows（PowerShell）ではSystem.Windows.Forms.MessageBoxを使った通知が公式ドキュメントに例示されています。

④ スマートフォン・外部サービスへのプッシュ通知 ntfy.shとTailscaleを組み合わせることでスマートフォンへのプッシュ通知を実現する方法が紹介されています（iOSのntfyアプリ・Androidにも対応）。

⑤ チャットサービス連携（Telegram・Discord・Slack等） Channelsという仕組みを使うと、Claude CodeセッションとTelegram・Discord等のプラットフォームを双方向に接続でき、外部からClaudeに通知を送ることも、ClaudeからSlackやDiscordに送ることも可能です。

⑥ バックグラウンドBashタスクの自動通知（45秒ルール） v2.1.98では「バックグラウンドのBashタスクがインタラクティブプロンプトで止まって見える場合、約45秒後に通知が自動で出る」機能も同時に追加されています。これはMonitor toolと独立した仕組みですが、連動して使える補完機能です。

まとめ

通知手段	Monitor tool直接	追加設定が必要
チャット画面インライン通知	✅	—
macOSデスクトップ通知	—	hooks（osascript）
Linuxデスクトップ通知	—	hooks（notify-send）
Windows通知	—	hooks（PowerShell）
スマートフォンへのプッシュ	—	hooks + ntfy等
Telegram / Discord / Slack	—	Channels（MCP）
45秒自動通知（スタック検出）	—	標準搭載（別機能）

Monitor tool自体は「チャット画面に流す」という1つの出力手段のみを持ち、それ以外の通知はClaude CodeのHooksやChannelsシステムを別途組み合わせる設計になっています。

---

Monitor toolとトークン・コンテキストの関係

良い質問です。まず既知の情報で整理してから、不明な部分を調べます。必要な情報が揃いました。整理してお答えします。

結論から

はい、Monitor toolはコンテキストを消費します。 ただし仕組みを理解した上で使えば、コントロールできます。

Monitor toolの出力がコンテキストに入る仕組み

Claude Codeのアーキテクチャ上、ツールが返す結果（tool result）は次のモデル呼び出しの前に会話履歴に追記されます。各ツールには maxResultSizeChars という上限があり、それを超えると内容は一時ファイルに保存され、モデルにはファイルパスとプレビューだけが渡されます。これによってコンテキストウィンドウが大きなアウトプットで溢れるのを防いでいます。

つまりMonitor toolがストリーミングするstdout出力も、tool resultとして会話履歴に入るため、コンテキストを消費します。スクリプトの出力が多いほど消費量は増えます。

コンテキスト・使用量を減らす方法

① 出力をフィルタする（最も直接的）

スクリプトの全出力をそのまま流さず、必要な行だけに絞るよう指示します：

バックグラウンドでビルドを実行して、Monitorで監視してください。
ただし "ERROR" または "WARN" または "完了" を含む行だけ通知してください。

② コンテキストを定期的に整理する

公式ドキュメントは /compact Focus on code samples and API usage のように、コンパクション時に何を保持するか指示することを推奨しています。また /clear を使って無関係なタスクに切り替える際にコンテキストをリセットすることも勧めています。

③ MCPサーバーの整理

/context コマンドを実行すると、カテゴリ別のトークン消費内訳が見えます。MCP toolsが多い場合は /mcp で使っていないサーバーを無効化すると効果的です。

④ サブエージェントに委ねる（コンテキスト分離）

サブエージェントは独立した別のコンテキストウィンドウで動作するため、大量のファイル読み込みをサブエージェントに任せると、返ってくるのはサマリーと小さなメタデータだけになり、メインのコンテキストをクリーンに保てます。

Monitor toolの出力が大量になる場合も、サブエージェントに監視を任せて「エラーがあれば報告して」という形にするとメインのコンテキスト消費を抑えられます。

⑤ MCP toolの遅延読み込みを活用する

MCPツール定義はデフォルトで遅延ロードされるため、ツール名だけがコンテキストに入り、Claudeが実際にそのツールを使うまで詳細定義は読み込まれません。

Pro/Max プランにおける「使用量」について

重要な前提として：

/cost コマンドはAPIユーザー向けのものです。Claude MaxやProサブスクライバーはサブスクリプションに使用量が含まれているため、/cost データは課金目的には関係ありません。サブスクライバーは /stats で使用パターンを確認できます。

つまり Pro/Maxプランでは「トークン量 = 金額」ではなく「トークン量 = レート制限の消費」です。Monitor toolを使うとコンテキストは確実に増えますが、課金面でのインパクトはプランによって異なります。

まとめ

問い	答え
Monitor toolでトークン増える？	はい、tool resultとして会話履歴に積まれる
コンテキストも消費する？	はい、同じ理由で消費される
減らせる？	はい、出力フィルタ・/compact・サブエージェント委譲が有効
他の出力を減らす方法は？	/context で内訳確認 → 不要なMCPを /mcp で無効化

---

MacのセッションにiPhoneから参加できるか

良い質問です。これはRemote Control機能との組み合わせの話になります。調べます。公式ドキュメントも確認できました。整理してお伝えします。

はい、できます。 これはRemote Control機能で実現します。

仕組み

Remote ControlはMacでローカルに動いているClaude Codeセッションに、iOSアプリ・Androidアプリ・ブラウザから接続する機能です。セッションはMac上で動き続け、iPhoneは「リモートの窓」として機能します。ファイルシステム・MCPサーバー・プロジェクト設定はすべてMac上に留まります。

会話はすべての接続デバイス間でリアルタイム同期されます。ターミナル・ブラウザ・スマートフォンのどこからでも交互にメッセージを送れます。

セットアップ方法

必要なのは「Pro・Max・Team・Enterprise」いずれかのプラン（APIキーは非対応）と、v2.1.51以降のClaude Code。セッション中に /remote-control または /rc と打つとセッションURLとQRコードが表示されます。iPhoneのClaudeアプリでQRコードをスキャンすれば接続完了です。

Monitor toolの出力もiPhoneで見えるか

「会話はすべての接続デバイスで同期される」とあります。Monitor toolの出力もtool resultとして会話履歴に積まれているため、iPhoneからも確認できます。追加の指示もiPhoneから送れます。

注意点

各Claude Codeインスタンスがサポートするリモート接続は同時に1つだけです。
2人が同じセッションに同時参加はできません。また、ネットワーク断が約10分続くとセッションがタイムアウトします。

現時点では --dangerously-skip-permissions フラグはRemote Controlと組み合わせて使えません。
そのため、Claudeがツールを実行するたびに承認が必要です。

まとめ

項目	状況
iPhoneから参加できるか	✅ できる（Claudeアプリ使用）
Monitor toolの出力を確認できるか	✅ できる（会話が同期される）
iPhoneから追加指示を送れるか	✅ できる
同時に2人が参加できるか	❌ 1接続のみ
必要なプラン	Pro・Max・Team・Enterprise
必要なバージョン	Claude Code v2.1.51以降

---

① 全セッションにRemote Controlをデフォルト適用できるか

必要な情報が揃いました。2つの質問それぞれに正確にお答えします。

はい、できます。 公式の設定方法があります。

Claude Codeの中で /config を実行し、「Enable Remote Control for all sessions」を true にすると、以降すべてのインタラクティブセッションが自動的にRemote Controlを有効にした状態で起動します。false に戻せば無効化できます。この設定をオンにすると、各Claude Codeプロセスが起動時に自動でリモートセッションを登録します。

ただし、既知のバグが報告されています。

「Enable Remote Control for all sessions」の設定が ~/.claude.json に "remoteControlAtStartup": true として書き込まれているにもかかわらず、セッションをまたぐと false にリセットされてしまうというバグが2026年3月に報告されています。UIで読み込まれる値と書き込まれた値に乖離があるようです。

バグが修正済みかは現時点で未確認なので、設定後に実際に動作するか一度確認することをお勧めします。

② iPhoneで新しいセッションを開始し、Macで同じセッションに参加できるか

これはできません。 Remote Controlは方向が決まっています。

Remote Controlには重要な制限があります。すでに誰かが開始した既存のセッションに接続して続けることはできますが、iPhoneから新しいセッションを開始することはできません。Macで何も動いていない状態では、iPhoneから起動する手段がありません。

開発者コミュニティでも、最も多いリクエストは「Remote Controlをもっと良くして」ではなく「スマートフォンからセッションを開始できるようにして」だと指摘されています。

つまり現状の設計は：

操作	可否
Macで開始 → iPhoneで参加・継続	✅ できる
iPhoneで新しいセッション開始 → Macで同じセッションに参加	❌ できない

iPhoneから新しいセッションを開始してMacでも使いたい場合は、SSH + tmux という別の方法（Tailscale + Termius等）が代替手段になりますが、これはかなり技術的なセットアップが必要になります。

各関連機能とMonitor toolの関係

整理してお答えします。
これらは「Monitor toolで長時間タスクを走らせているときに、何が起きているかを把握しやすくする」という共通の文脈でまとめられます。

Focus view（Ctrl+O）— 最も直接的な関係

Monitor toolがstdoutをストリーミングしていると、チャット画面に大量の出力が流れてきます。通常表示だと、ツールの実行ログ・過去の会話・システムメッセージなどが混在して、「今何が起きているか」が見づらくなります。

Focus viewはNO_FLICKERモードで Ctrl+O で切り替えられ、プロンプト・ツールのサマリー（編集のdiffstat付き）・最終レスポンスだけを表示する絞り込みビューです。

Monitor toolの出力を確認しながら作業するとき、Focus viewに切り替えると「今のスクリプト出力と、Claudeの直近の判断」だけにフォーカスできます。ノイズを減らして監視に集中できる、という関係です。

refreshInterval — 間接的な関係

ステータスラインに refreshInterval 設定が追加され、N秒ごとにステータスライン用のコマンドを自動再実行できるようになりました。

Monitor toolはチャット画面への通知という形で出力を届けますが、ステータスライン（画面下部のバー）は別の情報チャンネルです。refreshIntervalを使えば、たとえば「監視中のスクリプトの現在の行数」や「経過時間」をステータスラインにリアルタイム表示するスクリプトを書くことができます。Monitor toolの出力とは独立したサブ表示として活用できます。

● N running インジケーター — 補完的な関係

/agents コマンドに、アクティブなサブエージェントのインスタンス数を示す「● N running」インジケーターが追加されました。

Monitor toolをサブエージェントに委ねて監視させるケース（前回話したコンテキスト節約の方法）では、そのサブエージェントが今も動いているかどうかが /agents 画面でひと目でわかります。「監視エージェントがまだ生きているか」の確認手段として機能します。

まとめると

Monitor tool（バックグラウンド監視・stdout通知）
    │
    ├─ 出力が多くて見づらい
    │      └─→ Focus view で絞り込み表示
    │
    ├─ 進捗を別チャンネルで見たい
    │      └─→ refreshInterval でステータスラインに独自表示
    │
    └─ 監視エージェントが生きているか確認したい
           └─→ ● N running インジケーターで確認

3つとも「Monitor toolで長時間タスクを回している間の視認性と管理のしやすさ」を補う機能として、同時期にリリースされたという関係です。
Monitor tool単体で完結するのではなく、これらがセットで「バックグラウンド監視ワークフロー」を構成するように設計されています。

---

「Focus view で絞り込み表示」や「refreshInterval でステータスラインに独自表示」で、使用量（トークン量？）やコンテキスト消費量を減らせるか

正直に整理してお答えします。これは「表示」と「トークン消費」の関係についての重要な誤解を解くところから始める必要があります。

結論から

Focus viewやrefreshIntervalは、トークン消費・コンテキスト消費を減らしません。

なぜか：「表示」と「トークン」は別のレイヤー

Claude Codeのアーキテクチャ上、各ターンはAPIへのクエリ呼び出しによって駆動されます。ツールが返す結果はすべて、次のモデル呼び出しの前に会話履歴に追記されます。

つまりトークンが決まるのはAPIに送る内容であり、画面への表示方法とは無関係です。Focus viewで表示を絞っても、APIには同じ量のデータが送られています。

画面表示（Focus view等で制御できる）
    ↕  ここは連動していない
APIに送るコンテキスト（トークン消費）

では何がトークンを減らすのか

公式ドキュメントが挙げるトークン削減策は、タスク切り替え時の /clear、コンパクション時の保持内容の指定（/compact Focus on X）、不要なMCPサーバーの無効化（/mcp）、サブエージェントへの委譲、具体的なプロンプトを書くことです。

Monitor tool固有で言えば、前回お伝えした出力フィルタが直接効きます：

# これがトークン削減に効く
「ERROR と WARN を含む行だけ通知して、それ以外は無視して」

# これはトークン削減に効かない
Focus viewで表示を絞る
refreshIntervalでステータスラインを更新する

Focus viewとrefreshIntervalが実際に役立つこと

この2つは「トークン削減」ではなく「認知的な負荷の削減」に役立ちます。

機能	実際の効果	トークンへの影響
Focus view	画面が見やすくなる	なし
refreshInterval	ステータスバーで進捗把握	なし（バー表示はAPIを通らない）
出力フィルタ指示	tool resultが小さくなる	あり（直接減る）
/clear	コンテキストをリセット	あり（大幅に減る）
/compact	古い会話を要約	あり（減る）
MCPサーバー無効化	ツール定義が減る	あり（減る）

補足：ステータスラインはなぜトークンを消費しないか

refreshIntervalで動くステータスラインのスクリプトは、Claude CodeのUIレイヤーがローカルで実行するシェルコマンドです。その結果はAPIには送られず、画面下部のバーに表示されるだけです。
Monitor toolの出力とは完全に独立したチャンネルなので、コンテキストに影響しません。これはむしろ「コンテキストを使わずに情報を得る」方法として積極的に活用できます。

---

ステータスラインをコンテキストゼロで情報収集する方法

公式ドキュメントの全フィールドが確認できました。具体的にまとめます。

まず大前提として：

ステータスラインはローカルで動作し、APIトークンを消費しません。

これが核心です。以下のすべての情報を、Claudeに聞かずに把握できます。

ステータスラインで取得できるデータ一覧

Claude Codeがstdinに渡すJSONには以下のフィールドが含まれています。モデル名・作業ディレクトリ・プロジェクトディレクトリ・追加ディレクトリ・gitワークツリー名・セッションコスト（USD）・経過時間・API応答時間・変更行数・累計トークン数・コンテキストウィンドウサイズ・使用率・残量パーセント・直近APIコールのトークン内訳・レート制限の使用状況です。

活用パターン別の具体例

① コンテキスト残量の常時表示（最重要）

「あと何トークン使えるか」をClaude に聞かずに把握し、/compact や /clear のタイミングを自分で判断できます。

#!/bin/bash
input=$(cat)
PCT=$(echo "$input" | jq -r '.context_window.used_percentage // 0' | cut -d. -f1)
REMAIN=$(echo "$input" | jq -r '.context_window.remaining_percentage // 0' | cut -d. -f1)

# 色分け：70%未満=緑、70-85%=黄、85%以上=赤
if [ "$PCT" -lt 70 ]; then COLOR='\033[32m'
elif [ "$PCT" -lt 85 ]; then COLOR='\033[33m'
else COLOR='\033[31m'; fi

echo -e "${COLOR}Context: ${PCT}% used / ${REMAIN}% remaining\033[0m"

Claude Codeのセッション中に「コンテキストどのくらい残ってる？」と聞く必要がなくなります。

---

② Monitor tool監視中の進捗をステータスラインに外出し

Monitor toolの出力がチャットに流れる代わりに、外部ファイルに書き出してステータスラインで読む方法です。

# スクリプト側：外部ファイルも読む
input=$(cat)
PCT=$(echo "$input" | jq -r '.context_window.used_percentage // 0' | cut -d. -f1)

# Monitor toolのスクリプトが /tmp/monitor_status.txt に書き出している想定
MONITOR_STATUS=""
if [ -f /tmp/monitor_status.txt ]; then
  MONITOR_STATUS=" | $(tail -1 /tmp/monitor_status.txt)"
fi

echo "Context: ${PCT}%${MONITOR_STATUS}"

この構成にすると「スクリプトの最新行」はステータスラインに、「エラーや異常」だけをチャットに通知、という分離が可能です。

③ refreshIntervalで定期更新する情報

refreshInterval フィールドに秒数を設定すると、イベント駆動の更新に加えてN秒ごとにスクリプトを再実行します。最小値は1秒です。バックグラウンドのサブエージェントがgit状態を変えるときや、時刻ベースのデータを表示したい場合に使います。

{
  "statusLine": {
    "type": "command",
    "command": "~/.claude/statusline.sh",
    "refreshInterval": 10
  }
}

外部APIや時刻を表示したいときに有効です：

# 例：S&P500の価格を15分キャッシュして表示
CACHE=/tmp/sp500_cache.txt
if [ ! -f "$CACHE" ] || [ $(($(date +%s) - $(stat -f%m "$CACHE" 2>/dev/null || echo 0))) -gt 900 ]; then
  curl -s "https://query1.finance.yahoo.com/v8/finance/chart/%5EGSPC" \
    | jq -r '.chart.result[0].meta.regularMarketPrice' > "$CACHE" 2>/dev/null
fi
SP500=$(cat "$CACHE" 2>/dev/null || echo "N/A")
echo "S&P: $SP500"

④ レート制限の残量表示

JSONには rate_limits.five_hour.used_percentage と rate_limits.five_hour.resets_at（リセット時刻のUnixタイム）が含まれており、5時間・7日間のレート制限使用状況をステータスラインに表示できます。

input=$(cat)
RATE5H=$(echo "$input" | jq -r '.rate_limits.five_hour.used_percentage // 0' | cut -d. -f1)
RESET=$(echo "$input" | jq -r '.rate_limits.five_hour.resets_at // 0')
NOW=$(date +%s)
REMAINING_MIN=$(( (RESET - NOW) / 60 ))

echo "5h rate: ${RATE5H}% | resets in ${REMAINING_MIN}min"

⑤ /statusline コマンドで自然言語から自動生成

セッション内で /statusline コマンドに自然言語で指示すると、Claude Codeがスクリプトを自動生成して ~/.claude/ に保存し、設定も自動更新します。

/statusline コンテキスト使用率をプログレスバーで、70%以上で黄色、85%以上で赤で表示。セッションコストと経過時間も表示して

これ自体はトークンを消費しますが（Claudeが生成するため）、生成後の実行はトークンゼロです。

まとめ：「Claudeに聞かなくて済む」情報の一覧

従来の聞き方	ステータスラインで代替
「コンテキストどのくらい残ってる？」	context_window.remaining_percentage
「今いくら使ってる？」	cost.total_cost_usd
「今どのモデル使ってる？」	model.display_name
「レート制限どのくらい使った？」	rate_limits.five_hour.used_percentage
「監視スクリプトまだ動いてる？」	外部ファイル経由で refreshInterval で確認
「何行変更した？」	cost.total_lines_added / total_lines_removed

これらをすべてコンテキストゼロで常時把握できるため、「状況確認のための質問」そのものを排除できます。

---

設定ファイルの場所と役割を整理してお答えします。

結論：2ファイルに分けて管理する

① ~/.claude/settings.json — ステータスラインの「起動設定」

何を書くか： スクリプトへのパスと更新間隔

{
  "statusLine": {
    "type": "command",
    "command": "~/.claude/statusline.sh",
    "refreshInterval": 10
  }
}

場所： ホームディレクトリの .claude フォルダ内 （あなたの環境だと /Users/○○/.claude/settings.json）

このファイルはすでにMCPの設定で触っているものと同じです。既存の内容に statusLine のキーを追加するだけです。

② ~/.claude/statusline.sh — ステータスラインの「中身」

何を書くか： 実際に表示する内容のスクリプト

#!/bin/bash
input=$(cat)
PCT=$(echo "$input" | jq -r '.context_window.used_percentage // 0' | cut -d. -f1)
REMAIN=$(echo "$input" | jq -r '.context_window.remaining_percentage // 0' | cut -d. -f1)
COST=$(echo "$input" | jq -r '.cost.total_cost_usd // 0')
MODEL=$(echo "$input" | jq -r '.model.display_name')

if [ "$PCT" -lt 70 ]; then COLOR='\033[32m'
elif [ "$PCT" -lt 85 ]; then COLOR='\033[33m'
else COLOR='\033[31m'; fi

COST_FMT=$(printf '%.3f' "$COST")
echo -e "${COLOR}[${MODEL}] Context: ${PCT}% used / ${REMAIN}% left | Cost: \$${COST_FMT}\033[0m"

作成後に必ず実行権限を付与します：

chmod +x ~/.claude/statusline.sh

③ jq のインストール（未インストールの場合）

スクリプトがJSONを解析するために必要です：

brew install jq

全体の流れまとめ

~/.claude/
├── settings.json   ← 既存ファイルに "statusLine" を追記
└── statusline.sh   ← 新規作成するスクリプト

/statusline コマンドを使えばClaude Codeがこの2ファイルを自動生成・設定してくれるので、手動で書くより楽です。セッション内で次のように入力するだけです：

/statusline コンテキスト使用率を色分きプログレスバーで、セッションコストと現在のモデル名も表示して

---

#!/bin/bash
input=$(cat)
PCT=$(echo "$input" | jq -r '.context_window.used_percentage // 0' | cut -d. -f1)
REMAIN=$(echo "$input" | jq -r '.context_window.remaining_percentage // 0' | cut -d. -f1)
COST=$(echo "$input" | jq -r '.cost.total_cost_usd // 0')
MODEL=$(echo "$input" | jq -r '.model.display_name')

if [ "$PCT" -lt 70 ]; then COLOR='\033[32m'
elif [ "$PCT" -lt 85 ]; then COLOR='\033[33m'
else COLOR='\033[31m'; fi

COST_FMT=$(printf '%.3f' "$COST")
echo -e "${COLOR}[${MODEL}] Context: ${PCT}% used / ${REMAIN}% left | Cost: \$${COST_FMT}\033[0m"

---

こんな感じで表示されます。

コンテキスト使用率が低いとき（70%未満）→ 緑色

[Claude Sonnet 4.6] Context: 23% used / 77% left | Cost: $0.042

70〜85%のとき → 黄色

[Claude Sonnet 4.6] Context: 74% used / 26% left | Cost: $0.187

85%以上のとき → 赤色

[Claude Sonnet 4.6] Context: 91% used / 9% left | Cost: $0.334

表示される場所

Claude Codeの画面の一番下の行に常時表示されます。プロンプト入力欄のすぐ下のバーです。

補足：Pro/Maxプランの場合

コスト表示は $0.000 のまま変わりません。/cost はAPIユーザー向けで、Pro/Maxサブスクライバーには課金と直結しないため、コストデータは意味を持ちません。

コスト部分を別の情報に置き換えるなら、例えばこう変えると実用的です：

# コストの代わりに経過時間を表示
DURATION_MS=$(echo "$input" | jq -r '.cost.total_duration_ms // 0')
DURATION_MIN=$(( DURATION_MS / 60000 ))
echo -e "${COLOR}[${MODEL}] Context: ${PCT}% used / ${REMAIN}% left | ${DURATION_MIN}min elapsed\033[0m"

長時間かかるスクリプトを走らせるユーザーなら、ステータスラインの活用は地味に有効かもしれない。今、このスクリプトを走らせるかどうかを判断する場合の参考情報になるかもしれない。