メインコンテンツへスキップ

Claude Code を監視する Raycast 拡張機能を作った

手書き

「欲しいものは自分で作る」から Claude Code Monitor へ。AI 時代の個人開発者によるツール開発記録。Raycast 拡張機能でセッション監視・トークン使用量・拡張管理を一元化した開発プロセスを紹介します。

·9 分で読める

ある平凡な午後のことだった。

ターミナルでは 5 つの Claude Code セッションが同時に走っていた——ひとつはブログの修正、ひとつはバックエンド API の実装、ひとつはコードレビューの手伝い、残りの 2 つはどこまで進んだかすら分からない。画面を切り替えまくっても、どれが入力待ちで、どれがまだ実行中で、どれが終わったのか、まるで把握できなかった。

「すべてのセッション状態を一目で確認できる場所があればいいのに。」

探し回ってみたところ、Claude Code を監視するツールはいくつか存在していた。しかし、どれも私の期待に完全に合うものではなかった。セッション状態を見るだけでは足りない——セッション、Skills、MCP サーバー、プラグインなど、Claude Code に関するすべてを一元管理できる場所が欲しかったのだ。しかも、どのターミナル、どのエディタから開いたセッションでも、クリックひとつで直接ジャンプできるようにしたかった。

見つからないなら、自分で作るしかない。

Claude Code Monitor のコマンド一覧
Claude Code Monitor:5 つのコマンドで監視・使用量・拡張管理をカバー

AI 時代:欲しいものは自分で作る

この 2 年で最も実感したのは、AI が「ツールが欲しい」と「ツールを持っている」の距離を根本的に変えたということだ。

以前なら、アイデアがあっても誰かが作ってくれるのを待つか、自分で何ヶ月もかけて新しいフレームワークを学んでゼロから書くしかなかった。大半のアイデアの行き着く先は——「まあ、今あるもので我慢しよう」だった。

今は違う。要件を明確に伝えれば、Claude Code が残りをやってくれる。

私の Raycast 拡張機能ページ:以前にも AI で 2 つの拡張機能を作っていた

以前にも AI を使って 2 つの Raycast 拡張機能を作ったことがあったので、この新しいニーズが浮かんだとき、自然と手を動かし始めた——最初の一行目から基本機能が揃うまで、たった一晩で完成した。

Raycast をまだ知らない方は、以前書いた『Raycast:お気に入りの Mac アプリ』を参考にしてほしい。簡単に言えば、macOS 上の効率化ハブで、日常のほぼすべての高頻度操作を Raycast 経由で行っている。だから Claude Code の監視ツールを作りたいと思ったとき、Raycast は最も自然な選択肢だった——メニューバー常駐、キーボード優先操作、ネイティブ macOS パフォーマンス。「ちらっと確認する」使い方にぴったりだ。

AI 時代、誰かが作ってくれるのを待つ必要はない——あなた自身がその「誰か」なのだから。

ペインポイント:なぜこのツールが必要だったのか

ターミナル AI コーディングアシスタントの日常的な摩擦:複数セッション状態の不可視、トークン使用量の無自覚、プラグイン管理の煩雑さ、サーバー状態の不明確さ
ターミナル AI コーディングアシスタントの 4 つの日常的摩擦。ひとつひとつは小さいが、積み重なるとかなりのストレスになる

Claude Code を使えば使うほど、小さな摩擦が蓄積されていく。個別に見ればどれも大した問題ではないが、合わさると毎日注意力を消耗させる。

複数セッションの状態が見えず、ジャンプも面倒

これが最も直接的なペインポイントだ。Claude Code はターミナルで動く。ウィンドウひとつにセッションひとつ。複数プロジェクトを同時に開くのは普通のこと——ブログのスタイルを修正し、プラグインに機能を追加し、ツールライブラリのバグを修正する。しかし問題は、どのセッションが入力待ちで、どれが実行中で、どれが終了済みなのか、まったく分からないことだ。

