Robloxがゲーム制作をどのように評価しているか

当社の新しいモバイルファースト型制作ツール「Build」を使えば、Robloxユーザーはテキストプロンプトを用いてゲームを作成し、世界中のプレイヤーに公開することができます。包括的なゲームを生成するには、コード、ビジュアルアセット、ゲームプレイシステム、UI、および操作系を単一の複合アーティファクトとして統合する、エンドツーエンドのエージェンティックなゲーム生成システムが必要です。このシステムは、プレイヤーの入力やマルチプレイヤー間の相互作用によって生じる様々なシナリオに堅牢に対応できなければなりません。 ニュージーランドでのアルファ版リリース以来、10万人以上のプレイヤーがBuildを使ってゲーム制作に挑戦し、約9,000本のBuildゲームが公開されました¹。Buildを使ってゲームを作成した数千人のうち、71%はこれまでRoblox Studioを使用したことがありませんでした¹。これは、彼らがBuildを通じて新しいことに挑戦していることを示しています。

しかし、クリエイターがこの新しいツールを使い続けるためには、使いやすさだけでなく、生成されるゲームの品質が、さらなる発展の土台となるほど十分に高いものでなければなりません。Buildで作成されたゲームの品質を把握するため、私たちは制作プロセス全体を評価し、その評価結果とクリエイターからのフィードバックを製品改善に活かしています。 当社の評価（eval）フレームワークは、意図の理解、3Dでのプレイアビリティ、および完成度の向上を優先順位付けし、改善する上で役立っています。ニュージーランドでのBuildのアルファ版リリース以来、クリエイターの満足度は10％向上し、意図しない出力は18％から3％に減少しました。また、プロンプトによるセッションの約14％、プレイテストの19％が公開されています²。これらは進捗を示す記述的な指標であり、評価の影響のみによる因果関係の推定ではありません。

ゲーム制作の評価が他と異なる理由

ゲームは、アプリ、動画、世界モデルなど、複合的な成果物を生成する他のシステムに見られる評価上の課題の一部を共有しています。例えば、品質は複数のコンポーネントがどのように連携するかに依存しており、単一のコンポーネントのスコアだけでは結果を完全に説明することはできません。 

ゲームを他と一線を画すのは、その成果物がプレイヤーによって駆動される実行可能なリアルタイムシステムであるという点だ。応答性、主体性、進行感、ゲームの感触といった特性は、インタラクションを通じて現れるものであり、コードやアセットを単独で検証するだけでは完全に評価することはできない。したがって、ゲームは、低レベルの正確性（欠陥がなくプレイ可能であること）だけでなく、高レベルのプレイヤー体験（プロトタイプではなく、完成されたゲームとして感じられること）という、他に類を見ないほど高いハードルをクリアしなければならない。 

評価を通じて私たちが答えようとしているのは、個々の要素が正しいかどうかではなく、作品全体が制作者の意図に沿っているか、そしてプレイヤーが体験全体を最後までプレイできるかどうかです。その答えを出すには、単一の指標だけでは不十分です。

4つのシグナル、1つのフレームワーク

私たちの「Build」制作評価フレームワークは、4つのシグナルを組み合わせています。それぞれが異なる問いに答え、異なる種類の不具合を検出し、具体的な定量的なスコアを算出します：

1. ゲーム仕様の品質（0～100点）：Buildはエンドツーエンドの生成エージェントであり、クリエイターのプロンプトを仕様に変換し、それを用いてゲームを生成します。評価者は、仕様が重要な決定を明示的に行っているか、クリエイターの意図を保持しているか、Robloxの実行環境内での実現可能性を考慮しているか、そして明示されていない要件を勝手に追加していないかを評価します。

2. 静的ゲーム品質（0～100点）：静的評価担当者は、Roblox Studioの編集モードで生成されたゲームを検査します。これには、ゲーム構造、スクリプト、アセット、プロパティ、接続、およびクライアント／サーバーの境界が含まれます。 この段階では、2つの問いに答えを出そうとしています。1つ目は、ゲームが正しく構築されているかどうかです。これには、必要なシステムの実装、エンジンAPIやネットワークの選択、期待される操作方法やUIコンポーネントの有無、ゲームアーキテクチャの堅牢性と一貫性などが含まれます。 

2つ目は、ゲームが「楽しい」ように設計されているかどうかです。これには、コアループの深さ、コンテンツの多様性と段階的な難易度の上昇、進行システム、リプレイ性、そしてそのジャンルにおける標準的な枠を超えた革新性が含まれます。ゲームはアーキテクチャ的に整っていてもコンテンツの深みが欠けていたり、アイデアに溢れていても実装が不十分であったりする場合があります。 

