企画とプロトタイプで「この遊びは面白い」と確かめたら、次はその遊びを、実際のステージの形にして試します。色も質感もない灰色の箱でステージを組み、操作するキャラクターで歩いて・跳んで・戦ってみて、大きさと配置を直していく。この工程がグレーボクシング(ステージ仮組)です。全工程の中では、プリプロダクション(作るべきか・作れるかを、企画と試作で確かめる段階)の後半にあたり、美術を作り込むバーティカルスライスの前に置かれます。量産に入ってからも、新しいステージを作るたびに同じ手順を繰り返します。全体の流れは「ゲーム開発の全工程マップ」で確認できます。
本記事では、グレーボクシングの定義と目的、基準の寸法(メトリクス)の決め方、組み方の順番、美術へ渡すまでの進め方を、3D のアクションだけでなく 2D・ノベルゲーム・UI の例も交えて解説します。後半では、AI エージェントを使うとこの工程がどう変わるかを、筆者の実例とあわせて紹介します。エンジンの機能名と数値は、2026年10月時点の公式ドキュメント(Unreal Engine 5.8、Unity 6.6、Godot 4.7)で確認しています。
夕宮たいだふぁ……みんな〜、今日は「灰色の箱でステージを組む」話だよぉ。見た目はすっごく地味なんだけど、ここで決めた寸法が最後まで効いてくるんだぁ。いっしょに見ていこ〜。
グレーボクシングとは
ひとことで:灰色の箱・坂・円柱のような単純な形でステージを仮組みし、遊びと大きさを先に確かめる工程です。
グレーボクシングは、細部や仕上げの絵を入れずに、単純な形だけでレベル(ステージやマップ)の下書きを作る工程です。Unreal Engine 5.8 の公式ドキュメント「Project Setup and Level Blockout」は、完成した絵や細部より先にレイアウトと遊びやすさに集中するこの段階を「blockout(grayboxing)」と呼び、絵の具で仕上げる前にキャンバスに鉛筆で下書きするようなもの、とたとえています。呼び方は現場によって違い、次のように使われています。
| 呼び方 | 意味 | 補足 |
|---|---|---|
| グレーボクシング/グレーボックス | 灰色の単純な形で組んだ仮のステージ(を作ること) | 英語では greybox と graybox の両方の綴りが使われる |
| ブロックアウト/ブロックメッシュ | 同じ意味で使われることが多い | Epic Games の UEFN(フォートナイト向けの制作ツール)のドキュメントも、グレーボクシングを「ブロックアウトとも呼ぶ」と説明している |
| ホワイトボックス | 同じ意味で使う現場もある | QA の「ホワイトボックステスト」(中の仕組みを知った上で行うテスト)とは別物 |
| アートパス | 仮組を、本番の見た目に作り込む美術の作業 | グレーボクシングの次の段階 |
グレーボクシングで作るのは「見た目」ではなく「形」です。床の広さ、壁の高さ、段差、足場の間隔、敵が出る広場、遠くに見える塔。こうした遊びに関わる形を、作り直しが安いうちに決めます。灰色の箱はやがてアートパスで本番の建物や岩に置き換わりますが、配置と寸法はそのまま引き継がれます。
前後の工程との違いは、それぞれが確かめる問いで整理すると分かりやすくなります。
| 工程 | 確かめる問い | 作る物 |
|---|---|---|
| プロトタイプ | この遊びは面白いか(作るべきか) | 遊びの核だけを動かす、使い捨ての試作 |
| グレーボクシング | その遊びが、この大きさ・この配置のステージで成り立つか | 灰色の形で組んだ、通して遊べるステージ |
| バーティカルスライス | 製品と同じ品質で作れるか | 一部分を製品版に近い品質まで仕上げた版 |
なぜ灰色の箱で組むのか
ひとことで:作り直しが安いうちに遊びと大きさを決め、美術の大きな手戻りを防ぐためです。
灰色の箱を動かすのは数秒ですが、質感・照明・装飾まで仕上げた建物を動かすと、作り直しに何日もかかります。レベルデザインの解説サイト『The Level Design Book』も、荒いブロックアウトは消すのも作り直すのも安く、仕上げた美術を捨てるのは高くつく、と説明しています。グレーボクシングの目的を整理すると、次の5つになります。
- 遊びと大きさを確かめる:本物の操作・速さ・ジャンプで歩き、広すぎる・狭すぎる、遠すぎる・近すぎるを体で確かめます
- 美術の手戻りを防ぐ:寸法と配置を決めてから美術を作るので、完成した絵を作り直す事故が減ります
- 見た目にだまされずに判断する:きれいな絵が入ると、遊びの問題(迷う・単調・窮屈)が見えにくくなります。灰色なら形だけで判断できます
- チームの共通の土台にする:企画・プログラム・美術・音が、同じステージを歩きながら話せます。美術は寸法の決まった部品(モジュール)を作り始められます
- 量の当たりを付ける:広さから、必要な部品の数・敵の数・1周の時間を見積もれます
時期は、プロトタイプで遊びの核が固まった後、美術を作り込む前です。プリプロダクションでは代表的なステージを1〜2面組んで、進め方と基準(次の節のメトリクス)を固めます。量産(プロダクション)に入ってからも、新しいステージはまずグレーボックスで組み、遊んで直してから美術に回します。



