2026-03-27 — Dev

AIで「週末MVP」を量産する方法 — アイデアから動くプロダクトまで48時間の開発記録

「作りたいけど時間がない」という管理職のジレンマ

「こういうサービスあったらいいのに」と思うことは、たぶん月に3回くらいあります。

でも、本業で50名の組織を見ながら、副業もやって、すでに複数の事業を回している。新しいアイデアを思いついても、「いつ作るの？」が常に壁になる。

管理職をやっていると、日中は会議とSlackに追われて、まとまったコーディング時間は取れない。夜は疲れてるし、平日にゼロからプロダクトを立ち上げるのは現実的じゃない。

でも、アイデアは鮮度がある。「いつかやろう」のメモ帳には、二度と開かないアイデアが30個くらい眠っている人も多いんじゃないでしょうか。

この記事は、土曜の朝から日曜の夜までの48時間で、アイデアをMVPにする実践記録です。使うのはAI（Claude Code）と、週末のまとまった時間。「時間がないから作れない」を、「48時間あれば検証できる」に変えるための方法を共有します。

48時間MVP開発の全体設計 — 始める「前」にやること

いきなりコードを書き始めるのは、48時間開発における最大の罠です。

金曜の夜に1時間だけ使って、「何を作って、何を作らないか」を決める。この準備が、週末の生産性を3倍にします。

アイデアの絞り込み基準

アイデアのメモ帳から「今週末これを作る」を1つ選ぶとき、3つの基準で判断しています。

1. 自分が最初のユーザーか？

自分が使わないものは作らない。「こういうの需要ありそう」は危険信号。自分自身が「これがないと不便」と感じている課題を選ぶ。自分がユーザーなら、仕様の判断で迷うことが激減します。

2. 核となる機能が1つに絞れるか？

48時間で作れるのは、機能1つ。ログイン機能、ダッシュボード、管理画面、メール通知……全部入りを考えた瞬間にスコープは破綻します。「この1つの機能だけでも価値がある」と言えるものを選ぶ。

3. 技術的に枯れた構成で作れるか？

週末に新しいフレームワークを学んでいる余裕はない。Next.js、Tailwind CSS、Cloudflare Pages（またはVercel）。自分が手に馴染んだスタックで作ること。技術的チャレンジはMVP検証が終わってから。

スコープを決める「Not Doingリスト」

やることリストよりも、やらないことリストのほうが重要です。

たとえば、こんな感じで書き出します：

  • やらない: ユーザー認証（MVP段階では自分しか使わない）
  • やらない: モバイル対応（PCで動けば検証には十分）
  • やらない: デザインの作り込み（Tailwind UIのデフォルトで十分）
  • やらない: テストコード（MVP段階ではスキップ）
  • やらない: CIパイプライン構築（手動デプロイで十分）

これをClaude Codeにも共有しておくと、「テスト追加しましょうか？」みたいな提案をスキップしてくれるので効率的です。

ちなみに、自分が最初に意識するようになったのは「環境まわりを後回しにしない」こと。ManeBookのMVP開発では、dev環境とprod環境の差分をまったく想定していなかったため、あとからSupabaseのプロジェクトを新しく作り直してマイグレーションする羽目になりました。48時間で作り切るなら、「本番デプロイまでの最短経路」を最初に確保しておくのが鉄則です。

技術選定の判断軸

48時間MVPでの技術選定は、「最速でデプロイできるか」が唯一の基準。

自分の場合、よく使う構成はこうです：

レイヤー選択肢理由
フロントエンドNext.js（App Router）慣れている・SSG可能
スタイリングTailwind CSSクラスを書くだけで完結
データベースCloudflare D1 / Supabase無料枠がある
ホスティングVercel / Cloudflare PagesGitプッシュでデプロイ
AI開発Claude Codeコード実装・レビュー・デバッグ

ここに時間を使うのはもったいないので、テンプレートとして固定しています。

実録: 土曜朝〜日曜夜の開発タイムライン

ここからは、実際の48時間の流れを時系列で追います。

ここからは、ManeBook（マネジメント学習プラットフォーム）のMVP開発を例に、実際の流れを追います。ManeBookは「初めてマネジメントを担う管理職に、実務で使えるTipsを体系的に届けたい」という自分自身の課題から生まれたプロダクトです。

土曜日 午前（9:00〜12:00）: 学習コンテンツの骨格をつくる

