Unityで効率的なデータ管理！リスト・辞書の活用法を徹底解説

はじめに：データ管理で詰まり始めるタイミング

Unityでゲーム制作を始めたばかりの頃は、
「とりあえず配列で管理しておけばOK」
という形でも、あまり困らずに進められることが多いです。

でも、少しずつ機能が増えてくると──
アイテムの種類が増えた
敵や弾の管理が複雑になってきた
フラグや状態管理がごちゃごちゃしてきた
こんな状況に心当たりはありませんか？

この段階でよく起きるのが、
「配列が増えすぎて、どれが何を管理しているのか分からない」
「後から修正しようとすると、思わぬ場所が壊れる」
といった 保守性の問題 です。

実はこれ、センスや経験不足が原因ではなく、
データ構造の選び方が、今の規模に合っていない だけ、というケースがほとんどなんです。

Unity（C#）には、配列以外にも
List や Dictionary といった、
ゲーム開発と相性の良いコレクションが用意されています。

この記事では、
・List / Dictionary の基本的な役割
・配列との違いと使い分けの判断基準
・実際のゲーム開発でよくある利用シーン
・初心者がやりがちなミスと注意点
を順番に解説していきます。

「とりあえず配列」から一歩進んで、
後から直しやすく、拡張しやすいデータ管理ができるようになることが、この記事のゴールです。

難しい設計理論はできるだけ使わず、
「じゃあ、どんなときに何を使えばいいの？」が分かるように説明していくので、
安心して読み進めてくださいね 🙂

---

結論：List・Dictionary・配列の使い分けは「役割」で決める

先に結論からお伝えしますね。

Unityでのデータ管理は、
「どれが正解か」ではなく「そのデータの役割に合っているか」で選ぶのが大切です。

基本となる考え方は、とてもシンプルです。

• 順番を持ち、数が増減するデータ → List
• IDや名前から素早く探したいデータ → Dictionary
• 数が固定で、軽く扱いたいデータ → 配列

たとえば、
敵キャラや弾、所持アイテムの一覧など、
「あとから増えたり減ったりする」ものを配列で管理し続けると、
コードがどんどん苦しくなっていきます。

逆に、
アイテムIDやフラグ名のように、
「このキーに対応するデータをすぐ取りたい」ものを List で探していると、
処理も読みやすさも悪くなりがちです。

ここで大事なのは、
List や Dictionary を「暗記すること」ではありません。

・このデータは順番が必要？
・数は途中で変わる？
・名前やIDで直接取り出したい？

こうした問いを立てて、
役割に合ったコレクションを選べるようになることが、この記事の一番のゴールです。

---

コレクションの基礎整理：配列 / List / Dictionary の違い

ここからは、配列・List・Dictionary の違いを、
「機能」ではなく 役割の違い という視点で整理していきます。

なんとなく使っていると違いが分かりづらいですが、
実はそれぞれ 向いている場面がかなりはっきり 分かれています。

配列（Array）の特徴と限界

配列は、Unityを始めて最初に触れることが多いデータ構造ですね。

配列の特徴をまとめると、次のようになります。

• 要素数が最初に決まる（固定長）
• インデックスで高速にアクセスできる
• 構造がシンプルで軽量

そのため、
・曜日データ
・初期配置が決まっているオブジェクト
・途中で増えない設定値の集合
といった 「変わらない前提のデータ」 には今でも十分向いています。

一方で、ゲーム開発ではどうしても、
「あとから増える」「途中で減る」データが多くなりがちです。

配列でそれをやろうとすると、
サイズを意識した管理コードが増え、
修正のたびに壊れやすい構造 になってしまいます。

List<T> の役割と強み

そこで登場するのが List<T> です。

Listは、配列と同じようにインデックスでアクセスできますが、
最大の違いは 要素数が動的に変わる ことです。

• 途中で要素を追加・削除できる
• 順番を保ったまま管理できる
• ゲーム中に増減するデータと相性がいい

