yohakulab

Claude Codeの使用量をメニューバーに出すまで、3回作り直した話

公開

Claude Codeを使っていると、5時間ごと・週ごとの使用量が今どれくらい残っているか、クリックせずにひと目で見えてほしくなります。そこで、macOSのメニューバーに常時表示する個人用のツールを自作しました（yohakulabの公開アプリではなく、手元だけで使っているローカルツールです）。最終的にたどり着いたのは、Anthropic公式のMessages APIが標準で返す「レート制限ヘッダー」を読む方式でした。ただ、そこに着くまでに3回、方式をまるごと作り直しています。今回はその遠回りの記録です。

やりたかったことと、既存ツールを見送った理由

欲しかったのはシンプルで、メニューバーに常時パーセンテージが出ていることの一点でした。クリックして初めて数字が見える方式だと、結局チェックする習慣が続きませんでした。

既存ツールもいくつか調べました。

要件にぴったり合うものがなかったので、自作することにしました。xbar（無料のメニューバーカスタマイズアプリ）のプラグインとしてPythonスクリプトを1本書けば済むだろう、と当初は軽く考えていました。

1回目：ローカルログ解析——「使った量」は出せても「残り%」は出せない

Claude Codeは会話のログを手元に .jsonl 形式で保存しています。ここにはトークン使用量の記録が含まれているので、まずはこれを集計する方式を試しました。Cookieも外部APIも不要で、安全そうに見えたからです。

ところが、これでは自分が実際に使ったトークン数は出せても、「Anthropicが管理している5時間・週次の上限に対する残り%」は出せないことがわかりました。上限の値自体が公開されていないため、分母が手元にないのです。CLIに /status を打たせて数値を横取りする方法も試しましたが、そちらの出力にも残り%は含まれていませんでした。

「自分で決めた目安トークン数に対する相対%」を出す案も考えましたが、知りたかったのは公式の正確な数字だったので、この方式は見送りました。

2回目：Cookie方式——動いたが、こまめに切れる

次に試したのが、claude.aiにログインした状態のブラウザCookieを使い、Web版が内部で叩いている使用量APIを直接呼ぶ方式です。OSSツール（ClaudeUsageBar）のSwiftソースコードを読みに行ったところ、https://claude.ai/api/organizations/{orgId}/usage という内部APIと、レスポンスの five_hour.utilization / seven_day.utilization というフィールドの存在がわかりました。

これは実際に動きました。ただ、セッションCookieはブラウザのタブを閉じると失効し、そのたびにDevToolsを開いてCookie値を手動コピー、Keychainに貼り直す運用になってしまいました。これが何度も発生するのは、常時表示を目指した当初の目的からするとかなり本末転倒です。

セットアップスクリプト自体にも小さなつまずきがありました。ターミナルの read -s プロンプトにCookie値がうまく貼り付けられず、.command ファイルをFinderでダブルクリックし、ネイティブダイアログにペーストする方式に変更しています。ターミナル操作に不慣れな場面でも確実に動くのはこちらでした。

自動化を3案試して、3案とも撤回した

Cookie失効の手間をなくすため、取得を自動化できないか3つの案を試しました。

  1. Claude Code自身がKeychainに持つOAuth資格情報の流用 —— スコープがAPI推論用で、Web版の使用量APIには使えないと判明。
  2. ブラウザ自動操作ツール経由での定期取得 —— 会話中にしか動かせない仕組みで、バックグラウンドで無人稼働させる用途には合いませんでした。
  3. ChromeのローカルCookieデータベースを、Keychain由来の鍵で復号して自動取得 —— 鍵の導出と復号自体は成功したものの、一部のCookie値が壊れる不具合が出て安定しませんでした。

