こんにちは、株式会社TIMEWELLの濱本です。
先日、独立を考えている知人に「アプリのアイデアはあるけど、エンジニアを雇うお金がなくて動けない」と相談されました。その場でClaude Codeを開いて、彼の構想を10分ほど日本語で打ち込んだら、ブラウザで動く試作品ができあがりました。彼は画面をタップしながら「あ、ここ違う。こういう順番じゃない」と、それまで言葉にできなかった中身を次々に話し始めました。作るハードルはもう、驚くほど下がっています。
だからこそ、ここで一つ、逆説めいたことをお伝えしたいのです。誰でも作れる時代の勝ち筋は「うまく作ること」ではなく「気持ちよく捨てること」にあります。AIで試作が一瞬になったぶん、多くの人が「作る」に逃げ込み、作ったものに執着して身動きが取れなくなります。この記事は、AI（とりわけClaude Code）を相棒に、最初から捨てる前提でMVPやMockを回す実践的なやり方をまとめたものです。この記事は新規事業の作り方を順を追って解説するシリーズの一本で、全体の地図は新規事業フレームワーク完全ガイドにあります。手を動かす前に、いま自社にAI活用の余地がどれくらい残っているかを知りたい方は、AIリテラシー診断を先に試しておくと、後半のAIの使い方がすっと入ってくるはずです。
そもそもMVP・Mockは「小型版の製品」ではありません
MVPやMockと聞くと、多くの人が「本番の製品を小さくしたもの」を思い浮かべます。ここが最初のつまずきです。MVP（Minimum Viable Product、実用最小限の製品）は、製品の縮小コピーではありません。仮説を確かめるための、動く実験です。言い換えると、動く仮説そのものです。目的はコードを書くことでも、良いものを作ることでもなく、最速で仮説を検証すること、もっと正直に言えば、最速で自分の間違いを見つけることにあります。
なぜ「文章で説明する」のではなく「動くものを見せる」のか。理由は、動く画面が会話の解像度を一気に上げるからです。同じ「顧客管理の画面」という言葉でも、頭の中に思い浮かべる絵は人によってまるで違います。文章で百回説明しても埋まらない認識のズレが、動く画面を一枚見せた瞬間に「あ、そういうことね」と揃います。私の体感では、動くものを前にした会話は、資料を前にした会話の何倍も具体的になります。相手が指で画面を触りながら「ここが違う」と言ってくれるからです。
言葉の整理も先にしておきます。Mock（モック）は、中身が動かなくても画面や体験の見本を見せて反応を測るもの。PoC（Proof of Concept、概念実証）は、技術的に実現できるかを確かめる実証。Prototype（プロトタイプ、試作）はその総称に近い言い方です。さらに検証の型として、後で詳しく触れるSmoke Test（スモークテスト、需要があるかを軽く煙で確かめる）、Concierge（コンシェルジュ、裏で人が手作業でサービスを提供する）、Wizard of Oz（オズの魔法使い、裏は手動なのに表は自動に見せる）といった呼び名があります。そして今回の主役が、Throwaway（スローアウェイ、使い捨て）という考え方です。
この記事では、架空の新規事業「カムバックサロン」を例に話を進めます。個人経営の美容室オーナー（1席か2席、年商800万円ほど）向けに、来店の間隔が空いてきた常連客を自動で見つけ、LINEで再来店クーポンを送るツール、という設定です。あなた自身の事業に置き換えながら読んでみてください。
なぜ「捨てる前提」で作るのか
MVPのコードは8割方捨てる前提で書きます。これがThrowawayの発想です。捨てる前提だと決めた瞬間、ふだんは罪悪感を覚える手抜きが、全部正しい判断に変わります。ノーコードのツールで組んでいい。データはベタ打ちのハードコードでいい。裏側は人力の手動運用でいい。「将来のスケール」は完全に無視していい。どうせ捨てるのだから、拡張性もきれいな設計もいりません。必要なのは、仮説を確かめられる最小の一点だけです。
逆に、少しでも完成度を上げようとした瞬間、Mockは「試作品」から「作品」に格上げされます。作品になると、人は捨てられなくなります。「せっかくここまで作ったのだから」という気持ちが、事業の判断を鈍らせるのです。これはサンクコスト（sunk cost、すでに払って戻ってこない費用や労力）の罠と呼ばれます。初期に大きく作り込むほど、撤退や方向転換の判断ができなくなります。逆に軽く作るほど、間違っていたと分かったときに身軽に捨てて次へ進めます。捨てやすさは、そのまま学びの速さになります。
ここに、AI時代ならではの落とし穴があります。作ることが簡単になったぶん、人はいくらでも「作る」に逃げ込めるようになりました。顧客と話すのは怖いし、面倒だし、否定されるのは痛い。それに比べれば、部屋にこもってAIと一緒にMockを磨いているほうがずっと快適です。だからこそ、Vibe Coding（AIと対話しながら感覚でコードを作っていくやり方）の本当の勘所は「作る勇気」ではなく「捨てる勇気」にある、と私は考えています。誰でも作れる時代に事業の輪郭を決めるのは、逃げずに捨てられるかどうかです。
4種のMVPを「安く早く検証できる順」で選ぶ
いきなり動くプロダクトを作り始めるのは、たいてい遠回りです。検証したいことに合わせて、一番安く早く確かめられる手段を選びます。代表的なのが次の4種で、上から順に安くて速いと覚えてください。
| MVPの種類 | 何をするか | 何を確かめるのに向くか |
|---|---|---|
| Smoke Test | ランディングページと広告だけ出す | 需要がどれくらいあるか |
| Concierge | 裏側を全部人力でサービス提供 | その価値が本当に刺さるか |
| Wizard of Oz | 裏は手動、表は自動に見せる | 体験やUIが成立するか |
| Mechanical | 実際に動くプロダクトを実装 | 動くものとして機能するか |
Smoke Testは、まだ何も作らずに需要量を測る方法です。サービス紹介のページを一枚だけ用意し、広告を少額回して「申し込む」ボタンが何回押されるかを見ます。有名なのはDropboxやZapposの逸話で、製品が完成する前に紹介動画やページで反応を集め、需要を確かめてから本格開発に進んだと言われています。Conciergeは、システムを作らずに自分が手作業でサービスを届けてしまうやり方です。Wizard of Ozは、利用者から見ると自動で動いているように見えるのに、裏では人がせっせと手を動かしている状態を指します。そしてMechanicalが、いわゆる動くプロダクトの実装です。
やってはいけないのは、確かめたいことが「価値が刺さるか」なのに、いきなりMechanicalに飛ぶことです。フル実装してから「作ったけど誰も使わない」と気づくのは、最も高くつく失敗です。カムバックサロンの場合、一番不安なのは「オーナーがお金を払ってでも欲しがるか」でした。ですからまずConciergeを選びます。知り合いのオーナー数人ぶんの顧客リストを自分の手で預かり、離反しかけの常連を洗い出し、送るべきLINEの文面まで作って渡してみる。人力でやって喜ばれるかどうかで、価値の有無が分かります。並行して、自動で動いているように見せるWizard of Oz用に、次に説明するダッシュボードのMockだけ用意しておく、という組み立てになります。
どのMVPを選ぶかで迷ったら、AIに壁打ち相手になってもらうのが早いです。次のプロンプトは、あなたの事業仮説を渡すと「いま作るべき1つ」を理由つきで判定してくれます。
あなたはリーンスタートアップとY Combinatorの方法論に精通した新規事業メンターです。私の事業仮説に対して、4種のMVP（Smoke Test＝ランディングページと広告で需要量を測る / Concierge＝人力でサービス提供する / Wizard of Oz＝裏は手動で表は自動に見せる / Mechanical＝動くプロダクトを実装する）のうち「いま作るべき1つ」を、理由つきで判定してください。いきなり作り込むのではなく、一番安く早く検証できる方法を必ず優先してください。
【私の情報】
・検証したい主仮説（1つだけ）：誰が・どんな状況で・何に・いくら払うか
・いま一番不安なこと：需要があるか / 価値が刺さるか / 体験が成立するか / 動くか
・使える時間：週◯時間 / 予算：◯円 / コードは書ける・書けない
【出力してほしいこと】
1. 推奨するMVPの種類と、それを選んだ理由
2. 逆に「いま作らなくていいもの」
3. この1週間で最初にやる具体アクション3つ
需要そのものが読めないときは、その前にどれくらいの市場があるのかを大づかみで押さえておくと判断が楽になります。市場規模の見積もりはTAM・SAM・SOMの出し方にまとめてあります。
Claude Codeで、その日のうちに動くMockを作る
「価値が刺さるか」の手応えがつかめたら、次はWizard of Ozやその先で使う、動くMockが欲しくなります。ここで私が唯一おすすめするのがClaude Codeです。日本語で「こういうものを作って」と打つと、そのままコードを書いて動くものにしてくれるAIツールで、2026年時点なら月額数千円程度の個人向けプランから始められます。プログラミングの経験がなくても、その日のうちに動くMockが手元にできる、というのは数年前には考えられなかったことです。
命令のコツは、たった4点を普段の日本語で書くことです。誰向けか。何のためか（顧客のどんな用事を片づけるか）。必要な画面は何か（3画面以内に絞る）。見た目のトーンはどうか（色やスマホ優先など）。この4点に加えて、技術的な条件を少し足します。ブラウザで開けばすぐ動く1ファイルにすること、ログインなしでダミーデータで動くこと、画面の隅に小さく「v0.1（試作版）」と出すこと、凝ったデザインは不要でまず動くことを最優先にすること。この「v0.1」の一言が地味に効きます。完成品と誤解されるのを防いでくれるからです。
自分で命令文を組み立てるのが難しければ、それ自体をAIに作ってもらえます。次のプロンプトに情報を渡すと、そのままClaude Codeに貼り付けられる命令文が返ってきます。
あなたはClaude Code（日本語で指示するとコードを書いてくれるAI）に渡す「Mock作成の命令文」を組み立てるアシスタントです。私が渡す情報から、そのままコピペでClaude Codeに投げられる日本語の命令文を1つ作ってください。
【命令文に必ず含める4点】
1. 誰向けか
2. 何の目的か（顧客のどんな用事を片づけるか）
3. 必要な画面（3画面以内）
4. 使うダミーデータと見た目のトーン（色・スマホ優先など）
【命令文に入れる技術条件】
・HTML/CSS/JavaScriptの1ファイル（index.html）で、ブラウザで開けばすぐ動くこと
・ダミーデータを入れて、ログインなしで動くこと
・画面の隅に小さく「v0.1（試作版）」と表示すること
・凝ったデザインは不要。まず動くことを最優先にすること
【私の情報】
・誰向け：（ ）／目的：（ ）／画面：（ ）／データ・トーン：（ ）
カムバックサロンでこのプロンプトを回すと、たとえば次のような命令文が返ってきます。これはそのままClaude Codeに貼って使えます。
個人経営の美容室オーナー向けに、離反しかけの常連客を見つけて再来店クーポンを送るWebアプリのMockを作ってください。画面は3つです。(1)顧客一覧ダッシュボード（氏名・最終来店日・平均来店周期・離反リスクを赤/黄/緑で色分け表示）、(2)クーポン作成画面（割引率と有効期限を選ぶ）、(3)送信確認画面。ダミーの顧客データを20件入れて、ログインなしでブラウザですぐ動くようにしてください。HTML/CSS/JavaScriptの1ファイルにまとめ、スマホ表示を優先。画面の隅に小さく「v0.1（試作版）」と表示。デザインは凝らなくてよいので、まず動くことを優先してください。
作ってみて方向性がずれていたら、遠慮はいりません。「全部捨てて作り直して」と打てば、また一から作ってくれます。捨てるのが一瞬で済むのも、AIで作る大きな利点です。
自分の手で作らない道もあります。ノーコードのツールで組む、身近なITに強い家族に頼む、地域の商工会やよろず支援拠点のIT相談員（多くは無料）に相談する、クラウドソーシングで小さく発注する。どれも立派な選択です。大企業にお勤めの方から「会社のPCではこういうツールを使えない」という声をよく聞きますが、そこで諦める必要はありません。個人のPC、個人の時間、個人のメールアドレスを使う合法的なルートがあります。ただし就業規則は必ず確認し、会社の機密情報は一切入れず、あくまで架空のデータだけで試すこと。この線引きは守ってください。
顧客に見せるときの「捨てる前提」台本
ここが、この記事で一番お伝えしたいところです。MVP検証の失敗の8割は、Mockの出来ではなく「見せ方」で起きます。せっかく良い試作品を作っても、見せ方を間違えると、返ってくるのは本音ではなく社交辞令です。
人は、目の前に完成品らしきものを出されると、褒めようとします。「いいですね」「便利そう」という言葉は、たいてい相手のやさしさであって、事実ではありません。そして厄介なことに、作った本人は褒め言葉に酔います。酔ったまま、間違った方向へ全力で進んでしまう。これが新規事業でいちばんよく見る転び方です。
だから、見せる前に「捨てる前提」を宣言します。仕掛けは3つ。第一に、具体的な数字で言うこと。「これは実験段階の試作品で、来週には半分以上捨てます」。第二に、先回りしてクギを刺すこと。「褒められるとむしろ間違った方向に進んでしまうので、少し困るんです。率直に、これは要らない、と言ってください」。第三に、時間を区切ること。「今日は10分だけお願いします」。この前置きを読み上げるだけで、相手のモードが儀礼的な褒めから本音へ切り替わります。この台本も、自分の話し方に合わせてAIに作ってもらえます。
あなたは顧客インタビュー設計の専門家です。作ったMock（試作品）を顧客に見せる前に読み上げる「捨てる前提の前置き台本」を、私の言葉づかいに合わせて作ってください。目的は、顧客に「これは完成品ではなく、率直なダメ出しを集めるための実験だ」と伝え、儀礼的な褒め言葉ではなく本音を引き出すことです。
【台本に必ず入れる仕掛け】
1. 「実験段階の試作品」「来週には半分以上捨てる」と具体的な数字で言う
2. 「褒められると（間違った方向に進むので）少し困る」と先回りで言う
3. 「10分だけ」など時間を区切る
4. 最後に、率直なツッコミを1つお願いする一文
【私の情報】
・誰に見せるか：（ ）
・見せるMockの一言説明：（ ）
・私の普段の話し方：やわらかい / ビジネスライク など
出力は、そのまま読み上げられる話し言葉でお願いします。あわせて、面談の後に3行でメモすべき観点も教えてください。
カムバックサロンでは、知り合いのオーナー3人に「まだ実験段階の試作品で、来週には半分以上捨てます。褒められるとむしろ困るので、率直にこれは要らないと言ってください。10分だけお願いします」と前置きしてから見せます。狙いは、褒め言葉ではなく、痛い声と反証の一言を意図的に集めることです。顧客の数はまず5人から20人を目安にします。
コードが書ける人ほど落ちる3つの罠
皮肉なことに、コードが書ける人ほどMVPで転びます。作れてしまうからこそ、作りすぎてしまうのです。罠は3つあります。
一つ目は作り込み病です。Mockを完成品に仕上げようとして、CSSやアニメーションに凝り、気づけば3週間が過ぎている。対策は単純で、7日以上かけたら無条件でそのままリリースして次のサイクルへ進む、と決めておくことです。質の高さではなく、サイクルの多さで勝負します。二つ目は機能追加病です。顧客の要望を全部聞いて足していくうちに、Mockが肥大化していく。ここで大事な視点があります。顧客の「この機能が欲しい」という言葉は、たいてい「機能」の形をとった痛みの表れです。だから、要望をそのまま実装せず、「なぜそれが欲しいんですか」と3回くらい掘り下げて、根っこの痛みに翻訳してから、作るかどうかを決めます。要望を痛みに翻訳する感覚は、顧客の課題を見つける共感マップやバリュープロポジションキャンバスの書き方も助けになります。
三つ目が、いちばん危ない顧客回避病です。Mockづくりに何ヶ月もかけて、その間、顧客に一度も会わない。作っている間は前に進んでいる気がしますが、実際には何も検証できていません。対策は、毎週この一行を点検することです。「Mockを作った時間 ≦ 顧客と話した時間」になっているか。作る時間が話す時間を超えていたら、それは黄色信号です。カムバックサロンの週次レビューでも、Mock作成に8時間、顧客との対話に3時間、という週がありました。典型的な作りすぎ・話さなすぎの状態です。
スコープを1ページに畳み、週次で回す
作りすぎを構造で防ぐ道具が、スコープ管理です。おすすめはMoSCoW法という優先順位づけのやり方で、要件をMust（必須）、Should（あるとよい）、Could（できれば）、Won't（今回はやらない）の4つに仕分けます。ここで守るべき掟が一つ。Mustは5項目以下に絞ること。Mustに入れていいのは「これがないと仮説の検証そのものが成り立たないもの」だけです。Mustが6つ以上になったら、それは作りすぎのサインなので、半分に削ります。そして仕様書は1ページに収めます。1ページに収まらない仕様は、たいてい欲張りすぎです。期限は2週間から4週間で固定し、終わらないときは「プロダクト」ではなく「スコープ」を切ります。「あと1週間」を繰り返し始めたら、これも赤信号です。
この1ページ仕様書も、AIに叩き台を作らせると速いです。反証条件やPivot（方向転換）、Kill（撤退）の基準まで、最初から数値で入れさせるのがポイントです。
あなたはMVP設計の専門家です。私の事業について「1ページに収まるMVP仕様書」を作ってください。ふくらませず、2〜4週間で必ず終わる範囲に切ってください。
【前提】
・検証する主仮説（1つ）：（ ）
・その仮説が「外れた」と判断する反証条件：（ ）
・想定顧客と、実際に話せる相手の数：（ ）
【出力フォーマット】
1. 検証する仮説（1つ）と反証条件
2. MVPの種類（4種から1つ）
3. 主指標＋補助指標2つ（数値目標つき）
4. スコープをMoSCoW法で仕分け：Must（5項目以下）/ Should / Could / Won't
5. あえてやらないこと（Out of Scope）の明示
6. 期限（着手日 / 顧客に見せる日 / 判定日）
7. 続行・方向転換・撤退の判定基準（すべて数値で）
最後に「Mustが多すぎないか」を自己点検し、6項目以上なら削る提案をしてください。
作って見せたら、あとはBuild-Measure-Learn（作る・測る・学ぶ）のループを週次で回します。今週作ったもの、測った数字、顧客の生の声を並べ、続行するか、方向転換するか、撤退するかを決めます。この判断こそAIの壁打ちが効く場面です。自分では手放せない外れた仮説に、遠慮なくダメ出しをしてもらいます。
あなたはリーンスタートアップの週次レビューを回すコーチです。私が今週やったMock検証の結果を渡すので、Build-Measure-Learnの観点で振り返り、続行・方向転換・撤退のどれかを理由つきで提案してください。私が外れた仮説にしがみついていたら、遠慮なく指摘してください。
【私が渡す情報】
・今週の仮説と反証条件：（ ）
・作った/変えたもの と、かけた時間：（ ）
・測った数字：目標 vs 実績 / 会えた顧客数：（ ）
・顧客の生の声（良い声と痛い声を両方）：（ ）
・Mockを作った時間 と 顧客と話した時間：（ ）
【出力してほしいこと】
1. 想定通りだったこと / 想定外だったこと
2. 「Mockを作った時間 ≦ 顧客と話した時間」になっているかの点検（超えていたら警告）
3. 続行・方向転換・撤退の判定と理由
4. 方向転換するなら、顧客・価値・価格・チャネルのどれを変えるか
5. 来週の仮説と、作るもの・測るもの
カムバックサロンの2週目を、このレビューにかけてみます。「使ってみたい」はオーナー6人中4人。ところが「月3,000円払う」は6人中1人でした。生の声で多かったのは「離反しそうな客が一目でわかるのは良い。でも一斉配信で今のところ足りている」。しかもMock作成8時間に対して顧客との対話は3時間で、顧客回避病の気味も出ています。ここでの判定は方向転換です。値段を下げる前に、一斉配信では届かない「離反客だけへのパーソナルな文面」に価値の軸を寄せ直すか、顧客を「予約が埋まらず単価も上げたい新規開業のサロン」に変えるか。来週はMockに使う時間を減らし、顧客との対話を最低3件増やす。そう決めて、Mockはいったん捨てて次のサイクルへ回します。
愛着が湧いて捨てられないときは、捨てる儀式を用意しておくと手放しやすくなります。ファイル名に日付を入れておく、「採用」と「捨てる」のフォルダに分ける。小さな仕掛けですが、意外と効きます。
まとめ
AIとClaude Codeで試作が一瞬になった今、MVPやMockづくりの勝ち筋は、うまく作ることではなく、気持ちよく捨てることに移りました。最後に、今日から動くためのポイントを整理します。
- MVP・Mockは製品の小型版ではなく、動く仮説。目的は最速で自分の間違いを見つけること
- コードは8割捨てる前提で作る。作り込んだ瞬間に「作品」になって捨てられなくなる
- 4種のMVPは安く早く検証できる順に選ぶ。いきなりMechanicalに飛ばない
- Claude Codeに4点（誰向け・何のため・画面3つ以内・トーン）を日本語で渡せば、その日のうちに動くMockができる
- 見せる前に「捨てる前提」の台本を読む。失敗の8割は出来ではなく見せ方で起きる
- MoSCoWでMustは5項目以下、仕様は1ページ、期限は2〜4週間。週次で作る・測る・学ぶを回す
一番伝えたいのは、これだけです。作れる時代だからこそ、逃げずに捨てられるかどうかが、事業の輪郭を決めます。誰でも「作る」に逃げ込める今、あえて顧客の前に立って本音のダメ出しをもらいに行く人が、結局いちばん速く正解に近づきます。捨てる勇気は、才能ではなく習慣です。今週のMockに日付を入れて、来週きれいに捨てるところから始めてみてください。
AIを事業づくりの相棒として使いこなす感覚をチームで身につけたい、あるいは新規事業の立ち上げそのものに伴走が欲しいという場合は、AIコンサルティングのWARPで、こうした検証サイクルの設計をご一緒しています。何から手をつけるか自社の状況に合わせて相談したいときは、WARPの個別相談からお声がけください。
参考文献
- 濱本 隆太『顧客と歩むAI時代の事業のつくり方』(株式会社TIMEWELL)
- Eric Ries『The Lean Startup』(2011)
- Steve Blank『The Four Steps to the Epiphany』(2005)