Unityのオブジェクト指向設計！継承・ポリモーフィズム・インターフェースを徹底解説

「継承って本当に必要なんだろう？」
「interfaceって、正直いつ使えばいいの？」
Unityでスクリプトを書いていると、こんな疑問を感じ始めるタイミングが必ず来ます。

最初は1つのスクリプトに処理を書いても問題ありません。
でも、キャラの動き・攻撃・当たり判定・アニメーション・SE……と機能が増えてくると、 「どこを直せばいいのか分からない」「触るのが怖いコード」になってしまいがちです。

そこで出てくるのが、オブジェクト指向設計という考え方です。
ただし、ここでよくある落とし穴があります。

C#の教科書どおりに
「とりあえず継承」「とりあえずinterface」
と使ってしまうと、Unityでは逆に設計が破綻しやすい、という点です。

Unityには MonoBehaviour という強い前提があり、
純粋なC#アプリとは違う制約・思想でコードを書く必要があります。

この記事では、
継承・ポリモーフィズム・インターフェースを“どう書くか”ではなく、
「なぜその設計が必要なのか」「いつ使うべきか・使わないべきか」という 実務で迷わないための判断基準を中心に解説していきます。

文法の細かい説明は最小限にして、
・スクリプトが増えても破綻しにくい考え方
・後から仕様変更しやすい設計の作り方
を、Unityの実例ベースで整理していきます。

「今は小規模だけど、将来もっと大きなゲームを作りたい」
「設計で詰まらないUnity開発をしたい」
そんな人にとって、長く使える考え方を持ち帰ってもらえる内容を目指します。

---

結論：Unityのオブジェクト指向は「継承」よりも判断基準が重要

先に結論からお伝えします。
Unityでオブジェクト指向を使ううえで一番大切なのは、テクニックではなく判断基準です。

よくある誤解として、
「オブジェクト指向＝継承を使いこなすこと」
と思われがちですが、Unityではこれは半分正解で、半分間違いです。

Unityの設計で意識したいポイントを、まずはシンプルにまとめると次のようになります。

• 継承は「AはBである（is-a）」関係が本当に強いときだけ使う
• 基本はコンポーネント分割（合成）を優先する
• interfaceは「将来差し替えたい境界」に使う
• 迷ったら「後から変更しやすいか？」で判断する

Unityでは、すでに MonoBehaviour を継承している時点で、
クラス設計の自由度は純粋なC#よりも制限されています。

そのため、
「とりあえず共通処理だから継承」
「なんとなくinterfaceを切っておく」
といった設計は、あとから変更しづらい構造を生みやすくなります。

逆に言うと、
・なぜ今それが必要なのか
・将来どこが変わりそうか
この2点を意識して選択できれば、設計は驚くほど安定します。

このあとの章では、
Unity開発で実際によく起きる失敗例からスタートして、
「どのタイミングで、どの選択をすれば破綻しにくいのか」を順番に見ていきます。

---

Unityで起きがちな失敗①：巨大MonoBehaviour問題

Unity初心者〜中級者が、ほぼ確実に一度はぶつかるのが
1つのMonoBehaviourに処理を詰め込みすぎる問題です。

たとえばプレイヤー用スクリプトに、次のような処理が全部入っていませんか？

• 入力の取得（キーボード・ゲームパッド）
• 移動やジャンプなどの物理処理
• 攻撃判定・ダメージ計算
• アニメーションの制御
• 効果音・エフェクトの再生

最初は問題なく動きますし、
「とりあえずゲームが完成する」という意味では正解です。

でも、機能が増えてくると次のような状態になりがちです。

• コードが長すぎて全体を把握できない
• 少し修正しただけで別の挙動が壊れる
• どこに手を入れていいか分からず触るのが怖い

これは書き方が悪いのではなく、
「責務」が1つのクラスに集まりすぎていることが原因です。

MonoBehaviourは便利ですが、
「何でも書ける」＝「何でも書いていい」ではありません。

特にUnityでは、
入力・移動・攻撃・演出のように
役割（ドメイン）が違う処理を分けて考えることがとても重要です。

この考え方を理解しておかないと、
あとから継承やinterfaceを導入しても、根本的な解決にはなりません。

「じゃあ、どうやって分ければいいの？」という点については、
次の記事でより具体的に整理しています。

---

継承（Inheritance）の正しい使いどころと落とし穴

巨大なMonoBehaviourを分けようとしたとき、
多くの人が次に考えるのが「継承を使えばいいのでは？」という選択です。

たとえば、
「EnemyBaseを作って、そこからゴブリンやスライムを継承する」
といった設計は、Unityでもよく見かけます。

