郭立 (leeguoo)

# Claudeのアカウント停止で見るべき3点:地域、IPタイプ、リクエスト指紋、そして自己チェック方法

最近のClaudeアカウント停止の波を分解すると、独立して検出できる3つの軸が重なったものです:地域(公式が唯一明言しているレッドライン)、IPタイプ(データセンター/VPN/プロキシ/住宅プロキシ)、そして中継利用時に日付の中へ隠されるステガノグラフィー透かし。この記事では各軸の検出メカニズム、自己チェック方法、回避方法を整理し、無料の検出ページとステータスバー用の小さなツールも紹介します。

2026年7月3日 · 記事 · 公開

このページの目次

カバー:1つの出口IPが地域、IPタイプ、リクエスト指紋という3つの検出ゲートを順に通過し、リスク判定ダッシュボードへ集約される

最近のClaudeアカウント停止の波について、今でも多くの人が自分がどう引っかかったのか分かっていません。ネットワークを変えてそのまま使えている人もいれば、翌日に再ログインしたらアカウントが消えていた人もいます。同じように中継を使い、同じように中国国内にいるのに、結果は分かれています。

調べられる仕組みしくみを一通り確認しました。Anthropicの公式こうしきポリシー、IPレピュテーションを扱ういくつかの事業者じぎょうしゃの方法論ドキュメント、コミュニティ内の実際のアカウント停止事例じれい、さらにClaude Codeクライアント内でリバースエンジニアリングにより見つかった透かしコードです。見ていくと、アカウント停止は不可解ふかかいなものではなく、個別に検出けんしゅつできるいくつかの軸が重なって起きていることが分かりました。この記事では、それらの軸を一つずつ分解します。何が原因で停止されるのか、どう自己チェックするのか、どう避けるのかを説明します。

文末ぶんまつには、私が自分で作った小さなツールを2つ載せています。1つはネットワークを調べるもの、もう1つは使用量を監視するものです。どちらも無料で、後で説明します。

$ markdown
## まず結論:アカウント停止で見られるのは1つではなく3つ

多くの人は「VPN/中継を使うと停止される」と考えています。この言い方は半分だけ正しいです。実際にリスクを決めるのは、互いに独立した3つの<ruby>次元<rt>じげん</rt></ruby>で、それぞれが単独であなたを停止に追い込む可能性があります。

1つ目は地域です。あなたのネットワーク出口がどの国にあるか。これはAnthropicが公式に唯一明言している停止トリガーです。2つ目はIPの種類です。住宅回線、データセンター、VPN、プロキシ、Torのどれか。この次元はベンダーのレピュテーションデータベースが最も正確に測れますが、公式には明言されていません。3つ目はリクエスト指紋です。第三者の中継を使っている場合、Claude Codeはリクエスト内にあなたまで追跡できるステガノグラフィー透かしを埋め込みます。この次元は前の2つとは完全に独立しています。

順番に見ていきます。

次元1: 地域、公式が唯一明言しているレッドライン

まず Anthropic 自身がどう言っているかを見ます。サポート文書「利用ポリシー違反の警告を受け取った場合はどうすればよいですか」では、アカウント停止のトリガーとして挙げられているのは3種類だけです。利用内容の違反、サービス規約違反、そしてサポート対象外の地域からのアカウント作成です。

最後の1つに注意してください。公式文書全体の中に、VPN、プロキシ、IPアドレス、共有接続に触れる言葉は1つもありません。ネットワークに関係するものとして唯一出てくるのが「地域」です。一方で Anthropic は別の告知で、法的・規制上・安全上のリスクを理由に、一部地域でのサービス利用をサービス規約で禁止していると書いています。

噛み砕いて言うと、中国本土は Anthropic のサポート対象地域リストに入っていません。中国本土のIPで Claude に直接アクセスすること自体がサービス規約違反であり、そのIPがクリーンかどうかとはまったく関係ありません。

