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

CIFシステムの発注は、顧客IDの正本を決め、要件を整理し、名寄せPoCで確かめてから本開発に入る順で行います。この順に進めると、段階的な委託と安全な移行につながります。

CIFシステムの全体像は、完全ガイドでも詳しく扱っています。

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

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

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

銀行のCIFは、顧客情報を顧客単位でつなぐ中核基盤です。本人確認や顧客リスク、契約・口座の関係、変更履歴を安全に扱います。預金、融資、外為、カード、営業店、インターネットバンキングには、顧客情報が分散しがちです。

画面数だけを基準に発注を考えると、後から移行や連携の難しさが判明します。その結果、費用と期間が膨らみやすくなります。

CIFとCRM・CDP・KYC基盤の違い

CIFは、顧客IDと個人・法人の属性、代表者、実質的支配者を管理します。家族やグループ会社の関係、口座・融資・カード・担保などの契約関係も扱います。

• CRM：営業活動、接点、案件、提案履歴の管理。
• CDP：複数チャネルの行動データを、分析しやすい状態にまとめます。
• KYC・AML：本人確認、顧客リスク評価、制裁・反社チェックを担います。

KYC・AML基盤は、必要な顧客属性や履歴をCIFから参照することがあります。ただし、CRMを導入してもCIFが不要になるとは限りません。

CRMを営業画面に使う場合でも、顧客ID、口座関係、権限、監査証跡、更新責任は、CRMとは別に設計します。

2025年4月、三菱UFJ銀行はSalesforceとSansanの連携を開始しました。公表された取り組みは、分散した顧客データを営業活動に活用する顧客接点・営業DXの事例です。銀行CIFの正本を置き換える事例とは、分けて捉える必要があります（出典：Sansan株式会社、2025年）。

発注前に決めるべき顧客データと正本

RFPの精度を上げるため、顧客データの項目と、ID・更新・名寄せの扱いを分けて整理します。

• 項目表：顧客・組織・契約・口座から、本人確認・リスク・同意・連絡先・変更履歴までを含めます。
• 個人・法人の属性：氏名や旧姓、生年月日、住所、電話番号、本人確認の状況を記載します。
• 法人情報：商号や法人番号、本店・支店、代表者、実質的支配者、グループ関係を項目化します。
• 更新と名寄せ：必須か任意か、更新部門と頻度、保存期間、閲覧できる役職、連携先を決めておきます。

顧客IDをCIFが発行するのか、勘定系の番号をCIFが保持するのかは、先に決めておきます。ここが決まらないと、連携先ごとに番号の扱いが食い違うおそれがあります。住所変更は、窓口、アプリ、コールセンターのどこで受け付けるかも特定しておきます。

名寄せは完全な自動処理を前提にせず、表記揺れや旧住所の違いで候補を示したうえで、営業店が確認・承認できるようにします。さらに、誤って統合した場合に備えて、取消しと判断理由の記録も要件に含めます。

CIFシステムの発注・外注方法の選び方

発注形態の基本は、パッケージ・金融向けクラウド、スクラッチ・モジュール型、そして両者を組み合わせるハイブリッド方式です。各方式が合うかどうかは、標準機能と自行固有のルールとの差で判断します。

既存システムやデータの品質が分からない場合は、調査と名寄せPoCを分けて委託します。そのうえで、調査と名寄せPoCの結果をもとに本開発の方式を決めると、一括で発注するより安全に進められます。

パッケージ・クラウドを核にした発注

製品・クラウド方式が自行に合うかは、標準機能の範囲、標準との差、クラウド特有の運用条件の三つで判断します。

• 標準機能：認証、監視、バックアップ、権限管理について、一から作る範囲を抑えられるかどうか。
• 標準との差：顧客コード、名寄せ、法人関係、営業店の承認手順と照らし合わせて、差を洗い出します。
• クラウド条件：データ所在地、鍵管理者、特権ID、ログ期間、復旧目標、再委託先の扱い。

