referral-abuse-guardrails

紹介プログラム不正利用のガードレール

顧客が友達紹介プログラムを不正に利用するのを防ぐガードレールを定義し、しきい値、検証ゲート、報酬保留ポリシー、段階的な適用措置、監視シグナルを含むガードレール仕様として提示します。このスキルは、既存の報酬体系を守るものであり、報酬体系を再設計することはありません。

消費者向け紹介プログラムの不正利用を対象とする、公認された標準はありません。借用するのは次の4つだけです。それ以上は借用せず、コンプライアンス上の主張としてではなく、思考モデルとしてのみ使用します。

• GIVT/SIVTの考え方（広告測定の標準）：低コストの決定論的な段階と、コストは高いものの裏付けとなる段階。
• OWASP OAT-019 Account Creation：自動化された部分のみ。
• Trust and Safetyの適用措置に関する原則：段階的な適用措置のセクションにおける、比例性、一貫性、透明性。
• シビル攻撃の結果を戦略的な枠組みとして使用します。中央のID機関なしに偽のIDを完全に検知することはできないため、どのガードレールも実際には不正利用者に課すコストとなります。

目的は不正利用をすべて見つけ出すことではなく、割に合わなくすることです。

基本ルール

• 厳密に防御に徹してください。不正利用のパターンは、防御側が認識して阻止するのに必要な深さまでだけ説明します。プログラムデータで観測可能な兆候を示し、回避手法、ツール、悪用の手順は説明しません。
• 数値しきい値にはすべて、その根拠を明記してください。根拠は、公開済みのプログラム規約、学術的な結果、ベンダーの経験則、またはユーザーが自社データから導き出したベースラインのいずれかです。ベンダーのヒューリスティックを業界共通の定数として提示しないでください。
• 広まっている次の2つの数値には注意を促してください。「紹介詐欺は、すべてのEコマース詐欺の21%を占める」はベンダー間の相互引用による循環引用であり、「誤検知による拒否は4430億ドル、詐欺は480億ドル」という数値には、検証可能な精度がありません。これらの数値は使わず、仕組みを示してください。すなわち、誤検知は顧客生涯価値の損失を伴うため、詐欺よりもコストが高くなります。
• 本物の不正利用者と、積極的にお得な条件を探す利用者を区別してください。前者には段階的な適用措置を行い、後者にはルールの調整で対応します。後者は、多くの場合、継続利用してもらう価値があります。
• 紹介が行われる前にプログラム規約で公開されていないルールは、その紹介に対して適用できません。ルールはすべて、公開方法と合わせて設計してください。

ヒアリング

何かを設計する前に質問してください。1回のメッセージにつき質問は1つにし、可能な場合は選択式にしてください。すでに回答されている質問は省略します。

• 現在のプログラムの仕組みと報酬体系を教えてください。紹介者と被紹介者のどちらに報酬があるか、各側の報酬の種類と価値、支払いのトリガーは何ですか？
• B2B、B2C、または両方ですか？
• ユーザーアカウントとIDのモデルはどのようなものですか？メールアドレスのみで登録しますか？電話番号は使いますか？条件を満たすイベントの前に支払い手段を登録しますか？
• 現在利用できる検証機能は何ですか（メール確認、SMS、使い捨てドメインのブロック、デバイスシグナル、請求関連のWebhookなど）？
• 実際に照会できるデータは何ですか？紹介イベント、登録時のメタデータ、支払い記録、返金・チャージバック記録、コホート別の継続率などですか？
• これまでにどのような不正利用があり、どのように発覚しましたか？
• リスクにさらされる報酬の価値はいくらですか？報酬1件あたり、およびプログラム全体で1か月あたりの金額を教えてください。
• 対象となる購入の返金またはチャージバックの対象期間はどのくらいですか？
• 摩擦と不正利用の見逃しについて、どの程度まで許容できますか？不正利用者に何人か余分に支払うのと、正当な紹介をいくつか失うのとでは、どちらを選びますか？
• 現在、プログラム規約は公開されていますか？上限、適格条件、報酬の拒否について、すでにどのような定めがありますか？
• ガードレールをいつまでに稼働させる必要がありますか？プログラムの再開、取締役会のレビュー、またはすでに損失が発生しているインシデントへの対応ですか？
• すでに確認されている不正利用に対する一度限りの修正が必要ですか、それともプログラムの拡大後も効果が続く、強化される管理策のセットが必要ですか？
• 労力の上限はどのくらいですか？今期に割けるエンジニアリングの時間、レビュー担当者の人数、および条件となるイベントを変更できるかどうかを教えてください。

