Cat Wu氏が数百人のPM候補者を面接したところ、ほぼ誰も正解しなかった問いとは「AIプロダクトマネージャーの役割とは何か？」

Cat WuはAnthropicのClaude CodeおよびCoworkのプロダクトリードであり、Boris Chernyとパートナーを組んでチームを率い、プロダクト機能の納期を半年から1日へと圧縮した。Lenny's Podcastの最新回で、CatはAnthropic内部のスピード文化、PM（Product Manager）役割の劇的な変化、ソースコード漏洩への対応、そしてオープンソースコミュニティを沸かせたOpenClawのブロック決定について語った。

image**

オリジナル動画：https://www.youtube.com/watch?v=PplmzlgE0kg

ポイントまとめ

• 多くのPM候補者は依然として6〜12ヶ月のロードマップ思考で求人を探しているが、Anthropicのリズムは機能リリースを週単位、あるいは1日単位で行うこと
• Claude Codeチームのほぼ全PMがエンジニアリング背景を持つか直接コードを書く経験があり、デザイナーも元々はフロントエンドエンジニアだった
• Anthropicはresearch preview（Research Preview）メカニズムを用いてリリースのコミットメントを軽減し、エンジニアがアイデアからリリースまでエンドツーエンドで完結できるようにしている
• CatはCoworkを意図的に限界まで押し上げるのに30%の時間を費やし、モデルと対話させてエラーの原因を解明している
• Claude Codeのソースコード漏洩は二段階の手動レビューを経ても見逃され、Catはこれをプロセスの失敗と位置づけた
• OpenClawの利用をサブスクリプションクォータでブロックする決定について、Catはキャパシティ管理の観点から説明したが、「まず機能を複製してからブロックする」という論争を回避した
• Anthropicの成功の核心：統一されたミッションにより、チームが自らのKR（Key Results）を犠牲にしてでも会社全体の目標に貢献する意志を持つこと

1. Boris Chernyとのパートナーシップ：80%のシンクロ、20%は各自の担当

Lennyは冒頭で、CatとBorisがどのように分担しているかを尋ねた。BorisはClaude Codeの生みの親であり技術責任者で、ポッドキャスト界ではすでにスター級の人物だ。Lennyは彼の回がポッドキャスト史上最高の人気エピソードだったと語っている。

Catは自分とBorisの関係が「80% mind-meld（マインド meld / 思考の融合）」と表現できると話す。Borisが得意なのは方向性の把握で、3ヶ月後や6ヶ月後にプロダクトがどうなっているべきか、最もAGI pilled（AGI Pilled）バージョンは何かを語る。Catの役割はこのビジョンを実行パスに翻訳すること**だ：現在からそのビジョンに至るまで、一歩ずつどう進むか？同時に彼女はクロスファンクショナルな調整に多くの時間を費やし、マーケティング、セールス、財務、キャパシティなどのチームが計画に同意し、機能準備完了後に障害が発覚しないようにしている。

残りの20%は、各自が特に重視する事項だ。Catは自分がより関心のあることを主導し、Borisも同様で、より関心の高い方が推進する。この曖昧な分担は外見上あまり正統派ではないが、Catにとってはこの曖昧さこそがスピードを生むのだという。

**

編集者注：** Boris ChernyはAnthropicのClaude Code技術責任者であり、O'Reillyより刊行された『Programming TypeScript』の著者でもある。2024年9月にAnthropicに入社後、Claude Codeの最初のターミナルプロトタイプを構築した。AGI pilledはインターネットスラングのred pilled（映画『マトリックス』由来）に由来し、AGIの到来に対して極めて楽観的かつ熱狂的な態度を指す。AI業界内部では、この言葉には前向きな意味（より強力なモデル向けにプロダクトを設計する勇気）と警告の意味（現在のモデルの実力から乖離している可能性）の両方が含まれる。

2. 数百人のPM面接後の発見：大半は旧世界に生きている

Lennyは興味深い現象に言及した。AnthropicのPMになりたい人が多すぎて、もうすぐ30億ドルのARR（Annual Recurring Revenue）相当の「紹介料」をもらってしまうほどだ。Catは数百人を面接したが、大半がAI PMの役割に対する理解の方向性が間違っていると感じている。

