AMLシステムは、自社のリスクとデータを整理し、RFPやPoC、見積比較を経て発注すると、稼働後に有効性を検証しやすくなります。
発注形態の選び方、RFPと要件整理、契約と費用、委託先の選び方を、この順に説明します。全体像は、下の完全ガイドで確認できます。
▼全体ガイドの記事
・AMLシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
AMLシステムを発注・外注する前の全体像
AMLシステムは本人確認だけでなく、KYC、顧客リスク評価、制裁・PEP・反社会的勢力の確認まで担います。
取引モニタリング、アラート調査、疑わしい取引の届出支援、監査ログまでをつなぐリスク管理基盤です。そのため、画面やAIの機能よりも、自社の業務とデータの連携や、判断根拠を説明できるかどうかが発注の成否を左右します。
製品選びより先の、リスク管理の仕組みとしての発注
発注前に決めるのは、どの製品を入れるかより先に、どのリスクをどの業務で低減し、どんな証跡を残すかです。
- 不正利用対策：法人口座など、事業特有のリスクの範囲
- 取引監視：海外送金や暗号資産など、対象取引に応じた設計
- 運用規模：顧客数、月間取引件数、対象国、商品・チャネルの把握
- 検知と調査：高リスク顧客の割合とアラートの優先順位
条件を整理しないまま製品を比べると、不要な機能に費用を払い、必要な連携を後から追加することになりがちです。
金融庁は2025年、取引モニタリングのシナリオや敷居値を定期的に検証し、調整する取り組みを示しています（出典：金融庁「マネー・ローンダリング等及び金融犯罪対策の取組と課題」、2025年）。そのため、一律の確認表では足りません。導入後もリスクへの有効性を測り、改善できる仕組みが必要です。
外注後も残る発注側の管理責任
開発や運用を外部に委託しても、AML/CFTの管理責任は発注側に残ります。標準ルールを使う場合でも、自社の顧客層や取引に合っているかを確かめる必要があります。
- アラート量：現場が処理できる件数に収まるか
- 判断理由：疑わしい取引と判断した根拠を説明できるか
- 役割と承認：検証データの提供者と、ルール変更の承認者
- 継続管理：障害連絡、監査協力、解約時のデータ返却を契約に記載しておく
金融庁の2026年FAQも、外部委託や共同システムを利用する際は、自社の規模やビジネスモデルに合うかを検討する考え方を示しています（出典：金融庁「マネロン・テロ資金供与対策ガイドラインに関するFAQ」、2026年）。顧客層や取引状況に合うかも、確かめる対象です。また、外部サービスを利用する場合も、自社のリスクに応じた対応が必要です。
AMLシステムの発注形態の選び方
発注形態は大きく4つに分けられます。SaaS・API、パッケージ・クラウド、既存システムを活かすハイブリッド、独自開発の4つです。
選ぶ際は、導入速度や独自ルールの量、データ品質が判断材料になります。さらに、将来の対象国や取引量、運用人材の有無も、考慮に入れます。
SaaS・パッケージ・ハイブリッドを選ぶ基準
SaaSやAPIは、制裁リスト検索、簡易KYC、少量の取引モニタリングを早く始めたい場合に向いています。初期投資を抑えやすく、機能や規制情報の更新はサービス側に任せられます。
- 従量課金：利用量が増えた場合の料金体系
- データ管理：保管場所と、学習データへの利用の有無
- 継続性：障害時の代替手段と、解約時のエクスポート
- 周辺業務：顧客・取引データ連携とケース管理の範囲
小規模な利用でもケース管理が必要なら、単純なAPI接続だけでは運用が完結しない場合があります。
パッケージや金融機関向けクラウドは、KYCや顧客リスク評価、取引監視といった標準機能に、自社向けの設定を加えて使います。調査ワークフローも、この標準機能に含まれます。
規制対応や導入実績を確認しやすい一方で、標準機能に業務を合わせる範囲とカスタマイズの範囲を決めておかないと、費用が膨らみます。
既存のAMLを残してケース管理やAIスコアリングを加えるハイブリッドは、業務を止めずに改善を進めやすい方式です。
スクラッチ開発が向くケースと注意点
既製品では重要な差分を吸収できない場合に、スクラッチ開発を検討します。たとえば、独自の顧客リスクモデル、大量取引の特殊処理、複数国にまたがる複雑な連携が該当します。
画面やルールを自由に設計できる一方で、規制やリストの更新、検知ロジックの検証は、継続して担う必要があります。さらに、モデルの再現性の確保、担当交代への備え、脆弱性対応も自社で継続して担う対象に含まれます。そのため、開発費と5年分の保守・改善費を同じ条件で見積もります。
発注形態は、最初の稼働時期、業務差分、導入後の体制の順に確認して決めます。
- 最初の稼働を何か月以内に実現する必要があるか。
- 標準シナリオを採用できない業務差分がどれほどあるか。
- 導入後のルール調整と、経営・監査への報告体制があるか。
短期の導入しやすさだけで決めず、業務と責任の持ち方も含めて選びます。
RFP・要件整理からAMLシステム発注までの進め方
開発会社へ相談する前に、自社の前提を整理してRFIやRFPを出すと、候補を比べやすくなります。ただし、仕様をすべて決め切る必要はありません。
候補企業には、対象業務やデータ量、期待成果を同じ条件で伝えます。そのうえで、制約や委託後の責任範囲も示しておきます。
RFP前の業務・データ・成果指標の整理
まず、対象範囲を業務フローに書き出します。また、各工程で誰が何を判断するかまで分けて考えます。
- 顧客確認：口座開設時の本人確認、法人の実質的支配者の確認。
- リスク確認：顧客リスク格付、制裁・PEPのスクリーニング。
- 取引調査：取引監視、アラート調査、承認・エスカレーション。
- 届出：疑わしい取引の届出支援と、記録の保存。
工程ごとに、現行システム、担当部署、入力情報を並べます。出力帳票、保存期間、課題も書き加えると、相談すべき要件が見えてきます。
次に、どのシステムにデータがあるかを洗い出します。顧客ID、口座ID、取引IDを持つシステムが、その対象です。
データの中身については、氏名や住所の表記ゆれ、法人番号、国・地域のそろい具合を調べます。通貨、取引目的、送金先情報も、あわせて確かめます。
連携本数、日次かリアルタイムか、ピーク件数は、サンプルで測定します。加えて、保持期間、欠損率、名寄せ率も測っておきます。精度を上げたい場合ほど、AIモデルより先にデータ辞書とデータリネージを整えることが近道です。
成果指標は検知率だけで終わらせず、過去の疑わしい取引の再現度や、誤検知によるアラート件数も測ります。また、調査時間、担当者間の判断差、処理遅延も指標に加えます。検知理由を説明できる割合やルール変更後の品質も、測る対象です。
発注前に測定方法を合意しておけば、PoCや受入テストで、主観だけに頼らず判断できます。
RFPに書く機能・非機能・運用条件
RFPには、機能に加えて、設定と記録、非機能、AI運用の条件を分けて書いておくと、候補企業が同じ前提で見積もれます。
- 機能：KYC/CDD、顧客リスク評価、制裁・PEP・反社・ネガティブニュース検索、取引監視。
- 設定と記録：シナリオ追加・停止・変更、閾値根拠、アラート集約、判断再現。
- 非機能：可用性、性能、復旧、暗号化、認証、権限、監視、監査。
- AI運用：学習範囲、更新、再現性、説明、修正保存、人による上書き。
機能要件では、アラートの重複排除やケース管理、調査メモも対象に含めて確かめます。承認や届出支援、レポートも同じ要件の中で扱います。過去の入力データと判断結果を再現できるかも、開発会社に質問します。
非機能要件には、職務分掌や操作ログの改ざん防止、脆弱性対応、障害通知も入れます。
データの所在地、委託先監査、持ち出し方法をRFPに記載します。停止時の手作業や後追い処理も、あわせて書いておきます。
金融庁は2025年、金融機関ごとにリスクプロファイルが異なるという考え方を示しています（出典：金融庁「金融分野におけるITレジリエンスに関する分析レポートの概要」、2025年）。そのため、一律の確認表では足りません。
AIでは、バージョン管理とスコアの根拠を確かめます。モデル検証や、機密データの目的外利用も対象です。
生成AIで調査メモを要約する場合は、最終判断と承認を担当者が行います。AIの出力をそのまま届出理由にしない運用も決めておきます。
PoC・並行稼働・受入テストによる発注判断の検証
候補を2〜4社に絞ったあと、PoC、並行稼働、受入テストの順に、発注判断を検証します。
- 匿名化PoC：過去取引での再現度や誤検知、調査時間、ピーク時遅延を測定
- サンプル設計：通常取引、高リスク国、複雑な名寄せ、複数口座、疑わしい事例を含むサンプル
- 並行稼働：新旧の検知、アラート数、調査時間、判断差、データ欠損の比較
- 受入条件：取引取込、シナリオ、権限、変更履歴、障害復旧の確認
PoCでは、実データを加工して使います。サンプルが少ないと結果が偏るため、対象となる取引の幅を確保しておきます。
本番移行では、既存システムをすぐに止めず、一定期間並行稼働させます。受入時には、画面表示の確認に加えて、担当者以外が閲覧できないことも確かめます。
NTTデータは2025年、ACSiONと連携し、法人口座開設から取引モニタリングまでを扱うAML/CFTサービスを始めました。このサービスは、既存のネットバンキングや口座開設サービスとの接続事例でもあります（出典：NTTデータ「マネロン・不正利用を防ぐ、法人口座向けの対策サービスを提供開始」、2025年）。
自社でも、置き換えるシステムと残すシステム、データの正本を管理する担当者を、RFPで明確にしておきます。
AMLシステムの契約形態と外注時に確認する責任分界
契約は、準委任と請負、SaaS利用、保守・運用を組み合わせるのが一般的です。業務の性質によって、工程ごとに契約の形が変わります。
工程ごとの準委任・請負・SaaSの使い分け
要件が固まらない段階で完成品の納品を約束するのは難しいため、工程の性質に合わせて契約を使い分けます。
- 準委任：要件定義、データの洗い出し、RFP、PoC支援、運用改善。
- 請負：仕様と成果物が確定したシステム開発。
- SaaS：システムの継続利用。
- 保守契約：リリース後の改善や運用支援。
契約名よりも、納品物と検収方法を先に確かめます。変更管理や遅延時の扱いも、契約書に書かれているかを見ます。
SaaSでは、利用料に含まれる機能とデータ処理量を確かめます。サポート時間や障害時のSLA、保守時間も、あわせて確認します。
規制やリストの更新の責任、サブプロセッサー、データ所在地も対象です。顧客数や取引数、追加環境によって、従量課金が増える場合があります。過去データの保管やAPI利用も、従量課金を押し上げる場合があります。
契約期間と自動更新の条件は、稟議の段階で把握しておきます。
外注契約に入れるべきデータ・監査・出口条件
個人情報や取引情報を扱うため、秘密保持と安全管理に加えて、再委託を行う際の承認や管理方法を決めておきます。
- 安全管理：アクセス権限、ログ保存期間、脆弱性診断。
- 事故対応：第一報の期限、原因分析、再発防止。
- 監査協力：監査資料の提出と当局・内部監査への協力。
- クラウド：保管・バックアップ地域、暗号鍵管理者、復旧目標。
出口条件では、データの返却を定めておきます。返却の対象は、顧客情報、取引履歴、アラートです。
さらに、ケース、調査メモ、ルールも返却の対象に含めます。閾値、モデル版、監査ログも、返す必要があります。
形式、期限、費用は契約で定めます。返却後の削除証明や移行支援、並行稼働期間も決めておきます。
API仕様書やデータ辞書の引き渡しも、契約に盛り込みます。こうした取り決めがないと、移行できない契約になり、将来の変更費用が見えにくくなります。
ルールやモデルの変更権限も、責任分界の中心になります。標準ルールを更新する場合でも、本番反映の承認者と、事前検証の要否を決めておきます。
金融庁の2026年資料は、外部委託先の管理をAML/CFT態勢の論点として挙げています（出典：金融庁「マネー・ローンダリング等及び金融犯罪対策の取組と課題」、2026年）。また、委託先が「対応済み」と示した内容と、自社リスクへの有効性検証は、別に確認します。
AMLシステムの費用相場と見積もりの内訳
国内価格は、顧客数や取引件数、対象国によって変わります。リストや連携本数、リアルタイム性も、価格を左右します。既存基盤の状態も、価格に関わります。
専用製品の一律の価格表は限られるため、ここで示すのは、公開価格や金融系業務システムの相場、個別要件をもとにした発注時の目安です。そのため、同じ前提で複数社の提案を比べます。
発注形態別の費用と期間の目安
発注形態別の初期費用、ランニング費用、期間は次のとおりです。金額は記事内の推定を含む目安です。
- SaaS・API：初期0〜500万円、月額10万〜100万円または従量課金、1〜3か月。
- クラウド・パッケージ：初期500万〜3,000万円、年額500万〜3,000万円程度、期間3〜9か月。
- 追加開発・ハイブリッド：初期3,000万〜1億円、年額1,000万〜5,000万円程度、期間6〜12か月。
- スクラッチ・オンプレミス：初期5,000万円〜数億円、年額1,000万〜数億円、期間12〜24か月以上。
SaaS・APIは、制裁リスト検索や簡易KYC、限定的な取引監視に向いています。一方、クラウド・パッケージは、料金が機能と連携範囲によって変動します。
ハイブリッドは、既存のAMLを残したうえで、データ基盤、AIスコアリング、ケース管理を加える場合などが該当します。
ここに挙げた金額は、国内AML専用の公開価格が少ないことを踏まえた推定です（出典：NotebookLMリサーチノート「AMLシステム」、2026年）。
公開価格の例として、Alibaba CloudのSMART AMLには、機能ごとの一時設定費36,000米ドルと、取引監視1件あたり0.19米ドルがあります。ただし、これは海外サービスの参考値で、日本の金融機関向けの相場ではありません。
初期設定費と、顧客・取引量に応じた従量課金が併存する形です（出典：Alibaba Cloud「Financial Intelligence Engine Pricing」、2026年）。
為替や契約地域、サポート範囲、税金は、別途確認が必要です。
初期費用だけでなく5年TCOでの比較
5年TCOでは、初期費用の内訳と継続費用、データ整備を、同じ期間と業務範囲をそろえて比べます。
- 初期費用：ライセンス、要件定義、設計、連携、移行、テスト、研修など。
- 初期費用の比率：ライセンス40〜60%、要件等20〜30%、テスト等10〜20%、運用支援等10〜20%。
- 継続費用：クラウド、保守、更新、チューニング、検証、監査、教育など。
- 整備費：データクレンジングの範囲、方法、追加単価、発注側作業。
初期費用には、クラウド利用、データ整備、運用設計も含めます。大規模案件ではデータ統合とテストの比率が上がります。そのため、費用の割合を固定の基準にはしません。
ランニング費用には、リスト更新やストレージ、監視を含めます。ルールの追加や閾値の調整、モデルの再学習も必要になります。さらに、問い合わせ対応も含めて考えます。
たとえば、初期3,000万円、年額1,500万円なら、5年TCOは1億500万円になります。初期1億円のスクラッチで年額2,000万円の保守が必要な場合は、5年で2億円です。
氏名や法人名、住所の不統一は、検知精度や名寄せに影響します。国名や通貨の不統一も、精度や名寄せを左右します。日付や顧客IDのずれも、精度に響きます。
そのため、サンプル調査の結果と対象項目を見積書に記載し、追加作業を防ぎます。修正方法、追加費用の単価、発注側が用意する作業も明らかにしておきます。
委託先の選定とAMLシステムの見積比較ポイント
委託先は、知名度だけでなく、金融業務の理解やデータ連携力で選びます。現場定着の支援や検証・改善体制も、判断材料に入ります。
同じRFPへの回答を受けたら、価格と提案の具体性を分けて評価します。リスク指摘や担当者経験、運用支援も、評価の軸にします。また、標準機能の説明だけで自社課題への回答がない場合は、追加費用が増える可能性があります。
委託先の実績と運用体制の確認
委託先は、実績と専門性を軸に確認します。説明可能性と、導入後の体制も見ておきます。
- 類似実績：自社と同じ業態・規模・取引量の案件の有無
- 担当者：要件定義の責任者と、国内届出実務の知見
- 改善実績：同業案件で改善したKPIの実績
- 運用体制：責任者、AML、データ、セキュリティ、支援担当の役割分担
銀行の口座開設と、暗号資産交換業者の取引監視では、必要な知識や構成が異なります。
AML/CFT製品・サービスを持つ企業には、NTTデータやNEC、Oracleがあります。NICE、SAS、野村総合研究所も含まれます。企業名だけで選ばず、各社のAIの精度、説明可能性、共同利用や自社運用への組み込み方を比べて評価します。
NECは、不正スコアだけでなく判断根拠を示すサービスを公表しています。また、マネー・ローンダリング対策共同機構のAIスコアリングに関するシステムも構築しています。これらは、NEC「マネー・ローンダリング対策（AML）サービス」（2026年確認）に記載されています。
提案時と運用開始時で担当が変わる場合は、引き継ぎ資料と教育内容を決めておきます。月次レビューや四半期ごとのシナリオ見直し、年次のモデル検証は、頻度と費用も含めて見積に入れます。
見積書の金額・前提・除外項目の同時比較
見積比較では、前提条件と作業範囲を同じ基準でそろえます。加えて、追加費用と評価軸も確認します。
- 前提：顧客数、月間・年間取引件数、ピーク処理量、保持期間、連携方式、機能、環境、ユーザー数、サポート時間、SLA。
- 見積明細：工数、単価、期間、成果物、検収、除外、変更単価。
- 保守範囲：更新、調整、障害、監査資料、返却、移行支援。
- 評価配点例：要件適合30点、金融・AML知見20点、データ連携・セキュリティ20点、PoC・受入テスト15点、運用支援・出口条件10点、提案の透明性5点。
税と為替も、そろえておきます。片方の見積だけ移行や研修を含まない場合、選定後に差額が発生します。
「標準機能内」と「個別開発」、「設定変更」と「別途見積」の境界を、見積の段階で確かめます。成果物と発注側の作業、変更時の条件も、見積書に記載してもらいます。
配点は、自社の優先順位に合わせて変えます。RFP前に評価軸を決めておくと、提案の印象や担当者との相性だけで選ぶことを避けられます。
よくある質問（FAQ）
発注では、費用や機能に加えて、外注後の責任や導入期間にも疑問が出てきます。よくある質問に、実務で判断しやすい形で答えます。
AMLシステムの発注費用はいくらかかりますか？
小規模なSaaS・APIの場合、初期費用は0〜500万円、月額は10万〜100万円程度です。金融機関向けのクラウド・パッケージでは、初期費用500万〜3,000万円が目安になります。
追加開発やハイブリッドは3,000万〜1億円、大規模スクラッチは5,000万円〜数億円です。顧客数や取引量によって変わります。
連携や移行、保守の内容でも、金額は変わります。そのため、5年TCOで比べます。
AML業務を外注すれば自社の責任はなくなりますか？
外注しても、自社の責任は残ります。委託できる業務があっても、自社の顧客・取引リスクに合うかを判断し、有効性を検証して改善する責任は発注側にあります。
契約では、作業範囲や承認者、ルール変更を明確にします。監査協力や障害報告、データ返却も契約に盛り込みます。そのうえで、社内に業務責任者を置きます。
RFPにはどこまで細かく書けばよいですか？
画面仕様をすべて確定させる必要はありません。対象業務と顧客・取引データ、件数を記載します。連携方式や検知シナリオ、監査証跡も書いておきます。
セキュリティやSLA、PoC指標も必要です。受入条件や契約終了時のデータ返却も書きます。未確定の項目は質問事項とし、候補各社が同じ前提で見積もれる粒度にします。
RFP作成を専門会社に支援してもらう場合でも、業務上の優先順位は自社で決めます。
AMLシステムにAIを入れれば誤検知は必ず減りますか？
AIを入れても、誤検知が減るとは限りません。顧客IDの統合や正解データが不足していたり、調査フローが変わらなかったりすると、誤検知や負荷は残ります。
過去データを使うPoCでは、誤検知率や検知漏れを測ります。アラート件数や調査時間、根拠の説明可能性も測ったうえで、AIを人の判断支援として評価します。
まとめ
AMLシステムは、機能一覧や初期費用より先に、自社のリスク評価とデータを見て考えます。検知・調査、監査証跡、有効性検証も含めて、一つのプロジェクトとして設計します。
導入速度や標準機能を重視するならSaaS・パッケージ、既存基盤を段階的に変えるならハイブリッド、独自要件が大きいならスクラッチを検討します。運用責任を持てる方式を選びます。
発注前に確認する5つのポイント
発注前には、業務、データ、RFP、契約、総費用の5つを確かめておきます。
- 業務とリスク：対象業務と自社のリスク評価の整理
- データ：顧客ID・口座ID・取引ID、データ量、欠損、名寄せ、連携方式の状態
- RFP：機能、非機能、PoC指標、受入条件の、候補企業への共通提示
- 契約：成果物、責任分界、ルール変更、障害対応の定義
- 総費用：保守、チューニング、監査、教育、移行を含む5年TCOと出口条件の比較
最初の一歩はRFP前のデータと業務の洗い出し
発注を急ぐ場合でも、まずは顧客・取引データとアラート処理を一枚にまとめます。承認・エスカレーションや監査資料も、同じ資料に加えます。その資料をもとに、発注形態や、委託先に求める金融・AML知見、PoC指標を決めます。
AMLシステムは、導入後もルールやリスクの変化に合わせて検証を続けます。自社業務を把握し、外部の専門性と組み合わせることが、費用とリスクを抑える発注につながります。
▼全体ガイドの記事
・AMLシステム開発の完全ガイド
▼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を創業。