Anthropic Claude Code 開発責任者 Boris Cherny が Lenny's Podcast で話したこと、ほぼそのまま共有します

2026年2月19日に公開された Lenny's Podcast に、Anthropic の Claude Code 開発責任者 Boris Cherny が出演しました（YouTube動画はこちら、1時間27分45秒）。

ちょうど Claude Code が外部リリースされて 1 周年というタイミングです。この 1 年でソフトウェアエンジニアという職業がどれだけ変わったか、ここから先どこへ向かうのかを、当事者本人がかなり率直に語っている回でした。

私が要約して薄めるよりも、一次情報をそのまま共有したいというモチベーションのほうが強いので、Boris の発言を ほぼそのままの粒度で 日本語に置き換え、Lenny との掛け合いの流れも極力崩していません。一気に読むと長いので、章ごとに区切って読めるようにしています。

もう一つのモチベーションとして、元の YouTube 動画は 1 時間半近くあって視聴するとそれだけ時間が溶ける のですが、記事化しておけば自分のペースで一気に読めるし、欲しい情報だけ拾い読みもできます。動画を最初から最後まで再生する余裕がない人にも届くように、こういう形で残しておきます。

特に印象に残ったのは次の 4 点です。

• Boris 自身が「11月以降、自分の手で1行も編集していない」状態で、毎日 10〜30 個の PR を出していること

• GitHub の全コミットの 4% が Claude Code 製で、年末には全コミットの 5分の1 に達すると見ていること

• Anthropic 社内ですらエンジニア生産性が 200% 向上、しかもチーム規模は 4 倍に拡大している事実

• 「最初から最適化しようとしないこと、コスト削減から入らないこと」というスタートアップへの強烈なアドバイス

それでは本編です。Lenny を L、Boris を B と表記します。

なぜ Boris は Anthropic を辞めて Cursor に行き、2 週間で戻ってきたのか

冒頭、Lenny がいきなりスパイシーな質問から入ります。

L: 約 6 ヶ月前、覚えている人もいないかもしれませんが、あなたは実は Anthropic を退職して Cursor に参加し、その 2 週間後に Anthropic に戻りましたよね。何があったんですか？私が経験した中で最速の転職劇でした。

B: Cursor に入ったのは、プロダクトの大ファンだったからです。チームに会って本当に感銘を受けました。AI コーディングがどこに向かうかを、多くの人より早く見抜いていたチームです。良いプロダクトを作るというアイデア自体がとてもエキサイティングでした。

ところが入社してすぐに気づいたのは、私が Anthropic で本当に恋しかったのはミッションだった ということです。Anthropic に惹かれたのはそのミッションです。それは安全性に関するものでした。Anthropic の社員に「なぜここにいるのか」と聞くと、廊下で誰を捕まえても答えは必ず「安全性」です。

このミッションドリブンさが本当に自分に響いて、個人的にこれがないと幸せになれないんだと分かりました。仕事の内容がどれだけエキサイティングでも、たとえ本当にクールなプロダクトを作っていても、それの代わりにはならないと気づきました。

「2 週間でラボに戻った」を「ミッションが恋しかった」と語れるのは、今の AI バブルの中では割と希少な感覚です。プロダクトの面白さでは Cursor を上回る評価を持っていた、と本人が言っているのもポイントだと思います。

GitHub 全コミットの 4% が Claude Code 製、まだスタート地点

L: 最近 Semi Analysis が出したレポートをご存じだと思いますが、GitHub の全コミットの 4% が Claude Code 製 であり、年末までには全コミットの 5 分の 1 に達するだろうと予測しています。レポートの言葉を借りれば「私たちが瞬きしている間に、AI がソフトウェア開発を飲み込んだ」です。

L: この収録の日、Spotify が「ベスト開発者は 12 月以降 AI のおかげで 1 行もコードを書いていない」というヘッドラインを出しました。あなたを含め、最先端のシニアエンジニアの多くが、もはやコードを書かない、すべて AI 生成だと公言するようになっています。

B: 全コミットの 4% なんて、想像をはるかに超えていますし、これでもまだスタート地点という感じです。しかもこれは公開コミットだけです。プライベートリポジトリを見れば、もっと高い割合だと思っています。

B: 私にとって最もクレイジーなのは現在の数字ではなく、成長のペースそのものです。Claude Code の成長率はどの指標を見ても加速し続けています。単に上昇しているだけでなく、上昇スピードがどんどん速くなっている。

「指数関数の途中」という抽象論ではなく「私個人がもう手で書いていない」「DAU は垂直」というレベルで肌身に感じている人物が言っている、というのが効きます。

Claude Code 誕生 — Bash ツールだけ渡したら聴いている音楽を当ててきた

B: Claude Code を始めた当初、これはちょっとしたハック程度のはずでした。Anthropic 社内では、何らかのコーディング製品を ship したいというぼんやりした方針がありました。Anthropic では長らく、安全な AI を構築するメンタルモデルに合うようにモデルを訓練してきました。最初にコーディングが得意になり、次にツール使用、その次にコンピュータ使用、というのがおおまかな軌跡です。

B: 私が当初所属していたチームは「Anthropic Labs」と呼ばれていて、Mike Krieger と Ben Mann が、第 2 ラウンドとして再びこのチームを立ち上げました。チームはかなり良いものを作りました。Claude Code、MCP、デスクトップアプリ。コーディング → ツール使用 → コンピュータ使用という流れの種が見えてきます。