これで、多くの人が納得できずにいる現象も説明できます。自宅のブロードバンドは明らかにクリーンな住宅IPで、プロキシも一切使っていないのに、なぜリスクがあるのか。問題は「汚れている」ことではなく、「場所が違う」ことにあります。北京聯通の住宅IPはレピュテーションスコアが満点の0であっても、それが中国本土の出口である以上、Claude にとってはレッドラインです。多くの人がVPN/中継を使うのは、まさにこのレッドラインを迂回するためです。しかし地域という次元を迂回した結果、今度はIPの種類とリクエスト指紋でつまずくことになります。

次元二:IPタイプ、ベンダーが最も正確に測れる次元

公式は明言していませんが、コミュニティで見かける「ネットワークを変えたら大丈夫になった」という事例の大多数は、同じことを指しています。あなたの出口IPが、データセンター、プロキシ、VPNではないか、という点です。この次元をどう判定するかについては、リスク管理を専門にするベンダーが方法論をかなり細かく公開しているので、その公開ドキュメントに沿って説明します。

まずタイプを見ます。proxycheck.io はIPをタイプ別に基礎点で分類しています。データセンターは33点、VPNは50点、クローラー/Torは75点、公開プロキシと侵害済みホストは一気に100点です。点が高いほど危険です。この順序が重要です。VPNは通常のデータセンターより危険で、プロキシはさらにVPNより危険です。なぜなら、データセンターIPは少なくとも「このサーバーが普通にインターネットにつながっている」という状態ですが、プロキシやVPNは、誰かが身元を隠そうとしていることが明白だからです。

住宅プロキシは最も厄介な部類です。IP2Location の分類には RES、residential proxy という専用カテゴリがあります。これは、誰かが住宅用ブロードバンド回線をプロキシとして売っているという意味です。この種のIPは、地理情報やASN上では通常の住宅回線とまったく同じに見えますが、無数の見知らぬ人にさまざまな自動化用途で使われており、レピュテーションはすでにボロボロです。安価な「住宅IP」サービスを買った場合、高確率でこのタイプであり、リスクはデータセンターよりも高くなります。

レピュテーションには連座があります。ipapi.is には abuser_score という指標があります。これは単一のIPではなく、ASN/組織ネットワーク全体の中で悪用IPが占める割合を計算するものです。5段階に分かれており、20%超は極めて高い、3%から20%は高い、0.85%から3%はやや高い、0.05%から0.85%は低い、0.05%未満は極めて低い、という扱いです。つまり、たとえあなたの具体的なIPがクリーンで、直接的な悪事の履歴が一切なくても、そのIPが属するネットワーク全体が汚れていれば、あなたも巻き添えで責任を負わされます。元の説明では、そのIP自体はフラグされていないものの、所属ネットワーク内に悪用IPがこれほど多いことを考えると、近いうちに悪用される可能性が高い、という趣旨になっています。リスク管理とはそういう計算です。あなたが誰かではなく、誰と一緒にいるかを見るのです。

悪用履歴は蓄積します。AbuseIPDB は各IPに 0 から 100 の abuseConfidenceScore を付けています。これは完全にコミュニティからの報告に基づくもので、100 はほぼ確実に悪意あるIPであることを意味します。スコアは報告数の自然対数で決まり、報告が多いほど点は高くなりますが、伸びは徐々に鈍ります。1、2件の報告だけで一気に跳ね上がるわけではありません。

これらを組み合わせると、あるIPのリスク像はだいたい次のようになります。タイプが下地であり、データセンター、VPN、プロキシにはそれぞれ基準線があります。その上に悪用履歴とネットワーク単位のレピュテーションが重なり、重なるほど赤くなっていきます。これが、私の検出ツールの採点ロジックでもあります。後で説明します。

重要な訂正:データセンターIPだから必ず封じられるわけではない

ここで、私自身も最初は誤解していた点を訂正しておく必要があります。多くの人は「データセンターIPにはリスクがある」と聞くと、クラウドサーバー上で Claude を動かすと封じられると思いがちですが、そうではありません。