標準機能と自行の業務が合わないと、追加開発か業務の変更が必要になります。そのため、RFPの機能一覧で標準機能との境界を示してもらいます。

一方で、導入期間の短縮や将来の保守体制の確保も期待できます。また、契約終了時のデータ返却と消去も条件に含めます。

NTTデータは2025年、複数のID体系を共通IDへ統合するOpenCanvas IDaaSを、みずほ銀行へ提供したと公表しました。これはCIF周辺の認証・ID連携の事例にあたります。ただし、ID統合と顧客マスタの正本は同じものとして扱いません（出典：NTTデータ、2025年）。

スクラッチ・モジュール型による固有領域の構築

自行固有の名寄せや法人・グループ関係、主要管理店を細かく反映させたい場合に選ばれます。閲覧理由、排他制御、勘定系連携も、細かく反映できます。独自の顧客モデルや承認手順も作り込めます。

一方で、設計・テスト・保守を長期に担う人材と、仕様変更を管理する体制が必要になります。全機能を独自に作らず、標準の認証や監視、メッセージングは既存の仕組みを再利用します。バックアップと脆弱性管理も、再利用の対象にします。

顧客IDのライフサイクルや名寄せ判定といった業務の中核に、投資を集中させます。RFPでは、製品で代替する機能と開発範囲、製品の終了や更新時の影響を明示させます。

ハイブリッド方式による段階的な外注

ハイブリッド方式では、取引の信頼性と段階的な導入のしやすさを両立させるために、配置と発注範囲を分けます。

• 配置：CIFの正本と高信頼な連携は専用環境や既存基盤に置き、接点、ID統合、営業支援、分析はクラウドに展開します。
• 開始範囲：全チャネルを一度に統合せず、法人ID統合や営業店の情報更新、特定Web連携などから始めます。
• 共通設計：各フェーズのデータモデルやAPI、顧客IDの所有者、障害時の責任分界をそろえておきます。

効果と範囲を説明しやすい単位で区切ります。別の会社に委託する場合は、発注者側で仕様書と運用設計の責任者を決めておきます。

さらに、将来の勘定系・融資・AML連携を妨げない拡張方針も、RFPに含めます。

CIFシステムの発注・外注の進め方

外注は企画から安定化まで、順を追って進めます。まず現状を調べ、要件定義とPoCで実現性を確かめてから、設計・開発に入ります。

そのあとテストと移行リハーサルを行い、切替と安定化に進みます。段階を踏むことで、意思決定の抜け漏れを抑えられます。

調査・設計・実装はベンダーへ委託できます。一方で、顧客データの定義と、どのリスクを受け入れるかは発注者が決めます。

RFPと要件整理に向けた発注者の準備

提案条件をそろえるため、RFPの記載事項と、現行の調査やデータの準備を整理します。

• RFPの範囲：業務やチャネル、システム、データ、連携、非機能要件、移行、教育、保守を記載します。
• 名寄せ要件：候補の提示から、営業店の承認と取消し、判定根拠の保存までを定めます。
• 現行データ：顧客コードや重複、表記揺れ、欠損、更新頻度、連携の失敗を調べます。

RFPには、背景・目的、可用性、性能を明記します。権限と監査、セキュリティの要件も書きます。加えて、スケジュールと提案・見積の提出形式も記載します。

顧客コードの桁数や調査値は、サンプルで確認します。本番の個人情報は渡さず、匿名化・マスキングしたデータで件数、桁数、分布を再現します。

質問と回答を全候補に共有すれば、提案条件の公平さが保たれます。

名寄せPoCと業務シナリオによる実現性の確認

本開発の前に行うPoCでは、名寄せの判定条件と本番業務での扱いを確かめます。

• データ：2〜3個のソースと、個人・法人の属性の組み合わせ。
• 判定：自動統合と確認待ちの条件を決め、精度と誤統合の影響を評価します。
• 業務場面：住所変更や本人情報の更新、代表者確認、AML履歴の参照を試します。
• 例外処理：更新競合、連携停止、権限不足、異常データの再処理を確認します。