最後の3つの質問は、ワークフローのステップ4における管理策の優先順位を決めます。設計に入る前に質問してください。ステップ4まで進むと、読者はすでに方針を決めているからです。

ワークフロー

1. インタビューを実施し、仕様が依存する回答をすべて収集します。

2. スコープの境界を確認します。報酬体系（片側か両側か、種類、金額、発生条件）は既定のものです。それ自体が問題であれば、その旨を伝え、mbfinotti/partnerships-skills@referral-incentive-design に案内します（「参考資料」を参照）。

3. references/abuse-patterns.md をもとにプログラムの不正利用の対象範囲を整理し、報酬額、本人確認モデル、対象イベントによって、どのパターンが実際に起こり得るかを確認します。

4. references/guardrail-mechanics.md を使って対策の優先順位を検討します。6 つの対策で、同じ作業時間を取り合います。

   • イベント：対象イベントの設計。
   • 上限：予算上限、利用頻度の制限、クールダウン。
   • 保留：報酬の保留期間。
   • 適格性：履歴を考慮するルール。
   • 検証：ゲート。
   • レビュー：手動レビュー。

   ベンダーのブログではこの順序が逆になっており、検知ツールが最初、プログラム設計が最後に提示されています。以下のように順位付けします。

   • 効率性：event > caps == hold > eligibility > verification > review
   • 効果：event > eligibility > hold > verification > caps > review
   • 工数：review > verification > event > eligibility > caps == hold
   • コンプライアンスコスト：verification > eligibility > event == caps == hold > review

   上限と保留が同順位なのは、どちらも規約に明記する報酬側の数値で、設定変更 1 回で導入でき、正当なユーザーを制限しないうえ、もう一方では抑えられない損失をそれぞれ抑制できるためです。上限は件数を、保留は取り消しを制限します。コンプライアンスコストでは、イベント、上限、保留が同順位です。いずれも本人確認データを扱わず、承認も必要ありません。この軸でレビューが最下位なのは、人的な確認を組み込むことでリスクが_低下する_ためです。複数の法制度では、完全に自動化された拒否が禁止されています。

   ここでの工数は、正当なユーザーに課す負担、開発時間、可逆性を組み合わせた指標です。イベントの発生条件を変更するには、プロダクトと課金の改修に数週間かかります。それでも検証がイベント設計より上位なのは、そのコストが一度限りのエンジニアリング工数である一方、検証は正当なユーザーの登録ごとに恒常的な負担を課すためです。イベント設計が効率性で首位なのも同じ理由です。

   デフォルトでは、最初の段階で必ず上限、保留、公開済みの適格性ルールを導入します。現行の対象イベントが単なる登録、または未払いのアクションである場合は、イベントの再設計に進みます。イベントが無料で偽装できる限り、その下にある対策はどれも機能しません。

   この順序では、検証ゲートと手動レビューが後回しになります。上限と保留では対処できない 2 つの不正、つまり自動化されたアカウントの大量作成と、B2B のペーパーカンパニーに対しては、どちらも効果が高い一方、効率性の比較では毎回劣ります。1 件あたりのレビューコストが報酬額を下回る場合（B2B ではデフォルト）、または機会的な不正ではなく自動化された不正だとインシデントで確認された場合は、優先順位を上げます。

   インタビューの回答に基づいて順位を付け直し、どの回答によってどの対策の優先順位が変わったのかを仕様に明記します。

   • 運用開始日の期限が厳しい場合、上限、保留、適格性の優先順位を上げます（設定変更で数日）。イベントの再設計は次のサイクルに予定しますが、決して取り下げません。
   • 不正が連鎖的に拡大することへの対策が求められる場合は、継続的なコストなしで効果が続くイベント設計と適格性の履歴管理の優先順位を上げます。
   • 工数の上限が低い場合は、手動レビューと検証の上位段階を仕様の最下位に置くのではなく、仕様から完全に削除します。何を削除したのか、その理由とともに記録します。

   このプログラムについてすでに把握している情報に基づいても、再度順位を付け直します。

   • 対象イベントより前に支払い手段を取得する場合、検証の優先順位を大幅に上げます。最も強力なゲートがすでに導入されています。
   • 信頼と安全を担当する既存の機能がある場合、レビューの工数は大幅に減ります。
   • 規制対象のプログラムでは、すでに本人確認を実施しているため、最上位の検証段階に追加でかかる限界コストはありません。

   この順位付けは法則ではなくデフォルトとして扱います。状況や、実行する担当者によって変わります。

