AIゲーム開発用語集｜αROM・βROM・マスターアップほか88語

2026年10月4日

ゲーム開発の現場では、「αROM」「バーティカルスライス」「マスターアップ」のような工程の言葉が飛び交います。同じ言葉でも会社や資料で意味が違うことが多く、知らずに話すと、何がどこまでできていればよいかが食い違います。

本記事は、連載「インディーゲーム開発の全工程」で使う言葉を、工程の順に集めた用語集です。各語に「ひとことで」の意味と短い説明、詳しい記事へのリンクを付けました。工程の流れの中での位置は、「ゲーム開発の全工程マップ」で確かめてください。

定義は一般に多い使い方とこの連載での使い方を示し、会社や資料で基準が違う言葉はそう書いています。Steam の規則と数値は、2026年10月4日に公式ドキュメントで確認したものです。

夕宮たいだ

ふぁ……みんな〜、今日はゲーム開発の用語集だよぉ。工程の順に並べてあるから、知らない言葉が出てきたら、ここで引いてねぇ。

ゲーム開発の主な用語を、企画から発売と運用までの6つの段階の順に並べた地図。Steam の用語の帯と、全体を横切る AI の用語の層つき — 図1：用語を工程の順に並べると、どの段階の言葉かがわかる

企画の用語

ひとことで：何を作るかを決め、作れる規模と道具をそろえる段階の言葉です。

コンセプト（Concept）：そのゲームの面白さを一言で表したものです。

「誰が・何をして・どう楽しいか」を1〜2文で言えるようにします。迷ったときの判断の基準になります。→ 企画の立て方

コアループ（Core Loop）：プレイヤーが何度も繰り返す、遊びの中心となる行動の輪です。

例：ローグライクなら「探索→戦闘→強化→また探索」。この輪が楽しくないと、素材や量を増やしても面白さは増えません。→ 企画の立て方

USP（ユーエスピー・Unique Selling Proposition）：他の作品にない、そのゲームならではの売りです。

似た作品と並んだときに選ばれる理由です。ストアページやトレーラーで最初に伝える点にもなります。→ 企画の立て方

スコープ（Scope）：作る範囲と量のことです。

ステージ数・キャラ数・機能の数などで表します。人数と期間で作りきれる大きさかを、企画の段階で見積もります。→ 企画の立て方

企画書（きかくしょ・Game Proposal）：ゲームの狙いと中身を伝え、合意を取るための資料です。

日本では、提案・合意用の「企画書」と、実装用の「仕様書」を分けて呼ぶことがあります。個人でも1枚にまとめると、判断がぶれにくくなります。→ 企画の立て方

プロトタイプ（Prototype）：遊びが成立するか（作るべきか）を確かめる、使い捨ての試作です。

確かめる問いを1つに絞り、見た目は作り込みません。カードゲームなら紙で作ることもあります。→ プロトタイプとは

GDD（ジーディーディー・Game Design Document）：ゲームの設計をまとめた文書（ゲームデザインドキュメント）です。

決まった型はなく、仕組み・ステージ・操作・絵や音の方向などを書き、開発中も更新し続けます。図に注釈を入れた1ページの設計図にまとめる方法もあります。→ GDDの書き方

仕様書（しようしょ・Specification）：実装の判断基準になる、細かく決めた設計図です。

画面の動き・数値・条件・例外（〜のときはどうなるか）まで書きます。作る人が迷わず、確かめる人が合否を判断できる細かさが目安です。→ GDDの書き方

マイルストーン（Milestone）：開発の途中に置く「ここまでできたら次へ進む」到達点です。

プロトタイプ・バーティカルスライス・αROM・βROM・マスターアップなどがあります。中身の基準は、会社やパブリッシャーとの契約で違います。→ スケジュールとマイルストーン

スコープクリープ（Scope Creep）：作る範囲が、計画の外でじわじわ広がっていくことです。

「ついでにこれも」の積み重ねで締め切りに間に合わなくなります。何かを足すときは、何かを削るか締め切りを動かします。→ スケジュールとマイルストーン

バッファ（Buffer）：遅れや予定外の作業に備えて、スケジュールに確保しておく予備の時間です。

見積もりは外れるものとして、最初から計画に組み込みます。外注の納品や審査のように、自分では縮められない待ち時間にも確保します。→ スケジュールとマイルストーン

