メインコンテンツへスキップ
Dev Tools 12分で読める

Claude Code MCP認証ガイド|claude mcp loginでSSH越しの認証を解決

この記事を書き始めた瞬間、手元のClaude Codeが「Notion」「Google Drive」「Gmail」「Google Calendar」のMCP接続について「認証が必要です。claude mcpまたは/mcpで認可してください」と告げてきた。今回はDiscord報告やGA4データ取得を自動実行するタスクの最中で、対話的にブラウザを開いてOAuth認証する余裕がない。よくある話だ。MCPサーバーが増えるほど、この手の「今すぐ認証して」という壁に当たる頻度も増える。

この記事はこんな人におすすめ
  • Claude CodeでMCPサーバーを複数運用しているエンジニア・PM
  • SSHでリモートサーバーに接続して開発している人
  • 「認証が必要です」の壁で作業が止まった経験がある人
  • CI/CDやDockerなど非対話環境でClaude Codeを動かしたい人

MCP認証がそもそも厄介な理由

MCPサーバーの多くはOAuthで認証する。ブラウザを開いて許可を出し、リダイレクトされたトークンをClaude Codeが受け取る、という一般的な流れだ。ローカルのMacで作業している分には問題ない。

問題はSSH越しに動かしたときだ。GitHubのIssue #1178では、Linear MCPをSSH経由のリモート開発環境で使おうとしたユーザーが、ブラウザにアクセスできず認証が完了しないと報告している。ローカルプロセスとして標準入出力でやり取りする「stdio接続」ではENOENTエラー(コマンドが見つからないエラー)が、HTTP経由でイベントを受け取る「SSE接続」では401 Unauthorizedエラーが出た。

ユーザーは「AWS認証のように、ローカルでブラウザ認証を試みつつSSH接続時は認可トークンを手動入力できるオプションが欲しい」と要望していた。このIssue自体は「計画外」としてクローズされているが、同じ課題は後述のアップデートで別の形で解消されていく。

同じ設定でCursorやClaude Desktopは問題なく動く。ローカルアプリケーションだからブラウザに直接アクセスできるからだ。ターミナル経由でリモートに接続するClaude Codeだけが割を食う格好だった。

claude mcp login / logout:シェルから直接認証する

Claude Code v2.1.186で追加されたのがclaude mcp login <サーバー名>だ。設定済みのMCPサーバーのOAuthフローを、セッション内で/mcpパネルを開かずにシェルから直接実行できる。

# サーバーを認証する
claude mcp login notion

# 認証情報を削除する
claude mcp logout notion

同じv2.1.186で、--no-browserフラグによるstdinリダイレクト方式のSSH対応も同時に追加された。地味な変更に見えるが、効果は大きい。セッションを一度も開かずに認証状態を整えられるので、スクリプトや自動化フローの中に組み込みやすくなった。

SSHでの使い勝手改善:v2.1.191のheadless自動検知

v2.1.186で導入されたSSH対応は、v2.1.191でさらに使いやすくなった。OAuthのdiscovery・トークン取得が一時的なネットワークエラー後に1回リトライされるようになったほか、ブラウザのないheadless環境(SSHセッションやディスプレイのないLinuxなど)を自動検知し、ブラウザを開こうとする代わりに認可URLをそのままテキストで表示するようになった。

手順はこうだ。表示されたURLを手元のマシンのブラウザで開いて認証する。その後、リダイレクト先URLをブラウザのアドレスバーからコピーし、ターミナルに貼り付ける。この貼り付け操作は対話型ターミナルでの入力が前提になるため、接続時はssh -t(疑似端末を強制的に割り当てるオプション)を使っておくと安全だ。

ssh -t user@remote-host
claude mcp login notion
# ブラウザのないheadless環境ではURLがテキスト表示される
# → 手元のマシンでURLを開いて認証 → リダイレクト先URLを貼り付け

起動時通知とセキュリティ強化:認証待ちを見える化

v2.1.193では、認証が必要なMCPサーバーがある場合に起動時通知が出るようになった。以前は/mcpを開かないとどのサーバーが未認証か分からなかったが、今は起動直後に把握できる。

v2.1.196ではセキュリティ面の改善が入った。リポジトリにコミットされた.claude/settings.jsonで自己承認された.mcp.jsonのサーバーであっても、claude mcp list/getが無条件にそのサーバーを起動しなくなり、信頼していないワークスペースでは「⏸ Pending approval(承認待ち)」と表示されるようになった。認証まわりの利便性だけでなく、勝手に外部サーバーが起動するリスクにも手が入っている。

影の部分:残る不具合とAPIキー認証の限界

改善は進んだが、完全ではない。GitHub Issue #44535では、claude mcp listではサーバーが「✓ Connected」と表示されているのに、UI上は「needs authentication」のままというバグが報告された。OAuthを必要としないローカルHTTPサーバーで発生し、ツールがセッションに読み込まれない状態になる。このIssueは重複としてクローズされているが、CLIとUIで認証状態の表示がズレる問題自体は根深い。

もう一つ、勘違いしやすいポイントがある。Claude Code自体の認証はANTHROPIC_API_KEY環境変数を設定することでOAuthからAPIキー方式に切り替えられるが、これはあくまでClaude CodeとAnthropic API間の話だ。Notion・GitHub・Linearといった個別のMCPサーバーへのOAuth認証は別物で、ANTHROPIC_API_KEYを設定してもスキップされない。個別サーバー側の認証を省略したいなら、そのMCPサーバー自体がAPIキーやパーソナルアクセストークンでの認証方式に対応しているかを確認し、.mcp.json側の設定でそちらを使う必要がある。

MCP認証まわりの現時点での評価

強み: claude mcp loginでシェルから直接認証、SSH環境の自動検知とURL表示、起動時通知で「どのサーバーが未認証か」が見える化された

弱み: CLIとUI間で認証状態表示がズレる不具合が報告されている、ANTHROPIC_API_KEYは個別MCPサーバーのOAuth認証を代替しない

結論: 個人利用・SSHリモート開発ならclaude mcp login+--no-browserの組み合わせで大半の壁は越えられる。非対話環境で動かすサーバーは、そのサーバー自体がAPIキー/PAT方式に対応しているか事前に確認しておくと詰まりにくい

PMとしての実感:MCPサーバーが増えるほど認証は「地味な律速要因」になる

このサイトの運用でも、Google Analytics、Search Console、Notion、GitHub、Supabaseと複数のMCPサーバーを常時接続している。冒頭で書いた通り、自動化タスクの最中にNotionやGoogle系サービスの認証切れに当たることは珍しくない。認証そのものは数十秒で終わる作業だが、非対話環境で走らせているタスクの途中で止まると地味に痛い。

自分の判断としては、対話的に使うサーバーはOAuthのまま、バッチ処理や自動化に組み込む頻度が高いサーバーは、そのサーバー自体がAPIキー/PAT方式に対応しているかを先に確認し、対応していればそちらに寄せる方針にしている。全部をOAuthで統一した方が管理はシンプルだが、非対話環境で動かす頻度が高いタスクほど、認証切れによる作業停止のリスクが上回る。

MCPの基本概念とセットアップ手順はMCP実践入門ガイドで解説している。エンタープライズ向けのSSO統合についてはClaude MCPエンタープライズ管理認証も参照してほしい。

詳しく見る

関連記事


免責事項: 本記事の情報は2026年7月2日時点の公開情報に基づく。Claude Codeのバージョン番号・コマンド仕様・挙動は今後のアップデートで変更される可能性がある。導入前に公式ドキュメントの最新情報を確認してほしい。

Share