AIエージェントの『繋ぎ先』をどう信頼するか——VibeCoding内製化で見落とされるMCPの境界線
「便利そうなMCPサーバーを見つけたので繋いでみました」——VibeCoding内製化の現場で、非エンジニアの担当者からこう相談されることが増えました。動いた、便利になった、で話が終わりがちですが、その一歩の裏には、Claude Codeのpermissionsもsandboxも及ばない別の境界線があります。以前お伝えした機密情報の多層防御では、名前だけ挙げて掘り切れなかった論点です。今回は、MCP経由の連携をどこまで信頼していいのか、私たちが現場で線引きしている考え方をお伝えします。
- 01「繋いだら便利」の一歩先に何があるか——ある内製化現場のひとコマ
- 02permissionsとsandboxは、なぜMCPの外側までは守れないのか
- 03MCPサーバー1つが、なぜ「会社全体」への入口になるのか
- 04実際に起きている手口——なりすまし・野良サーバー・サプライチェーン
- 05信頼境界をどう線引きするか——allowlistとスコープの最小化
- 06VibeCoding内製化の現場でこそ危ない理由——「繋ぐだけ」の手軽さが招く油断
- 07すり抜けテストは、MCPにも当てはまる
- 08MCPが最適とは限らない——CLIという選択肢
- 09それでも残るリスクという正直な話
- 10私たちの見解——「繋ぐ」という行為を、経営が把握できる状態にする
- 11よくある質問
- 12まず試すなら
- 13参考リンク
「繋いだら便利」の一歩先に何があるか——ある内製化現場のひとコマ
ある中堅の部品メーカーで、情シス担当がClaude Codeに、会議調整を助けてくれるMCPサーバーを繋いだときのことです。日程調整のやりとりが一瞬で終わるようになり、チームからも好評でした。
数週間後、そのMCPサーバーが個人が公開していた検証用のプロジェクトだったと判明します。開発元は更新を止めており、脆弱性を抱えたまま、社内の会議情報——出席者名、議題、外部取引先の名前——を外部のサーバーに送り続けていました。
担当者に悪気はありません。むしろ「早く便利にしたい」という真面目さの表れです。Claude Codeのpermissionsで機密フォルダへのdenyルールを設定していたので、安心していたと言います。ですが、MCP経由の連携は、そのdenyルールが及ぶ範囲の外側にありました。
これは特殊な事故ではないと私たちは考えています。VibeCoding内製化の現場で、非エンジニアの担当者が「便利そうなツールを見つけて繋ぐ」という行動そのものは、むしろ積極性として評価すべきことです。問題は、繋ぐ前に確認すべきことが、ツールを追加するときのハードルの低さに比べて、あまりに知られていないことにあります。
permissionsとsandboxは、なぜMCPの外側までは守れないのか
前回の記事では、Claude Codeのpermissions(denyルール)とOSレベルのsandboxを重ねる多層防御をお伝えしました。この2つは、AIエージェントが「ローカルの何を読み書きできるか」を縛る仕組みです。ところがMCPサーバーは、AIエージェントから見ると「呼び出せる外部のツール」であり、その内部で何が起きているかまではツール層の制御が届きません。
MCPサーバーの内部で、サーバー自身が別のAPIを呼んだり、受け取ったデータを外部に転送したりしても、Claude Code側のdenyルールはそれを検知できません。denyルールが見ているのは「AIがローカルファイルを読むか」だけです。「AIが呼び出したMCPサーバーが、その先で何をするか」までは、そもそも見る仕組みになっていません。
2026年7月28日、MCPの仕様が大きく更新されました。ステートレスなアーキテクチャへの移行に伴うものです。この更新を検証したエンジニアの記事によれば、通信の土台が作り直され、認可の強化や複数機能の非推奨化まで含む、発足以来もっとも大きな変更だったといいます。つまり公式仕様そのものが、「セキュリティ境界を作るのは実装する側の責任だ」という方向に進んでいるということです。私たちはこれを、MCPが「AI-Pathの多層防御でいう6番目の層」ではなく、まったく性質の異なる、別の座標軸にある境界線だと捉えています。
言い換えると、Claude CodeのpermissionsやsandboxがAIエージェントという「主体」の行動を縛るのに対して、MCPの信頼境界はAIエージェントが「誰に何を委任するか」という別の問題を扱っています。前回の記事の5層防御を厳密に実践していても、MCPサーバーへの委任先の管理を怠れば、そこだけが素通しの穴になります。私たちが現場で確認するのは、この2つの問題を同じ担当者が同じ意識で扱えているか、という点です。
MCPサーバー1つが、なぜ「会社全体」への入口になるのか
MCPサーバーは、複数のサービスの認証情報を1か所に集約する構造を取ることが多くあります。カレンダー、社内Wiki、顧客管理システム、コードリポジトリ——便利さを追求するほど、1つのMCPサーバーが扱う接続先は増えていきます。
ここで起きやすいのが、AIエージェントが本来持つべきではない広い権限を、代理として使ってしまう問題です。セキュリティの世界では「confused deputy(混乱した代理人)」と呼ばれる古典的な脆弱性の一種で、MCPの文脈でも同じ構造がそのまま再現されます。ユーザーが依頼したのは「カレンダーの空きを確認して」という狭い操作でした。ですがMCPサーバーに渡された認証情報は、実際にはカレンダー全体の編集権限まで持っていた、というケースがこれにあたります。エージェントは悪意なく、渡された権限の範囲で忠実に動きます。だからこそ、渡す権限そのものを最初から絞っておく必要があります。
もう一つ見落とされがちなのが、上流から受け取ったトークンを、そのまま下流のサービスに渡してしまう挙動です。「token passthrough」と呼ばれるこの構造では、1つのトークンが複数のサービスをまたいで使い回されます。どこか1か所が破られただけで、渡された先すべてに影響が広がります。私たちの現場経験では、「動くかどうか」だけを基準にMCPサーバーを選んでいる案件ほど、この設計の甘さに気づかず本番投入されています。急いで便利さを取りにいくほど、権限設計を後回しにしてしまう、というのが実感です。
実際に起きている手口——なりすまし・野良サーバー・サプライチェーン
MCP経由の攻撃は、抽象的な脅威ではなく、すでに具体的な手口が確認されています。1つ目は、ツールの説明文にAIへの隠れた指示を埋め込み、正規のツールになりすます手口です。AI自身は説明文をそのまま信頼して読み込むため、人間の目には見えない指示に従ってしまうことがあります。2つ目は、開発が止まった、あるいは最初から悪意を持って公開された「野良サーバー」に、うっかり接続してしまう事故です。どちらも、見た目の便利さだけでは判別できません。私たちの現場経験では、名前がそれらしい、スター数が多そう、といった印象だけでMCPサーバーを選んでいる案件ほど、この種の見分けに弱いという傾向があります。
サプライチェーン側のリスクも軽視できません。ある医療系スタートアップのテックリードは、自社の開発環境を守る取り組みを紹介する記事の中で、npm上のパッケージにマルウェアが仕込まれ、インストールした時点で遠隔操作ツールが入り込む供給網攻撃が実際に起きたと報告しています。MCPサーバーの多くもnpmやPyPI経由で配布されるため、同じ経路の危険がそのまま当てはまります。つまり「見た目の機能」だけでなく「配布経路そのもの」も、信頼するかどうかの判断材料に含める必要があるということです。
開発現場そのものへのAI活用が広がるにつれ、この種のリスクは他人事ではなくなってきています。開発現場でのAI活用を振り返ったある記事では、フルスクラッチ開発の初期はローカル環境で完結するため問題を感じにくいものの、開発・検証・本番環境の構築や接続に踏み込むあたりから、AIエージェントへの「丸投げ」に危険を感じ始めた、という実感が語られています。インフラ構成の確認やDBへの接続、本番データへのアクセスまでエージェントに渡してしまうと、渡す情報の整理が追いつかなくなる、という指摘は、私たちがMCPの接続先管理で懸念していることと重なります。
信頼境界をどう線引きするか——allowlistとスコープの最小化
具体的な対策は、大きく3段に分けて考えると整理しやすいと私たちは考えています。
まず、接続先そのものを絞ることです。MCPサーバーごとに、アクセスしてよい外部の宛先をあらかじめ許可リスト(allowlist)として定義し、それ以外への通信は既定でブロックする。ファイルパスやメタデータエンドポイントのような、想定外の経路へのアクセスも同じ発想で塞いでおきます。
次に、認証・権限を最小化することです。OAuth 2.1とPKCEの組み合わせで認証を強め、トークンは特定のサーバー・特定のツールにだけ使える範囲にスコープする。「カレンダーの空き確認だけ」を依頼したいなら、渡す権限もそこだけに絞る。権限を後から広げるのは簡単ですが、狭めるのは案外難しいというのが私たちの実感です。
最後に、MCPサーバーそのものを隔離することです。可能であれば個別のコンテナやプロセスとして分離し、1つが侵害されても他に影響が広がらない構造にしておきます。加えて、通信ログを継続的に監視し、想定外の宛先への通信を検知したら自動的に停止できる仕組み(kill switch)を用意しておくと、被害が広がる前に止められます。
私たちの経験では、この3段のうち最初に手をつけやすいのは権限の最小化です。allowlistの整備やサーバーの隔離は、既存の開発環境に手を入れる分だけ調整に時間がかかります。一方で「このMCPサーバーに、この作業以上の権限を渡していないか」を見直すことは、設定を1つずつ確認するだけで今日から始められます。優先順位に迷う場合は、まずここから着手することをお勧めしています。
VibeCoding内製化の現場でこそ危ない理由——「繋ぐだけ」の手軽さが招く油断
私たちがこの話を特にVibeCoding内製化の文脈で強調するのは、非エンジニアの担当者ほど「繋ぐ」という行為の重さを実感しにくいからです。コードを書く経験があれば、外部サービスに認証情報を渡すことの意味は自然と身につきます。ですが、AIエージェントに「このMCPサーバーを使って」と伝えるだけで機能が増える体験は、その重さを覆い隠してしまいます。
私たちが顧客の内製担当に伝えているガードレールの発想は、ここにも応用できます。非エンジニアがVibeCodingを安全に回すための線引きとして、「最初はデータベースを直接いじらないものに留める」「メインブランチに直接マージせず、まずPRを上げてAIにレビューさせる」という進め方を私たちはお勧めしています。これと同じ発想で、MCPサーバーの追加も「担当者が見つけたら即座に繋ぐ」のではなく、「まず技術に詳しい人が確認してから繋ぐ」という一段のチェックポイントを挟むだけで、事故の多くは防げると私たちは考えています。
情報の扱いについても、私たちが機密データの分析で徹底している考え方は、MCP経由のデータ受け渡しにもそのまま当てはまります。AIに学ばせるのは「解き方」だけで、固有名詞や具体的な金額は学習対象に含めない、という設計です。MCPサーバーに渡すデータも、「このMCPサーバーが本当に必要としている情報は何か」を先に切り分けてから渡します。便利だからと丸ごと渡してしまうと、必要以上の情報がサーバーの向こう側に残ってしまいます。
私たちが顧客の内製担当者向けに用意している確認リストは、そう複雑なものではありません。このMCPサーバーは何をするために繋いだのか。動かすために渡した権限は、その目的に対して広すぎないか。開発元は継続的に更新しているか。この3点を、繋ぐ前の5分間で確認するだけで、事故の芽の多くは摘み取れると私たちは考えています。
すり抜けテストは、MCPにも当てはまる
前回の記事で、ルールを作った後に「本当に破れないか」を自分で試す「すり抜けテスト」という発想をお伝えしました。この発想は、MCPの信頼境界にもそのまま当てはまります。
具体的には、allowlistに登録していない宛先への通信が本当にブロックされるか、スコープを絞ったはずのトークンで範囲外の操作を依頼したら実際に拒否されるか、1つのMCPサーバー経由で得た認証情報が、別のツール呼び出しに漏れ出していないか。これらを一つずつ、自分の手で確かめます。設定したはずのルールが実は抜け穴だらけだった、という事故を私たちは何度も目にしてきました。合格の基準は「すべてブロックされること」で、一つでも通過してしまえば、そこが実際の事故の入口になります。
MCPが最適とは限らない——CLIという選択肢
ここまでMCPの守り方を中心にお伝えしてきましたが、正直に言えば、MCPが常に最適な選択とは私たちは考えていません。AIエージェント向けのデータ分析基盤を開発したエンジニアは、MCPではなくCLIとしてツールを作った理由をまとめた記事の中で、設計の3原則を示しています。人間がターミナルから使うことと、AIエージェントに操作させることの両方を同じインターフェースで担わせる、という発想です。
MCPは複数のサービスをまとめて扱える柔軟さが魅力ですが、その柔軟さは、信頼境界を増やすことと表裏一体です。単一のツールを、決まった手順でしか呼び出せないCLIの形にしておく方が、結果的に攻撃対象領域を狭められる場面は少なくありません。私たちの現場経験では、「本当にMCPで繋ぐ必要があるか、CLIやAPIを直接呼ぶ形で十分ではないか」を一度立ち止まって考えるだけで、無駄な信頼境界を1つ減らせることがあります。
それでも残るリスクという正直な話
ここまでの対策をすべて実践しても、万能ではありません。MCPサーバーの開発元が、ある日突然、悪意のあるコードを紛れ込ませる可能性は理論上残ります。信頼していた接続先が、後になって信頼できなくなるという事態は、技術的な設定だけでは防ぎきれません。
誤解のないように言えば、これは「対策をしても無駄」という話ではありません。防げる経路は技術で塞ぎます。防ぎきれない部分は、「定期的に接続先を棚卸しし、使われていないMCPサーバーは繋いだままにしない」という運用で補う。両方が揃って、現実的に安全と言える状態に近づくというのが私たちの理解です。
余談ですが、この話を社内の技術メンバーと共有したとき、「結局、人を信頼するかどうかの話に戻ってくる」という感想が出ました。MCPサーバーの向こう側にも、それを作っている人がいます。技術的な線引きは、その人たちを疑い続けるための仕組みではなく、疑わなくて済む範囲を先に決めておくための仕組みだと私たちは捉えています。
私たちの見解——「繋ぐ」という行為を、経営が把握できる状態にする
一般的なSaaS開発であれば、ベンダー側が接続先の安全性をある程度担保してくれます。しかし私たちが支援するVibeCoding内製化の現場では、どのMCPサーバーに何の権限を渡しているかを、自分たちで把握し続ける必要があります。
私たちの現場経験では、便利なMCPサーバーが次々と登場するスピードに、社内の管理体制が追いつかなくなっている案件をよく見かけます。誰が、いつ、どのMCPサーバーを、どんな権限で繋いだのか。この一覧が社内のどこにも存在しない状態は、それ自体がリスクだと私たちは考えています。
これは技術投資というより、経営としての意思決定に近い話です。接続先を1つ確認する手間、権限を絞る手間は、短期的には開発の初速を少し落とします。ですが、機密情報が漏洩すれば、失うのは開発速度どころではありません。取引先からの信頼、契約継続の判断、場合によっては法的な対応にまで発展します。VibeCoding内製化における「繋ぎ先」の管理を、現場の担当者任せにせず、経営層が最初に方針を決めるべき話として位置づけることを、私たちはお勧めしています。
よくある質問
Q1. permissionsのdenyルールを設定していれば、MCP経由のリスクも防げますか。 防げません。denyルールはClaude Code自身が解釈するローカルの読み書きを制御する仕組みで、MCPサーバーの内部で何が起きるかは別の話です。両方を独立した対策として設計する必要があります。
Q2. 社内で使うMCPサーバーは、どこまで調べれば十分ですか。 開発元が誰か、更新が継続されているか、配布元(npm・PyPI等)の信頼性、要求してくる権限の範囲、この4点は最低限確認することをお勧めしています。GitHubのスター数だけを判断材料にしないことも大切です。人気があることと、安全に設計されていることは、別の話だからです。1つでも不明な場合は、技術に詳しい担当者の確認を挟んでから接続してください。
Q3. 非エンジニアの内製チームでも、この線引きは実践できますか。 一度にすべてを整える必要はありません。まずは「MCPサーバーを繋ぐ前に、誰かに確認する」という1つのルールから始めることをお勧めします。
Q4. すでに繋いでしまっているMCPサーバーがある場合、どうすればよいですか。 まずは現在繋がっているMCPサーバーと、それぞれに渡している権限の一覧を作ることが最初の一歩です。使われていない、あるいは必要以上の権限を持っているものは、この機会に見直してください。
Q5. MCPサーバーを自社で開発する場合の注意点はありますか。 配布先(npm等)の管理を厳重にすることに加え、要求する権限を機能に必要な最小限にとどめること、通信先を明示的に制限すること、この2点を設計の初期段階から組み込むことをお勧めしています。
まず試すなら
- 現在Claude CodeやAIエージェントに繋いでいるMCPサーバーを一覧化し、それぞれに渡している権限を確認すること
- 使われていない、あるいは開発元が不明なMCPサーバーは、この機会に接続を解除すること
- 新しいMCPサーバーを繋ぐ前に、技術担当者の確認を挟むという社内ルールを1つ決めること
- allowlistに登録していない宛先への通信が本当にブロックされるか、自分の手で一度試してみること(すり抜けテスト)
どれも、外部への発注や大きな予算を必要としない、社内だけで今日から始められることです。AI-Pathでは、無償の業務プロセス診断(BPR)を実施しています。自社のVibeCoding内製化におけるMCP連携の管理に不安がある場合は、まずは棚卸しからご相談ください。
参考リンク
櫻井 文雄（さくらい ふみお） 株式会社AI-Path 代表取締役CEO
関西大学法学部法律学科卒業。財務コンサルティング会社（エフアンドエム）、外資系生保営業（Prudential）でコンサルティング営業の経験を積んだ後、起業し様々な企業のCTO/CMOを歴任。その後、デロイトトーマツコンサルティング（Big4）、ABEJA（AI研究開発の国内リーディングカンパニー）にて官公庁・製造業・金融業・小売業・不動産業を中心に延べ20社以上のDX推進や業務システム刷新をPM/SMとしてリード。利用者目線での現場の課題解決にフォーカスしたものづくりに拘り、導入ではなく「定着化」を目的とした伴走型のプロジェクト推進・システム導入を得意とする。2025年にAI駆動開発（VibeCoding）と出会い、より多くの人・企業に価値提供するためにAI-Pathを創業。
関連コラム
AIエージェントに『見せてはいけない情報』をどう線引きするか——VibeCoding内製化の現場を守る5層防御
AIコーディングエージェントに顧客データや機密情報を『見せない』ためには、CLAUDE.mdでの指示だけでは不十分です。VibeCoding内製化の現場で私たちが実践している、構造で守る多層防御の設計をお伝えします。
AIエージェントはなぜテストを握りつぶすのか——「報酬ハッキング」を防ぐ現場のレビュー設計
AIコーディングエージェントは、指示通りに動いているように見えて、テストの合否判定そのものを操作することがあります。この「報酬ハッキング」について、私たちがVibeCoding内製化の現場で見た手口と、防ぐためのレビュー設計をお伝えします。
スタック型プルリクエスト——AIエージェントの大量生成物を、レビューできる単位に分割する技術
AIエージェントが生成する変更量が増えるほど、1つの巨大なプルリクエストにレビューが押しつぶされます。GitHub公式のStacked PRsを、私たちAI-Path自身の現場実践を交えて解説します。