AIによる不正検知・異常取引検知｜誤検知と未検知をどう設計するか

結論：閾値を決める前に、誤検知と未検知の「1件あたりコスト」を決める

不正検知の相談で最も多いのが「どのくらいの閾値にすればよいか」という質問です。しかしこの問いには、閾値だけを見ていても答えが出ません。同じ検知性能でも、誤検知（正常な取引をアラートにしてしまうこと）と未検知（不正をアラートにできないこと）のどちらがどれだけ痛いかは、業務によってまったく違うからです。

本記事が勧める設計順序は次のとおりです。

1. 検知対象の業務を1つに絞って定義する
2. 誤検知1件のコストと未検知1件のコストを、内訳つきで金額として先に決める
3. その2つのコストを使って、閾値の候補ごとの総コストを混同行列から計算する
4. 総コストが小さく、かつ調査体制で処理しきれるアラート件数になる閾値を選ぶ

この順序を逆にすると——つまり閾値を先に決めてから「この件数なら回せるか」を後付けで議論すると——アラートは出るのに調査が追いつかず、担当者が形式的にクローズするだけの仕組みになります。後述する設例では、まったく同じ混同行列でも、コスト構造が違うだけで最適な閾値が逆転します。

もう一点、最初に確認しておきます。アラートは調査の起点であって、AIが不正を断定するものではありません。事実確認と認定は人が行います。誤って個人を疑うことの影響は取り返しがつかない場合があるため、判断者・判断日時・根拠資料・顧客への連絡内容を記録に残す設計が、検知精度と同じくらい重要になります。

全体像：不正検知の運用は6工程で回る

不正検知は「モデルを作る」プロジェクトではなく、毎日回り続ける業務プロセスです。工程を分けると次の6つになります。システムが担うのは①〜③まで、④以降は人の作業です。

この図で強調したいのは⑥のフィードバックです。調査した結果（不正だったのか、正常だったのか）をデータに戻さなければ、モデルは新しい正解を学べず、閾値の妥当性も評価できません。実務で最初に壊れるのはこの工程です。

本記事の方針：不正の手口は扱わない

先に断っておきます。本記事は検知する側の設計論に限定し、不正の具体的な実行手口、検知を回避する方法、閾値をすり抜ける手段は一切扱いません。類型名（架空取引、循環取引、資産の流用、なりすましによる取引など、一般に公表されている分類）に触れることはありますが、実行方法は書きません。

これは倫理上の理由だけではなく、実務上の理由でもあります。検知の条件（どの項目を、どの水準で見ているか）はそれ自体が統制の一部であり、社内でもアクセス範囲を限定して管理するのが通例です。記事に書けない情報は、社内でも「誰でも見られるフォルダ」に置くべきではない、と考えてください。

ステップ1：検知対象の業務を1つに絞って定義する

「不正検知」という言葉は範囲が広すぎます。設計を始める前に、次の4点で対象を1つに絞ります。

• 検知単位：1取引単位か、1口座（1顧客）単位か、1日単位の集計か。単位が違えば必要なデータも閾値も別物になります。
• 検知のタイミング：取引を成立させる前に止めるのか（リアルタイム）、成立後に事後検知するのか（バッチ）。前に止められるなら未検知コストは下がりますが、誤検知の影響は大きくなります。
• 検知の目的：被害の防止か、法令・社内規程に基づく報告のためか、内部統制の一環としての点検か。目的が違えば「見逃してはいけないもの」が変わります。
• 対象外の明示：この仕組みでは検知しないもの（別の統制で担保するもの）を書き出します。これを書かないと、後から「なぜ検知できなかったのか」という議論が際限なく広がります。

本記事では、仮設の決済事業者「東雲ペイメント株式会社」を使い、次の2業務を並べて設計します。数値はすべて理解のための仮設例です。

• 業務X：個人向けカード決済（少額・大量。月間取引10,000件。決済完了前に保留する運用）
• 業務Y：法人向け振込送金（大口・少数。取引を止めると取引先への支払遅延が発生する）

会計不正の点検も同じ枠組みで設計できます。たとえば関連当事者取引の網羅性確認や、会計不正のレッドフラグに対応した抽出条件は、本記事のいう「ルール」に相当します。決算数値そのものの正常化を議論するEBITDAの正常化調整や、財務指標から破綻確率を推定するAltman Zスコアは、いずれも「異常の疑いを絞り込む道具」という点で発想が近いものです。ただし本記事の主題は検知システムの設計と運用なので、これらには深入りしません。