B: Anthropic に入ってから、最初の 1 ヶ月はハッキングに費やし、たくさんの変なプロトタイプを作りました。次の 1 ヶ月はポストトレーニングをやりました。研究側を理解するためです。エンジニアとして良い仕事をするには、自分が働くレイヤーの一つ下のレイヤーを本当に理解する必要があると思っています。

B: それから戻ってきて、後に Claude Code となるもののプロトタイピングを始めました。最初のバージョンは、そのデモを録画してポストした夏のビデオがあります。当時は Claude CLI と呼んでいました。

ここからが象徴的なエピソードです。

B: 衝撃的だったのは、Bash ツールを与えただけで「今何の音楽を聴いてる？」と聞いたら、それを使ってコードを書き、私が今聴いている音楽を答えてきた ことです。これが本当にクレイジーで、「このツールはこれに使え」みたいな指示は一切していないんです。モデルにツールを渡しただけで、自分が答えられるかどうかも分からなかった「今聴いている音楽は何か？」という問いに、自力で使い方を考え出したんです。

B: それで少しプロトタイピングを進めて、社内でアナウンスを投稿しました。返ってきたいいねは 2 つだけ。当時の反応はそれが全てでした。

社内アナウンスへの「いいね 2 個」から始まったプロダクトが、1 年後に GitHub 全体の 4% を書いている、というのは結構味わい深い対比です。

なぜターミナルだったのか — 最初は意図的にリソースを少なめにする

B: 社内の人たちは、コーディングツールというと IDE のような、かなり洗練された環境を思い浮かべます。誰もこれがターミナルベースになるとは思わなかった。ターミナルで作るのは奇妙な設計選択で、別にそれを意図したわけではありません。最初の数ヶ月は私一人だったので、ターミナルで作るのが一番楽だったんです。

B: これは私にとって重要なプロダクトの教訓でもあります。

B: その後、他のフォームファクターを検討し始めましたが、しばらくはターミナルのままでいくことにしました。一番の理由は、モデルがあまりに速く進化していて、それに追いつけるフォームファクターが他にない と感じたからです。正直、これは「何を作るべきか」と私が悩んでいた中での結論で、過去 1 年 Claude Code のことしか考えてきませんでした。夜遅く、「モデルが進化し続けている。どうすれば追いつけるのか」と考え続けて、ターミナルが正直唯一思いついたアイデアでした。

B: リリース後、すぐに人気が出て Anthropic 社内でヒットになり、DAU は垂直に伸びました。

B: 2 月に外部リリースしました。あまり覚えられていませんが、Claude Code は外部リリース当初はヒットではなかったんです。すぐに飛びつくアーリーアダプターはいましたが、これが何なのかみんなが理解するのに何ヶ月もかかりました。あまりにも違うものだったからです。

「最初は人気がなかった」「ターミナルなのは消極的選択」というのは、後から見ると Claude Code 神話のように語られがちな部分の解像度を上げてくれます。

Boris の現在のワークフロー — 100% Claude Code、毎日 10〜30 個 PR

L: 現時点でコードの 100% が Claude Code で書かれている、というのが今のあなたのコーディング状況なんですね？

B: はい、私のコードの 100% は Claude Code で書かれています。私は結構コードを書く方で、Instagram にいた頃も生産性で上位数人の中に入っていました。Anthropic でもそれは変わっていません。毎日 10〜20〜30 個の Pull Request を ship しています。

L: 毎日。

B: 毎日です。

L: なんてこと。

B: 100% Claude Code で書かれていて、11 月以降 1 行も自分の手で編集していません。それがずっと続いています。

B: ただし、コードは見ています。完全にハンズオフにできる段階にはまだないと思います。特に多くの人がプログラムを動かしているなら、正しさを確認しないといけないし、安全性も確認しないといけない。それから Anthropic では全ての Pull Request に対して Claude が自動コードレビューをしています。100% の PR を Claude がレビューしている。その後にも人間のレビューレイヤーがあります。チェックポイントとしての人間の目はまだ持っておきたい。

B: ただし、どこにも動かない純粋なプロトタイプコードは別です。

「自分は手で書かないが、Claude が書いたものを Claude が一次レビューし、最後の砦として人間が見る」という三段ロケットになっているのは、自社運用としても参考になります。

次のフロンティア — Claude が「同僚」のようにアイデアを出し始める

L: 次のフロンティアは何でしょうか？コードの 100% が AI で書かれている。あなたのチームが既に動いている、あるいは向かう「ソフトウェアの書かれ方」の次の大きな変化は何ですか？

B: 今起きているのは、Claude がアイデアを出し始めている ことです。フィードバックを読み、バグレポートを見て、テレメトリを確認して、バグ修正や ship すべきもののアイデアを出してくる。少しずつ「同僚」のような振る舞いをし始めています。

B: 2 つ目は、コーディングから少し外側に広がり始めていることです。今やコーディングは大部分解決済みと言っていいと思います。少なくとも私がやる類のプログラミングは、Claude ができるので解決済みです。

B: それから一般的なタスクです。私自身、Cowork を毎日使ってコーディングと全く関係ないことをこなしています。例えば駐車違反の支払いを Cowork にやらせました。チームのプロジェクトマネジメントも全部 Cowork がやっています。スプレッドシート間のデータ同期、Slack やメールでのメッセージのやり取りとか、そういうこと全部。

L: 「何に取り組むべきか」を提案してくれるというアイデア、とても面白いです。これに Claude をどう使いますか？

B: 一番シンプルなのは、Claude Code か Cowork を開いて Slack スレッドに向けるだけ です。うちの場合、Claude Code に関する社内フィードバックが全部流れるチャンネルがあります。最初にリリースした 2024 年内から、ずっとフィードバックの噴水のようになっています。

