監修：藤井厚志（元KONAMI／著書『プロフェッショナルゲームプランナー』）

はじめに

企画書でゴーサインが出た。さあ、次は何をする？
それは、仕様書の作成です。

ゲームプランナーを目指す人が企画書の書き方を学ぶ一方で、意外と見落とされがちなのが「仕様書」の存在です。企画書は「何を・なぜ作るか」を定める羅針盤ですが、仕様書はその先——「どうやって作るか」をデザイナーやプログラマーに伝える、ゲーム開発の設計図です。

GPC監修の藤井先生は著書の中でこう語っています。

監修者・藤井厚志からひとこと

絶対に正しい仕様書は存在しない——今まで何人もの仕様書を見てきましたが、人によって様式が全く異なります。まさに十人十色。いい仕様書も悪い仕様書もあります。だからこそ「誰が読んでも理解できる汎用性の高い仕様書」を目指すことが、プランナーとしての大前提です。

本記事では、藤井先生の著書『プロフェッショナルゲームプランナー』をもとに、ゲーム仕様書の書き方を体系的に解説します。

読み終えるころには、こんなことがわかるはずです。

• 概要仕様書と詳細仕様書の違いと使い分け
• 仕様書は「書く」より「見る」が大切な理由
• 更新履歴の正しい書き方とバグを防ぐポイント
• ゲームサイクル・モチベーションフローの設計方法
• 仕様書のフォーマット統一とレビューの進め方

👉 「ゲーム企画書の書き方」をまだ読んでいない方は、まずゲーム企画書の作り方【プランナー直伝】ペライチから5枚版まで完全解説をお読みください。

---

ゲーム仕様書とは？企画書との違い

仕様書は「開発チームの作業の拠り所」

仕様書とは、ゲームの設計図です。

企画書が「このゲームを作りましょう」とゴーサインをもらうための資料であるのに対し、仕様書は「このゲームをこうやって作ります」とデザイナーやプログラマーに伝えるための資料です。企画書を通した後、プランナーはすぐに仕様書の作成に入ります。

デザイナーは仕様書を見てグラフィックを制作し、プログラマーは仕様書を見てコードを書きます。つまり仕様書は、開発チーム全員が毎日参照する「作業の拠り所」になる資料です。

開発スタッフが仕様書で見ているもの

プランナーが作った仕様書を渡されて、開発スタッフが確認したいのは次の2点です。

• 「自分たちの作業に落とせるか」——タスクに分解できる粒度で書かれているか
• 「判断を丸投げされていないか」——曖昧な部分を自分たちで埋めさせられないか

「なんとなくこういう仕様にした」という企画書と同じ落とし穴が、仕様書にも存在します。「この仕様で迷ったら、ここを見れば判断できる」という設計が、プランナーとしての現場理解を示します。

---

2種類の仕様書を使い分ける

仕様書には大きく分けて2種類あります。概要仕様書と詳細仕様書です。企画書に「ペライチ版」と「5枚版」があるように、仕様書にも「全体像をまとめた概要版」と「細部まで書き込んだ詳細版」があると考えてください。

概要仕様書：「このゲームって何だっけ？」に答える資料

概要仕様書は、ゲームの全体像をコンパクトにまとめた資料です。一度作ったら基本的に更新頻度は低く、大きく仕様が変わるタイミングでのみ更新します。

主な用途は、プロデューサーや上位役職者から「そういえばどんなゲームでしたっけ？」と聞かれたときに短時間で正確に伝えること。詳細仕様書を見せながら説明するわけにはいきませんし、そのたびに説明資料を作っていては時間がいくらあっても足りません。

概要仕様書は次の4要素で構成します（詳しくは後述）。

1. 仕様概要と目的
2. ゲームサイクル
3. 簡易画面フロー
4. モチベーションフロー

詳細仕様書：開発チームが毎日読む「作業の設計図」

詳細仕様書は、いわゆる一般的に「仕様書」と呼ばれるものです。ゲームシステムや細かい仕様を網羅した資料で、デザイナーやプログラマーはこれを見ながら作業します。

開発が終了するまで手を加え続ける、プランナーの相棒というべき資料です。ツールはExcelが最もスタンダードで、ほぼすべてのPCで開けるうえ、外注先とのやりとりにも便利ですが、最近だとConfluenceやNotionも増えてきました。開発規模に応じてファイルを分割するのが基本で、メインゲーム・サブゲーム・課金周りなど、大きなセクション単位でファイルを分けると管理しやすくなります。

