Claude Codeに広告運用を任せる安全アーキテクチャ2026｜トークン保護とCLIプロキシ3層構成

Claude CodeなどのAIエージェントに広告運用を任せる構想は、2026年に入って急速に現実味を帯びています。一方で、現場の最大の懸念は「Google Ads・Meta Ads・TikTok・X Adsなどの広告アカウント認証情報を、AIエージェントに安全に渡せるのか？」という点です。リフレッシュトークン・デベロッパートークン・OAuthアクセストークン・MCC配下の顧客IDといった機密情報がAIに流出すれば、広告アカウントの乗っ取り・予算不正消費・配信経路改ざんといった深刻な被害につながります。本記事では、「Claude Codeに広告運用を任せながら、トークン/APIキーを一切エージェントに見せない」アーキテクチャパターンを、実装現場の知見をもとに解説します。

なぜ広告運用AIではトークン保護が決定的に重要なのか

広告運用領域でクレデンシャルが流出すると、被害は次の3段階で広がります。

1. 金銭被害：広告アカウントへの不正アクセスで予算が不当に消費される
2. ブランド毀損：競合や悪意ある第三者によって配信内容が改ざんされる
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. マルチテナント分離

複数の組織・プロジェクトを扱う場合、認証情報はテナント単位で完全に分離します。`project_id`と`account_id`を組み合わせてバックエンドが認証情報を取り出す設計にすることで、テナント間の認証情報の漏れを構造的に防げます。

3. CLIに「インラインクレデンシャル禁止」を組み込む

CLI/Wrapper層では、コマンドライン引数や環境変数からのインライントークン受け取りを明示的にブロックします。`project_id`と`account_id`だけを渡してバックエンド経由で認証する仕様にし、トークンを直接渡そうとするとエラーで止まる実装にします。

4. アクセストークンの自動更新

OAuthアクセストークンの期限切れは、運用上の最大の障害の一つです。バックエンド側でリフレッシュトークンを使った自動更新ロジックを実装し、CLI/Wrapper層やAIエージェントには更新を意識させない構成にします。

5. 監査ログとレート制御

誰が・いつ・どのアカウントに・どんな操作を行ったかを、すべてバックエンドに監査ログとして残します。同時に、レート制御（短時間に大量の操作を行う異常パターンの検知）をバックエンド層で実装し、AIエージェントが暴走しても被害を最小化します。

Claude Codeに広告運用を任せる際の運用フロー

上記のアーキテクチャを前提にすると、Claude Codeでの広告運用は次のようなフローになります。

1. 運用担当者がClaude Codeに「先週のCPCが想定より高いので、Google Adsキャンペーン群を確認して改善案を提示せよ」と指示する
2. Claude Codeは専用CLI経由でメトリクス取得コマンドを発行（例：`renue ads-google metrics`）
3. CLIが`project_id`/`account_id`を付けてバックエンドにリクエスト
4. バックエンドがDB上のクレデンシャルを使ってGoogle Ads APIを叩き、結果を返す
5. Claude Codeが結果を解釈し、改善案（除外キーワード追加・入札調整・除外配信面追加等）を提示
6. 運用担当者が承認した変更だけを、再びCLI経由で発行する

この流れの全工程で、Claude Codeが扱うのは「業務指示」と「集計結果」だけであり、認証情報そのものは一切流れません。

このアーキテクチャがもたらす5つのメリット

• セキュリティ：トークン流出のリスクが構造的に消える
• 運用効率：トークン更新・期限切れ対応が自動化される
• マルチテナント対応：1つのバックエンドで複数組織の広告運用を扱える
• 監査対応：すべての操作がログ化され、内部統制・コンプライアンス対応が容易
• AIエージェント切替の容易さ：Claude Code以外のエージェント（GPT-5等）に切り替えても、認証層は変えなくて済む

避けるべき3つのアンチパターン

1. アンチパターン1：AIエージェントに直接トークンを渡す。最も多い失敗。エージェントの履歴・ログ・メモリ・プロンプト経由でトークンが流出する危険性が高い。
2. アンチパターン2：.envファイルや設定ファイルにトークンを置く。Gitリポジトリ流出・CIログ流出・設定ファイル誤共有の経路で漏れる。
3. アンチパターン3：MCCのトップレベル権限を渡す。被害範囲がMCC配下の全アカウントに及ぶ。最小権限の原則で、必要なアカウントだけにアクセスを限定する。

FAQ

Q1. Claude Codeで広告運用を任せるのはそもそも安全ですか？

「AIエージェントに認証情報を見せない」アーキテクチャを前提にすれば、十分に安全に運用できます。逆に、トークンをそのままClaude Codeに渡す構成は2026年時点では推奨できません。AIの履歴・ログ・メモリから情報が漏れるリスクが構造的に存在するためです。

Q2. SaaS型のAI広告運用ツールでも同じ懸念がありますか？

あります。SaaS型ツールは内部でクレデンシャルを管理していますが、第三者にトークンを預ける形になるため、情報セキュリティポリシー上の確認が必要です。最小権限の付与・監査ログの可視性・データ取り扱いポリシーの3点は、必ず契約前に確認してください。

Q3. 小規模な事業者でもこのアーキテクチャは必要ですか？

「自社の広告予算が月数十万円以上」「複数アカウントを運用している」「AIエージェントに広告操作を任せたい」のいずれかに該当する場合は必要です。逆に、Google Ads UIを手動で運用している小規模事業者には過剰投資です。

Q4. このアーキテクチャは内製で構築できますか？

技術的には可能ですが、OAuth更新ロジック・マルチテナント分離・監査ログ・レート制御・暗号化などをすべて自前で実装するのは相応の工数がかかります。renueでは、こうしたバックエンドアーキテクチャを実装済みで、CLI経由でClaude Codeに広告運用を任せられる構成を提供しています。

Q5. AIエージェント側での「トークン保持禁止」を強制する仕組みはありますか？

CLI/Wrapper層でインラインクレデンシャルの受け取りをブロックする実装が有効です。コマンドライン引数や環境変数経由のトークン渡しをエラーで停止させ、`project_id`/`account_id`経由でしか認証できない仕様にすることで、開発者・エージェントが誤ってトークンを渡そうとしても構造的に防げます。