Codexで広告APIの認証・トークン更新を自動化！環境構築から実装まで

Codexで広告APIの認証・トークン更新を自動化する方法｜環境構築から実装ステップまで解説

結論：Codexを使えば広告APIの認証とトークン更新はほぼ全自動化できる

広告API（Google広告、Yahoo!広告、各種SNS広告など）は、OAuth2をベースにした認証・認可方式を採用しており、アクセストークンとリフレッシュトークンを正しく扱うことが運用の要になります。しかし、これを毎回手作業で行うと、更新漏れや人的ミスが発生しやすく、運用効率も悪くなります。

この記事では、動画の内容をもとに、AIコード生成ツール「Codex」を活用して、広告APIの認証処理とトークン更新処理を自動化する具体的な流れを、環境構築から実装手順まで体系立てて解説します。

最終的には、以下ができる状態をゴールとします。

• 必要なSDK・ライブラリが揃ったPython（またはNode.js）環境が用意できる
• 広告APIのOAuth2認証フローを理解し、コードに落とし込める
• Codexに適切なプロンプトを投げて、認証・トークン更新処理を自動生成させられる
• アクセストークンの期限切れを気にせず、スクリプトが自動で更新してくれる

広告APIの認証・トークン更新の全体像

広告APIの認証とは何か

広告APIの認証とは、広告アカウントのデータにアクセスする権限を、アプリケーションに対して与える仕組みのことです。多くの広告プラットフォームは、OAuth2（OAuth 2.0）という標準的なプロトコルを採用しています。

OAuth2では、ユーザーが一度ログインして許可を与えると、API側から以下2種類のトークンが払い出されます。

• アクセストークン（access_token）：実際のAPIリクエストに付与する短命のトークン（有効期限あり）。
• リフレッシュトークン（refresh_token）：アクセストークンが期限切れになったとき、新しいアクセストークンを取得するためのトークン（長期間有効）。

トークン更新とは何か

トークン更新とは、有効期限が切れたアクセストークンを、リフレッシュトークンを使って新しいアクセストークンに交換する処理のことです。多くの広告APIでは、アクセストークンの有効期限は30分〜1時間程度と短いため、自動更新の仕組みを組み込んでおかないと、スクリプトが頻繁にエラーを返すようになります。

典型的な流れは以下の通りです。

• APIリクエスト時に、HTTPステータス401（Unauthorized）や特定のエラーコードを検知
• リフレッシュトークンとクライアントID／クライアントシークレットを使って、トークンエンドポイントにリクエスト
• 新しいアクセストークン（場合によってはリフレッシュトークンも）を受け取り、保存
• 再度APIリクエストをリトライ

Codexで自動化するメリット

Codexとは、自然言語からソースコードを自動生成するAIモデルであり、GitHub Copilotの根幹技術の一つです。Codexを使うことで、次のようなメリットが得られます。

• 複雑なOAuth2フローを、ドキュメントを読みながら手書きする必要がなくなる
• トークン更新ロジックや例外処理を、ひな形ベースで素早く作れる
• Python、Node.jsなど、複数言語への対応が容易
• 広告APIごとの微妙な仕様差（ヘッダー名、エンドポイントURLなど）も、サンプルコードから推論して補完してくれる

環境構築：Codexと広告APIを扱う準備

1. 開発言語とランタイム環境の選定

まずは、どの言語でスクリプトを組むかを決めます。動画では主にPythonベースの例で解説されているケースが多いため、ここでもPythonを前提に説明しますが、Node.jsでも同じ考え方で進められます。

おすすめの環境構成は以下の通りです。

• 言語：Python 3.9以上
• パッケージ管理：pip / Poetry / pipenv のいずれか
• 実行環境：ローカルPC、もしくはクラウド（Cloud Run、Lambda、Functionsなど）

2. 必要なライブラリ・SDKのインストール

広告APIごとに公式・非公式のクライアントライブラリが用意されている場合があります。代表的な構成は以下の通りです。

• HTTPクライアント：requests（Python）／axios（Node.js）
• OAuth2クライアント：oauthlib・requests-oauthlib など
• プラットフォーム公式SDK：Google Ads API、Yahoo!広告APIなど

