Reveniumで見るAI費用が膨らむ原因｜上限で止める仕組み

「AIエージェントの予算は、モデルの利用料の見積もりで組んだはずだった」「請求書が何社からも別々に届いて、結局1件の処理にいくらかかったのか誰も答えられない」——AIエージェントを業務に入れ始めた会社の情報システム部門や経営企画から、よく出てくる声です。予算を組んだ人も、請求を受け取る人も、見ている数字が違っています。実際、AIの原価を計る基盤の提供元が出した例では、融資の審査の処理1件の費用のうち、モデルの利用料（トークン代）は1%に満たず、残りは信用情報の照会や本人確認などの外部のサービスだったとされています（提供元の発表を伝えた報道）。費用が膨らむ原因は、トークン代の外側にあることが多いのです。この記事では、AIの原価を計る海外の新しい製品 Revenium を例に、エージェント1件の原価を誰が定義し、上限に達したら処理を止める判断を誰が持つかを整理します。

Revenium は、AIの利用と費用と原価を1件ずつ記録する基盤

Revenium は、企業がAIを使ったときの利用量と費用を、呼び出し1回ごとに記録し、それを部門・製品・エージェント・顧客に結び付けて見せる製品です。公式サイトでは、技術部門と財務部門の責任者に向けた「AIの経済を管理する仕組み」と位置づけられ、見える化・制御・成果との結び付けの3つを柱に掲げています（2026年10月時点）。

仕組みとしては、自社のアプリやエージェントに Revenium の部品（SDK）を組み込み、モデルを呼ぶたび、道具を使うたびに、その記録を送る形です。記録には、どのエージェントの、どの処理の流れの、どの顧客のための呼び出しかが付きます。請求書を後から分解するのではなく、使った瞬間に「誰の何のための費用か」を付けておくのが特徴です。

これまで、AIの費用の管理と言えば、モデルの提供元の管理画面で月ごとの利用料を見ることでした。しかしエージェントは、モデルを呼ぶだけでなく、検索の窓口、外部のデータの提供元、社内のシステム、人の確認と、いくつもの費用のかかる先を次々に呼びます。Revenium は、その全部を1件の処理の中の費用として並べようとしています。

つまり導入を考えるときの論点は、見える化の道具を入れるかどうかではありません。1件の処理に、どこまでの費用を含めて「原価」と呼ぶかを、社内で決められるかが、最初の論点になります。

どんな会社で、国内でまだ知られていない理由

Revenium は、最高経営責任者のジョン・ローウェル氏と、最高製品責任者のジェイソン・カンバーランド氏が共同で創業した会社です。2026年に入ってから、3月、6月、8月と続けて新しい機能を発表しており、活動は活発です。本社の所在地は、公式サイトでも確かめた報道でも示されていなかったため、この記事では書きません。

報道によれば、料金の区分には、無料の開発者向けの枠、中小の企業向け、大企業向けの個別の契約があるとされています。公式サイトでは顧客の名前は出ておらず、匿名の推薦の言葉として、海外のセキュリティ企業や業務ソフトの会社の技術・製品の責任者が挙がっています。

国内でまだ知られていない理由は、確かめた範囲で3つあります。一つは、公式サイトと文書が英語だけであること。二つめは、想定する読み手が、AIを自社の製品に組み込んで顧客に提供する会社の技術と財務の責任者で、社員がAIを使うだけの会社とは課題が違うこと。三つめは、国内ではまだ、エージェントを本番の業務で大量に動かしている会社が多くなく、トークン代の外側の費用が問題になる段階に来ている会社が限られることです。

ただし、エージェントが外部のデータや人の確認を呼ぶ業務は、審査・調査・問い合わせ対応などで国内でも増えています。製品を入れるかどうかとは別に、この製品が前提にしている「1件の原価」の考え方は、エージェントを動かすすべての会社に関係します。

2026年に出た3つの機能と、それぞれの中身

Revenium が2026年に出した機能のうち、この記事の主題に関わるのは次の3つです。日付と中身は、公式の文書と、提供元の発表を伝えた報道で確かめた範囲です。

機能	発表	中身（確かめた範囲）
Tool Registry	2026年3月4日（一般提供）	外部の窓口・MCP サーバー・業務ソフト・社内の計算・人の確認の時間を「道具」として登録し、1回ごとに計ってエージェント・処理の流れ・顧客に結び付ける。報道では、処理の単位で上限に達すると止める仕組みも含むとされる
AI Insights	2026年6月9日（報道）	取引の履歴から、削れる費用の候補を、月あたりの削減の見込みの順に並べて示す。公式文書の説明は提案で、自動で設定を変えるとは書かれていない
Guardrails	2026年8月3日（報道）	AIの呼び出しが提供元に届く前に、予算や使ってよいモデルの規則で止める。顧客は提供開始の時点から使えるとされる

