13
15

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

MCP サーバーと繋いだだけで情報漏洩? 危険の4パターンと事前に確認すべき7つのことをまとめてみた

13
Posted at

MCPサーバーを追加する前の図。上に利用者→AIエージェント→MCPサーバー→業務システムの流れ。下に危険の4パターンと確認すべき7つのこと。A ツールポイズニング→①提供元とバージョンを確かめる。B 間接プロンプトインジェクション→②issue・Web・PDFなど外部第三者の書き込みを読むか。C 過剰な権限・有効期間の長いキー→③追加するスコープを決める④ツールと権限を最小にする⑤キーの保存場所と取り消し方。D 自動承認(Human in the Loopなし)→⑥承認の既定と常に許可の範囲⑦承認が出ない実行で使わない

MCP(Model Context Protocol)を使うとき、利用者は Claude・Codex・Antigravity などの AI エージェントに頼めば(あるいは簡単な設定をすれば)、AI エージェントが MCP サーバーのツールを呼び出せるようになります。

簡単に接続できる一方で、危険を確かめないまま接続してしまうと、間接プロンプトインジェクションツールポイズニング で AI エージェントが乗っ取られ、非公開のデータが誰でも見られる場所へ書き出されたり、業務システムの資格情報(キーやトークン)が攻撃者の用意した宛先へ送られたりするおそれがあります。どちらも、実際に報告された事例です。

この記事は、MCP の仕様、報告された事例 2 件、公開されている MCP サーバーの実装を数えた調査 2 本、そして Claude CodeClaudeCodexAntigravity の公式文書をもとに、危険を 4 つのパターン(ツールポイズニング・間接プロンプトインジェクション・過剰な権限と有効期間の長いキー・自動承認)に整理し、MCP サーバーを追加する前に確認すべき 7 つのことをまとめたものです。上の図が、その全体です。

答える問いは 3 つです。

  • MCP サーバーを AI エージェントに追加して、安全か?
  • MCP サーバーを信用して良いか?
  • 追加する前に、何を確かめればいいか?

この記事は、IT連携マップ(renkeimap.jp)の調査ページ MCP サーバーを追加する前に、何を確かめるか をもとにした Qiita 版です。仕様と実装の調査は MCP で繋ぐと中身はどこへ行くか、事例は 間接プロンプトインジェクション に置いています。引用した英語の原文と出典は、それぞれのページで 1 行ずつ確かめられます。

この記事で使う言葉

先に、この記事の土台になる言葉をそろえます。

言葉 この記事での意味
MCP(Model Context Protocol) AI に「何ができるか」を伝え、外のシステムの機能を呼び出させるための決まり。詳しくは MCP とは何か
MCP サーバー 業務システムなどの機能を、AI が呼べる「ツール」として公開するプログラム。誰でも作って公開できます
ツール MCP サーバーが AI に提供する機能のひとつ。名前と説明文が付いていて、AI はそれを読んで何を呼ぶかを決めます
AI エージェント 頼まれたことを、ツールを使って自分で進める AI。Claude Code・Codex・Antigravity など。詳しくは AI エージェントとは何か
API 外のシステムが、決められた手順でデータや機能を使うための窓口。詳しくは API とは何か
資格情報(キー・トークン) システムに接続するための秘密の情報。API キーやアクセストークンなど。詳しくは API キーとは何かAPI トークンはいつ切れ、どう取り消すか
認可・OAuth 認可は、誰に何を許すかを確かめること。OAuth は、パスワードを渡さず、範囲と期限を決めて許可する仕組み。詳しくは OAuth とは何か
プロンプトインジェクション AI に読ませる文章の中に指示を紛れ込ませ、AI を意図しないとおりに動かす攻撃。詳しくは プロンプトインジェクション
間接プロンプトインジェクション プロンプトインジェクションのうち、Web・PDF・issue など 外部第三者の書き込み に指示を仕込むもの。詳しくは 間接プロンプトインジェクション
ツールポイズニング MCP サーバーが出す ツールの説明文 に指示を仕込むこと。AI は説明文を読んで何を呼ぶかを決めるので、そこが入口になります
過剰な権限 AI エージェントに、仕事に必要な範囲より広い権限を渡してしまうこと。渡した権限の大きさが、事故の大きさを決めます。詳しくは 過剰な権限と爆発半径
最小権限 必要な操作に必要な範囲だけの権限を渡す、という考え方
自動承認・Human in the Loop 自動承認は、ツールを呼ぶたびに人の確認を求めず、AI エージェントがそのまま実行する設定。Human in the Loop は、その逆に、人が確認して止められる状態を残すこと

