Opus 5.5 にロードランナー風ゲームを作らせたら、検証は「頼まれてから」だった

どうもです！えむしんです！

前回の記事では、Opus 5 に「ロードランナー風のゲームを作って」と一行だけ頼んだところ、遊ぶ前に自分で検証ツールを書き、クリアできないステージを見つけて直してくれた、という話でした。

では、その次の世代はどうか。同じ一行を Claude Opus 5.5（Claude Code）に投げてみました。

指示は一行だけ

空のフォルダで、前置きなし、仕様なし。途中で一度セッションが中断したので「再開」とだけ送っています。こちらから出した指示はそれで全部です。

できあがったもの：「金塊ランナー」

返ってきたのは index.html 1ファイルだけ。ブラウザで開けばそのまま遊べます。

• ドット絵のランナーと番人（10×10 ドットのスプライトをコードで描画）

• 全3ステージ（「第1坑 はじまりの坑道」「第2坑 隠し金庫」「第3坑 双子の塔」）

• レンガは掘れるが岩盤は掘れない。掘った穴は約6秒で埋まる

• 番人は穴に落ちると一定時間閉じ込められ、埋まると倒されて上から出直す

• 番人は金塊を拾って運び、穴に落ちたときに落とす

• 金塊を全部集めると隠し梯子が現れ、最上段に登ればクリア

• 3面を越えると2周目に入り、番人の足が速くなる

• 効果音（Web Audio）、スマホ用のタッチボタン

梯子の上で待ち構えて右下を掘り、番人を閉じ込めた場面です。

番人の追跡には、毎回プレイヤーまでの経路を幅優先探索（BFS）で求める処理が入っていました。重力・梯子・ロープの規則をそのまま探索の遷移に使っているので、ちゃんと梯子を回り込んで追いかけてきます。

実際に遊んでみると、ちゃんとゲームになっています。

違ったのは「検証」だった

前回の Opus 5 と一番違ったのはここです。

Opus 5.5 がゲームを作り終えるまでにやった確認は、ブラウザでの表示確認1回だけでした。画面が描画され、コンソールにエラーが出ていないことを見て、完成として報告しています。報告にも「3つの坑道すべてを最後までクリアできるかは、まだ実際に遊んで試していません」と正直に書かれていました。

前回のように、自分から検証ツールを書き出すことはありませんでした。

記事を書くと伝えたら、検証が始まった

面白かったのはその後です。前回の記事の URL を渡して「これを参考に記事を書きます」と伝えたところ、Opus 5.5 は記事を書く前にこう言いました。

そして、ゲーム本体の HTML からステージデータを読み出し、到達可能性を調べるスクリプトをその場で書いて実行しました。チェックしていたのは次の3点です。

1. 各行がちゃんと 28 マスあるか（マップの書き損じ）

2. スタート地点から、すべての金塊に到達できるか

3. 各金塊の位置から、隠し梯子が出たあとに最上段まで脱出できるか

移動の規則はゲームと同じで、「支えがなければ落ちる」「梯子のマスでだけ上に登れる」「ロープにはつかまれる」を反映しています。さらに「足元斜め下のレンガを掘って落ちる」動きも遷移に含めていました。

結果は、3面とも金塊30個すべてに到達でき、脱出もできる。前回のように「8割のステージが詰んでいた」ということはありませんでした。

「掘らないと取れない金塊」も検証した

第2坑「隠し金庫」には、壁で囲まれた部屋の中に金塊が2つ置いてあります。

####H##################H####   ← この床を掘って部屋に入る

H# $ $ #H ← 左右を壁で閉じた金庫

H#####@@@@@@@@#####H ← 掘れるのは両端の # だけ

H------------------H ← 床を掘って抜けると、このロープにつかまれる

Opus 5.5 は、同じスクリプトから「掘る」遷移だけを外したものを実行し、結果を比べていました。

L2 第2坑 隠し金庫: 到達不能=[[10,7],[19,7]] 脱出不能=[[10,7],[19,7]]

掘らなければこの2つは取れず、掘れば取れる。「掘らないと入れない部屋」が設計どおりに機能していることと、チェッカー自体が「掘る」遷移をちゃんと見分けていることを、同時に確かめたことになります。

スクショを撮ったら、検証ツールの死角が見つかった

ここで話は終わりませんでした。

記事用にスクリーンショットを撮ってほしいと頼むと、Opus 5.5 はヘッドレス Chrome をスクリプトで操作し、ゲーム内のデバッグ用ハンドルからキー入力を流し込んで「番人を穴に閉じ込める場面」を再現して撮影しました（1回目は自機が進みすぎて番人に捕まり、撮り直しています）。

そして、第2坑の全景を撮った画像を見て、こう報告してきました。

原因は、6行目の文字列でレンガの # を1つ数え間違え、梯子 H が1列左にずれていたことでした。左側の梯子から回り込めるので詰みにはならず、到達可能性だけを見ていた検証ツールは「ok」を出していたのです。

Opus 5.5 はマップを直す前に、まず検証ツールのほうに「1マスだけの梯子」「レンガ1枚で途切れた梯子」を検出するチェックを足しました。直す前のマップで実行して、ちゃんと引っかかることを確かめています。

NG  2. 第2坑 隠し金庫（金塊 10 / 番人 2）

- 1 マスだけの梯子 (22,6)

- レンガで途切れた梯子 (23,6)

そのうえでマップを直し、全面 ok になったことを確認してから撮り直しました。

前回の記事にも「検証ツールにも死角がある」という話がありましたが、今回はその死角を目で見て見つけ、同じ種類の間違いを次から機械で拾えるように道具のほうを育てた、という流れになりました。

考えたこと

前回の記事の結論は、「測る道具を先に作る」ことがモデルの世代として当たり前になりつつある、というものでした。

今回の Opus 5.5 は少し違って見えました。

• 完成時点では検証ツールを作らず、報告で「どこまで確認したか」と「どこは確認していないか」を分けていた

• 検証が意味を持つ場面（記事にする＝人に見せる）になった時点で、頼まれる前に検証を始めた

• 見つけた問題は、その場で直すだけでなく、次から検出できるようにチェックを足してから直した

一方で、梯子の書き間違いは作った本人が混ぜ込んだもので、最初の到達可能性チェックでは見逃していました。「詰みはない」ことと「意図どおりの地形になっている」ことは別で、後者はスクリーンショットという別の角度から見て初めてわかりました。

そして今回の検証も、見ているのは地形だけです。番人の動きや穴が埋まるタイミングまでは見ていないので、「番人に囲まれて実質詰む」ような状況は、実際に遊ばないとわかりません。

遊べる場所

▶ https://m4n-works.github.io/KinkaiRunner/

• 移動：← → ↑ ↓（WASD でも可）

• 掘る：Z（左下）/ X（右下）

• ポーズ：P ／ やり直し：R

• スマホでは画面下に十字キーと掘るボタンが出ます

公開にあたっては、外部へのリクエストを一切出さない作りにしています。フォント（DotGothic16）は使う文字だけに絞ってファイルに埋め込み、Cookie や localStorage も使いません。

ソースと検証ツールは GitHub にあります：https://github.com/m4n-works/KinkaiRunner

ではでは。