AMLシステム開発の発注/外注/依頼/委託方法について

AMLシステムの発注・外注は、製品を購入するだけではなく、自社のリスク評価、データ、調査業務、監査証跡までを一体で設計して委託することが成功の条件です。

本記事では、AMLシステムの発注形態の選び方から、RFPに書くべき要件、要件定義やPoCの進め方、契約形態、費用相場、委託先の選定と見積比較のポイントまで、発注側が準備すべき実務を順番に解説します。金融機関だけでなく、資金移動業者、暗号資産交換業者、決済事業者など、AML/CFT対応を外部パートナーに相談したい方にも役立つ内容です。

▼全体ガイドの記事
・AMLシステム開発の完全ガイド

AMLシステムを発注・外注する前に知っておきたい全体像

AMLシステムは、本人確認だけを自動化するツールではありません。顧客の入口で行うKYC、顧客リスク評価、制裁・PEP・反社会的勢力などのスクリーニング、取引モニタリング、アラートの調査、疑わしい取引の届出支援、監査ログまでをつなぐリスク管理基盤です。したがって、発注の成否は画面の数やAIの有無よりも、自社の業務とデータが正しくつながり、判断の根拠を後から説明できるかで決まります。

発注前にまず決めるのは、「何を導入するか」ではなく「どのリスクを、どの業務で、どの証跡を残しながら低減するか」です。たとえば、法人口座の不正利用を重視する事業者と、海外送金や暗号資産のトランザクション監視を重視する事業者では、必要なデータ、検知シナリオ、アラートの優先順位が変わります。顧客数、月間取引件数、対象国、商品・チャネル、高リスク顧客の割合を整理しないまま製品を比較すると、不要な機能に費用を払い、必要な連携が後から追加されることになります。

金融庁は、2025年の資料で、AML/CFTの有効性検証について、取引モニタリングのシナリオや敷居値を定期的に検証・調整する取り組みを示しています。導入した事実だけでは十分ではなく、自社が直面するリスクに対して有効に機能しているかを測定し、改善できる仕組みが必要です（出典: 金融庁「マネー・ローンダリング等及び金融犯罪対策の取組と課題」、2025年）です。

AMLシステムの開発や運用を外部委託しても、発注側のAML/CFTに関する管理責任が委託先へ移るわけではありません。委託先が用意した標準ルールを採用する場合も、自社の顧客層や取引の特徴に合うか、アラートを現場が処理できる量か、疑わしい取引の判断理由を説明できるかを自社で確認する必要があります。契約書には、役割分担だけでなく、検証データの提供、ルール変更の承認、障害時の連絡、監査への協力、解約時のデータ返却まで記載します。

金融庁の2026年FAQでも、外部委託や共同システムを利用する場合に、自社の規模、ビジネスモデル、顧客層、取引状況を踏まえて適合性を検討する考え方が確認されています。これは、外注を禁止する趣旨ではなく、外部サービスを使う場合でも自社のリスクに応じた追加対応を考えるという意味です（出典: 金融庁「マネロン・テロ資金供与対策ガイドラインに関するFAQ」、2026年）です。

AMLシステムの発注形態はどのように選べばよいですか？

AMLシステムの発注形態は、SaaS・API、パッケージやクラウド、既存システムを活かすハイブリッド、独自開発の大きく4つで整理できます。最適解は企業規模だけでなく、必要な導入速度、独自ルールの多さ、既存データの品質、将来の対象国や取引量、社内に運用できる人材がいるかで変わります。

SaaSやAPIは、制裁リスト検索、簡易的なKYC、少量の取引モニタリングを早く始めたい場合に向いています。初期投資を抑えやすく、機能追加や規制情報の更新をサービス側に任せられる一方、従量課金の増え方、データの保管場所、学習データへの利用、障害時の代替手段、解約時のエクスポートを確認する必要があります。小規模な事業者でも、顧客・取引データの連携とケース管理が必要なら、単純なAPI接続だけでは運用が完結しない場合があります。

パッケージや金融機関向けクラウドは、標準的なKYC、顧客リスク評価、取引モニタリング、調査ワークフローを使いながら、自社向けの設定を加える方式です。規制対応や導入実績を確認しやすい反面、標準機能に業務を合わせる範囲と、カスタマイズする範囲を最初に決めないと費用が膨らみます。既存のAMLを残してケース管理やAIスコアリングを追加するハイブリッドは、現行業務を止めずに改善しやすい選択肢です。

