ClaudeとCodexの残量をタスクバー常駐で見る「残量バー」を自作した記録

Claude Code を重いモデルで走らせていると、あとどれくらい使えるのかが見えません。/usage を打てば出ますが、打たないと分かりません。Codex にレビューを往復させている間も同じです。

そこで、両方の残量をタスクバーに出しっぱなしにする常駐ツールを自作しました。この記事は、そのときに叩いて分かった仕様と、AI のレビューで出てきた欠陥19件の記録です。

Claudeの残量を、作業中ずっと見ていたい

/usage を打てば、5時間枠と週次枠の使用率は出ます。困っていたのは、打たないと分からないことです。

重いモデルや高い effort で走らせていると、枠の減り方が変わります。この設定のまま続けたらあとどれくらい使えるのか、そこが読めません。打てば分かるとはいえ、気になるたびに手を止めて打つことになります。

Codex も同じです。私は AI 同士にレビューを往復させる運用をしているので、回している間ずっと枠が減っていきます。/status を打てば出ますが、こちらも打たないと分かりません。

欲しかったのは、打たなくても目に入る状態です。数字が常に見えていれば、今の設定で続けるか落とすかを、その場で決められます。

既製のツールは8本あった。それでも作ってみた

同じことを考える人は当然いて、監視ツールは探すとすぐ出てきます。私が見つけたのは8本です。目についたのは codex-minibar、Claude-Code-Usage-Monitor、ai-usage-widget、CodexBar-Win あたりです。いずれも 2026年8月に GitHub で確認しました。

機能は十分です。私が作ろうとしていたものより多機能なものもあります。

それでも自分で作りました。いちばん大きかったのは「これくらいなら AI に作らせられるのではないか」という興味です。どれを入れるか比べている時間で作れてしまうかもしれない、と思いました。

もう1つ、入れるのをためらう理由もありました。この種のツールは、残量を出すという役割の性質上、次の2つをやることになります。

• ローカルに保存されている認証情報を読む（Claude なら ~/.claude/.credentials.json、Codex なら ~/.codex/auth.json）
• そのトークンを持って、公開されていないエンドポイントへ通信する

たとえば codex-minibar は、GitHub の説明文で「ログインせずに利用上限を監視する」と掲げています（2026年8月に確認）。ログインせずに数字が出るということは、すでにローカルにある認証情報を使っている、ということです。つまり、私のアカウントのトークンを読める実行ファイルを常駐させることになります。

そのトークンをどこへ送っているかは、ソースを読まない限り分かりません。読んだとしても、配布されているバイナリがそのソースから作られている保証はありません。

API キーやトークンの置き場所は、以前 1Password に集約する記事を書いたくらいには気にしています。そこまでやっておいて、中身を確かめていない常駐アプリに同じものを渡すのは、少し落ち着きが悪く感じます。

ただ、公開されているツールが危険だと言いたいわけではありません。悪いところは何も見つけていません。私が確かめていないだけです。

作ってみるかという気持ちが先にあって、確かめるより作るほうが早そうでした。それが実際のところです。

作ったもの: タスクバーに置く2行の帯

できたものがこれです。記事の中では「残量バー」と呼びます。

タスクバーの空いている場所に置いています。幅は480ピクセル、高さは48ピクセルです。60秒ごとに勝手に更新されます。Windows の起動時に立ち上げる登録スクリプトも用意しましたが、私自身はまだ登録しておらず、今は手で起動しています。

読み方は単純です。上が Claude、下が Codex。それぞれ「5時間枠」「週次枠」が並び、Claude はもう1つ、モデル別の週次枠（この画面では Fable）が付きます。数字は使用率で、カッコの中がリセットまでの残り時間です。

この画面では Claude の週次枠が50%、Fable 枠が73%まで来ていて、どちらも4日13時間後に戻ります。

Codex の5時間枠が — になっているのは、5時間枠そのものが返ってこないためです。以前はあった記憶がありますが、2026年8月時点の私の環境では見当たりません。列を残しているのは、Claude 行と桁の位置を揃えるためです。ここを詰めると上下の数字がずれて、かえって読みにくくなります。

色は使用率で変わります。69%までが緑、70〜85%が黄色、86%以上が赤です。点滅はしません。視界の端で光るものが動くと、それだけで作業の邪魔になります。

