PMのための「AIエージェント仕様書」——VCが10億ドルを張ったtoA時代の7項目

こんにちは、仕様書を書かないPM@カイです。

「AIエージェントが顧客」って、まだピンと来ないですよね。

経営会議で「うちのプロダクト、AIエージェント対応どうなってるの？」と聞かれて、一瞬固まった経験ありませんか。

私は去年、まさにそれをやらかしました。

「ええと、API公開はしてますけど……」と返したら、CTOから「で、エージェントが安全に決済まで完走できる設計になってるの？」と追撃されて、議題ごと撃沈です。

あのとき痛感したのは、「APIを公開している」と「エージェントが使える設計になっている」はまったく別の話だ、ということでした。

そこから半年かけてPMの仕様書を書き直しました。

今回はその内容を共有します。

この記事で得られるものを先に言っておきます。

• なぜ今、PMが「AIエージェント仕様書」に手を入れるべきかの納得材料
• AIエージェントを「顧客」として扱うときの設計フレーム
• PMが今すぐPRDに追加すべき7項目（うち1項目はテンプレを完全公開）

5,000文字超の記事ですが、コピペで使えるテンプレ込みなので、自社のPRDを開きながら読むのがおすすめです。

明日の経営会議で7項目に即答できる状態になれます。

それでは入っていきますね。

VCが10億ドルを投じた「AIエージェント経済」とは何か

ここで少し興奮した話をさせてください。

折しも2026年5月4日、Haun Venturesが新規10億ドル（約1,500億円）の調達を発表しました。

投資テーマの1つに「AIエージェント経済（Agentic Economy）」が掲げられています。

VCが10億ドルを張る、ということの意味をPM視点で考えると、「予測ではなく確信がある」という信号なんですよね。

予測で10億ドルは張りません。

Haun Venturesが示した3つの投資テーマ

3つの投資テーマは、それぞれ独立しているように見えて、実は1本の線でつながっています。

• 1.新しい金融インフラ
• 2.新しい資産と市場（ステーブルコイン・トークン化資産）
• 3.AIエージェント経済（Agentic Economy）

• 金融インフラ → エージェントが取引できる土台
• 新しい資産と市場 → エージェントが扱える流動性（ステーブルコイン等）
• AIエージェント経済 → 上2つを使う「主体」としてのエージェント

「AIが取引主体になった世界の、上から下までを総取りする」という張り方なんです。

これはかなり構造化された賭けで、インフラ・流動性・主体の3層をセットで抑えにきている。

こういう張り方をするのは、「来るかもしれない」ではなく「来ると決めた」側の動きです。

「エージェント向けの支払い・信用・身元確認」がなぜ必要か

CEOのKatie Haunさん（元連邦検事、Coinbase取締役・Andreessen Horowitz General Partner出身のVC）の主張をかみ砕くと、こうなります。

「エージェントが24時間365日、自律的に支払い・取引する世界では、詐欺防止・与信・本人確認・認証・評判・プロベナンス（来歴）を、エージェント向けに再設計する必要がある」

人間向けに作られた既存の金融インフラは、AIエージェントには向きません。

いわば、「左ハンドル専用の道路に右ハンドルの車を走らせようとしている」ような状態です。

• 認証: 人間用のIDとパスワード、SMSのワンタイムコード → エージェントは入力できない
• 与信: クレジットカードの限度額は「人間のリスク」で算出 → エージェントの行動量に対応していない
• 詐欺検知: 「夜中に大量に決済」は通常フラグ → エージェントは24時間動くので誤検知だらけ
• 身元確認: 顔認証や免許証 → エージェントには使えない

ここを再設計しないと、エージェント経済は離陸しない。

VCがここに張る理由が、とても腑に落ちますね。

toAシリーズで主張してきたことが、VC視点で裏付けられた

実はこれ、私がこのシリーズで予言してきた話が裏付けられた瞬間で、内心ガッツポーズしてました。

シリーズ第1弾で「AIエージェントが顧客になる時代＝toA市場が来る」と書いて、第2弾で「AIエージェントが人間の専門家を雇う」というHumworkの事例を紹介して、第3弾で「Cloudflare+Stripeがすでにインフラを敷き始めた」と整理してきました。

そして今回、VCが「ここに張る」と10億ドル分の意思表示をした。

流れがそろってきたんですよ。

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

こんにちは、カイ@プロダクトマネージャーです。「うちのプロダクト、ユーザーに愛されてるし、NPSも高い。当面は大丈夫でしょ」――そう思っていたのに、気づいたら競合にシェアを取られていた。しかも、取っていったのは人間のユーザーじゃない。AIエージェントです。toC、toB――プロダクトの届け先を語るとき、私たちPM...

