ブログ・ 2026年8月4日

ブロックリスト伝播：一つの不正利用事例でネットワーク全体を無力化する (JA)

アカウントを禁止することは、ヒドラから一つの頭を取り除くことに過ぎません。しかし、セッションからブロックリストを作成すると、顔、ドキュメント、電話番号、メールアドレス、IPアドレス、デバイスなど、そのセッションが接触したすべての識別子が12種類の入力タイプにわたって自動抽出されます。これにより、次のアカウントは入り口で拒否されます。.

By Didit2026年8月4日更新日 2026年8月4日

ほとんどの不正対策プログラムが価値を失う特定の瞬間があります。それは、あなたが勝利した後の瞬間です。

トラフィック層がアカウントにフラグを立てます。アナリストが調査します。証拠は確実で、ケースは確認され、アカウントは禁止されます。しかし、数時間後には、同じオペレーターが新しいアカウントで戻ってきます。なぜなら、あなたの対策が触れたのはユーザーテーブルの1行だけだったからです。

Anthropicは、2026年2月の蒸留キャンペーンに関するレポートで、このダイナミクスを正確に記述しています。このプロキシネットワークは、「2万以上の不正アカウントを同時に管理」し、削除されるとすぐに置き換えました。削除がボトルネックではありませんでした。再生は削除よりも安価だったのです。

この問題を解決するには、対策をアカウントではなく識別子に対して行うことです。DiditのLists APIは、これを単一の呼び出しで行うメカニズムを中心に構築されています。

主なポイント

reference_session_id を使用したブロックリスト作成により、Diditはセッションから適切な値（顔、ドキュメント、電話番号、メールアドレス、IPアドレス、デバイスなど）を自動抽出し、基になるモデルをブロックリストに登録済みとしてマークし、そのエントリを元のセッションにリンクします。
12種類の入力タイプ： face、document、phone、email、ip_address、device_fingerprint、wallet_address、bank_account、user、business、country、key。
ブロックリストはシステムによって作成され、エントリタイプごとに1つずつ存在し、不変です。これらを作成することはできません。これにより、対策の均一性が保たれます。
エントリは検証時に即座に有効になります。エントリを削除すると、一致するものがブロック解除されます。
ip_address はCIDR範囲を受け入れるため、単一のアドレスではなくインフラ全体をブロックリストに登録できます。
同じ12種類のタイプにわたる許可リストは、信頼できる開発者をすべてのエスカレーションパスから除外します。

重要な2つのリストタイプ

APIには3つのリストタイプがあり、その区別は意図的なものです。

ブロックリストはシステムによって作成され、エントリタイプごとに1つずつ存在し、不変です。これらを作成したり、名前を変更したり、削除したりすることはできません。エントリの追加と削除のみが可能です。この制約は機能です。これにより、「ブロックリストに登録済み」が組織全体で正確に1つの意味を持つようになり、異なるサービスが矛盾した方法でチェックする4つの競合する顔ブロックリストに陥ることはありません。

許可リストは自由に作成できます。既知の良好なデバイス、アドレス範囲、事業体、ユーザーがここに入ります。

カスタムリストは、それ以外のすべてのもの（独自の分類、監視グループ、レビューコホートなど）に使用されます。

# 顔ブロックリストを検索
curl -X GET 'https://verification.didit.me/v3/lists/?list_type=blocklist&entry_type=face' \
  -H 'x-api-key: YOUR_API_KEY'

重要なメカニズム

ブロックリストに何かを追加する一般的な方法は次のとおりですが、ほとんどすべての実際の状況でこれは間違った方法です。

curl -X POST 'https://verification.didit.me/v3/lists/{list_uuid}/entries/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{ "value": "203.0.113.44" }'

これは1つのアドレスをブロックリストに登録します。一方、調査していたセッションには、顔、ドキュメント番号、電話番号、メールアドレス、デバイスフィンガープリントも含まれていました。これらはすべて、オペレーターが戻る前に置き換えなければならない識別子です。

より良い呼び出し方法：

curl -X POST 'https://verification.didit.me/v3/lists/{list_uuid}/entries/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{ "reference_session_id": "a7f3...c19" }'

reference_session_id を渡すと、Diditはセッションからそのリストのエントリタイプに適した値を自動抽出し、基になるモデルをブロックリストに登録済みとしてマークし、エントリをセッションにリンクして、コンソールでどこから来たかを表示できるようにします。

これには3つの結果があり、そのすべてが運用上重要です。

