ラベルと命名ルールで広告を分類する

このページでは、検索語句・ASIN・キャンペーンにラベル（分類の目印）を付けて、「主力」「防衛」「切り出し対象」といった広告の役割や商品ラインの切り口で売上と広告費を読み解けるようにできます。あわせて、キャンペーンの命名ルールも統一できます。数千〜数万のキーワードを一件ずつ判断するのは不可能なので、役割ごとにまとめて扱えるようにするのがねらいです。

このページの基本情報

項目	内容
このページでできること	ラベル分類体系の設計、競合商品の自動ラベリング、検索語句への一括ラベル付け、キャンペーン命名ルールの管理
対象	検索語句・ASIN・SP キャンペーン・Amazon DSP のラインアイテム（横断）
必要なデータ・接続	接続済みアカウントの検索語句データ。競合商品の自動ラベル付けには、Picaro が取得する Amazon のカタログ情報（商品名・ブランド）を使用します
実行範囲	承認後に Picaro 側のラベル・命名ルールを変更（分析・提案 → 確認 → 反映）。広告設定（入札・予算・キーワード）そのものは変更しません

このページで使う言葉

• ラベル … 検索語句・ASIN・キャンペーンに付ける 1 つの分類の目印（例: 主力、競合／高価格帯）。
• ラベル分類体系 … ラベルをまとめる全体の構造。Picaro では 大分類 → 中分類 → 小分類 の 3 階層まで設計できます。
• 検索語句 … 買い物客が実際に入力した言葉。キーワード … 広告主が広告に登録した言葉。
• ASIN … Amazon の商品識別番号（B0XXXXXXXX 形式）。ここでは主に検索語句に紛れ込んだ競合商品を指します。
• ROAS（広告費用対効果）／ACoS（広告費用対売上高比率）… 広告効率の指標。

1 対象 = 1 ラベル。付け直すと上書きされます

Picaro では 1 つの検索語句 / ASIN / キャンペーンに付けられるラベルは 1 つまでです。新しいラベルを割り当てると既存のラベルは警告なしで上書きされ、元の状態には自動で戻りません。

このため、ラベルを割り当てるプロンプトは まず実行プランを確認 → 問題なければ本実行 の 2 段構えで使ってください。「まず実行プランだけを見せて」と頼めば、書き込み前に内容を確認できます。

• 上書きが発生しない場合のメッセージは「対象の分類が空」と「既に同じラベルが付いている」の両方を意味することがあり、実行結果だけでは区別できません。「新規に付いた」と断定せず、「上書きは発生しない（既存同一の可能性もある）」と読んでください。
• 商品（ASIN）は現在のラベルを事前に確認する手段が無く、実行プランの時点でも上書きの有無を検出できません。既存の共通ラベルがあれば消えるものとして扱ってください。
• Amazon DSP のラインアイテム ID を一覧で取得する手段は現在ありません。 DSP ラインアイテムにラベルを付けたい場合は、Amazon DSP の管理画面で ID を確認してから指定してください。

こんな時に使います

• 数千〜数万のキーワードを、主力／利益エンジン／防衛／探索／切り出し対象 の 5 つの広告役割で自動分類したい
• 検索語句に紛れ込んだ競合商品（ASIN）に、商品名とブランドでラベルを自動で付けたい
• 一度設計したラベルのルールを、既存の検索語句に一括で適用したい
• キャンペーンの命名ルールを統一して、レポートの集計を安定させたい
• ラベルごとに ACoS・ROAS・予算配分の目標を別々に管理したい

---

なぜラベルが必要なのか

Amazon 広告の管理画面は、キャンペーン・広告グループ単位の集計が基本です。「全体 ACoS が 35% でした」という数字は分かっても、主力のキーワードが効いているのか、防衛が崩れているのか、切り出し候補が広告費を食っているのかは見えません。

キーワード数が数千〜数万になると、1 件ずつ判断するのは不可能です。「どのグループが利益を生み、どのグループが赤字なのか」を広告の役割でグルーピングしないと運用が回りません。代理店が複数クライアントを担当する場合も同じで、「なぜ ACoS が悪化したのか」をデータで説明しようとすると、手作業で CSV を加工することになりがちです。

