claude.ai高速化の2週間 — 3,000件超の変更で表示を約3倍速くした手順

claude.aiの新規読み込みで入力できるまでの時間(p75)は、3,085msから550msへ縮みました。Anthropicが開発者ブログで明かした、2週間のスプリントの成果の一つです。対象はclaude.aiとClaudeデスクトップアプリで、13の計測値の幾何平均が約3.1倍の高速化でした。

この記事の関心は、速くなった結果より、速くした進め方にあります。人間が決めたのは目標、トレードオフ、変更の承認。ボトルネックの発見からベンチマーク作成、PR、デプロイ後の監視までは、Slackの各スレッドにいるClaudeが回しました。

claude.aiの何を、どれだけ速くしたのか

対象にしたのは、利用の95%を占める4つの行動です。アプリの起動、会話の開始、既存の会話の読み込み、メッセージの送信。Datadog MCPサーバー経由で利用データを分析させ、Claude自身に選ばせた4つです。Webとデスクトップ、製品ごとに分けると、13の計測値になりました。

計測はリアルタイムのユーザー監視(RUM)で、2026年8月13日と8月27日を比べています。値はいずれもp75です。

見出しの「3倍」は、この13行の幾何平均です。個々の幅は1.5倍から19倍まで開いています。デスクトップのコールドスタートは6.3秒から3.3秒で、1.9倍にとどまりました。体感の差は行動と製品によって大きく違うはずです。

ブログは、p95(遅い側の利用者)、ここで扱わなかった行動、非常に長い会話にはまだ改善の余地があると述べています。

3,000件超の変更を、事故ゼロで通せた理由

Anthropicは、マージした変更が3,000件を超えた一方で、顧客に見える障害もロールバックも出なかったと書いています。この数字を支えたのが安全策です。

安全策

高速化と並走した安全策

• 人のレビュー

  すべてのPRに自動レビューと、少なくとも1人の人間の承認を置きます。単体テストは最適化より先に書きます。

• 短命のフィーチャーフラグ

  利用者に見える変更は、短期間だけ使うフラグの裏に出します。期間中に導入したフラグは200近く、半数超が終了時までに片付きました。

• 段階的ロールアウト

  リスクの高い変更は、社員、利用者の1%、全員の順に広げます。

• CIの天井値

  速くなった結果を固定する計測を作り、数値が悪化したPRをCIで落とします。

フラグの管理もClaudeの仕事でした。Claudeがすべてのフラグを「キルスイッチ」か「段階展開用」に分類し、安全になった時点で順に撤去しています。

実機の計測は遅い。だから命令数で測った

最初の壁は反復の速度でした。本番の計測値が出るまでにはデプロイを待つ必要があり、Claudeが夜通し動いても、結果を確かめる手段がありません。

きっかけは、エンジニアのSamがスレッドに書いた問いです。実時間以外に測れるものはないか。Claudeの答えは、純粋なJavaScriptの経路なら、Valgrindとnode --predictableで命令数を数えるというものでした。ブラウザ側には命令数がないため、決定的に数えられる別の指標を挙げています。Reactのコミット回数、V8のコールカウント、レイアウトとスタイル再計算の回数、DOMの変更回数です。11分後には、5つのスレッドが走っていました。

ここで採用の条件が決まります。新しいベンチマークには2つの役目を課します。Claudeが動かせる指標であること。そしてCIで数値が下がる方向にしか動かない上限として働くこと。不安定なもの、実際のレイテンシと相関しないものは捨てました。

命令数が本当に実時間を代弁するのかは、Claudeに証明させています。

メッセージツリーでは、命令の4分の1がメガモーフィックな辞書参照でした。1時間で2つの経路を直し、それぞれの命令数に上限(ラチェット)を設けています。以後、命令数を増やすPRはCIで落ち、毎日のジョブが数値の下がった分だけ上限を引き下げます。

ブログはここから、この取り組みの中心的な教訓を引き出しています。

計測は以前、ステップ0だった。指標を足し、データが貯まるのを待ち、それから問題を理解する。Claudeがいると、計測はステップ1、つまり山登りの出発点になる。(ブログの趣旨を要約)

数値を一つ得れば、Claudeはその数値を下げにいけます。だから最も効くのは、測れるものを増やすことでした。

スレッド単位の山登りループ

作業は一つのSlackチャンネルで進みました。Claudeを呼び出す常設の指示が置かれ、複数のエンジニアが各スレッドに同時に入ります。ブログが描くループは次のとおりです。

手順

1スレッドの流れ

1. 1

   スレッドを立てる

   遅い場面を共有します。スクリーンショットや録画を添えることが多いようです。

2. 2

   再現とベンチマーク

   Claudeがフローを追跡し、遅さを示すベンチマークを探すか、自分で作ります。

