仕様書作成が劇的に変わる!ゲームプランナーが実践する生成AI(ChatGPT/Claude等)フル活用フロー
こんにちは。ゲームプランナーとして、スマートフォンゲームやオンラインゲーム、ソーシャルゲームの開発・運営に長く携わってきました。
ゲームプランナーの仕事というと、「企画を考える人」というイメージを持たれることが多いかもしれません。しかし実際の現場では、企画を形にするための仕様書作成、画面遷移の整理、報酬設計、マスターデータ作成、デバッグ観点の洗い出し、エンジニアやデザイナーへの制作指示など、かなり幅広い業務があります。
その中でも、特に時間がかかるのが「仕様書作成」です。
仕様書は、ただ機能の説明を書けばよいものではありません。ユーザーがどの画面から入り、どのボタンを押し、どんな条件で成功し、どんな条件でエラーになるのか。報酬はどこに送られるのか。通信エラー時はどうするのか。デバッグ時に何を確認すればよいのか。
こうした細かい観点を抜け漏れなく整理しないと、実装後に認識違いや手戻りが発生します。
そこで近年、私が実務で積極的に取り入れているのが、ChatGPTやClaudeなどの生成AIです。今回は、ゲームプランナーの視点から「仕様書作成に生成AIをどう活用しているのか」を、実際の流れに沿って紹介します。
目次
生成AIを仕様書作成に使おうと思った理由
仕様書作成で大変なのは、文章を書くことそのものよりも、「考えるべき観点を漏らさないこと」です。
たとえば、ログインボーナス機能を作る場合でも、単純に「ログインしたら報酬を受け取れる」と書くだけでは足りません。
通常ログインボーナスとプレミアムログインボーナスがある場合、それぞれの受け取り条件はどうするのか。未受け取り分は翌日に持ち越すのか。報酬は直接付与なのか、プレゼントボックス送付なのか。通信エラーやメンテナンス中の挙動はどうするのか。長期間ログインしなかったユーザーにはどう見せるのか。
このように、一つの機能でも検討すべきことは多岐にわたります。
以前は、過去の仕様書や既存タイトルの事例を見ながら、自分で観点を洗い出していました。もちろんこのやり方は今でも重要です。ただ、最初のたたき台を作るまでに時間がかかり、抜け漏れの確認にもかなり労力が必要でした。
そこで、生成AIを「仕様書を書いてくれるツール」としてではなく、「観点を広げる壁打ち相手」として使い始めました。
ここが重要です。AIに丸投げするのではなく、自分が持っているゲーム開発の経験や、プロジェクト固有の前提条件をAIに渡し、たたき台・観点整理・例外条件の洗い出しを補助してもらうイメージです。
実際に使っている仕様書作成フロー
私が実務で使っている流れは、大きく分けると以下のようになります。
1. まず機能の目的を整理する
最初に行うのは、「その機能が何のために存在するのか」を整理することです。
たとえば交換所機能であれば、単にアイテムを交換する場所ではなく、イベント参加の動機付けや、余ったアイテムの消費先、継続プレイの報酬導線として設計することがあります。
この目的が曖昧なままAIに聞いてしまうと、一般的で無難な仕様しか返ってきません。AIから良い回答を得るためには、こちら側の前提入力がかなり大事です。
私は最初に、以下のような情報を整理してからAIに渡します。
- 対象機能
- 想定ユーザー行動
- 画面遷移
- 付与・消費するアイテム
- 成功条件
- 失敗条件
- 運営上の意図
- 参考にしたい既存タイトルの方向性
- チーム内で決まっている制約
この段階では、完璧な文章にする必要はありません。箇条書きでよいので、まずはAIに渡せる材料を揃えます。
2. AIに仕様書の構成案を出してもらう
次に、AIに「この機能の仕様書に必要な見出しを作ってください」と依頼します。
たとえば、以下のような構成案を出してもらいます。
- 機能概要
- 目的
- 対象画面
- 遷移元・遷移先
- 表示条件
- 操作仕様
- 報酬・アイテム仕様
- エラー仕様
- 例外条件
- デバッグ観点
- 未決事項
ここで便利なのは、自分が最初に想定していなかった見出しが出てくることです。
もちろん、AIが出した構成がそのまま正解とは限りません。ゲームの仕様書には、プロジェクトごとの書き方や、エンジニアが知りたい粒度、デザイナーが必要とする情報があります。そのため、AIの構成案をベースにしながら、自分の現場に合う形へ調整します。
3. 正常系・異常系・例外条件を洗い出す
生成AIが特に役立つのは、正常系だけでなく、異常系や例外条件を広げたいときです。
仕様書を書いていると、どうしても「ユーザーが想定どおりに操作する前提」で考えがちです。しかし実際には、通信エラー、所持上限、期間外アクセス、アイテム不足、連打、日付切り替わり、メンテナンス突入など、さまざまな例外が発生します。
そこでAIには、次のように依頼します。
「この仕様で発生しそうなエラー条件・例外条件・ユーザーの誤操作を洗い出してください」
すると、自分では後回しにしていた観点が出てくることがあります。特に、ログインボーナス、交換所、ショップ、ミッションパス、プロフィール、フォロー・いいね機能など、状態管理が絡む機能では有効です。
ただし、AIが出してきた内容をそのまま採用するわけではありません。実装コスト、運営方針、UIの見せ方、ユーザー体験を考えたうえで、必要なものだけを仕様に落とし込みます。
4. デバッグ観点まで同時に作る
仕様書作成とデバッグ観点作成は、分けて考えられがちです。しかし私は、仕様書を作る段階でデバッグ観点も同時に洗い出すようにしています。
たとえば、交換所機能であれば、
- 必要アイテムを所持している場合に交換できるか
- 必要アイテムが不足している場合に交換できないか
- 交換上限に達した場合の表示が正しいか
- 期間外の商品が交換できないか
- 報酬が正しい送付先に送られるか
- 通信エラー時に不整合が起きないか
といった確認項目が必要になります。
AIに「この仕様をもとにテスト観点を作ってください」と依頼すると、仕様書とテスト項目のつながりを作りやすくなります。
これはかなり大きなメリットです。仕様書だけを作って終わりにすると、後からデバッグチームやQA担当が確認すべき項目を作る際に、仕様の意図を読み解く必要があります。最初からデバッグ観点まで整理しておくことで、チーム全体の認識合わせがしやすくなります。
5. 最後は必ず人間がレビューする
生成AIは便利ですが、最終判断を任せるものではありません。
AIは一般的な仕様やパターンを出すのは得意です。一方で、そのゲームがどんな体験を目指しているのか、IPの世界観に合っているのか、運営上その導線が本当に必要なのか、といった判断は人間が行う必要があります。
特にゲーム開発では、「仕様として正しい」だけでは足りません。
ユーザーが気持ちよく遊べるか。
報酬を受け取ったときに嬉しいか。
操作が直感的か。
運営施策として継続率や課金導線にどう影響するか。
チームが実装しやすい粒度になっているか。
こうした観点は、ゲームプランナーが責任を持って見るべき部分です。
AIはあくまで補助ツールです。仕様書の完成度を上げるための相棒ではありますが、責任者ではありません。
生成AIを使うときに注意していること
実際に使ってみて感じた注意点もあります。
一つ目は、AIの回答はそれらしく見えても、前提がずれていることがある点です。
たとえば、一般的なスマホゲームでは自然な仕様でも、開発中のタイトルでは実装方針やUI設計と合わない場合があります。そのため、AIの回答を「正解」として扱うのではなく、「検討材料」として扱うことが大事です。
二つ目は、プロンプトが曖昧だと回答も曖昧になる点です。
「ログインボーナスの仕様書を作ってください」だけでは、どのゲームにも当てはまる一般論になりやすいです。より実務で使える形にするには、「30日付与型」「プレミアム枠あり」「未受け取り分の扱い」「報酬送付先」「エラー条件」など、具体的な条件を入れる必要があります。
三つ目は、機密情報の扱いです。
開発中タイトルの具体的な名称、未公開情報、契約上外部に出せない情報は、そのまま入力しないように注意しています。AIを使う場合でも、社内ルールやプロジェクトの情報管理方針に従うことが前提です。
使ってみて感じたメリット
生成AIを仕様書作成に取り入れて感じた一番のメリットは、作業時間の短縮だけではありません。
むしろ大きいのは、考えるべき観点を早い段階で広げられることです。
一人で仕様を考えていると、自分の経験に基づいた観点には強くなりますが、逆に慣れているからこそ見落とす部分もあります。AIに一度投げることで、別の角度から確認できるため、初期段階で抜け漏れに気づきやすくなります。
また、仕様書のたたき台が早くできることで、エンジニアやデザイナーとの相談も前倒しできます。
「まだ何も書けていないので相談できない」という状態ではなく、「仮でここまで整理したので、この部分の実装可否を見たいです」と話せるようになります。これはチーム開発において大きな違いです。
仕様書作成は、プランナーだけで完結する仕事ではありません。エンジニア、デザイナー、QA、PM、運営担当など、さまざまなメンバーと認識を揃えるための土台です。
その土台作りを早く、広く、わかりやすくするために、生成AIはかなり有効だと感じています。
まとめ
今回は、ゲームプランナーが仕様書作成に生成AIを活用する流れについて紹介しました。
ChatGPTやClaudeなどの生成AIを使うことで、仕様書の構成作成、例外条件の洗い出し、デバッグ観点の整理、文章の整形といった作業はかなり効率化できます。
ただし、AIに任せれば良い仕様書が完成するわけではありません。
ゲームの面白さ、ユーザー体験、運営意図、実装現場との整合性を判断するのは、あくまで人間の仕事です。特にゲームプランナーは、AIが出した答えを鵜呑みにするのではなく、「この仕様は本当にユーザーにとって良いのか」「チームが迷わず作れる内容になっているか」を見極める必要があります。
私にとって生成AIは、作業を肩代わりしてくれる存在というより、思考の抜け漏れを減らし、仕様書の完成度を高めるための壁打ち相手です。
これからゲーム開発の現場では、AIを使えるかどうかだけでなく、AIの出力をどう判断し、どう現場の成果物に落とし込むかが重要になっていくと思います。
仕様書作成に時間がかかっている方、レビューで抜け漏れを指摘されることが多い方、AIを使ってみたいけれど実務への取り入れ方に迷っている方は、まずは「仕様書の見出し作成」と「例外条件の洗い出し」から試してみるのがおすすめです。
AIに任せるのではなく、AIを使いこなす。
その意識を持つことで、ゲームプランナーの仕事はもっと速く、もっと精度高く進められるようになると感じています。



















