「便利そうだから」で外部のMCPサーバーを追加し、あとから何を許可したのか誰も把握していない——中小企業の開発現場でも起きうる話だ。MCP（Model Context Protocol）はClaude Codeを外部のツール・データベース・APIにつなぐ仕組みで、便利さと引き換えに新しい確認事項を増やす。Claude Codeの公式ドキュメントに実際に書かれている境界線を基準に、追加前に確認すべき5項目を整理する。

1. どのスコープに置くか

MCPサーバーの設定は3つのスコープに分かれ、それぞれ保存場所と共有範囲が違う。

スコープ使える範囲チームに共有されるか保存場所
local（既定）追加した本人・そのプロジェクトのみされない~/.claude.json
projectそのプロジェクトの全員される（バージョン管理経由）プロジェクト直下の.mcp.json
user追加した本人・全プロジェクトされない~/.claude.json

判断基準は単純で、認証情報を含む個人的な設定はlocalかuserに留め、チーム全員が同じツールを使うべき設定だけをprojectスコープの.mcp.jsonに置く。.mcp.jsonはgitにコミットする前提の場所なので、ここに生の認証情報を書いてしまうと、リポジトリを見られる人全員に渡ることになる。

2. 認証情報を平文で書いていないか

.mcp.jsonは環境変数展開（${VAR}・${VAR:-default}）をサポートしている。これを使えば、チームで設定ファイルを共有しつつ、実際のAPIキーは各メンバーのローカル環境変数に置いたままにできる。書き込む場所はcommand・args・env・url・headersのどこでも展開できるので、認証情報が絡む項目は基本的にすべて変数化できる。

OAuth認証に対応しているMCPサーバーなら、そちらを優先する方が扱いが安全になる。認証後のクライアントシークレットはmacOSではシステムキーチェーンに、それ以外では認証情報ファイルに保存され、設定ファイル自体には残らない。詰まりやすいのは、動作確認のために一度平文のトークンを.mcp.jsonに書いて、そのままコミットしてしまうケースだ。claude mcp addは認証情報を検証せずに設定を保存するため、間違った値でも一見エラーなく登録できてしまう。/mcpで接続状態がconnectedになっているかまで確認する癖をつけておくといい。

3. project scopeの承認フローを迂回していないか

.mcp.json経由のproject-scopedサーバーは、対話セッションでは利用前に承認プロンプトが出る仕組みになっている。ここで見落としやすいのが、クローンしてきたリポジトリは自分自身のMCPサーバーを承認できないという設計だ。リポジトリの.claude/settings.jsonに「このサーバーは自動承認する」という設定を書き込んでおいても、ワークスペースを信頼していない状態では無視される。承認済みの状態を持ち込めるのは、ユーザー個人の設定・組織の管理設定・--settingsで明示的に渡した設定など、リポジトリの外側にある設定だけだ。

これは、リポジトリ自体やその中の設定ファイルが「自分は安全だ」と自己申告してMCPサーバーの自動承認を勝手に得る、という抜け道を塞ぐための仕組みになっている。裏を返せば、claude -pのような非対話実行やCI・クラウドセッションではこの承認プロンプト自体が出ない。project-scopedサーバーをそのまま読み込む前提になるため、CI環境に組み込む場合はdisabledMcpjsonServersで明示的に対象外にできることも含めて、あらかじめどのサーバーを読み込ませるかを決めておく必要がある。

4. 外部コンテンツを取得するサーバーかどうか

公式ドキュメントは、MCPサーバーを追加する画面でこう警告している。「各サーバーを接続する前に、そのサーバーを信頼できるか確認すること。外部コンテンツを取得するサーバーは、プロンプトインジェクションのリスクにつながりうる」。Web検索・スクレイピング・外部API経由でドキュメントを取得するようなMCPサーバーは、取得した内容の中に紛れ込んだ指示をClaudeが実行してしまう経路になり得るという意味だ。以前紹介したWebFetchツールの脆弱性も、外部コンテンツの取得が起点になっていた話として通じる。

自社で使う分にはリスクの許容度を判断できても、顧客の環境やCI経路に組み込む場合はこの一文だけでは足りない。そのサーバーが具体的にどのドメインへ何を取りに行くのか、取得結果をどう処理するのかまで確認してから接続するのが筋がいい。

5. 「Anthropicの公式ディレクトリに載っている」を安全の証明にしていないか

ここが一番誤解されやすい。Anthropicは公式ディレクトリに掲載するコネクタを独自の掲載基準で審査しているが、セキュリティに関する公式ドキュメントは同じ文の中で明確に線を引いている。「Anthropicはディレクトリに追加する前にコネクタを掲載基準に照らして審査するが、MCPサーバーのセキュリティ監査や運用管理は行わない」。掲載基準を通っていることと、そのサーバーの実装が安全であることは別の話だ、という意味になる。公式ドキュメントの推奨も「自社でMCPサーバーを書く」か「信頼できる提供元のMCPサーバーを使う」のどちらかで、“ディレクトリに載っているものを選べば安心”という書き方はしていない。

詰まりやすい箇所

実務でつまずくのは、たいてい「動いた」時点で確認を終えてしまうことだ。claude mcp addは認証情報を検証せずに保存を通すため、接続できているかどうかは/mcpかclaude mcp listで別途確認しないと分からない。project scopeで追加したはずのサーバーが同僚の環境で動かない場合も、ワークスペーストラストを受け入れていないことが原因のケースが多く、エラーメッセージからは気づきにくい。

MCPは便利な分だけ、確認すべき項目も新しく増える。ここまでの5項目は、既存記事で整理した許可ルール・サンドボックス・auto modeという別々の壁のうち、主に「何を信頼するかを自社で決める」という入口の話にあたる。この考え方の土台にあるのはハーネスという発想——AIの判断力そのものに頼るのではなく、構造で安全を確保することだ。自社のMCP・権限設計を一度棚卸ししたい場合は、パイロット・構築のフェーズで一緒に整理できる。まずは30分の無料診断から相談してほしい。