AIネイティブなスタートアップの作り方

• AIが夜間に反復業務を処理しているあいだ、創業者はプロダクト改善に集中する新しい運営モデルであり、本当の変化は時間の使い方ではなく、会社が学習・反復・進化する速度にある
• AIネイティブ企業では運営モデル自体が変わり、少人数で調整を減らし、エージェントが反復作業を実行し、人は方向性・センス・関係性・検証・責任に集中する
• 移行は、業務のマッピング、コンテキストシステムの構築、最も単純な自動化の選定、反復業務のスキル化、品質を判定するevalの作成、週間改善ループの実行という段階で進む
• モデルは毎月入れ替わり改善され、互いに似通っていくため、会社固有の資産はコンテキストとevalのような運営システムにある
• 誰もが同じモデルを使う環境で本当の堀は規律（discipline）、つまり毎週業務をマッピングし、コンテキストを積み上げ、evalを書き、ループを回す一貫性にある

---

2つのスタートアップの対比

• 同じ市場で同じ月に創業した2社を午前9時に比較する
  • 1社目ではオペレーションリードが滞留したサポートチケットを処理し、アナリストが先週のダッシュボードを作り直し、創業者は誰も解決できなかった顧客通話案件のためにスタンドアップの最中で、全員が昨日の問題の後始末に追われ、プロダクトは停滞している
  • 2社目ではそれらすべてをエージェントが一晩で処理している。チケット分類、ダッシュボード更新、通話内の**解約リスク（churn risk）**の浮上まで完了しており、創業者はすでに問題を修正し、チームとプロダクトの改善に取り組んでいる
• 中核的な差は学習速度にあり、2社目は毎日より速く学び、そのレバレッジが数週間・数カ月・数年にわたり複利で蓄積していく

1段階 - 業務をマッピングする（Map The Work）

• 過去2週間で繰り返された業務をすべて列挙する。顧客通話ノート、リード調査、アウトバウンド草案、サポート分類、プロダクトQA、オンボーディング、リリースノート、投資家アップデート、週間指標、バグ再現、採用スクリーニング、請求書レビュー、競合モニタリングなど
  • 繰り返されるならエンコード候補であり、ほとんどの創業者のカレンダーには20〜40項目が存在する
  • 初期チームが正直に列挙すると、すでにルーティン化していた10〜15項目を見つける

• 自律性レベル分類

  • L1は人間専用。戦略的意思決定、最終採用、大口返金、法的署名、取締役会コミュニケーション
  • L2はAIが準備し、人が承認する。投資家アップデート草案、契約のレッドライン、価格ページの書き換え、サポートマクロ
  • L3はAIが実行し、人が監督する。インバウンド分類、ミーティングノートのルーティング、リード強化、テスト生成
  • L4は明確な境界内で自律。競合モニタリング、夜間レポート生成、既知ベンダーの請求書抽出、単純な異常検知

• 退屈なワークフローがたいてい勝つ

  • 週間戦略メモのような見栄えのいい業務よりも、毎日繰り返されるサポートのタグ付けのほうが10倍多く実行され、より多くの時間を取り戻し、きれいな正解データを提供する。頻度は名声に勝る
  • 最初の攻略対象は、頻度が高く、測定可能で、巻き戻し可能で、実際のボトルネックにつながる作業である

• 自動化してはいけない業務

  • まれで、不明確で、高い信頼を必要とし、不安定な業務は除外する
  • C.H. Robinsonのチームは1日1万件のメール分類をL4まで押し上げたが、監督が不可能になりL2へ戻した。量が誤分類コストを覆い隠していた
  • 良い成果物が何かを説明できないなら、まだエンコードの準備ができていないということであり、1回の誤出力で顧客関係を損なう可能性があるなら、ゆっくり進めるべきだ

• 開始構成

  • 1ページと3つのワークフローから始める。個人向け（受信箱分類、デイリーブリーフ、投資家アップデート草案）、顧客対応（通話要約、チケット分類、リード強化）、内部向け（テスト生成、請求書抽出、週間指標の記述）
  • 同時にあまりに多くの実験を行うと注意が分散し、20個の未完成パイロットを作ってしまう最も一般的な失敗モードを引き起こす

2段階 - コンテキストシステムを構築する（Build The Context System）

