りょうのAI Hack Lab

広告レポートの集計や残予算の計算を、毎朝手作業でこなしていないだろうか。Google広告やMeta広告のAPIをClaude Codeから直接叩ければ、この定型作業は数十秒で終わる。鍵になるのがMCP（Model Context Protocol・AIツールと外部APIをつなぐ共通規格）だ。この記事では、PythonでMCPサーバーを自作し、Claude Codeに広告APIをつなぐまでの手順を、実際に詰まった点つきでまとめる。読み終えれば、今日から自分の運用環境に組み込める。 なぜ広告運用にMCPが必要なのか MCPはAnthropicが2024年末に公開した開かれた規格だ。AIツールが外部APIを使うための共通の口を定める。これまではツールごとに個別の連携を作る必要があった。MCPなら一度サーバーを用意すれば、Claude CodeでもChatGPTでも同じデータに届く。2026年時点で公式レジストリには8,000を超えるMCPサーバーが登録済みだ。広告分野はまだ法人メディアの実装記事が薄く、先行者の窓が開いている。 広告運用と相性が良い理由は3つある。1つ目は、GAQLやInsightsの複雑なクエリをAIに任せられる点。2つ目は、残予算や消化ペースの計算を自然言語で頼める点。3つ目は、複数媒体の数字を1つの窓口で横断できる点だ。手元のGoogle広告APIの叩き方は Google広告APIをPythonで動かす手順 にまとめている。MCP化の前にAPI単体で動かしておくと理解が早い。 Pythonで最小構成のMCPサーバーを作る 実装は驚くほど短い。Python公式のMCP SDKを使えば、3ステップで動く。まず環境を用意し、次にツールを1つ定義し、最後にClaude Codeへ登録するだけだ。以下の手順はブックマークして、自分のAPIキーとエンドポイントに書き換えて使ってほしい。詳しい仕様はMCP公式サイト（https://modelcontextprotocol.io）で確認できる。 （1）SDKを入れる: pip install "mcp[cli]" を実行する。（2）サーバー本体を書く: FastMCPを読み込み、関数の上に @mcp.tool() デコレータを付けるだけで、その関数がAIから呼べるツールになる。残予算を返す関...

広告運用で最も避けたいのは、月の半ばで日予算の消化ペースが崩れる事態だ。気づいた時には月予算を大きく超えている、という失敗はよくある。とはいえ毎朝すべてのキャンペーンの残予算を手で見るのは続かない。Google広告スクリプトを使えば、消化異常を検知して自動でメール通知できる。しかも管理画面の中だけで完結し、開発者トークンもサーバーもいらない。この記事では、コピペで動く監視の骨格と、実運用でつまずいた罠までまとめる。 なぜAPIでなくGoogle広告スクリプトなのか Google広告の自動化には二つの道がある。一つはGoogle広告APIをPythonなどの外部プログラムから叩く方法だ。もう一つが、管理画面の中でJavaScriptを動かすGoogle広告スクリプトである。前者は開発者トークンの申請やOAuth認証が要る。後者は申請なしで、アカウントにログインできれば今日から書ける。 監視や通知のような軽い自動化なら、後者の手軽さが効く。逆に、3媒体の横断集計や重い処理はAPI側が向く。用途で使い分けるのが正解だ。より本格的にPythonから制御したい場合は Google広告APIをPythonで動かす手順 を参照してほしい。日予算そのものの計算ロジックは 日予算を自動計算するPython実装 で扱った。 予算超過が起きる仕組みと監視の軸 Google広告の日予算は、1日の消化が設定額の最大2倍まで振れることがある。これは公式仕様で、月間ではならされる。だが月途中の日予算変更や急な配信増があると、体感としての超過は普通に起きる。だから「月予算に対して今どのくらいのペースか」を日次で見る必要がある。 監視の軸はシンプルだ。残予算を残日数で割った理想ペースと、実際の消化を比べる。実消化はGAQLという問い合わせ言語でcost_microsという項目を取る。この値は円ではなくマイクロ単位なので、100万で割って円に直す。例えばcost_microsが96810000なら、実消化は96.81ドル相当になる。桁を意識するだけで、通知の精度は大きく変わる。この監視の考え方の完全版はnoteの実践ガイドにまとめている。 コピペで使える監視スクリプトの骨格 ブックマークして、自分のアカウントに合わせて閾値やメールアドレスを書き換えて使ってほしい。全体は次の4ステップで組む。 （1）当...