3案目は、技術的な不具合よりも前に踏みとどまる理由がありました。「他アプリが暗号化して保護しているデータを、正規のAPIを介さずに取り出す」という設計そのものが、自分のデータであっても筋が悪いと感じたからです。ブラウザ側は今後もこうした手法への対策を入れてくるはずで、直しても直しても壊れる消耗戦になりかねません。結局この3案はすべて撤回し、Cookie手動運用を続けることにしました。

3回目：「製品版は何をしているのか」を、もう一度確かめにいった

自動化を諦めて手動運用に落ち着いたはずが、ここで一つ問いが浮かびました。実際に製品化されているツールは、いったいどういう手段でこの数字を取っているのか。 その方式なら実現できないのか、あらためて確認することにしました。

もう一度OSSのソースコードを読みに行きます。今度はhamed-elfayome/Claude-Usage-Trackerという、2026年3月時点で活発に更新されていたツールです。ソースコードのコメントに、次の2点がはっきり書かれていました。

これで探していたものが見つかりました。Cookieのような非公式・不安定な仕組みに依存せず、公式APIの標準機能だけで完結する方式です。429（レート制限中）が返ってきてもヘッダー自体は付与されるため、取得に失敗しないという利点もありました。

実装で踏んだ小石

方式が決まってからも、細かいつまずきがいくつかありました。

まず、私のMacではClaude Code標準のKeychain項目にOAuthトークンが空で入っており、直接の流用はできませんでした。代わりに使ったのが claude setup-token という正規のCLIコマンドです（Claudeの有料プランが前提のコマンドです）。ターミナルで実行すると長期間有効なトークンが発行されるので、それを先ほどと同じくGUIダイアログ経由でKeychainに保存する運用にしました。

ここでもコピペの事故が2回起きています。ターミナル出力を貼り付ける際に空白や改行が混入し、トークンが壊れて401エラー（認証エラー）になりました。原因を切り分けたあと、貼り付けた値から内部の空白を正規表現で全部取り除く処理を入れて解決しています。

もう一つはxbar側の表示バグです。ドロップダウンメニューの詳細行だけ文字色が薄く表示され、色指定をいろいろ試しても直りませんでした。切り分けていくと、次のようなことがわかってきました。

最終的に、色による表現はあきらめ、太字とフォントサイズの差だけで情報の階層をつける方式に落ち着きました。ドロップダウン全体が半透明で描画されており、通常の文字色指定はその合成で薄まってしまうけれど、太字だけは合成に負けず視認性を保てる——というのが、この環境固有の癖だったようです。

今の運用

今は claude setup-token で発行した長期トークン（有効期限1年）をKeychainに保存し、1分おきにヘッダーを読みに行く方式で落ち着いています。Cookie特有の失効やブラウザ側の対策変更に振り回されることがなくなり、体感の安定度はかなり上がりました。

副作用として、メニューバーを更新するたびにAnthropicへごく小さなAPIリクエストが飛ぶ仕様にはなっています（1分間隔なら1日1,440回、Haikuモデルで1トークン分）。使用量への影響はごくわずかですが、チェックする行為自体がわずかに使用量を消費する、という構造は踏まえておく必要があります。

コードはGitHubで公開しています。claude setup-token で発行したトークンをKeychainに保存し、xbarのプラグインとして動かすだけなので、同じ環境（macOS + Claude Code + xbar）なら手元でも試せます。

振り返って

一番遠回りだったのは、「自動化できない」と一度結論を出したあとに、もう一段上の「そもそもCookie方式をやめられないか」を考え直したところでした。目の前の課題（Cookie失効の手間）を解決しようとするより、前提（Cookie方式そのもの）を疑い直したことで、結果的に一番シンプルな答えにたどり着いています。

OSSのソースコードを実際にcloneして読みに行ったのも効きました。今回、ドキュメントには載っていない実装の勘所は、動いているコードのコメントの中にありました。

筆者：yokafolio。「シンプルなアプリと、余白のある暮らし。」をテーマに、登録不要で開いてすぐ使えるWebアプリを作っています。

← 記事一覧へ