コンテンツにスキップ
Picaro.AI Picaro.AI Prompt Library

カタログを診断して改善案を作る

このページでは、Amazon の商品カタログ（商品ページ）を診断し、修正案を「提案」することができます。AI がカタログを無条件に作成・確定するのではありません。流れは常に「AI が提案 → 人が確認・承認 → 登録用データを出力 → Seller Central / Vendor Central で手動反映」で、Picaro からカタログへの書き込み（自動更新・アップロード）は行いません。

このページの基本情報

Section titled “このページの基本情報”
項目内容
このページでできること現行カタログの総合診断・Rufus 観点の診断と、商品タイトル / 箇条書き（Bullet Points）/ 商品説明 / Item Highlights の改善案づくり、Seller Central / Vendor Central 登録用データへの整形
対象Amazon の商品カタログ（商品タイトル / ブランド / 箇条書き（Bullet Points）/ 商品説明 / 特徴属性 / カテゴリー / 画像 / 寸法 / 識別子）
必要なデータ・接続対象 ASIN。カタログは Picaro のカタログ取得 API（POST /ai/catalog/item）から読み取ります（対応マーケットプレイス: 日本 / 米国 / ドイツ / 英国、既定は日本）。自社・他社どちらの ASIN でも取得できます
実行範囲提案のみ・整形のみ（読み取り専用）。反映は人が Seller Central / Vendor Central で手動で行います。Picaro からカタログへの書き込みはありません

こんな時に使います

Section titled “こんな時に使います”
  • 現行の商品ページのどこから直すべきか、優先順位を付けたい
  • Rufus 経由の露出・購入判断を意識して、質問に答えられる情報が揃っているか確認したい
  • 商品タイトル / 箇条書き（Bullet Points）/ 商品説明 / Item Highlights の改善案がほしい
  • 現行カタログと提案版を並べて、社内レビューやブランド確認に回したい
  • 承認済みの改善案を、Seller Central / Vendor Central に登録しやすい形式に整えたい
  • クリックされにくい商品広告の商品ページを見直したい（きっかけは関連ページの分析）

実行前に確認すること

Section titled “実行前に確認すること”
  • 対象 ASIN … 診断したい商品の ASIN（例: B0XXXXXXXX）を用意します。
  • マーケットプレイス … 日本 / 米国 / ドイツ / 英国 から指定できます（既定は日本）。
  • 検索キーワードの裏付けを取るかどうか … プロンプト 3・5 は検索語句の実データを使います。対象 ASIN が SQP（検索クエリパフォーマンス）に登録されていない場合は、アカウント全体の広告検索語句で代替し、その旨が出力に明記されます。
  • 反映は人が手動で行う前提 … このページは提案・整形までです。文字数制限・入力項目・カテゴリー別テンプレートは Seller Central と Vendor Central で仕様が異なり変更されることもあるため、反映前に登録先の最新仕様を確認します。

プロンプト早見表

Section titled “プロンプト早見表”
やりたいこと分かること・作られるもの設定変更プロンプト
現行カタログを 4 観点で総合診断する観点別の評価・評価理由と修正優先順位提案のみプロンプト 1
Rufus の観点でカタログを診断する診断項目別の評価・不足情報・改善案提案のみプロンプト 2
商品タイトルの改善案を作る改善案 3 案 × 変更理由 × 検索キーワードの裏付け数値提案のみプロンプト 3
箇条書き（Bullet Points）の改善案を作る現行 → 提案の対比表 × 変更理由 × 文字数提案のみプロンプト 4
商品説明の改善案を作る改善案 × 変更理由 × 根拠区分の書き分け提案のみプロンプト 5
Item Highlights の改善案を作るフレーズ形式の改善案 × 根拠区分 × 採用理由提案のみプロンプト 6
現行カタログと提案版を比較する項目別の 現行 / 提案 / 変更理由 の比較表提案のみプロンプト 7
承認済みの改善案を登録用データに整形する登録用テキストとレビュー用データ整形のみ／手動反映プロンプト 8

プロンプト 1: 現行カタログを 4 観点で総合診断する

Section titled “プロンプト 1: 現行カタログを 4 観点で総合診断する”

現行カタログを取得し、検索性 / 購入判断 / 可読性 / 情報不足の 4 観点で診断します。改善案づくり（プロンプト 3〜6）の前段として、どこから直すべきかの優先順位を付けます。

こんな時に使う — 個別の改善に入る前に、直す優先順位を付けたいとき。

実行前に必要な情報 — 対象 ASIN。マーケットプレイス（既定は日本）。

目的：カタログ改善による検索順位・購入率向上のため、ASIN {{対象ASIN（例: B09J4YRG2P）}}の現行カタログを取得して総合診断してください。


