Claude Codeのアカウント停止はまず分岐確認：appeal前の復旧手順

Claude Codeでアカウントやorganizationが無効と表示されたら、最初にやるべきことはVPN変更でも新規アカウント作成でも返金交渉でもありません。同じロックアウトに見えても、実際には本当のアカウント停止、Console/API組織の問題、古いANTHROPIC_API_KEY、使用量上限、ログイン障害、支払いサポート、返金レビューが混ざります。

日本語の読者は、本人確認で復旧した体験談、Redditの停止例、appeal guide、ログイントラブル解説を同時に目にします。だから最初に必要なのは、停止されたかどうかの断定ではなく、どの分岐にいるかを早く確認できる実務的な復旧ルーターです。

最初の10分では、結論を急ぐよりも、証拠を減らさないことが重要です。Claude.aiに入れるか、CLIだけ失敗しているか、環境変数が残っているか、statusに障害があるかを順番に見ます。ここで原因を一つに決めつけなければ、appeal文もsupport文も短くなり、返金の相談も論点がずれません。

また、日本語では「BAN」という言葉が便利に使われますが、公式のUIやsupportはaccount、organization、usage limit、billing、refundという別々の面で動きます。記事の中でも、BANという感情的な呼び名ではなく、停止、無効、認証、上限、請求という判断語を使うほうが実務に近いです。

結論：停止かどうかを決める前に、失敗分岐を分ける

Claude Codeのロックアウトは一種類ではありません。すべてを「BAN」と呼ぶと、appealすべきケース、supportに聞くべきケース、status incidentを待つべきケース、ローカル認証を直すべきケースが混ざります。まず保存するのは、エラー原文、時刻とタイムゾーン、アカウントメール、支払い経路、Claude.aiかClaude CodeかConsole/APIか、Organization IDにアクセスできるかです。

その上で、失敗した面を確認します。ブラウザのClaude.aiは入れるのか。CLIはサブスクリプションログインなのか、API keyなのか。表示はsuspended、organization disabled、usage limit、authentication、network、credit、policy refusalのどれなのか。ここまで分けると、次に送る文面も短くなります。

Claude Codeではこの切り分けが特に重要です。AnthropicのClaude Code文書は、CLIがPro/MaxサブスクリプションでもConsole/APIでも動けること、そしてANTHROPIC_API_KEYがサブスクリプション認証より優先されることを説明しています。ブラウザのClaudeは正常でも、CLIだけ古いConsole組織に向いていることがあります。

本当のアカウント停止に近いケース

本当の停止に近いのは、アカウントレベルの通知があり、Claude.aiも使えず、SafeguardsまたはTermsの審査対象になっている場合です。AnthropicのSafeguards Warnings and Appealsは、反復的なUsage Policy違反、非対応地域からのアカウント作成、Terms違反を公開カテゴリとして示しています。

ただし、公開カテゴリは完全な内部判定リストではありません。日本語や英語のコミュニティで語られるVPN、端末、カード、深夜利用などの説は、公式に確認できる仕組みとして書くべきではありません。appealでは、推測ではなく、アカウント、製品面、エラー原文、発生時刻、Claude Codeでの用途、判断が誤っていると思う理由を簡潔に書きます。

返答が遅いこともあります。Anthropicの公式ページは時期によって通常より返信が遅いと案内しています。数日返信がないことだけで、結果を決めつけないでください。

This organization has been disabled は別枠で見る

This organization has been disabledは、見た目より幅が広いエラーです。まずClaude.aiをブラウザで開きます。ブラウザが動くなら、消費者アカウント全体の停止よりも、CLI認証、API key、Console organizationを疑う余地があります。

次にClaude Codeの/statusやログイン状態を見て、現在どのアカウントまたは組織に入っているかを確認します。shell、dotfiles、IDE、CIにANTHROPIC_API_KEYが残っている場合、Pro/Maxサブスクリプションではなく、古いConsole組織へ接続している可能性があります。意図した経路がサブスクリプションなら、その変数を外して再ログインします。

これは回避策ではなく、誤診を防ぐ手順です。前職のキー、古いプロジェクト、停止されたConsole組織、API billingの問題は、消費者アカウントの停止とは別のsupport laneです。

利用上限、ステータス、ログイン、支払い、地域を分ける

usage limit、reset、quota、rate limit、creditという語があるなら、停止申立てより先に上限の分岐です。必要なら Claude Codeの使用量制限問題 に進んで、reset windowとplan surfaceを確認してください。

Claude Statusも最初に確認します。Claude.aiとClaude Codeが同時に落ちているとき、active incidentがあれば対応はappealではなく、待機、再試行タイミング、時刻保存に変わります。逆にstatusがgreenでも、個別のaccount、organization、key、billing、region、plan stateが健康だとは限りません。

支払いと地域も混同しないでください。Pro/Maxの消費者サブスクリプションとConsole/API billingは別です。App Store経由、ウェブ購入、対応地域、電話番号、カード発行元は、それぞれsupportやrefundの分岐を変えます。

appeal/support用の証拠パケット

よい問い合わせは短く、証拠がそろっています。悪い問い合わせは長く、推測、怒り、個人情報、矛盾が混ざります。

