Claude Codeの/usageでLoopの内訳から消費トークンを特定する

このTipsでできること

/usage のLoops欄を読むと、/loop や他の定期タスクのうちどれがトークンを消費しているかを、タスクごとに特定できます。バックグラウンドで動く定期タスクは気づかないうちにトークンを積み上げるので、犯人を1つずつ探すより先に、この内訳を見るのが近道です。

Loopsの内訳を表示する手順

Claude Codeのセッション内で /usage を実行します。

/usage

Pro・Max・Team・Enterpriseのいずれかのプランなら、/usage の下部に「Plan usage breakdown」が表示され、その中にLoopsの行が並びます。Loopsを含むPlan usage breakdownは、これらのプランの内訳です。

画面上で d を押すと直近24時間、w を押すと直近7日間に切り替わります。数値はこのマシン上のローカルなセッション履歴から計算した近似値で、別デバイスやclaude.aiでの利用は含まれません。

Loopsの行が示す5つの値

Loopsの各行は、直近に動いた /loop や定期タスクのうち消費トークンが大きいものから並び、その他は件数だけがまとめて表示されます。

行を特定するキーはタスクのプロンプト文字列です。同じ /loop を一度止めてから同じ文面で再作成しても、Claude Codeは同一の行として扱います。逆に言うと、プロンプトの文面が変わると別行に分かれます。同じ目的の/loopを試行錯誤で何度も書き直していると、行が枝分かれして合計が見えにくくなります。

この機能はClaude Code v2.1.242以降で使えます(公式ドキュメントの表記どおりで、changelogでは同じ変更が2026年8月25日付のv2.1.243のエントリに記載されています)。

例: 行が示す形

実際の数値はタスクごとに異なりますが、Loopsの1行は仮の値で書くとおおよそ次のような形になります(公式ドキュメントが示す構造に沿った例示で、実出力そのものではありません)。

この形で見ると、1回あたりトークンが他のタスクより大きければ「そのタスクの会話が長く育っている」ことが読み取れます。一方で、発火頻度に対して実行回数が少ないからといって「セッションが閉じていた間の分をまとめて実行した」とは読めません。公式ドキュメントによれば、定期タスクに取りこぼしの救済はなく、予定時刻を過ぎてもClaude Codeが長い応答の途中でbusyだった場合は、アイドルに戻った時点で1回だけ発火します。逃した回数分をまとめて実行する挙動はありません。行に並ばなかった残りのタスクは件数だけが表示されるので、行数が多いほど/loopや定期タスクを併走させているという目安にもなります。

なぜ1回あたりトークンが膨らみやすいか

定期タスクは、セッションが待機中でも設定した間隔ごとに呼び出され、そのたびに会話の文脈が送信に乗ります。/loopを仕込んだセッションで別の作業も並行して続けていると、そのセッションの会話量がそのまま毎回の送信量に乗るため、1回あたりトークンは会話が長くなるほど増えていきます。プロンプトキャッシュが効くので、送信のたびにゼロから処理し直すわけではありません。ただし有効期間を過ぎてからの初回送信はキャッシュミスになります。会話の履歴全体を再処理するぶん、トークン消費が跳ね上がります。メインの会話での有効期間は、サブスクリプションなら1時間、使用量クレジットを使っている間は5分です。

Loopsの行が増えない・消える・遅れるとき

行の数字が想定とずれるときは、バグを疑う前に定期タスク側の仕様を見ます。

行が突然見えなくなったら、まず作成から7日たっていないかを疑います。長く回したい繰り返しタスクは、期限前に作り直すか、クラウドのRoutinesやデスクトップの定期タスクに移す選択肢があります。--resume や --continue で再開したときも、期限切れの繰り返しタスクと予定時刻を過ぎた単発タスクは復元されません。自走型の/loopも復元されないので、再開後は/loopを実行し直します。

実行回数が間隔の計算より少ないときは、発火のずれと取りこぼしなしの仕様が重なっています。タスクIDから決まる固定のずれが毎回乗り、Claude Codeが応答中なら応答が終わるまで待ちます。ターミナルを閉じたりセッションを終えたりした間は発火せず、バックグラウンドセッションに移せばターミナルなしで動き続けます。

自走型の/loopでは、反復が次回の予約も停止もしないまま終わると、約20分後にフォールバックで起動します。それでも予約も停止もなければループは終了するので、行が増えずに消えたように見えることがあります。

VS Code拡張では見えない

VS Code拡張のAccount & usageダイアログにも、Attribution(skills・subagents・plugins・MCPサーバーへの帰属)とBehavior flags(長文脈・キャッシュミスなどの割合)はDay/Weekの切り替え付きで表示されますが、Loopsの行だけは出ません。定期タスクの消費を確認したいときは、CLI側の/usageを開く必要があります。

