Anthropic は 2 週間で claude.ai とデスクトップアプリを平均 3.1 倍速くし、3,000 件超の変更で顧客影響の障害は 0 件だった
- 数えられるものは速くできた。CPU 命令数や再計算の回数など、実行ごとにぶれない数を指標にしたことで、Claude が自分で直せる対象が増えた。
- 改善ループを Slack のスレッドごとに回し、150 本以上を並走させた。計測、PR、フラグ付き出荷、実測と進み、速くなった値を CI の合格ラインにして後戻りを防ぐ。
- 速さを守る安全装置を先に作った。人の承認・テスト先行・約 200 本のフラグ・段階公開で、顧客に影響する障害とロールバックは 0 件。
20 件の計画で始め、3 日目には 13 目標中 12 を達成した
使ったのは Slack で動く Claude Tag (ベータ) で、中身は Opus 5.5 とほぼ同等の社内研究モデルだ。チャンネルには常設の指示を置いた。役割は性能の監視、計測の点検、ダッシュボードの整備、改善の実装と提案、人への報告。指示文には、最終目標は Claude の自律だが今はまだ無理だとも書いた。
Claude が Datadog の MCP サーバー経由で利用データを分析し、起動・会話の開始・既存会話の読み込み・送信の 4 操作を選んだ。この 4 つで利用の 95% を占める。Web とデスクトップ、製品ごとに分けると 13 計測になる。計測の形もそろえた。どれも操作で始まり、描画で終わり、クライアントとサーバーの時間を分けて測る。
計画は約 20 件。Claude が各施策の効果をミリ秒で見積もり、合算して目標にした。計画した施策は予定より早く入り、3 日目に 13 目標中 12 を達成した (主な 5 件は表 1)。達成後、人は「まだ試していないことは何か。突飛な案も歓迎」と問い、Claude の提案で目標を引き上げた。
| 施策 | 記事の分類 | 中身 |
|---|---|---|
| 静的な入力欄 | 起動を速く | 入力欄を HTML に焼き込み、React の初期化中も打てるようにする |
| V8 コードキャッシュの事前コンパイル | 起動を速く | デスクトップ版のメインプロセスが毎回ゼロからコンパイルしないようにする |
| 入力欄をマウントしたまま保つ | 画面遷移を速く | 会話を移っても入力欄を作り直さない |
| ホバー時の先読み | 画面遷移を速く | マウスを乗せた時点でその会話のデータを取りに行く |
| サイドバーの再描画削減 | 画面遷移を速く | サイドバーの再レンダリングを 90% 減らす |
実時間の代わりに CPU 命令数を数え、実時間を最大 78% 縮めた
Claude は夜通しでも自分で作業を続けられる。本番の計測を待っていては遅いので、手元の実験だけで測れる指標を探した。著者の Sam が「実時間の代わりに JS の命令数を測れないか」と聞いた。Claude は、命令数を数えるツール Valgrind なら 1 回の実行で値が決まると答えた (図 3 ①)。11 分後には 5 本のスレッドが並走していた (③)。
ブラウザ側の案は、React が画面に反映した回数 (コミット数) や DOM 変更数を数えることだ (②)。各ベンチには 2 つの役目を持たせた。実験で Claude が下げる指標と、CI の関門だ。CI は数値を悪化させる PR を落とし、合格ラインは改善したときだけ下げる。記事はこれを「ラチェット」と呼ぶ。実時間はぶれが大きく、CI の合否に使えないからだ。
人は「実時間の改善につながると証明せよ。できないベンチは外す」と指示した。試したのはメッセージツリーの組み立てと、ステータス行の走査だ。前者では命令の 4 分の 1 が、同じメッセージ ID を 3 回引き直す辞書参照だった。1 時間後、前者は命令 −48%・実時間 −78%、後者は命令 −31%・実時間 −44% になった (④⑤)。
Slack スレッド 1 本で改善ループを回し、同時に 150 本以上を走らせた
流れは図 4 の通りだ。誰かが遅い箇所を、多くは画面写真か録画を付けてスレッドに投げる。Claude が再現ベンチを作り、リスクとレビュー量で小分けした PR を出す。見た目が変わるものはフラグの裏に置く。出荷後は実ユーザーの数値を読み、速くなればベンチの上限を下げ、変わらなければフラグを切ってやり直す。
例はサイドバーのガタつきだ。Chat と Cowork の行が別々の時刻に現れていた。CLS は 1 回あたり 0.008 で、良好とされる 0.1 を大きく下回り、監視では見つからなかった。著者の Issac の案で、ブラウザがずれを報告する Layout Instability API を直接使った。ずれを「どの領域で、読み込みのどの段階か」でラベル付けして記録した。
スレッドは閉じずに続き、1 本で 50〜100 本の PR を出した。やがて Claude 自身が夜間ジョブなどからスレッドを立て、並走は 150 本を超えた。2 週目には多い日で 200 件超の変更が入り、日次報告に収まらなくなった。エンジニアの Shelley は「このモデルは数字の鬼だ」と評した。安全装置と Claude 用の手順書 (skill) がそろい、新しい開発も最初から速い書き方になった。
| 見つけたもの | 数字 | 見つけ方 |
|---|---|---|
| サイドバーのずれ | データを初回描画後まで止めて開くテストは、修正前 20 回中 20 回失敗、修正後 20 回とも成功 | ずれた領域ごとに失敗させる結合テスト |
| 使える状態になった後のずれ | Web の読み込みの 31% で、操作なしに画面が動いた | Layout Instability API の本番イベント |
| ずれの原因 | 遅れて届くヘッダー行、名前の読み込みで横にずれるキャレット、スクロールバーの出現で動くリスト | 原因を名指しし、上位からまとめて直した |
| 入力欄のタイピング経路 | フック 6,900 個とストア購読 900 件がキー入力ごとに再描画 | React フックの全数調査 |
| :root:has() セレクタ 1 個 | DOM を変えるたびに 24ms 追加 | スタイル再計算の回数を数える |
| 消し忘れの location.reload() | 1 日 50 万回の見えない再読み込み | 初回描画後のコード経路を追う |
| 放置タブのキャッシュ保存 | 同じスナップショットを 1 分に 2 回 IndexedDB へ複製。すべてメインスレッド | 放置タブのプロファイラを読む |
| Latin-1 以外の文字を含む返答 | 最初のコードブロックのハイライトで約 1 秒固まる (図 6 上) | CPU の引っかかりを探す巡回 |
| 計測や安全装置の追加 | PR の約 3 分の 1 に計測や安全装置の追加が入り、そこから次のスレッドが生まれた | Claude が新しいベンチを提案し続けた |
安全装置を先に作り、社内公開 4 時間後の小さなずれも原因まで追った
触る場所はほぼすべて初回描画・入力欄・会話表示だった。そこで最適化に入る前にルールを決めた。全 PR は自動レビューと 1 人以上の承認を通す。最適化より先に単体テストを書く。見た目に響く変更は短命のフラグの裏で出す。結果、3,000 件超の変更で顧客に影響する障害もロールバックも出なかった。
フラグは約 200 本作り、Claude が緊急停止用か段階公開用かを分け、2 週間の終わりには半分以上を片付けた。静的な入力欄は壊れやすい。React 版に替わる瞬間に 1px でもずれると画面が跳ね、速くした意味が無くなる。そこで Claude は何十もの安全装置を作った (表 3)。危ない変更は社員、利用者の 1%、全員の順に広げた。
社内公開の 4 時間後、エンジニアの Marius が「新しいタブで開くと入力欄が落ちる」と録画を出した (図 5)。原因は自社コードではなかった。組織管理下の Chrome は新しいタブの下に 56px のフッターを出す。アドレスバーに入力中に Chrome が先読みしたページは、フッターの分だけ低い高さで描かれ、約 0.1 秒後に伸びる。Claude は伸びる間もレイアウトを固定し、先読みを再現するテストを足した。
| 静的な入力欄の安全装置 | 何を保証するか |
|---|---|
| 静的 HTML は本物の React 部品を jsdom で描いて生成する | 静的版と React 版の中身がずれないことをテストで保証 |
| 14 種類の画面幅で静的版と React 版を比べる結合テスト | 位置のずれが 1px 以内 |
| 交代の瞬間もキーを打ち続けるテスト | キーの取りこぼしや順序の入れ替わりがあれば失敗 |
| 本番で交代のたびにずれを 0.1px 単位で報告 | 0 でない報告があれば Claude がスレッドを立てる |
人が攻め方・好み・方向を決め、Claude は描画を 1 フレーム 8.33ms の予算に収めた
ループは自律ではなかった。人の役目は 3 つだ (表 4)。Claude は放っておくと手を広げたがらない。見つけた問題はチケットに回し、実現性を控えめに言い、見積もりを多めに出す。人は安全装置を信じて背中を押した。目標を達成してスレッドの勢いが落ちると、Sam は「目標は止まる地点ではない。次は何か」と各スレッドに書いた。
脇道の 1 つは描画の滑らかさだ。Claude が録画にフレームレート表示を付けると、著者の Raymond が「120fps まで上げられるか」と聞いた。ヘッドレス Chromium は既定で 60Hz で刻む。Claude は DevTools のフレーム制御で 120Hz に正確に刻めると確かめた。240 回の指示でちょうど 240 フレームが描かれ、フレームごとの合否が揺れなく決まる。
120fps なら 1 フレームの持ち時間は 8.33ms。Claude は長い返答を 1 コマずつ測った。完成したブロックはメモ化し、伸びるコードブロックの字句解析はワーカーへ移し、表はセルが届くたびに描くようにした。約 60 本の PR で、メインスレッドを塞ぐ時間は約 750ms から約 200ms に減った。CPU は約 3 分の 1 になり、120Hz の測定は Claude が見張る夜間ジョブになった。
| 人の役目 | 記事の例 |
|---|---|
| 攻め方: 慎重な Claude をもっと大胆にさせる | Claude が「PR は今週出す。数値が出るのは数日後」と答えると、Raymond が「今すぐ出せばマージもデプロイもする。僕らには何でもできる力がある。もっと勇敢に」と返した。Claude は「1 時間以内に出す」と応じた |
| 好み: 体感が変わる変更を、担当者が前後の画面写真や録画で判断する | 表はセル単位で埋めるか行ごとか。読み込み中の骨組み表示はすぐか 0.5 秒後か。1 語ずつのフェードの見た目は、1 フレーム予算の 5 分の 1 という描画コストに見合うか |
| 方向: スレッドを 1 つの指標か操作に絞り、優先順・統合・打ち切りを決める | 記事は 150 本のスレッドを「釘を探す 150 本のハンマー」と表現した。900 行の PR には「送信 1 回 2ms のためにビルドプラグインを保守する価値はない」と 1 行で却下した |
記事の見出し 8 つとこのページの対応表 (9 行・拾った数値つき)2 段落 + 表 9 行
この表は、記事の各見出しがこのページのどこで扱われ、どの数値と図を拾ったかを示す。記事の主張はすべて記事本文と図に基づく。
本ページが加えたものは次の通りで、記事の主張ではない。図に描き込んだ日本語の訳・赤枠・番号。動画から切り出したコマの選び方と、コマの秒数の読み取り (秒数と英語の表示は動画内の文字)。表 1〜4 の列の立て方と要約。辞書参照・キャレットなどの訳語。
| 記事の見出し | このページの該当箇所 | 拾った数値・図 |
|---|---|---|
| 冒頭 (見出しなし) | タイトル・結論・3 行・図 1 | 3.1 倍 (幾何平均)・3.1→0.55 秒・0.8→0.3 秒・2.6→0.73 秒・13 計測全件・利用の 95%・1 日数万時間・3,000 件超の変更で顧客影響の障害とロールバック 0・Opus 5.5 とほぼ同等 |
| The brief | 節 1・図 2・表 1 | 常設の指示・Datadog MCP・約 20 件の計画・3 日目に 12/13・サイドバー再描画 −90%・0.36 秒と 2.93 秒・突飛な案の募集 |
| Anything can be hill climbed | 節 2・図 3 | 11 分で 5 スレッド・命令 −48%/−31%・実時間 −78%/−44%・4.6 倍/1.8 倍・命令の 4 分の 1・ID を 3 回参照・ラチェット |
| The loop, thread by thread | 節 3・図 4・表 2 | 6 段のループ・CLS 0.008 と 0.1・20/20 回・31%・ずれの原因 3 つ |
| Scaling horizontally | 節 3・表 2・図 6 上 | 150 本超・1 本 50〜100 PR・1 日 200 件超・PR の 3 分の 1・フック 6,900・購読 900・24ms・50 万回/日・1 分 2 回・1.0→0.35 秒・100→40ms・20 行・数字の鬼 |
| Guardrails | 節 4・図 5・表 3 | 約 200 本のフラグ・半分超を片付け・14 画面幅・1px・0.1px・社員→1%→全員・4 時間後・15〜20px・49 回で 0px・56px・18%・10px・約 0.1 秒 |
| Steering | 節 5・表 4 | 攻め方・好み・方向・150 本のハンマー・900 行の PR・2ms・1 フレーム予算の 5 分の 1・0.5 秒 |
| An 8-millisecond budget | 節 5・図 6 下 | 60Hz/120Hz・8.33ms・240 フレーム・約 60 本の PR・750→200ms・CPU 3 分の 1・夜間ジョブ・約 4 倍・9 倍・4.5 倍 |
| What's next | 記事の結論と今後の枠 | 約 3 倍・ラチェット・p95・他の操作・長い会話・Electron/Chromium/Node.js・半年前 |