循環依存エラー（Cyclic Interaction）の発生原因
『The Elder Scrolls』や『Fallout』シリーズなど、Bethesda系タイトルのMOD環境において、Mod Organizer 2やVortex、あるいは単体ツールとして活用されるLOOT（Load Order Optimisation Tool）は、プラグインのロード順を自動調整するための不可欠な基盤です。しかし、MODリストに含まれる .esm、.esp、.esl ファイルの数が数百個規模に膨らむと、ソート処理を完全に停止させる致命的なエラーに直面することがあります。
Cyclic interaction detected between plugins: "PluginA.esp" -> "PluginB.esp" -> "PluginC.esp" -> "PluginA.esp"
このエラーが発生すると、LOOTはソート処理を中断します。既存のロード順は未適用のまま凍結され、新しく導入した競合回避パッチが適切な位置に配置されなくなります。この状態でゲームを起動すると、必須マスターの欠落やパッチ順序の逆転により、タイトル画面でのCTD（デスクトップへのクラッシュ）や、深刻なクエスト・スクリプトの破損を引き起こします。
循環依存が発生するグラフ理論上の理由と、LOOTのルール判定ロジックを理解することで、MODリストを一から再構築することなく、競合の原因箇所を特定して修復できます。
LOOTのソートアルゴリズム：有向非巡回グラフとトポロジカルソート
LOOTがプラグインの順序を決定する仕組みは、単純な優先順位リストではなく、数学のグラフ理論に基づいています。
LOOTは、現在アクティブになっているすべてのプラグインを**有向非巡回グラフ（Directed Acyclic Graph: DAG）**としてモデル化します。
- 頂点（ノード）： ゲームのDataフォルダ内に存在する各プラグインファイルが、グラフ上の1つの頂点となります。
- 有向辺（矢印）： 「プラグインAはプラグインBよりも前にロードされる必要がある」というルールは、ノードAからノードBへの有向辺（$A \rightarrow B$）として表現されます。
これら多数の依存関係を1次元の連続したロード順（00からFEまでのインデックス）へと展開するため、LOOTは**トポロジカルソート（Topological Sort）**を実行します。トポロジカルソートとは、すべての有向辺 $u \rightarrow v$ において、頂点 $u$ が頂点 $v$ よりも必ず前方に位置するように頂点を一列に並べるアルゴリズムです。
グラフ理論の基本定理として、**「有向グラフがトポロジカルソート可能であるための必要十分条件は、有向閉路（サイクル）が存在しないこと」**が証明されています。
もしルール群の中に「AはBの前（$A \rightarrow B$）」「BはCの前（$B \rightarrow C$）」「CはAの前（$C \rightarrow A$）」という矛盾が含まれていた場合、閉じたループ（サイクル）が形成されます。この状態では、すべての条件を同時に満たす順序が数学的に存在しません。LOOTはこの矛盾を検知した瞬間に「Cyclic interaction detected」を出力して処理を停止します。
ルールの階層構造：ハードルールとソフトルールの違い
サイクルの原因を切り分けるには、LOOTがプラグイングラフを構築する際に適用する2種類のルール体系を理解する必要があります。
1. ハードルール（絶対に無視できない制約）
ハードルールは、ゲームエンジンの仕様やファイル構造に直結した必須ルールであり、LOOTが勝手に除外することはできません。ハードルール間でサイクルが形成された場合、ソートは確実に失敗します。
- マスターフラグ（Master Flag）：
.esmフラグを持つプラグインは、通常の.espプラグインよりも必ず前にロードされなければなりません。 - ファイルヘッダーのマスター依存（Header Masters）： プラグイン内部の
File HeaderにあるMAST（Master Files）に別のプラグインが登録されている場合、親プラグインは物理的に必ず先立ってロードされる必要があります。逆順になると起動時に即座にCTDが発生します。 - ゲーム公式の固定順序：
Skyrim.esmやFallout4.esmなどの公式コアファイルは、エンジンによって先頭の配置が強制されています。 - ユーザー設定の「〜の後にロード」ルール： LOOTのメタデータエディタでユーザーが手動追加したルールは、最優先のハードルールとして扱われます。
- 必須要件メタデータ： 公式マスターリストで指定されたハード依存関係。
2. ソフトルール（柔軟に除外可能な推奨制約）
ソフトルールは、競合解決の最適化を支援するためのルールですが、グラフ全体のソート可能性を損なう場合には自動的に破棄されます。
- グループルール（Group Rules）： LOOTはプラグインを階層的なグループ（Core、Bug Fixes、UI、Late Loaders など）に分類しています。グループの順序がハードルールと衝突してサイクルを引き起こす場合、LOOTはそのグループルールを自動的に無視します。
- オーバーラップルール（Overlap Rules）： 複数のプラグインが同一のレコードやアセットを変更している場合に適用されるルールです。ハードルールと競合した場合は除外されます。
LOOTはソフトルールが引き起こすサイクルを自動的に回避するため、解消しない循環依存エラーのほぼ100%は、ハードルール同士の衝突（マスター指定とユーザー指定ルールの矛盾）によって発生しています。
循環依存を引き起こす3つの典型的な原因
実際のMOD導入において、このエラーは以下の3パターンのいずれかに分類されます。
パターン1：互換パッチ同士の相互マスター参照
複数の大型MODを導入し、コミュニティ製の互換パッチを重ねた際によく発生します。
- MOD A は基本MOD X を要求する。
- MOD B は基本MOD Y を要求する。
- AとBを調整する
Patch1.espが誤ってPatch2.espをマスターに指定し、Patch2.esp側でもPatch1.esp（またはその前提ファイル）をマスターに指定しているケースです。 双方が相手の先行ロードを物理的に要求しているため、抜け出せないデッドロックに陥ります。
パターン2：ユーザー独自ルールとヘッダーマスターの衝突
ネットの古いガイドなどを参考に、ユーザーがLOOT上で手動ルールを追加した際に発生します。
- ユーザーが「
Armor_Patch.espをWeather_Mod.espの後にロードする」というルールを手動設定した。 - しかし、
Weather_Mod.espの前提フレームワークが、内部ヘッダーでArmor_Patch.espをマスターとして要求していた。 この場合、ユーザーの指定と内部ヘッダーの要求が正反対を向くため、サイクルが形成されます。
パターン3：ESMフラグ付きプラグインが通常ESPをマスター指定している
Bethesdaエンジンは、すべてのESMフラグ付きプラグインを通常のESPより前に配置することを要求します。MOD作者がプラグインにESMフラグを付けたものの、前提ファイルに通常の .esp を指定したままにしておくと、
- マスター依存ルール：「通常ESPが先」
- ESMフラグルール：「ESMフラグ付きが先」 という矛盾が生じ、LOOTがサイクルとして検出します。
5段階のトラブルシューティング手順
365Finds の分析では、循環依存エラーの大半は LOOT の公式マスターリストの不備ではなく、ユーザーが過剰に設定した「〜の後にロード」ルールや、互換パッチ作者が不用意にお互いをマスター指定してしまったことに起因します。カスタムメタデータを整理し、xEdit で実際のレコード参照を確認することで、大型MODパックを再導入することなく9割以上のソート停止を解消できます。
以下の手順で体系的にエラーを特定し、解消してください。
ステップ1：エラーメッセージから衝突ループを特定する
LOOTが警告を出した際、ダイアログまたは画面上部のカードに表示されているパスを確認します。
例：
Back cycle: ModAlpha.esp, ModBeta.esp, PatchGamma.esp, ModAlpha.esp
ここに表示されたプラグイン名をすべてメモします。競合はこの輪の中に含まれるファイル間でのみ発生しています。
ステップ2：カスタムユーザーメタデータを確認・削除する
ツールの内部データを弄る前に、手動設定したルールが原因でないか確認します。
- LOOTのメイン画面で、エラーに表示されたプラグインを探します。
- プラグイン右側の3点リーダー（⋮）をクリックし、**メタデータを編集（Edit Metadata）**を選択します。
- **〜の後にロード（Load After）タブとグループ（Group）**タブを確認します。
- ユーザーが手動で追加した「Load After」ルールが存在する場合、ゴミ箱アイコンをクリックして削除します。
- チェックマークアイコンをクリックして保存します。
- LOOT上部の「ソート」ボタンを再度押します。これでエラーが消えれば、原因は手動ルールの矛盾でした。
ステップ3：xEditで物理ファイルヘッダーを確認する
メタデータを消してもエラーが出る場合、プラグイン本体のヘッダーに原因があります。
- MODマネージャーから xEdit（SSEEdit、FO4Edit等）を起動します。
- プラグイン選択画面で右クリックして「Select None」を選び、ループに含まれていたプラグインのみにチェックを入れてロードします（公式コアファイルは自動で読み込まれます）。
- 読み込み完了後、左ペインで対象プラグインを展開し、最上部の
File Headerをクリックします。 - 右ペインの
Master Files (MAST)項目を確認します。 - ループ内のプラグイン同士がどのようにマスター指定し合っているかを照合します。
ステップ4：「Clean Masters」で不要なマスター指定を除去する
MOD作者が作業中に誤って無関係なMODを巻き込んでしまい、実際にはそのMODのレコードを何も変更していないのにマスター指定だけが残っているケースが多々あります。
- xEditで、不要なマスターを含んでいる疑いのあるパッチを右クリックします。
- コンテキストメニューから Clean Masters を実行します。
- xEditがプラグイン全体を走査し、参照されていない不要なマスターファイルをヘッダーから自動削除します。
Ctrl + Sで変更を保存し、xEditを終了します。
ステップ5：互換性のないパッチを整理する
Clean Mastersを実行してもマスターが消えない場合、そのパッチは本当に両方のファイルを書き換えています。
- この場合、本来併用してはならない別バージョンのパッチ（例：FOMODで「単体版」と「統合版」を両方選んでしまった等）を同時に導入している可能性が高いです。
- MODマネージャー側で重複しているパッチを無効化するか、再インストールして適切なオプションを選択し直します。
- 再度LOOTを起動してソートを実行します。サイクルが解消され、正常にロード順が確定します。