Python例：

pip install requests requests-oauthlib python-dotenv

3. Codexを利用できる環境を用意

Codexは、通常は以下のどちらかの形で利用します。

• GitHub Copilot として、VS Code などのエディタ上で利用
• OpenAI API 経由で、gpt-3.5-turbo や後継モデルをコード生成用途で利用

ここでは、エディタ上でGitHub Copilot（Codex）を利用しながら開発する想定で話を進めます。

広告APIの認証フローを整理する

OAuth2の基本的な流れ

広告APIのOAuth2認証は、概ね次のステップで進みます。

1. 開発者コンソールで「アプリケーション」を登録し、クライアントIDとクライアントシークレットを取得
2. リダイレクトURIを設定（例：http://localhost:8080/callback）
3. 認可URLにブラウザからアクセスし、ユーザーがログイン＆同意
4. リダイレクトURIに認可コードが付与されて戻ってくる
5. 認可コードを使って、トークンエンドポイントにPOSTし、アクセストークンとリフレッシュトークンを取得
6. 以降のAPIリクエストでは、アクセストークンを Authorization: Bearer <token> ヘッダーに付与

必要な設定情報（クレデンシャル）の整理

自動化を設計する前に、最低限以下の情報を変数・環境変数として整理しておきます。

• CLIENT_ID：広告プラットフォームから払い出されるクライアントID
• CLIENT_SECRET：同じくクライアントシークレット
• REFRESH_TOKEN：初回認証時に取得したリフレッシュトークン
• TOKEN_ENDPOINT：トークンエンドポイントのURL
• API_BASE_URL：広告APIのベースURL

Codexに書かせる：認証・トークン更新処理の実装パターン

Codexへのプロンプト設計のポイント

Codexに任せるとき、プロンプト設計がとても重要です。広告APIの認証処理を自動生成させるときの基本構造は次のようになります。

• 何をしたいのかを1文で明確に書く
• 前提条件（言語、使用ライブラリ、環境変数名など）を箇条書きで渡す
• 欲しい関数のインターフェイス（引数・戻り値）を簡単に指定する
• エラー処理やリトライ戦略があれば、それも指定する

例：Pythonでリフレッシュトークンからアクセストークンを取得するコードを生成させたい場合のプロンプト例は以下の通りです。

"""
Pythonで、広告APIのリフレッシュトークンからアクセストークンを取得する関数を書いてください。
前提条件：
- HTTPクライアントにはrequestsライブラリを使う
- 環境変数から CLIENT_ID, CLIENT_SECRET, REFRESH_TOKEN, TOKEN_ENDPOINT を取得する
- 成功時はaccess_token文字列を返す
- 失敗時は例外を投げる
"""

トークン取得用関数のひな形（Python例）

上記プロンプトをもとにCodexが生成する典型的なコードは、概ね以下のような形になります。

import os
import requests

def get_access_token_from_refresh_token() -> str:
    token_endpoint = os.environ["TOKEN_ENDPOINT"]
    client_id = os.environ["CLIENT_ID"]
    client_secret = os.environ["CLIENT_SECRET"]
    refresh_token = os.environ["REFRESH_TOKEN"]

    data = {
        "grant_type": "refresh_token",
        "client_id": client_id,
        "client_secret": client_secret,
        "refresh_token": refresh_token,
    }

    response = requests.post(token_endpoint, data=data)
    response.raise_for_status()

    token_json = response.json()
    access_token = token_json["access_token"]

    # 必要なら新しいrefresh_tokenが返ってきた場合に保存
    if "refresh_token" in token_json:
        # ファイルやDBに保存する処理を書く
        pass

    return access_token

このようなひな形をCodexに書かせた上で、自分のプロジェクトに合わせた細かい部分（ログ出力、保存先、型ヒントなど）を調整すると効率的です。

APIリクエスト時の自動リフレッシュ処理

次に、APIリクエスト中に401エラーが出たら自動でトークンを更新してリトライするパターンです。Codexには次のようなプロンプトを投げます。

