あなたのプロダクト、AIエージェントが使えますか？ toAという新市場を読み解く

こんにちは、カイ@プロダクトマネージャーです。

「うちのプロダクト、ユーザーに愛されてるし、NPSも高い。当面は大丈夫でしょ」

――そう思っていたのに、気づいたら競合にシェアを取られていた。

しかも、取っていったのは人間のユーザーじゃない。

AIエージェントです。

toC、toB――プロダクトの届け先を語るとき、私たちPMはこの2つの枠組みで考えてきました。

でも今、3つ目の宛先が生まれつつあります。

toA（to Agent）。

AIエージェントがプロダクトの"ユーザー"になる世界です。

自分は元メガベンチャーのPMで、今はAIにPM業務の8割を任せながらプロダクトを回しています。

この記事では、AIエージェント時代のプロダクト戦略として注目されるtoAという新しい市場カテゴリを「PMが翌日の会議で使える粒度」に噛み砕いて解説します。

技術の深い話はしません。

代わりに、チェックリスト、優先順位マトリクス、ステークホルダーへの説明テンプレートなど、PMの日常業務にそのまま使えるツールを用意しました。

読み終わったら、明日のスプリントプランニングで「ちょっとこの話させて」と切り出せるはずです。

toC・toBの次に来る「toA」とは何か

エージェントが"ユーザー"になる世界

toAとは、AIエージェントがプロダクトやサービスを自律的に利用するビジネスモデルのことです。

これまでプロダクトの「顧客」は人間でした。

toCなら個人ユーザー、toBなら企業の担当者。

どちらも人間がUIを操作して、プロダクトの価値を受け取っていました。

toAではこの前提がひっくり返ります。

AIエージェントがAPIを叩き、データを取得し、判断し、次のアクションを実行する。

人間は最終的な意思決定だけを行い、途中のオペレーションはエージェントが担う。

いわば、プロダクトの「お客さん」が人間からロボットに変わるようなものです。

パジ（hajimeataka）さんがnoteで紹介し、国内で広まった「toA」という概念は、単なるバズワードではありません。

Claudeが加速させる「toA」という新潮流｜パジ

note.com

プロダクトの設計思想そのものを問い直す、構造的な変化です。

「へぇ、面白い概念だね」で終わらせないでください。

この変化が何を意味するか、次の比較表を見ればゾッとするはずです。

toC → toB → toA、ビジネスモデルの地殻変動

3つのモデルを並べてみると、違いが鮮明になります。

ここ、ちょっと注目してください。

「スイッチングコスト」の行。

toCやtoBでは、ユーザーが慣れたUIやデータの蓄積が"堀"（moat）になっていました。

toAでは、その堀がほぼ消えます。

エージェントにとって、UIの使いやすさは無関係です。

APIの仕様が同等なら、レスポンスが10ミリ秒速い方に乗り換える。

それが、エージェントの「合理性」です。

つまり、PMが必死に積み上げてきた「使いやすいUI」「高いNPS」「ブランドへの愛着」が、toAの世界では防御壁にならないんです。

これ、結構衝撃的じゃないですか。

でも、まだ先の話だと思いますか？

実は、用語レベルで見ても市場が動き始めていることがわかります。

「BtoA」「Machine Customer」――呼び名が乱立する今のフェーズ

同じ概念を指す言葉がいくつも飛び交っています。

• toA / toAgent: 日本国内で広まりつつある呼称。パジ（hajimeataka）さんのnoteが起点
• BtoA（Business-to-Agent）: より正式なビジネスモデル表記。Zennの技術記事で詳述
• Machine Customer: Gartnerが2023年頃から主要トレンドとして位置づけた概念。少なくとも150億のコネクテッドプロダクトが「機械の顧客」として振る舞うポテンシャルを持つと予測している

用語がバラバラ。

これは実は良いニュースです。

用語が定まっていない = 市場定義がまだ固まっていない = 先行者が有利。

