商品データ検証：必要な箇所にAI、それ以外はルールで

商品データは、入力が不揃いでも期待する出力が構造化されて見えるため、企業向けAIの有望な用途です。ただし、文書を読んだり説明文を書いたりできるモデルに、レコードが要件を満たすかの判断まで委ねるべきではありません。当社は確率的な解釈と決定論的な統制を分離します。モデルは抽出と文章化を、追跡可能なルールは検証と判断を担います。

商品データは文章作成ではなく統制システム

商品レコードは、サプライヤーの根拠資料、商取引上の要件、法的義務、チャネルの仕様、社内のマスターデータが交わる場所です。一つの属性が、検索、物流、税、安全審査、包装、顧客の期待に影響します。小さく見える変更でも、多くの下流システムへ波及し得ます。

そのため、「商品コンテンツの生成」だけをシステムの範囲にするのは不適切です。生成は一つの作業にすぎません。実際のワークフローは、根拠を受け取り、対象と属性を特定し、方針を適用し、例外を振り分け、承認を記録し、許可された版を公開します。信頼性は一連の処理全体に依存します。

当社はまず作業を次の二種類に分けます。

解釈：形式の異なる文書、画像、自由文を読み、見慣れない用語を既知の概念に対応付け、簡潔な説明文を作成する。
統制：必須項目、データ型、許容値、単位、項目間の依存関係、根拠の要件、権限、公開状態を確認する。

解釈は確率的で、モデルが役立ちます。統制は、方針を明文化できる限り決定論的にすべきです。両方を一つのプロンプトにまとめると、出力の監査、テスト、判断への異議申し立てが難しくなります。

AI導入前に正規レコードを定義する

正規の商品モデルには、安定した識別子、型を定めた項目、明示的な責任者が必要です。各属性の定義、単位、値の個数、許可された情報源、必須の根拠、市場・チャネルの適用範囲、変更を承認する権限を記録します。

原資料は変更せず、抽出した候補を承認済みの値と分けて保存します。これにより、モデルの生成値がひそかに事実となるのを防ぎ、担当者が候補を原資料と比較できます。最小限のデータリネージ記録は次のとおりです。

product_id
attribute_id
candidate_value
source_document_id
source_location
extraction_method
model_or_rule_version
confidence
created_at
review_status

本番のレコードに入れるのは、該当するルールと承認経路を通過した値だけです。これは認証ページ付きB2B商品カタログの設計と同じです。主張を交換可能な宣伝文句として扱わず、根拠に結び付けておきます。

モデルが価値を生む領域

モデルは、ワークフローの中で入力や出力の変動が大きい部分で役立ちます。

非構造化の根拠資料から候補を抽出する

サプライヤーの書式、技術資料、ラベル、画像は、同じ属性を異なる配置や言葉で表します。モデルは値の候補を見つけ、周辺の文章を正規化し、根拠への参照付きで構造化した候補を返せます。出力仕様では、根拠がなければnullを必須とします。推測で埋めても処理を完了したことにはなりません。

画像処理では抽出を裏付ける画像領域やページを、文章では短い原文の抜粋や座標を保持します。信頼度は振り分けには有用ですが、証拠ではなく、原資料への参照の代わりにはなりません。

統制語彙へ対応付ける

原資料の用語が組織の分類体系と完全に一致しない場合、モデルは最も近い統制済みの概念と対応付けの理由を提案できます。最終的な受け入れはルールまたは権限を持つ担当者が判断します。完全一致する同義語表があるなら、決定論的な照合を先に行い、モデルは未解決の残りだけを処理します。

顧客向け文章を作る

モデルは承認済み属性から、タイトル、箇条書き、要約、翻訳を作れます。プロンプトには承認済みレコードの情報だけを使い、任意の文体指示を明確に区別します。生成した文章には、長さ、禁止された主張、必須の限定表現、用語、裏付けのない値を確認するルールを適用します。

モデル自身に、その文章が要件を満たすかを判定させません。同じ確率的な処理が書き手と判定者を兼ねることになるためです。

ルールが判断すべき領域

失敗条件を表現し検証できる部分には、ルールを使います。代表的な種類は次のとおりです。

ルールの種別	統制例
必須	この商品分類の必須属性が入力されている
型・形式	宣言された型と文字コードで値を解析できる
範囲	数値が許可された範囲内にある
列挙	値が現在の統制語彙に含まれる
単位	許可された単位であり、換算が情報を失わないか承認済みである
項目間	条件となる値が該当するとき、依存する項目が存在する
根拠	主張に適格かつ最新の原資料がある
整合性	包装数量、寸法、算出した合計が一致する
適用範囲	値が対象の言語、市場、チャネルに対して有効である
権限	実行者に、この項目の承認または公開の権限がある

各ルールには識別子、バージョン、責任者、重大度、人が理解できるメッセージが必要です。メッセージは重要です。「検証失敗」はサポートへの問い合わせになりますが、「正味量には承認済み単位と原資料への参照が必要です」なら、具体的な修正作業になります。

この分離により、複数の配信先へのフラットファイル自動化も安全になります。正規データの検証方針を弱めずに、配信先ごとの書式を変えられるためです。

取り込み時、抽出後、人による編集後、出力前、公開前の複数の境界でルールを実行します。画面、バッチパイプライン、APIで同じバージョン管理済み検証サービスを使います。システムごとにルールを複製すると、矛盾した結果になります。

参照ワークフロー

プロセスは次の明示的な状態遷移として実装します。

