施策と外部イベントを記録して効果を検証する

このページでは、自分が打った施策（施策ログ）と自分以外で起きた外部イベントを Picaro に記録し、記録した施策について変更の前後（Before/After）で効果を検証できます。打った施策は記録しておかないと、後から「何が効いたのか」を振り返れません。記録した施策は ダッシュボードで KPI を確認する のプロンプト 3「施策 Before/After 効果測定」でも使えます。

このページの基本情報

項目	内容
このページでできること	施策・外部イベントを Picaro に記録し、変更の前後で KPI を比較して効果を検証する
対象	施策ログ（入札調整・予算変更・昇格など自分が打った打ち手）と外部イベント（TV 放送・セール・バズ・在庫切れなど自分以外の要因）
必要なデータ・接続	接続済みアカウント。効果検証には接続済みアカウントの KPI 実績データ（追加設定は不要）
実行範囲	プロンプトによって異なります。施策・外部イベントの登録＝Picaro への記録（書き込みが発生）／変更履歴の比較・レポート＝分析のみ（読み取り）。いずれも Amazon の広告設定そのものは変更しません。各プロンプトの「設定変更」で個別に示します

このページで使う言葉

• 施策ログ … 自分が打った打ち手（入札調整・予算変更・昇格など）の記録。後で効果を測るために Picaro に登録します。
• 外部イベント … 自分の施策ではない外部要因（TV 放送・セール・バズ・在庫切れなど）の記録。KPI が動いた理由として後から参照します。
• 施策 ID / イベント ID … 登録時に自動で採番される番号。効果検証や更新のときに指定します。
• 変更の前後（Before/After） … 施策を実施した前後の期間で KPI を比べること。効果があったかを判断する基本の方法です。
• ACoS（広告費用対売上高比率）／ROAS（広告費用対効果）… 広告効率の指標。ACoS は低いほど、ROAS は高いほどよい。

記録と効果検証はセットで使う

施策ログは記録しただけでは価値が出ません。実施から 7〜14 日後に、記録した施策 ID を効果検証のプロンプト（プロンプト 4）やダッシュボードの施策 Before/After 効果測定に渡すと、ACoS / ROAS / 広告費 / 売上の差分を自動で集計できます。

効果を比較する前に確認すること

個別施策の効果判定（プロンプト 4・6）では、比較を始める前に次の 3 点を確認してください。

• 施策 ID は実在確認してから使う。 比較ツールは指定した施策 ID が存在するかを検証しません。存在しない ID を渡しても比較自体は進んでしまうため、先に施策ログの個別取得で実在を確認してください。
• 比較期間に外部イベントが重なっていないか確認する。 セール・TV 放送・在庫切れなどが比較期間に重なっていると、施策の効果と外部要因が混同されます。比較ツールは外部イベントを自動で除外しません。
• 施策前後の比較日数を必ず一致させる。 変化率は期間の合計値どうしの単純比較で、日数のずれを正規化せず、ずれていても警告は出ません。施策前 14 日・施策後 14 日のように日数を揃えてください。

こんな時に使います

• 打った施策（入札調整・予算変更・昇格など）を、後で効果を測れる形で記録しておきたい
• TV 放送・セール・バズ・在庫切れなど、自分以外で起きたことを KPI 変動の理由として残しておきたい
• 実施した施策の前後で KPI がどう変わったかを比べて、効果を検証したい
• KPI が良くなった理由を、記録した施策から逆引きしたい

実行前に確認すること

• 接続先のアカウント … 複数アカウントを扱う場合は、記録・分析する対象アカウントが合っているか先に確認します。
• 施策の実施日 … 施策ログの登録では過去の日付のみ指定できます。
• 効果検証の対象期間 … 変更の前後を比べる期間（プロンプト 4 は前後で必ず同じ日数を指定・既定 14 日）。当日・前日のデータは未確定のことがあるため、確定済みの直近期間が安全です。
• 対象ブランド・ASIN（任意） … 特定ブランドや商品に絞りたい場合に指定します。指定しなければアカウント全体が対象です。

プロンプト早見表

