Laravelのキャッシュクリア｜cache:clearとoptimize:clearの違いと本番デプロイの手順

Laravelで「変更が反映されない」ときに打つコマンドは、実のところ用途の異なる2系統に分かれています。ひとつは自分がコードから書き込んだデータを消すもの、もうひとつはフレームワークが起動を速くするために吐き出した生成物を消すもの。この2つを混ぜたままoptimize:clearを常用すると、開発中は問題なく回るのに本番でだけ想定外の副作用が出ます。ここでは各コマンドが実際に何を消すのかを13.x系のソースと公式ドキュメントで確かめたうえで、デプロイ手順に組み込むときの順序と、打ってはいけない場面の線引きまで整理します。版によって挙動が変わる部分があるため、手元のアプリのLaravelのバージョンを先に確認する手順も併せて押さえてください。

まとめ：どのコマンドが何を消すかと本番で打つ順序

先に結論から並べます。以下の記述は2026年8月29日時点の13.x系のソースコードと公式ドキュメントで確認した内容です。

• キャッシュはアプリケーションキャッシュ（Cacheファサードで読み書きした値）と起動用の生成物（設定・イベント・ルート・ビュー）の2系統に分かれる
• cache:clearが触るのは前者だけ。config:clear・event:clear・route:clear・view:clearが触るのは後者だけ
• optimize:clearは6つのコマンドをまとめて回す。その2番目にcache:clearが入っているため、アプリが保持していたデータまで消える
• 本番のデプロイ手順に置くのはoptimize:clearではなくoptimize。生成物は消すのではなく新しい内容で上書きするほうが、無キャッシュ状態の時間が生まれない
• config:cacheを実行した後は環境変数ファイルが読まれなくなり、設定ファイルの外で呼んだenv()はすべてnullを返す
• キャッシュを空にする操作はプレフィックスを無視して全件を消すため、Redisを他システムと共有している構成では影響範囲がアプリの外へ広がる
• キューワーカーやOctaneのような常駐プロセスは、キャッシュを消しただけでは古いコードのまま動き続ける

Laravelのキャッシュは2系統｜消したい対象を先に切り分ける

コマンドを覚える前に、何が溜まっているのかを分けて捉えておくと迷いが減ります。同じ「キャッシュ」という語で呼ばれていても、生成する主体も、消えたときの影響範囲も別物だからです。

アプリケーションキャッシュは自分で書き込んだ値を保管しておく置き場所

ひとつめは、コードから明示的に書き込んだ値の層です。集計結果を数分だけ保持する、外部APIの応答を使い回す、レート制限のカウンタを持つ、といった用途でCache::putやCache::rememberが書き込んだデータがここに入ります。保存先は設定ディレクトリのcache.phpで選んだストアで、13.x系の雛形ではdatabaseドライバが既定です。直列化した値をアプリのデータベースへ格納する構成なので、テーブルが1つ増えている点を見落とさないでください。

この層は業務データに近い性質を持ちます。消せばアプリは動きますが、消えた瞬間にキャッシュを前提にしていた処理が一斉に元データへ取りに行くため、負荷の波が立ちます。本番で軽い気持ちで空にしてよい対象ではありません。

設定とルートとビューは起動時間を短縮するために作られる専用の生成物

ふたつめは、フレームワークが毎リクエストの手間を減らすために事前に吐き出しておくファイル群です。設定ファイル群を1つに結合したもの、ルート定義をまとめたもの、Bladeをコンパイルした結果、イベントとリスナの対応表の4種類があり、いずれも元になるソースコードから再生成できます。中身はコードの写しであってデータではないため、消しても失われる情報はありません。

ここが先ほどの層と決定的に違う点です。生成物のほうは「消して困るのは速度だけ」で済みますが、アプリケーションキャッシュのほうは消すと値そのものが失われます。同じclearという語感でも、リスクの水準がまったく違うわけです。

反映されないときは症状から原因となるキャッシュの系統を逆算する

症状から系統を逆算すると、打つべきコマンドはほぼ一意に決まります。設定ファイルを書き換えたのに古い値が使われるなら設定の結合ファイル、ルートを足したのに404になるならルートの結合ファイル、Bladeを直したのに表示が変わらないならコンパイル済みビュー。いずれにも当てはまらず、画面に出る数値だけが古いなら、それはアプリケーションキャッシュに残った値です。手当たり次第に全部消すより、どれが原因かを言い当てるほうが本番での事故は減ります。

なお、画面が変わらない原因がJavaScriptやCSSの側にあるケースも珍しくありません。フロント資産のビルド結果はartisanのキャッシュとは別系統で管理されているため、Laravel Viteでの本番ビルドの扱いを先に確かめたほうが早い場合があります。

