判定ルールを保存して提案の承認・監視を仕組み化する

このページでは、入札や除外の判定ルールをアカウントに保存して毎回の指定を省いたり、最適化プロンプトが出した提案を確認して反映したり、予算超過の通知や定期サマリーの配信、条件に合う対象の自動提案を仕掛けたりできます。同じ判断を繰り返している運用を、ルール化して軽くするためのページです。

このページの基本情報

項目	内容
このページでできること	判定ルールの保存、提案の確認と反映、定期的な監視・通知の設定、条件に合う対象の自動提案
対象	スポンサープロダクト広告（SP）が中心
必要なデータ・接続	接続済みアカウント。通知・配信は Slack 連携などの追加設定が必要な場合があります（下記の注記を参照）
実行範囲	プロンプトによって異なります。ルール・条件の登録＝記録／提案の承認＝承認後に広告設定を変更／監視・配信＝通知の設定／判定・提案＝分析・提案のみ。各プロンプトの「設定変更」で個別に示します

こんな時に使います

入札や除外の判定基準を毎回書くのが手間なので、ルールとして保存しておきたい
最適化プロンプトが出した提案を、全部または一部だけ選んで反映したい
予算を使いすぎたら通知してほしい／週次の成績を定期的に受け取りたい
条件（成果が低い・配信が止まっている等）に合う対象を、自動で見つけて提案してほしい

実行前に確認すること

対象アカウント … 複数アカウントを扱う場合、提案を作ったアカウントと反映するアカウントは一致している必要があります。
判定の基準値 … 目標 ACoS、対象とする最小クリック数・注文数など。KPI 目標を登録済みなら自動参照されます。
通知・配信の連携 … プロンプト 5・6 は追加の連携設定が必要です（上の注記を参照）。

プロンプト早見表

やりたいこと	分かること・作られるもの	設定変更	プロンプト
判定の基準をアカウントに保存して再利用する	登録内容と参照先の案内	ルールを登録	プロンプト 1
提案の中身（現在値・推奨値・理由）を確認する	提案項目の詳細一覧	変更なし（読み取り）	プロンプト 3
終わらせるべき季節キャンペーンを見つける	終了推奨の判定と理由	変更なし（終了は手動）	プロンプト 4
予算を使いすぎたら通知する	通知条件と直近の超過実績	通知条件を登録	プロンプト 5
週次の成績サマリーを定期配信する	配信スケジュールとプレビュー	配信設定を登録	プロンプト 6
予算が余っている広告で成果の高い商品に入札強化を提案する	入札引き上げの提案一覧	変更なし（提案のみ）	プロンプト 7
クリックは多いのに売れていない対象の除外を提案する	除外候補の提案一覧	変更なし（提案のみ）	プロンプト 8
配信が止まっている広告の再開プランを出す	原因と再開アクションの提案	変更なし（提案のみ）	プロンプト 9

プロンプト 1: 判定ルールを保存する

入札・予算・除外キーワードなどの判定基準をアカウントに保存し、以降の最適化プロンプトから自動参照させます。

こんな時に使う — 同じ判定基準を毎回書くのをやめて、ルールとして固定したいとき。

実行前に必要な情報 — ルールの種別と、判定に使う基準値（目標 ACoS、最小クリック数など）。

{{ルール種別（例: 入札最適化）}} の判定ルールを登録して:
- 目標 ACoS: 15%
- 評価対象とする最小クリック数: 10 以上
- 評価対象とする最小注文数: 1 以上
- 反映方法: 承認するまで反映しない（提案として返す）

変更できる条件 — ルール種別（「入札最適化」「キーワード入札」「予算」「掲載位置倍率」「除外キーワード」「検索結果上部の表示シェア」「複合」など）、目標 ACoS、最小クリック数・最小注文数のしきい値。目標 ACoS は KPI 目標を登録済みなら省略できます。

返ってくる内容 — 登録内容の表と、どの最適化プロンプトから自動参照されるかの案内。

設定変更 — 判定ルールをアカウントに登録します（広告設定は変更しません）。反映モードは「承認するまで反映しない」で固定されます。

