Shopify AIで任せられる商品ページ業務と、保存前に確認する改善ポイント

Shopify AIには、商品説明の下書き、言い回しの候補、商品項目の編集補助、画像の生成・編集候補、レポートの調整を任せられる。保存する内容は、商品の原資料、変更前の値、実画像、公開先と照合して決めるものである。文章が自然であっても、商品性能や配送条件まで正しいとは限らない。

本記事では、商品情報の入力から採否、保存後の記録までを「商品AI作業票」でつなぐ。この作業票は公式資料を組み合わせた本記事独自の編集設計であり、標準機能の名称や実証済みの改善手法ではない。実ストアでの操作実演、売上や工数の改善測定は行っていない。

機能と制約の説明は、2026年10月8日に参照した公式資料に基づく。商品説明の公式手順などを参照し、対象ストアの画面、プラン、商品データの送信経路は、実際に作業する担当者が判断する前提である。

このページで確認できることは次のとおりである。

• 商品説明、商品項目、画像のどの入口を使うか。
• AIへ渡せる原資料と、生成材料から外す未確認情報の分け方。
• 下書きと変更前後を照合するプロンプト、入力票、差分票。
• SEO項目とGoogleへ送る商品データを混同しない確認方法。
• 保存可、修正、保留を決め、次の更新に記録を残す方法。

Shopify AIで任せられる商品ページ業務を選ぶ

MagicとSidekickを、完成させたい作業で選ぶ

Shopify Magicは日常業務の生成機能であり、Sidekickは管理画面内のAIアシスタントである。Shopifyには標準のAI機能に加えて外部AIとの接続もある。「Shopify AI」という言葉だけで、同じ画面、権限、操作を使う単一の製品だと考えないことが出発点である。

商品説明を作りたいのか、複数の商品項目の変更案を比較したいのかで入口を選ぶ。説明欄の生成と、チャットを通じた編集依頼では、対象を指定する方法も、変更した箇所を見つける方法も異なる。次の表は商品ページ業務に絞った選択表である。

表の完了条件は本記事の編集提案である。Sidekickに依頼できることと、その商品に採用してよいことは別の判断である。例えば説明の候補が必要なだけなら、価格や在庫の変更を依頼へまとめる必要はない。入力欄が多いからといって、すべてを同じ生成タスクへ含めない設計とする。

外部AI接続、サイトの構築、テーマ制作は、この表の作業を始めるための必須条件ではない。本記事の成果物は商品ページの確認票であり、外部接続や制作環境の設定手順へは広げない。担当している仕事が商品更新なのか、サイト制作なのかを先に決めることで、必要な機能の調査範囲も定められる。

日本語、端末、顧客対応を別々に判断する

SidekickはデスクトップとShopifyアプリから利用できるが、モバイルブラウザーの管理画面では利用できない。これはSidekickへのアクセス条件であり、商品説明欄のテキスト生成が同じ端末条件になるという意味ではない。

FAQの文章案を考えることと、顧客への返答を実行することは同じではない。顧客対応を担当するAIだと思って使い始めると、記事で扱う商品ページの編集範囲から外れてしまう。対応できない入口に出会った場合も、直ちに有料アプリの購入やプラン変更を解決策にせず、まず機能名、対象画面、端末を切り分ける。

参照記事

• AIを搭載したツール
• Sidekick
• Sidekickを使い始める
• 商品説明を自動生成する

商品情報を固定し、生成依頼の入力票を作る

原資料、表現の候補、運用者の決定を分ける

AIに渡す前に、各情報を「原資料で固定」「表現の候補」「運用者が決定」に分ける。これは本記事の編集上の分類である。素材や規格を文章の都合で変更せず、語順や説明の組み立てを候補として扱い、価格や公開先などの設定判断を別に残すためのものである。