• コンテキストはAIネイティブスタートアップの**運用メモリ（operating memory）**であり、会社が自分自身について知っているすべてのことを、エージェントが読める場所に保管する
  • モデルは交換可能だが、コンテキストは本当の会社固有の資産であり、共同創業者のように働くエージェントと、混乱した臨時スタッフのように働くエージェントを分ける
  • 出力の書き直しにレビューより多くの時間がかかるなら、問題はプロンプトやモデルではなく、エージェントが会社を十分に知らないことにある

• 週次診断法

  • 代表的な作業を1つ、新しいエージェントにワークスペースのコンテキストだけを与えて渡し、次の行動を3つ求める
  • 強い提案が2つ以上出るならコンテキストは機能しており、一般論の回答が3つならコンテキストは貧弱で、プロンプトでは救えない

• Gitリポジトリ基盤

  • すべてのチームメンバーとエージェントが読める共有Gitリポジトリ1つから始める。バージョン管理、diff、人間とエージェントの双方による可読性、特定ベンダーのランタイムに依存しない点が利点
  • 7日目のワークスペースは、CLAUDE.md、context/company.md、context/product.md、context/customers.md、context/lessons.md、そしてアクティブな作業用のGTD.mdを含む単一ルートで構成できる
  • 手書きの40〜60行で維持する。避けるべきことの密な一覧を生成した400行の雑文より優れている

• 権限境界で分割する

  • 成長すると、共有会社リポジトリ + 機能別プライベートリポジトリ（営業、プロダクト、エンジニアリング、財務、サポート）、またはプロジェクト・顧客別のプライベートリポジトリ + 全社共有ルートに分かれる
  • エンタープライズ規模では、自前ホスティングのGitea、GitHub Enterprise、GitLabのようなプライベートGitサーバーで、ディレクトリ・リポジトリ単位の権限付与を行う
  • Blockの社内ハーネスGooseは、役割別スコープで同じアーティファクトストリームを読み取るが、スコープがずれた瞬間に公開発言と非公開取引コンテキストを混ぜ始める。境界は非常に重要だ

• システムに入る3種類のデータ

  • コネクタ。SaaS、API、MCPサーバー、メール、カレンダー、CRM、サポート、分析、GitHub、Linear、Stripe、ウェアハウス、ドキュメントから外部データを収集する
    • すべてのコネクタには識別子、スコープ権限、監査ログ、管理された認証情報が必要で、そうでなければ最大のセキュリティホールになる。ZitadelのようなIAMレイヤーが識別規律を担う
    • AnthropicのMCPコード実行タスクでは、サーバーフォルダのファイルシステムパターンで全ツール定義を事前ロードする方式に比べ、コンテキスト使用量を約15万トークンから約2千トークンへ、98.7%削減した
  • 会社が生成するデータ。仕様、顧客要約、意思決定、教訓、プロジェクトノート、運用ルールで、基本はMarkdown
    • 最も重要なルールは生データ（raw）と蒸留版（distilled）の分離である。通話録音が生データ、その通話から導かれた決定・顧客の異議・フォローアップ担当者・更新リスクが蒸留版であり、エージェントが実際に参照する対象となる
    • 意思決定ログは1行に1件ずつのappend-onlyで維持し、推論が結論とともに追えるようにする
  • データベースとストリーム。Postgresのプロダクトデータ、ウェアハウスのマーケティング、分析イベントのように、元データがすでに存在している場所
    • Markdownへ盲目的にコピーせず、DBをソース・オブ・トゥルースとして維持し、エージェントには制限付き読み取りユーザーを付与し、スキーマをエージェント向けファイル（data-models/postgres.md）に文書化し、許可されたクエリ・書き込みを明示する
    • デフォルトでエージェントが本番データを削除できないよう設定する。2025年半ばのReplit事件（コーディングエージェントがセッション中に本番DBを削除した）は、プロンプト指示がセキュリティ境界ではないことを思い出させる

• 高度版と出典追跡

  • 構造化されたコンテキストグラフ。エージェントが参照する前に、生データを人・会社・異議・約束・機能要望・更新リスク・フォローアップ・日付・決定・ソースリンクなどのエンティティと関係として処理する
    • 録音を保存する代わりに内容を抽出し、同じ人物・同じプロジェクトの通話をチェーンでつなぐことで、「Vandelay Industriesの更新リスクは？」に対し、正確な発言行を引用して回答できる
  • すべての要約は出典（録音、チケット、コミット、請求書、DB行）までたどれる必要がある。出典がなければ検証不能でもっともらしい要約が蓄積し、最初の誤答でエージェント全体への信頼が崩壊する
    • 出典があればエージェントは監査可能になり、チームメンバーはワンクリックでソースを確認し、意見の相違を数秒で解消できる

