AIが提案書を書く時代、PdMの本質的な価値をどこに置くか

はじめまして。ミツモア・ミツモアProでPdMを担当している、三ツ江です。

普段はプロダクトの価値向上に向き合う傍ら、組織の業務効率を上げるためのAIエージェントやBot、各種オートメーションの実装にも取り組んでます。

今更ではありますが、この時代、作業というのはことごとくAIに代替されました。そして、これまで当たり前のように頭と手をフル稼働して作成していた提案書や要件定義書も例外ではないです。

このAI時代、目の前のイシューに向き合ってメンバーと議論しているだけで、それらが勝手に生成されるようになった。（正しくは生成されるような仕組みを作れるようになった。）

つまり成果物は「作る」ものではなく、「こぼれ落ちる」ものになった。

意図して作るものではなく、勝手に出来上がるものになった。

この記事は、コードを書かない一人のPdMが、それを実現するシステムを自作してみた話です。

時間あたり業務効率が飛躍的に伸び、可処分時間が膨大に増えたからこそ、これからのPdMはプロダクトに対してどのように向き合っていくべきなのか。そもそもAI時代におけるPdMとは何なのかを改めて見つめ直したいと思い、この記事を書いてます。

結論から言うと、この「こぼれ落ちる」は半分だけ実現しました。何が実現し、何が実現しなかったのかを、正直に書きます。

なぜ作ったのか ──「作業に分解できるなら、AIで良い」

きっかけは、けっこうたまたまでした。タイミングが噛み合ったからです。

まず大前提として、私はめんどくさがり屋です。そして、作業が嫌い。提案書や要件定義書の作成というのは、5W1Hを気遣い、正しい表現で、見やすい構成で、自分の持つ抽象的な概念やイメージを、明確な言葉で言語化する作業。これが甚だめんどくさい。

めんどくさい単純作業を積み上げた結果、成果物として提案書や要件定義書が完成する。しかも、アイデアの解像度や資料の品質には「個人のパフォーマンスによるブレ」がつきまとう。

アイデアの発散も、資料づくりも、突き詰めればすべて「作業」に分解できる。作業に分解できるなら、ルールにできる。ルールにできるなら、AIに任せて良い――。

そんなことを思っていた矢先、私の所属する部署でAI-DLCの導入検討が行われていました。

（他部署ですがAI-DLCについて言及してる記事があるのでこちらもどうぞ）

私自身が抱いていた課題感と、事業部の短期目標が、「たまたま」噛み合った瞬間です。

追い風もありました。Claude Codeの躍進でローカルファイルの制御やMCPの活用が進み、ドキュメントを集約していたNotionもAIで飛躍的に進化した。おかげで「高度なコーディングスキルがない自分でも実装できるなぁ」という像が、高い解像度で描けた。これが、重い腰を上げるのに十分な理由でした。

遅かれ早かれ自動化される仕事だとも思っていたので、とりあえず手を動かしました。

どう作ったのか ── 工程ごとに"専門家"を置き、狙って起動する

仕組みの肝は、ひとつです。工程ごとに"専門家"を置き、その一人だけを狙って起動する。

具体的には、次の3段階に専属のエージェント群を配置してます。実装やQA、データ分析は、今回の主役にはしません。

アイデアの具現化を担うエージェント群（7体）
提案書の作成を担うエージェント群（8体）
要件定義書の作成を担うエージェント群（16体）

設計で意識したのは、「一気通貫で流す」のではなく「工程を決めて、その専門家だけを確実に起動する」ことです。曖昧に呼び出すのではなく、決まった手順でその担当だけを"確実に発火"させる。「今日はこの工程」と決めて、担当の専門家だけを立ち上げる、というイメージです。

そして、いちばんの肝が「副産物の仕組み」です。会議の会話を録音して文字起こしし、それを入力にする。するとAIがその会話を「資料の編集項目」へと変換し、提案書や要件定義書に落とし込む、あるいは既存の資料を編集していきます。それにより、"資料を作ろうとしていない会話"から、成果物がこぼれ落ちるという設計です。

何が変わったのか ──"時短"ではなく"並列化"という本質

結論から言うと、一番の変化は、"速くなったこと"ではありません。

もちろん、速くはなりました。ここから挙げる数字は、実装範囲や規模による概算で、あくまで体感値ですが、一人で作ろうと思えば丸2日相当かかりそうな分量が3〜5時間ほどでできるようになり、結果、1週間で提案資料を3〜5本つくることが、現実的になりました。