用語補足 — 最小クリック数・最小注文数のしきい値は、データが少ない対象を誤って判定しないための目安です（例では 10 クリック・1 注文）。

次にすること — 登録したルールは入札単価を調整する・予算を調整する・除外キーワードを追加するが参照します。

プロンプト 2: 提案の詳細を確認する

提案 ID から各項目の中身（現在値・推奨値・理由）を一覧表示し、一部だけ反映する準備に使います。

こんな時に使う — 提案を全件反映する前に、項目ごとに中身を見て取捨選択したいとき。

実行前に必要な情報 — 提案 ID。

目的: 承認前に提案内容を正確に把握し、誤った変更の反映を防ぐ。

提案ID {{提案ID（例: campaign-1787102102700-xxxxx）}} の詳細を表示してください。

【必ず表示する】
- 項目ID（item id）
- 現在値 / 推奨値 / 推奨の理由
- 各項目の metadata に入っている設定値
- proposal の type と account_id、失効日時（expires_at）
- 表示した項目数

【🔴 proposal の type で見る場所が変わる。必ず分岐する】
A. キャンペーン新規作成の提案（type=campaign）のとき
- items[] はサマリだけです。campaign_plan_raw を必ず見てください。
  SP の提案では campaign_plan_raw.steps[] に Amazon Ads API に送る実のリクエスト body が全階層分入っています。
  実測で確認できた項目:
  ・ campaign: name / targetingType / state / budget{budget,budgetType} / dynamicBidding / portfolioId
  ・ adGroup: name / state / defaultBid
  ・ productAd: sku / state
  ・ keyword: keywordText / matchType / state / bid
  ・ 各 step の nameSource / nameSourceLabel（名前が利用者指定か命名規則由来かが分かる。例: "user-override" / "by user override"）
- 項目数は campaign_plan_raw.summary に入っています（campaigns / adGroups / productAds / keywords / negativeKeywords / targets の内訳）。
  これを使って階層ごとの件数を提示してください。
- 🔴 階層で state が違うことがあります。 実測では campaign が PAUSED なのに adGroup / productAd / keyword は ENABLED でした。
  「作成時の状態」をまとめて１つとして書かず、階層ごとに列挙してください。
- ※ SB / SD のキャンペーン提案には campaign_plan_raw がありません。metadata も
  {name, budget, budgetType}（SB）/ {name, budget, tactic}（SD）だけで、渡した開始日と
  ポートフォリオはエコーされません。この場合は「提案の差分には出ない項目」として列挙し、
  提案を作ったときのリクエスト内容を利用者に再提示させて照合してください。

B. 入札・予算などの調整提案（type=budget / 入札系）のとき
- items[] の metadata に 書き込み先の親 ID が入ります。
  入札系では targetId / targetKind / campaignId / adGroupId と、判断根拠の clicks / spend / sales / orders を確認できました。
  よって「親 ID が返らない」と断定せず、まず metadata を見てから判断してください。
- 予算提案の items には id / label / current_value / recommended_value / reason しか入らないことがあります。
  spend / sales / estimated_impact は存在しないので、差額を効果額として提示しないでください。

【必ず「未取得」と明記する】
上記 A / B を見たうえでなお取得できなかった項目だけを、推測で補わず「MCP からは取得不可」と明記してください。
例（実測で確認したもの）:
- SP キャンペーン新規作成での開始日— 作成ツールの config に開始日の項目がそもそも存在しないため、
  campaign body にも startDate は入りません（Amazon 側の既定で決まる）。「未指定（作成時点で開始）」と書いてください。
  ※ SB / SD は開始日を引数として受け取るのに差分に出ないだけなので、扱いが違います。混同しないでください。
- 既存エンティティの現在の実態（新規作成の提案は currentValue が "(new)" になるだけで、
  同名キャンペーンが既に存在するかを提案側では判定しません）