ゲームエンジン（Game Engine）：描画・音・入力・物理など、ゲームに共通する仕組みをまとめた土台のソフトです。

Unity・Unreal Engine・Godot・RPGツクールなどがあります。費用や利用条件は、エンジンごとに違います。→ エンジンと開発環境

バージョン管理（バージョンかんり・Version Control）：ファイルの変更履歴を記録し、前の状態に戻せるようにする仕組みです。

Git・SVN・Perforce P4（旧 Helix Core）などがあります。大きな画像や音を Git で扱うときは、Git LFS を併用します。→ エンジンと開発環境

ブランチ（Branch）：同じプロジェクトから枝分かれさせた、別の作業の流れです。

本流を壊さずに新機能や修正を試し、終わったら合流させます。Steam にも、配る版を切り替えるブランチの仕組みがあります。→ エンジンと開発環境

ビルド（Build）：ソースや素材から作った、実行できるゲームのファイル一式です。

「ビルドを作る」と動詞でも使います。αROM・βROM も、提出・確認用のビルドのことです。→ エンジンと開発環境

パブリッシャー（Publisher）：ゲームの販売や宣伝などを担う会社です。

資金・宣伝・翻訳・移植などを支えてくれます。その代わりに、売上の分け方などの条件を契約で決めます。→ 資金とパブリッシャー

セルフパブリッシング（Self-publishing）：パブリッシャーを通さず、開発者が自分で販売・宣伝することです。

決定権を自分で持てる一方、ストアの手続き・宣伝・サポートもすべて自分で行います。筆者の麻雀ゲームも、サークル名義のセルフパブリッシングです。→ 資金とパブリッシャー

プリプロダクションの用語

ひとことで：この品質で作れるかを確かめ、制作の基準を決める段階の言葉です。

プリプロダクション（Pre-production）：作るべきか・作れるかを、企画と試作で確かめる段階です。

一般には企画と試作もここに含みます。この連載では、ステージの仮組とバーティカルスライスをこの段階の記事として扱います。→ 全工程マップ

グレーボクシング（Greyboxing）：単純な形でステージを仮組みし、遊びと大きさを先に確かめる工程です。

ブロックアウト（Blockout）、グレーボックスとも呼びます。色も質感もない箱や坂で組み、遊んで直してから見た目を作ります。→ グレーボクシングとは

ホワイトボックス（White Box）：グレーボクシングと同じ意味で使う現場もある言葉です。

QA の「ホワイトボックステスト」（中の仕組みを知ったうえで行うテスト）とは別物です。どちらの意味かは文脈で見分けます。→ グレーボクシングとは

メトリクス（Metrics）：キャラの大きさ・移動やジャンプの性能と、それに合わせた通路・扉・段差の寸法ルールです。

例：2Dアクションでジャンプの高さを3マスと決め、段差は余裕をもって2マスまでにする。数値はゲームごとに決めます。→ グレーボクシングとは

アートパス（Art Pass）：仮組みしたステージや画面に、本番の見た目を付けていく工程です。

遊びと寸法を固めてから行うので、見た目の作り直しが減ります。メトリクスを守ったまま、仮の形を本番の素材に置き換えていきます。→ グレーボクシングとは

ファーストプレイアブル（First Playable）：主要な遊びが初めて通しで動く版です。

会社によってはアルファと同じ意味で使います。プリプロダクションの試作を元に作ることが多い版です。→ バーティカルスライスとは

バーティカルスライス（Vertical Slice）：ゲームの一部分を製品版に近い品質まで作り、この品質で作れることを示す版です。

例：1ステージ、ノベルゲームなら1章ぶん。品質の基準を決め、制作の流れの詰まりを見つけ、残りの量の見積もりに使います。→ バーティカルスライスとは

ホリゾンタルスライス（Horizontal Slice）：この連載では、ゲーム全体を荒く通した版を指します。

全体がおおまかに遊べる状態で、つながりや順序、おおよそのプレイ時間をつかむために作ります。「技術の層ごとに分けて作る進め方」という逆向きの意味で使う資料もあるので、使うときは定義を添えます。→ バーティカルスライスとは

MVP（エムブイピー・Minimum Viable Product）：学ぶための最小の製品です。

リーン・スタートアップで知られる Eric Ries 氏は「最小の労力で、顧客について検証された学びを最大限集められる製品」と定義しています。「最小限の完成品」という意味ではありません。→ バーティカルスライスとは

