MCPサーバーのセキュリティ：社内データ接続の許可基準

MCPサーバーのセキュリティは、「そのサーバーが安全か」を審査するだけでは決まらない。MCP（Model Context Protocol）の仕様自身が、利用者の同意や認可の原則をプロトコルの側では強制できないと明記しているからである（2026年11月7日時点の公式情報）。同じサーバーでも、誰の資格情報で、読み取りだけか書き込みまでで、外へデータを出せる経路があるかによって、リスクはまったく変わる。企業が社内データの接続を許可するときに審査すべきなのは、サーバーという製品ではなく接続1件ごとの条件だ、と本稿は考える。公式の仕様とドキュメントが挙げるリスクを経営判断に必要な範囲で整理し、海外の元記事から許可の基準を4つに絞って示す。MCPの仕組みそのものはMCPの定義と、ホスト・クライアント・サーバーの仕組みで整理した。

MCPのセキュリティは、なぜ従来の製品審査では決まらないのか

MCPの仕様は、MCPが任意のデータアクセスとコード実行の経路を通じて強力な機能を実現する、と書く。そのうえで、利用者の同意と制御、データのプライバシー、ツールの安全性という3つの原則を掲げる。ツールは任意のコード実行に当たるので慎重に扱うこと、信頼できるサーバーから得たものでない限りツールの挙動の説明も信頼しないこと、とある。続けて、MCP自体はこれらの原則をプロトコルの側で強制できず、同意と認可の仕組みは実装する側、つまりAIアプリケーションやサーバーの作り手が組み込むべきだとしている。認可の仕組みも仕様の上では任意（OPTIONAL）である。「MCP対応」は、安全の保証ではなく接続の方式の表示にすぎない。

現場の数字もこの構造を裏づける。a16zが従業員1,000人超の企業のCISO（最高情報セキュリティ責任者）100人に行った調査では、55%がMCPサーバーなど、エージェントとアプリケーションの連携をすでに本番で使っていた。懸念については、47%の回答が社員による機密データのAIツールへの流出を、46%がエージェントの権限超過や乗っ取りを挙げている。63%は、審査や承認の要件、特定用途の制限などのセキュリティ対応が、少なくとも一部のAI導入を遅らせていると答えた（2027年のセキュリティ予算、87%のCISOが増加を予想──AIエージェント関連の優先度が急上昇）。

a16zの指摘から読み取れる、従来の審査が効きにくい理由は2点ある。1つは、承認の対象が後から変わることだ。通常のアプリケーションとして承認したソフトウェアが次の更新でエージェントの機能を持ち、社員は拡張機能や連携を足し、エージェントの権限は担う仕事が増えるほど広がる。もう1つは、操作の主体が見分けにくいことだ。エージェントは社員の端末上で社員本人の権限で動くので、従来のエンドポイントのセキュリティ製品からは社員本人の操作と区別できない。元記事は次のように書いている。

“EDR, DLP and Zero Trust all break at that point.”

訳: EDR、DLP、ゼロトラストは、すべてそこで破綻する。

出典: The New Security Agenda by a16z, 2026-10-28

本稿は、一度の審査で製品を承認し、あとは利用者の権限に任せるやり方では、接続が増え、変わり続ける状況に追いつかないと考える。権限の線は一度引いて終わりではなく運用の中で動き続ける、という前提で設計し直す必要がある。その前提の置き方は権限境界を動かし続ける意思決定と、その所有権で論じた。

MCPサーバーにはどんなリスクがあるのか

MCPの公式ドキュメントには、セキュリティのベストプラクティスのページがある。主な対象は開発者とサーバーの運用者だが、経営と情報システム部門が押さえるべき点に絞ると次のようになる（2026年11月7日時点の内容）。

• ローカルのサーバーの乗っ取り: 社員の端末で動くサーバーの設定や配布物に悪意のある処理が混ざると、任意のコードが実行されうる。ワンクリックの設定では、実行するコマンドを省略せずに示して利用者の明示的な承認を得ることが必須とされ、クライアントと同じ権限で動く旨の警告や、隔離環境で動かすことが勧められている
• トークンの素通し（トークンパススルー）: MCPサーバーが自分宛てでないトークンを受け取り、そのまま下流のサービスへ渡すこと。仕様は明確に禁じており、許すと誰の操作かが記録に正しく残らない
• 広すぎる権限の一括付与: files:* や admin:* のような広い権限を付けたトークンが盗まれると、被害が無関係なデータにまで広がる。最小限の範囲から始め、必要な時点で段階的に引き上げる方式が勧められている
• 代理で認可するサーバーの悪用: 外部のAPIに代理でつなぐサーバーでは、特定の条件がそろうと、攻撃者が利用者の同意なしに認可を得られる。接続してくるMCPクライアントごとに利用者の同意を確認してから、外部の認可へ進めることが対策とされる

