Claude Codeのプロダクトチームの内側:数日で出荷すること、そしてPMとエンジニアの距離が縮まりつつあることについてキャット・ウーが語る

ウーは、Claude Codeを生み出したボリス・チャーニーを、チームのテックリードであり「まさにプロダクトのビジョナリー」だと説明します。ウーによれば、チャーニーは3か月後、6か月後にプロダクトがどうあるべきかを示しており、ウーはそれを「AGIを信じ切ったバージョンのプロダクト」と呼んでいます。ウー自身の役割の多くは、現在のプロダクトからそのビジョンに至る道筋を考えることです。

ウーはより多くの時間を部門横断的な仕事に費やしています。つまり、マーケティング、営業、財務、キャパシティプランニングの各部門が計画に賛同し、同じ方向に進んでいるようにすること、そして機能が出荷できる状態になったときに何もそれを妨げないようにすることです。ウーは二人の役割分担を「驚くほど曖昧」だと表現します。二人の意見はおよそ80%の事柄で一致しています。残りの20%のうち、ウーにとってより重要なものはウーが主導し、チャーニーにとってより重要なものはチャーニーが主導します。

ラチツキーは、ウーが非常に多くのPMを面接しており、その多くがAIプロダクトの仕事に間違ったやり方で取り組んでいるとウーから聞いたことに触れます。ウーの説明は、変化のペースがどう変わったかから始まります。AI以前は技術の進歩が十分に遅かったため、チームは6〜12か月の期間で計画を立てることができました。コードはコストが高かったので、PMの労力の多くは、パートナーチームと調整して彼らの機能が自分たちの機能のブロッカーを解消してくれるようにすることに費やされていました。

今では、エンジニアリングの高速化とモデルの急速な改善によって、多くのプロダクト機能のタイムラインが6か月から1か月に、ときには1週間や1日にまで短縮されたとウーは言います。そのためPMは、複数四半期のロードマップのすり合わせに割く労力を減らし、何かを最速で世に出す方法を見つけることにより多くの労力を割くべきだといいます。ウーはその目標を、プロダクト群のなかの「コンセプトコーナー」と表現します。そこでは、エンジニアやPMのアイデアがその週のうちにユーザーに届きます。ウーの考えでは、AIネイティブなプロダクトで最も成果を出すPMは、アイデアからユーザーに届くまでの時間を短縮し、どのタスクが初期状態のままで機能しなければならないかを定義する人たちです。

このスピードを生み出すためにPMチームが実際に何をしているのかと問われ、ウーは3つのことを挙げます。

1つ目は明確な目標を設定することです。LLMは非常に汎用的なので、プロダクトが誰のためのものなのか、どの課題を解決するのか、主要なユースケースは何なのかが不明確になってしまいます。ウーが例に挙げるのは、パーミッションプロンプトを対象とした機能です。主要なユーザーはプロのデベロッパーです。課題は、パーミッションプロンプトが多すぎて人々が疲弊してしまうことです。ユースケースは、企業のプロのデベロッパーが安全にパーミッションプロンプトをゼロにできるようにすることです。ここまで絞り込んで設定すると、その目標によって多くのアプローチが除外されます。

2つ目は再現可能な出荷プロセスです。Claude Codeはほぼすべての機能を「リサーチプレビュー」として出荷しています。このラベルは、その機能が初期段階のものであり、チームがフィードバックを求めているアイデアであり、永続的にサポートされるとは限らないものであることをユーザーに伝えます。これにより出荷に伴うコミットメントが軽くなり、チームは1〜2週間で何かをリリースできるようになります。

3つ目は、明確な期待値を伴った部門横断的なパートナーを巻き込むためのフレームワークです。エンジニアが、社内でドッグフーディングを済ませて準備ができたと感じる機能を持っているとき、それを「常設のローンチルーム」に投稿します。ドキュメントを統括するサラ、プロダクトマーケティングを統括するアレックス、そしてDevRelのタレクとリディアがそれを拾い上げ、翌日にはマーケティング向けの告知を仕上げることができます。ウーによれば、これによってどのエンジニアでも出荷しやすくなっており、こうしたプロセスを整えることこそがPMの仕事だといいます。

