Claude Code MCP ガイド — claude mcp add・login・stdio command / remote HTTP の選び方

Claude Code で MCP を使いたいが、何をどうつなげばよいのか分からない。検索では claude code mcp server、claude code add remote mcp server、stdio claude、claude code mcp add stdio command、claude code mcp stdio、claude mcp add stdio、claude mcp add --transport stdio のように調べる人もいますが、実際に止まりやすいのは同じ地点です。claude mcp add で server を増やすところまではできても、「最初の1本を stdio にしてよいのか」「claude mcp login はいつ使うのか」「read-only のつもりなのに write tool と同席していないか」で止まりやすいからです。

この記事は、Claude Code で MCP を実務導入する人向けの手順書です。特に「claude code mcp server や claude mcp stdio、stdio claude、claude code mcp add stdio command 周辺で検索しているが、本当に local command で始めてよいのか」「official docs を読んだあと何を確認すべきか」「claude mcp login はどこで使うのか」と迷っている人を想定しています。組織配布そのものの設計は Claude Code managed settings 設計ガイドに、認証・監査・配布統制の全体論は MCP エンタープライズ運用ガイドに分けています。transport と session lifecycle を先に整理したい場合は MCP Streamable HTTP 移行ガイドと MCP Session 管理ガイドを、remote MCP の prompt injection と承認境界を先に固めたい場合は MCP prompt injection 対策ガイドを、Claude Code 全体の導入順を先に押さえたい場合は Claude Code の使い方実践ガイドを併読すると、接続面と安全面を分けて理解しやすいです。今回はそれより一段手前の、「Claude Code から MCP server をどう追加し、claude mcp login をどこで使い、最初の10分で何を確認し、どこで session を分けるか」に絞ります。社内ルールを先に作りたい場合は AIコーディングツールの社内ガイドラインを先に読んでください。

読む順番の目安としては、まず本記事で claude mcp add と stdio command / remote HTTP の分け方を押さえ、その次に MCP Session 管理ガイドで MCP-Session-Id と 404 再初期化の扱いを整理し、必要なら MCP Streamable HTTP 移行ガイドで transport 全体へ広げ、approval reviewer や app tool 承認の話まで混ざり始めたら Codex auto review ガイドで reviewer lane を切り出し、最後に Claude Code managed settings 設計ガイドと MCP エンタープライズ運用ガイドで team 配布と OAuth・監査・SSO を含む全社運用へ広げると、個人導入と中央統制を混同しにくくなります。

検索意図ごとに入口を 3 本へ切るなら、まず次を見れば十分です。

claude mcp add --transport stdio、claude code mcp stdio、stdio claude の導入判断なら本記事
mcp-session-id、404 再初期化、stateful remote server の lifecycle まで詰めるなら MCP Session 管理ガイド
Codex 側の approval reviewer や approvals_reviewer = "auto_review" も同時に整理したいなら Codex auto review ガイド

特に claude mcp add --transport stdio や claude code mcp stdio で来た人は、まず本記事で local command と remote HTTP の分け方だけ決めてください。接続自体は通ったのに MCP-Session-Id や 404 再初期化で止まったときだけ、すぐに MCP Session 管理ガイドへ進むのが最短です。

`claude code mcp stdio` / `claude mcp stdio` / `stdio claude` で探している人向けの結論

結論だけ先に言うと、claude code mcp stdio、claude mcp stdio、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 の話と配布統制の話を混ぜずに済みます。

最初の10分で決める判断表

導入初日に毎回迷う論点は、実はかなり限られます。私なら最初の 10 分で次の表だけ埋めます。

迷う点	先に出す答え	理由
まず 1 本目を何にするか	read-only の docs / repo metadata 系	価値が出やすく、write を開けずに済む
stdio か remote HTTP か	個人補助なら stdio、共有接続なら remote HTTP	配布・監査・停止点の作りやすさが違う
`claude mcp login` を使うか	UI を開けないなら使う。callback port は登録時に固定してから login する	SSH / headless と OAuth redirect URI の切り分けを分けられる
write tool を同席させるか	最初は分ける	prompt injection と review 負荷を下げられる
team 配布まで考えるか	使い続ける前提なら最初から考える	後で `managed settings` へ移す方が重い

この表を埋めずに claude mcp add や claude mcp add --transport stdio だけ進めると、「つながったが運用できない」状態に入りやすいです。

先に結論: 最初に決めるのは 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/mcp

JSON 設定があるなら 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 で統制するのか

`claude mcp add` の直後、最初の10分で確認すること

接続テストが通ったあとに確認漏れしやすいのは、機能より運用です。私は最初の10分で次の5点だけを見ます。