B: 初期の頃の私は、誰かがフィードバックを送るたびに、出来る限り早く全部直していました。1 分以内、5 分以内とか。この超高速のフィードバックサイクルがあると、人はもっとフィードバックを出してくれるんです。「聞いてもらえている」と感じるから、めちゃくちゃ大事です。

B: 今も同じことをしていますが、Claude が多くを代行してくれます。チャンネルに Claude を向けると「これとこれができる、PR を 2 つ作ったから見て？」と言ってくる。「うん」と返す。

PM の聖杯だった「何を作るかを決める」が、Claude のフィードバック読解と組み合わさって溶け始めている、というのが個人的に一番ぞっとした部分でした。

異常な生産性向上 — Meta で何百人が 1 年かけて数 % だったものが、いま何百 %

B: 生産性向上の幅は本当に異常です。Anthropic では、Claude Code を導入してから過去 1 年で、エンジニアチームの規模を正確な数字は知らないけど 4 倍 くらいにしましたが、エンジニアあたりの生産性も 200% 上がっています。Pull Request 数で見て。開発者生産性の領域で実際働いたことがある人なら、この数字がどれだけ異常か分かるはずです。

B: 私は前職で Meta にいて、責任のひとつが会社全体のコード品質でした。Facebook、Instagram、WhatsApp、全コードベースが私の責任でした。当時見えていたのは、何百人ものエンジニアが 1 年取り組んで、数パーセントポイントの生産性向上を得る、というレベル感でした。今、何百パーセントポイントもの生産性向上が出ているのは、本当に絶対に異常です。

B: 同じくらい異常なのは、これがすっかり当たり前になっていることです。「ああ、AI が私たちにこれをしてくれてるんだね」みたいに数字を聞き流している。ソフトウェア開発、プロダクト作り、テックの世界に起きている変化の量は、本当に前例がないんです。

B: 慣れてしまうと簡単に普通に感じてしまいますが、これは本当にすごいことなんだと認識するのが大事です。たまに自分自身に思い出させなければならないことです。

数字の比較対象として「Meta の中でコード品質を見ていた人」自身が出してきた「何百人 × 1年 = 数 %」の話は、現場の感覚としてかなり重い裏取りです。

速さに慣れすぎる、という落とし穴 — メモリリーク事件

B: モデルの変化が速い分、ある種の欠点もあります。個人レベルで言えば、その一つはモデルがあまりに頻繁に変わるので、自分が古い考え方にとらわれてしまう ことがある、ということです。

B: 実際、チームに新しく入ってきた人や新卒のメンバーの方が、私よりずっと AGI 寄りのアプローチで物事を進めているのを見かけます。例えば、数ヶ月前にメモリリークがあった案件があって、これはつまり Claude Code のメモリ使用量がどんどん上がっていって最終的にクラッシュする、という話です。

B: 従来のやり方はヒープスナップショットを取って、専用のデバッガに読み込ませて、特殊なツールで何が起こっているかを把握する、というものです。私もそれをやっていて、トレースを眺めて何が起こっているのかを突き止めようとしていました。一方、新しく入ったエンジニアはただ Claude Code に「Claude、リークがあるみたいだから、原因を突き止めてくれる？」と頼んだだけなんです。

B: すると Claude Code は、私がやっていたのとまったく同じことをしました。ヒープスナップショットを取り、自分で解析できるよう小さなツールをその場で書いて、いわばジャストインタイムなプログラムを作り、問題を突き止めて、私より早くプルリクエストを上げたんです。

B: 長くモデルを使っている我々こそ、自分を「今この瞬間」に連れ戻して、古いモデルの感覚に縛られないようにしないといけません。もう Sonnet 3.5 ではなく、新しいモデルはまったく別物です。このマインドセットの転換がとても大きい。

L: あなたはチームのために特定の原則を明文化していて、新メンバーが入るとそれを共有していると聞きました。その一つが「自分でやるより Claude にやらせるほうがいい」だと思います。今のメモリリークの話はまさにそれですよね。

B: あらゆることに少しだけリソースを足りなくしておくと、面白いことが起きるんです。そうすると人は工夫せざるを得なくなる。Cowork でも、プロジェクトに一人だけエンジニアを置くと、本人がリリースを急ぎたいから猛烈な速さで出せる。これは内発的なモチベーションで、いいものを作りたい気持ちから来ます。

B: もう一つは、人にどんどんスピードを上げるよう促すことです。今日できることは今日やるべきだ、と。

「ベテランのほうが Claude を信用しきれず手を動かしてしまう」というアンチパターンは、自社で Claude を導入している人ほどぐさっと刺さる話だと思います。

エンジニアにはトークンを無制限に渡せ、最適化は後で

L: 「リソースをあえて足りなくする」という発想は面白いですね。一般には AI のおかげで従業員やエンジニアをそんなに抱えなくて済む、という感覚があります。

B: ええ。優秀なエンジニアを採れば、彼らは自力でやり方を見つけます。特に権限を与えてあげれば。これは CTO や色々な企業の人たちとよく話す話題です。私のアドバイスは「最初から最適化しようとしないこと、コスト削減から入らないこと」です。

B: まずはエンジニアにできるだけ多くのトークンを渡してあげる。Anthropic では今、全員が大量のトークンを使えますし、これを福利厚生として打ち出している企業も出てきていて、「入社すれば無制限にトークンが使えます」と謳っているところもあります。これは大いに推奨したいことで、これまで突拍子もないと思われていたアイデアを試す自由を与えてくれます。

