Claudeでゲームデザインドキュメントの仕様矛盾を洗い出す手順 — 数式と用語の食い違い

ゲームデザインドキュメント(GDD)は、システムごとに書き手が変わります。戦闘は戦闘担当、経済はバランス担当、クエストはシナリオ担当。それぞれの文書は筋が通っていても、並べると食い違います。戦闘仕様のダメージ式と、スキル仕様に載っている式が別物だった。ショップでは「ゴールド」、クエスト報酬では「コイン」と書かれている。実装の段階で気づくと、手戻りが大きい種類の不具合です。

この記事では、システム別に分かれたGDDをClaudeのProjectsに置き、用語・数式・数値の食い違いを場所つきの一覧にさせる手順をまとめます。Claudeに任せるのは、食い違いの候補を漏れなく拾うところまでです。どちらを正にするかは、プランナーが決めます。

GDDの矛盾は5つの型で起きる

「矛盾を探して」とだけ頼むと、言い回しの揺ればかりが返り、直すべき食い違いが埋もれます。探す型を先に決めておくと、指摘の質がそろいます。

最初の3つは文書の突き合わせで拾えます。4つ目と5つ目は、全システムの文書が同じProjectに入っていて初めて見える型です。文書を1本ずつ別のチャットで点検していては、拾えません。

手順1: GDDを読める形でProjectに置く

Claudeに渡す前の準備で、結果の大半が決まります。

• システム別に1ファイルへ分ける: 戦闘、スキル、経済、アイテム、クエストなど、担当が分かれている単位で置きます。巨大な1本にまとめるより、指摘に「どの文書の何節か」が付きます
• ファイル名で中身と版を示す: 02_combat_v0.8.md のように、系統番号・システム名・版を入れます。ファイル名が分かりやすいほど、検索で正しい文書を引き当てやすくなります
• 改定前の版を混ぜない: 新旧が並ぶと、すでに直した箇所の矛盾が報告されます。旧版は別フォルダに置くか、入れません
• 数値表はCSVで別に置く: 経験値テーブルや装備性能表は、本文に埋めずCSVにします。数式は文章でなく表の列として読ませられます

Projectに置けるファイルの扱いにも制約があります。

XLSXは、アカウントで「コード実行とファイル作成」を有効にしている場合に限りアップロードできます。無効なら、CSVに書き出します。

GDDで見落としやすいのが、画像の扱いです。フローチャートや画面遷移図は、画像のまま貼ってあるとテキスト抽出では読まれません。状態遷移を図だけで持っているなら、遷移の一覧(状態A → 条件 → 状態B)を文章か表で起こしておきます。

NotionやConfluenceで管理している場合は、Markdown、HTML、PDFなどに書き出してから入れます。書き出し時に表が崩れていないかは、点検の前に目で見ておくと、あとの指摘を信頼しやすくなります。

手順2: プロジェクト指示に点検のルールを書く

Projectsは、独自のチャット履歴とナレッジを持つ作業スペースです。サイドバーの「Projects」から「+ New Project」を選んで作ります。名前と説明はClaudeには渡らないので、点検のルールは「Set project instructions」に書きます。

次の文面は、書き方の一例です。自分のGDDの構成に合わせて置き換えてください。

あなたはゲーム仕様書の整合性を点検する担当です。
ナレッジの仕様書とCSVだけを根拠にします。
- 食い違いは、必ず両方のファイル名と節(または表の行)を示す
- 引用は原文のまま。要約で言い換えない
- 種別を「用語」「数式」「数値」「単位」「参照」に分類する
- どちらが正しいかは判断しない。論点だけ挙げる
- 数値を計算した場合は、計算過程を示す
- 仕様書に書かれていないことは「記載なし」と書き、推測で補わない

最後の2行が効きます。Claudeは矛盾を見つけると、「おそらく後から書かれた戦闘仕様が正しい」のように、原因まで書きたがります。GDDには更新日や決裁の経緯が載っていないことが多く、原因は材料から決まりません。指示で止めておきます。

プロジェクト内でも、チャットどうしの文脈は共有されません。「ゴールドを正式名称にする」といった決定は、ナレッジに文書として足す必要があります。これは手順4で扱います。

手順3: 用語、数式、数値表の順に突き合わせる

全部を一度に頼むと、粗い指摘で終わります。突き合わせの単位を、用語 → 数式 → 数値の順に分けます。

用語と通貨名を先に確定する

全仕様書から、通貨・資源・ステータスを指す語を拾い、「語」「出てくるファイルと節」「定義の有無」の表にしてください。同じ対象に別の語を使っている疑いがあるものと、同じ語が別の対象を指している疑いがあるものは、表の末尾に分けてまとめてください。

この表が、後続の土台になります。語の対応を人が確定してから進むと、数式や数値の指摘が減ります。ゴールドとコインが別の通貨なのか同じものなのかは、仕様書の文面から決まりません。企画の意図を知っている人が答える部分です。

ダメージ式を横並びにする