PoCで使うデータには、匿名化・マスキングした氏名、生年月日、住所の項目を使います。法人については、商号、法人番号、代表者を使います。

確認にかかる時間、取消しの手順、更新後の再判定も評価します。また、成果物と判定基準を契約書に明記しておけば、本開発へ進むかどうかを判断する材料がそろいます。

設計・テスト・移行リハーサルの管理

本番切替に備えて、設計、異常系テスト、移行リハーサルの管理項目を分けて確認します。

1. 設計：関係モデルやAPI・イベント、バッチ再送、排他ロック、監査ログ、権限、障害時の補償処理を確定します。
2. 総合テスト：同時更新、連携先の停止、名寄せの取消し、権限外の閲覧を試します。
3. 移行：抽出、クレンジング、変換、名寄せ、ロード、照合、業務承認の順に進めます。
4. リハーサル：本番前に複数回行い、所要時間、エラー、再実行、ロールバックの条件を測ります。

件数とサンプルを照合し、旧環境へ戻す方法と、CIFの排他が残った場合に解除する権限を決めておきます。

切替時の問題や排他の解除が遅れると、取引停止の影響が長引くおそれがあります。

CIFシステムの契約形態と責任分界

要件が未確定の調査と、成果物や受入条件が明確な開発・移行は、同じ契約類型にまとめません。契約書には、義務、協力事項、成果物を記載します。あわせて、検収と変更の扱い、障害対応、知的財産を決めておきます。

再委託やデータの返却についても、具体的に定めます。契約の名称だけで判断するのではなく、実際の役割と責任分界を明確にします。

準委任契約が向く調査・要件定義・PoC

新しい事実が見つかりやすい調査や分析、検証では、作業範囲と成果の管理方法を定めます。

• 対象工程：現行調査、データ分析、名寄せルールの検証、構成の検討を扱います。
• 契約と成果物：専門人材と作業時間を確保したうえで、報告書や項目表、課題一覧、PoC結果、次工程の見積条件を定めます。
• 進行管理：作業範囲とレビュー日を明確にし、双方の責任者を通じて優先順位と成果を管理します。

IPAは、請負と準委任の区分や役割を整理した資料を公開しています。現場の指揮命令と契約形態を一致させ、業務分担と意思決定の経路を文書にしておきます（出典：IPA「情報システム・モデル取引・契約書」、2020年以降の公開資料）。

請負契約が向く開発・成果物・移行作業

請負を検討する工程では、対象の成果物と受入条件、変更時の手続きを先に定めておきます。

• 対象成果物：設計書、プログラム、テスト結果、移行ツール、操作手順書を定めます。
• 受入条件：機能や性能、可用性、ログ、エラー処理、移行件数、既知の制約、検収方法を具体的に示します。
• 変更管理：変更要求票に、範囲、費用、納期、テスト、セキュリティ審査への影響を記載します。

仕様が未確定のまま固定金額で契約すると、変更や追加費用をめぐる交渉が増えやすくなります。一方で、大規模なCIFでは要件定義を準委任とし、基本設計以降や移行・運用は個別に契約する方法もあります。

変更要求の承認者は一人に決めておきます。口頭での追加依頼をそのまま作業に流さないことが、予算管理の基本です。

障害・再委託・契約終了時の責任の明記

障害対応、委託先の管理、契約終了時の処理は、どこまでを発注者と委託先のどちらが負うのかを、契約書で具体的に書いておきます。

• 障害対応：誤更新、連携遅延、二重登録、誤統合、権限ミス、ロック解除、復旧について、判断者と実行者を決めます。
• SLA：重要度、一次報告、暫定復旧、原因報告、再発防止、データ整合性を定めます。
• 委託先：再委託先や海外拠点、クラウド・監視会社のデータの所在国、ログ、監査権、事故連絡先を確認します。
• 契約終了：返却の形式、消去の証明、アカウントの無効化、移行支援を記載します。

