ボリス・チャーニーが語るClaude Codeの1年目と、コーディングの次に来るもの

レニーはまず、覚えている人の少ないある出来事について尋ねた。収録の約6か月前、チャーニーはAnthropicを離れてCursorに移り、2週間後に戻ってきた。チャーニーはこれを「これまでで最速の転職」と呼んだ。Cursorに入ったのは、製品の大ファンで、チームにも感銘を受けていたからだ。多くの人より先にAIコーディングの行く末を見抜いていたとチャーニーは言い、今でも素晴らしいチームだと思っているという。

ところが、移ってすぐに、自分が恋しく思っているのはAnthropicのミッションだと気づいたとチャーニーは語った。そもそもAnthropicに惹かれたのもそのミッションだった。大手テック企業で働いた後、AIラボで働き、「私たちが作っているこのとんでもないもの」の形づくりに関わりたいと考えていた。とりわけAnthropicに惹かれたのは、安全性を重視している点だった。廊下で誰かを呼び止めて、なぜここにいるのかと尋ねれば、答えは必ず安全性だという。チャーニーは、ミッションに突き動かされていることが、自分が幸せでいるために個人的に必要なものだと説明した。どれほど刺激的な仕事であっても、たとえ素晴らしい製品を作ることであっても、その代わりにはならなかった。

レニーは、公開されているGitHubのコミットの4%が現在Claude Codeによって書かれており、年末までには全コミットの5分の1に達する見込みだとするSemiAnalysisのレポートを紹介した。また、収録当日に出たSpotifyに関する見出しにも触れた。同社の最も優秀な開発者たちが12月以来コードを1行も書いていない、という内容だ。チャーニーは、4%という数字は想像をはるかに上回るものだったと語った。これは公開コミットだけを数えたものなので、Anthropicとしてはプライベートリポジトリでの割合は「かなり高い」と考えているという。チャーニーが最も驚いたのは現在の水準ではなく、そのペースだった。どの指標で見ても、Claude Codeの成長率はいまだに加速し続けているという。レニーの冒頭の紹介でも、デイリーアクティブユーザー数がこの1か月で倍増したことに触れられていた。

対談の終盤、レニーは自身が目にした売上の数字を持ち出した。Claude Codeがおよそ20億ドル、Anthropic全体では約150億ドルというものだ。チャーニーはClaude Codeを「数十億ドル規模のビジネス」と呼び、今では友人がみなClaude Codeのことでメッセージを送ってくると話した。それでも、今はまだ初期段階だと言う。世界の大半の人はまだClaude Codeも、そもそもAIも使っていない。だからチャーニーには「まだ1%しか終わっていない」ように感じられるのだという。

チャーニーは、Claude Codeの起源をAnthropicの長期的なテーゼの中に位置づけた。同社はある軌道に沿ってモデルを作っているという。まずコーディングが非常に得意になり、次にツールの使用、そしてコンピューターの操作へと進む。チャーニーが最初に加わったチームであるAnthropic Labsは、Claude Code、MCP、デスクトップアプリを生み出した。最近、マイク・クリーガーとベン・マンがこのチームを「第2ラウンド」として再始動させたという。チャーニーはこのテーゼを安全性と結びつけた。AIの能力が高まるにつれ、AIは単なる会話の相手ではなくなり、現実の世界で行動し始める。エンジニアにとって、その変化はこの1年で起きた。Coworkによって、非技術系のユーザーも同じ移行を経験しつつあるとチャーニーは見ている。その中には、たとえばGmailやSlackの中で実際に行動するAIを初めて使う人もいる。

入社当初、チャーニーは1か月かけて「奇妙なプロトタイプ」を作った。そのほとんどはリリースに近づくことすらなかったが、目的はモデルにできることの境界を知ることだった。その後さらに1か月、ポストトレーニングの仕事をして研究側の理解を深めた。チャーニーの考えでは、優れたエンジニアリングには、自分が作業しているレイヤーの「一つ下のレイヤー」を理解することが必要だ。従来のプロダクト開発では、そのレイヤーはランタイムや言語、仮想マシンだった。AIでは、それがモデルにあたる。

最初のバージョンはClaude CLIという名前だった。チャーニーが録画したデモでは、いくつかのツールを使う様子が示されていた。衝撃を受けたのは、bashツールを与えて自分が何の音楽を聴いているかを尋ねたところ、モデルがそれを調べるためのコードを書いたことだった。その目的のためにツールをどう使うかは指示していなかった。社内でプロトタイプを発表したとき、その投稿についた「いいね」は2つだけだった。コーディングツールといえば高度なIDEのことだったので、ターミナルベースのコーディングツールなどあり得ないと思われたのだろうとチャーニーは考えている。