ほよ? 灰色のまま遊ぶんだぁ。見た目がないほうが、遊びのダメなところがよく見えるんだねぇ。
メトリクス(基準の寸法)を先に決める
ひとことで:キャラの大きさ・移動やジャンプの性能を測り、それに合わせて通路・扉・段差・足場の寸法ルールを決めます。
メトリクスは、キャラの大きさ・移動やジャンプの性能と、それに合わせた通路・扉・段差の寸法ルールのことです。『The Level Design Book』は、メトリクスを2種類に分けています。
- プレイヤーのメトリクス:エンジンの中で測れる事実の値。身長と幅、移動の速さ、ジャンプの最大の高さなど
- 建物のメトリクス:体験の狙いに合わせて自分で決める寸法のルール。通路の幅、扉の大きさ、段差の高さなど
数値はゲームごとに決めるものです。同じ人型のキャラクターでも、軽快なアクションと、じっくり進む探索のゲームでは、気持ちのいい通路の幅が違います。
まずキャラの性能を測る
最初に、実際に操作するキャラクターで次の値を測り、表にします。計算で出すのではなく、ゲームの中で実際に動かして測るのがポイントです。加速や空中での操作があると、計算どおりの距離にならないためです。
| 測る値 | 測り方の例 |
|---|---|
| 身長と幅 | 当たり判定(カプセルなど)の寸法 |
| 歩く・走る速さ | 10m(2D なら10マス)を走りきる時間 |
| ジャンプの最大の高さ | 少しずつ高くした段に、跳び乗れる上限 |
| 走って跳んだときに届く距離 | 少しずつ広げた隙間を、越えられる上限 |
| 無傷で降りられる高さ | 落下のダメージや硬直が出ない上限 |
| カメラの位置と画角 | 三人称なら、キャラの後ろの距離と高さ |
性能は開発中に何度も変わります。表には版(いつの値か)を付け、性能を変えたら寸法のルールも見直します。
性能から寸法のルールを作る
次に、測った性能から寸法のルールを決めます。大切なのは、「登れる」「登れない」がはっきり分かる寸法にすることです。登れそうで登れない高さや、届きそうで届かない隙間は、意図して置く場合(隠し通路のヒントなど)を除いて作りません。3D アクションの例を挙げます。数値はすべて例です。
| 項目 | キャラの性能(例) | 寸法のルール(例) |
|---|---|---|
| 段差 | ジャンプの最大の高さ 1.2m | 登れる段差は 1.0m まで。登れない壁は 1.5m 以上。1.0〜1.5m の高さは作らない |
| 足場の間隔 | 走って跳んで届く距離 4.0m | 普通の足場は 3.0m まで、難しい足場は 3.5m、越えられない隙間は 5.0m 以上 |
| 通路 | キャラの幅 0.6m | 1人で通る通路は 1.5m 以上、敵とすれ違う通路は 3m 以上 |
| 扉 | 身長 1.8m | 幅 1.2m・高さ 2.2m(カメラが後ろにある三人称なら広げる) |
| 落下 | 無傷で降りられる高さ 3m | 一方通行にしたい段差は 1.5〜3m(登れないが、無傷で降りられる)。3m を超える所は柵などで落ちられないことを見せる |
登れる段差を上限ぎりぎりの 1.2m にしないのは、斜めから跳んだときや、操作が少し遅れたときにも確実に登れるようにするためです。逆に、登れない壁は上限から十分に離して、試す前から「無理だ」と分かる高さにします。Unreal Engine 5.8 の公式ドキュメントにも同じ考え方の例があり、ジャンプの高さ 0.5m の人に対して、進む方向を示すために置く低い庭の塀を 0.6m(ジャンプより10cm高い)にして、「沿って歩かせるが、跳び越えさせない」物にしています。
2D なら、寸法を「マス」で考えます。例えば2D アクションでジャンプの高さを3マスにすると決めたら、登れる段差は2マスまで、登れない壁は4マス以上にそろえます。1マスを64ピクセルにして1920×1080の画面に表示すると、横は30マス、縦は約17マスです。跳ぶ前に着地する場所が画面に見えているかも、あわせて確かめます。
エンジン公式の目安と、よく引かれる資料
自分の数値を決めるときの参考として、公開されている目安を挙げます。どれも業界の決まりではなく、それぞれの資料も「目安」として紹介しています。
| 資料 | 目安の例 | 補足 |
|---|---|---|
| Unreal Engine 5.8 公式ドキュメント | 人=身長 1.8m・ジャンプ 0.5m/廊下=幅 2〜3m・高さ 3〜4m/扉=幅 1〜1.5m・高さ 2m/壁=高さ 4m・厚み 10〜30cm から | 三人称のカメラは後ろに引くぶん物が小さく見えるので、寸法を1.5倍にする目安も示す。公式も、目安にすぎず、ゲームの体験に合わせて決めるものだと明記 |
| The Level Design Book | プレイヤーの大きさの例=Unity 1.0×1.8m、Unreal 60×176cm(目の高さ 152cm)/廊下の幅は最低でもプレイヤーの幅の2倍(それでも狭く感じる)/階段の傾きは30〜35度 | メトリクスは判断を助ける道具であって、魔法ではないと注意している |
| 『Skyrim』のレベルデザインの講演(GDC 2013、講演者による寄稿) | キャラの身長は約128ユニット(6フィート)/AI が通れるよう、通路は最低でもキャラ2人分の幅/部品の寸法は互いの倍数(512 と 256 など)/グリッドのスナップは部品の寸法の半分 | 部品(モジュール)を組み合わせてステージを量産する作り方の例(Game Developer) |
メトリクスの見本部屋を作る
数値を決めたら、それを確かめる専用の部屋を作ります。『The Level Design Book』は、ゲームで使う物や部品を並べた開発者専用のテスト用マップを「metrics zoo(メトリクスの動物園)」と呼び、壁が高すぎて跳べないか、隙間が広すぎないかを、実際に遊んで確かめるよう勧めています。『Fallout』の共同制作者 Tim Cain も、戦闘や会話などの機能だけを切り離して試す「テストルーム」を、制作の最初の段階に挙げています(Game World Observer、2023年11月)。
見本部屋には、例えば次のような物を並べます。
- 0.5m から 1.6m まで、0.1m ずつ高くした段差(床に高さの数字を書いておく)
- 2.0m から 5.0m まで、0.5m ずつ広げた隙間
- 幅 1m・1.5m・2m・3m の通路と、大きさ違いの扉
- 傾きの違う坂(20度・30度・35度・45度など)と階段
本物のキャラクターとカメラで歩き、気持ちよく通れる値と、はっきり通れない値を選んで、表を確定させます。





