きっかけ

Claude CodeをTeamプランで使えるようになりました。

ガンガン業務に使っていくぞ！と思ったのですが、Teamプランにも当然制約があります。

個人プラン同様、5時間ごと、7日間ごとの利用上限があり、これを超えると、月間最大$50のクレジットから消費される設定になっています(この設定はClaude Teamの組織設定によります)。

使いすぎには注意しなければなりません。

 

Claudeのデスクトップアプリを入れておけば、この上限に対する消費率をメニューバーから確認できます。

ただ、このメニューを開かないと状況が見れないので、使用量を気にしながら使うとなると、頻繁にこのメニューを開く必要があります。
さらに、この画面が教えてくれるのは今この瞬間の消費率だけです。

5時間のうち40%を使った、という数字を見ても、それが使いすぎなのかまだ余裕があるのかは、見るタイミングによって変わります。
まだ30分しか経過していないのであれば明らかに使いすぎですし、あと１時間でリセットされるのであればまだ余裕があります。

あと何時間/何日でリセットされるかは表示されていますので、ちょっと考えればわかるのですが、いちいち開いて確認するのも、ちょっと考えるのも面倒です。

理想使用量と実績を比較するアイディア

Claudeに調査させたところ、現在の使用量は以下のコマンドで取得できることがわかりました。
claude -p /usage
この結果はCLI上の表示だけでなく ~/.claude.json の cachedUsageUtilization.utilization に書き込まれるので、その値を使用します。

ただ、必要なのは使用量そのものではなく、使用量を評価するための基準線です。
5時間なり7日間なりの枠を均等に使い続けた場合、今の時点で何%消費しているのが妥当かを計算し、実際の使用量と比較すればいい、と考えました。
理想使用量は単純に、経過時間をサイクルの長さで割るだけで求まります。

メニューバーに常駐させたい

こうしたアイデアをUIに落とし込もうとすると、Claude CodeはすぐにNext.jsでWebアプリを組み始めようとします。
しかし消費ペースを確認するためにいちいちブラウザでページを開くのでは、Claudeアプリの数値を見に行くのと大差ありません。

メニューバーに常駐して勝手に更新される表示があれば…と思っていました。
その要件に合ったのがSwiftBarでした。

SwiftBarについて

SwiftBarは、Macのメニューバーに任意のスクリプトの実行結果を定期表示できるツールです。
Pythonやシェルスクリプトに対応しています。

プラグイン(表示に使うスクリプト)は、ファイル名に更新間隔を埋め込むだけで定期実行されます。
たとえばusage.10m.pyのように名付ければ、10分おきに再実行されて表示が更新される仕組みです。

出力の扱いも単純で、最初の---より前がメニューバー本体に常に表示される行、それ以降がクリックで開くドロップダウンメニューの中身になります(SwiftBar README)。
今回作ったプラグインも、この「本体行に3色アイコン、ドロップダウンにプログレスバーの詳細」という2段構成をそのまま使っています。

作ったもの

メニューバーには、実績の使用量と理想使用量の差分を🟢（余裕あり）🟡（ちょっと注意）🔴（使いすぎ）の3色で表示します。

クリックして展開すると、プログレスバーの中に現在の使用量（■）と理想使用量（▲）を並べて表示します。

これがあることで、今、どれだけClaudeを使っていて、少し控えて別のタスクに手を付けるべきなのか、ガンガン使っていいのか、”スタミナ”を見て判断しやすくなりました。

さらにいちいちメニューを開かなくても、メニューバー表示が「🟢 🟢 🟢」なら気兼ねなく使うことができます。

ちょっとした工夫もしてみた

実際に使う中で、7日間サイクルの表示で問題が浮上しました。

  1. 24時間均等に減り続けると、夜間の稼働していない時間もカウントされてしまって、今の理想使用量が分かりづらい
  2. 毎日均等に減り続けると、土日の稼働していない時間もカウントされてしまって、今の理想使用量が分かりづらい

24時間×7日を分母にすると、金曜の夜に「使いすぎている」と焦っても、土日を挟んで月曜になった頃には理想使用量の方が積み上がっていて、体感としては全然余裕がある、という結果になります。

平日の営業時間だけを枠として数える方が、実際の使い方に合います。

まとめ

SwiftBarはスクリプトを書くだけで使えるうえに、Claude Codeのようなコーディングエージェントがあれば、制作の負担は大幅に軽減されます。

ほんのちょっとの困りごとにアプリを一本作るのは、以前なら割に合いませんでしたが、このような組み合わせでちょっとした困りごとの改善はどんどん進められます。

まだちゃんと実装/運用できていないのですが、この概念をskillに応用して、長期に及ぶタスクの自律実行中にClaudeがスタミナ切れになるのを防ぐ仕組みも構築中です。

消費の激しいClaude Securityや、サブエージェントを複数走らせても、トークン切れを気にせずにつかえるようになるかもしれません。

ここまで読んでいただきありがとうございました！