B: うまくいくアイデアが見つかれば、そこからスケールさせる方法を考え、最適化やコスト削減に取り組めばいい。「Opus じゃなくて Haiku か Sonnet で十分かも」とかね。最初はとにかく大量のトークンを投入して、アイデアが機能するかを試して、エンジニアにその自由を与えるべきです。

L: 「Anthropic で働いているからそりゃそう言うよね」と思う人もいるかもしれません。

B: ええ。それに小規模なら巨額の請求が来るわけではない。個人のエンジニアが実験している分には、トークンコストは給料や事業運営の他のコストと比べて相対的に低いはずです。スケールが大きくなれば話は別で、例えば素晴らしいものが出来上がって大量のトークンを消費し、コストがそれなりに膨らんだら、そこで初めて最適化すればいい。あまり早く取り組みすぎないことです。

L: トークンコストが給与より高くなっている企業を見たことはありますか？

B: Anthropic でも、月に何十万ドル分もトークンを使うエンジニアが出始めています。少しずつそういう状況が見えてきていて、他社でも似たような事例を耳にし始めています。

「月に何十万ドルのトークンを使うエンジニアが既にいる」という具体的レンジがさらっと出てくるのは、生身の現場感としてかなり貴重な情報です。

コーディングは目的か手段か — TI83 でカンニングした少年時代から

L: コードを書くこと自体を恋しく思いますか？ソフトウェアエンジニアとしてコードを書かなくなることに寂しさはありますか？

B: 私の場合、面白いことに、エンジニアリングを学んだ動機はとても実用的だったんです。物作りのために学んだ。独学でした。学校では経済学を専攻していて、CS は専攻していませんが、早い時期に独学でエンジニアリングを身につけたんです。中学生ぐらいからプログラミングをしていて、最初からずっと実用一辺倒でした。

B: 最初に学んだのは数学のテストでカンニングするためです。当時グラフ電卓があって、答えを電卓に仕込んでおく、という。

L: TI83 ですね。

B: TI83 Plus です。そうそう（笑）。で、翌年のテストになると、もう難しすぎて、問題が分からないから全部の答えを仕込めない。だから 小さなソルバーを書いたんです。代数の問題を解いてくれるプログラム です。さらに、ケーブルがあればクラスメートにプログラムを配れることに気づいて、クラス全員で A を取った。でもバレて、先生に「やめなさい」と言われました。

B: 最初からプログラミングは私にとってとても実用的なもので、物を作るための手段でした。それ自体が目的ではない。ただ一時期、プログラミングそのものの美しさにのめり込みました。TypeScript の本を書いたし、当時世界最大の TypeScript ミートアップを始めたりもしました。言語そのものに惚れ込んだからです。関数型プログラミングなどにも深く入っていきました。

B: 多くのコーダーはこれに気を取られると思います。でもそれが目的ではない。私にとってコーディングはあくまでツールで、何かを成し遂げる手段なんです。

B: ただ、誰もがそう感じるわけではありません。例えば チームのリーナというエンジニアは、週末でも手で C++ を書いている。彼女は手書きで C++ を書くこと自体が本当に楽しいんです。人それぞれですし、この分野が変わっても、すべてが変わっても、こうした楽しみ方の余地は常にある。芸術として楽しむ余地、手作業でやる余地は、やりたければいつでもある。

L: エンジニアとしてのスキルが衰えていくことは心配ですか？

B: そういう流れだと思っているので、個人的にはあまり気にしていません。プログラミングは連続体だと捉えていて、そもそもソフトウェアって意外と新しい概念なんです。今日のように仮想マシン上で動くプログラムを書くようになったのは、たぶん 1960 年代以降で、せいぜい 60 年ほどの歴史。それ以前はパンチカード、その前はスイッチ、その前はハードウェアそのもの、さらに前は紙とペン、紙の上で計算する人間で部屋が埋まっていた。プログラミングはずっと変わり続けてきたんです。

「TI83 でカンニングした少年が TypeScript の本を書き、いま AI でコードを書かない」という流れ自体が、彼が何度言葉を変えながら続けて言っている「プログラミングはずっと変わり続けてきた」の一番強い証拠になっています。

活版印刷のアナロジー — 写字生は活版印刷を歓迎していた

B: これに合う歴史的な類似例は何だろう、とよく考えます。一番近いと感じるのは活版印刷です。

B: 1400 年代半ばのヨーロッパでは識字率が非常に低くて、人口の 1% にも満たなかった。書き仕事を担っていたのは写字生で、彼らはしばしば自身が読み書きのできない領主や王に雇われていて、ごくわずかな人々が「読み書き」という仕事を独占していました。そこに登場したのがグーテンベルクと活版印刷です。

B: 印刷物の量は跳ね上がり、コストは次の 50 年で 100 分の 1 ほどに下がりました。識字率の上昇には時間がかかりました。読み書きを学ぶのは難しいし、教育制度や自由時間が必要で、一日中農作業をしなくていいだけの余裕がいる。それでも、その後 200 年で世界の識字率は約 70% にまで上がった。同じような転換が起きるんじゃないかと考えています。

B: そして興味深い歴史資料があります。1400 年代の写字生にインタビューしたもので「活版印刷をどう感じる？」と聞かれた写字生は、むしろ大歓迎だったんです。「自分がやりたくないのは本の写本作業で、やりたいのは挿絵を描くことや製本だ。これからはその時間ができて嬉しい」と。

B: エンジニアとして私自身、それと並行性のあることを感じます。コーディングの退屈な部分、つまり細かい作業をしなくて済むようになった。それはずっと細部の話で、git をいじったり、いろんなツールを行き来したり、そういうのは楽しい部分じゃなかった。楽しいのは「何を作るか」を考える部分、ユーザーと話すこと、大きなシステムについて考えること、未来について考えること、チームの仲間と協働することです。今はそれをもっとできるようになっています。