Shopifyの商品詳細では、商品説明とは別に価格、在庫、重量、メタフィールドなどを扱う。重量は配送料の計算に使われるため、説明文としてもっともらしい値を作り、そのまま配送データへ入れる設計にはしない。説明欄に価格を書いた場合でも、価格の管理項目が同時に正しくなったとは扱えない。

資料の例は一般的な入力票の項目であり、すべてに専用のShopify欄があるという説明ではない。読者は自店で実際に持つ資料へ置き換える。表に商品名を書いたら、その商品の情報だけを集める。似た商品の記述を、同じ値を持つ根拠として混ぜないことを運用上の条件とする。

入力票は情報を大量に集めるためではなく、生成へ渡せるものを選ぶために使う。資料名だけでは参照できない場合、該当する項目の位置や条件も残す。原資料と現行ページが異なる場合は、どちらが正しいかをAIの文章の自然さで決めず、資料を管理する担当へ判断を戻す。

商品名と確認済みの特徴をそろえる

商品説明の公式手順では、少なくとも商品名と、2つ以上の特徴またはキーワードを入力することが勧められている。これは入力の目安であり、特徴の数を満たせば内容が正確になる基準ではない。商品説明の生成はプロンプトと同じ言語で出力されるため、日本語の説明が必要なら日本語で入力する。

記入の仕方を示す条件例として、素材の資料がまだ手元にない場合は「素材: 生成へ渡さない、資料担当へ照会、採否は保留」と書く。これは実商品の検証結果ではなく、資料が欠けたときの作業票の埋め方である。空欄を「AIが埋めてよい欄」と解釈しないよう、未確認である理由と次の担当を残す。

Sidekickで入力資料を整理する対話用テンプレート

商品説明の生成では、入力していない特徴やメリットが文中に入る場合があり、公開内容の正確性は利用者の責任である。生成に使う値を先に選ぶため、次の依頼文をSidekickの対話で使う編集提案とする。商品説明欄に入れる文章は次節のMagic用であり、この対話用依頼文を説明欄へ転記する用途ではない。

役割は、渡された商品資料を整理する編集補助である。
目的は、説明の生成に使える事実と不足資料を分けることである。
対象商品: [商品名]
原資料で確認した特徴: [特徴、適用条件、参照位置]
現行の商品説明: [変更前の説明]
対象読者: [説明を読む相手]
利用場面: [原資料にある利用場面]
注意条件: [省略せず残す条件]
希望する文体と形式: [自店の文体、説明の構成]

最初の応答は、入力済みの事実、不足資料、生成から外す事項、
資料照合から文案比較までの手順に限る。
資料にない性能や条件は推測せず、不足資料として整理する。
資料間で矛盾した値は、採用せず確認担当へ戻す項目にする。
材料がそろった範囲で説明候補と原資料の対応を提示する。
価格、在庫、配送データ、公開先は変更対象に含めない。
変更の適用、保存、公開、送信は行わず、人の判断を待つ。
完了報告は、使える事実、説明候補、参照資料、残った照合事項である。

置換欄は自店の入力票で埋める。パスワード、認証情報、顧客の非公開情報を求める依頼ではない。注意条件の資料がなければ、条件を作って入れるのではなく、資料整理の段階で保留する。この依頼文は公式の入力と対象指定を基にした出発点であり、実商品での出力検証を経たものではない。

Magicの商品説明欄へ渡す本文生成用テンプレート

Magicの公式手順では、生成文が商品説明へ直接適用される。そのため入力票の不足や相談の返答を、商品説明の本文に混ぜない依頼にする。以下は資料の採否が済んだ後に使うものであり、不足資料の点検は上の対話用依頼か担当者の作業票で先に終える。

原資料で確認した事実だけを使い、日本語の商品説明本文を作る。
商品名: [商品名]
確認済みの特徴: [原資料にある特徴またはキーワード]
対象読者: [説明を読む相手]
利用場面: [原資料にある利用場面]
残す注意条件: [原資料の注意事項と適用条件]
文体: [自店で使う文体]
構成と長さ: [希望する説明の構成と長さ]

