ラベル分類を設計する

検索語句・ASIN・キャンペーンに ラベル（個別の分類値）を割り当てると、ダッシュボードや N-gram 分析で「主力 / 利益エンジン / 防衛 / 探索 / 切り出し対象」のような 広告役割の切り口 で売上と広告費を読み解けます。ラベル分類体系（ラベルをまとめる全体構造）を設計し、競合 ASIN を自動でラベリングし、検索語句に一括でラベルを付け、命名規則を管理するプロンプトをこのページにまとめています。数千〜万単位のキーワードがある中で、各 KW が広告にどう影響を与えているか を分類することが、運用判断をスケールさせる鍵になります。Picaro のラベルは 大分類 → 中分類 → 小分類 の 3 階層まで設計でき、Amazon ポートフォリオでは不可能な粒度で売上と広告費を分解できます。

なぜラベルが必要なのか

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

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

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

ラベルで何が変わるか

ラベルを設計・適用すると、分析とレポートの解像度が大きく変わります。

ラベルなし（現状）

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

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

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

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

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

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

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

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

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

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

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

主力（大分類）
└── 商品ライン A（中分類）
    ├── Exact マッチ（小分類）
    ├── Phrase マッチ
    └── ASIN ターゲット

利益エンジン（大分類）
└── ニッチ用途（中分類）
    ├── 用途 X
    └── 用途 Y

防衛（大分類）
├── 自社ブランド（中分類）
└── 競合ブランド（中分類）

探索（大分類）
└── 新規 KW プール

切り出し対象（大分類）
└── 整理待ちプール

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

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

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

商品ライン（サブブランド）を最上位に置く設計です。商品ごとに ACoS 目標や粗利が異なる場合、まず商品ラインで切ることで KPI が混在しません。

3 階層の展開例（複数商品ラインを持つブランド）:

商品ライン A（大分類）
├── スタンダード（中分類）
│   ├── Branded（小分類）
│   ├── Generic
│   ├── Competitor
│   └── Auto
├── 大容量・まとめ買い（中分類）
│   ├── Branded
│   ├── Generic
│   └── Competitor
└── ギフト・セット（中分類）
    ├── Branded
    └── Generic

商品ライン B・新規／リピート（大分類）
├── 新規（中分類）
└── リピート（中分類）

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

商品ライン別の ACoS・売上を一覧で比較できる
中分類に「新規 / リピート」を置くと新規獲得コストとリピート維持コストを分けて管理でき、LTV 視点の判断ができる
最下層に Branded / Generic / Competitor を置くことで「商品ライン A × Generic の ACoS はいくつか」という粒度まで掘り下げられる

このカテゴリで使う場面

数千〜万単位のキーワードを主力 / 利益エンジン / 防衛 / 探索 / 切り出し対象の 5 つの広告役割で自動分類したい
検索語句に紛れ込んでいる競合 ASIN を価格帯・レビュー・カテゴリーで自動分類したい
ラベル分類体系で一度設計したルールを、既存の検索語句に一括適用したい
キャンペーンの命名規則を統一し、レポートでの集計を安定させたい
ラベル別に ACoS・ROAS・予算配分の目標を別々に管理したい

プロンプト早見表

やりたいこと	プロンプト
競合 ASIN を 4 軸（価格 / 評価 / カテゴリー / 商品名）で自動ラベリング	プロンプト 1
ラベル分類体系で検索語句に一括ラベル付け	プロンプト 2
検索語句 / ASIN にラベル ID を手動で直指定	プロンプト 3
SP キャンペーン / DSP / 商品にラベル割り当て	プロンプト 4
ラベル分類体系の管理	プロンプト 5
キャンペーン命名規則の登録 / 推論	プロンプト 6
広告役割（主力 / 利益エンジン / 防衛 / 探索 / 切り出し対象）でラベル分類体系を設計	プロンプト 7

詳細仕様は安全装置 / 自動化フェーズ / 困ったときを参照。

プロンプト 1: 競合 ASIN を 4 軸で自動ラベリング

検索語句に含まれる ASIN（B0XXXXXXXX 形式）を抽出し、価格帯・レビュー評価・カテゴリー関連性・商品名の 4 軸で自動的にラベルを生成・割り当てます。

検索語句から B0XXXXXXXX 形式の ASIN を抽出して、
4 軸（価格 / レビュー / カテゴリー / 商品名）で競合 ASIN ラベルを自動生成して。

skip_labeled={{ラベル済みを除外（例: true）}}（既存ラベルは除外）、
limit={{処理上限件数（例: 50）}}（外部 API のコスト制御のため必須）。

dry_run=true で実行プランを先に確認 →
問題なければ dry_run=false で本実行。

プレースホルダー: ラベル済みを除外 (例: true、既定 true)、処理上限件数 (例: 50、必須・外部 API コスト制御)。 返ってくるもの: ASIN × 推奨ラベル × 価格 × レビュー数 × カテゴリーの表。承認するまでラベルは書き込まれません。

プロンプト 2: 検索語句にラベル分類体系で一括ラベル付け

ラベル分類体系に登録済みのラベルパターンを使い、Picaro に取り込まれた検索語句へ一括でラベルを付与します。

