Unityでスクリプトを書き始めてしばらくすると、ほとんどの人が一度は「配列」で詰まります。
IndexOutOfRangeException が出たり、クリックしたオブジェクトを追加したいだけなのにうまくいかなかったり…。
「配列ってこんなに難しかったっけ?」
そう感じているなら、それはあなたの理解力の問題ではありません🙂
実はUnity初心者が配列でつまずく原因の多くは、配列そのものではなく「使い分け」を知らないことにあります。
Unityでは配列のほかに List や Dictionary といった便利なコレクションがあり、ゲーム制作ではこちらを使う場面のほうが圧倒的に多いです。
それなのに、
- とりあえず配列を使っている
- ListとDictionaryの違いがあいまい
- 「動いたからOK」でそのままにしている
こうした状態のまま進むと、後から修正が大変になったり、コードが一気に読みにくくなってしまいます。
この記事では、Unity初心者の方に向けて
- なぜ配列で詰まりやすいのか
- 配列・List・Dictionaryの違い
- クリック・接触処理での実践的な使い分け
- 実務でも通用する考え方
を、できるだけ感覚的に、そして実際のゲーム制作をイメージしながら解説していきます。
「どれを使えばいいか分からない…」という迷いがなくなり、
自信を持ってデータ構造を選べるようになるのがゴールです✨
結論|Unity初心者は配列にこだわらなくていい
先に結論からお伝えしますね。
Unity初心者のうちは、配列を無理に使う必要はほとんどありません。
実際のゲーム制作では、配列よりも List と Dictionary が主役になります。
判断基準はとてもシンプルです。
- 数が増えたり減ったりする → List
- ID・名前・キーで直接取り出したい → Dictionary
- 要素数が完全に固定で変わらない → 配列
「迷ったらList」「識別が必要ならDictionary」。
これだけ覚えておくだけでも、配列エラーで悩む時間は一気に減ります。
配列がダメというわけではありません。ただし、
- 初心者には扱いがシビア
- ゲームの仕様変更に弱い
- エラーの原因になりやすい
という特徴があるため、最初からメインで使うと遠回りになりがちなんです。
このあとで、
「なぜ配列で詰まるのか」
「実際のクリック・接触処理ではどう使い分けるのか」
を順番に見ていきます。

ここを理解できると、コードの書きやすさも、あとからの修正のしやすさも、かなり変わってきますよ🙂
なぜ配列で詰まるのか
まず、Unity初心者が配列でつまずきやすい理由を整理しておきましょう。
ここを理解すると、「自分がダメだったわけじゃないんだ」と腑に落ちるはずです。
① 配列は「固定長」という制約がきつい
配列の一番の特徴は、最初に要素数を決める必要があることです。
でもゲーム開発では、
- 敵の数が変わる
- アイテムの所持数が増減する
- クリックや接触でオブジェクトが追加・削除される
こういった「あとから数が変わる」場面がほとんどですよね。
それなのに配列を使うと、
- 要素が足りない
- 空きが無駄に残る
- 結局作り直す
という状態になりがちです。
初心者ほど、この固定長の制約に苦しめられます。
② インデックス管理が地味に難しい
配列は「0」から始まる番号(インデックス)で管理されます。
これが原因で、
- 1番目と0番目を混同する
- 存在しない番号を指定する
- IndexOutOfRangeException が出る
といったミスが頻発します。
特にクリック処理や接触処理では、
「今どこまで入っているのか」を常に意識しなければならず、頭が混乱しやすいんです。
③ 初期化忘れでエラーが出やすい
配列は宣言しただけでは使えません。new を使って実体を作らないと、すぐにエラーになります。
この結果、
- NullReferenceException が出る
- 原因が分からず時間を溶かす
という、初心者にとってかなりつらい体験をしがちです。
配列が悪いわけではない
ここまで読むと「配列ってダメじゃん…」と思うかもしれませんが、そうではありません。
配列は、
- 要素数が完全に決まっている
- 構造が変わらない
こうしたケースでは、今でもしっかり使われています。
ただし、Unity初心者が最初に触る用途とは相性が悪い、
これが配列で詰まりやすい一番の理由です。

次は、配列・List・Dictionaryをどう使い分ければいいのかを、
もっと直感的に整理していきましょう🙂
配列 / List / Dictionaryの違い
ここでは、配列・List・Dictionaryの違いを、
「どんな場面で使うか」という視点で整理していきます。
細かい文法よりも、まずは役割の違いをつかむのが大切です🙂
配列:サイズが決まっている「固定の箱」
配列は、最初に決めた数だけ要素を入れる箱です。
- 要素数は変更できない
- 番号(インデックス)で管理する
- 構造がシンプルで高速
向いているのは、
- 曜日(7日分)
- ステージ数が固定のゲーム
- 絶対に数が変わらない設定データ
逆に、「あとから増えるかも?」という時点で、配列は不向きです。
List:増えたり減ったりする「名簿」
Listは、Unityで最もよく使われるコレクションです。
- 要素の追加・削除が自由
- 順番を保ったまま管理できる
- 扱いが直感的で初心者向き
たとえば、
- 所持アイテム一覧
- 現在フィールドに存在する敵
- クリック・接触したオブジェクトの管理
こうした「数が変わるもの」は、ほぼListで問題ありません。
「とりあえずListにしておく」は、
実務でもかなり現実的な判断です。
Dictionary:名前やIDで一発取得できる「名簿+タグ」
Dictionaryは、キー(名前・ID)と値をセットで管理します。
- キーを指定して即アクセスできる
- 順番より「識別」を重視
- 大量データでも高速
向いているのは、
- ID付きアイテム管理
- 敵ID → ステータス
- レベル番号 → データ
「〇番目」ではなく、
「このIDのデータが欲しい」という場面で真価を発揮します。
途中まとめ|まずはこう覚えよう
- 配列:数が変わらないデータ
- List:増減するデータ
- Dictionary:IDや名前で管理したいデータ
この整理ができるだけで、
「どれを使えばいいか分からない…」という迷いは、かなり減ります。

