株式会社renue
AI導入・DXの悩みをプロに相談してみませんか？
AIやDXに関する悩みがありましたら、お気軽にrenueの無料相談をご利用ください。 renueのAI支援実績、コンサルティングの方針や進め方をご紹介します。
Model Context Protocol（MCP）の入門記事は2026年現在数多く存在しますが、「自社で複数のMCPサーバを内製し、業務システム全体をAIエージェントから操作可能にする」というエンタープライズ実装の知見はまだ限られています。本記事では、業務システム×MCP複数並走の運用知見をもとに、企業内MCPサーバの設計パターン、複数MCPの統合アーキテクチャ、認証・権限・モニタリングの運用設計を整理します。
なぜ「1つの巨大MCP」ではなく「複数MCPの並走」が現実解なのか
企業内でMCPを本格運用するとき、最初に直面する設計判断が「すべての業務機能を1つのMCPサーバに詰め込むか、業務領域別に複数のMCPサーバを並走させるか」です。実装現場の経験から言うと、ほぼすべてのケースで後者が正解です。理由は次の3つです。
- 権限分離が容易：人事系MCP・営業系MCP・経理系MCPで、ツール一覧と実行権限を分けられる
- 更新サイクルの独立化：1つのMCPの修正で他のMCPが止まらない
- リスク隔離：1つのMCPに脆弱性が発見されても、他の業務領域への影響を限定できる
renueでも、業務領域別の複数のMCPサーバを並走させ、Claude CodeやCursorからプレフィックス付きで呼び分ける構成（業務領域ごとのプレフィックスを付与する形）を採用しています。
企業内MCPサーバの3つの実装パターン
パターン1：プロセス起動型MCPサーバ（最も一般的）
Pythonやnodeで実装し、Claude Code側の設定ファイルのMCPサーバ設定からプロセスとして起動する最も基本のパターンです。
- 強み：実装が単純、ローカル環境への閉じ込めが容易、認証情報を環境変数で渡せる
- 弱み：Claude Code起動時に全MCPプロセスが立ち上がるため、起動時間が伸びる
- 適性：個人開発・小規模チーム・社内ツール
パターン2：HTTPサーバ型MCPサーバ
MCPサーバをHTTPサーバとして常駐させ、Claude Codeから接続するパターン。複数ユーザー・複数エージェントから同時接続できます。
- 強み：常駐サーバでパフォーマンスが安定、複数クライアントから接続可能、認証・監査・レート制御を統一的に組み込める
- 弱み：常駐運用のインフラコストが発生、認証設計を間違えるとセキュリティリスク
- 適性：エンタープライズ運用・複数ユーザー共有・本番業務システム連携
パターン3：In-Process MCPサーバ（SDK埋め込み型）
アプリケーション内部で動的にMCPサーバを生成し、エージェント実行のスコープ内でだけ有効にするパターンです。Anthropic SDKのSDK内MCPサーバ生成相当の機能を活用します。
- 強み：実行スコープに完全に閉じ込められる、認証情報をプロセスメモリ内に閉じ込められる、エフェメラル運用に最適
- 弱み：実装にはAgent SDKの理解が必要、汎用クライアントから直接呼び出せない
- 適性：機密性の高い業務・1セッション完結のエージェント実行
多くの企業実装では、これら3パターンを業務領域ごとに使い分けるのが現実的です。一般に、ローカル利用はプロセス起動型、業務システム連携はHTTPサーバ型、機密データを扱う実行はIn-Process型と使い分けます。
複数MCPを並走させる際の名前空間設計
複数のMCPサーバを並走させるとき、ツール名の衝突と取り違えを防ぐ名前空間設計が重要です。Claude Codeのデフォルト挙動では、MCPサーバごとにプレフィックスがツール名に付与されます。たとえば次のような構造になります。
mcp__<サーバ名>__<ツール名>- 例：
mcp__sales__projects-list、mcp__pmo__issues-create、mcp__hiring__candidates-search
このプレフィックス設計を活かすには、MCPサーバ名そのものに業務領域・テナント・権限レベルを反映させます。たとえば「PMO業務専用」「採用業務専用」など、名前から責務が一意に分かる命名にすると、運用上のトラブルを大きく減らせます。
認証・権限・モニタリングの運用設計
認証：APIキー・OAuth・mTLSの3パターン
HTTPサーバ型MCPは必ず認証を組み込みます。実装パターンは3つあります。
- APIキー：単純で実装容易、社内ネットワーク内での運用に適する
- OAuth：複数組織・複数ユーザーへの提供時に必須、refresh token管理が必要
- mTLS：ゼロトラスト環境での最高セキュリティ運用、証明書管理コストが高い
個人ローカル運用ならAPIキー、SaaS的に複数顧客に提供するならOAuth、本番業務システム連携ならmTLSという使い分けが一般的です。
権限：ツール単位のホワイトリスト
MCPサーバ側で「このユーザーはこのツールだけ呼べる」というツール単位のホワイトリストを実装します。これがないと、権限のないユーザーが破壊的ツール（削除・送信・更新）を呼べてしまいます。
モニタリング：呼び出しログとレート制御
すべてのMCPツール呼び出しを「誰が・いつ・どのツールを・どのパラメータで・どんな結果で」呼んだか記録します。同時に、レート制御（短時間に大量呼び出しを行う異常パターンの検知）をMCPサーバ側で実装し、エージェントが暴走しても被害を最小化します。MCP呼び出しログをエージェント実行の時系列イベント基盤に統合すると、セッション単位で一連の追跡ができます。
企業内MCPの典型ユースケース
- 営業：案件検索、見積生成、提案資料ドラフト、商談議事録要約
- PMO：プロジェクトステータス取得、課題作成、リソース配分提案
- 採用：候補者検索、スカウト文生成、面接記録要約
- 経理：仕訳ドラフト、予実差異コメント生成、レポート初稿
- マーケ：競合調査、コンテンツドラフト、SNS投稿案生成
- カレンダー/メール：日程調整、要約、自動返信ドラフト
- 社内DX：従業員一覧、組織情報、社内ドキュメント検索
これらをすべて1つの巨大MCPに詰め込もうとすると、ツール一覧が数百件に膨れ上がり、エージェントの選択精度が落ちます。業務領域別にMCPを分けることで、エージェントは「いま使うべきMCP」を狭く絞れて、ツール選択の精度が上がります。
MCP内製で陥りやすい4つの落とし穴
- 落とし穴1：ツール一覧をすべて1つのMCPに詰め込む。エージェントの選択精度が落ち、暴走リスクも増えます。業務領域別に分割するのが鉄則です。
- 落とし穴2：認証を後回しにする。プロトタイプで認証なしのまま本番に持ち込まれると、社内全体のセキュリティ穴になります。
- 落とし穴3：呼び出しログを取らない。誰が何をしたか追えない状態では、ガバナンス対応ができません。
- 落とし穴4：1つのMCPに「破壊的ツール」と「読み取りツール」を混在させる。読み取り専用MCPと書き込み可能MCPを物理的に分離するほうが、権限管理が容易です。
企業内MCP内製で押さえておきたい3原則
- 業務領域単位でMCPを分割する：1つの巨大MCPは作らない。10件のツールごとに新しいMCPを作る感覚で粒度を保つ
- 認証・権限・モニタリングを最初から組み込む：プロトタイプ段階から認証を入れ、本番化フェーズで追加するのは禁じ手とする
- ツール命名と説明文を徹底的に磨く：エージェントは命名とdescriptionからツールを選ぶため、ここの品質がそのまま実用性になる
