ChatGPTアカウントのリスク管理ではログイン環境の一貫性が重要

アカウントで認証を求められたり一時的な制限がかかったりすると、多くの人はまず利用頻度が高すぎた、あるいはIPが十分にクリーンではなかったと考えます。頻度やIPも影響しますが、より一般的な原因はログイン環境が変化していることです。

プラットフォームが見ているのは1つのIPではなくアクセスの軌跡

リスク管理では、特定のアドレスがクリーンかどうかだけを見ているわけではありません。ログイン環境全体が時間を通じて一貫しているかも確認されます。IPのほか、ASNのネットワーク所属、地理的位置、利用端末、TLSやHTTPレイヤーのフィンガープリント特性なども含まれます。長期間にわたって通常利用されているアカウントでは、これらの情報が比較的安定したアクセス軌跡を形成し、プラットフォームはその軌跡をもとに基本的な信頼を構築します。

ここからもう1つ分かることがあります。Cookiesを削除しても、別の身元になるわけではありません。端末識別には、Canvas、WebGL、User-Agent、OSなどの要素で構成されるブラウザフィンガープリントが使われます。Cookiesはその一層にすぎません。異常があったからといってCacheを削除しても、実際にはほとんど何も変わらないことがあります。

同じアカウントで接続元や端末を変えると何が見えるか

• 接続元の国を変更する: 午前中は国内ネットワーク、午後は海外ノードを使うと、プラットフォームからは同じアカウントが2つの地理的位置で活動しているように見えます。再ログインを求めたり、メールや携帯電話へ認証コードを送ったりするのが一般的で、深刻な場合は一時的にアクセスを制限されることがあります
• 複数端末で同時ログインする: 同じアカウントを複数端末で並行利用し、異なる場所からのリクエストが時間的に重なって同時セッションが発生します
• ブラウザを変える、またはOSを再インストールする: 端末パラメータがまとめて変わるため、一貫したプロファイルを構築しにくくなり、かえって認証が増えることがあります
• 環境と接続元が一致しない: IPは米国なのにタイムゾーンはローカルのまま、UI言語も中国語のままといった矛盾は、高度な検出を使わなくても見つけられます

なぜこれらがリスクとして扱われるのか

リスク管理が答えようとしている問いはとても単純です。通常の人が1つのアカウントを安定して使っているように見えるかどうかです。環境の断絶、身元の交差、不自然な利用ペースがあると判断の確度が下がり、その結果として認証や制限が発生します。

特に身元の交差は個別に考える価値があります。複数のアカウントが長期にわたって同じブラウザ環境を共有している場合、ログアウトしても終了するのはアカウントセッションだけで、ブラウザ環境自体は分離されません。フィンガープリント、Cache、端末パラメータが大きく重なるため、アカウント同士に関連性を示す特徴が生まれます。そのうち1つが監視対象になると、ほかのアカウントでも追加認証を求められる可能性があります。

見落とされやすいもう1つのケースは、利用履歴がほとんどないアカウントです。新規アカウントは信頼モデル上の重みが低いため、登録直後から連続してコンテンツを生成し、大量の呼び出しを行い、複数端末で同時ログインすると、監視対象になりやすくなります。しばらく通常のペースで利用し、履歴を少しずつ積み上げるほうが、どんな小手先の方法より有効です。

また、アカウント共有そのものが多くのサービスの利用規約に反します。見つかりにくい共有方法を考えるより、利用者ごとに個別のサブスクリプションを用意するほうが適切です。

環境を安定させる方法

目的はパラメータを特殊にすることではなく、同じアカウントを長期にわたって同じ環境で使い続けることです。次の順序で整えることができます。

• 1つのブラウザ環境を固定し、同じ接続元グループに紐付けて、ログイン経路が長期間にわたり同じネットワークと端末構成に収まるようにします。ネットワークを調整する必要がある場合は接続元アドレスだけを変え、同時にブラウザパラメータまで変えないことで、1回の変更で動く変数を減らします
• タイムゾーン、言語、画面解像度、WebRTC、DNSを1セットのパラメータとして固定して長期利用します。接続元の地域とセットで整合させ、手動で何度も変更しないようにします
• 1アカウントにつき1つの独立環境を使い、Cookies、Cache、ローカルストレージ構造を共有しません。さらに用途ごとにコンテナを分け、コンテンツ用、広告用、サポート用のアカウントをそれぞれ別の経路にします
• 接続元はできる限り同じ地域または同じASNに保ち、国をまたぐ頻繁な移動を避けます。アカウント数が増えたら、アカウントと環境、接続元の対応関係を固定し、一時的なログインや環境間の切り替えを減らします
• ローカルデータは環境全体と一緒に移動させます。端末変更や引き継ぎの際は環境データ一式を移行し、問題が起きたらすべてを再インストールするのではなく、直近の安定状態へ戻します

環境が増えると、対応関係を人の記憶だけで管理するのはミスにつながりやすくなります。PurpleMarkのようなツールは、各アカウントをそれぞれ独立した環境と接続元に固定し、環境同士でデータを共有しないようにすることで、アカウントのアイデンティティ層を安定させるためのものです。

すでに制限されている場合

まず制限の種類を見分けます。一時的な制限は待機や認証完了で復旧できることが多い一方、BANの場合は異議申し立てが必要で、対応方法は異なります。

環境に問題がある場合は、異議申し立ての前にその問題を解消します。そうしないと、復旧後に同じ問題が再発する可能性が高くなります。異議申し立ては公式の案内に従い、状況を明確に説明し、短時間に繰り返し送信しないようにします。また、制限中に同じ環境を使って新規アカウントを登録しないほうがよいでしょう。新しいアカウントにも関連性を示す特徴が引き継がれる可能性があります。

結局のところ、リスク管理が見ているのは安定性と一貫性です。固定したログイン環境、地域に合った一連のパラメータ、通常の利用ペースを保つことで、ほとんどのリスク管理上の問題を避けやすくなります。