Anthropic：多くの内部製品が未発表です

著者：デジタル開物

最近、Anthropicはアメリカ証券取引委員会（SEC）にS-1の新規公開株式申請書を提出しました。申請書によると、企業顧客はClaudeをビジネスの重要なプロセスに組み込むことで、消費者向けAIよりも強力な保持率と高い収益化を実現しています。企業市場に焦点を当て、Claude Codeを育成することは、Anthropicの研究および実験室チームの2つの製品実践であり、最近、Anthropicの研究および実験室チームの製品責任者であるDianne Na Pennがポッドキャスト「The Skip」に出演しました。チームはClaude 2からClaude 5.5ファミリーのコアモデル製品を担当し、Claude Code、MCP、Skills、Claude Designなどの製品の育成と拡張にも関与しています。この対話では、研究駆動型企業の月次計画と長期仮説、Claude Codeが基盤から製品に進化するプロセス、研究の優先順位とユーザーフィードバックのトレードオフ、Anthropic内部のプロダクトマネージャー文化、前線展開エンジニアPDEの役割などのトピックが議論されました。

Dianne Na Pennは、Anthropicは3ヶ月をかけて2週間後に無効になる年間計画を策定することはせず、月単位で計画を立て、今後6〜12ヶ月の業界の動向に基づく高レベルの仮説に基づいていると述べました。製品チームも「誰かがある機能を発表したら、明日には必ずそれに従わなければならない」という短期的なサイクルには陥っていません。

製品の育成において、Claude Codeはある日突然誕生したわけではなく、API顧客や内部および外部の人々の長期的な試行錯誤の結果です。コマンドライン端末のインタラクションパラダイムと、モデルがより多くのエージェントループを実行できるようにするハーネスが、真の化学反応を生み出しました。チームは微調整APIを提供するかどうかについて激しい議論を交わしましたが、核心的な考慮事項はモデルのイテレーションが非常に速いため、企業が独自に後処理や展開を行うときには、すでに2〜3世代遅れていることが多いということです。

さらに、研究の優先順位とユーザーフィードバックのトレードオフは、主に研究責任者との継続的な議論に依存しています。プロダクトマネージャーの価値は、問題がユーザーに与える影響を明確に説明することであり、研究チームにトレーニングパラメータを指定することではありません。チームはまた、集団休暇や2人で同じビジネスラインを担当するなどの方法を通じて、高強度の作業リズムに対処しています。

01 研究駆動型の戦略的リズム：月次計画と6〜12ヶ月の仮説

急速に変化する業界に直面して、製品チームにとって大きな助けとなるのは、Anthropicの研究組織も中長期的な戦略的思考を持っていることです。Dianne Na Pennは、会社の研究ミッションと北極星目標が長期的な視点を持っており、有益な引力を形成しているため、チームが「今日X、Y、Zなどの機能を発表したら、明日には必ずそれに従わなければならない」という短期的な対応サイクルに陥るのを防いでいると説明しました。

具体的な計画方法について、チームは月単位で、当月に達成すべき目標に焦点を当てていますが、これは未来の6〜12ヶ月の業界動向に対する高レベルの判断に基づいています。Dianne Na Pennは、チームは3ヶ月をかけて2週間後に無効になる年間計画を策定することはないと述べました。初期には完全なOKRプロセスを試み、全員が同じOKRに整合することを要求しましたが、使用量と採用率の仮説が著しく低いことが証明されると、これらのOKRはすぐに忘れ去られました。

理想的な作業方法は、まず3〜6ヶ月の次元での核心的な仮説を確定し、それを毎月に分解し、市場に対する敏捷な応答を維持しながら、月次計画を通じて長期目標に向かって進むことです。ライフサイエンス分野の例として、DarioなどはAIがライフサイエンス機関が病気を克服するのを助ける上で大きな役割を果たすと頻繁に語っています。これは短期プロジェクトではありませんが、具体的な行動に転換する必要があります。たとえば、毎月どのモデルトレーニングや製品投資テストを行う必要があるか、科学者や研究者がこれらのモデルにアクセスできるようにする方法、そして初期市場の動向に応じることを両立させる必要があります。

02 製品育成：基盤探索駆動と何をしないか

