広告運用AIエージェント実装ガイド【2026年版】— ツール設計・SQLホワイトリスト・マルチテナント分離の本番アーキテクチャ | 記事

広告運用AIエージェントを「動くデモ」ではなく「本番で運用できる品質」で実装するには、カスタムツール設計、SQLホワイトリスト、マルチテナント分離、認証情報の安全な管理、Rate Limitといった複数のレイヤーが必要となる。本記事では、renueが自社プロダクトとして実装している広告運用AIエージェントの設計パターンをもとに、本格実装で必要な考慮事項を解説する。単なる「Claude APIを叩くチャットボット」ではなく、エンタープライズ品質の広告運用エージェントを作るためのガイドである。

本番品質の広告運用AIエージェントに必要な8レイヤー

レイヤー	役割	主要技術
1. カスタムツール定義	エージェントが呼べる業務操作を定義	Anthropic Tool Schema
2. System Prompt設計	エージェントの行動指針と出力形式	プロンプトテンプレート
3. SQLホワイトリスト	エージェントのDB操作を安全に制限	クエリパーサー + 許可テーブルリスト
4. マルチテナント分離	組織/プロジェクト単位のリソース保護	verifyResourceOrg / org_idスコープ
5. 認証情報DB管理	広告プラットフォーム認証の安全な保存	AES-256-GCM暗号化
6. Rate Limit	AI生成・チャット呼び出しの保護	ユーザー/IP単位の制限
7. 選択肢応答	曖昧指示を聞き返す仕組み	choices JSON block
8. 監査ログ	広告配信変更の追跡	ad_submission_audit_log

レイヤー1: カスタムツール定義 — エージェントの業務を定義する

広告運用AIエージェントが「何ができるか」は、Anthropic Tool Schemaで定義するカスタムツールで決まる。renueの実装では以下のカテゴリのツールを提供している。

データ取得ツール

get_ad_metrics: 広告メトリクス(imp/click/cost/conv/CTR/CVR/CPA/ROAS)を取得。日次/サマリー切替、期間・媒体・キャンペーンで絞り込み
get_kpi_dashboard: KPIダッシュボードの全体サマリー、予算消化率、チャネル別パフォーマンス、仮説一覧
list_campaigns: キャンペーン一覧取得。ステータス/媒体/プロダクトで絞り込み
list_ads: 広告一覧取得

操作ツール

update_ad_status: 広告ステータス変更(active/paused/removed)
update_campaign_status: キャンペーンステータス変更
generate_creative_image: AIによる画像生成・入れ替え

分析・検索ツール

sql_query: ホワイトリスト内のテーブルに対するSELECT限定のSQL実行(後述)

Tool Schemaの例

{
  "name": "get_ad_metrics",
  "description": "広告メトリクス(imp/click/cost/conv/CTR/CVR/CPA/ROAS)を取得する",
  "input_schema": {
    "type": "object",
    "properties": {
      "campaign_id": { "type": "number" },
      "platform": {
        "type": "string",
        "enum": ["google", "meta", "tiktok", "x"]
      },
      "date_from": { "type": "string", "description": "YYYY-MM-DD" },
      "date_to": { "type": "string" },
      "granularity": {
        "type": "string",
        "enum": ["daily", "summary"]
      }
    }
  }
}

スキーマを厳密に定義することで、LLMが不正な引数でツールを呼び出すことを防げる。

レイヤー2: System Promptによる行動指針の明示

本番品質のエージェントは「何ができるか」だけでなく「どう振る舞うか」を明示する必要がある。

行動指針の例

金額は日本円で3桁区切り(例: ¥1,234,567)
指標はパーセント表記(例: CTR 3.5%、CVR 1.2%)
レポートは「概要→チャネル別詳細→改善ポイント」の構成
広告のステータス変更など重要な操作の前は、必ず対象を確認
上限金額(spending_limits)は参照のみで変更不可

曖昧指示への対応

「成果を教えて」「広告を止めて」のような曖昧な指示には、勝手に推測で実行せず、必ず選択肢を提示して聞き返す仕組みが重要である。

「どの期間の成果を確認しますか?」
```choices
["今日", "昨日", "今週", "今月", "直近7日間", "直近30日間"]
```

このようにAIが自分で選択肢を提示することで、ユーザーは曖昧な指示から安全に具体的な操作へ進める。選択肢の文言はそのままユーザー入力として扱えるよう設計する。

レイヤー3: SQLホワイトリスト — 汎用SQL実行ツールを安全に提供する

