Google広告で実は止まっているKWを見抜く4手順

キーワードの停止や除外を提案したあとで「それ、とっくに止まっています」と返された経験はないだろうか。広告運用の自動化を進めるほど、この誤判定は増える。原因ははっきりしている。Google広告APIでstatus を1階層しか見ていないからだ。キャンペーンが有効でも、広告グループが停止していれば配信はゼロ。ここでは実運用で3度同じミスを踏んだうえで固めた、実効的な配信状態を4階層で判定する手順を示す。GAQLのクエリと、そのままコピペできるチェックリストまで持ち帰れる構成にした。

1階層のstatusだけ見ると「止まっているKW」を提案してしまう

Google広告の管理画面は、親が止まっていても子の行を「有効」と表示する。APIも同じだ。ad_group_criterion.status が ENABLED でも、それはそのキーワード自身の設定値にすぎない。上位のキャンペーンや広告グループが PAUSED なら、実際のインプレッションは発生しない。

実際に踏んだ失敗はこうだ。90日間の消化額が大きいキーワードを抽出し、無駄打ちとして停止提案を出した。だがそのキーワードは、提案の3週間前にすでに停止されていた。90日という窓が、停止前の消化を丸ごと含んでいたわけだ。指摘を受けるまで、レポート上は完全に正しく見えていた。同じ種類のミスを3度繰り返して、ようやく判定ロジックそのものが誤っていると認めた。

誤判定の怖さは、間違った数字が出ることではない。「もう対処済みの問題」を提案として出し続けることで、自動化の出力そのものが信用されなくなる点にある。

実効配信の判定は「4階層すべてENABLED」＋「有効な広告が1本以上」

判定条件を言葉にすると単純だ。次の5つを同時に満たしたときだけ、そのキーワードは配信されている。

  • campaign.status が ENABLED
  • ad_group.status が ENABLED
  • ad_group_criterion.status が ENABLED
  • キャンペーンの期間・予算が有効（campaign.primary_status で確認）
  • その広告グループに有効な広告が1本以上ある

最後の条件が抜けやすい。キーワードが有効でも、広告グループ内の広告が全て停止・不承認なら配信は起きない。広告本数は ad_group_ad リソースを別クエリで引き、広告グループIDごとに件数を数えて突き合わせる。

キーワード側のGAQLはこう書ける。ブックマークして、自分のアカウント構成に合わせて書き換えて使ってほしい。

SELECT campaign.id, campaign.status, campaign.primary_status, ad_group.id, ad_group.status, ad_group_criterion.criterion_id, ad_group_criterion.keyword.text, ad_group_criterion.keyword.match_type, ad_group_criterion.status FROM ad_group_criterion WHERE ad_group_criterion.type = 'KEYWORD' AND ad_group_criterion.negative = false

ここで WHERE 句に status の条件を書かないのが要点だ。ENABLED だけ取得すると、「なぜ止まっているか」を後から説明できなくなる。全件取得してPython側で判定し、除外理由をログに残す設計にしておくと、提案を出さなかった根拠も追える。

campaign.primary_status は ELIGIBLE / PAUSED / LIMITED / MISCONFIGURED / NOT_ELIGIBLE などの値を返し、配信できていない理由の手がかりになる（Google Ads Query Language 公式ドキュメント）。予算上限による LIMITED は「配信はしているが抑制されている」状態であり、停止とは区別して扱う。

APIの初期設定でつまずいている段階なら、先にGoogle広告APIをPythonで動かす手順と初回の壁を読んでおくと早い。クエリの書き方そのものはGAQLの書き方を実際に使ってわかった5つのコツにまとめてある。この判定ロジックを組み込んだ運用スクリプトの完全版はnoteの実践ガイドで公開している。

一致タイプを1語に丸めない：集計キーは(KW, match_type)

もう一つの落とし穴が一致タイプだ。実際にあったのは、同じキーワード文字列でフレーズ一致は停止、完全一致は稼働中という状態だった。キーワード文字列だけで集計すると、この2行が1行にまとまる。結果、稼働中の完全一致まで「停止済み」と判定されてしまう。

対策は単純で、集計キーを必ずタプル (keyword_text, match_type) にすることだ。文字列だけをキーにした辞書を作った時点で、この事故は避けられない。ad_group_criterion.keyword.match_type は EXACT / PHRASE / BROAD を返すので、正規化せずそのまま保持する。

さらに厳密にやるなら、広告グループIDまで含めた3つ組をキーにする。同じキーワードが複数の広告グループに存在するアカウントでは、広告グループ単位で状態が分かれるためだ。

長い集計窓の消化額を「今の無駄」と読み替えない

90日や180日の実績で無駄打ちを探すのは定石だが、その窓には停止前の消化が含まれる。「消化が大きい」ことと「いま無駄が出ている」ことは別の事実だ。