ステップ2：誤検知コストと未検知コストを先に決める

ここが本記事の中心です。閾値を触る前に、次の2つの金額を内訳つきで決めます。

• 誤検知1件のコスト：調査にかかる工数、顧客への確認連絡、取引を保留したことによる機会損失、顧客体験の毀損。
• 未検知1件のコスト：直接の被害額、事後の返金・調査・報告対応、再発防止対応。

「金額に置けない要素があるから決められない」という反応をよく受けますが、精緻な金額を出すことが目的ではありません。目的は、誤検知と未検知の相対的な重さを関係者で合意することです。桁が合っていれば、閾値の議論は前に進みます。

業務Xは未検知が誤検知の60倍痛いので、多少うるさくても検知を広げるほうが有利になります。業務Yは誤検知の重みが12倍（60,000 ÷ 5,000）に上がるため、比率は5倍まで縮みます。この時点で、業務Xと業務Yに同じ閾値を使ってはいけないことが決まります。

なお、期待損失を「発生確率 × 損失額」で捉える考え方は与信の世界と共通です。損失の分解に慣れていない場合はクレジットリスク分析の基礎（PD・LGD・EAD）を先に押さえると、コストの内訳を組み立てやすくなります。

ステップ3：混同行列でトレードオフを数値化する

閾値の候補を2つ用意し、それぞれについて混同行列を作ります。設例の前提は次のとおりです。

• 対象期間：1か月。取引件数 10,000件
• そのうち事後に不正と認定された取引：20件（正常 9,980件、不正発生率 0.2%）
• パターンA：閾値を緩める（アラート300件）／パターンB：閾値を厳しくする（アラート60件）

計算の手順と検算

パターンA（アラート300件）

• 真陽性 TP ＝ 17件（アラートが出て、実際に不正だった）
• 偽陽性 FP ＝ 300 − 17 ＝ 283件
• 偽陰性 FN ＝ 20 − 17 ＝ 3件
• 真陰性 TN ＝ 9,980 − 283 ＝ 9,697件
• 合計の検算：17 ＋ 283 ＋ 3 ＋ 9,697 ＝ 10,000件（母数と一致）
• 適合率 ＝ TP ÷（TP＋FP）＝ 17 ÷ 300 ＝ 0.05667 → 5.7%
• 再現率 ＝ TP ÷（TP＋FN）＝ 17 ÷ 20 ＝ 0.85 → 85.0%

パターンB（アラート60件）

• 真陽性 TP ＝ 12件／偽陽性 FP ＝ 60 − 12 ＝ 48件
• 偽陰性 FN ＝ 20 − 12 ＝ 8件／真陰性 TN ＝ 9,980 − 48 ＝ 9,932件
• 合計の検算：12 ＋ 48 ＋ 8 ＋ 9,932 ＝ 10,000件（母数と一致）
• 適合率 ＝ 12 ÷ 60 ＝ 0.20 → 20.0%
• 再現率 ＝ 12 ÷ 20 ＝ 0.60 → 60.0%

閾値を厳しくすると調査効率（適合率）は5.7%から20.0%へ約3.5倍に改善しますが、見逃しは3件から8件へ増えます。どちらが良いかは、この数字だけでは決まりません。ここでステップ2で決めたコストを掛けます。

総コストで比べると、業務によって答えが逆転する

まったく同じ検知性能なのに、最適な閾値が逆になりました。業務Xでは閾値を緩めたAが325,000円有利、業務Yでは閾値を厳しくしたBが12,600,000円有利です。閾値を先に決めていたら、この逆転には気づけません。

体制の制約も同時に確認する

総コストが最小でも、調査体制が回らなければ絵に描いた餅です。1か月の稼働を1名あたり160時間とすると：

• 業務X・パターンA：300件 × 0.5時間 ＝ 150時間/月 → 専任1名でほぼ埋まる（150 ÷ 160 ＝ 0.94名）
• 業務X・パターンB：60件 × 0.5時間 ＝ 30時間/月（0.19名）
• 業務Y・パターンA：300件 × 1.5時間 ＝ 450時間/月 → 約2.8名分（450 ÷ 160 ＝ 2.81名）で現実的でない
• 業務Y・パターンB：60件 × 1.5時間 ＝ 90時間/月（0.56名）