たとえば、
敵キャラの一覧、発射中の弾、所持アイテムなどは、
Listで管理したほうが圧倒的にコードが楽になります。

「配列の代わりに List を使う」というより、
最初から役割が違うものと考えると理解しやすいです。

なお、配列・List・Dictionary の全体的な使い分けを、
もう少し広い視点で整理したい場合は、
こちらの記事もあわせて参考にしてみてください。

Dictionary<TKey, TValue> は「検索役」

最後に、Dictionary です。

Dictionaryは、
キー（ID・名前など）から値を直接取り出す ためのコレクションです。

Listのように順番で探すのではなく、
「このキーに対応するデータは何？」
という取り出し方をします。

そのため、
・アイテムID → アイテム情報
・ステータス名 → 数値
・フラグ名 → 状態
といった 対応表のようなデータ にとても向いています。

ここまでで、
「順番・増減」なら List、
「キー検索」なら Dictionary、
「固定データ」なら 配列、
という大枠のイメージがつかめてきたと思います。

---

List<T> の実践的な使いどころ

ここからは、List<T> が実際のゲーム開発でどんな場面に向いているのかを見ていきましょう。

Listは「配列の上位互換」のように思われがちですが、
本質はそこではなく、
「増えたり減ったりする前提のデータを、安全に管理するための器」です。

ゲーム開発でよくある List の利用例

Unityで List が活躍する代表的なシーンは、次のようなものです。

• 現在シーンに存在している敵キャラの一覧
• 発射中・生存中の弾オブジェクト
• プレイヤーが所持しているアイテム一覧
• UIに表示するログや履歴データ

これらに共通しているのは、
ゲーム中に数が変わるという点です。

もし配列で管理しようとすると、
「何番目が空いているか」
「サイズを超えたらどうするか」
といった余計な管理コードが増えてしまいます。

List を使えば、
追加は Add、削除は Remove や RemoveAt で済み、
本来書きたいゲームロジックに集中できるようになります。

List を使うときの注意点

便利な List ですが、
初心者の方がつまずきやすいポイントもいくつかあります。

foreach 中に Add / Remove できない

List を foreach で回している最中に、
Add や Remove を行うと、例外が発生します。

これは Unity 特有の制限ではなく、
C# の仕様によるものです。

ループ中に要素を変更したい場合は、

• for 文で後ろから回す
• 削除対象を別リストに一時保存する

といった方法を取る必要があります。

パフォーマンスと Capacity の考え方

List は内部的に配列を使っており、
要素数が増えすぎると、自動的に容量（Capacity）が拡張されます。

通常は気にしなくて問題ありませんが、
最初から大量に追加すると分かっている場合は、
初期容量を指定しておくことで無駄な再確保を減らせます。

ただし、
最適化を意識しすぎてコードが読みにくくなるのは本末転倒なので、
「必要になってから考える」くらいで大丈夫です 🙂

---

Dictionary<TKey, TValue> の役割と本領

次は Dictionary<TKey, TValue> です。

List に慣れてきた頃に、
「これ、Listで管理するのちょっと苦しくない？」
と感じ始めたら、Dictionary の出番です。

Dictionary は、
キー（Key）と値（Value）をセットで管理するコレクションです。

List が「順番で管理する箱」だとしたら、
Dictionary は 辞書・対応表 のようなイメージになります。

Dictionary が向いているデータ構造

Dictionary が本領を発揮するのは、
「この名前（ID）に対応するデータをすぐ取りたい」という場面です。

たとえば、こんなケースですね。

• アイテムID → アイテムの詳細データ
• ステータス名 → 数値（HP / ATK / DEF など）
• フラグ名 → 現在の状態

これらを List で管理すると、
毎回ループして探す必要があり、
コードも意図も分かりづらくなってしまいます。

Dictionary なら、
キーを指定するだけで一発で取得できるため、
「何をしたいコードなのか」が非常に読みやすくなります。

なぜ Dictionary は高速なのか（ざっくり）

