scenario-roblox-performance

Robloxのパフォーマンスとリリース

対象：macOS上のRoblox Studio（2026年10月ビルド）。scenario-roblox-expert ツールキットを通じて操作します。

ここでいうエキスパートレベルとは、悪影響が出る側から、変更の前後で測定した数値をすべての主張に示し、問題を隠すのではなく作業そのものを取り除く修正を行うことです。予算はローエンドのスマートフォンを基準とし、Studioの数値はStudioの数値であると明記します。リリースもパフォーマンスの一部です。再起動計画とロールバック手段を用意し、オーナーの許可なく公開することは決してありません。

ここで指定した兄弟スキルが利用可能なスキルにない場合は、ユーザーにインストールを依頼してください （npx skills add scenario-labs/skills --skill <name>）。無人で作業する場合は、ツールのスキーマに基づいて進め、不足している点を明示してください。

必須の背景知識： scenario-roblox-expert（チャンネル、レビューの反復、ツールキット、現在のRobloxに関する落とし穴）。

スタンス（エキスパートとしての差分）

1. ローエンドのスマートフォンを基準に予算を設定し、Studioの数値はStudioの数値と明記します。 McNeillの予算カードは2 GBのスマートフォンを対象としています。500ドローコール、500,000トライアングル、1.3 GB、150,000インスタンス、ダウンロード50 KB/sです（RDC 2024）。スマートフォンのCPU処理はデスクトップの約4倍遅くなります。Studioのメモリは「Studioでは正しくありません。実環境でテストする必要があります」（McNeill）。Studioはプレイテストのサーバーとクライアントを1つのプロセスで実行するため、サーバーの処理がクライアントのフレームに現れます［追加、測定済み］。
2. 修正の前に原因を明示します。 各フレームで動くシステムすべてにdebug.profilebeginでラベルを付け、最も長い最下層のラベルを修正します（Roblox Learn、MicroProfiler）。Studioのexecute_luauからScript Profilerを利用できるため、エージェントはコードで同じ答えを得られます。ラボではBasePart.CFrame [C]とスキャンのラベルがサーバー時間の大部分を占めていました（測定済み）。
3. フレームごとに比較して、フレームの一貫性を基準に判定します。 10 msのフレームが59回、410 msのフレームが1回あると、「60 fps」でもカクつきます（Roblox Learn）。基準ゲートを使います。p95は予算の1.2倍以下、最悪値は2倍以下とし、健全なプレースは60 fpsでp95が17.2～17.4 msです。スクリプト時間はフレームごとに比較します。修正によってフレームレートが上がると、フレームごとの処理がより頻繁に実行されるためです［追加、測定済み］。
4. プレイヤーに見えないサーバー処理を取り除きます。 「サーバー上でTweenを実行しないこと」（Crusherfire）。溶接されたサーバーパーツのサイズを変更すると、アセンブリ全体が再レプリケーションされます（McNeill、Lynn、RDC 2025）。アイドル状態のゾンビをアンカー化したところ、あるゲームのサーバーCPU使用率は半分になりました（同講演）。ただし、サーバーが引き続きパーツを動かす場合、アンカー化だけでは不十分です。サーバーが回転させていたアンカー済みのコインは、Studioで7.6～10 MB/sを送信しましたが、クライアントが回転させるようにすると12 KB/sになりました（測定済み。DataSendKbpsの単位はキロバイト/秒です）。
5. メモリリークとは、所有者を特定できる形で底上げされていく使用量です。 健全なメモリ使用量はのこぎり歯状になります（Roblox Learn）。同じ状態で3～4回スナップショットを取得し、上昇し続ける行だけを信頼してください（Crusherfire）。サーバーは数百人のプレイヤーより長く稼働するため、サーバーのリークが最も重大です（Crusherfire）。Destroyを呼び出しても、パーツから他のシグナルへの接続は解放されません。各オーブはメモリに残り、親を失った後もHeartbeatのクロージャーに保持されていました（測定済み）。
6. レプリケーションはメモリ、帯域幅、参加時間に影響します。 すべてのパーツに付けたタグと属性はすべてのクライアントにレプリケーションされます。あるゲームではクラッシュ率が3～4％から45％に上昇しました（McNeill、Lynn）。サーバー所有の移動するアセンブリはそれぞれ約1 KB/sを消費し、参加時には毎秒約10,000インスタンスがレプリケーションされます（McNeill）。サーバー専用データはLuauのテーブルに保存し、容量の大きなフォルダーはServerStorageに配置してください。ストリーミングは無効にせず、調整してください（Roblox Learn）。
7. リリースもパフォーマンスの一部であり、公開するのは人です。 ServerRestartScheduledを処理し、古いサーバーだけを再起動してください。アップデート後にクライアントのクラッシュ率が2～3％を超えた場合は調査してください（ドキュメント）。ロールバックでは復元、公開、再起動が必要です。復元しただけでは何も公開されません（ドキュメント）。エージェントは準備とドライランを行い、オーナーが公開します。

