広告戦略を立案する

このページでは、ACoS や入札の戦術調整より一段上、ブランド戦略・予算配分・CAC / LTV といったマネジメント層が見たい判断材料を作れます。広告効率だけでなく、ファネル全体・商品ライン横断・新規顧客獲得の視点で、月次〜四半期の戦略レビュー向けに分析します。

このページの基本情報

項目	内容
このページでできること	Sponsored Ads の実績から、ファネル分解・ブランド構造・予算配分シミュレーション・ASIN 別収益といった戦略レベルの判断材料を一覧化する
対象	Sponsored Ads（SP / SB / SD）。各プロンプトはスポンサープロダクト広告（SP）を中心に扱います。Amazon DSP・AMC は別ページ（下記の note を参照）
必要なデータ・接続	Picaro が保持する Sponsored Ads の実績データ（接続済みアカウントであれば追加設定は不要）。ただしプロンプト 5・9 は AMC（Amazon Marketing Cloud）のデータも使うため、AMC 未接続のアカウントでは実行できません
実行範囲	分析のみ・提案のみ（読み取り専用）。予算配分の配分案も提案までで、広告設定は変更しません。実際の予算・入札・キーワードの変更は関連ページの承認フローで行います

CTR（クリック率）… 広告が表示された回数のうち、クリックされた割合。
CVR（購入率）… クリックのうち、購入につながった割合。
ACoS（広告費用対売上高比率）… 広告費 ÷ 広告経由売上。低いほど効率がよい。
ROAS（広告費用対効果）… 広告経由売上 ÷ 広告費。高いほど効率がよい。
CAC（新規顧客獲得単価）… 新規顧客 1 人を獲得するのにかかったコスト。
LTV（顧客生涯価値）… 1 人の顧客が生涯にもたらす売上・利益。
NTB（新規ブランド顧客, New-to-Brand）… 過去一定期間に自社ブランドを買っていなかった新規の顧客。
ROI（投資対効果）… かけた費用に対して得られた利益の割合。Picaro は利益指標を保有しないため、このページのプロンプトは ROI ではなく ROAS または広告貢献額で算出します。

このページのプロンプトは、次の注意点を本文に明記しています。プロンプトを書き換える場合も、内容は残してください。

消化率など「膨らむ」指標は自分で正規化する — budgetUtilizationRate など一部の指標は「期間合計 ÷ 1 日分の値」で返り、期間が長いほど日数倍に膨らみます（実測で最大 29 倍）。必ず「期間合計 ÷（日予算 × 実効日数）」で計算し直してください。
当日・未確定日は集計から除外する — rollup_status は未出稿の広告タイプが 1 件あるだけで日全体が no_data に落ちるため、確定判定には使えません。レポート別の status を見て fully_missed の日を除外してください。
CTR / CVR は同一ソースの clicks で計算する — ツールをまたいで指標を混ぜると分母がずれます。get_dashboard は clicks を返さないため、この計算には使わないでください。
退役キャンペーン（old_ を含む名称など）が「増額推奨」に混入することがある — optimize_budget 等の提案をそのまま使わず、キャンペーン名で除外してください。
数値が書式付き文字列（¥1,691,946 / 112.8% 等）で返ることがある — 四則演算の前に記号を除去してください。文字列のままソートしないでください。
ASIN 別の指標はデータソースを 1 つに固定する — get_amc_ntb_by_asin の DSP / Sponsored Brands 行は ad_spend が常に 0 になる既知の欠陥があるため、Sponsored Products 行のみを使ってください。
analyze_search_term_contribution は period_first＝前期・period_second＝当期の順で渡す — 逆に渡すと change / contribution の符号が反転します。同ツールの change（bps）・change_value（パーセンテージポイント）・change_ratio（相対変化率）は単位が異なるため、どの単位かを必ず明記してください。アカウント全体の寄与度は返りません（total.contribution は --）。行の contribution を合計して代用しないでください。
get_change_history の 0 件を「変更なし」と断定しない — エラーの出ない 0 件は「変更が無かった」と「履歴を取得できていない」を区別できません。90 日を超える開始日は自動で 90 日前に切り上げられます。
get_placement_summary は当期分のみ返る — 前期と比較するには 2 回に分けて取得してください。「Rest of Search」は Home / Off-Amazon / Placement Rest of Search / Site Amazon Business の 4 種を合成した値です。

こんな時に使います

新規構築の前に、既存のキャンペーン構成を棚卸しして命名衝突や重複を避けたい
どのファネル段階（表示 → クリック → 注文）がボトルネックかを見極めたい
自社ブランド名を含むキーワードと一般語のキーワードで、どちらが効率よく売れているか比較したい
ACoS だけでは見えない不採算の要因を、CAC / LTV や新規顧客の視点で説明したい
追加予算をどのキャンペーンに配るのが最適か、シミュレーションしてから配分したい
ASIN 単位で広告貢献額（売上 − 広告費）や、クリックされているのに売れていない商品を見極めたい

実行前に確認すること

接続先のアカウント … 複数アカウントを扱う場合は、対象アカウントが合っているか先に確認します。
対象期間 … 「過去 30 日」など。長期トレンドを見る戦略分析では 30 日以上を推奨します。当日・前日は未確定のことがあるため、確定済みの直近期間が安全です。
対象ブランド・ASIN・ポートフォリオ（任意） … 特定の範囲に絞りたい場合に指定します。指定しなければ接続中アカウント全体が対象です。
目標 ACoS / ROAS を売上・広告費・ACoS の目標を設定するで登録しておくと、「効率がよい／悪い」の判定基準が自動で使われます。

プロンプト早見表

やりたいこと	分かること・作られるもの	設定変更	プロンプト
新規構築の前に既存の SP キャンペーン構成を棚卸しする	キャンペーン名・ステータス・日予算の一覧と命名衝突の注意	変更なし	プロンプト 1
ファネル段階別にボトルネックを見つける	ファネル × キャンペーン別のパフォーマンス表	変更なし	プロンプト 2
自社ブランド名を含むキーワードと一般語のキーワードで効率を比べる	Brand 群 vs Generic 群の集計と ASIN ランキング	変更なし	プロンプト 3
不採算の要因を顧客視点で説明・改善提案する	不採算対象 × CAC / 想定 LTV × 改善提案の表	変更なし	プロンプト 4
新規顧客を増やす予算追加の配分案がほしい	配分先 × 配分額 × 実測 NTB CAC の表	変更なし	プロンプト 5
既存キャンペーン内で予算追加分の最適配分を知る	キャンペーン × 推奨配分額 × 実績 ROAS の表	変更なし	プロンプト 6
予算が消化されない原因を分析する	未消化対象 × 想定原因 × 対処方針の表	変更なし	プロンプト 7
イベント前後の予算配分案を検索ファネル別に作る	ファネル × リード期 / 当日 / フォロー期の配分表	変更なし	プロンプト 8
ASIN 別に広告貢献額を計算する	ASIN × 売上 × 広告費 × 広告貢献額の表	変更なし	プロンプト 9
主要 ASIN のパフォーマンスサマリーを取得する（期間合計）	ASIN × 広告売上 / 広告費 / 広告販売個数 / ROAS の表	変更なし	プロンプト 10
クリック率は高いが購入率が低い ASIN を特定する	ASIN × CTR × CVR × 平均比 × 原因仮説の表	変更なし	プロンプト 11
悪化した指標の原因を要因ごとに切り分ける	検索語句 / 入札 / CPC / CVR / 予算 / 掲載枠別の寄与度と対応の優先順位	変更なし	プロンプト 12

現状の構成と成果を分析する

プロンプト 1: 既存キャンペーン構成を確認する

新規構築の前段階として、参照中の広告プロフィールに紐づく SP キャンペーン一覧を取得し、命名衝突と重複構築を回避します。

こんな時に使う — 新しいキャンペーンを作る前に、既存の構成を棚卸しして命名衝突や重複構築を避けたいとき。

実行前に必要な情報 — 広告プロフィール ID（接続済みのプロフィール ID。1 件だけ接続している場合は自動で参照されます）。

広告プロフィール {{広告プロフィールID（例: 3528945248353716）}} に紐づくスポンサープロダクト広告のキャンペーン一覧を出して。
新規構築前の命名衝突チェックと重複構築の確認用に使う。

ステータス・日予算を表示して（作成日はPicaroがAPIから取得できないため対象外。必要な場合はAmazon広告コンソールのCSVを案内して）。

取得件数が総件数と一致することを確認し、一致しない場合は期間指定などで再取得して。既存キャンペーンと同一・類似名があれば候補として明示して。

この結果を使う次のプロンプト: スポンサープロダクト広告（SP）を新規構築する

変更できる条件 — 対象の広告プロフィール ID。

返ってくる内容 — キャンペーン名・ステータス・日予算の一覧表と、似た名前があるときの注意書き。

設定変更 — 変更なし（読み取り専用）。Amazon 広告側には何も書き込みません。

次にすること — 構成を確認したら、新規作成はスポンサープロダクト広告（SP）を作成する、命名ルールの整備はラベルと命名ルールで広告を分類するを使います。

プロンプト 2: ファネル別にパフォーマンスを分解する

検索ファネル KPI（インプレッション → クリック → 注文）を参照し、過去期間のキャンペーンをファネルステージ別に分解したパフォーマンスレポートを作成します。

