Claude CodeにおけるMCP認証 2026年版ガイド

MCPとは？

MCP（Model Context Protocol）は、Anthropicによって開発されたオープンスタンダードであり、 Claude Code が外部システムと構造化された方法で通信することを可能にします。
ツールロジックをプロンプトに詰め込む代わりに、MCPは明確なミドルウェア層を作成します。Claudeは標準形式でツールを呼び出します。MCPサーバーはリクエストを受信し、データベース、内部API、クラウドサービス、チケット管理システムなど、その背後にある実際のシステムに転送します。

あなたは MCPサーバー をアダプター層と考えることができます。片側はClaude Code、もう片側はあなたの物理インフラストラクチャです。統合が発生するたびにすべてをゼロから書き直す必要なく、両者が互いを理解するのに役立ちます。

MCPがなければ、Claude Codeはテキストにしか応答しませんでした。MCPがあれば、実際のシステムと対話し始めます。そしてその時点から、それはもはや単なる「遊びで答えるAI」ではありません。

MCP認証が重要である理由

MCPが普及するにつれて、多くの人がClaude Codeを使って内部システムに直接接続しているのを目にします。APIテストを呼び出すだけの人もいれば、厳格なIAMを持つAWS上で実行されているサービスに直接接続する人もいます。

問題は、Claudeがツールを呼び出せるようになるとすぐに、それがあなたのシステム内で何らかのアイデンティティを表すということです。

認証設定が緩い場合、リスクはすぐには現れません。それは潜在的で厄介なものです。CloudFrontの設定をデバッグした時のように、一見無害な転送ヘッダールールに過ぎなかったとしても、500エラーもダウンタイムもありませんでした。しかし実際には、アクセス境界は予想以上に拡大されていました。問題を見つけるには、ログを注意深く調べる必要があります。

MCPにも同じことが言えます。誤った認証方法を選択すると、意図せずして以下の事態を招く可能性があります。

• 長期的なAPIキーを漏洩させる
• 複数の異なるユーザーにアクセスキーを配布する
• Claudeに必要以上の権限を付与する。

AWS上の製造データベースや金融システムに接続することは、もはや些細な問題ではなくなります

そのため、適切な認証方法を選択することは、「接続を機能させる」ことだけではありません。それは、その背後にあるシステム全体のセキュリティと一貫性を左右する可能性があります。

なぜ認証が最初に検討すべきことなのでしょうか？

これらの外部ツールは「無害」とは程遠いものです。ソースコード、顧客記録、本番データ、内部チケットなどが含まれる可能性があります。しかし、ClaudeがMCP経由で接続する場合、単に娯楽のために読み込んでいるわけではありません。それは、システム内部の奥深くで検証済みのIDとして機能しています。認証が脆弱であれば、攻撃を受ける可能性があります。複雑な攻撃は必要ありません。APIキーが1つ漏洩するだけで、事態はあっという間に悪化します。

私が遭遇した状況も同様でした。そのサービスは、開発環境と本番環境の両方で単一のトークンしか提供しません。リポジトリのテスト中にそのトークン情報が漏洩しなければ、すべて問題ありませんでした。そのため、問題が発覚した際にすぐに発生するのを避けるため、本番環境と開発環境の両方でログイン認証情報を変更する必要があります。つまり、システム自体が問題なのではなく、権限の管理方法に重要な問題があります。認可は単なる追加機能ではありません。Claudeが許可された範囲内で何ができるかを決定し、セキュリティリスクを防ぎます。

この記事は何を扱っていますか？

Claude Codeは、いくつかの異なる認証方法をサポートしています。例えば：

• APIキー
• ベアラートークン
• OAuth
• AWS認証情報（アクセスキーまたはロールの引き受け）

一見すると混乱しやすいかもしれません。それぞれの方法には、それぞれの存在理由があります。「すべてのケースに最適な方法」というものはありません。

間違った方法を選択すると、次のような結果につながる可能性があります：

