ゲームデザインドキュメント（GDD）の書き方｜AIに渡す仕様書の基本

2026年10月4日

ゲームデザインドキュメント（GDD）は、ゲームの設計を書き残し、チームで同じ物を作るための文書です。日本の現場では「仕様書」と呼ぶことも多く、企画と試作で決めたことを、実装できる細かさまで書き下ろします。この連載の工程の順では、企画と試作の後、スケジュールの前に置いています（全体の流れは「ゲーム開発の全工程マップ」）。

本記事では、GDD の役割と構成、1ページの概要と機能ごとの仕様の分け方、仕様の粒度（数値・条件・例外・失敗したときの動き）、生きた文書として更新し続ける運用を、ジャンプ・ショップ・会話ウィンドウの短い仕様の例を交えてまとめます。AI エージェントで開発する場合は、仕様書がそのまま AI への指示になります。後半では、その書き方と落とし穴を整理します。企画書（1枚企画書）は「ゲーム企画の立て方」、スケジュールは「ゲーム開発のスケジュールとマイルストーン」で扱います。

夕宮たいだ

ふぁ……みんな〜、今日は仕様書の話だよぉ。書くのはめんどくさいけど、AI と一緒に作るなら、すごく効いてくる道具なんだぁ。一緒に見ていこ〜。

GDD とは

ひとことで：ゲームの設計を書き残し、チームの共通理解・判断の記録・実装の指示に使う文書です。

GDD は、開発チームの作業をそろえるための設計文書です。多くの会社で必須とされる一方、業界で決まった形式はありません。また、開発の途中で書き足され続けることから「生きた文書（living document）」とも呼ばれます（Wikipedia: Game design document）。

GDD には、大きく3つの役割があります。

役割	書くこと	主に読む人
共通理解	何を作るか、何を作らないか	チーム全員、外注先、AI エージェント
判断の記録	なぜそう決めたか、捨てた案は何か	未来の自分、あとから入った人
実装の指示	数値・条件・例外・失敗したときの動き	プログラマー、アーティスト、AI エージェント

1人で作る場合も、GDD は要ります。数か月後の自分は、今日の自分が何をなぜ決めたかを覚えていません。AI エージェントも同じで、Claude Code の各セッションは新しいコンテキスト（AI が一度に読める情報の範囲）で始まると、公式ドキュメントに書かれています。

日本では、ゲーム全体のコンセプトを伝えて合意を取るための「企画書」と、実装の判断基準になる細かい「仕様書」に分けて呼ぶこともあります（Wikibooks「仕様書の書き方」）。

呼び方	目的	細かさ	中身の例
企画書	提案・合意	1〜数枚	コンセプト・ターゲット・類似作・規模
仕様書	実装	機能ごとに細かく	画面ごとの操作、敵の動き、ダメージの計算式

本記事では、仕様書と GDD をほぼ同じ意味で使います。

夕宮たいだ

決まった型がない……むずかしいねぇ。でも、型より「読んだ人が同じ物を作れるか」が大事なんだぁ。

GDD の構成

ひとことで：決まった型はないので、代表的な章立てを参考に、1ページの概要と機能ごとの仕様に分けて書きます。

代表的な章立て

Wikipedia の GDD の項目では、典型的な中身として次のような章が挙げられています。個人〜少人数なら、全部を最初に書く必要はありません（右の列は、本記事が勧める書き始めの目安です）。

章	中身	書き始める時期
対象プレイヤー	誰に向けるか	企画書から写す
ゲームのメカニクス	操作・ルール・数値	最初に（コアループの部分から）
UI と操作	画面の一覧・画面の移り変わり・ボタン	最初に（主要な画面から）
物語とキャラクター	あらすじ・人物	物語のあるゲームなら、概要を最初に
レベルと環境	ステージの構成と大きさの基準	ステージの仮組みの前に
アートの方向性	絵柄・色・参考の絵	素材を作り始める前に
サウンドと音楽	曲と効果音の一覧・方向性	素材を作り始める前に
アクセシビリティ	文字の大きさ・色の見分け・操作の変更	方針だけは早めに
開発スケジュール	節目と期間	スケジュールの記事を参照
収益化	売り切り・追加コンテンツなど	方針だけ