こんな時に使う — 表示・クリック・注文のどの段階で取りこぼしているか、ボトルネックを見極めたいとき。

実行前に必要な情報 — 対象期間（例: 過去 30 日、2026-04）。

直近{{対象期間（例: 過去30日）}}のSPキャンペーンについて、インプレッション・クリック・注文数からCTRとCVRをキャンペーン別に算出し、ファネルのどの段階がボトルネックかを特定してください。
目的: ボトルネックの段階を特定し、改善の優先順位を決めるため。

データ取得（必須・単一ソース）
- インプレッション / クリック / 注文数は**必ず同一ソースから同時に取得**する。
  `start_existing_sp_campaigns_job`（from_date / to_date 指定）→ `get_mcp_job_status` が
  `truncated=false` になったのを確認 → `get_mcp_job_result` で全キャンペーン行を取得する。
  同期で足りる場合は `analyze_ad_type_performance`（campaign_types=["SP"]）の `campaign_rows` でもよいが、
  `top_n` は**ROAS降順固定**なので取得漏れが無いか `source_row_count` と突き合わせること。
- **CTR も CVR も分母/分子に clicks を含むため、複数ツールをまたいで取得してはいけない。**
  `get_dashboard` は clicks を返さない。別ツールの CVR フィールドは**注文点数（販売個数）ベース**で
  注文数ベースより過大に出るため使わない。**必ず自分で orders ÷ clicks を計算する。**
- 期間を指定したら、レスポンスが返した期間が要求と一致しているか毎回確認する。

確定データの扱い
- 取得前に `get_data_ingestion_status` を実行し、`fully_missed` の日（通常は当日）を**期間から除外**する。
  除外しないと指定日数が無警告で1日短くなる。未確定日は0埋めの行を返し実績0と区別できないため、
  `rollup_status` を確定判定に使わない。実際に集計した日数を出力に明記する。

算出と健全性チェック
- CTR = clicks ÷ impressions、CVR = orders ÷ clicks。**比率を出すたびに分子・分母・日数を明示**する。
- 基準値（平均）は個別行の平均ではなく、**同一取得の全体合計**から算出する
  （全体CTR = 全体clicks ÷ 全体impressions、全体CVR = 全体orders ÷ 全体clicks）。
- 健全性チェックを行い、結果を明記する:
  (a) **CVR が100%を超える行が無いか**（あれば注文点数ベースの列を掴んでいるので除外し、注文数ベースに切り替える）
  (b) 行の合計が全体合計と一致するか（不一致なら取得打ち切りを疑う）
  (c) 注文数が特定期間だけ大幅に欠損していないか（平均注文単価が他期間と桁違いなら欠損を疑う）
  欠損期間を「CVRがボトルネック」と判定してはいけない。
- **統計的な下限を設ける**: impressions {{最小インプレッション（例: 50000）}} 未満、
  または clicks {{最小クリック（例: 200）}} 未満の行は「著しく低い」の判定対象から外し、
  「サンプル不足」として別枠で列挙する（少数クリックのCVRは大きく振れるため）。
- 両段階の母集団が同一であることを確認する（CTRのclicksとCVRのclicksが同じ値であること）。

ボトルネック判定と並び順
- 各キャンペーンについて CTR不足率 =（全体CTR − 当該CTR）÷ 全体CTR、
  CVR不足率 =（全体CVR − 当該CVR）÷ 全体CVR を求め、大きい方をボトルネック段階とする。
- 影響度 = impressions × 不足率（大きい方）。**影響度の降順**に並べ、上位 {{件数（例: 10）}} 件を出す。

出力
1. 前提 — 集計期間（実日数）・データソース・全体CTR/全体CVR（分子・分母つき）・対象キャンペーン数（実績のある数／全数）・健全性チェックの結果
2. ボトルネック一覧 — キャンペーン名／段階（CTR or CVR）／impressions／clicks／orders／CTR／CVR／不足率／影響度
3. 推奨アクション — CTR側ならクリエイティブ・入札・検索語句の見直し、CVR側なら商品ページ・価格・在庫の見直しを、
   対象・優先度（影響度順）・期待効果・確信度・リスクとともに提示。
   **期待効果は「当該キャンペーンのCTR（またはCVR）が全体平均まで回復した場合の増分クリック数・増分注文数」として計算し、根拠の数式を併記する**（推測値を書かない）。
   **確信度は clicks 数と不足率の大きさから 高／中／低 の3段階で機械的に付ける**（判定基準を明記する）。
   リスクには Guardrail KPI として **ACoS の悪化許容上限 {{ACoS上限（例: 現状比+5ポイント）}}** を必ず含める。
4. 実行方法 — 入札見直しは、提案をユーザーが確認・承認してから反映することとし、商品ページ課題はリスティング担当への確認依頼とする（このプロンプトでは変更を実行しない）
5. 測定 — 「施策の効果測定」を使い、{{評価日（例: 実施4週間後）}}に**本プロンプトと同一のソース・同一の計算式で**CTR/CVRを再取得して改善を確認する。
   施策前後の値と、Guardrail KPI（ACoS）が上限内かを併記する。
   ⚠ 変更履歴APIは実質的に空を返すため、**再取得した変化を施策の効果と断定できない**。
   施策の実施内容・実施日は実行者が別途記録しておくこと。

変更できる条件 — 対象期間。

返ってくる内容 — ファネルステージ × キャンペーン × インプレッション / クリック / 注文 / CVR / ACoS の表と、ボトルネック段階の特定。

設定変更 — 変更なし（分析のみ）。

次にすること — クリック段階が弱ければカタログを診断して改善案を作る、注文段階が弱ければ入札単価を調整するを検討します。

プロンプト 3: 自社ブランド名を含むキーワードと一般語のキーワードで成果を比較する

キャンペーン名から Brand（自社ブランド名を含むキーワード）と Generic（一般語のキーワード）を判別し、最も成果の良い ASIN 群を特定します。

こんな時に使う — 指名検索と一般語検索のどちらが効率よく売れているかを比べ、注力先を決めたいとき。

実行前に必要な情報 — なし（そのまま使えます）。

全 SP キャンペーンを確認し、名称に Brand キーワード相当が含まれるものと
Generic キーワード相当が含まれるものを比較して、
最も成果（ROAS / ACoS / 売上）の良い ASIN 群を特定して。

変更できる条件 — 比較する指標（ROAS / ACoS / 売上）。

返ってくる内容 — Brand 群 vs Generic 群の集計表と、ASIN 別パフォーマンスランキング。

設定変更 — 変更なし（分析のみ）。

次にすること — Brand / Generic の判別精度はキャンペーン名の付け方に依存します。精度を上げたい場合はラベルと命名ルールで広告を分類するプロンプト 6 で命名ルールを整えてください。

用語補足 — Brand キーワードは自社ブランド名を含む指名検索向けのキーワード、Generic キーワードはブランド名を含まない一般語のキーワードを指します。

プロンプト 4: 不採算の要因を CAC と LTV の視点で分析する

ACoS だけでは見えない不採算の要因を CAC（新規顧客獲得単価）/ LTV（顧客生涯価値）視点で分解し、改善提案を返します。まだどれが問題か絞れていないときに、不採算対象そのものを広告貢献額の低さから探すプロンプトです（対象と悪化指標がすでに分かっている場合はプロンプト 12「悪化した指標の原因を 6 つの要因に切り分ける」を使ってください）。

こんな時に使う — ACoS が高い対象について、単なる効率悪化なのか顧客獲得への投資なのかを切り分けたいとき。

実行前に必要な情報 — 対象期間（例: 過去 90 日。長期トレンドを見るため 30 日以上を推奨）。

直近 {{対象期間（例: 過去90日）}} の不採算キャンペーン / 不採算 ASIN を特定して、
原因を CAC / LTV 視点で説明して。
改善提案を ACoS 軸ではなく顧客視点で出して。

変更できる条件 — 対象期間。

返ってくる内容 — 不採算キャンペーン × CAC / 想定 LTV / 改善提案の表。

設定変更 — 変更なし（分析・提案のみ）。

次にすること — 改善提案を予算・入札に落とし込むときは予算を調整するや入札単価を調整するの承認フローで実行します。対象と悪化した指標が絞れている場合は、先にプロンプト 12「悪化した指標の原因を 6 つの要因に切り分ける」で要因を切り分けてから実行します。

用語補足 — LTV は Picaro が持つ売上履歴からの推定値です。

予算配分とブランド構造をシミュレーションする

プロンプト 5: 新規ブランド顧客を増やす予算追加の配分案を作る

新規顧客（NTB, New-to-Brand）を増やす目的で、予算追加分の配分案を提示します。

こんな時に使う — 追加予算を、既存顧客の刈り取りではなく新規顧客の獲得に振り向けたいとき。

実行前に必要な情報 — 追加する予算額（例: ¥500,000）。

広告予算を{{追加予算（例: ¥500,000）}}追加する場合に、NTB（新規顧客）増加を最大化する配分案を作成してください。
目的: 追加予算をNTB獲得効率の高いキャンペーンに配分し、新規顧客獲得を最大化するため。
対象: {{対象広告タイプ（例: SPのみ）}}の稼動中キャンペーン。