やりたいこと	分かること・作られるもの	設定変更	プロンプト
打った施策を後で効果検証できる形で記録する	自動採番された施策 ID と登録内容	施策ログを記録	プロンプト 1
記録済みの施策を一覧・更新・メモ追加する	施策ログの一覧、または更新結果	一覧は変更なし／更新・削除は施策ログを変更	プロンプト 2
外部要因（TV / セール / バズ / 在庫切れ）を記録する	自動採番されたイベント ID と登録内容	外部イベントを記録	プロンプト 3
入札調整の前後 2 週で KPI を比較する	前後 2 週の KPI 差分の比較表	変更なし（読み取り）	プロンプト 4
KPI 改善に寄与した変更を特定する	今期・前期の比較と寄与した施策	変更なし（読み取り）	プロンプト 5
実行した施策の効果を判定し、継続／拡大／調整／停止／差し戻し／要調査を決める	実行前後の指標比較表と6択の判定・理由	変更なし（読み取り中心。施策ログ未登録時は登録）	プロンプト 6

記録系と分析系の見分け方

プロンプト 1〜3 は施策・外部イベントを Picaro に記録します（データの書き込みが発生します）。プロンプト 4〜5 は記録済みの変更履歴や KPI を 読み取って分析・比較するだけで、何も書き込みません。プロンプト 6 は基本的に読み取り専用ですが、比較対象の施策ログが未登録の場合はユーザーに確認のうえで登録することがあります。いずれも Amazon の広告設定そのものは変更しません。

---

施策・外部イベントを記録する

プロンプト 1: 施策ログを登録する

実施した施策（入札調整・予算変更・昇格など）を、変更の前後（Before/After）で比較できる形で Picaro に記録します。

こんな時に使う — 打った施策を、後で効果測定できるよう記録に残したいとき。

実行前に必要な情報 — 施策の種類、施策名、実施日（過去の日付）。

内部施策（入札調整等）のログを登録して。
- 種類: 入札調整
- 名前: {{施策名（例: 高ACoS KW 18件の入札 -22%）}}
- 実施日: {{実施した日（例: 2026-05-18）}}
- 詳細: 何のために打った施策か（任意）
- ステータス: 効果測定中

注: これは内部施策の効果測定用ログ（manage_measure相当）。セール等の外部要因記録は別プロンプト
（外部イベントを記録する）を使うこと。

この結果を使う次のプロンプト: {{接続先（例: 施策の効果測定・2週間後）}}

変更できる条件 — 施策名、実施日（過去の日付のみ）、種類（「入札調整」「予算変更」「掲載枠調整」「昇格」「除外」「その他」から選択）。入札調整の提案を実行した直後なら、その提案を紐づけることもできます。

返ってくる内容 — 自動採番された施策 ID と登録内容の表。実施から 7〜14 日後に効果測定する案内が付きます。

設定変更 — 施策ログを Picaro に記録します（書き込みが発生します。Amazon の広告設定は変更しません）。

次にすること — 記録した施策の効果は、実施から 7〜14 日後にプロンプト 4 や ダッシュボードで KPI を確認する の施策 Before/After 効果測定で検証します。

---

プロンプト 2: 施策ログを一覧 / 更新 / メモ追加する

過去に登録した施策ログを一覧で確認し、進捗メモやステータスの更新を行います。

こんな時に使う — 記録済みの施策の状況を確認したいとき、または進捗メモやステータスを更新したいとき。

実行前に必要な情報 — 更新・削除する場合は対象の施策 ID。

効果測定中（status=monitoring）の施策ログを一覧で見せて。

1. 種別は「{{絞り込み種別（例: 入札調整）}}」。施策ログの pattern_id は
   cpc / budget / placement / promotion / negative / custom の6種のみなので、
   指定された種別をこの6種のいずれかに対応付けてから絞り込むこと
   （入札調整→cpc、予算変更→budget、掲載枠調整→placement、プロモーション→promotion、
   除外キーワード→negative、その他→custom）。
   対応付けできない種別は絞り込まずに全件を出し、「指定種別は pattern_id に存在しない」と明示すること。
2. 絞り込み結果が0件のときは、「条件に合う施策が0件」と「施策ログ自体が0件」を必ず区別して報告すること
   （絞り込み条件を外した一覧をもう一度取得して確認する）。
3. 各施策について、施策日（date）起点の経過日数と、登録日（createdAt）起点の経過日数の両方を出す。
   登録日は一覧に含まれないため、各施策を個別に取得して確認すること。
   両者がずれる場合は施策日起点を主に扱い、差がある旨を注記する。
4. 経過日数の計算に使う「今日」は、広告データの取込状況を確認したうえで
   確定済みの最終日とすること（当日が未確定なら当日を起点に使わない）。