"""
Pythonで、広告APIにGETリクエストを送るヘルパー関数を書いてください。
仕様：
- アクセストークンは get_access_token_from_refresh_token() で取得する
- 最初のリクエストで401が返ってきた場合、もう一度アクセストークンを取得し直し、1回だけリトライする
- それでも失敗した場合は例外を投げる
- 引数は endpoint_path (str) と params (dict) を取り、JSONレスポンスを返す
"""

生成されるコード例：

import os
import requests

API_BASE_URL = os.environ["API_BASE_URL"]


def api_get(endpoint_path: str, params: dict | None = None) -> dict:
    if params is None:
        params = {}

    access_token = get_access_token_from_refresh_token()

    headers = {
        "Authorization": f"Bearer {access_token}",
        "Content-Type": "application/json",
    }

    url = f"{API_BASE_URL}{endpoint_path}"

    response = requests.get(url, headers=headers, params=params)

    if response.status_code == 401:
        # アクセストークンを更新して1回だけリトライ
        access_token = get_access_token_from_refresh_token()
        headers["Authorization"] = f"Bearer {access_token}"
        response = requests.get(url, headers=headers, params=params)

    response.raise_for_status()
    return response.json()

このパターンを土台として、POSTリクエストやバルク処理などにも展開していくことで、「トークン管理を意識せずにAPI操作ができる」状態を作れます。

トークン情報の安全な管理方法

なぜトークンの管理が重要か

アクセストークンやリフレッシュトークンは、実質的にアカウントへの鍵です。漏洩すると広告アカウントを不正操作されるリスクがあるため、以下の点を必ず押さえましょう。

• ソースコードに直接ベタ書きしない（Gitにコミットしない）
• 環境変数やシークレットマネージャーを利用する
• ログ出力時にトークン値を表示しない・マスクする

.envファイルと環境変数の利用（開発環境）

ローカル開発では、python-dotenvのようなライブラリを使って、.envファイルから環境変数を読み込むパターンがシンプルです。

# .env
CLIENT_ID=xxxx
CLIENT_SECRET=yyyy
REFRESH_TOKEN=zzzz
TOKEN_ENDPOINT=https://example.com/oauth2/token
API_BASE_URL=https://api.example.com/v1

from dotenv import load_dotenv
import os

load_dotenv()

# 以降 os.environ["CLIENT_ID"] などで参照可能

本番環境ではクラウドのシークレット機能を利用

本番環境では、次のようなマネージドサービスを利用すると安全です。

• AWS Systems Manager Parameter Store / Secrets Manager
• Google Secret Manager
• Azure Key Vault

Codexに対しても、これらのサービスから値を取得するコードのサンプルを生成させることで、「シークレット取得＋トークン更新」の一連の流れを自動化できます。

スケジューリングと運用設計

バッチ実行のパターン

広告APIの利用シーンとして多いのが、日次・時間単位でレポートを取得して集計するバッチ処理です。この場合、以下のような運用設計が考えられます。

• 毎日深夜3時に「前日分のインプレッション・クリック・コンバージョン」を取得してデータベースに保存
• 1時間ごとに「予算消化状況」をチェックし、しきい値を超えたら通知

これらのバッチ処理から広告APIのヘルパー関数（api_getなど）を呼び出せば、トークンの存在をほとんど意識せずにAPI連携を運用できます。

スケジューラ選定の例

Codexを活かすための実践的なコツ

1. まずは「手書き＋Codex補完」で骨格を作る

完全にCodex任せにするのではなく、最低限の関数名・コメント・Docstringを自分で書いた上で、途中からCodexに続きを書かせると、精度の高いコードが出やすくなります。

例：

def fetch_campaign_report(start_date: str, end_date: str) -> list[dict]:
    """指定期間のキャンペーン別レポートを広告APIから取得する。

    - 期間はYYYY-MM-DD形式の文字列
    - ページネーションがある場合はすべてのページを取得
    """
    # ここまで書いてからCodexに続きを補完させる

2. 実際のエラーをそのままプロンプトに貼る

広告APIのエラーはプラットフォームごとにメッセージやコードが異なるため、出てきたエラーメッセージをそのままプロンプトに貼り付けて、原因と修正案を聞くと効率的です。

例：

