CIF（顧客情報管理）システム開発の発注/外注/依頼/委託方法について

CIF（顧客情報管理）システムの発注・外注は、顧客マスタの正本、名寄せ、勘定系やチャネルとの連携範囲を先に決め、要件整理と小規模な検証を経て段階的に委託する方法が適しています。

銀行のCIFは、単なるCRMや顧客名簿ではありません。預金・融資・外為・カード・営業店・インターネットバンキングなどに分散する情報を顧客単位でつなぎ、本人確認、顧客リスク、契約・口座との関係、変更履歴を安全に扱う基盤です。本記事では、発注形態の選び方、RFPと要件整理、契約形態、費用相場、委託先選定、見積比較、切替までの進め方を実務目線で解説します。

▼全体ガイドの記事
・CIF（顧客情報管理）システム開発の完全ガイド

CIF（顧客情報管理）システムの全体像

CIFの発注では、システム名や画面数から考え始めると、後からデータ移行と連携の難しさが明らかになり、費用と期間が膨らみやすくなります。最初に「何を顧客情報と呼ぶのか」「どのシステムを正本にするのか」「誰が更新を承認するのか」を整理することが重要です。

CIFは、顧客を一意に識別する顧客IDと、個人・法人の基本属性、代表者、実質的支配者、家族やグループ会社との関係、口座・融資・カード・担保などの契約関係を管理する中核基盤です。CRMは営業活動や接点、案件、提案履歴の管理に強く、CDPは複数チャネルの行動データを分析しやすくする基盤です。KYCやAMLの仕組みは本人確認、顧客リスク評価、制裁・反社チェックなどの業務を担いますが、必要な顧客属性や履歴をCIFから参照する関係になる場合があります。

したがって、CRM製品を導入すればCIFが不要になるとは限りません。営業部門の利用画面をCRMに置く場合でも、勘定系取引の成立に必要な顧客ID、口座関係、権限、監査証跡、更新責任は別に設計します。2025年4月から三菱UFJ銀行がSalesforceとSansanの連携を開始し、分散していた顧客データを営業活動で活用する取り組みを公表していますが、これは顧客接点・営業DXの統合事例であり、銀行CIFの正本をそのまま置き換える事例とは切り分けて捉える必要があります（出典: Sansan株式会社、2025年）。

発注者が最低限作成したいのは、顧客・組織・契約・口座・本人確認・リスク・同意・連絡先・変更履歴のデータ項目表です。個人なら氏名、旧姓、生年月日、住所、電話番号、本人確認状況を、法人なら商号、法人番号、本店・支店、代表者、実質的支配者、グループ関係を項目化します。項目名だけでなく、必須か任意か、更新部門、更新頻度、保存期間、参照できる役職、連携先を並べると、RFPの精度が上がります。

特に「顧客IDをCIFが発行するのか」「勘定系が発行した番号をCIFが保持するのか」「住所変更が窓口、アプリ、コールセンターのどこから来るのか」を曖昧にしないことが大切です。名寄せは完全自動を前提にせず、表記揺れや旧住所を使った候補提示、営業店による確認・承認、誤統合の取消し、判断理由の記録まで要件に含めます。

CIFシステムの発注・外注方法はどれが適していますか？

CIFシステムの発注形態は、パッケージ・金融向けクラウドを核にする方式、スクラッチまたはモジュール型で固有領域を作る方式、両者を組み合わせるハイブリッド方式のいずれかが基本です。結論として、既存システムやデータ品質が分からない段階で全体開発を一括発注するより、現状調査と名寄せPoCを分けて委託し、その結果で本開発の方式を決める方法が安全です。

標準機能の多いパッケージや金融機関向けクラウドを核にすると、認証、監視、バックアップ、権限管理などを一から作る範囲を抑えやすくなります。導入期間も短縮しやすく、将来の保守体制を確保しやすい点がメリットです。一方で、既存の顧客コード、独自の名寄せ基準、法人グループの持ち方、営業店の承認手順が標準と合わない場合は、追加開発や業務変更が発生します。

RFPでは、標準機能と追加開発の境界を機能一覧で示してもらいます。金融機関向けクラウドなら、データ所在地、暗号鍵の管理者、特権ID、ログの保存期間、障害時の復旧目標、再委託先、契約終了時のデータ返却・消去を確認します。NTTデータは2025年に、複数のID体系を共通IDへ統合するOpenCanvas IDaaSをみずほ銀行へ提供したと公表しています。認証・ID連携はCIF周辺の重要領域ですが、ID統合と顧客マスタの正本を同一視しない整理が必要です（出典: NTTデータ、2025年）。