3. 3

   PRを出す

   リスクとレビューのしやすさに合わせ、複数のPRに分けます。

4. 4

   フラグの裏でデプロイ

   デプロイ後はClaudeが実利用の数値を読みます。

5. 5

   結果で分岐

   速くなればベンチマークの上限を下げて固定し、ならなければフラグを切って作り直します。

実例が、サイドバーの項目が遅れて現れる問題です。画面録画で見つかったのですが、既存の監視では拾えませんでした。累積レイアウトシフト(CLS)は1回あたり約0.008で、良好とされる基準0.1を大きく下回るため、問題として現れませんでした。そこでIssacが、Layout Instability APIを直接使う案を出します。

Claudeは、シフトの発生源をサイドバーやトランスクリプトといった領域と、初回描画前や入力可能後といった局面に対応づけるイベントを作りました。サイドバーのデータを初回描画後まで止める結合テストも追加しています。mainでは20回中20回失敗し、修正PRでは20回中20回成功しました。このイベントを展開すると、Webのページ読み込みの31%が、ページが使える状態になったあとに何かが動いていたと分かります。遅れて届くヘッダー行、名前の読み込み後に横へずれるキャレット、スクロールバーの出現で動く一覧。原因を一つずつ名指しして、上位から直しています。

スプリント中は150本以上のスレッドが同時に動きました。1本のスレッドが50本、多いときは100本の最適化PRを出しています。Claude自身が新しいスレッドを立てる場面も増えました。

計測すれば何かが見つかる

ブログに並ぶ発見は、どれも測らなければ見えなかったものです。

発見

計測が掘り当てたもの

• 入力経路のフック

  Reactのフック集計で、入力経路に6,900のフックと900のストア購読があり、キー入力のたびに再描画されていました。

• CSSセレクタ

  スタイル再計算の集計で、1つの:root:has()セレクタがDOMの変更のたびに24msを足していました。

• 隠れた再読み込み

  初回描画後のコード経路を追うと、location.reload()の取り残しが1日50万回の隠れた再読み込みを起こしていました。

• IndexedDBへの複製

  アイドルのタブを調べ、同一のキャッシュスナップショットが毎分2回、メインスレッドでIndexedDBに複製されていると分かりました。

もっとも風変わりな原因は、em dashです。完成したコードブロックのハイライトで、ページが約1秒止まることがありました。返信のMarkdownにem dashや曲がった引用符のようなLatin-1の範囲外の文字が1つでもあると、V8は文字列全体をUTF-16で持ちます。するとハイライトの正規表現が、すべて2バイトの遅い経路を通ります。Claudeは、ハイライト前に各コードブロックを1バイト文字列へ複製する20行の変更で直しました。ページ最初のTypeScriptブロックのブロック時間は1.0秒から0.35秒に、同じブロックの2回目以降は100msから40msになっています(4 vCPUのコンテナ、ヘッドレスChrome、CPU制限なし、各値2〜3回の測定)。

静的コンポーザーを守る仕組み

起動を速くした施策の一つが静的コンポーザーです。HTMLに入力欄を焼き込み、React初期化の最中でも入力できるようにします。デスクトップでは、V8のコードキャッシュを事前コンパイルして、メインプロセスの再コンパイルを避けました。会話間でコンポーザーを載せたままにする、ホバーでセッションを先読みする、サイドバーの再描画を90%減らす、という施策も並びます。

静的コンポーザーは、設計上壊れやすい部品です。HTMLの複製を先に見せ、その上へReactが直接描画します。1ピクセルずれればこの仕掛けは台無しになります。Claudeが作った守りは数十個に及びます。

• 静的マークアップは、実物のReactコンポーネントをjsdomで描画して生成する。両者が乖離しないことをテストで保証する
• 14種類のビューポートで静的ページとReactの描画を比べ、ずれを1px以内に収める結合テストを走らせる
• キー入力が引き継ぎの瞬間に失われたり順序が入れ替わったりしないか、打鍵を通すテストを置く
• 実利用では、引き継ぎのたびにずれを0.1px単位で報告させ、動きがゼロでなければClaudeがスレッドを立てる

研究室では見つからない問題もありました。内部リリースの4時間後、同僚が画面録画を共有します。claude.aiを新しいタブで開くと、入力欄が15〜20px下がるというものでした。

Claudeの調査結果は、静的コンポーザーの引き継ぎではない、というものです。引き継ぎは、その同僚の49回の読み込みすべてで0pxでした。原因は、組織管理下のChromeが新規タブページの下に出す56pxのフッターです。ページ遷移でフッターが消えるとページは56px高くなりますが、それは初回描画の約100ms後です。/newは挨拶と入力欄を上から18%の位置に置くため、0.18×56で約10px下がり、録画の実測と合いました。「たまに起きる」のは、Chromeがアドレスバー入力中に先読みでページを描画しておくとき、初回描画がリサイズより先に終わる場合だけだからです。この潜在バグは以前からあり、ページがここまで早く描画されたことがなかっただけです。レイアウトテストが見逃すのも当然でした。ヘッドレスChromeには、引っ込むブラウザUIがないからです。Claudeがリサイズをまたいでレイアウトを固定し、チームは先読み描画の流れを再現するテストを足しました。

