Claude KYC 認証ガイド 2026: 電話番号、本人確認、支払い、アカウント境界

Claude には、いまも全ユーザー共通の 1 本化された認証フローがあるわけではありません。最初に考えるべきなのは「どうやって全部の確認をまとめて通すか」ではなく、目の前の prompt がどの分岐に属しているかです。新規アカウントでよく出る電話番号確認なのか、一部ケースだけの本人確認なのか、別扱いの支払い確認なのか、それとも認証後でも残る地域 / 年齢 / policy 制限なのかを先に切り分ける必要があります。

ここを見誤ると、次の行動もずれます。電話番号を求められているなら、論点は対応地域の SMS 携帯番号を持っているかどうかです。身分証と自撮りを求められているなら、あなたはより狭い本人確認分岐にいます。Verify now のような請求モーダルなら、支払い経路の話です。何かしらの認証を終えたのにまだ使えないなら、問題は認証不足ではなく資格や制限にあることが多いです。

2026 年 6 月 17 日時点でも、Anthropic の help center はこれらを別 surface として書いています。電話番号確認は多くの新しい consumer Claude account の基本分岐のままです。本人確認は一部 use case に限定されます。支払い確認は別の billing flow です。年齢確認は Yoti を使う別チェックとして出ることがあります。そして認証に通っても、unsupported location、18 歳未満、Terms、Usage Policy の制限が消えるわけではありません。だから最初にやるべきことは、曖昧な回避ワードを探すことではなく、いまの prompt、ページ、または account state を正しい分岐に戻すことです。

Claude の代理認証を勧められた場合

Claude の代理認証を、普通のサポート手順として扱わないでください。実際には、第三者が電話番号、身分証、自撮り、Claude のログインセッション、支払い経路、遠隔ブラウザセッションをあなたの代わりに扱う、という意味になりがちです。それは Anthropic の公式フローを本人が進めることとは別物で、リスクも別の種類です。

赤信号はかなり明確です。パスポート、運転免許証、顔動画、Claude パスワード、メールセッション、復旧コード、カード情報、遠隔ログイン権限を求めるサービスは、あなたの本人情報やアカウントを危険にさらす情報を求めています。"anti-ban"、"region bypass"、"KYC on your behalf"、"shared verified accounts"、"Claude Code access after verification" のような約束も、認証と制限回避を混ぜています。

安全な分岐はもっと狭いです。資格があるなら公式の電話、本人、支払い確認を自分で完了する。すでにアカウントが警告や制限の流れに入っているなら Anthropic のサポート / 申立てを使う。目的が Claude 消費者アカウントの復旧ではなくプログラムからの利用なら、Claude Console、対応クラウドプロバイダー、準拠した API 経路を選ぶ。Gateway が API アクセスの問題を解くことはありますが、本人確認書類や消費者アカウントを外部の代理確認者に渡してよい理由にはなりません。

KYC screener や金融 agent のページだった場合

もうひとつ混同しやすいのが、Anthropic の金融サービス向け agent 情報です。そこに出てくる KYC screener は、個人ユーザーが Claude にログインするための本人確認 prompt ではありません。銀行、ファンド、保険、コンプライアンスチームが使う業務テンプレートに近く、entity file を組み立て、source documents を確認し、risk scoring や escalation packet をまとめるためのものです。

つまり KYC という語が出ても、文脈が違えば next step も違います。個人アカウントの文脈では、「Claude が利用前に何か確認を求めている」という意味で使われがちです。金融サービスの文脈では、顧客、取引先、法人、証憑、例外処理を審査する compliance workflow を指します。どちらにも identity や document という言葉は出ますが、前者はあなたの Claude account の画面、後者は企業向け product workflow です。

開いているページが KYC screener、Cowork、Claude Code plugins、Managed Agents、connectors、entity-file review について説明しているなら、それは企業向け product information と読んでください。個人の Claude account に身分証を提出すべきかどうかは、実際に表示されている phone、identity、payment、age、location、appeal の prompt で判断します。

年齢確認は本人確認とは別に読む

Anthropic は age assurance も別に説明しています。Consumer Claude は 18 歳以上向けで、システムが under-18 signal を検出した場合、Yoti を使った年齢確認を求めることがあります。この確認には facial age estimation、ID verification、Yoti Digital ID が使われる場合があり、Anthropic は pass / fail の結果だけを受け取ると説明しています。