スクラッチ開発は、独自の顧客リスクモデル、大量取引の特殊な処理、複数国にまたがる複雑なデータ連携など、既製品では重要な差分を吸収できない場合に検討します。画面やルールを自由に設計できる反面、規制やリストの更新、検知ロジックの検証、モデルの再現性、担当者の交代、脆弱性対応までを自社と開発会社で継続的に担います。開発費だけでなく、5年分の保守・改善費を同じ土俵で見積もることが大切です。

発注形態を決めるときは、次の3つの問いを順番に確認します。第一に、最初の稼働を何か月以内に実現する必要があるかです。第二に、標準シナリオを採用できない業務差分がどれほどあるかです。第三に、導入後にルールを調整し、検証結果を経営や監査へ報告できる体制があるかです。短期導入だけを優先してSaaSを選ぶのではなく、業務と責任の持ち方まで含めて選定します。

RFP・要件整理からAMLシステム発注までの進め方

AMLシステムの発注は、いきなり開発会社へ相談するのではなく、発注側が自社の前提を整理してからRFIやRFPを出すと比較しやすくなります。すべての仕様を決め切る必要はありませんが、対象業務、データ量、期待する成果、制約条件、委託後の責任範囲は、少なくとも同じ条件で各社へ伝えます。

最初に、対象範囲を業務フローで書き出します。口座開設時の本人確認、法人の実質的支配者の確認、顧客リスク格付、制裁・PEPのスクリーニング、取引モニタリング、アラート調査、承認・エスカレーション、疑わしい取引の届出支援を、誰がいつ何を判断するかまで分解します。各工程で、現行システム、担当部署、入力情報、出力帳票、保存期間、困っている点を並べると、ベンダーに相談する要件が見えます。

次にデータを棚卸しします。顧客ID、口座ID、取引IDをどのシステムが持ち、氏名や住所の表記ゆれ、法人番号、国・地域、通貨、取引目的、送金先情報がどの程度そろっているかを確認します。連携本数、日次かリアルタイムか、ピーク時の件数、過去データの保持期間、欠損率、名寄せ率をサンプルで測定します。AMLシステムの精度を上げたいときほど、AIモデルより先にデータ辞書とデータリネージを整えることが近道です。

成果指標は、検知率だけにしないことが重要です。過去に疑わしいと判断された取引をどの程度再現できるか、誤検知によるアラート件数が何件になるか、1件の調査にかかる時間、担当者間の判断差、処理遅延、検知理由を説明できる割合、ルール変更後の品質を測る指標を設定します。発注前に測定方法を合意しておけば、PoCや受入テストで「使いやすい」「高性能そう」といった主観だけに頼らず判断できます。

RFPの機能要件には、KYC/CDD、顧客リスク評価、制裁・PEP・反社・ネガティブニュースの検索、取引モニタリング、アラートの重複排除、ケース管理、調査メモ、承認、届出支援、レポートを記載します。シナリオを追加・停止・変更できるか、閾値の根拠を保存できるか、顧客単位で複数アラートを束ねられるか、過去の入力データと判断結果を再現できるかも質問します。

非機能要件には、可用性、処理性能、バックアップ、災害復旧、暗号化、多要素認証、最小権限、職務分掌、操作ログ、ログの改ざん防止、脆弱性対応、監視、障害通知、データ所在地、委託先監査、データの持ち出し方法を含めます。特にAML業務では、システムが停止したときの手作業や後追い処理をRFPに書く必要があります。金融庁は2025年のITレジリエンスに関する分析で、金融機関ごとにリスクプロファイルが異なるため、一律のチェックリストだけでは足りない考え方を示しています（出典: 金融庁「金融分野におけるITレジリエンスに関する分析レポートの概要」、2025年）です。

AIを使う場合は、AIという言葉だけで評価しないことが大切です。学習データの範囲、モデルの更新頻度、バージョン管理、出力の再現性、スコアの根拠、担当者が修正した内容の保存、モデル検証の方法、誤判定時の人による上書き、機密データの目的外利用を確認します。生成AIで調査メモの要約を行う場合も、最終判断と承認は担当者が行い、AIの出力をそのまま届出理由にしない運用を定義します。