このうち、無駄の候補を並べる AI Insights は、費用を「減らす」ための機能で、どんな使い方が無駄になりやすいかの話は、別の記事「AIの無駄を見つける方法（フィンオプス）」で扱っています。この記事は、原価を「定義する」ことと、上限で「止める」ことの2つに絞ります。

また、報道で伝えられた機能と、公式文書に書かれた機能は、細部で一致しないところがあります。たとえば処理の単位で止める仕組みは報道に出てきますが、確かめた公式文書の上限の説明は、日・週・月・四半期の期間で区切る形でした。導入の判断では、公式文書に書かれた動きだけを前提にするのが安全です。

課題：エージェントの費用が予算を超えても、気づくのは請求のあと

エージェントの費用で起きる問題は、金額の大きさより、気づくのが遅いことです。モデルの利用料は提供元の管理画面でほぼ毎日見られますが、外部のデータの提供元や検索の窓口の請求は、月末か翌月にまとめて届くことが多い。人の確認の時間は、そもそも請求書になりません。

その結果、エージェントが想定より多く外部のサービスを呼んでいても、モデルの利用料だけを見ている担当者は気づきません。月末に複数の請求がそろい、合計してみて初めて予算を超えていたと分かります。そのときには、すでにひと月分の処理が終わっています。

もう一つの問題は、超えたと分かっても、どの処理が原因かを特定できないことです。外部のサービスの請求は「今月の照会の件数」として届き、どのエージェントのどの処理の流れが呼んだかは書かれていません。原因が分からないまま、全体の利用を絞るしかなくなるのが、よくある結末です。

報道で伝えられた提供元の説明でも、問題はトークンの単価ではなく、モデルの請求の外で起きているエージェントの支出だ、とされています。課題は「高い」ではなく「見えない」ことにあります。

トークン代が原価のごく一部になる業務がある

リードで触れた例をもう少し見ます。Tool Registry の発表を伝えた報道によれば、融資の審査を行うエージェントの例で、1件の処理のトークン代は数十セント程度だったのに対し、信用情報の照会に数十ドル、本人確認や不正の判定、口座の確認にそれぞれ数ドルがかかり、トークン代は1件の費用の1%に満たなかったとされています（提供元の発表を伝えた報道。内訳の合計と全体の金額は報道の中で厳密には一致していません）。

同じ報道では、保険の請求の処理で、人の確認に回る割合が最初は35%で、6か月で12%まで下がった例も紹介されています。これも提供元が示した例ですが、人の確認の割合が変わると1件の原価が大きく動くことを示しています。

この2つの例から分かるのは、エージェントの原価は、業務によって中身がまったく違うということです。調べものや文章の下書きのように、モデルを呼ぶだけの業務ならトークン代が中心です。一方、外部のデータを買う業務や、人の確認が欠かせない業務では、トークン代は脇役になります。

国内の会社が自社の業務に当てはめるときは、自社のエージェントがどちらの型かを最初に見分けます。トークン代が中心の業務なら、モデルの利用料の予算化で足ります。その考え方は別の記事「従量課金のAIはどう予算化する？」で扱っています。この記事が対象にするのは、トークン代の外側の費用が大きい業務です。

原因1：費用がトークン・外部サービス・人の作業に分かれて請求される

一つめの原因は、費用の発生する場所がばらばらで、それぞれ別の仕組みで請求されることです。モデルの利用料はAIの提供元から、外部のデータは各提供元から、社内の計算は社内の基盤の費用として、人の確認は人件費として計上されます。

この4つは、締めの日も単位も違います。モデルはトークン、外部のデータは照会の件数、社内の計算は時間、人の確認は人の時間です。単位が違うものを合計するには、同じ1件の処理に結び付ける鍵が要ります。鍵がなければ、月の合計は出せても、1件あたりの原価は出せません。

Tool Registry が解こうとしているのは、この鍵の問題です。公式文書では、お金がかかるものは何でも道具として登録して単価を付け、計ることができ、道具の費用はモデルの呼び出しと同じく、エージェント・処理の流れ（トレース）・顧客に結び付けて記録されると説明されています。単価は一律の単価のほか、量に応じて単価が変わる段階の料金にも対応し、1回ごとに実際の金額で上書きすることもできるとされています。

