AI の指数関数的進化におけるプロダクトマネジメント
2024 年 10 月の Claude Sonnet 3.5 (new) 以来、私は新しいモデルが出るたびに Claude Code（当時は社内ツール）に Excalidraw にテーブルツールを追加するよう頼んでテストする習慣をつけていました。新しいモデルが出るたびに Claude は少しずつ先に進みましたが、それでもまだ失敗していました。
そして 2025 年 6 月の Opus 4 のリリースで、Claude は時々成功するようになりました。十分な頻度で成功するようになったため、私たちはこの演習を Claude 4 モデルローンチの事前収録デモに仕立て、最新モデルで何が可能になったかを示しました。
それから 1 年も経たないうちに、Opus 4.6 は Excalidraw の機能リクエストをワンショットで十分に信頼性高くこなせるようになり、数千人のプロフェッショナル開発者の前でライブデモを行えるほどになりました。
モデルの進歩のスピードは、可能性の範囲を拡大し続けています。従来のプロダクトマネジメントのプレイブックは、プロジェクト開始時に技術的に可能なことは終了時にもおおむね同じであるという前提に基づいて構築されています。PM は将来について確信を持った賭けをするのに十分な情報を事前に集め、数か月かけて計画に沿って実行していました。
指数関数的に改善するモデルは、その前提を壊します。設計時に考慮した制約が、プロジェクトの途中で消えてしまうかもしれません。足元の地面がせり上がっているようなもので、チームはその現実に合わせて再編成する必要があります。新しいプロダクトマネジメントのリズムは、素早い実験、一貫したリリース、そしてうまくいくものへの倍賭けです。
当然のことながら、Anthropic のプロダクトマネージャーとして私が最もよく受ける質問の一つは、私たちの役割がどう変わっているかということです。ここでは私が学んだことを共有します。
Claude Code を使ったプロダクトマネジメントへの道のり
私は Scale AI や Dagster といったスタートアップでプロダクトエンジニアとしてキャリアをスタートし、その後ベンチャーキャピタリストになりました。VC の仕事でも、X で新しい会社の発表をスキャンしたり、オープンソースプロジェクトが勢いを増しているのを検出したりと、仕事の退屈な部分を自動化するためにコードを書いていました。
2024 年 8 月に Anthropic に入社し、リサーチチームと実際の顧客との橋渡しをしてより良いモデルを提供する Research PM チームのプロダクトマネージャーになりました。その秋に Claude Code が社内で使えるようになると、大規模なユーザーフィードバックを分析する Streamlit アプリの構築や、信頼できる新しいベンチマークを見つけるための eval の実行など、仕事の手作業の多い部分を加速させるために使いました。構築のハードルが低いということは、RL 環境を作ってトレーニングをより深く理解するなど、通常の役割をはるかに超えた探索もできるということでした。
これらのプロジェクトには Sonnet 3.5 (new) を搭載した Claude Code で何百時間ものプロンプト入力を要しましたが、手で書いたコードは一行もありません。
新しいプロダクトマネジメントワークフローの設計
Claude Code や Cowork のようなツールは、プロダクト開発ライフサイクルにおける各役割の境界を曖昧にしています。
Claude Code だけが私のワークフローを支えているわけではありません。時間をかけて、3 つのプロダクトの間で自然な分業に落ち着きました：チャットコラボレーター（Claude.ai）、エージェント型コーディングツール（Claude Code）、そしてナレッジワークツール（Cowork）です。
Claude.ai は、アクションを取ってもらう必要なく、思考のパートナーとして Claude と話す場所です。戦略ドキュメントのアイデアを壁打ちしたり、難しい状況への対処法を相談したり、素早い回答を得たりします。
Claude Code は、プロトタイプ、eval、スクリプトを作る場所で、多くが Claude API を呼び出します。出力がコードのときにこれを使います。
Cowork は、それ以外のすべてを行う場所です。受信トレイゼロの達成、ToDo リストの追跡と実行、スライドデッキの作成、Slack を検索して意思決定の経緯を理解すること、出張の予約などです。
業界全体のプロダクトマネージャーと話しましたが、それぞれ自分なりのバージョンのワークフローを見つけています：
「Claude は優れたプロダクトチームが構築できるもののの上限を引き上げ、アイデアからプロトタイプまでの距離を劇的に縮めました。以前は顧客の前に具体的なものを出すのに数週間のビルドが必要でした。今では Claude Cowork で Slack やコードベース、ドキュメントからコンテキストを取り込むところから始めて、Claude Code に移り、数時間でデモ可能なものができます。優れたプロダクトチームは常に実際の顧客でアイデアをテストしてきましたし、その本能は変わっていません。変わったのは、実際にそのループに通せる高品質なアイデアの数がはるかに多くなったことです。」 - Bihan Jiang, Director of Product, Decagon
「私にとって、AI ネイティブな世界の PM であることは、クリエイティブであると同時にアカデミックでもあります。新しいモデルのリリースごとに可能なことが変わります。Datadog の Bits AI SRE エージェントを構築する中で、実際のプロダクション障害に対するオフライン評価を通じてモデルの強みと失敗パターンを研究しています。また、エージェントが苦戦する箇所を可視化する UX を改良し、そこから得られたインサイトをプロダクト改善につなげるという、タイトなフィードバックループも設計しています。その意味で、PM の技術は事前に確実性を定義することから、発見を加速することへとシフトしています。」 - Kai Xin Tai, Senior Product Manager, Datadog
今日プロダクトマネージャーであることの最もエキサイティングな点の一つは、これらのワークフローが常に進化し、私たちにより大きなレバレッジを与えてくれていることです。
AI の指数関数的進化に乗る
METR. (2026, March). Task-Completion Time Horizons of Frontier AI Models. https://metr.org/time-horizons/
METR の調査によると、Opus 4.6 は人間がほぼ 12 時間かかるソフトウェアタスクを約半分の確率で完了できます。Claude Code を最初に構築し始めたとき、Sonnet 3.5 (new) がフロンティアモデルで、METR の測定では人間が約 21 分かかるタスクをこなせるレベルでした。これは 16 か月で約 41 倍のジャンプです。
Claude Code チームは、モデルの改善速度に追いつくために進化してきました。役割が融合しつつあります：デザイナーがコードをシップし、エンジニアがプロダクト判断を下し、プロダクトマネージャーがプロトタイプや eval を作ります。これが機能するのは、明確な戦略と目標によって全員が自律的に優先順位をつけられるからです。プロダクトマネージャーの仕事は、急速なモデルの進歩が生み出す曖昧さの中に明確さを作り出し、何が可能かについてチームにもっと大きく考えるよう促し、より速くシップするための道を切り開くことです。
ここでは、私たちが取り入れた 4 つのシフトを紹介します：
短いスプリントで計画する
従来のプロダクトマネージャーの考え方では、探索はロードマップが確定する前に行うものでした。リサーチをして PRD を書き、エンジニアリングチームにビルドを引き渡します。
長期的なロードマップの代わりに、チームの全員（エンジニア、プロダクトマネージャー、デザイナー）にサイドクエストに取り組むことを奨励しています。サイドクエストとは、公式のロードマップの外で行う短い自主的な実験です——午後をかけてアイデアのプロトタイプを作ったり、手が届かないと思っていた機能をテストしたり、モデルを予想以上に強くプッシュしたときに何が起こるかを確かめたりします。
Anthropic の最も人気のある機能のいくつか——Claude Code on Desktop、AskUserQuestion ツール、ToDo リスト——はこのように生まれました。
ドキュメントよりデモと eval を奨励する
私たちのチームは、ドキュメントファーストの考え方をプロトタイプファーストの考え方にほぼ置き換えました。従来のスタンドアップミーティングの代わりに、新しいアイデアのデモを共有します。社内ユーザーがそれを試し、実際にエンゲージメントのあったものが磨かれ、より広く共有されます。午後一つでプロトタイプが作れるため、間違った賭けのコストは低いです。
たとえば、Noah が Claude Code のプラグイン仕様を共有したとき、返ってきたプロトタイプはほぼプロダクション品質でした。そのプロトタイプがチームが最終的にシップしたものの基盤となりました。UX を素早く検証できたからです。
プロのコツ：仕様を書いたら、それを Claude Code に送って構築できるか試してみてください。粗いプロトタイプでも会話の質が変わります。
デモに加えて、eval も抽象的なプロダクトをより具体的にするのに役立ちます。たとえば、ユーザーが複数の Claude Code インスタンスを連携して作業させられる Agent Teams では、Conner が Agent Teams がうまく機能するとき、しないとき、何を修正すべきかを理解するための eval セットを手作りしました。機能が動作しているかを測定することで、改善が容易になります。
新しいモデルで機能を再検討する
今は、機能をシップした後に、より良いモデルが出て機能が劇的に向上する可能性があります。モデルのリリースは毎回、すでに構築したものを見直す暗黙のきっかけです。
こうした瞬間を捉える最良の方法は、デイリーアクティブユーザーであり続け、難しすぎると思うことを意図的に頼んでみることです。時にそれが動作し、それはプロダクトが追いつく必要があるというシグナルです。
Claude Code with Chrome はそうやって生まれました。ユーザーが Claude Code でウェブアプリを構築し、それをテストするために Chrome の Claude に手動で切り替えているのに気づきました。ユーザーは手動でプロンプトを入力し、2 つのツール間で指示をコピー＆ペーストしていました。それが十分にうまく機能していたので、これは組み込み機能にすべきだと気づきました。ユーザーが何かを無理やりつなぎ合わせているなら、それはプロダクトに組み込める足場です。
これらのアイデアをプロトタイピングする際は、常にまず機能性を最優先に最適化してください。必要だと思う以上にトークンを使ってください。トークンコストを早期に削減しすぎて、結果としてはるかに能力の低いものをシップしてしまうのはよくある間違いです。より安価なモデルが追いつけば後からコストは下げられますが、まずその機能が可能かどうかを知る必要があります。
シンプルなことをする
Anthropic では、すべてのチームに共通する指針があります：うまくいくシンプルなことをする。
モデルの制限を巧みに回避するプロダクトを作ると、次のモデルが出たときにその回避策は不要な複雑さになります。だからこそ「シンプルなことをする」が重要なのです——実装がシンプルであるほど、新しい機能が登場したときに入れ替えやすくなります。
Claude Code で ToDo リストを最初にローンチしたとき、モデルはタスクを完了しても確実にチェックを入れてくれませんでした。そこで数メッセージごとにシステムリマインダーを追加して、定期的にエージェントに自分の ToDo リストを更新するよう促しました。動作はしましたが、ハックでした。次のモデルでは、その動作が自然に備わり、リマインダーは完全に削除できました。このパターンは繰り返し見てきました：私たちのシステムプロンプトとツール説明はモデルの制限を補うために入念に作り込まれていましたが、モデルごとにプロンプティングを削減でき、Opus 4.6 では 20% の削減を実現しています。
この先を見据えて
多くのプロダクトマネージャーは、プロダクト体験全体を緻密にコントロールすることに慣れていますが、AI は素早く動くためにコントロールを手放すことを求めます。特に AI プロダクトの構築に関しては、波に乗るサーフィンのようなもので、最も重要なのは波の上にいることです。完璧主義者として、これは私にとって最も慣れるのが難しいシフトでしたが、プロダクトマネージャーの役割は今や、本当に譲れない少数のことを特定し、残りは手放すことです。
これらのシフトの正味の効果として、プロダクトチームは大幅に速く動けるようになります。プロダクトマネージャーがアイデアから動くプロトタイプまで一午後で到達できるとき、「もし試してみたら......」と「はい、これを試してみて」のギャップはほぼ消えます。
Anthropic では、Claude を使ってワークフローを変革しているのはプロダクトマネージャーだけではありません。データサイエンス、ファイナンス、マーケティング、法務、デザインチームがこれらのツールを自発的に取り入れました。組織全体がハンドオフを待つのではなく、同じスピードで動いています。
PM の役割は今、2 つのことを同時に追うことです：AI が働き方をどう変えているか、そして AI がプロダクトで何を可能にしているか。これをうまくやれば、テーブルツールがついに動いたとき驚くことはありません。それが来ることを見抜いていたのはあなた自身です。
Claude Code でより良いプロダクトの構築を始めましょう。
謝辞:この記事は、Anthropic の Claude Code プロダクト責任者である Cat Wu によって執筆されました。X と LinkedIn でフォローできます。この記事への貢献に対し、Bihan Jiang と Kai Xin Tai に感謝します。