PMとしてこのフェーズで動くことには、明確な戦略的価値があります。

では、なぜ"今"なのか。

ここからがさらに面白いんです。

なぜPMが"今"toAを見なければいけないのか

エージェントは人間の100倍の速度で"乗り換える"

想像してみてください。

人間のユーザーは、多少不満があっても使い慣れたプロダクトに留まります。

データが溜まっている。

操作を覚え直すのが面倒。

ブランドへの信頼感がある。

――PMにとってはありがたい「惰性」ですよね。

エージェントには、これらの「留まる理由」が一切ありません。

エージェントの選定ロジックはシンプルです。

API仕様を確認し、レスポンス速度を計測し、コストを比較し、最適な選択肢に切り替える。

この判断を、人間なら数週間かけるところを数秒で完了します。

つまり、toAの世界では既存ユーザーの「慣れ」や「ブランドロイヤルティ」が防御壁にならないのです。

プロダクトの競争力が、API性能とドキュメントの質にダイレクトに紐づく。

PMとしてこの構造変化を理解しているかどうかで、ロードマップの引き方が根本的に変わります。

「でも、うちは人間のユーザーに選ばれてるから大丈夫でしょ？」

……本当にそうでしょうか。

"選ばれない"は"候補にすら入らない"

ここがtoAの一番怖いところです。

人間のユーザーなら、たとえAPIがなくても、WebサイトやアプリのUIから手作業でプロダクトを使ってくれます。

エージェントはそうしません。

エージェントの選定プロセスは、大まかにこうです。

1. APIドキュメント / llms.txt / MCPサーバーの有無を確認する
2. 認証方式を確認する（OAuth / APIキーが使えるか）
3. レスポンスのフォーマットを確認する（構造化されたJSONか）
4. 条件を満たすサービスの中から、性能・コストで最適なものを選ぶ

お気づきでしょうか。

ステップ1の段階で、APIもllms.txtもないプロダクトはふるい落とされます。

比較検討すらしてもらえない。

「UIが最高」「NPS80超え」「CSが手厚い」――人間に刺さるこれらの強みが、エージェントの選定フィルターには引っかからないのです。

これ、PMにとっては恐怖でしかないですよね。

自分たちが磨き上げてきた「強み」が、新しいチャネルでは完全に無効化される。

では、「まだ先の話でしょ」と言い続けて大丈夫でしょうか。

すでに動いているプレーヤーたち

「toAなんてまだ先の話でしょ？」と思うかもしれません。

でも、大手はもう動いています。

エージェントを迎え入れる側として、3社が特に象徴的です。

StripeはAgent Toolkitをリリースし、エージェントが決済処理を自律的に行える環境を整えました。

ShopifyはMCPサーバーを公開し、エージェントがストア管理・商品登録・在庫確認をAPI経由で行えるようにしています。

TwilioはAgent-2-Human（A2H）プロトコルを公開し、AIエージェントが承認取得・情報収集・エスカレーション等を人間に対して行うための標準プロトコルを整えています。

ここがポイントなんですが、これらは「実験的な取り組み」じゃないんです。

各社のコアプロダクトに直接組み込まれた、本気の戦略的投資です。

スタートアップも動いています。

ComposioはAIエージェントが1,000以上の外部サービスと連携するための統合プラットフォームを提供し、エージェントとSaaS群をつなぐインフラとして注目を集めています。

これらのプレーヤーに共通するのは、「エージェントをユーザーとして迎え入れる設計」を意識的に行っているということです。

では、あなたのプロダクトはどうでしょうか。

ここから先は、具体的な診断に入ります。

あなたのプロダクト、エージェントが使えますか？ ――5つの条件

ここからが本題です。

自社プロダクトがエージェントに"使ってもらえる"状態にあるかどうか。

以下の5つの条件で診断してみてください。

正直、全部クリアしているプロダクトはまだほとんどありません。

だからこそ、今チェックする価値があるんです。

条件1: APIが"外に開いて"いるか

