体数が増えるほど、コストの議論は避けて通れなくなる。正しい問いは「安いか」ではなく「何と比べているか」だ。
体数が増えると、必ず誰かがコストの話を始める。「ループを100件走らせたら、いくらかかるのか」。この問い自体は自然だ。だが問いの立て方を間違えると、正しい答えにたどり着けない。
第1回で見たとおり、ステップ0の壁のひとつはトークン単価に議論が向いてしまうことだった。ステップ3に入ると、同じ罠がもう一度、もっと大きな規模で戻ってくる。体数が増えた分、単価の話も大きな数字に見えるようになるからだ。
今回はコストを規律として扱う。何と比較するか、いつ節約を考えるべきでないか、そして「大きさの警告」をどう読むかの3つに分けて見ていく。
何と比較するべきか
コストは、トークン単価ではなく人件費と比較して初めて意味を持つ。Boris Chernyは、AIのコストを議論するときによくある間違いをこう指摘している。
“Compare it to what the cost would have been if an engineer had done this work”
筆者訳それは、エンジニアがこの作業をした場合にかかっていたはずのコストと比較すべきものだ。
トークン単価だけを見ると、数字は大きく見える。だが同じ仕事を人が行っていたら何時間かかり、いくらの人件費になったかと比べると、印象はしばしば逆転する。現場でいえば、夜間シフトの担当者を1人追加で確保するコストと、そのシフトのカバー範囲を比べるのに近い。単価だけを取り出して議論すると、比較の土台がずれる。
これは「安ければ何でもよい」という話ではない。比較の軸を正しく選ぶという話だ。軸を誤ると、本当は割に合っている投資を、数字だけ見て止めてしまう判断ミスが起きる。
ただし、この逆転がいつも起きるとは限らない。変更が小さいほど、人件費との比較はむしろAI側に不利に働くことがある。Claude Codeを強く推す実務家でさえ、その事実を隠していない。
“I watched Claude Code burn through $5 in tokens to make a simple change...something that I could have typed myself for free in 30 seconds.”
筆者訳Claude Codeが単純な変更に5ドル分のトークンを燃やすのを見た。自分で打てば30秒で、無料で済んだはずの変更だった。
同じKlaassenは、月400ドルのサブスクは数日で元を取るとも述べたとされる。1回の作業単位で見れば損をすることがあっても、まとまった期間の総量で見れば引き合うことが多い。比較は、その場の1タスクではなく、ある程度の期間の総量で行う必要がある。
最初からコストカットを狙わない
始める前から節約に走ると、そもそも検証ループが育たない。
比較の軸を正しくとる一方で、もうひとつ大事な指摘がある。
“Don't try to cost-cut at the beginning. Start by giving engineers as many tokens as possible.”
筆者訳最初からコストカットを狙ってはいけない。まずはエンジニアに、できるだけ多くのトークンを与えることから始めるべきだ。
これは第7回で扱った検証ループの話と直結している。検証ループを2〜3倍の質に育てるには、まず何度もやり直させる余地が要る。最初の段階でトークンを絞ると、検証を鍛える前に手を縛ることになる。節約を考えるのは、検証ループがすでに機能し、パターンが見えてきてからでいい。順番を間違えると、質の低いまま安くなるだけの結果になる。
モデル選択というコスト管理
単価の安いモデルが、必ずしも総コストを下げるとは限らない。コストは体数やトークン量だけでなく、どのモデルを使うかでも変わる。
Boris Chernyは、自分がOpusを常用する理由をこう説明している。
“since you have to steer it less and it's better at tool use, it is almost always faster”
筆者訳操作の手数が減り、ツールの使い方も上手いぶん、ほぼ常に速い。
安いモデルを選べば、1トークンあたりのコストは下がる。だが手戻りが増え、指示のやり直しが増えれば、同じ結果に到達するまでの総トークン量は膨らむ。
作業の性質に対してモデルの能力が見合っていれば、手戻りが減り、確認の往復も減る。同じ結果に到達するまでの総コストは、単価の高いモデルのほうが安く済むことがある。
判断すべきは単価ではなく、その仕事を最後までやり切るのに何往復かかるかだ。単純な繰り返し作業には軽いモデル、判断が絡む設計には重いモデル、という振り分けが目安になる。
この振り分けは、実際の大規模プロジェクトでも同じ形で使われている。Anthropicが公開した移行事例では、実装役には小さいモデルを、レビュー役には大きいモデルを残すという原則が明記されている。
“You can offload implementer work to smaller models and keep reviewers on larger ones.”
筆者訳実装は小さいモデルに任せ、レビュアーは大きいモデルに残す。
Mike Kriegerが16.5万行のPython→TypeScript移行を週末で終えたときも、主要な翻訳フェーズで展開した12体のサブエージェントの実装役にはClaude Sonnetを使い、レビュー役には上位モデルを残している。単価の安いモデルに全部を寄せるのではなく、役割ごとに使い分けるという、この回で見てきた原則そのものだ。
大きさの警告をどう読むか
第14回で触れたとおり、Dynamic Workflowsには規模の目安がある。25体を超える、または見込みトークン量が150万を超えると「Large workflow」の警告が出る。
実際、その負荷は軽くない。Anthropicのマルチエージェント検証システムの報告（2025年6月公開）によれば、マルチエージェント構成のトークン消費量は、通常のチャット1回の約15倍に達した。BrowseCompでの評価では、エージェント間に生まれる性能差の80%が、トークン使用量の違いだけで説明できてしまうという結果も出ている。体数を増やす判断は、そのままコストの規模を決める判断でもある。
注意
警告は止まれという意味ではない
この警告は「使うな」という意味ではない。その規模が、目的に対して本当に必要かをもう一度確認しろという合図だ。
100件の処理が必要な仕事なら、25体を超えるのは自然なことがある。だが「なんとなく多めに」で体数を増やしているなら、警告が出た時点で目的に立ち返るべきだ。数を減らせないか、あるいはバッチを分けて段階的に実行できないかを検討する。
実際にコストを見る
感覚の前に、まず数字を見る。
$/usageCurrent session: 340K tokens Weekly plan usage: 62% (resets in 3 days)
コストの話を抽象的な不安のままにしないコツは、実際の数字を定期的に見る癖をつけることだ。感覚だけで「高そうだ」「安そうだ」と判断すると、比較の軸を誤ったまま議論が進む。数字を見てから、何と比較するかを考える順番を守る。
よくある誤解と罠
- トークン単価だけを見て高い安いを判断する: エンジニアが同じ仕事をした場合のコストと比較して初めて、正しい評価になる
- 最初から節約を狙って、検証に使うトークンまで絞ってしまう: 検証ループを育てる段階では、まずトークンを潤沢に与える。節約はその後の話
- 安いモデルに全部寄せれば得だと思い込む: 手戻りが増えれば総コストはむしろ膨らむ。仕事の性質に見合ったモデルを選ぶほうが、結果として安く済むことがある
今日のまとめ
- コストはトークン単価ではなく、人が同じ仕事をした場合のコストと比較する
- 検証ループを育てる段階では最初からコストカットを狙わない。節約はパターンが見えてからでいい
- モデル選択は単価ではなく総コストで見る。「Large workflow」の警告は止まれではなく確認しろという合図
明日のアクション
最近Claudeに任せた仕事を1つ選び、かかったトークンやコストの感覚的な印象を書き出してください。
そのうえで、(1) 同じ仕事を自分または同僚が手作業でやったら何時間かかったか (2) その時間の人件費に換算するといくらか、を概算します。
トークンコストとその概算を並べて、印象がどう変わるかを確認してください。数字を並べる前と後で、評価が変わったならそれが今回の練習の狙いです。
次回、第18回はステップ3の最終回。信頼をどう段階的に作るかに入ります。