アカウントが高リスクと判定される原因は、通常ひとつの操作だけではありません。プラットフォームは、アカウント情報、ログイン・端末環境、操作行動、取引履歴など複数のシグナルを組み合わせて評価します。本記事では、リスクスコアを悪化させる要因、先に現れやすい兆候、確認すべき順序を整理します。
越境ビジネスや海外向けSNS運用では、いきなりアカウント停止になるよりも、アカウント自体は残っているのに、プラットフォームから高リスクと評価され続ける状態のほうがよく見られます。ログインのたびに何度も確認を求められ、一部機能が使えず、注文や決済処理が止まり、それでもどこで問題が起きたのか分からないという状態です。
こうした状況が単一の原因で起こることは多くありません。プラットフォームは複数種類のシグナルを重ねて評価するため、確認もレイヤーごとに進める必要があります。
スコアは複数のシグナルから作られる
プラットフォームは、ひとつのルールだけでアカウントの信頼性を判断するわけではありません。異なる情報源から得たシグナルを組み合わせ、リスク値を推定します。大きく分けると次の4種類です。
- アカウント情報：登録情報が完全か、他のアカウントと重複していないか、紐付けたメールアドレス、電話番号、受取・支払い情報に共通点がないか。
- ログイン・端末環境：出口IPの履歴、IPが示す地域とアカウント所在地が整合しているか、同じブラウザ環境が複数アカウントで再利用されていないか。
- 操作行動：ログイン頻度、操作時間の分布、インタラクションのリズムが人間らしくないほど規則的ではないか。
- 取引・アフター対応：支払い方法がルールに適合しているか、返金、紛争、購入者からの苦情が適切に処理されているか。
どれか一つのカテゴリで明確な異常があるだけでも、評価が悪化する可能性があります。出口を変更してもアカウントが引き続きフラグされるのは、問題がネットワークではなく、アカウント情報や環境レイヤーにある場合があるためです。
スコアを悪化させる行動
まず出口側を見ます。プロキシIPそのものは中立的なネットワークツールであり、リスクは使い方から生じます。同じIPが複数アカウントの作成、異常なログイン試行の繰り返し、その他利用規約に反する活動に頻繁に使われると、そのIPと関連行動が不審と判断される可能性があります。リスク管理は、そのIPに紐づくアカウントにも及ぶことがあります。
よくある三つのパターンは評価を下げやすい要因です。一つ目は、短時間に出口を何度も切り替えることです。通常のユーザーが頻繁に行う動きではありません。二つ目は、安価で共有度の高いプロキシを使うことです。こうしたIPは多数の利用者に使われ、すでに各種ブロックリストに入っている場合があり、他人の履歴まで引き継ぐ形になります。三つ目は、同じ出口を高頻度アクセスや大量スクレイピングに使うことです。IP帯全体がブロックされると、その出口を共有しているアカウントがまとめて影響を受ける可能性があります。
ブラウザ側の問題はさらに見えにくくなります。ブラウザ設定、拡張機能情報、Cookieは組み合わさってフィンガープリントを形成し、プラットフォームはそれを使って操作が実在のユーザーによるものか、複数アカウントが同一人物に由来する可能性があるかを判断します。問題はフィンガープリント自体ではなく、そこから生まれる関連付けです。同じ端末・同じブラウザで複数アカウントに順番にログインすると、特徴がほぼ同一になるため、同一由来と判断されるのを避けにくくなります。キャッシュ削除やシークレットモードでは解決しません。フィンガープリントはハードウェアとソフトウェア情報に基づき比較的安定しており、シークレットモードは主にローカル履歴を残さないためのものです。
スコアが悪いときに先に現れるもの
多くのプラットフォームは段階的に対応します。リスク評価が高いからといって、通常はいきなり停止されるわけではありません。まず追加確認、一部機能の制限、注文や決済の保留、追加資料の提出要求などが出ることがあります。こうした制限が出た時点で、アカウントはすでに重点監視の対象になっていると考えられますが、まだ最終措置には至っていない状態です。
その後に停止が行われ、関連アカウントも同時に処理されることがあります。確認回数が増える、決済が遅くなるといった初期サインが見えた時点で環境を見直し、停止通知が来るまで待たないことが重要です。
確認する順序
制限や措置の通知を受けたら、次の順序で確認できます。まず通知の性質を見ます。ネットワークやログイン場所に関する内容なら出口レイヤーを優先し、複数アカウントや同一端末に関する内容なら環境レイヤーを優先します。次に、現在の出口がブロックリストに入っていないか、履歴に問題がないかを確認します。その後、各アカウント環境のタイムゾーン、言語、解像度、UAパラメータを横並びで比較し、重複が多ければそこから修正します。最後に、ログイン頻度と操作時間の分布を見直し、不自然なほど規則的ではないか確認します。
環境レイヤーの関連付けリスクを抑えるには、各アカウントに独立し、かつ内部整合性のある環境を持たせます。Cookie、キャッシュ、ローカルストレージ、拡張機能を共有せず、フィンガープリントの各パラメータを個別に設定して出口地域と整合させ、出口も分けます。アカウントが10個を超えると、手作業での維持はミスが起きやすくなります。PurpleMarkのようなマルチアカウント環境ツールでは、プロキシ、スタートページ、フィンガープリントパラメータを環境に紐付けます。1環境を1アカウントに対応させることで、環境を切り替えると設定一式も切り替わります。
ただし境界は明確です。環境分離が扱うのは技術的な干渉や関連付けであり、プラットフォームがアカウントの本人性や許容数を判断するルールそのものを変えるものではありません。
よくある質問
スコアは回復しますか？ プラットフォームの仕組みによります。一般的には、一定期間、安定してルールに沿った操作を続け、同じシグナルを再び発生させないことが必要です。
静的な出口と動的な出口ではどちらが安全ですか？ 絶対的な答えはありません。主要アカウントには、地域と整合した安定した出口のほうが向いています。地域テスト用のアカウントではローテーション出口も使えますが、頻繁な切り替えは避けるべきです。
環境レイヤーだけ対処すれば十分ですか？ 十分ではありません。出口レイヤーと環境レイヤーを合わせて確認し、どちらもプラットフォームのルールに従う必要があります。アカウント情報と取引のコンプライアンスも評価の一部です。
