AI利用の従量課金をコスト設計する。予算とガードレールの決め方

AIの活用が全社に広がる段階で、静かに起きる事故があります。
生成AIのAPI料金、つまり請求額が想定を大きく超えるという事故です。
10人で試していたときは月に数千円だったものが、300人に広げた途端に桁が変わります。
気づくのは、たいてい「請求が来たとき」です。

一度この事態が起きると、たいてい利用そのものを止めることになります。
現場の信頼を失って、次の展開が数か月遅れるからです。

今回は、この請求が膨らむ事故をどう防ぐかについて書いていきます。
自動化の全体像とコスト設計の全体については、AIによる業務自動化の全体像。手段の選び方とコスト設計にまとめてあります。

気づいたときには、もう請求が膨らんでいる

なぜ膨らんでいることに気づけないのでしょうか？
理由は3つあります。
まず、使った瞬間には費用が見えません。
定額のサービスと違って処理した量に応じてあとから請求されるので、現場は自分がいくら使ったかを知らないまま作業を続けます。

次に、展開すると量が急に増えます。
10人が1日3回使う状態から300人が1日3回使う状態になれば、単純計算で30倍です。
ただ、増え方そのものは線形なのに、体感よりずっと速く膨らみます。

もうひとつは、自動化すると費用が人の意識から外れることです。
定時に走る処理もイベントで起動する処理も、人が意識しないまま動き続けます。
もちろん、処理の件数が増えれば、そのぶん費用も比例して増えていきます。

この3つの中で、もっとも危ないのは最後の理由です。
人が使う分は使った人が量を体感できますが、自動化された分はだれも体感していないからです。

費用は4つの要因で決まり、4つの打ち手で下げられる

では、何にお金がかかっているのでしょうか。
仕組み自体はシンプルです。

費用は処理した量で決まり、その量は渡した内容と返ってきた内容の合計で計算されます。
費用を増やす要因は4つあります。
渡す情報が多いこと、返ってくる内容が長いこと、実行の回数が多いことです。

このなかで、渡す情報の量がいちばん効きます。
長い文書をまるごと参照させたり、大量のデータを渡したりする使い方です。

もうひとつ、高性能なものを使うと単価が上がるという要因もあります。
同じ処理でも、使うモデルによって単価は数倍から数十倍違います。
この4つが、そのまま打ち手の起点になります。

まず、渡す情報を絞ります。
参照させる文書を必要な範囲に限定して、全文ではなく関係する章だけを渡すという工夫です。

次に、出力の分量を指定します。
「300字以内で」と一言添えるだけで、際限なく長くなっていた出力が止まります。

もうひとつが、段階処理で単価を下げることです。
すべてを高性能なものに通すのではなく、単純な絞り込みは安いものに任せ、判断が要る部分だけを高性能なものに回します。
また、同じ結果を出していても、ここで費用は大きく変わります。

最後が、結果を再利用することです。
同じ処理を繰り返さない設計にして、特に自動化では一度処理した対象を再処理しない形にしておきます。

このなかで、もっとも効果が大きいのは段階処理です。
同じ結果を、費用だけ数分の1に抑えて得られることがあります。

そのため、事故の予防としては再利用の設計も重要です。
「同じ行を何度も処理する」という誤りが、費用が急増する典型的な原因だからです。

段階処理そのものの進め方については、AIの精度が低いと言われる前に。段階処理を現場の標準手順にするにまとめてあります。

部門別の予算と2段階アラートで、上限までの運用を決める

使う側の設計を決めたら、次は管理する側をどう設計すればいいのでしょうか？

まず、予算は部門別に分けます。
全社で1つの枠にすると、どこで使われたか分からなくなるからです。
予算の根拠は「1人あたり月〇円 × 人数」で十分で、削減できる時間と比べておきます。

アラートは2段階に置きます。
予算の5割で気づいて、8割で実際に対処するという水準にします。
通知先も決めておきます。
部門の担当と推進チーム、それに部門長にも届くようにします。

あわせて「上限に達したときの動作」も決めておきます。
止まるのか、待たせるのか、承認を求めるのか、あらかじめ選んでおきます。
現実的な運用としては、8割で通知して超過分は承認を求める形です。
完全に止めてしまうと、業務のほうが止まるからです。

承認も3段階に分けます。
予算内は部門の判断で自由に使います。
1.5倍までは部門長の承認、それを超える場合は推進チームと経営の判断とします。
そのうえで「なぜ超えたか」を確認する工程を必ず挟みます。

利用そのものが増えたのか、設計の誤りで無駄な処理が走っているのか。
後者であれば、予算ではなく設計のほうを直します。
つまり、ここを飛ばして予算だけを増やすと、無駄な処理がそのまま固定化します。

展開前の試算は、実測をもとに保守的に出す

この事故を防ぐうえで、いちばん効くのはどの工程になるでしょうか？
展開前の試算です。
もっとも重要なのがこの工程になります。
やることは、展開の前に1件あたりの処理量と想定件数から費用を試算することです。