どこに問題があるのか？Catは、AI登場以前は技術変化が遅く、6〜12ヶ月の計画を立てることができたと考えている。コードを書くコストが高いため、PMの中核業務は各チームのロードマップを調整し、機能がお互いにロック解除されることを確保することだった。この戦術は旧世界では正解だった。

しかし現在、モデルの能力が急速に向上し、AIはエンジニアリング効率を大幅に加速させている。多くのプロダクト機能の納期が6ヶ月から1ヶ月、場合によっては1週間、あるいは1日へと短縮された。このリズムにおいて、PMは複数の四半期にわたるロードマップのクロスチーム調整に精力を費やすべきではなく、どうやってものを出すか最速の方法を見つけるかを考えるべきだ。エンジニアがアイデアを持ち、週末までにユーザーの手に届くようにするにはどうすればよいか？

**

最高のAIプロダクトPMは、「このアイデア」から「実際にユーザーの手に届く」までの時間を短縮する方法を解き明かし、プロダクトがどのタスクでout-of-the-box（Out-of-the-box）状態であるべきかを定義できる人だ。

（“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つのことを語った。

1つ目は明確な目標の設定だ。**大语言模型（Large Language Model）の能力があまりにも汎用的であるため、ユーザーは誰か、解決する問題は何か、コアシナリオは何かがすべて曖昧になる。優れたPMはこれらを明確に定めることができる：私たちのコアユーザーは企業内のプロフェッショナルな開発者であり、この機能は権限プロンプトが多すぎることに起因する疲労感を解決するものであり、目標は企業開発者が安全にゼロ権限プロンプトを実現できるようにすることだ。この目標が明確になれば、関連性の低い方案の大部分が排除される。

第二に「research preview（研究プレビュー）」の仕組みです。 Claude Code のほぼすべての機能は、まず研究プレビューとして公開されます。ユーザーには明確に伝えます：これは初期版であり、単なるアイデア段階です。フィードバックを収集中であり、この機能は永久にサポートされない可能性があります。これにより公開のハードルが下がり、1〜2週間で製品をリリースできます。

第三に、クロス機能の迅速な対応パイプラインを構築することです。 Cat のチームには「evergreen launch room（エヴァーグリーン・ランチラーム）」という仕組みがあります。エンジニアが機能の準備ができ、社内テストも完了したと判断すると、このチャンネルに投稿します。ドキュメント担当の Sarah、プロダクトマーケティング担当の Alex、デベロッパーリレーションズのスタッフが即座に参画し、翌日には外部向けのプロモーションが完了します。このフローが円滑に回れば、どのエンジニアも機能公開する際に摩擦なく進められます。

Cat は明確にこう述べています：「この公開パイプラインを構築することは、PM がやるべきことです。」

\n編集者注： Anthropic の公開ペースはどれほど速いのでしょうか？ある人物がカレンダーを作成し、Anthropic が 2026 年の最初の数ヶ月ではほぼ毎日、重要な機能や製品の公開を行っていたことを発見しました。

4. PRD (Product Requirements Document) は死んでいないが、生き方が異なる

Lenny は PRD をまだ書くかどうかを尋ねました。Cat によると、彼らはその代わりとして 2 つのことを行っています。

第一に、毎週厳格な「metrics readout（メトリクス・リードアウト）」を実施することです。チーム全員でデータを確認し、誰もがビジネスの各側面、主要な目標、トレンド、そしてそれを駆動する要因を深く理解していることを保証します。

第二に「team principles（チーム原則）」を維持することです。これには、コアユーザーは誰か、なぜ彼らなのか、どのようなトレードオフを受け入れるかが含まれます。この原則の目的は、チームの誰もが PM やその他のステークホルダーに判断を仰がずとも、自ら意思決定できるようにすることです。

PRD が完全に消えたわけではありません。特に曖昧な機能については、Cat 还是一頁のドキュメントを作成し、目標、理想シナリオ、現在の失敗パターンを列挙します。インフラへの多大な投資が必要な長期プロジェクトにも PRD は残っています。ただし、大部分の機能には必要ありません。

5. Mythos が彼らを速くしたわけではない

Lenny は、Anthropic がまだ正式公開していない Mythos モデルが外部から注目を集めていることに注目し、社内でこのモデルを使用して開発を加速させているかどうかを尋ねました。