この考え方自体は間違いではありません。
ただし、継承にははっきりした向き・不向きがあります。

継承が向いているケース

Unityで継承を使ってよいのは、
「AはBである（is-a）」という関係が本当に強いときです。

• ゴブリンは敵である
• スライムは敵である
• すべての敵が共通のライフ・死亡処理を持つ

このように、
概念として明確な共通点があり、将来も大きくブレなさそうな場合は、
継承は有効な選択肢になります。

継承が破綻しやすいパターン

一方で、次のような理由で継承を使うと、あとから苦しくなりがちです。

• 「コードを共通化したいから」という理由だけで継承する
• 機能単位（移動・攻撃・AI）を親クラスに押し込む
• 将来の仕様変更をあまり考えずに階層を深くする

特にUnityでは、すでに MonoBehaviour を継承しているため、
これ以上クラス継承を重ねると設計の逃げ道がなくなりやすいです。

「やっぱりこの敵だけ挙動を変えたい」
「この敵には物理がいらなかった」
といった変更が入った瞬間、親クラスが肥大化し始めます。

その結果、
「全部の子クラスに影響が出る怖い基底クラス」が完成してしまいます。

Unityにおける継承の判断基準

継承を使うか迷ったら、次の質問を自分に投げてみてください。

• これは本当に「is-a」の関係か？
• 将来、この親クラスに処理が増え続けないか？
• 一部の子だけ挙動が違う未来は想像できないか？

1つでも不安があるなら、
継承ではなくコンポーネント分割を選んだ方が安全です。

なお、継承とセットで誤用されやすいのがシングルトン設計です。
Unity特有の落とし穴については、こちらで詳しく解説しています。

---

ポリモーフィズムは「共通操作」を作るための道具

「ポリモーフィズム（多態性）」と聞くと、
一気に難しそうに感じる人も多いですが、考え方はとてもシンプルです。

一言でいうと、
「同じ命令を投げても、相手によって振る舞いが変わる仕組み」です。

Unity開発では、
この考え方を使えるようになると、if文やswitch文だらけのコードから一気に解放されます。

if / switch が増え始めたら要注意

たとえば攻撃処理で、こんなコードを書いた経験はありませんか？

• 敵の種類ごとに if 文で分岐
• タグやenumで分けて処理を切り替える
• 敵が増えるたびに条件分岐が増える

この構造は、
「今は動くけど、将来必ずつらくなる」典型パターンです。

敵が1種類なら問題ありません。
でも、ボス・雑魚・無敵敵・イベント敵……と増えていくと、
修正のたびに条件分岐を追いかけることになります。

ポリモーフィズムを使うと何が変わるか

ポリモーフィズムを使うと、
「何者か」を判定するコードが不要になります。

たとえば、
「ダメージを受け取れる存在」という共通の振る舞いだけを定義しておけば、

• プレイヤー
• 敵
• オブジェクト

それぞれが自分なりのダメージ処理を実装できます。

攻撃側は、
「相手が誰か」を一切気にせず、
同じ命令を投げるだけで済みます。

Unityでの実務的な使いどころ

Unityでは、次のような場面でポリモーフィズムが特に効果を発揮します。

• ダメージ・回復などの共通イベント
• 攻撃・スキル・ギミックの実行
• 「何かを実行する」対象が増えそうな処理

ポイントは、
「処理の流れは同じだが、中身だけが違う」という部分を見つけることです。

逆に、
毎回まったく違う手順になる処理には、
無理にポリモーフィズムを使う必要はありません。

---

interfaceは「差し替え前提の境界」に使う

ポリモーフィズムの考え方が少し見えてくると、
次に出てくるのがinterface（インターフェース）です。

ただ、ここで多くの人がつまずきます。

「便利そうだから全部interfaceにしておこう」
「とりあえず抽象化しておけば正解な気がする」

これはUnity設計でかなり危険な考え方です。

interfaceの本当の役割

interfaceは、
「このクラスは、こういう振る舞いを持っていますよ」
という契約（ルール）を定義するための仕組みです。

重要なのは、
実装の中身ではなく、境界を切るために使うという点です。

Unity開発でいうと、
「ここは将来、別の実装に差し替わる可能性があるか？」
という視点が判断基準になります。

Unityでinterfaceを使うべき典型パターン

実務で特に多いのは、次のようなケースです。

• 入力処理（プレイヤー操作 / AI操作 / デモ操作）
• 攻撃方法（近接 / 遠距離 / 魔法など）
• ダメージを受け取る対象

たとえば入力処理なら、
「今はプレイヤー操作だけど、あとでAI操作に切り替えたい」
という未来はとても想像しやすいですよね。