Meta広告のクリエイティブは、配信して数日で効果が落ちる。同じ人に何度も表示されると飽きられ、CTRが静かに下がっていく。これがクリエイティブ疲労だ。運用者の悩みは「気づくのが遅れること」にある。管理画面を毎日見ても、数字のブレか本物の疲労かは判断しづらい。そこで有効なのが、フリークエンシー・CTR・CPMの3指標をPythonで毎日自動チェックし、閾値を割った瞬間にSlackへ飛ばす仕組みだ。この記事では、Meta Marketing APIから指標を取り、疲労を定量判定するまでの実装を手順で示す。 クリエイティブ疲労はなぜ検知が遅れるのか 疲労の主犯はフリークエンシーだ。同じユーザーへの表示回数が増えるほど、反応は鈍る。目安として、フリークエンシーが3〜4を超えると疲弊の予兆とされる。ただし単独では判断できない。数字は日々ブレるからだ。 現場で使える基準は「CTR低下」と「CPM上昇」の同時発生だ。この2つが揃ったとき、疲弊がオークションの非効率にまで波及したサインになる。逆に言えば、フリークエンシーだけを見て差し替えると、まだ効くクリエイティブを早期に捨ててしまう。判定ロジックの設計は 現場の指標解説 とも整合する。 人の目で毎日これを追うのは非効率だ。3指標の複合条件は、コードに落とすほうが速く正確になる。 疲労を定義する3つの指標と閾値 検知ロジックは、次の3条件をANDで結ぶ。1つでも欠けたら「疲労ではない」と判定する。過検知を防ぐための設計だ。 フリークエンシー ：直近7日で3.0を超えている CTR減衰 ：直近7日のCTRが、過去ピークから25%以上低下 CPM上昇 ：直近7日のCPMが、基準期間から10%以上上昇 閾値は媒体や商材で動く。BtoBの狭い配信面ならフリークエンシーは早く上がるため、3.0でなく2.5を採る場合もある。まず上の初期値で回し、誤検知の頻度を見て自分の口座に合わせて調整するのが実務的だ。この閾値表はブックマークして、自分の環境に合わせて書き換えて使ってほしい。 重要なのは「ピークからの相対低下」で見る点だ。CTRの絶対値は業種で桁が違う。だが「自分の過去最高から何%落ちたか」なら、どの口座でも同じ物差しになる。 Meta APIから指標を取るPython実装 データ取得はMeta Marketing APIのinsight...

広告の管理画面では今日のCVが12件。だがGA4を開くと8件しかない。この食いちがいに手を止めた運用者は多いはずだ。数字が合わないまま予算判断を続けると、良い広告を止め、悪い広告に足す事故が起きる。原因はバグとは限らない。GA4と広告プラットフォームは、そもそも別の物差しでCVを数えている。ここでは、ズレが生まれる4つの理由を整理し、GA4 Data APIと広告APIをPythonで毎日つき合わせ、乖離が閾値を超えたら気づける監視の作り方までを示す。手作業の突合をやめ、判断できる数字を自動でそろえるのが狙いだ。 なぜGA4と広告のCVはズレるのか まず前提として、両者の数字は一致しない方が普通だ。ズレの正体は、大きく4つに分けられる。 アトリビューションの物差しが違う ：広告側は自媒体のなかの接点だけを成果とみなす。GA4は自然検索や他媒体も横断し、最後の流入元へ貢献を割りふる。同じCVでも帰属先が変わる。 Cookie規制とITP ：SafariのITPでCookieの寿命が短くなった。クリックからCVまで日数が空くと、GA4は広告流入と結びつけられなくなる。 タグの二重計測・未発火 ：イベント名の重複やトリガーの誤設定で、1件のCVが2件にふくらむ。逆に未発火で減ることもある。 クロスドメインの断絶 ：外部カートや決済へ移る瞬間に参照元が切れ、流入経路が失われる。 実運用での体感では、GA4のCVが広告管理画面より2〜3割ほど少なく出るのは珍しくない。媒体側の乖離要因は https://squadbeyond.com/blog/ga4_suuchikairi/ や https://markecats.co.jp/column/discrepancy-reasons/ が詳しい。大事なのは、この差をゼロにしようとしないことだ。閾値を決めて「いつもの差か、事故か」を見分ける発想に切りかえる。 手作業の突合が破綻する理由 毎朝、広告管理画面とGA4を並べて数える運用は長くは続かない。媒体が3つ、口座が10あれば、確認だけで30分が飛ぶ。人が見るかぎり、見落としと転記ミスが必ず混ざる。しかもズレは、数字が動いた瞬間に気づきたい。翌週に気づいても、その間の予算配分はもう狂っている。だから突合はコードに任せ、人は「閾値を超えた時だけ」見ればよい。異常を検知して通知に流す発...