候補を2〜4社に絞ったら、実データを匿名化したPoCを実施します。過去の取引やアラートを使って、既存の判断をどの程度再現するか、誤検知が何件出るか、1件の調査に何分かかるか、ピーク時間帯の処理遅延が許容範囲かを確かめます。サンプルが少ないと結果が偏るため、通常取引だけでなく、高リスク国、複雑な名寄せ、複数口座をまたぐ取引、過去に疑わしいと判定された事例を含めます。

本番移行では、既存システムをいきなり停止せず、一定期間の並行稼働を設けます。新旧システムの検知結果、アラート件数、調査時間、判断差、データ欠損を比較し、差分をレビューします。受入条件には、画面が表示されることだけでなく、指定した取引が正しく取り込まれること、想定したシナリオが発火すること、担当者以外の権限では見られないこと、ルール変更履歴が残ること、障害時に復旧できることを含めます。

NTTデータは2025年、ACSiONと連携し、法人口座の開設から取引モニタリングまでを一貫して扱うAML/CFTサービスを提供開始しました。既存のインターネットバンキングや口座開設サービスと接続できる事例は、連携範囲を発注時に確認する重要性を示しています。自社でも、どの既存システムを置き換え、どのシステムを残し、どのデータを誰が正本として管理するかをRFPで明確にします（出典: NTTデータ「マネロン・不正利用を防ぐ、法人口座向けの対策サービスを提供開始」、2025年）です。

AMLシステムの契約形態と外注時に確認する責任分界

AMLシステムの契約は、準委任、請負、SaaS利用契約、保守・運用契約を組み合わせることが一般的です。要件が固まっていない段階から完成品の納品を約束するのは難しいため、要件定義やPoCは準委任、仕様と成果物が確定した開発は請負、継続利用はSaaS、リリース後の改善は保守契約というように、業務の性質に合わせて分けて考えます。

準委任契約は、専門家の支援や作業時間に対して報酬を支払う形態で、要件定義、データ棚卸し、RFP作成、PoC支援、運用改善のように成果物を一つの仕様で確定しにくい業務に向きます。請負契約は、合意した仕様のシステムや成果物を完成させる形態で、開発範囲と受入条件が明確な工程に適しています。契約形態の名前だけでなく、納品物、検収方法、変更管理、遅延時の扱いを確認します。

SaaS利用契約では、利用料に含まれる機能、データ処理量、サポート時間、障害時のSLA、保守時間、規制・リスト更新の責任、サブプロセッサー、データ所在地を確認します。月額料金が安くても、顧客数や取引数が増えたときの従量課金、追加環境、過去データの保管、APIの利用料が大きくなる場合があります。契約期間と自動更新の条件も、稟議の段階で把握します。

個人情報や取引情報を扱うため、秘密保持や安全管理だけでなく、委託先が再委託する場合の承認・管理方法を決めます。アクセス権限、ログ保存期間、脆弱性診断、インシデントの第一報の期限、原因分析、再発防止、監査資料の提出、当局や内部監査への協力を条項化します。クラウドサービスを使う場合は、データの保管地域、バックアップ地域、暗号鍵の管理者、障害時の復旧目標も確認します。

特に見落とされやすいのが契約終了時の出口条件です。顧客情報、取引履歴、アラート、ケース、調査メモ、ルール、閾値、モデルのバージョン、監査ログを、どの形式で、いつまでに、いくらで返却するかを決めます。返却後に委託先が削除したことを証明する方法、別のサービスへ移行する支援、並行稼働期間、API仕様書やデータ辞書の引き渡しも含めます。移行できない契約は、将来のベンダー変更や事業拡大のコストを見えにくくします。

ルールやモデルの変更権限も責任分界の中心です。委託先が規制情報を受けて標準ルールを更新する場合でも、自社の承認なしに本番へ反映するのか、テスト環境で検証してから反映するのかを定義します。金融庁が2026年に公表した資料では、外部委託先の管理もAML/CFT態勢の論点として整理されています。委託先が「対応済み」と説明することと、自社のリスクに対する有効性を検証できることは別であるため、契約と運用の両方で確認します（出典: 金融庁「マネー・ローンダリング等及び金融犯罪対策の取組と課題」、2026年）です。