夕宮たいだ

ホリゾンタルスライスって、逆向きの意味が2つあるんだぁ……むずかしいねぇ。使うときは「どっちの意味か」をひとこと添えようねぇ。

プロダクションの用語

ひとことで：決めた基準で素材と機能を量産し、遊んで直す段階の言葉です。

プロダクション（Production）：本制作（量産）の段階です。

バーティカルスライスで決めた基準に沿って、素材とプログラムの大部分を作ります。この連載では、素材と音の制作から αROM、プレイテスト・バランス調整・ローカライズまでを含めます。→ 全工程マップ

アセット（Asset）：絵・3Dモデル・アニメーション・UI・音など、ゲームに入る素材のことです。

種類ごとにサイズ・形式・名前の規則を決めて作ります。名前の付け方は「アセット命名・バージョン規則」も参考になります。→ アセット制作の流れ

アセットリスト（Asset List）：作る素材の一覧表です。

名前・仕様・担当・状態（仮・制作中・検収済みなど）を並べ、何がどこまでできたかを管理します。音は場面ごとのサウンドリストにまとめます。→ アセット制作の流れ、BGM・効果音の作り方

仮素材（かりそざい・Placeholder）：本番の素材ができるまで代わりに置く、仮の素材です。

プレースホルダーとも呼びます。大きさや形式を本番と同じにしておくと差し替えが楽です。出荷前に残っていないかを必ず確かめます。→ アセット制作の流れ

スタイルガイド（Style Guide）：絵柄・色・線・文字など、見た目の決まりをまとめた資料です。

見本の絵と、やってはいけない例を並べると伝わりやすくなります。人や AI が作る素材のばらつきを抑え、検収の基準にもなります。→ アセット制作の流れ

検収（けんしゅう・Acceptance Inspection）：納品された素材や成果物が、発注どおりかを確かめて受け取ることです。

サイズ・形式・名前などの決まりと、見た目の品質を確かめます。合格しなければリテイクを出します。→ アセット制作の流れ

リテイク（Retake）：納品物の直しを依頼することです。

どこを・なぜ・どう直すかを具体的に書きます。変えてはいけない部分も明記すると、別の所が変わる事故を防げます。→ アセット制作の流れ

αROM（アルファロム・英語では Alpha）：α版の段階で提出・確認用に作るビルドを、日本の現場で呼ぶ言い方です。

α版は、主な機能がそろい、最初から最後まで通して遊べる段階を指すことが多く、基準は会社や契約で違います。「ROM」はカートリッジの名残です。→ αROMとは

フィーチャーフリーズ（Feature Freeze）：新しい機能の追加を止める取り決めです。

α を区切りに置くことが多くあります。その後は、バグ修正と使い勝手の改善を中心にします。→ αROMとは

プレイテスト（Playtest）：他の人に遊んでもらい、意図どおりに遊ばれているかを観察して直す工程です。

説明せずに見るのが基本です。不具合を探す QA とは目的が違います。→ プレイテストのやり方

バランス調整（バランスちょうせい・Balancing）：難しさ・経済・テンポ・確率などの数値を直す工程です。

数値を表で管理し、1度に1つずつ変えます。プレイテストとデータの両方で確かめるのが基本です。→ バランス調整の進め方

ローカライズ（Localization）：ゲームを他の言語・地域向けに作り変える工程です。

翻訳だけでなく、文字数に合わせた画面の調整や、ストアページの翻訳も含みます。下準備の「国際化」を早めに済ませておくと楽になります。→ ローカライズ

国際化（こくさいか・Internationalization）：あとから翻訳しやすいように、ゲームの作りを整えておくことです。

文章をプログラムの外に出す、各言語のフォントを用意する、伸びる文字数や画像の中の文字に備える、などです。i と n の間が18文字なので i18n とも書きます。→ ローカライズ

LQA（エルキューエー・Linguistic / Localization Quality Assurance）：翻訳した文章を、ゲームの画面の中で確かめる工程です。

その言語の話者が、誤訳・不自然な言い回し・文字のはみ出しなどを実際の文脈で確かめます。訳文だけを読む校正とは別に行います。→ ローカライズ

仕上げの用語

ひとことで：機能と素材を固め、不具合を潰して提出する段階の言葉です。

ポストプロダクション（Post-production）：この連載では、βROM〜マスターアップの、発売前の仕上げの段階を指します。