出力は、商品ページへ掲載する説明本文だけとする。
事実、数値、性能、注意条件を追加・変更しない。
資料整理、確認待ちの注記、質問、挨拶、完了報告は本文に入れない。
価格、在庫、配送データ、公開先の変更は依頼しない。

完成条件は、出力が原資料の事実と条件に対応し、商品説明として採否を決められることである。資料が足りない段階ではこの生成操作に進めず、入力票へ戻す。生成文に会話の返答や資料整理の注記が入った場合も、その部分を掲載用の説明として採用しない。

どちらの依頼文も権限制御の設定ではない。対象外と書いた項目が変更案へ入ったかは、人が実際の案を照合する。保存と既存連携への反映が不明なら保存も保留し、ストアへ適用しない文案の整理を続ける条件とする。

参照記事

• 商品説明を自動生成する
• AIツールのベストプラクティス
• 商品詳細ページ

Shopify Magicで商品説明の下書きを作る

商品画面の操作と、各段階で見るもの

商品説明の自動生成は、参照した公式資料ではデスクトップ管理画面で行う手順である。同資料のテキスト生成はiPhoneとAndroidに対応していない。Sidekickへアプリからアクセスできることを、そのままこの生成機能の利用条件へ置き換えない。

公式手順では、商品を開いて生成アイコンを選び、プロンプトを入力して送信すると、生成されたテキストが商品説明へ直接適用される。説明欄に入った時点で、原資料との照合が終わった確定版とは呼ばない。次の表では公式操作と本記事の照合提案を分けている。

生成操作の前に現行説明を残すのは、変更後と比較するための編集提案である。公式操作へ、資料にない別の確定ボタンや保持の手順を追加するものではない。使用中の画面で別の表示がある場合は、同名の機能であるかを分けて扱う。

文体の確認と、商品事実の確認を分ける

説明の読みやすさは必要だが、読みやすいという評価だけで事実を採用しない。生成文を、商品性能、使い方、注意条件、対象読者、文体へ分けて照合する。商品資料で条件付きだった文が生成案で断定になっていれば、語順だけの変更とは扱えない。

例えば、元資料に利用できる条件があり、生成案がその条件を省略した場合、採否欄には「修正: 原資料の適用条件を戻す」と記入する。特定商品の出力例を作る必要はなく、条件が消えたという差分を理由として残せばよい。ここで確認した内容を後の差分票へ引き継ぐ。

文章を短くしたい場合も、まず残す事実と条件を指定する。短さを優先した結果、商品の注意点が抜けた案は採用しない。一方、原資料の内容が足りない場合は、文章の長さを変えて再生成するだけでは根拠が増えないため、資料の不足を解消する側へ戻す。

再生成と資料の補充を使い分ける

再生成は候補の言い回しや構成を変えるために使う。原資料にない特徴が必要な場合、AIに別案を求めて、もっともらしい内容が出たことを採用理由にしない。現行説明にも根拠のない記述があるなら、「以前から載っていた」という理由だけで引き継ぐこともしない設計とする。

作業票には、生成案のどこが不一致だったかを残す。「文章が悪い」ではなく、注意条件の消失、性能の追加、対象読者のずれなど、判断した箇所を記す。表現の問題なら文体や形式の指定を直し、事実の問題なら原資料を整える。この切り分けは本記事の運用提案であり、再生成回数の合格基準を設けるものではない。

公開済みの商品で説明を保存すると、新しい説明はすぐに表示される。したがって保存は、後で照合するための下書き整理と同じ位置に置かない。公開前の確認を終えるまで止まる位置を、編集担当と保存担当の間で明確にする。保存による既存連携への反映が不明なら、説明の照合が済んでいても保存は保留する。これは各ストアの送信挙動を断定した説明ではなく、本記事の保存判断の条件である。

参照記事

• 商品説明を自動生成する

