Unityでゲームを作っていると、最初は楽しかったはずの数値調整が、いつの間にか苦痛になっていませんか？
「敵が強すぎたからHPを少し下げたいだけなのに、スクリプトを開いて数値を探す」
「調整するたびにコンパイルを待つのが地味にストレス」
「どこを直したのか、後から自分でも分からなくなる」
こうした状態に心当たりがあるなら、それはあなたのスキル不足ではありません。
多くの場合、原因はUnityの使い方ではなく、数値の持たせ方・設計の考え方にあります。
特に中級者手前の段階では、 「とりあえず動くからOK」
「Inspectorで調整できるし問題ない」
という判断を積み重ねた結果、数値がコード・Prefab・Inspectorに散らばり、後から手が付けられなくなるケースがとても多いです。
この記事では、Unity開発でよくある「数値調整が地獄になる構造」を整理しながら、
- なぜマジックナンバーが増えてしまうのか
- Inspector調整が限界を迎える理由
- ScriptableObjectに進む前に考えるべきこと
を順番に解説していきます。
「ScriptableObjectを使えば解決する」という話で終わらせず、
今のプロジェクトを壊さずに改善していくための考え方を重視しているので、
・毎回スクリプトを触って数値調整している人
・なんとなく設計に違和感が出始めている人
には、特に役立つはずです。
まずは結論から見ていきましょう。
結論：数値調整が地獄になる本当の理由
結論から言うと、Unityで数値調整がつらくなる原因は「ScriptableObjectを使っていないから」ではありません。
本当の原因は、数値がどこにあるのか分からない設計になっていることです。
具体的には、
- 一部の数値はコード内に直接書かれている
- 一部はPrefabのInspectorで調整している
- 似たような数値がオブジェクトごとに微妙に違う
このように数値が分散した状態になると、 「どこを直せばいいのか分からない」「直した影響範囲が追えない」という状態に陥ります。
その結果、
- 調整のたびにスクリプトを開く
- コンパイル待ちが発生する
- 調整理由が後から分からなくなる
という、いわゆる「数値調整が地獄」な状況が生まれます。
ここで大事なのは、
問題はツールではなく設計の段階にあるという点です。
ScriptableObjectは確かに強力ですが、 「とりあえず使えば解決する魔法の仕組み」ではありません。
まず必要なのは、
- どの数値がゲームバランスに関わるのか
- どの数値はロジックに近いのか
- どこまでをInspectorで触るべきか
を整理することです。
この考え方は、いわゆるデータ駆動設計の入口でもあります。 より体系的に知りたい場合は、以下の記事も参考になります。
次の章では、そもそもなぜUnityではマジックナンバーやInspector依存が増えやすいのか、 その構造的な理由を掘り下げていきます。
なぜUnityの数値調整は「地獄」になりやすいのか
マジックナンバーが増殖する瞬間
Unityで数値調整が破綻し始める最初のきっかけは、ほぼ間違いなくマジックナンバーです。
たとえば、
- ダメージ計算の中に突然書かれる
1.2f - 移動速度にかけられる理由不明な
0.75f - 条件分岐に埋め込まれた
if (hp < 30)
最初は「とりあえずこれでいいか」と思って書いた数値でも、 あとから見返すとその数値にどんな意味があるのか分からなくなることがよくあります。
特に厄介なのは、マジックナンバーが調整用なのか、仕様として固定すべき値なのかの区別がつかなくなる点です。
結果として、
- 調整したいのに、どこを触ればいいか分からない
- 怖くて数値をいじれない
- 似たような数値を別の場所に追加してしまう
という悪循環が始まります。
この問題は、コードの「動き」には影響しないため、 プロジェクトが進んでから一気に表面化するのが特徴です。
読みやすさ・保守性の観点でマジックナンバーをどう扱うべきかについては、 次の記事で具体例付きで整理しています。
Inspector調整が万能だと勘違いすると起きること
マジックナンバーを避けようとして、多くの人が次に取る行動が「全部Inspectorで調整する」です。
確かにInspectorを使えば、
- コードを開かずに数値を変更できる
- コンパイル待ちが減る
- 調整の心理的ハードルが下がる
といったメリットがあります。
しかし、Inspector調整を続けていると、別の問題が静かに積み上がっていきます。
- Prefabごとに微妙に違う数値が増える
- どれが基準値なのか分からなくなる
- 「この数値、どこで使われてるんだっけ？」となる
特に敵キャラや武器が増えてくると、 調整対象がヒエラルキーやPrefabに散らばる状態になります。
この時点で、数値調整は「楽」ではあっても、 「安全」でも「再現性がある」わけでもありません。
一度バランスが崩れたときに、 元に戻す方法が分からないのがInspector依存の怖さです。
MonoBehaviourにデータを持たせ続けた結果
さらに問題を深刻にするのが、 MonoBehaviour自身に調整用データを持たせ続ける設計です。
たとえば、
- 敵のHP・攻撃力・移動速度
- 武器の威力・クールタイム
- スキルの効果量
これらをすべてMonoBehaviourのフィールドとして持たせると、 Prefabを複製するたびに同じようなデータのコピーが増えていきます。
数が少ないうちは問題になりませんが、
- 敵が10体、20体と増える
- 難易度違いのPrefabが増える
- 後から共通調整をしたくなる
このあたりで一気に破綻します。
「全部同じ数値にしたいだけなのに、Prefabを一つずつ開いて直す」 という作業を経験したことがある人も多いはずです。
この問題を整理する上で重要になるのが、 Serializable と ScriptableObject の役割の違いです。
次の章では、こうした状況をいきなり壊さずに改善するための 第一段階の現実的な対処法を紹介します。
第一段階の解決策：Inspectorでできる「最低限の改善」
いきなり設計を大きく変えるのは不安、という人も多いと思います。 そこでこの章では、今の構成を壊さずにできる現実的な改善から整理していきます。
ここでの目的は、
- 数値調整を少しでも安全にする
- 後から設計を改善しやすい状態にしておく
という土台作りです。
[SerializeField] を正しく使う意味
Unityで数値調整の第一歩として、多くの人が使うのが [SerializeField] です。
これは単に「Inspectorに表示するための属性」ではありません。 設計的には、カプセル化を守りながら調整ポイントを明示するための仕組みです。
例えば、
publicにしないことで、外部からの書き換えを防げる- 「この数値は調整していい」という意思表示になる
- ロジック用の変数と調整用の変数を分けられる
といったメリットがあります。
逆に言うと、
すべてをInspectorに出してしまうのは、設計放棄に近い状態です。
「どこまでをInspectorで触らせるのか」
「どの数値はコード側に閉じるのか」
この判断ができるようになるだけで、数値調整のストレスはかなり減ります。
もしこのあたりがまだ曖昧で、
- Unityの基本構造に自信がない
- なんとなく動かしてきた感覚がある
という場合は、一度基礎を整理しておくのがおすすめです。
ゼロからスタート！ Unityゲーム開発 １冊目の教科書
この手の基礎書は、「全部知ってるつもり」でも、 設計視点で読み直すと刺さるポイントが意外と多いです。
Playモード中の調整が危険な理由
Inspector調整でよくやりがちなのが、Playモード中に数値をいじって満足してしまうことです。
Unityでは、Playモード中の変更は基本的に停止すると元に戻ります。
そのため、
- 「いい感じになった数値」を忘れる
- メモやコピペで管理し始める
- 再現性のない調整になる
という問題が起きやすくなります。
Playモード調整は感覚を探るための作業としては有効ですが、 設計上の解決策にはなりません。
この段階では、
- どの数値が頻繁に調整されているか
- どの調整が毎回発生しているか
を観察することが重要です。
次の章では、こうして浮かび上がった「よく調整される数値」を、 安全にまとめて扱える仕組みとして ScriptableObject をどう使うかを見ていきます。
次の一手：ScriptableObjectが効いてくる条件
ここまでで、Inspector調整には限界があり、 MonoBehaviourに数値を持たせ続ける設計が後から効いてくる、という話をしてきました。
そこで登場するのが ScriptableObject です。
ただし、最初に強調しておきたいのは、 ScriptableObjectは「入れた瞬間にすべて解決する仕組み」ではないという点です。
ScriptableObjectが「魔法の杖」ではない理由
ScriptableObjectを知った直後によくあるのが、
- とりあえず全部ScriptableObjectにしようとする
- MonoBehaviourの代わりに数値を移しただけで満足する
というパターンです。
これをやってしまうと、
- どのScriptableObjectが正なのか分からない
- 依存関係が逆に見えづらくなる
- 「結局どこを直せばいいの？」が再発する
という、Inspector地獄が「アセット地獄」に変わっただけの状態になります。
ScriptableObjectが本当に効いてくるのは、 「どの数値をまとめるか」が事前に整理できている場合だけです。
ScriptableObjectが本領を発揮するケース
ScriptableObjectが向いているのは、 複数のオブジェクトから共通で参照される調整用データです。
具体的には、
- 敵キャラのステータス（HP / 攻撃力 / 移動速度）
- 武器性能（威力 / クールタイム / 射程）
- ゲーム全体で共有されるルール定数
こうしたデータをScriptableObjectとして切り出すことで、
- 数値の変更箇所が1か所に集まる
- Prefabを量産しても調整が一瞬で終わる
- 「どれが基準値か」が明確になる
という状態を作れます。
特に調整フェーズが長いゲームほど、この差ははっきり出ます。
この段階で、ScriptableObjectの中身が増えてきた場合、 Inspectorの視認性と編集体験がボトルネックになりやすくなります。
その改善策として、多くの現場で使われているのが以下のツールです。
Odin Inspectorを使うと、
- ScriptableObjectの項目をグループ化できる
- 調整用UIをコードなしで整理できる
- 「触っていい数値」が直感的に分かる
といった形で、数値調整の体験そのものが変わります。
次の章では、ScriptableObject導入時にありがちな 誤解や失敗パターンを先回りで整理していきます。
よくある誤解・やりがちな失敗
ScriptableObjectを使い始めると、数値調整はかなり楽になります。 ただし、ここで別の落とし穴にハマる人も少なくありません。
この章では、実際によく見かける誤解と失敗パターンを整理します。
最初から全部ScriptableObjectにしてしまう
「MonoBehaviourに数値を持たせるのは良くない」 ↓ 「じゃあ全部ScriptableObjectにすればいい」
この思考はとても自然ですが、かなり危険です。
すべてをScriptableObjectにすると、
- どれが設定値で、どれが状態なのか分からなくなる
- 実行中に変化する値までアセット側に混ざる
- Playモード後に意図せず値が書き換わる
という問題が起きやすくなります。
ScriptableObjectはあくまで「調整用・定義用のデータ」向けです。 HPの現在値やクールタイム残り時間のような状態まで持たせると、設計が一気に崩れます。
ScriptableObjectをグローバル変数として扱う
次によくあるのが、ScriptableObjectを
- どこからでも参照できる
- どこからでも書き換えられる
便利なグローバル変数のように使ってしまうケースです。
確かに参照は楽になりますが、
- 誰がいつ値を変えたのか分からない
- 調整ミスとバグの区別がつかない
- ビルド後に想定外の挙動になる
といった問題が起きやすくなります。
ScriptableObjectは「共有できるから安全」なのではなく、 扱い方を決めて初めて安全になるものです。
設定値をどう守るか、どこまで変更を許可するかについては、 次の記事でより実践的に整理しています。
調整用データと進行用データを混ぜてしまう
もう一つ多いのが、 「調整用」と「ゲーム進行用」のデータを同じ場所に置いてしまうことです。
例えば、
- 敵の最大HP（調整用）
- 現在HP（進行用）
これらを同じScriptableObjectに入れると、 どちらをいつ初期化すべきか分からなくなります。
結果として、
- シーン遷移で値が壊れる
- リトライ時に初期化されない
- デバッグが極端にしづらくなる
というトラブルにつながります。
ScriptableObjectは「定義」、 MonoBehaviourや専用クラスは「状態」。
この役割分担を守ることが、 数値調整を長期的に楽にするための重要なポイントです。
まとめ：数値調整は「技術」ではなく「設計」
Unityで数値調整がつらくなる原因は、 「便利な機能を知らないから」でも「ツールが足りないから」でもありません。
多くの場合、問題は数値をどう扱うかを決めないまま開発を進めてしまう設計にあります。
この記事で見てきた内容を、順番に振り返ってみましょう。
- マジックナンバーは、後から必ず自分の首を絞める
- Inspector調整は便利だが、万能ではない
- MonoBehaviourに調整用データを持たせ続けると破綻しやすい
- ScriptableObjectは「前提が整ってこそ」効果を発揮する
特に大事なのは、 いきなり理想形を目指さないことです。
おすすめの進め方は、
- まずマジックナンバーを意識する
- Inspectorで触る数値を意図的に絞る
- 「よく調整する数値」だけをScriptableObjectに切り出す
この順番を守るだけでも、 数値調整のストレスは大きく変わります。
もし今、
- 毎回スクリプトを開いて数値を直している
- PrefabやInspectorがカオスになり始めている
という状態なら、 それは設計を見直すちょうどいいタイミングです。
数値調整は作業量の問題ではなく、 設計の積み重ねの結果として楽にも地獄にもなります。
ぜひ今回の内容を、自分のプロジェクトに当てはめながら見直してみてください 🙂
参考文献
- UnityにおけるScriptableObjectの設計と考え方（i-ssue）
- UnityのScriptableObjectの基本的な使い方と注意点（kyoro-s）
- What are some bad practices to avoid when using ScriptableObject?（Reddit / r/Unity3D）
- ScriptableObject（Unity公式マニュアル）
- SerializeField（Unity公式スクリプトリファレンス）
よくある質問（FAQ）
- QScriptableObjectは小規模プロジェクトでも使うべきですか？
- A
必須ではありません。 敵や武器が数個しかなく、調整回数も少ない場合は、 Inspector調整だけでも十分なケースは多いです。
ただし、「あとから増えそう」「バランス調整が頻繁に入る」兆しがあるなら、 早めにScriptableObjectを検討する価値はあります。
- QInspector調整だけではダメなのでしょうか？
- A
ダメではありません。 問題なのは、Inspector調整に依存しすぎることです。
「どの数値をInspectorで触っていいか」が整理されていないと、 後から必ず混乱します。
Inspectorはあくまで調整手段のひとつとして使うのが理想です。
- QScriptableObjectとCSV・JSONはどう使い分ければいいですか？
- A
目安としては、
- 開発中の調整・設計フェーズ → ScriptableObject
- 大量データ・外部編集・運営更新 → CSV / JSON
という使い分けが分かりやすいです。
最初から完璧に分ける必要はありませんが、 「何のためのデータか」を意識するだけで、設計はかなり安定します。
※当サイトはアフィリエイト広告を利用しています。リンクを経由して商品を購入された場合、当サイトに報酬が発生することがあります。
※本記事に記載しているAmazon商品情報（価格、在庫状況、割引、配送条件など）は、執筆時点のAmazon.co.jp上の情報に基づいています。
最新の価格・在庫・配送条件などの詳細は、Amazonの商品ページをご確認ください。