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が、

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

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

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

従来の縦方向のレイヤーだけでは、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主権」はこれから経営課題になる