• 認証情報の漏洩
• 途中で再設定が必要になる
• チームがワークフローの修正に時間を浪費する

以前、AWS上のAPI Gatewayの背後で動作するMCPサーバーを設定しました。

当初、アクセスを迅速化するために長期的なアクセスキーを使用していました。しかし、複数のテスターとキーを共有して簡単にアクセスできるようにすることと比較すると、これは理想的ではないと気づきました。最終的には、権限をより明確に定義するために、ロールベースの引き受けに切り替えました。

この記事では、各ポイントを掘り下げて説明し、それぞれの異なる方法をいつ使用すべきかを解説します。目標は、最初から正しい選択ができるよう支援し、将来的な修正を避けることです。

Claude Codeのインストール

まだClaude Codeをインストールしていない場合は、すぐにセットアップできます。

macOS、Linux、WSL：

curl -fsSL https://claude.ai/install.sh | bash

Windows PowerShell：

irm https://claude.ai/install.ps1 | iex

macOS限定

brew install --cask claude-code

次に、認証セキュリティに関するセクションに進みましょう。

CLI環境におけるセキュリティの定義

ローカルマシンでCLIを実行する際、多くの人はHTTPSのことばかり考えがちです。しかし、実際には、より大きな問題は資格情報をどのように管理するかという点にあります。

HTTPSはデータ転送中の保護に過ぎません。トークンがマシン上で露出してしまえば、意味がありません。CLI環境における主な問題点は以下の通りです。

• キーはどこに保管しますか？
• トークンの有効期間はどのくらいですか？
• 誰が利用できますか？

低セキュリティ とは、長期的なAPIキーを平文の構成ファイルに残しておくことです。もしそのファイルが誤ってリポジトリにコミットされてしまえば、もう手遅れです。そのキーは実質的に制御不能になります。そして、長期キーであるため、手動でローテーションする必要があります。

以前、ECSの環境問題をデバッグしている際に、同様の状況に遭遇しました。Amazon ECS MCPサーバーをアクセスキーとシークレットキーで使用していました。その後、それらの資格情報のことを忘れていました。数日後、別の環境でいくつかの問題を調査するようClaudeに依頼しましたが、古い資格情報がまだ使用されていたため、結果的に本番環境で多くの操作を実行してしまいました。

高セキュリティ は異なります。短期的なトークンを使用します。あるいは、環境変数経由で参照したり、IAMロールのようなサービスレベルの認証メカニズムを使用したりします。例えば、AWS SSOを使用する場合、トークンには明確な有効期限があります。期限切れ後は、再度ログインする必要があります。もしマシンが侵害された場合でも、攻撃者が何かを行うための時間は非常に短くなります。この方法は完璧ではありませんが、何か問題が発生した場合の被害を最小限に抑えます。

以下に、Claude CodeにおけるMCPサーバーの一般的な認証設定方法を4つ紹介します。それぞれの方法は異なる状況に適しています。

1. 静的HTTPヘッダー（APIキーとベアラートークン）

これは最も簡単に始められる方法です。この方法は、長期的なAPIキーやプライベートアクセストークン（PAT）を使用する多くのサードパーティサービスでうまく機能します。

コマンドライン設定

認証ヘッダー付きでMCPサーバーを素早く追加したい場合は、「claude mcp add」と渡します 「--ヘッダー」

# Add a weather service MCP server with Bearer Token authentication
claude mcp add weather-service \
    --transport http \
    --header "Authorization: Bearer secret-token-123" \
    https://api.weather-data.com/mcp

処理が完了すると、Claudeが自動的に設定を書き込みます。手動での作業は不要です。「Claude/settings.json」。この方法は、外部サービスを素早く確認するのに非常に便利です。

システムに正式に統合する前にAPIをテストする必要がある場合によく利用します。ただし、一つだけ覚えておいてください。実際のトークンをコマンドに貼り付けて、シェル履歴をどこかにコミットしないようにしてください。これは思っているよりも頻繁に起こります。

