BeatAPIは公開から10日間で400人以上の登録と、約150ドルの売上を得ました。
3人のチームにとって励みになる数字です。しかし、それ以上に見えてきたのは、AIによって開発は速くなっても、プロダクトを見つけてもらい、信頼してもらうことは依然として難しい、という事実でした。
私は開発者ですが、現在は成長施策の大部分も担当しています。私たちが作っているBeatAPIは、汎用Agent向けのプロフェッショナルな機能レイヤーです。簡単に言えば「OpenRouter for Agents」であり、AIモデル、Social Data、MCPツールを1つの入口から利用できます。
当初はSEO、X、開発者コミュニティ、OSS、ディレクトリなど、チャネルの一覧を増やしていました。しかし、一覧だけでは優先順位が決まりません。そこで各チャネルに明確な役割を持たせ、1つのファネルとして接続しました。
1. 検索は、すでに存在する需要を捉える
出発点は、開発者が実際に抱えている問いです。
- このワークフローにはどのAPIが合うのか
- 同じモデル・同じ仕様なら費用はいくらか
- 長時間実行されるタスクをAgentからどう扱うべきか
乗り換え意図には比較ページ、価格判断には無料のAPIコスト計算機、実装上の疑問には技術記事を用意します。
AEOでは、さらにAIアシスタント側から逆算します。ユーザーになったつもりで質問し、観察できる範囲で、どの検索語が使われ、どのページが開かれ、何が引用され、どんな根拠が不足しているかを確認します。
比較の根拠が足りなければ条件をそろえた比較を作る。構造化データが必要なら表や計算機を作る。ドキュメント、GitHub、開発者コミュニティが参照されるなら、自社ブログだけでなく、そこにも検証可能な情報を置く。
ユーザーとして質問する → 参照経路を見る → 不足する根拠を見つける → コンテンツを再設計する
調査自体もAgenticなワークフローです。FirecrawlがWebソースを収集し、Codexが全体を調整します。BeatAPI経由で工程ごとにモデルを使い分け、長文の初稿にはClaude系、全体計画にはGPT-6 Astra、反復実行にはDeepSeek、編集品質の確認にはGPT-5.6 Solを利用します。
モデルは選択肢を作ります。公開を決めるのは私たち自身の基準です。
2. Social Dataは、立ち上がりつつある需要を捉える
検索は「何が探されているか」を示します。Social Dataは「その問題が今どのような言葉で語られているか」を示します。
私たちは毎日、BeatAPIのSocial Data APIでXのタイムライン、トレンド、投稿の反応、周辺の会話を確認します。関連性が高く、注目が伸びている会話を候補にします。
返信は自動投稿しません。元の投稿を読み、実装の詳細、運用上の制約、コストのトレードオフ、再現可能な例など、具体的な価値を追加できる場合だけ返信します。
返信から疑問を見つけ、短い投稿で仮説を試し、反応があったテーマを長文で整理する。この順番にすると、記事のための記事を減らせます。
3. 開発者ストーリーは、日々の実装を証拠に変える
開発者が欲しいのは、APIエンドポイントそのものではありません。完了したタスク、低いコスト、壊れにくいワークフロー、管理する統合先の少なさです。
そのため、普段の開発がそのままコンテンツの材料になります。
- なぜ非同期タスク方式を採用したのか
- プロバイダー障害時にどう復旧するのか
- 計画、実行、執筆、QAでモデルを分ける理由は何か
- どの仮説が間違っていたのか
同じ事実を、Xの短文、開発者コミュニティの記事、詳しい実装ガイドへ展開できます。BeatAPIは後付けの広告ではなく、その判断を実際に試したプロダクトとして自然に登場します。
4. OSSは、主張を検証可能にする
GitHubを集客チャネルとして使うためだけにリポジトリを作ることはしません。自分たちが日常的に使っているワークフローを公開します。
BeatDesignは、AI画像・動画制作のためのローカルファーストなOSSワークスペースです。1つのProjectの中にCanvas、Assets、動画Editor、MCPアクセスをまとめています。
実際にTikTok向けUGC動画などで、Canvas上で企画し、BeatAPI経由でバリエーションを生成し、使える成果物をAssetsへ移し、タイムラインで仕上げています。
公開することで、コミュニティはワークフローを確認し、ローカルで動かし、拡張し、不足点を指摘できます。BeatDesignは同時にBeatAPIのCustomer Zeroでもあり、Agent主導のクリエイティブ制作でAPIを検証する実環境です。
チャネル数より、完了したループを見る
GitHub Starは登録ではありません。登録はAPIキー作成ではありません。APIキー作成はタスク成功ではありません。
私たちが見る経路は次の通りです。
実際の問い → 役に立つ成果物 → 適切な訪問者 → 登録 → APIキー → タスク成功 → 継続利用 → 売上
検索は既存需要を捉え、Social Dataは新しい需要を見つけ、開発者ストーリーは作業を証拠に変え、OSSはその証拠を検証可能にします。
どのループが最も強く複利で伸びるかは、まだ分かりません。だからこそ、答えが分かった後の成功談ではなく、学習している今の段階で記録しています。
BeatAPI: https://beatapi.io/