Claude Codeを使っていて、こう思ったことはありませんか？
「あと、どれくらい使えるんだろう」
画面の隅には使用量バーがあります。
ところが、AI自身はその値を認識していません。
海外コミュニティで、ある開発者の投稿が話題を集めました。
Claude Codeのこの問題に、正面から取り組んだ内容です。
本記事では、その投稿を取り上げます。
あわせて、コメント欄で交わされた議論も整理しました。
一次情報として参考になる議論が多くありました。
そこから、技術的なポイントと注意点を抜粋しています。
なぜClaude Codeは自分の残量を見えていないのか
Claude Codeを本格的に使い始めると、ある違和感に気づきます。
モデルは、自分が今どれだけクォータを消費したかを把握できません。
UI側にはきれいな進捗バーが表示されています。
しかし、モデル本体には、その情報が一切渡されていないのです。
会話の最中に「現在の使用率は？」と聞いても、Claudeは答えられません。
会話中の使用量を取得するAPIやツール、フックが提供されていないからです。
これは設計上の盲点と言えるでしょう。
バーがあるのだから、データはどこかに存在するはずです。
ただ、モデルから見える場所には届いていません。
レスポンスヘッダーに隠されたヒント
投稿者が突き止めたのは、興味深い事実でした。
Anthropicは推論レスポンスごとに、レート制限関連のヘッダーを返しています。
具体的には anthropic-ratelimit-unified-5h-utilization や anthropic-ratelimit-unified-7d-utilization といった名前のヘッダーです。
Claude Code自体は、これらのヘッダーを内部的に受け取っています。
UIのバーを描画するためです。
ところが、その値はモデルに渡る経路には乗っていません。
情報は「ある」のに「届かない」状態だったわけです。
ここに気づけば、解決の方向性は自然と見えてきます。
ローカルプロキシで橋渡しする
提案された方法は、いたってシンプル。
Claude Codeと api.anthropic.com の間に、自前のローカルHTTPプロキシを挟むだけです。
Claude Codeは ANTHROPIC_BASE_URL という環境変数を尊重します。
そこで、この変数を http://127.0.0.1:4080 のような自前のアドレスに向け直すのです。
すると、すべての通信がプロキシを経由するようになります。
プロキシはレスポンスヘッダーを観察します。
そして、現在の使用率を ~/.claude/usage-status.md のような単一ファイルに書き出すのです。
書き込まれる内容は、たとえば以下のように1行で表現されます。
5h=9% 7d=99%! overage=0% bottleneck=seven_day (10/05/2026, 16:19:04)
Claudeにこのファイルを参照させる方法は、2通りあります。
一つは、必要なときにモデル自身に読ませる方式。
もう一つは、UserPromptSubmit フックを設定して、毎回のプロンプトに自動で内容を注入する方式です。
CLAUDE.mdにルールを書いておけば、状況に応じてモデルの振る舞いを変えられます。
たとえば「90%を超えたら軽量モードに切り替える」といった指示が可能です。
あるいは「98%に達したら新規の実装作業を引き受けない」といった条件分岐も書けます。
公開されているコードは、Node.jsの標準ライブラリだけで書かれています。
npm依存はゼロとのことです。
WindowsではNSSM経由でサービス登録できます。
macOSとLinux向けには、launchdとsystemdの設定例がREADMEに用意されているそうです。
なお、この仕組みはClaude Code(CLI)でのみ動作します。
ウェブチャットやブラウザ拡張は、Anthropic側のインフラから直接APIを叩く構造です。
そのため、ローカルプロキシを挟む余地がありません。
副産物として見えてきた「統一プール」の真実
テスト中に分かったことが、もう一つあります。
これがコミュニティで議論を呼んだ大きなポイントでした。
投稿者は、OpusとSonnetのリクエスト両方を試しています。
そして、anthropic-ratelimit-* で始まるヘッダーをすべてダンプしてみました。
結果、モデル別のヘッダーは存在しなかったといいます。
つまり、すべてのモデルが一つの統一プールを共有しているということです。
Claude CodeのUI上ではSonnet用の別バーが見えています。
ただ、そのバーは実際の独立した制限を反映していません。
投稿によると、GitHubのissue #57050にこの経緯が触れられているそうです。
Anthropicは2025年11月に、Sonnet専用のバケットを設けると発表していました。
しかし、バックエンドの実装が間に合わなかったとのことです。
そのため、いまもSonnetを使うとOpusと同じプールから消費されてしまいます。
「Opusが枯れたからSonnetに切り替えれば長持ちするはず」という直感は、残念ながら正しくないようです。
コメント欄でも、関連する体験談が共有されていました。
「96%でSonnetだけに切り替えたら、すぐに99%警告が出た」というものです。
コミュニティで挙がった改善案
投稿のコメント欄には、すぐに技術的なフィードバックが集まりました。
最も票を集めたのは、フェイルクローズ設計についての指摘でした。
プロキシがファイルを書き込めない状態に陥ったとします。
すると、Claudeは古いデータを見て、「まだクォータに余裕がある」と判断してしまう恐れがあります。
これを防ぐには、ファイルにタイムスタンプを刻んでおきましょう。
そして、CLAUDE.md側で「60秒より古い情報は無視する」というルールを書いておくのが安全です。
別のコメントでは、より構造的なアーキテクチャが提案されていました。
フラットファイルではなくSQLiteに書き出し、MCPサーバー経由で参照するというものです。
同時実行時の競合を避けられます。
さらに、リクエストごとのトークンログが副産物として残るのです。
このログは、単なる現在の残量把握にとどまりません。
将来のコスト予測にもつながる素材になる、という指摘でした。
クロスプラットフォーム化を望む声もありました。
Dockerコンテナでまとめてしまえば、インストールが格段に楽になる、という意見です。
規約上の懸念は？
「これはAnthropicの利用規約に違反するのではないか」という懸念も挙がっていました。
サブスクリプションAPIへの第三者ツール接続を禁じる条項を指摘するコメントです。
投稿者は、実際にサポートに問い合わせたとのことです。
そして、回答を得たと報告しています。
要点はこうです。
プロキシはAPIコールを行わず、トラフィックを変更もしません。
中身を覗くだけのリスナーとして動作します。
WiresharkやSquidを流すのと変わらない、という位置づけです。
そのため、規約上は問題にならない、という説明だったといいます。
ANTHROPIC_BASE_URL は、もともと公開ドキュメントに記載されている変数です。
まさにこの種の用途のために用意されています。
禁止されているのは「Claudeを第三者ツール経由でユーザーに提供する」ような形態だそうです。
観測のためのプロキシは対象外、というのが投稿者の理解でした。
ただし、この解釈はあくまで投稿者とサポートのやりとりとして示されたものです。
導入を検討する読者は、自身でも最新の規約とドキュメントを確認したほうが安全でしょう。
そもそも標準機能で足りる、という声
このアプローチに対しては、冷静な反応もありました。
Claude Codeには、もともとstatuslineという機能が備わっています。
シェルスクリプトを settings.json に登録すれば、[CTX: 6%] [5h: 1% ~4h57m] [7d: 48% ~3d] のような形で残量を表示できます。
同じ値をフラットなテキストファイルに書き出す設定も可能です。
トラフィックを解析するより、こちらのほうがずっと手軽でしょう。
ただ、statuslineにも同じ制約があります。
新しいレスポンスを受け取るまで、値が更新されないという点です。
リアルタイム性という意味では、プロキシ方式と本質的に変わりません。
似た方向性のツールも紹介されていました。
一つは、Goで書かれたstatuslineプログラム。
もう一つは、–output-format stream-json –verbose を使ってトークン消費をJSONで取り出すアプローチです。
コンテキスト使用率が20%で警告、25%で強制停止、という閾値設計の例も挙がっていました。
「使用量を意識させる」ことの是非
一方で、こんな反対意見も出ています。
「モデルに自分の制限を意識させると、急いで作業を雑にこなすようになる」
確かに納得感のある指摘です。
残量が気になりだしたモデルを想像してください。
本来必要な徹底的なリファクタリングを省略し、表面的な修正だけで済ませてしまう。
そんな可能性は否定できません。
ただ、別のコメントでは逆の体験も語られていました。
予算という制約は、ジュニア開発者への「2日ではなく2時間で」という指示に似ています。
同じような効果が、Claudeにも出るのではないか、というのです。
実際、「20行で十分な場面で、400行のリファクタリングを書き始めてしまう」と困っていたユーザーもいました。
そのユーザーは、トークン効率を意識させる工夫を試したそうです。
すると、より絞った変更にフォーカスするようになったとのことでした。
どちらが正しいというより、目的とワークフローによって結果が変わるのでしょう。
複数AIを組み合わせた自動化スタックを動かしている人にとっては、有用な信号になります。
一方、単発のコーディング作業で品質を最優先したい人には、ノイズになる可能性もあります。
まとめ
Claude Code自身に使用量を意識させる、というアイデア。
技術的にはささやかな工夫です。
ANTHROPIC_BASE_URL を自分のプロキシに向け、レスポンスヘッダーをファイルに書き出し、CLAUDE.mdからそれを参照する。
流れだけ見れば、それほど大それたものではありません。
しかし、このシンプルな仕組みは、いくつかの興味深い問いを投げかけています。
UIに表示されている情報は、本当に必要な場所まで届いているのか。
モデル別のバーは、実際の独立した制限を反映しているのか。
そして何より、AIに自身の制約を伝えることは、賢い行動を引き出すのか。
それとも、雑な選択を促してしまうのか。
正解は一つではないはずです。
それでも、コミュニティは実装と数値でこの問いを検証しようとしています。
この動きは、Claude Codeを業務に組み込みたい人にとって、参考になる事例と言えるでしょう。
公開されたリポジトリ、競合する別アプローチ、そして冷静な反対意見。
これらが一つの議論の場にそろっていることが、何より価値のある情報源と感じます。
