KYCシステムの発注は、業務範囲と要件を整理したうえで、RFPを作って提案を比べ、契約へ進みます。そのあと、PoCを経て開発、受入、運用設計の順に進みます。
業務に合う発注形態の選び方、要件・契約・費用の整理、委託先と見積の比べ方を説明します。全体像はKYCシステム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・KYCシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
KYCシステムを発注する前に押さえる全体像
Know Your Customerの略であるKYCは、顧客本人や本人特定事項、取引目的、事業内容を確認したうえで、リスクに応じて継続的に管理することを指します。KYCシステムは、本人確認画面だけを指す場合もあります。ただし発注時には、審査、再提出、リスク評価、監査、データ連携までを一つの業務基盤として捉えます。
eKYCだけではカバーしきれないKYCシステムの範囲
KYCシステムの発注では、本人確認の入口から継続管理まで、対象を整理します。
- eKYC：運転免許証やマイナンバーカードを撮影・IC読取し、オンラインで本人確認
- KYC・KYB：法人の実在性と実質的支配者、PEPs・制裁・反社情報を確認
- 継続管理：取引目的の確認、リスク評価、定期的な再確認を実施
審査担当者がExcelやメールで判断履歴を管理し続けている運用では、KYC業務全体がシステム化されたとは言えません。対象範囲は、個人の新規申込、法人の口座開設、本人確認後の取引モニタリングを分けて決めます。対象を広げるほど、費用と期間も増えます。
全機能を一度に作る必要はなく、機能は段階的に広げる形で進められます。たとえば、低リスクの個人申込で本人確認完了率や審査時間を測り、効果を確かめた機能から広げます。
発注範囲の「確認」「判定」「管理」「証跡」への分け方
要件表では、KYC業務は次のとおりに分けて整理できます。
- 確認：本人確認書類を取得する
- 判定：自動の仕組みか目視で審査を行う
- 管理：顧客情報の更新と再審査
- 証跡：判定理由、操作者、時刻の記録
連携先も業務フローに記載します。口座開設、会員登録、決済のほか、CRMや勘定系も含めます。
範囲が曖昧なままだと、提案会社ごとに機能や納品物が変わり、価格を比べられません。そのため、監査ログや再提出理由、権限管理もRFPに明記します。データの保存・消去や障害時の代替運用も、同じRFPに書いておきます。
KYCシステムの発注形態の選び方
標準的な本人確認を早く始めたいなら、SaaS・APIが候補になります。業界固有の審査や基幹連携が必要なら、パッケージ導入やSIを検討します。
独自の顧客・取引リスク管理を競争力にしたい場合は、個別開発やハイブリッドを選択肢に入れます。会社の規模より、独自性、法令対応の責任、将来のデータ移行を基準に選びます。
SaaS・API型が向く短期導入と標準機能の活用
SaaS・API型は、本人確認機能をサービスとして利用し、標準機能を早く導入する方式です。
- 本人確認：書類撮影、顔照合、ライブネス判定、ICチップ読取
- 導入・更新：画像解析基盤を自社で持たずに済み、法令対応や更新も任せやすい
- 適する事業：新規サービスの検証や、月間件数がまだ見えない事業
API接続を済ませても、導入がそれだけで完了するとは限りません。申込画面や顧客IDとの紐付け、審査結果の取込のほか、再提出通知やケース管理が自社側に残る場合があります。
監査ログや、API停止時の手作業の内容も確認しておきます。契約前には、データの保管場所や学習利用、解約時の返却を確かめてください。SLAや再委託先も、契約書で押さえます。
パッケージ＋SIで金融業務と個別要件を両立する進め方
導入前に、標準機能と自社要件の対応範囲を確かめます。
- 標準機能：KYC・AML・ケース管理などを基礎に、業務フローや既存システム連携を追加
- 業務対応：権限管理や承認履歴、リスト照合を揃え、金融・決済・保険などの個別審査ルールも扱える
- 追加作業：一見すると標準で足りても、追加モジュールや設定作業が必要な場合がある
見積は内訳ごとに分けてもらいます。特に、ライセンスと初期設定、追加開発は別々に示してもらうと比べやすくなります。データ移行、テスト、教育、保守なども含めてください。
デモでは、再提出や差し戻し、二重承認、監査抽出をサンプルデータで確かめます。
個別開発・ハイブリッドが向く独自業務とデータ主権の重視
独自業務やデータ管理を重視する場合は、個別開発とハイブリッドが候補になります。
- 個別開発：顧客・取引・不正検知データを統合し、独自判定を作る
- ハイブリッド：本人確認はSaaS、顧客・監査データは自社基盤に置く
- 標準化：結果を自社モデルへ変換し、ベンダー固有項目と分ける
個別開発では、法令改正や本人確認方式の変更、脆弱性対応などを自社か委託先が担います。モデル更新や24時間の障害対応も含むため、開発費だけでなく運用体制も確認します。
ハイブリッドの構成によっては、独自のAML判定を別サービスに分ける形もあります。
KYCの結果は、顧客ID、確認方式、判定結果を含む標準データモデルに置き換えておきます。判定理由や証跡、ルールやモデルの版も含めます。そうしておけば、ベンダー変更や相見積への備えになります。
KYCシステムの発注・外注の進め方と順番
KYCシステムは、現状業務の洗い出しから運用設計まで、段階を追って進めます。その際、発注者は業務上の判断基準を整理し、委託先には技術や実装、運用設計の専門性を求めます。
大まかには、現状業務を洗い出して対象範囲を決め、RFPを作って提案を比べます。そのうえで契約し、PoCを経て開発、受入、運用設計へ進みます。
現行業務と法的根拠の棚卸し
申込から疑わしい取引の調査まで、業務の順序と確認条件を洗い出します。
- 申込、本人確認、差し戻し
- 目視審査、承認、口座開設
- 情報更新、疑わしい取引の調査
各工程について、担当者と確認・保存するデータ、次へ進む条件を記録しておきます。郵送やメール、Excelへの転記、経験に頼った判断が見えると、どこから自動化すべきかを決めやすくなります。
本人確認方式の条件は、犯収法の対象事業者かどうかと取引内容によって異なります。金融庁の「犯罪収益移転防止法におけるオンラインで完結可能な本人確認方法に関する金融機関向けQ&A」は、2025年7月1日に更新されました（出典：金融庁、2025年）。
また、警察庁JAFICも、2026年3月公布の改正に関するQ&Aを公開しています（出典：警察庁JAFIC、2026年）。そのため、古い要件表を転用しないよう注意してください。
RFPに書く業務範囲・データ・非機能要件
RFPでは、提案の前提となる条件を揃えます。対象顧客や件数、本人確認方式を明記すると、提案を同じ前提で比べられます。
- 業務範囲：個人・法人の割合、月間・繁忙期件数、国内外、書類、再提出、目視審査
- 照合対象：PEPs、制裁、反社チェックの範囲
- データと連携：既存API、移行件数、権限、担当者数
非機能要件には、稼働時間や可用性、応答時間を盛り込みます。さらに、同時申込数や復旧目標、ログ保存期間も書いておきます。暗号化とアクセス制御も挙げておきます。
脆弱性診断や保管国もRFPに明記します。再委託、バックアップ、データの返却・消去については、扱いを具体的に書きます。
たとえば、「操作者・時刻・判定前後の値を検索できる」「権限のない担当者は本人確認画像を閲覧できない」のように、テストで確かめられる文にします。
一つの申込導線に絞ったPoCとKPIでの判定
提案会社のデモに加えて、自社の申込導線を使った小規模なPoCを行います。対象は、低リスクの個人申込など一つに絞ります。
- 利用者側：本人確認完了率、再提出率
- 審査側：平均審査時間、目視審査件数
- 品質と費用：誤受入・誤却下、1件あたりの運用コスト
判断は、AIの精度だけでなく、業務時間や利用者の離脱がどれだけ減るかで行います。PoCの期間やサンプル件数、成功基準は契約前に決めておきます。検証後のデータ消去の方法も、同じ時期に取り決めます。
製品版に移るときの追加費用も確かめておきます。検証対象は、方式比較、API連携、ケース管理のどれかに絞り、機能を無制限に増やさないようにします。
KYCシステムの契約形態と責任分界
KYCは法令に関わる業務で、個人情報や本人確認画像、審査判断を扱います。そのため、開発契約だけでなく、運用中に誰がどこまで責任を負うかも決めておく必要があります。
請負、準委任、SaaS利用契約を組み合わせるケースもあります。その場合は、契約名だけでなく成果物や検収条件まで決めます。障害対応や法令改正時の担当者も、契約書に明記します。
成果物と責任の違いで見る請負と準委任の使い分け
契約形態は、成果物を定められる工程か、不確実性の高い支援工程かで選びます。
- 請負：合意したシステムや機能を完成させ、検収を受ける
- 準委任：専門家の作業やプロジェクト支援が対象
請負では、画面やAPI、テスト仕様書などを成果物として明確にします。データ移行や運用手順書も書き出しておきます。
要件が固まらないまま全工程を請負にすると、変更や追加費用で揉めやすくなります。
準委任は、要件定義や現状分析、PoC、運用設計などに使いやすい契約です。また、発注者も意思決定や成果物のレビュー、優先順位付けを担います。
要件定義は準委任、仕様が確定した後の開発は請負、稼働後の保守は準委任とする組み合わせがあります。この形は、要件が段階的に固まる案件と相性がよいです。
契約書に書くSLA・障害・法令改正の担当者
SaaS・API契約では、稼働条件や障害対応、法令改正時の役割を決めておきます。
- SLA：提供時間、月間稼働率、API応答、障害通知、復旧目標
- 運用：保守告知、窓口、停止時の保留・目視切替・再処理
- 改正対応：情報提供、仕様変更、テスト、リリースの担当
- 費用条件：無償範囲、追加費用、通知期間、緊急対応料金
最新の資料を確認する最終的な責任は、対象事業者の側にあります。そのため、社内の法務・コンプライアンス担当もプロジェクトに加えてください。
個人情報・監査・再委託の条件
KYCでは、本人確認書類や顔画像、住所を扱います。生年月日や法人情報、取引目的も含むため、委託先の安全管理措置を点検します。
- 委託先確認：監査報告書、セキュリティシート、保管場所、海外移転
- RFP条件：ログ、権限分離、再委託承認、事故報告、返却・消去証明
個人情報保護委員会と金融庁の金融分野向けガイドラインは、利用目的や安全管理、従業者と委託先への監督について示しています（出典：個人情報保護委員会・金融庁、2024年）。
金融関連では、FISC「金融機関等コンピュータシステムの安全対策基準・解説書」第13版も点検の材料になります（出典：FISC、2025年）。
FISC基準は、すべての事業者に一律で適用されるものではありません。ただし、点検の材料として、RFPに点検条件を含めておくと、確認漏れを減らせます。
KYCシステムの費用相場の目安
KYCシステムの費用は、eKYCの標準APIだけであれば初期費用0〜300万円程度が参考レンジです。法人確認や目視審査、CRM連携まで含めると、300万〜1,500万円程度になります。
AML・金融業務向けパッケージは1,000万〜5,000万円程度です。大規模スクラッチや基幹連携は、5,000万円〜3億円以上が目安になります。数字を見るときは、公開価格と推定、個別見積を区別して読みます。
公開料金と開発費の切り分け
料金は、公開価格、開発費、運用費に分けて比べます。まず、公開料金の例を挙げます。
- 公開料金：GMO顔認証eKYCは初期費用なし、50件・月額22,000円から（2026年3月時点）
- 開発費：要件定義、業務設計、画面、API、権限、移行、テスト、インフラ、監査、マニュアル
- 運用費：基本料、従量料、照合、クラウド、保守、リスト更新、審査、改正対応、問合せ
公開価格はGMOグローバルサインの案内によるものです（出典：GMOグローバルサイン、2026年）。ただし、これは本人確認サービスの利用料で、KYC業務全体の費用ではありません。
申込画面やAPI連携、データ紐付けは、別見積になる場合があります。審査画面やログ、脆弱性診断、運用教育も、別の見積として出てくることがあります。
3年TCOでの比較
3年TCOは、費用を一つの数字にまとめて比べる方法です。3年TCOには初期費用と36か月分の利用・運用費を含めます。比べるときは、件数や機能、運用の条件もそろえて見ます。
- TCO項目：初期費用、36か月の基本・従量料、連携改修、保守、審査運用、移行
- 件数：月間件数、繁忙期のピーク、個人・法人比率
- 機能：書類・確認方式、顔認証、海外顧客、多言語、リスト照合
- 運用：取引監視、データ品質、オンプレミス、災害対策、目視審査
初期費用が安いAPIでも、件数が増えると従量料金が大きくなります。一方で、高額なパッケージは、大量処理や業務自動化によって1件あたりの費用が下がる場合があります。
費用相場は案件の条件で変わるため、金額だけでなく、含まれる機能と運用も比べます。
見積依頼で渡す件数と前提条件
KYCの処理量と審査体制を踏まえて、見積の条件をそろえます。
- 需要：月間新規申込・1日最大件数、繁忙時のピーク、対象国、端末
- 審査：完了目標、目視審査率、法人確認件数、稼働時間
- 料金：初年度導入費、2年目以降の保守費、本人確認1件の追加単価、契約最低件数、超過単価
- 契約後：テスト環境、サポート、改正対応、解約時のデータ出力
「大量」や「高い可用性」といった言葉は、会社ごとに前提が異なります。たとえば、月間1万件か、繁忙日だけ1時間に1,000件かを示すと、基盤と運用人員を比べられます。
推定費用の場合は、前提に加えて、上下に振れる要因も示してもらいます。そうすると、経営会議で説明しやすくなります。
KYCシステムの委託先選定と見積比較のポイント
委託先は、知名度や価格だけでなく、自社業務とリスクへの適合で選びます。API会社やKYC・AMLパッケージ会社、金融系SIer、業務整理から支援する開発会社では、得意な工程が異なります。
提案書の機能数より、同業種や同じ確認方式、同規模の連携実績を確かめます。
金融・決済・法人確認の実績の確かめ方
自社に近い業種の事例を確認します。たとえば、金融や決済、証券などです。導入社数よりも、実績の中身を尋ねることが大切です。
- 業務実績：完了率、審査時間、目視審査、リスト照合
- 連携実績：法人KYB、CRMや勘定系との接続
- 担当範囲：規模、対象件数、稼働後の運用体制
顧客名を開示できなくても、業種や規模、担当範囲は説明できるはずです。
サービス提供者やクラウド基盤、目視審査のBPO先が、別々になる場合があります。本人確認書類の照会先が加わることもあります。個人情報を扱う会社や障害対応者、再委託先を一覧にしてもらいます。
相見積で揃えるRFPと評価軸
相見積では、提案の条件と評価軸を揃えます。評価表に入れる項目は、観点ごとに整理します。
- 適合性：業務、確認方式、法人確認、AML・リスト照合
- 技術・管理：API・SDK、既存連携、監査ログ、セキュリティ
- 導入・費用：SLA、導入期間、3年TCO、担当者の経験
- 継続性：データ移行、解約条件
全社に、RFPや業務フローを同じ形で渡します。サンプルデータや非機能要件、希望日程も、そろえて提示します。質問への回答も、可能な範囲で共有します。
業務の解釈が違う見積を合計額だけで比べると、後から追加開発が増える可能性があります。そのため、価格を100点満点の大部分にせず、法令・セキュリティ・運用の不確実性を減らす提案を評価します。
安さだけを強調する提案の見極め
「初期費用だけ」「月額だけ」「AIで完全自動化」と説明しつつ、追加費用や例外時の対応を示さない提案には注意します。
- 費用・運用：従量料、目視審査、改正、ログ、代替策、データ返却
- 停止・失敗：失敗時の救済、誤判定の再審査、API停止時の扱い
- 異常時：偽造書類、顔・IC失敗、重複、制裁該当、権限逸脱、通信障害
- AI：判定根拠、モデル版、人手介入、学習データの扱い
デモの成功例やAIの精度だけで決めず、異常時の処理、判定根拠、人の介入条件を確かめます。
よくある質問
発注では費用のほかに、対象業務や法令対応も確認します。データ管理と運用責任も含めて見る必要があるため、下の質問には発注判断の観点から答えます。
KYCシステムの発注費用を安く抑える方法はありますか？
標準的な本人確認はSaaS・APIを使い、独自性が必要な顧客管理やケース管理だけを自社開発する方法があります。
対象顧客と本人確認方式を一つに絞ったPoCで効果を測り、不要な機能を作らないことも有効です。初期費用だけでなく、3年TCOや障害・法令改正の対応費まで比べます。
KYCシステムのRFPには何を書けばよいですか？
RFPには、対象業務と顧客・法人の種類、月間・ピーク件数を記載します。書類や確認方式、審査・再提出の流れも書きます。外部リストや既存連携、保存する証跡も記載します。
権限や稼働率、復旧目標も含めます。さらに、データ保管場所や再委託、解約時の返却も書きます。「自社が保持するデータ」と「委託先が処理するデータ」を分けておくと、比べやすくなります。
小規模事業者でもKYCシステムを外注できますか？
外注はできます。月間件数が少ない場合は、初期費用のないSaaS・APIや、開発の要らない本人確認サービスから始める方法があります。
GMO顔認証eKYCのように最小件数と月額を公開するサービスもあります。顧客管理や審査、監査は、自社の責任として残ります。個人情報の委託先管理も自社が担うため、運用フローを作成しておきます。
将来ベンダーを変更できるKYCシステムにするにはどうすればよいですか？
顧客IDや確認方式・日時、判定結果を含む項目は、自社の標準データモデルで保持します。判定理由や証跡、ルールやモデルの版も含めます。ベンダー固有のAPI項目とは、分けておいてください。
契約には、データ形式と出力期間、費用を含めます。加えて、画像やログの返却・消去と、移行支援の範囲も定めておきます。切替用のテスト環境と代替手順は、稼働前に準備しておきます。
まとめ
KYCシステムの発注では、eKYCやKYB、CDD、AML、継続的顧客管理のうち、どこまでを対象にするかを決めます。
そのうえで、SaaS・API、パッケージ＋SI、個別開発・ハイブリッドを比べます。比べる軸は、独自要件と法令対応、データ主権です。さらに、運用体制と3年TCOも見ます。
最初に整える業務フローとRFP
発注者は、現行業務と月間件数、対象書類、審査基準をRFPに書きます。連携先やログ、SLAも書いておきます。障害時の代替策やデータ返却も、RFPに入れます。
同じ前提を複数社に渡し、PoCで完了率や審査時間、再提出率を測ります。誤判定や1件あたりのコストも押さえると、本開発の前に見積の妥当性を判断しやすくなります。
価格よりも責任分界と将来の変更可能性
契約前には、本人確認と最終判断、法令改正の担当者を明確にしてください。障害や誤判定、個人情報事故への対応者も決めておく必要があります。
標準データモデルや監査ログ、解約時のデータ返却を確保しておくと、ベンダー変更や機能拡張に備えられます。KYCを顧客・リスク・証跡の業務基盤として発注すれば、長期的な安全性と費用対効果にもつながります。
▼全体ガイドの記事
・KYCシステム開発の完全ガイド
▼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を創業。