Sidekickで変更前後を比較し、編集対象を限定する

対象商品と変更する欄を指定する

Sidekickでは商品の作成や編集、メタフィールド値の更新を依頼できる。依頼する前に、対象商品、参照する情報、変更する欄、期待する出力を分ける。商品名が似ている場合や、会話の途中で別の商品を扱った場合にも、その回の対象を曖昧にしない設計とする。

公式資料では、@の後にリソースを指定して対象へ言及できる。複数の項目を変更する場合には変更前と変更後の表を求める考え方も示されている。Sidekickが生成したフィールドは紫で強調表示され、変更箇所を見つける手掛かりとなる。ただし強調表示は、商品資料と一致したことを示す判定ではない。

メタフィールドという名称だけで、どの情報を入れる欄なのかは決まらない。作業票では自店が使う欄の意味と原資料を指定する。説明の文体を直す依頼の途中で、配送データまで変える必要が生じたなら、同じ案の延長として採用せず、別の判断に切り分ける。

Sidekickは変更を適用する前に確認のため提示するという説明がある。それでも、提示された案を一括で承認する前に、自分が限定した範囲と一致しているかを見る。適用前に見えることと、元資料の確認が済んでいることは別の条件として扱う。

差分票で、事実と表現を別々に採否判定する

入力票に、変更前、生成案、事実差分、表現差分、他の欄への影響を加える。原資料の位置は入力票から引き継ぐが、生成案を見て初めて分かる差分も記録する。合っている言い回しと、誤った性能が同じ案にある場合は、案全体をそのまま採用しない。

これは条件別の記入例であり、実商品の更新結果ではない。自店で記入する際は、各行へ実際の変更前と候補の文面、原資料の位置、確認者を足す。

「採用候補」は保存完了を意味しない。事実の一致が分かっても、文体や公開先の判断が残ることがあるためである。「修正」は、理由が分かり修正内容を決められる状態、「保留」は、根拠や決定者が欠けていて採用へ進めない状態として使う。曖昧な「問題なし」だけを残すより、何を根拠に次へ進めるかを記述する設計とする。

差分確認を依頼するテンプレート

次の依頼は、公式資料の対象指定と変更前後の比較を、説明更新へ当てはめた編集用テンプレートである。対象商品を@で指定できる場合は、その対象を選んだうえで、変更予定の欄を文章でも記す。作業の途中で対象が変わるなら、同じ依頼を継続する前に対象欄を差し替える。

役割は、商品項目の変更案と原資料の差分を整理する確認担当である。
対象は[対象商品]、更新予定の欄は[更新予定の欄]である。
原資料は[確認済みの資料と該当位置]、変更前の内容は[現行値]である。
目的は[今回の編集目的]である。

最初に対象商品、対象欄、不足資料、変更対象外の欄を整理する。
変更前、変更案、原資料の対応、事実差分、表現差分を表で示す。
未確認の値は埋めず、確認待ちとして列挙する。
価格、在庫、配送データ、公開先は、明示した対象でなければ含めない。
変更を適用する前に比較案を提示し、人の判断を待つ手順とする。
保存や適用が既存連携へ反映されるか不明なら、実行せず保留事項へ記す。
完了報告には、変更案、採否が必要な箇所、未確認事項を含める。

テンプレートの制約は権限制御ではないため、提示された変更案そのものを照合する。戻してほしいという依頼だけを、元の状態へ必ず戻る仕組みと見なさない。比較に使った元の値と素材を手元に残すことを本記事の運用提案とし、保存後に差分を追えるようにする。

参照記事

• AIツールのベストプラクティス
• Sidekickによるコンテンツの生成
• 商品詳細ページ

商品画像は用途別に生成し、実物と照合する

チャットの生成とファイルエディタの編集を分ける