【ステップ0｜予算が制約になっているかを最初に判定する（必須・省略しない）】
- start_existing_sp_campaigns_job → get_mcp_job_status → get_mcp_job_result で稼動中キャンペーンの dailyBudget と期間 spend を取得する（同期版 list_existing_sp_campaigns は応答が大きすぎて失敗しうる）。
  ポートフォリオ単位の粗い判定で十分な場合は get_portfolio_budget_summary でもよいが、その場合は下記の分母・分子の非対称に注意する（spend は全 state 合計、daily_budget_sum は ENABLED のみ）。
- 応答の budgetUtilizationRate をそのまま使わない。 これは「期間spend ÷ 1日分のdailyBudget」で、期間日数の分だけ膨らむ。必ず 真の消化率 = 期間spend ÷ (dailyBudget × 期間日数) を自分で計算し、分子・分母・日数を明示すること。dailyBudget=0 の行は同キーが欠落するので0と読み替えない。
  🔴 膨らみの規模を見誤らないこと。実測では31日の窓でツールが「消化率2694%」「1288%」「1015%」のような値を返し、日数で割るとそれぞれ 86.9% / 41.5% / 32.7% になった。正規化前の値は100%を超えていても何の意味もない。
- 真の消化率が{{制約とみなす消化率（例: 80%）}}以上のキャンペーンが1件も無い場合、予算は制約になっていない。この場合は配分表を作らず、「予算追加ではNTBは増えない。ボトリネックは入札・ターゲティング・露出である」と結論し、アカウント全体の真の消化率を分子・分母・日数つきで示して終了する。

【ステップ1｜NTB効率の実測（ステップ0で制約ありと判定された場合のみ）】
- get_amc_metric(metric_name="campaign_attribution") を使う。campaign_id 別に ntb_purchases と total_spend があり、実測NTB CAC = total_spend ÷ ntb_purchases を計算できる。
- 🔴 max_rows_per_table を必ず渡す。 省略すると先頭数行のサンプルだけが返り truncated: true になる。全キャンペーンのNTB CACを並べるには全行必須。tables[].row_count 以上の値を渡し、truncated: false になったことを確認してから集計する。サンプルだけで並び順を作らない。
- 🔴 件数は tables[].row_count（選択された run の行数）を使う。 metadata.tables.*.list_row_count は全 run 横断の件数で、実測では前者の約10倍の値だった。この2つを混同しない。
- get_amc_new_customer は使わない（ブランド×月次のみでキャンペーン軸が無く、配分に使えない）。
- get_amc_ntb_by_asin を配分根拠に使わない（広告タイプ単位で ad_spend が全行0になる既知欠陥。total_dsp_spend も按分されていない定数）。
- campaign_attribution の窓は固定の長期累積である。返却された report_start_date / report_end_date を必ず明記し、直近実績と混同しない（実測では約2年分の累積で、数週間の変化は完全に埋没する）。
- ステップ0の稼動中キャンペーンのうちAMC行が無いものは「NTB CAC算出不能」として除外し、除外件数を明示する。広告費0の広告タイプも同様に比較対象から除外する（0を「広告費ゼロで新規獲得できている」と解釈しない）。
- 🔴 campaign_attribution は DSP 行を含む。{{対象広告タイプ}}で絞る場合は ad_product_type で行を選別し、除外した広告タイプと件数を明記する。DSP は SP と NTB CAC の桁が大きく違うことがあるので、混ぜて並べた場合は広告タイプを行ごとに併記する。

【ステップ2｜配分案】
- 真の消化率が制約水準に達しているキャンペーンだけを配分先候補にする。
- キャンペーン × 現在の日予算 × 真の消化率 × 配分額 × 実測NTB CAC × ACoS実績 を表で併記し、実測NTB CACの低い順に並べる。
- 「想定NTB増加数」を断定値として出さないこと。 追加予算1円あたりのNTB増加を推定できるデータ（限界CAC・予算弾力性・予算起因の機会損失インプレッションシェア）はMCPに存在しない。過去の平均NTB CACで追加予算を割ると増加数を桁で過大申告する。数値が必要な場合のみ「実測NTB CACが限界CACと等しいと仮定した場合の上限値」と明記し、仮定であることと、指名/Branded面では成立しないことを必ず添える。

【Guardrail】
- 既存キャンペーンの日予算を現状の日予算額の{{下限（例: 80%）}}未満に削らない（消化率でなく日予算額に対する比率）。
- ACoSは{{基準期間（例: 直近30日）}}の実績比{{上限（例: +3pt）}}を超えないこと。ACoSは取得元により乖離するため、取得元を1つに固定して明記する。
- check_budget_status が unconfigured、またはポートフォリオが NO_CAP のアカウントでは、CAP起因の制約は判定対象外である旨を明記する。
  🔴 unconfigured のとき check_budget_status は cap だけでなく ad_spend も null を返す（実測）。このツールを広告費の取得元にしない。

【出力・承認】
- 変更内容の一覧（キャンペーン・現在日予算・変更後日予算・差額・実測NTB CAC・ACoS）を提示し、承認を得るまで媒体に反映しない。
- 予算の差額合計を効果額として提示しない。optimize_budget の items には id / label / current_value / recommended_value / reason しか無く、spend / sales / estimated_impact は存在しない（実測で確認）。差額は効果ではない。
- optimize_budget を併用する場合は target_acos を明示的に渡す（未指定はハードエラーで proposal が生成されない）。応答の target_acos_goal_resolution に渡した値と source が記録されるので、それを出力に引用する。ただし同ツールはNTB軸を持たず、増減判定が上記の膨らんだ消化率に基づくため、NTB最大化の根拠には使わない。
  🔴 さらに同ツールは {{対象広告タイプ}} に絞れない（実測で SP / SB / SBV / SD が混在して返った）し、キャンペーン名が old_ で始まる退役キャンペーンを「増額推奨」として提示する（実測で2件）。提案をそのまま並べない。生成した proposal は承認しない限り必ず cancel する。

【実行後】
- 提案内容をユーザーが確認・承認したうえで反映し、{{評価日（例: 4週間後）}}に 「施策の効果測定」で再評価する。
- 再評価に使えるのは campaign_attribution_monthly（campaign_id×月次のNTB）と広告側のACoS。同テーブルに spend 列が無いためNTB CACの前後比較はできないこと（実測で確認: 返るのは purchase_uv / ntb_uv / repeat_uv / total_purchases / ntb_purchases / repeat_purchases / product_sales のみ）、spendを持つ campaign_attribution は長期累積窓のため数週間の変化が埋没することを、評価設計時に明記する。
- 🔴 2つのテーブルを campaign_id で結合するのはよいが、広告タイプの列名と値の表記が違う。campaign_attribution は ad_product_type（実測値: SPONSORED_PRODUCTS / DSP）、campaign_attribution_monthly は ad_type（実測値: sponsored_products / DSP）。文字列の完全一致で結合しない（大文字小文字が揃っていない）。
- get_change_history は変更履歴を返さないことがあるため、実施内容は別途記録しておく（manage_measure の施策ログに登録するのが筋）。
- 判定は Keep/Expand/Adjust/Pause/Revert/Investigate から選ぶ。

【データ境界】
- 当日は未取込（fully_missed）で、指定期間が無警告で1日短くなる。期間は前日までで切り、実際に集計した日数を明記する。
- rollup_status を確定判定に使わない（未出稿の広告タイプ1件で日全体が no_data に落ちる）。

【実行条件】
- AMCのcampaign_attributionが取得できないアカウントでは、NTB CACの算出を行わず「AMC未対応のためNTB効率での配分は試算不可」と明記する。

変更できる条件 — 追加する予算額。

返ってくる内容 — 配分先キャンペーン × 配分額 × 実測 NTB CAC（新規顧客獲得単価）の表。並び順は実測 NTB CAC の低い順です。「想定 NTB 増加数」は、Picaro に限界 CAC・予算弾力性のデータが無いため断定値としては出ません。数値が必要な場合のみ「実測 NTB CAC が限界 CAC と等しいと仮定した場合の上限値」という仮定付きの参考値として示されます。

設定変更 — 変更なし（提案のみ）。配分案を作るだけで、予算は変更しません。

次にすること — 配分を実行するときは予算を調整するの承認フローで反映します。

プロンプト 6: 既存キャンペーン内での予算追加の最適配分を求める

既存 SP キャンペーン内で予算追加分をどこに配分するのが最適かをシミュレーションします。

こんな時に使う — 新規キャンペーンを増やさず、既存キャンペーンの中で追加予算を最も効く場所に配りたいとき。

実行前に必要な情報 — 対象ブランド名（任意、絞り込み用）、追加する予算額（例: ¥1,000,000）。

目的: 追加予算を最も広告経由売上への貢献が見込めるキャンペーンに配分し、アカウント全体の
ROASを改善するため、{{対象ブランド名（例: ○○ブランド）}} の既存キャンペーンに
{{追加予算（例: ¥1,000,000）}} を追加する場合の配分先を検討してください。
{{追加予算の単位（例: 期間総額 / 日額）}} を明示してから計算してください（Picaroが扱うのは
日予算なので、単位が変わると結論が桁違いに変わります）。