ただし、登録しなければ計られません。報道では、登録されていない道具を動いている最中に見つける機能もあるとされていますが、確かめた公式文書の道具の説明には、その記述は見当たりませんでした。何を道具として登録するかは、導入する側が棚卸しして決めることになります。

原因2：1件あたりの原価を誰も持っていない

二つめの原因は、組織の問題です。モデルの利用料は情報システム部門が、外部のデータの契約は業務の部門が、人の確認の人件費は現場の上長が持っていて、1件の処理の原価を全部足して見る役割が、どこにもないことが多いのです。

持ち主がいないと、何を「1件」と数えるかも決まりません。融資の審査なら申込み1件か、照会1回か。問い合わせ対応なら問い合わせ1件か、やりとりの1往復か。数え方が決まらないまま記録の仕組みを入れても、集計の画面には数字が並ぶだけで、誰もその数字で判断しません。

また、原価の持ち主がいないと、上限の金額を決める人もいません。情報システム部門は「業務の部門が決めることだ」と考え、業務の部門は「システムの設定の話だ」と考える。その間で、上限は誰も責任を持たない仮の数字のまま置かれます。

社内の部門に費用を配る話とは、ここで分けて考えます。配賦は「誰が払うか」の話で、別の記事「AIの利用料は誰が負担する？」で扱っています。この記事で言う原価の持ち主は、「1件にいくらまでかけてよいか」を決める人です。

原因3：止める条件が決まっていない

三つめの原因は、どこまで来たら止めるかが決まっていないことです。人が行う業務なら、予算を超えそうになれば誰かが気づいて相談します。しかしエージェントは、止める条件を与えられていなければ、条件が許す限り処理を続けます。

止める条件が決まっていないと、2つの極端が起きます。一つは、上限を置かずに走らせ、月末に予算超過が分かるパターン。もう一つは、怖くなって上限をきつく置き、業務の途中で処理が止まって顧客への対応が滞るパターンです。どちらも、止めたあとに業務をどう続けるかを決めていないことが根にあります。

エージェントが外部のサービスに支払う権限そのものの決め方は、別の記事「AIに支払いを任せても責任は会社に残る」で扱っています。また、AIのツールを買う前の申請と承認は、同じ日に公開の Zip の記事が扱います。ここで扱うのは、すでに動いているエージェントの費用が、決めた線を超えたときの止め方です。

止める条件には、金額だけでなく、期間と対象の範囲が要ります。1日あたりか、1か月あたりか。全社でか、エージェントごとか、顧客ごとか。この3つが決まって初めて、仕組みに条件を渡せます。

原因ごとの手当てと、持ち主

ここまでの3つの原因を、手当てと持ち主の組み合わせで並べると次のようになります。Revenium のような仕組みが担えるのは「記録」と「判定」の部分で、手当ての中身を決めるのは人です。

原因	起きること	手当て	決める人
請求が分かれている	月末まで合計が分からない。原因の処理を特定できない	費用のかかる先を道具として棚卸しし、単価を付けて1件の処理に結び付ける	業務の部門（棚卸し）と情報システム部門（組み込み）
1件の原価の持ち主がいない	何を1件と数えるか決まらず、上限の金額も仮のまま	業務ごとに「1件」の定義と、含める費用の範囲を決める	業務の責任者（原価の持ち主）
止める条件が決まっていない	上限なしで超過するか、きつすぎて業務が止まる	上限の金額・期間・範囲と、止めたあとの続け方を先に決める	原価の持ち主と、業務を止める権限のある上長

表の右の列が空欄のままなら、仕組みを入れても効きません。逆に、右の列が埋まっていれば、仕組みがなくても表計算で始められる部分もあります。道具を選ぶ前に、この表の右の列を埋めるのが順番です。

次の節から、3つの手当てを順に見ます。

対策1：1件の原価を定義する

最初の手当ては、業務ごとに「1件」を決め、そこに含める費用を決めることです。定義は、原価の持ち主になる業務の責任者が、情報システム部門と経理と一緒に作ります。次の順で進めると漏れが減ります。

この定義ができると、Revenium のような仕組みに「何を道具として登録するか」を渡せます。逆に、定義なしで仕組みを入れると、登録された道具だけが原価に見え、登録し忘れた費用は原価にないものとして扱われることになります。

人の確認の時間を、原価に入れる

1件の原価の定義で、もっとも抜けやすいのが人の確認の時間です。エージェントが判断に迷ったときに人へ回す、出力を人が承認する、例外を人が処理する。こうした時間は人件費として別の場所に計上され、エージェントの費用としては見えません。

