Anthropicはいかにして世界No.1のLLMを安全に提供するのか：脳と手を分離する

AnthropicがIPOを控えてS-1を公開したタイミングで、Latent Spaceは同社の「Claude Platform」の内側を掘り下げる特別エピソードを配信した。ゲストはKatelyn Lesse（プロダクト責任者）とAngela Jiang（エンジニアリング責任者）で、両者はStripe時代からの長い同僚関係にあり、モデルローンチのたびに製品側とエンジニアリング側の判断を突き合わせる役割を担っている。エピソードの中心はOpus 5.5のリリース直後に収録されたもので、単なるベンチマークの話ではなく、フロンティアモデルを「安全に、しかも効率的に」世に出すために何が必要になったのかという、この1年で激変したローンチ業務の実態が語られた。

背景としてホストが提示した数字は強烈である。従業員あたりの直近12カ月売上は660万ドルで、1年前の140万ドルから約5倍に拡大。2025年第2四半期には売上1ドルあたり0.5ドルの損失だったのが、今やコスト1ドルに対して2ドルの売上を生む構造に転換し、GAAPベースで19%の黒字四半期を初めて計上した。ホストはこれを「改善ループ」と「投資ループ」の二重螺旋として整理し、Claudeが使われるほどモデルが良くなり、モデルが良くなるほどユースケースが増える循環が効率を押し上げていると論じた。さらにS-1では、年間10万ドル以上を支出する顧客の半数以上がClaude Platformを利用していると開示されており、Anthropicがモデルラボからハイパースケーラー的なクラウドプラットフォームへと脱皮しつつあることが示されている。

6:25「脳」と「手」を分離するアーキテクチャ

このエピソードで最も繰り返し登場する設計思想が、エージェントの「brain（脳）」と「hands（手）」を分離するというものだ。Claude Managed Agents（CMA）では、ハーネス（エージェントの制御ループ）はAnthropic側の耐久性のあるサーバー上で動き、実行環境であるサンドボックスやコンテナは必要なときだけ起動される。この分離によって、サンドボックスが落ちてもエージェント全体は死なず、初期リクエストに対して迅速にトークンを返せる。初期のプロトタイプは「Claude Codeをサンドボックスに入れてAPIをかぶせる」という素朴な構成だったが、サンドボックスの起動を待たないとトークンが返らない点と、サンドボックス死亡時にエージェントごと失われる信頼性の問題から、この構成は耐久性・拡張性のある解としては採用されなかった。

興味深いのは、この分離が当初はレイテンシと信頼性のために設計されたのに、後にセキュリティ上の最重要特性として評価されるようになった点である。認証情報はエージェントとは別のVaultに保管され、エージェントはプレースホルダーしか見ない。外部サービスへの通信時にプロキシが正しい資格情報を注入するため、エージェントが資格情報を悪用する経路が物理的に存在しない。加えてサンドボックス側ではドメイン許可リストやネットワーク遮断といったegress制御が可能で、信頼できないコードが実行されても外部へ勝手に到達できない「secure by default」の構成になっている。あるプロダクトマネージャーが最初から「この設計の最重要性はセキュリティだ」と主張していたが、当時は誰も真剣に聞いておらず、今になってその正しさが証明されたという顛末も語られた。

この設計は社内のあらゆる製品に波及しつつある。Claude Codeは歴史的にローカルマシン上で広い権限を持つ「危険な」ツールとして知られてきたが、現在はこのパターンへ移行しつつあり、Projectsのような機能も「脳はクラウド、手はローカル」という同じ形の延長線上にあると説明された。CMAとClaude Codeはハーネス自体は共有しないものの、サンドボックスフリートやAPI基盤といった実行インフラは共通で、プラットフォームチームが両方を支えている。

サンドボックスからの「脱出」インシデントが世間で話題になっている点についても整理がなされた。報道されている事例の多くは学習中のモデルに対して「不可能な課題を解け」と追い込む設定で起きるものであり、本番ワークロードではオンラインのセーフガードが稼働し、ハーネスと実行環境が分離されているため同じ問題は構造的に起きにくい。ただし長期間動くエージェント自体が新しい領域であるため、業界全体が手探りでガードレールを整備している段階だという認識が示された。

9:18蒸留対策と「思考ブロック」をめぐる綱引き

ローンチの舞台裏として最も具体的だったのが、推論トレースの蒸留対策である。研究チームが責任ある開示のもとで公表した論文は、 proprietary なLLMからchain-of-thoughtを抽出する手法を示したもので、Anthropicはこれを既知のギャップとして認識していた。蒸留を防ぎたい理由は商業的な損失ではなく安全性にある。Anthropicのモデルは出力トークンに対して分類器やセーフガードを走らせているが、蒸留されたモデルがセーフガードなしで運用されれば、世界に悪影響が及ぶ可能性がある。実際、蒸留されてもAnthropicには利用料が入るため商業的にはむしろ収入になるという指摘もあった。

