株式会社renue
AI導入・DXの悩みをプロに相談してみませんか？
AIやDXに関する悩みがありましたら、お気軽にrenueの無料相談をご利用ください。 renueのAI支援実績、コンサルティングの方針や進め方をご紹介します。
広告運用AIエージェントを「動くデモ」ではなく「本番で運用できる品質」で実装するには、カスタムツール設計、SQLホワイトリスト、マルチテナント分離、認証情報の安全な管理、Rate Limitといった複数のレイヤーが必要となる。本記事では、広告運用AIエージェントの一般的な設計パターンをもとに、本格実装で必要な考慮事項を解説する。単なる「Claude APIを叩くチャットボット」ではなく、エンタープライズ品質の広告運用エージェントを作るためのガイドである。
本番品質の広告運用AIエージェントに必要な8レイヤー
| レイヤー | 役割 | 主要技術 |
|---|---|---|
| 1. カスタムツール定義 | エージェントが呼べる業務操作を定義 | Anthropic Tool Schema |
| 2. System Prompt設計（選択肢応答を含む） | エージェントの行動指針と出力形式、曖昧指示を聞き返す仕組み | プロンプトテンプレート、choices JSON block |
| 3. SQLホワイトリスト | エージェントのDB操作を安全に制限 | クエリパーサー + 許可テーブルリスト |
| 4. マルチテナント分離 | 組織/プロジェクト単位のリソース保護 | 組織所有検証関数 / 組織IDスコープ |
| 5. 認証情報DB管理 | 広告プラットフォーム認証の安全な保存 | 共通鍵暗号による暗号化 |
| 6. Rate Limit | AI生成・チャット呼び出しの保護 | ユーザー/IP単位の制限 |
| 7. 監査ログ | 広告配信変更の追跡 | 監査ログテーブル |
| 8. 広告プラットフォームAPIの抽象化 | 媒体ごとのAPIを共通の操作にまとめる | 媒体別クライアントと共通インターフェース |
レイヤー1: カスタムツール定義 — エージェントの業務を定義する
広告運用AIエージェントが「何ができるか」は、Anthropic Tool Schemaで定義するカスタムツールで決まる。一般的な実装では以下のカテゴリのツールを提供している。
データ取得ツール
- 広告メトリクス取得ツール: 広告メトリクス(imp/click/cost/conv/CTR/CVR/CPA/ROAS)を取得。日次/サマリー切替、期間・媒体・キャンペーンで絞り込み
- KPIダッシュボード取得ツール: KPIダッシュボードの全体サマリー、予算消化率、チャネル別パフォーマンス、仮説一覧
- 専用ツール: キャンペーン一覧取得。ステータス/媒体/プロダクトで絞り込み
- 専用ツール: 広告一覧取得
操作ツール
- 専用ツール: 広告ステータス変更(active/paused/removed)
- 専用ツール: キャンペーンステータス変更
- 画像生成ツール: AIによる画像生成・入れ替え
分析・検索ツール
- SQL実行ツール: ホワイトリスト内のテーブルに対するSELECT限定のSQL実行(後述)
Tool Schemaの定義
スキーマで引数の型や必須項目を定義する。Anthropicの対応機能でstrict: trueを指定すると、対応するスキーマへの適合が保証される。ただし、値の業務上の妥当性や操作権限は実行側で別途検証する（Strict tool useの仕様）。
レイヤー2: System Promptによる行動指針の明示
本番品質のエージェントは「何ができるか」だけでなく「どう振る舞うか」を明示する必要がある。
行動指針の例
- 金額は日本円で3桁区切り(例: ¥1,234,567)
- 指標はパーセント表記(例: CTR 3.5%、CVR 1.2%)
- レポートは「概要→チャネル別詳細→改善ポイント」の構成
- 広告のステータス変更など重要な操作の前は、必ず対象を確認
- 上限金額は参照のみで変更不可
曖昧指示への対応
「成果を教えて」「広告を止めて」のような曖昧な指示には、勝手に推測で実行せず、必ず選択肢を提示して聞き返す仕組みが重要である。
AIが自分で選択肢を提示することで、ユーザーは曖昧な指示から安全に具体的な操作へ進める。選択肢の文言はそのままユーザー入力として扱えるよう設計する。
レイヤー3: SQLホワイトリスト — 汎用SQL実行ツールを安全に提供する
エージェントに自由にSQLを書かせると強力だが、重大なセキュリティリスクがある。一般的な実装では以下の制限を設けている。
許可テーブル方式(ホワイトリスト)
実行可能なテーブルを明示的にリスト化し、それ以外へのクエリは拒否する。
- 組織IDスコープ: 業務系テーブル群（実名は割愛）等
- プロジェクトIDスコープ: 業務系テーブル群（実名は割愛）等
- 間接テーブル(親とのJOIN必須): 親テーブルとのJOINを必須とするテーブル群（実名は割愛）
アクセス禁止テーブル
認証・組織管理系のテーブル群には一切アクセスさせない。認証情報の漏洩を防ぐ絶対的なガード。
SELECT以外の禁止
INSERT/UPDATE/DELETE/DROPは全て拒否する。データ変更が必要な場合は、専用のツール(専用ツール等)を経由させる。専用ツールには監査ログの記録処理を実装し、記録の失敗も検知する。SELECT限定や専用ツールへの振り分けだけでは、ログの保存は保証されない（OWASPのログ実装指針）。
レイヤー4: マルチテナント分離 — 組織間のデータを絶対に混ぜない
広告運用AIエージェントを複数の組織で利用するSaaSにする場合、テナント分離が最重要である。1件でもデータ漏洩があればプロダクトの信頼が失墜する。
一般的な実装パターン
- プロジェクト所有検証関数: 組織IDは必須引数、省略不可
- 組織所有検証関数: orgスコープリソースの検証
- ファイル所有検証関数: S3ファイルの組織識別子絞り込み
- 組織コンテキスト検証: 全APIルートで組織IDとプロジェクトIDを取得
- 外部キー検証: リクエストボディの 外部キーは所有権検証してからINSERT
重要な設計原則
- テナント分離コードは一度実装したら変更・再実装しない(セキュリティ監査の対象)
- 組織識別子絞り込みをアプリケーション層で徹底する(DBレベルでRow Level Securityを使わない場合は特に重要)
- 全てのクエリに組織識別子の絞り込みが入っているかを定期的に監査する
レイヤー5: 広告プラットフォーム認証情報のDB管理
Google Ads、Meta、TikTok、X Ads等の認証情報(APIキー、リフレッシュトークン、シークレット)をどこに保存するかは重大な設計判断である。
やってはいけないこと
- `.env`ファイルに直書き(複数組織で共有される場合は致命的)
- コードから`process.env`で直接参照(レガシー変数が残っている場合でも参照禁止)
- 平文でDBに保存
推奨パターン(一般的な実装)
- 専用の認証情報テーブルで組織・プロジェクト単位に管理
- トークンは暗号化してDBに保存
- 自社利用分の認証情報も例外なくDB管理(自社運用と顧客運用を同じ仕組みで扱う)
- 認証情報取得時は組織ID＋プロジェクトIDで絞り込み
レイヤー6: Rate Limit — AI生成の暴走とコスト爆発を防ぐ
AI生成機能は1回の呼び出しが高コストになるため、Rate Limitが必須である。一般的な実装では以下の4カテゴリに制限をかけている。
- 対話API: チャット対話
- 画像生成API: 画像生成
- 動画生成API: 動画生成(Sora等)
- 2要素認証API: 2FA認証(ブルートフォース対策)
Rate Limitはユーザー単位/IP単位/組織単位で多層的に設計する。特に動画生成はコストが高いため厳しめに設定する。
レイヤー7: 監査ログ — 広告配信変更の完全な追跡
AIエージェントが広告のステータス変更、予算変更、クリエイティブ入れ替えを行う場合、すべてのアクションを監査ログに記録する必要がある。
必須の記録項目
- 実行者(user_id)
- 実行時刻
- 対象リソース(業務系テーブル群（実名は割愛）等)
- 変更前後の状態
- AI経由か手動かの区別
- AI判断の根拠(どのプロンプト・ツール呼び出しの結果か)
一般的な実装では監査ログで重要な変更を記録しており、トラブル発生時に原因を特定できる体制を作っている。
レイヤー8: 広告プラットフォームAPIの抽象化
Google Ads、Meta Ads、TikTok Ads、X AdsはそれぞれAPIが異なるため、統一インターフェースで抽象化する必要がある。
一般的な抽象化レイヤー
媒体別のクライアント実装と共通インターフェースを分離したモジュール構成としている。これにより、エージェント側は「どの媒体か」を気にせず、統一的なメソッドで操作できる。
サニタイズ処理による入力検証
AIエージェントが生成したパラメータを各プラットフォームに渡す前に、必ずsanitizeする。不正な値(例: 負の予算、無効なステータス)を事前に弾くことで、API呼び出しエラーを防ぐ。
Next.js + API Routes構成の推奨
一般的な実装ではNext.js App RouterのAPI Routesでバックエンドを実装している。主な理由は以下の通り。
- フロントエンドと同じTypeScriptで統一できる
- 認証ミドルウェアをフロント・APIで共有できる
- SWR/SWR Mutationとの相性が良い
- UIライブラリとの統合が容易
DBアクセスとファイルアップロードは、それぞれ共通モジュール経由に統一している。
開発時の認証ルール
3段階の認可チェック
- 第1段階（認証）: ログイン必須
- 組織コンテキスト検証: 組織所属が必須(組織識別子とプロジェクト識別子を取得)
- 第3段階（管理者権限）: 管理者のみ
2FA(TOTP)の本番必須化
本番環境では2FA必須とする。認証情報へのアクセス、管理操作、APIキー管理など、セキュリティクリティカルな操作は必ず2FAで保護する。
CSRF対策
Origin/RefererチェックはCSRF対策の一部である。Next.jsのServer ActionsにはPOST限定とOrigin/Hostの照合があるが、この記事のAPI Routes全体に同じ保護が自動適用されるとは限らない。認証方式とエンドポイントに応じて、CSRFトークンやSameSite Cookie等の対策を設計する。X-Frame-Options等のセキュリティヘッダーも用途に応じて明示的に設定する（Next.jsの対象機能、OWASPのCSRF対策）。
広告AIエージェント導入の一般的なアプローチ
renueは「Self-DX First」の方針のもと、広告代理AIエージェントを自社プロダクトとして開発・運用している。社内の主要業務(採用・経理・PMO・評価など)を自社開発のAIツールで自動化済み(2026年1月時点)であり、広告代理AIエージェントはその中でも最も機能が豊富なプロダクトの一つである(全て公開情報)。
公開されている特徴
- 6媒体統合(Google・Meta・X・TikTok・LINE・YouTube)
- マージン1〜2%(従来型代理店の最大90%以上削減)
- クリエイティブ管理機能内蔵(生成→QA→配信→実績取り込みまで一気通貫)
- マルチテナントSaaS設計(複数組織で安全に利用可能)
- Anthropic Claude APIをメインLLMとして利用
導入時のよくある失敗パターン
- ツールを定義せずに汎用チャットで対応しようとする: エージェントが推測で動き、誤操作のリスクが高い
- SQLを無制限に書かせる: 認証情報や他テナントのデータが漏洩する
- マルチテナント分離を後回しにする: 後から実装すると全API routeの書き直しが必要
- 認証情報を.envに残す: 複数組織での運用ができない
- Rate Limitを設定しない: AI生成コストが爆発する
- 監査ログを記録しない: トラブル時に原因追跡できない
- 曖昧な指示をそのまま実行する: 意図しない操作が発生する
あわせて読みたい
サービス・採用に関する公開情報は、renue公式サイトをご確認ください。
