rails assets:clobberとは？precompile・cleanとの違いとアセットパイプライン運用【Rails 8 Propshaft対応】

rails assets:clobber は、プリコンパイルで生成した public/assets 配下のファイルとマニフェストをまとめて削除するrakeタスクです。似た名前の assets:precompile（生成）や assets:clean（古い世代だけ整理）と混同すると、本番でアセットが丸ごと消える事故につながります。この記事では3つのコマンドの役割の違いと使い分け、実行タイミング、Rails 8で標準アセットパイプラインになったPropshaftでの挙動、そして「本番でアセットが表示されなくなった」ときの確認手順を、Sprockets／Propshaftの両方を前提に整理します。

まとめ：clobber・clean・precompileの要点

• clobber＝全削除：assets:clobber は出力先（public/assets）とマニフェストを丸ごと消す。作り直し用であって、単独では本番を復旧できない。
• clean＝世代整理：assets:clean は古い世代だけを残数を保って削除する（既定でSprocketsは最新3世代、Propshaftは最新2世代を保持）。ローリングデプロイ中の安全なクリーンアップはこちら。
• precompile＝生成：assets:precompile がdigest付きファイルと manifest.json を作る。clobberの後は必ずprecompileで作り直す。
• Rails 8（2024年11月）から新規アプリの既定はPropshaft。assets:clobber／clean／precompile はPropshaftでも同名で使えるが、内部の仕組みはSprocketsと大きく異なる。
• JavaScriptのバンドルは現在 importmap-rails／jsbundling-rails が担当し、旧Webpackerは2022年に開発終了。アセットパイプラインはCSS・画像・digest配信を担う役割に整理された。

rails assets:clobberの役割と削除される対象

assets:clobber は「プリコンパイル成果物を初期化する」ためのタスクです。ディスク節約が主目的ではなく、壊れた・古くなった生成物を一度まっさらにして作り直すために使います。

clobberが実際に削除するもの

削除対象はアセットの出力先ディレクトリ（既定で public/assets、設定上は config.assets.output_path）の中身と、そこに置かれたマニフェストファイルです。Sprockets環境では、これに加えて tmp/cache/assets のファイルシステムキャッシュもクリアされます。Propshaftのclobberは出力先ディレクトリの削除に絞られており、Sprocketsのような重いキャッシュを持たない設計です。

$ bin/rails assets:clobber
# public/assets 配下の生成物とマニフェストを削除
# Sprocketsではあわせて tmp/cache/assets のキャッシュも消える

実行コマンドと主な使いどころ

単に bin/rails assets:clobber を実行するだけで動きます。使うのは次のような「作り直したい」場面に限られます。

• プリコンパイル済みファイルのdigest（ハッシュ）が壊れ、ブラウザが古い参照を掴んでいるとき。
• アセットの内容を変えたのに反映されず、キャッシュ由来と切り分けたいとき。
• Sprockets→Propshaftの移行など、パイプライン自体を入れ替えて生成物をリセットしたいとき。

典型的には、clobberで消してからprecompileで作り直す2手をセットで実行します。

$ bin/rails assets:clobber
$ RAILS_ENV=production bin/rails assets:precompile
# 古いdigestを一掃し、最新のアセットとマニフェストを再生成する

本番でclobberを不用意に叩くと危険な理由

clobberは出力先を空にするため、実行した瞬間から次のprecompileが完了するまで、その環境にはアセットが1つも存在しません。稼働中のサーバーで直接叩くと、その隙間にアクセスしたユーザーにはCSS・JavaScriptが当たらない崩れたページが返ります。ローリングデプロイで新旧のリビジョンが同時に動いている最中にclobberすると、まだ旧アセットを参照している旧リビジョンのページも壊れます。本番の定常的なクリーンアップにclobberを使うべきではありません。世代を残して安全に消す assets:clean が本来の担当です。cron等でclobberを定期実行する運用は、崩れの温床になるため避けてください。

assets:clobber・clean・precompileの違いと使い分け

3つのタスクは名前が似ていますが、削除の範囲と安全性がまったく異なります。役割を取り違えないよう、動作と用途を一覧で押さえます。

本番のクリーンアップに使うのは基本 assets:clean

assets:clean は残す世代数を引数で指定でき、既定ではSprocketsが最新3世代、Propshaftが最新2世代を保持したまま、それより古い未参照の生成物だけを削除します。これはローリングデプロイを想定した挙動で、切り替え途中に旧リビジョンがまだ旧アセットを参照していても壊さないためのものです。SprocketsでもPropshaftでも同名の assets:clean が用意されていますが、既定の保持世代数が異なる点に注意してください。なお、Propshaftではdigest名付きアセットの取りこぼしが起きうるため、確実に作り直したい場面ではclobber→precompileを選ぶ運用が安全です。

