Claude Codeのチーム認証の設定手順と認証情報の優先順位
Claude Codeのチーム認証はTeams/Enterprise・Claude Console・クラウドプロバイダー経由の3系統に分かれます。招待手順とAPIキーなしのサインイン、認証情報の保存先までを管理者向けにまとめました。
Claude Codeをチームに配るとき、開発者が個々にログイン方式を選ぶ運用と、管理者が最初に経路を決めて配布する運用は別物です。設定できる経路は大きく3系統あります。Claude for Teams / Enterprise、Claude Console、クラウドプロバイダー経由で、それぞれ招待の手順とサインイン後に残る認証情報の形が違います。選んだ経路によっては使えなくなる機能もあるので、先にそこから確認します。
いま端末でどの認証が使われているかを知りたいときは、Claude Code内で/statusを実行します。ログイン方式、組織、メールアドレスが表示されます。認証情報が複数あるときの選ばれ方は「認証情報が複数あるとき、どれが使われるか」の節に書きました。
Claude Codeのチーム認証、3系統の選び方
チームで使う認証の土台は、契約形態によって決まります。claude.aiベースの月額課金で使うか、API従量課金で使うかがまず分かれます。もう1つは、Amazon Bedrock・Google CloudのAgent Platform・Microsoft Foundryのようなクラウド契約に相乗りする選択肢です。
| 系統 | 向くケース | 課金 | 開発者が最初にすること |
|---|---|---|---|
| Claude for Teams / Enterprise | 向くケースほとんどのチーム。Claude on the webも同じ枠で使いたい場合 | 課金シート単位の月額 | 開発者が最初にすることclaude.aiアカウントでログイン |
| Claude Console | 向くケースAPI従量課金で請求したい・既存のConsole基盤がある場合 | 課金従量課金 | 開発者が最初にすることConsole招待を承認してログイン |
| クラウドプロバイダー経由 | 向くケースすでにBedrock/Vertex/Foundryの契約と権限管理がある場合 | 課金クラウド側の契約 | 開発者が最初にすることクラウドのCLI認証を通す |
経路の選択は課金だけの話ではありません。Claude Codeのクラウドセッション・Routines・Code Review・Remote Control・Chrome拡張は、claude.aiアカウントが前提の機能です。ConsoleのAPIキーやクラウドプロバイダーの認証情報だけでは使えません。BedrockやFoundryで展開する場合は、claude.aiアカウントを持つシートも別に用意するかを先に決めておく必要があります。
この3つとは別に、自前のIdPでサインインさせて推論だけAnthropicや各クラウドへ流すClaude apps gatewayという選択肢もあります。社内IDプロバイダーを認証の唯一の入口にしたい組織向けの経路で、セルフホストが前提です。
Claude for TeamsまたはEnterpriseでチーム認証を設定する
Claude for TeamsとEnterpriseは、Claude on the webとClaude Codeを同じ請求・管理画面の下にまとめる経路です。
招待から初回ログインまで
- 1
プランを契約する
Claude for Teams(小規模チーム向けのセルフサービスプラン)か、Claude for Enterprise(要問い合わせ)を契約します。
- 2
メンバーを招待する
管理者ダッシュボードから招待します。シートにClaude Codeアクセスが含まれていないと、本人の端末に
You haven't been added to your organization yetと出ます。 - 3
メンバーがログインする
Claude Codeをインストールし、招待を受けたclaude.aiアカウントでログインします。
SSOはTeamsの時点で含まれ、Enterpriseにはドメインキャプチャ・ロールベースの権限・コンプライアンスAPIが加わります。組織全体のClaude Code設定をサーバー側から配るserver-managed settingsはTeamsでも使えます。SSOやSCIM、シート割り当ては、Claude Codeの設定ではなくclaude.aiのアカウント側で行います。プラン間の料金・最低人数の違いはClaude Enterpriseとはにまとめています。
Claude Consoleでチーム認証を設定する
API従量課金での請求を選ぶ組織は、Claude Console(platform.claude.com)側でユーザーを管理します。
Console組織を立ち上げる流れ
- 1
Consoleアカウントを用意する
既存のConsoleアカウントを使うか、新規に作ります。
- 2
ユーザーを追加する
Settings → Members → Inviteから一括招待するか、SSOを設定して招待を省略します。
- 3
ロールを割り当てる
招待時に選べるのは2種類です。Claude CodeロールはClaude Code用のAPIキーしか作れず、Developerロールは任意の種類のAPIキーを作れます。
- 4
メンバーがセットアップする
招待を承認し、システム要件を確認し、Claude Codeをインストールして、Consoleアカウントでログインします。
ログインの入口は/loginのほかに、claude auth loginでも開けます。v2.1.287の--helpは次のとおりです。
claude auth login --helpUsage: claude auth login [options]
Sign in to your Anthropic account
Options:
--claudeai Use Claude subscription (default)
--console Use Anthropic Console (API usage billing) instead of Claude
subscription
--email <email> Pre-populate email address on the login page
-h, --help Display help for command
--sso Force SSO login flow既定は--claudeaiで、Consoleに入りたいときは--consoleを付けます。--ssoはSSOログインの強制、--emailはログイン画面のメールアドレス欄の事前入力です。同じauth配下にはlogoutとstatusがあり、statusは--json(既定)と--textで出力形式を選べます。
APIキーなしでサインインする — キーレスConsoleサインイン
v2.1.242以降は、開発者がAPIキーを作れない権限設定でも、Console組織のメンバーとしてサインインできます。/loginプロンプトでAnthropic Consoleアカウントを選ぶと、Claude Codeはサインイン方法を尋ねてきます。どちらもブラウザーでConsoleにサインインする点は同じで、その後に保存するものが違います。
Consoleサインインの2つの経路
Consoleアカウントでサインイン
OAuthトークンをAnthropicプロファイルとして保存し、APIキーは作成しません。プロファイルのログインはClaude Codeが自動更新します。
APIキーを作成
Console APIキーを発行し、他の認証情報と同じ場所に保存します。静的な資格情報として扱われます。
更新に失敗するとリクエストが止まり、Anthropicプロファイルのログイン期限切れエラーが出ます。この選択肢はすべてのマシンで出るわけではなく、次のいずれかに該当するセッションでは、確認なしにAPIキーが自動作成されます。
- Amazon Bedrock・Google CloudのAgent Platform・Microsoft Foundry・Claude Platform on AWSなどクラウドプロバイダー経由で実行している
- いずれかの設定ファイルで
forceLoginOrgUUIDが設定されている、またはforceLoginMethodが"claudeai"か"console"になっている - managed settingsファイル・MDMプロファイル・キャッシュ済みのサーバー管理設定のいずれかは存在するのに、Claude Codeがそれを読み込めず、かつ他に有効な管理ソースが無い
キーなしサインインを試す前に、シェルにANTHROPIC_API_KEYが残っていないか確認してください。残っていると優先されてしまいます。
unset ANTHROPIC_API_KEY
claudeサインイン後は、APIキーの代わりにプロファイルが1つできる状態になります。書き込み先はANTHROPIC_PROFILEで指定したプロファイル、なければアクティブなプロファイル、それも無ければdefaultです。対象がfederationプロファイルの場合、Claude Codeは上書きを拒否してサインインを中止します。組織でserver-managed settingsを使っている場合、このサインインにも適用されます(v2.1.257以降)。このサインインはマシンに保存済みのclaude.aiログインをサインアウトさせる副作用もあるため、既にclaude.aiでログイン済みの端末で試すときは注意してください。取り消したい場合は/logoutを実行すれば、このサインインが書き込んだ認証情報が削除・失効されます。
クラウドプロバイダー経由でチーム認証を設定する
Amazon Bedrock・Google CloudのAgent Platform・Microsoft Foundryをすでに契約しているチームもあります。その場合は、Claude Codeの認証をそのクラウドのIAM基盤に乗せられます。手順は各プロバイダーのセットアップドキュメントに従い、生成された環境変数と認証情報の取得手順をメンバーに配布し、それぞれがClaude Codeをインストールするという3段階です。ブラウザーのログインは要りません。ログイン画面で3rd-party platformを選ぶと、BedrockとVertex AI向けの対話式セットアップウィザードが起動します。
プロバイダー間で使える機能に差があるため、選ぶ前にClaude Codeの機能比較 — Bedrock・Vertex・Foundry別対応表で確認しておくと導入後の手戻りを減らせます。
クラウドプロバイダー経由のセッションは、Consoleが発行するAPIキーとは扱いが根本的に違います。組織の所属チェックはクラウド側のアクセスポリシーが担います。ただしforceLoginOrgUUIDなどを配布した端末では、ANTHROPIC_API_KEYなどのキーが残っているとクラウド経由のセッションも起動時に止まります。claude.aiアカウントの所属組織をforceLoginOrgUUIDで絞る設定は、Claude Codeで組織限定ログインを強制する方法にまとめています。
認証情報が複数あるとき、どれが使われるか
チーム展開で起きやすいのは、開発者の端末に複数の認証情報が同居して、意図しないものが選ばれる事態です。Claude Codeは次の順で1つを選びます。
CLAUDE_CODE_USE_BEDROCK・CLAUDE_CODE_USE_VERTEX・CLAUDE_CODE_USE_FOUNDRYで選んだクラウドプロバイダーの認証情報ANTHROPIC_AUTH_TOKEN(Authorization: Bearerで送る。LLMゲートウェイ向け)ANTHROPIC_API_KEY(X-Api-Keyで送る。対話モードでは初回に使うかを尋ねられ、答えが記憶される)apiKeyHelperスクリプトの出力CLAUDE_CODE_OAUTH_TOKEN- Anthropicプロファイル・federation認証情報。
ANTHROPIC_PROFILEで名指ししたものは/loginより上、ant auth loginが書いたプロファイルは名指しがなければ/loginの下 /loginで得たサブスクリプションのOAuth認証情報(Pro・Max・Team・Enterpriseの既定)
サインイン済みのClaude apps gatewayセッションだけはこの順位の外にあり、クラウドプロバイダーの変数より優先されます。サブスクリプションがあるのに認証が通らないときは、期限切れや無効化された組織のAPIキーがANTHROPIC_API_KEYに残っていないかを疑います。unset ANTHROPIC_API_KEYしたうえで/statusを見ると、どの方式が有効かが分かり、ログインとキーが併存するときは使われていない側に印が付きます。
名指しのプロファイルやfederation変数が選ばれている間は、claude.aiコネクタや/scheduleのようにclaude.aiログインを必要とする機能も使えません。
管理者が端末側でログイン方式を縛る
配布した後に開発者が使う認証を絞るには、managed settingsに次のキーを置きます。allowedProvidersはv2.1.285以降です。
{
"forceLoginMethod": "claudeai",
"forceLoginOrgUUID": ["xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"],
"allowedProviders": ["anthropic", "bedrock"]
}この設定では、自組織のclaude.aiにサインインした開発者かBedrockを構成した開発者だけが通常どおり起動できます。それ以外のプロバイダー向けの構成は起動時に拒否されます。社内のLLMゲートウェイを通す場合は"customEndpoint"も許可し、ゲートウェイのURLを同じ管理ソースのmanaged envに固定します。
ただし、/loginの対話式ログイン画面ではforceLoginMethodは方式を事前選択するだけで強制しないため、そこからConsoleにログインすることは可能です。Consoleログインの所属組織もforceLoginOrgUUIDでは確認されません。
forceLoginOrgUUIDに入れる組織IDは、Teams/Enterpriseならclaude.aiの管理者設定の組織ページ、Consoleならplatform.claude.com/settings/organizationで確認できます。Consoleの場合、単一の組織IDを入れてもサインイン画面で組織が事前選択されるだけです。
注意が要るのは配布経路です。server-managed settingsはすでに組織へ認証済みのアカウントにしか届かず、最初のログインを誘導できません。そのためMDMなど端末側の配布で設定します。server-managed settingsも併用する場合、forceLoginMethodとforceLoginOrgUUIDは両方に置きます。管理ソースはマージされず、キャッシュ済みのサーバー管理設定が端末側のファイルを置き換えるためです。allowedProvidersだけは扱いが違い、端末側のリストはサーバー側からリストが届いても効き続けます。使えるのは両方のリストに載ったプロバイダーだけです。
認証情報はどこに、どう保存されるか
サインインが終わると、Claude Codeは認証情報をOSごとに違う方法で保存します。
| OS | 保存先 | 備考 |
|---|---|---|
| macOS | 保存先暗号化されたKeychain | 備考SSHセッション中などKeychain書き込みが拒否される場合は~/.claude/.credentials.json(パーミッション0600)にフォールバック。この状態でConsoleログインからAPIキーを作ろうとすると、Keychainが書き込み可能になるまで失敗し続ける |
| Linux | 保存先~/.claude/.credentials.json(パーミッション0600) | 備考— |
| Windows | 保存先%USERPROFILE%\.claude\.credentials.json | 備考ユーザープロファイルディレクトリのアクセス制御を引き継ぐ |
CLAUDE_CONFIG_DIR環境変数を設定している場合、.credentials.jsonはそのディレクトリ配下に置かれます。macOSのフォールバック分も同じで、Keychainのエントリもそのディレクトリ名でキー付けされます。仕事用と個人用のアカウントを併用したい開発者には、この仕組みを使ってアカウントごとに設定ディレクトリを分けるエイリアスが使えます。
alias claude-work='CLAUDE_CONFIG_DIR=~/.claude-work claude'ただし、キーなしConsoleサインインはconfigディレクトリの外に保存されるため、この方法ではConsoleサインイン同士を分けられません。対応する認証タイプは次のとおりです。
- claude.ai認証情報
- Claude API認証情報
- Microsoft Foundry・Bedrock・Vertexの各認証
- Anthropicプロファイル
- Workload Identity Federation認証情報
- Claude apps gatewayのセッショントークン
apiKeyHelperでスクリプトからAPIキーを動的発行している場合、挙動は次の通りです。
- 既定では5分ごとにヘルパーを再実行する。間隔は
CLAUDE_CODE_API_KEY_HELPER_TTL_MS環境変数で調整できる - 401・403の応答時と、キャッシュが期限切れのJWTだった場合(v2.1.246以降)も再実行される
- ヘルパーの応答が10秒を超えると、プロンプトバーに経過時間つきの警告が出る。頻繁に出る場合はスクリプトの高速化を検討する
- ヘルパーがエラー終了・タイムアウト・無出力のいずれかになると、3回の試行以内に
Your apiKeyHelper script is failingというエラーで止まる
CIやスクリプトにはブラウザーなしの長期トークンを使う
ブラウザーログインができないCIには、claude setup-tokenで1年有効のOAuthトークンを発行します。v2.1.287のclaude setup-token --helpは「Set up a long-lived authentication token (requires Claude subscription)」と表示します。Pro・Max・Team・Enterpriseのいずれかのプランが前提です。
トークンは端末に保存されず、承認後にターミナルへ表示されるだけです。控えて、使いたい環境でCLAUDE_CODE_OAUTH_TOKENに設定します。このトークンはモデルへのリクエストしか行えないので、Remote Controlのセッション確立やclaude.aiコネクタの取得はできません。--bareを付けたスクリプトはこの変数を読まないため、その場合はANTHROPIC_API_KEYかapiKeyHelperを使います。
ログイン期限が近づいたとき
/loginで作ったログインの期限まで3日を切ると、起動時にYour login expires in 3 days · run /login to renewという警告が出ます。警告は情報提供で、期限が来るまでは認証が通ります。切れた後は、リクエストのたびにLogin expired · Please run /loginで止まります。
/statusのLogin行には、期限切れの状態がExpired — log in againと出ます(v2.1.210以降、claude.aiのログインが有効な認証情報のときだけ)。バックグラウンドセッションやRemote Controlのセッションは、期限が切れるとサインインし直すまで進まなくなるため、無人で長く回す端末では早めの更新が効きます。
よくあるつまずき
Consoleのキーなしサインインの選択肢が出ない
クラウドプロバイダー経由、forceLoginOrgUUID・forceLoginMethodの設定、管理設定を読み込めない場合のいずれかです。条件の詳細は先の節のとおりで、選択肢が出ないこと自体は異常ではありません。
サインインし直したらclaude.aiログインが消えた
/logoutでキーなしサインインの認証情報を取り消し、/loginでclaude.aiを選び直すと戻せます。
招待したのにYou haven't been added to your organization yetと出る
シートにClaude Codeアクセスが含まれていない状態です。管理コンソールでシートの割り当てを見直してもらいます。
Bedrock・Vertex・Foundryで認証エラーになる
BedrockはCould not load AWS credentials、VertexはCould not load Google Cloud credentialsと出ます。端末のAWS認証情報チェーンやGoogleのアプリケーションデフォルト認証情報を取得できなかった状態です。Claude Codeは2回再試行してから表示します。
FoundryのMicrosoft Foundry authentication failedは、Azureの認証情報が拒否されたか、そのIDにFoundryリソースへのアクセス権がない状態です。/loginではどちらも直りません。プロバイダー別の確認コマンドは「Could not load credentials」の直し方にまとめています。
まとめ
経路を選ぶ決め手は、課金より先に「claude.aiアカウントが要る機能を使うか」です。使うならTeams/Enterpriseを軸にし、BedrockやConsoleはシートと併用する構成を検討します。展開後は、認証情報の優先順位とforceLoginMethodの配布経路を確認しておくと、「別のキーが使われている」系の問い合わせを減らせます。開発者個人が普段どのログイン方式を選ぶかはClaude Codeログイン方法3種の使い分けに書いています。