Claudeは、ボトルネックの発見から性能試験の作成、修正、公開後の監視までを行い、3000件を超える変更を加えたという。

　その詳しい内容を明らかにしたのが、Anthropicが2026年9月23日にClaudeの開発者向けブログで公開した「How we made claude.ai 3x faster in two weeks」という記事だ。記事によると、この高速化は同年8月、わずか2週間の集中した取り組みとして行われたという。

　claude.aiのWeb版とデスクトップ版、さらに同社の関連製品まで調べると、改善すべき項目は13種類に及んだ。このうち12項目は、わずか3日で目標値を達成した。その後もClaude自身が新たなボトルネックを見つけ、次々と改善を重ねていった。

　その成果は、実際の利用環境にも表れている。実際の利用環境でも、claude.aiを開いてから文字を入力できるようになるまでの時間は、75パーセンタイルで3.1秒から0.55秒へと短縮された。

　「Claude Code」の新規セッション開始も0.8秒から0.3秒へ、「Claude Cowork」のクラウドセッション読み込みは2.6秒から0.73秒へ、そして、メッセージ送信は0.928秒から0.048秒へと短縮されたという。Anthropicは、これによって利用者が待つ時間を合計で毎日数万時間削減できると推測している。

　こうした高速化を支えたのが、ベータ版の「Claude Tag」と呼ばれる仕組みだ。今回は、この仕組みを使って「Claude Opus 5.5」とおおむね同等の性能とされる社内研究モデルを動かしたという。

　Claude Tagは社内の「Slack」チャンネルに常駐し、測定から最適化、デプロイ、監視までの一連の作業を繰り返した。これにより、Claudeが高速化のための改善を次々と試せる環境を整えた。

　具体的には、次のような流れだ。

　このループは150以上のスレッドで同時に進み、多い日には200件を超える改善が実際のサービスに反映されたという。

　とはいえ、全てをClaudeに任せたわけではない。開発者はSlackでClaudeに問題を伝えたり、何を測定すべきかを提案したりしながら、改善の方向性を示した。自然な言葉で開発者とやりとりするClaudeは、まるで開発チームの一員のようだ。

　今回の取り組みでは、開発者とClaudeが「測定できるものは改善できる」という考え方の下、まずは計測できる項目を徹底的に増やすことから始めた。従来の「実際にかかった時間」（wall-clock）だけでは、さまざまな要因によるばらつきが大きく、ミリ秒単位の改善を正確に検証するのが難しかったためだ。

　そこで、Valgrindを使ったCPU命令数の計測や、V8による関数呼び出し数、Reactのコミット数、WebブラウザのDOM変化数、スタイル再計算数など、システム内部で何が起きているのかを細かく測定できるようにした。

　こうして計測できる項目を増やすことで、Claudeは「どこが遅いのか」をより正確に把握できるようになった。さらに、その中から改善につなげやすく、実際の処理時間の短縮にもつながりそうな指標を選び、CI（継続的インテグレーション）の基準として採用した。

　実際に、会話のメッセージツリーを組み立てる処理では、同じメッセージIDを3回も辞書検索していることが、CPU命令数の分析から分かった。Claudeはこの重複した検索を見直し、CPU命令数を48％削減。実際の処理時間も78％短縮した。

　Claude Codeの出力を解析する「ステータス行検出スキャナ」でも、CPU命令数を31％、処理時間を44％削減した。さらにWebブラウザでは、ページ読み込み時に起こるレイアウトシフト（画面上のズレ）が、ユーザー体験を損ねていることも分かった。

　一般的なCLS指標では問題とされないほど小さなズレでも、「Layout Instability API」を直接参照すれば、ページのどの部分が、いつ動いたのかまで正確に把握できる。Claudeはこのデータを基に、遅れて表示されるヘッダ行やスクロールバーなど、細かな原因を特定し、一つずつ修正していった。

　重要なのは、単に測定と最適化を繰り返したことではない。測定した結果を、次の改善につなげる仕組みにしたことだ。

