2026 年 5 月 27 日、Hacker News で Stripe is friendly to “friendly fraud”（gingerlime 2026-05-27） が話題になりました。論点は、決済プラットフォーム（Stripe 等）における チャージバック、なかでも 正規購入者本人による不正な返金請求 ＝ フレンドリーフラウド（friendly fraud / first-party fraud） に対し、加盟店側の 異議申し立て（representment） がしばしば不利になりがちだという問題提起です。正しく提供したのに「身に覚えがない」と申告され、手数料とペナルティだけが残る構図は、EC 事業者なら一度は経験するでしょう。
私たちは中堅企業の自社 EC / D2C / サブスクを 受託（コンサル / 構築 / 運用） で支援する立場から、これを 収益を守る設計課題 と捉えています。不正対策はフォーム保護から地続きで、Google Cloud の不正対策・reCAPTCHA 移行受託 で扱ったセッション保護と決済層の証跡設計をつなぐことで初めて成立します。本記事では弊社の 「EC チャージバック・不正決済対策」受託パッケージ の設計、契約条項、価格モデルを整理します。
なぜ「チャージバック対策が分水嶺」なのか
チャージバックには大きく 2 種類あります。悪意ある第三者による不正利用（盗難カード・カードテスト等）と、本記事のテーマである フレンドリーフラウド（本人が正規に購入したうえで「覚えがない/届いていない」と申告するもの）です。前者は 3DS2 等で 入口を絞る 戦い、後者は 証跡で覆す 戦いであり、混同すると対策は的を外します。
| 観点 | 無策（決済を入れて終わり） | 体系的なチャージバック対策 |
|---|---|---|
| 不正検知 | なし、または決済代行の既定値のみ | 3DS2 / SCA + ルール・ML による多層検知 |
| 証跡（配送・同意・利用ログ） | 散在、または取得していない | 注文・配送・同意・利用ログを構造化して自動蓄積 |
| 異議申し立て勝率 | 提出せず諦める、または定型なし | 理由コード別テンプレ運用で勝率改善が期待できる |
| 手数料・ペナルティ | 件数増で手数料率が上がるリスク | しきい値監視で超過プログラム入りを回避 |
| LTV への影響 | 優良顧客まで弾き機会損失 | 誤検知を抑えつつ被害だけを削る |
一般に、チャージバック比率が決済ブランドの定める水準を超え続けると 監視プログラム入りや手数料率の引き上げ につながるとされます。被害額そのものより、この 二次的なペナルティ の方が事業インパクトが大きくなる場合があります。
受託案件で活きる 3 つの構造変化
構造 1: 「決済を入れて終わり」から「不正前提の決済設計」へ
これまでの EC 構築は決済を つなげば完了 でした。今は 不正が一定割合で必ず起きる前提 で、3DS2 のかけ方、リスクに応じた追加認証、返金フローまで初期構築に織り込む必要があります。決済設計はカート最適化と不可分で、EC サイト比較 2026 で論じたプラットフォーム選定の段階から考えるべきテーマです。
構造 2: 属人対応から「証跡の自動蓄積」へ
異議申し立ては 証拠勝負 です。担当者が都度メールやログを探す属人運用では勝てません。配送追跡・同意取得・利用ログ・本人確認 を注文 ID にひも付けて自動で残す仕組みが、勝率改善の前提です。
構造 3: 個別対応から「継続的な不正運用」へ
不正の手口は変化します。一度ルールを組んで終わりではなく、理由コードの傾向を毎月レビューし、しきい値とルールを調整し続ける 運用が必要です。フォーム入口の摩擦設計は EFO（入力フォーム最適化） と地続きで、CVR を落とさず不正だけを絞る調整が肝になります。
受託で提供する「EC チャージバック・不正決済対策」5 フェーズ
フェーズ 1: 現状診断
- 直近のチャージバック率・件数・被害額を棚卸し
- 理由コード分析（不正利用 / 商品未着 / 品質不備 / 解約漏れ 等）で多い型を特定
- フレンドリーフラウドと第三者不正の 比率の見立て を顧客と合意
フェーズ 2: 決済・不正検知設計
- 3DS2 / SCA の適用範囲（全件強制かリスクベースか）を設計
- 不正検知ルール（金額・地域・速度・デバイス・初回購入 等）と ML スコアの しきい値 を定義
- 誤検知を許さない決済と、ブロックを許容する操作を区別
フェーズ 3: 証跡基盤の実装
- 配送追跡・受領記録、利用規約への 同意ログ、サブスクの 利用ログ、本人確認結果を注文 ID にひも付けて自動蓄積
- 個人情報の保管期間・マスキング方針を設計に含める
フェーズ 4: 異議申し立て運用の整備
- 理由コード別の 異議申し立て（representment）テンプレ を整備し、必要証憑を自動で束ねる
- 提出期限管理とエスカレーションのワークフローを定義
フェーズ 5: 運用レビュー（継続）
- チャージバック率・勝率・誤検知率を ダッシュボード で可視化
- 月次で理由コードの傾向を見直し、ルール・しきい値・テンプレを更新
受託向け技術スタック標準セット
| レイヤ | 推奨 | 代替 / 補足 |
|---|---|---|
| 決済 | Stripe | 国内 PSP / 複数ブランド対応 |
| 3D セキュア / SCA | 決済側のリスクベース 3DS2 | 全件 3DS（CVR 影響を要評価） |
| 不正検知 | ルール + ML スコアの併用 | 決済代行の標準不正検知のみ |
| チャージバック管理 | 理由コード別の管理ワークフロー | スプレッドシート手運用（小規模のみ） |
| 証跡・ログ基盤 | 注文 ID 連携のログストア + オブジェクトストレージ | 既存 DWH への集約 |
| ダッシュボード | BigQuery + Looker Studio 等 | 決済代行の標準レポート |
具体プロダクトは顧客の既存構成に合わせて選定します。重要なのは製品名ではなく 各レイヤを注文 ID で串刺しにできているか という一点です。
どの案件に必要か / 不要か
| 必要性が高い | 必要性が低い |
|---|---|
| 自社 EC / D2C で月商規模が大きい | 受注が少なく被害が軽微 |
| サブスク・継続課金がある | 都度・単発の少額販売のみ |
| チャージバック率が上昇傾向 | 監視プログラムから十分に距離がある |
| 高単価・転売対象になりやすい商材 | デジタル提供で配送証跡が単純 |
| 海外決済・越境 EC の比率が高い | 国内・少額・低リスク中心 |
受託契約に書く 6 つの条項
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 責任範囲 | 検知・証跡・運用の支援範囲、最終判断は顧客 | 損失補填の有無を明確化 |
| 個人情報・PCI 取り扱い | カード情報は保持せず PSP に委ね、証跡は必要最小限 | 保管期間とマスキング方針 |
| 目標指標（SLO/KPI） | チャージバック率・勝率の目標と前提 | 数値は努力目標か保証か |
| 期限・SLA | 異議申し立て提出の対応時間 | 期限超過時の取り扱い |
| 検知の誤検知方針 | 正規購入を弾いた際の取り扱い | 機会損失の責任分界 |
| 変更管理 | ルール・しきい値変更の合意プロセス | 緊急時の暫定対応権限 |
価格モデル — EC チャージバック対策パッケージ
| メニュー | 内容 | 価格レンジ（税別） |
|---|---|---|
| 診断 / PoC | 現状診断・理由コード分析・改善提案 | 約 40〜80 万円（一括） |
| Lite | 検知ルール監視 + 異議申し立てテンプレ提供 | 月額 約 10〜20 万円 |
| Standard | 上記 + 証跡基盤運用 + 月次レビュー | 月額 約 25〜45 万円 |
| Enterprise | 上記 + ML 検知運用 + 専任ダッシュボード | 月額 約 50〜90 万円 |
| 初期構築 | 決済・3DS2・証跡基盤・ダッシュボード構築 | 約 150〜400 万円（一括） |
金額は商材・取扱高・決済構成により上下します。被害額と工数の見立てを診断で出してから メニューを提案します。
顧客側 ROI 試算
| 効果項目 | 想定インパクト |
|---|---|
| チャージバック損失額の削減 | 検知強化と証跡で被害を縮小 |
| 異議申し立て勝率の向上 | 提出率・勝率の改善が期待できる |
| 不正対応工数の削減 | 証跡自動化で 1 件あたりの工数を圧縮 |
| ペナルティ手数料率の回避 | 監視プログラム入りを避け手数料維持 |
たとえば月商 5,000 万円規模で チャージバック率が 1.0% から 0.4% 前後へ低下 し、勝率も改善した場合、被害・手数料・対応工数の合算削減 が Standard 月額を上回るケースは珍しくないと考えられます。回収期間は理由コード構成に依存するため、診断時に顧客のデータで個別試算 します。
ハマりやすい 5 つの落とし穴
落とし穴 1: 不正検知を厳しくしすぎて正規購入を弾く
しきい値を上げれば被害は減りますが、優良顧客のオーソリ拒否 が増え LTV を毀損します。被害削減と CVR の両天秤で調整すべきです。
落とし穴 2: 証跡を残していないので異議申し立てで負ける
ルールだけ作って配送・同意・利用ログを残していないと、いざ representment で 提出する証拠がない 状態になります。証跡基盤は検知ルールと同時に整えます。
落とし穴 3: 理由コードを分析しない
「チャージバックが多い」だけでは打ち手が決まりません。理由コード別に型を分解 しなければ、効く対策は組めません。
落とし穴 4: 3DS2 を全件強制して CVR を落とす
入口を固めれば第三者不正は減りますが、追加認証の摩擦で離脱 が増えます。リスクベースで適用範囲を絞るのが定石とされます。本人申告であるフレンドリーフラウドは 3DS2 では防げない点も忘れないでください。
落とし穴 5: フレンドリーフラウドを第三者不正と混同する
フレンドリーフラウドは 証跡で覆す 領域であり、第三者不正と同じ入口強化だけで手当てしようとすると勝てません。両者の比率を見極め、出口（証跡・異議申し立て）の整備にも投資配分することが重要です。
90 日アクションプラン
| 期間 | 主な作業 |
|---|---|
| 第 1〜2 週 | 現状診断・理由コード分析・被害額の棚卸し |
| 第 3〜5 週 | 3DS2 / 検知ルール設計、しきい値の合意 |
| 第 6〜9 週 | 証跡基盤の実装、注文 ID 連携の整備 |
| 第 10〜11 週 | 異議申し立てテンプレ整備・提出ワークフロー構築 |
| 第 12〜13 週 | ダッシュボード公開・月次レビュー体制の立ち上げ |
まとめ
フレンドリーフラウドは「正規購入者の顔をした損失」であり、決済を入れただけの EC では静かに利益を削り続けます。打ち手は 不正検知（入口）と証跡・異議申し立て（出口）の両輪 で、しかも 継続運用 が前提です。私たちは現状診断から決済設計・証跡基盤・運用レビューまでを 受託 で一気通貫に整え、被害とペナルティの両方を抑える体制づくりを支援します。チャージバックの増加に心当たりがあれば、まずは お問い合わせフォーム よりお気軽にご相談ください。
Sources
- Stripe is friendly to “friendly fraud”（gingerlime 2026-05-27）: https://www.gingerlime.com/2026/stripe-seem-friendly-to-friendly-fraud/
- EC サイト比較 2026
- Google Cloud 不正対策・reCAPTCHA 移行受託
- EFO（入力フォーム最適化）
