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

KYCシステムの発注・外注は、eKYCの導入だけでなく、法人確認、リスク判定、継続的顧客管理、監査ログまでの業務範囲を決めてから、SaaS・パッケージ・個別開発を選ぶことが成功の近道です。

「何をRFPに書けばよいか分からない」「SaaSとスクラッチの見積を比べられない」「開発会社へどこまで任せるべきか不安」という担当者に向けて、KYCシステムの発注形態、要件整理、契約、費用相場、委託先選定、見積比較の進め方を解説します。法令や料金は更新されるため、公開前には必ず最新の公式資料と自社の法務・コンプライアンス部門で確認してください。

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

KYCシステムを発注する前に押さえる全体像

KYCはKnow Your Customerの略で、顧客が本人であること、本人特定事項、取引目的、事業内容などを確認し、リスクに応じて継続的に管理する業務です。KYCシステムは本人確認画面だけを指す場合もありますが、発注時には審査・再提出・リスク評価・監査・データ連携までを一つの業務基盤として捉えることが大切です。

eKYCは、運転免許証やマイナンバーカードなどの本人確認書類を撮影したり、ICチップを読み取ったりして、オンラインで本人確認を行う入口の機能です。一方で、KYC業務には法人の実在性や実質的支配者を確認するKYB、PEPs・制裁対象者・反社情報の照合、取引目的の確認、リスクスコアリング、定期的な再確認も含まれます。eKYC導入後に審査担当者がExcelやメールで判断履歴を管理する状態では、業務全体のKYCシステム化とは言いにくいです。

発注前に「個人の新規申込だけか」「法人の口座開設も対象か」「本人確認後の取引モニタリングまで対象か」を分けてください。対象を広げるほど費用と期間は増えますが、最初からすべてを一括開発する必要はありません。低リスクの個人申込で本人確認完了率や審査時間を測り、効果が確認できた機能から段階的に拡張する設計が現実的です。

要件表は、本人確認書類の取得を「確認」、自動判定や目視審査を「判定」、顧客情報の更新や再審査を「管理」、判定理由・操作者・時刻を残す機能を「証跡」として分けると作りやすいです。さらに、口座開設・会員登録・決済・CRM・勘定系など、どのシステムと連携するかを業務フロー上に記載します。

この分け方をしないまま「KYCシステムを作りたい」とだけ伝えると、提案会社ごとに含まれる機能が変わり、価格だけでなく納品物の範囲も比較できません。特に監査ログ、再提出の理由、権限管理、データ保存・消去、障害時の代替運用は見積の後半で追加費用になりやすいため、最初のRFPに明記することが重要です。

KYCシステムの発注形態はどれを選ぶべきですか？

結論から言うと、標準的な本人確認を早く始めたい場合はSaaS・API、業界固有の審査や既存基幹との統合が必要な場合はパッケージ導入やSI、独自の顧客・取引リスク管理を競争力にしたい場合は個別開発やハイブリッドが候補です。発注形態は会社規模ではなく、必要な独自性、法令対応の責任、将来のデータ移行までを基準に決めます。

SaaS・API型は、本人確認書類の撮影、顔照合、ライブネス判定、ICチップ読取などをサービスとして利用する方式です。自社で画像解析や不正対策の基盤を一から作らずに済み、本人確認方式の法令対応やサービス更新を提供会社に任せやすい点がメリットです。新規サービスの検証や、月間件数がまだ読めない事業者にも適しています。

ただし、APIをつなぐだけで導入が完了するわけではありません。申込画面、顧客IDとの紐付け、審査結果の取り込み、再提出通知、担当者のケース管理、監査ログ、API停止時の手作業フローは自社側の開発・運用範囲に残ることがあります。データ保管場所、学習利用の有無、解約時のデータ返却、SLA、再委託先を契約前に確認してください。