公式文書では、人の確認の時間も道具として登録する例が示されています。確認する人の時間あたりの人件費を単価にして、確認にかかった時間を記録するという考え方です。人の確認を費用として記録すると、エージェントの改善の効果が原価の変化として見えるようになります。

ただし、ここには注意が要ります。人の確認の時間を原価に入れると、原価を下げるために確認を減らしたくなります。保険の請求の例のように人の確認の割合が下がることは、効率の面では望ましく見えますが、確認を減らした分だけ誤りが通る危険もあります。

だから、人の確認の割合は、原価の持ち主だけで下げてはいけません。どの判断は必ず人が確認するかは、業務の品質と法令の観点で決める話で、原価とは別の線です。原価の表には、確認の割合を下げてよい範囲と、下げてはいけない判断を並べて書いておきます。

対策2：上限の置き方と、止め方

2つめの手当ては、上限を置き、達したら止める仕組みです。公式文書の説明では、Revenium の上限の規則は、費用・トークン数・エラーの数などの指標に、日・週・月・四半期の期間と、超えてはいけない上限の値を組み合わせて作ります。上限に達したときの動きは、新しい規則では「止める」だけが選べるとされています。

止め方は、自社のアプリの中に組み込んだ部品（SDK）が、モデルの提供元に要求を送る前に判定し、上限を超えていれば例外を返す形です。公式文書では「提供元は要求を一度も受け取らない」と説明されています。8月の Guardrails の報道でも、提供元に届く前に止めるので請求されない、とされています。

ここで大事なのが、新しい規則は最初「影の運用」で動くという点です。公式文書では、影の運用では利用を集計して通知を送り、記録も残すが、止めはしない、とされています。そして、少なくとも期間の1回分は影の運用で様子を見てから止める運用に切り替えることを勧めています。いきなり止めるのではなく、止めたら何が起きるかを先に見る設計です。

また、上限より手前に警告の線を置き、超えたらチャットやメールに通知を送ることもできるとされています。警告の通知を誰が受け、受けたら何をするかまで決めておかないと、通知は届くだけで誰も動きません。

止める仕組みが、止まらない場合がある

上限で止める仕組みは心強いものですが、仕組みの説明をよく読むと、止まらない場合があることも分かります。導入の前に、その場合を知っておく必要があります。

公式文書では、部品は規則を手元に覚えておき、60秒ごとに新しい規則を取りに行くとされています。そして、Revenium に届かないときは最後に覚えた規則で動き続け、一度も規則を取れていない場合は、止める判定そのものが行われないと書かれています。つまり、仕組みの側が止まったときに業務を止めない作り（フェイルオープン）です。業務を止めない点では妥当ですが、上限が必ず守られるわけではありません。

• 上限の規則を作っただけで、影の運用のまま止める運用に切り替えていない
• 部品を組み込んでいないエージェントや、部品を通さずに外部のサービスを呼ぶ処理がある
• 外部のデータや人の確認の費用は記録と通知だけで、止める対象になっていないことを知らない
• 期間で区切った上限だけを置き、1件の処理が異常に長く回る場合の止め方を決めていない

3つめの点は見落とされがちです。確かめた公式文書では、道具の費用については警告の通知の記述はありましたが、道具の呼び出しそのものを止める記述は見当たりませんでした。モデルの呼び出しは止められても、外部のデータの照会は止まらない可能性があります。トークン代の外側の費用が大きい業務ほど、この差は大きくなります。外部のサービス側の契約で利用の上限を置けるかも、合わせて確かめてください。

対策3：止めたあと、業務をどう続けるか

3つめの手当ては、止めたあとの決めごとです。上限に達して処理が止まったとき、その業務の顧客や社内の依頼者に何が起きるかを、先に決めておかなければなりません。公式文書では、止められた要求には例外が返り、それを自社のアプリが受け取って利用者にエラーを見せる、とされています。エラーの見せ方と、その後の流れは自社で作る部分です。

考えておく選択肢は、主に3つです。人の手作業に切り替えて処理を続ける。処理を翌日や翌月に回して待ってもらう。上限を一時的に引き上げて続ける。どれを選ぶかは業務ごとに違い、顧客との約束がある業務ほど、止めることの損が大きくなります。

確かめた公式文書には、要求ごとの例外の扱いは書かれておらず、止めるのをやめるには規則を無効にする、とされていました。規則を無効にすると、その規則の対象全体が止まらなくなります。だから、上限を一時的に外す権限を誰が持ち、外したら誰に報告するかを、止める判断とセットで決めておきます。外す権限が現場の担当者にあると、上限は形だけになります。

