こんにちは、美空だよ。
年末ってさ、部屋のホコリもヤバいけど……Unityの情報量もヤバくない？ 新しいバージョン、機能の更新、パッケージの動き、そして「結局ウチのプロジェクトはいつ何を上げればいいの？」問題。 気づいたらタブが増殖して、読むだけで一日終わるやつ。ほんと、情報の雪崩。
だから今回は、2025年に「Unityでいってみよう！」で特に読まれた記事を軸にして、今年のUnityを“迷子にならない形”で整理するよ。
ポイントはこの3つ。ここを押さえれば、来年の判断がちょっとラクになるはず。
LTSと“移行判断”：いつ上げる？何が変わる？何を先に潰す？
レンダリングの将来像：URP/HDRPはどうなる？「統合」の本当の意味は？
現場の困りごと解決：GPU選択みたいな“即効性のある初手”、音の新基盤の見通し
まずはTop5から。ここが今年の“みんなの関心の中心”ってわけ。
続きを読む
こんにちは、美空です！
Unity の自動化って便利なんだけど、たまに「え、ここで止まるの!?」みたいな罠があるのよね。今回はその代表、WaitForEndOfFrame が UnityEditor の -batchmode 実行では使えない話。
「CI で EditMode テストが固まる」「バッチで走らせるとコルーチンが返ってこない」みたいな現象に心当たりある人、たぶんここが刺さる。
続きを読む
Unity 6000.3.0f1で「Editor Assemblies Compatibility Level」をお試しで .NET Standard に切り替えたら、URPのEditorコードで System.Runtime.Remoting.Messaging が見つからないエラーが出て、Playモードに入れなくなった……という事例のまとめです。
どの設定を変えると再現するのか、「なんで.NET Standardだとダメなの？」という仕組みの話と、現状取りうるワークアラウンド（.NET Frameworkに戻す／URPパッケージをいじる）を、Unity中上級者向けに整理していきます。
続きを読む
こんにちは、美空です！
Unity 6.3 LTS が正式リリースされたので、公式ライブ配信（2025年12月4日）を見ながら、気になったポイントをまとめてみたよ。
Unity 6 系はもうしばらく前から使ってる人も多いと思うけど、6.3 はいわゆる 「長期サポート版（LTS）」。サポート期間は基本2年（Enterprise/Industryは＋1年）で、「とりあえずここを基準にしておけば安心」という、いわば“避難所”的ポジションのバージョンだね。
で、今回の 6.3 の一番の売りは、単に「不具合が減りました〜」じゃなくて、
「Production Verified（本番・実戦で検証済み）」のLTSですよ！
と、めちゃ強気に打ち出しているところ。
ライブ配信の中でも、V Rising や Den of Wolves みたいな実タイトルの制作現場でドッグフーディングしてきたって話が何度も出てきてて、「あ、これは“使わせてから出す”方向にかなり振ってきてるな〜」という印象だったよ。
続きを読む
2026年1月1日にテキサス州で施行される App Store Accountability Act（Texas SB2420） に合わせて、Google は Play Age Signals API (beta)、Apple は Declared Age Range API を出してきました。
これによって、「ストアが持っている年齢シグナルをアプリ側が受け取って、未成年ユーザー向けに挙動を切り替える」という前提が、かなり現実味を帯びてきています。
一方 Unity 側は、Discussions で「ローカル法対応の専用プラグインは出さない」「コンプライアンスは開発者の責任」というスタンスを表明しました。
この記事では、Unity エンジニア目線で、
そもそも何が起きているのか
ストア / Unity / 自分たちアプリの“責任分界線”はどこか
じゃあ Unity プロジェクトとして、どういう設計をしておけばいいのか？
をまとめていきます。
続きを読む
こんにちは、美空だよ！
Unite 2025 のセッションの中でも、エンジニア的に一番「腹を括るため」に見ておきたいのが、
The Unity Engine roadmap
っていうセッション。例の YouTube のあれだね。
Unite 2025 の「The Unity Engine roadmap」は、
「Unity 6 をこれから数年どう育てていくのか」をまとめて見せるセッションだったよ。
キーワードはこの3つ：
Develop（作る）
Deploy（届ける）
Grow（育てる）
しかも、今回は単に「エンジンの新機能紹介」だけじゃなくて、
品質保証とリリースサイクル
パッケージやアセットストアを含めたエコシステム
プラットフォームサポート（Switch 2 / XR / モバイル…）
ライブゲーム、ゲーム内エコノミー、IAP
そしてエージェントAI
まで含めた、「Unity 全体」のロードマップになってるのが特徴。
セッション自体は英語だけど、
今は YouTube の自動翻訳の日本語音声＆字幕が使えるから、気になる人は本編もぜひどうぞ。
この記事では、その内容を現場の Unity エンジニア視点で整理しつつ、
「じゃあ、実際のプロジェクトで何を意識しておけばいいの？」
というところまで落としていくけど、もの凄く長くなってしまったので、最後のまとめや目次から気になる所だけをチェックしてもOKだよ。
目次
まず最初の大きな話が、プロダクション検証（Production Validation / PV）。
Unity はここ数年、
「ちゃんとゲーム作りながらエンジンを検証してよ！」
というユーザーの声に本気で振り切っていて、
自社タイトル（例：Switch のローンチに合わせた 『Survival Kids』）
外部スタジオ（Tin Chambers, Stunlock, Kinetic Games など）
と一緒に、実プロジェクトの中で新機能を試してから出荷する流れを作ってる。
プログラムはざっくり3本柱：
内部プログラム
Unity Studio Productions / Consulting とプロダクトチームが直接組む
パートナーカウンシル
外部スタジオに機能のアーリーアクセスを配り、会議やテストでフィードバック収集
コード共有
これを通じて、Unity が言っていたのが
「リリースされる前に“プロダクションフィットネス”を満たすようにする」
というスタンス。
要するに「ユーザーに渡る前に、現場で一回殴らせろ」ってことだね。
セッションでは、内部の成果指標もいくつか数字付きで出てた：
社内での問題検出率：60% → 70% に向上
高優先度リグレッションの平均修正時間：43% 短縮
Unity 6.0 LTS は、すでに 約 600 万ダウンロード
さらに、Unity 6 系のリリースモデルはこう整理されてる：
6.0 LTS
最初の LTS。「土台」のバージョン
6.1 / 6.2
新機能や改善を積み増すサポート付きアップデート
6.3 = 次の LTS
セッション時点では「数週間以内に出荷」として紹介
2026 年：6.4 / 6.5 / 6.6 / 6.7
四半期アップデートを経て、6.7 が次の LTS に
ポイントは、
「でかい変化を LTS の節目ごとにドカンと入れるんじゃなくて、
間の 6.1 / 6.2 / 6.4… みたいなアップデートで細かく刻んでいく」
っていう方針になってきていること。
品質周りで、もうひとつ重要なのが
Developer Data Framework（DDF）＋新しい診断機能の話。
Unity は「データ処理者」として動くことを明確にしつつ
クラッシュや ANR、パフォーマンス問題などのシグナルを共通方式で集める枠組みを作っている
新規プロジェクトでは、エンジン診断がデフォルト ON（いつでもオフにできる）
6.3〜6.4 では、
新しいエンジン診断ダッシュボード
アラート／カスタムロギングブレッドクラム
分析との統合
Crashlytics / Google Play Console などで Unity スタックトレースと一緒に見るフロー
が強化されていく予定。
さらに、2022 LTS や 6.0LTS にも後方展開されるけど、その場合は手動で有効化が必要という位置づけ。
今後は
「LTS → LTS 一気に飛ぶ」より、「同一メジャー内で小刻みに追う」方が楽になりそう
DDF と診断機能は、
単なる“クラッシュレポートツール”じゃなくて、
Unity 本体の修正優先度に影響するデータ源になる可能性が高い
既存プロジェクトでも
「とりあえず DDF を有効にしておく」価値は十分ありそう
次のトピックは、Unity Core Standards と パッケージ署名の話。
今の Unity って、
…みたいに、拡張機能の入手ルートがやたら多い。
便利だけど、そのぶん
「これ、本当にオリジナルのまま？
誰が作った何バージョン？」
っていう セキュリティ＆トレーサビリティの問題 がデカくなってきてる。
そこで Unity が出してきたのが、
という「コア標準」の取り組み。
Unity 6.3 からは、
パッケージが署名されているか
誰により署名されているか
出所が検証されているか
を、パッケージマネージャー上で視覚的に確認できるようになる。
ざっくりいうと：
Unity / 組織 / 検証済みパブリッシャーによる署名 → 緑のインジケーター
署名はあるけどカスタムレジストリ由来 → 情報付きで表示
未署名パッケージ → エラー／警告表示（使うこと自体は可能）
さらに、Asset Store側も UPM フォーマットでの配布へ移行していく予定で、
パブリッシャーは公式フローで署名＆バージョニング
Unity は署名者を検証済みとしてマークできる
という構図に持っていこうとしている感じ。
今後は
「署名されているパッケージを優先して使う」という運用が安全側になりそう
社内向けパッケージでも、
CI で署名するフローを作っておくと、後々かなり楽になるはず
「とりあえず GitHub の怪しい UPM を引っ張ってくる」は、
だんだんリスクが目立つ動きになっていきそう
Unity Hub とエディター周りは、「地味だけど効く」QoL 改善が多め。
Hub
UI 更新
拡張された設定
新しい通知機能
6.3 からは マルチプレイテンプレートやビルディングブロックも Hub 経由で利用可能に
Version Control
エディターツールバーからの状態確認と操作
Hierarchy でロック中シーンのアイコン表示
ブランチ切り替えがスムーズになるよう改善
Unity 6.3〜6.4 では：
Editor Status ウィンドウ（6.4）
→ プロジェクトのパフォーマンスやヘルス指標をまとめて表示
検索機能の刷新
LMDB 連携の新データベースで超大型プロジェクトの検索も高速化
UI Toolkit で作り直された新 Hierarchy は
ゲームオブジェクトタイプ別アイコン
カスタムカラム
横スクロール対応
とにかく、
「巨大プロジェクトでの編集体験を、ちゃんとスケールさせよう」
っていう意思を感じる。
UI Toolkit は、完全に「これからの UI の本命」に据える感じで話されてた。
6.2：World Space UIに対応（3D空間内に UI 配置するやつ）
6.3：
Accessibility：
一方で、Unity 側もちゃんと分かってるのが、
「今動いてる大半のゲームは uGUI でできている」
という事実。
なので、
Survival Kids を含む実プロジェクトで uGUI をガッツリ使い、
ボトルネックを調査し、
パフォーマンス改善や TextMesh Pro × Addressables 連携などを強化
…といった投資も続ける、と明言されてた。
6.2：実験的なパッケージとして登場
6.4：エディターのコアモジュールに昇格
→ これからの「ノードベース編集の共通フレームワーク」という立ち位置
今後：
6.3 で「初登場以来最大のアップグレード」と紹介されてた
UI / 地形 / スタイライズ用など、多くのグラフィック機能をカバーするテンプレート
ネストプロパティ、最大 8 UV などの機能拡張
6.5 ではステンシル設定のサポート追加予定
6.2：メッシュ / スキンメッシュの自動 LOD 生成と管理フローを導入
今後：
さらに、RenderGraph を各 SRP の共通バックエンドにしていくことで、
「HDRP と URP のあいだで機能やバックエンドをなるべく共有する」
という方向に進めるとのこと。
Cloudコードサービスをアップデートし、ターンベースマルチプレイヤーソリューションに必要な機能を提供。
要するに簡単にカードゲームのようなターンベースのマルチプレイヤーゲームを作成することが出来るようになる。凄い！
2D Renderer が MeshRenderer / SkinnedMeshRenderer を扱えるように
→ 2D ライトとスプライトマスクと連動した“2.5D 的表現”がやりやすくなる
タイルマップ用スプライトインポーター
インポート時にタイルセット〜タイルパレットまで自動生成
Sprite Atlas Analyzer / ランタイム API
2D IK のマルチスレッド化＆Burst対応、Box2D v3 ベースの低レベル 2D 物理 API
→ ECS / Job System との相性も考えた設計
いちばん“基礎っぽいけど激しめ”な話が、
Core CLR への移行。
これまでの Mono / .NET 実装から、
6.7 までに、デスクトップ向け CoreCLR プレイヤーをExperimental版として提供する、というロードマップ
要するに：
という宣言。
ECS（Entities） についても、
6.4 で ECS がエンジンのコアパッケージ化
その後：
GameObject と ECS の Transform を統一
共通 ID を持たせ、
ECS コンポーネントを GameObject に楽にアタッチできるようにする
つまり、
「ECS を使うためにプロジェクトを全部 ECS 化する」のではなく、
「GameObject ベースのゲームに、必要なところだけ ECS を噛ませる」
方向に寄せていく感じ。
Burst 1.8.25 では、
Galaxy サンプルの決定論バージョンなんかも準備中で、
将来的には物理やネットコードにも広げていく予定らしい。
Platform Toolkit は、個人的にかなり刺さったやつ。
アチーブメント
セーブデータ
ユーザーアカウント
ストレージエラー時の UI …
みたいな、各プラットフォームごとに微妙に違う“あるある機能”を共通 API で抽象化するパッケージ。
特徴：
エディター上で
ユーザー切り替え
セーブ失敗
アチーブメント解除
などを 実機なしでテスト できる
出荷したいプラットフォームのサポートパッケージを追加するだけで、
実装済みの共通コードが動く
Unity のサンプルプロジェクトは、すでに Xbox / Nintendo などで認定通過済みとのこと。
「プラットフォームごとに同じ UI を3回書き直して認定に落ちる」
みたいな悲劇を、ちょっとでも減らしたい、という意図が伝わってきた。
サポートしている機能とプラットフォーム：
2025/6/5 にローンチした Nintendo Switch 2 に対して、Unity は
初日サポート（Day One Support） を実現
対応バージョンは 6.0 / 6.3
機能面では：
さらに『Survival Kids』プロジェクトを通じて、
Studio Productions + KONAMI + Platform チームで、
Switch 2 向けサポートをガッツリ検証している、という話も出てた。
6.3：
環境レイトレース
ルームメッシュ
フレーム落ちを抑える高速ポストプロセス（HDR でもいける）
どちらも OpenXR + AR Foundation ベースでまとめていく流れ。
6.5 で thin LTO build による起動時間・ランタイムパフォーマンス改善
折りたたみ端末・エッジトゥエッジ対応：
Network：HTTP/2 & gRPC
6.3：
サーバー側が対応していれば、UnityWebRequest はデフォルトで HTTP/2
初期テストでは、サーバー負荷最大 40% 減、クライアント CPU 15〜20% 減くらいの結果も
6.5：
UnityWebRequest に ストリーミングハンドラ を追加して gRPC を扱えるようにする
シェーダービルド設定：
ビルドプロファイルごとにキーワードを削除・変換
URP のビルド時間を最大 45% 短縮した例も紹介されてた
DX12：
Build Automation：
失敗原因の分類
プレミアムストレージ（Boost Disk）で増分ビルド時間を最大 58% 短縮 など
Project Auditor：
エディターのコアパッケージとして標準化
静的解析でプロジェクトの問題やアップグレード障壁を洗い出す
AssetBundles / Addressables
6.3：TypeTreeの重複排除でメモリ削減
6.5：TypeTreeをAssetBundle外に出してダウンロードサイズ削減
将来：Addressables の「スワッパブルバックエンド」で
CDN・セキュア配信・帯域最適化をしやすくする
最後の大きな塊は、ライブゲーム ＋ ゲーム内エコノミー ＋ IAP の話。
Unity 自身が、
「最初のゲームエコノミー製品は正直イマイチだった」
と認めたうえで、ここ数年は
アプリ内購入
コンテンツ＆コンフィグ
状態＆エンタイトルメント
データとリリース管理
の 4 つを軸に作り直している、という説明だった。
IP SDK
代替トランザクションプロセッサー・Web ショップ向けにも同じ発想を適用
単一の C インターフェース
共通の Webhook
バックエンドのフラグ切り替えだけでプロバイダを変更可能に
サーバーサイドトランザクション＆レシート検証
Web / PC への展開、WebOps 対応
要するに：
「SDKごとにまったく別のコードを書いて、
変更のたびにクライアントビルドを出し直す世界から卒業しよう」
って感じ。
統一製品カタログ：
クロスプラットフォームエンタイトルメント：
「どのストアで買っても、アカウントとしては同じ所有権」となるような仕組み
自前バックエンドがあればそれと連携、なければ Unity 側で提供
既存の Cloud Content Delivery + Remote Config を統合したような
新しい Live Content System を構築中
機能イメージ：
ここで Unity が強調していたのは、
「金曜日の夜 9 時に全員オフィス待機して
デプロイボタンを押す世界から卒業しよう」
ということ。
これはわかりみが深すぎる…。
Developer Data Framework からのテレメトリ
ゲーム内エコノミー・IAP・エンタイトルメントのデータ
必要ならスタジオ側のファーストパーティデータ
を全部まとめて、
どこでクラッシュが起きているのか
それが保持・収益にどう影響しているのか
通貨が過剰か、不足か
イベントや新オファーの効果はどうか
を 1 つのダッシュボードで見れるようにする、という方向性が示されてた。
最後のトピックが、エージェントAIツール。
Unity 的には、
「エージェントは、開発チームの一員として振る舞う共同開発者」
という位置づけで、
構成は大きく 3 本柱：
インフラストラクチャ
オーケストレーションによるマルチステップ計画
ツールの呼び出し
Git diff と連携して、「どのファイルをどう変えたか」をわかりやすく確認
コンテキスト
プロジェクトをインデックス化してナレッジグラフ構築
巨大なプロジェクトでも、プロンプトには必要な部分だけを渡す
エディタやシーンのスクリーンショットなど視覚入力も扱う
プロファイラーデータを読んでパフォーマンス改善案を出す
ワークフロー
UI Builder エージェント（Text → UI Toolkit レイアウト）
QA エージェント（コンソールログ監視）
チャットからのアセット生成（UI / スカイボックス / 3D メッシュ / テクスチャ / エフェクト…）
つまり Unity 的には、
「コード補完とかチャットボットを超えて、
“エディターの中に住んでいる開発メンバー”として機能させたい」
っていうビジョンなんだと思う。
というわけで、Unite 2025 の Engine Roadmap をざっくりまとめると、
Unity 6 時代のキーワードはこんな感じになりそう：
Develop
Deploy
Platform Toolkit
Nintendo Switch 2 / Android XR / Meta Quest / Apple 最新 OS
HTTP/2 & gRPC、DX12 / Vulkan、Build Automation
Addressables & AssetBundles の最適化
Grow
Developer Data Framework
ゲーム内エコノミーと IAP の再設計
Live Content System と実験・リリース管理
データ統合とセグメンテーション
最後に、現場目線での「じゃあどうする？」をざっくり書くと：
新規プロジェクト
→ 基本は Unity 6.3 LTS 前提で検証して、
Platform Toolkit / DDF / 新診断 まわりは早めに触っておいた方がよさそう。
2022 LTS / 6.0 の既存プロジェクト
→ いきなり 6.3 にジャンプする前に、
Project Auditor ＋ 開発者データフレームワーク＋新プロファイラを使って
技術的負債とパフォーマンスのボトルネックを棚卸し しておくと安心。
UI 周り
→ 新規部分は UI Toolkit に寄せつつ、
既存 uGUI は「パフォーマンス改善＆TextMeshPro/Addressables 連携」だけでも取り込んでおく。
ネットワーク／ライブサービス系
→ HTTP/2 / gRPC / IAP 再設計 / 統一製品カタログは、
ちゃんとハマると運用コストをかなり下げてくれそうなので、
長期運営タイトルを持っているスタジオほど早めにウォッチしておくと良さげ。
AI エージェント
→ これはまだ進化途中だけど、
「とりあえずコードを書かせる」よりも
プロファイラやログ解析、UIレイアウトのたたき台づくりみたいな
“面倒だけどパターンが決まっている作業”から任せるのが現実的かな、って感触。