業務YでパターンAを選べないのはコストだけの問題ではなく、体制からも無理だと分かります。コスト計算と体制計算の両方で同じ結論が出るとき、その閾値は説明できる閾値になります。

なお、この設例には実務上の重要な留保があります。「実際の不正20件」は事後に認定できた件数であり、真の不正件数ではありません。アラートが出なかった取引の中に、誰も気づかないまま終わった不正が残っている可能性は常にあります。したがって再現率は原理的に「上限の推定値」であり、100%に近い数字が出たときほど、母数の定義を疑うべきです。

ステップ4：ルールベースと機械学習を使い分ける

「機械学習にすれば精度が上がる」という説明を見かけますが、実務ではそう単純ではありません。両者は目的が違うので、優劣ではなく役割分担で考えます。分類モデルや過学習といった機械学習そのものの基礎はファイナンスのための機械学習入門で扱っているため、ここでは検知設計の観点だけを比較します。

ステップ5：検知設計シートに落とす（本記事の成果物）

ここまでの検討を1枚にまとめたものが検知設計シートです。業務ごとに1枚作り、変更のたびに版を更新します。記入例は業務X（東雲ペイメントの個人向けカード決済・パターンA採用）です。

ステップ6：トリアージとエスカレーションを設計する

アラートが出た後の設計を省くと、検知の精度を上げても成果につながりません。最低限、次の3つを決めます。

1. 優先度の区分と対応期限：区分を作るだけでなく期限を書きます。期限のない区分は、実際には全件が同じ扱いになります。
2. 一次判断で「解除してよい範囲」：一次担当者がどこまで自分の判断で解除できるかを明文化します。ここが曖昧だと、全件が第2線に上がって滞留します。
3. エスカレーションの条件：件数・金額・繰り返しの有無など、客観的に判定できる条件で書きます。「怪しいと感じたら」は基準になりません。

調査工程の一部を自動化したくなる場面もありますが、取引の保留・解除や顧客への連絡といった外部に影響する操作を、AIに自律実行させる設計は勧められません。自律性の段階と統制の考え方はAIエージェントの自律性3段階と統制設計で整理しています。本記事の文脈では、AIは「情報を整理して人に渡す」までにとどめる設計が妥当です。

AIに任せる部分と人が判断する部分

もう一度書きます。アラートは「調査を始めるべき候補」であって、「不正である」という判定ではありません。この区別を運用側が共有していないと、担当者がアラート＝クロと受け取り、顧客への説明が不用意になります。誤って個人を疑うことは、金銭的な損害よりも回復が難しい影響を与える場合があります。だからこそ、判断の根拠と経緯を残す記録設計が必要になります。

プロンプト例と出力例

生成AIは、検知設計そのものを代行する道具ではなく、設計の抜けを洗い出す道具として使うのが実務的です。以下は業務特化の完成形プロンプトです。いずれも、不正の実行方法や検知回避の方法を出力させない禁止条項を含めています。

プロンプト①：検知設計シートの初期案を作らせる

【役割】あなたは金融機関・決済事業者の不正検知の運用設計を支援するアナリストです。検知する側の設計論のみを扱います。

【目的】以下の業務について、検知設計シート（15項目）の初期案を作成してください。私はこれを叩き台として使い、最終的な内容は自分で決定します。

【入力情報】
- 事業：カード決済（個人向け・少額大量）
- 対象期間：直近1か月
- 月間取引件数：10,000件（うち事後に不正と認定：20件）
- 検知タイミング：決済完了前に保留する運用
- 調査体制：専任1名（月160時間稼働）、1件あたり調査0.5時間
- 誤検知1件のコスト：5,000円（内訳＝調査3,000円＋機会損失2,000円）
- 未検知1件のコスト：300,000円（内訳＝直接被害200,000円＋事後対応100,000円）
※実データは含みません。上記はすべて仮設の数値です。

【単位】金額は円、件数は件、工数は時間で統一。他の単位に変換しない。

