claude -pが5時間枠を対話の約1.8倍消費する報告 — 計測の切り分け方
claude -p(entrypoint sdk-cli)が同じ作業で対話より5時間枠を多く使うという報告が、GitHub issueで複数アカウントから出ています。数値の読み方と自分の環境での測り方をまとめます。
claude -pは対話より5時間枠を多く使うのか
サブスクリプションでclaude -pを回すと、同じトークン量でも対話モードより5時間枠の減りが速い。anthropics/claude-codeのissue #97074(open)には、そう読める計測が複数のアカウントから集まっています。
報告者の最初のA/Bテスト(Maxプラン、Claude Code 2.1.282、Opus 5、effort high)では、ほぼ同額のAPI換算コストで枠の減りが倍近く違いました。
| 実行方法 | API換算コスト | 5時間枠の使用率 | 枠1%あたりの金額 |
|---|---|---|---|
ヘッドレス(sdk-cli) | API換算コスト$12.74 | 5時間枠の使用率52%から60% | 枠1%あたりの金額約$1.6 |
対話(cli) | API換算コスト$12.91 | 5時間枠の使用率60%から65% | 枠1%あたりの金額約$3.0 |
同じ$1.6〜$3.0の差を、報告者は「ヘッドレスの方が約1.8倍速く枠を使う」と読んでいます。使用率は1%刻みでしか読めないため、範囲は重なりません(1.5〜1.9対2.4〜3.9)。
先に注意点を挙げます。これはissueの報告であり、Anthropicからの公式な回答は同issueには載っていません。意図した重み付けなのか計測側の不具合なのかは分かっていません。
報告された数字を並べると何が見えるか
issueには複数の報告者が別々の方法で測った結果が付いています。条件が違うので倍率をそのまま平均しない方が安全です。
| 報告者 | 比較対象 | 倍率の目安 | 条件 |
|---|---|---|---|
| 最初の報告 | 比較対象sdk-cli対cli | 倍率の目安約1.8倍 | 条件固定プロンプト41ターン、Opus 5 |
| 別アカウント(Pro) | 比較対象sdk-cli対cli | 倍率の目安約2.0倍(1.8〜2.2) | 条件31ターン、Opus 5.5 effort low |
| 別アカウント(Max 5x) | 比較対象sdk-ts・sdk-cli対cli・claude-desktop | 倍率の目安約2.4倍(1.9〜3) | 条件2回の測定、Opus 5.5 medium |
| 別アカウント(Team) | 比較対象sdk-ts・sdk-cli対claude-vscode | 倍率の目安約2.8〜3.0倍 | 条件3ブロックずつ、Opus 5.5 high |
| 受動データ(Mac) | 比較対象sdk-cli対claude-desktop | 倍率の目安約1.3倍 | 条件管理されたA/Bではなく17日分のログ |
方向はそろっていますが、大きさは1.3倍から約3倍まで開いています。受動データの報告者自身が、ヘッドレス側はサブエージェントを使う自動承認のオーケストレーターが中心で、作業の中身が違うと断っています。
もう一つ、T3 Codeを運営する報告者は、claude -pとAgent SDK(sdk-ts)が対話より1.6〜1.7倍速く5時間枠を使ったと書いています。同じ報告で、週次上限の減り方は実行方法によらず同じだったとされています。一方、別のコメントにはclaude -pを約$120分回して週次上限が約10%減ったという体感の報告もあり、週次への影響は報告の間で食い違っています。
ヘッドレスと対話の差ではなく、ラベルの差かもしれない
「ヘッドレスだから重い」という読みを揺らす報告があります。TeamプランでのA/Bを公開した報告者によると、VS Code拡張も内部では--output-format stream-json --input-format stream-jsonのヘッドレス起動で、違いはCLAUDE_CODE_ENTRYPOINTがclaude-vscodeになる点だけです。そのclaude-vscodeは、sdk-ts(Agent SDKアプリ)とsdk-cli(claude -p)より約2.8〜3倍長く枠が持ちました。
この報告者のコード調査では、CLI 2.1.301でsdk-ts・sdk-cli・sdk-pyは同じクライアント区分(claude_code_sdk)に、claude-vscodeは別区分に対応づけられます。生のラベルは、リクエストごとにx-anthropic-billing-headerブロックのcc_entrypointとして送られます。
つまり論点は「非対話かどうか」ではなく「どのエントリポイントとして自分を名乗るか」にある、という仮説です。別の報告者は、対話でもCLAUDE_CODE_ENTRYPOINT=sdk-cliが環境に残っていると記録がsdk-cliになり、2つの実行が同じだけ枠を動かしたと書いています。仮説に沿う結果ですが、差は各2ポイントと小さく、報告者自身も弱い対照と述べています。
これらはどれも外から測った推定です。サーバー側の課金ロジックは見えないため、重み付けの有無と理由は公式の説明を待つ領域です。
自分の環境で測るには
結論から言うと、使用率の読み取りはrate_limit_eventが最も細かいと報告されています。/usageやget_usageは約1分ごとにしか更新されず、長く動くCLIプロセスではさらにキャッシュが挟まるため、差を測ると最大1分分の使用が別の実行に混ざる、という指摘です。
ヘッドレス側は、stream-jsonの出力に含まれる次の値を読みます。
rate_limit_event.rate_limit_info.unifiedWindows.five_hour.utilization実行の前後には、軽量モデルで空に近い呼び出しを1回入れて同じ方法で使用率を読みます。報告者が使っているプローブは次の形です。
claude -p --model claude-haiku-4-5 \
--output-format stream-json --verbose "reply: ok"対話側は、statuslineに渡されるJSONのrate_limits.five_hour.used_percentageから読み、ターンの終わりはStopフックで検知する、という手順が報告されています。statuslineのused_percentageとstream-jsonのutilizationは、どちらも同じ5時間枠の使用率なので、前後の値をそのまま並べて比べられます。なお前後のプローブ自体も枠をわずかに使うため、その分は差分から差し引きます。
測定で外せない条件は次のとおりです。
測定の条件をそろえる
- 同じ作業内容・同じモデル・同じeffortで、新しいセッションから始める
- アカウントで同時に動いている他の実行(別マシンを含む)を止めるか、差し引く
- トークンはセッションのトランスクリプトから、メッセージIDとリクエストIDで重複を除いて数える
- 対話側を起動するシェルに
CLAUDE_CODE_ENTRYPOINT=sdk-cliが残っていないか確かめる - 使用率は1%刻みなので、動かす幅を数ポイント以上にして誤差を相対的に小さくする
トランスクリプトのentrypointの値で、その実行がどのラベルで記録されたかを突き合わせられます。tmuxサーバーがSDK起動のセッションから環境変数を引き継ぎ、対話のつもりの実行がsdk-cliで記録された例が報告されています。
トランスクリプトからトークンを数えるときの落とし穴
報告者たちは枠の減りを「トークン量あたり」で比べるため、セッションのトランスクリプト(JSONL)からトークンを集計しています。集計で外せないのは重複の除去です。最初の報告者は、message.usageをメッセージIDとリクエストIDの組で重複を除いて数えたと書いています。同じ応答の使用量が複数行に記録されていると、単純に全行を足すと過大になるためです。
形としては次のような集計になります。フィールド名はissueの記述に沿った例で、手元のバージョンでトランスクリプトの構造が同じかは、先に1行を開いて確かめてから使います。
cat session.jsonl | jq -s '
[ .[] | select(.message.usage != null)
| {k: "\(.message.id)|\(.requestId)", u: .message.usage} ]
| unique_by(.k)
| map(.u.input_tokens + .u.output_tokens) | add'この例は入力と出力だけを足しています。キャッシュの読み取りと書き込みは単価が違うため、枠への効き方を比べるなら種類ごとに分けて、API価格表の比率で重み付けします。報告のいくつかが「API換算コスト」や「重み付きトークン」で比べているのはこのためです。
サブエージェントのトランスクリプトは、セッションのsubagents/ディレクトリ以下に別ファイルとして置かれます。最初の報告者は、過去分の集計にはそれを含め、A/Bテストではサブエージェントを使っていないと書いています。サブエージェントを多用するワークロードを比べるときは、ここを含めるかで結果が変わります。
自分の症状はどの報告に近いか
issueのコメントから、読者の状況ごとの見当を付けておきます。
| 状況 | 近い報告 | 先にやること |
|---|---|---|
対話からclaude -pの自動化に移したら上限に当たりやすくなった | 近い報告最初の報告、Proの再現 | 先にやること同じ作業を対話で1回測り、前後の使用率を比べる |
| Agent SDKアプリ(サードパーティ含む)経由で枠が早く尽きる | 近い報告Max 5xとTeamの報告、T3 Code | 先にやることトランスクリプトのentrypointがsdk-tsか確かめる |
| VS Code拡張では問題ない | 近い報告Teamの報告(claude-vscodeが基準) | 先にやること同じ作業をclaude -pで測って差を見る |
| 週次上限まで減った | 近い報告食い違う2つの報告 | 先にやること5時間枠と週次の使用率を別々に前後で記録する |
受動データの約1.3倍は、ヘッドレス側と対話側で作業の中身が違うため、管理されたA/Bの約1.8倍以上と同じ物差しでは扱えません。自分の数字がどちらに近いかは、作業をそろえて測ったかどうかで分かれます。
どの行でも、数値が出るまでは「同じ作業」「同じモデル」「他の実行なし」の3条件が前提です。
他の原因を除いた確認項目
最初の報告者は、差の原因になりそうな点を先に潰しています。
- 自動承認の分類器ではない: 両方で
--dangerously-skip-permissionsを使い、41ターン中40ターンはツール呼び出しなし - ヘッドレス側のハーネスが大きいわけではない: 最初のリクエストは対話より小さい(中央値で約66K対約88Kの入力トークン、2.1.267)
- 記録漏れではない:
result.total_cost_usdはトランスクリプトの合計と一致 - 隠れたリクエストや再試行ではない: ローカルのログ用プロキシで、ヘッドレスの
/v1/messages呼び出しはすべてトランスクリプトにあり、429や529もなし
プロキシ計測で目立つのは、トークンの種類ごとに見てもヘッドレスの方が少ないのに、枠は多く減った点です。ワイヤー上の違いは、cc_entrypointの値とUser-Agent、それに対話クライアントだけが送るredact-thinking-2026-02-12ベータでした。
運用で何を変えられるか
原因が公式に確定していない以上、確実に効く回避策は示せません。報告と公式の記述から言えることは次のとおりです。
- サブスクリプションの枠で自動化を回している場合、5時間枠の消費は対話実行の見積もりより速い可能性がある。計画を立てるときは、自分の環境で前後の使用率を測った実測値を使う
- 公式のヘルプ記事によると、MaxとTeamのプランには2026年10月7日から月次のAPIクレジットがあり、Claude Agent SDK、
claude -p、Claude API、Claude Managed Agentsに使えます。サブスクリプションの上限でも引き続き使えます --bareは認証にOAuthを読まず、APIキーが必要です。サブスクリプションの枠を使う経路とは別になるため、同じ比較にはなりません(claude -pオプションの解説)
使用量の内訳を見る手段としては、/usageのLoops内訳があります(Claude Codeの/usageでLoopの内訳から消費トークンを特定する)。対話側でトークンが増える原因はClaude Opus 4.8でトークンが増える理由に別の切り口があります。使用量の上限に当たったときの待ち方は使用量上限を再確認する間隔に設定があります。
まとめ
claude -pの5時間枠消費が対話より多いという報告は、独立した複数のアカウントで同じ方向に出ています。ただし倍率は1.3倍から約3倍まで幅があり、原因は公式に説明されていません。エントリポイントのラベルが効いているという仮説が、今のところ最も多くの測定と整合しています。自動化を回す側にとっては、見積もりを対話実行の延長で立てず、前後の使用率を自分で測っておくのが現実的です。