1993年、イラクのバグダッド。20代の工学部生が、テレビにつないだ小さなパソコンでゲームを作りました。名前は「Babylonian Twins」。使った機械はAmiga 500。メモリは512KB、ハードディスクなし。中身は、機械にいちばん近い言葉（68000アセンブリ＝かんたんに言うと、部品に一つずつ命令を出す書き方）で書かれた72,758行でした。
それから33年。作者のRabah Shihabさんは、そのゲームを今の環境へ作り直しました。ただし、古いコードを読んで移し替えたのは本人ではありません。AIです。7月の連休、夜22時23分から翌朝2時15分までの記録が、そのままブログに残っています。
この記事では「AIがどこまでやれたのか」と同じくらい、「どこで失敗したのか」を見ます。そのうえで、あなたの仕事に持ち帰れる形にします。
※2026年9月時点の情報です。内容は作者本人のブログ（2026年9月1日公開）の記述に基づきます。
33年前のゲームが、なぜ「AIの実力テスト」になったのか
まず、この話に出てくるコードは3種類あります。ここが分かると全部スッキリします。
- 1993年のオリジナル：68000アセンブリで72,758行
- 2010年のiPhone版：チームが自作したエンジンでC++約34,000行
- 2026年の新しい版：Godot 4（＝かんたんに言うと、無料で使えるゲーム制作ソフト）で作り直したもの
作者はこの移植を、わざと3段階に分けました。しかも「前の段階が成功したら次に進む」という条件付きです。
第1段階は「安全な依頼」。自分が2010年に書いたC++約34,000行を、Godot 4へ移すこと。これは腕試しの基準線です。
第2段階は「無茶な依頼」。1993年の68000アセンブリ72,758行を、Godot上でゼロから組み直すこと。しかも当時と同じ速さ（1秒に50回更新）で動かすこと。作者いわく、このコードには説明書きがほとんどありません。C++版とも共通点がありません。
第3段階は「欲張りな依頼」。第2段階を第1段階の中に入れ込むこと。つまり、今のゲームを買うと1993年版もおまけで起動できる、という形です。
作者によれば、3つとも成功しました。
なぜこれが「AIの実力テスト」なのか。作者の狙いがはっきりしています。Amigaのアセンブリは、AIが学んだ資料の中にほとんど無いはずだ、と踏んだのです。
たとえるなら、参考書に載っていない問題を出すようなものです。暗記で答えられるなら見抜けない。でも「その場で考える力」なら、ここでこそ差が出る。作者はそう考えて、同じ素材をもう一度AIに渡しました。
一晩で34,000行が動いた。タイムスタンプが生々しい
第1段階は水曜の夜に始まりました。作者がブログに載せた記録は、手を加えていない生の時刻です。
| 時刻 | 起きたこと |
|---|---|
| 22:23 | Godot 4のプロジェクトの土台、素材の同期、レベルの読み込み経路ができる |
| 22:44 | 双子キャラが2人とも動く。当たり判定、物理、カメラ、切り替えまで |
| 23:19 | 38種類ある登場物すべてを移植 |
| 00:35 | メニュー、マップ、ストーリー、セーブなど画面の流れが全部つながる |
| 02:15 | macOS、iOS、Android向けに書き出し |
空っぽのプロジェクトから、キャラが操作できるまで21分。ここに移された行は、すべて作者が2010年に何か月もかけて書いた行です。
作者は「混乱したまま寝た」と書いています。正直な感想だと思います。
ただし、ここで終わりではありません。「手触りが正しいか」を合わせるのに、そのあと約3日かかっています。ジャンプの弧の描き方、トランポリンのタイミング、ボタン連打が報われる当たり判定。7月2日・3日・4日に、まとめて直していきました。
ここが大事なところです。動くまでは一晩。気持ちよく遊べるまでは3日。 この差は、AIに仕事を任せるとき必ず出ます。
去年は解けなかった問題が、今年はヒントなしで解けた
作者は、この挑戦を1年ほど前にも試しています。同じAmigaの素材を、当時の古い世代のモデルに渡しました。
お願いしたのは「バイナリのレベルマップを読み解いて」ということ。バイナリ＝かんたんに言うと、人間が読めない数字の羅列です。ステージの地形が、どんなルールでその数字に詰め込まれているか。それを当てさせたわけです。
そのときは、最終的には解けました。ただし何回もやり取りが必要でした。作者からのヒントもたくさん要りました。
そして今回、Claude Fable 5に同じファイルを渡しました。結果は、作者のヒントなしで、1回のパスで解けた。1年前に何ラウンドも要した形式が、一発で出てきたのです。
同じ素材、同じ質問。違うのはモデルだけ。だからこの比較は分かりやすいのです。
AIに「自分で答え合わせ」をさせた仕組み
ここが、この事例で一番マネできる部分です。
作者はAIをClaude Codeで動かしました。つまり、ターミナル（＝文字で命令を打つ画面）とファイルを触れる状態です。AIは、ファイルを書き換え、変換の道具を動かし、ゲームをビルドして起動し、返ってきた文字を読むところまでやりました。
ポイントは「人間が見に行かなくても、AIが結果を確認できる形」を先に作ったことです。
ゲーム側に「機械が読める操作口」を付けた
AIは早い段階で、ゲームに起動オプションを追加しました。人が遊ばなくても、ゲームを検証できるようにするためです。
--level=<名前>… 指定したステージを直接読み込む--pose=<指定>… 双子を好きな座標に置く--drive=<指定>… ボタン操作を台本どおり、1コマずつ押す--probe… スイッチ・門・扉・鍵の状態を吐き出す--screenshot=<パス>… 1コマ描いて終了する
これで何が変わるか。「ジャンプの感触は正しい？」という曖昧な問いが、こういう機械が読める1行になります。
drive[btw_jump:2.2] pos=(25.44, 24.04) vel=(0.00, -14.51) ground=false apex_y=22.48
さらに、人に見せる前に必ず走る自動チェックを2つ用意しました。ひとつは全スクリプトがちゃんとコンパイルできるか。もうひとつは全ステージがビルドできて、失敗があれば報告すること。画面を出さずに走らせる（ヘッドレス）ので、速いです。
1993年側はもっと徹底しています。vasm（アセンブリを機械語に変える道具）で組み立て直し、出てきたファイルを当時のファイルと差分比較しました。そのうえでFS-UAE（昔のAmigaをパソコン上で再現する道具）で実際に起動させています。AIが本物の道具を回して、自分の答えを検算したわけです。
中級者向け：ここで踏み抜きやすい落とし穴
ひとつ、地味だけど怖い話があります。
オリジナルは、地面を走るときの摩擦をこう書いていました。
static const float GROUND_DRAG_FACTOR = 0.85f;
this->velocity.x *= GROUND_DRAG_FACTOR; // every tick!
毎コマ、速度に0.85を掛ける。それだけです。
でも、1秒に60回掛けるのと、50回掛けるのとでは、結果がまったく違います。掛け算が積み重なるからです。
だから更新の速さを変えて移植すると、ゲーム中のあらゆる加速の曲がり方が変わります。エラーは1つも出ません。落ちもしません。ただ、永遠に手触りが変です。 しかも差分を眺めても見つかりません。
今回の移植では、新しい版は1秒60回に固定しました。2010年のiOS版が60回だったからです。だから0.85という数字がそのまま使えます。一方、1993年の再現版は50回のまま動かしています。手で調整された数字は、その速さでだけ正解だからです。作者は「自分なら1つに揃えたくなっていた」と書いています。AIは2つの時計を分けて残しました。
同じ理由で、プレイヤーの動きにGodot標準の部品（CharacterBody2Dやmove_and_slide）は使っていません。オリジナルは自前の移動処理を持っています。それを他人の物理エンジンの上に載せ直すと、微妙にズレて、原因追跡が地獄になる。だからプレイヤーはただのNode2Dにして、150行の当たり判定を1行ずつそのまま持ってきました。15年前に感覚で決めた微調整の数字も、未来の自分に向けて書いたコメントも、丸ごとです。
古い数字を「きれいに整える」誘惑に勝つ。移植でいちばん効くのは、この一点です。
自動化しなかった部分に、失敗が残った
ここを飛ばして読むと、この事例は誤解されます。作者は正直に、穴を書いています。
自動化されなかったのは2つ。
1つ目は画像の比較です。新しい移植版には、画面を機械同士で見比べる仕組みがありません。スクリーンショットは撮りましたが、見たのは人間の目です。
2つ目は「手触りが正しいか」の確認です。これを判定する仕組みは、そもそもありませんでした。
そして作者はこう書いています。数週間たってから腰を据えて、自分のゲームに何がされたのかを読み返した。一部は間違っていて、数週間気づかなかった、と。
これはAIの敗北談ではありません。「答え合わせの仕組みを作らなかった場所に、間違いが溜まる」という話です。逆に言えば、vasmで組み直して差分を取った1993年側は、機械が検算できたので早く確定しました。
なお、この移植は個人の趣味では終わっていません。1993年当時のディスクはitch.ioで無料公開され、作り直した「Definitive Edition」はiOSとAndroidで配信中、今秋にはSteamにも来ると書かれています。2010年のiPhone版は200万ダウンロードを超えました。
余談ですが、毎回のビルドを一緒に遊んだのは作者の13歳の息子さんだそうです。父が作ったゲームだと知ってはいたけれど、作っている姿は見たことがなかった。テストが親子の時間になった、と書いています。
日本の読者は、これをどう真似るか
古いゲームを持っていなくても、この型はそのまま使えます。カギは1つだけ。
AIに仕事を渡す前に、「合ってるかを機械が判定できる入口」を作らせる。
たとえるなら、家庭教師に丸投げする前に、答えのある小テストを用意しておくようなものです。テストが無い科目だけ、後から成績が崩れます。
まずはこれをコピーして使ってください。
これから頼む作業に取りかかる前に、まず「検算のしかた」を設計してください。作業自体はそのあとです。 前提 ・作業の内容：〔ここに頼みたいことを書く〕 ・正解に近いと言える状態：〔どうなっていれば成功かを書く〕 ・今ある材料：〔既存のファイル、データ、画面、旧バージョンなど〕 やってほしいこと 1 この作業のうち、機械が○×を判定できる部分と、人間しか判定できない部分に分けて一覧にしてください。 2 機械が判定できる部分について、コマンド1つで走る確認手段を作ってください。実行して結果の文字が読める形にしてください。 3 旧バージョンや既存データと突き合わせて差分を出せる場合は、その差分の取り方を先に決めてください。 4 人間しか判定できない部分は、私が見るべき箇所を一覧にしてください。あなたは判定しないでください。 5 ここまでの計画を私に見せて、承認をもらってから作業を始めてください。 禁止事項 ・確認手段が無いまま「できました」と報告しないこと ・元の値や設定を、きれいに見せるために勝手に整えないこと。変えたい場合は理由を添えて提案だけすること 業種別の穴埋め例を2つ出します。〔 〕を埋めるだけで動きます。 **例1：ECの在庫発注** ・作業の内容：〔過去2年の販売実績から、毎週の発注数を計算する仕組みを作る〕 ・正解に近いと言える状態：〔去年の同じ週に当てはめたとき、欠品と過剰在庫が今の運用より減る〕 ・今ある材料：〔販売実績CSV、現在の発注ルールの一覧、仕入先ごとの納期表〕 **例2：問い合わせの一次対応** ・作業の内容：〔よくある質問への返信文をAIが下書きする仕組みを作る〕 ・正解に近いと言える状態：〔過去の問い合わせ100件に対して、担当者が手直しなしで送れる下書きが出る〕 ・今ある材料：〔過去の問い合わせと実際の返信ログ、社内FAQ、送ってはいけない表現の一覧〕
出てきた計画を、5点満点で採点する
AIが出した検算の計画は、次の5項目で見てください。低かったときの打ち手も並べます。
| 項目 | 見るところ | 低かったときの打ち手 |
|---|---|---|
| 判定の自動度 | 人が見ないと分からない項目が多すぎないか | 「この項目を数字で出す方法を3案ください」と追加で聞く |
| 突き合わせ相手 | 旧版や実績データと比べる形になっているか | 「去年の実績に当てはめて再現できるか試して」と指示する |
| 一発で走るか | コマンド1つで確認まで終わるか | 「手順をまとめて1つのスクリプトにして」と頼む |
| 変更点の申告 | 勝手に値を整えていないか | 「元の値から変えた箇所を全部一覧にして」と毎回言わせる |
| 人が見る範囲 | 私が見るべき箇所が絞れているか | 「私の確認を10分で終わらせる一覧に削って」と圧縮させる |
そして、この事例からもう1つ持ち帰ってください。「手触り」「読みやすさ」「なんとなく変」の判定は、まだ人間の仕事です。 そこだけは、AIに任せた気になってはいけません。作者が数週間気づかなかったのも、まさにそこでした。
まとめ：今日・1週間・1か月でやること
今日（30分） いま抱えている仕事を1つ選び、紙に2列で書き出してください。左に「機械が○×を判定できること」、右に「人間しか判定できないこと」。この線引きだけで、任せ方が変わります。
1週間（1〜2時間×3日） 上のプロンプトを使って、AIに検算の計画を先に作らせてください。作業そのものは、計画を承認してから始めます。5項目の採点表で1回は突き返すこと。最初の計画は、だいたい人任せの項目が多すぎます。
1か月 「1コマンドで走る確認」を、自分の定番業務に1本だけ組み込んでください。全部やろうとすると続きません。1本でいいので、毎回必ず走る状態にする。そこから先、AIの出力を信じられる範囲がじわじわ広がります。
33年前のバグダッドで、512KBのメモリと1冊のハードウェア解説書だけで作られたゲームが、今また動いています。すごいのはAIの速さだけではありません。答え合わせの仕組みを、先に用意した人がいたことです。それは、今日のあなたの仕事でもまったく同じです。