【承認前の必須確認】
1. 新規作成の提案なら、campaign_plan_raw の portfolioId ・ sku ・ keywordText ・ matchType を
   実在確認してください（ポートフォリオ一覧・SKU 逆引き・キャンペーン一覧で照合）。
   🔴 存在しない ID でも proposal は生成されます（作成時に実在検証されません）。
   提案が生成できたことを「対象が実在する証拠」にしないでください。
2. 調整提案なら、metadata の campaignId / adGroupId を一覧取得ツールで照合してください。
3. metadata と campaign_plan_raw のいずれからも対象を特定できない場合は、提案を作成したときに指定した
   {{対象キャンペーンID}} / {{対象広告グループID}} を利用者に再提示させ、
   それが実在し意図した対象かを一覧取得ツールで照合してから承認可否を答えてください。
   照合できない場合は「承認不可（対象未確認）」と結論してください。

【有効期限】
提案は生成から24時間で失効します（expires_at を必ず提示）。
提案 ID を後から一覧で探す手段はないので、承認しないと決めた提案はその場で破棄し、
破棄したことを報告してください（放置すると後日別の担当者が承認できる経路が残ります）。

この結果を使う次のプロンプト: {{接続先（例: 提案を承認して反映する）}}

変更できる条件 — （なし。表示するだけです）

返ってくる内容 — 項目 ID × キャンペーン × 対象 × 現在値 × 推奨値 × 理由の表。

設定変更 — 変更なし（読み取り専用）。何も反映されません。

次にすること — ここで確認した項目 ID を、そのままプロンプト 2 の一部反映に渡せます。

プロンプト 3: 終わらせるべき季節キャンペーンを見つける

過去 14 日の商品（SKU）別の広告利益から、そろそろ終わらせるべき季節ものキャンペーンを判定します。

こんな時に使う — セール・季節商品の広告を、いつ止めるか判断したいとき。

実行前に必要な情報 — （対象期間は既定で過去 14 日）

過去{{対象期間（例: 14日）}}の実績から、終了すべき季節キャンペーンを判定して。

0. 【確定データ境界】まず取込状況を確認し、未確定の日（当日を含む）を集計期間から除外する。実際に使用した確定期間を明示する。未確定日を推移の最終点に含めない。
1. 【識別】「季節キャンペーン」の判定基準として季節・イベント語のリスト（春/夏/秋/冬/雪/紅葉/クリスマス/バレンタイン/ホワイトデー/福袋/母の日/父の日/ハロウィン/年末年始/新生活/ベスコス/限定/セール/プライムデー 等）を先に列挙してから、SP/SB/SDを全件横断検索する。取得件数/総件数・ページングを最後まで処理したかを明示（打ち切りを全件として扱わない）。
   - 語が商品ライン名・ASIN文字列・社内コードの一部に偶然一致する誤検出を必ず排除する。候補は「広告グループ→プロダクト広告→ASIN→商品名」まで辿り、季節商材か通年の商品ラインかを確認してから採用する。除外した候補と理由を列挙する。
   - キャンペーンに季節を示すフィールド（終了日・スケジュール・イベント紐付け）は存在しないため、同定は名称に基づく推測であることを明記し、名称に季節語を持たない季節キャンペーンは検出できない旨を網羅性の限界として書く。
   - 判定対象は稼働中（配信状態が有効 かつ 広告費>0）のものに限る。0件ならその旨を述べて終了。
2. 【推移】対象キャンペーンの売上・ROASを、確定期間を前半/後半に2分割した2点で比較する。分割の合計が全期間の集計と一致することを確認し、一致しない場合は「単一期間の集計値のみ」と明示して「トレンド/推移」の語を使わない。
3. 【在庫】対象キャンペーンで配信中の広告のASINについて、在庫数・週次出荷・在庫週数を併記する。停止中の広告のASINは含めない。
4. 【効率の基準】原価が未接続の場合は明示し、ROAS/ACoSを「効率の代理指標」と注記する。判定の基準線としてアカウント全体のROASを取得して併記する。
5. 【終了判定の基準】次を全て満たすものだけを終了推奨とする（充足した条件を必ず明記）:
   (a) 後半期間の売上が前半比で {{減衰閾値（例: -30%）}} 以下
   (b) 後半期間のROASがアカウント全体ROASを下回る
   (c) 在庫週数が {{在庫週数の下限（例: 4週）}} 未満でない（在庫消化目的の継続を誤って止めないため）
   (a)(b)のみ該当は「観察継続」、いずれも非該当は「据え置き」とする。
