MCPサーバー導入の7ステップ|セキュリティ審査で迷わない進め方

CData Connect AI ブログ「MCPサーバー導入の7ステップ|セキュリティ審査で迷わない進め方」のタイトルカード

この記事でわかること


・AIエージェントを業務システムにつなぐMCPサーバーを、セルフホストでなくマネージドMCPで導入する理由
・データソースの棚卸しからID連携、サンドボックス、段階展開までの7ステップと、導入前に決めておく4原則
・稟議・セキュリティ審査に持っていける導入前チェックリストと、避けたい失敗パターン



最終更新: 2026年11月

AIの活用を社内に展開する際、多くの企業が突き当たるのが「AIエージェントを業務システムにどうつなぐか」という問題ではないでしょうか。エージェントが役に立つには、業務データへ社内のルールを守ったままリアルタイムでアクセスできる必要があり、そのためModel Context Protocol(MCP)をどう導入するかが情シス部門の優先課題になっています。導入後にMCPの活用をどう広げていくかは、MCP連携のロードマップ(英語)が参考になります。

MCPサーバーを用意する方法は、大きく分けて2つあります。自社でサーバーを立てて運用するセルフホストと、クラウドで提供されるマネージドMCPです。

セルフホストは一見手軽です。オープンソースのMCPサーバーを動かすだけなら、すぐにでも試せそうに思えます。ところが社内の業務で使い始めると、認証の組み込み、ログの保管、障害対応と、運用の作業が一気に積み上がります。権限の設定を誤れば、そのままセキュリティ事故の入口にもなります。一方、CData Connect AIのようなマネージドMCPは、SSO(シングルサインオン)・監査ログ・監視の機能を最初から備えています。そのため、短期間で本番に近い形で使い始められます。

どちらを選ぶにしても、情シスの責任者が確認すべき点は3つに絞れます。セキュリティ、ガバナンス、そしてリアルタイムなデータ接続です。本記事の7ステップは、この3点を順に固めていくための手順です。

MCPとは?ゲートウェイとフェデレーションの役割は?

MCPは、AIモデルと業務システムのあいだをつなぐ共通の規格です。Linux Foundation傘下のAgentic AI Foundationが管理するオープンな標準で、AIエージェントが社内のツールやデータソースに安全に接続するための取り決めを定めています。

規格が共通なので、MCPに対応したAIクライアントであれば、製品が違っても同じMCPサーバーを経由して業務データにアクセスできます。AIクライアントごとに個別の接続を作り込む必要はありません。

企業で本格的に運用する段階になると、次の2つの考え方が出てきます。7ステップの中でも繰り返し使う言葉なので、ここで整理しておきます。

  • ゲートウェイ:AIエージェントとツールのあいだに置く中央の層です。接続の管理、認証、レート制限、コンプライアンスへの対応をここでまとめて引き受けます。

  • フェデレーション:リージョンや事業部門ごとに置いた複数のゲートウェイが互いを自動で見つけ、ツールの登録情報を共有する仕組みです。

従来のAPI Gatewayとの違いが気になる方は、API GatewayとMCP Gatewayの特徴と選定基準もあわせてご覧ください。

MCPと従来のAPIの違いは?

APIはシステムごとに個別の接続を作り込みますが、MCPはAIクライアントとツールをつなぐ共通規格です。一度用意したMCPサーバーを、複数のAIから使い回せる点が大きな違いです。

観点

従来のAPI連携

MCP

接続の作り方

システムとアプリの組み合わせごとに個別に実装します

共通規格に沿ったMCPサーバーを1つ用意します

主な利用者

アプリケーションやバッチ処理です

AIエージェントやAIアシスタントです

認証・権限

連携ごとにAPIキーやトークンを管理します

ゲートウェイでSSO・OAuthを一元管理できます

再利用性

連携先が増えるたびに開発が必要です

MCP対応のAIクライアントなら同じ接続を使えます

CData Connect AIのマネージドMCPでは、既存のRBACやSSOの設定をそのまま引き継いでAIに業務データを渡せます。