これは本人確認や enforcement と同じ意味ではありません。年齢確認は年齢要件を満たしているかを見るもの、本人確認は一部 use case で本人性を見るもの、enforcement は地域、Terms、Usage Policy の境界を見るものです。ここを分けておくと、身分証を準備すべきなのか、支払い modal に戻るべきなのか、申立てに進むべきなのかを誤りにくくなります。

まず 30 秒で「いまどの分岐か」を判断する

Claude の認証プロンプトをひとつの言い方に潰してしまうと、実際には 4 つの別問題が見えなくなります。すると案内も「全部を本人確認として説明する内容」か「回避や迂回を前面に出す内容」に寄りやすくなります。Anthropic の公式サポート記事はそうではありません。電話番号確認、本人確認、支払い確認、制限をそれぞれ別ものとして扱っています。

ここで一番役立つのは、抽象的な compliance 解説よりも surface の見分け方です。Anthropic の通常 login は今も email link や Google sign-in が中心です。だから、アカウント作成や初回 setup の途中で電話番号を求められているなら、それは phone verification branch と読むのが自然です。login に関係する prompt を全部「本人確認」と読んでしまうと、最初の一歩からずれます。

だから範囲は意図的に狭くします。プライバシー論でもなければ、回避チュートリアルでもありません。目の前の Claude 認証プロンプトを正しく読むための判断手順です。

Claude が電話番号確認を求める場合

Claude がアカウント作成時に電話番号を求めるなら、Anthropic は今もそれを consumer Claude の通常入口として扱っています。重要なのは「SMS が届くかどうか」だけではありません。その番号が supported location に属しているか、そしてテキスト SMS を受け取れる mobile number であるかです。

Anthropic はこの分岐で、VoIP numbers、Google Voice、app-created numbers、landlines を受け付けないと明記しています。ここはかなり重要です。このテーマの多くのページは、つながる番号さえあればよいかのように書きますが、公式の contract はそうではありません。番号タイプ自体が unsupported なら、同じ種類の番号で再試行しても本質的な修正にはなりません。

さらに Anthropic は、新しい consumer Claude account に対してこの step を skip する公式な方法はないとも書いています。この境界はかなり明快です。Pro に入る予定があるとしても、signup contract が別物になるわけではありません。Pro plan でも account creation は supported-location presence と supported-location phone verification に依存します。

もうひとつ覚えておくとよいのは、verified phone number は現在あとから変更できないという点です。最初の phone verification は一時的な hurdle というより、長く残る account setup の一部として扱うほうが安全です。

Claude が本人確認を求める場合

本人確認は、読者が全体像だと誤解しやすい branch ですが、すべての Claude account の default requirement ではありません。Anthropic の current help article は、これを一部 use case 向けの rollout として説明しています。だからこの branch を phone verification より前に置くと、読者の現実とずれます。

この flow では、physical government-issued photo ID と live selfie を求められることがあります。Anthropic は現在の partner として Persona を明記しています。また、verification data は identity confirmation や safety / legal obligations のために使われ、model training には使われないとも説明しています。画像自体は Persona が保持し、Anthropic は必要に応じて verification records にアクセスするが、画像を自社保存するわけではないという説明です。

ここで役立つのは narrow に対処することです。いま見えている screen がこの branch なら、有効な document、読める画像、十分な光、使える camera という本人確認そのものの条件に集中してください。Anthropic は identity verification を正確に引き起こす capability や account state の完全 matrix を公開していません。そこを推測で埋めないことも大事です。

Claude が支払い確認を求める場合

Anthropic は、paid-account situations の一部で payment-method verification prompt が出ることも別記事で案内しています。これは phone verification の延長でも、本人確認への静かな昇格でもありません。billing surface です。

公式に見える action は Verify now modal で、Remind me later を押すと 24 時間あとに再表示されると説明されています。この detail 自体が useful です。つまり、いま解くべきなのは payment path であって、広い意味の identity issue ではありません。カード情報や請求経路の話に留め、そこから region や document flow 全体の話へと無理に広げない方が安全です。

支払い確認が厄介なのは、ここで subscription、region、document verification、fraud speculation が一気に混ざりやすいからです。早めに payment verification を payment surface に戻すほど、次の一手は明確になります。

