つながっただけで、基幹データをAIに上書きさせるな

顧客管理の試作AIを基幹システムへつなぐと、住所変更の候補を見つけ、画面へ反映できた。連携試験は成功し、「次は夜間に自動更新しよう」という話が出る。しかし、接続できたことと、顧客や商品の正しい記録を確定できることは別です。

たとえば「株式会社青山 東京支店」と「青山株式会社 本社」は同じ取引先なのか。移転した住所と、請求書だけを送る住所のどちらを直すのか。統合前の顧客IDに残る未回収金はどう引き継ぐのか。文字列の近さだけでは決められません。正本、IDの対応、更新権限、例外処理が決まるまで、基幹データへの直接上書きは認めない判断が必要です。

接続試験の成功は、会社の正本をAIが自動で確定してよい根拠にはなりません。

いま止めるのは、基幹データへの自動確定です

まず停止対象を曖昧にしません。顧客・商品・契約・請求先など、基幹システムが正本として扱うデータについて、AIの候補から人の承認を通さずに行う更新、削除、統合、状態変更を止めます。夜間バッチ、APIによる書込み、表の一括取込み、画面操作の自動化も対象です。

候補を作ることや差異を見つけることまで止める必要はありません。連携を次の四段階に分けます。

1. 正本を読む
2. 更新候補と根拠を表示する
3. 権限を持つ担当者が承認する
4. 承認済みの内容だけを書き込み、結果を照合する

確認中は二段階までに制限します。AIが自分の候補を承認し、そのまま書き込めるなら、その権限または接続を外します。承認と実行が一つの画面にあるかより、誰がどの変更を承認し、その内容だけが実行されるかが重要です。「注意して使う」という周知だけでは、無人処理や誤操作を止められません。

項目ごとに、正本と更新責任を決める

正本は、システム全体に一つとは限りません。顧客名は契約管理、配送先は受注管理、請求先は会計、担当者の連絡先は営業管理が基準かもしれません。「顧客情報は基幹が正しい」という大きな言い方では、項目が衝突したときに決められません。

更新対象ごとに、少なくとも次を一枚にします。

MicrosoftのMaster data management in Microsoft Purview は、複数のデータ源から重複を除いた標準的なマスターレコードを作り、権威あるデータとして扱う考え方を説明しています。これは製品とMDMの概念を説明する資料であり、自社の正本やAIの更新可否を決めてくれるものではありません。どの項目を誰が確定するかは、実際の業務と責任から決めます。

「どのシステムが正しいか」ではなく、「この項目を、どの根拠で、誰が確定するか」まで分けます。

ID照合は、一致・保留・別物に分ける

データ連携で難しいのは、値の修正より「同じ相手か」の判断です。同じ電話番号を複数拠点が使う、会社名が変わる、支店が統合される、一つの商品が容量別に分かれる、旧コードが別商品へ再利用される、といった例外があります。氏名、住所、電話番号の一部が一致しても、同じIDとは限りません。

照合結果を自動的な「一致」だけにせず、三つに分けます。

• 一致：会社が定めた識別子と条件がそろい、同一と確定できる
• 保留：候補はあるが、根拠不足または業務上の例外がある
• 別物：似ていても異なる顧客・商品として維持する

保留には、判断する部署、追加で見る資料、期限を付けます。AIの確信度が高いという表示は参考情報にはなりますが、会社が定めた一致条件の代わりにはなりません。とくに顧客の統合、契約状態の終了、商品コードの置換のように後続処理へ広く届く変更は、確信度にかかわらず人の承認対象にします。

上書き前後を追えなければ、訂正できない

一件の更新記録には、候補、元データ、対応したID、変更前後の値、提案時刻、承認者、実行者、反映結果を残します。個人名だけでなく、どの業務権限で承認したかも必要です。大量更新では、対象件数、除外件数、失敗件数と、再実行した範囲をまとめます。

承認を待つ間に、別の担当者が正本を直す場合もあります。書込み直前に、承認時の旧値と現在の値が一致するかを確認し、変わっていたら差分を見直します。古い候補を実行して、後から確定した正しい変更を消さないためです。

戻す対象も基幹システム一つではありません。住所を誤更新した後に請求書を発行していれば、旧値を戻すだけでは訂正が終わりません。帳票、配送、会計連携、分析用データ、顧客への連絡まで、変更後の値を受け取った先を確認します。切戻し試験では、通常の一件に加えて、統合、分割、取消しなどの例外を使います。

切戻しとは旧値を復元する操作だけでなく、その値を使った後続業務まで見つけて訂正することです。

再開は、書き込む項目ごとに判定する

直接書込みの再開を「連携が安定した」「テストでエラーがなかった」で決めません。次の条件がすべてそろった項目と処理だけを再開候補にします。

1. 項目の意味と正本が定まり、正本側の責任者が確認した
2. IDの一致条件、保留条件、別物とする条件を、利用許可を得た実務に近いデータで試した
3. 提案、承認、実行の権限が分離され、無人の確定経路が閉じている
4. 統合・分割・名称変更などの例外を扱う担当と期限がある
5. 変更前後、根拠、承認、実行結果を追跡できる
6. 後続処理を含む切戻しと再照合を実際に完了できた

一つでも未確認なら、その項目は候補表示と承認待ちにとどめます。顧客住所の一部を再開できても、顧客統合や契約終了を同時に解放する必要はありません。再開後も、一定件数までは全件確認し、不一致率、保留率、訂正件数が決めた範囲を超えたら書込み権限を再び止めます。

正本・照合・履歴・切戻しを整え、小さな範囲から書き戻しを再開する

AIは複数の記録を比べ、更新候補を見つける助けになります。しかし、誰と誰が同じ顧客か、どの住所を請求に使うか、どの契約を終了するかは、会社の業務判断です。

接続を急いで外すのではなく、まず書込み権限を止めます。そのうえで、項目ごとの正本と責任、ID照合、例外、履歴、切戻しを整えます。再開の単位を小さくすれば、便利な候補作成を生かしながら、会社の正本を未確認の判断で変えない運用にできます。

参考資料

• Microsoft「Master data management in Microsoft Purview」