Unityのスクリプト設計を改善！SOLID原則で整理する方法

1. はじめに

Unityでゲームを作っていると、気がつけばスクリプトがどんどん大きくなり、「どこを直せばいいのか分からない…」なんてことはありませんか？
プレイヤー操作、敵の動き、UIの更新などを1つのクラスに全部まとめてしまうと、いわゆる「神クラス」になってしまい、バグ修正や機能追加のたびに大工事が必要になります。

こうした問題を防ぐために役立つのがSOLID原則です。これは、オブジェクト指向プログラミングで守るべき5つの基本ルールをまとめた考え方で、設計の指針として世界中のエンジニアに使われています。
Unity開発に取り入れることで、コードが見やすくなり、チーム開発でも「誰が見ても理解しやすい」スクリプトを書けるようになります。

本記事では、SOLID原則の概要とUnityにおける具体的な活用例を解説し、さらにデザインパターンとの組み合わせでどう設計を改善できるのかを紹介します。
「設計を意識したコードが書きたい」「保守性の高いプロジェクトにしたい」と考えている方はぜひ参考にしてください。

設計を体系的に学びたい方には、下記の書籍もおすすめです。基礎から応用までしっかりカバーされているので、実務にもすぐ活かせますよ。
Unityゲーム プログラミング・バイブル 2nd Generation
✅ Amazonでチェックする ｜ ✅ 楽天でチェックする

---

2. 設計の重要性とよくある失敗例

プログラムを書くとき、つい「とりあえず動けばいいや」と思って実装を進めてしまうことがあります。ですが、このやり方は短期的には便利でも、長期的には大きなトラブルの原因になりがちです。

2-1. 設計を怠ると起こる問題

• 神クラス化：1つのクラスがあまりに多くの役割を持ち、修正が難しくなる
• 依存関係の複雑化：他のスクリプトを少し変えるだけで予期せぬエラーが発生
• 処理の流れが不明確：どの関数がどこで呼ばれているのか追うのが困難
• 修正コストの増大：機能追加やバグ修正に時間がかかりすぎる

こうした問題は、個人開発だけでなく、チーム開発でも深刻です。
「自分以外の人が読んでも理解できるコード」であることは、後々の開発効率を大きく左右します。

2-2. 設計を意識するメリット

• クラスや関数の役割が明確になり、処理を追いやすい
• バグ修正が局所化され、影響範囲が小さくなる
• 新しい機能を追加するときも既存コードを壊さずに済む
• チームメンバーが読みやすく、開発のスピードが上がる

---

3. SOLID原則の解説（Unity実装例つき）

SOLID原則は、オブジェクト指向プログラミングで守るべき5つの基本ルールをまとめた考え方です。
この原則を意識すると、クラスの役割が明確になり、保守性・拡張性の高いコードを書くことができます。Unity開発においても非常に役立つ知識なので、一つずつ見ていきましょう。

3-1. S（Single Responsibility Principle）単一責任原則

定義：「1つのクラスは1つの役割に責任を持つべき」という考え方です。
悪い例：PlayerManagerクラスが「入力処理」「移動処理」「アニメーション制御」をすべて担当してしまう。
改善：入力処理はInputHandler、移動処理はPlayerMover、アニメーションはPlayerAnimatorなどに分割すると見通しが良くなります。

3-2. O（Open Closed Principle）オープンクローズド原則

定義：「拡張には開いているが、修正には閉じているべき」という考え方です。
悪い例：AreaCalculatorクラスで、図形ごとにif文を追加して面積を計算している。
改善：図形ごとにクラスを作成し、共通のインターフェイス（IShape）を通じて計算することで、新しい図形を追加しても既存コードを変更せずに済みます。

3-3. L（Liskov Substitution Principle）リスコフの置換原則

定義：「派生クラスは基底クラスとして正しく振る舞わなければならない」という考え方です。
悪い例：EnemyクラスのAddDamage()をBossクラスで完全に無効化してしまう。
改善：基底クラスで定義された契約を守りつつ、Boss固有の処理を追加する形にすることで、コード全体の信頼性が保たれます。

3-4. I（Interface Segregation Principle）インターフェイス分離の原則

定義：「使わないメソッドの実装を強制されてはいけない」という考え方です。
悪い例：IUnitStatsに「HP」「移動」「爆発」など全部まとめて定義 → ExplodingBarrelクラスに不要なMove()が強制される。
改善：IDamageable、IMovable、IExplodableなどに分割して、必要な機能だけを継承できるようにする。

3-5. D（Dependency Inversion Principle）依存性逆転の原則

定義：「上位クラスは下位クラスに依存せず、抽象に依存すべき」という考え方です。
悪い例：Buttonクラスが直接Doorクラスを操作する。
改善：IOpenableインターフェイスを用意し、Buttonはそのインターフェイスを通じて処理を呼び出す。Door以外のクラス（宝箱など）も同じ仕組みで操作できるようになります。

このようにSOLID原則を意識すると、コードの見通しが劇的に改善されます。
特にUnityのようにオブジェクトやコンポーネントが増えていく開発環境では、原則を意識するだけで後々のメンテナンス性が大きく変わります。

---

