YCパートナーが、AIを使ってゼロから会社を立ち上げる方法を共有。新興企業は、AIをツールではなくOS（オペレーティングシステム）として捉えるべきだ。

新創企業へのAIの影響は、エンジニアのプログラミングをより速くすること、カスタマーサポートの業務フローを自動化すること、あるいは既存プロダクトにCopilotを追加することだけではありません。YCパートナーのDianaは近日、真の変化は「企業がゼロからどのようにして作られるべきか」をAIが書き換えつつある点にあると指摘しました。初期の創業者にとって、AIは会社がたまに使うだけの効率化ツールであるべきではなく、最初の日から、会社全体のオペレーティングシステムとして設計されるべきです。

生産性の観点はもう時代遅れ、AIが企業の設計の出発点を変えている

Dianaは、現在市場でAIについて語る際には、まだ「生産性向上」の枠組みに留まりすぎていると考えています。たとえば、エンジニアはより速くコードを書ける、チームはより多くのプロセスを自動化できる、会社はより多くの機能をリリースできる、というような話です。しかし、この見方は実際には、AIがもたらす構造的な変化を過小評価しています。彼女は、正しい人材がAIツールと組み合わさることで、これまでチーム全体でやっと実現できた機能を作れるようになり、さらにはこれまでそもそも不可能だったプロダクトを開発できるようになっている、と述べています。

したがって、創業者が本当に問うべき問題は、「会社のどの業務フローにAIを追加できるか」ではなく、「今日ゼロから会社を立ち上げるなら、どの仕事は本来“人手で層をなして”処理されるべきではないのか？」です。

これこそが、いわゆるAI-native企業の核心です。Dianaは、AIを会社の業務プロセスの外に置き、外付けのように特定部門の効率を上げるべきではないと言います。逆に、会社のあらゆる業務フロー、あらゆる意思決定、あらゆる重要なアクションはすべて、学習し続けて改善する知的システムの層を通過すべきです。

言い換えれば、将来の新創企業は、まず組織図、部門、会議の運用、管理制度を作り、最後にAIを導入するのではなく、設立初日から、AIが理解し、検索し、分析し、自ら改善できるシステムとして会社を設計するのです。

第一歩：会社全体を、AIが検索できる知的なハブにする

この枠組みのもとで、会社設立の第一歩は、組織全体を「検索可能」にすることです。従来の会社では、情報は会議、DM、電子メール、ドキュメント、CRM、GitHub、カスタマーサポートシステム、そして上司の頭の中に散らばりがちです。

これにより会社は、オープンループのシステムになります。創業者が意思決定をし、チームがタスクを実行するものの、結果が有効だったか、問題がどこにあるのか、次にどう調整すべきかは、往々にして人の報告と上司の解釈に依存します。Dianaは、このようなモードは本質的に情報の流出を招き、会社のスピードも遅らせると考えています。

AI-native企業では、それをクローズドループのシステムに変えなければなりません。毎回の会議、毎件のチケット、顧客からのあらゆるフィードバック、あらゆるプロダクトの意思決定、毎回の営業通話、そしてエンジニアリングの各納品サイクルごとに、AIが読み取れる記録が生成され、それが会社の知的レイヤーにフィードバックされるべきです。

Dianaは、新創企業は重要な会議を録音し、AIのノート作成ツールを使い、DMやemailに隠れてしまう情報を減らし、さらにSlack、Linear、GitHub、Notion、Google Docs、カスタマーサポートツール、営業電話、運営データにAgentを組み込むべきだと提案しています。会社が本当に作るべきなのは、バラバラに散らばった多数のツールではなく、「いま会社で何が起きているのか」を即座に答えられる、知的なハブです。

エンジニアリングマネジメントの実例：Sprint時間を半分に、アウトプットはほぼ10倍

