一人×AIで10のプロダクトを作って、わかったこと

2023年8月にFloat Engineeringを設立してから、2年半で10以上のWebプロダクトを作った。すべて一人で。企画、設計、開発、デザイン、マーケティング、運用まで。

特別な話ではない。AIの進化で、一人の開発者が出せるアウトプットの量が根本的に変わった。以前なら3人で3ヶ月かかっていたものが、一人で3週間で作れるようになった。

この記事では、10以上のプロダクトを作る中で学んだことを整理する。技術的なTipsではなく、「何を作るか」「何を作らないか」「いつやめるか」の判断基準の話だ。

作ったもの一覧

まず全体像を見せる。

受託サービス：

• AIのあとしまつ — AI生成コードを本番品質に仕上げるサービス
• LITMUS — 新規事業のアイデアを6週間で検証するスタジオ

自社プロダクト：

• 転職DB — 退職理由・転職先がデータで見える企業研究DB
• Calen — イベントを参加者のカレンダーに1クリックで追加
• webmusic.app — ブラウザで使える無料音楽ツール集
• my9books — あなたを形作った9冊を選んでシェア
• maneguri — 中小企業のための無料資金繰りシミュレーター
• Supabase Risk Check — SupabaseのセキュリティリスクをURL入力だけで自動診断
• Lean Canvas — 9つの質問で事業仮説を整理
• Javelin Board — 仮説検証プロセスを構造化して記録

加えて、リードジェン用のSEOメディアを3ドメインで運営し、記事は合計150本以上ある。

わかったこと 1：作らない判断が最も重要

10以上作ったと言うと、「たくさん作ったんですね」と言われる。だが実際には、作らなかったアイデアの方がはるかに多い。

プロダクトを作るかどうかの判断基準は3つに絞られた：

① 自分自身が課題を感じているか

maneguriは、自分の会社の資金繰り管理がスプレッドシートでは限界だと感じて作った。Supabase Risk Checkは、あとしまつの案件で毎回同じセキュリティチェックをしていたから自動化した。

自分が使わないものは作らない。ユーザーの気持ちがわからないプロダクトは、改善のしようがない。

② 最小限の形で1週間以内に作れるか

アイデアの良し悪しは、作ってみないとわからない。だが、作るのに3ヶ月かかるなら、そのアイデアの検証コストが高すぎる。

1週間で最小限のものを作り、公開し、反応を見る。反応がなければ撤退する。反応があれば育てる。このサイクルを回すために、初期開発のスピードは絶対条件だ。

③ 既存の代替手段に明確な不満があるか

「あったら便利」ではなく、「今の方法に不満がある」かどうか。my9booksは「本をシェアする方法がTwitterの長文スレッドしかない」という不満から作った。不満がないところにプロダクトを置いても、誰も乗り換えない。

わかったこと 2：技術選定を固定するのが速さの鍵

10以上のプロダクトをそれぞれ違う技術で作っていたら、メンテナンスだけで破綻する。

すべてのプロダクトで技術スタックを統一している：

• フレームワーク: Next.js
• ホスティング: Vercel
• データベース: Supabase（必要な場合）
• スタイリング: Tailwind CSS
• 言語: TypeScript

新しい技術を試したい誘惑は常にある。だが、技術選定で悩む時間はプロダクトの価値を生まない。「慣れた道具で速く作る」方が、「新しい道具で時間をかけて作る」より圧倒的に成果が出る。

AIコーディングツールとの相性も、スタックが固定されていると上がる。Cursorに「いつものNext.js + Supabase + Tailwindで作って」と指示するだけで、自分の書き方に近いコードが出てくる。

わかったこと 3：AIは「書く」のが速いだけで、「考える」のは人間

AIコーディングツールの恩恵は計り知れない。だが、万能ではない。

AIが速くしてくれること：

• UIの実装（コンポーネント、レイアウト、レスポンシブ対応）
• 定型的なロジック（CRUD、フォームバリデーション、API接続）
• リファクタリング、テストコードの生成
• ドキュメントの下書き

AIではどうにもならないこと：

• 何を作るかの判断
• ユーザーが本当に求めていることの理解
• ビジネスモデルの設計
• 撤退のタイミング

AIで開発速度が10倍になっても、間違ったものを10倍速く作ったら意味がない。「何を作るか」の判断力は、AIでは代替できない。むしろ速く作れるようになった分、この判断の重要性は増している。

わかったこと 4：撤退の基準を先に決める

10以上作った中で、成長を続けているものは半分以下だ。残りは、最小限の運用コストで維持しているか、アクティブな開発を止めている。

撤退を判断する基準は、リリース時に決めておく：

• リリース後1ヶ月で、オーガニックでのアクセスがゼロ → 課題設定が間違っている
• 3ヶ月使い続けているユーザーがいない → 課題は合っているがソリューションが違う
• 自分自身が使わなくなった → そもそも必要なかったか、より良い代替手段が出た

重要なのは、撤退を「失敗」と捉えないこと。1週間で作って、1ヶ月で検証して、ダメなら次に行く。このサイクルを回せるのが、少人数の最大のメリットだ。大きな組織では、一度始めたプロジェクトを止める判断に半年かかる。

わかったこと 5：自社プロダクトが受託の信頼になる

想定外だったのは、自社プロダクトを作ること自体が、受託開発の営業になっていたことだ。

「10以上のプロダクトを一人で運営している」と言うと、技術力の証明になる。だが、それ以上に効いているのは「この人は実際に作って、運用して、失敗もしている」という信頼だ。

コンサルタントの提案書より、自分で作って公開しているプロダクトの方が雄弁だ。「あとしまつ」も「LITMUS」も、受託の相談を受ける中で見つけた課題を、自分でサービスにしたものだ。

受託と自社プロダクトは対立しない。むしろ、両方やることで互いが強くなる。受託で顧客の課題を知り、自社プロダクトで解決策を形にし、その実績がまた次の受託につながる。

同じやり方で、あなたの開発もやる

ここまで書いたことは、そのまま受託開発にも適用している。

• 作る前に「本当に必要か」を確認する（LITMUS）
• AIで速くプロトタイプを作り、本番品質に仕上げる（AIのあとしまつ）
• 技術選定で悩まず、実績のあるスタックで速く作る
• 撤退の基準を先に決めて、小さく検証する

「開発の町医者」を名乗っているのは、このプロセスを直接提供できるからだ。アドバイスだけではなく、自分の手で作る。

開発の相談があれば、無料相談から始められる。