この2つの視点を分離し、ベストプラクティスに照らして評価することで、ゲームのどの部分が不十分なのかをより詳細に把握することができます。

3. プレイテスト（合格率 0～100%）：プレイテスト評価者はゲームを起動し、コードからイベントを発生させるのではなく、タップ、クリック、キー入力、ナビゲーションなど、実際のプレイヤーと同様の入力操作を用いてテスト計画を実行します。 ケースごとのテスト計画により、ゲームの起動、応答、進行、障害からの回復、および実行時エラーの発生がないことを確認します。各項目は「合格／不合格」の二値判定となり、単純な「プレイ可能／プレイ不可」の判定に加え、階層加重合格率として報告されます。一貫性を測定するために、実行を繰り返し行います。

4. ビジュアルおよび体験の質（0～100点）：ゲームの見た目や雰囲気において最も重要な要素の一部はコードからは読み取れないため、ビジュアル評価者は、さまざまなデバイスを再現したビューポート上でキャプチャされたゲームプレイ映像を用いて、プレゼンテーションを独自に採点します。この評価基準では、アセットの作り込み、UIの完成度、モーション、照明、オーディオに基づいて、ゲームの見た目と音のみを評価します。 核心となる問いは、「このゲームは出荷可能な製品として見られるか、それともプロトタイプとして見られるか」です。ビジュアルとメカニクスを分離して評価することで、「コードが動作する」ことと「ゲームが完成品のように見える」ことが、1つの誤解を招くスコアに平均化されるのを防ぎます。

採点対象のシグナルに加え、各実行では、トークンの使用量、ツール呼び出し、トリガーされたスキル、レイテンシなど、情報提供のみを目的としたメトリクスもキャプチャされます。これらのメトリクスは評価スコアには反映されませんが、結果がどのように生成されたかを説明したり、同じゲームのビルドコストが2倍になったといった、評価基準では見逃されがちな退行現象を検出したりするのに役立ちます。

各シグナルは、検出された不具合と対応付けられています：

プロンプト表示された3Dオビーコースの攻略

実際のプロンプトを見れば、その意図が最も分かりやすい。例えば、「スタートプラットフォーム、動く障害物、チェックポイント、ゴールラインを備えた、本格的な3Dオビーゲーム」といった具合だ。オビーはRobloxで人気のあるプラットフォームゲームの一種である。実装の細部まですべてが規定されていなくても、制作者の意図は明確である。ビルダーは、合理的な仮定に基づいて詳細を埋めていく必要がある。

計画と仕様

Buildは、『Skyforge Ascent』という新作ゲームの仕様書を作成しました。この仕様書には、チェックポイントと3種類のハザードを備えた5セクションからなるコースの詳細が記載されています。また、コアループ、難易度曲線、アートディレクション、画面、オーバーレイ、操作方法についても定義されています。仕様評価では100点満点中91点を獲得し、完全性、指示への順守、実現可能性、内部一貫性において満点を獲得しました。減点となったのは、「実装の詳細」と「受け入れ基準の網羅性」という2つの具体的な項目でした。 

この仕様書では、回転速度、滑走距離、タイルのタイミング、プラットフォームの寸法、リセットプレーンの高さといった数値定数が一切明記されていなかったため、エンジニアは依然としてそれらを独自に決定する必要があります。 さらに、「プラットフォームは約24個」や「セレスティアル・フォージの配色」といった一部の受け入れ基準は、厳密には反証不可能です。仕様書のスコアが高いということは、その文書がビルド可能な状態であることを証明するに過ぎません。それらの仕様が実際のゲーム開発の現場で通用するかどうかは、次の3つの段階で測定されることになります。

静的チェック：コード品質とコンテンツ品質

仮想審査員は『Skyforge Ascent』のプレイを行わずにそのプレイスファイルを検査し、2つの評価基準で異なる結論に達しました。

同じプレイスファイルを読み込んだエンジニアリング評価レンズは、98/100のスコアを付けた。5つのセクションと3つの移動式ハザードを備えた模範的な構築であり、サーバー主導型の順次チェックポイント、落下リセットシステム、StyleSheetフレームワークに基づくUIを用いて、制作者の意図を完全に満たしていた。仕様書に記された内容はすべて実装されていた。唯一の問題は、未使用のヘルパー関数のエクスポートが2つあったことだけだった。

一方、デザイン視点では100点満点中31点という評価でした。機能的にはすべて問題ありませんでしたが、進行性、再プレイ性、プレイヤーの主体性、そして独自の魅力という点でスコアはゼロでした。コアループは単純かつ直線的（各チェックポイントに到達し、ゴールを通過する）で、プレイごとのバリエーションがほとんどなく、2回目もプレイしたいと思わせる要素がありませんでした。これはオビー（obby）というジャンルの定番であり、独自の魅力を持つゲームとは言えません。

