不正送金検知システム開発の進め方/やり方/流れや方法/手法/工程/手順

不正送金検知システムは、顧客・端末・取引・送金先の情報を組み合わせ、送金前後のリスクを即時判定して、保留・追加認証・停止・調査までつなぐ業務基盤です。

銀行、信用金庫、資金移動業者、決済事業者などが開発を検討するとき、AIモデルだけを作ればよいわけではありません。被害シナリオの定義、データの棚卸し、検知後の顧客確認、出金停止や凍結、警察・他金融機関との情報連携、24時間365日の運用までを一つの流れとして設計する必要があります。本記事では、全体像、開発の進め方、費用相場、見積もりのポイント、よくある質問を順番に解説します。

▼全体ガイドの記事
・不正送金検知システム開発の完全ガイド

不正送金検知システムの全体像とは何ですか？

不正送金検知システムは、ログイン、口座開設、振込指示、送金先、端末、問い合わせなどの情報を横断して、取引ごとのリスクを評価する仕組みです。判定結果をスコアとして返すだけでなく、追加認証、保留、担当者による調査、出金停止、凍結、顧客への確認までを業務フローとして実行できることが重要です。

不正送金検知は、口座乗っ取り、フィッシング、マネーミュール、異常な高額送金、短時間の連続送金などを対象に、取引の直前または実行中にリスクを判定する領域です。一方、AML/CFTは、継続的な顧客リスク評価、取引モニタリング、疑わしい取引の確認・届出などを含む、より広いマネー・ローンダリングおよびテロ資金供与対策の業務です。多くの案件では両者のデータを連携させますが、リアルタイムの不正送金阻止と、事後を含む継続的なモニタリングでは、担当部署と判断基準が異なります。

多要素認証や取引認証も重要ですが、認証を通過した利用者がだまされて送金するケースや、正規端末を使った不正操作までは認証だけで防ぎにくいです。警察庁の公表では、令和6年のインターネットバンキングに係る不正送金事犯は4,369件、被害額は約86億8,900万円でした（出典: 警察庁「令和7年警察白書」、2025年）。認証、端末分析、取引分析、検知後の業務を重ねる多層防御が必要です。

検知機能の一つ目は、金額、頻度、時間帯、送金先、名義変更、ログイン失敗回数などを条件にするルール検知です。二つ目は、IPアドレス、端末情報、ブラウザ、位置情報、ログイン時刻、普段の操作傾向を通常時の行動と比較する属性・行動分析です。三つ目は、顧客、口座、電話番号、端末、IP、送金先の関係をグラフとして捉え、単一取引では見えない資金循環や受け子口座を探すネットワーク分析です。

業務機能では、アラートの優先順位付け、ケースの割り当て、調査メモ、顧客確認、追加認証、保留、出金停止、凍結、解除、解約、届出、警察連携までを管理します。判定理由、利用したデータ、ルールの版、モデルの版、担当者の操作履歴を保存する監査ログも欠かせません。検知エンジンとケース管理を別製品にする場合も、同じ取引IDで判定から措置までを追跡できる設計が必要です。

リアルタイム判定では、振込指示を受けてから顧客体験を損なわない時間内に、許可、追加認証、保留、拒否のいずれかを返す必要があります。判定の許容時間、ピーク時の取引量、タイムアウト時の扱い、検知エンジンが停止した場合に送金を止めるのか通すのかを、要件定義で明確にします。後から調査するログ処理では、数時間から数年の履歴を横断できるよう、保管期間と検索性能を設計します。

警察庁と金融庁は2025年9月、口座開設時の実態把握、多層的な検知、シナリオと閾値の精緻化、検知後の顧客確認・出金停止・凍結・解約、金融機関間の情報共有、警察との連携などを金融機関に要請しています（出典: 警察庁「預貯金口座の不正利用等防止に向けた対策の一層の強化について」、2025年）。そのため、検知エンジン単体ではなく、検知後に誰が何分以内に何をするかまでをシステムの対象に含めます。

不正送金検知システム開発の進め方・流れや手順

開発は、AIの方式を先に選ぶのではなく、被害シナリオと業務上のアクションを決め、データを確認し、PoCで検証してから本番化する順序が基本です。ここでは、企画から運用改善までを、被害シナリオ定義、データ棚卸し、PoC、並行運用、本番化、継続チューニングの6段階として整理します。

最初に、何を不正とみなし、どの時点でどのアクションを取るかを決めます。たとえば、フィッシングによる口座乗っ取り、普段と異なる端末からのログイン、登録直後の高額送金、短時間の複数口座への振込、名義変更直後の送金、休眠に近い口座からの急な出金、受け子口座への集中送金などをシナリオ化します。

シナリオごとに、対象チャネル、利用するデータ、判定のタイミング、リスクスコアの範囲、顧客への表示、追加認証、保留時間、担当者への通知、停止・凍結の権限者、解除条件を記述します。高リスクだから即時拒否、中リスクだから保留、低リスクだから許可という三段階から始め、顧客影響と調査能力に応じて細分化する方法が現実的です。