1. 結論

問い 答え
追加して安全か 接続しただけで漏洩するわけではありません。ただ、仕様に従っているだけでは安全になりません。仕様は認可を「任意」とし、人の確認(Human in the Loop)も「推奨」にとどめています。安全かどうかは、何を追加し、どこまで自動承認で動かすかで決まります
サーバーを信用して良いか 信用は前提ではなく、確かめてから与えるものです。仕様は、ツールの説明文を、信用できるサーバーから得たものでない限り信用できないものとして扱うよう書いています。Anthropic は、信用できる組織のサーバーだけに接続するよう書いています。さらに、サーバーのコードに欠陥が無くても、サーバーが運んでくる文章(間接プロンプトインジェクション)で AI エージェントが乗っ取られた事例があります
何を確かめるか 冒頭の図の 7 つです。一つずつの説明と製品ごとの確かめ方は 8 章にあります

追加する前に確認すべき 7 つのこと

  1. 誰が作ったサーバーか。バージョンは最新か
  2. issue・Web・PDF・メールなど、外部第三者の書き込みを読むサーバーか
  3. どの範囲(スコープ)に追加するか(自分だけ・プロジェクトで共有・全体)
  4. ツールと権限を、必要なものだけに絞ったか
  5. キーやトークンがどこに保存され、どう取り消せるか
  6. 承認の既定はどうなっているか。「常に許可」は、無人で動かしてよいツールだけにしたか
  7. 承認が出ない動かし方(claude -p・SDK・クラウドなど)で使っていないか

2. 仕様の調査 — API と比べて何が変わるのか

REST・SOAP・GraphQL・gRPC・MCPの5方式を6つの軸で比べた表。1行目の機能一覧を実行時に出すかだけMCPが◎で他は—か△

この図で見てほしいのは 1 行目だけです。

  • MCP だけが、使える機能の一覧を 動いている最中(実行時)に 出す
  • その一覧(ツールの名前と説明文)を読んで、何を呼ぶかを決めるのは AI エージェント(Claude Code・Codex・Antigravity など)
  • つまり、説明文を書いた人が、AI エージェントの行動に口を出せる

API では、どの窓口をどの順に呼ぶかは、開発者が書いたプログラムが決めます。MCP では、それを AI エージェントが決めます。仕様自身が、MCP のツールは、AI(言語モデル)が文脈の理解と利用者の指示をもとに、見つけて自動で呼べるように作られている、と書いています。

比べる点 API(REST など) MCP
何を呼ぶかを決めるのは 開発者が書いたプログラム AI エージェント(Claude Code・Codex・Antigravity など)
使える機能の一覧 設計のときに人やプログラムが読む仕様書(OpenAPI など) 実行時にサーバーへ問い合わせて受け取り(tools/list という要求)、AI エージェントが読む
認可 規格の外(OAuth などを別に組み合わせる) HTTP で接続する形では、OAuth を土台にした決まりが仕様の中にある。ただし付けるかどうかは「任意」

1,899 件の実装を調べた論文も、AI が処理の流れを決め、毎回同じ動きになるとは限らない MCP の作りが、新しい危険を持ち込むと書いています。

仕様は守り方も書いています。ツールの呼び出しを拒否できる人が常に間に入る、サーバーを呼ぶ前にツールへの入力を利用者に見せる、結果を言語モデル(LLM)に渡す前に検証する、使う操作に必要な範囲だけの権限を求める。ただし、これらはすべて「推奨」(SHOULD)です。「必須」(MUST)は、入力の検証・アクセス制御・呼び出し回数の上限・出力の無害化の 4 つで、どれもサーバー側の義務です。

つまり、自動承認を使うかどうかは、仕様ではなく、使う側の設定で決まります。

📎 仕様の原文は MCP で繋ぐと中身はどこへ行くか の「仕様が書いている守り方」、API との比べ方は MCP とは何か にあります。


3. 事例の調査 1 — 間接プロンプトインジェクション:公開 issue 1 件で、非公開リポジトリの内容が漏洩しうる(GitHub の MCP サーバー)