Cat の回答は非常に直接的でした。「彼らはすでに数四半期にわたって高速化しており、Mythos が核心的な原因ではありません。」 Mythos は強力であり、確かに社内ではモデルを使用しており、それが開発をある程度上積かせたのは事実ですが、速度向上の主要部分を説明するには不十分です。より大きな要因はプロセスとチームの期待値の設定です：誰もが、アイデアを1週間以内に現実に変える権限と責任を持っていると感じています。

\n編集者注： 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 の回答は明確でした。「在籍しています。これはプロセスの失敗であり、最も重要なのは教訓を学び、防護を強化することです。」

\n編集者注： 漏洩の根本原因は、Claude Code が Bun runtime を使用してビルドされていたことにあります。Bun はデフォルトで source map ファイルを生成しますが、.npmignore に *.map のエントリが不足していたため、59.8 MB の source map ファイルが公開の npm レジストリに公開され、約 2,000 のファイル、512,000 行の TypeScript ソースコード、44 の非公開機能フラグ、そして KAIROS という名前の自律型バックグラウンドエージェント（漏洩したコードから発見された未公開機能で、ユーザーがアイドル状態のときでも「メモリ整理」を行うため、Claude をバックグラウンドで継続実行可能にするもの）が暴露されました。これは 13 か月間での 2 回目のコード漏洩であり、Mythos モデルの情報が CMS の設定ミスにより漏洩してからわずか 5 日後のことでした。「セキュリティファースト」をブランドポジショニングとする企業にとって、1 週間のうちに 2 回の漏洩が発生したことは、外部から運用セキュリティへの疑問を投げかけました。

7. OpenClaw のブロック：キャパシティ管理か、エコシステムの壁か？

Lenny はもう一つの論争的な話題に言及しました。Anthropic がサブスクリプションユーザーによるサードパーティ製ツール（特に OpenClaw）を通じた Claude の使用を禁止していることです。オープンソースコミュニティからの反応は非常に大きかったです。

Cat の説明は以下の通りです。Claude への需要が非常に大きいため、インフラの拡張に努めると同時に、harness のトークン効率を最適化しています。サブスクリプションプランはサードパーティ製ツールの使用パターンを想定して設計されたものではありません、こうした製品がシステムに不均衡な負荷をかけています。彼らは最も円滑な移行策を模索するために多くの時間を費やし、最終的に各ユーザーにサブスクリプションに付随する一定のクレジットを付与することを選びましたが、中核的な判断は自社製品と API の優先確保にあります。

**\n私たちは確かに困難な決断を下す必要があり、自社製品と API を優先確保する必要がありました。\n

（“We did have to make the hard decision that we needed to prioritize our first-party products and our API.”）**

編集者注：** Cat の回答はこの論争の一面しかカバーしていません。完全なタイムラインは以下の通りです：OpenClaw（旧名 Clawdbot、2026 年 1 月に Anthropic が商標の混同を懸念して改名）は、オーストリアの開発者 Peter Steinberger によって作成されたオープンソースの AI Agent（エージェント）フレームワークで、2026 年初頭に急激に人気を集め、GitHub でのスター数は累計 24.7 万を数え、オープンソース史上最も成長が速いプロジェクトの一つです。2 月 14 日、Steinberger は OpenAI への加入を発表し、OpenClaw はオープンソース財団に移管されました。2 月 20 日、Anthropic は利用規約を更新し、サードパーティ製ツールへの OAuth token（アクセストークン）の使用を明確に禁止しました。3 月末、Anthropic 自身の Cowork が Claude Dispatch（Claude ディスパッチ）などの機能をリリースし、OpenClaw で最も人気のある機能と大きく重複しました。4 月 4 日に正式なブロックが適用され、ユーザーへの通知はわずか 24 時間未満でした。Steinberger は Anthropic を「人気機能を自社のクローズドな harness（ハルネス）に先に取り込み、その後オープンソースを締め出す」と批判しました。Boris Cherny は X 上でチームが「オープンソースの大きなファンである」と表明し、本人も OpenClaw にプロンプトキャッシュ効率を改善する PR（プルリクエスト）を提出したことがあります。これらの行動と実際のポリシーの間の温度差は、ユーザーに感じ取られています。月額 $200 の Max サブスクリプションユーザーが OpenClaw を通じて終日自律型 Agent（エージェント）を稼働させると、$1,000〜$5,000 に相当する API コストを消費する可能性があり、経済的な観点から 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 の業務をこなすだけでなくコードも提出しています。彼女は二つの道があると言います：一つは製品センス（プロダクトテイスト）のあるエンジニアを大量に採用すること、もう一つはエンジニアの数を維持したまま 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（プロダクトテイスト／製品センス）**であると依然として考えています。