"""
以下のPythonコードで広告APIを呼び出したところ、次のエラーが発生しました。

コード：
<ここに自分のコード>

エラーメッセージ：
<ここにエラーログ>

原因と修正済みのコード例を教えてください。
"""

3. 認証まわりの「一度きりの手動作業」を切り出す

OAuth2フローのうち、ユーザーがブラウザでログインして同意するステップだけは、どうしても手動が必要です。このステップを「初回セットアップスクリプト」として切り出し、Codexにコード生成を任せてしまうと、2回目以降は完全自動で回せます。

例えば、次のようなスクリプトをCodexに書かせます。

• 認可URLを生成して表示する
• ユーザーがそのURLにアクセスして同意後、表示された認可コードをコピー＆ペースト
• 認可コードをトークンエンドポイントに送り、リフレッシュトークンを取得して保存

まとめ：Codexで広告API連携の「めんどうな部分」を自動化する

広告APIの認証・トークン更新処理は、どのプラットフォームでも概ね同じパターンでありながら、実装には細かい決まりや例外が多く、手作業で実装するには時間もかかります。

この記事で解説したように、

• OAuth2の基本構造（アクセストークンとリフレッシュトークン）の理解
• Codexに渡すプロンプト設計のコツ
• トークンの安全な管理方法
• バッチ・スケジューリングとの組み合わせ方

を押さえておけば、Codexを使って広告APIの認証・トークン更新をほぼ全自動の仕組みとして構築できます。これにより、日々のレポート取得や自動最適化ロジックの実装に、より多くの時間を割けるようになるはずです。

もし実際に手元で試す場合は、この記事のステップに沿って、まずは「小さなスクリプト」で一連の流れ（認証 → トークン取得 → 単一エンドポイントへのリクエスト）を成功させ、その後で徐々に対象エンドポイントや処理内容を広げていくと、つまずきにくくなります。

よくある質問（FAQ）

Q1. Codexだけに任せて広告APIの認証処理を作っても安全ですか？

A1. Codexはコード生成を支援するツールであり、最終的な責任は開発者にあります。生成されたコードをそのまま本番環境に使うのではなく、以下を必ず確認してください。

• クレデンシャルが平文でハードコードされていないか
• 例外処理やリトライの実装が自分の要件に合っているか
• 公式ドキュメントとの整合性が取れているか

Q2. リフレッシュトークンはどれくらいの頻度で更新すべきですか？

A2. プラットフォームによります。明確な有効期限が決まっている場合は、その期限前に更新するようスケジュールするか、定期的にトークン再発行フローを回す仕組みを用意します。一方で、ユーザーが権限を取り消さない限り有効という仕様のAPIもあるため、必ず各プラットフォームのドキュメントを確認してください。

Q3. 複数の広告プラットフォームのトークンをまとめて管理したいです。

A3. 共通の「トークンストア」テーブルやファイルを用意し、platform（例：google, yahoo, facebook など）のカラム／キーを持たせて紐付ける方法が一般的です。Codexに対して「複数プラットフォームのトークンを読み書きするリポジトリクラス」の実装を依頼し、そこから個別のAPIクライアントが参照するように設計すると管理しやすくなります。

Q4. 開発環境と本番環境でクライアントIDなどを切り替えるには？

A4. 環境変数に ENVIRONMENT=dev|prod のような値を持たせ、.env.dev と .env.prod を使い分ける方法がシンプルです。Codexには「ENVIRONMENTの値に応じて読み込む設定ファイルを変えるコード」を書かせることで、切り替え処理を自動生成できます。

Q5. Cronでバッチを回しているときにアクセストークンが失効したらどうなりますか？

A5. この記事で紹介したように、APIリクエスト関数の内部で401エラーを検知して自動的にリフレッシュトークンからアクセストークンを再取得するロジックを実装しておけば、バッチ処理はそのまま継続します。重要なのは、「バッチ側ではなくAPIクライアント側でトークン管理をカプセル化する」ことです。

さらに詳しい実装例や画面操作を含む解説は、こちらの動画でも確認できます：
https://youtu.be/MDKJA5lqELo?si=bX5t8NNeb_ErYWPN