Claude Codeの誕生は、Anthropicの製品開発方法を理解するための一つのサンプルです。Dianne Na Pennは、製品開発はより基盤探索駆動であると考えています。なぜなら、この技術とそのエコシステムには無数の一般化の可能性が存在するからです。Claude Codeが登場するずっと前から、API顧客はモデルを使用してコードの自動補完を行っていました。コードを書くことはある日突然エージェントの特性を持つようになったわけではなく、内部および外部の人々が試行錯誤を繰り返すさまざまな段階を経てきました。コマンドライン端末というインタラクションパラダイムと、モデルがより多くのエージェントループを実行できるようにするハーネスが、製品体験とモデル能力を結びつけ、真の化学反応を生み出しました。

優先順位の判断は、チームが押し出す核心テーマに依存し、現在の技術スタックが体験や効果の面で実行可能か、ユーザーが十分な驚きを感じているかを迅速に検証できるかどうかに大きく依存しています。現在の戦略は、To Bおよび企業市場に焦点を当てています。理由は、瞬息万変する消費者市場と比較して、企業側の需要がより安定しているからです。

何をしないかも同様に重要です。チームは微調整APIを提供するかどうかについて激しい議論を交わしましたが、そこから形成された製品の考え方は、核心モデルのイテレーションが非常に速いため、企業チームが独自に後処理、最適化、展開を行うときには、すでに2〜3世代遅れている可能性があるということです。最終的には、再び最初からやり直さなければならなくなり、Dianne Na Pennはこれが会社、ユーザー、顧客にとって賢明な投資であるかどうかを問いかけました。「3ヶ月または6ヶ月後に何が変わるか」を常に問い続けることで、チームはどの製品が市場に出す価値があるかを明確にするのを助けます。内部で開発されたプロトタイプの多くは最終的に外部に公開されませんでした。なぜなら、最初の目的はアイデアを刺激したり、技術を検証したりすることだからです。

03 研究の優先順位とユーザーフィードバック：プロダクトマネージャーが研究チームと協力する方法

研究者は目の前のユーザーだけを見ているわけではありません。Dianne Na Pennは、最前線のAI実験室の研究者は短期的な既存ユーザーだけでなく、しばしばまだ現れていないユーザー群や技術の二次的影響を考慮していると指摘しました。チーム内部で合意が得られた場合、サービスは現在のユーザー層だけでなく、未来のユーザーエコシステムにも向けられているため、多くの問題が解決されます。

たとえば、製品チームが「なぜClaudeがJSONやSchema形式を出力する際にもっと良くできないのか」と提起することは、研究者がコンピュータ制御や推論能力の最適化に関する作業を一時停止しなければならないことを意味するかもしれません。これは伝統的なPMのロードマップのように段階的に既存の体験を改善することができるわけではなく、より長期的な技術への賭けと現在のトレーニング投資の間でのトレードオフを行う必要があります。問題を評価する際には、モデルの知能が自然に進化するにつれて、自動的にP0レベルではなくなる可能性があるかどうかも判断しなければなりません。Dianne Na Pennは、これは完璧なパスを計画することに慣れているPMにとっては落胆する答えであると認めています。

記憶機能の例を挙げると、2年前、チームは「Claudeが記憶機能をうまく発揮できていない」というような広範なフィードバックを頻繁に受けていましたが、今でも聞かれることがあります。しかし、その背後にある技術の複雑さは以前とは比べ物になりません。記憶のパフォーマンスが悪いことが直接的にユーザーの離脱を引き起こす場合、チームは傍観することはなく、製品の観点から別のアプローチを取ることができるかもしれません。たとえば、使用シーンを適切に制限し、新世代のモデル能力の向上を待つ間に、ユーザーが依然として満足できる体験を得られるようにします。まとめると、3つのポイントがあります：異なるライフサイクルのユーザーを考慮する必要があること；成熟した技術に基づく製品開発と比較して、この不確実性に満ちた開発が時には本当に落胆させることを認める必要があること；そして最も重要なのは、認知モデルを構築し、最終目標と自分が制御できる手段を明確にすることです。根本的な研究を修正することが常に唯一の最適解であると信じるのではなく。