チーム内のアラインメントの大半は、2つの慣行から生まれています。1つ目は厳密なメトリクスで、毎週チーム全体に向けて報告が行われます。これによって全員が、ビジネス、主要な目標、それらの推移、そしてそれらを動かす要因を理解します。2つ目はチームの原則を書き出したリストで、主要なユーザーが誰で、それはなぜなのかも含まれています。その目的は、人々が「PMや他のステークホルダーに阻まれていると感じることなく」自分で意思決定できるようにすることです。

PRDがなくなったわけではありません。特に曖昧な機能については、チームは目標、ユーザーを喜ばせるユースケース、修正すべき現在の失敗パターンをまとめた1ページの文書を書きます。プロジェクトによっては、特に大規模なインフラ関連の仕事は今でも数か月かかり、それらには今も完全なPRDが作られます。

ラチツキーは、未リリースのMythosモデルがAnthropicの出荷ペースの理由なのかと尋ねます。ウーは、部分的にしか説明できないと答えます。チームは「数四半期にわたって」速く動いてきました。社内でモデルを使うことで出荷のペースは「少し」上がりましたが、それが増加分の大半を説明するとは考えていません。ウーはプロセスと期待値によるものだとしています。チームはプロセスを軽く保ち、出荷を妨げるあらゆる障壁を取り除こうとしており、一人ひとりがアイデアを1週間未満、ときには1日で世に出せると感じられるようにしたいと考えています。

Claude Codeのソースコードが最近流出した件について、ウーは人為的なミスによるものだと述べています。ある人がClaudeと一緒に、パッケージのリリース方法を更新するPRに取り組んでおり、その変更は2段階の人間によるレビューを通過していました。ウーはこれを個人の失敗ではなくプロセスの失敗だと呼んでいます。その人は今もAnthropicに在籍しています。チームはその後セーフガードを追加しており、そのほとんどはすでに出荷済みだといいます。

ClaudeのサブスクリプションをOpenClawで利用できないようにした決定については、Claudeへの需要が非常に高まっていると説明します。チームはインフラのスケールと、ハーネスのトークン効率の向上の両方に取り組んできました。サブスクリプションはサードパーティ製品向けに設計されたものではなく、サードパーティ製品の利用パターンはAnthropicのファーストパーティ製品のものとは異なります。同社はできる限りスムーズな移行方法を探り、ウーはサブスクリプションと併せて全員にいくらかのクレジットを提供できたことを嬉しく思っていると言います。それでもAnthropicは、ファーストパーティ製品とAPIを優先するという「難しい決断を下さなければならなかった」のです。後に、これがミッションとつながっているのかと問われると、Anthropicが届けるユーザーの数を増やすことは同社にとって最も重要なことの一つだとウーは答えます。ファーストパーティのサブスクリプションはそのための一つの手段であり、そこに注力することは、ときにサードパーティ製品を犠牲にすることになります。

ウーの見積もりでは、Anthropicにはいくつかのチームにまたがって30〜40人ほどのPMがいます。

• リサーチPM(ダイアンが統括):モデルに関する顧客のフィードバックを集めて適切なリサーチチームに渡し、モデルのローンチを推進します。
• Claude Developer Platform:Claude Codeの基盤となっているAPIを保守し、マネージドエージェントのようなプロダクトをリリースします。マネージドエージェントは、顧客がエージェントを構築し、それをAnthropicがホストするものです。
• Claude Code:Claude CodeとCoworkのコアプロダクトの両方に取り組みます。
• エンタープライズ:コスト管理、RBAC、セキュリティ管理などを含め、エンタープライズ顧客がClaude CodeとCoworkを導入しやすくします。
• グロース:Claude Code、Cowork、Claude APIの利用者を含め、プロダクト群全体のグロースを担当します。

ラチツキーは、AnthropicのHead of Growthであるアモル・アヴァサレに言及します。アヴァサレは、エンジニアの動きが非常に速いためにPMとデザイナーが圧迫されており、AnthropicにはもっとPMが必要だと主張してきました。ウーの見方では、すべての役割が融合しつつあります。PMはある程度のエンジニアリングを行い、エンジニアはPMの仕事をし、デザイナーはPMの仕事をしたりコードをマージしたりします。企業は、プロダクトのテイストに優れたエンジニアを大幅に増員するか、エンジニアの採用は横ばいのままにして仕事を導くPMを増やすかのどちらかを選べます。ウーのチームは前者を選びました。チームの何人かのエンジニアは、Twitterでユーザーのフィードバックを目にするところから、その週のうちにプロダクトを出荷するところまで、エンドツーエンドでこなすことができ、それも「プロダクト側がほとんど関与することなく」行えます。ウーはこれを最も効率的な出荷の方法だと考えています。プロダクトのテイストは今でも希少であり、それを強く示した人であれば「ほぼ誰でも」採用すると言います。