ブラウザ計測だけに頼るMeta広告は、iOSの制限や広告ブロックでCVを取りこぼす。取りこぼしはそのまま学習の材料不足になり、CPA悪化につながる。対策がサーバーからCVを直接送るコンバージョンAPI（CAPI）だ。だが解説記事の多くは「とは」「メリット」で止まり、実際に動くコードまで書いたものは少ない。ここではPythonで最小構成を組み、検証で実際に詰まった3点まで先回りで潰す。読み終えれば今日から送信テストに入れる。 なぜサーバー側の計測が要るのか 従来のMetaピクセルはブラウザ上のJavaScriptでCVを送る。この方式はSafariのトラッキング制限や広告ブロックの影響を受け、購入やリード送信の一部がMetaに届かない。届かないCVは、自動入札の学習に使われない。つまり計測ロスは数字が減るだけでなく、配信の質そのものを下げる。 CAPIは自社サーバーからMetaのサーバーへ直接イベントを送る。ブラウザを経由しないため、規制やブロックの影響を受けにくい。結果として計測できるCVが増え、学習の元データが厚くなる。自動入札の挙動が計測に依存する点は、 tCPA学習リセットの条件 を整理した記事とあわせて読むと理解が早い。 Pythonで送る最小コードの骨格 用意するのは2つだけだ。Meta イベントマネージャで発行するアクセストークンと、ピクセルID（データセットID）。この2つがあればPythonのrequestsで送れる。 送信先はGraph APIのイベントエンドポイントで、形は https://graph.facebook.com/vXX.X/<ピクセルID>/events になる。vXX.X はGraph APIの最新版に合わせる。バージョンは公式ドキュメント（developers.facebook.com/docs/marketing-api/conversions-api）で確認する。 手順は次の流れになる。（1）url にエンドポイントを組み立てる。（2）1件のイベントを辞書で作る。必須は event_name（例: Purchase）、event_time（UNIX秒）、action_source（website）、user_data（後述のハッシュ済み値）。（3）payload を {"data": [ev...

広告費の消化は、放置すると1日で数万円ぶれる。管理画面を朝と夕に開いて目視する運用は、担当アカウントが増えるほど続かない。この記事では、Google広告やMeta広告の消化異常「だけ」をSlackに自動通知するPython監視の作り方を、実際に組んだ構成・閾値の決め方・つまずいた点までまとめる。コピペで使える通知関数も置いた。読み終えたら、朝いちの管理画面めぐりをやめられる。 なぜ目視チェックは破綻するのか 担当アカウントが3つを超えたあたりから、目視の巡回はほぼ機能しなくなる。理由は3つある。 監視対象が「アカウント数×媒体数」で増える 消化の暴走は日中の急加速で起きる。朝夕のチェックでは半日出遅れる 人は毎日はやらない。異常がない日が続くほどチェックをサボる だから監視は「正常なら黙り、異常のときだけ鳴る」形にするのが正しい。人が毎回見に行くのではなく、機械が異常だけを拾って人を呼ぶ。この発想の転換が起点になる。 何を「異常」と判定するか 通知の質は、閾値の設計でほぼ決まる。監視する軸は3つに絞ると運用しやすい。 ペース異常 ：その時刻までの想定消化に対し、実消化が130%を超えたら警告 消化ゼロ ：稼働時間帯なのに消化が0円。配信停止や支払いエラーのサイン CPA異常 ：目標CPAの1.5倍を超えたら警告。学習リセットや競合入札の兆候 閾値は最初から厳密に詰めなくてよい。ゆるめに始めて、数日ログを見ながら締めるほうが早い。以下は監視設計のチェックリストだ。ブックマークして、自分のアカウント事情に合わせて数値を書き換えて使ってほしい。 （1）想定日消化＝日予算 ÷ 稼働時間 × 経過時間、で当該時刻の基準を出す （2）超過率の警告ラインを決める（例：130%で警告、180%で緊急） （3）消化ゼロ判定に「稼働時間帯か」の条件を必ず添える（深夜の0円は正常） （4）CPAは母数が小さい日は判定から外す（CV数の下限を置く） （5）通知に必ず「次アクション」を1行つける この判定ロジックは、消化の絶対額ではなく想定ペースとの比率で見るのが肝だ。日予算そのものの自動計算は別記事にまとめている。 広告の日予算を自動計算するPython実装 と組み合わせると、基準値の算出まで自動化できる。 Slack WebhookとPythonで通知する最小実装 通知の送信部分は驚くほ...