パッケージ＋SIは、KYC・AML・ケース管理などの標準機能を基礎に、業務フローや既存システム連携を追加する方式です。金融・決済・保険などで必要になりやすい権限管理、承認履歴、リスト照合、アラート管理を既製機能で揃えながら、自社固有の審査ルールにも対応しやすいです。

見積では、ライセンス費用、初期設定、追加開発、データ移行、テスト、教育、保守を分けて記載してもらいます。標準機能に見えても、実際には追加モジュールや設定作業が必要な場合があります。デモでは「自社の再提出、差し戻し、二重承認、監査抽出」を実際のサンプルデータで確認し、画面の見た目だけで判断しないことが大切です。

個別開発は、既存の顧客・取引・不正検知データを統合し、独自のリスク判定や審査業務を作り込みたい場合に向いています。一方で、法令改正、本人確認方式の変更、脆弱性対応、モデル更新、24時間の障害対応まで自社または委託先が継続して担う必要があります。開発費だけでなく、稼働後の運用体制を用意できるかを先に確認してください。

実務では「本人確認はSaaS、顧客・ケース・監査データは自社基盤、独自のAML判定は別サービス」というハイブリッドが比較しやすいです。KYC結果をベンダー固有の項目のまま保存せず、顧客ID、確認方式、結果、判定理由、証跡、ルールやモデルのバージョンを自社の標準データモデルへ変換すると、将来のベンダー変更や相見積にも対応しやすくなります。

KYCシステムの発注・外注はどの順番で進めますか？

KYCシステムの外注は、いきなり開発会社へ丸投げするのではなく、現状業務の棚卸し、対象範囲の確定、RFP作成、提案比較、契約、PoC、開発、受入、運用設計の順に進めます。発注者が業務上の判断基準を整理し、委託先には技術・実装・運用設計の専門性を求める役割分担が基本です。

まず、申込、本人確認、差し戻し、目視審査、承認、口座開設、情報更新、疑わしい取引の調査までを一枚の業務フローにします。各工程で誰が何を見て、どのデータを保存し、どの条件で次へ進めるかを記録してください。郵送、メール、Excelへの転記、担当者の経験に依存した判断が見えると、自動化の優先順位を決めやすくなります。

本人確認方式は、犯収法の対象事業者と取引内容により確認すべき条件が異なります。金融庁の「犯罪収益移転防止法におけるオンラインで完結可能な本人確認方法に関する金融機関向けQ&A」は2025年7月1日に更新されており、オンライン確認の方式や留意点を整理する際の基礎資料になります（出典: 金融庁、2025年）。2026年3月公布の改正についても警察庁JAFICがQ&Aを公開しているため、古い要件表をそのままRFPに転用しないでください（出典: 警察庁JAFIC、2026年）。

RFPには、対象顧客、月間・繁忙期の本人確認件数、個人と法人の割合、対応する本人確認書類、国内外の利用者、本人確認方式、再提出の条件、目視審査の有無、PEPs・制裁・反社チェックの範囲を記載します。顧客登録や口座開設との連携方式、既存システムのAPI、データ移行件数、利用者権限、想定する担当者数も必要です。

非機能要件では、稼働時間、可用性、応答時間、同時申込数、障害時の復旧目標、監査ログの保存期間、暗号化、アクセス制御、脆弱性診断、データの保管国、再委託、バックアップ、データ返却・消去を明示します。例えば「高いセキュリティ」ではなく、「操作者・操作時刻・判定前後の値・ルールの版数を検索でき、権限のない担当者は本人確認画像を閲覧できない」のように、テスト可能な文章にします。

提案会社のデモだけでなく、自社の申込導線を使った小さなPoCを実施してください。低リスクの個人申込など対象を一つに絞り、本人確認完了率、平均審査時間、再提出率、誤受入・誤却下、目視審査の件数、1件あたりの運用コストを測ります。AIの精度という言葉だけで評価せず、業務がどれだけ短くなり、利用者の離脱がどれだけ減るかで判断します。