設定ファイル (.claude/settings.json)

トークンコードをファイルに平文で記述したくない場合は、環境変数を使用できます。

Claudeは「${ENV_VAR}」を読み込み、CLI起動時に実際の値に置き換えます。

例：

{
  "mcpServers": {
    "data-tool": {
      "url": "https://api.myservice.com/mcp",
      "type": "http",
      "headers": {
        "Authorization": "Bearer ${APP_API_TOKEN}",
        "X-Org-Id": "org-888"
      }
    }
  }
}

この方法は、トークンをファイルに直接書き込むよりも安全です。Claudeを実行する前に環境変数をエクスポートするだけです。

以前、社内リポジトリで誤ってトークンが設定ファイルにコミットされているのを見たことがあります。最初はプライベートリポジトリだから問題ないと思っていました。その後、テストのために別のチームとリポジトリが共有されました。その中には本番環境のトークンも含まれていました。環境変数を使用しても、すべてのリスクが解決されるわけではありません。しかし、少なくとも誤ってコミットしてしまった場合のキー漏洩のリスクは軽減されます。

利点：

• 設定が簡単です。
• 外部サービスとの迅速な連携に適しています。

欠点：

• トークンは依然として有効期限が長いタイプです。
• 漏洩した場合は、手動でローテーションする必要があります。

2.1 AWS MCP認証情報

2.1 アクセスキーとシークレットキー (AWSホスト型MCPサーバー向け)

MCPサーバーがAWS上にある場合、こちらの方がはるかに実用的です。お使いのマシン上の既存のAWSログイン認証情報を使用できます。通常、これはAWS configureまたはAWS SSOを介して設定されます。Claudeは次のような変数を継承します。

• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY
• AWS_SESSION_TOKEN
• AWS_PROFILE

これは、MCPサーバーがAPI Gatewayの背後で実行されている場合に非常に有効です。あるいは、バックエンドがLambdaまたはECS上にあり、IAM認証が有効になっている場合にも同様です。 

例えば、Signature V4を使用してリクエストに署名するようにMCPプロキシを設定する場合などです。

{
  "mcpServers": {
    "cloud-logger": {
      "command": "node",
      "args": ["/path/to/aws-mcp-proxy.js"],
      "env": {
        "AWS_PROFILE": "my-dev-profile",
        "AWS_REGION": "ap-southeast-1",
        "MCP_ENDPOINT": "https://my-mcp-service.execute-api.ap-southeast-1.amazonaws.com/prod"
      }
    }
  }
}

あるいは、もっと簡単に、Claudeを実行する前に環境変数をエクスポートします。

# Claude Codeを実行する前にAWS認証情報を設定

export AWS_PROFILE=my-dev-profile
export AWS_REGION=ap-southeast-1

# Claude Codeを開始 — MCPサーバーはこれらの認証情報を使用します claude

Claudeはキーの詳細を知る必要はありません。ログインしているAWSコンテキストのみを使用します。

API Gatewayの背後で実行されている社内MCPサーバーをデバッグしていた時のことを覚えています。リクエストは常に403エラーを返していました。当時、私はポリシーの問題だと思っていましたが、その後、自分のマシン上のAWS SSO証明書が期限切れになっていることを発見しました。単に「aws sso login」コマンドを再度実行するだけで、すべてが解決しました。それ以来、私はIAMを責めるのではなく、登録されたサービスは作業を開始する前にセッションを確認する必要がある、と常に心に留めています。

利点：

• トークンは通常、STS経由で短期間です。
• 自動的にローテーションできます。
• 長期的なAPIキーよりもセキュリティが高い。

欠点：

• AWSのログイン状態に依存します。
• セッションが終了すると、すべてが即座に停止します。

2.2. IAMロールの引き受け（最小権限アクセス）

AWSの認証情報を直接使用する場合、Claudeはあなたの個人IDとして動作します。これは便利ですが、常に正しい方法とは限りません。ロールを引き受けることで、MCPは別のIDを使用できます。このIDは特定のマシンまたはサービス専用です。これは本番環境をシミュレートしたい場合に非常に役立ちます。

