Skip to content
··1分で読めます

4週間目:昼寝をしながら10エージェントのマーケティングプラットフォームを構築中

マルチテナントアーキテクチャを備えた3つのAIマーケティングエージェントを4週間で構築しました。これは前回のプロダクトで1ヶ月かかった量と同じで、そのプロダクトはローンチまで7ヶ月かかりました。

更新(2025年11月): STRAŦUMがローンチしました!「4週間スピードラン」として始まったものが、完全な9エージェントのマーケティングインテリジェンスアプリケーションへと進化しました。フルローンチストーリーはこちら:STRAŦUM:75日間で一人で構築した9エージェントマーケティングアプリケーション

今すぐ試す: stratum.chandlernguyen.comにて(Private Alpha - 招待制アクセス)

6日間DIALØGUEをローンチしてから次のプロジェクトを開始するまでに待った日数です。

「ポッドキャストジェネレーターのマーケティングとか、ユーザー獲得とか、バグ修正とかすべきじゃないの?」と思うかもしれません。そしてそれは_全くもって正しい_です。でもこういうことなんです — 新しいAIツールでどこまで速く進めるか試したかったのです。スピードラン、野心的すぎると呼んでもいいし、Claude CodeとGemini 2.5 Proが開発を再び_楽しく_した結果と呼んでもいいです。

あり得ないはずのタイムライン

これを視点に入れてみましょう:

- DIALØGUE:最初のコードからローンチまで6-7ヶ月

- Marketing Suite:4週間目にして、すでに3つのAIエージェントが互いに連携中

gitヒストリーを見ると、初日の終わりまでに以下が完了していました:

- マルチテナントアーキテクチャ(組織 → クライアント → キャンペーンの階層構造)

- 初期のReactフロントエンドと認証

- 11の異なるフレームワークを使用する動作するビジネス戦略Agent(異なる地域をカバー)。これらのフレームワークは世界的・地域的なトップコンサルティングファームで使用されています。例えば:

- Supabase統合とRow Level Security

DIALØGUEの構築で最初の_1ヶ月_で達成した量を超えています。

モチベーションになる数字

過去4週間のクイック指標:

- リリースした機能:3つの完全なエージェント + マルチテナントアーキテクチャ

- コード行数:約117,000(Python: 39k、TypeScript: 58k、SQL: 20k、Javascript: 残り)

- データベーステーブル:39(それぞれ特定の目的に対応 - 詳細は後ほど)

- Gitコミット:232(約26日間で)

- 消費したコーヒー:聞かないでください

なぜこのプロジェクトは実際10倍難しいのか

DIALØGUEは確かに複雑でした。AWS Lambda Functions、Step Functions、最終的にすべてをGoogle Cloud Runに移行。しかし根本的には単一目的のツールでした:ポッドキャストを生成する。ユーザータイプは1つ。ワークフローは1つ。ハッピーパスは1つ。

このMarketing Suite?どういう意味か見せましょう:

実際のシナリオ: あるエージェンシーがNikeとAdidas(仮定)を管理しています。エージェンシーのストラテジストがBusiness Strategy Agentを使ってNikeのポジションを分析します。その分析はstrategy_outputsテーブルに自動保存されます。Persona Agentに切り替えると、Nikeの戦略を引き出してペルソナ開発に反映させますが、Adidasのデータは見え_ません_。一方、brand_guidelinesテーブルのNikeのブランドガイドラインはContent Agentにカスケードし、すべてのコンテンツがNikeの声で作成され、Adidasのものではないことを保証します。

これに必要なのは:

- SME vs AGENCY型のorganizationsテーブル

- clientsテーブル(エージェンシー専用)

- orgとclient両方への外部キーを持つcampaigns

- キャンペーンレベルの分離を持つstrategy_outputs

- 階層的な継承を持つbrand_guidelines

- すべてのテーブルに対するRow Level Securityポリシー

これは_1つの_ワークフローだけです。これを10のエージェントに掛け合わせると、それぞれに独自のデータ要件があります。

実際に動いているもの(とまだカオスなもの)

動いているもの(3つのライブAgent + ビジネスインテリジェンス)

Business Strategy Agent:典型的なSWOTジェネレーターではありません。11の包括的なフレームワークを適用します:

- SWOT分析

- ポーターのファイブフォース(競争の激しさ、供給者の交渉力、買い手の交渉力、代替品の脅威、新規参入の脅威)

- ビジネスモデルキャンバス(ビジネスデザインの9つの構成要素)

- ICE優先順位付け(Impact、Confidence、Easeスコアリング)

- BCG成長シェアマトリックス(Star、Cash Cow、Question Mark、Dog)