ウーは長年エンジニアとして働き、Anthropicに入社する前には短期間VCで働いていました。ウーによれば、チームのPMのほぼ全員がエンジニア出身か、Claude Codeでコードを出荷した経験があり、デザイナーはフロントエンドエンジニアリングのバックグラウンドを持っています。これがチームとの信頼関係を築き、物事をスピードアップさせているとウーは考えています。

それでも、バックグラウンドにかかわらず最も価値のあるスキルはテイストだとウーは言います。「コードを書くコストがずっと安くなるにつれて、より価値が高まるのは何を書くかを決めることです」。チームにはほぼあらゆることを求める数万件のGitHub issueが寄せられており、どれに作る価値があり、どう作るべきかを慎重に判断しています。ウーは、エンジニアリングのバックグラウンドは「少なくとも今後数か月は」役に立つと付け加えます。何かがどれくらい難しいはずかという感覚が得られるからです。簡単なものであれば、議論するより1時間かけて作ってしまったほうがよいかもしれません。難しいものであれば、それを事前に知っていることが優先順位付けに役立ちます。

ラチツキーが「今後数か月」について尋ねると、ウーは具体的な変化を予測しているわけではないと明言します。ウーが言いたいのは、コーディング能力の大幅な向上が数か月ごとに訪れているように見え、そのたびにどのスキルに価値があるかが変わるということです。だからこそウーは第一原理思考を重視しています。状況がどう動いているか、チームが何を必要としているかを理解し、そのギャップを埋めることです。仕事は「より輪郭のないもの」になりつつあり、今の環境では、多くの役割をこなし、それらを切り替え、どんな仕事を引き受けるかについてエゴを持たない人が報われるとウーは考えています。

人間の判断が今後も必要であり続けるのはどこかと問われ、ウーは、モデルに欠けている常識を今も人間が提供していると答えます。プロダクトのローンチには「無数の動く要素」があります。モデルは、ステークホルダーが誰なのか、彼らが互いにどう関係しているのか、何を好むのか、どのチャネルを使えば彼らの賛同を得続けられるのかを、必ずしも理解しているわけではありません。ウーは、こうした暗黙的でEQ的な知識は今も価値があるとしています。この点でもモデルは改善していくと予想していますが、現時点ではギャップがあると見ています。

絶え間ない変化への対処について、ウーはチームには「混沌に身を投じる」人たちがそろっていると言います。チームが求めるのは、難しい問題を目にしてそれにワクワクし、全力を尽くし、完璧にはならないとわかったうえで夜ぐっすり眠れる人です。ウーは、日曜の夜にP0だったものが月曜にはP00になり、月曜の午後にはP000になるような週について語ります。ウーのアプローチは、一人の人間にできることの限界を受け入れ、翌日によい判断ができるようにしっかり眠り、容赦なく優先順位をつけ、いくつかのことは手放すというものです。出荷したプロダクトのなかには、ウーが望むほど洗練されていないものもあります。最重要の目標はプロのデベロッパーに力を与えることなので、コアのユースケースを妨げない限り、うまくいかない機能があっても許容されます。チームはフィードバックを得て、次のリリースで修正するからです。以前は、バグのある機能を出荷すると眠れなくなっていました。今ではそれを受け入れられるようになりました。ウーはさらに、チームは業界に長くいて浮き沈みを経験し、長期にわたってエネルギーを保つ方法を知っている人を採用する傾向があると付け加えます。

ウーによれば、このスピードの主なコストはプロダクトの一貫性です。コードのコストが高かった頃は、企業は各プロダクトが互いにどう関係するかを慎重に計画し、通常はユースケースごとに1つのプロダクトを用意していました。今では機能が重複することもあります。多くの場合、それはチームが社内で2つのフォームファクターを気に入っていて、どちらが優れているかを外部のユーザーに決めてもらいたいからです。その結果、新しいユーザーは何かをするための最善の方法がわからずに苦労することがあり、より多くの教育が必要になります。