【カタログの取得方法】
call_picaro_api で POST /ai/catalog/item、body は {"asin": "{{対象ASIN}}", "market_place": "{{マーケットプレイス（例: JP）}}"}。
フィールド名は market_place（アンダースコア）です。marketplace と書くと 422 になります。
これで タイトル(product_name)／ブランド／メーカー／Bullet Points(bullet_point)／商品説明(product_description)／
カテゴリ(classifications・親カテゴリ付き)／商品タイプ(product_type)／画像(product_images)／識別子(identifiers)／
寸法／特徴(special_feature)／便益(product_benefit)／注意書き(safety_warning)／発売日 が取得できます。自社・他社どちらのASINでも取得できます。
取得経路はこの API だけです。エラーを返した場合も、ほかの取得手段を探さないでください。


【取得データの読み方（誤読防止・必ず守る）】
- product_images は1画像が複数解像度で返ります。variant（MAIN / PT01…）で重複排除してから枚数を数えてください。そのまま数えると約3倍になります。
- product_description は商品によって空文字のことがあります（同一ブランド内でも空・非空が混在します）。
  空だった場合は「登録が無い」と断定せず、language_tags.product_description が空配列かを併せて確認し、
  「商品説明は空（A+コンテンツへ移行している可能性あり・本APIでは判別不可）」と書いてください。
- bullet_point は改行区切りの1つの文字列です。行数を Bullet Points の本数として数えてください。
- 空配列（color / material / care_instructions 等）は「属性が未登録」であり、「取得できなかった」とは区別して書いてください。


【このAPIで取得できないもの（診断対象から外し「取得不可」と明記する）】
A+コンテンツの有無と内容／動画／価格／レビュー／在庫／検索結果順位／ブランドストア導線。
これらを推測で補完したり、「無い」と断定したりしないでください。


【診断】検索性（検索キーワードの反映度）／購入判断（比較・意思決定に必要な情報が揃っているか）／
可読性（構成・文の長さ・重複・表記の乱れ）／情報不足（欠けている情報）の4観点で、観点ごとに評価と評価理由を付け、
修正優先順位の高い順に改善ポイントを挙げてください。評価理由には必ず取得した実データ（文字数・本数・画像枚数・属性の空欄など）を根拠として添えてください。
検索性の評価では、analyze_sqp で対象商品の実際の検索クエリとインプレッションシェアを取得し、
上位クエリがタイトル・Bullet Points・商品説明に反映されているかを突き合わせてください
（集約プレースホルダー「ノーブランド品」は実クエリではないため施策対象から除外します）。
商品の実際の効能と一致しないクエリは、露出が取れても購入に繋がらないため、カバー対象に含めないでください。


【取得に失敗した場合】上記の API がエラーを返した場合は、実際に呼び出したツール名・パス・返ってきたエラー内容のみを
正確に報告し、診断は実施しないでください。取得できた一部の項目だけで部分的に診断することも行わないでください。
代わりに、現行のタイトル・Bullet Points・商品説明のテキスト（ブランド公式の説明）を貼り付けるようユーザーに依頼してください。
呼び出していないツールについて「アクセス不可」等の説明を作らないでください。


最後に次の3点を出力してください。
1. 推奨アクション — 改善優先度上位の項目を対象・理由・優先度とともに示す。
   ブランド確認が必要な項目（効能表現の追加・多言語表記など）は「要ブランド確認」と明示して切り分ける
2. 実行方法 — プロンプト 3（商品タイトル）／プロンプト 4（箇条書き）／プロンプト 5（商品説明）／
   プロンプト 2（Rufus の観点でカタログを診断・未実施の場合）へ渡す
3. 測定 — カタログ更新後、Rufus回答品質・検索順位の変化を次回診断で確認する

変更できる条件 — 対象 ASIN（例: B0XXXXXXXX）／マーケットプレイス（日本 / 米国 / ドイツ / 英国）。

返ってくる内容 — 4 観点ごとの評価・評価理由・改善ポイントと、修正優先順位のリスト。評価理由には取得した実データ（文字数・本数・画像枚数・空欄の属性）が根拠として添えられます。

このプロンプトで AI がやること — まず Picaro のカタログ取得 API で現行カタログを読み、画像の重複排除や「空文字」と「未登録」の区別といった誤読しやすい箇所をルールどおりに処理します。検索性の評価だけは実データが必要なため、SQP（検索クエリパフォーマンス）で対象商品の実際の検索クエリとインプレッションシェアを取得し、上位クエリがカタログに反映されているかを突き合わせます。取得に失敗したときは、部分的に診断せず、呼び出したツールとエラー内容だけを報告して止まります。

設定変更 — 提案のみ（読み取り専用、カタログの変更なし）。

次にすること — 診断結果を踏まえて、プロンプト 3〜6 の個別改善案づくりに進みます。

プロンプト 2: Rufus の観点でカタログを診断する

Section titled “プロンプト 2: Rufus の観点でカタログを診断する”

カタログに「買い物客の質問に答えられる情報」が揃っているかを診断します。この揃い具合が、Rufus 経由の露出・購入判断に影響します。

こんな時に使う — Rufus が回答しやすい商品情報になっているか確認したいとき。

実行前に必要な情報 — 対象 ASIN。