- VRIOフレームワーク(Value、Rarity、Imitability、Organization)

- Three Horizonsモデル(現在のコア、新興の機会、将来の賭け)

- ブルーオーシャン戦略(排除、削減、増加、創造のグリッド)

- McKinsey 7Sフレームワーク(戦略、構造、システム、共有価値、スキル、スタイル、スタッフ)

- OKRsフレームワーク(目標と主要な成果)

- Jobs to Be Done(顧客のジョブ、ペイン、ゲイン)

各フレームワークは他のエージェントに入力される構造化データを生成します。SWOT分析を実行すると、「機会」がMarketing Strategy Agentの成長戦術に自動的に反映されます。

Persona Agent:15以上の属性を持つ詳細な顧客ペルソナを生成し、そして — ここが驚きの部分 — インタビューもできます。実際の会話:

あなた:「現在のプロジェクト管理ツールで最も不満に思うことは何ですか?」

ペルソナ(テックスタートアップ創業者):「絶え間ないコンテキストスイッチングです。Slackを確認し、次にAsana、そしてアナリティクスダッシュボード。何に注意を払うべきか分かるまでに30分を失ってしまいます。」

各インタビュー応答はpersona_interactionsの履歴から引き出すため、よりスマートになります。ユーザーはこれらのインタビューに20-30分を費やしています。あるユーザーは「フォーカスグループのようだけど、即座にできて実際に役立つ」と言ってくれました。

Marketing Strategy Agent:これは橋渡し役です。ビジネス戦略を取り込み、ペルソナを理解し、実行可能な市場投入計画を作成します。単に「ソーシャルメディアを使いましょう」とは言いません — 特定のペルソナを特定のチャネルに特定のメッセージングでマッピングします。ブートストラップされたスタートアップ向けのゼロ予算戦術。中小企業向けの70-20-10予算配分。エンタープライズ向けのマルチチャネルオーケストレーション。

ビジネスインテリジェンス(隠れたヒーロー):任意のエージェントとのすべての会話が自動的にインサイトを抽出し、組織の知識を構築します。Strategy Agentとヨーロッパ市場参入について話しましたか?そのインサイトはai_insightsテーブルに保存されます。翌週Content Agentを使う時には、すでにヨーロッパ展開計画を知っています。再説明の必要なし。コンテキストの喪失なし。

まだ構築中(次の7エージェント)

Campaign Execution Agent:ここからが怖い部分です。Google Ads、Meta、LinkedIn、TikTokのAPIキーをどうやって安全に保存するか?現在の計画では、すべてのAPIコールに監査ログを付けたplatform_credentialsテーブルでの暗号化ストレージを予定しています。しかし権限モデルは夜も眠れない問題です。

Analytics Agent:どのAPIを最初に統合すべきか?Google Analytics 4?Meta ads?LinkedIn Analytics?課題はデータの取得だけではなく、プラットフォーム間で正規化してリンゴとリンゴを比較できるようにすることです。

ROI & Budget Agent:異なるアトリビューションモデルを持つ複数プラットフォームにまたがるリアルタイム追跡。GoogleのデータドリブンアトリビューションとMetaのモデルをどう調和させるか?まだ模索中です。

その他の4エージェント:Quick Wins(即座の機会発見)、Competitive Intelligence(倫理的な競合分析)、Client Success(リテンション戦略)、Content Agent(実際にはすでに動作していますがポリッシュが必要)。

夜も眠れない難問

- ブランド名:このアプリケーションを何と呼ぶべきか? :P 良い提案があれば、下のコメントで教えてください!

- APIセキュリティ:複数の広告プラットフォームのAPIキーをセキュリティの悪夢にならずにどう扱うか?

- 統一された体験:10の専門エージェントを、10の異なるツールをダクトテープでくっつけたものではなく、1つの統合プラットフォームのように感じさせるには

- その他多数 :)

アーキテクチャの進化:痛みから学ぶ

DIALØGUEでは、レースコンディションについて痛い目に遭いました。あの3分のサインアップバグを覚えていますか?auth triggerとEdge Functionが同じユーザーレコードを作成しようと競い合い、新規ユーザーが永遠に待たされていました。

今回は初日から正しく構築しました。数日前の実際の例をお見せします:

問題: Marketing Strategy Agentは、どのペルソナが存在するか、どの戦略が作成されたか、どのブランドガイドラインに従うべきかを知る必要がありますが、完全なデータ分離を維持しながらです。

解決策: 各エージェントが複数のテーブルにクエリする(遅い、複雑、エラーが起きやすい)代わりに、単一の信頼できる情報源として機能するEnterprise Context Serviceを構築しました:

