著者: lpre_ys 最終更新日: 2026.08.18
この記事で紹介する環境は、実装をほぼ全て Claude Code に任せて作った。私がやったのは方針を決めることと、出てきた結果を見て判断することだけで、プログラムは自分では書いていない。詳しくは最後の章で。 なお、この文章もほとんど Claude に書かせた。（もちろん添削はしている）
RPGツクール2000で「玉露の続き物」というシリーズを作っている。Vol.1 から Vol.11 まであって、通しでプレイすると15〜18時間かかる。
この規模になると、手でテストプレイするのがそろそろしんどい。通しプレイは毎回やっているものの、1周試すのがせいぜいである。
そこで、ゲームを勝手に動かして勝手に壊れ方を報告してくれる仕組みを作ることにした。寝る前にコマンドを1つ叩いておくと、朝にはこういうレポートが出ている。
=== 夜間モンキーテスト night_20260816_213146 ===
期間 : 08-16 21:31:46 → 08-17 06:43:33 (9h11m)
ラウンド : 18/18 完了 条件: 8並列 × 1800秒
総ゲーム時間 : 72.0時間相当 総送信キー : 471691回
--- 判定 ---------------------------------------------------------
OK 134 / SUSPECT 0 / CRASH 2 / KNOWN_ISSUE(除外) 8
--- ソフトロック候補の詳細 ---------------------------------------
なし30分ずつ8本を同時に走らせるのを18回繰り返して、合計144本。実時間9時間で、のべ72時間プレイさせた結果。キーは47万回叩いている。144本のうち134本が問題なし、2本が異常終了、8本は調査済みの問題として集計から外した。
人間には到底無理な物量で、しかも寝ている間に終わる。
モンキーテストというのは、ランダムにボタンを叩き続けるだけのテストのこと。猿がキーボードを叩いているイメージからこう呼ばれている。
ゲーム内容を理解しての操作ではないため、実際のプレイとはかけ離れたテストではある。
それでも最初にこれを選んだのは、自動テストの中でいちばん要求が少ないから。ゲームを理解する必要がないので、AI等の考えを挟む必要が無く、機械的に実装できる。 「操作を送る」「画面を見る」「異常を見つける」「もう一度同じことを起こす」という土台さえ作れば成立する。そしてこの土台は、もっと賢いテストに流用することも可能。
まずは自動テストの第一歩として、並列モンキーテストの実装を行った。
仮想デスクトップを8個用意して、その中でEasyRPG Player(後述)を1本ずつ動かし、ランダムなキー入力を延々と送り込んでいる。
仮想デスクトップであれば、実行中も自分の画面には何も出ないし、作業中のウィンドウからフォーカスも奪われない。8本走らせても互いのキー入力が混ざることもない。
ゲームは1秒ごとに自動でスクリーンショットを保存する。あとはそれを見ながら、異常が起きていないかを機械的に判定する。
ツクール2000で作ったゲームは RPG_RT.exe
で動く。これは普通の Windows
アプリで、外から自動操作する手段がほとんど用意されていない。フォーカスが外れると動作が止まる仕様もあって、8本同時に走らせるようなことはできない。
代わりに EasyRPG Player を使う。ツクール2000/2003のゲームデータをそのまま動かせるオープンソースのソフトで、これがテスト用途に最適。
| 本家 RPG_RT | EasyRPG Player | |
|---|---|---|
| 起動 | ダブルクリックのみ | コマンドから細かく指定できる |
| 入力の記録・再生 | できない | できる |
| 乱数の固定 | できない | できる |
| 自動スクリーンショット | できない | 設定で1秒ごとに保存できる |
| フォーカスが外れたとき | 止まる | 止めない設定がある |
| 中で何が起きているか | 分からない | オープンソースなので調べられる |
| 動作環境 | Windows のみ | Linux でも動く |
バグを見つけても再現できなければ直せないので、入力の記録と再生は必須。そしてオープンソースなので改造も可能。 また、Linux環境でも動くためWSL上で動かすことができる。
互換性は先に確かめる必要がある。一通りプレイしたスクショを見て、大きな描画崩れや本家ではありえないスタックが起きないことは確認済み。 なお、玉露の続き物シリーズは自作システムを多く使っている都合、ツクール側の機能は最低限しか使っていない。（ピクチャ表示・画面表示系と変数操作とIF/ループ構文がほとんど）ツクール側のマイナーな機能を使っている場合は正しく動かない可能性があるので注意。
もちろん、EasyRPGでの通しプレイまでは時間の都合上やっていない。（そもそもサポート対象にしていない） よって「本家とまったく同じもの」としては扱わない。本当にゲームのバグかどうかは個別に調査する必要がある。
モンキーテストなので、ゲームの挙動やバランスといった点はテスト対象外とした。 対象とするのは下記のみ。
| 見るもの | どう判定するか |
|---|---|
| 落ちていないか | ゲームが最後まで生きていたか |
| ログに異常が出ていないか | エラーや警告のメッセージが記録されていないか |
| ソフトロックしていないか | 画面が変わらないまま、キーを送り続けている状態が続いていないか |
| どこまで行けたか | 到達したマップの数（バグではなく、テストの効き具合を測る指標） |
画面が止まっているだけならメニューやコマンド選択中でも起きるので、「キーを送り続けているのに画面が1ミリも変わらない」を条件にしている。これでほとんどの誤検知が消える。
EasyRPG が保存する画像は、同じ画面なら1バイトの狂いもなく同じデータになる。よって画像比較は不要で、ハッシュを取って前の1枚と突き合わせればいい。
ハッシュ同士の比較なら速いし、ハッシュさえ残っていれば画像本体は消しても良い。 判定後のスクショはほとんど捨てている。
バグで多いのが、暗転したまま戻ってこないやつ。フェードアウト後に画面を戻す処理が抜けているパターン。
PNG は同じ色が続くところを圧縮するので、完全な黒一色は極端に小さくなる。この環境だと必ず302バイト。ファイルサイズを見るだけで暗転を検出できるので、画像を開く必要すらない。
前章の仕組みで「38秒間、画面が変わらないままキーを73回送っていた」までは分かる。しかしその先に進めない。
画面が真っ黒だと手がかりが何もない。
そこで EasyRPG Player
自体に手を入れて、ゲーム内部の状態を1秒ごとに記録させるようにした。ツクールで言えば
RPG_RT.exe
を改造して「今このイベントの何行目を実行中」と吐き出させるようなもの。
修正は、内部情報を外から読めるようにするだけの追加。当然だが、ゲームの動作そのものには手を加えていない。
| 記録するもの | 内容 |
|---|---|
| 画面の状態 | どのマップのどこにいるか、暗転しているか、メッセージを表示中か |
| イベントの実行位置 | どのイベントの何番目のコマンドを実行中か。コマンドの名前と引数まで |
| 待ち状態 | 入力待ちなのか、ウェイト中なのか、移動待ちなのか |
| ピクチャ | 表示中の画像の一覧（名前・位置・拡大率・透明度） |
| 変数とスイッチ | 前の1秒からの変化ぶんだけ |
効くのは真ん中と最後。
イベントの実行位置は「マップ139のイベント1、341コマンド中の89番目、顔グラフィックの変更を実行中」と出る。私の場合ほとんどの実装はツクブリのコードを経由しているため、行番号が分かればすぐ追えるし、コマンド名と引数が分かれば尚追いやすい。
変数とスイッチは、全部出すと数千件になるため変化したものだけを記録している。数件で済むうえ、ループしている変数が一発で見つかる。
記録はスクリーンショットの連番と対応づけてあるので、「この画面のとき中で何が起きていたか」が常にセットで見られる。
「このラウンドでバグがあった」という報告だけでは困る。仮にテストから30分後に見つかったバグの場合、30分同じ操作をしなければバグの再現すらできず、確認できないからだ。
試行のたびに30分かかっていたら仮説の検証が回らないので、段階的に縮めていく。
EasyRPG Player には入力を記録して再生する機能がある。乱数も固定できるため、完全に状況再現を行うことができる。
ただし記録時と再生時で画面まわりの条件を揃える必要がある。記録をウィンドウ表示で取ったなら再生もウィンドウ表示にする。片方だけ画面なしのモードにすると結果がずれて、バグが再現しないことがある。
再生を10倍速にする改造も入れた。30分の記録が3分で終わる。
早送りすると挙動が変わりそうだが、再生は「何フレーム目にどのキーを押したか」で管理されているため結果は変わらない。10倍速と通常速度で、暗転区間も画像のハッシュも完全に一致することは確認済み。
さらに縮めるため、指定した時点でセーブファイルを作る機能(ステートセーブ)を足した。バグの直前でセーブを作れば、以降の調査は「ロードして数キー送るだけ」で済む。3分が数秒になる。
ただし取ってはいけない瞬間がある。
| そのときの状況 | 使えるか | 理由 |
|---|---|---|
| 普通にマップを歩いている | 使える | 問題なし |
| メッセージを表示中 | 一応使える | ウィンドウは消えるが、イベントの続きからは進む |
| 選択肢や数値入力の待ち | 使えない | 待っている状態が保存されず、ロードすると勝手に既定の選択肢が選ばれる |
| 戦闘中 | 使えない | ロードすると戦闘が消えてマップに戻ってしまう |
ツクールのセーブはマップ上の状態しか持たないので、そこから外れた場面は収まらない。そもそもこの機能は本家のセーブとは別物で、内部処理を直接呼んで無理やり作っている。安全ではないタイミングで取れば正しく動かないのは当たり前。
よって、危険なタイミングでステートセーブを取らないよう調整する必要がある。
最後はキーの押し方を変えながら試して、バグが起きる最小の手順を割り出す。直前のセーブから始めれば、そこからバグまでに送ったキーは数十回ぶんしか残っていない。その記録を手がかりにすれば10通りも試せば当たるし、1回の試行は数秒で終わる。
ここまで来れば、人間が本家で確認できる手順書ができる。
ここまでで「1本走らせて調べる」はできた。あとはこれを放置して回せるようにする。
コマンドはシンプルにした。起動時に、正しく立ち上がったかのチェックも走り、引っかかったら進まないようにしている。朝起きて「実は起動に失敗していて8時間何も動いていなかった」ほど悲しいことはない。またWSLはWindowsが再起動すると即死するので、中断からの再開も組み込んである（実際に一晩ぶん消えた）。
実行は8時間を1本ではなく、30分のかたまりの繰り返しにしている。スクリーンショットは同じフォルダに溜まるほど保存が遅くなり、8時間ぶんで1枚あたり98ミリ秒、撮るたびにゲームが目に見えて止まるところまでいく。フォルダを分ければ6ミリ秒で済む。区切りのたびに判定と刈り込みを挟めるという利点もついてきた。
実際に見つかった不具合で、一連の流れを説明する。
夜間の実行で、1本が「38秒間、画面が変わらないままキーを73回送信」を記録した。画面は完全な黒一色。
当初これは「38秒の遅延」に見えていた。ランダム入力が73回叩き込まれた結果、偶然抜けられていたからだ。
そこで直前のセーブから同じ状態を作り、今度は入力をまったく送らずに放置してみた。
143秒経っても戻らなかった。しかもこれは私が待つのをやめただけで、実際にはまだ続いていた。
つまり、もたつきではなく完全なソフトロックである。ランダム入力で偶然脱出できていたせいで、症状が軽く見えていた。
ランダム入力は、バグを見つけると同時にその深刻さを過小に見せることがある。人間なら「これ戻らないな」と思ってコントローラーを置くところを、機械は延々と叩き続けて偶然抜けてしまう。以降、怪しい判定が出たら「入力を止めたらどうなるか」を必ず確認するようにした。
記録を見るとはっきりしていた。
バトルのマップで【画面の消去】が実行されて暗転する。そのまま場所移動でクエスト選択のマップへ移る。ここまでは想定どおり。
ところが移動先で、【画面の表示】が一度も実行されないまま選択肢が3つ連続で表示されていた。
真っ黒な画面の裏に、見えない選択肢が3つ並んで入力を待っていた。プレイヤーからはフリーズにしか見えないが、実は決定ボタンを連打すれば抜けられる。
なお、この「記録を読んで原因を突き止める」部分は機械に任せられない。ここは Claude Code に解析させている。
ツクール2000のヘルプの「画面の消去」にはこう書いてある。
このコマンドによって画面を消去した後で［場所移動］コマンドを実行すると、［システム］の［場所移動］に設定された［画面の消去方法］および［画面の表示方法］に基づく処理は無視され、画面が消去されたまま場所移動されます。
暗転したまま場所移動しても暗転が続くのは仕様どおりで、その裏では文章もピクチャも表示されない。悪いのは、移動先で【画面の表示】を実行する前に選択肢を出しているイベント側の組み方である。
これは EasyRPG だから起きたバグではない。本家で動かしても同じソフトロックになる。自動テストで見つけた最初のバグとなった。
最初に残っていた入力記録は33,323行。それが最終的にこうなった。
直前のセーブも一緒に残してあるので、ロードして4キーで誰でも再現できる。
バトル敗北時のメニューは、初期に組んだものがそのままのため、普段使わない「クエスト選択に戻る」はテストされる機会自体が少ない。（本来は毎回テストすべきだが、忘れがち） よって、モンキーテストの価値が分かる1件となった。
冒頭に貼ったレポートが一晩回した結果になる。ソフトロック候補なし、危険な暗転なし、新規のゲームバグは実質ゼロ件。到達したマップは累積31種。
「落ちた」が2件出ていたので調べたが、これもゲームのバグではなかった。キー入力を送り込む側が仮想デスクトップに繋がらず、1回もキーを送らないまま30分放置されていただけである。テスト基盤の不具合が「バグ発見」として報告されるのは自動テストあるあるなので、異常が出たら元のデータを見に行くようにしている。
これが現状の最大の問題。
到達したマップは31種と書いたが、ラウンドごとの新規到達を追うと、序盤で6つ4つと増えたあとは0が並ぶ。後半の6ラウンド、3時間ぶんで新しく踏んだマップは1つしかなかった。
しかも中身が問題で、Vol.11 のために新しく作ったマップは6枚あるのに、そのうち1枚にしか到達していない。残り30マップは共通の拠点部屋やメニュー、クエスト選択画面。ランダム入力は本編の奥にまったく届いていない。
考えてみれば当たり前だった。Vol.11 の開始時点から始めた場合、まず開始イベントの会話シーンを抜ける必要がある。ランダム入力ではここだけで相当な時間を食ってしまうので、クエスト本体まで辿り着かない。運よく辿り着けたとしても、今度はバトルがある。ランダムに叩いてバトルをクリアできることは、ほとんどない。
モンキーテストで見つかるのは入口付近の壊れ方だけ。「新規バグ0件」も、正確には「モンキーが届く範囲には新規のバグが無い」でしかない。
対策は2つ考えている。ひとつは開始地点を増やすこと。手動プレイなどで途中のセーブを細かく取っておき、毎回その中からランダムに選んで始める。確実だが、セーブを人力で用意する手間がかかるうえ、イベントを直すたびに作り直しになる。
もうひとつは前のラウンドのセーブを引き継ぐこと。30分ごとに区切って走らせているので、そのラウンドが終わった時点のセーブを次の開始地点にすれば、うまくいけば少しずつ奥へ進む。全部自動で済むが、モンキーが自力で進める範囲までしか行けない。
まずは後者を試して、届かないところを前者で補う。
冒頭に書いたとおり、この環境の実装はほぼ全て Claude Code に任せている。3,000行ほどのプログラムも EasyRPG Player の改造も、自分では書いていない。
モンキーテストを動かすこと自体に Claude は関わっていない。夜間の実行も異常の判定も朝のレポートも、あらかじめ組んだスクリプトが動いているだけ。一度出来上がってしまえば、Claude を起動しなくても毎晩勝手に走る。
Claude が要るのは、環境そのものを作るときと、出てきた結果を検証するとき。レポートに出た怪しい判定を追いかけて原因を突き止めるところは判断の連続なので、人間か Claude が要る。 が、人間がやってられる作業ではないので、ここはAIが無いとキツい所。
Claude Code は有料で、私は動画制作でも使うので Max5x のプランに入っている。Proでもこれだけなら充分だと思う（が、もちろん未検証）。
実装と調査と実測はぜんぶ Claude にお任せ。「そもそも出来るのか？」の確認からすべて。
自分で決めたのは、何を作るかという方針そのものと、ゲームの原本を触らない・セーブを作り置きしないといった運用のルール、そして測った結果を見ての判断。 ざっくり「どういう技術を組み合わせればできるのか」さえ分かっていればこの手の物は作れる。
個人開発で一番ネックになる、テストプレイの物量が足りない問題に対して、特効薬とまではいかないがある程度効く物が作れたので満足している。 現に致命的なバグが見つかったのは大きい。
スクリプト経由でのプレイが出来るようになったので、Claude による自動プレイもやりたかったのだが、残念ながら時間切れとなった。 もう少し詳しく話すと、自動プレイ自体は動いたが、キー入力の挙動による誤操作の多発だったり、AI側がゲームシステムを理解できずに阿呆な行動を繰り返す問題があったり（これは私がモデルをケチってるのが悪いんだけど……）で、なかなかうまく動かない。 また暇があったら試す予定。
とはいえ土台はできた。操作を送る、画面を見る、中を覗く、同じことをもう一度起こす。この4つが揃っていれば、あとは「次に何を押すか」を決める部分を差し替えるだけでいい。
まともに動いたら、また記事にする予定。