旧来の道は7ステップのループ、新しい道は4区間だけ

AIは起業のどの段階もスキップさせません。取り払ったのは、段階と段階のあいだにあった暗黙の紐づけです。かつては新しい段階に入るたび、自動的に人を増やし、必要なスキルを入れ替え、もう一度資金を調達することを意味しました。この紐づけがほどけました。

AIが各工程で肩代わりする能力を、ハンドブックはかなり具体的に書いています。リサーチでは、いつでも呼べる各分野の専門家として、競合分析・市場規模の試算・財務モデリング・投資メモの起草をこなします。コーディングでは、常時オンラインで手が止まらないエンジニアとして、かつてチーム総出だった仕事を創業者ひとりで出せる量まで圧縮します。運営では、必要なときだけ動く自動化チームとして、商談が進めば CRM が自動更新され、週次レポートが勝手に組み上がり、プロダクトの変更に合わせてドキュメントが同期されます。

結果として、創業者の役割の重心が丸ごと上に移ります。コードを書き、人を管理し、日々の雑務をさばく「実行者」から、アイデアを生み出し、これらのAIツールを指揮して形にする「オーケストレーター」へ。ハンドブックが特に強調するのは、ここでもっとも重い変化——業界経験はあってもエンジニアリングの素養がない人でも会社を立ち上げられるようになったことです。起業家の母集団が、エンジニアの外側へ広がります。

同じ Claude を、3つの異なる作業空間で使い分ける

ハンドブックが強調するのは、Chat・Claude Cowork・Claude Code の3つは背後が同じ Claude だという点です。違うのは外側にかぶせた作業空間だけ。インターフェースを間違えると、本来スムーズなはずの作業がぎこちなくなります。次の表はそのまま使える選択フレームです。

ハンドブックが示す肌感覚はこうです。Chat は会社を回すなかで次々に湧く小さな用事を処理します。びっしり書かれた投資メモから結論を一行で抜き出す、取締役会の前に一点だけ事実確認する、といった具合です。Claude Cowork は本当に時間を食う知識労働を担います。顧客との通話記録をフォルダごと整理してテーマ別の発見文書にまとめる、月曜の朝に連携ツールから指標を自動で引いて KPI レポートに仕上げる。Claude Code はチームのエンジニアが使う開発環境です。プロトタイプから本番へ、MVP 時代の古いコードの移行まで、もう人手が増えるのを待つ必要はありません。

素早い質疑応答、書き直し、ブレストなら → Chat（速い、対話的、設定不要）。リサーチや分析、あるいは自分のファイルとシステムを踏まえて完成文書に仕上げるなら → Claude Cowork（フォルダを読め、各種コネクタにつながり、スキルを動かし、定時実行できる）。コードを書く、テストする、ソフトウェアをリリースするなら → Claude Code（コードベースを直接読め、diff・git・開発環境が揃う）。3つとも背後は同じ Claude で、違うのは外側にかぶせた作業空間だけ。

コードを書く前に、「これは本物の課題か」を検証しきる

どの創業者も同じ場所から出発します。自分がどうしても考えるのをやめられない課題です。Idea 段階の心得は一言だけ——証拠が揃うまで作り始めない。この段階の仕事はリサーチ、顧客インタビュー、競合分析、そして自分に不利な証拠の誠実な評価。すべて、Claude Code に最初の本番コードを書かせる前に済ませます。

ハンドブックは Idea 段階を、順番に答えていく問いの連なりとして並べます。この課題は、会社を立ち上げる価値があるほど現実的で、具体的で、頻繁に起きるか。誰がぶつかっていて、それは市場を形づくるか。他に解こうとしている人はいるか、どこまで解けているか。本当に解決する案は何を満たす必要があり、自分のアイデアはそれを満たしているか。すべてが最後の問いに集約されます——これは作る価値があるか。

鍵は、具体にしてから動くことです。「経費精算はみんな面倒がっている」は観察にすぎず、検証できません。検証できる仮説に置き換えて初めて、話が立ちます。

卒業基準：3つの問いすべてに「はい」で進む