導入前に決めておく4つの原則は?

手順に入る前に、押さえておきたい原則が4つあります。MCP導入でよくある課題の多くは、この準備を飛ばしたことに原因があります。最初に決めておけば、後から作り直す手間を減らせます。

  • IDと最小権限を最優先にする:固定のパスワードや、複数人で使い回す認証情報は使いません。社内のSSOに加え、PKCE(認可コードの横取りを防ぐ拡張仕様)を組み合わせたOAuth 2.1(MCPの認可仕様のベース)と、スコープを絞ったトークンで認証します。

  • ツールスキーマを重要な資産として管理する:スキーマはバージョン管理し、名前空間で明確に区別します。似た名前のツールが2つあり、エージェントがどちらを呼べばよいか判断できなければ、その時点で処理は止まります。

  • 可観測性とコンプライアンスは初日から組み込む:リアルタイムのログと、改ざんできない監査証跡が必要です。個人情報保護法への対応や社内のセキュリティ審査、SOC 2などの監査では、どれも後付けでは説明できません。

  • 止まらず、待たせない設計にする:時間のかかる処理には非同期のタスクハンドルを、障害にはサーキットブレーカーを使います。複数リージョンにまたがる場合はフェデレーションでゲートウェイ同士を連携させ、負荷を分散します。

この4つを決めたら、いよいよ7つのステップです。

MCPサーバー導入の7ステップは?

マネージドMCPの導入は、次の7つの手順で進めます。前のステップで決めたことが次のステップの前提になるので、順番どおりに進めるのが近道です。

  1. AIにつなぐデータソースとツールを棚卸しする

  2. MCPのデプロイモデルを選ぶ

  3. IDを軸にしたセキュリティとアクセス制御を組む

  4. ツールをサンドボックスで隔離し、コンプライアンスに備える

  5. ツールのバージョン管理・文書化・タグ付けを決める

  6. パイロットで検証し、性能を測る

  7. 監査ログを整え、段階的に展開する

ステップ1:AIにつなぐデータソースを棚卸しする

最初に確認しておきたいのは、社内のデータベースをすべてAIにつなぐことがゴールではない、という点です。つなぐ対象を業務に必要なものに絞るほど、セキュリティリスクは下がり、連携の作業も早く終わります。棚卸しは一覧を作る作業ではなく、何をつなぐかを選ぶ作業です。

まず、AIエージェントが必要とするアプリケーション・API・リアルタイムデータのソースを洗い出します。次に、それぞれを2つの軸で分類します。1つはデータの機密度(個人情報、財務、業務)、もう1つは求められる応答の速さと可用性です。この分類表を作ると、追加のガバナンスが必要なデータソースと、リアルタイム性が求められるデータソースがひと目で分かります。

国内の企業であれば、最初の候補に挙がりやすいのは、kintoneやSalesforceといったSaaS、SharePointに置いた文書、部門ごとに管理しているExcelファイルです。CData Connect AIはこうした多様なデータソースに接続できるので、個別の連携を作り込んだり、複雑なデータパイプラインを保守したりする必要がありません。

棚卸しは情シスだけで完結させず、業務部門と一緒に進めてください。現場でデータが実際にどう使われているかは、業務部門の担当者がいちばんよく知っています。また、一度作って終わりにせず、データソースや業務フロー、AIの取り組みが変わるたびに更新します。

ステップ2:MCPのデプロイモデルを選ぶ

つなぐ対象が決まったら、MCPをどの形で動かすかを決めます。選択の決め手は、企業の規模、規制の要件、そして社内の体制です。企業環境でのMCP実装では、先に整理したゲートウェイとフェデレーションの組み合わせ方で、主に3つのモデルに分かれます。

デプロイモデル

向いている企業

長所と短所

マネージド(クラウド提供)のMCPサーバー(CData Connect AI)

早く展開したい、セキュリティ機能を最初から備えたい多くの企業

長所:MCPサーバーを自社で立てて保守する必要がなく、短期間で使い始められます。企業向けのセキュリティ機能を備えています。