ラベルはこのギャップを埋める仕組みです。検索語句・ASIN・キャンペーンに「主力」「防衛」「切り出し対象」などの分類を付けることで、同じ広告費・売上データを役割の切り口で集計・比較できます。入札調整やレポートの根拠が「感覚」から「データ」に変わり、AI エージェントへの指示も「主力のキーワードの入札を見直して」のように高い視点で出せるようになります。

ラベルで何が変わるか

ラベルなし（現状）

「今月の全体 ACoS は 35% でした。先月比で 3pt 悪化しています。」

ラベルあり（Picaro のラベル適用後）

ラベル	売上比率	ACoS	評価
主力（自社ブランド指名の検索語句）	42%	12%	スケール継続
防衛（ブランド + カテゴリー）	18%	18%	効率維持
利益エンジン（ニッチ用途）	20%	18%	段階的に拡大の余地
探索（新規・学習中の検索語句）	10%	32%	観測を継続
切り出し対象（競合商品・低 ROAS の語句）	10%	78%	整理候補

ラベル別に見ると「ACoS の悪化は、切り出し対象のグループが広告費を食っているため」とすぐ特定できます。代理店であればクライアントへの説明が「数字の羅列」から「戦略の説明」に変わり、入札調整の目標 ACoS もラベルごとに別々に設定できます。

Picaro 推奨のラベル設計 — 2 つのパターン

ラベル分類体系の設計には大きく 2 つのパターンがあります。どちらが正解ということはなく、商品ラインの数と分析の主軸によって選びます。

	パターン A: 広告役割ファースト	パターン B: 商品ラインファースト
向いている状況	商品ライン 1〜2 種類 / キーワード数千件以上	商品ライン 3 種類以上 / サブブランド複数
大分類（第 1 層）	広告役割（主力 / 利益エンジン / 防衛 / 探索 / 切り出し対象）	商品ライン / サブブランド
中分類（第 2 層）	商品ライン or トピック	商品バリエーション / 顧客ステージ
小分類（第 3 層）	マッチタイプ or 具体的な語句	語句のタイプ（自社ブランド名 / 一般語 / 競合名）
強み	各語句が広告にどう貢献しているかが即座に分かり、打ち手に直結	商品ライン別の ACoS・粗利を独立して管理しやすい

パターン A: 広告役割ファースト型

数千〜数万のキーワードを、広告に与える影響・役割で分類する設計です。「このキーワードが広告全体にどう貢献しているか」を即座に把握でき、入札調整・除外判断・予算配分の打ち手に直結します。商品ラインが少なく、キーワード数が多い場合に向いています。

大分類	意味	該当する典型例	入札・予算スタンス
主力（Hero）	高 ROAS × 高ボリュームの売上ドライバー	自社ブランド指名の語句、定番商品の主要な語句	スケール優先・予算厚め
利益エンジン（Profit Engine）	高 ROAS × 中低ボリュームの隠れ優良	ニッチ需要・高粗利商品の語句	維持・段階的に拡大
防衛（Defensive）	ブランド指名・競合対策の防衛枠	自社ブランド + カテゴリー、競合ブランド名の語句	高入札・効率重視
探索（Exploration）	新規・学習中（判定材料が不足）	Auto 由来の新規語句、立ち上げ期の Manual 語句	低予算で観測
切り出し対象（Cut）	低 ROAS で整理予定	購入 0 件の語句、ACoS が目標の 2 倍超	除外候補化・段階的に停止

3 階層の展開例（数千のキーワードを運用するブランド）:

主力（大分類）
└── 商品ライン A（中分類）
    ├── Exact マッチ（小分類）
    ├── Phrase マッチ
    └── 商品ターゲティング
利益エンジン（大分類）
└── ニッチ用途（中分類）
防衛（大分類）
├── 自社ブランド（中分類）
└── 競合ブランド（中分類）
探索（大分類）
└── 新規語句プール
切り出し対象（大分類）
└── 整理待ちプール

このパターンが有効な理由:

• 数千〜数万のキーワードを 5 つの役割で粗くグルーピングでき、運用判断がスケールする
• ラベルがそのまま打ち手につながる（主力 → スケール、切り出し → 除外、など）
• ダッシュボードで「主力の ROAS が落ちた」「探索枠の予算がオーバーしている」が瞬時に分かる
• AI エージェントへの指示を「主力のキーワードの入札を見直して」のように高い視点で出せる

