プロンプトが長くなりすぎたら：ゲーム仕様をファイルに分ける

なぜ「ファイルに分ける」と改善するのか

プロンプトをファイルに分ける目的は二つあります。一つは「その会話で必要な情報だけをAIに渡す」こと。もう一つは「自分が仕様を把握しやすくなる」ことです。

AIへの入力は短いほど精度が上がるわけではありませんが、関係のない情報が混じると回答がぶれます。たとえばUIのデザイン指示とゲームロジックの仕様が同じブロックに書いてあると、「UIを直して」とお願いしたときにAIがロジックも触り始めることがあります。ファイルを分けておくと、「今回はこのファイルだけ参照して」と絞り込めます。

また、自分自身の理解が整理されるという副次効果があります。仕様をファイルに書き出す作業は、頭の中の曖昧な意図を言語化する工程です。ここで矛盾に気づくことが多く、AIに聞く前に問題を潰せます。

ファイルを分ける三つの軸

仕様を切り分けるときに使いやすい軸が三つあります。

「変わらないもの」と「変わるもの」

ゲームのコアルール（例：タイルを三つ並べたら消える）は滅多に変わりません。一方、スコアの計算式やUIの色は頻繁に調整します。変わらないものは core-rules.md のような名前で固定し、会話のたびに渡します。変わるものは別ファイルにして、改訂が入るたびに上書きします。こうすると「さっき直したはずなのに反映されていない」という事故が減ります。

「何をするか」と「どう見せるか」

ゲームロジック（スコア計算、当たり判定、ステージ進行）とビジュアル・UI（色、フォント、アニメーション）は別ファイルにするのが基本です。AIにロジックだけ直してもらいたい場面でUIの仕様を見せる必要はなく、逆も同じです。ファイルが分かれていると「今日はロジックファイルだけ渡す」という判断が自然にできます。

「AIへの指示」と「AIへの参照資料」

「こういうコードを書いて」という命令と、「このデータ構造を使って」という参照情報は性質が違います。命令はプロンプト本文に書き、参照情報はファイルに外出しするのが見通しがよくなります。たとえばアイテムの一覧表や敵キャラクターのパラメータ表は参照資料です。毎回プロンプトに貼るのでなく、ファイルとして渡して「このファイルに書いたデータを使ってください」と一行添えるだけにします。

実際のファイル構成の例

シンプルなパズルゲームを想定した例です。

game-spec/
  core-rules.md       ← ゲームの根幹ルール（ほぼ変更しない）
  ui-design.md        ← 画面レイアウト・色・フォント（頻繁に調整）
  level-data.md       ← ステージ構成・難易度（段階的に追加）
  bug-log.md          ← 既知の不具合と対処の記録
  prompt-base.txt     ← 毎回使う定型プロンプト（役割設定・出力形式など）

prompt-base.txt には「あなたはHTML/CSSとJavaScriptでブラウザゲームを書くエンジニアです。コード全体を返してください。説明は不要です。」のような定型文を書いておきます。毎回打ち直す手間がなくなり、指示の揺れも防げます。

実際の会話では「prompt-base.txt の指示に従い、core-rules.md と ui-design.md を参照して、レベル選択画面を実装してください」のように渡す資料を明示します。バグ修正の会話なら bug-log.md と core-rules.md だけを渡し、UIファイルは含めません。

「いつ分けるか」の判断基準

最初から細かく分けようとする必要はありません。次のどれかに当てはまったら分割を検討するタイミングです。

• 同じ仕様を2回以上コピペした
• 「さっき伝えたはずの仕様が反映されていない」が連続した
• 仕様変更のたびにプロンプト全体を読み返している
• 一度のプロンプトに異なる種類の指示が三種類以上混在している

逆に、2〜3時間で完成させる小品や実験的な試作なら、ファイルに分けるコストが見合わないこともあります。プロジェクトを繰り返し更新していく、あるいは複数セッションにまたがる規模になったときに導入するのが現実的です。

失敗しやすいパターンと対策

ファイルを増やしすぎて迷子になる

ファイルが増えると「どれを渡せばいいか」を考える認知負担が増えます。ファイル数は最初は三つ程度に抑え、「このファイルに何が書いてあるか」を一言で言えない場合は統合を検討します。

古いバージョンと混同する

同じ仕様を「プロンプトのメモ帳アプリ」「ローカルのテキストファイル」「AIの会話履歴」の三か所に書くと、どれが最新かわからなくなります。仕様の正本は一か所だけ、という原則を最初に決めておくことが大切です。多くの場合、ローカルのファイルを正本にしてAIの会話履歴には頼らない運用が安定します。

AIに「前のファイルを覚えていて」と期待する

多くのAIツールは会話をまたいで記憶を保持しません。「前回見せたファイル」は次のセッションでは存在しないと考え、毎回必要なファイルを渡す習慣にします。これを前提に設計しておくと、ファイル管理の重要性が自然と身につきます。

仕様ファイルがコードと乖離する

コードを修正するたびに仕様ファイルも更新しないと、やがてドキュメントと実装が別物になります。一つの解決策は「コードを修正したらその場でAIに『今回の変更を仕様ファイルに反映した差分を書いて』と頼む」習慣です。更新作業もAIに担わせることで乖離を防げます。

次の行動

今取り組んでいるゲームのプロンプトを開き、「ロジックに関する部分」と「見た目に関する部分」に線を引いてみてください。切り分けられそうなら、それぞれをテキストファイルに書き出してみるのが最初の一歩です。完成したゲームはアソバースに投稿して、実際にプレイしてもらいながら仕様を育てていくこともできます。