彼女はエンジニアリングマネジメントの例を挙げて説明します。もしAgentがLinearのチケット、Slackのエンジニアリングチャンネル、GitHub、顧客のメール、Pylonのようなカスタマーサポートツール、NotionやGoogle Doc内の上位の計画、営業通話、日々のスタンドアップ記録を読み取れるなら、それは会議の要約を手伝うだけではなく、前のSprintで何を実際に納品したのか、納品結果は本当に顧客のニーズを満たしているのか、そして完了したはずの機能が期待した効果を生んでいないのはどれなのかを分析できるはずです。

これらの情報がすべてAIでつながると、Agentは次のSprint計画をさらに提案でき、エンジニアリングの計画はより正確で、より予測可能で、そして市場ニーズにより密接になります。これは、新創企業がゼロから立ち上げる際に、最初に大企業のエンジニアリングマネジメント制度をそのまま複製すべきではないことを意味します。これまでエンジニアリングマネージャーは、社内の情報が不透明なため、人間が情報を運んで解釈し続ける必要があり、その結果、状態を集め、進捗を整理し、上層に報告するのに多くの時間を費やさねばなりませんでした。

しかし、会社が最初からすべての重要な業務フローを検索可能になるよう設計しているなら、多くの従来型のミドルマネジメント業務は不要になります。Dianaは、彼女はすでに複数のYC企業で同様のやり方を見ており、その結果として一部のチームはエンジニアリングのSprint時間を半分にし、同じ時間の中でほぼ10倍のアウトプットに到達していると述べています。

第二歩：AIソフトウェアファクトリーで「誰がコードを書くか」を再定義する

第二歩は、AIソフトウェアファクトリーによってプロダクト開発のプロセスを作り直すことです。Dianaは、AI-native企業はAIをエンジニアの隣に置くただのコードアシスタントとして扱うべきではなく、「誰がコードを書く責任を負うのか」を再定義すべきだと考えています。

新しいプロダクト開発のやり方では、人間は主に仕様を書き、テストを書き、成功基準を定義します。AI Agentは実装を生成し、コードを書き、何度もテストして修正し、結果が仕様を満たすまで繰り返します。人間の役割は、問題を定義し、結果を判断し、方向性を校正することであって、1行1行のコードを自ら完遂することではありません。

このモデルは、テスト駆動開発の次の段階として理解できます。これまでのTDDは、人間が先にテストを書き、そのテストに人間がコードを書いて合格させるものでした。AIソフトウェアファクトリーでは、人間が仕様とテストのフレームワークを書き、Agentが自らコードを生成してイテレーションするのです。

Dianaは、この手法を極限まで進めている会社があると述べています。コードベースにはほとんど手書きのコードが存在せず、仕様、テスト、シナリオ検証によって駆動されるAIが実装を完了するのです。これはいわゆる「1000倍エンジニア」の本当の意味でもあります。誰かのエンジニアが突然、他者より努力が1000倍になったのではなく、エンジニアの背後に一連のAgentシステムがあり、これまでチーム全体でしかできなかった仕事を彼（彼女）が成し遂げられるからです。

第三歩：最初の採用を再設計し、3種類の人だけ残す

したがって、AIでゼロから会社を作るなら、創業者は最初の採用の定義を再考する必要があります。DianaはBlockの創業者Jack Dorseyの見方を引用し、もし会社が単にAIツールを既存の組織図に追加するだけで、古い管理階層や情報の流路パスを維持してしまうなら、真の変化を逃すことになると述べています。

将来の会社は、大量の「人間の仲介者」を作って、情報が上司、調整役、プロジェクトマネージャーの間を何層にも伝わるようにすべきではありません。逆に、会社は知的なレイヤーとして設計され、情報の統合と流動をAIが担い、人間は端に立って判断し、創造し、意思決定し、結果に責任を負います。このような会社では、従業員の役割はより少なく、より明確になります。

