先日、同僚の @inoyu-qiita さんに、記事でいじられました。
「お前がみろ」このプロンプトを書いたのは、同僚の @Shinn_Matsumoto さんです。
— 「お前がみろ」はAIに効くのか。高圧的なプロンプトで回答精度を検証した
はい、私です。ありがとうございます。せっかくなので乗っかります。怒られ続けた Claude から、別のものが出てきた話です。
Claude Code の Opus には5時間枠と7日枠があるじゃないですか。私、あれに毎日引っかかってます。
どのくらい使ってるのか、手元のセッションログを全部集計してみました。直近30日（2026年8月12日〜9月10日）で132.7億トークン、APIの定価で換算すると $11,536 でした。1日あたり $384 です。
サブスクなので実際にこの額を請求されているわけではありません。ただ、Claude Code 自身も同じやり方で金額を出しています。
Claude Code computes the dollar figure locally from token counts at list price
（Manage costs effectively - Claude Docs）
で、その公式ドキュメントの同じページに、こう書いてあるんですよね。
Across enterprise deployments, the average cost is around $13 per developer per active day and $150-250 per developer per month, with costs remaining below $30 per active day for 90% of users.
平均が1日$13。90%の人は1日$30未満。私は1日$384なので、平均の約30倍、90%ラインの約13倍です。月額で見ると目安の46〜77倍でした。
みなさんどのくらい使ってるんでしょうか。多いのか、単に下手なだけなのか、正直よく分かってません。使用量の確認方法は公式にも書いてあるので、気になる方はどうぞ。
で、これだけ使ってると毎日枠に引っかかるわけです。引っかかるたびに Claude に当たってきました。その記録がセッションログに全部残っていて、読み返したら、1ヶ月ぶんの八つ当たりがそのまま仕様書になっていました。いまは Claude が作業前に自分のトークン消費を見積もって、上限を超えそうなら着手を拒否してきます。
会話の引用はすべてセッションログの実物です。読めないところだけ句読点を足して、音声入力の誤変換を直しました（面白いやつは残してあります）。口調はそのままです。
何にそんなに使ってるのか
自分でも気になったので、30日ぶんのログを割ってみました。
まずトークンの種別です。ここが一番びっくりしました。
| 種別 | トークン | 割合 |
|---|---|---|
| キャッシュ読み込み | 129.4億 | 97.5% |
| キャッシュ書き込み | 2.8億 | 2.1% |
| 出力 | 0.5億 | 0.4% |
| 入力 | 0.01億 | 0.01% |
え、97.5%が「過去のやりとりの読み直し」でした。私が打ち込んだ入力は0.01%しかありません。
公式ドキュメントに理由が書いてありました。
Claude Code sends your full conversation with every request（…）a one-line question in a session that has been open all day still draws usage for the whole conversation
長く開いたセッションでは、一行の質問をするだけでも会話全体を読み直します。プロンプトキャッシュが効いているぶん単価は安いんですが、量が量です。私の使用量は、私が何を書いたかではなく、私がセッションを閉じないことで決まっていました。
プロジェクト別（推計$）
| 推計$ | トークン | プロジェクト |
|---|---|---|
| $3,251 | 40.5億 | 記事自動化ツール（案件A） |
| $2,855 | 34.4億 | 記事自動化ツール（案件B） |
| $1,486 | 11.7億 | Next.js/Supabase のPWA |
| $1,183 | 13.9億 | プロジェクト外の雑作業 |
| $929 | 10.1億 | ハッカソン用アプリ |
| $873 | 10.0億 | ECサイト |
| $539 | 7.5億 | 動画配信サービス |
上位2つで$6,106、全体の53%です。どっちも「記事を書かせるツール」でした。記事を書かせるために、記事を書かせるツールを作っていて、いまその話を記事に書いています。
モデル別（推計$）
| 推計$ | モデル |
|---|---|
| $9,141（79%） | Opus 5 |
| $2,116 | Fable 5 |
| $237 | Fable 5.1 |
| $43 | その他（Sonnet・Haiku・旧Opus） |
公式ドキュメントにはこう書いてあります。
Sonnet handles most coding tasks well and costs less than Opus. Reserve Opus for complex architectural decisions or multi-step reasoning.
「複雑な設計判断のために取っておけ」と言われているものを、ほぼ全部に使ってます。ここは自分でも直しどころだと思ってます。
メイン vs サブエージェント
| 推計$ | トークン | 件数 | |
|---|---|---|---|
| メインの会話 | $10,109（87.6%） | 120.2億 | 49,827 |
| サブエージェント | $1,430（12.4%） | 12.5億 | 14,320 |
これが一番意外でした。サブエージェントは件数では全体の22%あるのに、コストでは12%しかありません。
でもこれ、「サブエージェントは軽い」という話ではないんですよね。サブエージェントのコストは、サブエージェントの欄には出てこないんです。走っている間のトークンはサブの側に計上されますが、帰ってきた報告を受け取ったあとのコストは全部メイン側に乗ります。しかも一度乗ったら、そのセッションが終わるまで毎回運ばれます。上のキャッシュ読み込み97.5%の中に混ざっているわけです。
この話は後半でもう一度出てきます。
（金額はすべてAPIの定価から自分で計算した推計です。入力$5/出力$25/キャッシュ書き込み$10/キャッシュ読み込み$0.50 per 1M トークン（Opus 5、1時間TTL）で計算しました。）
最初は「表示すれば解決する」と思ってました
2026年8月21日。サブエージェントを大量に起動して全滅させた直後でした。成果ゼロの失敗にセッション入力の42%を食われています。
どんぐらい圧迫する？、なんかこの作業をすると何％圧迫するとか毎回表示する方法ないの
このとき欲しかったのは表示でした。数字が見えれば自分で判断できる、と思ってたんですよね。これが間違いだと気づくまで、あと5日かかります。
Claude はステータスラインに増分表示を組み込みました。▶ レポート執筆 ~30分 [5h+5 7d+3] | … | 5h:38%(+18)>01:00 みたいな表示です。
表示を直すと、別のところが消える
4日後。
「5hのトークン消費量が見切れるんだけど」「横長すぎて」。情報を詰め込みすぎて、肝心の5時間枠が画面から見切れていました。Claude は「切られてよい側」を右端に回して直します。その翌朝。
> え、なんかステータスラインからディレクトリの名前とか消えちゃっていて、どこで作業してん
のか全然わかんなくなってんだけどお前何かした？（…）お前が誰かわかんないよ。
● はい、私がやりました。前の指示（「5hが見切れる／横長すぎて」）に対して、ディレクトリ
を「切られてよい側」＝右端に回したのが原因です。判断を誤りました。
ステータスラインって横幅が有限なので、何かを足すと何かが消えるんですよね。表示で解決しようとしている限り、この綱引きは終わりません。
欲しかったのは表示じゃなくて判断でした
同じ日の昼、作業計画を出させていたときにこう言っています。
> 脳漿のあのさぁ、今はFableなので、Opusに切り替えて2番を行えば何%の圧迫で済みますとか、
そこまで提案してくれないとやれって言えないよ。止まっちゃったらどうすんだよ。
（…）なんかチグハグだな。
「脳漿の」は「Notionの」です。音声入力がやりました。それはいいとして、重要なのは後半でした。
「止まっちゃったらどうすんだよ」 ——これが仕様だったんです。
欲しかったのは現在値の表示じゃなくて、これから始める作業が枠に収まるかどうかの判断でした。数字を見せられても、その数字が「この作業で何%増えるか」を含んでいなければ、判断材料にならないんですよね。
Claude の返答はこうなりました。
数字を出します。今の残り枠は 5時間枠 32%使用、7日枠 35%使用（…）④ デモを実装する｜Opus｜+25〜35%｜Fableだと+87%で止まる
これが原型です。ここから「+25〜35%」をどう出すかという問題が始まります。
あと、この直前にこんなことも言ってました。
> でもさぁ、君この作業すると100%超えちゃうから作業内容切り替えますとか言ってさぁ、（…）
まじでそういう挙動してますか？やってるとしたら凄くない？聞いた記事にしたらバズる、聞い
た、聞いた？
末尾の「聞いた」は、音声入力が 「Qiita」 を取り違えたものです。つまり「Qiita記事にしたらバズる、Qiita、Qiita？」と言ってます。この伏線は最後に回収します。
で、どうやって見積もるか
ここからは仕組みの話です。全体はこう回っています。
claude_task.sh という200行くらいのシェルスクリプトを CLAUDE.md に登録しておいて、Claude 自身が作業前に叩きます。
$ CC_SID=<セッションID> claude_task.sh "作業内容" <見込み分数> --turns 22 --agents 0
task set: Qiita記事の執筆と投稿 (40分, やりとり22回[指定], agents=0)
見込み: $2.79 → 7d+0.4% / 5h+3%
悪い側: $3.4 → 7d+0.4% / 5h+4% （実測の上振れ ×1.24。判定はこちらで行う）
現在 : 7d 86% / 5h 71% → 残り 7d 14% / 5h 29%
着手後: 7d 86.4% / 5h 74%
判定 : 上限に近づく（85%超）。着手前にユーザーへ確認すること
判定は4段階あります。
| 判定 | 意味 | Claude がやること |
|---|---|---|
| 余裕あり | 着手後も85%未満 | そのまま進める |
| 上限に近づく（85%超） | 着手後85〜99% | 着手前に数字を見せて確認する |
| 上限を超える見込み | 着手後100%以上 | 着手しない。分割するか本数を減らして出し直す |
| 判定不能 | %換算率が未取得 | $の見込みだけ見せる |
ちなみに「現在 7d 86%」という今の使用率は、ステータスラインからしか取れません。Claude Code は statusLine コマンドの標準入力に rate_limits を含む JSON を流し込んでくるんですが、これを受け取れる場所が他にないんですよね。内部イベントログも統計キャッシュもセッションログも、使用率を持っていませんでした。なのでステータスラインのスクリプトが描画のたびに現在値をファイルに書き出して、それをこのスクリプトが読んでいます。
分で見積もっていたのが間違いでした
最初は「見込み分数」で見積もっていました。30分の作業なら30分ぶんのコスト、という発想です。これがまるで当たらない。
そこで過去の会話ログ 78,966ターン / 103セッションを実測したら、分よりも「やりとりの回数」のほうが誤差が狭いと分かりました。誤差の幅（P90/P10）が 3.3倍から2.6倍に縮まります。
考えてみたら当たり前で、同じ30分でも、こっちが黙って待ってる30分と、10往復やりとりする30分ではコストが桁違いなんですよね。時間はコストの単位じゃないです。往復回数がコストの単位でした。
いまは回数で見積もって、回数が不明なときだけ turns_per_min（実測 5.74回/分）で換算しています。
中央値で判定すると、半分の確率で突き抜けます
次に踏んだ地雷がこれです。統計の言葉でいうとパーセンタイルの話です。
見込みちょうどで上限判定をすると、外れた半分のケースで上限を突き抜けます。見込みって当たるか外れるかで、外れる方向は上下両方にあるじゃないですか。中央値で「ぎりぎり収まる」と判定した作業は、半分の確率で溢れます。
なので判定は**悪い側（P90）**でやります。履歴から「実績÷見込み」の比を並べて上位10%点を取って、それを hi_factor として見込みに掛けます。いまの実測値は 1.24倍。
表示は 見込み: $2.79（中央値相当）、判定は 悪い側: $3.4（× hi_factor 1.24）。読者に見せる数字と、着手を止める数字を分けています。
この hi_factor 自体も履歴から自動更新されます。「どれくらい外すか」を実測して、その実測値で安全マージンを決めているわけです。
終わったら実績と突き合わせる
作業が終わったら --done を打ちます。すると：
- 会話ログから実際に掛かったターン数を数える
- ステータスラインが記録していた**実際の消費%と$**を取る
- 見込みと突き合わせて履歴ファイルに1行追記する
- 単価を EMA（指数移動平均）、α=0.3 で更新する
いまのモデルはこうなってます（145回校正済み）。
{
"per_turn_usd": 0.08, "per_agent_usd": 2.07,
"turns_per_min": 5.74, "hi_factor": 1.24,
"pct7d_per_usd": 0.127, "pct5h_per_usd": 1.107,
"calibrated": 145
}
校正で一番効いたのは、**「使った項だけを直す」**ことでした。
前はサブエージェントの単価と1ターンの単価を同じ比率で掛けて補正してたんですが、これだとサブエージェントを1本も使ってない作業の誤差が、サブエージェントの単価まで動かしてしまうんですよね。いまは項ごとに分けています。
- 1ターンの単価 → サブを使っていない作業だけで校正する
- サブ1本の単価 → サブを使った作業だけで、1ターン単価ぶんを引いた残りから校正する
あと校正が1回も走ってない間は、%を表示しません。判定: 判定不能 と正直に出します。推測した数字を出すと、その数字を信じて事故るので。
「これだって帰ってきた時も圧迫するんじゃないの？」
2026年9月9日20時47分。「いい事例を見つけてくれ」と指示したら、Claude がサブエージェントを20本起動しました。
> え、そんなにエージェント走らせて枠大丈夫？見込みは？なん％になる見込みなの？
● 現在: 7d 72% / 5h 38%（…）着地の見込み: 5h 55〜80% / 7d 75〜77%
で、ここで投げた一言が、この仕組みで一番大きな発見になりました。
> これだって帰ってきた時も圧迫するんじゃないの？
● そのとおりです。走らせるコストより、帰ってきたあとのコストのほうが効きます。
止めます。
● 16本止めました。
サブエージェントって、終了時に報告を親のコンテキストに丸ごと投げ込むんですよ。1本の報告が2万トークンに達することがあって、それを以降のやりとり全部で持ち歩くことになります。走行中のコストしか見ていない見積もりには、この帰還ぶんが入っていません。
冒頭の内訳で、サブエージェントがコストの12%しかなかったのを覚えているでしょうか。あれです。軽いんじゃなくて、コストの置き場所がメイン側に移ってるだけでした。集計上サブの欄が薄いので、余計に危ない。
この日からルールが1行増えました。サブエージェントは1回に4本まで。これは上限であって目安ではない。（サブエージェントの公式ドキュメント）
本数は「調べたい観点の数」じゃなくて「報告を読み切れる数」で決めます。5本以上要ると思ったら、それは観点を絞れてないということなので。
あとで公式ドキュメントを見たら、ちゃんと書いてありました。
Agent teams use approximately 7x more tokens than standard sessions
（Manage costs effectively - Claude Docs）
7倍だそうです。20本起動したときに知りたかった。
正しく止まった結果、枠を丸ごと捨てました
同じ日の20時26分、その21分前の話です。5時間枠が67%に達していて、Claude は仕様どおり「上限に近づく」と判定して、確認を取りに来ました。そして私の返事を待って止まっていました。
> あ、いいよ全然
> むしろ早くやれ
> お前何止まってんだよ
> 後3分でリセットだろうが！
● 止まったのは私の判断ミスです。枠を余らせました。以後、数字は出しても止まりません。
枠はリセットで戻るんですよね。リセット3分前に確認を取りに行って返事を待つのは、戻る直前の枠を丸ごとドブに捨てる行為でした。判定としては正しくて、判断としては最悪です。
なのでルールにこう足しました。
- 「上限に近づく」でも、確認せずに進めてよい場合がある
- リセットまで10分以下で、いまの使用が90%未満なら、聞かずに着手する
- 数字は出す。だが止まらない
安全側に倒す仕組みを作ると、倒しすぎて損をする局面が必ず出てきます。「止まる条件」は「見積もる仕組み」とは別に設計しないとダメでした。
見込みを校正してたのに、見込む本人が校正されてなかった
ここまで書いておいて何なんですけど、この仕組みにはまだ穴があります。記事を書くにあたって履歴を集計し直したら見つかりました。
実績÷見込みの分布（n=114）がこれです。
| 中央値 | P90 | 最大 | 最小 | |
|---|---|---|---|---|
| 実績/見込み（金額） | 0.35倍 | 1.24倍 | 6.51倍 | 0.05倍 |
114件中 97件（85%）が見込みを下回っています。2倍を超えたのは6件だけ。つまり中央値で見ると体系的に過大見積もりで、見込みの3分の1しか実際には使ってません。
誤差を分解すると、犯人がはっきりします。
| 誤差の出どころ | 中央値 | 校正ループに乗っているか |
|---|---|---|
ターン数の見込み（--turns N） |
0.41倍 | ❌ 乗っていない |
| 1ターンあたりの単価 | 0.75倍 | ✅ EMAで校正済み |
主因は AI の自己申告でした。Claude が「この作業は22往復かかります」と申告して、実際は9往復で終わってる。しかも見込みと実績のターン数は両方とも履歴に記録されてるのに、その比が次の見込みに還ってないんですよね。
単価だけを145回校正し続けた結果、「単価は正確だけど回数が2.4倍過大」という状態にきれいに収束していました。校正ループの中に、見積もりを出す本人が入ってなかったわけです。
ただ、中央値が過大側なだけで分散そのものが大きいです。実例を出すと、この記事を書いた作業がまさにそうでした。
実績: $2.2482 / 7d+1% / 5h+7% やりとり49回・23分
見込: $2.79 / 7d+0.4% やりとり22回・40分
差 : 回数 2.23倍 / 金額 0.81倍
22回と申告して49回かかってます。中央値とは逆方向に2.23倍外しました。金額が0.81倍で収まったのは、1ターンの実単価が見込みより安かったぶんが相殺しただけです。
じゃあ直すべきかというと、一部は「直さないほうがいい」と思っています。過大見積もりは安全側の誤りだからです。少なく見積もって上限を突き抜けるより、多く見積もって余らせるほうがマシですよね。
ただ、過大見積もりには固有の害があります。**「止まらなくていい場面で止まる」**ことです。で、それが実際に起きたのが、上の「後3分でリセットだろうが！」でした。誤差の偏りが、そのまま事故の形になってたわけです。
なので直しどころは、見込みを正確にすることだけじゃないと思っています。
- 見込み自体は過大側に倒したままでいい（安全側）
- ただし実績/見込みのターン数比を記録して、表示だけは実勢に寄せる
- 判定は従来どおり P90 側でやるので、安全マージンは保たれる
- 「止まる/止まらない」の条件は、見込みの精度とは別の軸で設計する
これは次の宿題です。
1ヶ月やって分かったこと
- 表示では解決しません。必要なのは「これから始める作業が枠に収まるか」の判断で、現在値のモニタじゃない
- 時間はコストの単位じゃないです。往復回数がコストの単位でした（実測で誤差が3.3倍→2.6倍に縮まった）
- 判定を中央値でやってはいけません。外れた半分で突き抜けます。実測した上振れ（P90）で判定する
- サブエージェントは走行コストより帰還コスト。報告が親のコンテキストに丸ごと乗ります。本数は「読み切れる数」で決める
- 安全側に倒す仕組みは、倒しすぎて損をします。「止まる条件」は「見積もる仕組み」と別に設計する
- 校正ループに、見積もりを出す本人を入れ忘れると、単価だけ正確で回数が過大な状態に収束します
で、最後に冒頭の伏線を回収しておきます。8月26日、この仕組みがまだ影も形もなかった頃に、私はこう言ってました。
> でもさぁ、君この作業すると100%超えちゃうから作業内容切り替えますとか言ってさぁ、（…）
まじでそういう挙動してますか？やってるとしたら凄くない？聞いた記事にしたらバズる、聞い
た、聞いた？
繰り返しますけど、この「聞いた」は音声入力が取り違えた 「Qiita」 です。
半月後、その本人がこの記事をQiitaに書いています。バズるかどうかは知りません。
ちなみに、この記事を書くにあたって「何がバズるのか」も調べました。Qiita 2,765本とZenn 2,787本を回帰分析した記事によると、いいねの説明力は著者0.238に対して中身0.077だそうです。中身の寄与は1割以下。
つまりこの記事がどうなるかは、たぶん中身とはあまり関係ありません。それでも書いたほうがいい理由は、冒頭の同僚の記事がそうだったように、書かないと誰にもいじられないからです。