L: 素晴らしいのは、あなたが作っているツールのおかげで、誰でもこれができるようになっている点ですね。今は「これ教えて」と言えば、ステップ 1、2、3、4、はい解決、と教えてくれる。

B: 今日もあるエンジニアと話していて、彼は Go でサービスを書いていて、もう 1 ヶ月近く取り組んでいて、サービスもしっかり動いている。「書いてみてどう？」と聞いたら、「正直まだ Go はあんまり分かっていないんだよね（笑）」って。こういう例はこれからどんどん増えると思います。正しく効率的に動くと分かっているなら、細部までは知らなくていいわけです。

「写字生は活版印刷を歓迎していた」という史実、知らなかった人も多いはずです。AI コーディングへの感情を整理する際の、一番きれいなフレームワークだと思います。

次に AI に呑まれる職種、エージェント時代の幕開け

L: 次に AI に最も影響を受ける職種はどれだと思いますか？

B: エンジニアリングに隣接する職種が大きく影響を受けると思います。プロダクトマネージャー、デザイン、データサイエンスなど。コンピュータでできる仕事ならほぼ何でも対象になります。

B: 一方、非エンジニアリング的な仕事や、プロダクトのような半技術的な仕事、データサイエンスなどの領域で人々が使っている AI は今のところ会話型 AI、つまりチャットボットばかりです。誰もエージェントを使ったことがない。

B: 「エージェント」という言葉も乱用されすぎて意味を失いつつありますが、技術的にはとても明確な意味があって、ツールを使える AI、つまりツールを使える LLM のことです。喋るだけでなく、実際に行動でき、システムと相互作用できる。例えば Google ドキュメントを操作したり、メールを送ったり、コンピュータでコマンドを実行したり、いろんなことができる。

B: だから、コンピュータのツールを使う仕事はすべて次のターゲットだと思います。これは社会としても、業界としても考えていかないといけないテーマです。

L: 「ジェヴォンズのパラドックス」というものがありますよね。「できることが増えると、人をもっと雇うことになる」と。

B: ええ、うちのチームは採用しています。Claude Code チームは絶賛採用中です。個人的には、このすべてのおかげで仕事がずっと楽しくなりました。コーディングがこんなに楽しいと思ったことはないというくらいです。

B: ただ、これがどう転がっていくかは予測しにくい。だからこそ歴史的類似例に頼ってしまう。少数の人にしかなかった「読み書き」の技術が、すべての人に開放された。本質的に民主化を促した。誰もができるようになって、ルネサンスのような出来事が起こり得た。

B: 何が起きるかは分かりません。ただ、その移行の途中ではかなり破壊的で、多くの人にとって痛みを伴うものになると思います。やはり社会全体で議論しともに解決していくべきテーマです。

「エージェント = ツールを使える LLM」のシンプルな定義は、社内の非エンジニアに何を期待していいか説明する時にそのまま使える、と思いました。

ジェネラリスト時代 — エンジニア・PM・デザイナーの境界はどうなる

L: このカオスな時代に成功したい、生き残りたいと思って聞いている人にアドバイスはありますか？

B: 基本的には、ツールを使い倒し、よく知り、恐れないこと。飛び込んで、試して、最先端のさらに先を行くこと。

B: もう一つアドバイスするなら、これまで以上にジェネラリストを目指すこと。例えば学校で CS を学んだ人は、コーディングを学ぶだけで、それ以外をあまり学ばないことが多いですよね。私が日々一緒に働く中で最も成果を出しているエンジニアやプロダクトマネージャーは、専門分野を横断する人たちです。

B: Claude Code チームでは全員がコードを書きます。プロダクトマネージャーも、エンジニアリングマネージャーも、デザイナーも、ファイナンス担当も、データサイエンティストも、全員コードを書きます。さらに個々のエンジニアを見ても、専門分野をまたいで活動している人が多い。

B: 最強クラスのエンジニアは、プロダクトとインフラのハイブリッドだったり、デザインセンスに優れていてデザインもこなせるプロダクトエンジニアだったり、ビジネス感覚に優れていてそれを次の打ち手の判断に使える人だったり、ユーザーと話すのが本当に好きで、ユーザーのニーズをそのまま吸収して次に作るものを決められるエンジニアだったり。

L: エンジニアリング、デザイン、プロダクトマネジメントという三つの職種で分けて考えるのは、まだチーム作りで有効だと感じますか？

B: 短期的には残ると思います。ただ、この三つの役割には 50% くらいの重なりが出てきていて、実際には同じことをしている部分が多くて、それぞれ少しずつ得意分野がある、という状態です。

B: 今年の終わりごろには、これらの境界がさらに曖昧になっていくと思います。「ソフトウェアエンジニア」という肩書きが消えて「ビルダー」に置き換わる場所もあれば、全員がプロダクトマネージャーで全員コードを書く、そんな組織も出てくるかもしれません。

「ビルダー」という単語は、これから組織図を書き直すときの新しいラベル候補としてかなり強そうです。

潜在需要（latent demand）という最強のプロダクト原則

L: 「潜在需要を解放したときに何が起こるのか」を説明してください。

B: 潜在需要というのは、プロダクトを設計時の意図とは違う形でハック的に、あるいはちょっと誤用されるような形で使えるように作っておくと、ユーザーが本当にやりたいことが見えてきて、プロダクトを次にどこへ持っていくべきかがわかる、という考え方です。

