本動画は、YCのゲイリー・タンが長いブランクを経て再びソフトウェア開発に戻り、Claude CodeやOpenClaw、GStack、GBrainを使って驚異的な速度でコードを書き、プロダクトを構築していく過程を語る内容である。薄いハーネスと厚いスキルという新しい開発思想、トークン最大化、個人AI、そして人間がAIツールを制御し続けることの重要性について掘り下げる対談である。
自分のツールを支配するのか、ツールに支配されるのか
それが決定的な問いだと思います。自分のツールを自分で制御できるのか、それともツールに自分が制御されるのか、ということです。
最近OpenClawを使う感覚は、フェラーリを運転しているようなものです。ものすごく爽快で、正気じゃないくらいです。機械がそんなことを理解できるはずがないと思うようなことまで、ちゃんと理解してくれるんです。しかも、とても速い。
でも同時に、フェラーリでもあります。つまり、自分が整備士である覚悟が必要なんです。一番必要なときに道端で故障するフェラーリみたいなもので、レンチを持って外に出て、ボンネットを開けて、直さないといけない。自分で直す必要があるんです。
だから今は、コンピューターサイエンスとテクノロジーにおいて、とても刺激的な時期です。
ゲイリー・タンが再びビルダーに戻った
Light Coneの特別回へようこそ。今回は、ゲイリー・タンがどのように再びものづくりに戻ったのかについて話します。
Twitterで私たちをフォローしている人なら知っていると思いますが、数年にわたって投資家として過ごしたあと、ゲイリー・タンはビルダーに戻ってきました。そしてこの数か月で、何十万行ものコードを出荷し、ゼロからGitHubで10万スター以上を集める人気のオープンソースプロジェクトを作りました。しかも、それをYCをフルタイムで運営するという非常に大変な仕事をしながらやったんです。
インターネット上では、そんなことは可能なはずがないと考えている人も多く、かなり信じられないという反応もあります。でも実際に起きました。私たちはその場にいて、全部見ていたので分かります。だから今日は、彼がどうやってそれを実現したのか話していきます。
正直、自分でもかなり驚いています。私もびっくりしています。13年間コードを書いていなかったのに、突然、ドンと、その年にやっていた仕事量の400倍くらいをやるようになったんです。最後に自分の時間の3分の2くらいをコードを書くことに使っていた頃と比べても、そうです。
まずは、すべてのきっかけになったプロジェクト、Gary’s Listに戻るところから始めるのがよさそうですね。
ああ、そうですね。
数か月前にClaude Codeを本格的に使い始めて、コーディングに戻っていった話をしましょう。
Lyonのエピソードの直後でしたよね。
そうですね、間違いなくそうです。自分が信じていることを同じように信じている人たちを集めたいと気づいたんです。特にカリフォルニアのためにです。それで501(c)(4)を始めました。今はC3とPACにもなっています。多くの政治団体がやっているような形です。人々を結びつけるための、ごく一般的な方法です。
みんなお金に注目しますが、私たちは賢い人たちを集めようとしているんです。サンフランシスコ政治に関わってきた数年で学んだのは、人を集めることにはものすごい力があるということです。それこそが大規模な社会運動です。
それで、ではそれを始めるためのウェブサイトを作ればいいんじゃないかと思いました。まずは、自分が心配している課題について書くことから始めればいい。たとえば、子どもたちに学校でちゃんと学んでほしいということです。
世界中からこれを見ている人たちには、とても奇妙に感じるかもしれません。私自身も奇妙だと思っています。サンフランシスコの公立中学校に通う7年生や8年生が代数を履修することが、不可能で、今でも非常に難しいという状況です。
これは数学教育の問題でした。もし私がベイエリアのイーストベイの公立学校にいたときにそれを学べなかったら、スタンフォードで工学を学ぶことはなかったでしょう。コードを書くこともなかったでしょう。今やっていることのどれもできなかったはずです。だから私にとってはすごく大事な問題でした。
そして、コードを書くときが来たんだと気づきました。私は結局、2008年の最初のYCスタートアップであるPosterousを作ることになりました。
Posterousを覚えていない人のために説明すると、何だったんですか。
Posterousは、メールで投稿できる、とてもシンプルなブログでした。インターネット上でトップ200に入るウェブサイトに成長し、その後Twitterが約2,000万ドルで買収しました。だから、私にとって最初の大きな成果のようなものでした。
実はその後、Twitterがそれを買収したあと、採用していた素晴らしい人たちのために、Post Havenとしてもう一度作りました。Twitterはそのスタートアップを閉鎖しました。Twitterから買い戻すには数百万ドルかかったでしょうが、当時の私はまったくお金がありませんでした。だから次善の策として、もう一度自分で書けばいいじゃないかと思ったんです。
そして今年の1月に、私はそれを3回目に書きました。ただし、最初のときは約400万ドル、6人か7人、1年半くらいかかりました。2回目は、たぶん10万ドルくらい、私と共同創業者のブレット・ギブソンの2人で、今はInitializedを運営している彼ですが、3か月くらいでした。そして今回の場合は、約200ドルでした。それはClaude Code Maxアカウントの費用です。そしておそらく5日でした。
フル機能のブログプラットフォームで、必要なことは全部できます。そのうえで、完全なRAG、完全なエージェント型検索も備えています。外に出てインターネット全体を読みに行くようなことができるんです。私がこれまでにしたすべてのツイート、再帰的クロール、どんなトピックでも深いリサーチができます。
代数の件は、私たちが本当に大切にしているさまざまな課題のうちの一つにすぎません。インターネットを取り込み、賛成と反対のすべての議論を見て、バックエンドで非常に詳細なレポートを作ることができます。引用できる箇所は何か、というようなことです。
Light Coneを熱心に見ている人は、初期のエピソードの一つで、ジェイク・ヘラーとエージェント型システムについて話した回を覚えているかもしれません。ジェイクはCasetextを作りました。そして彼が説明していたことは、私が最終的に構築したものそのものです。つまり、何らかの論点や起きているニュースについて、ジャーナリスティックな長文記事を作るためのものです。
だから今なら誰でもgarys.orgに行けます。私たちは毎日2本から3本くらい、かなり調査され、完全に出典が付いた記事を出しています。カリフォルニア、サンフランシスコ、LAで何が起きているのか、どうすればより良い政府を作れるのか、という内容です。
Gary’s Listについて人々が見落としていると感じるのは、まさにここで私たちがずっと話してきた古典的なことなんです。ソフトウェアとは、人々が使うために作るものだった。つまり、ブログプラットフォームを作ると、人々がブログを書く。そしてやがて自分のSubstackを始めたり、記事を書いたりするかもしれない。
でもGary’s Listは、ブログプラットフォームであると同時に、高品質な調査報道記者の仕事そのものを実行します。記者が記事を公開するために使うだけのものではありません。
そうですね。基本的に、Opusの呼び出しで5ドルから10ドル相当くらいだと思いますが、本物の人間がやるなら、何十本もの記事を丹念に読み、特定のテーマについて本を丸ごと読み、注釈を付けていく必要があるような仕事をやってくれます。
Casetextの例に戻ると、ジェイクが私に教えてくれたのは、与えられた文脈の中で人間なら何をするかを考える必要があるということです。何を取り出すのか。図書館に行くのか。どんな本を探すのか。ウェブでは何を検索するのか。
今の素晴らしいところは、それをただ一つの方法でやる必要がないことです。PerplexityのAPIを使って、そこでDeep Researchができます。XのAPIもあり、そこでDeep Researchができます。Xについて調べる必要があるなら、GrokのAPIを使った調査は実際とても優れています。そうやってすべての文脈を集められます。
これは私のエッセイの一つである、海を沸かせという考え方に戻る話です。特に今エージェント型ソフトウェアを作るときには、人間がコードを書いていた頃にやっていたことに落ち着く必要はありません。これはリサーチにも当てはまります。
徹底的に海を沸かしたらどうなるのか。完全主義者として、人間ならこの調査に1か月かかるとしたらどうか。もっと強く岩にレーザーを当てればいいんです。より多くのお金を払う。トークン上限に近づくかもしれない。でもトークンは最大まで使うべきです。
基本的に、何かをより完全に、より素晴らしくする追加作業があるなら、それをやるべきです。この種の執筆の場合でいえば、私たちは現実をより代表するものにしたいんです。一つのソースで満足する必要はありません。20のソースを得られるならそうする。相互参照もできる。この13のソースはこう言っていて、7つのソースはそれに反対している、と分かる。そしてその文脈すべてを中核となるプロンプトに入れる。
そうすると、単に人間がリンクをクリックして見出しを読み、それだけで理解した気になる場合よりも、より良い判断ができます。トークンを最大化するなら、今できる最もクールなことはまさにそれだと思います。
それは記事生成だけの話ではありません。コードを書くことにおいても明らかにそうです。今後は、社会のあらゆる部分に浸透していくでしょう。私たちが知識労働と呼ぶものは、すべてトークン最大化できるはずです。
それは人間が不要になるという意味ではないと思います。人間は依然として主体性を供給する必要があるという意味だと思います。私はこれが必要なんです。代数のことでここに座って気にしているのは私です。私立学校に行けなかった自分のような子どもたちに学んでほしいんです。
サンフランシスコは、世界で最も私立学校への通学率が高い都市です。おそらく全米でもそうでしょう。それはよくありません。良い教育を受けるために裕福である必要はないはずです。それがなぜ議論を呼ぶのか、私には分かりません。
だから私にとっては、テクノロジーの大きな変化が起きていて、そこに自分の必要、望み、欲求がありました。それは燃えるような欲求でした。10歳、12歳、13歳の子どもたちが代数を知らないことを考えると、私は傷つき、苦しくなります。学べたはずなのに、官僚や、権力の座にいる美徳アピールをする人が、代数を学びたいその子に実は学ばせたくないと言っているわけです。
Gary’s ListからGStackへ
若い頃のゲイリーが抱えていた痛みと必要を解決し、Gary’s Listを構築する過程で、トークン最大化やこの新しい構築方法に関する多くのパターンを発見したわけですね。そしてそれが次のプロジェクト、GStackにつながった。
実はGStackを作る予定はまったくありませんでした。ただ、自分が同じことを何度も何度もやっていることに気づき、同じことを入力するのが嫌になっただけなんです。それでApple Notesを開いて、Claude Codeに何度も書いていることを全部入力しました。
かなり単純な内容でした。たとえば、計画レビューはこう、というものです。私がやり始めたことの一つに、ClaudeにASCIIアートの図を作らせるのがすごく好きだというものがあります。発見したことの一つは、Claudeが混乱してバグを書いたり、不完全なものを書いたりすることがあるということでした。
でも、作業を始める前に、すべてのデータフロー、すべての入力と出力、ユーザーフロー、エラーメッセージについてASCII図を作ってくれと言い始めると、データフロー、状態機械、依存関係グラフ、処理パイプライン、意思決定ツリーが見えるようになりました。それをやると、すべての文脈が読み込まれて、より完全に作業をしてくれるようになったんです。よりうまく海を沸かしたわけです。
そして、それはいくつかのセクションに分かれました。アーキテクチャレビュー、コード品質、テスト、というようにです。
Gary’s Listを作って学んだことの一つは、自分でコードを書いていたときは、いつも最小限のテストしかしなかったということです。あまり楽しくなかったからです。必要なのは分かっていました。でも私は新しくて楽しいコードを書きたいんです。テストを書くためにコードを書いていたわけではありません。
そして正直なところ、バイブコーディングを始める人がみんなぶつかる問題に私もぶつかりました。これは雑だ、あまりうまく動かない、80%のケースでは問題ないけれど、実際にユーザーが触ると崩れ始める、というやつです。
そのとき、テストカバレッジ100%まで行けるんだと気づきました。その後、100%はたぶんやりすぎだと学びました。現時点では80%から90%に到達するのがたいていベストプラクティスです。
でも、これが基本的にplan-go-reviewの最初のバージョンでした。みんなオフィスアワースキルを知っていると思います。新しいプロダクトや新しい機能を作ろうとしているときに人々が使えるもので、私も今でも使っています。私たちが会社と一緒に仕事をするときにやることをシミュレートするんです。どうやって人々がこれを欲しがっていると分かるのか。誰のためのものなのか。何をするのか。そしてインパクトは何か、ということです。
でもこれは原型のスキルでした。私はスキルというものが存在することすら知りませんでした。それを投稿したらバズりました。20万人が見ました。そして、もっと広範な別バージョンを作りました。それをメガプランと呼びました。その後、CEOプランに名前を変えました。
メタリングについては以前話したことがあるかもしれません。ここではメタプロンプティングを使いました。私たちが持っていた別のレビュープランを取り、それから、これのバージョンを作ろう、ただしブライアン・チェスキーが隣に座っていると想像して、という感じにしました。
ブライアン・チェスキーには、10つ星体験とは何かという素晴らしい言葉があります。要するに、みんなホテルを2つ星や3つ星の体験、4つ星の体験というふうに考えるわけです。彼は5つ星までリストをたどります。みんな、いいね、という感じです。でも彼は、では6つ星は何か、7つ星は何か、8つ星は何か、と問い続けます。そしてそのリスト全体を進んでいくんです。
これは私のお気に入りのプロダクトとデザインの思考演習の一つです。そしてクールなのは、今なら毎回それができるということです。これがそれです。このプロンプトは基本的に、それのプラトン的理想が何かを見つけようとします。
ここにはかなり素晴らしいものが二つあります。一つは10倍チェックです。2倍の労力だけで、より野心的で10倍多くの価値を届けるものは何か、ということです。
なぜか、潜在空間から出てくることがモデルの可視化を大きく助けます。だから私はplan CEOスキルを実際とても気に入っています。私はADHDのCEOで、純粋な可能性が大好きです。これは信じられないくらいで、文字通り短い2文なのに、とてつもないものを解き放ちます。
そうしてGStackは始まりました。最初から何か大きなものにするつもりだったわけではありません。ただ、スキルをいくつか作る必要があるなと思っていたんです。人々がスキルのリポジトリを作っているという話も聞いていました。
それから3つ目にやったのは、この二つのスキルをあまりにも頻繁に使うようになった結果、自分のconductorインスタンスがかなり詰まってしまったことです。
15個の機能を並列で進める日常ワークフロー
これが私のconductorの使い方です。実際の私のセットアップです。
これが毎日のワークフローなんですね。月に何十万行ものコードを出荷してきた方法が、全部ここにある。
そうです。直近48時間で13本のPRを出しました。そして、それらをキューに入れていくんです。新しいアイデアを思いつくたびにここに来ます。これです。
私はCEOスキルを使うのが大好きです。とてもよくテストされたものにするためのスキルを使うのも大好きでした。それを全部プランモードでやりました。それからここで承認をクリックすると、Claudeが全部やってくれます。
それをあまりにもやった結果、15個の異なる機能が全部キューに入って、私が手動でテストするのを待つ状態になりました。エンドツーエンドテストは通った。統合テストも通った。ユニットテストも通った。でも結局のところ、Gary’s Listの場合なら、Railsサーバーを開いて、そのユーザーを読み込んで、その特定のユーザーの構成にして、手動で本当に動くか確認する必要があります。
それが嫌になって、Claude in Chrome MCPを使おうとしていました。でも、それは非常に遅かったんです。ターンごとに2秒から3秒かかりました。これはQAには使えないと思いました。
でもMicrosoftがPlaywrightをリリースしていたと聞いていました。代替のテストフレームワークのようなものです。振り返ってみれば、エージェントハーネスや他にも使えたツールがあったんだと思います。でもClaude Codeの良いところでも悪いところでもあるのは、何かを始めるのが非常に簡単なことです。
私はただこれを開きました。文字通りここに入りました。たぶん私がやったのはこういうことです。Chrome MCPのClaudeを使うのはもううんざりだ、遅すぎる。MicrosoftのPlaywrightをラップしよう。できるかな。そう入力して、エンターを押しただけです。
そしてGStackで見えてきたことの一つは、今の私はこうやって新機能を作るということです。もちろん今これをやると、もうそれは作ったでしょ、と言われます。笑えますね。
私のところには、バグ修正が巨大な機能の隣に並んでいます。GStackの仕組みとしては、CEOがいます。デザイナーがいます。実際には開発者体験の担当者もいます。いくつかのデザインツールがあり、最後にPlanGEがあります。そして私はたいていSLCEXを実行します。最近、slashclaude in codexも追加しました。
私がYCの卒業生から学んだクールなことの一つがあります。イベントに来て、頭が完全に混乱していましたが、バッチイベントに行き、Claude Code対Codexで何が起きているのかについて話していました。当時の私は完全にClaude Codeだけの人間でした。
そこで気づいたんです。実はCodexを好む人が多い。なぜだろう、と。そして分かったのは、Claude CodeはADHDのCEOには理想的だけれど、ときどきClaude Codeはかなり適当なことを言うということです。Claudeモデルはとても優れていますが、実は最も賢いわけではありません。
多くの人が私に説明してくれたのは、もっとずっと狂ったような問題があるなら、IQ200でほとんど話さないCTOが必要だということです。だから友人を呼び込めるようにした。それが/codexです。
これはGStackのスキルで、あなたの計画が何であれそれを取り込みます。あるいはプランモードを出てすでに実装しているなら、リポジトリを取り、コマンドラインプロンプトでCodexを実行します。そのプロンプトは、すべての問題とすべてのバグを見つけろ、というものです。そしてそれをClaude Codeに報告し、あなたとClaude Codeがそのフィードバックを通じて作業できるようにします。
その後、Codexをメインのコーディングエージェントとして使う場合には、/claudeと入力して、必要ならClaudeに一時的にCEOとして来てもらうこともできるようにしました。
GStackのクールなところは、私がこのプログラムを通して実行するとき、いつもオフィスアワー、CEOレビューから始めることです。UIがあるならデザインをやります。開発者がそれを使う必要があると分かっている場合、つまりGStackやGBrain関係のほぼすべてですが、開発者レビューを実行します。そしてレビューをして、計画が終わったらCodexを使います。
すべての問題に取り組んだあと、GStackはask user questionにかなり強く依存しています。私にとってそれはとても重要です。そこが、人間、つまりバイブコーダー、オペレーター、エージェント型エンジニアが、自分たちが何を作っているのか、何が起きているのかについての理解を提供する場所だからです。その代替は本当にありません。
人間がループに入らずに、ソフトウェアをただ作れるものを本当に作れた人がいるとしたら、私はかなり驚くでしょう。これは物議を醸す意見かもしれませんが、私は完全にループの外に出たいとは思いません。機械には、自分がやりたくないことをやってほしいだけです。
だからQAは良い例です。デモに戻ると笑えるのですが、現代版のGStackに何か入力すると、何をしているんですか、もうそれは作りましたよ、と言われます。browseがあります。browseはCLIとして70個のコマンドを持つ、長寿命のHPデーモンです。そしてQAは単にbrowseです。
ただしQAのプロンプトには、自分のコンテキストを見ろ、このブランチで何をしたのかを見ろ、UIやデータの変更があるなら、ブラウザを使ってそれをテストしろ、と書いてあります。これはクールです。ブラックボックスブラウザを持っているようなものです。
最初に動いたときは衝撃を受けました。ミニAGIはもうここにある、と思いました。もちろん、これは本物のAGIではないことは分かっています。本当の本当のAGIなら、私はここにすらいないでしょう。そして実際、この点ではそれでいいんです。
ビルダーとして、少し利己的に言えば、私たちが止まらなくて済むことを願っています。機械が決して完全には理解しきらないことを願っています。なぜなら、それはすごくクールだからです。そうなれば、人間は本当に重要ですし、これをどう扱うかを知っているエンジニア、センス、デザイン、プロダクトフィードバック、本物の顧客を念頭に置ける人は、ずっと翼を持っていられます。
YC Startup Schoolが戻ってきました。私たちは世界で最も有望なビルダーを厳選し、7月25日と26日にサンフランシスコへ招待して、テクノロジーの最前線について議論します。今すぐ参加枠に応募してください。
では動画に戻りましょう。
薄いハーネスと厚いスキル
この薄いハーネスと厚いスキルについてのXの投稿で、こうした考え方の多くを結晶化させたと思います。
そうですね。これはトークンを最大化する方法に関するこの哲学全体を含んでいます。
その一部は、インターネット上でMarkdownについて容赦なく荒らされたことから生まれました。私はMarkdownの代わりにMarkdownを売り歩いているだけだ、みたいなことを言われたわけです。でも、現時点での私の実感としては、Markdownは実際にはコードなんです。ただ、別の方法でコンパイルされているだけです。コンピューターに本当に驚くようなことをさせられます。
これだけでもそうです。私がVisual Studioを置き換えたものに話しかけているなんて、想像できたでしょうか。私はVisual Studioをまったく使いません。使う理由がないんです。エージェントに話しかけると、エージェントがこれをやってくれるからです。
記事の名前は実際、私たちのパートナーであるピート・クーミンから来ました。私たちは内部エージェントを作る必要があり、そのことを何度もハーネスと呼んでいました。そしてある時点で、Claude Codeを一日中使っていて気づいたんです。なぜ毎回そのバージョンを書き直す必要があるのか。ハーネスとして本当に素晴らしいものをそのまま使えばいいじゃないか、と。
ハーネスとは、ユーザー入力を受け取り、それをLLMに渡し、LLMがやることを実行する中核ループです。ツール呼び出しなどもできます。なぜ私たちがそれを作る必要があるのでしょうか。私たちが時間を費やすべきなのは、どんなMarkdownがあるべきかを考えることです。
Markdownの考え方は、もしあなたがイベントプランナーで結婚式を企画していて、次回また結婚式を行うためのチェックリストを書こうとしているなら、次にそれを担当する人に何をすべきか教えるために、平易な英語で何を書くか、というものです。そのすべてがMarkdownに入るべきです。
一方で、決定論的であるべきもの、あるいは実際のアクションであるものもあります。たとえばウェディングプランナーが20か所の会場に電話する必要があるかもしれません。でもそのためにMarkdownは使わないでしょう。たとえばTwilioを呼び出すでしょう。
今日のエージェント型エンジニアリングにおける難しさの多くは、本来Markdownにあるべきことをコードでやろうとして失敗するところにあります。コードは壊れやすく、特殊ケースを理解しないからです。実際、コードはあなたが何を望んでいるのか、あなたが誰なのかを文字通り理解しません。チューリング完全なループの中で、決定論的な0と1を実行しているだけです。コードは知らないんです。
でも今は、潜在空間を持つLLMがあります。それはあなたが誰かを知っています。あなたの動機を知っています。一般的なケースを扱えます。だから今エンジニアとしての魔法の多くは、これはどのくらいLLM側に置くべきなのか、どのくらいコード側に置くべきなのかを見極めることなんです。
さらに、私が学んだもう一つのこと、つまりテストは80%から90%まで持っていくべきだということと組み合わせる必要があります。テストされていないものにユーザーを投げ込んでいるだけなら、それは雑なものです。人間が書いたコードより10倍悪いかもしれません。何が起きるかまったく分からないからです。
だから人々がやるべきことの一つは、潜在空間で何が起きていて、決定論的空間で何が起きているのかを理解するだけではありません。それが個別にユニットテストされ、統合もテストされていることを確かめる必要があります。
そして海を沸かせに戻ると、機械は気にしません。ただやってくれます。すごいことです。もっと岩にレーザーを当てれば、90%のテストカバレッジまで到達できます。そして、完全ではないにせよ機能するシステムを持てます。
OpenClawは今、多くの失敗ケースがあります。でも95%はそこまで来ています。最近OpenClawを使う感覚は、フェラーリを運転しているようなものです。爽快で、正気じゃないくらいです。機械が理解できるはずがないと思うようなことを理解してくれるんです。しかもとても速い。
でも同時に、それはフェラーリでもあります。つまり、自分が整備士である覚悟が必要です。一番必要なときに道端で故障するフェラーリみたいなものです。レンチを持って外に出て、ボンネットを開けて直さなければなりません。自分で直す必要があるんです。
だから今は、コンピューターサイエンスとテクノロジーにおいて本当に刺激的な時期です。これはHomebrew Computer Clubです。Apple 1が出てきた瞬間のようなものです。スティーブ・ジョブズとスティーブ・ウォズニアックが作ったApple 1は、文字通り釘とダクトテープで組み立てられた木製ケースの中に入ったブレッドボードでした。
パーソナルコンピューターが欲しいなら、それをやる必要があったんです。そして今の私たちもそこにいます。比較的賢く技術的で、コンピューターサイエンスを学ぶ必要があった人たちが、2時間か3時間、そしてトークンとクラウドの両方で500ドルから1,000ドルくらい使って、そういうものを動かす必要があります。
でも一度手に入れたら、私たちはキットカーのフェラーリ段階にいるようなものです。そこから運転できる。どこへでも行ける。そして丘に向かって叫びたくなります。フェラーリを手に入れたぞ、と。
自分で直すという部分についても、実際に押し通してみるまで、人々はなかなか分からないものだと思います。少し大きく見ると、物事は本当に急速に進みました。
ずっと昔を思い返すと、プログラミングの問題で行き詰まったときに相談できるStack Overflowというウェブサイトがあるだけで、すごいことのように感じました。その後ChatGPTが登場して、今度はStack Overflowよりずっと優れたインタラクティブなものを手に入れた、となりました。
でも、まだやっていることはだいたい同じでした。質問をして、コードをコピーアンドペーストして、そのコードを実行して、何が起きるか見て、それをまたコピーアンドペーストして戻すという感じです。
そしてClaude Codeで、ある段階を突破します。コピーアンドペーストをもうしなくていいと気づくんです。実際にコードを実行し、走らせてくれるからです。
OpenClawでも、セットアップして分かったのですが、確かに面倒です。実質的に自分自身を壊してしまうこともあるし、いろいろ厄介なこともします。でもClaude Codeがあれば、それを直してくれます。Claude Codeを走らせておくだけで、直してくれます。
明らかに長期的にそうなるわけではありません。でも、壊れやすくて修理が必要でも、実はそれは問題ではないという考え方の転換があります。なぜなら、別のエージェントをそこに座らせて、ずっと修理させられるからです。
OpenClaw、GBrain、そして知識LLMウィキ
この進化について言えば、私は完全にClaude Codeを信じ切っていましたし、今でもそうです。ただ、プロダクト構築やエージェント型エンジニアリングの時間のうち、Claude Codeにいるのは今ではおそらく50%か60%だけです。ある時点から、ほぼ半分はOpenClawを通じて行うようになりました。
それはとても興味深いですね。とはいえ、私は時間の大半をGBrain自体の作業にも使っています。
GBrainが生まれたのは、明らかにあなたと会い、番組にピーターを呼んだことがきっかけです。そしてようやく着手しました。ある週末に、これは見てみないといけない、OpenClawで何が起きているのか確かめよう、動かしてみようと思ったんです。
ちょうどその頃、カーパシーが知識LLMウィキについてのX投稿を書きました。それで私は、Markdownでいっぱいのリポジトリがある、すべての文脈をそのMarkdownに入れればいい、と思いました。
ある時点で気づきました。ああ、これはGPを使っているだけだ、と。そしてGPはそれほど良くありません。文脈を無駄にしているし、必要以上に多くのものをコンテキストに読み込んでいます。それで私は沼にはまりました。
conductorに入り、quick startをクリックしました。その時点でGStackはすでにconductorに組み込まれていました。基本的には、こうやって始めました。
実際には、それよりもずっと面白い始まり方でした。私はゼロから始めたわけではありません。より大きなコードのコーパスを書いていくと学ぶことの一つは、それが頭の中に読み込まれるということです。Gary’s Listのためにエージェント型ニュースルームを作るには、ベクトル埋め込み、ハイブリッドRRF、チャンキングについて学ぶ必要があったな、という感じです。
その中で動くものを作ろうとしているときは、とても応用的になります。自分が欲しい出力があります。記事はこう見えてほしい。この品質である必要がある。こういう引用が必要だ。そうしてテストや統合テストを積み上げ始めます。そして欲しい出力から鍛え上げられたプロダクトができあがります。
そこで私は二つを結びつけました。そしてこれは、実は誰でもできます。だからこそ、私たちはオープンソースの黄金時代に入っていると思うんです。
私はこのプロジェクトをconductorで開けます。そして最初に書くのは、チルダスラッシュgaryslistを見に行って、チャンキング、埋め込み、ハイブリッドRF、RAGをどうやっているか見ろ、ということです。それを抽出して、PostgresとPG vectorを使いたい、OpenClawのための完全なRAGシステムが欲しい、と書きます。
そこから一つが次につながっていきました。そしてGBrainで10個のウィンドウを開き、ひたすら取り組むようになりました。
OpenClawのクールなところは、たぶんこれが良い例です。これは実際の私のOpenClawです。私は実際に、それに聞いてみました。どうやって自分はそこに入っていったのか、と。
1月23日です。
あなたのメールも全部ですね。
私はツイートしていました。今週のClaude Codeが25歳の自分を目覚めさせた。Red Bullを飲み、夜明けまでコードを書いていた自分だ。完全に戻ってきた、と。
ビルダーとしてのアイデンティティが再浮上したわけですね。
そうです。そして私は基本的に、睡眠4時間、1日20時間コードを書く生活に戻っています。この頃から、コード行数について話して自分を面倒に巻き込み始めた時期でもあります。
ちなみに、今でもこれは信じています。
コード行数は生産性を測れるのか
ここで少し脇道にそれて、コード行数が重要な指標かどうかという話をするのはよさそうです。これはインターネット上で議論になってきました。もちろん反論として、コード行数は開発者の生産性を測るものではない、というものがあります。
測れませんよね。
でも測れる部分もあります。
ある程度は測れますよね。
そうです。明らかに測れます。そして興味深いのは、実際に実行できる、広く公開されているGitリポジトリがあることです。それを使うと、余計なものを取り除き、実際の論理的なコード行数を標準化できます。私は実際にそれをやりました。
2013年の100倍の速度でコードを書いていると言って、少し面倒なことになりました。その後、論理行数に絞る処理をしたら、実は数字が上がりました。上がったんです。結局、私は実際には400倍の量のコードを生み出していました。
もちろん、私がそれを書いていたわけではありません。同時に15体のエージェントを指示して、それをやらせていたんです。数字で見ると、Claude Codeによる私のコード行数は少し減りました。でも驚いたのは、2013年に私が書いていたコード行数が70%くらい減ったことです。
ここに認識のズレがあると思います。人々がとても腹を立てるのは、人間がコードを書く場合、コード行数を水増しするのが簡単だからです。一方で、Claude Codeに文字通りコード行数を水増ししろと指示しない限り、必ずしもそうはしません。
間違ったものを作ることはあるかもしれません。うまく誘導できないかもしれません。正しいことをしないかもしれません。でも、人間が仕事でやるようにコード行数を最適化しようとしているわけではありません。それはただの現実です。
そして本当に驚くのは、2000年や1990年にさかのぼるソフトウェア工学の文献を見ると、プロのソフトウェアエンジニアが書く、テスト済みで本番投入可能な平均的なコード行数は、1日100行ではないとはっきり分かることです。50行とか30行です。
1日あたりですね。
1日あたりです。私の場合は14行くらいでした。でも私はパートタイムだったので、分かりません。
だから400倍という数字はそこから来ています。もう一つ分かっているのは、コード行数についてさらに人を煽る代わりに、そう説明すべきだったということです。もしインターネット上で私があなたを煽ったなら、本当にすみません。これにはもっと深い理解があります。そして私は最終的に、それをかなり詳しく説明するブログ記事を公開しました。
技術者にとって、これは少し重要という程度ではありません。非常に重要です。なぜなら、自分に何ができるのかという基準を実際に引き上げるからです。コード行数について私を攻撃していた人たちこそ、思い切ってやり、トークンを最大化すれば、最も翼を得る可能性が高い人たちです。
これは古典的な問題のようなものです。センスがあり、テクノロジーを理解しているなら、まさにそういう人こそ、これを得ることで最も恩恵を受ける人です。必要なのは、信じることだけです。戦うのをやめて、Claude Codeを開いて試してみればいいんです。
もう一つ起きている可能性があるのは、モデルやハーネスによって体験が劇的に変わるということです。私自身も気づいたことですが、OpenClawエージェントを通じて少しでも複雑なプログラミングタスクをやろうとすると、たいてい失敗します。Claude Codeとまったく同じモデル、つまりOpus 4.7なのに、単純なスクリプトを超えるようなことはあまり得意ではないと感じます。
だからClaude Codeに戻るんです。そしてある瞬間に気づきました。ああ、以前はこう感じていたんだ、と。6か月前でさえ、こういう感じでした。試してみても、こういうものはまだそこまで来ていないな、という感覚です。
そこにOpus 4.5のClaude Codeが来て、ああ、これは実際に来ている、再帰しようとしている、という感じになりました。
今、人々はOpenClawやHermesについて、まだそこまで来ていないとか、かなり手間がかかると感じているでしょう。でも保証します。来年の今頃には、ここで最初に聞いたことをみんなが言うようになります。地球上のすべての人が自分専用のAIを持つようになる、ということです。
私たちは、自分自身のAIを持ち、自分自身のデータを持ち、自分自身の統合を持つ世界に住むことができます。何が起きているかを見て、自分でプロンプトを書き、自分が見るものを制御できます。あるいは、企業に制御された世界になるかもしれません。どこかのホストに行くもので、Facebookフィードのようなものです。そのアルゴリズムを誰が書いたのか、それが誰の利益になるのか、その背後にどんなビジネスモデルがあるのか、分かりません。誰にも分かりません。
贈り物のようだった最も強力なアイデアは、パーソナルコンピューター革命でした。そして私たちは、個人AIでそれとまったく同じ変化を経験しようとしています。それは選択になります。人々は、自分のプロンプトを書き、自分のために書く気があるのかを見極める必要があります。
ピート・クーミンがここにいてくれたらと思います。彼から学んだことの一つもそこです。自分自身のプロンプトを持ち、自分のためにそれを書けない限り、あなたではない誰か、つまりあなたを理解せず、あなたのニーズを理解せず、あなたが独自に大切にしていることを理解しないPMや開発者のAPIガイドラインの下に置かれることになります。
そしてそれが決定的な問いだと思います。自分のツールを自分で制御するのか、それとも自分のツールに制御されるのか。
トークン最大化は新しい家賃である
ここに一般の人との断絶の一つがあると思います。こうした能力の多くは、最新最高のモデルを使っている必要があります。そして今のところ、それらを使い、トークンを燃やすにはかなりお金がかかります。
価格は下がってきていますが、たぶん人々は無料モデルや基本的なClaude Proサブスクリプションだけを試しているのかもしれません。
そうですね。そして一部として、この新しい方法、つまり構築におけるほとんどASIやAGIのような瞬間を本当に得るには、大量のトークンを燃やす必要があるということを説明しなければならないのかもしれません。トークン最大化というパラダイム全体です。
それは家賃を思い出させます。サンフランシスコの家賃です。YC創業者たちにいつもやらなければならないと感じることの一つに、一般的な話として、サンフランシスコに引っ越したくない、高すぎるから、というものがあります。でも実際には、そこに住まないことのほうがとても高くつくんです。
まさにその通りです。それが要点です。YCバッチの初期には、よく創業者が、こんなアパートは月に何千ドルも家賃がかかる、馬鹿げているように思える、払うべきかどうか、と言ってきます。答えは、絶対に払うべきだ、です。むしろもっと払って、サンフランシスコにいるだけでなく、Dogpatchのような場所にいて、偶然の出会いが生まれる地域にいるべきです。
トークン最大化は、創業者に教えなければならないことの一つになるでしょう。すぐには、そうすべきではないと分かるものではありません。これは実際、家賃に似ています。できるだけ多くを使って、最大限の効用を得るべきものの一つです。オフィスの机のように扱うものではありません。
机なら節約してもいいでしょう。超高級なソファも必要ありません。でもモデルの利用やトークン消費に関しては、かなり強く押し込むべきです。
YCの重要な格言の一つは、良いスタートアップアイデアをどう見つけるか、未来に住み、欠けているものを作れ、というものです。これはその深いバージョンです。必要なのは、自分の頭をコミットさせて、1日に500ドルをトークンに使うことを見て、それでも、自分にとって本当に大きな価値のあるものを作っていて、正しいものを作っている限り、それをやる、と言うことです。
時間がないからこそ自動化する
ゲイリー、変な質問なんですが、YCのCEOでもありながらこれら全部を作ろうとしたことが、ある意味で助けになったと思いますか。時間があまりにも足りないからこそ、会議の合間のわずかな時間で何十万行ものコードを書く方法を見つける必要があった。一方でフルタイムのソフトウェアエンジニアなら、ウェブサイトを開いてクリックしてテストする時間を取れます。そういう時間があなたにはものすごく限られていたから、すべてを自動化する方法を常に自分に迫っていたのではないですか。
私はときどき時間億万長者をうらやましく思います。自分の子どもたちを見ると、この子たちは今、時間億万長者だなと思います。Startup Schoolで出会う人たちにも、いつもそう感じます。今あなたは時間億万長者だ、これはすごいことだ、と。何でもできる。何でも学べる。これは素晴らしいことです。
だから個人的には、私の哲学は、自分の頭の中ではとんでもない急ぎの状態にある、というものです。今この身体で生きるために、たぶん100億回分の人生を生きたいと思っているんです。そしてすべての瞬間に意味が必要です。
もしトークンを最大化できるなら、機械の意識、機械の時間を何百万年分も買えるようなものです。今、私は時間億万長者になれます。それは自分自身の時間ではありません。自分のために働く機械の時間です。そして私が大切にしている人間の存在や、私が大切にしている大義に取り組むための時間です。
私はYCを大切にしています。ビルダーが構築できることを大切にしています。昨年の社内会議でも、オフサイトで、次の世代にこれらのツールの使い方をどう教えるかについて話していたのを覚えています。
だから、それがすべて壮大な計画の一部で、そこから始まったと言えたらいいのですが、そうではありません。でも潜在意識ではそうだったと思います。Light Coneをやって、この話をしていたことからです。
ここでボリス・チェルニーの隣に座ったのは、私にとって非常に強力な瞬間でした。彼が、自分にもできることを言い始めたからです。彼は、私たちのチームは1行もコードを書かない、と言いました。私は、ああ、それなら自分にもできる、と思ったんです。
今見ている人たちに言いたいのは、あなたと私は違わないということです。私たちは同じです。同じ場所から始めました。私は自分がもう空の上にいるとは思っていません。人々はそういうふうに話しているようですが、私はただ何かをやろうとしている一人の人間です。
ボリスの隣に座ると、彼は私がこれまで会った中で最高のエンジニアの一人です。でも同時に、プロンプトを開くだけなら、私たちは同じプロンプトを持っています。同じMacBook Proを持っています。そして、私やあなたや私たちの誰かが、人類に奉仕するために何百万年分ものトークンを引き出すことを妨げるものは何もありません。
ゲイリー、それはリツイートできる美しい言葉だったと思います。すぐにXに投稿しないといけませんね。機械から時間を借りることで、無限の時間を持てる。
そうです。なんて時代に生きているんでしょうね。
終わりにするには美しい考えですね。未来を見せてくれてありがとう、ゲイリー。
ありがとう。
ありがとう、ゲイリー。
はい、見てくれてありがとうございました。次回のLight Coneでまたお会いしましょう。
コメント