GitHubのMCPサーバーの事例を4段で示した図。1 攻撃者が公開リポジトリにAIへの指示を書いたissueを作る。2 利用者が無害な依頼をし、AIエージェントがMCPサーバーでissueを読む。3 AIエージェントが指示を命令として受け取り、非公開リポジトリのデータを読み込む。4 非公開の中身が公開リポジトリのプルリクエストに書き出される

まず、言葉を 3 つだけ確認します。GitHub はソースコードを置いて共同で開発するためのサービスで、ソースコードの置き場所を「リポジトリ」と呼びます(誰でも見られる公開リポジトリと、限られた人しか見られない非公開リポジトリがあります)。「issue」は不具合や要望を書き込む機能で、「プルリクエスト」は変更を提案する機能です。

2025 年 5 月、Invariant Labs は、GitHub の MCP サーバーを使うと次のことが起きうると報告しました。

攻撃者は AI に直接話しかけません。公開リポジトリに、AI への指示(プロンプトインジェクション)を書いた issue を 1 件作っておくだけです。利用者が AI エージェントに「公開リポジトリの issue を見て」と普通に頼むと、AI エージェントは GitHub の MCP サーバーで issue を読み、そこに書かれた指示を命令として受け取ります。そして、渡されていた権限のまま非公開リポジトリのデータを読み込み、誰でも見られる公開リポジトリのプルリクエストに書き出しました。

報告は「悪意ある GitHub の issue で利用者のエージェントを乗っ取り、非公開リポジトリのデータを漏洩させることができる」と書いています。利用者は普通のことを頼んだだけで、MCP サーバーも正しく動いています。

ここで大事なのは、報告者自身が 「GitHub の MCP サーバーのコード自体の欠陥ではない」 と書いていることです。エージェントの仕組みの側で対処すべき設計上の問題で、特定の AI エージェントや MCP クライアント(MCP サーバーに接続する側のアプリ)に限った話でもない、としています。

つまり、信用できるサーバーを選んでも、そのサーバーが運んでくる文章までは信用できません。 報告が勧める対策は、AI エージェントが触れるリポジトリを必要なものだけに絞ること(最小権限)です。渡した権限の大きさが事故の大きさを決める、という考え方は 過剰な権限と爆発半径 に、AI エージェントの暴走を 4 層(隔離・読み書きの分離・人の確認・外への通信の遮断)で防ぐ方法は AI エージェントの暴走を防ぐ にまとめています。

📎 英語の原文は 間接プロンプトインジェクション の「MCP のツールで実際に起きたこと」 で確かめられます。


4. 事例の調査 2 — プロンプトインジェクション:細工したホスト名 1 つで、資格情報が外へ送られうる(CVE-2026-18655)

2 件目は、サーバーそのものに欠陥があった例です。CVE は、公開された脆弱性に付く共通の番号です。

2026 年 8 月、AWS Labs は、自分たちが公開している Amazon MQ の MCP サーバーについて勧告(脆弱性と対処を知らせる文書)を出しました。Amazon MQ はメッセージを中継するサービスで、その中継役のサーバーを「ブローカー」と呼びます。勧告の題は「プロンプトインジェクションによる、ブローカーの資格情報と OAuth トークンの漏えい」です。

この MCP サーバーのツールは、接続先のホスト名(接続先のサーバーを指す名前)を引数で受け取ります。AI エージェントが処理した内容に指示が埋め込まれていると、AI エージェントはツールを呼ぶときに、細工したホスト名を渡してしまいます。すると 2.0.24 より前のバージョンでは、利用者の資格情報や OAuth のアクセストークンを載せた要求が、その任意の宛先へ送られえました。

事例 1 と違い、こちらはサーバー側に直すべき欠陥がありました。それでも、入口は同じく AI が読んだ文章 です。勧告は、次の 3 つの対処を挙げています。

勧告が書いている対処 意味
最新バージョンに上げ、派生したコードも直す サーバーの欠陥をふさぐ
ブローカーの資格情報を入れ替える 漏洩したかもしれないキーを使えなくする
それまでは、該当するツールに自動承認を使わない 実行前に、人が宛先を目で確かめられる

3 つ目に注目してください。修正版を入れるまでの暫定策が、自動承認を切って、人が確かめる ことでした。2 章で見た仕様の「人の確認」を、実際の勧告が使った例です。

📎 勧告の英語の原文は 間接プロンプトインジェクション の同じ節 で確かめられます。


5. 実装の調査 1 — 有効期間の長いキー:半数を超えるサーバーが頼っている(5,200 件超)

