Claude Code stableとlatestの選び方

「昨日まで動いていた手順が、今朝は動かない」「設定を変えた覚えはないのに、挙動が変わっている」——そう感じたとき、心当たりは一つしかありません。夜のあいだに、道具のほうが新しくなっているのです。

結論から言うと、Claude Code の更新には latest と stable という2本の線があり、どちらに乗るかは自分で選べます。そして「何も選ばなければ最新版が来る」という理解は、半分しか正しくありません。入れ方によって、既定の線そのものが違うからです。

株式会社Fyveは、無人で動かす仕組みの設計と運用を仕事にしています。この記事では、私が2026年9月24日に配布記録を自分で測った実数をもとに、2本の線が今どれだけ開いているのか、そして自分がどちらに乗っているのかをどう確かめるのかを整理します。

Claude Code の更新には2本の線がある

Claude Code の公式ドキュメント「Configure release channel」には、更新の受け取り方が2種類あると明記されています。設定名は autoUpdatesChannel です。

• latest（既定） — 新機能がリリースされ次第そのまま受け取る
• stable — 典型的には1週間ほど前の版を使い、大きな退行（major regressions）を含むリリースを飛ばす

ここで最初に釘を刺しておきたいことがあります。stable は「安全な線」ではありません。公式の説明は「大きな退行を含むリリースを飛ばす」であって、不具合がないという意味ではないからです。飛ばす対象になるのは、あくまで大きな退行と判断されたリリースだけです。

この区別は言葉遊びではありません。「stable にしておけば壊れない」と理解してしまうと、壊れたときに原因の探し方を間違えます。stable が約束しているのは安全ではなく、遅さです。そして遅さには、後で見るとおり具体的な中身があります。

「何も選ばなければ最新版」は半分しか正しくない

ここが、この記事でいちばんお伝えしたい点です。

「既定は latest」という記述は公式ドキュメントにあります。しかしそれは autoUpdatesChannel という設定の既定値の話であって、「あなたの環境に何が入っているか」とは別の話です。公式ドキュメントの各インストール手順を最後まで読むと、入れ方によっては、何も選ばなくても stable 側に乗っていることが分かります。

公式ドキュメントの記載を、入れ方ごとに並べ直すと次のようになります。

Homebrew には2つの cask が用意されています。claude-code が stable を追いかけ、claude-code@latest が latest を追いかけます。つまり公式ドキュメントに載っている brew install --cask claude-code をそのまま実行した人は、選んだ覚えがないまま stable 側に乗っています。

Linux のパッケージマネージャも同じです。公式ドキュメントは apt・dnf・apk の各リポジトリが stable と latest の2系統を配信していると書いたうえで、掲載しているコマンドは stable のほうを設定しています（「which fits most users」という注記つきで、latest 側のURLも各タブに併記されています）。

自動更新の有無も揃っていません。公式ドキュメントは「Homebrew、WinGet、apt、dnf、apk のインストールは既定では自動更新しない」と明記しています。ネイティブと npm は起動時と実行中に定期的に更新を確認しますが、パッケージマネージャ経由はシステム側の更新作業に委ねられます。

ここから導かれる実務上の結論は、シンプルですが見落としやすいものです。「自分がどの線に乗っているか」は、設定ファイルを見るだけでは分かりません。どうやって入れたかとセットで初めて決まります。そして多くの場合、入れた日のことはもう覚えていません。

この記事を読んでいるあなたへ無料プレゼントClaude Codeを「素のまま」使うな設定で差がつく——CLAUDE.md・権限・スキルの実物を公開（全24ページ）そのまま書き換えて使えるCLAUDE.mdの型お金と送信をAIに触らせない「3段階の柵」1回教えたら何度でも動く、手順書のコピペ雛形無料でダウンロード →登録すると、過去の特典もまとめて受け取れます（PDF 15点・合計400ページ ＋ すぐ使えるzip素材 3点）

2本の線が今どれだけ開いているか、自分で測れる

「1週間ほど遅れる」という説明は公式のものですが、今この瞬間に実際どれだけ開いているかはどこにも書かれていません。書かれていない代わりに、配布記録を見れば自分で測れます。

私が2026年9月24日に測った値は次のとおりです。

• latest = 2.1.281（公開 2026-09-23 17:01 UTC）
• stable = 2.1.273（公開 2026-09-15 18:06 UTC）
• 時間差 = 7日22時間55分

公式の「約1週間」という説明と、実測がほぼ一致しました。ただしこれは2026年9月24日という1点のスナップショットです。配布記録から読み取れるのは「今どの版を指しているか」であって、タグが過去にどう動いてきたかの履歴は取れません。ですから「常に1週間遅れ」と一般化することはできませんし、この記事の数字も、あなたが読んでいる時点では動いているはずです。