B: 例えば Facebook マーケットプレイス。Facebook グループ内の投稿の 40% が物の売買だったんです。これはすごいことで、要するにみんな Facebook グループプロダクトを濫用して物を売り買いしていたわけです。だから、もっと売買がしやすいプロダクトを作れば、みんな絶対に気に入るというのは明白でした。

B: Facebook Dating も似たようなところから始まったと思います。Facebook 上で互いのプロフィールを見ている人の 60% が、友達ではなくて異性同士だったんです。要するに、伝統的な出会い系の構図で互いを覗き見していた、ということ。

B: 例えば Cowork もここから生まれました。ここ半年くらい、Claude Code を使っている人の多くがコーディング以外の用途で使っているのを見てきました。Twitter で、Claude Code でトマトを育てている人がいたり、ゲノムを解析している人がいたり、壊れたハードディスクから写真を復元している人もいました。MRI の解析に使っていた人もいたと思います。

B: これに気づいたのは結構早くて、去年の 5 月くらいでした。オフィスに入ると、データサイエンティストの Brendan が自分の PC で Claude Code を使っていて、ターミナルを開いていた。びっくりしました。「Brendan、何やってるの？ターミナルの開き方を覚えたの？」って。彼はターミナルの使い方を覚えて、Node.js をダウンロードして、Claude Code をダウンロードして、ターミナル上で SQL 分析をしていたんです。すごいことだと思いました。翌週には、データサイエンティスト全員が同じことをしていました。

B: 潜在需要には興味深いもう一つの側面があります。従来のフレーミングは「人々がやっていることを観察して、それを少し楽にしてエンパワーする」というものでした。ここ半年で見えてきた現代的なフレーミングは少し違って、「モデルがやろうとしていることを観察して、それを少し楽にする」というものです。

B: Claude Code を最初に作り始めた頃、LLM で何かを設計するときの一般的なやり方は、モデルを箱に閉じ込める発想でした。「これがアプリで、これがやりたいこと。モデル、君はこの一部分だけやってくれ」という具合に。Claude Code では、これを逆転させたんです。「プロダクトとはモデルそのものだ」と。モデルを露出させ、最小限の足場だけ周りに置く。最小限のツールセットだけ与える。そうすれば、モデルが自分でいろいろできる。

B: 研究の世界ではこれを「on distribution（分布内にいる）」と呼びます。モデルが何をしようとしているかを見たい。プロダクト用語で言えば、潜在需要というのは全く同じ概念をモデルに当てはめたものです。

「ユーザーの潜在需要」だけでなく「モデルの潜在需要」までフレームワーク化しているのが、ここ最近の AI プロダクトデザインで一番効いている話だと思いました。

Cowork はなぜ 10 日で作れたのか

L: Cowork の話で、ローンチ時に話されていたと思いますが、チームが 10 日で作ったというのが。

B: イカれてますよね。

L: リリースして、すぐに数百万人のユーザーに使われるようになったプロダクトを 10 日で作ったって。「Claude Code で作っただけだよ」以外に。

B: Claude Code はリリース当初すぐにヒットしたわけじゃないんです。時間をかけてヒットになりました。いくつか変曲点があって、一つは Opus 4。これで本当に大きく伸びました。それから 11 月にもう一段、そしてその後もずっと伸び続けています。

B: Cowork はリリースした瞬間からヒットしました。Claude Code の初期よりずっと早かった。これは正直なところ、Felix、Sam、Jenny、それを作ったチームの功績が大きいです。

B: Cowork がどこから来たかというと、これも潜在需要から。Claude Code を非技術的な用途で使っている人を見て、何を作るべきか考えていました。数ヶ月チームでいろいろな選択肢を試して、最終的に 誰かが「Claude Code をそのままデスクトップアプリに入れたらどうか」と言ったんです。それが本質的に機能した。10 日で Claude Code をフル活用して作りました。

B: Cowork には実はかなり高度なセキュリティシステムが組み込まれていて、モデルが暴走しないようにするガードレールがあります。例えば、仮想マシンを丸ごと同梱しているんです。そのコードは Claude Code が全部書きました。

B: 早めに出しました。まだかなり粗削りで、今でも荒削りなところはあります。でもこれが私たちの学び方なんです。プロダクト面でも安全性面でも、思っているより少し早めにリリースしないと、フィードバックを得られないし、ユーザーと話せない。何が求められているかを理解できない。

「10 日でローンチ」を成立させているのは Claude Code 自身、というのは Anthropic の自己食い（dogfooding）の極致のような話で気持ちがいいです。

Anthropic の 3 層の安全性アプローチ

B: Anthropic は安全性の研究所なので、もう一つの側面が安全性です。モデルの安全性を考えるには、いろいろなレベルがあります。

B: 最も低いレベルがアラインメントとメカニスティック・インタプリタビリティ。これはモデルを学習させる時に、安全になっているかを確かめるレベル。今では神経細胞レベルで何が起きているかを追跡する、かなり高度な技術があります。例えば、欺瞞に関連するニューロンがあれば、それをモニタリングして発火を検知できるところまで来ています。

B: 2 つ目のレイヤーが eval。これは要するに実験室のセッティングで、モデルをペトリ皿に入れて研究するイメージ。合成された状況に置いて、「モデル、どうする？正しい行動を取るか？アラインしているか？安全か？」と確かめる。

B: 3 つ目のレイヤーは、モデルが実環境でどう振る舞うかを見ること。モデルが高度になるほど、ここが重要になります。最初の 2 つのレイヤーでは良く見えても、3 つ目では良くないかもしれない。

