※本記事は、Y CombinatorのポッドキャストThe Light Coneのエピソード「We're All Addicted To Claude Code」の内容を基に作成されています。本エピソードでは、Segmentの共同創業者であり、OpenAIのCodexチームの元エンジニアであるCalvin French-Owen氏をゲストに迎え、コーディングエージェントがなぜこれほど強力に感じられるようになったのか、Codex・Claude Code・Cursorの違い、そして仕事の未来について議論しています。動画は https://www.youtube.com/watch?v=qwmmWzPnhog でご覧いただけます。本記事では、ポッドキャストの内容を要約しております。なお、本記事の内容は原著作者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご視聴いただくことをお勧めいたします。
1. Intro
冒頭では、本エピソードの見どころとなるハイライトが予告的に紹介されます。Claude Code を使っているときの「コードの中を飛んでいるような感覚」、CLIだからこそネストした遅延ジョブを5階層深くまでデバッグしてバグを特定しテストまで書いてくれるという驚き、スタートアップが限られたランウェイの中でコーディングエージェントを限界まで使い倒している現状、そしてトップ1%のユーザーになるためのヒントといった話題が断片的に流れます。
Gary： 皆さん、The Light Cone の新しいエピソードへようこそ。今日は素晴らしいゲストをお迎えしています。Calvin French-Owen さんです。彼は OpenAI で最初期に Codex を作った一人であり、それ以前には数十億ドル規模の企業に成長し見事なイグジットを果たした Segment を創業しています。Calvin、ようこそ。
Calvin： お招きいただきありがとうございます。
2. Gary が Claude Code をやめられない！
Gary： 今は本当にクレイジーな時代ですよね。自分は最近、Claude Code に完全に中毒になってしまいました。例えるなら、10年前の自分はマラソンランナーで走ることが大好きだったのに、「マネージャーモード」という壊滅的な膝の怪我を負ってコーディングをやめてしまったんです。それは本当に悲劇的でひどいことでした。しかしこの9日間は、かつてできていたことがすべて蘇るような信じられないアンロック体験でした。まるで人工膝関節の全置換手術を受けたら、実はバイオニック膝で、以前の5倍の速さで走れるようになったという感覚です。Calvin はまさに最前線にいるわけですが、どう見ていますか。Codex は今みんなが使っているアイデアの多くを切り拓きましたし、今も進化し続けていますよね。
Calvin： 簡単に背景をお話しすると、自分が OpenAI にいたとき、Codex の Web プロジェクトに取り組んでいました。当時は Cursor が市場に出ていて、GPT-3.5 あたりのモデルを薄くラップして IDE 上で動くようにしていました。Claude Code が CLI として登場したばかりの頃で、私たちは「将来のコーディングは同僚と話すような感覚になるだろう」というアイデアを持っていました。質問を投げると、相手がどこかへ行って作業をして、PR を持って戻ってくる。それが私たちが Web ビューから始めた出発点であり、方向性としては今も正しいと思っています。ただ、現実には今みんな CLI でコーディングしています。Claude Code であれ Codex であれ、CLI ツールがはるかに多く使われています。自分にとっての教訓は、Gary の言うとおり将来は誰もがマネージャーになるだろう、少なくともそれが自分のホットテイクですが、そこに至るまでにはステップがあって、モデルへの信頼を築き、モデルが何をしているかを理解する必要があるということです。Gary は最近 Claude Code に移行しましたよね。メインのツールとしてどんな感じですか。
Gary： そうですね、Claude Code は今の自分のデイリードライバーです。正直なところ、これは数ヶ月ごとに切り替わっています。しばらくは Cursor にどっぷりでしたし、Cursor の新しいモデルは本当に速くてかなり良いと思います。その後、特に Opus と一緒に Claude Code に移行しました。Claude Code は非常に面白いプロダクトで、プロダクトとモデルの両方がいかにうまく連携しているかは過小評価されていると思います。
3. IDEとの対比、コンテキスト分割
Calvin： Claude Code を注意深く観察すると、特に素晴らしいのはコンテキストの分割がうまいことです。Skills やサブエージェントといった仕組みを見ると、Claude Code に何かを頼むと、通常は探索用のサブエージェントを1つ、あるいは複数スポーンします。それぞれが Haiku を使ってファイルシステムをトラバースし、何があるかを調べていて、それぞれが独自のコンテキストウィンドウで動作しています。Anthropic は「あるタスクが1つのコンテキストウィンドウに収まるのか、それとも複数に分割すべきなのか」という判断について、何かを掴んでいると思います。モデルはこの判断が驚くほど上手く、だからこそ非常に良い結果が出ているのだと思います。
Gary： 面白いのは、ターミナル上にあるからこそ、コンポーザブルでアトミックなインテグレーションの最も純粋な形になっているということです。IDE ファーストの世界から来た場合、つまり Cursor がそうでしたし、Codex もそうだったと思いますが、コンテキストをより自由な形式で見つけるというコンセプトは、これほど自然には出てこなかったでしょう。
Calvin： 個人的に驚いたのは、20年前のテクノロジーである CLI が、未来であるはずだった IDE をすべて打ち負かしたということです。奇妙なレトロフューチャーですよね。
Gary： 100%同意します。
Calvin： Claude Code にとって、IDE ではないことが実は重要だと思っています。IDE ではないことで、書かれているコードから距離を置けるのです。IDE はファイルを探索することがすべてですよね。すべての状態を頭の中に保持して、何が起きているかを理解しようとする。しかし CLI はまったく別のものなので、体験の自由度がはるかに大きくなります。皆さんもそう感じるかわかりませんが、自分は Claude Code を使っているとき、コードの中を飛んでいるような感覚になります。いろんなことが同時に起きていて、小さなプログレスインジケーターがあって、ステータスの更新をもらっているような感じで、書かれているコード自体が前面に出てくるわけではないんです。
Gary： 開発環境って本当にごちゃごちゃしていますよね。サンドボックスのコンセプトはすっきりしていて好きなんですが、実際にやってみると、単純なテストをしようとしただけでクレイジーな問題にぶつかりました。Postgres にアクセスする必要があるのにできないとか、codex.md が20行にもなってしまったのにそれでも動かないとか。CLI であれば開発データベースにそのままアクセスできます。こんなことをしていいのかわかりませんが、本番データベースにもアクセスさせたことがあります。そうすると「調べました。これが起きたと思います。この並行性の問題をデバッグします」とやってくれるんです。ネストした遅延ジョブを5階層深くまでデバッグして、バグを特定して、そのためのテストを書いて、二度と同じことが起きないようにしてくれました。これは正気の沙汰じゃないですよ。
4. ディストリビューションモデル：トップダウン vs ボトムアップ
Calvin： ディストリビューションモデルという観点は率直に言って過小評価されていると思います。Cursor でも Claude Code でも Codex の CLI でも、ダウンロードするだけで誰の許可も得ずにすぐ使えるという事実は、非常に大きな違いを生みます。実際、先日あるプロダクトを試していたのですが、デスクトップアプリをダウンロードすると、ラップトップ上で動いている Claude Code を exec して、MCP サーバー経由でそのデスクトップアプリと通信するんです。誰の許可も必要なく、ダウンロードしてすぐ使える。これはラップトップとの新しい働き方として非常に面白いと思います。
Gary： New Relic には MCP がありますし、Sentry ではマークダウンをコピーできて、実質的にオートバグフィクサーになっています。すぐそこにあるんです。変化がこれほど速い世界では、プロダクトにはトップダウンではなくボトムアップのディストリビューションが必要です。トップダウンは単純に遅すぎます。企業の CTO はセキュリティやプライバシーやコントロールについてあらゆる懸念を持つわけですが、エンジニアはただインストールして使い始めて「これすごい」となるわけです。
Calvin： その通りだと思います。ただ自分は基本的に B2B エンタープライズ畑の人間なので悩むところもあります。トップダウンの販売には一定のモートが生まれるという面もあるはずで、どこかの企業がそれをうまくやるはずです。個人が自由に使い始められるけれど、企業としてもそれを取り込める形です。元祖は Netscape Navigator ですよね。非商用利用は無料で、みんなが商用でもダウンロードして使い始めて、IP を追跡して各企業に何クライアントあるかを把握し、「ライセンスを買ってください。違反ですが、購入するだけでいいんです」と言えた。同じモデルがここでも使えるかは興味があります。
Gary： ディストリビューションという観点は本当に面白くて、今や人々は Claude Code の中で直接アーキテクチャの決定をしているわけです。どのアナリティクスを使うかすら知らないかもしれないのに、Claude Code が PostHog を使えと言えば PostHog を使う。
Calvin： 100%そうです。自分がアドバイスしている企業の1つが GEO 戦略について話していました。GEO とは Generative Engine Optimization、つまりチャットボットにどう表示されるかという最適化です。面白いことに、競合の1社が自分たちのカテゴリで使うべきツールのトップ5リストを作っていて、当然自分たちのツールが1位にランクされています。人間が見れば「これは明らかにバイアスがかかっている。トップのツールがそのドメインのものじゃないか」とわかりますが、LLM は騙されるんです。いろんなコンテキストをかき集めて「これがトップです」と推奨してしまう。開発者ツールを売るなら、良いドキュメントを公開し、ソーシャルプルーフを得て、Reddit にもう少し投稿するといったことが、ものすごく有利に働きます。
Gary： だからこそオープンソースプロジェクトがより一層伸びているのだと思います。その好例が Supabase です。昨年本当に大きく成長しましたが、その一因は、セットアップ方法についての優れたオープンソースドキュメントがあることです。バックエンドで Firebase 的な処理を必要とするセットアップ方法を誰かが尋ねると、すべての LLM からのデフォルト回答が実は Supabase なんです。試してみましたが、まさにそうなっています。Supabase はインターネットを制している。かつて Stack Overflow で検索して Google を使っていた時代と同じ構図で、今やみんな Google を使わなくなった中でも、同じダイナミクスが働いています。
5. オープンソースの優位性とコーディングエージェント構築の教訓
Calvin： このディストリビューションの話はオープンソースに不釣り合いなほど有利に働いていると思います。皆さん見たかわかりませんが、Ramp が自社のコーディングエージェント構築についてブログ記事を公開していて、ハーネスとして Open Code を使っていると書いていました。モデルがソースコードを直接見て、どう動いているかを理解できるからです。自分もオープンソースのプロダクトでは常にこれをやっています。リポジトリをクローンして、Codex や Claude Code を立ち上げて「ここで何が起きているかウォークスルーしてくれ」と頼む。非常に有用です。
Gary： コーディングエージェントを作りたい人へのヒントとしては、Calvin は何度もやっているわけですが、どんな教訓がありますか。
Calvin： 一番重要なのはコンテキストをうまく管理することです。私たちは O3 のような推論モデルのチェックポイントを取って、その上で大量のファインチューニングと強化学習を行いました。コーディング問題を解く、テストを修正する、機能を実装するといった質問が与えられ、モデルはそれに応答するよう RL で訓練されます。ほとんどの人はそこまではやらないでしょうが、できることは「最良の結果を得るためにこのエージェントにどんなコンテキストを供給すべきか」を考えることです。Claude Code の動作を観察すると、探索用のサブエージェントを複数スポーンして、ファイルシステム内の異なるパターンを検索し、戻ってきてコンテキストを要約し、次に進むべき場所を示してくれます。異なるエージェントがこのコンテキストをどう構造化するかを見るのは面白いです。Cursor はセマンティック検索のアプローチを取っていて、すべてを埋め込みベクトルにして最も近いクエリを見つけます。一方、Codex や Claude Code は実は grep を使っています。
Gary： それがうまくいくのは——
Calvin： ええ、非常にうまくいきます。なぜならコードは文脈密度が極めて高いからです。コードの各行はおそらく80文字未満で、コードベースに巨大なデータブロブや JSON がたくさんあるわけではありません。多少はあるかもしれませんが、大量ではない。.gitignore を参照して関連のないものやパッケージされたものをフィルタリングできますし、grep や ripgrep を使ってコード周辺のコンテキストを見つければ、そのコードが何をしているかの良い感触が得られます。フォルダ構造もナビゲートできます。
Gary： それにモデルは、人間だったら苦痛になるような非常に複雑な grep 式を生成するのが上手いですよね。
Calvin： そうです。まさにこれが RL の実践です。こうしたことすべてを踏まえると、コーディング以外の作業にエージェントを統合するシステムを構築しようとしている自分のような立場でも、多くの教訓を学べます。つまり「モデルがコードのように周辺を覗いて正しい構造化データを取得できるような、コードに最も近い形式にデータを整えるにはどうすればいいか」を考えるということです。
6. コーディングエージェントのトップ1%ユーザーになるためのヒント
Gary： 最高のコーディングエージェントの超能力がコンテキストエンジニアリングだとすると、コーディングエージェントのトップ1%ユーザーになるためのヒントは何でしょうか。何をすればそこまで生産的になれるのですか。
Calvin： まず1つ目は、使うコードとプラミングをできるだけ少なくすることです。自分がやっているのは、Vercel や Next.js、Cloudflare Workers のようなスタックにデプロイすることで、ボイラープレートがすでに用意されていて、さまざまなサービスを立ち上げたりサービスディスカバリーを扱ったり中央エンドポイントへの登録やデータベース管理を考える必要がありません。すべてがだいたい100〜200行のコードで定義されている。マイクロサービスや構造がしっかりした個別パッケージの方向に寄せる傾向があります。
LLM の超能力が何かを知ることも重要です。Andrej Karpathy がちょうどツイートしていましたが、コーディングエージェントは超粘り強くて、何があっても止まりません。そして基本的に、そこにあるものをさらに作る傾向があります。少し OpenAI の例で説明すると、OpenAI には巨大なモノレポがあって、数年間にわたり何千人ものエンジニアがコミットしています。その中には Meta から来たスーパーシニアでプロダクションコードの書き方を熟知した人もいれば、新しい PhD もいる。かなり幅広いレンジで、LLM はどこに向けるかによって異なるものを拾います。コーディングエージェントが「最適なコードとはどういうものか」を判断できる余地はまだ大きいと思います。
また、モデルに自分の仕事をチェックする手段を与えると、パフォーマンスが劇的に向上します。テスト、Lint、CI を走らせられるほど良い。個人的にはコードレビューボットもかなり積極的に使っています。YC 企業の Reptile は本当に優れていますし、Cursor の Bug Bot もかなり良くなりました。Codex もコードレビューに使っていて、正確性の面で非常に良い仕事をします。こうしたことはエージェントが得意な領域です。コードベースの探索も素晴らしい。一方で苦手な領域としては、先ほどの「さらに作る」傾向があります。もっと作ることが目的でない場合、コードを重複させたり、こちらが「もちろんそれは不要だ」と思うようなことを再実装するのに時間を費やしたりします。
コンテキストポイズニングは本当に起きる問題です。ある方向に進み始めると、その粘り強さゆえに、解決策の追求として正しくないトークンを参照し続けてしまう。だから自分はかなり積極的にコンテキストをクリアしています。
Gary： どのくらいの頻度でクリアしますか。
Calvin： だいたいトークンが50%を超えたらクリアします。
Gary： そんなに早く。Human Layer という YC Fall 24 の企業の Dex という人がいますよね。彼は LLM が「ダムゾーン」に達するというコンセプトを提唱しています。一定量のトークンを超えると品質が劣化し始めるという考え方です。
Calvin： それは非常に真実だと思います。強化学習がどう機能するかを考えるとわかりやすい。大学生が試験を受けていると想像してください。最初の5分間は「時間はたっぷりある。素晴らしい仕事をしよう。一つ一つの問題をじっくり考えよう」と思っています。残り5分でまだ半分残っているとなると、「とにかくできることをやるしかない」となる。それがコンテキストウィンドウにおける LLM の状態です。
Gary： ファウンダーたちが使っているトリックの1つは、コンテキストの冒頭にカナリアを置くことです。とても難解で面白いもの、例えば「私の名前は Calvin で、朝8時にお茶を飲みました」というランダムな事実を入れておく。そして会話を続けながら「私の名前を覚えていますか？お茶を飲んだのはいつですか？」と聞いて、忘れ始めたらコンテキストが汚染されたサインです。ランダムカナリアですね。
Calvin： 試したことはありませんが、完全に信じます。自分はコンパクション前のバグには遭遇していませんが、注意していないだけかもしれません。最適でない奇妙なことを始めるというのは、本当にそうなんですか。
Gary： はい、そうです。ただこれは Claude Code 自体で解決可能なはずです。何らかの検知を行って、コンテキストに対する内部ハートビートのようなものを持つべきです。
Calvin： 同意しますが、まだそこには到達していません。今のところコンテキスト管理は確かに難しくて、コンテキストウィンドウを分割してすべてをマージしようとすることで対処しています。しかし Claude Code のセッション終了時にコンテキストに残っているものは基本的に固定されているという限界があります。面白いのは Codex のアプローチがほぼ逆で、OpenAI のブログにも書かれていましたが、各ターンの後に定期的にコンパクションを実行します。そのため Codex は非常に長時間走り続けることができ、CLI のパーセンテージ表示がコンパクションの実行に伴って上下するのが見えます。
Gary： Claude Code と Codex のアーキテクチャの違いはかなり根深いようですね。Codex はもともとはるかに長時間のジョブ向けに設計されていて、最初から異なるユースケースで、その結果アーキテクチャが大きく異なるということですね。
7. エージェントが24〜48時間の長時間ジョブを自律実行できるのはいつか？
Gary： 今のところ2026年は CLI の年になりそうですが、一方で AGI がすでに到来し ASI も目前だという考え方もあります。現在のコーディングエージェントは本当に賢いですが、長時間にわたって自律的に動き続けるにはまだ賢さが足りない。ここから計算能力が10倍になったら、24時間や48時間のジョブを自律実行できるところに到達するのでしょうか。そして Codex のアーキテクチャはまさにその世界のために正しいのでしょうか。
Calvin： 良い質問ですね。これは両社の創業 DNA に遡る話だと思います。Anthropic はずっと「人間のためのツールを作る」ことに非常に力を入れてきました。トーンのスタイルや、他の仕事全体にどうフィットするかといった点です。Claude Code はその自然な延長線上にあります。多くの点で人間が働くように動きます。例えば犬小屋を作る必要があるとすると、ホームセンターに行って材料を全部集めて、どう組み合わせるかを考える、という感じです。一方 OpenAI は、最高のモデルを訓練し、時間をかけて強化学習を重ね、より長い時間軸のタスクをこなせるようにするという、AGI の追求に大きく傾倒しています。だからまったく人間的でないやり方になるかもしれない。犬小屋の例に戻ると——
Gary： AlphaGo もそうでしたよね。
Calvin： まさに AlphaGo も人間的ではなかった。犬小屋を一から3Dプリントできるプリンターを持っているようなもので、まさに望み通りのものができて、時間はかかるし、非常にカスタムで、奇妙なことをするけれど、ちゃんと動く。究極的にはそちらが正しいアプローチなのかもしれません。だからこの2つがどう展開していくかは本当に面白いと思います。差し引きすると後者の方がある程度不可避に見えますが、自分は前者がとても好きなんです。10年前に自分がリファクタリングやコードの理解のために奇妙な正規表現を手で書いていた感覚、あれが Claude Code を使っているときに蘇るんです。1日で5人分の仕事ができるような感じです。ロケットブースターですよ。信じられないくらいです。
Calvin： 大企業と小さな企業でこれがどう展開するかは非常に興味深いと思います。趣味レベルやごく小さなスタートアップでこの技術を試している人たちは、コーディングエージェントを限界まで使い倒しています。他のことを考えている時間がないんです。スタートアップはランウェイが限られているので、ひたすらスピードに最適化する。大企業ではもっと失うものがあって、コードレビューの社内プロセスがあり、大きなエンジニアリングチームをすでに雇っている。1人チームの個人が「あっちのチームは正しいことをやっていない、自分がもっとうまくいくプロトタイプを作ってやろう」と言い出すような状況は、非常に奇妙なことになると思います。ある時点でそれが実際にうまく機能し始めるでしょうし、その地殻変動は非常に興味深いものになるはずです。
Gary： 自分の10歳の息子は毎日ライティングの課題があるのですが、昨日初めて AI を使ったんです。そうしたら「これは10歳ができる言い回しではないだろう」という文章が出てきました。このことをここでの文脈で考えてしまうのは、私たちが多くの18〜22歳と一緒に働いているからです。彼らはインターンの経験はあっても、私たちが言うような本当のマネージャー的仕事——プロダクトマーケットフィット後の、何百万件のジョブキューと何十万件のエラーを抱えた状態——はやったことがない。それが本当のマネジメントです。何十万件ものエラーを地道にくまなく調べて、すべてのユーザーのためにバックグラウンドで正しく動いていることを手動で確認するという、ひどく華やかさのない仕事です。次の世代はそれをどう理解するのでしょうか。Claude Code のボットは実際にアーキテクチャなどを人に教えられるのか、それとも結局壁にぶつかって、ユーザーが苦しんで、自分で何とかするしかないのか。
8. エージェントはアーキテクチャを教えられるか？次世代エンジニアへの影響
Calvin： 少なくとも自分がプロダクトに関して最も時間を費やしているのは、いわばプロダクトモデルを見極めることです。ユーザーが今日理解しなければならないものは何か、そしてユーザーがやりたいことを何でもできるためのプリミティブは何か。いつも Slack を例に考えます。Slack はある意味ではまったく新しいコンセプトではありませんでした。それ以前にもたくさんのチャットが存在していた。しかしチャンネル、メッセージ、リアクションというシンプルな構造を持っていて、人々がすぐに「これの使い方がわかる」と思えた。それが非常に理にかなっていました。ところが一度そこに定着してしまうと、ユーザーのメンタルモデルを後から変えるのは非常に難しい。ドキュメントファースト方向に行きたかったかもしれないし、今はエージェントを組み込もうとしているかもしれないけれど、ユーザーのメンタルモデルを変えるのは困難です。だから自分がプロダクトを作るときは、初期段階からこれを非常に慎重に考える必要があります。コーディングエージェントにカーネルとして供給したものが、そのまま彼らが走り続けて永遠に増やし続けるものになるからです。
Gary： エージェントをよく知っている立場から、どんなタイプのエンジニアがこれらのツールからより恩恵を受けると思いますか。
Calvin： 一般的に、シニアであればあるほど恩恵が大きいと思います。エージェントは何かのアイデアを受け取ってそれを実行に移すのが非常に得意だからです。数語でプロンプトを書けるなら、突然そのアイデアが形になる。OpenAI でコードベースをスクロールしていると本当によくありました。「ここが違えばいいのに」「これも変えたい」「あれも変えたい」と。それをただ投げて、戻ってくるのを待てばいい。これは非常にエンパワリングで、インパクトを何倍にも増幅します。また、どの変更がアーキテクチャ的に良いか悪いかを見極められること、エージェントに何をフラグすべきかの感覚を持っていることも非常に重要です。
より整理上手でマネージャー的なエンジニアが有利で、ここにはまだ作られていないプロダクトがあると思います。例えば Conductor のようなもので、すべてのセッションにまたがって「この作業が終わりました、ここであなたの判断が必要です」「こちらに注意を切り替えてください」と教えてくれるようなものです。
Gary： Conductor がその機能を追加すべきですね。
Calvin： ええ、エージェントのためのコンテキスト管理はもちろんですが、人間のためのコンテキスト管理も必要です。
Gary： 100%同意します。毎朝起きたときに「昨夜完了した作業はこれです。あなたが下す必要がある判断が3つあります。深い思考を予定していた領域はこれです」と、一日のターンバイターン案内が欲しい。
Calvin： アイデアのクイックプロトタイプを作って見せられるというのも、もちろんエージェントが非常に得意な領域です。OpenAI にいた頃、自分はよくプロトタイプコードを書いていました。「インメモリのキーバリューストアがあるんだけど、これをプロダクションデータベースで動くようにしてくれ」というようなことです。アイデアをコードで簡潔に指定できる能力、そして正しいアーキテクチャに対する嗅覚を持つこと——これはまだモデルがあまり得意でない領域です。
Gary： もし大学時代に戻って CS を一から学び直すとしたら、自分でシラバスを組むなら何を学びますか。
Calvin： 個人的には、システムを理解することが依然として非常に重要だと思います。Git がどう動くか、HTTP とは何か、データベース、キューといったさまざまなシステムについてある程度の理解を持つこと。これらの基礎は今でもかなり重要です。もう1つやるとしたら、1学期をかけて毎週何かを作り、モデルを限界まで使い倒す期間を設けるでしょう。何かをしているとき、常に「もう1レイヤー上に行ってモデルに任せられる」「さらにもう1レイヤー上に行ける」という感覚があります。次のフェーズを実装する implement コマンドがあって、さらに全部を段階的に実行して新しいサブエージェントを作る implement all コマンドがあって、さらに作業をチェックする仕組みもある。モデルがどこまでできてどこからできないかの境界は常に動いているので、とにかくたくさんいじって試すことに価値があります。
もう1つ本当にすごいと思うのは、18〜22歳に教えたいということです。このテーブルにいる全員が、人々が本当に欲しがって愛するものを出荷してきた。それをどうやって人に教えるのか。
9. 次世代のセンスとマルチタスク能力、そして未来像
Gary： 5年後の最も優秀な18〜22歳は、あらゆる面で桁外れのテイストを持つようになるのではないでしょうか。はるかに多産になれるはずですから。前の世代と比べて10倍も多く現実に触れ、ローンチし続けているはずですよね。
Calvin： その点で1つ考えていたことがあります。皆さんもそうかわかりませんが、子供の頃、母に「マルチタスクをやめなさい、ちゃんと見ていないでしょう」とよく言われました。確かにそれは一理あって、自分はよくコンピュータに向かって注意を払っていなかった。でも自分は親の世代よりもマルチタスクが本当に上手かったと思います。そして今の新しい世代を見ると、私たちよりもかなりマルチタスクが上手いと思うんです。インターネットの時代に育って、TikTok やさまざまなショートフォーム動画を扱っているからです。じっくり観察して理解して問題を解くようなディープシンキングのモードと、たくさんの異なることの間を飛び回って常にコンテキストスイッチしているモードの、両方に余地があるように見えます。
Gary： ADHD モードですね。
Calvin： ええ、新しい世代はこれがかなり上手です。
Gary： 間違いなく、ある種の賢い人——ADHD かもしれませんが——常に良いプロジェクトをたくさん抱えているのに、何一つ最後まで終わらせないタイプがいますよね。自分もちょっとこの性格に心当たりがあります。
Calvin： 自分のバイブコードをリリースしましたよね。
Gary： ええ、でもそれは Claude Code があったからこそです。ある種の脳は頭の中に常に10本のブランチが走っているけれど、どれも最後まで見届ける時間が一日の中に足りない。だからいつも半完成の状態です。それが今は Claude Code がすべてをゴールラインまで連れて行ってくれる。Calvin がブログ記事で「ビデオゲームのような感覚だ」と書いていましたが、まさに常に新鮮さがあるんです。何かに取り組んでいて、普通なら「飽きてきた、こっちの方がいいアイデアだ、そっちを始めてからまた戻ろう」となるポイントに達する。今はそれが実際にできて、しかもすべてが本当に完成するんです。
Gary： 少し未来に住んでみましょう。40年後です。ソフトウェアはまだ存在する。データベースもアクセスコントロールも存在する。でもその核心では、ソフトウェアは完全にパーソナルなものになっている。アクセスコントロールや誰がそれをやるかは、まだ人々がミーティングで話し合うマネージャーモード的なものですが、企業のそれ以外のすべて——機能もルールも——は、人々がそれぞれの Claude Code 的なツールで自分で定義している。CLI かもしれないし、巨大なワーカー軍団を持つ形かもしれない。それはどんな姿になるでしょうか。例えば企業が Segment にサインアップするたびにコードベースをフォークして、自社サーバーで動く Segment のコピーを渡す。何か変えたければチャットウィンドウに伝えるだけで、エージェントのコーディングループが自社版の Segment を編集する。Segment という企業が新機能を出したら、何かのエージェントがマージ方法を見つけ出す。
Calvin： 完全にあり得ると思います。自分が考えてきたのは——この未来がどのくらい先かはわかりませんが——最終的にはすべての働く人が自分専用のクラウドコンピュータとクラウドエージェント群を持つようになるということです。ほとんどの時間はただやり取りしているだけ。スーパー EA（エグゼクティブアシスタント）を持っているようなもので、「注意を払うべきことはこれ。素早く判断しよう。これにはもっと時間をかけよう。他の人と会おう」という感じです。人と会ってアイデアを交換したいという人の居場所はまだあると思いますし、少なくとも自分はそこに大きな充実感を感じています。そして別途、自分のために物事を実行し自動化してくれるエージェントの軍団がいる。平均的な企業はおそらく少し小さくなり、より多くの企業がより多くのことをやるようになるでしょう。
10. メーカースケジュール vs マネージャースケジュール
Gary： 興味があるのは、Paul Graham のメーカースケジュール vs マネージャースケジュールの現代版アップデートがどうなるかということです。YC で起きていることの一部は、私たちの仕事の多くが本質的にマネージャースケジュールで、それが自分でソフトウェアを作ることを本当に難しくしていたということです。でも今は完全にできるようになった。だからパートナーの何人かは——
Calvin： ミーティング中にやればいいんです。まさにこのポッドキャストの冒頭みたいに。走らせておいて、後で戻ってくればいい。
Gary： そう、隙間時間でやるんです。以前は文字通り、何かをやるのに最低4時間の空きブロックがなければ、始める価値すらなかった。これはプログラミングをどう変えたかという点で非常に深い話だと思います。以前はコードを書くために、すべてのクラス名、関数、それが触れるコードについて、自分の頭のコンテキストウィンドウに膨大なデータを詰め込む必要がありました。そのコンテキストウィンドウを構築するのに何時間もかかっていた。だから10分の細切れ時間でやるのは本当にフラストレーションが溜まるだけでした。
この未来の世界のプリミティブの1つとして、データモデルは依然として一貫性が必要で、システムオブレコードが残ると思います。エージェンティックファーストな何かにはチャンスがあります。今はまだデータベースや SQL、NoSQL のクエリと非常にローレベルに統合されていますが、カスタムソフトウェアのさまざまなビューに必要なデータをすべて生成するようなものを想像してみてください。世界の多くはカスタムビューになるでしょう。ただ、統一されたデータは正確である必要があるという部分は変わりません。
Calvin： データには大きな重力があると思います。API や MCP でアクセスを提供している企業を見るとわかります。Slack は API を少し制限しましたよね。人々が Slack からすべてを抜き出してその上にエージェンティックな体験を構築するのを望まなかったからです。
11. Calvin が今 Segment を作り直すなら？
Gary： その話を踏まえて、もし今のツールで Segment を作り直すとしたら、どんな形になりますか。
Calvin： Segment は面白いビジネスで、出発点はインテグレーションを構築することでした。同じデータを Mixpanel、Kissmetrics、Google Analytics などに配線する必要があるという問題です。そのコードを書くことは以前はもっと面倒で難しかったから、お金を払う価値がありました。今やその価値はゼロに落ちています。
Gary： ええ、実際には多くの場合、「このようにマッピングしたい、この特定の動作が欲しい」と Claude や Codex に伝えれば、その通りにやってくれて、まさに自分が望む動作が手に入るので、そちらの方がむしろ良いくらいです。
Calvin： そうですね、Segment のそのインテグレーション面の価値は急落しました。一方で、データパイプラインを安定的に稼働させ続けること、ビジネスの各部分を自動化し続けること、例えば顧客がサインアップするたびに Customer.io 経由で配信されるべきメールをスケジュールすること、オーディエンスを管理すること——こうした価値はまだ残っています。さらにもっと面白いことができるはずで、すべてのデータと顧客の全体像があるなら、どうメールすべきか、ログイン時にプロダクトの一部を変えるべきか、相手によって異なるオンボーディングを提供すべきか、といったことです。小さな LLM エージェントをデータに対して走らせて動的に変えていく。それが自分がやるであろう変更です。
Gary： つまり先ほどの話のように、スタックの上位へ移動するということですね。ローレベルの配線はすべてなくなり、キャンペーンレベルのはるかに抽象的なことをやるようになる。Claude Code がリポジトリのコンテキストだけから自分の動機を推測してくるのには驚かされます。
Calvin： 自分もコーディングエージェントにはいまだに驚かされます。やっていることは本質的に、エージェントにリポジトリのコピーを渡して、ドアの下からメモを滑り込ませて「これを実装してくれ」と頼んでいるだけです。あなたの会社が何をしているか、顧客が誰かなんて、ほとんどの場合まったく知らない。トレーニングセットに入っていて Gary のことを知っているかもしれませんが。それがそもそも機能すること自体が驚きです。だからこそコンテキストが本当に重要で、正しくないものに飛びつくと、手がかりが少ないので間違った方向に進みますし、本質的なものを見落とせば、ただ再実装してしまいます。
Gary： 今の制約は何だと思いますか。コンテキストウィンドウはまだ制約ですが、かなり大きくなっているので、メガリアーキテクチャの再構築はできなくても、多くのことはできます。Opus 4.5 が大幅に賢くなって大きなアンロックがあったのも興味深かった。あれがプリトレーニングなのかポストトレーニングなのかはわかりませんが。フロンティアモデルの知能とコンテキストウィンドウ以外に、どんなレバーがあると思いますか。
Calvin： コンテキストウィンドウがおそらく依然として最大の制限だと思います。Claude Code の実行を見ると、さまざまなコンテキストウィンドウに委譲していて、各ウィンドウが戻ってくるときにはある種の要約を受け取っています。つまり全体像を得ているわけではない。1つのウィンドウに収まらないほど大きな問題があれば、どれだけコンパクションしても助けにならない。Anthropic がサブコンテキストウィンドウへの委譲で非常に有用な何かを見出したのは確かですが、それでもなおブロッカーだと思います。
Gary： つまり毎回100万トークンのコンテキストがあれば、もっとうまくいくということですか。
Calvin： はい、そう思います。そして特に非常に長いコンテキストの軌道を訓練するより良い方法を見つける必要があります。インターネット上には「次の文は何か」「次の段落は何か」というトレーニングデータは大量にあります。しかし8万トークンが生成された状態で、「2万トークン目を参照すべきだ」と判断して次に何をするかを理解する——これはもっと難しい問題です。
この統合とオーケストレーションが制限要因になり始めていると思います。コードレビューに関連する話もあって、こうしたコードを全部マージしているとき、誰が見ているのか。人間がまだ見なければならないのか。変更をどう検証するのか。そしてツールからコンテキストを正しく取り込むこと——先ほどの Sentry の話のように、Sentry が自動的に PR を生成して、トラフィックの一部にプッシュして、問題なければ全体にロールアウトする。そうした自動化はまだ構築されていません。
12. テストの重要性とエージェントメモリ
Gary： テストがどれほど重要かには驚きました。9日間の荒野生活の最初の2〜3日は、テストなし、あるいはほとんどテストなしで運用していました。そしてある日、「よし、今日はリファクタリングの日だ。テストカバレッジを100%にしよう」と決めたんです。そうしたら劇的にスピードアップしました。「できた、動く」の連続で、手動テストをする必要がほとんどなくなりました。テストカバレッジが非常に高いので何も壊れないんです。
Calvin： これはコーディング以外のプロンプトエンジニアリングで企業がやっていることと非常に似ていますね。まさにテスト駆動開発です。Jake Heller とのエピソードでも話しましたが、良いプロンプトを得る方法はすべてテスト駆動で、テストケースが Evals に相当するという大きなパラダイムシフトでした。
Gary： 今いくつか壊れたフローがあって、Claude Code 用の Stack Overflow のようなもの——Claude Code 版 Stack Overflow——が必要かもしれないと思っています。こんなことがありました。ジョブキューの優先度の設定で、自分が書いたのではなく機械が書いたのですが、カンマ区切りの文字列を書いたんです。そのシンタックスで受け付けると思って。ところが実際には JSON の配列を期待していて、ジョブがまったく動かなくなった。そこから30分間、Rails のジョブ内部——Active Job の数千行のコード——をウォークスルーしてデバッグしていくのを見守りました。そして実際にバグを見つけたんです。これはすごいと思いました。10年前の自分だったら「なぜジョブが動かないんだ」と言って Stack Overflow か Rails のブログ記事を探して、「ああ、カンマ区切り文字列を入れられると思うけど実は配列にしないといけないという、あの誰も直さなかった馬鹿げたバグか」となっていたはずです。
Calvin： なるほど。
Gary： 本当に面白かったです。ここで何が起きるかを考える上で最も難しい部分の1つだと思います。人間が CLI でやることは今は明白ですが、エージェント専用の Stack Overflow が必要かという問題もある。仮に知能を10 IQ ポイント——10バーチャル IQ ポイントとでも言いましょうか——上げたら、そもそもそんなことをするでしょうか。「ああ、それは文字列だね」で終わりかもしれない。
Calvin： ええ、そうでしょうね。ここでエージェントメモリについて非常に面白い話があると思います。Claude Code は、Codex もそうだと思いますが、すべての会話履歴をファイルとして保存するようになっています。だから過去の会話履歴を読めるツールへのアクセスを与えるということが想像できます。ただ、コラボレーションの面で欠けているピースが多いと思います。同僚のプロンプトを賢く共有する方法があったら素晴らしいですよね。「自分はこの問題にぶつかったけど、実はあっちの Brian が先に解決していた」とわかって、二人で知識を共有できるような仕組みです。
Gary： モデルが生成する Wiki のようなもの、Graphopedia のようなものには何かあると思います。
13. Claude Bot たちが会話している！ ＆ 複雑な問題の事例とツールの進化
Gary： もう頭から離れないんですが、Claudebot Social を見ましたか。Claude ボット同士が会話するソーシャルネットワークで、これがまさにさっきの話の進化形ですよね。
Calvin： ええ。Claudebot は基本的に自分のマシンで動かせる個人用 AI エージェントで、ダウンロードして使えます。自分の一番のアドバイスは、メールへのアクセスは絶対に与えないこと、おそらく他のものもです。どれだけ安全かが明確ではなく、今この瞬間にもかなり多くの人がプロンプトインジェクションを受けている可能性がほぼ確実にあります。ただ、誰かがサイトを作って——自分は実際には見ていなくて Twitter で見かけただけですが——みんなが自分専用の Claudebot パーソナルエージェントを立ち上げて、エージェント同士が会話できるようにしたんです。今やパーソナル AI エージェント同士が会話している AI 生成コンテンツが大量にあります。
Gary： Reddit みたいに見えますが、Reddit がエージェントによって運営されている感じです。Codex がコードを書くときに個性が出てくるのも面白い。人間がやらないことをほとんどやるんです。AlphaGo 的な感覚で、ファイルシステムの一部を変更するために Python スクリプトを書いたりする。これは非常に面白くて、学習されたエイリアン的な行動です。
Calvin： ただ、複雑な問題のデバッグでは、少なくとも自分にとっては超人的な結果をもたらします。Opus がよく見落とすような問題でもです。
Gary： 具体的にどんな複雑な問題ですか。並行性や命名の問題ですか。
Calvin： モデルは実は並行性はそこそこ得意です。よくあるのは、リクエストが複数の異なるサービスをまたいでトラバースしているような場合です。先ほどのカンマを含むデータのシリアライゼーションとデシリアライゼーションの話にも通じますが、そうした複雑な振る舞いを追跡する必要があったり、複雑な UI ステートのリフレッシュの仕方だったり。ファイルが多い場合に Opus はよく見落としますが、Codex はキャッチするんです。
Gary： 面白いですね。ツールが今後どう進化するかという予測について、自分はこの領域の新しい市民のような気分です。起きていることは知っていて、マネージャースケジュールの中でようやくプロジェクトが現れて「これに全力投球しよう」と。今はまさにその中にいて、見知らぬ土地にいる異邦人のようですが、かつて覚えていたものとそっくりなんです。
Calvin： みんなそう感じていると思います。最も重要なのはとにかくいじり続けることです。すべてが数ヶ月ごとに変わるので。将来コーディングエージェントから最大の恩恵を得る人たちは、よりマネージャー的になると思います。フローを特定の方向に向けることに集中し、おそらくデザイナーやアーティスト的な面も持つようになる。プロダクトに何を入れて何を省くかを見極め、自動化の余地やコンテキストの欠落を常に考え続ける人です。
面白いことに、たった今自分の Rails プロジェクトで Codex を使おうとしたんですが、OpenAI で誰も Rails を気にしていないのが明らかなんです。それ自体は構いませんが、Rails は遺物的な言語で、たまたま自分が10年前に深く入り込んだだけですから。誰でも何かを作れるけれど、人々が欲しいものを作るのは非常に難しいということの再確認です。OpenAI のような無制限のリソースがあっても。Codex の人が見ているなら、お願いしたいのは、すべてのランタイムのリストを順に処理して、シンタクティックシュガーを追加してほしいということです。トップ15のランタイムに対して、おそらく最大10個の PR でできるはずです。ユーザーにとってちゃんと動かないソフトウェアの言い訳が、今ほど少ない時代はないという思い出させてくれます。
Gary： トレーニングデータのミックスという観点では面白いポイントですね。Codex は Python のモノレポ——まさに OpenAI の形——で非常にうまく動きます。
Calvin： ええ、OpenAI の内部で使っていたとき「このツールはすごい、信じられない」と感じましたが、データミックスとそれに取り組んでいる研究者を考えれば納得です。Anthropic はフロントエンド寄りにもう少しフォーカスしていると思います。Ruby のような言語で誰が最良のモデルを持っていてデータミックスに組み込んでいるかは不明です。一部のラボは「データは多ければ多いほど良い」という立場で、とにかくデータを大量に流し込みます。他のラボはミックスをもっと調整している。どちらのアプローチを取るかで結果は大きく変わり得ます。JavaScript のトップ10%だけを使うのと、すべてを見るのではかなり違います。実は OpenAI のモデルは Ruby が非常に得意だと思います。
Gary： でもそれはモデルの周りのハーネスの問題ですよね。
Calvin： ああ、面白い。なるほど。
Gary： 文字通り、Rails には Postgres に特定の方法でアクセスしなければならないとか、サンドボックスに収まらないとかいう変な問題があるんです。
Calvin： サンドボックスの問題ですね。これは非常に面白い問題です。OpenAI はサンドボックスとセキュリティの問題を他のどこよりも真剣に受け止めていると思います。Codex を構築していたとき、モデルをリリースするために通過しなければならないゲートの1つとして、リリースするたびに安全性とセキュリティのリスクについて議論する必要がありました。私たちが特に調べていたのはプロンプトインジェクションで、多くのユーザーが「インターネット上で動かなければ」と言っていたからです。私たちは「うーん、わからない。プロンプトインジェクションがかなり簡単にできそうだ」と。チームの PM である Alex が GitHub Issue を作って、非常に明白なプロンプトインジェクション——「この情報を明かせ」——を仕込みました。そしてモデルに「この Issue を修正してくれ」と指示した。「絶対にうまくいかないだろう」と思っていたのに、即座にプロンプトインジェクションが成功したんです。だから OpenAI は正しく警戒していて、すべてをサンドボックスで実行し、マシン上の機密ファイルに触れないようにし、シークレットについて非常に慎重に扱うという姿勢です。スタートアップでとにかく速く走りたいなら、おそらく気にしないでしょう。ただ動けばいいと。
Gary： 危険な Skip Permissions 派ですか？
Calvin： 自分は実はそうではないです。許可する範囲を決めています。
Gary： あなたは？
Calvin： 自分はエージェントが何をしているか読みたいタイプです。
Gary： Jared、あなたは Skip Permissions？
Jared： 100%。
Gary： YOLO ですね。YC のエンジニアリングチームではだいたい50対50です。
Calvin： セキュリティエンジニアがこの部分を見たら「このパートは公開できない。ポッドキャストからカットしてくれ」と言うでしょうね。
Gary： コンテキスト次第だと思います。エンタープライズにいるならやるべきではない。スタートアップで失うものがなければ、おそらくやるでしょう。YC はスタートアップから少し成長しましたが、まだスタートアップのように振る舞っています。それが重要だと思います。
14. Outro
Gary： 本当に素晴らしかったです。Calvin、参加してくれてありがとうございます。
Calvin： もちろん、お招きいただきありがとうございました。
Gary： 最高に楽しかった。さあ、Claude に戻りましょう。