次は、実際のゲーム制作でよくある
クリック・接触処理を例に、さらに具体的な使い分けを見ていきましょう✨
クリック・接触時の使い分け例
ここからは、Unityのゲーム制作で特に登場回数が多い
「クリック」や「接触(Trigger / Collision)」を例に、使い分けを具体的に見ていきます。
この章を読むと、
「あ、この場面はListだな」「ここはDictionaryのほうが楽だな」
と自然に判断できるようになります🙂
① アイテムの取得・削除は List が向いている
プレイヤーがアイテムに触れて取得する、という処理を考えてみましょう。
- 取得すると増える
- 使うと減る
- 順番が意味を持つこともある
この条件、Listと相性がとてもいいですよね。
Listを使えば、
Add()で追加Remove()で削除
と直感的に書けるため、
配列のようにインデックス管理で悩むことがほぼなくなります。
② 接触したオブジェクトを記録したい場合も List
「今どのオブジェクトに触れているか」
「一度でも触れたものを覚えておきたい」
こうしたケースでもListが便利です。
接触イベントは発生回数や対象が変わりやすいため、
固定長の配列とは相性がよくありません。
「とりあえずListに追加しておく」だけで、
後から処理を広げやすくなります。
③ クリック削除+管理も List が安定
クリックしたオブジェクトを削除しつつ、
その情報をどこかに残したい、という場面もよくあります。
この場合も、
- 削除前にListに記録
- 削除後も履歴として保持
といった柔軟な処理がしやすく、Listの強みが活きます。
④ 「このIDのデータが欲しい」は Dictionary
一方で、次のようなケースではListよりもDictionaryが向いています。
- オブジェクトにIDが振られている
- 名前や番号で直接アクセスしたい
- 毎回ループしたくない
たとえば、
- 敵ID → ステータス
- アイテムID → データ
こうした対応表をListで管理すると、
毎回for文で探す必要が出てきます。
Dictionaryなら、
キーを指定するだけで一発取得できるので、
処理もコードもシンプルになります。
ここまでの整理
- クリック・接触で増減する → List
- 履歴や一覧管理 → List
- ID・名前で直接取得 → Dictionary
「配列じゃないとダメな場面」は、
実はこの手の処理ではほとんどありません。

次は、こうした知識を踏まえて、
実務ではどんな設計がされているのかを見ていきましょう✨
実務ではこう設計する
ここまでで、配列・List・Dictionaryの役割はかなり整理できたと思います。
では実際の開発現場では、これらをどう組み合わせて設計しているのでしょうか。
ポイントは、「エラーを出さない」「あとから壊れない」設計です。
① Dictionaryは安全に使う(TryGetValue / TryAdd)
Dictionaryはとても便利ですが、
存在しないキーを指定すると例外が出るという弱点があります。
そのため実務では、
- 直接
dic[key]で取得しない TryGetValueを使って存在チェックをする
という書き方がほぼ必須です。
「あれば使う、なければ何もしない」
この安全確認を入れるだけで、バグの発生率は大きく下がります。
② DictionaryのValueに「クラス」を入れる
初心者のうちは、Dictionaryの中身(Value)にint や string を入れがちです。
でも実務では、
- ステータス
- 設定値
- 参照したいオブジェクト
こうした情報をひとまとめにしたクラスをValueに入れます。
たとえば、
「レベルID → レベルデータクラス」
のような構成ですね。
こうしておくと、
- データが増えても管理しやすい
- 後から仕様変更に強い
- コードの見通しが良くなる
というメリットがあります。
特にScriptableObjectと組み合わせる設計は、
中規模以上のプロジェクトでは定番になっています。
③ Listの「全検索」はいずれ重くなる
Listは便利ですが、
要素数が増えるほど「探す処理」が重くなります。
たとえば、
- 毎フレームListをfor文でチェック
- 数百〜数千のオブジェクトを検索
こうした処理は、後からパフォーマンス問題の原因になりがちです。
実務では、
- 一覧管理 → List
- 頻繁に参照するもの → Dictionary
と役割を分けて両方使うことがよくあります。
④ 最初から「増える前提」で考える
初心者のうちは、
- 今は3個しかない
- とりあえず動けばOK
と考えがちですが、実務では逆です。
「将来10倍に増えたらどうなるか」
これを軽く想像するだけで、選ぶべき構造は自然と見えてきます。
ここまで理解できれば、
配列・List・Dictionaryの使い分けは、もう「勘」ではなく
理由を持って選べる状態になっています🙂