逆に、入れなかったものもあります。履歴のグラフ、コスト計算、通知、クリックで開く詳細画面。全部やめました。欲しかったのは「ちらっと見れば分かる」ことだけで、それ以上を足すと見る手間が発生します。

エンドポイントを叩いて分かった仕様

ここからは、実際に自分で叩いて確かめた内容です（2026年8月15日に実測。いずれも公開されている仕様ではないので、変わる前提で読んでください）。

手順としては、認証ファイルを読んで両方のエンドポイントを叩くだけの使い捨てスクリプトを書き、それを自分の手で実行しました。トークンを触るスクリプトの実行を AI に任せるのは、この記事の趣旨と正面から矛盾するためです。

Claudeは limits[] だけを読めばいい

レスポンスには five_hour や seven_day といった分かりやすい名前のフィールドが並んでいます。ところが、私が実測した範囲では seven_day_opus と seven_day_sonnet はどちらも null でした。

実際の値が入っているのは limits[] という配列です。ここに3つ並んでいて、kind で見分けます。

• session ＝ 5時間枠
• weekly_all ＝ 週次の全体枠
• weekly_scoped ＝ モデル別の週次枠。scope.model.display_name にモデル名が入る

私の環境では、この3つ目に Fable が入っていました。名前の付いたフィールドだけを見ていると、いちばん見たい枠が丸ごと視界に入りません。

なお、この3つ目に入るモデル名は、こちらで決め打ちにしていません。モデルのラインナップは入れ替わるので、名前を固定すると、入れ替わった時点でその枠が表示から消えます。しかも消えたことに気づけません。

そのため、既知のモデル名の一覧を持っておき、当てはまるものを拾う形にしました。どれにも当たらなければ、その枠は表示しません。

Codexは窓の位置で枠の種類を判定できない

Codex のレスポンスには primary_window と secondary_window という2つの枠があります。名前からすると、primary が短いほうの枠で secondary が週次枠のように読めます。

実測は違いました。primary_window に週次枠（limit_window_seconds が 604800 秒＝7日）が入っていて、secondary_window は null でした。

ここで位置を信じて「primary は短いほうの枠」と決め打ちにすると、週次枠の数字を5時間枠として表示することになります。中身を見ずに並び順で判断すると、実際とは違う枠に見えるわけです。limit_window_seconds の値そのものを見て、18000秒なら5時間枠、604800秒なら週次枠、と振り分ける必要があります。

トークンは8時間で切れる

認証ファイルに入っているアクセストークンの有効期限を見たところ、取得時点から約8時間後でした。

常駐ツールとしては、これが設計に効いてきます。起動時に1回だけ読んで持っておく作りにすると、朝つけたものが昼過ぎには数字を出せなくなります。取得のたびにファイルを読み直す形にしました。

あわせて、トークンの更新は実装していません。更新すると認証ファイルを書き換えることになり、Claude Code 本体と取り合いになってログインを壊す可能性があります。このツールは認証ファイルを読み取り専用でしか開きません。期限が切れている間は「認証待ち」と表示して、本体が更新してくれるのを待ちます。

AIのレビューで19件の欠陥が出ました

実装は Claude に書かせました。私が書いたのは設計と、レビューの回し方です。

できあがったコードは実装だけで約1,500行、それに自動テストが140件付いています。そのうえで、見つけて直した欠陥が19件ありました。しかも12件は、コードを書く前の計画そのものの誤りです。

いくつか挙げます。

• リセット残時間の幅を5文字と決めていたが、2桁時間と分が並ぶと 13h53m で6文字になる。週次枠はリセット前の11時間ほど、毎週この帯域を通る
• キューから取り出す役が例外で自分を止めてしまい、帯が固まってタスクマネージャ以外に終わらせる手段が無くなる
• 起動直後、まだ一度も取得していない状態を、正常時と同じ見た目で表示してしまう。数字が無いのか、枠を使っていないのか区別がつかない

最後のものは、このツールでいちばん困る壊れ方です。古い数字や無い数字を正常時と同じ見た目で出すと、余裕があると思い込んだまま作業を続けることになります。残量を見るために作ったツールが実態と違う数字を出す形になるので、ここは表示を分けました。

ちょうどこの記事を書いている最中に、その分けた表示が出ました。Claude 側が HTTP 429 を返して取得できなくなった状態です。

上の Claude 行だけ、数字も含めて全体が暗い灰色に落ちています。数値そのものは残していますが、これは最後に取れた値です。下の Codex 行は取得できているので通常の色のままです。取れていない提供元だけが灰色になる形にしてあります。