段階を追う文書と、1ページの設計図

1999年に Tim Ryan 氏が Gamasutra（現 Game Developer）に書いた解説では、設計文書を「コンセプト文書（1〜2ページ）→ 提案書 → 機能仕様書 → 技術仕様書」と段階を追って細かくしていく形が紹介されています（The Anatomy of a Design Document, Part 1）。一方で、長い設計書は読まれないという問題もあります。Stone Librande 氏は GDC 2010 の講演「One-Page Designs」で、図に注釈を書き込んだ1ページの設計図にまとめる方法を紹介しました（Game Developer）。

個人〜少人数でのおすすめの分け方

この2つを組み合わせて、次のように分けると、読む人も書く人も迷いにくくなります。

ファイル	中身	更新するとき
概要（1ページ）	コンセプト・コアループ・ターゲット・決まっていること・決まっていないこと	大きな方針が変わったとき
機能ごとの仕様（1機能1ページ）	ジャンプ、ショップ、会話ウィンドウなど	その機能を作る前と、変えたとき
数値の表	敵の体力、アイテムの価格など	調整のたび
決定ログ	決めた日・決めたこと・理由・捨てた案	決めるたび

数値は文章の中に散らばらせず、表やデータのファイルにまとめます。調整のたびに文章を書き換えずに済み、ゲームが読み込むデータと仕様書を一致させやすくなります（数値の調整は「ゲームバランス調整の進め方」）。

全部を最初に書く必要はありません。概要を先に書き、機能ごとの仕様は、その機能を作る少し前に書きます。早く書きすぎた仕様は、試作の結果で書き直しになりやすいからです。画面の仕様は、文章だけで書くより、画面の下書き（ワイヤーフレーム）に番号を振り、番号ごとに動きを書くと伝わります。

仕様書の構成。概要（1ページ）の下に機能ごとの仕様（ジャンプ・ショップ・会話ウィンドウ）が並び、決定ログから概要と仕様へ反映し、仕様は数値の表を参照する — 図1：概要は1ページ、仕様は1機能1ページ、数値は表に、決めたことは決定ログへ

仕様の粒度

ひとことで：読んだ人（と AI）が迷わず作れるように、数値・条件・例外・失敗したときの動きまで書きます。

仕様が粗いと、作る人が空白を想像で埋めます。想像が当たれば問題ありませんが、外れると、作り直しや「言った・言わない」になります。1つの機能について、次の4つを書くのが目安です。

書くこと	中身	例（2Dアクションのジャンプ）
数値	大きさ・速さ・回数・時間	最高点の高さは3マス
条件	いつできるか、いつできないか	地面か足場の上に立っているときだけ跳べる
例外	普通と違う扱いをする場面	足場から落ちた直後のわずかな間は跳べる
失敗したときの動き	できなかったときに何が起きるか	空中で押しても何も起きない（二段ジャンプは無い）

曖昧な書き方を、作れる書き方に直すと次のようになります（数値はすべて例です）。

曖昧な書き方	作れる書き方
ジャンプは気持ちよく	最高点は3マス。ボタンを早く離すと低くなる（最低1マス）
お金が足りないときは買えない	所持金が価格より少なければ「買う」を灰色にし、押すと「お金が足りません」と出す
文字はいい感じの速さで出す	1秒に30文字。設定で10〜60文字に変えられる。クリックで全文を出す
敵は賢く動く	プレイヤーが5マス以内に来たら追いかけ、見失って3秒たったら元の位置へ戻る

決まっていない所は、空欄にせず「未決」と書きます。空欄は「書き忘れ」なのか「まだ決めていない」のかが区別できず、作る人が勝手に決めてしまう原因になります。

用語もそろえます。同じ物を「HP」「体力」「ライフ」と書き分けると、読む人は別の物だと受け取ります。画面に出す言葉とプログラムで使う名前の対応を、概要の用語の一覧で決めておきます。

状態が切り替わる機能（会話ウィンドウ、メニュー、敵の行動など）は、状態と、切り替わるきっかけを表にすると抜けが見つかります。