さらに厄介なのがジャンプだ。ブログプロジェクトのセッションは Zed で開き、プラグインプロジェクトは Warp で走らせ、さらにツールライブラリのセッションもバックグラウンドにある。戻りたい?まずどのプロジェクトがどのウィンドウにあるか思い出して、大量のターミナルから探し出さなければならない。私が欲しかったのは、セッションがどこから開かれたものであっても、クリックひとつで直接ジャンプできること。

トークン使用量の感覚がない

毎日 Claude Code でコードを書いていれば、トークンはずっと消費され続ける。CLI には /cost コマンドがあるが、サブスクリプションユーザーには「サブスクリプション枠を使用中」としか表示されず、具体的な数字すら見えない。どのプロジェクトが最も多くトークンを消費しているのか?今日の使用量は昨日と比べてどうか?モデルごとの消費分布は?これらの疑問に、まったく答えがなかった。

プラグインの更新と管理が煩雑

Claude Code のプラグインエコシステムはどんどん充実しているが、十数個の plugins を管理するのは非常に原始的だ——インストール済みのプラグイン、バージョン、アップデートの有無を確認するには設定ファイルを漁るしかない。有効化、無効化、更新、アンインストール、すべてコマンドライン操作が必要だ。

Claude Code プラグイン管理画面
プラグイン管理はすべてコマンドライン頼み。アップグレードしても本当に反映されたか確信が持てない

さらに頭を抱えるのがアップグレード体験だ。やっとプラグインをアップグレードしたのに、次に Claude Code を起動すると旧バージョンに戻っている。コマンドラインは「アップグレード成功」と言うが、本当にアップグレードされたのか確認する術がない——バージョン比較もなければ、変更ログもなく、すべてのプラグインの実際のバージョンを一覧できる場所もない。プラグインが増えると、管理は完全に記憶頼みの力仕事になる。

Skills と MCP サーバーの状態が不明

Skills をインストールした後、本当に有効になっているかどうやって確認する?ユーザーレベルなのかプロジェクトレベルなのか?どの plugin からインストールされたのか?さらに厄介なのは MCP サーバーだ——5 〜 6 個設定しても、どれが接続済みで、どれが再認証が必要で、どれがそもそも接続できないのか分からない。これらの情報は異なる設定ファイルに散在しており、全体像を見渡せる場所がない。

結局のところ、私が必要だったのはコントロールパネル——すべてのセッション状態、使用量分布、拡張機能の健全性を一目で把握できるものだ。

開発プロセス

開発フロー概要:PRD 策定、データフロー設計からマトリョーシカ式デバッグまで
開発フロー全体:PRD 策定 → Hooks + JSONL データフロー → Raycast 表示 → AI で AI をデバッグ

ステップ 1:PRD を書いて要件を明確にする

AI でコードを書くとき、最も重要なステップはコードを書くことではない——要件を明確にすることだ。

まず Claude Code に PRD(プロダクト要求仕様書)を書いてもらい、欲しい機能をひとつずつ列挙した:セッションのリアルタイム監視、メニューバー常駐ステータス、使用量統計パネル、拡張管理(Plugins + Skills + MCP Servers)、ワンクリックジャンプと復帰。各機能の想定インタラクション、データの取得元、表示方法はすべて PRD に記載した。

PRD が完成した後は、ドキュメントに沿ってモジュールごとに実装を進めるだけで、Claude Code にコンテキストを改めて説明する必要はほとんどなかった。

ステップ 2:既存ソリューションのリサーチ

PRD 確定後、Claude Code に調査させた:市場にはすでにどのような Claude Code 監視のオープンソースツールがあるか?それらはどう実装されているか?

調査の結果、既存ソリューションの大半はJSONL ファイルの読み取りをコアアプローチとしていることが分かった。Claude Code は各セッションの記録を ~/.claude/projects/ ディレクトリ配下の .jsonl ファイルにリアルタイムで書き込んでおり、各ラウンドの対話のトークン数、使用モデル、タイムスタンプなどの情報が含まれている。これらのファイルを解析すれば、セッションの詳細データを復元できる。

