Claude Code 責任者との対話：プログラミングはすでに「解決済み」であり、ソフトウェアエンジニアはやがて Builder に取って代わられる
TechFlow厳選深潮セレクト
Claude Code 責任者との対話：プログラミングはすでに「解決済み」であり、ソフトウェアエンジニアはやがて Builder に取って代わられる
AIに「あなたのために何ができるか」を尋ねてはいけません。ツールを与え、AI自身が行動するようにしましょう。
Web3業界の深掘り報道に専念し潮流を洞察編集・翻訳：TechFlow
ゲスト：ボリス・チェルニー（Claude Code チーフ）
司会：レニー・ラチツキー
ポッドキャスト元：Lenny's Podcast
オリジナルタイトル：Head of Claude Code: What happens after coding is solved | Boris Cherny
放送日：2026年2月19日
要点まとめ
ボリス・チェルニーは、Anthropic 社の Claude Code プロジェクトの創設者兼責任者です。わずか1年という短期間で、彼はターミナルベースのシンプルなプロトタイプを、ソフトウェアエンジニアリングの役割を変革し、あらゆる専門分野に影響を及ぼしつつあるツールへと育て上げました。
今回の対談では、以下のトピックが取り上げられました：
- Claude Code が、素早く開発されたプロトタイプから、公共の GitHub 提出の4%を占めるツールへと成長し、先月の日次アクティブユーザー数が倍増した過程。
- Claude Code の成功の裏にある「直感に反する」製品設計原則。
- なぜボリスは「プログラミングの問題はすでに解決済み」と考えるのか。
- Claude Code および Cowork の開発を支えた潜在的ニーズ。
- Claude Code および Cowork を最大限に活用するための実践的なアドバイス。
- チーム規模を縮小し、無制限のトークン使用権を付与することで、より優れたAI製品が生まれる理由。
- ボリスが一時的に Anthropic を離れて Cursor に参加したが、わずか2週間後に復帰した経緯。
- ボリスが新入社員全員に共有する3つの核心原則。
注目すべき見解の要約
Anthropic 離脱・復帰の真実
- 「私を Anthropic に惹きつけたのは、そのミッション——つまり『安全性』でした。Anthropic で誰かを捕まえて『なぜここにいるのですか？』と尋ねれば、答えは必ず『安全性』です。このミッション主導の文化は、私にとって非常に強く共鳴します。これは私が個人的に必要とするものであり、これがないと私は決して満足できません。どんなに刺激的な仕事であっても、どんなにクールな製品を開発していても、このミッションがなければ、それは埋められない欠落です。この気づきは、非常に迅速かつ明確に訪れました。」
Claude Code の急成長の理由
- 「Anthropic では、『指数関数的思考』がDNAに刻まれています——共同創立者は『scaling laws』論文の上位3著者であり、私たちが本当に指数関数的に物事を考えていることを示しています。もし当時、Claude Code のコード生成シェアの指数曲線を描き、それを延長して線を引いていたなら、年末には100％を超えることは明らかだったでしょう。」
- 「イノベーションにはロードマップがありません。強制することはできません。人々に空間を与える必要があります——いわば『安心感』を与えるのです。失敗しても構わない、思いつくアイデアの80％がダメでも構わないという心理的安全性を確保することが不可欠です。」
次のフロンティア：プログラミングはすでに解決済み
- 「プログラミングはすでに基本的に解決されています——少なくとも私が行っているような種類のプログラミングについては、完全に解決済みの課題です。なぜなら、Claude がそれを可能にするからです。昨年11月以降、私は手動で1行もコードを修正していません。毎日、10件、20件、30件のプルリクエスト（PR）を提出していますが、すべてが Claude Code によって作成されています。」
転移学習がもたらした予期せぬ恩恵
- 「この『転移学習（transfer learning）』という現象は非常に興味深いものです——モデルにタスクXを教えると、別のタスクYにおけるパフォーマンスも向上します。たとえば、Quad Code（四元コード）技術を導入して以来、当社のエンジニアリングチームの規模は約4倍に拡大しましたが、それ以上に衝撃的なのは、各エンジニアの生産性が200％向上したことです。」
チーム原則①：意図的な「リソース不足（Underfund）」
- 「プロジェクトに意図的に『リソース不足』の状態を設定すると、人々はClaudeを使わざるを得なくなります。エンジニア1人を単独のプロジェクトに配置した場合、彼らが迅速に成果を出す原動力は、仕事をきちんとやり遂げたいという内発的モチベーションに他なりません。そこにClaudeがあれば、大量の作業を自動化できます。」
チーム原則②：エンジニアに無制限のトークンを提供
- 「最初から最適化したり、コスト削減を試みたりしないでください。まずは可能な限り多くのトークンをエンジニアに与えてください。入社後すぐに無制限のトークンを利用できるようにするのは、私が強く支持するアプローチです。なぜなら、これにより人々は自由に『突飛なアイデア』を試すことができるからです。最も興味深く、画期的なイノベーションは、こうした自由な実験の過程から生まれてくるのです。」
印刷機との比喩：『楽しい部分』が変わった
- 「最も適切な比喩は、印刷機です。私はもはやGitの操作やさまざまなツールの調整といった面倒な作業をする必要がありません——これらはそもそも『楽しい部分』ではありませんでした。『楽しい部分』とは、何を構築するかを明確にすること、ユーザーと対話し、大規模なシステムや将来の展望を考えること、そしてチームと協働することです。今では、こうしたことにより多くの時間を費やすことができます。」
次に変わる職業は何か？エージェントがPCに登場
- 「おそらく、エンジニアリングに隣接する多くの職種——プロダクトマネージャー、デザイナー、データサイエンティスト——がまず影響を受けるでしょう。最終的には、PC上で完遂可能なあらゆる業務へと拡大していくと考えられます。『エージェント』の真の意味とは——ツールを活用できるLLMのことです。単に話すだけではなく、実際に行動し、あなたのシステムとインタラクションできる存在です。」
キャリアパスの再編成：『ビルダー』がエンジニアを代替
- 「今年末までには、これらの境界線はさらに曖昧になり、一部の地域では『ソフトウェアエンジニア』という職名が『ビルダー』に置き換えられるか、あるいは全員がプロダクトマネージャーとなり、同時に全員がコードを書くようになるでしょう。報酬が最も大きいのは、好奇心旺盛で博識かつ複数の分野を横断できる人材です。」
現代版「潜在的ニーズ」フレームワーク
- 「従来の潜在的ニーズのフレームワークは、ユーザーが何をしているかを観察することに基づきます。しかし、私が見ている現代版のフレームワークは少し異なります：モデルが何をしようとしているかを観察し、それをより容易にすることです。製品そのものがモデルであり、我々はそれを可能な限り露出させ、最小限のラッパーで包むことで、モデル自身がどのツールを、どのような順序で実行するかを判断できるようにしたいと考えています。」
AIを用いて10日間でCoworkを構築
- 「Coworkの誕生は、まさに『潜在的ニーズ』から生まれました——私たちは、人々がClaude Codeを使って非技術的な作業を行っている様子を観察しました。最終的な解決策は、10日間かけて、すべてClaude Codeで構築することでした。Coworkには非常に精密なセキュリティシステムが組み込まれており、そのコードはすべてClaude Codeによって作成されました。」
Anthropicの三層セキュリティ体制
- 「第一層は、アライメント（価値観の一致）と機械的解釈可能性（mechanistic interpretability）です。第二層は、評価（Eval）——実験室環境での検証です。第三層は、モデルが現実世界でどのように振る舞うかを観察することです。我々は、自分たちが準備できたと感じるよりも早くリリースする必要があります。そうすることで初めてフィードバックを得ることができ、リリース後の段階でも、アライメントやセキュリティに関する新たな知見を得続けることができるのです。」
『エージェント停止不安症』について
- 「朝起きたら、まずiPhoneのClaude iOSアプリを開き、前夜のエージェントの進捗を確認するのが習慣になっています。ある意味で確かに少しばかりの不安があります——『どこかのエージェントが止まってしまい、私の生産性が大きく落ちている』という感覚です。正直言って、iOSで『コードを書く』ことになるとは全く予想していませんでした。」
AI製品開発の核心原則
- 「モデルが何をしてくれるかを問うのではなく、モデル自身が自ら行動できるよう、どのようなツールを提供するかを考えるべきです。過度に管理したり、箱の中に閉じ込めたりしてはいけません。常に『6ヶ月後のモデル』に向けて構築してください。今日のモデルではなく、その未来のモデルのために構築すれば、そのモデルが登場した瞬間に、あなたの製品は一気に飛躍します。」
専門ユーザー向けのテクニック：プランモード（Plan Mode）
- 「私は、およそ80％のタスクを始める際に、まずプランモードを使います。これは非常にシンプルで、プロンプトに『まずコードを一切書かないでください』という一文を挿入するだけです。計画が妥当だと判断できたら、その後にモデルに実行を指示します。最も強力なモデル（Opus 4.6）を使用すると、むしろコストが下がることが多いです。」
なぜボリスは一時的にAnthropicを離れてCursorに移り、また戻ってきたのか？
司会 レニー：およそ6か月前、あなたはAnthropicを離れてCursorに加入されましたが、わずか2週間で戻ってこられました。いったい何が起こったのでしょうか？
ボリス・チェルニー：
これは私が経験した中で最も速い転職でした。Cursorに加入したのは、自分がその製品の熱狂的なファンだったからです。チームにも会い、とても尊敬しました——素晴らしいチームで、とてもクールなものを開発しており、AIによるプログラミングの方向性を多くの人よりも早く見抜いていたと感じました。そのため、その製品を完成させるという挑戦そのものが、私にとって非常に魅力的でした。しかし、そこに到着した瞬間から、私が本当に懐かしんでいたのはAnthropicのミッションであることに気づき始めました。それが、当初私がAnthropicに加わろうとした動機でもあります——私は以前、大手テクノロジー企業で働いていましたが、ある実験室の中で、この狂気じみた出来事の未来を、ある形で一緒に形作ることを望んでいたのです。
私をAnthropicに引きつけたのは、そのミッション——つまり『安全性』でした。Anthropicで誰かを捕まえて『なぜここにいるのですか？』と尋ねれば、答えは必ず『安全性』です。このミッション主導の文化は、私にとって非常に強く共鳴します。これは私が個人的に必要とするものであり、これがないと私は決して満足できません。どんなに刺激的な仕事であっても、どんなにクールな製品を開発していても、このミッションがなければ、それは埋められない欠落です。この気づきは、非常に迅速かつ明確に訪れました。
Claude Code 一周年
司会 レニー：さて、Anthropicとそこで達成された成果に戻りましょう。このポッドキャストが公開される頃には、Claude Codeのリリースからちょうど1年になります。あなたもご覧になったと思われるSemiAnalysisのレポートによると、GitHub上の公開提出の4％がClaude Codeによって生成されており、年末までには5分の1に達するとの予測が出ています。このポッドキャスト収録当日、Spotifyはニュースを発表し、同社の最高レベルのエンジニアが12月以降、一行もコードを書いておらず、すべてAIに依存していると伝えました。この1年間の影響について、あなたはどのような振り返りをお持ちですか？
ボリス・チェルニー：
これらの数字は本当に驚くべきもので、私の予想をはるかに上回っています。しかもこれらはあくまで公開リポジトリの記録に過ぎず、プライベートリポジトリを含めれば、数字はさらに大きくなるでしょう。しかし、私にとって最も驚くべき点は、現在の数字そのものではなく、私たちの成長速度です——あらゆる指標において、Claude Codeの成長率は継続的に加速しており、単に上昇しているだけでなく、その上昇スピード自体がどんどん早くなっているのです。当初Claude Codeを立ち上げたとき、それは単なる小さなハックにすぎませんでした。Anthropicは、プログラミング向け製品を開発したいという大まかな方針を持っており、長年にわたってモデルを構築してきた方法論には一定の軌跡がありました：まずモデルをプログラミングにおいて極めて優れた存在にし、次にツール利用において極めて優れた存在にし、さらにその後はコンピュータ操作において極めて優れた存在にする——これは安全上の配慮からも当然の流れです。なぜなら、AIの能力が高まるにつれ、責任ある形で発展させていくことが求められるからです。
Claude Codeの起源物語
ボリス・チェルニー：
Anthropicに加入した後、私はまず1か月間、さまざまな奇妙なプロトタイプを作成しましたが、ほとんどはリリースされませんでした。その後、1か月間は後訓練（post-training）を行い、研究側の理解を深めました。良い仕事をするには、自分の作業の背後にあるレイヤーを理解する必要があると私は考えています。AIの分野では、ある程度モデルを理解しなければ、優れた製品を作ることはできません。
Claude Codeの最初のバージョンは「ClaudeCLI」と呼ばれ、いくつかのツールを活用する様子がデモンストレーションされました。私が最も衝撃を受けた瞬間は、bashツールをモデルに与えた際、モデルが自らそのツールを用いて「今、私は何の音楽を聴いているか？」という問いに答える方法を推論したことです。これは非常に不思議な出来事で、私はモデルに対して「このツールを使ってこのタスクを実行せよ」と指示したわけではありませんでした。モデルが自ら推論したのです。これを社内に共有したところ、反応は「いいね」が2つだけでした。なぜなら、誰もがプログラミングツールと言えばIDEを連想し、ターミナルで動作するものなど想像もしなかったからです。ターミナルというデザインは確かに奇妙で、非常に異質なものでした。しかし、当時私がターミナルを選んだのは、最初の数か月間、私一人で開発していたため、ターミナルが最も簡単に構築できる手段だったからです。
これは重要な製品設計の教訓です——初期には、若干のリソース投入を抑えることが有効です。その後、他の形式への移行を検討しましたが、最終的にターミナルに固執することを決めた最大の理由は、モデルの改良スピードがあまりにも速かったため、他の形式ではその進化に追いつくことができないと判断したからです。これは私が深夜に何度も考え続けた問いでした：モデルはまだ進化し続けていますが、我々はどうすればよいでしょうか？その答えとして私が思いついた唯一の選択肢がターミナルであり、結果としてリリース直後から急速に人気を博し、Anthropic内部では爆発的なヒットとなり、日次アクティブユーザー数はほぼ垂直に上昇しました。
2月に一般公開した際には、即座に成功したわけではありません。数か月が経って、大多数の人々がようやくこのツールの本質を理解し始めました。それはあまりにも斬新で、Claude Codeが成功した理由の一つは、「潜在的ニーズ」という概念に根ざしています——我々は、人々が既に活動している場所にツールを持ち込み、既存のワークフローをわずかに容易にするというアプローチを取りました。もちろん、ターミナルという形態であるため、やや馴染みにくく、それを使用するにはオープンマインドで学ぶ姿勢が必要です。現在では、Claude CodeはiOSおよびAndroidアプリ、デスクトップアプリ、Web版、IDEプラグイン、Slack統合、GitHub統合など、エンジニアがいる場所ならどこにでも存在し、より親しみやすく使いやすいものとなっています。当初、このツールが実際に機能するということ自体が、すでに驚きでした。チームが成長し、製品が進化するにつれ、小さなスタートアップから世界最大のテクノロジー企業に至るまで、世界中のユーザーがこのツールを採用し、フィードバックを送ってくれています。この1年を振り返ると、我々はユーザーから学び続け、誰もが何をやっているのか正確には把握しておらず、皆で一緒に模索している状況でした。
AIがソフトウェア開発を変えるスピードはどれほど速いか？
司会 レニー：あなたは1年前にこの製品をリリースしました。AIでコードを書くツールとしては初のものではありませんでしたが、1年の間に、ソフトウェアエンジニアリング業界全体が劇的に変化しました。当初は「AIが100％のコードを書く？ありえない！」と言われていましたが、今では「当然だ、それが今起きていることだ」と言われるようになりました。変化のスピードはあまりにも速いです。
ボリス・チェルニー：
2025年5月のCode with Claudeカンファレンスで、私は短いスピーチを行いました。Q&Aセッションで、来賓から「年末までの予測は？」と質問されました。私はこう答えました：「年末までには、コードを書くためにIDEを必要としなくなるかもしれません。」実際、すでにIDEを使わずにコードを書くエンジニアが現れ始めています。その言葉を口にした瞬間、会場から一斉に息を呑む音が聞こえました。当時、この予測はあまりにも突飛に思われましたが、Anthropicでは、指数関数的思考がDNAに刻まれています——共同創立者は「scaling laws」論文の上位3著者であり、我々は本当に指数関数的に物事を考えています。もし当時、Claude Codeのコード生成シェアの指数曲線を描き、それを延長して線を引いていたなら、年末には100％を超えることは明らかだったでしょう。私は実際にそうしたのですが、その予測が私自身に実現したのは11月であり、それ以降ずっと続いています。今では、多くの顧客でも同様の状況が見られます。
AIイノベーションにおける実験精神の重要性
司会 レニー：あなたが語られたこの旅は非常に興味深いものです——何が起こるかわからないまま、ただ遊びながら試すという感覚。これは、AI分野における多くの最大級のイノベーションの核となる要素であり、多くの人が、他の大多数よりも遥かに先のところまでモデルを押し進めているのです。
ボリス・チェルニー：
イノベーションに関して、一つ確かなことがあります：それはロードマップが存在せず、強制することができないということです。人々に空間を与える必要があります——いわば『安心感』を与えるのです。失敗しても構わない、思いつくアイデアの80％がダメでも構わないという心理的安全性を確保することが不可欠です。同時に、ある種の説明責任も必要です：もしアイデアがうまくいかなかったら、損失を認め、次に進むのです。深みに嵌まってはいけません。Claude Codeの初期段階では、このツールが本当に役立つかどうか、私もまったくわかりませんでした。2月に一般公開した時点でも、私のコードのうち約20％しか生成していませんでした。5月になると、その割合は30％程度に上がりましたが、それでも私はCursorを使って大部分のコードを書いていました。100％を超えたのは11月になってからです。しかし、最初の日から、何か大きなものに触れたという感覚がありました。私は毎晩、週末もこのツールを研究していました。時には、ある手がかりを見つけたら、それを最後まで追い続けるしかないのです。
ボリスの現在のプログラミングワークフロー（100％AIによるもの）
司会 レニー：つまり、現在のあなたのプログラミングは、100％Claude Codeによって行われているということですね？
ボリス・チェルニー：
はい、100％のコードがClaude Codeによって作成されています。私はかなり多産なエンジニアですが、Instagram時代でも、私は会社内で最も多産なエンジニアの一人でした。この傾向はAnthropicでも変わっていません。毎日、10件、20件、30件のPRを提出していますが、すべてがClaude Codeによって作成されています。11月以降、私は手動で1行もコードを修正していません。
私は依然としてコードを確認します——完全に任せっきりにしてしまう段階にはまだ至っていないと私は考えています。特に多くの人があなたのプログラムを使用している場合には、それが正しくかつ安全であることを保証する必要があります。Anthropicでは、Claudeによる完全自動コードレビューも実施しており、100％のPRがClaudeによってレビューされていますが、その後に人工によるレビューも行われています。これらのチェックポイントには意義があり、完全なプロトタイプコード（実際に稼働させないもの）でない限り、省略すべきではありません。
次のフロンティアとは何か？
司会 レニー：AIが100％のコードを書くというこの驚くべきマイルストーンは、今や「当然のこと」として受け入れられています。では、次にソフトウェア開発の方法論を大きく変えるものは何でしょうか？
ボリス・チェルニー：
今まさに起きていることの一つは、Claudeが自らアイデアを提案し始めてきたことです。フィードバックやバグ報告、テレメトリーデータを見ながら、修正案やリリース候補機能を提案し始め、まるで同僚のように振る舞っています。もう一つは、プログラミングからさらに広がり始めたことです。現時点で、プログラミングは基本的に解決済みと言っても過言ではありません——少なくとも私が行っているような種類のプログラミングについては、完全に解決済みの課題です。なぜなら、Claudeがそれを可能にするからです。
そこで我々は今、次に何が来るのか？プログラミングの先には何があるのか？という問いを立て始めています。周辺領域には多くの可能性があり、それが次に到来するものだと私は考えています。また、より汎用的なタスクもあります——私は今、Coworkを使ってプログラミングとはまったく関係のないさまざまな作業を毎日行っています。先日は、Coworkを使って駐車違反の罰金を支払いました。また、私のチーム全体のプロジェクト管理もすべてCoworkが担当しており、スプレッドシートとSlackの間で情報を同期したり、メールを送信したりしています。そのため、フロンティアはまさにここにあると私は感じています。プログラミングはすでに基本的に解決済みであり、今後数か月のうちに、業界全体のさまざまなコードベースやテクノロジースタックが次々と解決されていくでしょう。
司会 レニー：Claudeが『次に何をすべきか』をあなたに提案してくれるのは、とても興味深いですね。多くの視聴者はプロダクトマネージャーですが、彼らはおそらく冷や汗をかいているでしょう。あなたはこれをどのように使っているのですか？
ボリス・チェルニー：
最も簡単な方法は、Claude CodeまたはCoworkを開き、Slackのチャンネルを指定することです。私たちは、Claude Codeの内部フィードバックを収集するための専用チャンネルを設けており、これは内部リリース当初から存在し、常に途切れることのないフィードバックの流れが続いています。初期には、誰かがフィードバックを投稿すると、私はすぐにその場で、可能な限り速くすべての問題を修正しました——1分か、5分か、非常に迅速なフィードバックループでした。これは、ユーザーが自分の声が届いていると感じさせ、満足させる効果がありました。通常、製品を使ってフィードバックを送っても、それはブラックホールに消えてしまい、二度とフィードバックを送ろうとは思わなくなるものです。しかし、ユーザーが自分の声が届いていると感じれば、彼らは継続的に貢献し、製品の改善に協力し続けます。今も私は同じことをしていますが、Claudeがその大部分の作業を担っています。
司会 レニー：Opus 4.6のパフォーマンスは、大幅に向上したのでしょうか？全体として、このモデルの進化はどのようになっていますか？
ボリス・チェルニー：
確かに顕著な向上が見られます。その一因は、プログラミングに特化したトレーニングを行ったことです。Codexは、現在世界で最も優れたプログラミングモデルの一つであり、そのパフォーマンスはさらに向上し続けています。たとえば、4.6バージョンのパフォーマンスは非常に優れており、プログラミング分野のトレーニングのみが向上をもたらしたわけではありません。実際、他の分野で行ったトレーニングも、プログラミングタスクへの転移学習として非常に効果的です。この『転移学習（transfer learning）』という現象は非常に興味深いものです——モデルにタスクXを教えると、別のタスクYにおけるパフォーマンスも向上します。たとえば、Quad Code（四元コード）技術を導入して以来、当社のエンジニアリングチームの規模は約4倍に拡大しましたが、それ以上に衝撃的なのは、各エンジニアの生産性が200％向上したことです。プルリクエストの提出数が大幅に増加した例は、開発生産性の研究に携わる人にとっては、信じがたいほどの成長率です。
私はかつてMetaで働き、Facebook、Instagram、WhatsAppなどのすべてのコードベースを含む、社内のコード品質管理を担当していました。当時、エンジニアの生産性向上に非常に注力しており、コード品質の向上は開発効率の向上に直結するからです。しかし、何百人ものエンジニアが1年間協力しても、生産性の向上は通常数パーセントにとどまりました。
急速なイノベーションの代償
司会 レニー：さらに驚くべきことは、これらの変化がすでに日常的になっていることです。こうした数字を聞くと、AIが私たちの働き方を変えているため当然だと感じてしまうかもしれませんが、ソフトウェア開発、プロダクト構築、さらにはテクノロジー業界全体に及ぶこのような巨大な変革は、前例のないものです。
ボリス・チェルニー：
もちろん、このような急速な変化にはいくつかの課題も伴います。私自身の例で言えば、モデルの更新スピードが速すぎるため、時に過去の思考パターンに囚われ、新しい変化に適応できなくなることがあります。私は、チームに新しく加わったメンバー、特に新卒の若手エンジニアが、AGI（汎用人工知能）の視点からより先見性のある思考でタスクを遂行できるのを目の当たりにし、逆に自分が遅れていると感じることさえあります。
たとえば、数か月前、Claude Codeのメモリ使用量が上昇し、最終的にクラッシュするというメモリリークの問題が発生しました。これは非常に一般的なエンジニアリング課題であり、伝統的な解決法はヒープスナップショットを取得し、デバッガーに読み込んで、専用ツールで分析することです。私もそうしました。しかし、チームの比較的新しいエンジニアは、ただClaude Codeに「ねえ、Claude、リークがあるみたいだけど、見つけてくれる？」と尋ねただけで、Claude Codeは私と同じことをすべて実行しました——ヒープスナップショットを取得し、独自の小さな分析ツールを即座に生成して解析し、問題を特定し、PRを送信しました。しかも、私のより速く解決しました。つまり、長期にわたりモデルを活用している私たちにとっては、常に現在の状況に自分自身を引き戻す必要があります。旧モデル（Sonnet 3.5）の思考枠組みに留まってはいけません。新しいモデルはまったく異なるものであり、その思考の転換は非常に重要です。
Claude Codeチームの仕事原則
司会 レニー：私は、あなたのチームには具体的な仕事原則があると聞いています。その一つは『何かを自分でやるよりも、Claudeにやらせる方が良い』というもので、あなたが先ほど語ったメモリリークの話は、まさにこの原則を体現しています——あなたは自分の原則を忘れ、まずClaudeに試させることを忘れてしまったのです。
ボリス・チェルニー：
もう一つ面白い原則は、「意図的なリソース不足（underfund）」です。リソースが不足していると、人々はClaudeを使うことを余儀なくされます。これは、私たちが繰り返し観察している現象です。時々、エンジニア1人を単独のプロジェクトに配置します。彼らが迅速に成果を出す原動力は、仕事をきちんとやり遂げたいという内発的モチベーションに他なりません。そこにClaudeがあれば、大量の作業を自動化できます。だからこそ、リソース不足は一つの原則なのです。
もう一つの原則は、人々がより速く行動することを奨励することです——今日できることは今日やる、という考え方は、チーム内で非常に重視されています。初期段階ではこれが特に重要でした。なぜなら、当時は私一人しかおらず、私たちが持っていた唯一の優位性はスピードであり、この激しい競争のプログラミング市場で生き残るための唯一の手段だったからです。しかし、今日に至るまで、この原則は維持されています。より速く進めるための良い方法は、Claudeに多くの作業を任せるということであり、この二つの原則は相互に促進し合っています。
なぜエンジニアに無制限のトークンを与えるのか？
司会 レニー：『リソース不足』という概念はとても興味深いです。通常の考え方は、AIが少ない人数でより多くの仕事を可能にすることです。しかし、あなたはこう言っています：AIは単にスピードを上げるだけでなく、むしろ少ない人数で運用することで、AIツールからより多くの恩恵を得られるというのです。
ボリス・チェルニー：
その通りです。優秀なエンジニアを雇えば、彼らは必ずやり遂げます。これは、私がCTOやさまざまな企業の関係者に頻繁に話すテーマでもあります。私のアドバイスは常におおむねこうです：最初から最適化したり、コスト削減を試みたりしないでください。まずは可能な限り多くのトークンをエンジニアに与えてください。今では、いくつかの企業がこれを福利厚生として導入し始めています——入社後すぐに無制限のトークンを利用できるようにする、というものです。これは私が強く支持するアプローチです。なぜなら、これにより人々は自由に『突飛なアイデア』を試すことができるからです。アイデアがうまくいったら、その時点でスケールや最適化の方法を考えればよいのです。そのときにHaikuやSonnetでOpusを代替するかどうか、規模を縮小するかどうかなどを検討すればよいのです。しかし、最初の段階では、とにかく大量のトークンを使って、アイデアが機能するかどうかを試すことが重要です。エンジニアにその自由を与えるのです。
司会 レニー：これを聞いている人は、『もちろん、彼はAnthropicで働いているのだから、トークンをたくさん使ってほしいと思っているに違いない』と思うかもしれません。しかし、あなたが言っているのは、最も興味深く、画期的なイノベーションが、こうした自由な実験の過程から生まれてくるということです。
ボリス・チェルニー：
その通りです。そして現実には、小規模な状況では、エンジニアが個人的に実験する場合、トークンのコストはその給与やその他の運用コストと比べて、相対的に低いのです。コストが本当に増加するのは、あるアイデアが実際に機能し、スケールが拡大したときです。その時点で最適化を検討すべきであり、それより前に最適化を試みるのは得策ではありません。
司会 レニー：トークンのコストが給与を上回る企業を見たことがありますか？
ボリス・チェルニー：
Anthropicでは、一部のエンジニアが毎月数十万ドルのトークンを消費しているのを既に観察しています。また、いくつかの企業でも同様の状況が見られるようになっています。
将来、プログラミングスキルはまだ重要なのか？
司会 レニー：あなたはコードを書くことを懐かしむでしょうか？ソフトウェアエンジニアとして、それがもはやあなたの仕事ではなくなり、少し寂しさを感じますか？
ボリス・チェルニー：
私にとってはとても興味深いことです。なぜなら、私がプログラミングを学んだのは、実用的な目的のためでした。私は独学のエンジニアで、大学では経済学を専攻し、コンピューターサイエンスは学びませんでしたが、中学からすでにプログラムを書いていました。そして、最初から実用的でした。私はプログラミングを学んだのは、それを『ズル』するために使いたかったからです——グラフィック電卓があり、私はそれに答えをプログラムしました。翌年、問題が難しくなり、問題文すらわからなかったので、小さな代数ソルバーを書きました。その後、小さなケーブルでクラス全員にプログラムを配布し、全員がAを取ったのですが、最後には発覚し、先生に『もうやらないで』と言われました。最初から、プログラミングは私にとって、何かを構築するための手段であり、目的そのものではなかったのです。
その後、私はプログラミングそのものに魅了されることもありました——TypeScriptの本を書き、当時世界最大のTypeScriptオフラインミートアップを立ち上げました。なぜなら、私はこの言語そのもの、関数型プログラミングや型システムに心を奪われたからです。しかし、プログラミングは私にとって本質的にツールであり、何かを成し遂げるための手段です。もちろん、そうではない人もいます。プログラミングそのもののプロセスを楽しむ人もいます。誰もが異なり、この分野が変化しても、この芸術を楽しむ、手でコードを書くというスペースは、常に存在し続けるでしょう。
司会 レニー：あなたは自分のエンジニアリングスキルが劣化することを心配していますか？
ボリス・チェルニー：
私自身については、あまり心配していません。プログラミングは常に進化しています——パンチカード、スイッチ、ハードウェア、紙とペン、そして現在の仮想マシン上で実行されるソフトウェアへと変遷してきました。これは私たちがプログラムを書く方法として、約60年続いてきたものです。それぞれの変遷において、『これは本当のプログラミングではない』と言う人がいました。しかし、私は、今後も下層を理解しようとする気持ちが続くだろうと思います。なぜなら、それがより優れたエンジニアになるための鍵だからです。しかし、おそらくそれはあと1年ほどで終わり、その後は本当にどうでもよくなり、アセンブリ言語がプログラマーにとってどうでもよくなったのと同じような状況になるでしょう。
感情的な面では、私は常に新しいことを学ぶ必要があります。プログラマーとして、これは新鮮さではありません。なぜなら、常に新しいフレームワークや新しい言語があるからです。これは、この分野で私たちが非常に慣れ親しんでいることです。しかし同時に、すべての人に当てはまるわけではなく、一部の人にとっては喪失感やノスタルジア、あるいはスキルの劣化を感じるかもしれません。
印刷機の比喩：AIの影響
司会 レニー：今、常に疑問に思うのは、「私たちはまだプログラミングを学ぶ必要があるのか？」ということです。学校の生徒たちは、まだプログラミングを学ぶ必要があるのでしょうか？あなたの見解では、1〜2年以内に、これはもはや必須のスキルでなくなるかもしれません。
ボリス・チェルニー：
私の見解は、現在四元コード（Quad Code）やスマートエージェント（agents）を使ってプログラミングを行っている人々にとって、まだ基礎的なプログラミングロジックを理解する必要があります。しかし、1〜2年以内には、この理解がそれほど重要でなくなるかもしれません。
最近、私はこのような現象を歴史的に類比するのにふさわしい出来事は何なのかをずっと考えていました。なぜなら、この現象をより大きな歴史的文脈に置き、我々がこれまでに似たような技術的転換を経験したことがあるかどうかを理解する必要があるからです。私が最も適切な類比として思い浮かべたのは、印刷機です。1400年代半ばのヨーロッパでは、識字率は実際には非常に低く——人口の1％未満、つまり貴族や王の下で雇われていた文士のみが読む・書くことができました。多くの支配者自身が文盲であり、その後、グーテンベルクと印刷機が登場しました。驚くべき統計があります——印刷機発明後の50年間に、それ以前の1000年間の合計よりも多くの印刷物が生産されました。印刷物の量は急激に増加し、その後50年間でコストは約100倍低下しました。一方、識字率は、1％未満から世界で70％に達するまでに約200年を要しました。なぜなら、読む・書くことを学ぶのは非常に難しく、教育制度や余暇の時間が必要であり、農地で一日中働くことなどできないからです。
私は、同様の変革が起こる可能性があると考えています。また、興味深い歴史的記録があります——1400年代の文士に印刷機について尋ねたところ、彼らは実際には非常に興奮していました。なぜなら、彼らはこう言ったからです：「私が嫌いなことは、本と本の間で写し写すことだ。私が好きなのは、本の中の絵や装丁だ。」私は、今や私の時間が解放されたことにとても喜んでいる。エンジニアとして、私はこの感覚に強く共鳴します。私はもはやGitの操作やさまざまなツールの調整といった面倒な作業をする必要がありません——これらはそもそも『楽しい部分』ではありませんでした。『楽しい部分』とは、何を構築するかを明確にすること、ユーザーと対話し、大規模なシステムや将来の展望を考えること、そしてチームと協働することです。今では、こうしたことにより多くの時間を費やすことができます。
司会 レニー：そして驚くべきことに、あなたが構築したこのツールは、技術的背景のない人でも使えるようにしました。私は自分自身でいくつかの小さなプロジェクトを進めましたが、行き詰まったときにClaudeが助けてくれました——ライブラリや依存関係に費やしていた苦痛の時間は、今やすべて消えてしまいました。
ボリス・チェルニー：
まさにその通りです。今日の朝、私はあるエンジニアと話しました。彼はGoでサービスを書きました。1か月かかり、すでにかなりうまく動作しています。そこで私は彼の感想を尋ねると、「実は、私はまだGoをよくわかっていません……」と答えました。私は、今後ますますこのような状況が見られるだろうと考えています——それが正しく、効率的に動作していることを理解していれば、すべての詳細を知る必要はないのです。
AIが次に変える職業は何か？
司会 レニー：AIが次に最も早く衝撃を与える職業は、テクノロジー分野内のプロダクトマネージャーやデザイナー、あるいはテクノロジー分野外の職業だと、あなたはどのように考えますか？
ボリス・チェルニー：
私は、エンジニアリングに隣接する多くの職種——プロダクトマネージャー、デザイナー、データサイエンティスト——がまず影響を受けるだろうと考えています。最終的には、PC上で完遂可能なあらゆる業務へと拡大していくと考えられます。なぜなら、モデルはこの分野でますます強力になっていくからです。Coworkは、こうした業務に到達するための最初の手段ですが、それは単なる第一歩にすぎません。私は、CoworkがAgentic AIを、これまで一度も使ったことのない人々に届け、人々に初めてその感覚を与えていると考えています。1年前のエンジニアリング分野を振り返ると、誰もが『エージェント』とは何かを本当に理解しておらず、誰もが実際に使ったことはありませんでした。しかし、今ではそれが私たちの働き方となっています。
そして、私が非技術的、あるいは準技術的な仕事——たとえばプロダクトやデータサイエンス——に目を向けると、人々が使っているAIはまだ会話型であり、単なるチャットボットです。『エージェント』という言葉は、乱用されており、多くの意味を失っていますが、それは非常に明確な技術的定義を持っています：ツールを活用できるLLMのことです。単に話すだけではなく、実際に行動し、あなたのシステムとインタラクションできる存在です。Google Docsを使ったり、メールを送信したり、PC上でコマンドを実行したりできます。したがって、PCのツールを使うあらゆる仕事が次のターゲットです。これは、Anthropicでこの仕事をすることの重要性と緊急性を感じる理由でもあります——我々はこの問題を非常に真剣に捉えており、経済学者、政策研究者、社会的影響の専門家も含めて、大規模な議論を行うことを望んでいます。そうすることで、社会全体として、どう対応すべきかを一緒に考えることができるからです。これは、我々だけで決めるべきことではありません。
司会 レニー：『ジェヴォンズの逆説』という概念があります——より多くができるようになると、より多くの人を雇うことになります。これはそれほど恐ろしいことではありません。AIがエンジニアリングの仕事の重要な一部となった過程で、あなたは何を経験しましたか？あなたはより多くの人を雇いましたか？
ボリス・チェルニー：
Claude Codeチームは採用を進めています。私自身にとっては、すべてが仕事の楽しみを増幅させています。私は今日ほどプログラミングを楽しんだことはありません。なぜなら、細かい作業を処理する必要がなくなったからです。また、多くの顧客からも同様のフィードバックをいただいています——彼らはClaude Codeを愛しており、それがプログラミングを再び楽しくしてくれると述べています。しかし、この先がどこへ向かうのかは、まだわかりません。私は依然として歴史的な類比を探していますが、印刷機は本当に適切な比喩です——かつて少数の人々のみが持っていた能力——読む・書く能力——が、誰もが使えるものになりました。これは本質的に民主化です。誰もがこの能力を身につけ始め、そうでなければルネサンスは起こり得なかったでしょう。なぜなら、ルネサンスは知識の伝播や文字による記録に大きく依存していたからです。当時、電話もインターネットもありませんでした。文字は、人々が大規模に協調するための手段でした。私は、数年後、誰もがプログラミングできるようになり、誰もがいつでもソフトウェアを構築できるようになる世界を想像します。それによって何が解き放たれるのでしょうか？私はまったく想像できません。1400年代の人々が、その後に何が起こるかを予測できなかったのと同じです。しかし、私は、この移行期間は非常に破壊的であり、多くの人々にとって非常に苦しいものになると確信しています。これは、社会全体で一緒に議論し、対応しなければならない課題です。
AI時代に成功するためのアドバイス
司会 レニー：この激動の時代に、自分の立ち位置をしっかり確保したい人に対して、あなたはどんなアドバイスをしますか？AIツールをたくさん使うこと、最新のものを習得することでしょうか？それ以外にもありますか？
ボリス・チェルニー：
おそらく、これが最初のアドバイスです——これらのツールを使ってみて、それらを理解してください。恐れず、大胆に探求し、最先端を追ってください。2番目のアドバイスは、これまで以上に、博識なジェネラリストになる努力をしてください。たとえば、大学では、多くのCS（コンピューターサイエンス）の学生がコードを書くことを学びますが、他の分野をあまり学びません。せいぜいシステムアーキテクチャなどの知識を少し得る程度です。しかし、私が毎日一緒に仕事をしている最も効果的なエンジニアの多くは、複数の分野を横断しています——Claude Codeチームでは、全員がコードを書きます。私たちのプロダクトマネージャーはコードを書き、エンジニアリングマネージャーはコードを書き、デザイナーはコードを書き、財務担当者はコードを書き、データサイエンティストはコードを書きます。全員がコードを書きます。そして、多くのエンジニアは異なる分野を横断しており、最も優れたのは、プロダクトエンジニアでありながらインフラストラクチャエンジニアでもある人、あるいは優れたデザイン感覚を持つプロダクトエンジニア、強いビジネス的直感を持つエンジニア、ユーザーと対話し、ユーザーのニーズをよく理解できるエンジニアです。したがって、私は、今後数年間で最も報われる人は、単にAIネイティブでこれらのツールを使いこなせる人ではなく、好奇心旺盛で博識かつ複数の分野を横断し、自分が解決しようとしている問題をより広い視野から考えられる人——単にエンジニアリングという狭い視点にとどまらない人——であると考えています。
司会 レニー：エンジニアリング、デザイン、プロダクトマネジメントという3つの独立した分野は、今後も長期的に価値を持ち続けますか？それらは現在、互いに重なり合い、お互いの仕事を行っていますが。
ボリス・チェルニー：
短期的には存続し続けますが、すでにこれらの役割の約50％が重なり合い、多くの人々が実質的に同じ仕事をしているのが現状です。ただし、それぞれの専門性は異なります。たとえば、私が書くコードはやや多いかもしれませんが、私たちのプロダクトマネージャーは、調整、計画、予測、ステークホルダーの管理などに重点を置いています。私は確かに、今年末までには、これらの境界線はさらに曖昧になり、一部の地域では『ソフトウェアエンジニア』という職名が『ビルダー』に置き換えられたり、あるいは全員がプロダクトマネージャーになり、同時に全員がコードを書くようになるだろうと考えています。
調査：AIによって仕事がより楽しくなった職業は？
司会 レニー：私はTwitterで非公式な調査を行いました。エンジニア、プロダクトマネージャー、デザイナーに、AIツールを採用して以来、仕事がより楽しくなったか、それともより楽しくなくなったかを尋ねました。エンジニアとプロダクトマネージャーの70％が『より楽しくなった』と答え、約10％が『より楽しくなくなった』と答えました。デザイナーについては興味深いことに、55％が『より楽しくなった』と答え、20％が『より楽しくなくなった』と答えました。
ボリス・チェルニー：
私は両者の意見をもっと詳しく聞きたいと思っています。Anthropicでは、私たちのデザイナーの多くはコードを書きます——これは採用時に評価する項目の一つであり、非技術職のポジションでも多くの技術面接を行っています。私たちのデザイナーの多くは、AIがもたらした変化を、エンジニアを煩わせずに自分自身で変更を加えられるという点で、非常に楽しんでいます。また、以前はコードを書かなかったデザイナーが、今ではコードを書き始めているケースもあり、彼らにとってそれはとても良いことです。なぜなら、自分自身で障壁を取り除けるからです。しかし、私はもっと多様な体験を聞きたいと思っています。なぜなら、状況は一律ではないと信じているからです。
司会 レニー：ですから、このポッドキャストを聞いているあなたが、仕事がより楽しくなくなったと感じているなら、ぜひコメントでお知らせください——なぜそれが楽しくなくなったのかを教えてください。なぜなら、大多数のプロダクトマネージャーとエンジニアの70％は、仕事がより楽しくなったと答えているからです。
ボリス・チェルニー：
また、人々が異なるツールを使っていることも観察しています——私たちのデザイナーは、コードを書くためにClaudeのデスクトップアプリをより多く使っています。つまり、デスクトップアプリをダウンロードし、そこにコードタブがあり、Coworkタブの隣に配置されています。実際には、完全に同一のClaude Code Agentが使われており、可能な限り多くのClaudeセッションを同時に実行できます。これを私たちは『マルチパラレルClaude』と呼んでいます。これは、エンジニアでない人にとっては、より自然なインターフェースだと思います。これもまた、『人々が既にいる場所に製品を届ける』という原則に戻ります——人々にワークフローを変えることを求めず、新しいものを学ぶことを強制せず、人々が今何をしているかに関係なく、その作業を少しでも容易にできれば、製品はより良くなり、人々はより好むのです。
製品開発における『潜在的ニーズ』の原則
司会 レニー：『潜在的ニーズ』という原則について教えていただけますか？Coworkのリリース時にそれを言及しましたが、この概念の意味と、潜在的ニーズを解き放ったときに何が起こるのかを説明していただけますか？
ボリス・チェルニー：
潜在的ニーズとは、このような考え方です：もし、あなたが構築した製品が、その本来の設計意図とは異なる方法で人々によって『濫用』され、彼らがやりたいことを実現するために使われているなら、それは製品開発者として、次のステップがどこにあるかを知るための強力な手がかりとなります。たとえば、Facebook Marketplaceです。当時のチームリーダー、フィオナ氏は、この話をよく語っていました——Facebook Marketplaceの起源は、Facebookグループの投稿の約40％が物品の売買に関するものであるという観察から生まれました。人々は、売買のためにFacebookグループを『濫用』していたのです。誰
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
深潮TechFlow