このギャップこそが重要な発見です。コードの品質とコンテンツの品質は根本的に異なる次元のものであり、あるビルドは一方ではほぼ完璧であっても、もう一方では失敗している可能性があります。単一の統合品質スコアでは、これらを平均化してしまい、意味のない数値になってしまっていたでしょう。

プレイテスト

プレイテストエージェントは、実際のプレイヤーと同様の入力を用いてゲームをプレイし、テスト計画に掲げられた9つの項目すべてをクリアしました。具体的には、スタートプラットフォームでのキャラクターのスポーン、隙間を跨ぐ3Dジオメトリの移動、ハザードへの衝突、チェックポイントのトリガーと自動落下回復、ランの完了、そして再スタートであり、これらすべてにおいてランタイムエラーは発生しませんでした。この特定のプレイにおいて、『Skyforge Ascent』はプレイテストで100/100のスコアを獲得しました。

プレイテストで満点を獲得したことは、単にゲームのメカニクスが機能しており、技術的には最初から最後までプレイ可能であることを証明するに過ぎません。それが実際に魅力的であるか、プレイして楽しいかについては何も語っていません。その違いこそが、デザイン評価で31点というスコアが付けられた理由なのです。

ビジュアル品質

最後に、評価システムは、スマートフォンサイズのビューポートでのビジュアル表現について、記録されたセッションを採点しました。『Skyforge Ascent』は86/100を獲得しました。クリーンで統一感があり、典型的なオブスタクルコースゲームのビジュアルと違和感なく調和しています。プラットフォームの形状は判別しやすく、ハザードも明確に認識でき、モダンで邪魔にならないHUDが採用されています。些細なビジュアル上の制限により完璧とは言い難いものの、不具合はなく、プレイヤーがスクロールを止めてしまうような要素もありません。

トレースメトリクス

同じプレイセッションでは、プロセスに関するメトリクスも記録されました。ゲームのビルドには約8分かかり、ツールエラーはゼロでした。また、ビルドプロセスでは3D、UI、スクリプト編集、アセット挿入、ゲームオーディオのスキルが使用されました。これらのメトリクスは評価スコアに直接影響を与えるものではありませんが、ゲームがどのように制作されたかを示しており、将来的に改善が見られないままビルド時間が長くなったり、リソース消費が増加したりした場合に警告サインとなります。

5つの評価段階において、『Skyforge Ascent』はゲーム仕様、コード品質、コンテンツ品質、プレイテスト、ビジュアル品質の各項目で異なるスコアを獲得しました。そのうち4つの評価項目は、「Build」が単一のプロンプトから、完全かつ正確で、プレイ可能かつ提示可能なRoblox体験を生み出せることを示しています。一方で、1つの評価項目は、このゲームを誰かが二度とプレイしたいとは思わないだろうという結果を示しています。このギャップを平均化して埋めるのではなく、正確に測定することこそが、「Build」評価の真の目的です。

早期評価がBuildをどのように改善したか 

評価結果は単にスコアを算出するだけでなく、製品改善に向けた具体的な指針も提供します。個々のコンポーネントのデバッグとシステムレベルでの包括的なテストを組み合わせ、標準化されたプロンプトスイートを用いたオフラインのバッチ評価を行うことで、Buildの開発は直接的に形作られてきました。 

1. アルファ版クリエイターの課題を迅速に解決：ニュージーランドでのアルファ版リリースにおいて、ユーザーからは「3Dゲームを作りたいのに、Buildが2Dゲームを作成してしまうことがある」というフィードバックが寄せられました。評価フレームワークのおかげで、チームはBuildの3D機能を迅速に改善することができました。2週間以内に、ユーザーが明示的に指定していなくても、3Dゲームを作成したいという意図をBuildが理解する能力を向上させました。 また、オブジェクトの位置決めや照明などに関する一般的な問題を修正することで、3Dのプレイアビリティと完成度も向上させました。それ以来、全苦情のうち「期待したものと違う」という苦情は18％から3％に減少し、プレイテスト後の全体的な不満度は10ポイント低下しました。さらに、フレームワーク自体の反復改善を通じて、多くの知見も蓄積されました。 
2. モデルおよびアーキテクチャ間の比較ベンチマーク：当社は評価フレームワークを用いて、標準化されたプロンプトスイートに対してビルドシステムの設定を厳密にベンチマークしています。変更を本番環境にリリースする前に、オフラインのA/B評価レポートを用いて、候補となるリリースを、以下の4つの側面すべてにおいて、本番環境のベースラインと比較します： 

例えば、これらのオフライン差分分析により、さまざまなモデルのアップグレードやエージェントのルーティング決定が、個々の品質指標にどのような影響を与えるかを特定することができます：