3段階 - 最も単純な自動化を選ぶ（Choose The Simplest Automation）

• すべてのワークフローをエージェント化しないこと。最良のシステムは、スクリプト、AI支援の人間、決定論的ワークフロー、エージェントの混合で成り立つ。
  • 創業者の役割は、品質基準を満たしつつ安全に回せる最も軽量なツールを選ぶこと。

• ツール別の適用

  • スクリプト - 決定論的なステップ（レポートのエクスポート、CSV変換、テスト実行、リンク確認、JSON検証、週次指標パックの整形）
  • AI支援の人間 - 会社の外に出す前に判断が必要な出力（投資家向けアップデート、創業者メール、価格コピー、契約メモ）
  • ワークフロー - 手順が事前に分かっている場合（通話収集→要約→異議抽出→CRMノート作成→フォローアップ生成）。エンジンは LangGraph、Temporal、Inngest、Prefect が順序・再試行・可観測性を担当。
  • エージェント - 経路を事前に決められない場合（本番バグ調査、市場リサーチ、異常なサポートケース、もつれた顧客アカウント）
    • Browserbaseのbbエージェントは、Slack対面の汎用エージェントとして、作業ごとに異なるスキルファイルとスコープ権限をロードする。作業別にボットを個別作成するより優れている（時間が経つとボット同士がずれていくため）。

• Harness - 6段階の安全レイヤー

  • Preflight - エージェントがトークンを使う前にコンテキストと権限を確認
  • Plan - タスク分解と提案ステップを可視化
  • Approve - 人間または判定モデルのゲートが悪い計画を実行前に遮断
  • Execute - タスクを実行
  • Verify - テスト・スキーマ・ルーブリック・例で出力を検証
  • Log - 次の反復が正解を持てるよう、起きたことを実行ファイルに記録

• ガードレールはコードと設定に置く（プロンプトではない）

  • 「本番データを削除するな」というプロンプトはセキュリティ境界ではない。
  • 交渉不可の項目 - 実行・日次コスト上限、再試行上限、最大ツール呼び出し深度、エージェント別スコープ資格情報、承認なしの本番書き込み禁止、コードの自動マージ禁止、全フリート用キルスイッチ
  • 2025年を通して発生した 再帰生成インシデント（エージェントが子エージェントを呼び続ける事象）は、Harnessが追いつく前に実コストを発生させた。上限は、モデルが指示を無視する機会より前、実行時に置かなければならない。

ステップ4 - スキルとevalのエンコード（Encode Skills And Evals）

• ここまではすべて準備であり、反復業務をスキルとしてエンコードし、evalで採点することが、会社を毎週少しずつ複利で成長させるエンジンになる。
  • スキルは反復作業のための再利用可能な指示 + 例。手で2回実行したあと、繰り返される部分をエンコードする。
  • すべてのスキルには明確な形が必要 - 範囲、入力、ロードするコンテキスト、手順、出力形式、例、エスカレーション規則、オーナー、実行ログ
  • 何を受け取り・返し・いつ助けを求め・誰が保守するかが書かれていなければ、それはスキルではなく長いプロンプトにすぎない。

• スキルテンプレート例（customer-call-synthesis）

  • Scope: 録音確保後の営業通話 / Inputs: 録音、アカウント記録、製品コンテキスト、進行中の案件
  • Load: ICP、価格、製品ロードマップ、異議分類体系 / Steps: 事実抽出→異議クラスタ化→リスク特定→フォローアップ作成
  • Output: CRMノート・顧客ブリーフ・機能要望・次のアクション / Examples: 想定ノート付きの過去通話3件
  • Escalate: 法務・セキュリティ課題、離脱リスク、エンタープライズ価格 / Owner: revenue lead / Eval: 想定抽出フィールド付きの過去通話30件