【対象の特定】
{{対象ブランド名}} を list_accounts のアカウント名で解決し、以後すべてのツール呼び出しに
account_id を明示的に渡してください。キャンペーンにブランド属性は無く、ポートフォリオは
製品ライン単位なので、ブランドで直接絞れない場合は「アカウント全体を対象にした」と明記して
ください。配分先からは次を必ず除外し、除外件数を明記してください。
- 🔴 終了済(ENDED)ポートフォリオ配下のキャンペーン
  ※ get_portfolio_budget_summary は include_ended=false を渡しても ENDED 行を返す。
    実測では include_ended=false で 8 行の ENDED ポートフォリオが返り、いずれも spend=0 なのに
    daily_budget_sum と active_campaign_count は非ゼロ（合計で日予算約50万円弱・稼動キャンペーン約50件）。
    これを除外しないと消化率の分母だけが膨らみ、アカウント全体が不当に「予算余力あり」に見える。
    各行の status / is_ended を確認して自分で除外すること。
  ※ 逆に、ENDED ポートフォリオの中に state=ENABLED のキャンペーンが存在する（実測で確認）。
    キャンペーンの state だけでは判定できないので、必ずポートフォリオ側の status と照合する。
- {{対象広告タイプ（例: SPのみ / SP+SB+SD）}} 以外の広告タイプ
  ※ get_portfolio_budget_summary と optimize_budget は広告タイプの指定を受け付けない。
    前者は source_contract.ad_type_scope="all_ad_types" を宣言しており、後者は実測で SP / SB / SBV / SD を
    混在させて返した。SP に絞りたい場合はキャンペーン単位のツールで選別すること。
- 🔴 キャンペーン名に old_ 「コピー」を含む退役キャンペーン
  ※ optimize_budget はこれを「増額推奨」として提示する（実測で old_ キャンペーン２件が増額推奨に入っていた）。
    ツールの提案をそのまま並べないこと。

【期間と確定データ】
{{対象期間（例: 直近30日）}} で集計してください。集計前に get_data_ingestion_status で
確定状況を確認し、未確定日（fully_missed 等）があれば除外し、実データが何日分あるかを
明示してください。「30日」と指定しても実力29日になることがあります。
rollup_status を確定判定に使わないでください（未出稿の広告種別が1件あるだけで日全体が
no_data に落ちる）。レポート別の status を見てください。

【予算制約が実在するかの確認 — 最初に必ずやること】
「追加予算の配分先」は、既存キャンペーンが日予算で頭打ちになっている場合にのみ存在します。
まずアカポート全体とキャンペーン単位で 正規化日予算消化率 を出してください。

    正規化日予算消化率 = 期間広告費 ÷ (日予算 × 実データ日数)

- 分子・分母・日数を必ず明示してください。
- ツールが返す消化率(budgetUtilizationRate や optimize_budget の「消化率」)は、
  窓が2日以上のとき日数で割られておらず、日数倍に膨らみます。そのまま使わないでください。
  必ず上式で自分で計算し直してください。
  🔴 膨らみの規模: 実測では 31 日の窓でツールが「消化率 2694%」「1288%」「1015%」を返し、
     日数で割ると 86.9% / 41.5% / 32.7% だった。同じ実測で、ツールが「予算不足」と判定した
     35 キャンペーンのうち、正規化後に 100% に達したものはゼロ。
- 🔴 get_portfolio_budget_summary を使う場合は、分子と分母の母集団が違うことに注意してください。
  source_contract が宣言しているとおり spend_scope="all_states"（全 state の実支出合計）に対して
  control_scope="ENABLED_only"（daily_budget_sum と active_campaign_count は ENABLED のみ）。
  この非対称により消化率は体系的に高く出ます。どちらの母集団を使ったかを明記し、
  制約の有無を判定するのに使う場合は「高めに出てこの値」として読んでください。
- optimize_budget を使う場合は target_acos を明示的に渡してください
  （未設定アカウントでは指定しないとハードエラーになります）。応答の
  target_acos_goal_resolution に渡した値と source が記録されるので、それを出力に引用してください。
- 正規化消化率がどのキャンペーンでも十分低い（例: 概ね{{予算制約とみなす消化率の下限（例: 70%）}}
  未満）場合は、「予算は制約になっていないので追加予算の配分先は無い」と結論し、
  制約が入札・ターゲット網羅・在庫のどこにあるかを次アクションとして提示してください。
  無理に配分先を作らないでください。
- CAP（月次上限）による制約は別系統です。check_budget_status が unconfigured、または
  ポートフォリオが全件 NO_CAP（cap_amount 0）の場合は、CAP起因の制約は判定対象外である旨を
  明記してください。unconfigured のとき check_budget_status は cap だけでなく ad_spend も null
  を返すので、このツールを広告費の取得元にしないでください。

【配分先の抽出（予算制約が実在した場合のみ）】
正規化消化率が高い（予算で頭打ち）× ACoSが低い × 実績ROASが高い、の3条件でキャンペーンを
抽出してください。インプレッションシェアはキャンペーン単位では取得できません
（ターゲット単位のIS%しか無く、ターゲット別インプレッションが返らないため加重集計も
できません）。IS を判断材料にする場合は、ターゲット単位の値であることと、集計していない
ことを明記してください。

【提示】
キャンペーン × 推奨配分額 × 直近実績ROAS（広告経由売上÷広告費）を、Impact順に提示して
ください。次を厳守してください。
- 予算の増減差分を、効果額・売上増加額・捻出額として扱わないでください。
  日予算を下げても実支出がもともと日予算を大きく下回っている場合、実削減額は¥0です。
  optimize_budget の items には spend / sales / estimated_impact が存在しないことを実測で確認しています。
- 追加予算に対する期待効果額・限界ROASはPicaroから取得できません。 実績ROASは
  過去実績であって追加予算に対する限界ROASではない旨を明記し、推定値を断定しないでください。
- 「Picaroは利益指標を保有しないため、ROIでなくROASまたは広告貢献額で算出」を守ってください。

【Guardrail】
- まず現状のアカウント全体ACoSを算出して明示してください（出所ツール名も併記。
  出所により数pt乖離します）。
- 配分後もアカウント全体のACoSが {{ACoS上限（例: 20%）}} を超えないようにしてください。
- ただし現状ACoSが既に上限を超えている場合は、提案を全棄却せず、
  「現状ACoSを悪化させないこと」を実効ゲートに切り替え、上限との乖離を併記してください。
- 既存の高ROASキャンペーンの予算は削らないでください。

【実行と測定】
提案は承認後に反映してください（自動実行はしないでください）。予算変更は入札変更とは
別系統なので、予算反映用の承認フローを使ってください。検証のために optimize_budget で
proposal を生成した場合は、承認しない限り必ず cancel してください。
反映{{測定までの日数（例: 7日）}}後にACoSとROASを再取得し、改善していればKeep、
悪化していればRevertを提案してください。再取得時も、比率は分子・分母・日数を明示し、
未確定日を除外してください。

変更できる条件 — 対象ブランド名／追加する予算額。

返ってくる内容 — キャンペーン × 推奨配分額 × 直近実績 ROAS（広告経由売上 ÷ 広告費）の表。Picaro は利益指標を保有しないため ROI では算出しません。差額を効果額・売上増加額として扱わない旨と、実績 ROAS は過去実績であって追加予算に対する限界 ROAS ではない旨が明記されます。

設定変更 — 変更なし（提案のみ）。配分案を作るだけで、予算は変更しません。

次にすること — 配分を実行するときは予算を調整するの承認フローで反映します。

プロンプト 7: 予算が消化されない原因を分析する

ポートフォリオやキャンペーンが予定通りに予算消化されていない理由を説明します。

こんな時に使う — 予算枠を確保しているのに使い切れていない原因を切り分けたいとき。

実行前に必要な情報 — 対象ブランド名、対象ポートフォリオ名（未指定なら全体）。

{{対象ブランド名（例: ○○ブランド）}} の {{対象ポートフォリオ名（例: ○○ポートフォリオ）}} が予定通りに予算消化されていない
理由を説明して。原因（入札が低い / 表示シェアが足りない / マッチタイプの絞り込みすぎ など）を
分けて提示して。

変更できる条件 — 対象ブランド名／対象ポートフォリオ名。

返ってくる内容 — 未消化キャンペーン × 想定原因（入札の高さ / 表示シェア / マッチタイプ / 競合の強さ）× 対処方針の表。

設定変更 — 変更なし（分析のみ）。

次にすること — 入札が原因なら入札単価を調整する、予算枠が原因なら予算を調整するの承認フローで対処します。

プロンプト 8: イベント前後の予算配分案を検索ファネル別に作る

セールやキャンペーンイベントの前後で、リード前後の予算配分案を検索ファネル別（調査 / 比較 / 購入直前）に作成します。

こんな時に使う — セールに向けて、事前の認知づくりから当日の刈り取りまで予算のかけ方を変えたいとき。

実行前に必要な情報 — 対象ブランド名、イベント日（例: 2026-07-15）。

{{対象ブランド名（例: ○○ブランド）}}の{{イベント日（例: 2026-07-15）}}のセール／割引について、リード期／イベント期／フォロー期の3区間でSP予算配分案を作成してください。
目的: イベント前後の需要変動に合わせてSP予算配分を最適化し、機会損失を防ぐため。
対象: 当該ブランドの全SPキャンペーン。ただし state=ENABLED のみを対象とし、PAUSED／ARCHIVED、キャンペーン名に「コピー」「old_」を含むものは除外して、除外件数を出力に明記してください。
※ 🔴 state=ENABLED でも、そのキャンペーンのポートフォリオが ENDED のことがあります（実測で確認）。キャンペーンの state だけでなく、get_portfolio_budget_summary の status / is_ended と照合して除外してください。

