企業内MCPサーバ内製ガイド2026｜複数並走の設計パターンと認証・権限・モニタリング

Model Context Protocol（MCP）の入門記事は2026年現在数多く存在しますが、「自社で複数のMCPサーバを内製し、業務システム全体をAIエージェントから操作可能にする」というエンタープライズ実装の知見はまだ限られています。本記事では、業務システム×MCP複数並走を運用しているrenueの内部実装をもとに、企業内MCPサーバの設計パターン、複数MCPの統合アーキテクチャ、認証・権限・モニタリングの運用設計を整理します。

なぜ「1つの巨大MCP」ではなく「複数MCPの並走」が現実解なのか

企業内でMCPを本格運用するとき、最初に直面する設計判断が「すべての業務機能を1つのMCPサーバに詰め込むか、業務領域別に複数のMCPサーバを並走させるか」です。実装現場の経験から言うと、ほぼすべてのケースで後者が正解です。理由は次の3つです。

• 権限分離が容易：人事系MCP・営業系MCP・経理系MCPで、ツール一覧と実行権限を分けられる
• 更新サイクルの独立化：1つのMCPの修正で他のMCPが止まらない
• リスク隔離：1つのMCPに脆弱性が発見されても、他の業務領域への影響を限定できる

renueでも、社内・人事・カレンダー・PMO・営業など複数のMCPサーバを並走させ、Claude CodeやCursorからプレフィックス付きで呼び分ける構成（例：`mcp__renue__*`、`mcp__renue-pmo__*`、`mcp__renue-hiring__*`など）を採用しています。

企業内MCPサーバの3つの実装パターン

パターン1：プロセス起動型MCPサーバ（最も一般的）

Pythonやnodeで実装し、Claude Code側の`settings.json`の`mcpServers`設定からプロセスとして起動する最も基本のパターンです。

• 強み：実装が単純、ローカル環境への閉じ込めが容易、認証情報を環境変数で渡せる
• 弱み：Claude Code起動時に全MCPプロセスが立ち上がるため、起動時間が伸びる
• 適性：個人開発・小規模チーム・社内ツール

パターン2：HTTPサーバ型MCPサーバ

MCPサーバをHTTPサーバとして常駐させ、Claude Codeから接続するパターン。複数ユーザー・複数エージェントから同時接続できます。

• 強み：常駐サーバでパフォーマンスが安定、複数クライアントから接続可能、認証・監査・レート制御を統一的に組み込める
• 弱み：常駐運用のインフラコストが発生、認証設計を間違えるとセキュリティリスク
• 適性：エンタープライズ運用・複数ユーザー共有・本番業務システム連携

パターン3：In-Process MCPサーバ（SDK埋め込み型）

アプリケーション内部で動的にMCPサーバを生成し、エージェント実行のスコープ内でだけ有効にするパターンです。Anthropic SDKの`create_sdk_mcp_server`相当の機能を活用します。

• 強み：実行スコープに完全に閉じ込められる、認証情報をプロセスメモリ内に閉じ込められる、エフェメラル運用に最適
• 弱み：実装にはAgent SDKの理解が必要、汎用クライアントから直接呼び出せない
• 適性：機密性の高い業務・1セッション完結のエージェント実行

多くの企業実装では、これら3パターンを業務領域ごとに使い分けるのが現実的です。renueの内部でも、社員端末にインストールするローカルMCPはプロセス起動型、業務システム連携はHTTPサーバ型、機密データを扱う特定エージェントはIn-Process型、というように使い分けています。

複数MCPを並走させる際の名前空間設計

複数のMCPサーバを並走させるとき、ツール名の衝突と取り違えを防ぐ名前空間設計が重要です。Claude Codeのデフォルト挙動では、MCPサーバごとにプレフィックスがツール名に付与されます。たとえば次のような構造になります。

• mcp__<サーバ名>__<ツール名>
• 例：mcp__renue__projects-list、mcp__renue-pmo__issues-create、mcp__renue-hiring__candidates-search

このプレフィックス設計を活かすには、MCPサーバ名そのものに業務領域・テナント・権限レベルを反映させます。たとえば「`renue-pmo`はPMO業務専用」「`renue-hiring`は採用業務専用」など、名前から責務が一意に分かる命名にすると、運用上のトラブルを大きく減らせます。

認証・権限・モニタリングの運用設計

認証：APIキー・OAuth・mTLSの3パターン

HTTPサーバ型MCPは必ず認証を組み込みます。実装パターンは3つあります。

• APIキー：単純で実装容易、社内ネットワーク内での運用に適する
• OAuth：複数組織・複数ユーザーへの提供時に必須、refresh token管理が必要
• mTLS：ゼロトラスト環境での最高セキュリティ運用、証明書管理コストが高い