• 創業者にやさしいスキルから始める

  • 顧客通話の総合 - 元の録音から異議、機能要望、リスク、約束、次のアクションを抽出
  • インボックス分類 - 投資家・顧客・採用・運営メッセージを整理し、最初の3種類の返信下書きを作成
  • 投資家向けアップデート - 指標と意思決定から叙述を作成し、両方を引用
  • 価格ページ分析 - 公開中のページを最新の顧客異議ログと比較
  • 週次指標の叙述 - 何が変わり、何が壊れ、何を点検すべきかを説明
  • テスト生成 - 仕様をテストと下書きPRに変換

• evalの3層（順に積み上げる）

  • 第1に、人手ラベルの正解 - 実例で良い出力が何かを人間が示す
  • 第2に、決定論的チェック - コストゼロで明確な判定を提供（スキーマ妥当性、ソースと一致する数値、解釈可能なリンク、存在する引用、通るテスト）
  • 第3に、LLM判定 - 決定論的チェックが届かない部分だけ（文章品質、感情、ブリーフ適合性）。小さく速いモデルで十分だが、信頼する前に人手で示した例による補正が必要。

• ケーススタディ: 顧客通話の総合

  • 過去の通話30件を revenue lead がマーキング。重要な事実、異議、リスク、フォローアップを示す。
  • 決定論的確認 - 名前・契約金額・フォローアップ日付の週単位の正確性を確認し、ブリーフが通話らしく聞こえるかはLLM判定が担当。
  • およそ50回実行すると、たいてい同じ2つが壊れる。3人以上の通話で話者追跡に失敗するか、異なる2つの異議を1つに統合してしまう。これをクラスター単位で修正し、一貫して動くまで書き直す。

• ケーススタディ: アウトバウンドリード分類

  • 過去のリード300件を創業者がICP適合かどうかを yes/no でラベル付け。
  • 機械的確認 - 実在する会社か、ウェブサイトが読み込まれるか、従業員数が記入されているか。残りはICP説明に照らしてLLM判定。
  • evalが整えば、オープンソースのプロンプト進化ループ（GEPA, DSPy）が、ラベルに対して分類プロンプトを一晩中書き換える。創業者は最終プロンプトを読まず、重要なのはeval判定だけである。

• eval成熟の5段階

  • 1. 1つの例を手動確認 → 2) 作成したルーブリックで少数事例を採点 → 3) そのルーブリックを過去20〜300件に適用 → 4) エージェントが見たことのないホールドアウトセットでテスト → 5) スキルが動かそうとしていたビジネス指標を追跡

• リリース後に良好な状態を保つ - 毎週6つの数字

  • 受容率（acceptance rate）、オーバーライド率、実行あたりコスト、サイクルタイム、レビュー時間、インシデント数
  • 受容率が核心。およそ70%未満（軽微な編集は受容として計算）なら、自律レベルを上げる準備はできていない。
  • 受容率が低いとき、プロンプトの書き換えが正解であることはほとんどなく、たいてい次の4つのどれか - 実行時にコンテキストを追加する、スキル範囲を狭める、ファイルに動作例を追加する、担当させるべきでなかったケースに対する明確なエスカレーション規則を書く。

ステップ5 - チームをAIネイティブにする（Make The Team AI-Native）

• 創業者が先に始める。チームを新しい運営方式へ移す最速の道は、会社の文脈の中でライブで見せること。
  • カレンダー・インボックス・Slackから一晩で引き上げた朝のブリーフ、昨日の通話による顧客総合、仕様に対してエージェントがつないだテストPR、最後の指標パックから作った投資家向けアップデートの下書きを実演する。
  • 目標は キャリブレーション - エージェントレイヤーに何ができて何ができないかを直接見ること。
  • Jack Dorsey は2025年を通して毎朝何時間もこれらのツールを自ら扱ったあと、Blockを再編した。大規模な効率化リストラにつながり、その判断はエージェントを実際に使ったリーダーシップから生まれた。

• 初日から導入し、オンボーディングは成果物で終える

  • すべてのチームメンバーが最初のセッションで、その日にデプロイ可能な成果物（整理された顧客ブリーフ、サポートマクロ、テストPR、価格ページ批評）を持って帰る。実作業を生まない研修は翌週には忘れられる。
  • Ramp の Glass ツールは、すべてのオンボーディングセッションが新しい人のスキル・アーティファクト1つを共有ライブラリに追加して終わるというルールにより、3か月で日次ユーザー20人から約700人に増えた。