5. 施策日起点の経過日数が {{評価目安日数（例: 14日）}} を超えているものは「評価時期到来」と明示し、
   経過日数の長い順に並べる。
6. 出力は表形式（施策日 / 種別 / 名前 / 状態 / 施策日起点の経過日数 / 登録日起点の経過日数 / 評価時期到来 / ID）。

注: これは内部施策ログの一覧（manage_measure）。外部イベントログ（manage_event）は対象外。

この結果を使う次のプロンプト: {{接続先（例: 施策の効果測定）}}
引き渡す値は 施策ID・施策日・種別。Before/After の比較窓は施策日を境に自分で指定する必要があり、
施策ログは対象キャンペーン/ASIN を保持しないためアカウント全体での比較になる点を必ず添えること。

変更できる条件 — 一覧の絞り込み条件（種類・ステータスなど）。特定の施策 ID（例: evt_2026_05_18_cpc）を指定して、内容の更新・進捗メモの追加・削除もできます（「evt_2026_05_18_cpc に『3 日目: 効果出始め』とメモを追加して」のように依頼）。

返ってくる内容 — 施策 ID / 種類 / 名前 / 実施日 / ステータス / 経過日数の一覧表（既定 20 件・実施日が新しい順）、または個別取得・更新の結果。

設定変更 — 一覧・個別取得は変更なし（読み取り）。更新・メモ追加・削除は施策ログを変更します（書き込みが発生します）。削除のときは必ず確認をはさみます。

次にすること — 効果が出そろった施策は、プロンプト 4 で前後の KPI を比較します。

---

プロンプト 3: 外部イベントを記録する

TV 放送・セール・バズ・在庫切れなど、自社が打った施策ではない外部要因を記録し、KPI 変動の理由として後から参照できるようにします。

こんな時に使う — KPI が大きく動いた背景（自分以外の要因）を、後で振り返れるよう残しておきたいとき。

実行前に必要な情報 — 外部イベントの種類、開始日、イベント名。

外部イベント（セール・TV放送・バズ・在庫切れ等）を記録してください。
- 種類: {{種別（tv / sale / buzz / stockout / other のいずれか。値上げ・競合施策など該当が無いものは other）}}
- 開始日: {{開始日（YYYY-MM-DD。例: 2026-06-11）}}
- 終了日: {{終了日（YYYY-MM-DD・任意。単日なら省略）}}
- ラベル: {{イベント名（例: プライムデー 2026 春）。対象範囲や補足（例: 全ASIN対象・20%OFFクーポン併用）を残したい場合は、保存先が名称欄しか無いためこのラベル内に含めて記載する}}

【登録前】
既存イベントの一覧を取得し、重複が無いことを確認してから登録してください。
一覧は filter_from / filter_to（日付範囲）と filter_type（種別）で絞り込めるので、登録しようとしている期間で絞って重複を見てください。
イベントは単日でなく date〜end_date の期間を持つので、重複判定は期間の重なりで見てください（開始日の一致だけで見ない）。

【登録後】
再度一覧を取得し、登録内容（種別・開始日・終了日・ラベル）が意図どおりかを確認して報告してください。
返ってきた id（UUID）を必ず報告に含めてください。 後で訂正・削除するにはこの id が必要で、
一覧から探す以外に得る方法がありません。
一覧が返す項目は id / type / date / end_date / label / registered_by_email / registered_by_user_id /
updated_by_email / updated_by_user_id / created_at / updated_at です。
※ registered_by_* ・updated_by_* は null で返ることがあります（実測で既存イベントはすべて null）。
  「登録者不明」と「登録者なし」を区別し、null を推測で埋めないでください。

【このイベントを後で使うときの注意】
登録したイベントは、ダッシュボードやレポートの応答に自動では現れません。
この期間のKPI変動を確認する際は、イベント一覧を対象期間で絞り込んで取得し、分析期間と日付を突き合わせたうえで
要因候補として扱ってください（イベント起因の変動を施策効果と混同しない）。
※ 施策の前後比較をするプロンプトはこの一覧を実際に入力として使います。比較ツールはイベントを
  自動除外しないので、ここで登録を欠かすと下流の分析がセールの影響を施策効果と誤認します。
※ 大規模セールは「先行セール」と「本体」が連続することが多いので、別イベントとして分けて登録してください
  （下流の区間分析でリード期が先行セールに食い込んでいることを検出できるようにするため）。

