Claudeでゲームを作るとき、私が最初に渡している「設定資料」と進め方
はじめに
前回の記事を読んでくださった方、ありがとうございました。
コメントでは、「最後の音を5回直した話」や「音は候補を並べて選ぶ」の話に触れてもらえました。失敗の話を、どう気づいたかまで具体的に書くと伝わるんだ、と分かって嬉しかったです。
あれから1本増えて、作ったゲームは17本になりました。
今回は、前回予告したとおり、実際にどうやって作っているかを書きます。
設定資料の書き方（Claudeに最初に渡す資料）
作業の進め方（Phaseの分け方と、遊んで確かめるタイミング）
使用量の節約（長い作業で、上限に当たらないための工夫）
今回も、手順だけでなく、それぞれのやり方にたどり着くまでの失敗を一緒に書きます。最後に、そのままClaudeに伝えられる「頼み方」も載せています。
1. 設定資料の書き方
設定資料を渡したら、そのまま作り始めてしまった
ボタンを押すだけの仕事なのに、客の注文がどんどん面倒になるゲーム「エレベーター係」を作り始めたときの話です。
私は、いつもどおり設定資料を書いて、Claudeに渡しました。すると、Claudeは資料を読んだあと、そのまま最初のPhaseの実装まで作り始めてしまいました。
前回の記事で書いたように、私は「考える役」と「作る役」でモデルを分けています。設定資料を読んで整理するのは考える役、実装は作る役です。ところが、考える役のまま実装まで進んでしまったのです。
それ以来、設定資料を渡すときは、「保存するところまでで止めて」とはっきり伝えるようにしています。
設定資料は、AIと相談しながら私がまとめる
設定資料は、AIと相談しながら、私がまとめています。
「こんなゲームを作りたい」というぼんやりした考えを話して、AIに質問してもらったり、案を出してもらったりします。でも、何を作るかを決めるのは私です。AIには、それを言葉にするのを手伝ってもらっています。
エレベーター係の設定資料は、全部で約5,700字、24項目ありました。その中から、書いておいて特に効いた項目を紹介します。
効いた項目1：ひとことで言うと
エレベーターのボタンを押すだけなのに、客の注文がどんどん面倒になるゲーム
最初に1行で書いておくと、AIも私も、迷ったときにここに戻れます。
効いた項目2：設計方針
操作を難しくするのではなく、状況を難しくする
エレベーター係では、操作は最後まで「正しい階のボタンを押す」だけです。そのかわり、途中で目的の階が変わったり、存在しない階を頼まれたりします。
これを書いていないと、AIは「難しくする」ために、制限時間や複雑な操作を足してしまいがちです。
効いた項目3：入れないもの
育成・アイテム収集・長時間前提・複雑なストーリー・複雑な操作・大量素材・外部3Dモデル・オンライン機能
AIは、親切に機能を足してくれます。でも、足してほしくないものもあります。「入れないもの」を書いておくと、話がふくらみすぎません。
効いた項目4：最後にプレイヤーに思ってほしいこと
最初はただのエレベーターゲームだったのに、なんで最後こんなことになってるんだよｗ
これが、一番大事な項目だと思っています。細かい判断に迷ったとき、「これはこの一言に近づくか？」で決められるからです。
効いた項目5：Phase分け
最初から、Phaseの中身を書いておきます。エレベーター係では、こう分けました。
・Phase 1：エレベーターの空間、階数ボタン、ボタンで階を移動、簡単な乗客
・Phase 2：乗客の目的階、正解の判定、スコア、次の乗客
・Phase 3：難しくなっていく、注文の変更、複数の乗客、変な注文
・Phase 4：バカゲー展開、存在しない階、終盤のイベント、エンディング
・Phase 5：見た目や操作の調整、演出、バグ修正、テンポ調整
Phaseの進め方は、次の章で書きます。
分からないところは、先に質問してもらう
設定資料を渡すときは、「分からない点や矛盾があれば、作り始める前に質問して」と添えています。
夜道を家まで帰るホラーゲーム「帰り道」では、私が書いた資料の中で、道順の書き方と、物語の流れが食い違っていました。 Claudeがそれを先に指摘してくれたので、作り始める前に直せました。そのまま作っていたら、あとで大きな手戻りになっていたと思います。
設定資料テンプレート
私が使っている項目を、テンプレートにしました。全部埋めなくても大丈夫です。特に1・5・6・7・8があると、ぶれにくくなります。
ひとことで言うと（1行）
遊ぶ環境（PC／スマホ、縦画面／横画面、ブラウザ／Unity など）
基本の流れ（1回遊ぶと、何が起きるか）
面白さの芯・設計方針
入れないもの
最後にプレイヤーに思ってほしいこと
Phase分け（Phase 1〜N の中身）
完成条件（どこまでできたら完成か）
8の完成条件は、エレベーター係の資料には書いていませんでした。書いておかないと、どこまでも直したくなります。これも次の章で書きます。
頼み方
「この設定資料を保存するところまでで止めてください。分からない点や矛盾があれば、実装を始める前に質問してください」
2. 作業の進め方
全体の流れは、こうです。
前回も少し書きましたが、今回はそれぞれの理由を書きます。
Phaseの終わりに、必ず自分で遊ぶ
Phaseが終わったら、私が実際に遊んで、OKを出してから次へ進みます。
前回の落とし穴4で書いたとおり、3Dの脱出パズル「最後の学校」では、AIのレビューが7件のバグを見つけてくれました。でも、私が遊んでみると、レビューが見つけていない問題が4件ありました。どれも「コードの上では動いている」けれど、遊ぶとおかしいと分かるものでした。
AIは「正しく動くか」を確かめてくれます。でも「遊んでどう感じるか」は、遊ぶ人にしか分かりません。だから、Phaseごとに遊ぶ時間をとっています。
細かいことで止めない。まとめて報告してもらう
作り始めたころは、Claudeが細かい改善案を思いつくたびに、作業を止めて確認してくれていました。ありがたいのですが、毎回止まって確認されるのが面倒でした。それに、やり取りが増えるほど、使用量も増えます（3章で書きます）。
今は、こう頼んでいます。
・すぐ知らせてほしいことだけ、作業を止めて報告してもらう
・先に進めなくなるバグ
・あとのPhaseに響く、設計の問題
・設定資料と大きく食い違うこと
・それ以外（見た目の小さな調整など）は、記録しておいて、Phaseの終わりにまとめて報告してもらう
完成条件を満たしたら、作り込まない
最後に通しで遊んで、見つけた問題はまとめて1回で直します。 完成条件を満たしていたら、そこで完成です。
途中で「もっとこうしたら良くなる」と思いついたことは、今回は足さずに「次にやるなら」というメモに書くだけにしています。
こうしているのには、理由があります。
自分が気になる所を直しても、他の人は気にならないかもしれない。逆に、自分が気にならない所が、他の人には気になるかもしれない。
作っている本人は、同じゲームを何十回も遊ぶので、細かい所がどんどん気になってきます。でも、それが遊ぶ人にとって大事かどうかは、分かりません。だから、作り込みや細かい修正は、他の人の意見を聞いてからにしています。
記録を残してもらう
作業のたびに、Claudeに記録を書いてもらっています。何を直したかだけでなく、なぜそうなっていたかも書いてもらいます。
この記録があると、会話を新しく始めても、続きから再開できます。これが、次の章の節約にもつながります。
頼み方
「Phase 1 だけ作ってください。終わったら、作ったもの・残っている問題・次のPhaseへの影響を短く報告して、止まってください。軽い見た目の改善案は、作業を止めずに記録だけしておいてください」
3. 使用量の節約
先に、言葉の説明を2つ
・会話の長さ（コンテキスト）：AIが、その会話の中で覚えている量です。AIは、返事をするたびに、それまでの会話を全部読み直します。だから、会話が長くなるほど、1回のやり取りで使う量が増えます。
・利用制限：一定の時間に使える量の上限です。上限に当たると、時間がたつまで待つしかありません。
上限に当たって、作業が止まった
ゲームを作っていて、何度も上限に当たりました。続きをやりたいのに、待つしかない。作業が止まってしまうのが、困りました。
そこで、どうすれば使用量を節約できるかを、Claudeに聞いて、少しずつやり方を直していきました。 過去の作業の記録を分析してもらうと、原因がはっきり分かりました。
爆弾バレー
・1つの会話に、45回分の依頼を積み重ねていた
・テストのたびに、考える役（上位のモデル）が自分で画面を撮って確かめていた
・その結果、会話が約78万トークンまで膨らみ、上限に当たった
（トークンは、AIが読む文字の量の単位です。ここでは「会話の長さ」と思ってください）
BULLET TIME
・考える役の会話は、約20万トークンに収まっていた
・でも、作業役（実装を担当する別のAI）を1体だけ、12回使い回していた
・作業役の会話が約69万トークンまで膨らんでいた
最後の学校
・作業を細かく分けて、そのたびに「実装 → レビュー」を機械的に繰り返していた
・レビュー役のほうが上限に当たって、レビューが失敗した（前回の落とし穴4の続きです）
どれも、「1回1回は大したことがないのに、積み重なって膨らんでいた」という失敗でした。
今やっていること（5つ）
1. 考える役と作る役を分ける
設計やレビューは上位のモデル、実装は軽いモデルにまとめて任せます。レビューは、毎回ではなく、影響の大きい所だけにしています。
2. 作業役は、1つの仕事ごとに新しく呼ぶ
同じ作業役を使い回すと、その作業役の会話がどんどん長くなります。1つの仕事が終わったら、次は新しい作業役に頼みます。
3. 画面の撮影を減らす
画面の画像は、文字よりずっと重いです。ゲームの状態は、画像ではなく文字で確かめてもらいます。テストは作業役に任せて、結果は「OK／NG＋原因」だけ短く返してもらいます。
4. 区切りで、新しい会話に移る
会話が約20万トークンを超えたら、Phaseの区切りで新しい会話に移ります。2章で書いた記録があるので、新しい会話でも続きから始められます。
5. 細かいことで止めない
2章の「まとめて報告」と同じです。やり取りの回数そのものが減ります。
頼み方
「テストは別の作業役に任せて、結果は『OK／NG＋原因』だけ短く報告してください。画面の撮影は、見た目の確認が必要なときだけにしてください」
「この会話が長くなってきたら、Phaseの区切りで新しい会話に移ることを提案してください」
おわりに
3つの話に共通しているのは、「決めるのは私、手を動かすのはAI」という境目を、最初にはっきり書いておくことでした。
・何を作るか、何を入れないか → 設定資料に書く
・いつ止まって、何を報告するか → 頼み方に書く
・どのくらいの量を使うか → 役割と区切りを決めておく
境目を書いておくと、AIは迷わず進められますし、私も「遊ぶ」「選ぶ」「決める」に集中できます。
次回は、ブラウザゲームの落とし穴を書く予定です。スマホを縦に持ったときの見え方や、最初にタップしないと音が出ない話など、ブラウザで遊べるゲームを作るときにハマったことをまとめます。
AIゲーム実験室では、ゲームの紹介や制作の過程を発信しています。
・X：https://x.com/AIGameLabJP
・YouTube：https://www.youtube.com/@AIGameLabJP-q9s
・ゲームを遊ぶ：https://fish-suika.github.io/games/