手動抽出なし。 アナリストが画面からデバイスフィンガープリントを読み取って再入力することはありません。対策データにおける転記エラーはサイレントな失敗であり、禁止が発動せず、誰も気づきません。

出所が保持されます。 すべてのエントリは、それを正当化したセッションにリンクされます。4か月後にこのデバイスがブロックされた理由を誰かが尋ねた場合、答えはワンクリックで得られ、考古学的な調査は不要です。

対策は繰り返し可能です。 各エントリタイプのブロックリストに対する同じ呼び出しは、セッションの全識別子表面をカバーします。

セッションに同じタイプの複数のインスタンスが含まれている場合は、曖昧さを解消するために reference_session_id とともに value を渡します。

検証セッション外から対策を講じることもできます。reference_object_uuid と metadata.reference_type — transaction、vendor_user、または vendor_business — を組み合わせることで、トランザクション、ベンダーユーザー、またはベンダービジネスからブロックリストに登録し、元のソースへの同じリンクを保持します。

12種類の入力タイプ

入力タイプ	ブロック対象	備考
`face`	人物	顔アップロード経由で直接ロード可能
`document`	認証情報
`phone`	電話番号	E.164に自動正規化
`email`	メールアドレス
`ip_address`	IPアドレスまたは範囲	CIDRを受け入れます（例: `10.0.0.0/8`）
`device_fingerprint`	マシン	最低8文字の英数字
`wallet_address`	オンチェーンアドレス
`bank_account`	銀行口座
`user`	ユーザーレコード
`business`	事業体
`country`	管轄区域
`key`	カスタムキー

この問題に関して、2つについて言及する価値があります。

ip_address はCIDR範囲を受け入れます。 203.0.113.0/24 をブロックリストに登録すると、1つのアドレスではなくインフラ全体がブロックされます。ファーミング操作がレンタルされたサブネットで実行されている場合、これは、スケールする対策とモグラたたきのような対策の違いです。慎重に使用してください。範囲は実際のユーザーもカバーしており、広すぎる範囲は国のモバイルキャリアを静かに禁止する方法です。

face は直接アップロードをサポートしています。 画像はあるがセッションがない場合、直接ロードします。

curl -X POST 'https://verification.didit.me/v3/lists/{list_uuid}/entries/face-upload/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{ "image": "<base64-encoded image>" }'

Diditは生体情報を抽出します。それ以降、その顔はすべての検証でスクリーニングされます。

エントリが登録された後に何が起こるか

システムブロックリストへの追加は、検証時に将来の一致を即座にブロックします。伝播遅延やバッチ処理はありません。

次の検証では、警告として対策が表示されます。

FACE_IN_BLOCKLIST — 確定的な一致。検証は拒否されます。POSSIBLE_FACE_IN_BLOCKLIST は、ハードな閾値を下回る境界線上のマッチであり、拒否ではなくレビューに回すべきです。
IP_ADDRESS_IN_BLOCKLIST / DEVICE_FINGERPRINT_IN_BLOCKLIST — ネットワークおよびデバイスの一致。

顔検索では、ブロックリストの一致のみが status を "Declined" に設定します。応答内のすべての一致には is_blocklisted も含まれるため、調査により、クラスターのどの部分がすでに強制されているか、どの部分がまだ有効であるかがすぐにわかります。

削除は対称的です。エントリを削除すると、一致するエンティティのブロックが解除されます。対策は意図的に元に戻せるように設計されており、広すぎる対策は実際のリスクであるため、クリーンな経路に戻すことが重要です。

curl -X DELETE 'https://verification.didit.me/v3/lists/{list_uuid}/entries/{entry_uuid}/' \
  -H 'x-api-key: YOUR_API_KEY'

許可リスト：必要な開発者を保護する

エスカレートするだけの対策は、最終的に製品を締め付けてしまいます。同じ12種類の入力タイプが許可リストをサポートしており、これらが圧力弁となります。

デザインパートナーのオフィスIP範囲を許可リストに登録します。エンタープライズ顧客のエンジニアリングチームのデバイスを許可リストに登録します。検証済みの事業体を許可リストに登録することで、そのユーザーはエスカレーションパスに入ることはありません。IP_ADDRESS_IN_ALLOWLIST および DEVICE_FINGERPRINT_IN_ALLOWLIST は一致が発生したときに発動するため、免除が適用されたことを仮定するのではなく確認できます。

これは、積極的な対策を存続させるメカニズムです。既知の良好なユーザー層が明示的に除外されているからこそ、未知のインフラストラクチャに対して厳格なポリシーを設定できます。

対処すべきエラー

