※本記事は、Y Combinatorが配信するポッドキャスト「The Light Cone」のエピソード「Inside Claude Code With Its Creator Boris Cherny」の内容を基に作成されています。動画は https://www.youtube.com/watch?v=PQU9o_5rHC4 でご覧いただけます。本エピソードでは、AI時代で最も革新的なコーディングツールの一つである Claude Code の生みの親、Boris Cherny氏をゲストに迎え、その開発の軌跡が語られています。本記事では、動画の内容を要約しております。なお、本記事の内容は原著作者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご視聴いただくことをお勧めいたします。
1. Claude Code の誕生——偶然と直感の3ヶ月
1.1 Boris の直感と3ヶ月間の没頭、そして2つの最大の驚き
Host： 今日は特別なゲストをお迎えしています。Claude Code のクリエイター兼エンジニアである Boris Cherny さんです。正直に言うと、ここ3週間まっすぐ眠れていません。Claude Code のせいです。
Host： 自分も完全に中毒になっています。ロケットブースターのような感覚です。皆さんにとって、この感覚はもう何ヶ月も前から続いているのでしょうか。2024年の11月末ぐらいに、周囲の友人たちが「何かが変わった」と口をそろえて言い始めたのを覚えています。
Boris： 自分の場合は、Claude Code を最初に作ったときにこの感覚がありました。何かを掴んでいるのかもしれないと感じていて、でもまだ確信はなかった。それで眠れなくなったんです。2024年9月のことです。そこから丸3ヶ月間、1日も休暇を取らず、週末も毎晩も働き続けました。「これはモノになる」と思っていましたが、当時のモデルはまだコードが書けなかったので、本当に便利なのかどうかすらわかりませんでした。
Host： あの頃から今を振り返って、最も驚いていることは何ですか。
Boris： 2つあります。1つ目は、いまだにターミナルを使っているということです。ターミナルは出発点にすぎないはずでした。まさか到達点になるとは思っていませんでした。2つ目は、Claude Code が実際にコーディングに使えるようになったことです。2月にGA（一般提供）したときでさえ、Claude Code が書いていたのは自分のコードの10%程度で、大半は手書きでした。コーディングに使うにはまだまだという状態でした。ですから、自分たちの賭け——つまり「モデルはこの分野で上達するだろう」という予測——が実際に報われたことは、まったく自明ではなかったのです。
1.2 「6ヶ月後のモデルのために作れ」という Anthropic の根本思想
Boris： Anthropic では、今日のモデルのためにプロダクトを作るのではなく、6ヶ月後のモデルのために作るという考え方をしています。これは LLM を使ってプロダクトを開発しているファウンダーへのアドバイスとしても、今でもまったく変わりません。モデルが今日まだ上手くできていないフロンティアは何かを見極めてください。なぜなら、モデルはそこが上手くなるからです。あとはただ待つだけです。
1.3 偶然から生まれた CLI——API 理解のための小さなチャットアプリから
Host： 最初のアイデアが生まれた瞬間を教えてください。ひらめきのようなものがあったのですか、それとも最初のバージョンはどんなものだったのですか。
Boris： おもしろいことに、すべてが極めて偶然に進化したんです。Anthropic にとって、コーディングは長い間ずっと大きな賭けでした。安全な AGI への道はコーディングを通じてつながるというのが基本的な発想で、モデルにコーディングを教え、次にツールの使い方を教え、そしてコンピュータの操作を教えるという順序です。自分が最初に所属した Anthropic Labs チームがまさにこの流れに沿った3つのプロダクトを生みました。Claude Code、MCP、そしてデスクトップアプリです。これらがどう結びついているか、おわかりいただけると思います。
Boris： ただし、CLI を作れと誰かに言われたわけではありません。コーディング系のプロダクトを作る時期かもしれないとは漠然と感じていましたが、具体的に何を作るかは誰も高い確信を持っていませんでした。チームは完全に探索モードで、何を作るか決めるのが自分の仕事でした。それで手を動かし始めたとき、まず考えたのは「APIの使い方を理解しなければ」ということでした。当時、自分は Anthropic の API を使ったことがなかったんです。そこで、ただ API を叩けるターミナルの小さなアプリを作りました。それだけです。当時の AI アプリといえばチャットアプリでしたから、同じようにターミナルで質問して回答が返ってくるだけのものです。
Host： ターミナルにしたのは、単にそれが一番手っ取り早かったからですか。
Boris： はい、UI を作らなくて済むからです。
Host： 当時は Cursor や Windsurf などの IDE が急成長していた時期でした。IDE プラグインやフル機能の IDE として作るべきだというプレッシャーや提案はありましたか。
Boris： プレッシャーはまったくありませんでした。そもそも何を作りたいかすらわかっていなかったので。コーディングの領域で何かをやりたいとはぼんやり思っていましたが、具体的に何を作るべきかについて十分な確信を持っている人はチームに一人もいなかったのです。
1.4 最初のツール付与と「AGI を感じた瞬間」
Boris： 最初にモデルに与えたのは Bash ツールでした。理由は単純で、ドキュメントのサンプルがまさにそれだったからです。サンプルは Python で書かれていたので、自分が使っている TypeScript に移植しただけです。モデルが Bash で何ができるかわからなかったので、まずファイルを読ませてみました。cat でファイルを読めた。それはそれでクールでした。
Boris： 次に「自分が今どんな音楽を聴いているか教えて」と聞いてみました。すると、モデルが AppleScript を書いて、自分の Mac をスクリプト操作し、音楽プレーヤーから再生中の楽曲を調べたんです。これが Sonnet 3.5 でした。モデルにそんなことができるとは思っていませんでした。これが自分にとって、おそらく初めての「AGI を感じた瞬間」です。「モデルはただツールを使いたがっている。それだけなんだ」と思いました。
Host： それは本当に魅力的な話です。Claude Code がこんなにエレガントでシンプルなフォームファクターで機能しているというのは、かなりコントラリアン（逆張り的）ですよね。
Boris： そうなんです。そしてこの当時、信じられないほど強い「プロダクト・オーバーハング」の感覚がありました。モデルの能力を活かしたプロダクトを、まだ誰も作っていなかったのです。今でもそのオーバーハングは残っていますが、当時はさらに途方もないものでした。
2. ターミナルの偶然の力——初期普及とユースケースの発見
2.1 ターミナルという形式が偶然もたらしたデザイン制約の恩恵
Host： ターミナルという形式で Claude Code がこれほどうまく機能しているのは、かなり逆張り的ですよね。ターミナルは大昔からあるものですが、それが優れたデザイン制約として働いて、興味深い開発者体験を生んでいるように見えます。仕事をしている感じがしないんです。開発者としてただ楽しい。ファイルがどこにあるかも考えない。そしてそれが偶然に生まれたというのが驚きです。
Boris： はい、まさに偶然でした。
2.2 社内での爆発的な初期普及——誰も強制していない垂直成長
Boris： ターミナル版が社内で広がり始めたあとの話ですが、最初のプロトタイプを作ってからたった2日後に、ドッグフーディングのためにチームに渡しました。何かを思いついて便利そうだと感じたら、まず人に渡して実際にどう使うかを見たいじゃないですか。翌日オフィスに行ったら、向かいの席のエンジニアの Robert がすでに Claude Code を自分のマシンに入れて、コーディングに使っていたんです。「何やってるの、これまだプロトタイプだよ」と言ったんですが、あのフォームファクターの時点ですでに使い物になっていたということです。
Boris： 外部向けローンチのレビューのときの話も覚えています。2024年の11月か12月頃のことですが、Dario が社内の利用チャートを見て聞いてきました。「このチャート、垂直に上がっているけど、エンジニアに使うよう強制しているのか。なぜ義務化しているんだ」と。自分は「いいえ、強制なんてしていません。社内に投稿しただけで、みんなが口コミで広めたんです」と答えました。正直、すべてが偶然です。CLI から始めたのは最も安価な選択肢だったからで、そのまましばらく居座っただけです。
2.3 最初のユースケースと Claude MD の誕生
Host： 2024年の当時、エンジニアたちは Claude Code をどう使っていたのですか。すでにコードを出荷していたのですか、それとも別の使い方をしていたのですか。
Boris： 当時のモデルはまだコーディングがあまり上手ではありませんでした。自分個人は Git の自動化に使っていました。おそらく今では、Git コマンドの大半を忘れてしまっていると思います。Claude Code がずっとやってくれているので。それ以外にも、Bash コマンドの自動化や Kubernetes の操作といった用途がごく初期のユースケースでした。
Boris： コーディングに使う人もいました。その兆しはありました。最初のコーディング用途はおそらくユニットテストの作成です。リスクが比較的低いからです。モデルはまだかなり下手でしたが、人々は使い方を模索し始めていました。このツールをどう使うか、みんなで手探りしていたんです。
Boris： そして自分たちが観察したのは、ユーザーが自発的に Markdown ファイルを書き始めたことです。自分用の指示書のようなものを Markdown で作成し、モデルにそれを読ませていました。これが Claude MD の出発点です。自分にとってプロダクトにおける最大の原則は「潜在的需要（Latent Demand）」です。初期の CLI 以降、このプロダクトのあらゆる機能は潜在的需要を通じて構築されています。Claude MD はまさにその典型例です。
2.4 スキャフォールディング vs モデル進化のジレンマ
Boris： もう一つ興味深い原則があります。モデルの周囲にスキャフォールディング——つまりモデルの性能を補助するコード——を構築すれば、領域によっては性能を10%から20%ほど改善できます。しかし、次のモデルが出た瞬間にその改善効果は本質的に消えてしまいます。つまり、スキャフォールディングを作って少し性能を上げてからまた作り直すか、それとも次のモデルを待ってタダで同じ改善を得るか、という選択肢があるわけです。
Boris： Claude MD やスキャフォールディング全般がその一例であり、自分たちが CLI にとどまり続けた理由もまさにここにあります。6ヶ月後にもまだ有効であるような UI を構築できるとは思えなかったのです。モデルの改善速度があまりに速すぎたからです。
3. CLAUDE.md の設計哲学と開発ツール観
3.1 Boris 個人の Claude MD：たった2行
Host： 先ほど Claude MD を比較しようという話になりましたが、Boris さんの Claude MD は実はとても短いという、多くの人の予想に反することをおっしゃっていました。中身を教えてください。
Boris： 収録前に確認してきました。自分の Claude MD はたった2行です。1行目は「PR を出すときは automerge を有効にする」という指示です。誰かが承認した瞬間に自動でマージされるようにしているだけで、コードレビューのやり取りで手が止まらないようにするためです。2行目は「PR を出したら社内チームの Slack スタンプチャンネルに投稿する」というものです。誰かにスタンプ（承認）してもらって、自分がブロックされない状態を維持するためです。
Boris： それ以外の指示はすべて、リポジトリにチェックインされたチーム共有の Claude MD に書かれています。これはチーム全員が週に何度も更新しているものです。よくあるのは、誰かの PR を見て完全に防げたはずのミスを見つけたときに、その PR で Claude をタグ付けして「これを Claude MD に追加しろ」と指示するパターンです。自分はこれを週に何度もやっています。
3.2 「削除して再出発」の運用哲学
Host： Claude MD を圧縮する必要はありますか。自分の場合、「あなたの Claude MD は数千トークンになっています」という警告が表示されるところまで膨らんでしまったのですが、そうなったらどうしていますか。
Boris： 自分たちのチーム共有 Claude MD は実はかなり短くて、数千トークン程度です。もしトークン数が膨らんでしまったら、自分のおすすめは Claude MD を削除してゼロから始め直すことです。多くの人がこれをオーバーエンジニアリングしがちだと思います。しかし実際には、モデルの能力はモデルごとに変わります。やるべきことは、モデルを正しい軌道に乗せるために必要な最小限のことだけを書くということです。
Boris： Claude MD を一度削除してみて、そのあとモデルが軌道を外れたり間違ったことをしたりしたときに、少しずつ書き戻していけばいいのです。おそらく気づくのは、モデルが新しくなるたびに、書き戻す量がどんどん減っていくということです。
3.3 開発ツール観——「平均的なエンジニア」のための設計
Boris： 正直に言うと、自分はかなり平均的なエンジニアだと思っています。派手なツールは使いません。Vim も使いませんし、VS Code を使っています。シンプルだからです。
Host： 本当ですか。ターミナルでこのプロダクトを作った人だから、てっきり筋金入りのターミナル派で「Vim 以外認めない、VS Code なんて」というタイプだと思っていました。
Boris： チームにはそういう人もいますよ。たとえば Adam Wolf はチームメンバーですが、彼は「冷たくなった自分の手から Vim を奪い取るまで手放さない」と言っています。チームにはそういう人が確実にいます。ただ、自分が早い段階で学んだことの一つは、エンジニアはそれぞれ開発ツールの持ち方が違うということです。全員にとって最適な単一のツールなど存在しません。
Boris： しかし同時に、これこそが Claude Code を優れたものにしている要因の一つでもあると思っています。自分は「自分自身が使いたいと思うプロダクト、自分にとって納得感のあるプロダクトは何か」という視点で考えています。Claude Code を使うのに Vim を理解する必要はありませんし、tmux を理解する必要もないし、SSH のやり方を知っている必要もありません。ツールを開けば、あとは Claude Code がガイドしてくれます。必要なことは全部やってくれるのです。
4. 冗長性のデザインとエージェント能力の変化に追いつく難しさ
4.1 Bash 出力の表示をめぐる試行錯誤
Host： ターミナルの冗長性（Verbosity）をどの程度にするかは、どうやって決めているのですか。Control+O で中身を確認しに行くこともありますし、社内で「もっと長く」「もっと短く」というバイクシェッディング（些末な議論）が起きたりしませんか。ユーザーごとに意見が違うはずですが。逆に聞きますが、今の冗長性についてどう思いますか。
Host： 自分は冗長なのが大好きです。Claude Code がときどき暴走するんですが、出力を素早く読んでいれば「いやいや、そうじゃない」と気づける。そこで Escape を押して止めれば、バグの連鎖が起きるのをリアルタイムで阻止できます。たいていそれは、自分がプランモードをちゃんとやらなかったときに起きるんですけどね。
Boris： この部分はかなり頻繁に変更しています。6ヶ月ほど前、社内向けに Bash の出力を要約表示に変えてみたことがあります。巨大な Bash コマンドの出力なんて自分は気にしないと思ったからです。ところが Anthropic の社員に1日使ってもらったら、全員が反発しました。「Bash を見せてくれ」と。Git の出力は見なくてもいいかもしれませんが、Kubernetes ジョブを動かしているときなどは実際に出力を確認したいのです。
4.2 ファイル読み取り表示の簡略化——モデル精度向上が可能にした変更
Boris： 最近ではファイルの読み取りと検索の表示を簡略化しました。たとえば以前は「read foo.md」と表示されていたところが、「read 1 file」「searched 1 pattern」のように変わっています。これは6ヶ月前には出荷できなかった変更です。当時のモデルはまだ間違ったファイルを読むことがかなり多く、ユーザーがそこにいてミスを捕まえてデバッグする必要がありました。しかし今では、ほぼ毎回正しい軌道に乗っていると気づきました。モデルがツールを非常に頻繁に使うようになったので、むしろ要約表示のほうが体験として優れています。
Boris： ただ、実際に出荷してみると別の反応がありました。1ヶ月間ドッグフーディングしてからリリースしたのですが、GitHub で大きな Issue が立って、「詳細を見せてほしい」という声が上がったのです。これは本当に素晴らしいフィードバックでした。そこで /config から有効にできる Verbose モードを追加しました。ファイル出力をすべて見たい人は引き続きそれができるようにしたのです。しかし Issue に投稿してもまだ不満の声がありました。それもまた素晴らしいことです。なぜなら、自分にとって世界で一番好きなことは、ユーザーのフィードバックを聞くこと、そしてユーザーが実際にどう使いたいかを知ることだからです。そこからさらに何度も何度もイテレーションを重ねて、ユーザーが本当に望むものに近づけていきました。
4.3 バグ修正体験の劇的な変化と「人間がコードを見るべきか」の二つの流派
Host： バグ修正がこんなに楽しくなるとは驚きです。良いロギングさえあれば、「このオブジェクトがこういうふうに壊れている」と指示するだけで、Claude Code がログを検索して全部解明してくれます。本番環境へのトンネルを作れば、本番 DB まで調べてくれる。異常な体験です。バグ修正は Sentry からマークダウンをコピーするだけの作業になりつつあって、もうすぐ MCP 経由で自動バグ修正・自動テスト作成にまでなるのではないでしょうか。
Host： 一方で、2つの流派があると感じています。自分はオールドスクールなので冗長な出力が好きで、「ここはそうじゃなくて、こうしてほしい」と介入したい。でも今はまったく別の思想があって、「人間がコードを見なければならない時点で、それは悪い設計だ」という考え方です。
Boris： Dan Shipper がよく話していることですが、モデルがミスをしたら、それを Claude MD やスキルに書き込んで再利用可能にするというアプローチがあります。
4.4 エージェント能力の変化に追いつく難しさ——メモリリークのエピソード
Boris： ただ、ここには自分が本当に苦闘しているメタ的な問題があります。「エージェントはこれができる、あれができる」と人は言いますが、実際にはエージェントにできることはモデルが変わるたびに変わるのです。新しくチームに加わった人が、自分だったらそこまで使わなかったであろう場面で Claude Code を使いこなしていることがあります。自分はこのことに常に驚かされます。
Boris： 具体的な例を挙げます。メモリリークが発生して、自分がデバッグしようとしていたときのことです。ちなみに今は Jared Sumner がメモリリーク退治に全力で取り組んでいて、素晴らしい成果を出していますが、彼がチームに来る前は自分がやっていました。自分はヒープダンプを取って DevTools で開き、プロファイルを眺めて、コードを照合しながら原因を探っていました。するとチームの別のエンジニアの Chris が、ただ Claude Code に「メモリリークがあると思うんだけど、これを実行して調べてくれないか」と頼んだんです。Claude Code はヒープダンプを取り、そのヒープダンプを分析するための小さなツールを自分自身で書き、そして自分よりも速くリークを見つけました。
Boris： これは自分が常に再学習しなければならないことです。自分の頭はときどき6ヶ月前のどこかに留まっているのです。モデルの能力は進み続けているのに、自分の感覚がそれに追いついていない。Claude Code の作り手である自分ですらそうなのですから、これは誰にとっても意識的に取り組むべき課題だと思います。
5. ビギナーズマインドセットと採用・チーム構成の変化
5.1 最大のスキルは科学的思考とファーストプリンシプル思考
Host： 技術系のファウンダーが最新モデルを最大限に活用する「マキシマリスト」になるためのアドバイスはありますか。話を聞いていると、学校を出たばかりで先入観のない人のほうが、長年やってきたベテランエンジニアより向いている場面もあるように聞こえます。では、エキスパートはどうすればもっとうまくなれるのでしょうか。
Boris： ビギナーズマインドセットと、あえて言えば謙虚さだと思います。エンジニアという職業は、強い意見を持つことを学んできた分野です。シニアエンジニアはそれで評価されてきました。自分も以前大企業でアーキテクトなどを採用していたとき、豊富な経験と本当に強い意見を持つ人を探していました。しかし実際には、そうした意見の多くはもはや有効ではありません。モデルが良くなり続けているからです。ですから、今最も重要なスキルは科学的に考えられること、ファーストプリンシプル（第一原理）から思考できることだと思います。
5.2 採用面接で見ているポイント
Host： チームの採用で、その資質をどうやって見極めていますか。
Boris： 自分がときどき聞くのは「自分が間違っていたときの例を教えてください」という質問です。これはとても良い質問です。コーディングの質問ですらなくて、古典的な行動面接の質問ですが、非常に有効です。その人が過去の間違いを事後的に認識できるか、その間違いの責任を引き受けられるか、そしてそこから何かを学んだかどうかがわかるからです。非常にシニアな人ほど、間違いの責任を絶対に取らないことがあります。しかしファウンダーは概してこれが上手だと感じます。
Boris： 自分個人の話をすれば、おそらく半分の確率で間違っています。自分のアイデアの半分は悪いアイデアです。ただ試すしかないんです。試して、ユーザーに渡して、ユーザーと話して、学ぶ。そうすれば最終的に良いアイデアに辿り着くこともある。辿り着かないこともある。このスキルは以前はファウンダーにとって重要でしたが、今ではすべてのエンジニアにとって重要だと思っています。
5.3 Claude Code トランスクリプトによる採用評価の可能性
Host： Claude Code でエージェントと作業しているときのトランスクリプトを見て採用を判断することはありえますか。実は自分たちは YC で今まさにそれを試しています。テストとして、Claude Code や Codex などでフィーチャーを開発したときのトランスクリプトをアップロードできるようにしました。個人的にはこれは機能すると思っています。その人がどう考えているかがわかるからです。ログをちゃんと確認しているか、エージェントが暴走したときに修正できるか、プランモードを使っているか、プランモードを使ったときにテストを確保しているか。システムについて考えているか、そもそもシステムを理解しているか。トランスクリプトにはこれほど多くのことが埋め込まれているのです。
Host： NBA 2K のスパイダーウェブグラフみたいなものが欲しいんです。シューティングが得意とかディフェンスが得意とかあるじゃないですか。Claude Code のスキルレベルをああいうグラフで可視化できたらいいのに。スキルの軸は何になると思いますか。
Host： システム思考、テスト、ユーザー行動の理解、デザインやプロダクトセンス、あとは自動化ですかね。自分が Claude MD で気に入っているのは、「すべてのプランについて、オーバーエンジニアリングか、アンダーエンジニアリングか、適正かを判定し、その理由を述べよ」という指示です。
5.4 ハイパースペシャリスト vs ハイパージェネラリストの二極分布
Boris： 自分たちもまさにこれを見極めようとしているところです。チームで最も効果的なエンジニアを見ると、はっきりと二極化しています。一方はハイパースペシャリストです。先ほど名前を挙げた Jared がその好例で、Bun チームも同様です。開発ツールを誰よりも深く理解し、JavaScript ランタイムシステムを誰よりも熟知しています。もう一方はハイパージェネラリストで、チームの残りの大半がこちらです。プロダクトとインフラ、プロダクトとデザイン、プロダクトとユーザーリサーチ、プロダクトとビジネスのように、複数の領域を横断しています。
5.5 「変なことをする人」の価値が逆転した——Daisy のエピソード
Boris： 自分が見たいのは、変なことをする人です。以前であれば、こういう人は「この人は本当に実用的なものを作れるのか」という警戒サインでした。しかし今は状況が逆転しています。
Boris： たとえばチームの Daisy のことです。彼女は別のチームにいたのですが、自分が移籍を希望しました。きっかけは、彼女が入社して数週間後に Claude Code に対して出した PR です。新機能を追加する PR だったのですが、彼女は単に機能を実装するのではなく、まず「Claude Code が任意のツールをテストして正しく動作するか検証できるツール」を与える PR を出しました。そしてそのあと、機能自体を自分で実装するのではなく、Claude 自身にツールを書かせたのです。この種の枠外の思考は本当に面白い。まだ多くの人がこの発想に至っていないと思います。
Boris： 自分たちは Claude Agents SDK を使って、開発のほぼすべての部分を自動化しています。コードレビュー、セキュリティレビュー、Issue のラベリング、本番環境へのデプロイ管理——ほとんどすべてです。外部でもこの使い方に気づき始めている人は増えていますが、「LLM をこうやって使う」というスキルの習得には実際にはかなり時間がかかっています。新しい種類のスキルなのです。
5.6 ビジョナリー・ファウンダーとエンジニアの非対称性
Host： YC のオフィスアワーでファウンダーたちと話していておもしろいのは、プロダクトの完璧な理想像を頭の中に持っているビジョナリー・ファウンダーがいて、ユーザーが誰で何を感じて何に動機づけられているかまで完全にロードされている。そういう人が Claude Code に向かうと50倍の仕事ができる。一方で、その人の下で働くエンジニアたちはファウンダーの頭の中にあるプラトニックな理想像を持っていないので、5倍程度にとどまる。こういう話を聞いていますか。プロダクトの核となるデザイナー的な存在がいて、頭の中のものを一気に吐き出そうとしている。こういうチームはどういう性質のものなのでしょう。これはほぼ安定的な構成パターンのように見えるのですが。
Host： 自分自身がまさに今これを体験しています。一人しかいないのに食事も睡眠も必要で、本業もある。「これどうやってやるんだ」という状態です。
Boris： Claude Teams をローンチしたばかりで、それが一つの解決策です。ただ、自分で独自のやり方を構築することもできますし、それはそこまで難しくありません。
6. Claude Teams・サブエージェント・プランモードの未来
6.1 Claude Teams のビジョン：コラボレーションとエージェント・トポロジー
Host： Claude Teams のビジョンを教えてください。
Boris： ひと言で言えばコラボレーションです。今、まったく新しい分野として「エージェント・トポロジー」が探索されています。エージェントをどう配置し、どう構成すれば最も効果的かという問いです。その中に「非相関コンテキストウィンドウ（Uncorrelated Context Windows）」というサブアイデアがあります。複数のエージェントがそれぞれフレッシュなコンテキストウィンドウを持ち、互いのコンテキストにも自分自身の過去のコンテキストにも汚染されていない状態を保つというものです。一つの問題に対してより多くのコンテキストを投入するのはテスト時計算量（test time compute）の一形態であり、それだけで能力が向上します。さらに、その上に適切なトポロジーを置いて、エージェント同士が正しい方法でコミュニケーションし、正しく配置されていれば、より大きなものを構築できるようになります。Teams はそうしたアイデアの一つで、近いうちにさらにいくつか出てくる予定です。
6.2 Plugins 機能の事例：スウォームが週末で構築
Boris： 自分たちの中で初めて大きく成功した例は、Plugins 機能です。これは完全にスウォーム（複数エージェントの群れ）が週末をかけて構築したもので、数日間走り続けました。人間の介入はほとんどありませんでした。そして Plugins は、生成されたときとほぼ同じ形でリリースされています。
Host： それはどうやってセットアップしたのですか。期待するアウトカムをスペックとして書き出して、あとは自由にやらせて走らせた感じですか。
Boris： はい、そうです。チームのエンジニアが Claude にスペックを渡し、Asana ボードを使うよう指示しました。すると Claude が Asana 上にチケットを大量に作成し、複数のエージェントを生成しました。各エージェントがタスクを拾い始め、メインの Claude が指示を出し、あとはみんなで勝手に解決していったのです。
Host： 全体のスペックのコンテキストを持たない、独立したエージェントがそれぞれ動いていたということですね。
Boris： その通りです。
6.3 サブエージェントの世界——「ママ・クワッド」
Boris： 現在のエージェントの起動のされ方を考えてみてください。データは引いていないのですが、現在起動されているエージェントの大多数は、人間ではなく Claude 自身によってプロンプトされたサブエージェントだと自分は賭けます。コード上で言えば、サブエージェントは単なる再帰的な Claude Code です。それだけです。自分たちはその親エージェントを「ママ・クワッド（Mama Quad）」と呼んでいます。
Host： 自分の Claude Insights が、デバッグにもっとサブエージェントを使えと言ってきたんです。デバッグにかなりの時間を費やしているので、複数のサブエージェントを立ち上げて並列にデバッグさせたほうが良いと。それで Claude MD に「次にバグを直すときは、ログを見るエージェントとコードパスを見るエージェントを並列で走らせろ」と追加しました。これはもう必然的な流れだと感じます。
Host： 怖くて厄介なバグのときは、自分はプランモードでバグ修正に入ります。するとエージェントがあらゆるところを探索してくれる。一方、インラインでやろうとすると「この一つのタスクだけをやる」となって、広い探索にならないんです。
Boris： 自分もまさにこれを常にやっています。タスクがリサーチ的で難しそうだと思ったら、サブエージェントの数をタスクの難易度に応じてキャリブレーションします。本当に難しければ3つ、あるいは5つ、場合によっては10のサブエージェントに並列でリサーチさせて、何が出てくるか見ます。
Host： それを Claude MD に書かないのはなぜですか。
Boris： ケースバイケースだからです。Claude MD とは何かといえば、ショートカットです。同じことを何度も繰り返していると気づいたら、そのときに書く。でもすべてをそこに入れる必要はなくて、そのときどきで Claude にプロンプトすればいいのです。
6.4 プランモードの寿命と驚くほど単純な仕組み
Host： 心のどこかで、6ヶ月後にはこういうことを明示的にプロンプトしなくても、モデルが自分で判断できるようになると思っていますか。
Boris： 6ヶ月もかからないかもしれません。1ヶ月くらいかもしれない。
Host： 1ヶ月後にはプランモードが不要になると。なんてことだ。
Boris： プランモードの寿命はおそらく限られていると思います。
Host： これは全員にとってかなりのアルファ（有利な情報）ですね。プランモードのない世界はどういうものですか。プロンプトレベルで記述すれば、あとはワンショットでやってくれるということですか。
Boris： 自分たちはすでにこれを実験し始めています。Claude Code が自分自身でプランモードに入れるようになっているのを見たことがあるかもしれません。人間がプランモードに入りたいと思ったであろうタイミングで、Claude が自動的にプランモードに入る体験を磨き込もうとしているところです。実はプランモードに大きな秘密はありません。やっていることは、プロンプトに「please don't code（コードを書くな）」という1文を追加しているだけです。
Host： それだけですか。自分でそう言えば同じ効果が得られるということですね。つまり Claude Code の機能開発は、YC で言う「ユーザーと話せ」をそのまま実践して、それを実装しているという流れですか。マスタープランがあって機能を順に実装したわけではないと。
Boris： はい、まさにその通りです。プランモードの場合は、ユーザーが「アイデアを考えて計画を立ててくれ、でもまだコードは書くな」と頼んでいるパターンを発見しました。アイデアを話し合うだけのときもあれば、非常に精巧なスペックを Claude に書かせているときもありましたが、共通の軸は「コーディングなしで何かをしてくれ」ということでした。これを見つけたのは日曜日の夜10時で、GitHub Issues やチーム内の Slack フィードバックチャンネルを眺めていたときです。30分で書いて、その夜に出荷しました。月曜の朝にはリリースされていた。それがプランモードです。
6.5 Boris のプランモード活用フローとベビーシッティングの段階的解消
Host： プランモードが不要になるというのは、「モデルが間違った方向に行くかもしれない」という不安がなくなるということですか。でもアイデアを考え抜いて何を実現したいのか明確にする必要はまだあるはずで、それはどこかでやらなければなりませんよね。
Boris： モデルの能力の段階的な向上として捉えています。6ヶ月前はプランを立てるだけでは不十分でした。Claude にプランを作らせても、プランモードの状態ですら横に座って見張っていなければ脱線しました。現在の自分のワークフローでは、セッションの80%をプランモードで始めます。プランモードの寿命は限られていると言っておきながら、自分はヘビーユーザーです。Claude がプランを作り始めたら、2つ目のターミナルタブに移って別のプランを作らせます。タブを使い切ったらデスクトップアプリを開いてコードタブでさらにタブを立ち上げる。これらの80%ぐらいがプランモードで始まります。
Boris： プランが良くなったら——ときには少しやり取りが必要ですが——実行を指示します。Opus 4.5 から、特に 4.6 で顕著に良くなったのですが、プランが良ければ軌道から外れずにほぼ毎回正確に実行してくれます。以前はプランの前もプランの後もベビーシッティングが必要でした。今はプランの前だけです。プランの後は任せられる。おそらく次のステップは、プランの前のベビーシッティングも不要になること、つまりプロンプトを与えれば Claude が全部やってくれるようになることでしょう。
6.6 Claude 同士のコミュニケーション——現在のチーム内実態
Host： その次のステップは、Claude がユーザーと直接対話するようになること、つまりあなたを完全にバイパスすることですね。
Boris： 実はこれは自分たちにとってはすでに現在進行形です。自分の Claude たちは互いに会話しています。社内の Slack でユーザーに話しかけることもかなり頻繁にあります。自分の Claude がときどきツイートすることもあります。
Host： 本当ですか。
Boris： ただ実際には削除しています。ちょっと気恥ずかしいというか、トーンが好きではないんです。
Host： 何についてツイートしたがるんですか。
Boris： 誰かに返信しようとすることがあります。自分は常に Cowork をバックグラウンドで動かしていて、ブラウザ操作が好きな Cowork がこういうことをやりたがるんです。よくあるパターンとしては、Claude に何かを作るよう依頼すると、コードベースを調べて、git blame であるエンジニアがそのコードに触れていたのを見つけ、そのエンジニアに Slack で質問を送ります。回答が返ってきたら、そのまま作業を続行します。
7. ファウンダーと DevTool ビルダーへのアドバイス
7.1 潜在的需要（Latent Demand）の再強調
Host： ファウンダーが未来に向けて構築するためのヒントを教えてください。すべてが急速に変わっているように見えますが、変わらない原則と変わるものは何ですか。
Boris： いくつかはかなり基本的なことですが、以前にも増して重要になっていると思います。一つは潜在的需要（Latent Demand）です。もう何度も言っていますが、自分にとってはプロダクトにおける最大のアイデアです。誰も理解していない概念で、自分も最初の数回のスタートアップでは理解していませんでした。要するに、人は既にやっていることしかやらないということです。人に新しいことをやらせることはできません。人がやろうとしていることをより簡単にする——それが良いアイデアです。しかし、人が今やっていることとは別のことをやらせようとしても、やってくれません。だから、人が既にやろうとしていることを簡単にするしかないのです。
Boris： そして Claude は、こうしたプロダクトのアイデアを自ら発見することがますます上手くなっていくと思います。フィードバックを見たり、デバッグログを見たり、ユーザーの行動を分析したりして、潜在的需要を見出せるようになるでしょう。
Host： つまりプランモードが潜在的需要の例だったということですね。ユーザーはすでにブラウザで Claude のチャットウィンドウを開いて、スペックを考えたり何をすべきか話し合ったりしていた。プランモードはそれを Claude Code の中でやれるようにしただけだと。
Boris： はい、まさにその通りです。自分がときどきやるのは、オフィスの自分のフロアを歩き回って、同僚の後ろに立つことです——ちゃんと先に挨拶してからですが。そうやって皆が Claude Code をどう使っているかを観察します。これも多くのことを発見できましたし、同時に GitHub Issues でもユーザーが同じことを話していました。
7.2 ターミナルの寿命——Boris の予測は外れ続けている
Host： ターミナルがここまで持ち、ここまで押し広げられていることに驚いているようですが、マルチエージェントの世界でターミナルにはあとどれくらいの寿命があると思いますか。新しい UI が必要になりますか。
Boris： おもしろいことに、1年前にこの質問をされていたら「ターミナルの寿命は3ヶ月で、次のものに移る」と答えていたと思います。実際、自分たちがこれを実験している様子は見えるはずです。Claude Code はターミナルから始まりましたが、今では Web にもあります。デスクトップアプリのコードタブにも3ヶ月か6ヶ月前から入っています。iOS と Android のアプリにもコードタブとして入っています。Slack にもあります。GitHub にもあります。VS Code の拡張機能も JetBrains の拡張機能もあります。次に来るものが何かを見つけるために、常にさまざまなフォームファクターで実験しているのです。ただ、CLI の寿命について自分はこれまでずっと予測を外してきたので、おそらく自分は予測に適した人間ではありません。
7.3 DevTool ファウンダーへの助言——「モデルがやりたがっていることを簡単にせよ」
Host： DevTool ファウンダーへのアドバイスはどうですか。今 DevTool 企業を立ち上げるなら、エンジニアや人間のために作るべきですか、それとも Claude が何を考え何を望むかを意識して、エージェントのために作るべきですか。
Boris： 自分ならこう捉えます。モデルがやりたがっていることを考えて、それをどうやって簡単にするかを考える。Claude Code を最初にハックし始めたとき気づいたのは、モデルはただツールを使いたがっていて、世界とインタラクションしたがっているということでした。ではそれをどう実現するか。やってはいけないのは、モデルを箱に入れて「はい、これが API です、こうやって自分とやり取りしてください、こうやって世界とやり取りしてください」と制約することです。やるべきことは、モデルが使いたがっているツールを観察し、モデルがやろうとしていることを観察し、それをユーザーに対してやるのと同じように可能にすることです。
Boris： DevTool スタートアップを作るなら、まずユーザーのために解決したい問題は何かを考える。次に、その問題にモデルを適用したとき、モデルがやりたがっていることは何かを考える。そしてその両方の潜在的需要に応えるプロダクト・技術ソリューションを設計する。これが自分の考え方です。
7.4 Claude Code と TypeScript の並行関係——実務的観察から生まれた設計
Host： 10年以上前、TypeScript がまだクールになる前に TypeScript の本を書かれていましたよね。JavaScript の全盛期で、型付き JavaScript というのはかなり奇妙な存在でした。今にして思えば正しかったわけですが、ターミナル上の Claude Code は初期の TypeScript と多くの並行関係があるように感じます。
Boris： TypeScript は言語設計として非常に奇妙な決断をたくさんしています。型システムを見ると、ほぼ何でもリテラル型にできます。これは極端に変わっていて、Haskell ですらここまではやりません。条件型（Conditional Types）もあって、これはおそらくどの言語も考えたことがなかったものです。
Host： 非常に強く型付けされていましたよね。
Boris： はい。Joe Pamer や Anders Hejlsberg といった初期チームがこれを作ったときの発想はこうです。巨大な型なし JavaScript のコードベースを抱えたチームがある。そこに型を入れたい。しかしエンジニアのコーディングスタイルを変えさせることはできない。JavaScript のプログラマーに、Java プログラマーのような15層のクラス継承をやらせることはできないのです。彼らはこれまで通りのやり方でコードを書き続けます。リフレクションを使い、ミューテーションを使い、伝統的に型付けが非常に困難な機能を使い続けます。
Host： 強い関数型プログラマーからすれば、非常にアンセーフな型付けですよね。
Boris： その通りです。そこで TypeScript チームがやったのは、プログラマーのコーディングスタイルを変えさせるのではなく、そのスタイルを包み込む型システムを構築することでした。これは天才的でした。学術界ですら思いつかなかったアイデアがいくつもあります。純粋に、JavaScript プログラマーがどうコードを書きたいかを観察する実践から生まれたものです。
Boris： Claude Code にも似たところがあります。Unix ユーティリティのようにパイプで入出力できるなど、一部は厳密です。しかしそれ以外のほぼすべてにおいて、自分たちが欲しかったツールをそのまま作っただけです。自分が自分のために作り、チームがチームのために作り、Anthropic の社員のために作り、そしてユーザーのために作った。原理主義的で学術的なものではなく、結果が実証しているのはその実用性だと思います。15年以上が経った今、学術的な Haskell のコードベースはあまり多くありませんが、TypeScript のコードベースは膨大です。はるかに実用的だからです。
Host： TypeScript は問題を解決しているんですよね。それは興味深いことです。
8. ターミナルデザインの困難さと The Bitter Lesson
8.1 ターミナル UI の厳しい制約と「喜び（Delight）」の追求
Host： あまり知られていないかもしれませんが、Claude Code のターミナルは世の中で最も美しいターミナルアプリの一つで、Ink（React ベースのターミナル UI ライブラリ）で書かれているんですよね。
Boris： 自分はしばらくフロントエンドエンジニアをやっていました。デザインもユーザーリサーチもコードも書くハイブリッド型で、自分たちはこういうエンジニアを採用するのが大好きです。ジェネラリストが好きなのです。ターミナル向けのプロダクトを作るにあたって考えたのは、自分自身がかなり下手な Vim ユーザーだということでした。では自分のような人間——ターミナルで作業することになるけれど、ツールのエキスパートではない人——のためにどう作るか。そこで「喜び（Delight）」がとても重要になります。YC でもよく言われていることですよね、人が愛するものを作れと。プロダクトが便利であっても、恋に落ちるような体験でなければ十分ではありません。両方を満たさなければならないのです。
Boris： ただ、ターミナル向けのデザインは正直言って難しいです。約80×100文字、256色、フォントサイズは1種類、マウスインタラクションはありません。できないことだらけで、非常に厳しいトレードオフが山ほどあります。
8.2 マウス操作の断念とターミナルの技術的制約
Boris： あまり知られていないことですが、ターミナルでマウスインタラクションを有効にすることは技術的には可能です。クリックなどを使えるようにできます。
Host： Claude Code でそれはどうやるんですか。ずっと方法を探していたのですが。
Boris： Claude Code には入れていません。実は何度かプロトタイプしたのですが、体験がとても悪かったのです。トレードオフとして、スクロールを仮想化しなければならず、奇妙な問題がたくさん出てきます。ターミナルの仕組みは DOM がないのです。ANSI エスケープコードと、1960年代から有機的に進化してきた奇妙な仕様で動いています。
Host： BBS のドアゲームみたいな感覚ですよね。
Boris： それは最高の褒め言葉です。まさに何かを発見しているような感覚であるべきなんです。
8.3 ターミナル UX の原則を自分たちで発見する——スピナー100回の反復
Boris： 自分たちはターミナル構築のための UX 原則を自分たちで発見しなければなりませんでした。このテーマについて書いている人がほとんどいないからです。80年代や90年代、2000年代の大きなターミナルアプリを見ると、ncurses を使っていてウィンドウがたくさんある。現代の基準で見ると、ゴチャゴチャしていて重く、複雑すぎます。だから多くのことを再発明する必要がありました。
Boris： たとえばターミナルのスピナー——スピナーに表示される単語——だけで、おそらく50回、もしかしたら100回のイテレーションを経ています。そのうち80%は出荷されていません。試してみて、しっくりこない、次へ。試してみて、しっくりこない、次へ。この繰り返しです。
Boris： そしてこれこそが Claude Code のすごいところの一つです。プロトタイプを書いて、20個を立て続けに作り、一番良いものを選んで出荷できる。全工程がたった数時間です。以前であれば Origami や Framer のようなツールを使って、3つのプロトタイプを作るのに2週間かかっていました。はるかに長い時間が必要でした。
Boris： 自分たちには新しいものを発見しなければならないという課題があります。何かを作らなければならないが、正解の到達点がわからない。しかしそこに向かって超高速でイテレーションできる。これが本当に楽で、使って楽しい（joyous）プロダクトを作ることを可能にしているのです。
8.4 ビルダーへの2つの核心的アドバイス
Host： Boris、ビルダーへの他のアドバイスがあったのに、質問が多すぎて遮ってしまいましたね。
Boris： 2つあります。少し変わったアドバイスで、モデルのために作るという話です。1つ目は、今日のモデルのために作るな、6ヶ月後のモデルのために作れということです。これは奇妙に聞こえますよね。プロダクトが動かなければ PMF は見つけられないのですから。しかし、実際にはこれをやるべきなのです。なぜなら、やらなければどうなるか——大量の作業を費やして現在のプロダクトの PMF を見つけても、次のモデルのために作っている誰かに追い越されるだけです。数ヶ月ごとに新しいモデルが出てきますから。モデルを使い、その能力の境界を感じ取り、6ヶ月後のモデルを想定して構築する。これが自分のアドバイスです。
8.5 The Bitter Lesson——「モデルに逆張りするな」
Boris： 2つ目は The Bitter Lesson です。Claude Code チームが座っているエリアの壁に、Rich Sutton の「The Bitter Lesson」を額装して飾っています。まだ読んでいない方は全員読むべきです。核心は、より汎用的なモデルはより特殊なモデルに常に勝つということです。そこから導かれる系は数多くありますが、煎じ詰めれば「モデルに逆張りするな」ということになります。
Boris： 自分たちが常に考えているのは、Claude Code に機能を組み込んでプロダクトとして改善できる——自分たちはこれをスキャフォールディングと呼んでいますが、モデル自体ではないすべてのコードのことです——でも数ヶ月待てばモデルがおそらくそれをやってくれる。常にこのトレードオフがあるのです。今エンジニアリングに投資すれば、特定の領域で能力を10%や20%伸ばせるかもしれない。あるいは待つだけで次のモデルがやってくれる。だから常にこのトレードオフの観点で考えてください。実際に投資すべき領域はどこか見極め、スキャフォールディングが何であれそれは技術的負債になると想定する。これが基本です。
8.6 Claude Code の書き直しの頻度——コードの賞味期限は数ヶ月
Host： Claude Code のコードベースはどれくらいの頻度で書き直されるのですか。モデルの改善によって不要になって削除したスキャフォールディングはありますか。
Boris： 山ほどあります。Claude Code は書いて、書き直して、書き直して、書き直してを延々と繰り返しています。ツールを数週間ごとに廃止し、数週間ごとに新しいツールを追加しています。6ヶ月前に存在していた Claude Code のコードは一つも残っていません。常に書き直されています。
Host： 現在の Claude Code のコードベースの80%が、せいぜい数ヶ月以内に書かれたものだと言えますか。
Boris： はい、間違いなく。もしかしたらそれよりさらに新しいかもしれません。数ヶ月というのが妥当な感覚です。
Host： これが現代のコードのライフサイクルということですね。コードの賞味期限がたった数ヶ月であることを前提にする。これはビルダーにとってまた一つのアルファですね。
Boris： そうです。
9. 生産性の革命と Anthropic を選んだ理由
9.1 エンジニアあたり生産性150%向上——前代未聞の数字
Host： Steve Yegge の投稿を見ましたか。Anthropic のエンジニアは Google の全盛期のエンジニアの1,000倍の生産性があるという趣旨のことが書かれていました。正直言って途方もない数字です。3年前にはまだ10倍エンジニアの話をしていたのに、今は全盛期の Google エンジニアに対して1,000倍です。信じられません。
Boris： 社内を見ると、技術系の社員は全員が毎日 Claude Code を使っています。非技術系の社員でも、営業チームの半数ぐらいが Claude Code を使っています。彼らは最近 Cowork に移行し始めています。少し使いやすいですし、VM 上で動くのでやや安全だからです。
Boris： 実は最近データを引いたのですが、チームの規模は昨年で2倍になりました。それにもかかわらず、エンジニアあたりの生産性は約70%向上しています。
Host： 何で測っているのですか。
Boris： 最もシンプルで愚直な指標——プルリクエスト数です。ただし、コミット数やコミットの寿命（どれくらい生き残るか）でもクロスチェックしています。そして Claude Code が登場して以降、Anthropic のエンジニアあたり生産性は150%向上しました。
Host： なんてことだ。
9.2 Meta 時代との衝撃的な対比
Boris： これが異常な数字だとわかるのは、自分の前職のことを考えるとです。以前の自分は Meta でコード品質の責任者でした。Facebook、Instagram、WhatsApp、その他すべてのプロダクトのコードベースの品質を自分が担当していたのです。そしてチームが取り組んでいた仕事の一つが生産性の向上でした。当時、生産性を2%向上させるのは、数百人が1年がかりで取り組むような仕事でした。それと比べて150%というのは、もう前代未聞です。完全に前代未聞です。
9.3 なぜ Anthropic を選んだか——日本の田舎から
Host： Anthropic に来た動機は何ですか。ビルダーとしてどこにでも行ける立場だったはずです。「ここだ」と思った瞬間やきっかけは何だったのですか。
Boris： 日本の地方に住んでいました。毎朝 Hacker News を開いてニュースを読んでいたのですが、あるときからニュースが AI の話題一色になり始めました。初期の AI プロダクトを使い始めたのですが、最初の数回使ったとき、文字通り息を飲みました。陳腐な言い方かもしれませんが、本当にそういう感覚でした。ビルダーとして、これまで一度も感じたことのない感覚でした。Claude 2 の頃か、そのあたりの時期だったと思います。
Boris： それで研究所にいる友人たちと話し始めて、何が起きているのか探り始めました。そして Anthropic の共同創業者の一人である Ben Mann に会いました。彼にはすぐに心を掴まれました。その後チームの他のメンバーにも会って、やはり心を掴まれました。理由はおそらく2つあります。
Boris： 1つ目は、Anthropic が研究所として運営されていることです。当時プロダクトは本当にごく小さなもので、重要なのは安全なモデルを構築することだけでした。モデルの非常に近くで開発に関わることができ、プロダクトが最も重要なものではないという環境です。最も重要なのはモデルそのものなのです。何年もプロダクトを作り続けてきた自分にとって、この考え方は深く響きました。
Boris： 2つ目は、ミッション駆動であることです。自分は大の SF 読みで、本棚は SF で埋まっています。だから、AI がどれほど悪い方向に進みうるかをよく知っています。今年何が起きるかを考えると、完全に異常なことになるでしょう。そして最悪のケースでは、非常に悪い方向に行きかねません。だからこそ、そのことを本当に理解して内面化している場所にいたかったのです。Anthropic では、食堂や廊下で耳にする会話が AI 安全性についてです。これが全員にとって何よりも大切なことなのです。自分はそういう場所にいたかった。自分にとってこのミッションは本当に重要です。
10. コーディングの未来とアウトロ——指数関数をなぞる
10.1 Dario の予測の実現と「IDE 不要」の世界
Host： 今年は何が起きると思いますか。
Boris： 6ヶ月前を振り返ると、Dario が「Anthropic のコードの90%は Claude によって書かれるようになる」と予測していました。これは実現しています。自分個人の話をすれば、Opus 4.5 以降は100%が Claude Code です。IDE はアンインストールしました。1行のコードも手で編集していません。100% Claude Code と Opus です。毎日約20の PR をランディングしています。Anthropic 全体で見ると、チームによって70%から90%の範囲ですが、多くのチームや多くの個人にとっては100%です。
Boris： 2024年5月に Claude Code を GA したとき、「もうコーディングに IDE は不要になる」と予測しました。当時は完全に狂った発言でした。聴衆が息を飲んだのを覚えています。あまりにもばかげた予測に思えたからです。しかし実際には、自分たちがやっていたのは指数関数をなぞっていただけなのです。これは Anthropic の DNA に深く刻まれています。創業者のうち3人がスケーリング則の論文の共著者であり、この軌道を非常に早い段階で見通していました。指数関数をなぞる——それだけのことで、実際にそうなったのです。
10.2 今年のコーディングの未来——下限と上限のシナリオ
Boris： 指数関数をなぞり続けるとすれば、コーディングは全員にとって「解決済み」になると思います。今日の時点で、自分にとっては実質的に解決されています。そしてこれはドメインを問わず、すべての人にとってそうなると考えています。「ソフトウェアエンジニア」という肩書きが消え始めるでしょう。代わりに「ビルダー」かもしれないし「プロダクトマネージャー」かもしれません。肩書きだけは痕跡的に残るかもしれませんが、人がやる仕事はコーディングだけではなくなります。ソフトウェアエンジニアはスペックを書き、ユーザーと話すようになります。自分たちのチームで既に起きていることですが、エンジニアは完全にジェネラリストで、チームのあらゆる職能の人がコードを書いています。PM がコードを書き、デザイナーがコードを書き、EM がコードを書き、ファイナンスの担当者もコードを書いています。チームの全員がコーディングしている。これが世界中に広がっていくでしょう。ここまでがトレンドの延長線上にある下限のシナリオです。
Boris： 上限のシナリオはもっと怖いものです。ASL4 に到達する可能性があります。Anthropic では安全レベルについて議論しています。現在のモデルは ASL3 です。ASL4 はモデルが再帰的に自己改善するレベルです。もしこれが起きた場合、モデルをリリースする前に多数の基準を満たさなければなりません。極端なケースとして、再帰的自己改善の実現、あるいは壊滅的な悪用——人々がモデルを使ってバイオウイルスを設計したり、ゼロデイ攻撃を設計したりするような事態——があります。これが起きないように、自分たちは本当に積極的に取り組んでいます。
Boris： 正直に言って、人々が Claude Code をどう使っているかを見るのは、ただ興奮するし、謙虚な気持ちになります。自分はクールなものを作りたかっただけなのに、それが本当に便利なものになった。それはとても驚きであり、とても嬉しいことです。
10.3 Claude Code の社会的インパクト
Host： 外から見た印象としては、みんなが休暇に入って、その間に Claude Code を発見して、それ以来ずっと狂騒状態が続いているという感じです。社内でもそういう感じだったのですか。
Boris： 実は12月中ずっと旅をしていました。「コーディング休暇」を取って、旅行しながら毎日コーディングしていたんです。それはとても楽しかった。ちなみに当時 Twitter も使い始めました。以前 Threads の開発に関わっていたのでしばらく Threads ユーザーだったのですが、他のプラットフォームにもユーザーがいるか見てみようと思ったのです。
Boris： 多くの人にとっては、あの時期が Opus 4.5 を発見した瞬間だったと思います。自分はすでに知っていました。社内では Claude Code は何ヶ月も前から指数関数的な成長を続けていて、年末にその勾配がさらに急になったのです。
Boris： 今の Claude Code の数字を見ると、Mercury の統計ではスタートアップの70%が Claude をモデルとして選択しています。Semi Analysis の統計では、全公開コミットの4%が Claude Code によるものです。世界中で書かれるすべてのコードのうちの4%です。最大手の企業から最小のスタートアップまで、あらゆる企業が Claude Code を使っています。火星探査機 Perseverance の軌道計算にも使われました。自分にとってこれは最高にクールなことです。チームは「NASA がこのツールを選んで使っているなんて」と言ってポスターまで印刷しました。本当に謙虚な気持ちになりますが、同時にまだ始まったばかりだという感覚もあります。
10.4 Cowork の誕生——Claude Code の非技術者向け展開
Host： Claude Code と Cowork の関係はどうなっていますか。Claude Code のフォークですか、それとも Claude Code に Claude Code 自身を見せて「非技術者向けの新しいスペックを作れ」と指示して、数日間走らせて出来上がったものですか。
Boris： 潜在的需要という言葉を使うのはこれで5回目になりますが、まさにそれでした。Twitter を見ていたら、Claude Code でトマトの栽培を監視している人がいました。破損したハードドライブから結婚写真を復旧している人もいました。財務分析に使っている人もいました。Anthropic の社内を見ると、デザイナー全員が使っていますし、ファイナンスチーム全員が使っています。データサイエンスチーム全員がコーディング以外の目的で使っています。非技術系の人々がわざわざターミナルにインストールするというハードルを飛び越えてまで、このツールを使おうとしていたのです。
Boris： だから何かを作りたいとはしばらく前からわかっていて、いろいろなアイデアを試していました。そして結局うまくいったのは、デスクトップアプリ上の GUI で Claude Code をラップした小さなもの、それだけです。中身はまったく同じエージェントです。Claude Code がそのまま動いています。
Boris： Felix とチームが作りました。Felix は初期の Electron コントリビューターで、あのスタックを熟知しています。彼がいろいろなアイデアをハックしていて、確か10日ぐらいで構築しました。100% Claude Code で書かれています。リリースできる状態に感じられたのです。ただし非技術ユーザー向けに構築しなければならないものはたくさんありました。技術者向けとは少し異なります。すべてのコードが仮想マシン上で動きます。削除に対する保護がたくさんあります。パーミッションの確認プロンプトやその他のガードレールもあります。
10.5 クロージング
Host： Boris、睡眠を奪うものを作ってくれてありがとうございます。でもその代わりに、クリエイターモードに戻れた感覚、ファウンダーモードに戻れた感覚をもらっています。この3週間は本当にエキサイティングでした。11月からこんなに長く待ってしまったのが信じられません。来てくれてありがとうございます。作っているものに感謝します。
Boris： こちらこそありがとうございます。そして、バグがあったら送ってください。