Picaro に登録済みの全検索語句に対して、
ラベル分類体系のルールで一括ラベル付けして。

skip_labeled={{ラベル済みを除外（例: true）}}（既存ラベルは除外）、
dry_run=true で実行プランを確認 →
問題なければ dry_run=false で本実行。

プレースホルダー: ラベル済みを除外 (例: true、既定 true)。 返ってくるもの: 検索語句 × 適用予定ラベル × マッチパターンの表。パターン無マッチの語句はラベル未割り当てのまま残ります。

プロンプト 3: 検索語句に手動でラベル付け

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

label_id {{ラベルID（例: lbl_XXXXXX）}} に対して、
以下の検索語句 / ASIN を直接割り当てて:
{{対象リスト（例: ["term1", "B0XXXXXXXX"]）}}

dry_run=true で検証 →
問題なければ dry_run=false で本実行。

プレースホルダー: ラベルID (例: lbl_XXXXXX、プロンプト 5 の show で取得可)、対象リスト (例: ["term1", "term2", "B0XXXXXXXX"])。 返ってくるもの: 対象 × 種別（検索語句 / ASIN）× 既存ラベル × 割り当て後ラベルの表。既存ラベルがある対象は上書きフラグ付きで明示されます。

プロンプト 4: キャンペーン / DSP / 商品にラベルを割り当てる

ラベルを SP キャンペーン、DSP ラインアイテム、商品 ASIN に割り当てて、ダッシュボードや N-gram での切り口として使えるようにします。

label_id {{ラベルID（例: lbl_XXXXXX）}} に、以下を割り当てて:
- SP キャンペーン: campaign_ids = {{キャンペーンID（複数可）}}
- DSP ラインアイテム: line_item_ids = {{ラインアイテムID（複数可）}}
- 商品 ASIN: product_ids = {{商品ID（複数可）}}

dry_run=true で検証 →
問題なければ dry_run=false で本実行。

プレースホルダー: ラベルID、キャンペーンID（複数可） / ラインアイテムID（複数可） / 商品ID（複数可）（不要なら省略可）。 返ってくるもの: 対象 ID × 種別 × 既存ラベル状況 × 割り当て後ラベルの表。商品 ASIN は衝突検出 API がないため上書きリスクが「要注意」フラグで明示されます。

プロンプト 5: ラベル分類体系の管理

ラベル分類体系（カテゴリー階層 → ラベル）の現状確認・追加・更新・海外販路設定・初期化を 1 つのプロンプトで一元管理します。

ラベル分類体系の操作: {{操作（例: show）}}

- show: 現状表示
- clone_default: デモ値からコピー
- upsert_category: カテゴリー階層を追加・更新
- upsert_label: ラベルを追加・更新
    （マッチパターン、ルール種別、Picaro 側ラベル ID を含む）
- update_asin_enrichment: 海外販路設定
    （amazon_domain / currency / language）
- create_picaro_label: Picaro 側にラベルを新規作成
- reset: 全削除（破壊的、要確認）

プレースホルダー: 操作 (show / clone_default / upsert_category / upsert_label / update_asin_enrichment / create_picaro_label / reset のいずれか)。 返ってくるもの: 操作別の結果（一覧表示、追加・更新確認、初期化完了など）。reset は破壊的のため明示確認後のみ実行されます。マッチパターン変更後の再ラベリングはプロンプト 2 を別途実行。

プロンプト 6: キャンペーン命名規則の登録 / 推論

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

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

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

プレースホルダー: サンプル数 (例: 50、既定)、命名テンプレート (例: {広告タイプ}_{ブランド}_{商品ライン}_{マッチタイプ})。 返ってくるもの: 推論された命名パターン × 一致率 × 例の表。登録した命名規則はキャンペーンを作るで新規作成時に自動適用されます。

プロンプト 7: 広告役割でラベルを設計・分類する

既存の検索語句データから広告貢献度を分析し、主力 / 利益エンジン / 防衛 / 探索 / 切り出し対象 の 5 つの広告役割で 3 層のラベル分類体系案を設計します。

検索語句を広告役割の 5 種類（主力 / 利益エンジン / 防衛 / 探索 / 切り出し対象）で分類する
ラベル分類体系の設計を提案して:

1. 直近 {{対象期間（例: 過去30日）}} の検索語句データから各役割の代表例を 10 件ずつ抽出して
   分類根拠（ROAS / ボリューム / 戦略的位置づけ）を示す
2. 大分類（広告役割）/ 中分類（商品ライン or トピック）/ 小分類（マッチタイプ or KW）の
   3 層ラベル分類体系案を設計
3. 各役割の判定基準（ROAS / クリック数 / 注文数の閾値）を併記

確認後、ラベル分類体系に登録する場合は「登録して」と返信。

プレースホルダー: 対象期間 (例: 過去 30 日、既定 30 日)。 返ってくるもの: 大分類（役割）× 中分類 × 小分類 × 代表語句例 × 判定基準の 3 層ラベル分類体系案。登録は明示的な「登録して」確認後のみ実行されます。各 KW がどの役割に該当するかは ROAS・ボリューム・既存ラベルから自動判定され、人が後から個別補正できます。