画像は入口によって条件と保存の意味が異なる。Sidekickチャットで画像の候補を作る操作と、ファイルエディタで既存画像を編集する操作を、同じ画像処理としてまとめない。参照画像のサイズ条件も、通常の商品画像のアップロード全般へ転用しない。

5MB未満という条件は、5MB以下とは異なる。境界の条件を言い換えて、利用可能なファイルの範囲を広げない。最大3件という数もチャットの参照画像に限るものである。商品画像を何枚登録できるかを、この値から判断しない。

Sidekickの一般的な利用案内と個別の画像機能資料には、対象画面の異なる制限がある。したがって「Sidekickは画像をすべて編集できる」「画像は一切編集できない」と広く断定しない。必要なのがチャット生成か、背景編集か、画像変換かを選び、その入口で使える範囲を扱う。

料金やプランにも対象範囲の異なる説明があるため、画像機能全般を無制限、永久無料と呼ばない。機能を選んだ後に、対象ストアで利用できる条件を判断する。利用できない場合は、目的と入口を整理したうえで、当該機能の利用条件を調べる作業へ戻す。

実物から変えてよい部分を先に指定する

生成候補の見栄えがよいことと、販売する実物を正しく表していることは別である。元画像、商品の原資料、生成候補を並べ、何を変える目的だったかと照合する。撮影した画像であっても、撮影対象と販売する商品の対応は残す設計とする。

この表は実物照合の編集提案であり、画像処理が自動的に商品を正しく保つという製品仕様ではない。自動検出がある場合も、選択した領域と商品の輪郭を比較する。背景を変える依頼なら、色や形まで変化した候補は、そのまま背景変更の完了としない。

素材の出所や利用できる範囲が不明な場合は、入力画像をそろえるところへ戻す。本記事の資料には、個々の画像の利用権利や法的な適否を判断する根拠はない。生成できたという操作上の事実から、使用許可まで得られたと扱わない。

候補の保存と、商品への採用を区切る

Sidekickチャットの候補は、プレビューしただけではストアのメディアライブラリへ追加されない。「ストアに保存」を選んだときに追加される。候補を見る、ストアへ保存する、商品に採用するという判断を、作業票では分けて記録する。

ファイルエディタでは「保存」と「新規として保存」を選べる。元画像を比較用に残したい場合、新規として保存を選ぶことを本記事の運用提案とする。どの候補が元画像に対応するかを記録せず、ファイルが増えただけの状態にはしない。

透明背景を保つにはPNGとして保存する必要がある。標準1MPという説明は、すべての画像の画質や商品ページでの見栄えを評価した結果ではない。候補を保存する際には、用途、形式、元画像との対応も記録する。

ファイルエディタの未保存の生成画像は、編集セッションが終了すると失われる。必要な候補を残す判断と、販売ページへ採用する判断は分けられるが、未保存の候補を後で比較できる前提にはしない。候補保存を含め、実行する操作が商品や連携先へ反映されないと分かる範囲だけを進める。反映の有無が不明ならストア側の保存は保留し、保留理由と元画像の参照を作業票に残す。

参照記事

• Sidekickによるコンテンツの生成
• ファイルエディタでのメディア生成

SEO項目を本文と実画像に合わせて確認する

タイトル、メタ説明、alt、本文を別の欄で照合する

ShopifyのSEO用の案内では、ページタイトル、メタディスクリプション、alt、本文が確認場所となる。商品説明の本文だけを直して終えるのではなく、別の場所に出した商品情報も、同じ原資料と対応させる。

この表の採否は本記事の編集基準である。AIへ同じ商品情報を渡した場合も、各欄が自動的に一致すると決めない。例えばメタ説明の候補だけに新しい性能が現れたなら、本文をその性能へ合わせて書き足すのではなく、原資料に戻って採用できるかを判断する。

タイトルの短い表現と本文の詳しい表現が同じ長さである必要はない。大切なのは、短くしたことで約束が変わっていないことである。条件を省いた文が断定に変わっていれば、本文と同じキーワードがあるだけでは一致と判定しない。

