organization has been disabledエラーの意味と対処 — Claude Code

「This organization has been disabled」は、無効化されたConsole組織に属する古いANTHROPIC_API_KEYをClaude Codeが使い続けているときに出ます。有効なサブスクリプションでログイン済みでも、環境変数のキーが残っていればそちらが優先されるため、このエラーが出ます。対処はunset ANTHROPIC_API_KEYが起点です。

画面に出る文言とヒントの読み方

Claude Codeは、環境変数のキーがある状態を検知すると次のいずれかを表示します。

Your ANTHROPIC_API_KEY belongs to a disabled organization · Unset the environment variable to use your subscription instead
Your ANTHROPIC_API_KEY belongs to a disabled organization · Update or unset the environment variable
API Error: 400 ... This organization has been disabled.

·のあとのヒントは、保存済みの認証情報があるかどうかで変わります。Unset the environment variable to use your subscription insteadが出るなら、キーを外せば動くサブスクリプションのログインへ切り替わります。Update or unset the environment variableが出る場合は、フォールバック先の保存済みログインが無く、キーを外したあとに/loginをやり直す必要があります。

たとえば、過去にConsole(API)アカウントを試したときのexport ANTHROPIC_API_KEY=...がシェルの設定ファイルに残っていて、そのAPIキーが属していたConsole組織が後から無効化された、という経緯で出ます。

なぜサブスクリプションがあるのに優先されないのか

Claude Codeの認証は、環境変数がログインより優先される設計です。シェルプロファイルでエクスポートしたキーや.envファイルから読み込んだキーは、動作するPro・Max・Team・Enterpriseの契約があっても使われます。非対話モード(-p)では、キーが存在すれば常にそちらが使われ、承認を尋ねる余地もありません。対話モードでは、キーを使うかどうかを最初に一度だけ尋ねられ、選択は記憶されます。あとから変えるときは/configの「Use custom API key」を切り替えます。

認証方式の優先順位のどこにキーがあるか

このエラーが起きやすい構造を理解するには、Claude Codeがどの順番で認証情報を選ぶかを知っておくと早道です。複数の認証情報が同時に存在するとき、Claude Codeは次の順で最初に見つかったものを使います。

1. クラウドプロバイダー認証情報(CLAUDE_CODE_USE_BEDROCK等が設定されている場合)
2. ANTHROPIC_AUTH_TOKEN環境変数
3. ANTHROPIC_API_KEY環境変数
4. apiKeyHelperスクリプトの出力
5. CLAUDE_CODE_OAUTH_TOKEN環境変数
6. Anthropicプロファイル・フェデレーション認証情報
7. /loginによるサブスクリプションOAuth

ANTHROPIC_API_KEYは上から3番目で、/loginのサブスクリプションOAuthより上位です。つまり、サブスクリプションでログインし直しても、シェルに残ったキーがある限りそちらが選ばれ続けます。この順位を知らずに/loginだけを繰り返しても解決しない理由がここにあります。

似た3つの「組織が原因」エラーを見分ける

「組織」が絡むエラーはこのほかに3種類あり、原因がまったく違います。個人のシェルに残った値が原因のものと、管理者の設定で出るものを混同すると、直す場所を間違えます。

2番目の「Your organization has disabled API key authentication」はv2.1.169以降で表示され、管理者がAPIキー認証そのものを無効化した状態です。Claude Desktopから使っている場合は「Sign in again with your claude.ai account」というヒントも出ます。ヒントは原因の場所によって変わり、ANTHROPIC_API_KEYが原因なら環境変数を外して/login、apiKeyHelperが原因ならその設定をsettings.jsonから取り除いて/loginします。

3番目の「Your organization has disabled Claude subscription access」は、サーバー側の組織設定でありローカルの設定・環境変数・CLIフラグでは上書きできません。Agent SDKと非対話モード(-p)ではoauth_org_not_allowedというエラーコードとして表面化します。管理者に有効化を依頼するか、Console APIキーでの認証に切り替える必要があります。

直し方の手順

/status

/statusを実行し、有効な認証情報がサブスクリプション側になっているかを確認します。Login methodの行に契約アカウントが表示されます。ログインとAPIキーの両方が設定されていると、/statusは使われていない側の認証情報に印を付けます。環境変数を何も設定していないのにこのエラーが続く場合は、サポートへ問い合わせるか、別のアカウントでサインインしてください。