止める判断を持つのは、原価の持ち主と、その業務を止める権限のある上長の二者が基本です。夜間や休日に上限に達したときの連絡の順番も、導入の前に決めておきます。

何が外に出るか、費用の増え方、畳み方

Revenium のような仕組みを入れると、呼び出しの記録が Revenium に送られます。何が送られるかは、社内の審査で必ず確かめる点です。公式文書の AI Insights の説明では、一部の分析はトークンの数だけを使い、Revenium はプロンプトやモデルの応答の中身を読まない、とされています。

ただし、これは特定の分析についての記述です。記録には、エージェント・処理の流れ・顧客を結び付けるための識別の情報が付きます。顧客の識別子をどの粒度で送るか、プロンプトや応答の中身を送らない設定になっているかは、組み込む前に開発の担当者と確かめます。保管の場所や期間は、確かめた範囲の公式文書では読み取れなかったため、契約の前に提供元に確かめてください。

費用の増え方は、報道によれば無料の開発者向けの枠から、中小向け、大企業向けの個別の契約へと段階があるとされています。記録する呼び出しの数や、登録する道具の数が増えると、利用の区分が上がっていくと考えておくのが自然です。金額は公式で確かめてから比べてください。

畳み方も先に決めておきます。部品を組み込む形なので、やめるときは各エージェントから部品を外す更新が要ります。そのとき、上限の規則も一緒に消えることを忘れないでください。仕組みを外すと、止める判定もなくなるので、外す前に、外部のサービス側の上限や社内の承認の流れで代わりの歯止めを用意します。

AIと仕組みに任せる工程と、人が決める工程

最後に、役割の線を整理します。費用の記録、集計、上限での自動の停止、無駄の候補の提示は、仕組みとAIに任せてよい工程です。人が手で集計するより早く、漏れも少ない。一方、原価の定義、上限の金額、止めたあと業務をどう続けるか、止める例外は人が決めます。ここをAIや仕組みの既定値に任せると、誰も説明できない上限が業務を止めることになります。

上限で止める前に決める項目を、一覧にしておきます。導入の前と、四半期ごとの見直しのときに使ってください。

• 業務ごとに、成果の単位で「1件」を決め、原価の持ち主の名前を書いた
• 1件の中で呼ばれる費用の先（モデル・外部のデータ・社内の計算・人の確認）を全部書き出し、単価を付けた
• 人の確認の割合を下げてよい範囲と、必ず人が確認する判断を分けて書いた
• 上限の金額・期間・範囲（全社・エージェント・顧客）を決め、決めた理由を残した
• 影の運用で期間の1回分を見てから、止める運用に切り替える日を決めた
• 警告の通知の受け手と、受けたときにやることを決めた
• 止めたときの業務の続け方（手作業・待ってもらう・一時的な引き上げ）を業務ごとに決めた
• 上限を一時的に外す権限の持ち主と、外したときの報告先を決めた
• 外部のサービスの呼び出しが止める対象になっているかを確かめ、なっていなければ契約側の上限を確かめた
• 記録に送る識別子の粒度と、プロンプトや応答の中身を送らない設定を開発の担当者と確かめた

この一覧が埋まるまでは、上限の規則は影の運用のままでかまいません。止める仕組みは、止める判断の持ち主が決まってから効かせるのが、業務を守りながら費用を抑える順番です。

まとめ

AIエージェントの費用が膨らむのは、トークンの単価が高いからではなく、外部のサービスや人の確認の費用が別々に請求され、1件あたりの原価を誰も持たず、止める条件が決まっていないからです。Revenium は、2026年3月の Tool Registry で外部のサービスや人の確認の時間まで処理ごとに計り、上限の規則で、モデルの呼び出しを提供元に届く前に止める仕組みを公式文書で示しています。ただし、新しい規則は影の運用から始まり、仕組みに届かないときは止めない作りで、確かめた文書では外部のデータの呼び出しを止める記述はありませんでした。入れるなら、業務ごとに1件の原価を定義して持ち主を決め、上限と止めたあとの続け方、上限を外す権限を先に決める。記録・集計・自動の停止・無駄の候補の提示は仕組みとAIに任せ、原価の定義・上限の金額・止める例外は人が持ってください。

• 製品の機能と提供状況は、Revenium の公式サイト、公式文書（上限の規則・道具の利用の記録・AI Insights）を2026年10月23日に確かめた範囲と、2026年3月・8月の発表を伝えた報道に基づきます
• 本社の所在地、料金の金額、記録の保管の場所と期間、日本での提供の窓口は確かめられなかったため、契約の前に提供元に直接確かめてください

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。