株式会社renue
AI導入・DXの悩みをプロに相談してみませんか？
AIやDXに関する悩みがありましたら、お気軽にrenueの無料相談をご利用ください。 renueのAI支援実績、コンサルティングの方針や進め方をご紹介します。
Claude CodeなどのAIエージェントに広告運用を任せる構想は、2026年に入って急速に現実味を帯びています。一方で、現場の最大の懸念は「Google Ads・Meta Ads・TikTok・X Adsなどの広告アカウント認証情報を、AIエージェントに安全に渡せるのか？」という点です。リフレッシュトークン・デベロッパートークン・OAuthアクセストークン・MCC配下の顧客IDといった機密情報がAIに流出すれば、広告アカウントの乗っ取り・予算不正消費・配信経路改ざんといった深刻な被害につながります。本記事では、「Claude Codeに広告運用を任せながら、トークン/APIキーを一切エージェントに見せない」アーキテクチャパターンを、実装現場の知見をもとに解説します。
なぜ広告運用AIではトークン保護が決定的に重要なのか
広告運用領域でクレデンシャルが流出すると、被害は次の3段階で広がります。
- 金銭被害：広告アカウントへの不正アクセスで予算が不当に消費される
- ブランド毀損：競合や悪意ある第三者によって配信内容が改ざんされる
- 連鎖被害：MCC（Manager Account）経由で複数のクライアントアカウントが同時に侵害される
特に代理店業務や複数アカウント運用では、1件のトークン流出が10〜100アカウント規模の被害につながる可能性があります。広告運用AIを設計する上で、トークン保護は「AI機能の機能性」と同じレベルの一級論点として扱う必要があります。
安全な広告運用AIの基本原則：「AIにトークンを見せない」
原則は単純です。Claude Codeなどの汎用AIエージェントには、トークン・APIキー・リフレッシュトークン・デベロッパートークンを一切渡しません。代わりに、エージェントは「業務指示」を発し、その指示を受け取った専用バックエンドが認証情報を持ったままAPIを叩く構成にします。
具体的には、次の3層構成が現代の標準的なアーキテクチャです。
第1層：Claude Code（指示者）
AIエージェントは「広告運用の意思決定者」として動きます。具体的な認証情報には一切触れず、業務指示（例：「キャンペーンXのCPCを下げる」「除外キーワードを追加する」）を専用CLI経由で発行するだけです。
第2層：CLI/Wrapper（プロキシ層）
AIエージェントとバックエンドの間に薄いCLI（コマンドラインインターフェース）またはWrapper層を置きます。この層はトークンを保持しません。受け取った業務指示を、認証情報なしの構造化リクエストとしてバックエンドに転送します。
第3層：FastAPI（バックエンド）
バックエンドサーバーが、データベースに暗号化保存されたクレデンシャルを取り出し、Google Ads / Meta Ads / TikTok / X Ads などのAPIを呼び出します。
この3層構成により、Claude Code側にはどのような形でも認証情報が渡らない構造が成立します。エージェントが何らかの形で侵害されても、トークンそのものは漏れません。
renueが採用しているアーキテクチャの主要設計
私たちrenueは、Google Ads / Meta Ads / TikTok / X Ads など複数の広告プラットフォームに対して、Claude Codeから安全に運用指示を出せるアーキテクチャを実装してきました。主要な設計原則は次の通りです。
1. クレデンシャルはDB管理、.envに置かない
広告プラットフォームの認証情報（リフレッシュトークン・デベロッパートークン・顧客ID・アカウントID）は、すべてバックエンドのデータベースに暗号化して保存します。`.env`ファイル、ソースコード、設定ファイルへの直書きは禁止します。これにより、リポジトリ流出やCIログ流出からトークンを守れます。
2. マルチテナント分離
複数の組織・プロジェクトを扱う場合、認証情報はテナント単位で完全に分離します。テナントとアカウントの識別子を組み合わせてバックエンドが認証情報を取り出す設計にすることで、テナント間の認証情報の漏れを構造的に防げます。
3. CLIに「インラインクレデンシャル禁止」を組み込む
CLI/Wrapper層では、コマンドライン引数や環境変数からのインライントークン受け取りを明示的にブロックします。テナントとアカウントの識別子だけを渡してバックエンド経由で認証する仕様にし、トークンを直接渡そうとするとエラーで止まる実装にします。
4. アクセストークンの自動更新
OAuthアクセストークンの期限切れは、運用上の最大の障害の一つです。バックエンド側でリフレッシュトークンを使った自動更新ロジックを実装し、CLI/Wrapper層やAIエージェントには更新を意識させない構成にします。
5. 監査ログとレート制御
誰が・いつ・どのアカウントに・どんな操作を行ったかを、すべてバックエンドに監査ログとして残します。同時に、レート制御（短時間に大量の操作を行う異常パターンの検知）をバックエンド層で実装し、AIエージェントが暴走しても被害を最小化します。
Claude Codeに広告運用を任せる際の運用フロー
上記のアーキテクチャを前提にすると、Claude Codeでの広告運用は次のようなフローになります。
- 運用担当者がClaude Codeに「先週のCPCが想定より高いので、Google Adsキャンペーン群を確認して改善案を提示せよ」と指示する
- Claude Codeは専用CLI経由でメトリクス取得コマンドを発行する
- CLIがテナントとアカウントの識別子を付けてバックエンドにリクエスト
- バックエンドがDB上のクレデンシャルを使ってGoogle Ads APIを叩き、結果を返す
- Claude Codeが結果を解釈し、改善案（除外キーワード追加・入札調整・除外配信面追加等）を提示
- 運用担当者が承認した変更だけを、再びCLI経由で発行する
この流れの全工程で、Claude Codeが扱うのは「業務指示」と「集計結果」だけであり、認証情報そのものは一切流れません。
このアーキテクチャがもたらす5つのメリット
- セキュリティ：エージェント経由でのトークン流出リスクを大きく低減できる
- 運用効率：トークン更新・期限切れ対応が自動化される
- マルチテナント対応：1つのバックエンドで複数組織の広告運用を扱える
- 監査対応：すべての操作がログ化され、内部統制・コンプライアンス対応が容易
- AIエージェント切替の容易さ：Claude Code以外のエージェント（GPT-5等）に切り替えても、認証層は変えなくて済む
避けるべき3つのアンチパターン
- アンチパターン1：AIエージェントに直接トークンを渡す。最も多い失敗。エージェントの履歴・ログ・メモリ・プロンプト経由でトークンが流出する危険性が高い。
- アンチパターン2：.envファイルや設定ファイルにトークンを置く。Gitリポジトリ流出・CIログ流出・設定ファイル誤共有の経路で漏れる。
- アンチパターン3：MCCのトップレベル権限を渡す。被害範囲がMCC配下の全アカウントに及ぶ。最小権限の原則で、必要なアカウントだけにアクセスを限定する。