メトリクス……むずかしいねぇ。でも要は「このキャラはどこまで跳べるか」を先に測って、ステージの寸法をそれに合わせるって話なんだぁ。
グレーボクシングの進め方
ひとことで:グリッドとスケールを決め、動線・目印・遊びの場所の順に組み、遊んで直してから美術へ渡します。


①グリッドとスケールを決める
最初に、エンジンの1単位の長さと、形を置くグリッド(方眼)の間隔を決めます。Unreal Engine は1単位を1cm として扱い、Unity は物理などの計算が1単位=1m を前提にしています。『The Level Design Book』は、メトリクス(特にプレイヤーの幅)をもとにした粗いグリッドを使うよう勧め、Unity なら1か2、Unreal なら 50/100 や 64/128 を例に挙げています。Unreal Engine 5.8 の公式の手順でも、LevelPrototyping の箱・坂・円柱をグリッドにスナップ(吸着)させながら置いていきます。
あわせて、人の大きさの目安(スケールリファレンス)をステージに置きます。完成した絵がない状態では大きさの感覚が狂いやすいので、常に人の大きさと見比べながら組みます。
箱の色は、役割で分けると話が早くなります。『The Level Design Book』も、色と明るさは「その空間が何でできているか」を伝える大切な手がかりだとしています。例えば「歩ける床=明るい灰色、壁=暗い灰色、登れる所=黄色、危険な所=赤、仮の敵=赤い円柱」のように決めておきます。
②動線を引く(主な道と寄り道)
いきなり箱を置かず、まず真上から見た見取り図を描きます。走り書きでも十分です。そのうえで、次の2つを分けて考えます。
- 主な道(クリアに必要な道):入口から目的地まで、迷わずに進める一本の流れ
- 寄り道(任意の道):ご褒美・近道・景色のための道。行き止まりには、ご褒美か、主な道へ戻る道を用意する
緊張する場所(戦闘など)と、休める場所(安全な部屋など)を交互に並べると、遊びにリズムが出ます。組んだら、主な道を歩いて通りきる時間を測っておきます。1周の時間は、ゲーム全体のボリュームを見積もる材料になります。
③視線と目印(ランドマーク)を置く
プレイヤーは地図を読むより、見えている物に向かって進みます。遠くからでも見える塔や光る門などの目印(ランドマーク)を、入口から見える位置に置き、「先に見せてから、そこへ行かせる」並びにします。通路の先を明るくする、壁や床の線で行き先を指す、開けた場所から次の目的地を見せる、といった手もあります。GDC 2018 のワークショップ「Invisible Intuition: Blockmesh and Lighting Tips to Guide Players and Set the Mood」(Naughty Dog の David Shaver と、NYU の Robert Yang)でも、ブロックメッシュの形と照明でプレイヤーを導く技法が紹介されています。
確かめ方は単純で、初めての人に説明なしで遊んでもらい、主な道を見つけられるかを見ます。
④戦闘や謎解きの場所を作る
遊びの山場になる場所は、寸法に特に気を配ります。
- 戦闘:敵の数に対する広場の大きさ、身を隠す物の間隔、出入口の数、高低差。敵は色付きの円柱などで仮に置きます
- 謎解き:解くのに必要な物がすべて見えるか、行き詰まったときにやり直せるか、解くのにかかる時間
- 隠れて進む遊び:敵の視線が通る線と、隠れられる場所の位置
戦闘の広場は、カメラの引き具合でも感じ方が変わります。三人称のカメラなら、壁際でカメラが壁に埋まらないかも確かめます。
⑤遊んで直す
組んだら、本物の操作で遊びます。『The Level Design Book』は、重力・当たり判定・移動の速さがすべて本番どおりの状態で、エンジンの中を歩き回るよう勧めています。最初の案は、遊んでみるとほぼ確実に直す所が見つかります。「遊ぶ→メモする→直す→また遊ぶ」を、短い間隔で回します。
- 自分で遊ぶだけでなく、他の人に説明なしで遊んでもらい、迷った場所・止まった場所を記録する(詳しくは「プレイテストのやり方」)
- 版ごとに、真上から見た画面写真と1周の時間を残し、直す前と後を比べられるようにする
- 灰色のまま見た目を整えたくなっても後回しにする。形の問題を直すのが先
⑥美術へ渡す(アートパス)
形と寸法が固まったら、美術の担当者に渡し、灰色の形を本番の見た目に置き換えてもらいます。渡すときは、次の物をそろえます。
- メトリクスの表と、寸法を書き込んだ見取り図
- 動かしてはいけない所(跳ぶ隙間・隠れる物の位置・視線の通り道など、遊びに関わる寸法)と、自由に作ってよい所の区別
- 見せたい景色(目印の見え方)の画面写真
- 当たり判定の扱い。見た目と当たり判定を分けておくと、装飾を足しても通り道が狭くならない(Unreal Engine の公式の手順では、見えない当たり判定として Blocking Volume を使っている)
美術が入ると、装飾で通路が狭くなる、目印が背景に紛れる、照明で行き先が見えにくくなる、といった変化が起きます。アートパスの後に、グレーボックスのときと同じ確認をもう一度行います。灰色の版も残しておくと、遊びの問題か見た目の問題かを切り分けられます。
エンジンごとのブロックアウトの道具
| 環境 | 主な道具 | 特徴 |
|---|---|---|
| Unreal Engine | LevelPrototyping の箱・坂・円柱をグリッドにスナップして置く。Modeling Mode で形を作る | 公式ドキュメントにブロックアウトの手順がある。Modeling Mode は UEFN のドキュメントでグレーボクシングの道具として案内されている |
| Unity | ProBuilder(シーンの中で形を作り、編集する) | 公式マニュアルは用途を「シーン内のレベルデザイン、プロトタイピング、コリジョン用メッシュ、プレイテスト」と説明。Unity Learn にグレーボックスの教材もある |
| Godot | CSG ノード(基本の形を足し引きして組む) | 公式ドキュメントはレベルの試作を主な用途とし、UV の編集はできない。本番の形には FuncGodot や Cyclops Level Builder の検討を案内している |
| 2D(各エンジン) | タイルマップ(Unity の Tilemap、Godot の TileMapLayer など) | マス目にタイルを塗るようにして足場を組める |
| DCC(Blender・Maya・Houdini など) | 形を組んで、エンジンへ書き出す | スクリプトや手続き型の生成で、何案も作る使い方もできる |



