まずどのやり方を選ぶか 先に結論です。
レポートテンプレート×メール
難易度: ★☆☆（画面操作のみ） 出力先: メール添付 費用: 無料・申請不要 弱点: 加工・蓄積はできない Yahoo!広告スクリプト
難易度: ★★☆（JS少し） 出力先: スプレッドシート/Drive 費用: 無料・API申請不要 弱点: 管理画面内での実行が前提 ETLツール（TROCCO等）
難易度: ★★☆（SQLは必要） 出力先: BigQuery 費用: ツール月額数万円〜 弱点: ランニング費用がかかる LINEヤフー広告 API 直連携
難易度: ★★★（法人申請＋実装） 出力先: 自由（スプシ/DB/BI） 費用: API利用料の定めなし 弱点: 検索/ディスプレイでAPIが別 Yahoo!広告レポート自動化の4つのやり方。Looker Studioの公式コネクタが無いぶん、スクリプトとAPIの使い分けが軸になる 毎朝メールで数字が届けば十分ならやり方1（レポートテンプレート）、スプレッドシートに蓄積したいならやり方2（Yahoo!広告スクリプト）で足ります。ここから先、AI分析や他媒体との横断まで見据えるならやり方3（ETLツールでBigQuery）、自社システムに組み込みたい・完全に自由にしたいならやり方4（API直連携）です。
Google広告のときと同じ構図ですが、Yahoo!はやり方1と2が「API申請なしで使える」点に価値があります。順に設定手順を見ていきます。
やり方1: レポートテンプレートで毎朝メールに届かせる（申請不要） いちばん手軽なのは、管理画面に組み込まれているレポートのスケジュール機能です。
パフォーマンスレポートでテンプレートを作成し、作成スケジュール（日次・週次・月次）と送付先メールアドレスを設定すると、以後は指定のタイミングでレポートが自動送付されます。画面操作だけで完了し、費用も申請も不要です。
限界も明確で、届くのは「できあいのレポートファイル」です。数字の加工や蓄積、他データとの突き合わせはできないため、「毎朝の確認作業を消す」以上のことはできません。
やり方2: Yahoo!広告スクリプトでスプレッドシートに自動出力する（申請不要） Google Adsスクリプトに相当するものが、Yahoo!広告にもあります。Yahoo!広告スクリプト です。管理画面内で動くJavaScript実行環境で、ここが重要なのですが、APIの利用申請なしで レポート取得からスプレッドシート・Driveへの出力、メール・Slack通知まで自動化できます。
「法人としてAPIを申し込むほどではないが、スプレッドシートには毎日自動で溜めたい」という中小規模の運用では、実務上これが最有力です。個人事業主はAPI申請の対象外（法人限定）なので、その場合もこの方法になります。
検索広告・ディスプレイ広告の両方に対応しており、スケジュール実行も可能です。書き味はGoogle Adsスクリプトに近いため、Google側で自動化済みなら移植の感覚で書けます。Google側の書き方はGoogle広告レポート自動化のやり方｜API・BigQuery連携からAI分析まで にまとめています。
やり方3: ETLツールでBigQueryに自動蓄積する Google広告にはBigQuery Data Transferという無料の公式転送がありますが、Yahoo!広告には相当するものがありません 。BigQueryに集めたい場合は、ETLツールを使うか、やり方4のAPIで自作するかの二択です。
ETLツールでは、たとえばTROCCOが「Yahoo!検索広告」「Yahoo!ディスプレイ広告」の転送コネクタを公式提供しており、画面設定だけで日次のBigQuery転送を組めます。裏側では後述のAds APIが使われているため、API申請は自社で行う形です。ツールの月額は数万円からで、媒体数が増えるほど1媒体あたりの単価は下がります。
BigQueryまで来れば、Looker Studioでの可視化も他媒体との横断分析も自由です。BigQuery側の費用はストレージとクエリのみで、広告レポート程度のデータ量なら無料枠に収まることが多い、というのはGoogle広告のときと同じです。クエリ費用の考え方はBigQueryの料金体系とコスト削減｜課金トラップと対策 で解説しています。
やり方4: LINEヤフー広告APIで自由に取得する 自社システムへの組み込みや、ツール費用をかけずに完全自動化したい場合の本命です。GoogleのAds APIとは思想がだいぶ違うので、順を追って説明します。
手順1: API利用を申し込む（法人・ルートMCC権限が必要） LINEヤフー広告APIの利用条件は、法人であること と、ルートMCC（管理アカウント）の管理権限を持つビジネスID があることです。Google広告のような開発者トークンという仕組みはなく、法人単位でAPI利用そのものを申し込みます。API利用料については、Evastでこれまで運用してきた範囲では請求が発生したことはありません（正式な料金定めは利用約款側で確認してください）。審査期間の公式な明記はありませんが、実務では数日〜1週間程度を見ておくと安全です。
なお、2026年4月のLINE広告統合により、このAPIはLINE面を含むディスプレイ広告の公式APIにもなりました。旧LINE広告API側の終了スケジュールと移行のToDoはLINE広告レポート自動化の現在地｜API終了とLINEヤフー広告への移行 で整理しています。
以下、画面操作の手順です（※画面の表記・導線はバージョンによって異なる場合があります）。
(1) 広告管理ツールにルートMCC権限のあるビジネスIDでログイン
ブラウザで https://business.yahoo.co.jp/ のトップから「広告管理ツール」を開き、ルートMCCの管理権限を持つビジネスID でログインします（URLはヘルプ記事 https://ads-help.yahoo-net.jp/s/article/H000045039 内の「広告管理ツールにログイン」リンクからも辿れます）。個人アカウントや、権限がクライアントアカウント止まりのビジネスIDでは以降の申し込みメニューが表示されません。 権限が分からない場合は、社内でYahoo!広告の管理者に「ルートMCCの管理権限を、自分のビジネスIDに付与してほしい」と依頼してから進めてください。 (2) ベースアカウントで「ルートMCC」を選択
ログイン直後の画面上部（またはサイドバー）に**「ベースアカウント選択」というアカウント切替欄があります。プルダウンから、API申請対象の ルートMCC（管理アカウント）**を選択します。子アカウントを選んだ状態では申し込みメニューが出ません。 画面のタイトル部分に選択中のアカウント名（MCC名）が表示されていることを確認します。 (3) 「ツール」→「LINEヤフー広告 API お申し込み」を開く
画面**右上のグローバルナビゲーションにある「ツール」**をクリックすると、ドロップダウンメニューが開きます。 メニュー内の**「LINEヤフー広告 API お申し込み」**を選択します（旧UIでは「Yahoo!広告 API お申し込み」表記の場合あり）。 お申し込みフォーム画面に遷移し、契約種別の選択と会社情報の入力を求められます。 (4) 契約種別を選び、必要事項を入力→約款に同意して送信
「契約種別」で自社に該当するものを選択します。選択肢は**「Yahoo!広告正規代理店」「ツールプロバイダー」「運用代行」「広告主」**の4種類です（複数該当する場合は、実態にいちばん近いものを選びます）。 フォームの案内に従って会社名・担当者名・連絡先メールアドレス等を入力します。 画面下部の**「LINEヤフー広告 API利用約款」のリンクを開いて内容を確認し、 「同意する」のチェックボックスにチェック**を入れます。 「申し込む」（または「送信」）ボタン をクリックして送信します。(5) 承認完了メールを待つ
数日〜1週間ほどで、ビジネスIDに登録したメールアドレス宛に**「【Yahoo!広告 API】登録完了のお知らせ」**という件名のメールが届きます。件名は変更される可能性があるため、ads-developers LINEヤフー広告 API 等でメール検索してください。 このメールが届くまでは次の手順2（API管理ツール）にログインしてもアプリケーションが登録できません。届いたら手順2に進みます。 手順2: API管理ツールでアプリケーションを登録する 承認メールが届いたら、API管理ツール （LINEヤフー広告APIのアプリケーション管理サイト。広告管理ツールとは別サイト）でアプリケーションを登録し、client_id と client_secret を発行します。
(1) API管理ツールにログインする
ブラウザで https://connect-business.yahoo.co.jp/cooperation/ads-developers.yahoo.co.jp の「はじめてのAPI」ページから最新のAPI管理ツールへのリンクを辿ってください）。 手順1と同じルートMCCの管理権限を持つビジネスID でログインします。承認メール受信前だと「利用申し込みが未完了です」等のメッセージで先に進めません。 複数企業の権限がある場合は、画面右上のプルダウン から対象企業（API申し込みを行った法人）を選択します。 (2) アプリケーション一覧画面から「登録アプリケーション」を開く
ログイン後のトップ画面の左サイドバー（またはグローバルナビ）にある**「登録アプリケーション」**をクリックします。既存のアプリがある場合はここに一覧表示されます。 画面上部（または一覧右上）の**「登録」ボタン**をクリックし、新規アプリケーション登録フォームに移動します。 (3) 登録フォームに入力する
以下3項目がすべて必須です。入力例をそのまま流用しても問題ありません（後から編集可）。
アプリケーション名 : evast-yahooads-report のように**「社名-yahooads-report」形式**にしておくと、他アプリと区別しやすいです。この文字列はユーザー認可画面にも表示されます。アプリケーションの説明 : 用途を1文で。例: 社内のYahoo!広告レポートをBigQueryへ日次転送するためのバッチ 。この文字列も認可画面に表示されます。リダイレクトURI : 開発段階または社内サーバー用途では oob と入力 します（コールバックURLを立てずに、認可コードをブラウザ画面に表示させる特殊値）。登録画面で oob が弾かれる場合は、自ホストのコールバック（例: http://localhost:8080/callback のような開発用URLを許容する運用であればlocalhost、そうでなければ社内で用意した https:// のURL）を登録し、簡易サーバー（nc -l 8080 やPythonの http.server 等）で受け取る方法にフォールバックしてください。ユーザーに認可させるWebサービス等では自社のコールバックURL（本番はHTTPS必須）を入力します。入力後、「確認」ボタン →内容確認画面で**「登録」ボタン**をクリックすると登録完了です。
(4) client_id と client_secret を控える
登録完了後は自動的にアプリケーション詳細画面（または一覧画面）に戻ります。 一覧の該当行に **Client ID（クライアントID）**が表示されているのでコピーします。 Client Secret（クライアントシークレット）は一覧では伏字（************）になっているため、行内の 「表示する」リンクこの値は絶対にコード内へ直書きせず、環境変数やシークレット管理サービスに保存 してください。万が一シークレットが漏洩した場合は、同じ画面の**「シークレット再生成」**から作り直せます（再生成すると旧シークレットは即失効）。 手順3: OAuth 2.0でリフレッシュトークンを取得する 認証はOAuth 2.0の認可コードフロー で、認可サーバーは専用の biz-oauth.yahoo.co.jp、スコープは yahooads 固定です。運用上のポイントを先にまとめます。
アクセストークンの有効期限は1時間 （実装では expires_in=3600 が返る想定。公式リファレンスの該当ページで最新値を確認してください）。バッチでは毎回リフレッシュトークンから取り直すのが確実です。リフレッシュトークンは承認を解除するまで有効 とされています。Google（テストモードで7日失効）のような明示的な期限は無い一方、6か月以上APIアクセスが無いクライアントID（アプリケーション）自体が削除されることがある ため、月1回程度は定期実行して生存確認しておくのが安全です。APIリクエストには Authorization: Bearer ヘッダーに加えて、x-z-base-account-id ヘッダー（ベースアカウントID。Google Ads APIの login-customer-id に相当）を毎回付けます。 (1) 認可URLをブラウザで開いて認可コードを得る
以下のURLの YOUR_CLIENT_ID を手順2-(4)で控えたクライアントIDに置き換え、1行のままブラウザのアドレスバーに貼り付けて開きます。redirect_uri は手順2-(3)で登録した値（例では oob）とURLエンコード済みで完全一致 している必要があります。なお oob は英字のみのためエンコード不要でそのまま貼ってOKですが、自社コールバックURL（例: https://example.com/callback）を使う場合は https%3A%2F%2Fexample.com%2Fcallback の形にエンコードして貼ってください。
https://biz-oauth.yahoo.co.jp/oauth/v1/authorize?response_type=code&client_id=YOUR_CLIENT_ID&redirect_uri=oob&scope=yahooads&state=random12345 パラメータの意味: response_type=code（認可コードフロー）、scope=yahooads（固定）、state はCSRF対策の任意文字列（自分で決めてOK。返却時に同じ値が返るのを確認するだけ）。
Yahoo!ビジネスIDのログイン画面が出るので、API対象アカウントの管理権限を持つビジネスID でログインします（申請者と同一である必要はありませんが、対象MCCに権限のあるIDでないと認可画面で権限不足エラーになります）。 「（アプリ名）が Yahoo!広告 API の利用を求めています」といった同意画面 で**「承認」ボタン**をクリックします。 redirect_uri=oob の場合、ブラウザは外部URLに飛ばず、画面に認可コード（code=xxxxxxxx の形式ではなく、コード文字列そのもの）が表示 されます。この文字列をコピーします。コールバックURLを登録している場合は、https://your-callback/?code=...&state=random12345 にリダイレクトされるので、URL中の code= の後ろ〜&state の手前をコピーします。認可コードは短時間で失効 します（数分〜10分程度が目安）。すぐに次のトークン交換へ進んでください。(2) 認可コードをトークンに交換する
ターミナルで以下のcurlコマンドを実行します（YOUR_CLIENT_ID・YOUR_CLIENT_SECRET・認可コードの3か所を自分の値に置き換え。redirect_uri はアプリ登録時の値と完全一致させます）。バックスラッシュ（\）による行継続はmacOS/Linux（またはWSL・Git Bash）前提です。PowerShell/cmdでは \ を外して1行にまとめてください。
curl -X POST "https://biz-oauth.yahoo.co.jp/oauth/v1/token" \ -d "grant_type=authorization_code" \ -d "client_id=YOUR_CLIENT_ID" \ -d "client_secret=YOUR_CLIENT_SECRET" \ -d "redirect_uri=oob" \ -d "code=ここに(1)でコピーした認可コードを貼り付け" 成功すると次のJSONが返ります。
{ "access_token" : "Atzz|IwEB..." , "token_type" : "bearer" , "expires_in" : 3600 , "refresh_token" : "AAJ...." } refresh_token の値を環境変数やシークレット管理サービスに保存 してください。以降の自動実行では、このリフレッシュトークンさえあればユーザー再ログインなしでアクセストークンを取り直せます。invalid_grant エラーが返る場合は認可コードの期限切れか、redirect_uri の不一致が典型なので(1)からやり直してください。
手順4: ベースアカウントID（x-z-base-account-id）を取得する APIリクエストには毎回 x-z-base-account-id ヘッダーが必要です（Google Ads APIの login-customer-id に相当）。この値はBaseAccountService/get を呼ぶと一覧で取得できます。ここでは(1)ベースアカウントIDをcurlで手動確認する方法と、(2)レポート取得に使う広告アカウントIDの調べ方を示します（Python内で自動取得したい場合は、次項のPythonスクリプトのフローに BaseAccountService/get を1つ挟むだけで組み込めます）。
(1) curlでベースアカウントIDを確認する
手順3-(2)で取得したアクセストークン（Atzz|...）と、対象APIの種別（検索広告なら ads-search、ディスプレイ広告なら ads-display）を使って以下を実行します。このAPIは「自分がどのベースアカウントに紐づいているか」を返すためのものなので、ここだけは例外的に x-z-base-account-id ヘッダー不要 で呼べます（他のAPIはこの後で取得したIDを使って必ずヘッダーを付けます）。検索広告の例:
curl -X POST "https://ads-search.yahooapis.jp/api/v20/BaseAccountService/get" \ -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \ -H "Content-Type: application/json" \ -d '{}' 成功時のレスポンス（抜粋）はこの形です。
{ "rval" : { "values" : [ { "baseAccount" : { "accountId" : "1111111111" , "accountName" : "Evast MCC" } } ] } } この rval.values[].baseAccount.accountId（10桁前後の数値）がベースアカウントID です。複数のMCCに権限がある場合は values が複数返るので、レポート対象の広告アカウントを配下に持つMCCの accountId を選びます。
(2) レポート対象の広告アカウントID（accountId）を控える
レポート取得時に指定する accountId は、ベースアカウントIDとは別の、各広告アカウントのアカウントID です。広告管理ツールで対象アカウントを開き、URLの accountId=xxxxxxxxxx 部分、または画面右上のアカウント情報表示の「アカウントID」欄から確認します。
手順5: レポートを取得する（非同期3ステップ） ここがGoogle広告APIとの最大の違いです。GAQLのようなクエリ言語も、1リクエストでデータが返る同期取得もありません。レポートは必ず「定義を作る→完成を待つ→ダウンロードする」の非同期3ステップ です。
① addレポート定義を作成
→
② get数秒おきにポーリング
→
③ downloadCSVを取得
②で reportJobStatus が COMPLETED になるまで待つ。GAQLのような同期取得（1リクエストで即データ）は無い
LINEヤフー広告 APIのレポート取得は非同期3ステップ。定義を作り、完成を待って、CSVを受け取る さらに、検索広告とディスプレイ広告でAPIが完全に分かれています 。ベースURLも、レポートの仕様も別です（検索 https://ads-search.yahooapis.jp/api/v20、ディスプレイ https://ads-display.yahooapis.jp/api/v20）。使うサービスは ReportDefinitionService/add（定義作成）、ReportDefinitionService/get（ジョブ状態取得）、ReportDefinitionService/download（CSVダウンロード）の3つです。サービス名・メソッド名は必ず公式リファレンス（検索広告 v20 リファレンス ）で最新版を確認してから使ってください 。バージョンアップで名称や引数が変わることがあります。
全操作はPOST＋JSONで、キャンペーン別×日別の主要指標を任意の期間で取るレポート定義はこの形になります（検索広告 v20 / 月次まとめ用に期間指定した例）。
{ "accountId" : 1234567890 , "operand" : [ { "reportName" : "campaign_daily_2026-07" , "reportType" : "CAMPAIGN" , "fields" : [ "DAY" , "CAMPAIGN_ID" , "CAMPAIGN_NAME" , "IMPS" , "CLICKS" , "COST" , "CONVERSIONS" ], "reportDateRangeType" : "CUSTOM_DATE" , "dateRange" : { "startDate" : "20260701" , "endDate" : "20260731" }, "reportDownloadFormat" : "CSV" , "reportDownloadEncode" : "UTF8" , "reportLanguage" : "JA" , "reportCompressType" : "NONE" } ] } 一方、日次バッチとして毎朝回すことを想定したPythonの最小実装は次のとおりです（前日分のみを固定で取るため reportDateRangeType に YESTERDAY を使い、dateRange は指定しません。YESTERDAY は公式に用意されている reportDateRangeType の列挙値の1つで、日次バッチの定番指定です）。ライブラリは requests のみで、認証情報を書き換えて python yahoo_ads_report.py を実行すれば campaign_daily.csv がカレントディレクトリに保存されます。
(1) Python環境を準備する
ターミナルで以下を順に実行します（Python 3.9以降がインストール済みの前提）。
# 作業用ディレクトリを作成して移動（Windows PowerShellでは && を ; に置き換えるか、2行に分けて実行） mkdir yahooads-report && cd yahooads-report # 仮想環境を作成して有効化（Windowsは .venv\Scripts\activate） python3 -m venv .venv source .venv/bin/activate # HTTPクライアントをインストール pip install "requests>=2.31" pip show requests を実行してバージョンが表示されればインストール成功です。
(2) スクリプトを作成する
以下の内容を yahoo_ads_report.py として保存し、冒頭「ここから自分の値に書き換える」ブロックの5つの定数を、ここまでの手順で控えた値に書き換えます（それ以外の変更は不要です）。
"""LINEヤフー広告（検索広告）のキャンペーン日次レポートを前日分だけCSVでダウンロードするスクリプト。 実行方法: python yahoo_ads_report.py 成功すると、カレントディレクトリに campaign_daily.csv が生成されます。 """ import sys import time import requests # ==== ここから自分の値に書き換える ==== CLIENT_ID = "xxxxxxxxxxxxxxxxxxxxxxxxxxxx" # 手順2-(4) のクライアントID CLIENT_SECRET = "xxxxxxxxxxxxxxxxxxxxxxxxxxxx" # 手順2-(4) のクライアントシークレット（表示するをクリック） REFRESH_TOKEN = "AAJ...." # 手順3-(2) で保存したリフレッシュトークン BASE_ACCOUNT_ID = "1111111111" # 手順4-(1) の baseAccount.accountId ACCOUNT_ID = 1234567890 # 手順4-(2) の広告アカウントID（数値のまま） # ==== ここまで ==== # 検索広告のAPIベースURL。ディスプレイ広告用は "https://ads-display.yahooapis.jp/api/v20" API_BASE = "https://ads-search.yahooapis.jp/api/v20" TOKEN_URL = "https://biz-oauth.yahoo.co.jp/oauth/v1/token" POLL_INTERVAL_SEC = 3 # ポーリング間隔（秒） POLL_MAX_ATTEMPTS = 200 # 最大試行回数（3秒 × 200 = 最長10分待つ） def refresh_access_token () -> str : """リフレッシュトークンからアクセストークンを取得する（有効期限は1時間）。""" res = requests.post( TOKEN_URL , data = { "grant_type" : "refresh_token" , "client_id" : CLIENT_ID , "client_secret" : CLIENT_SECRET , "refresh_token" : REFRESH_TOKEN , }, timeout = 30 , ) res.raise_for_status() payload = res.json() if "access_token" not in payload: # invalid_grant → 手順3-(1) から取り直す raise RuntimeError ( f "アクセストークン取得に失敗: { payload } " ) return payload[ "access_token" ] def build_headers (access_token: str ) -> dict : return { "Authorization" : f "Bearer { access_token } " , "x-z-base-account-id" : BASE_ACCOUNT_ID , "Content-Type" : "application/json; charset=UTF-8" , } def add_report_definition (headers: dict ) -> str : """レポート定義を作成し、reportJobId を返す。""" body = { "accountId" : ACCOUNT_ID , "operand" : [ { "reportName" : "campaign_daily" , "reportType" : "CAMPAIGN" , "fields" : [ "DAY" , "CAMPAIGN_ID" , "CAMPAIGN_NAME" , "IMPS" , "CLICKS" , "COST" , "CONVERSIONS" , ], "reportDateRangeType" : "YESTERDAY" , # 前日分 "reportDownloadFormat" : "CSV" , "reportDownloadEncode" : "UTF8" , "reportLanguage" : "JA" , "reportCompressType" : "NONE" , # 集計行と列ヘッダーを無効化（BigQueryロード時の二重集計を防ぐ） "reportSkipReportSummary" : "TRUE" , "reportSkipColumnHeader" : "FALSE" , } ], } res = requests.post( f " {API_BASE} /ReportDefinitionService/add" , json = body, headers = headers, timeout = 60 , ) res.raise_for_status() payload = res.json() try : return payload[ "rval" ][ "values" ][ 0 ][ "reportDefinition" ][ "reportJobId" ] except ( KeyError , IndexError ) as e: raise RuntimeError ( f "reportJobId の取得に失敗: { payload } " ) from e def wait_until_completed (headers: dict , job_id: str ) -> None : """reportJobStatus が COMPLETED になるまでポーリングする。FAILED は例外化。""" for _ in range ( POLL_MAX_ATTEMPTS ): res = requests.post( f " {API_BASE} /ReportDefinitionService/get" , json = { "accountId" : ACCOUNT_ID , "reportJobIds" : [job_id]}, headers = headers, timeout = 60 , ) res.raise_for_status() payload = res.json() status = payload[ "rval" ][ "values" ][ 0 ][ "reportDefinition" ][ "reportJobStatus" ] if status == "COMPLETED" : return if status == "FAILED" : raise RuntimeError ( f "レポート生成に失敗: { payload } " ) time.sleep( POLL_INTERVAL_SEC ) raise TimeoutError ( f "reportJobStatus が {POLL_INTERVAL_SEC * POLL_MAX_ATTEMPTS} 秒以内に COMPLETED になりませんでした" ) def download_report (headers: dict , job_id: str , out_path: str ) -> None : """完成したレポートをダウンロードしてファイルに書き出す。レスポンスボディがCSV本体。""" res = requests.post( f " {API_BASE} /ReportDefinitionService/download" , json = { "accountId" : ACCOUNT_ID , "reportJobId" : job_id}, headers = headers, timeout = 120 , ) res.raise_for_status() with open (out_path, "wb" ) as f: f.write(res.content) def main () -> None : access_token = refresh_access_token() headers = build_headers(access_token) job_id = add_report_definition(headers) print ( f "レポート生成をリクエストしました（reportJobId= { job_id } ）" ) wait_until_completed(headers, job_id) print ( "レポートが完成しました。ダウンロードします" ) out_path = "campaign_daily.csv" download_report(headers, job_id, out_path) print ( f "ダウンロード完了: { out_path } " ) if __name__ == "__main__" : try : main() except requests.HTTPError as e: # HTTP 403 → レート制限（5req/秒）超過。30秒以上待って再試行 # HTTP 401 → アクセストークン失効。refresh_access_token を再実行 print ( f "HTTPエラー: { e.response.status_code } { e.response.text } " , file = sys.stderr) sys.exit( 1 ) except Exception as e: print ( f "エラーが発生しました: { e } " , file = sys.stderr) sys.exit( 1 ) (3) 実行して結果を確認する
python yahoo_ads_report.py 「ダウンロード完了: campaign_daily.csv」と表示され、カレントディレクトリに campaign_daily.csv が生成されていれば成功です。1行目が列名（DAY,CAMPAIGN_ID,CAMPAIGN_NAME,IMPS,CLICKS,COST,CONVERSIONS）、2行目以降が前日の日次×キャンペーン別の実績になります。上記スクリプトはリトライを組み込んでいないため、初回で HTTP 401（アクセストークン失効）や HTTP 403（レート制限超過）で落ちた場合はそのまま再実行してください。定期実行に載せる際は、requests 呼び出しをリトライでラップするか、ジョブスケジューラ側で失敗時再実行を有効にしておくのが安全です。
これをCloud FunctionsやCloud Runで毎朝5時以降に実行し、CSVをBigQueryにロードすれば、やり方3をツール費用なしで自作したことになります。レート制限は5リクエスト/秒 （超過はHTTP 403・30秒以上待って再試行が公式推奨）で、レポート用途で困ることはまずありません。
Google広告APIとの違い早見表 Google側の経験があるほど戸惑いやすいポイントを並べます。
観点 Google Ads API LINEヤフー広告 API APIの構成 1つのAPIで全キャンペーン 検索とディスプレイで完全に別 レポート取得 GAQLで同期取得（searchStream） 非同期3ステップのみ 利用開始 開発者トークン＋OAuth 法人単位のAPI申し込み＋OAuth 費用の単位 cost_micros（100万分の1） 円の値そのまま 公式ライブラリ 多言語で充実 OpenAPI仕様＋生成サンプル中心 バージョン寿命 約1年 短め（年3〜4回リリース）
特にバージョン移行は要注意です。公式には年3〜4回の新バージョンリリース が案内されており、旧バージョンは新バージョン公開後しばらくの間だけ併用可能とされています。実務では年2回程度の載せ替え作業が前提 と見ておくと安全です。2026年7月時点の最新はv20で、公式リファレンス（ads-developers.yahoo.co.jp/reference/ads-search-api/v20/ ）から確認できます。過去バージョンのサポート終了日は公式のバージョン管理・deprecationスケジュールを都度確認してください。
実務でハマる落とし穴5つ Evastで広告データ基盤を構築してきた中で、Yahoo!広告まわりで繰り返し踏まれているポイントです。
1. CSVに合計行とヘッダーが混ざる 。ダウンロードしたCSVには、デフォルトで列ヘッダーと合計（Total）行が含まれます。そのままBigQueryにロードすると集計が合計行のぶん二重になります。レポート定義の reportSkipReportSummary と reportSkipColumnHeader で制御するのが定石です。
2. 当日データは暫定値 。当日分の実績は翌日にかけて順次確定していきます（公式ヘルプでも「翌日以降に確定値になる」旨が案内されています）。日次バッチを深夜0時に回すと未確定の数字を取り込むため、日本時間の早朝5時以降の実行 にしておくと未確定値を掴みにくくなります。
3. 組み合わせられないフィールドがある 。検索広告のレポート仕様には、指定可能なフィールドの組み合わせに制約があります（例として、コンバージョン名別（CONVERSION_NAME）を含めた場合に費用系フィールドを同時指定できないケースがある、といった制約）。組み合わせの可否は v20 リファレンスのレポート仕様表で必ず確認してください。「CV名別に費用も並べたい」といった要件は、1本のレポートで足りない場合は2本に分けてBigQuery側で結合する設計になります。
4. 過去データは37か月まで 。2026年7月29日から、検索広告のパフォーマンスデータは「抽出日から37か月前まで」しか取得できなくなりました。3年より前の実績はAPIでも遡れないため、長期分析をしたいならBigQueryへの蓄積を今から始めておく必要があります。
5. ポーリングの作り込み不足 。非同期レポートは、失敗時に FAILED ステータスとエラー詳細が返ります。COMPLETEDだけを待つ実装だと、失敗時に無限ループやタイムアウトになりがちです。公式サンプルと同じく、FAILED判定と試行回数の上限を必ず入れてください。
集めたデータをAIにつないで考察まで自動化する 数字が自動で集まるようになったら、考察もAIに任せられます。やり方2のスプレッドシートやCSVをChatGPT・Gemini・Claudeに渡し、「CPAが悪化したキャンペーンと要因の仮説」「予算の再配分案」を数字を引用して挙げるよう指示するだけでも、週次レポートの所感の下書きは返ってきます。
Yahoo!広告で特に効くのは、検索クエリレポートをAIに読ませる 使い方です。SEARCH_QUERYレポートをCSVで取得し、「CVにつながっていない検索語句から除外キーワード候補を理由つきで挙げて」と渡せば、数分で除外候補の一覧が返ります。Evastでも広告運用の日次ルーチンにこの形を組み込んでいます。
やり方3・4でBigQueryに蓄積している場合は、「SQLで前日分を集計→生成AIのAPIに考察を書かせる→Slackに配信」という日次パイプラインまで組めます。組み方はGoogle広告のときと同じで、コツも同じ。生データを丸投げせず、集計してから渡す のが定石です。何万行の生ログより、キャンペーン別に集計した数十行のほうが、考察の精度もAPI費用も桁違いに軽くなります。
こうしたAI分析・異常検知を既製で載せたい場合は、私たちのアドヨミAI のように、広告データのBigQuery集約とAI考察をセットで提供するサービスという選択肢もあります。
Google以上に外注判断が早くなる Yahoo!広告単体なら、やり方1〜2は今日から無料で始められます。API直連携も、法人でルートMCC権限があれば申請から1〜2週間で動かせます。
ただ、GoogleとYahoo!の2媒体を自作した時点で、認証方式もレポート仕様もバージョン更新サイクルも異なる連携を2本抱えることになります。Metaが加わると3本です（Metaの手順とトークン管理の癖はMeta広告(Facebook)レポート自動化のやり方｜APIからAI分析まで で解説しています）。Evastの現場でも、Google単独なら片手間で保守できていたスクリプトが、Yahoo!の非同期レポートとバージョン載せ替えを含めた瞬間に「四半期に1度は必ず触るコード」に格上げされ、保守工数が体感2倍になりました。公式転送が無料で揃っているGoogleと違い、Yahoo!は自作かツール費用のどちらかが必ず発生するため、媒体横断の段階で構築サービスに寄せる判断がGoogleより一段早くなる というのが実務での結論です。外注する場合の費用相場は広告レポート自動化の費用は？ツール・代行の料金相場と選び方 にまとめています。
私たちのアドヨミAI は、Google・Yahoo!・Meta・TikTokなどの広告データをAPIで自動連携し、自社所有のBigQueryに集約するサービスです。この記事のやり方3〜4の構築と保守（バージョン載せ替え含む）、AI分析までをまとめて肩代わりし、初期5万円・月1.5万円〜/媒体で運用できます。
まとめ Yahoo!広告にはLooker Studioの公式コネクタが無く 、Googleと同じ進め方は通用しない。だからこそ、入口の選び方が最初の分岐点になります。
メールで届けば十分ならレポートテンプレート 、スプレッドシート蓄積ならYahoo!広告スクリプト 。どちらもAPI申請不要で無料で始められる BigQueryに集めるならETLツール（TROCCO等）か、API自作 の二択で、公式の無料転送は無い API直連携は法人＋ルートMCC権限 で申し込み、レポートは検索／ディスプレイ別かつ非同期3ステップになる 主な落とし穴はCSVの合計行、当日データの暫定値、37か月の保持制限、そして年2回程度のバージョン載せ替え。集めた数字はAIにつないで考察や除外キーワード候補の洗い出しまで自動化 できます。2媒体目以降は自作の保守が急に重くなるため、媒体横断のタイミングが構築サービスへの切り替え判断点 です。
まずはやり方1のメール配信かやり方2のスクリプトを、今日の運用に1つ入れるところから始めてみてください。
Yahoo!広告を含む複数媒体のレポート自動化はEvastへ 株式会社EvastのアドヨミAI は、Google・Yahoo!・Meta・TikTokなど主要媒体の広告データをAPIで自動連携し、自社所有のBigQueryに集約する半スクラッチ型の広告レポート自動化・AI分析サービス です。
「Yahoo!広告のAPI申請や非同期レポートの実装を自社で持ちたくない」 「Google・Yahoo!・Metaの数字を1つのダッシュボードで見たい」 「レポートだけでなく、AIでの分析や異常検知まで載せたい」 現状の運用の棚卸しからで構いません。1媒体・最短2週間から始められます。
→ アドヨミAIの詳細・料金を見る 無料相談を申し込む
