Unreal Engine 5.5系で「ShaderCodeResource.GetFrequency() == Frequency」クラッシュが出る原因と最短復旧手順（DevelopmentビルドのCook失敗）

朝はShippingで通ったのに、同じプロジェクトをDevelopmentでパッケージしようとした瞬間に、ShaderCore.h のアサートでCookが落ちる。ログには FShaderCode::GetFinalizedResource() や FShaderCompilingManager::ProcessCompiledShaderMaps() が並び、最後は Unknown Cook Failure で終了――この症状は、ほとんどの場合「壊れた／古いシェーダーキャッシュを別コンフィグが再利用して破綻した」パターンです。Epic Developer Community Forums

• Unreal Engine 5.5系で「ShaderCodeResource.GetFrequency() == Frequency」クラッシュが出る原因と最短復旧手順（DevelopmentビルドのCook失敗）
  • 何が起きているか：Frequency不一致は「シェーダー情報の食い違い」
  • 最短で直す：キャッシュ全消し→シェーダー再構築
    • 手順1：エディタと関連プロセスを完全終了
    • 手順2：プロジェクト直下のキャッシュを削除
    • 手順3：ユーザー共通DDCも削除
    • 手順4：起動してシェーダー再コンパイル→Developmentで再パッケージ
  • まだ落ちる場合：強制リコンパイルで“取りこぼし”を潰す
  • 再発防止のコツ：DevelopmentとShippingでキャッシュ境界を意識する
    • 1) ビルド設定を切り替えた日は“DDC削除”をルーチン化
    • 2) ソースビルドは“中身が変わりやすい”前提で扱う
    • 3) 異なるマシン／CI／共有ドライブでキャッシュを混ぜない
  • まとめ：このクラッシュは“プロジェクト破損”ではなく“キャッシュ整合性”の問題が多い

何が起きているか：Frequency不一致は「シェーダー情報の食い違い」

ShaderCodeResource.GetFrequency() == Frequency は、ざっくり言うと「いま処理しているシェーダー（例：Vertex/Pixel/Computeなど）の“種別（Frequency）”と、キャッシュから取り出したバイナリ側のメタ情報が一致しない」という検出です。Cook中にシェーダーを取りまとめる段階（ShaderMapの統合）で落ちるため、**個別のマテリアル不具合というより“キャッシュ整合性の崩れ”**で起きやすいのが特徴です。Epic Developer Community Forums

特に、次の条件が重なると再現しやすくなります。

• Shippingビルドを先に通した直後にDevelopmentを回す

• Engineをソースビルドしていて、途中でビルド設定やモジュール状態が変わった

• シェーダー派生物（DDC）を別設定でも共用している

ShippingとDevelopmentでは、最適化設定・定義マクロ・有効化されるシェーダーバリアントが異なり、キャッシュの「使い回し」が想定外の形で成立してしまうことがあります。その結果、Cookが“以前の成果物”を拾って不整合を起こし、アサートで停止します。Epic Developer Community Forums

最短で直す：キャッシュ全消し→シェーダー再構築

この手のクラッシュは、原因追跡より先にキャッシュの完全リセットが最短ルートです。ポイントは「プロジェクト内」だけでなく「ユーザー共通DDC」も消すことです。

手順1：エディタと関連プロセスを完全終了

• Unreal Editor

• UAT/AutomationTool

• ShaderCompileWorker（残っていれば）

手順2：プロジェクト直下のキャッシュを削除

プロジェクトフォルダで以下を削除します。

• Intermediate

• Saved

• DerivedDataCache

手順3：ユーザー共通DDCも削除

Windowsなら代表例はここです（環境で多少前後します）。

• %LOCALAPPDATA%\UnrealEngine\Common\DerivedDataCache

この「共通DDC」が残っていると、プロジェクト側を消してもまた古い成果物を拾って復活することがあります。Epic Developer Community Forums

手順4：起動してシェーダー再コンパイル→Developmentで再パッケージ

起動後、シェーダーの再コンパイルが走ります。完了を待ってからDevelopmentでPackagingをやり直します。

まだ落ちる場合：強制リコンパイルで“取りこぼし”を潰す

キャッシュ削除後でも、稀に「一部だけ残った不整合」が残ります。そのときは、エディタのコンソールで全シェーダー再構築を指示します。

この操作で、Cook時に拾われる可能性のある中途半端な成果物を潰しやすくなります。Epic Developer Community Forums

再発防止のコツ：DevelopmentとShippingでキャッシュ境界を意識する

キャッシュ問題は「直った後に再発」しやすいので、運用面も押さえると得します。

1) ビルド設定を切り替えた日は“DDC削除”をルーチン化

特に、Shipping→Development、あるいはその逆を短時間で繰り返す場合は、DDCが地雷になりやすいです。

2) ソースビルドは“中身が変わりやすい”前提で扱う

同じバージョン表記でも、手元の変更・マージ状況・プラグイン更新でシェーダー出力が変わります。
「昨日のDDCは今日の正解」とは限りません。

3) 異なるマシン／CI／共有ドライブでキャッシュを混ぜない

共有DDC運用は強力ですが、設定やバージョンがズレると破壊力も大きいです。まずはローカルで安定させ、うまくいってから共有化するのが安全です。

まとめ：このクラッシュは“プロジェクト破損”ではなく“キャッシュ整合性”の問題が多い

ShaderCodeResource.GetFrequency() == Frequency でDevelopmentのCookが落ちるケースは、ログが派手でも本質はシンプルで、古い／壊れたDDC（Derived Data Cache）を別コンフィグが再利用して破綻している可能性が高いです。Epic Developer Community Forums
まずは Intermediate / Saved / DerivedDataCache + 共通DDCの削除、次に recompileshaders all の順で、最短復旧を狙うのが効果的です。