# 既定（最新2世代を残す）
$ RAILS_ENV=production bin/rails assets:clean

# 残す世代数を明示（例: 5世代）
$ RAILS_ENV=production bin/rails assets:clean[5]

整理の頻度を上げてディスクを詰まらせたくないなら、まず assets:clean を検討し、clobberは「全部作り直したい」明確な理由があるときだけに限定するのが安全な線引きです。

rails assets:precompileの詳細と実行時の注意点

assets:precompile は、開発中のアセットを本番向けに変換・digest付与して出力するタスクです。デプロイ工程に組み込むのが基本で、rails assets:clobber の後始末としても必ず呼ぶことになります。

precompileが生成するもの

実行すると、対象アセットにコンテンツのハッシュ（フィンガープリント）を付けたファイルが public/assets に出力され、論理名と実ファイル名の対応表であるマニフェスト（Propshaftは .manifest.json、Sprocketsは .sprockets-manifest-*.json）が作られます。ビューの asset_path や stylesheet_link_tag は、このマニフェストを見てdigest付きのURLを埋め込みます。

$ RAILS_ENV=production bin/rails assets:precompile
# public/assets に digest付きファイルとマニフェストを生成
# 例: application-1a2b3c...d.css ／ application-9f8e...7.js

よく使う設定とオプション

特定のアセットを追加でプリコンパイル対象にするには config.assets.precompile に足します。エラー時は --trace でバックトレースを出すと原因を追いやすくなります。

# config/initializers/assets.rb
Rails.application.config.assets.precompile += %w( admin.js admin.css )

# 本番設定の要点（config/environments/production.rb・Sprockets構成）
config.assets.compile = false   # 本番はオンザフライ生成を無効化（プリコンパイル前提）

# エラー調査
$ RAILS_ENV=production bin/rails assets:precompile --trace

本番でアセットが反映されない時の確認ポイント

「デプロイしたのにCSSが当たらない」「404になる」といった不具合は、多くがprecompile回りの取りこぼしです。次の順で切り分けます。

• precompileが走ったか：デプロイ時に assets:precompile が実行され、public/assets にファイルが出ているか。
• compile設定：config.assets.compile = false のとき、マニフェストに載っていないアセットは404になる。追加アセットは precompile リストに入れる。
• 参照側：ビューで直リンクせず asset_path 系ヘルパーを使っているか（digestが付かないと参照が外れる）。
• キャッシュ・digestの不整合：作り直しが必要なら assets:clobber→assets:precompile で一掃する。

デプロイの仕組み自体を見直す場合は、Kamal 2とThrusterによる最新デプロイ構成の記事もあわせて参照してください。プリコンパイルと静的アセット配信をどこで行うかは、デプロイ設計と直結します。

アセットパイプラインの仕組み：SprocketsとPropshaft

コマンドの背後にあるのがアセットパイプラインです。ここを理解しておくと、clobber／precompileが「何を操作しているのか」がつながります。

アセットパイプラインの役割

アセットパイプラインは、CSS・JavaScript・画像などの静的ファイルにコンテンツハッシュ（フィンガープリント）を付け、本番で確実にキャッシュを効かせながら配信するための仕組みです。ファイル名にハッシュが入ることで、内容が変わればURLも変わり、古いキャッシュを掴み続ける問題（キャッシュバスティング）を防げます。precompile はこの変換・命名を一括で行う工程にあたります。

Sprocketsの仕組み

SprocketsはRails 7まで標準だったアセットパイプラインで、複数ファイルの結合、圧縮、SCSSなどのプリプロセス、依存関係の解決までを担っていました。//= require のようなディレクティブで依存を宣言し、それを解決して1つにまとめるのが特徴です。この依存スキャンと結合処理があるぶん、ファイル数の多い大規模アプリではプリコンパイルの所要時間がPropshaftより長くなりがちです。

Rails 8で既定になったPropshaftとの違い

Rails 8（2024年11月リリース）から、新規アプリの標準アセットパイプラインはPropshaftに切り替わりました。Propshaftは結合や依存スキャンを行わず、各ファイルにdigestを付けて配信することだけに役割を絞っています。JavaScriptのバンドルはimportmap-railsやjsbundling-rails、CSSはcssbundling-railsといった専用の仕組みに任せる前提のため、パイプライン本体が大幅に軽量・高速化されました。ディレクティブによる結合が無いぶん、読み込み順は開発者が明示的に管理します。

