Claudeでゲームを16本作って分かった、AI制作で本当にやらかした4つのこと
はじめに
Claudeを使って、ゲームを16本作りました。
私は、コードを自分では書いていません。作りたいゲームの設定を考えて、遊んで、「ここが変」「こうしてほしい」と伝える役です。実装は、AIがやってくれます。
16本も作ると、同じような失敗を何度もやらかします。 この記事では、その中から「これは同じようにAIでゲームを作る人に伝えたい」という4つを選びました。
私は、プログラミングもゲーム制作も、ほぼ未経験です。それでもAIを使えば、ゲーム制作の知識がなくても、自分のアイデアや作りたいものを形にできる。それが、AIでゲームを作り始めた理由です。
16本作ってきて、経験値が増えていく感じがして、今とても楽しいです。もっと作りたいと思っています。ただ、楽しい一方で、失敗もたくさんしました。
書いた順番ではなく、気づきやすい順に並べています。
作ったゲーム
16本のうち、13本はブラウザで遊べます。残りの3本は、まだ公開していません（落とし穴4で出てくる「最後の学校」もその1本です）。
その中から、4本だけ紹介します。
ほかにも、蚊のステルスゲーム、文字型抜きなどがあります。説明と遊べるリンクは、こちらのページにまとめています。
私のゲームの作り方
ざっくり、こういう流れです。
設定資料を書く。 どんなゲームか、完成の条件はどこか
Phaseに分ける。 最初から完成版を作らず、少しずつ作る
各Phaseの終わりに、私が遊んでOKを出す。 OKが出てから、次へ進む
最終チェックで見つけた問題は、まとめて直す。 修正は原則1回だけにする
思いついた「もっと良くする案」は、今回は足さず、次回に回す。 終わらなくなるからです
役割は、こう分けています。
・考える役（設計・レビュー）：上位のモデル
・作る役（実装）：軽いモデル
決まったものを実装するだけなら、軽いモデルで十分で、使用量の節約にもなります。考える作業は、上位のモデルのほうが強いからです。モデルの名前や世代はどんどん変わるので、「考える役」と「作る役」を分ける、という点だけ覚えてもらえれば十分です。
作業の記録も、毎回残しています。何を直したかだけでなく、「なぜそうなっていたか（原因）」まで書いてもらうのが、コツです。この記録が、今回の記事の元ネタになりました。
落とし穴1：ブラウザゲームでCtrlキーを使うと、タブが閉じる
蚊になって人間に見つからず血を吸う3Dゲームを、Claudeと一緒に作っていたときの話です。UnityでWebGL版を作って、ブラウザで遊べる形にして公開しました。
蚊が上下に飛ぶので、上昇と下降のキーが必要です。移動はWASD、上昇はSpaceにしました。下降は、最初はShiftにしていました。
でも、私が今までに遊んできたゲームでは、下降はCtrlのものがほとんどでした。それに合わせたくて、公開の前に、下降をShiftからCtrlに変えました。
公開したあと、自分で遊んでいたら、ゲームの途中でいきなりページが閉じました。原因を調べてもらうと、下降に使っていたCtrlキーでした。
原因
前進のWと、下降のCtrlを同時に押すと、ブラウザのCtrl+W（タブを閉じる）になります。ゲーム側からは止められません。Ctrl+Shift+W（ウィンドウを閉じる）、Ctrl+T、Ctrl+Nも同じです。普通に前進しながら下降するだけで、タブごとゲームが消えていました。
一番の失敗は、書いてあった注意に気づかなかったこと
あとで制作記録を見返すと、下降をCtrlに変えたとき（公開の前）に、Claudeがこう書いていました。
「ブラウザ（WebGL）では Ctrl を押しながら W を押すとタブが閉じる（Ctrl+W）など、ブラウザ側のショートカットと重なる。下降のために Ctrl を押したまま前進するとき、全画面にすると防げることが多いが完全ではない。気になるなら下降を別のキーにする候補（06 に記録）」
（※「06」は、制作記録の「次にやるなら」ノートのことです）
注意は、公開の前から記録に書いてありました。でも、私は読んでいませんでした。 長い制作記録の中に埋もれていて、気づかないまま、公開してしまったのです。
私がやることにしたこと
・ブラウザゲームに、Ctrl・Alt・Cmdを含むキーを割り当てない。 下降はCキーに変えて、Claudeに頼んで操作表示とREADMEも直し、再公開しました。
・公開する前に、制作記録の「注意」「リスク」と書いてある所を、自分で探して読む。 記録に書いてあることと、私が知っていることは、別物でした。
Claudeに頼むときのコツ
ブラウザで遊ぶゲームを頼むときは、最初に一言入れておくと防げます。
「ブラウザで遊ぶゲームなので、Ctrl・Alt・Cmdを使うキー割り当ては避けてください」
落とし穴2：同じ指摘が続いたら、細部ではなく「前提」を疑う
矢印のコマンドを素早く入力するゲーム「COMMAND」で、コマンドを打ち終わったときの最後の音を、5回も直した話です。
5回の流れ
私の感想は、毎回こうでした。Claudeは、その感想に合わせて直してくれました。
1回目
私の感想：最後の音が変かも
Claudeが直したこと：音が高すぎて濁っていたので、高さと重ね方を直した
2回目
私の感想：最後の音だけ下がるのが違和感
Claudeが直したこと：直前の音とのつながりを直した
3回目
私の感想：最後の音が重なって聞こえる
Claudeが直したこと：和音をやめて、1音にした
4回目
私の感想：ドレミの音が不安な感じ
Claudeが直したこと：半音階をやめて、ハ長調にそろえた
5回目
私の感想：最後の音は違う音にせず、前の音階の次の音にしてほしい
Claudeが直したこと：最後の音を、普通の音と同じにした
原因
Claudeの記録には、こう書かれていました。
最初の指摘から一貫して「最後の1打は特別な音」という前提で直し続けていたが、本人が求めていたのは最初から特別扱いしないことだった
（記録の一部を、読みやすく言い換えています）
私が毎回伝えていたのは、「変」「下がる」「重なる」「不安」という症状でした。Claudeは、その症状を1つずつ直しました。でも、「最後の音を特別な音にする」という前提が合っていなかったので、直しても、また別の違和感が出てきたのです。
実は、私は最初から「最後の音を特別扱いしたくない」と思っていました。 でも、何が気になるのか、自分でもうまく言えなかったのです。だから、「変かも」「下がる」「重なる」と、耳に聞こえた症状だけを伝えていました。
最終的に、「最後の音は違う音に変えず、前の音階の次の音にしてほしい」と言葉にできて、今は納得できる音になりました。
私が学んだこと
・自分の違和感をうまく言葉にできないときは、伝えやすい症状を伝えるしかない。 でも、それだけだと、AIは症状を1つずつ直し続けます
・同じ場所を2回直しても納得できなかったら、細部の話をやめる。 「あなたは何を前提に直しているの？」とAIに聞いてもらう。もしくは、自分から「本当はこうしたい」を言葉にする
・症状だけでなく、「こうなってほしい」という形を、早めに伝える。 今回なら「最後の音も、ほかの音と同じ並びで上がってほしい」です
Claudeに頼むときのコツ
「同じ箇所の指摘が2回続いたら、細かい修正をする前に、『その箇所に最初に置いた前提』が合っているかを私に確認してください」
落とし穴3：AIは、自分で作った音を波形でしか捉えられない。音は「候補を並べて選ぶ」
爆弾をボールにしたバレーのゲーム「爆弾バレー」で、ボールを叩く音を作っていたときの話です。
Claudeは、自分で作った音を、波形（音の形のデータ）としてしか捉えられません。 「太鼓みたい」「電気みたい」のように、どんな音に聞こえるかを、正確に言い表すことができないのです。
外れ続けた3回
・最初の音は、「太鼓みたい」でした
・Claudeが低い音を外して作り直すと、今度は「タッチ音がパチって電気が走った音に聞こえるから、ちゃんとボールを手で叩いた音にして」でした
・直し直すと、また「太鼓っぽい」でした
Claudeの記録には、こう書かれています。
音を1つずつ作り替えても、こちらは音を聞けないので当たらなかった（太鼓 → 電気 → 太鼓）
候補を並べてもらったら、2回で決まった
Claudeが、候補を並べた聞き比べページを作ってくれました。
・1回目の候補A〜Eは、全部「金属の蓋を爪で叩いたような音」でした。原因は、同じ音を少しずらして重ねると、特定の高さが強め合って金属のように鳴ることでした
・2回目の候補F〜Iは、響きをなくして作り直しました。私がIを「一番近い」と選んで、ゲームに入れました
1回目の候補が全部「金属の蓋」に聞こえたときは、正直、「なんでそうなった？」と思って、面白くなりました。ただ、聞き比べページ自体は、自分で「これだ」と思うものを選べるので、とても楽でした。
私が学んだこと
・Claudeは、作った音を波形でしか捉えられず、どんな音に聞こえるかを正確に言い表せない。 「こんな音のはず」で作り直しても、当たりません
・耳で判断できるのは私だけなので、選ぶ役に回るほうが早い
・「一番近い」でも、まず進められます。気に入らなければ、また調整する、と決めておけば止まりません
Claudeに頼むときのコツ
「音の作り直しを、1つずつ試さないでください。候補を5個ほど並べて聞き比べられるページを作って、私に選ばせてください」
落とし穴4：実装したAIにレビューさせても、バグは見つからない。そして、面白いかどうかは別の話
ここまでは、小さな失敗の話でした。最後は、一番大きな学びです。
3Dの脱出パズル（このゲームは非公開）を作っていたときの話です。先ほどの役割分担（考える役と作る役）で、実装の担当とは別のAIに、書かれたコードをレビューさせました。
音楽室の謎まで作り終えた段階（フェーズ2）
ここでいう「レビュー担当」は、私ではありません。書かれたコードを読んで、問題を探す専用のAI（Opus）です。私は、そのAIが見つけた問題の報告を受ける側でした。
そのAIは、7件の不具合を見つけてくれました。一方、コードを書いた実装担当のAI自身が見直して見つけたのは、0件でした。
見つかったのは、どれも「普通に動くけれど、特別な状況でだけ壊れる」バグです。たとえば、横に長い楽器を長い辺の側から近づくと、触れるはずなのに「調べる」の表示が出ない。楽器を扉のすぐ内側に落とすと、通れなくなりかねない、といったものです。私が普通に遊んで確かめるだけでは、まず気づけません。
でも、レビューだけでは足りなかった
ところが、体育館まで作った段階で、私が自分で通しで遊んでみたら、レビューが見つけていない問題が4件ありました。
文章の紙を調べる判定が広すぎて、どこを見ればいいのか分かりにくい。近づきすぎると、判定が出なくなる
体育館が広すぎて、手がかりを読んで回るのが面倒
校門前の前庭が、無制限に歩ける（白い地面の外まで出られてしまう）
昇降口に「貼り紙を調べる」の表示は出るのに、貼り紙そのものが見えない
どれも、コードの上では「動いている」ものです。遊んで初めて、おかしいと感じるものでした。
最後まで遊んで、一番強く感じたこと
最後まで通して遊んだあと、私が一番強く感じたのは、バグではなく次の2つでした。
・謎解きの難しさが、ちょうどよくない。
・クリアしたあとの報酬や達成感が足りなくて、面白みがない。
バグは、ほぼ直っていました。コードの上では、ちゃんと動いていたのです。それでも、遊んでいて「面白い」と感じられるかどうかは、別の話でした。
AIのレビューは、「動くか」「壊れないか」は教えてくれます。でも、「この謎は簡単すぎないか」「解いたあとに嬉しいか」は、レビューの対象になっていません。そこは、私が遊んで判断するしかありませんでした。
私が気づいたこと
・AIのレビューが見つけるのは、「コードの中の間違い」。 特別な状況でだけ壊れるような、遊んでもなかなか気づけないものです
・私が遊んで見つけるのは、「遊んだときの感じ」。 判定の分かりやすさ、広さ、見えているはずのものが見えないこと、そして謎の難しさと達成感です
・どちらか片方では、足りません。両方あって初めて、完成に近づきます
・AIに「正しく動くゲーム」は作らせられても、「面白いゲーム」にできるかは、遊ぶ私の仕事でした
使用量の問題
最初のうちは、タスクごとに「実装 → レビュー」を機械的に繰り返していました。すると、ある時点でレビュー側が利用制限に達して、レビューが失敗しました。
そこで、私は方針を変えました。
「サブエージェントやバックグラウンドレビューを増やしすぎないように。実装は軽いモデルにまとめて任せ、重要な箇所だけレビューする」
以降は、変更の影響が大きい所（既存の動作に触れる処理など）だけレビューに回しました。
Claudeに頼むときのコツ
レビュー担当には、こう伝えます。
「実装者の報告は信用せず、関連するコードを自分で読んで、特別な状況（すでに何かが置いてある状態、順番を入れ替えた状態）でも壊れないかを確かめてください」
AIに任せること、任せないこと
16本作ってみて、私の中で、こう分かれました。
任せること
・コードを書く（実装）
・テストを作る、回す
・細かい数値の調整
・制作の記録（何を直したか、なぜそうなっていたか）
任せないこと（自分でやること）
・どんなゲームにするかという、方向性
・遊んで、面白いかどうかを判断すること
・音など、人の耳や感覚で決めること（選ぶ役になる）
・公開するかどうかの判断
今回の4つの失敗は、どれも「任せないこと」を自分でやっていなかったか、AIの出した注意が私に届いていなかったことが原因でした。
おわりに
AIにゲームを作らせるのは、とても楽です。でも、楽になった分、「遊ぶ」「確かめる」「選ぶ」という自分の仕事が、はっきり残ると感じました。
今回は、失敗談を4つに絞って紹介しました。次回は、もっと実践的な部分を解説する予定です。
・設定資料の書き方（Claudeにゲームを作ってもらうための、最初の資料の作り方）
・作業の進め方（Phaseの分け方、遊んで確認するタイミング）
・コンテキストや利用制限の節約方法（長い作業で、使用量を使い切らないための工夫）
次回も読んでもらえたら嬉しいです。
AIゲーム実験室では、ゲームの紹介や制作の過程を発信しています。
・X：https://x.com/AIGameLabJP
・YouTube：https://www.youtube.com/@AIGameLabJP-q9s
・ゲームを遊ぶ：https://fish-suika.github.io/games/
