［開発者向け］Codex×Astraで宇宙探索ゲームを作る——1万惑星を一続きで飛ぶ設計と計測の記録

2026-09-05

はじめに

　OpenAIが2026年9月4日、開発者向けブログで、コーディングエージェント「Codex」とモデル「Astra」を使ってブラウザ向けの宇宙探索ゲームを制作した過程を公開しました。本稿では、作りたい体験の伝え方からアーキテクチャの選定、計測にもとづく最適化までの進め方を解説します。

参考記事

タイトル: Building games with Astra
著者: Thomas Ricouard
発行元: OpenAI
発行日: 2026年9月4日
URL: https://developers.openai.com/blog/how-to-build-games-with-astra

要点

制作された「Void Explorer」は2,048の星系と1万を超える手続き生成の惑星を持ち、宇宙空間から大気圏を抜けて着陸し、船を降りて歩くまでを一続きで行えるブラウザゲームである
実装はTypeScriptとViteで、描画はThree.jsを採用している。当初のWebGL2構成から、シミュレーション部分を保ったままWebGPU構成へ移行した
ゲーム側に状態を読み出すJavaScriptインターフェースと名前付きのテストシーンを用意し、Astraが自分でシーンを再現して状態やスクリーンショットを確認できる構成としている
描画コール数・三角形数・破棄された地形ジョブ数などの計測にもとづき、遠景惑星のポリゴン割り当てや地形データの転送量が削減された
惑星の地形はハイトフィールド方式のため、洞窟やオーバーハングは表現できないという制約が明示されている

詳細解説

何が作られたのか

　OpenAIの記事によれば、制作されたゲーム「Void Explorer」は2,048の星系と1万を超える手続き生成(procedural generation、あらかじめ用意せずアルゴリズムで生成する手法)の惑星を持ち、地球サイズの世界も含まれます。画面に見えている星はすべて実際の宇宙の一部で、遠くの光点を目標に指定して移動できます。惑星へは宇宙空間から接近し、大気圏を通過して海岸線の上空まで降下し、着陸して船外を歩き、また離陸できます。

　なお、ここで使われている「Astra」はOpenAIの最新世代モデルで、公開前の能力評価と安全対策が注目されたモデルでもあります。今回の記事は、そのモデルが実際の制作現場でどう使われているかを示す事例だと言えます。

体験を先に伝え、ビジュアルは画像生成で詰める

　著者が最初にAstraへ渡したのは、仕様書ではなく「プレイヤーに何ができてほしいか」でした。見えているものにはすべて到達できること、距離は実際のスケールを保ったうえでスピードと演出で移動を成立させること、地球サイズの惑星があるため手続き生成の地形とチャンク単位の描画が必要になること、といった内容です。この伝え方により、星を背景の点として描いたり、惑星への接近時に別のステージへ切り替えたりする実装が最初から選択肢から外れます。

　ビジュアルの方向性は、実装に入る前に画像生成で固めています。最初の案は写実的すぎ、次は単純すぎたため、色やネオンの光、コントラストを指定して中間を探る修正を重ねたとのことです。気に入った画像は保存させ、軌道上の飛行、高速移動、大気圏突入、着陸という場面ごとの参照画像として扱っています。言葉での説明よりも画像のほうが判断基準を共有しやすい領域では、この進め方が 有効に働く と考えられます。

アーキテクチャの選定と検証環境

　制約を決めたうえで、実装方針はAstraに提案させています。採用されたのはTypeScriptとVite、描画はThree.jsです。最初に動く形になった描画はWebGL2でしたが、後に描画品質の頭打ちを相談した結果、Astraはシミュレーション部分を維持したままThree.jsのWebGPU構成へ移すことを提案しました。宇宙・航行・地形の各システムを保ったまま描画層だけを差し替えた形で、大気や水面、ライティングはThree.jsのノードマテリアルとTSL(Three.js Shading Language)でコードとして記述されています。

　地形生成はWeb Worker(ブラウザで別スレッド処理を行う仕組み)に分離し、入力と描画を担当するスレッドを止めない構成です。テストはVitestとPlaywrightで、再現性のある生成結果や座標計算といった土台を押さえることで、著者自身は「遊んだときの感触」の確認に集中できたと説明されています。

エージェントに「見る手段」を渡す

　実務的な示唆が大きいのは、Astraが自力で問題を調べられる仕組みを先に用意している点です。ゲームは window.__VOID_EXPLORER__ という小さなJavaScriptインターフェースを公開しており、ブラウザテストから現在の状態(接近中の天体、飛行モード、地形の準備状況、有効なカメラ)を読み出せます。あわせて描画コール数、三角形数、待機中の地形ジョブ数、バッファ済み地形データといった計測値も取得できます。

