情シス必見！MCPサーバー導入時のセキュリティ・ガバナンスチェックリスト

MCP（Model Context Protocol）サーバーは、生成AIが社内システムやSaaSの「ツール」を呼び出して業務を進めるための接続点です。便利になる一方で、情シス視点では「誰が・何に・どの権限で・いつアクセスし、何が実行されたか」を説明できない構成だと、稟議・監査・事故対応で詰みやすい領域でもあります。

この記事では、「MCPサーバーを社内利用に耐える形で導入するためのセキュリティ要件」を、RFPやベンダー比較に転用できるチェックリストとして整理します。特に、認証/権限（認可）/監査ログ/データ持ち出し対策にフォーカスします。

この記事で整理できる判断ポイント

• MCPサーバー導入で最低限確認すべきセキュリティ要件（SSO/MFA、最小権限、監査、DLP等）を一覧化できます。
• 「ツール実行」が絡むMCP特有のリスク（誤実行・権限越境・データ吸い上げ）に対する設計観点が整理できます。
• RFP・稟議で説明しやすい言い回し（責任分界、統制、運用）に落とし込めます。

向いているのは、生成AIを業務で使いたいが、社内システム連携や監査要件があり「野良連携」にしたくない企業です。逆に、監査ログが取れない／権限設計ができない場合は、MCP以前に運用統制の土台（ID基盤・権限管理・ログ保管）を整える優先度が高いです。

背景：MCPサーバーは「AI連携のハブ」になりやすく、統制が甘いと事故の影響範囲が広がる

MCPサーバーは、生成AI（クライアント）が業務ツール（例：チケット、CRM、ファイルストレージ、社内API等）を呼び出すための仕組みです。情シスが気にするポイントは、従来のAPI連携と似ているようで、次の点が難しくなりがちなことです。

• 人ではなくAIが実行主体になる（ただし責任は人・組織に帰る）。
• プロンプトやコンテキストにより実行内容が揺れる（同じ操作でも再現性が下がる）。
• 1つの連携口から多くのシステムへ到達できる（横展開が早い分、漏えい・誤実行の爆発半径が大きい）。

したがって、導入判断では「便利になるか」だけでなく、統制（ガバナンス）をどう実装し、運用で回せるかが主戦場になります。

全体像：MCPサーバー導入で押さえるべきセキュリティ設計の骨格

設計の全体像は、次の4レイヤーに分けて考えると整理しやすいです。

• 認証：誰がMCPサーバーを使えるか（SSO、MFA、端末条件など）。
• 認可（権限）：何のツールを、どの範囲で実行できるか（RBAC/ABAC、スコープ、最小権限）。
• 監査：いつ誰が何を実行し、どのデータに触れたか（監査ログ、証跡、保管）。
• データ保護：機密・個人情報をどう持ち出させないか（DLP、マスキング、出力制御、学習利用の扱い）。

さらにMCPは「ツール実行」が中心なので、ツール実行の権限境界（AIが勝手に強い権限で叩けない設計）を明確にする必要があります。

検討ポイント：認証（SSO/MFA/端末条件）

まずは「誰が使えるか」を堅くします。ここが曖昧だと、権限やログを頑張っても統制が破綻します。

確認すべき要件

• SSO（Single Sign-On）対応：SAML/OIDC等で社内IdP（Identity Provider）と連携できるか。
• MFA（多要素認証）：IdP側強制か、MCP側でも条件付けできるか。
• 条件付きアクセス：端末準拠（MDM/EDR）、社内ネットワーク/VPN、国・IP制限などが可能か。
• プロビジョニング：SCIM（System for Cross-domain Identity Management）等でユーザー/グループ同期ができるか。
• サービスアカウントの扱い：人のアカウント共有を禁止できるか、用途別の発行・棚卸ができるか。

稟議・監査で効く説明ポイント