短所:第三者のクラウドでホストされるため、外部ネットワークから完全に切り離した環境には向かない場合があります。

エンタープライズゲートウェイ

ハイブリッド環境や拠点ごとの環境をつなぐ中堅〜大企業

長所:環境が分かれていても、認証と監視を一か所に集約できます。

短所:クラウドとオンプレミスのツールを橋渡しするため、ネットワーク設計に手間がかかります。

セルフホストのフェデレーションゲートウェイ

専任のセキュリティエンジニアリングチームが成熟している企業

長所:データを完全に自社で管理でき、分散したチーム間でフェデレーションを組めます。

短所:運用の負荷が大きく、専門チームがいなければ機密データを扱う業務にはリスクが高くなります。

セルフホストに惹かれる場合は、成熟した専任のセキュリティエンジニアリングチームが社内にいるかどうかで判断してください。企業規模ごとの判断軸は、内製と外注のどちらを選ぶかの3つの判断軸で詳しく整理しています。

ステップ3:IDを軸にセキュリティとアクセス制御を組む

デプロイモデルが決まったら、誰が、どのツールを呼び出せるかを確定させます。まず、MCPの基盤を社内のIDプロバイダー(英語)につなぎます。Okta、Microsoft Entra ID、Google Workspaceなどと連携し、OAuthとOIDC(OpenID Connect)の認証フロー、PKCE、同意画面を使えるようにします。

CData Connect AIはさらに一歩進んで、パススルー型の認証を採用しています。エージェントが動くときも元のシステムの権限がそのまま引き継がれるため、既存のRBAC・OAuth・SSOのポリシーを変えずに運用できます。既存の権限を保ったままAIへ業務データを公開する考え方については、MCPのセキュリティ対策の解説も参考になります。

この土台ができたら、次の4項目を順に確認します。

  1. SSOを連携する:MCPのゲートウェイをIDプロバイダーにつなぎ、固定のパスワードを使わないようにします。

  2. RBAC(ロールベースのアクセス制御)を定義する:権限を細かく設定し、各エージェントが必要なツールだけを見られるようにします。

  3. 同意フローを入れる:機密性の高い操作には、人の承認を必須にします。

  4. 監査ログを有効にする:すべてのツール呼び出しとデータへのアクセスを、改ざんできない形で記録します。

ステップ4:ツールをサンドボックスで隔離する

ステップ3のアクセス制御が決めるのは、誰がシステムに入れるかまでです。AIエージェントやツールが中に入ったあと、実際に何を見て何をしてよいかは、別のルールで縛る必要があります。

そこで使うのがサンドボックスです。素性がよく分からないツールや、まだ信頼しきれないツールに専用の実行場所を与え、基幹システムや機密データに直接触れられないようにします。具体的には次の2つを実施します。

  • 個人情報の検出とマスキング:プラットフォームの組み込み機能や外部のセキュリティ製品を使い、個人情報がAIモデルに届く前にマスキングまたは削除します。

  • 厳格なサンドボックス化:ツールの実行環境を社内ネットワークから切り離します。そのうえで、実行時の監視、脅威の検知、プロンプトインジェクションのフィルターを加えます。

ステップ5:ツールのバージョン・文書・タグを管理する

安全性を固めたら、次はツールが増えても壊れない仕組みを作ります。準備の原則で触れたとおり、似たツールをエージェントが区別できなくなると処理は止まります。それを防ぐのが、バージョン管理・文書化・タグ付けです。

  • 命名とバージョンを統一する:finance.reportやcrm.Contact:writeのように中身が分かる名前空間を使い、セマンティックバージョニングで変更点を追いやすくします。

  • きちんと文書化する:ツールの機能、パラメーター、変えない約束事(契約)を書き出します。よく使うクエリのロジックを、ガバナンスの効いた仮想テーブル(派生ビュー)に集約しておくと、どのツールから呼んでもエージェントの動きがそろいます。Connect AIでの手順は派生ビューの作り方(英語)を参照してください。

  • 環境ごとにタグを付ける:prod・dev・betaのタグで区別し、主系のツールが失敗したときの代替先も決めておきます。

  • 設定を一か所にまとめる:.mcp.jsonやmanaged-mcp.jsonのような設定ファイルをバージョン管理します。