最も基本的な、でも最も見落とされやすい条件です。

エージェントがプロダクトを使うには、プログラムからアクセスできるAPIが必要です。

「うちAPIありますよ」というプロダクト、多いですよね。

でもそれ、社内ツール連携用だったりしませんか。

社内専用のAPIは、外部に公開していなければ、toAの土俵に上がれません。

確認ポイントはシンプルです。

• 外部開発者がアクセスできるREST API / GraphQL APIが存在するか
• APIのエンドポイント一覧がドキュメントとして公開されているか
• サンドボックス環境（テスト用のAPI）が提供されているか

「APIはあるけど社内専用です」というプロダクトは、エージェントから見ると"存在しない"のと同じです。

ドアに鍵がかかっているどころか、ドアそのものがない状態。

エージェントはノックすらできません。

条件2: 認証フローがエージェント前提になっているか

APIがあっても、認証が人間前提だと使えません。

たとえば、ログイン画面でID・パスワードを入力し、二要素認証コードをSMSで受け取る――これは人間のためのフローです。

エージェントにスマホは持てませんからね。

エージェントが使えるのは、こういった認証方式です。

• OAuth 2.0（クライアントクレデンシャルフロー）
• APIキー（Bearer Token方式）
• JWT（トークンベースの認証）

もしあなたのプロダクトが「ブラウザでログインしないとAPI叩けない」状態なら、エージェントは認証の段階で詰みます。

人間に例えると「受付で名刺を出したいのに、受付がない」みたいな状態です。

条件3: レスポンスが"機械が読める形"か

エージェントはHTMLを「見る」ことができません。

正確には、HTMLを解析してスクレイピングすることは可能ですが、それは非効率で不安定な方法です。

エージェントが求めるのは、こういうレスポンスです。

{
  "status": "success",
  "data": {
    "order_id": "ORD-12345",
    "total": 4980,
    "currency": "JPY",
    "items": [
      {"name": "商品A", "quantity": 2, "price": 1990},
      {"name": "商品B", "quantity": 1, "price": 1000}
    ]
  }
}

構造化されたJSON。

フィールド名が明確で、型が一貫している。

これが「エージェントにとって読みやすい」レスポンスです。

人間でいえば、整理された棚から目的の書類をサッと取り出せる状態。

逆に、HTMLの中にデータが埋め込まれていてスクレイピングしないと取り出せない状態は、散らかった部屋で書類を探すようなものです。

エージェントはそんな面倒なことをせず、別のプロダクトに行ってしまいます。

条件4: ドキュメントがLLMに読まれる設計か

ここが意外と盲点なんです。

エージェントにとって、ドキュメントは「UI」です。

人間がアプリの画面を見て操作方法を理解するように、エージェントはAPIドキュメントを読んで使い方を理解します。

つまり、ドキュメントの質 = エージェントにとってのUXなんです。

チェックすべき項目は以下のとおりです。

• OpenAPI（Swagger）仕様書が公開されているか
• llms.txtが設置されているか（LLMがプロダクトの概要を把握するための標準フォーマット）
• MCPサーバーが提供されているか（Claude等のAIエージェントが直接接続するためのプロトコル）
• ドキュメントがマークダウンや構造化テキストで記述されているか（PDFやWordだけだと機械が読みにくい）

「ヘルプページはあります」「FAQは充実してます」――それは人間向けのドキュメントです。

エージェント向けのドキュメントとは、機械が解釈できるフォーマットで、プロダクトの全機能を網羅的に記述したものです。

人間向けのヘルプページしかないプロダクトは、エージェントにとっては「取扱説明書が外国語で書かれている」のと同じです。

条件5: エラー時にエージェントがリカバリーできるか

人間はエラー画面を見て、「あ、もう一回やり直そう」と判断できます。

エージェントはエラー画面を「見る」ことができません。

「なんかエラー出たっぽいな」という曖昧な判断もできません。