広告運用で最も静かに予算を溶かすのが、検索語句レポートに埋もれた無関係なクエリだ。完全一致でも部分一致の派生でクリックは入り込む。手作業の棚卸しは週次でも追いつかない。この記事では、Google広告APIの search_term_view から除外キーワード候補をPythonで自動抽出する手順を、実運用で使っている判定ルールごと公開する。コードを自分の環境に貼り替えれば、無駄クリックの検出を今日から自動化できる。 手作業の除外キーワード運用が破綻する理由 検索語句レポートは1アカウントで数百から数千行に膨らむ。目視で「これは関係ない」を拾う作業は集中力を消耗し、見落としも増える。とくに複数アカウントを掛け持ちする運用者ほど、週次の棚卸しが後回しになりやすい。 実際の現場では、週2時間ほどかけていた検索語句の目視チェックを自動抽出に置き換えたところ、確認作業は数分で済むようになった。人間は「候補リストを承認するか」だけを判断すればよい。抽出は機械、判断は人間、という分業が最も破綻しにくい。 Googleの 検索語句レポート は関連性の低いクエリの発見に使えるが、UIでの絞り込みには限界がある。閾値ロジックを自分で書けるAPI取得のほうが精度が高い。 search_term_viewからクエリを取得するGAQL Google広告APIでは、検索語句のパフォーマンスはsearch_term_viewリソースに格納される。取得はGAQL（Google Ads Query Language）というSQLに似た構文で書く。ブックマークして、日付範囲と指標を自分の運用に合わせて書き換えて使ってほしい。 基本クエリはこの1行で足りる： SELECT search_term_view.search_term, metrics.clicks, metrics.cost_micros, metrics.conversions FROM search_term_view WHERE segments.date DURING LAST_30_DAYS 実装の流れは（1）GoogleAdsClientを認証情報から初期化する（2）GoogleAdsServiceを取得する（3）上記GAQLでsearch_streamを実行する（4）返ってきたストリームを1行ずつ回してsearch_termと...

Meta・Google・Yahooを回している運用者なら、3媒体の数字を1枚に並べる作業に毎朝時間を溶かしているはずだ。媒体ごとに管理画面を開き、CSVを落とし、列名を手で揃える。この手集計はミスの温床であり、月次のたびに憂うつになる。結論から言うと、統合でつまずく原因のほぼ全ては「コスト単位と列名のバラつき」に集約される。ここさえ設計すれば、3媒体の横断CPA比較はPythonで5分に落ちる。実際に運用中のスクリプトをもとに、設計から実装、ハマった点までを順に示す。 なぜ3媒体を1つにするだけで数字がズレるのか 統合が難しいのはAPI連携そのものではない。各媒体が「同じ指標」を別の名前・別の単位で返すからだ。特にコストの表現がバラバラで、ここを見落とすと合計金額が桁単位で狂う。 Google広告API: コストは マイクロ単位 で返る。cost_microsを1,000,000で割って初めて円になる Meta広告API: コストは spend という名前で、しかも数値でなく文字列で返る。floatへの変換が要る Yahoo広告API: コストはcostだが、レポート項目の指定を誤ると税抜・税込がズレる クリック・表示回数・CVも同様で、Metaはimpressions、Googleはimpressions、Yahooはimpsのように微妙に違う。つまり統合の本質は「API取得」ではなく「取得後の正規化」だ。列名と単位を共通スキーマに寄せる工程を設計に入れないと、後から必ず破綻する。Google広告APIの単位仕様は公式リファレンス（developers.google.com/google-ads/api）に明記されている。個別のMeta取得の基礎は Meta広告レポートをPythonで自動化する実装手順 にまとめた。 設計図: 共通スキーマを最初に固定する 実装より先にやるべきは、3媒体を流し込む「共通の器」を決めることだ。器が決まれば、各媒体の処理は器に合わせる変換関数を書くだけになる。横断分析できない案件のほぼ全ては、この器を決めずにコードから書き始めている（Qiitaの横断分析の解説でも同じ指摘がある）。ブックマークして、自分の担当媒体に合わせて列を足し引きして使ってほしい。以下が実運用で落ち着いた8列の共通スキーマだ。 （1）date（日付・YYYY-MM...