製品側の注意も具体的だ。Claudeのヘルプセンターは、カスタムコネクタについて次の3点を挙げている。信頼できる組織が作り運営しているサーバーにだけ接続すること。悪意のあるMCPサーバーには、Claudeに意図しない操作をさせる隠れた指示が含まれうること。サーバーの開発者がツールの挙動を予告なく変えうること。さらに、「常に許可」を選ぶのは、監督なしで動かしてよいと信頼できるサーバーとツールに限るよう求めている（2026年11月7日時点のClaudeヘルプセンター）。

自前で作るMCPサーバーには別のリスクがある。Every社の記事で、Katie Parrottは、自作のアプリに外部のエージェントからつなぐためのMCPの接続口をClaudeで作った。着手前、経験のあるソフトウェアエンジニアの友人に危険性を尋ねたところ、答えはこうだった。認証済みのAPIは、エージェントが使うからといって危険になるわけではない。だが利用者のアクセスを管理するバックエンド側は話が別で、誰を入れるかを決めるので、誤った呼び出しや操作された呼び出しが開けてはならない扉を開けうる。結果として、本番に出した接続口には、本来は非公開であるべき公開の登録経路が開いていた。後日、別系統のモデルであるGPT-5.6 Solに点検させて見つかったもので、利用された形跡はなかった（非エンジニアの AI 開発をどこまで許可すべきか — vibe coding が本番に持ち込んだ脆弱性の教訓）。この事例が示すのは、危険がエージェントがデータを読む部分よりも、接続口が「誰を入れるか」を決める部分に潜みうるという点である。

企業は社内データの接続を何で許可すべきか ― 4つの基準

本稿は、企業がMCPを使うとき、許可の単位をサーバーではなく接続1件にすることを勧める。同じSnowflake向けのMCPサーバーでも、読み取り専用の資格情報でつなぐのと、書き込みのできる共有キーでつなぐのとでは、別の判断になる。次の4つは本稿の整理であり、公式の分類ではない。第一と第二は申請の時点で確認できる。第三は、同じエージェントにつながる他の接続との組み合わせで確認する。第四は「誰が追加するか」と「許可した後の変化を誰が追うか」をまとめたもので、後半は許可した後も続けて確認する。

基準	確認すること	確認する時点
誰の資格情報でつなぐか	利用者ごとの認証か、全員共有のAPIキーか	申請時
読み取りか書き込みか	社内システムを書き換えられるか	申請時
外へ出せるか	読んだデータを外部へ送る経路が同じエージェントにあるか	申請時と、接続を足すたび
誰が追加し、変化を誰が追うか	追加できる人と、許可後のツールの変化を追う担当	申請時と、許可した後も継続

第一に、誰の資格情報でつなぐか。 Claudeのヘルプセンターによれば、カスタムコネクタは通常OAuthで認証し、TeamやEnterpriseの組織に追加されたコネクタには、メンバーが個別に接続して認証する。一方、APIキーのような固定の資格情報を使うコネクタでは、利用者全員が同じ資格情報でサービスにアクセスするので、メンバーがアクセスしてよい範囲に絞った資格情報を使うよう求めている（2026年11月7日時点）。共有の資格情報の権限は、使う人全員の権限になる。

第二に、読み取りだけか、書き込みまでか。 公式ドキュメントでは、AIモデルが呼び出す「ツール」はデータベースへの書き込みもでき、「リソース」は読み取り専用の情報源である。Every社のカスタマーサポートのマネージャー、Waqqas Mirは、カスタマーサポートのAIエージェントを提供するFinのMCPサーバーにCodexをつなぎ、誤対応した会話の原因を診断させている。元記事によれば、この接続でできるのは分析までで、設定の反映は本人が行う（新AIモデルへの乗り換えは何を根拠に決めるのか ― 2日ほどの締め切りに対し監査と下書きを90分で終えたビズオプスのマルチモデル運用）。読み取りの接続は速く通し、書き込みの接続にだけ承認者を置く、という分け方が成り立つ。

