Unity 6.4からProject AuditorがEditorに標準搭載されたため、実際に触ってどのような問題を検出できるのか確認してみました。
環境
Unity 6000.4.9f1
Project Auditorとは
Project AuditorはUnityプロジェクト用の診断ツールです。
ProfilerやFrame Debuggerのように、実行中の状態を見るツールではありません。
プロジェクトが実行していないときに解析を行い、
・コード中の重くなる可能性がある処理
・パフォーマンス上よくない可能性のある設定
・アセット関係の扱いに関する改善余地
・ビルドサイズへの影響
などを一覧で出してくれるものです。
UnityManualでも「Project Auditorは、Unityプロジェクト向けの静的解析ツール群です。プロジェクト内のスクリプト、アセット、コードに関する分析結果や問題を報告し、それらの情報をレポートとしてまとめ、専用のProject Auditorウィンドウで確認することができます。」と記載されています。
| 時期 | 内容 |
|---|---|
| 2020年以前 | GitHub上でひっそりと存在していました。その後、少しずつアップデートを重ねています。 |
| 2025年2月5日 | v1.0.0のリリース メジャーバージョンが1になったこのタイミングが正式リリースに当たると思われます |
| 2025年4月24日 | Unity 6.1リリース記事で、Project Auditorが静的解析ツールとして紹介されました。 |
| 2026年3月18日 | Unity 6.4に標準搭載されました。 |
Unity6.4 から標準搭載
以前はパッケージマネージャなどからインストールを行っていましたが、Unity6.4 より標準機能として実装されました。
Project Auditor Rules
com.unity.project-auditor-rules
Project Auditor自体は標準搭載ですが、「Project Auditor Rules」というパッケージをインストールする必要があります。
これは、Project Auditor が何を問題として診断するかを判断するための解析ルール集です。
インストールは、Package Manager（UPM）経由で行います。
※下記のProject Auditorウィンドウを開いたタイミングでも行えます。
Project Auditor を使ってみた
検証のため以下のスクリプトと、画像・音データをプロジェクトに入れています。
using System.Linq;
using UnityEngine;
class Enemy {
public bool isAlive;
}
public class BadUpdateSample : MonoBehaviour {
private Enemy[] enemies;
private void Update() {
Debug.Log("Update running");
var aliveEnemies = enemies
.Where(enemy => enemy != null && enemy.isAlive)
.ToList();
var player = GameObject.FindWithTag("Player");
}
}
さっそく実行します。
Window>Analysis>Project Auditor
から専用ウィンドウを開き、「Start Analysis」ボタンを押すことで診断が開始します。
実行後、こんな感じの画面になったと思います。
左のタブのCode、もしくは「Go to Code」ボタンからコードの詳細画面に飛びます。
Filters
| 項目 | 意味 |
|---|---|
| Assembly | 対象アセンブリで絞り込み |
| Area | CPU / Memory などの影響範囲で絞り込み |
| Search | キーワード検索 |
| Only Major/Critical | 重大度が高いものだけ表示 |
| Show Ignored Issues | Ignoreした項目も表示 |
検索範囲の絞り込みになります。
特定の範囲に絞りこんだり、調査対象にしないものを外したりすることが出来ます。
検出結果一覧
| 列 | 意味 |
|---|---|
| Issue | 検出された問題名 |
| Severity | 重要度 |
| Areas | 影響範囲 |
| Filename | 問題があるファイル |
| Assembly | 所属アセンブリ |
| Descriptor | 検出ルール名 |
| Ignored | 無視設定されているか |
| Severity | 重要度 | 対応優先度 |
|---|---|---|
| Critical | 致命的 | 最優先で確認・対応 |
| Major | 重要 / 問題度が高い | 優先して確認・対応 |
| Moderate | 注意 / 改善候補 | 内容を確認して必要なら対応 |
| Minor | 軽微 | 余裕があれば確認 |
| Info | 情報 | 参考情報 |
内容を見ると、
今回、以下のような問題が検出されました。
-
Update()内でのDebug.Log使用 - LINQの
Where()/ToList()使用 - ラムダ式に起因するアロケーション
特に Where() や ToList() は Major として検出されており、CPUとMemoryの両方に影響する可能性がある項目として表示されました。
アセット関係も同様に、画像データと音データがリストで表示されており、問題のあるアセットを見分けるために必要な項目も記載されています。
触ってみた感想
個人的には、Project Auditorは「最適化ツール」というより、プロジェクトの健康診断ツールに近い印象でした。
Profilerのように実行時の負荷を見るものではなく、プロジェクト内に潜んでいる問題候補を事前に洗い出す用途に向いていると感じました。
Profilerは実行時の負荷を見るため、実行した場面や処理回数によって見え方が変わります。
Project Auditorは実行前にコードや設定を解析するため、実行状況に左右されずに問題候補を確認できる点が便利だと感じました。
アセット関係は実際に問題が出るまで、問題が見逃されがちなため、アセットを大量に導入したタイミングで使用するのが好ましく感じます。
実務で使うなら
- Unityバージョンアップ前後
- リリース前の確認
- 新規メンバーが入った後のプロジェクト状態確認
- 大量のアセット追加後
- ビルドサイズやメモリ使用量が気になり始めたタイミング
頻繁に使うというより、要所要所で使用するのが良いと思います。
注意点
Project Auditorは便利ですが、検出結果に出ていないから問題がない、というわけではありません。
Update() 内に記述した GameObject.FindWithTag() は検出されませんでした。
このことから、Project Auditorはすべての負荷要因を検出するものではなく、用意されたルールに一致した問題候補を表示するツールだと分かります。
そのため、Project Auditorはあくまで問題候補を洗い出すためのツールとして使い、最終的な判断はProfilerなどを利用してコードの用途や実行頻度を見て行う必要があると思います。