【制約】実在未確認のキャンペーンへの推奨禁止。表の見出しと中身を一致させる。上位N件限定時は総件数明示。名称推測は明記。書き込み系操作は実行しない（キャンペーンの停止、自動化ルールの作成・更新・削除を含む）。

最後に次の3点を出力してください。
1. 推奨アクション — 終了推奨/観察継続/据え置きを優先度付きで提示し、終了推奨には削減見込み広告費（確定期間の実績広告費を日割りした月額換算）を算出根拠つきで併記する
2. 実行方法 — 終了推奨キャンペーンは、ユーザーが対象と停止理由を確認・承認してから停止する（このプロンプトでは実行しない）
3. 測定 — 承認後の停止実行から{{評価日（例: 14日後）}}にアカウント全体ROASと在庫状況を再確認する。再確認時も未確定日を除外した確定期間で切る

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

返ってくる内容 — キャンペーン × 過去 14 日の売上推移 × ROAS × 終了推奨の判定 × 理由の表。

設定変更 — 変更なし（分析・提案のみ）。実際のキャンペーン終了は手動で行います。

次にすること — 在庫状況とあわせて判断したい場合は在庫と販売機会を管理するを併用します。

プロンプト 4: 予算の使いすぎを通知する

配信中のすべての SP キャンペーンの予算消化ペースを見張り、日予算を 15% 超えたら通知します。

こんな時に使う — 予算を使いすぎたときに、あとで気づくのではなくその都度知りたいとき。

実行前に必要な情報 — 通知する超過の割合（既定は 15%）。通知の連携設定（上の注記を参照）。

配信中のすべての SP キャンペーンの予算消化ペースを見張って、
1 日の予算を 15% 超えたら通知して。

変更できる条件 — 超過の割合（例では 15%）。

返ってくる内容 — 通知条件の確認と、直近 1 週間の超過実績。

設定変更 — 通知条件を登録します（広告設定は変更しません）。通知の配信には追加の連携設定が必要です。

次にすること — 予算そのものの見直しは予算を調整するで行います。

プロンプト 5: 週次サマリーを定期配信する

週次の SP パフォーマンスサマリーを、決めた曜日・時刻に自動で作成・配信します。

こんな時に使う — 毎週の成績を、手作業でまとめずに定期的に受け取りたいとき。

実行前に必要な情報 — 配信する曜日・時刻（例では毎週水曜 13 時）。配信の連携設定（上の注記を参照）。

毎週水曜 13 時に SP の週間パフォーマンスサマリーを作って、
前週比（WoW）の比較を含めて配信して。

変更できる条件 — 配信する曜日・時刻。

返ってくる内容 — 配信スケジュールの確認と、直近 1 週間サマリーのプレビュー。

設定変更 — 配信設定を登録します（広告設定は変更しません）。配信には追加の連携設定が必要です。

次にすること — レポートの中身をカスタマイズしたい場合はレポートを作成するを使います。

プロンプト 6: 予算が余っている広告で成果の高い商品に入札を強める提案を作る

予算を使い切れていないキャンペーンの中で、成果の高い商品（ASIN）に対して入札を引き上げる提案を作ります。

こんな時に使う — 予算に余裕があるうちに、伸びている商品へ配分を寄せたいとき。

実行前に必要な情報 — 予算消化ペースのしきい値（既定は 70% 未満）。

予算消化に余力があるSPキャンペーン内の高効率ターゲットに対して、入札引き上げ案を提案して。

【前提】
- 分析期間は{{分析期間（例: 直近14日・確定日まで）}}とし、当日は未確定のため含めない。
- 目標ACoS{{目標ACoS（例: 35%）}}を必ず指定する。未指定だと観測TACOSが暫定軸に使われ down_or_maintain_only となり、増額提案が0件になるため。