• 「既存のID統制（入退社、異動、MFA、条件付きアクセス）に組み込める」
• 「ユーザー管理が個別運用にならず、棚卸可能」

検討ポイント：権限（最小権限、ツール実行の境界、接続先管理）

MCPサーバーの難所はここです。生成AIが呼べるツールが増えるほど、“できてしまうこと”が増えます。権限の設計不備は、情報漏えいだけでなく、誤操作（削除・更新）にも直結します。

基本方針：最小権限と「読み取り優先」

• 初期はRead中心（参照系ツール）に寄せ、更新・削除系は段階的に解放する。
• 更新系を入れるなら承認フロー（人の確認）や対象制限（特定プロジェクト/顧客/期間のみ）を併用する。

確認すべき要件（権限モデル）

• RBAC（Role-Based Access Control）：役割単位でツール利用可否を制御できるか。
• ABAC（Attribute-Based Access Control）相当：部門、雇用形態、端末状態、時間帯など条件で制御できるか（提供形態はベンダーにより差）。
• スコープ設計：ツールごとに「参照のみ」「作成まで」「管理者操作不可」等の粒度を切れるか。
• 接続先の許可リスト（Allowlist）：MCPサーバーが接続できるSaaS/API/ホストを限定できるか。
• 環境分離：開発/検証/本番で接続先・権限・秘密情報を分離できるか。

確認すべき要件（トークン・秘密情報管理）

• 秘密情報管理：APIキーやOAuthトークンをKMS/Secrets Manager等で安全に保管・ローテーションできるか。
• ユーザー委任（OAuth）：可能なら“サーバー共通権限”ではなく、ユーザー単位に委任し、取り消し可能にする。
• 期限・失効：トークン失効、短命トークン、利用停止が即時反映されるか。

MCP特有の論点：ツール実行を「安全に失敗させる」

• 実行前ガードレール：危険操作（全件削除、外部共有、権限付与等）をブロック/要承認にできるか。
• パラメータ検証：AIが生成する引数（対象ID、範囲、宛先）をサーバー側で検証・制限できるか。
• ツールの分類：参照系/更新系/管理系で明確に分け、管理系は原則禁止または強い制約。

検討ポイント：監査ログ（証跡、追跡性、保管）

導入後に最も効くのが監査ログです。インシデント対応だけでなく、監査・内部統制・運用改善に直結します。要件定義の段階で「何を、どの粒度で、どこに、どれだけ保管するか」を決めておくと、後戻りが減ります。

最低限ほしい監査ログ項目

• 認証イベント：ログイン成功/失敗、MFA、IP、端末/ユーザーエージェント。
• 権限変更：ロール付与/剥奪、ポリシー変更、接続先追加。
• ツール実行ログ：実行者（ユーザー/サービス）、ツール名、実行時刻、対象（リソースID等）、結果（成功/失敗）、レスポンス概要。
• データアクセスの要約：どのデータ分類に触れたか、件数、外部送信の有無（可能な範囲で）。
• プロンプト/コンテキストの扱い：全文保存は慎重（機密混入リスク）。保存する場合はマスキングや暗号化、閲覧権限の制御が前提。

ログ運用の要件

• 外部転送：SIEM等へ転送できる（例：Syslog、Webhook、クラウドログ連携）。
• 改ざん耐性：WORM（Write Once Read Many）相当、アクセス制御、保管先の権限分離。
• 保管期間：社内規程・監査要件に合わせて設定できる（期間の根拠も社内で合意）。
• 検索性：ユーザー・ツール・対象IDで追える。インシデント時に「追跡できること」が最重要。
• アラート：異常検知（大量実行、深夜実行、権限外エラー多発、外部共有操作など）のルール化。

検討ポイント：データ持ち出し対策（DLP、マスキング、学習利用の扱い）

「MCPサーバー セキュリティ」で最も問われやすいのが、機密・個人情報の扱いです。ここは技術だけでなく、データ分類と運用ルールがセットになります。