B: Claude Code をかなり早めにリリースしたのは、安全性を研究したかったから。実際 Anthropic 社内で 4〜5 ヶ月くらい使ってからリリースしました。当時、これが最初の本格的なエージェントだったし、少なくとも広く使われるコーディングエージェントとしては最初だったので、安全かどうか確信が持てなかった。

B: 基本的な考え方は、脳とは何か、ということです。要するにニューロンが繋がっているもの。驚くべきことに、これがモデルにもかなり当てはまるんです。モデルのニューロンは動物のニューロンとは違いますが、多くの点で似た振る舞いをします。

B: 少し前までは、モデルは単に次のトークンを予測しているだけなのか、それとももう少し深いことをしているのかが分かりませんでした。今ではかなり強い証拠で、もう少し深いことをしているとわかっています。1 つのニューロンが十数個の概念に対応していたりする。他のニューロンと一緒に発火することで、より高度な概念を表現する。これを「重ね合わせ（superposition）」と呼びます。

B: これは Claude Code でも同じで、社内では「race to the top（頂点への競争）」と呼んでいます。Claude Code で言えば、オープンソースのサンドボックスをリリースしました。エージェントを実行する際のサンドボックスで、一定の境界を設けてシステム全体にアクセスできないようにするもの。これをオープンソースにして、Claude Code に限らず任意のエージェントで動くようにしました。他のチームも同じことを簡単にできるように、というのが狙いです。

「アラインメント → eval → 実環境」の 3 層は、自分のチームに AI 製品の安全性を整理して話すときの背骨として、そのまま使えるフレームです。

Claude Code を使いこなすプロのコツ — 最強モデル・plan mode・bitter lesson

L: AI プロダクトを作る上で、Claude Code を初めて使う人、あるいはすでに使っていてもっと使いこなしたい人へのコツは何かありますか。

B: 一つ前置きをすると、Claude Code には「これが正解」という使い方は存在しません。コツはお伝えできますが、これは開発者向けツールです。開発者は人それぞれで、好みも環境も違います。だから使い方も無限にあって、唯一の正解はないんです。

B: 1 つ目は、とにかく一番性能の高いモデルを使うこと。今だと Opus 4.6 です。私は常に maximum effort を有効にしています。

B: よく起きるのが、Sonnet など安いモデルを使おうとするケースです。でもモデルの知能が低いぶん、結局同じタスクをこなすのにかかるトークン数が多くなってしまう。だから安いモデルを使ったほうが安いとは限りません。むしろ最高性能のモデルを使ったほうが、修正も少なくて済むし、手取り足取り教える必要もないので、ずっと速く同じことをこなせて、結果的に安く、トークンも少なく済むことが多いです。

B: 2 つ目は plan mode を使うこと です。私は 8 割方のタスクを plan mode から始めます。plan mode の仕組みは実はとてもシンプルで、モデルのプロンプトに「まだコードを書かないでください」という 1 文を差し込むだけです。それだけです。

B: ターミナルを使っている方は Shift+Tab を 2 回押せば plan mode に入れます。デスクトップアプリの方は小さなボタンがあります。Web 版にも小さなボタンがあります。Slack 連携にも先日追加しました。

B: これが 2 つ目です。plan mode ではモデルがあなたと往復しながら計画を詰めていきます。計画が良さそうに見えたら、モデルに実行させます。私はその後 edit を auto accept にしています。なぜなら計画さえまともなら、Opus 4.6 はほぼ毎回ワンショットで一発で正しく書き上げてくれるからです。

B: 3 つ目のコツは、いろいろなインターフェースを試してみること です。ターミナルである必要はありません。どこで動かしても同じ Claude エージェントが動いています。

それから AI プロダクトを作る側のアドバイスとして、Boris は 2 つの強い原則を出しています。

B: 1 つは、モデルを箱に閉じ込めようとしないこと。多くの人がモデルの上に何かを構築するときの本能として、モデルを非常に特定の方法で振る舞わせようとします。例えば、モデルにすごく厳格なワークフローを重ねる人がいて、「ステップ 1 をやって、次にステップ 2、次にステップ 3」と、すごく凝ったオーケストレーターでこれをやらせる。でも実際には、ほとんどの場合、モデルにツールを渡してゴールを与え、自分で考えさせた方が良い結果になります。

B: 2 つ目は、「the bitter lesson（苦い教訓）」です。Claude Code チームでは、これを必読としています。Rich Sutton が 10 年くらい前に書いたブログ記事で、彼の主張は、より汎用的なモデルが、より特化したモデルに常に勝つ、というもの。

B: 私にとって最大のものは、長期的には常に汎用モデルに賭けろ、ということ。小さなモデルを使ったり、ファインチューニングしたり、そういう小細工をしないこと。私たちが見てきた限り、足場でせいぜい 10〜20% くらいパフォーマンスが上がるかもしれませんが、たいていその上乗せ分は次のモデルで吹き飛んでしまう。だったら次のモデルを待った方がいいくらいだ。

B: 最後の原則かもしれないが、Claude Code が結果的に正解だったと思うことがある。最初から、6 ヶ月後のモデル向けに作ることに賭けたのだ。今日のモデルにではなく。

B: これを最初に目にしたのが Opus 4 と Sonnet 4 の時で、Opus 4 は 5 月にリリースした最初の ASL3 クラスのモデルだった。みんなが初めて Claude Code を使うようになり、変曲点を迎えたのだ。

B: これは多くの方、特にスタートアップを作っている人たちによくお伝えするアドバイスなのだが、最初の半年間はプロダクトマーケットフィットがあまり良くなくて、不安に感じるはず。でも、6 ヶ月先のモデルを想定して作っておけば、そのモデルが出た瞬間に走り出せて、プロダクトがハマって動き始める。

