CData のAI 導入の意思決定者向け解説シリーズへようこそ。米国版では毎週火曜日と木曜日に公開される全8回のシリーズで、いま業界で注目を集めているアーキテクチャ概念「AI Gateway」を、基礎から順を追って取り上げていきます。この概念がなぜ登場したのか、どんな課題を解決するために設計されたのか、まだ足りていない部分はどこか、そして貴社の広範なAI インフラ戦略にどう組み込めるのかを解説していきます。第1回となる本記事では、その需要を生んだ根本原因、つまり「なぜこれほど多くのエンタープライズAI が予算を超過し、期待された成果を出せずにいるのか」から始めましょう。

エンタープライズAI は、本来なら予測しやすい道筋をたどるはずでした。パイロットで価値を実証し、段階的に展開を広げ、ROI で投資を正当化する、という流れです。しかし現実に多くの組織が直面しているのは、本番環境のAI がきわめて高コストで、支出の見通しが立てにくく、そしてほとんどの場合、ガバナンスがまったく効いていないという事実です。マッキンゼーによるエンタープライズAI FinOps 調査（2026年5月、5つの主要業界から75社が回答）では、93％の組織がすでにAI 予算を超過しており、適用範囲が個別のユースケースから全社規模へ広がるにつれて支出が4倍近くまで膨らむことが明らかになりました。しかも、そのうち62％はすでに実験段階を脱しています。つまり、難しいのはAI を本番環境に載せることではありません。本当の問題は別のところにあります。本番環境のAI が、誰も十分に想定していなかった額の請求書を生んでいること。そして、その理由をほとんどの組織が次の調達サイクルまで把握できないことです。

本記事では、エンタープライズAI のコスト超過を生んでいる3つの構造的なギャップと、それを解消するために必要なアーキテクチャの見直しについて考えます。

AI 予算の危機は、パイロット段階ではなく本番環境で起きている

いま多くの企業が、ある同じ局面にさしかかっています。AI はすでに本番で稼働し、エージェントも動き、最初の調達サイクルがひと通り終わった段階です。ところが、経営陣が有望なインフラ投資として承認したものが、想定を超える請求額になっています。しかもその理由は、説明を求められたチームにとってもはっきりしません。

この状況を難しくしている要因の一つは、AI の価格構造が従来のエンタープライズソフトウェアのどのカテゴリーとも異なる点です。ユーザーライセンス型であれば、費用はあらかじめ見通せます。しかし従量課金では、そうはいきません。同じタスクでも、ワークフローやプロンプトの組み立て方、入力するデータによって、トークン消費量は最大30倍も変動します。これでは財務チームがコストを見積もるのは難しく、仮に見積もれたとしても、その利用がどんな価値を生んでいるのかまでは把握しきれません。

さらに、支出が複数の場所に散らばっているため、全体像がつかめません。マッキンゼーの調査では、AI 関連支出の20～30％がクラウドプロバイダー、モデルベンダー、ソフトウェアプラットフォーム、検証環境、各事業部門などに広がり、横断的に見る仕組みがないまま日常的に見落とされていることがわかりました。

個別の事例を見ると、その広がり方がよく分かります。あるプロジェクトで予算を洗い出したところ、エンタープライズ向けコパイロット、基盤モデルの契約、AI 搭載のソフトウェア機能、API ベースのサービス、事業部門による個別購入にまで、コストが及んでいることが判明しました。しかも、そのどれもが一元的に管理されておらず、全体を照合できる場所がどこにもありませんでした。

こうした状況を受けて、社内のAI 利用状況ランキングの公開をやめ始めた組織もあります。この2年間続いてきた「とにかく前へ」という勢いは、財務部門が初めて本格的に請求書へ目を向けたことで、いま壁に突き当たりつつあります。

ルーティングのギャップ：ありふれた処理に最先端モデルの料金を払っている

インテリジェントなルーティング層がなければ、エージェントからのリクエストはすべて同じ最先端モデルに流れ込みます。それが複雑な多段階の推論であろうと、もっと速くて安いモデルで十分こなせる単純なデータ検索であろうと、扱いは変わりません。マッキンゼーはこの点をはっきり指摘しています。最先端モデルの料金に見合うタスクは実際にはごくわずかであり、最大の削減効果は、モデルの料金を交渉することではなく、トークンを消費するシステムそのものを最適化することから生まれるといいます。