aimanavo.com

「toAという概念がそもそもピンと来ない」という方は、まず第1弾を先に読むと、この後の話がスッと入ると思います。

では、「そのエージェントを顧客として設計する」とは何か。ここを具体的に整理しますね。

AIエージェントを「顧客」として設計するとはどういうことか

少し立ち止まって考えてほしいのですが、「AIエージェントが顧客」という言葉を聞いたとき、最初に頭に浮かぶイメージは何ですか。

「なんとなく、APIを叩いてくるやつ」くらいの解像度だと、設計が根本的にズレます。

ここで定義を合わせておきますね。

人間顧客と何が違うのか（速度・スケール・プロベナンス）

人間顧客とAIエージェント顧客の違いを一覧にしました。

この表を見るとわかるように、「速度」「スケール」「稼働時間」の3つだけで、既存の設計前提がほぼ全部崩れます。

たとえば「夜中の大量リクエストは不審」という不正検知ロジック、エージェントが相手だと即誤検知です。

「人間と同じUI・同じ要件」で設計してしまうと、エージェントが入ってきた瞬間にあらゆるところで詰まる。

逆に言うと、ここを先に設計し直したプロダクトが、エージェント時代の選ばれる側に立てます。

面白いのが、エージェント前提で設計し直すと、人間顧客の体験も底上げされるところで。

たとえば「APIに予算上限を設定できる」という機能は、AIエージェントに必須なんですけど、実は人間ユーザーにも便利なんですよ。

Humwork事例——AIエージェントが人間の専門家を「雇う」現実

「エージェントが顧客」という話をすると、「でも実際そんなサービス、動いてるの？」と返ってきます。

動いてます。しかもYCがバックしています。

Humworkは2026年Y CombinatorのSpring 2026バッチ採択スタートアップで、公式サイトに記載されている数字がエグいんですよ。

• AIエージェントがコードや法律の判断で詰まったとき、30秒以内に人間の専門家とつながる
• 公式サイトに記載されている最新の解決率は83%（「人間とAIの会話」で問題が解決）
• 専門家への支払いはAIエージェント側がする（つまり、AIエージェントが顧客）

「AIエージェントがお金を払って人間を雇う」という構図、5年前なら絶対あり得なかったですね。

でも今、現にYCがバックして動いている。

AIエージェントが自ら専門家を雇う時代——YC採択スタートアップHumworkが示すtoA市場の現実

仕様書を書かないPM@カイです。AIでPM業務の8割を自動化し、意思決定に集中する働き方を実践中。PRD、競合分析、ユーザーインタビュー分析をAIと共同で行っています。「toAって結局ふわっとしてない？」前回あの記事を書いたとき、正直そう思っている読者が一定数いるだろうと感じていました。前回の記事はこちら↓概念は...

aimanavo.com

PMから見ると「AIエージェントが顧客になる」だけじゃなく、「AIエージェントが発注者になる」ケースもある、ということです。

これ、ステークホルダーマップを書き直す必要が出てくるんですよ。

Stripe Agentic Commerce Suiteが先に動いている

では、そのエージェントが安全に取引するインフラはあるのか、という話です。

あります。すでに動いています。

Stripeはすでに「Agentic Commerce Suite」というエージェント向け決済プリミティブを公開していて、Shared Payment Tokens（SPT）という、エージェント専用の限定権限決済トークンが利用可能です。

Cloudflareは4月のAgents Week（4月13〜17日）にエージェント向けの認証・本人確認・支払いの基盤を発表していて、Stripeも4月末のSessions（4月29〜30日）で関連発表を行いました。

インフラ側はもう動いています。

つまりPMからすると「エージェント向け決済の土台はすでにある。あとは自社プロダクトの仕様書をどう書き換えるか」という段階に来ているわけです。

Cloudflare+StripeでAIエージェントが「顧客」になった──toA時代にPMが今すぐ設計すべき7つのプロダクト戦略

「toAって何するやつなの？うちのプロダクト、何を変えればいいの？」──先週のMTGでそう聞かれて、答えに詰まりませんでしたか。Cloudflareのあの投稿、見ました？2026年4月、AIエージェントが自分でCloudflareアカウントを作成し、有料プランを契約し、ドメインを買い、APIトークンを取得してコー...

aimanavo.com

第3弾では、5レイヤー（Identity / Runtime / Interface / Memory / Settlement）と7つのtoAネイティブプロダクト戦略を整理しています。

「自社のどこを最初に動かすか」を決めるときに、ぜひ一度目を通してください。

