【はじめに】なぜこの記事を書いたか
「6ヶ月がかりでロードマップを書き上げたのに、3ヶ月後に Claude 4 がリリースされてすべて無駄になった」――。
Anthropic の Head of Product である Cat Wu のインタビューを読み、日本のPdM（プロダクトマネージャー）のやり方が根本からズレていると確信した。本記事は単なる翻訳ではない。現場の記録と、そこから導き出される「未来のPdMに関する4つの大胆な仮説」である。
Part 1: Anthropic の現場 — Cat Wu が語る高速開発の全貌
1.1 誰がこの話をしているのか
Cat Wu ―― Claude Code Head of Product。以前は Google や Stripe で PM を務め、現在は「業界最速の shipping 文化」を築く現場の中心にいる。彼女が語るのは机上の理論ではない。毎日、実際にプロダクトを届けている最前線の話だ。
1.2 速度の衝撃：6ヶ月 → 1日
従来のソフトウェア開発ライフサイクルは死んだ。計画に6ヶ月、実装に数ヶ月――そんな時代は終わった。Anthropic の shipping サイクルは1週間、短いものでは1日だ。
その秘密は「Research Preview（研究プレビュー）」というブランド戦略にある。機能をあえて「プレビュー」と位置づけることでユーザーの期待値（ハードル）を下げ、長期的なコミットメントを軽くする。これにより、本番環境を実験場として扱えるのだ。即時フィードバックを収集し、リアルタイムでイテレーションできる。失敗が許されない大規模ローンチの重荷を背負う必要はない。
Cat Wu の言葉をそのまま引用しよう：
"We want to remove every single barrier to shipping things. The timelines for a lot of our product features have gone down from 6 months to 1 month and sometimes to even one day."
— Cat Wu, Head of Product for Claude Code at Anthropic
1.3 Roadmap の死亡
従来のプロダクトマネージャーは「調整役」だった。関係チームの足並みを揃え、依存関係を管理し、会議をセッティングする。しかしAIネイティブな世界では、このアプローチは根本的に破綻している。
もしあなたのロードマップが、3ヶ月後に陳腐化するモデルの能力に依存しているなら、その計画はもはや資産ではなく負債だ。
新しいPMのミッションは単純である。「アイデア」と「リリースされた機能」の距離を極限まで縮めること。硬直したロードマップの代わりに、Anthropic が使うのは「Team Principles」と「Metrics Readouts」だ。
Team Principles とは何か：
- 誰のための機能か
- ユーザーはなぜそれを求めるのか
- チームはどのようなトレードオフを受け入れるか
これらがチームの「Golden Path（あるべき道筋）」を定義する。エンジニアはPMの承認を待たずにリリースできる。なぜなら「正しい方向性」がすでに共有されているからだ。
1.4 Product Taste がハードスキルになる
AIがコードを劇的に低コストで生成する時代、ボトルネックは「実行」ではなく「識別力」にシフトした。
Product Taste（プロダクトの目利き力）――これはもはや曖昧なソフトスキルではない。必須のハードスキルだ。非決定論的なモデルの出力を見て、直感的に「これはユーザーの期待を満たしているか」を見極める能力である。
ただし、「味覚」だけでは不十分だ。それを裏付ける新しい形の技術的厳密さ、すなわち「Evals（評価ケース）」が必要になる。
現代のPMにとって最も重要なスキルの一つは、高品質なテストケースで「成功」を定義する能力だ。数百ものテストは不要である。真の価値は、10個の質の高い evals を構築し、進捗を定量化し、モデルがどこで躓いているかを特定することにある。
Cat Wu の言葉：
"As code becomes much cheaper to write, the thing that becomes more valuable is deciding what to write."
— Cat Wu, Head of Product for Claude Code at Anthropic
1.5 モデルが“補助輪”を不要にする
成功したプロダクトは時間とともに単純化する――これは直感に反するが、紛れもない真実だ。
開発者は往々にして「ハーネス（足場）」や「松葉杖」を構築する。モデルを補助するための追加コードやUI要素である。しかしモデルが Opus 4 から Opus 4.5、Sonnet 4.6 へと進化するにつれ、これらの処理をネイティブにこなすようになる。
To-Do List の具体例：
初期の Claude Code では、モデルに複雑なリファクタリングを完了させるために明示的なUIが必要だった。チェックリスト、進捗インジケーター、確認ダイアログなどだ。しかし現在、新しいモデルはこれらのタスクを自然に完遂する。残っているUIは、人間ユーザーの安心感のためだけにある。モデルはもはや補助を必要としていない。
ここから導かれる戦略的含意は「"delete-first" メンタリティ」だ。モデルが賢くなるたびに、システムプロンプトとUIを監査し、不要になった松葉杖を積極的に取り除かなければならない。
1.6 "Just Do Things" の哲学
このペースを維持するには、特定のマインドセットが求められる。Cat Wu はこの文化を「カオスに身を委ねる（leaning into the chaos）」と表現する。周囲で船が解体されていく中でも、冷静に階段を降りていくようなメンタリティ――優先順位の変更に振り回されても消耗しない姿勢である。
Anthropic の運営マントラは "Just Do Things"。極端なまでの主体性（オーナーシップ）文化だ。"Jobs are fake" ――職務定義書に書かれていることだけを待つのではなく、問題を見つけたら解決する。ギャップがあれば、自ら埋める。
これにより、チーム固有の「パーソナライズされた業務ツール」が急増している。例えば、営業チームのメンバーが Claude Code を使ってカスタムWebアプリを構築したケースだ。Salesforce と会議メモから文脈を抽出し、個別最適化された営業資料を自動生成する。30分かかっていた手作業が、数秒の自動化に置き換わった。
Part 2: これから勝つPdM — 4つの大胆な仮説
仮説1: Evals こそが新しい PRD である
従来の流れ： 要件定義書 → 設計 → 実装 → テスト。
未来： Evals（評価設計）がプロダクト要件の核心になる。
なぜか： モデルの出力は非決定論的である。従来の仕様書ではその「質」を捉えきれない。10個の質の高い evals の方が、100ページのPRDよりも正確に「あるべき姿」を定義できる。
実践： どうやって「良い応答」を数値化するか。人間がスコア付けしたデータをもとに、自動評価の基準を構築する。
日本のPdMへの示唆： Excelで仕様書を書く時間を、eval設計に回せ。最初は「1機能 × 10ケース」から始めればいい。
仮説2: PdM はプロンプト設計者になる
コードが安価になった時代、PdMの価値は「何を書くか」の判断にある――Cat Wu もそう指摘する。しかしそれだけでは不十分だ。
新しいPdMの核心能力： モデルに「味（基準）」を教えること。
プロンプト設計は、新しい形のプロダクト設計だ。システムプロンプトの調整が、場合によってはUI設計よりもUXに決定的な影響を与える。モデルに「良い応答とはこういうものだ」と示すことこそが、PdMの仕事になる。
日本企業の適用障壁： 「プロンプト設計はエンジニアの仕事」という線引き。これを越える必要がある。
仮説3: PdM は「削除」のプロになる
Anthropic の "delete-first" メンタリティは、プロダクト戦略だけでなくPdMの自己定義にも適用される。
モデルが賢くなるたびに、人間が用意した「補助」は不要になる。PdMの仕事は機能を追加することではなく、松葉杖を取り除くことだ。
実践：
- UI要素の定期監査――「モデルはもうこれを必要としているか？」
- システムプロンプトの削減――モデルのネイティブな能力に委ねる
- ワークフローの単純化――成功したプロダクトは「薄く」なる
日本のPdMの課題： 「機能追加＝価値創造」という固定観念。AI時代は逆だ。削除こそが価値を生む。
仮説4: Shipping が唯一の真実になる
Research Preview の本質：完璧を待たず、出して学ぶ。
従来： 計画 → 合意形成 → 開発 → レビュー → リリース。
未来： アイデア → プロトタイプ → プレビューリリース → 学習 → 改善。
PdM の KPI はこう変わる：
- ❌ 計画書の完成度
- ❌ 要件定義の網羅性
- ✅ 1週間に何回 shipping したか
- ✅ ユーザーから得た学びの数
日本企業への適用： 「プレビュー」という言葉で期待値をコントロールする戦略だ。PoCとして閉じず、「プレビュー」として世に出す。仮に失敗しても「プレビュー段階だったから」で済む。これがイテレーションの速度を上げる。
【おわりに】100%自動化への道
"Which 'tedious' part of your role are you ready to automate to 100% today to find your extra day of the week?"
— Cat Wu, Head of Product for Claude Code at Anthropic
95%の自動化は、失敗である。100%までやり切って初めて、週に1日の余裕が生まれる。その時間で、本質的なインパクトを生む個人プロジェクト（pet project）に時間を使うのだ。
私が今、100%自動化に挑んでいるもの：
- 会議からの action items 自動抽出
- 週次進捗レポートの自動生成
- ユーザーインタビュー transcript の自動分析
あなたは何を自動化する？
本記事は Anthropic Head of Product Cat Wu のインタビュー内容を元に、筆者の解釈と仮説を加えたものです。