AWS/GCP のサーバー上で Claude Code を動かしたり、APIを呼び出したりするのは、完全に通常の、サポートされた使い方です。データセンターIPが本当に危険になる場面は一つだけです。それを使って claude.ai のWeb版にログインしたり、新規アカウント登録したりする場合です。Webログインや登録は、生身の人間がブラウザで行うことを前提に設計されたフローだからです。そこにデータセンターIPが現れると、自動化スクリプトが大量にアカウントを育成しているように見えます。

したがって、データセンターIPを判断するときに一律で切り捨ててはいけません。APIやコマンドラインを動かすなら、データセンターでも問題ありません。Web版へのログインや登録では、データセンターは危険です。この違いを正しく扱えていない検出ツールは多く、私自身の初版もそうでした。

3つ目の軸: 日付の中に隠された透かし

最初の2つの軸は「あなたのネットワークがどう見えるか」でした。この軸は「Anthropic がリクエスト内でどう印を付けているか」です。材料は @chenchengpro による Claude Code 191版ソースコードのリバースエンジニアリング で、私も手元のクライアントと照合しました。仕組みは本物です。

発火条件は、第三者中継の ANTHROPIC_BASE_URL を設定していて、かつそれが公式の api.anthropic.com ではないことです。公式に直結しているユーザーはまったく影響を受けません。だからこそ陳成は、最近のこの一連のBANとこの透かしに直接の関係はないと言っています。透かしは中継や蒸留の場面に備えた追跡手段であって、BANそのものではありません。

Claude Code には、システムプロンプト内の日付として組み立てられる、こんな一文があります。

return `Today${n}s date is ${r}.`;

一見すると無害ですが、その n、つまりアポストロフィと日付の区切り文字にステガノグラフィが仕込まれていて、2つの軸の身元情報をこっそりエンコードしています。

一つはタイムゾーンです。システムのタイムゾーンが Asia/Shanghai または Asia/Urumqi の場合、日付の区切り文字が 2026-06-30 から、こっそり 2026/06/30 に変わります。注意すべきなのは、読んでいるのはシステムのタイムゾーン、つまり Intl…resolvedOptions().timeZone であって、IPの地理位置ではないという点です。

もう一つは、そのアポストロフィです。4種類の書き方があり、肉眼ではほとんど見分けがつきません。

  • '(U+0027 標準アポストロフィ)、通常の第三者エンドポイント
  • (U+2019)、ドメインのホワイトリストに命中
  • ʼ(U+02BC)、中国国内の大規模モデル関連キーワードに命中
  • ʹ(U+02B9)、ドメインとキーワードの両方に命中

無害に見える一文 Today's date is 2026/06/30 に、3ビットの身元情報が隠されている。日付の区切り文字(- か /)がシステムのタイムゾーンを、アポストロフィの4つの字形が中継ドメインの .cn ホワイトリスト命中と deepseek キーワード命中をエンコードする

3つの軸は独立してエンコードされます。たとえ中継ドメインがホワイトリストに入っておらず、キーワードも含んでいなくても、システムのタイムゾーンが上海またはウルムチなら、区切り文字は同じようにスラッシュになります。つまり「中国タイムゾーン + 任意の第三者エンドポイント」のユーザーは、全員がタイムゾーンの軸でタグ付けされます。

マッチングロジックも掘り出されています。ドメインはサフィックス一致で、ホワイトリストは cn から始まり、末尾が .cn のドメインは個別列挙なしに一網打尽です。キーワードは部分文字列一致で、ドメイン内に "deepseek" が出てくるだけで命中し、完全一致は不要です。2つのリストはさらに XOR(key=91)と base64 で難読化されており、文字列スキャンを避けています。