エージェントがリカバリーするためには、以下の設計が必要です。

• 明確なHTTPステータスコードとエラーメッセージ（400系/500系の区別、具体的な原因の記述）
• 冪等性のあるAPI設計（同じリクエストを2回送っても結果が変わらない）
• リトライ可能な設計（Rate Limitのレスポンスヘッダー、Retry-Afterの指定）

冪等性は特に重要です。

エージェントはネットワークエラーで処理が中断した場合、同じリクエストを再送します。

そのとき、「注文が2回入ってしまう」ような設計だと、エージェントは安心してプロダクトを使えません。

これ、人間相手なら「二重注文になっちゃいました、キャンセルしますね」で済む話ですが、エージェントが1日に1,000回リクエストを送る世界では致命的な問題になります。

エージェント対応度チェックリスト

5つの条件をまとめます。

ここまで読んで「うちはどうだろう」とモヤモヤしている方、このチェックリストで一発で整理できます。

自社プロダクトに当てはめてチェックしてみてください。

全部に対応できている必要はありません。

むしろ、今この段階で全部対応できているプロダクトがあったら、それはかなりの先進事例です。

大事なのは「今どこにいるか」を正確に把握することです。

現在地がわかったら、次は「どこから手を付けるか」ですよね。

ここからが、PMの本領発揮です。

PMとしてどこから手を付けるか ――AIエージェント対応のプロダクト戦略と優先順位のつけ方

ステップ1: 自社プロダクトの"エージェント対応度"を診断する

まずは上のチェックリストを使って、現状を棚卸ししてください。

ポイントは、「全部やらなきゃ」と思わないことです。

13項目のうち、対応済みが0個でも問題ありません。

「え、0個でもいいの？」って思いますよね。

いいんです。

重要なのは、「何ができていて、何ができていないか」を一覧にすることです。

自分がこれをやるときは、スプレッドシートに5条件を縦軸、チーム内のステークホルダー（エンジニアリーダー、デザイナー、CTO）を横軸にとって、それぞれの認識をヒアリングします。

「APIあるよね？」「外部公開してましたっけ？」という会話から始めるだけで、驚くほど認識のズレが見つかります。

このズレを可視化するだけで、ステップ1は完了です。

ステップ2: インパクト x 工数のマトリクスで並べ替える

チェックリストの結果が出たら、未対応の項目を「やるべき順」に並べます。

PMならお馴染みの、インパクト x 工数の4象限マトリクスです。

            インパクト 大
                │
    ロードマップ │  すぐやる
    に入れる     │ （Quick Win）
                │
  ──────────────┼──────────────
                │
    やらない     │  余裕があれば
                │
                │
            インパクト 小

  工数 大 ←─────┼─────→ 工数 小

「すぐやる」の典型例:

• APIドキュメントの公開（ドキュメントは書かれているが外部公開していないケース）
• llms.txtの設置（テキストファイル1つ追加するだけ）
• エラーレスポンスの標準化（既存APIのエラーフォーマットを統一する）

これ、地味にすごいのが「llms.txtの設置」です。

テキストファイルを1つ追加するだけで、エージェントからの発見可能性が劇的に上がります。

工数はほぼゼロ。

やらない理由がないですよね。

「ロードマップに入れる」の典型例:

• 外部向けAPIの新規構築
• OAuth 2.0認証フローの実装
• MCPサーバーの提供

「余裕があれば」の典型例:

• サンドボックス環境の構築
• APIのバージョニング戦略の整備

「やらない」の典型例:

• 自社のユースケースにエージェントの利用が想定しにくい機能のAPI化

ここで大事なのは、完璧を目指さないことです。

toAはまだ黎明期です。

全項目を一度に対応する必要はなく、Quick Winから着手して「エージェントに使ってもらえる最低限の状態」をまず作る。

そこからユーザー（エージェント）のフィードバックを見て、次の優先順位を決める。

いつもPMがやっていることと、実は同じです。