Idea 段階の卒業条件は、課題と解決策の適合を見つけることです。つまり、まず確かな定性的証拠（主に生身の人との会話から得るもの）で、現実の人の現実の課題を解いていると示す。そのうえで初めて解決策を作りにいきます。3つの問いがすべて「はい」になって、ようやく進めます。

この段階の3つの落とし穴

Claude で Idea 段階を走り切る

まず仮説を、本当に検証できるところまで磨きます。ここで Claude がもっとも役立つのは、具体を言わせてくることです。誰がこの課題を抱えているのか、どのくらいの頻度か、どれほど深刻か、今どうしているか。これらに答えられない課題記述は、まだ検証できる段階に達していません。

自分の課題記述を Claude に伝え、検証できる仮説へ磨いてもらう。悪い例：「契約レビューが遅すぎる」——これは検証できない。良い例：「中堅企業の社内法務チームは、契約レビュー1件に3日以上かけている。赤入れの修正をバージョン管理された単一文書ではなく、メールのやり取りで管理しているからだ」——これは検証できる。仮説を磨き終えたら、次は Claude に立場を反転させ、この仮説を覆す反証を専門に探させる。

次は競合です。ハンドブックは起業家に特有の癖を指摘します。competitor neglect（競合の軽視）——自分のビジョンと実行に集中するあまり、同じ領域で他社が何をしているかを構造的に過小評価してしまうことです。処方は、Claude に逆を演じさせること。ある競合がなぜ勝ち、自分がなぜ負けるのかを論証させます。

Claude に競合環境をレイヤー別に描かせる：直接の競合、間接の競合、潜在的な買い手、隣接領域から参入しうるプレイヤー。そのうえで、各レイヤーがなぜ自分にとって現実的な脅威なのかを論証させる——いちばん反論しやすい弱いバージョンを出させない。

続いて顧客インタビューの設計です。駆け出しの創業者がもっともよくやる失敗は、広く未来に向けた問い（「こういうプロダクトは使いますか」）を投げて、具体的な過去（「前回この課題にぶつかったとき、どう対処したか教えてください」）を聞かないことだとハンドブックは言います。自分で書いた質問を Claude にレビューさせ、誘導的なもの・仮定に基づくもの・広すぎるものを洗い出させましょう。

まず自分でインタビュー設問を書き、そのうえで Claude にレビューさせる。どの設問が誘導的か、未来の仮定を問うものか（例：「こういうプロダクトは使いますか」）、広すぎるか、あるいは本音ではなく気を遣った回答を引き出しやすいかを明示的に指摘させる。さらに、インタビュー中に相手がもっともはぐらかしやすい2〜3の急所について、掘り下げる追加質問を設計させる。

検証をやり切り、解決策のコンセプトもストレステストを通ってから、ようやく Claude Code の出番です。ここで作るのは本物のプロダクトではありません。生身の人に触ってもらえる機能サンプルを作り、顧客や投資家との会話で使います。

自分の解決策が依存する中核のインタラクションが何かを明確にし、Claude Code にはその1点だけを作らせる。できあがったら、検証済みのターゲット像に合う5人に触ってもらい、実際の反応を観察して、進めるか検証に戻るかを決める。

作っただけでは始まりに過ぎない。「手放せない」というユーザーを示せて初めて前進できる

MVP を純粋な施工フェーズだと捉える創業者は多いのですが、本質はやはり証拠集めです。違うのは、集める証拠が解決策についてのものになること。実在する、識別できる人たちが、使いたい・戻ってきたい・お金を払いたい・人に勧めたいと思うほどの価値を感じているか。

ハンドブックは MVP 段階に3つの目標を置きます。第一に、検証済みの課題を、実ユーザーが使うプロダクトに変えること。ロードマップの機能を詰め込んだ完成版ではなく、最小で最も絞り込んだ版です。第二に、速く、ただし複利で効いてくる技術的負債は背負わないこと。第三に、初日から持続的なコンテキストに投資すること。AIを増幅器のままにし、エントロピー源に変えないための鍵はここです。卒業条件は、プロダクトマーケットフィットの本物の証拠を得ること。つまり継続・課金・紹介のうち、少なくとも1つが実証されることです。