【保存できないこと】
影響範囲・割引率・対象ASINなどの構造化フィールドはありません。ラベルの文字列に含めるしかありません。
よってイベント名で検索・集計することはできない前提で、人が読んで判別できる命名にしてください。

この結果を使う次のプロンプト: {{接続先（例: ダッシュボードKPI（前期間比較付き））}}

変更できる条件 — 開始日、終了日（任意・単日イベントなら省略）、イベント名、種類（「TV 放送」「セール」「バズ」「在庫切れ」「その他」から選択）。

返ってくる内容 — 自動採番されたイベント ID と登録内容の表。

設定変更 — 外部イベントを Picaro に記録します（書き込みが発生します。Amazon の広告設定は変更しません）。

用語補足 — 記録した外部イベントは、ダッシュボードやレポートの応答に自動では表示されません。施策前後の比較をする際は、イベント一覧を対象期間で絞り込んで取得し、KPI 変動の要因候補として突き合わせてください（比較ツールは期間を自動除外しません）。

次にすること — 記録したイベントを踏まえて KPI の動きを確認したい場合は ダッシュボードで KPI を確認する へ。

---

変更履歴を分析・検証する

プロンプト 4: 入札調整の前後 2 週で KPI を比較する

指定した入札調整について、実施前 2 週と実施後 2 週の KPI パフォーマンスを比較します。

こんな時に使う — 記録済みの入札調整に、実際に効果があったかを数字で検証したいとき。

実行前に必要な情報 — 実施した入札調整の実施日。施策ログが未登録でも実施日を基準に判定できます（登録済みならプロンプト 1 のログと突き合わせます）。

{{施策実施日（例: 2026-08-04）}} に実施した入札調整の効果を判定し、継続要否を決めてください。

前提確認（先に行い、結果を出力に明記する）
1. manage_measure(action=list) で該当施策の記録があるか確認する。記録があれば施策ID・pattern_id・実施日を引用する。
   記録が無い場合は「施策ログ未記録」と明記したうえで、指定された施策実施日を基準に続行する。
   施策IDを渡す場合も、比較ツールはIDの実在を検証しないため、必ず manage_measure(action=get) で存在を確認してから使う。
   （action=get は存在しないIDに対して「該当ログが見つかりません」を返すので、この確認は実際に機能する。）
2. manage_event(action=list) で比較期間にセール・TV・在庫切れ等の外部イベントが重なっていないか確認する。
   重なっている場合は比較期間をずらすか、影響を出力に明記する。比較ツールはイベントを自動除外しない。
   イベントは date〜end_date の期間を持つので、開始日だけでなく期間全体と before / after の重なりを見る。

比較の条件（厳守）
- 施策実施日の直前{{比較期間の日数（例: 14日）}}を before、直後{{比較期間の日数（例: 14日）}}を after とし、before と after の日数を必ず一致させる。
  変化率は期間合計の単純比で日数正規化されず、日数がずれても警告が出ないため、揃っていない比較は無効とする。
- after の期間末は売上が確定した日までとする。売上系は約7日、トラフィック系は約3日かけて確定する。
  get_data_ingestion_status で確定済みの最終日を確認し、fully_missed / in_progress の日を after に含めない。
  実行結果に「集計確定前」の警告が出たら、期間末を確定日まで下げて必ず再実行する。未確定値のまま判定しない。
- 広告側の指標（広告費・クリック・広告売上・注文数・ACoS・ROAS・CTR・CPC・CVR）の出所は compare_measure に一本化する。 他ツールと値が食い違うため混在させない。
- 総売上は compare_measure が返さない。 総売上だけは get_dashboard を after 期間・include_previous=true で1回呼んで取得する
  （前期間が自動で「同じ日数の直前期間」になるため、before と after の日数一致が機械的に保証される）。
  取得した総売上は別出所の参考値として扱い、表では出所名を添えて区別する。
  同じ期間・同じアカウントでも compare_measure の広告売上と get_dashboard の広告売上は一致しないことがある
  （実測では after 期間は一致したのに before 期間だけ数%ずれた）。乖離があれば乖離幅を明記し、片方の値で他方を上書きしない。
- CTR は表示が小数第1位で丸められるため、clicks ÷ impressions で再計算した値を差分表に載せる。
  丸めた表示が before / after で同じ値に見えても、再計算では有意に動いていることがある。
- ツールが返す judge（improved/neutral/degraded）は判定基準が非公開のため結論に使わない。参考として併記するに留める。
  ACoS と ROAS がともに悪化していても judge が neutral を返す実測がある。

