YCombinator（YC）が社内で実践している最先端のAI活用戦略と、組織全体を「AIネイティブ」へと変革するためのインフラ構築について、当事者たちが深く語り合う。単なるコパイロット（副操縦士）としてのAI利用を超え、すべての業務の基盤レイヤーとしてAIを組み込み、データやツールのレジストリを一元化することの圧倒的な優位性を解説。さらに、議事録などの組織内の活動ログをAIに学習させ、自律的に改善ループを回すことで、組織全体の知能を爆発的に高める「人工超知能（ASI）」化への具体的なアプローチを提示している。
AIをコパイロットから組織の基盤レイヤーへ
企業の中に人工超知能を構築するにはどうすればいいのでしょうか。重要な鍵の一つは、AIを単なるコパイロットとして使わないことです。すべてを構築するための基盤レイヤーとしてAIを活用するのです。そして、あらゆる成果物や記録を蓄積し始める必要があります。それは組織の共有脳のようなもので、私たちの脳同士を接続することに最も近い状態を作り出せます。組織内の全員が、一緒に働く人々の集合的なスキルや直感を利用して、自分の業務をより洗練させていく手法として捉えるなら、これは信じられないほど強力なものになります。
本日は素晴らしいゲストをお迎えしています。YCのジェネラル・パートナーであるピート・クーマンです。彼はアプリやウェブサイトのABテストを行う最初期かつ最高の方法の一つであるOptimizelyを創業しました。それ以来、彼はYC内のすべてのエージェント・インフラストラクチャを構築してきました。文字通り、すべてのハーネスやYC内部でのAIの活用方法の基礎を作った人物です。ピート、ライトコードへようこそ。
ありがとうございます、ゲイリー。
ChatGPTが登場してからのここ数年、YCは主にAI企業への投資を行ってきました。そして、主にAI製品を開発するAIネイティブな企業をどう育てるかについて、様々なアドバイスの変遷を経て、彼らと共に多くのことを学び、狂気的な旅を続けてきました。多くの人は気づいていないと思いますが、YCの内部では、スタートアップの支援で使っているものと全く同じ仕組みを自分たちで構築し、活用しています。このツールを採用し、AI以前の時代に設立された組織をスーパーAIネイティブな組織へと変革していくプロセスは、非常に強力な共生関係を生み出してきました。そしてピートはその先頭に立って指揮を執ってきたのです。社内で構築してきたすべての取り組みについて、このように公の場で話せる機会をずっと望んでいたので、今回のエピソードは本当にエキサイティングです。ピート、まずは始まりの時期に遡って、社内で本格的にAIツールの導入を始めた特定の瞬間について話してもらえますか。その道を開いたのは、まさにあなたでした。
喜んでそのストーリーをお話しします。そのように位置づけてもらえるのは嬉しいですね。というのも、私と数人のエンジニアで1年ほど前、あるいはもう少し前に始めたプロジェクトが、今では雪だるま式に膨れ上がり、YC内部で多種多様な方法でAIを活用することを可能にするインフラストラクチャ・レイヤー全体へと発展したからです。そして、最も素晴らしいことの一つは、エンジニアリングチーム全体や多くのパートナーたちも次々と飛び込んできて、このインフラレイヤーの構築に貢献してくれたことです。
私たちは約1年前にYC内部の独自のハーネス、つまりYC特化型のエージェントを作り始めました。プロジェクトの最初のきっかけは、私と数人のソフトウェアエンジニアが財務チームと一緒に進めていた業務でした。少し背景を説明すると、YCはその設立当初から、知る限りほとんど独自のソフトウェアで運営されてきました。この時代において、それは私たちに巨大なアドバンテージをもたらしています。その文脈を踏まえて1年ほど前のあの瞬間に戻ると、私たちは財務チームと席を並べ、彼らの財務ワークフロー、つまり仕訳の入力や価格設定された資金調達ラウンドの記録など、YCを運営する上で不可欠なあらゆる業務を支援するためのツール群について話し合っていました。
その時、私は二つのことを同時に目撃していました。一方では、社内で従来の開発ループが回っていました。財務チームがソフトウェアエンジニアに複雑な財務ワークフローの仕組みを説明し、エンジニアがその内容を完全にカプセル化した決定論的なソフトウェアを専用に構築して財務チームに引き渡す、というプロセスです。これは非常に非効率に感じられました。
しかし同時に、まさにその頃、エージェント的なコーディングツールが本格的に普及し始めていました。当時すでにWindsurfやCursorといった第一世代のツールが定着しており、Claude Codeが導入されたのもこの頃だったと思います。これらのツールは私にスーパーパワーを与えてくれていると感じていました。YCでの古典的なソフトウェア開発の手法を見つめつつ、自分のマシンで自分がどのように作業しているかを比較したとき、その二つの間の乖離がどんどん広がっていくように感じたのです。
そこで最初の衝動が生まれました。財務チームが自分たちのソフトウェアを自分でコントロールできるように、エージェントを実行できるツールをYCで構築してみてはどうか、と考えたのです。ソフトウェアエンジニアが複雑なワークフローを理解しなければならないという狂ったループからエンジニアを解放し、財務チームが自分たちでワークフローをコード化できるツールを提供するのです。それはRubyのコードとしてではなく、プロンプトを使った英語によって行うのです。
SQLクエリの解放とデータの一元化という魔法の瞬間
興味深いのは、私たちは2〜3年前、LLMが登場したもののエージェントによるコーディングがまだ実用化されていなかった頃にも多くの企業に投資していたということです。当時、最初に取り組んだのはコーディングではなく、SQLクエリを記述するためのLLMでした。
まさにその通りです。
あなたが最初に構築したバージョンのシステムでよく覚えているのは、それがどれほど優れていたか、そして過去に私たちが投資して失敗に終わったいくつかのスタートアップのアイデアと、基本的には同じプロトタイプを持っていたかということです。私たちはそれぞれ、どこかの時点でそのような企業に投資した経験があるはずです。しかし、ここではそれが実際に機能していました。エンジニアリングのバックグラウンドを持たない財務チームの、非常にスマートではあるものの非技術的な人々が、これらのツールを使って本質的な質問をデータに投げかけることができるほど、見事に機能していたのです。
正直なところ、私自身も本当に驚きました。最初は財務向けの専用ツールとして始めましたが、その後、さらに一般的なエージェントループへとシステムを書き換えました。今ではこうした仕組みは至る所で目にするようになりましたが、私が最初に魔法のような瞬間を経験したのは、エージェントループと、YC特化型のツールを集めた共有ツールレジストリを作った時でした。そして、最初の大きな突破口となったツールは、振り返ってみるとジャレッド、あなたが構築したものだったと思います。それは、エージェントが私たちのデータベースに対して読み取り専用のSQLクエリを実行できる機能でした。
そうです、実際には二つのツールでした。一つはデータベースに対してクエリを実行するツールで、もう一つはモデルファイルを読み込む機能でした。これらのツールを構築したときのことを覚えていますが、少しルールを破っているような感覚がありました。当初はドメインが非常に狭く限定されたツールから始めたのですが、自分がやりたいことを実行するにはパワーが足りず、いつも不満を感じていたのです。そこで、「いっそのこと、本番環境のデータベースへの完全なアクセス権を与えて、何でも自由に探索できるようにしたらどうだろう」と考えました。そして、夜遅くにこっそりとそれをデプロイしたのです。
そしてそれは機能しました。驚くほど上手くいきましたね。
ええ、これはその後のOpenClawのような展開を予兆していたのかもしれません。世界を阻んでいたのは、セキュリティやプライバシー、そして起こり得るすべてのトラブルに対する過度な懸念だったということが分かります。そうした心配を少し手放してみると、「なんてことだ、このツールは信じられないほど強力だ」と気づくのです。仕事中は非常に狭いボックスの中でオペレーションしているのに、家に帰ればClaude CodeやOpenClawなどを使って何でもできる、という奇妙なギャップを縮めようとする試みの、非常に良い例です。
データベースに対してSQLクエリを実行できる機能が、なぜこれほどまでに有用だったのでしょうか。響きとしては非常にシンプルに聞こえますが。
この実験に取り組むにあたって、YCが持っていた大きなアドバンテージについて話すことが重要だと思います。それは、私たちが独自のソフトウェアで運営されており、そのすべてのソフトウェアが、YCの世界におけるあらゆる重要な情報を内包した一つのPostgreSQLデータベース上に存在しているという点です。私たちが投資したすべての企業が「companies」テーブルにあり、「founders」テーブルがあり、財務取引のテーブルがあり、私が社内のCRMに残したメモのテーブルがあります。他の多くの企業がサードパーティのSaaSツールに外注しているような機能を、私たちはすべて自社で構築してきました。
その結果、あらゆる重要なコンテキストが一つのデータベースに集約されているため、「過去4つのバッチで宇宙関連の企業に投資したすべての投資家を表示して」といった質問を投げかけることができます。スキーマの配置に関する最低限の追加情報を提供するだけで、エージェントはビジネスに関する任意の質問に自律的に答えることができるのです。
初めてそれを見たときは、確かに魔法のような瞬間でした。
私にとってクールだったのは、単に質問に答えるのが簡単になったということだけではありません。私たちが問いかける質問の数が劇的に増え、投げかける質問の規模や複雑さが劇的に向上したことです。昔、BIツールを使ってそのような質問をしようとしたら、SQLを書くのに数時間を要していました。そのため、本当に重要な要件でない限り、わざわざ調べようとはしなかったのです。
これは、あるタスクを完了させるために必要なチーム間の往復のコストを削減したときに発生する、ジェボンズのパラドックスの典型例です。YCに関する複雑な質問をするために、データサイエンスチームのドアを叩き、彼らのバックログが消化されるのを待たなければならないとしたら、質問をする回数自体がどうしても少なくなってしまいます。
これを読んでいる人の中には、今でもそうした古い体制の職場で働いている人もいるでしょう。実際のところ、大多数の人がまだその世界で生きています。2026年にもなってそのような状態であることは、少し信じがたいことですが。
まだまだ先は長いと思いますが、だからこそ非常にエキサイティングです。
大規模テーブル化とエージェント最適化への進化
一つの疑問は、そうした古い世界にいる企業が、どうすればこれほど迅速に動くための翼を得られるのかということです。私たちの魔法は、あなたが言ったように、すべてのコンテキストが一つの場所にあって容易にアクセスできたことでした。歴史的にデータサイエンスを振り返ると、初期のグーグラーたちが解決しなければならなかった最初の課題の一つがBigtableでした。Bigtableは、スキーマや結合（Join）を使う代わりに、マップリデュースが可能な一つの巨大なテーブルを持つというアプローチでした。
その現象が再び起きているのだと思います。現在は、アンドレイ・カルパシーのスタイルである知識LLMウィキや、Gbrainによってそれが起きていると主張したいです。少なくとも私はそれを目の当たりにしています。私のOpenClawは多くのシステムへのアクセス権を持っており、それを私自身や私が関心のある事柄に関連する独自のスキーマへと正規化しています。これは非正規化（Denormalization）のようなものです。データを取得し、OpenClawやHermesエージェントのような特定のハーネスが質問を投げかけるのに最適化されたフォーマットに変換するのです。
それには検索が必要であり、RAG（検索拡張生成）やGraphRAG、ハイブリッドRRF（相互階層融合）、リランキングなど、誰もが検索について学んできたあらゆる技術が、現在のGbrainの内部に組み込まれています。そして、エージェントに魂を与え、データを与え、エージェントがあなたとあなたの関心事を理解したとき、これらのツールは突然、狂気的なほどの翼を持ちます。
ツールが先回りして物事を見通す様子は信じられないほどです。質問を投げかけると、その意図を解釈し、あなたを本当によく知っている人間でなければ答えられないようなアウトプットを返してくれます。それが今や可能なのです。データが至る所に散らばっているという問題に対する、GbrainのOpenClaw・Hermesでの経験から得た私の答えは、データを非正規化し、エージェントの検索と理解に最適化されたフォーマットに投入する必要がある、ということです。MCP（Model Context Protocol）でラップすることもできますが、直感的には、これらのツールはMCPやC言語での動作も得意ですが、CLI（コマンドラインインターフェース）のほうがさらに得意です。エージェント専用に非正規化を行い、Bigtableのようなアプローチをとる必要があるように思えます。
過去1年半を振り返ると、私たちはまだエージェントのシングルプレイヤー時代にいるように感じられます。現在非常に普及しているハーネス、つまりClaude Code、Codex、Pi、OpenClaw、Hermesなどは、すべて単一の人間が単一のマシン上で実行するように設計されています。その環境では、エージェントはほぼ何でもこなすことができ、ユーザーに途方もないパワーを与えてくれるため、これは非常に理にかなっています。使っていて本当に楽しいものです。
しかし、まだ誰も上手く解決できていない大きな課題の一つが、マルチプレイヤー向けのハーネスです。つまり、そのスーパーパワーをチームや組織のレベルで有効化することです。YCで構築したインフラを探索する中で興味深かったのは、私たちが作成したどのプリミティブ（基本要素）が、個人やチームによるエージェントの活用を可能にしたのかを観察することでした。
設立から2年以上経っているようなレガシーな組織の中で働いている場合、組織の全員がAIを使ってより多くのことを達成できるようにするために、一体何に集中すべきかという質問がありました。私たちは共通のコンテキストレイヤーについて話しました。社内の重要なコンテキストが可能な限り蓄積されているデータウェアハウスは、極めて有用です。個々のエージェントハーネスを他のMCPツールや他の信頼できる情報源に接続するためのツールは数多く存在します。しかし、モノレポ（単一リポジトリ）内のコーディングエージェントがはるかに効率的であるのと同様に、私たちのエージェントがすべてを一つのスキーマに収めた単一のデータベース上で動作している様子を見ると、すべてのコンテキストを一箇所に集めること自体に大きな価値があることが分かります。
社内のツールレジストリを持つこと。これが、私たちが構築したもう一つの極めて重要な要素です。初期の頃は、システム全体が本当にシンプルでした。エージェントループ、シンプルなツールレジストリ、そしてその下にあるモデルルーターなど、いくつかのパーツだけで構成されていました。ツールレジストリこそが、YC特化型の機能の大部分が格納されている場所です。ツールレジストリが、これらのエージェントを職場での実用的なツールへと変えるのです。
当初はSQLデータベースをクエリする魔法の機能を含めて20個ほどのツールしかありませんでしたが、時間が経つにつれて、各チームがどんどんツールを追加していきました。YCの業務の中で、エージェントによって改善できると思われるタスクに直面するたびに、ツールを追加していったのです。現在では350以上のツールが存在しています。各チームが独自のツールを追加しています。オフィスアワー（面談）の管理、財務チームによる仕訳の入力、運営するイベントの管理など、YCが行うすべての重要な業務のためのツールがあります。これらが一箇所に揃っていれば、社内で構築したエージェントから利用できるようにするだけでなく、個々のマシンで実行されているClaude Codeなどからも利用可能にすることができます。
もし私が他の組織で働いているとしたら、何よりもまずこれらの要素の構築に集中すると思います。
メタスキルとセルフインプルーブメントの循環
正直なところ、あなた方がツールを使って行った取り組みに触発されて、OpenClawに「skillify（スキル化）」という機能を実装しました。そして実際、skillifyの最後の部分が最も重要です。skillifyは私がOpenClawで作ったメタスキルで、OpenClawやHermes上で何でも実行できるようにするものです。Hermesにはすでに同様の機能があり、自動的にスキルを作成します。
しかし、最も重要なのは、それをリゾルバー（解決器）にプラグインすることだと思います。これは、エージェントが実行できることのリストを含む「agents.mmd」のようなもので、基本的にはツールを使用可能にするMarkdownのエントリーポイントにリンクしています。この仕組みは様々な文脈で繰り返し登場します。Claude Codeのスキルレジストリも実質的にはリゾルバーですし、私たちのツールレジストリもリゾルバーです。
そして、その上に構築すべき興味深い要素として、私が頻繁に呼び出す「check_resolvable」というメタスキルがあります。エージェントで新しく異なる処理を行い、その結果が気に入った場合、それを「skillify（スキル化）」してツール呼び出しやメソッド呼び出しに変換します。その後、「check_resolvable」を実行して、既存の他のすべてのスキルやツールを確認し、DRY（Don't Repeat Yourself：同じことを繰り返さない）を満たしているか、そしてMECE（Mutually Exclusive, Collectively Exhaustive：相互に排他的で、集合的に網羅的）であるかを確認します。MECEはマッキンゼーのコンサルタントが優れたスライドを作るために使う言葉で、少し恐縮ですが、DRYの上に重ねる追加のレイヤーとして非常に有用です。
モデルはこれらの概念が何であるかを理解しているようです。そのため、DRYでMECEなリゾルバーテーブルがどこかに存在していれば、それは事実上最適なリゾルバーになります。同じことを行う10個のスキルを持つのは不適切であり、パラメータによって呼び出しを制御できる1つのスキルや1つのツールを持つことが望ましいのです。
応用コンピューター科学者として生きる上で、今は最もエキサイティングな時代だと思います。同じ有用な応用概念が、同時多発的に何度も再発見されているからです。かつて人々がUnixの初期バージョンを開発していた頃、スタックやヒープを発見した時も同じような感覚だったのではないでしょうか。私たちは今、まさにその瞬間に立ち会っています。エージェントシステムの本質的な新しいプリミティブを構築しているのです。Claude Code、独自の社内ハーネス、OpenClaw、あるいはHermesなど、異なる開発ラインの中で、これらの概念が何度も繰り返し現れるのを目にすることができます。
（ここで、YCスタートアップスクールの再開に関する案内。7月25日・26日にサンフランシスコで最先端のテクノロジーとスタートアップについて議論するため、世界中から有望なビルダーを招待する選考プロセスの告知）
他の企業がこれらのシステムをどのように構築しているかを見るのは非常に興味深いです。それぞれのインフラの中に、これらと同じプリミティブが多く見られるからです。エージェントループがあり、ツールレジストリがあり、スキルレジストリがあります。
現在YCでスキルがどのように使われているかを見ると、スキルをツールの上位にあるシンプルな抽象化レイヤーとして捉えた場合、このエージェントシステムを通じて全員がアクセスできるいくつかの共有スキルが存在します。そして、興味深い進歩が見られます。初期の頃は自分でシステムプロンプトを書いていたのが、やがてスキルが登場して独自のスキルを書くようになり、さらにメタプロンプトを活用してエージェントにスキルを書かせる、プロンプトを自動的に改善させる、という段階に移行していきました。
まさにその通りです。
社内でも同じ進化を遂げており、いくつかのスキルを経た今、自律的で自己改善的なループ（自律改善ループ）を持つ段階に達しています。アンドレイ・カルパシーの「auto-research」や、現在のCodexの「SLG goal」も同様の機能を組み込んでいます。私たちは、毎晩社員が行ったすべてのエージェントの会話を読み込み、もっと上手くできたはずの点や、あらかじめ知っていればより効率的に処理できたはずのコンテキストを探し出す総合エージェントを運用しています。
これはOpenClawの「ドリームサイクル（夢共有サイクル）」と同じ思想であり、Gbrainもドリームサイクルを持っています。これはスキルの改善を行うドリームサイクルですが、将来的にはすべての文字起こしデータを読み込み、社内のデータベースやCRMに、人々や企業について把握した内容を書き戻すことも可能になります。
文字起こしデータを活用して、これらのスキルをさらに効果的にしている素晴らしい例があります。私たちが共有しているスキルの一つに、YCのパートナーが投資先企業に対して「2文での説明（2-sentence description）」を作成するのを支援するスキルがあります。ここにいる全員がこれを何百回も書いてきました。
2文での説明とは何なのか、少し説明しておいたほうがいいですね。
2文での説明とは、自分の会社が何をしているのか、そしてなぜそれが面白いのかを、誰もが理解できる自然言語で簡潔に説明する手法です。簡単そうに聞こえますが、起業家が実際に書くのは驚くほど難しいのです。
そして不思議なことに、誰もそれをやろうとしません。どれほど経験豊富な起業家であっても、自分自身の頭の中には完璧なコンテキストがあるため、それを忘れてしまうのです。興味深いことに、YC自体が一種の「コンテキスト・エンジニアリング」のプロセスであると気づきました。自分の頭の中にある完璧なコンテキストを、他人の頭の中に再現することこそが優れたコミュニケーションであり、2文のピッチの本質です。最初の1文で「一体それは何なのか」を伝え、2文目で「なぜそれが面白く、価値があるのか、時間を割く価値があるのか」を伝えます。
私が2文のピッチを教える際、このアプローチが最も気に入っています。「一体それが何なのか」が分からなければ、質問すらできません。それが分からないと、聞き手は「コンピューターに関する何かだろう、お昼ご飯は何にしようか」と考えてしまいます。
そして2文目も同様に重要です。「この部屋には同じようなことをしている企業が他に5社ある」と言われたときに、なぜこの会社が注目に値するのかが理解できなければ、聞き手はまたパストラミサンドイッチのことを考え始めてしまいます。ですから、2文のピッチは起業家にとって極めて重要であり、すべてのYCパートナーが何度も何度も練習してきたシンプルな原子要素なのです。
パートナーの一人であるトムが、企業に関するコンテキストを受け取り、それを2文の説明に凝縮する方法をエージェントに教えるスキルを書きました。それが彼の手書きのプロンプト、あるいはスキルでした。そして過去1、2ヶ月の間に起きた素晴らしい展開として、他の数人のパートナーが春のバッチの企業たちと行ったグループオフィスアワーのミーティングを取り上げ、すべての起業家に2文の説明に挑戦してもらい、フィードバックを与えました。
効果的な説明方法に関するパートナーの頭の中の知識が、そのミーティングの文字起こしデータというコンテキストの形で可視化されたのです。それをエージェントに引き渡し、「このコンテキストを読み込んで学んだ内容を基に、2文の説明スキルを改善して」と指示しました。その結果、スキルは見違えるほど向上しました。今やそのスキルは、私個人が書くよりも優れたものを出力すると断言できます。
組織的知能の爆発とインターフェースの未来
これこそが、組織の内部で人工超知能（スーパーインテリジェンス）が発生するメカニズムです。この2文のピッチの話は小さなことのように聞こえるかもしれませんが、その内部には非常に強力な仕組みが埋め込まれています。ジャック・ドーシーがBlockで取り組んでいることについての話を聞いたことがあるかと思います。彼は基本的に、世界中の人々が相互に決済を行うのを支援する領域において、BlockをミニAGI（汎用人工知能）に変えようとしています。
そして、これこそがそれを実現するためのミクロなメカニズムです。あらゆる組織の運営は、無数のタスクの集合体として捉えることができます。YCにおける2文のピッチは、私たちが起業家のために行う何千ものタスクの一つに過ぎません。しかし、誰かがプロンプトを書き、それを他の多くの人々が使い、そこから文字起こしデータなどの成果物が生まれ、それがメタプロンプトの材料として使われ、自律的に日々改善されていくという、非常に具体的なプロセスを確認しました。そして突然、その1つのスキルが、私たち個人の能力を超える存在になったのです。
これは、あらゆる組織の業務プロセスにおける決定的な転換点です。企業の中にどのように人工超知能を構築するか。それは、あなたが行うすべての業務において、これと同じことを実践するのです。それ以上複雑なことではありません。行うすべての業務、あらゆる個人ができることを集約し、この特定のプロセスで結合すれば、スーパー組織が誕生します。これは今や可能です。これを見ているすべての人が、自分の会社や自分の仕事で実践できます。
だからこそ、新しくスタートアップを始めるべきなのです。既存の組織にいる人々は、強力な権限やリソース、資本を持ちながらも、私たちが今話したことを信じないリーダーたちの下に閉じ込められることになるからです。なぜなら、彼らは「安全ではないから」という理由で、すべてのコンテキストをロックダウンしてしまうからです。
安全第一主義ですね。私はそれが嫌いです。
AIネイティブな組織をどのように構築するかという話に戻ると、重要なポイントはAIを単なるコパイロットとして使わないことです。それは非常に2023年や2024年的なアプローチです。AIをすべての構築レイヤーとして使用し、すべての成果物を記録し始める必要があります。これまではミーティングの録音などは考えもしなかったかもしれませんが、ミーティングレコーダーがこれほど普及しているのには理由があります。ミーティングのコーチングだけでなく、メールの作成、コミュニケーション、プランニングなど、あらゆるアウトプットを改善するためにその全コンテキストを活用できるのです。
ダリオ・アモデイのエッセイを思い出します。AIの進歩を阻む要因のいくつかは技術的なものではなく、社会文化的なものであると述べられていました。非常に興味深い例です。2年前であれば、ミーティングを録音することに対して社会的なエチケットや抵抗感があり、どれほど侵入的であるかを気に揉んでいましたが、今日では、特にZoomなどにおいては録音されていることがほぼデフォルトの前提となっています。誰もが録音を始めています。
少し恐ろしい面もありますが、これを「組織の全員が、共に働く人々の集合的なスキルや直感を利用して、自分の業務をより洗練させていくための方法」として位置づけるなら、信じられないほど強力です。標準的な2文の説明スキルを持つことは、起業家のためにテキストを生成するだけの手段ではありません。何が効果的な起業家コミュニケーションを生み出すのかを、私自身がより深く理解するための手段でもあるのです。なぜなら、ダイアナやハージ、そしてあなた方が長年の経験から学んできたすべての知見が、会話を通じてこのスキルに焼き付けられているからです。
組織の共有脳ですね。
私たちの脳を接続することに最も近い状態です。
まさにその通りです。今ではエージェントを呼び出して練習セッションを行い、自分のアプローチを批評してもらうことができます。すべての知識をエージェントが扱える場所に集約できれば、非常に多くの可能性が開かれます。それは組織内のあらゆる人間を強力にエンパワーするものです。
私たちが正しく実践できていると感じる、いくつかの洗練された興味深いポイントがあります。その一つは、デフォルトでエージェントの会話が、YCのすべての正社員に対してグローバルに閲覧可能になっている点です。最初はその決定に確信が持てませんでした。それが正しいと感じられ、未来を生きている感覚はありましたが、容易な決断ではありませんでした。「全員がすべてを見られる状態にして本当に大丈夫なのか」「何が許されないのか」について多くの議論を重ねました。結果として、オープンにする選択をして本当に良かったと思っています。
同感です。他の人がどのように使っているかを見ることで、人々は使いこなす方法を学んでいきました。
私たちはその透明性を利用して、いくつかの課題を同時に解決しました。すべてのエージェントの会話が社内のSlackチャンネルにブロードキャストされ、誰でもそのチャンネルに参加して観察し、学ぶことができました。あなたが非常にヘビーに使い始めたとき、その独創的な活用方法を見て、多くのメンバーが「そんな使い方ができるのか」と目から鱗が落ちる思いをしました。
これにより、社内のセキュリティを少し寛容にすることが可能になります。先ほど話したように、エージェントは無制限のコンテキストへのアクセスを与えられたときに最も強力になりますが、それは多くの組織の運営方法とは相反します。会話をパブリックにブロードキャストすることをデフォルトにすることで、一種の緩やかな社会的コントロールが働き、高い信頼関係が担保された環境下において、プライベートな情報を適切に保護しつつ、ツールを最大限に活用することに成功したのです。
興味深いのは、1000倍の超知能を持つ真のエージェント的組織が備えるべき、事前の予想を超えた二つの特質が示されている点です。それは、組織が比較的平等主義的（エガリタリアン）でなければならないということ、そしてデフォルトで信頼（トラスト・バイ・デフォルト）を前提としていなければならないということです。世界のほとんどの組織はそのどちらでもありません。組織の創業者であるならば、それらをコアに据えなければなりません。そして、そのような環境は、全員の方向性が一致し、高い信頼関係で運営されているスタートアップにおいて最も機能します。
もう一つ必要なのは、年間1万ドルから10万ドル規模のトークン費用を惜しまずに支払う覚悟です。それを許容し、スキルに投資し、チームと共にオープンな方法ですべてを実行するならば、基本的には2028年の世界を先取りして生きることができます。今年間10万ドルや100万ドルかかっているものは、2年後には当たり前のものになり、コストは1万ドルになり、その翌年には数百ドルになります。誰もがそれを行うようになり、それが企業の当たり前の姿になります。
つまり、すべての既存企業やフォーチュン500、あらゆるスタートアップをごぼう抜きにできる、一回限りのタイムワープが存在しているのです。1990年代に企業が従業員のためにコンピューターを買い始めた時期も、同じような感覚だったのではないでしょうか。当時は非常に高価で、一部の企業だけがその不安定で高価なシステムに投資していたはずですが、競合が持っていない時にコンピューターを持っているというのは、どれほどのスーパーパワーだったことでしょう。
戦術的な観点から、これがYCに与えた影響として、組織の「底上げ」が挙げられます。新入社員が業務に慣れるまでに以前は6ヶ月かかっていたところが、このシステムによって、組織のベストプレイヤーやスタープレイヤーがどのように業務を遂行しているかを、AIを通じた丁稚奉公（アプレンティスシップ）のような形で自動的に吸収できるようになりました。パートナーの時間は貴重であり、優秀な人材は常に多忙です。ピートが起業家に対して素晴らしいセールスのコーチングを行う様子や、ゲイリーが非常に具体的なアドバイスを与えるシミュレーションをエージェントを通じて実行できるため、新しいメンバーがより迅速にミニチュア版のプロフェッショナルとして成長できるのです。
コーディングエージェントを使い始めて最初に恩恵を感じたのは、恥ずかしくて人には聞けないような間抜けな質問を、エージェントには何の抵抗もなく投げかけられる点でした。それと同じことが組織レベルで起きているのです。新入社員がハージに質問するのを遠慮してしまうような場面でも、もうその必要はありません。その結果、より多くの質問が投げかけられ、解決され、人々が圧倒的なスピードで立ち上がることができるのです。
ジャストインタイム・ソフトウェアの夜明け
あなたがYCでこのすべてのエージェント・インフラを構築した後、その経験にインスパイアされて執筆したエッセイ『 Horseless Carriages（馬なし馬車）』は、インターネット上で大きな反響を呼びました。その背景にあるアイデアについて説明してもらえますか。今でも非常に重要な示唆を含んでいると思います。
当時目にした多くのAIソフトウェアに対する批評でした。完全に率直に言うと、現在のソフトウェアの多くもまだその範疇に留まっていると思います。
いまだにそうですね。変わっていません。
多くの企業が、既存のソフトウェアの内部に少しだけAIの機能を組み込む形で製品を作っているのを目にしました。当時私が挙げた例は、Gmailチームが提供していたメールの自動執筆機能です。しかし、その根底にある本質的なアイデアは、AIの真のポテンシャルは「ソフトウェアのコントロール権を開発者からユーザーへと移行させること」にあるという点です。
従来の「機能としてのAI」は、AIがどのようにタスクを実行すべきかというプロンプトのコンテキストを、ユーザーから隠蔽し、ロックダウンしていました。「複雑な仕組みを設計するのは開発者の仕事であり、ユーザーをその複雑さから守るべきだ」という古典的なアプローチです。
安全第一主義ですね。私はそれが大嫌いです。
まさにその通りです。そうしたツールの動作方法と、自分のコンピューターで何でも実行できるコーディングエージェントを使ってスーパーパワーを感じていた経験とのコントラストに立ち返ることになります。このエッセイが指し示す結論は、私たちがAIネイティブなソフトウェアの構築に習熟していくにつれて、それは「決定論的なソフトウェアがAIをラッピングする」のではなく、「AIエージェントが決定論的なツールやソフトウェアをラッピングする」構造に変化していくということです。私たちは構築したプリミティブを通じて、社内の従業員にその本質を提示しようと試みてきましたが、まだ道半ばです。
インターフェースとしてのチャットについてですが、現在、AIのための新しいインターフェースを構築する必要性や、それがどのような姿になるべきかについての議論が盛んに行われています。しかし、それはまだツールの真価を肌で感じていない人々から出ている意見のように思えます。チャットは実際、非常に優れたインターフェースです。エージェントに対する信頼が高まるにつれて、より多くの仕事を委ねるようになり、その意思決定を信頼するようになるため、エージェントが何をしているかをレビューするための過剰なUIは必要なくなっていくからです。これこそが「ジャストインタイム・ソフトウェア」の時代です。
その通りですね。特定のビューを表示させたい瞬間があれば、エージェントはその瞬間のためだけに専用に作られたシングルページのJavaScriptとしてソフトウェアを構築し、いつでも呼び出せるスキルファイルとして保存すればよいのです。
以前は「チャットがすべてのAIアプリケーションのUIになるとは限らない」という陣営にいましたが、完全に考えが変わりました。これらのツールを経験し、深く省察を重ねる中で、なぜチャットがより優れたインターフェースであるのか。それは、チャットが人間の言語に最も近く、言語や記述こそが思考の表現に最も近いからです。したがって、チャットは明確な知能への最短の架け橋なのです。
特定の固定されたボックスの中にAIを閉じ込めてしまうのは、私たちの可能性を狭めすぎます。だからこそ、チャットインターフェースに全面的に賭けるべきだと考えるようになりました。マルチモーダルである点も重要です。Telegramなどの音声メモを使い、タイピングしたくない時には音声で指示を出しますが、まるで人間に話しかけているかのように、テキスト、音声、画像、ファイルをClaudeに渡すことができ、極めて快適に動作します。
私はまさにこれを体感しました。1月と2月を通じて、Railsアプリケーションのために50万行のコードを書いて「Gary's List」を構築しました。ブログのようなシステムですが、ブログ自体は最初の1週間で構築し、残りの1ヶ月半は、独自のディープリサーチやファクトチェックを行う完全なエージェント枠組みの構築に費やしました。しかし、私はそれを2013年当時の手法、つまりWeb 2.0のやり方で構築してしまったのです。Claude Codeはそのような開発を可能にします。
そして驚くべきことに、過去3日間でGbrainのために約4万行のコードを書きました。Gbrainは実質的にGary's List 2.0ですが、完全にオープンソースです。エージェント検索、音声抽出、ファクトチェックのために書かなければならなかったすべての機能が、現在Gbrainの内部に存在しています。昨日、それをGary's listのチームに独自のOpenClawインスタンスとして引き渡したところ、彼らの開発スピードは爆発的に向上しました。
彼らは、私が作ったモノリシックなライターのチャットインターフェースがバグだらけであると不満を漏らしていました。私がOpenClawやTelegramがすでに備えている機能を再実装しようとしていたからです。今では彼らはOpenClawとTelegram、そして私が抽出したデータとMCPを組み合わせた検索システムを使い、完璧に機能しています。Gary's List 2.0の次の書き換えは、幸いにも50万行のRailsコードを必要としません。手動での記述を100分の1に減らしたとしても、それは硬直的で時間がかかります。50万行のRailsコードは、容易に1万行のTypeScriptと2000行のMarkdownに置き換えることができ、しかもはるかにダイナミックです。
たとえば「2段目の段落には、焦点を当てている政治家の伝記を含めたい」と言えば、Railsでコードを書く必要も、複雑な評価インフラで実行されるRubyファイルを書く必要もありません。OpenClawはそれを自然に理解し、評価スキルを実行します。編集長はそれをオンザフライで変更でき、私はコードに一切触れません。
これは本当に狂気的であり、ジャストインタイム・ソフトウェアの夜明けを目の当たりにしています。私が使用してきた最高のAIソフトウェアは、YCの社内ツールであれ他者が構築したツールであれ、事前に記述するコードの量を最小限に抑え、モデルの能力を最大限に輝かせるように設計されています。
それだけで驚くほど多くのものを構築できます。何万行ものコードを書くことも可能ですが、理解しなければならない初期の認知負荷が極めて低い、この上なくシンプルな状態からスタートできること自体が信じられないほど強力です。将来のほとんどのソフトウェアはそのような姿になると思います。
それこそがOpenClawが非常にうまく機能した理由です。いくつかの要素、つまり少しのペルソナ（個性）を与え、永続性を持たせ、長期的なメモリ（記憶）の概念を持たせること。完璧ではなくとも、そのユースケースには十分な性能を発揮します。
Claude Codeの開発者であるボリスがYCで話をしてくれたときも、彼がどれほどシンプルさに執着し、プロダクトを可能な限り小さくすることに心血を注いでいるかが印象的でした。私のお気に入りの例は、「Pi」と呼ばれるオープンソースのハーネスです。これは技術者がすぐに使える、最小限の構成のコーディングエージェントです。Piを使用して、Pi自体のコードを修正し拡張することができます。自己拡張的で自己参照的なソフトウェアというアイデアは非常に魅力的です。そしてOpenClawもその思想の上に構築されました。このミニマルな状態から始めて、エージェントを使って時間をかけて拡張していくという形式のクラシックなソフトウェアが、今後どれほど登場してくるか非常に興味深いです。
未来の商用ソフトウェアの多くには、こうしたカスタマイズ能力が標準で備わってくるようになると思います。
AIの民主化か、中央集権的な支配か
あなたのエッセイから学んだ非常に洗練された視点として、「AIは中央集権化をもたらすか、それとも分散化をもたらすか」という選択の問いがあります。GoogleのGmailにおける「プロンプトを変更できない」という仕様は、前者の完璧な例です。私たちは今後18〜24ヶ月、長くとも5年の間に、一つの選択を迫られることになります。
脳裏をよぎるのは、アップルによる1984年のマッキントッシュのCMです。2034年の未来は、あの『1984年』のような世界になるのでしょうか。中央集権的なコントロールのシナリオでは、5人の王が存在し、そのうちの1人が勝ち残り、最も進化したAIと、計算資源（コンピューティング）と電力へのアクセスを独占します。アメリカ国内には陸上のデータセンターをこれ以上建設できないため、彼らは巨大な宇宙データセンターを保有し、コントロールを集中させます。さらに、ユーザー自身がプロンプトを実行することを許さず、全コンピューティング体験において例のGmailのような制限を課します。
これは、パーソナルコンピューターが誕生せず、メインフレームとミニコンピューターしか存在しなかった世界線のようです。歴史の砂に埋もれてしまいがちですが、1960年代や70年代にコンピューターが登場した当時、今日のようにアップルストアに行ってiPhoneやMacを購入することはできませんでした。数十万ドルから数百万円の価値がある巨大なシステムへのアクセス権を得る必要があり、それらは企業のポリシーによって厳格にロックダウンされていました。
その通りです。そして、コンピューティングの革命を真に推し進めたのは、人々が個人の手元で実験できるパーソナルコンピューターを持ち始めた瞬間でした。
当時は、資本と生産手段を支配する少数の聖職者（プリーストフッド）と制度的基盤が存在していました。それが、私たちが直面する可能性のある、しかし私が絶対に生きたくはないコヒーレントな未来の姿です。
それに対するオルタナティブ（代替案）が、ホームブリュー・コンピューター・クラブの精神に埋め込まれており、スティーブ・ジョブズとスティーブ・ウォズニアックがマウンテンビューのガレージでブレッドボードに半田付けをし、500台のApple Iを販売したあの革命に埋め込まれています。私たちは今、まさにその「Apple Iの瞬間」にいます。私たちはプリミティブを考案し、これらがどのように機能し、どのようにパッケージ化して販売できるかを学んでいます。
しかし現在、多くの選択肢が存在する中で、10億人の大衆ユーザーはChatGPTを使用しており、ChatGPTは限定的なアクセスしか提供していません。MCPは厳格にロックダウンされており、自分のデータベースに接続するのも容易ではありません。Claudeはもう少しオープンであると主張したいところですが、実際にはそれほどでもありません。Perplexity Computerはおそらく現時点で最も優れたバージョンの一つですが、OpenClawやHermesエージェントで実行できることと比較すれば、まだ非常に限定的です。
では、真のパーソナルAIの瞬間としての革命はどのような姿をしているのでしょうか。それこそが、私たちがGbrainやHermes、OpenClawを通じて構築したいと願っているものです。独自のソフトウェアを実行し、独自のプロンプトを変更し、そのすべてをテストし、自分だけのプライベートなリポジトリを持ち、どのモデルを使用するかを選択し（それがオープンウェイトのモデルであってもよい）、そうした自由を持つこと。これこそが、AIにおける「ホワイトピル（希望の薬）」です。
さもなければ、企業の管理下に置かれ、自分のプロンプトをコントロールできず、AIがあなたに対して一方的に「発生」する（APIラインの下に置かれる）未来になります。私は10億人の人々が、自分自身のためにAIをコントロールし、プログラミングできるようになる選択肢を望んでいます。AIはあなた自身と、あなたが大切にしていることの延長線上にあるべきであり、MetaやAlphabet、あるいはOpenAIやAnthropicが関心を持っていることの延長線上にあるべきではないのです。
AIが「人間の代替」として語られるのを目にするとき、私はいつも強い違和感を覚えます。なぜなら、私や私の周囲の多くの人々が経験してきたAIの姿は、人間の代替ではなく、人間を強力にエンパワーするツールだからです。メインフレームからPC、そして全員にパブリッシング・プラットフォームを与えたインターネットへと至るテクノロジーの発展の歴史を振り返れば、それは何よりも個人のエンパワーメントの物語です。AIも全く同じように展開していくでしょう。私たちがかつてできなかったことを、より多く成し遂げることを可能にし、過去に私の仕事を苦痛にさせていた退屈な雑務（ドラッジワーク）を消し去ってくれるはずです。
そのためには、私たちが自ら選択を行う必要があります。デフォルトの状態では、企業はオープンではありません。デフォルトの企業構造とは、コマンド＆コントロール（命令と統制）です。リーダーシップ層はこれらのツールへのアクセスを得るかもしれませんが、現場のスタッフ層には与えられません。だからこそ、私たちは根本的に異なるタイプの組織を必要としており、異なる方法でコンピューティングを提供する必要があります。これらの選択を行うのは、これを見ている、社会の中でこれらのシステムを構築していく人々です。私たちは賢明な選択をしなければなりません。
本日の時間はここまでです。かなり重厚なテーマをカバーできたと思います。ピート、参加してくれてありがとうございました。
ありがとうございました。
ご視聴ありがとうございました。また次回のエピソードでお会いしましょう。
コメント