完成したゲームの仕様をAIに逆算させて、元の企画と比べる

ずれを4種類に分けておく

比べる前に、「ずれ」を分類する枠を決めておきます。枠がないと、差異を見つけるたびに感想で終わってしまうからです。次の4種類で記録します。

• 欠落、状態：企画にあるが、AIの仕様書にない、考えられる原因：未実装、またはコードからは読み取れない内容（演出の狙いなど）
• 追加、状態：AIの仕様書にあるが、企画にない、考えられる原因：実装中に入った挙動、意図しない副作用、バグ
• 値のずれ、状態：両方にあるが、数値や条件が違う、考えられる原因：修正の取りこぼし、企画メモの更新漏れ
• 推測、状態：AIが根拠なく補ったように見える、考えられる原因：コードに該当箇所がない、読み手の思い込み

4つ目の「推測」は、AI側の問題として別に扱います。仕様書の各項目に「どのコードのどの部分が根拠か」を必ず書かせ、根拠が示せない項目を推測として拾います。この区別を入れないと、AIの作り話を「実装の隠れた挙動」と誤読してしまいます。

準備するもの

用意するものは次のとおりです。

• 元の企画メモ：番号付きの箇条書きで、できれば10〜20項目。「ミスは3回で終了」「制限時間は1皿ごと」のように、確認できる形で書かれたものを使います。完成後に書き直した企画メモは、実装を見たうえでの後付けになるため、使わないほうが安全です。
• 完成したゲームのコード：単独のHTMLファイルが扱いやすいです。複数ファイルに分かれている場合は、まず1ファイルにまとめられないか考えます。
• AIとの新しい会話：企画メモを一度も見せていない状態で始めます。会話を使い回すと、前の回の内容が混ざります。
• 記録用の表：後述の列を持つ表計算でもメモでも構いません。

コードの長さにも注意します。長すぎると、AIが途中を読み飛ばしたり要約したりします。数百行を超えるなら、「入力処理」「得点・終了判定」「画面表示」のように役割ごとに分けて渡し、仕様書も分けて作らせます。

手順：企画を固定し、コードだけ渡す

1. 企画メモを固定する

企画メモの項目に番号を振り、実験が終わるまで書き換えません。比べている最中に「実はこういう意図でした」と修正が入ると、ずれが見えなくなります。

2. 数値の一覧を先に作っておく

AIの出力と突き合わせるため、コードに書かれている数値の定義を手元で一覧にしておきます。単独のHTMLをブラウザで開き、開発者ツールのコンソールで次のコードを実行します。

// スクリプト内の「const/let/var 名前 = 数値」の行を拾う
const text = [...document.scripts].map(s => s.textContent).join("\n");
const rows = text.split("\n")
  .map((line, i) => ({ no: i + 1, line: line.trim() }))
  .filter(r => /(const|let|var)\s+[A-Za-z_]\w*\s*=\s*-?\d/.test(r.line));
console.table(rows);

外部ファイルとして読み込んでいるスクリプトや、オブジェクトの中に入れた数値は拾えません。あくまで「数値の定義らしい行」の目安です。この一覧と企画メモを先に見比べておくと、AIの出力を評価するときの基準点になります。

3. コードだけを渡して、仕様書を書かせる

新しい会話で、コード全体を貼り付け、たとえば次のように依頼します。

以下はブラウザゲームのコードです。このコードだけを根拠に、ゲームの仕様書を書いてください。項目ごとに、根拠になった関数名または変数名を併記してください。コードから読み取れないことは「不明」と書き、推測で補わないでください。作り手の意図や狙いは書かず、実際の挙動だけを書いてください。

ポイントは3つあります。根拠の併記を求めること、「不明」と書かせること、意図ではなく挙動を書かせることです。この3つがないと、AIは読み手の好意で整った仕様書を作ってしまい、ずれが見えにくくなります。

4. 同じ条件で3回繰り返す

回ごとに新しい会話を開き、同じ指示で3回作らせます。1回だけでは、AIの揺らぎとコードの曖昧さを区別できないためです。コメントの影響を見たい場合は、コメントを残した版と削除した版の2種類を用意し、それぞれ3回ずつ回します。コメントが企画の言葉をそのまま含んでいると、AIがコードではなくコメントを要約してしまうからです。