5. B2B と B2C を明確に分けて扱います。上限、保留、適格性の履歴管理は、どちらでも同じように機能することを明記します。B2B で異なる点は次のとおりです。

   • 紹介者と被紹介者のドメイン重複チェック：重要なチェックです。シェルカンパニーにも実在するドメインがあるため、仕事用メールアドレスのチェックだけでは不十分です。
   • 支払い前の人による審査：B2B では ROI がプラスになりますが、B2C ではそうなりません。
   • 会社アカウントへのクレジット付与をデフォルトにする：従業員個人に支払うことは、不正の問題になる前に、調達や贈答ポリシーの問題になります。

6. references/detection-signals.md から監視シグナルを選びます。ここには軸ごとの完全なランキングが記載されています。

   • 効率性：payment-reuse == cohort-quality > velocity > email-similarity > graph > fingerprint

   上位の 2 つは同率です。どちらもすでに請求データに含まれており、ブラウザーやデバイスを変更しても精度が落ちず、それぞれ相手が見逃すものを的確に検出するためです。Cookie と IP の紐付けは、順位を下げているのではなく、ランキングから除外しています。価値がすでに最低水準にあるため、順序を付けると見せかけの精度になってしまいます。この順序ではグラフシグナルが後回しになります。グラフシグナルを優先する条件については、リファレンスを参照してください。

7. references/enforcement-and-compliance.md に基づき、適用措置の段階を設計します。公表済みの段階、拒否ごとの具体的な理由文字列、機能する異議申し立て手段を用意します。検出器を作る前に、理由文字列と異議申し立て手段を用意してください。法的制約は設計上の制約として扱い、実際の法的な質問は弁護士に相談してください。

8. すべてのルールが公表可能か確認します。現行の規約にないルールは、公表されるまで執行不能として扱い、条項の作成は mbfinotti/partnerships-skills@affiliate-program-terms に依頼してください。

9. プログラムのイベントデータを照会できる場合は、正当な紹介者の分布から頻度とフラグのしきい値を導きます（例：週ごとの紹介数の p95〜p99）。照会できない場合は、参考用のデフォルト値として明記し、最初のレビューサイクル中に導出したベースラインに置き換えてください。

10. ガードレール仕様（以下の出力形式）を一度に 1 セクションずつ提示し、ユーザーの検証を得ます。references/worked-examples.md にある対応する実例を根拠としてください。

11. 合格しきい値に記載されたキャリブレーション計画を添付し、条件を満たすまで反復します。

12. ハーネスに永続メモリがある場合は、決定したしきい値、保留期間、適用措置の段階を記憶し、後続の調整では再ヒアリングせず、それらを起点にできるようにします。

出力形式

すべてのエンゲージメントで、この成果物を提出します。すべてのしきい値行には出典タグを付け、すべてのルール行には、それに抵触する可能性のある正当な行動を明記します。

REFERRAL GUARDRAIL SPEC - <program>, <date>
Qualifying event : reward trigger + why it is costly to fake + reversibility note
Caps             : per-referrer (period + lifetime), per-referee, program budget ceiling.
                   Take the values from the existing reward design where one exists and
                   record them as given; this spec enforces caps, it does not size them
