最終的に私たちがモデルに教えることは、子どもに教えることと同じです。
記事執筆者、出典：機械の心
多くの人々は、AI時代において、嗜好が人間の最後の防衛線であると語るが、ボリス・チェルニーはそうは考えていない。
彼はAnthropicの技術メンバーであり、Claude Codeの主要な構築者の一人です。彼は毎日モデルを使ってコードを書き、モデルを研究するためにもモデルを使っています。そして彼が見ているトレンドは、「味わい」と呼ばれるものが、モデルによって急速に学習されているということです。
「何をすべきか」さえモデルに掌握されてしまったら、人間には何が残るのか？
最近のインタビューで、ボリスはこの話題について語りました。
Claude Code はどのようにして企業の体制を根本的に変えるのか；
モデルがほとんどのコードを書けるようになっても、エンジニアを採用する価値はあるのか？もしそうなら、何を重視すべきか？
なぜAnthropicの内部には多くのMember of Technical Staffがいるのか、明確な職級や分工がないのはなぜですか？
すべての起業家への反直感的なアドバイスは、なぜ「人を少なく雇い、トークンを多く与える」のか？
……
これらの質問は表面上、ある製品の誕生と進化についてですが、それぞれの回答は、すべて同じより根本的な変化、すなわち組織の運営方式がモデル自体によって再定義されていることを示しています。
一方、ボリスの回答は、冷静に考える価値が非常に高い。
Claude Codeはどのようにして生まれたのか？
ホストがBoris Claude Codeの由来を尋ねたとき、彼の答えは少し予想外だった。
彼の説明によると、Claude Code は Anthropic が当初から計画していた核心製品ではなく、ある意味では偶然の産物とも言える。
2024年末、BorisはAnthropicのLabsチームに加わりました。このチームの役割は既存製品の保守ではなく、未来の製品形態を探索することです。一方で、彼らはモデルの能力の限界を常に押し広げており、他方で、これらの能力を真正に引き出す新しい製品を探しています。
当時、チームには非常に強い感覚がありました：モデルは既存の製品をはるかに上回る能力を備えており、しかし市場にはその能力を十分に活用できる製品が存在していなかったことです。特にプログラミング分野でそうでした。
当時、市場に出ているAIプログラミングツールは大半が二つの方向性にとどまっていた。一つは自動補完で、開発者が次の行のコードを完了するのを支援するものであり、もう一つは質問応答アシスタントで、開発者が特定のコードの意味やエラーの解決策を尋ねられるものだった。しかし、ボリスは、当時まだ真正意义上的Coding Agentは存在しなかったと考えていた。
そこでチームは、より大膽な試みを決断した：モデルを補助ツールとして扱うのではなく、それを直接開発の主体にすることにした。ゼロからエージェントを中心に構築されたプログラミング製品を実現した場合、何が起こるかを試してみたかった。
しかしBorisは、初期のClaude Codeは使いにくかったと率直に認めました。
長い間、彼はその作業の約10％～20％しか完了できませんでした。大部分のコードは依然として彼自身が手動で記述する必要がありました。今日人々が見ているClaude Codeは、当時の製品とはまったくの別物です。
なぜAnthropicはコーディングに如此重視しているのでしょうか？
多くの人々は、Anthropicがコーディングを重視する理由は単純だと考えている——プログラミング市場は十分に大きく、商業的価値も十分に高いからだと。しかし、ボリスの説明はまったく異なる。
彼は、Anthropicのオフィスでランダムに従業員を拦って、なぜここに来たのか尋ねれば、ほとんどの場合同じ答えが返ってくるだろう、と述べた：AI Safety。
ボリスの見解では、Anthropicは設立以来、最も核心的な使命はAIの安全性である。解釈可能性研究、アライメント研究、その他のさまざまなセキュリティ分野は、本質的にモデルの行動を理解しようとするものだが、これらの研究はすべて同じ問題に直面している：実験室内でモデルを観察するだけでは不十分であり、研究者はモデルが現実世界に導入された後に何が起こるかを観察しなければならない。
そしてCodingは、ほぼ理想的な実験場である。
作文や絵画、その他のオープンなタスクとは異なり、プログラミングには非常に明確なフィードバックメカニズムがあります。コードが実行できるかどうか、プログラムがテストを通過できるかどうか、コンパイルが成功するかどうかといった答えは、しばしば明確です。同時に、インターネットには膨大な量のコードがトレーニングデータとして提供されています。無数の優れた解答が存在する可能性のある詩の創作と比較して、プログラミングの問題における正解の空間ははるかに収束しており、モデルの能力を検証しやすいです。
そのため、Anthropic は早期から Coding、Tool Use、Computer Use に注力してきました。これらの分野は商業的価値があるだけでなく、モデルが現実世界とどのように相互作用するかを研究するための自然な実験環境を提供します。
この観点から見ると、Claude Codeはプログラマー向けの生産性ツールにとどまらない。ボリスの説明によれば、それはAnthropicが将来のAIシステムを理解するための重要な実験プラットフォームでもある。
Claude Code はなぜ急に強くなったのですか？
Claude Code の起源を紹介した後、ホストは多くの人が知りたいと思う質問を投げかけた。Claude Code が誕生した当初は、Boris の仕事の約10％から20％しかこなせなかったのに、その後何が起きたのか？ 今日、Boris はすでに半年以上、自らコードを書いていないと公に述べている。わずかなタスクしか処理できなかった段階から、開発作業をほぼ完全に引き継ぐまでに、明らかに大きな変化が起こった。
この質問に対して、ボリスの回答は意外にシンプルだった。彼は、外界が製品の機能に注目しがちだが、自分が本当に能力が飛躍した瞬間を振り返ると、その最も重要な理由はただ一つ、モデルが強化されたことだと述べた。
過去1年間、Anthropicチームは確かにClaude Code自体を継続的に改善してきました。彼らは多くのエンジニアリング作業を重ね、さまざまな新しいインタラクション方法や製品形態を追加しました。当初Claude Codeはコマンドラインツールにすぎませんでしたが、その後、デスクトップ、モバイル、Slack、GitHubなどさまざまなシナリオに拡張されてきました。チームは、開発者とエージェントが協力するためのプランモード（Plan Mode）などの新しい機能も次々と試行してきました。しかし、Borisにとっては、これらすべてが増分的な改善にすぎません。
Claude Codeの上限を真正に決定するのは、基盤モデルそのものです。
彼はいくつかの重要な節目を挙げました。Sonnet 4、Opus 4 からその後の Opus 4.5 まで、モデルの能力が向上するたびに、Claude Code のパフォーマンスにも直接反映されました。
その後、司会者が、Claude Code の使用経験がモデル開発に逆に影響を与えるかどうかを質問しました。Boris の回答は、Anthropic の内部では、モデルを開発する人や製品を開発する人を含め、ほぼ全員が毎日 Claude Code を使用しており、会社全体で使われているということでした。
したがって、専用のフィードバックチャネルは存在しません。フィードバック自体が会社の日常業務の一部です。
研究者が使用中に問題を発見すると、モデルチームはその問題を把握します。モデルの能力が向上すると、皆はすぐに実際の業務での変化を実感します。製品とモデルは並行する線ではなく、同じサイクル内で共に進化しています。
Claude Code は Anthropic にどの程度の生産性向上をもたらしましたか？
ボリスは、AIラボで長く働いていると、人々は指数的な成長の考え方を習慣化してしまうと語った。収益、利用量、モデルの能力など、多くの内部指標がいずれも指数曲線のように見えるため、彼らは変化を観察する際に対数座標を使うことにさえ慣れている。
また、コードの出力も同様の傾向を示しています。
Anthropicが過去に公開したデータによると、Claude Codeが社内で広く導入されて以来、エンジニア1人あたりのコード生成量は約3倍に増加しました。しかし、Borisは特に、このデータはすでに古くなっていると強調しました。実際の増加率はこの数値をはるかに上回っています。
より興味深いのは、この成長が会社の規模が急速に拡大している過程で発生していることです。
伝統的な経験則によると、企業のエンジニア数が増えるほど、平均生産性は低下する傾向があります。新入社員はシステムを学ぶ必要があり、ベテラン社員は質問に答える必要が生じ、組織内のコミュニケーションコストは常に上昇します。
しかし、ボリスが観察したのは、その逆の状況だった。かつては新入エンジニアが社内システムに慣れるのに数週間かかっていたが、今はこのプロセスが通常2日で済む。
原因はトレーニング体制が革命的な変化を遂げたことではなく、人々がすでにClaudeに直接質問する習慣をつけたからである。新入社員はデータベースをどのように検索すべきかを知る必要すらない。誰に尋ねるべきかも知る必要がない。Anthropic内部では、「データベースをどう検索するか」と質問されたとき、よく返される答えは「Claudeを開いて、Claudeにデータベースを検索させなさい」である。かつてはベテランエンジニアが身に付けていた多くの暗黙の知識が、エージェントに移行し始めている。Borisにとって、これが最も重要な変化かもしれない。
Claude Codeが向上させているのは、コード生成速度だけではなく、組織内の知識伝達コストを徐々に削減している点です。過去、企業は階層的な師弟関係を通じて知識を伝えてきました。しかし現在、ますます多くの知識がモデルに直接封じ込められています。
穴あきテープからVibe Codingまで、人間はただ再びプログラミングの抽象レベルを向上させただけだ
Claude Code がそれほど優れているなら、Anthropic が新たに採用したエンジニアはまだコードを書くのか？ホストがこの質問を投げかけた後、議論の焦点は「コードを書く」とはどう定義するかに移った。
ボリスの見解では、ソフトウェアエンジニアリングの発展史は、本質的に抽象レベルを高め続けてきた歴史である。
彼の祖父はソ連時代にパッチカードでプログラミングしていた。その時代、プログラマーは紙カードに穴を開け、そのカードをコンピューターに投入して結果を待たなければならなかった。その後、アセンブリ言語が登場し、さらにFortran、Cobolが現れた。その後にはJava、Python、JavaScriptが登場した。毎回、抽象レベルの向上が起こるたびに、誰かが「これは本当のプログラミングではない」と主張してきた。アセンブリを書く人は高級言語を書く人を軽視し、Cを書く人はPythonが簡単すぎると感じた。しかしBorisは、今日起きていることは本質的にそれと変わらないと考えている。人類は再びプログラミングの抽象レベルを引き上げただけなのだ。
彼は、過去一年間の仕事の変化を説明した。最初は、他の開発者たちと同じように：IDEを開き、コードを書き、たまにオートコンプリートを使用する、従来のソフトウェア開発方式だった。
Claude Code が登場した後、彼の作業スタイルは、Claude に要件を説明し、Claude にコードを書かせ、自分自身でチェックして修正するようになった。この段階では、人間は依然としてモデルに直接指示を出している。コードはモデルが生成するだけである。しかし、Boris は、これはあくまで過渡期に過ぎないと考えている。
最近、本当に興味深い変化が起こった。彼は言う。「今では、私はもうClaudeに直接プロンプトを送ることはない。彼の仕事は別の形に変わった。彼は、さまざまな自動実行プロセスやループを書き、それらがClaudeに質問を投げかけ、タスクを分解し、コンテキストを管理し、複数のClaudeインスタンス間の作業を調整する役割を担っている。」
言い換えれば、かつては人がClaudeに指示を出していたが、今はプログラムがClaudeに指示を出す。彼の仕事は、これらの自動化システムを設計することになった。彼はこれを非常に簡潔に要約している：「私の仕事はもはやLoopsを書くことになった。」
ボリスはコードをClaudeにアウトソースするだけでなく、「Claudeとのやり取り」そのものを自動化しているようだ。これはこれまで馴染みのあったCopilotのモードではなく、複数のエージェントが継続的に動作するシステムに近い。
ボリスは、昨年11月に自らのIDEをアンインストールしたと述べた。これは象徴的な意思表示ではなく、1か月以上IDEを開いていなかったため、全く使用していないなら削除するのが当然だと判断したからである。その時期、彼は通常、5〜10個のClaudeインスタンスを同時に実行し、異なるClaudeが異なるタスクを担当し、彼自身は全体のプロセスを監督していた。
エンジニアがコードを書かなくなった場合、採用では何を見るのか？
このとき、司会者が興味深い質問を投げかけました：今日、あるエンジニアがAnthropicに加わりたいと思ったとき、Anthropicは彼をどのように評価するのでしょうか？あるいは、手作業でコードを書く機会がますます減る世界において、企業は一体どのような人材を求めているのでしょうか？
ボリスの回答は、その後の組織形態に関する議論をほぼ直接引き出した。彼は、Claude Code チームが最も好むタイプの人間は、実はジェネラリスト（汎用性の高い人）であると述べた。
理由は単純です。過去のソフトウェア組織には明確な役割分担がありました——ユーザー研究者はユーザーを理解し、デザイナーは製品を設計し、プロダクトマネージャーは要件を計画し、エンジニアは機能を実装しました。それぞれが自分の担当箇所で作業し、まるで生産ラインのようでした。
しかし、Claude Code チームは過去半年で、この分業が急速に崩れ始めていることに気づきました。チームの全エンジニアが、ほぼ毎日、元々「エンジニア」の職務範囲に含まれていなかった多様なタスクをこなしています。誰かがユーザーと直接やり取りし、誰かがインタラクションを設計し、誰かがデータを収集し、データ分析を行い、ダッシュボードを構築しています。誰もが狭い範囲の業務だけに特化しているわけではありません。
ボリスはさらに極端な例を挙げた：Anthropicのデザイナーもコードを書き、財務の同僚もコードを書いている。サティア・ナデラはこのような役割を「ビルダー」と呼んでいる。この呼び方は、「コードを書けるかどうか」ではなく、「アイデアを現実のものにできるかどうか」が真の境界線であるため、より正確かもしれない。
ボリスの視点から見ると、AIは単にプログラマーを置き換えるのではなく、知識と実行の関係を根本的に変えている。過去には、学習コストが高すぎたため、一人が複数の役割を同時に担うことは難しかった。しかし現在、モデルはこれらの能力間の移行コストを着実に低下させている。したがって、将来最も優位に立つのは、特定の分野で最も深い専門家ではなく、異なる分野を素早く横断し、継続的にリソースを統合できる人々である。
これがボリスが、私たちがジェネラリストの黄金時代に入っていると考える理由です。多くのことをやりたい人にとっては、今が歴史上最高の時代かもしれません。
Member of Technical Staff は宣伝ではなく、未来の予演である
ホストは話題を製品から文化と組織設計に移した。彼は、ボリスの役職が「製品ディレクター」や「エンジニアリングディレクター」ではなく、Member of Technical Staffであることに気づき、Anthropicの多くの人がこの役職であることを指摘した。彼は疑問を呈した：これにはどのような利点があるのか？欠点はあるのか？
ボリスは非常に率直でした。彼は最も悪い点として、Slackで誰かにメッセージを送ると、その人の肩書がMTSだが、この人がデザイナーなのか、エンジニアなのか、マネージャーなのか、また何のプロジェクトに携わっているのか全くわからないと述べました。しかし、彼はこの肩書が大好きでした。
彼はMetaでの経験を思い出した。Metaのすべてのソフトウェアエンジニアには、シニアやプリンシパルといった階層なしに、「Software Engineer」という一つのタイトルしか与えられていなかった。当初、彼はこの仕組みを理解できなかったが、後にこれが文化的な設計であることに気づいた。誰かに「上級」というタイトルを与えると、他の人々は敬意からその人の悪いアイデアに反論しづらくなってしまう。一方で、全員を表面上平等な場に置くことで、経験ではなくアイデアそのものが競い合うようになるのだ。
もちろん、彼は、階級がタイトルが消えたからといって実際に消えるわけではないと認めています。誰かがL7であることは知っていますが、タイトルが書かれていないだけです。しかし興味深いことに、多くの場合、本当にわからないのです。
彼は、FacebookでL4エンジニアをしていたときの話をした。あるアイデアを思いつき、直接コネクティビティ担当のVPに会い、「これが私のアイデアです。一緒にやりましょう」と言った。そのVPは彼がどのレベルの従業員か知らなかった。彼はもう一人のVPにも声をかけたが、失敗した。三度目の正直で成功し、チームを組んで製品開発を始めた。
ボリスは、現在彼がClaude Codeチームで毎日同じ状況を見ていると語る。20年、30年の経験を持つベテランエンジニアたちは、もはや適用されない古い習慣を「unlearn」（捨て去る）するために数ヶ月を要する一方で、新卒の大学生がチームに加わると、若者たちは自然にモデル思考で考えるので、彼にClaude Codeをより良く使う方法を教えることができる。
新しいモデルが登場するたびに、すべての人が再キャリブレーションしなければなりません。この時代において、経験は線形に蓄積されるわけではなく、時には負債となることもあります。
したがって、Member of Technical Staffという曖昧に見える役職名は、Borisにとって、年末までにエンジニア、PM、デザイナー、ユーザー研究者の境界がほぼ消えてしまうという即将到来の現実の予兆である。この変化を受動的に受け入れるのではなく、役職を通じて皆を同じ役割、つまりBuilderへと能動的に導くべきだ。
すべての創設者へのアドバイス：雇用を減らし、トークンをより多く発行してください
司会者がBorisに、Anthropicの視点から、2026年末までに組織がどのようにマインドセットを調整すべきか、参加している創業者や企業に対して一般的なアドバイスを求める。
ボリスの最初の言葉は笑いを含んでいた：「できるだけ多くのトークンをすべての人へ。」これは、ジェン・フン・ルンの有名な言葉「買うほど、節約できる」に似ている。
これは冗談ではありません。彼は真剣です。彼が提示した具体的な提案は以下の2つです：
まず、可能な限り多くのトークンを提供し、皆さんが自由に実験できるようにしましょう。
第二に、各プロジェクトでは意図的に「人を少し減らす」のです。あるプロジェクトに4人のエンジニアが必要だと感じたら、実際に割り当てるのは2人だけにし、大量のトークンを渡して、彼ら自身で解決策を見つけるようにします。そうすると、彼らは実際にそれを成し遂げることがほとんどです。彼らは自動化可能なすべてのプロセスを自動化し、自動化されたことで次回はより速く、より安価に実行できるようになります。これは複利効果です。
ホストはこの提案を非常に簡潔に要約しました：人件費を減らし、予算をトークンに移行する。これにより前期コストは上昇するが、継続的コストを大幅に削減できる。プリコンパイルのように、一度だけ面倒な作業を済ませ、その後の繰り返し実行はほぼ無料になる。
ボリスは完全に同意した。ホストはさらに鋭い質問をした。「かつて人々は自分の専門分野に誇りを持っていた。PMは自分が書いた製品記事に、デザイナーは自分の美しいポートフォリオに誇りを持っていた。しかし、12ヶ月のうちに、誰もが『私は〇〇です』というアイデンティティを放棄し、『柔軟で、トークンを消費する袋』になってしまうのか？」
ボリスは言います：「少し違う言い方をするかもしれませんが……はい、だいたいその通りです。」
味わいもモデルに侵食される？最終的に残るのは「価値観」だけ
司会者は、以前にAnthropicの別のメンバーであるJaredと話したトピックに触れ、Borisの意見を聞きたいと考えました：「taste」（嗜好）とはどのように理解されていますか？
ボリスの回答は非常に率直だった。彼は、プログラミングに関して「特別な感性」があると感じたとき、すべて誤りであることが証明されたと語った。
彼はかつて関数型プログラミングを大変好んでおり、HaskellやScalaといった言語が好きだった。Claude Codeの初期コードベースでは、彼は「classを使ってはならず、functionのみを使用する」というルールを定めた。週末にはエンジニアたちがclassを含むコードをこっそりコミットしたが、月曜日には彼に却下されていた。その後、モデルが大規模にコードを書くようになり、モデルは直接classを書き始めた。彼は長く見つめた末、こう言った。「よし、おそらくモデルが正しいのだろう。私のこのこだわりにはそもそも意味がなかったのかもしれない。ビジネスの結果は達成され、さらに速く、コードの品質も悪くない。」
その後、彼はさらに大胆な推論を展開した。現在、誰もが「製品の味わいが最後のアルファである」と言っているが、彼はそのアルファも急速に失われつつあると考えている。
現在、数百のClaudeインスタンスが同時に動作しています。一部はTwitterのフィードバックをスキャンし、一部はGitHubのイシューを確認し、一部はSlackを監視し、自ら次に実装すべき機能を分析しています。現在のアイデアの大部分はまだ不十分で、約20％が良いものです。しかし、次のモデルが登場し、さらに3〜6ヶ月経てば、ほとんどのアイデアが良質になる可能性があります。
司会がさらに追及した：では、人間には最終的に何が唯一無二のものなのか？モデルが決してできないことは何かあるのか？
ボリスは考えた後、価値観と言った。
彼は、最終的に私たちがモデルに教えるべきことは、子供に教えるのと同じことだ、と述べた。つまり、良い存在となる方法、そして単に物事を正しく行うだけでなく、正しいことをする方法である。