claude.aiを2週間で3倍速くした話を深掘る
- How we made claude.ai 3x faster in two weeks（claude.dev, 2026-09-23）
- Anthropicが2週間のスプリントで、claude.ai／デスクトップアプリの主要操作を平均約3倍高速化した（例：初回ロードp75 3.1秒→0.55秒）
- 実装の大半はSlack常駐のClaude（Claude Tag）が担当し、人間は目標設定、トレードオフ判断、承認に専念した
- 3,000件超の変更を、顧客影響のあるインシデントもロールバックもなしでマージした
| 項目 | 内容 |
|---|---|
| 対象 | 利用の95%を占める4操作（起動／会話開始／会話読込／送信）× プラットフォームで13指標 |
| 中心の教訓 | 測れれば登れる（With Claude, measuring something makes it tractable） |
| 手法 | 決定的な代理指標（命令数など）でラボ改善 → CIでラチェット化 |
| ループ | スレッド起票 → ベンチ作成 → PR（フラグ付き）→ デプロイ監視 → 良ければラチェット／ダメならフラグOFF → 次の遅い箇所へ |
| 規模 | 最大150スレッド並列、多い日は1日200件超の変更 |
| 人間の役割 | 野心、センス、方向づけ |
① 「測れれば登れる」の素材はどこから来たか
Section titled “① 「測れれば登れる」の素材はどこから来たか”測るための素材集めが難しいはず。実際どうやったのか？
分かったこと
Section titled “分かったこと”新しく集めたというより、もともと存在するのに誰も数えていなかった信号を掘り起こした。 入手経路は3つある。
- 既存データの棚卸し：Datadogの利用データから重要ジャーニーを特定し、計測の起点（ユーザー操作）と終点（描画完了）を揃え、クライアント処理とサーバー処理を分けた
- ランタイムが持つ決定的カウンタ：CPU命令数（Valgrind）、V8の呼び出し数、Reactのコミット数、スタイル再計算数、DOM変更数
- 人間の違和感を計測器に翻訳：
- サイドバーのガタつき録画 → 既存指標（CLS）では閾値内でスルー → Layout Instability APIの生データを領域ごとに紐付け → ページロードの31%で発生していたと判明
- 「60fps上限？」の一言 → 120Hzで決定的にコマ送りできる計測台を構築
実際にやる時の論点
Section titled “実際にやる時の論点”「そもそも何が測れる信号なのか」の棚卸しから始める必要がある。 記事でも、Samの「wall-clock以外に何が測れる？」にClaudeが信号の梯子を列挙して答えていた。 棚卸し自体をAIに投げられる。 人間は問いの粒度を用意すればいい。
棚卸しの2軸：
- レイヤー：体感（表示時間、ジャンク、fps）／アプリ（レンダー回数、APIコール数、クエリ数）／ランタイム（呼び出し数、GC、メモリ確保）／OSとHW（命令数、I/O、syscall）
- 性質：決定的（CIゲートやラチェット向き）／ノイズあり（フィールド計測や最終確認向き）
AIと「測れるもの」を棚卸しし、各指標が体感とどう絡むかを一覧化していく。
この一覧は生きた表で、行ごとに「この指標を下げるとこの体感が良くなる」という仮説になっている。
- 増える：既存指標に引っかからない違和感から新しい行が生まれる。 計測が問題を見つけ、さらに計測を生む（PRの約1/3がテレメトリやガードの追加）
- 減る：体感との相関を証明できない指標は捨てる
計測器を作るコストがほぼゼロになったことが、「測れるものを増やす」戦略を成立させた。
② 代理指標は体感とどこまで一致すればいいか
Section titled “② 代理指標は体感とどこまで一致すればいいか”引っかかった点
Section titled “引っかかった点”命令数48%減 → 実時間78%減、31%減 → 44%減と、率が一致していない。
どちらも割合で、命令数と実時間は相関はしても一致はしない。 減った方向が同じならいいのでは？
分かったこと
Section titled “分かったこと”指標の使い道で必要条件が変わる。
| 使い道 | 必要な条件 | 理由 |
|---|---|---|
| 守り（CIガードレール／ラチェット） | 方向の一致で十分 | 役割は悪化の検知だけ |
| 攻め（登る目標） | 方向の一致だけでは危ない | 下記2点 |
攻めで方向だけだと危ない理由：
- 大きさが分からないと努力配分を誤る：命令数50%減で実時間1%減の指標を登るのは無駄（グッドハート化）
- 方向が逆転し得る：命令1個のコストは一定ではない。 記事で削られたのは重いメガモーフィックな辞書引きだったから効果が大きかった。 逆に「計算をキャッシュ参照に置き換える」と、命令数は減るのにメモリアクセスで実時間が増えることもある
記事の対処は、相関の証明を2例で済ませ、毎デプロイ後にフィールドの実時間を読むことを必須にするものだった。 ラボ指標はあくまで代理で、正解は常にフィールドにある。 相関は一度きりのお墨付きではなく、毎回検証される仮説として扱われた。
守りは方向一致でOK。 攻めは方向一致を入口に、フィールド実時間で毎回答え合わせ。
③ 人間の役割はどう移ったか（PM視点）
Section titled “③ 人間の役割はどう移ったか（PM視点）”記事での人間の役割
Section titled “記事での人間の役割”- 野心：Claudeは放っておくと慎重（チケット化する、実現性をぼかす、見積もりを盛る）。 「今PRを出せば今日マージする。もっと大胆に」「目標は止まる地点じゃない」と押す
- センス：体感に関わる変更はbefore/after録画で人間が判断。 各スレッドに名前付きの人間オーナーを置く
- 方向づけ：スコープを狭く保つ、順番決め、スレッドの統合、収穫逓減での打ち切り。 900行PRを「2msのためにこのビルドプラグインを保守する価値はない」と一言で却下
自分の見立て
Section titled “自分の見立て”- 野心はAIだからこそできる。 人間相手なら信頼関係を作ってからでないとここまで言えない。 AI相手なら関係コストがゼロで、失敗してもガードレールで拾えるので押すリスクも低い（二重に安く押せる）
- センスと方向づけは、エンジニアならできる
- PMの仕事の向きが逆転している：人間チームではキャパや燃え尽きを見てブレーキ役になりがち → ここでは実行側キャパが実質無限かつ慎重すぎるのでアクセル役。 ブレーキはガードレールが機械的に担う
1日200件の承認をどうさばいたか
Section titled “1日200件の承認をどうさばいたか”最初の想像：一件ずつ見ていたら時間が足りない。 Claudeと良し悪しを壁打ちしながら判断するのでは？
記事から読み取れるのは「速く見る」より「1件あたりの判断を軽くする」工夫である。
- PRの形を判断しやすく：Claudeが1改善を複数PRに分割し、リスクとレビュー容易性でサイズ調整
- AIが先にふるう：全PRに自動コードレビュー＋人間の承認最低1つ
- 判断点だけを浮かせる：体感変更にはbefore/after録画
- 間違えても安い：フラグの裏に置き、ダメならOFF
- 人数で割る：10人前後で、スレッドごとにオーナー
（推測）リスクに応じてレビューの深さを変えていたはず。 ラチェット付き内部最適化は軽く、フラグ付きUI変更は録画で、ビルド基盤への変更は重く。
承認の帯域問題は「人間が頑張る」ではなく、事故のコストを下げ、判断の粒度を小さくすることで解く。 見る粒度を細かくするのはリスク管理の定番で、AI活用でも同じ手が効く。
④ ガードレールはどう設計されていたか
Section titled “④ ガードレールはどう設計されていたか”4層構造（スイスチーズモデル）
Section titled “4層構造（スイスチーズモデル）”- 変更の入口：自動レビュー＋人間承認／最適化前にユニットテスト／ユーザーに見える変更は短命フラグの裏
- 勝ちを守る：
- ラチェット（指標を上げるPRはCIで落ちる、改善すれば毎日上限を下げる）
- 壊れやすい改善（静的コンポーザー）には専用ガードを多重に：本物のReactからjsdomで静的HTMLを生成しドリフト検知／14画面サイズで1px以内／切り替え中のキー欠落と順序入れ替わりのテスト／フィールドで0.1px単位のズレを報告し非ゼロならClaudeがスレッドを立てる
- ラボで捕まらないものを捕まえる：段階リリース（社員 → 1% → 全員）。 社内リリース4時間後に、Chromeのプリレンダー起因のレイアウトずれが社員の録画で発覚。 ヘッドレスChromeにはブラウザUIがなく原理的にラボ再現不可だった
- ガードレール自体の負債管理：約200個のフラグをClaudeが「キルスイッチ」と「段階展開用」に分類し、安全になり次第撤去（期間中に半数以上）
ガードレールは2種類
Section titled “ガードレールは2種類”- 方針（人間が最初に宣言）：レビュー必須、テスト先行、フラグ、段階リリース。 汎用的で、作るというよりルール化するもの
- 個別装置（Claudeが勝ちごとに追加）：ラチェット、1pxテストなど。 走りながら肉付けする
速度と安全が別々ではなく一緒にスケールしていた（ガードの多くをClaude自身が作った）。
取り返しのつかない事態を安全側に倒せる構えを先に作っておけば、Claudeに大胆に動いてもらえるので、結果として速くなる。 骨格は人間が先に決め、肉付けはClaudeと走りながら作る。
横断的なつながり
Section titled “横断的なつながり”- 決定的な出力はモデルではなくスクリプトへ ↔ ノイズの多い実時間ではなく、決定的な命令数をCIゲートにする。 前者は、同じ入力に毎回同じ結果が要る処理（集計、判定、変換など）を、出力が揺らぐモデルに生成させずスクリプトに任せるという原則である。 CIゲートは毎回同じ判定を返さないと誤検知で止まるので、実時間ではなく命令数を使うのは、この原則の性能版にあたる
- エージェントのサンドボックス化（devcontainer） ↔ ガードレール設計。 どちらも「被害範囲の限定」と「可逆性」で、AIに大胆に動いてもらう前提を作る
- 判断品質と被害範囲は別問題 ↔ センスと方向づけ（判断品質）は人間、フラグと段階リリース（被害範囲）は仕組み、と分担されていた