意思決定は主に議論に依存しています。新しいバージョンのClaudeをトレーニングする際、チームは研究責任者たちと定期的なスタンドアップミーティングを開催し、トレーニングの進捗を追跡し、調整が必要な点や確信を持っている点を議論します。プロダクトマネージャーの価値は、ある問題がなぜP0であるべきかを説明することにあります。それはユーザーに大きな影響を与え、解決しなければ期待される成果を提供できないからです。逆に、極少数のユーザーから不満の声が聞かれるだけであったり、関連機能の使用頻度自体が減少している場合は、P2と見なされ、代替パスの設計に移ることがあります。Dianne Na Pennは、PMは研究チームに特定のトレーニングパラメータを変更するよう要求する権限はなく、エンジニアリングチームが指示に従って一行ずつコードを書くことを受け入れないのと同様であると強調しました。PMがすべきことは、問題がユーザーにどのような影響を与えるかを明確にし、共に解決策を探ることです。もしプロンプトなどの手段が緩和できない場合、最終的にはモデルのトレーニングを調整することになります。

04 内部の人材文化と育成システム

採用時、背景の多様性はチームの共通点です。多くのプロダクトマネージャーのキャリアパスは、同じ会社で順調に昇進するのではなく、むしろクロスボーダーの探求のようなものであり、これが彼らに非常に強い適応能力を与えています。技術が急速に変化する中で、過去の仮説が常に打破されています。その中には、新しい事柄を迅速に習得することが得意な人や、スタートアップで初代プロダクトマネージャーを務めた人がいます。Dianne Na Pennは、このような履歴は非常に競争力があると考えています。なぜなら、初代プロダクトマネージャーは顧客成功、IT運用、さらにはビジネス開発を兼任することが多く、こうした多様な役割をこなすことで得られる敏捷性がチームのニーズに合致するからです。チームはまた、元研究者や、長い間同じ会社に在籍し、製品やワークフローに対する固定観念を打破したいと願う従業員を採用したこともあります。

入社後も、ハードルは同様に高いです。チームに参加することは、入社初日からスムーズに元の職務に戻ることを意味するわけではありません。Dianne Na Pennは新入社員の入社プログラムで、最初の2ヶ月はキャリアの中で最も苦しい時期であるべきだと明言しました。もし苦痛を感じるなら、それは正しい状態を示しています。なぜなら、リズムが非常に速く、短期目標と瞬息万変する中長期計画の間でバランスを取る必要があり、担当するビジネスラインの製品計画、戦略ロードマップを策定し、成果を提供しなければならないからです。

チームは意図的に非常に挑戦的な初期適応タスクを設定します。迅速に適応できる人はすぐに成長の加速レーンに入りますが、「難しすぎる」と不満を言ったり、さまざまな理由でできない人はますます苦労することになります。入社して1、2ヶ月以内に基本的な潜在能力を把握できることが多く、最終的には成長型思考が試されます。

どこでつまずくことが多いかを尋ねられたDianne Na Pennは、特に大企業から来たプロダクトマネージャーが、厳格な階層的な作業モデルに慣れていることを指摘しました。副社長が指示を出すと、実行チェーンは盲目的に従い、誰もその指示が現在の正しい選択であるかどうかを疑問視することはほとんどありません。これは、最も近い研究開発モデルである学術界とは全く異なります。学術界では、1年生の博士課程の学生でさえ、指導教官に疑問を呈することができます。

Anthropicでは、従業員は固定観念を打破し、最高科学者のJaredに意見を述べる勇気を持つ必要があります。たとえば、彼のある技術に関する記事を読んだ後、いくつかの前提条件を無視していることを指摘し、調整後にユーザーにとってより価値のあるものになるよう提案することです。これは、初期段階で声を上げて議論に参加することを要求し、高管たちがすべてを考え抜いていると仮定するのではなく、表現は好奇心と相互信頼に基づく必要があります。他人を無分別に非難するのではなく、詳細な証拠を示すことが求められます。チームが求めるのは、深い議論に参加し、新しい視点を補足し、既存の基盤の上でイテレーションを行い、実現を推進することができる人です。最初に提案されるアイデアは、2、3年前に考慮されたが保留されたものである可能性がありますが、誰かが苦労して研究し、適切な方法で既存の仮定に疑問を呈し、独自の見解を提案することで、しばしば大きな成功を収めることができます。

