商品feedをAIで補完するなら何を生成してよい？事実項目と推測項目を分ける

結論

生成数を増やす前に、ground truth・権利・開示・承認者・測定仮説を固定し、AIは候補生成と変換に限定して運用する。

「AI 商品データ 補完 EC」で迷ったときは、最初に fieldごとのGENERATE/TRANSFORM/DO-NOT-GUESS表 を埋めてください。比較表の空欄を憶測で埋めず、必須条件を満たさない候補を先に落とす方が、総合rankingより再現性があります。

判断表：fieldごとのGENERATE/TRANSFORM/DO-NOT-GUESS表

観点	記録するもの	PASS条件	停止 / 要再確認
事実	source・取得日・confidence・更新責任を記録	事実と推測を分離し再確認先がある	sourceのない推測を事実欄へ書かない
変換	変換を同じ定義・同じ観測窓で記録	変換の根拠と判断者が明示される	変換が未確認のまま総合点で相殺しない
推測	source・取得日・confidence・更新責任を記録	事実と推測を分離し再確認先がある	sourceのない推測を事実欄へ書かない
検証	検証を同じ定義・同じ観測窓で記録	検証の根拠と判断者が明示される	検証が未確認のまま総合点で相殺しない
更新	version/revision/保存場所/再取得可否を記録	削除・更新後も再現経路が残る	参照元不明のassetを先に削除しない

使い方：各行を◎/○/△の雰囲気で採点するのではなく、PASS条件を満たす証拠を添付します。停止欄に該当した候補は、他の長所で相殺せず「要確認」に戻します。worksheet系の項目は自分の入力条件/実際の観測結果がない限り空欄のままにします。

なぜこの順番で判断するか

このテーマで最も起こりやすい失敗は、AI 商品データ 補完 EC という検索語から、すぐに「どれが一番か」というrankingへ飛ぶことです。しかし、同じ製品・求人・講座でも、利用者の目的と運用条件が違えば結論は変わります。本記事では、まず必須条件を落とし、その後に得失を比較します。比較軸は 事実、変換、推測、検証、更新 です。

また、料金・plan・求人・credit・利用規約・対応機能は時間で変わります。ここで固定するのは「2026-09-13時点の事実」ではなく、何をどの公式sourceで再確認し、どう意思決定するかです。公開直前に変わり得るな項目だけを更新すれば、記事の結論を追跡可能にできます。

使い方：5ステップ

1. まず自分の目的を1文にし、成功条件を1つ決めます。便利そう、人気そう、AIだからという理由は成功条件にしません。
2. 事実、変換、推測、検証、更新 を同じ単位で埋めます。不明は0点ではなく「未確認」として残します。
3. 公式pricing、docs、terms、求人票など一次情報で変わり得る情報を再確認します。
4. worksheet/検証が必要な項目は、空欄のまま結論を出さず、実際の観測結果または自分の入力条件で埋めます。
5. 最後に除外条件を適用し、必須条件を満たした候補だけを比較します。

Shopify、Google Merchant Centerを見るときの注意

Shopify、Google Merchant Centerはいずれも候補ですが、サービス名だけで優劣は決めません。同じ「AI」「agent」「cloud」「学習」「販売」という表現でも、課金単位、データ経路、管理者機能、権利、更新頻度が違います。公式ページで確認できない項目は「ない」と断定せず、未確認として扱います。逆に、公式に機能があることと、自分のワークフローで安全・採算的に使えることも別問題です。

AIは「候補を増やす装置」、公開判断は別工程

広告文、mail、lead data、商品feed、short video、avatarのいずれでも、AIが出した候補数を成果にしません。事実に基づくfieldとcreative variationを分け、brand/policy/rightsの確認後にhuman approvalを通します。A/B 検証では一度に複数の仮説を変えず、audience・value proposition・CTAのどれを変えたかを記録します。

AI生成/編集コンテンツの表示やmetadata、platform policyは更新されるため、公開時点の公式policyを再確認します。

サービス別の確認ポイント

• Shopify: plan/price/terms/機能のうち本記事の比較軸に関係する項目だけを公式sourceで再確認し、未確認項目を推測で埋めない。
• Google Merchant Center: plan/price/terms/機能のうち本記事の比較軸に関係する項目だけを公式sourceで再確認し、未確認項目を推測で埋めない。

実際の判断例

たとえば候補Aが機能豊富でも、事実 の条件を満たさず、候補Bは機能数が少なくても必須条件を満たすなら、先に候補Bを残します。その後で 変換 と 更新 の得失を比較します。これにより「機能数」「知名度」「AIっぽさ」の総合点で、本当に重要な欠点を隠しません。

費用を比較する場合も、月額や単価だけを横並びにしません。初期設定、従量、保存、再実行、確認、supportなど、この判断で実際に発生する項目だけを同じ期間・同じ成果単位へ揃えます。公式価格が変わったらinputだけを更新し、判断式は維持します。

選ばない・進めない条件

事実項目のsource、human approval、platform policy、権利/開示条件のどれかを確認できない素材は自動公開しない。

これは「慎重に」という抽象論ではなく、比較表の必須条件を満たさない候補を意思決定から外す公開条件です。条件が後から確認できたら、同じ表へ戻して再評価します。

一次情報

• Shopify — Magic product descriptions — Shopify Magicは商品情報からdescriptionを生成できるが、merchantが正確性を確認する責任を負う。
• Google Merchant Center — AI-generated content — Merchant CenterはAI生成title/description等の扱いとproduct data要件を公式仕様で定める。
• Canva — AI Product Terms — Canva AI Product Termsは2026-06-26版がcurrentで、AI contentのmisrepresentationやprovenance metadataの扱いを規定する。
• Google Ads — AI / responsive ads help — Responsive search adsは複数headline/descriptionを組み合わせ、広告資産を運用する仕組みを公式ヘルプで確認できる。
• Meta — GenAI transparency for ads — Metaは生成AIで作成・大幅編集された広告へのAI info表示を拡張している。
• HubSpot — Personalization — HubSpotではCRM属性等を基にemail personalizationを設定でき、利用data fieldの管理が必要。

まとめ

生成数を増やす前に、ground truth・権利・開示・承認者・測定仮説を固定し、AIは候補生成と変換に限定して運用する。 そのために正本とするのは固定rankingではなく fieldごとのGENERATE/TRANSFORM/DO-NOT-GUESS表 です。変化した事実だけを最新の情報源または実際の観測結果で差し替えれば、同じ判断基準で結論を更新できます。