パターン B: 商品ラインファースト型

商品ライン（サブブランド）を最上位に置く設計です。商品ごとに ACoS 目標や粗利が異なる場合、まず商品ラインで切ることで KPI が混ざりません。最下層に「自社ブランド名（Branded）／一般語（Generic）／競合名（Competitor）」を置くと、「商品ライン A × 一般語の ACoS はいくつか」という粒度まで掘り下げられます。中分類に「新規／リピート」を置けば、新規獲得コストとリピート維持コストを分けて管理でき、LTV 視点の判断ができます。

まず大分類だけで始める

どちらのパターンでも、最初から 3 階層まで作り込むと管理コストが高くなります。まず大分類だけ（広告役割 5 つ、または商品ライン）で運用を始め、「商品ライン別の差が気になる」「マッチタイプ別に見たい」と感じたタイミングで中分類・小分類を足すのが現実的です。プロンプト 7 を使うと、既存の検索語句データから広告役割別のラベル分類体系案を自動生成できます。

Amazon ポートフォリオとの違い

Amazon のポートフォリオはキャンペーンを 1 階層でまとめるだけです。Picaro のラベルは 大分類 → 中分類 → 小分類の 3 階層で設計でき、検索語句・ASIN・キャンペーンすべてに横断適用できます。

プロンプト早見表

やりたいこと	分かること・作られるもの	設定変更	プロンプト
検索語句・ASIN に手動でラベルを直指定する	対象 × 割り当て後ラベルの一覧	承認後にラベルを付与（上書き）	プロンプト 3
キャンペーン・DSP・商品にラベルを付ける	対象 × 割り当て後ラベルの一覧	承認後にラベルを付与（上書き）	プロンプト 4
ラベル分類体系を確認・追加・初期化・削除する	操作別の結果	追加・更新・初期化・削除	プロンプト 5
キャンペーンの命名ルールを登録・推論する	命名パターン × 一致率の一覧	命名ルールを登録	プロンプト 6

プロンプト 1: 検索語句・ASIN に手動でラベルを付ける

自動マッチを使わず、指定したラベルに対して検索語句や ASIN を直接割り当てます。

こんな時に使う — 自動分類では拾えない対象に、狙って手動でラベルを付けたいとき。

実行前に必要な情報 — 割り当て先のラベル名（プロンプト 5 で現状表示すると一覧で確認できます）と、対象のリスト。

ラベル「{{ラベル名（例: 競合 / 高価格帯）}}」に対して、
以下の検索語句 / ASIN を直接割り当てて:
{{対象リスト（例: term1, term2, B0XXXXXXXX）}}

まず内容を確認させて、問題なければ本実行して。

変更できる条件 — ラベル名、対象リスト（検索語句や ASIN）。

返ってくる内容 — 対象 × 種別（検索語句 / ASIN）× 既存ラベル × 割り当て後ラベルの表。すでにラベルが付いている対象は「上書きになる」と明示されます。

設定変更 — 承認後に Picaro 側でラベルを付与します（既存ラベルは上書き）。

次にすること — キャンペーンや商品にも付けたい場合はプロンプト 4 へ。

---

プロンプト 2: キャンペーン・DSP・商品にラベルを付ける

ラベルを SP キャンペーン、Amazon DSP のラインアイテム（DSP の配信設定の単位。DSP を配信しているアカウントのみ）、商品 ASIN に割り当て、ダッシュボードや N-gram の集計軸として使えるようにします。

こんな時に使う — 検索語句だけでなく、キャンペーンや商品自体も役割で分類したいとき。

実行前に必要な情報 — 割り当て先のラベル名と、付けたい対象。

ラベル「{{ラベル名（例: 主力 / 商品ライン A）}}」に、以下を割り当ててください。
- SP キャンペーン: {{キャンペーン名や ID（複数可）}}
- 商品 ASIN: {{ASIN（複数可）}}
- DSP ラインアイテム: {{DSP ラインアイテム ID（複数可・任意）}}

🔴 この操作は既存ラベルを黙って消すことがあり、元に戻せません。下記の順序を必ず守ってください。

【前提: 1エンティティ = 1 column = 1 ラベル】
Picaro は「1キャンペーン（ラインアイテム・商品）につき、同じ column（最上位ラベル）には1つのラベルだけ」という制約を警告なしで強制します。
同じ column に既存ラベルがある状態で別ラベルを付けると、既存の割当は消失し、割当解除では復元できません。

