ファイル名の content hash とは何か? アセットのフィンガープリント

ファイル名の content hash は、ファイルコンテンツから導かれる短いフィンガープリントで、コンテンツが変わった場合に限りファイル名が変わります。

ビルド出力フォルダで main.8a3f21.js のようなファイル名を見たことがあるでしょう。その 16 進文字列は content hash、つまり名前に焼き込まれたファイルコンテンツのフィンガープリントです。これはキャッシュバスティングと効率的な CDN キャッシュの背後にある仕組みであり、ビルドが自動的に計算します。これを理解すると、デプロイがなぜ変わったファイルだけを正確に無効化するのかがわかります。

ハッシュの計算方法

ビルドはファイルコンテンツに対してハッシュ関数を実行し、その結果の一部をファイル名に埋め込みます。同一のコンテンツは同じハッシュになり、どれほど小さな変更でも異なるハッシュを生みます。

長期キャッシュを可能にする理由

名前がコンテンツを一意に反映するため、ハッシュ付きアセットは事実上永久にキャッシュできます。もしコンテンツが変われば、ファイル名も変わるので、ユーザーは古いキャッシュではなく新しいファイルを自然に取得します。

精密な無効化

コンテンツが変わったファイルだけが新しいハッシュを得ます。
変わっていないファイルは名前を保ち、キャッシュされたままになります。
デプロイは最小限のアセットセットだけを無効化します。

ハッシュの安定性が重要

理想的にはハッシュはコンテンツだけに依存すべきで、無関係な変更がすべてのファイル名を組み替えないようにします。ビルドツールは、たとえばモジュール ID を分離することでハッシュを安定に保とうとし、vendor chunk がデプロイをまたいでキャッシュを保てるようにします。

CI/CD における content hash

ビルドがハッシュを計算し、deploy が生成されたファイルをアップロードします。同じコンテンツが同じハッシュを生むため、再現可能なビルドは CI 実行をまたいで安定したファイル名を生み、それが CDN にアセットを積極的にキャッシュさせ、デプロイが変わった分だけに触れることを可能にします。

重要なポイント

content hash は、ファイルコンテンツをファイル名にフィンガープリントとして刻みます。
アセットを永久にキャッシュしつつ、コンテンツが変わったときだけ名前を変えられます。
再現可能な CI ビルドはハッシュを安定させ、精密なキャッシュ無効化を可能にします。