個人ローカル運用ならAPIキー、SaaS的に複数顧客に提供するならOAuth、本番業務システム連携ならmTLSという使い分けが一般的です。

権限：ツール単位のホワイトリスト

MCPサーバ側で「このユーザーはこのツールだけ呼べる」というツール単位のホワイトリストを実装します。これがないと、権限のないユーザーが破壊的ツール（削除・送信・更新）を呼べてしまいます。

モニタリング：呼び出しログとレート制御

すべてのMCPツール呼び出しを「誰が・いつ・どのツールを・どのパラメータで・どんな結果で」呼んだか記録します。同時に、レート制御（短時間に大量呼び出しを行う異常パターンの検知）をMCPサーバ側で実装し、エージェントが暴走しても被害を最小化します。renueでは、MCP呼び出しログを`agent_runs`の時系列イベントテーブルに統合し、Claude Codeセッションと一連で追跡できる構成を採用しています。

企業内MCPの典型ユースケース

• 営業：案件検索、見積生成、提案資料ドラフト、商談議事録要約
• PMO：プロジェクトステータス取得、課題作成、リソース配分提案
• 採用：候補者検索、スカウト文生成、面接記録要約
• 経理：仕訳ドラフト、予実差異コメント生成、レポート初稿
• マーケ：競合調査、コンテンツドラフト、SNS投稿案生成
• カレンダー/メール：日程調整、要約、自動返信ドラフト
• 社内DX：従業員一覧、組織情報、社内ドキュメント検索

これらをすべて1つの巨大MCPに詰め込もうとすると、ツール一覧が数百件に膨れ上がり、エージェントの選択精度が落ちます。業務領域別にMCPを分けることで、エージェントは「いま使うべきMCP」を狭く絞れて、ツール選択の精度が上がります。

MCP内製で陥りやすい4つの落とし穴

1. 落とし穴1：ツール一覧をすべて1つのMCPに詰め込む。エージェントの選択精度が落ち、暴走リスクも増えます。業務領域別に分割するのが鉄則です。
2. 落とし穴2：認証を後回しにする。プロトタイプで認証なしのまま本番に持ち込まれると、社内全体のセキュリティ穴になります。
3. 落とし穴3：呼び出しログを取らない。誰が何をしたか追えない状態では、ガバナンス対応ができません。
4. 落とし穴4：1つのMCPに「破壊的ツール」と「読み取りツール」を混在させる。読み取り専用MCPと書き込み可能MCPを物理的に分離するほうが、権限管理が容易です。

renueがMCP内製で徹底している3原則

1. 業務領域単位でMCPを分割する：1つの巨大MCPは作らない。10件のツールごとに新しいMCPを作る感覚で粒度を保つ
2. 認証・権限・モニタリングを最初から組み込む：プロトタイプ段階から認証を入れ、本番化フェーズで追加するのは禁じ手とする
3. ツール命名と説明文を徹底的に磨く：エージェントは命名とdescriptionからツールを選ぶため、ここの品質がそのまま実用性になる

FAQ

Q1. MCPサーバは何個まで並走させて良いですか？

技術的な上限はありませんが、実用上は10〜20個程度までが管理しやすい規模です。それ以上になる場合は、上位の「MCPカタログサーバ」を作って、必要なMCPだけを動的にロードする設計が現実的です。

Q2. プロセス起動型とHTTPサーバ型はどちらが良いですか？

個人開発・小規模はプロセス起動型、複数ユーザー・本番業務はHTTPサーバ型が標準です。両者を併用するのも有効で、ローカル開発はプロセス起動、本番運用はHTTPサーバに切り替えるパターンがよく採用されます。

Q3. 既存の業務システムとMCPはどう連携させれば良いですか？

既存の業務システムが提供しているREST API/GraphQL APIをラップする形でMCPサーバを実装するのが標準です。FastAPI・Express・Flask等で薄いラッパーサーバを作り、認証・レート制御・ログ統合を組み込みます。

Q4. MCPの呼び出しログはどこに保存すべきですか？

Claude Codeのエージェント実行と紐付けて追跡できる場所に保存するのが理想です。具体的には、agent_runの時系列イベントテーブル、SIEM、または社内ログ集約基盤への統合です。MCPの呼び出しを単独で見ても意味が薄く、エージェントセッションの文脈と組み合わせて初めて価値が出ます。

Q5. 内製と外部公開MCPはどう使い分けますか？

外部公開MCP（公式・サードパーティ）は汎用的な機能（GitHub・Slack・Notion等）に使い、自社固有の業務システム・社内データ・独自業務フローは内製MCPで実装するのが現実的です。混在することは前提として、運用設計の段階から「どのMCPは外部に依存」「どのMCPは社内管理」を明確に分けます。