【初心者向け】Unityでラムダ式＆LINQを活用するメリットと注意点

Unityでコードを書いていると、ラムダ式やLINQを使ったサンプルコードを目にする機会が増えてきますよね。
Where や First を使うと、for文よりスッキリ書けて「なんだか賢そう」に見える反面、

• これ、使っていいの？
• LINQって重いって聞いたけど大丈夫？
• for文に戻した方が安全なんじゃ…？

こんな不安を感じたことはありませんか？

特にUnity初心者〜中級者の方だと、
「とりあえず動くから使っているけど、正直よく分からない」
「後からパフォーマンス問題にならないか心配」
というモヤっとした状態になりがちです。

この記事では、ラムダ式やLINQの書き方そのものを詳しく解説することはしません。
それよりも、

• Unity開発でラムダ式・LINQは何が便利なのか
• なぜ「重い」「危険」と言われることがあるのか
• 実務では「使っていい場面／避けるべき場面」をどう判断するのか

といった判断基準にフォーカスして解説していきます。

「LINQは使うべきか、使わないべきか」という白黒の話ではなく、
状況に応じて正しく選べるようになることがこの記事のゴールです。

読み終わる頃には、
「なんとなく不安だから使わない」でも「便利だから無条件で使う」でもなく、
自分で理由を持って判断できる状態になれるはずです。

---

結論：UnityでのLINQ・ラムダ式の基本スタンス

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

Unityでラムダ式やLINQは、使っても問題ありません。
ただし、それは「使う場所と頻度を間違えなければ」という条件付きです。

よくある誤解として、

• LINQは重いから使ってはいけない
• for文に書き直せば全部正解

といった極端な意見を見かけますが、実務ではそこまで単純ではありません。

Unity開発における基本的な考え方は、とてもシンプルです。

• 毎フレーム実行される処理か？
• GCが発生しても問題ない場面か？

この2点を基準に判断します。

たとえば、

• 初期化処理や一度しか実行されない処理
• UI操作やメニュー画面のロジック

こういった場面では、LINQを使うことでコードが読みやすくなり、保守性も上がります。

一方で、

• Update 内で毎フレーム実行される処理
• 大量のデータを頻繁に走査する処理

このような箇所では、LINQやラムダ式がパフォーマンス低下やGC発生の原因になる可能性があります。

つまり重要なのは、

「LINQを使うか・使わないか」ではなく、
「この処理でLINQを使っても問題ないか？」を判断できるかどうか

---

ラムダ式・LINQの役割と「できること」

まずは、「そもそもラムダ式とLINQは何のためにあるのか？」を整理しておきましょう。

ここを曖昧なまま使ってしまうと、
「便利そうだから使う」→「なんか危なそうだからやめる」
という行き来をずっと繰り返してしまいます。

LINQは「データをどう取り出したいか」を書く仕組み

LINQ（Language Integrated Query）は、
コレクション（Listや配列など）から、欲しいデータを取り出すための仕組みです。

Unityでよくある例だと、

• 条件に合う要素だけを取り出したい
• 特定の要素が存在するか確認したい
• 最初に見つかった1件だけ取得したい

といった「検索・抽出・判定」を、
短いコードで、意図が分かりやすく書けるのがLINQの役割です。

ポイントは、
「どうやってループするか」ではなく「何を取りたいか」を表現する、という点です。

ラムダ式は「条件や処理内容をその場で書くための道具」

ラムダ式は、LINQとセットで使われることが多いですが、
役割としてはとてもシンプルです。

「この条件に合うかどうか」
「各要素に対して何をするか」
といった処理を、その場で簡潔に書くための仕組みです。

たとえば、

• HPが0以下のキャラだけ取り出す
• 特定のフラグが立っている要素を探す

こうした「条件部分」をメソッドとして切り出さず、
その場で完結させられるのがラムダ式のメリットです。

ラムダ式とLINQの本当のメリットは「可読性」

ラムダ式やLINQが評価されている最大の理由は、
コードが短くなることではありません。

本質的なメリットは、
「この処理は何をしているのか」が読みやすくなることです。

for文で書くと、

• ループの開始条件
• インデックス管理
• if文による条件分岐

といったノイズになりやすい要素が増えがちです。