次に、顧客、口座、取引、ログイン、端末、IPアドレス、位置情報、送金先、問い合わせ、凍結履歴、過去の不正確定情報が、どのシステムにあり、どの粒度で、何年保存されているかを確認します。項目名やコード体系、タイムゾーン、匿名化の方法、利用目的、データオーナー、外部提供の可否まで整理し、学習データとリアルタイム判定データを分けて設計します。

不正のラベルが少ない場合は、ルールで検知して担当者が確定した結果や、凍結・組戻しなどの業務結果を暫定ラベルとして使うことがあります。ただし、暫定ラベルには見逃しや担当者ごとの判断差が含まれるため、学習に使う前に品質を確認します。機能要件と同時に、判定レイテンシ、ピーク時のTPS、可用性、障害時のフェイルセーフ、暗号化、権限分離、監査ログ、データ保持期間、モデル版管理を非機能要件として明文化します。

PoCでは、検知率だけを競わせないことが重要です。再現率、適合率、False Positive率、アラート件数、1件あたりの調査時間、判定速度、停止から解除までの時間、被害抑止額、正常顧客への影響をKPIに設定し、ルールのみ、機械学習のみ、両者の組み合わせを同じデータで比較します。AIの精度が高くても、アラートが多すぎて担当者が処理できなければ本番運用には向きません。

NICTは2025年、4行の銀行と連携したプライバシー保護連合学習の実証で、個別モデルとの比較において適合率が最大約10ポイント向上し、再現率が95％を超えたと公表しました（出典: NICT「DeepProtectを活用した銀行の不正口座検知の実証実験」、2025年）。一方で、銀行ごとのデータ項目や定義の違いが課題になったとも説明されています。PoCではモデル性能だけでなく、データ定義をそろえる工数と、個人情報を外部に出さずに学習できるかも評価します。

PoCの次は、既存のAMLシステムや不正検知サービスと並行してスコアを出し、担当者が判定理由とアラート量を確認するシャドーモードを設けます。一定期間の実績を確認した後、低リスク取引は自動許可し、高リスク取引は保留または追加認証にするなど、アクションを段階的に有効化します。いきなり自動停止すると、誤検知による顧客の送金不能や問い合わせ急増が起きる可能性があります。

本番化では、APIまたはメッセージングによる低遅延連携、二重化、暗号化、監視、ログ集中管理、モデルレジストリ、ルール変更の承認、ロールバック、障害時の迂回手段、夜間休日のエスカレーションを実装します。稼働後は月次または週次で、手口の変化、検知率、誤検知率、調査時間、凍結解除時間、被害額、顧客苦情を確認し、ルールとモデルを更新します。2026年7月10日施行の改正犯罪収益移転防止法では送金犯罪に関する罰則が創設されています（出典: 警察庁「令和8年犯罪収益移転防止法の改正について」、2026年）。そのため、制度変更の影響を法務・コンプライアンスと定期的に確認します。

不正送金検知システムの費用相場とコストの内訳

不正送金検知システムの公開定価は少なく、取引量、対象チャネル、データ量、既存システムとの接続、国内保管、監査、冗長化、運用体制によって見積もりが変わります。企画段階では、一般的なAI開発の公開相場を基準にしつつ、金融機関向けのセキュリティ・可用性・監査・業務連携を加えた段階別のレンジで考えると、稟議に使いやすい概算になります。

データ診断と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万円、中堅金融機関が口座開設、ログイン、振込、カード・決済、AML連携など複数チャネルへ対応する場合は8,000万〜2億円が目安です。大規模なスクラッチ開発や共同利用基盤で、勘定系・情報系・外部機関との連携、独自モデル、冗長化、全国規模の移行・監査まで含める場合は、2億〜5億円超になることもあります。

費用の内訳は、要件定義10〜15％、データ連携・ETL15〜25％、検知ロジックとモデル15〜25％、アプリ・ケース管理15〜25％、セキュリティ・監査・テスト15〜25％、移行・教育・プロジェクト管理という配分で整理すると比較しやすいです。連携先が増えるほど、接続仕様の調査、性能試験、障害時の再送、データ項目の変換、責任分界の調整に工数がかかります。

運用費は、SaaS利用料、クラウド推論料、ログ保管、監視、ルールチューニング、モデル再学習、データ品質管理、障害対応、夜間休日対応を含めて月額50万〜300万円程度を起点に考えます。高い取引量、複数リージョン、専用の監視体制、24時間365日の有人対応、厳格なログ保管を求める本番環境では、月額300万〜1,000万円超になる可能性もあります。

初期費用の安さだけで製品を選ぶと、再学習の追加料金、ルール変更の支援費、APIの従量課金、データ保管費、専用環境費、サポート費、解約時のデータ移行費が見落とされます。5年間の取引件数、クラウド・ライセンス、開発追加、監視、保守、制度対応、教育、切替、終了時の移管までを含むTCOを並べ、被害抑止額と調査工数の削減額を分けてROIを説明します。

不正送金検知システムの見積もりを取る際のポイント