監修者・藤井厚志からひとこと

概要仕様書は開発初期だけでなく、開発中ずっと有益な資料として使い続けられます。「そういえばどういうゲームだったっけ？」「どんなシステムなの？」とプロデューサーや役職者が確認してくるのは、開発のどの段階でも起きます。そのたびに詳細仕様書を広げて説明していては、お互いに余計な時間を使ってしまいます。概要仕様書があれば、短時間で正確に伝えることができます。

---

仕様書の書き方の基本——書くより「見る」

まずは「既存ゲームの仕様書化」でトレーニングする

新人プランナーが仕様書のスキルを最も効率よく身につけるには、既存ゲームを仕様書化するトレーニングが最も効果的です。

起こすゲームは社外タイトルでも構いませんが、社内タイトルなら作成後に実際の仕様書と比較できるので、より高い学習効果が得られます。ポイントは、スクリーンショットをそのまま使わないこと。ゼロからワイヤーフレームでゲーム画面を再現することで、情報整理力とUI設計力が鍛えられます。完成したら必ずデザイナーとプログラマーにも見せてフィードバックをもらいましょう。「何が足りないか」「何が不要か」が一目でわかります。

これは実際のゲーム会社でも、新人プランナーの研修カリキュラムとして採用されているトレーニングのひとつです。

「書く」より「見る」に時間をかける

仕様書は書くのが仕事だと思われがちですが、書いた仕様書を「見る（点検する）」ことの方が重要です。

初稿で完璧な仕様書を作り上げることはプロでも不可能です。何度も見直すことで見落としや矛盾が見つかります。コツは「この人が見たらどう感じるか」という目線で読み返すことです。

• デザイナーが見たら：「コストが高すぎないか？」「作るデータ数は現実的か？」
• プログラマーが見たら：「実装可能か？」「仕様に矛盾がないか？」

仕様書が完璧な状態というのは、開発が終了した時点だけです。それまでは常に「更新中」＝「点検中」という意識を持ち続けましょう。

---

更新履歴こそ「仕様書の命」

バグの大半は「仕様変更」から生まれる

仕様書の中で最も重要なシートは、更新履歴です。

ゲーム開発はバグとの戦いですが、バグの発生原因には2パターンあります。「最初から存在していたバグ」と「仕様変更で生まれたバグ」です。圧倒的に多いのは後者です。「いつ・何を・どう変えたから・どうなったか」が更新履歴で追えれば、バグの原因究明が格段に速くなります。更新履歴はバグ対策の最前線です。

また、開発が進むにつれて更新履歴は「作業の索引」としても機能します。デザイナーやプログラマーにとって「自分の次の作業が書かれている場所」になるため、見やすさと引き継ぎのしやすさを常に意識して記載することが重要です。

更新履歴に書くべき5つの項目

更新履歴で押さえるべき項目は次の5つです。

5つの項目を実際に記入するとこのようになります。

— は未実装（対応待ち）を示す

監修者・藤井厚志からひとこと

更新履歴を怠る者はプランナー失格と言っても過言ではありません。バグとの戦いは仕様書の更新履歴から始まります。「どのタイミングで、何をどうしたから、どうなったのか」は更新履歴があれば割り出せます。地味に見えますが、更新履歴を重要視するプランナーは必ず周囲に認められます。

仕様ログも残しておく

更新履歴とは別に、仕様ログも残しておくことをおすすめします。仕様ログとは、「なぜその仕様になったか」という経緯を記録したプランナー自身のための備忘録です。

数ヶ月前に決めた仕様の経緯を忘れることは珍しくありませんし、関係者から「これはなぜこういう仕様なの？」と聞かれたときに即答できることがプランナーの信頼につながります。また、スケジュールやコストの都合で実現しなかった仕様も書き残しておきましょう。後のアップデートや別ゲームで使える可能性があります。

---

概要仕様書の4要素を作る

概要仕様書の核となる4要素について、それぞれ解説します。

① 仕様概要と目的（5W1H）

ゲームの内容と目的をわかりやすく・簡潔にまとめたものです。5W1Hをベースに記載します。

• WHAT：どんなゲームか
• WHO / WHY / WHEN / HOW：誰が・何のために・いつ・どう達成するか
• WHERE：達成目標

