AIで「実行」が潤沢になった。創業者に必要なのは4つの台帳だ

リード

Anthropicの『The Founder’s Playbook』は、Idea、MVP、Launch、Scaleという4段階で構成されている。しかし、より重要なのは各段階の名称ではない。実行コストが下がるほど、スタートアップにはエビデンス、コンテキスト、注意力、複利という4つの歯止めが必要になる。

少し前まで、説得力のあるプロトタイプを作ること自体が、創業者にとって大きな関門だった。

技術共同創業者を探すか、開発者を雇う資金を用意する必要がある。要件を変えれば、スケジュールも後ろにずれる。コストと待ち時間は厄介だったが、「この機能は本当に必要か」「この課題には解く価値があるか」を何度も考える時間にもなっていた。

いま、その物理的な抵抗が急速に小さくなっている。エンジニア経験のない創業者でも、coding agentと数回やり取りすれば動くアプリを作れる。市場調査、競合分析、投資家向け資料、日々のオペレーションも、AIを組み込んだワークフローに任せられるようになった。

これは、ものを作れる人の範囲を大きく広げる変化だ。同時に、プロトタイプが持つ意味も変える。画面が動くことは、モデルがソフトウェアを生成できる証明にはなる。だが、顧客がその製品を必要としている証明にはならない。

Anthropicが2026年5月に公開した36ページの『The Founder’s Playbook: Building an AI-Native Startup』は、この緊張関係を繰り返し扱っている。スタートアップの歩みをIdea、MVP、Launch、Scaleの4段階に分け、それぞれに目標、次の段階へ進む条件、典型的な失敗を示したものだ。

これを「一人会社の作り方」とだけ読むと、肝心な変化を見落とす。AIは起業の基本原則を無効にしたのではない。希少なものの置き場所を変えた。開発時間の希少性は下がり、判断の希少性は上がる。アウトプットは増えたが、信頼できる証拠は増えていない。機能は簡単に追加できても、一貫したプロダクト文脈を保つのは依然として難しい。

創業者の仕事に引き寄せて言えば、派手な結論ではない。AIネイティブなスタートアップは、初日から4つの台帳を管理する必要がある。

台帳1：エビデンス

Idea段階で最も危険なのは、自分自身を納得させるほど出来のよいデモを、早く作りすぎることだ。

AIは質問の方向に沿うのがうまい。ある市場へ参入すべき理由を求めれば、市場動向、規模、顧客の不満をすぐに整理する。既存プレイヤーが弱い理由を聞けば、それらしい競合分析を返してくる。

資料が網羅的に見えても、結論まで信頼できるとは限らない。創業者の直感を補強するためだけに使えば、AIリサーチは確認バイアスを高速化する装置になる。

だからIdea段階では、ビジョンを書いた企画書とは別に、エビデンスの台帳を持ちたい。少なくとも、次の4項目を分けて記録する。

• チームはいま何を信じているか
• その判断を支える実際の行動や一次情報は何か
• どの発見が仮説と矛盾しているか
• 新しい証拠を受けて、何を変えたか

海外営業を長く経験した創業者が、中小メーカー向けの「AI見積もりアシスタント」を作るとしよう。最初のバージョンは週末でも作れる。顧客のメールを読み、仕様を抽出し、英語の見積書を作成する。見た目だけなら、すでに製品らしい。

しかし顧客インタビューで聞くべきなのは、「AIで見積もりを作れるなら使いますか」ではない。直近の見積もりについて聞く。どれくらい時間がかかったか。どこで止まったか。誰の承認が必要だったか。なぜ受注できたのか、あるいは失注したのか。

5件ほど話を聞くと、英文メールを書く時間は数分にすぎないと分かるかもしれない。本当の遅れは、原材料価格が複数のスプレッドシートに散らばっていること、非標準仕様を工場長に確認しなければならないこと、顧客ごとの割引条件が担当者の記憶にしかないことから生まれている。

最初のデモが無駄になったわけではない。役割が変わったのだ。解くべき課題が「英語の見積もりメールを書けない」ではなく、「見積もりに必要な情報が時間どおりに集まらない」ことだと見抜く道具になった。

AnthropicがIdea段階を抜ける条件として挙げる内容はシンプルだ。誰が、どのような高頻度または高コストの状況で困っているかを具体的に言えること。調査で明らかになった課題に解決策が向いていること。そして、確実ではなくても、MVPへ進む判断を勘ではなく証拠で説明できることだ。