スクラッチやモジュール型は、名寄せ、法人・グループ関係、主要管理店、顧客情報の閲覧理由、排他制御、勘定系との連携など、自行固有のルールを細かく反映したい場合に向いています。業務上の差別化になる顧客モデルや承認ワークフローを作り込みやすい反面、設計・テスト・保守を長期に担える人材と、仕様変更を管理する体制が欠かせません。

全機能を独自実装する必要はありません。標準認証、監視、メッセージング、バックアップ、脆弱性管理の部品は再利用し、顧客IDのライフサイクルや名寄せ判定など、業務の中核に投資する方が合理的です。RFPでは、ベンダーに「どの機能を製品で代替し、どこを開発するのか」「製品の終了やバージョンアップ時に何が影響するのか」を明示させます。

ハイブリッド方式では、CIFの正本と取引成立に直結する高信頼な連携を専用環境や既存基盤に置き、顧客接点、ID統合、営業支援、分析をクラウドへ段階的に展開します。最初から全チャネルを統合せず、法人顧客の顧客ID統合、営業店の基本情報更新、特定のWebサービス連携など、効果と範囲を説明しやすい単位から始める方法です。

段階発注の際は、各フェーズでデータモデル、API仕様、顧客IDの所有者、障害時の責任分界を共通化します。フェーズごとに別会社へ発注する場合も、インターフェース仕様書と運用設計の責任者を発注者側で決めます。小さく始めても、将来の勘定系・融資・AML連携を妨げない拡張方針をRFPに含めることが重要です。

CIFシステムの発注・外注はどのように進めますか？

CIFの外注は、企画、現状調査、要件定義、PoC、設計・開発、テスト、移行リハーサル、切替、安定化の順に進めると、意思決定の抜け漏れを抑えられます。発注者が業務判断を手放すのではなく、ベンダーに調査・設計・実装の専門性を委託し、顧客データの定義とリスク受容を自社で決めることが成功の前提です。

RFPには、背景と目的、対象業務、対象チャネル、現行システム一覧、顧客データ項目、連携方式、想定データ量、可用性、性能、権限、監査、セキュリティ、移行、教育、保守、スケジュール、提案・見積の提出形式を記載します。たとえば「名寄せを行う」だけでなく、「個人・法人を対象に、候補を自動提示し、営業店が承認または取消しでき、判定根拠を履歴として保存する」と書くと、提案の比較単位が揃います。

現行調査では、顧客コードの桁数、重複件数、住所や商号の表記揺れ、欠損率、更新頻度、連携失敗の件数をサンプルで調べます。本番の個人情報をそのまま渡すのではなく、匿名化・マスキングしたデータと、件数・桁数・分布を再現したデータを用意します。RFPの質問受付期間を設け、各社から出た質問と回答を全候補へ共有すると、提案条件の公平性も保ちやすくなります。

本開発の前に、2〜3個のデータソースを対象に名寄せPoCを実施します。個人の氏名・生年月日・住所、法人の商号・法人番号・代表者などを組み合わせ、どの条件なら自動統合し、どの条件なら確認待ちにするかを試します。精度だけでなく、誤統合した場合の影響、確認にかかる時間、取消し手順、データ更新後の再判定まで評価することが大切です。

PoCでは、窓口で住所変更を受け付ける場面、アプリで本人情報を更新する場面、融資審査で法人代表者を確認する場面、AML調査で過去の変更履歴を参照する場面など、業務シナリオを使います。画面の使いやすさだけでなく、更新競合、連携停止、権限不足、異常データの再処理を含めて確認すれば、本番移行後の事故を減らせます。PoCの成果物と判定基準を契約書に明記すると、本開発へ進む判断もしやすくなります。

設計・開発では、顧客・契約・口座の関係モデル、APIやイベントの仕様、バッチの再送、排他ロック、監査ログ、権限、障害時の補償処理を確定します。総合テストでは、正常系だけでなく、同一顧客を複数チャネルが同時更新するケース、連携先が停止するケース、名寄せを取り消すケース、権限のない担当者が閲覧するケースを用意します。

移行は、抽出、クレンジング、変換、名寄せ、ロード、件数照合、サンプル照合、業務承認の順に手順化します。少なくとも本番前に複数回の移行リハーサルを行い、所要時間、エラー件数、再実行方法、ロールバック条件を測定します。切替当日に問題が起きた場合の旧環境への戻し方と、CIF排他が残った場合の解除権限を決めておかなければ、取引停止の影響が長引く可能性があります。

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