資料によっては発売後の運営や振り返り、アルファから発売までを指すこともあり、意味が割れています。迷ったら「仕上げ」と言い換えます。→ 全工程マップ

βROM（ベータロム・英語では Beta）：β版の段階で提出・確認用に作るビルドを、日本の現場で呼ぶ言い方です。

β版は、機能と素材がそろい、不具合の修正と調整が中心になる段階を指すことが多く、基準は会社や契約で違います。オンラインゲームの「βテスト」とは別の意味です。→ βROMとは

コンテンツロック（Content Lock）：素材や文言など、中身の追加・差し替えを止める取り決めです。

コンテンツフリーズとも呼び、止めた後は多くの場合、不具合の修正と調整だけを行います。翻訳に出す文言を先に確定させる「テキストロック」を置くこともあります。→ βROMとは

コードフリーズ（Code Freeze）：プログラムの変更を止める取り決めです。

「一切変えない」と「バグ修正だけは許す」の幅がある言葉です。何を許すかを、チームで決めておきます。→ βROMとは

最適化（さいてきか・Optimization）：動作を軽くし、目標のフレームレートや読み込み時間に収める作業です。

感覚ではなく、計測して重い所を見つけてから直します。目標の数値（例：60fps）と、確かめる機種を先に決めておきます。→ βROMとは、リアルタイム最適化チェックリスト

動作環境（どうさかんきょう・System Requirements）：ゲームが遊べるパソコンの条件（OS・CPU・メモリ・GPU など）です。

Steam ではストアページに、OS ごとのシステム要件として載せます。ビルドの審査では、載せたすべての OS で起動するかが確かめられます。→ βROMとは

QA（キューエー・Quality Assurance）：品質保証。テストの計画を立てて不具合を探し、報告し、直ったことを確かめる工程です。

テスト計画とチェックリストに沿って、決めた範囲を漏れなく確かめます。面白さを確かめるプレイテストとは目的が違います。→ デバッグとQA

デバッグ（Debugging）：不具合（バグ）の原因を突き止めて直す作業です。

直したら、再現手順で直ったことを確かめます。日本のゲーム業界では、不具合を探すテスト作業そのものを「デバッグ」と呼ぶこともあります。→ デバッグとQA

バグ票（バグひょう・Bug Report）：見つけた不具合を1件ずつ記録する報告書です。

要約・再現手順・期待した結果と実際の結果・重さ・環境・画像や動画を書きます。バグ管理ツールで、未対応から確認済みまでの状態を追います。→ デバッグとQA

再現手順（さいげんてじゅん・Steps to Reproduce）：不具合を起こせる操作の順番です。

誰がやっても同じ結果になる粒度で書きます。再現できない不具合は、直ったかどうかも確かめられません。→ デバッグとQA

回帰テスト（かいきテスト・Regression Test）：修正や変更のあとで、前は動いていた所が壊れていないかを確かめるテストです。

リグレッションテストとも呼びます。自動テストにしておくと、変更のたびに素早く確かめられます。→ デバッグとQA

自動テスト（じどうテスト・Automated Test）：プログラムでゲームを動かし、結果が期待どおりかを自動で確かめる仕組みです。

ルール・計算・セーブなどの確認に向き、面白さや見た目の確認には向きません。筆者の麻雀ゲームでは、提出時の自動テストが約3.2万件ありました。→ デバッグとQA

リリース候補（リリースこうほ・Release Candidate）：重大な不具合が出なければ、そのまま製品になる版です。

RC と略します。最終確認で問題がなければ、マスター（ゴールド）として確定させます。→ マスターアップとは

マスターアップ（英語では Gold Master）：製品版として確定し、量産や配信に回せる状態にすることです。

狭い意味ではゲームが完成した瞬間を、広い意味ではそこを目指す最後の作業全体を指します。基準は会社や契約で違います。→ マスターアップとは

ゴールド（Gold）：英語圏で、製品版の最終ビルドが確定し、量産に回せる状態になることです。

「ゴールドになる（going gold）」と言い、そのビルドをゴールドマスターと呼びます。日本のマスターアップに近い言葉です。→ マスターアップとは

ロットチェック（Lot Check）：任天堂のゲーム機で出すゲームを、任天堂が確かめる検査工程です。

