AIベンダーを変更できない企業が約7割。「AI主権」をアーキテクチャから考える

AI活用が進むにつれて、新しい問題が見え始めています。

それは、

「導入したAIを、あとから自社の意思で変更できるのか」

という問題です。

マイナビニュースで紹介されたIBM Institute for Business Valueの調査では、日本企業の69%が主要なAIベンダーやモデルの切り替えを困難と感じているという結果が出ています。

さらに、89%がAIベンダー・モデル・インフラ間の依存関係を十分把握できていないとされています。

この問題は「ベンダーロックイン」という言葉でも説明できます。

しかしAIの場合、従来のベンダーロックインより少し複雑です。

今回はこれを「AI主権」という観点から、特にEnterprise Architecture（EA）との関係を考えてみます。

AI主権とは「全部内製すること」ではない

まず、ここでいうAI主権を、

「自社でLLMを開発すること」

「すべてオンプレミスで動かすこと」

「外部ベンダーを使わないこと」

とは考えていません。

むしろ重要なのは、

必要になったとき、自社の意思で選択肢を変更できること

だと考えています。

例えば、

GPT系からClaude系へ変更できる
クラウドLLMからローカルLLMへ変更できる
RAGの検索基盤を変更できる
Agent Frameworkを変更できる
開発ベンダーを変更できる

といったことです。

外部サービスを利用していても、これらを自社の判断で選択できるのであれば、主導権は自社にあります。

逆に、システムを所有していても、

「なぜこの構成なのか分からない」

「このモデル以外では動かない」

「変更するには現在のベンダーに頼むしかない」

という状態なら、実質的な主導権を持っているとは言いにくいでしょう。

これはEAが昔から扱ってきた問題でもある

ここでEnterprise Architecture（EA）を考えてみます。

EAでは企業システムを、

インフラ
データ
アプリケーション
プレゼンテーション

などの領域・レイヤーに分けて整理してきました。

もちろんEAの体系や分類方法によって表現は異なりますが、アーキテクチャ設計において重要な考え方の一つは、

ある部分の変更がシステム全体を道連れにしないようにすること

です。

例えば、

インフラを変更しただけで、すべてのアプリケーションを書き直す。

データベースを変更しただけで、すべての画面を作り直す。

これではシステムを継続的に変化させることができません。

そのため責務を分離し、インターフェースを定義し、変更の影響範囲を限定します。

言い換えると、

「交換可能性」をアーキテクチャによって確保する

という考え方です。

AI主権について考えていると、これは従来のEAが扱ってきた問題とかなり近いことに気づきます。

ただし「AIレイヤー」を追加するだけでは足りない

では、従来のアーキテクチャに「AI層」を一つ追加すればいいのでしょうか。

私は、それでは不十分だと考えています。

AIは一つのレイヤーに閉じないからです。

例えば生成AIを組み込んだ業務システムを考えてみます。

Infrastructure

GPU
Cloud
Container
推論基盤
Local LLM実行環境

Model

GPT系
Claude系
Gemini系
OSS LLM

Data / Knowledge

RAG
Vector Store
Knowledge Graph
RDB
Document Store

Application

AI Agent
Workflow
Tool Calling
業務ルール
API連携

Presentation

Chat UI
Voice UI
Copilot型UI
Generative UI

AIはインフラからプレゼンテーションまで入り込みます。

さらにAIエージェントでは、一つのアプリケーション内部でAIを利用するだけではありません。

AIが、

情報を取得する
内容を判断する
次の行動を決定する
外部システムを操作する
結果を別のシステムへ記録する

といった動きをするようになります。

つまり、複数のアプリケーションやデータを横断する存在になります。

従来の縦方向のレイヤーだけでは、AIシステムの依存関係を表現しにくくなってきています。

AIを「製品」ではなく「能力」として分解する

そこで必要になるのではないかと考えているのが、

従来のレイヤー分離に加えて、AIを構成する「能力」を分離する

という考え方です。

例えば次のように考えます。

能力	役割	交換対象の例
推論能力	入力から回答・判断を生成	GPT / Claude / Gemini / Local LLM
知識取得能力	外部・社内情報を取得	RAG / SQL / Graph / Search
計画能力	タスクを分解し次の行動を決定	Agent / Workflow
ツール実行能力	外部システムを操作	API / MCP / Connector
記憶能力	状態・履歴を保持	RDB / Vector DB / Graph DB
UI能力	人間とのインターフェース	Chat / Voice / GUI
実行基盤	AIを実行する	Cloud / On-premise / Local

ポイントは、

「どの製品を使うか」と「その製品が担っている能力」を分離して考えること

です。

例えば「GPTを使う」と設計するのではなく、

「推論能力が必要であり、現在はGPTを実装として採用している」

と考えます。

この違いは小さく見えますが、アーキテクチャとしてはかなり重要です。

「GPTを使う」と「推論能力にGPTを使う」は違う

例えばシステム全体が、次のように密結合していたとします。

業務処理
   ↓
GPT API
   ↓
GPT固有レスポンス
   ↓
業務ロジック

この場合、GPTを変更すると業務ロジックまで影響する可能性があります。