【手順】
1. ラベルの特定。ラベル名から内部 ID（label_id）を特定します。
   ラベルの一覧を返す専用ツールはありませんが、ラベル別 KPI 集計ツールを apply_to を変えて呼ぶと
   root_label_id / root_label_name / label_id / label_name が一覧で返るので、これをラベル台帳として使います
   （apply_to=SA で SA キャンペーンラベル、apply_to=ALL で共通ラベル。分類ルール側は分類体系管理ツールの show でも見られます）。
   特定した label_id と、それがどの tree（SA / DSP / ALL / SEARCH_TERM）のどの階層なのかを必ず提示してください。
   ※ tree が合っていないと割当できません。キャンペーンには SA または ALL、DSP ラインアイテムには DSP または ALL、
     商品には ALL のみ（SA/DSP 専用ラベルは商品に付けられない）です。
2. 対象 ID の実在確認。キャンペーン名で指定された場合は、キャンペーン一覧を名前の部分一致で引いて
   campaign_id に解決し、名前と ID の対応を提示してください。推測で ID を作らないでください。
   ※ キャンペーン名の区切り文字には半角 | と全角 ｜ が混在します。
   商品は ASIN をそのまま渡せます（ツール側で内部 UUID に変換され、未登録 ASIN はスキップされて warning になる）。
   スキップされた ASIN は必ず件数と内訳を出力に載せてください。
3. 🔴 必ず dry_run でプレビューする（既定は dry_run）。割当ツールを dry_run のまま呼んで、
   ・解決された label（name / level / apply_to）と自動解決された root_id（column）
   ・割当経路（SA 専用 / 共通のどちらと自動判定されたか）
   ・対象件数と対象 ID
   ・上書きの有無（collisions）
   をそのまま提示してください。
   ※ 上書きなしの場合のメッセージは「column が空 or 既に同じラベルが付いている」の両方を含み、
     この2つを区別できません。「新規に付く」と断定せず、「上書きは発生しない（既存同一の可能性もある）」と書いてください。
   ※ 商品（ASIN）だけは現在ラベルを返す API がなく、dry_run でも上書きを事前検出できません。
     商品については「事前検出不可。既存の共通ラベルがあれば消える」と必ず警告してください。
4. 承認を求めて停止する。 上記1〜3を提示した時点で一旦停止し、利用者の承認を得てから本実行してください。
5. 本実行は dry_run を外して行います。実行後にラベル別 KPI 集計を再取得し、意図したラベルに
   対象が付いていることを確認して報告してください。

【上書きが必要な場合】
dry_run で上書きが検出されたときは、あなたの判断で上書きフラグを立ててはいけません。
消える既存ラベルを列挙して利用者に提示し、利用者から明示的な上書き指示を得てから、
その発言を引用形式で添えて実行してください（ツールは確認フラグと利用者発言の引用の両方を要求し、
短い定型句は監査証跡として不十分なため拒否します）。

【DSP ラインアイテムの扱い】
🔴 DSP ラインアイテムの ID を一覧で列挙する手段は MCP にありません。
DSP レポートはラインアイテム別の行を返しますが ID を含まないため、名前から ID への解決ができません。
よって DSP ラインアイテムの ID は Amazon DSP の管理画面で事前に確認し、私から渡してください。
ID が渡されていない場合は DSP の割当をスキップし、「DSP ラインアイテム ID 未提供のため未実行」と
明記してください（推測で ID を作らない。キャンペーンと商品の割当はそのまま進めてください）。
※ 共通ラベル（ALL）で集計する場合、ラベル別 KPI の ALL モードは SA キャンペーンと DSP の実績を
  合算して返すので、DSP 側を管理画面で別途ラベル付けしておけば、集計自体は成立します。

【出力】
割当前に、label_id / ラベル名 / tree / column（root_id）/ 対象種別ごとの件数 / 上書きの有無 /
スキップされた ASIN / 未実行にした対象とその理由 を一覧で提示してください。

【実行後】
ラベル軸での集計が意図どおりになっているかを、次回レポート作成時にラベル別 KPI で確認してください。
ラベル別 KPI の集計粒度は weekly / monthly のみで、任意日数の区間は切れないことに注意してください。