Codexだけが見つけた3件

ここが今回いちばん書きたかったところです。

私は AI のレビューを1回で終わらせない運用にしています。レビューを往復させるルールを作って、指摘が出なくなるまで回す形です。今回もそれに沿って、Claude 系のレビューを5回通しました。

そのあと Codex に投げたら、3件出ました。5回のレビューで誰も触れなかった箇所です。

• リダイレクトされたとき、転送先に Authorization ヘッダがそのまま付いていく
• トレイアイコンが起動後に消えると、終了手段が無くなる
• 中身が壊れた 200 応答を正常な取得として扱うため、再試行も古さの表示も働かない

同じモデルを何度も往復させると、同じ角度からしか見ない、ということだと思います。違うモデルを1回通したほうが速い場面がある、というのは以前に同じ急所を3回直した記事を書いたときにも感じていました。

リダイレクト先にトークンが届くのを再現しました

1件目は指摘を読んだだけでは信じきれなかったので、自分で再現しました。

ローカルにサーバーを2本立てます。片方（A）にアクセスすると、もう片方（B）へリダイレクトするだけの構成です。A へ Authorization: Bearer を付けて投げ、B に何が届いたかを記録しました。

=== urllib.request ===
  A(host=127.0.0.1:50165): Authorization='Bearer SECRET-TOKEN-VALUE'
  B(host=localhost:50164): Authorization='Bearer SECRET-TOKEN-VALUE'
=== requests ===
  A(host=127.0.0.1:50165): Authorization='Bearer SECRET-TOKEN-VALUE'
  B(host=localhost:50164): Authorization=None

標準ライブラリの urllib.request では、B にトークンがそのまま届いています。外部ライブラリの requests では届いていません（2026年8月16日に自分の環境で実行した結果です）。

私が使っていたのは urllib のほうです。依存を増やしたくなくて標準ライブラリを選びました。この点では守りが薄いほうを選んでいたことになります。

その修正が、いちばん重要なテストを無効にしました

ここが今回の副産物です。

リダイレクトの件を直すために、通信の入口を専用の部品に差し替えました。ところがその差し替えによって、トークンが漏れていないことを確かめるテストが、実際には何も検査しない状態になりました。テストは今までどおり通ります。中で見ている対象が、もう使われていない古い場所を指しているだけです。

これはセキュリティの修正としては最悪の形です。守りを固める変更が、その守りが効いているかを見る仕組みを警告なしに外していました。しかも表示上は今までどおり全部通ります。

気づけたのは、修正を担当した AI が「これは自分の担当範囲の外だが、こうなっている」と報告してきたためです。指示していない範囲の異常を報告する余地を残しておいたことが効きました。テストの検査対象を差し替えて、あわせてリダイレクト対策そのものの回帰テストを3件追加しました。

ソースは公開しません

ここまで書いておいて申し訳ありません。このツールのソースは公開していません。私専用のリポジトリに置いたままです。

認証情報を読むツールを配るなら、脆弱性が見つかったときに直す責任と、使う人からの問い合わせに答える責任が発生します。私はその責任を引き受けられません。引き受けないまま配れば、私が中身を確かめていない8本と、他人から見て同じ位置に立つことになります。

その代わり、仕様は上に全部書きました。どのファイルを読んで、どのエンドポイントを叩いて、レスポンスのどこを見るか。ここまで分かっていれば、同じものを自分の AI に作らせることができます。自分で作れば、少なくとも中で何をしているかは自分が知っている状態になります。

作るときに気をつける点も、この記事に書いたものがそのまま使えます。トークンを更新しない、認証ファイルを書き換えない、ログにトークンを出さない、リダイレクトを追わない。この4つを外さなければ、大きくは事故りません。

まとめ

作ってみて分かったのは、残量が見えていると設定の選び方が変わる、ということです。減りが早いと分かれば、モデルや effort を落として続けます。今までは気になるたびに手を止めて打つか、気にせず走らせて後で驚くかのどちらかでした。

もう1つ、AI に書かせたものを自分で確かめる作業は、確実に増えます。この記事の材料になった欠陥19件は、全部その過程で出てきたものです。Threads の投稿を自動化したときも同じ構図でした。

作らせるのは速いです。ただ、確かめる工程を省くと、動いているように見えるものが出来上がります。