Claudeで回すAIエージェントのコスト管理【2026】

🧾Claude Code の費用は「API」と「サブスク」で見え方が違う

API で使うならトークンの消費量がそのまま費用になり、Pro や Max のサブスクなら利用分がプランに含まれます。同じ使い方でも、気にするべき数字が変わります。

Claude Code の公式ドキュメントには、Claude Code は API のトークン消費で課金されると書かれています。 一方、Pro や Max のサブスクでは利用分がサブスクに含まれていて、セッションごとの金額は請求の目安にならず、プランの利用状況のほうを見ることになります。

相場の目安として、同じページには、企業での導入全体の平均でアクティブな日あたり開発者1人約13ドル、月150〜250ドル、利用者の90%は1日30ドル未満、という数字が載っています。 あわせて「使うモデル・コードベースの大きさ・使い方で大きく変わる」とも書かれているので、自分の予算は小さく試して実測で決めるのが筋です。

📏削る前に、どこで使っているかを測る

感覚で削ると外します。セッションの内訳とキャッシュの効き具合を、手元の数字で先に見ておきます。

Claude Code なら /usage で、そのセッションのモデル別の入出力・キャッシュ読み込み・キャッシュ書き込みの量が見られます。 ここに出る金額は手元で計算した見積もりです。通常は定価で計算されますが、組織の管理者がmodelPricing を設定している場合は契約レートで計算されます（Manage costs effectively）。 サブスク利用者にとっては請求額の目安になりません。正式な請求は Console の利用状況ページで確認します。

自前でエージェントを組んでいる場合も、呼び出しごとのトークン数を記録しておくと、あとで同じように内訳を比べられます。 キャッシュを使っているなら、読み込みと書き込みを分けて残しておくと、効いているかどうかの見当がつきます。

📚長い会話を抱えたままにしない

トークン課金では、モデルに読ませた量がそのまま入力として数えられます。前置きや会話が長いほど、一回の呼び出しが重くなります。

エージェントは一つの仕事の中で何度もモデルを呼び出します。前の作業のやり取りを抱えたまま次の作業に入ると、関係のない文脈の分まで読ませ続けることになりかねません。 そこで有効な方法の一つが、関係のない作業に移るときは会話を切る（Claude Code なら /clear。新しいセッションとして始まります）という地味な習慣です。

自前でエージェントを組んでいる場合も、考え方は同じです。毎回の呼び出しに載せる前置きの指示は必要なことだけに絞り、長いテスト出力やログはそのまま渡さずに要点を抜き出してから渡す。 これは製品の機能というより設計の工夫ですが、入力の量が費用に直結する以上、効き目は/usage や自前の記録で確かめられます。

🧠モデルの選び方も費用を左右する

モデルによって単価そのものが違います。どの仕事もいつも上位モデルで回していると、それだけで費用は膨らみます。

Claude API のプロンプトキャッシュのページに載っている主要モデルの料金表では、100万トークンあたりの基本の入力単価に、1ドルのモデルから10ドルのモデルまで開きがあります（2026年9月時点）。 難しい判断が要る作業と定型作業を分け、定型作業にはより安いモデルを試してみる価値はあります。 ただし、安いモデルで品質が足りずにやり直しが増えれば、かえって高くつくこともあります。

うまく動かないときに、すぐ上位モデルへ替えたくなる気持ちはよく分かります。 ただ、原因が情報不足なのか粘りの不足なのかを切り分けずに替えると、値段だけが上がることもあります。 その順番は 上位モデルに替える前に、切り分ける に書きました。

🧊キャッシュは寿命の内側で使って初めて安くなる

キャッシュからの読み込みは通常の入力より安くなります。ただし寿命があり、切れてから呼ぶと割高な書き込みを払い直すことになります。

読み込みの倍率はモデルごとに違うので、使っているモデルの料金表で確かめてください。 寿命は既定で5分で、キャッシュが使われるたびに追加の費用なしで更新されます。つまり、寿命の内側で次の呼び出しが来るなら安く、切れてから来るなら書き込みの費用を払い直すことになります。 ループを回す間隔とキャッシュの関係は 自走AIのループ間隔はキャッシュで決める で詳しく書いています。

すぐに結果が要らない大量処理なら、Message Batches APIという選択肢もあります。非同期で処理するかわりに費用は半分になり、多くのバッチは1時間以内に終わると案内されています。 夜間の一括チェックのような仕事は、こちらに寄せられないか一度考えてみる価値があります。

🧭自走させる範囲を、先に線引きしておく

人が画面を見ていない間に動く仕組みほど、費用の膨らみに気づくのが遅れがちです。何を任せ、どこで止め、上限をいくらにするかを、走らせる前に決めておきます。

定期実行やサブエージェントを使う構成では、手元の会話とは別のところで呼び出しが積み重なります。 走らせる前に決めておきたいのは、次の三つです。

• 任せる範囲：完了の条件が機械で判定できる作業から自走させる。判定が人の目頼みの作業は、やり直しで費用が二重になりやすい。
• 止める条件：試行の回数と、終わったら閉じることを最初に書いておく。役目を終えたサブエージェントや定期実行を残さない。
• お金の上限：API なら Console のワークスペース単位の支出上限、Claude Code なら --max-budget-usd のような上限を、仕組みの側に持たせる。

ただし、支出上限は「そこで必ず止まる」保証ではありません。Batch processing のドキュメントには、バッチは処理量が多く並行して動くため、ワークスペースに設定した支出上限をわずかに超えることがあると書かれています。 上限だけに頼らず、利用状況の定期的な確認と、ジョブ側の止める条件（回数・時間・件数）も合わせて持たせておくのが安全です。

✅明日からやる順番

測る → 文脈を切る → モデルを選び直す → キャッシュを確かめる → 自走に上限。この順なら、効果を確かめながら進められます。

大事なのは、一度に全部変えないことです。まとめて変えると、どれが効いたのか分からなくなります。 一つ変えたら、しばらく同じ仕事を回して /usage や自前の記録を前と比べる。比べる期間は、編集部としては一週間ほどを目安にしていますが、これは決まった基準ではありません。 利用量が少ない場合や、月次の締めのように仕事の周期が長い場合は、その周期が一巡するまで待ってから比べてください。 遠回りに見えますが、効いたかどうかを確かめやすいやり方です。

エージェントに仕事を任せるほど、費用はモデルの賢さだけでなく「段取り」にも左右されるようになります。 使い方を整えるのと同じ目線で、お金の流れも一度見直してみてください。