この段階でAIに任せたいのは、味方よりも反対役である。失敗した類似製品を探させる。顧客がExcelを使い続ける理由を説明させる。資金力のある競合がどう勝つかをシミュレーションさせる。整った市場レポートより、見たくなかった事実を早く見つけるほうが価値は大きい。

台帳2：コンテキスト

MVP段階に入ると、多くのチームは自然に「作るモード」へ移る。プレイブックの見方はもう少し厳しい。MVPも引き続き証拠を集める装置であり、検証対象が課題から解決策へ変わっただけだ。

ユーザーは中核となる操作を完了したか。1週間後、1か月後にも戻ってきたか。料金を払い、同僚に勧め、日常のワークフローに組み込んだか。MVPが生み出すべき証拠は、こうした行動である。機能数、公開初日の登録数、知人からの好意的な反応は気分を上げてくれるが、継続利用の代わりにはならない。

AI開発は、別の問題も持ち込む。スコープがほとんど摩擦なく広がることだ。以前なら1 sprintかかった機能が、午後の数時間で追加できる。個々の要望が安く見えるからこそ、方針を変えた自覚がないまま製品の焦点がぼやけていく。

先ほどの見積もりアシスタントを考えてみよう。最初の顧客はCRMを求める。2社目は配送追跡、3社目は通関書類の自動生成を求める。どれも取引に隣接し、AIですぐに作れそうだ。3か月後、半完成のモジュールを十数個抱えながら、見積もりに必要な情報を安定して集めるという核心部分が未完成、ということも起こる。

2つ目の台帳には、プロダクトとコードベースの継続的なコンテキストを残す。重い文書制度は要らないが、次の問いには答えられるようにしたい。

• 現在の製品はどの課題だけを解き、何を明確に対象外とするか
• なぜこのアーキテクチャを選んだか
• 変更してはいけない依存関係やセキュリティ境界は何か
• どのユーザー証拠が出ればスコープを広げるか
• 今回の大きな変更で、新たにどの仮説を持ち込んだか

ここで重要になるのが、プレイブックのいうagentic technical debtだ。AIが一つの悪いコード片を書くことだけが問題なのではない。毎回のセッションが、断片的な情報からプロジェクトの歴史を推測し直すことが厄介なのだ。ある日は依存ライブラリを増やし、別の日は異なるデータ構造を導入し、その次は元の権限モデルを迂回する。各部分は動いても、システム全体を説明できる人がいなくなる。

Claude Codeを使うチームなら、CLAUDE.mdにプロジェクト記憶の一部を持たせられる。他のツールではファイル名が変わるが、原則は同じだ。agentを毎朝「初出勤」にしてはいけない。スコープ、アーキテクチャ判断、指標の定義、変更履歴は、人とagentの両方に向けて書く。

セキュリティも同じ台帳に入る。動くコードだからといって、認可、データ分離、入力検証、依存関係の安全性が担保されるわけではない。リリース前のAIコードレビューは一部の問題を見つけられるが、認証、秘密情報、顧客データの扱いなどでは、セキュリティツールや必要な人間のレビューを置き換えられない。

非技術系の創業者にとって、「公開できる」と「運用責任を負える」の間には、まだ埋めるべき距離がある。

台帳3：注意力

MVP段階では、製品が存在する価値を証明する。Launch段階で問われるのは、事業が壊れずに成長できるかどうかだ。

初期には、創業者がすべての顧客会話とプロダクト判断に参加することが強みになる。情報が集まり、フィードバックも速い。しかし利用者が増えると、同じ働き方が会社の速度制限になる。サポートチケットは創業者の返事を待ち、値引きは承認を待ち、週次レポートは創業者が思い出した週だけ作られる。

ここですぐに自動化ツールを増やす必要はない。まず2週間、創業者に届く反復作業と意思決定をすべて記録する。それが注意力の台帳になる。各項目について、次のように問い直す。

• なぜこれは自分を通る必要があるのか
• ルールにできるか、別の人へ渡せるか
• 通常ケースは自動で処理し、例外だけを上げられるか
• 1週間不在にしたら、どこで仕事が止まるか

見積もりアシスタントが20社の有料顧客を持つようになったとしよう。創業者はまだ価格表を手動で取り込み、書式エラーを直し、顧客の声を整理し、チームにフォローアップを促している。これらをまとめてagentへ渡しても、運営モデルが良くなるとは限らない。