LINQを使うことで、
「条件に合う要素を探している」
「1件でも存在するか確認している」
といった意図がコードから直接読み取れるようになります。

ただし、この可読性のメリットは、
使いどころを間違えると、一気にデメリットに変わる点も覚えておく必要があります。

---

for文／foreachとLINQの本質的な違い

ラムダ式やLINQを使うかどうかで迷う原因の多くは、
for文やforeachとの「考え方の違い」がはっきり理解できていないことにあります。

ここでは文法の細かい話ではなく、
「何がどう違うのか」という本質的な部分を整理します。

命令的に書くか、宣言的に書くか

for文やforeachは、いわゆる命令的（How）な書き方です。

つまり、

• どこからどこまでループするのか
• 1つずつ取り出して何をするのか

といった処理の手順を細かく指定します。

一方、LINQは宣言的（What）な書き方です。

「このリストの中から、
条件に合うものを取りたい」
という目的をコードで表現します。

この違いが、LINQが「読みやすい」と言われる理由でもあり、
同時に「よく分からない」と感じやすい理由でもあります。

可読性が上がるケース／下がるケース

LINQは、条件がシンプルなほど強力です。

たとえば、

• 1つの条件で要素を探す
• 存在チェックをする

こうした処理は、LINQの方が意図を読み取りやすくなります。

しかし、

• 条件が複数に増える
• 途中で処理が分岐する
• デバッグしながら中身を追いたい

といった場合、LINQは一気に読みにくくなることがあります。

「短い＝読みやすい」ではない、という点はとても重要です。

遅延実行というLINQ特有の挙動

LINQを使う上で、初心者が特にハマりやすいのが遅延実行です。

LINQの多くのメソッドは、
書いた瞬間に処理が実行されるわけではありません。

実際に、

• foreachで回したとき
• ToList()などで結果を確定させたとき

にはじめて処理が走ります。

この仕組みを知らないと、

• 同じLINQを何度も列挙して無駄な処理をする
• 「1回しか実行していないつもり」が実は複数回動いている

といった気づきにくいパフォーマンス問題につながります。

この章で押さえておいてほしいのは、
LINQはfor文の「上位互換」ではないという点です。

---

Unity開発でよくあるLINQ使用シーン

ここからは、Unity開発の中で実際によく使われがちなLINQのシーンを見ていきます。

「この使い方、やったことあるかも…」と感じるものがあれば、
その時点で一度立ち止まって判断できるようになるのが理想です。

よく使われる（使っても問題になりにくい）シーン

LINQが活躍しやすいのは、
処理の頻度が低く、意図をはっきり書きたい場面です。

• Listや配列から条件に合う要素を探す
• 特定の要素が存在するかを判定する（Any）
• 初期化時にデータを整理・変換する

たとえば、

• 敵リストの中から特定タイプだけを抽出する
• UI表示用にデータを整形する

といった処理は、LINQを使うことで
「何をしたいのか」が一目で分かるコードになりやすいです。

これらは多くの場合、
Awake / Start / ボタン操作など、毎フレーム実行されないタイミングで使われます。

便利そうに見えて注意が必要なシーン

一方で、初心者がやりがちなのが、
「とりあえずLINQで書いてしまう」パターンです。

特に注意したいのが、次のようなケースです。

• Update 内で毎フレームLINQを実行している
• 移動・当たり判定・AI思考などリアルタイム処理で使っている
• 要素数が多いListを毎回検索している

これらの処理は、

• 実行回数が非常に多い
• GC Allocが積み重なりやすい

という特徴があります。

コード自体は短くて綺麗でも、
ゲーム全体のフレームレート低下や、カクつきの原因になることがあります。

「見た目がスッキリしている＝安全」ではない、という点は
Unity開発では特に重要です。

---

初心者がやりがちなNG例と、なぜ問題なのか

ここでは、Unity初心者〜中級者が無意識にやってしまいがちなLINQ・ラムダ式のNG例を整理します。

どれも「コード自体は正しく動く」ため、
問題に気づきにくいのが厄介なポイントです。

NG例① Update内でLINQを使ってしまう

もっとも多く、そして影響が大きいのがこのパターンです。

Updateは毎フレーム呼ばれるため、
その中でLINQを使うと、処理コストやGC Allocがフレーム単位で積み重なります。

結果として、