Attributionの内訳との役割分担

/usage のPlan usage breakdownには、Loops以外にAttributionという欄もあります。これはskills・subagents・plugins・個別のMCPサーバーへの消費の帰属を、それぞれ全体に対する割合で示すものです。MCPサーバーの割合は、そのサーバーのツール結果を実際に使ったリクエストだけを数えます(v2.1.222より前は、一度呼んだMCPサーバーにその後の全リクエストを帰属させてしまい、割合を実態より大きく見せていました)。

Attributionは「どの仕組みが消費しているか」を横断的に見る欄で、Loopsは「どの/loopタスクが消費しているか」をタスク単位で掘り下げる欄です。/loop自体が全体のどれくらいを占めるかはAttribution側の割合で把握し、その中身をLoopsの行で個別に特定する、という順番で読むと切り分けやすくなります。

同じPlan usage breakdownには、長文脈やキャッシュミスといった振る舞いが直近利用の10%以上を占めたときだけ表示される「Behavior flags」欄もあります。会話が長いセッションに/loopを仕込んでいる場合、その/loopの消費が積み上がって「長文脈」のフラグを押し上げていることがあるので、Behavior flagsで長文脈が立っているときはLoopsの1回あたりトークンも合わせて確認する価値があります。

Claude Codeのその他の消費内訳(セッション全体のコストやモデル別の使用量)を読む手順はClaude Codeの/usageコマンドで見る使用量の内訳にまとめています。Loopsはこの記事にはない、定期タスク単位の内訳です。フッターのfキーで推奨を適用する手順は/usageのfキーの解説にあります。

/insightsは別のツール

/loopの消費を確認したいとき、パターン分析の/insightsと混同しないよう注意します。/insightsはこのマシン上の直近セッションを分析し、何に時間を使ったか・つまずいた点・改善提案をHTMLレポートにまとめるコマンドで、1回の実行で未分析の最大200セッションを対象にします。トークンの生の数字を/loop単位で並べるLoopsとは違い、/insightsは使い方そのものを振り返るための報告書です。Loopsで消費の大きいタスクを特定してから、そのタスクの使い方を見直したいときに/insightsを補助的に使う、という順番になります。

Stopフックのsession_cronsとは同じ管理対象

Loopsが集計している定期タスクは、内部的にはCronCreate・ScheduleWakeup・/loopが管理する予定済みの再起動(スケジュールされたウェイクアップ)です。この同じ一覧は、Stopフックの入力にあるsession_cronsフィールドとしても渡され、フック側からタスクIDやcron式、プロンプト文字列を直接読み取れます。/usageを都度開かずに、フックから「今どのタスクが待機中か」を自動判定したい場合は、このsession_cronsを読む実装が使えます。

トークンを食っているLoopを見つけたときの対処

Loopsの行で1回あたりトークンや合計が突出しているタスクが見つかったら、まず止め方を、種類で選びます。

そのほかの対処は次の3つです。

1. 専用の軽いセッションに分ける: 他の作業をしている会話の長いセッションに/loopを仕込むと、毎回の送信にその会話全体が乗ります。定期タスク専用の短いセッションに分けるほうが1回あたりのトークンは小さくなります。
2. サブエージェントならモデルを下げる: そのタスクをサブエージェントに切り出しているなら、サブエージェントの設定でmodel: haikuを指定すると、単純な確認作業ほどトークン単価を下げられます。
3. 全体を止める: 環境変数CLAUDE_CODE_DISABLE_CRONを1に設定すると、/loopスキルとcron系のツールが使えなくなり、実行中のタスクを含めてすべての定期タスクが止まります。個別のタスクではなく定期タスクの仕組みごと止めたいときに使います。

/loopの消費が気になったきっかけがセッション全体のトークン消費の急増であれば、Claude Codeのトークン消費が異常に速いときの原因の切り分け方で他の原因(長文脈化・キャッシュミス・サブエージェントなど)と合わせて切り分けられます。1リクエスト単位の内訳まで見たいときはClaude Codeのcurrent_usageで直近リクエストの内訳を読むが対応します。チームで動かす自動化タスクの消費を組織側で管理したい場合はAgent Teamsのコスト管理 — トークン消費を抑える設定も参考になります。

まとめ

Loops欄は、突出した定期タスクを1行で名指しできる、CLIの /usage だけにある内訳です。数字が想定とずれたら、7日の期限・発火のずれ・/loop の種類による止め方の違いを先に当たると、原因を切り分けやすくなります。