CIFでは、要件が固まっていない調査・要件定義と、成果物や受入条件が明確な開発・移行を同じ契約類型で一括りにしないことが重要です。契約名だけで判断せず、ベンダーが負う義務、発注者の協力義務、成果物、検収、変更手続き、障害対応、知的財産、再委託、データ返却を具体的に記載します。

現行調査、データプロファイリング、名寄せルールの検証、アーキテクチャ検討は、作業を進めながら新しい事実が見つかりやすい工程です。この段階では、一定の専門人材と作業時間を確保する準委任契約が使いやすくなります。成果物を求めないという意味ではなく、調査報告書、データ項目表、課題一覧、PoC結果、次工程の見積条件を納品物とし、作業範囲とレビュー日を明確にします。

準委任では、発注者がベンダー担当者へ直接作業指示を出し続けるのではなく、双方の責任者を通じて優先順位と成果を管理します。IPAは、システム開発の契約において請負・準委任などの区分や、ユーザー企業とITベンダーの役割を整理する資料を公開しています。契約形態と現場の指揮命令が食い違わないよう、業務分担と意思決定経路を文書化しておきます（出典: IPA「情報システム・モデル取引・契約書」、2020年以降の公開資料）。

設計書、プログラム、テスト結果、移行ツール、操作手順書など、対象と受入条件を定義できる工程は請負契約を検討できます。請負にする場合は、「完成」の意味を画面の存在だけでなく、機能要件、性能、可用性、ログ、エラー処理、移行件数、既知の制約、検収方法で具体化します。未確定の仕様を残したまま請負金額を固定すると、変更要求や追加費用の交渉が増えやすくなります。

大規模CIFでは、要件定義を準委任、基本設計以降を個別の請負または準委任、移行・運用を別契約とする段階構成が現実的です。開発途中で業務要件が変わる場合は、変更要求票に影響範囲、費用、納期、テスト、セキュリティ審査への影響を記載し、承認者を一人に固定します。口頭の追加依頼をそのまま作業へ流さないことが、予算管理の基本です。

責任分界では、顧客情報の誤更新、連携遅延、二重登録、名寄せの誤統合、権限設定ミス、障害時のロック解除、バックアップからの復旧を誰が判断し、誰が実行し、何時間以内に報告するかを決めます。SLAには稼働率だけでなく、障害の重要度、一次報告、暫定復旧、原因報告、再発防止、データ整合性の確認を含めます。

また、開発会社の再委託先、海外拠点、クラウド事業者、運用監視会社まで把握し、アクセス可能なデータ、所在国、ログの保管先、監査権、事故時の連絡先を確認します。IPAは2026年4月、サプライチェーン全体の委託先を把握し、契約でサイバーセキュリティ上の役割と責任範囲を明確化するよう示しています。契約終了時のデータ返却形式、バックアップを含む消去証明、アカウント無効化、移行支援もRFPと契約の両方に記載します（出典: IPA、2026年）。

CIFシステムの費用相場とコスト内訳

CIF単体の公開価格は少ないため、以下は2026年時点の一般的なシステム開発費、金融システムの連携・移行・セキュリティ工数、リサーチノートの前提を組み合わせた税別の推定です。実際の契約額ではなく、銀行規模、顧客数、データ品質、対象チャネル、リアルタイム性、可用性、既存勘定系の仕様で大きく変わります。見積比較では、金額だけでなく、何が含まれ、何が別費用なのかを揃えて確認します。

現状調査、データプロファイリング、名寄せPoCなら、2〜3データソースを対象に500万〜1,500万円、期間は2〜4か月が一つの目安です。パッケージまたはクラウドを核にし、3〜5システムと連携するCIF周辺基盤なら、初期費用3,000万〜8,000万円、期間6〜12か月程度を仮置きします。個人・法人の名寄せ、勘定系を含む複数チャネル、移行、総合テスト、切替まで行う銀行内CIFは5,000万〜1.5億円以上、8〜18か月程度が目安です。

複数の勘定系やグループ会社をまたぐ大規模統合では、1.5億〜3億円以上、18〜30か月程度になる可能性があります。一般的なシステム開発の2026年相場でも、機能数、連携、データ移行、運用要件によって価格が大きく変わると整理されています（出典: SIA株式会社「システム開発の費用・相場【2026年版】」、2026年）。このため、CIFでは「顧客数」だけでなく、連携本数、更新頻度、名寄せの確認件数、停止できる時間、切替回数を見積条件に含めます。

