AIエージェントのモデル選択とコストの判断軸

エージェントを本格的に使い始めると、ほぼ全員が同じ驚き方をします。思ったより高い。あるいは、サブスクリプションなら「気づいたら制限に達している」という形で現れます。

そして多くの人が最初に疑うのがモデル選択です。それも一因ではありますが、支配的な要因ではありません。本当の原因は、コンテキストがどう積み上がるかにあります。この章では、その構造を確認したうえで、効くレバーを整理します。

長く開いているセッションほど高くつく

この疑問には、公式ドキュメントが正面から答えています。仕組みはこうです。

エージェントはリクエストのたびに、会話の全体を送ります。さらに、ツールを使うたびにその結果を載せた別のリクエストが飛びます。つまり1回のやり取りの裏で、何度も会話全体が往復しています。

公式の表現を借りると、1日開きっぱなしのセッションでは、一行の質問でも会話全体分の使用量が発生します。プロンプトキャッシュが効くため、その読み直しはキャッシュ済みの単価になりますが、ゼロにはなりません。

コストはやり取りの回数ではなく、コンテキストの大きさ × 往復の回数で決まります。

ここから、最も効く対策が自然に出てきます。無関係な作業に移るときにセッションを切ることです。古い文脈を運び続けないだけで、以降のすべてのリクエストが軽くなります。

キャッシュは「前方一致」である

プロンプトキャッシュは強力ですが、性質を知らないと簡単に無効化できます。キャッシュは前方一致で判定されます。プレフィックスのどこか1バイトでも変わると、それ以降のキャッシュはすべて無効になります。

実務上の帰結は2つです。

安定した内容を前に、変わる内容を後ろに置く。 指示ファイルのような固定的な内容は前方に、そのときどきの質問は後方に来る構造になっています。ここに毎回変わるもの——現在時刻、実行ごとのID、並び順が不定なデータ——が前方に混ざると、毎リクエストでキャッシュが壊れます。

間が空くとキャッシュは失効する。 公式によれば、キャッシュの有効期間を超えて休憩を挟むと、次の最初のメッセージはコンテキスト全体を再処理します。有効期間はプランや契約形態によって異なり、1時間の場合と5分の場合があります。昼休みを挟んで戻ってきた1通目が妙に重いのは、これが理由です。

実際どのくらいかかるのか

金額の感覚も示しておきます。Claude Codeの公式ドキュメントは、企業導入における実測の目安として次の数字を挙げています。

モデルは仕事に合わせる

そのうえでモデル選択です。公式の指針は明快で、階層を仕事に合わせるというものです。

最上位モデルを既定のまま使い続けるのは、最も分かりやすい浪費です。

判断の軸は3つで考えると整理できます。正確さがどれだけ結果を左右するか。間違えたときの手戻りがどれだけ高いか。何回繰り返す作業か。この3つが小さいものは、下の階層で十分です。

公式も、想定外に高額になるケースの原因として「長いセッションを一度もクリアしていない」と「最上位モデルを既定にしたまま」の2つを挙げています。裏を返せば、この2つを直すだけで大半は改善します。

思考の深さもコストである

見落とされがちなのが、拡張思考（深く考えさせる設定）の扱いです。思考にかかったトークンは出力トークンとして課金されます。そして既定の設定では、リクエストあたり数万トークンに達することもあります。

複雑な計画や推論では価値がありますが、単純な作業では払い損です。多くのツールが思考の深さを段階で調整できるようになっているので、作業の難易度に合わせて下げるのが正解です。「常に最大」は品質を保証しませんが、コストは確実に上げます。

効くレバー

公式が挙げている削減策を、効果の大きい順に整理します。

このうちフックによる出力の絞り込みは、検証ループの章で扱ったものと同じ仕組みです。検証を成立させながらコストも下げられるので、費用対効果が最も高い部類に入ります。

指示ファイルを短く保つ話も、指示ファイルの章で扱った200行の目安と同じものです。あちらでは遵守率の観点から、ここではコストの観点から、同じ結論に行き着きます。

並列化はコストにも効く

複数のエージェントを同時に走らせる構成では、それぞれが自分のコンテキストを持ちます。公式は、エージェントを複数立てる構成が標準的なセッションのおよそ7倍のトークンを使うと述べています（各メンバーが計画モードで動く場合）。

レビューの章で、並列化はレビューする人間の負荷を集中させると書きました。コストの面でも同じ方向に効きます。並列で量を増やす判断は、レビュー体制とコストの両方とセットで行う必要があります。

測っていないものは減らせない

最後に、可視化の手段です。公式には次のような仕組みがあります。

• セッション単位の内訳表示（モデルごとの入力・出力・キャッシュ読み書き）
• 直近の使用が何に使われたかの内訳（スキル、サブエージェント、個別のツールごと）
• 「長いコンテキスト」「キャッシュミス」など、直近使用の10%以上を占める挙動へのフラグ
• 組織単位では、分析ダッシュボード、テレメトリの外部出力、ゲートウェイ経由の集計

3つ目が特に実務的です。自分のコストが何によって膨らんでいるかを、推測ではなく名指しで教えてくれます。「高い気がする」で対策を始めると、たいてい効かないところを直すことになります。

よくあるハマりどころ

セッションを開きっぱなしにする。 最大の要因です。作業が変わったら切ります。

最上位モデルを既定のまま使う。 公式が高額化の典型原因として挙げているものです。

キャッシュを壊す内容を前方に置く。 現在時刻や実行IDが前方にあると、キャッシュは毎回無効になります。効いているかは測れます。

使っていないツールを入れっぱなしにする。 呼ばなくても定義は毎回積まれます。

測らずに「高い」と言う。 何が占めているかを見ずに対策を選ぶと、外します。

思考の深さを常に最大にする。 難しい作業には効きますが、単純な作業では出力トークンを増やすだけです。

ちゃんと使うためのポイント

• コストはコンテキストの大きさ × 往復回数。やり取りの数ではない
• セッションを切るのが最も効くレバー
• キャッシュは前方一致。変わるものを前に置くと毎回壊れる。間が空いても失効する
• モデルは仕事に合わせる。最上位を既定にしない
• 思考の深さもコスト。作業の難易度に合わせて下げる
• フックで出力を絞ると、検証とコスト削減が同時に効く
• 並列化はトークンを大きく増やす（公式の目安で約7倍）
• 何が占めているかを測ってから対策を選ぶ

次の章では、ここまでの技術的な話をチームに広げるときに何が起きるかを扱います。個人で効いた工夫が、そのままチームで効くとは限りません。

参考リンク

• Manage costs effectively（Claude Code 公式） — 使用量が積み上がる仕組み、削減策、可視化の手段、1人あたりコストの目安
• Prompt caching（Claude 公式ドキュメント） — 前方一致の挙動とキャッシュの有効期間
• Pricing（Claude 公式ドキュメント） — 最新の単価。本書には転記していないので、金額はここで確認する