最初に確認すること

• 症状と影響箇所：クライアントのフレームレート低下、サーバーのラグ（ハートビートが60未満で、全員にラバーバンド現象が発生する）、クラッシュやメモリ、参加時間、または帯域幅です。症状ごとに担当者を1人決めます。
• 対象デバイス：サポート対象のうち最も性能の低いスマートフォンです。デフォルトは2 GBのスマートフォン、60 fps、予算はcritique.mdに記載されています。
• ライブデータ：ゲームが稼働中の場合は、パフォーマンスダッシュボードの数値（クラッシュ率、経過時間別のサーバーメモリ、デバイス別のフレームレート）を確認します。
• 再現方法：プレイテストで問題を確認できる場所またはスクリプト化されたシナリオと、負荷をかけるためのデバッグスポーナー（N人のプレイヤー、N体のNPC、N個のアイテム）を用意します。
• リリース状況：未リリース、プレイヤーがいる状態で稼働中、またはアップデート中のいずれかを確認します。公開と再起動を行える人を決めます（必ず人が行います）。
• 回答がない場合のデフォルト：サーバーとクライアントを計測し、プレイテストごとに変更は1つだけにして、公開はしません。

手順

1. 負荷をかけて再現します。 目標：プレイテストで遅いケースを再現し、両側の数値を取得します。方法：Workspace属性で駆動するデバッグスポーナー（N人のプレイヤー、N体のNPC、N個のアイテム。McNeill and Lynn）を使い、同じサーバーのtime()でサーバーとクライアントの両方に対してrbx_perf.measure(pt, 6)を実行します（P2）。GATE：両側のベースラインを保存し、フレームゲートに失敗する側を特定します。
2. 静的に監査します。 目標：プレイテスト前に、コストの高いパターンと件数を把握します。方法：Luneでrbx_perf.audit_place(path)を、EditでPerfAudit.all(game)を実行します（P1）。GATE：すべての警告を修正するか、1行で正当化し、件数をNumbersテーブルに記載します。
3. 原因を特定します。 目標：コストの原因となっている関数、ラベル、またはアセットを特定します。方法：プレイテストでrbx_perf.script_profile(s, side)を、Editでラベルの特定にMicroProf.captureを、三角形数、インスタンス数、スクリプトメモリの確認にSceneScan.all()を使います（P3、P6）。GATE：最もコストの高い関数またはラベルを、フレームあたりのmsとともに示します。
4. プレイテストごとに1つだけ修正します。 目標：ほかは変更せず、効果が実証された改善を得ます。方法：属性を1つ切り替え、同じオフセットで計測し、5パーセントのノイズフロアを考慮してrbx_perf.compare(before, after)を実行します。パターンはP4に記載されています。GATE：修正対象の指標がノイズフロアを超えて改善し、ほかの指標は悪化せず、影響が出る側でフレームゲートを維持します。
5. リークがないか長時間テストします。 目標：減少しないメモリと、その原因を特定します。方法：リーク経路を有効・無効にし、サーバー上で20秒以上にわたってPerfProbe.soak、HeapProf.diff、およびSceneScanのUnparentedInstancesを使います（P5）。GATE：メモリカテゴリの増加と親のないインスタンス数が横ばいで、追跡対象のオブジェクト数が上限内に収まります。
6. シーン、描画、ストリーミングを確認します。 目標：最も負荷の高い表示がスマートフォンの予算内に収まるようにします。方法：クライアントのStats.SceneDrawcallCountとSceneTriangleCount、バッチングプローブ（P7）、プロジェクトファイルのストリーミング半径（P8）を確認します。GATE：最も負荷の高い表示で、ドローコール数、三角形数、インスタンス数がNumbersテーブルの範囲内に収まります。
7. スマートフォンのテストリストを担当者に渡します。 目標：Studioでは取得できないデバイスの数値を得ます。方法：P9のリストとgui-paths.mdのGUIパスを使います。GATE：実機のスマートフォンからメモリとフレームレートを取得するか、レポートに「Studio only」と記載します。
8. リリースします。 目標：プレイヤーが問題なく移行でき、元に戻す手段のあるアップデートを行います。方法：再起動ハンドラー（P10）、scenario-roblox-dataの保存機能、scenario-roblox-toolingのShipCheckを使います。担当者が公開し、古いサーバーを再起動します。GATE：ハンドラーをプレイテストで検証し、担当者の承認を記録します。エージェントは決して公開しません。

数値