今の状態	起きたこと	次の状態
文字を表示中	クリック	全文を表示
全文を表示	クリック	次の文を表示中
全文を表示	オートモードで2秒たつ	次の文を表示中
どの状態でも	メニューを開く	一時停止（閉じたら元の状態へ）

表にすると、「メニューを開いたら文字の表示はどうなるか」のような、文章では書き漏らしやすい組み合わせが見えてきます。

仕様書の書き方の例

ひとことで：1機能を1ページにし、目的・数値・条件・例外・失敗したとき・確かめ方の順で書きます。

最後の「確かめ方」は、その仕様どおりにできたかを判定する条件です。AI に頼むときの「Done when（完了の条件）」にそのまま使えます。数値はすべて例です。

例1：ジャンプ（2Dアクション）

目的：足場から足場へ渡る。届くか届かないかの判断を楽しむ
数値：ボタンを押し続けると最高点は3マス。早く離すと低くなり、最低1マス。空中の左右の速さは地上の8割
条件：地面か足場の上でだけ跳べる。二段ジャンプは無い
例外：足場の端から落ちた直後の0.1秒は跳べる（落ち始めの猶予で「コヨーテタイム」と呼ばれる）。着地の0.1秒前に押したボタンは、着地と同時に跳ぶ（先行入力）
失敗したとき：空中で押しても何も起きない。天井に頭が当たったら、上昇をやめて落ち始める
確かめ方：3マスの段差には届き、4マスには届かない。足場の端から落ちる途中で押して跳べる

例2：ショップ（RPG・カードゲーム）

目的：手に入れたお金を、次の戦いの準備に使う
数値：価格はアイテムの表の「価格」の列。売ると価格の半分（端数は切り捨て）
条件：所持金が価格以上で、持ち物に空きがあるときだけ買える
例外：同じ物は99個まで。数が限られた品は、買い切ると棚から消える
失敗したとき：お金が足りなければ「お金が足りません」、持ち物がいっぱいなら「持ち物がいっぱいです」と出す。どちらの場合も、所持金と持ち物は変わらない
確かめ方：所持金が価格とちょうど同じなら買える。1足りなければ買えない。買った後にセーブして再開しても、所持金と持ち物が一致している

例3：会話ウィンドウ（ノベル）

目的：文章を読みやすく見せ、読む速さを遊ぶ人が決められるようにする
数値：1行全角28文字×3行。文字は1秒に30文字の速さで出す（設定で変えられる）
条件：クリックしたとき、文字を出している途中なら全文を出し、全文が出ていれば次の文へ進む
例外：名前の欄は、話す人がいる文だけに出す。オートモードでは、全文が出てから2秒後に次へ進む
失敗したとき：3行に収まらない文は、勝手に次のページへ送らず、記録に残してテストで見つけられるようにする
確かめ方：いちばん長い文が3行に収まる。読み返しの画面（バックログ）で、表示した順に読める

会話ウィンドウに入る文字数は、翻訳すると足りなくなることがあります。多言語に対応する予定があれば、文字数の余裕も早めに仕様に書きます（「ゲームのローカライズ（多言語対応）」）。

2D アクションのジャンプの仕様を図にした例。最高点は3マス、早く離すと低い（最低1マス）、落ちた直後0.1秒は跳べる、3マスの段差には届き4マスには届かない、天井に当たると落ち始める — 図2：仕様の例。数値・例外・失敗したときの動きを図に書き込むと、読み違いが減る

生きた文書として更新する

ひとことで：仕様書は一度書いて終わりではなく、決定ログと版管理で「今の正解」を保ち続けます。

仕様書は、開発の間ずっと書き換わります。書き換え方の決まりがないと、古い内容と新しい内容が混ざり、どれが正しいのかわからなくなります。次の4つを決めておきます。

決定ログを付ける：決めた日・決めたこと・理由・決めた人・捨てた案を1行ずつ残します。例：「10月4日　二段ジャンプは入れない。理由：足場の配置を3マス基準で設計するため。捨てた案：アイテムで一時的に解放」
状態の印を付ける：各節に「決定」「検討中」「未決」「廃止」の印を付けます。廃止した内容は消すか、日付と決定ログへのリンクを添えて残します
コードと同じ版管理に入れる：仕様書をゲームのコードと同じ Git などのリポジトリに入れると、「いつ、どの変更と一緒に仕様が変わったか」を後から追えます（版管理は「ゲームエンジンの選び方と開発環境」）
正は1か所にする：チャットや会話で決めたことは、仕様書に書くまで「決まっていない」扱いにします。同じ内容の写しを複数の場所に置かないようにします