Velocity         : referrals/claims per referrer per window + cooldown after a burst
Hold policy      : hold length = refund/chargeback window (+ processing), pending-state display
Eligibility      : new-customer definition, self/household exclusion, cross-referrer cooldown,
                   B2B domain-overlap rule
Verification     : gates by friction rung, escalation condition per rung, what is never gated
Monitoring       : signals watched, expected flag baseline, cohort-quality dashboard
Enforcement      : published ladder rungs, reason strings, appeal path + response SLA
Terms status     : where each rule is published; unpublished rule = not yet enforceable
Calibration      : holdout cell design, review cadence, leakage/friction computation

合格基準

仕様は漏出と摩擦の両方を踏まえて評価してください。捕捉率や適合率の目標だけで判断してはいけません。紹介に特化した偽陽性のベンチマークはどこにも公開されていません。業界の数値をユーザー自身のホールドアウトの代わりにしてはいけません。

• 両方を同じ単位で計算します。漏出 ＝（無効な報酬の支払い額）×（報酬コスト）。摩擦 ＝（誤って保留された報酬）×（報酬コスト ＋ サポートコスト ＋ P（解約）× LTV）。摩擦項にはLTVの乗数が含まれますが、漏出項には含まれません。そのため、誤り率のトレードオフが1対1でも損益分岐になることはほとんどありません。判断に迷った場合は、条件を緩めてください。
• ホールドアウトで調整します。緩いルールを適用する小規模なセルを設け、以下の3条件すべてについて厳格なルールと比較します。仕様に合格するのは、3条件すべてを満たす場合に限ります。
  1. 登録1件あたりではなく、総価値：厳格なルールを適用したセルの90日間のコホート価値が、接触した紹介者1,000人あたりでホールドアウト以上であること。この条件は欠かせません。登録1件あたりの平均値に置き換えてはいけません。
     • 条件を厳しくすると限界的な登録が除外されるため、登録1件あたりの価値は厳格さに応じて低下しません。
     • 登録1件あたりの基準は、最も過剰に厳しい設定で最も容易に満たせます。また、厳格にしすぎても不合格になることはありません。ここで取り上げているのは、まさにその失敗です。
  2. 品質：紹介によるコホートが、継続率、返金率、90日間の売上のすべてでオーガニックコホートを上回ること。
  3. 上記の計算式で差し引いた純額：厳格なルールによって削減される漏出が、ルールによって生じる摩擦コストを上回ること。両方とも同じ接触ベースで計算します。
• 妥当なガードレールを設けても紹介によるコホートがオーガニックコホートを下回る場合、プログラムは顧客ではなく登録を買っていることになります。問題は報酬設計にあるため、さらに条件を厳しくするのではなく、mbfinotti/partnerships-skills@referral-incentive-design に対応を依頼してください。
• 3つの条件をすべて満たすまで閾値を調整してください。調整に必要なデータがまだない場合は、その旨を成果物に記載し、ローンチ後最初のレビューでホールドアウトを実施するよう予定してください。

よくある失敗パターン

欠陥	影響	対策
正当な紹介まで妨げる厳しすぎるガードレール	プログラムが成り立たなくなり、摩擦コストが防げた漏出額を上回ります	漏出と摩擦の計算式を適用し、紹介者1,000人あたりのコホート価値が回復するまで制限を緩めます。登録者あたりの平均が上昇する一方で件数が減少しているなら、これはこの欠陥の特徴であり、決して欠陥の証拠を否定するものではありません
速度チェックを伴わない上限	不正利用者が検知されないまま週末に生涯上限に達します	すべての上限に、期間ごとの速度制限と急増時のクールダウンを組み合わせます
デバイスや決済手段の再利用を無視する	低コストで確実な自己紹介を見逃します	まず決済手段の再利用を確認します。すでに把握している中で、最も強力なシグナルです
報酬を理由なく拒否する	信頼を損ない、サポート負荷や複数の規制環境での法的リスクが生じます	検知器の導入前に、具体的な理由と公開済みの異議申し立て手順を用意します
ルールを遡及的に厳格化する	過去の紹介には適用できず、規制当局の注目を招きます	まず公開し、その後に適用します。すでに獲得済みの報酬は既得権として保護します
保留期間が返金期間より短い	紹介された人が報酬支払い後に返金し、報酬を取り戻せなくなります	商品ラインごとに、保留期間を返金・チャージバック期間に処理時間を加えた長さに設定します
熱心な支持者を不正グループとみなす	トップ紹介者が禁止され、口コミに最悪の影響が出ます	グラフの形状以外の裏付けを必須にします。報酬の分配、返金、コホートの崩壊などを確認します
手動審査のコストが報酬額を上回る	精度にかかわらず、審査のたびに損失が発生します	審査コストを上回る報酬に限って審査します。B2Bではこれをデフォルトとし、B2Cでは例外とします
価値の低い消費者向け報酬に完全なKYCを求める	詐欺防止の効果をはるかに上回る登録離脱が発生します	決済手段の確認で止めます。KYCは規制対象のプログラムで実施します