誤更新などが起きた際の報告期限も定めておきます。あわせて、IPAは2026年4月、委託先を把握し、契約でサイバーセキュリティ上の役割と責任を明確にするよう示しています（出典：IPA、2026年）。

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

CIFの公開価格は少ないため、ここに示す金額は、2026年時点の開発費や連携・移行・セキュリティの工数、リサーチノートをもとにした税別の推定です。実際の契約額ではありません。

費用は、銀行の規模や顧客数、データ品質によって変わります。チャネルの数やリアルタイム性、可用性、勘定系の仕様も影響します。見積では、含む範囲と別費用をそろえて確認します。

スコープ別の初期費用と開発期間の目安

初期費用と期間は、対象範囲ごとの推定目安として次のとおり比較します。

• 調査・PoC：2〜3ソース、500万〜1,500万円、2〜4か月。
• 周辺基盤：3〜5システム連携、3,000万〜8,000万円、6〜12か月程度。
• 銀行内CIF：複数チャネル・勘定系連携・移行を含み、5,000万〜1.5億円以上、8〜18か月程度。
• 大規模統合：複数勘定系・グループ会社をまたぎ、1.5億〜3億円以上、18〜30か月程度。

銀行内CIFの範囲には、総合テストと切替も含みます。一般的な開発費も、機能数などによって変わります（出典：SIA株式会社「システム開発の費用・相場【2026年版】」、2026年）。

見積条件には顧客数のほか、連携本数や更新頻度を含めます。さらに、名寄せの確認件数、停止できる時間、切替回数も条件に入れます。

名寄せ・連携・セキュリティによる費用の押し上げ

初期費用の配分は、見積項目の漏れを探すための目安として使えます。

• 要件定義・データ調査：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全体の責任者としての評価材料にするのは適切ではありません。判断基準、担当部署、期限、追加費用まで、答えられるかを確かめます。

見積比較における前提・成果物・除外範囲の統一

見積を比べる前に、各社の金額の前提、作業範囲、評価方法をそろえます。

• 費目：人月、単価、期間、人数、ライセンス、クラウド、移行、試験、教育、旅費、保守、税区分を確認します。
• 前提：データ量、API・画面数、稼働時間、性能、RTO・RPO、利用者数、環境数をそろえます。
• 比較表：要件ごとに、対応、標準か追加か、金額、納期、発注者の作業、リスク、未確定事項を記録します。

同じ1億円でも、移行や休日切替を含む提案と、要件定義と開発だけの提案は単純に比べられません。

未確定事項の少なさ、対策と予備費、データ品質も評価します。最終候補には、有償の要件定義やPoCを依頼して、その結果を本開発の見積に反映する方法もあります。

提案に組み込む金融機関のセキュリティと委託先管理

機能と同時に、個人情報保護、金融分野の安全基準、AML・CFTに関する要件を、RFPに反映します。

• 安全管理：最小権限、多要素認証、職務分掌、特権ID、暗号化、ログ、閲覧理由、脆弱性管理を定めます。
• 運用・委託先：バックアップ、災害・事故対応、監査、データ削除と証跡を含めます。
• FISC：対象基準、実装箇所、証跡、発注者審査、運用後の点検を対応表にします。
• AML・CFT：顧客リスク評価と確認記録をCIFまたはAML基盤で追跡します。

金融分野における個人情報保護に関するガイドラインは、組織的、人的、物理的、技術的な安全管理措置を示しています。また、外国で個人データを扱う場合は、外的環境の把握も求めています（出典：個人情報保護委員会・金融庁、2024年版）。

FISCの安全対策基準・解説書第13版は、経済安全保障、オペレーショナル・レジリエンス、金融分野のサイバーセキュリティガイドラインを反映しています。AI・生成AIの安全対策やシステム障害の事例も含まれます。そのため、「FISC対応済み」の一言で済ませず、対応状況を確かめます（出典：FISC「安全対策基準・解説書第13版」、2025年）。