clear系5コマンドが実際に消す対象と再生成のされ方の違い

ここからは個別のコマンドを、13.x系のソースで確認した実挙動として見ていきます。artisanのコマンド体系そのものについてはphp artisanの生成系コマンド一覧も参照してください。

cache:clearは既定ストアを空にして中間ファイルも削除する

php artisan cache:clearは、引数を省略すると既定ストアに対して全件削除を実行します。引数にストア名を渡せば対象を絞れますし、--tagsでタグを指定した部分削除、--locksでロックだけの解放も可能です。実行の前後でcache:clearingとcache:clearedという2つのイベントが発火するため、削除を監査ログに残したい場合はここにリスナを差し込めます。

見落とされやすいのが、ストアの削除に加えてフレームワーク用ディレクトリからファサード向けの中間ファイルを消している点です。リアルタイムファサードを使っていると、この中間ファイルが実体を持ちます。ストアの中身だけが対象だと思っていると、ファイルの再生成が走るタイミングを見誤ります。

config:clearとroute:clearは結合ファイルを消して都度読みに戻す

config:clearとroute:clearは、それぞれconfig:cache・route:cacheが生成した結合ファイルを削除するだけのコマンドです。削除後はキャッシュが無い状態、つまり毎リクエストで設定ファイルを読み直し、ルートを登録し直す動作に戻ります。開発環境の既定はこの状態なので、ローカルでconfig:clearを打っても体感は変わりません。

逆に言えば、本番でconfig:clearだけを打って放置すると、キャッシュを前提に組んだ設定が読めるようになる代わりに、起動のたびに全設定ファイルを走査する状態が続きます。緊急の切り分けとしては有効でも、そのまま運用するものではありません。

view:clearとevent:clearを個別に打つのはどんな場面か

view:clearはコンパイル済みのBladeを削除するコマンドです。テンプレートを書き換えたのに反映されないケースのほか、コンパイル結果が壊れて画面が白くなった場合の復旧にも使います。event:clearはイベントとリスナの対応表を消し、起動時の自動探索へ戻すコマンドで、リスナを足したのに発火しないときの確認に向きます。

どちらもデータを失わない安全な操作なので、本番で単独実行しても副作用はほとんどありません。原因の系統が絞れているときは、全部を巻き込むコマンドではなくこちらを選んでください。

optimizeとoptimize:clearが回すコマンドを13系ソースで確認する

この2つは複数のコマンドをまとめて実行する司令塔です。中身を知らないまま使うと、意図した以上のものを消してしまいます。

optimizeはconfigからviewまで4つを順に生成していく

php artisan optimizeが回すのは、config:cache・event:cache・route:cache・view:cacheの4つで、この順序で実行されます。加えて、サービスプロバイダの静的プロパティに登録されたコマンドがあれば末尾に続きます。特定のタスクだけ外したい場合は--exceptにキー名かコマンド名をカンマ区切りで渡してください。ルート定義に不安がある構成なら、routesだけ外すといった運用ができます。

そのルート定義の扱いについて補足すると、13.x系のソースではルートの直列化処理がクロージャを直列化可能な形へ包む実装になっています。「クロージャのルートがあるとroute:cacheは必ず失敗する」という古い前提で書かれた解説が今も多く残っていますが、手元の版で実際に通るかどうかを確かめてから判断してください。

optimize:clearの2番目にcache:clearが入っている事実

一方のoptimize:clearが回すのは6つです。config:clear、cache:clear、clear-compiled、event:clear、route:clear、view:clearの順で、公式ドキュメントも「optimizeが生成したキャッシュファイルすべてと、既定キャッシュドライバの全キーを消す」と明記しています。

つまり、名前から受ける「optimizeの取り消し」という印象とは裏腹に、optimizeが触っていないアプリケーションキャッシュまで巻き込む設計です。日本語の解説記事では「困ったらoptimize:clear」と案内されることが多いのですが、その一言が本番では集計結果の全消去やレート制限カウンタのリセットを意味します。3番目のclear-compiledもパッケージ検出とサービスプロバイダ解決の結果を捨てるコマンドで、次の起動時に再解決が走ります。

パッケージが自前のタスクを差し込める登録の仕組みまで押さえる

optimize系は拡張可能な作りになっており、サービスプロバイダの静的プロパティに「説明文とコマンド名」の組を登録すると、パッケージ側の生成タスクをこの一括実行へ相乗りさせられます。導入しているパッケージによっては、自分が書いた覚えのないコマンドがoptimizeの中で走っているわけです。実行ログに見慣れない行が出たときは、まずここを疑ってください。

本番デプロイにはclearではなくcacheで上書きする形で組み込む

