MCPサーバーとは何か

生成AIの使われ方は、この数年で変わりました。「質問して答えをもらう」段階から、「社内のファイルや業務システムを見せて、実際の仕事を任せる」段階に入っています。
社内のことを答えさせるには、社内のデータを見せなければなりません。しかし、どのデータを、誰の権限で、どこまで見せるのか。これを決めずに接続すると、本来その人が見られない情報まで、AI経由で読めてしまいます。
この「見せ方」を決める共通ルールが、MCP（Model Context Protocol）です。押さえておきたいのは、MCPが「データをAIに渡す」仕組みではない点です。ファイルを預けるのではなく、データは自社の管理下に置いたまま、AIが許された範囲だけを取りに来ます。
そして、このルールに沿って各システム側が用意する接続の受け口が「MCPサーバー」です。ストレージにはストレージの、営業支援システム（SFA）にはSFAのMCPサーバーがあり、AI側はそこへ接続します。本記事で審査の対象として扱うのは、この受け口のことです。代表的なものとしては、GitHub、Slack、Notionなど、業務でよく使われるサービスのMCPサーバーが公開されています。ファイルシステムやデータベースに接続するものもあり、自社がすでに使っているサービスに受け口が用意されているかどうかが、最初の確認事項になります。
これまでは、必要なファイルをその都度アップロードするか、システムごとに専用の連携機能を開発するしかありませんでした。前者は会社側でどのファイルが渡ったかを把握できず、後者は接続先の数だけ開発が必要になります。この負担が、AI活用が試験導入で止まる理由になっていました。
MCPなら、システム側がMCPサーバーを1つ用意すれば、対応するAIツールならどれからでも接続できます。逆にAIツールを乗り換えても、システム側を作り直す必要はありません。数か月単位でモデルが入れ替わる領域では、この違いが実務に効いてきます。
実際の使い方としては、複数のシステムにまたがる作業を、ひとつの指示で任せられるようになります。

AIは指示した人の権限の範囲で商談データと提案書を検索し、両方を突き合わせて資料案を作ります。これまで人が担っていた「探して、集めて、突き合わせる」手順を代行できるようになります。
なお、SaaS型とオンプレミス型のどちらで構成するか、データをどこに置くかといったシステム構成の考え方は、以下の記事で解説しています。

※関連記事：MCPサーバーが拓く企業のAI基盤設計：SaaS活用とオンプレミス運用の最適バランスを理解する

通常の生成AI利用と、セキュリティ上どこが違うのか

MCPで接続できるのは、読み取りだけではありません。レコードの更新、ファイルの保存、メールの作成も対象になります。ここが、通常の生成AI利用と決定的に違う点です。チャットに機密情報を貼り付けるリスクは、情報が外に出ることでした。業務システムにつながったAIは、それに加えて実際にデータを書き換えたり、消したり、社外へ送ったりできます。便利さと危うさは、同じ性質から生まれています。
したがって、考えるべき範囲は情報漏えいだけにとどまりません。アクセス権限の付与と定期的な見直し、操作記録の取得と保管、委託先の管理。これらはすでに、社内規程やISMS（ISO/IEC 27001）、Pマーク、顧客からのセキュリティチェックシートで説明を求められている項目です。AIが利用者に代わって操作するようになれば、同じ説明をAI経由の操作についても求められます。「この更新を実行したのは誰か」に答えられない状態は、内部統制上も監査上も問題になります。
リスクを整理する前に、押さえておきたい前提が3つあります。いずれもMCPの仕組みそのものから生まれるもので、どの製品を選んでも避けられません。

AIは、指示を言葉どおりに受け取る

「不要なファイルを整理して」という指示を、削除と解釈する可能性があります。人間なら文脈や場の空気で判断できることでも、AIは書かれたとおりに実行することがあります。
攻撃を受けていなくても業務データが失われるということです。重要な操作については、実行前に止める仕組みか、実行後に取り消せる仕組みのどちらかが必要になります。どちらを選ぶかは日々の運用の重さに直結するため、後述の「4段階で広げる」で改めて扱います。

つなぐ先が増えるほど、コストと待ち時間が増える