番号の引き算では、版の数は出ない

ここで一つ、数えるときの落とし穴があります。

281 と 273 を引き算すると8になります。しかし実際に配られた版は7つです。配布記録に 2.1.279 が存在しないからです。実在したのは 2.1.274／275／276／277／278／280／281 の7版でした。

欠番が生まれる理由は公表されていないので、ここでは推測しません。押さえておくべきことは手順のほうです。差を数えるときは、番号を引き算せず、配布記録に実在する版を数える。これだけです。引き算で出した数字は、たいてい実際より多くなります。

測り方

特別な道具は要りません。npm のレジストリは、パッケージごとに「どのタグがどの版を指しているか」と「各版がいつ公開されたか」を公開しています。前者を見れば latest と stable の現在地が分かり、後者を突き合わせれば時間差が出ます。

手順としては次の3つです。

1. 配布記録から、latest と stable がそれぞれどの版を指しているかを読む
2. その2つの版の公開時刻を読み、差を取る
3. 2つの版のあいだに実在する版を列挙して数える（引き算しない）

なお、npm の配布記録に stable というタグが実在することは確認できますが、公式ドキュメントの npm の章には stable タグの記載がありません。ですから「配布記録に実在する」とは言えても、「npm で stable を使うのが公式に案内された経路だ」とは書けません。断定はここで止めておきます。

「1週間待つ」とは、何を待つことなのか

線を選ぶというのは、抽象的には「速さと落ち着きのどちらを取るか」という話です。しかしそれだけでは判断できません。待っているあいだに何が積み上がっているのかが分からないからです。

そこで、開いている7版の変更点を全部数えました。2026年9月24日時点の公開 CHANGELOG を対象にした集計です。

合計583項目。内訳は修正が365項目で62.6%、追加が62項目で10.6%、改善が90項目で15.4%、変更が52項目で8.9%でした。

この比率が、判断の材料になります。「遅い線を選ぶ＝新機能を我慢する」ではありません。数のうえでは、待っているものの6割以上は修正です。新機能は10項目に1項目しかありません。

言い換えると、線の選択はこう整理できます。

• 修正を早く受け取りたいなら latest。自分が踏んでいる不具合が直っていた場合、それが手元に届くのが早い
• 変化の量そのものを減らしたいなら stable。1週間ぶんの583項目を一度に浴びずに済む

「安定性を取るなら stable」という言い方は、この意味では少し不正確です。stable で減るのは変化の頻度であって、手元にある不具合の数ではありません。すでに踏んでいる不具合については、stable のほうが直るのが遅くなります。

「1版」の大きさは、まったく一定ではない

上の表をもう一度見てください。版ごとの項目数が、極端にばらついています。

2.1.276 は1項目、2.1.278 は2項目しかありません。一方で 2.1.281 は176項目です。最小と最大で176倍の開きがあります。項目数の少ない版は、おそらく特定の問題に対する緊急の手当てでしょう（理由は公表されていないので断定はしません）。

これが意味するのは、「何版遅れているか」という言い方自体が、かなり粗い指標だということです。7版遅れと聞くと相当な差に聞こえますが、その7版のうち2版は合計3項目しかありません。逆に、たった1版の差でも176項目ぶん離れていることがありえます。

ですから、差を気にするなら版の数ではなく項目の数で見るほうが実態に近いということになります。前の節で「引き算ではなく実在する版を数える」と書きましたが、さらに一歩進めるなら、数えるべきは版ではなく中身です。

数え方で結果が変わった話

この集計では、途中で数字を取り直しています。正直に書いておきます。

最初に数えたとき、修正は266項目、追加は31項目（5.3%）と出ました。しかしこれは過小な集計でした。CHANGELOG の項目には [VSCode] や [Claude Desktop] のように、対象を示す角括弧が先頭に付くものがあります。行頭の単語だけを見て分類すると、これら148項目が「Fixed でも Added でもないもの」として全部こぼれ落ちます。

角括弧を外してから数え直した結果が、上の表の365項目・62項目です。修正は266ではなく365、追加は31ではなく62で、比率は5.3%ではなく10.6%でした。

この手の取りこぼしは、集計結果を見ただけでは気づけません。合計が583で変わらないので、表面上はつじつまが合っているからです。気づけたのは、分類できなかった項目の数を別途数えていたからでした。集計するときは「分類できた数」だけでなく「どれにも入らなかった数」を必ず出す——これは、この件から持ち帰るべき一般的な教訓だと思います。

線を選ぶ場所は、入れ方ごとに4か所に分かれている

ここまでで「線は2本ある」「自分がどちらに乗っているかは入れ方で決まる」と見てきました。では、どこで選ぶのか。公式ドキュメントを読むと、選ぶ場所が入れ方ごとに4か所に分かれていることが分かります。同じ道具なのに、見るべき場所が違うのです。