例えば、読み取り専用アクセスでサービスがどのように機能するかをテストする場合。あるいは、MCPサーバーが固定のIAMロールのみを受け入れ、個々のユーザーが直接呼び出すことを許可しない場合などです。

私はこのようなケースに遭遇しました。ある内部APIは、バックエンドロールからのアクセスのみを許可していました。個々のユーザーはブロックされました。ローカルでテストするには、その特定のロールを引き受ける必要がありました。

ワークフローは非常に明確です。

1. IAMロールの引き受けをリクエストします。
2. AWS STSは、あなたがsts:AssumeRoleを使用する権限を持っているかを確認します。有効な場合、STSは一時的な認証情報を返します。
3. その MCPプロキシ はその一時的な認証情報を使用してターゲットサービスを呼び出します。サービスはあなたの個々のユーザーではなく、ロールのみを認識します。

この方法で私が気に入っているのは、権限が非常に明確であることです。ロールには独自のポリシーがあります。何らかの制限を課したい場合は、そのポリシーで調整できます。欠点は、初期設定に少し時間がかかることです。信頼ポリシーが一行でも間違っていると、引き受けは機能しません。そして、IAMのデバッグは決して楽しい作業ではありません。

設定例

{
  "mcpServers": {
    "finance-bot": {
      "command": "node",
      "args": ["/path/to/aws-role-mcp-proxy.js"],
      "env": {
        "ASSUME_ROLE_ARN": "arn:aws:iam::123456789012:role/mcp-finance-bot-role",
        "AWS_REGION": "ap-southeast-1",
        "MCP_ENDPOINT": "https://secure-finance.execute-api.ap-southeast-1.amazonaws.com/prod"
      }
    }
  }
}

ロールを引き受けるためのIAM権限の設定

ロールを引き受けるには、現在のユーザーがその権限を持っている必要があります。正しい信頼ポリシーがなければ、すべてが即座に停止します。

通常、簡潔にするためにいくつかの変数を定義します。

変数を定義する

export ACCOUNT_ID="123456789012"
export ROLE_NAME="mcp-finance-bot-role"
export MY_USER_ARN="arn:aws:iam::${ACCOUNT_ID}:user/developer@company.com"

ロールの信頼ポリシーを更新し、ユーザーがそのロールを引き受けられるようにする

aws iam update-assume-role-policy \
    --role-name "${ROLE_NAME}" \
    --policy-document '{
      "Version": "2012-10-17",
      "Statement": [{
        "Effect": "Allow",
        "Principal": {"AWS": "'"${MY_USER_ARN}"'"},
        "Action": "sts:AssumeRole"
      }]
    }

このセクションは基本的に一つのことだけを行います。それは、あなたのユーザーがそのロールを引き受けることを許可されているとAWSに伝えることです。

私はかつて、信頼ポリシーに正しいARNが欠けていたというだけの理由で、ほぼ午後いっぱいを無駄にしました。ロールにアタッチされたポリシーは正しかったのですが、信頼ポリシーがユーザーの引き受けを許可していなかったのです。その結果、STSはAccessDeniedエラーを返し続けました。もう一つ覚えておくべき点があります。

IAMにはわずかな遅延があります。ポリシーを更新した後、効果が反映されるまで1、2分待つ必要があるかもしれません。すぐにテストしてもうまくいかない場合でも、慌てないでください。

利点：

• 最小権限の原則を維持します。
• ロールができることはすべて、そのポリシーの範囲内です。

欠点：

• 設定が少し複雑です。
• ほんの小さな間違い一つで機能しなくなります。

3. 組み込みのOAuth 2.0サポート

GitHub、Linear、Slackのような複雑なサードパーティサービスでは、APIキーだけでは不十分です。それらは標準的なユーザーフローを介したログインを必要とします。Claude Codeは、これらの種類のMCPサーバー向けに組み込みのOAuthサポートを提供します。