認証後もアカウントが制限される場合

ここが最も誤読コストの高い branch です。verification に通ったからといって、Anthropic の他の boundary をすべて超えたことにはなりません。Identity-verification article 自体が、successful verification で unsupported location、under-18 usage、Terms of Service、Usage Policy による later action が消えるわけではないと書いています。

つまり、「もう認証した」は「必ず使えるはずだ」と同義ではありません。認証後もアカウントが利用不可のままだったり、warning や restriction が残るなら、より重要なのは資格か制限かの見極めです。Anthropic の getting-started docs は今も 18 歳以上を要求し、Claude 消費者向けサービスは supported locations に依存し、warnings and appeals docs では unsupported-location account creation が account action の理由になり得ると説明しています。

だから同じ認証手順を繰り返すことは、しばしば罠になります。問題が地域、年齢、ポリシーにあるなら、同じ書類や電話ステップをやり直しても本質は変わりません。より安全なのは、制限の境界を特定し、Anthropic が用意している申立て / サポート経路に移ることです。

もしシステムがすでに warning、suspension、appeal flow に入っているなら、そのサポート表面を主語にしてください。「もう一度自撮りを出せば解決するかも」という理解のままでは、問題の種類を取り違えます。認証が証明するものと、制限判断が見るものは別です。

本当の問題は Claude 消費者向け認証ではなく API / 接続経路かもしれない

ここに来る読者の一部は、実際には consumer Claude の verification ではなく、「Claude にどうアクセスするか」を解きたいだけです。この 2 つは混ぜない方がいいです。Anthropic は consumer Claude と Claude API について別々の support-location docs を持っており、third-party tooling には API key を使うべきだとも案内しています。

本当に解きたいのが access path choice なら、Claude の access path ガイド を見てください。Claude API key を試せるか、billing がどう始まるかが知りたいなら、Claude API key と free-tier のガイド の方が本筋です。

この転換が必要なのは、互換 gateway が解決するのは別のアクセス問題だからです。通常の Claude 消費者アカウントに対する Anthropic の電話確認や地域ルールを置き換えるわけではありません。

安全な経路が約束しないこと

安全な経路は回避を約束しません。Anthropic の phone-verification help article は、新しい consumer account に skip path がないことをかなり明快に書いています。本人確認トリガーの完全一覧も約束しません。Anthropic はその matrix を公開していません。認証成功が地域やポリシーによるブロックを消すとも約束しません。公式がそう言っていないからです。

その代わり、答えは狭くても実用的であるべきです。いまの prompt を正しい branch に置き直せれば、その先の action はかなりシンプルになります。

FAQ

Claude はいつも本人確認を要求しますか？

いいえ。本人確認は identity-verification branch に属し、Anthropic は現在それを一部 use case 向けとして説明しています。多くの新規 consumer Claude account では、より一般的な入口は phone verification のままです。

Claude の電話番号確認はスキップできますか？

Anthropic の current help article では、新しい consumer Claude account に公式な skip path はないと案内されています。

Claude の代理認証サービスを使うべきですか？

いいえ。代理認証サービスは、身分証、顔データ、アカウントセッション、支払い情報、復旧経路を第三者に渡すリスクがあり、認証問題を Terms や制限の問題に変える可能性もあります。公式分岐は自分で進め、必要なら Anthropic の申立て経路を使い、開発者アクセスが目的なら正規の API 経路を選んでください。

Google Voice、VoIP、仮想番号、固定電話は使えますか？

使えません。Anthropic はそれらの number type を phone verification では受け付けないと明記しています。

Claude Pro に入れば電話番号確認は不要になりますか？

なりません。Anthropic の current Pro-plan guidance では、ユーザーが supported location にいること、そして supported-location phone verification を伴う account creation が前提のままです。

認証済みの電話番号はあとから変更できますか？

現時点ではできません。Anthropic は verified phone number を後から変更できないと案内しています。

認証済みなのにまだ制限されるのはなぜですか？

認証と制限判断が別の層だからです。Anthropic は supported-location rules、age minimums、Terms、Usage Policy を認証とは別に適用します。

Claude API の認証は Claude 消費者向けアカウントの認証と同じですか？

同じではありません。Anthropic は consumer Claude と Claude API を別 official surface として扱っています。API が本当の目的なら、consumer verification 問題として処理しない方が正確です。