ここまでで「なぜ今か」が腹落ちしたと思います。

ではいよいよ、「何を仕様書に書くか」です。

PMが「AIエージェント仕様書」に今すぐ追加すべき7項目

ここからが本題です。

PMが今、PRD・要件定義書・仕様書のどこかに必ず追加すべき7項目を整理しました。

シリーズ3本でずっと「概念」を扱ってきましたが、ここでは具体的な仕様書の文言まで降ろします。

7項目の全体像

まず俯瞰してください。

• 1.エージェント向け認証——OAuthスコープと delegated trust 設計
• 2.エージェント向け予算枠と与信——payment tokenによる権限制御
• 3.エージェント向け本人確認・プロベナンス——暗号署名による「誰が呼んだか」の検証
• 4.APIレート設計——エージェントのバースト性に対応する非対称レート
• 5.詐欺防止——agent fingerprintingと行動ベースリスクスコア
• 6.監査ログと冪等性——「誰が・いつ・何を」の完全トレーサビリティ
• 7.価格設計——per-call / subscription / outcome-basedの選定

それぞれ独立した話題に見えるんですけど、実は1〜7の順番通りに設計すると整合性が取れます。

認証ができないと与信が設計できない、与信ができないと詐欺防止のしきい値が決まらない、というふうに、上から下に依存関係があるんですよ。

設計フレームとして「依存関係の上流から順に手を付ける」のが鉄則で、ここを無視して「詐欺防止だけ先にやろう」とすると後から設計が崩れます。

これ、AIに壁打ちすると論点がさらに鋭くなりますよ。

「自社プロダクトに当てはめると、まず最初にどこを動かすべき？」と聞いてみてください。

それでは項目2「エージェント向け予算枠と与信」を完全公開します。

残り6項目も、これと同じ構造（PRDテンプレ + 経営層説明 + 判断フロー + 失敗パターン）で揃えています。

【完全公開】2. エージェント向け予算枠と与信——Stripe Wallet for Agents的発想

なぜ項目2を完全公開するかというと、AIエージェント経済の話を「金銭」という最も具体的な形で体感できるからです。

「AIエージェントが顧客」という抽象を、「予算枠を持ったAI」という具体に落とし込めれば、残り6項目もイメージしやすくなります。

a) PRDテンプレ（コピペ可能）

そのまま自社のPRDテンプレに貼り付けてください。

明日のPRDレビューでそのまま使えます。

## 機能要件: AIエージェント向け予算枠と与信制御

### 概要
本機能は、AIエージェントが本サービスのAPIを通じて自律的に課金行動を取る際、
予算枠を事前に設定し、超過時の挙動を制御する。
これによりユーザーの意図しない大量課金・乗っ取り時の被害拡大を防ぎ、
かつエージェントの自律性を損なわない範囲で取引を許可する。

### 必須要件
- 1. 予算上限設定: ユーザーは1エージェント・1サービスあたり、
     月額・日額・1取引あたりの上限金額を設定可能とする
- 2. Payment Token方式: カード番号や恒久的な決済情報をエージェントに渡さず、
     用途・期間・金額が制限された短期トークンを発行する
- 3. 取引承認フロー:
     - 予算上限の80%超過時にユーザーへ通知
     - 100%到達時に自動停止し、ユーザーの追加承認を求める
- 4. ロールバック: ユーザーは任意のタイミングでpayment tokenを失効可能。
     失効後はエージェントからの取引が即座に拒否される
- 5. 監査ログ: すべての取引にエージェントID・呼び出し時刻・金額・対象サービス・
     payment token IDを記録し、ユーザー画面で参照可能とする

### 付帯要件
- payment tokenは1エージェント・1サービスごとに発行する
  （複数サービスをまたぐトークンは発行しない）
- 月額予算のリセットタイミングはUTC 0:00を基準とする
- ユーザーへの通知はメール・アプリ内通知の両方で行う
- 予算枠は一時的に手動増額可能（増額には2要素認証を必須とする）
- API側からpayment tokenの残高・期限を照会できる機能を提供する

### 非機能要件
- payment token発行のレイテンシ: 99パーセンタイルで500ms以下
- 監査ログの保持期間: 法定保存期間+1年
- 予算枠超過判定の精度: 99.99%（同時並列リクエストでも超過を許可しない）

ポイントは3つです。

エージェントに「制限なしの権限」を渡さない。ユーザーが任意のタイミングで止められる。すべての取引を後から追跡できる。

この3つを仕様書に明記するだけで、認証チームとの設計議論が一気に前に進みます。