事例は 2 件ですが、MCP サーバー全体ではどうなっているのでしょうか。Astrix Security は、オープンソース(ソースコードが公開されたもの)の MCP サーバーの実装 5,200 件超を、資格情報の扱い方について調べました。

分かったこと 割合
資格情報を必要とする 88%
API キーや個人用アクセストークンのような、有効期間の長い固定のキーに頼る 53%
OAuth のような方式を使う 8.5%
API キーを、単純な環境変数(プログラムの外から設定値を渡す仕組み)で渡す(API キーを使うものの中で) 79%

調査は、その固定のキーが「長く使われ、めったに入れ替えられない」とも書いています。すべての接続先が OAuth に対応しているわけではないが、OAuth がよいやり方とされている、とも。

AI エージェントに MCP サーバーを追加するとき、多くの場合、業務システムのキーをそのサーバーに渡すことになります。漏洩したときに長く使え、止めにくいキー を渡していないかが、確かめる点です。

なお、これは サーバーが接続する先のサービスへの資格情報を、どう持っているか の数字です。動いている MCP サーバーの入口に認証が付いているかを数えたものではありません。

📎 調査の原文は MCP で繋ぐと中身はどこへ行くか の調査の詳細、キーの期限と取り消し方は API トークンはいつ切れ、どう取り消すか、漏洩したキーがどれだけ使えるままかは API キーは実際どう漏れるのか にあります。


6. 実装の調査 2 — ツールポイズニング:5.5% のサーバーで、ツールの説明文に仕込みがあった(1,899 件)

もう 1 本は、オープンソースの MCP サーバー 1,899 件を、健全性・安全性・保守性について調べた論文(arXiv:2506.13538)です。

分かったこと
特定した脆弱性の種類 8 種類。うち従来のソフトウェアの脆弱性と重なるのは 3 種類だけ
一般的な脆弱性があったサーバー 7.2%
MCP 特有のツールポイズニング(ツールの説明文への仕込み)があったサーバー 5.5%

ツールの説明文は、2 章で見たとおり、AI が何を呼ぶかを決めるときに読む文章です。そこに指示が仕込まれていれば、サーバーを作った人が AI の動きを左右できます。仕様が説明文を「信用できないもの」として扱うよう求めているのは、このためです。

8 種類のうち 5 種類は、従来のソフトウェアの脆弱性と重なりません。いつもの脆弱性の見方だけでは捉えにくい種類がある、ということです。論文は、MCP サーバーの一覧を載せるレジストリで、自動の安全検査を回せるようにすることを勧めています。

📎 論文の原文は MCP で繋ぐと中身はどこへ行くか の調査の詳細 で確かめられます。


7. 分析と整理 — 危険は 4 つのパターンに分かれる

7-1. 4 つのパターン

ここまでの 5 本を並べると、危険は次の 4 つのパターンに分かれます(筆者の整理)。

パターン 何が起きるか どこに現れたか
A. ツールポイズニング AI がツールを選ぶときに読む説明文に、指示が仕込まれる 仕様・実装の調査 2(5.5%)
B. 間接プロンプトインジェクション AI エージェントが、外部第三者の書き込み(issue・処理した内容)の中の指示に従う 事例 1・事例 2
C. 過剰な権限・有効期間の長いキー 乗っ取られたとき・漏洩したときの被害が大きく、止めにくい 事例 1・事例 2・実装の調査 1(53%)
D. 自動承認(Human in the Loop なし) A・B の指示が、そのまま実行される 仕様(人の確認は「推奨」)・事例 2

A と B は AI が乗っ取られる入口、C と D は 乗っ取られたときの被害の大きさ です。操作が取り消せるかどうかで被害が変わる点は 副作用と不可逆性 に、壊れても捨てられる場所で動かす方法は サンドボックスとは何か にあります。

7-2. 被害は、入口と権限の掛け算で決まる

事例 1 は B(公開 issue)× C(非公開リポジトリにも届く権限) でした。事例 2 は B(処理した内容)× C(ブローカーの資格情報) で、D(自動承認)を切ることが暫定策でした。

入口の A と B は、AI エージェントに外部第三者の書き込みを読ませる限り、サーバーを直すだけでは塞ぎきれません。事例 1 の報告者が「サーバーのコードの欠陥ではなく、エージェントの仕組みの問題」と書いたのは、このためです。だから、利用者が手を打てるのは、入口を減らすこと(A・B:確認 ①②)と、C を絞り、D を残すこと(確認 ③〜⑦)です。