**

Product taste（プロダクトテイスト）は依然として非常に希少なスキルであり、この能力を強力に証明できる人物であれば、私たちはほぼ全員を採用します。

（“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 pilled（AGI 信仰）が強すぎると目の前のユーザーのペインポイントを見失い、保守的すぎると次のモデルアップグレード時に手違いを起こします。

最高の PM は一つのシグナルを見抜きます：ユーザーが既存製品の限界をどのように突破するか。彼らはこれらのシグナルから方向性を判断し着実に進めつつ、モデルの能力が予想を上回ったり下回ったりした場合でも柔軟にルートを変更します。

Cat 自身のアプローチは、時間の 30％を故意に Cowork を限界まで押しやることに費やし、モデルと対話して、なぜ特定のタスクでエラーが発生するのかを解明することに充てています。

11. モデルがまだ理解していないこと

Lenny は質問します：「モデルが超賢くなる前に、人間の脳はどの領域でまだ有用なのか？」

Cat 的回答指向常識とEQ。任何一次产品发布都有一千个细碎环节，模型还不能很好地判断谁是关键的利益相关方、他们之间的关系、他们的偏好、应该用什么沟通场合让他们保持在状态里。这种隐性的人际判断仍然是人的领地。她相信模型会越来越擅长这些，但目前缺口还在。

12. P0（最高優先度事故）到 P0000：混乱中怎么保持理智

Lenny 问如何在这种节奏下保持理智。Cat 笑着说他们的团队都是享受混乱的人。面对每一个挑战都带着笑容，因为如果你对任何事情太紧张，就会燃尽。

她给了一个很有画面感的描述：周日晚上出了一个 P0（最高優先度事故），周一又来一个 P0，周一下午来了个 P0000，“你会想，天啊，我居然还为周日那个 P0 担心过。”

她的应对方式很实际：承认你能做的事有限，睡好觉才能第二天做好决策，暴力排优先级，允许产品不够完美。有些发布确实不够打磨，但只要不影响核心场景，就接受它，等反馈，下个版本修。

13. 速度的代价：功能重叠，用户困惑

Lenny 问为了速度牺牲了什么。Cat 说最大的代价是产品一致性。

传统做法是仔细规划产品套件里每个产品的关系、每个产品的场景、它们怎么整合。现在 Anthropic 有时候会同时推出功能重叠的东西，因为内部有两种方案都不错，他们想让外部用户来告诉他们哪个更好。

代价是新用户可能不知道完成某件事的最佳路径是什么。她承认需要做更多教育工作来帮用户理解核心功能和最佳实践。

14. Anthropic 为什么能赢：使命和聚焦

Cat 说了两个因素。

第一是统一使命。 Anthropic 招的是最在意“把安全 AGI（人工知能の一般化）带给全人类”的人，这个使命在产品决策中被频繁引用。因为使命高于任何单个产品线，跨组织决策可以非常快，执行可以高度统一。

Cat 特别强调了使命的具体含义：它意味着团队愿意做出牺牲自身目标和 KR（成果指標）的决策，来服务 Anthropic 整体的目标和 KR，而且人们很乐意做这种取舍。

**

使命意味着团队愿意做出伤害自己目标和 KR 的牺牲，来服务 Anthropic 的整体目标和 KR。

（“Mission means that teams are willing to make sacrifices that hurt their own goals and their own KRs in service of Anthropic's goals and Anthropic's KRs.”）

15. Claude Code、Desktop、Cowork：什么时候用哪个

这部分 Cat 给了一个清晰的分类。

• CLI（コマンドラインインターフェース）：最强大的，功能通常最先在这里上线。适合随手启动一个编程任务，需要最新最全功能的时候用。

• Desktop 版：适合做前端开发。Cat 经常打开预览窗格，一边和 Claude 聊天一边实时看自己在构建的 Web 应用。

• Web 和移动端：适合不在电脑前的时候。走在路上有个想法，掏出手机就能启动任务。

• Cowork：处理非代码输出——回完 Slack 消息、做一个客户会议的 slide deck、写一份功能目标文档。

