AIに「重い」を判断させるには何を読ませるか(Profilerの代わり)
Unity の Profiler は画面で見る道具なので、AI には読めません。代わりに何を読ませれば重さを判断できるのか。CLI から取れる描画・メモリ・フレーム時間、ブラウザで測る fps と最長フレーム、コードの中で測る時間と確保量。3つの実測を並べて、どれが何に効くかを書きます。
公開 2026年9月19日
この記事の要点4 points
- AI に読ませられるのは数字だけ。 Profiler の画面は読めないが、同じ情報の一部は CLI で取れる。
- 同じ場面で比べたら、描画の呼び出し 418 → 360、CPU のフレーム時間 14.04ms → 3.66ms。
- ブラウザの fps は 60 で頭打ち。 差を見るなら最長フレームか、コードの中の実測。
- いちばん確実なのは、比べたい2つを同じ場面で交互に測ること。
目次6章
検証した環境最終確認 2026年9月19日
- Windows 11 / RTX 2080 Ti
- Unity 6.6(6000.6.0f1)・Unity CLI 1.0.0-beta.10
- Claude Code(Opus 5 / 思考レベル 高)
書いてあるのは、この環境で実際に試した結果です。ツールの仕様や料金は変わるので、重要な判断の前には公式の情報も確認してください。
AI にゲームを作らせていると、必ずこの質問になります。「これ、重くない?」
人なら Profiler を開いて見ます。AI は画面を見られません。では何を読ませるか。3つ使いました。
- 1
エディターから数字で取る
Unity CLI のget_performance_stats。描画の呼び出し数・メモリ・フレーム時間が JSON で返る - 2
コードの中で測る
同じ処理を60回くり返してStopwatchとGC.GetTotalMemory。内訳がいちばんはっきりする - 3
本番のブラウザで確かめる
自動で開いて fps と最長フレームを数える。最後はここで確かめる
1. エディターから数字で取る
実行中のエディターに問い合わせると、こういう JSON が返ります。
unity command get_performance_stats --result-only
{
"render": { "drawCalls": 360, "batches": 0, "setPassCalls": 5, "triangles": 807, "vertices": 1611 },
"memory": { "totalAllocatedBytes": 972184639, "monoUsedBytes": 116084736 },
"frameTiming": { "available": true, "cpuFrameTimeMs": 3.66, "gpuFrameTimeMs": 0.51,
"cpuMainThreadFrameTimeMs": 1.75 }
}これを、同じ場面のまま書き方だけ切り替えて取り直します。4本目のゲームで、絵を使い回す/毎フレーム作って壊す、を切り替えた結果がこれです。
毎フレーム作って壊す
- 描画の呼び出し 418
- CPU のフレーム時間 14.04ms
- メインスレッド 8.12ms
作ったものを使い回す
- 描画の呼び出し 360
- CPU のフレーム時間 3.66ms
- メインスレッド 1.75ms
出している絵はまったく同じなのに、時間は約4倍違います。AI はこの2つの JSON を比べるだけで「どちらが重いか」を判断できます。
エディターの数字は本番より重い
エディター上の計測には、エディター自身の負担が混ざります。大小の比較には使えますが、そのまま「本番で何 ms」とは言えません。 最後は本番で確かめます。
2. コードの中で測る(内訳がいちばんはっきりする)
もっと細かく知りたいときは、比べたい処理だけを60回くり返して測ります。
System.Action<bool> measure = (usePool) =>
{
view.UsePool = usePool;
view.Render(b); // 1回描いて温める
GC.Collect(); GC.WaitForPendingFinalizers(); GC.Collect();
long mem0 = GC.GetTotalMemory(true);
var sw = System.Diagnostics.Stopwatch.StartNew();
for (int i = 0; i < 60; i++) view.Render(b);
sw.Stop();
long mem1 = GC.GetTotalMemory(false);
Log($"{sw.Elapsed.TotalMilliseconds / 60:0.00}ms / 確保 {mem1 - mem0}バイト");
};
画面にあるもの:敵60 自機の弾300 合計361個 プールあり: 60回 9.0ms(1回 0.15ms)確保 0バイト プールなし: 60回 1143.8ms(1回 19.06ms)確保 1904640バイト プールあり: 60回 8.8ms(1回 0.15ms)確保 0バイト
最後にもう一度「プールあり」を測っているのがポイントです。同じ数字に戻れば、途中で機械の状態が変わっていないと分かります。
3. 本番のブラウザで確かめる
最後は本番です。スマホの見た目で開き、はじめて、10秒数えます。
node scripts/measure-play.mjs "https://aigame.game-union-libra.com/play/mureuchi/" 25
{"url":"https://aigame.game-union-libra.com/play/mureuchi/","fps":60.1,"worstMs":16.9,"frames":601}ここで大事なことが1つあります。
⚠️ ブラウザの fps は 60 で頭打ち
描画は画面の更新に合わせて呼ばれるので、余裕があってもなくても 60 前後になります。私は最初これで「差が無い」と判断しかけました。余裕を知りたいなら最長フレーム(worstMs)を見るか、上の2つの方法で1回あたりの時間を測ってください。
使い分け
内訳を知りたい
本当に大丈夫か知りたい
AI に渡す手順にしておく
毎回同じことを頼まなくていいように、手順そのものをリポジトリに置いています。
重さを判断するときの決まりごと
まとめ
- Profiler の画面は AI に読めない。同じ情報の一部は CLI で数字として取れる
- 同じ場面で切り替えて比べれば、描画の呼び出し 418→360・CPU 14.04ms→3.66ms のように差が出る
- ブラウザの fps は 60 で頭打ち。最長フレームか、コードの中の実測を見る
- 手順を決めて置いておけば、毎回同じやり方で測れる
FAQ
よくある質問
AI は Unity の Profiler を読めますか?
画面としては読めません。ただし Unity CLI の get_performance_stats を使うと、描画の呼び出し数・メモリ・フレーム時間が JSON で取れます。数字で比べるぶんには、これで足ります。
ブラウザで fps を測れば十分ですか?
足りません。ブラウザの描画は 60 回/秒で頭打ちなので、余裕があってもなくても 60 と出ます。最長フレームの時間や、コードの中で測った1回あたりの時間を併せて見てください。
どこで測るのが正しいですか?
本番(ブラウザ)です。ただし本番では細かい内訳が取れないので、エディターで内訳を見て、本番で結果を確かめる、という順にしています。
測るときの注意は?
同じ場面で、交互に、温めてから測ることです。1回目は準備の時間が混ざるので、2回目以降を使います。
この記事は役に立ちましたか?
NEXT
あわせて読む
毎フレーム作って壊すのをやめる(オブジェクトプールの効き目を実測)
弾と敵が同時に数百個出るゲームを作りました。表示のたびに GameObject を作って壊す書き方と、作ったものを使い回す書き方を、同じ場面で測って比べます。1フレーム 19.06ms が 0.15ms になり、確保するメモリは 0 バイトになりました。
Unity WebGLの読み込み時間とfpsを測る方法(軽量化の前後で比較)
ダウンロード 0.76秒、起動 0.6秒、プレイ中 60.1fps。10.1MB 版と 7.37MB 版を同じ条件で比べたら起動が19%速くなりました。計測用ページの作り方と、圧縮を外したあとのサイズという見落としがちな数字、そして fps の計測でつまずいた話です。
Webゲームの進行を保存する(何を保存しないか・壊れても落ちない形)
ブラウザで遊ぶパズルに「どこまでクリアしたか」と自己ベストを保存しました。盤面は保存しません。保存先がブラウザの領域であること、壊れた保存データで落ちない書き方、記事を書いていて気づいた「版が無い」という穴と、その直し方を残します。