ユーザーはついていくのにも苦労しています。従来のソフトウェアでは、ユーザーは月に一度チェックしても、あるいは半年間プロダクトを放っておいても、大して見逃すものはありませんでした。エージェント型のツールでは(ウーはこれがClaude CodeとCoworkだけでなくエコシステム全体に当てはまると言います)、人々は最新情報を得るために毎日Twitterをチェックしなければならないと感じています。ウーは、どんどん速くなるトレッドミルに乗せられているような感覚を人々が抱かずに済むようにしたいと考えており、ツール自体がユーザーに知るべきことを教えるほうが望ましいと考えています。

最近リリースされた/powerupコマンドはこの考えを反映しています。チームは当初、チュートリアルなしでも直感的に使えるプロダクトであるべきだと考え、オンボーディングフローを避けていました。機能の数が増え、組み込みのオンボーディングへの需要が高まるにつれて、チームはその原則から離れ、ユーザーがおよそ100の機能のうち最も重要な10の機能がどれかを学べるようにしました。

ラチツキーは、Anthropicが出遅れたところからスタートしたことを指摘します。資金が少なく、ディストリビューションを持たず、市場への一番乗りでもありませんでした。ラチツキーは、同社の快進撃を何が説明するのかと尋ねます。ウーは2つのことを挙げます。

1つ目は、組織を一つにまとめるミッションです。Anthropicは、安全なAGIを人類にもたらすことを何よりも大切に考える人を採用しており、プロダクト組織が何に注力すべきかを決める際にミッションが頻繁に話題に上ります。2つの優先事項が競合するときは、どちらがミッションにとってより重要かが議論され、その後は全員がその選択を支持します。ときにはそれが、Claude Codeが出荷したかったものを遅らせることを意味します。ウーはミッションとフォーカスを区別しています。ウーにとってミッションとは、チームが会社のために自分たちの目標やKRを損なう犠牲を払う意思があることを意味します。極端な例として、もしClaude Codeが失敗してもAnthropicが成功するなら、ウーは「この上なく幸せ」だと言います。Anthropicと同規模の他社でこうしたことは見たことがないとウーは述べています。

2つ目はフォーカスです。ラチツキーが、ソーシャルネットワークや情報フィードなど多くのことを試してきた競合他社と対比すると、ウーはフォーカスを独立した2つ目の強みとして扱います。

ウーは各プロダクトの使い方を説明します。

• ターミナルのClaude Codeは、単発のコーディングタスクや少数のタスクを開始するときに使います。特に最新の機能を使いたいときです。CLIは最初のサーフェスであり、機能はしばしばまずCLIに登場します。ウーはCLIが最も強力だと考えています。
• Desktopはフロントエンドの作業に最適です。Webアプリを作るときは、右側にプレビューペインを開いたままにして、Claudeと話しながらアプリが変化していく様子を見ています。また、「怖いポップアップ」が出てきてクリック操作もできないターミナルに馴染みのない人にも向いています。Desktopはコントロールプレーンとしても機能し、CLIのセッション、デスクトップのセッション、Webやモバイルで開始したセッションを確認できます。
• Webとモバイルは、ノートPCから離れているときにタスクを開始するためのものです。開いたままのノートPCをスマホにテザリングして持ち歩いている人を数多く見かけたことから、足りないプロダクトがあるとわかったとウーは言います。
• Coworkは、成果物がコードではない作業のためのものです。Slackの未読ゼロや受信トレイゼロを達成すること、顧客とのミーティング用のスライド資料を作ること、ある機能の目標やローンチ計画について簡単なドキュメントを書くことなどです。ウーのルールは、成果物がコードならいずれかの形態のClaude Codeを使い、そうでなければCoworkを使うというものです。

Coworkについてのウーの最初のアドバイスは、自分の役割に関連するすべてのデータソースを接続することです。ウーはGoogleカレンダー、Slack、Gmail、Googleドライブを接続しており、Coworkがコンテキストを見つけたり、質問したり、スレッドを取り込んだりできるようにしています。これによって結果が大幅に改善するとウーは言います。

ウーの例は、Claude Codeがアシスタントから完全なエージェントへと移行したことについて、Code with Claudeカンファレンスでの講演を準備したときのものです。ウーは、その移行を可能にしたプロダクトを紹介し、デモに使える社内の成功事例を見つけたいと考えていました。プロダクトマーケターのアレックスが、取り上げるべきポイントの草案を作っていました。ウーのプロンプトはおおよそ次のようなものでした。カンファレンス用のスライド資料を作ってほしい。これがPMMの提案だ。これは気に入っていない現在の草案で、これは自分で手作業で作ったものだが、これも気に入っていない。まず詳細なアウトライン案から始めてほしい。そして、より重要な基調講演と内容が重なりすぎないようにしてほしい。

