Claude Code 流プロダクトマネジメント — Cat Wu が語る AI ネイティブ開発の6原則

Anthropic で Claude Code と Cowork のプロダクト責任者を務める Cat Wu が 2026 年春に立て続けに公開した発言から、AI 時代のプロダクトマネジメント＝Claude Code 流の開発スタイルがはっきり見えてくる。一次ソースから 6 つの原則を整理した。

1. ドキュメントよりプロトタイプ — 仕様書を Claude Code に渡す

Peter Yang のインタビューで Cat Wu はチームの実態をこう語っている。

We don't use Google Docs much on our team. The source of truth is the code base. （社内ではほとんど Google Docs を使わない。真実の源はコードベースだ）

そして Anthropic 公式ブログでは PM 向けにこう書いている。

After you write a spec, send it to Claude Code and see if it can build it. （仕様書を書いたら、Claude Code に渡してビルドできるか試せ）

仕様書 → レビュー → 合意 → 実装、という従来の流れは、Claude Code がプロトタイプを午後に 1 つ吐き出せる時代には重すぎる。仕様の妥当性を議論で詰めるのではなく、動くプロトタイプで検証する。これが PM の働き方を根本から変える。

ただし、誤読してはいけない。「仕様書ゼロでよい」のではなく、「Claude Code が読める仕様」を書く力——構造化された制約、API 設計、ユースケース列挙——が新しい PM スキルとして立ち上がっている、というのが現場感に近い解釈だ。

公式ブログによると、Anthropic で生まれた人気機能の多くは正式なプランの外側から来ている。エンジニアが個人的な実験として作った "Side Quest"（寄り道クエスト）が、後から正規機能に昇格していくモデルだ。

具体例として挙げられているのは：

四半期計画でガチガチに固めた組織からは、こうした機能は出てこない。ロードマップは薄く、Side Quest 用の余白は厚く——これが Anthropic の組織設計上の答えだと読める。

Peter Yang の記事から、もうひとつ重要な発言。

Many of our best features came from an engineer prototyping an idea and shipping it. （ベスト機能の多くは、エンジニアがアイデアをプロトタイプして出荷したところから生まれた）

そして、よりラディカルな部分として、デザイナーや PM が直接プロダクションコードをコミットする運用が紹介されている。ハンドオフではなく、自分で実装まで持っていく。これは Claude Code がコード書きの参入障壁を下げているからこそ成立する。

職能ごとの分業を前提とした旧来の PM 役割は、AI ネイティブな組織では再定義を迫られる。

公式ブログから、おそらく最も実装に効く一行。

Use more tokens than you think you need. You can always bring costs down later. （必要だと思うより多くのトークンを使え。コストは後でいつでも下げられる）

ケイパビリティが先、コスト最適化は後。AI プロダクト設計の決定的な順序判断だ。プロトタイプ段階でトークンを節約しはじめると、何が本当に価値ある体験なのかが見えなくなる。価値を確認してから、最適化のサイクルに入る——順序を逆にしてはいけない。

新しいモデルが出るたびに、「今まではうまくいかなかったこと」を片っ端から試す。これは Cat Wu が毎回のリリースで実行しているルーティンだという。Claude Code の Chrome 連携は、まさにこの手順で発見された機能だ。

続きを読むには

CCHub は Claude Code 開発者のための日本語コミュニティです。