Claude Code で MCP を使いたいが、何をどうつなげばよいのか分からない。検索では claude code add remote mcp server、stdio claude、claude code mcp add stdio command、claude mcp add stdio のように調べる人もいますが、実際に止まりやすいのは同じ地点です。claude mcp add で server を増やすところまではできても、Claude Code に stdio server command をそのまま足してよいのか、remote HTTP の方がよいのか、OAuth ログインをどこで済ませるべきか、session を持つ前提でどこまで設計すべきか、未承認 server をどの session に残すべきかで迷います。
この記事は、Claude Code で MCP を実務導入する人向けの手順書です。特に「stdio claude や claude code mcp add stdio command で検索しているが、本当に local command で始めてよいのか」と迷っている人を想定しています。組織配布そのものの設計は Claude Code managed settings 設計ガイド に、認証・監査・配布統制の全体論は MCP エンタープライズ運用ガイド に分けています。transport と session lifecycle を先に整理したい場合は MCP Streamable HTTP 移行ガイド と MCP Session 管理ガイド を、remote MCP の prompt injection と承認境界を先に固めたい場合は MCP prompt injection 対策ガイド を、Codex 側で approval reviewer をどう置くかまで比較したい場合は Codex auto-review ガイド を併読すると、接続面と安全面を分けて理解しやすいです。今回はそれより一段手前の、「Claude Code から MCP をどう追加し、どこに安全境界を置くか」に絞ります。社内ルールを先に作りたい場合は AIコーディングツールの社内ガイドライン を先に読んでください。
読む順番の目安としては、まず本記事で claude mcp add と local/remote の分け方を押さえ、その次に MCP Streamable HTTP 移行ガイド と MCP Session 管理ガイド で MCP-Session-Id と 404 再初期化の扱いを整理し、最後に Claude Code managed settings 設計ガイド と MCP エンタープライズ運用ガイド で team 配布と OAuth・監査・SSO を含む全社運用へ広げると、個人導入と中央統制を混同しにくくなります。
stdio claude で探している人向けの結論
結論だけ先に言うと、stdio claude で探している人が最初に決めるべきなのは「stdio でつながるか」ではなく、その local command を個人端末だけで閉じるのか、あとで team 配布まで広げるのかです。
- 個人マシン固有の補助ツールなら、固定コマンドの stdio から始めてよい
- GitHub、Slack、社内 API のような共有接続なら、最初から remote HTTP を優先した方が戻りが少ない
- stateful server を配るなら、
MCP-Session-Idと 404 再初期化を MCP Session 管理ガイド で先に揃えておく
そのうえで、個人検証を team 配布へ広げる段階になったら Claude Code managed settings 設計ガイド と MCP エンタープライズ運用ガイド に進むと、claude mcp add の話と配布統制の話を混ぜずに済みます。
先に結論: 最初に決めるのは 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> で設定確認もできます。
2026年6月以降の docs では、認証だけをシェルから進める claude mcp login <name> と、資格情報を外す claude mcp logout <name> も使えます。/mcp パネルを開ける環境なら UI から進めてもよいですが、SSH 越しや headless 環境では CLI の方が詰まりにくいです。
claude mcp login my-server
claude mcp get my-serverローカルブラウザが使えない環境では --no-browser で認証 URL を表示できます。
claude mcp login my-server --no-browserここで重要なのは、追加できたことと安全に運用できることは別だという点です。接続確認の次に見るべきは、次の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 から考えた方が後戻りが少ないです。
このとき見落としやすいのが、remote HTTP は「URL でつながるか」だけでは終わらないことです。MCP-Session-Id を返す stateful server なのか、404 が返ったら client 側で再初期化すべき設計なのか、session を DELETE で閉じるのかまで含めて transport を理解しておかないと、Claude Code 側の接続は通っても運用品質が不安定になります。ここは MCP Streamable HTTP 移行ガイド で整理している session lifecycle の話とセットで見るのが安全です。
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 で始める方が堅いです。
1.5 callback port を固定すべきか
MCP server 側で redirect URI を事前登録する運用なら、Claude Code 側の callback port も固定した方が安全です。docs でも、http://localhost:PORT/callback を事前登録する server では --callback-port を合わせる前提になっています。
claude mcp add --transport http \
--callback-port 8080 \
my-server https://mcp.example.com/mcpここをランダム port のまま進めると、「接続先は見えているのに認証だけ終わらない」状態を作りやすいです。固定 port が必要な server かどうかは、導入手順の最初に確認した方が手戻りが少ないです。
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 をセッションごと分ける運用が重要になります。
session 境界で追加確認したいこと
ここでいう session は OAuth session ではなく、Claude Code の作業 session と、HTTP transport 側の状態保持をどう混ぜないか の話です。最近の観測では mcp-session-id や mcp session id を調べる流入が少量ながら続いており、接続手順だけでなく「stateful server をどこまで同じ会話に置くか」を気にする読者が出ています。
実務では次の4点を確認すると事故が減ります。
- その server は stateless で十分か
docs 検索や read-only API 参照なら、接続を短く保てる stateless 寄りの設計で足りることが多いです。 MCP-Session-Idを返す stateful server か
長い stream や resume を持つ server なら、transport 側の session lifecycle を前提にした運用が必要です。- 同じ Claude Code session に write tool を同席させるか
stateful な外部 server と write tool を同席させるほど、review しづらい到達経路が増えます。 - session を壊したときの戻し方を持っているか
404 での再初期化や再 login の手順を、運用メモとして残しておく方が安全です。
MCP-Session-Id、404 再初期化、DELETE による終了まで含めた transport 実装判断は、Claude Code MCP の導入論より MCP Streamable HTTP 移行ガイド 側の守備範囲です。この記事では、stateful server を同じ作業 session に雑に混ぜない ことだけ押さえれば十分です。
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 分離で解消できないかを考えます。stateful な remote server なら、ここで MCP-Session-Id を含む transport 挙動を observer 的に確認し、write 系 task と混ぜない方針を先に決めます。
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 を増やすことではありません。claude mcp add の後に何を確認するか、stdio/remote をどう切るか、承認をどの session に残すか です。
私なら、まず read-only remote MCP を最小構成でつなぎ、claude mcp login か /mcp で認証を済ませ、/permissions で挙動を確認します。そのうえで stdio は固定コマンドだけ、write 系は別 session と人間レビュー前提、stateful な remote server は transport 境界を理解したうえで分離する。この順で進めると、Claude Code の MCP は「便利だけど危ない接続機能」ではなく、再現可能に導入できる作業面になります。