Google広告の自動入札を回したら、突然CPAが跳ね上がって元に戻らない。原因の多くは設定の触りすぎによる「学習リセット」だ。tCPAは変更のたびに学習をやり直す。ここを知らずに数値を触ると、せっかく安定した配信が振り出しに戻る。この記事では、tCPA学習がリセットされる条件と、月数千万円規模の運用で使っている「触ってよい範囲」の運用ルールを、公式仕様と実運用の両面からまとめる。 tCPA学習リセットが運用の命取りになる理由 スマート自動入札は、過去のコンバージョンデータをもとに入札単価を1オークションごとに調整する。ここで重要なのは、学習が「やり直し」になると、その間の配信品質が一時的に落ちる点だ。Googleの入札アルゴリズムの学習の仕組み（support.google.com/google-ads/answer/10970825）でも、システムが安定するまで7〜14日かかると明記されている。 実運用でありがちな失敗が、CPAが目標を1割超えた程度で焦って目標CPAを一気に3割下げるケースだ。すると学習が振り出しに戻り、配信量が絞られ、2週間ほどCPAがむしろ悪化する。触らなければ数日で収束したものを、触ったせいで悪化させる。これが最も多い自滅パターンだ。日予算の変更でも同じことが起きる。 広告の日予算を自動計算するPython実装 で自動化する場合も、変更幅の上限を必ずロジックに組み込む必要がある。 tCPA学習がリセットされる主な条件 何をすると学習がやり直しになるのか。スマート自動入札について（support.google.com/google-ads/answer/7065882）の記載を実運用の粒度でまとめると、リセットの引き金は主に次の3つだ。 入札戦略の変更 : 個別単価↔tCPA↔tROASの切り替えは即リセット。戦略の種類を変える操作が最も影響が大きい。 目標値の大幅変更 : 目標CPA・目標ROASを大きく動かすと再学習に入る。小幅なら影響は限定的だが、幅が大きいほどリセット寄りになる。 コンバージョン設定の変更 : 計測対象のCVアクションや値、アトリビューションを変えると、学習の前提が変わるためやり直しになる。 加えて、日予算の急な増減、キャンペーン構成の大改編（広告グループ大量追加・統合）も実質的な再学習を招...

Meta広告のレポート自動化に続いて、Google広告もPythonでデータを引きたい運用者は多い。だが公式ドキュメントどおりにコードを書いても、最初のAPIコールでほぼ全員が同じ場所でつまずく。原因は認証コードでも書き方でもなく、発行されたばかりの開発者トークンの「アクセスレベル」にある。この記事では、Google広告APIをPythonで動かすまでの実装手順と、初回に必ず当たる壁の回避法を、そのまま試せる形でまとめる。 初回の壁はアクセスレベルにある Google広告APIの利用登録を済ませると、開発者トークン（developer token）が発行される。これは22文字の英数字で、アプリをAPIサーバーに識別させる鍵だ。ここで見落としやすいのが、発行直後のトークンは「テストアカウントアクセス」という最も制限された段階から始まる点である。 この段階のトークンで本番の広告アカウントにクエリを投げると、認証は通るのにデータが返らず、次のエラーが出る。「The developer token is only approved for use with test accounts. To access non-test accounts, apply for Basic or Standard access.」つまり本番アカウントを触るには、API Centerから「Basicアクセス」を申請して承認を得る必要がある。Basicは本番・テスト両方に使え、1日15,000オペレーションまで実行できる。アクセスレベルの区分は 公式のAccess Levels に明記されている。 実運用で詰まったのはまさにここだった。ローカルで認証まで成功し、コードは正しいのにデータがゼロで返る。半日ほど認証周りを疑った末、原因がトークンのアクセスレベルだと判明した。申請フォームには利用目的の記述が必要で、承認までは数営業日かかる。先に申請を出しておくのが最短ルートだ。 認証に必要な4つの情報 Pythonクライアントライブラリは 公式ページ とPyPIで配布され、Python 3.8以上で動く。認証には、次の4つの情報を1つの設定ファイルにまとめる。 developer_token（22文字。ads.google.com/aw/apicenterで確認） client_id と clien...