なお、旧記事や古い資料で見かけるWebpackerは2022年に公式の開発を終了しており、現在の新規構成では使いません。既存のRails 7以前のアプリはSprockets構成のまま assets:clobber／precompile を使い続けられますが、これからのアプリはPropshaft＋importmap／jsbundlingが標準線です。バージョン差の大きいテーマなので、対象アプリのRailsバージョンを確認してから設定を合わせてください。

public/assetsディレクトリと静的アセット配信の最適化

public/assets は、プリコンパイル済みのアセットが置かれ、Webサーバーやアプリから直接配信されるディレクトリです。ここの中身と配信設定が、静的アセットの表示速度を左右します。

public/assetsの中身とキャッシュバスティング

assets:precompile を実行すると、digest付きのファイルとマニフェストがこのディレクトリに出力されます。ファイル名のハッシュ部分が内容に応じて変わるため、更新時にブラウザが確実に新しいファイルを取りに行きます。中身を確認したいときは、Propshaftなら assets:reveal タスクで論理名と実パスの対応を一覧できます。

$ ls public/assets
application-1a2b3c4d5e.css
application-9f8e7d6c5b.js

# Propshaft: 論理名→digestパスの対応を確認
$ bin/rails assets:reveal

CDN・圧縮・長期キャッシュの設定

digest付きのアセットは内容が変わればURLも変わるため、長期キャッシュ（Cache-Control: public, max-age を長く）と相性が良い設計です。配信は次のような手段で最適化します。

• CDN：config.action_controller.asset_host にCDNのホストを指定し、エッジから配信する。
• 事前圧縮：gzip／brotliで圧縮済みファイルを用意し、Webサーバーで配信する。
• アプリ層での配信：Rails 8標準のThrusterは、X-Sendfileによる効率的な静的ファイル配信とアセットキャッシュ、圧縮をアプリ前段で担います。

「どこで静的アセットを配るか」はデプロイ構成そのものなので、precompileのタイミングとあわせて設計するのが要点です。

よくある質問

assets:clobberとassets:cleanの違いは何ですか？

clobberは出力先（public/assets）とマニフェストを丸ごと削除し、Sprocketsではキャッシュも消します。cleanは古い世代だけを残数を保って削除し（既定でSprocketsは最新3世代、Propshaftは最新2世代を保持）、ローリングデプロイ中でも壊れないよう配慮された安全なタスクです。本番の定期整理はclean、全作り直しはclobberと使い分けます。

rails assets:clobberでアセットを消したら元に戻せますか？

clobberはソースを消すわけではなく、生成物を消すだけです。assets:precompile を実行し直せば、元のソースから同じアセットとマニフェストが再生成されます。ただし再生成が終わるまで本番にはアセットが無い状態になるため、稼働中サーバーで直接叩くのは避けてください。

本番でassets:precompileしたのにCSSが反映されません。

まず public/assets にファイルが生成されているかを確認します。次に config.assets.compile = false の場合、precompileリストに載っていないアセットは404になるため、config.assets.precompile への追加漏れを疑います。ビュー側が asset_path 系ヘルパーを使わず直リンクしていると、digestが付かず参照が外れます。digestの不整合なら assets:clobber→assets:precompile で作り直します。

Rails 8でもSprocketsは使えますか？

使えます。Rails 8で既定がPropshaftに変わっただけで、Sprockets（sprockets-rails）をGemfileに指定すれば従来どおり動きます。既存アプリを無理にPropshaftへ移す必要はありませんが、新規アプリはPropshaft＋importmap／jsbundlingが標準です。

assets:clobberは自動で実行されますか？

いいえ。デプロイ時に自動で走るのは通常 assets:precompile で、clobberは自動実行されません。cron等で定期的にclobberを走らせる運用は、実行直後にアセットが空になり崩れの原因になるため推奨されません。世代整理が目的なら assets:clean を使ってください。

関連記事

• Railsジェネレータ（rails generate）の使い方｜モデル・scaffold・カスタム生成まで
• Kamal 2とThrusterを使用した最新デプロイメントの進化
• Rails APIとは？作成手順・JWT認証・React連携・Docker環境を実装解説【Rails 8.1】
• ruby on rails を vscode で開発する環境構築【2026年版】拡張機能・デバッグ・Dev Container