Anthropic製品責任者が語る：6ヶ月から1日へ短縮されたリリースの秘密、「ハーネスはモデルに朝食として食べられる」

Anthropicの製品リリースペースは、他に類を見ないと言っていいでしょう。

カレンダーにAnthropicの最近の製品リリースをプロットしてみると、ほぼ毎日、何かしらの新機能がリリースされていることがわかります。

最近、Lenny Rachitsky氏は、AnthropicでClaude CodeとCoworkのプロダクト責任者を務めるKat Wu氏をポッドキャストに招き、インタビューを行いました。番組の情報密度は非常に高く、プロダクトマネージャーの役割の変化、Anthropicの内部プロセス、ソースコード漏洩事件、OpenClawに関する決定まで、あらゆる話題が取り上げられました。

重要なポイントを以下にまとめました。

彼女は誰か

Kat Wu氏は以前、長年エンジニアとして働き、短期間VCを経験した後、Anthropicに入社し、Claude CodeとCoworkのプロダクト責任者になりました。

彼女はBoris氏（Claude Codeの生みの親であり、技術責任者）とパートナーを組んでいます。

Boris氏は製品ビジョンを担当し、3～6ヶ月後に製品がどうあるべきかを定義します。Kat氏はそのビジョンを実行可能な道筋に落とし込み、マーケティング、セールス、ファイナンスなど、各チームとの連携を図る役割を担っています。

「私たちのアイデアは、おそらく80%が一致しています。残りの20%は、より強く望む方が推し進めます。」

彼女たちのチームには一つの特徴があります。ほぼ全てのPMがエンジニアリングのバックグラウンドを持ち、デザイナーも元フロントエンドエンジニアです。

これは意図的にそうしたわけではありません。Kat氏の説明によると、エンジニアリングのバックグラウンドがあれば、何かを作るのが実際どれほど難しいかをより早く判断でき、現在の開発ペースでは、この判断が極めて重要だからです。

どれほど速いのか

Anthropicの製品イテレーションサイクルは、6ヶ月から1ヶ月へと短縮され、機能によっては、わずか1日でリリースされるものもあります。

その背景にある秘訣は、複雑な方法論ではありません。

Kat氏は3つのことを挙げました。

明確な目標を設定すること。

LLMは非常に汎用性が高いため、ユーザーとシナリオを絞り込まなければ、チームは簡単に方向性を見失ってしまいます。例えば、Claude Codeのターゲットユーザーはプロの開発者であり、ある機能が解決しようとしている問題は「権限ポップアップが多すぎて疲労する」ことで、その目標は、企業の開発者が安全にゼロ権限プロンプトを実現できるようにすることです。

この条件だけで、無関係な多数の案が排除されます。

リサーチプレビュー（Research Preview）の仕組み。

ほぼ全ての機能が、まずリサーチプレビューとしてリリースされます。ユーザーはこれが初期バージョンであり、恒久的に提供されるとは限らないことを認識しています。この方法の利点は、完璧を目指さずともリリースでき、1～2週間で機能を世に送り出せることです。

ローンチルーム（Launch Room）のプロセス。

エンジニアが機能の準備が整ったと判断すると、「エバーグリーンローンチルーム」と呼ばれるチャンネルにそれを放り込みます。ドキュメント責任者のSarah氏、PMM責任者のAlex氏、DevRelチームのTarek氏とLydia氏が迅速にフォローし、翌日にはリリースされます。

「私たちはリリースを妨げるあらゆる障壁を取り除きたいと考えています。チームの誰もが、自分のアイデアを1週間以内、あるいは1日以内に製品にできるべきです。」

Lenny氏は思わず追问しました。社内でMythosモデルを使っていますよね……それが理由で速いのでは？

Kat氏の答えはこうでした。

「社内でこれらのモデルを確かに使用しており、それによって速度が少し向上したのは事実です。しかし、加速の大部分は、プロセスとチーム文化によるものです。」

モデルがあなたの製品を食い尽くす

Kat氏が注目すべき現象について語りました。新しいモデルが登場するたびに、彼女たちが最初に行うのは機能の削除だということです。

Claude Codeには当初、ToDoリスト機能がありました。当時のモデルは大規模なコードリファクタリングを行う際、20箇所ある修正箇所のうち、必ず5箇所を修正したところで停止していました。チームはある方法を考え出しました。モデルにまずリストを作成させ、それを一つずつ完了させるのです。

結果的に、この方法は非常に効果的でした。

しかし、Opus 4以降では、モデル自体が自発的にリストを作成し、一つずつ完了させるようになりました。ToDoリストは「必要な松葉杖」から、「あってもなくても良い補助的なインターフェース」へと変わったのです。

「新しいモデルをリリースするたびに、私たちはシステムプロンプト全体を読み返し、一文一文を振り返ります。モデルにはまだこの注意喚起が必要だろうか？もし不要なら、削除します。」