【出力形式】以下の15行のMarkdown表。列は「#／記入項目／記入案／根拠／確認が必要な点」。
1 対象業務・検知単位／2 検知タイミングと目的／3 検知しないもの／4 ルール群の位置づけ／
5 モデルの種類と出力／6 入力データと更新頻度／7 誤検知1件のコスト／8 未検知1件のコスト／
9 閾値と選定根拠／10 想定アラート件数と体制／11 トリアージ基準／12 エスカレーション基準／
13 記録項目／14 監視指標と頻度／15 再学習の頻度・条件・承認者

【計算方法】
- アラート件数の候補を3つ（60件・150件・300件）置き、それぞれについて偽陽性件数・偽陰性件数を仮定したうえで、
  総コスト ＝ 偽陽性件数 × 5,000円 ＋ 偽陰性件数 × 300,000円 を計算する。
- 適合率 ＝ 真陽性 ÷（真陽性＋偽陽性）、再現率 ＝ 真陽性 ÷（真陽性＋偽陰性）で計算する。
- 四隅の合計が10,000件と一致することを必ず確認し、確認結果を明記する。
- 各候補について、調査時間（アラート件数 × 0.5時間）と月160時間の比較を示す。

【禁止事項】
- 不正の具体的な実行手口、検知を回避する方法、閾値をすり抜ける手段は書かない。
- 特定の閾値を「正解」として断定しない。判断材料の提示にとどめる。
- 法令・ガイドラインの適用可否について断定的な解釈を書かない。
- 実在の企業名・製品名を根拠なく挙げない。

【不明情報の処理】前提が不足している項目は「不明」と書き、何が分かれば埋まるかを1行で示す。推測で数値を作らない。

【出典の表示】一般的な考え方に依拠した記述には、それが一般論であることを明記する。統計や事例を挙げる場合のみ出典名を書き、確認できない場合は「出典を確認できず」と書く。

【検算】表の後に、3候補それぞれの「真陽性＋偽陽性＋偽陰性＋真陰性＝10,000件」の式を数字で書き出す。

【レビュー項目】最後に、私が人として確認すべき点を5つ、箇条書きで挙げる。

出力例（抜粋・要約）

この出力を受け取ったあと、人が確認すべきことは明確です。「TP12・15・17」という仮定はAIが置いたものであり、実測ではありません。実際の運用では、閾値を動かした検証データで各候補の内訳を実測し直す必要があります。AIの出力は「検討すべき候補と計算の型」を提供するところまでです。

プロンプト②：アラートの一次確認用に事実を整理させる

【役割】あなたは不正検知アラートの一次確認を行う担当者を補助するアシスタントです。判断は行わず、事実の整理のみを行います。

【目的】以下のアラート情報から、調査担当者が最初の5分で状況を把握できる要約を作成してください。

【入力資料】（すべてマスキング済み。氏名・口座番号・カード番号・住所・電話番号は含まれていません）
- アラートID、発生日時、リスクスコア、該当したルールの識別番号
- 直近90日の同一顧客ID（記号化済み）の取引件数・金額の推移（集計値のみ）
- 過去の同種アラートの件数と、その一次判断の結果（解除／継続調査）

【対象期間】アラート発生日を含む直近90日。

【単位】金額は円、件数は件。期間は日数。

【出力形式】
(1) 3行以内の状況要約
(2) 「確認済みの事実」の箇条書き（入力資料に明示されている情報のみ）
(3) 「未確認の事項」の箇条書き（判断に必要だが入力資料にない情報）
(4) 一次担当者への質問リスト（3つまで）

【禁止事項】
- 不正か否かの判断・断定を書かない。「不正の可能性が高い」等の評価表現も使わない。
- 入力資料にない事実を補わない。一般的な傾向から個別案件を推測しない。
- 不正の手口や検知回避の方法には言及しない。
- 個人を特定しうる記述を生成しない。記号化されたIDのみを用いる。

【不明情報の処理】入力資料から読み取れない事項は、(3)に「不明」として列挙する。空欄にしない。

【出典の表示】(2)の各項目について、入力資料のどの項目に基づくかを括弧書きで示す。

【検算】(2)に数値を書く場合は、入力資料の数値をそのまま転記し、加工した場合は計算式を併記する。

【レビュー項目】最後に「この要約だけでは判断できない理由」を1行で書く。

