ループエンジニアリングをProプランで実現したい。無理ゲーなのか?!

前の記事で触れた、
ループエンジニアリング体験したいけどClaude Code Proプランだとすぐ5時間制限で停止する…
についての緩和方法で試した仕組みをご紹介

Claude Codeが「5時間リミット」の手前で自分から止まるようになるまで

Claude Codeに/loopで長時間の連続実行を任せていたら、Proプランの5時間枠を使い切って、作業が中途半端なところでプツッと止まったことがある。それも一度や二度ではない。今回はそれをどう解決したかという話。

もし同じようにProプランをご利用の方には、たぶん共感してもらえると思う。たぶん。

何が困っていたか

Claude Code Proプランには、5時間のローリング利用枠がある。この枠を使い切ると、次の枠が開放されるまでエージェントは一切動けなくなる。

厄介なのは、当たり前ではあるが…この停止がエージェント側の都合を一切考慮してくれないことだ。

• 品質ゲート(テスト・Lint・静的解析)を回している途中
• 独立レビュアーの指摘にすり合わせている途中
• git commit前で作業ディレクトリが汚れている状態

こういうタイミングで枠を使い切ると、中途半端な状態がそのまま置き去りになる。特に「計画→実装→テスト→レビュー→修正」を自律ループで回す構成だと、/loopのような長時間・連続実行には非常に厳しい。

理想を言えば、上限に当たって強制終了するのではなく、上限が近いことに自分で気づいて、キリの良いところで安全に区切ってから待機してほしい。それを実現するために、手元にある2つの情報源を突き合わせながら、少しずつ運用ルールを固めていった。

情報源は2つあるが、どちらも単体では役に立たない

Claude Codeの利用状況を知る手段は、実質的に2つしかない。

情報源	取得方法	正確性	エージェントが自分で取得できるか
/usage	Claude Code内の対話コマンド	公式・正確	不可(人間が打つ必要がある)
ccusage	npx ccusage@<version> claude blocks --active --json	ローカルログからの近似値	可(BashやPowerShellから叩ける)

これが厄介で、正確な値を持っている/usageは人間しか見られず、逆にエージェントが自分で読めるccusageは正確とは限らない。どちらか一方だけでは、「エージェント自身がリミットの接近に気づいて自律的に止まる」という動きは作れない。そこで、両者を何度も突き合わせて、ccusageの値がどこまで信用できるのかを見極めるところから始めた。以下、それぞれの実際の出力を見ていく。

/usage ： 正確だけど、自分の目では見られない

/usageはClaude Code CLI内の対話コマンドで、結果はクライアントのUI上に表示されるだけだ。人間が対話的に打鍵しないと開けない画面なので、エージェントが自分でこの画面を開いたり中身を確認したりすることはできない。以下は実際の表示内容を書き起こして、メールアドレス・組織名・%・リセット時間をすべてマスキングしたものだ(架空の数値で、実測値ではない)。

見るべきところは3つある。
まずSession (5hr)、今まさに走っている5時間ローリングブロックの消費率とリセットまでの残り時間。今回ccusageと突き合わせて追いかけているのはこの値だ。
次にWeekly (7 day)、5時間枠とは別枠の週次利用枠で、これも見落とすと5時間枠より先に週次側が詰まっていた、ということが起こりうる。
最後にWhat's contributing to your limits usage?の内訳。長いコンテキスト、サブエージェントの多用、特定スキル(/dev-loopなど)の実行のうち、何が直近の消費を押し上げているかがここで分かる。

ccusage ： 近似値だけど、エージェントが自分で取ってこられる

一方ccusageはただのコマンドなので、エージェントが自分で叩いて実出力を確認できる。以下はnpx ccusage@20.0.17 claude blocks --active --jsonの実出力をベースに、コスト・トークン数・burn rate・remainingMinutesなどの数値をすべてダミー値に差し替えたものだ。
※バージョンを固定しているのはサプライチェーン攻撃対策です。適宜良いバージョンに読み替えてください。