節目（試作の終わり、αROM の前など）には、仕様書と実際のゲームを見比べ、ずれている所を直します。

夕宮たいだ

決定ログがあると、「なんでこうしたんだっけ？」にすぐ答えられるんだよぉ。未来の自分が喜ぶよぉ。

AIゲーム開発での仕様書

ひとことで：仕様書がそのまま AI への指示になります。曖昧な所は AI が埋めてしまうので、完了の条件と例外まで書き、仕様と実装のずれを AI に点検させます。

仕様書がそのまま AI への指示になる

AI エージェントは、作業の始めに指示ファイルを読んでから動きます。Claude Code はプロジェクトの CLAUDE.md をすべてのセッションの開始時に読み（公式ドキュメント「Claude があなたのプロジェクトを記憶する方法」）、Codex は AGENTS.md を起動ごとに読み込んで、リポジトリの最上位から作業中のフォルダまでの分を順につなげます（Custom instructions with AGENTS.md）。人が読むための仕様書は、そのまま AI が読む仕様書にもなります。

ただし、指示ファイルに仕様をすべて書くのは逆効果です。Claude Code の公式ドキュメントは、CLAUDE.md は1ファイル200行以下を目標にし、長いほどコンテキストを多く使って、指示が守られにくくなると説明しています。Codex も、AGENTS.md の合計が既定で 32 KiB に達すると、それ以上のファイルを読み込みません（どちらも2026年10月時点）。そこで、次のように分けます。

置き場所	書くこと	例
指示ファイル（CLAUDE.md・AGENTS.md）	毎回守るルールと、仕様書の場所	触ってよいフォルダ、テストの実行方法、報告の型、「仕様は docs/specs/ にある」
機能ごとの仕様書	その機能の目的・数値・条件・例外	ジャンプ、ショップ、会話ウィンドウ
決定ログ	決めたことと理由	二段ジャンプは入れない
依頼文	今回の作業の Goal と Done when	ショップの仕様どおりに「買う」を作る

Claude Code と Codex を両方使うなら、CLAUDE.md の中に @AGENTS.md と書いて読み込むと、指示を1つのファイルにまとめられます（同じ公式ドキュメント）。書き方の詳細は「CLAUDE.md 完全ガイド」「Codex AGENTS.md完全ガイド」で解説しています。

夕宮たいだ

ほえ〜、仕様書がそのまま AI への指示になるんだぁ。書いてない所は、AI が想像で埋めちゃうんだねぇ。

曖昧な所は AI が埋める

AI は、仕様に書かれていない所を「よくある作り」で埋めて、とにかく動く物を作ります。たとえばショップの仕様に「お金が足りないとき」が書かれていなければ、ボタンが消えるのか、押しても何も起きないのか、所持金がマイナスになるのかは、できあがるまでわかりません。動くので気づかず、後で遊んだときに「思っていたのと違う」となります。対策は次の2つです。

仕様に完了の条件（Done when）と例外を書く。AI が自分で動作を確かめる基準になります
決まっていない所は「未決」と書き、「未決の所は作らずに、質問として返す」と指示ファイルに書いておく

また、指示どうしが食い違っていると、Claude はどちらか一方を任意に選ぶことがあると、公式ドキュメントにあります。古い指示や矛盾する指示は、定期的に消します。指示ファイルは強制の設定ではないので、絶対に止めたい操作は、権限の設定などの仕組みで止めます（「Claude Code パーミッションと安全設定ガイド」）。

仕様の作業で AI に任せやすいこと

作業	AI に頼む内容
仕様の下書き	会話やメモから、目的・数値・条件・例外・確かめ方の型に整える
抜けの洗い出し	未決の点、状態の表の抜け、用語の揺れを一覧にする
確かめ方の変換	仕様の「確かめ方」を、自動テストや確認の手順に書き直す
ずれの点検	仕様とコードを突き合わせ、違いを表にする