1. 設定ファイル（ネイティブ・npm）

settings.json に autoUpdatesChannel を書きます。

{
  "autoUpdatesChannel": "stable"
}

対話中に /config を開き、「Auto-update channel」から選ぶこともできます。こちらは後述する確認のやりとりが入るぶん、単独で設定ファイルを書き換えるより親切です。

2. cask の名前（Homebrew）

Homebrew ではこの設定ではなく、どちらの cask を入れたかで線が決まります。claude-code が stable、claude-code@latest が latest です。設定ファイルに autoUpdatesChannel を書いても、Homebrew 側の線は変わりません。

3. リポジトリのURL（apt / dnf / apk）

Linux のパッケージマネージャでは、登録したリポジトリのURLそのものが線を表しています。URL の末尾が stable か latest かで、配信される版が変わります。線を切り替えるには、登録済みのリポジトリ行を差し替えることになります。

4. インストール時の引数（ネイティブインストーラ）

ネイティブインストーラは、版番号か線の名前のどちらかを引数で受け取ります。そして公式ドキュメントに明記されているとおり、インストール時に選んだ線が、その後の自動更新の既定になります。つまり入れた瞬間の引数が、その後ずっと効き続けます。

組織で揃えたい場合は、これら4つとは別に managed settings（管理者設定）があり、ユーザー設定やプロジェクト設定で上書きできない形で線を強制できます。

4か所に分かれていること自体は、それぞれの入れ方の作法に合わせた結果なので、おかしな設計ではありません。ただ結果として、「更新の線を決めた覚えがない」という状態が自然に発生します。設定ファイルを開いても、そこに書いていなければ「既定のまま」としか分かりませんし、その既定が何なのかは入れ方に戻らないと確定しないからです。

切り替えるときに知っておきたいこと

stable に移ると、版が下がるのか

ここは多くの人が気にする点だと思います。答えは「下げない手当てがある」です。

minimumVersion という設定が下限として働きます。公式ドキュメントによれば、バックグラウンドの自動更新と claude update は、この値より低い版のインストールを拒否します。そのため、すでに latest の新しい版にいる状態で stable に移っても、下限を設定しておけば版が下がることはありません。

さらに /config 経由で latest から stable に切り替えると、現在の版に留まるか、ダウングレードを許可するかを聞かれます。留まるほうを選ぶと、その版が minimumVersion として設定されます。latest に戻すと、この値はクリアされます。設定ファイルを直接書き換えるより /config を勧めたいのは、この確認が入るからです。

自動更新そのものを止めたいとき

線を選ぶのとは別に、更新を止める設定が2つあります。名前が似ていますが、効く範囲が違います。

• DISABLE_AUTOUPDATER — バックグラウンドの確認だけを止める。claude update や claude install は引き続き動く
• DISABLE_UPDATES — 手動更新を含む全経路を止める。自前で配布していて、利用者に特定の版を使わせたい場合向け

ネイティブまたは npm のインストールであれば、claude doctor を実行して Auto-updates の行が disabled になっているかを見れば、設定が効いたかを確認できます。

なお、起動そのものを版の範囲で制限したい場合は、これらとは別に managed settings の requiredMinimumVersion と requiredMaximumVersion があります。minimumVersion が「更新の下限」なのに対し、こちらは「範囲外なら起動させない」という別の機能です。混同しないほうがよいところです。

今日やる4手

ここまでの内容を、手を動かす順番に並べ直します。

手1. 今の版と、どの入れ方で入れたかを確認する

claude --version で版が出ます。入れ方のほうは、思い出せなければ claude doctor の出力が手がかりになります。ここが分からないと、次の手が決まりません。

手2. その入れ方に対応する場所で、線を明示的に選ぶ

前章の4か所のうち、自分の入れ方に対応するものを開きます。結果として既定のままにするのは、まったく構いません。問題は速いか遅いかではなく、選んでいないことです。選んだうえで latest に留まるのは、立派な判断です。

手3. 無人で動かすものと、手で触るものを分ける

ここは実務的にいちばん効く手だと思います。

手元で対話しながら使っている環境では、更新で挙動が変わってもその場で気づけます。困ったら手を止めて調べればよい。一方、決まった時刻に無人で動く仕組みでは、挙動の変化に気づく人がその場にいません。私自身、無人で回している定型の処理については、手で触る環境とは更新の扱いを分けています。止まって困るほうを遅い線に置き、手で触るほうで先に新しい版を踏む、という分け方です。

これは「遅い線のほうが安全だから」ではありません。前述のとおり stable は安全を約束していません。そうではなく、変化が起きるタイミングを、自分が見ている時間帯に寄せるための分け方です。同じ変化なら、気づける場所で先に起きてほしい。それだけの話です。