ターミナルを選んだのは、当初は壮大な設計判断ではなかった。最初の数か月はチャーニーが一人で取り組んでおり、ターミナルが単に一番作りやすかったのだ。チャーニーはここからプロダクトの教訓を引き出している。最初はリソースを少し足りないくらいにしておけ、というものだ。その後、チームが別の形態を検討した際には、意図的にターミナルにとどまった。モデルの進化があまりに速く、それについていける別のインターフェースを思いつけなかったからだ。チャーニーは、正直なところ、そのことを考えて眠れない夜を何度も過ごした中で、思いついたアイデアはターミナルだけだったと語った。

社内ではすぐに広まった。ベン・マンに背中を押されてリリース前にデイリーアクティブユーザーのグラフを作ったところ、ほぼ即座に「垂直に伸びた」。2月の外部向けリリースは事情が違った。チャーニーは、Claude Codeが世間ですぐにヒットしたわけではないことを強調した。アーリーアダプターはすぐに理解したが、大半の人がそれが何なのかを理解するまでには何か月もかかった。ターミナルであることが「少し異質」に感じさせたため、ユーザーは心を開いて使い方を学ぶ必要があったのだとチャーニーは考えている。今ではiOSとAndroidのアプリ、デスクトップアプリ、Webサイト、そしてSlackやGitHubなどの連携機能でも動いており、より馴染みのある場所で使えるようになっている。チャーニーはこの経験全体を、謙虚な気持ちにさせられるものだったと表現した。「私たちの誰も、自分が何をしているのか本当にはわかっていない」のであり、ユーザーのフィードバックこそがチームにとって最良のシグナルなのだという。

チャーニーは、Anthropicが指数関数で物事を考える様子を説明した。共同創業者のうち3人が、スケーリング則の論文の筆頭から3人目までの著者だったことにも触れた。2025年5月の開発者カンファレンス「Code with Claude」で、チャーニーは年末の予測を尋ねられた。年末までには、コーディングにIDEが必要なくなっているかもしれないと答えた。会場から息をのむ音がはっきり聞こえたのを覚えているという。チャーニーがしたのは、Claudeが書くコードの量の線をたどることだけだった。その線を延ばしていくと、「直感とまったく合わないとしても」、年末までに100%を超えていた。

チャーニー自身の数字もその曲線をたどった。2月の時点では、Claude Codeが書いていたのは自分のコードの20%程度だった。5月には約30%で、仕事の大部分ではまだCursorを使っていた。そして11月に100%を超えた。ごく初期の頃から「何かをつかみかけている」感覚はあったが、それが何なのかははっきりしなかったという。毎晩、毎週末それをいじり続け、妻の支えがあったことにも感謝を述べた。イノベーションについてのチャーニーの考えは、無理に生み出すことはできず、ロードマップも存在しないというものだ。アイデアの80%が悪いものでも構わないのだから、人には失敗できる心理的安全性が必要だ。同時に、悪いアイデアに投資し続けるのではなく、見切りをつけて先に進むよう、十分な責任を負わされることも必要だという。

チャーニーは、自分はInstagramで最も多くのコードを書いたエンジニアの一人であり、チームを率いている今もAnthropicでそうだと話した。1日に10、20、あるいは30ほどのプルリクエストを出しており、すべてClaude Codeが書いたものだ。コードは今も読んでいる。特に多くの人が使うソフトウェアでは、正しさと安全性をまだ検証する必要があるため、完全に手放しにできる人はまだいないとチャーニーは考えている。Anthropicでは、どこでも実行されない純粋なプロトタイプのコードを除き、プルリクエストの100%をClaudeがレビューし、その後に人間によるレビューの層がある。

チャーニーは普段、複数のエージェントを走らせている。収録中も5つほどが動いていたという。その日の朝、最初にしたのはClaudeのiOSアプリを開き、前日に書いたコードをエージェントに再確認させることだった(コードは正しかった)。今ではコーディングの作業が、ターミナル、デスクトップアプリ、iOSアプリにおよそ3分の1ずつ分かれている。2026年にそんなふうにコーディングしているとは予想していなかったという。エージェントが詰まって待機しているときに不安を感じる人もいるという話を振られると、常にエージェントを走らせているので、そういう不安は特に感じたことがないと答えた。