箱の色を「歩ける・登れる・危ない」で分けておくと、美術の人に渡すときにも話が早いんだぁ。ほら、便利でしょ?
3Dだけではない:2D・ノベル・UIの仮組
ひとことで:2D はタイルで足場を、ノベルは背景・立ち絵・文字枠の配置を、UI は画面の骨組みを、本番の絵の前に仮組みして確かめます。
グレーボクシングの考え方は、3D のステージ以外にも使えます。共通するのは「本番の絵を作る前に、形と配置と大きさを、実際の画面と操作で確かめる」ことです。
2D:タイルで足場を仮置きする
2D アクションでは、単色のタイルで足場を塗り、実際のキャラクターで跳んで確かめます。タイルは役割で色を分けます(例:乗れる床、下からすり抜けられる足場、触れると危ない所)。マスの数で寸法を管理できるので、メトリクスの表もマス単位で作ります。見下ろし型の RPG やパズルでも同じで、通路の幅・部屋の広さ・建物とキャラクターの大きさの比を、仮のタイルと仮のキャラクターで先に決めます。
ノベルゲーム:背景・立ち絵・文字枠を仮組みする
ノベルゲームの「ステージ」は1枚の画面です。本番の背景や立ち絵を描く前に、灰色の背景、人の形のシルエット(本番と同じ大きさ)、文字枠、名前の欄、選択肢のボタンを並べて、次の点を確かめます。
- 立ち絵の顔が文字枠に隠れないか。立ち絵の足元(または腰)の位置をどこにそろえるか
- 1人・2人・3人が並んだときの位置(左・中央・右)が重ならないか
- 文字枠に、本文でいちばん長い台詞が収まるか(1行の文字数と行数を先に決めて、実際の台詞を流し込む)
- 一枚絵(スチル)を出したとき、文字枠で大事な所が隠れないか
ダミーの文章ではなく、シナリオの実際の台詞で確かめると、文字枠の大きさの決め違いを早く見つけられます。
UI:画面の骨組み(ワイヤーフレーム)を仮組みする
メニューや HUD(遊んでいる間ずっと出ている表示)も、灰色の四角と仮の文字で骨組みを作り、実際に操作して確かめます。何を常に出し、何を必要なときだけ出すか、ボタンの大きさと並び、コントローラーで選ぶ順番(フォーカスの移り方)などです。翻訳すると文字数が増える言語もあるので、多言語に対応する予定があれば、長い文字列でも崩れないかを仮組の段階で見ておきます(「ゲームのローカライズ」)。