対策の核心は、ターンをまたいで「thinking blocks」の保存を必須化することだ。ただしこれを一方的に強制すれば、コンパクション戦略など既存の統合を壊してしまう。そこで同社はUXへの影響を二層に分けて考えた。ひとつは「統合変更が必要で面倒だが、同じことは達成できる」層、もうひとつは「以前できたことができなくなる」層で、後者を絶対に避けることを最優先した。結果として、保存を前提とした新しいコンパクション機能をAPI側で提供し、オープンソースのハーネスメンテナーやCognition、Cursorのような主要顧客と事前に調整してアップグレードを促した。複数アカウントをまたぐ抽出への対策も進めており、測定可能な範囲では蒸留の効果が実際に減少しているという。

19:09モデルローンチを覆う安全政策のレイヤー

かつてはモデルを学習して出荷するだけだったローンチ業務が、今や大半が安全対策の仕事になっているという証言は重い。データ保持ポリシーの設計はその代表例だ。多数のアカウントがネットワーク上でモデルを様々な形で使う状況では、トークンが流れるオンラインの瞬間だけでは悪意ある利用や蒸留を捕捉できない。そのため一部モデルでは自動レビューや人手レビューのためのデータ保持が必須になる。Opus 5.5はFableと異なりデータ保持要件を持たないが、これはモデルごとに毎回判断される政策決定である。

サイバー領域やライフサイエンス領域の検証プログラムも同様に、ローンチごとに整備が必要になった。デュアルユース（防御的なセキュリティ研究やバイオ研究など）の正当な利用者には、申請と審査を経てセーフガードを緩和したモデルへのアクセスを与える仕組みで、用途の確認とユーザー単位のスコープ設定が前提となる。こうした許可が確実に機能するよう、認可情報がシステム全体を貫通する「trust grant」の仕組みが構築された。特定モデルへのアクセス権やプログラム参加資格を、APIキーを渡してフィーチャーフラグを立てるだけの雑な運用ではなく、リクエストのホットパス上で検証する堅牢な認可基盤として実装したのである。

この認可基盤は「Zanzibar的なものか」というホストの問いに対し、IAMをAnthropic向けに作り直したようなものだという説明がなされた。Fable 5.1で保存必須化の移行猶予を与えた際の「既存顧客の grandfathering」の追跡にも、このtrust grantがそのまま使われた。汎用的に設計したプリミティブが、後から想定外の用途に何度も再利用されるというパターンが繰り返し現れ、結果として「汎用的に作る」という判断が報われ続けているという。

24:09確率論的プロダクトマネジメントと「1ボタンで止める」備え

Fableのデプロイ撤回という前例は、製品開発の意思決定のあり方を変えた。従来のプロダクトマネジメントは「起こりそうなこと」を順序立てて賭けるものだが、政府関与による撤回のような出来事は事前に予測できない。そこでチームは、起こる確率は低いが起きたときの影響が大きい事象に備えて「ヘッジのポートフォリオ」を意図的に組むようになった。その結果、想定したヘッジの多くが実際に使われるという逆説的な成果が生まれている。

象徴的なのが「全顧客のモデルアクセスを1ボタンで撤回できる仕組み」だ。インシデントが起きてから過剰に備えるというプラットフォームエンジニアリングの定石を、Anthropicは実際にワークアイテムとして組み込んだ。これは先述のtrust grant基盤の上に載っており、検証プログラムやモデルアクセス管理と同じプリミティブを全ユーザーの下に敷くことで、いざというときの制御を可能にしている。

アクセスプログラムの設計でも同じ教訓が語られた。当初は検証ポータルと特定能力の付与に特化するか、より汎用的にするかで迷ったが、汎用性を選んだことで、後にモデル全体へのアクセス管理、信頼済みアクセスプログラム全般、モデルのデプロイ撤回など、想定外の用途に次々と転用できた。通常のプロダクト感覚なら「用途を絞るべき」となるところを、あえて汎用に振る判断が効いているという。

30:37モデルローンチの実務と評価の現在地

ローンチプロセス自体は「安全対策を除けば機械化されてきた」という。モデルを切り、社内でドッグフーディング（本人は「ant feeding」と呼ぶ）し、早期に違和感を検出する。Claude自身を社内で大量に使っているため、どのバリアントが優れているかの初期シグナルが得やすい。その後、Claude CodeやCoworkといったファーストパーティ製品、あるいはCognitionやCursorのようなAPI顧客の早期アクセスプログラムを通じてフィードバックを集める。顧客側はハーネスに変更を加える必要があり、評価スイートでの性能と「 vibes 」の両方が集められる。