ルーティングの研究も、これを具体的な数字で裏づけています。RouteLLM（ICLR 2025）の研究によれば、適切に学習させた複雑度ベースのルーティングは、最先端モデルの性能の95％を保ちながら、高コストモデルへ回すリクエストを14～26％に抑え、ルーティング対象のワークロードのコストを75～85％削減できました。ところが、そのためのルーティング層を用意できている組織はまだ少なく、多くはこの水準に届いていないのが実情です。何も設定しなければ、処理はすべてモデル階層の最上位へ送られます。そして、その既定の状態こそがコストを押し上げます。

エージェント型ワークフローは、この問題を多くのチームの想像よりずっと速く悪化させます。1回のやり取りで10回のモデル呼び出しが発生するワークフローは（予算上は1回のつもりだったとしても）、ルーティングの問題をそのまま10倍に膨らませます。本番でエージェントを動かしている組織にとって、モデル選択は打てる施策のなかで最も効果の大きいものです。それでも多くのチームには、その選択を動的に切り替える仕組みがなく、結果としてあらゆるケースで最先端モデルの料金を払い続けることになっています。

データアクセスのギャップ：不要なスキーマまで渡してコンテキストが膨らむ

データアクセスのギャップはルーティングほど目立ちませんが、データ集約型のワークフローでは、より大きな無駄を生むことが少なくありません。AI エージェントがスキーマを理解したアクセス層を通さずに企業データを取得すると、システム全体のスキーマ、フィルタリングされていないレコードセット、周辺のメタデータまで、あらゆるものを受け取ってしまいます。実際のリクエストで必要だったのはそのごく一部だったとしても、モデルはその全体を処理します。コンテキストウィンドウに載った不要なトークンの一つひとつが、エージェントが最初から必要としていなかったデータへの支払いになります。

マッキンゼーは、その解決策を明確に示しています。「プロンプトを短縮し、コンテキストウィンドウを制限し、ドキュメントやツール出力の関連部分のみを渡す……静的なプロンプトコンテキストを再利用することで、特に検索拡張生成（RAG）や、大規模で安定したプレフィックスを持つエージェントにおいて、入力トークンのコストを最大約90％削減できる。」ガバナンスの効いたデータアクセス層は、この原則をアーキテクチャとして実装したものです。スキーマの理解も、返すデータを必要な範囲に絞ることも、開発者一人ひとりがリクエストのたびに手作業で調整するのではなく、インフラのレベルで確実に効かせるという考え方です。

ツールの設計次第で、削減効果はさらに上乗せできます。ツール呼び出しの時点でリクエスト元ユーザーの権限に応じたフィルターをかけ、集計や複数システムをまたぐ結合といった重い処理を、モデルに渡る「前に」済ませておくとします。するとモデルが受け取るのは、そのユーザーに閲覧権限のあるレコードのうち、質問に答えるのに必要な最小限のデータだけになります。これで、範囲外のデータを処理するトークンコストと、モデルが権限外のレコードを表に出してしまうリスクが、どちらも解消されます。1つのアーキテクチャ上の工夫で、2つの問題が同時に解決するわけです。CData 独自のベンチマークでは、ガバナンスを効かせたマルチソースのエンタープライズクエリで、フィルタリングなしのアクセスと比べてトークン消費量が97.6％削減されました。これはマッキンゼーが説明しているのとまったく同じ考え方です。リクエストに必要なものだけを送り、そのユーザーが見てよい範囲に絞り込む、ということです。

ガバナンスのギャップ：見えない支出と、説明責任の不在

マッキンゼーによると、成熟したAI FinOps の体制を整えている企業はわずか20～25％です。多くの組織では、コスト超過に気づくのは請求書が届いてからです。つまり、手を打てるタイミングをすでに過ぎているということです。

責任の所在があいまいなままだと、日々の運用で次のような問いに答えられなくなります。先月の超過分はどのチームが使ったのでしょうか。どのエージェントワークフローが不必要に500回もループしたのでしょうか。ユースケースに必要だったのは12行だけなのに、5万行を返してきたのはどの取得処理でしょうか。リクエスト単位で、チーム・ユースケース・ワークフローごとに支出を紐づける仕組みがなければ、無駄の出どころを突き止めることも、同じことを繰り返さないようにすることもできません。コスト帰属（どの支出が誰のものかを紐づける仕組み）は最適化に取りかかるための前提条件であり、体制が整ってから付け足せばよいレポート機能ではありません。

