9月23日、claude.devが「How we made claude.ai 3x faster in two weeks / claude.dev」と題した記事を公開した。AnthropicのチームがSlackチャンネル1つを司令塔に、2週間のスプリントでclaude.aiとClaude desktop appのパフォーマンスを劇的に改善した経緯と、その技術的構造が詳述されている。
「測定できれば、攻略できる」——Claudeが3,000件のPRを自律的に回した2週間
今年8月、AnthropicのチームはSlackチャンネル1つを司令塔に、2週間でclaude.aiとClaude desktop appのパフォーマンスを劇的に改善した。
数字で見ると：
- 新規ページロードのTime to Typeable（操作可能になるまでの時間）：3.1秒 → 0.55秒（75パーセンタイル）
- Claude Code新規セッション開始：0.8秒 → 0.3秒
- Claude Coworkクラウドセッション読み込み：2.6秒 → 0.73秒
これだけの改善が、ユーザー起因のインシデントもロールバックもゼロで実現された。マージされたPRは3,000件超。どうやって安全に回したか、その構造こそがこの記事の核心だ。
ループの設計：Claudeを何百スレッドで同時に走らせる
チームはSlackの #claude-apps-perf チャンネルにスタンディングインストラクション（常時有効な指示）を設定し、Claude Tagを常駐させた。Claude TagはAnthropicが提供するSlack向けのClaude連携機能で、記事公開時点ではOpus 5.5相当のモデルが使用されている。スタンディングインストラクションはClaude Tagの機能の一つで、チャンネルやスレッドにClaude向けの常設指示を埋め込める仕組みだ。
スプリント中のループはこうだった：
- エンジニアが「このUIの動きが遅い」という画面録画や気づきをスレッドに投稿
- Claudeがフローをトレースし、問題を再現するベンチマークを構築
- ラボで改善を確認したらPRを提出（リスクに応じてサイズ分割、UIへの影響がある変更はフィーチャーフラグの裏に隠す）
- デプロイ後、Claudeがフィールドデータを監視
- 改善が確認されればベンチマークの上限値を引き下げ（ラチェット）、効果がなければフラグをオフにして再試行
- 同じジャーニーの次のボトルネックを探す
スレッドは最盛期で150本以上が同時進行。1スレッドあたり50〜100件のPRが積み上がることもあった。スプリント後半はClaude自身が新しいスレッドを開いて調査を始めるようになり、エンジニアのShelleyは「こいつは数字の悪魔だ」と表現したという。
最も面白い発見：「測定できれば攻略できる」の実証
記事が強調するのは、Claudeとの開発における認識論的な変化だ。
With Claude, measuring something makes it tractable.
従来、パフォーマンス最適化では「メトリクスを追加 → データが溜まるのを待つ → 問題の理解を始める」という順序だった。Claudeがいれば、測定はステップゼロではなくステップ1の登山開始になる。数字さえあればClaudeはすぐに最適化を始められるため、チームの最大のレバレッジは「何を測るかを見つけること」に変わった。
具体例1：Valgrind + --predictable による命令カウントベンチマーク
ウォールクロック時間（実経過時間）はノイズが多くCIのゲートとして使えない。そこでチームはNode.jsを--predictableオプションで動かし、Valgrindで命令数を計測する決定論的ベンチマークを導入した。
Claudeがこのベンチマークを使って2つのホットパスを調べたところ：
- 会話のメッセージツリーを構築するルーティンで、命令の1/4が「同じメッセージIDを3回解決するメガモーフィックな辞書ルックアップ」に費やされていた
- 命令数を48%・31%削減したところ、ウォールクロック時間は78%・44%削減
相関が確認できたため、このベンチマークをCIのラチェットとして組み込んだ。以降、これらのパスの命令数が増えるPRはCIで自動的に弾かれる。
具体例2：サイドバーのジャンク（レイアウトシフト）
ユーザーが「サイドバーの行が後から飛び込んでくる」と報告。Cumulative Layout Shift（CLS）スコアは0.008と問題なしの範囲（閾値0.1）だったが、見た目には明らかに不快だった。
エンジニアのIsaacがLayout Instability APIを直接参照するアイデアを出し、Claudeがサイドバー・トランスクリプトなど領域ごとにシフト発生源をマッピングするテレメトリを実装。統合テストで「first paint後に既存領域でシフトが起きたらテスト失敗」という自動ガードレールを作った。
フィールドデータを読み込んだClaudeが発見したのは、Webページロードの31%でユーザー操作なしにレイアウトシフトが発生していたという事実だった。原因を名前付きで特定し（「ユーザー名が遅れて読み込まれるとキャレットが横にずれる」等）、バッチで修正。修正が完了すると次のバッチを探す、という動作を自律的に繰り返した。
具体例3：エムダッシュが1秒のフリーズを引き起こしていた
コードブロックのシンタックスハイライト時に約1秒の固まりが発生するケースをCPUヒッチのスイープ中に発見。原因はエムダッシュや波括弧クォートなどLatin-1外の文字が1文字でもあると、V8がstring全体をUTF-16として格納し、シンタックスハイライトの正規表現がすべて低速の2バイトパスを通るというものだった。
修正はコードブロックをハイライト前に1バイト文字列にコピーする20行の変更だった。
3,000件のPRを安全に回したガードレール
- すべてのPRに自動レビュー＋最低1名の人間によるApproval
- ユニットテストは最適化コードより必ず先に
- UIへの影響があるものはショートライブドなフィーチャーフラグの裏に
- ロールアウトは社内 → 1% → 全ユーザーの段階的展開
- ベンチマークは「ラチェット式」——一度下げたら上げられない
フィーチャーフラグはスプリント中に約200本導入し、2週間の終わりには半数以上がすでに削除されていた。
Static Composer（ページをHTMLとして即座に表示し、Reactがその上にマウントする手法）では、「Reactレンダリングが1ピクセルでもズレたら体験が壊れる」という要件から、14種類のビューポートサイズでの整合テスト、1px以内のアライメント確認、キーストロークが引き継ぎをまたいで欠損・並び替えなしに届くことの確認など、十数個のガードレールをClaudeが構築した。
まとめ
このスプリントが示したのは、LLMエージェントが「測定 → 最適化 → 監視 → 次の測定」という繰り返しループを自律的にスケールさせられるという実証だ。エンジニアの役割は「何を測るか」「どのトレードオフを選ぶか」「変更を承認するか」の意思決定に集中し、Claudeが並列に数百スレッドを駆動した。
※編集部の考察：日本の開発現場への示唆として注目したいのは、ガードレール設計の緻密さだ。「人間のApprovalなしにマージしない」「UIへの影響はフィーチャーフラグで隔離する」「ラチェット式ベンチマークで退行を機械的に防ぐ」という構造は、AIエージェントの並列活用を検討するチームが参照できる具体的なプラクティスとなっている。AIが自律的に動く範囲を広げるほど、人間が担う「承認・測定設計・トレードオフ判断」の質が問われるという構図は、今後のAI活用を考えるうえで示唆に富む。
詳細はHow we made claude.ai 3x faster in two weeks / claude.devを参照していただきたい。