ccusage-blocks-active.example.json

{
  "blocks": [
    {
      "id": "2026-07-25T22:00:00.000Z",
      "startTime": "2026-07-25T22:00:00.000Z",
      "endTime": "2026-07-26T03:00:00.000Z",
      "actualEndTime": "2026-07-26T01:00:00.000Z",
      "isActive": true,
      "isGap": false,
      "entries": 80,
      "models": ["claude-sonnet-4-6", "claude-opus-5", "claude-sonnet-5"],
      "tokenCounts": {
        "inputTokens": 2000,
        "outputTokens": 130000,
        "cacheCreationInputTokens": 400000,
        "cacheReadInputTokens": 13000000
      },
      "totalTokens": 13532000,
      "costUSD": 14.2,
      "burnRate": {
        "tokensPerMinute": 140000.0,
        "tokensPerMinuteForIndicator": 1350.0,
        "costPerHour": 8.4
      },
      "projection": {
        "remainingMinutes": 120,
        "totalTokens": 30332000,
        "totalCost": 31.0
      }
    }
  ]
}

isActive: trueになっている現在アクティブなブロックについて、そのブロックでの消費コスト(costUSD)や、このペースのまま進んだ場合の着地予測(projection)が取れる。ただしここには公式の%は一切含まれていない。だから「このコストやトークン数が、体感としてどのくらい危ないラインなのか」は、ハーネスの警告や実際に止まったタイミングと突き合わせながら自分で覚えていくしかなかった。

両方を見比べて分かったこと

セッションを重ねるたびに、次のようなタイミングで両方の値を見比べるようにした。

• ハーネスが利用枠の逼迫を警告してきたとき、ccusageのblocks --activeはどんな値だったか
• 実際に枠が切れて止まったとき、直前のccusageはどのくらいの値だったか
• 逆にccusageがかなり高い値を示していても、実はまだ枠に余裕があったケースはなかったか

これを繰り返して見えてきたのは、大きく2つのことだ。

1つ目は、ccusageは公式%とぴったり一致はしないが、傾向はちゃんと掴めるということ。ローカルログ由来の近似値なので、集計タイミングのズレやAPIリクエストの粒度の違いで多少ブレる。それでも「危険域に近づいている」という方向性は十分読み取れた。

2つ目は、100%ぴったりを狙うと手遅れになりやすいということ。ログの反映には多少の遅延があるし、大きめのツール呼び出しやサブエージェント起動が連続する場面ではブロック内の消費が一気に伸びる。ccusage側がまだ余裕を示していても、実際にはもう少し進んでいることがある。安全マージンを取らずにギリギリを攻めると、「気づいたら枠を使い切っていた」という事故になる。

この2点から、ccusageのblocks --activeが高水準(目安90%)に達したら、公式に100%と確定していなくても新規着手を止める、という閾値に落ち着いた。100%ではなく90%で切り上げるのは、正確な値ではなく傾向を追いかけている以上、むしろ自然な判断だったと思う。

運用ルール: ccusageのblocks --activeの消費が目安90%に達したら、公式に100%と確定していなくても新規着手を止める。
※タスク粒度によっては更に閾値を下げた方が良い場合もあり得ます。

CLAUDE.mdに落とし込む

ここまでの経験則を勘のまま持っておくのは気持ち悪いので、リポジトリのCLAUDE.mdに運用規約として書き下した。実際のセクションはこうなっている。

CLAUDE.md

## 稼働制限(Pro プラン・5時間枠)

