不正送金検知システムの発注は、被害シナリオとデータを整理し、RFPで要件をそろえ、PoCと並行運用を経て本番化する流れが基本です。
要件の決め方、発注と契約の進め方、費用相場、見積もりの比べ方は、それぞれ次の節で扱います。全体像は不正送金検知システム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・不正送金検知システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
不正送金検知システムの概要
不正送金検知システムは、送金前・送金中・送金後の情報から取引リスクを判定する業務基盤です。判定の結果をもとに、追加認証、保留、顧客確認、停止などの対応につなげます。
判定では金額に加えて、ログイン状況や端末、IPアドレス、位置などを組み合わせます。送金先や利用履歴、口座や顧客同士の関係も、判断材料になります。
発注前に決める被害シナリオ
発注側は、どの被害をどの時点で抑止するかを先に決めておきます。機能の要否は、この被害の定義があってはじめて判断できます。
- 口座乗っ取り：フィッシングや、普段と異なる端末からのログインによる被害。
- 不自然な送金：短時間の連続送金や、名義変更直後の高額送金のパターン。
- 資金循環：複数口座を経由する資金の動き。
各シナリオを検知したあとの対応も、あわせて決めておきます。たとえば、自動停止か一時保留か、追加認証か顧客通知かを決めておくと、RFPの仕様が具体的になります。
不正送金検知とAML/CFTは重なる部分がありますが、同じ仕組みではありません。不正送金検知は、リアルタイムの口座乗っ取りや詐欺送金を止めることが中心です。一方でAML/CFTは、継続的な顧客リスク評価や疑わしい取引の調査・届出が中心になります。
重なる部分では、両者で共有する顧客・口座・取引データや、担当部署、判定後の責任の分け方を、発注時に明記しておきます。
検知精度と対応業務の範囲
被害を抑えられるかはアラート後の業務設計で決まるため、要件には、検知から事後対応までを記録する機能を含めます。
- 検知機能：ルールと属性・行動分析、AIスコアリング、ネットワーク分析の各方式。
- 調査機能：ケース管理と判定理由の確認、監査ログ、モデル管理を備えます。
- 対応記録：顧客連絡、保留解除、出金停止、口座凍結、警察や他金融機関への情報連携の経過。
金融機関向けでは、24時間365日の稼働や、ピーク時の処理量、判定レイテンシも確認します。障害時に送金を通すか止めるかも、あらかじめ決めておきます。
2025年9月、警察庁は預貯金口座の不正利用防止策と警察との連携強化を金融機関に要請しました。この要請を踏まえ、多層検知から顧客確認、停止、凍結までをRFPに含めます（出典：警察庁「預貯金口座の不正利用防止に向けた対策の一層の強化」、2025年）。
不正送金検知システムの発注・外注の進め方
発注は、被害シナリオの定義とデータ棚卸しから始め、RFP作成、複数社比較、PoCを経て本番化し、継続チューニングへ進めます。各段階で得た検証結果は、次の要件に反映します。
企画とRFPで決める対象範囲
企画書とデータ棚卸しで対象範囲とデータの利用条件をそろえておくと、候補会社が同じ前提で提案できます。
- 企画書：チャネルと不正手口、取引件数、ピーク時TPS、判定許容時間の記載。
- 業務要件：利用可能なデータや必要なアクション、KPI、監査証跡、障害時方針の定義。
- データ棚卸し：顧客、口座、取引、ログイン、端末、IP、送金先などの項目を確認する作業。
問い合わせや不正確定情報も対象に含めます。そのうえで、各データについて所在と粒度、保存期間、匿名化の可否を確認しておきます。
不正ラベルが少ないままでは、機械学習の精度を初めから保証できません。そのため、RFPではAIを使うこと自体を目的にせず、解決したい課題を先に書きます。
RFPには、ルールのベースラインと暫定ラベルの作り方、データ整形、PoCで検証する仮説を記します。候補会社が同じ条件で比べられるよう、同一のサンプルデータと評価指標も渡します。
委託先の比較と検知後の運用体制
委託先は、技術力に加えて本番運用や検知後の体制を評価します。検知エンジンに強い会社と、業務システムや移行に強いSIerとでは、得意とする領域が異なります。そのため、会社名の知名度で一律に順位をつけず、同じ観点で評価します。
- 金融機関の経験：本番実績と、勘定系・インターネットバンキングとの連携。
- 検知と運用：処理性能、シナリオ更新、AIの説明可能性、ケース管理の扱い。
- 保守体制：移行の経験と、24時間の障害対応の有無。
提案会では、検知後の対応時間と顧客説明を質問します。あわせて、ルールの変更担当者と承認者、モデル更新時の再テスト担当も確認します。
NTTデータのCAFIS Brainは、端末・取引情報を分析して不正ログインや不正送金に対応するサービスとして公開されています。また、IIJは2025年、既存ログから通常と異なる地域のアクセスや不自然な送金指示を検知するRaptor振る舞い検知ソリューションを提供開始しました。
発注側は、候補サービスを自社要件と照合し、導入事例の範囲を確かめます。なお、NTTデータ「CAFIS Brain」は2025年確認の情報で、IIJ「Raptor振る舞い検知ソリューション」は2025年提供開始の情報です。
PoCから並行運用を経た本番化
PoCでは、精度に加えて業務で対応できるかを評価します。成果物には、データ品質診断、ルールとモデルの比較、シナリオ別の適合率・再現率を含めます。
- 検知結果：False Positive率、アラート件数、判定速度を見ます。
- 調査負荷：1件あたりの調査時間と、現場が判定理由を説明できるかどうか。
- 顧客対応：停止から解除までの時間。
本番前は、AMLシステムや既存の不正監視と並行してシャドー運用し、自動停止へは一度に切り替えないようにします。
取引の記録、担当者による確認、一部条件での自動保留へと段階的に進め、誤検知と顧客への影響を調べます。夜間に確認担当者がいなければ、精度が高くても運用上のリスクが残ります。
発注形態と契約形態の選び方
発注形態には、パッケージ・クラウドや既存システムとのAPI連携、ハイブリッド、フルスクラッチがあり、これらを比べて選びます。
判断の基準には、導入速度に加えて、データ配置、ルール変更の自由度、既存システムとの接続も入ります。さらに、モデルの所有権や将来の運用体制まで含めて選びます。
クラウド・パッケージ・スクラッチの使い分け
既知の不正シナリオや金融犯罪対策の知見を使って短期間で導入したい場合は、パッケージやクラウドのAPI連携が候補になります。
データ配置に厳しい制約がある場合や、独自の顧客確認・停止フローがある場合は、ハイブリッドも候補になります。
- パッケージ・クラウド：短期導入や既知の不正シナリオへの対応が中心となる場合。
- ハイブリッド：検知エンジンは外部に任せ、顧客データとケース管理は自社に置く形。
- スクラッチ：独自の検知知見や特殊な業務・データ要件がある場合の選択肢。
スクラッチでは、学習データと再学習、説明可能性について自社が責任を負います。加えて、監査や脆弱性対応、24時間保守も自社の担当になります。
AIは、既存ルールで不足する課題が明確な範囲から、段階的に採用します。
請負と準委任の工程ごとの使い分け
契約形態は、成果物と要件が固まっているかを基準に、工程ごとに選びます。なお、精度や未知の手口への対応は、単一の数値で保証するのが困難です。
- 請負：成果物や受入条件、検査、瑕疵対応、納期が定まった本番開発やAPI連携で使います。
- 準委任：データ診断、PoC、ルール設計、モデル評価、継続的な運用改善の工程。
組み合わせとして、PoCは準委任、本番機能は請負、運用改善は月額準委任とする方法もあります。
契約書では、成果物の範囲と評価方法を定めます。加えて、データや学習済みモデルの権利と再利用範囲を明記し、特徴量やルール、ソースコードも対象に含めます。さらに、秘密保持や事故時の責任、解約時のデータ返却も契約に含めます。
不正送金検知システムの費用相場と内訳
公開されている価格は多くありません。見積もりは、取引量やチャネル数、既存システムによって変わり、データ保管や監査、高可用性、運用時間も影響します。
ここに挙げる金額は、定価ではなく企画段階の目安です。公開されているAI外注相場と、金融系の連携・監査・冗長化を踏まえています。
PoCから本番までの初期費用の段階
初期費用は、PoCから本番へ進む段階と連携規模によって変わります。段階ごとの金額を並べて比べると、企画時の予算を組みやすくなります。
- データ診断・PoC：200万〜800万円程度。
- 1チャネルの小規模連携：クラウドや検知サービスのAPI連携で500万〜2,000万円程度。
- 本番導入：パッケージまたはクラウドで複数シナリオやケース管理を含み、2,000万〜8,000万円程度。
- 中堅金融機関向け：複数業務・AML連携まで含み、8,000万〜2億円程度。
- 大規模スクラッチ：広範な連携や移行を含み、2億〜5億円を超える場合もあります。
本番導入には、権限や監査ログ、性能・障害試験が含まれます。中堅金融機関向けでは、口座開設やログイン、振込などに加えて、カードや決済、AML連携を想定します。
大規模スクラッチでは、勘定系・情報系・外部機関との連携や独自モデルが費用に影響します。冗長化や全国規模の移行、監査も、金額を左右する要素です。
AI開発の公開相場は、PoCが100万〜500万円、本番構築が1,000万円以上、運用が月50万〜300万円とされています（出典：LASSIC「AI開発委託外注の進め方と注意点」、2026年確認）。
金融機関向けでは、データ連携やセキュリティ、テストの費用に加えて、監査や24時間運用の費用もかかります。公開相場は参考にとどめ、個別条件を見積もりに反映します。
運用費と5年間のTCO
運用費は、月額料金だけでなく、監視や更新、障害対応の範囲によって変わります。そのため、見積書の「保守費」は作業内容ごとに分けて確認します。
- 月額費用：SaaSや推論・保存、監視に加えて、チューニングや再学習を含む費用。
- 運用目安：月50万〜300万円程度を起点として考えます。
- 本番環境：金融機関向けでは、取引量や監視体制によって月300万〜1,000万円を超えることもあります。
- 確認事項：作業人月、ルール変更回数、障害対応時間ごとの内訳。
運用費の見積もりには、データ品質管理や夜間対応、障害訓練も含めます。
5年間のTCOでは、開発費に加えて、連携先の追加やログ容量の増加、再学習を含めます。さらに、脆弱性対応やライセンス改定、データ返却や解約時の移行費も確認します。
費用構成の目安は、要件定義が10〜15％、データ連携・ETLが15〜25％、検知ロジック・モデルが15〜25％です。アプリ・ケース管理と、セキュリティ・監査・テストは、それぞれ15〜25％です。
移行や教育、PMも想定し、割合が極端に低い項目は、別費用がかかるかを確認します。
RFPと見積書の比べ方
見積りの安さだけで選ばず、同じ条件のRFPをもとに、初期費用と運用費、追加費用、責任の分け方を比べます。
費用と性能は切り離さず、被害の抑止額と業務負荷の両面から投資効果を判断します。たとえば、検知率が高くても、誤検知が多ければ顧客対応や調査工数が増えます。
RFPに記載するデータ・性能・業務フロー
RFPには、データ、処理性能、アクションの状態遷移と担当部署を記載します。障害時の動作も含めると、候補各社が同じ条件で提案できます。
- システム条件：チャネル、取引件数、処理量、判定時間、接続方式の指定。
- データ・統制：データ項目や保存期間、暗号化、権限、監査ログ、バックアップの取り決め。
- 検知後の動作：許可、追加認証、保留、拒否、確認、通知、口座停止の定義。
障害時のフェイルセーフや、各アクションの状態遷移、担当部署も決めておきます。
評価指標には、検知率、適合率、再現率に加えて、False Positive率やアラート件数も含めます。運用面では、調査時間、判定レイテンシ、停止解除時間を見ます。また、月間のルール更新数も確認します。
NICTの2025年の4銀行連合学習実証では、個別学習より適合率が最大約10ポイント向上した例や、再現率95％超の例が確認されました。ただし、銀行間ではデータ項目や定義が異なる課題も示されました。
そのため、自社データの標準化をRFPに含めます（出典：情報通信研究機構「DeepProtectを活用した銀行の不正口座検知の実証実験」、2025年）。
委託先の実績・技術・運用体制の配点
評価項目を分けて配点を先に決めておくと、営業資料の印象に左右されにくくなります。
- 金融実績：25点を配点する例。
- 技術・連携：20点を配点する例。
- セキュリティ・監査：20点の配点例。
- 運用体制：20点の配点例。
- 費用・契約：15点の配点例。
評価項目には、要件定義、既存連携、リアルタイム性能、データ保護が含まれます。検知ロジックや説明可能性、ケース管理も対象です。移行、教育、保守、障害対応までを評価の範囲に入れます。
2026年7月のSASとりそなHDの発表では、4行でAIスコアリング、ネットワーク特徴量、調査用Agentic AIを段階的に検証しています。また、調査結果を人が確認する設計も示されています。
提案会社には、検知から調査、報告を経て、ルールやモデルの見直しまでを一連の運用として示してもらいます（出典：SAS「りそなHDとのAML/CFT業務高度化に向けた取り組み」、2026年）。
契約前に防ぐ失敗リスク
PoCの成功条件がないと、本番移行を判断できません。精度だけを見ていると、調査工数も見落としやすくなります。
データ整備は発注側の作業として明確にしておく必要があります。また、障害時に送金を通すか止めるかも決めておきます。
- 評価条件：評価データと合格ラインを、PoCの前に定めること。
- 移行条件：成果物と次工程へ移るための条件の合意。
- 追加費用：費用が発生する条件の事前の取り決め。
データ、モデル、ルールの所有権が曖昧だと、ベンダーを変えたり内製化したりする際に、過去の知見を持ち出せないおそれがあります。
契約では、利用目的や再委託、国外移転、学習への二次利用を定めます。さらに、ログ保存年数やモデル説明資料も含めます。脆弱性対応やSLA、事故報告についても、取り決めを明記します。
終了時のデータ返却形式も決めておきます。価格差が小さいときは、移行のしやすさや運用負荷も判断材料になります。
よくある質問（FAQ）
発注では、検知範囲とデータの扱い、契約後の運用責任を確認しておく必要があります。稟議や委託先の選定に入る前に、代表的な疑問を取り上げます。
不正送金検知システムの開発費用はいくらですか？
企画段階の費用目安は、導入範囲によって変わります。
- データ診断・PoC：200万〜800万円程度。
- API連携の小規模導入：500万〜2,000万円程度。
- 本番導入：2,000万〜8,000万円程度。
- 中堅・大規模スクラッチ：中堅向けは複数業務とAML連携を含み8,000万〜2億円程度、大規模スクラッチは連携や移行を含み2億〜5億円を超える場合もあります。
見積もりでは、取引量やデータ、可用性の条件をそろえます。監査や運用範囲も同じ前提にしておくと、金額を比べやすくなります。
パッケージとスクラッチ開発はどちらが良いですか？
短期導入や既知の不正への対応が目的なら、パッケージやクラウドのAPI連携が候補になります。独自の要件を強みにしたい場合は、スクラッチも検討します。
データとケース管理を自社に残しつつ、検知エンジンを利用する場合はハイブリッドが候補です。どの方式が合うかは、PoCで費用、精度、運用負荷を比べて決めます。
請負契約と準委任契約はどう使い分けますか？
要件や成果物、受入条件が固まった本番開発やAPI連携は、請負が基本です。一方、データ診断やPoC、ルール設計、モデル評価、継続チューニングは準委任が適しています。
PoCを準委任、本番機能を請負、運用改善を月額準委任とする方法もあります。契約前には作業範囲と責任の分け方を定めます。あわせて、データとモデルの権利や返却条件も決めておきます。
まとめ
発注では、検知エンジンを比べる前に、被害シナリオや対象チャネル、データを整理します。判定後の業務やKPI、監査証跡、障害時方針も、あわせて固めておきます。そのうえでRFPを作成し、方式と契約を工程ごとに選びます。
PoCと並行運用による本番の失敗防止
費用はPoCと本番構築、運用、5年間のTCOに分けて捉えます。検知率や再現率に加えて、誤検知や調査工数、顧客影響も評価します。判定速度や被害抑止額も、評価の対象です。
PoCからシャドー運用、限定的な保留、自動停止へと段階的に進めると、現場が対応できる仕組みとして定着しやすくなります。
契約と運用の責任分界の明確化
委託先については、本番実績に加えて、データ保護や説明可能性を確認します。さらに、モデルやルールの更新、ケース管理、障害対応、終了時のデータ返却の扱いも見ておきます。
2026年7月に送金犯罪の罰則が創設されるなど、制度環境も変わっています。そのため、手口や法令、業務KPIに合わせて見直せる体制を整えておきます（出典：警察庁「令和8年犯罪収益移転防止法の改正について」、2026年）。
▼全体ガイドの記事
・不正送金検知システム開発の完全ガイド
▼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を創業。