• 人の役割は大きくなる

  • 人間はシステムを設計し、関係を所有し、出力を判断し、責任を負う。エージェントは実行を担当する。
  • 狭い作業だけを回すチームメンバーはこのモデルでは露わになり、判断を指示・例・evalへ変換できる人は以前よりも価値が高い。

• 採用も変わる

  • 役割を開く基準は高くなる。以前は採用が必要だった一部は今ではスキルになったため、本当に人間が必要な仕事にだけ新しい役割を割り当てる。
  • 採用時には雑学ではなく、与えられた時間内に手作業では終えられない大きなプロジェクトを与え、エージェントをどう指揮するかを観察する。判断・センス・エージェントが外したときの復旧力を見る。
  • 実例 - アナリストは3時間以内にソース収集・証拠抽出・磨き上げたブリーフまで含む実レポート、エンジニアは1日以内に実製品の表面複製または仕様ベースの内部ツール作成（テスト含む）、グロース採用候補は50〜100社対象の市場マップ・キャンペーン計画（スクレイピング・クラスタ化・作成・優先順位付け）。いずれも時間内に手作業では完了できないことが核心。

6段階 - スタートアップをフィードバックループとして運営する (Run As A Feedback Loop)

• AIネイティブなスタートアップは毎週、運営システムを改善し、最初に戻って再び始める
  • レビューで扱うもの - エージェントが行ったこと、人がオーバーライドした箇所、失敗したeval、欠落したコンテキスト、絞り込むべきスキル、廃止すべきワークフロー、自律性レベルを上げるワークフロー

• 同時に2つのループを回す

  • インナーループ - 既存作業を改善する（実行あたりのコスト↓、サイクルタイム↓、インシデント↓、アーティファクトあたりのレビュー時間↓）
  • アウターループ - 次を探索する（新規顧客セグメント、製品アイデア、価格変更、パートナーシップ、競合の動き、規制の変化、離脱リスク）。バックグラウンドエージェントが候補を24時間供給し、人が追う対象を選ぶ

• ソフトウェアファクトリー（インナーループの最大部分）

  • 人が仕様とテストを書き、エージェントがそれに合わせて実装する。決定論的なチェックは自動で回し、マージ前に人がレビューする
  • 受け入れ基準が明確で、影響範囲が小さいところから始める - テスト生成、依存関係アップグレード、マイグレーション、内部ツール、統合スキャフォールド、QAスクリプト、セキュリティ自動修正
  • 2つのハードルール - 何も自動マージしない、どのエージェントも本番環境へ書き込ませない
    • Cursorでさえ、大規模な自律クラウドエージェントを動かしながら、2026年初頭まではマージに人によるレビューゲートを維持する。このゲートが、他の部分を安全に拡張できるようにする

• 市場学習システム（アウターループ）

  • 通話記録、異議の抽出、機能要望のクラスタリング、競合追跡、利用変化の観察、サポートパターンの把握、失注案件の分析
  • 発見を仮説に変換し、最も有力なものをテストする - 顧客との対話、ランディングページテスト、製品実験、データに対する新しいクエリ
  • エージェントが提案し、人が選ぶ - 戦略の提案と意思決定の両方をエージェントに任せると、無難な合意に落ち着くか、最も引き上げやすい指標だけを坂登り的に最適化してしまう

• 会社全体の自己改善の核心 = evalを書く能力

  • 数百の例を良い/悪いで手作業ラベリングし、evalを作ってプロンプト進化ループにつなぐ - GEPA、DSPyのようなフレームワークが小さなリフレクションモデルでプロンプト変異を提案し、evalがラベルセット上で順位付けして勝者をデプロイし、これを反復する
  • 創業者はevalを書き、失敗クラスターを読むが、進化したプロンプトは使いも読んだりもしない
  • 足を引っ張るのはエージェントの能力ではなく、「良い」の基準をエンコードできるかどうかだ - コーディングは役立つがボトルネックではなく、出力を信頼性高く良い/悪いと判定できるドメイン専門家がループ全体を回せる
  • evalは荷重を支える中核アーティファクトであり、evalを書くのが止まった瞬間、会社の複利成長も止まる

結論

• 必要なのは天才や大きなチームではなく、業務をマッピングし、コンテキストを積み上げ、evalを書き、毎週ループを回す規律だ - 皆が同じモデルを使う今、運営システムこそが秘密兵器になる