【手順】
1. ENABLEDのSPキャンペーンをstart_existing_sp_campaigns_jobで取得し、get_mcp_job_statusがcompleteかつtruncated=falseであることを確認してからget_mcp_job_resultを取得する。running状態のまま件数を確定しない。「取得件数/総件数」を明示する。このジョブが返すのはキャンペーン単位の行のみで、広告グループ・商品広告の入れ子は含まれない。
2. 消化率は次の式で自分で計算する。返却フィールドbudgetUtilizationRateをそのまま消化率として使わない（実体は「期間合計spend ÷ 1日分のdailyBudget」で、期間日数の分だけ倍率がずれる）。
   消化率 = 期間合計spend ÷ (dailyBudget × 分析期間の日数)
   各行に分子と分母の値を併記する。
3. 消化率が{{消化率しきい値（例: 70%）}}未満かつROASが{{ROASしきい値（例: 3倍）}}以上のキャンペーンを全件列挙し、件数と表の行数を一致させる。期間内spend=0の行は「配信実績なし」として別掲し、消化率0%の余力として増額候補に混ぜない。集計していない件数を書かない。
4. 該当キャンペーンをcampaign_idsに指定してoptimize_target_bidsを目標ACoS付きで呼ぶ。target_fetch_truncated / target_fetched_pages / target_total_pages_availableを読み、ターゲット取得率を「取得ページ/全ページ」で明示する。これらのフィールドが応答に現れない場合は打ち切りが起きていないので「全件取得」と明記する。
5. get_proposalで明細を取得し、metadataのspend/sales/orders/clicksを使って広告費の大きい順に並べる（optimize_target_bids の直接応答には metadata が入らないため、必ず get_proposal を経由する）。現在入札額(currentValue)・提案入札額(recommendedValue)・差額・算出根拠(reason)を金額で提示する。
   Amazon推奨入札額は入札提案のitemsには含まれないが、ターゲット実績一覧から推奨入札額（suggested_bid）を別途取得し、metadataのtargetIdで突き合わせて併記できる。入札提案ツールの出力だけを根拠に「推奨入札額は取得不可」と結論しないこと。推奨入札額が返らないターゲット（停止中など）は「推奨入札額は取得不可」と明記し、0として扱わない。
   最大CPCを返す面はないので「取得不可」と明記する（無い値を推測で埋めない）。
6. Branded面と獲得面をキャンペーン名で分け、Branded面はACoSの低さを増額根拠にしない。増額提案はBranded以外を優先する。
7. 提案単位は「ターゲット（キーワード／商品ターゲット）」であることを明記する。商品ターゲットのASINは広告対象の自社ASINではなくターゲティング先ASINである点を明示し、キャンペーン単位の消化率とASIN単位の指標を混同しない。

【制約】
- 推測での補完禁止。MCPが返さない指標は「取得不可」と書く。ただし別のツールから取れる値を「取得不可」と書かないこと。
- 提案の提示までとし、execute_proposal / execute_ads_adjustment_workflow / update_*等の書き込み系は一切実行しない。
- 生成されたproposalは提示後にcancel_proposalで削除し、get_proposalで消失を確認する。

実行前に必ず: 変更内容の一覧（対象・現在値・変更後の値・Amazon推奨入札額・広告費インパクト）を提示し、承認を得るまで媒体に反映しないでください。
実行後: 提案内容をユーザーが確認・承認したうえで反映し、{{評価期間（例: 14日）}}後に「施策の効果測定」でROASとACoSを比較し、悪化していればRevert、改善していればKeepと判定してください。

変更できる条件 — 予算消化ペースのしきい値（例では 70% 未満）。

返ってくる内容 — キャンペーン × 商品（ASIN）× 今の入札 × 提案する入札 × 見込める消化率の表。

設定変更 — 変更なし（提案のみ）。反映はプロンプト 2 の承認フローで行います。

用語補足 — 70% 未満は「予算をまだ使い切れていない」と判断する目安です。