企画書で定義した内容が土台になりますが、仕様を固めていくにつれて情報が具体化されます。適宜アップデートして最新の状態を保ちましょう。

② ゲームサイクル

ゲームサイクルとは、プレイヤーが継続して遊び続ける「循環」を可視化したものです。画面単位ではなく「コアな遊び単位」でまとめるのがポイントです。

例えばRPGなら、「街で依頼を受ける→ダンジョンで依頼をこなす→依頼主に報告する」がひとつのサイクルになります。まず小さなサイクルをたくさん作ってから合体させていくのが効率的な作り方です。すべての遊びをひとつのサイクルに収める必要はなく、ゲームサイクル外のコンテンツ（「カジノ」のような寄り道）も許容します。

③ 簡易画面フロー

簡易画面フローとは、細かい分岐を取り除いたミニマムな画面遷移図です。以下の目的を果たします。

• おおよそのゲーム設計が見える
• おおよその画面数がわかり、見積もりの情報源になる
• コストカットの検討ができる
• 詳細仕様書を作る前のヌケモレ防止になる

コストカットを検討する際には「この2つの画面を1つにまとめられないか？」という視点が重要です。ただし、一画面に機能を詰め込みすぎると情報量が増えてユーザビリティが下がるリスクもあるため、必ずプログラマー・デザイナーと一緒に検討します。

④ モチベーションフロー

モチベーションフローとは、プレイヤーが遊び続けられるかを可視化したものです。ゲームサイクルが「ゲームの構造」を定義するのに対し、モチベーションフローは「面白さと継続性」を定義します。

プレイヤーのモチベーションは、プレイ時間とともに変化します。藤井先生はこれを4つのフェーズで捉えています。

• フェーズ①：接待——基本サイクルを覚え始める序盤。短いサイクルで成功体験を与え「遊び続けてもいい」と思わせる
• フェーズ②：自立——余裕が出てきた中盤前半。適度なストレスと報酬でプレイを深め、プレイヤーの自立を促す
• フェーズ③：意志——ほぼすべての機能が解放された中盤〜クリア。マンネリ対策と「自由と強制のバランス」が最大の課題
• フェーズ④：繋がり——エンドコンテンツ。コミュニティ・DLC・やり込み要素でファンとの繋がりを確立する

また、モチベーションの観点として「内側（ゲーム内）の面白さ」が「外側（SNS・攻略サイト・友人との会話）の面白さ」に波及し、また戻ってくる仕組みを設計することで、ゲームの耐久性が大きく高まります。

監修者・藤井厚志からひとこと

モチベーションフローはソーシャルゲームだけのものだと思われがちですが、課金要素がないCSタイトルでも必ず作るべきです。CSタイトルの場合は、ゲームの最初から最後までをまとめた「体験フロー」を作るといいでしょうね。「遊び続けられる仕組みになっているか」「モチベーションが納得感のあるものになっているか」を可視化することで、企画段階では気づかなかった問題点が浮き彫りになります。

---

UIの設計——「ドンブリUI」から始める

概要仕様書の簡易画面フローができたら、次はUI設計に入ります。ここで重要な考え方が「ドンブリUIから始める」というアプローチです。

UIを設計する前に、まずゲームで取り扱うデータや情報をすべて洗い出す「情報整理」を行います。「情報の洗い出し→分類・グループ化→階層化→関連付け→優先度決め」の5段階で整理することで、何をどの画面に置くべきかが見えてきます。

情報整理が終わったら、いきなり完成版のUIを目指さないことが重要です。藤井先生が提唱するのは、まず「ドンブリUI」を作ること。丼ぶりにおかずをどかどか乗せる要領で、配置やサイズは無視して「必要な情報・要素を全部乗せる」ことだけを目指します。

「具材を揃えてから整える」という順番を守ることで、後から要素の取り忘れが発覚するリスクを防げます。要素を後から減らすことはできても、足すことは簡単ではないからです。ドンブリUIで全要素が揃ったら、次に配置・サイズ・導線を整えた「ベントーUI」（弁当容器のように整然と区分けされた完成版UI）を目指します。

---

仕様書のフォーマットを統一する

人によって書き方がバラバラなのが仕様書の現実ですが、共通フォーマットを作ることでプランナー間のブレを最小化できます。フォーマットが揃っていると読み手のストレスが減り、余計な疑問や懸念が生まれにくくなります。

