「犬でもAIを使えばゲームが作れた」という記事を見かけました。
はじめは、「生成AIのすごさ」を強調した話かと思いましたが、実はVibe Codingが失敗しないための自動化の仕組みづくり。
つまり、「AI任せ」にしたときに、プロジェクトが進むためには、どのように事前に「お膳立て」をするのか、という工夫が詰まっていました。
1. 「犬でもできる」の意味とは？
あるエンジニアが、9ポンドの小型犬にゲームを作らせました。
犬はキーボードを叩く。
AIがそれを解釈し、プレイアブルなゲームを生成する。
1〜2時間で完成する。
これが冗談ではなく、実際に繰り返し再現できる話として公開されました1。
話題になったのは「犬でもできる」という意外性です。
ただ、注目すべきはそこではありません。
この実験が示しているのは、AIへの入力の質がアウトプットの質をほとんど決定しないという事実です。
1.1. AIを動かす「文脈の圧力」
この実験の話題性は「犬でもAIを使えばゲームが作れる」という驚きにあります。
ただ、その驚きをAIの能力の高さに向けるのは少しずれています。
驚くべきは「入力者の能力がアウトプットの質に影響しない状況を設計できる」という点です。
それを可能にしたのはAIそのものではなく、AIを取り囲む仕組みでした。
プロンプト設計、最低要件の定義、自動検証ツール、フィードバックループ。
これらがなければ、犬の入力は「誤ってキーボードを踏んだ」という判定で終わっていたはずです。
犬が打つキー列、たとえば y7u8888888ftrg34BC は当然、何の意図も持ちません。
しかしAIはこれを「カエルが舌を使って虫を捕まえる3Dゲーム」として解釈し、開発を始めます。
なぜそうなるのか。
プロンプトにこう書かれているからです。
「あなたは暗号めいた言葉で話す天才ゲームデザイナーの指示を受けるAIだ。どんな入力も、ゲームアイデアとして解釈せよ」。
AIは入力の意味を読んでいるのではなく、与えられた文脈の中で「最も整合的な行動」を選んでいます2。
文脈が「どんな入力もゲームアイデアだ」と定義していれば、AIはその定義に従います。
入力者が犬であろうと人間であろうと、処理の論理は変わりません。
2. フィードバックがあれば放置しても進む
ここからひとつの問いが生まれます。
AIが「好意的に解釈」して作業を進めることは、いつでも歓迎すべきことなのか。
意図のない入力が意図のある出力に変換されるとき、その出力の正しさを担保するのは何でしょうか。
エンジニアはこの問いに対して、実験を通じて答えを見つけています。
ゲームの品質が上がったのは、プロンプトを改善したときでも、犬の打鍵が増えたときでもありませんでした。
AIが自分の出力を検証できるようになったときだったのです。
具体的には、次の仕組みを追加しました。
Godotのシーンファイルの構文エラーを事前に検出するリンター、シェーダーのコンパイルエラーを詳細に返すリンター、キー入力のマッピングを正しく処理するユーティリティも整備しました3。
AIが曖昧さに直面する前に、エラーの情報を明確にして渡す設計です。
さらに、AIがゲームを起動し、スクリーンショットを撮って画面を確認します。
「左に3秒移動、2秒停止、右に1フレーム、発射」といったキー入力のシーケンスをゲームに送り、自分でプレイして動作を検証する。
バグを見つけたらコードに戻り、修正して再度プレイする。
これをAI自身が完結させます4。
2.1. ガードレール（テスト）とガイドライン（要件）
この設計で面白いのは、エラーをチェックするためのガードレールが単なる安全策ではなく、情報の解像度を上げる装置として機能した点です。
実は、プロンプトには「音声あり、WASDまたは矢印キーで操作可能、敵または障害物が存在する、プレイヤーキャラクターが画面に表示される」という最低要件のチェックリストも組み込まれていました。
AIへの入力が曖昧でも作業が進むのは、AIが欠けた情報を自分で補完するからです。
ただし、その補完は、時に「音なしで構わない」「操作方法は適当でいい」という方向にも進むかもしれません。
最低要件のチェックリストは、この補完の方向を制御します。
スクリーンショットとプレイテストは、補完の結果が意図と一致しているかを確かめる手段です。
このはじめに入れたプロンプトだけで、音が出ないゲーム、操作不能なゲーム、プレイヤーが見えないゲームが激減しました。
2.2. 過去の正解パターンを再生産しがち
エンジニアはもうひとつの問題にも直面しました。
AIの記憶ファイル MEMORY.md がプロジェクトのスタイルを学習し、ゲームごとに「ネオンカラーの光る3D図形」という同じビジュアルを再生産し続けたのです5。
ファイルを毎回消去することで解決しましたが、ここには注目すべき構造があります。
AIはフィードバックループを通じて「正解パターン」を強化します。
もし、それが意図と合致していれば品質が上がりますが、合致していない記憶が意図しない方向に定着することもある。
3. プロンプト解釈の「土台」に目を向ける
AIに仕事をさせるとき、「何を伝えるか」に意識が向きがちです。
しかしこの実験が示したのは、AIが返した出力を受け取る側の仕組みの設計が先にある、ということでした。
AIへの問いの質よりも、AIからの答えを検証する仕組みの質が、最終的なアウトプットを決めます。
犬はそれを意図せず証明しました。
- この実験はAIとの対話だけでコードを生成する開発スタイル「vibe coding（バイブコーディング）」の延長線上にある。AIコンピュータ科学者のAndrej Karpathyが2025年2月にXへの投稿でこの言葉を広め、Collins English Dictionaryの2025年版ワード・オブ・ザ・イヤーにも選ばれた。 – Vibe coding – Wikipedia
- 大規模言語モデルが「好意的に解釈する」のは、学習データに基づいてコンテキストと整合する確率の高い出力を選ぶためであり、入力者の意図を能動的に推測しているわけではない。この性質はプロンプト設計の議論で広く言及されている。 – I Taught My Dog to Vibe Code Games
- Godotは2014年にオープンソース化されたゲームエンジン。シーンの構成情報がテキスト形式の.tscnファイルに保存されるため、AIがファイルを直接読み書きしやすい。これが今回UnityやBevyを退けてGodotが選ばれた主な理由だとエンジニアは述べている。 – Godot Engine
- チャイム音でMomoに入力を促す仕組みは、Claude CodeのHooks機能で実装されている。HooksはClaude Codeのライフサイクル上の特定タイミング（AIが応答を終えたとき、ツールを実行する前後など）に、ユーザー定義のシェルコマンドを自動実行できる仕組みだ。 – Hooks reference – Claude Code Docs
MEMORY.mdはClaude Codeが自分自身のためにプロジェクト内で学んだことを書き留めるファイルで、セッションをまたいで読み込まれる。CLAUDE.mdがユーザーがAIへ与える指示を書く場所であるのに対し、MEMORY.mdはAIが自分でノートを取る場所という位置づけになっている。 – Manage Claude’s memory – Claude Code Docs