AIがすべてのコードを書くようになった後に何が来るのかと問われ、チャーニーは2つの答えを挙げた。1つ目は、Claudeがアイデアを出し始めていることだ。フィードバックやバグ報告、テレメトリーを読み、バグ修正やリリースすべきものを提案する。これによってClaudeは「少し同僚に近い存在」になる。2つ目は、仕事がコーディング以外にも広がりつつあることだ。少なくとも自分が手がけるプログラミングについては、コーディングは「事実上解決された」とチャーニーは言う。今後数か月のうちに、業界全体で、あらゆるコードベースや技術スタックについて、ますます解決された状態になっていくと予想している。

アイデア出しのためのチャーニーのやり方はシンプルだ。Claude CodeやCoworkにSlackのスレッドを読ませるのである。チームにはClaude Code用の社内フィードバックチャンネルがあり、2024年の社内リリース以来、情報が「洪水のように」押し寄せている。初期の頃、チャーニーはすべてのフィードバックをできる限り速く、多くの場合1分から5分以内に修正していた。そのスピードのおかげで、人々はフィードバックがブラックホールに消えていくのではなく、ちゃんと聞いてもらえていると感じ、さらにフィードバックが集まったのだとチャーニーは考えている。今ではその作業の多くをClaudeがこなしている。チャンネルを読み、自分にできることを列挙し、すでにチャーニーがレビューするためのPRもいくつか出している。

チャーニーによれば、モデルはこの点で大きく進歩した。その一部はコーディングに特化したトレーニングによるもので、チャーニーはOpus 4.6を「信じられないほどすごい」と称賛した。さらに、コーディング以外のトレーニングも転移するという。生産性については次のような数字を挙げた。Claude Codeの導入以来、Anthropicのエンジニアリングチームはおそらく4倍ほどに増え(正確な数字はわからないとのこと)、プルリクエストで測ったエンジニア1人あたりの生産性は200%向上した。チャーニーはこれを、以前在籍していたMetaでの仕事と比べた。そこではFacebook、Instagram、WhatsAppなどのコードベース全体のコード品質を担当していた。Metaでは、数百人のエンジニアが1年かけて取り組んでも、数パーセントポイントの改善にしかならないこともあった。数百パーセントの向上を目の当たりにするのは「まったくとんでもないこと」だという。

チャーニーは、この速いペースがもたらす個人的なマイナス面を1つ挙げた。モデルがあまりに頻繁に変わるため、ときどき古い考え方にとらわれてしまい、新しく入った人や新卒のほうが自分よりも「AGI寄り」のやり方で仕事をしていることがあるという。数か月前、Claude Codeにメモリリークがあった。チャーニーは伝統的なやり方をとった。ヒープスナップショットを取り、デバッガーに読み込み、トレースをじっくり調べたのだ。一方、もっと新しいエンジニアは、単にClaude Codeに原因を突き止めるよう頼んだ。Claudeはヒープスナップショットを取り、それを分析するための小さなツールを自分用に書き(チャーニーの言葉を借りれば「ジャストインタイム・プログラム」)、問題を見つけて、チャーニーより速くPRを出した。チャーニーがここから得た教訓は、長く使ってきたユーザーほど自分を現在に合わせ続けなければならないということだ。「もうSonnet 3.5の時代ではない」のだから。

レニーは、チャーニーが新しいチームメンバーに一連の原則を説明していることに触れた。その中には、自分でやるよりClaudeにやらせたほうがいい、というものも含まれる。チャーニーは関連するいくつかの考えを説明した。

1つ目は、プロジェクトのリソースを少し足りないくらいにしておくことだ。一人のエンジニアがプロジェクトに割り当てられ、早くリリースしたいと考えると(チャーニーはこの動機を内側から湧いてくるものだと見ている)、できるだけ多くを「Claude化」し、自動化せざるを得なくなる。チームではこれが何度も繰り返し見られるという。

2つ目は、スピードを奨励することだ。今日できることは今日やる。初期にチャーニーが一人でプロジェクトに取り組んでいた頃、競争の激しいコーディング市場で戦う方法はスピードしかなかった。これは今もチームの原則であり、Claudeにより多くをやらせることが、速く進むための当然の方法になっている。

