はじめに
Railsアプリ開発において、画像・CSS・JavaScriptといった「アセット」の管理は欠かせません。
しかしRailsの歴史を振り返ると、この仕組みは大きく揺れ動いてきました。
- Rails 3〜6：Sprockets がアセット管理の主役
- Rails 5.1〜6：フロントエンドのモダン化で Webpacker が登場
- Rails 7：Webpacker廃止、Importmap / JSBundling / CSSBundling に分割
- Rails 7.1〜8：シンプルさを重視した PropShaft がデフォルトに
この記事では、「そもそもPropShaftって何？」「どうやって使うの？」「Sprocketsと何が違うの？」 を入門向けに整理します。
Railsにおけるアセット管理の歴史をざっくり振り返る
まずは流れを理解しましょう。
Sprockets時代
.scssや.coffeeをトランスパイル可能- 巨大なgem依存（sass-rails、coffee-railsなど）
- 本番用にダイジェスト付きファイルを生成
長年の標準でしたが「重い」「依存が複雑」といった課題がありました。
Webpacker時代
- Node.js + WebpackをRailsに統合
- React/Vue/TypeScriptを使いやすくなった
- ただし設定が複雑化し、Rails本来のシンプルさが薄れる
Importmap / Bundling時代
- Rails 7で「JSを必ずしもビルドしなくていい」思想が強調
- importmap-rails でCDN読み込み
- jsbundling-rails / cssbundling-rails で外部ビルドツールを柔軟に利用
PropShaft登場
- Sprocketsの後継としてRails本体に統合
- 「静的ファイルの配信をシンプルに」 がテーマ
- ダイジェスト付きファイル名でキャッシュバスティング
- 余計なプリプロセッサ機能を廃止
PropShaftの特徴を整理
PropShaftは「Railsのための軽量な静的アセットパイプライン」です。
- SHAダイジェストでキャッシュ制御
logo-9fbc12.pngのようにファイル名にハッシュを埋め込み、キャッシュ破棄を保証します。 - マニフェスト方式
どの論理名がどのハッシュ付きファイルに対応するかをJSONマニフェストにまとめ、asset_pathなどで自動解決。 - 依存が極小
SassやCoffeeScriptのプリプロセッサはサポートせず、外部ツールと役割分担。 - Rails本体に統合
gemを追加せずともデフォルトで利用可能。
基本の使い方
新規アプリの例
Rails 7.1+ でアプリを作成すると、自動でPropShaftが使われます。
rails new blog --css=tailwind --javascript=esbuildアセットの配置
- CSS, JS:
app/assets - 画像:
app/assets/images - ビルド成果物は
public/assetsに置かれます
Viewでの呼び出し
<%= image_tag "logo.png" %>
<%= stylesheet_link_tag "application", "data-turbo-track": "reload" %>
<%= javascript_include_tag "application", defer: true %>呼び出し時に、自動でハッシュ付きのファイルパスに解決されます。
Sprocketsとの違いを表で理解
| 項目 | Sprockets | PropShaft |
|---|---|---|
| キャッシュ制御 | ダイジェスト付きファイル名 | SHAダイジェスト付きファイル名 |
| プリプロセッサ | SCSS/CoffeeScript対応 | 非対応（外部ツールへ移行） |
| 設定ファイル | manifest.js | JSONマニフェスト |
| エコシステム | 多数のgem/plugin | 軽量・Rails本体に統合 |
違いの核心は「責務の切り分け」
Sprocketsが担っていたプリプロセッサ機能を切り捨て、PropShaftは「静的アセット管理だけ」に集中しました。
移行で注意するポイント
既存プロジェクトでSprocketsを使っている場合は注意が必要です。
.scss→cssbundling-railsでSassをビルド.tsや.vue→jsbundling-rails（esbuildやViteなど）で処理- CoffeeScript → 廃止推奨（変換してJS化）
つまり、プリプロセッサはRails外のビルドツールに任せるのが基本方針になります。
カスタマイズ例
アセットパスを追加
# config/application.rb
config.assets.paths << Rails.root.join("vendor/assets")CDNと組み合わせ
<%= image_tag "logo.png", host: "https://cdn.example.com" %>独自マニフェスト
PropShaftのマニフェストはJSON形式なので、複数アプリやマイクロフロントエンドでの統合も比較的簡単にできます。
Rails 8におけるPropShaftの位置づけ
Rails 8の世界ではこう整理できます：
- 静的アセット配信：PropShaft
- CSSのビルド：cssbundling-rails（Tailwind, Sass, PostCSS）
- JSのビルド：jsbundling-rails（esbuild, rollup, webpack, Viteなど）
- ライブラリ直読み：importmap-rails
つまり、Railsは「自前でビルドを抱え込まず、シンプルなアセット配信に専念」する設計になりました。
まとめ
- PropShaftは Sprocketsの後継としてRails本体に統合されたアセットパイプライン。
- キャッシュバスティングはSHAダイジェスト方式で、仕組みがシンプル。
- プリプロセッサは非対応、外部ビルドツールとの併用が前提。
- Rails 8時代では PropShaft + Bundling系Gem + CDN が標準構成。
これから新規でRailsアプリを始めるならPropShaftはデフォルト。既存アプリを移行する場合は「プリプロセッサを外部化」してから取り入れるのが安全です。
コメント