　さらに、軌道飛行・パルス移動・大気圏降下・海岸への着陸といった名前付きのテストシーンを用意しており、毎回宇宙を横断しなくても目的の状況から検証を再開できます。Playwrightはシーンを読み込み、地形の準備完了を待ち、スクリーンショットと背後の状態を確認します。これとは別に、実際の操作で位置や状態変化を記録する通し(ジャーニー)テストも用意され、着陸、船外への移動、歩行、セーブと再読み込み、乗船、離陸までを対象としています。シーンを直接呼び出す検証だけでは、着陸そのものを確かめたことにはならないためです。

　この構成があると、作業は「問題を再現し、スクリーンショットと状態を確認し、該当コードをたどり、修正し、再検証する」というループになります。再現可能なシーン、意味のある状態と性能のカウンタ、主要操作のブラウザテストの3点は、AIエージェントと組んで開発する際の共通の準備物として応用できると思います。

スケールと連続した降下をどう成立させたか

　1万を超える惑星といっても、詳細なメッシュを1万個読み込むわけではありません。惑星は半径・軌道・大気・シード値といった「記述」として存在し、シード値によって同じ地形が何度でも再現されます。座標についても、光年単位の距離と船の横に立つ人物ではスケールが違いすぎ、巨大な座標をそのままGPUへ渡すと地表付近の精度が失われます。Astraは宇宙上の住所を大きな整数のセルと小さなローカル座標に分け、描画前に観測者の位置を差し引いてカメラを原点に置く方式を採りました。

　降下の連続性は反復を要した部分です。浅い角度で接近すると速度が出すぎ、地形の読み込み中に惑星が見えなくなる問題があったため、高度と惑星の半径・重力から見積もった軌道速度をもとに、浅い接近には別の速度上限をかける調整が入っています。描画はLOD(Level of Detail、距離に応じて描画の詳細度を変える手法)を複数段構えとし、遠方では低ポリゴンの球、接近すると立方体の6面を球面に投影した地形へ切り替え、各面は四分木(quadtree)で再帰的に分割されます。

　受け渡しの設計も重要な点です。遠景の惑星は粗い地形6面がすべて準備できるまで表示を維持し、地形タイルは4つの子タイルがそろうまで置き換えられません。切り替え中は相補的なピクセルマスクで各ピクセルを新旧いずれかの面に割り当て、置き換え待ちの間に惑星全体が透明になる事態を避けています。着陸時はさらに厳しく、見えている地面、当たり判定の三角形、液体の危険領域が同じ生成結果から同時にそろう必要があります。一方で、惑星の地形は各方向に1つの高さを持つハイトフィールド方式のため、洞窟やオーバーハング、破壊可能なトンネルは表現できないという制約も明示されています。

計測にもとづく最適化

　性能改善では、体感の指摘をAstraが計測に置き換えています。Three.jsの描画カウンタで描画コール、三角形、ジオメトリ、テクスチャを確認し、Playwrightのテストで90フレーム分の間隔を収集して平均値やパーセンタイルを併記する形です。手続き生成の船をBlender製のモデルに置き換えた際の比較では、描画コールが119から77へ減り、三角形数は48,809から61,092へ増え、平均フレーム間隔は251.48ミリ秒から199.26ミリ秒になったと報告されています。ただしこの計測はヘッドレスChromiumとソフトウェアレンダリングによるもので、実機のフレームレートではないと明記されています。

　地形側では、遠景惑星のポリゴンを画面上の大きさに応じて配分する方針に変えた結果、同一条件の比較で51,200だった代理形状の三角形数が7,040になりました。また、隣接する三角形で頂点を共有するインデックス付きメッシュの採用により、三角形数241,952を維持したまま転送データ量が約35MBから15MBへ減っています。地形の選択処理では、要求と破棄を繰り返す無駄が見つかり、判断を安定させて子タイル4枚分の予算があるときだけ細分化する方式に変えたところ、条件をそろえたシミュレーションで破棄されたジョブが6,074件から13件になりました。これらは幾何量や転送量、無駄な処理の削減を示す数値であり、ハードウェア上のフレームレートの計測ではない点には注意が必要です。

　なお、制作された3作品はブラウザで公開されており、Sitesプラグインに「@Sitesでこのゲームをデプロイしてリンクを出して」と依頼する形で共有できると説明されています。手元で動くものをすぐ人に触ってもらえる点は、試作の回し方に影響すると考えられます。

まとめ

　今回の事例は、体験の指定と画像による方向づけを人が担い、アーキテクチャの提案・計測・実装をAstraが担う分担で構成されています。中でも、状態を読み出すインターフェースと再現可能なテストシーンを先に用意した点は、他の開発にも移しやすい工夫だと思います。Codexの実務への組み込みについては、過去記事でも整理していますので、あわせてご覧ください。