AI147体を1人で操縦。24日で3DS移植を完走した全手順

「24日で1人＋AIが、ゲーム機1台を丸ごと動かした」

あなたが今日ひとりで抱えている仕事を思い浮かべてください。人手が足りない。時間もない。だから諦めている案件が、たぶん1つはあるはずです。

海外の個人開発者が2026年9月3日、こんな報告を公開しました。ニンテンドー3DSでレースゲーム『F-Zero X』を動かすという大仕事を、Claude Code（＝かんたんに言うと、指示を出すと自分でコードを書いて動かすAI）を使って24日で終わらせた、と。動かしたAIの分身は147体。かかった日数は実働15日。しかも最後は1秒60コマ、立体3Dで遊べるところまで到達しています。

すごいのは結果より「やり方」です。この人は、AIを賢く働かせるための仕組みを全部あとから文章で公開してくれました。そこが、あなたの仕事にそのまま持ち帰れます。

※本記事は2026年9月時点の情報です。数値はすべて作者本人が公開したポストモーテム（＝振り返り記録）に基づきます。

まず数字だけ見てほしい

盛った話ではないことを、先に数字で確認します。すべて公開記録の値です。

そして、いちばん大事な「なめらかさ」の推移です。

• 8月14日 はじめてレースが動く（パソコン上のニセ3DS＝エミュレータ）：1秒12〜20コマ
• 8月21日 はじめて本物の3DS実機で起動：48〜50コマ
• 9月2日 改善キャンペーン前：中央値51.3コマ
• 9月3日 最終ビルド：中央値59.6コマ、重い場面でも51.4コマ

60コマが上限なので、59.6はほぼ理想値です。「60コマに届いた瞬間の割合」は1週間前の14%から53%へ跳ね上がりました。

たとえるなら、パラパラ漫画が1秒12枚のカクカクから、1秒60枚のヌルヌルになった、ということ。これを24日でやったんです。

AIの分身147体を、どうやって働かせたのか

ここが本題です。147体を同時にワイワイ動かした、わけではありません。構造がありました。

中心にいるのは1つの司令塔セッション。プロジェクトの最初から最後まで生き続けた、たった1本の会話です。分身たちはこの司令塔から仕事をもらい、結果を司令塔に返します。分身が人間に直接話しかけることはありません。原文にはこうあります。

Agents never talked to the user; the orchestrator relayed. （分身はユーザーと直接話さない。司令塔が中継した）

なぜ分けるのか。全員が人間に話しかけたら、あなたが147通の報告を読む係になってしまうからです。窓口はひとつ。これだけで負担が桁違いに変わります。

もうひとつ大事なのが作業場所を分けたこと。96個の複製フォルダを用意して、分身1体につき1つを割り当てました。同じ部屋で147人が同時に工作すると、道具を取り合って壊し合います。実際このプロジェクトでも、初期に分身同士が互いの成果物を消してしまう事故が起きています。

そして司令塔だけが持っていた3つの役目が、記録にはっきり書かれています。

• 記憶を持つ：591行のメモ書きファイルを、節目ごとに更新し続けた
• 指示書を書く：分身に渡す作業依頼を、毎回同じ形式で作った
• 落ちた仕事を拾う：AIが途中で力尽きて止まったとき、残りを人間側が引き継いだ

3つ目、地味ですが本質です。AIは途中で止まります。止まる前提で、拾う人を決めておく。それが司令塔の仕事でした。

「AIには見えないもの」を、人間が36回運んだ

このプロジェクトが特別なのは、AIが成果を自分で見られなかったことです。

普通のWebサービス開発なら、AIはテストを走らせて自分で合否を確認できます。でも今回の相手は3DSという実物の機械。AIはそこに手が届きません。だから人間が動きました。

やり方はこうです。ビルドしたゲームをSDカードに入れる。3DSに挿して実際に遊ぶ。動きの記録を取り出す。それをAIに返す。この往復が、記録上36回あります。

The user ran the SD-card loop dozens of times... Those reports were the only ground truth. （ユーザーはSDカードの往復を何十回も回した。その報告だけが唯一の真実だった）

さらに人間は、数字に出ない部分の判定役もやりました。「色がおかしい」「一瞬カクつく」「操作の感じが重い」。これは測定器ではなく人の目にしか映りません。

あなたの仕事に置き換えるとこうです。AIが自分で確認できない部分は、必ず人間が確認ルートを作る。メールの文面なら実際に届いたものを読む。在庫の発注なら実際の倉庫の数を見る。ここを省くと、AIは「たぶん大丈夫です」と言い続けます。

失敗から生まれた6つのルール（ここが一歩踏み込んだ話）