第一のタイプは個人貢献者、つまりbuilder-operatorです。エンジニアだけでなく、オペレーション、カスタマーサポート、セールスもAIを使ってプロトタイプ、業務フロー、または自動化システムを作れるべきです。

第二のタイプはDRI、つまりDirectly Responsible Individual（直接の責任者）です。これは従来のマネージャーではなく、特定の明確な成果に対して責任を負う人であり、1人につき1つの成果が対応し、プロセスや部門の背後に隠れることはできません。

第三のタイプはAI founder type、つまり創業者本人です。創業者は自ら最前線に立ってAIを使い、能力がどのように増幅されるのかを示す必要があり、「AI担当者」にAI戦略を丸投げして処理させるべきではありません。

創業者が最大化すべきは従業員数ではなく、トークン使用量

これはまた、AI-native企業で最も直感に反する点を浮き彫りにします。今後、創業者が最大化すべき可能性があるのは従業員数ではなく、トークン使用量だということです。Dianaは、新創企業は不快になるほど高いAPIの請求に対しても覚悟を持つべきだと考えています。なぜなら、これらの支出は、従来はより高価で、よりかさばる人材コストを置き換えるからです。AIツールを熟練して使える人なら、前のAI時代におけるエンジニアリング、設計、あるいはオペレーションのチーム全体の仕事を1人で成し遂げるかもしれません。

そのため、ゼロから会社を立ち上げる創業者は、「迅速な増員」を成長の象徴として見なすべきではなく、問い直すべきです。どの仕事はAgent、クローズドループなプロセス、そしてソフトウェアファクトリーによって処理できるのか？そして、それができないからこそ新たに1人を雇う必要があるのはどれなのか？

これは、特に初期の新創企業にとって重要です。小さな会社には歴史的な負債がありません。大企業がAI-nativeへ転換するには、一方で既存のプロダクトを維持しながら、長年積み上げたSOP、管理制度、社内政治、古い技術スタックを取り壊さなければなりません。プロセスを調整するたびに、本来まだ動いていたはずのシステムを壊してしまう可能性があります。

一方、初期の新創企業にはこれらの制約がありません。初日から、会議、エンジニアリング、カスタマーサポート、セールス、採用、オペレーション、そしてプロダクト開発をすべて、AIが読み取り、検索し、フィードバックできる構造として設計できます。Dianaは、これこそが新創企業が大企業に対して持つ重大な優位性だと考えています。

将来の起業の参入障壁は、AIで会社を再発明できること

したがって、「AIでゼロからどうやって会社を作り始めるか」の答えは、ChatGPT、Claude、Cursor、Devin、あるいは各種Agentツールを既存のプロセスに詰め込むことではなく、逆に会社そのものを再設計することです。

創業者はまず、検索可能な組織を作り、すべての重要な情報をAIが読み取れる文脈に変えるべきです。その次に、意思決定、実行、そして結果が継続的にフィードバックされる閉ループプロセスを作ります。さらに、仕様とテストに駆動されるプロダクト開発で、Agentが大量の実装を担当できるようにし、最後に、より少数だがより強力なbuilder-operator、DRI、そしてAI founder typeでチームを組成します。

Dianaの見解は、より過激な結論へと向かっています。AI時代の新創企業は、「同じ会社だが効率が高い」というだけでは済まないということです。本当にAI-nativeな会社は、組織、プロセス、プロダクト開発、役割分担、そしてコスト構造までもが異なります。

それはAIで会社を少し速く動かすのではなく、最初から、学習し、フィードバックし、自ら改善する知的システムとして会社を設計することです。創業者にとって、それは今後数年で最も重要な起業の参入障壁になる可能性があります。AIを使えるかどうかではなく、AIを使って会社そのものを再発明できるかどうかです。

この記事は、YCパートナーがAIでゼロから会社を立ち上げる方法を共有しており、新創企業はAIをツールとしてではなくオペレーティングシステムとして扱うべきだ。最初に現れた場所：鏈新聞 ABMedia。