次は、初心者が特にやりがちな誤解や勘違いをまとめて整理していきましょう。
よくある誤解・初心者がやりがちなミス
最後に、Unity初心者の方がかなりの確率でハマる誤解を整理しておきます。
ここを知っておくだけでも、無駄に悩む時間を減らせますよ🙂
①「配列を使わない=ダメなコード」ではない
C#の基礎を学ぶと、最初に配列が出てくることが多いですよね。
その影響で、
- 配列を使わないといけない気がする
- Listを使うのは逃げている感じがする
こう思ってしまう人がとても多いです。
でも実際のUnity開発では、
ListやDictionaryを使うのが普通です。
「配列を使わない=悪」ではなく、
用途に合ったものを選んでいるだけなので、安心してください。
② Dictionaryで「順番」を管理しようとする
Dictionaryはとても便利ですが、
順番を前提にした管理には向いていません。
「1番目、2番目…」という考え方を持ったまま使うと、
- 思った順で取り出せない
- 処理が複雑になる
といった違和感が出てきます。
順番が大事ならList、
識別が大事ならDictionary。
この役割分担を崩さないのがコツです。
③ for文ループ前提の思考から抜けられない
初心者のうちは、
- 何か探す=for文で回す
という発想になりがちです。
もちろんそれ自体は間違いではありませんが、
データ量が増えると一気に重くなります。
「毎回ループしなくても、
キーで直接取れる構造にできないかな?」
と一度考えてみるだけで、設計レベルはぐっと上がります。
④ 「今動いているからOK」で止めてしまう
Unity初心者あるあるですが、
- とりあえず動いた
- 深く考えず次に進む
これを繰り返すと、あとから修正が地獄になります。
今回紹介したように、
- 増える?減る?
- 識別が必要?
- 後から仕様変更しそう?
この3点を少し考えるだけで、
「壊れにくいコード」に近づいていきます。

次はこの記事の内容をまとめつつ、
今後どう学んでいくと良いかを整理していきます✨
まとめ
今回は、Unity初心者がつまずきやすい
配列・List・Dictionaryの使い分けについて解説してきました。
ポイントをもう一度整理すると、次のとおりです。
- 配列は「数が完全に固定」のデータ向け
- Listは「増えたり減ったりする」データ向け
- Dictionaryは「ID・名前で直接取り出したい」データ向け
Unity初心者が配列で詰まりやすいのは、
理解力が足りないからではなく、用途に合っていない選択をしているだけです。
特に、
- クリック・接触で増減するもの
- 後から仕様変更しそうなもの
こうしたデータを配列で管理しようとすると、
エラーや書き直しが一気に増えてしまいます。
「迷ったらList」
「識別が必要ならDictionary」
まずはこの2つを基準に考えるだけで、
コードはぐっと書きやすく、読みやすくなります🙂
今回の内容を意識しながらコードを書いていくと、
あとから自分が見返しても理解できるコードになっていきますよ。
参考文献
- Unity/C#における配列・List・Dictionaryの基本整理(Qiita)
- 【C#基礎】配列・List・Dictionaryの違いと使い分け
- C#のListとDictionaryの違いを初心者向けに解説(侍エンジニア)
- C#のコレクション(配列・List・Dictionary)の考え方まとめ
- Unity×C# Dictionaryの実践的な使い方
- What is the difference between List and Dictionary in C#?(Stack Overflow)
- C# Collections Explained – List vs Dictionary(YouTube)
よくある質問(FAQ)
- QUnity初心者は配列を使わなくていいですか?
- A
基本的には問題ありません。
実際のUnity開発では、
ListやDictionaryをメインに使うケースのほうが圧倒的に多いです。配列は「数が完全に固定」と分かっている場面で、
必要になったときに使えれば十分です。
- QDictionaryはいつから使うべきですか?
- A
次のように感じたタイミングが使いどきです。
- IDや名前で直接データを取りたい
- 毎回for文で探すのが面倒
- データ数が増えてきた
この段階に来たら、Dictionaryを使うことで
コードも処理も一気にスッキリします。
- Q今はListで作っていますが、あとからScriptableObjectに移行できますか?
- A
はい、できます。
ListやDictionaryで役割を分けて設計していれば、
後からScriptableObjectに置き換えるのはそこまで大変ではありません。むしろ、今回の考え方は
将来ScriptableObjectへ進むための土台になります。まずは「正しく使い分ける」ことを意識しながら、
少しずつレベルアップしていきましょう✨













※当サイトはアフィリエイト広告を利用しています。リンクを経由して商品を購入された場合、当サイトに報酬が発生することがあります。
※本記事に記載しているAmazon商品情報(価格、在庫状況、割引、配送条件など)は、執筆時点のAmazon.co.jp上の情報に基づいています。
最新の価格・在庫・配送条件などの詳細は、Amazonの商品ページをご確認ください。