誰もデプロイしていない朝に、管理画面のボタンが効かなくなる。
原因を追うと、自社が書いたコードは1行も変わっていません。変わったのは、画面が読み込んでいる外部のライブラリのほうです。バージョンを指定せずに読み込んでいたため、提供側が新しい版を出した時点で、実行される中身が入れ替わっていた。
この種の事故を避けるために、8月末に出たあるリリースが実際に取った判断が参考になります。
htmx 4.0 は、あえて「latest」にならなかった
htmx 4.0.0 が2026年8月28日にリリースされました。8ヶ月の開発期間を経たメジャーバージョンで、内部実装が XMLHttpRequest から fetch() に移りました。ReadableStream を使えるようになったことで、サーバーから届いた断片を到着した順に描画する、いわゆるHTMLストリーミングが可能になっています。14KB 程度のライブラリでそれができる、というのが今回の目玉です。
破壊的な変更もあります。最も大きいのが属性の継承です。これまで hx-target などは暗黙に子要素へ継承されていましたが、4.0 では既定で継承されなくなり、継承させたい場合は hx-target:inherited="#div" のように明示します。子要素が理由の分からない影響を受ける、という従来の分かりにくさを解消するための変更です。
ほかに、イベント名が htmx:フェーズ:動作 の形に整理され、履歴の扱いが localStorage 依存をやめて戻る操作時に再取得する方式になり、morph によるスワップが標準で入り、<hx-partial> タグが追加されました。
そのうえで、npm の latest タグは 2.x のまま据え置かれています。 4.0 系は next として配布され、2027年の初頭まではこの状態を続ける予定です。htmx 2 は無期限にサポートすると明言されています。
理由は明快です。バージョンを指定しないCDNのURLで htmx を読み込んでいるサイトを、強制的に更新させないためです。
「勝手に上がる」構成になっていないか
ここが、htmx を使っていない会社にも関係する部分です。
外部のスクリプトをCDNから読み込むとき、URLの書き方は2通りあります。
<!-- バージョンを固定している -->
<script src="https://cdn.example.com/[email protected]/lib.min.js"></script>
<!-- バージョンを指定していない -->
<script src="https://cdn.example.com/lib/lib.min.js"></script>下の書き方をしている場合、自社のデプロイとは無関係に、実行される中身が変わります。package-lock も、リリース作業も、確認のテストも経由しません。提供側が新しい版を latest に置いた瞬間に、全ユーザーの画面で新しいコードが動きます。
htmx の開発チームは、まさにこの構成のサイトを壊さないために latest を動かさない判断をしました。逆に言えば、提供側がそこまで気を遣ってくれる保証はないということでもあります。
そして、勝手に変わるのは機能だけではありません。第三者のスクリプトが差し替えられ、悪意のあるコードが配信された事例が実際にあります。polyfill.io の件がそれで、あのとき影響を受けたのは、バージョンを指定せずに読み込んでいたサイトでした。
自社が何を読んでいるかを確認する
作業としては15分程度で終わります。
- 自社サイトの主要なページをブラウザで開き、ページのソースを表示する。
<script src=と<link href=の行を拾い、自社ドメイン以外のものを書き出す。- そのURLにバージョン番号が入っているかを見る。
@latest、/dist/、/v1/のようにバージョンが曖昧なものは、書き出しておきます。 - 書き出したものについて、それが何のために読み込まれているかを確認する。 過去のキャンペーンで入れた計測タグが残っているだけ、という場合が珍しくありません。
3 で該当したものが、提供側の判断ひとつで中身が変わりうる箇所です。4 で用途が分からないものは、そもそも外せる候補です。
固定すればいい、という話でもない
バージョンを固定すると、今度は脆弱性の修正が自動では届かなくなります。固定は、更新を止める判断ではなく、更新のタイミングを自分で決める判断です。決めた側が、決めた責任を負います。
そのため、固定とセットで必要になるのが「誰がいつ更新するか」の取り決めです。外部に開発・保守を委託しているなら、保守契約の範囲にライブラリの更新確認が入っているかを見てください。入っていない契約は珍しくありません。入っていない場合、固定したまま何年も放置される構成になります。
依存パッケージをそもそも増やさないという判断もあります。機能ひとつのために依存を1つ足す前に考えることは、この文脈と地続きです。
htmx 4 を今から使うかどうか
業務システムの管理画面や社内ツールのように、一覧とフォームが中心で、サーバー側でHTMLを組み立てている画面では、htmx のような部分更新の仕組みは選択肢に入ります。React などを持ち込むより、コード量も学習範囲も小さく収まります。
一方、図形編集や表計算のようにクライアント側の状態が複雑に絡む画面、オフライン動作が要件の画面では、状態管理を持つフレームワークを選びます。この線引き自体は、フレームワークを選び直すときの判断と同じです。
ただし、すでに htmx 2 で動いているシステムを今すぐ 4 に上げる理由は薄いです。2 は無期限にサポートされ、npm の既定も 2 のままです。上げる場合には、2.x からの移行を確認するCLIツールと、4 の上で 2 の既定値やイベント名を復元する htmx-2-compat 拡張が用意されているので、段階的に進められます。
つまずきやすいところ
「メジャーバージョンが出た＝上げなければならない」ではありません。 今回のように、提供側が旧系統を既定に据え置いているケースもあります。上げる判断は、得られるものと確認の手間を並べてから決めてください。
確認の対象を、自社が書いたコードに限定しないでください。 埋め込みのチャット、フォーム、計測タグ、フォントの読み込み。これらはたいてい制作時に入れたまま、誰も触っていません。動いているものほど、確認されません。
次にやること
自社の公開サイトと社内システムについて、外部から読み込んでいるスクリプトの一覧を出してください。バージョンが書かれていないURLが1つでもあれば、そこは自社の管理外です。
一覧が出たら、それぞれについて「必要か」「バージョンを固定するか」「誰が更新を見るか」の3つを決めてください。決まっていない項目が残ったまま次のリリースを迎えると、冒頭のような朝が来ます。
外部依存の棚卸し、フロントエンドの構成の見直し、保守の範囲にライブラリ更新を組み込む設計については、グリームハブの開発・AI・自動化のご相談で承っています。現在の構成と運用体制によって進め方が変わるため、お問い合わせからご相談ください。
