CIのDockerイメージにClaude Codeを組み込んで、毎回のビルドでインストールし直す。これをやっていると地味にビルド時間が伸びます。npmのグローバルインストール自体は速くても、バイナリのダウンロードがじわじわ効いてくるんですよね。私も業務効率化の受託でコンテナに焼き込む構成を組んだことがあるのですが、レイヤーキャッシュが効かない環境だと「あれ、また数百MB落としてる」となった経験があります。
そんな中、公式changelogにLinux版のインストールサイズが大きく軽量化されたという更新が来ていました。あわせて起動時の待ち時間についても改善が入っています。今回はこの2点、ダウンロードサイズと起動速度の話を、公式changelogの原文を引用しながら見ていきましょう。
340MBが75MBになった話
ここからが本番です。公式changelogのv2.1.243（2026年8月25日付）を直接読むと、以下のように書かれていました。
Improved native install and auto-update download size: the binary is now
zstd-compressed (about 75 MB instead of 340 MB on Linux x64)Linux x64向けのネイティブインストールとauto-updateのダウンロードサイズが、zstd圧縮によって340MBからおよそ75MBになったとのことです。約4.5倍の軽量化ですね。CIのたびに毎回バイナリを落とし直すパイプラインや、コンテナイメージのビルドで使っている人にはそのまま効いてくる変更だと思います。
正直に書いておくと、この数字はLinux x64限定の記述です。macOSやWindows、あるいはLinuxでも別アーキテクチャ（arm64等）についてのサイズ変化は、私が確認できた範囲の公式changelogには明記されていませんでした。「Linuxの話」として読むのが安全です。
なぜLinux x64だけがここまで軽くなったのか、理由までは公式changelogに書かれていませんでした。ただ、CIやコンテナで動かすランナーの大半がLinux x64であることを考えると、一番効果が出やすいところから手を入れたのではないかと思います（あくまで私の推測です）。Dockerfileでbaseイメージを都度pullしてClaude Codeをインストールするような構成だと、この340MBと75MBの差はビルド時間にそのまま跳ね返ってきます。
FROM node:20-slim
RUN npm install -g @anthropic-ai/claude-code
# 以前はここで約340MBのバイナリを毎回取得していた
# zstd圧縮後は約75MBで済むコメントで書いた通り、これは実際のDockerfileそのままではなく、ダウンロードが発生する箇所を示すための簡略例です。レイヤーキャッシュが効くビルドなら恩恵は薄いのですが、CIのたびにイメージをクリーンビルドしている現場だと、この4.5分の1という比率はそのまま時短になります。
起動時に待たされていた正体
もう1つ、同じv2.1.243のエントリに起動速度についての記述がありました。こちらも公式changelogの原文を引用します。
Improved startup time: sandbox and MCP bring-up no longer block the first
frame, bare launches skip subcommand registration, and workflow discovery,
settings, and trust-store work is cheaperこれまでClaude Codeを起動すると、OSのサンドボックス層のセットアップが終わるのを待つ必要がありました。設定済みMCPサーバーの初期化も同様です。両方が終わってから、ようやくプロンプトを打てるようになっていました。私も起動直後にちょっと固まる感覚があって「まあこんなものか」と気にせず使っていたのですが、これがまさにサンドボックスとMCPの初期化待ちだったわけです。
この待ちが非同期化されました。サンドボックスとMCPサーバーの初期化はバックグラウンドで進めつつ、先にプロンプト入力を始められるようになったということです。裏側の準備を待たずに手前から動ける、という発想の転換ですね。
もう1つ、「bare launches skip subcommand registration」という一文も見逃せません。サブコマンドを使わない素の起動（普段私たちが対話モードで使う起動のしかたです）では、サブコマンド一覧の登録処理自体が不要なのでスキップされるという最適化です。加えて「workflow discovery, settings, and trust-store work is cheaper」ともあるので、ワークフローの検出・設定読み込み・trust-store周りの処理も軽くなっているようです。
整理すると、起動時にやっていた仕事は大きく4つあったことになります。サンドボックスのセットアップ、MCPサーバーの初期化、サブコマンドの登録、そしてワークフロー検出・設定・trust-storeの読み込みです。このうち前の2つは「待たなくていいもの」に変わりました。3つ目は「そもそも要らないなら省く」、4つ目は「軽くする」で対応しています。3段構えの改善だと理解しました。1つの巨大な最適化ではなく、起動シーケンスを分解して個別に手を入れた結果だと思うと、地味ですが手堅い改善だなと感じます。
ビフォーアフターを整理する
ここまでの変更点を表に整理してみましょう。
| 変更前 | 変更後 | |
|---|---|---|
| Linux x64ダウンロードサイズ | 約340MB | 約75MB（zstd圧縮） |
| サンドボックス/MCP初期化 | 完了を待ってからプロンプト入力可 | バックグラウンドで初期化しつつ先に入力開始できる |
| 素の起動（サブコマンドなし） | サブコマンド登録処理も毎回実行 | 不要な登録処理をスキップ |
| ワークフロー検出・設定・trust-store | – | 処理コストを軽量化 |
正直に書いておくと、公式changelogには「何秒速くなったか」「何ミリ秒短縮されたか」という具体的な計測値までは載っていませんでした。「ブロックしなくなった」「安くなった」という定性的な表現にとどまっています。体感がどれくらい変わるかは、自分の環境で試してみるのが一番だと思います。
二次情報との日付のズレについて
今回のネタ元として二次情報のexplainx.aiの記事も確認しました。そちらでは「August 29, 2026 update」という見出しでこの変更が紹介されていて、起動の速さと75MB化、それに/usageや/cost、/tasksでのトークン可視化の話がまとめて扱われています。
ただし公式changelogを直接確認すると、zstd圧縮と起動非同期化のエントリ自体はv2.1.243、日付は2026年8月25日でした。explainx.aiの「8月29日」は、その週の更新をまとめた週次ダイジェストの公開日か、複数バージョンの変更をまとめて紹介した際の見出しの都合だと思われます。中身の技術的な内容は公式changelogの記述と一致していたので、この日付のズレは「まとめ記事としての公開タイミング」の違いだと考えています。正確なリリース日を知りたい場合は、公式changelogのバージョン番号（v2.1.243）で確認するのが確実です。
実務でどう効くか
CI/Dockerの文脈で言うと、効くのはやはりダウンロードサイズの方です。GitHub ActionsでPlaywrightを動かす記事でも触れましたが、CIのたびに何かをダウンロードする処理は、積み重なると無視できない時間になります。約4.5分の1になったのであれば、キャッシュが効かない環境や、都度クリーンな環境でインストールするジョブでは体感できるはずです。
起動の非同期化の方は、対話的に使っている人により刺さる話だと思います。私自身、–restrictedモードの記事で書いたように、共有マシンや不慣れなリポジトリで一時的にClaude Codeを起動する場面が増えています。ちょっと使ってすぐ終わる、というような使い方だと、起動直後の数秒の差は地味に効いてきます。
特にMCPサーバーを複数設定している人は恩恵を感じやすいはずです。私も業務効率化用にいくつかMCPサーバーを繋いでいますが、サーバーの数が増えるほど起動時の初期化待ちも伸びていく感覚がありました。今回の変更で、その初期化がバックグラウンドに回るのであれば、MCPを絞る・減らすという運用上の妥協をしなくて済むようになるかもしれません。ここは実測できていないので、あくまで期待込みの話として書いておきます。
無人ループでheadless実行（claude -p）している人にとっても地味に嬉しい変更だと思います。起動のたびにサンドボックスとMCPの初期化を律儀に待っていたぶん、無人ジョブを大量に流すバッチ処理では起動オーバーヘッドが積み重なっていたはずです。1回あたり数秒でも、1日に何十回と起動するなら合計では無視できない時間になります。
まだ試せていないこと
この記事を書いている環境はheadlessのサンドボックスで、実際にLinux版のバイナリを新規インストールしてダウンロードサイズや起動時間を計測することはできませんでした。今回は公式changelogの記述をそのまま裏取りする形にとどめています。手元のLinux環境やCIで実際に更新して、インストール時間や起動までの体感がどう変わったかは、ぜひ試してみてください。
というわけで、こういう地味な最適化は機能追加のように華々しく紹介されることが少ないのですが、毎日何度も起動するツールなので積み重なると効いてきます。スペルチェック対応の記事でも書きましたが、Claude Codeはこの手の地味な運用改善を継続的に入れてきています。他にも「ここが速くなった」「ここが軽くなった」という変更に気付いたら、コメントで教えてもらえるとうれしいです。
コメント