目的：Amazonの生成AIアシスタント（Rufus）を含む「商品情報を読む機械と人」が、ASIN {{対象ASIN（例: B09J4YRG2P）}} の商品を正しく理解できるかを、現行カタログの実データに基づいて診断してください。


【カタログ取得】
call_picaro_api で以下を呼び、返却された実データだけを診断の根拠にしてください。
  method: POST
  path: /ai/catalog/item
  body: {"asin": "{{対象ASIN（例: B09J4YRG2P）}}", "market_place": "{{マーケットプレイス（例: JP）}}"}
- フィールド名は market_place（アンダースコア）です。marketplace だと 422 エラーになります。
- product_images は同一画像が複数解像度で返るため、variant（MAIN / PT01…）で重複排除してから枚数を数えてください。
- A+コンテンツ・レビュー・カスタマーQ&A・全成分表示は、このAPIには含まれません。
- 上記APIがエラーを返した場合のみ、呼び出したツール名と返ってきたエラー内容のみを正確に報告し、診断は実施せず、現行カタログのテキストを貼り付けるようユーザーに依頼してください。呼び出していないツールについて存在しない制約を説明しないでください。


【診断のルール（厳守）】
- Rufus のランキング要因や内部仕様は公開されていません。「Rufus はこう評価する」と断定しないでください。評価は「カタログの構造化情報がどれだけ充足し、一貫しているか」という観測可能な代理指標で行い、断定ではなく傾向・仮説として記述してください。
- すべての指摘に根拠区分を付けてください。
  [実データ] … 取得したカタログの該当フィールドを引用して示せるもの
  [取得不可] … このAPIでは取得できないもの（推測で埋めないこと）
  [一般論] … 一般的なベストプラクティス（出典のない断定をしないこと）
- 空のフィールドを「情報が無い」と断定しないでください。A+コンテンツ側で補われている可能性があるため「構造化フィールドが空」と表現してください。
- 該当しない診断項目は「非該当（カテゴリ: <product_type>）」と明記し、無理に埋めないでください。


【診断項目】
商品の用途／対象ユーザー／使用方法／サイズ・容量・素材・成分／比較ポイント／対応環境・互換性／購入前によくある疑問への回答／情報の不足・矛盾／タイトル・Bullet Points・商品説明の重複／購入判断に必要な情報の網羅性。


項目ごとに「根拠区分・評価理由・不足情報・修正優先順位（高／中／低）・具体的改善案」を出してください。スコアのみの回答は不可です。
「情報の不足・矛盾」では、数値フィールド間の不整合（item_dimensions と item_package_dimensions、size・容量・重量とタイトル表記の食い違いなど）を必ず突き合わせて確認してください。


【最後に次の3点を出力してください】
1. 推奨アクション — 改善案のうち優先度上位のものを、対象フィールド・理由・根拠区分とともに示す
2. 実行方法 — 対応する改善提案プロンプト（プロンプト 3 商品タイトル／プロンプト 4 箇条書き／プロンプト 5 商品説明）へ渡す。成分・素材・効能に関わる変更は、ブランドによる事実確認を必須条件として明記する
3. 測定 — 次回診断で「構造化フィールドの非空率」と「矛盾件数」を再測定する。Rufus の回答品質そのものは外部から測定できないため、KPIとして断定しないこと

変更できる条件 — 対象 ASIN。

返ってくる内容 — 診断項目ごとの評価・評価理由・不足情報・修正優先順位・具体的な改善案。「Rufus 対応スコア」のような点数だけではなく、何をどの順に直すべきかまで返します。

このプロンプトで AI がやること — Rufus のランキング要因は公開されていないため、「Rufus がどう評価するか」ではなく「カタログの構造化情報がどれだけ充足し、一貫しているか」という観測できる代理指標で診断します。指摘には [実データ] / [取得不可] / [一般論] の根拠区分が必ず付くので、実データに基づく指摘と一般論を読み手が区別できます。寸法・容量・重量とタイトル表記の食い違いなど、フィールド間の矛盾も突き合わせます。

設定変更 — 提案のみ（読み取り専用、カタログの変更なし）。

プロンプト 3: 商品タイトルの改善案を作る

Section titled “プロンプト 3: 商品タイトルの改善案を作る”

現行の商品タイトルを診断し、検索性と識別性を両立する改善案を提案します。盛り込むキーワードは実データで裏を取ります。

こんな時に使う — 検索キーワードを盛り込みつつ、訴求語の羅列にならないタイトルにしたいとき。

実行前に必要な情報 — 対象 ASIN。

目的：ASIN {{対象ASIN（例: B0XXXXXXXX）}}の検索性と購入率向上のため、商品タイトルの改善案を作成します。


【手順1: 現行カタログの取得（必須・一次ソース）】
call_picaro_api で以下を呼び、現行タイトル（product_name）・bullet_point・product_description・product_type・classifications を取得してください。
  method: POST / path: /ai/catalog/item / body: {"asin": "{{対象ASIN}}", "market_place": "JP"}