ノベルでも「仮組」ってできるんだねぇ。灰色の人形を並べてみるだけでも、文字枠の失敗はけっこう見つかるよぉ。
判断の基準と完了の条件
ひとことで:「最後まで通して遊べる」「迷わない」「寸法がメトリクスを守っている」「美術に渡す範囲が決まっている」がそろえば完了です。
グレーボクシングは、作り込むほど終わらなくなる工程です。次の表で、合格の目安とやり直しのサインを確かめます。
| 観点 | 合格の目安 | やり直しのサイン |
|---|---|---|
| 通して遊べる | 最初から最後まで、本物の操作で通せる | 途中に通れない所・戻れない所がある |
| 迷わない | 初めての人が、説明なしで主な道を見つける | 何人も同じ場所で止まる |
| 寸法 | 段差・隙間・通路がメトリクスの表のとおり | 意図していないのに、登れそうで登れない高さがある |
| 遊びの密度 | 戦闘・謎解き・休む所の並びが狙いどおり | 何も起きない移動が長く続く |
| 時間 | 1周の時間が見積もりの範囲に収まる | 想定の倍以上かかる |
| 美術との合意 | 動かしてはいけない所と、自由に作ってよい所が決まっている | 美術が作り始めてから、寸法の質問が相次ぐ |
期間に決まりはありません。参考として、『Skyrim』の講演では、部品の一式(キット)がグレーボックスの段階にある期間を1〜4週間と紹介しています。個人や少人数なら、ステージごとに「灰色のまま通して遊べるところまで何日」と期限を決め、期限が来たらこの表の観点で判断します。直しても遊びの感触がほとんど変わらなくなったら、灰色で決められることは出尽くしたと考え、美術へ進めます。
AIゲーム開発でのグレーボクシング
ひとことで:箱を並べる・何案も作る・寸法を検査する作業は AI に任せやすく、遊んだ手触りと「面白い配置か」の判断は人に残ります。
グレーボクシングは、AI エージェントと相性のよい工程です。形が単純で、寸法を数値で書けて、結果を自動で検査できるからです。一方で、「遊んで気持ちいいか」は AI には分かりません。作る手間が減るぶん、遊んで比べて捨てる判断が重くなります。
AIに任せやすいこと
| 作業 | AI に頼む形 | 人が確かめること |
|---|---|---|
| 箱を並べる | 見取り図や寸法の表から、エディタ用のスクリプト(Unity の Editor スクリプト、Godot の EditorScript、Blender の Python など)で、箱・坂・足場を配置させる | 実際に歩いて、狙いの大きさに感じるか |
| 何案も作る | 部屋の数・通路の幅・高低差などを数値で変えられる手続き型の生成で、配置の案を3〜5通り出させる | 何を比べて絞るか(比べる観点)を先に決める |
| 寸法を検査する | メトリクスの表(CSV や JSON)を読み、通路の幅・段差の高さ・足場の間隔を測って、表に反する場所を一覧にさせる | 「わざと」の違反(隠し通路など)を見分ける |
| 見本部屋を作る | メトリクスの見本部屋(段差・隙間・通路を少しずつ変えた部屋)を、表から自動で組ませる | どの値が気持ちいいかを、遊んで決める |
| 記録を残す | 版ごとに、真上からの画面写真・1周の時間・つまずいた場所をまとめさせる | 記録から、何を直すかを決める |
| 見た目の方向を探る | グレーボックスの画面写真をもとに、生成AIで完成のイメージを何案か作らせる | 寸法は灰色の版と表を正とし、絵は雰囲気の参考にとどめる |
寸法の検査は、手作業では見落としやすく、AI に任せる効果が大きい作業です。例えば、キャラクターの大きさで歩ける範囲(ナビメッシュ)を作り直して、つながっていない場所を探す。測ったジャンプの高さと距離から、足場どうしが届くかを総当たりで調べる。こうした検査をスクリプトにしておけば、案を作るたびに自動で走らせられます。
人が決めること・確かめること
- 手触り:跳んで気持ちいいか、狭くて息苦しくないか、広すぎて退屈でないか
- 面白い配置か:寸法が正しくても、遊びとして面白いとは限りません
- 見せたい景色:どこで何を見せるか、目印がどう見えるか
- メトリクスの表そのもの:寸法のルールを変えるかどうか
- どの案を残すか:最後に選ぶのは人です
重心はどう動くか
AI を使うと、箱を置く作業はほぼ自動になり、案を出す速さも上がります。代わりに、出てきた案を遊び、比べ、捨てる作業が人の仕事の中心になります。もう一つ大切になるのが、メトリクスを「数値の表(ファイル)」として残すことです。表があれば、AI に作らせるときの指示にも、検査の基準にも、同じ表を使えます。口頭や感覚のままのルールは、AI には伝わりません。
落とし穴
- 置けるが、気持ちいいかは分からない:スクリプトは寸法どおりに置けても、手触りは遊ばないと分かりません。AI の「完成しました」は、寸法の検査に通ったという意味にすぎません
- 案が多すぎて比べきれない:10案を毎回全部遊ぶと、疲れて判断が雑になります。比べる観点を2〜3に絞り、同じ視点の画面写真を並べて候補を減らし、実際に遊ぶのは上位2案だけにします
- 表のほうを書き換えられる:検査に通すために、AI がメトリクスの表を変えてしまうことがあります。「表を変えてよいのは人だけ」と依頼文に書きます
- 当たり判定のない箱・重なった箱:スクリプトで置いた形に当たり判定がない、グリッドからずれている、形どうしが重なっている、といった事故も検査に含めます
- 生成した絵が寸法を守らない:グレーボックスの画面写真から生成AIで作った完成のイメージは、扉や段差の大きさがメトリクスとずれていることがあります。その絵を見て美術を作ると、アートパスで寸法が崩れます
- 重い操作で道具が落ちる:起動中のエディタに大量の操作を一度に送ると、ツールが落ちることがあります。重い処理は、画面を出さずに実行する形に分けます
依頼文は、例えば次のように書きます(書き方の基本は「Claude Code プロンプト設計」「Codexプロンプト設計」)。
Goal: 2Dアクションのステージ1-2を、灰色のタイルだけで仮組みする(Godot の TileMapLayer に置くスクリプトを書く)
Context: メトリクスは docs/metrics.csv(ジャンプの高さ3マス・走って跳んで届く距離5マス・1マス64px)。
見取り図は docs/stage1-2_sketch.png。完成した絵は使わない
Done when: 最初から最後まで届くこと(段差と足場の間隔がすべて metrics.csv の範囲内)をスクリプトで検査し、
違反0件の検査結果と、ステージ全体の画面写真を出している。metrics.csv は変更しない
筆者の実例
筆者は、ゲームとは別に、Houdini の手続き型の生成ツール(デジタルアセット)を AI に作らせたことがあります。GUI の操作手順を人がなぞるのではなく、AI がスクリプトでツールを組み立て、画面の撮影と、まっさらな環境でのテストで自分の作業を確かめる進め方です。作ったのは、コースの動きを9種類の「文法」の組み合わせで作り、衝突を避ける処理を入れて実際の衝突を0にしたコースの生成や、地形・段丘・必ず海へ流れる川・遺跡を一度に作る島の生成などです。途中、起動中の Houdini にライブ接続して大量の操作を送ったところ Houdini が落ちたため、画面を出さずに実行する方式に切り替えました。手続き型でグレーボックスを量産するときも、重い処理は画面なしで回すのが安全です(Houdini を Python で動かす方法は「Python in Houdini入門」)。
開発中の RPG の試作では、探索マップを「コンセプトアート→背景の規格表→街の地図→グレーボックス→清書」の順で作っています。広さは、実際のゲーム画面でキャラクターの身長に対する比を測って決めました。扉は身長の0.77倍、街灯は1.6倍、通り道は約4倍です。扉が身長より低いのは現実の寸法とは違いますが、画面の中での見え方を基準にしています。こうした比を規格表にしておくと、AI に背景を描かせるときの指示にも、できた絵を確かめるときの物差しにも使えます。