Googleは、生成AIコンテンツの審査を本文に加え、title要素、メタディスクリプション、構造化データ、画像の代替テキストにも適用すると説明している。構造化データがある場合は、その値も商品事実との照合に含める。ただし、本記事は実装コードの作成や検索結果での表示確認を行ったものではない。

入力制限と推奨文字数を区別する

Shopifyの資料では、ページタイトルには最大70文字まで入力でき、60文字以内が推奨されている。メタ説明については160文字が推奨されている。入力できる上限と、文章を考える際の推奨を同じ合格基準にしない。

これらの値から、日本語の検索結果で必ず全文が表示される、順位が上がる、すべての入力画面が同じ制限である、といった結論は出さない。文字数を整えた後にも、商品名の対応、性能の根拠、残す条件の点検を行う。短い候補と詳しい候補を比べるなら、差分票に「残った事実」と「省いた条件」を記すと判断を具体化できる。

altは実画像を説明する

altは、画像に何が写っているかを明確に説明する読みやすい語句で作る。商品を買ってもらうための説明文を、そのまま画像の説明に置き換えるものではない。画像が変わった場合は、以前のaltと新しい画像の対応を改めて見る。

同じ説明を多くの商品へ自動展開するときも、対象商品と画像の対応を置き換える必要がある。Googleは、ユーザーへの価値を加えない大量のページ生成がスパムポリシーに違反する可能性を示している。AIを使うこと自体を違反とせず、生成した量を読者への価値や商品の正確性と同一視しない判断とする。

参照記事

• SEO用のキーワードを追加する
• 生成AIコンテンツのガイダンス

Googleへ送るAI生成商品データを確認する

Merchant Centerへの送信があるかを先に分ける

この節はGoogle Merchant Centerへ商品データを送る場合の確認である。商品ページの説明欄、検索用のSEO欄、ページの構造化データ、Merchant Centerへ送るデータは別の対象として扱う。商品説明を作っただけで、送信する属性の設定まで完了したとは判断しない。

Merchant Centerへの送信がないと確認できた読者は、保存判定の節へ進める。送信の有無や保存・適用から既存連携への反映が分からない場合は、「対象外」と決めず、連携確認待ちを記録し、当該商品データの保存・適用・公開・接続作業を保留する。資料整理やストア外での下書きは別に進められる。ストア側で進める操作は、その操作の非反映が確認できた範囲に限る。確認担当に伝える内容は、どの商品情報を生成したか、何を送信する予定か、どの連携経路かである。SEOの文章を直したという説明だけでは、送信先を特定できない。

テキストの属性と画像の識別情報を分ける

Merchant Centerの公式資料では、生成AIで作ったタイトルにはstructured_title、商品説明にはstructured_descriptionを使用する。生成AIで作った画像には、AI生成を示すIPTCのDigitalSourceTypeとTrainedAlgorithmicMediaの識別情報が必要とされる。

表は識別確認票であり、接続済み、送信成功、適合済みの記録ではない。読者が記入する際には、送信経路の名前、担当者、確認した資料、確認日を加える。「AI生成だから自動で付く」という理由だけで確認済みにはしない。

これらの属性名をShopifyのSEO欄へ貼り付ければ対応が終わるという手順ではない。どの欄からどの属性へ値を送るかは、連携側の仕様と送信データの対応を見て判断する。本記事の根拠資料には、特定のコネクターが自動で識別処理をすることを示す記録がない。

Shopify側の不可視透かしと、Merchant Centerが必要とするIPTC識別情報が同じであるという根拠もない。画像がAI生成だと分かる別の仕組みがあっても、必要な属性が送信画像にあるかは別の確認として残す。

技術値はタイトル用の範囲と原文を照合する

参照した日本語資料と英語資料には、タイトルのdigital_source_typeの値に表記差がある。英語資料ではtrained_algorithmic_mediaであり、日本語資料にはtrainer_algorithmic_mediaという表記がある。技術値を扱う場合は、文章としての翻訳と実装する値を同じものとして転記しない。