// Before: 各エージェントが複数クエリを実行
  const personas = await supabase.from('personas').select()
  const strategies = await supabase.from('strategies').select()
  const guidelines = await supabase.from('brand_guidelines').select()

  // After: 1つのインテリジェントサービス
  const context = await getEnterpriseContext(campaignId)
  // フィルタリング、キャッシュ、適切にスコープされたデータを45msで返す

結果は?Content Agentはブランドボイスガイドラインに即座にアクセスし、どのペルソナ向けに書くべきかを確認し、マーケティング戦略を理解できます。すべてデータ境界を尊重した1回のコールで。

スピードの違いは本物

9月14日は凄まじかったです。タイムスタンプ付きの実際のgitログを見てください:

08:04 AM - フロントエンドを標準化されたAPIクライアントに移行
08:19 AM - API標準化完了(カバレッジ100%)
11:34 AM - フェーズ1:中央集約ルート設定
            (ハードコードされたURLがどこにもなくなった)
1:00 PM  - フェーズ2:全10エージェントページを標準化
            (/agents/strategy/:campaignIdのような統一URLパターン)
1:10 PM  - フェーズ3.1:コアコンテキスト管理
            (workspace → client → campaign階層をURLに反映)
4:31 PM  - フェーズ3.2:ナビゲーションコンポーネントがコンテキスト対応に
            (パンくずリストに「Nike › Summer Campaign › Strategy Agent」と表示)
4:38 PM  - フェーズ3.3:すべてのエージェントがコンテキストシステムに統合
            (キャンペーン切り替え時に位置が保持される)
5:03 PM  - フェーズ3.4:テスト&ポリッシュ
            (コード分割で92%のバンドルサイズ削減)

6つの主要なアーキテクチャ改善。URLシステムだけでコードベース全体の40以上のファイルに影響しました。AI支援なしでは、これは恐らく数日間がかりのリファクタで、いくつかの壊れた機能が出ていたでしょう。

しかも実はほとんどパソコンの前にいませんでした :D

日曜日だったので、教会に行き、スーパーマーケットに行き、シーフードのフルランチを食べ、昼寝をし、Costcoに行き、iPadでゲームをしていました。これはAI支援コーディングのおかげで可能です。Claude CodeとGemini CLIに感謝! URL標準化がユーザーにとって実際に何を意味するのかはこちらです:

// Before: エージェント間の切り替えでコンテキストが失われる
  "/strategy" // どのキャンペーン?どのクライアント?誰にも分からない

  // After: コンテキストがURLに保持される
  "/workspace/nike/campaign/summer-2025/agents/strategy"
  // ブックマーク、共有、リフレッシュ - コンテキストが維持される

DIALØGUEがローンチしたばかりなのになぜ構築するのか?

できるからです。ツールが_それほど_良くなったからです。広告業界20年以上の経験を経て、ようやくずっと使いたかったマーケティングプラットフォームを構築するスキルを手に入れたからです。

でも最大の理由は?ドメインの専門知識と最新のAIツールを組み合わせた時に何が可能かを記録したいからです。これは開発者を置き換えることではなく、増幅することです。4週間前、これほど複雑なものを構築するにはチームが必要でした。今は決意と、良いAIアシスタントと、危険な量のカフェインがあれば可能です。(ただし、後でSwiftを知らずにネイティブiOSアプリを構築した時に分かったように、AIが連れて行ってくれるのは約60%で、残りの40%のテイストとポリッシュは完全に人間の仕事です。)

次のステップ

10月/11月にアルファローンチを目標にしています。必要なことはこちらです:

- 残りの7エージェントを完成させる

- キャンペーン計画インターフェースを構築

- 広告プラットフォーム統合のセキュリティを解決

- エージェンシーUI/フローが合理的か確認

- 実際のユーザーでテスト(恐ろしい)

Analytics Agentだけでも、Google Analytics、広告プラットフォーム、内部指標のデータを統合ダッシュボードに集約する必要があります。ROI Agentは複数プラットフォームにまたがるほぼリアルタイムの予算追跡が必要です。

それぞれがそれ自体で1つのプロジェクトです。でもこのペースなら?実際に可能な気がしてきました???

フォローしてくれますか?構築を進めながら、もっと更新を共有していきます。

パブリックに構築するということは、勝利と一緒にカオスも共有するということです。今のところ、ほとんどカオスです。でも_生産的な_カオスで、それが大事です。

1ヶ月後にまた見に来てください。うまくいけば、マーケティング部門全体の仕事をAIエージェントがこなすマーケティングプラットフォームをテストできるようになります。うまくいかなかったら...まあ、少なくともブログ記事は面白いものになるでしょう。 :P

続きを読む

私の歩み
つながる
言語
設定