Lenny氏は一例を挙げました。「モデルは君のハーネスを朝食として食べてしまうだろうね。」

Kat氏はそれに同意しました。

しかし、彼女がより興奮したのは、新しいモデルが切り開く全く新しい能力でした。例えばコードレビューです。彼女たちはいくつかのバージョンを試しましたが、精度が十分ではありませんでした。Opus 4.5と4.6が登場して初めて、エンジニアリングチームが本当に依存できる水準に達し、現在ではAnthropic社内でPRをマージする前に、Claudeのコードレビューを通過することが必須となっています。

「まだ完全には使えない製品プロトタイプを事前に作っておくことが重要です。そうすれば、新しいモデルが出たときに、それを直接載せ替えて、ギャップが埋まったかどうかを確認するだけで済みます。」

これは、以前Mike Krieger氏がポッドキャストで語ったのと同じ考え方です。未来のモデルのために製品を作る、ということです。

ソースコード漏洩

先月のClaude Codeのソースコード漏洩についても、Kat氏は回答しました。

「我々は直ちに調査を行いました。これは人為的ミスの結果であり、誰かがClaudeを使ってPRを作成し、パッケージ公開フローを更新する際に誤りが生じました。二重の人間によるレビューを経ましたが、それでも見落とされました。」

Lenny氏がその人物はまだ在籍しているのかと尋ねると、Kat氏の回答にはAnthropicの文化がよく表れていました。

「これはプロセスの問題です。最も重要なのは、そこから学び、より多くの防御策を追加することです。改善の大部分は既に適用済みです。」

OpenClawの決断

Lenny氏はOpenClawについても質問しました。最近、Anthropicはサードパーティツール（OpenClaw🦞など）がClaudeのサブスクリプション枠を使用することを制限し、コミュニティから大きな反発と抗議の声が上がりました。

Kat氏の説明は、Claudeへの需要があまりにも急速に伸びており、サブスクリプション枠はもともとファーストパーティ製品向けに設計されたものだということです。サードパーティツールの使用パターンは異なり、インフラにさらなる負荷をかけていました。

「私たちは最もスムーズな移行方法を検討するために多くの時間を費やしました。緩衝材として、各ユーザーにいくらかのクレジットを提供できたことは救いでした。しかし、私たちはファーストパーティ製品とAPIを優先的に保護する必要がどうしてもありました。」

Lenny氏は当然ながらAnthropic側の立場です。

「月額200ドルでほぼ無制限の使用量を提供していること自体、ユーザーを補助している状態です。企業も収益を上げる必要がありますからね。」

Coworkは過小評価されている

番組内では、Coworkに関するセクションもありました。

Kat氏は、来たる「Code with Claude」カンファレンスのために、Coworkを使って20ページの講演原稿を作成しました。彼女のやり方は、Google Calendar、Slack、Gmail、Google Driveを接続し、Coworkに講演のテーマと物語の方向性を伝えるというものです。

Coworkは約1時間かけて、X（旧Twitter）上の製品リリース記録、社内のローンチルームチャンネル、デモチャンネルを閲覧し、20ページのプレゼンテーションを自ら作成しました。

「朝起きて読みましたが、かなり良い出来でした。少し文字が多かったので、1回フィードバックをして調整しました。しかし、Coworkが当社のデザインシステムのテンプレートを読み取れるため、視覚的にはまるでAnthropicのデザイナーが作ったかのように見えました。」

彼女は製品を2つのカテゴリに分けて使っています。出力がコードの場合はClaude Codeを使い、出力がコード以外（PPT、ドキュメント、メール）の場合はCoworkを使うのです。

Applied AIチーム（顧客のClaude API採用を支援する技術系マーケティングチーム）は、おそらくAnthropic社内でエンジニアに次いでトークン消費量が多いチームでしょう。

彼らはCoworkを使い、顧客との打ち合わせ前にブリーフィングを自動生成しています。明日会う顧客は誰か、彼らが以前に何を質問したか、アクションアイテムは何か、特定の機能の最新リリース日はいつか、といった情報です。

これらはすべて彼ら自身が構築したワークフローであり、完成後はチームの他のメンバーと共有されています。

PMの未来

PMの役割の変化に関するKat氏の見解は、この番組の中で最も記録しておくべき部分です。

「コードはどんどん安くなっています。では、何がより価値を持つようになるのか？それは、何を作るかを決めることです。」

彼女によると、Anthropicは現在、プロダクトセンスのあるエンジニアを採用する傾向が強く、従来の意味でのPMが第一候補になるとは限らないそうです。

チームには、X（旧Twitter）でユーザーフィードバックを見てから、週末に自分で機能をリリースしてしまうエンジニアが何人もおり、PMの関与はほとんど必要ありません。

