Anthropic CPO陣「なぜClaudeはまだPMになれないのか」― プロダクトマネージャーの役割、AI時代にどう変わるか
「1年前、AIによってPM(プロダクトマネージャー)は、不要になると言われていた。今は逆に、誰もがPMになる必要があると言われている」。あるカンファレンスのパネルセッションで、司会者はこう切り出しました。登壇したのは、Anthropicの製品部門を率いる2人の幹部、AmiさんとMikeさんです。本記事は、AI企業の内部から見た「プロダクトマネジメントの変化」について、2人の発言を整理します。
なお、本セッションは、特定のカンファレンスでのパネル討論であり、Anthropicの公式見解というより、登壇した2人個人の経験と考えに基づく発言です。
1. PMの役割は消えるのか、変わるのか
1-1. 「人間の問題」は変わらない、変わるのは技術
Amyさんは、プロダクトの仕事を「人々が抱える現実の問題と、それを解決できる技術との橋渡し」だと定義しました。その上で、技術が、かつては5〜10年周期で変化していたのに対し、今は「2か月ごとに変わる」ように感じると指摘します。人間として、この変化のスピードに対応するのは非常に難しいものの、「人間側の問題」自体はそれほど速く変わらないとし、「人間の問題を解決することに執着しながら、技術については常にまっさらな目で見続ける」ことが重要だと述べました。
同氏は、この状況を「プロダクトマネジメント黎明期への巻き戻し」だと表現します。まだ職務の定義すらなかった時代のように、役割の境界が曖昧になり、汎用的な問題解決者として動き、壁にぶつかったら人に聞いたり自分で調べたりする、という働き方に戻りつつあるという見立てです。
1-2. 「Claudeがいるから、PMは不要では」と思った瞬間
Mikeさんは、今年初めに個人貢献者(IC)としての役割にシフトし、主に開発業務を担うようになったと明かしました。あるプロジェクトの出荷が近づいた際、PMリードの一人から「このプロジェクトには、APM(アソシエイトPM)が必要だ」と言われたといいます。Mikeさんは、当初、「Claudeがいるし、必要だろうか」と思ったものの、実際にPMが加わったことで、それまで見過ごされていた「接着剤」のような役割、つまり、案件同士をつなぐ連携作業の重要性に気づかされたと振り返りました。1週間後、Mikeさんはそのリードに「あなたが100%正しかった」と伝えたそうです。
2. AIワークフローにおける人間の判断
2-1. 「まとめ役」としての人間
Mikeさんは、Anthropicが、幅広い顧客層(プロシューマーから大企業まで)にサービスを提供する中で、変更内容をカスタマーサクセスチームがリアルタイムで説明できる体制を整えているか、安全対策の担当者が関与しているか、といった「誰も無限のキャパシティを持たない」領域を、誰かが担う必要があると説明しました。開発に没頭できる人がその作業から離れずに済むよう、これらを調整する役割は「本質的に不可欠だ」と述べています。
司会者が、「なぜClaude(Fableの上位版など将来のモデル)にやらせないのか」と尋ねると、Mikeさんは、Anthropic社内では、Claude Tagやコネクティビティ機能が組織内の関連情報を検知してくれる場面もあるとしつつ、「Claudeは、まだ『まとめ役(convener)』にはなれていない」と述べました。同氏は、最近、「超高性能AI時代における人間の役割」について講演した際に考えたアーキタイプの一つとして、「人とAIを引き合わせて仕事を進める、まとめ役」を挙げたといいます。「Claudeが、私の代わりに、あるいは私のために会議を設定して、『あの二人は話すべきだと思ったから』と言ってくる瞬間は、まだ来ていない」と冗談交じりに語りました。
2-2. 曖昧さの中での「執念」と判断力
Amyさんは、ツールが非常に優れ、速く多くのものを作れるようになったことで、構築可能な範囲は広がった一方、限られた情報の中で「何を作るべきか」を判断する優れた判断力は、これまで以上に重要になったと述べました。分岐点が無数にある中で、「これが必要だと思う、使う人へのフィードバックループもある、人間の問題も分かっている、だからやる」という執念と、曖昧さの中での判断力が極めて重要だと強調しています。
3. 変化の激しい時代に不要になったスキル、必要になったスキル
3-1. 「ボタンをどこに置くか」を議論した時代の終わり
Amyさんは、長年のプロダクトマネジメントのキャリアを振り返り、かつては、「ユーザーの心情に自分を置き換え、何かが彼らの生活にどう組み込まれるか」を理解する能力に多くの時間を費やしたと述べました。開発と出荷のコストが非常に高かったため、レビューでは、「このボタンをどこに置くべきか」「ユーザーが電話をポケットから取り出す瞬間、指はどこに動くか」といった議論を重ねていたといいます。
しかし、今は、3つのバージョンを実際に作って試し、どれが機能するか確かめる方が速くなりました。「自分が誇りに思っていたスキルが、もうそれほど役に立たない」とAmyさんは述べ、これはアイデンティティの観点で非常に難しいことだと認めます。企業が得意な一つのことに固執し続ける「イノベーターのジレンマ」は、個人レベルでも起こりうるとし、「自分の得意分野に固執し続けるのではなく、より重要かもしれない別のやり方を試す」ことの必要性を訴えました。
3-2. 必要とされる特性:「変化への耐性」「判断力」「執念」
司会者が、「うまく適応できる人の特徴は何か」と尋ねると、Amyさんは、「変化への耐性の上限を上げ、変化を積極的に受け入れる意志」、すなわち、適応力を挙げました。あわせて、前述の判断力と執念も繰り返し重要だとしています。
同氏は、チームに対し、これらを言葉にして共有することを大切にしていると述べました。「常に適応し続けなければならないのは自分だけだ」と感じると孤独になりがちですが、実際には全員が同じ状況にあると伝えることで、負担感を和らげられるといいます。また、不確実な時期には「これから起きることを正確に描き出そう」としがちですが、それは一種のコントロール欲求であり、新しいことに挑戦する妨げになるとし、「混沌に安全に関われるような枠組みを与える」ことの重要性を語りました。
4. 組織運営:「混沌の中の明確なリーダーシップ」
Mikeさんは、Amyさんの組織運営について、「混沌を許容しつつ、特定の領域には明確なリーダーシップと責任者(DRI)を置く」やり方を評価しました。Anthropic社内では、先端的な取り組みを「ベット(bets)」と呼び、それぞれに「ベットリード」を置いているといいます。このリードは、「この取り組みに賭けるべきか、縮小すべきか」「このチームには人を増やすべきか、減らすべきか」を最終的に判断する責任者であり、変化が速い今こそ、この役割の重要性が増していると述べました。
5. 「エージェントネイティブ」なソフトウェアをどう作るか
5-1. 「人間ができることは、エージェントもできるべき」
話題は、開発するプロダクトそのものの変化に移りました。Mikeさんは、AI機能の統合には段階があったと振り返ります。当初はサイドバーの小さなウィンドウに切り離された形で存在し、次第に機能全体がAI搭載になり、そして「エージェントネイティブ」な方向へと進化してきたという整理です。
同氏は、この1年間、エージェントネイティブなアーキテクチャについて考え続けてきたとし、その核心を「人間ができることは、エージェントもできるべきだ」という原則で表現しました。この原則を守れている製品はまだ少ないものの、実現すると、これまで組み合わされていなかった要素をエージェントが自律的に組み合わせたり、新しいやり方を能動的に提案したりする、創発的な挙動が生まれるといいます。
5-2. 社内事例:Claudeが自らUIを作る
Mikeさんは、現在進行中の複雑なプロジェクト(少なくとも4つの独立した作業ストリームを持つ)の運用例を紹介しました。Claudeに進捗の監視を任せるだけでなく、TPM(テクニカルPM)、さらにはチーム全体がプロジェクトの状況を理解するためのUIそのものをClaudeに作らせているといいます。この表示が気に入らなければ、社内の加速化チームやサードパーティが決めた仕様に縛られることなく、Claudeとともに自由に変更できる点が、この1年でAnthropicの働き方における大きな変化の一つだと評価しました。
同氏は、こうした状況が「誰がデータを更新できるのか」「バックグラウンドで動くClaudeも更新するのか」「データの出所(プロヴェナンス)をどう管理するか」といった新しい問いを生んでいるとも述べています。
5-3. 外部企業へのアドバイス:「共有される配管」を作る
司会者が「Anthropicの外にいて、既存のSaaSアプリにエージェントを組み込むかどうかを考える企業は、何を基準に判断すべきか」と尋ねると、Mikeさんは、プロダクトに適切な「プリミティブ」をインフラ層として組み込むことが重要だと答えました。新しい製品を試す際、人間にはできるがエージェントには思考や設計が必要な操作を頼んでみて、それがエージェントとREST APIの両方が通る「共有された配管」を通じて設計されているかどうかを確認するといいます。20年間開発してきたアプリケーションに後付けするのは難しいと理解を示しつつ、一度正しく設計できれば、サイドペインから始めて徐々に発展させるなど、段階的に進化させられると説明しました。
6. Anthropicが直面する「フロンティアと一貫性」のジレンマ
6-1. 「今は全員で一緒に探求している段階」
Amyさんは、Anthropicが最先端を追求する一方で、単にClaudeとチャットしたいだけのユーザーや、インターフェースを一夜にして変えられない大企業向け契約も抱えるという課題について、「非常に難しい問題」だと認めました。同氏のアプローチは「今いる場所でユーザーに寄り添う」ことであり、何が機能するかについてまだ理解が浅いため、正解をいきなり作るのではなく「全員で一緒に探求している」段階だと述べています。
かつてのキャリアでは、シンプルさ・信頼性・完全な予測可能性を重視していたと振り返りつつ、「多くのことについて、まだ正解の形が分かっていないのが現実だ」とし、チームには「とにかく多くの挑戦をする」ことを推奨していると述べました。重複や類似に見える取り組みがあっても、うまくいったものが見つかった時点で一つにまとめ直せばよいという考えです。過度に制約されたプロダクトを最初から作り、市場に問う機会すら与えないことこそが「失敗状態」だと表現しています。
6-2. 「熱意のないチーム」には任せない
複数の並行実験を進める際の心理的なハードルについて、Amyさんは、あるプロダクトの方向性を巡り、片方に強い確信を持つチームがいて、もう片方には特に誰も熱意を持っていない、という社内での実例を挙げました。「良いと思うから」という理由だけで、誰も望んでいない方向性の探求をチームに割り当てても、うまくいった試しがないと述べ、「B級チーム」的な空気になってしまうと説明しています。複数のチームがそれぞれ熱意を持てる方向性を持っているなら、それぞれに探求させるのがよいという考えです。
6-3. 基盤インフラの統一:メモリー・MCP・ファイル保存の共通化
Amyさんは、過去半年〜3か月ほどで大きく進展した点として、ChatとCoworkが異なるメモリーシステム、異なるMCP、異なるファイル保存方式を持っていた状態を挙げました。この状態では、新しい取り組みを試すたびに、他の機能とメモリーを共有できず、最初から不利な立場に置かれてしまいます。そこで「Foundations(基盤)チーム」が、製品のどこにいてもメモリーにアクセスできる仕組みづくりに取り組んでいるといい、こうした基盤整備を、先端的なプロダクトチームとは別のチームが担うことで、重複する実験同士も「補完的」に感じられるようにしていると説明しました。
同氏はまた、「3つの異なるベットが並行して走っている場合、士気が下がったり、誰かが不利な立場に置かれているように感じたりすることがある。それでいい。それが今の世界だ。私たちは、その旅路に一緒についてきてほしいと頼んでいるだけで、誰も正解を知らない」と、率直に伝えること自体の重要性を語りました。
7. 何をもって「機能し始めた」と判断するか
7-1. 基本は「プロダクトマーケットフィット」
「何かがうまくいき始めたと分かる兆候は何か」という問いに、Amyさんは、人々が使うか、気に入るか、戻ってくるか、話題にするか、価値を得ているか、といった基本に立ち返ると答えました。
7-2. 「早すぎず、遅すぎず」:プロジェクトの「保留」という戦略
一方で、一度うまくいかないと判断したものが、新しいモデルの登場で急に機能し始めることがあり、早く見切りをつけすぎるのも、逆にしがみつきすぎるのも避けたいとAmyさんは述べました。Anthropicの研究ラボチームでは、プロジェクトを完全に廃止せず「保留」し、新しいモデルが出るたびに再挑戦する運用をしているといいます。
同氏は、2024年に社内で最初のコンピューター操作プロダクトを開発した際の例を挙げました。当時のモデルではまだ性能が不十分で、Photoshopでの複雑な操作を試みても、「初期のエージェント的Claude」らしく、20分かけて試行錯誤した末に「できませんでした」と返ってくるような状態だったといいます。それでも評価ハーネス上でプロジェクトを動かし続け、あるモデル(文字起こしでは「37」と表記、Claude 3.7を指すとみられる)で突然、成功率が逆転する瞬間をトランスクリプトで確認し、「これは本物の転換点だ」と気づいたと振り返りました。
同氏は、プロジェクトが「モデルがまだ対応できる段階に達していない」ことを示すだけに終わったとしても、それを評価指標(eval)として外部化したり、研究チームとの接続点を作れたりすれば、それは「勝利」だとみなしていると述べています。Mikeさんも、一度試して評価指標を作らないままにしておくと、モデルの進化を見逃す「能力の見えなさ(capability blindness)」に陥ると同意しました。
7-3. 「最新モデルを使っているか」で会場アンケート
Mikeさんは会場に「Fable(モデル名)を使ったことがある人は?」と挙手を求め、多くの手が挙がったのに対し、「Astra(モデル名)は?」という質問には挙手が減った様子に触れ、「これは非常に参考になる。よく、『これはできない』と言われて、『最新モデルを使いましたか』と聞くと、『いや、Sonnet 4.5か何か使った』と返ってくることがある。それだけで話が大きく変わる」と述べました。
8. 並行実験を一貫したプロダクトへ統合する難しさ
司会者は、複数の並行実験の一つがうまくいき始めた際に、それを実際のプロダクトへ統合する方法について、業界共通の課題として問いかけました。タブを増やす、別アプリとして分離したまま統合しない、といった選択肢はいずれも「あまり美しくない」とし、「誰もこれが正解だと確立できていない」と指摘しています。
Amyさんは、「完全に解決できているとは思わない」と率直に認めつつ、Mikeさんが述べたプリミティブの整備が鍵になるとし、ユーザーが「何も考えずに使える」体験を作ることを目指していると述べました。同氏は、Instagramで見られた「タブ利用の強いべき乗則」(メインフィードが利用の約8割を占め、探索タブを改善しても10%から15%程度にしか伸びない、という経験則)に触れ、「メインタブをいかに優れたものにし続けるか」という問いは、今後も続く課題だと述べています。プロダクト開発の半分は、「サイドバーに新しい項目やタブを追加する」ことに「ノー」と言い、検証が済んだものだけを本体に統合しつつ、早すぎる段階で潰さないことの見極めにあるとし、これが変化の速い時代における「プロダクト開発の技術そのもの」だと結びました。
9. 1年後の展望
セッションの最後、司会者が「1年後にこの場に戻ってきたら、何が変わっていると思うか」と尋ねました。
Amyさんは、「人々が、自分が望む方法でもっと多くのことを構築できるようになっていてほしい。いつでも答えを得られ、事業を始められ、少人数チームや個人による事業運営がもっと当たり前になってほしい」と述べ、開発者がツールを直接使わない人々にも恩恵をもたらす「増幅効果」への期待を語りました。
Mikeさんは、「モデルが持つ能力と、多くの人が実際にそれをどう使えているかのギャップ」を縮めることを最大の目標に挙げました。このギャップは利用者の責任ではなく、作り手側が埋めるべきものであり、2024年よりも2025年、そして今の方が難しくなっているとしつつ、「Claude漬けのソフトウェアエンジニアだけでなく、並行して複数の研究をこなす人や、事業を運営しながらこの技術を活用できたと感じる人」にまで、このギャップを縮める民主化効果をもたらせたら、それが成功の証だと締めくくりました。