この表はタイトル用の説明に限る。説明用の技術値へ、そのまま横展開する指示ではない。実装する担当は個別属性の仕様を照合し、連携側の入力形式と対応を判断する。本文では送信コード、実装済みの設定、成功した送信例を作らない。

作業票へ記入する条件例として、「送信予定あり、属性の対応資料が未提供、連携確認待ち、連携担当へ照会」と書ける。この条件例では、連携確認が済むまで反映に関わる商品保存や適用も保留する。ページの説明案の内容を採用候補にできても、保存できる状態と同じ扱いにしない。

参照記事

• AI生成コンテンツ（日本語）
• AI-generated content（英語）

公開先と保存条件を作業票で判定する

商品の状態と公開先を別々に見る

商品の公開欄には販売チャネルとマーケットの一覧がある。商品のステータスだけを見て、どこに表示されるかまで判断しない。説明欄の更新がどの販売先に関わるかを、対象商品の公開設定と照合する。

また、非掲載の商品にはストアフロントのページがあり、直接URLでアクセスできる。下書きとは異なる状態である。非掲載へ変更すれば非公開のレビュー専用環境になる、という使い方を勧めない。誰にどの方法で内容を見せるかは、商品状態と公開先を分けて判断する。

これは自店の公開状態を調査した結果ではない。読者は実際の対象商品で、設定と表示先を記録する。同じ説明を更新する作業でも、すでに公開されている商品と販売前の商品では、保存時に判断する影響が異なるためである。

保存可、修正、保留を集約する

入力票、差分票、画像照合票、SEO票、送信確認票の内容を、保存判定へ集約する。他節の項目を全文写し直すより、採否、残った理由、次の担当を結び付けることを本記事の設計とする。販売先に関わる未確認事項がある場合は、文章の読みやすさだけで進めない。連携だけを止めて商品保存を続ける分岐にはせず、保存が送信へつながるかという判断もこの票へ集約する。すべての保存で送信されるという主張ではなく、反映が分からない操作を保留する運用提案である。

記入例として、元資料の条件が生成案から消えた行は「修正、原資料の条件を戻す、文面確認者が再照合」と記す。実際の完了記録では、修正後の文面と確認者、確認日を加える。判断が保留になった場合にも、空欄にしておくのではなく、足りない根拠と次の担当を記す。

確認者の役割は、原資料確認者、文面確認者、保存担当として残すことを提案する。同じ人が兼ねる場合も、資料と文章と保存のどこを判断したかが分かる形にする。

表の条件を満たしたことから、適法性や品質を一律に認定するものではない。本記事の資料で判断できる商品事実と操作条件の範囲で、採否を記録する。法的な判断や画像の使用許可が必要な場合は、対象の根拠を用意して別に判断する。

保存後の表示と、変更記録を残す

保存後の確認は自店で行う作業として提案する。商品説明の表示、採用した画像と商品の対応、選択したバリエーション、スマートフォンでの見え方、SEO欄、公開先を点検する。ここでいう点検は、本記事で実演して完了した結果ではない。

表示が異なれば、保存した値と、どの画面で見た内容かを分けて記す。説明の保存が済んだから画像の対応も済んだ、という集約はしない。テーマや表示側の問題がある場合は、どの表示がどの入力と異なるかを記録し、該当する担当へ渡す設計とする。

完了記録には、対象商品、変更前、変更後、原資料、採否理由、確認者、確認日、保存先、残った事項を入れる。元の値と素材は、比較できる状態で保持する。AIへの戻す依頼だけを、変更前の状態へ自動復旧できる保証として扱わない。

保存しないと判断した作業にも記録を残せる。生成案を捨てた理由が根拠不足なら、次に必要なのは資料の補充である。文体の不一致なら、次の依頼で文体を変えられる。採用したかどうかだけでなく、なぜ止めたかを残すことで、次の作業の入力が具体化する。