7-3. 守る場所は、利用者の側に残る

MCPで誰が何を決めるかを4段に並べた図。仕様が定めること、仕様が求めること、仕様が決めないこと、だから見るものの4行。仕様2026-07-28から作成

  • 仕様が決めるのは、やりとりの形と最初の手順まで
  • どのサーバーに接続するか、自動承認を使うか、キーをどこまで渡すかは、仕様が決めない
  • だから、それを決めるのは利用者(と、その組織)

仕様の不備というより、誰でもサーバーを作って公開できる設計にした結果です。

📎 4 つのパターンと、それぞれがどこに現れたかは、原文つきで MCP サーバーを追加する前に、何を確かめるか の「危険は 4 つのパターンに分かれる」 にもまとめています。


8. まとめ — 追加する前に、確認すべき 7 つのこと

8-1. 確認すべき 7 つのこと(チェックリスト)

どの AI エージェントでも、MCP サーバーを追加する前に、次の 7 つを確かめてください。かっこの中は、防ぐパターンです。

  • ① 提供元とバージョン(A: ツールポイズニング)
    自分で作ったサーバーか、信用できる提供元のものか。事例 2 のように修正版が出ることがあるので、最新バージョンかも確かめる。
  • ② 外部第三者の書き込みを読むか(B: 間接プロンプトインジェクション)
    issue・Web・PDF・メールなど、外部第三者が書き込める文章を読むサーバーなら、そこが乗っ取りの入口になる。読ませる範囲を決めてから追加する。
  • ③ 追加するスコープ(C: 過剰な権限)
    自分だけか、プロジェクトで共有するか、すべてのプロジェクトで使うか。範囲が広いほど、知らないうちに使われる場面が増える。
  • ④ ツールと権限を最小に(C: 過剰な権限)
    使わないツールは外し、接続先で求められる権限も必要な範囲だけにする(最小権限)。
  • ⑤ キーの保存場所と取り消し方(C: 有効期間の長いキー)
    有効期間の長い固定のキーを渡していないか。漏洩したとき、すぐに取り消せるか。詳しくは API トークンはいつ切れ、どう取り消すか
  • ⑥ 承認の既定と「常に許可」(D: 自動承認)
    「常に許可」は、無人で動かしてよいと言えるツールだけにする。書き込みや外への送信をするツールは、人の確認を残す。
  • ⑦ 承認が出ない実行(D: 自動承認)
    Claude Code の場合、claude -p(対話なしで動かすコマンド)・Agent SDK(プログラムから動かすための部品)・クラウドでの実行では、承認を求める画面が出ない。CI(コードを変更するたびに自動で処理を走らせる仕組み)などで無人で動かす前に、何が読み込まれるかを確かめる。

📎 7 つを確かめる理由と、防ぐパターンの対応は MCP サーバーを追加する前に、何を確かめるか の「追加する前に確かめる 7 つ」 にもまとめています。

8-2. Claude Code

Claude Code は、Anthropic の AI エージェントです(mac・Linux・Windows とブラウザで使えます)。

  • 信用できるか確かめる: 公式文書は「接続する前に、各サーバーを信用できるか確かめる」と書き、自分で書いたサーバーか、信用できる提供元のサーバーを使うよう勧めています。Anthropic は一覧に載せる前にコネクタを審査しますが、MCP サーバーのセキュリティ監査も管理もしない、とも書いています(確認 ①)。
  • 外の内容を取ってくるサーバーに注意: 外の内容を取ってくるサーバーは、プロンプトインジェクションの危険を持ち込みうる、と書かれています(確認 ②)。
  • スコープを選ぶ: 追加するときに選ぶスコープで、どのプロジェクトで読み込まれ、チームと共有されるかが決まります。既定は、追加したプロジェクトだけ・自分だけです。プロジェクトで共有するスコープにすると、設定はプロジェクトの .mcp.json(設定ファイル)に書かれ、チームと共有されます(確認 ③)。
  • 承認が出ない動かし方に注意: .mcp.json のサーバーは、対話の中で使う前に承認を求めます。複製したリポジトリが自分でサーバーを承認することもできません。ただし claude -p・Agent SDK・クラウドでは、承認を求めずに読み込みます。自動実行や CI で使う前に、そのリポジトリの .mcp.json に何が書かれているかを見てください(確認 ⑦)。
  • 権限を絞る: MCP サーバーごとに権限を設定できます(確認 ④)。