前提として決めること（データ分類）

• 対象データ：機密（営業秘密）、個人情報、社外秘、公開情報など。
• 利用可否：生成AIに入力してよい範囲（部門別・業務別）を明文化。
• 保存・学習：入力内容がモデル改善（学習）に利用される可能性の有無、オプトアウト可否、保存期間。

※法令・契約・規程の最終判断は、法務/コンプラ/個情担当とすり合わせてください（執筆時点の一般論です）。

技術的な持ち出し対策チェック

• DLP（Data Loss Prevention）：個人情報・機密の検知（正規表現/辞書/分類ラベル）とブロック/マスクが可能か。
• マスキング/トークナイズ：必要に応じて送信前に伏字化・置換できるか。
• 出力制御：回答に機密が混ざった場合の抑止（出力フィルタ、社内規程違反の検知）。
• 外部送信の制御：外部ドメインへの送信、外部共有リンク作成、メール送信などのツールを制限できるか。
• データのローカル保存抑止：クライアント側にキャッシュ/ログが残る設計になっていないか（端末要件とセット）。
• 暗号化：転送時（TLS）・保管時（暗号化鍵の管理）を満たすか。

委託先管理・データ越境

• サブプロセッサ（再委託先）の開示、変更通知、監査権限の扱い。
• データ保管リージョン、越境の有無、バックアップ/DR拠点。
• 契約条項：ログ提供、インシデント通知SLA、削除証明、データ返却。

導入ステップ：PoC→本番で「統制を先に作る」

PoCで価値検証だけを先行すると、本番でセキュリティ要件が原因で作り直しになりがちです。おすすめは、PoC段階から最低限の統制を入れるやり方です。

PoCの目的（例）

• 業務効果：一次対応率、処理時間、検索工数削減などKPIを設定
• 運用性：権限棚卸が回るか、ログ追跡できるか
• 安全性：危険操作をブロックできるか、DLPが機能するか

PoCで最低限入れたい統制

• SSO（可能ならMFA強制）
• ロール分離（利用者/運用者/管理者）
• ツールは参照系から開始、更新系は要承認
• ツール実行ログをSIEMまたはクラウドログに集約
• 機密データを扱う場合はマスキング or 対象外化

よくある失敗パターンと回避策

• 失敗：サービスアカウントで全ユーザーが強権限ツールを実行できる
  回避：ユーザー委任（OAuth）＋最小権限、ツールごとにスコープ分割
• 失敗：ログはあるが、誰が何をしたか追えない（関連付けできない）
  回避：ユーザーID・リクエストID・対象リソースIDを必須項目化、SIEMで相関検索できる形に
• 失敗：プロンプト/ログに機密が混入し、二次漏えい経路になる
  回避：保存方針を明確化（全文保存しない/マスクする）、閲覧権限を限定
• 失敗：PoCは成功したが、本番で監査・法務要件に合わず止まる
  回避：PoC時点でデータ分類・委託先条項・ログ保管要件を確認

RFP・ベンダー比較に使える：MCPサーバー セキュリティ・ガバナンスチェックリスト

以下は、社内説明やRFPにそのまま貼れる形を意識したチェック項目です（必要に応じて自社規程に合わせて調整してください）。

1. 認証（Identity）

• SSO（SAML/OIDC）に対応している
• MFA強制（IdP側含む）が可能
• 条件付きアクセス（IP/国/端末準拠/時間帯）を設計できる
• SCIM等でユーザー/グループの自動同期ができる
• 共有アカウントを禁止でき、例外運用（サービスアカウント）を管理できる

2. 権限（Authorization）

• RBACでツール利用権限をロールに紐付けられる
• ツールごとに操作種別（参照/作成/更新/削除/管理）の制御ができる
• 接続先（SaaS/API/ホスト）のAllowlistがある
• ユーザー委任（OAuth）を基本にできる／困難な場合の代替設計が提示される
• トークンの保管（Secrets管理）、ローテーション、失効が運用できる
• 開発/検証/本番で環境分離ができる（権限・秘密情報・接続先）