認証が UI 依存か CLI 依存か デスクトップを開けるなら /mcp でもよいですが、SSH 越しや headless 環境では claude mcp login を前提にした方が詰まりにくいです。
その server は read-only で足りるか いきなり write scope を取りにいかず、まず検索・参照だけで仕事になるかを確認します。
local command か共有 URL か 個人端末専用の補助か、team へ配る接続かで、その後に読むべき記事が変わります。
stateful remote server か MCP-Session-Id を返すなら、接続成功だけで終わらせず MCP Session 管理ガイドの 404 再初期化と DELETE 終了まで読んでおく方が安全です。
未信頼入力と write tool を同席させていないか issue、chat、web、logs のような外部入力を読む server は、同じ作業 session に write tool を置かない方が事故が減ります。

この 5 点を飛ばして「つながったから次へ進む」とやると、後で managed settings、review、transport の責務が混ざります。

`claude mcp login` を先に使う場面

claude mcp login は「UI がなくても認証できる便利コマンド」以上の意味があります。私は次の条件なら、/mcp より先に CLI login を使います。

SSH 越しや remote devbox で作業している
claude mcp add / add-json で callback port を固定した後、その OAuth flow を CLI で再現したい
認証手順を runbook に残したい
team 配布前に headless 環境でも再現するか確かめたい

逆に、ローカル GUI で一度だけ試す個人検証なら /mcp から始めても構いません。ただし、そのまま本番運用へ持ち込まず、再ログイン手順だけは claude mcp login / logout で確認しておく方が安全です。

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 の話とセットで見るのが安全です。

迷ったときの4パターン

抽象論のままだと決めにくいので、私は次の 4 パターンで切ります。

状況	まず選ぶもの	理由
個人端末で docs 検索や軽い補助だけしたい	stdio	ローカル command だけで閉じ、OAuth や共有認証を増やさずに済む
GitHub / Slack / 社内 API を team に配りたい	remote HTTP	URL、OAuth、scope、停止点を中央で揃えやすい
認証は必要だが write をまだ開けたくない	read-only remote HTTP	callback port と scope だけ先に揃え、操作権限は後回しにできる
長い stream や stateful session を持つ remote server を使いたい	remote HTTP + 別 session	接続面と write tool を分け、404 再初期化の責務も切り分けやすい

この表で決められないなら、選ぶ server が問題なのではなく、用途の主語が広すぎる可能性があります。まず read-only で始めるか、そもそも team 配布の話なのかを先に切った方が速いです。

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/mcp

JSON でも同じことができます。

{
  "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 をセッションごと分ける運用が重要になります。

remote MCP server を同じ作業 session に混ぜてよいか

ここでいう session は OAuth session ではなく、Claude Code の作業 session と、HTTP transport 側の状態保持をどう混ぜないか の話です。最近の観測では mcp-session-id や mcp session id を調べる流入が少量ながら続いており、接続手順だけでなく「stateful remote MCP 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 移行ガイドと MCP Session 管理ガイド側の守備範囲です。この記事では、stateful server を同じ作業 session に雑に混ぜない ことだけ押さえれば十分です。reviewer lane や approval request の自動化まで論点が伸びるなら、接続面の次に Codex auto review ガイドを読むと境界がぶれません。

個人導入から team 配布へ広げるときの境界

ここから先は claude mcp add の話というより、追加した server をどう広げるかの話です。個人検証の時点で便利だった設定を、そのまま team 配布へ持ち込まない方が安全です。

個人導入の主語: この command / URL が自分の作業で役立つか
team 配布の主語: 誰に配るか、何を固定するか、どこで止めるか

この境界を越えたら、詳細は Claude Code managed settings 設計ガイドと MCP エンタープライズ運用ガイドに寄せた方が責務がぶれません。ただし allowedMcpServers と deniedMcpServers の見方だけは、Claude Code MCP の導入記事でも押さえておく価値があります。

allowlist / denylist は名前だけで終わらせない

Claude Code docs では、allowedMcpServers と deniedMcpServers は次の3種類で制限できます。

serverName
serverCommand
serverUrl

ここで雑に 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 資格情報分離を決めないと危険です。

実務メモ: 導入初日にやらないこと

導入初日にやらない方がいいことも明確です。

docs 検索 server と GitHub write server を同じ session で試す
npx の stdio server をそのまま team に配る
callback port が曖昧なまま OAuth 付き remote server を増やす
MCP-Session-Id を返す stateful server を、session cleanup 手順なしで常用する
/mcp で一度つながっただけで「運用できる」と判断する

Claude Code MCP は接続できた瞬間より、2 回目に同じ手順を再現できるか、review しやすい分け方になっているかの方が重要です。実運用へ広げる前に、導入初日でこの5つを避けるだけでも事故率はかなり下がります。

導入チェックリスト

最後に、私ならこの順で確認します。

claude mcp add か add-json で再現可能な登録手順になっている
UI がなくても claude mcp login / logout で認証をやり直せる
stdio なら固定 command、remote なら固定 URL と scope を説明できる
read-only と write 系を同じ作業 session に雑に混ぜていない
stateful remote server なら MCP-Session-Id、404 再初期化、DELETE 終了の読む先が運用メモに入っている
個人導入で止めるのか、managed settings へ広げるのかを決めている

よくある詰まりどころ

「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 は「便利だけど危ない接続機能」ではなく、再現可能に導入できる作業面になります。