朝のコーヒーを淹れながら、ターミナルで claude --version を打つのが癖になっていた時期があります。昨日と同じ番号の日もあれば、二つ進んでいる日もあって、そのたびに「今日は更新内容を読むべきか」と手が止まりました。
感覚で迷い続けるのをやめたくて、公開履歴そのものを数えてみました。ここでお伝えするのは、2026 年 11 月 6 日の朝に npm のレジストリから取り出した数字と、そこから私が引いた線引きです。
最初にお伝えしたいのは、更新を追う頻度は、気分ではなく公開間隔の実測から決めるということです。
数えた結果を先に置きます
対象は npm の @anthropic-ai/claude-code です。直近 28 日（10 月 9 日〜11 月 6 日）の数字は次のとおりでした。
| 項目 | 値 |
|---|---|
| 公開された版 | 21 本（週あたり約 5.2 本） |
| 公開の間隔（中央値） | 約 23 時間 |
| いちばん短い間隔 | 約 3.6 時間 |
| いちばん長い間隔 | 約 103 時間（4 日強） |
dist-tag latest の後ろにある版 | 1 本 |
dist-tag stable の後ろにある版 | 7 本 |
「ほぼ毎日、何かが出ている」のは実感どおりでした。一方で、4 日以上あく週末のような谷もあります。毎朝確かめても、半分近い朝は変化がないか、小さな修正が一つ増えているだけでした。
なお、2.1.0 から 2.1.319 までは番号が 320 個あるのに、公開されているのは 275 本です。版番号が飛ぶことがあるため、番号の引き算で「何本遅れているか」を出すのは避け、公開履歴の本数で数えるようにしています。この点は安定版の Claude Code には、二度の既定モデル交代がまだ届いていませんでも触れました。
数えたスクリプト
標準ライブラリだけで動きます。公開時刻の順に並べ直すのが要点です。
import json
import urllib.request
import datetime as dt
from statistics import median
URL = "https://registry.npmjs.org/@anthropic-ai/claude-code"
DAYS = 28
with urllib.request.urlopen(URL, timeout=30) as r:
meta = json.load(r)
times = meta["time"]
since = dt.datetime.now(dt.timezone.utc) - dt.timedelta(days=DAYS)
# 公開時刻の昇順に並べる（版番号ではなく実際の公開順）
releases = sorted(
(dt.datetime.fromisoformat(times[v].replace("Z", "+00:00")), v)
for v in meta["versions"]
if v in times and "-" not in v # プレリリース表記を除く
)
recent = [(t, v) for t, v in releases if t >= since]
gaps_h = [
(b[0] - a[0]).total_seconds() / 3600
for a, b in zip(recent, recent[1:])
]
print(f"直近{DAYS}日の公開: {len(recent)}本 / 週あたり {len(recent) / DAYS * 7:.1f}本")
print(f"間隔の中央値: {median(gaps_h):.1f}時間 / 最短 {min(gaps_h):.1f} / 最長 {max(gaps_h):.1f}")
for tag, ver in meta["dist-tags"].items():
ts = dt.datetime.fromisoformat(times[ver].replace("Z", "+00:00"))
behind = sum(1 for t, v in releases if t > ts)
print(f"{tag:7s} {ver:9s} 公開済みの新しい版が {behind}本")time に載っていない版を除く条件を入れたのは、メタデータに公開時刻のない版が混ざっていても落ちないようにするためです。実行すると、上の表と同じ形の三行が出ます。
数えて気づいた三つのこと
一つ目は、中央値が 1 日弱でも、最長は 4 日強だったことです。「毎日更新される」と思い込んで毎朝見ていると、谷の日が空振りになります。
二つ目は、latest は 1 本後ろ、stable は 7 本後ろと、同じ「出ている」でも距離がかなり違うことでした。どのチャンネルを追うかで、同じ日に手元に届く内容は変わります。
三つ目は、数字を見る前の私が、更新の頻度を「多すぎて追えない」と感じていた一方、実際は週 5 本ほどで、週に一度まとめて読めば足りる量だったことです。胃が痛くなるような量ではありませんでした。
私の線引き
数字を見て、次のように決めました。
- 普段は自動更新に任せて、更新内容は週に一度、週明けの朝にまとめて読みます。
- 納期の近い作業の前だけ、バージョンを固定するかどうかを考えます。
- 作業中に挙動が変わったと感じたら、その日のうちに直前の版との差を読みます。
自動更新が思わぬ形で止まる場合の切り分けは、Claude Code の自動アップデートが効かない時の診断手順に、共有ホームで実行中のバイナリが消える事例は共有ホームで Claude Code が Bus error で落ちるときに書き残しました。
個人開発の現場で、この線引きが効いた場面
私はアプリの審査提出の前後に、Claude Code でビルド設定や多言語の文言をまとめて直すことがあります。提出前の数日は、手元の道具が毎日少しずつ変わっていると、不具合が出たときに「自分の変更か、道具の変更か」を切り分けられず、手が止まります。
そこで、提出の山を迎える週は、週明けに版を確かめたら、その週は新しい版を取り込まない日を決めておく運用にしました。公開間隔の最長が 4 日強と分かっていたので、「4 日待っても取りこぼしは大きくない」と判断する根拠になりました。数字がなければ、固定するのが怖くて、毎朝落ち着かなかったかもしれません。
窓の取り方で見え方が変わります
28 日という長さは、私が選んだ窓にすぎません。14 日にすれば、大きな機能追加の直後に公開が詰まった週が目立ち、90 日にすれば、均した週 5 本前後に落ち着いていきます。
どの長さが正しいというわけではなく、自分が更新を読む周期の 2〜3 倍の窓で数えると、判断に使いやすいと感じています。週に一度読む人なら、2〜3 週間が目安です。
次にやることは一つです
上のスクリプトを手元で一度だけ動かし、ご自身の窓の数字を見てみてください。28 日を 14 日に変えるだけでも、季節による揺れが見えます。
更新の追い方は、数字をひとつ持つだけで、ずいぶん静かになります。この習慣だけは、これからも守るようにしています。