3. ツール実行の安全設計（MCP特有）

• 危険操作のブロック/要承認（ガードレール）を設定できる
• ツール引数の検証（範囲制限、ID形式、宛先ドメイン制限等）ができる
• 実行回数・レート制限、異常時停止（キルスイッチ）を備える
• エラーハンドリング（リトライ、失敗時の扱い）と運用手順が定義できる

4. 監査ログ（Auditability）

• 認証・権限変更・ツール実行のログが取得できる
• ログにユーザーID、時刻、ツール名、対象リソース、結果が含まれる
• ログの外部転送（SIEM等）に対応
• ログ保管期間・改ざん耐性（権限分離/WORM相当）を設計できる
• インシデント対応時に追跡できる検索性・相関IDがある

5. データ保護（DLP/マスキング/学習利用）

• データ分類（機密/個人情報等）に沿った制御が可能
• DLP（検知/ブロック/マスク）の適用が可能
• 入力・出力の保存方針（保存の有無、期間、暗号化、閲覧権限）が設定できる
• モデル学習への利用有無、オプトアウト、データ削除要請への対応が明確
• 外部送信（外部共有リンク、メール送信等）を制限できる

6. 運用・統制（ガバナンス）

• 権限棚卸（定期レビュー）の運用手順を作れる
• 変更管理（ツール追加、権限変更、ポリシー変更）の承認フローを設計できる
• 委託先管理（サブプロセッサ、インシデント通知、監査対応、SLA）が確認できる
• 責任分界（どこまでがベンダー/どこからが自社）が明文化される
• BCP/DR（バックアップ、復旧目標）が説明できる

まとめ：MCPサーバーは「認証・権限・監査・データ保護」を揃えて初めて社内展開できる

MCPサーバーの導入可否は、生成AIの精度以上に、ツール実行の権限境界と監査可能性で決まります。PoCの段階からSSO・最小権限・ログ・DLPの方針を入れておくと、本番移行が現実的になります。

一方で、要件が曖昧なまま進めると「どのログが必要か」「どこまでマスクすべきか」「委任認可をどう設計するか」で関係者調整が長期化しがちです。RFP作成やベンダー比較の前段として、要件整理から進めるのが近道です。

要件整理の段階からの相談（PoC設計、権限設計、監査ログ設計、委託先管理の観点整理など）も可能です。自社の前提（ID基盤、接続先SaaS、扱うデータ分類）に合わせて、チェックリストをRFPに落とすところまで一緒に詰められます。

SaaS連携基盤なら「JOINT」にお任せください

ストラテジットは 「AIとSaaSの力をすべての企業に」 をミッションに、連携ツールであり連携基盤でもあるJOINT シリーズを展開しています。
まずは “どんな連携が可能か知りたい” という段階でも、お気軽にご相談ください。

• SaaSベンダー向けiPaaS「JOINT iPaaS for SaaS」
  SaaSベンダーが自社製品に連携機能を簡単に組み込めるEmbedded iPaaS
  
• SaaS利用者向けiPaaS「JOINT iPaaS for Biz」
  SaaS利用企業向けのデータ連携・業務自動化ソリューション
  
• 生成AI連携基盤「JOINT AI Flow」
  AIが必要なデータを探し出し、業務フローに沿ってつなげる新しいAI連携サービス

これらのソリューションを通じて、ベンダー・利用企業双方に「つながる価値」を提供します。

自社SaaSの満足度を上げたいSaaSベンダー様、まずは話だけでも聞いてみたいといった企業様は、ストラテジットが提供する　『JOINT』プロダクトを是非ご検討ください。

◆無料相談はこちらよりお気軽にご連絡ください。
◆ストラテジットに関する詳細はこちら。