4つの落とし穴、うち2つがAI時代らしい

Claude Code を開く前に、まず Claude に何を作るのかを説明する：このプロダクトが解く中核の課題、対象ユーザー、今後6か月で現実的に見込む規模。そのうえで、MVP 段階で守るべきアーキテクチャ原則、避けるべき依存関係、この段階で意識的に受け入れるトレードオフを定義してもらう。この対話の成果物を CLAUDE.md として保存し、以後の Claude Code セッションが毎回読み込むアーキテクチャ文脈の文書にする。

実ユーザーが触れる前に、明確なレビュー指示とともに中核のアプリコードを Claude に通す：認証とセッション管理、APIレスポンスでのデータ露出、入力バリデーションとインジェクションのリスク、既知の脆弱性を持つ依存パッケージ。指摘は一つひとつ真剣に扱い、認証・鍵・データ処理に関わるものはすべて人によるレビューを通す。

ハンドブックの注記：Claude Code のAIスキャンは補助であり、セキュリティツールの代わりにはなりません。リスクの高い箇所では、人によるレビューの代わりにもなりません。別途 Claude Code Security があり、さらに脆弱性を洗い出して人がレビューするためのパッチを出しますが、刊行時点では数量限定のテスト版でした。使う前に利用可否を確認してください。

卒業基準：Sean Ellis テスト＋エフォートテスト

プロダクトマーケットフィットを得たと宣言し、MVP から Launch へ進むかは、最終的には創業者の直感と集めた証拠を組み合わせた判断になります。ハンドブックは使いやすい物差しを2つ示します。1つ目は Sean Ellis テスト。アクティブユーザーにひとつ聞きます——明日からこのプロダクトが使えなくなったら、どう感じますか。「非常に困る」と答えた比率が40%を超えれば、意味のあるPMFのシグナルです。

2つ目は力の入れ方テスト。プロダクトマーケットフィットの前は、継続を支えるのは創業者が押し続ける力です。頻繁に接触し、インセンティブを出し、人力でフォローする。見つかった後は、プロダクトが自分でそれをやり始めます。感覚が「あなたがユーザーを押している」から「プロダクトがユーザーを引き寄せている」に変わったとき——この力の入れ方の転換こそ、本物の変化が起きた最も明確なシグナルのひとつです。

3回イテレーションしても変化がないとき

3回以上イテレーションして、PMFの主要指標が一向に動かない。それは失敗ではなく、システムが正常に働いている証拠だとハンドブックは言います。MVP 段階はそもそも、間違った答えに深入りしすぎる前にこの情報を表に出すために設計されています。ここで次の一手を急いで決めず、まず Claude に診断を回させます。

3回以上のイテレーションを終えてもPMFの主要指標が明らかに動かないなら、次の一手を決める前に Claude に診断を回させる。継続データ、ユーザーからのフィードバック、当初の課題仮説をすべて渡し、3つ問う：このデータの中に、他と明らかに反応が違うセグメントはあるか？設計時に想定した価値と、ユーザーが実際に体験した価値のギャップは、ポジショニングの問題かプロダクトの問題か？現行プロダクトが本物のPMFに到達するには何が満たされる必要があり、いま見えている状況を踏まえてそれは現実的か？

「自分ひとりで背負う」から「システムが自走する」へ

MVP 段階がプロダクトの存在価値を証明する場だとすれば、Launch 段階はこの事業が育つ価値を証明する場です。プロダクトを本番に耐えるところまで仕上げるだけでなく、その下のインフラを固め、プロダクトのまわりに会社をきちんと立ち上げます。

ハンドブックが特に注意を促す転換点があります。Idea と MVP の段階では、会社が創業者中心なのは自然です。全体の状況把握と密なフィードバックループが必要だからです。Launch に入ってなお糸を一本残らず自分の手に握ろうとする創業者は、そこでボトルネックになります。目標は自分を会社から抜くことではなく、運営システムを組み上げ、創業者にしかできない意思決定へ注意を空けることです。