ただ、これには大事な注釈があります。

この3〜5時間には、AIが生成している最中の待機時間も含まれています。実際に自分が手を動かしている時間は、もっと短い。

なので、私が思うに、「所要時間の削減は本質ではない」です。

真の価値は、この"空いた待機時間に、別の施策のAI-DLCを回せること"にあります。

つまり並列化（＝マルチタスク）です。

「”マルチタスクが出来る（と言われてる）”人は、実は行っているのはマルチタスクではなく、シングルタスクを高速にさばいているだけ」と良く言われます。私もそう思ってます。

でも、そういう話ではありません。文字どおり、複数の施策を同時に進められる。それが最大の強みです。

思わぬ落とし穴 ──このシステムには向き不向きがある

しかしこのシステムは、当初の狙いそのままでは実務に載りませんでした。

もともと想定していたのは、「みんなで会話し、その会話をAIが読み取って資料化する」という設計でした。明確な意思決定者を置かず、"みんなで決める"民主的なMTGを主軸にしたワークフローです。（もちろん最終的な意思決定として議論を束ねるファシリテーターやオーナーポジションは存在します。）

ところが実地で強く出たのは、メリットの裏返しでした。

「MTGをするだけで副産物として資料ができる」はずが、裏を返せば「MTGをしないと資料ができない」。この"みんなでモード"だけに頼ると、参加メンバー全員が次回もそろって集まれる確証はなく、日程が合わずに次のMTGまで空くと、資料づくりのテンポが一気に落ちてしまいます。人が集まらないと前に進まない。言われてみれば当たり前の話ですが、当時は盲点でした。

そこで、この"みんなでモード"を置き換えるのではなく、発案者とAIが1対1で会話し、一人でも資料を作り込める機能を追加しました。

これが、思いのほかうまく噛み合いました。2つのモードは、補完し合うようになったんです。MTGまでは1対1（AIと一緒）でも黙々とPRDの粒度が上がり、さらにMTGをもって異なる観点からのレビューがPRDをさらに醸成させる。みんなでも、一人でも、どちらからでも資料づくりが前に進む。片方が廃れたわけではありません。両方がかみ合って、AI-DLC全体がバランスよく、現実的なハードルで回るようになりました。

冒頭で「半分だけ実現した」と書きました。正直に言うと、"会話が成果物にこぼれ落ちる"という仕組み自体は、ちゃんと実現しています。

実現しきれなかったのは、「ただ会話するだけ」という、当初いちばん描いていた"手軽な入り口"のほうです。単一のモードだけでは利用ハードルが高くて回らない。モードを足して、ようやく実用のハードルに収まった。ここが「半分」の正体です。

ただ、残る宿題もあります。

言語の壁です。弊社では、英語を話す海外圏のメンバーと、日本語を話すメンバーが混在します。音声文字起こしのツールは大抵の場合、取得する言語設定を事前に決める必要があるため、1つのツールで多言語対応させた文字起こしをするのは現時点で難易度が高いです。

なので、複数人での会話を主軸にする"みんなでモード"には、向いてる組織、不向きな組織が必ず存在すると感じました。だからこそ、一人でも進められる入り口を併せ持たせることが、実務に載せる鍵になります。

ただしAIは日進月歩で、数か月に一度、ゲームチェンジャー級のアップデートが当たり前に起きる時代です。改めて解決策を講じれば、この結論はいずれ覆るかもしれません。

エンジニアへの接続 ──"情報量は多いほど良い"という逆張り

このAI-DLCの目的は、「高品質なPRDを、再現性高くつくるAIワークフローの構築」です。このゴールを満たせているかどうかを判断するための重要指標として、「PRDを読み込んだエンジニアが、TRD（技術要件定義）をスムーズに書けるか」があります。

PRDには、フロントやクライアント寄りの、表面的な技術要件が並びます。それを読んだエンジニアが、バックエンドやインフラ寄りのTRDに落としていく。

だとすれば、PRDの情報がいかに詳しく、正確に、読みやすく整理されているか。ここがPRDの重要命題になるのは、最初から自明でした。なので、「高品質なPRD」たらしめる要素を、3つに定義しました。

「網羅性」「情報深度」、そして「デザインモック」です。

まず、網羅性と情報深度ですが、これまでは、読み手を思って「短く、スマートに書く」ことにPdMが多くのリソースを割いてきたと思います。PRDにおける「簡潔さ」と「網羅性」のジレンマに悩んできたPdMは、多いのではないでしょうか。

