AIゲーム制作で起きた「指示の競合」

体調不良で学校を休んだ息子。

ものすごく暇そうにしていたので「ちょっとしたゲームを作ってみようか」と持ち掛けた。とはいえ、私にはプログラミングの専門知識もなければ、ゼロから指導する技量もない。そこで、AIの力を借りて一緒に学んでみる機会を設けることにした。

ただ、息子にとってAIと対話し、戯れる機会はこれまで一度もなかった。いきなり「ゲームを作れ」と言っても何をどう指示すればいいか分からないだろう。まずは私のサポートのもと、AIとのアイスブレイクから始めることにした。

「好きな食べ物は？」
「友達と遊んでいて楽しめる時は？」
「普段は何をしているときが一番楽しい？」

AIから息子へ質問を投げかけてもらい、一問一答で答える。次に、しりとりや連想ゲームを一緒にやってみる。この段階を踏むことで、AIが「言葉を返してくれる存在」であることを感覚的に掴んでもらった。

場が温まったところで、本題のゲーム制作に入る。

対話だけでGeminiに完全なゲーム空間を構築させるのは無理があるため、役割を分担することにした。文章を打ち込んでコードを生成し、遊べる環境を整える「実装担当」は私。そのゲームを評価し、どうアレンジを加えるかアイデアを出す「ディレクター」は息子。

この体制で、実践をスタートさせた。

第1形態：WASDで動く「赤い箱」の召喚

まずは息子がよく遊んでいる『ロブロックス』を連想し、「3D空間で何かが動くロジックを、WordPressの投稿に貼り付けられる形式で作って」と指示を出した。

出力されたHTMLコードを貼り付けた結果が、これだ。

W＝奥へ、A＝左へ、S＝手前へ、D＝右へ。

PCゲームの基本操作で、緑の床の上を赤い箱が動く。それだけの空間である。これをやってみた息子の反応は、「え？なにこれ？これでどうするの？」というものだった。

彼が普段触れているのは、プロの手によって美しく完成されたゲームばかりだ。目的も敵もスコアもないこの空間は、彼にとってまだ「ゲーム」と認識できない様子が見て取れた。

第2・第3形態：「もっとゲームっぽく！」音とジャンプの追加

「じゃあ、もっとゲームっぽくしてみようか」 私主導で、ロブロックス内によくある「障害物を飛び越えるミニゲーム」をイメージし、自動で前に進みながらジャンプする機能をAIに追加させた。

単調ではあるものの、ゲームらしくはなった。障害物を避けるというお馴染みのルールになった途端、息子はすんなりと操作を覚え、楽しそうな様子を見せ始めた。

「ただ飛び越えるだけじゃ楽しくないよね？ 次はどうしたい？ どんな要素が加わればもっと面白くなる？」

そうディレクターに問いかけると、「音楽があるといいなぁ」という要望が返ってきた。そこで、Web Audio APIを使ってブラウザ上で直接ビートを鳴らす機能を実装した。

BGMがつくことで没入感が増し、反応は上々だった。しかし、今度は「簡単すぎてつまらない」という新たな不満が出てきたのだ。

第4・第5形態：息子の容赦ない要求（雷、暗転、理不尽なトラップ）

難易度を上げるためにはどうすればいいか。 「パパ。雷とか、画面が暗くなったりするのはどう？」 雷が鳴って視界が遮られれば、プレイの邪魔になる。素晴らしいアイデアだ。そこに私からの提案で「500点ごとにスピードが上がるレベルアップ方式」も採用することにした。

いい感じに仕上がってきたが、要素を詰め込んだことでシステムに歪みが生じ、バグが頻発し始めた。

・ジャンプが反応しないタイミングがある
・スペースキーを押すと、画面全体が下にスクロールしてしまう
・レベル3以降のスピードが速すぎて、人間にはクリア不可能な難易度になる

これらのバグを一つずつAIと対話しながら修正していく。その際、単なる障害物だけでなく「天井に紫のトラップを配置し、ジャンプしたら頭をぶつけてアウトになる」という意地悪な仕組みも追加してもらうことになった。

おおよその全体構成が見え、簡単なゲームとしての仕上げ段階に入った。息子自身も、自分の口から出たアイデアが目の前ですぐに形になり、ゲームが少しずつ組み上げられていく感覚を楽しんでいる様子だった。

第6形態：最終形態『THUNDER BEAT』の完成

最後に落とし穴（ジャンプしないと落ちる）の要素を追加し、バグもほぼ解消した最終バージョンがこれだ。

ここまで完成させるのに、おおよそ30〜40分程度。出来栄えとしては非常にシンプルで単調なものかもしれないが、息子自身は「自分が一緒に作ったゲームだ」と解釈しており、愛着を持って遊んでいる様子が見受けられた。