なぜ「今日の日付」という一文を媒体に選んだのか。ここがいちばん陰湿なところです。この印は HTTP header やメタデータではなく、システムプロンプト本文の中に隠されています。中継サーバーは通常、リクエストヘッダーを書き換えたりフィルタしたりしますが、「日付」のような自然言語まで触る人はほとんどいません。つまりこれは、header を洗っても洗い落とせない透かしです。しかも currentDate はすべてのリクエストに含まれるユーザーコンテキスト字段なので、透かしは100%安定して出現します。アポストロフィと区切り文字の変更は意味を損なわず、モデルにとってはまったく同じに読めますし、diff でも気づけません。

証拠はどう閉じるのか。印はリクエストについて回ります。ある中継サービスや蒸留パイプラインが、最終的に Anthropic 公式 API へ回り込んで Claude を再販すると、この印付きのリクエストが Anthropic 自身のサーバーへ戻ってきます。すると Anthropic は自社ログ上でこう読めます。この「私に直結している」リクエストの日付は 2026/06/30、つまりスラッシュなので中国タイムゾーン。アポストロフィは ʹ、つまりドメインと deepseek キーワードの両方に命中。動かぬ証拠です。発信元は、中国タイムゾーンで、中国国内大規模モデル系の中継を設定したクライアントです。能動的に探知する必要はありません。トラフィックが自分から白状します。

ステガノグラフィーの印を帯びたリクエストがユーザーの端末を出発し、中国国内の .cn 中継を経て、最終的に Anthropic 公式 API へ再販で戻ってくる。Anthropic は自社ログで同じ印を読み取り、中国タイムゾーンで国内中継を使うクライアントだと見抜く

普通のユーザーにとっての意味は非常に明快です。第三者中継を使う限り、あなたのリクエストはフィンガープリントで追跡可能です。中国大陸のタイムゾーンなら確実に印が付きますし、タイムゾーンが違っていても、中継ドメインが .cn だったり中国国内モデル名を含んでいたりすれば同じように印が付きます。完全に印を付けられたくないなら、公式エンドポイントに直結する以外の道はありません。

では、結局どうセルフチェックするのか

3つの次元は話し終えました。問題は、あなたが今使っているこのネットワークがどの位置にいるのか、どうやって知るかです。IP の種類、地域、評判といったものは、肉眼では分かりません。

私は無料のチェックページを作りました。「今のこのネットワークで Claude を安全に使えるのか」に答えるためのものです。

ip-check.leeguoo.com

開けばすぐに、現在の出口 IP の判定が見られます。登録不要、何かを入力する必要もありません。やっていることはいくつかあります。

判定は4分類で、漠然としたスコアではありません。安全(住宅回線かつ対応地域)、慎重(データセンター。何に使うか次第)、高リスク(VPN、プロキシ、Tor、または濫用シグナルが重なっている)、地域非対応(中国大陸など)です。各分類ごとに、数字だけ投げて自分で推測させるのではなく、何をすべきかを直接教えてくれます。

地域は IP より優先されます。北京のクリーンな住宅 IP であっても、「安全」とは騙して表示せず、「地域非対応、直接アクセスはリスクあり」と伝えます。ここが、IP チェックを本当に Claude 向けチェックにするうえでの要点です。Claude にとっては、あなたの IP がどれだけクリーンかより、どの国にいるかのほうが重要です。

シグナルはすべて開示して見せます。データセンター、VPN、プロキシ、住宅プロキシ、Tor、モバイルネットワーク、ネットワーク帯域の濫用レピュテーションがどの段階にあるかを全部並べます。点数に入れないものも表示します。ここには最近「中国クラウド」という専用の段を追加しました。Alibaba Cloud、Tencent Cloud、Volcengine、ByteDance などは、IP が米国にジオロケーションされ、帰属地が米国と表示されても、単独で赤く印を付けます。Claude にとって重要なのは、その IP が米国にあるかどうかではなく、背後のクラウドが中国企業かどうかだからです。上の対策リストにある「米国出口+国内大手のドメインはかえって危険」は、まさにこの段が担っています。

