導入
MCPサーバ構築は、AIエージェントと社内システムの接続を“つなぎやすくする”点で大きな魅力があります。ですが、つながることと、安全に使えることは別問題です。ここを混同すると、導入後にガバナンス、権限、監査のどこかでつまずきます。
MCP（Model Context Protocol）は、Anthropicの公式ドキュメントで、AIアプリケーションと外部ツールやデータソースを接続するためのオープンなプロトコルとして説明されています。つまり、主眼は「接続の標準化」です。安全運用そのものを全部肩代わりする仕組みではありません。ここを最初に押さえる必要があります。［出典: Anthropic公式ドキュメント］
中堅〜大企業のIT部門でよく問題になるのは、PoCで動いたことが評価され、本番で必要な統制が後回しになることです。MCPサーバは一見シンプルに見えますが、実際には認証、認可、ログ、障害対応、バージョン追従まで含めて考えないと、運用負債が積み上がります。
この記事では、MCPサーバ構築を「どう作るか」ではなく、「なぜ危ういのか」という視点で整理します。特に、仕様の外側に残りやすい認可設計と、AI特有の非決定性が生むリスクに注目します。
MCPサーバ構築における「責任共有モデル」の再定義
MCPが解消する課題と、新たに生じる「実装者の責任」
MCPの価値は、ツール接続の作法を揃えられることにあります。個別APIごとに独自実装を積み上げるより、接続の考え方を共通化しやすい。これは大きな前進です。
ただし、標準化は責任の消滅を意味しません。むしろ、責任の置き場所が変わります。接続仕様が揃うほど、実装者は「このサーバは誰に何を許すのか」「どのデータを返してよいのか」を明確に定義しなければなりません。MCPは接続の共通言語であって、業務権限の自動判定装置ではないからです。
Anthropicの公式情報では、MCPはクライアントとサーバの間でコンテキストやツールをやり取りするためのプロトコルとして示されています。つまり、実運用で必要な細かな業務ルールは、各組織が自分で持ち込む前提です。［出典: Anthropic公式ドキュメント］
なぜ「動くサーバ」を作るだけでは不十分なのか
PoC段階では、ツールが呼べる、データが返る、ログが出る。この3点で「成功」に見えます。ですが本番では、そこから先が本番です。
- そのユーザーはそのデータに触れてよいのか
- その操作は実行してよいのか
- 失敗時に誰が気づくのか
- 仕様変更にどう追従するのか
この4つに答えられないサーバは、動いていても安心して使えません。特にMCPでは、複数のAIクライアントや複数の業務ツールが接続対象になりやすく、権限境界がぼやけやすい。接続点が増えるほど、責任の線引きは難しくなります。
エコシステムの未成熟さがもたらす仕様変更リスク
MCPは比較的新しいプロトコルです。新しい標準は、採用が進むほど周辺実装が増えますが、実装の成熟度は均一ではありません。
ここで注意したいのは、プロトコルそのものだけでなく、SDK、サンプル、周辺ツールも含めて変化が起きやすいことです。公式ドキュメントやリポジトリの更新に合わせて、実装方針を見直す必要が出る可能性があります。最新情報は公式ドキュメントで確認する運用が前提です。
特定すべき3つの潜在リスク：技術・セキュリティ・運用
認可（Authorization）の不在が生むデータ漏洩リスク
MCPサーバ構築で最も見落とされやすいのが、認可です。認証は「誰か」を確認しますが、認可は「何をしてよいか」を決めます。この違いは小さくありません。
MCPの接続が整うと、AIエージェントは複数のツールやデータソースにアクセスしやすくなります。そのとき、サーバ側で細かな業務権限を実装していないと、広すぎるアクセスがそのまま許可される危険があります。たとえば、閲覧だけ許されるはずの情報に、要約生成の過程で不要な詳細が混ざることもあります。
MCPの仕様に認可のすべてが含まれていると考えるのは危険です。実際には、トランスポート層の認証や周辺のID基盤だけでは足りず、各ツール単位での権限制御が必要になります。ここを設計しないまま本番化すると、漏えいは「攻撃」ではなく「仕様どおりの動作」として起きます。
プロンプトインジェクションによる「意図しないツール実行」
LLM連携の怖さは、入力がそのまま命令になるわけではないのに、結果として命令のように振る舞う点にあります。プロンプトインジェクションは、その代表例です。
MCPサーバがAIエージェントの実行経路に入ると、外部データに埋め込まれた指示がツール操作に影響する可能性があります。これは、メール本文、文書、チャット、Webページなど、自然言語を含むあらゆる情報源で起こりえます。
重要なのは、「AIが賢いから大丈夫」ではないことです。むしろ、賢いほど自然言語の意図を拾いやすく、不要な命令まで解釈する余地が生まれます。したがって、MCPサーバ側では、
- 危険な操作の明示的な承認
- ツール引数の厳格な検証
- 出力のサニタイズ
- 重要操作の分離
が欠かせません。
分散するMCPサーバ群の死活監視とガバナンスの欠如
MCPの採用が進むと、1つのサーバだけでなく、部門ごと、用途ごとに複数のサーバが増えやすくなります。ここで起きるのが、運用の見えにくさです。
サーバが増えるほど、障害の切り分け、バージョン管理、ログの集約、権限棚卸しが難しくなります。しかも、AIエージェント経由の呼び出しは、通常のAPI利用よりも経路が長くなりがちです。どこで失敗したのか、どのツールが遅いのか、誰の操作がきっかけだったのかを追跡できないと、現場はすぐに疲弊します。
ガバナンスが弱い状態でMCPサーバを増やすと、便利さよりも運用コストのほうが先に立ちます。これは技術の問題であると同時に、組織設計の問題でもあります。
リスク評価マトリクス：発生確率とビジネス影響度の可視化
開発環境と本番環境でのリスク許容度の違い
開発環境では、多少の権限の広さやログ不足は許容されやすいです。ですが、本番環境では話が違います。本番で重要なのは、正しく動くこと以上に、誤っても被害を小さく抑えられることです。
MCPサーバ構築の評価では、次の2軸で見ると判断しやすくなります。
- 発生確率: どれくらい起きやすいか
- ビジネス影響度: 起きたときにどれだけ痛いか
この2軸で見ると、優先順位がはっきりします。たとえば、監査ログ不足は発生確率が高く、影響も大きいことが多い。逆に、非常に特殊な機能の不具合は発生確率は低くても、起きたときの影響が大きい場合があります。
優先的に対処すべき「高影響・高頻度」の脆弱性パターン
実務上、先に潰すべきなのは以下です。
- 権限が広すぎるツール公開
- 重要操作の承認なし実行
- 監査ログの欠落
- 入力検証の甘さ
- 障害時のフェイルセーフ不在
この中でも、1と2は特に危険です。なぜなら、正常時には問題が見えにくいからです。事故が起きて初めて、権限設計の粗さが露呈します。
技術的負債としてのMCPサーバメンテナンスコスト
MCPサーバは、作って終わりではありません。APIの変更、ツールの追加、認可の見直し、監査要件の更新が続きます。
ここで見落とされがちなのは、保守の中心がコードだけではないことです。運用手順、権限台帳、監査証跡、障害連絡、例外処理の定義まで含めて保守対象です。これを軽く見積もると、導入後に「便利だが、維持が重い」状態になります。
「安全なMCPサーバ」を構築するための防御策と緩和策
Human-in-the-loopをどこに置くか
人間による承認は、全部に入れれば安全というものではありません。入れすぎると業務が止まります。重要なのは、止めるべき操作だけを止めることです。
たとえば、読み取り系の操作は自動化しやすい一方、削除、送信、更新、外部連携などの高リスク操作は承認対象にしやすい。Human-in-the-loopは、AIを止める仕組みではなく、AIの自動性にブレーキをかける仕組みとして設計すべきです。
サンドボックス化とAPIゲートウェイによるトラフィック制御
MCPサーバを直接本番APIに接続する構成は、見た目は簡単ですが、事故時の被害が大きくなります。そこで有効なのが、サンドボックス化とゲートウェイ制御です。
- サンドボックス化: 実行できる操作を限定する
- APIゲートウェイ: 通信を集中管理し、制御点を増やす
- レート制御: 異常な連続実行を抑える
- ルールベース検査: 危険な引数や宛先を止める
この構成にすると、MCPサーバが多少誤動作しても、被害を局所化しやすくなります。
ログ監査：誰が、いつ、どのMCPツールで何をしたか
監査ログは、あとで見るためだけの記録ではありません。事故を早く見つけるためのセンサーです。
最低でも、次の情報は追えるべきです。
- 実行主体
- 実行時刻
- 使用したツール名
- 入力内容の要点
- 結果とエラー
- 承認の有無
この粒度がないと、原因調査が遅れます。さらに、責任の所在も曖昧になります。AIエージェントの時代こそ、ログの価値は上がります。
残存リスクの許容と「構築しない」という選択肢
内製とマネージドの境界線
すべてを自前で構築することが正解とは限りません。むしろ、ガバナンス要件が厳しい組織ほど、どこまで内製し、どこから標準機能やマネージド基盤を使うかを慎重に分ける必要があります。
判断の目安は、次の3点です。
- 機密性の高いデータに触れるか
- 監査要件が厳しいか
- 運用担当者を継続的に確保できるか
この3つのうち2つ以上が重いなら、自前構築の魅力よりも、運用可能性を優先したほうがよい場合があります。
MCPエコシステムの将来予測と投資判断のタイミング
MCPは、今後も周辺実装や運用パターンが増える可能性があります。ただし、標準化が進むほど、導入のしやすさと運用の難しさは別問題として残ります。
今の段階で重要なのは、流行に乗ることではなく、次の問いに答えられることです。
- 権限設計を誰が維持するのか
- 監査要件に耐えられるか
- 仕様変更に追従できるか
- 事故時に止められるか
この問いに明確に答えられないなら、急いで構築しない判断も十分に合理的です。
まとめ
MCPサーバ構築は、AIエージェントと社内ツールの接続を標準化する有力な手段です。ただし、標準化は安全性の保証ではありません。認可、監査、運用、障害対応まで含めて設計しないと、便利さがそのままリスクになります。
特に注意すべきなのは、MCPの仕様だけでは埋まらない認可設計、プロンプトインジェクションへの備え、分散運用の管理です。ここを後回しにすると、本番での負担が一気に増えます。
まずは「動くか」ではなく、「守れるか」で評価することです。その視点があれば、MCPは単なる接続技術ではなく、業務自動化の基盤として扱えます。関連する論点としては、MCPプロトコルの基礎、Slack / Drive / Calendar連携、API × MCP連携設計も併せて整理すると、判断の精度が上がります。
コメント