JSONL のデータは豊富だが、統計分析——トークン累計、モデル分布、プロジェクト比較——に向いている。セッションのリアルタイム状態追跡(どれが入力待ちか、どれが実行中か)を行うには、別のデータソースが必要だ。

そこで登場するのが Claude Code Hooks API だ。Hooks は Claude Code が公式に提供するライフサイクルイベント機構で、SessionStartUserPromptSubmitPreToolUseStopSessionEndNotification などのイベント発生時にスクリプトを自動実行するよう登録できる。以前から Claude Code で Hooks を使っていたので、イベント駆動の状態追跡が可能だと分かっていた。

方針は明確だった——Hooks がリアルタイム状態を担当し、JSONL がリッチなメタデータを提供する。2 つのデータソースを補完し合えば、完全な監視ソリューションが構築できる。

なぜ Web パネルや VS Code 拡張機能ではなく Raycast を選んだのか?理由は単純だ。Raycast はもともと私の効率化ハブであり、メニューバー常駐アイコンをサポートしている。ウィンドウを開かなくてもステータスをちらっと確認できる。キーボード操作もシームレスで、ワークフローを中断しない。しかも Raycast 拡張機能の開発は React + TypeScript で、私には馴染み深い技術スタックだ。

ステップ 3:一晩で機能を完成させる

PRD と技術方針が揃えば、あとは Claude Code に実装を任せるだけ。システム全体のデータフローは 2 つのラインに分かれる:

Claude Code ライフサイクルイベント


    hook.sh (Bash + 内蔵 Python)

        ├── アトミックファイルロック (mkdir)
        ├── イベント → 状態マッピング
        ├── 非同期 AI ラベル生成 (Haiku)
        └── 期限切れセッションのクリーンアップ


    sessions.json (リアルタイム状態)

        └──────────┐

        Raycast Extension
          useSessions Hook

        ┌──────────┘

    ~/.claude/projects/**/*.jsonl

        └── Chunk-based 正規表現解析
            (256KB 固定メモリ)

要約すると、Hooks がリアルタイムイベントをキャプチャして sessions.json に書き込み、JSONL 解析がトークンやモデルなどのメタデータを提供し、Raycast 拡張機能が両者を統合して表示する。技術的な詳細——アトミックファイルロック、chunk-based 正規表現解析、AI ラベル生成、ディスクキャッシュ——はすべて Claude Code が自ら選択したもので、私は動けば OK という姿勢で検収しただけだ。

本当に面白かったのはその後のデバッグだ。自分で作ったツールで Claude Code を監視し、次々と問題を発見して修正するサイクル:

  • Subagent がパネルを埋め尽くす:起動直後、セッション一覧に大量の見覚えのない session が突然出現。調べてみると、Claude Code のサブエージェント起動も Hook をトリガーしており、ひとつのメインセッションが十数個の subagent を派出してパネルが爆発していた。フィルタリングを追加して解決。
  • MCP の偽エラー:Extensions ページでいくつかの MCP が "Unreachable" と表示されていたが、実際には正常に動いていた。stdio モードの MCP に HTTP ヘルスチェックを行うべきではなかったのだ。
  • Worktree が認識されない:当初、worktree セッションをまったく検出できなかった。.claude/worktrees/ パスを正規表現でマッチングするよう追加して解決。
  • プラグイン更新が偽物:拡張管理を実装中、Claude Code 自体のバグを発見——プラグイン更新時に CLI がリモートリポジトリから最新版を取得せず、ローカルキャッシュと比較するため、常に「最新です」と表示されていた。拡張機能側で更新前に手動で marketplace リポジトリを git pull するステップを追加し、プラグイン更新を本当に機能させた。