出力するもの
- ACoS・ROAS・売上（広告売上）・CTR の Before / After / 変化率を含む差分表。広告費・クリック数・注文数も併記する。
- 参考として総売上の変化率も併記し（出所を get_dashboard と明記する）、広告売上と符号が異なる場合はその旨を明記する。
- compare_measure はキャンペーン別の広告費・ACoS 上位も返すので、全体の変化を牽引したキャンペーンを1〜3件挙げる。
  ただし before の広告費が0のキャンペーンは「ACoS +100%」のように出るため、新規配信と悪化を区別して書く。

判定基準
- ACoS が {{改善基準（例: 相対で10%以上改善）}} を満たし、かつ広告売上が -5% 以内なら Keep 推奨。
  さらに ROAS も改善していれば Expand を検討。
- ACoS が改善していても広告売上が -10% 超悪化なら Revert 検討。
- 上記のいずれにも当てはまらない、または前提確認1・2で不確実性が残る場合は Investigate。
- 改善幅は「相対変化率（%）」か「パーセントポイント（pt）」かを必ず明示する。
  ACoS 61.1%→58.6% は相対 -4.0% / 絶対 -2.5pt であり、どちらで読むかで結論が変わる。

Guardrail: 広告売上を大きく落としてまで ACoS を改善しない。
Guardrail: 施策が特定できない・期間が確定していない場合に「効果なし」「継続不要」と断定しない。必ず Investigate とし、不足している情報を明記する。
Guardrail: 前後比較のみで対照群が無いことを明記する。季節性・在庫・価格・レビュー変動は分離できない。

最後に次の3点を出力してください。
1. 推奨アクション — 判定結果（Keep/Expand/Adjust/Revert/Investigate）・理由・優先度・期待効果・確信度・リスクを明記する
2. 実行方法 — Revert は入札を施策前水準に戻す提案を、Expand は対象拡大案を、いずれも提案内容をユーザーが確認・承認したうえで反映する
3. 測定 — 実行後{{比較期間の日数（例: 14日）}}で同指標を再取得し、「施策の効果測定」で再判定する

変更できる条件 — 施策実施日／比較期間の日数（既定 14 日。施策前後で必ず同じ日数）／ACoS の改善基準（既定 10% 以上改善）。

返ってくる内容 — ACoS・ROAS・売上・CTR の Before/After/変化率の差分表（広告費・クリック数・注文数も併記）と、Keep/Expand/Adjust/Revert/Investigate の判定。

設定変更 — 変更なし（読み取り）。

用語補足 — ダッシュボードで KPI を確認する の施策 Before/After 効果測定と似ていますが、こちらは入札系施策向けに、施策前後の比較日数を必ず一致させて比較します（既定 14 日。日数がずれても変化率は正規化されず警告も出ないため厳守します）。入札調整以外の施策（予算変更・昇格・除外など）を対象にしたい場合や、実行前後で異なる比較期間を指定したい場合はプロンプト 6 を使います。

次にすること — アカウント全体でどの変更が効いたかを逆引きしたい場合はプロンプト 5 へ。入札調整以外の施策も含めて Keep/Expand/Adjust/Pause/Revert/Investigate の 6 判定で効果を確認したい場合はプロンプト 6 へ。

---

プロンプト 5: KPI 改善に寄与した変更を特定する

期間内のアカウント全体 KPI パフォーマンスをレポートし、前の期間と比較して、改善に寄与した変更を特定します。

こんな時に使う — 数字が良くなった理由を、記録した施策から逆引きしたいとき。

実行前に必要な情報 — 対象期間（既定は直近 30 日）。

直近30日のアカウント全体の売上・ACoS・ROASを前期間と比較し、KPI改善に寄与した施策を特定して対応（継続/拡大/停止）を判断するレポートを作成して。
目的: 効果のあった施策を特定し、横展開または停止の判断に使うため。

## Step 0. 期間を確定してから始める（省略不可）
1. get_data_ingestion_status で確定済みの最終日を確認する。fully_missed / in_progress の日は当期に含めない。
2. 当期＝確定最終日から遡る{{比較日数}}日、前期＝その直前の同じ{{比較日数}}日とし、両期間の日数を必ず一致させる。
3. レポート冒頭に「確定最終日」「当期の開始日と終了日」「前期の開始日と終了日」「各期間の日数」を明記する。
※ 日数が揃っていない比較は、変化がゼロでも「変化した」と出る。未確定日を1日含むだけで変化率が数ポイント動くため、この確認を飛ばさないこと。ツールは期間長の不一致を警告しない。
※ rollup_status を確定判定に使わない。未出稿の広告種別が1件あるだけで、他のレポートがすべて completed でも日全体が no_data に落ちる。各レポートの status を見る。