エージェントに自由にSQLを書かせると強力だが、重大なセキュリティリスクがある。renueの実装では以下の制限を設けている。

許可テーブル方式(ホワイトリスト)

実行可能なテーブルを明示的にリスト化し、それ以外へのクエリは拒否する。

org_idスコープ: ad_metrics_daily, ai_prompts, conversion_events, marketing_budgets, pdca_hypotheses, products 等
project_idスコープ: sales_campaigns, marketing_creatives, spending_limits, brand_assets, creative_generations 等
間接テーブル(親とのJOIN必須): product_personas→products, unified_ad_groups→sales_campaigns 等

アクセス禁止テーブル

認証系テーブル(users, organizations, org_members, sessions, accounts 等)には一切アクセスさせない。認証情報の漏洩を防ぐ絶対的なガード。

SELECT以外の禁止

INSERT/UPDATE/DELETE/DROPは全て拒否する。データ変更が必要な場合は、専用のツール(update_ad_status等)を経由させる。これにより監査ログが確実に残る。

レイヤー4: マルチテナント分離 — 組織間のデータを絶対に混ぜない

広告運用AIエージェントを複数の組織で利用するSaaSにする場合、テナント分離が最重要である。1件でもデータ漏洩があればプロダクトの信頼が失墜する。

renueの実装パターン

verifyResourceProject(table, id, projectIds, orgId): orgIdは必須引数、省略不可
verifyResourceOrg(table, id, orgId): orgスコープリソースの検証
verifyFileOwnership(key, orgId, projectIds): S3ファイルのorg_id絞り込み
requireOrg(): 全APIルートでorgIdとprojectIdsを取得
外部キー検証: リクエストボディの hypothesis_id, campaign_id 等は所有権検証してからINSERT

重要な設計原則

テナント分離コードは一度実装したら変更・再実装しない(セキュリティ監査の対象)
org_id絞り込みをアプリケーション層で徹底する(DBレベルでRow Level Securityを使わない場合は特に重要)
全てのクエリにorg_idの絞り込みが入っているかを定期的に監査する

レイヤー5: 広告プラットフォーム認証情報のDB管理

Google Ads、Meta、TikTok、X Ads等の認証情報(APIキー、リフレッシュトークン、シークレット)をどこに保存するかは重大な設計判断である。

やってはいけないこと

`.env`ファイルに直書き(複数組織で共有される場合は致命的)
コードから`process.env`で直接参照(レガシー変数が残っている場合でも参照禁止)
平文でDBに保存

推奨パターン(renueの実装)

`project_ad_platform_accounts`テーブルで組織・プロジェクト単位に管理
トークンはAES-256-GCMで暗号化してDBに保存
renue自身の認証情報も例外なくDB管理(自社運用と顧客運用を同じ仕組みで扱う)
認証情報取得時は`org_id + project_id`で絞り込み

レイヤー6: Rate Limit — AI生成の暴走とコスト爆発を防ぐ

AI生成機能は1回の呼び出しが高コストになるため、Rate Limitが必須である。renueの実装では以下の4カテゴリに制限をかけている。

agentChat: チャット対話
imageGeneration: 画像生成
videoGeneration: 動画生成(Sora等)
totpVerify: 2FA認証(ブルートフォース対策)

Rate Limitはユーザー単位/IP単位/組織単位で多層的に設計する。特に動画生成はコストが高いため厳しめに設定する。

レイヤー7: 監査ログ — 広告配信変更の完全な追跡

AIエージェントが広告のステータス変更、予算変更、クリエイティブ入れ替えを行う場合、すべてのアクションを監査ログに記録する必要がある。

必須の記録項目

実行者(user_id)
実行時刻
対象リソース(campaign_id, ad_id, creative_id等)
変更前後の状態
AI経由か手動かの区別
AI判断の根拠(どのプロンプト・ツール呼び出しの結果か)

renueの実装では`ad_submission_audit_log`テーブルで広告提出の監査ログを完全に記録しており、トラブル発生時に原因を特定できる体制を作っている。

レイヤー8: 広告プラットフォームAPIの抽象化

Google Ads、Meta Ads、TikTok Ads、X AdsはそれぞれAPIが異なるため、統一インターフェースで抽象化する必要がある。

renueの抽象化レイヤー

`lib/ad-platforms/`ディレクトリ配下に媒体別のクライアント(`google-ads.ts`, `meta-ads.ts`, `tiktok-ads.ts`, `x-ads.ts`)と、共通インターフェース(`index.ts`)を実装している。これにより、エージェント側は「どの媒体か」を気にせず、統一的なメソッドで操作できる。