PoCの期間、利用するサンプル件数、成功基準、検証後のデータ消去方法、製品版へ移行する際の追加費用を契約前に決めます。PoCが本番要件の検討を兼ねる場合でも、無制限に機能を追加すると目的がぼやけます。本人確認の方式比較、API連携、ケース管理のどれを検証するのかを一つずつ定義すると、発注判断に使える結果になります。

KYCシステムの契約形態と責任分界をどう決めますか？

KYCは法令、個人情報、本人確認画像、審査判断を扱うため、開発契約だけでなく運用中の責任分界まで決める必要があります。請負、準委任、SaaS利用契約を組み合わせる場合が多く、契約名だけでなく、成果物、検収条件、障害対応、法令改正時の対応者を具体化してください。

請負契約は、合意したシステムや機能を完成させ、検収を受けることを重視する契約です。画面、API、データ移行、テスト仕様書、運用手順書など、何を完成品とするかを明確にできる場合に向いています。ただし、法令解釈や業務要件が固まっていない段階で全工程を請負にすると、変更管理や追加費用を巡る問題が起きやすいです。

準委任契約は、専門家の作業やプロジェクト支援を受ける形で、要件定義、現状分析、PoC、運用設計など不確実性が高い工程に使いやすいです。発注者側も意思決定に参加し、成果物のレビューや優先順位付けを行います。要件定義を準委任、仕様確定後の開発を請負、稼働後の保守を準委任とする組み合わせは、KYCシステムのように要件が段階的に具体化する案件と相性がよいです。

SaaSやAPIを外注する場合は、サービス提供時間、月間稼働率、APIの応答時間、障害通知の期限、復旧目標、メンテナンスの告知、サポート窓口をSLAに記載します。本人確認が止まったときに、申込を保留するのか、目視確認へ切り替えるのか、後日再処理するのかも業務手順として定めてください。

法令改正や本人確認方式の変更については、委託先が情報提供だけを行うのか、仕様変更・テスト・リリースまで含むのかを確認します。改正対応を無償とする範囲、追加費用になる条件、事前通知期間、緊急対応の料金を決めておくと、公開後の予算超過を抑えられます。警察庁や金融庁の最新資料を確認する最終責任は、システム会社ではなく対象事業者側にあるため、社内の法務・コンプライアンス担当をプロジェクトに入れてください。

KYCでは本人確認書類の画像、顔画像、住所、生年月日、法人情報、取引目的などを扱うため、委託先の安全管理措置を確認します。個人情報保護委員会と金融庁の金融分野向けガイドラインは、利用目的、安全管理、従業者の監督、委託先の監督などを示しています（出典: 個人情報保護委員会・金融庁、2024年）。委託先の監査報告書やセキュリティチェックシートを受け取り、データの保管場所と海外移転の有無を確認してください。

金融機関や金融関連サービスでは、FISCの「金融機関等コンピュータシステムの安全対策基準・解説書」第13版も、アクセス制御、ログ監視、委託先管理、クラウド、可用性・復旧を点検する材料になります（出典: FISC、2025年）。すべての事業者に同じ対応が義務付けられるわけではありませんが、RFPの確認項目として、監査ログの取得、権限分離、再委託の事前承認、事故時の報告、データ返却・消去証明を入れると抜け漏れを減らせます。

KYCシステムの費用相場はいくらですか？

KYCシステムの費用は、eKYCの標準APIだけなら初期費用0〜300万円程度、法人確認・目視審査・CRM連携まで含めると300万〜1,500万円程度、AMLや金融業務向けパッケージでは1,000万〜5,000万円程度、大規模なスクラッチ開発や基幹連携では5,000万円〜3億円以上が一つの参考レンジです。公開価格、編集上の推定、個別見積を混同しないことが重要です。