費用内訳は、要件定義・データ調査が10〜15%、データクレンジング・移行が15〜25%、API・勘定系・周辺連携が25〜35%、CIFアプリ・名寄せ・画面が25〜35%、セキュリティ・性能・障害試験が10〜20%、プロジェクト管理・教育・切替が5〜15%という比率を初期検討に使えます。これは契約額を保証する比率ではなく、見積項目の抜けを探すためのチェックです。

低い見積もりでは、名寄せルールの設計、既存データのクレンジング、連携先ごとの接続試験、脆弱性診断、ペネトレーションテスト、移行リハーサル、並行稼働、休日切替、利用者教育が含まれていないことがあります。各社へ同じデータサンプルとシナリオを渡し、要件ごとに「標準」「追加開発」「対象外」「別途見積」の4区分で回答してもらうと、価格差の理由が見えやすくなります。

初期費用とは別に、クラウド利用料、ライセンス、監視、バックアップ、障害対応、問い合わせ、脆弱性対応、OS・ミドルウェア更新、ログ保管、データ品質の維持、名寄せルールの改善に費用がかかります。リサーチノートでは、クラウド基盤・監視・保守・問い合わせを合わせた月額運用費を、初期費用の年15〜25%程度で仮置きしていますが、可用性や24時間運用によって変わるため、必ず個別見積で確認します。

運用費を比較するときは、平日日中のみの監視か、24時間365日か、障害一次対応だけか、データ修正や名寄せ判断まで含むかを分けます。保守契約に「軽微な変更」が含まれる場合も、月何時間までか、対象環境はどこか、緊急対応の単価はいくらかを確認します。初期費用が安くても、毎年の運用費と契約更新時の製品費が高い場合があるため、5年程度の総保有コストで比較することが大切です。

委託先の選定と見積比較で確認すべきポイント

委託先は、知名度や見積総額だけでなく、CIFのどの層を任せられるかで選びます。金融基幹・勘定系連携に強い会社、データ移行や名寄せに強い会社、クラウド・ID統合に強い会社、CRMや顧客接点に強い会社では、得意領域が異なります。単独ですべてを担えない場合も、主契約者、製品会社、移行会社、運用会社の責任分界を説明できる体制なら候補になります。

実績確認では、「金融機関向けの実績があります」という説明だけで終わらせません。個人・法人の顧客数、対象チャネル、勘定系やAMLとの連携本数、名寄せの方法、移行回数、稼働後の障害件数、現在の保守体制、主担当者の経験を、開示可能な範囲で質問します。大規模案件の実績があっても、今回の会社が担当したのが画面開発だけなら、CIF全体の責任者として評価するのは適切ではありません。

RFPでは、匿名化した事例資料、体制図、再委託先一覧、過去の移行計画、障害時の連絡網、サンプルのテスト計画を提出してもらいます。提案会では、発注者が「顧客IDの正本はどこですか」「名寄せを誤ったとき誰が戻しますか」「勘定系の応答が止まったとき取引をどう扱いますか」と質問し、答えの具体性を見ます。抽象的な「柔軟に対応します」ではなく、判断基準、担当部署、期限、追加費用の扱いまで示せる会社が望まれます。

見積書は、工程別の人月、単価、期間、担当人数、外部ライセンス、クラウド、移行、試験、教育、旅費、保守、税区分を分けて確認します。さらに、見積の前提データ量、API本数、画面数、稼働時間、性能目標、RTO・RPO、利用者数、環境数を並べます。同じ1億円でも、A社が移行と休日切替を含み、B社が要件定義と開発だけを含むなら、単純比較はできません。

比較表を作る場合は、要件ごとに「対応方法」「標準か追加か」「金額」「納期」「発注者の作業」「リスク」「未確定事項」を列にします。価格の安さだけでなく、未確定事項が少ないか、リスクに対する対策と予備費があるか、データ品質を見たうえで見積もっているかを評価します。見積精度を上げるために、最終候補には有償の要件定義またはPoCを依頼し、その成果を本開発見積に反映させる方法もあります。

金融分野のCIFでは、機能要件と同じタイミングでセキュリティ要件を定義します。最小権限、多要素認証、職務分掌、特権ID、暗号化、操作・変更ログ、閲覧理由、脆弱性管理、バックアップ、災害対策、インシデント対応、委託先監査、データ削除と証跡をRFPに入れます。金融分野における個人情報保護に関するガイドラインは、組織的・人的・物理的・技術的な安全管理措置と、外国で個人データを扱う場合の外的環境の把握を示しています（出典: 個人情報保護委員会・金融庁、2024年版）。

