Amazon Fraud Detector

解決する課題

オンラインサービスでは、なりすましによる不正なアカウント登録、盗難カードを使った不正注文、ボットによる大量登録などのオンライン不正が絶えません。これらをルールベースのチェックだけで防ごうとすると、抜け道を突かれて見逃しが増える一方、ルールを厳しくすると正規ユーザーまで弾いてしまいます。Amazon Fraud Detector を使うと、こうした不正の検知を機械学習で自動化できます。

• 新規アカウント登録がなりすましや使い捨てかどうかをリスクとして評価
• オンライン注文やトランザクションが不正かどうかをスコア化
• ゲストでのチェックアウトやプロモーション悪用など、用途に応じた不正パターンを学習
• スコアにビジネスルールを重ねて、承認・人手レビュー・拒否といった具体的な判定を返す

不正検知モデルの構築・学習・運用を自前で抱えず、自社の過去データを与えるだけで検知を始められる点が中心的な価値です。

主要概念と用語

• イベント（Event）: 不正かどうかを評価したい出来事の単位。アカウント登録やトランザクションなど。事前にイベントタイプとして定義する
• イベントタイプ: 評価対象イベントの構造定義。どの変数を含み、どのエンティティとラベルに関連するかを定める
• 変数（Variable）: イベントを構成する入力データ項目（メールアドレス、IP アドレス、金額など）。型に応じて検知に活用される
• エンティティ: イベントを起こす主体（顧客やアカウントなど）の種別を表す
• ラベル: 過去イベントの結果が「不正」か「正常」かを示す教師データ。モデル学習に使う
• モデル: 過去データから学習した、不正リスクを推定する機械学習モデル。学習後にバージョンとしてデプロイする
• モデルタイプ: 用途に応じた学習テンプレート。オンライン不正やトランザクション不正、アカウント乗っ取りなどに対応する種類がある
• 検出器（Detector）とディテクターバージョン: モデルとルールをまとめ、判定ロジックとして公開する単位。バージョン管理される
• ルール: 変数やモデルスコアの条件式。満たすと特定のアウトカムを返す
• アウトカム（Outcome）: ルールが返す業務上の結論（例: 承認、要レビュー、ブロック）
• 不正スコア（Fraud score）: モデルが返すリスクの度合い。しきい値とルールで判定に変換する

仕様・制限・クォータ

• 利用には自社の過去イベントデータ（不正・正常のラベル付き）が必要で、学習に十分な件数と不正比率が求められる
• 学習用データは S3 に置いた CSV を取り込むか、API でイベントを蓄積する方式がある
• 評価はオンライン（リアルタイム）の同期推論と、過去データをまとめて評価するバッチ予測の両方に対応する
• 出力はモデルの不正スコアと、ルール評価で導かれたアウトカムを含む構造化データ（JSON）として得られる
• イベントタイプ数、変数数、検出器やルール数、リアルタイム評価のレートなどにアカウント単位のクォータがあり、引き上げ申請が可能
• 学習に使える期間やデータ量、対応するモデルタイプは更新される

具体的なデータ要件・上限値・クォータは更新されるため、最新の公式ドキュメントで確認してください。

内部の仕組み

利用者から見ると、評価したいイベントの変数を渡すと、AWS 側のマネージドなモデルとルールエンジンがリスクを判定し、スコアとアウトカムを返す仕組みです。

• データ準備と学習: ラベル付きの過去イベントを与えると、サービスが特徴量の生成やモデル選択を自動で行い、不正検知モデルを学習する。AWS が保有する不正に関する知見が学習を補強する場合がある
• モデルのデプロイ: 学習済みモデルはバージョンとしてアクティブ化し、検出器に紐づけて推論に使えるようにする
• ルール評価: リアルタイム評価では、モデルが出した不正スコアと入力変数に対してルールを上から順に評価し、合致したルールのアウトカムを返す
• リアルタイムとバッチ: 単一イベントを即時評価する同期 API と、S3 上のデータセットをまとめて評価するバッチ予測ジョブの二方式がある

