Executive Summary
AI時代のアーキテクトに必要なのは「どのLLMが最強か」を決めることではありません。
重要なのは、
どこを決定論的ロジックにし、どこをAIに任せ、どの境界でデータ・権限・評価・監査を制御するか
を設計することです。
2026年は、Model / RAG / Agent / MCP / Sandbox / Eval / Observabilityまでを一つのシステムとして設計する必要があります。
最終確認日: 2026-10-08
背景と重要性
AIモデルの更新速度は、一般的な業務システムのリプレース周期より圧倒的に速くなっています。
2026-10-08時点でも主要ベンダーには複数の現行モデルがあります。
したがって、
「GPT-Xを使うシステム」
ではなく、
「必要品質を満たすModelをPolicyによって選択できるシステム」
として設計した方が変更に強くなります。
主要トピックと最新動向
AIシステムを層で分離する
推奨する基本構造は次です。
モデルだけを抽象化するより、
- Model
- Retrieval
- Tool
- Policy
- Eval
を分離した方が有効です。
Model PortabilityとProvider Featureのバランス
完全なベンダー非依存APIを作ろうとすると、
Provider Aの高度なAgent機能
Provider BのContext機能
Provider CのMultimodal機能
を使えなくなります。
そこで、
共通化するもの
- Authentication
- Audit
- Rate Control
- Cost
- Routing
- Model Policy
Provider固有を許容するもの
- Tool Calling
- Reasoning parameters
- Agent Runtime
- Realtime
- Provider-specific multimodal
と分けます。
「ベンダーロックインをゼロにする」より、ロックインする場所を明示する方が現実的です。
RAGかLong Contextか
Long Contextが大きくなってもRAGの役割は消えません。
RAGには、
- 情報更新
- アクセス制御
- 出典付与
- 検索対象限定
- Context量削減
というアーキテクチャ上の利点があります。
また、Long Contextについては情報位置によって性能が低下し得ることを示した研究もあります。
判断基準は、
| 条件 | Long Context | RAG |
|---|---|---|
| 文書量が小さい | ◎ | △ |
| 更新頻度が高い | △ | ◎ |
| ACLが複雑 | △ | ◎ |
| 出典が重要 | ○ | ◎ |
| 全体構造理解 | ◎ | ○ |
程度から始め、必ず自社Evalで確認します。
WorkflowかAgentか
まず決定論的Workflowで作れないか検討します。
Agentを使うほど、
- 非決定性
- Cost
- Security Surface
- Debug難易度
が増えます。
「Agent化」は目的ではありません。
MCPをIntegration Architectureとして見る
MCPはAIアプリケーションと外部システムを標準化して接続します。
一方でMCP Serverは実システムへの能力を公開する境界でもあります。
したがって、
MCP Server = AI向けAPI Gateway
に近いセキュリティ意識が必要です。
2026-07-28仕様にはHTTP AuthorizationやLeast Privilege等の要件があります。
実務での活用例
Architecture Decision RecordにAIを含める
ADR例:
Decision:
顧客サポート回答生成にRAGを採用する。
Context:
情報は毎日更新される。
部署別ACLが必要。
回答には根拠リンクが必要。
Decision Drivers:
- Freshness
- ACL
- Citation
- Cost
Consequences:
- Retrieval品質を別途評価する必要がある
- Index Pipelineを運用する必要がある
モデル選択もADR化します。
AI Capability Map
Capability
├─ Classification
├─ Extraction
├─ Search
├─ Summarization
├─ Generation
├─ Coding
└─ Autonomous Action
右へ行くほどではなく、特に「Autonomous Action」へ近づくほどRisk Controlを強くする、という考え方が有効です。
実務チェックリスト
Architecture
- AIを使わない選択肢を比較した
- WorkflowとAgentを比較した
- Long ContextとRAGを比較した
- Hosted / Open Model / On-deviceを比較した
- Provider依存箇所をADRに残した
- Model Policyをアプリケーションコードから分離した
- Retrieval Policyを分離した
- Tool Policyを分離した
Security Architecture
- AgentのTrust Boundaryを図示した
- MCPごとの権限を定義した
- Sandbox境界を定義した
- Egress Policyを定義した
- Human Approval Pointを定義した
- Data ClassificationとAI利用可否を結び付けた
Lifecycle
- Model変更をEval Gate経由にした
- Prompt変更もVersion管理する
- Index変更も評価対象にする
- Rollback可能にした
- Cost Budgetを設計した
導入時の注意点とリスク
「AI Gatewayを作ればベンダー非依存」ではない
Syntaxは抽象化できてもSemanticは完全には揃いません。
モデルごとに、
- Tool Calling
- Reasoning
- Context
- Multimodal
- Safety
- Agent Runtime
の特性が異なります。
最低共通機能へ揃えすぎないことが重要です。
Multi-Agentを最初から採用しない
複数Agentは魅力的ですが、
Agent A
↓
Agent B
↓
Agent C
と増えるほど障害原因やCost Attributionが難しくなります。
単一Agent → 必要な箇所だけSubagent、という順序が安全です。
AIをSystem of Recordにしない
最終的な権限や状態は、
- Database
- IAM
- Workflow Engine
- Policy Engine
側で決定します。
LLMの会話履歴を権限状態の正本にしないことが重要です。
推奨情報源
- OpenAI Developers
- Anthropic Platform Docs
- Google AI for Developers
- AWS AgentCore
- MCP Specification
- NIST AI RMF
- Hugging Face Model Cards