• ベースモデルのパフォーマンス：ベースモデルをアップグレードした結果、すべての指標で一貫した向上が見られました。これにより、初回ビルドでの失敗が減り、視覚的な完成度が向上し、ゲームプレイコンテンツの深みが増しました。
• エージェントルーティングアーキテクチャ：対照的に、デュアルエージェント構成において特定のサブタスクを軽量モデルに委任した場合は、コンテンツの深みと多様性は維持されたものの、プレイアビリティとビジュアルの完成度において急激な退行が見られました。

1. 制作パラダイムを横断した品質ベースラインの追跡：また、このフレームワークを用いて、最も関連性の高い評価セットを用いて、異なる時点におけるビルドの現在の品質を把握しています。これらのセットは、次第に広範かつ複雑になる制作タスクのスナップショットを提供します。
   最も初期のセットは、比較的単純なメカニズムを持つ完全な2Dゲームで構成されています。ゲームロジックは構築しやすかったため、プレイテストスコアは高くなる傾向にありました。一方、まったく同じ理由から、コンテンツスコアは低いままでした。
   焦点を3Dゲームに移すと、スコアの分布は自然に変化します。バグのないプレイを実現することがより困難になり、プレイテストスコアは低下します。アセットの仕上げが不十分なためビジュアルスコアは横ばいのままであり、ゲームにはプロトタイプのような印象が残ります。3Dゲームはより奥行きのある内容になる可能性を秘めているため、コンテンツスコアは高くなりますが、1ターン制のプロンプトではコンテンツを拡張する余地が限られているため、総合スコアは低いままである傾向があります。

1. ジャンル特有のボトルネックの解明：評価データからは、ジャンル間でパフォーマンスに大きなばらつきがあることも明らかになっています。プレイメカニズムが複雑なジャンル（例：RPG、シューティングゲーム、レースゲーム）では、プレイアビリティに関する問題が多く発生する傾向があります。 比較的ロジックが単純なジャンル（例：サバイバルゲームやタイクーンゲーム）は、プレイテストでのパフォーマンスが良好なことが多く、そのため、視覚的な仕上げやUIデザインが次に解決すべき課題となります。ジャンル間の違いを把握することで、Buildのゲーム全体からよりバランスの取れたサンプリングを行い、評価セットを拡大する動機付けとなります。
2. 評価用ハーネスの設計から得られた教訓：フレームワークそのものを反復改善する過程で、ハーネスの信頼性について重要な教訓を得ました：

• システムメトリクス対コンポーネントメトリクス：クリーンなコード構造やAPIの使用だけでは、プレイ可能なゲームが保証されるわけではありません。修正可能なバグが見逃されないよう、正しさ、設計、表現を明確に区別しています。
• 評価フレームワークの弱点と人間によるキャリブレーション：静的チェックでは、ゲームをクラッシュさせるランタイム上の障害を見逃す可能性があり、自動プレイテストは複雑な物理演算の処理に苦戦します。仮想審査員は、プロのゲーム開発者や経験豊富なコミュニティレビュアーを基準に、継続的にキャリブレーションされています。
• マルチターンおよび実際のトラフィックへの拡張：実際のクリエイターは継続的に反復作業（システムの追加、難易度の調整、バグの修正）を行うため、私たちは評価ハネスを拡張し、マルチターンの編集や現実世界のプロンプト分布を評価できるようにしています。

今後の展望

現在、当社は「Build」創作評価システムを以下の5つの方向で拡張することに注力しています：

1. ジャンル、2D/2.5D/3D体験、マルチプレイヤーシナリオ、複雑さのレベルにわたる評価範囲の拡大
2. マルチターン編集に対するより強力なサポート
3. プレイテスト、スクリーンショット、動画、音声による証拠の信頼性向上
4. 大規模な人間による評価や、クリエイター主導のベンチマーク事例との照合
5. オフライン評価、オンラインの製品シグナル、回帰テスト間の連携強化

私たちの長期的な目標は、クリエイターが重視するレベル、つまり「制作・テスト・共有・継続的な開発が可能な体験の質」を測定する、透明性が高く継続的に改善される評価システムの構築です。現在、これらのシグナルはBuildが生成したゲームの評価に使用されています。今後、これらのシグナルをさらに洗練させ、人間の判断と照らし合わせて調整していくにつれ、他の制作ワークフローにも応用可能となり、Robloxエコシステム全体においてゲームの品質を理解するための共通言語を提供する一助となるでしょう。

Roblox Assistantのエージェント型システムの評価に関する関連記事については、「OpenGameEvalを使用したRoblox Studio向けエージェント型AIアシスタントのベンチマーク」をご覧ください。