接続先が増えるほどAIが処理する情報量も増え、利用料金と回答時間の両方に跳ね返ります。「とりあえず全部つなぐ」進め方は、統制の面だけでなくコスト面でも不利です。最初につなぐ先は、業務上の効果が見込める1〜2システムに絞るのが現実的です。

問題が起きたとき、どこに聞けばよいか分からない

AIモデル、AIツール、MCPサーバー、接続先のシステム。提供元がすべて別会社ということも珍しくありません。障害や情報漏えいが起きたとき、どこの責任範囲なのかが、契約上も技術上も見えにくくなります。
だからこそ、リスクを一覧で並べるだけでは審査に使えません。項目ごとに「誰に聞けばよいのか」まで分けておく必要があります。

MCPのセキュリティリスクと対策10項目

MCPのリスクは、誰が手を打つ項目なのかによって、次の3つに分かれます。
サービス側の作りで決まるもの（項目1〜5）——自社では変えられないため、導入審査で提供元に確認します。
自社のルールで決まるもの（項目6〜8）——どのサービスを選んでも残ります。社内の承認手順や管理台帳として、自分たちで整えます。
どちらか一方では防げないもの（項目9・10）——両方で手を打たないと対処できません。それぞれが何を担うのかを分けて確認します。
良いサービスを選ぶだけでも、社内ルールを整えるだけでも、対処は終わりません。また、リスクをゼロにすることもできません。目指すのは、事故が起きにくく、起きたときに追跡でき、止められる状態です。
以下では10項目それぞれについて、リスク（何が起きうるか）、対策（何をするか）、確認（提供元や社内で何を確かめるか）をまとめて示します。

※関連記事：AIエージェントのセキュリティリスクと対策｜企業が押さえるべき脅威と安全な導入方法

サービス側の作りで決まるリスク（5項目）

サービスを選ぶ段階で決まり、契約後に自社で改善することはできません。導入審査で提供元に確認します。

自社のルールで決まるリスク（3項目）

どのサービスを選んでも残ります。社内で誰がどう承認するかによって決まる項目です。

どちらか一方では防げないリスク（2項目）

サービス側の作りと自社のルール、その両方で手を打たなければ対処できません。

10項目のうち、判断が分かれやすいのが項目9です。文書やメールに仕込まれた指示をAIが見抜けるかどうかは、業界全体としてまだ手法が固まっていない領域にあたります。
ここで検知機能の有無だけを条件にすると、審査は「見抜けるかどうか」の一点に寄ります。すると、見抜けなかったときにどうなるかが、評価から抜け落ちます。攻撃の手口は後から新しいものが出てくるため、この抜け落ちは時間が経つほど効いてきます。
一方、権限を超える操作ができないこと、すべてが記録されること、実行後に取り消せること。この3つは、見抜けたかどうかと関係なく機能します。仮に指示が通ってしまっても、被害は利用者本人の権限の範囲で止まり、何が起きたかを後から追え、元に戻せます。「防げるか」と「防ぎきれなかったとき、どこまでで止まるか」は、必ずセットで確認してください。
また、サービス側の作りで決まる5項目と、両方で分担する2項目は、提供元に確認しなければ分かりません。各項目の「確認」欄は、そのまま提供元への質問リストとして使えます。
明確に答えられないMCPサーバーは、便利でも、機密情報を扱う用途への導入は慎重に判断すべきです。一方で、すべてに「対応済み」と答える提供元にも、根拠の説明を求めてください。
MCPには、まだ手法が固まっていない領域が含まれます。どこまでを自分たちが担い、どこから先を利用企業やAIツール側が担うのか。この線引きを説明できるかどうかが、実際の判断材料になります。

利用範囲は、4段階で広げる

打つべき対策が見えても、最初からすべてを任せる必要はありません。つまずきやすいのが、書き込みや削除まで一度に許可してしまうケースです。次の4段階で、少しずつ広げることをおすすめします。

第1段階：検索・閲覧

社内文書やマニュアルを読むだけの状態です。データを書き換えないため、AIが指示を取り違えても影響が限定されます。前述の「言葉どおりに受け取る」性質を、実際の業務データで確かめる期間にあてます。

第2段階：生成・下書き