## Step 1. KPIの出所を1つに固定する（省略不可）
- 本レポートの主KPI出所を {{KPI出所}}（get_dashboard または analyze_ad_type_performance のいずれか一方）に固定し、レポート冒頭に明記する。
- 出所の選び方: get_dashboard は ROAS と clicks を返さない（返るのは総売上・広告売上・広告費・ACOS・TACoS・注文数・CVR）。ROAS を主KPIに含めるなら analyze_ad_type_performance を選ぶか、ROAS を「当方算出（広告売上÷広告費）」と明記する。一方 analyze_ad_type_performance は SP/SB/SD の広告側だけで、総売上を返さない。どちらを選んでも欠ける指標が出るので、欠ける側は「この出所では取得不可」と書く。
- 複数の出所の数値を1つの表・1つの比較の中で混在させない。 同じ期間・同じアカウントでも出所により ACoS・ROAS・広告費は一致しない（集計ソース・税区分・アトリビューション窓が異なる）。参考として別出所の値を併記する場合は、必ず出所名を添え、乖離幅も書く。
- ツールが返さない指標を返ったかのように書かない。 自分で計算した値は「当方算出」と明記する。
- 比率の変化は単位を揃える。 「絶対差（ポイント）」か「相対変化率（%）」かをレポート内で統一し、どちらかを明記する。ツールによって返る単位が異なるため、応答の値をそのまま並べない。
- 比率を提示するたびに、分子・分母・対象日数を併記する。変化が分母由来か分子由来かを読み手が判別できる形にすること。

## Step 2. 施策の記録を集める（3経路すべてを確認する）
次の3つをすべて実行し、それぞれの取得件数を記録する。
1. get_change_history … Amazon側の変更履歴（遡り上限は90日。profile_id は account に紐づく値を渡す）
2. manage_measure（action=list, フィルタ無し） … Picaro の施策ログ
3. query_audit_log … MCP経由の操作記録

重要な取り扱い:
- どれかが0件でも「施策は行われなかった」と書かない。 正しい記述は「施策の記録が取得できず、実施の有無を判定できない」。記録の不在は施策の不在を意味しない。
- 3経路それぞれについて「取得できた件数」と「その経路が原理的に捕捉できない範囲」を分けて明記する。
- query_audit_log は呼び出し元エージェント自身のツール呼び出し記録であり、広告への変更記録ではない。施策ログの代替として扱わない。他の人・他のエージェント・Seller Central からの変更はここには出ない。
- query_audit_log の件数を全数として扱わない。応答には「表示件数 / 該当件数 / 走査件数」が別々に出、走査上限（実測で10,000件）に到達すると未走査分を指す next_cursor が返る。このとき「該当N件」は下限値でしかない。走査上限に到達したか否かを必ずレポートに書く。
- audit_level=mutation を「書き込み操作の絞り込み」として使わない。実測では一覧取得系の読み取り専用ツールも audit=mutation とラベルされていた。ラベルでなくツール名で判定する。なお、MCP経由の書き込み試行は成功・失敗ともに記録されるので、自分の経路に限っては使える。
- 記録が0件なのに広告費・キャンペーン配分が実際に動いている場合は、「真のゼロ」ではなく「記録経路の欠落」の可能性が高いと明記し、確認アクションとして残す。
- 外部イベント（セール・TV・在庫切れ）は施策とは別に manage_event（action=list）で確認する。施策ログが0件でもイベントは登録されていることがあり、KPI変化の主因になりうる。期間に重なるイベントは必ずレポートに載せる。

## Step 3. 施策記録が1件以上あった場合のみ、対応判断へ進む
- 各施策について、施策実施日を境に前後の日数を揃えて Before/After を比較する。
- 影響度（KPI改善幅）が大きい順に並べ、「継続」「拡大」「停止」のいずれかを推奨する。
- ツールが返す総合判定（judge等）を Guardrail 判定の代わりに使わない。 效率指標が改善していても売上・注文数が悪化していることがあるため、売上と注文数は必ず独立に確認する。