こういった差し替えが前提になりやすい場所に、
interfaceを使うと効果が最大化されます。

interfaceを使わない方がいい場面

一方で、次のような場合は無理にinterfaceを切る必要はありません。

• 今後ほぼ変更されない処理
• 1つの実装しか想定されていない処理
• 抽象化することで逆に理解しづらくなる場合

interfaceは増やすほど設計が良くなる魔法ではありません。
むしろ、使いすぎるとコードを追うのが大変になります。

だからこそ、
「ここは将来、差し替えたいか？」
この1点で判断するのがおすすめです。

なお、interfaceと相性が良い設計として、
依存性注入（DI）という考え方があります。

---

Unityでは「継承よりコンポーネント（合成）」が基本戦略

ここまで、継承・ポリモーフィズム・interfaceについて見てきましたが、
Unity設計の前提として、もう一段大事な考え方があります。

それが、「継承よりコンポーネント（合成）を優先する」という方針です。

これは流行りの設計論というより、
Unityというエンジン自体が、最初からそう作られていると考えた方が分かりやすいです。

GameObjectは「機能を入れる箱」

Unityでは、GameObjectそのものはほとんど何もしません。
実際の処理は、すべてComponent（MonoBehaviour）が担当します。

つまりUnityの基本構造は、最初からこうなっています。

• GameObject：ただの入れ物
• Component：役割ごとの機能

この構造は、
「1つのクラスに全部詰め込む」よりも、
「役割ごとに分けて組み合わせる」ことを強く後押ししています。

継承で作った設計が壊れやすい理由

継承をベースに設計すると、
どうしても「親クラスに機能を足していく」流れになりがちです。

最初はシンプルでも、
・この敵だけ移動方法が違う
・このキャラだけ攻撃が特殊
といった例外が増えてくると、親クラスがどんどん太っていきます。

結果として、
「すべてを知っている神クラス」が生まれ、
ちょっとした修正が全体に影響する状態になります。

コンポーネント分割の考え方

コンポーネント設計では、
「このオブジェクトは何ができるか？」を機能単位で考えます。

• 移動できる → MoveComponent
• 攻撃できる → AttackComponent
• ダメージを受ける → HealthComponent

必要な機能だけをGameObjectに追加していくイメージです。

こうすると、
「この敵には移動だけ付ける」
「このオブジェクトには攻撃はいらない」
といった調整が、とても自然に行えます。

合成＋interfaceの組み合わせが強い

ここで、先ほど解説したinterfaceが効いてきます。

コンポーネント同士を直接つなぐのではなく、
interfaceを介してやり取りすることで、
差し替えやテストがしやすい構造になります。

継承で「構造を固定」するのではなく、
コンポーネントとinterfaceで「組み替え可能」にする。
これが、Unityで長く使える設計の基本形です。

---

コンポーネント間のつなぎ方で設計は決まる

コンポーネント分割まではできたのに、
なぜかコードが読みにくい・直しづらい……。
そんなときは、「コンポーネント同士のつなぎ方」が原因になっていることが多いです。

Unityでは、コンポーネント同士をどう連携させるかで、
設計の柔軟性が大きく変わります。

① 直接参照する

一番シンプルなのが、
GetComponent などで直接参照する方法です。

実装が分かりやすく、動作も追いやすい反面、
結合度が高くなりやすいという特徴があります。

「この2つは常にセットで動く」
という関係が明確な場合は、無理に避ける必要はありません。

② interfaceを介して参照する

少し柔軟性を持たせたい場合は、
interfaceを介してコンポーネントを扱います。

こうすると、
「何をするか」だけに依存し、「誰がやるか」を隠せるため、
後から実装を差し替えやすくなります。

差し替え・テスト・拡張を考えるなら、
この方法が最もバランスの良い選択になることが多いです。

③ イベント・メッセージでつなぐ

さらに疎結合にしたい場合は、
イベントやメッセージを使って連携します。

発生元と受信側が互いを知らなくて済むため、
大規模なプロジェクトや拡張前提の設計で力を発揮します。

ただし、
処理の流れが追いづらくなるという欠点もあるため、
小規模な処理では使いすぎに注意が必要です。

迷ったときの判断フロー

• 常に一緒に動く → 直接参照
• 差し替えたい可能性がある → interface
• 独立性を最大化したい → イベント

この順番で考えるだけでも、
「とりあえず全部つなぐ」設計から抜け出しやすくなります。

Unityでよく使われる設計パターンの違いについては、
こちらの記事でより詳しく整理しています。

---

🔰 設計に迷ったら読む1冊（おすすめ書籍）

ここまで読んで、
「考え方は分かったけど、まだ自信がない」
「もう少し体系的に理解したい」
と感じた人もいると思います。