フォーマットを作る際には、次の6つの観点を意識しましょう。

監修者・藤井厚志からひとこと

仕様書のフォーマットを統一することで、プランナーが変わっても同じ品質の仕様書が作れるようになります。フォーマットは一度作ったら終わりではなく、チームで運用しながら改善していくものです。いろんなスタッフに意見やアドバイスを聞いてブラッシュアップしていきます。新しいプランナーが入ってきたときに「このフォーマットに従えばOK」と言える状態を目指しましょう。

---

仕様レビューを徹底する

どれだけ優秀なプランナーでも、自分の仕様書のヌケモレを100%自力で発見することはできません。だからこそ、プランナー同士での仕様レビュー会を定期的に開くことが重要です。

プランナーは「自分の仕様には甘く、他人の仕様には厳しい」という特性があります。これを逆に利用しましょう。異なるタイプのプランナーをレビューに参加させることで、同調ムードを防ぎ、アイデアの過不足・他ゲームとの比較・実装の現実性について鋭い指摘が得られます。

可能であれば、まったく別のチームやプロジェクトのプランナー・ディレクターにレビューしてもらうことも効果的です。自分たちでは持てない俯瞰的な視点が得られますし、自分たちが試みようとしていることが他のチームで既に経験済みなら、直接有益な情報を聞けます。厳しい意見がグサっとくることもありますが、それはすべて仕様の穴を塞ぐチャンスです。臆せずどんどん情報を開示して、より良い仕様書を目指しましょう。

監修者・藤井厚志からひとこと

プランナー同士のレビュー会は、仕様書の品質を上げるだけでなく、チームの結束力を高める効果もあります。「あっちはあっち、こっちはこっち」というムードが生まれると、お互いの仕様への興味が薄れてしまいます。仕様レビューを通じて「チーム全員でこのゲームを作っている」という意識を育てていきましょう。

---

よくある質問（FAQ）

Q1. 仕様書はどのツールで作ればいいですか？

現状はExcelが最もスタンダードです。ほぼすべてのPCにインストールされており、外注先とのやりとりにも便利です。シート管理のしやすさや、セルの自由度の高さもプランナーの作業スタイルに合っています。

Q2. 新人プランナーは仕様書の練習をどうすればいいですか？

既存ゲームを仕様書化するトレーニングが最も効果的です。スクリーンショットを使わず、ゼロからワイヤーフレームで画面を再現することがポイントです。完成したらデザイナーとプログラマーに見せてフィードバックをもらうことで、自分の仕様書の足りない部分が明確になります。

Q3. 企画書と仕様書、どちらを先に作りますか？

基本的には企画書を通した後に仕様書を作ります。ただし概要仕様書は企画書と並行して作り始めることもあります。企画書で「何を・なぜ作るか」を固め、仕様書で「どうやって作るか」を詰めるのが正しい順序です。

Q4. 仕様書はどのくらいのボリュームになりますか？

ゲームの規模によって大きく異なります。小規模なカジュアルゲームであれば数シートで収まることもありますが、大規模タイトルでは複数のExcelファイルに分けて管理するほどの量になることもあります。Excelのシートタブが一画面に収まる程度の情報量を1ファイルの目安にすると、情報の確認モレ防止にもなります。

---

まとめ：仕様書は「書き続ける」ではなく「見続ける」もの

本記事の要点を3つにまとめます。

1. 概要仕様書と詳細仕様書を使い分ける。概要仕様書はゲームの全体像を伝える羅針盤、詳細仕様書は開発チームが毎日使う作業の設計図。役割を理解して使い分けることがプランナーの基本
2. 更新履歴こそ仕様書の命。バグの大半は仕様変更から生まれる。5つの項目を漏れなく記載し、チーム全員が安心して作業できる仕様書を維持する
3. 「書く」より「見る」を大切に。点検の習慣がゲーム開発の精度を上げる。ドンブリUIで全要素を揃え、フォーマットを統一し、仲間とのレビューを繰り返すことで仕様書の品質は着実に上がる

仕様書の書き方を学ぶには、まず企画書でゲーム設計の骨格を作れるようになることが近道です。まだ企画書に自信がない方は、こちらの記事もあわせてご覧ください。

👉 ゲーム企画書の作り方【プランナー直伝】ペライチから5枚版まで完全解説

---