■区間の決め方
1. まず manage_event を action=list（読み取りのみ。登録・更新はしない）で呼び、{{イベント日（例: 2026-07-15）}}を含む、またはその日を開始日とするイベントを特定してください。イベントは単日でなく date と end_date を持つ期間です。見つかった場合は「イベント期 = date〜end_date」とし、見つからない場合はイベント期を{{イベント日（例: 2026-07-15）}}の1日として、その旨を明記してください。
2. リード期 = イベント開始日の{{日数（例: 7日）}}前〜開始日の前日。フォロー期 = イベント終了日の翌日〜{{日数（例: 3日）}}後。
3. 同じ manage_event の一覧で、リード期・フォロー期が他の登録イベント（先行セール等）と重なっていないかを確認してください。重なる場合は、その日を除外するか、重なったまま使う旨を必ず出力に書いてください。
   🔴 重なりは例外でなく規則です。 大規模セールは「先行セール」と「本体」が連続して登録されているのが普通なので（実測で確認）、本体の開始日をイベント日に取るとリード期がほぼ必ず先行セールに食い込みます。この場合は「リード期のうち○日は先行セール期間であり、平時のリード期とは読めない」と明記し、除外するか別区間として切るかを選んで理由を書いてください。
4. 各区間の日付範囲と実日数を出力に必ず書いてください。

■確定データの扱い
- get_data_ingestion_status を対象期間で呼び、status が fully_missed の日を各区間から除外してください。未確定日は0埋めの行を警告なしで返すため、含むと「イベント後に配信が止まった」と誤読します。
- rollup_status を確定判定に使わないでください。未出稿の広告種別が1つあるだけで日全体が no_data になります。レポート別の status を見てください。
- 除外した日数と、除外後の各区間の確定実日数を明記してください。

■区間比較のルール
- 区間の長さが揃わないため、すべての金額・件数を「1日あたり」に正規化してから比較してください（区間合計 ÷ その区間の確定実日数）。
- 比率を出すたびに、分子・分母・日数を明示してください。
- 生の区間合計どうしの比較は出力に載せないでください。正規化の有無で増減の符号が反転しえます。

■代理指標
「検索ファネル」はPicaroに存在しないフィールドのため、ブランドKW／ジェネリックKW／ASINターゲットの区分を代理指標として使い、各区間で比重を変えてください（例: リード期はジェネリック比率を高め、イベント期はブランドKWを強化）。取得手順は次のとおりです。
- list_existing_sp_campaigns を name_filter で区分ごとに呼び、coverage_complete と be_total_results を確認して母集団を全走査したことを担保してください。応答には matched_count / scanned_campaign_count / be_total_results / coverage_complete / pages_fetched が返ります。
  🔴 name_filter の結果には PAUSED / ARCHIVED が含まれます（実測で 18 件中 3 件が PAUSED）。各行の state を見て自分で除外し、除外件数を明記してください。
  🔴 キャンペーン名の区切り文字が半角 | と全角 ｜ で混在します（実測で確認）。name_filter 自体は NFKC 正規化で両方を拾いますが、キャンペーン名を自分で分割して区分を判定する場合は両方の区切り文字を扱ってください。 片方だけで分割すると一部のキャンペーンが「未分類」に落ちます。
- 得た campaign_id を analyze_ad_type_performance の campaign_ids に渡し、campaign_types=["SP"] と各区間の period_start／period_end を指定して、区間別に集計してください。
- 🔴 analyze_label_kpi は使わないでください。 ラベル軸（competitor／generic／branded）はSaaS正本ですが frequency が weekly／monthly のみで、1日や3日の区間を切れません。
  実測での挙動: 4 日間（4/13 まで）を指定して呼んだと、応答の period は要求したままの 4 日間をエコーしてきながら、値はその月全体の広告費の約 45% に相当する大きさで返ってきました（数週分相当）。警告もなく、エコーされた期間も要求と一致するので、応答を見てスナップを検知する手段がありません。 区間分析に使ってはいけません。
  なおラベル軸に ASIN ターゲットの区分は存在しないことも実測で確認済みです。だからキャンペーン名を代理指標にします。
- 命名規則に乗らないキャンペーン（Catch All、Category、AUTO 等）は「未分類」として別掲し、未分類の広告費構成比を必ず出力に明記してください。この比率が大きいほど代理指標の信頼度は下がります。
- 代理指標である旨と、その根拠がキャンペーン名（運用者の命名）でありSaaSのラベル正本でないことを、出力に明記してください。

■出力
- 区間 × 区分のマトリックスで、確定実日数・1日あたり広告費・1日あたり広告経由売上・ACoS・広告費構成比を示してください。
- 各区間の想定予算配分比率（区分別・合計100%）を併記し、現状比率からの増減ptを書いてください。
- 変更内容の一覧（区間・キャンペーン・現行日予算・提案日予算・差額）を提示してください。ただし差額を効果額・捻出額として提示しないでください（実支出が日予算を大きく下回っている場合、日予算を下げても実削減額は¥0です）。

■Guardrail
- 平時ベースライン = manage_event の一覧で登録イベントと1日も重ならない直近の連続{{日数（例: 7日）}}間とし、自動で決めた期間を出力に明記してください（ユーザーが期間を指定した場合はそちらを優先）。確定済み日の範囲内で選んでください。
- ACoS の取得元を1つに固定してください（既定: analyze_ad_type_performance の campaign_types=["SP"]）。同一期間でも取得元により数pt異なるため混在させず、使用した取得元を出力に明記してください。
- アカウント全体のACoSが平時比{{上限（例: +5pt）}}（パーセンテージポイント）を超えない範囲で配分してください。この上限が、上で固定した取得元・平時期間のACoSに対する加算である旨を出力に書いてください。

実行前に必ず: 変更内容の一覧（区間・キャンペーン・配分額）を提示し、承認を得るまで媒体に反映しないでください。このプロンプトでは配分案の提示までとし、予算の書き込みは行いません。
実行後: 提案内容をユーザーが確認・承認したうえで反映し、「施策の効果測定」を使って各区間終了後にACoSと広告経由売上を取得し、目標未達なら次区間の配分をAdjustしてください。

実行条件
- 各区間の日数はイベント特性に応じて調整可能とし、変更した場合はその日数を明記する
- optimize_budget を配分の根拠に使う場合は target_acos を必ず指定する（未指定はエラーになり提案が生成されない）。同ツールはSB／SD／SBV を含みSPに絞れないし（広告タイプの引数がそもそも存在しない）、消化率が期間長に比例して膨らむため、消化率をそのまま引用せず「区間合計 ÷（日予算 × 確定実日数）」に正規化して使うこと
  🔴 さらに同ツールはキャンペーン名が old_ で始まる退役キャンペーンを「増額推奨」として提示します（実測で2件）。上の除外ルールに従って落としてください。生成した proposal は承認しない限り必ず cancel してください

変更できる条件 — 対象ブランド名／イベント日／リード期・フォロー期の日数／ACoS 上限。

返ってくる内容 — 区間（リード期 / イベント期 / フォロー期）× 区分（ブランド KW / ジェネリック KW / ASIN ターゲット）のマトリックス表。「検索ファネル」は Picaro に存在しないフィールドのため、この区分を代理指標として使う旨が明記されます。

設定変更 — 変更なし（提案のみ）。配分案を作るだけで、予算は変更しません。

次にすること — 配分を実行するときは予算を調整する、施策として記録するときは施策と外部イベントを記録して効果を検証するを使います。

ASIN 単位で収益と成果を分析する

プロンプト 9: ASIN 別に広告貢献額を計算する

SP 広告の売上から広告費を差し引いて、注文あたりの広告貢献額を計算します。

こんな時に使う — ASIN 単位で広告の貢献度を見て、注力商品と絞る商品を決めたいとき。

実行前に必要な情報 — 対象期間（確定済みの暦月。例: 2026-07）。

目的: ASIN別の広告貢献度を可視化し、投資配分の是正判断につなげるため。

データソース（固定・変更しない）
- ASIN別の広告経由売上・広告費は `get_amc_ntb_by_asin`（AMC NTB by ASIN）を唯一の出所とする。`max_rows=5000` で最新 run を全件取得し、`returned_row_count / selected_row_count` を網羅率として本文に明記する。
- `ad_product_type == "sponsored_products"` の行だけを対象にする。同ツールの DSP 行と sponsored_brands 行は `ad_spend` が全行 0 で、そのまま貢献額を計算すると「広告費ゼロで売れている」と誤読するため必ず除外する。
- `list_top_asins_by_metric` は「広告が当たったターゲットASIN」軸であり自社商品の母集団ではない（他社ブランドのASINが上位に混在する）。この分析には使わない。
- get_dashboard / analyze_ad_type_performance など他ツールの売上・広告費と混ぜない。

対象期間: {{対象暦月（例: 2026-07）}}
- このソースの最小粒度は暦月（`report_month`）で、「過去30日」のような任意窓は切れない。指定は必ず確定した暦月にする。
- 応答の `report_end_date` が対象月の末日より前なら、その月は未確定なので対象にせず、直前の確定暦月に切り替えたうえでその旨を明記する。