作者は、痛い目に遭ってからルールを足していきました。原文の対応表がそのまま実用的です。

1. 変更は「差分だけ」で書く — 別々のAIが出した変更がぶつかり、同じ修正が二重に入った事故から
2. すべての機能にオフにできるスイッチを付ける — これがないと、どの変更が効いたのか比べられない
3. すべての作業に「証拠」を残させる — 黙って動いたAIの成果が、別のビルドの手柄にされていた
4. 早めに保存させる — 力尽きたAIが、1つも保存せず全部消えたことがある
5. 道具の取り合いを防ぐ鍵を作る — 動作確認用ソフトを1体ずつ順番に使わせる仕組み（30秒ごとに札を更新して順番待ち）
6. 設定ファイルは上書きではなく合体させる — 上書きのせいで立体3Dが黙って無効のまま出荷された

中級者のあなたに刺さるのは、たぶん2番と6番です。

2番の「オフにできるスイッチ」は、効果測定の生命線です。AIに5個の改善を同時にやらせると、良くなっても悪くなっても原因が分かりません。1個ずつオフにできれば、犯人はすぐ割れます。

6番は本当に怖い落とし穴。AIは設定ファイルを丸ごと書き直しがちです。すると、あなたが前に入れた設定がエラーも出さずに消えます。「上書き禁止、既存の値は残して追記」と最初に書いておいてください。

日本のあなたが、今日から真似する方法

3DSは関係なくても、仕組みは全部使えます。核心は「指示書の型を決めて、毎回同じ形で渡す」ことです。作者も全依頼に共通ルールの塊をコピーして貼っていました。

そのまま使える型を用意しました。

あなたに1つの作業だけをお願いします。他のことはしないでください。

1. ねらい：この作業で何を良くしたいか
2. 場所：触ってよいファイル・シート・範囲（ここ以外は触らない）
3. 測り方：良くなったと判断する数字と、その測り方
4. 戻し方：この変更をオフにする手順を必ず用意し、名前を書く
5. 証拠：実行したコマンド、変更した箇所、前後の数字をすべて書き出す

共通ルール
・既存の設定は上書きせず、追記で残す
・作業のキリが良いところで必ず途中保存する
・自信がない箇所は勝手に決めず、判断待ちとして報告する
・私が確認できない部分は「確認できていない」と正直に書く

**穴埋め例1：EC在庫の発注**
ねらい＝欠品を減らす／場所＝発注数の計算部分だけ／測り方＝過去1か月の欠品件数／戻し方＝旧ルールに1行で戻すスイッチ／証拠＝商品ごとの新旧発注数の一覧。

**穴埋め例2：問い合わせの一次対応**
ねらい＝初回返信までの時間短縮／場所＝返信の下書き生成だけ（送信はしない）／測り方＝下書きをそのまま送れた割合／戻し方＝下書き機能をオフにする設定／証拠＝人が直した箇所の一覧。

渡した指示書がうまく回らないときの打ち手も1行ずつ置いておきます。

- **ねらいが曖昧だった** → 数字を1つだけ決め直す（例：欠品件数を月20→10件）
- **場所が広すぎた** → 触ってよいファイルを1つに絞る
- **測り方が無い** → 先に「測るだけ」の作業をAIに1回やらせる
- **戻し方が無い** → 実装前に戻す手順だけ書かせて、それを承認してから進める
- **証拠が薄い** → 「実行ログ全文を貼れ」と明記する

作者本人が感じた「怖さ」

最後に正直な話を。作者はニュース掲示板の投稿で、こう書いています。「大きなプロジェクトでAIをどう導くかをかなり学んだ。でも同時に、かなりの恐怖も感じた」と。

すごいものが作れた興奮と、これができてしまう時代への戸惑い。両方が同居しています。この感覚を隠さず書いているところが、この記録の信頼できるところだと思います。

まとめ：今日・1週間・1か月でやること

今日（30分） 上の指示書テンプレをコピーして、いま抱えている作業1つに当てはめてみる。「測り方」と「戻し方」の2行が書けたら、それだけで合格です。

1週間 AIの成果を人間が確かめる往復ルートを作る。誰が、どこで、何を見て合否を出すか。この人が36回SDカードを運んだのと同じ役目です。1日1回でも構いません。

1か月 うまくいった指示書と失敗パターンを1つのメモファイルにまとめ、AIに毎回読ませる。作者は591行まで育てました。あなたのメモも、育つほど強くなります。

24日で1人がゲーム機1台を動かせた理由は、AIが賢いからだけではありません。測って、戻せて、記録が残る仕組みを人間が作ったからです。その部分は、今日のあなたの机の上でも、そのまま真似できます。