AMLシステムの費用相場と見積もりの内訳

AMLシステムの国内価格は、顧客数、取引件数、対象国、リストの種類、連携本数、リアルタイム性、既存基盤の状態で大きく変わります。専用製品の一律価格表は限られるため、以下は公開価格、金融系業務システムの相場、個別要件をもとにした発注時の目安です。実際の見積として断定せず、同じ前提条件で複数社から提案を受けて比較します。

小規模なSaaS・API導入は、初期費用0〜500万円、月額10万〜100万円または従量課金、期間1〜3か月が一つの目安です。制裁リスト検索や簡易KYC、限定された取引モニタリングから始めたいフィンテックや決済事業者に向きます。金融機関向けクラウド・パッケージ導入は、初期500万〜3,000万円、年額500万〜3,000万円程度、期間3〜9か月が目安です。料金は対象機能と連携範囲で大きく変わります。

中規模の追加開発やハイブリッドは、初期3,000万〜1億円、ランニング年額1,000万〜5,000万円程度、期間6〜12か月が目安です。既存AMLを残しながらデータ基盤、AIスコアリング、ケース管理を追加する場合などが該当します。大規模スクラッチやオンプレミスは、初期5,000万円〜数億円、保守・基盤・リスト更新を含むランニング年額1,000万〜数億円、期間12〜24か月以上になる可能性があります。いずれも国内AML専用の公開価格が少ないことを踏まえた推定です（出典: NotebookLMリサーチノート「AMLシステム」、2026年）です。

公開価格の例では、Alibaba CloudのSMART AMLに、機能ごとのワンタイムセットアップ36,000米ドルや、取引モニタリングの1取引0.19米ドルという価格が掲載されています。これは日本の金融機関向けの相場ではなく、海外サービスの価格設計を知るための参考値ですが、初期設定費と顧客・取引量に応じた従量課金が併存することを理解できます（出典: Alibaba Cloud「Financial Intelligence Engine Pricing」、2026年）。為替、契約地域、サポート範囲、税金は別に確認します。

見積の初期費用は、ライセンスやクラウド利用料、要件定義、設計・設定、データ連携、データクレンジング、移行、テスト、研修、運用設計に分解します。初期費用の仮説として、ライセンス・クラウドが40〜60%、要件定義・カスタマイズ・連携が20〜30%、テスト・移行・研修が10〜20%、運用支援やモデル検証が10〜20%という比率で整理すると、どこに差があるかを確認しやすくなります。ただし、大規模案件ではデータ統合とテストの比率が高くなるため、比率を固定的な基準にしないことが大切です。

ランニング費用には、リストの更新、クラウド・ストレージ、監視、保守、ルール追加、閾値チューニング、モデル検証、再学習、監査対応、教育、問い合わせ対応を含めます。たとえば、初期3,000万円に年額1,500万円がかかる5年間のTCOは1億500万円です。一方、初期1億円のスクラッチに年額2,000万円の保守が必要なら、5年で2億円になります。単年度の安さではなく、同じ期間・同じ業務範囲で比較します。

見積にデータクレンジングが含まれているかは、必ず確認します。氏名の漢字、法人名、住所、国名、通貨、日付、顧客IDの不統一は、検知精度や名寄せに影響します。発注後に「データが汚れているため追加作業」となりやすい領域なので、サンプル調査の結果、対象項目、修正方法、追加費用の単価、発注側が用意する作業を見積書に明記します。

委託先の選定とAMLシステムの見積比較ポイント

委託先は、製品の知名度だけでなく、金融業務の理解、データ連携力、調査現場への定着支援、検証と改善の体制で選びます。候補企業から同じRFPへの回答を受け、価格、提案の具体性、リスクの指摘力、担当者の経験、運用開始後の支援を分けて評価します。提案書に自社の課題をそのまま反映せず、標準機能の説明だけで終わっている場合は、導入後の追加費用が増える可能性があります。

