現象：アニメーション作業中にFast-Refで設定したLink Constraintがリロード（Reload）後に消えたり、データが正しく復元されない現象が発生。
ユーザー体験：復元されないため、手動でPoint Constraintなどを使って再度作業しなければならない不便が生じます。

Fast-Refはリロード時のデータ整合性を保つため、以下のような**「比較アルゴリズム」**に基づいて復元の可否を判断します。

区分	[Skip] リギング基本状態	[Restore] Fast-Ref カスタム作業
判断基準	リギング（Rig）とアニ（Ani）ファイルの両方に既に同一のLinkがある場合	リギング（Rig）にはないが、アニ（Ani）ファイルにコンストレイントが存在する場合
アルゴリズムの動作	「元データと同一」「元のリギングを優先」と判断して無視	「ユーザーデータ」と判断して別途記録・復元
設計の意図	不要なコンストレイント処理を省略することで最適化	アニメーションとコンストレイントの追加事項がアニに自動反映されるようにする

上記のアニメーターの方が経験された問題は、アルゴリズムの**「判断ロジック」**で発生した例外状況によるものです。

データの誤認識：リギングファイルにもアニメーションファイルにも既にコンストレイントが設定されている状態で作業したため、ツールが「これはユーザーが新しく作ったものではなく、元のリギングにあったもの」と誤認し、**復元対象から除外（Skip）**してしまったものです。

ユーザーの意図を100%反映するため、アルゴリズムを次のようにアップデートします。

アルゴリズムが元データと作業データを比較する際に混乱しないよう、リギングファイルをクリーンに保つ方法です。

説明：リギング元ファイルには、武器（Prop）などの要素に事前にLink Constraintを設定しないでください。
理由：元データに既にリンクがあると、Fast-Refはアニメーションファイルでユーザーが新しく設定したリンクを**「元からあったもの」**と誤認し、復元対象から除外（Skip）する可能性があるためです。
推奨：武器は床に置いたまま（Clean）にしておき、リンク作業はアニメーターがアニメーションシーンでFast-Refを通じて実行するようにすれば、復元が100%確実になります。

コンストレイント復元ロジック自体を回避するようにシステム構造を変更する、より専門的なリギング方式です。

説明：コンストレイントを復元する代わりに、コントローラーの**カスタムAttr（例：Switch 0/1）**や特定の**ドライブ（移動値Xなど）**を通じて接続を制御してください。
理由：この方式はアニメーションシーンでコンストレイントを新たに生成しないため、復元すべき要素自体が発生せず、データ消失のリスクが根本的に遮断されます。
参考：Mayaなどのメジャースタジオの基本リギングでも推奨される方式ですが、これを実装するにはチーム内に専任の**リガー（Rigging TD）**の協力が必要です。