Vibe Codingは、ソフトウェアを作れる人の範囲を広げた。Agentが構文や実装のより多くを担い、人間は意図と判断に集中する。「Vibe Marketing」も、本来は同じ変化を意味するはずだ。
ところが、現在の多くの事例は、まだ「投稿に1つのプロンプト、スレッドにもう1つ、ランディングページにさらに1つ」という形にとどまっている。そのたびにコンテキストはゼロからだ。
それはマーケティングシステムではない。単にタイピングが速くなっただけだ。
Shann Holmberg氏の「How to Become a Marketing Engineer」は、本物のVibe Marketingに必要なものを、私が読んだ中で最も明確に説明していた。職能ごとに整理されたワークスペース、執筆より先に接続されたツールとデータ、Agentが出典をたどれる知識レイヤー、そして人間によるレビューゲートだ。
3人でBeatAPIを運営している私たちも、これらの要素の粗い版をすでに作っていた。ただし、共通の言葉で説明できていなかった。彼の構造を読んだことで、私たちが作りつつあるものを、1つのシステムとして見られるようになった。
投稿単位ではなく、職能単位でワークスペースを整理する
Agentに「マーケティング関連のファイル」を1つの大きなフォルダで渡すべきではない。
コンテンツ、SEO、広告、ライフサイクルなど、職能ごとにワークスペースを分け、それぞれに独自のワークフローと出力を持たせる。その上で、すべての職能が最初に読む共通レイヤーを置く。対象ユーザー、製品の事実、ポジショニングなどだ。
私たちも似た構造にたどり着いた。1つの正式なポジショニング文書と、チャネルの状態を管理する1つのグロースプレイブックを使っている。そして独自のルールがある。
事実は1つ、チャネルごとの原稿は複数。コピー＆ペーストはしない。
同じ検証済みの開発者ストーリーでも、X Article、LinkedIn、Substack、DEV Community、Qiita、Zennではそれぞれ表現を変えた。事実は固定したまま、導入、技術的な深さ、CTAを読者に合わせている。
ライターを接続する前に、ツールとデータを接続する
ソーシャルデータ、生成ツール、パフォーマンスデータに対するAPIアクセスは、Agentが実用的な仕事をするためのインフラだ。文章生成のプロンプトより先に用意しなければならない。
これはBeatAPIの前提とも重なる。そのため、自分たちのマーケティングワークフローを検証する良い問いになった。
マーケティングAgentは、本当に現実のデータへアクセスしているのか。それともまだ推測しているのか。
先週、私たちはAgentにBeatAPI Social Data APIを使わせ、特定の24時間にXで注目されているAIトピックを調べた。1つのBearer Key、1つのエンドポイント、twitter.web.fetch_search_timeline Actionを使用した。
3回の検索で60件の投稿を取得し、重複除去後に指定した24時間内の21件を残し、5つのテーマに整理した。重要なのは数そのものではない。開発者に提供している製品を自分たちのマーケティングAgentも使い、推測だけでテーマを決める状態から抜け出したことが重要だ。
読むだけではなく、引用できる知識レイヤーを作る
社内知識と外部知識を分ける考え方は正しい。私たちはさらに1つ条件を追加した。
すべての主張に、追跡できる出典が必要だ。フォルダに入っているだけでは足りない。
今週、私たちは1つの調査ブリーフを4回の独立したAIリサーチで処理した。当初は6つのファイルがあったが、2組はそれぞれ同じ調査のレポートと作業用ワークブックだったため、別の調査とは数えなかった。
4回の実質的な調査から、約160件の候補となるペインポイントを集め、25の反復する問題ファミリーに対応付け、実際にはユーザーの痛みではないものを5件除外した。
私たちは、25個のきれいな要約だけで原始ソースを置き換えなかった。原始の出典をすべて残した。主張から実際の不満や質問までたどれるAgentであれば、公開するに十分な強さがあるか判断できる。要約しか見えないAgentには、その判断はできない。
Agentに仕事を任せるほど、ゲートが重要になる
Agentが実際の仕事を担うようになると、権限の境界はオプションではなくなる。
私たちのシステムでは、調査は公開権限なしで実行できる。レビュー済みの下書きも、それだけでは公開承認済みではない。公開済みと記録するのは、実際の公開URLを確認し、記録した後だけだ。その後、スクリプトがURLの欠落、不正なステータスリンク、間違ったアカウントハンドルを検出する。
上流でより大きな自律性をAgentに与えられるのは、下流のゲートをより厳密にしているからだ。
BeatAPIが担う部分
Vibe Codingにモデル、ハーネス、ワークスペースが必要なら、本物のVibe Marketingにも同じものが必要だ。さらに、チャット画面の中ではなく、APIを通じて利用できる専門能力が必要になる。
私たちにとって、BeatAPIは具体的に2つの部分を提供する。
- 画像、動画、テキスト制作のためのモデルAPI。長時間実行されるメディアやワークフローの呼び出しは、非同期タスク、ポーリングまたはWebhook、ホスト済み出力、利用記録という形で扱う。
- 公開Actionカタログに対して認証付きの呼び出しを行うSocial Data API。
どちらも1つのアカウントと1つのKeyから利用できるが、すべてのワークフローが同じ実行方式ではない。
最初から1人のマーケティング部門を作ろうとしないほうがいい。
1つの職能、1つの実際のAPI接続、1つのゲートから始める。
そのタスクにモデルや現在のソーシャルデータが必要なら、BeatAPIで実際に1回実行し、結果、コスト、ステータス、出典までの追跡可能性を確認してから、次に何を接続するか決めてほしい。