見出し画像

「エージェントに選ばれる」プロダクトをどう作るか——YCパートナーが語る、開発者ツール市場の新しいルール

AIエージェントが自律的にツールを選び、コードを書き、タスクを実行する時代が来た。YCombinatorのパートナーたちのポッドキャスト「The Light Cone」では、この変化がスタートアップのプロダクト設計とGo-to-Market戦略に何をもたらすかが具体的に議論された。「Make something people want」というYCの創業哲学は今、「Make something agents want」へと書き換えられようとしている。


1. エージェントが「選ぶ」ことで何が変わるのか


1-1. ツール選択の主体が変わる

1年前、開発者ツールの採用は人間のコミュニティ経由で起きていた。Stack Overflow、GitHubのトレンドリポジトリ、同僚の口コミ——それが今、AIエージェントが直接ツールを選択・利用する形に変わりつつある。

「エージェントは今後のソフトウェア市場だ。エージェントが選ぶものを作れ」——ポッドキャストで引用されたこの一文は、開発者ツール市場の変化を端的に表している。

1-2. 開発者人口の拡大とエージェントの乗数効果

従来、コンピューターサイエンスを学んだ開発者は世界に約2000万人程度と言われていた。しかし、ClaudeCodeのようなコーディングエージェントの普及により、プログラミング経験のない人でもアプリを作れる時代になった。「今や世界中の誰もが開発者になれる。数億人規模になりうる」という認識の上に、さらに各ユーザーが複数のエージェントを並走させるという乗数効果が加わる。ツール選択の意思決定主体の数は、人間の開発者数をはるかに上回るペースで増えていく。

2. 「選ばれる」ための条件——ドキュメントが競争力になる


2-1. Supabaseはなぜエージェントのデフォルト選択になったか

過去12ヶ月でPostgreSQLデータベースの新規作成数が急増している。その背景にはバイブコーディング(自然言語でコードを生成する開発スタイル)とエージェントによる自律的なツール選択がある。エージェントがデータベースホスティングとしてSupabaseを選ぶ理由は、機能の優劣よりも「ドキュメントの充実度と解析しやすさ」にある。「エージェントはSupabaseのドキュメントが最も優れていると判断するから、それをデフォルトツールとして使う」という説明はシンプルだが、示唆は大きい。

2-2. Resendが示した先行事例

メール送信ツールのResendは、この変化を1年以上前に察知した。創業者がChatGPT経由の顧客流入がトップ3チャネルに入ったことに気づき、ドキュメントをエージェント向けに最適化した。

その具体的な内容は、「エージェントや人間が問いそうな形式での質問整理」「クリック一つで表示される構造化された箇条書き回答」「各項目に付随するコードスニペット」だ。さらに、llm.txtという、LLMがResendをデフォルトスタックとして推奨しやすくするための専用ファイルまで整備した。

対照的に、従来型のメール大手SendGridのドキュメントは、「カスタマーサポートへの誘導が中心でコードスニペットを探しにくく、エージェントには解析困難」だとされた。従業員1万人規模の企業でさえ、この変化に対応できていないという現実がある。

2-3. Mintlifyというインフラプレーヤー

ドキュメントのエージェント最適化という需要の高まりを受け、開発者向けドキュメント作成ツールのMintlifyに大きな追い風が吹いている。もともとは「見栄えの良いAPIドキュメントを手軽に作れる」というポジショニングだったが、今やエージェント向け最適化という必須ニーズの担い手になりつつある。「ドキュメントの品質を5%改善するだけでビジネスへの影響が大きい——これは前例のない構造だ」という指摘は、この領域への投資対効果を端的に示している。

3. エージェント専用インフラというビジネス機会


3-1. Agent Mail——「エージェントのためのメールボックス」

既存のメールプロバイダーは、スパム対策として自動化を意図的に難しくしている。そこに登場したのが、Agent Mailだ。AIエージェント専用のメールプロバイダーとして設計された同社は、ClaudeCodeのようなエージェントに固有のメールアドレスを持たせ、外部サービスとの通信を可能にする。エージェント向けコーディングツールの普及とともに需要が急拡大した。

「エージェントが本当に自律的に動くには、個人アカウントに接続するのではなく、エージェント自身のメールと電話番号を持たせるのが正しいアプローチだ」という認識が共有されている。

3-2. 「エージェント向けTwilio」はまだない

「エージェント向けの電話番号サービスは誰が作るのか」という問いは、まだ整備されていない領域の存在を示す。メール・電話番号・決済・認証——人間向けに設計されたすべてのインフラに、エージェント向けの代替品が必要になる可能性がある。「エージェントのためのエージェントが使う技術スタック」というコンセプトは、まだスタートアップが入り込める余地が大きい段階にある。

4. スタートアップ創業者へのインサイト——「エージェントの視点で設計する」


ポッドキャストを通じて見えてきた実践的な示唆をまとめる。

まず、エージェントと実際に手を動かして使い込むことが出発点だ。「エージェントが何を得意とし、どこで詰まるかを自分のメンタルモデルとして持つこと」——これがエージェントフレンドリーなプロダクト設計の前提になる。

次に、ドキュメントは、「フロントドア」だという認識を持つことだ。SEOでもなく、営業チームでもなく、エージェントが最初に参照するドキュメントが、ツール選択を決定づける。APIファースト、コードスニペットの充実、問答形式での整理——これらはエージェントに「選ばれる」ための基本条件になりつつある。

そして、エージェントが自然に向かいたい方向に合わせる姿勢も重要だ。「モデルが自然にやりたいことを支援し、逆らわない」という設計思想は、エージェントとの協調を前提とするプロダクト開発において一つの原則になる。ウェブサイトよりAPIを好み、オープンソースを好むエージェントの傾向は、設計判断の基準として参照できる。

オススメ記事


Next Big Wave(成長株・アイデアの種・トレンド深掘り)



いいなと思ったら応援しよう!