結論：Claude Code で高速にプロトタイプ・MVP を作る鍵は「実装力」ではなく「スコープを削る判断力」と「Plan Mode で段取りを固めてから一気に書く流れ」にある。アイデアを最短で動くものに変えるには、仕様を最小化し、技術スタックを Claude Code に相談して即決し、Plan Mode で計画を承認してから実装し、動かしながら直すループを回す——この型をそのまま使えば、ひとりでも数時間で「触れる試作品」までたどり着ける。ただしプロトタイプは「動く」だけで、品質・セキュリティ・本番耐性は別物。捨てる前提のコードと本番化するコードの線引きを最初に決めておくのが、後で泣かないための前提だ。
- 要点1：仕様の最小化（コア機能1つに絞る）で実装量を 1/3 以下にできる
- 要点2：スタック選定は Claude Code に「最速で動かす前提」で相談して即決する
- 要点3：Plan Mode で計画を確認してから実装すると、手戻りと暴走を同時に防げる
対象読者：アイデアを素早く形にしたい個人開発者・スタートアップのエンジニア・社内で新規ツールの試作を任された人。今日できること：この記事の指示例（プロンプト）をコピーして、自分のアイデアを今日中に「動くプロトタイプ」まで持っていく。
「頭の中にあるアイデアを、とりあえず動く形で見せたい」——この瞬間が一番もどかしい。要件定義書を書いている間に熱が冷めるし、ライブラリ選定で半日溶ける。私が Claude Code を一番ありがたいと感じるのは、まさにこの「0→1の試作」フェーズなんです。正直、フルスクラッチでやっていた頃と比べて、最初の「触れるもの」が出るまでの時間が体感で 1/5 になった。本記事では、2026年6月時点の Claude Code で、プロトタイプ・MVP を最短で立ち上げる実践的な流れを、指示例とコード例つきで解説します。
そもそもプロトタイプと MVP は別物｜先に線を引く
高速開発で一番やりがちな事故が「プロトタイプのつもりが、いつの間にか本番コードになっていた」というやつ。最初に言葉の線引きをしておくと、後の判断が全部ラクになります。
- プロトタイプ（試作品）：アイデアが「成立するか」を確認するための使い捨て。ハリボテで OK。エラー処理もテストも最小限。動いて見せられればゴール。
- MVP（Minimum Viable Product）：実際のユーザーに使ってもらって学習を得るための「最小限の製品」。捨て前提ではなく、最低限のデータ保全とエラー処理は要る。
- 本番プロダクト：可用性・セキュリティ・テスト・運用が揃ったもの。プロトタイプのコードをそのまま昇格させてはいけない領域。
Claude Code は3つとも作れますが、どれを今作っているのかを宣言してから始めるのが大事。試作なら「動けば汚くていい」と明示すれば、Claude も余計な抽象化やテストを書かずに最速ルートを取ってくれます。逆に MVP 以上なら、最初からその前提でガードレールを敷く。ここを曖昧にしたまま走ると、捨てるはずのコードに愛着が湧いて本番に持ち込み、後で技術的負債として跳ね返ってくる。
ステップ1：アイデアを動くものにする最短ルート（スコープを削る）
プロトタイプ高速化の8割は「何を作らないか」で決まります。私はまず Claude Code に、アイデアを渡して「コア機能を1つに削らせる」ところから始めます。自分一人で削ろうとすると、どの機能も大事に見えて削れないんですよね。第三者（AI）に削らせるほうが冷静にいける。
以下は実際に使っている指示例。アイデアの一文と「制約」を渡すのがコツです。
これからプロトタイプを作りたい。あなたはプロダクトの壁打ち相手です。
【アイデア】
チームのSlack投稿から「決定事項」だけを抽出して、週次でまとめるツール
【ゴール】
今日中に「動いて触れる試作品」を1つ作る。本番品質は不要、使い捨て前提。
以下を出してください：
1. このアイデアの「コア価値」を1文で
2. 試作で必ず要る機能を1つだけ選ぶ（残りは「後回しリスト」へ）
3. 後回しにしてよい機能を理由つきで列挙
4. 試作で省略してよいもの（認証・DB永続化・エラー処理など）を明示
このプロンプトのポイントは「使い捨て前提」「1つだけ選ぶ」「後回しリスト」を明示していること。これがないと Claude は親切心から「認証もあったほうが」「DBも入れましょう」と機能を足してくる。試作フェーズでは、その親切が敵になる。
削る基準のセオリーはシンプルで、「これがないとアイデアの検証ができない機能」だけ残す。上の例なら「Slack投稿から決定事項を抽出する」がコアで、週次自動化・UI・保存はすべて後回しでいい。まずは手元の JSON を読み込んで決定事項を出力するだけのスクリプトで、アイデアの成否は判断できます。
ステップ2：技術スタックを Claude Code に相談して即決する
スタック選定で半日溶かすのは、もったいないの極み。私はもう自分で比較表を作るのをやめて、Claude Code に「最速で動かす前提」で決めてもらっています。ここで効くのが、選定理由まで言語化させること。後から「なんでこれ選んだんだっけ」とならない。
このプロトタイプの技術スタックを決めてください。
【前提】
- ゴールは「今日中に動かす」。学習コストの低さを最優先
- 私が普段使うのは Python と TypeScript
- 外部に公開せず、まずは自分のローカルで動けばいい
【お願い】
1. 最速で動く構成を1案だけ提示（迷わせないで）
2. なぜその構成かを2〜3行で
3. 「あえて使わなかった選択肢」とその理由も1〜2個
4. セットアップに必要なコマンドを順番に
「1案だけ」と縛るのが効きます。選択肢を3つ出されると、また悩む時間が発生する。試作フェーズでは「最適解」より「即決できる及第点」のほうが価値が高い。Claude Code はプロジェクトのファイルやあなたの過去のやり取りも踏まえて提案するので、たとえば既存のリポジトリがあれば、その構成に寄せた現実的な案を返してくれます。
なお、スタックが決まったら CLAUDE.md に「この試作の前提・スタック・やらないこと」を3〜5行で書いておくと、以降のセッションで前提がブレません。詳しくはCLAUDE.md設計・運用ガイドを参照してください。試作でも「やらないことリスト」を CLAUDE.md に明記しておくと、Claude が勝手にスコープを広げにくくなります。
ステップ3：Plan Mode で段取りを固めてから一気に実装する
ここが高速プロトタイピングの心臓部です。いきなり「作って」と投げると、Claude Code が思わぬ方向に大量のファイルを書いてしまって、結局読み直すハメになる。これを防ぐのが Plan Mode。実装の前に「何をどう作るか」の計画を提示させ、人間が承認してから実行に移る仕組みです（2026年6月時点で Claude Code に搭載）。
Plan Mode はキーボードの Shift+Tab でモードを切り替えて入ります。あるいは最初から計画を求める形でも使えます。手順はこうです。
- Plan Mode に入る：
Shift+Tabでプランモードに切り替える（ファイルを書き換えず、計画だけ立てる読み取り専用モード） - 計画を依頼する：「ステップ1で絞ったコア機能を実装する計画を立てて。ファイル構成・実装順・各ステップの完了条件を出して」と指示する
- 計画をレビューする：提示された計画を読み、過剰なファイル分割・不要な抽象化・スコープ外の機能がないか確認する
- 修正を伝える：「認証は試作では不要なので削って」「ファイルは1つにまとめて」など、計画に対して直接フィードバックする
- 承認して実装させる：計画に納得したら承認し、Claude Code に一気に実装させる
Plan Mode の何が嬉しいかというと、「実装が始まる前に方向のズレを潰せる」こと。コードを書いてしまってから「いや、そうじゃない」とやり直すより、計画段階で「そこは要らない」と言うほうが圧倒的に速い。試作では特に「最小構成で」と計画段階で念押しすると、Claude が1ファイルのスクリプトでサッと仕上げてくれます。
計画依頼の指示例はこんな感じ。
（Plan Modeで）
ステップ1で絞った「Slack投稿から決定事項を抽出する」機能だけを実装する計画を立てて。
制約：
- 試作なのでファイルは可能な限り1つにまとめる
- 入力はサンプルのJSONファイル、出力は標準出力でOK
- DB・認証・Webサーバーは作らない
- 各ステップに「動作確認の方法」を添えて
計画ができたら、私が承認するまで実装はしないで。
Plan Mode の使い込み方はClaude Code Plan Mode実践ガイドに詳しくまとめています。大きな変更を安全に進める基本作法なので、試作でもクセにしておくと事故が激減します。
ステップ4：動かしながら改善する（フィードバックループ）
プロトタイプは「一発で完成」を狙わない。むしろ「とりあえず動かす → 触る → 直す」の小さいループを高速で回すほうが、結果的に速いし、アイデアの良し悪しも早く見える。Claude Code はこのループと相性が抜群で、実行結果やエラーをそのまま貼り付けて「直して」と言えば、文脈を踏まえて修正してくれます。
私が回しているループはこう。
- 動かす：実装されたコードを実際に実行する
- 観察する：期待通りか、エラーは何か、出力は使い物になるかを見る
- フィードバックを返す：エラーメッセージや「ここがイマイチ」をそのまま Claude に渡す
- 直させる：修正してもらい、再度動かす（1へ戻る）
このとき、エラーは要約せずに全文を貼るのがコツ。スタックトレースを丸ごと渡すと原因特定が速い。改善の指示例はこう。
実行したら以下のエラーが出た。原因を特定して直して。
$ python summarize.py sample.json
Traceback (most recent call last):
File "summarize.py", line 14, in <module>
data = json.loads(raw)
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
あと、出力に「誰が決めたか」も含めたい。決定事項とセットで投稿者名も出して。
このフェーズで欲張って一気に直そうとすると、また方向がズレる。1ループにつき変更は1〜2個までに抑えると、何が効いたかが分かるし、Claude も的を絞って直せます。動くものができたら、関係者にその場で触ってもらう——試作の価値は「議論より早く、触って判断できる」ことにあります。実装テクニックの引き出しを増やしたい人はClaude Code 実践テクニック完全ガイドもあわせてどうぞ。
ステップ5：捨てる前提のコードと本番化の線引き
ここが、エンジニアとして一番大事な判断。プロトタイプが「いい感じ」だと、つい「このまま本番に」と思いがちですが、試作コードと本番コードは別物として扱うのが鉄則です。プロトタイプは「動く」を最優先に削りまくっているので、品質・セキュリティ・テストの観点ではスカスカ。これを本番に持ち込むと、後で必ず痛い目を見ます。
線引きの判断基準を、私はこう整理しています。
- そのまま捨てるべきコード：認証を省略している、エラー処理がない、ハードコードだらけ、テストゼロ——これらは試作の証なので、本番化では書き直す前提で考える
- 残してよい資産：アイデアの検証で得た「これは要る／要らない」の学び、固まった仕様、Claude に積み上げた CLAUDE.md やプロンプト群
- 本番化で必ず人がやること：セキュリティレビュー、入力バリデーション、エラーハンドリング、テスト追加、認証・権限設計——ここは AI が書いたものでも人間が必ずレビューする
「本番化する」と決めたら、Claude Code にもそのモードに切り替えてもらいます。指示例はこう。
このプロトタイプを本番化フェーズに進めます。試作モードから品質モードに切り替えてください。
以下を洗い出して、優先度つきのリストにして：
1. セキュリティ上の懸念（入力検証・機密情報の扱い・権限）
2. エラー処理が欠けている箇所
3. テストを追加すべき箇所
4. ハードコードを設定に外すべき箇所
※リストだけ作って。実装は私が1件ずつ確認しながら進めます。
重要なのは、ここで AI に丸投げしないこと。プロトタイプは「動く」が品質・セキュリティは別物であり、本番化の前には人がレビュー・テスト・堅牢化する——この前提を崩すと、動くだけの脆弱なコードを世に出すことになる。Claude Code はレビューの叩き台を高速で出してくれますが、最終判断はエンジニアの仕事です。セキュリティの観点を体系的に押さえたい人はClaude Codeで爆速フロント開発ガイドの堅牢化パートも参考になります。
よくある失敗パターン3つ
私自身がハマった、あるいは周りでよく見る失敗を共有します。先に知っておくと回避できます。
- ❌ 最初から全機能を作ろうとする：「どうせなら認証もDBも」と盛った結果、試作が終わらない
⭕ コア1機能だけ作って、まず触れるものを出す：検証に必要な最小機能に絞れば、当日中に動く - ❌ Plan Mode を飛ばしていきなり「作って」：意図とズレた大量のファイルが生成され、読み直しに時間を溶かす
⭕ Plan Mode で計画を承認してから実装：方向ズレを書く前に潰せる - ❌ 試作コードをそのまま本番に昇格させる：エラー処理もテストもない脆弱なコードが世に出る
⭕ 本番化は別フェーズとして、人がレビュー・堅牢化する前提で進める：捨てる勇気が品質を守る
まとめ｜「削る判断」と「段取り」が高速化の本体
Claude Code でプロトタイプ・MVP を高速に作るコツは、結局のところ「実装をどう速くするか」ではなく、「何を作らないかを決め、段取りを固めてから一気に書く」という設計判断にあります。スコープを最小化し、スタックを即決し、Plan Mode で計画を承認してから実装し、小さいループで改善する。そして、試作と本番の線をはっきり引く。この型は、ひとり開発でも、社内の新規ツール試作でも、そのまま効きます。
大事なのは、プロトタイプは「動く」ことがゴールで、品質・セキュリティ・本番耐性は別物だという前提を忘れないこと。本番化の前には、AI が書いたコードであっても人がレビューし、テストし、堅牢化する——ここを守れば、Claude Code は「アイデアを最速で形にする最強の相棒」になります。
今日からできる3アクション
- 手元のアイデアを1つ選び、Claude Code に「使い捨て前提でコア機能を1つに削って」と相談する
- 絞った機能を Plan Mode（
Shift+Tab）で計画させ、承認してから一気に実装させる - 動かして触り、エラー全文を貼って改善ループを2〜3回回し、当日中に「触れる試作品」を完成させる
次回予告：作ったプロトタイプを、サブエージェントと git worktree で並列に育てていく実践フローを解説予定です。
著者プロフィール
佐藤傑（さとう・すぐる）。株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援に携わる。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載を7回執筆。