※フィールド名は market_place（アンダースコア）です。marketplace だと 422 になります。
※product_description は空文字で返ることがあります。空の場合は「取得したが空」と明記し、「説明が無い」と断定しないでください。A+コンテンツはこのAPIに含まれません。
取得に失敗した場合は、呼び出したツール名とエラー内容をそのまま報告し、改善案を生成せずに停止してください。


【手順2: 検索キーワードの実データ取得（必須・推測禁止）】
タイトルに入れるキーワードは、必ず実データで裏を取ってください。推測で「検索されていそうな語」を書いてはいけません。
  a) list_sqp_products で対象ASINの product_id を引く。
  b) 見つかれば list_sqp_date_ranges で有効な date_range を確認し、analyze_sqp（frequency=monthly、確定済みの直近期間）を実行する。
     → 各 query の queryVolume / impressionShare / asinCtr / asinCvr / bottleneck を根拠に使う。
  c) 対象ASINが list_sqp_products に無い場合のみ、list_search_term_performance（直近1か月）で代替する。
     この場合は「アカウント全体の広告検索語句であり対象ASIN固有ではない」と出力に明記する。
根拠に使った各キーワードには、必ず数値（検索ボリューム・インプレッションシェア等）と取得元ツール名を併記してください。


【手順3: 改善案の作成】
現行タイトルの改善案を3案出してください。各案について次を併記します。
- 変更理由
- 盛り込んだ検索キーワードと、その裏付け数値・取得元（手順2で取得したもののみ）
- 削った情報とその理由
- 文字数（現行タイトルの文字数を併記して比較する）
制約:
- 訴求語の羅列は避けること。
- 根拠が現行カタログ（bullet_point / product_description / special_feature 等）に無い訴求は本文に入れず、「要ブランド確認」として別枠に出すこと。検索ボリュームが大きくても、カタログに根拠が無い効能・成分は入れないこと。
- タイトルの文字数上限・禁止表現は取得できません。現行タイトルの文字数を暫定の目安として使い、「カテゴリ別の文字数上限と禁止表現（薬機法・カテゴリ規約）は利用者側での確認が必要」と必ず明記すること。勝手に上限値を断定しないこと。


【出力】最後に次の3点を出力してください。
1. 推奨アクション — 3案の優先度（検索キーワード網羅性・訴求力の順）・期待効果（手順2の数値で示す）・確信度・リスクを明記する
2. 実行方法 — この結果はプロンプト 7「現行カタログと提案版を比較する」に渡す。カタログの実更新は行わない（提案までにとどめる）
3. 測定 — {{評価日（例: 反映2週間後）}}に該当ASINの検索順位（SQP）とCVRを再取得し、改善/悪化を判定する。Guardrail: 現行のasinCvrを下回らないこと

変更できる条件 — 対象 ASIN／評価日。

返ってくる内容 — 改善案 3 案 × 変更理由 × 盛り込んだキーワードの裏付け数値と取得元 × 削った情報の理由 × 文字数の比較 × 要ブランド確認事項。

このプロンプトで AI がやること — キーワードを推測で挙げさせないために、SQP（検索クエリパフォーマンス）から対象商品の実際の検索クエリを取得させ、各キーワードに検索ボリュームやインプレッションシェアの数値と取得元を併記させます。対象 ASIN が SQP に登録されていない場合は、アカウント全体の広告検索語句で代替したうえで「対象 ASIN 固有ではない」と明記されます。検索ボリュームが大きくても、カタログに根拠のない効能・成分は本文に入れず「要ブランド確認」に分けます。

設定変更 — 提案のみ（カタログの変更なし）。文字数・表記ルールはカテゴリーやマーケットプレイスで異なるため、反映前に Seller Central / Vendor Central の最新仕様を確認してください。

プロンプト 4: 箇条書き（Bullet Points）の改善案を作る

Section titled “プロンプト 4: 箇条書き（Bullet Points）の改善案を作る”

箇条書き（Bullet Points）はスマートフォンでは冒頭数行しか表示されないため、先頭に重要情報を置く構成が重要です。現行の箇条書きを診断し、改善案を提案します。

こんな時に使う — 先頭に重要情報を寄せた、読みやすい箇条書きにしたいとき。

実行前に必要な情報 — 対象 ASIN。マーケットプレイス（既定は日本）。

目的: 可読性と購入率向上のため、ASIN {{対象ASIN}} の現行カタログを取得して、Bullet Points の改善案を出してください。カタログの変更は行わず、提案までにとどめてください。


【カタログの取得】
1. まず call_picaro_api で POST /ai/catalog/item を呼んでください（body: {"asin": "{{対象ASIN}}", "market_place": "{{マーケットプレイス}}"}）。フィールド名は market_place（アンダースコア）です。marketplace と書くと 422 になります。
2. 返却された bullet_point は配列ではなく、改行(\n)区切りの1つの文字列です。必ず \n で分割してから「現行が何本あるか」「各本が何文字か」を数え、language_tags.bullet_point の要素数と一致することを確認して、その表を出力に含めてください。
3. product_description は空文字のことがあります。空なら「取得できたが空だった」と明記し、「説明が無い」と断定しないでください。A+ コンテンツはこのエンドポイントに含まれないため、A+ の記載を根拠にしないでください。