sanitize.tsによる入力検証

AIエージェントが生成したパラメータを各プラットフォームに渡す前に、必ずsanitizeする。不正な値(例: 負の予算、無効なステータス)を事前に弾くことで、API呼び出しエラーを防ぐ。

Next.js + API Routes構成の推奨

renueの実装ではNext.js App RouterのAPI Routesでバックエンドを実装している。主な理由は以下の通り。

フロントエンドと同じTypeScriptで統一できる
認証ミドルウェアをフロント・APIで共有できる
SWR/SWR Mutationとの相性が良い
Chakra UI v2との統合が容易

DBアクセスは`lib/db.ts`のMySQLコネクションプール経由、ファイルアップロードは`lib/storage.ts`のS3クライアント(本番S3 or 開発用MinIO)経由で統一している。

開発時の認証ルール

3段階の認可チェック

requireAuth(): ログイン必須
requireOrg(): 組織所属が必須(org_idとproject_idsを取得)
requireAdmin(): 管理者のみ

2FA(TOTP)の本番必須化

本番環境では2FA必須とする。認証情報へのアクセス、管理操作、APIキー管理など、セキュリティクリティカルな操作は必ず2FAで保護する。

CSRF対策

Origin/Refererチェックにより、外部サイトからのCSRF攻撃を防ぐ。Next.js標準のCSRF対策に加え、セキュリティヘッダー(X-Frame-Options等)も明示的に設定する。

renueのアプローチ — Self-DX Firstによる広告AIエージェント

renueは「Self-DX First」の方針のもと、広告代理AIエージェントを自社プロダクトとして開発・運用している。社内12業務(採用・経理・PMO・評価など)を553のAIツールで自動化済み(2026年1月時点)であり、広告代理AIエージェントはその中でも最も機能が豊富なプロダクトの一つである(全て公開情報)。

公開されている特徴

6媒体統合(Google・Meta・X・TikTok・LINE・YouTube)
マージン1〜2%(従来型代理店の最大90%以上削減)
クリエイティブ管理機能内蔵(生成→QA→配信→実績取り込みまで一気通貫)
マルチテナントSaaS設計(複数組織で安全に利用可能)
TypeScript + Next.js + MySQLで構築
Anthropic Claude APIをメインLLMとして利用

導入時のよくある失敗パターン

ツールを定義せずに汎用チャットで対応しようとする: エージェントが推測で動き、誤操作のリスクが高い
SQLを無制限に書かせる: 認証情報や他テナントのデータが漏洩する
マルチテナント分離を後回しにする: 後から実装すると全API routeの書き直しが必要
認証情報を.envに残す: 複数組織での運用ができない
Rate Limitを設定しない: AI生成コストが爆発する
監査ログを記録しない: トラブル時に原因追跡できない
曖昧な指示をそのまま実行する: 意図しない操作が発生する

よくある質問

Claude Agent SDKと自前実装、どちらが良い?

本格的なマルチテナントSaaSを作るなら、Next.js + Anthropic SDKで自前実装するのが柔軟性が高い。Claude Agent SDKはPython中心で、Hookやストリーミング配信が強力だが、複雑なテナント分離・認証・UIとの統合は自前実装の方が扱いやすい。

SQLホワイトリストを維持するコストは?

許可テーブルが増減するたびに更新が必要だが、これは「セキュリティコスト」として割り切るべきである。間違ったテーブルへのアクセスを許してしまうリスクに比べれば、メンテナンスコストは軽微である。

マルチテナント分離のベストプラクティスは?

アプリケーション層でorg_id絞り込みを徹底する。ヘルパー関数(verifyResourceOrg等)に統一し、個別のAPI routeで直接クエリを書かない。また、定期的にコードレビューで「org_idの絞り込みがあるか」をチェックする文化が重要。

どのLLMを使うべき?

2026年現在、Anthropic Claude(Opus/Sonnet)がツール呼び出しと構造化出力で最も安定している。OpenAI GPT-4oやGoogle Gemini 2.0も選択肢だが、LLMごとにTool Schemaの扱いが微妙に異なるため、本番では1つに統一するのが運用上楽である。

開発開始から本番リリースまでの期間は?

本格実装の場合、最低3〜6ヶ月は必要。特にマルチテナント分離・認証・Rate Limit・監査ログのセキュリティレイヤー実装に時間がかかる。機能だけなら1〜2ヶ月で動くものが作れるが、本番運用に耐えるにはセキュリティレイヤーが必須である。