そういう段階で役立つのが、
Unity前提で“設計の考え方”まで踏み込んで解説している書籍です。

その中でも、
実装例と設計意図をセットで学べるという点で特におすすめなのがこちらです。

Unityゲーム プログラミング・バイブル 2nd Generation
✅ Amazonでチェックする｜ ✅ 楽天でチェックする

この本が良いのは、
単に「こう書けますよ」というサンプル集ではなく、

• なぜその構成になっているのか
• なぜそのクラス分割なのか
• なぜその責務を持たせているのか

といった設計の理由が、Unityの文脈で説明されている点です。

特に、
・コンポーネント分割の考え方
・責務をどう切るか
・後から拡張しやすい構造
といった部分は、この記事の内容とかなり相性がいいです。

「今すぐ全部理解しなきゃ」と思う必要はありません。
設計で迷ったときに立ち戻れる1冊として、手元に置いておくのがおすすめです。

---

よくある誤解・初心者がやりがちなNG設計

ここまで読んで、
「じゃあ、こう書けば正解なんだ！」
と思いたくなる気持ち、すごく分かります。

ただ、設計で一番やってしまいがちなのは、
別の極端に振り切ってしまうことです。

ここでは、Unity初心者〜中級者が特によくやりがちな
NGになりやすい考え方を整理しておきます。

誤解① 継承は悪だから使ってはいけない

「継承は危険」「継承は使うな」という話を聞いて、
完全に避けてしまう人もいますが、これは正しくありません。

問題なのは継承そのものではなく、
使いどころを考えずに使ってしまうことです。

is-a関係が明確で、
将来の変更も想像しやすい場合は、
継承は今でも有効な選択肢です。

誤解② interfaceを使えば設計が良くなる

interfaceは便利ですが、
増やせば増やすほど設計が良くなるわけではありません。

特に、
・差し替える予定がない
・実装が1つしか存在しない
という場合は、interfaceが逆にノイズになります。

「将来、本当に差し替えたいか？」
この問いを常に自分に投げるのが大切です。

誤解③ 最初から完璧な設計を目指すべき

設計に慣れていない段階で、
最初から完璧な構造を作ろうとすると、ほぼ確実に手が止まります。

Unity開発では、
動くものを作ってから、必要に応じて分けていく
という進め方でまったく問題ありません。

設計は一発で決めるものではなく、
経験と修正の積み重ねで洗練されていくものです。

誤解④ ScriptableObjectを使えば全部解決する

ScriptableObjectはとても強力ですが、万能ではありません。

ロジックとデータの責務を混ぜてしまうと、
逆に構造が分かりづらくなることもあります。

---

まとめ：Unity設計は「正解」より「判断基準」

この記事では、Unityにおける
継承・ポリモーフィズム・interfaceの使い分けを、
「どう書くか」ではなく「どう判断するか」という視点で整理してきました。

大切なポイントを、もう一度振り返ってみましょう。

• 巨大なMonoBehaviourは、最初の分岐点
• 継承は「is-a」が本当に強いときだけ使う
• ポリモーフィズムは「共通操作」を作るための道具
• interfaceは「差し替え前提の境界」に切る
• 基本戦略は、継承よりコンポーネント（合成）
• 設計の質は、コンポーネントのつなぎ方で決まる

Unityの設計に、
「これが絶対の正解」という形はありません。

でも、
「なぜ今それを選ぶのか」
「将来どこが変わりそうか」
この2点を意識できるようになると、設計は驚くほど安定します。

最初からきれいに書けなくても大丈夫です。
動くものを作って、
壊れ始めたところを分けて、
必要な場所だけ抽象化していく。

その繰り返しの中で、
「あ、この判断いらなかったな」
「ここはinterface切って正解だったな」
という経験が少しずつ溜まっていきます。

設計は知識よりも、
判断の引き出しを増やすもの。
この記事が、その引き出しを1つ増やすきっかけになれば嬉しいです。

---

参考文献・参考リンク

• Unity Manual：ScriptableObject
• Unity Scripting API：MonoBehaviour
• Unity Manual：Script Execution Order
• Unity Blog：10,000 Update() calls
• Unity Blog：Game Programming Patterns for Unity
• Unity Blog：Level up your code with game programming patterns
• Game Programming Patterns：Component Pattern
• Microsoft Learn：C# Interfaces
• Microsoft Learn：C# Polymorphism
• GameDev StackExchange：When to use inheritance vs composition in Unity
• Refactoring.Guru：Design Patterns
• Refactoring.Guru：Composite Pattern
• Zenn：Unity設計トピック

---

よくある質問（FAQ）