PoC開発サービス
同じ商品らしい行が複数あり、検索や集計のたびに担当者が確認している。商品名の表記が仕入先ごとに違い、どれを残せばよいか決められない。こうした商品マスターの整備では、AIで統合候補を探すPoCを検討できます。
最初に試すのは、似た行を見つけ、同じ点と異なる点を担当者へ示す工程です。似ているという理由だけで品番を削除したり、在庫や受注の参照先を変更したりしない形から始めます。
何を同じ商品として扱うか決める
商品名が似ていても、容量、材質、色、販売単位などが違えば、別の商品として管理する必要があります。メーカーや仕入先が同じというだけでも、統合の根拠にはなりません。
まず、自社で商品を区別している項目を並べます。メーカー型番などの識別情報、規格、販売単位について、どの組み合わせなら同じ商品と判断できるかを担当者が決めます。情報が足りない行は、候補から消すのではなく「判断保留」として残します。
重複行を統合する作業と、代替品や似た商品を探す作業も分けます。代わりに使える商品であっても、同じ商品コードにまとめてよいとは判断できません。
表記をそろえる処理とAIの判定を分ける
空白や表記の違いを一定のルールで整えられるなら、その処理を先に試します。ただし、型番の記号や文字の一部を消すと別商品になることもあるため、元の値を残し、比較用の列を別に作ります。
MicrosoftのPower Query公式資料でも、文字列の類似度や変換表を使う照合の仕組みが説明されています。こうした既存の照合方法で候補を十分に絞れるなら、すべてをAIへ任せる必要はありません。
AIを使う場合は、名称に埋め込まれた規格の読み取りや、表記が離れた候補の提示など、単純な照合では確認が残る部分を対象にします。AIが付けたスコアだけで同一商品と確定せず、判断に使った項目と根拠を表示します。
元の商品IDと判断資料を用意する
統合候補から元の行へ戻れるように、商品IDと取得元を残します。検証用のデータは本番から切り離し、書き戻さずに結果を確認できるようにします。
| 用意する情報 | 確認する内容 |
|---|---|
| 商品IDと名称 | 元の行を特定できるか、別名があるか |
| メーカー・型番・規格 | 同一商品と判断する項目がそろうか |
| 販売単位や数量 | 単品、箱、セットなどを区別できるか |
| 登録元と更新日 | 情報の出所と古さを確認できるか |
| 過去の統合判断 | 統合した例と、似ていても分けた例があるか |
価格や取引条件など、判定に不要な情報は対象から外します。資料に書かれた規格とマスターの値が違う場合、AIに都合のよい方を選ばせず、確認する担当者と優先する情報源を決めます。
欠けた型番や規格を想像して補う処理は、名寄せの成功には数えません。どの情報が不足しているかを示せれば、担当者が確認すべき行を整理できます。
仮例：名称が同じでも販売単位が違う
架空の商品マスターに、同じ名称の「ケーブルA」が二つあり、一方は1本、もう一方は5本セットで販売されているとします。名称だけでまとめると、受注時の数量や価格の扱いを誤る原因になります。
この例では、名称が近い候補として表示しつつ、販売単位の違いを示して統合を保留します。名称の別表記だけが違い、型番や販売単位が一致する組み合わせとは区別します。この例は検証条件の説明であり、実在する商品や導入実績ではありません。
候補一覧には、比較する二つのID、一致項目、相違項目、不足情報、担当者の判断を残します。残す商品IDを決める作業は、同じ商品かどうかの判断の後に行います。
成功条件は誤統合と候補の見落としを分ける
検証用に、同じ商品と確認済みの組み合わせと、似ている別商品の組み合わせを用意します。調整に使ったデータとは別のデータでも試し、特定の仕入先の表記だけに合っていないか確かめます。
評価するのは、別商品を統合候補として強く提示する誤りと、同じ商品を候補に出せない見落としです。候補の段階の誤りと、担当者の承認後にも残った誤りは分けて記録します。重要な規格違いを見逃した結果を、件数の多い簡単な照合と平均化しないようにします。
担当者が一組ずつ探す時間と、候補を見て根拠を確認し、判断を終える時間を比べます。候補が多く出ても、不要な比較や資料確認が増えるなら、絞り方や画面を改善する必要があります。
統合後の参照先まで確認して運用する
PoCの出力は、まず担当者が承認する候補表にとどめます。本番への反映を含める場合は、在庫、受注、過去の取引など、商品IDを参照している箇所を確認します。
統合元と統合先の対応表、承認者、反映日時を記録し、誤った場合に戻す方法を決めます。承認してから反映するまでに元データが変わった場合は、同じ判断で反映してよいか再確認します。
新しい商品が登録されるたびに候補を探す運用なら、判断保留を誰が処理するかも決めます。放置された候補が増えていないか、同じ誤りが繰り返されていないかを確認します。
開発費用と個別開発を急がない条件
見積もりでは、データの行数と形式、比較する項目、元システム、候補の確認方法、本番更新の有無を伝えます。候補一覧の出力までと、基幹システムへの書き戻しまででは開発範囲が変わります。
AiPHAのPoC開発サービスは開発・検証20万円〜、10日でAIエージェントを納品する案内です。金額は対象業務と開発範囲に応じた見積もりで、AIサービスの利用料など別途必要な費用は事前に確認します。継続的な保守も別途相談となります。
件数が少ない場合や、既存の表計算の照合で十分に確認できる場合は、先にその方法を試せます。同一商品と判断する基準や担当者が決まっていない場合は、候補を自動で増やす前に判断体制を整えます。
AiPHAのオンライン30分の無料相談では、マスターの項目、重複で困る作業、判断に必要な資料から相談できます。実データを共有する前に、入力範囲と利用条件を確認します。