前処理
- `asin == "below_reporting_floor"` の行は実ASINと同じ `asin` 列に混在する集約行なので除外し、除外した金額が対象月SP広告経由売上の何%かを明記する。
- `ad_spend == 0` の行は「広告費ゼロ」ではなく欠損として扱い、貢献額を算出せず件数を明記する。

算出: ASIN別に「広告経由売上（attributed_revenue）－広告費（ad_spend）＝広告貢献額」と「注文1件あたり広告貢献額（広告貢献額 ÷ total_purchases）」を算出してください（実利益ではなく広告貢献額である旨を明記する）。

分析: 広告貢献額がマイナスのASINを、広告費の大きい順に最大10件抽出してください。あわせてマイナスASINの合計広告費・合計貢献額と、それが対象月SP広告費に占める割合も出してください。

最後に次の3点を出力してください。
1. 推奨アクション — 広告貢献額がマイナスのASINは入札引下げまたは予算縮小の候補とする。ただし同一ソース・同一期間の広告経由売上（attributed_revenue）上位10%のASINは縮小候補から除外する（アカウント全体の総売上ランキングはASIN単位で全件列挙できないため、ガードレールの母集団は本ソース内に固定する）
2. 実行方法 — 提案をユーザーが確認・承認してから反映する（このプロンプトでは実行しない）
3. 測定 — 「施策の効果測定」を使い、翌確定暦月に同一手順で広告貢献額を再取得し、改善していればKeep、悪化していればRevertと判断する（ASIN軸の日次・週次ソースが存在しないため、7日後ではなく暦月サイクルで測る）

実行条件
- 「広告貢献額」は粗利・利益ではない。原価やAmazonフィーを含む実利益とは混同しない
- 本ソースの広告経由売上はAMCのクリーンルーム集計で、キャンペーン単位ツールの広告売上とは母集団も帰属も異なる。両者の金額を並べたり差分を語ったりしない

変更できる条件 — 対象暦月。

返ってくる内容 — 広告貢献額がマイナスの ASIN 上位 10 件 × 広告費 × 広告貢献額 × 注文 1 件あたり広告貢献額の表。データソースは AMC の get_amc_ntb_by_asin（Sponsored Products 行のみ）に固定されます。

設定変更 — 変更なし（分析のみ）。

次にすること — 縮小候補への対応は予算を調整するや入札単価を調整する、低い商品の商品ページ改善はカタログを診断して改善案を作るを使います。

用語補足 — 「広告貢献額」は粗利・利益ではありません。原価や Amazon フィーを含む実利益とは混同しないでください。原価率・粗利を加味しない、広告費に対する売上貢献の目安として使う指標です。

プロンプト 10: 主要 ASIN のパフォーマンスサマリーを取得する

主要 ASIN について、直近の確定した暦週を対象に、広告売上 / 広告費 / 広告販売個数 / ROAS を ASIN 単位でまとめて取得します（Picaro では ASIN 別の日次データは取得できないため、期間合計での集計です）。

こんな時に使う — 注目している複数の商品の直近の成果を、まとめて一覧で確認したいとき。

実行前に必要な情報 — 対象 ASIN 一覧（例: B0XXXXXXXX, B0YYYYYYYY。複数指定可）、対象期間（直近の確定した暦週。例: 直近 1 週）。

目的: 複数ASINの広告パフォーマンスを一覧化し、異常ASINの早期発見につなげるため、
{{対象ASIN一覧（例: B0XXXXXXXX, B0YYYYYYYY）}} について {{対象期間（直近の確定した暦週。例: 直近1週）}}
の広告売上／広告費／広告販売個数／ROASを1ASIN1行で集計してください。

【期間の決め方 — 必ずこの順で行うこと】
1. get_data_ingestion_status で未確定日（fully_missed）を数え、確定している最終日を特定する。
   rollup_status ではなくレポート別の status を見る（未出稿の広告種別1件で日全体が no_data に落ちる）。
2. 🔴 このエンドポイントは期間を暦週へスナップする。日単位の指定は効きません。
   実測で確認済み: from_date/to_date を 1 日ずらして2回呼んだと、全項目が完全に同一の値で返ってきました
   （同じキャンペーンで ads_sales / ads_units / clicks / impressions が1円・1件も違わない）。
   しかも実効期間を示すフィールドは応答にないので、応答を見てスナップを検知できません。
   → よって対象は必ず「直近の確定した暦週」とし、前期はその1つ前の暦週とする。
   → 参考にしたい場合のスナップの検出方法: 同じASINで from/to を 1 日ずらして2回呼び、
     値が完全一致したら「スナップしている（日単位の指定は効いていない）」と判定できます。
3. call_picaro_api で POST /bigquery/sales-ranking（body: {"amazon_account_id": <account_id>,
   "frequency": "weekly"}）を呼び、応答の from_date / to_date に表示される週の範囲で
   当期・前期の週境界を確認する。
4. 集計に使う from_date は必ず日曜、to_date は必ず土曜にすること。
   週境界に揃っていない期間を渡すと、近い週にスナップするか複数の暦週が無警告で合算されます。
   実際に使った日付と日数を必ず出力に書くこと。

【取得方法】
- 各ASINについて call_picaro_api で POST /product-analysis/product-detail/ad
  （body: {"amazon_account_id": <account_id>, "from_date": "<当期の日曜>",
  "to_date": "<当期の土曜>", "code": "<ASIN>", "type": "asin"}）を呼び、
  応答の total から ads_sales / ads_spend / ads_units / roas を取る。
- 前期は同じ呼び出しを前週の日曜〜土曜で行う。
- 一括取得の口は無いため、ASIN 1件ごとに呼び出すこと。
- 🔴 total は「返したページ内の合計」であって全体合計ではありません。
  実測で確認済み: page_size を 1 にして呼んだと、total_count は 17 のままなのに
  total は先頭1キャンペーン分だけの値になりました（全体の約4分の1）。
  → page_size を指定しない（既定20）か、total_count 以上にして 1 ページで取り切る。
  → total を読む前に、pagination.total_count と items の件数が一致していることを必ず確認し、
     両方を出力に記載する。一致しないまま total を使わない。
- 「売上」はROASの分子と揃えるため広告売上（ads_sales）を使い、総売上とは混同しないこと。
- 🔴 このエンドポイントでは purchases と ads_units が全行で同値です（実測で全キャンペーン確認）。
  つまりここで取れるのは販売個数であって注文数ではないので、出力の列名は「広告販売個数」とし、
  「広告注文数」と書かないでください。cvr も ads_units ÷ clicks なので販売個数ベースです。
- 応答の数値はすべて書式付き文字列（"¥1,691,946" / "733" / "112.8%"）で返ります。
  四則演算する前に ¥ ・カンマ・% を除去し、文字列のままソートしないでください。

【異常判定】
- 前週と比較し、ROASの相対変化率が {{ROAS悪化の閾値（相対変化率・例: -20%）}} 以下の
  ASINをフラグしてください。
- 相対変化率 =（当期ROAS − 前期ROAS）÷ 前期ROAS で必ず自分で計算すること。
  ツールが返す change_percentage は「%ポイントの差」なのに "%" 付きで表示されるため、
  そのまま閾値判定に使ってはいけない。
- ROAS 欄は百分率表記（実測: "112.8%"）で倍率ではないので、分母・分子を揃えてから比すこと。
- 比率を出すたびに、分子・分母・対象日数を明示すること。

【欠損の扱い】
- 存在しないASINも、実在するが広告出稿の無いASINも、どちらも 0件（全項目 "--"）で
  返り、エラーも警告も出ません。
- 入力したASIN件数と、値が取得できた行数を必ず突き合わせ、取得できなかったASINを
  「データなし（実績0か対象外かは判別不能）」として別掲すること。件数が合わないまま
  一覧を確定しないこと。
- ※ ASIN の実在確認が必要な場合は、別途 SKU 逆引きツールまたは商品一覧（child-asin）で
  登録の有無を確認できます。これにも出ない ASIN は「未登録」として分けて書いてください。

【出力】
- 1ASIN1行の表（広告売上／広告費／広告販売個数／ROAS当期／ROAS前期／相対変化率）
- 集計に使った当期・前期の実日付と日数、および両期間が同じ週長であること
- ASINごとの pagination.total_count と items 件数（total を使ってよい根拠）
- フラグしたASINの一覧（0件ならその旨）
- 取得できなかったASINの一覧

フラグされたASINは、「原因診断」で詳細分析の対象としてください。
次回、対象週が確定したあとに再集計し、フラグしたASINのROASが改善したか確認してください。
確定済み期間でも再取込で値が変わりうるので、前回値と違ってもそれだけで不具合と断定しないこと。

変更できる条件 — 対象 ASIN 一覧／対象期間／ROAS 悪化とみなす閾値。

返ってくる内容 — ASIN × 広告売上 / 広告費 / 広告販売個数 / ROAS（当期・前期・相対変化率）の一覧表と、前期比で悪化した ASIN のフラグ。対象期間は暦週にスナップされるため、日単位の任意指定はできません。

設定変更 — 変更なし（分析のみ）。

次にすること — 日次の全体 KPI を見たいときはダッシュボードで KPI を確認するを使います。

プロンプト 11: クリック率は高いが購入率が低い ASIN を特定する

CTR（クリック率）は高いが CVR（購入率）が低い ASIN を特定します（広告は引きが強いが商品ページで離脱しているケース）。