見積もりの精度は、ベンダーの技術力だけでなく、発注側がどこまで条件をそろえられるかで決まります。「AIで不正を見つけたい」という依頼ではなく、対象チャネル、取引量、判定時間、データ項目、検知後のアクション、KPI、監査、運用体制をRFPに記載し、同じ前提で複数社を比較します。

RFPには、口座開設、ログイン、振込、送金先登録、カード・決済、ATM、資金移動などの対象チャネルと、既存の勘定系、インターネットバンキング、AML、本人確認、顧客通知、ケース管理との接続先を記載します。月間取引件数、ピーク時のTPS、同時接続数、許容レイテンシ、アラート保持件数、ログ保存年数、データセンターの地域、開発・本番環境の分離も数値で示します。

「外部連携一式」「セキュリティ対応一式」のような曖昧な表現は避け、接続方式、電文、認証、証明書、再送、タイムアウト、監視、試験環境、障害時の窓口を分けて書きます。自動停止を採用する場合は、停止の解除権限、顧客への通知、誤停止時の補償・復旧、手動運用への切替条件も要件に入れます。

不正検知では、再現率を上げるほど正常取引までアラートになる場合があります。そのため、再現率、適合率、False Positive率、1日あたりのアラート数、調査担当者1人あたりの処理件数、調査時間、顧客への追加確認率、送金停止後の解除時間、被害抑止額を一緒に評価します。検知モデルの評価指標と、現場の業務指標を別々に置くことが大切です。

受入条件は、「AIの精度が高いこと」ではなく、「指定した期間とデータで再現率が何％以上、適合率が何％以上、判定時間が何ミリ秒以内、アラートが何件以内、判定理由がケース画面に表示され、監査ログを追跡できること」のように記述します。学習データのラベル品質が低い場合は、数値の解釈限界と、本番後に再評価する時期も契約や計画に含めます。

短期導入と既存サービスの活用を優先するなら、クラウド型やパッケージのAPI連携が候補です。独自の業務フローやデータ主権が大きい場合は、検知エンジンを外部サービスにし、顧客・取引データとケース管理を自社側で持つハイブリッドが現実的です。独自の検知知見を競争力として蓄積でき、長期の運用人材と投資を確保できる場合に限り、スクラッチを選びます。

比較では、金融機関の本番実績、検知シナリオの更新頻度、リアルタイム性能、AIの説明可能性、API・イベント連携、データの国内保管、モデルとルールの所有権、障害時の責任分界、再委託、保守費、解約時のデータ返却を確認します。NTTデータのCAFIS Brainは、700種類以上の不正判定ルールや導入企業によるルール・スコア調整、リンク分析を特徴として公開しています（出典: NTTデータ「CAFIS Brain」、2026年確認）。このように、機能数だけでなく、自社で変更・説明・運用できる範囲を比較します。

障害時に送金を停止するのか、暫定的に通すのか、手動審査へ切り替えるのかを決め、復旧目標、代替手段、通知先、事後の突合方法を整理します。検知エンジンの障害だけでなく、本人認証、勘定系、通知、ケース管理、監視、ネットワークのどこが止まった場合を想定するかで、必要な冗長化と試験の範囲が変わります。

また、学習に使うデータの利用目的、個人情報の取扱い、匿名化、再委託、データの保管場所、学習済みモデルの権利、ルールの知的財産、契約終了時の削除・返却を明記します。準委任契約で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年の法改正を踏まえ、検知後の対応まで含めた要件にする必要があります。

開発では、被害シナリオと対象チャネルを定義し、利用可能なデータ、ラベル、接続先、処理性能、監査要件を棚卸しします。そのうえで、ルールとAIをPoCで比較し、再現率や適合率だけでなく、誤検知、アラート件数、調査工数、顧客影響、被害抑止額をKPIにします。既存システムとの並行運用から始め、アクションを段階的に自動化することが安全です。

費用は、PoCで200万〜800万円、クラウド・API連携の小規模導入で500万〜2,000万円、パッケージ・クラウドの本番導入で2,000万〜8,000万円、複数チャネルで8,000万〜2億円、スクラッチや共同基盤で2億〜5億円超が企画段階の推定です。正式な見積もりでは、初期費用だけでなく、データ整備、外部接続、監査、移行、モデル再学習、監視、24時間運用、5年TCOまで比較します。

最初の検討資料として、被害シナリオ一覧、対象チャネル図、データ項目・保管期間一覧、検知後の業務フロー、KPIと受入条件、外部接続一覧、非機能要件、障害時方針、PoC計画、概算費用、5年TCOをまとめます。これらがあれば、ベンダーへ同じ条件でRFPを提示でき、AI搭載の有無や初期価格だけに引きずられず、実際の運用効果と責任分界で比較できます。

不正送金対策では、検知エンジンの性能と同じくらい、現場がアラートを調査し、顧客へ確認し、適切なタイミングで停止・解除し、結果を次のルール・モデル改善へ戻せることが重要です。まずは対象を絞ったPoCと並行運用から始め、データと業務の成熟度に合わせて本番範囲を広げると、投資と顧客影響を管理しながら継続的に対策を強化できます。

▼全体ガイドの記事
・不正送金検知システム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。