広告運用者にとって、毎朝のレポート更新は避けて通れない。Meta広告マネージャを開き、数字をコピーし、スプレッドシートに貼る。この作業を複数アカウントで回すと、それだけで1時間が消える。だが Meta の Marketing API と Python を組み合わせれば、この定型作業は数分に縮む。実際に3アカウントの日次レポートを自動化したところ、毎朝の手作業がほぼゼロになった。ここでは、アクセストークンの取得から Insights API の呼び出し、現場でハマった罠までを、そのまま動くコードとあわせて解説する。 なぜMeta広告レポートはPython自動化に向くのか GAS やスプレッドシートのアドオンでも自動化はできる。ただ、複数媒体を横断し、独自の集計軸で並べたい運用者には Python が向く。理由は3つある。第一に、pandas で自由に集計・結合できる。第二に、Meta・Google・Yahoo の各 API を同じ言語でまとめられる。第三に、cron や launchd で完全に無人化できる。実測では、3アカウントの日次集計を手作業で回すと毎朝およそ50分かかっていた。Python 化した後は、朝には集計済みの CSV が出来上がっている。この差は月20営業日でおよそ16時間になる。この集計ロジックの完全版は note の実践ガイドにまとめている。 事前準備 アクセストークンとアカウントIDを用意する Insights API を叩くには、事前に2つの値がいる。アクセストークンと広告アカウントIDだ。手順はこうなる。（1）Meta for Developers でアプリを作り、ads_read の権限を付ける。（2）短期トークンは数時間で失効するため、ビジネス設定からシステムユーザーの長期トークンを発行する。（3）広告アカウントIDはビジネスマネージャで確認し、必ず先頭に act_ を付けた形（例 act_1234567890）で使う。ここを普通の数字だけで渡すと、API はエラーを返す。最初の詰まりどころなので、まず1件だけ手元で叩いて疎通を確かめるとよい。 PythonでInsights APIから広告データを取得する 取得のエンドポイントは GET /v21.0/{act_アカウントID}/insights になる。主要なパラメータは field...

広告の月予算を月末に余らせたり、逆に月中で使い切って配信が止まったりする。運用者なら誰もが踏む失敗だ。原因の多くは「日予算を月初に決めて放置する」ことにある。解決策はシンプルで、毎日「残予算÷残日数」で日予算を引き直せばよい。この計算をPythonで自動化すれば、手作業のスプレッドシート更新から解放される。この記事では、3媒体の運用で実際に固めた計算ルールと、そのまま使えるPython実装をまとめる。 なぜ日予算は「残予算÷残日数」で毎日引き直すのか Google広告の日予算は固定値ではない。公式ドキュメントによれば、1日の消化は日予算の最大2倍まで振れ、月間では日予算のおよそ30.4倍まで使われる。つまり日予算¥3,000でも、ある日は¥6,000消化することがある。詳細はGoogleの予算オーバービュー(developers.google.com/google-ads/api/docs/campaigns/budgets/overview)に書かれている。 この振れ幅がある以上、月初に決めた日予算のまま放置すると、月末には数千円〜数万円のズレになる。だから毎日、その日時点の「残り予算」を「残り日数」で割り直す。こうすれば日々の消化ブレを翌日以降で吸収でき、月末の着地が月予算にほぼ一致する。 さらにGoogleは2026年8月17日から、予算制限キャンペーンのペーシングをより安定させる変更を告知している。挙動が変わる時期こそ、手計算ではなく自動計算でズレを毎日リセットする価値が上がる。同じくPython×広告APIの実装は Yahoo広告APIをPythonで自動化して詰まった罠の記事 もあわせて読むと、認証まわりの落とし穴を先回りできる。 実運用で固めた日予算の計算ルール4つ 「残予算÷残日数」は骨格にすぎない。3媒体を横断で回すうちに、そのままでは事故る点が見えてきた。ブックマークして、自分の環境に合わせて書き換えて使ってほしい。運用で確定させたルールは次の4つだ。 ¥100単位で切り捨てる : ¥3,472のような端数はUIでも扱いにくい。int計算で¥100の位まで落とす。切り上げにしないのは超過側に倒さないため。 月予算の100%を超える増額はしない : 残日数が少ない月末は「残予算÷残日数」が跳ね上がる。当月の想定消化が月予算を超える...

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回...