「自分で使う→問題を発見→ Claude Code に修正させる→また使う」というサイクルの繰り返しだ。Claude Code で Claude Code を監視するツールを作り、そのツールでツールを書いている Claude Code を監視する。マトリョーシカ状態である。

ステップ 4:アイコンの作成

開発プロセス全体で、唯一手動で行う必要があったのがアイコン作成だった。

まず iconfont で探し回り、Claude Code の小さなカニに一目惚れした——この造形は抜群に識別しやすい:

iconfont で見つけた Claude Code のカニアイコン
iconfont で見つけた Claude Code のカニ。一目で決定した

次に Raycast 公式の Icon Maker ツールで配色とスタイルを選び、最終的な拡張機能アイコンを生成した:

Raycast Icon Maker で拡張機能アイコンを作成
Raycast Icon Maker で最終的な拡張機能アイコンを生成

このステップを除けば、コーディングから Raycast Store への提出まで、すべて Claude Code が操作した。私はコードを一行も手動で変更していない。

機能紹介

セッション監視

これが拡張機能全体のコア機能だ。Claude Code Sessions を開くと、すべてのセッションがステータス別にグループ化される:Active(実行中)、Waiting for Input(入力待ち)、Idle(アイドル)、Ended(終了済み)。

各セッションには、プロジェクト名、AI 生成ラベル、エディタ/ターミナルタイプ、Git ブランチ、継続時間が表示される。Git worktree 内で実行中のセッションには worktree バッジも表示される。

Claude Code Sessions のセッション一覧
セッション一覧:リアルタイム状態グループ、AI ラベル、worktree バッジ、ワンクリックジャンプ

任意のセッションを選択して Enter を押すと、対応するエディタウィンドウ(VS Code、Cursor、Zed、Windsurf 対応)またはターミナル(Terminal、iTerm2、Warp、Ghostty、kitty)に直接ジャンプできる。終了済みのセッションはワンクリックで resume でき、手動で claude --resume を入力する必要はない。

メニューバー常駐

Claude Code Status はメニューバーアイコンとして、現在のアクティブセッション数を常時表示する。色はステータスに応じて変化する:緑はセッション実行中、オレンジは入力待ちのセッションあり、黄色はすべてアイドル。

アイコンをクリックするとドロップダウンメニューが展開され、すべてのセッションのプロジェクト名、ターミナルタイプ、継続時間、ステータスが一目で分かる。どの項目をクリックしても直接ジャンプできる。

Claude Code Monitor のメニューバー
メニューバー常駐:ウィンドウを切り替えずに、すべてのセッション状態を一目で把握

これで最大のペインポイントが解消された——ターミナルウィンドウをひとつずつ切り替える必要がなくなった。メニューバーをちらっと見るだけで、オレンジなら待っている、緑なら作業中、それ以外は放っておけばいい。

しかもこのステータスバーがあると、無意識のうちに常に緑を保ちたくなる——つまり、常にセッションが走っていて、常に作業が進んでいる状態。全部黄色になったら急いで次のタスクを投入する。要するに Claude Code を一分たりとも休ませず、徹底的に使い倒すのだ。

使用量パネル

Claude Code Usage は完全なトークン使用量統計を提供する。上部は概要表:今日、今週、今月のトークン消費量とセッション数。

下には日次使用量のトレンドグラフ(直近 7 日間)、モデル別消費(Opus vs Sonnet vs Haiku)、プロジェクト別使用量ランキングが表示される——ついにどのプロジェクトが最もトークンを消費しているか分かるようになった。

Claude Code Usage ダッシュボード
使用量パネル:トークンのトレンド、モデル分布、プロジェクトランキングが一目瞭然

今ではときどきこのパネルを確認し、各プロジェクトのトークン消費状況を把握している。あるプロジェクトの使用量が異常に高いことに気づいたときは、戦略を即座に調整できる——たとえば、単純なタスクを Opus から Sonnet に切り替えるなど。

拡張管理