• 一見軽そうな処理なのに、フレームレートが不安定になる
• 特定のタイミングでカクッとしたGCスパイクが発生する

といった問題につながります。

「1回の処理は軽いから大丈夫」という判断は、
UnityではUpdateという回数の多さによって簡単に裏切られます。

NG例② ラムダ式による外部変数キャプチャを意識していない

ラムダ式は、そのスコープ外にある変数を自動的にキャプチャします。

この仕組み自体は便利なのですが、
UnityではGCやメモリ管理の面で問題になることがあります。

キャプチャされた変数は、
デリゲートが生存している間、ヒープ上に保持され続けます。

その結果、

• 不要なメモリが解放されない
• 意図しないタイミングでGCが走る

といった挙動を引き起こすことがあります。

特に、「なんとなく書いたラムダ式」ほど、
何がキャプチャされているかを把握していないケースが多いので注意が必要です。

NG例③ 遅延実行を理解せずに何度も列挙している

LINQの遅延実行は、理解していないと見えないコストになります。

たとえば、

• 同じLINQクエリを複数回foreachしている
• 結果を使い回しているつもりで、毎回再計算している

こうしたコードは、
書いた本人の想定よりも処理が何度も走っていることがあります。

「LINQは1回書いたら終わり」ではなく、
列挙されるたびに実行されるという点は、必ず意識しておきましょう。

---

使っていい場面／避けた方がいい場面の判断基準

ここまで読んで、「じゃあ結局、いつLINQを使っていいの？」と感じているかもしれません。

そこでこの章では、
実務でそのまま使える判断基準を整理します。

難しいルールはありません。
大切なのは「場所」と「頻度」です。

使っていい場面（可読性を優先してOK）

LINQを安心して使いやすいのは、
実行回数が少なく、処理時間に余裕がある場面です。

• Awake / Start などの初期化処理
• ボタン操作・UIイベント
• メニュー画面や設定画面のロジック
• エディタ拡張・開発用ツール

これらの処理では、

• 多少のGCが発生しても問題になりにくい
• 可読性・保守性のメリットが大きい

という特徴があります。

チーム開発や、後から見返す可能性が高いコードほど、
「分かりやすく書く」価値は高くなります。

避けた方がいい場面（パフォーマンス優先）

逆に、LINQを避ける判断をした方がいいのは、
処理が高頻度で呼ばれる場面です。

• Update / FixedUpdate 内
• 毎フレーム呼ばれるAI・移動・判定処理
• 要素数の多いListを頻繁に走査する処理

これらの場所では、

• 1回あたりのコストが小さくても
• 回数が多く、GCが蓄積しやすい

という理由から、for文やforeachで明示的に書いた方が安全です。

判断に迷ったときのチェックリスト

LINQを使うかどうか迷ったら、次の3つを自分に問いかけてみてください。

• この処理は毎フレーム実行される？
• GCが発生しても問題ないタイミング？
• LINQにすることで本当に読みやすくなる？

この3つすべてに「YES」と言えない場合は、
無理にLINQを使わず、素直にfor文で書く判断も立派な選択です。

---

パフォーマンスが気になるなら「計測」が最優先

LINQやラムダ式について調べていると、
「LINQは重い」「GCが出るから危険」といった意見をよく見かけます。

ただ、ここで一番やってはいけないのが、
噂やイメージだけで判断してしまうことです。

体感やネットの声だけで判断しない

実務で大切なのは、
「実際に問題が起きているかどうか」です。

LINQを使っていても、

• 処理回数が少ない
• 要素数が小さい
• GCが発生しても問題にならない場面

であれば、パフォーマンス上の影響はほぼ無視できることも多いです。

逆に、for文で書いていても、
設計や実装次第では重い処理になることもあります。

つまり、
書き方だけで良し悪しを決めることはできません。

Unity Profilerで「事実」を確認する

そこで重要になるのが、Unity Profilerです。

Profilerを使えば、

• どの処理でCPU時間を使っているか
• どこでGC Allocが発生しているか

を数値とグラフで確認できます。

「LINQを使っているから重い」のではなく、
「このLINQが、どのくらいコストを生んでいるか」を見て判断する、という考え方です。

GC AllocやGCスパイクの仕組みについては、
こちらの記事で詳しく解説しています。