参照記事

• 商品説明を自動生成する
• 商品詳細ページ
• AIツールのベストプラクティス

同じ作業を再利用し、結果を記録する

共通の指示と毎回の商品情報を分ける

Sidekickのスキルは、頻繁に行うタスクの再利用可能な指示である。ショートカットは、/の後にスキル名を入力する形で実行できる。指示を保存することと、商品を無人で更新することを同じ機能として説明しない。

作成できるスキルは最大50個で、一部のストアでは上限が25個となる。以前のバージョンでスキルとして保存したプロンプトは、この制限には数えないという説明もある。上限を一律の値として扱わず、対象ストアの条件に合わせて使う。

再利用する部分は「最初に不足資料を示す」「変更前後を比較する」「対象外の項目を分ける」といった作業の型とする。一方、商品名、特徴、注意条件、画像、対象欄は、その回の資料へ差し替える。前回の商品の規格が残っていたら、共通手順が正しくても今回の入力としては採用できない。

共有する指示へ、自店の商品固有情報や機密を固定して入れないことを運用提案とする。共通の指示から商品情報を外し、実行時に対象の資料を渡す形なら、何を毎回差し替えるかを明示できる。ただし、その設計からデータの安全性や利用規約への適合を断定するものではない。

レポートの調整とコピー保存を区切る

既存レポートのカスタマイズでは、管理画面の「ストア分析」から「レポート」へ進み、対象のレポートを開く。「クエリを絞り込む」欄へ平易な言葉で依頼を入力し、Enterで送信する。必要なら追加のプロンプトで内容を調整する。

変更が済んだら「別名で保存」を選び、新しいレポートの名前を入力して「コピーを保存」を選ぶ。ここでは既存レポートの調整手順を扱い、新しいデータ探索の作成手順へは広げない。

対象や期間の照合は本記事の編集提案であり、公式手順で必須の操作として足したものではない。依頼が自然言語で書けることから、意図した商品だけが集計されたと決めない。どの条件を伝え、どの集計を保存したかを記録する。

商品インサイトには、販売数、購入した顧客数、純売上高が表示される。これらの値が動いた場合にも、AIで商品説明を変更したことの効果だと直ちに判断しない。商品ページの変更以外に、販売条件や流入が変わったかどうかを、同じ記録で整理する提案とする。

作業の採否と、観測する数値を別の欄に残す

更新作業が完了したことと、売上の改善が分かったことは別の状態である。実際の観測値を持たない段階では、成果欄を作り数字を埋める必要はない。何を変更し、何を観測するのかを先に決め、実測した時点で記録を加える。

記入例として、生成案に原資料のない性能があった場合は「採否: 保留、次の作業: 資料担当への照会、数値の評価: 本件では行わない」と記す。これは作業票の条件例であり、成果測定をした記録ではない。売上や作業時間の改善量を、作業の採否から作らない。

次に行う作業は、票に残った未確認事項から選ぶ。原資料が不足していれば資料整備、事実は合っていて文体が違えば文面調整、保存値と表示が違えば該当画面やテーマの確認、送信属性が不明なら連携担当の照合である。すべてを再生成で解決しようとせず、止まった理由に対応する作業へ戻す。

商品ページへAIを使う際の完了条件は、候補が出たことだけではない。資料を用意し、対象を限定し、差分と表示先を照合して、採否と保存を記録できる状態を目指す。本記事の票と依頼文はそのままコピーし、自店の資料へ置き換えられる。まずは対象商品と変更する欄を定め、入力票の未確認事項を整理するところから始める。

参照記事

• Sidekickでスキルを使用
• SidekickでShopifyQLクエリを生成する
• 商品詳細ページ
• 生成AIコンテンツのガイダンス
• AI生成コンテンツ（日本語）
• AI-generated content（英語）