Unityには「便利」とされている機能が多く存在しますが、実際に使ってみるとプロジェクト全体の設計が崩れたり、デバッグが難しくなったりするケースがあります。この記事では、「抽象的に見た開発設計上の落とし穴」という視点から、具体的にUnityでどのような機能がそれに該当するかを5つ紹介します。
1. 「状態を持ちすぎる設計」 → DontDestroyOnLoad
概要
シーンをまたいでオブジェクトを残すために使われる機能。BGMの再生オブジェクトや管理系のコンポーネントで利用されることが多い。
問題点
- 同じオブジェクトが複数生成されることで重複バグが発生しやすい
- 状態を持たせると、再度シーンに戻ったときに想定外の挙動をする
対策
- Singletonパターンと組み合わせて多重生成を防ぐ
- そもそもシーン間で保持すべきかどうかを再検討する
2. 「グローバル依存」 → Singleton
概要
グローバルにアクセスできるインスタンスを1つだけ持つためのパターン。GameManagerやAudioManagerなどで使われることが多い。
問題点
- 他のスクリプトが依存しすぎて、保守性が下がる
- 非同期処理との相性が悪く、nullアクセスが起きやすい
対策
- イベントや依存性注入など、代替手段を検討する
- Singletonに状態やロジックを詰め込まない
3. 「データとロジックの分離不足」 → ScriptableObject
概要
インスペクターから編集できる共有データとして便利。武器のステータスや設定情報の定義に使われることが多い。
問題点
- 実行時にデータを変更すると、他のオブジェクトにも影響が出る
- データの共有インスタンスを意識せず使うと予期せぬバグに繋がる
対策
- 実行時はインスタンスをCloneして使う
- 読み取り専用としてのみ使用するように設計する
4. 「明示的な接続の欠如」 → GameObject.Find() / FindObjectOfType()
概要
シーン上のオブジェクトを名前や型から検索できる便利な関数。
問題点
- 処理コストが高く、毎フレーム呼び出すとパフォーマンスに悪影響
- 名前変更や構造変更で簡単に壊れるため、保守性が低い
対策
- Inspectorから明示的に参照させる
- デバッグ用途に限定し、常用は避ける
5. 「初期化タイミングの不明確さ」 → OnEnable() / Start()の初期化処理
概要
スクリプトのライフサイクルに応じて処理を自動的に実行できる機能。
問題点
- 初期化順が保証されず、他のスクリプトに依存しているとバグが発生しやすい
- エディタ上で再生を止めたり再開したりすると意図しない動作をすることがある
対策
- 初期化タイミングを明示的に管理する（Initメソッドなど）
- GameManagerなどから順序制御された初期化を行う
おわりに
Unityの便利機能は、適切に使えば開発効率を大きく高められます。ただし「便利だから」という理由だけで採用すると、長期的な開発や保守において大きな負債になりかねません。今回は「抽象的な設計上の落とし穴」に着目し、それがUnityの具体機能にどう現れるかをまとめました。開発の初期段階から設計を意識するきっかけになれば幸いです。
ブログでもUnityや個人開発ネタを発信中です！
開発ノウハウやアプリ制作過程、Unity連携系のハマりポイントなど
より深掘りした内容をブログにまとめています。
▶ https://syunpp.com
公開中のアプリ一覧はこちら！
実際にUnityで開発してリリース済みのアプリ一覧をまとめています。
▶ https://syunpp.com/公開中のアプリ一覧/
YouTubeショートでもゲーム開発の裏側を公開中！
Unityで制作中のゲームの進捗や演出テスト、実装の様子を
ショート動画でタイムラプス形式にまとめて発信しています。
▶https://www.youtube.com/@syunpp_8413/shorts
コメント