初心者向け
Cat Wuが数百人のPM候補を面接、ほぼ誰も正解できなかった質問：AIプロダクトマネージャーは実際に何をすべきか？
Cat Wuが数百人のPM候補を面接し、ほぼ誰も正解できなかった質問：AIプロダクトマネージャーは実際に何をすべきか？
Cat WuはAnthropicのClaude CodeおよびCoworkのプロダクトリーダーです。Boris Chernyと協力し、チームを率いてプロダクト機能の提供サイクルを6ヶ月から1日に短縮しました。Lenny's Podcastの最新エピソードで、CatはAnthropicの内部スピード文化、PMの役割の劇的な変化、ソースコード漏洩の余波、そしてオープンソースコミュニティで怒りを巻き起こしたOpenClawブロックの物議を醸す決定について語りました。
主要なポイント#
- ほとんどのPM候補は依然として6〜12ヶ月のロードマップを持つ仕事を探しているが、Anthropicのリズムは毎週、あるいは毎日機能をリリースすることである。
- Claude CodeチームのほぼすべてのPMはエンジニアリングのバックグラウンドを持っているか、直接コードを書いている。デザイナーでさえ元フロントエンドエンジニアだった。
- Anthropicは研究プレビュー（Research Preview）メカニズムを採用し、リリースのコミットメントを低く抑え、エンジニアがアイデアからローンチまでをエンドツーエンドで処理できるようにしている。
- Catは時間の30%を意図的にCoworkの限界を押し広げることに費やし、モデルと対話してなぜ間違いを犯すのかを理解している。
- Claude Codeのソースコード漏洩は2層の人間によるレビューをすり抜けた。Catはこれをプロセスの失敗と表現した。
- OpenClawがサブスクリプション枠を使用するのをブロックする決定について、Catはキャパシティ管理の観点から説明したが、「まず機能をコピーし、その後ブロックする」という論争には触れなかった。
- Anthropicの成功の核となる要因：統一されたミッションにより、チームは自らのKRを犠牲にしてでも会社全体の目標に貢献することを厭わない。
1. Boris Chernyとの協力：80%のマインドメルト、20%の単独行動#
Lennyはまず、CatとBorisがどのように仕事を分担しているかを尋ねた。BorisはClaude Codeの生みの親でありテクニカルリーダーで、ポッドキャスト界ではすでにスターだ。Lennyは彼のエピソードがポッドキャスト史上最も人気があったと述べた。
CatはBorisとの関係を「80%のマインドメルト」と表現した。Borisは方向性に優れており、プロダクトが3ヶ月後や6ヶ月後にどうあるべきか、最もAGIに傾倒したバージョンを思い描くことができる。Catの役割は、そのビジョンを実行可能なパスに変換することだ。つまり、現在からそのビジョンに至るまでのステップは何か？また、Catはクロスファンクショナルな調整により多くの時間を費やし、マーケティング、セールス、ファイナンス、キャパシティなどのチームが連携し、機能の準備が整ったときに障害がないようにしている。
残りの20%は、各人が深く関心を持つ事項をカバーしている。Catは自分がより情熱を注ぐ事項をリードし、Borisも同様だ。この曖昧な分担は外部から見ると異例に映るかもしれないが、Catはまさにこの曖昧さこそが迅速な行動を可能にしていると信じている。
編集者注：Boris ChernyはAnthropicのClaude Codeのテクニカルリーダーであり、O'Reillyの『Programming TypeScript』の著者でもある。2024年9月にAnthropicに参加後、Claude Codeの最初のターミナルプロトタイプを構築した。「AGIに傾倒した（AGI pilled）」は、インターネットスラング「レッドピル（red pilled）」（映画『マトリックス』由来）に由来し、AGIの差し迫った到来に対する極度に楽観的、あるいは狂信的な信念を指す。AI業界では、この用語は肯定的な意味合い（より強力なモデル向けに製品を設計する勇気）と警告（現在のモデル能力からの乖離の可能性）の両方を持つ。
2. 数百人のPMを面接した結果：ほとんどが依然として旧世界に生きている#
Lennyは興味深い現象を指摘した。AnthropicでPMになりたい人が非常に多く、彼は実質的に「紹介料」として300億ドルのARRを受け取っているようなものだという。Catは数百人を面接してきたが、ほとんどの人がAI PMの役割を誤解していると感じている。
問題は何か？Catは、AI以前はテクノロジーの変化が遅く、6〜12ヶ月の計画が可能だったと考える。コードを書くのはコストがかかったため、PMの核となる仕事はチーム間でロードマップを調整し、機能が互いにロックを解除できるようにすることだった。このアプローチは旧世界では正しかった。
しかし今、モデルの能力は急速に向上し、AIはエンジニアリングの効率を劇的に加速させ、多くのプロダクト機能の提供時間は6ヶ月から1ヶ月、時には1週間、あるいは1日にまで短縮されている。このペースでは、PMは複数四半期にわたるチーム間のロードマップ調整に注力すべきではない。代わりに、次のように考えるべきだ：どうすれば何かを出荷する最速の方法を見つけられるか？どうすればエンジニアがアイデアを持ち、週末までにユーザーの手に届くようにできるか？
最高のAIプロダクトPMは、「このアイデアを持った」瞬間から「プロダクトがユーザーに届く」までの時間を短縮でき、プロダクトがすぐに取り組むべきタスクを定義できる。 （"The PMs who do the best on AI native products are the ones who can figure out: How can I shorten the time from having this idea to actually getting the product in the hands of users."）
3. 1日に1つの機能をリリースする方法#
Lennyは、どのようにしてそのスピードを達成しているのか具体的に尋ねた。Catは3つのことを挙げた。
第一に、明確な目標を設定すること。大規模言語モデルは非常に多用途であるため、すべてが曖昧だ。ユーザーは誰か、どの問題を解決するか、核となるシナリオは何か。優れたPMはこれらを確定させる。つまり、核となるユーザーは企業のプロフェッショナル開発者であり、この機能は権限プロンプトが多すぎることによる疲労に対処するものであり、目標はエンタープライズ開発者が安全に権限プロンプトをゼロにできるようにすることだ。この目標が明確になれば、無関係な解決策の膨大な数が排除される。
第二に、研究プレビューメカニズム。Claude Codeのほぼすべての機能は、最初に研究プレビューとしてリリースされる。彼らはユーザーに明確に伝える：これは初期のプロダクトであり、単なるアイデアであり、フィードバックを収集しており、この機能が永久にサポートされるとは限らない。これによりリリースのハードルが下がり、1〜2週間で何かを出荷できるようになる。
第三に、クロスファンクショナルな迅速対応パイプラインを構築すること。Catのチームには「エバーグリーン・ローンチルーム」と呼ばれるメカニズムがある。エンジニアが機能の準備が整い、社内でテストされたと感じたら、このチャンネルに投稿する。ドキュメント担当のSarah、プロダクトマーケティング担当のAlex、デベロッパーリレーションズの同僚が参加し、外部へのプロモーションは翌日には完了できる。このパイプラインがスムーズに機能すれば、どのエンジニアでも摩擦なく機能を出荷できる。
Catは明確に述べた：このリリースパイプラインを構築することが、まさにPMのすべき仕事である。
編集者注：Anthropicのリリースペースはどれほど速いのか？誰かがカレンダーを作成し、2026年の最初の数ヶ月間、Anthropicはほぼ毎日主要な機能やプロダクトをローンチしていたことを示している。
4. PRDは死んでいない、しかし今は違う形で存在している#
Lennyは、彼らがまだPRDを書いているのか尋ねた。Catは、それを2つのものに置き換えたと答えた。
1つ目は、毎週の厳格なメトリクス読み合わせで、チーム全体が一緒にデータをレビューし、ビジネスのあらゆる側面、主要な目標、トレンド、推進要因を全員が深く理解することを確実にするもの。
2つ目は、チームの原則を維持することであり、それにはコアユーザーが誰か、なぜそのユーザーなのか、そしてどのようなトレードオフを進んで行うかが含まれる。これらの原則の目的は、チームの全員がPMや他のステークホルダーの承認を待たずに、独立して意思決定できるようにすることである。
PRDは完全に消えたわけではない。特に曖昧な機能については、Catは依然として目標、理想的なシナリオ、現在の障害モードをリストアップした1ページのドキュメントを書いている。大規模なインフラ投資を必要とする長期的なプロジェクトには、依然としてPRDが存在する。しかし、ほとんどの機能にはそれらは必要ない。
5. 彼らを高速にしたのはMythosではない#
Lennyは、Anthropicのまだ正式リリースされていないMythosモデルが外部の注目を集めていることに言及し、開発を加速するために社内でそれを使用しているかどうかを尋ねた。
Catの答えは直接的だった。彼らはすでに数四半期にわたって高速であり、Mythosがその核となる理由ではない。Mythosは強力であり、彼らは社内でモデルを使用しており、開発がある程度加速されるが、それがスピード向上の主な要因ではない。より大きな理由はプロセスとチームの期待である。つまり、誰もがアイデアを1週間以内に現実のものにする権利と責任を持っていると感じていることだ。
編集者注：Mythos（内部コードネームCapybara）はAnthropicの最新フロンティアモデルであり、2026年4月7日に主にProject Glasswingサイバーセキュリティイニシアチブ向けの研究プレビューとして限定リリースされた。当初は3月26日にCMSの設定ミスにより早期に露出した。Fortuneなどのメディアが入手した草稿では、Opusよりも大きく、より強力なモデルと説明されていた。Anthropicは、このモデルがコード、推論、サイバーセキュリティにおいて過去のすべてのモデルを大幅に上回り、すでに数千のゼロデイ脆弱性を発見したと主張している。
6. ソースコード漏洩：プロセスの失敗と位置づけ#
2026年3月末、Claude Codeの完全なソースコードがnpmパッケージを介して漏洩した。LennyはCatに何が起こったのか尋ねた。
Catはすぐに調査したと述べた。原因は人為的ミスだった。誰かがClaudeを使用して、パッケージ公開プロセスの更新に関するPRを書いていた。そのPRは2層の人間によるレビューを経たが、それでもすり抜けてしまった。彼らはその後、再発を防ぐためにプロセスを強化した。
Lennyは鋭いフォローアップの質問をした。その人物はまだAnthropicに在籍しているのか？ Catの答えは簡潔だった。はい。これはプロセスの失敗であり、最も重要なことは教訓を学び、防御を強化することである。
編集者注：根本原因は、Claude CodeがBunランタイムを使用して構築されており、デフォルトでソースマップファイルを生成することだった。.npmignoreファイルに*.mapエントリが欠落していたため、59.8 MBのソースマップファイルが公開npmレジストリに公開され、約2,000ファイル、512,000行のTypeScriptソースコード、44の未リリース機能フラグ、およびKAIROSという自律型バックグラウンドエージェント（漏洩コードで発見された未リリース機能で、ユーザーがアイドル状態のときでもClaudeがバックグラウンドで継続的に実行され、「メモリ統合」を行うことを可能にする）が露出した。これは13ヶ月で2度目のコード漏洩であり、CMS設定ミスによるMythosモデル情報漏洩のわずか5日後に発生した。「安全性第一」を掲げる企業にとって、1週間で2度の漏洩は、その運用セキュリティに対する外部からの疑問を引き起こした。
7. OpenClawのブロック：キャパシティ管理かエコシステムの壁か？#
Lennyは別の論争の的となっているトピック、すなわちAnthropicがサブスクリプションユーザーがサードパーティツール（具体的にはOpenClaw）を介してClaudeを使用することを禁止したことに触れた。オープンソースコミュニティは強く反応した。
Catの説明：Claudeの需要は非常に高く、彼らはインフラの拡張に努めると同時に、ハーネスのトークン効率を最適化してきた。サブスクリプションプランは、システムに不均衡な負荷をかけるサードパーティ製品の使用パターン向けに設計されたものではなかった。彼らは最もスムーズな移行方法について多くの時間をかけて検討し、最終的に各ユーザーにサブスクリプションに紐づいたいくつかの割り当てを与えることにした。しかし、核となる決定は、自社製品とAPIを優先することだった。
We did have to make the hard decision that we needed to prioritize our first-party products and our API. （「私たちは、自社のファーストパーティ製品とAPIを優先する必要があるという難しい決断を下さなければなりませんでした。」）
編集者注：Catの回答は、この論争の片側だけをカバーしている。完全なタイムラインは以下の通り：OpenClaw（元々はClawdbotという名前で、2026年1月にAnthropicの商標混同懸念により改名）は、オーストリアの開発者Peter Steinbergerによって作成されたオープンソースのAIエージェントフレームワークである。2026年初頭に急速に人気を博し、GitHubで247,000スターを獲得し、オープンソース史上最も急速に成長したプロジェクトの1つとなった。2月14日、SteinbergerはOpenAIに参加することを発表し、OpenClawはオープンソース財団に移管された。2月20日、Anthropicは利用規約を更新し、サブスクリプションのOAuthトークンをサードパーティツールに使用することを明示的に禁止した。3月末までに、Anthropic自身のCoworkがClaude Dispatchなどの機能をローンチし、これらはOpenClawの最も人気のある機能と大きく重複していた。正式なブロックは4月4日に発効し、ユーザーへの通知は24時間未満だった。Steinbergerは、Anthropicが「人気機能を自社のクローズドハーネスにコピーし、その後オープンソースを締め出した」と批判した。Boris ChernyはXで、チームは「オープンソースの大ファン」であり、彼自身がOpenClawにプロンプトキャッシュ効率を改善するPRを提出したと述べた。これらの行動と実際のポリシーの間の温度差はユーザーに感じられた。月額200ドルを支払っているMaxサブスクリプションユーザーがOpenClawを通じて終日自律エージェントを実行すると、APIコストに換算して1,000〜5,000ドル相当を消費する可能性がある。経済的観点からは、Anthropicの決定には合理性がある。しかし、この決定のタイミングがCoworkの機能拡大と一致していることが、コミュニティの論争の核心であり続けている。
8. PMチームの全体像#
Catは、Anthropicには複数のチームに分散して約30〜40人のPMがいると述べた。
- リサーチPMチーム：モデルに関する顧客フィードバックを収集し、モデルリリースを推進する責任を負う。
- Claudeデベロッパープラットフォームチーム：APIやManaged Agentsなどのサービスを維持する。
- Claude Codeチーム：コア製品を構築する。
- エンタープライズチーム：セキュリティコントロール、コスト管理、RBAC（ロールベースのアクセス制御）、および大企業が製品を快適に使用できるようにするその他の機能を担当する。
- グロースチーム：製品スイート全体の成長を担当する。
9. 役割の曖昧化：エンジニア、PM、デザイナーの境界線が消えつつある#
Lennyが、すべてのPMが不安に思っている質問を投げかけました。将来、PMという役割はまだ必要なのでしょうか？
Catの見解では、すべての役割が曖昧になっています。PMはコードを書き、エンジニアはプロダクトの意思決定を行い、デザイナーはPMの仕事をしつつコードを提出しています。彼女は、2つの道があると言います。プロダクトセンスを持つエンジニアを大量に雇うか、同じ数のエンジニアを維持し、彼らを導くためにより多くのPMを雇うかです。Anthropicは前者を選択しました。つまり、プロダクトセンスを持つ多くのエンジニアを雇っているのです。
彼女は、チーム内の多くのエンジニアが、「Twitterでユーザーフィードバックを見る」ことから「週末に機能をリリースする」までのプロセス全体を、PMの関与をほぼ必要とせずに独立して処理できると指摘しました。これが最も効率的なモデルです。
コードを書くコストがはるかに安くなるにつれて、より価値が高まるのは「何を書くか」を決めることです。 ("As code becomes much cheaper to write, the thing that becomes more valuable is deciding what to write.")
Cat自身はエンジニアリングのバックグラウンドを持っています。彼女は以前、Scale AIでプロダクトエンジニア、Dagster Labsでエンジニアリングマネージャーを務め、その後Index Venturesでベンチャーキャピタルに携わりました。チーム内のPMのほぼ全員が、元エンジニアであるか、Claude Codeで直接コードを書いています。デザイナーも以前はフロントエンドエンジニアでした。
では、なぜ今エンジニアリングのバックグラウンドが特に役立つのでしょうか？ Catは、エンジニアリングのバックグラウンドがあれば、ある作業の難易度を判断できるからだと説明しました。簡単なことであれば、議論をやめて1時間で実行に移す。難しいことであれば、事前にコストがわかり、より正確に優先順位を付けられます。
しかし、彼女はそれでも、バックグラウンドに関わらず、最も核となるスキルはプロダクトセンスだと考えています。
プロダクトセンスは依然として非常に稀なスキルであり、私たちはそれを強く示していると感じる人なら、ほぼ誰でも雇うでしょう。 ("Product taste is still a very rare skill to have, and we'll pretty much hire anyone who we feel has demonstrated this strongly.")
10. 「適切な程度のAGI信奉」#
PMに必要な新しいスキルについて議論する中で、Catはエピソード全体を通して最も洞察に富んだ答えを返しました。
最も難しいスキルは、1ヶ月後のプロダクトのあるべき姿を定義することです。そこには計り知れない曖昧さがあります。その期間内にモデルの能力はどうなるのか？ ユーザーの行動はどう変化するのか？
適切な程度のAGI信奉を保つことは非常に難しい。 ("It is very hard to be the right amount of AGI pilled.")
Catは、誰もが究極の未来を見ることができると言います。モデルは信じられないほど賢く、何でもでき、あなたは入力ボックスでやりたいことを伝えるだけで、モデルはあらゆるツールに接続してタスクを完了してくれる。 それがAGIのプロダクト形態です。
しかし問題は、その究極のバージョンに向けてプロダクトを設計するのはあまりにも簡単だということです。難しいのは、現在のモデルの能力の限界を見極め、その限界の中で最大の価値を引き出す方法を考えることです。AGIに傾倒しすぎると、現在のユーザーのペインポイントを無視することになります。保守的すぎると、次のモデルアップグレードに備えられなくなります。
最高のPMは、ユーザーが既存のプロダクトの限界をどのように押し広げているかというシグナルを見ることができます。彼らはこれらのシグナルを利用して方向性を決定し、着実に前進し、モデルの能力が期待を上回ったり下回ったりした場合に柔軟にロードマップを調整します。
Cat自身のアプローチは、時間の30%を意図的にCoworkの限界に挑戦することに費やし、モデルと対話して特定のタスクでなぜ失敗するのかを理解することです。
11. モデルがまだ理解できないこと#
Lennyが質問しました。モデルが超賢くなる前に、人間の脳はまだどこで役立つのでしょうか？
Catの答えは、常識と感情的知性を指摘しました。すべてのプロダクトローンチには、無数の細かいディテールが伴います。モデルは、主要なステークホルダーは誰か、彼らの関係性、好み、彼らの関心を維持するためにどのようなコミュニケーションコンテキストを使うべきかを、まだ正確に判断できません。この暗黙の対人判断は、依然として人間の領域です。彼女は、モデルは時間の経過とともにこれらが改善されると信じていますが、ギャップはまだ存在します。
12. P0からP0000へ：混乱の中で平静を保つ#
Lennyは、このペースの中でどのようにして平静を保っているのか尋ねました。Catは笑いながら、彼らのチームは混乱の中でこそ力を発揮する人々で溢れていると言いました。彼らはどんな課題にも笑顔で立ち向かいます。なぜなら、何かに過度にストレスを感じると、燃え尽きてしまうからです。
彼女は生き生きと説明しました。日曜の夜にP0（最優先インシデント）が発生し、月曜日に別のP0、そして月曜の午後にはP0000が発生する。「あなたは思うでしょう、『ああ、日曜のP0を心配していたなんて』と。」
彼女の対処法は非常に実用的です。自分のキャパシティは限られていると認識し、翌日良い決断ができるよう十分な睡眠を取り、 ruthlessly に優先順位を付け、プロダクトが不完全であることを許容する。一部のリリースは確かに洗練されていませんが、コアとなるシナリオに影響がなければ、それを受け入れ、フィードバックを待ち、次のバージョンで修正します。
13. スピードの代償：機能の重複、ユーザーの混乱#
Lennyは、スピードと引き換えに何を犠牲にしたのか尋ねました。Catは、最大の代償はプロダクトの一貫性だったと言います。
従来のアプローチは、スイート内の各プロダクト間の関係、各プロダクトのユースケース、そしてそれらがどのように統合されるかを注意深く計画することです。現在、Anthropicは、社内に2つの優れたアプローチがあり、どちらが優れているかを外部ユーザーに判断してもらいたいため、重複する機能を同時にリリースすることがあります。
その代償として、新規ユーザーはタスクを達成するための最適なパスを知らない可能性があります。彼女は、ユーザーがコア機能とベストプラクティスを理解できるよう、より多くの教育活動を行う必要があると認めました。
14. Anthropicが勝つ理由：ミッションと集中#
Catは2つの要因を挙げました。
第一に、統一されたミッションです。Anthropicは、「安全なAGIを全人類にもたらす」ことを最も重視する人材を採用しており、このミッションはプロダクトの意思決定において頻繁に参照されます。ミッションが単一のプロダクトラインを超越しているため、組織横断的な意思決定は非常に迅速に行われ、実行は高度に統一されます。
Catは特に、ミッションの具体的な意味を強調しました。それは、チームが自身の目標や主要業績評価指標（KR）を犠牲にしてでも、Anthropic全体の目標やKRに貢献する意思決定を喜んで行うことを意味します。
ミッションとは、チームが自身の目標やKRを犠牲にしてでも、Anthropicの目標やKRに貢献することを喜んで行うことを意味します。
15. Claude Code、Desktop、Cowork：それぞれをいつ使うべきか#
このセクションで、Catは明確な分類を示しました。
- CLI（コマンドラインインターフェース）： 最も強力で、通常はここで最初に機能がリリースされます。最新かつ最高の機能が必要な場合、コーディングタスクを迅速に開始するのに最適です。
- Desktopアプリ： フロントエンド開発に最適です。Catはよくプレビューペインを開き、Claudeとチャットしながら、自分が構築しているWebアプリをリアルタイムで確認します。
- Webとモバイル： コンピューターから離れている場合に最適です。散歩中にアイデアが浮かんだら、電話を取り出してタスクを開始できます。
- Cowork： コード以外のアウトプットを処理します。Slackメッセージへの返信、クライアントミーティング用のスライドデッキ作成、機能目標ドキュメントの作成などです。
Catは、Coworkを最大限に活用するための最初のステップは、関連するすべてのデータソース（Googleカレンダー、Slack、Gmail、Googleドライブ）を接続することだと特に述べました。Coworkが十分なコンテキストにアクセスできて初めて、高品質なアウトプットを生成できます。
16. カスタムアプリケーション：誰もが持つパーソナルSaaS#
キャットが例を挙げた。Claude Codeの営業チームの誰かが、同じタイプのプレゼンテーションを繰り返し作成していることに気づいた。彼らはClaude Codeを使って、効果的なデッキテンプレートを内蔵し、SalesforceやGongから顧客データを取得して、特定のクライアント向けにカスタマイズされたデッキを自動生成するWebアプリケーションを構築した。例えば、クライアントがBedrockを使用しているか、Claude Code for Enterpriseを使用しているかに応じて、対応する機能セットを自動的に反映する。
17. トークンコストは上昇中だが、依然として給与を下回る#
レニーがホットな話題を持ち出した。トークンコストが従業員の給与を超えるというものだ。キャットはこの傾向を認めたが、具体的な数字は示さなかった。彼女は、モデルのアップグレードや主要な製品改善のたびに、人々がより多くのタスクをAIに委任し、Claude CodeやCoworkで過ごす時間が増え、エンジニアやナレッジワーカー一人当たりのトークンコストは確かに増加していると述べた。しかし、それでもエンジニアの給与をはるかに下回っており、その割合は着実に増加している。
18. Claudeのパーソナリティは堀（モート）#
キャットは、Claudeの核となる差別化要因の一つはそのパーソナリティだと述べた。ユーザーはよく、Claudeは「リラックスしていて楽しいが、信じられないほど有能」だと感じると言及する。
彼女は特に2つの性格特性を強調した。
- 低いエゴ： Claudeに間違いを指摘すると、「おっと、教えてくれてありがとう、修正します」と言い、言い訳をしない。
- 前向きな姿勢： 一見不可能に思えるタスクに直面したとき、Claudeは「問題ありません。まずはこんな風に始められると思います。私が始めましょうか？」と言う。
キャットはこれを同僚関係に例えた。一緒に働いたことのある人を思い浮かべてほしい。いつも、そのエネルギーに本当に感謝する人がいるものだ。Claudeの目標は、そんな同僚になることだ。
19. プロダクトビジョン：単一タスクからエージェントマトリックスへ#
キャットは「ビルディングブロック」を使って長期的なロードマップを説明した。核となるビルディングブロックは、単一タスクの成功率である。明確なプロンプトが与えられたとき、一貫して許容可能な出力を生成できるかどうか。
モデルが強力になるにつれて、単一タスクの成功率は向上し、ユーザーは自然と複数のタスクを並行して実行するようになる。2025年末までに、マルチコーディングが主要なトレンドとなり、現在ではさらに一般的になっている。
キャットの推測はこうだ。1つのタスクが成功し、次に6つのタスクが同時に実行される。その後、おそらく50のClaudeが同時に実行され、あるいは数百になる。この道筋は、単一のオペレーターからエージェントマトリックスへと続く。
20. ライトニングラウンド：ロッククライミング、Waymo、そして一万の岩の隠遁#
キャットは2冊の本を推薦した。
- 『How Asia Works』： どのような政策と政府が持続的に成功する経済を生み出すかについて。
- 『The Technology Trap』： 過去の技術革命（産業革命、コンピュータ革命）が労働者に与えた影響について。
どちらも、彼女が経験しているAI変革に直接関連している。
彼女のお気に入りの製品はWaymoで、毎日の通勤に2回利用している。お気に入りのメディアは、F1ドキュメンタリー『Drive to Survive』とロッククライミングのドキュメンタリー『Free Solo』だ。キャットは、純粋なエンジニアリング目標に集中している人々を見るのが好きだと言い、それがおそらく彼女がAnthropicにいる理由を説明している。
働かなくてもよければ？ 彼女は、フランスのフォンテーヌブローに移住するかもしれないと言う。そこには一万の岩があり、毎日クライミングができる。また、現在週0.5冊の読書量を、週1〜2冊に増やしたいとも語った。
Q&Aハイライト#
- AnthropicのPMチームの規模は？ 約30〜40人で、5つのチーム（リサーチ、デベロッパープラットフォーム、Claude Code、エンタープライズ、グロース）に分かれている。
- PMはまだPRDを書いているか？ ほとんどの機能については書いていない。週次のメトリクス読み合わせとチームの原則が、通常のPRDに取って代わっている。特に曖昧なプロジェクトや、大規模なインフラ投資を必要とするプロジェクトについては、依然として1ページのPRDが作成される。
- Anthropicは社内開発を加速するためにMythosモデルを使用したか？ 役立ったが、それが核となる理由ではなかった。スピードは、プロセスとチーム文化から生まれている。
- Claude Codeのソースコード漏洩の責任者は解雇されたか？ いいえ。キャットはこれをプロセスの失敗と特徴づけ、保護策を強化したと述べた。
- Claude CodeとCoworkはいつ使い分けるべきか？ コード出力にはClaude Codeを、コード以外の出力（ドキュメント、デッキ、メール処理）にはCoworkを使用する。
編集者注：注目すべき3つの矛盾#
このインタビューは全体的にかなり友好的な会話だった。レニーはセンシティブな話題にあまり踏み込まず、キャットもうまく対応した。しかし、いくつかの興味深い矛盾が注目に値する。
1つ目は、スピード文化と安全性への約束のギャップだ。 キャットは、「1日1機能のリリース」「リリース基準の緩和」「エンジニアによる自律的なリリース」といったスピード文化について多くの時間を費やして語った。しかし、Anthropicは「安全性」を名刺に掲げるAIラボでもある。1週間に2度の情報漏洩（Mythos CMSの設定ミス + Claude Codeのソースマップ）があったが、キャットは両方について「人為的ミス、保護策を追加した」と説明した。これら2つのインシデントの性質は、単一のPRの範囲を超えている。彼女は、スピード文化自体がこの種のリスクを悪化させた可能性について、何の反省も示さなかった。
2つ目は、オープンエコシステムと囲い込みのトレードオフだ。 OpenClawに関するキャットの説明は経済的に理にかなっている。月額200ドルのサブスクライバーがエージェントフレームワークを使用すれば、数千ドル相当の計算リソースを消費する可能性がある。しかし、タイミングの偶然は無視できない。Anthropicは、自社のCowork製品で同様の機能をローンチした後で、サードパーティツールのサブスクリプションチャネルをブロックしたのだ。OpenClawの創設者ピーター・スタインバーガーの批判——「人気機能をクローズドなハーネスにコピーし、その後オープンソースを締め出す」——は、キャットによってインタビューで直接的に扱われることはなかった。ボリス・チャーニーが「私たちはオープンソースの大ファンです」と言いながらOpenClawのパフォーマンス向上のためのPRを提出していることと、実際のポリシーとの温度差は、おそらくポリシー自体よりも多くのことを物語っている。
3つ目の矛盾は、PMの役割に関するキャットの議論に隠れている。 彼女はPMの未来を「役割の融合」と表現するが、彼女が説明する最も効率的なモデルは、エンジニアがユーザーフィードバックからローンチまでの全プロセスを処理し、「ほとんどPMを必要としない」というものだ。これが真実なら、PMの価値はどこにあるのか？ キャットの答えは「プロダクトのセンス」だが、この概念は会話全体を通して抽象的なままで、運用可能な定義や評価基準は示されなかった。スクリーニング基準が明確に説明できない場合、それは容易に反証不可能なゲートになり得る。そして、「AGIに取り憑かれた」という彼女の議論は、より深いパラドックスを示唆している。モデルが十分に強力であれば、単一のテキストボックスだけで十分であり、彼女のプロダクト業務は本質的に過渡的なものになる。プロダクトリーダーが自身の仕事に有効期限があることを認めるのは珍しい。
次に注目すべきシグナル： Anthropicが約束した安全対策が実際に効果を発揮するかどうか、OpenClawブロック後のデベロッパーエコシステムの方向性、そしてこの「恒久的ベータ」研究プレビューモデルがいつまで持続できるか——ユーザーの忍耐に上限があるかどうか。