値	数値	基準
シーンの描画呼び出し数	500 以下、UI を含む	低性能スマートフォン、最悪のビュー（McNeill）
シーンの三角形数	500,000 以下	同上
シャドウの描画呼び出し数	シーンの描画呼び出し数の最大 3 倍	同上
クライアントのメモリ	1.3 GB 未満。2 GB の約 66 パーセントを超えると追い出しが始まります	2 GB のスマートフォン、デバイス上（McNeill）
インスタンス	150,000 未満。参加時は毎秒約 10,000	参加時間（McNeill）
レプリケーションのダウンロード	50 KB/s 未満	クライアントごと（McNeill、Crusherfire）
サーバー所有の移動アセンブリ	それぞれ約 1 KB/s	McNeill
スマートフォンの CPU	デスクトップの約 4 倍	デスクトップで 10 ms は約 40 ms
フレームゲート	p95 は予算（20 ms）の最大 1.2 倍、最悪時は最大 2 倍（33.3 ms）。健全な場所では p95 が 17.2～17.4 ms	60 fps（リードゲート）
サーバーのメモリ	6.25 GiB にプレイヤー 1 人あたり 100 MiB を加算。半分未満に抑える	ドキュメント
クライアントのクラッシュ率	2～3 パーセントを超えたら調査	ドキュメント
BulkMoveTo	パーツごとの書き込み 0.49 ms に対して 0.255 ms	Crusherfire のスピナー
ラボ、すべての修正適用後	サーバースクリプトはフレームあたり 12.0 ms から 0.36 ms、サーバー送信量は 6,526 から 11 KB/s、HUD インスタンスは 6,002 から 302	Studio 0.743、デスクトップ、単一プロセス

品質ゲート

測定可能な項目：

• 影響が大きい側のフレームゲート。PerfProbe.window(...).gate またはリードの Stats.frames で確認します。
• 各修正が対象とするメトリクスについて、ノイズフロアを超えた rbx_perf.compare の行。バリアントごとに結果ファイルを 1 つ用意します。
• PerfAudit の警告が 0 件であること。警告がある場合は、それぞれに根拠を示します。
• 負荷テスト：メモリカテゴリの増加と親のないインスタンスが横ばいであり、追跡対象のオブジェクト数に上限があること。
• SceneScan とクライアントの Stats：描画呼び出し数、三角形数、インスタンス数が「数値」表の範囲内であること。
• すべてのフレームごとのシステムに debug.profilebegin ラベルを付けます。長時間稼働するスレッドには debug.setmemorycategory を設定します。
• プレイテストで再起動ハンドラーが接続されていること。P9 のスマートフォンの数値は所有者が報告するか、「Studio のみ」と明記します。

視覚的な確認：最悪のビューについて、rbx_review を使ってプレイテスト中に修正前後をキャプチャします（rbx_review.contact_sheet）。主張の根拠に MicroProfiler または Script Profiler を挙げる場合は、手動でキャプチャします（gui-paths.md）。完全な評価基準はcritique.mdにあります。

よくある間違い

間違い	症状	修正
fps や Studio のメモリ量を基準にする	スマートフォンでは表示されない数値	フレーム時間の p95 と最大値、P9 のスマートフォン一覧を使う
修正後に秒あたりの ms を比較する	fps が上がるとフレームあたりの処理が悪化したように見える	フレームあたりの ms を比較する
Studio で Stats.HeartbeatTime、クライアントの DataReceiveKbps、または FrameTime を基準にする	8～100 ms の変動、0 KB/s、323 ms のフレーム	Heartbeat の dt、サーバーの DataSendKbps、物理演算の回数、Script Profiler
1 回のプレイテストで 2 つの変更を行う	変化の原因を特定できない	実行ごとに属性を 1 つだけ変更する
異なる時刻に取得したウィンドウを比較する	メモリリークにより後の実行ほど負荷が高くなる	同じサーバーの time() になるまで待つ
アンカーを設定してもサーバー上でパーツを動かす	レプリケーションが MB/s に達する	クライアント上で装飾要素を動かす
外部接続を解放せずに Destroy する	親のないパーツとテーブルエントリが増加する	Destroying:Once で接続を解除する
execute_luau から gcinfo() を読み取る	約 0.9 MB：注入されたチャンクのヒープ	HeapProf のメモリカテゴリ
サーバー上で Tween を実行する、または溶接されたパーツのサイズを変更する	レプリケーションが急増する	クライアント側で Tween とサイズ変更を行う
すべてのパーツにタグや属性を設定する	メモリ使用量とクラッシュ率が上昇する	サーバーデータは Luau テーブルに格納する
Studio のウィンドウが覆われた状態でレンダリング統計を読み取る	カウンターが同じ値で止まる	パーツを視界に入れ、まずカウンターが動くことを確認する
Vector2 をキーにしてグリッドセルを管理する	すべての検索が失敗する	Vector3 または数値をキーにする
修正をテストするために公開する	プレイヤーに未検証のビルドが配信される	オーナーが公開し、Version History から復元して公開し、再起動する