モデルフィードバックの現状は依然としてSlackチャンネルでの非構造的なやり取りが中心で、非決定論的な製品の性質上やむを得ない面がある。ただし早期アクセスに招かれるのは堅牢な評価基盤を持つ顧客に限られ、業界全体でエージェント製品の評価が整っている例は驚くほど少ないという指摘があった。最も有用なフィードバックはネガティブなもので、回帰や弱点を突きつけられるほど修正が進む。

評価における根本的な難問が「アラインメント対パーソナライゼーション」だ。デフォルトの人格や挙動を全員に提供しつつ、個々のClaude.mdに応じた調整も求められる。あるホストはFrontier Codeベンチマークが過剰な活動を減点する設計であるため、パーソナライズされた設定を反映できないベンチマークがOpus 5.5を不当に低く評価している可能性を指摘した。これに対し、パーソナライゼーションは現状うまく解けていないという率直な回答があった。reasoning effortのようなパラメータを顧客セグメントごとに調整する程度のことで、多数のClaude.mdに応じた個人化はスケールしない。将来的にはユーザーが信号を提供したりチューニングしたりできる方向に進む必要があるという。

パラメータの乱立も課題として挙がった。effort、budget、様々な設定がAPI上に混在し、どの組み合わせが正解か誰にも分からない状態になっている。Claude Codeのデフォルトeffortがmediumに変わったのも、こうした調整の一環だ。CMAの価値提案のひとつは、こうしたパラメータ調整や破壊的変更への対応をAnthropic側がハーネス込みで引き受ける点にある。

42:17CMA、Dreaming、そしてマルチエージェントの設計原則

Claude Managed Agentsは、生のトークンアクセスを提供するMessages APIの上位抽象として位置づけられる。エージェントを定義しセッションを開始すれば、ハーネスやインフラの構築をスキップできる。ローンチ後、業界各社が類似機能を出したことにも触れられた。CMAのハーネスは意図的にシンプルに保たれており、過度に意見を押し付けず、ベストプラクティスと定型化できる部分だけを取り込む方針だ。その上に、ユーザーが独自のハーネス戦略を積み上げられる余地を残している。

その代表例がDreamingで、これはCMAの上にCMAを重ねるマルチエージェント構成である。別のマネージドエージェントを起動して前のエージェントを検査させ、記憶を書き込ませる。「マネージドエージェントの上にマネージドエージェント」という入れ子構造で、モジュール化された部品を組み合わせれば様々な戦略が作れるという設計意図の実証になっている。best-of-Nや検証エージェント、並列エージェントを大量に起動して記憶を共有するような実験的なハーネスもコミュニティで現れており、近くマルチエージェント戦略を構築するためのプリミティブとテンプレートが公開される予定だという。

マルチエージェントの実践的な指針も示された。基本的には1人のリードを置き、並列化可能でコンテキストを共有できるタスクを分割する。各サブエージェントが非同期で互いをブロックしないことが重要で、この2原則さえ守れば後はClaudeに設計を任せてよい。Claudeは自分を分割し複製し適応する方法をますます学習していくため、共有状態と非ブロッキングを担保すれば、これまで難問とされてきた問題を一撃で片付ける可能性もあるという期待が語られた。

評価については、静的な決定論的評価からLLM-as-a-judgeまで種類は様々だが、最も多い失敗は「評価への投資不足」だという。完璧な少数の評価セットは存在せず、相対的に大きなスイートが必要になる。まずは簡単なものから始めるべきで、評価手法のメニューを眺めて複雑な仕組みを試す前に、評価を1つも持っていない状態を脱することが優先される。Claude自身が評価作成を手伝える点も強調され、JSONを眺めて固まるより、左右比較のUIを作ってClaudeに評価させ、その結果をClaude自身に消費させて改善ループを回す方が productive だという。エンジニアリングを研究のように扱い、目標を事前に評価として形式化し、失敗の原因が評価側にあるのか環境側にあるのかモデル側にあるのかを見極めることが、AIエンジニアリングの中心になりつつある。

53:28Rustへの全面移植とCPU枯渇という新しい制約

スケールの話は、GPUではなくCPUの枯渇という意外な制約を中心に展開された。製品サービス、API、アプリ、サンドボックス、そしてClaudeが書くコードの増加に伴うCI実行まで、あらゆるものがCPUを消費する。かつては予算の範囲内でオンデマンドにCPUをスケールできたが、今は事前のキャパシティプランニングが必要で、業界全体が「あらゆるものが不足している」状態にある。Anthropic全体でCPUはゼロサムの配分問題であり、研究用サンドボックスと製品用サンドボックスの間で取り合いになっている。