「PMとエンジニアという二つの役割は融合しつつあります。プロダクトセンスのあるエンジニアをもっと多く採用するか、あるいはエンジニアリングの方向性を示すためにより多くのPMを採用するか、その効果は似たようなものです。」

しかし、融合の代償は何でしょうか？

それは製品の一貫性です。

時には、同じニーズに対して二つの機能が同時に開発されることがあります。チーム内に二つの優れた案があり、どちらも良いと思えるため、両方をリリースしてユーザーに投票してもらうのです。新規ユーザーにとっては、どれを使うべきかを理解するのにより多くの時間がかかることを意味します。

Kat氏は、/powerup機能（組み込みのチュートリアルガイド）は、当初彼らが掲げた「製品はチュートリアルが不要なほど直感的であるべき」という原則に実際には反していると率直に認めました。しかし、機能があまりにも多いため、ユーザーは「この100の機能のうち、絶対に使うべき10はどれか」を誰かに教えてもらう必要が確かにあります。

なぜ間違えたのかをモデルに尋ねる

Kat氏はAI製品を作る上でのユニークなコツを共有しました。モデル自身にその行動を内省させることです。

例えば、彼女はモデルがフロントエンドのコードを変更した後にテストを実行するのに、実際にページを開いてUIを確認しようとは決してしないことに気づきました。そこで彼女はモデルに尋ねました。「なぜUIをチェックしないの？」

モデルからの回答は時に驚くべきものです。

「ある時、モデルはシステムプロンプトの特定の部分が混乱を招いたと言いました。またある時は、検証タスクをサブエージェントに委任したが、サブエージェントがそれを実行しておらず、自分もその作業をチェックしなかったと言いました。」

これらのフィードバックは、ハーネス（Harness）レベルの改善点を直接的に示しています。

「モデルの意思決定に好奇心を持ち続け、なぜその選択をしたのかを尋ねれば、何がモデルを誤った方向に導いたのかが見えてきます。そして、その隙間を埋めるためにハーネスを修正することができるのです。」

50のClaudeを並行実行

将来のロードマップについて、Kat氏は製品の進化をレンガを積み上げるようないくつかの段階に分けて説明しました。

第一段階：単一タスクの成功。明確なプロンプトを与えれば、モデルはマージ可能なコードや共有可能なドキュメントを安定的に出力できるか？

第二段階：複数タスクの並行処理。2025年末にはマルチコーディングが既に話題になるでしょう。現在、ユーザーはおおよそ同時に6つのClaudeを実行しています。

第三段階：50から数百のClaudeが同時に実行される。その段階になると、ローカルマシンのメモリは確実に不足するため、タスクはリモートで実行しなければなりません。インターフェースは、あなたが確認する必要のあるタスクがどれかを示し、モデルは自ら作業を検証できるようにすべきです。そうすれば、「完了」と表示されたときに安心して信頼できます。

「そして、このプロセスは自己改善できる必要があります。一度フィードバックを与えれば、モデルはその後の全ての実行で同じ間違いを二度と繰り返さないのです。」

Just do things（とにかくやれ）

Kat氏の人生のモットーは、「Just do things（とにかくやれ）」です。

「仕事は元々、虚構のようなものです。制約条件を理解すれば、何をすべきかを考え出し、それを実行に移せます。迅速に行動し、過ちから学び、もし間違えたら謝罪して修正するだけです。」

この言葉は、Anthropicの文脈では理解しやすいでしょう。彼女は、多くの企業では役割の境界が明確で、PMはPMの仕事をし、エンジニアはエンジニアの仕事をする、と言います。

一方、Anthropicが奨励しているのは、越境することです。問題を見つけたら、それが誰の縄張りかを気にせず、直接解決するのです。

95%で立ち止まるな

最後に記録しておくべきアドバイスは、自動化に関するものです。

Kat氏は二つの極端な例を見てきたと言います。一方は自動化を全く行わない人、もう一方はツールの設定をいじったり、MCPを追加したり、スキルを弄ったりすることに夢中になり、実際にタスクを完了するよりも多くの時間を費やす人です。

しかし、より一般的な問題は……多くの人が自動化を95%まで達成した後に、諦めてしまうことです。

「自動化が100%機能しないなら、それは真の自動化ではありません。最後の5%には確かに多くの時間がかかりますが、その労力を注ぎ込み、あなたの好みをClaudeに教え、完全に信頼して実行できるようになるまでフィードバックを与え続ける必要があります。」

彼女自身も、Coworkを使ってGmailの受信トレイをゼロにする作業では、まだ100%に達していないと認めています。

しかし、これこそが方向性です。繰り返し行う、好きではない作業を見つけてAIに任せ、それを完全に信頼できるまで磨き上げるのです。節約できた時間を、本当にやりたいことに使いましょう。

これこそが、AIが全ての人に与える真のレバレッジ（てこ）なのです。

◇ ◆ ◇