取り込み：原資料のファイル、チェックサム、出所、受領時刻を登録します。
前処理：文書を分類し、商品の識別候補と関連付けます。
抽出：決定論的なパーサーを先に使い、未解決の項目だけモデルへ送ります。
正規化：意味を変えずに形式と単位を変換します。
検証：該当するバージョン管理済みルール一式を実行します。
レビュー：例外または高リスクの変更だけを、権限を持つ人へ送ります。
承認：受け入れた値、根拠、承認者の識別情報を記録します。
公開：管理されたアダプターを通して各配信先へ書き込みます。
観測：下流での却下、訂正、成果を示す情報を記録します。

各遷移でイベントを記録し、再実行可能なシステムにします。分類体系やルールが変わったら、すべてを再抽出せず、影響を受けるレコードを特定して再検証できます。

同じ原則が言語版にも当てはまります。規律ある多言語ECの設計では、翻訳を派生したバージョン管理対象の出力とし、承認済みの事実と根拠を共有します。

また、すべての項目を利用可能な最大のモデルに送る、コストのかかる設計を避けます。正確な識別子、日付、既知の単位、列挙コードは決定論的に処理し、モデルを曖昧な項目だけに使います。費用と遅延を減らし、残るモデルの評価にも意味を持たせられます。

信頼度は作業を振り分けるが、真実を保証しない

信頼度スコアは誤解されがちです。高い信頼度は、情報源が正しい、最新である、使用を許可されていることを証明しません。特定の方法によるモデルの評価を示すだけです。

当社は、信頼度をリスクとルールの結果と合わせて振り分けに使います。低リスクで直接の根拠があり、すべてのルールを通過した候補は、簡易なレビューへ送れます。規制対象や商業上重要な主張は、信頼度にかかわらず人の承認が必要なことがあります。根拠がなければ閾値を下げるのではなく、判断を見送ります。

代表的なデータを使い、属性と文書の種類ごとに閾値を調整します。標準識別子の抽出と素材に関する主張の解釈は同じではなく、全体で一つの閾値を使うと大きな差を隠します。意味のある区分ごとに適合率、再現率、判断の見送り、レビュー担当者による判断の上書きを追跡します。

例外もプロダクトの一部

実際のカタログには、セット商品、交換品、地域別仕様、古いレコード、矛盾するサプライヤー資料があります。正常経路だけの設計は、見えない場所で手作業を生みます。

例外には理由コード、重大度、責任者、期限、許可された解決方法を設けます。担当者が候補、原資料の根拠、失敗したルール、下流への影響を一画面で確認し、原資料を編集せずに受け入れ、修正、却下、新たな根拠の要求を行えるようにします。

判断の上書きは明示的で範囲を限定したものにします。特定の商品と配信先の警告を上書きしても、ルール全体を無効にしてはいけません。繰り返す上書きは、ルール、分類体系、情報源のプロセス、商品モデルの見直しが必要な兆候です。

対応水準は到着順ではなく業務リスクに合わせます。任意の販促項目の欠損と安全属性の矛盾を、同じキューで扱うべきではありません。

ベースラインから成果まで測る

自動化前に、項目の充足率、初回検証の通過率、訂正サイクル、レビュー時間、下流での却下率、重大な欠陥率を測ります。機密性のある社内報告では、各系列をBaseline = 100の指数にし、絶対件数と商業上の値は認可された環境内に残せます。

リリース後は抽出品質と運用成果を分けます。抽出が技術的に正確でも公開に間に合わないことがあり、レビュー時間が減っても重大な欠陥が増えることがあります。そのため評価表には次の項目を含めます。

属性ごとの候補精度と根拠の網羅率
ルール通過率と判断の見送り率
人による判断の上書き率と訂正率
キュー滞留時間とレコード承認までの時間
配信先での却下と公開後の訂正
重大な誤りに対する安全基準

モデル、プロンプト、分類体系、ルールは別々にバージョン管理します。評価データには一般的なレコードと既知の例外を含めます。デプロイ前に提案版を再実行し、新たに受け入れられるレコードと、新たに拒否されるレコードの両方を比較します。平均精度が上がっても、安全基準が合意した許容範囲を超えて悪化したらリリースを止めます。

変更を運用方針の変更として管理する

ルールは運用方針を表し、変更によって公開できる商品、許される主張、作業を受け取るチームが変わります。そのため、ルール変更には責任者、理由、適用開始日、テスト、影響に応じた承認が必要です。

モデル変更にも同様の規律が必要ですが、テストは異なります。敵対的・低品質の入力を含む正解ラベル付き事例で抽出と文章化を評価します。構造化出力の仕様も検証し、未知の項目、不正な型、根拠の欠損が安全に失敗することを確認します。

展開は段階的に行います。シャドーモードでレコードを変えずに新経路を比較し、限定した対象群へ進め、安全基準を保てれば広げます。書き込みアダプターで冪等性、最小権限、ロールバックを担保し、モデルに正本を管理するシステムへの無制限な直接アクセスを与えません。

スケールする役割分担

持続可能な設計は、AIかルールかの二択ではなく、意図的な役割分担です。

モデルは不揃いな根拠を候補へ、承認済みの事実を有用な文章へ変換します。ルールは反復可能な方針を表し、人が曖昧さを解消し、影響の大きい変更を承認し、例外から分かった方針の不足を改善します。イベントログが、すべての判断を根拠とバージョン管理済みロジックに結び付けます。

リスクが操作と根拠で限定されるため経営層へ説明しやすく、各要素の仕様をテストできるため構築しやすくなります。運用時の失敗も、抽出漏れ、不適格な情報源、ルールによる組み合わせの拒否、権限者による警告の上書き、と具体化します。

企業の商品データが完全に整い、統一されることはありませんし、その必要もありません。システムは、観測したもの、推測したもの、許可されたもの、判断者を把握する必要があります。解釈が本当に必要な箇所にAIを、組織が判断を明文化できる箇所にルールを使います。