5. アソバースの下書き機能を併用する場合

アソバースに作品を投稿する予定があるなら、投稿画面の「紹介文と遊び方を作成」も、第三者の読み取りとして使えます。公開済みURLまたは本人の検証済みアップロードを読み取り、選択した言語で下書きを作る機能です。「この文章を使う」を押さない限り反映されず、生成しただけで公開されることもありません。ただし利用は1時間に3回までです。実験のために回数を使い切らないよう注意し、あくまで補助的な比較材料として扱います。出てくるのは紹介文と遊び方の下書きであり、仕様書ではないという点も押さえておきます。

記録の取り方と結果の読み方

記録する項目

記録は項目単位で、1項目1行にします。列は次のとおりです。

• 企画番号、内容：企画メモの番号。AI側だけにある項目は「新規」
• 企画の記述、内容：元の文面をそのまま写す
• AI仕様の記述（1〜3回目）、内容：回ごとに別の列に入れる
• 根拠、内容：AIが示した関数名・変数名、実際の行番号
• 判定、内容：一致／欠落／追加／値のずれ／推測
• 確認方法、内容：コードを読んだ、実際に遊んだ、など

「AIがこう言った」だけで判定を確定させないことが大切です。判定の列を埋める前に、根拠として挙げられた箇所を実際にコードで開き、実際にゲームを動かして挙動を確かめます。

読み方の基準

3回の出力と企画メモを並べたときの読み方を、パターンごとに整理します。

• 3回とも企画とずれている：コード自体が、企画と違う挙動を表している可能性が高いです。まず実際に遊んで確かめます。
• 3回のうち一部だけずれている：コードが曖昧で、読み手によって解釈が分かれる箇所です。変数名が実際の役割と違う、条件分岐が離れた場所に散らばっている、といった原因が考えられます。バグではなくても、読みにくさのサインです。
• 企画にあるのに、3回ともAIの仕様書にない：未実装か、コードの外にある内容（演出の狙い、難易度の感触など）です。未実装なら実装漏れ、後者なら「コードからは読み取れない項目」として分けて管理します。
• AIの仕様書にあるのに、企画にない：意図しない挙動の候補です。良い偶然なら企画メモに追記し、悪い偶然なら修正します。どちらの場合も、気づかないまま公開するよりよい状態です。
• 根拠の欄が空、または存在しない名前を挙げている：推測として扱います。ずれの数には入れず、別に数えます。

3回一致したからといって、それが正しい仕様とは限りません。一致したのは「同じAIが同じコードを同じように読んだ」という事実だけです。正しさは、実際に遊んで確かめるまで確定しません。

起こりやすい誤り

• 企画メモを先に見せてしまう：AIが企画に合わせた仕様書を作ってしまい、ずれが消えます。企画メモは、仕様書がそろってから初めて開きます。
• AIの出力を鵜呑みにする：根拠の行を開かずに「一致」と判定すると、実験の意味がなくなります。
• ずれをすべて悪いものと決めつける：企画より面白くなっている挙動もありえます。ずれの種類を分けるのは、良し悪しではなく、意図して起きたことかどうかを区別するためです。
• コードが長すぎて途中で切れる：出力が後半に偏る、後半の機能がまるごと抜ける、といった症状が出たら、役割ごとに分割して依頼し直します。
• 回数を絞る：1回だけの出力で結論を出すと、AIの揺らぎをコードの問題と取り違えます。最低3回は回します。
• 企画メモの項目が曖昧：「遊びやすい」「緊張感がある」といった項目は、コードから確認できません。実験前に、数値や条件で書ける形へ直しておきます。

次の行動

まず、手元の完成作品について、確認できる形の企画メモを10項目ほど書き出してください。次に、新しい会話でコードだけを渡し、根拠つきの仕様書を3回作らせて、記録表で比べてみます。ずれが見つかったときは、コードを直すのか、企画メモを直すのか、どちらを正とするかを決めてから手を入れると、次の作品の企画にも使える記録が残ります。