保存するものは、エラー原文、時刻、タイムゾーン、発生面、アカウントメール、planまたは支払い経路、Claude.aiが動くか、Claude Codeがsubscription authかAPI keyか、ANTHROPIC_API_KEYの有無、Organization IDが見えるか、請求書またはreceiptです。スクリーンショットではAPI key、支払い情報、個人情報、非公開プロジェクト内容を隠します。

support文面は短くできます。ClaudeまたはClaude Codeのアクセスがdisabledに見える。エラーはこれ。発生時刻はこれ。発生面はClaude.ai、Claude Code、Console、APIのどれ。planまたはpayment channelはこれ。Claude.aiには入れる、または入れない。Organization IDは見える、またはロックアウトで見えない。enforcement、organization status、authentication、billing、refund reviewのどれか確認してほしい。

返金は分岐確認の後に置く

返金可否はアクセス喪失の理由によって変わります。AnthropicのConsumer Termsは、支払いは原則返金不可であり、Termsまたは法律が認める場合を除くとしています。Termsやpolicy違反によるterminationでは返金権が弱く、別理由でウェブ購入サブスクリプションを終了した場合には未使用分按分の言及があります。

iOSやAndroid支払いならapp store側のルールが絡みます。支払い紛争が始まっている場合、公式のrefund handlingが制限されることもあります。銀行側の手続きが必要な個別事情はあり得ますが、多くのClaude Code lockoutでは最初の技術的対応ではありません。

待っている間に避けること

代替アカウント作成、IPやVPNの切り替え、他人の認証情報、解禁サービス、支払いカードの差し替えを復旧策として扱わないでください。これらは誤ったauth問題を、より説明しにくいTerms問題に変える可能性があります。

また、メール、Organization ID、API key、請求書、DMが見えるスクリーンショットを公開しないこと。複数の矛盾するsupport ticketを送らないこと。公式が確認していない原因を断定しないこと。安全な回復は、事実を整理して公式ルートに出すことです。

チームや会社の開発環境では、Claude Codeがどこで動いているかも確認します。個人PC、remote dev server、CI、IDE拡張、古いshell profile、前のプロジェクトのsecretなど、API keyが残る場所は一つではありません。ローカルだけを見て「keyはない」と決めるより、確認した場所をリスト化したほうがsupport caseとして強くなります。

支払いの話も分けてください。最初の問い合わせでは、access branchの確認を優先します。その後、実行問題ではないと分かった段階で、invoice、支払いチャネル、購読開始日、アクセスできなかった期間、キャンセルまたは返金レビューの希望を追加します。返金を弱めるためではなく、返金の話を事実の上に置くためです。

すでに曖昧なticketを送ってしまった場合も、別の話として作り直すより、同じスレッドで短い補足を入れるほうが安全です。前回は停止と書いたが、現在はClaude.ai、Claude Code、API key、status、billingをこの順番で確認した。まだ不明な点はこれで、確認してほしい分岐はこれ、という形に戻します。

仕事が急ぎであることは、supportへの主張ではなく、手元の継続計画で扱います。公式連絡では、緊急度よりも、確認済み事実と未確認分岐を明確にするほうが効果的です。

組織利用なら、Consoleを見られる人、請求を確認できる人、購読を管理している人も分けて確認します。

待っている間に進められる作業はあります。要件整理、ローカルテスト、コードレビュー、ドキュメント更新、別ツールでの設計検討などです。ただし、停止されたアカウントを別アカウントや借用資格情報で置き換えることは、継続策ではなく回避に見えます。この境界を守るほど、後から説明しやすくなります。

審査中の安全な継続策

継続策はアカウント復旧ではありません。できるのは、ブロックされた作業を記録し、ローカルで進められるテストや設計を進め、各サービスのTerms内で別のcoding assistantを使うことです。

別ツールを検討するなら Claude Code vs Codex はworkflow continuityの比較です。停止アカウントを回避する方法として読まないでください。

よくある質問

This organization has been disabled は必ずBANですか？

いいえ。organizationまたはaccount actionのこともありますが、古いANTHROPIC_API_KEYやConsole/API routeが原因のこともあります。

すぐappealすべきですか？

実際のsafeguardsやaccount enforcementが見えている場合だけです。limit、status、API key、billing、authは先に別分岐を確認します。

Organization IDが見えない場合は？

作らないでください。ロックアウトで見えないと書き、エラー原文、メール、製品面、時刻、支払い証拠を添えます。

返金は期待できますか？

理由次第です。違反によるterminationは弱く、非執行のアクセス・請求問題ならsupport reviewの余地があります。

Claude Statusがgreenなら安心ですか？

いいえ。広域障害の可能性が下がるだけで、個別accountやorganizationの状態は別です。

ANTHROPIC_API_KEYは消すべきですか？

Pro/Max subscriptionを使いたいのにAPI keyが優先されている場合だけです。API利用が意図ならownerとbillingを確認します。

VPN変更で直りますか？

公式に安全な復旧策として扱うべきではありません。appeal、support、status、auth、billingの確認が先です。

一文で言うと？

記録を保存し、失敗分岐を確認し、対応する公式appealまたはsupportへ進む。アカウントやネットワークを変えるのはその前にしない。