モデルの学習基盤・スケーリング・ハードウェア管理はすべて AWS 側が担います。

設計パターン / ベストプラクティス

• スコアとルールの分離: 機械学習モデルでリスクをスコア化し、業務上の判定はルールで表現する。しきい値やルールはモデルを再学習せずに調整できる
• アウトカムを段階化する: 二者択一にせず、「承認」「人手レビュー」「拒否」のように段階を設け、グレーゾーンはレビューへ回す
• 入力前段に組み込む: 登録 API や注文 API の処理経路で評価を呼び出し、結果に応じてフローを分岐する疎結合構成にする
• 継続的に再学習する: 不正の手口は変化するため、新しいラベル付きデータで定期的にモデルを更新する
• まずデータ品質から: 検知精度はラベルの正確さとデータ量に大きく左右される。十分な不正・正常イベントを整備してから学習する

運用・監視

• 評価 API の呼び出し回数やレイテンシ、エラー率は CloudWatch のメトリクスで監視する
• API 操作やモデル・検出器の変更といった監査証跡は CloudTrail に記録される
• バッチ予測ジョブの状態（完了・失敗）を確認し、後続処理や通知を EventBridge 経由で自動化する
• 本番のアウトカム分布やレビュー件数を継続的に観察し、しきい値やルールを定期的に見直す
• モデルの精度指標（学習時のスコア分布など）を確認し、劣化が見えたら新しいデータで再学習する

コスト

• 課金は基本的に、モデルの学習・ホスティングと、評価したイベント（予測）件数に応じた従量制で構成される
• リアルタイム評価とバッチ予測で課金の考え方が異なる傾向がある
• 学習済みモデルをアクティブにしている間はホスティングの費用が伴うため、使わないモデルは無効化を検討する

具体的な単価は変動するため、料金は公式の料金ページで確認してください。少量データで検証してから本番ボリュームを見積もるのが安全です。

セキュリティ

• アクセス制御は IAM で行い、学習データを置く S3 バケットや評価 API への最小権限のみを付与する
• 転送は TLS で保護し、S3 上の学習データは S3 側の暗号化（KMS 管理鍵を含む）で保存時を保護する
• 評価に使う変数にはメールアドレスや IP アドレスなどの個人情報が含まれるため、取得目的・保管期間・取り扱いに配慮する
• 不正検知ロジックそのものが攻撃者に推測されると回避されやすいため、ルールやしきい値の情報は限られた担当者のみが扱えるようにする

Well-Architected の観点

• セキュリティ: 機械学習でオンライン不正を検知し、IAM の最小権限と暗号化で学習データと判定ロジックを保護する。なりすましや不正注文という脅威への防御層を強化する
• 運用上の優秀性: マネージドサービスにより不正検知の運用負荷を下げ、CloudWatch や EventBridge で評価とジョブを可観測化・自動化する
• 信頼性: 評価を疎結合に組み込み、サービス呼び出しが失敗してもフロー全体が止まらないようフォールバックを設計する
• コスト最適化: 従量課金のため、使わないモデルは無効化し、評価件数に見合った構成にする

試験で問われるポイント

関連サービス・比較

汎用の機械学習プラットフォームである Amazon SageMaker でも不正検知モデルは作れますが、専門性と手間が異なるため比較します。

ハンズオン / CLI例

# 検出器を使って単一イベントの不正リスクを評価し、スコアとアウトカムを得る
aws frauddetector get-event-prediction \
  --detector-id my_fraud_detector \
  --detector-version-id "1" \
  --event-id "order-12345" \
  --event-type-name my_order_event \
  --entities '[{"entityType":"customer","entityId":"cust-9876"}]' \
  --event-timestamp "2026-06-14T00:00:00Z" \
  --event-variables '{"email_address":"user@example.com","ip_address":"203.0.113.10","order_amount":"199.99"}'