②のプロンプトで重要なのは、AIに「不正の可能性が高い」といった評価表現を書かせないことです。評価語が入ると、それを読んだ担当者の判断が引きずられます。AIの役割は、確認済みの事実と未確認の事項を分けて並べるところまでです。

モデル監視項目と再学習

不正検知は「作って終わり」がありません。手口も取引の分布も変わるため、放置したモデルは静かに劣化します。監視すべき項目を8つに整理しました。

とくに⑤のフィードバックループを強調します。調査結果をラベルに戻す運用が止まると、再学習の教師データが古いまま固定され、③の適合率も測れなくなります。滞留の上限日数（たとえば「調査開始から30日以内に結果を入力する」）を決め、その遵守状況を監視項目に入れてください。

また、⑥の再学習では「新モデルのほうが良い」と判断する基準を事前に決めておくことが重要です。並行稼働させてから基準を決めると、都合の良い指標を後から選ぶことになります。モデルの版と学習データの範囲を記録に残す点は、モデルのバージョン管理の考え方と共通です。

検知結果の検証方法

AI出力全般の検証手順（出典の実在確認・数値転記・計算再現・論理整合の4層）は生成AI出力の検証手順で扱っています。ここでは不正検知に固有の検証項目だけを挙げます。

1. 四隅の合計が母数と一致するか：TP＋FP＋FN＋TN が対象期間の全件数と一致すること。ここがずれる原因の多くは、期間の切り方（取引日基準か認定日基準か）の混在です。
2. 分母の定義が揃っているか：適合率の分母は「発報したアラート件数」か「調査を完了したアラート件数」か。前者と後者では数値が変わります。シートに定義を書いておきます。
3. 「実際の不正件数」の出所：確定した認定件数なのか、推定を含むのか。推定を含む場合は再現率に「推定」と明記します。
4. ラベルの汚染がないか：調査未了のアラートを「正常」に含めていないか。未了は未了として別区分にします。データの妥当性チェックの一環として、ラベル区分の定義を先に固定します。
5. 比較の母集団が同じか：閾値変更の前後を比べるとき、取引の構成（季節性・キャンペーン・チャネル比率）が変わっていないか。変わっていれば、指標の変化は閾値の効果ではありません。
6. コスト単価の根拠資料：誤検知・未検知の単価に、実績に基づく裏づけ資料があるか。仮置きなら「仮置き」と明記し、いつ見直すかを決めます。
7. 再現できるか：同じ入力・同じ設定で同じ結果になるか。AIに集計させた場合は、少なくとも1度は表計算ソフトで独立に再計算します。

機密情報・個人情報の注意

不正検知の周辺には、取引明細・顧客属性・調査記録といった機微な情報が集中します。個人を特定できる情報や検知条件そのものを、外部の生成AIサービスにそのまま入力することは避けてください。プロンプトに渡すのは集計値・記号化済みIDに限り、実データを扱う場合は社内で許可された環境に限定します。生成AIサービスの利用にあたっては、個人情報保護委員会が2023年6月2日付で注意喚起を公表しており、利用目的の達成に必要な範囲かどうかの確認が求められています。具体的な社内ルールの作り方は生成AIに入れてよい情報・いけない情報を参照してください。

よくある失敗

1. 閾値を先に決め、コストを後付けする。「まず動かしてみる」と言って閾値を置くと、そのあと出てくるコスト議論は追認になります。順序を守るだけで議論の質が変わります。
2. 正解率（Accuracy）だけを見る。設例では全件を「正常」と判定しても正解率は 9,980 ÷ 10,000 ＝ 99.8% になります。不正のような希少事象では正解率は指標になりません。適合率・再現率・総コストで見ます。
3. 調査結果をラベルに戻さない。フィードバックが切れると、再学習も指標の測定もできなくなります。検知の性能ではなく運用の設計不備で劣化します。
4. 体制と無関係にアラート件数を決める。処理しきれない件数を出すと、担当者は形式的にクローズせざるを得ません。アラート疲れは見落としの温床です。
5. アラートを「不正の判定」として扱う。顧客への連絡や取引の扱いをアラートだけで決めると、誤って個人を疑うことになります。認定は調査の結果としてのみ行い、判断の根拠を記録します。

実務チェックリスト