- Pro プランには5時間のローリング利用枠があり、超過すると次回開放まで停止する。上限で作業を不用意に打ち切らない。
- 利用枠の逼迫を認識したら(ハーネスの上限警告、または `npx ccusage@20.0.17 claude blocks --active --json` で確認したアクティブな5時間ブロックの消費が**高水準=目安90%**)、新規の着手を止め、進行中の成果を安全な区切りでコミット等により保全し、**次回リミット開放まで待機**する。
- 長時間の連続作業・`/loop` 実行時は、区切り(目安10分)ごとに利用状況を意識する。`/loop` 実行時は ScheduleWakeup のセルフペーシングで近似する。
- 補足(実装上の制約): 利用量は `ccusage`(ローカルログからの**近似**。公式の Pro 5時間枠とは一致しない)でオンデマンド取得できるが、公式%そのものを読む手段は無い(`/usage` はユーザー操作)。また「10分毎の自動確認・自動待機」を自走させる時間トリガは通常セッションに無く、`/loop` の ScheduleWakeup でのみ近似できる。本ルールはハーネスの警告・`ccusage`・`/usage`・ユーザーの合図を signal とした運用規約として扱う。

やっていることは、検知・保全・待機の3段階に集約できる。
ハーネスの警告かccusageの消費率で逼迫に気づき、新規タスクの着手を止めて進行中の成果をコミットなどで安全な区切りに保全し、次回のリミット開放を待つ。打ち切りではなく一時停止、というのがポイントだ。

冒頭に「上限で作業を不用意に打ち切らない」という一文をわざわざ置いたのは、意図的にそうした。枠が近いからと焦って雑にタスクを畳んでしまうと、テストが壊れたままのコードやレビュー未了の変更がコミットされるリスクの方が高い。それよりは、多少ギリギリでもキリの良い区切りまで正常に進めてから止まる方を優先している。

「10分ごとに自分でチェックさせる」が簡単ではない

Claude Codeの通常セッションには、「10分おきに自動で何かを確認する」ような時間ベースのトリガーが存在しない。エージェントは基本的に、ユーザーからの入力やツール実行の合間にしか「今、何か判断する」機会を持てない。

これを擬似的に実現しているのが、/loop実行時のScheduleWakeupだ。/loopのダイナミックモードでは、次に処理を再開するタイミングを自分で予約できる。長時間の連続タスクを回している間、区切り(目安10分)ごとに一度目を覚ましてccusageの値を確認し、高水準なら保全して停止、そうでなければ次のチェックポイントを再度予約する。これでセルフペーシングを近似している。

ただしこれはあくまで/loopという仕組みに乗っかった近似であって、通常の対話セッションでは使えない。通常セッションでは結局のところ、ハーネスの上限警告・ユーザーからの合図・タスクの区切りといった、こちらから能動的に取りにいけないシグナルに頼らざるを得ない。CLAUDE.mdの補足で「本ルールはハーネスの警告・ccusage・/usage・ユーザーの合図をsignalとした運用規約として扱う」とわざわざ書いたのは、この限界を認めた上でも実用上は機能するところまで落とし込んだ、という意味だ。

まとめ

Claude Codeの5時間リミットには、公式の正確な値(/usage)は人間しか読めず、エージェントが自律的に読める値(ccusage)は近似でしかない。

この2つを実運用の中で何度も突き合わせることで、
「ccusageの消費率が高水準(目安90%)に近づいたら危険域」という実務上の閾値を学習できた。
学んだことは勘のままにせず、CLAUDE.mdに「検知→保全→待機」の3段階ルールとして書き下し、チーム(というか自分自身)が再現できる規約にした。
「10分ごとの自動チェック」は通常セッションにネイティブな仕組みがないため、/loopのScheduleWakeupで近似しているが、これもあくまで近似で、公式%を直接読む手段が無いという制約自体は残っている。

AIエージェントに長時間・自律的な作業を任せるほど、こうした「エージェント自身にリソース制約を意識させる」運用設計は避けて通れなくなる。
公式の正確な情報源とエージェントが自力で取得できる近似情報源を突き合わせて経験則を作り、それをルールとして明文化しておくやり方は、他のプラットフォームのレート制限やクォータ管理にも応用できるはず。