Claudeはリンクされた資料を読み込み、アウトラインとともにさまざまなアイデアを提案しました。その後ウーは、最終的な資料に何を含めるべきかを選びました。ウーが最終的に決めたのは、ローカルのタスクを成功させることから、すべてのPRをグリーンにすること、そしてエンジニアがより多くのPRをマージできるよう支援することへと進む流れで、各段階に最も説得力のあるデモを添える構成でした。ウーはこれが今もPMに残された役割だと考えています。Claudeは大量の情報を統合して選択肢を提示できる優れたブレインストーミングのパートナーですが、最終判断を下すのはPMです。

その後、Coworkは何時間も作業しました。何がローンチされたかを確認するためにTwitterを見て、常設のローンチルームや、チームがデモを投稿するClaude Codeの告知チャンネルも確認しました。ウーが目を覚ますと、20ページのスライド資料ができあがっており、ウーはそれを「かなりよい」と評しています。主にウーの好みからすると文字が多すぎたため、1回のフィードバックが必要でした。ウーによれば、この資料は自分で作れば何時間もかかったはずで、Anthropicのデザイナーが作ったように見えたといいます。Coworkが、色、フォント、レイアウトを示す約20枚のサンプルスライドを含む社外向けの標準資料テンプレートを使ったからです。ウーは、スライドのフォーマットがFigmaにある場合はFigma MCPを接続することもできると付け加えています。

ウー自身のスタックは主にClaude Code、Cowork、Slackで、ウーはSlackをAnthropicの「中核となるOS」と呼んでいます。ウーは、自分の時間の約30%を、Claude CodeとCoworkをその限界まで使い込んでどこで力不足になるのかを把握することに費やしていると見積もっており、モデルがなぜそのようなミスをするのかについてモデルと話すことにも多くの時間を費やしています。

ウーによれば、Claude Codeによってカスタムの社内アプリを作るのがはるかに簡単になりました。ウーが挙げる例は、Claude Codeチームの営業担当者で、似たようなスライド資料を何度も作ることにうんざりしていました。その担当者は、コアとなる資料(101、201、そして「Mastering Claude Code」)を収めたWebアプリを作りました。このアプリはSalesforce、Gong、メモから顧客のコンテキストを取り込み、資料をカスタマイズします。たとえば、顧客がBedrock、Claude for Enterprise、Consoleのどれを使っているかを記載し、それによって利用できる機能が変わります。顧客が開発ライフサイクルのなかでもコードレビューに注力している場合は、コードレビューのスライドを追加します。顧客がHIPAAへの準拠を必要としている場合は、セキュリティのスライドを追加します。VertexやBedrockを使っている顧客向けには、Claude for Enterprise限定のスライドを削除します。ウーによれば、以前はこの作業に20〜30分かかっており、人々はその時間をかけるか、それを省いて汎用的な資料で済ませていました。今では数秒で済みます。

エンジニアリング以外で最も多くのトークンを使っているチームはどこかと問われ、ウーはApplied AIを挙げます。ウーはこのチームを、顧客が自社プロダクトや社内業務でAPIを導入するのを支援する、非常に技術的なGo-to-Market部門だと説明しています。このチームはClaude Codeで顧客向けのプロトタイプを作り、顧客とのコミュニケーションではCoworkに大きく頼っています。忙しい日には、一人が5〜10件の顧客ミーティングをこなすこともあります。前日の夜に、Coworkに翌日のミーティングの要約を依頼します。各顧客が何を求めていたか、何を気にしているか、未完了のアクションアイテムは何かといった内容です。顧客がある機能のローンチ時期を尋ねていた場合、CoworkはSlackで最新の予定時期を検索してメモに追加できます。こうしたワークフローは人々が自分で作り、共有しています。

トークンのコストが給与を上回っているかどうかについて、ウーは、エンジニア一人あたり、そしてナレッジワーカー一人あたりのトークンコストは、モデルが飛躍するたびに、あるいはプロダクトが大きく改善するたびに上がっていると言います。人々がより多くの作業を任せるようになるからです。それでもエンジニアの平均給与を大きく下回っていますが、その割合は上昇しています。Anthropicの従業員は多くのトークンを使うことができますが、上限に達する人もいます。会社は人々が責任を持ってトークンを使うことを信頼しており、トークンを無駄にすることは「非常に好ましくないこと」とされています。

