MCPの登場と、現実とのギャップ
Model Context Protocol（MCP / モデルコンテキストプロトコル）は、AIエージェント（AI Agents）が外部ツールやシステムと接続するための有望な標準プロトコルとして注目を集めています。しかし、実際のエンタープライズ環境でMCPを運用してみると、プロトコルの仕様と現場で求められる要件の間に明確なギャップがあることがわかります。
私たちが数多くの企業チームとMCP導入を支援する中で学んだのは、「APIをそのままツール化する単純な実装では、むしろ課題を増やしてしまう」ということでした。ここでは、実際に機能するエンタープライズMCPアーキテクチャの構築法を解説します。
MCPの理想と現実
MCPの核は非常にシンプルです。LLM（大規模言語モデル）駆動のアプリケーションがツールを発見（tools/list）し、呼び出す（tools/call）ための統一的な仕組みを提供します。この設計により、クライアントとサーバー間の通信効率が最適化され、業界横断的な相互運用性（Interoperability）が実現します。
しかし現実には、MCPを“使える”ようにするための大部分の作業は、プロトコルの外で行う必要があります。
MCP自体には、認証・認可・ログ管理・リトライ制御・ビジネスルール・ガバナンスといった要素は含まれていません。これらは「追加要件」ではなく、実運用に不可欠な基盤です。
もちろん、この設計思想は意図的であり、MCPが余計な複雑性を抱えないための強みでもあります。実際、「MCP Apps Extension」などの拡張仕様も登場し、必要に応じて拡張可能な構造が整いつつあります。しかし、それでもなお、複雑な業務プロセスをどのように構成（Compose）するかという課題は解決されていません。
「Enterprise MCP」とは何か
エンタープライズMCPとは、単なるMCPサーバー実装ではなく、次の要件を満たす実運用レベルのアーキテクチャを指します。
1. マルチシステムオーケストレーション（Multi-System Orchestration）
Salesforce、Stripe、ERPなど複数のシステムを横断的に統合。
AIエージェントは、単一のAPIではなく、CRM・決済・コミュニケーション・レガシーデータベースなどを横断してワークフローを実行します。
2. 本番稼働レベルの信頼性（Production-Grade Reliability）
SLA、モニタリング、リトライ制御、災害復旧などを備え、
高可用性（High Availability）とトランザクション整合性（Transactional Integrity）を保証。
3. ガバナンスとコンプライアンス
監査ログ（Audit Logs）、アクセス制御、データ管理を徹底。
GDPRやHIPAAといった規制にも準拠。
4. 動的かつスケーラブルな処理
ユーザー数やトラフィックの増減に応じて自動的にスケール。
グローバルな負荷分散にも対応。
5. 現実的な統合複雑性への対応
RESTだけでなくSOAP、CSV、ファイルベース統合なども想定。
20年以上前のシステムとも連携可能な柔軟性が求められます。
これは企業規模の問題ではなく、「人々が日常的に依存するシステムをAIが安全に扱う」ために必要な設計思想です。
単純なMCP実装が失敗する理由
多くのチームが最初に試みるのが、既存APIをそのままMCPツールとして公開する方法です。一見合理的に見えますが、これは「ナイーブなMCPアーキテクチャ」であり、すぐに限界に直面します。
たとえば、社員がAIアシスタントを使って経費精算を依頼したとします。MCPサーバーがAPIをそのまま公開している場合、エージェントは「createParentWithChild」「async_GetReport_byId」など複数の低レベル操作を逐次呼び出す必要があり、非同期ジョブ管理やエラーハンドリングもすべて自力で行わなければなりません。
結果として、AIは「処理の迷路」に陥り、ユーザー体験は複雑で非効率になります。
セパレーション・オブ・コンサーン（責務分離）の再定義
この問題を解決するには、まず「AIとバックエンドの責務」を正しく切り分ける必要があります。
| 領域 | 得意な処理 |
| LLM（AI側） | 意図理解、曖昧さの処理、自然言語の変換、次の行動予測など「非決定的処理」 |
| バックエンド | 権限管理、確定処理、リトライ・バッチ制御、状態管理など「決定的処理」 |
LLMは創造的・予測的タスクに強い一方で、確定性や一貫性が求められる処理には向きません。逆にバックエンドは、自然言語理解や意図推測といった高エントロピー処理には不向きです。
つまり、MCPアーキテクチャはこの2つの強みを補完し合うように設計する必要があるのです。
コンポーザブルアーキテクチャの実例
架空のホテル「Dewy Resort」を例に考えてみましょう。フロント担当がAIに「お客様のチェックアウトをお願いします」と依頼した場合、その裏では次のような処理が走ります。
- 予約と部屋ステータスの確認
- 支払い処理
- 客室在庫の更新
- 清掃依頼のトリガー
- コンプライアンス用のログ登録
ナイーブな実装では、AIがこれらすべてを個別のAPI呼び出しで制御しなければなりません。一方、コンポーザブルアーキテクチャでは「Process guest checkout」という1つのスキルツールとして提供し、バックエンド側で必要な全処理を自動オーケストレーションします。
このように、MCPサーバーを複数の再利用可能スキル（Reusable Skills）として設計することで、AIエージェントは「意図」に集中でき、バックエンドは「実行」を確実に行う構造を実現できます。
ビジネスインパクト
| ステークホルダー | 効果 |
| ユーザー | 操作が自然になり、システム構造を意識せず業務が完結 |
| AIエージェント | 意図理解に集中でき、技術的処理の負担が軽減 |
| 開発者 | ロジックを再利用可能なワークフローとして集中管理可能 |
| 企業 | ガバナンス・可観測性・ビジネスルールの統一が容易に |
エンタープライズMCP設計の3原則
- MCPの範囲は限定的であることを理解する
認証・ガバナンス・オーケストレーションはプロトコル外で設計すべき領域です。 - 実システムの複雑性を軽視しない
AIのランタイムに押し付けるのではなく、バックエンドで吸収する仕組みを設計します。 - APIではなく「業務目的（Jobs-to-be-Done）」を軸に設計する
ユーザーが実現したい目的を中心に、必要な統合をスキルとして構成します。
実践：オープンソースで学ぶコンポーザブルMCP
Workatoでは、ホスピタリティ業界向けのデモアプリ「Dewy Resort」をオープンソースで公開しています。
リポジトリには以下が含まれています：
- 構成済みMCPスキルの実装（チェックアウト、メンテナンスリクエストなど）
- バックエンドオーケストレーションの具体例
- Salesforce、Stripe、IoTデバイス連携パターン
- スキル単位のアーキテクチャ設計ドキュメント
▶︎ GitHub: workato-devs/dewy-resort
まとめ：プロトコルが与えるのは「相互運用性」、設計が決めるのは「実用性」
MCPはAI統合の未来を拓く強力な標準ですが、その価値を引き出すかどうかはアーキテクチャ次第です。
単なるAPIラッパーにとどまらず、コンポーザブルアーキテクチャを基盤としたエンタープライズMCPが、AIエージェントを真に実用的な存在へと進化させます。