Claudeの使用量がアイドル中に急増する原因と確認手順

Claude CodeやClaude Desktopをまったく操作していないのに、週次(Weekly)クォータとFableクォータが急に増えたという報告が2026年8月、GitHub Issueへ相次ぎました。Fableクォータとは、Claudeの最上位モデルであるFable系に割り当てられた、全モデル共通の週次クォータとは別枠の使用量上限です。Max 20xプランの利用者が中心で、アイドル中に0%から50%や100%へ跳ね上がったという内容でした。Anthropicはこの現象自体をクライアント側では再現できないと回答し、報告者の1人については後日、セッションが盗まれていたことが確認されています。両者は別の話であり、issue全体の原因が1つに絞り込まれたわけではありません。

Max 20xで相次いだ「アイドル中に0%→100%」報告

最初の報告は2026年8月3日、Max 20xプランの利用者によるものです。7月31日午後8時(米東部時間)の週次リセット直後、全モデルとFableのクォータはともに0%でした。翌8月1日昼に確認した時点でも0%のままで、アプリを閉じて操作していません。ところが8月2日夜に開き直すと、全モデルが50%、Fableが100%まで消費された状態になっていました。この間Fableは一度も呼び出していないと報告者は述べています。

同じissueには、似た現象を報告するコメントが複数付きました。

akshayramdassは、ローカルのMacを10秒間隔で監視した結果、該当時間帯に不審なプロセスやネットワーク通信は見られなかったと申告しています。本人の測定であり第三者による裏付けはありませんが、少なくとも複数のMax 20xアカウントが近い時期に同種の増加を報告した事実は残ります。

Anthropicの回答は「サーバー側の計算」だった

Anthropic側の担当者(コメント主bcherny)は8月17日、issueの経緯を確認したうえで回答しています。Claude Code v2.1.233でクライアント側の再現を試みたものの、テストする手段自体が無いという内容でした。週次・モデル別のクォータはAnthropicのサーバー側で計算・適用され、Claude Codeやデスクトップアプリは結果を表示しているだけだと説明しています。

ローカルで何かが動いてメーターを動かすことはできないため、アイドル中の増加はサーバー側のリクエスト履歴を見ない限り診断できないとも述べました。あわせて、このリポジトリ(Claude Code CLIの管理先)では原因の特定や修正ができないこと、各自が投稿したサポートの会話IDを軸に使用量制限チームへ引き継ぐ方針であることも伝えています。Claude Code CLIのセッション中にメッセージを送っていないのにメーターが動くのを見た場合は、CLIのバージョンとclaude doctorの出力を添えて報告するよう呼びかけました。

claude.ai・Claude Code・デスクトップは同じ使用量枠を共有する

Anthropicの公式サポートによると、claude.ai・Claude Code・Claude Desktopでの利用量は同じ使用量上限に合算されます。CLIしか使っていないつもりでも、同じアカウントでclaude.aiのブラウザセッションやデスクトップアプリが別途ログイン状態にあれば、そこでの消費も同じカウンターに反映されます。

このため「Claude Codeを一切開いていないのにクォータが減った」という体感だけでは、他の利用形態側で何かが動いていた可能性を排除できません。見覚えのないセッションを疑うときは、CLIだけでなくアクティブセッション一覧全体を確認する必要があります。

1件はセッション窃取(infostealer)が原因と確認された

報告者の1人nico-viewは、ほかの投稿者とは違う経過をたどりました。自分のアカウントで2回アイドル期間を測定したところ、どちらもクォータは動きませんでした。アプリを開いたまま2時間放置しても3つのカウンターはいずれも変化せず、マシンの電源を落とした一晩(約7時間)も~/.claude/projectsへのリクエストはゼロのまま、週次91%・Fable85%から動きませんでした。

代わりに見えたのは、メッセージを送った瞬間にカウンターが動くこと、しかもその上がり幅が送った内容に見合わないことでした。同じ日の朝の1通で使用率が33%から59%へ26ポイント跳ね上がった一方、その後8時間・1,366リクエストの作業では61%から76%へ15ポイントしか上がっていません。10倍近く働いて上昇幅は6割にとどまった計算です。

nico-viewは当初、サーバー側の反映が遅延しているという仮説を立てていました。しかし8月18日、Anthropicから直接メールが届きます。マルウェアに感染した自分のマシンから、Claudeのセッションが盗まれ、別人がそれを使ってクォータを消費していたという説明でした。Anthropicは盗まれたセッションを無効化し、上限をリセットし、余分に消費された分を返金したとしています。

nico-viewはこの結果を受けて、自分が立てた別issueを「誤った仮説」として閉じています。これはnico-view自身のケースで確認された原因であり、最初の報告者や他のコメント投稿者について同じ結論が出たとは、このissueのやり取りからは読み取れません。issueは2026年9月20日、動きが止まったままbotによって自動クローズされました。

自分のケースをどう切り分けるか

アイドル中にクォータが増えていた場合、まず切り分けたいのは「本当に何も送っていないか」と「増えたタイミングがいつか」です。

1. Claude Codeなら/usageでスキル・サブエージェント・MCPサーバーごとの消費内訳を確認し、自分が送った覚えのあるリクエストと突き合わせる(/usageコマンドで見る使用量の内訳も参照)
2. 増加が「アプリを開き直した瞬間」に見えているだけなのか、本当に何もしていない間に動いたのかを区別する。nico-viewの計測では、サーバー側の反映に遅延があり得ることも分かっています
3. claude.aiのアクティブセッションを開き、見覚えのない端末やロケーションが無いか確認する

/usage

見覚えのないセッションを見つけたときの対処

見覚えのない端末やロケーションのセッションが見つかった場合、該当セッションだけを個別に終了できます。claude.aiの設定からアカウント、アクティブセッションのセクションで対象を選び、三点メニューから終了操作を選ぶだけです。

疑わしい状況がはっきりしない場合は、全デバイスを一括でログアウトする手順で仕切り直す選択肢もあります。ログアウト後は再ログインが必要になるため、自分が普段使っている端末にも影響が及びます。

nico-viewのケースのようにマルウェア感染が疑われるなら、Vidar・Lumma・StealC・RedLine・Acreed・Atomic Stealerといった情報窃取型マルウェアのスキャンも合わせて行う選択肢があります。パスワードの変更も、Anthropicからのメールでは合わせて案内されていました。nico-viewの場合は超過分の使用量が自動で返金されていますが、同じ対応が全員に取られる保証はありません。心当たりのない消費が残っているなら、返金の有無も含めてサポートに個別で確認するのが安全です。

issueで報告されたケースの一部は、サポートへ問い合わせた後も長期間回答が付かなかったと記録されています。ある報告者は72時間経っても人からの返信が無かったと投稿していました。同じ現象に遭遇した場合は、発生した日時とアプリ・CLIのバージョン、そしてサポートの会話IDを添えて連絡すると、後からの相関調査がしやすくなります。

まとめ

Max 20xプランを中心に、アイドル中に週次・Fableクォータが急増したという報告は2026年8月に複数件出ました。Anthropicはクライアント側の不具合として再現できておらず、issueは9月20日に一次原因が確定しないまま自動クローズされています。確認できているのは、報告者の1人については盗まれたセッションが原因だったという1件だけです。

同じ現象に遭遇したら、まずアクティブセッションに見覚えのない端末が無いかを確認し、/usageの内訳表示と突き合わせるのが最初の一歩になります。似た「原因不明のまま経過した」報告としては、Opus 4.5の使用量上限が急に厳しくなった理由も参考になります。