3つ目は、チャーニーがCTOたちによく伝えている原則で、最初からコスト削減をしないことだ。エンジニアにはできるだけ多くのトークンを与える。最近ではトークン無制限を福利厚生として提供する企業もあり、チャーニーはそれを勧めている。そうすれば、本来なら突飛すぎると思えるアイデアも試せるようになるからだ。アイデアがうまくいき、大規模にトークンを大量に消費し始めたら、そのときに最適化すればいい。たとえばOpusからSonnetやHaikuに切り替えるといった具合だ。Anthropicの社員なら当然トークンの使用量を増やしたいだろう、という反論を見越して、チャーニーは、個々のエンジニアが試行錯誤するコストは給与と比べれば比較的小さいと主張した。また、Anthropicのエンジニアの中にはすでに月に数十万ドルをトークンに費やしている人もおり、他の企業の中にも同様のパターンが見られ始めているところがあるという。

チャーニーは、今ほどコーディングを楽しんだことはないと言う。細かな作業に煩わされることがなくなったからだ。チャーニーはこれを自身の経歴から説明した。大学では経済学を学び、プログラミングは中学生のときに独学で身につけたもので、その動機は最初から実用的なものだった。最初に書いたプログラムは、数学のテストの答えをTI-83 Plusに保存するものだった。翌年のテストは難しすぎて答えを事前に入れておけなかったため、小さな代数ソルバーを書き、ケーブルでクラス全員に共有した。先生にばれるまで、クラス全員がAを取ったという。その後、チャーニーはプログラミングの美しさにも魅了された。TypeScriptについての本を書き、当時世界最大のTypeScriptミートアップを立ち上げ、関数型プログラミングや型システムにも深くのめり込んだ。それでもチャーニーにとって、コードは常に目的ではなく道具だったという。誰もがそう感じているわけではないことも認めている。チームのエンジニアの一人であるレナは、楽しいからという理由で今でも週末に手作業でC++を書いている。チャーニーは、そうした職人技の居場所はこれからも常にあると考えている。

自分のスキルが衰えることについては、チャーニーはあまり心配していない。プログラミングを連続したものとして捉えているからだ。紙と鉛筆による計算、ハードウェア、スイッチ、パンチカード、そして1960年代頃からは仮想マシン上で動くソフトウェアへと続いてきた。今のところ、下のレイヤーを理解していることはまだ役に立つとチャーニーは言い、それは「おそらく今後1年かそこら」は当てはまると考えている。しかし間もなく、今日プログラムの下で動いているアセンブリコードと同じように、「それはもうあまり重要ではなくなる」という。レニーは、人々はまだコーディングを学ぶべきかと尋ねた。チャーニーは、今エージェントを使っている人にはまだ下のレイヤーの理解が必要だが、「1年か2年もすれば重要ではなくなる」と答えた。レニーは、なぜAIが直接バイナリを書かないのかとイーロン・マスクが問いかけていたことに触れた。チャーニーは、望めばそれも可能だと答えた。

チャーニーは家族の話も披露した。祖父はソビエト連邦で最初期のプログラマーの一人で、パンチカードを使って仕事をしていた。チャーニーの母親は、子どもの頃にそのカードの束にクレヨンで絵を描いたことを覚えている。祖父はソフトウェアへの移行を見ることはなかった。その世代のプログラマーの中には、ソフトウェアを真剣に受け止めず、「あれは本当のコーディングじゃない」と言う人もいただろうとチャーニーは推測している。今、エージェントに意図を説明することを軽視する人がいるのと同じように。(この話の途中で、二人はともにオデッサ生まれであることがわかった。チャーニーの家族は1995年に、レニーの家族は1988年にアメリカに渡った。)

この瞬間を歴史の中に位置づけるために、チャーニーは活版印刷を引き合いに出す。1400年代半ばのヨーロッパでは、識字率は1%未満だったという。写字生が、自らも読み書きできないことが多かった領主や王に代わって読み書きを担っていた。チャーニーが挙げた数字によれば、グーテンベルク以後の50年間に作られた印刷物の量は、それ以前の1000年間を上回り、コストはおよそ100分の1に下がった。識字率の上昇はもっとゆっくりだった。教育制度と自由な時間が必要だったからだ。およそ200年かけて、世界全体で約70%に達した。チャーニーは、これに匹敵する移行が起きると予想している。一部の小さな集団が持っていたスキルが、誰にでも手の届くものになるのだ。