こんな時に使う — 広告でクリックは取れているのに売上につながらない商品を見つけ、商品ページ改善の優先度を決めたいとき。

実行前に必要な情報 — 対象期間（例: 過去 30 日）。

目的: 広告のクリック獲得は強いのに購入に至っていないASINを特定し、リスティング改善の優先度をつける。

データソース（1つに固定する。他ソースと混在させない）
- ASIN単位の impressions / clicks / ads_units / ads_spend / purchases / sessions / glance_views /
  stock_status / sellable_inventory / buy_box_percentage / org_cvr / ads_cvr は
  call_picaro_api の POST /product-analysis/product-list/child-asin から取得する。
  body: {amazon_account_id, product_line_id: 0（0 = 全商品ライン。省略や他の値だと一部ラインしか返らない）,
         from_date, to_date, frequency: "daily", page, page_size: 40}
  ※ page_size を大きくすると応答が80KBで無警告に切り捨てられる。page_size=40 で total_pages まで全ページ取得すること。
  ※ 応答の pagination に page / page_size / total_count / total_pages が入る。total_count を対象ASIN数の分母に使う。
- 🔴 数値はすべて書式付き文字列で返る。 例: "¥59,959,000" / "25,000" / "35.9%" / "0.66%"。
  四則演算する前に ¥ ・カンマ・% を除去し、"--" は null（ゼロでない）として扱う。
  例外として sellable_inventory / sku_quantity は生の数値。文字列のまま比較・ソートしない。
- アカウント平均は同じ応答の total ブロックを使う（自分で平均を再計算しない）。
- 網羅性の検算: 全ページの impressions / clicks / ads_spend の合計が total と一致することを確認し、一致率を明記する。
  一致しなければ取得漏れとして報告する。

期間
- {{対象期間（例: 過去30日）}}。ただし日数を決め打ちしない。
- 先に get_data_ingestion_status を呼び、status が completed の最終日を確定日とする。
  fully_missed / in_progress の日は窓に含めない（含むと窓が無警告に短くなり広告費が過少に出る）。
  rollup_status を確定判定に使わない（未出稿の広告種別1件で日全体が no_data に落ちる）。レポート別の status を見る。
- 実際に集計した開始日・終了日・日数を必ず出力に書く。

指標の定義（この定義以外を使わない。すべて同じ応答内のフィールドから組む）
- CTR = clicks ÷ impressions（応答の ctr と一致することを検算する）
- 広告CVR（販売個数ベース）= ads_units ÷ clicks（応答の ads_cvr と同義）
  ⚠ これは「販売個数 ÷ クリック」であり注文数ベースではない。1注文で複数個売れると実際の注文ベースCVRより高く出る。
  出力では必ず「販売個数ベース・広告帰属」と明記する。
- 全体CVR（販売個数ベース）= total_units_sold ÷ glance_views（応答の cvr と同義）
- 🔴 全体CVR（注文ベース）= purchases ÷ glance_views — これは取得できる。
  purchases は注文数（オーガニック＋広告の合計）で、total_units_sold は販売個数。両方同じ行に返る。
  分母はツール自身の cvr と揃えるため glance_views を使い、アカウント平均も total ブロックの
  purchases ÷ glance_views で同じ式で算出する（sessions を分母にすると別の値になるので混同しない）。
  ※ 注文ベースの「広告帰属」CVR は取得できない（ads_units に対応する ads_purchases 相当のフィールドがない）。
    「広告の転換」は販売個数ベース、「商品・リスティングの転換」は注文ベースで見ると割り切る。
- 上記のうちどの定義を使ったかを指標ごとに表の列名に書く。定義の違うCVRを同じ列に混ぜない。

母集団と最小サンプル
- impressions が "--"（null）の行は「広告実績なし」でなく「データ無し」。0 と区別し、母集団から除外して件数を明記する。
- impressions = 0 の行は未配信。CTR/CVR は 0% でなく「算出不能」として除外する。
- 統計的に無意味な行を除くため、impressions ≥ {{最小impressions（例: 10000）}} かつ clicks ≥ {{最小clicks（例: 200）}}
  を満たす行だけを判定対象にする。除外した行数と、除外しなければ該当していた行を必ず併記する。

抽出条件（{{閾値}}の意味を一意に固定する）
- CTR > アカウント平均CTR、かつ
- 広告CVR（販売個数ベース）≤ アカウント平均広告CVR × {{閾値（例: 50%）}}
  ※「CVR下位{{閾値}}」という順位ベースの解釈はしない。閾値の実数値（アカウント平均CVR × 閾値）を出力に明記する。
- 抽出後、各件について注文ベースの全体CVRも併記し、販売個数ベースと同じ方向に低いかを確認する。
  方向が違う場合は「1注文あたりの購入個数の違いによる見かけ上の差」の可能性を明記する。

原因の切り分け（取得できるものは仮説にしない）
- 在庫: stock_status / sellable_inventory と get_fba_inventory を突合する。
  ⚠ get_fba_inventory は現時点のスナップショット（coveragePeriod は直近1週間）であり、
    対象期間中ずっと在庫があったことは証明できない。「現時点で在庫あり」までしか書かない。
- 価格競争力: buy_box_percentage を必ず出す。100%未満なら「価格/カート獲得の問題」として事実ベースで指摘する
  （これは仮説でない）。ただし実測では大半のASINが 99% 台に張るので、アカウント平均（total ブロック）
  との差で評価し、数ptの差を主因として誇張しない。
- リスティングか広告ターゲティングかの切り分け: org_cvr（オーガニックCVR）を併記する。
  org_cvr もアカウント平均を大きく下回るなら商品・リスティング側の問題、
  org_cvr が正常で広告CVRだけ低いなら広告ターゲティング側の問題として区別する。
  ※ org_cvr = org_units ÷ org_click で、これも販売個数ベース。広告CVRと同じ基準なので直接比較できる。
- 画像/レビュー本文は取得できないため「仮説」と明記し、事実として断定しない。

出力
- 広告費投下額が大きい順に最大5件。該当が5件未満ならその件数だけを出し、「該当○件」と明記する。0件なら0件と書く（水増ししない）。
- 各件について: ASIN / 商品名 / CTR / アカウント平均CTR / 広告CVR（販売個数）/ アカウント平均 /
  閾値実数 / 全体CVR（注文ベース）/ impressions / clicks / ads_units / purchases / 広告費 /
  在庫 / buy_box_percentage / org_cvr。
- 比率を出すたびに分子・分母・集計日数・母集団の網羅率を併記する。

最後に次の3点を出力する。
1. 推奨アクション — 在庫切れが原因のものは即時対応、buy_box低下は価格・カート要因として是正依頼、
   それ以外はリスティング担当への確認依頼とする
2. 実行方法 — 広告側の停止・入札変更は、ユーザーが確認・承認してから反映することとし、
   リスティング課題は担当部門への確認依頼とする
3. 測定 — 「施策の効果測定」を使い、対処7日後に同じソース・同じ定義でCVRを再取得し改善を確認する

実行条件
- 画像/レビューは仮説であり事実として断定しない
- CVR は必ず基準（販売個数 / 注文）と帰属（広告のみ / 全体）の両方を毎回明記する
- 取得できなかった行・除外した行を必ず件数で開示する（0件と未取得を混同しない）
- 確定済み期間でも再取込で値が変わりうる。再測定時に値が違ってもそれだけで改善/悪化と断定しない

変更できる条件 — 対象期間／CVR 判定の閾値。

返ってくる内容 — ASIN × CTR × 広告 CVR（販売個数ベース）× アカウント平均比 × 全体 CVR（注文ベース）× 在庫 × buy_box_percentage × org_cvr の表（広告費の大きい順に最大 5 件）。在庫・価格競争力は実データで確認し、画像・レビューは「仮説」と明記して事実と区別します。

設定変更 — 変更なし（分析のみ）。

次にすること — 商品ページ改善の優先順位付けにはカタログを診断して改善案を作る、在庫の確認には在庫と販売機会を管理するが使えます。

プロンプト 12: 悪化した指標の原因を 6 つの要因に切り分ける

対象のキャンペーン・ポートフォリオと悪化した指標がすでに分かっているとき、原因を検索語句 / 入札 / CPC / CVR / 予算 / 掲載枠の 6 分類に切り分け、寄与度の高い要因から対応の優先順位をつけます。プロンプト 4「不採算の要因を CAC と LTV の視点で分析する」がどれが問題かをまだ絞れていないときに対象そのものを探すのに対し、このプロンプトは対象と悪化指標がすでに分かっているときに、なぜ悪化したかを切り分けるためのものです。

こんな時に使う — 特定のキャンペーン・ポートフォリオで指標が悪化していることは分かっているが、検索語句・入札・CPC・CVR・予算・掲載枠のどれが主因か切り分けたいとき。

実行前に必要な情報 — 対象キャンペーン・ポートフォリオ。悪化した指標（例: ACoS が前週比 +5pt 悪化）。分析期間（例: 過去 14 日）。

{{対象キャンペーン・ポートフォリオ（例: キャンペーンID 12345678）}}で
{{悪化した指標（例: ACoSが前週比+5pt悪化）}} が発生しています。原因を検索語句／入札／CPC／CVR／予算／掲載枠の
どの要因かに分類し、対応の優先順位をつけてください。

