この記事について
この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。
Google公式のAdSense Management API v2、OAuth 2.0、クライアントライブラリの一次情報を確認し、AdSenseの管理データを安全に取得・分析する仕組みを、初心者から運用担当者まで分かる形で整理します。情報確認基準日：2026-09-19
検証ステータス：Google公式一次情報を確認。名称・APIバージョン・OAuth Scope・公式リンクは基準日時点で再確認しています。
まず一言でいうと
AdSense Management APIは、Google AdSenseの管理画面で見る情報を、プログラムから取得・整理するための窓口です。
API（Application Programming Interface）とは、画面を人が操作する代わりに、プログラム同士が決められた形式で情報をやり取りする入口です。たとえば「過去7日分の推定収益とページビューを毎朝CSVへまとめる」といった処理を自動化できます。
この記事を読むと、AdSense Management APIがGoogle全体のどこに位置し、何を自動化でき、OAuth 2.0でなぜ本人の許可が必要なのか、Microsoft系の仕組みに置き換えるとどう考えればよいかまで分かります。
Google全体では何のパーツ？
| 観点 | 位置づけ |
|---|---|
| 大分類 | 広告・収益化 / 開発者向けAPI |
| 大きな目的 | AdSenseの管理・レポート情報を人手だけに頼らず取得・分析する |
| このAPIの役割 | AdSenseと自作スクリプト・分析処理をつなぐデータ取得パーツ |
| 一緒に使うもの | Google AdSense、Google Cloud Project、Google Auth Platform / OAuth 2.0、Google API Client Libraries |
| 主な利用者 | サイト運営者、分析担当者、開発者 |
AdSense Management APIそのものが広告を配信したり、広告をクリックしたりするものではありません。AdSenseで発生した管理情報を外部の処理へ安全につなぐ部品と考えると分かりやすくなります。
flowchart LR VISITOR[サイト閲覧者] --> SITE[Webサイト] SITE --> ADS[Google AdSense] ADS --> CONSOLE[AdSense管理画面] ADS --> API[AdSense Management API v2] USER[サイト運営者] --> CONSENT[OAuth 2.0で許可] CONSENT --> API API --> SCRIPT[Pythonなどの安全な取得処理] SCRIPT --> REPORT[CSV / 集計表] REPORT --> ANALYSIS[分析・確認]
何ができる？
基準日時点のRESTリファレンスでは、accounts、adclients、adunits、payments、policyIssues、reports、sitesなどのリソースが提供されています。ブログ運用で特に利用しやすいのがレポート取得です。
| 処理 | 何に使う？ |
|---|---|
reports.generate | 条件を指定してJSON形式のレポートを取得する |
reports.generateCsv | CSV形式でレポートを取得する |
| 保存済みレポートの生成 | AdSense側で保存したレポート設定を再利用する |
たとえば日付別に ESTIMATED_EARNINGS（推定収益）、PAGE_VIEWS（ページビュー）、CLICKS（クリック数）などを取得し、Excelや分析処理へ渡せます。
認証はOAuth 2.0 ― 初心者向けにいうと
OAuth 2.0とは、Googleアカウントのパスワードをプログラムへ渡さず、「このアプリにはAdSenseデータの参照だけを許可する」と権限を渡す仕組みです。
Scope（スコープ）は、その許可範囲を表します。Google公式ではAdSense Management API v2向けに次のScopeが案内されています。
| Scope | 意味 |
|---|---|
adsense | AdSenseデータの表示と管理 |
adsense.readonly | AdSenseデータの表示 |
参照だけが目的なら、必要以上の権限を渡さないため adsense.readonly を優先します。
sequenceDiagram participant U as サイト運営者 participant A as 自作アプリ participant G as Google OAuth participant S as AdSense API U->>A: レポート取得を開始 A->>G: 必要なScopeで認可を要求 G->>U: AdSense参照を許可しますか？ U-->>G: 許可 G-->>A: Access Token A->>S: Token付きでレポート要求 S-->>A: 収益・ページビュー等
Access Tokenは「許可済みであることをAPIへ示す一時的な通行証」のようなものです。パスワードではありませんが、漏えいすれば悪用され得るためGitHubへ保存しません。
Google Cloud Projectは必要？
自作アプリからGoogle APIを利用する場合、Google Cloud側でProjectを用意し、対象APIとOAuthクライアントを設定するのが基本です。Projectは「API利用の設定や認証情報をまとめる箱」と考えると分かりやすいでしょう。
ここで重要なのは、AdSenseの収益データそのものをGoogle Cloudへ移すという意味ではないことです。ProjectはAPIを呼び出すアプリ側の設定・認証の単位として登場します。
具体的な実務例
一般利用者・事務職 / サイト運営者
毎朝AdSense画面を開いて数字を書き写す代わりに、前日分をCSVへ自動出力してExcelで推移を確認できます。手入力ミスを減らし、「昨日だけ急に数字が変わった」といった変化へ気づきやすくなります。
IT管理者
OAuthクライアント、Tokenの保存場所、実行アカウント、ログ、出力先を管理します。特に「取得できるから全部GitHubへ置く」設計にせず、公開してよい列だけへ絞ることが重要です。
開発者
日次バッチ、ダッシュボード、他のアクセス解析データとの突合などへ組み込めます。Google API Client Librariesを使えば、HTTP要求や認可処理の一部を言語向けライブラリへ任せられます。
Microsoft経験者ならどう考える？
完全な同等製品ではありませんが、仕組みを理解する橋渡しとしては次のように考えられます。
| Google側 | Microsoftで近い考え方 | 違い |
|---|---|---|
| AdSense Management API | Microsoft Graph等のREST API利用 | GraphはMicrosoft 365等を横断するAPIで、AdSense APIはAdSense領域に特化 |
| Google OAuth 2.0 | Microsoft identity platform / OAuth 2.0 | 認可の基本概念は近いが、登録画面・Scope・対象APIが異なる |
| Google Cloud Project | Azureのアプリ/API利用時の管理単位を考える感覚 | Azure subscriptionやEntra app registrationと1対1で同じものではない |
「管理画面の情報を、OAuthで許可されたアプリがAPI経由で読む」という全体像はMicrosoft Graphを使った経験がある人には理解しやすいでしょう。
Pythonで安全に試す最小イメージ
以下は構造を理解するためのサンプルです。IDはダミーです。token.json は認証情報なのでGitHubへ保存しません。
from google.oauth2.credentials import Credentials
from googleapiclient.discovery import build
SCOPES = ['https://www.googleapis.com/auth/adsense.readonly']
creds = Credentials.from_authorized_user_file('token.json', SCOPES)
service = build('adsense', 'v2', credentials=creds)
result = service.accounts().reports().generate(
account='accounts/pub-0000000000000000', # ダミー
dateRange='LAST_7_DAYS',
dimensions=['DATE'],
metrics=['ESTIMATED_EARNINGS', 'PAGE_VIEWS'],
).execute()
print(result)
何を見る？ 日付単位のレポート行が返ることを確認します。
成功条件は？ OAuth認可エラーではなく、指定したDimension / Metricに対応するレポートが返ることです。
1か所変えるなら？ LAST_7_DAYS の期間を変え、取得範囲がどう変化するか確認するとAPIの考え方を理解しやすくなります。
実務では「取得」より「安全に残す」が重要
APIレスポンスをそのまま公開リポジトリへ置かず、分析に必要な列だけ抽出します。
date,estimated_earnings,page_views 2026-09-15,0.00,123 2026-09-16,0.00,145
この例の値は説明用です。実運用ではアカウント識別子、メールアドレス、OAuth Token、Client Secret、生の認証レスポンスなどを公開対象から除外します。
flowchart LR TIMER[systemd timer] --> PY[Python] PY --> API[AdSense Management API] API --> RAW[raw response] RAW --> SAN[必要列抽出 / 匿名化] SAN --> SAFE[safe CSV] SAFE --> ANALYSIS[Excel・分析処理] SAN -. 秘密情報は除外 .-> SECRET[安全な保管領域]
料金・アカウント・提供状態
AdSense Management APIを使うには、対象となるAdSenseデータへアクセスできるGoogleアカウントと、API利用のための認証設定が必要です。APIの利用条件・割当・AdSense自体の契約条件は将来変更される可能性があるため、実装時は公式ドキュメントとGoogle Cloud Consoleの表示を再確認してください。 変動しやすい条件を将来まで固定の料金として断定しません。
よくある勘違い
広告をクリックするAPI？
違います。広告クリックを自動化するためのAPIではありません。管理情報やレポート等を扱うAPIです。
ESTIMATED_EARNINGS は確定額？
名前のとおり推定値です。分析では確定した支払額と同一視しないようにします。
account IDを実値でサンプルへ書いてよい？
公開コードではダミー値へ置き換えます。認証情報だけでなく、不要な識別子も公開しない設計にします。
APIがあるならService Accountだけで読める？
「Google APIだから全部Service Accountでよい」とは考えません。AdSenseはユーザーのAdSenseデータへの認可が中心なので、対象メソッドが要求するOAuth Scopeと公式認証手順を確認します。
セキュリティで最低限守ること
読み取りだけなら可能な限りread-only Scopeを使う。
OAuth TokenやClient SecretをGitHubへ保存しない。
認証ファイルをソースツリー外のアクセス制限された場所へ置く。
APIから得たデータも「秘密でなければ全部公開」ではなく、目的に必要な列だけ残す。
定期処理では失敗ログへTokenやレスポンス全文を不用意に出さない。
Papandaで触ってわかる：Service Account JSONをGitへ入れない検査
見える成果物：PowerShellが秘密鍵らしい文字列や典型的なcredentialファイル名を検出して警告。 実鍵は使わずダミーfixtureで検証します。Daily Codeでは private_key、client_email 等の典型項目を検出し、「見つけたら削除」ではなくcommit前に止めるチェックにします。
Google公式情報
結局どういうサービス？
AdSense Management APIは、AdSenseの管理・レポート情報を、自分の分析や自動処理へ安全につなぐためのAPIです。
初心者はまず「管理画面をプログラムから読める窓口」と理解すれば十分です。実務では、取得コードそのものよりも、OAuthの権限を必要最小限にすること、Tokenを守ること、取得後のデータをどこまで保存・公開するかを設計することが重要です。