戦闘仕様とスキル仕様、アイテム仕様に出てくるダメージ計算式を全部拾い、記載箇所と式の原文を並べてください。式の構造が違う組を挙げ、攻撃力50・防御力20・倍率1.5の場合の計算結果をそれぞれ示してください。計算過程も書いてください。

出力の形は、次のようなものを狙います。以下は形式を示す架空の例です。中身は、自分のGDDから出てきたものに置き換わります。

同じ入力値で比べさせるのがコツです。式の文面を見比べるより、計算結果が違うことのほうが、食い違いを説明しやすくなります。

ただし、数値の計算はClaudeが誤りやすい作業です。示された結果を鵜呑みにせず、スプレッドシートや手元のスクリプトで再計算して確かめます。式の確認を繰り返す運用なら、式をコードに起こして単体テストにする手もあります。こうしたゲーム開発側の作業は、Claude CodeでUnityゲーム開発を進める手順が参考になります。

数値表と本文の上限値を照らす

経験値テーブル(CSV)の最終行のレベルと、各仕様書に書かれたレベル上限を照合してください。食い違う箇所は、ファイルと行、または節を示してください。

レベル上限、所持数の上限、スタック数、ステータスの最大値など、上限値は文書ごとに複製されがちです。上限値を拾わせる依頼は、定型として使い回せます。

単位と参照先を最後に確かめる

時間を表す数値(クールタイム、持続、待機)の単位が、秒・フレーム・ターンのどれかを文書別に一覧にしてください。単位が書かれていない数値は、別枠にまとめてください。

各仕様書が「〜仕様を参照」と書いている箇所を全部拾い、参照先の文書と節が実在するか、ナレッジ内で照合してください。

単位が書かれていない数値は、矛盾というより「確認が要る箇所」です。拾わせておくと、未定義の部分が一覧になります。

手順4: 指摘を仕分け、決定事項をナレッジに戻す

指摘の一覧は、そのまま使わずに仕分けます。

決定事項の文書は、たとえば 00_decisions.md のように先頭に並ぶ名前にします。点検のたびに「決定事項と矛盾する記述を優先して挙げる」と頼めば、決まったはずの内容に戻った仕様書を拾えます。チャットを新しく開いても、プロジェクトのナレッジは引き継がれるので、同じ指摘は繰り返されません。

文書が増えたときの漏れ方と区切り方

有料プラン(Pro、Max、Team、Enterprise)では、ナレッジがコンテキストの上限に近づくと、RAGモードが自動で有効になります。プロジェクトの容量は最大10倍まで広がり、画面には有効を示す表示が出ます。

RAGは、プロジェクトのナレッジ検索ツールで関連しそうな部分を取り出して答える仕組みです。全文を一度に読み込む方式とは違うので、GDDの点検では扱いに差が出ます。

• 「全システムのすべての数式を漏れなく」と頼むと、検索で取り出された範囲の話になります。システム単位や節単位に区切るほうが、漏れを確かめやすくなります
• 文書名を指定して頼むと、探す範囲が絞れます。「02_combatと03_skillを比べて」の形です
• 関連する文書は、同じProjectにまとめておきます。そろっているほど、文書間のつながりを見てもらえます

どの方式で動いているかは、画面の表示でわかります。RAGが有効になったら、最後に「検索で拾えなかった可能性がある箇所」を自己申告させる一文を加えておくと、確認の目安になります。ただし、この申告も完全ではありません。重要な数式は、人が原文で見比べます。

共有と運用の注意

TeamまたはEnterpriseプランでは、Projectを開発チームで共有できます。「Can view」は閲覧とチャット、「Can edit」はプロジェクト指示とナレッジの変更もできます。決定事項の文書を触る担当を絞るなら、編集権限はプランナー側の管理者にとどめる運用が考えられます。

Freeプランで作れるProjectは5つまでです。GDDを1作品1Projectで持つなら、複数タイトルを並行で扱う場合は上限に注意が要ります。

未発表タイトルの仕様書を外部サービスに預けてよいかは、社内の情報管理規程と、利用しているプランのデータ設定で判断します。社名やコードネームを伏せた形で試す方法もありますが、仕様の中身を伏せられるわけではないため、扱いは所属先の決まりに従ってください。

関連する運用は、規程どうしの食い違いを洗う等級基準と賃金規程の矛盾を洗い出す手順や、Projectsの全体像を扱うClaude Projects完全ガイドにまとまっています。非エンジニアが試作を作る場面なら、Claude Artifactsでのゲーム制作も参照できます。

まとめ

GDDの矛盾は、用語・数式・数値・単位・参照先の5型に分けて探すと、拾い漏れが減ります。Claudeが得意なのは、場所と原文つきで候補を並べるところまでです。数式の結果は再計算し、どれを正にするかはプランナーが決め、その決定を 00_decisions.md のような文書でナレッジに戻す。この循環が回ると、次の点検の起点は「前回の決定事項」になり、仕様のぶれが溜まりにくくなります。