AI Agent の料金:アクション課金とセルフホスト実行コスト
アクション単位や token 単位の課金は柔軟に見えるが、agent が自律的になるほどツール呼び出しは増える。コストは使用量曲線、データ域外、ロックイン、自社運用の分岐点を一緒に見る必要がある。
結論から言うと: アクションあたりの課金とは、agent がうまく働くほど多く払うということだ。本当のコストは、成功とともに使用量が爆発するかどうか、データのエグレスやロックインといった価格表に載らない請求、そしてセルフホストの損益分岐点がどこにあるか――この三点に行き着く。
四半期末、CFO は agent プラットフォームの請求書を開いて、一瞬固まった。予算の四倍だった。
誰も無駄遣いをしたわけではない――むしろ逆だ。カスタマーサポート agent が成功しすぎたのだ。その帳簿を広げて計算してみよう。導入前、チームは一日に約 5,000 件のチケットを処理していた。agent 導入後、一人あたりの効率が上がり、対応量は約 10,000 件へと倍増した。そしてプラットフォームはアクションごとに課金する。チケットを一件処理するたびに、その裏では顧客照会、注文照会、履歴照会、ナレッジベース照会、返金の起動、通知の送信――七つ八つのアクションが基本だ。ざっと計算すると、10,000 件 × 7 アクション × $0.10 ≒ 一日 $7,000、一年で約 250 万ドル。一方、予算は当初「5,000 件、一件あたりは少なめに」見積もって当て勘で決めたものだった。
最も皮肉なのはここだ。このプロジェクトが成功するほど、この請求書は恐ろしくなる。 だから取締役会の第一反応は、効率倍増を祝うことではなく、「使用量を抑えられないか」と問うことだった――本来は拡大すべき成功が、課金モデルのせいで、かえってブレーキを踏まれた。ROI がまだ本当に実現する前に、規模がコスト不安に首を絞められた。
一毛(いちまい)に、膨らみ続ける数を掛ける
Salesforce の Agentforce は Flex 課金を打ち出した。アクションあたり $0.10。この数字だけ見れば、安すぎて警戒が緩む。
だが agent の課金で最も警戒すべきはここだ――それはコストを 使用量 に縛りつけるが、agent の存在意義はまさに、自律的に、高頻度で、疲れを知らずアクションを起こすことにある。しかも自律的な agent ほど、一つのことをうまくやるために起こす中間アクションが多い。「この顧客の状況を整理して」という一つのリクエストの裏には、十数回のツール呼び出しがあるかもしれず、あなたは事前にそれを数え切れず、上限を設けるのも難しい。さらに token ごとに課金するプラットフォームもあり、アクション課金よりも予測しにくい――同じタスクでも、モデルが数ステップ多く考えれば、請求書が一段増える。公開された報道のあの対比は誇張ではない。同等の利用量で、SaaS モデルの年間コストは 200 万ドル超 に達しうるが、機能的に等価なセルフホストのデプロイは、ライセンス込みのインフラでおよそ 25 万ドル の桁だ――差は一桁ある。
従量課金のほうが節約で、柔軟ではないのか?
ここで一つの反論を真剣に受け止めなければならない。多くの場面でそれが正しいからだ。従量課金は初期投資がなく、使う量が少なければ払う額も少なく、ベンダーが運用を肩代わりしてくれ、あなたは生み出された価値の分だけ払う――この論理はクラウドコンピューティングの時代に何度も検証された。なぜ agent ではそれが成り立たないと言うのか?
それは成り立つ。だが一つ前提がある。コストがそれに連れて増える「量」が、あなたの価値と切り離されている、あるいは弱い相関であること。 クラウドストレージを GB ごとに課金するのは問題ない。多く保存するのは普通、業務が大きく、払えることを意味し、両者がおおむね同期するからだ。
agent はこの前提を破壊した。それは「アクション数」で課金し、アクション数はまさに 自律の度合い と 成功の度合い に連れて暴騰する――あなたがそれに多く仕事をさせ、より良くやらせたいほど、それが起こすアクションは多くなり、請求書は高くなる。これは一種の「成功への課税」になる。あなたが激しく最適化するほど(agent に一歩多く照会させ、一度多く照合させて品質を上げる)、税率はかえって高くなる。従来のソフトウェアは席ごとに課金するので、どれほど激しく使ってもコストは上限がある。アクションごとに課金すれば、あなたがうまくやるほど、多く払う。クラウド時代のあの「従量こそ公平」という直感は、無数の中間アクションを自分で起こし、しかもあなたがそれを多くやるよう奨励する実行体の上では、機能しなくなる。
ではいったいどれくらいの使用量で自分で動かすべきか? 交差点を計算する
「場合による」で止まってはいけない。CFO のあの二つの数字を使えば、交差点をおおよそ割り出せる。
セルフホスト側は、年間コストが約 25 万ドル(ライセンス + インフラ + 一部の運用分担)に固定されると仮定する。それは 呼び出し回数にほとんど連動しない。アクション課金側は $0.10 × アクション数だ。両者を等しいと置く。
$250,000 = $0.10 × 年間アクション数
年間アクション数 ≈ 250 万回 → 約 一日 6,800 アクション
つまり、一日の agent アクション数が約 7,000 の桁を超えると、アクション課金はセルフホストより高くなり始め、その後は差がどんどん開いていく。あの CFO に戻ろう。彼は一日 7 万アクション(10,000 チケット × 7)で、交差点を一桁以上上回っていた。これこそ請求書が 250 万に跳ね上がった理由だ。彼の苦痛は不慮の事故ではなく、利用量が試験導入から規模化へ入ったことを示している。
この計算式は、そのまま自分の数字に当てはめられる。チームの一日の対話量に「一回の対話でだいたい何アクションか」を掛けて、7,000 という桁と比べてみれば、自分が交差点のどちら側にいるかが分かる。
三つのコストモデル、並べて比べてみる
| モデル | 代表 | コストが何に連れて増えるか | 予測可能性 | データはどこにあるか |
|---|---|---|---|---|
| アクション / token 課金 | Agentforce Flex($0.10/アクション) | アクション数に線形、ときに超線形で膨張 | 悪い、うまく使うほど高い | ベンダーのクラウド |
| 席課金 | 多くの Copilot 系 | 人数に連れて増え、上限はあるが一人あたりは安くない | 中、だが agent の自律性と乖離 | ベンダーのクラウド |
| セルフホストランタイム | ObjectStack / ObjectOS | インフラに連れて、使用量とほぼデカップリング | 良い、使用量倍増でも曲線はほぼ動かない | あなた自身のインフラ |
席課金は安定して見えるが、内在的な矛盾がある。agent の価値は席を占めずに大量の反復労働を代替することにあるのに、あなたはまだ「頭数」で払っている――課金の軸と価値の軸が合っていない。セルフホストはコスト構造そのものを取り替える。あなたは実行エンジンと自分の計算力に払い、使用量が一万から十万に増えても、請求書はアクション数にそのまま線形には増えない。
まず冷や水を:セルフホストはどこでも安いわけではない
「40〜60% 節約」を四方八方で通用する真理と思ってはいけない。それには明確な成立区間があり、境界を越えれば成立しない。
あの 25 万ドルという代表的な数字は、人を計算に入れていない。セルフホストは、運用し、パッチを当て、可用性を保証する人がいることを意味する――もしプラットフォームチームがいなければ、この隠れた人件費が、帳簿上の優位を大きく食い潰しかねず、上のあの交差点を右へ押しやることにもなる。しかも固定費がある。インフラと運用は先に払うもので、使用量とはあまり関係がない。
だから使用量がごく小さく、低頻度で、純粋に実験的な段階では、従量課金のほうがかえって柔軟で安い――ほとんど遊んでいるランタイム一台のために、チームを養う必要はない。セルフホストの優位は、あなたが 規模拡大するのが確実になった あとに初めて実現する。
本当に高い一筆は、価格表に載っていない
たとえセルフホストのほうが得な側に来たとしても、毎月の請求書だけ比べるのは、なお問題を過小評価している。課金モデルを選ぶ前に、本当に計算すべきは 三つの帳簿 で、そのうち二つは価格表に載っていない。
- 使用量の帳簿:コストは成功に連れて暴騰しないか? これこそ CFO のあの四倍の請求書――あなたの使用量が agent の成功と正の相関にあるか。あるなら、アクション課金は罠だ。
- コンプライアンスの帳簿:データが域外に出る代償。 アクション課金、席課金の SaaS は、業務データが継続的にベンダーのクラウドへ流れることを意味する。EU AI Act が 8 月に強制執行され、CADA が主権フレームワークを提案する背景の下、一度のデータレジデンシー違反の罰則は、何年分ものライセンスを払うに足りる。
- ロックインの帳簿:将来出ていけなくなる代償。 業務定義、フロー、権限がすべてあるプラットフォームの中に生えると、移行コストが使用時間に連れて複利で上がる。ソフトウェアに払っているつもりが、実は「将来出ていけなくなる」ための敷金を払っている。
この三つを合わせて計算すれば、「アクションあたり一毛」のあの表面的な安さは、すぐに食い尽くされる。
セルフホストはなぜこの数筆を同時に押さえられるのか
核心はひとことだけだ。あなたはこの業務定義を動かすエンジンに払うのであって、それが何回呼び出されたかに払うのではない。 ここから――
- コストが使用量とデカップリングする。 ObjectOS はあなた自身のサーバー上で業務定義を実行し、agent がガバナンスされたツールを何回呼び出そうと回数で課金しない――コストはインフラで決まり、予測でき、計画できる。あのチケットが倍増した CFO の請求書は、ほとんど動かない。
- データが域外に出ない。 オブジェクト、権限、監査証拠はすべてあなた自身のインフラに留まり、コンプライアンスリスクとデータ域外コストが一緒に下がる。
- ロックインされない。 業務定義はオープンプロトコル(Apache 2.0)の下、あなたのリポジトリの中のメタデータで、diff が取れ、移行できる。あなたが買うのはランタイムのサービスであって、「将来出ていけなくなる」ための敷金ではない。
結び
「アクションあたり $0.10」は、入念に設計された値札だ。あなたが立ち上げたばかりで使用量が小さいときは無害に見え、あなたが本当に成功して使用量が離陸するときに牙をむく。四半期末のあの CFO に戻ろう――彼の請求書は暴走したのではなく、この課金モデルが設計したとおりの必然だ。それは、あなたが最も祝うべき瞬間に、最も大きな一枚の請求書を差し出す。
agent のコストを計算するなら、単価だけを見てはいけない。あの三つの帳簿――使用量、コンプライアンス、ロックイン――を計算し、それからあの交差点の公式で自分の使用量と比べてみよう。これらを計算し切れば、「セルフホストで 40〜60% 節約」はスローガンではなく、予算表に書き込める、しかもいつ 成立しない かも分かる結論になる。
npm i -g @objectstack/cli && os start
自分のマシンでビジネスオブジェクトを一つ動かし、agent に何千回も繰り返し呼び出させて、それから請求書を見てみよう――それは動かない。「毎回 $0.10」という項目がないからだ。