【改善案】
- 提案する Bullet Points の本数は現行の本数を超えず、かつ5本以内にしてください（Amazon の Bullet Points は通常5本まで）。
- 各 Bullet Point は「見出し：本文」の形式で、先頭に重要な情報を配置してください。
- 現行との対比（現行→提案）と変更理由を1本ずつ併記してください。
- 根拠が現行カタログ（タイトル・現行 Bullet・product_description・special_feature 等）にない訴求は本文に入れず、「要ブランド確認」として分けてください。
- Bullet Points の文字数上限は取得できません。提案した各本の文字数を明記したうえで、「上限はカテゴリ要件の確認が必要」と出力に明示してください。上限値を推測で書かないでください。
- 検索語句を根拠にキーワードを足す場合は、必ず analyze_sqp（対象商品の product_id）で実際に取得し、取得した語だけを使ってください。取得していない場合は「入れるべきキーワード」を書かないでください（推測になります）。


【カタログ取得ツールが失敗した場合】実際に呼び出したツール名と、そのツールが返したエラー内容のみを正確に報告してください。呼び出していないツール・エンドポイントについて「アクセス不可」「制約」等の説明を作ってはいけません。上記1が失敗した場合は、ほかの取得手段を探さず、改善案の作成を保留して、現行のタイトルと Bullet Points のテキスト（ブランド公式の説明）を貼り付けるようユーザーに依頼してください。


【出力の最後】採用時にそのまま次工程（登録用カタログデータの整形）へ渡せるよう、提案した Bullet Points を番号付きのプレーンテキストで、装飾なしにまとめて再掲してください。


【Measurement / Follow-up】反映後2〜4週間で、CVR とカート追加率の傾向を確認してください（analyze_sqp の asinCvr / asinAtc を同一 product_id・同一 frequency で反映前後の確定済み期間で比較）。

変更できる条件 — 対象 ASIN／マーケットプレイス。

返ってくる内容 — 現行の本数と各本の文字数の表、箇条書きごとの現行 → 提案の対比と変更理由、要ブランド確認事項、そして装飾なしで再掲された提案本文（次工程へそのまま渡せます）。

このプロンプトで AI がやること — 箇条書きは改行区切りの 1 つの文字列で返るため、まず分割して本数と文字数を数え、言語タグの要素数と一致するか検算させます。「見出し：本文」形式は Amazon（米国）の公式ガイドで推奨されている構成で、日本語カタログでも視認性の面で有効です。提案本数を現行以下かつ 5 本以内に制限しているのは、Amazon の箇条書きが通常 5 本までのためです。

設定変更 — 提案のみ（カタログの変更なし）。

プロンプト 5: 商品説明の改善案を作る

Section titled “プロンプト 5: 商品説明の改善案を作る”

商品説明（Product Description）を診断し、箇条書き（Bullet Points）との重複を避けつつ、購入判断に必要なストーリー・詳細情報を補う改善案を提案します。

こんな時に使う — 用途シーンや詳細仕様を補い、タイトル・箇条書きとの重複を避けたいとき。

実行前に必要な情報 — 対象 ASIN。マーケットプレイス（既定は日本）。

目的: 購入判断の材料を補い購入率を向上させるため、ASIN {{対象ASIN}} の現行カタログを取得して、
商品説明（product_description）の改善案を出してください。


【カタログ取得の手順】
call_picaro_api で下記を実行してください。
  method: POST / path: /ai/catalog/item
  body: {"asin": "{{対象ASIN}}", "market_place": "{{マーケットプレイス（既定: JP）}}"}
フィールド名は market_place（アンダースコア）です。marketplace と書くと 422 になります。
取得できたら product_name / bullet_point / product_description / special_feature /
product_benefit / safety_warning / size / item_dimensions / classifications /
product_images を根拠として使ってください。product_images は同一画像が複数解像度で返るため、
variant（MAIN / PT01…）で重複排除してから枚数を数えること。


【product_description が空文字だった場合】
language_tags.product_description が空配列なら「そのASINに商品説明が登録されていない」ことを意味し、
取得失敗ではありません。この場合は「現行との対比」ではなく新規作成として、Bullet Points と
上記カタログ属性のみを根拠に商品説明の初稿を作成し、冒頭に「現行の商品説明は未登録のため対比なし。
A+コンテンツへ移行している可能性があるため、A+ の内容と重複しないかブランド側での確認が必要」と
明記してください。A+ コンテンツはこの API では取得できません。


【出力に含めるもの】
- タイトル／Bullet Points と重複している記述の指摘（どの Bullet と重複しているかを明示）
- 改善案本文。用途・シーン・詳細仕様・購入前の疑問への回答を補う構成にする
- 現行との対比と変更理由
- 各記述の根拠区分を「カタログ実データ」「実績データ（使ったツール名と期間を明記）」「一般論」の
  3つに必ず書き分けて表示する