公開料金の例として、GMOグローバルサインのGMO顔認証eKYCは、2026年3月時点の公式ページで初期費用なし、確認件数50件・月額22,000円からの料金体系を案内しています（出典: GMOグローバルサイン、2026年）。これは本人確認サービスの利用料の例であり、KYC業務全体の費用ではありません。自社の申込画面、API連携、顧客・法人データの紐付け、審査画面、ログ管理、脆弱性診断、運用教育は別途見積になる可能性があります。

開発費は、要件定義・業務設計、画面開発、API連携、認証・権限、データ移行、テスト、インフラ設定、監査対応、マニュアル作成に分けて確認します。ランニング費用は、月額基本料、本人確認の従量料金、法人確認やリスト照合の利用料、クラウド、保守、リスト更新、目視審査BPO、法令改正対応、問い合わせ対応を分けると、安い見積に含まれない費用を発見しやすいです。

見積比較では、初期費用だけでなく3年TCOを計算します。3年TCOは「初期費用＋36か月分の基本料・従量料＋連携改修費＋保守費＋リスト・審査運用費＋移行費」で考えると整理しやすいです。例えば初期費用が安いAPIでも、月間件数が増えると従量料金が大きくなり、逆に高額なパッケージでも大量処理や既存業務の自動化によって1件あたりの費用が下がる場合があります。

費用の変動要因は、月間件数、繁忙期のピーク、個人・法人の比率、対応書類、JPKI・ICチップ、顔認証、海外顧客、多言語、PEPs・制裁リスト、取引モニタリング、既存データの品質、オンプレミス要件、災害対策、目視審査の有無です。費用相場は案件条件で大きく変わるため、金額だけでなく、どの機能と運用が含まれるかを比較してください。

見積依頼書には、月間の新規申込件数、1日あたりの最大件数、本人確認の完了目標、目視審査へ回す割合、法人確認の件数、対象国、対応端末、必要な稼働時間を記載します。「大量」「高い可用性」のような表現では、会社ごとに前提が変わります。月間1万件なのか、繁忙日だけ1時間に1,000件なのかを明示すると、インフラと運用人員を含めた比較ができます。

さらに、初年度の導入費、2年目以降の保守費、追加の本人確認1件の単価、契約最低件数、超過単価、テスト環境、サポート、法令改正対応、解約時のデータ出力を同じ書式で回答してもらいます。費用が推定の場合は、その前提と上下に振れる要因を記載してもらうと、経営会議で説明しやすくなります。

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

委託先は知名度や価格だけでなく、自社の業務とリスクに合うかで選びます。本人確認APIの提供会社、KYC・AMLのパッケージ会社、金融システムに強いSIer、業務整理から支援する開発会社では、得意な工程が異なります。提案書に書かれた機能数より、同じ業種・同じ本人確認方式・同じ連携規模の実績を確認してください。

提案会社には、金融・決済・暗号資産・保険・証券など、自社と近い業種の導入事例を確認します。導入社数の多さだけでなく、本人確認完了率、審査時間、目視審査の運用、リスト照合、法人KYB、既存CRMや勘定系との連携をどこまで担当した事例なのかを尋ねてください。顧客名を開示できない場合でも、業種、規模、対象件数、担当範囲、稼働後の運用体制は説明できるはずです。

サービス名と法人名を混同しないことも重要です。例えば、eKYCのサービス提供会社、本人確認書類の照会先、クラウド基盤、目視審査のBPO会社が別々に存在するケースがあります。提案書に「誰が個人情報を取り扱うのか」「どの会社が障害時に対応するのか」「再委託先はどこか」を一覧で示してもらうと、契約後の責任分界が明確になります。

相見積を取るときは、全社に同じRFP、業務フロー、サンプルデータ、非機能要件、希望スケジュールを渡します。提案会社から質問があった場合は、可能な範囲で回答を共有し、前提条件の差を小さくしてください。会社ごとに異なる業務解釈で作られた見積を、合計金額だけで比べると、後から追加開発が増えてしまいます。