8-3. Claude(アプリのカスタムコネクタ)

Claude のアプリでは、外部の MCP サーバーに「カスタムコネクタ」として接続します。

  • 信用できる組織のサーバーだけ: 信用できる組織やアプリが作り、動かしているサーバーにだけ接続するよう書かれています。悪意ある MCP サーバーは、Claude に意図しない動作をさせる隠れた指示を含みうる、とも書かれています(確認 ①)。
  • 認証の画面で権限を見る: 認証のときにサーバーが求める権限を確かめ、できるだけ範囲を絞り、不要な権限なら拒否します(確認 ④)。
  • 「常に許可」を押す前に: 「常に許可」は、無人で動かしてよいと信用できるサーバーとツールにだけ押すよう書かれています(確認 ⑥)。
  • 取り消し方: コネクタを外せば、いつでも権限を取り消せます(確認 ⑤)。

8-4. Codex

Codex は、OpenAI の AI エージェントです(mac・Linux・Windows のほか、IDE や Web でも使えます)。

  • 設定の置き場所: MCP の設定は config.toml(設定ファイル)に置きます。プロジェクト単位の設定は、信用したプロジェクトでだけ効きます(確認 ③)。
  • ツールを絞る: enabled_tools(許可リスト)と disabled_tools(拒否リスト)で、そのサーバーのツールのうち使うものだけに絞れます(確認 ④)。
  • 承認の既定を決める: default_tools_approval_mode で、そのサーバーのツールの承認の既定を決められます(確認 ⑥)。
  • サーバーの説明も指針になる: Codex は、サーバーが最初のやりとりで返す説明(instructions)を読み、ツールと並べてサーバー全体の指針として使います。サーバーを作った人が書いた文章が、AI エージェントの振る舞いに入るということです(確認 ①・パターン A)。

8-5. Antigravity

Antigravity は、Google の開発者向けのデスクトップアプリです。会話で「この URL の MCP サーバに繋いでもらえますか?」と頼むだけで、AI が自分で設定ファイルを書き換えて MCP サーバーを追加しました(筆者が 2026-09-08 に試した結果。画面は 自社システムに MCP は要るか の「AI は MCP をどうやって発見し、接続するのか」 にあります)。「追加する」操作そのものを AI が代わりにできる ので、何が追加されたかを設定ファイルで確かめる習慣が要ります(確認 ③)。

  • 設定の置き場所: 全体の設定は ~/.gemini/config/mcp_config.json、作業場所ごとの設定は .agents/mcp_config.json です(確認 ③)。
  • 承認の既定: 設定していない MCP のツールは、既定で確認(Ask)の扱いになり、実行の前に承認を求めます。ポリシーで、ツール単位・サーバー単位に許可できます。許可を広げる前に、どのツールを無人で動かしてよいかを決めてください(確認 ⑥)。
  • 資格情報の置き場所: アクセストークンは ~/.gemini/antigravity/mcp_oauth_tokens.json に保存されます。ヘッダーに固定のトークンを書く設定例もあります。その場合、キーは設定ファイルの中にそのまま入ります(確認 ⑤)。

8-6. 製品ごとの確かめ方の一覧

# 確かめること パターン Claude Code Claude Codex Antigravity
1 提供元とバージョン A 信用できる提供元を勧める 信用できる組織だけ サーバーの説明も指針になる
2 外部第三者の書き込みを読むか B 外の内容を取るサーバーはプロンプトインジェクションの危険 悪意あるサーバーの隠れた指示
3 追加するスコープ C スコープ プロジェクトの設定は信用したものだけ 全体/作業場所
4 ツールと権限を最小に C サーバーごとの権限 求める権限を絞る enabled_toolsdisabled_tools ポリシーでツール・サーバー単位
5 キーの保存場所と取り消し C 外せば取り消せる トークンの保存場所・ヘッダーの固定トークン
6 承認の既定・「常に許可」 D .mcp.json は承認を求める 「常に許可」は無人で動かしてよいツールだけ default_tools_approval_mode 既定は確認(Ask)
7 承認が出ない実行 D claude -p・SDK・クラウドは承認を求めずに読み込む

「—」は、その製品の文書から、この点について引いていないという意味です。無いという意味ではありません。

📎 製品ごとの英語の原文は MCP サーバーを追加する前に、何を確かめるか の「製品ごとの原文」 で確かめられます。