4. インターフェイス分離原則の実践

SOLID原則の中でも、特にUnityで役立つのがインターフェイス分離の原則です。これは「必要のないメソッドを無理やり実装させない」ための考え方で、コードをシンプルに保つのにとても有効です。

4-1. 悪い例：1つのインターフェイスに詰め込みすぎる

例えば、キャラクターやオブジェクトの特性をまとめた「IUnitStats」というインターフェイスを定義し、そこに以下のような機能をすべて入れてしまうケースです。

public interface IUnitStats
{
    void TakeDamage(int amount);
    void MoveForward();
    void Reverse();
    void Explode();
}

この場合、敵キャラ（EnemyUnit）も爆発する樽（ExplodingBarrel）もIUnitStatsを継承することになりますが、不要なExplode()やMoveForward()を実装せざるを得なくなり、無駄なコードが増えてしまいます。

4-2. 良い例：機能ごとにインターフェイスを分割する

不要なメソッドを避けるには、インターフェイスを小さな単位に分けて設計するのが効果的です。

public interface IDamageable
{
    void TakeDamage(int amount);
    void Die();
}

public interface IMovable
{
    void MoveForward();
    void Reverse();
}

public interface IExplodable
{
    void Explode();
}

こうして分割すれば、EnemyUnitはIDamageableとIMovableを継承、ExplodingBarrelはIDamageableとIExplodableを継承する、といった具合に「必要なものだけ」実装すればOKになります。

4-3. メリット

• 無駄なメソッド実装がなくなり、コードがスッキリする
• 新しいオブジェクトを追加する際も柔軟に対応できる
• 大規模なゲーム開発でも役割分担が明確になり、チームでの分業がしやすい

---

5. デザインパターンとの組み合わせ

SOLID原則を意識した設計をさらに強力にしてくれるのがデザインパターンです。
デザインパターンは「よくある問題に対する解決のテンプレート」であり、Unityのゲーム開発でも役立つ場面がたくさんあります。

5-1. Singleton（シングルトンパターン）

ゲーム開発で最もよく使われるデザインパターンのひとつです。
特徴：インスタンスが1つしか存在しないことを保証し、どこからでもアクセスできるようにする。
Unityでの例：GameManagerをシングルトンとして実装し、ゲーム全体の状態管理を一元化する。
ただし、便利すぎるために濫用すると依存関係が複雑になりがちなので注意が必要です。

5-2. Observer（オブザーバーパターン）

イベントや通知を扱うのに便利な仕組みです。
特徴：「あるオブジェクトの変化を、複数のオブジェクトが監視する」仕組み。
Unityでの例：C#のActionやeventを使って、プレイヤーのHP変化をUIに自動的に反映させる。
この方法なら、監視対象と監視側が疎結合になり、コードの再利用性が高まります。

5-3. MVP（Model View Presenter）

UIやゲームロジックを分離するのに役立つ設計パターンです。
特徴：データ（Model）、表示（View）、制御（Presenter）を分けることで、役割が明確になり保守しやすくなる。
Unityでの例：UIはView、スコア計算はModel、やり取りを橋渡しするPresenterを用意することで、テストや修正がしやすくなります。

5-4. デザインパターンを使うメリット

• コードの再利用性が高まる
• 複雑な処理を整理して見通しが良くなる
• チーム開発で役割分担がしやすい

デザインパターンを使うと「設計の意図」が明確になるので、あとからコードを読む人にとっても理解しやすくなります。

---

6. まとめ

今回は、Unityのスクリプト設計を改善するためのSOLID原則と、よく使われるデザインパターンについて解説しました。

学んだポイントを振り返り

• SOLID原則は「単一責任」「拡張に強い」「継承の正しい使い方」「インターフェイス分離」「依存性逆転」の5つが基本
• Unityのプロジェクトでは特に「神クラス化」を防ぐのに役立つ
• インターフェイスを分けることで、不要なコードを書かずに済む
• デザインパターン（Singleton・Observer・MVP）を組み合わせるとさらに効率的な設計が可能

大事なのは「原則を守るためにコードを書く」のではなく、
開発をスムーズに進めるために原則を意識するという姿勢です。
プロジェクトの規模やチームの状況に合わせて、適材適所で使いこなすことが何より重要です。

もっと体系的に設計やパターンを学びたい方は、以下の書籍がおすすめです。実例を交えて詳しく解説されているので、Unity開発のスキルアップにきっと役立ちますよ。
✅ Amazonでチェックする ｜ ✅ 楽天でチェックする

---

あわせて読みたい

今回紹介したSOLID原則や設計改善に関連する内容を、さらに深掘りできる記事をまとめました。興味のある方はあわせてチェックしてみてくださいね。

• Unityのコードをきれいに保つ！依存性注入（DI）の基本と実装方法
• Unityのコードをリファクタリング！初心者でもできる最適化＆整理術
• Unityでステートマシンを活用！ゲーム開発を効率化する方法
• Unityのオブジェクト指向設計！継承・ポリモーフィズム・インターフェースを徹底解説
• Unityの設計パターンを徹底比較！シングルトン・サービスロケーター・イベント駆動の違いと使い方

---

よくある質問（FAQ）