ぁぅ……AI に10案出してもらうのは一瞬なんだけど、全部遊んで比べるのは人なんだよねぇ。比べる観点は、先に決めておいてねぇ。
よくある失敗と対処
ひとことで:多くは「寸法の基準がない」「遊ばずに判断する」「灰色の段階で作り込みすぎる」のどれかから起きます。
| 症状 | 主な原因 | 対処 |
|---|---|---|
| 美術を入れたら通路が狭くなった・通れない | 装飾が当たり判定ごと通路を削った | 通路の寸法を「動かしてはいけない所」にし、装飾と当たり判定を分ける |
| 「跳べそう」で跳べない場所に人が集まる | あいまいな高さ・距離が残っている | 登れる寸法と登れない寸法の間を空け、意図しない中間の値を検査で探す |
| ステージごとに大きさの感覚がばらばら | メトリクスの表がない、または途中で変えた | 見本部屋で表を確定し、性能を変えたら全ステージを検査し直す |
| 初めての人が迷う | 目印がない、行き先が見えない | 入口から目印を見せ、明るさや線で行き先を示す |
| 巨人や小人の世界に見える | 人の大きさの目安がない、カメラの高さが合っていない | 人の大きさの目安を置き、カメラの高さと画角を本番に合わせる |
| 灰色の段階が何週間も終わらない | 見た目を整え始めた、終わりの条件がない | 期限と完了の条件を先に決め、形の問題だけを直す |
| 見取り図では良かったのに、遊ぶとつまらない | 遊ばずに図面だけで判断した | 本物の操作とカメラで遊び、他の人にも遊んでもらう |
| アートパスの後に手触りが変わった | 美術で見え方や通り道が変わった | アートパスの後に、同じ確認をもう一度行う |
チェックリスト
ひとことで:美術に渡す前に、次の項目を確かめます。
- [ ] キャラの性能(身長・幅・速さ・ジャンプの高さと距離)を、実際の操作で測って表にした
- [ ] 段差・足場の間隔・通路・扉の寸法ルールを決め、意図しない「登れそうで登れない」高さを作っていない
- [ ] メトリクスの見本部屋で、本物のキャラとカメラを使って寸法を確かめた
- [ ] グリッドの間隔と、エンジンの1単位の長さを確かめてそろえた
- [ ] 人の大きさの目安をステージに置いて組んだ
- [ ] 主な道と寄り道を決め、行き止まりにはご褒美か戻り道がある
- [ ] 目印が入口から見え、初めての人が説明なしで主な道を見つけられた
- [ ] 戦闘・謎解き・休む所の並びと、1周の時間を記録した
- [ ] 動かしてはいけない所と、美術が自由に作ってよい所を書き分けた
- [ ] アートパスの後に、同じ確認をもう一度行う予定を入れた
- [ ] (AI を使う場合)メトリクスの表をファイルにし、案を作るたびに寸法の検査を自動で走らせている
次に読む記事
ひとことで:仮組で形が決まったら、一部分を製品の品質まで仕上げるバーティカルスライスへ進みます。
- バーティカルスライスとは:仮組したステージの一部を、製品版に近い品質まで作って基準を決める
- ゲームアセット制作の流れ:アートパスで使う素材を、リスト・発注・検収で量産する
- ゲームのプロトタイプとは:グレーボクシングの前に、遊びそのものを確かめる工程
- プレイテストのやり方:他の人に遊んでもらい、迷う場所や退屈な場所を見つける
- Claude Code × 3DCG活用ガイド:Blender・Maya・Houdini を AI から操作する方法



ふぁ……灰色の箱、地味だけど奥が深いんだぁ。まずはキャラの跳べる高さを測るところから、試してみてねぇ。









