最小機能（MVP）だけで作る

このレッスンで終わる頃には

• MVPの本質「1つの痛みを1機能で解決する」が腹落ちしてる
• 自分のアイデアから「捨てる5つ」を書き出せる
• 1週間で動くものを出すスケジュール感がある

いよいよ手を動かす

Lesson 02までで、作るアイデアが1つに決まったはずです。

ここからの数レッスンは、それを 1週間で動く形 にして公開するまでを扱います。

最初のレッスンは、その入口で多くの人がつまずく 「何を作るか」じゃなくて「何を作らないか」 の話です。

MVPとは

MVP（Minimum Viable Product）= 最小限機能するプロダクト。

定義はシンプルで、

1つの痛みが、1機能で解決できる状態。

それ以上は、最初は要らない。

Shin氏はソロプレナー入門の動画でこう言ってます。

1つの痛みを解決できたらもうすぐに出しましょうってことです。

「すぐに」が肝です。完璧を目指して機能を盛り続けると、永遠に出ない。

なぜMVPが大事か

理由は3つあります。

理由1：作っても使われないことが多い

これは聞きたくない真実なんですけど、自分が「便利だ」と思って作ったアプリでも、いざ手元に来ると 意外と使わない ことがあります。

3ヶ月かけて全機能実装してから「使わなかった」と気づくのは時間の損失です。1週間で「動くもの」を出して、自分が使うかどうかを確かめたほうが早い。

理由2：完璧を目指すと出ない

「もう少しUIを綺麗にしてから」「認証もちゃんとつけてから」「ダークモードを実装してから」...

この「〜してから」が積み重なると、半年経っても公開できません。

私もこれで何本か潰しました。動かないけど綺麗 より 汚いけど動く の方が、結局は遠くまで行けます。

理由3：使ってみないとボトルネックが分からない

実際に自分で使うと、「ここで詰まるな」「これは要らないな」が見えてきます。

これは作る前には絶対に分からない。1日使えば、3ヶ月分の机上の議論より価値ある気づき が出ます。

何を「捨てる」か

具体的に、最初のMVPで捨てていいもの：

「これ実装したい」と思った機能の 半分以上は捨てていい です。

「動くもの」の最低ライン

逆に、捨てちゃダメなもの。

□ 1つの痛みが、1機能で解決される
□ 自分が10秒以内に起動できる（パスワード入力で詰まらない）
□ 自分のデータが消えない（最低限の保存）
□ エラーで完全に止まらない（落ちても再起動でリカバー可）

これだけ満たしてればOK。あとは自分で使いながら、足りないものだけ足していく。

1週間スケジュール感

Shin氏が紹介してた感覚を一般化すると、こんなイメージです。

1週間で動かなかったら、設計が大きすぎる サインです。スコープを半分に削ってください。

技術スタックは何でもいい

「Next.jsとReactとTailwindとTypeScriptとPostgreSQLと...」

ここで時間を取られないでください。

Shin氏の比喩がうまいので引用します。

家立てる時にとんかち、どこの商品、どこのお店のとんかち使ってますかって、住む人にとったらどうでもいいので。

Vibe Coding 入門編でやったClaude Code + Next.js（or HTML 1ファイル）で十分です。慣れてる道具で作ってください。

迷ったら「Claude Codeに『MVPで作って』と頼んで、提案された構成のまま」が最速です。判断コストをゼロにする。

実装前に「ドキュメントを3つ書く」

ここがShin氏の工程で、いちばん盗みたいポイントです。

Vibe Coding 入門編でやった Claude Code との対話、いきなり「これ作って」って頼んでませんでしたか？

それでも動くものは作れます。でも Shin氏は動画で、実装に入る前にドキュメントを3つ書く やり方を実演してます。

これが コンテキストエンジニアリング の肝で、最初の30分の手間が、後の3時間の手戻りを救います。

書く3つのドキュメント

1. docs/REQUIREMENTS.md（要件定義）

ボイスモードや対話で、Claudeに質問させながら作る。

「このアプリ、まずいくつか質問してください。質問が溜まったら docs/REQUIREMENTS.md にまとめて」

これでClaudeが「認証は？」「決済は？」「画像生成は？」と聞いてくれて、答えていくうちに要件が文字に固まります。頭の中だけにある仕様 が、ドキュメントに変わる瞬間です。

2. docs/tasks.md（進捗管理）

要件定義をもとに、フェーズ1〜4でMVPを段階分けして、チェックボックスでタスクを並べる。

「要件定義をもとに、開発タスクをフェーズ分けして docs/tasks.md に書いて。各タスクはチェックボックスで」

これがあると：

• 1セッションで終わらなくても、次のチャットで続きから再開できる
• 「いまどこまで進んだ」が常に見える
• AIに「次のフェーズに進んで」と頼むだけで、迷子にならない

3. docs/best-practices.md（ベストプラクティス）

実装が始まる前に「型」を文字化しておく。

「Next.js App Router のベストプラクティスを、Web検索して docs/best-practices.md に残して」

これで Claude が、サーバーコンポーネント・データフェッチ・キャッシュなどの「正しいやり方」を先に書き出してくれます。

実装に入ってから「サーバーコンポーネント使ってない」と気づく事故が、ほぼゼロになります。

なぜ先にドキュメントなのか

従来：いきなり実装
   ↓
途中で要件のブレに気づく
   ↓
手戻り＋やり直し
   ↓
3時間ロス

ドキュメント先行：
要件定義（30分）
   ↓
タスク分割
   ↓
ベストプラクティス文字化
   ↓
そのまま実装
   ↓
ブレが減って手戻り削減

理由は1つで、AIに渡せるコンテキストが多いほど、AIの仕事の質が上がる から。