報告書やメール、議事録の要約の下書きを作らせます。成果物は必ず人が確認し、そのまま使わない習慣を、この段階で定着させます。

第3段階：限定的な書き込み

チケット登録、下書き保存など、影響が限られる操作を許可します。書き込める場所、件数、対象部門を絞って始め、操作記録を確認しながら範囲を広げます。

第4段階：業務実行

データ更新、顧客への連絡、社外送信を任せます。承認手順、二要素認証、操作記録、異常検知、緊急停止が揃っていることが前提です。ここで、項目8で決めておいた「危険な操作の扱い」が実務で問われます。

DirectCloud MCPサーバーの安全設計

ここまでの観点を、実際のサービスがどう満たすのか。ひとつの回答例として、当社の設計を開示します。
DirectCloud MCPサーバーを使うと、ChatGPT、Claude、Microsoft CopilotなどのAIから、DirectCloud上の提案書や契約書、マニュアルを権限に基づいて検索・参照できます。接続したからといって、社内のファイルがすべてAIから見えるようになるわけではありません。AIから見える範囲は、利用者ごとのフォルダ権限の設定によって決まります。
2026年8月25日にβ版としてリリースした時点での安全設計は、次の6点です。

上記のうち1〜5は現在ご利用いただけます。6は正式版での提供を予定しています。

1. 初期状態では使えない。管理者がユーザーごとに許可する

MCP機能は、初期状態では無効です。管理ページの「DirectCloud AI」＞「MCP」を開き、MCPユーザー管理から、ユーザーごとに利用の可否を設定します。許可していないユーザーは、AIツール側で接続しようとしても認証が通りません。

許可するユーザーを選び、「選択したユーザーを許可」を指定して変更します。1名だけの変更でも操作は同じです。誰にいつ許可を出したかが管理ページ上で一覧になるため、承認台帳と実際の設定を突き合わせやすくなります。

項目6の対策「使ってよいMCPを登録制にする」は自社で決める項目ですが、決めたルールを実際に効かせるには、サービス側に利用者を限定する機能が必要です。特定の部門だけで試験導入し、運用が固まってから対象を広げる、という進め方ができます。

2. 権限を超えた操作はできない

フォルダに設定されている権限が、そのままAI経由のアクセスにも適用されます。利用者に権限のないフォルダは、AIからも見えません。AI用に権限を作り直す必要はなく、普段のフォルダ管理がそのままAIの見える範囲になります。権限は7種類に分かれており、削除を実行できるのは副管理者・オーナー・編集者に限られます。

3. 認証情報が漏れても、影響が広がりにくい

接続には有効期間30分の署名付きトークン（JWT）を使い、7日間使われなかったものは自動的に破棄されます。さらに、会社単位で設定を無効にしたとき、利用者を禁止に変更したとき、パスワードを変更したとき、IPアドレス制限に違反したときは、発行済みのトークンが即座に無効になります。有効な時間の短さと、すぐ止められること。この両方で影響を抑えています。

4. すべての操作を記録する

MCP経由で実行された操作は、すべて記録されます。管理ページのMCP API履歴から、実行した人、実行した処理、日時、成否、応答時間、接続元IPアドレスを確認でき、やり取りの内容も操作ごとに参照できます。期間は直近7日・15日・1か月・3か月から選べるほか、日付指定での絞り込みにも対応します。参照できる範囲は12か月以内で、CSV形式での書き出しも可能です。

5. 誤って消しても、元に戻せる

MCP経由の削除は、ゴミ箱への移動として処理されます。消えたファイルは、利用者自身が元に戻せます。管理者への依頼も必要ありません。
AIが指示の意図を取り違える可能性は、設計上なくせません。そこで「間違えさせない」ではなく「間違えても取り消せる」形で扱っています。実行のたびに承認を挟む方式は確実ですが、承認待ちが日常的に発生すると、現場は結局その仕組みを使わなくなります。

6. 接続元のIPアドレスを制限できる

DirectCloudのIPアドレス制限のホワイトリストを、MCPの接続にも適用する設計です。会社ごとに設定済みの内容が、そのまま引き継がれます。

導入後の管理の手間で選ぶ

ここまでの6点は、導入審査を通すための条件です。実務で差が出るのは、その先です。導入したあとに管理の手間が増えないかどうかで、運用が続くかどうかが決まります。