• 検知対象の業務を1つに絞り、検知単位（取引／口座／日次集計）を明記したか
• この仕組みで検知しないものを書き出し、別統制で担保する旨を明記したか
• 誤検知1件のコストを、内訳つきの金額で決めたか
• 未検知1件のコストを、内訳つきの金額で決めたか
• 閾値の候補を2つ以上置き、それぞれの混同行列を整数で作ったか
• 四隅の合計が対象期間の全件数と一致することを検算したか
• 適合率・再現率を計算し、正解率だけで判断していないか
• 候補ごとの総コストを計算し、最小になる候補を確認したか
• 想定アラート件数に対する調査工数を計算し、体制で処理できるか確認したか
• ルールとモデルの役割分担を決め、どちらか一方に寄せていないか
• トリアージの区分に対応期限を設定したか
• エスカレーション条件を客観的に判定できる形で書いたか
• 判断者・判断日時・根拠資料・顧客への連絡内容を記録する様式を用意したか
• 監視8項目それぞれに頻度と異常時アクションを割り当てたか
• 調査結果をラベルに戻す運用と、その滞留上限日数を決めたか
• 再学習の頻度・臨時実施の条件・承認者を決めたか
• 閾値やルールの変更履歴を、承認記録とあわせて残す仕組みがあるか

日本企業・日本市場での留意点

制度面の要求は業態によって大きく異なります。以下は概観であり、適用の可否や具体的な水準については所管当局の公表資料および専門家の確認が必要です。本記事は断定的な解釈を示すものではありません。

• 金融機関のマネー・ローンダリング対策：金融庁は「マネー・ローンダリング及びテロ資金供与対策に関するガイドライン」を公表しており、直近では2026年3月31日に一部改正版が公表されています（パブリックコメントは18団体52件、同日適用）。リスクに応じた取引モニタリング・フィルタリングの実効性確保が求められています。対象範囲や具体的な対応水準は同ガイドラインおよびFAQで確認してください。
• モデルを使う金融機関のガバナンス：金融庁「モデル・リスク管理に関する原則」（2021年11月12日、全15ページ）は、①ガバナンス②モデルの特定・インベントリー管理及びリスク格付③モデル開発④モデル承認⑤継続モニタリング⑥モデル検証⑦ベンダー・モデル及び外部リソースの活用⑧内部監査、の8原則で構成されています。同原則が直接の対象としているのは本邦G-SIBs・D-SIBs等の限られた先ですが、対象外の事業者にとっても、監視・検証・承認・内部監査という枠組みの整理は参考になります。
• 事業会社の内部統制：財務報告に係る内部統制の評価及び監査の基準・実施基準は2023年4月7日に改訂の意見書が公表され、2024年4月1日以後開始する事業年度から適用されています。内部統制報告制度（J-SOX）の枠組みの中で、不正リスクへの対応をどう位置づけるかは各社の評価範囲の設計次第です。
• AI利用全般の指針：総務省・経済産業省「AI事業者ガイドライン」は2026年3月31日に第1.2版が公表されています。金融庁は2026年3月3日に「AIディスカッションペーパー（第1.1版）」を公表し、AIエージェントに関する章を新設しています。
• 会計・監査の文脈：日本公認会計士協会は2024年8月13日にテクノロジー委員会研究文書第11号「監査におけるAIの利用に関する研究文書」を公表しています。監査人の判断をAIが代替するという整理ではない点に注意してください。

よくある質問（FAQ）

Q. 適合率が5.7%というのは低すぎませんか。20件調べて19件が空振りという意味ですよね。
A. 業務によっては合理的な水準です。設例の業務Xでは未検知1件のコストが誤検知の60倍あるため、空振りを許容して見逃しを減らすほうが総コストが小さくなります。逆に業務Yのように誤検知のコストが高い業務では、同じ5.7%は許容できません。適合率の目標値は、業務のコスト構造から逆算して決めるものであり、業界平均を写すものではありません。ただし、体制で処理できる件数を超える設定にしないことが前提です。

Q. ルールをすべて機械学習モデルに置き換えることはできますか。
A. 実務では併用が基本です。ルールには「必ず止めるべきものを、説明可能な形で確実に止める」という役割があり、モデルには「ルールで書けない広い範囲に優先度をつける」という役割があります。モデルに一本化すると、なぜその取引を止めたのかを説明する負荷が跳ね上がり、変更時の影響範囲も読みにくくなります。表3の5観点で、自社にとってどちらの弱点が致命的かを判定してください。

