AIエージェントの請求書、何割が無駄か。

毎月の支払い、内訳を言えますか？

AIエージェントの利用料は、多くの会社で「エンジニアが使っているAI代」という1行で決裁されています。チームが5人くらいまでならそれで回るんですが、10人を超えたあたりから急に効いてきます。去年の同じ月と比べて何倍になっているか、即答できますか。

厄介なのは金額の大きさではなく、増えた理由を説明できないことです。モデルの単価表を並べても答えは出ません。請求額を決めているのは単価ではなく、そのモデルをどう動かしているかの設計のほうだからです。

同じモデルでも、請求額は変わる

エージェントはモデル単体では動きません。指示文、参照するファイル、ツール定義、失敗時のやり直し、権限まわり。この一式を実行基盤と呼びます。モデルが原材料なら、実行基盤は調理場です。同じ素材でも、動線の悪い厨房では原価が上がります。

これは感覚論ではなくて、Harness or Model?という論文（arXiv:2609.11987）では、256件のタスクで実行基盤を入れ替えて比較したところ、正解率の差は1ポイント台にとどまる一方、解いたタスク1件あたりの支出は1.2〜1.6倍動いたと報告されています。成果はほぼ同じで、費用だけが動く。経営から見ると、これは値引き交渉ではなく設計の話です。

請求書に潜む5つの税

では、払った金額はどこで消えているのか。支払ったトークンのうち成果に結びつかなかった分を「ハーネス税（Harness Tax）」と呼ぶ整理が、海外の分析で広がっています。名前はともかく、分け方が実務的でよくできてるんですよ。5種類あります。

ツール税は仕組みを知ると納得が早いと思います。APIに渡すツール定義は、ツール名も説明文もスキーマも、すべて毎回の入力トークンとして課金されます（Claudeの料金ページにツール使用の課金対象として明記されています）。使う予定がなくても、接続してあるだけで毎ターン課金されるということです。MCPサーバーを気前よく増やした会社ほど、ここが重くなります。

セッション税も似た構図で、--resume で続きから入らずに毎回ゼロから立ち上げると、CLAUDE.md や初期の読み込みを人数×回数だけ買い直すことになります。

月600万円のうち、210万円は何も買っていない

数字を見ましょう。30人のエンジニアチームが月4万ドル（1ドル150円換算で約600万円）払っている場合、およそ1.4万ドル（約210万円、全体の35%）が成果を生んでいない、という試算がFuture AGIの分析に出ています。内訳として挙がっているのは、週10セッションに満たない座席が28〜41%あること、1ターンで8万〜16万トークンを積み込みながら実際に参照されるのは1万トークン前後であること、そして47%のターンが中位モデルで、22%が最小モデルで同じ結果を出せていたことです。

別の集計では、同じ月4万ドルの請求に対してハーネス税は総支出の30〜45%、金額にして1.2万〜1.8万ドル（約180万〜270万円）という幅で語られています。つまり35%は点ではなく帯です。

ここで1点、注意が要ります。5つの税それぞれに付いている金額を素直に足すと、月4万ドルという総額を軽く超えてしまう。チーム規模や稼働本数の前提が税ごとに揃っていないからです。だから金額をそのまま自社に持ち込むのは危ない。使えるのは比率のほうです。

6人のチームが月120万円使っているなら、30〜45%で月36万〜54万円。年にすると430万〜650万円が、何も買わずに出ていっている計算になります。人を1人採れる額です。

削っていい税と、削ると痛い税

では、どこから手を付けるか。無駄だと分かっても全部を等しく削ると、成果のほうが先に落ちます。順番があります。

削っても成果がほぼ落ちないのがセッション税とツール税です。前の作業を再開する運用に変えること、使っていないツール接続を外すこと。どちらも出力の質には関係しません。会議を減らすのと違って、誰も痛くない。

次がコンテキスト税ですが、これは「減らす」より先に「単価を下げる」ほうが効きます。毎回同じものを読ませているなら、キャッシュを効かせれば読み込み分が通常入力の10分の1になる。参照範囲をむやみに絞ると、今度はエージェントが前提を見落としてやり直しが増えるので、順番を逆にしないほうがいいです。

一番危ないのが階層税です。単価だけ見れば下げたくなります。最小モデルと最上位モデルでは入力単価で5倍から10倍違いますから、全部を下位モデルに寄せれば請求書は劇的に軽くなる。ですが下げすぎると1回で終わっていた作業が3回に増えて、総額は逆に上がります。一律に下げるのではなく、どの種類の作業を下位モデルに回すかを決める話です。

座席税だけは性質が違います。これは削減ではなく配り方の問題で、使っていない人から回収して毎日使っている人の制限を緩めるほうが、投資対効果は上がります。

見るべきは単価ではなく、成果1件あたりの値段

トークン単価を最適化しても、経営の意思決定には使えません。見るべきは、全体の実行コストを検証済みの成功件数で割った数字です。やり直しも、レビューにかかった人間の時間も、失敗して捨てたぶんも、分母ではなく分子に入れる。

この指標のいいところは、削減しか見ないモードから抜けられることです。単価だけ追うと「安いモデルに寄せた」で終わりますが、成果1件あたりで見れば「同じ600万円で成果を1.5倍にする」が選択肢に入ってきます。

ただしこの計算には前提が要ります。何をもって1件の成果とするかを決めないと、分母が作れない。そしてこの定義は、エンジニアではなく経営側が決めるべきものです。

来月の請求書を開く前に、決めておくこと

棚卸しの順番はもう決まっています。座席の稼働率を見る。セッションの再開率を見る。接続しているツールの数を数える。ここまでは今週できますし、成果への副作用もありません。コンテキストとモデル階層はその後、検証しながら動かす。

そのうえで最初に埋めるべき空欄は、削減目標ではありません。「自社にとって、何をもって1件完了とするか」です。ここが決まらない限り、来月の請求書もまた「エンジニアが使っているAI代」という1行のまま決裁されます。

数字が下がったかどうかではなく、同じ金額で何件終わるようになったか。次の経営会議に持っていくなら、そちらの数字だと思っています。