2026.09.12
MCPサーバーで築く安全なAI連携基盤
IT関連
MCPサーバーは、生成AIを社内のデータや業務ツールへ安全かつ再利用可能な形で接続するための仕組みです。個別API連携を積み重ねるだけでは、エージェントの増加に伴って認証、仕様、運用の複雑さが急速に膨らみます。
AIが回答するだけでなく、検索、参照、申請、更新まで担うには、モデルが必要な能力を正しく発見し、許可された範囲で実行できる接続層が不可欠です。そこで注目されるのが、外部システムとの文脈共有を標準化するModel Context Protocolです。
本記事では、基本アーキテクチャ、AIエージェント連携の設計、RAG構築との使い分け、AI推論基盤への組込み方、AIエージェント安全を守る統制を順に説明します。小さく検証し、業務価値を測りながら拡張する実践手順も紹介します。
MCPサーバーとは何かを最初に理解する
標準化された接続層としての役割
MCPサーバーは、AIアプリケーションが外部の情報源や機能を利用する際の接続方式をそろえるサーバーです。モデルごと、SaaSごとに専用連携を作る代わりに、能力の公開方法と呼び出し方を共通化します。
MCPは3つのコンポーネントで構成されています。利用者側のホスト、接続を担当するクライアント、能力を提供するサーバーが役割を分けるため、AIアプリを変えても連携資産を再利用しやすくなります。
Anthropicが2024年11月に公開したMCPは、AIアプリケーションと外部システムをつなぐオープンな仕様です。ただし、標準化は無審査の実行を意味しません。提供する操作と利用者の権限は、業務側で厳密に設計します。
- ホスト：会話体験やエージェント実行を担うアプリケーション
- クライアント：サーバーごとの接続とセッションを管理する層
- サーバー：データ参照・業務操作・定型指示を公開する層
Tools・Resources・Promptsの違い
MCPで公開する能力は、用途に応じてTools、Resources、Promptsへ分けるのが基本です。三者を混在させず、読み取り、実行、対話の補助を分離すると、モデルの選択精度と監査性を高められます。
Toolsは、チケット作成や在庫照会のように処理を実行する入口です。入力スキーマ、説明文、戻り値を具体化し、曖昧な「何でも更新できるツール」を避けます。副作用がある操作には、確認画面や承認を挟むべきです。
Resourcesは、Google Drive, SharePointの文書や、PostgreSQL, SQL Serverの参照情報を文脈として渡す用途に向きます。Promptsは、定例報告の作成手順など、利用者が選べる定型的な指示を提供する役割です。
- Tools：外部処理を行う操作インターフェース
- Resources：モデルに読ませる参照可能な文脈
- Prompts：再現性ある対話の出発点
通信とリクエストの流れ
通信の中心はJSON-RPC 2.0です。クライアントはサーバーの能力一覧を取得し、モデルが必要性を判断した後に、引数を付けてツールやリソースを要求します。戻り値は会話や次の推論に利用されます。
ローカル環境では標準入出力、ネットワーク越しではStreamable HTTPやServer-Sent Events (SSE)を選べます。双方向性、接続の継続時間、社内ネットワークの制約を見て、運用しやすいトランスポートを決めることが重要です。
典型的な処理は、能力の発見、入力の検証、認可、外部システム実行、結果の返却、監査ログ記録という順序です。モデルの出力をそのまま実行せず、サーバー側で業務ルールとスキーマ検証を必ず通します。
- 能力の発見：利用可能なツールと説明を取得
- 実行前検証：型・必須項目・権限を確認
- 結果の記録：呼び出し元、引数、結果、失敗理由を保存
AIエージェント連携を業務成果につなげる
連携対象は業務の判断点から選ぶ
AIエージェント連携は、会話AIに多くのシステムをつなぐことではありません。担当者が情報を探し、照合し、次の処理を決める判断点を選び、その一連を短縮することが目的です。まずは頻度が高く、効果を測れる業務から始めます。
たとえば「先月の売上を取引先別に集計し、上位5社に対する未回収を抽出してメールの下書きを作る」という業務は有効な候補です。CRM、販売管理、会計、メールをまたぐため、参照と下書きを分けたツール設計が求められます。
接続先にはSalesforce, SAP、Slack, Teams、Jira, Linear, Notionなどがあります。ただし、全データを一度に公開する必要はありません。部門、用途、個人情報の有無で対象を絞り、読み取り専用の価値から検証します。
- 情報探索：案件・契約・履歴を横断して要約
- 判断支援：条件に合う対象を抽出して根拠を提示
- 業務実行：承認済みの定型処理だけを起票・更新
コンテキスト量とマルチエージェントの判断
複数の担当を置く構成は、単体のエージェントでは検証しにくい複雑な仕事で有効です。一方で、役割を増やすほど呼び出し回数、待ち時間、障害点が増えます。最初から多数にせず、明確な専門性がある場合だけ分割します。
Claude 3.5 Sonnetで200Kトークン、GPT-4oで128Kトークンを扱えても、長い文脈を無差別に渡す設計は適切ではありません。必要なデータだけを取得し、要約、出典、期限を付けて、推論に不要な情報を減らします。
Google DeepMindの研究（2024年）では、議論型マルチエージェントを使った数学問題の解答精度が、シングルエージェントに比べて15%向上しました。業務でも同様に、実装役とレビュー役など、検証目的が明確な2〜3体から評価するのが現実的です。
- 単体構成：定型照会、限定的なデータ取得
- 2〜3体構成：作業とレビューを分離する業務
- 多人数構成：明確な分業・調整役・評価基準がある場合
API・iPaaS・MCPを使い分ける
MCPは既存APIを置き換えるものではなく、AIが安全に能力を発見・利用するための接続面です。基幹処理そのものは安定したAPIで提供し、エージェント向けには用途を限定したMCPのツールとして公開する構成が堅実です。
3つのアプリが5つのサービスと連携するとき、最大15の個別実装が必要になります。共通の接続規約を採ることで、各アプリがサービスごとの独自形式を抱え込む負担を減らし、変更の影響範囲も抑えられます。
iPaaSは定型ワークフローの接続、RPAは画面操作しか手段がないレガシー対応に向きます。MCPはエージェントが状況に応じて能力を選ぶ場面に適します。方式を競合させず、責任範囲で組み合わせることが重要です。
- API：業務機能を安定提供する基盤
- iPaaS：決まったイベントと処理の自動化
- MCP：AIが文脈に応じて選ぶ能力の公開
AIエージェント設計で失敗しない境界を決める
目的と成功条件を先に固定する
AIエージェント設計では、モデル選定より先に「誰の、どの判断を、どこまで支援するか」を固定します。成功条件を曖昧にすると、便利そうなツールが増える一方で、利用者が責任を持てない自動化になりやすいためです。
基本形は、AI エージェント = LLM + メモリ + ツール + 計画機構です。これに入力制約、承認者、停止条件、監査ログを加え、利用者が途中で確認・修正・取り消しできる体験まで設計します。
感知（Sense）、推論（Reason）、計画（Plan）、調整（Coordinate）、実行（Act）、改善（Improve）の循環で考えると、問題の所在を切り分けやすくなります。誤答なのか、データ不足なのか、ツールの権限過大なのかを別々に評価できます。
- 成果指標：処理時間、一次回答の採用率、差し戻し率
- 境界条件：実行可能な業務、禁止操作、承認が必要な操作
- 停止条件：上限回数、予算、タイムアウト、例外検知
ツールを小さく、意味を明確に公開する
良いツール設計とは、自然言語の要求を安全な業務操作へ変換しやすくすることです。「顧客情報を操作」のような広い機能ではなく、「担当顧客の未払い請求を一覧する」のように、目的と対象範囲を小さく切ります。
ツール説明には、利用してよい条件、引数の型、返却する項目、失敗時の挙動を含めます。モデルが説明を誤解しても、サーバーが入力を拒否できるようにし、更新系の操作は冪等性キーや確認トークンを使います。
開発を始める場合は、公式SDKと既存の認証基盤を優先します。たとえば npm install @modelcontext/mcp-framework の後、version: “1.0.0” の小さなサービスとして読み取り専用ツールを実装し、テストとログを整えてから対象を広げます。
- 粒度：1ツールにつき1つの業務意図を原則にする
- 入力：JSONスキーマで必須値と許容範囲を制限
- 出力：判断根拠、更新結果、次の行動を分けて返す
評価は会話品質と実行品質を分ける
評価すべきなのは回答の自然さだけではありません。AIエージェント設計では、正しいツールを選べたか、正しい引数だったか、権限外の実行を止めたか、結果を根拠付きで説明できたかを個別に測定します。
実業務に近い評価データを作り、正常系、曖昧な依頼、権限不足、外部障害、悪意ある入力を含めます。テストカバレッジが80%を超えたら止める(閾値)のように、品質とコストの両方に停止基準を置きます。
本番では、要求からツール実行、応答までを追跡できるトレースを残します。失敗をモデルの問題と決めつけず、プロンプト、検索結果、サーバー応答、認可判定を確認することで、継続的な改善が可能になります。
- 正確性：業務上正しい結論・処理に到達した割合
- 安全性：拒否すべき要求を適切に拒否した割合
- 運用品質：遅延、失敗、再試行、承認待ちを可視化
RAG構築とMCPの役割を分けて活かす
RAGは根拠検索、MCPは行動の接続である
RAG構築は、社内文書を検索して関連箇所をモデルへ渡し、回答の根拠を補う手法です。一方、MCPは文書検索に限らず、データ取得や業務操作を能力として公開します。両者は競合ではなく、役割が異なります。
規程の内容を答える業務なら、RAG構築で文書チャンク、メタデータ、アクセス権を整えることが中心です。申請状況を確認して差し戻し通知を作る業務なら、検索結果に加えて、申請システムを呼ぶMCPツールが必要になります。
回答には参照元、更新日時、適用範囲を添え、検索結果が不十分なら「不明」と返す設計にします。MCP経由で取得した最新データも、表示範囲と利用目的を制限することで、回答の信頼性と安全性を両立できます。
- RAG：非構造文書から関連する根拠を検索
- MCP Resources：必要な文脈を参照可能な形で公開
- MCP Tools：照会・作成・更新などの操作を実行
データ層と実行層を分離する
RAG構築を安定させるには、検索用のデータ層と、業務を変更する実行層を分離します。検索インデックスに更新権限を持たせず、実際の更新は認可を備えた業務APIとMCPツールだけが行う形が分かりやすい境界です。
文書には部署、機密区分、契約状態、有効期限などのメタデータを付けます。検索前の権限フィルタリングを行えば、モデルに渡す前に対象外文書を除外でき、単なる回答制御より堅い情報保護になります。
業務データは鮮度が重要です。定期同期した検索結果だけで在庫や請求額を断定せず、必要な場面ではMCPの読み取りツールで原本を照会します。検索は理解の補助、原本照会は確定判断という役割分担が有効です。
- 検索前：利用者の権限に応じて候補を絞る
- 生成前：根拠と対象期間をプロンプトへ明示
- 実行前：原本再照会と承認で更新対象を確定
回答から実行までを段階的にする
安全な導入では、まず検索・要約・下書きまでを提供し、更新や送信は人が確認してから実行します。この段階化により、検索精度、ツール選択、現場の受容性を別々に検証でき、誤操作の影響を限定できます。
たとえば、エージェントが就業規則を検索し、休暇申請の不足項目を示し、申請内容を下書きするところまでは自動化できます。提出処理は本人確認と最終承認の後に限定ツールで実行すれば、利便性と統制を両立できます。
ALION株式会社のように業種を問わずシステム開発を支援する体制では、既存業務の見える画面だけでなく、認証、データ連携、例外処理まで確認することが重要です。AI機能を後付けする際ほど、既存システムの責任境界を丁寧に整理します。
- 第1段階：検索、要約、分類、回答案
- 第2段階：下書き、候補提示、担当者への通知
- 第3段階：承認付きの登録、送信、更新
AI推論基盤とAIエージェント安全を運用に落とす
推論基盤はモデル以外の制御面が重要
AI推論基盤は、モデルAPIを呼ぶだけの環境ではありません。利用者認証、プロンプトとツールの制御、秘密情報管理、レート制限、ログ、監視、障害対応をまとめ、エージェントを継続運用するための制御面です。
MCPサーバーはこの基盤の境界に配置し、モデルに直接データベース資格情報を渡さないようにします。サーバーが呼び出し元を識別し、権限に応じた短期トークンで下流システムへ接続する構成が基本になります。
開発・検証・本番では、接続先、データ、認可設定を分離します。Kubernetes, AWS上に配置する場合も、ネットワーク経路、シークレット、監査ログの保管先を環境別に分け、検証用の誤設定が本番へ持ち込まれないようにします。
- 制御面：認証、認可、ポリシー、ログ、監視
- 実行面：モデル推論、ツール呼び出し、データ取得
- 運用面：障害対応、変更管理、評価、コスト管理
最小権限と認可を多層で実装する
AIエージェント安全の要点は、モデルを信用するのではなく、権限を技術的に狭めることです。利用者、エージェント、MCPサーバー、下流システムの各段階で認可し、どこか一つの判定漏れで全権限にならないようにします。
認証・委任にはOAuth 2.0やOAuth 2.1を用い、利用者の権限を引き継ぐ方式を検討します。加えてRBACで職務ごとの操作を制限し、読み取りと更新を分け、顧客データや機密ファイルには属性条件を追加します。
TLSで通信を保護するだけでは十分ではありません。WAF、DLP、入力検証、出力マスキング、監査ログを組み合わせ、プロンプトインジェクションや意図しない情報流出に備えます。秘密情報はモデル文脈へ入れないことが原則です。
- 認証：誰が要求しているかを確認
- 認可：何を読めて、何を実行できるかを判定
- 監査：誰が、いつ、何を要求し、どう処理されたかを記録
小さな検証から本番運用へ進める
導入は、読み取り専用で対象データを限定したパイロットから始めるべきです。利用回数だけで成功とせず、回答根拠の妥当性、作業時間、差し戻し、権限拒否、障害時の復旧を確認し、利用部門と合意した基準で次段階へ進みます。
実装候補を比較する際は、接続可能なデータ、認証方式、監査性、運用責任、障害分離、コスト、拡張性、サポートを含む8 criteriaで評価します。機能数だけで選ぶと、後から認可や監視の不足が運用負債になります。
本番後もツール説明、アクセス権、評価データを更新し続けます。業務ルールや組織変更に追従できなければ、当初安全だった連携も危険になります。AI推論基盤の改善は、モデル更新より先に権限と監査を点検する習慣から始まります。
- 検証対象：限定部門、限定データ、読み取り専用
- 判定基準：品質、時間、安全拒否、復旧可能性
- 拡張条件：承認手順、責任者、ログ確認方法の確立
まとめ
MCPサーバーは、AIを業務データと操作へつなぐための標準化された接続層です。価値を引き出すには、RAGの検索基盤、エージェントの役割設計、推論基盤の認可・監査を分離し、それぞれの責任境界を明確にする必要があります。
要点
- Tools・Resources・Promptsを分け、能力を小さく明示的に公開する。
- AIエージェント連携は、効果測定できる判断点から読み取り専用で始める。
- RAG構築は根拠検索、MCPはデータ参照・業務実行の接続として組み合わせる。
- OAuth 2.0、最小権限、監査ログを前提にAIエージェント安全を設計する。
- AI推論基盤ではモデル性能だけでなく、認可、可観測性、変更管理を継続運用する。
まずは、現場で繰り返される情報照会を1つ選び、参照可能なデータ、必要な権限、成功条件を書き出してください。その結果を基に、既存システムを理解した開発チームと小規模なMCP接続を検証すると、安全で拡張しやすい導入計画を作れます。
よくある質問
Q1. MCPサーバーとAPIの違いは何ですか？
APIは業務機能を提供する一般的な接続口であり、MCPサーバーはAIが利用できるツール、リソース、プロンプトを標準的に公開する接続層です。実運用では、既存APIをMCPツールの背後で利用する構成が一般的です。
Q2. MCPサーバーだけでRAG構築は不要になりますか？
不要にはなりません。RAG構築は文書から根拠を検索する仕組みで、MCPは検索・参照・実行の能力をAIへ公開する仕組みです。社内規程の回答ではRAGを使い、最新の申請状況照会ではMCPツールを使う、といった併用が有効です。
Q3. MCPサーバー導入で最初に作るべき機能は何ですか？
更新を伴わない、限定データの読み取りツールから始めるのが安全です。利用者、対象データ、入力項目、返却項目、権限、監査ログを明文化し、回答品質と業務時間の改善を確認してから実行系へ広げます。
Q4. AIエージェント安全のために最低限必要な対策は何ですか？
利用者認証、最小権限の認可、入力スキーマ検証、更新前の承認、監査ログを最低限の要件にしてください。さらに、プロンプトインジェクションを想定し、モデルの出力だけで権限判定や業務更新を行わない設計が必要です。
Q5. マルチエージェントは最初から必要ですか？
必ずしも必要ではありません。単一エージェントで要件を満たすなら、その方がコスト、遅延、障害解析を抑えられます。作業とレビューの分離など、役割分担による検証効果が明確な場合に2〜3体から試すのが適切です。
参考文献・出典
 [このページの本文へ](#main) # MCPサーバーとは？AIと業務データをセキュアに接続する構築・運用ガイド Yazhini Gopalakrishnan,…
ascii.jp
[Home](/) > [Infosec Essentials](/infosec-essentials) > What Is an MCP Server? Definition, Architecture & How It Works # What Is an MCP Server? Definition,…
www.cyberhaven.com
Close […
www.bitsight.com