ステップ6:パイロットで検証し、性能を測る

ここで陥りやすいのが、すべてを一度に本番へ移そうとすることです。早く成果を出したいところですが、避けたいのは全範囲を一気に移すことです。範囲を区切ったパイロットを重ねるほうがリスクは小さく、チームも自信を持って本番を迎えられます。

パイロットのたびに、次の枠組みを繰り返します。

  • 対象を絞る:少人数のユーザーと、止まっても業務に響かないデータの流れから始めます。

  • 測る指標を決める:ツールの呼び出し回数、エラー率、レイテンシを記録します。

  • 時間のかかる処理を工夫する:MCPのタスクハンドルを使い、処理の呼び出しと結果の受け取りを分けます。結果を待ち続ける必要がないので、AIは裏で処理を進められます。応答が遅すぎる処理は、サーキットブレーカーで打ち切ります。

  • 結果を見える化する:ダッシュボードに集約しておくと、チューニングや切り戻しの判断が早くなります。

ステップ7:監査ログを整え、段階的に展開する

監査ログはSIEM(セキュリティ情報イベント管理)に送り、利用状況とコンプライアンスをリアルタイムで監視できるようにします。CData Connect AIは監査ログの機能を備えているので、この作業の多くを省けます。全社に広げる前に、小さく始め、セキュリティチェックを済ませ、問題が起きたときの切り戻し計画を用意してください。

段階的な展開は、一般に次の4つのフェーズで進めます。

  1. 限定部門での本番運用:パイロットで確認した範囲を、限定した部門の本番業務に移します。ログは詳しめに取り、基準となる数値を記録します。

  2. 見直しと調整:SIEMのログを確認し、利用者の声を集め、スキーマを手直しします。

  3. 対象の拡大:業務価値の高いツールをサンドボックス内で開放し、利用部門を増やします。

  4. 全社展開:厳格なRBAC、脅威の自動検知、コンプライアンスの継続監視を前提に、全社へ広げます。

導入前チェックリスト:稟議・審査の前に確認すること

7つのステップを、稟議やセキュリティ審査で説明しやすい形に並べ直すと、次のようになります。

  • AIにつなぐデータソースを、機密度と求められる鮮度で分類したか

  • セルフホストを選ぶ場合、運用を担えるセキュリティチームが社内にいるか

  • 固定のパスワードや共有の認証情報を使わず、IDプロバイダー経由のSSOで認証しているか

  • エージェントごとに、必要なツールだけを使えるよう権限を絞ったか

  • 機密性の高い操作に、人の承認を挟んでいるか

  • すべてのツール呼び出しを、改ざんできない監査ログに残しているか

  • ツール名に名前空間とバージョンを付け、似た名前のツールを区別できるか

  • パイロットの対象・指標・切り戻し計画を決めたか

MCP導入でよくある失敗パターンは?

反対に、避けたい進め方もはっきりしています。

  • 固定の共有APIキーで接続する:誰がいつ何を呼び出したかを追えなくなり、監査が成り立ちません。

  • 体制がないままセルフホストする:成熟したセキュリティチームがいなければ、運用の負荷とリスクを抱え込むことになります。

  • コネクタを自作してしまう:独自のアダプターは、時間がたつほど技術的負債になります。ベンダーが提供するコネクタを使うほうが、保守の手間を抑えられます。

  • 一度にすべてを移す:パイロットを飛ばして全社に広げると、問題が起きたときに原因を絞り込めません。

  • サーキットブレーカーなしで複数のエージェントを動かす:1つの処理の遅れや失敗が、ほかのエージェントにも連鎖します。

マネージドMCPプラットフォームで何が変わる?