チャーニーはまた、活版印刷を歓迎した15世紀の写字生への、ある歴史的なインタビューについても語った。その写字生は、本から本へ書き写す作業は好きではなく、挿絵や製本のほうが好きだと話していた。チャーニーはこれに共感した。チャーニーにとって、コーディングには常にgitやツール類と格闘するような退屈な部分があった。楽しいのは、何を作るかを決めること、ユーザーと話すこと、システムや未来について考えること、そして協働することだ。今ではそうしたことにより多くの時間を使っている。チャーニーは、1か月かけてきちんと動くGoのサービスを作り上げたものの、実はまだGoをよくわかっていないと認めたエンジニアの話にも触れた。結果が正しく効率的に動くとわかっているなら、細部まですべて知っている必要はない、というのがチャーニーの考えだ。

チャーニーはこのたとえを楽観的な方向に広げた。識字の普及がなければルネサンスは起こり得なかったし、部屋にあるマイクに至るまで、現代の協調は存在しなかっただろうと論じた。チャーニーは数年後に誰もがプログラミングできる未来を思い描いており、それが何をもたらすかは誰にも予測できないと認めている。同時に、警告も添えた。その過渡期は「非常に破壊的なものになる」のであり、社会はそれにどう対処するかを共に考えていかなければならない。

チャーニーは、次に変わるのはプロダクトマネジメント、デザイン、データサイエンスといったエンジニアリングに隣接する職種だと予想している。最終的には、コンピューター上で行われるほぼあらゆる仕事に及ぶと考えている。チャーニーは、「エージェント」という言葉は使われすぎて意味を失うほどになっていると指摘した。技術的には、ツールを使って行動できるLLMを指す。Googleドキュメントを編集し、メールを送り、コマンドを実行するものだ。1年前にはエージェントを使ったことのあるエンジニアはほとんどいなかったが、今ではそれがエンジニアリングの仕事のやり方になっている。非技術系の働き手の大半はチャットボットしか使ったことがなく、チャーニーはCoworkを彼らにとってのエージェントとの最初の接点だと見ている。Anthropicには経済学者、政策担当者、社会的影響を扱うスタッフがいてその影響について取り組んでいるが、こうした決定は「私たちが決めるべきものではない」とチャーニーは述べた。

個人へのアドバイスは2つある。1つ目は、ツールを試し、恐れず、最前線にとどまること。2つ目は、以前よりもジェネラリストになることだ。Claude Codeのチームでは、PM、エンジニアリングマネージャー、デザイナー、財務担当、データサイエンティストまで、全員がコードを書く。チャーニーが一緒に働く中で最も優れたエンジニアたちは、分野の垣根を越えている。プロダクトとインフラを兼ね備えていたり、デザインのセンスがあったり、ビジネスを理解していたり、ユーザーと話すのが大好きだったりする。最も報われるのは、AIネイティブであり、かつ問題全体について考える好奇心旺盛なジェネラリストだとチャーニーは予想している。

エンジニアリング、デザイン、プロダクトマネジメントが別々の職種として残るかと問われると、短期的には残ると答えたが、すでに約50%は重なっており、専門性は端のほうにあるだけだと見ているという。たとえばエンジニアは少し多めにコードを書き、PMは調整や計画、予測をより多く担う、といった具合だ。年末までには、境界線はさらに曖昧になると予想している。場所によっては「ソフトウェアエンジニア」という肩書きが消え始め、「ビルダー」に置き換わるか、あるいは全員がプロダクトマネージャーになり、全員がコードを書くようになるという。

レニーは、Twitterで行った非公式のアンケート結果を紹介した。エンジニアとPMの約70%が、AIツールを導入してから仕事が以前より楽しくなったと答え、約10%は楽しくなくなったと答えた。デザイナーでは55%が楽しくなった、20%が楽しくなくなったと答えた。チャーニーは、どちらのグループの人とも話してみたいと述べた。Anthropicでは非技術系の採用者も技術面接を受け、デザイナーはほとんどがコードを書くことにも触れた。チャーニーが見てきた限り、Anthropicのデザイナーたちは、エンジニアに頼らず自分で行き詰まりを解消できることを楽しんでいるという。また、デザイナーはターミナルよりもClaudeデスクトップアプリの「Code」タブを使うことが多いとも話した。同じエージェントが動いており、多数のセッションを並行して走らせることができる。チームではこれを「マルチClauding」と呼んでいる。チャーニーは、経験は企業によって一様ではないだろうと見ている。