## Step 4. 因果の切り分け（省略不可・Step 3 の有無にかかわらず実施）
KPIの変化を施策の成果と呼ぶ前に、次を全て確認し、レポートに明記する。
1. 露出量の増減 — インプレッション・クリック・広告費が同時に減っていないか。效率指標の改善が「效率の悪い出稿が止まった結果」である可能性を検討する。
2. 規模と效率の方向 — 效率（ACoS/ROAS）と規模（売上・注文数）が逆方向に動いていないか。逆なら「改善」と単純に呼ばない。
3. 対照群の不在 — 前後比較のみで対照群が無いことを明記する。季節性・カテゴリ変動・在庫・価格・レビュー変動は分離できないことを書く。
4. 数値の可変性 — 確定済み期間でも再取込で値が変わりうることを明記する。
上記のいずれかが切り分けられない場合、「〜が効いた」と断定せず「〜と同時期に〜が起きた（因果は未確定）」と書く。

## Guardrail
- 売上または注文数を悪化させた施策は継続・拡大の推奨にしない。
- 根拠（施策記録）が空のまま継続/拡大/停止の推奨を出さない。 施策を特定できない場合は、推奨アクションを「施策判断」でなく「施策判断を可能にするための整備アクション」に置き換える。
- 取得できた範囲と欠落した範囲を必ず分けて明記する。断定できないことは「判定不能」と書く。

## 出力
最後に次の3点を出力してください。施策を特定できなかった場合は、各項目にその旨と代替内容を書くこと。
1. 推奨アクション — 施策ごとの継続/拡大/停止・理由・優先度（KPI改善幅順）・期待効果・確信度・リスク。施策を特定できない場合は、記録整備・原因確認のアクションを優先度順に出し、「KPI改善幅順に並べていない理由」を明記する
2. 実行方法 — 拡大・継続は{{実行用プロンプト}}で対象拡大・予算増額を提案し、承認後に実行する。引き渡す対象が0件の場合はその旨を書き、引き渡さない
3. 測定 — 実行{{再測定日数}}日後に同指標を再取得して比較する。再測定時も Step 0（確定境界・期間長一致）と Step 1（KPI出所の固定）を必ず適用する。悪化していればRevertする

変更できる条件 — 対象期間（既定 30 日。前期も同じ日数で比較）／KPI の主出所（get_dashboard または analyze_ad_type_performance のいずれか一方に固定）。

返ってくる内容 — 今期・前期の KPI 比較と、3 経路（Amazon 側変更履歴・Picaro 施策ログ・MCP 操作記録）から集めた施策の一覧。施策ごとに継続／拡大／停止の推奨と、理由・優先度・確信度・リスクが付きます。施策の記録が取得できない場合は、判断の代わりに記録整備のアクションを優先度順に示します。

設定変更 — 変更なし（読み取り）。

次にすること — 特定した施策の効果を個別に深掘りしたい場合はプロンプト 4 で前後を同じ日数（既定 14 日）で比較します。月次レポートに含めたい場合は レポートを作成する へ。

---

プロンプト 6: 施策の効果を測定して継続か差し戻しかを判断する

実行した施策について、実行前後の指標を比較し、Keep（継続）／Expand（拡大）／Adjust（微調整）／Pause（停止）／Revert（差し戻し）／Investigate（要調査）の6判定で結論を出します。

こんな時に使う — 実行した施策（入札調整に限らず、予算変更・昇格・除外なども含む）に実際に効果が出ているかを判定し、続けるか・広げるか・戻すかを決めたいとき。

実行前に必要な情報 — 実行した施策の内容と実行日。比較対象（キャンペーン・キーワード・ASIN等）。実行前後の比較期間。比較したい評価指標。悪化と判定する水準（例: Orders 前週比 -10%以内）。

{{実行した施策（例: キーワード入札の引き下げ）}}を {{実行日（例: 2026-08-10）}} に反映済みです。効果が出ているかを
判定し、継続／拡大／調整／停止／差し戻し／要調査のいずれかを判断したいです。

対象（{{対象キャンペーン・キーワード・ASIN等（例: キャンペーンID 12345678）}}）について、実行前期間
（{{実行前の比較期間（例: 実行日の前14日間）}}）と実行後期間（{{実行後の比較期間（例: 実行日から14日間）}}）の
{{評価指標（例: ACoS, Orders, CPC）}} を比較し、表で示してください。それぞれ改善／悪化／変化なしを判定してください。