ここまでの7ステップを自社だけで組み上げるのは、正直なところ骨が折れ、工数のかかる作業です。CData Connect AIは、これらの手順を1つのマネージドMCPの層にまとめて提供します。数百のデータソースに対応したコネクタ、IDを軸にしたパススルー型のセキュリティ、すべての操作を追える監査証跡をそろえています。パイロットを早く回し、運用のリスクを下げるための土台として使えます。

たとえばヘルスケア領域のある専門商社では、コミュニティ版のMCPサーバーではなく、SOC 2 Type IIなどのセキュリティ基準を満たした提供元のMCPサーバーを選びました。社内システムのデータをSQLで扱える形にしてAIへ渡すことで、誤った回答のリスクを抑えながら、5,100万件を超える商品マスタの自動分類を開発なしで実現しています。

よくある質問

MCPとは何ですか?マネージドMCPを選ぶ理由は?

MCP(Model Context Protocol)は、AIエージェントを業務システムやデータに安全につなぐためのオープンな標準規格です。マネージドMCPを選ぶと、SSO・改ざんできない監査証跡・セキュリティ機能を最初から備えた状態で使い始められます。

セルフホストのMCPサーバーとマネージドMCPは、どう選べばよいですか?

判断の分かれ目は、MCPサーバーを運用できるセキュリティ体制が社内にあるかどうかです。専任のセキュリティエンジニアリングチームがあるならセルフホストも選択肢になります。そうでなければ、認証・監査ログ・監視を備えたマネージドMCPから始めるほうが安全です。

MCPのIDとアクセス管理は、どう設計すればよいですか?

OktaやMicrosoft Entra IDなど社内で使っているIDプロバイダーと連携し、SSOとOAuth/OIDCで認証します。そのうえでスコープを絞ったトークンを発行し、各ツールが必要最小限の権限で動くようにします。

導入時に押さえるべきセキュリティとコンプライアンスの論点は?

監査ログ、個人情報のマスキング、リスクの高いツールのサンドボックス化、監視の一元化、定期的なセキュリティレビューの5点です。これらをそろえておくと、個人情報保護法や社内のセキュリティ審査、SOC 2・ISO 27001などの監査要件に沿って説明しやすくなります。

MCP環境の可用性と拡張性は、どう確保しますか?

複数リージョンにまたがる構成ではフェデレーションしたゲートウェイを使い、時間のかかる処理にはタスクハンドルを、障害の連鎖を防ぐにはサーキットブレーカーを使います。

MCPツールの監査とガバナンスで、続けるべきことは?

監査ログを一元管理し、権限を定期的に見直し、セマンティックバージョニングでツールの変更を追えるようにし、変更は段階的に展開することです。

ClaudeなどのAIクライアントからMCPサーバーを使えますか?

MCPに対応したAIクライアントであれば、同じMCPサーバーを経由して業務データにアクセスできます。CData Connect AIのマネージドMCPでは、SSOで認証したうえで利用できます。対応状況はクライアントごとに異なるため、導入前に確認してください。

kintoneやSalesforce、SharePointなどの業務SaaSもMCPでつなげますか?

CData Connect AIのコネクタを使えば、kintone・Salesforce・SharePointをはじめとするSaaSやデータベース、ファイルにも接続できます。既存のアクセス権を引き継ぐため、AI用に権限を作り直す必要はありません。

MCPの導入は、まず何から始めればよいですか?

AIエージェントにつなぎたいデータソースの棚卸しから始めます。全部をつなぐのではなく、業務で本当に必要なものに絞り、機密度と求められる鮮度で分類します。そのうえで、重要度の低いデータと少人数のユーザーでパイロットを始めてください。

MCPサーバーの導入を小さく始めるには

CData Connect AIを使えば、データソースへの接続、IDプロバイダーと連携した認証、監査ログを最初からそろえた状態で、7つのステップを進められます。まずは重要度の低いデータと少人数のユーザーで、パイロットから試してみてください。

無料トライアルを始める

MCPサーバーの導入を小さく始める

データソースの棚卸しからID連携、監査ログまで、7ステップの多くをCData Connect AIが引き受けます。重要度の低いデータとパイロットから試してみてください。

無料トライアルでお試し