Claude高速化の舞台裏、AnthropicがAIエージェントに測定目標を与えた2週間

Anthropicは、claude.aiとClaudeデスクトップアプリの主要な利用フローを2週間で約3倍高速化したと発表しました。同社が2026年9月23日に公開したエンジニアリング記事によると、エンジニアはSlackチャンネルを通じてパフォーマンス改善をClaudeに任せ、3,000件を超える変更をマージしましたが、顧客に影響する障害やロールバックは1件も起きませんでした。モデルの性能も重要ですが、より大きかったのは進め方です。チームはまず何を測るかを正確に決め、その数値をAIエージェント(複数の手順からなる作業を自ら計画して進めるAIシステム)に下げさせ、ガードレールは人間が握りました。

2週間の成績表

Anthropicは実際のユーザーセッションの75パーセンタイル値で結果を測定しました。対象は、アプリの起動、会話の開始、既存の会話の読み込み、メッセージの送信という4つの利用フローで、ユーザー活動全体の95%を占めます。

作業を担ったのは、Opus 5.5とほぼ同等の社内研究用モデルで動くSlackボット、Claude Tagです。チームは13の目標に対して2週間のスプリントを計画していましたが、3日目までにそのうち12を達成しました。

▲ エージェントによる性能改善のループ

第1段階:ユーザーが実際に感じる時間を測る

チームは専用のSlackチャンネルを作り、常設の指示を置きました。Claudeはclaude.aiとデスクトップアプリのパフォーマンス作業全般を担当し、デプロイ後の性能低下の監視、テレメトリーが正確かどうかの確認、ダッシュボードの管理、新しい施策の提案まで受け持ちました。Datadog MCPサーバー(MCPはツールやデータソースをAIモデルにつなぐための標準的な仕組み)を通じて利用データに接続したClaudeは、影響の大きい4つの利用フローを特定し、それらはWebとデスクトップをあわせて13の計測ポイントに広がりました。

重要だったのは、各計測をどこで始めてどこで終えるかという選択です。すべての計測ポイントはユーザーの操作から画面への最終的な描画までを対象とし、クライアント側の時間とサーバー側の時間を切り分けています。多くのチームは代わりに内部のコンポーネント更新を測っており、そのせいでダッシュボードには200msと表示される一方、実際のユーザーは8秒待たされるといったことが起こります。最適化をエージェントに任せる前提条件は、この計測を正しく整えることだといえそうです。

そのうえでチームは20のプロジェクトを選び、Claudeがそれぞれで何ミリ秒短縮できるかを予測しました。その見積もりを積み上げたものがスプリントの目標になりました。

第2段階:ぶれない数値をエージェントに渡す

実時間(ウォールクロック時間)はばらつきが大きく、コードを少しずつ改善していくエージェントの目標には向きません。Anthropicのあるエンジニアが代わりになる指標を尋ねると、Claudeはプロファイリングツールの「Valgrind」でJavaScriptの命令数を数え、Node.jsを予測可能モードで動かす方法を提案しました。リポジトリに登録した基準値と比べれば、その数値には統計的なノイズがまったくありません。

ブラウザーではこうした命令数の計測ができないため、Claudeは代わりに決定論的な代理指標を段階的に示しました。

• 操作1回あたりのReactのコミット数
• 精密カバレッジによるV8の関数呼び出し数
• レイアウトとスタイルの再計算回数
• DOMの変更回数

各ベンチマークには2つの役割がありました。実験段階では、Claudeが固定されたスコアに対して一歩ずつ改善を重ねる「山登り」の目標になります。継続的インテグレーション(CI)では、数値が下がる方向にしか動かせないチェック、つまりラチェットになりました。Claudeには、代理指標での改善が実時間の短縮につながったことを証明することも求められました。

実際にどうなったかは、2つのホットパスに表れています。

メッセージツリーの組み立てでは、命令の25%が、同じメッセージIDを3回別々に解決する遅い辞書検索に費やされていました。

エージェントが見つけたもの

作業のループは単純でした。エンジニアが遅いフローを画面録画で報告すると、Claudeがそれを再現するベンチマークを作り、機能フラグの背後でプルリクエストを出し、デプロイ後に実環境のデータを確認します。実際の数値が改善していればベンチマークの上限を引き締め、そうでなければフラグを切ってClaudeが再挑戦しました。

2週目には、チームはこれを横に広げて100を超えるClaudeのスレッドを走らせ、同時に最大50が動いていました。最初の作業を終えた後も新たな作業を見つけ続け、それぞれ50〜100件のプルリクエストを出したスレッドもありました。ピークの日には200件を超える変更が取り込まれました。Anthropicのあるエンジニアは、このモデルを「数字の鬼」と表現しています。

エージェントが掘り起こした問題には、次のようなものがありました。

• メッセージ入力欄では、キーを1回押すたびにReactのフック6,900個とストア購読900件が再実行されていました。
• ルートに置かれたCSSの「:has」セレクター1つが、DOMが変わるたびに24msのスタイル再計算を上乗せしていました。
• 消し忘れたページ再読み込みの呼び出しが、1日約50万回の目に見えないページ全体の再読み込みを引き起こしていました。
• バックグラウンドのタブが、同じキャッシュのスナップショットをブラウザー内蔵のデータベースであるIndexedDBへ、メインスレッド上で1分に2回複製していました。
• Markdown内のエムダッシュや曲がった引用符のせいでChromeのV8エンジンが文字列を遅い2バイト形式で保持し、シンタックスハイライト用の正規表現がすべて遅い経路で実行され、ページが約1秒固まっていました。ハイライトの前にコードブロックを1バイト文字列へコピーする20行の変更で解消しました。