チャーニーは潜在需要を「プロダクトにおける唯一にして最も重要な原則」と呼んだ。人々が製品をハックしたり本来の用途とは違う使い方をしたりして、設計されていないことをやろうとしているなら、それは製品が次に向かうべき方向を教えてくれる、という考え方だ。チャーニーはFacebookの例を挙げた。Marketplaceの創設時のマネージャーであるフィオナ・ファンは、この製品がある観察から始まったことを語っている。チャーニーの記憶では2016年頃、Facebookグループの投稿の40%が売買に関するものだった。それが売買グループにつながり、さらにMarketplaceへと発展した。Facebook Datingも同様の観察から生まれたという。プロフィール閲覧の60%が、友達ではない異性同士の間で行われていたのだ。

Coworkも同じ原則から生まれた。およそ6か月にわたり、多くの人がClaude Codeをコーディング以外の作業に使っていた。トマトの栽培、自分のゲノムの解析、壊れたハードディスクからの結婚式の写真の復元、MRIの解析などだ。人々は「ターミナルを使うために苦労を重ねて」おり、それは製品が必要とされていることを示すシグナルだった。チャーニーが最初にこれに気づいたのは前年の5月で、データサイエンティストのブランドンがターミナルでClaude Codeを動かしているのを見つけたときだった。ブランドンはNode.jsとClaude Codeをインストールし、そこでSQLの分析をしていた。翌週には、データサイエンティスト全員が同じことをしていた。

チャーニーは、この原則のもう一つの、より新しいバージョンについても説明した。モデルが何をしようとしているかを観察し、それをやりやすくする、というものだ。初期のLLMアプリケーションの多くは、モデルを一つのコンポーネントとして「箱に入れ」、あらかじめ決められたやり取りをさせていた。Claude Codeはそのアプローチを逆転させた。製品はモデルそのものであり、その周りを最小限の足場と最小限のツールセットが囲んでいるだけで、どのツールをどの順番で使うかはモデルが決める。研究の言葉で言えば、これは「分布の内側にいる(on distribution)」ということだとチャーニーは述べた。

チャーニーによれば、Coworkは約10日で、すべてClaude Codeを使って作られた。Claude Codeの出だしが遅かったのとは異なり、Coworkはほぼ即座にヒットし、初期のClaude Codeよりもはるかに速く成長している。チャーニーはチームの功績だとして、フェリックス、サム、ジェニーの名前を挙げた。チームは数か月かけて選択肢を探り、その後誰かがClaude Codeをデスクトップアプリに入れることを提案し、それがうまくいった。Coworkの安全のためのガードレールもClaude Codeが書いた。その中には、製品に同梱される完全な仮想マシンも含まれる。チームの仕事は、非エンジニアにとってエージェントをより安全で、より自律的に動けるものにすることだった。Coworkは早めにリリースされ、まだ粗削りな部分があるとチャーニーは認めたが、それは意図的なものだという。心地よいと感じるよりも早くリリースすることが、ユーザーが何を求めているかをチームが学ぶ方法なのだ。

チャーニーは、Claude Codeの成長は一本のなめらかな曲線ではなく、いくつかの変曲点を経てきたと説明した。Opus 4がその一つで、11月がもう一つであり、それ以来成長はさらに急になり続けている。初期には、多くのユーザーがそれが何のためのものか理解しておらず、モデルも「まだあまり良くなかった」。

チャーニーは、早期リリースは安全性のための取り組みでもあると説明し、安全性に関する3つの層について述べた。最も下の層は、アラインメントと機械論的解釈可能性だ。トレーニング中にモデルの内部で何が起きているかを理解する取り組みである。Anthropicは、欺瞞に関連するニューロンのようなものを監視し、それがいつ活性化するかを見ることができる段階に近づいているという。2つ目の層は評価(eval)で、モデルを合成的な状況、つまり「シャーレの中」に置き、正しく振る舞うかどうかを確かめる。3つ目は実世界での振る舞いを観察することで、モデルが高度になるほどこれが重要になるとチャーニーは言う。最初の2つの層では良く見えても、3つ目の層ではそうでないことがあり得るからだ。

チャーニーが初めて広く使われたコーディングエージェントだと説明するClaude Codeは、安全かどうかチームに確信が持てなかったため、リリース前に約4、5か月にわたって社内で使われた。その後、実世界での利用から得られた教訓はモデルと製品にフィードバックされてきた。Coworkも同じ道をたどった。アラインメントでも評価でも、社内でも、一部の顧客においても良好に見えたため、実世界でどう振る舞うかを学ぶための「リサーチプレビュー」としてリリースされた。