ログイン方式全体の使い分けはClaude Codeログイン方法3種の使い分けにまとめています。

認証まわりのコマンドを手元で確認する(v2.1.285)

/statusのほかに、シェルから使える認証系のサブコマンドがあります。ヘルプ表示だけで確認できる範囲を、v2.1.285で見ておきます。

$ claude auth --help
Commands:
  login [options]   Sign in to your Anthropic account
  logout            Log out from your Anthropic account
  status [options]  Show authentication status
 
$ claude auth status --help
Options:
  --json      Output as JSON (default)
  --text      Output as human-readable text

claude auth statusは、対話セッションを開かずに認証状態を出せるコマンドです。既定はJSONで、--textを付けると人間向けの表示になります。スクリプトやCIから認証状態を見たいときに向いた形式です。

もう1つ、ログインの選び方がclaude auth loginのオプションに出ています。

$ claude auth login --help
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
  --sso            Force SSO login flow

このエラーの後始末で/loginをやり直すとき、既定は--claudeai(サブスクリプション)で、--consoleを付けたときだけAPI従量課金のConsoleアカウントで入ります。古いConsole組織に紐づくアカウントで--consoleを選ぶと、同じ種類の問題を再び踏むおそれがあります。

--bareで起動したときは認証の前提が変わる

claude --helpの--bareの説明には、Anthropic auth is strictly ANTHROPIC_API_KEY or apiKeyHelper via --settings (OAuth and keychain are never read)と書かれています。OAuthやキーチェーンを読まないモードなので、--bareでは/loginで入ったサブスクリプションが使われず、ANTHROPIC_API_KEYか、--settingsで渡すapiKeyHelperだけが頼りです。ここに無効化された組織のキーが残っていると、通常のセッションで直したつもりでも--bareを使うスクリプトだけは同じエラーで落ち続ける、という状況が起こりえます。--bareを使う自動化では、キーの中身が現行の組織のものかを別に確認しておく必要があります。

管理者側で確認すること

組織のAPIキー認証やサブスクリプションアクセスそのものを止めているのか、単に1つの組織が無効化されているのかは、管理コンソール側でしか判断できません。組織のポリシーとして何を統制しているか、ファイルベースとサーバー管理設定のどちらが優先されるかはClaude Code組織管理ガイドで扱っています。開発者が自分のsettings.jsonをいじっても解決しない種類の設定が多いことも、あわせて確認しておくと問い合わせの手間が減ります。

管理者側からすると、開発者から「organization has been disabled」という報告を受けたときにまず切り分けるべきは、報告してきたのが1人だけか、チーム全体かです。1人だけなら、その人のシェルに個人的に残った古いキーである可能性が高く、管理コンソールの設定を疑う前に本人の環境変数を確認してもらうほうが早く解決します。チーム全体で同時に発生しているなら、共有しているキーが属する組織の状態を管理コンソールで確認する必要があります。この切り分けを最初に行うだけで、原因調査にかかる時間の多くを削れます。

よくある質問

.envファイルが原因になることはありますか

あります。直接exportしていなくても、direnvやdotenv系のシェルプラグイン、IDE内蔵ターミナルがプロジェクトの.envファイルからANTHROPIC_API_KEYを自動で読み込むことがあります。env | grep ANTHROPICで現在有効な値を確認し、意図しないキーが読み込まれていないか確認してください。

会社のAPIキーを使いたいのに無効化されていると出ます

そのAPIキーが属するConsole組織自体が無効化されている状態です。個人のシェル設定を直しても解決しません。組織の管理者に、Console上での組織の状態を確認してもらう必要があります。

自動化スクリプトで気づくのが遅れるのはなぜですか

CIやスクリプトで無効化された組織のキーが残っていると、対話モードなら画面のヒントで気づけますが、非対話モードでは承認を尋ねる余地もないため、ジョブが落ちてから発覚しがちです。自動化環境ほど、環境変数の棚卸しが効きます。

まとめ

原因が自分の環境変数側にあるのか組織のポリシー側にあるのかは、メッセージの文言で最初に切り分けられます。1人だけの症状かチーム全体の症状かも、管理者へ問い合わせるかどうかの判断材料になります。