「どこまで制限するか」「止める条件は何か」という話が、このテンプレを見ながらすると30分で決まります。

b) 経営層への説明テンプレ（3行）

経営会議で説明するときは、難しい言葉を使わずに3行で伝えるのがコツです。

何を: AIエージェントが本サービスを「予算枠の中で自動的に」使えるようにします。
なぜ: エージェント経由の取引が今後増えるなか、与信なしで開放すると大事故が起きるからです。
リスク: 既存ユーザー体験は変えません。予算ゼロ運用にすれば従来と同じです。

「リスク」のところで「既存ユーザーには影響しない」と明示するのが大事で。

経営層は「今動いているものを壊さないか」を一番気にしますからね。

このテンプレ、私が実際の経営会議で使って「わかりやすい」と言われたやつです。

c) 自社適用判断フロー（5ステップ）

自社プロダクトに当てはめる際は、上から順番に答えていってください。

1. 自社サービスはAPI経由で課金が発生するか？ → Yesなら必要
2. 1回あたりの課金額はいくらか？ → 100円以上なら必須、10円未満なら後回し可
3. ユーザーごとの取引頻度は1日何回か？ → 10回超なら予算枠が必須
4. payment tokenを実装する基盤はあるか？ → Stripe等の主要決済を使っていればすぐ可能
5. 監査ログ基盤はあるか？ → なければここから整備（最も時間がかかる）

5ステップ目（監査ログ基盤）が一番時間を食うので、そこから着手するのが現実的です。

「Stripeを入れているからすぐできる」と勘違いしがちですけど、監査ログを後回しにすると後々大事故になります。

経験談です。

d) 失敗パターン（PMが避けるべき罠）

やってしまいがちなパターンを正直に書いておきます。

• 予算枠だけ作って通知を作らない → ユーザーが気づかないうちに上限到達。「使えなくなった」というクレーム頻発
• payment tokenを永続化する → 失効フローを後回しにすると、エージェント乗っ取り時に被害が拡大する
• 予算上限を硬直的にする → 業務拡張時にエージェントが止まり、現場から「なぜ硬直的なのか」と突き上げられる
• 監査ログにエージェントIDを記録しない → 不正発生時に「どのエージェントが何をしたか」を追跡できない
• 経営層に「セキュリティ強化」とだけ説明する → 「で、ビジネス上の意味は？」と返されて議論が止まる

特に最後、経営層への説明はビジネス価値（新しい収益機会）と一緒に出すのが効きます。

「セキュリティのための投資」ではなく「エージェント経済に乗るための投資」として提案する。この言い換えだけで、通りやすさが変わります。

e) チャレンジ

ここまで読んだあなたへ、1つお願いです。

このPRDテンプレを、いま手元のPRDツール（Notion・Confluence・Google Docsなど何でも）に貼り付けて、自社プロダクトに当てはまるかを10分考えてみてください。

「自社サービスはAPI経由で課金が発生するか？」から順に5ステップ書いてみるだけです。

それ、AIに壁打ちするとさらに論点が鋭くなります。「うちのプロダクトの場合、ステップ3で詰まりそう。なぜ？」と聞いてみてください。

ここまでが項目2の完全テンプレでした。

残り6項目（認証・本人確認・APIレート・詐欺防止・監査ログ・価格設計）も同じ構造で揃えています。

同じ品質で残り6項目を揃えるコスト

「自社で7項目をゼロから作る」「外部に依頼する」「この記事の有料エリアを使う」、それぞれ実際にいくらかかるかを比較してみました。

コンサルに頼むと最低でも600万円、最大1,500万円です。

この記事はコンサルの代替ではありません。ただ「社内で議論を始める一次資料」「PRDのたたき台」としては、一杯のコーヒー以下のコストで同等の出発点に立てます。

ここまでで、項目2「予算枠と与信」のテンプレを手に入れていただきました。

ではここで、1つ問いを置かせてください。

もし明日の経営会議で「うちのプロダクト、AIエージェント対応どうなってるの？」と聞かれたとき、いまのあなたは7項目すべてに即答できますか？

項目2のテンプレを手に入れた時点で、あなたはすでに「エージェント対応を考えているPM」の側にいます。

残り6項目（認証・本人確認・APIレート・詐欺防止・監査ログ・価格設計）は、それぞれ項目2と同じレベルのPRDテンプレ・経営層説明・判断フロー・失敗パターンを用意しています。

「項目2だけ」で持ち帰っても十分役に立ちます。

ただ、PRD全体を「エージェント対応」で書き直すなら、6項目分まとめて手元に置いた方が早いです。