AIとPMで回す 3倍速いプロトタイピング

こんにちは。estieでプロダクトマネージャー（PM）をしている高橋です。

このブログは「PM Blog Week」第6弾・3日目の記事です。3月24日、27日に開催予定のMeetupに向けた連載の一部としてお届けしています。
≪過去の PM Blog Week の記事はこちら ≫

皆様におかれましては、ますますAI活用の進む毎日をお過ごしのことと存じます。私もただただ、好奇心にまかせて使い倒すのが楽しくて仕方ない今日このごろです。たとえこの先、PMという職務が消滅するとしても。

小規模チームのPMが抱える課題

さて、現在estieのプロダクト開発は、小規模なチーム単位で進められています。私が担当するプロダクトも例外ではなく、PM1名・デザイナー・エンジニア数名という限られた体制で、運用と新規開発の両方を担っています。

小規模チームのPMには、常に一つの課題がつきまといます。
少ないエンジニアのリソースで、いかに多くの顧客価値につながる検証と実装を繰り返すか？ということです。

企画したものが本当に顧客にとって価値があるかは、実際に触ってもらわないとわからない部分が大きいです。
しかし、その検証のためにMVPやモックアップを都度開発チームに依頼すれば、確度の高い案件のデリバリーが遅れてしまいます。

ですが2026年現在、我々にはAIという最高の武器があります。なんでも自動化して、最小の工数で最大の価値提供を行いたい！

初期の試行錯誤：企画を速くする

最初に考えたのは、企画書（PRD）の執筆速度を高速化できないか？ということでした。
Cursorなどを使うことで、これまでの機能要望やユーザーヒアリングをもとに、普段使っているテンプレートにPRDを落とし込むスピードを格段に上げることができます。

しかし企画書がいくら増えても、顧客に見せられるのは箇条書きの質問票がせいぜいです。
効果的な検証に進めるのは難しいと判断しました。

次の試行錯誤：AIで開発しても、コードレビューの負担がある

次に開発側のタスク消化を高速化できないか？と考えました。

いくつか顧客要望の対応を引き取り、Devin（自然言語の指示からコードを自律的に生成・実行できるAIソフトウェアエンジニア）で対応してみることにしました。ユーザー要望をもとに、自然言語で指示するだけでコードが次々と生成されるので、実装スピード自体はかなりのものです。estieにはプルリクエストの内容から動作確認ができる機能も整備されており、品質面も悪くなさそうでした。

ただ、ここにも壁がありました。コードレビューです。

2026年現在、開発の全体像を十分に理解していないPMがAIに指示を出しても、出てくるコードの品質にはどうしても限界があります。また、AIが書いたコードは、結局エンジニアにレビューしてもらわなければ本番には出せません。

企画を速くしても、開発だけを速くしても、結局ボトルネックが別の場所に移るだけでした。

転換：30分で"触れるプロトタイプ"を作る

そこで試したのが、Streamlit in Snowflake（Snowflake上で直接Streamlitアプリを構築・実行できる機能）やClaudeのArtifact（対話の中でUIやコードをその場でプレビューできる機能）でした。

ある日、営業メンバーからヒアリングした内容の詳細を確認するためにClaudeと対話していると「この手順は自動化できるのでは？」と思いつきました。そのままArtifactのコードを書いてもらうと、画面があって、ボタンが押せて、ファイルを読み込んでデータを反映できるプロトタイプを、およそ30分で形にすることができました。

企画書を書くよりも短い時間で、「触れるもの」が手に入る。この体験は想像以上のインパクトがありました。

PMのDiscoveryと開発チームのDeliveryが分離できた

冒頭触れた通り、これまでは、PMが本格的な検証をしようとすると、MVP開発のために開発チームの手を借りる必要がありました。その間、その他の開発は止まります。小規模チームにとってこれは痛手です。

今は、PMが課題発見から要求整理、プロトタイプ開発、顧客への提案・フィードバック収集までを一人で回せます。企画の検証サイクルが、開発チームのリソースを食わずに回るようになりました。

開発チームは検証済みの機能の本開発に集中できる。PMはその間に次の仮説を検証できる。PMのDiscoveryサイクルと、開発チームのDeliveryサイクルが分離できたことが、小規模チームにとって一番大きな変化でした。

「対話」の打席が、体感3倍になった

企画からプロトタイプまでを一人で完結できるようになり、顧客との対話に至るスピードは確実に上がりました。

ただ、振り返って一番大きかったのは、スピードよりも検証の打席数が増えたことです。
プロトタイプの制作工数が劇的に下がったことで、まったく別の顧客をターゲットとした機能の検証を複数同時に走らせられるようになりました。今は以前と比較して体感で3つの異なる機能を並行して検証しています。

しかも、プロトタイプは「触れるもの」なので、顧客の反応が具体的です。「あったら便利かも」ではなく、より解像度の高い顧客からの期待感や、具体のフィードバックを得ることができています。

estieで新しい開発スタイルを模索する

私たちのチームでは、この「AI×プロトタイプ」の開発スタイルはまだ模索の途中です。
プロトタイプから実装に移す過程で何が起こるか、まだ見通し切れていません。
またお恥ずかしいことですが、プロトタイプを量産できてしまうがゆえに「なぜ作るか？」が曖昧になってしまうこともあります。PM自身のクライテリア強化も必要です。

ですがAIをうまく活用することで、社内の他職種とも連携しながら、より質の高い検証を重ねられる可能性を感じています。