ここからが運用の話です。コマンドの意味が分かっていても、どの順序でデプロイ手順に置くかを外すと、リリースのたびに数秒から数十秒の劣化が発生します。

デプロイ手順ではコード反映を終えてから起動用キャッシュを生成する

基本の並びは、依存関係の解決、データベースの移行、キャッシュの生成、常駐プロセスの再起動です。生成物は新しいコードを読んで作られるので、コードが入れ替わる前に走らせても意味がありません。

composer install --no-dev --optimize-autoloader
php artisan migrate --force
php artisan optimize
php artisan reload

要点は3行目でoptimize:clearを使っていないことです。optimizeは既存の結合ファイルを新しい内容で上書きするため、キャッシュが存在しない時間帯が生まれません。先に消してから作る手順にすると、その隙間に来たリクエストが無キャッシュ状態のアプリに当たります。台数が多い環境ほどこの差は効いてきます。

config:cacheの後はenv関数の戻り値がnullになる

設定を結合ファイルにまとめると、起動時に環境変数ファイルが読み込まれなくなります。結果として、設定ファイル以外の場所で呼んだenv()はすべてnullを返す仕様。コントローラやサービスクラスで直接env()を呼んでいる箇所があると、ローカルでは動いていた処理が本番でだけ静かに壊れます。

対処は単純で、環境変数の参照は設定ファイルの中だけに閉じ、アプリ側はconfig()経由で読む形へ寄せることです。この制約はconfig:cacheを入れた瞬間に顕在化するので、キャッシュ導入とセットで既存コードを一度洗い出しておくと安全に移行できます。

常駐プロセスはキャッシュを消しても古い定義を読み込んだまま動く

キューワーカーやOctane、Reverbのような長時間動き続けるプロセスは、起動時に読み込んだコードと設定をメモリに抱えたままです。ファイルを消しても、すでに起動しているプロセスの中身は入れ替わりません。13.x系にはこれらをまとめて終了させるphp artisan reloadが用意されているので、デプロイの最後に必ず置いてください。プロセス監視の仕組み側が終了を検知して起動し直す構成が前提になります。

反映されない原因がOPcacheのときはartisanでは消せない

ここまでのコマンドを全部打っても古い挙動が残る場合、PHP側のバイトコードキャッシュが疑わしくなります。OPcacheはPHPの実行エンジンが持つ仕組みで、Laravelのartisanコマンドの管轄外。プロセスマネージャの再読み込みや、専用のリセット処理を通さないと入れ替わりません。「キャッシュクリアを全部試したのに直らない」という相談の相当数がこの切り分け漏れです。デプロイ手順の設計や本番運用の体制づくりで手が足りないときは、保守運用・内製化支援のサービスもご相談ください。

キャッシュドライバの選択によってクリア時の副作用の範囲が決まる

同じcache:clearでも、どのドライバを選んでいるかで消える範囲が変わります。ここを設計段階で決めておくと、運用フェーズの判断がぶれません。

13系の既定はdatabaseでflushはテーブルを空にする

13.x系の雛形が既定に据えているのはdatabaseドライバで、直列化した値をアプリのデータベースへ書き込みます。この構成での全件削除は、キャッシュ用テーブルの中身を落とす操作。アプリのデータベースに対する書き込み負荷が発生する点と、削除直後にキャッシュを埋め直すクエリが集中する点の両方を見込んでおいてください。トラフィックの多い時間帯に打つ操作ではありません。

共有Redisではアプリのプレフィックスを越えて全件が消える場合がある

Redisやmemcachedを選んでいる場合、公式ドキュメントは「キャッシュを空にする操作は設定したプレフィックスを尊重せず、すべてのエントリを削除する」と明記しています。つまり、同じRedisを別のアプリやセッションの保存先と共有している構成では、自分のアプリのキー空間だけを消したつもりが全体に及びます。

実務では、キャッシュ用の接続とセッション用の接続を別のデータベース番号へ分けるのが最初の防御になります。セッションの保存先をどう選ぶかを設計時に決めておくと、この事故は構造的に避けられます。逆にすでに共有してしまっている環境では、全件削除ではなくキー単位の削除で運用するほうが安全です。

Laravel側のセッション設定とドライバ選定はLaravelのセッション管理｜ドライバ選定とCSRF・複数台構成の共有設計で扱っています。

タグによる部分削除機能は対応しているキャッシュドライバに限られる

タグを付けて関連するキーだけをまとめて消す機能は便利ですが、対応していないドライバがあります。公式ドキュメントによれば、file・dynamodb・database・storageの4つではタグが使えません。既定のdatabaseが含まれている点に注意が必要です。

部分削除を運用の前提に置くなら、ドライバ選定の段階でRedisかmemcachedを選ぶ必要があります。あとから「タグで消したい」と思っても、ドライバごと入れ替える判断になるためです。

