株式会社renue
案件モニタリングAI
案件モニタリングAIで、この記事のテーマを実務に落とし込めます
renueが社内で運用しているシステムをサービス化したものです。何ができるか、どう動くかをサービスページでご覧ください。
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サーバ設定からプロセスとして起動する最も基本のパターンです。
- 強み：実装が単純、標準入出力（stdio）で子プロセスと接続するため、MCP接続用のネットワークポートを公開せずに運用できる、認証情報を環境変数で渡せる。ただし、ローカル起動だけではファイルや外部通信を隔離できず、実行権限・ファイル・通信の制限は別途必要
- 弱み：サーバ数に応じてプロセス資源・接続初期化の管理が必要。現行Claude Codeでは通常バックグラウンドで接続し、起動待機の設定等によって待ち時間が変わる
- 適性：個人開発・小規模チーム・社内ツール
パターン2：HTTPサーバ型MCPサーバ
MCPサーバをHTTPサーバとして常駐させ、Claude Codeから接続するパターン。複数ユーザー・複数エージェントから同時接続できます。
- 強み：常駐サーバでパフォーマンスが安定、複数クライアントから接続可能、認証・監査・レート制御を統一的に組み込める
- 弱み：常駐運用のインフラコストが発生、認証設計を間違えるとセキュリティリスク
- 適性：エンタープライズ運用・複数ユーザー共有・本番業務システム連携
パターン3：In-Process MCPサーバ（SDK埋め込み型）
アプリケーション内部でMCPサーバを生成し、そのエージェント実行へツールを渡すパターンです。Claude Agent SDKのcreateSdkMcpServer（TypeScript）／create_sdk_mcp_server（Python）は、アプリケーションと同じプロセス内でツール関数を動かします。提供範囲を指定する機能であり、アプリケーションから隔離する仕組みではありません。
- 強み：必要な実行へ渡すツールを選べる、アプリケーション内の関数・状態を扱いやすい、実行単位で構成を作れる。同一プロセスで動くため、共有メモリ内の認証情報を他のアプリケーションコードから隔離する保証はない
- 弱み：実装にはAgent SDKの理解が必要、汎用クライアントから直接呼び出せない
- 適性：1セッション完結のエージェント実行・アプリケーション内の関数との連携。機密性はIn-Processという形式だけで決まらず、実行環境の権限・隔離・通信制御を別途設計する
これら3パターンは、業務領域や接続条件ごとに使い分けられます。ローカルの子プロセスにはstdio、複数ユーザーから共有する遠隔サーバには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には、認証・認可を組み込んで運用します。MCPの認可機能自体は仕様上任意ですが、HTTP向けにはOAuthベースの認可フローが定められています。以下の3方式は同じ階層の代替規格ではなく、クライアント対応と保護対象に応じて選択・併用します。
- APIキー：Claude CodeではカスタムHTTPヘッダーにトークン等を設定できる。APIキー方式はサーバ独自の認証設計で、利用するクライアントのヘッダー対応、キーの保管・失効・権限範囲を確認する
- OAuth：HTTP向けMCP認可仕様が定めるOAuth 2.1ベースの方式。ユーザー等に応じたアクセス権を扱い、認可サーバ情報の発見や対象リソースの検証に対応する。refresh tokenを発行・利用する構成では、その保管・更新・失効も管理する
- mTLS：TLS接続でサーバだけでなくクライアントの証明書と秘密鍵保有を確認する方式。OAuthと組み合わせる設計もある。接続するクライアント・サーバ双方の証明書対応と運用管理が必要で、ツール単位の認可を代替するものではない
stdioではHTTP向けOAuthフローを適用せず、必要な認証情報を実行環境から取得します。HTTPでは、OAuthの対応状況、独自ヘッダー認証の互換性、証明書で接続元を限定する必要性を確認します。「個人ならAPIキー、本番ならmTLS」と固定せず、誰にどのデータ・操作を許可するかを先に決め、方式と権限制御を組み合わせます。
権限：ツール単位のホワイトリスト
MCPサーバ側で「このユーザーはこのツールだけ呼べる」というツール単位のホワイトリストを実装します。これがないと、権限のないユーザーが破壊的ツール（削除・送信・更新）を呼べてしまいます。
モニタリング：呼び出しログとレート制御
すべてのMCPツール呼び出しを「誰が・いつ・どのツールを・どのパラメータで・どんな結果で」呼んだか記録します。同時に、レート制御（短時間に大量呼び出しを行う異常パターンの検知）をMCPサーバ側で実装し、エージェントが暴走しても被害を最小化します。MCP呼び出しログをエージェント実行の時系列イベント基盤に統合すると、セッション単位で一連の追跡ができます。
企業内MCPの典型ユースケース
- 営業：案件検索、見積生成、提案資料ドラフト、商談議事録要約
- PMO：プロジェクトステータス取得、課題作成、リソース配分提案
- 採用：候補者検索、スカウト文生成、面接記録要約
- 経理：仕訳ドラフト、予実差異コメント生成、レポート初稿
- マーケ：競合調査、コンテンツドラフト、SNS投稿案生成
- カレンダー/メール：日程調整、要約、自動返信ドラフト
- 社内DX：従業員一覧、組織情報、社内ドキュメント検索
これらの業務で使うツールが数百件になると、定義をすべて読み込む構成ではコンテキストを消費します。業務領域別にMCPを分けても、全サーバの全ツールを読み込めば総数は減りません。現行Claude CodeのTool Searchは、ツール定義を必要時に読み込む仕組みで、対応モデル・接続先・設定により利用可否が変わります。業務ごとに接続先を限定し、対応クライアントではツール検索も用いて、実際の選択誤りを評価しながら構成を調整します。
MCP内製で陥りやすい4つの落とし穴
- 落とし穴1：ツール一覧をすべて1つのMCPに詰め込む。全ツール定義を常時読み込むとコンテキストを消費します。業務領域別の分割に加え、接続するサーバの限定や対応クライアントのツール検索・遅延読み込みを検討します。分割だけで選択精度や権限制御が保証されるわけではありません。
- 落とし穴2：認証を後回しにする。プロトタイプで認証なしのまま本番に持ち込まれると、社内全体のセキュリティ穴になります。
- 落とし穴3：呼び出しログを取らない。誰が何をしたか追えない状態では、ガバナンス対応ができません。
- 落とし穴4：1つのMCPに「破壊的ツール」と「読み取りツール」を混在させる。読み取り専用MCPと書き込み可能MCPを物理的に分離するほうが、権限管理が容易です。
企業内MCP内製で押さえておきたい3原則
- 業務領域単位でMCPを分割する：業務の責務・権限・更新単位に応じて粒度を決める。ツール件数だけを分割基準にせず、各セッションで有効にするサーバと読み込み方式も利用クライアントの仕様に合わせる
- 認証・権限・モニタリングを最初から組み込む：プロトタイプ段階から認証を入れ、本番化フェーズで追加するのは禁じ手とする
- ツール命名と説明文を徹底的に磨く：エージェントは命名とdescriptionからツールを選ぶため、ここの品質がそのまま実用性になる