400 — 値がエントリタイプのバリデーターに失敗した、操作に対して list_type が間違っている（例：顔以外のリストに対する顔アップロード）、または reference_session_id に要求されたタイプのデータがない。最後のケースは一般的で無害です。すべてのセッションがすべての識別子をキャプチャするわけではありません。
403 — {"detail": "このアクションを実行する権限がありません。"}

「セッションにそのタイプのデータがない」という400エラーは、すべてのエントリタイプブロックリストにわたってセッションをループするときに予想されます。これを失敗ではなくスキップとして処理してください。

対策フローの例

アナリストがアカウント acct_8842 で不正利用を確認しました。

まずクラスターを解決します。 セッションの顔に対する顔検索は12のアカウントを返します。デバイスとIPの関連付けはさらに数十のアカウントを引き込みます。解決前の対策は1つのアカウントを禁止し、オペレーターに警告するだけです。
確認されたセッションからブロックリストを作成します — 顔、デバイス、IP、メール、電話、ドキュメントのブロックリストに対して reference_session_id を使用します。6回の呼び出しで、手動抽出なし、完全な出所が確保されます。
範囲を検討します。 ネットワークの証拠がレンタルされたインフラストラクチャを指している場合、CIDRエントリがサブネットをカバーします。まず、そこに他に何があるかを確認してください。
自身のポリシーに従ってクラスターに対して行動します — すでに特定したアカウントは自動的にブロック解除されません。
対策を検証します。 顔検索を再実行します。一致には is_blocklisted: true が含まれるはずです。
再生成の試みを待ちます。 その顔、デバイス、またはサブネットで作成された次のアカウントは、3週間後にトラフィックに表示されるのではなく、検証時に拒否されます。

ステップ6が最も重要な点です。オペレーターが戻るためのコストは、「新しいメールアドレスを作成する」ことではなくなりました。「新しいハードウェア、新しいネットワーク、そして新しい人物を獲得する」ことになります。

ユースケース

AI APIプラットフォームが、確認された蒸留または不正利用のケースを、オペレーターが接触したすべての識別子に対する対策に変換します。

新しい無料割り当てのために同じデバイスと顔が繰り返し戻ってくるトライアルおよびクレジットの不正利用。

削除された販売者が新しいビジネスで再登録するのをブロックするマーケットプレイス。

自主排除を強制するiGaming。排除されたプレイヤーが戻ってくることは規制上の失敗であり、顔レベルの対策が唯一の信頼できる制御です。

よくある質問

独自のブロックリストを作成できますか？

いいえ。ブロックリストはシステムによって作成され、エントリタイプごとに1つずつ存在し、不変です。エントリの追加と削除のみが可能です。許可リストとカスタムリストは自由に作成できます。この制約により、「ブロックリストに登録済み」がどこでも1つの意味を持つようになります。

エントリはどれくらいの速さで有効になりますか？

次の検証時に即座に有効になります。

誤ってブロックリストに登録してしまった場合はどうなりますか？

エントリを削除すると、エンティティのブロックが解除されます。これが、出所が重要である理由です。セッションから作成されたすべてのエントリはそれにリンクされているため、削除する前にエントリが何のためであったかを監査できます。

IP範囲をブロックリストに登録すると、その範囲の正当なユーザーに影響しますか？

はい、それがリスクです。CIDRエントリは、その中のすべてをブロックします。証拠が専用のインフラストラクチャを指している場合は範囲を使用し、それ以外の場合は単一のアドレスを使用し、既知の良好な範囲を最初に許可リストに登録してください。

検証セッションではないものからブロックリストに登録できますか？

はい。reference_object_uuid と metadata.reference_type（transaction、vendor_user、または vendor_business）を組み合わせることで、トランザクション、ベンダーユーザー、またはベンダービジネスをカバーします。

これはモデル抽出を阻止しますか？

いいえ。これは、特定の既知のアクターが、あなたが対策を講じた識別子を通じて再侵入するのを阻止し、再生成のコストを上げます。そもそも抽出を検出するのはあなたのトラフィック層の仕事であり、抽出がもたらすものを制限するのはあなたのモデル層の仕事です。これは3層防御の対策アームであり、他の2つの代替ではありません。

始めませんか？

Lists APIはすべてのDiditアカウントで利用できます。

ドキュメントを読む — Lists APIの概要とIP & デバイス警告カタログ。
製品を見る — ユーザー認証。
料金を確認する — 公開されている料金、成功時課金、最低料金なし。
無料で始める — business.didit.me、毎月500回のKYC検証が無料。