でも、このAI-DLCはむしろ逆です。情報量は、多ければ多いほど良い。読みやすさは、文章を削ることではなく、構成で担保する。この基本理念で動かしています。おかげでPRDは、これまでの比にならないテキスト量になりました。ただ、これで良いと思ってます。

なぜなら、TRDもAIが書き、それを人が確認する未来が、確実に来るからです。LLMは大量のデータを扱って整理するのが得意です。だから文字数は、もう論点になりません。どれだけ抜け漏れなく網羅できているか。1項目あたり、どこまで深く考察できているか。そこを隈なく落とし込むことが大事なんです。

とはいえ、です。そのPRDを読む「人」の目線に立ったら、これは本当に良いPRDなのか。もちろん、人が全文を読むには、少々分量が多すぎます。AIに要約させたり、体系的なインプット資料をつくってもらって、それを読む。そういう工夫も要ります。ただ、AIの要約には抜け漏れがありますし、何を重要な情報かと見極めるにはそれ相応のドメイン知識も要る。

そこで活きるのが、3つ目の「デザインモック」です。このAI-DLCには、デザインモックをつくる機能と、できあがった（もしくは既に制作済み）デザインモックをPRD資料の要素として落とし込む機能があります。すると、関わる全員が、同じ完成イメージを持てます。

なにより、頭への情報の入り方が変わります。「何を作りたいか」のビジュアルが先に入って、その補足としてPRDのテキストがある。この順番だと、入り方がまるで違います。効率よく、正確にインプットが進む。結果、エンジニアがTRDを書くときの摩擦が、大幅に減りました。

これが、このAI-DLCのすごみの一つだと思ってます。

最後に──”AI時代”のPdMの本質的な価値

正直に振り返ると、AI-DLCを実務に載せる鍵は"利用ハードルの設計"にありました。これが、この実験でいちばんの学びです。副産物化そのものは、仕組みとしてちゃんと成立します。ただ、当初描いた単一の入り口だけでは利用ハードルが高くて回らず、モードを足して、ようやく実用のハードルに収まった。ツールの限界が見えたからこそ、逆に人がどこに立つべきかが、かえってはっきりしてきた気がします。

AIが提案書を書く時代、PdMの本質的な価値をどこに置くべきか。私の答えは、"より上流、かつ複数の変数を考慮した意思決定"です。

もちろんPdMの定義や役務内容は事業者ごとに異なりますが、本質は「プロダクトの価値を最大化する」ことだと思います。

ただ、これまでのPdMは、”現在のイシュー”に向き合ってきました。足元のペインを解消するために、その時々の最適解を形にする仕事です。これからは、”未来の起き得るイシュー”に向き合う必要が出てくると思っています。未来というのは不確定なもので、それを不確定たらしめているのが”変数”です。

ここでいう変数とは、プロダクト内部のKPIのような下流のものから、市場のマクロトレンド・経営戦略・協業先といった上流のものまで、幅広く存在します。そして上流の変数が変わると、それに追従するように下流の変数も変わります。

大事なのは、実際にその経営判断に関わっていなくとも、その上流変数を考慮に入れるか、入れないか。つまり視座を上げられるかどうかで、これからのPdMの価値は大きく変わりそうです。

つまり変数とは、プロダクトがとある着地をした”理由”にあたるものであり、現在の足元の課題と、未来に起き得る課題、そしてそれらをもたらす理由──。

無数に広がる、ウェブのような関係相関図の中から、プロダクトグロースに最適な変数を導き出し、その変数を考慮した最適な意思決定を行っていくことが重要だと思います。

とどのつまり、事業目標に従った役務ではなく、”次の目標を決める”役務をおこなう。それが、AI時代のPdMだと思っています。

AI-DLCは、あくまで品質のブレを抑えるためのツールに過ぎず、意思決定を人がやる以上、そこで生まれるアウトプットには必ず差が出ます。そのくせ、人間が出すアイデアは、過去の経験や定石から結ばれた"予想可能な範疇"のものでしかありません。それをAIに食わせれば、再現は容易です。なので、これまでPdMの得意とされてきた「発想力」の価値も、次第に薄れていくでしょう。

なのでこれからは、プロダクトグロース戦略やマーケティング（ブランディング）といった、事業成長のコアエンジンを、進みたい方角・速さ・地形に合わせて適応させていくことに軸足を移していくのが重要だと私は考えます。