チェックリストと優先順位が決まったら、次はいよいよ最大の難関です。

ステップ3: ステークホルダーに"3行で"説明する

PMが一番苦労するのは、「なぜこれをやるのか」をステークホルダーに伝えるフェーズですよね。

「わかるわかる」と頷いている方、多いんじゃないでしょうか。

toAは概念としてまだ新しいので、「何の話をしてるの？」と返されることも多いはずです。

そこで、エレベーターピッチのテンプレートを用意しました。

コピペでそのまま使えます。

相手に合わせて使い分けてください。

経営層向け（3行）:

AIエージェントが自律的にサービスを選ぶ時代が来ています。 APIとドキュメントが整備されていないプロダクトは、エージェントの候補リストに載りません。 Stripe・Shopifyはすでに対応済みで、対応の遅れは競争力の低下に直結します。

エンジニアリーダー向け（3行）:

LLMベースのエージェントが外部APIを自律的に叩くユースケースが急増しています。 当社のAPIは現状、認証フローとドキュメント形式がエージェント非対応です。 まずllms.txtの設置とOpenAPI仕様書の公開から着手したいのですが、工数感を相談させてください。

デザイナー向け（3行）:

今後、プロダクトのユーザーは人間だけではなくなります。 エージェントにとっての"UI"はAPIドキュメントです。 人間向けのUXと並行して、エージェント向けの"体験設計"も考える必要が出てきます。

テンプレートをそのまま使ってもいいですし、自社の状況に合わせてカスタマイズしてもらっても構いません。

大事なのは「3行で伝わるレベルまで言語化しておく」ことです。

説明が長くなるほど、ステークホルダーの関心は薄れます。

ここまで来たら、あとはロードマップに落とすだけ。

でもその前に、もう一つだけ考えておきたいことがあります。

toAはチャンスか、脅威か、それとも"問いの立て直し"か

「で、結局toAってチャンスなの？ 脅威なの？」

PM同士の会話でこう聞かれたら、自分はこう答えます。

「どっちでもない。問いの立て方が変わるんだ」と。

これまでPMは「誰に、どんな価値を、どう届けるか」を考えてきました。

その「誰に」の部分に、人間だけでなくエージェントが加わる。

それだけのことです。

でも「それだけ」が、プロダクト戦略の前提を大きく揺さぶります。

• ユーザーリサーチの対象に「エージェントの行動パターン」が加わる
• UIデザインと並行して「API設計」がユーザー体験の一部になる
• NPS（顧客推奨度）のような人間ベースの指標だけでは、プロダクトの健全性を測れなくなる
• 競合分析に「エージェントからの選ばれやすさ」という軸が追加される

ここ、PMとして想像するとワクワクしませんか。

これまでの「ユーザー理解」のフレームワークが丸ごとアップデートされる。

新しい問いが生まれる。

それは、PMという仕事がまた一段面白くなるということです。

チャンスか脅威かは、あなたのプロダクトの現在地と、ここからの動き方で決まります。

エージェント対応を先行すれば、競合がまだ気づいていない新しいチャネルから流入が生まれます。

放置すれば、競合のプロダクトがエージェントに選ばれ、自社は候補にすら入らなくなります。

toAは「やるかやらないか」の問題ではなく、「いつやるか」の問題です。

そして、「いつやるか」を決めるのはPMの仕事です。

最後に一つだけ。

自分がPMとして一番大事にしていることがあります。

「それ、AIに壁打ちした？」

toAの対応方針も、チェックリストの優先順位も、ステークホルダーへの説明も。

自分の頭だけで考えるのは、もったいないです。

AIエージェントが顧客になる世界を考えるなら、まずは自分自身がエージェントと一緒に考えることから始めてみてください。

今日できる最初の一歩は、このチェックリストを開いて、自社プロダクトの現在地を確認すること。

そして明日、チームに「ちょっと5分だけ、この話させて」と切り出すこと。

そのほうが、きっと速いし、面白いですから。