Claude Code Extensions は Plugins、Skills、MCP Servers の 3 つの側面をひとつの画面に統合している。

Plugins ページでは、インストール済みのすべてのプラグインが一覧表示され、有効/無効状態、バージョン、ソースリポジトリが表示される。ワンクリックで有効化、無効化、更新、アンインストールが可能で、各プラグインに含まれる commands、skills、agents、MCP servers も確認できる。

Claude Code Extensions のプラグイン管理
プラグイン管理:バージョン、状態、ソースが一目瞭然。設定ファイルを漁る必要なし

MCP Servers ページでは、すべての設定済み MCP サーバーとその接続状態が表示される——Connected(接続済み)、Needs Auth(認証が必要)、Unreachable(到達不能)。認証が必要なサーバーについては、認証リンクを直接開いて認可を完了できる。

MCP Servers の状態監視
MCP サーバー状態:どれが接続済みで、どれが認証必要で、どれがダウンしているか一目瞭然

「この MCP は本当に接続されているのか?」と推測する必要はもうない。

ちょっとしたハプニング:アカウントが凍結された

開発中にちょっとしたトラブルが発生した。

この拡張機能には、各セッションに自動でラベルを生成する機能があり、Raycast 内蔵の AI 機能を利用している。デバッグ中、複数の Claude Code セッションを同時に開いて繰り返しテストしていたため、セッションが起動するたびに Raycast AI が呼び出され、短時間でリクエスト量が一気に跳ね上がった。

するとある日、Raycast を開いたらログインできなくなっていた。メールログインもダメ、GitHub ログインもダメ。

受け取った凍結通知は非常に物々しいものだった:永久凍結、利用規約第 IV、VI、VIII 条違反、「AI の濫用」、復旧不可。

完全に頭が真っ白になった。200 ドルの Claude クレジットすら使い切る暇がないのに、何を濫用したというのか。

急いで Raycast の Slack コミュニティに申し立てのメッセージを送り、GitHub リポジトリのリンクを貼って、コードを見てくれ、これは普通の Claude Code 監視プラグインで、AI 呼び出しはプラグイン機能の一部であって濫用ではない、と説明した。

Raycast Slack コミュニティでの申し立てのやり取り
Raycast Slack コミュニティで申し立て。2 日待ってようやく返信をもらえた

ところが週末にぶつかり、Raycast チームは休みだった。2 日待って、月曜日にようやく Tirta から返信があった。幸い対応は丁寧で、すぐに謝罪してくれた——自動検知システムがプラグインの正常な高頻度 AI 呼び出しを濫用と誤判定してしまったとのこと。このような拡張機能駆動の呼び出しパターンは想定外だったらしく、自分たちの問題だと認めてくれた。アカウントはすぐに復旧した。

肝を冷やしたが、逆に考えれば、このプラグインが本当に真面目に仕事をしている証拠でもある——ただ少し働きすぎて、プラットフォーム側を困惑させてしまっただけだ。

おわりに

最初のひとつの思いつき——「すべてのセッション状態が見られたらいいのに」——から、今の Claude Code Monitor まで、コア機能はたった一晩で完成した。これが AI 支援開発のリアルな体験だ。セッション監視、使用量統計、拡張管理、メニューバー常駐を備えた完全なツールが、アイデアから使える状態まで、予想を超える速さで実現した。

これが AI 時代から一般の開発者への贈り物だ:生産性の限界は、どの技術スタックを知っているかではなく、どんな問題を解決したいかで決まる

プロジェクトはオープンソースで公開済み、MIT ライセンス。ぜひ使ってみてほしい:

GitHub:wuyuxiangX/claude-code-monitor

あなたも Claude Code のヘビーユーザーなら、ぜひ試してみてほしい。もし完全にはニーズに合わなければ——大丈夫、自分で作ればいい。今のあなたにはその力がある。

コメント

Claude Code を監視する Raycast 拡張機能を作った | Yuのサイバーデスク