全モデル・全バージョンで正しく動くか、任天堂のガイドラインに合っているかを確かめます。細かい要件は、開発者向けの非公開資料にあります。→ マスターアップとは

TRC（ティーアールシー・Technical Requirements Checklist）：ソニーのゲーム機で発売する前に満たす、技術要件のチェックリストを指す呼び名です。

開発現場では、機種を問わず認証要件の総称のように使われることもあります。要件の中身は開発者向けの非公開資料にあります。→ マスターアップとは

XR（エックスアール・Xbox Requirements）：Xbox のゲームが守るべき、ポリシーと技術の要件です。

マイクロソフトが公開しています。「提出時に機能が完成し、テストできること」などの項目が並び、認証では印の付いた項目が試験されます。→ マスターアップとは

夕宮たいだ

ほよ？日本だと、バグを探すテストのことも「デバッグ」って呼ぶんだぁ。頼むときは「探す」のか「直す」のか、書いておくと安心だねぇ。

発売準備の用語

ひとことで：開発と並行して進める、遊んでほしい人に届けるための準備の言葉です。

体験版（たいけんばん・Demo）：ゲームの一部を無料で遊べるようにした版です。

デモとも呼びます。Steam では本編とは別のアプリとして作り、本編のストアページにダウンロードのボタンを出せます。→ 体験版の作り方

プレスキット（Press Kit）：報道や配信者が記事・動画を作るときに使う、ゲームの資料一式です。

概要・特徴・スクリーンショット・ロゴ・トレーラー・問い合わせ先などを集めます。1つのページやフォルダにまとめ、自由に使ってよい範囲も書いておきます。→ 宣伝とウィッシュリスト

レーティング（年齢区分・Age Rating）：ゲームの内容に応じて対象年齢を示す区分です。

日本の家庭用ゲーム機では CERO（セロ）の区分（A・B・C・D・Z）が使われ、ダウンロード専用のソフトは条件つきで国際的な仕組みの IARC でも出せます。Steam では CERO は求められず、内容の申告からいくつかの地域の区分が自動で付きます（ドイツでは区分のないゲームが表示されません）。→ 権利と規約

発売と運用の用語

ひとことで：発売してから遊ばれ続けるまでの言葉です。

デイワンパッチ（Day One Patch）：発売日に配信する更新です。

パッケージ版は製造のために早めに完成版を固めるので、その後に直した分を発売日に配ります。製造の待ちがないダウンロード専売では、事情が少し違います。→ マスターアップとは

ホットフィックス（Hotfix）：通常の更新の予定の外で、急いで出す修正です。

多くは重い不具合への対応です。元は、稼働中のサーバーに当てる修正を指す言葉でした。→ 発売後の運用

パッチノート（Patch Notes）：更新で何が変わったかを、プレイヤーに知らせる文書です。

直した不具合・調整した数値・追加した内容を、遊ぶ人に分かる言葉で書きます。大きな変更には理由を添えると、受け入れられやすくなります。→ 発売後の運用

DLC（ディーエルシー・Downloadable Content）：発売後に追加で配る、ダウンロード式の追加コンテンツです。

有料・無料の両方があります。新しいステージ・キャラ・衣装などを、本編とは別に配る形で足します。→ 発売後の運用

ポストモーテム（Postmortem）：開発が一区切りしたあとに、うまくいったこと・いかなかったことを振り返ることです。

ゲーム業界では主に、開発の振り返りの記事や講演を指します。IT の運用では、障害の振り返りを指します。→ 発売後の運用

移植（いしょく・Porting）：作ったゲームを、別の機種で動くように作り変えることです。

入力・画面・性能・認証・年齢区分が機種ごとに違います。同じゲームを複数の機種で出すことは「マルチプラットフォーム」と呼びます。→ 移植とマルチプラットフォーム

Steam の用語

ひとことで：Steam で売るときに必ず出てくる仕組みの言葉です（2026年10月時点の公式ドキュメントによる）。

Steam Direct（スチームダイレクト）：Steam に作品を登録する仕組みと、その手数料です。

1本ごとに $100 で、返金はされませんが、その作品の売上が $1,000 以上になった後の支払いで回収されます。支払いから発売までは最低21日です（2026年9月に公式ドキュメントが30日から書き換わった。紹介ページは30日のまま）。→ ストアページの作り方

ストアページ（Store Page）：Steam で作品を紹介・販売するページです。

