UnityのEditor拡張で「設定の保存先」に毎回悩む話
Unity でエディタ拡張を書いていると、
「この設定、どこに保存するのが正解なんだろう？」
と悩む場面がよくあります。
そのときにまず候補に上がるのが EditorPrefs です。
bool isOpen = EditorPrefs.GetBool("MyTool_Foldout", false);
とても手軽で便利ですが、使い方を間違えると
チーム開発では地味に事故りやすい API でもあります。
この記事では、
-
EditorPrefs は何のための仕組みなのか
-
どんな用途に向いているのか
-
逆に使ってはいけないケース
を整理してみます。
EditorPrefs とは何か
EditorPrefs は、Unity エディタ専用の設定保存機構です。
-
プロジェクト単位ではない
-
ユーザー（マシン）単位で保存される
-
バージョン管理の対象外
という特徴があります。
つまり、
「この PC で、この Unity を使っている自分だけの設定」
を保存するためのものです。
保存場所はどこ？
EditorPrefs の中身は、OS ごとに以下の場所に保存されます。
-
Windows：レジストリ
-
macOS：
~/Library/Preferences -
Linux：
~/.config
この時点で分かる通り、
Git にも SVN にも乗りません。
向いているユースケース
1. エディタ UI の表示状態
例えば、
-
ツールウィンドウの開閉状態
-
折りたたみ（Foldout）の ON / OFF
-
最後に選択していたタブ
こういった「見た目の状態」は、EditorPrefs と非常に相性が良いです。
bool isOpen = EditorPrefs.GetBool("MyTool_Foldout", false);
プロジェクトを切り替えても、
「前回と同じ使い心地」を保てます。
2. 個人向けの作業効率設定
-
デバッグ表示を有効にするか
-
自動リロードを切るか
-
ログを詳細表示にするか
といった 人によって好みが分かれる設定 も適しています。
ここを ScriptableObject で共有してしまうと、
「誰かが変えた設定で全員の挙動が変わる」
という事故が起きがちです。
3. 一時的な作業フラグ
例えば、
-
デバッグ用セーブデータを使うか
-
テスト用モードで起動するか
など、
正式な仕様ではないが、作業中は必要
というフラグにも使えます。
向いていないユースケース
1. チームで共有すべき設定
-
ビルド設定
-
デバッグ機能の有効 / 無効
-
ゲーム挙動に影響するフラグ
これらを EditorPrefs に入れるのは危険です。
理由は単純で、
他人の EditorPrefs は見えないから。
「自分の環境では再現しない」という地獄が始まります。
2. 実行時（Runtime）で使うデータ
EditorPrefs は Editor 専用 です。
ビルド後のゲームでは一切使えません。
実行時に必要なデータは、
-
PlayerPrefs
-
ScriptableObject
-
JSON / Binary ファイル
などを使うべきです。
よくある設計ミス
キー名を適当に書く
EditorPrefs.SetInt("Debug", 1);
これはかなり危険です。
-
他のツールと衝突する
-
何の設定か分からなくなる
必ず ツール名・機能名を含めたキー にしましょう。
プロジェクト固有だと勘違いする
EditorPrefs は プロジェクトを跨いで共有 されます。
同じキー名を使っていると、
-
別プロジェクトの設定が混ざる
-
意図しない初期値になる
といった問題が起きます。
必要であれば、
Application.productName などをキーに含めるのも一案です。
ScriptableObject との使い分け
| 用途 | 推奨 |
|---|---|
| チームで共有 | ScriptableObject |
| 個人の作業環境 | EditorPrefs |
| 実行時データ | PlayerPrefs / ファイル |
| 一時的なUI状態 | EditorPrefs |
「誰が使う設定なのか？」
を基準に考えると、判断しやすくなります。
まとめ
EditorPrefs は、
-
小さく
-
個人的で
-
なくても困らないが、あると快適
そんな情報を保存するための仕組みです。
強力ですが、
仕様データやチーム共通設定を入れ始めた瞬間に破綻 します。
エディタ拡張を書くときは、
これは「自分だけの設定」か？
と一度立ち止まって考えるだけで、
後々のトラブルをかなり減らせるはずです。
Discussion