このような風潮の根源は、Dianne Na Pennはモデルのイテレーションの頻繁さに関連していると考えていますが、根本的には企業文化に起因しています。会社は研究実験室から始まり、多くの共同創業者が第一原理を非常に重視しています。この技術が今日の突破口を得たのは、過去の仮説に制約されず、仮説に疑問を持ち、自ら実験を通じて検証する勇気があったからです。これは、トップ研究者間での最も核心的な運営ロジックです。内部のコミュニケーションは非常に透明であり、大多数のチャンネルは完全に公開されています。あなたがグループで特定の製品の詳細について議論しているとき、あなたが気づかなかった誰かが礼儀正しく割り込んで、別のアプローチを考慮したことがあるかどうかを尋ねるかもしれません。チームは相互に肯定し、思考を拡張し続ける協力を重視しています。

成功したプロダクトマネージャーについて、もう一つのポイントは、この技術に対するほぼ狂信的な熱意です：入社するとすぐにプロトタイプ段階で自社製品の機能を深く試用したり、最新のモデルを繰り返しテストして評価を公開したりして、実際の行動で製品やモデルの最適化を証明します。隅に隠れて要件文書を書くのではなく、積極的にモデルや製品の実現を推進することこそが、トッププロダクトマネージャーが際立つ証です。

多くの初級プロダクトマネージャーは、環境が悪く良いポジションが少ないと不満を言いますが、Dianne Na Pennの観察は正反対です：チーム内の経験の浅いプロダクトマネージャーは非常に高い作業効率と無限の潜在能力を示しています。その理由は、既存の組織構造の束縛から意図的に脱却する必要がなく、ここでは他人が指示を出すのを待ったり、上司が要件文書にサインするのを待って次のステップを進める必要がないからです。やる気に満ち、主体性の強い人は「これは私が担当するモジュールだから、実現を保証しなければならない」と考え、顧客とコミュニケーションを取り、研究者と連携します。相手が研究主管であろうとなかろうと関係ありません。

大企業の背景を持つプロダクトマネージャーと比べて、これらの人々は各チームを調整し、段階を踏んで確認するプロセスを経る必要がなく、軽装で臨むことが非常に効率的です。しかし、これは中堅や上級のプロダクトマネージャーがこれらの特性を持っていないという意味ではありません。チームには起業経験のある前の上級プロダクトマネージャーもいれば、内部で困難なプロジェクトを克服し、真剣に戦ってきた人もいます。

Dianne Na Pennによれば、核心は、巨大な組織の慣性や抵抗を克服する必要があることを成し遂げたかどうかです。そのような粘り強さと使命感は、他のどの特性よりも強力であり、常に好奇心を持ち、あらゆる手段で答えを探し、未知の問題に直面したときに自己駆動を実現することを意味します。受動的に待つのではなく。

育成において、チームの出発点はプロダクトマネジメントの定義です。Dianne Na Pennは、新技術の初期の状態に戻るべきであり、機械的に職務を定義するのではなく、最も重要な原則は依然としてユーザーの周りにあります。つまり、どのように複利効果を持つ方法でユーザーに価値を創造するか、他の実行アクションはそこから派生します。もしかしたら一年後にはモデル評価を書くことがユーザー成果を定義する最良の方法ではなくなるかもしれませんし、もしかしたら誰もが直接コードを書いてプロトタイプを作成しなければならないかもしれませんが、北極星の目標は変わりません。

入社プロセスは非常に高圧的です：新入社員は最初の2〜3週間でユーザー調査を完了し、モデル評価を作成し、製品ロードマップを策定しなければなりません。多くの人がさらに2週間の猶予を求めますが、これは実行力を引き出すためであり、彼らを会社のリズムに合わせた実戦状態に入れるためです。実際に効果があることが証明されています。同時に、新人は最も優先度の高いコアビジネスラインに直接配置され、チームは小規模を維持し、各人が同時に2〜3つの方向を兼任することを好み、部門間のコミュニケーションやアイデアの衝突、迅速な学習を促進し、強い納品の緊迫感をもたらします。