- 根拠が現行カタログにない訴求は本文に入れず、「要ブランド確認」として別枠にまとめる


【検索語句を根拠に使う場合】
一般論で済ませず、list_sqp_products で product_id を取得したうえで analyze_sqp を実際に実行し、
自社ATC率・CVRが市場平均を下回っている検索語句を特定してから、その語句が示す購入前の疑問に
答える構成にしてください。商品特性そのものが一致しない検索語句（用途違い・処方違い）は
「説明文では解決しない」として改善対象から除外し、その旨を明記すること。
ボトルネック分類が exposure_gap に偏っている場合は「商品説明の改善で動くのは CVR / ATC であり、
露出不足は解決しない」と必ず明記してください。


【ツールが失敗した場合】
実際に呼び出したツール名と、そのツールが返したエラー内容のみを正確に報告してください。
呼び出していないツール・エンドポイントについて「アクセス不可」等の説明を作ってはいけません。
上記のカタログ取得が失敗した場合に限り、改善案を生成せず、現行のタイトル・Bullet Points・
商品説明のテキストを貼り付けるようユーザーに依頼してください。


【カタログへの書き込みは行わないこと。】提案までにとどめ、反映はユーザーが行います。


【Measurement / Follow-up】反映後2〜4週間で、analyze_sqp の該当 ASIN の asinCvr（Primary KPI）
と asinAtc の傾向を、反映前のベースラインと比較して確認してください（「施策を記録・検証する」ページの効果測定プロンプト）。
直帰率・滞在時間は Amazon が出品者に提供しておらず Picaro でも取得できないため、Guardrail は
asinAtc の非悪化で代替してください。

変更できる条件 — 対象 ASIN／マーケットプレイス。

返ってくる内容 — タイトル・箇条書きとの重複指摘、改善案本文、現行との対比と変更理由、そして各記述の根拠区分（カタログ実データ / 実績データ / 一般論）の書き分け。

このプロンプトで AI がやること — 商品説明が空で返ったときに「説明が無い」と決めつけないよう、言語タグの要素数で「未登録」と「取得失敗」を区別させます。未登録なら対比ではなく新規作成に切り替わります。検索語句を根拠に使う場合は、自社の ATC 率・CVR が市場平均を下回っている語句に絞ります。ボトルネックが露出不足に偏っているときは「商品説明の改善では解決しない」と明示されるので、打ち手を取り違えずに済みます。

設定変更 — 提案のみ（カタログの変更なし）。

プロンプト 6: Item Highlights の改善案を作る

Section titled “プロンプト 6: Item Highlights の改善案を作る”

Item Highlights（special_feature / product_benefit）は、カンマ区切りの短いフレーズで商品の要点を伝える項目です。商品概要ブロックに「特徴」「商品の効能」として表示されます。現行値はカタログ取得 API から取得できます。

こんな時に使う — タイトルに入りきらない要点を、短いフレーズで補いたいとき。

実行前に必要な情報 — 対象 ASIN。比較対象にしたい同カテゴリーの自社 ASIN があれば併せて指定します。

目的：ASIN {{対象ASIN}} の商品ページ訴求力向上のため、Item Highlights（Amazon 出品属性の special_feature / product_benefit。商品概要ブロックに「特徴」「商品の効能」として表示される短い属性フレーズ）の改善案を作成します。提案までにとどめ、カタログへの変更は一切行わないでください。


【現行カタログの取得】
call_picaro_api で以下を呼び、現行値を一次ソースとして取得してください。
  method: POST / path: /ai/catalog/item
  body: {"asin": "{{対象ASIN}}", "market_place": "{{マーケットプレイス（例: JP）}}"}
※ フィールド名は market_place（アンダースコア）。marketplace だと 422 になります。
※ 現行カタログの取得経路はこの API だけです。ほかの取得手段を探さないでください。取得に失敗し、ブランド公式の説明（現行カタログのテキスト）も無い場合は、改善案を作成せずに保留してください。
取得したら次を必ず明示してください。
- 現行の special_feature / product_benefit の値と件数（0 件なら「未設定」と書く。空配列と未取得を混同しない）
- product_name / bullet_point / product_description の取得可否（product_description は空文字のことがあります。空を「説明が無い」と断定せず、取得できたか否かで書く）
- 参考として同一ブランドの比較対象 ASIN {{比較対象ASIN（同カテゴリの自社ASIN・任意）}} の special_feature / product_benefit も取得し、自社内での充足度を比較する


【提案の作り方】
- カンマ区切りの短いフレーズで、素材/用途/使用シーン/客観的な比較特徴を優先する
- product_name と重複する情報は入れない（重複判定に使った現行タイトルを明記する）
- 価格・配送・保証への言及、誇張表現、絵文字は入れない
- 提案フレーズごとに根拠区分を必ずラベルする
    [実データ] … 取得した bullet_point / product_description / 属性値に該当記述がある（該当箇所を引用する）
    [一般論]   … カタログ記述に根拠が無く、一般的なベストプラクティスに基づく
  実データの裏付けが無いフレーズを実データとして書かないこと。
