Claude Codeの生みの親であるエンジニアBoris Cherneyが、ツール誕生の経緯から設計思想、そして今後の展望までを語る動画である。「今日のモデルではなく、6ヶ月後のモデルのために作れ」という哲学のもと、ターミナルという意外なUIを選んだ理由、ユーザーの潜在需要から機能を導き出すプロダクト手法、そしてAnthropicにおけるエンジニアリング生産性の飛躍的向上について詳述している。AIコーディングツールの現在地と未来像を俯瞰する上で欠かせない対談である。
Claude Codeの誕生
Anthropicでの私たちの考え方は、今日のモデルのために作るのではなく、6ヶ月後のモデルのために作るというものです。これは今でも、LLMを使ったものを作っているスタートアップの創業者たちへの私のアドバイスと変わりません。つまり、モデルが今まだあまり得意でない領域の限界線がどこにあるかを考えることです。なぜなら、そこはいずれ得意になるから。ただ待てばいい。
Claude Codeのコードは、もう何度も何度も書き直されて、書き直されて、書き直されて、また書き直されてきました。6ヶ月前の面影が残っている部分など一切ありません。試してみて、ユーザーに渡して、ユーザーと話して、学ぶ。そうしてようやく、いいアイデアにたどり着けることもある。たどり着けないこともある。
プランモードを1ヶ月後には使わなくてよくなると思う？ そんな話をしていたら、「1ヶ月後にはプランモード不要」なんてことに？ なんてこった。
Light Coneへようこそ。本日のゲストは非常に特別な方、Claude Codeの生みの親であるエンジニア、Boris Cherneyさんです。Borisさん、ご参加ありがとうございます。
ありがとう。招いてくれて嬉しいよ。
こちらこそ、3週間ぶっ通しで私の睡眠を奪ってくれたものを作ってくれてありがとう。
開発初期の3ヶ月間
私、Claude Codeに完全に依存してしまっていて、ロケットブースターを背負っているみたいな感覚なんですよ。あなたはもう何ヶ月もずっとこの感覚だったんですか？ たしか11月末あたりから、友人たちが口々に「何かが変わった」と言い始めたんですが。
私自身がこの感覚を覚えたのは、Claude Codeを最初に作ったときでした。まだ何かに手応えを感じているのかどうか分からない段階で、でも何かに手応えを感じているような気がして、そこから眠れなくなった。3ヶ月ぶっ通しでしたよ。
それが2024年9月ですね。3ヶ月間、一日も休まなかった。週末も、毎晩も、ずっと働き続けた。「これは絶対に何かになる、でもまだ有用かどうか分からない、だってコードがまだ書けないから」って感じで。
今、この瞬間から振り返って、あの頃から最も驚いていることは何ですか？
まだターミナルを使っているということが信じられない。あれは出発点のつもりだったのに、終着点になるとは思っていなかった。それと、そもそも役に立っていること自体も驚きです。最初はまともにコードが書けなかったから。2月にリリースした時点でも、私のコードの10%くらいしか書いてくれなくて、コードを書かせるために使っていたわけじゃなかった。まだほとんど手で書いていましたよ。だからこそ、賭けが報われて、得意になると思っていたことを本当に得意になったという事実が嬉しい。当然じゃなかったから。
Anthropicでの考え方は、今日のモデルのために作らないということです。6ヶ月後のモデルのために作る。LLMの上に何かを作っているスタートアップ創業者へのアドバイスも、今でも同じです。モデルが今あまり得意でない境界線はどこかを考えること。なぜならそこは必ず得意になるから、ただ待てばいい。
アイデアの原点
でも遡って聞かせてください。最初にアイデアが浮かんだのはいつですか？ どんな経緯だったんでしょう。何かひらめきのような瞬間があったんですか？ あなたの頭の中の最初のバージョンって？
面白いことに、あまりにも偶然の積み重ねで、気づいたらこうなっていたという感じなんです。Anthropicでは、コーディングというのがずっと大きな賭けでした。安全なAGIへの道はコーディングを通じてだ、という考えがずっとある。コーディングをモデルに教えて、ツールの使い方を教えて、コンピューターの使い方を教える、という流れです。それは私が最初に参加したチーム、Anthropic Labsチームを見ると分かります。あのチームが生み出した三つのプロダクトが、Claude Code、MCP、そしてデスクトップアプリです。これらがどう絡み合っているか、見えてくるはずです。
私たちが作った具体的なプロダクトについて言うと、CLIを作れと誰かに言われたわけじゃない。コーディング系のプロダクトを作る頃合いかもしれないとは感じていた。モデルの準備は整っているのに、その能力を活かすプロダクトをまだ誰も作っていないと思っていて。だから、プロダクトの供給不足みたいな感覚があったし、当時はそれがさらに強かった、誰もまだ作っていなかったから。
それでハックしながら始めたんです。コーディングプロダクトを作るなら、まず何をしなければいけないか。APIの使い方を理解しなきゃいけない。当時まだAnthropicのAPIを使ったことがなかったから。だから、APIを使う小さなターミナルアプリを作った。それだけです。チャットアプリでした。当時のAIアプリケーションを考えると、非コーダーが今最もよく使っているものはチャットアプリだから。だからチャットアプリを作った。ターミナルで動いて、質問して、答えてもらう。そのうちツール使用機能がリリースされて、試してみたくなった。ツール使用って何なのか、よく分かっていなかったから。面白そうだな、実際に使えるのかな、たぶん使えないけど試してみよう、という感じで。
ターミナルを選んだのは単純にUIを作らなくて済むから一番手軽だったから？
そうです。UIを作る必要がなかった。当時は私一人だったし。
当時はCursorやWindsurfといったIDEが台頭していましたが、プラグインにすべきとか、フル機能のIDE自体にすべきとかいったプレッシャーや提案はありましたか？
プレッシャーは全くなかったですよ。何を作りたいかすら分かっていなかったから。チームは探索モードにいただけで、コーディング関連で何かやりたいとはぼんやり思っていたけど、何が正解か誰も確信を持てていなかった。それを突き止めるのが私の仕事だったんです。
初期の実験とAGIの予感
モデルにはまずbashツールを渡しました。最初に渡したツールがそれだったのは、たしかドキュメントのサンプルにあったからです。そのサンプルをそのまま使って、Pythonで書かれていたのをTypeScriptに移植した。私はTypeScriptで書いていたから。モデルがbashで何ができるか分からなくて、とりあえずファイルを読んでみるよう頼んだら、ファイルをcatしてきた。面白いな、と思って、「じゃあ実際に何ができる？」と聞いて、「私が今聴いている音楽は？」と試したら、Macをスクリプトして音楽プレーヤーで確認するAppleScriptを書いてきた。
なんてこった。
それがClaude 3.5でした。モデルにそんなことができるとは思っていなかった。あれが私の初めての「AGIを感じた瞬間」でした。モデルはただツールを使いたいんだ、それだけなんだ、という感覚。
面白いですね。Claude Codeがシンプルで洗練されたフォームファクターでこれほど機能するというのは、ある意味かなり逆張りですよね。ターミナルは長い歴史があって、それが面白い開発者体験を生む良い制約になっている気がします。仕事している感じがしなくて、ただ楽しい。ファイルがどこにあるかとか考えなくていい。そしてそれはほとんど偶然だったと。
そうなんですよ、偶然でした。ターミナルが内部で広まり始めた後を振り返ると、最初のプロトタイプを作ってから2日後くらいには、チームに渡してドッグフーディングしてもらっていました。アイデアを思いついて役立ちそうなら、まず人に渡して使い方を見るのが当然だから。翌日来たら、向かいに座っているエンジニアのRobertがもうClaude Codeでコードを書いていて、「何やってるの？これはまだプロトタイプだよ」って言ったら、もうそのフォームファクターで十分使えていた。
Darioの「垂直なグラフ」
外部へのリリースのレビューをした時、2024年の12月か11月か、Darioが内部の利用チャートを見て「これ垂直に伸びてるけど、エンジニアに強制してるの？義務にしてる？」って聞いてきたんです。私は「いや、Slackに投稿しただけで、みんなが口コミで広めてくれた」と答えた。本当に偶然だったんですよ。CLIから始めたのは一番コストが低かったから、そのままの状態がしばらく続いただけで。
2024年の時期、エンジニアはどんな使い方をしていましたか？コードを本番に出していたのか、それとも別の使い方をしていたのか？
モデルはまだコーディングがあまり得意じゃなかった。私個人はgitの自動化に使っていました。もうgitのほとんどは忘れてしまったと思います、Claude Codeがずっとやってくれているから。bashコマンドの自動化、Kubernetesの操作みたいなことですね。コーディングにも使い始めていて、初期の兆しはありました。最初のユースケースはユニットテストの作成だったと思います。リスクが低めだし、モデルはまだあまり得意じゃなかったけど、みんな使い方を模索していた。
CLAUDE.mdの誕生
あるとき、人々が自分用のMarkdownファイルを書いて、モデルにそのファイルを読ませ始めていることに気づきました。それがCLAUDE.mdの起源です。私にとってプロダクトで最も重要な原則が「潜在需要」です。最初のCLIの後、このプロダクトのすべての機能は潜在需要から生まれています。CLAUDE.mdはその典型例です。
もう一つ面白い原則があって、モデルのために作ることもできるし、モデルの周りに足場（スキャフォールディング）を作ってパフォーマンスを少し向上させることもできる。ドメインによっては10〜20%向上できるかもしれない。でも基本的に、次のモデルが出たらその向上分は消えてしまう。足場を作ってパフォーマンス向上を得て、またそれを作り直すか、次のモデルを待って自然についてくるか、という選択肢になる。CLAUDE.mdや各種スキャフォールディングはその典型で、CLIにとどまってきた理由もそこにある。6ヶ月後も通用するUIなど作れないと感じていたほど、モデルが急速に改善していたから。
さっきCLAUDE.mdの比較をしようという話になりましたが、あなたのがとても短いと言っていましたね。人々の予想とは逆で。なぜですか？何が書いてあるんですか？
来る前に確認してきたんですが、私のCLAUDE.mdはたった2行なんです。一行目は、PRを上げるたびに自動マージを有効にすること。承認されたら自動でマージされるようにしている。コードを書きながらレビューとやり取りを往復しなくて済むように。二行目は、PRを上げるたびに社内のチームSlackチャンネルに投稿すること。誰かにスタンプしてもらってブロック解除できるように。その他の指示はすべてコードベースにチェックインしてあるCLAUDE.mdに書いてあって、チーム全員が週に何度も更新しています。誰かのPRを見て完全に防げたはずのミスを見つけたら、そのままClaudeをタグしてPRに「これをCLAUDE.mdに追加して」と書く。週に何度もやっています。
CLAUDE.mdをコンパクト化したりしないんですか？私はトークン数が多すぎますという警告が出るくらいになったんですが、そうなったらどうしていますか？
私たちのCLAUDE.mdは実際かなり短いです。たぶん数千トークンくらいかな。そうなったら、私のおすすめは削除して最初からやり直すことです。
面白い。みんな過剰設計しようとしがちだと思いますが、能力はモデルごとに変わるので、モデルを軌道に乗せるための最小限のことだけをやるのが理想です。CLAUDE.mdを削除して、モデルが脱線したとき、間違ったことをしたとき、そのときに少しずつ追加していく。するとおそらく、モデルが新しくなるたびに追加する量は減っていく。
開発者ツールとしての哲学
私は自分のことをわりと平均的なエンジニアだと思っています。凝ったツールはあまり使わない。Vimじゃなく、VS Codeを使っている。シンプルだから。
えっ、そうなんですか？ターミナルで作ったからてっきりVim一筋の人かと思っていました。
チームにはそういう人もいますよ。例えばAdam Wolfは「Vimは死んでも手放さない」というタイプです。でも早い段階で学んだのは、エンジニアはみんな開発ツールの使い方が違って、全員に合うツールなんてないということ。それがClaude Codeをこれほど優れたものにできる理由の一つでもある。自分が使いたいと思えるプロダクトを作るという感覚で作ってきたから。Claude Codeを使うのにVimを知らなくていい、tmuxを知らなくていい、SSHを知らなくていい。ツールを開けばガイドしてくれる。
ターミナルの冗長性についてはどうやって決めているんですか？Ctrl+Oで確認しに行く必要があったりして、ユーザーによって意見が違うと思うんですが。
今の冗長さはどう思いますか？多すぎる？
私は多いのが好きです。モデルが突っ走っているとき、さっと読んで「あ、違う違う」ってエスケープで止めれば、バグの温床になる前に止められる。
それはプランモードをちゃんとやっていなかったときによく起きますね。冗長性はわりと頻繁に変えています。6ヶ月くらい前、bashの出力を要約するだけにしようとしたことがありました。長いbashコマンドとか、実際気にしないよな、と思って。でも社内で試したら一日で大反発。Kubernetesのジョブを実行しているときなんかは実際に見たいので、分かる。
最近はファイルの読み込みとファイル検索を非表示にして、「fooを読み込む」の代わりに「1ファイルを読み込む」「1パターンを検索した」と表示するようにしました。これ、6ヶ月前には出せなかったと思う。まだモデルが間違ったものを読み込むことも多くて、ユーザーが見ていてキャッチしてデバッグする必要があった。今はほぼ毎回正しい軌道に乗っているので、要約した方がずっとすっきりする。出荷して1ヶ月ドッグフーディングしたんですが、GitHubでは不評でした。「詳細を見たい」という声が上がって、それはすごくいいフィードバックだった。だから新しいverboseモードを追加して、/configで有効にできるようにした。それでもまだ気に入らないという声があって、またそれも最高なことで。ユーザーの声を聞いて実際の使い方を知るのが一番好きなことだから。
ユーザーフィードバックと反復開発
バグ修正がこんなに楽しくなるとは。ちゃんとしたロギングさえあれば、「このオブジェクトがこういうふうにおかしい」と言うだけで、ログを検索して全部解明してくれる。プロダクションのトンネルに入って、プロダクションDBも見に行ける。Sentryからmarkdownをコピーするだけでバグ修正ができてしまう。そのうちMCPだけで全部できるようになる。自動バグ修正ツールみたいな。スタートアップファクトリーって言うんでしたっけ？
あー、コードをレビューしなきゃいけなくなるたびにそれは良くないという考え方の流派もありますね。人間が実際にコードを見なければいけないことがダメ、という。
ええ、そうですね。Dan Chipperもよく言っていますよね、モデルがミスをするたびにCLAUDE.mdかスキルに追加して再利用できるようにする、と。でも私がずっと葛藤しているメタな問題があって、エージェントにこれができる、あれができると言われるけど、実際にできることはモデルごとに変わる。新しいチームメンバーが入ってくると、私が使っていた以上にClaude Codeを使うことがある。それに毎回驚かされます。
例えばメモリリークがあって、デバッグしようとしていたとき。ちなみにJared Sumarがメモリリーク潰しに取り憑かれていてすごい仕事をしてくれているんですが、Jaredが来る前は私がやっていた。ヒープダンプを取ってDevToolsで開いて、プロファイルを見て、コードを見て、解明しようとしていた。するとチームの別のエンジニア、Chrisが「メモリリークがあると思うけど、調べてみて」ってClaude Codeに頼んだだけで、Claude Codeがヒープダンプを取って、解析用の小さなツールを自分で作って、私より早くリークを見つけた。自分の思考が6ヶ月前のどこかで止まっていることを、常に再学習しなければいけない。
テクニカルファウンダーへのアドバイス
最新モデルで最大限の力を引き出すための技術的創業者へのアドバイスはありますか？何の前提もない新卒の方が、長年の経験を持つエンジニアより向いているのかもしれない？
自分にとってはビギナーズマインドと、謙虚さかな。エンジニアという職種は強い意見を持つように訓練されていて、上級エンジニアはそれで評価される。前の大企業での仕事でアーキテクトを採用するとき、経験豊富で強い意見を持つ人を探していた。でも実際は、その多くはもはや関係ないし、モデルが向上しているから多くの意見は変えるべきなんです。だから今最も重要なスキルは、科学的に考えられる人、ファーストプリンシプルから考えられる人だと思います。
採用面接でどうやってスクリーニングしているんですか？
間違ったことがある例を挙げてもらうことがあります。こういうクラシックな行動面接の質問は、コーディング問題じゃなくても、振り返って自分のミスを認められるか、そこから何かを学んでいるかが見えるから有用です。とても上級な人でも、ミスの責任を取れない人がいる。でも私は半分くらいは間違っている。アイデアの半分はダメで、試して、ユーザーに渡して、ユーザーと話して、学ぶしかない。いいアイデアにたどり着くこともあれば、たどり着けないこともある。これは昔は創業者にとって重要なスキルだったけど、今はすべてのエンジニアにとって重要だと思います。
Claude Codeのコーディングセッションのトランスクリプトをもとに採用することを考えていますか？私たちは実際にそれを試しているんですが、Claude CodeやCodexでフィーチャーをコーディングしたトランスクリプトをアップロードできるようにしました。どう思いますか？
うまくいくと思います。ログを見ているか、エージェントが脱線したときに修正できるか、プランモードを使っているか、プランモードでテストを確認しているか、システムについて考えているか、システムを理解しているか。そういったことがトランスクリプトに凝縮されている。スパイダーグラフみたいなものが欲しいですよね、NBA 2Kのように。Claude Codeのスキルレベルのスパイダーグラフ。
スキルは何になりますか？
システム思考、テスト、ユーザー行動の理解、プロダクトセンス、自動化。私のCLAUDE.mdのお気に入りは「すべてのプランについて、過剰設計か、過少設計か、ちょうどいいかを判断してその理由を言え」という一文です。
チームで最も効果的だと思うエンジニアのパターンを見ると、二極化している。一方は極度の専門家。JaredやBunチームが典型で、開発ツールやJavaScriptランタイムシステムを誰よりも深く理解している。もう一方は超ジェネラリスト。プロダクトとインフラ、プロダクトとデザイン、プロダクトとユーザーリサーチを横断する。変わったことをやっている人が好きです。昔は警戒サインだったかもしれないけど、今は違う。
例えばDaisyというエンジニアがいて、別チームからトランスファーしてきてもらったんですが、彼女がClaude CodeにPRを上げてきた。新しい機能を追加するんですが、ただ追加するんじゃなくて、まずClaude Codeに任意のツールをテストして検証できるツールを与えるPRを上げた。そしてClaude自身にツールを書かせた。このアウトオブボックスな思考は本当に面白い。私たちはClaude agents SDKを使って開発のほぼあらゆる部分を自動化しています。コードレビュー、セキュリティレビュー、イシューのラベリング、本番環境へのリリース管理、ほぼ全部。でも外部でもこれをやり始めた人が増えてきているが、この使い方を習得するには時間がかかっている。
ビジョナリー創業者と現場の乖離
創業者のオフィスアワーで面白い話を聞くんですが、ビジョナリーな創業者がいて、プロダクトの理想的な姿を脳内に完全に構築していて、そのユーザーが何を感じて何に動機づけられるかも全部頭に入っている。そしてClaude Codeで50倍の仕事ができる。でもチームのエンジニアはその「水晶宮殿」を共有していないから5倍の仕事しかできない。そういう話を聞きますか？
ありますよ、コアデザイナーが一人いて、頭の中のものを爆発的に吐き出そうとしている。それはほぼ安定した構成のように思えます。ビジョナリーがClaude Codeで解き放たれる一方で、チームはついていけない。でも、Claude Teamsを作った理由の一つもそこにある。自分でも作れるけど、これは簡単にできる方法の一つです。
Claude Teamsのビジョン
Claude Teamsのビジョンは何ですか？
コラボレーションです。エージェントのトポロジーという新しい分野が広がっていて、エージェントをどう構成するかを探っている。一つのサブアイデアは「相関のないコンテキストウィンドウ」です。複数のエージェントがそれぞれフレッシュなコンテキストウィンドウを持っていて、互いのコンテキストや自分自身の以前のコンテキストで汚染されていない。問題に多くのコンテキストを投入することは、テスト時コンピュートの一形態です。それだけで能力が上がる。そこに適切なトポロジーがあれば、エージェントが適切な方法でコミュニケーションして、より大きなものを作れる。
Teamsはその一つのアイデアで、もう少し追加機能が近々来る予定です。最初の大きな成功例は、プラグイン機能が週末にスウォームで完全に作られたこと。数日間動かしっぱなしで、ほぼ人間の介入なし。今のプラグインはほぼそのリリース時の形のままです。
どうセットアップしたんですか？期待するアウトカムを仕様で定めて、細部を任せて走らせた？
はい。チームのエンジニアがClaudeに仕様を渡して、Asanaボードを使うよう指示したら、Claudeがチケットをたくさん作って、エージェントを大量にスポーンして、エージェントたちがタスクを拾い始めた。メインのClaudeが指示を出して、みんなで勝手に解決した。
それぞれ大きな仕様のコンテキストを持たない独立したエージェントが、ですよね。
そうです。私のClaude Insightsが、デバッグの効率を上げるために複数のサブエージェントを並列で立ち上げるべきだと言っていたので、CLAUDE.mdに追加しました。バグを修正しようとするとき、ログを見るエージェント一つ、コードパスを見るエージェント一つ、という感じで。
変なバグのとき、プランモードでバグ修正しようとすると、エージェントを使って広く検索してくれる。インラインでやろうとすると、この一つのタスクだけというふうになりがち。私はよく、「タスクの難しさに応じてサブエージェントの数を増やして」と言います。難しいなら3つ、5つ、10つ並列でリサーチさせて、何が出てくるか見る。
じゃあなぜCLAUDE.mdに入れないんですか？
ケースバイケースだから。CLAUDE.mdは、同じことを繰り返しているなら入れるためのもので、全部入れる必要はない。そのままClaudeにプロンプトすればいい。
プランモードの未来
6ヶ月後には、そこまで明示的にプロンプトしなくてもよくなると思いますか？モデルが自分で判断できるくらいよくなる？
1ヶ月後かも。
1ヶ月後にはプランモード不要に？
なんてこった。
プランモードにはたぶん寿命が限られていると思います。プランモードがない世界はどうなるんだろう？プロンプトレベルで説明するだけでワンショットでやってくれる？
はい、この実験も始めています。Claude Codeが自分でプランモードに入れるようになってきているんです。人間がプランモードに入りたかったタイミングで自動的に入るようにする。プランモードに大した秘密はなく、「コードを書かないで」という一文をプロンプトに追加しているだけです。それだけ。だからそう言えばいいだけでもある。
ユーザーの声からのプロダクト開発
Claude Codeの機能開発は、まさにYCで言うユーザーと話せ、ということを実践していて、実装はそれから、という感じですね。マスタープランがあってから機能を実装したわけじゃない。
ええ、それだけです。プランモードも、ユーザーが「計画を立ててほしいけど、まだコードは書かないで」と言っているのを見てきた。バリエーションがいろいろあった。アイデアを話し合うだけのこともあれば、とても精密な仕様を書かせることもあった。共通していたのは「まだコーディングしないでやること」だった。それで日曜の夜10時に、GitHubのイシューとSlackのフィードバックチャンネルを見ながら30分で書いて、月曜の朝に出した。それがプランモードです。
プランモードが不要になるというのは、モデルが脱線するのを心配する必要がなくなるという意味で、でもアイデアを考え抜いてどう作りたいかを明確にする必要はなくなるわけじゃない？
モデルの能力向上という観点で考えています。6ヶ月前はプランだけでは不十分で、プランモードでもずっと張り付いて監視しなければいけなかった。今は80%のセッションをプランモードで始めて、プランが始まったら2つ目のターミナルタブに移って別のプランを作って、タブがなくなったらデスクトップアプリを開いてコードタブで新しいタブを開いて、全部プランモードで始める。
プランが固まったら、少しやり取りが必要なこともあるけど、あとはClaudeに実行させる。最近Opus 4.5、というかClaude 4.6から本当によくなって、プランが固まれば、ほぼ毎回正確にやり遂げてくれる。以前はプランの前も後も監視が必要だったのが、今はプランの前だけになった。次はプランも監視不要になって、プロンプトを渡すだけでClaudeが判断してくれるかもしれない。
次のステップはClaudeがユーザーと直接話すようになることですよ。あなたを完全にバイパスして。
実は今まさにそういうことをしていて。Claudeたちが互いに話し合ったり、Slackでユーザーと話したりしています、少なくとも社内では。私のClaudeは時々ツイートもしますよ。
まさか。
でも削除しています。ちょっとわざとらしくて、トーンが好きじゃなくて。
何についてツイートしようとするの？
バックグラウンドで常にco-workが動いていて、それがブラウザを使いたがっているから。
面白いですね。よくあるパターンとして、Claudeに何かを作るよう頼むと、コードベースを見て、gitのflameでエンジニアが何かを触ったのを見つけて、そのエンジニアにSlackでメッセージを送る。質問を明確にしてから、回答が来たら作業を続ける、というのがあります。
創業者へのアドバイス
創業者へのアドバイスは何でしょう？すべてが急速に変わっている中で、どんな原則が残り、何が変わるのか？
基本的なことだけど、今以前より重要になっていることがいくつかある。潜在需要。何度も言っているけど、私にとってプロダクトで最大のアイデアです。誰も理解していないことで、私自身も最初のスタートアップの頃は分かっていなかった。人はすでにやっていることしかやらない。新しいことをやらせることはできない。人がやろうとしていることをより簡単にしてあげるのはいいアイデアだけど、別のことをやらせようとしても無理。だからやろうとしていることを簡単にしてあげればいい。Claudeはフィードバックやデバッグログを見て、こういったプロダクトアイデアを探し出すことがますます得意になっていく。
プランモードが潜在需要だったというのは、人々がすでにブラウザのClaudeチャットで仕様について話し合っていて、それがClaude Codeのプランモードになった、ということですね。
そうです。時々オフィスフロアをふらっと歩いて、人々の後ろに立ってClaude Codeの使い方を見ています。「こんにちは」と声をかけてから。GitHubのイシューでも見えていた。
ターミナルがこれほど進化して驚いているとのことですが、マルチエージェントの世界でどこまで行けると思いますか？その上に新しいUIが必要になると思いますか？
1年前に聞かれたら、ターミナルの寿命は3ヶ月くらいで次に移ると言っていたでしょう。実際に実験もしていて、Claude Codeはターミナルから始まってウェブ、デスクトップアプリ、iOS・Androidアプリ、Slack、GitHub、VS Code拡張、JetBrains拡張と広がっています。常に別のフォームファクターを試して次を探っている。CLIについての予想をずっと外してきたので、私には予測する資格がないかもしれません。
DevToolスタートアップへのアドバイス
DevToolスタートアップの創業者へのアドバイスはありますか？エンジニアや人間向けに作るべきか、Claude向け、エージェント向けに考えるべきか？
モデルがやりたいことを考えて、それをどう簡単にするかを考えることだと思います。Claude Codeをハックし始めたとき気づいたのは、このモデルはとにかくツールを使いたがっている、世界と関わりたがっている、ということ。どうやって実現するか。APIを箱に入れて、「ここがAPIで、これが世界との関わり方」と渡すのはダメ。モデルが使いたがっているツールを見て、やろうとしていることを見て、ユーザーへのやり方と同じように可能にしてあげる。DevToolスタートアップを作るなら、ユーザーに対して解決したい問題は何か、モデルを使ってその問題を解決しようとするとき、モデルが何をやりたがっているか、そして両方の潜在需要に応える技術的・プロダクト的解決策は何か、を考える。
TypeScriptとの類似点
10年以上前、TypeScriptの本を書いていたんですよね、TypeScriptが有名になる前に。当時はみんなJavaScriptに浸かっていた頃で。
そうですね、2010年代前半くらい。
TypeScriptはとてもおかしな言語設計の決断をたくさんしていますよね。型システムを見ると、ほぼあらゆるものをリテラル型にできたり、Haskellでも採用していないような極端さだったり、他の言語が思いつかなかったような条件型があったり。
非常に強く型付けされていました。Joe PamerやAndersと初期チームがこれを作ったとき、巨大な型なしJavaScriptコードベースを持つチームに型を導入しなければいけないが、エンジニアのコーディングスタイルを変えさせることはできない、という考えでした。JavaScriptプログラマーにJavaプログラマーのような15層のクラス継承をやらせることはできない。リフレクションやミューテーションや、従来は型付けが非常に難しい機能を使い続ける。だから彼らのコードスタイルを変えさせる代わりに、その周りに型システムを構築した。学術界でも誰も考えていなかったアイデアばかりで、JavaScriptプログラマーのコードの書き方を観察することから純粋に生まれた。
Claude Codeも似ていて、Unixユーティリティのように使えて、パイプイン・パイプアウトができる。原則的というより、自分たちが使いたいツールを作っていただけです。チームが自分のために、Anthropic社員のために、ユーザーのために作って、結果として本当に役立つものになった。学術的でもなんでもない。そして15年後、Haskellで書かれたコードベースはほとんどなくなって、TypeScriptには膨大な数のコードベースがある。実用的だから。
ターミナルUIの設計
一つあまり知られていないことがあって、このターミナルは実際にはReactで書かれた最も美しいターミナルアプリの一つです。
最初に作り始めたとき、フロントエンドエンジニアとして働いていたし、デザインもユーザーリサーチもコードも書く、そういうハイブリッドな人間です。そういうエンジニアを採用するのが大好きです。ターミナルで動くものを作るにあたって、私はVimがあまり得意じゃないので、私のような人が快適に使えるものを作りたかった。そして喜びが大事だということはYCでもよく言いますよね。人が愛せるものを作れ、と。役立つだけでは足りない、愛されなきゃいけない。
ターミナルのためのデザインは本当に難しい。80×100文字で、256色で、フォントサイズ一つで、マウス操作なし。制約が多い。マウスインタラクションはターミナルでも有効にできるのですが、Claude Codeでは実装しなかった。何度かプロトタイプを作ったけど、スクロールを仮想化しなければならなくてトレードオフが辛かった。ターミナルにはDOMがなくて、ANSIエスケープコードという1960年代から有機的に進化してきた仕様があるだけで。
BBS感覚で探索しているみたいですね。Lord of the Red Dragonみたい。
そうそう、そんな感じを目指している。でもターミナルのUX原則はほぼ誰も書いていないから、全部自分たちで発見しなければいけない。80年代や90年代の有名なターミナルアプリはncursesを使ったウィンドウだらけで、現代の目には重くて複雑に見える。だから多くを再発明しなければいけなかった。ターミナルのスピナーだけでも50〜100回はイテレーションを重ねて、8割はリリースしなかった。Claude Codeのおかげで、バックトゥバックで20プロトタイプ作って、一番いいのを選んでリリース、それが数時間で終わる。以前はFigmaやFramerで2〜3プロトタイプ作るのに2週間かかっていた。正解が分からない状態でも、こんなに速くイテレーションできるから、喜ばれるプロダクトを作ることができる。
創業者への最後のアドバイス
Borisさん、他にもアドバイスがあったのに私たちが割り込んでしまいましたよね。
ちょっと変なアドバイスが二つあって、モデルのために作ることについてです。一つ目は、今日のモデルのために作らないで、6ヶ月後のモデルのために作ること。変に聞こえますよね。プロダクトが機能しなければPMFは見つけられない。でもこれをやるべき理由は、今のモデルでPMFを見つけたとしても、次のモデルのために作っている人に追い抜かれるから。新しいモデルは数ヶ月ごとに出るので。モデルを使って、何が得意かの境界を感じ取って、6ヶ月後のモデルだと思うものために作る。
二つ目は、Claude Codeチームのスペースに「苦い教訓（The Bitter Lesson）」のコピーを額に入れて飾っています。Rich Suttonの論文です。読んでいなければぜひ読んでほしい。アイデアはシンプルで、より汎用的なモデルは常により特化したモデルを上回る、ということ。要するに、モデルに逆張りするな、ということです。Claude Codeに機能を追加することもできる、スキャフォールディングと呼んでいるモデル以外のすべてのコードです。でも数ヶ月待てばモデルが自分でできるかもしれない。常にこのトレードオフを考える。今エンジニアリング投資をしてある領域の能力を10〜20%伸ばすか、次のモデルを待つか。どこに本当に投資したいかをスキャフォールディングは技術的負債だという前提で考える。
コードの書き直しと生産性向上
Claude Codeのコードは6ヶ月ごとに書き直していますか？モデルが向上したから不要になったスキャフォールディングを削除したこともありますか？
たくさんあります。Claude Codeのコードは何度も何度も書き直されています。ツールを数週間ごとに廃止したり、追加したりしている。6ヶ月前から残っているコードなんて一部もない。80%どころか、もっと新しいかもしれない。数ヶ月くらいかな。コードのライフサイクル自体、賞味期限が数ヶ月という前提でいるのが正しい。
Steve Yaggiの投稿を見ましたか？AnthropicエンジニアはGoogleのピーク時のエンジニアと比べて1000倍の生産性があると書いてあった。3年前は10倍エンジニアの話をしていたのに、今はGoogleのエンジニアのさらに1000倍ですよ。信じられない数字です。
内部で技術系社員は全員毎日Claude Codeを使っています。非技術系でも、営業の半分くらいはClaude Codeを使っている。最近はco-workの方が使いやすいので移行が始まっていますが。チームは去年倍になったけど、エンジニアひとりあたりの生産性は約70%向上した。最もシンプルな指標、プルリクエスト数ですが、コミット数やコミットの寿命とも照合している。Claude Code登場以来、Anthropicのエンジニアひとりあたりの生産性は150%向上しました。
信じられない。私はMetaでコード品質を担当していて、Facebook、Instagram、WhatsApp全製品のコードベースの品質を管理していた。そのとき生産性向上に取り組んでいて、2%の向上が得られたら何百人ものチームが1年かけた成果だった。それが100%向上なんて、前代未聞もいいところです。
Anthropicへの転職の動機
なぜAnthropicに来ようと思ったんですか？
田舎の日本に住んでいて、毎朝Hacker Newsを開いていたら、ある時点からすべてAIの話題になっていた。初期のプロダクトを使ってみたら、本当に息を呑む体験でした。陳腐な言い方だけど、本当にそう感じた。ビルダーとして、あんな感覚は初めてだった。Claude 2の頃か、そのくらいの早い時期の話です。Labs関係の友人たちと話を始めて、共同創業者の一人Ben Mannに会ったら、すぐに引き込まれた。チームの残りのメンバーに会っても同じ気持ちで、二つの理由がありました。
一つ目は、研究ラボとして運営されていること。プロダクトは本当に小さくて、すべては安全なモデルを作ることだけが大事。モデルに近いところで働けて、プロダクトが最重要ではない、モデルが最重要だという感覚が、長年プロダクトを作ってきた後でとても響いた。二つ目は、使命への強いコミットメントです。私はSFを大量に読んでいて、本棚はSFだらけで、どれほど悪い方向に行き得るかも知っている。今年何が起きるかを考えると、本当に凄まじいことになる。最悪の場合、非常に悪いことが起きる可能性もある。だから本当にそれを理解して内面化している場所にいたかった。Anthropicでランチやホールウェイで会話を立ち聞きすると、AI安全性の話をしている。それが全員の最大の関心事です。そういう場所にいたかった。
今年の予測
今年は何が起きると思いますか？
6ヶ月前に振り返ってみると、Darioの予測、AnthropicのコードのうちClaudeによって書かれる割合が90%になるというのは本当になった。私個人はOpus 4.5以来100%になっています。IDEをアンインストールして、一行も手でコードを書いていない。100%Claude CodeとOpusです。毎日20個くらいPRをマージしている。Anthropic全体では70〜90%、チームによっては100%の人もたくさんいる。
5月のClaude Codeリリース時に、IDEでコードを書く必要はなくなると予測していた。当時は完全に非常識な発言でした。聴衆がざわついたくらい。でも指数関数をトレースするだけで見えてくる。Anthropicには創業者3人がスケーリング則の共著者で、これを早い段階で見ていた。指数関数をトレースするだけ。そしてそれは本当になりました。
さらに指数関数をトレースすると、コーディングは誰にとっても基本的に解決される問題になると思います。今すでに私にとっては実質的に解決されていて、すべての人にとってそうなる。「ソフトウェアエンジニア」という肩書きがなくなり始めると思う。「ビルダー」か「プロダクトマネージャー」か、あるいは名残として肩書きは残るかもしれないけど、仕事の中身はコーディングだけじゃない。ソフトウェアエンジニアも仕様を書いて、ユーザーと話す。私たちのチームで見え始めているのは、エンジニアが本当にジェネラリストになっていること。チームのPMもデザイナーもEMも、ファイナンス担当も、全員がコードを書いている。これが至るところで起きていく。これがトレンドを続けた場合の下限。
上限はもっと怖い。ASL4に到達したとき、AnthropicではASL3が今のモデルレベル、ASL4はモデルが再帰的に自己改善しているレベルです。これが起きると、いくつかの基準を満たす前にモデルをリリースできなくなる。極端な場合、バイオウイルスの設計やゼロデイ攻撃への悪用が起きる可能性もある。これは本当に積極的に取り組んでいることです。
Claude Codeを作って、こんなに多くの人に使ってもらえていることは、本当に興奮するし、謙虚な気持ちになります。クールなものを作りたかっただけなのに、本当に役立つものになったのが、これほど驚きで、これほど嬉しいことはないですね。
年末年始と爆発的成長
Twitterや外から見た印象は、みんな休暇から戻ってきてClaude Codeを知って、それから狂乱状態、という感じですが、内部ではどうでしたか？クリスマス休暇中に何かが起きたんですか？
12月はずっと旅行していました。コーディング旅行という感じで、旅しながら毎日コードを書いていた。とても楽しかった。あの頃ThreadsのチームにいたのでしばらくThreadsユーザーでしたが、その頃Twitterも始めて、他のプラットフォームにいる人たちも見るようにしました。多くの人にとってはOpus 4.5を発見した瞬間だったと思います。私はもう知っていましたが、社内のClaude Codeはずっと指数関数的に伸び続けていたので、さらに急激になったということです。
今のClaude Codeを見ると、Mercuryの統計でスタートアップの70%がClaudeをモデルに選んでいるとか、Semi Analysisの統計でパブリックコミットの4%がClaude Codeによるものとか、すべての企業のすべてのコードの中で。大企業から最小スタートアップまでClaude Codeを使っていて、火星探査機パーサヴィアランスのルートプロットにも使われた。これが私にとって一番クールなこと。チームもポスターを印刷したくらい、NASAがこれを選んでいることが嬉しくて。謙虚な気持ちになりますが、これはまだ始まりの始まりという感じもします。
co-workとの関係
co-workとClaude Codeの関係はどうなっているんですか？Claude Codeを見て、非技術系ユーザー向けの新しい仕様を作ったんですか？
これが5回目の「潜在需要」という言葉になると思うけど、まさにそれです。Twitterでトマトの苗を監視するのにClaude Codeを使っている人とか、壊れたハードドライブから結婚式の写真を復元している人とか、ファイナンスに使っている人とかを見た。社内では、デザイナー全員、ファイナンスチーム全員、データサイエンスチーム全員がコーディングのためではなくClaude Codeを使っている。ターミナルにインストールするためにわざわざ苦労して使ってくれていた。しばらく前からこういうものを作りたいと分かっていて、いろんなアイデアを試していたら、デスクトップアプリのGUIでClaudeをラップしたものが上手くいった。実はClaude Codeが裏で動いているだけです。同じエージェント。
FelixとチームがElectronの初期コントリビューターということもあって、そのスタックに詳しくて、10日くらいでビルドしました。100%Claude Codeで書かれた。すぐにリリースできる状態に感じた。非技術系ユーザー向けの調整がいくつか必要で、すべてのコードが仮想マシンで動くようになっていて、削除操作の保護や、権限のプロンプト確認などのガードレールもある。
Borisさん、本当にありがとうございました。睡眠を奪われましたが、その代わりにクリエイターモード、ファウンダーモードを取り戻させてくれた。この3週間は本当に興奮の連続でした。11月からもっと早く始めればよかったと思っています。作ってくれて本当にありがとう。
ありがとう。バグを送ってね。
了解です。ありがとうございました。
コメント