AIを使ってひとりでプロダクトをつくるプロセス：アイデアからリリースまで

以前は、プロダクトひとつをつくるのに、それぞれ別の役割を担う何人もの人が必要だった。いまはAIのおかげで、ひとりでもユーザー調査、企画、デザイン、開発、テスト、ドキュメント作成までをすばやく行き来できる。だからといって、AIがチーム全体の代わりになってくれるわけではない。むしろ、ひとりでつくる人の肩には、より多くの判断と責任がのしかかってくる。

私が考えるAIを活用したひとりでのプロダクト開発の核心は、コードを速く生成することにはない。解くべき問題を絞り込み、余計な作業を減らし、実際のユーザーに届くまでの時間を縮めることにある。この記事は、アイデアを思いついた瞬間からMVPを公開してフィードバックをもらうまでに、私がたどっているプロセスをまとめた記録だ。

AIは共同創業者ではなく、スピードを上げるための道具だ

AIに「いいサービスのアイデアを教えて」と聞けば、それらしいリストがすぐに手に入る。問題は、そのリストが私の経験も、私が実際にアプローチできるユーザーも、私が負担できるコストも知らないことだ。

だから私は、AIを共同創業者のようには扱わない。そのかわり、役割のはっきりした何人ものアシスタントとして使っている。

• リサーチアシスタント：市場と競合プロダクトをざっと見渡す。
• 企画アシスタント：要件を整理し、抜けている条件について質問する。
• 開発アシスタント：小さな機能を実装し、コードを説明する。
• テストアシスタント：失敗しうるケースとテスト項目を洗い出す。
• 編集アシスタント：ランディングページや案内文、ドキュメントを整える。

最終的な決定権は、いつも自分の手元に残しておく。この線引きがないと、生成のスピードは上がっても、プロダクトはいとも簡単に見当違いの方向へ大きくなっていく。

1. 解決する問題を一文で定義する

プロダクトをつくる前に、まず次の文を完成させる。

[どんな人]が[どんな状況]で抱えている[具体的な問題]を、[どんな方法]で減らす。

たとえば「AIのスケジュール管理アプリをつくる」は、プロダクトの説明であって問題の定義ではない。「複数のプロジェクトを同時に回している個人事業主が、今日必ずやるべきことを5分以内に決められるよう手助けする」という文なら、ユーザーと状況、そして結果が見えてくる。

このときAIには、アイデアを出してもらうよりも、この文の穴を突いてもらうように頼む。

• この問題は実際によく起きているか？
• ユーザーはいま、どんな方法で解決しているか？
• お金や時間をかけてでも変えたいほど不便なのか？
• もっと絞り込めるユーザーは誰か？
• プロダクトがなくても検証できる仮説は何か？

いい出発点とは、答えがたくさんあるアイデアではなく、確かめるべき問いがはっきりしているアイデアだ。

2. AIで調べ、人に確かめる

初期の調査では、AIはとにかく速い。競合プロダクトをタイプ別に分けたり、想定ユーザーを整理したり、インタビューの質問案をつくったりするのに役立つ。ただし、生成された要約を市場の事実として受け取ってはいけない。

私は調査結果を3つの層に分けている。

1. AIが提案した仮説：まだ確認されていないアイデア
2. 自分で確認した資料：プロダクトページ、価格、レビュー、公開ドキュメント
3. ユーザーが語った経験：インタビュー、観察、実際の行動

プロダクトの方向性は、3つ目の層に近づくほど信頼できる。できれば、潜在ユーザー5人に同じ問題について聞いてみる。「この機能を使いますか？」よりも、「最近この問題をどうやって解決しましたか？」のほうがいい質問だ。未来の意向よりも、過去の行動のほうが強い証拠になるからだ。

3. 1ページのプロダクト仕様書をつくる

調査が終わったら、長い企画書のかわりに1ページだけのプロダクト仕様書を書く。そこに載せるのは次の項目だけだ。

項目	書くべき内容
ユーザー	今回のバージョンで集中する1種類のユーザー
問題	くり返し起きている具体的な不便
約束	使ったあとに変わるひとつの結果
コアフロー	ユーザーが最初から最後までたどる行動
スコープ外	今回はつくらない機能
成功基準	リリース後に確認する行動または数字
リスク	個人情報、コスト、精度、運用の負担