悪化と判定した指標が {{守るべき水準（例: Orders 前週比 -10%以内）}} を下回っている場合は「Revert候補」と
明記してください。判定に基づき、Keep（継続）／Expand（拡大）／Adjust（微調整）／Pause（停止）／Revert（差し戻し）／
Investigate（要調査）のいずれか1つを理由とともに提示してください。

実行条件
- 実行前後は必ず2回に分けて取得する（1回の呼び出しで前期間を同時に返させない）
- アカウント全体の比較は compare_measure に before / after を渡す（judge と主要KPIの変化率が返る）。
  このツールには対象を絞るパラメータが無く、返るのはアカウント合計とキャンペーン別Top10（広告費順・費用とACOSのみ）
  である。対象がその中に無い場合、または Orders・CPC が必要な場合は下記の粒度別手段へ切り替える
- キャンペーン単位の比較は list_existing_sp_campaigns（include_metrics=true）を before / after の期間で2回呼ぶ。
  name_filter を付けると include_metrics と期間が無視されるため、メトリクス取得時は期間指定のみで呼び、
  truncated が false であることと returned が total_results と一致することを確認してから対象を突き合わせる
- キーワード／商品ターゲット単位の比較は list_target_performance を before / after で2回呼び、search_key で
  対象を絞る。target_fetch_truncated が true の場合は max_pages を target_total_pages_available 以上へ上げて
  取り直す。それでも截断する場合は「全件取得を保証できない」と明記して判定を暫定とする。上流集計は数時間
  キャッシュされるため、直近の変更が反映されていない可能性にも触れる。複数期間を並列で呼ぶとタイムアウト
  しやすいので1件ずつ実行する
- 施策の記録・参照は manage_measure（action=list / add / get、pattern_id と proposal_id を指定）で行う。
  実行記録が無い場合は実行日・対象・変更内容をユーザーに確認してから登録する。manage_event は外部イベント
  （セール・在庫切れ・TV等）の記録用で施策ログではないため、比較期間に外部イベントが重なっていないかの
  確認（action=list）に使い、重なる場合は解釈に注記する
- 売上系指標（売上・注文・ACoS・ROAS・CVR）は約7日、トラフィック系指標（表示・クリック・費用）は約3日で
  確定する。比較期間の終端が未確定日を含む場合はその旨を明記し、可能であれば確定済み日までに期間を切り直す
- 判定は6択（Keep/Expand/Adjust/Pause/Revert/Investigate）のうち必ず1つを明記する
- Revertと判定した場合は、変更前の値に戻す提案を作成し、ユーザーの承認を得てから反映することを案内する
- 部分データ・截断がある場合は判定を保留し「暫定」と明記する。取得できなかった指標は推測で補完しない

変更できる条件 — 対象（キャンペーン・キーワード・ASIN等）、実行前後の比較期間、評価指標、悪化と判定する水準。

返ってくる内容 — 実行前期間と実行後期間の指標比較表（改善／悪化／変化なしの判定つき）と、Keep／Expand／Adjust／Pause／Revert／Investigate のいずれか1つの判定と理由。部分データ・截断がある場合は判定が保留され「暫定」と明記されます。

設定変更 — 変更なし（読み取り中心）。ただし比較対象の施策ログが未登録の場合は、実行日・対象・変更内容をユーザーに確認したうえで記録することがあります（書き込みが発生します）。Amazon の広告設定そのものは変更しません。

用語補足 — プロンプト 4「入札調整の前後 2 週で KPI を比較する」は入札調整に限定し、比較日数を前後で必ず一致させて比較します（既定 14 日。変更できます）。プロンプト 6 は施策の種類を問わず、比較期間も施策ごとに指定できる汎用版で、6 択の判定まで結論を出します。他のプロンプトから「実行後に効果を再評価する」として参照されるのはこちらです。

次にすること — Revert（差し戻し）と判定した場合は、変更前の値に戻す提案を作り、ユーザーの承認を得てから反映します。

---

関連カテゴリ

• ダッシュボードで KPI を確認する — プロンプト 3「施策 Before/After 効果測定」で記録済み施策を使う
• 入札単価を調整する / 予算を調整する — 提案実行と組み合わせて施策ログを残すのが定石
• 売上・広告費・ACoS の目標を設定する — 施策の効果判定基準として目標 ACoS / TACoS を事前登録
• レポートを作成する — 月次レポートに施策ログ + 外部イベントを同梱
• 判定ルールを保存して提案の承認・監視を仕組み化する — 承認して反映した施策をここに記録する