カプセル画像・トレーラー・スクリーンショット・説明文・タグ・対応言語・システム要件などを載せます。審査（通常3〜5営業日）を通ると公開できます。→ ストアページの作り方

近日登場（Coming Soon）：発売前のストアページが公開されている状態です。

ここからウィッシュリストに入れてもらえます。新しい作品は、発売前に最低2週間この状態で公開しておく必要があります。→ ストアページの作り方

カプセル画像（Capsule）：一覧や特集に表示される、作品の顔になる画像です。

ヘッダー（920×430px）・小（462×174px）・メイン（1232×706px）・縦長（748×896px）などがあり、2024年8月より前の古いサイズは受け付けられません。入れてよい文字は、ゲーム名と公式のサブタイトルだけです（期間限定の差し替えを除く）。→ ストアページの作り方

ウィッシュリスト（Wishlist）：気になる作品を登録しておく、Steam の「欲しいものリスト」です。

登録した人には、発売時と、条件を満たす20%以上の割引時に通知が届きます。Valve は、表示されるための最低件数はないと説明しています。→ 宣伝とウィッシュリスト

Steam Next Fest（スチームネクストフェス）：Steam が年3回（2月・6月・10月）開く、未発売の作品の体験版を集めた1週間の催しです。

1作品1回だけ参加できます。本編のストアページの公開と、誰でも遊べる体験版が条件です。→ 体験版の作り方

Steam Playtest（スチームプレイテスト）：本編とは別の枠で、テスト版を無料で配れる Steam の機能です。

独自のストアページはなく、本編のページに参加の申し込み欄が出ます。お金は取れず、秘密保持の契約もないので、機密のテストには向きません。→ プレイテストのやり方

早期アクセス（そうきアクセス・Early Access）：開発途中のゲームを販売し、プレイヤーの声を聞きながら完成させる出し方です。

遊べる状態であることが前提で、将来について具体的な約束をしないことが求められます。一度早期アクセスで出すと、近日登場には戻せません。→ 発売の手順

ローンチ割引（Launch Discount）：発売と同時に始める割引です。

期間は7〜14日、割引率は10〜40%で、発売前にしか設定できません。発売から30日間は、これ以外の割引はできません。→ 発売の手順

キュレーター（Curator）：Steam でおすすめのゲームを紹介する個人や団体です。

Curator Connect という機能で、キーを使わずに作品を直接送れます（100キュレーターまで・1キュレーターにつき最大5本）。近日登場ページの公開と、遊べるビルドのアップロードが条件です。→ 宣伝とウィッシュリスト

夕宮たいだ

ぁぅ……カプセル画像は、2024年8月より前のサイズだと受け付けてもらえないんだよぉ。古い記事の数字を写すときは、気をつけてねぇ。

AIゲーム開発の用語

ひとことで：AIエージェントでゲームを作るときの言葉です。AI に任せやすいのは作業の量、人が決めるのは基準と採否と公開です。

AIエージェントを使うと、試作・実装・テスト・下書きの量を大きく増やせます。その分、どの案を採るか、仕様どおりか、権利と開示は大丈夫かを決めて確かめる人の仕事が重くなります。

生成AI（せいせいエーアイ・Generative AI）：文章・画像・音楽・プログラムなどを、指示に応じて新しく作り出す AI です。

商用で使えるかはサービスとプランの規約で違います。ゲームに入る絵・音・文章を作った場合は、Steam で開示が必要です。→ 権利と規約

AIエージェント（AI Agent）：目標を伝えると、ファイルの読み書きやコマンドの実行を重ねて作業を進める AI です。

1回の質問に答えるチャットと違い、複数の手順を自分で進めます。結果を確かめて採用を決めるのは人です。→ Claude Codeとは？

Claude Code（クロードコード）：Anthropic の AI エージェントです。

プロジェクトのファイルを読み書きしながら作業を進めます。筆者の開発では、設計・実装・テスト・検収・文書を受け持っています。→ Claude Codeとは？

Codex（コーデックス）：OpenAI の開発用 AI エージェントです。

コードベースを読んで、実装・調査・レビューなどを進めます。筆者の開発では、画像の初稿・翻訳の校正・試し遊びを受け持っています。→ Codex入門

プロンプト（Prompt）：AI への指示文です。

目的（Goal）・材料（Context）・守ること（Constraints）・完了の条件（Done when）を書くと、結果がぶれにくく、確かめやすくなります。調べるだけの依頼なら、たとえば次のように書きます。→ Claude Code プロンプト設計、Codexプロンプト設計