この仕様書をAIにレビューさせると、互いに矛盾する条件や抜けている例外をすばやく見つけられる。特に大事なのが、スコープ外をはっきり書いておくことだ。ひとりでつくるプロダクトは、機能不足よりも、スコープの膨らみすぎで止まることのほうが多い。

AIが各段階をすばやくつないでくれても、次の段階に進むかどうかを決めるのは、プロダクトをつくる私自身だ。

4. MVPでは最短のユーザーフローだけをつくる

MVPは完成度の低いプロダクトではなく、いちばん重要な仮説を、いちばん少ない機能で確かめるプロダクトだ。私は最初のバージョンのフローを、たいてい4つのステップに絞っている。

1. ユーザーがやって来る。
2. 必要な情報を入力する。
3. プロダクトが核となる結果を生み出す。
4. ユーザーが結果を保存するか、次の行動に移る。

アカウント設定、ダッシュボード、通知、決済、管理画面は、核となる仮説に直接関係しないなら後回しにする。まずはクリックできる画面や、シンプルな手作業のサービスでフローを検証してもいい。コードを一行も書かずに、ユーザーのために結果を手づくりしたほうが速いケースも多い。

AIを使うと、機能を足すのが簡単になる。だからこそ、削るための基準をもっと厳しくしなければならない。「つくれるか？」ではなく、「この機能なしでは仮説を検証できないのか？」を問う。

5. AIと開発するときは小さな単位で任せる

「このサービスを全部つくって」と頼めば、大量のコードがすぐにできあがる。でも同時に、レビューしにくいシステムまでできあがってしまう。私は作業を、画面ひとつ、ユーザーの行動ひとつ、データの流れひとつといった小さな単位に分けている。

AIに開発作業を頼むときは、次の4つをセットで渡す。

目標：ユーザーがメールアドレスでログインできるようにする。
現在の状態：使っているフレームワークと関連ファイルを説明する。
制約：既存の構成、セキュリティのルール、変更してはいけない範囲を書く。
完了条件：成功・失敗のフローと、実行すべきテストを定義する。

コードが生成されても、すぐに次の機能には進まない。変更されたファイルを読み、実際に動かし、失敗したときの経路を確認する。理解できないコードは、自分では保守できないコードだ。AIがきちんと説明できなかったり、テストが不安定だったりしたら、実装をもっと小さな単位に戻す。

私が守っている開発の手順

1. いまの構成と目標をAIに説明する。
2. まずは実装計画と、変更するファイルの一覧だけを出してもらう。
3. 一度にひとつずつ、小さな変更を適用する。
4. 型チェック、リント、テスト、ビルドを実行する。
5. ブラウザで実際のユーザーフローを確認する。
6. 変更した理由と、残っているリスクを記録する。

この手順を守れば、AIが書いたコードを手で書き直す時間よりも、レビューと判断により多くの時間を使えるようになる。

6. テストとセキュリティはAIに丸投げしない

AIは、テストケースを提案したり、セキュリティ上の問題を見つけたりするのを手伝ってくれる。しかし、「問題ありません」という答えをお墨付きとして受け取ってはいけない。特に認証、決済、個人情報、ファイルアップロード、外部APIが絡むなら、人間が自分の目で確認しなければならない。

リリース前には、最低限次の点をチェックする。

• 正常系だけでなく、空の入力、不正な値、重複したリクエストも試す。
• シークレットキーや個人情報が、ブラウザやログに露出していないか確認する。
• ユーザーがほかのユーザーのデータにアクセスできないことを確認する。
• AI機能が間違えたり応答しなかったりしたときの画面を用意しておく。
• 想定より利用量が増えたときに備えて、コストの上限と利用制限があるか確認する。
• モバイル画面、遅いネットワーク、アクセシビリティの基本的な動作を確認する。

7. 小さくリリースして、実際の反応を記録する

リリースは最後のステップではなく、いちばん正確な調査が始まるタイミングだ。最初から大勢に知らせるより、その問題を実際に抱えている小さなユーザーグループに公開する。

最初のリリースでは、ページビューよりも次のような行動を見る。