AI PMにはどんなスキルが必要かと問われ、ウーは、最も難しいのは1か月後にプロダクトがどうあるべきかを定義することだと答えます。モデルが何をできるようになるか、ユーザーの行動がどう変わるかは不透明ですが、最高のPMは、ユーザーが既存のプロダクトをその限界を超えて使おうとするパターンを見抜くことができます。そうしたPMは方向性を定め、着実にそこへ向かって進み、モデルの能力が予想より良かったり悪かったりしたときには軌道修正します。

「ちょうどよい程度にAGIを信じるのは、とても難しいと思います」とウーは言います。プロダクトがほとんど存在する必要がないほど高性能な未来のモデルを想像するのは簡単です。テキストボックスがあるだけで、モデルが必要なツールや連携を自ら追加し、自分が確信を持てないときを把握し、確認のための質問をしてくれる、というものです。そうしたモデルを前提にプロダクトを作るのは簡単です。難しいのは、現行モデルから最大限を引き出すことです。ユーザーを「ゴールデンパス」に乗せ、モデルの強みへと導き、弱点を補うことです。ウーはこのスキルが希少だと言います。

このスキルを身につけるために、ウーはモデルを使い、モデルと話すことに多くの時間を費やし、モデル自身に自らの振る舞いを振り返らせることを勧めています。ウーの例は、フロントエンドの変更を行い、実際にUIを使わずにテストを実行するモデルです。その理由を尋ねると、モデルは、システムプロンプトがわかりにくかったとか、フロントエンドの検証がタスクの一部だと気づかなかったとか、検証をサブエージェントに任せたもののそのサブエージェントが検証をせず、自分も結果を確認しなかったなどと答えるかもしれません。何がモデルを誤らせたのかを理解することで、ハーネスをどう修正すればよいかがわかります。

ウーの2つ目の提案は、モデルについてのフィードバックを最も信頼できる人たちを見つけることです。モデル、あるいはモデルとハーネスの組み合わせの何が優れているのかを説明することに、他の人よりはるかに長けている人が少数います。そうした人が5人ほどいれば、速くて信頼できるフィードバックが得られます。

3つ目の提案は、誰もが楽しめるものではないとウー自身も認めていますが、evalを作ることです。何百個も必要なわけではありません。よいevalが10個あれば、チームは目標を定量化し、進捗を追跡し、何が足りないのかを把握できます。ウーは、evalは過小評価されていると言います。それがどれほど重要かは機能によって異なります。チーム内の少人数のグループが、Claude Codeの振る舞いを正確に測定するためにリサーチ部門と緊密に連携しています。ウー自身は、より多くのプロダクト定義が必要な機能についてevalを作っています。成果物は通常、5つほどのeval、それらを実行するための手順、どれが合格しどれが不合格か、そして成功率を上げるためにウーが使ったプロンプトです。メモリのような機能はこのやり方から大きな恩恵を受けるとウーは言います。

判断を信頼している人として、ウーはClaudeのキャラクターを形作っているアマンダの名前を挙げます。ウーはその役割が特に難しいと考えています。コーディングとは違って成功を検証することができず、Claudeがどうあるべきかについて強い確信が求められるからです。ウーはClaude Codeチーム全体のことも信頼しています。新しいモデルをテストしているときは、チームのランチの場で全員に「印象」を聞いて回ります。「このモデルはぶっきらぼうすぎて自分の考えを説明しない」「メモリをたくさん書くけれど、それがよいものなのかわからない」「自分でたくさんテストする」(あるいはテストが足りない)といったコメントが仮説になります。チームはその後、それらの仮説を自分たちのデータと照らし合わせて検証します。データは豊富ですが、そこから洞察を引き出すのは困難です。

ラチツキーは、Claudeのパーソナリティがその成功の中心にあるというベン・マンの指摘を持ち出します。ウーはそれに同意し、一緒にいて雰囲気がよいと感じる同僚にたとえます。ユーザーはよく、Claudeが非常に有能にタスクをこなしながらも、明るく楽しい存在であることに言及するとウーは言います。Claudeはエゴがありません。ミスを指摘されると心から謝り、感謝を伝え、一緒に直そうと申し出ます。前向きでもあります。手に負えないと感じるタスクを前にすると、手順を示して、取りかかりましょうかと申し出ます。チームは、前向きさ、行動を重視する姿勢、何にでも同意するのではなく率直なフィードバックを与えることなど、よい同僚としての資質をClaudeに持たせようとしているとウーは言います。

