GDD（企画書）の書き方：Living Documentで進化する設計書の実践

皆さんこんにちは、ゲームディレクターのためのナレッジポッドキャストへようこそ。今日は「GDD、ゲームデザインドキュメントの書き方」についてお話しします。

実はそれ、多くの開発者が陥る罠なんです。2026年現在、100ページのWordファイルを最初に書いて放置するという古いアプローチは、完全に時代遅れになっています。

現代のGDDは「Living Document」、つまり「生きた文書」として、プロトタイプやプレイテストと並走しながら進化し続けるものなんです。今日はその実践的な手法を詳しくお伝えします。

いい質問ですね。実はここがポイントなんですが、一人開発でも3ヶ月後の自分は「別人」なんです。頭の中の曖昧なアイデアを言語化することで、自分自身が何を作ろうとしているかが明確になります。

まさにそうです。GDDには3つの核心的な価値があります。1つ目は「ビジョンの明文化」。2つ目は「意思決定の基準点」。開発中に「これは本当に必要か？」と問う際の拠り所になります。

3つ目は「コミュニケーション基盤」です。チーム開発では、デザイナー、プログラマー、アーティストが同じビジョンを共有するための唯一の信頼できる情報源になります。パブリッシャーへの提案時にも不可欠ですね。

では具体的な書き方をお伝えしましょう。最も重要な原則は「Start Small, Evolve Always」、最小で始めて常に進化させるということです。

まずは「High Concept」から。これは30分で書ける1ページの文書です。エレベーターピッチ、コアループ図、ターゲットオーディエンス、そして競合との差別化ポイントだけを書きます。

例えばBraidなら「時間を巻き戻せる2Dパズルプラットフォーマー」。これだけでゲームの本質が伝わりますよね。High Conceptが固まったら、次は「One-Pager」に進化させます。

主要機能を3から6個、ビジュアル参考画像を1枚、そしてプラットフォームと規模感を追加します。これで2時間くらいの作業です。その後、プロトタイプを作ってから「Core GDD」に進化させる流れになります。

そこが重要なポイントです。開発前に50ページのGDDを書いても、プロトタイプで全てが変わって誰も更新しなくなる。これを「100ページの墓場」というアンチパターンとして覚えておいてください。

実はここが大きな分かれ目なんです。WordやPDFは月次更新が限界で、検索性も低く、共同編集にも向きません。一方、NotionやConfluenceのようなWiki形式なら、デイリー更新も可能です。

一人開発なら、ObsidianかNotionがおすすめです。Obsidianはオフライン動作で軽量、無料で、Gitで履歴管理もできます。Notionはテンプレートが豊富でビジュアル編集にも強いですね。

2人から10人の小規模チームならNotion TeamかConfluenceがおすすめです。コメント機能や権限管理が重要になってきますからね。大規模スタジオになるとSharePointや社内カスタムWikiという選択肢もあります。

鉄則は「1トピック＝1ページ」です。巨大な「God Document」を作るのではなく、戦闘システムは戦闘システムのページ、レベルカーブはレベルカーブのページ、と分けてください。小さなページは更新しやすく、探しやすく、陳腐化しにくいんです。

ここで重要な概念をお伝えします。GDDとTDD、Technical Design Documentは分離すべきです。

GDDは「何を作るか」「なぜ作るか」を定義します。プレイヤー体験やメカニクスの仕様ですね。一方TDDは「どう実装するか」を定義します。アーキテクチャやパフォーマンス目標といった技術的な内容です。

その通りです。面白い例があって、Hollow KnightのGDDには「ナイトの動きは重厚感と正確性の両立がテーマ」と書かれています。一方TDDには「ジャンプ力は7.5N、空中移動は地上の60%速度」と具体的な数値が書かれている。

両者が相互参照しながらも、役割は明確に分離されている。これが更新頻度の違いや読者の違いに対応できる秘訣なんです。

そこで「Pitch Deck」の出番です。10分から15分でプレゼンして、次のミーティングに繋げるための資料ですね。構成は15から20スライドが最適です。

最初のスライドは最もインパクトのあるビジュアルとキャッチコピー。そして超重要なのが、2分以内の実機プレイ映像です。これがないと通らないと思ってください。

コアメカニクスの図解、競合との差別化、ターゲットオーディエンス、そして「Comparable Games」が重要です。「Dead Cellsのローグライト進行とHollow Knightの手描きアート」のような位置づけですね。

あと忘れてはいけないのが「The Ask」、つまり要求を明確にすること。「50万ドルの出資で18ヶ月後にSteam早期アクセス開始」のように、具体的な数字と時期を示しましょう。

いくつか紹介しましょう。まずStray。猫が主人公のアドベンチャーゲームですが、2人の小規模チームでした。彼らはGoogle Docsで1ページ企画書から始めて、Trelloで機能ごとにカード管理しました。

少人数チームでは「会話が文書より大事」なんです。最小限のGDDと頻繁なコミュニケーションで十分。結果、7年かけてMetacritic83点の作品になりました。

面白いことに、彼らはNotionで「カード一覧データベース」を構築したんです。各カードが1ページで、コスト、効果、バランス履歴を全て記録。フィルタ機能で「コスト2以下のアタックカード」をすぐ抽出できる。

結果として300枚以上のカードを追加・調整しながら、Steam98%肯定的レビューを達成しています。履歴記録が後のバランス調整判断に役立ったそうです。

Baldur's Gate 3を見てみましょう。約400人のチーム、3年のEarly Access期間です。彼らはConfluenceベースのカスタムWikiを構築して、なんと7000ページ超のドキュメントを管理しました。

「GDD Owner制度」を導入しています。Combat担当、Narrative担当、UI担当と、各セクションに責任者を配置して全体整合性を管理する。これがガバナンスの鍵なんです。

さらに面白いのは、翻訳チーム向けに「文脈説明GDD」を別途作成していたこと。「この台詞はジョークか、シリアスか」といった情報を付けることで、翻訳品質を上げています。結果はGame of the Year受賞、Metacritic96点。

ここからは避けるべきアンチパターンを5つお伝えします。これを知っておくだけで、多くの失敗を防げます。

その通り。2つ目は「所有者不在の文書」。GDDが共有ドライブに放置されて、誰が更新すべきか不明。矛盾した情報が混在して、誰も信頼しなくなるパターンです。

3つ目は「コピペテンプレート」。業界標準テンプレートをそのまま使って、自分のゲームに不要なセクション、例えばシングルプレイヤーゲームなのに「マルチプレイヤー仕様」が空欄で残っているケース。

「専門用語の密林」です。GDDが専門用語だらけで、新メンバーやアーティストが理解できない。「MDAフレームワークに基づくエマージェントナラティブ」とか書かれても困りますよね。

「機能肥大化聖書」です。「将来的には実装したい」アイデアを追加し続けて、実装可能範囲を超えてしまう。対策は、Core GDDとWishlistを分離すること。本当に必要なものだけCoreに入れましょう。

さて、今日のポイントをまとめましょう。GDDは「生きた文書」として進化させること。最初は1ページのHigh Conceptから始めて、プロトタイプと並走しながら成長させてください。

その通りです。そしてGDDとTDDは分離すること、セクションごとにオーナーを決めること。Slay the SpireやBaldur's Gate 3の事例が示すように、適切なGDD管理は大きな成功につながります。

それでは、また次回のエピソードでお会いしましょう。さようなら。