人間の仕事は何だったのか

ブログは、ループは生産的でも自律的ではなかったと言います。人間の役割は3つに分けられています。

役割

人間が担った3つの役割

• 野心

  Claudeは既定でスコープに慎重です。調査結果をチケット化し、実現性を留保し、見積もりに余裕を持たせます。ガードレールに自信があったので、早い段階から大胆になるよう促しました。目標に届くとスレッドが鈍るため、Samは「目標は終点ではない。次は何か」と各スレッドに書いて回っています。

• センス

  どのスレッドにも名前のある人間の担当者がいます。利用者に見える変更は、前後のスクリーンショットや録画で見せ、担当者が採否を決めます。表をセル単位で埋めるか、行がそろってから出すか。ローディングのスケルトンをすぐ出すか、0.5秒待つか。

• 方向づけ

  各スレッドは一つのベンチマークか行動に絞り、範囲外の改善は求めません。150本のスレッドは、釘を探す150本のハンマーです。900行のPRに「送信1回あたり2msでは、このビルドプラグインを保守する複雑さに見合わない」と一言で返した例も載っています。

8.33msの予算で、ストリーミングを120fpsに

脇道の一つが、ストリーミング表示の滑らかさです。リアルタイムのシンタックスハイライトで使う正規表現を最適化したとき、Claudeはその効果を示すため、長い返信が流れ込む様子の画面録画を添え、隅にフレームレートの表示を重ねました。Raymondが「60fpsで頭打ちか。120まで上げられるか」と問うと、Claudeはヘッドレスのリグが既定で60Hzで動くことを確認します。DevToolsのBeginFrame制御で、120Hzを決定的に刻む方法を見つけました。240フレームを送ると、ちょうど240フレームが返ります。1フレームが8.33msの予算に収まったかが、ばらつきのない値で読めるようになりました。

そこからClaudeは、返信を1フレームずつ進めて時間を測り、遅い箇所を洗い出します。完成したブロックをメモ化して、チャンクごとにメッセージ長に比例して走っていた処理をなくし、伸びるコードフェンスのトークン化をワーカーに移し、表をセル単位で表示しました。この1スレッドで入ったPRは約60本。長い返信がメインスレッドを塞ぐ時間は合計約750msから約200msへ減り、CPU使用量は約3分の1、120HzのMacBookでは最初から最後まで120fpsを保ちました。この120Hzのリグは、回帰を見張る夜間ジョブになっています。

数字の読み方と、残る問い

ここまでの数字は、Anthropic自身の計測です。読む側が押さえたい観点は3つです。

• 比較は8月13日と8月27日の2時点で、指標はp75。外部から再現できる条件ではありません
• 「約3倍」は幾何平均です。デスクトップのコールドスタートのように、改善が1.9倍にとどまる項目も含まれます
• 使ったのはClaude Tag(ベータ)と、Opus 5.5とおおむね同等の社内研究モデルです。一般に提供されている構成とは限りません。製品の位置づけはClaude TagとClaude Code in Slackの違いに、モデルの側はClaude Opus 5.5の解説にあります

編集上の見立てを一つ述べます。この事例から持ち帰れる部分は、モデルの賢さより、数値の下がる方向にしか動かないCIの上限という設計です。命令数のような決定的な指標なら、人が張りつかなくても、夜通し動くエージェントが自分の結果を判定できます。ただし、実時間との相関を先に証明するという手間を省けば、間違った丘を登らせます。ブログが相関を示せなかったベンチマークを捨てたと明記しているのは、この点でした。

自分の環境に持ち込むなら、材料はすでに公開されています。可観測性の入口はDatadog MCPをClaude Codeに接続する手順、ブラウザ側の計測はChrome DevTools MCPの使い方にまとめています。評価指標を固定して改善を繰り返す考え方は、claude-apiのhillclimbと過学習を避けるeval設計と同じ系統です。

まとめ

この2週間は、「速くする作業」を「測れるものを増やす作業」に置き換えた期間と読めます。レビュー、最適化より先に書く単体テスト、短命のフィーチャーフラグといった安全策を先に整え、段階的ロールアウトも併用していたので、1日200件を超える変更の日があっても、顧客に見える障害は報告されていません。増えたフラグはClaudeが分類し、安全になったものから片付けました。開発者ブログはElectron、Chromium、Node.jsなどへの上流貢献を別の記事で書くと予告しています。