第三に、読んだデータを外へ出せるか。 社員約900人のメンタルヘルスケア企業Headwayは、社内アシスタント「Eddy」をMCPのコネクタで社内のツールにつないだ。元記事は、この構成で最悪の事態になりうるのはプロンプトインジェクションだと書く。悪意のある第三者が、AIに読ませるメールなどの中に、機密データを集めて外へ送れという指示を隠す攻撃である。CTOのArnaud Ferreriによれば、同社の通信の制御（egress policy）は、機密データにアクセスできるエージェントであってもそれを外へ送れないように設計されている。会話ごとの使い捨てコンテナ内の制限として、データウェアハウスのSnowflakeは読み取りのみ、インターネットは厳しいプロキシ経由の検索のみ、メールは送れない（社内 AI アシスタントは自作すべきか購入すべきか ― Headway が Claude Code SDK で「Eddy」を自社構築した判断基準）。1件ずつ見れば問題のない接続でも、社内データを読む接続と外へ送れる接続が同じエージェントに揃うと、持ち出しの経路になる。

第四に、誰が追加し、許可した後の変化を誰が追うか。 ClaudeのTeamプランでは、リモートMCPを使うカスタムコネクタを組織に追加できるのはOwnerとPrimary Ownerに限られる。EnterpriseプランではLibrariesの管理権限を含むカスタムロールも追加できる（2026年11月7日時点のClaudeヘルプセンター）。追加の権限は製品の設定で絞れるが、許可した後にツールの挙動が変わることは、追加の時点の審査では防げない。a16zが投資先として紹介する端末側のセキュリティ製品は、社員の端末にあるエージェント・拡張機能・MCPサーバーと、それぞれがアクセスできる範囲を追跡し、障害の調査は許しても変更には承認を求める、という運用を例に挙げる。投資元による紹介である点は割り引いて読む必要があるが、つながっているものの一覧を持ち、見直す担当を置くことはどの製品を使うにしても前提になる。

4つの基準のうち、人の承認を置くのは書き込みと外への送信を伴う接続だけでよい。読み取りは失敗してもやり直せるが、書き込みや送信は取り返しがつかないからだ。取り返しのつかない操作にだけ関門を置く考え方は、不可逆な操作にだけ強制ゲートを置く非対称な権限設計と同じである。

許可の基準は、社内ルールのどこに置くべきか

許可の基準を社内ルールのどこに置くかについて、公式にも元記事にも記述はない。本稿は、基準を登録簿と製品の管理設定に置くほうがよいと考える。接続は追加のたびに内容が変わる個別の情報で、規程の本文より台帳のほうが更新しやすいからだ。登録簿には、どのサーバーを、誰の資格情報で、読み書きどちらでつなぐか、外への経路の有無を記す。ただし管理設定で止められるのは、本稿で確認できた範囲ではClaudeのコネクタの追加権限である。社員の端末で動くローカルのサーバーまで止められるかは、使う製品ごとに確かめる必要がある。生成AIのガイドラインに条項を足し続けることの副作用については、関連する論点として条項の総量に上限を置くガイドラインの見直し方で扱った。

接続の許可を決める体制の組み方としては、社内AIツールを自作したHeadwayのCTOの助言が参考になる。助言は自作する会社向けのものだが、要点は接続の許可にも当てはまる。経営層のスポンサーを付け、法務・コンプライアンス・セキュリティの担当を早い段階から加えて、製品が何にアクセスし何をできるかを決めること。安全な権限の境界と再利用できる設計を作ってから、利用を広げること。エンジニアだけの試行が責任ある始め方になりうること。元記事によれば、Eddyが広がったのは、同社がのちにコネクタ・権限・成果物をエンジニア以外にも役立つ形に整えたからで、初日から全部門に制限のない版を配ったからではない。

自前で作るMCPサーバーには、もう1段の手続きが要る。前述のKatie Parrottは事後、Codexが最初に読むAGENTS.mdに指示を加えた。他の人に影響する作業、機密データや権限を扱う作業、壊れたときに元に戻しにくい作業では人のレビューを求めること、などである。次にMCPの接続を作るときは、系統の異なる複数のモデルにレビューさせ、ソフトウェアエンジニアにも穴を探してもらうとも書いている。組織に置き換えれば、社内データや権限に触れるMCPサーバーを自前で作るときは、作ったAIとは別の点検と人のレビューを、公開の前に必須にすることになる。

まとめ: 審査の単位をサーバーから接続へ移す

MCPの仕様は同意と認可の原則を掲げるが、それをプロトコルの側で強制はしない。だからMCPサーバーのセキュリティは、サーバーを製品として承認するだけでは決まらない。接続1件ごとに、誰の資格情報で、読み取りか書き込みか、外へ出せるか、誰が追加し誰が変化を追うかを確認し、書き込みと外への送信にだけ承認を置く。次に決めるのは、MCPの利用ルールの文面ではない。この4つを記入する登録簿を誰に持たせるか。そして、登録簿にない接続を使わせない設定が使う製品に存在するかを確認したうえで、どの管理画面で行うかである。