引き継ぎ

• scenario-roblox-environment から受け取るもの：EnvAudit のカウントとモデルごとのストリーミングモード （モデルごとのモードは環境側が管理し、ストリーミング設定はここで決定します）。
• scenario-roblox-luau から受け取るもの：Bench と Parallel の結果、ネイティブ化候補、メモリリークの傾き。
• scenario-roblox-gameplay から NPC のベンチマーク数値、scenario-roblox-vfx-audio から エミッター、ビーム、フリップブックの数、scenario-roblox-networking からペイロードサイズと送信レートを受け取ります。
• scenario-roblox-luau に引き渡すもの：リークしている関数またはホットループ。クリーンアップコード（Leak、クラスの テンプレート）、ネイティブコード、Actor はそちらにあります。
• scenario-roblox-tooling に引き渡すもの：リリースの承認。ShipCheck、保存済みバージョン、Open Cloud による公開、:restartServers の自動化はそちらにあります。エージェントはドライランのみを実行します。
• scenario-roblox-data に引き渡すもの：再起動計画。これにより、BindToClose とセッション保存が30 秒のシャットダウン予算内に収まります。
• scenario-roblox-ui、scenario-roblox-assets、scenario-roblox-animation に引き渡すもの：ゲートで不合格となった UI 描画 呼び出し、テクスチャまたはメッシュの予算、リグのタイマー（updateInvalidatedFastClusters）。

現在の Roblox に関する注意事項

• ScriptProfilerService と HeapProfilerService は PluginSecurity です。Studio の execute_luau はプレイテストのサーバーとクライアントの両方でこれらにアクセスできますが、ゲームの Script では「lacking capability Plugin」と表示されます（測定済み、P3）。
• SceneAnalysisService は、6つのクエリとして Scene Analysis ウィンドウを公開します。Edit、プレイテストのサーバー、クライアントで応答し、ゲームの Script からも呼び出せます（測定済み）。
• クライアントでは、Stats.SceneDrawcallCount と SceneTriangleCount を通じて描画呼び出し数と三角形数をスクリプトから読み取れます。Studio ウィンドウで3D描画が停止すると、これらの値も更新されなくなりました（測定済み）。
• 新しい place ではストリーミングが有効です。Workspace のストリーミング設定はゲームスクリプトからは NotScriptable で、型定義にもありません。execute_luau から読み書きできるのは StreamingEnabled のみです。半径の値では「is not a valid member of Workspace」エラーが発生します（測定済み）。Properties パネルまたは Rojo プロジェクトで設定してください。
• RunService.PreRender は RenderStepped に置き換わります。Lighting.LightingStyle は Technology に置き換わります（Future は Realistic に PrioritizeLightingQuality を加えたものです）。4K テクスチャは2026-01-30から本番環境で利用できます。
• 公開には Maturity and Compliance の質問票への回答が必要です。また、place 公開 API では SurfaceAppearance、unions、EditableImage、EditableMesh、BaseWrap のコンテンツを更新できません。
• require("@rbx/LibMP") は、MicroProfiler を execute_luau とコマンドバーに公開します（MCP スキル rbx-perf-profiling）。Edit のスナップショットにはフレーム全体が保持されます。プレイテストのスナップショットには0～128フレームが保持され、シーンが重いほど少なくなります（測定済み）。

リファレンス

• references/expert-notes.md：専門家による原則と判断。タイムスタンプと実測値を含みます。
• references/procedures.md：ステージ P1～P10 の全コード。それぞれにテスト ID と実測結果を記載しています。
• references/critique.md：合格・不合格の基準と予算ゲートの表。
• references/memory-and-crowds.md：クライアントメモリの構成、アセットとバッチ処理の監査（PerfAudit.assets）、キャラクターとペットのコスト （updateInvalidatedFastClusters が4 ms超）、ストリーミングで対処できない群衆。
• references/gui-paths.md：MicroProfiler、Developer Console、Scene Analysis、ダッシュボード、リリースメニューと、スクリプトによる代替手段。
• references/sources.md：すべてのドキュメントと動画。認証情報とタイムスタンプを含みます。
• scripts/rbx_perf.py：キットランナー、オフライン監査、ラボ属性、サーバーおよび クライアントのウィンドウ、ノイズフロアとの比較、プロファイラーのラッパー。
• scripts/agentkit/performance/：PerfProbe、ScriptProf、 MicroProf、HeapProf、SceneScan、PerfAudit、lune_perf_audit.luau。