optimize:clearを本番で打ってよい条件と見送る場面

ここが本記事の結論です。optimize:clearを本番環境で打ってよいのは、次の3つが同時に成り立つときに限ると考えてください。

1つめは、アプリケーションキャッシュに失われて困る値が入っていないこと。キャッシュを純粋な高速化の手段としてのみ使い、消えても元データから再構築できる設計になっている場合です。2つめは、キャッシュストアが他システムと共有されていないこと。専用のRedisデータベース番号か、アプリ固有のテーブルに閉じている構成であれば、影響がアプリの外へ出ません。3つめは、再構築の負荷に耐えられる時間帯であること。全件が消えた直後は元データへの問い合わせが集中するため、ピークを外して実行できることが条件になります。

逆に、見送るべき場面ははっきりしています。レート制限のカウンタや一時トークンをキャッシュに置いている構成、複数のアプリで1つのRedisを共有している構成、そして日中のトラフィックが読めない状態での実行。この3つのどれかに当てはまるなら、optimize:clearではなくconfig:clearやview:clearのような系統別のコマンドを選んでください。原因が特定できていないから全部消す、という判断は、開発環境でだけ通用する手順です。

そして通常のリリースでは、そもそもclear系を使う必要がありません。optimizeで上書きするだけで生成物は入れ替わりますし、アプリケーションキャッシュはコードの更新とは無関係だからです。デプロイのたびにキャッシュを空にしている手順書があるなら、それは「消さないと反映されない何か」を抱えている合図として、原因のほうを潰すのが筋になります。

よくある質問

現場で判断が分かれやすい点を、5つの質問に絞って整理します。

コマンドを全部打ったのに変更が反映されない原因はどこにありますか？

artisanの管轄外にあるキャッシュが残っている可能性が高い状況です。OPcacheはPHPの実行エンジン側の仕組みなので、プロセスマネージャを再読み込みしないと入れ替わりません。加えて、キューワーカーやOctaneのような常駐プロセスも古いコードを抱えたままなので、php artisan reloadで終了させる必要があります。画面の見た目だけが古いなら、原因はフロント資産のビルド結果かブラウザ側のキャッシュです。

cache:clearとoptimize:clearはどちらを使うべきですか？

原因が分かっているなら系統別のコマンド、分からないなら開発環境でのみoptimize:clear、という使い分けをおすすめします。optimize:clearにはcache:clearが含まれているため、本番で打つとアプリが保持していた値まで消えます。本番のデプロイ手順に置くのはどちらでもなくoptimizeです。

PaaS上へ載せる場合はデプロイの前提そのものが変わります。基盤側が引き受ける範囲はLaravel Cloudとは｜構成・料金・ForgeとVaporの違いと受託での採用条件で確認できます。

本番でoptimize:clearを打つと具体的に何が起きますか？

設定・イベント・ルート・ビューの結合ファイルとコンパイル済みクラスが削除の対象であり、加えて既定キャッシュストアの全キーも消える動作です。直後のリクエストは無キャッシュ状態のアプリに当たるため応答が遅くなり、キャッシュを前提にしていた処理は一斉に元データへ取りに行きます。

config:cacheを入れたら設定値がnullになりました

仕様どおりの挙動です。設定を結合ファイルにまとめると環境変数ファイルが読み込まれなくなり、設定ファイル以外の場所で呼んだenv()はnullを返します。該当箇所を洗い出し、値を設定ファイルへ移してconfig()で読む形に直してください。緊急の復旧が要るなら、いったんconfig:clearで結合ファイルを外せば元の挙動に戻せます。

Dockerのローカル環境ではどう実行すればよいですか？

コンテナの中で実行する必要があるため、ホスト側でそのまま打っても対象が違います。Sailを使っている構成ならsail artisanを接頭辞に付けて呼んでください。素のDocker Composeなら、アプリのコンテナを指定して実行する形になります。Laravel Sailの基本コマンドと導入手順に環境側の前提をまとめてあります。

関連記事

• Laravelのバージョン確認｜artisanとcomposerの違いとサポート期限：挙動が版で違うため先に確かめます。
• php artisan makeコマンド一覧｜Laravel 13対応 生成先・オプション早見表：artisanの生成系を一覧できます。
• Laravel Viteの使い方｜@viteの書き方と本番ビルドの落とし穴：フロント資産は別系統の管理です。
• セッション管理とは？セッションIDの発行から失効までの実装と保存先選定を解説：保存先の共有を避ける設計です。
• Laravelのバリデーション｜validateとFormRequestの使い分け・カスタムルール・JSON応答：同じくLaravelの実装解説です。