企業向けAI Gatewayの設計と実装
生成AIを業務システムに組み込む際、「どのLLMを使うか」という問題は以前より複雑になっています。
OpenAI、Anthropic、Googleなどが提供するクラウドLLMに加え、DeepSeekやQwenなど選択肢は急速に増えています。さらに、企業内の機密情報を外部サービスへ送信したくないという理由から、Ollama、llama.cpp、vLLMなどを使ってローカル環境にLLMを配置するケースも増えてきました。
選択肢が増えること自体は歓迎すべきことです。しかし、企業システムとして見ると新しい問題が発生します。
- アプリケーションごとに異なるLLM APIを実装するのか
- 各サービスのAPIキーをどう管理するのか
- 誰がどのLLMを利用できるのか
- 利用量とコストをどう把握するのか
- 機密データをクラウドLLMへ送信してよいのか
- 社内のローカルLLMを誰が利用しているのか
- モデルが増えたとき、どう選択するのか
LLMを1つ導入するだけであれば、これらは大きな問題にならないかもしれません。
しかし、複数のクラウドLLMとローカルLLMを同時に利用し始めると、「LLMそのもの」ではなく、「LLMを管理する基盤」が必要になってきます。
本記事では、筆者らがLykuro AI Gatewayを開発する中で直面した課題を題材に、クラウドLLMとローカルLLMを一元的に管理するAI Gatewayの設計について紹介します。
1. なぜ今、AI Gatewayが必要なのか
一般的なLLMの利用は、アプリケーションからモデル提供事業者のAPIを直接呼び出す形から始まります。
たとえば、次のような構成です。
Application
|
+----> OpenAI API
|
+----> Anthropic API
|
+----> Gemini API
PoC段階ではこれでも十分です。
しかし、本番システムでモデルを増やしていくと問題が出てきます。
各プロバイダーには、
- API仕様
- モデル名
- 認証方式
- ストリーミング形式
- Tool Calling
- JSON出力
- Rate Limit
- 料金体系
などの違いがあります。
アプリケーション側でこれらを個別に実装すると、モデルを追加するたびに改修が必要になります。
そこで、アプリケーションとLLMの間にAI Gatewayを配置します。
Application
|
v
+------------------+
| AI Gateway |
+------------------+
| | |
v v v
OpenAI Claude Gemini
アプリケーションはGatewayだけを呼び出し、実際にどのモデルへ接続するかはGateway側で管理します。
この構成にすると、LLMの違いをアプリケーションから切り離せます。
ただし、企業利用ではこれだけでは足りません。
実際には、
Application
|
v
+----------------------+
| AI Gateway |
| |
| Authentication |
| RBAC |
| Rate Limit |
| Model Routing |
| Usage Control |
| Audit Log |
+----------------------+
| |
v v
Cloud LLM Local LLM
のように、AI Gatewayそのものが「AI利用のControl Plane」として機能する必要があります。
2. 企業でLLMを利用すると「管理」が問題になる
クラウドLLMを直接利用していると、APIキーはアプリケーションごとに増えていきます。
たとえば、営業部門でOpenAIを利用し、開発部門でClaudeを利用し、社内FAQではGeminiを利用する、といった構成です。
すると次のような状態になりがちです。
営業システム
└ OpenAI API Key
開発支援
└ Anthropic API Key
FAQシステム
└ Gemini API Key
誰がどれだけ利用しているのかを横断的に把握しにくくなります。
さらに、各部門が独自にLLMサービスを利用し始めれば、
「このAPIキーは誰が発行したのか」
「退職者が作成したキーが残っていないか」
「この部門は月にいくら利用しているのか」
といった管理上の問題も発生します。
そこでAI Gateway側でVirtual API Keyを発行します。
Application
|
| Virtual API Key
v
AI Gateway
|
+--> OpenAI
+--> Claude
+--> Gemini
実際のLLMプロバイダーのAPIキーはGatewayにのみ保存します。
アプリケーションにはプロバイダーのAPIキーを渡しません。
Virtual API Keyには、
- ユーザー
- 部門
- プロジェクト
- 利用可能モデル
- 利用上限
- Rate Limit
などのポリシーを紐付けます。
この設計にすると、LLM利用を企業単位で統制しやすくなります。
3. ローカルLLMを導入すると、さらに管理対象が増える
企業が生成AIを利用する場合、すべてのデータをクラウドLLMへ送信できるとは限りません。
たとえば、
- 契約書
- 顧客情報
- 社内設計書
- ソースコード
- 研究開発情報
- 未公開の経営情報
などについては、社内ネットワークや自社管理環境内で推論を完結させたいケースがあります。
そこでローカルLLMが選択肢になります。
しかし、ローカルLLMにはクラウドLLMとは異なる問題があります。
クラウドLLMの場合、モデルの実行環境はサービス提供者が管理します。
一方、ローカルLLMでは利用者側が、
- モデル
- GPU
- 推論エンジン
- メモリ
- Context Length
- モデルファイル
- 起動状態
- API Endpoint
などを管理する必要があります。
さらに推論エンジンも一つではありません。
代表的なものだけでも、
- Ollama
- llama.cpp
- vLLM
などがあります。
つまり、
クラウドLLM管理
+
ローカルLLM管理
という二重構造になりやすいのです。
筆者らが重要だと考えたのは、この2つを別システムにしないことでした。
4. クラウドLLMとローカルLLMを同じ管理基盤に載せる
目指した構成は次のようなものです。
+------------------+
| Application |
+------------------+
|
v
+----------------------+
| AI Gateway |
| |
| Model Registry |
| RBAC |
| Routing |
| Usage Control |
| Audit Log |
+----------------------+
| |
+------+ +------+
| |
v v
Cloud Provider Local Adapter
Adapter Layer
| |
+-----+------+ +-------+-------+
| | | | | |
OpenAI Claude Gemini Ollama llama.cpp vLLM
重要なのは、Gatewayから見たときにクラウドLLMとローカルLLMをできるだけ同じ「Model」として扱うことです。
たとえばModel Registryでは次のような情報を管理します。
{
"model_id": "local-qwen",
"provider": "local",
"engine": "vllm",
"endpoint": "http://local-ai:8000",
"context_length": 32768,
"capabilities": [
"chat",
"json"
]
}
クラウドモデルであれば次のようになります。
{
"model_id": "cloud-model-a",
"provider": "provider-a",
"capabilities": [
"chat",
"json",
"tool_calling"
]
}
アプリケーション側は、
model = local-qwen
なのか、
model = cloud-model-a
なのかを細かく意識する必要はありません。
Gatewayが適切なAdapterへ処理を渡します。
5. Ollama、llama.cpp、vLLMをAdapterで吸収する
ローカルLLMを統合する際に最も重要になるのがAdapter Layerです。
推論エンジンによってAPI仕様や能力が異なるため、直接アプリケーションから利用すると依存関係が強くなります。
そこで共通インターフェースを定義します。
概念的には次のような形です。
interface ModelAdapter {
chat(request)
stream(request)
healthCheck()
listModels()
getCapabilities()
}
そのうえで、
OllamaAdapter
LlamaCppAdapter
VllmAdapter
CloudProviderAdapter
のように実装します。
アプリケーションはAdapterの違いを知りません。
Application
|
AI Gateway
|
Model Adapter
という構造だけを認識します。
この抽象化により、後から新しい推論エンジンを追加しやすくなります。
ただし、すべてを完全に共通化できるわけではありません。
たとえば、
- Tool Calling
- Structured Output
- Vision
- Embedding
- Function Calling
- Context Length
などはモデルによって異なります。
そのため「APIを共通化する」だけではなく、モデルごとのCapabilityを管理する必要があります。
たとえば、
{
"chat": true,
"stream": true,
"json": true,
"tool_calling": false,
"vision": false
}
といった能力情報を保持します。
モデル選択時には、このCapabilityも条件として利用します。
6. ローカルLLMを「インストール済みモデル」から「管理対象モデル」へ
ローカルLLM導入では、
「Ollamaをインストールしてモデルを起動できた」
というところで終わるケースもあります。
しかし企業運用では、それだけでは不十分です。
たとえば、
「このモデルを利用してよい部署はどこか」
「誰が何回利用したのか」
「機密文書をこのモデルへ入力してよいか」
「モデルを入れ替えたのは誰か」
といった管理が必要になります。
つまり重要なのは、
Installed Model
ではなく、
Managed Model
にすることです。
Gateway側でローカルLLMもクラウドLLMと同様に管理対象にします。
たとえば、
Model: local-model-a
Allowed Groups:
- Legal
- R&D
Denied Groups:
- External Users
Data Policy:
- Confidential: Allowed
- Personal Data: Internal only
といったポリシーを定義できます。
すると「ローカルだから安全」という曖昧な考え方ではなく、
「どのモデルを、誰が、どのデータに使えるのか」
を明示的に管理できます。
7. どの処理をクラウド、どの処理をローカルにするのか
クラウドLLMとローカルLLMの両方を利用できるようになると、次に問題になるのがRoutingです。
すべてをローカルLLMで処理する必要はありません。
逆にすべてをクラウドへ送る必要もありません。
たとえば次のような使い分けが考えられます。
一般的な文章生成
↓
クラウドLLM
機密文書の要約
↓
ローカルLLM
高度なコードレビュー
↓
高性能クラウドLLM
大量の定型データ抽出
↓
低コストモデル
社内限定FAQ
↓
ローカルLLM
Routing条件には、
- データ機密性
- 必要品質
- コスト
- レイテンシ
- モデルCapability
- 部門ポリシー
などを利用できます。
概念的には、
if confidential:
use local_model
elif high_quality_required:
use premium_cloud_model
elif high_volume:
use low_cost_model
というルールです。
企業AI基盤では、モデル名を利用者に選ばせることよりも、
「この処理に適した実行先を基盤側で決める」
ことが重要になっていくと考えています。
8. LLMを「モデル名」ではなく「業務用途」から選ぶ
LLMの数が少なかった時期は、
「とりあえず最も高性能なモデルを使う」
という選択でも大きな問題はありませんでした。
しかしモデル数が増えると、それぞれの特性を人間が把握し続けるのは難しくなります。
また、「最も高性能なモデル」がすべての業務で最適とは限りません。
たとえば、
- summarization
- code_review
- data_extraction
- internal_faq
- legal_review
- agent_automation
では求められる能力が異なります。
データ抽出では、
- JSON形式を正しく守れるか
- 必須項目を欠落しないか
が重要です。
コードレビューでは、
- 問題の発見率
- 修正案の妥当性
- 誤検知率
が重要になります。
エージェント処理では、
- Tool Calling成功率
- 指示追従性
- 処理の安定性
が重要になります。
そのため、モデルを評価するときも総合スコアだけではなく、用途別に評価する必要があります。
9. 品質だけではなく、コストとのバランスを見る
企業利用ではAPIコストも無視できません。
仮にモデルAの品質が100、モデルBの品質が95だったとしても、
モデルAの価格がモデルBの10倍であれば、すべての処理をモデルAへ送ることが合理的とは限りません。
たとえばモデル評価を、
Quality Score
Cost
Latency
Success Rate
といった複数軸で行います。
さらに用途別に、
品質優先
バランス
コスト優先
というモデル推薦も考えられます。
大量の定型処理では多少品質が低くても安価なモデルを利用し、人間の判断に影響する処理では高品質モデルを利用する、といった使い分けです。
ローカルLLMについても「API料金がゼロだから無料」とは限りません。
実際には、
- GPU
- サーバー
- 電力
- 保守
- モデル更新
- 運用監視
のコストがあります。
クラウドとローカルを比較するときは、API単価だけで判断しないことが重要です。
10. ガバナンスはモデル選択と同じくらい重要
企業AI基盤では、「どのモデルが賢いか」だけではなく、
「誰が何をできるか」
の管理が必要です。
たとえばAI Gatewayで次のような仕組みを持たせます。
RBAC
Developer
├ Coding Model
└ General Model
Legal
├ Legal Review Model
└ Local Confidential Model
利用上限
Department A
Monthly Limit: 100,000 JPY
Project B
Monthly Limit: 30,000 JPY
Rate Limit
100 requests / minute
Audit Log
User
Application
Model
Timestamp
Token Usage
Tool
Result Status
これによって、
「誰が、いつ、どのモデルを利用したか」
を追跡できます。
AIが企業システムへ深く組み込まれるほど、こうした管理機能は重要になります。
11. MCP時代には「モデル」だけでなく「ツール」も管理する
LLMが文章を生成するだけであれば、管理対象はモデルだけでした。
しかしAI AgentがMCPなどを介して外部ツールを利用するようになると、状況は変わります。
LLMが、
- データベースを検索する
- ファイルを読む
- メールを送信する
- チケットを作成する
- 社内APIを実行する
といった操作を行うようになります。
すると、
このユーザーはどのモデルを使えるか
だけでは不十分です。
このユーザーはどのツールを使えるか
も管理する必要があります。
たとえば、
Developer
Model:
Coding LLM
MCP Tools:
GitHub Read
Jira Read
Denied:
Production DB Write
のようなポリシーです。
AI Gatewayは今後、
Model Gateway
から、
AI Control Plane
へ変わっていくのではないかと考えています。
12. 実際に作って分かったこと
クラウドLLMとローカルLLMを統合すると、単純なAPI Gatewayとは異なる課題が見えてきます。
共通APIだけでは不十分
Chat APIを共通化すること自体は比較的容易です。
難しいのは、
- Tool Calling
- Structured Output
- Context Length
- Vision
- Streaming
などモデル固有の能力差です。
モデルCapabilityをメタデータとして管理する必要があります。
ローカルLLMは運用が必要
クラウドLLMではモデルの起動状態を意識する必要はありません。
ローカルでは、
- GPUメモリ不足
- モデル停止
- サーバーダウン
- 推論速度低下
などが発生します。
そのため、
healthCheck()
や監視の仕組みが重要になります。
モデルは頻繁に変わる
LLMの進歩は速く、数か月前に最適だったモデルが現在も最適とは限りません。
そのためモデル推薦を固定設定にするのではなく、
Benchmark
↓
Evaluate
↓
Update Ranking
↓
Routing
という継続的な評価サイクルが必要になります。
13. Lykuroで目指している構成
筆者らが開発しているLykuro AI Gatewayでも、こうした考え方をもとに、
- 複数クラウドLLMの統合
- ローカルLLM管理
- 業務用途別モデル評価
- モデル推薦
- Virtual API Key
- 利用量管理
- RBAC
- 監査ログ
- MCPツール制御
などを一つのAI基盤として扱うことを目指しています。
特に重視しているのは、
「ローカルLLMにも接続できる」
ことそのものではありません。
重要なのは、
「クラウドLLMとローカルLLMを同じガバナンスの下で扱える」
ことです。
一般的な問い合わせではクラウドLLMを利用し、機密情報はローカルLLMで処理する。
高品質が必要な処理では高性能モデルを利用し、大量の定型処理では低コストモデルを利用する。
そうしたモデル選択を個々のアプリケーションへ実装するのではなく、AI基盤側で統一的に管理することを目指しています。
14. まとめ
生成AIの企業利用は、
1つのアプリケーション
+
1つのLLM
という構成から、
複数アプリケーション
+
複数クラウドLLM
+
複数ローカルLLM
+
AI Agent
+
MCP Tools
という構成へ変わりつつあります。
この環境では、モデルそのものの性能だけではなく、
- モデル管理
- Routing
- コスト
- 権限
- データ送信先
- Audit
- Tool Permission
まで含めたAI基盤の設計が重要になります。
また、ローカルLLMはクラウドLLMの代替というより、企業が扱うデータや用途に応じて使い分ける選択肢の一つだと考えています。
一般的な処理はクラウドへ、機密情報はローカルへ。
高品質が必要なら高性能モデルへ、大量処理なら低コストモデルへ。
そしてアプリケーション側には、その複雑さをできるだけ持ち込まない。
そのための境界としてAI Gatewayを設けることが、今後の企業向け生成AI基盤における重要な設計パターンの一つになると考えています。