Cat 特别提到，要让 Cowork 发挥最大作用，第一步是连接所有相关数据源**：Google Calendar、Slack、Gmail、Google Drive。只有 Cowork 能访问到足够的上下文，它才能给出高质量的输出。

16. 自定义应用：每个人的个人 SaaS（Software as a Service）

Cat 讲了一个例子。Claude Code 销售团队里有个人，发现自己反复做同样类型的演示文稿。他用 Claude Code 做了一个 web 应用，内置了效果好的 deck 模板，可以从 Salesforce 和 Gong 拉取客户数据，自动生成针对特定客户的定制 deck，比如会标注这个客户是用 Bedrock 还是 Claude Code for Enterprise，对应不同的功能集。

17. Token（トークン）花费在涨，但仍低于薪资

Lenny 提到一个热门话题：token 花费超过员工薪资。Cat 确认了趋势但没给具体数字。她说每次模型升级或产品大幅改进后，人们会把更多任务交给 AI，花更多时间在 Claude Code 和 Cowork 里，单个工程师或知识工作者的 token 成本确实在增长。但目前仍然远低于工程师薪资，只是占比在持续上升。

18. Claude 的性格是护城河

CatはClaudeの核心的な差別化要因の一つが性格（personality）であると語った。ユーザーからは「リラックスして楽しく、かつ非常に有能に感じられる」という意見が頻繁に寄せられている。

特に彼女は以下の2つの性格的特徴を挙げた。

• 低エゴ（Low ego）：Claudeが間違っていると指摘すると、「ああ、教えてくれてありがとう、直してみるね」と言い訳せずに修正する。

• 前向きでポジティブ：手がかりのないように見えるタスクに直面した際、Claudeは「大丈夫です。こんな感じで始められると思いますよ。まずは私が手を動かしましょうか？」と声をかける。

Catはこれを同僚との関係に例えている。これまで一緒に仕事をした人々を振り返れば、必ず「この人のエネルギーは素晴らしい」と感じる人がいるはずだ。Claudeが目指すのは、まさにそのような同僚である。

19. 製品ビジョン：単一タスクからエージェント・マトリックスへ

Catは長期ロードマップを「ビルディングブロック（building blocks）」で説明している。中核となる構成要素は単一タスクの成功率だ。明確なプロンプト（prompt）を与えたとき、それが常に許容範囲内の出力を生成できるかどうか。

モデルが強化されるにつれて単一タスクの成功率が上昇し、ユーザーは自然とマルチタスク並列処理を始めるようになる。2025年末にはマルチコーディング（multi-coding）が大きなトレンドとなり、現在ではさらに一般的になっている。

Catの推論はこうだ。1つのタスクが成功すれば、次は6つのタスクを同時に実行する。さらに先では、おそらく50のClaude、あるいは100以上のClaudeを同時に稼働させることになる。このロードマップは単独運用からエージェント・マトリックス（Agent matrix）へと移行していく。

20. スピードループ：クライミング、Waymo、そして一万の巨石がある引退後の生活

Catは以下の2冊の本を推薦している。

• 『How Asia Works』：持続可能な成功を収める経済体を生み出すための政策と政府の在り方について論じている。

• 『The Technology Trap』：過去の技術革命（産業革命、コンピュータ革命）が労働者に与えた影響について述べている。

両書とも、彼女が現在経験しているAI変革と直接的に関連している。

最も好きなプロダクトはWaymoで、毎日通勤で2回利用している。お気に入りの映画・ドキュメンタリーはF1ドキュメンタリー『Drive to Survive』とクライミングドキュメンタリー『Free Solo』だ。Catは、人が純粋なエンジニアリングの目標に極限まで集中している様子を見るのが好きだと語っており、この嗜好がAnthropicで働いている理由の一端を説明している。

もし将来仕事をしなくても？と問われると、フランスのフォンテーヌブローに引っ越すかもしれないと答えた。そこには一万もの巨石があり、毎日クライミングを楽しめるという。また、現在の週0.5冊から1〜2冊へ読書量を増やしたいとも語った。

Q&A サマリー

• AnthropicのPM（Product Manager）チームはどのくらい規模が大きいか？ 約30〜40人で、リサーチ（research）、デベロッパープラットフォーム（developer platform）、Claude Code、エンタープライズ（enterprise）、グロース（growth）の5つのチームに分かれている。

