AIに40年前のゲームを作らせたら、「遊ぶ前から詰んでいた」

どうもです！えむしんです！
最近、コーディングエージェントが熱い。

指示を出すと、AIが自分でファイルを作り、コードを書き、動かして、間違えたら直す。数年前まで「コードの続きを予測してくれる便利な入力補完」だったものが、今は勝手にプロジェクトを一つ完成させて帰ってくる。

これは記事にするしかないでしょう、というわけで書きます。

やったことは単純です。同じお題を、4つのAIに出しました。

たったこれだけ。仕様書も、素材も、参考コードも渡していません。

ロードランナーというゲーム

知らない方のために。1983年、Apple II というパソコン向けに発売されたアクションパズルです。作者は Douglas E. Smith、当時ワシントン大学の学生でした。日本ではファミコン版が猛烈に売れたので、そちらの記憶がある方も多いと思います。

ルールはとても簡単です。

• 金塊を全部集めて、地上へ脱出すればクリア

• 敵に触れたらアウト

• プレイヤーは足元のレンガを掘れる

この3つが全てです。ジャンプも攻撃もできない主人公にできるのは、穴を掘ることだけ。追ってくる敵を穴に落とし、レンガが元に戻る前にその上を走り抜ける。うまくやれば、敵は穴の中で生き埋めになります。

40年前のゲームで、ルールは3行で説明できる。だから「AIに作らせる課題」としては簡単な部類に見えました。

使ったAIたち

今回使ったのは4つ。

Claude Opus 4.8（Anthropic） 今回のメイン。「工数最大」——つまり、答える前にどれだけ深く考えるかの設定を、一番上まで振り切って使いました。

Claude Fable 5（Anthropic） 同じ Anthropic の別モデル。以前このお題を出したとき、たった1回の指示で最後まで作り切りました。

Grok 4.5（xAI） イーロン・マスクの会社のAI。2回試しました。

GPT 5.6（OpenAI） ChatGPT の会社のAI。こちらは完成に至りませんでした。理由は後で書きます。

Opus 4.8 が1時間で作ったもの

先にお見せします。これが成果物です。

• ステージは全5面。手描きのドット絵は一枚も使っていません（全部プログラムで図形を描いています）

• レンガを掘る、穴に落ちる、敵を生き埋めにする、ロープにぶら下がる

• 金塊を全部集めると、光る脱出ハシゴが現れる

• 効果音も、音声ファイルなしでその場で合成

• スマホのタッチ操作にも対応

完成まで、約1時間。 その間に私がやったのは、最初のお題を出したことと、途中で何度か「ここがおかしい」と伝えたことだけです。

面白いのは、この1時間の使い道でした。Opus 4.8 は、ゲームを書き終えてもブラウザを開きませんでした。代わりに「このゲームは本当にクリアできるか」を機械的に調べるプログラムを先に書いたのです。

そして、そのプログラムが見つけました。

ステージ1が、クリア不能でした。

どういうことか、順を追って説明します。
このゲームのステージは、文字を並べて作られています。# がレンガ、H がハシゴ、$ が金塊。空白は、何もない空間です。
問題は、ステージの中ほどにある床の1行でした。

###### ######H####### ######
      ^              ^

ぱっと見、レンガの床が横一直線に続いているように見えます。でもよく見ると、^ を付けた2箇所だけ、レンガが1マスずつ抜けています。
ここで思い出してください。ロードランナーの主人公は、ジャンプができません。歩いていて隙間に差しかかれば、そのまま下へ落ちます。
つまりこの床は、つながっていない。3つの区画に分断されているのです。
そして主人公が下から登ってくるハシゴ（H）は、真ん中の区画にしか生えていませんでした。

• 左の区画 … 金塊が1個。行けない。

• 右の区画 … 脱出ハシゴ。行けない。

• 上の階 … 金塊が3個。登るハシゴは左右の区画にしかないので、行けない。

• 真ん中の区画 … 主人公は、ここから一生出られない。

