はじめに：便利さと引き換えに何を渡しているのか
MCPサーバ、Google連携、Microsoft Copilot――。
AI連携ツールが爆発的に増えている。
Gmail、カレンダー、Drive、Slack、チケット管理。
1つの窓口で全部触れる世界が、すでに来ている。
便利だ。
圧倒的に便利だ。
だが、ふと考えてほしい。
そのAI、本当に"社内の範囲だけ"で動いてますか？
本記事では、MCPサーバやAI連携に潜む構造的なセキュリティリスクを整理し、「最低限ここだけは押さえろ」という現実的な対策を示す。
これ、1つでも当てはまったら要注意
- AIが外部APIを自由に呼び出せる状態になっている
- Drive / Slack / メールなどを全部つないでいる
- AIがそのまま投稿・送信できる権限を持っている
- どのデータが外に出ているか説明できない
1つでもYesなら、この記事は他人事ではない。
なぜAIは"内部不正者"と同じなのか
情報セキュリティにおいて最も厄介な脅威は、内部不正者だ。
- 正規の権限を持っている
- 広範囲にアクセスできる
- ログを見ないと気づかれない
AIエージェント（MCP連携含む）は、この3つをすべて満たす。
しかも、人間の内部不正者と決定的に違う点がある。
悪意がなくても情報を持ち出す。
AIは「より良い回答」を目指して動く。
その過程で、人間なら絶対にやらない横断参照を平然と実行する。
👉 "善意の内部不正者" ── これがAIエージェントの正体だ。
ある日、何もしていないのに情報が漏れた
開発チームでAIエージェント（MCP連携）を導入した。
社内のDrive、Slack、チケット管理ツールにアクセスできるようにした。
ある日、エンジニアがこう聞いた。
「この不具合、過去に似た事例あった？」
AIは答えるために以下を実行した：
- 過去の障害チケットを検索
- 関連する設計書をDriveから取得
- Slackの議論ログを参照
ここまでは想定通り。
しかし問題はその後だった。
AIは回答精度を上げるために、外部のコード解析APIを呼び出した。その際――
👉 社内設計書の一部がそのまま外部に送信された。
誰も気づいていない。ログも見ていなかった。
さらに問題なのは、この外部APIがログを保持していた場合だ。
👉 その設計書は「第三者の環境に半永久的に残る可能性がある」。
なぜ起きたのか？
| 原因 | 説明 |
|---|---|
| AIは「より良い回答」を優先した | 精度向上のために外部ツールを自律的に使用 |
| データの機密レベルを理解していない | 設計書も公開情報も区別なく処理 |
| 外部送信に人間の承認がなかった | 自動実行が許可されていた |
誰も悪くない。だが、設計が負けている。
構造的リスク：3つの「境界」が壊れている
AI連携の危険性は、個別のツールの問題ではない。
境界が崩れることが本質だ。
① 外部との境界（外部API呼び出し）
ここが最大の地雷。
LLMやAIエージェントが外部ツール・APIを呼び出すとき、送信内容がブラックボックスになる。
[社内データ] → [AIエージェント] → [外部API] → ???
- どのデータが送られたか？
- どこに保存されるか？
- 誰がアクセスできるか？
これに答えられないなら、すでに事故は起きている可能性がある。
👉 「外に出る経路を閉じてない時点で負け」
② データ間の境界（参照範囲の広さ）
Drive / Slack / チケット / メール ── 全部つながっていると、AIは横断して最適化する。
これは人間なら絶対にやらない動きだ。
- 別プロジェクトの機密情報が回答に混入
- 本来見せてはいけない情報を要約に含める
- Aの質問に対してBのデータを参照し、Cに出力
👉 「"横断できる設計"がすでにリスク」
③ システム→外界の境界（書き込み権限）
AIにSlack投稿、チケット更新、メール送信の権限を与えた瞬間、出力＝外部影響になる。
- 間違った情報を全社Slackに投稿
- 機密内容を含むチケットコメント
- 誤った宛先へのメール送信
👉 「AIに"発言権"を与えた瞬間、事故は外に出る」
これはMCPだけの問題ではない
ここが重要なポイントだ。
| プラットフォーム | 統合対象 | 構造 |
|---|---|---|
| MCP | 各種ツール・API | サーバ経由で広範囲アクセス |
| Google（Gemini） | Gmail / Drive / カレンダー | Google Workspace全体 |
| Microsoft（Copilot） | Outlook / Teams / SharePoint | Microsoft Graph経由 |
| Slack AI | チャンネル / DM / ファイル | ワークスペース全体 |
全部同じ構造だ。
👉 "便利さ = 権限の統合" だから危ない。
どのプラットフォームでも、連携が増えるほどリスクは線形ではなく指数関数的に増える。
接続先が増えるほど、「どのデータがどこに流れるか」の把握が急激に難しくなるためだ。
最低限これだけやれ（3つの対策）
「全部やれ」は非現実的だ。
だから3つに絞る。
対策①：外部送信はデフォルト禁止
最優先。
これだけで事故の大半を防げる。
- allowlist方式：許可したAPIのみ通す（ブロックリストではなく許可リスト）
- 送信前の人間確認：最低でも導入初期は必須
- MCPなら
toolsの定義で外部呼び出しを制限できる - ツール呼び出しログを必ず取得・保管する：「どの入力がどの外部APIに渡ったか」を追跡できる状態にしておく
これは「最小権限の原則（Principle of Least Privilege）」そのものだ。
AI時代でもこの原則は変わらない。
例えば、OpenAI / Gemini / 各種SaaSのAPIにそのままデータを渡している場合、「プロンプトとして送信された内容」は外部処理対象になる点に注意が必要だ。
❌ デフォルト：全部許可 → 必要に応じてブロック
✅ デフォルト：全部禁止 → 必要に応じて許可
対策②：データ参照は分断する
「全部つなぐ」をやめる。
- プロジェクト単位・用途単位でMCPを分離
- 機密レベル別にアクセス範囲を設定
- 公開情報 → AI連携OK
- 社内情報 → 読み取りのみ
- 機密・極秘 → AI連携禁止
「全部つなぐと便利」は正しい。
だが**「全部つなぐと危険」も同時に正しい**。
対策③：書き込みは人間承認
- read-onlyから始める（まず読み取りだけ許可）
- 書き込み・送信は段階的に解禁
- 自動実行は十分な検証の後に限定的に許可
| フェーズ | 権限 | 承認 |
|---|---|---|
| 導入初期 | 読み取りのみ | 不要 |
| 検証後 | 読み取り＋書き込み | 毎回人間承認 |
| 安定運用後 | 一部自動化 | 例外のみ人間承認 |
なぜこの3つなのか？
すべて 「境界」を守るため だ。
| 対策 | 守る境界 |
|---|---|
| ① 外部送信禁止 | 社内 ↔ 外部 |
| ② データ参照の分断 | データ ↔ データ |
| ③ 書き込みの人間承認 | システム ↔ 外界 |
セキュリティは"境界管理"でほぼ決まる。
これは従来の「ゼロトラスト」の考え方とも一致する。
おわりに：問題はAIではない
AIはミスをしない。
ただし、設計通りにしか動かない。
そして今、多くの現場では「便利さ」を優先した設計が先行している。
その結果として生まれるのが――
👉 "最強の内部不正者"としてのAI である。
問題はAIではない。
どう使うか、どう繋ぐかの設計そのものだ。
「使うな」ではない。
「設計しろ」 だ。
セキュリティ事故は"悪意"ではなく"設計ミス"で起きる。
「"便利だから全部つなぐ"は一番危険な設計です」
まずは、自分の環境で「AIが外部に何を送れるのか」を確認してほしい。
そこが見えていないなら、あなたの組織はすでに"制御できていないAI"を使っている。
AIは便利なツールではない。制御しなければ、"勝手に動く内部システム"になる。