実装での解決は、長期窓の集計に必ず直近窓の数値を併記すること。具体的には、90日の消化額と並べて直近7日のインプレッションと消化額を出す。直近7日がゼロなら、それはすでに止まっている証拠であり、提案対象から外す。

この2列を並べるだけで、提案リストの精度は目に見えて変わった。導入前は「停止済みの項目が提案に混ざる」ことが常態だったが、導入後は判定段階で機械的に落ちるようになった。人が目視でダブルチェックする工程を丸ごと削れたのが実利だ。

コピペで使える停止提案チェックリスト

提案を出力する前に通す関門を、コードとは別に文章のチェックリストとして持っておくと再現しやすい。保存して、自分の運用ルールに合わせて書き換えて使ってほしい。

  • （1）campaign / ad_group / ad_group_criterion の3階層すべてが ENABLED か
  • （2）その広告グループに有効な広告が1本以上あるか
  • （3）campaign.primary_status が ELIGIBLE または LIMITED か
  • （4）集計キーに match_type を含めているか
  • （5）長期窓の消化額に直近7日の実績を併記しているか
  • （6）除外した候補について、除外理由をログに残しているか

この6項目を通過しなかった候補は、提案リストに載せない。判定を関数として切り出し、提案を生成するスクリプトは必ずその関数を経由させる。関数を通さずに出した提案は無効、というルールをコード側で強制するのが確実だ。

広告が配信されない原因は設定以外にも審査や支払いなどがある。原因の全体像はGoogle広告ヘルプの「広告が表示されない原因」が網羅している。

［PR］ 判定結果をクライアント共有用の資料に落とし込む工程まで含めて短縮したいなら、AIスライド作成ツール「イルシル」を試してみるのも手だ。

まとめ

停止提案の誤検知は、判定ロジックの精度ではなく見ている階層の数で決まる。4階層のstatusと広告本数、そして (キーワード, 一致タイプ) の集計キー。この3点を関数として固定してしまえば、同じミスは構造的に起きなくなる。まずは手元のアカウントで、上のGAQLを全件取得モードで一度回してみてほしい。「有効なのに配信されていないキーワード」が何件あるかを数えるだけで、自動化の前提が変わる。

実務でそのまま使いたい人へ

本記事の手法の完全版（実際のコード・テンプレート・つまずき対処つき）は、運営者のnote（note.com/ryo_ai_hack）で公開している。実データに基づく実践ガイドをまとめて読める。

DMM 生成AI CAMP

コメント

コメントを投稿

このブログの人気の投稿

Claude Skills販売で月5万稼ぐ3ステップ実践

イメージ
2026年、Anthropicが公開した「Claude Skills」が新たな副業の入口として注目を集めている。SKILL.mdというMarkdown形式の手順書を1枚書くだけで、誰でも自分の業務ノウハウをAIワークフローとして販売できる仕組みだ。海外では非エンジニアが50日で5,000ドルを売り上げた事例も登場し、日本でも参入の動きが加速している。今回は「Claude Skills 販売 副業」を軸に、月5万円を狙うための3ステップを具体的に解説する。コードは一切不要、初期費用もほぼゼロで始められる。 Claude Skillsとは何か:販売できる理由 Claude Skillsは、Claude Codeが特定タスクを実行する際に読み込む「再利用可能な指示書」である。実体はSKILL.mdというテキストファイル1枚で、業務手順を自然言語で記述するだけで動く。プログラミング言語は必要なく、日本語で「請求書を読み取り仕訳を生成する」「議事録から議題別サマリを作る」といった手順を構造化して書けば成立する。 販売できる理由は3つある。第一に、Anthropicの審査やマーケットプレイス登録が不要で、自分のサイトやGumroad経由で即販売できる。第二に、業務知識そのものが資産になるため、士業・人事・経理など専門職の暗黙知が高値で売れる。第三に、購入者はファイルをClaude Codeに置くだけで使えるため、サポート負荷が極めて低い。海外メディアagent37の報告では、税務処理を自動化するSkillが1本79ドルで継続的に売れている。 月5万円のリアルな単価設計 1本2,980円のSkillを月17本売れば達成できる。1本9,800円なら月5本で到達する。高単価帯は専門業務向け、低単価帯は汎用ツール系という棲み分けが定石となっている。 ステップ1:売れるSkillテーマを30分で決める 最初の関門はテーマ選定である。売れるSkillには共通点が3つある。「毎週繰り返す業務」「結果物がテキストかコード」「担当者の判断が定型化できる」の3点だ。この条件を満たす自分の業務を15個書き出し、上位3つに絞り込む作業を30分で行う。 具体例を挙げる。広告運用者なら「日次レポートのSlack要約Skill」、人事なら「面接フィードバック整形Skill」、ライターなら「SEO見出し構成生...
続きを読む