チームは毎年1回トレーニングキャンプを開催し、その核心は指数関数的成長を駆動できる製品の作り方を共有することです。つまり、モデルの基盤能力が向上するにつれて、製品の価値も指数関数的に爆発することです。内容にはClaudeの最適化、高品質なプロンプトの作成、モデル評価の実施が含まれ、コースの録画はすべての新入社員の必修科目となります。この取り組みは2024年に始まり、当時チームは4〜5人しかおらず、日常業務は研究型PMに近づき始めました。例えば、ユーザーからのフィードバックデータを読み、評価を作成することです。製品機能に大いに役立つので、より多くの人に習得してもらいたいと考え、操作手順、重要な指標、価値の少ない部分を記録しました。最初は研究型プロダクトチーム以外のPM向けでしたが、現在はAnthropic全員に開放されています。

トレーニングキャンプはオープンQ&Aプラットフォームを構築する機会でもあります。Dianne Na Pennは、PMは単にモデルの反復を待つ必要はなく、プロンプトを修正することで望む結果を得ることができると強調しています。現場でのデモはハードルを下げ、技術の神秘感を打破しました。営業チームも参加後に「これが評価で、これがプロンプトなんだ、私もできる」と驚嘆しました。これらの方法は完全に複製可能で、スケールアップして普及させることができ、どの会社でも実現可能です。

メンター制度に関しては、新入社員はチームの経験豊富な社員と1対1で指導を受け、Claude Tagなどの内部ツールを利用して入社をサポートします。新人には過去2ヶ月のグループチャットの記録を見返すことがよく勧められます。なぜなら、会社に入ることは熱心に進行中の対話に途中参加するようなもので、最も効率的な方法は、まず十分な準備をし、自分のビジネスの背景に対する理解を表現し、意見を求めて積極的に参加することだからです。会社が知識を与えてくれるのを待つのではありません。

05 フロントラインデプロイエンジニア：深さと広さの選択

プロダクトマネージャーがフロントラインに深く入り込み、顧客のシーンに埋め込まれるべきかどうかについて、Anthropicはフロントラインデプロイエンジニアと専用のフロントラインデプロイチームを配置し、企業顧客がプラットフォームやアプリケーションで大規模に実現できるよう支援しています。Dianne Na Pennは、このフロントラインでの深耕スキルが不可欠であることに同意していますが、現実の矛盾は、一方で深く入りすぎると、もう一方で妥協せざるを得なくなることです。このことに常に引き裂かれています：研究モデルの反復に常に追随したいと思いながら、すべての顧客のフィードバックを聞きたいと思っていますが、現在の規模ではすべての顧客の電話会議を傍聴することはできません。

重要な問題は、ビジネスのフロントラインの深い洞察をどのように効果的に上にフィードバックし、担当する製品に反映させるかです。チームはAPI顧客や新しいモデル機能を試用する顧客から直接フィードバックを収集しますが、エネルギーと生産能力が完全に専任のフロントラインデプロイを許可しないため、フロントラインのビジネスチームと密接に協力し、彼らの洞察を補完的な検証として利用します。現在のモデルは、各PMが顧客のフロントラインに根ざし、トップ研究チームと整合することを要求するのではなく、全景的なビジネスコンテキストの共有に重点を置いています。両方の側面で非常に深い専門性を達成することは非常に困難です。

効果的な経験の一つは、チームが後に内部アプリケーション型およびフロントラインデプロイエンジニアチームから一部の人を選抜してPMに転職させ、驚くべき成果を上げたことです：彼らは深いビジネス感覚を持ち、Harnessの原理、ユーザー側のアプリケーションアーキテクチャと使用動機を深く理解し、フロントラインの声を開発チームにスムーズにフィードバックすることができます。Dianne Na Pennは、2023年にClaude.aiが初めてリリースされたとき、唯一のベータ版製品であった時期に、システムプロンプトを長い間自分で書いていたことを思い出します。その後、新しく加入したPMに引き継がれましたが、これがフロントラインデプロイエンジニアの日常です。技術の深さを抽象的に語ることはしばしば空虚ですが、実際に落とし込むための最も堅実な方法は、フロントラインデプロイエンジニアとして顧客の声を直接聞くことかもしれません。これはPMのキャリアパスを再構築する一つの答えかもしれません。