解釈可能性については、チャーニーはレニーにクリス・オラーへのインタビューを勧めた。この分野を創始したのはオラーだとチャーニーは評価している。モデルのニューロンは動物のニューロンとは異なるものの、多くの点で似た振る舞いをするという。今では、モデルが次のトークンを予測する以上のことをしており、先を見越した計画も立てているという「かなり強力な証拠」があるとチャーニーは述べた。また、重ね合わせ(superposition)についても説明した。一つのニューロンが十数個の概念に対応することがあり、他のニューロンとの組み合わせによって、より高度な概念を表現することもあるという。Anthropicは他のラボを後押しするためにこうした研究の多くを公開しており、チャーニーはこれを「トップへの競争(race to the top)」と呼んだ。Claude Codeでの例として、チームはエージェントがシステム上でアクセスできる範囲を制限するオープンソースのサンドボックスを公開した。これはClaude Codeに限らず、あらゆるエージェントで使える。

チャーニーはいくつかの原則を示した。第一に、モデルを箱に閉じ込めないこと。厳密なステップごとのワークフローや手の込んだオーケストレーターは、たいていの場合、モデルにツールと目標を与えるよりも結果が悪くなる。1年前には足場が必要だったが、今ではほとんど必要ないという。最初にコンテキストを詰め込むのではなく、必要なコンテキストを集めるためのツールをモデルに与えるべきだ。

第二に、チャーニーはリッチ・サットンの「The Bitter Lesson(苦い教訓)」を挙げた。チャーニーはこれを、より汎用的なモデルが最終的には専門特化したモデルに勝つと説くものだと説明し、Claude Codeチームではこれを指針にしていると述べた。そこから導かれるチャーニーの結論は、柔軟に選べる場面では、より汎用的なモデルに賭けるべきだというものだ。ほとんどの場合、小さなモデルやファインチューニングは避けるべきだという。チャーニーの経験では、足場によって性能が10〜20%上がることはあっても、次のモデルが出るとその上積みはしばしば消えてしまう。

第三に、6か月後のモデルに向けて作ること。Claude Codeの初期バージョンは、Sonnet 3.5世代のモデルが十分に優秀ではなかったため、チャーニーのコードをほとんど書けなかった。賭けていたのは、いずれ十分に優秀になるということだった。それが実現したのがOpus 4とSonnet 4だった。チャーニーの言葉によれば、Opus 4はAnthropic初のASL-3クラスのモデルで、5月にリリースされ、Claude Codeの成長が指数関数的になったのはそのときだった。チャーニーはスタートアップに対し、このやり方をとると最初の6か月はプロダクトマーケットフィットが弱くなると警告したが、モデルが追いついたときには「すぐに全力で走り出せる」という。

今後のモデルに何を期待すべきかと問われ、チャーニーはラボの内部で働いているのは「少しずるい」と認めつつ、2つの予想を挙げた。モデルはツールやコンピューターの使用がうまくなり、より長い時間、人の手を借りずに動くようになるという。1年前のSonnet 3.5では、モデルが脱線するまでの時間は15秒か30秒ほどだったかもしれない。Opus 4.6では、通常10分から30分、ときには数時間から数日にわたって、人の手を借りずに動き続けるという。何週間にもわたって動き続けた例もあるとチャーニーは述べた。

チャーニーは、Claude Codeの正しい使い方は一つではないと言う。開発者はそれぞれ異なり、Claude Codeは自分自身の設定を提案したり編集したりもできる。チャーニーは3つの一般的なヒントを挙げた。1つ目は、最も高性能なモデルを使うこと。チャーニーにとってはOpus 4.6で、エフォートは常に最大に設定している。性能の低いモデルは修正が多く必要になるぶん、結果的にトークンを多く消費することがあり、安いモデルが必ずしも安上がりとは限らないとチャーニーは主張した。2つ目は、プランモードを使うこと。チャーニーはタスクの約80%をプランモードから始めている。プランモードは、まだコードを書かないようモデルに伝える一文を挿入するだけのものだと説明した。ターミナルではShift+Tabを2回押す。デスクトップアプリとWebにはボタンがあり、Slack連携でもちょうど使えるようになったばかりで、モバイルにも近く導入される。プランが良さそうなら、チャーニーは編集を自動承認にする。Opus 4.6はたいてい一発で正しくこなすからだ。3つ目は、さまざまなインターフェースを試すこと。どこでも同じエージェントなので、しっくりくるものを使えばいい。