MCPを導入した企業の事例

MCPサーバーを自社の業務に導入した企業の事例を3つ取り上げます。業種も用途も異なりますが、いずれも接続することより、AIに何を参照させ、どこまで実行させるかを先に決めている点が共通しています。

IT・ソフトウェア業界：Dropbox

過去およそ1年半に作成した150件のセキュリティ設計レビューや脅威モデルを、DashのMCPサーバーを通じてAIエージェントから検索できる仕組みを構築しています。設計文書、関連資料、コード変更を横断し、設計段階のセキュリティ要件が実装に反映されているかを分析します。

• ●脅威モデルと実装コードの照合、設計変更による影響範囲の確認
• ●過去のセキュリティレビューの再利用、コードレビュー時のリスク指摘

MCPサーバーが単なる検索の手段ではなく、複数の文書とシステムの関係をAIに分析させるための土台になっている例です。用途が読み取りと分析に寄っているため、本記事の「第1段階：検索・閲覧」から始める進め方とも重なります。

金融・決済業界：Block

社内のデータ基盤とAIエージェントをつなぐ独自のMCPサーバーを構築しています。特徴は、管理されたセマンティックレイヤー（指標や定義を統一して管理する層）と組み合わせている点です。利用者が普通の言葉で質問すると、AIは会社が承認した指標や定義を参照して分析結果を返します。

• ●売上・利益・取引データの分析、部門別実績の比較
• ●経営指標の定義確認、定型レポートの自動作成

AIにデータを自由に解釈させるのではなく、参照先をあらかじめ絞り込む設計です。同じ質問に誰が聞いても同じ数字が返る状態は、項目1の対策「必要最小限の権限で、本人の権限のまま動かす」と同じ発想にあたります。数字が経営判断や外部報告に使われる領域ほど、この作り込みが効いてきます。

クラウド・情報通信業界：Cloudflare

コンテンツ配信網（CDN）やゼロトラストセキュリティなど、インターネットインフラを提供するCloudflareでは、エンジニアリング、製品、営業、マーケティング、財務など複数の部門がMCPを利用しています。

• ●社内Wikiやプロジェクト情報の検索、営業・マーケティング情報の取得
• ●財務部門専用データへのアクセス、コード管理システムの参照・更新

注目したいのは、承認、認証、監査ログ、認証情報の管理、書き込みの制限を、部門ごとではなく共通の基盤にまとめている点です。会社が把握していないMCPサーバーが社内に増えること（Shadow MCP）を防ぐ狙いもあります。項目6の対策「使ってよいMCPを登録制にする」を、運用ルールではなく仕組みとして担保した形といえます。
各部門がそれぞれ接続を作り込んだあとで統制を取り戻そうとすると、動いている業務を一度止めることになります。利用が広がるほど個別の管理は続かなくなるため、共通の基盤を先に用意しておくほうが、結果として手戻りが小さくなります。

まとめ：権限と記録を前提に、MCPを使う

MCPサーバーは、AIと社内データをつなぐ共通の土台です。一方で、つながるシステムと実行できる操作が増えるほど、権限の与えすぎ、認証情報の漏えい、文書に仕込まれた指示といったリスクも大きくなります。影響は情報漏えいにとどまらず、内部統制、ISMS、Pマーク、顧客監査での説明にまで及びます。評価するとき、確認すべきことは3つです。

• ●誰が担う項目か

  サービス側で決まるのか、自社で決めるのか、両方で分担するのか。並べただけでは、どの相手に何を聞けばよいか分からない

• ●防げなかったときは

  検知できるかどうかだけで判断せず、防ぎきれなかったときに被害がどこで止まるのかを確認する

• ●説明できるか

  「すべて対応済み」ではなく、どこまでを自分たちが担い、どこから先を利用企業が担うのかを説明できるか

MCPは、危ないから使わない、という技術ではありません。強力だからこそ、権限と記録を前提にした環境で使うことが重要です。「どのAIが、誰の権限で、どのデータを見て、何をしたのか」を後から確認できること。この土台があってはじめて、業務で使える仕組みになります。

MCPのセキュリティに関するよくある質問