「ToDoアプリ作って」だけ渡すのと、「この要件、このタスク、このベストプラクティスに従って作って」では、出てくるコードの質が雲泥の差です。

これは Shin氏だけじゃなく、梶谷健人氏もPIVOT動画で同じことを言ってました。

適切なコンテキスト情報・背景情報を渡せば渡すほど、いい仕事してくれるんですけど、適切なコンテキストを人間がピックアップして渡すコストがめちゃくちゃ高かったんですよ。

これを 「フォルダで全部見れる状態にしておく」 ことで、人間がいちいち渡さなくてもAIが勝手に読みに行ってくれる、という発想です。

具体的な開始手順

プロジェクトフォルダで、こう投げる：

このアプリの要件定義をしたいので、いくつか質問してください。 答えが揃ったら docs/REQUIREMENTS.md に整理してください。 その後、docs/tasks.md（フェーズ分けのチェックリスト）と docs/best-practices.md（Next.js App Router 等のベストプラクティス）も 自分で作成してください。

これでドキュメント3点セットが揃った状態から、実装に入れます。

Claude Codeを「中の人」として育てる（rohit式）

Shin氏の3ドキュメントは、1本目のMVPを動かすには十分です。 ただし、2本目・3本目と作るうちに、毎回ゼロから3ドキュメントを書き直すのは無駄になってきます。

ここで効いてくるのが、米国の個人開発者 rohit4verse が "The solo founder stack of 2026" でまとめている、もう1段上の整え方です。彼の表現を借りるとこうなります。

Claude Code is a person you onboard. The leverage is in the workspace you build around it.

Claude Codeは「自動補完ツール」じゃなくて、新しく入ってきた人として迎え入れる。レバレッジはその周りのワークスペースに溜まっていく、という発想です。

3ステップで整えます。

具体的な使い分け：

• CLAUDE.md：DBはどこにある、認証はどう動く、PRを出す前にどのテストを通す、AIに勝手に触らせていい範囲はどこまで。新人テックリードがシニアハイヤーに渡すドキュメントを、自分のリポにも置く。
• skills/：ship-feature.md（PRを出す前の型）、triage-bug.md（本番が落ちた時の手順）、migrate-schema.md（データを失わない7つの教訓）。1度書けば、Agentが永遠に使い続ける。
• MCP：GitHub、Postgres、Linear、ファイルシステム、監視ツール。1度配線すれば永続化される。

ここまで仕込むと、Claude Codeは「指示を投げて返ってくる」自動補完から、「業務を覚えていて、勝手に進めてくれる」1人目の社員に変わります。

Vibe Coding 応用編（このコース）の範囲では、ここまで詰めなくても1本目は動きます。3本目・5本目を作るあなたが、ここに辿り着いておくと作業時間が桁で変わる、というイメージで頭の隅に置いてください。

出典: rohit4verse, "The solo founder stack of 2026" (X, 2026-04-15)

APIはMVPの強い味方

MVPで「コアになる1機能」を作るとき、API は最強の味方です。

理由：

• ChatGPT/Geminiに繋ぐだけで「AIっぽい機能」が10分で完成
• PubMedに繋ぐだけで「論文検索ツール」が30分で完成
• OpenWeatherMapに繋ぐだけで「天気アプリ」が10分で完成

自分でゼロから作るとどうしても遅くなるけど、API経由なら他人の作った機能をそのまま借りれる。

これがソロ開発が大手と戦える、もう1つの構造的な強みです。

実例：PubMed APIで論文検索ツール（5分で動く例）

具体例を1つだけ。「自分の専門領域の最新論文を毎日タイトルだけ取ってくる」ツール。

完成像：

pubmed-search "小児喘息"

これで、最新10本のタイトル+著者+年が返ってくる。これだけです。

実装に必要なもの：

• Python のワンファイル（30行くらい）
• PubMed API（完全無料、APIキー登録は5分）
• Vibe Coding 入門編 Lesson 4b「ターミナルって怖くない」でやった UV で環境分離

Claude Codeに、こう投げるだけで完成します。

PubMed APIで、コマンドラインから検索キーワードを渡すと、最新10本の論文タイトル・著者・出版年が返ってくるツールを作ってください。 APIキーは環境変数 NCBI_API_KEY から読み取り。Pythonで、UV で動かせる形に。

捨てたもの：

• データベース（コマンドラインに表示するだけ）
• 認証（自分1人で使う）
• Web UI（ターミナルで十分）
• 履歴保存（毎回新規検索でOK）
• 設定画面（コードに直書き）

これが MVP の感覚です。作りたかったものの3割で、最初は十分。

API実装の詳細は、別途レッスンを用意する予定です（PubMed APIの料金や、AI系APIに進むときの注意点など）。

今日の宿題

Lesson 02で「これ作る」と決めたアイデアについて、紙やメモアプリに2つ書き出してください。

1. このアプリの「1機能」は何か？（1行で書く）
   例：「ログイン後、PubMedで小児喘息を検索して10本表示する」

2. 捨てる機能リスト（5つ以上、できれば10）
   例：認証はGoogleだけ、ダークモード捨て、多言語捨て、...

書き終わったら、その「1機能」だけが動くものを、Claude Codeに作ってもらってください。

次のレッスン予告

MVPの設計が固まったら、次は 実装の手触り を取りに行きます。

Lesson 04（実装編：PubMed APIで論文検索ツールを作る）で、APIを叩く感覚を1本通しでつけます。AIサービスじゃなくて公的APIから始めるので、料金の心配なしで「動いた」体験ができます。

その先の Lesson 05（GitHub + Vercel）で、できたものを世界に公開します。