ManeBookの場合、最初に手をつけたのはLPでもUIでもなく、学習コンテンツでした。

「管理職の学習プラットフォーム」を名乗るなら、コンテンツがなければ話にならない。まずはClaude Codeに「初めてマネジメントを担う人が最初に学ぶべきトピックを体系化して」と伝えて、コンテンツの骨格を作りました。

ここでの発見は、学習コンテンツやブログ記事はAIのポン出しでかなり使えるレベルだったこと。マネジメントの基本フレームワークやケーススタディの素案は、Claude Codeが出してくれたものをベースに、自分の経験を加筆するだけで十分な品質になりました。

残りの2時間で、プロジェクトの初期化（npx create-next-app）、基本レイアウト、コンテンツ表示の仕組みまで。ここはClaude Codeに一気に任せて、自分はブラウザで結果を確認するだけ。

土曜日 午後（13:00〜18:00）: コア機能の実装

ここが勝負。5時間で核となる機能を実装する。

自分の経験上、Claude Codeに指示を出すときのコツは「完成形を言葉で描写する」こと。

悪い例: 「データを表示する画面を作って」

良い例: 「○○のデータを新しい順に一覧表示するページ。各行には名前・日付・ステータスを表示。ステータスが"完了"ならグリーンのバッジ、"未完了"ならグレー。一覧の上に件数を表示」

具体的であればあるほど、手戻りが減る。1回の指示で80%の完成度を出してもらい、残り20%を修正指示で詰める。この「80→100」のサイクルを1時間に2〜3回転させると、5時間で核となる機能が形になります。

ManeBookの開発で実感したのは、AIが得意な領域と苦手な領域がはっきり分かれるということ。

学習コンテンツやブログ記事は、Claude Codeの出力がそのまま使えるレベル。構成も文章も、ほぼポン出しでOKでした。

一方で、LPは何度修正を重ねても、自分のイメージ通りにならなかった。「もっとシンプルに」「ここのコピーはこういうニュアンスで」と指示を繰り返しても、微妙にズレる。結局、LPのコピーライティングは自分で書き直す部分が多かったです。

もう一つ、利用規約やプライバシーポリシーなどのリーガル文章は、AIの出力をそのまま使うのは危険。法的に問題がないか、しっかりレビューを通す必要があります。ここは時間を惜しまないほうがいい。

このように「AIに任せる部分」と「人間が判断する部分」を切り分けるのが、48時間開発のスピードを左右します。

土曜日 夜（19:00〜22:00）: デバッグと調整

午後に作ったものをブラウザで触り倒す時間。

ManeBookの場合、幸いバグらしいバグは出なかった。Claude Codeがコードを書いてくれる精度は、正直かなり高いです。

ただ、ここで想定外だったのが「環境まわり」。開発中はローカルのSupabaseで動かしていたんですが、本番環境（prod）との差分をまったく考えていなかった。結果、Supabaseのプロジェクトを新しく作り直して、データベースのマイグレーションをやり直す羽目に。

これは「動くものを作る」ことに集中しすぎて、「動くものを本番に出す」までの経路を後回しにした典型的なミスでした。48時間開発では、土曜の午前中に一度、本番環境へのデプロイを通しておくのがおすすめ。空のプロジェクトでもいいから、デプロイの経路を確保しておくと、日曜の午後に焦らなくて済みます。

日曜日 午前（9:00〜12:00）: UI仕上げとデプロイ準備

日曜の朝は、見た目を整える時間。

Tailwind CSSのおかげで、UIの調整もコードベースで完結します。Claude Codeに「もう少しスペーシングを広げて」「フォントサイズを調整して」と投げるだけ。デザイナーがいなくても、最低限の見栄えは確保できます。

この段階で、OGP画像の設定やファビコンの追加もやっておく。MVPとはいえ、URLを共有したときの第一印象は大事です。

日曜日 午後（13:00〜17:00）: デプロイと初期検証

git push でVercel（またはCloudflare Pages）にデプロイ。

ここで大事なのは、デプロイしたら即、誰かに触ってもらうこと。自分だけで「できた」と満足するのはMVPとしてはもったいない。

デプロイ完了後にやること：

  1. 自分でスマホからアクセスして動作確認
  2. 信頼できる2〜3人にURLを送る
  3. 「触ってみて、最初に感じたことを教えて」とだけ伝える