ずれの点検では、コードと仕様書のどちらも書き換えさせません。仕様が古いのか、実装が間違っているのかを決めるのは人です。

Goal: ショップの仕様と実装のずれを洗い出す
Context: 仕様は docs/specs/shop.md、実装は src/shop/、決定ログは docs/decisions.md
Constraints: コードと仕様書は書き換えない。仕様に無い動きは「仕様に無い」として挙げる
Done when: 「仕様の項目／実装の場所／違い／直す案」の表ができている。
  お金が足りないとき・持ち物がいっぱいのときは、実際に動かして確かめた結果が入っている

依頼文の組み立て方は「Codexプロンプト設計」で解説しています。

人が決める、仕様書、指示ファイル（CLAUDE.md・AGENTS.md）、AI が作る、AI が仕様と実装を突き合わせる、人が裁定、の順に仕様書を中心に一巡する、人と AI の作業の流れ — 図3：決めるのは人、作って照らし合わせるのは AI。仕様書が両方をつなぐ

人が決めること

面白さに関わる判断：ジャンプの高さ、敵の速さ、価格の最終値。AI は候補を出せますが、遊んで決めるのは人です
仕様の優先順位：どの機能が必須で、どれが「あれば良い」か
食い違ったときの正：仕様と実装のどちらに合わせるか

AI に仕様書の書き換えまで任せると、根拠のない「決定」が紛れ込みます。仕様の変更は AI に提案させ、反映は人が決めてから行います。

落とし穴

長すぎる仕様書を毎回読ませる：大事なルールが埋もれ、コンテキストも余計に使います。指示ファイルは短くし、作業する機能の仕様だけを読ませます
古い仕様が残る：廃止した内容が残っていると、AI はそれも正しい指示として読みます。決定ログと「廃止」の印で、今の正解を1つにします
依頼文で仕様を変えて、仕様書に戻さない：依頼文で「やっぱり二段ジャンプも入れて」と頼んだら、その場で仕様書と決定ログにも反映します

夕宮たいだ

ぁぅ……長い仕様書を毎回ぜんぶ読ませると、大事なルールが埋もれちゃうんだよねぇ。入口は短くしておこうねぇ。

筆者の実例

筆者が開発中のRPGの試作では、Codex 向けの AGENTS.md に「触ってよい範囲」「納品前の確認」「報告の型」を書いています。作品の根幹に関わる判断は Codex に決めさせず「要裁定」として報告に残させ、小さな判断は決定ログに書かせます。発注書と組み合わせて、「1件の依頼＝1セッション」で回しています。

麻雀ゲームなどの作品には、新しいセッションの AI が最初に読む「引継ぎ資料」を作品ごとに置いています。中身は、プロジェクトの地図と地雷（どこに何があるかと、過去に踏んだ罠）です。日々の決定は、メモ・計画書・計測の記録の3か所に同期させています。また、AI に発注の仕事を教える手順書は、固定の数値を並べず、ベテランの考え方として書いています。ゲームの仕様には数値を書き、仕事の進め方の文書には考え方を書く、という書き分けです。

よくある失敗と対処

ひとことで：仕様書の失敗は「書きすぎて読まれない」「書かなすぎて伝わらない」「古いまま残る」に分かれます。

失敗	原因	対処
誰も読まない	長い、探せない	1ページの概要と、機能ごとの分割。目次と更新日を付ける
できあがりが想像と違う	数値・例外が書かれていない	数値・条件・例外・失敗したときの動き・確かめ方を書く
「なぜこうしたか」を思い出せない	決めた理由を残していない	決定ログに理由と捨てた案を書く
仕様書と実装が食い違ったまま	仕様を直さずにコードだけ直した	変えるときは仕様書から。節目ごとに照らし合わせる
古い仕様で作り直してしまった	廃止した内容が残っている	「廃止」の印と日付、決定ログへのリンクを付ける
AI が書いていない機能を足した	未決の所を空欄にした	「未決」と書き、作らずに質問するよう指示する
指示ファイルが長くなり、守られない	仕様まで指示ファイルに書いた	指示ファイルは短くし、仕様は別のファイルに分けて必要なときだけ読ませる