変更できる条件 — ラベル名と、割り当て対象（付けたいものだけ指定、不要なものは省略可）。

返ってくる内容 — 対象 × 種別 × 既存ラベルの状況 × 割り当て後ラベルの表。商品 ASIN は事前の重複チェックができないため、上書きリスクが「要注意」として明示されます。

設定変更 — 承認後に Picaro 側でラベルを付与します（既存ラベルは上書き）。

用語補足 — DSP の分析は Amazon DSP の配信実績を分析する を参照してください。AI エージェント環境によってはラベル割り当てが認識されない場合があります（修正中。Picaro 接続の拡張機能経由では動作する可能性があります）。

次にすること — 付けたラベルの成果は ダッシュボードで KPI を確認する で確認します。

---

プロンプト 3: ラベル分類体系を管理する

ラベル分類体系（カテゴリー階層 → ラベル）の現状確認・追加・更新・海外販路設定・初期化・削除を、1 つのプロンプトでまとめて行います。

こんな時に使う — ラベルの全体構造を整えたい・作り直したいとき。

実行前に必要な情報 — やりたい操作（下記のいずれか）。

ラベル分類体系(taxonomy)を管理する。まず現状を manage_taxonomy(show) で確認してから、以下のいずれかを実行して:

- 表示: 現在のtaxonomy構成をそのまま見せる
- 初期化: デモテンプレートから clone_default する
- 追加/更新: {{カテゴリー階層またはラベル定義（例: カテゴリー「香り」にラベル「シトラス」を追加）}}
- 海外販路設定: {{対象国のAmazonドメイン・通貨・言語（例: US / USD / English）}}
- 全削除して作り直す: **破壊的操作かつ実機確認で動作不安定と報告済みのため非推奨**。実行する場合は現状構成を提示し、承認を得てから実行する

整備後は、検索語句に紐づく競合商品の自動ラベル分類（プロンプト 1）や、検索語句への一括ラベル付け（プロンプト 2）の前提として使ってください。

変更できる条件 — やりたい操作の内容。

返ってくる内容 — 操作別の結果（一覧表示、追加・更新の確認、初期化完了など）。

設定変更 — 表示は変更なし。追加・更新・初期化・削除は Picaro 側の構造を変更します。全削除は破壊的なため、明示的に確認したうえでのみ実行します。

次にすること — マッチパターンを変えたら、再ラベリングはプロンプト 2 を別途実行してください。

---

プロンプト 4: キャンペーンの命名ルールを登録・推論する

キャンペーン・広告グループの命名テンプレートを登録し、新規作成時の命名をそろえます。既存の名前から命名パターンを推論することもできます。

こんな時に使う — キャンペーン名がばらばらで、レポートの集計が安定しないとき。

実行前に必要な情報 — 命名テンプレート（自社ルール）か、推論の材料にする既存キャンペーン名。

キャンペーン / 広告グループの命名規則を管理して:

- 既存のキャンペーン名{{件数（例: 50）}}件くらいから命名パターンのドラフトを推論して
- もしくは、命名テンプレート {{命名テンプレート（例: {ブランド}_{商品ライン}_{マッチタイプ}）}} を登録して
- もしくは、既存ルールを更新して

推論・登録したテンプレートは、以降の新規キャンペーン作成（「スポンサープロダクト広告（SP）を作成する」）の命名に適用してください。

変更できる条件 — 命名テンプレート（{ブランド}_{商品ライン}_{マッチタイプ} のように波括弧で表す）、推論に使うサンプル件数（30〜100 件程度が目安）。

返ってくる内容 — 推論された命名パターン × 一致率 × 例の表。

設定変更 — 推論（ドラフト返却）は変更なし。登録・更新は命名ルールを Picaro に保存します。

次にすること — 登録した命名ルールは スポンサープロダクト広告（SP）を作成する の新規作成時に自動適用されます。

関連カテゴリ

• ダッシュボードで KPI を確認する — ラベル分類別の KPI 集計の前提
• N-gram で成果の高い検索パターンを分析する — ラベル分類別のクラスタリングの実行先
• 検索から購入までのどこでつまずいているかを分析する（SQP） — ラベル別に市場での立ち位置を読み解く
• スポンサープロダクト広告（SP）を作成する — 命名ルールとラベル設計の利用先