起動の高速化は具体的な変更から生まれました。静的なメッセージ入力欄を最初のHTMLに組み込み、Reactの読み込みが終わる前から入力を始められるようにしました。デスクトップアプリはプリコンパイル済みのV8コードキャッシュを同梱するようになり、起動時にスクリプトを一から解析・コンパイルしなくなりました。会話を切り替えても入力欄はマウントされたままとなり、サイドバーにポインターを重ねると会話を先読みするようにしたことで、サイドバーの再レンダリングは90%減りました。

これとは別の取り組みでは、8.33msのフレーム予算を目標にしました。これは毎秒120フレームのときに1フレームあたり使える時間です。ClaudeはヘッドレスのChromiumを、ちょうどその間隔で240フレーム進めるように設定し、長い返答を1フレームずつ確認しました。完成したテキストブロックのメモ化と、伸びていくコードブロックのトークン化のWeb Workerへの移動によって、長い返答中のメインスレッドのブロック時間は750ms超から約200msに減り、CPU使用量は3分の2減りました。この1つのスレッドだけで60件近いプルリクエストが取り込まれました。

人間が主導権を握った部分

スピードにはガードレールが伴いました。すべてのプルリクエストには自動のCIチェックと最低1人の人間による承認が必要でした。リスクのある変更は短期間だけ使う機能フラグの背後で出荷され、その数は2週間で200近くに上りましたが、変更の安定が確認されるたびに削除されました。静的な入力欄は14種類のビューポートサイズでテストし、React版と1ピクセル以内で一致することを確かめ、さらに切り替えの瞬間をまたいで入力を続けるテストで、キー入力の取りこぼしがないかを確認しました。

それでもテストは見落としました。静的な入力欄を社内に公開して4時間後、ある社員がページが跳ねる様子を録画して送ってきました。原因は、企業管理下のChromeプロファイルで新しいタブのページに表示される56ピクセルの管理用フッターでした。Chromeはアドレスの入力中にページを先行レンダリングしますが、そのサイズは新しいタブのページに合わせたものです。約100ms後にフッターが消えるとページのサイズが変わり、下端に固定せず上からの割合で位置を決めていた入力欄が動いてしまいました。

方向づけも人間の役割でした。Claudeは初期設定のままだと作業範囲を狭く取り、所要時間を多めに見積もりがちでした。基礎となるテレメトリーに数日かかる計画を示したとき、あるエンジニアがもっと大胆にやるよう伝えると、見積もりは1時間未満に下がりました。初期の目標を達成した後は、より大胆な提案を引き出すために「突飛なアイデア」を明確に求めました。逆に、メッセージ送信1回あたり2msを削る900行のプルリクエストは、独自のビルドプラグインを保守し続けることになるため、レビューで却下されました。チームは150のスレッドを、それぞれ1つのベンチマークか1つの利用フローに絞り込んで運用しました。

感覚的な判断も人間に委ねられました。各スレッドには人間の担当者がつき、Claudeはユーザーの目に見える変化を前後比較の録画やスクリーンショットで示しました。表をセル単位でストリーミングするか行がそろうまで待つか、スケルトン表示をいつ出すか、単語ごとのフェードにフレーム予算の20%を使う価値があるかは、指標ではなく判断の問題です。

▲ サーバーとずれたサイドバーのキャッシュ

指標では見えない穴

高速化したclaude.aiを実際に使ってみると、その速さには代償があることがうかがえます。プロンプトを送ってすぐに再読み込みすると、新しい会話がサイドバーから消えてしまうことがあります。別のウィンドウで削除した会話がキャッシュされた項目としてサイドバーに残り続け、クリックするとそのセッションはもう利用できないというエラーが返ります。サイドバーはローカルのIndexedDBキャッシュから即座に描画されるようになりましたが、サーバーとの再検証は確実には行われていないように見えます。代替策の一つは、サーバーが確認するまでキャッシュされたデータを薄く表示することです。

より広い教訓は、背景を知らずに代理指標を追うエージェントは、単体ではスコアが良くなるという理由で、先読みやキャッシュといった有用な処理を止めてしまうかもしれないという点です。厳しすぎるレイアウトテストにも同じリスクがあります。キャッシュに4件あり、サーバーが5件を返した場合、リストが下にずれるのは正しい動作であってバグではありません。ユーザーが小さなカクつきや同期の遅れを報告することはめったにないため、エンジニア自身が製品を試すことは今も欠かせません。

自分の仕事に生かすには

最もはっきりした教訓は、具体的な計測値をエージェントに与えれば、終わりの見えない最適化の課題が解ける課題に変わるということです。パフォーマンス作業をコーディングエージェントに任せる予定があるなら、今回うまくいった次の順序が参考になります。

1. 主要な利用フローごとに、ユーザーの操作から最終的な描画までを計測し、クライアントとサーバーの時間を切り分けます。
2. 生の時間ではなく、命令数やReactのコミット数のような決定論的な目標をエージェントに与えます。
3. 代理指標の改善が実際の高速化に表れることを確認してから、CIのラチェットで固定します。
4. リスクのある変更は機能フラグの背後で出荷し、すべてのプルリクエストに人間の承認を必須にします。
5. もっと大きく考えるべき場面ではエージェントにそう明確に伝え、わずかな改善しか生まない複雑な変更は却下します。
6. どの指標にも記録されない同期の問題や表示のカクつきは、自分で製品を使って見つけます。