金塊を4個取り逃したうえ、出口にも届かない。完璧な詰みです。
しかも意地の悪いことに、遊んでいる分には何も壊れて見えません。レンガも金塊も普通に表示され、主人公は元気に走り回ります。ただ、クリアできないだけ。
ステージは28文字×16行、448マスあります。そのうちの空白2マスが、ゲームを成立させなくしていました。
これを目で数えて見つけるのは、困難です。だから、ツールを作って検査させた。

私が見つけたバグ

とはいえ、機械の検査も万能ではありませんでした。

遊んでいて、こうなったんです。

画面上の金塊を全部取ったのに、脱出ハシゴが出ない。

どこを探しても金塊は無い。なのにクリアできない。完全に手詰まりに見えました。

原因を調べさせたら、こうでした。敵が金塊を拾って持ち歩いていた。

Opus 4.8 は、敵が金塊を拾う仕様を勝手に入れていました（本家にもある動きです）。持ち逃げされたぶんはまだ回収されていないので、クリア条件を満たさない。でもマップ上からは消えているので、プレイヤーからは「全部取った」ようにしか見えない。

しかも、もっと悪いことが埋まっていました。敵を生き埋めにしたとき、金塊の置き場所が見つからないと、その金塊が消滅するコードになっていたのです。1個でも消えたら、そのステージは永久にクリアできません。

これは検査プログラムをすり抜けていました。人間が遊んで、初めて見つかった。

（今は直っています。敵を穴に落とすと、金塊を穴のふちに吐き出します）

そして、他の3つ

さて、ここからが本題です。

4つのAIが作ったゲームは、どれもスクリーンショットでは完璧に見えます。 レンガが並び、ハシゴが立ち、金塊が光り、赤い敵が追いかけてくる。並べて見せられたら、どれも「できている」と答えるでしょう。

そこで、Opus 4.8 が自分のために書いた「本当にクリアできるか」の検査を、他の3つの成果物にもそのまま当ててみました。

結果はこうです（Grok は2回試したので、成果物は全部で5つあります）。

 Opus 4.8    5面   →  合格
 Fable 5     3面   →  合格
 Grok 4.5 ①  5面   →  全滅（金塊に届かない）
 Grok 4.5 ②  3面   →  全滅（金塊に届かない）
 GPT 5.6     1面   →  ※後述

5つのうち3つが、遊ぶ前から詰んでいました。

Grok 4.5 が作ったステージ1です。記号は先ほどと同じに揃えました（# レンガ、H ハシゴ、$ 金塊、P あなた、E 敵、| は壊せない壁）。

|        $                   |   ← 金塊
|       ###                  |   ← それを支える3枚のレンガ
|             H              |   ← ハシゴの てっぺん
|     $       H              |
|    ####     H     $        |
|             H   ####       |
|   P         H              |   ← あなたはここ
| #####       H              |
|             H        E     |
|             H      ####    |
|             H              |
|############################|   ← 地面

ハシゴは、真ん中に1本きり。まずここを登ります。

登り切ると、H のてっぺんに立てます。でも、そこから先がありません。

左を見てください。金塊を載せた3枚のレンガは、周りが全部すきまです。宙に浮いた島になっている。ジャンプができない主人公は、ハシゴのてっぺんから左へ一歩踏み出した瞬間、下まで落ちます。島の横に着地することすらできない。

上からも行けません。ハシゴは島より下で終わっているので、島の真上に立つ手段がない。

下からも行けません。掘れるのは自分の足元の斜め下だけです。頭上のレンガは掘れない。

つまりこの金塊は、どこからも触れない場所に置かれています。他の2個も同じでした。3個とも取れないので、脱出ハシゴは永久に出てきません。

地形図としては綺麗です。ゲームとしては成立していません。そして5面すべてが、同じ作りでした。

GPT 5.6 のほうは、もっと不思議なことになっていました。主人公に重力がありません。 崖から歩き出しても落ちません。キーを押さなければ、空中に立ったままです。

さらに、敵は3体いるのに、あなたを殺せるのは1体目だけ。残り2体は、触れてもすり抜けます。