一方、

業務処理
   ↓
Inference Interface
   ↓
┌─────────────────┐
│ GPT Adapter     │
│ Claude Adapter  │
│ Local Adapter   │
└─────────────────┘

のように「推論能力」として境界を作っておけば、交換しやすくなります。

もちろん現実には、モデルごとに、

Context Window
Tool Calling
Structured Output
Reasoning特性
Multimodal能力
Token体系
Safety制約

などが異なるため、完全に同じインターフェースで抽象化できるわけではありません。

何でも抽象化すればよいわけでもありません。

重要なのは、

「どこを交換可能にしたいのか」を意図して設計していること

です。

AIでは交換可能性が従来以上に重要になる

従来の業務システムなら、一度導入した製品を5年、10年利用することも珍しくありません。

しかしAIでは、技術の変化が非常に速い。

数か月前まで最有力だったモデルより、別のモデルが特定用途で大幅に優れることもあります。

Agentの実装方式も変わります。

RAGの構成も変わります。

ローカルで動かせるモデルの能力も上がっていきます。

そのため、

「現在最も優れたAIを選ぶこと」

だけでは不十分です。

むしろ、

「もっと優れたAIが登場したとき、それへ乗り換えられること」

の価値が大きくなります。

AI主権は「技術的交換可能性」だけでもない

ただし、ここでもう一段問題があります。

システムが技術的に交換可能でも、

「何に変更すべきかを自社で判断できない」

のであれば、主導権を持っているとは言えません。

例えばベンダーから、

「このLLMが最適です」

と言われても、なぜ最適なのか判断できない。

「RAGが必要です」

と言われても、本当にRAGが必要なのか判断できない。

「Agent化しましょう」

と言われても、どこまで自律実行させるべきなのか判断できない。

この状態では、技術的なロックインを解消しても、

意思決定能力がベンダーへロックインされています。

私はAI導入における丸投げを、

丸投げは、コストの外注ではない。意思決定能力の外注である。

と考えています。

外部の専門家を使うことが問題なのではありません。

判断材料や高度な専門能力を外部から調達しながら、

最終的な選択を自社で行える状態を維持すること

が重要なのだと思います。

良いベンダーとは「交換できるベンダー」なのかもしれない

ここまで考えると、ベンダーの評価方法も少し変わってきます。

私が以前から考えているのが、

良いベンダーとは、最も自分たちを不要にする支援ができるベンダーである。

ということです。

これはベンダーを使わないという意味ではありません。

良いベンダーであれば、

設計思想を残す
技術選択の理由を残す
依存関係を明確にする
運用方法を残す
変更方法を残す
顧客へ知識を移転する
可能な部分を交換可能にする

ところまで支援する。

その結果、

「このベンダー以外には頼めない」

ではなく、

「他にも頼めるが、このベンダーが一番良いので頼む」

という関係になります。

囲い込みによる継続契約ではなく、専門性によって継続的に選ばれる。

AIの変化が速くなるほど、こちらの方が健全な関係ではないでしょうか。

AI時代のEAには何が必要になるのか

ここまで整理すると、従来のEAの考え方が不要になるわけではありません。

むしろ逆です。

「変更可能性をアーキテクチャとして確保する」という思想は、AI時代ほど重要になる

と思います。

ただし、AIは既存の複数レイヤーを横断します。

そのため、従来の、

Infrastructure
      ↓
Data
      ↓
Application
      ↓
Presentation

という一方向の見方だけではなく、

              AI Capability
                    │
        ┌───────────┼───────────┐
        ↓           ↓           ↓
Infrastructure → Data → Application → Presentation
        ↑           ↑           ↑
        └───────────┼───────────┘
                    │
              AI Capability

というように、

既存のArchitecture × 交換可能なAI Capability

という二つの軸で捉える必要が出てくるのではないでしょうか。

さらに、必要なのは技術的な交換可能性だけではありません。

Technical Portability
        ＋
Decision Sovereignty

つまり、

技術を変更できること

と、

何に変更するかを自社で判断できること

の両方を設計する。

これがAI時代のEnterprise Architectureに必要になる考え方の一つではないか、と考えています。

まとめ

AI主権を「AIを自社保有すること」と捉えると、本質を見失います。

重要なのは、

選択できることです。

モデルを変えられる。

ベンダーを変えられる。

実行基盤を変えられる。

必要なら外部へ依頼できる。

そして、それらを自社で判断できる。

AIの進化が速ければ速いほど、

「何を選んだか」以上に「後から選び直せるか」

が重要になります。

従来のEAがシステムを変更可能にするためにレイヤーや責務を分離してきたように、AI時代にはモデルや製品ではなく「能力」の交換可能性まで含めてアーキテクチャを考える必要があるのかもしれません。

AI主権とは、経営だけの話でも、契約だけの話でもありません。

アーキテクチャそのものの問題でもある。

私はそう考えています。

このテーマについて、経営・ベンダー選定まで含めてもう少し広い視点からnoteでも書いています。

AIベンダーを変更できない企業が約7割。「AI主権」はこれから経営課題になる