• ユーザーが説明なしでコアフローを最後までこなせるか？
• 結果をもう一度使ったり、ほかの人に共有したりしているか？
• どのステップで止まっているか？
• プロダクトがなくなったら残念だと言ってくれるか？
• 時間やお金を払う意思が、行動になって表れているか？

インタビューのメモやログをまとめて、くり返し出てくるパターンを探すのにはAIが使える。ただし、ユーザーごとに異なる意見を無理にひとつの結論にまとめることはしない。何を直すかは、プロダクトの約束にいちばん近い問題から選ぶ。

ひとりでプロダクトをつくる7日間の実行ループ

小さな実験なら、次のような1週間単位で回せる。

日程	やること	成果物
1日目	問題とユーザーを絞り込む	一文の問題定義
2日目	資料調査とユーザーとの対話	核となる仮説3つ
3日目	プロダクトのフローとスコープ外を決める	1ページの仕様書
4〜5日目	AIとコアフローを実装する	動くMVP
6日目	テストとセキュリティのチェック	リリース用チェックリスト
7日目	少数のユーザーに公開する	観察記録と次の判断

1週間で良いプロダクトが完成するわけではない。そのかわり、つくり続ける価値があるかどうかを判断できるだけの証拠は手に入る。このスピードこそ、AIを使ういちばん現実的な理由だ。

AIが得意なことと、自分でやるべきこと

AIに積極的に任せられること

• 資料の一次分類と要約
• 質問リストやドキュメントの下書き作成
• くり返しの多いコードやテストのひな形の生成
• エラーメッセージの説明と、デバッグの仮説出し
• 文言のバリエーションや翻訳の下書きの生成
• 会議やユーザーインタビューのメモの整理

最後まで自分で責任を持つべきこと

• どの問題を解決するかを選ぶこと
• ユーザーの言葉を文脈の中で解釈すること
• プロダクトの品質とセキュリティの基準を決めること
• 生成されたコードや情報が正しいかを検証すること
• 何を捨てて、いつリリースするかを決めること
• 失敗のコストと、ユーザーに及ぶ影響に責任を持つこと

よくある質問

開発者でなくても、AIでプロダクトはつくれるのか？

シンプルなプロトタイプや手作業のサービスなら可能だ。ただ、ユーザーのデータや決済が絡む本番のプロダクトとなると、システムの構造、セキュリティ、運用を理解している必要がある。わからない部分をAIの確信に頼って覆い隠すより、スコープを絞るか、専門家にレビューしてもらうほうが安全だ。

どのAIツールから選べばいいのか？

ツールより先に、作業を決めるのがいい。調査、ドキュメント作成、デザイン、コーディング、テストのうち、いちばん時間がかかっているステップをひとつ選び、それに合ったツールをひとつ使うところから始める。ツールをいくつもつなぐより、くり返し使える仕事の進め方をつくるほうが先だ。

AIが書いたコードはそのまま使っていいのか？

そのままデプロイしてはいけない。コードの動作、依存関係、ライセンス、セキュリティ、例外処理をレビューし、プロジェクトのテストとビルドを通さなければならない。説明できないコードは、プロダクトの負債になる。

ひとりでつくるとき、いちばん大事な指標は何か？

初期は、登録者数よりも、核となる問題を実際に解決できたユーザーの数が大事だ。プロダクトの核となる行動を最後までやり遂げた人、また戻ってきた人、結果のためにお金を払った人を、まず見る。

結局、プロダクトをつくるのは人間だ

AIは、ひとりでプロダクトをつくる人の手を速くしてくれる。調査と実装のあいだの距離を縮め、慣れない役割にも踏み出せるように助けてくれる。でも、プロダクトの方向性も、ユーザーへの理解も、リリースする勇気も、自動ではつくってくれない。

ひとりでつくる良いプロダクトとは、AI機能をいちばんたくさん使ったプロダクトではない。小さな問題を正確に選び、実際のユーザーにすばやく届け、学んだことを次のバージョンに反映したプロダクトだ。

私は人生をひとつのプロジェクトとして見ている。プロダクトづくりも同じだ。完璧な計画を待つより、小さなバージョンを公開し、結果を記録し、次の判断を下す。AIはそのプロジェクトを代わりに担う存在ではなく、より短いサイクルで実行できるようにしてくれる道具だ。