次にすること — 提案を反映するときはプロンプト 2 へ。

プロンプト 7: クリックは多いのに売れていない対象の除外を提案する

過去 14 日でクリックは多いのに売れていない検索語句・商品ターゲティングを見つけ、除外の提案を作ります。

こんな時に使う — コストばかりかかって売上につながらない対象を整理したいとき。

実行前に必要な情報 — クリック数・CPC・ROAS のしきい値（既定は下記）。

過去{{評価期間（例: 14日）}}の広告ターゲット実績から、クリック20以上・CPC100円超・ROAS0.5未満（＝ACoS200%超）を同時に満たす無駄打ちターゲットを洗い出し、除外候補一覧と除外提案（Proposal）を作成してください。媒体への反映は承認まで一切行わないこと。

【手順】
1. 期間の確定: get_data_ingestion_status で「Targeting SP」が completed の最終日を確認し、その日を終了日として評価期間ぶんさかのぼった開始日を決める。当日は fully_missed になりやすく、そのまま「過去N日」と書くと無警告で実効N-1日になるため、実際に使った from_date / to_date を必ず出力に明記する。rollup_status ではなくレポート別の status を見る。

2. 🔴 候補の取得は min_clicks を必ず渡して行う。 list_target_performance を min_clicks=20・target_types 指定で呼びます。
   min_clicks は上流サーバ側で絞り込まれるので、母集団が最初から小さくなります。
   応答の server_filter_applied が true になっていることを確認して出力に明記してください。
   ※ 「上流が売上降順なので高ACoS・低売上は取り漏らす」という回避策は不要です。
     絞り込みを指定すると並び順は clicks 降順に変わり、高ACoS・低売上の行は（クリックがあるので）すべて母集団に入ります。
     実測: min_clicks=10 / target_types=KEYWORD / 14日 で total_results 295 に対し fetched_row_count 295 で網羅率100%。
     その中に ACoS 1578% （売上¥800 / 広告費¥12,627）のような行も、売上0の行も含まれていました。
   ※ 低売上層をさらに絞りたい場合は max_sales を併用してください（取得後に適用され、filtered_row_count に反映されます）。
   ※ campaign_id での絞り込み引数は存在しないので、キャンペーン別の内訳は返った行の campaign_id で自分で集計してください。

3. 自算: 各行の CPC＝spend÷clicks、ROAS＝sales÷spend を自分で計算し、3条件を満たす行だけを残す。
   応答の roas 欄・acos 欄は百分率表記であり倍率ではないので閾値判定に使わないこと
   （実測: sales 2,540 / spend 5,160.09 の行で roas 欄は 49.22。つまり 0.4922 でなく 49.22%）。

4. 前処理: (a) 応答の duplicate_rows_folded を確認して載せる。この値が返る場合はツールが既に重複を畳んでいるので自前の重複排除は不要（返らない場合のみ target_id + ad_group_id で排除）。(b) campaign_type を確認し SP / SB / SD を分けて表示する（除外の実行ツールが別系統になるため）。

5. 売上ゼロ候補の取得: 🔴 zero_sales_only=true を min_clicks と一緒に渡して直接取得してください。
   これは上流サーバ側フィルタなので売上ゼロの行に直接到達できます
   （実測: zero_sales_only=true + min_clicks=5 で total_results 182 / fetched 175 = 網羅率 96.2%。
   返った行は sales/units/purchases がすべて0で spend は¥5,357〜¥12,331 あった）。
   「売上ゼロのターゲットは構造的に1件も取得できない」というのは誤りです。
   ※ zero_sales_only は sales が未取得（null）の行も 0 として含むので、行ごとに sales / units / purchases の3つとも 0 であることを確認してから候補に入れてください。
   detect_negatives を併用する場合は補助として使い、search_term_fetched_pages / search_term_total_pages_available を転記してください（candidates_truncated が false でも上流は打ち切られていることがある）。