FISCの安全対策基準・解説書第13版は、経済安全保障、オペレーショナル・レジリエンス、金融分野のサイバーセキュリティガイドライン、AI・生成AIの安全対策、システム障害事例などを反映しています。CIFの提案では「FISC対応済み」という一言で済ませず、対象基準、実装箇所、証跡、発注者が行う審査、運用開始後の点検を対応表にします（出典: FISC「安全対策基準・解説書第13版」、2025年）。

AML・CFTの観点では、金融庁が顧客管理をリスク低減措置の中核として位置づけ、取引開始時だけでなく取引期間中も顧客リスクに応じた定期的な実態把握と評価見直しを求めています。そのため、顧客リスク評価の結果、確認日、確認者、判断理由、次回確認時期を、CIFまたは連携するAML基盤から追跡できる設計にします（出典: 金融庁「金融機関におけるマネロン・テロ資金供与・拡散金融対策について」、2026年確認）。

よくある質問（FAQ）

CIFの発注では、費用、開発期間、CRMとの違い、契約方法、既存データの扱いについて質問が多くなります。ここでは、発注前に判断しやすいように、結論から回答します。

現状調査・名寄せPoCなら500万〜1,500万円、パッケージやクラウドを核にした周辺基盤なら3,000万〜8,000万円、複数チャネルと勘定系を連携する銀行内CIFなら5,000万〜1.5億円以上が推定目安です。公開価格ではなく、対象範囲とデータ品質で変わるため、連携、移行、セキュリティ試験、切替、保守を含むかを確認してください。

不要になるとは限りません。CRMは営業・接点・案件管理、CIFは顧客ID、契約・口座関係、本人確認、顧客リスク、更新履歴など、取引の正確性と統合管理を担うため、役割が異なります。CRMを顧客接点の画面として利用する場合でも、CIFの正本と更新責任、連携頻度、誤更新時の訂正方法を設計してください。

現行調査、要件定義、データ分析、PoCなど条件が変わりやすい工程は準委任、仕様と受入条件が確定した開発・成果物は請負を検討します。実際には工程ごとに契約を分け、成果物、発注者の協力義務、変更管理、検収、障害対応を明記する方法が適しています。契約名と現場の指揮命令が一致しているかも確認してください。

候補の洗い出しは4〜6社程度から始め、RFPを渡す提案依頼先は、体制と対象範囲を確認したうえで3社前後に絞ると比較しやすくなります。社数に絶対的な正解はありませんが、同じデータサンプル、同じ業務シナリオ、同じ費用内訳で提案してもらうことが重要です。金融基幹、名寄せ・移行、クラウド・ID、CRMなど、自行の課題に合う得意領域を持つ会社を組み合わせてください。

まとめ

CIF（顧客情報管理）システムの発注・外注では、最初に顧客の定義、顧客IDの正本、名寄せと訂正のルール、連携先、権限、監査、移行方針を決めます。CRM、CDP、KYC・AML、勘定系との役割を分け、必要な範囲をRFPへ落とし込むことが、過大発注と追加費用を防ぐ出発点です。

発注前は、第一に顧客・契約・口座・本人確認・リスク情報の対象範囲、第二にCIFと周辺システムの正本と更新責任、第三に名寄せ精度と人手確認の手順、第四にRFPの成果物・受入条件・セキュリティ要件、第五に費用の内訳・運用費・切替と障害時の責任分界を確認します。5項目が文書になっていれば、提案会社との会話が製品名中心にならず、業務成果とリスク中心になります。

全社統合の要件が固まっていない場合は、いきなり数億円規模の開発を発注せず、500万〜1,500万円程度の現状調査・名寄せPoCを別工程として委託する方法が現実的です。匿名化データで重複と欠損を調べ、業務シナリオで更新・承認・連携・障害復旧を確認し、その結果をパッケージ、クラウド、スクラッチ、ハイブリッドの選択と本開発見積へ反映します。

最も安い会社を選ぶのではなく、データの不確実性と運用開始後の責任まで説明できる委託先を選ぶことが、CIFの発注を成功させる近道です。発注者側に業務責任者とデータ責任者を置き、ベンダーと一緒に正本・名寄せ・移行・切替の判断を積み重ねてください。

▼全体ガイドの記事
・CIF（顧客情報管理）システム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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