Anthropicの新しいエンジニアリング記事で最も他社が持ち帰れるのは、claude.aiが2週間で約3倍速くなったという事実ではない。チームが残していった仕掛けのほうだ。CPU命令数を基準とするCIゲートで、数値は下方向にしか動かせない。これによって今後のプルリクエストはすべて性能テストになる。
要点
- 75パーセンタイルで、claude.aiの新規読み込みが入力可能な画面に達するまでの時間は3.1秒から0.55秒に短縮。Claude Codeの新規セッションは0.8秒から0.3秒になった。
- 2週間で3000件を超える変更がマージされ、顧客に影響した障害もロールバックもなかった。
- ホットパス2か所で命令数が48%と31%減り、実時間ではそれぞれ78%と44%の短縮につながった。計測時間ではなく命令数でCIを止めるという判断を支えた根拠だ。
なぜストップウォッチではなく命令数なのか
ユーザーが体感するのはレイテンシだが、ミリ秒の測定値はばらつきが大きく、ビルドを失敗させる根拠にはならない。Anthropicが取った回避策は、代表性のある数値ではなく決定論的な数値を探し、それが実際のレイテンシと連動することを証明してから信用するというものだった。
その証明は、会話のメッセージツリーを組み立てるルーチンで行われた。Valgrindでプロファイルすると、命令の4分の1がメガモーフィックな辞書参照で、同じメッセージIDを3度も別々に解決していた。この箇所とClaude Code出力のステータス行スキャナを直したところ、命令数は48%と31%減少。同じ経路の実時間は78%と44%減った。そこで初めて命令数はCIの恒久的な上限となり、上限を下回るビルドが出るたびに夜間ジョブが上限を引き下げる。
この運用を支える規律は、仕組みそのものと同じくらい重要だった。不安定と判明したベンチマークや、ユーザーのレイテンシと無関係に動くベンチマークは、許容せず削除した。そうしなければモデルは誰も望まない丘を登ってしまう。Reactのコミット回数、V8カバレッジの呼び出し回数、スタイル再計算、DOM変更も同じ審査を通った。
3倍という数字の基準
範囲は何かを出す前に決めた。ClaudeはDatadogのMCPサーバー経由で利用テレメトリを読み、全体の活動の95%を占める4つの動線を選び出した。アプリの起動、新規会話の開始、既存会話を開く、メッセージの送信である。これがウェブとデスクトップにまたがる13の計測指標になり、各指標はユーザー操作で始まりレンダリングで終わる区間として定義された。
13の目標のうち12は3日目までに達成された。手段は地味だ。React初期化中でも入力できるようHTMLに静的な入力欄を埋め込み、デスクトップ用シェルが再コンパイルを省けるようV8コードキャッシュを事前生成した。会話を切り替えても入力欄はマウントしたままにし、ホバー時にセッションを先読みし、サイドバーの再レンダリングを90%削減した。Anthropicはこうして削減した待ち時間を1日あたり数万ユーザー時間と見積もる。
数えて初めて見えたバグ
その後に出てきた一覧は、性能改善のバックログというより、どのダッシュボードも見ていなかったものの監査に近い。フックを全数調査すると、キー入力のたびに入力欄を再レンダリングするフックが6900個見つかった。:root:has()セレクタ1つが、あらゆるDOM変更に24ミリ秒を課していた。忘れ去られたlocation.reload()が、どの読み込み指標にも現れないまま1日50万回発火していた。同一のキャッシュスナップショットが、メインスレッド上で毎分2回IndexedDBに複製されていた。
最も奇妙だったのは、完成したコードブロックで1秒ほど固まる現象で、原因はemダッシュだった。Latin-1以外の文字が1つ混じるだけでV8は文字列全体をUTF-16で保持し、構文ハイライトの正規表現がすべて遅い2バイト経路に落ちる。ブロックを先に1バイト文字列へコピーする20行のコードで、症状は消えた。
レイアウトシフトがこの点を最も端的に示す。サイドバーが1回跳ねるたびのCumulative Layout Shiftは約0.008で、ページを「良好」と判定する0.1のしきい値を大きく下回っていた。標準指標では何も問題がないということだ。代わりにLayout Instability APIの生データを読み、画面領域ごとにシフトを分類すると、ウェブ読み込みの31%で、ページがすでに操作可能になった後に何かが動いていた。
より難しい数字はロールバック0件のほうだ
2週間でマージ3000件はスループットの主張である。ファーストペイントや入力欄のように露出の大きいホットパスで障害もロールバックもなかったというのはプロセスの主張であり、真似する価値があるのはこちらだ。
個々の仕組みは平凡だった。すべてのプルリクエストに自動レビューと最低1人の人間による承認を課し、最適化が守る対象のユニットテストを先に書いた。ユーザーに見える変更は短命のフラグの裏に置き、社員、ユーザーの1%、全体という順で段階的に展開した。平凡でなかったのは量だ。フラグを200個近く立て、その半数以上を2週間のうちに撤去。全プルリクエストのおよそ3分の1は修正ではなく新しいテレメトリやガードレールを含んでいた。計測は後追いのチケットではなく、変更の一部として扱われた。
なぜ重要なのか
計測はこれまでゼロ段階だった。指標を出し、データが溜まるのを待ち、それから問題を理解し始める。渡された数値なら何でも最適化するエージェントを前にすると、計測は登り始めの第1段階になる。そして希少になる資源は、そもそも何に数値を付けるかを決める判断へと移る。83万行規模のRust書き直しや、エージェントにコードを書かせつつデプロイ権限は人間が握ったPerplexityなど、エージェント主体の他のエンジニアリング事例にも同じ逆転が見える。
Anthropic自身は誇張を避けている。同社の記事は、このループが生産的ではあったが自律的ではなかったと明記する。目標、トレードオフ、承認は人間の側に残り、モデルが既定よりも範囲を大きく取るよう促し続けることが常設の課題だった。これをテンプレートとして読む組織にとって居心地の悪い含意は、ボトルネックがレビュー能力と「何を測るか」を選ぶ目利きに移るという点だ。どちらもエージェントを増やしても増えない。
FAQ — よくある質問
この集中作戦はどのモデルが実行したのか
Anthropicによれば、ベータ版のClaude Tagを使い、その上でOpus 5.5とおおむね同等と説明する社内の研究用モデルを動かした。作業は専用ツールではなく、共有のSlackチャンネル1つで調整された。
変更は人間がレビューしたのか
している。すべてのプルリクエストが自動レビューを通り、最低1人の人間による承認を必要とした。ユーザーに見える変更は機能フラグの裏で、社員、ユーザーの1%、全体という順に段階的に展開された。
社内モデルがないチームでも真似できるのか
仕組み自体はモデルを選ばない。決定論的な指標がレイテンシと相関することを示し、CIでその値を締め上げていけばよい。真似できないのはスループットのほうだ。2週間でマージ3000件は、多くのチームがまず構築しなければならないレビュー能力と計測を前提としている。
