Cookieを削除し、IPを変え、OSを再インストールし、シークレットモードを使っても、アカウントが関連付けられることがあります。リスク管理は一つのスイッチではなく、登録期・活動期・異常期ごとに異なるシグナルを収集し、中心的には行動が人間らしいかを判断します。本記事では3段階に分けて整理します。
Cookieを削除し、IPを変更し、OSを再インストールし、シークレットモードまで使っても、アカウントが関連付けられることがあります。理由は単純です。リスク管理は一つのスイッチではありません。段階ごとに異なるシグナルを収集し、最終的にはそのアカウントの行動が人間らしいかどうかを見ています。
プロセスは、登録した瞬間、コンテンツ活動が始まった後、異常が発生したとき、という3つに分けると理解しやすくなります。
登録期：ほとんど操作する前にシグナルは収集されている
登録時にプラットフォームが取得できる情報は、多くの人が想像するより多岐にわたります。デバイス側では、Canvasレンダリングによるピクセル差、AudioContextの波形差、WebGLが返すGPUベンダーとモデルなどのハードウェア・環境特性に加え、User-Agent、WebRTCがプロキシを迂回して実アドレスを露出していないか、タイムゾーン、言語などを見ます。ネットワーク側では、IPがデータセンター系か住宅回線か、そのリスクスコア、さらに同じIP帯に多数のアカウントが集中していないかを確認します。
行動面も見られますが、見落とされがちです。フォーム入力の速さ、フィールドを修正した痕跡、どの認証経路を通ったかなどです。すべてが不自然なほど速ければ、それ自体がシグナルになります。
登録期の対応は通常、直接拒否、利用は許可するが静かにリーチを下げる、または追加認証を求める、の3種類です。
ここで最も見落とされやすいのは一貫性です。IPの所在地、ブラウザのタイムゾーンと言語、入力した主体住所のどれかが一致しなければ、高度な検知手法がなくても分かります。地理的な論理矛盾は、最も低コストで見つけられる綻びの一つです。
活動期：コンテンツとインタラクションのパターン
登録を通過すると、判断基準は「誰が登録しているか」から「このアカウントが何をしているか」へ移ります。
コンテンツ側で主に見られるのは重複度です。複数アカウントが非常によく似た素材を一括投稿し、文面にも差別化がない場合、協調した自動運用と判定されやすくなります。その結果、単一アカウントだけではなく、グループ全体の配信が抑えられることがあります。
インタラクション側では分布が見られます。フォロー、いいね、DMの頻度、1日のどの時間帯に集中しているか、相手がどの程度重複しているかです。実ユーザーの行動は分散しやすい一方、スクリプトの行動は集中しやすい傾向があります。複数アカウントのインタラクション曲線がよく似ていると、関連付け判定が機能する可能性があります。
アセットを有効化するペースも観察対象です。日常的な閲覧や検索がまったくない新規アカウントが、すぐにビジネスツールを有効化し、カードを登録して広告を出すのは、リスクモデルで典型的なパターンです。
この段階の対応は登録期より軽いことが一般的で、リーチ制限、推薦順位の低下、認証要求、一部ビジネス機能の制限などがあります。処罰というより評価引き下げに近いものですが、同じパターンが続けば次の段階へエスカレートします。
異常期：ログイン地点や頻度が急に変わる
異常判定を引き起こすシグナルのうち、典型的なものは2種類あります。
一つはログイン地点の急変です。同じアカウントが短時間で別の都市へ移動した場合、たとえば5分以内にロサンゼルスからニューヨークへ移った場合、人間の移動速度には限界があるため、システムはまずアカウント乗っ取りの可能性を疑います。チームの複数メンバーが離れた場所から同じアカウントにログインする場合も、この条件に触れることがあります。
もう一つは頻度の偏りです。もともと低頻度だったアカウントが突然大量の操作を行ったり、複数アカウントが同じ時間帯に同じ操作をしたりすると、判定が強まる可能性があります。
この段階の対応は最も重く、保護目的の停止、本人確認や顔認証を求めるロック、関連アカウントへの連動措置などがあります。同一IP帯や同じデバイス特性を持つ他のアカウントも一緒に制限される可能性があります。ここまで来ると、単一アカウントの問題ではなく、環境チェーン全体の問題であることが多くなります。
特徴を消し切るより「人間らしさ」が有効な理由
直感に反する点があります。プラットフォームが見ているのは、単にフィンガープリントがあるかどうかではなく、特徴同士に矛盾や欠落がないかです。フィンガープリントの欠如や、明らかに改変されたパラメータそのものが異常シグナルになり、一般的な実データの組み合わせより不自然に見えることがあります。
そのため、方向性は「見えなくする」ことではなく「整合させる」ことです。
デバイス面では、各アカウントに安定したハードウェア・環境特性のセットが必要で、乱雑さが増えるほど良いわけではありません。ネットワーク面では、頻繁にノードを切り替えるより、一つの固定出口に長く紐づける方が安全です。環境面では、タイムゾーン、言語、地理位置をIPとセットで一致させ、個別にバラバラに変更しないことが重要です。たとえばUser-AgentはあるOSを名乗っているのに、低レベルのWebGLでは別構成のGPU情報が返る状態は、変更しすぎの典型です。
行動面も同じです。実際のユーザーのマウス軌跡には揺らぎがあり、スクロール速度は一定ではなく、滞在時間も大きく変わり、ときには非効率な経路を取ります。自動化にランダムな遅延を入れ、順序を変え、ときどき意味のないクリックを許す方が、ミリ秒単位の安定性を追求するより自然に見えることがあります。
3段階の判定は段階的に進み、対応も認証、評価低下、流量制限、停止というように強くなり、それぞれシグナルの強さに対応します。アカウントが制限された場合、単に運が悪かったのではなく、前段階のどこかで矛盾が出ていたことを示す場合が多いです。
3つしかできないなら、この順番
まず地理的一貫性を整えます。IP、タイムゾーン、言語を一つのセットとして一致させることが、最も低コストで効果が高い手順です。次に環境の独立性を確保し、1アカウントにつき1環境として共有しないようにします。行動ペースの調整は最後に行い、低頻度から始めて自然な揺らぎを許容します。
PurpleMarkの環境分離機能は、この中間のステップに対応します。アカウントごとに独立したブラウザ環境を設定し、フィンガープリントの独立性と環境パラメータの整合性を保ち、バッチ管理にも対応します。
順番を逆にすると効果は大きく落ちます。行動レイヤーをどれだけ自然にしても、環境レイヤーに矛盾があれば検知される可能性があります。
本文は技術的な仕組みの説明のみを目的としています。関連ツールは法令・規則を守って使用し、各プラットフォームの利用規約に従ってください。