LINQをfor文に書き直すべきか悩んだときは、
「まずProfilerで見る」を習慣にしておくと、無駄な最適化を避けられます。

---

学習を一段引き上げたい人向けの参考資料

ここまで読んで、

• LINQは便利だけど、使いどころが大事
• 最終的には「自分で判断できるか」が重要

という感覚は掴めてきたと思います。

ただ、ここで多くの人が次にぶつかるのが、

「じゃあ、その判断力ってどうやって身につけるの？」

という問題です。

断片的な知識だけでは判断できない

LINQが重い、GCが怖い、Updateでは使うな。
こうした知識自体は、ネットや動画ですぐに手に入ります。

でも実務では、

• どこまでが許容範囲なのか
• 可読性とパフォーマンスをどう天秤にかけるのか
• 「今は最適化しなくていい」と判断していいのか

といった設計レベルの判断が求められます。

これらは、
個別テクニックを点で覚えているだけでは身につきません。

体系的に学ぶことで「迷わなくなる」

そこでおすすめなのが、UnityとC#を
体系的にまとめて学べる資料を一度通して読むことです。

LINQやfor文といった話も、

• パフォーマンスの考え方
• GCやメモリ管理の前提知識
• コード設計の基本方針

と結びつけて理解できるようになります。

その中でも、判断基準を作るという意味で役立つのが、次の書籍です。

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

この本は、

• 「なぜその書き方をするのか」
• 「どんな場面で注意すべきか」

といった理由ベースの解説が多く、
今回のLINQのような「白黒つけにくいテーマ」と相性がいいです。

---

よくある誤解・注意点まとめ

ここまで読んでいただいた方の中には、
「LINQは結局、怖いものなのでは？」と感じている方もいるかもしれません。

そこで最後に、Unityでラムダ式・LINQを使う際に
よくある誤解を整理しておきます。

誤解① LINQは使ったらダメなもの

これははっきり否定できます。

LINQは、
正しく使えば、可読性と保守性を大きく高めてくれる道具です。

問題になるのは、

• 実行頻度が高い場所で使っている
• GCや遅延実行の仕組みを知らずに使っている

といった使いどころを間違えたケースです。

誤解② for文に書き直せば全部正解

これもよくある勘違いです。

確かにfor文は、

• GCが発生しにくい
• 処理内容を細かく制御できる

という強みがあります。

ただし、for文で書いたコードが

• 何をしているのか分かりにくい
• 後から修正しづらい

状態になってしまっては、本末転倒です。

可読性を犠牲にした最適化も、また別のバグやミスを生みやすくなります。

誤解③ パフォーマンスは最初から完璧にすべき

Unity開発では、

「早すぎる最適化は諸悪の根源」

という考え方がよく引用されます。

最初からすべてをfor文で固めるよりも、

• まずは分かりやすく書く
• 問題が出たらProfilerで計測する
• 必要なところだけ最適化する

という流れの方が、結果的に安全で効率的です。

---

まとめ：LINQと上手く付き合うために

この記事では、Unityにおけるラムダ式・LINQについて、
「使い方」ではなく「どう判断するか」を軸に整理してきました。

最後に、重要なポイントを振り返っておきましょう。

• LINQやラムダ式は、使ってはいけないものではない
• 重要なのは「どこで」「どれくらいの頻度で」使うか
• 毎フレーム実行される処理では、パフォーマンス面で注意が必要
• 可読性のメリットが大きい場面では、積極的に使ってよい
• 迷ったら、噂ではなくProfilerで計測して判断する

「LINQは重い」「for文が正義」といった極端な考え方に寄らず、
状況に応じて選べる判断軸を持つことが、Unity開発ではとても大切です。

今回の内容をベースに、
「これはLINQで書いた方が分かりやすいな」
「ここはfor文の方が安全そうだな」
と、自分なりに理由を持って選べるようになれば十分です。

---

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

• C# のラムダ式（Lambda expressions）｜Microsoft Learn
• LINQ（Language Integrated Query）の概要｜Microsoft Learn
• System.Linq.Enumerable クラス リファレンス｜Microsoft Learn
• Unityパフォーマンス最適化のベストプラクティス｜Unity公式マニュアル
• Avoiding LINQ in Unity｜Unity公式ブログ
• When should I not use LINQ?｜Stack Overflow

---

よくある質問（FAQ）