Dictionary が高速な理由は、
内部で ハッシュテーブル という仕組みを使っているからです。

難しく考える必要はなく、
「要素が増えても、探す速さがほとんど変わらない」
という理解で十分です。

そのため、
アイテム数やフラグ数が増えても、
パフォーマンスを気にせず使いやすい、という強みがあります。

ただし、
キーは必ず一意である必要がある
という点には注意が必要です。

---

Dictionary の実務利用シーンと設計例

ここからは、Dictionary<TKey, TValue> が
実際のゲーム開発でどのように使われるのかを、
もう一歩踏み込んで見ていきましょう。

Dictionary は「便利だから使う」というより、
設計をシンプルに保つために使うコレクションです。

アイテム・ステータス・フラグ管理

Dictionary が特に力を発揮するのが、
名前やIDで管理したいデータです。

たとえば、アイテム管理の場合、

• アイテムID → アイテム情報
• アイテム名 → 所持数

といった形で管理できます。

List でこれをやろうとすると、
「IDが一致する要素を探す」処理が必要になりますが、
Dictionary なら キー指定だけで完結します。

同じ考え方は、
ステータス管理やゲーム進行フラグにも使えます。

フラグ管理については、
単純な bool の乱立が後から破綻しやすいため、
設計として Dictionary を使うメリットが大きいです。

TryGetValue を使うべき理由

Dictionary を使ううえで、
ぜひ覚えておきたいのが TryGetValue です。

Dictionary には、
dictionary[key] で値を取得する方法もありますが、
キーが存在しない場合、例外が発生します。

一方 TryGetValue を使えば、

• キーが存在するかどうかを同時に確認できる
• 例外を出さずに安全に処理できる

というメリットがあります。

ゲーム開発では、
「存在しない可能性があるデータ」を扱う場面が多いため、
TryGetValue を前提に設計するだけで、
バグに強いコードになります。

---

初心者がやりがちなミス集

List や Dictionary はとても便利ですが、
使い始めの頃は「知らないと普通に踏む」落とし穴もいくつかあります。

ここでは、
Unity初心者〜中級者の方が 実際によくハマるミス を中心に、
理由とあわせて整理しておきましょう。

foreach 中の変更でエラーが出る

List を foreach で回している最中に、
Add や Remove を行うと、
InvalidOperationException が発生します。

これは Unity の仕様ではなく、
C# のコレクション全体のルールです。

「ループしながら消したい」という場合は、
次のような方法を取ります。

• for 文で後ろからループする
• 削除対象を別の List に一時的に溜めて、後でまとめて処理する

この制約を知らないと、
「なぜここで落ちるの？」とかなり混乱しやすいポイントなので、
仕様として覚えておくのがおすすめです。

Dictionary のキー重複・存在確認ミス

Dictionary で多いのが、
キーに関するミスです。

Dictionary では、
キーは必ず 一意（重複不可） である必要があります。

すでに存在するキーに対して Add を行うと、
例外が発生してゲームが止まります。

そのため、

• 追加前に ContainsKey で確認する
• 取得時は TryGetValue を使う

といった 防御的な書き方 をするのが基本です。

データ管理が肥大化する原因

もう一つ、設計面でよくあるのが、
「全部を1つのクラスに詰め込んでしまう」ことです。

List や Dictionary 自体は正しく使えていても、

• 管理用クラスが巨大になる
• どこで何を変更しているのか分からない

といった状態になると、
結果的にメンテナンスが大変になります。

「データを持つ責務」と
「処理を行う責務」を分けるだけでも、
コードの見通しはかなり良くなります。

---

「保存・表示・管理」が絡むときの発展的な考え方

List や Dictionary を使いこなせるようになると、
次にぶつかりやすいのが、
「データをどう管理・保存・表示するか」という問題です。

特に、
・Inspector で中身を確認・編集したい
・セーブ／ロードを簡単にしたい
といった要望が出てくると、
List / Dictionary だけでは少しつらく感じる場面が増えてきます。

Inspector 管理を楽にしたい場合