金融庁は、顧客管理をリスク低減措置の中核と位置づけています。取引開始時だけでなく、取引期間中も顧客リスクに応じた定期的な実態把握と評価の見直しを求めています（出典：金融庁「金融機関におけるマネロン・テロ資金供与・拡散金融対策について」、2026年確認）。記録には、確認日と確認者を含め、判断理由と次回の確認時期も残します。

よくある質問（FAQ）

CIFの発注では、費用、開発期間、CRM、契約、既存データについて質問が寄せられます。発注前に判断しやすいよう、順に回答します。

CIFシステムの開発費用はどのくらいかかりますか？

調査・名寄せPoCは500万〜1,500万円、パッケージ・クラウド型の周辺基盤は3,000万〜8,000万円が推定の目安です。銀行内CIFは5,000万〜1.5億円以上です。

公開価格ではなく、範囲とデータ品質によって変わります。連携、移行、セキュリティ試験、切替、保守を含むかどうか、確認してください。

CRMを導入すればCIFシステムは不要になりますか？

不要とは限りません。CRMは営業・接点・案件の管理が中心で、CIFは顧客ID、契約・口座、本人確認、顧客リスク、更新履歴を扱います。

CRMを顧客接点の画面に使う場合でも、CIFの正本、更新責任、連携の頻度、誤更新の訂正方法を設計します。

契約は請負と準委任のどちらを選べばよいですか？

現行調査、要件定義、分析、PoCは準委任、仕様と受入条件が確定した開発は請負を検討します。そのため、工程ごとに分ける方法が適しています。

成果物と協力義務、変更管理は明記します。検収と障害対応も、契約で定めておきます。契約名と現場の指揮命令が一致しているかどうかも、確認してください。

CIFシステムの委託先は何社くらい比較すべきですか？

候補は4〜6社程度から洗い出し、体制と範囲を確認したうえで、提案依頼先を3社前後に絞ると比較しやすくなります。社数に絶対の正解はありません。

同じデータ、シナリオ、費用内訳で提案を受けます。そのうえで、金融基幹、名寄せ・移行、クラウド・ID、CRMなど、自行の課題に合う会社を組み合わせます。

まとめ

発注前に、顧客の定義と顧客IDの正本、名寄せ・訂正、連携先を決めます。権限、監査、移行方針も定めます。そのうえで、CRM、CDP、KYC・AML、勘定系との役割を分けてRFPにします。

発注前に確認する5つの要点

発注の判断では、対象範囲、データ管理、要件、費用と切替を、項目ごとに確認します。

• 対象範囲：顧客、契約、口座、本人確認、リスク情報のどこまでを含めるかを決めます。
• 正本と責任：周辺システムとの間で、正本と更新責任を定めます。
• 名寄せ：精度と、人による確認の手順。
• RFP：成果物や受入条件、セキュリティ要件を記載します。
• 費用と切替：運用費と障害時の責任分界まで確認します。

この5項目を文書にまとめておけば、提案会社との打ち合わせを、製品名中心から業務成果とリスク中心へ移せます。

現状調査と名寄せPoCから始める進め方

要件が固まらないときは、全社開発の前に小さく検証し、その結果を発注の判断材料にします。

1. 現状調査・PoC：500万〜1,500万円程度で別工程にし、匿名化データの重複と欠損を調べます。
2. 業務検証：更新、承認、連携、障害復旧の場面を、シナリオで確かめます。
3. 方式と見積：結果を、パッケージ、クラウド、スクラッチ、ハイブリッドの選択と本開発の見積に反映します。

最も安い会社ではなく、データの不確実性と運用後の責任を説明できる委託先を選びます。また、発注者は業務責任者とデータ責任者を置いておきます。

ベンダーとのやり取りを通じて、正本、名寄せ、移行、切替の判断を積み重ねてください。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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