この制約への回答として最も印象的なのが、Messages APIのRustへの全面移植だ。チームにはRust経験者が1人もいなかったが、Claudeがコードを書き、人間が分散システムとしての設計を担うという分業で実現した。重要だったのは実装そのものより「計画」と「検証」で、API全体のRust版フォークを作ってシャドウトラフィックを流し、Python版とRust版の出力を突き合わせて検証した。通常なら数年がかりで部分移行するところを、一気に移植して徐々にトラフィックを切り替えるという離れ業で、CPU使用量は40〜50%削減、time to first tokenは10〜20%改善したという。機能追加の誘惑は徹底的に排除し、純粋な「ポート」に徹した点も強調された。

移植チームの次の狙いは、会話状態を毎回クライアントが送り返さなくて済むような再設計だ。長い会話ではコンテキストが積み上がるため、状態を一定期間サーバー側で保持できればレイテンシと効率の両面で大きな利得がある。ただしAnthropicは3つのクラウドすべてで稼働しており、特定クラウドの特殊なコンピュート（Cloudflare Durable Objectsのような）に依存できないため、最もバニラなプリミティブしか前提にできない難しさがある。それでもCPUを売りたい事業者からの提案は歓迎で、品質基準とスケール基準を満たすことが条件だと述べられた。

1:21:08スロップ対策、DevRelの再設計、そしてOpus 5.5の使い方

終盤は組織運営とコミュニティ論に移った。スロップ（AI生成の低品質な成果物）対策については、Claudeの利用自体は推奨しつつ、成果物の品質責任は人間にあるという原則が共有された。読む側の負担を増やすような丸投げは許容されず、ひどいものは差し戻す。一方で、em dashのような「Claudeっぽさ」の些細な痕跡に過剰反応して、実際には質の高い成果物を忌避するのも非生産的だとして、バランスが模索されている。コードについては、人間がシステム設計に関与し、実装はClaudeが担い、検証基盤で品質を担保するという分業が定着しつつあり、全行レビューよりも全体設計とテストへの信頼に重心が移っている。

プロダクトマネジメントのスロップについては、モデルの能力を使って10倍の機能を出荷するのではなく、ユーザー理解や実験に時間を使うべきだという戒めが語られた。実験コストが下がったからといって何でも試すのではなく、意図した目標に能力を使うことが重要で、これはブログ記事「2週間でClaudeのUIを速くする」の事例（13目標のうち12を3日で達成）にも通じる。目標を絞り、検証を伴う高速実行が理想とされた。

DevRelについては、CaitlinがStripe時代に学んだ「プロダクト・コンテンツ・コミュニティ」の3本柱を土台に、プラットフォームとClaude Codeで別チームを立ち上げた経緯が語られた。プラットフォーム事業は巨大でありながら、研究やポリシー、アプリケーション製品の陰で世間の物語から抜け落ちやすい。そこでLance（最近JoinしたAddy Osmaniとともに）のような技術的に深い人材が、メモリ管理やコスト管理、評価構築といった実践的な内容で思想的なリーダーシップを発揮する方向を目指している。ホストはDevRelの「フロントオフィスとバックオフィス」分離を提唱し、製品責任者やエンジニアリング責任者本人が前面に出て、聞き手・書き手のチームがそれを支える形が今後は主流になると論じた。Claude APIスキルがDevRelチーム製であることも明かされ、ベストプラクティスをエージェントに蒸留する行為こそが最もレバレッジの効くDevRelだという見方も示された。

最後にOpus 5.5の使い方として、コスト効率と簡潔さが改善したため、以前はコストを気にして踏み込めなかった長いエージェント実行を再挑戦すべきだという助言があった。特にマルチエージェント構成は「extra good」で、役割を事前に与えるのではなくエージェント同士が役割を割り当て合う形が新しいとされた。1人のリード、並列化可能で共有コンテキストのあるタスク、非同期で非ブロッキングなサブエージェントという原則を守れば、大胆な実験をする価値があるという。

結びに

このエピソードが残すのは、フロンティアモデルの競争が「モデルの賢さ」だけでは語れなくなったという実感である。安全性のためのデータ保持ポリシー、蒸留対策、trust grantによる認可、脳と手の分離、CPUのキャパシティプランニング、Rustへの全面移植——どれも1年前には存在しなかった仕事であり、今やローンチ業務の大半を占める。KatelynとAngelaのやり取りからは、製品とエンジニアリングの境界が溶けつつある現場の空気と、確率論的にヘッジを積むことで結果的に汎用基盤が育つという組織学習のパターンが伝わってくる。IPOを控えたAnthropicの強さを、モデル性能ではなく「安全に速く出す仕組み」の側から理解できる回として、AIエンジニアにとって示唆が大きい。