シェルコマンド

独自のログインフローを記述する必要はありません。開始する前に、どのサーバーが認証を必要とするかを確認できます。

# List the MCP servers that need authentication
claude mcp list

ログインしていないサーバーが見つかった場合は、次を実行してください。

# Start the login flow for a GitLab MCP server (opens browser)
claude mcp auth gitlab-server

対話型コマンド

便利な機能があります。Claudeを使用中に権限エラーが発生した場合、終了する必要はありません。チャットセッション内で直接認証できます。 

例： 

>>> あなた：私のToDoをリストアップして。

>>> Claude：Linearへのアクセスが必要です。

>>> /mcp auth linear-server

そのコマンドを入力するだけです。Claudeがログインフローを再開します。通常、権限確認のためにブラウザが開きます。

以前、問題をレビュー中にLinearトークンの有効期限が切れ、途中でClaudeが権限不足を報告したことがありました。

 CLIを再起動する代わりに、私はただ「/mcp auth」と実行するだけで済みました。その後すぐに作業に戻りました。

利点：

• 標準的なOAuthフロー。
• トークンは自動的に更新されます。
• ユーザーと連携する際に、かなりスムーズな体験が得られます。

欠点：

• 時折、ブラウザを開いて再度ログインする必要があります。特に、コンピューターを切り替える際や、ログインセッションが終了した場合などです。

まとめ

どの認証方法を選択するかは、次の2つの要素に依存します。

• 資格情報をどこに保存するか。
• そして、どのような問題を解決しようとしているか。

「あらゆる状況で最善」という選択肢はありません。文脈に合ったものだけです。小さな、しかし重要な注意点：まず、Node.js環境が安定していることを確認してください。最終的に、ローカルマシンが間違ったNodeバージョンを使用していることが判明しました。それを「nvm use"は正常に動作するはずです。nvmを使用することで、環境の不一致による多くの説明不能なエラーを回避できます。これは非常に重要です。 

クイックガイド：Claude CodeでのMCPサーバーの追加

認証ヘッダー付きHTTPトランスポート

# 認証ヘッダー付きHTTPトランスポート

claude mcp add my-server \
    --transport http \
    --header "Authorization: Bearer ${MY_TOKEN}" \
    https://my-mcp-server.com/mcp

# Stdioトランスポート (ローカルプロセス)

claude mcp add my-local-server \
    -- node /path/to/server.js

# 設定済みMCPサーバーの一覧表示

claude mcp list

# MCPサーバーの削除

claude mcp remove my-server

これらのコマンドを覚えておけば、すぐに始められます。残りは、状況に応じて適切な認証方法を選択することです。

よくある質問

Claude Code MCP OAuthトークンを生成する方法は？

Claude Code MCP OAuthトークンを生成するには、通常、短期的なアクセストークンを発行するOAuthプロバイダーと連携します。この非常に安全な方法は、Claude Code MCP接続における長期的な認証情報の直接的な漏洩を防ぐのに役立ちます。具体的な手順は、選択したOAuthプロバイダーの設定とClaude Codeとの連携によって異なります。

Claude CodeはMCPサーバーにアクセスできますか？

はい、Claude CodeはMCPサーバーにアクセスでき、データベースやAPIなどの外部システムとの連携を可能にします。この機能により、Claude Codeは単なるテキスト応答者から、アクティブなシステム参加者へと変貌します。効果的なClaude Code MCP認証は、安全な運用、不正アクセス防止、および米国のインフラ全体でのデータ整合性確保のために不可欠です。

Claude CodeでFigma MCPを認証する方法は？

Claude CodeでFigma MCPを認証するには、安全なClaude MCP認証方法を選択する必要があります。これは通常、Figmaの連携状況とセキュリティポリシーに応じて、APIキー、OAuth、またはベアラートークンを使用することを意味します。安全なシステム連携を確保するため、最小限の権限付与と長期キーの使用回避に重点を置いてください。