6. 出力: 語句/ASIN・種別（KEYWORD/TARGET）・広告種別（SP/SB/SD）・キャンペーン名・campaign_id・クリック・消費・売上・算出CPC・算出ROAS・suggested_bid を併記し検算可能にする。「売上ゼロ群」と「低ROAS群」を別表にし、それぞれ消費の大きい順に並べる。比率を出すときは分子・分母・日数を必ず併記する。

7. 取得率の明示: total_results / fetched_row_count / filtered_row_count / returned_row_count をそのまま転記し、網羅率 = fetched_row_count ÷ total_results で計算してください。
   絞り込みを渡しているときの total_results は「期間内の全ターゲット数」でなく「条件に該当する総件数」です。この区別を書いてください。
   網羅率が100%なら「この条件下では全件」と書いてよく、100%未満なら max_pages を上げて（上限 100 ページ = 10,000 行、既定 20）再取得してください。それでも届かない場合は「該当件数は確定できない」と明記してください。

【制約】
- 除外登録・入札変更などの書き込み系操作は一切実行しない。Proposal の生成までとし、execute_proposal は呼ばない。
  生成した Proposal は承認しなければ必ず破棄し、破棄したことを報告する（提案は24時間アカウントに承認待ちとして残り、一覧で探す手段はありません）。
- 巻き戻し経路を承認前に確認する: SPキーワード除外は update_sp_negative_keywords で state=PAUSED に戻せるが、対象IDを引く list_sp_negative_keywords は ad_group_id を省略すると total_count=0 を返すため、除外した campaign_id と ad_group_id を必ず控える必要がある。この控えが取れない対象は除外候補から外す。
- 「自動除外」として無人運用しないこと。manage_automation_rules の negative ルールは Phase 1 で propose_only / on_demand のみで、定期自動実行はできない。
- 上流の集計は約4時間キャッシュされるので、直近の入札変更や配信実績が反映されていない可能性を明記する。

【Follow-up】承認後に除外を実行した場合、{{評価期間（例: 14日）}}後に対象キャンペーンのCTR・ROASを再取得し、CVR・売上への悪影響が無いか確認する。除外したターゲット単体でなく広告グループ単位で測ること（除外したターゲットは必ず -100% になるため）。

変更できる条件 — クリック数・CPC・ROAS のしきい値。

返ってくる内容 — 対象（検索語句・商品ターゲティング）× クリック × CPC × ROAS × 推奨マッチタイプの表。

設定変更 — 変更なし（提案のみ）。反映はプロンプト 2 の承認フロー、または除外キーワードを追加するで行います。

用語補足 — クリック 20 以上は判定に足るデータがある対象に絞るための目安、CPC 100 円超・ROAS 0.5 未満は「コストの割に売上が伴っていない」対象の例です。いずれも運用に合わせて変えられます。

次にすること — 除外の実行は除外キーワードを追加するへ。

プロンプト 8: 配信が止まっている広告の再開プランを出す

過去 24〜48 時間で配信がゼロになっている SP キャンペーンに対して、再開のプランを出します。

こんな時に使う — 動いているはずの広告が急に配信されなくなったとき、原因と対処を知りたいとき。

実行前に必要な情報 — 対象期間（既定は過去 48 時間）。

過去48時間で配信ゼロ（インプレッション=0）のアクティブSPキャンペーンを特定し、再開してよいものだけを選別した再開プランを提示してください。書き込み系操作は一切実行しないこと。

【0. 対象期間の確定（最初に必ず行う）】
get_data_ingestion_status で確定済み日付を確認し、rollup_status が fully_missed / in_progress の日を除外した「確定済みの直近2日」を対象期間とする。使用した期間と、除外した日付を必ず明記すること。
※未確定日を含む1日窓で判定すると全キャンペーンが「配信ゼロ」に見える。確定日を含む合算窓であれば未確定日が混ざっても結果は変わらないが、対象期間は必ず明示する。

