広告コマンドセンターの構築 は何をしますか？
目的
Google Ads と Meta Ads の信頼性の高い広告ダッシュボードを構築します。数値の出所（プロベナンス）の保持、プラットフォーム間の差異の明確化、組織の分離、および広告プラットフォームに送信されるアクションのセキュリティを確保します。
構築前の製品分類
- レポート：接続、同期、読み取り専用。
- アシスト運用：推奨、プレビュー、そして予算、一時停止、再開に対する人間による承認。
- SaaS セルフサービス：マルチユーザー OAuth、アカウント選択、権限管理、課金、コンプライアンス、サポート。
管理者接続とシミュレーションテストのみが存在する場合、3 番目のレベルを約束しないでください。
実際のコンテキストから始める
スタックを選択する前に、既存のリポジトリとインフラストラクチャを調査します。対象ユーザー、アカウント数、更新頻度、期待される履歴、コンバージョンの真実の情報源、通貨、タイムゾーン、ホスティング、コンプライアンスの制約を収集します。
ソリューションの規模を選択したレベルに合わせます。内部の単一組織向けの読み取り専用ツールの場合、単一組織、単純なロール、モノリスで十分です。対応するニーズなしに、セルフサービス OAuth、マイクロサービス、課金、承認ワークフローを課さないでください。
有用な参考資料を読み込む
- 常に architecture-data-sync.md を読んでください。
- Google Ads については google-ads.md を読んでください。
- Meta Ads については meta-ads.md を読んでください。
- 外部書き込みや本番リリースの前には、必ず production-safety.md を読んでください。
- システム完了と宣言する前に、acceptance-checklist.md の該当セクションを適用してください。
API のバージョン、権限、レビュー手順、クォータは変更されます。実装時には公式ドキュメントを確認してください。
ワークフロー
- 機能マトリックスを作成する：プラットフォーム、読み取り/書き込み、ソース、確認済みステータス、制限。
- 組織、メンバー、ロール、接続、広告アカウント、監査ログを設計する。
- 最初に読み取り専用コネクタを実装し、生データの出所を保持する。
- 冪等なタスクで正規化されたデータベースに同期する。鮮度、エラー、カバレッジ、アトリビューションコンテキストを表示する。
- クローズドピリオドのサンプルを Google および Meta のネイティブインターフェースと照合する。
- ルールと決定論的な計算で推奨を生成する。LLM はそれらの説明や言い換えにのみ使用する。
- 各書き込み操作を個別に追加し、プレビュー、承認、制限、冪等性、監査、リモート確認、ロールバック手順を含める。
- 組織間の分離、OAuth 期限切れ、クォータ、タスク再試行、欠落メトリクスをテストする。
不変のルール
- シークレット情報は、リポジトリ、ブラウザ、ログ、スクリーンショット、エクスポート、プロンプトに含めない。
- Google と Meta のコンバージョンを単純に合計してはいけない：プラットフォーム、アクション、ウィンドウ、アトリビューションモデルを保持する。
- スケジュールされた同期はリアルタイムではない。
- 明示的な許可と正確なスコープなしに、本番アカウントで変更をテストしてはいけない。
- 各機能を「実装済み」「サンドボックスでテスト済み」「本番で検証済み」「部分的」のいずれかに分類する。
成果物
アーキテクチャとその前提条件、データスキーマ、Google および Meta の接続フロー、同期戦略、権限マトリックス、書き込み保護、照合テスト、運用ランブックを提供すること。実装済みのものと未検証のものを明確に区別すること。