Claude.aiを2週間で3倍高速化した方法

エンジニアリング Claude.aiを2週間で3倍高速化した方法 Claudeは一度測定できるようになれば、それを高速化できます。そのため、私たちは測定すべきものをさらに見つけ続けました。 著者 Raymond Wang, Sam Attard, and Issac G. 公開日 2026年9月23日 読了時間 15分 この8月、私たちはClaude.aiとClaudeデスクトップアプリのコアユーザーエクスペリエンスを2週間のスプリントで約3倍高速化しました。ユーザーは遅いと指摘しており、それは正しかったです。私たちは、Claudeをすべてのスレッドに配置し、単一のSlackチャンネルからすべてを実行しました。私たちはユーザーアクティビティの95%を占める4つのジャーニーに焦点を当てました。75パーセンタイルでは、claude.aiの新規ロード時のタイプ可能なページまでの時間が3.1秒から0.55秒に、Claude Codeセッションの開始が0.8秒から0.3秒に、Claude Coworkクラウドセッションのロードが2.6秒から0.73秒に短縮されました。全体として、これは毎日数万時間ものユーザーの待ち時間を節約すると推定しています。 コアユーザーのジャーニー、p75 リアルユーザーモニタリング、プラットフォームおよび製品ごと、8月13日 vs. 8月27日 アプリの起動 claude.ai web · 新規ロード 5.6倍高速化 -82% 3,085 → 550 ms デスクトップアプリのコールドスタート 1.9倍高速化 -47% 6,310 → 3,328 ms 会話の開始 チャット web 1.5倍高速化 -34% 416 → 273 ms チャット デスクトップ 2.1倍高速化 -51% 460 → 224 ms Claude Code デスクトップ 2.4倍高速化 -59% 837 → 347 ms 会話のロード チャット web 2.4倍高速化 -59% 1,557 → 646 ms チャット デスクトップ 2.8倍高速化 -64% 1,353 → 488 ms Claude Cowork デスクトップ · クラウド 3.5倍高速化 -72% 2,566 → 728 ms Claude Code デスクトップ 2.1倍高速化 -52% 545 → 262 ms メッセージの送信 クライアントサイド共有 チャット web 3.1倍高速化 -67% 180 → 59 ms チャット デスクトップ 2.2倍高速化 -54% 140 → 64 ms Claude Cowork デスクトップ · クラウド 19倍高速化 -95% 928 → 48 ms Claude Code デスクトップ 4.8倍高速化 -79% 250 → 52 ms 4つのジャーニーにわたる13の測定値、前後比較: 平均3.1倍高速化（幾何平均）。 コアユーザーのジャーニー、p75 リアルユーザーモニタリング、プラットフォームおよび製品ごと、2026年8月13日 vs. 8月27日 アプリの起動 claude.ai web · 新規ロード 5.6倍高速化 -82% 3,085 → 550 ms デスクトップアプリのコールドスタート 1.9倍高速化 -47% 6,310 → 3,328 ms 会話の開始 チャット web 1.5倍高速化 -34% 416 → 273 ms チャット デスクトップ 2.1倍高速化 -51% 460 → 224 ms Claude Code デスクトップ 2.4倍高速化 -59% 837 → 347 ms 会話のロード チャット web 2.4倍高速化 -59% 1,557 → 646 ms チャット デスクトップ 2.8倍高速化 -64% 1,353 → 488 ms Claude Cowork デスクトップ · クラウド 3.5倍高速化 -72% 2,566 → 728 ms Claude Code デスクトップ 2.1倍高速化 -52% 545 → 262 ms メッセージの送信 クライアントサイド共有 チャット web 3.1倍高速化 -67% 180 → 59 ms チャット デスクトップ 2.2倍高速化 -54% 140 → 64 ms Claude Cowork デスクトップ · クラウド 19倍高速化 -95% 928 → 48 ms Claude Code デスクトップ 4.8倍高速化 -79% 250 → 52 ms 4つのジャーニーにわたる13の測定値、前後比較: 平均3.1倍高速化（幾何平均）。 私たちは、Opus 5.5に匹敵する内部リサーチモデルを実行しているClaude Tag（ベータ版）を使用しました。Claudeはボトルネックを見つけ、ベンチマークを構築し、改善をリリースし、すべてのデプロイを監視しました。私たちは目標を設定し、トレードオフを行い、すべての変更を承認することで進めました。このアプローチにより、顧客に影響を与えるインシデントやロールバックを一度も起こすことなく、3,000件以上の変更をマージしました。この記事では、私たちがリリースしたもの、それをどのように測定したか、そして安全に行うためにClaudeと構築したループについて説明します。 概要 スプリントの前に、以下の定例指示を含むSlackチャンネルを作成しました。 @Claude あなたの仕事は、claude.aiウェブサイトとデスクトップアプリのパフォーマンスに関連するすべてのことを促進することです。あなたの責任には、パフォーマンスの低下を監視するデプロイの監視、既存のテレメトリの精度と網羅性の評価、適切にキュレーションされたオブザーバビリティダッシュボードの維持、観察された問題や容易に解決できる問題に対するソリューションのプロアクティブな実装、パフォーマンスプロジェクトの機会の提案、そして人間のチームメイトとのコミュニケーションが含まれます。 […] このチャンネルの究極の目標は、あなたが可能な限り自律的になることです。しかし、今日、それがまだ可能ではないことを私たちは知っています。 私たちはClaudeにDatadog MCPサーバーを介して使用状況データを分析するように依頼しました。それは、最も影響力の大きい4つのユーザーのジャーニーを特定しました：アプリの起動、会話の開始、既存の会話のロード、メッセージの送信。ウェブとデスクトップの間、そして私たちの製品全体で、それらのジャーニーは13の異なる測定値となりました。ベースラインを確立するために、結果が直接比較可能になるまでインストルメンテーションを追加しました：各測定はユーザーインタラクションで始まり、結果がレンダリングされると終了し、クライアントとサーバーの作業を明確に区別しました。 スプリントは、それぞれ特定のジャーニーを対象とした約20の厳選されたプロジェクトのリストで開始しました。Claudeは各プロジェクトの影響をミリ秒単位で推定し、私たちはそれらの推定値を集計してスプリントの目標を設定しました。プロジェクトの中にはかなり大きなものもありましたが、2週間以内にほとんどを達成できると考えていました。私たちは3日目までに13のターゲットのうち12を達成しました。計画されたプロジェクトは早期に着陸しました。より高速な起動のために、Reactの初期化中にユーザーが入力できるようにHTMLに静的なコンポーザーを組み込み、デスクトップシェルのメインプロセスがゼロから再コンパイルしないようにV8コードキャッシュをプリコンパイルしました。より高速なナビゲーションのために、会話間にコンポーザーをマウントしたままにし、ユーザーがホバーしたときにセッションをプリフェッチし、サイドバーの再レンダリングを90%削減しました。また、Claudeが機会を特定し、新しいワークストリームを提案するための余地も残しました。それらのワークストリームはすぐに独自のフルプロジェクトに発展し、初期の目標をはるかに超えました。そこで、新しい目標を設定し、さらに測定すべきものを探しました。 @Claude 元のプロジェクトリストのほぼすべてのプロジェクトと、さらに多くのプロジェクトに資金を提供することになりました。更新しましょう。 […] まだ探求していないことは何ですか？何をヒルクライムできますか？現時点で最も機会があるのはどこですか？ […] WACKYなアイデアも歓迎します。何でもヒルクライムできます。 開始当初から、デプロイのケイデンスよりも速くイテレーションしたいと考えていました。Claudeは数時間、さらには一晩中非同期で作業でき、フィールドリードを待たずにプロトタイプを検証させたいと考えていました。これを達成するために、ラボでパフォーマンスを測定する他の方法を探しました。Samが最初のリードを見つけました： #claude-apps-perf · スレッド Sam 12:34 PM ウォールクロックタイミングの代わりに何ができますか？例えばJS命令数を測定できますか？ ClaudeApp 12:42 PM はい。純粋なJSのホットパスでは、命令数を直接測定できます：node --predictableでベンチマークを実行し、チェックインされたベースラインと比較します。統計は必要ありません。 ブラウザパスについては、Chromiumの下で命令数をカウントすることはできませんが、他の決定論的なカウントの階層があります：インタラクションごとのReactコミット数、V8の正確なカバレッジからの関数呼び出し数、レイアウトとスタイルの再計算数、DOMミューテーション。どれから始めますか？ Sam 12:49 PM Valgrind + Ir + --predictableを1つのスレッドで、ブラウザ/Reactベンチのそれぞれを新しいスレッドで探求しましょう。すべてで私にピンしてください。あなたは私たちの望むものを知っています。さあ始めましょう。 実際の会話から再現。 11分後、5つのスレッドが実行され、それぞれが命令数、V8呼び出し数、Reactコミット数、スタイル再計算数、DOMミューテーションという異なる測定に焦点を当てていました。私たちは、新しいベンチマークをすべて懐疑的に扱いました。それぞれに2つのジョブがありました：第一に、Claudeがラボで動かせるメトリック。第二に、数値を下げることしかできないCIのガードレール。ベンチマークが不安定だったり、ユーザーのレイテンシーと実際には相関していなかったりした場合、Claudeが間違った丘を登るのを防ぐために、それを破棄しました。 @Claude これらのそれぞれに対するヒルクライムが、測定可能なウォールクロックパフォーマンスの勝利につながることを証明してください。証明できないベンチは出荷しません。 ウォールクロック時間はユーザーが感じるものですが、ノイズが多く、ミリ秒はCIゲートとして使用するには不安定すぎます。命令数は決定論的であるため魅力的でしたが、それでもClaudeにそれがウォールクロック時間と一致することを証明してもらう必要がありました。そこで、2つのホットパスでカウントを減らすようにClaudeに依頼しました：会話のメッセージツリーを組み立てるルーチンと、スキャナー