さらに、あなたのブラウザ上で直接動く検出が2つあります。どこにもアップロードせず、ちょうど第三の次元で説明した透かしに対応します。1つはブラウザのタイムゾーンです。ページが Intl.DateTimeFormat().resolvedOptions().timeZone を直接読み、Asia/Shanghai のような中国本土のゾーンに当たれば赤字で警告します。これは透かしが読むのと同じ値であり、信号チェーン全体の最初の関門でもあります。タイムゾーンが当たった時点で、後段の IP がどれだけクリーンでも無駄です。もう1つは WebRTC の実 IP です。プロキシを立てているのに、ブラウザの WebRTC がその背後の実際のグローバル IP を漏らすことを知らない人は多い。ページがそれを探り、漏れていればその IP を直接表示します。

その下には「ローカル自己チェック」の一角があります。システムプロキシ、環境変数に残った proxy、ANTHROPIC_BASE_URL——これらはウェブサイトが物理的に読めないシグナルですが、Claude Code は起動した瞬間にあなたのマシンから全部読み取ります。これは私が代わりにテストできないので、実行すべきコマンドを並べておきました。ターミナルで一通り走らせ、空でない箇所は消してください。

さらに Claude 安全スコアとグローバル順位もあります。0 から 100 で、高いほど安全です。世界中の検出結果のうち、自分がどれだけ上回っているかも見られます。完全にお遊びですが、実際こういう比較が好きな人もいます。判定が出たら、ワンタップで共有画像も生成できます。IP をぼかした自分のカードなので、スクショして送るのに便利です。

スコアリングロジックは、この文章で説明してきたものそのものです。proxycheck のタイプ基準に、ipapi.is のネットワーク帯域レピュテーション分類、さらに地域判定を加えています。自分の IP を調べるルートは、純粋な Cloudflare エッジのデータとローカル計算だけで、第三者には一切触れません。だから落ちず、回数制限もありません。「他人の」IP を調べるときだけ、無料の脅威インテリジェンスを一枚重ねます。

別の IP を調べたい場合もできます。ip-check.leeguoo.com/?ip=1.2.3.4、または Accept: application/json ヘッダーを付ければ構造化された結果を取得できます。

回避方法:影響度順のアクションリスト

自己チェックでリスク箇所が分かったら、次はどう回避するかです。重要度順に並べます。

地域が最優先です。 出口が中国本土、またはその他の非対応地域にある場合、これは公式が唯一明言しているレッドラインです。まずここを解決し、対応地域のクリーンな住宅回線からアクセスしてください。

システムのタイムゾーンを変えて、検出リストを避ける——コストが最も低い一手です。 3 つ目の透かしでは、タイムゾーンの次元で読まれるのは IP の位置情報ではなく、あなたのシステムタイムゾーンです。Asia/Shanghai や Asia/Urumqi にいるなら、Asia/Taipei に変更してください。同じ東 8 区なので、表示時刻は北京とまったく同じで、カレンダーや予定も正常に動きますが、検出リストには入っていません。しかも台北は Claude 公式の対応地域内です。シンガポールは選ばないでください——大量の中古アカウントがシンガポールのタイムゾーンを使っており、次に検出拡大の対象になりやすい候補としてかなり目立ちます。Mac では変更後に「プライバシーとセキュリティ → 位置情報サービス → システムサービス」へ行き、「時間帯の設定」をオフにするのを忘れないでください。そうしないと Apple が Wi-Fi 位置情報に基づいて、また上海に戻してしまいます。ターミナルで node -e "console.log(Intl.DateTimeFormat().resolvedOptions().timeZone)" を実行し、Asia/Taipei が返れば完了です。このコマンドこそ Claude Code 内部がタイムゾーンを読むときに使っているものです。この実践手順は @app_sail のアカウント凍結対策ガイド をもとに整理しています。

データセンター、VPN、プロキシ IP から Claude にログインしたり、再認証したりしないでください。 特に初回ログイン、登録、OAuth 認証のやり直しといった操作は、リスク管理が最も敏感になるタイミングです。日常的にクラウドサーバー上で API やコマンドラインを走らせるのは問題ありませんが、認証操作はできるだけクリーンな住宅回線で行ってください。