実績では、自社と同じ業態・規模・取引量の案件を確認します。銀行の口座開設と、暗号資産交換業者のトランザクション監視では、必要な知識と構成が異なります。NTTデータ、NEC、Oracle、NICE、SAS、野村総合研究所など、AML/CFTのサービスや製品を持つ実在企業は複数ありますが、企業名だけで優劣を決めるのではなく、要件定義を誰が担うか、日本の届出実務に詳しい担当者がいるか、同業案件でどのKPIを改善したかを確認します。

NECは、AI不正・リスク検知において不正スコアだけでなく、判断の根拠を提示するサービスや、マネー・ローンダリング対策共同機構のAIスコアリングサービスに関するシステム構築の取り組みを公表しています。これは、AIを採用する場合に「精度」だけでなく「説明できるか」「共同利用や自社運用にどう組み込むか」を評価する必要があることを示す事例です（出典: NEC「マネー・ローンダリング対策（AML）サービス」、2026年確認）です。

体制面では、プロジェクト責任者、AML業務の専門家、データ連携担当、セキュリティ担当、導入後のサポート担当が誰かを確認します。担当者が提案時だけ参加し、運用開始時に別のチームへ引き継がれる場合は、引き継ぎ資料と教育の内容を明確にします。月次のアラート品質レビュー、四半期ごとのシナリオ見直し、年次のモデル検証など、改善の頻度と費用も見積に含めます。

見積比較では、合計金額を先に見ず、前提条件をそろえます。顧客数、月間・年間取引件数、ピーク時の処理量、データ保持期間、連携方式、対象機能、環境数、ユーザー数、サポート時間、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で比較します。

なくなりません。開発、運用、データ分析の一部を委託できても、自社の顧客・取引リスクに適合するかを判断し、有効性を検証し、必要な改善を行う責任は発注側に残ります。契約では、委託先の作業範囲、承認者、ルール変更、監査協力、障害報告、データ返却を明確にし、社内に業務責任者を置きます。

すべての画面仕様を確定する必要はありませんが、対象業務、顧客・取引データ、件数、連携方式、必要な検知シナリオ、監査証跡、セキュリティ、SLA、PoCの評価指標、受入条件、契約終了時のデータ返却は書きます。候補企業が同じ前提で見積できる粒度にし、未確定の項目は「提案で確認したい事項」として質問します。RFP作成そのものを専門会社に支援してもらう場合も、業務上の優先順位は自社で決めます。

必ず減るとは限りません。AIを導入しても、顧客IDの統合が不十分だったり、正解データが少なかったり、現場の調査フローが変わらなかったりすると、誤検知や調査負荷が残ります。過去データを使ったPoCで、誤検知率、検知漏れ、アラート件数、調査時間、根拠の説明可能性を測定し、AIを人の判断を支援する仕組みとして評価します。

まとめ

AMLシステムの発注・外注では、製品の機能一覧や初期費用だけで判断せず、自社のリスク評価から必要なデータ、検知・調査業務、監査証跡、継続的な有効性検証までを一つのプロジェクトとして設計します。発注形態は、導入速度と標準機能を重視するならSaaS・パッケージ、既存基盤を活かして段階的に変えるならハイブリッド、独自要件が大きいならスクラッチというように、責任を持って運用できる方式を選びます。

発注前は、第一に対象業務と自社のリスク評価を整理します。第二に顧客ID・口座ID・取引ID、データ量、欠損、名寄せ、連携方式を確認します。第三にRFPで、機能、非機能、PoC指標、受入条件を候補企業へ同じ条件で示します。第四に、準委任・請負・SaaSを工程ごとに使い分け、成果物、責任分界、ルール変更、障害対応を契約に落とし込みます。第五に、初期費用ではなく保守、チューニング、監査、教育、移行まで含む5年TCOと出口条件を比較します。

発注を急ぐ場合も、まず現行の顧客・取引データ、アラート処理、承認・エスカレーション、監査資料を一枚にまとめます。その資料をもとに、必要な発注形態、委託先に求める金融・AMLの知見、PoCで測る指標が定まります。AMLシステムは導入して終わりではなく、ルールやリスクの変化に合わせて検証し続ける仕組みです。自社の業務を理解したうえで外部の専門性を組み合わせることが、費用とリスクの両方を抑える発注につながります。

▼全体ガイドの記事
・AMLシステム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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