MCPをつなぐ前に確認する10項目。設定ファイル1つで6つは確認できる

MCP でAIを社内のデータやツールにつなぐ前に、情シスが自分で確認できることが6つ、提供元に聞くことが4つあります。合わせて10項目です。10項目のうち6つは、利用者の端末にある設定ファイル1つとログを見れば済みます。

先に、何が起きるかを1件だけ見ておきます。2025年5月、GitHub の公式 MCP サーバーで、公開リポジトリの Issue に仕込まれた指示にエージェントが従い、利用者がアクセスできる非公開リポジトリの中身を公開リポジトリのプルリクエストとして書き出す実演が公表されました。利用者は、公開リポジトリの Issue を見てほしいと頼んだだけです。Invariant Labs は、これは MCP サーバーのコードの欠陥ではなく作りの問題であり、対策は1つのセッションで触れるリポジトリを1つに限ることと、最小限の権限のトークンを使うことだとしています²。

つまり、つないだ相手の範囲と権限を、つなぐ前に決めておく話です。MCP そのものの説明は別の記事にまとめてあります。

まず設定ファイルを開く

MCP サーバーは、AIクライアントの設定ファイルに書かれた内容で起動します。Claude Desktop の場合、ファイルは次の場所にあります³。

• macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
• Windows: %APPDATA%\Claude\claude_desktop_config.json

中身は、サーバーごとに command と args、必要なら env が並んだ JSON です。公式の手順書の例に env の行を足し、確認する4か所に番号を振りました³。

この1ファイルに、つないである相手、起動するコマンド、渡している権限、預けている鍵がすべて書いてあります。以下の01から05は、これを読めば確認できます。06は、同じ端末に残るログを見ます。

自分で確認する6項目

01 どのサーバーがつながっているか

mcpServers の下に並んでいる名前が、つないである相手の一覧です。部門が先に入れていれば、ここに情シスの知らない名前があります。まず棚卸しです。

02 起動コマンドは何か

command と args が、AIクライアントを立ち上げるたびに実行されます。図の例にある npx -y は、指定したパッケージを確認なしで取得して実行する指定です。何が取得されて動くかは、args のパッケージ名で決まります。

公式の手順書は、サーバーが利用者のアカウントの権限で動くこと、つまり利用者が手で行える操作はすべて行えることを注意書きにしています³。仕様も、ワンクリックで設定するクライアントに対し、実行するコマンドを省略せず表示して明示的な承認を求めることを必須にしています¹。導入時に承認画面が出たか、出たなら何と書いてあったかを確認します。

03 鍵が平文で置かれていないか

env に API キーなどを書く形式があります。公式の手順書にも、env にキーを置く例が載っています³。設定ファイルは利用者の端末に平文で置かれるので、そこに何の鍵があるか、誰の名義の鍵かを確認します。

04 触れる範囲はどこまでか

図の例では、args の末尾に列挙したディレクトリだけをサーバーが読み書きできます。手順書は、Claude に読み書きされて構わないディレクトリだけを渡すよう求めています³。ファイル以外のサーバーなら、トークンに付けた権限が同じ役割です。読み取りで足りる用途に書き込みや削除まで渡していないかを見ます。

05 1つのサーバーが複数の機密源にまたがっていないか

GitHub MCP の件で Invariant Labs が挙げた緩和策は、1つのセッションで触れるリポジトリを1つに限ることでした²。公開と非公開、部門AとB、顧客甲と乙。1つのサーバーが両方に届く形になっていると、片方に仕込まれた指示でもう片方が出ていきます。またがっているなら、サーバーを分けるか、片方への権限を外します。

06 記録は残っているか

Claude Desktop は MCP の接続と各サーバーの出力をログに書きます。macOS は ~/Library/Logs/Claude、Windows は %APPDATA%\Claude\logs にあり、mcp.log が接続の記録、mcp-server-サーバー名.log がサーバーごとの出力です³。事故が起きてから、何が動いたかを追う手段がここにしかない場合があります。ログが出ているか、どこまで残るかを確認します。

提供元に聞く4項目

社外の MCP サーバーや、開発部門が作ったサーバーについては、作った側にしか答えられないことがあります。

07 仕様のどの版に準拠しているか

現行の仕様は2026年7月28日版です¹。この版でプロトコルからセッションが無くなり、処理をまたいで状態を持つサーバーは明示的な識別子を発行して引数で受け取る形に変わりました。仕様は、その識別子を持っていることを認証として扱ってはならないと定めています¹。以前の版に基づいた資料のセッションの話は、そのまま当てはまりません。準拠している版を聞き、書いていなければ書いていない事実を記録に残します。

08 トークンは自分宛てのものだけ受け付けるか

仕様は、MCP サーバーが自分宛てに発行されていないトークンを受け入れてはならないと定めています¹。他のサービス向けに出たトークンをそのまま下流へ通す作りは、明確に禁止されています。禁止の理由として仕様が挙げているのは、通した先のログに別の名前で記録が残って追跡できなくなることと、盗まれたトークンでそのサーバーが持ち出し口にされることです¹。

09 権限は段階的に上げる作りか

仕様は、最初は低リスクの権限だけを渡し、必要になった時点で段階的に上げる形を推奨し、全部入りの広い権限を1つ用意する作りをよくある間違いとして挙げています¹。最初の同意画面に何が並ぶかで、どちらの作りかが分かります。

10 認可まわりの実装が仕様のセキュリティの章に沿っているか

仕様のセキュリティの章には、認可の実装で起きる攻撃がまとまっています。同意を使い回される混乱した代理、サーバーが返した URL をたどって社内やクラウドの内部にアクセスさせられる SSRF、認可 URL に実行可能なスキームを混ぜられる問題、認可サーバーの取り違え¹。どれも情シスが外から検証できるものではなく、実装した側の責任です。この章に沿って実装しているか、していないならどの項目かを聞きます。

順番

10項目を全部やる前に、01と05だけ先にやってください。つないである相手の一覧と、1つのサーバーが複数の機密源にまたがっていないかの2つです。GitHub MCP の件は、この2つだけで防げた種類のものでした。