そして決定的なのは、穴に敵を落とす概念が、そもそも存在しないこと。掘った穴は「ただの通り抜けられるマス」で、敵は素通りしていきます。掘っても、敵は絶対に倒せない。

このゲームの中心にある行為が、機能として無いのです。

なぜ GPT 5.6 は完成しなかったのか

能力の問題ではないと思います。時間の使い道でした。

GPT 5.6 が作ったフォルダを開くと、こうなっていました。

GoldMiner/

├── app/page.tsx 173行 ← ゲーム本体は、これだけ

├── worker/ 　 Cloudflare のサーバー設定

├── db/ 　 データベース設定

├── drizzle.config.ts 　 データベース設定

├── vite.config.ts 　 ビルド設定

├── next.config.ts 　 フレームワーク設定

└── dist/ 　 ビルド結果

Webアプリを本格的に運用するための足場が、隅々まで組んであります。データベースまで用意されている。

ロードランナーに、データベースは要りません。

AIには「一度に考えられる量」の上限があります。GPT 5.6 は、その上限のかなりの部分を、ゲームではなく足場を組むことに使ってしまった。ゲーム本体にたどり着く前に、息切れした。

一方 Opus 4.8 が作ったものは、ファイルをブラウザで開くだけで動く、部品ゼロの静的なファイルの集まりです。余計なものを作らなかったぶん、全部をゲームのルールに使えました。

いちばん面白かった話

Opus 4.8 が最初に書いた敵は、穴に落ちても素通りしていきました。

なぜか。プレイヤーは掘った穴を通り抜けて下の階へ降りていきます。当然です、穴なので。だから同じ物理法則で敵も落とした。筋が通っています。

でも、それだとゲームが成立しない。敵が捕まらないので、掘る意味が消える。

本物のロードランナーのルールは、気持ち悪いほど非対称でした。

同じマス、同じ物理で、違う結果が起きる。プログラムとして「正しく」「一貫して」書こうとすると、絶対にこうはなりません。遊びの側から逆算して、無理やり押しつけるしかないルールなんです。

1983年に、誰かが同じ壁にぶつかって、同じ結論に至ったはずです。

（※ 正直に書いておくと、この非対称が本家1983年版の仕様である、という点は原典のコードで確認したわけではありません。根拠は「単層のレンガ床でも敵は穴に嵌まったはずだ」という遊びの記憶だけです。ちなみに Fable 5 は逆の設計を選んでいて、そちらが正しい可能性もあります。詳細版に注記を書きました）

40年経ってコンピュータが何万倍速くなっても、この難しさだけは1ミリも減っていない。難しさはコンピュータの都合ではなく、ゲームデザインの側にあったからです。

まとめ

コーディングエージェントは、たしかに熱いです。1時間で、40年前の名作の骨格が、5ステージぶん立ち上がりました。

でも今回いちばん学んだのは、そこではありませんでした。

「見た目が完成している」ことと、「成立している」ことは、まったく別だ。

Grok 4.5 の8ステージも、GPT 5.6 の1ステージも、スクリーンショットは完璧です。レンガが並び、ハシゴが立ち、金塊が光っている。ただ、取れないだけです。遊んでみるまで、誰にも分からない。

そして「バグがなかった」のか「まだ誰も踏んでいないだけ」なのかも、遊んだだけでは区別がつきません。実際、金塊が消えるバグは、検査プログラムをすり抜けて、私が遊んで初めて見つかりました。

測る道具を先に作ったAIだけが、自分の失敗に気づけた。 それが、今回いちばん腑に落ちたことでした。

▶ 遊んでみてください

矢印キーで移動、Z と X で左下・右下を掘ります。ステージ4は、掘らないと絶対に解けません。

技術的な詳細（どうやって検査したのか、各実装のコードのどこが問題だったのか）は、こちらにまとめてあります。

Fable 5 が1回の指示で作ったものは、こちらで遊べます。素直に、いい出来だと思います。

※ 各モデルへの指示の細かさや試行回数は揃えていません。厳密な比較実験ではなく、「同じお題を投げてみた記録」として読んでください。

また、新しいモデルが登場したら試してみます！
ではでは。