AIゲーム制作ラボ
Unity×AI6分で読めます

AIに「重い」を判断させるには何を読ませるか(Profilerの代わり)

Unity の Profiler は画面で見る道具なので、AI には読めません。代わりに何を読ませれば重さを判断できるのか。CLI から取れる描画・メモリ・フレーム時間、ブラウザで測る fps と最長フレーム、コードの中で測る時間と確保量。3つの実測を並べて、どれが何に効くかを書きます。

Libra

公開 2026年9月19日

この記事の要点4 points

  1. AI に読ませられるのは数字だけ Profiler の画面は読めないが、同じ情報の一部は CLI で取れる。
  2. 同じ場面で比べたら、描画の呼び出し 418 → 360、CPU のフレーム時間 14.04ms3.66ms
  3. ブラウザの fps は 60 で頭打ち 差を見るなら最長フレームか、コードの中の実測。
  4. いちばん確実なのは、比べたい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. 1

    エディターから数字で取る

    Unity CLI の get_performance_stats。描画の呼び出し数・メモリ・フレーム時間が JSON で返る
  2. 2

    コードの中で測る

    同じ処理を60回くり返して StopwatchGC.GetTotalMemory。内訳がいちばんはっきりする
  3. 3

    本番のブラウザで確かめる

    自動で開いて fps と最長フレームを数える。最後はここで確かめる

1. エディターから数字で取る

実行中のエディターに問い合わせると、こういう JSON が返ります。

Git BashOK
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}バイト");
};
Unity のコンソールOK
画面にあるもの:敵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秒数えます。

Git BashOK
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回あたりの時間を測ってください。

使い分け

内訳を知りたい

エディターの get_performance_stats(描画の呼び出し・メモリ・フレーム時間)
コードの中の Stopwatch と GC.GetTotalMemory
同じ場面で交互に測る・温めてから測る

本当に大丈夫か知りたい

本番のページを自動で開いて測る
fps ではなく最長フレームを見る
遊べるまでの時間・転送量も一緒に記録する

AI に渡す手順にしておく

毎回同じことを頼まなくていいように、手順そのものをリポジトリに置いています

重さを判断するときの決まりごと

比べたい2つを、同じ場面で交互に測る(1回目は温めなので捨てる)
エディターの数字は大小の比較だけに使う
本番のブラウザで、fps と最長フレームと遊べるまでの時間を取る
数字は DB に入れて、記事はそこを読む(あとから食い違わない)

まとめ

  • Profiler の画面は AI に読めない。同じ情報の一部は CLI で数字として取れる
  • 同じ場面で切り替えて比べれば、描画の呼び出し 418→360・CPU 14.04ms3.66ms のように差が出る
  • ブラウザの fps は 60 で頭打ち。最長フレームか、コードの中の実測を見る
  • 手順を決めて置いておけば、毎回同じやり方で測れる

FAQ

よくある質問

AI は Unity の Profiler を読めますか?

画面としては読めません。ただし Unity CLI の get_performance_stats を使うと、描画の呼び出し数・メモリ・フレーム時間が JSON で取れます。数字で比べるぶんには、これで足ります。

ブラウザで fps を測れば十分ですか?

足りません。ブラウザの描画は 60 回/秒で頭打ちなので、余裕があってもなくても 60 と出ます。最長フレームの時間や、コードの中で測った1回あたりの時間を併せて見てください。

どこで測るのが正しいですか?

本番(ブラウザ)です。ただし本番では細かい内訳が取れないので、エディターで内訳を見て、本番で結果を確かめる、という順にしています。

測るときの注意は?

同じ場面で、交互に、温めてから測ることです。1回目は準備の時間が混ざるので、2回目以降を使います。

この記事は役に立ちましたか?

NEXT