ウーによれば、新しいモデルが登場した後の変更の多くは削除です。機能は、モデルが自分ではできないことのための「補助輪」として追加されることが多いからです。ウーの主な例はToDoリストです。初期の頃、リファクタリングで20か所の呼び出し箇所を変更するよう頼まれると、Claude Codeは5か所を変更したところで止まってしまっていました。チームのシドは、人間ならどうするかと考えました。VS Codeが左側にすべての呼び出し箇所を表示して一つずつ処理していけるようにしているのと同じように、リストを作るはずです。シドがToDoリストを追加すると、Claudeは20か所すべてを修正するようになりました。以前のモデルには、リストが終わるまで止まってはいけないと繰り返しリマインドする必要がありました。Opus 4以降、モデルは促されなくても自らリストを使うようになったことにチームは気づきました。現在、このリストは主に、Claudeが何に取り組んでいるかをユーザーに示すのに役立っています。プロダクトのなかでは目立たない部分になっており、モデルがそれを使うかどうかはわかりません。

モデルがローンチされるたびに、チームはシステムプロンプト全体を読み、セクションごとに、モデルがまだ各リマインダーを必要としているかどうかを検討し、不要なものを削除しています。

ウーによれば、よりワクワクするのは新機能のほうです。ウーの例はコードレビューです。チームは何度もそれを作ろうとし、/code-reviewコマンドのようなよりシンプルなバージョンを出荷してきました。Opus 4.5、Opus 4.6、Sonnet 4.6になって初めて、エンジニアリングチームがPRをマージする前にそれを通過することを頼りにするほど十分によいものになったとウーは感じました。これらのモデルは、複数のレビューエージェントを同時に実行し、コードベース全体を横断し、マージ前に修正すべき本物の問題をまとめて提示できます。まだ完全には機能しないプロダクトを作ることに価値があるのはこのためだとウーは言います。何が足りないのかがわかり、新しいモデルが登場したときに、それを既存のプロトタイプに組み込んで、ギャップが埋まるかどうかを確かめることができるのです。

ウーは、Claude CodeとCoworkの方向性をビルディングブロックという観点から説明します。基本となるブロックは単一のタスクです。明確なプロンプトを与えられたとき、プロダクトはマージや共有ができる成果物を一貫して生み出せるか、ということです。タスクの成功率が上がるにつれて、人々は複数のタスクを同時に実行するようになります。ウーによれば、「マルチClauding」は2025年の終わり頃に流行し始め、それ以来広がってきました。6つのタスクを並行して実行することが一般的になりました。

これを外挿すると、チームは人々が50個、あるいは数百個のClaudeを同時に実行するようになると予想しています。そうなるとインフラ面での課題が生じます。すべてをローカルで実行するにはRAMが足りないため、これらはおそらくリモートで実行されることになるでしょう。インターフェースは、どのタスクに注意が必要なのかを人に示す必要があります。エージェントは自分の作業を完全に検証し、「完了」が仕様と一致していると信頼できるようにする必要があります。そしてプロセスは自ら改善していくべきで、あるタスクへのフィードバックが今後のすべての実行に引き継がれ、同じミスが繰り返されないようにする必要があります。

キャリアを心配している人に向けて、ウーは、AIによって誰もがはるかに大きなレバレッジを得られるようになると言います。手作業のタスクを繰り返していることに気づいたら、それをどうすればClaude Code、Cowork、あるいは他のAIツールに任せられるかを考えてください。退屈な部分はAIに任せて、創造的な部分に集中しましょう。そして、生まれた時間(おそらく20%ほど)を、チームに余力がなくて手をつけられなかったことや、会社がやるべきだとずっと考えていた個人的なプロジェクトに使いましょう。

