AIは安い代替だという前提が崩れています
生成AIを検討する多くの発注側は、AIを人の安い代替として見ています。人を採ると高い、AIなら同じ仕事を安く回せる。導入の動機は、たいていこの期待から始まります。
ところが、この前提はいま崩れかけています。米国のベンチャーキャピタルa16zが引用したデータでは、企業のトークン支出が月あたり14.1%のペースで増え続け、ソフトウェアエンジニアの人件費を年およそ19万ドルと置いて比較すると、複雑で大量の処理をエージェントに任せた場合にトークン費が人件費を上回りうる、という指摘が示されています。同じデータでは、AIを活用する企業がこの24か月で従業員数を10.2%増やしたという見方もあります。AIで人が減るどころか、むしろ増えているという指摘です。
これらの数値は、AIやトークンを提供する側の視点を含み、ポジショントークの面もあります。発注側がそのまま鵜呑みにする数字ではありません。ただ、示している方向は実務の感覚と一致します。コードを書く「作る費用」は下がっても、AIを「動かし続ける費用」は使うほど積み上がる、という構造です。
だから、AI導入の費用は初期の開発費ではなく、運用でどれだけトークンを使い続けるかで決まります。安い代替を探す発想のままだと、この運用費を見落とします。
運用費が跳ねるのは、トークン消費が積み上がる構造だからです
トークン課金は従量制です。費用は「1回の処理で使うトークン量」と「実行回数」の掛け算で決まります。どちらも、エージェントに複雑で大量の処理をさせるほど大きくなります。
1回あたりのトークンは、処理が複雑になるほど跳ねます。長い文脈を読み込ませる、外部ツールと何度も往復する、失敗して再試行する、複数の手順を順に推論させる。人が一度質問して一度答えを受け取るのと違い、エージェントは内部で何度もやり取りします。その往復がすべてトークンとして課金されます。
実行回数は、対象業務の規模でそのまま効きます。PoCでは数十件でも、本番では月に数万件を自動で処理します。しかも精度を上げようとすると、確認の工程や参照する情報が増え、1回あたりのトークンはさらに膨らみます。品質と運用費は、多くの場合トレードオフの関係にあります。
運用費が跳ねる要因を分けると、次のようになります。
- 文脈の長さ: 参照する資料や履歴が長いほど、1回の入力トークンが増える
- ツールの往復: 検索や外部システムの呼び出しを繰り返すほど、回数分だけ課金される
- 再試行と多段推論: 失敗時のやり直しや複数手順の思考が、見えないところでトークンを積む
- 処理件数と頻度: 対象業務の規模と実行頻度が、月次の総量を押し上げる
初期費用は一度払えば終わりますが、運用費はこの構造で毎月積み上がります。
PoCは安く見えても、動かし続ける費用は本番で逆転します
PoCの段階では、運用費はほとんど気になりません。対象が小さく、実行回数も少ないため、トークン費は誤差の範囲に収まります。ここで「AIは思ったより安い」と感じてしまうことが、後の判断を狂わせます。
本番は事情が違います。処理件数、実行頻度、常時稼働が掛け合わさり、運用費が総額の主役になります。初期の開発費より、動かし続ける費用のほうが大きくなる。稼働してから想定外の請求に気づくのは、この逆転を見積もりに入れていなかったからです。
| 観点 | PoC | 本番 |
|---|---|---|
| 処理件数 | 数十件の試行 | 月に数千〜数万件 |
| 実行頻度 | 手動で随時 | 自動で常時、またはバッチ |
| 主なコスト | 初期の構築費 | 運用のトークン費 |
| 費用の見え方 | 安く見える | 使うほど積み上がる |
見積もりが「作る費用」だけで組まれていると、この右の列が見えません。総額を決めるのは初期費用ではなく、運用の単価と量です。「作る費用」の相場は適正価格の見方で整理していますが、発注時にはそこへ運用費の試算を必ず重ねてください。
どこまでAIに任せ、どこから人間が担うかを要件定義で決めます
運用費を抑える最大のレバーは、すべてをAIに任せないことです。どの作業をAIに任せ、どこから人間が担うかを、要件定義の段階で決めます。この切り分けは機能の設計であると同時に、費用の設計でもあります。
単純で定型的な作業や、間違えても影響の小さい処理はAIに向きます。逆に、判断を伴う工程、例外の多い処理、間違えると損害の大きい業務は、人間が受けたほうが安全で、結果として安く済みます。複雑な処理をエージェントに丸ごと任せるほどトークンは跳ねるので、切り分けを曖昧にしたまま進めると、運用費は読めなくなります。
要件定義で決めておく項目は、次のとおりです。
- AIに任せる作業の範囲と、1件あたりの想定トークン量
- 月間の処理件数と実行頻度(常時稼働か、バッチ処理か)
- 人間が確認・判断する境界と、その担当
- トークン消費の上限とアラート(想定を超えたら止める仕組み)
AIに任せる範囲と人が確認する範囲を分ける考え方は、AIネイティブ開発でも説明しています。利用範囲を先に決めることが、運用費を予測可能にする第一歩です。
弊社は運用コストを含めて設計します
弊社は、要件定義の段階で、発注側と一緒に利用範囲と運用コストを決めます。どの作業をAIに任せるか、月間でどれだけの量を処理するか、1件あたりどの程度のトークンを使うか。これらを見積もりに入れ、初期費用だけでなく、動かし続ける費用まで含めて設計します。
PoCも、本番の縮小版として、運用時の単価と量が読める形で検証します。小さく試して効果とリスクを確かめる進め方は、PoC止まりを防ぐAI開発の進め方で詳しく説明しています。精度が必要な工程を絞り、それ以外は軽い処理で回すことも、運用費を抑える設計の一部です。
運用が始まってからも、トークン消費を監視し、想定と実績のズレを見ながら範囲を調整します。作って納めて終わりにせず、動かし続ける費用まで面倒を見る。これが、AI導入を「安い代替」で終わらせないための進め方です。
AIの費用が想定より膨らむ、あるいは発注前に運用費を見積もっておきたい。当てはまるなら、まず対象業務を一つ決め、AIに任せる範囲と処理量を洗い出してください。運用コストを含めた設計のご相談は、お問い合わせからお聞かせください。
