ゲーム制作でAIに「やらないこと」を伝える禁止リストの作り方
遊びをつくる執筆にClaudeを使用しています。
AIにゲームのコードや仕様を書かせるとき、「こうしてほしい」という指示だけで進めると、意図しない実装が混入することがあります。たとえばライブラリを勝手に追加する、グローバル変数を多用する、スコアをlocalStorageに保存するコードを黙って差し込む——こうした「やりすぎ」は、後から気づいて直すほど手間が増えます。 禁止リストとは、プロンプトの冒頭や共通の指示ブロックに「これはしない」を明文化した制約の集まりです。「何を作るか」と「何を作らないか」の両方を渡すことで、AIの出力範囲を狭め、修正コストを下げられます。この記事では、禁止リストをどう設計し、どう育てるかを具体的に説明します。
なぜ「しないこと」の明示が必要なのか
AIは指示されていない選択肢を「よかれと思って」埋めます。これはモデルの設計上の特性であり、悪意ではありません。ただしゲーム制作の文脈では、この補完が問題になりやすい理由がいくつかあります。
ひとつは依存関係の問題です。外部ライブラリを一行追加するだけで、ブラウザゲームのファイルサイズが跳ね上がったり、CDNへの通信が発生したりします。もうひとつはコードスタイルの一貫性です。複数のプロンプトにまたがって開発を進めると、前のセッションで使った命名規則を引き継がずに上書きされることがあります。三つ目は意図しないデータ永続化で、localStorage・Cookie・IndexedDBへの書き込みが無断で入ると、プレイヤーのブラウザ環境を想定外の方法で使うことになります。
これらはいずれも「やってほしいこと」では制御できません。「外部ライブラリを使わずバニラJSで書いてください」と書いても、次の指示で別の話を始めると忘れられます。禁止リストを冒頭に固定することで、セッションをまたいでも制約を維持しやすくなります。
禁止リストに載せる項目の選び方
すべての懸念を列挙すると長大になりすぎ、AIが処理しにくくなります。載せる項目を選ぶ基準は「過去に一度でも起きた、または起きそうな具体的な失敗」に絞ることです。
項目を選ぶ三つの問い
- 「言わなかったら確実にやる」か — AIが自然な補完として選びそうな選択肢だけ禁止します。「空を青くしない」のような自明でない制約は、禁止より先に目標として説明する方が効果的です。
- 修正コストが高いか — 発覚後にリファクタリングが必要になる問題を優先します。変数名の微妙な違いより、アーキテクチャや依存関係の方が直しにくいです。
- プロジェクト固有か汎用か — 汎用の禁止（「外部ライブラリを使わない」など）はテンプレートに入れ、プロジェクト固有の禁止（「このゲームでは効果音の実装はしない」など）は都度追記します。
よくある禁止カテゴリの例
- 依存関係：外部CDNの読み込み、npmパッケージの追加、フレームワークの導入
- データ保存：localStorage・sessionStorage・Cookieへの無断書き込み
- コード構造：グローバル変数の新規追加、既存の関数シグネチャの変更、ファイル分割の変更
- UI・デザイン：既存のCSSクラス名の変更、レイアウト構造への無断追加
- ゲームロジック：難易度・スコア計算式・当たり判定パラメータの勝手な調整
これらはあくまで出発点です。自分のプロジェクトで実際に困ったことだけを残し、余分な項目は削ります。
禁止リストの書き方と配置
フォーマットの基本
禁止リストは短く、肯定形と混ざらないようにするのが基本です。「〜しないでください」で統一するか、「禁止：〜」の箇条書きで統一するか、どちらかに揃えます。混在するとAIが優先順位を判断しにくくなります。
良い例：
## 制約（変更不可）
- 外部ライブラリを読み込まないこと
- localStorageへの書き込みを追加しないこと
- 既存の関数名・引数を変更しないこと避けるべき例：
バニラJSで書いてください。外部ライブラリは禁止。
なるべくシンプルに。localStorageは使わないで。後者は禁止事項が「お願い」に近い文体で埋もれており、AIが制約として処理しにくくなります。
プロンプト内の配置
禁止リストはプロンプトの冒頭に置くのが原則です。長いプロンプトの末尾に書くと、AIが文脈上「補足」として扱い、優先度を下げることがあります。また「このルールは全指示に優先します」という一文を添えると、後続の指示と矛盾したときにどちらを優先するかを明示できます。
チャット形式のツールで複数セッションにまたがる場合は、新しいチャットを始めるたびに同じ禁止リストを貼る運用が現実的です。ファイルに保存しておき、コピーして使い回します。
禁止リストを育てるサイクル
禁止リストは一度作って終わりではなく、開発中に更新するものです。更新のタイミングは「修正のたびに理由を一行メモする」ことで自然に生まれます。
たとえば「AIがcanvasのサイズを勝手に変えたので直した」という出来事があれば、禁止リストに「canvasのwidth・height属性を変更しないこと」を追記します。このメモは後のセッションでもそのまま使えますし、別のプロジェクトに流用できる汎用禁止リストの素材にもなります。
禁止が機能しているか確認する方法
出力を受け取ったあと、禁止リストの項目と照合する習慣をつけます。特に「ファイル全体を書き換えてください」のような広い指示を出した後は、差分を確認して禁止項目が守られているかを見ます。守られていなければ、禁止の書き方が曖昧だったか、配置が末尾だったかを疑います。
また、禁止リストが長くなりすぎたら定期的に整理します。一度も違反されたことがない項目は、AIがそもそも選ばない行動かもしれないので外します。実際に問題になった項目だけが残ると、リストの密度が上がり効果も高まります。
禁止リストの限界と補い方
禁止リストはあくまで補助手段であり、すべての逸脱を防ぐものではありません。特に「ニュアンスで判断が変わる」領域——たとえばアニメーションの速度やUIの余白——は、禁止より「この部分は変更前に確認を取ること」という確認ステップの挿入の方が効果的です。
また、禁止が多くなると指示全体が窮屈になり、AIが正しい変更まで躊躇することがあります。禁止リストは10項目以内を目安に保ち、それを超える場合は「このセッションで触っていいファイルはgame.jsのみ」のようにスコープを絞る方法も検討します。スコープ制限は禁止とは異なり、作業範囲そのものを小さくするため、副作用が少ない制御方法です。
禁止リストとスコープ制限を組み合わせ、実際の失敗から更新していく——この小さなサイクルが、AIとのゲーム制作を安定させる基盤になります。
次の行動
手元のゲームプロジェクトで、前回AIに直してもらった箇所を一つ思い出し、「なぜ直す必要があったか」を一行書いてみてください。それがそのまま禁止リストの最初の項目になります。項目が3〜5本集まったら、次のプロンプトの冒頭に「制約（変更不可）」として貼り、変化を確かめてみてください。
