🧭 基本の流れ
- NTT共同GWに1700バイトデータが届く
└ 保険会社共通のフォーマット - システムにアップロード
└ 自動判定で「新規顧客作成」または「既存顧客情報の更新」 - 顧客情報＞契約情報＞1700バイト履歴で内容確認可能
🔍 マッチング条件（既存顧客との照合）
| 条件 | 内容 |
| 第一条件 | カナ名が一致していること |
| 第二条件 | 住所・電話番号・生年月日のいずれか1つが一致していること |
💡 両方の条件を満たす必要あり！
⚠️ マッチングされない例
- 住所の表記揺れ
例：元データ「1-3-6」 vs GWデータ「1丁目3番地6」 → ❌一致しない - 法人名の追加情報
例：元データ「ｶﾌﾞｼｷｶﾞｲｼｬ ﾃｽﾄ」 vs GWデータ「ｶﾌﾞｼｷｶﾞｲｼｬ ﾃｽﾄ ﾀﾞｲﾋｮｳﾄﾘｼﾏﾘﾔｸ ﾀﾛｳ」 → ❌一致しない
🏠 顧客情報の更新ルール
- 顧客が複数契約を持っている場合でも、直近の契約情報の変更が優先される
- 例：損保契約で住所変更 → 生保契約が未変更でも、顧客情報の住所は損保の内容で上書きされる
👤 担当者1の更新ルール
- 契約情報に含まれる募集人コードを元に、募集人アカウント（漢字名）と紐づけ
- 顧客情報の「担当者1」に表示される
- 直近の契約情報に含まれる募集人IDが優先される
💡 つまり、生保と損保で担当者が異なる場合でも、最後に計上された契約の担当者が表示される
🧩 よくある質問（FAQ）
Q. 同姓同名の顧客がいる場合、どうなる？
A. カナ名だけでなく、住所・電話番号・生年月日のいずれかが一致していないとマッチングされません。
Q. 住所が微妙に違うだけなのにマッチングされない…
A. 表記揺れ（例：丁目・番地の違い）はNGです。事前に表記統一のルールを確認しましょう。
Q. 担当者1が意図しない人になっている…
A. 直近の契約情報に含まれる募集人IDが優先されるため、複数担当者がいる場合は注意が必要です。
Q. どこで入ってきた情報を確認できる？
A. 顧客情報＞契約情報＞1700バイト履歴で、どの契約にどんな情報が入ってきたか確認できます。
🧠 補足：この仕組みの意図
- 自動化による業務効率化
→ 手入力の手間を減らす - 直近情報の優先
→ 最新の契約内容を反映させることで、顧客情報の鮮度を保つ - マッチング精度の確保
→ 誤更新を防ぐため、厳密な照合条件を設定