長く動くワークフローには、明確なトリガー、信頼できるデータソース、判断ルール、ログ、失敗時の行き先、そして責任を持つ人が必要だ。

標準価格表は自動で読み込み、検証できる。確信度の低い素材マッチングは人間の確認キューへ送る。割引上限を超える見積もりは責任者が承認する。週次のフィードバック要約は自動生成しても、プロダクトの優先順位は人が決める。

AIの役割は、情報と定型作業を正しい場所へ運ぶことだ。創業者は、価格設計、重要顧客、プロダクトの方向性に時間を使う。

プレイブックはこの変化を、「仕事をする人」から「仕事が進むシステムを設計する人」への移行として捉えている。価値は工数削減だけではない。創業者の頭に閉じていた判断を、点検でき、引き継げ、改善できる組織資産へ変えることにある。

この段階では、セキュリティとコンプライアンスも公開前の一度きりのチェックでは済まない。顧客データ、決済、法人契約を扱い始めたら、継続的なプロダクト運用になる。誰が何にアクセスできるか。インシデントをどう上げるか。文書をいつ更新するか。監査ログをどこに残すか。

創業者が常に火消しできることを前提にした成長は、まだ再現可能な仕組みではない。

台帳4：複利

基盤モデル、コード生成、汎用agentを競合も使えるなら、「AIを使っています」は堀にならない。Scale段階で積み上げたいのは、週末では複製できない深さだ。

Anthropicは、領域知識、ユーザー行動データ、顧客ワークフローへの統合を挙げている。3つとも、同じ問いに向かっている。使われるほど、その業界と利用者に合う製品になっているか。

見積もりアシスタントの価値は、少しずつ業務理解へ移る。特殊な単位、素材の別名、最小発注量、顧客別の承認経路、見積有効期限、注文を赤字にする例外。現場で遭遇した例外を、ルール、テスト、製品機能のいずれかに変える。時間がたつと、単に機能一覧が長くなるのではなく、実務に沿って育った知識地図ができる。

ユーザーデータも、適切な許可のもとで収集し、保護し、フィードバックループに変えて初めて複利を生む。どの提案が採用されるか。どの項目が頻繁に修正されるか。どの例外で見積もりが差し戻されるか。こうしたパターンは製品改善につながる。

ただし、データ量だけでは優位性にならない。どのシグナルを見るか、どこにバイアスが入るか、プライバシー境界の内側でどう改善するかをチームが理解している必要がある。

最後は、ワークフローへの入り込み方だ。たまに開くチャット画面だけの製品なら、次の高性能モデルに置き換えられやすい。メール、ERP、承認、会計システムにつながり、顧客がその上に安定した業務手順を築いていれば、切り替えはツール選定ではなく業務改革になる。

その粘着性は、顧客データを人質にして作るものではない。明確な権限、監査可能なインターフェース、実用的な入出力機能は、解約を促すどころか企業顧客の信頼を強くする。

複利の台帳で見るべきなのは、この製品が昨日よりどれだけ深く顧客の仕事を理解したかである。

4段階で混同してはいけない「進捗」

AIネイティブとは、会社をAIへ明け渡すことではない

Anthropicのプレイブックには、当然ながら同社の製品設計が反映されている。短い対話にはClaude、ファイルや外部システムをまたぐ知識作業にはClaude Cowork、ソフトウェア開発にはClaude Codeという分担だ。創業者がそのまま採用する必要はない。

製品名を外しても、運営の論理は残る。調査、開発、オペレーションが加速した会社ほど、エビデンス、コンテキスト、注意力、複利を意識して管理しなければならない。

そうしなければ、AIは曖昧な仮説をより速くコードにする。記録されなかった判断をより速く技術負債にする。創業者の一時的な思いつきをより速く業務プロセスにしてしまう。

AIネイティブ企業かどうかは、agentの数や従業員の少なさでは決まらない。実行速度が突然上がったとき、それでも「なぜ動くのか」「何を証拠に決めたのか」「いつ止まるべきか」を説明できるか。

それが、新しい創業者向けプレイブックの最も重要な1ページなのかもしれない。

出典

本稿は、Anthropicが2026年5月14日に公開した公式ブログおよび36ページの電子書籍『The Founder's Playbook: Building an AI-Native Startup』をもとに、独自に要約・発展させたものです。本文の「AI見積もりアシスタント」は説明のための架空事例で、特定の企業を指すものではありません。