直結できるなら公式エンドポイントに直結してください。 api.anthropic.comclaude.ai を使い、第三者の中継はなるべく避けます。中継には IP リスクに加えて、先ほど述べた消せない指紋透かしの問題もあります。アカウント凍結リスクを本当に心配しているなら、直結だけが IP と指紋の両方を同時に解決できる方法です。どうしても中継や VPS を使うなら、Alibaba Cloud、Tencent Cloud、Volcengine のような中国大手の海外ノードは避けてください——「米国出口 + 中国大手企業ドメイン」という組み合わせは、むしろ中国本土から直結するよりリスクスコアが高くなる可能性があります。サービス側に「中国ユーザーが海外ノードで回避して使っている」と教えているようなものです。独立ドメインのホスティング事業者、たとえば Hostinger、Vultr、Linode のように、逆引き hostname がクリーンなところを選んでください。

1 つのアカウントは 1 つのクリーンなネットワークに固定してください。 頻繁にネットワークをまたいで切り替えたり、1 台のマシンで複数アカウントを高速にローテーションしたりしないでください。こうした行動パターン自体がリスク管理上のシグナルになります。

定期的に再チェックしてください。 VPN は出口が変わります。住宅 IP は通信事業者に回収され、再割り当てされることがあります。信頼していた中継サービスが、ある日ブラックリスト入りする可能性もあります。今日クリーンだからといって、明日もクリーンとは限りません。

ついでに:使用量を監視するステータスバー

上のものはネットワークを確認するためのものです。もし Claude Code を使っているなら、私がずっとメンテしている小さなツールもあります。上限、コンテキスト、課金ペースをステータスバーで監視できます。

claude-code-usage-bar

これはいくつかのことをしてくれます。5 時間枠と 7 日枠の上限をリアルタイムのプログレスバーで表示し、そのウィンドウ内でおおよそ何パーセントまで消費しそうかも予測します。モデルを切り替えたとき(Sonnet から Fable へ)や、複数 agent を並列で動かしたときも、予測は新しい消費速度にすぐ追従し、遅れません。コンテキストウィンドウ、prompt キャッシュのカウントダウン、このセッションでいくら使ったかまで、1 行で全部見られます。

上で話したアカウント停止検知も組み込まれています。出口 IP にリスクがある場合、ステータスバーに「この IP で Claude にログインしないでください」という赤字警告が直接出ます。中継を使い、中国のタイムゾーンになっている場合は、リクエストにフィンガープリントが付いていることを知らせてくれます。ネットワーク確認のためにわざわざページを開く必要はありません。これが見張ってくれます。

インストールは 1 行です。

uv tool install claude-statusbar

または pipx install claude-statusbar、あるいは pip install -U claude-statusbar でも構いません。インストール後は、Claude Code のステータスバー設定でそこを指定すれば完了です。

最後に

アカウント停止という話も、分解して見ればそこまで謎めいたものではありません。地域は公式のレッドライン、IP 種別は事業者がかなり正確に測定できる信用度、リクエストフィンガープリントは中継を通すと避けられない目印です。この 3 つはそれぞれ独立しており、どれか 1 つだけでも引っかかる可能性がありますが、それぞれに対策もあります。

いちばん手間がかからない方法は、常に公式へ直結し、クリーンな住宅回線を使うことです。これで 3 つの観点を一度に解決できます。それができない場合でも、まずは 10 秒だけ使って ip-check.leeguoo.com を開き、自分が今どこに立っているのか確認してください。

ツールはすべて無料で、ソースコードも公開されています。問題があれば、ぜひ Issue を送ってください。

← 前の記事
微信ローカルデータの二つの道——wechat-use と wechat-decrypt の原理レベルの比較(実測による訂正付き)
次の記事 →
chrome-useのマルチエージェント隔離

コメント

コメントは即時公開されますが、ポリシー違反時は非表示になる場合があります。

最大 1000 文字。