ほかの AI エージェントの MCP への対応は、IT連携マップの各ページで確かめられます: CursorGitHub CopilotChatGPTGeminiClineKiroDevin

接続する先の業務システムが、公式の MCP サーバーを出しているかどうかも確かめる点です。出している例は kintonefreee会計マネーフォワード クラウド会計Salesforce PlatformNotionGaroonShopify で、提供元の原文は各ページにあります。業務システム 56 件のうち何件が MCP を出しているかは 自社システムに MCP は要るか — 8 つの問い にまとめています。

MCP サーバーの提供元や社内の担当者には、こう聞くと答えがそろいます。

「この MCP サーバーは誰が作り、どの権限で業務システムに接続しますか。キーはいつ切れ、どう取り消せますか。書き込みの前に人が確かめる設定にできますか。AI に読ませる情報は、外部第三者が書き込める場所から来ていませんか。」

最後に、3 つの問いへの答えを短く繰り返します。接続しただけで漏洩するわけではありません。サーバーは作った人を確かめて選び、そのサーバーが運んでくる文章は信用しない。そのうえで、キーを絞り、人が止められる状態を残す ── これが、追加する前に決めておくことです。

8-7. もっと詳しく知りたいとき

知りたいこと renkeimap.jp の調査ページ
製品ごとの確かめ方の原文 MCP サーバーを追加する前に、何を確かめるか
仕様が決めていること・守り方 MCP で繋ぐと中身はどこへ行くか
読ませた文章が命令になる仕組み 間接プロンプトインジェクション
渡した権限の大きさと被害の大きさ 過剰な権限と爆発半径
AI エージェントの暴走を防ぐ 4 つの防壁 AI エージェントの暴走を防ぐ
API キーが漏洩する経路と、漏洩したあと API キーは実際どう漏れるのか
OAuth の仕組み OAuth とは何か
MCP と API のどちらを使うか MCP か API か
AI エージェントが業務システムを操作できる条件 AI エージェントは業務システムを操作できるか
キーの期限と取り消し方 API トークンはいつ切れ、どう取り消すか
自社のシステムに MCP が要るか 自社システムに MCP は要るか — 8 つの問い
各製品の MCP 対応 Claude CodeClaudeCodexAntigravity

参考までに、IT連携マップ編集部も MCP サーバーを公開しています。何を開いて何を閉じたかは、編集部の MCP は何を開き何を閉じるか に置いています。


一次出典・参考文献

資料 発表 原文
Model Context Protocol 仕様 2026-07-28 版 2026-07-28 modelcontextprotocol.io
Invariant Labs: GitHub MCP Exploited 2025-05-26 invariantlabs.ai
AWS Labs: GHSA-xwj6-8x5h-hjp6(CVE-2026-18655) 2026-08-03 github.com
Astrix Security: State of MCP Server Security 2025 2025-10-15 astrix.security
Hasan ほか: MCP at First Glance(arXiv:2506.13538) 2025 arxiv.org
Claude Code: MCP/Security code.claude.com/docs/en/mcp/security
Claude: Get started with custom connectors using remote MCP support.claude.com
Codex: MCP learn.chatgpt.com
Antigravity: MCP antigravity.google

引用はすべて、保存した原本に原文のまま在ることを確かめています。1 行ずつの英語の原文と出典は、renkeimap.jp の調査ページ(MCP サーバーを追加する前に、何を確かめるかMCP で繋ぐと中身はどこへ行くか間接プロンプトインジェクション)で公開しています。

読者アンケート実施中
このテーマをもっと深掘りしてほしい方は、記事に「いいね」をお願いします。「いいね」の多いテーマから順に追加調査し、結果は新着記事でお知らせします(フォローしていただくと通知が届きます)。

【転載OK】本記事の転載について

本記事の文章・図表は、すべて転載 OK です。図は加工しないままお使いください。転載の際は、出典として renkeimap.jp もしくは本記事へのリンクをお願いします。事前の連絡は不要です。

※ 筆者は日立系ITベンダー・介護ソフトベンダー・大学病院IT部門を経て独立し、現在は中小企業のIT・DX支援をしながら、業務システムの「つながり」を一次資料で調べています。 文中の「編集部」は、筆者が所属する IT連携マップ編集部 のことです。誤りを見つけられましたら 訂正窓口(無料・アカウント不要)へお願いします。訂正履歴も公開しています。

13
15
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
13
15

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?