【1. 母集団の確定】
start_existing_sp_campaigns_job（state=enabled, from_date/to_date=上記確定期間）→ get_mcp_job_status → get_mcp_job_result で ENABLED キャンペーンを全件取得する。同期版 list_existing_sp_campaigns はタイムアウトするため使わない。truncated / row_count を確認し、全件取得できたことを明示する。
「配信ゼロ」は impressions=0 と定義する。spend=0 や clicks=0 で代用しないこと（配信はしているがクリックが付かないだけの正常キャンペーンを取り込んでしまう）。impressions=0 / spend=0 / clicks=0 のそれぞれの件数を併記して、定義の差を可視化すること。

【2. 選定と並べ替え】
該当件数を全件明示したうえで、上位{{件数（例: 10件）}}を「日予算降順」で選ぶ。日予算はあくまで機会規模の代理指標であり、回復見込み額ではないことを明記する。恣意的な先頭抜粋は禁止。選んだ上位が母集団の日予算合計の何％を占めるかを併記すること。

【3. 各キャンペーンの原因切り分け（下記の順に必ず全て確認する）】
(a) 予算上限 — impressions=0 のキャンペーンは spend=0 なので予算上限は原因になりえない。spend>0 のときのみ検討する。
    ※budgetUtilizationRate は「spend ÷ dailyBudget」で、期間日数で割られていない。2日以上の窓では実態の日数倍に膨らむため、必ず「期間spend ÷（dailyBudget × 対象日数）」に正規化してから判定すること。
(b) 広告（商品）側の停止 — list_sp_product_ads で各広告グループの product ad の state を取得する。ENABLED の広告が0件、または大半が PAUSED / ARCHIVED なら、入札や予算を触っても配信は戻らない。これを最優先で確認する。
(c) 在庫 — ENABLED の広告に紐づく ASIN を get_fba_inventory で確認する。daysOfSupply が評価期間を下回る、または sellableInventory が僅少なら「再開しない（在庫確保が先）」と判定する。在庫を確認せずに再開を推奨しないこと。
(d) ターゲットの絞り込みすぎ — list_sp_keywords でターゲットを実取得し total_in_period を明示する。0件なら「ターゲット取得できず」と明示し入札値を書かない。keyword_fetch_truncated が true の場合は取得ページ数と総ページ数を併記する。
(e) 入札不足 — current_bid と suggested_bid の乖離率を出す。suggested_bid が null のターゲットが存在するため、乖離率を算出できた件数／サンプル件数を必ず併記し、算出できないものは断定しない。
(f) 上記のいずれでも説明できない場合は「原因不明」と明記する。推測で埋めないこと。
※IS%（インプレッションシェア）はターゲット単位では取得できないため、根拠に用いない。

【4. 意図的停止の扱い（省略不可）】
キャンペーンには終了日フィールドが無く、manage_event にもキャンペーン紐付けが無いため、「季節施策の終了」「終売品」など意図的に止めたものを機械的に判別できない。したがって全件について「意図的停止かどうかは判定不能」と明記し、再開実行前に運用者の確認を必須とすること。キャンペーン名や広告のPAUSED状況から意図的停止が疑われるものは、その根拠とともに「要確認」として別枠に出すこと。

【Guardrail】
入札変更・状態変更・自動化ルールの作成／更新などの書き込み系操作は一切実行しない。承認後にのみ実行する。

最後に次の3点を出力してください。
1. 推奨アクション — 【3】の判定結果に基づき「再開推奨」「要確認（意図的停止の疑い／原因不明）」「再開非推奨（在庫不足・広告停止）」の3分類に振り分け、再開推奨のみ日予算規模順に優先度を付けて原因別の対処（入札引き上げ／広告の再有効化／ターゲット拡大）を示す。1件ごとに期待効果（回復見込みインプレッションと想定売上の根拠）を書き、根拠データが無い場合は「見積不可」と明記する
2. 実行方法 — 提案をユーザーが確認・承認してから反映する（このプロンプトでは実行しない）
3. 測定 — 再開後{{評価日（例: 7日後）}}にインプレッションとACoSを再取得する。再取得時も【0】と同じ確定データ境界を適用し、未確定日を含めないこと。回復かつACoS許容範囲内ならKeep、悪化ならRevertする