Claude Code で MCP を使いたいが、何をどうつなげばよいのか分からない。claude mcp add で server を増やすところまではできても、local stdio と remote HTTP のどちらを選ぶべきか、OAuth をどこまで絞るべきか、session を持つ前提でどこまで設計すべきか、未承認 server をどう止めるべきかで止まりやすいです。
この記事は、Claude Code で MCP を実務導入する人向けの手順書です。組織配布そのものの設計は Claude Code managed settings 設計ガイド に、認証・監査・配布統制の全体論は MCP エンタープライズ運用ガイド に分けています。transport と session lifecycle を先に整理したい場合は MCP Streamable HTTP 移行ガイド、remote MCP の prompt injection と承認境界を先に固めたい場合は MCP prompt injection 対策ガイド を併読すると、接続面と安全面を分けて理解しやすいです。今回はそれより一段手前の、「Claude Code から MCP をどうつなぎ、どこに安全境界を置くか」に絞ります。社内ルールを先に作りたい場合は AIコーディングツールの社内ガイドライン を先に読んでください。
読む順番の目安としては、まず本記事で claude mcp add と local/remote の分け方を押さえ、その次に Claude Code managed settings 設計ガイド で team 配布の固定方法を整理し、最後に MCP エンタープライズ運用ガイド で OAuth・監査・SSO を含む全社運用へ広げると、個人導入と中央統制を混同しにくくなります。
先に結論: 最初に決めるのは server の種類ではなく、3つの境界
Claude Code の MCP 導入で最初に決めるべきなのは、便利そうな server 名ではありません。私なら次の3つを先に決めます。
- 接続境界: local stdio で動かすのか、remote HTTP でつなぐのか
- 承認境界: read-only と write 系を同じ session に置くのか分けるのか
- 配布境界: 個人ごとに自由追加を許すのか、allowlist で絞るのか
この順序を飛ばして「とりあえず GitHub server を足す」「Notion も Slack も入れる」と始めると、あとで permissions と managed settings を足しても運用が歪みます。Claude Code の MCP は接続機能というより、権限を伴う実行面だからです。
Claude Code で MCP を追加する基本手順
Claude Code の公式ドキュメントでは、MCP server は claude mcp add と claude mcp add-json で追加できます。remote HTTP server の最小形はかなり単純です。
claude mcp add --transport http my-server https://mcp.example.com/mcpJSON 設定があるなら add-json の方が再現しやすいです。
claude mcp add-json docs-search '{"type":"http","url":"https://mcp.example.com/mcp"}'stdio server はローカルコマンドを直接登録します。
claude mcp add-json local-tools \
'{"type":"stdio","command":"/opt/company-mcp/local-tools","args":["serve"]}'追加後は Claude Code 上で /mcp を開き、接続状況や認証状態を確認します。OAuth 付き server なら、ブラウザの認証フローがここで走ります。CLI 側では claude mcp get <name> で設定確認もできます。
ここで重要なのは、追加できたことと安全に運用できることは別だという点です。接続確認の次に見るべきは、次の3項目です。
- この server は stdio か remote HTTP か
- この server は read-only か write を含むか
- この server は個人設定なのか managed settings で統制するのか
local stdio と remote HTTP はどう分けるか
これは「どちらが高性能か」ではなく、「どちらが説明しやすいか」で決めた方が失敗しません。
stdio が向くケース
- ローカルの開発補助ツールをつなぐ
- 社内で配布する固定コマンドがある
- ネットワーク越しの OAuth や共有認証を使わない
たとえば、社内専用のコード検索 helper やローカル変換ツールを 1 台の管理端末で動かすなら stdio でも成立します。
ただし stdio は、MCP server を追加する行為がほぼローカルコマンド実行です。npx や任意スクリプトを自由追加できる状態では、MCP 導入がそのまま未承認コード実行の入口になります。ここは Claude Code managed settings 設計ガイド で書いた managed-mcp.json や serverCommand 制限の論点と直結します。
remote HTTP が向くケース
- 複数人に同じ server を配りたい
- OAuth や scope 制御を使いたい
- 接続先 URL を allowlist で統制したい
- 監査や停止を server 側で集約したい
公式 docs でも、HTTP transport には OAuth、callback port、metadata discovery、scope 固定の仕組みがあります。組織利用で GitHub、Slack、社内 API などをつなぐなら、原則は remote HTTP を標準にした方が運用しやすいです。
私の基準は単純です。個人マシン固有の補助なら stdio、共有基盤や SaaS 連携なら remote HTTPです。迷ったら remote HTTP から考えた方が後戻りが少ないです。
OAuth 付き remote MCP で最初に見るべきポイント
Claude Code の公式 docs では、OAuth 付き HTTP server を --client-id、--client-secret、--callback-port 付きで追加できます。
claude mcp add --transport http \
--client-id your-client-id --client-secret --callback-port 8080 \
my-server https://mcp.example.com/mcpJSON でも同じことができます。
{
"mcpServers": {
"my-server": {
"type": "http",
"url": "https://mcp.example.com/mcp",
"oauth": {
"clientId": "your-client-id",
"callbackPort": 8080,
"scopes": "repo:read issues:read"
}
}
}
}このとき私なら、接続確認より先に次を見ます。
1. scope を絞れるか
Claude Code docs では oauth.scopes を space-separated string で固定できます。上流の authorization server が広い scope を返せる場合でも、クライアント側で「今回は read-only だけ」に寄せられます。
最初から chat:write や repo 全体を取りにいくより、まず read-only で始める方が堅いです。
2. metadata discovery を信じすぎないか
公式 docs には authServerMetadataUrl で OAuth discovery の参照先を明示上書きする設定があります。上流の metadata 解決が不安定なときに便利ですが、逆に言えば discovery 自体が接続面です。
MCP の Security Best Practices でも、malicious server が OAuth discovery URL を悪用して SSRF を狙う攻撃面が整理されています。したがって、remote MCP を配るときは「URL がつながるか」だけでなく、「どの metadata を信頼するか」まで固定した方がいいです。
3. token passthrough を前提にしないか
MCP Authorization と Security Best Practices では、token passthrough は明確に anti-pattern とされています。MCP server は、自分向けに発行された token だけを受け付け、下流 API 向け token をそのまま流してはいけません。
Claude Code 利用者の立場でも、この前提は重要です。server 側で audience 検証や token 分離ができていないなら、Claude Code 側だけ安全でも不十分だからです。ここは MCP エンタープライズ運用ガイド の認証設計とセットで見てください。
承認は「毎回聞く」より「分けて置く」の方が効く
Claude Code は /permissions で権限を見られますし、managed settings では permissions.deny や allowManagedPermissionRulesOnly も使えます。ただ、MCP 導入で本当に効くのは、承認の回数より承認を残す場所です。
私なら次のように分けます。
| 用途 | 推奨 |
|---|---|
| docs / repo metadata / 社内ナレッジ参照 | 同じ session で許可してよい |
| issue / chat / web / logs のような未信頼コンテンツ | read-only session に分離 |
| GitHub write / ticket 更新 / deploy / DB 更新 | 別 session + 人間レビュー |
理由は単純で、外部コンテンツ系 server が持ち込む指示と write 系操作を同席させると、prompt injection や tool poisoning に弱くなるからです。MCP を強く使うほど、read と write をセッションごと分ける運用が重要になります。
allowlist / denylist は名前だけで終わらせない
Claude Code docs では、allowedMcpServers と deniedMcpServers は次の3種類で制限できます。
serverNameserverCommandserverUrl
ここで雑に serverName だけ許可すると、stdio server では実行コマンドまで固定できません。実務では次の使い分けが分かりやすいです。
remote HTTP を許可するとき
serverUrl で絞ります。
{
"allowedMcpServers": [
{ "serverUrl": "https://mcp.company.example/*" },
{ "serverUrl": "https://*.internal.example/*" }
]
}stdio を許可するとき
serverCommand で固定します。
{
"allowedMcpServers": [
{
"serverCommand": ["node", "/opt/company-mcp/github-readonly/index.js"]
}
]
}組織で自由追加を止めたいとき
managed-mcp.json を配って固定し、必要なら allowManagedMcpServersOnly を併用します。
この辺りは managed settings 記事でも触れていますが、今回の主題は「MCP 導入時にどこまで固定するか」です。私なら初期導入はこうします。
- remote HTTP の read-only server を 1〜2 個だけ配る
serverUrlベースで allowlist を置く- write 系はまだ配らない
- stdio は固定コマンド配布のものだけにする
私ならこう始める: Claude Code MCP の最小導入順
最初から Slack 書き込みや deploy まで開けない方がいいです。私なら次の順で進めます。
1. read-only remote MCP を1本だけ足す
最初の候補は、docs 検索、read-only repo metadata、社内ナレッジ参照のどれかです。開発者が価値を感じやすく、事故面が比較的狭いからです。
2. /mcp と /permissions で承認境界を確認する
接続できたら終わりではなく、どの tool が見えていて、何に承認が必要かを実際に見ます。承認が多すぎるなら、すぐ全部許可に寄せるのではなく、session 分離で解消できないかを考えます。
3. managed settings に寄せる範囲を決める
個人検証で終わらないなら、早い段階で allowedMcpServers と deniedMcpServers を managed settings に寄せます。個人設定のまま普及させると、後から棚卸しできません。
4. write 系 server は最後に追加する
GitHub write、チケット更新、社内 DB 変更、デプロイ操作は後ろです。先に review 導線、監査、bot 資格情報分離を決めないと危険です。
よくある詰まりどころ
「HTTP server はつながるのに認証が終わらない」
callbackPort と登録済み redirect URI の不一致をまず疑います。Claude Code docs でも、この2つは合わせる前提です。
「server は追加できたが、本番運用に乗せにくい」
個人設定で増やしただけで、allowlist、scope、権限主体が未整理なことが多いです。接続成功の次に、managed settings 化できる形かを見てください。
「read-only のつもりなのに不安」
未信頼コンテンツ系 server が同じ session にいて、別の write tool や shell 実行が見えていないかを確認します。server の read/write だけでなく、session 全体の到達可能性を見るべきです。
まとめ
Claude Code MCP の実務導入で大事なのは、MCP server を増やすことではありません。local/remote の選び分け、承認を残す位置、allowlist の粒度です。
私なら、まず read-only remote MCP を最小構成でつなぎ、/mcp と /permissions で挙動を確認し、allowedMcpServers と deniedMcpServers を早めに managed settings へ寄せます。stdio は固定コマンドだけ、write 系は別 session と人間レビュー前提。この順で進めると、Claude Code の MCP は「便利だけど危ない接続機能」ではなく、再現可能に配れる作業面になります。