- special_feature / product_benefit は Amazon 側で許容値が制限される場合があり、許容値一覧を返す手段は存在しません。比較対象 ASIN で実在が確認できた値を優先し、それ以外は「登録可否は Seller Central での確認が必要」とリスク欄に明記してください。


最後に次の3点を出力してください。
1. 推奨アクション — 提案フレーズごとに、根拠区分・どの購買判断要因を強化するか・優先度・確信度・リスクを明記する
2. 実行方法 — この結果はプロンプト 7「現行カタログと提案版を比較する」に渡す（本プロンプトではカタログを変更しない）
3. 測定 — {{評価日（例: 反映2週間後）}}に商品ページの転換指標を再取得し、改善が無ければ表現を見直す。取得手段が無い指標を測定計画に書かないこと

変更できる条件 — 対象 ASIN／比較対象 ASIN／評価日。

返ってくる内容 — カンマ区切りフレーズ形式の改善案 × 各フレーズの根拠区分（[実データ] / [一般論]）× タイトルとの重複チェック結果 × 登録可否の要確認事項。

このプロンプトで AI がやること — 現行の特徴属性の値と件数をまず明示させ、0 件のときは「未設定」と書かせます（未取得と混同させないため）。同じブランドの別 ASIN を比較対象に取ることで、自社内での充足度を測れます。特徴属性は Amazon 側で許容値が制限されることがあり、許容値の一覧を返す手段がないため、比較対象 ASIN で実在が確認できた値を優先し、それ以外は登録可否を要確認として残します。

設定変更 — 提案のみ（カタログの変更なし）。

プロンプト 7: 現行カタログと提案版を比較する

Section titled “プロンプト 7: 現行カタログと提案版を比較する”

プロンプト 3〜6 で作った改善案を、現行カタログと項目別に並べて比較します。承認判断・ブランド確認に回すためのレビュー資料になります。

こんな時に使う — 社内レビューやブランド確認に、現行と提案を並べた資料を回したいとき。

実行前に必要な情報 — 対象 ASIN。同じ会話でプロンプト 3〜6 の提案が出ている状態で使います。

目的：承認判断を素早く行うため、直前の改善提案（タイトル / Bullet Points / 商品説明 / Item Highlights）を対象に、現行カタログとの比較表を作成します。


【提案版（比較表の右側）の入手】
提案版は前工程（プロンプト 3〜6）の出力です。工程間で成果物を自動的に受け渡す仕組みはありません。
同一チャット内に前工程の出力が残っていない場合は、比較を開始せず、対象ASINと改善提案の全文の提示を依頼してください。
提案版を推測・再生成して比較表を埋めることは禁止します。


【現行版（比較表の左側）の取得】
現行カタログは call_picaro_api で取得してください。
  method: POST / path: /ai/catalog/item / body: {"asin": "{{ASIN}}", "market_place": "{{MARKETPLACE}}"}
  ※ フィールド名は market_place（アンダースコア）です。marketplace では422エラーになります。
項目の対応は タイトル=product_name / Bullet Points=bullet_point（改行区切り）/ 商品説明=product_description です。
- bullet_point は配列でなく改行区切りの1つの文字列で返ります。改行で分割して本数を数え、language_tags.bullet_point の要素数と一致することを確認してください。
- product_description が空文字で返ることがあります。「商品説明が無い」と断定せず「取得結果は空（A+へ移行している可能性）」と記載してください。language_tags.product_description の要素数を見れば「未登録」と「取得失敗」を判別できます。
- A+コンテンツはこのレスポンスに含まれません。A+を根拠にした比較を行わないでください。
- 画像数を併記する場合は product_images を variant（MAIN / PT01〜）で重複排除してから数えてください（1画像が3解像度で返るため、そのまま数えると3倍になります）。
- Item Highlights はプロンプト 6 と同じ定義（special_feature / product_benefit）で扱ってください。この2フィールドはレスポンスに含まれ、それぞれ language_tag 付きの配列として複数値を返します。「取得不可」とは書かないでください。値が空配列のときは「未設定」と記載し、未取得と混同しないでください。なおこの2フィールドの許容値一覧を返す手段はないため、提案値の登録可否は「Seller Central での確認が必要」と要確認事項に残してください。
- 取得したASINの brand を確認し、対象が自社商品であることを確かめてください。


【出力】
項目（タイトル / Bullet Points / 商品説明 / Item Highlights）ごとに
現行 / 提案 / 変更理由 / 期待する効果 / 要確認事項 / 現行値の取得可否 を併記した比較表にまとめてください。
取得できた項目と取得できなかった項目は必ず区別して記載してください。
「要ブランド確認」等のフラグが残っている項目は、確認完了までは承認済みとして扱わないでください。
承認済み項目のみを次工程に進めてください。


この結果を使う次のプロンプト: プロンプト 8「承認済みの改善案を登録用データに整形する」

