Anthropicのプラットフォームチーム200人はどう動いているか ― 長時間稼働エージェント時代の組織とインフラ
ベンチャーキャピタルKleiner Perkinsが配信する「Builders」シーズン2で、Anthropicのプラットフォームチームを率いるKatelyn Lesse氏とAngela Jiang氏が、同社サンフランシスコオフィスで対談に応じた。両氏は、ともにStripeの出身で、Lesse氏はStripeから直接Anthropicへ、Jiang氏は一度OpenAIを経てAnthropicに合流したという異色の経歴を持つ。対談では、この1年でエージェントが「長時間自律的に働く」段階に入ったことで生じたインフラ課題、Anthropicが200人という比較的小規模なチームで世界中のClaudeトークンを支える組織運営、そして、トークンのコスト最適化に関する独自の戦略まで、幅広いテーマが語られた。長時間・多岐にわたる対談のため、本稿ではトピックごとに整理する。
1. この1年の最大の変化 ― 「長時間働けるモデル」の登場
Lesse氏は、この1年で最も顕著な変化として「モデルが長時間、より賢く働けるようになったこと」を挙げた。1年前は、チャットボットとの対話のように常に人間がループに入る前提だったが、現在は、モデルが長時間にわたり自律的に作業を進められるようになったという。これに伴い重要性が増したのが、モデルの能力を最大限引き出すためのインフラ、そして、コスト最適化に関わるエンジニアリング課題だとした。Jiang氏も、これに同意し、以前は「モデルを特定の方向に誘導するために多くの作業が必要だった」のに対し、現在は「やってほしいことを伝えるだけで実行される」段階に入ったとしつつ、その裏側でエージェントがエラーから回復し、セキュリティ・コンプライアンスに準拠した形で動作するための「別種の課題」への対応が不可欠になっていると説明した。
1-1. 具体例 ― 金融分野での変化
Jiang氏は、金融分野を例に、従来は、「このExcelシートのこのセルをこう計算して」という具体的で限定的な指示にモデルを当てはめる形だったのに対し、現在は、「この会社のDCF(将来キャッシュフロー割引)分析をして、投資判断をして」という成果ベースの依頼が可能になったと説明。エージェントがスプレッドシートを開いて計算し、誤りに気づけば自ら再計算するところまで、人間が介入せずにやり遂げるようになったといい、金融・医療をはじめあらゆるナレッジワークで、同僚に頼むのと同じ感覚でアウトカムを委ねられる場面が増えていると述べた。
2. 二人の経歴 ― Stripeから袂を分かちAnthropicとOpenAIへ
2-1. Lesse氏 ― Stripe Connectでの経験からAnthropicへ
Lesse氏は、Anthropic在籍約1年で、以前はStripeでConnect(開発者プラットフォーム)を担当していた。開発者顧客が、プリミティブなビルディングブロックを求める場合と、より完成されたソリューションを求める場合の両方に対応してきた経験が、Anthropicでのプラットフォーム設計の考え方に直結しているという。移籍の理由については「業界そのものが劇的に変化していく中で、その変化の一部でありたいと強く感じた」と述べた。
2-2. Jiang氏 ― 一度OpenAIへ、その後Anthropicへ
Jiang氏は、Lesse氏とStripeを同時に退職したものの、それぞれ別のAIラボに進んだという経緯を明かした。当初OpenAIに加わった決め手として、StripeでV2 Accounts APIという新しいAPIを開発していた際、顧客がドキュメントをCursorに読み込ませただけで統合作業の70%を完了させてしまった体験を挙げ、「未来はもう来ている」と痛感したと語った。その後、AnthropicにいたLesse氏と互いに「そちらに来ないか」と説得し合った末、最終的に、Jiang氏が、Anthropicに移籍したという。決め手は人材の密度の高さと、「安全なAGI」というミッションへの共感だったとしている。
3. Managed Agentsの設計思想
3-1. 「差別化しない部分」はプラットフォームが引き受ける
Jiang氏は、Managed Agents(マネージド・エージェント)のプロダクト哲学として、「開発者は、自社の差別化要因になる部分に注力し、差別化にならない部分はやらなくていいようにする」という考え方を説明した。インフラや分散システムの構築は、「差別化されない」領域であり、これをAnthropicが引き受けることで、開発者は、顧客理解や自社の課題領域に関する知見を活かしたチューニングに集中できるとした。一方で「唯一絶対のハーネスがすべてを解決する」という考え方は経験上正しくないとし、複数の最適化レイヤーで開発者に適切な制御権を与える設計を志向していると述べた。
3-2. サンドボックスの「使い捨て」アーキテクチャ
Lesse氏は、エージェントが暴走しないようにする仕組みとして、作業を実行する「サンドボックス」(コンテナのような隔離環境)の重要性を説明した。従来のサンドボックス技術は本来一時的(エフェメラル)な用途を想定しており、長時間稼働のインフラとしては不向きだという課題があった。そこでAnthropicは、エージェントの「頭脳」にあたるハーネス部分を永続的なサーバー上で稼働させ、実際の作業実行が必要な場面でのみサンドボックスを立ち上げ、完了後に破棄するというモジュール型のアーキテクチャを採用。これにより、サンドボックスが落ちても接続が切れても、エージェント全体が停止することはないという設計思想を、社内で多数のエージェントを構築してきた経験から確立したと説明した。
3-3. 企業導入の入り口はClaude Managed Agents
Fortune 500企業の経営層が、「長時間稼働エージェント」導入を検討する際の第一歩について問われたLesse氏は、「まずClaude Managed Agentsを使うことを勧める」と明言した。ライフサイクルの初期段階では複雑な詳細を気にする必要がなく、より高次の抽象化されたプロダクトから始め、必要に応じてプロンプトキャッシングなど下位レイヤーのプリミティブへとカスタマイズを深めていける設計になっているという。社内でも、プロンプトキャッシングやコンテキスト管理の専門家であっても、日常的にClaude Managed Agentsを利用しているとし、「毎回ゼロからハーネスを組むことが必ずしも時間対効果の高い使い方ではない」と述べた。
3-4. 信頼構築の2つの層 ― セキュリティ境界と可観測性
企業がエージェントに対して抱く信頼の課題について、Lesse氏は、2つの層があると説明した。第一に、エージェントが機密性の高い社内データや本番システムに触れる際、セキュリティ境界の中で動作することを保証するアーキテクチャ(自前のサンドボックスを持ち込める機能など)。第二に、エージェントの動作を監査・検証できる可観測性の提供だとし、この2層が適切な信頼を築くために最も重要だと述べた。
4. インフラのどこを自社提供し、どこを外部に開放するか
Jiang氏は、モデルの提供・実行と、安全性分類器の運用については引き続き自社で担うとしつつ、「Messages API」(最もプリミティブなAPI)より上位のレイヤーについては、アーキテクチャに関する考え方はあっても、インフラそのものに強いこだわりはないと説明。自前のサンドボックスをホストできる機能や、MCPサーバーをファイアウォールの内側に置いたままエージェントからアクセスできる「MCPトンネル」インフラなどを例に挙げ、今後さらに自社ホスト可能な範囲を広げていく方針を示した。
5. 「データが盗まれる」という懸念とコストに関する誤解
5-1. クローズドモデルへの誤解 ― 「学習には使わない」
クローズドモデル利用への懸念(顧客データがAnthropicに渡り競争優位が失われるという懸念)について、Jiang氏は「私たちは顧客のデータをモデルの学習に使わない」と明確に述べた。
5-2. コスト削減は「モデルの使い分け」より「目的の理解」から
コスト削減の観点でオープンソースモデルとの併用を検討する企業に対し、Jiang氏は、「何を達成したいのかを問い直すべきだ」と述べる。多くの場合、目的は「製品をより早く出荷したい」「チームの効率を上げたい」といったビジネス上の成果であり、単純にモデルの種類を切り替えることが最適解とは限らないという。すべてのトークンが正確であれば無駄が生じないため、結果的により高性能で高価なモデルを使う方が安上がりになる場合もあると説明。将来的には、タスクごとに必要な知性のレベルを自動的に判定し、コスト構造に応じた最適なトークン配分を実現することを目指しているとした。
6. トークンに「異なる役割」を与えるという発想
6-1. Advising ― SonnetにOpusが助言する
Jiang氏は、単純にトークンを「実行」だけに使うのではなく、異なる役割を持たせる戦略をいくつか紹介した。代表例が、「advising(助言)」で、小さいモデル(Sonnet)が実行を担い、難しい局面でより大きなモデル(Opus)に助言を求める仕組みだ。評価実験では、Sonnetが、Opusの助言を受けながら実行すると、Opus単体に近い性能を、Sonnet単体より低コストで実現できたという。これは、Opusが「仕事のやり方」を教えることで、より少ないトークンで目的を達成できるようになるためだとした。
6-2. Grading(採点)とDreaming(夢見)
Claude Managed Agentsには、「outcomes(アウトカム)」という概念もあり、望ましい結果の基準(ルーブリック)を与えると、最初のエージェントの成果物を別の「採点役」エージェントが評価し、不十分なら再試行させる仕組みが備わっている。さらに、「dreaming(夢見)」と呼ぶ機能では、過去のセッションを振り返り、メモリやスキルとして書き出すことで改善を図るという。こうした「実行以外の役割」をトークンに与えることで、単純な力任せの実行よりも「1ドルあたりの知性」を高められるとの知見が得られており、将来的にはこうした戦略をユーザーが意識せずとも自動的に適用できるようにしたいとした。
7. 「ハーネス」とは何か
Lesse氏は、「ハーネス」という言葉について、最も基本的な形は、「ユーザーからの入力を受け取り、モデルに問いかけ、ツールを呼び出す」という単純なwhileループだと説明した。長時間稼働のエージェントになると、ツールを安全に実行する環境、会話状態を保存する仕組み、外部システムに接続するための認証情報をエージェント自身に見せずに注入する仕組みなど、周辺の要素が加わってくる。さらにその上位には「メタハーネス」あるいは「戦略」と呼ばれるレイヤーがあり、複数のエージェントが異なる役割を持って連携する設計に、近年より大きな付加価値(アルファ)が生まれつつあると述べた。
8. エージェント導入でよくある誤解と失敗
Jiang氏は、社外の多くのチームと接する中で見えてきた最も多い失敗として、「最初から大きすぎるタスクに挑もうとすること」を挙げた。例えば、銀行のKYC(本人確認)プロセス全体を一気に自動化しようとするケースで、人間が長年つぎはぎで作り上げてきたプロセスに、そのままエージェントを当てはめようとすると、うまくいかないことが多いという。むしろ野心的なプロジェクトであっても、新入社員が担当するような最も基本的な単位にまで分解し、エージェント前提でプロセスを再設計する方が成功しやすいと説明。人間であれば「一つ一つ確認しながら進めたい」と考える場面でも、エージェントには自律的に完結させ、必要なときだけエスカレーションさせる方がうまくいくケースが多いとした。
9. UXの未来像 ― 「より人間らしい」インターフェースへ
エージェントとのインタラクションの今後の形について、Jiang氏は、「チャットボックスをあらゆる場所に置く」段階から、「Slackのような、人間同士が働く場所でエージェントとやり取りする」段階への移行を紹介した。Claude in Slackを例に、裏側では複雑な処理が動いていても、ユーザー体験としては、馴染みのあるSlackのインターフェースそのものであることが、エージェントの民主化につながるとの見方を示した。Lesse氏は、エージェントが人間の見ていないところで作業を進める場面が今後さらに増え、「寝ている間にエージェントを走らせ、朝に結果を確認する」といった使い方に対応した適切な指示・制御手段を整備していく必要があると述べた。
10. プロダクト提供とFTE(専属エンジニア)派遣の使い分け
Jiang氏は、企業がAnthropicの支援を受ける際の理想形として、最終的には「Claudeと直接対話するだけで完結する」状態を挙げつつ、現状では、まだそこに至っていないとした。社員に「可能性の芸術」を実感してもらう段階では既製プロダクトが有効で、実際にAnthropic社内でも新入社員が、Claudeの製品にアクセスできるようになった瞬間に「誰にも許可を求めずに自分で作れる」という感覚を得る例を紹介した。一方、12年かかるような大規模なコード移行のような根深い課題については、既製プロダクトでは対応しきれず、専属エンジニアが個別に設計・伴走する方が適しているとし、実際にそうした取り組みで12年分の移行作業を数カ月に短縮できた例もあると明かした。
11. わずか200人でどう回すのか ― 組織論
11-1. 「殴られる準備」ができたチーム
Lesse氏は、プラットフォームチームが約200人という規模で、世界中を流れるClaudeのすべてのトークンを支えている実態を明かした。1年前に立てた計画通りに進んだことはほとんどなく、常に想定外の難題(非常に困難な安全性の課題や、想定を超えるスケールの課題)に直面してきたとし、「常に顔面にパンチを受ける準備ができているチームでなければならない」という表現を社内で使っていると語った。実際、直近半年で誰も予想していなかった規模の課題に直面したという。
11-2. Tiger Team方式による機動力
まだAnthropicは、特定の課題に全員で集中する「タイガーチーム」を柔軟に組成できる規模だとLesse氏は述べる。異なるクラウド全体へのプラットフォーム展開や、安全性・インフラなど社内の様々な関心事項を扱うチームと連携しながら、大きな課題が生じた際には機能横断的なチームを即座に編成し、対応してきたという。
11-3. PMは「純粋な問題解決」だけが求められる時代に
プロダクトマネージャーの役割の変化について、Jiang氏は「調整・プロジェクト管理・足並みを揃えるといった業務の多くが、もはや重要でなくなりつつある」と述べた。従来なら「このエンジニアリングチームの2週間スプリントをどう配分するか」といった調整に時間を割いていたが、そうした作業がClaudeとの対話で瞬時に完了するようになったため、PMには「何を本当に解決すべきか」「誰のために解決すべきか」という、より純粋な問題設定の能力が求められるようになったという。
11-4. プロダクト戦略は「投資のポートフォリオ」に近づく
Jiang氏は、プロダクト開発の進め方自体が変化したとも述べた。従来は入念な調査の末に一つの仮説に「ベット」して深掘りする形だったが、現在は不確実性の幅が非常に大きいため、複数の施策を素早く並行して試す「ポートフォリオ」的なアプローチを取るようになったという。多くのものが即座に構築できるため、優先順位づけへの過度な集中は最上位レイヤーでのみ重要になり、あらゆる結果がポジティブな外部性を生むような「器」を設計することが求められる、独特の考え方だと説明した。
11-5. 失敗への高い耐性、ただしエンジニアリングは別
こうした変化は、失敗に対する高い耐性を前提としているとJiang氏は認めつつ、エンジニアリング面では依然として高い正確性が求められるとした。実際、直近半年で誰も予想していなかった規模のスケール課題に直面するなど、当初の計画からの軌道修正が常態化していると両氏は口をそろえた。Lesse氏は、家族から「Claudeで働いているんだ、すごいね」と言われた時期には、既に世界中で流通するすべてのClaudeトークンが自分たちのチームが構築したシステムを経由している状態だったと振り返った。
12. 個人的な生産性の工夫
Jiang氏は、開発者プラットフォームに長年携わってきた経験から、自社製品を「ドッグフーディング」する時間を確保することが難しかったが、現在はエージェントに指示するだけで、顧客が実際にどう製品を使っているかをスクリーンショット付きで報告させるなど、格段に容易になったと明かした。Lesse氏は「リモートエージェント」を多用しており、気づいたことは何でもClaudeに「覚えておいて」と伝え、間違いがあれば「それは間違っていた、覚えておいて、二度としないように」と繰り返すだけのシンプルな運用で、生産性が大幅に向上したと述べた。