• PMは依然としてPRD（Product Requirements Document）を書く必要があるか？ ほとんどの機能では不要だ。毎週のメトリクス・リードアウト（metrics readout）とチームの原則が通常のPRDに代わっている。特に曖昧な場合や大規模なインフラ投資が必要なプロジェクトには、依然として1ページ分のPRDが残っている。

• AnthropicはMythosモデルを使って内部開発を加速させたか？ 役には立っているが、中核的な理由ではない。速度は主にプロセスとチーム文化から生まれている。

• Claude Codeのソースコード漏洩事件後、関係者は解雇されたか？ いいえ。Catはこれを「プロセスの失敗」と位置づけ、防護策を強化済みだと説明した。

• Claude CodeとCoworkの使い分けは？ コード出力が必要な場合はClaude Codeを、ドキュメントやプレゼン資料（deck）、メール処理などの非コード出力が必要な場合はCoworkを使う。

エディターズノート：注目すべき3つの矛盾

今回のインタビューは全体的に非常に友好的な対話であり、Lennyは敏感な話題を深く追及せず、Catも対応を適切にコントロールしていた。しかし、いくつかの興味深い矛盾が注目される。

第一に、スピード文化と安全へのコミットメントの間のギャップである。 Catは「1日に1つの機能をリリースする」「リリースのコミットメントを減らす」「エンジニアに自主的なリリースを任せる」といったスピード文化について多くの篇幅を割いているが、Anthropicは同時に「安全」を社名のように掲げるAIラボでもある。1週間の間に2回の情報漏洩（Mythos CMSの誤設定とClaude Codeのソースコードsource map）が発生したが、Catの説明はどちらも「人的ミスであり、防護策を強化した」というものだった。この2つの失敗の性質は単一のPR（Pull Request）の範囲をすでに超えている。スピード文化自体がこうしたリスクを悪化させていないかについて、彼女は全く反省を示していない。

第二に、オープンエコシステムとウォールドガーデン（围墙花园）の間の取舍である。 CatのOpenClawに関する説明は経済的な論理において妥当だ。月額200ドルのサブスクリプションユーザーがエージェント・フレームワーク（Agent framework）を通じて数千ドル相当の計算リソースを消費する可能性があるためである。しかし、タイムライン上の偶然は無視しにくい。Anthropicは自社製品Coworkに類似機能をリリースした後、初めてサードパーティ製ツールのサブスクリプションチャネルを封じた。OpenClaw創設者Peter Steinbergerの「まず人気機能をクローズドなharness（枠組み）にコピーし、その後オープンソースを締め出す」という批判に対し、Catはインタビューで正面から応答しなかった。Boris Chernyが「私たちはオープンソースの大きなファンだ」と言いながらOpenClawのパフォーマンス改善PRを提出したという行動と、実際のポリシーとの温度差は、おそらくポリシー自体よりも考察に値するだろう。

第三の矛盾は、CatによるPM（Product Manager）の役割に関する記述の中に潜んでいる。 彼女は「役割の融合」でPMの未来を説明しているが、自身が提示する最も効率的な模式は、エンジニアがユーザーフィードバックからリリースまでの全プロセスをエンドツーエンドで完了し、「PMの関与はほぼ不要」とするものだ。これが本当なら、PMの価値とは一体どこにあるのか？Catの答えはproduct taste（プロダクトテイスト）だが、この概念は会話全体を通じて抽象的なレベルに留まり、具体的な定義や評価基準は一切提示されていない。一つの選別基準が明確に記述できない場合、それは検証不可能なハードルになりやすい。さらに、彼女によるAGI pilled（AGI志向の/AGIに特化した）に関する記述には、より深いパラドックスが内包されている。もしモデルが十分に強力であればテキストボックス1つで十分なら、彼女が行っているプロダクト作業は本質的に過渡的なものとなる。自分の仕事に賞味期限があることを認めるプロダクト責任者の、この率直さは稀である。

次に注目すべき信号は、Anthropicが約束した安全防護策が実際に機能するかどうか、OpenClaw封鎖後のデベロッパーエコシステムの動向、そしてこの「永久beta」のresearch preview（研究プレビュー）モードがどれほど持続可能か、そしてユーザーの忍耐限度に上限があるかどうかである。

原始動画：https://www.youtube.com/watch?v=PplmzlgE0kg