Claude CodeでExcel自動化副業を月5万にする手順

イメージ
Claude Codeを副業に使いたいが、何から手をつければ収入につながるのか見えにくい。本記事は、需要が安定しているExcel自動化案件に的を絞り、3週間で初案件を獲得し月5万円までスケールさせる具体的な手順をまとめる。コーディング未経験でも、手順どおりに進めれば動くものを納品できる構成にした。 なぜExcel自動化が初心者の最短ルートなのか クラウドソーシングで需要が枯れない領域がExcel関連だ。ランサーズやクラウドワークスでは「VBAでの集計自動化」「データ整形」「請求書生成」が常時数百件単位で募集されている。単価は1案件3,000〜30,000円で、納期も短い案件が多い。 従来は VBAの知識 が壁だった。だがClaude Codeは自然言語の指示からVBAコードを生成し、ターミナル上で実行・修正まで完結する。リベシティの解説によれば、Excel自動化はClaude Code副業16ジャンルの中で初心者が最も入りやすい分野とされている。 参考: リベシティのClaude Code活用例まとめ 準備するもの（初期費用は月3,000円のみ） Claude Pro契約: 月額20ドル（約3,000円） Node.js: 公式サイトから無料でインストール Microsoft Excel: すでに持っているはず クラウドソーシングのアカウント: ランサーズかクラウドワークス 初期投資はClaude Proの月3,000円のみ。1案件取れれば即回収できる水準だ。インストール手順は Uravationの2026年最新ガイド に図解で載っている。 3週間ロードマップ：初案件獲得まで 1週目：Claude Codeで動くものを3つ作る 最初の壁は「指示の出し方」だ。いきなり案件に応募せず、まず手元のExcelで3つの小さな自動化を作る。例として「フォルダ内のCSVを1つに統合」「請求書テンプレへの差し込み」「重複行の検出」が定番だ。各15〜30分で完成する。 この段階で重要なのは、生成されたVBAを 必ず自分で1行ずつ読む こと。読めなくても動作の意図は把握する。後工程のエラー対応で効いてくる。 2週目：ポートフォリオを2本作る 応募時に提示する成果物を準備する。「営業日報の月次集計を5秒で完了するマクロ」「100枚の請求書PDFを一括生成するツール」のように、効果を秒数や...
続きを読む

Yahoo広告APIをPythonで自動化して詰まった5つの罠

イメージ
Yahoo!広告のデータをPythonで自動取得しようとして、公式リファレンスの前で手が止まった経験はないだろうか。検索で出てくるのはPHPやGoogle Apps Scriptの記事ばかりで、Pythonの実装例は驚くほど少ない。実際に動かすと、Google広告APIとは作法がまるで違う。とくにレポート取得は「すぐ取れない」独特な仕様で、初見だと必ずつまずく。ここでは、月数千万円規模の運用でレポート自動化を組んだとき実際に踏み抜いた5つの罠と、その回避策を実装目線でまとめる。読み終えれば、非同期レポートの待ち受け処理まで自力で書けるようになる。 Yahoo広告APIをPythonで叩く全体像 まず処理の流れをつかむ。Yahoo!広告APIでレポートを取るまでは、大きく3ステップだ。1つ目がOAuth 2.0でのアクセストークン取得、2つ目がレポート定義の登録、3つ目が生成完了を待ってのダウンロードである。Google広告APIのように「クエリを投げたら即データが返る」設計ではない点が最大の違いだ。 通信はすべてHTTPSのPOSTで、リクエストもレスポンスもJSONで扱える。だからPythonなら requestsライブラリ1つ で完結する。公式SDKに頼る必要はない。認証まわりの仕様は LINEヤフー広告 API v19のリファレンス が一次情報になる。現行はv19で、URLのバージョン部分を間違えると404で弾かれる。 罠1・罠2：レポートは即取得できない「非同期ジョブ」 最初の関門がこれだ。Yahoo!広告は、事前に ReportDefinitionService へレポート定義を登録しないとデータが一切出力できない。アカウントID・レポート種別・期間・欲しいフィールドを指定して登録すると、レポートIDが返る。ここでCSVが返ると思い込むのが罠1である。 返ってくるのはIDだけで、サーバー側は裏でCSVを生成し始める。生成には数十秒から、行数が多いと数分かかる。登録直後にダウンロードを叩くと「生成中」ステータスが返り、空振りする。これが罠2だ。 対策はポーリングだ。 getReportJobで状態を数秒おきに確認 し、COMPLETEDになってから初めてダウンロードURLへアクセスする。Pythonなら「10秒sleep→状態確認→未完なら再試行、最大12回...
続きを読む