　Claudeは計測した数値を見ると、その数値をさらに下げる方法を探す。そして改善に成功すれば、その結果をCIの新しい基準値として設定し、以降はそれより悪化しないようにする。記事では、この「改善した状態を元に戻さない」仕組みを「ラチェット」と表現する。

　計測できる項目が増えるほど、新たな改善ポイントが見つかる。改善した結果は新しい基準として固定されるため、そこからさらに次の改善を目指せる。こうして、改善が次の改善を生むループが成立した。

　ただし、このループをClaudeが自由に回していたわけではない。安全性を確保するため、全ての改善プルリクエストは自動レビューを受けた上で、少なくとも1人の人間が承認することを必須とした。また、利用者に影響する可能性のある変更には、すぐに停止できる「機能フラグ」（feature flag）を設け、段階的に公開した。

　約200件の機能フラグが使われ、その半数以上は作業終了までに削除されたという。

　記事では、人間の役割として、Claudeに目標以上の改善を促す「野心」（Ambition）、速さと使いやすさのバランスを判断する「好み」（Taste）、優先順位や終了時点を決める「方向付け」（Direction）の3つを挙げている。

　実際、Claudeがメッセージ送信を2ミリ秒短縮するために約900行の変更を提案した際、人間が「保守の複雑さに見合わない」と判断して却下したという。

　最終的に、claude.aiとデスクトップアプリには3000件を超える変更が加えられたが、利用者に影響する障害やロールバックはなかったとされている。

　なお、claude.aiなどの速度が約3倍になったというのは、あくまで同社が公表した今回の事例についての話だ。全ての性能が一律に3倍になったわけではない。記事で示された数値も、対象となった操作や定められた条件に基づく代表値だ。今回の事例からは、AIをソフトウェア開発にどう活用していくのか、その一つの形が見えてくる。

　人間が修正内容を一件ずつ指示するのではなく、改善すべき数値と、安全に試行錯誤できる環境を用意する。そしてAIに、測定と改善を繰り返させる。つまり、AIに「何を作らせるか」だけでなく、「どの数字を与えるか」「どんな条件なら変更を認めるか」「どこで人間が止めるか」まで設計する。今後のAIを活用したソフトウェア開発では、こうした考え方がますます重要になっていくのかもしれない。

上司X：　AnthropicがClaudeを開発に活用し、claude.aiとデスクトップアプリの利用体験を、2週間で約3倍高速化させた、という話だよ。

ブラックピット：　ClaudeがClaude自身を速くした、ということですか。AIが自分で自分を改良したようにも聞こえますが。

上司X：　ちょっと違うんだよな。ClaudeのAIモデルそのものを学習し直した話ではない。あくまでサービスであるclaude.aiについて、Web画面やデスクトップアプリの読み込み、描画、入力処理などを改善したんだ。

ブラックピット：　なるほど。でも、3000件以上の変更とは、ずいぶん勢いよく手を入れたものですね。

上司X：　しかも、2週間だからな。

ブラックピット：　なんというか、測定できるものは改善できるですか？　それがポイントのようですね。

上司X：　ああ。Webページやアプリの処理の中で測定できる要素の中から、処理時間を短縮できるものを見つけていこう、という計画だったようだからな。改善できそうな場所を数値で捉えられれば、試行錯誤を始められるということだろう。

ブラックピット：　しかも、全部AIに任せるんじゃなくて人間の手も入ることで安全に機能向上できる、という。Anthropicは自分たちの手の内を明らかにしたようなものですけど、いいんでしょうかね？

上司X：　構わないからこその記事公開なんだろう。今回の記事は、claude.aiの改善をClaudeが担当したよ、という内容だけど、他のサービスでも、計測基盤や安全策を整えれば、この開発手法を応用できるかもしれない。今後は、AIを使った開発手法の中でも、AIと人間との「タッグ」による共同作業が欠かせなくなっていくかもしれないな。