エンタープライズMCP実装の本質は「プロトコル」ではない
前回の記事では、エンタープライズMCP（Model Context Protocol）の実装において最大の課題は「プロトコルそのもの」ではなく、その設計思想とアーキテクチャ判断にあると述べました。
多くのチームはMCPを「LLMのためのAPIゲートウェイ」と捉えがちですが、本来目指すべきはコンポーザブルアーキテクチャ（Composable Architecture）に基づくツール設計です。
今回は、その実践的な設計手法を実例とともに解説します。
ケーススタディ：ホテル運営システムでのMCPツール設計
例として、ホテルのフロント業務を考えましょう。
スタッフが次のように発話します：
「Beth Gibbsさんがチェックアウトします。トイレの調子が悪いそうです。」
この一言の背後には、複数の処理が必要です。
- チェックアウトの実行（支払い・領収書・部屋ステータス更新）
- メンテナンス依頼の登録（客室情報を保持したまま）
- 在庫・空室状況の更新
- メンテナンスチームへの依頼ルーティング
これらをMCP上でどう設計するべきでしょうか。
よくある誤ったアプローチ
多くのチームは既存APIをそのままツール化します。
- get_guest_by_email
- get_booking_by_guest
- get_room_by_booking
- create_payment_intent
- charge_payment_method
- send_receipt_email
- update_booking_status
- update_room_status
- create_case
- assign_case_to_contact
- set_case_priority
この場合、AIエージェントは11以上のAPI呼び出しを順序通りに実行し、状態管理とエラー処理を自分で行わなければなりません。結果はどうなるでしょうか。遅く、複雑で、ユーザー体験を損なうシステムになります。
正しいアプローチ：コンポーザブルなスキルベース設計
一方で、「ユーザーの意図」に基づいたツールを設計すると、こうなります。
- process_guest_checkout
- submit_maintenance_request
2つのツールで、自然な会話が成立します。処理の複雑さは消えたのではなく、適切な場所（バックエンド）に移動したのです。
コンポーザブルツール設計のための9つのパターン
実際のエンタープライズMCP環境で得られた、堅牢な設計を実現する9つの原則を紹介します。
1. システムIDではなくビジネス識別子を使う
NG例：
{
“contact_id”: “003Dn00000QX9fKIAT”,
“booking_id”: “a0G8d000002kQoFEAU”,
“room_id”: “a0I8d000001pRmXEAU”
}
OK例：
{
“guest_email”: “beth.gibbs@email.com”,
“room_number”: “302”
}
エージェントはデータベース構造を知る必要がありません。バックエンドがビジネス識別子を内部IDに変換する設計が理想です。
2. 冪等性（Idempotency）を設計に組み込む
全ての更新・作成ツールはidempotency_tokenを受け取るべきです。同じ操作が再送されても、重複せず安全に処理されます。
これにより、複数システム間での一貫性あるトランザクション管理（サガパターン）も可能になります。
3. 状態遷移を原子的（Atomic）に行う
ゲストチェックインでは、以下の状態が同時に変化します：
- 予約：Reserved → Checked In
- 部屋：Available → Occupied
- 商談：Pending → Active
これらを別々のツールで管理するのではなく、一つのツール（check_in_guest）で一貫して処理します。
4. 認可をツール設計に組み込む
次のような全検索APIを提供するのは危険です。
- search_all_cases
- search_all_rooms
代わりに、アクセス範囲を明示的に設計します：
- search_cases_on_behalf_of_guest(guest_email)
- search_rooms_on_behalf_of_staff(floor_filter, status_filter)
こうすることで、認可を宣言的（Declarative）に設計できます。
5. スマートデフォルト（Smart Defaults）を設定する
AIエージェントの認知負荷を減らすために、入力項目のデフォルト値を設けましょう。
{
“guest_email”: “required”,
“check_in_date”: “defaults to today”,
“number_of_guests”: “defaults to 1”
}
可変要素のみを指定すればよい設計が理想です。
6. 事前条件とエラーの挙動を明記する
ツールの説明文には、エラーコードや前提条件を記載します。
【例】「チェックインツールはゲスト予約を検証し、部屋の空き状況を確認。404＝予約なし、409＝部屋使用中。」
これにより、エージェントが安全に再試行や質問を行えるようになります。
7. 部分更新（Partial Update）をサポートする
更新ツールは、提供された項目のみ変更する設計にします。
{
“external_id”: “required”,
“check_in_date”: “optional”,
“room_number”: “optional”
}
全項目の再入力を強制するよりも、部分的な変更の方が効率的で安全です。
8. 防御的コンポジションヘルパーを作る
必要な前提条件を自動で確認するヘルパー関数を用意します。
create_contact_if_not_found(email, first_name, last_name)
このような関数は冪等性を持ち、再利用可能です。
9. 自然言語に合わせた命名を行う
「Beth Gibbsをチェックイン」→ check_in_guest
「302号室のトイレが壊れている」→ submit_maintenance_request
ツール名やパラメータは、人が実際に話す言葉に近づけることが重要です。
LLMとバックエンドの役割分担こそが鍵
これら9つの原則の根底にあるのは、セパレーション・オブ・コンサーン（Separation of Concerns）です。
- LLMは「意図の理解」に最適化された確率的システム
- バックエンドは「状態管理と整合性」に最適化された決定的システム
LLMにオーケストレーションを任せてはいけません。複雑な処理は常にガバナンス可能なバックエンド側で制御すべきです。
実際の効果：Dewy Resortでの結果
ホテル業務アプリ「Dewy Resort」で、従来のAPIラッパー設計からスキルベース設計へ移行したところ、以下の改善が見られました。
| 指標 | 変更前 | 変更後 |
| 平均応答時間 | 8〜12秒 | 2〜4秒 |
| 成功率 | 73% | 94% |
| 使用ツール数 | 47 | 12 |
| 1回の会話あたりの呼び出し数 | 6.2 | 1.8 |
| ユーザーフィードバック | 「動くけど遅い」 | 「直感的で速い」 |
差を生んだのは、AIの性能ではなくアーキテクチャでした。
エンタープライズMCPツール設計のチェックリスト
✅ 識別と解決
- ビジネス識別子（email, name, number）を使用しているか
- ID解決はバックエンド側で行っているか
✅ 安全性と信頼性
- 冪等性トークンを設計に組み込んでいるか
- 状態遷移は原子的に行われているか
✅ 認可とアクセス
- 認可スコープがツールインターフェースに組み込まれているか
✅ 認知負荷
- スマートデフォルトが設定されているか
- エラーモードが明確に文書化されているか
✅ 柔軟性
- 部分更新をサポートしているか
- ビジネス識別子で関係を変更できるか
他分野への応用：業界別ユースケース
この設計原則はホテル業界に限らず、あらゆるエンタープライズ領域に適用可能です。
- 医療業界：「この患者のフォローアップを予約」＝予約・通知・記録更新を自動連携
- 金融業界：「経費報告を提出」＝検証・承認・会計登録を一貫実行
- 小売業界：「返品処理を行う」＝在庫・返金・通知を統合処理
目的（Intent）に基づくツール設計こそ、AIとMCPを最大限に活かす鍵です。
まとめ：APIをラップするのではなく、スキルを構成せよ
Enterprise MCPは、ツール間の相互運用性を実現するための基盤です。その上で「コンポーザブルスキル設計」を採用することで、AIエージェントとバックエンドが連携する実用的で信頼性の高いオーケストレーション基盤が構築できます。
APIを単にラップする時代は終わりです。今こそ「スキルを構成する」時代へ。
本記事は、以前公開した「Beyond Basic MCP：なぜエンタープライズAIにはコンポーザブルアーキテクチャが必要なのか」 を踏まえた内容です。前回の記事では、MCPを本番環境で実用的なものにするために不可欠なアーキテクチャ原則について解説しました。