ゲーム制作の話をしようとすると、企画、没案、コード生成、素材、音楽、テスト、公開準備まで話したくなります。VOLT NOMADのLT初稿にも、それらを説明できる材料が揃っていました。
ただ、5分で工程を一通り紹介すると、聞き手が次の制作で何を変えればよいかが埋もれます。この記事では実在する資料を読み直し、聞き手に残したい判断に直接つながる例へ、持ち時間を配分する構成案を作ります。登壇時の反応や、実際に5分で話せたという記録ではありません。
初稿は9枚、改訂版では導入が増えていた
2026年8月27日の日付が入ったvolt-nomad-lightning-talk-draft.pptxは9枚でした。内容は、タイトル、自己紹介、今日の話、ゲーム紹介、Game Jam、プロトタイプ、Codex、素材制作、持ち帰るメッセージです。
同じ資料から作られた見た目の改訂版は10枚、個人サービスの紹介を加えた版は11枚です。ファイルの本文を抽出して比較すると、ゲーム制作の中核の話題はほぼ同じで、導入の画面が増えていました。これらが実際に登壇で使われた最終版かは確認していません。
この差を見ると、「スライドを一枚増やす」ことは、単純に同じ説明を見やすくするだけではありません。自己紹介、テーマの宣言、ゲームの説明に使う時間が、本題の具体例と競合します。
必要なのは枚数の一律制限より、重なった役割を見つけることです。この資料なら、タイトル、今日の話、ゲーム紹介を連続して説明する代わりに、ゲーム画面を見せながら題材と話の目的を伝える構成にできます。
一つ残すなら、採用・破棄の判断を制作へ戻す話にする
元の構成メモは、AIが制作できる範囲を広げ、Game Jamの締切と公開先が完成へ向かう条件になった、という筋を置いています。初稿の終わりにも、締切、AI、人の判断が並んでいました。
この材料から、5分版の問いを「AIに作業を任せられるようになったとき、何を人が決め続けるか」に絞ります。答えとして残すのは、動くものを比較し、残す案を選び、その選択を実装へ戻すことです。これは今回の編集案であり、聴衆に伝わったと確認した結論ではありません。
制作リポジトリでは、プロトタイプを退役させた変更が2026年8月9日にあり、以前のランチャーを現行ゲームから外したことを確認できます。固定したREADMEも、退役したランチャーが現行ゲームには含まれないと説明しています。
ここは「AIで何でも作れた」と機能を列挙するより、一度作ったものを公開版から外す判断を説明できる箇所です。ただし、Gitの変更だけから、作者がその瞬間に感じた迷いや理由までは補いません。判断の理由は、制作文書にある範囲で使います。
270秒の本編へ、例を一つずつ割り当てる
次の時間配分は新しく作った案です。話す速さを測った結果ではありません。本編を270秒とし、画面切り替えや言い直しのために30秒を残します。
| 経過時間 | 配分 | 話すこと | 見せる材料 |
|---|---|---|---|
| 0:00〜0:25 | 25秒 | 題材と、制作で何を決めた話なのか | 完成したゲームの画面 |
| 0:25〜1:10 | 45秒 | 締切と公開先がある制作条件 | Game Jamの期間と提出先 |
| 1:10〜2:25 | 75秒 | 作った案を残す・外す判断 | 旧プロトタイプと現行画面 |
| 2:25〜3:40 | 75秒 | 比較した結果を次の実装へ戻す | 素材候補と採用後のゲーム内表示 |
| 3:40〜4:30 | 50秒 | 次の制作で同じ判断をどこへ置くか | 選択と締切の関係を示す一文 |
| 4:30〜5:00 | 30秒 | 予備 | 追加の新しい話題は入れない |
秒数の合計はコードでも確かめました。これは台本の予算確認であり、読み上げ時間の推定器ではありません。
segments = [25, 45, 75, 75, 50]
buffer = 30
assert sum(segments) == 270
assert sum(segments) + buffer == 300
前半の例と後半の例は役割が違います。プロトタイプの例は、作った案を外して進む方向を絞る判断を示します。素材の例は、残したゲームの中で見え方を確認し、採否を決め直す判断を示します。ツール名の紹介は、その判断を説明するために必要な範囲へ留めます。
技術の詳しさは、補足へ逃がせる形で残す
VOLT NOMADには、日英テキスト、複数入力、素材台帳、ルート検証、提出用の画像や動画まであります。公開ページにも、ゲームの構造と使用したAIの説明があります。これらを本編ですべて説明する必要はありません。
たとえばCodexの役割を、企画から提出まで順に読むと、後に続く素材選定と話が重なります。ここでは、候補を出す、ゲームへ組み込む、違和感を返す、という一つのやり取りに絞る案にします。操作方法や自動テストの実装は補足資料へ回せます。
補足は不要になった資料ではありません。聞き手が「どう再現するか」を知りたくなったとき、リポジトリや記事へたどれるようにする役割があります。本編で省いた理由を、技術的に価値がないからとは扱いません。
実演を加えるなら、その時間を先に確保する必要があります。この案の予備30秒を、未計画の操作デモや追加トピックで使い切る設計にはしていません。
大きい数字を見せる前に、何を数えたかを残す
初稿には53コミット、1,440ルート、92素材候補、18曲という数字がありました。目を引く数字ですが、単位と集計範囲の説明にも時間が必要です。
53コミットは、固定したGit履歴から対象イベントのパスを指定し、日本時間の2026年8月1日から8月12日までで数えると再現しました。ただし、コミット数は制作時間やAIによる時間短縮の測定ではありません。「速くなった」を数値で裏付けるためには使えません。
素材候補数は台帳の集計範囲、曲数は割当枠と異なる実ファイルのどちらを数えるかで説明が変わります。初稿の数字を現在の総数としてそのまま使うより、出典文書や台帳と照合した注記を補足へ残すほうが、この本編の問いには合います。
数字を全部削る必要もありません。採否の違いを説明できる画像があるなら、その一組を見せるだけで話を進められます。今回の構成では、量の大きさを証明する時間を、判断の前後を見せる時間へ移しました。
最後に確かめるのは、実際に話した時間
ここまでで確認できたのは、資料の枚数と内容、制作リポジトリとの対応、配分の合計です。実際の読み上げ、会場の画面切り替え、聴衆の理解は検証していません。
次の確認は、予定した画面を使って通して話し、区間ごとの実時間を取ることです。超えた区間では、早口にする前に、その例が残したい判断へ直接つながっているかを見直します。資料を短くした後は、残した例を5分以内に説明できるか確かめます。