卒業基準：3条件の同時成立

自分がボトルネックになったと見抜く

手当ては、自分が手を動かしているすべてを徹底的に棚卸しすることです。最小のタスクから最もリスクの高い意思決定まで並べ、システム化できるもの、他者（自分でなくてよい）に渡せるもの、いまも創業者の時間と注意に値するものに仕分けます。

ハンドブックはさらに2つの宿題を名指しします。ひとつは、MVP 期にスピードのために背負った技術的負債。ここから利息がつき、放置するほど高くつきます。体系的なアーキテクチャ監査、狙いを定めたリファクタリング、テストカバレッジの実質的な拡大が要ります。もうひとつはセキュリティとコンプライアンス。実ユーザーのデータを扱う、決済を扱う、規制業種に売る——どれか一つでも始まれば、プロトタイプ段階では無縁だった要件がすべて適用されます。浮かび上がった項目は推奨ではなく、必ず直すものとして扱います。

Claude Code に MVP のコードベースの完全なアーキテクチャ監査をさせ、優先度順のリストを出させる：構造上の脆い箇所、テストカバレッジの穴、リファクタリング候補。そのリストを Claude に渡し、負債返済の作業を今後数スプリントに割り付けさせる：次のリリース前に必ず直すもの、新機能開発と並行できるもの、現段階では受け入れてよい負債。

堀はデータのフライホイールとワークフローへのロックインから育つ

Scale 段階に入ると、創業者の役割はビルダーから、外に向き合う会社の経営者へと再び移ります。日々の仕事はますます会社そのものについてのものになります。規模で見れば、数千ユーザーから数百万へ、単一市場から複数市場へ。目標は「ユーザーに張りついて直感で舵を切る」から、成熟した組織運営に支えられた体系的な成長の構築へ変わります。

AIネイティブのスタートアップにとって、この段階で築くべきは積み上げた深さに支えられた堀だとハンドブックは言います。プロダクトに埋め込んだ専門知識、プロダクトとユーザーが依存する他ツール／プラットフォームとの統合の深さ、そして独自のシステムデータとワークフローから生まれるものです。卒業条件はもはや単一のマイルストーンではなく、しきい値イベント——創業者が日々の運営を直接見る度合いが下がっても、会社が持続すること。

この3つのうち1つ。共通の前提は、成長が体系化され監査に耐えること、プロダクトの堀が検証に耐えること、組織運営が成熟して持続可能なことです。ここまで来れば——おめでとう、あなたの起業は賭けから事業になった、とハンドブックは書いています。

堀その1：ユーザーデータの複利フライホイール

ユーザーがプロダクトと関わるたび、行動シグナルが生まれます（どの出力を受け入れ、どれを拒んだか）。このシグナルがプロダクトロードマップに流れ込みます。時間が経つほど、自社のユーザーに固有のパターン、好み、エッジケースが見えてきます。これが複利の意味です。改善のたびにプロダクトが役立つようになり、利用が増え、フィードバックが増え、さらなる改善を押し出します。

このデータは時間に紐づき、文脈に固有で、模倣者には再現できないとハンドブックは強調します。何千人ものユーザーが自社プロダクトの中でワークフローを磨いて残した行動の指紋は、買ってこられません。

プロダクトのインタラクションデータの状況を Claude に渡す：何のデータをどれだけの期間集めたか、ユーザーが時間とともにどうプロダクトを使うようになったかについて何がわかっているか。そこからシグナルの強い行動パターンを3つ抽出させ、それぞれについて体系的なプロダクト改善へ変換できるフィードバックループを設計させる。さらに、堀のナラティブを1ページで起草させる：自分のデータフライホイールがどう回っているか、どれだけ回してきたか、そして潤沢なリソースを持つ競合が今日から追い始めても、なぜ2年では追いつけないのか。

堀その2：ワークフローへの深いロックイン