遊んでみて「これを追加したい」「こうすればもっと楽しくなる」と想像力を働かせ、イメージを形にしていく。プログラミング教育という枠を超え、ゼロからモノを生み出す「生産者」の視点を持たせる素晴らしい機会になったと思われる。

成長の記録を残そうとして起きた「システムエラー」

ゲームを自作する中でバグが生じるのは当然のことであり、それをどう修正するかが最重要である。そのプロセス自体は非常に有意義だった。

しかし、本当の悲劇（最大のバグ）は、このブログ記事を書いている最中に起きた。 息子と作り上げた第1形態から最終形態までの素晴らしい進化の軌跡を、すべてこの記事に縦に並べて掲載しようとしたのだ。

プレビュー画面を開いて絶句した。

一番上の「第1形態の赤い箱」は動くのに、下に配置した第2〜第6形態のゲームが、うんともすんとも言わない。スタートボタンを押しても、スペースキーを叩いても無反応。単体では完璧に動いていたはずの最新システムたちが、1つのページに並べた途端、完全に沈黙してしまったのである。

組織マネジメントと同じだった「バグの正体」

なぜ、最新版のゲームが動かなくなってしまったのか。

原因を探ってみると、それは家庭内のちょっとした技術的エラーにとどまらず、仕事やチーム作りにおける「組織マネジメントのエラー」と全く同じ構造を持っていることが分かった。

バグの正体は、大きく2つあった。

1. ID（名前）の重複による指示の無視
第2形態以降のゲーム画面には、すべて <div id="game-container"> という同じID（名前）が振られていた。HTMLの世界では、IDは絶対的な「個人の名前」である。 同じページ（会社）の中に「game-container」という名前の部署が6つも存在している状態で、システムが「game-container、動け！」と命令を出したとする。

するとブラウザは、一番最初に目が合った人物（一番上の第1形態）にしか指示を出さず、下にいる優秀な最新システムたちは完全に無視されてしまうのだ。役割や責任の所在を明確に分けず、曖昧な部署を乱立させると、組織は動かなくなる。

2. 全体への一斉指示（Windowイベント）による現場のパニック
ジャンプ操作には window.addEventListener という、いわば「全館放送」の仕組みが使われていた。 スペースキーを押すたびに、ページ内にあるすべてのゲームに対して「今スペースが押されたぞ！」と一斉送信される。すると、すべてのゲームが自分が呼ばれたと勘違いし、同時にジャンプしようとして処理がバッティングし、結果として全員がフリーズしてしまったわけだ。 特定の担当者を指定せず、現場全体に向けて曖昧な号令をかけると、現場が混乱してパニックに陥る。システムも人間も同じである。

解決編：すべてを独立して動かすための「3つの修正」

これらのバグ（組織の機能不全）を修正し、すべてのシステムが干渉せずに自律して動くようにするためには、以下の3つのルールを適用すればいい。

① 個別の名前を与える（IDの分離）
すべてのHTMLタグのIDの末尾に、-v2、-v3 といった独自の番号（サフィックス）を追加し、全くの別人として認識させる。

② 指示書を書き換える（JSの修正）
HTMLの名前を変えたら、JavaScript側で要素を呼び出す getElementById の中身も、正確に同じ番号へと変更する。

③ 担当部署にだけ指示を出す（ローカルイベント化）
全館放送をやめ、「マウスのカーソルがそのゲーム画面の上にある時（isHovered）だけ、スペースキーの操作を受け付ける」という条件を書き加える。 自分の担当領域に意識が向いている時だけ指示を聞くようにすれば、他のシステムを巻き込んでフリーズすることはなくなる。さらに e.preventDefault(); を入れれば、スペースキーを押した時に画面全体がスクロールしてしまうという、外部への迷惑行為（副作用）も防ぐことができる。

まとめ：むき出しの箱庭でバグと格闘する意味

ガチガチに管理された学校のプログラミング教材（ブロックを組み立てるようなもの）では、このような致命的なエラーは起きないよう、最初から安全に保護されている。しかし、ゼロからコードを組み上げるこの「むき出しの箱庭」では、設計の甘さが即座にシステムエラーとして返ってくる。

思い通りに動かない事象に直面し、「なぜ動かないのか」「どうすれば解決するのか」とロジックを紐解いていく時間。それこそが、ただ与えられた正解をなぞるだけではない、本質的な学びのプロセスである。

システムのエラーも、息子の野球で見えた課題も、そしてビジネスにおける組織の停滞も、根本を辿れば「適切な環境設定と、干渉しすぎない個別の管理」という同じ答えに行き着くのかもしれない。