評価表には、業務適合性、本人確認方式、法人確認、AML・リスト照合、API・SDKの使いやすさ、既存システム連携、監査ログ、セキュリティ、SLA、導入期間、3年TCO、担当者の経験、データ移行と解約条件を設定します。価格を100点満点の大部分にせず、法令・セキュリティ・運用の不確実性を減らせる提案を評価することが、結果的なコスト削減につながります。

「初期費用だけ」「月額だけ」「AIで完全自動化」といった説明で、従量料金、目視審査、法令改正、ログ保管、障害時の代替手段、データ返却を説明しない提案には注意が必要です。本人確認に失敗した顧客を誰が救済するのか、誤判定を誰が再審査するのか、API停止時に申込を止めるのかを質問してください。

また、デモで成功例だけを見せる提案より、偽造書類、顔不一致、ライブネス失敗、IC読取失敗、重複申込、制裁リストヒット、権限逸脱、通信障害をどのように処理するかを説明できる会社を選びます。AIを使う場合も、判定の根拠、モデルのバージョン、人手介入の条件、学習データの扱いを確認し、精度の数字だけで契約を決めないことが大切です。

よくある質問

KYCシステムの発注では、費用だけでなく、対象業務、法令対応、データ管理、運用責任を同時に確認する必要があります。ここでは、外注を検討する担当者から特に多い質問へ、発注判断に使える形で回答します。

標準的な本人確認はSaaS・APIを利用し、独自性が必要な顧客管理やケース管理だけを自社開発する方法があります。対象顧客と本人確認方式を一つに絞ったPoCで効果を確認し、不要な機能を最初から作らないことも有効です。ただし、初期費用だけでなく3年TCOと障害・法令改正への対応費まで含めて比較してください。

対象業務、顧客・法人の種類、月間件数とピーク件数、対応書類、確認方式、審査・再提出の流れ、外部リスト、既存システム連携、保存する証跡、権限、稼働率、復旧目標、データ保管場所、再委託、解約時のデータ返却を書きます。特に「自社が保持するデータ」と「委託先が処理するデータ」を分けて記載すると、見積と契約の比較がしやすくなります。

外注できます。月間件数が少ない場合は、初期費用のないSaaS・APIや、開発不要で利用できる本人確認サービスから始める方法があります。GMO顔認証eKYCのように最小件数と月額を公開するサービスもありますが、顧客管理、審査、監査、個人情報の委託先管理は自社の責任として残るため、導入前に運用フローを作成してください。

顧客ID、確認方式、確認日時、判定結果、判定理由、証跡、ルールやモデルのバージョンを自社の標準データモデルで保持し、ベンダー固有のAPI項目と分離します。契約には、解約時のデータ形式、出力期間、費用、画像やログの返却・消去、移行支援の範囲を入れてください。新しい委託先へ切り替えるためのテスト環境と代替手順を、稼働前から準備しておくと安心です。

まとめ

KYCシステムの発注・外注では、最初にeKYC、KYB、CDD、AML、継続的顧客管理のどこまでを対象にするかを決めます。そのうえで、SaaS・API、パッケージ＋SI、個別開発・ハイブリッドを、独自要件、法令対応、データ主権、運用体制、3年TCOで比較します。

発注者は、現行業務、月間件数、対象書類、審査基準、連携先、ログ、SLA、障害時の代替手段、データ返却をRFPへ具体的に書きます。複数社へ同じ前提を渡し、PoCでは本人確認完了率、審査時間、再提出率、誤判定、1件コストを測ってから本開発へ進めると、見積の妥当性を判断しやすいです。

契約前には、誰が本人確認を行い、誰が最終判断し、誰が法令改正・障害・誤判定・個人情報事故へ対応するのかを明確にしてください。自社の標準データモデル、監査可能なログ、解約時のデータ返却を確保しておけば、導入後のベンダー変更や機能拡張にも対応しやすくなります。KYCを入口の画面ではなく、顧客・リスク・証跡を管理する業務基盤として発注することが、長期的な安全性と費用対効果につながります。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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