データのネットワーク効果はプロダクトを複製しにくくし、ワークフローの固定はプロダクトから離れにくくします。ユーザーが日々の運営で使う期間が長いほど、プロダクトは深く埋め込まれます。上に自動化を組み、人を訓練し、データソースや他ツールをつなぐ。彼らが編み出したプロンプト、磨いたプロセス、標準化した出力は、すべて自社プロダクトのやり方に沿って形づくられます。ここまで来ると、ベンダーの乗り換えはプロダクトの選択から、運用プロジェクト一式へと変わります。ハンドブックはまず Claude を使い、統合の深さで顧客を層に分けて、プロダクトがどこで粘り、どこはまだ深掘りが要るかを見よと勧めます。

Scale 段階の最難関：本当に手放す

初日から自分で手を動かしてきた創業者にとって、運営レイヤーを渡すことは構造の問題であると同時に心理の問題です。渡しすぎ・早すぎ、とくにAIの自動化システムへ渡しすぎると、創業者にしか出せない重要な背景を欠いたまま肝心の判断が下されます。握りすぎれば、また自分がボトルネックです。核心の難しさは、創業者の頭の中だけに、あるいは書かれていないワークフローに散らばって存在する組織的な知識を洗い出し、文書化され監査でき引き継げるシステムへ符号化することにあります。ハンドブックのやり方は、Claude にボトルネックの地図を描かせ、自分が1週間消えたらどうなるかをシミュレーションさせることです。

現在の運営レイヤーのボトルネック地図を Claude に描かせる：自分の手を通る必要があるワークフロー、意思決定、承認をすべて洗い出す。そのうえで、自分が1週間まったく不在ならそれぞれがどうなるかをシミュレーションさせる。止まってしまうワークフローが、いま自分が深く入り込みすぎて進行を遅らせている箇所である。

事例：堀が育つとはどういうことか

巻末には実在企業10社超の事例があります。「積み上げた深さ」を最もよく物語る数字が2つ。

4段階プロンプト早見表

ハンドブック全編の練習課題をここにまとめました。段階別に並べてあるので、自分がいる段階と照らしてそのままコピーできます。ツールの割り当ては変わりません——リサーチと戦略は Claude、コーディングは Claude Code、業務自動化は Claude Cowork。

創業者がやるべきことは変わっていない。本物の課題を見つけ、それを解決するものを作り、意義のある会社へ育てる。変わったのはそこへ至る道だ。AIは四半期を週に、かつて数か月を要した検証サイクルを一つの午後に圧縮した。The Founder's Playbook · Anthropic

ハンドブックがやったことは2つ。ひとつは各段階に「卒業基準」を用意し、「次へ進むべきか」を勘からチェックへ変えたこと。もうひとつは変化の指摘です——AIは「新しい段階に入るならチーム拡大と追加調達」という紐づけをほどきました。ボトルネックは「何を作れるか」から「何を作ると選ぶか」へ移ります。では、その「卒業基準」はどう止めてくれるのか。次の図をどうぞ。

4段階は Idea（アイデア）、MVP（最小限の実用版、いちばん核だけを作る）、Launch（公開）、Scale（規模拡大）。ハンドブックは各段階を「門」に変えます。小互が「中堅企業の経費突合を自動化するツール」を携えて、ひと通り歩いてみましょう。

4段階は4つの門のようなもの。各門は、その段階の卒業基準を満たして初めて通れます。満たせないなら、次へは進まない。ハンドブックは「次へ進むべきか」を勘から、チェックできる一覧へ変えました。

各門の卒業基準には、そのままコピーできる Claude プロンプトがついています（リサーチと戦略は Claude、コーディングは Claude Code、業務自動化は Claude Cowork。全10本は本文の早見表に、まるごとコピーで使えます）。さらに各段階には、AI時代に特有の落とし穴も。プロトタイプを検証と取り違える、機能を足しやすすぎてスコープがあふれる、AIに論証させると逆に自分を欺きやすい——見分け方と対策は本文にあります。

「AIで起業が速くなる」と言われてもピンと来ません。ハンドブックは具体的な物差しを出します。同じアイデアの検証が、かつては数か月、いまは一つの午後まで縮む。