Q. 不正の手口を詳しく知らなければ、検知は設計できないのではありませんか。
A. 検知する側に必要なのは、手口の詳細ではなく①どの業務のどの工程が弱点になりうるか、②その弱点が突かれたときデータ上どこに痕跡が残るか、③その痕跡を確認できる記録が揃っているかの3点です。手口の詳細は、社内でもアクセス範囲を限定して管理すべき情報であり、広く共有するものではありません。設計の議論は「痕跡と記録」の側から進めるほうが、実務的にも安全です。

まとめ

不正検知の設計は、閾値の技術論から始めると必ず行き詰まります。先に誤検知1件と未検知1件のコストを内訳つきで決め、そのコストで閾値の候補を評価する——この順序を守るだけで、議論は「なんとなく厳しめ／緩め」から「金額と体制で説明できる設定」に変わります。設例では、同じ混同行列でもコスト構造が違うだけで最適な閾値が逆転しました。

ルールベースと機械学習は優劣ではなく役割分担で考え、併用を前提に設計します。作った後は、検知率・アラート件数・データドリフト・フィードバックの滞留・担当者の負荷といった監視項目を回し続けることが必要です。そして最後に、アラートは調査の起点であり、AIが不正を断定するものではありません。事実の認定は人が行い、その判断の根拠と経緯を記録に残す。この一線を守ることが、検知精度を上げること以上に重要です。

出典・参考（2026-08-03確認）

• 金融庁「『マネー・ローンダリング及びテロ資金供与対策に関するガイドライン』の一部改正（案）に対するパブリックコメントの結果等について」（2026年3月31日公表）　https://www.fsa.go.jp/news/r7/amlcft/20260331/20260331.html （ガイドライン本文：https://www.fsa.go.jp/news/r7/amlcft/20260331/02.pdf ）
• 金融庁「金融機関におけるマネロン・テロ資金供与・拡散金融対策について」　https://www.fsa.go.jp/policy/amlcftcpt/index.html
• 金融庁「モデル・リスク管理に関する原則」（2021年11月12日）　https://www.fsa.go.jp/common/law/ginkou/pdf_02.pdf
• 金融庁「AIディスカッションペーパー（第1.1版）金融機関等におけるAIの活用実態と健全な利活用の促進に向けた初期的な論点整理」（2026年3月3日公表）　https://www.fsa.go.jp/news/r7/sonota/20260303/aidp.html
• 金融庁「『財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準の改訂について（意見書）』の公表について」（2023年4月7日）　https://www.fsa.go.jp/news/r4/sonota/20230407/20230407.html
• 総務省・経済産業省「AI事業者ガイドライン（第1.2版）」（2026年3月31日公表）　https://www.soumu.go.jp/main_sosiki/kenkyu/ai_network/02ryutsu20_04000019.html
• 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」（2023年6月2日）　https://www.ppc.go.jp/news/careful_information/230602_AI_utilize_alert/
• 日本公認会計士協会「テクノロジー委員会研究文書第11号 監査におけるAIの利用に関する研究文書」（2024年8月13日）　https://jicpa.or.jp/specialized_field/20240813dfu.html
• 日本銀行「金融システムレポート別冊：金融機関における生成AIの利用状況とリスク管理」　https://www.boj.or.jp/research/brp/fsr/fsrb241021.htm
• Corporate Finance Institute「AI Anomaly Detection in Finance Using ChatGPT」　https://corporatefinanceinstitute.com/resources/fpa/ai-anomaly-detection-chatgpt-finance/

※本記事に登場する東雲ペイメント株式会社および取引件数・不正件数・コスト単価は、すべて理解のための仮設例です。実在の企業・統計に基づくものではありません。制度に関する記述は公表資料の存在と公表日を示したものであり、適用可否の解釈を示すものではありません。

※本記事は教育目的の一般的な解説であり、法務・税務・会計・投資に関する助言ではありません。実際の判断は専門家にご確認ください。設例は理解のための仮設例です。AI製品の仕様・料金は変更されることがあるため、利用前に各社の公式情報をご確認ください。