統合税:企業のAIが本当に支払うコスト

モデルはいちばん安い部分だ

AIベンダーの価格構造は、組織がプログラムのコストを見積もるやり方に系統的な歪みを生む。モデルの推論コストは目に見え、予測でき、下がりつづけている。ベンダーの提案書にはっきり載り、将来分を引き延ばして計算するのも容易だ。一方、モデルを依存先のシステムにつなぐために必要なエンジニアリング作業は、ベンダーの価格表にはまったく出てこない。

大規模な企業導入におけるAIプログラムのコスト構造に関するGartnerの分析によれば、導入が本番規模に達した時点で、統合とデータエンジニアリングが総プログラムコストの40〜60%を占める。これは多くのプログラムで単独最大のコスト要素であり、しかも多くの事業計画では、根拠のある見積もりではなく仮置きの数字で埋められている可能性がもっとも高い項目でもある。

L.E.K. Consultingの2025年 Office of the CFO 調査では、AIの価値実現を妨げる要因として最も多く挙げられたのが統合の失敗であり、モデルの性能、現場の定着、予算制約よりも上位だった。技術は動いていた。それを取り巻く基盤が支えられなかった。

---

レガシーシステムが必ず過小評価される理由

企業の基幹システムの多くを作った技術者は、もうそれを動かしている会社にいない。それらのシステムの文書は不完全か、内容が食い違っているか、2017年に置き換えられた版を説明している。APIは、あったとしても当時存在した統合のために作られたものであり、AIが求めるリアルタイムで大量の構造化データアクセスのために作られてはいない。

そこから、AI統合の作業中に決まった順序で発見が起きる。第一の発見は、AIが必要とするデータは存在するが、必要な形では存在しないということ。第二は、正しい形で使えるようにするには、基幹ERP、財務元帳、顧客記録といった、組織的リスクが不釣り合いに大きいシステムに手を入れる必要があり、そこでは変更管理の期間がスプリントではなく四半期で測られるということ。第三の発見は、AIが依存するフィールド単位で見たときのそれらのシステムのデータ品質が、プロジェクト前のどの監査が示したよりも低いということだ。

どれも珍しいことではない。10年以上運用されてきた組織における、企業データ基盤のごく普通の状態である。珍しいのは、それを途中で発見するコストではなく、あらかじめ分かっているコストとして扱うほうだ。

---

事業計画が見落とす4つの統合コスト

事後検証には出てくるのに事業計画には出てこない統合コストには、一貫した型がある。

データの準備と洗浄。 AIモデルの出力は、入力の品質に見合ったものにしかならない。多くの企業導入では、モデルが要求する品質水準までデータを整えること自体が独立したプログラムになる。ソースシステムの棚卸し、重複排除、正規化、そしてパイプラインの継続的な保守である。この作業がAIのパイロットに予算がつく前に終わっていることはまれで、終わっている場合でもほぼ必ず過小に見積もられている。

認証とアクセス制御。 企業システムはデータを自由に共有しない。権限構造、監査要件、アクセス制御があり、いずれもAIのサービスアカウントを想定して作られていない。AIをこれらのシステムにつなぐにはセキュリティアーキテクチャの作業が要り、時間がかかり、規制産業ではコンプライアンス審査も伴う。これはどのモデルベンダーの価格表にも載っていない。

ソースシステム側の変更管理。 AI統合のためにソースシステムの動きを変える必要が生じたとき、つまりAPIの変更、イベントトリガーの追加、データ構造の改変といった作業は、そのシステムの変更管理の待ち行列に入る。大きな組織ではその行列は長く、先頭に並んでいるシステムがAIプログラムの必要とするものであることはまれだ。ソースシステムの変更がプログラムの都合どおりに進むという前提で組んだ工期見積もりは、いつも外れる。

継続的な監視とドリフト管理。 モデルが本番に入ったあと、統合が無料になるわけではない。ソースシステムのデータは変わる。上流のAPIはバージョンが上がる。入力の分布が動けばモデルの出力もずれていく。統合レイヤーの監視と保守は継続的なエンジニアリングコストであり、多くの事業計画は稼働開始後についてこれを無視できるものとして扱う。

---

地に足のついた事業計画とはどんなものか

プログラム開始前に統合を正確に値付けできている組織は、ベンダー価格からではなくシステムアーキテクチャから始めている。

事業計画を出す前に問うべきは、このAIはどのソースシステムに、どんな形で、どれだけの遅延で接続する必要があるのか、そしてそれらのシステムのデータ品質とAPIの表面は今どういう状態か、である。この分析が、実際の統合スコープと実際のコスト見積もりを生む。同時に、どのモデルを選ぶかという判断よりもプログラムの日程を左右することになるソースシステム側の制約を、早い段階で表に出す。

長い作業ではない。ベンダー選定の前に行う2日間のシステムアーキテクチャレビューがあれば、制約のない事業計画を、守れるコスト構造を持つものに変えるには十分だ。この工程を飛ばした組織がコストを免れるわけではない。プログラムがすでに走り出し、対処の選択肢がかなり狭まったあとで、それを発見することになる。

---

調達にとっての意味

統合税は、企業がAIを調達するやり方に直接はね返る。統合の複雑さを勘定に入れず、モデルの性能とライセンス費用でベンダーを選べば、予算を承認した人たち以外の誰も驚かないコスト構造ができあがる。

AIプラットフォームを実装リスクで、具体的には自社が実際に動かしているソースシステムにどれだけきれいに速くつながるかで評価する調達プロセスは、モデルのベンチマークだけで評価するプロセスよりも良い結果を出す。主要プラットフォームのモデル能力は収束しつつある。各社が提供する統合の表面と、それを支えるプロフェッショナルサービスの生態系は、かなり分かれている。

企業AIから最も多くの価値を引き出している組織は、それらのモデルを自社の事業につなぐことが実際に何を要求するのかを正確に把握したうえでプログラムに入り、その要件を最初からプログラムに織り込んだ組織だ。モデル自体の性能が決め手になることはめったにない。

---

統合税は、見つけるのが難しいという意味での隠れたコストではない。調達プロセスの中に、それを早く表に出す動機を持つ者が誰もいないという意味で隠れている。ベンダーはモデルのコストを見積もる。システムインテグレーターは、まだ定義されていないスコープに対して実装コストを見積もる。社内チームは楽観シナリオで見積もる。それが予算のつく見積もりだからだ。

結果として生まれるのが、本番運用に対して構造的に予算不足で、日程に対して構造的に約束しすぎたプログラムである。事業計画を正しく組むのに、新しい道具も新しい方法論も要らない。要るのは、ベンダーへの問いより先に基盤への問いを立てること、そしてその答えを脚注ではなく制約として扱うことだ。