フィードバックを求めるとき、「どう思う？」は広すぎてダメ。「最初の30秒で何をするか迷わなかった？」「これ、お金払ってでも使いたい？」みたいに、Yes/Noで答えられる質問を投げるのがコツです。

日曜日 夜（18:00〜21:00）: フィードバック反映と振り返り

もらったフィードバックのうち、30分以内で直せるものだけ対応する。

「あったらいいな」系の機能追加は、ここでは絶対にやらない。MVPの目的は「この課題にニーズがあるか」の検証であって、完璧なプロダクトを作ることじゃない。

最後の1時間は振り返り。何がうまくいったか、次に48時間開発をするなら何を変えるか。これを CLAUDE.md やNotionにメモしておく。次のMVP開発のとき、同じ失敗をしなくて済みます。

「動くもの」を出した後にやるべき3つのこと

MVPが動いた。フィードバックももらった。ここからが、実はMVPの本番です。

1. 数字を見る

「いいね」とか「すごい」とか定性的な反応だけでは判断できない。

最低限、以下の数字を1週間追う：

  • アクセス数（Vercel Analyticsで十分）
  • 滞在時間
  • リピート率（同じ人が2回以上来たか）

これだけで「興味を持たれているか」「繰り返し使う価値があるか」がわかります。

2. 続行/撤退の判断基準を決めておく

MVPを作ったあと、一番危険なのは「なんとなく続けてしまう」こと。

自分の場合、1週間後に以下のチェックリストで判断しています：

  • 自分自身が毎日使っているか？
  • 2人以上から「もっと使いたい」と言われたか？
  • 次に追加すべき機能が明確にイメージできるか？

3つともYesなら続行。1つでもNoなら、いったん凍結して次のアイデアに移る。

ここで重要なのは、撤退を「失敗」と捉えないこと。MVPの目的は検証なので、「ニーズがなかった」とわかったこと自体が成果です。

ManeBookの場合、正直に言うと、最初はユーザーの反応がほぼなかった。

作ったものに自信はあったけど、有料で出したら誰も来ない。これは「ニーズがない」のか、「価格が壁になっている」のか、「そもそも認知されていない」のか。

判断に迷ったけど、自分自身が毎日使いたいプロダクトだったので、まず無料で公開して「認知の壁」を取り除くことにしました。無料にした上で使われるかどうかを見れば、ニーズの有無がより正確にわかる。

これも管理職の意思決定と同じで、**「データが足りないなら、データが取れる状態を先に作る」**という考え方。撤退するにしても、判断材料が揃ってからのほうがいい。

3. 「続ける」と決めたら、仕組み化する

続行判断をしたプロダクトは、週末だけの開発ではもたない。平日の朝30分でも進められるように、タスクを細かく分解しておく。

自分の場合、CLAUDE.md にプロジェクトの設計思想や開発ルールを書いておくことで、久しぶりにプロジェクトを開いても、Claude Codeがコンテキストを把握してくれる。「先週どこまでやったっけ」を思い出す時間がゼロになるのは大きい。

まとめ: 週末MVPは「完成」ではなく「問い」を立てる行為

48時間で作るMVPは、完璧なプロダクトじゃない。

それは**「この課題にニーズがあるのか？」を最小コストで検証するための装置**です。

面白いのは、管理職の日常スキルとMVP開発の相性がとても良いこと。

  • スコープを切る → 予算やリソースの制約の中で意思決定する力
  • 優先順位をつける → 「今やるべきこと」と「後でいいこと」を分ける力
  • 撤退判断をする → データを見て冷静に判断する力

これ全部、マネジメントの仕事で日常的にやっていること。開発の経験がなくても、判断力がある人はMVP開発に向いていると思います。

AIのおかげで、「作る」のハードルは劇的に下がりました。Next.jsの細かい構文を覚えていなくても、Claude Codeが書いてくれる。デザインのセンスがなくても、Tailwind UIのコンポーネントを組み合わせれば形になる。

残っているのは、「何を作るか」と「作ったものを、どう検証するか」の判断だけ。

そしてそれは、管理職が一番得意なことだったりする。

来週の金曜日の夜に、30分だけ時間を取って、アイデアメモの中から1つ選んでみてください。土曜の朝にはClaude Codeを立ち上げて、「これを作りたい」と伝えるだけ。48時間後には、動くものが手元にあるはずです。

完璧じゃなくていい。「これ、ニーズあるのかな？」という問いに、動くプロダクトで答えを出す。その一歩を踏み出すだけで、個人開発の景色は変わります。