手順はシンプルで、実際に10件処理してかかった費用を測り、そこに想定件数を掛けます。
一言でいうと、理論値ではなく実測から数字を出すのが要点です。
そして「想定件数は2倍で見る」ようにします。
展開してみると想定より使われることが多いので、保守的に見積もっておきます。

あわせて、自動化の分は別立てで試算します。
人が使う分と自動で走る分を分けて計算するということで、自動の分は件数が読みやすいぶん精度が高く出ます。
この試算を1枚にまとめて、展開の承認と一緒に出しておきます。

あとから請求を見て慌てる事態を防げます。
費用の話だけで終わらせず、効果と並べて見る設計も必要になります。
分子は削減された時間の金額換算で、業務ごとの原単位に件数と人件費単価を掛けたものです。
分母はAIに払っている総額で、定額の分と従量の分の合計になります。

忘れずに「保守の工数」も分母に入れておきます。
仕組みを維持するために使う時間は、集計してみると意外に大きいものです。
目安としては、分子が分母の3倍以上あれば投資として妥当です。
2倍を下回る場合は、対象業務の選び方のほうを見直します。

この数字は、部門別に見ます。
全社平均で見ると、効果が出ている部門の数字に隠れてしまいます。
効果が出ていない部門があれば、そこの使い方に問題があります。
ROIの設計そのものの考え方については、AI推進担当者の情報収集と経営判断。リサーチとROIの設計にまとめてあります。

月次で見るのは4指標。単価の上昇がいちばん見落とされる

導入したあとは、何を継続して見ればいいのでしょうか？
毎月見る指標は、4つに絞っておきます。
「総額の推移」「部門別の内訳」「1件あたりの単価」「予算の消化率」の4つです。
このなかで、もっとも見落とされやすいのが単価です。

総額そのものが増えていても、件数が増えているだけなら問題はありません。
1件あたりの単価が上がっている場合は話が別で、渡す情報が増えているか、高性能なものに寄っているか、設計に問題があります。

AI関数を使う場合の費用の考え方はスプレッドシートのAI関数で終わる業務・終わらない業務、連携そのものの判断はAPIを「窓口」として理解する。ツール連携の判断ができる組織になるで扱っています。

つまずきやすい失敗もまとめておきます。
展開前に試算しない、理論値で試算する、想定件数をそのまま使う、自動化の分を試算に入れない、同じ対象を再処理する設計にする、総額だけを見る、超えた理由を確認せずに予算を増やす、の7つです。
どれも、10件の実測から試算し、想定件数を2倍で見て、自動の分を分けて計算し、処理済みの記録を残し、単価を見て、理由を確認してから予算を判断すれば防げます。

追加費用が発生しない構成を選ぶという手もある

ここまでは費用を管理する話でした。
そもそも従量の費用が発生しない構成を選ぶという手もあります。
法人契約のサービスに含まれる範囲で使えば、利用量に応じた追加の請求は発生しません。

定額の中で使える範囲が広いなら、この構成のほうが管理は楽になります。
現場にとっても、そのほうが使いやすいものです。
「費用がかかるので使いすぎないでください」という制約がないほうが、利用そのものは広がります。

ノーコードの自動化フローを全社に広げていく話については、ノーコードの自動化フローを全社の武器にする。導入の全体像にまとめてあります。

判断の目安は、必要な処理が定額の範囲でできるかどうかです。
とはいえ、独自の開発が必要な処理は従量になります。
文書の要約や分類、下書きの作成といった一般的な用途は、定額の範囲で足りることが多いです。

利用を抑えないと決めたあとは、広がっているかを確かめる手段も要ります。
私たちの組織のAIポータル「AI Portalize」では、GeminiとClaudeの利用について、部署・職種・グレードごとの利用率と前期比が集計の手間なしで出ます。
費用の管理そのものに工数を使いたくない場合は、考え方の参考になるかもしれません。

費用は、見える化と実測をセットにすれば管理できる

請求が膨らむのは、使った瞬間に費用が見えない、展開すると量が急に増える、自動化すると人の意識から外れる、の3つが理由です。
このなかで、もっとも危ないのは自動化の分です。
費用を増やす要因は、渡す情報の多さ、出力の長さ、実行回数の多さ、高性能なものを使うことの4つです。
対処は、渡す情報を絞る、出力の分量を指定する、段階処理で単価を下げる、結果を再利用するの4つで、なかでも段階処理がいちばん効きます。

管理は、部門別の予算、2段階のアラート、上限に達したときの動作、3段階の承認で設計します。
そのうえで、必ず「なぜ超えたか」を確認する工程を挟みます。
それが設計の誤りであれば、予算ではなく設計のほうを直します。

展開前の試算は、実際に10件処理して実測から出し、想定件数を2倍で見ます。
自動化されている分は、人が使う分と分けて別に試算しておきます。

月次で見るのは、総額の推移、部門別の内訳、1件あたりの単価、予算の消化率の4つです。
このなかで、単価がいちばん見落とされます。

そもそも従量の費用が発生しない構成を選ぶという手も、あわせて検討しておきます。
一般的な用途であれば、定額の範囲で足りることが多いからです。
直近で検討している処理を10件実行して費用を実測すれば、予算の精度は一段上がります。