マッキンゼーが勧めているのは、個々のチームの行動変化に頼るのではなく、AI Gateway、コントロールプレーン、ポリシーエンジン、自動化されたガードレールを使って、ガバナンスをアーキテクチャに組み込むことです。あわせて、成果あたりのコスト指標（処理したクレーム1件あたり、解決したリクエスト1件あたり、顧客とのやり取り1回あたりのコスト）への移行も推奨しています。ここまで踏み込むには、単にAPI 利用料を合計するだけでなく、AI の利用実績を具体的なビジネス活動に結びつけられるインフラが要ります。測定の仕組みとガバナンス層は、別々の要件ではありません。どちらも同じ一つの基盤です。

コストを制御できている組織は、実際どうしているのか

マッキンゼーが調査した組織のおよそ3分の1は、積極的な最適化によってすでに20～30％のコストを削減しています。こうした組織とそれ以外を分けているのは、規律ではありません。アーキテクチャです。ガバナンスがシステムに組み込まれていて、費用が使われてしまった後に、レポート機能として後から足すものではありません。

コストを制御できている組織のAI 基盤には、4つの構造的な要素が共通しています。1つ目は、複雑さとコストに応じてリクエストを適切なモデルへ振り分けるインテリジェントなルーティングです。2つ目は、リクエストに必要な範囲だけを権限フィルターを通して返す、スキーマを理解したデータアクセスとツールです。3つ目は、トークンの一つひとつをチーム・ワークフロー・ユースケースに紐づけるコスト帰属です。そして4つ目が、暴走した支出を来月の請求書に載る前に表面化させる予算ガードレールです。目に見えるコスト削減を実現している組織は、これらを、余力ができたときに順番に取り組む4本のプロジェクトではなく、インフラとして扱っています。

そこで登場するのがCData Connect AI です。Connect AI は、単一のMCP 準拠インターフェースを通じて、数百のエンタープライズデータソースに対し、スキーマを理解した権限フィルター済みのアクセスを提供します。これにより、データ量の多いクエリでコンテキストが肥大化するのを抑えられます。さらにリクエストごとの監査ログが残るため、データ層でのコスト帰属も可能になります。コスト効率と説明責任のインフラが同じアーキテクチャ層で実現されるため、チームはどちらかを選ぶ必要がありません。

AI ガバナンスインフラのビジネスケースを組み立てる

マッキンゼーは、数字を率直に示しています。予測の成熟度が高い組織は同業他社より10％多くAI コストを削減できており、積極的に最適化している組織では、20～30％の削減を実現しています。AI に年間500万ドルを投じている企業なら、100万～150万ドルが取り戻せる計算です。問うべきは、ガバナンスインフラにコストがかかるかどうかではありません。もちろんかかります。重要なのは、そのコストが、ガバナンスによって防げる無駄より小さいかどうかです。

ここで多くのエンジニアリングチームが直面するのが、「内製か、外部調達か」という判断です。コスト帰属、ルーティングロジック、スキーマを理解したデータアクセスを内製するには、相応の工数がかかります。しかもモデルAPI の変更、スキーマの進化、エージェントアーキテクチャの移行に合わせて、保守し続けなければなりません。この負担は、データソース、モデルプロバイダー、本番ワークフローが増えるたびに重くなります。実際に内製したチームからは、変更に弱いシステムになってしまったという声が聞かれます。いま使っているモデルに合わせて作り込まれているため、半年後にもっと安い選択肢が現れても乗り換えられなくなります。

マッキンゼーは、常設のAI FinOps 機能を立ち上げることを勧めています。需要を予測し、利用状況を監視し、最適化の余地を見つけ、成果あたりのコストを追う、部門横断のチームです。整備されたガバナンスインフラは、そのチームの活動を支える基盤になります。あわせて、特定のモデルやベンダーへのロックインを防ぐ効果もあります。モデルを取り巻く状況は、この18か月だけを見ても大きく変わりました。ガバナンスインフラを整えている組織は、より優れた、あるいはより安い選択肢が現れたときにワークロードを移せます。整えていない組織は、そのまま同じモデルを使い続けるほかありません。

よくある質問

データアクセス層で、エンタープライズAI のトークンコストを削減する

CData Connect AI は、コンテキストの肥大化をデータソースの段階で解消するエンタープライズAI 向けデータゲートウェイです。単一のMCP 準拠インターフェースを通じて、数百のエンタープライズデータソースに対し、スキーマを理解した権限フィルター済みのアクセスを提供します。どのリクエストも、モデルが必要とするデータだけを返し、コスト帰属のための監査ログを漏れなく残します。

※本記事はCData US ブログ Why Enterprise AI Is Over Budget | CData の翻訳です。