デスクトップアプリのCodeタブの隣にあるCoworkについては、まずデスクトップの整理や、上位3通のメールへの返信など、一つのタスクから始めることを勧めた。次に、ツールを連携させる。プロジェクト管理の例として、チームではエンジニアごとに1行ずつ週次の進捗報告を書くスプレッドシートを使っており、毎週月曜日になると、Coworkがまだ記入していないエンジニア一人ひとりにSlackでメッセージを送るという。最後に、多くのタスクを並行して走らせる。チャーニーはまた、Coworkが駐車違反の罰金と交通違反の反則金を代わりに支払い、サブスクリプションを解約してくれたことも話した。レニーは、育児休暇中の同僚のために医療関係の書類を記入してくれた例に触れた。チャーニーによれば、1年前にチームで試したときは、モデルの準備が整っていなかったためにうまくいかなかったという。今のCoworkは、1年前のClaude Codeとよく似た感触だという。さらにチャーニーは、AnthropicのPMの一人がリリース前に、レニーの「Claude Codeの非技術系の使い方50選」という記事に照らしてCoworkを評価していたことも明かした。50のうち48をCoworkがこなせるようになった時点で、チームは十分な出来だと判断した。

Codexについて問われると、チャーニーはほとんど使ったことがないと答えた。リリース当初に試したときは、Claude Codeによく似ていて、光栄に感じたという。ユーザーには選択肢があるべきなので競争は歓迎するが、チームは競合製品にはほとんど時間を割かず、ユーザーのフィードバックに集中していると述べた。

ベン・マンからは、AGIの後に何をするつもりかという質問が寄せられていた。Anthropicに入る前、チャーニーは日本の田舎に住んでおり、町で唯一のエンジニアであり、唯一の英語話者だった。近所の人たちは手作りの漬物や味噌を交換し合うことで友情を育んでおり、チャーニーも味噌作りがそこそこ上手になった。チャーニーは、味噌作りが長い時間軸を強いるところを気に入っている。白味噌は最低でも3か月、赤味噌は2年から4年かかる。AGIの後、あるいはもしAnthropicにいなかったら、おそらく味噌を作っているだろうという。さらに、日本で季節に寄り添って暮らしながらSFをたくさん読んだことが、AIが「少しでも良い方向に」進むよう手助けしなければならないと確信させたのだと付け加えた。ベン・マンもまた、Anthropicに入る決断の大きな理由だったという。

ライトニングラウンドでは、これまで読んだ中で最高の技術書として『Scalaスケーラブルプログラミング』ならぬ『Functional Programming in Scala』を挙げた。読者がScalaを使うことはないかもしれないと認めつつも、型で考えることのエレガントさを教えてくれる本だという。また、この時代の加速するペースを捉えていると感じるチャールズ・ストロスの『アッチェレランド』と、『三体』よりも好きだという劉慈欣の短編集『流浪地球』も薦めた。テレビはめったに見ないが、Netflixの『三体』は楽しんだという。好きな製品はCowork、特にそのChrome連携で、好きなポッドキャストは『Acquired』、まずは任天堂の回から聴くのがいいという。人生のモットーは「常識を使え」。職場での失敗の多くは、考えずにプロセスや惰性に従うことから生まれ、最良の結果は第一原理から考える人たちから生まれるという。Xを使い始めたのは、12月にヨーロッパで過ごした「コーディング休暇」中に退屈したからだった。Claude Codeに関する投稿に返信し、バグを教えてほしいと呼びかけるようになると、よく説明されたバグであれば、Claudeに渡すことで数分以内に修正できることが多く、人々は驚いたという。

チャーニーは最後に、Anthropicの中核となるテーゼに立ち返った。まずコーディング、次にツールの使用、そしてコンピューターの操作へ。ターミナル製品が数十億ドル規模のビジネスになるというClaude Codeの具体的な形はまったくの驚きだったが、方向性は驚きではなかった。それは長い間、同社が信じてきたことだったからだ。製品を改善し続けているのは、何が壊れていて何が欲しいのかをチームに伝えてくれるユーザーだという。チャーニーはリスナーに、ThreadsやXで自分をタグ付けして、バグや機能要望、足りないものを教えてほしいと呼びかけた。