「Opus 一択 + plan mode + bitter lesson + 6 ヶ月先のモデルに賭ける」は、Claude Code を業務で本気で使い倒したい人がそのままチートシートにできる組み合わせだと思います。

AGI 後のプラン — 味噌作りと長い時間軸

L: Anthropic の共同創業者の Ben Mann と話したのですが、彼があなたに聞きたかった質問の一つが、「AGI 後のプランは何か」です。AGI に到達したあと、あなたは何をしていると思いますか。

B: Anthropic に入る前、私は実は日本の田舎に住んでいました。そこは全然違うライフスタイルでした。町で唯一のエンジニアで、町で唯一の英語話者でした。週に何度か自転車でファーマーズマーケットに行ったりしていました。田んぼの脇を自転車で走るんです。サンフランシスコとは完全に正反対の、まったく違うペースの世界でした。

B: 私が本当に気に入っていたのは、ご近所さんと知り合って友情を築く方法が、漬物の交換だったことです。

B: その町ではみんな味噌を作っていて、みんな漬物を作っていました。私もそれなりに味噌作りが上手くなって、何バッチも仕込みました。今でも作っています。味噌は面白いもので、こういう長い時間軸で考える力を鍛えてくれます。

B: エンジニアリングとはまったく違うんです。白味噌のバッチでも最低 3 ヶ月、赤味噌だと 2、3、4 年かかります。とにかく辛抱強くなるしかない。混ぜて、寝かせて、ただ待つ。本当にひたすら忍耐です。

B: 私がこれを愛しているのは、こうした長い時間軸で考えられるからなんです。だから AGI 後、あるいは Anthropic にいなかったとしたら、私はおそらく味噌を作っていると思います。（笑）

L: その答え、最高です。

最後に、Boris は最終メッセージとして次のように締めました。

B: Anthropic では創業以来、コーディングから始めて、ツール使用に進み、コンピュータ使用へと進む という考え方をずっと持ち続けてきました。これがモデルが発展していく道筋であり、私たちがモデルを構築していきたい道筋なんです。そしてこれは、安全性について最もよく学び、研究し、改善できる道筋でもあります。

B: 今、Claude Code が数十億ドル規模の巨大事業になっていて、私の友人がみんな Claude Code を使っていて常に Claude Code についてメッセージを送ってくる、みたいな状況は、ある意味では完全に予想外なんです。私たちはこれがそのプロダクトになるとは思っていなかったし、ターミナルから始まるとも思っていませんでした。

B: それと同時に、まだ非常に早い段階だとも感じます。世界の大部分はまだ Claude Code を使っていません。世界の大部分はまだ AI を使っていません。だからまだ全行程の 1% という感覚で、これからやるべきことが本当にたくさんあります。

L: Claude Code 単独で 20 億ドルの売上 があるんですよね。Anthropic 全体だと、150 億ドルの売上です。それでもまだこんなに早い段階で、こうした数字が出てきていると考えると、本当にすごいです。

「Claude Code 20 億ドルでもまだ全行程の 1%」というスケール感の桁ずれは、最後にもう一度殴ってもらえる感じで気持ちよかったです。

まとめにかえて

今回の Lenny's Podcast 回は、Claude Code 1 周年というタイミングで、Boris 自身の現場の解像度がかなり高い形で言葉になっていました。要点を 3 層に整理しておきます。

まずは「現場で何が起きているか」のレイヤー。Boris 自身が 11 月以降 1 行も自分で書いていない こと、毎日 10〜30 個 PR を ship している こと、Anthropic 社内のエンジニア生産性が 200% 向上 し、しかもチーム規模が 4 倍 になっていることが、何より一次情報として強い。GitHub の 4% が Claude Code 製 という外部統計もこれと符合します。

次に「Claude Code の作り方」のレイヤー。ターミナルから始めたのは消極的選択、最初は 「いいね 2 個」のローンチ、ヒットしたのは Opus 4 以降、Cowork は 10 日で作って仮想マシンごと Claude Code に書かせた、という個別の事実の積み重ねが面白い。背後にあるのは 「最初は意図的にリソースを少なめに」「6 ヶ月先のモデルに賭ける」「箱に閉じ込めず、潜在需要をモデル側にも当てはめる」「bitter lesson に従って汎用モデルに賭ける」 といった、組織の原則として明文化された設計思想です。

最後に「ここから先どうなるか」のレイヤー。コーディングはほぼ解決済み、次に来るのは エージェント時代 で、PM・デザイン・データサイエンスから順に AI に呑まれ、肩書きは 「ビルダー」 に置き換わっていく。求められるのは AI ネイティブで好奇心旺盛なジェネラリスト。生き残り戦略はシンプルで、ツールを使い倒して恐れず最先端の先に行く こと。プロのコツは Opus 一択・plan mode・複数インターフェース に集約されます。そして AGI の先には味噌があると。

この回はどのレイヤーから読んでも刺激的でしたが、個人的には 「メモリリーク事件」 と 「写字生は活版印刷を歓迎していた」 の 2 つを心に置いておきたいと思います。前者は「ベテランほど Claude を信じきれない」というアンチパターンの確認、後者は「やりたくない作業から解放される」という活版印刷モデルでの未来予測。両方とも、自分が AI ツールに対する態度を組み直すときに、何度でも引っ張り出せる軸だと感じました。

参考

• Lenny's Podcast: Boris Cherny 出演回（YouTube、1時間27分45秒） — 本記事の素材となった Lenny Rachitsky と Boris Cherny の対談本編