Amazon Fraud Detector は、機械学習の経験がなくても不正検知モデルを組めるようにしたAWSのマネージドサービスです。ただし2025年11月7日をもって新規顧客の受付を終えており、これから新しく採用することはできません。日本語で読める解説記事の多くは2020年の一般提供時点の内容で止まっているため、まず現況を押さえ、そのうえで「不正検知モデルの学習に何件のどんなデータが必要か」「代わりに何で組むか」を判断できる形に整理します。OFI・TFI・ATIという3つのモデルタイプの違い、必須100件と推奨1万件の差、検証で学習が止まる7条件、AutoGluon と SageMaker AI・AWS WAF Fraud Control・自前実装の選び分けまでをAWS公式ドキュメントの実測値で扱います。
まとめ｜Amazon Fraud Detectorは新規受付停止済み・代替は3系統
Amazon Fraud Detector は2025年11月7日をもって新規顧客に公開されなくなりました。既存の利用者は使い続けられますが、AWSのライフサイクル区分でいうメンテナンス状態にあたり、運用とサポートは続く一方で機能追加は見込めません。公式の提供終了ページには、コンソールやAPIが止まる期日の記載がありません（2026年9月4日時点）。争点は「いつ消えるか」ではなく「機能が伸びない基盤に不正検知の中核を置き続けるか」です。
これから不正検知を組むなら、AWSが挙げる代替は3系統です。第一にOSSのAutoMLライブラリであるAutoGluonで学習し、SageMaker AI でデプロイする構成。第二にアカウント作成やログインの防御に限るなら AWS WAF Fraud Control。第三に自前でモデルを設計・学習・運用する構成。判断の分かれ目は、不正ラベル付きの履歴データがどれだけあるかに帰着します。Fraud Detector が学習を受け付ける必須下限は100イベント・うち不正50件、まともな精度を狙う推奨値は総1万件・不正400件と正常400件です。この水準に届かないなら、モデルを作る前にラベル収集の設計から始める判断になります。
Amazon Fraud Detectorとは｜マネージドの不正検知が担う範囲
Fraud Detector が扱う対象は「イベント」です。アカウント登録や決済といった業務上の行為を1件のイベントとして送り込み、不正リスクのスコアと判定結果を受け取ります。構成要素はイベントタイプ、評価対象を指し示すエンティティ、スコアをビジネス判断に変換するルール、モデルとルールを束ねたDetectorの4つで、実装はこの4つを順に定義する作業になります。
新規受付停止2025年11月7日以降の扱いとメンテナンス状態の実務影響
AWS公式の提供終了告知は「2025年11月7日をもって新規顧客を受け付けない」と述べるにとどまり、既存顧客の停止期日には触れていません。AWS General Reference のライフサイクル定義に照らすと、これはメンテナンスの記述に一致します。新規オンボードはできず、既存利用者は継続でき、運用とサポートは維持されるが機能強化はしない、という状態です。
実務では2点に効きます。第一に、既存のDetectorに新しい不正パターンへの対応は期待できません。モデルタイプの追加やエンリッチ元データの拡充は、すでに止まった状態です。第二に、移行の準備を先に済ませられます。AWSは「Migrating event data stored in Amazon Fraud Detector」という移行手引きを用意しており、INGESTED_EVENTS に貯めたイベントデータの取り出しはここに沿って進めます。なお日本語のまとめ記事の一部が「2026年5月20日にサポート終了」と伝えていますが、公式ページと日本語版ユーザーガイドの冒頭バナーに当該記述は見当たりませんでした。
勾配ブースティング木とIP・BINのサードパーティエンリッチ
Fraud Detector のモデルは単一のアルゴリズムではありません。学習時にIPアドレスやカードのBINといった生の値を、AWS側が持つサードパーティデータで補います。IPアドレスからはジオロケーション、BINからは発行銀行が引き当てられ、これが特徴量として追加されます。さらにAmazonとAWSで観測されてきた不正パターンを深層学習で特徴量化し、それらをまとめて勾配ブースティング木に入力する構造です。
ハイパーパラメータはベイズ流の探索手続きで詰められます。木の本数、木の深さ、葉あたりのサンプル数などを変えた数十のモデルを順番に学習し、良い組み合わせを探す動きです。不正率が極端に低いデータでは、少数派である不正側の重みを上げる戦略も併用されました。自前実装との差はここに出ます。エンリッチ用の外部データとAmazon側の不正パターンは、同じアルゴリズムを自分で書いても再現できません。特徴量とは何かという設計の基礎を押さえ、どこを外部に頼りどこを自分で作るかを切り分けます。
モデルタイプ3種の選び分け｜OFI・TFI・ATIが想定する不正の形
Fraud Detector には3つのモデルタイプがあり、選択を誤るとデータ要件そのものが変わります。評価対象の履歴が薄いか厚いか、そして守る対象が取引かアカウントか、という2軸で決まります。3つめの Account Takeover Insights（ATI）はフィッシングなどによるアカウント乗っ取りの判定に用途を絞ったモデルで、データ準備の要件もOFI・TFIとは別立てです。予測単価も最初の1,000万件で1件0.001米ドルと、OFI・TFIの1件0.03米ドルより2桁安く、ログインは件数が桁違いに多いという前提が価格に表れていました。
OFIが向く履歴の薄いエンティティと偽アカウント登録の検知条件
Online Fraud Insights（OFI）は、評価対象の過去データがほとんどない状況を想定した教師あり学習モデルです。新規顧客が初めてアカウントを登録する場面が典型で、偽レビュー、プロモーションの悪用、ゲストチェックアウトでの決済不正といった用途にも向きます。入力変数の自由度が高く、必須メタデータ以外に最低2変数、上限100変数まで投入できます。
投入変数のうちAWSが名指しで推奨しているのはIPアドレスとメールアドレスです。エンティティを識別する力が強いためで、この2つを欠いた状態で変数の数だけ増やしても精度は伸びにくくなります。逆に不正ラベルがそもそも揃わない、あるいは「何が不正か」の定義が固まっていない段階なら、教師ありのOFIは選べません。その場合は異常検知の手法と製造業での導入判断で扱う教師なし寄りのアプローチが先に来ます。
TFIのエンティティ集計特徴量とユニーク1500件未満の警告
Transaction Fraud Insights（TFI）は、カード非提示（card-not-present）の取引不正に向けたモデルです。OFIとの最大の違いは、特徴量エンジニアリングエンジンがエンティティ単位・イベント単位の集計値を自動生成する点にあります。たとえば「そのエンティティが最後に購入した時刻」を学習時に計算して保存し、GetEventPrediction または SendEvent を呼ぶたびに動的更新する仕組みです。過去の購入履歴を持つ既存顧客の評価では、この集計値が効きます。
その仕組みの裏返しとして、TFIは学習データにエンティティの厚みを要求します。ユニークエンティティが1,500未満なら警告の対象です。学習自体は継続しますが、集計特徴量の母数が薄い状態なので、出てきた性能指標をそのまま信じない前提で見ます。推奨変数はIPアドレス、メールアドレス、決済手段の種別、注文金額、カードBINの5つです。
学習データ要件｜必須100件・推奨1万件と検証で落ちる境界条件
Fraud Detector はモデル作成の前にデータセットを検証します。要件を満たさなければモデルは作られず学習も始まりません。ここは自前実装に切り替える判断でも同じ基準が使えるため、数値をそのまま押さえておく価値があります。
必須イベントメタデータ6列とEVENT_TIMESTAMPの許容形式
データセットはUTF-8のCSVで、1行目がヘッダーです。イベントメタデータは大文字、イベント変数は小文字という命名規則が課されます。メタデータは次の6つで、モデルタイプによって必須かどうかが変わります。
| 列名 | 制約 | 必須 |
|---|---|---|
| EVENT_ID | 正規表現 ^[0-9a-z_-]+$ | モデルタイプ依存 |
| EVENT_TIMESTAMP | 4系統の日時形式のみ | 必須 |
| ENTITY_ID | ^[0-9A-Za-z_.@+-]+$ | モデルタイプ依存 |
| ENTITY_TYPE | 任意の文字列 | モデルタイプ依存 |
| EVENT_LABEL | fraud、legit、1、0 など | ラベル時刻があれば必須 |
| LABEL_TIMESTAMP | 日時形式に従う | ラベルがあれば必須 |
詰まりやすいのは EVENT_TIMESTAMP です。ISO 8601 で書く場合は %yyyy-%mm-%ddT%hh:%mm:%ssZ の完全一致で、UTCのみ、ミリ秒は不可。それ以外の3形式では月日を1桁で書けて、時刻の省略や時分のみの指定も通りますが、「時のみ」は通らず、ミリ秒はどの形式でも受け付けません。EVENT_ID にタイムスタンプを連結する設計はAWS自身が非推奨としています。イベント更新時に同一のEVENT_IDを再現できなくなるためです。
学習データの必須下限100件と推奨1万件・不正400件の判断基準
件数の基準は必須と推奨で2段階に分かれています。必須は学習を通すための最低線で、推奨は使える精度を狙うための水準です。この2つを混同すると「学習は通ったのに精度が出ない」状態に落ちます。
| 観点 | 必須（学習の下限） | 推奨（精度の目安） |
|---|---|---|
| 総イベント数 | 100件以上 | 1万件以上 |
| 不正ラベル | 50行以上 | 400行以上 |
| 正常ラベル | 規定なし | 400行以上 |
| 履歴の期間 | 規定なし | 3週間以上・理想6か月 |
| ユニークエンティティ | 不正側で100以上 | 100超（TFIは1,500） |
実務で先に枯れるのは不正ラベルです。総件数は業務ログから増やせても、不正と確定した400件は不正率1%の事業なら4万件の取引に相当します。ここが集まらないうちにモデル化へ進むと、学習は通っても評価が当てになりません。教師データ作成の種類と品質管理の設計がモデル選定より前に来ます。
データ成熟期間2週間〜3か月とチャージバック60日待ちの設計
もう一つの制約が時間です。直近のデータは新しい不正パターンを多く含む一方で、ラベルが確定していない期間のデータを混ぜると学習が濁ります。AWSが示す成熟期間は、業種に応じて2週間から3か月です。クレジットカード取引ならチャージバックの受付期間、あるいは調査担当が判定を下すまでの時間で決まります。
TFIのドキュメントはより踏み込んで、チャージバック不正では正しく不正と識別できるまで60日以上かかることが多いと述べています。つまり「先月分のデータで学習」は成り立ちません。学習用の期間を切るときは、末端から成熟期間ぶんを落とすのが前提になります。あわせて分布の偏りへの注意も必要です。不正イベントは過去6か月分、正常イベントは直近1か月分といった構成は分布がずれた不安定なデータセットと見なされ、性能評価にバイアスが乗ります。
検証エラー7条件とEVENT_LABEL欠損1%超で学習が止まる境界
データセット検証で落ちる代表的な条件は7つです。いずれか1つでも該当すればモデルは作成されません。
- CSVがUTF-8形式でない
- イベント数が100件未満
- 不正または正常と判定された数が50件未満
- 不正イベントに紐づくユニークエンティティが100件未満
- EVENT_TIMESTAMP のnullまたは非対応形式が0.1%超
- EVENT_LABEL のnullまたはイベントタイプ未定義の値が1%超
- 学習に使える変数が2つ未満
0.1%と1%という閾値の差に意味があります。EVENT_TIMESTAMP は学習データのサンプリングと分割の基準になるため、桁違いに厳しく見られていました。10万行なら不正な日時が100行あるだけで止まる計算です。EVENT_LABEL 側は1%まで許容され、他の変数のnullはさらに緩く、多すぎる場合はその変数が自動的に学習から除外されます。事前確認には、AWSがOSSで公開しているデータプロファイラを利用可能です。CloudFormation スタックから起動でき、コードは GitHub の aws-samples/aws-fraud-detector-samples にあります。
EXTERNAL_EVENTSとINGESTED_EVENTSの選択基準とS3の前提
データの置き場所は2択で、選べる範囲がモデルタイプで決まります。OFIは両方使えますが、TFIは内部保存のみです。
| 観点 | EXTERNAL_EVENTS | INGESTED_EVENTS |
|---|---|---|
| 保存先 | Amazon S3 | Fraud Detector 内部 |
| 形式 | CSVをバケットへ配置 | APIで逐次投入 |
| 対応モデル | OFIのみ | OFI・TFI |
| EVENT_LABEL | 全イベントに必須 | 任意（未ラベルは除外） |
| 集計特徴量 | 継続更新なし | エンティティ値を更新 |
内部保存では未ラベルのイベントの扱いを学習設定で選べます。無視する、正常とみなす、不正とみなすの3択で、既存の運用ログをそのまま流し込みたい場合に有効な設定です。一方で内部保存に寄せるほどデータがサービス側に貯まるため、移行時には前掲の移行手引きに沿った取り出しが要ります。推論時に同じ特徴量を安定して供給する仕組みまで自分で持つなら、特徴量ストアのオンライン・オフライン二層構成が設計の参照点になります。
Fraud Detector停止後の代替3系統｜移行先の選び分けと判断線
AWSが提示する代替は AutoGluon、SageMaker AI、AWS WAF の3つですが、これらは横並びの選択肢ではありません。役割が違うため、まず守る対象と手持ちのラベル量で振り分けます。
AutoGluonとSageMaker AIで組む代替構成の役割分担
AutoGluon はAWSが公開しているOSSのAutoMLライブラリで、表形式データの分類に強く、不正検知用のノートブックが Kaggle に公開されています。学習の自動化はここが担い、学習済みモデルのデプロイは SageMaker AI 側に寄せる構成が公式に案内されている組み合わせです。リアルタイムの決済処理アーキテクチャについてはAWSのワークショップが別途あり、推論をどこに挟むかの参照設計として使えます。
Fraud Detector から失われるのは2つです。IPアドレスやBINのサードパーティエンリッチと、Amazon側の不正パターン由来の特徴量。前者は外部のIP評価サービスやBINデータベースを自分で調達すれば埋められますが、後者は代替が効きません。この構成に移すときは、自社データから作る変数の設計へ投資が移ります。再学習の頻度、モデルの版管理、推論と学習の特徴量の一致といった論点はMLOpsの仕組みと導入判断の領域に入ります。
AWS WAF Fraud Controlで足りる場面と機械学習が不要な線
ここは言い切ります。守る対象がログインページとサインアップページに限られ、止めたい攻撃がクレデンシャルスタッフィング、クレデンシャルクラッキング、偽アカウント作成の3型なら、機械学習モデルを作る必要はありません。AWS WAF Fraud Control のマネージドルールで足ります。AWSも同機能の不正検知はマネージドルールに基づくもので機械学習モデルではないと明示しており、それでも用途としてはアカウント作成不正の代替に挙げています。
逆に、この線を越える要件ではWAFを選びません。取引の金額や決済手段の組み合わせでリスクを測りたい、自社固有の不正手口をデータから見つけたい、スコアに応じて審査へ回すか自動承認するかを段階的に切り替えたい。こうした要件はルールの列挙では表現しきれず、教師ありモデルが必要になります。判断の順序は「WAFで足りるかを先に確かめ、足りない部分だけをモデルにする」です。最初からモデルを前提に置くと、ルールで止められた攻撃にまで学習データを要求することになります。
不正検知モデルを自前実装で組む条件と過剰投資になる規模の目安
自前実装に踏み込んでよい条件は2つそろったときです。第一に不正ラベルが400件以上あり、ラベル定義が業務として固まっていること。第二に不正による損失が、開発と運用の年額を明確に上回っていること。Fraud Detector の料金が判断の目盛りになります。ホスティングが1時間あたり0.06米ドルなので常時1つ立てても月額は40米ドル台にとどまり、費用の主役は予測件数です。月1万件の評価なら300米ドル規模。この帯にマネージド相当の仕組みを自前で作って載せると、人件費だけで桁が変わります。
見送るべき場面も明確です。月間の評価件数が数千件に届かず、不正ラベルが2桁しかない段階では、モデルを作らずルールと目視の運用で回します。学習の必須下限は100イベント・不正50件と低く設定されていますが、これは「動く」下限であって「効く」下限ではありません。推奨値の1万件・不正400件に1桁足りない状態では、精度指標そのものが信用できないためです。この段階でやるべきは、不正の判定履歴をラベルとして残す仕組みを業務に埋め込むこと。ラベルが貯まったところでモデル化へ進みます。設計・学習・運用まで含めて外部と組む選択を検討する段階なら、機械学習モデル開発の相談先として声をかけてください。
よくある質問
Amazon Fraud Detector の現況と学習データ要件について、検索されやすい質問に答えます。
Amazon Fraud Detectorは今も使えますか？
既存の利用者は使えます。2025年11月7日をもって新規顧客の受付が終わったため、これから新しく契約して使い始めることはできません。AWSのライフサイクル区分でいうメンテナンス状態にあたり、運用とサポートは継続しますが機能追加は行われません。AWS公式のFraud Detector提供終了ページには、コンソールやAPIへのアクセスが止まる期日の記載がありませんでした（2026年9月4日時点）。
Amazon Fraud Detectorの料金はどれくらいかかりますか？
2026年9月4日時点の料金ページでは、モデル学習が1時間あたり0.39米ドル、ホスティングが1時間あたり0.06米ドル、データ保存が1GBあたり0.10米ドルでした。不正予測は月間の段階制で、Online Fraud Insights と Transaction Fraud Insights は最初の10万件が1件0.03米ドル、以降1件0.0075米ドル。ルールのみの評価は最初の40万件が1件0.005米ドル、Account Takeover Insights は最初の1,000万件が1件0.001米ドルでした。
学習データは何件あれば不正検知モデルを作れますか？
学習を通す必須要件は100イベント以上で、うち不正と分類された行が50以上です。ただしこれは検証を通過するだけの下限にすぎません。AWSが推奨する水準は総イベント1万件以上、不正400行以上かつ正常400行以上、履歴は3週間以上で理想は6か月分です。TFIを使う場合はユニークエンティティ1,500件以上も見ます。不正率1%の事業なら、不正400件は取引4万件に相当する規模になります。
Amazon Fraud DetectorとSageMakerはどう違いますか？
Fraud Detector は不正検知に用途を絞ったマネージドサービスで、アルゴリズム選択やチューニングを隠しています。IPアドレスやBINをサードパーティデータで補い、Amazon側の不正パターンを特徴量に組み込む処理も内包していました。SageMaker AI は用途を限定しない機械学習の基盤で、モデルの設計とチューニングは利用側が担います。AWSは代替としてOSSのAutoGluonで学習し SageMaker AI でデプロイする組み合わせを案内していました。
不正検知モデルの精度はどの指標で判断すればよいですか？
単一の正解率では判断できません。不正は全体のごく一部なので、すべてを正常と判定しても正解率は高く出ます。実務では「不正のうち何割を捕まえたか」と「そのとき正常をどれだけ誤って止めたか」の組み合わせが判断軸です。AWSのドキュメントも目標設定の例として、不正登録のX%を捕捉し誤検知率をY%に収める、自動承認のうち不正を5%まで許容する、といった形を挙げています。運用前のベースラインと比べる設計にしてください。
関連記事
- 時系列データの異常検知｜手法の選び分けとしきい値・評価・アラート運用を実装目線で解説：ラベルが揃わない段階で選ぶ教師なし寄りの手法。
- 特徴量エンジニアリングとは？変換・選択・自動化の工程と実装判断：TFIの集計特徴量を自前で作り直す工程。
- アノテーションとは？AI・機械学習の教師データ作成の種類・やり方・品質管理を解説：不正ラベル400件を貯める付与と品質管理の設計。
- Azure Machine Learningとは？料金・できること・SageMakerとの違いと導入判断：AWS以外に載せる場合の基盤比較。