手4. 差が気になったら、配布記録を見て自分で数える

「今どれだけ開いているか」は、公式ドキュメントには書かれていません。しかし配布記録には書いてあります。気になったときに自分で測れる、というのがこの記事でいちばん持ち帰ってほしいことです。そのとき、番号の引き算をしないことだけ忘れないでください。

よくある疑問

stable にすると、新機能はどれくらい遅れて届きますか

公式の説明は「典型的には約1週間前の版」です。私が2026年9月24日に測った実測では7日22時間55分でしたので、説明と実測はおおむね一致しています。ただし前述のとおり、これは1点のスナップショットです。大きな退行を含むリリースを飛ばす仕組みである以上、飛ばす対象が出れば差は広がりますし、出なければ縮みます。固定の日数として期待できるものではありません。

今すぐ最新の修正だけ受け取りたいときは

線の選択とは別に、claude update で手動更新できます。バックグラウンドの確認を待たずに、その時点で選んでいる線の最新版が適用されます。線が stable のままなら、届くのは stable の最新版です——手動更新は線を越えません。latest の最新版が欲しい場合は、線そのものを切り替える必要があります。

チーム全員で線を揃えたいときは

managed settings（管理者設定）で組織全体に線を強制できます。公式ドキュメントには、ユーザー設定やプロジェクト設定では上書きできないと明記されています。minimumVersion も同様に、管理者設定で組織共通の下限として効かせられます。

ただし注意点があります。Homebrew や Linux のパッケージマネージャで入れた環境は、設定ではなく cask 名やリポジトリURLで線が決まります。設定で揃えたつもりでも、入れ方が違うメンバーの環境は揃いません。チームで揃える場合は、設定を配る前に入れ方を揃えるほうが先です。

Homebrew は自動更新しないそうですが、放置するとどうなりますか

公式ドキュメントによれば、Homebrew・WinGet・apt・dnf・apk のインストールは既定では自動更新しません。つまり brew upgrade などを実行するまで、版は止まったままです。stable 側に乗っているうえに手動更新もしなければ、差は「約1週間」では収まらず、放置した期間ぶん開き続けます。

なお Homebrew と WinGet については、CLAUDE_CODE_PACKAGE_MANAGER_AUTO_UPDATE を 1 に設定することで、Claude Code 側がアップグレードコマンドを代わりに実行する挙動を有効にできます。apt・dnf・apk は管理者権限が必要なため、引き続き手動での更新が必要だと明記されています。

関連記事

入れ方そのものを確認したい場合は、6通りのインストール方法を手順つきでまとめたこちらが参考になります。

Claude CodeClaude Codeのインストール方法【2026年版】全6通り完全ガイド

autoUpdatesChannel を含め、設定ファイルに何をどう書くかは別途まとめています。

Claude CodeClaude Code settings.jsonの書き方｜settings.local.jsonとの違いと実務設定例

更新を受け取ったあと、変更履歴のどこを読むかについてはこちらで扱っています。この記事が「いつ届くか」の話なのに対し、そちらは「届いたものの何を読むか」の話です。

Claude CodeClaude Code更新履歴の読み方｜新機能より「直った」欄

まとめ

更新は降ってくるものだと思っていました。実際には、降り方は最初から2種類あって、何も選ばなければ入れ方に応じたどちらかに乗ります。latest に乗る人もいれば、Homebrew や Linux のパッケージマネージャで入れた人のように、選んだ覚えがないまま stable に乗っている人もいます。

要点を3つにまとめます。

• 線は2本ある。stable は「約1週間前・大きな退行を飛ばす」であって、安全を約束するものではない
• 既定は1つではない。ネイティブと npm は latest、Homebrew と apt/dnf/apk は公式手順のまま入れると stable 側に乗る
• 差は自分で測れる。2026年9月24日時点では7版・7日22時間55分・583項目ぶん開いており、その6割以上は修正だった

選ばないことの問題は、速い線に乗ることではありません。何かが変わったときに、それが自分の選択の結果なのかどうかが分からなくなることです。今日のうちに一度だけ確かめて、意識的に選び直しておけば、次に「昨日まで動いていたのに」と思ったとき、原因の切り分けが一つ減ります。

株式会社Fyveでは、こうした更新の扱いを含めて、無人で動かす仕組みをどう設計し、どう運用するかをご支援しています。

本記事の数値は2026年9月24日に、npm の配布記録（dist-tags および各版の公開時刻）と公開 CHANGELOG、および Claude Code 公式ドキュメント「Configure release channel」を突き合わせて私が集計したものです。配布記録は随時更新されるため、最新の状況はご自身の環境でご確認ください。