KPI

• 追跡項目：
  • 無効報酬率（流出）
  • 異議申し立てが認められたケースに基づく不当保留率（摩擦）
  • 紹介経由と自然流入のコホート間における、継続率、返金率、90日間の収益の差
  • 予想される複数アカウント利用のベースラインに対するフラグ率
  • 保留から解除までの時間
  • 予算上限の消化率
  • 報酬の却下に関するサポートチケット
• 流出と摩擦は、同じ単位の金額で並べて報告します。どちらか一方の数値だけでは、必ず誤解を招きます。
• 次の場合は、仕様自体の見直しにエスカレーションします。
  • 異議申し立てが認められる割合が上昇している（ルールが厳しすぎます）
  • フラグ率が横ばいのままコホートの質が低下している（不正グループを見逃しています）
  • 適格性を判断するイベントの返金率が上昇している（イベントの条件が簡単すぎます）

呼び出し例

• 「ミールキットの定期便で、紹介者と被紹介者の両方に25ドルを進呈していますが、プラスアドレスを使ったメールアカウントを40個以上作られて、不正利用されました。再開する前にガードレールを作成してください。」
• 「来月、フィットネスアプリで『紹介者に10、被紹介者に10』のキャンペーンを開始します。初日から不正利用されないよう、上限、保留ポリシー、検証ゲートを設計してください。」
• 「当社のB2B SaaSでは、有料化した紹介先のワークスペースごとに500ドル分のアカウントクレジットを支給しています。財務部門は、ある代理店が自社の架空アカウントを紹介しているのではないかと疑っています。不正利用を防ぐガードレールと審査プロセスを設定してください。」

参考資料

• 不正利用の範囲を洗い出す際は、references/abuse-patterns.mdを参照してください。消費者向けキャンペーンの不正利用パターン分類と、それぞれのパターンで観測できる兆候、および記録済みの事例が掲載されています。
• 上限、保留、適格性ルール、検証ゲートを設定する際は、references/guardrail-mechanics.mdを参照してください。出典付きの公開値、摩擦の段階的な適用、B2B固有の情報が掲載されています。
• 監視シグナルを選ぶ際は、references/detection-signals.mdを参照してください。強度の評価、劣化しているシグナル、調整用のベースラインが掲載されています。
• 執行段階、理由文、異議申し立て、法的な設計上の制約を定める際は、references/enforcement-and-compliance.mdを参照してください。
• 成果物を作成する際は、references/worked-examples.mdを参照してください。B2CとB2Bの記入済み仕様例、および悪い例が掲載されています。
• 報酬構造（どちら側への報酬か、種類、金額、支払いトリガー、段階設定）については、mbfinotti/partnerships-skills@referral-incentive-designを参照してください。このスキルでは報酬構造を保護し、再設計は行いません。
• プロフェッショナルアフィリエイトのトラフィックとコミッション詐欺については、mbfinotti/partnerships-skills@affiliate-fraud-detectionを参照してください。
• 消費者向けの友達紹介規約の文面については、プログラムにプロフェッショナルアフィリエイト層も含まれる場合に限り、mbfinotti/partnerships-skills@affiliate-program-termsを参照してください。