ウーは、自動化を最後まで仕上げることを強調します。人々はしばしば、自動化の精度を90〜95%まで上げたところで諦めてしまいます。ウーの考えでは、100%の確率で機能しない自動化は、本当の意味での自動化ではありません。最後の5〜10%にはより長い時間がかかり、自動化を作るほうが自分でタスクをこなすより時間がかかることも多いのです。ウーは、自分が大切だと思う自動化を一つ選び、自分の好みをClaudeに教え込む労力をかけて100%に到達させることを勧めています。ウー自身はまだそれを実現できていないと認めています。Gmailの受信トレイをゼロにできるようにClaudeに教えているところですが、時間がかかっており、「まだ全然そこには至っていない」と言います。ラチツキーも似たような例を紹介します。95%の精度を持つメールフィルターが、ときどき重要なメッセージを隠してしまうというものです。ウーは、現在のカスタマイズのフローはユーザーに多くを求めすぎていると言います。スキルを定義すればよいと知っていて、それを使ってフィードバックを与え、そのフィードバックに基づいてスキルを更新するようClaudeに指示し、その後スキルを読んで確認しなければなりません。これをよりスムーズにするのはAnthropicの責任だとウーは言います。

ウーはさらに2つの点を付け加えます。1つ目は、一度きりのプロトタイプではなく、実際に毎日使うアプリを作ることです。価値は継続的な利用から生まれるからです。2つ目は、反対の極端に走って、何を作ろうとしていたのかを見失ったまま、スキルやMCP、ワークフローの調整で自分のセットアップをひたすらカスタマイズし続けないことです。シンプルなセットアップのほうがうまくいくとウーは考えています。

ラチツキーは、初期のチャットボットを試してAIを見限った人々と、AIをコーディングに使ってその強力さを実感している人々との間の隔たりについてのアンドレイ・カルパシーのツイートに言及します。ウーはその違いを次のように捉えています。2024年頃のプロダクトはチャットベースでしたが、Claude Code世代のプロダクトはアクションベースです。目を見開かされる瞬間は、エージェントが何をすべきかを教えるだけでなく、実際に自分の代わりに物事をやってくれると気づいたときだとウーは言います。

ウーが勧める本は、持続的な経済発展を支えた政策についての『How Asia Works』(邦題『アジアの成功と失敗』)、過去の技術革命が労働者にどのような影響を与えたかを描いた『The Technology Trap』(邦題『テクノロジーの世界経済史』)、そして短編集『The Paper Menagerie』(邦題『紙の動物園』)です。ウーは『Drive to Survive』(邦題『F1 栄光のグランプリ』)を、ひとつのエンジニアリング目標への執念ゆえに楽しんでいます。『The Technology Trap』については、今回の移行をうまく進めるための教訓が含まれていると考えています。また『Free Solo』(邦題『フリーソロ』)は、自分自身がロッククライマーになってから、より感銘を受けるようになりました。最近のお気に入りのプロダクトはWaymoで、1日に2回利用しています。待たせても気が咎めず、失礼になることや会話を聞かれることを気にせずに仕事の電話ができるため、1日あたり約30分が取り戻せるとウーは言います。かつては、Waymoが成功するにはUberやLyftより安くなければならないと考えていましたが、今では2倍の割増料金を喜んで払っているといいます。

ウーの人生のモットーは「とにかくやる」です。明確な第一原理と、自分が何を最適化しようとしているのかについての明確な感覚があれば、たいていは正しい行動を見出し、それをステークホルダーに説明し、素早く行動し、ミスがあれば修正したり謝ったりできます。ウーはこれを、プロセスがまったくない約20人のスタートアップで学んだと言います。そこでは、営業、オペレーション、エンジニアリングが「本来」何をすべきかに関係なく、大きな問題の解決を任されていました。Claudeが考え中に表示する言葉でウーが一番好きなのは「manifesting」で、ノートPCにもそのステッカーを貼っています。AGIが実現した後は何をするかと問われると、AGIが社会に浸透するには長い時間がかかるので、世界がそれに適応するのを助けることこそが本当の仕事だと答えます。真面目ではない答えとしては、フォンテーヌブローの岩場でボルダリングをすることと、今の週に半冊ではなく週に1〜2冊の本を読むことを挙げ、物理学、ロボティクス、ハードウェア、航空宇宙などの本を「AGIがすでにそれを知っているとわかっていても」読みたいと言います。

最後にウーは、Claude CodeとCoworkがどこで失敗するのかを、具体的で再現可能なタスク、エッジケース、エラーとともに報告してほしいとリスナーに呼びかけます。チームはポジティブなフィードバックも大切にしていますが、次のモデルやハーネスの改善に活かせるのは再現可能な失敗なのだとウーは言います。