変更できる条件 — 対象 ASIN／マーケットプレイス／比較する項目の範囲。

返ってくる内容 — 項目別の 現行 / 提案 / 変更理由 / 期待する効果 / 要確認事項 / 現行値の取得可否 の比較表。社内レビューやブランド確認への回付にそのまま使えます。

このプロンプトで AI がやること — 提案版は前工程の出力であり、工程間で自動的に受け渡す仕組みはありません。同じ会話に前工程の出力が残っていない場合、AI は比較を始めず提示を求めて止まります（推測で比較表を埋めさせないため）。現行版は改めてカタログ取得 API から読み直すので、比較表の左側は常に実データです。要ブランド確認のフラグが残っている項目は、承認済みとして次工程に進みません。

設定変更 — 提案のみ（カタログの変更なし）。

プロンプト 8: 承認済みの改善案を登録用データに整形する

Section titled “プロンプト 8: 承認済みの改善案を登録用データに整形する”

人の確認・承認が済んだ改善案を、Seller Central / Vendor Central に登録しやすい形式に整形します。自動アップロードや無確認での反映は行いません。 登録作業は必ず人が Seller Central / Vendor Central 上で行います。

こんな時に使う — 承認済みの改善案を、登録作業しやすい形に整えたいとき。

実行前に必要な情報 — 登録先（Seller Central / Vendor Central）。対象 ASIN。承認済みの改善案が同じ会話にある状態で使います。

目的：承認済みのカタログ改善案を、実際の登録作業に使える形に整形します。
前提：Picaroからカタログへの登録・反映は実行できません。この成果物は、担当者が{{登録先（例: Seller Central）}}の編集画面またはフラットファイルに手で貼り付けるためのデータです。整形までを行い、登録は行わないでください。


入力：{{承認済みの改善案（前工程の比較表で承認された項目）}}
この入力が会話上に提示されていない場合は、改善案を推測・生成せず、提示を求めて停止してください。


手順：
1. {{対象ASIN}}の現行カタログ情報をPicaroのカタログ取得で取得し、根拠として使う値（商品名・箇条書き・商品説明・商品タイプ・カテゴリ・特徴属性・識別子・画像）を控えてください。取得できなかった項目は「取得できず」と明記し、推測で埋めないでください。
   - 商品説明が空で返ることがあります。空を「説明が無い」と断定せず、取得できたか否かを分けて書いてください。
   - 画像は同一画像が複数解像度で返るため、variantで重複排除してから枚数を数えてください。
   - A+コンテンツは取得範囲に含まれません。A+側の表現に関わる項目はその旨を明記してください。
2. 承認済みの改善案を、現行値と対応づけて登録用テキストに整形してください。変更しない項目は「現行のまま維持」と明示してください。


以下を分けて出力してください：
- 【登録用データ】項目別の登録用テキスト（貼り付けてそのまま使える。理由や注記を混ぜない）
- 【レビュー用データ】変更理由（変更前→変更後と対応づけて）
- 【レビュー用データ】根拠として使用した商品情報（取得元と取得日、使用したフィールド、取得できなかったもの）
- 確認が必要な表現（法務・薬事・ブランドの確認フラグ付き）
- 反映前の確認事項チェックリスト


チェックリストには次を必ず含めてください：
- 商品タイプごとの必須属性・入力欄の仕様は{{登録先}}側で確認する（Picaroからは取得できません）
- 変更しない項目に意図しない上書きが入っていないか反映画面で差分確認する
- 反映前の現行値を控えとして保存する（ロールバック用）
- 反映日を記録し、効果測定の起点にする


登録後{{評価日（例: 2週間後）}}に該当ASINのCVRを再取得し、改善が無ければ表現を見直してください。CVRはASINによって取得できない場合があるため、反映前に対象ASINのCVRが取得できるかを確認し、取得できない場合は代替指標と、その指標が商品ページCVRとは異なることを明記してください。
この結果を使う次のプロンプト: 「施策を記録・検証する」ページの効果測定プロンプト

変更できる条件 — 登録先（Seller Central / Vendor Central）／対象 ASIN／評価日。

返ってくる内容 — 項目別の登録用テキスト（そのまま貼り付けられる形）と、理由・根拠・確認フラグ付きのレビュー用データ、そして反映前チェックリスト。

このプロンプトで AI がやること — 登録用データとレビュー用データを混ぜないよう分けて出力します。承認済みの改善案が会話に無い場合は、推測で生成せずに提示を求めて止まります。チェックリストには「変更しない項目に意図しない上書きが入っていないか」「反映前の現行値をロールバック用に控える」「反映日を効果測定の起点として記録する」が必ず含まれます。

設定変更 — 整形のみ（アップロード・反映は行いません）。文字数制限・入力項目・カテゴリー別テンプレートは Seller Central と Vendor Central で仕様が異なり変更されることもあるため、反映前に必ず登録先の最新仕様を確認してください。反映は人が手動で行います。

関連カテゴリ

Section titled “関連カテゴリ”