Unity標準の Inspector では、
Dictionary はそのままでは表示・編集ができません。

その結果、
「中身が見えないからデバッグしづらい」
「設定ミスに気づきにくい」
といった問題が起こりがちです。

こうした Inspector 周りのストレスを一気に解消してくれるのが、
Odin Inspector and Serializer です。

✅アセットストアでチェックする

Odin を使うと、
Dictionary を含む複雑なデータ構造でも、
Inspector 上で直感的に確認・編集できるようになります。

「設計はできているのに、確認がつらい」
と感じ始めたタイミングで導入すると、
効果を実感しやすいアセットです。

セーブデータと組み合わせる場合

次に悩みやすいのが、
List や Dictionary をどう保存するかという点です。

自前で JSON 化やバイナリ保存を書くこともできますが、
ゲームロジックとは別の部分で手間がかかりがちです。

そうしたセーブ周りを、
まとめて安全に任せられるのが Easy Save 3 です。

✅アセットストアでチェックする

Easy Save 3 は、
List や Dictionary を含むデータを、
ほぼそのまま保存・ロードできるのが大きな強みです。

「まずはゲームを完成させたい」
「セーブ処理で詰まりたくない」
という場合には、かなり心強い選択肢になります。

なお、
データ管理全体の考え方としては、
Serializable や ScriptableObject と組み合わせる設計も重要です。

---

学習を一段深めたい人向け

ここまでで、
List・Dictionary・配列の役割や使い分けについては、
かなり整理できたと思います。

ただ、実際のゲーム開発では、
・データ構造の選択
・クラス設計
・処理の流れ
が絡み合ってくるため、
「なんとなく分かった」から「自信を持って書ける」までには、
もう一段ステップがあります。

そのステップを埋めるのに役立つのが、
Unityゲーム プログラミング・バイブル 2nd Generation です。

✅ Amazonでチェックする ｜ ✅ 楽天でチェックする

この書籍は、
単なるコード例集ではなく、
「なぜその設計にするのか」という背景まで丁寧に解説されています。

List や Dictionary の話も、
より大きな設計の文脈の中で理解できるため、
「場当たり的に書いていたコード」が、
一本筋の通ったコードに変わっていく感覚を得やすいです。

今すぐ全部を理解しなくても、
「困ったときに戻ってこられる一冊」として手元にあると、
かなり心強いと思います。

---

まとめ：とりあえず配列から卒業しよう

今回は、Unity（C#）における
配列・List・Dictionary の使い分けについて解説してきました。

ポイントをあらためて整理すると、次のとおりです。

• 配列：要素数が固定で、構造がシンプルなデータ向け
• List：順番を保ちつつ、増減するデータ向け
• Dictionary：IDや名前など、キーから素早く取り出したいデータ向け

大切なのは、
「どれが一番すごいか」ではなく、
そのデータがどんな役割を持っているかを考えることです。

最初は配列だけで問題なくても、
ゲームが少しずつ成長していくにつれて、
データ管理の負担は確実に増えていきます。

そこで List や Dictionary を適切に使えるようになると、
・修正が怖くなくなる
・コードの意図が読みやすくなる
・後から機能を追加しやすくなる
といったメリットを実感できるようになります。

「とりあえず配列」で進めてきた方こそ、
一歩だけ設計を意識することで、
Unityでの開発がぐっと楽になるはずです。

ぜひ今回の内容を参考に、
自分のプロジェクトのデータ管理を、
少しだけ見直してみてくださいね 🙂

---

参考文献・公式ドキュメント

• List<T> クラス（Microsoft Learn）
• Dictionary<TKey, TValue> クラス（Microsoft Learn）
• foreach ステートメント（C# 言語リファレンス）
• .NET のコレクションとデータ構造（Microsoft Learn）
• Unity Script Reference（公式ドキュメント）
• ArgumentException クラス（Microsoft Learn）
• Hashtable と Dictionary コレクションの種類（Microsoft Learn）

---

よくある質問（FAQ）