Goal: ノベルゲームの第1章で、英語が未翻訳の行を一覧にする
Context: 日本語は data/text/ja/、英語は data/text/en/ にある
Constraints: 文章のファイルは書き換えない
Done when: 未翻訳の行の場所と件数を表にして報告している

指示書ファイル（CLAUDE.md・AGENTS.md）：AIエージェントが作業のたびに読む、プロジェクトの決まりを書いたファイルです。

Claude Code は CLAUDE.md を、Codex は AGENTS.md を読みます（AGENTS.md は他の多くのツールも読む共通の形式です）。筆者は、触ってよい範囲・納品前の確認・報告書の型を書き、作品の根幹に関わる判断は人に戻すと決めています。→ CLAUDE.md 完全ガイド、Codex AGENTS.md完全ガイド

コンテキスト（Context）：AI が判断に使う情報（会話・読んだファイル・指示）のことです。

一度に扱える量には上限（コンテキストウィンドウ）があり、長い作業では前の指示を取りこぼすことがあります。決まりは指示書ファイルに書き、作業は区切って頼みます。→ Claude Code 用語集

サブエージェント（Subagent）：メインの AI から呼び出され、別の文脈で一部の作業を受け持つ AI です。

調査や下書きを並行して進めるのに向きます。筆者は、立ち絵の発注書を複数のサブエージェントに並行して書かせ、検収はメインの Claude が画像を直接見て行っています。→ Claude Code サブエージェント・並列作業ガイド

バイブコーディング（Vibe Coding）：コードの中身をほとんど見ずに、ことばの指示だけで AI にプログラムを作らせる作り方です。

2025年2月に Andrej Karpathy 氏が使い始めた言葉で、英国の Collins 辞典は2025年の「今年の言葉」に選びました。試作には向きますが、売る製品では、テスト・コードの確認・権利の確認を人が担います。→ プロトタイプとは

ハルシネーション（Hallucination）：AI が、事実と違う内容をもっともらしく出力することです。

存在しない設定項目や、古い・間違った規則の説明が混ざることがあります。筆者は、AI の試し遊びで出た指摘も、別の AI にコードで裏取りさせてから直しています。→ プレイテストのやり方

AI生成コンテンツの開示（AI Content Disclosure）：ゲームに生成AI で作った内容が含まれることを、ストアなどで申告することです。

Steam では Content Survey（内容の申告）の生成AI の欄で申告し、ストアページに表示されます。対象はプレイヤーが触れる絵・音・文章・翻訳などで、コード補完のような作業効率化の利用は対象外です。筆者の麻雀ゲームは、初回の審査で開示が薄いと差し戻され、素材の種類ごとに書き直して通過しました。→ 権利と規約

夕宮たいだ

AI が言った規則を、裏取りしないでそのまま信じるのは絶対ダメだよ！公式の資料と、実際の動きで確かめてねぇ。

よくある失敗と対処：取り違えやすい言葉

ひとことで：同じ言葉が別の意味で使われる組み合わせを先に知っておくと、話の食い違いを防げます。

言葉	取り違えやすい点	対処
ポストプロダクション	発売前の仕上げ／発売後の運営／振り返り／アルファ〜発売、の4通り	この連載では「仕上げ」。話すときは意味を言い添える
ホリゾンタルスライス	全体を荒く通した版／技術の層ごとに作る進め方	この連載では前者。使うときは定義を添える
ホワイトボックス	ステージの仮組／QA のホワイトボックステスト	仮組なら「グレーボックス」と言う
αROM・βROM	「αROM＝全機能、βROM＝全素材」は業界の決まりではない	到達条件を会社・契約ごとに文章で決める
β版とβテスト	開発の段階／一般の人に遊んでもらうテスト	段階なら「βROM」、テストなら「βテスト」と分ける
プロトタイプとバーティカルスライス	「作るべきか」と「作れるか」	試作は捨てる前提、スライスは品質の基準
体験版・Steam Playtest・早期アクセス	無料で遊べる一部／無料のテスト（お金は取れない）／開発途中のまま出す本編（お金を取れる）	宣伝・テスト・販売のどれが目的かで選ぶ
デバッグ	原因を直す作業／不具合を探すテスト作業	依頼では「探す」か「直す」かを書く