不正送金検知システムの開発は、シナリオ定義、データ棚卸し、PoC、並行運用、本番化、継続チューニングの6段階で進めます。
この順に段階を踏めば、投資と顧客影響を管理しながら対策を強められます。全体像は、不正送金検知システム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・不正送金検知システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
不正送金検知システムの全体像
不正送金検知システムは、顧客・端末・取引・送金先の情報を組み合わせて、ログインや口座開設から問い合わせまでの場面をまたぎ、取引ごとのリスクを評価する業務基盤です。
不正送金検知システムには、スコアを返すだけで終わらず、追加認証、保留、担当者の調査、出金停止、凍結、顧客確認まで実行できる業務フローが必要です。
不正送金検知とAML/CFT・認証強化の違い
不正送金検知、AML/CFT、認証強化は、それぞれ担う範囲が異なります。認証だけでは補えない不正もあるため、違いを押さえておくことが大切です。
- 不正送金検知：口座乗っ取り、フィッシング、マネーミュール、高額・連続送金を、取引の直前や実行中に判定する役割です。
- AML/CFT：顧客リスク評価、取引監視、疑わしい取引の確認・届出を含む、広範なマネー・ローンダリングおよびテロ資金供与対策です。
- 認証との違い：認証後にだまされて送金するケースや、正規端末の不正操作は、認証だけでは防ぎにくい点です。
不正送金検知とAML/CFTのデータは連携できますが、リアルタイムの送金阻止と継続監視では、担当部署も判断基準も異なります。
警察庁によると、令和6年のインターネットバンキング不正送金事犯は4,369件に上り、被害額は約86億8,900万円でした（出典：警察庁「令和7年警察白書」、2025年）。このため、認証、端末・取引分析、検知後の業務を重ねて対策を組み立てます。
主な検知機能と業務機能
検知方式は、設定条件で見るルール検知、通常の行動との差を見る属性・行動分析、複数の関係から資金の流れを探すネットワーク分析に分けられます。
- ルール検知：取引の金額・頻度・時間帯、送金先、名義変更、ログイン失敗回数を条件に当てはめる方式です。
- 属性・行動分析：IPアドレス、端末、ブラウザ、位置、時刻、普段の操作傾向を通常の行動と比べ、その差を見ます。
- ネットワーク分析：顧客、口座、電話番号、端末、IP、送金先の関係をたどり、資金循環や受け子口座を探す手法です。
業務機能では、アラートの優先順位付け、ケース割り当て、調査メモを管理します。対応では、顧客確認、追加認証、保留を扱い、停止・凍結・解除につなげます。解約、届出、警察連携も管理します。
判定理由・利用データ・ルールやモデルの版・担当者の操作履歴は、監査ログに残します。さらに、検知エンジンとケース管理が別製品でも、同じ取引IDで一連の措置を追えるように設計します。
リアルタイム検知と事後調査の接続
即時判定と事後調査をつなぐには、応答と障害時の方針、履歴の管理を一体で決めておく必要があります。
- リアルタイム判定：振込指示を受けてから顧客体験を損なわない時間内に、許可、追加認証、保留、拒否のいずれかの結果を返す役割です。
- 判定要件：許容時間、ピーク取引量、タイムアウト時、検知エンジン停止時に送金を止めるか通すかの判断基準です。
- 事後調査：数時間から数年の履歴を横断して調べるための、保管期間と検索性能の設計です。
警察庁と金融庁は2025年9月、口座開設時の実態把握、多層的な検知、シナリオ・閾値の精緻化、検知後の顧客確認や出金停止などを要請しました。この要請の出典は、警察庁「預貯金口座の不正利用等防止に向けた対策の一層の強化について」（2025年）です。
この要請には、凍結・解約、金融機関間の情報共有、警察との連携も含まれます。そのため、検知後に誰が何分以内に動くかまで、システムの対象に含めます。
不正送金検知システム開発の進め方・流れや手順
開発は、AIの方式を選ぶより先に、被害シナリオと業務アクションを決めることから始めます。データを確認し、PoCで検証してから本番化します。
企画から運用改善までは、6段階で進みます。シナリオ定義・データ棚卸し・PoC・並行運用・本番化・継続チューニングの順です。
被害シナリオと対象チャネルの定義
被害の起点から受け子口座への送金まで、取引がどう変わるかを業務シナリオに落とし込んでおきます。
- 口座乗っ取り：フィッシングや、普段と異なる端末からのログインを捉える場面です。
- 不自然な送金：登録直後の高額送金や、短時間の複数口座への振込が対象です。
- 口座・送金先の変化：名義変更直後の送金、休眠に近い口座からの急な出金、受け子口座への集中が手がかりになります。
各シナリオには、対象チャネル、利用データ、判定時点を対応づけます。さらに、スコア範囲、顧客表示、追加認証、保留時間も対応づけます。
担当者への通知先、停止・凍結の権限者、解除条件も書き出します。そのうえで、高リスクは保留・追加認証、中リスクは要確認、低リスクは許可から始め、実績を見て即時拒否へ移します。その後は、顧客影響と調査能力に応じて判定を細分化します。
データの棚卸しと要件定義
要件定義では、データの所在と品質、利用条件を確かめたうえで、学習用と判定用を分けておきます。
- 対象データ：顧客、口座、取引、ログイン、端末、IP、位置、送金先、問い合わせ、凍結履歴、不正確定情報が対象です。
- データの条件：所在、粒度、保存年数、項目名、コード体系、タイムゾーン、匿名化、利用目的、データオーナー、外部提供可否を一覧にします。
- 要件：判定レイテンシ、ピーク時TPS、可用性、障害時対応、暗号化、権限分離、監査ログ、保持期間、モデル版管理に関する定めです。
不正ラベルが少ない場合は、担当者の判断や凍結・組戻しの結果を暫定ラベルとして使えます。ただし、見逃しや判断差が含まれるため、学習前に品質を確かめておく必要があります。学習データとリアルタイム判定データは、分けて設計します。
PoCでのルールとAIの効果比較
PoCの結果で本番適用を判断するには、検知性能と現場の処理負荷を合わせて評価することが欠かせません。
- 検知性能：再現率、適合率、False Positive率で測ります。
- 業務負荷：アラート件数、1件あたりの調査時間、停止から解除までの時間。
- 事業・顧客影響：判定速度、被害抑止額、正常顧客への影響の評価です。
ルールのみ、機械学習のみ、両者の組み合わせを比べます。精度が高くても、担当者が処理できないアラートが多ければ、本番運用には適しません。
NICTは2025年、4行の銀行とのプライバシー保護連合学習の実証を公表しました。個別モデルとの比較では、適合率が最大約10ポイント向上し、再現率は95％を超えました（出典：NICT「DeepProtectを活用した銀行の不正口座検知の実証実験」、2025年）。
同実証では、銀行間のデータ項目や定義の違いも課題でした。そのため、データ定義をそろえる工数や、個人情報を外部に出さずに学習できるかも評価します。
並行運用から本番化・継続改善まで
本番導入は、既存環境で挙動を確かめてから自動化し、稼働後の結果も改善に反映する順に進めます。
- 並行運用：既存のAML・不正検知サービスと並べて動かし、判定理由とアラート量を一定期間、担当者が確かめる段階です。
- 段階的な有効化：一定期間の実績を見てから、低リスクの自動許可、高リスクの保留・追加認証を順に導入する流れ。
- 本番化：低遅延連携、二重化、暗号化、監視、ログ集中管理、モデルレジストリ、変更承認、ロールバック、障害迂回、夜間休日の連絡体制を揃える。
- 継続改善：月次または週次の実績確認と、ルール・モデルの更新。
自動停止をいきなり始めると、誤検知による送金不能や問い合わせの急増が起きるおそれがあります。
本番連携には、APIまたはメッセージングを使います。月次・週次の確認では、手口、検知率、誤検知率、調査時間を見ていきます。さらに、凍結解除時間、被害額、顧客苦情も見ていきます。
2026年7月10日施行の改正犯罪収益移転防止法では、送金犯罪に関する罰則が設けられています（出典：警察庁「令和8年犯罪収益移転防止法の改正について」、2026年）。そのため、制度変更の影響は法務・コンプライアンスの担当と定期的に確かめます。
不正送金検知システムの費用相場とコストの内訳
公開されている定価は少なく、見積もりは取引量・対象チャネル・データ量・既存システムとの接続・国内保管・監査・冗長化・運用体制によって変わります。
一般的なAI開発の公開相場を土台に、金融機関向けのセキュリティ、可用性、監査、業務連携を加えて段階別の概算にすると、稟議で使いやすくなります。
PoC・小規模導入の費用相場
PoCと1チャネル導入では、費用帯も得られるものも異なります。そのため、企画の段階で範囲をそろえて見積もります。
- データ診断・PoC：200万〜800万円。抽出、匿名化、整形、ベースライン、ルール・モデル比較、精度レポートまでを想定します。
- 小規模導入：1チャネルのクラウド・API連携で500万〜2,000万円。API、管理画面、通知、限定的なルール設定、テスト環境が範囲です。
各費用帯は、いずれも正式な価格ではなく、金融要件を加味した企画用の推定です。
参考になるのは、株式会社LASSICが公表している一般的なAI開発費用です。PoCは100万〜500万円、本番システムは1,000万〜5,000万円、運用保守は月50万〜300万円とされています（出典：株式会社LASSIC「AI開発委託外注の進め方と注意点」、2026年確認）。
不正送金案件では、機密データ、24時間運用、誤検知時の顧客対応、監査証跡、勘定系接続が加わります。このため、一般的なAI PoCより高くなる可能性があります。
本番構築・複数チャネル対応の費用相場
本番化の構成を検討するときは、導入形態とチャネルの広がりに応じた費用帯を比べます。
- パッケージ・クラウド：本番導入では2,000万〜8,000万円が目安です。
- 複数チャネル：中堅金融機関では8,000万〜2億円が目安です。口座開設、ログイン、振込、カード・決済、AML連携などを含みます。
- 大規模構築：スクラッチや共同基盤は、2億〜5億円超になる場合があります。
大規模構築では、勘定系・情報系・外部機関との連携と、独自モデルが含まれることがあります。加えて、冗長化や全国規模の移行・監査も含まれることがあります。
費用の内訳の目安は、要件定義が10〜15％、データ連携・ETLが15〜25％です。検知ロジックとモデル、アプリ・ケース管理も、それぞれ15〜25％です。
セキュリティ・監査・テストは15〜25％で、移行・教育・プロジェクト管理も加わります。さらに、連携先が増えると、接続仕様の調査や性能試験に工数がかかります。障害時の再送、データ項目の変換、どこまでを誰が受け持つかの調整も必要です。
運用費と5年TCOの見積もり
取引量や運用体制によって月額費用は変わります。そのため、必要なサービス範囲と5年間の支出を分けて確かめます。
- 基本運用：月額50万〜300万円程度が起点です。
- 大規模運用：高取引量、複数リージョン、専用監視、24時間365日の有人対応、厳格なログ保管などがあると、月額300万〜1,000万円超になることもあります。
- 5年TCO：取引件数、クラウド・ライセンス、追加開発、監視、保守、制度対応、教育、切替、終了時の移管を含めて見る、5年間の総額です。
基本運用には、SaaSやクラウド推論の利用、ログ保管、監視に加えて、ルール調整、モデル再学習、データ品質管理、障害対応、夜間休日対応が含まれます。
初期費用だけで比べると、再学習、ルール変更支援、API従量課金を見落としがちです。また、データ保管、専用環境、サポート、解約時の移行費も、初期費用には表れにくい項目です。
ROIを説明するときは、被害抑止額と調査工数の削減額を分けて示します。
不正送金検知システムの見積もりを取る際のポイント
見積もりの精度は、発注側が条件をどこまでそろえられるかで決まります。そのため、対象チャネル、取引量、判定時間、データ項目をRFPに記載します。あわせて、検知後のアクション、KPI、監査、運用体制も記載します。
「AIで不正を見つけたい」という依頼のままでは、社ごとに前提が異なります。共通条件を示したうえで、複数社を比べます。
RFPへの対象範囲・処理性能の記載
ベンダー間で提案条件をそろえるため、RFPでは対象範囲、処理性能、環境・保管条件を具体的に書きます。
- チャネル・接続先：口座開設、ログイン、振込、送金先登録、カード・決済、ATM、資金移動と、勘定系、AML、本人確認、通知、ケース管理との接続。
- 処理性能：月間取引件数、ピーク時TPS、同時接続数、許容レイテンシ、アラート保持件数。
- 環境・保管：ログ保存年数、データセンター地域、開発・本番環境の分離を数値で示す項目です。
「外部連携一式」「セキュリティ対応一式」のような書き方は避けます。代わりに、接続方式、電文、認証、証明書を、項目ごとに分けて書きます。さらに、再送、タイムアウト、監視、試験環境、障害時窓口も、項目を分けて書きます。
自動停止を採用する場合は、解除権限・顧客通知・誤停止時の補償と復旧・手動運用への切替条件を、要件に含めます。
検知率以外のKPIと受入条件
再現率を上げると、正常な取引までアラートになる場合があります。このため、モデルと現場の両方を評価できる指標をそろえます。
- 検知指標：再現率、適合率、False Positive率で評価します。
- 業務指標：1日あたりのアラート数、担当者1人あたりの処理数、調査時間。
- 顧客・損失指標：追加確認率、停止後の解除時間、被害抑止額を見る指標です。
受入条件は、指定した期間とデータを使って、数値で定めます。
たとえば、再現率が何％以上か、適合率が何％以上か、判定時間が何ミリ秒以内かを示します。
判定理由のケース画面表示と監査ログの追跡も、条件に含めます。ラベル品質が低い場合は、数値の限界と本番後の再評価時期も、契約や計画に記載します。
パッケージ・クラウド・スクラッチの比較
導入期間、業務の独自性、データ管理、運用人材の条件に照らして、構成を選びます。
- クラウド・パッケージ：短期導入や既存サービスの活用を優先するなら、API連携で構成する形になります。
- ハイブリッド：独自業務やデータ主権が大きい場合に現実的で、検知エンジンは外部サービス、顧客・取引データとケース管理は自社で持ちます。
- スクラッチ：独自知見を競争力にでき、長期の運用人材と投資を確保できる場合の選択肢です。
比較では、本番実績、シナリオ更新頻度、リアルタイム性能を見ます。さらに、AIの説明可能性、API・イベント連携、国内保管も見ます。
モデル・ルールの所有権、障害時の受け持ち範囲、再委託、保守費、解約時のデータ返却も、比べる対象になります。
たとえば、NTTデータのCAFIS Brainは、700種類以上の不正判定ルール、導入企業によるルール・スコア調整、リンク分析を特徴として公開しています（出典：NTTデータ「CAFIS Brain」、2026年確認）。
機能の数だけでなく、自社で変更・説明・運用できる範囲を比べます。
障害・データ・モデルの責任の分け方
契約の前に、障害時の判断、データの扱い、成果物（モデル・ルール）の権利と責任分担を明らかにしておきます。
- 障害対応：停止・継続・手動審査の方針、復旧目標、代替手段、通知、事後突合。
- 対象範囲：検知エンジン、本人認証、勘定系、通知、ケース管理、監視、ネットワークの障害を想定する範囲です。
- データ・権利：利用目的、個人情報、匿名化、再委託、保管場所、モデル・ルールの権利、終了時の削除・返却の取り決め。
- 契約・体制：PoCと本番で契約形態を分けて検討し、発注側に業務・データの責任者を置く。
止まる箇所によって、必要な冗長化と試験範囲も変わります。PoCや探索は準委任、本番構築は納めるものと受入条件を確定して請負にするなど、フェーズごとに契約形態を分けられます。
発注側に業務オーナーとデータオーナーを置き、ベンダー任せにしない体制が大切です。
よくある質問（FAQ）
開発方針を決めるときの判断軸は、AIだけで作るか、パッケージとスクラッチのどちらにするか、期間の見方です。費用については前の章で扱っています。よくある疑問も、この判断軸と誤検知の抑え方に集まります。
不正送金検知システムはAIだけで作れますか？
AIだけで作る方法はおすすめしません。まずは、金額や頻度、既知の送金先など、説明しやすく即時に変更できるルールを土台にします。
一方、未知のパターンや複数データの組み合わせはAIで補います。そのうえで、判定理由、モデル版、再学習条件、誤検知時の人手による上書きも設計します。
開発期間はどのくらいかかりますか？
データ診断・PoCは1〜3か月、1チャネルのクラウド・API連携は2〜6か月、パッケージ・クラウドの本番導入は6〜12か月が目安です。
複数チャネルや勘定系とAML連携に加えて、24時間運用、移行、監査、段階リリースを含む場合は、12〜24か月になります。独自モデルや大規模共同基盤では、18〜36か月を想定します。
期間を縮めるには、対象チャネルとアクションを絞り、既存の認証・ケース管理を活用します。あわせて、PoCと並行してデータ整備を進めます。
パッケージとスクラッチはどちらがよいですか？
既知の不正に短期間で対策するなら、クラウドやパッケージをAPIでつなぐ方法が向いています。
独自業務や特殊な商品があったり、データ保管が厳しかったり、長期的に知見を蓄えたかったりする場合は、ハイブリッドかスクラッチを検討します。
スクラッチでは、学習データ、人材、MLOps、監査、保守、制度変更対応を継続して負担することになります。このため、製品の優劣より、5年TCOと運用体制で判断します。
誤検知を減らすには何を見ればよいですか？
False Positive率に加えて、アラート総数、顧客への追加確認率、調査時間、停止から解除までの時間を見ます。
高額送金を一律に止めず、端末の信頼性、取引履歴、送金先との関係、本人確認結果を組み合わせて判断します。また、保留、追加認証、自動許可を使い分けます。
担当者が判定理由を理解できる画面を用意することも大切です。さらに、ルールを安全に変えて効果を検証する運用も必要です。
まとめ
不正送金検知システムは、振込を止める機能と、その後の業務を一体で支える仕組みです。
不正送金検知システムは、顧客・端末・取引・送金先を分析し、アラートから顧客確認、停止・凍結、調査、情報連携までを支える業務基盤になります。
2025年の警察庁・金融庁の要請と、2026年の法改正を踏まえて、検知後の対応も要件に含めます。
開発で押さえるべき要点
開発は、シナリオとデータの整理から始めます。その後、PoCと並行運用を経て、自動化の範囲を広げます。
- 検討と検証：被害シナリオ、対象チャネル、データ、性能、監査要件の整理と、ルールとAIのPoCでの比較。
- 運用開始：検知性能と現場負荷を評価したうえで、既存システムとの並行運用から段階的に自動化する流れです。
PoCでは、再現率・適合率に加えて、誤検知、アラート数、調査工数、顧客影響、被害抑止額をKPIとして扱います。
企画段階の費用は、PoCが200万〜800万円、小規模導入が500万〜2,000万円、本番導入が2,000万〜8,000万円です。
複数チャネルは8,000万〜2億円、スクラッチや共同基盤は2億〜5億円超です。ただし、正式な見積もりでは初期費用だけでなく、データ整備、外部接続、監査、移行を比べます。さらに、再学習、監視、24時間運用、5年TCOも含めて見ます。
最初に作るべき検討資料
ベンダーに同じ前提を示すため、業務・データ・技術・費用に関する資料をそろえます。
- 業務・データ資料：被害シナリオ、対象チャネル図、データ項目と保管期間、検知後の業務フローを一つにまとめたもの。
- 要件・費用資料：KPI、受入条件、外部接続、非機能要件、障害時方針、PoC計画、概算費用、5年TCOを並べた資料。
資料がそろえば、同じ条件のRFPで提案を比べられます。AI搭載の有無や初期価格だけでなく、運用効果と、障害時にどこまでを誰が受け持つかも確かめられます。
現場がアラートを調べ、顧客に確認し、適切な時点で停止・解除します。そして、その結果をルールやモデルの改善に反映することが重要です。
対象を絞ったPoCと並行運用から始め、データと業務の成熟度に応じて本番の範囲を広げていけば、投資と顧客影響を見ながら対策を強められます。
▼全体ガイドの記事
・不正送金検知システム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。