直近 {{分析期間（例: 過去14日）}} と、その直前の同じ長さの期間を比較し、次の6分類それぞれについて
悪化への寄与を確認してください。

1. 検索語句 — analyze_search_term_contribution を使う。period_first に前期間、period_second に
   直近期間を渡す（順序を逆にすると change / contribution の符号が反転する）。tab=acos で寄与度、
   tab=spend で広告費の増減を確認する。total_items と returned_items を比較し、
   next_page_token が返る場合は分析に必要な範囲まで継続取得する。全件を取得していない場合は
   取得件数と総件数を明記し、全体結果として断定しない。
   🔴 実際に集計された期間は effective_period_first / effective_period_second を見る。
   応答には be_request_ranges も入っているが、monthly / weekly ではこれがアンカー日１日だけになる
   （実測で月次比較なのに from と to が同じ月初の日付で返った）。これを引用すると「1日だけの比較」と誤報告する。
   period_resolution_reason と period_mode も併記する。
   🔴 単位を取り違えない。 change は bps 表記、change_value はパーセンテージポイント、
   change_ratio は相対変化率である（実測: 55.7%→62.0% に対し change "+623 bps" / change_value 6.23 / change_ratio +11.18%）。
   どの単位で語っているかを必ず明記する。
   🔴 アカウント全体の「寄与度」は返らない。 total.contribution は -- / contribution_value は null である
   （実測で確認）。行の contribution を合計して代用してもいけない（応答の surface_refs が sum(rows[]) を
   名指しで禁じている）。寄与度は上位行の値をそのまま引用し、全体の変化は total.change で語る。
2. 入札 — get_change_history で入札・予算・状態の変更履歴を確認する。0件が返っても
   「入札変更なし」と断定しない。エラー無しの0件は「変更が無かった」と「履歴を取得できていない」を
   区別できないため、「変更履歴0件（未取得の可能性あり）」と記載する。
   🔴 90日を超える開始日を渡すと、ツールは自動で 90 日前に切り上げ、
   「注記: Amazon の変更履歴は過去 90 日までのため、取得開始日を YYYY-MM-DD に調整しました。」
   という注記を返す（実測で確認）。この調整後の日付をそのまま引用して「確認できた範囲」として示す。
   profile_id は account_id に紐づく値を渡す（必須引数）。
   補助として、寄与度上位の検索語句について get_search_term_impression_trend（frequency=weekly、targets 一覧の
   keyword_id を指定）で週次の keyword_bid と検索上部インプレッションシェアの推移を確認する。
   この系列は検索語句×単一ターゲット単位であり、targets が全件返らない場合は返却件数と
   target_count を明記して、キャンペーン全体の入札変化として断定しない。
3. CPC — analyze_search_term_contribution の tab=cpc の total を使う。広告費÷クリックの
   自前計算はしない。入札が下がっているのに CPC が上がっている場合は市場要因の可能性を
   「仮説」として提示し、因果として断定しない。
4. CVR — tab=cvr の total を使う。クリックが増えているのに注文が減っていないかを確認する。
   CPC の変化率と CVR の変化率の積が ACoS の変化率とおおむね整合するかを確かめる。
   ※ この検算は全 tab で同じ単位（相対変化率 = change_ratio）に揃えて行う。bps と pt を混ぜると合わない。
5. 予算 — check_budget_status で月次予算上限の設定状況を確認する。status が未設定、または
   cap / ad_spend / utilization_rate が null の場合は「上限未設定のため上限比の消化率は
   評価不可」と明記し、null を 0% として扱わない。
   🔴 unconfigured のときは cap だけでなく ad_spend も null で返る（実測で確認）。
   このツールを広告費の取得元にしない。
   そのうえで get_portfolio_budget_summary を対象期間・前期間の2回に分けて取得し、実支出の変化と、
   現行の日予算合計に対する消化水準を確認する。ただし daily_budget_sum は現行の有効
   キャンペーン設定値であり期間別の予算履歴ではないため、「消化率の期間比較」としては扱わない。
   🔴 さらに、このツールの spend は全 state 合計・daily_budget_sum は ENABLED のみで母集団が違うので、
   消化水準は体系的に高めに出る。また include_ended=false を渡しても ENDED 行が返るので、
   status / is_ended で自分で除外する。予算による配信制限が起きていたかを判定できない場合は「未確認」と記載する。
6. 掲載枠 — get_placement_summary を対象期間・前期間の2回に分けて取得する
   （source_contract が period_policy="current_period_only" を宣言しており、1回では比較できない）。
   掲載枠別の ACoS・CVR・クリック・広告費シェアの変化を見る。orders が0で返る場合は「実績0」と断定せず
   「データ未取得の可能性」と明記する。入札倍率（avg_current_modifier_pct）は現行設定値であり
   期間別の履歴ではないため、「入札倍率の変化」としては読まない。
   🔴 「Rest of Search」は合成バケットである。 実測では placement_raw_values が
   HOME / OFF_AMAZON / PLACEMENT_REST_OF_SEARCH / SITE_AMAZON_BUSINESS の4種で、source_row_count も
   他の掲載枠の約3倍だった。この行の avg_current_modifier_pct は4種類の掲載枠を混ぜた平均なので、
   単一の枠の設定値として読まない。内訳を見る必要がある場合は placement_raw_values を列挙する。
   掲載枠のデータは広告タイプ（SP と SB）が混在した集計で SD / DSP を含まないため、
   ダッシュボードやキャンペーン明細の数値と直接比較しない。
   （実測: 同じ月の広告費が掲載枠集計・ポートフォリオ集計・SP単独集計で3通りになった。
    どの出所の値かを必ず明記する。）

実行条件
- Picaro MCP から実データを取得して分析する。MCP で取得していない数値を推測・補完しない
- 使用禁止ツール analyze_ad_type_performance は使わない。SB/SDは
  list_existing_sb_campaigns / list_existing_sd_campaigns で個別取得する
- null、未取得、データなし、0 は区別する。null や未取得を 0 として扱わない
- 全６分類を確認してから寄与度（高／中／低／なし／未確認）を判定する（1分類だけ見て断定しない）
- 取得できなかった分類は「未確認」と明記し、確認済み分類のみで結論づけたことを、
  確認できた分類数とともに明示する
- 期間は直近の確定済み日まで。当日・前日は含めない。rollup_status を確定判定に使わず、
  レポート別の status を見る
- 比率を提示するたびに分子・分母・日数を明示し、両期間の確定実日数が一致していることを確認する
- 最も寄与度の高い1〜2分類に絞って提示し、それぞれについて次に取るべき打ち手
  （入札調整・予算調整・除外KW追加のいずれか）を案内する。広告費の大半を占める中核語を
  除外KWの対象にしないこと
- 寄与度「高」の分類は、対応する既存プロンプトへの接続先を示す（入札変更を伴う場合は、ユーザーの承認を得てから反映する）
- 分析・候補抽出・提案までを行い、承認前にAmazon広告側の設定を変更しない。
  検証や分析の過程で提案（proposal）を生成した場合は、承認しないものは破棄したうえで
  破棄したことを明記する（提案は生成から24時間アカウントに残る）
- 本診断の結果は、対応実行後に「施策の効果測定」で効果検証することを前提とする

変更できる条件 — 対象キャンペーン・ポートフォリオ／悪化した指標／分析期間。

返ってくる内容 — 検索語句 / 入札 / CPC / CVR / 予算 / 掲載枠の 6 分類ごとの寄与度（高 / 中 / 低 / なし / 未確認）と、寄与度の高い 1〜2 分類への対応方針（入札調整・予算調整・除外キーワード追加のいずれか）。期間別の予算履歴・掲載枠の入札倍率の変化履歴は Picaro に無いため、予算・掲載枠の 2 分類は現行の設定値からの判定にとどまる旨が明記されます。

設定変更 — 変更なし（分析・候補抽出・提案まで）。分析の過程で提案（proposal）を生成した場合、承認しないものは破棄され、その旨が出力に明記されます。

次にすること — 寄与度が高いと判定された分類に応じて、入札単価を調整する／予算を調整する／除外キーワードを追加するの承認フローへ進みます。対応実行後は施策と外部イベントを記録して効果を検証するで効果を検証します。

広告戦略を立案する

このページの基本情報

こんな時に使います

実行前に確認すること

プロンプト早見表

現状の構成と成果を分析する

プロンプト 1: 既存キャンペーン構成を確認する

プロンプト 2: ファネル別にパフォーマンスを分解する

プロンプト 3: 自社ブランド名を含むキーワードと一般語のキーワードで成果を比較する

プロンプト 4: 不採算の要因を CAC と LTV の視点で分析する

予算配分とブランド構造をシミュレーションする

プロンプト 5: 新規ブランド顧客を増やす予算追加の配分案を作る

プロンプト 6: 既存キャンペーン内での予算追加の最適配分を求める

プロンプト 7: 予算が消化されない原因を分析する

プロンプト 8: イベント前後の予算配分案を検索ファネル別に作る

ASIN 単位で収益と成果を分析する

プロンプト 9: ASIN 別に広告貢献額を計算する

プロンプト 10: 主要 ASIN のパフォーマンスサマリーを取得する

プロンプト 11: クリック率は高いが購入率が低い ASIN を特定する

プロンプト 12: 悪化した指標の原因を 6 つの要因に切り分ける

関連カテゴリ