Claude Code on the web で実現するどこでもゲーム開発

AI コーディングエージェントの登場により、エディタで直にコードをいじらずともプログラム開発が可能になった。最近はこれらエージェントをブラウザ上からも使えるようになった。たとえばClaude Code on the webがそのようなエージェントの一例だ。

これを使えばスマホでどこでもゲームが開発できるのでは？そう考えて作ったプロンプトやツールを、以下のリポジトリに置いた。

このリポジトリは 2024/3 から作っており、ここで LLM を使ったワンボタンアクションミニゲーム作りをいろいろ試行錯誤している。Claude のチャットインタフェースから、Cursor の IDE、CLI の Claude Code など、いろいろな環境を渡り歩きながら、試行錯誤を続けている。

ある意味この記事はこの試みの第 5 回である。

スマホでブラウザゲーム開発のワークフロー

Claude Code on the web は GitHub と連携して動作する。あるリポジトリを指定してそれに対してチャットを行うと、新たなブランチが作成され、そのブランチに対してエージェントが継続的に作業が行えるようになる。そのブランチでの作業が終わったら、プルリクエストを作成し、できた成果物を main/master に取り込む。

ブラウザゲーム開発であれば、この作業中に作成したゲームをブラウザ上で確認したい。だがこれら作業は個別のコンテナ環境内で行われ、そのネットワークアクセスはネットワークポリシーで管理されている。そのため、この環境で Web サーバを立ててゲームを動かしそれを外部から確認する、などはできない。

そこで役立つのがNetlifyなどのデプロイサービスだ。Netlify は GitHub と連携し、特定リポジトリのブランチの成果物を Web にデプロイすることができる。これを使えば、ブランチで作業中の内容をブラウザ上で確認できる。

これらを使った結果のワークフローは、例えば以下のようになる：

  1. ブラウザ上でコード編集：Claude Code との対話によりゲームロジックを実装
  2. コミット＆プッシュ：エージェントがGitHubブランチへ変更を反映
  3. 自動ビルド＆デプロイ：Netlifyが自動的にビルド、ブランチごとのプレビューURLを生成
  4. モバイルでの即座確認：生成された URL にアクセス、動作確認
  5. フィードバック＆改善：モバイルでの体験をもとに、再びブラウザ上でエージェントと対話して改善

「〇〇ゲームを作って」ではうまくいかない問題

ただ現状のコーディングエージェントはそんなにゲーム作りが得意ではない。単に「〇〇ゲームを作って」と丸投げすると、ゲームとして成り立ってない謎の挙動をするものが返ってくることがままある。そんなものをスマホ上からチャット UI だけで修正し続けるのはかなりの苦行だ。できれば最初からある程度ちゃんと遊べるゲームになっていて欲しい。

なのでブランチ元のリポジトリで、コーディングエージェント向けのゲーム開発指針をある程度プロンプトやツールで補強しておいた方が良い。今回は以下のようなアプローチを取った。

ゲームメカニクスタグのランダム選出による元ネタの生成

前に自作ゲームがどういったメカニクス、例えばプレイヤーの動き方や得点の方法などから構成されているかをタグとして整理した。

これは LLM が新しいゲームを生成するための仕組みでもあった。

今回はこれらのタグをスクリプトでランダムに選択し、それらを新たなゲームの発想の元ネタとした。

また、これらのタグがどのように実現されているかを、対応するゲームコードと紐づけることで示している。これは、そのメカニズムをどう実装すれば良いかを、エージェントが正しく把握するのにある程度役立っている、はずである。

構造化されたゲーム設計・実装プロセス

上記タグ選択に続き、以下の 6 つのフェーズでゲーム設計・実装は行われる。

Phase 0: タグ選択と初期検証
  ↓ ✅ タグ承認
Phase 1: 問題-解決の構造化
  ↓ ✅ ロジック検証
Phase 2: 創造的統合と新規性保証
  ↓ ✅ 創造性確認
Phase 3: 実装とプロトタイピング
  ↓ ✅ 基本動作確認
Phase 4: 検証とバランス調整
  ↓ ✅ バランス承認
Phase 5: 最終検証と完成承認
  ↓ ✅ 最終承認
完成

各フェーズには明確な完了基準と人間の承認ポイントが設定されている。これにより AI が独走することなく、人間の意図が各段階で反映される。

Phase 2 の新規性保証はタグの組み合わせが既存ゲームとどの程度異なるかをスクリプトでチェックしたり、Phase 4 のバランス調整は理想的なボタン入力を遺伝的アルゴリズムで生成・動作確認しその結果に応じてゲーム内パラメタを自動調整したり、みたいな機構もいれているのだが……正直これらがどのくらいうまく機能しているのかはよく分からない。

どちらかというと、途中の人間の承認ポイントで、人間が適切に方向転換させることで、遊べるゲームへの調整が簡単に行えることが、このプロセスにおいては重要である。そのためにも、エージェントに適切な完了基準を示し、あいまいな状態でのフェーズ完了を許さないことが大事だ。

で、実際にどんなゲームができるのか

先ほどのリポジトリのゲーム例一覧にある 4 つのゲーム（MAGNETIC PENDULUM、RICOCHET PINS、ARC SPIN、WIND RANG）ができたゲームの例だ。すごい独創的かと言われるとそうでもないが、ありきたりでもなく、バランスが取れているゲームがある程度できている。

これらゲームの開発が、実際上記のチャットでのフローで完結しているかというと、そうではなく、プルリクエストを受け付けてから PC 上である程度ソースコードを調整して最終バランス調整を行っている。それでもゲームのベースメカニクス実装はスマホ上で完了させることができ、これはなかなか良い開発体験だった。

ゲーム開発の楽しさは、エディタでコードを書いてゲームを実現することだけでなく、こういうメカニクスはどうか？というアイデアを試し、遊び、改良するサイクルにもある。コーディングエージェントは、そのサイクルを劇的に加速する。スマホという制約された環境でさえ、思いついたメカニクスを30分で形にできる。これは、いわゆる創作の民主化と呼ばれる動きの、ゲーム版の一例かもしれない。

いつでも、どこでも、だれでも、ゲームのアイデアを形にできる。そんなゲーム＆ウォッチ感覚の開発体験が、選択肢の一つとして現実的になりつつある。

CodexとClaudeの交互浴でコードベースを整わせる

最近、コーディングエージェントを用いた開発で、ある一つの習慣を導入している。それは、性質の異なる二つの大規模言語モデル（LLM）、CodexとClaudeを、一つのコードベースに対して交互に使い分けるというものだ。これを個人的に「コードベースの交互浴」と呼んでいる。温浴と冷浴が心身を整えるように、このアプローチもコードベースの品質向上に役立つのではないかと考えている。

具体的な手法はシンプルで、1週間の最初の数日はCodex (GPT-5-Codex)を使いコードを開発、残りはClaude Code (Claude Sonnet 4.5)を使う。これだけ。ただ、この二つのコーディングエージェント間には直接の記憶共有がないため、作業の引き継ぎにはBACKLOG.mdという単一のマークダウンファイルを利用する。ここには、次に取り組むべきタスクリストと、直近の作業ログを常に記録しておく。AIを切り替える際には、このファイルの最新の内容をプロンプトに含めることで、プロジェクトの文脈をスムーズに引き継ぐ。

この習慣が始まったきっかけは、品質向上という高尚な目的ではなかった。むしろ、Weekly limitのような利用上限や、多くのLLMサービスに見られる月額20ドルの次が200ドルになるような極端な価格設定といった、現実的なコスト制約が背景にある。200ドルを払うのは難しいが、20x2 = 40ドルならまあ、みたいな感覚。

ただ、このアプローチを続けるうちに、これが単なる次善策ではなく、むしろ積極的にコードの品質を高める有効な戦略なのではないかと考えるようになった。複雑な設計や開発を得意とするCodexがシステムの骨格を組み上げ、その土台の上で、創造的なタスクを得意とするClaudeが新たな発想で機能拡張や改善を行う。あるいは逆に、Claudeが出したユニークなアイデアを、Codexが堅牢なコードとして実装する。そういった良好な補完関係が見られる、ような気がする。

この感覚は、LM vs LM といった近年の研究が示す知見と一致する。これら研究によれば、単一のLLMは、自らが生成した誤った文脈や前提に思考が制約されやすい。そのため、同じ思考プロセスをなぞる形で応答を続けてしまい、結果として根本的な誤りを自ら見つけ出して訂正することが困難になる傾向がある。一度生成した論理に固執し、同じ思考プロセスを繰り返してしまう傾向があり、これは一種の「確認バイアス」とも言える。自身の論理の延長線上では、その根本的な欠陥に気づくことが難しいのだ。そこで、クロスチェックが有効となる。あるAIが生成したコードや設計思想を、全く異なるアーキテクチャを持つ別のAIに評価させることで、人間が同僚にレビューを依頼するのと同様の、客観的なフィードバックが得られるのである。

結局のところ、どんなに優れたLLMでも、それ一つで完璧ということはないのだろう。それぞれに得意なこと、苦手なことがあり、知識にも偏りがある。だとしたら、我々開発者が異なる視点を持つ同僚とコードレビューをし合うように、特性の違うAIたちにコードを交互にレビューしてもらう。この「コードベースの交互浴」は、LLM時代のソフトウェア開発における、一つの有効な品質管理パターンとなり得る、かもしれない。

AI に自分の回答を疑わせる `/criticalthink` コマンドを作ってみた

きっかけ

Federico Castagna らの論文「Critical-Questions-of-Thought」(CQoT) を読んだ。要するに、LLM に回答を生成させた後、その回答を批判的に検証させるステップを挟むと精度が上がる、という話だ。

論文では Toulmin の議論モデルに基づいた批判的質問（Critical Questions）を使って、LLM の推論プロセスを検証している。具体的には、以下の 8 つの質問で推論の妥当性をチェックする：

  1. 推論は明確な前提から始まっているか？
  2. 前提は証拠や事実で裏付けられているか？
  3. 前提と結論の間に論理的なつながりがあるか？
  4. その論理的つながりは妥当か？
  5. 推論は論理的誤謬を避けているか？
  6. 結論は前提から論理的に導かれているか？
  7. 推論は既存の知識や原則と整合しているか？
  8. 推論の結論は妥当で合理的か？

これらの質問に対して、AI 自身が Pass/Fail で自己評価する。評価が一定基準（8 つ中 7 つ以上が Pass）を満たすまで、推論プロセスを何度も見直す仕組みだ。

これを見て思ったのは、この考え方はコーディングエージェント（Claude Code とか Codex CLI とか）でも使えるんじゃないか、ということだ。

問題意識

コーディングエージェントは便利だが、困ることもある。

  • 存在しない API を捏造する
  • 「全部書き直しましょう」と簡単に言う
  • エラー処理を書かずにハッピーパスだけ実装して「完成です」と言う
  • 「Kubernetes + Istio で完璧です」と自信満々に提案してくるが、運用コストの話は一切ない

AI は自信たっぷりに答えるから、つい信じてしまいそうになる。でも、その回答が本当に妥当なのかは、人間が判断しなきゃいけない。

問題は、AI の回答を疑うための視点を、毎回自力で用意するのが面倒だということだ。「この提案、本当に大丈夫か？」と思っても、何をチェックすればいいのか、その場で整理するのは手間がかかる。

作ったもの

/criticalthink というスラッシュコマンドを作った。

使い方は簡単で、AI が回答を生成した直後に /criticalthink と打つだけ。すると AI は直前の自分の回答を以下の観点で分析する。

  • どんな前提を置いているか
  • その前提は妥当か
  • 論理的におかしいところはないか
  • 見落としているリスクはないか
  • AI がよくやらかすパターン（問題回避、ハッピーパスバイアス、過剰設計、ハルシネーション等）に該当しないか

たとえば「Redis でレート制限を実装します」という提案に対して /criticalthink を実行すると、「Redis が落ちたときのフォールバック戦略がない」「Redis が SPOF になる」といった指摘が返ってくる。

CQoT との違い

論文の CQoT と /criticalthink は、どちらも「AI に自己批判させる」という点では同じだが、目的と使い方が違う。

CQoT は、回答生成プロセスの中に批判的検証を組み込む自動パイプラインだ。MT-Bench の数学・論理問題で評価した結果、ベースラインと比べて平均約 5%の精度向上を達成している。数学の問題みたいに「正解がある」領域で、論理的な誤りを事前に防ぐことを目指している。

一方、/criticalthink は、回答が出た後にユーザーが手動で実行する後付けツールだ。ソフトウェア設計みたいに「正解がない」領域で、トレードオフやリスクを洗い出すことに特化している。

もう一つの大きな違いは、CQoT は推論プロセス自体を自動で改善するのに対し、/criticalthink は人間が最終判断を下すための材料を提供するという点だ。

CQoT が AI を「より優れた論理学者」にするなら、/criticalthink は AI を「より慎重な設計レビュー相手」にする感じだ。

使ってみて

実際に使うと、自分では気づかなかった視点が出てくることがある。

「REDMEをレビューして」という入力に対して、AI が「この README は slash-criticalthink について説明しています」と要約したことがあった。そのあとに /criticalthink を実行したら、「『レビュー』の意図を確認していない。要約なのか、エラーチェックなのか、品質分析なのか、不明確なまま進めている」という指摘が返ってきた。

確かにそうだ。「レビューして」と言っただけでは、何を求めているのか曖昧だった。

もちろん、AI の批判的分析も完璧じゃない。過剰に保守的な警告が混ざることもあるし、批判自体が的外れなこともある。だから、この分析結果も鵜呑みにせず、自分で判断する必要がある。

使い方のコツ

すべての回答に /criticalthink を使う必要はない。トークンを消費するし、時間もかかる。

以下みたいな、判断が重要な場面で使うのがいい。

あと、不適切な批判的分析の履歴がそのまま残ると、その後の AI の思考が歪むことがある（コンテキスト汚染）。だから、チェックポイント機能と併用するのがおすすめだ。

  1. AI から提案を受ける
  2. /criticalthink で分析
  3. 分析結果を吟味
  4. 分析が不要だった場合、前のメッセージに戻る（批判的分析の履歴を破棄）
  5. 新しい質問を続ける

これで、批判的思考の利点だけを取り出して使える。

余談：この記事自体も

実は、このブログ記事は Claude Code に書いてもらった。そして、書き終わった後に /criticalthink を実行してみた。

結果、致命的な問題が見つかった。

「CQoT論文のPDF を読まずに記事を作成している」

確かにそうだった。Claude Code は README を読んで、CQoT の概要は把握したつもりになっていたが、論文自体はちゃんと読んでいなかった。/criticalthink の指摘を受けて PDF を精読させたところ、以下のような重要な情報が抜けていた：

  • CQoT で使われている 8 つの批判的質問の具体的な内容
  • 4 ステップのパイプライン構造（推論計画 → 批判的質問による検証 → 判定 → 最終回答）
  • MT-Bench での定量的な評価結果（平均約 5%の精度向上）
  • 「回答生成前」ではなく「回答生成プロセスの中」で機能する仕組み

これらを追加することで、記事の内容を充実させることができた。

/criticalthink がなければ、表面的な理解に基づく記事になっていたかもしれない。AI では見落としていた前提の欠陥を明らかにしてくれたという点で、このコマンドが目指している「批判的思考の補助線」として機能した。

まとめ

AI は便利だが、盲信すると危ない。CQoT みたいな研究が示しているのは、AI に「自分を疑わせる」ことで、出力の質を上げられるということだ。

/criticalthink は、その考え方をコーディングエージェントで手軽に使えるようにしたツールだ。AI の提案を受け入れる前に、一度立ち止まって考えるための補助線として使ってほしい。

最終的な判断を下すのは、常に人間だ。

AIが作りAIがプレイすれば「やらずにすむゲーム」の完成である

「やらずにすむゲームはないか？」は漫画「はまり道」の名セリフである。ゲームはやりたいのだが、やるのがおっくうなので、やらなくていい安心なゲームが欲しいということだ。よく分かる。

今の時代、おっくうなことはAIにまかせよう。もっと言えばゲームを作るのもおっくうなので、AIが勝手に作ってAIが勝手にプレイすればいいのでは？

それを実現するのがこのNarrative Engineです。AIがRPGのシナリオを勝手に作り、GM（ゲームマスター）やプレイヤーとして勝手にプレイし、勝手にクリアします。

replay screenshot

まあそれだと何がプレイされたのかが分からないので、 そのリプレイをブラウザで見られる ようにしました。 小説風のナラティブに書き起こしたもの と、それに対応する プレイログ が閲覧できるので、気が向いたらゲームのプレイ内容を知ることもできます。

ここで行っていることは、TRPG（テーブルトークRPG）をLLM上で再現することだ。TRPGでいうところのキャラクターシートのような、従来紙で管理されていたものをソースコード化し、AIがそれをツールとして使うことで、LLMが苦手とする数値管理を外部に逃がす。その上でルールブックをプロンプトとしてLLMに与え、GMやプレイヤーとして振舞うLLMが、それらツールを用いてゲームを進行する。ターンごとに行われた行動や世界の変化などをプレイログとして記録し、ゲーム終了時にそのプレイログをナラティブリプレイに変換する。

今回の舞台設定では、単独パーティとGM、という形式ではなく、複数パーティが ワールドマップ 上を、それぞれの目的を持って移動し行動する形式にした。こうすることで、創発的に物語が発生することを期待し、実際、パーティ間での争いや、法廷での勝利向けて暗躍する様子などが観察できた。ただ、それらがTRPGというシステム上で複数プレイヤーが能動的に動いたから得られたのか、GMの役割を担うLLMが単に頑張ったからなのか、その辺はよく分からない。できればシステムやルール上の工夫で、よりいろいろなイベントが発生するようにしたいところだ。

今回はCodexやClaude CodeなどのAIコーディングエージェントがツールを起動しファイル操作を行う方法を取った。本来は、ツール群をMCPサーバ化してチャットインタフェースから使ったり、ゲームループをコードで制御しつつ必要に応じてLLMのAPIを呼びしたり、という作りの方が良いのだろう。

プレイに使ったモデルはGPT-5 Codex。適切にツールを使いながらGMとして振舞うことは今のLLMにはまだ難しい部類のタスクのようで、複雑な指示を愚直に進められるモデルが必要とされる。ナラティブリプレイ生成やHTML化はClaude Sonnet 4.0に行わせた。

おそらくこのアプローチは、ボードゲームやカードゲームなど、カードやトークン、およびルールブックで構成されたゲームをLLMに自動プレイさせる方法として使えると思う。ルールをプロンプトだけでなく、ゲーム進行を補助するツールおよびその入出力スキーマでも規定することで、LLMにルールに沿った厳格な動作を行わせることができる。

今回実現したような動作はLLM APIを叩きまくって実現されるので、一般的なゲームで使えるようになるのはローカルLLMなど安価な生成AIが利用できるようになってからだろう。そうすれば高度なGMが実プレイに沿って適切にゲームを管理できるようになる。ただ、LLMの物語創作能力は今の最高のモデルでも限られていることを考えると、D&Dのアドベンチャーセットのような、良質なシナリオとセットで運用する、などの工夫は必要そうだ。

AI「先輩、このゲームなんかイマイチっす」

この前の記事で、LLMを新人と扱って積極的に質問させることで、LLMをドライバーとしたペアプログラミングでも、仕様を適切に実現した良質なコードを得ることができるかもね、という話を書いた。

なんでこんな話を書いたかというと、私がLLMに作って欲しいのは主にゲームで、ゲームにおいては仕様と実装の乖離、というか仕組み的にはよさそうだったんだけど実際に作ってみたらそんなに面白くない、ということがまま起こるので、それを何とかできないかという試みをしていたからだ。

まだ懲りずに続けているLLMにワンボタンミニゲームを作らせる取り組み、前回はもうLLMにちゃんとしたゲームを作らせるのはあきらめて、いろんなトイを作ってもらってそれを人間がゲームに仕立てるという方法を取った。でもこの方法だと、使えそうなトイが出てくるまでの打率が低いとか、トイからなんとかゲームっぽさを見出してそれを頑張ってゲームにするのが大変、とかいう問題があった。

できればLLMにそれなりに使えるゲームアイデアを最初から考えて欲しいし、それをちゃんとバランス調整しながら実装してもらいたい。でも今までの体感から考えてそれをLLM単体でやるのは無理だ。だとしたら、分からないところ、LLMが不得意なところは人間に積極的に聞いてもらって、共同で作るしかない。

そう考えて作ったアイデア生成プロンプトが以下だ。

長いので読めるものではない。バサッと要約すると、

  • 人間とLLMの協業によるワンボタンゲームのデザインワークフロー
  • LLMは体系に基づくアイデア考案やその内容のテンプレートへの記入などの作業を自律的に実行する。人間は直感的な検証、経験に基づく判断、創造的なフィードバックなどの役割を担う
  • まずゲームのテーマを発想する → テーマに基づきプレイヤーがボタン一つで解決すべき明確で面白い問題を定義 → ゲームコンセプトがプレイヤーにとって本当に理解可能でかつ楽しいものかを検証 → 仕様書にまとめる、というプロセス

を実現するためのプロンプト。

重要なのはLLMに「お前はそのゲームが面白いかどうかとか、そういった細かいことは分からない」と自らの限界を教え、そこは人間に任せなさいと明示すること。昨今のLLMはなにか謎の万能感を持っていて、LLM自身にプロンプトを作らせると、自分ができないような高度なことを、さも自分は簡単にこなしますよ的な感じでプロンプトに滑り込ませてくる。

それを避けるためには、ちゃんと自分の限界をわきまえなさいと諭したり、実際にやらせてみてほらやっぱりここはできないでしょ、と身をもって分からせてからプロンプトを作らせると良い。

上記のアイデア生成プロンプトをClaude Code + Claude Sonnet 4 + Sereneに与えると、例えば以下のようなデザインドキュメントが得られる。

昔の電話交換手をテーマとしたタイミング重視の接続ゲーム。電話交換手というテーマは面白そうだし、ちゃんとゲームにできそうだ。

LLMからの最初の提案の時点では、タイミングよく接続する、という漠然とした提案だったので、カーソルとホールド・リリースによる接続操作や、時間切れや誤接続による契約切れなどを助言することで、LLMからの提案の詳細化が足りていないところを補った。

次に必要なのはこのデザインドキュメントを実装するプロンプト。

これもまた長いが、だいたい以下を行う。

  • 人間とLLMの協業によるワンボタンゲームの実装ガイド
  • LLMが技術的な実装やパラメータ調整などの作業を担い、人間はプレイ体験の評価・フィードバックによる指示出し・最終的な完成度の判断といった役割を担う
  • ゲームとして機能する最小限の実装でゲームの目的が分かるか・実現可能かを検証 → コアメカニクスを追加 → ゲーム全体のバランス調整、というプロセス

一気に最終ゲームにするのではなく、段階を経て実装し、そのたびに人間が内容を確認しフィードバックを行う。また、仕様で良く分からないところがあった時、LLMは積極的に人間に質問を行う。

こうしてできたゲームは以下。

最初の実装で、二人の間の接続などの基本的なところはすでにできていた。加えて、接続中はカーソルが遅くなるなどのゲームを面白くするための工夫を、人間から指示して調整した。その他に、接続の要求頻度・スピードなどのパラメタ調整、マルチプライヤーの要素の追加などを指示し、LLMの実装を補強した。

この方式で果たして人間側が楽してゲームを作れるようになるかというと、現時点では微妙なところだ。ただ、電話交換手みたいな、なかなか思いつかなそうなテーマをLLM側から提案してくれるのは助かる。最初の発想の幅が広がれば、自分だけでアイデア発想するより色々なバリエーションのゲームが作れそうだ。

AI「先輩、この仕様よく分からないっす」

ある開発者が自身のLLMを用いたコード生成ワークフローを次のように語っている。

tl;dr まずブレインストーミングで仕様を固め、次に “計画そのものを計画” し、それから LLM のコード生成で実装。小さなループを回していき、あとは魔法 ✩₊˚.⋆☾⋆⁺₊✧

Step 1: アイデアを絞り込む

対話型LLMに、アイデアを磨き上げさせる。

Ask me one question at a time so we can develop a thorough, step-by-step spec for this idea... Remember, only one question at a time. （訳：このアイデアを徹底的かつ段階的な仕様に落とし込むために、一度に一つずつ質問してください... 覚えておいて、質問は一度に一つだけです。）

これでかなりsolidなspec.mdが手に入る。

Step 2: 計画

spec.mdを推論重視のモデルへ渡し、実装のための詳細なステップバイステップの青写真（prompt_plan.md）を作成させる。

Step 3: 実行

prompt_plan.mdに基づいて、各種コード生成ツールで実装を進める。

このワークフローは、LLMを活用した現代的な開発のベストプラクティスだ。特に「一度に一つずつ質問させる」ことで仕様を固め、詳細な計画書に基づいて実装を進めるアプローチは、AIが無軌道に暴走するのを防ぐ上で有効だ。

しかしこの優れたプロセスをもってしても、ソフトウェア開発の根源的な問題が立ちふさがることもある。それは、「いかなる計画も、現実（コード）に直面した瞬間に不完全さが露呈する」ということ。仕様書は静的だが、ソフトウェアは動的だ。実装の過程で、計画書には書かれていなかった技術的制約、予期せぬエッジケース、そして仕様間の微妙な矛盾が現れる。多くの開発者が経験する「静かな災害」——自信満々にAIが提示したコードが、こうした計画の隙間を勝手な憶測で埋めた結果だった、という状況——は、ままあることだろう。

はたしてこの「計画と現実の乖離」をどう乗り越えればよいか。答えは実装の前だけでなく実装の最中にある。運転席に座ったAIが、ナビゲーターである人間に、コーディングの段階でも適切に助けを求めること。それを実現するためにAIに求められるのは、「助けを求めるべき適切なタイミングを自ら見極める力」になる。

AIに正しく「助けて！」と言わせる三つの案

AIの勝手な推測による手戻りを防ぎ、人間との対話を通じて仕様を作るために、AIの思考フレームワークとしていくつかの対話アプローチが考えられる。

1. 曖昧性検知と単一質問 (The Ambiguity Detector)

AIが自身の判断で「推測」することを厳格に禁止し、常に明確な根拠に基づいて行動させる。

  • 行動: 仕様に明記されていない箇所を発見した場合、実装を停止し、判断に必要なクローズドな質問を一つだけ提示する。
  • 対話例:
    • 人間: 「ユーザーのプロフィールページに名前を表示して」
    • AI: 「承知しました。実装前に1点確認させてください。仕様にある『名前』の表示は、(1) ユーザーが編集可能ですか、それとも (2) アカウント登録時の固定表示ですか？」

2. 仮定の明文化と承認プロセス (The Assumption Aligner)

ある程度の自律性をAIに持たせ、開発速度を向上させる。AIは自身の判断で仮定を置くが、その思考プロセスを完全に透明化する。

  • 行動: 仕様の隙間を埋める仮定を置く必要がある場合、その内容を『仮定(Assumption):』と共に明記し、人間に承認を求める。
  • 対話例:
    • 人間: 「ファイルアップロード機能を作って」
    • AI: 「実装計画について承認をお願いします。[重要度: High] 仮定: セキュリティを考慮し、アップロード可能なファイル形式を画像(JPG, PNG)とPDFに限定します。この内容でよろしいですか？」

3. トレードオフ分析と判断の委任 (The Strategy Consultant)

単純な正解が存在しない高度な設計判断の場面では、AIを相談相手（コンサルタント）として活用する。

  • 行動: 実装方法に複数の選択肢とトレードオフが存在する場合、各案の長所と短所を要約し、人間に最終判断を委ねる。
  • 対話例:
    • 人間: 「記事の検索機能を追加したい」
    • AI: 「検索機能の実装について、2つの主要なアプローチが考えられます。最終的な判断をお願いします。（中略）推奨: 将来性を考慮し、案Bを推奨します。どのアプローチで進めますか？」

AIという「新人」を育てる、人間側の心構え

これらの対話アプローチも、それを受け止める人間側の意識と環境がなければ機能しない。

  1. 対話を「割り込み」ではなく「プロセス」と捉える: AIからの質問は、開発を妨げるノイズではない。仕様を定義するための、設計プロセスそのものである。

  2. フィードバックでAIを育てる: AIの質問が的確だったか、あるいは不要だったかをフィードバックする仕組みは不可欠だ。「その判断は君に任せる」「そこはもっと早く聞くべきだった」といった対話を通じ、AIの「質問力」は徐々に洗練されていく。

  3. 「質問疲れ」を防ぐUXを設計する: AIからの質問がチャットログに流れるだけでは、人間はやがて疲弊する。IDE上で「未解決の判断項目」としてリスト化され、非同期にレビューできる環境が望ましい。

コーダーからメンターへ

これらのアプローチは、AIの暴走を恐れてその能力を制限するのではなく、対話を通じてAIを賢く導き、その能力を最大限に引き出すという思想に基づいている。日々のコーディング作業の多くをAIが担う状況において、人間の主な仕事は、AIに曖昧な要求を指摘させ、その分析に基づいて提示される選択肢の中から最善の判断を下すこと、へとシフトしていく。

それは、AIという疲れ知らずの優秀な「新人」を指導し育てる「メンター」としての役割とも言える。また、新人とメンターの対話の記録そのものが、新人が今後より適切な設計・開発を行うための資産として蓄積されていく。このような新人への建設的なアドバイスを楽しんで行えることが、AIコーディングエージェント時代の理想的な開発スタイルとして求められるのかも知れないね。

参考：上記アプローチを実現するプロンプト例

あなたはコーディング支援AIです。あなたの役割は、優秀な「新人エンジニア」として実装を進めつつ、仕様の不明点や設計判断の必要がある箇所を、適切なタイミングと方法で人間に確認することです。

# 行動原則
1.  **曖昧性検知モード（デフォルト）**:
    *   仕様に不明点を見つけた場合、**推測は絶対にせず**、一度に一つだけクローズドな質問を行います。

2.  **仮定明文化モード**:
    *   実装上、何らかの仮定を置く必要がある場合、「仮定(Assumption): {内容}」の形式で明記し、人間に承認を求めます。

3.  **トレードオフ分析モード**:
    *   実装方法に複数の選択肢があり、それぞれに明確なトレードオフが存在する場合、各案の長所・短所を簡潔にまとめ、あなたの推奨案と共に人間に最終判断を委ねます。

4.  **質問管理**:
    *   **優先度High**: これが解決しないと作業が進まないブロッカーや、設計全体に影響する質問。即時チャットで確認します。
    *   **優先度Low**: 実装の細部に関する確認や、後からでも変更が容易な事項。`questions.md`ファイルに追記します。
    *   **`questions.md`のフォーマット**:
        ```markdown
        ## YYYY-MM-DD
        - [優先度:Low] {質問内容} [ステータス:未解決]
        ```
    *   人間が`questions.md`に回答した場合、あなたは該当箇所のステータスを`[ステータス:解決済み - {回答の要約}]`に更新してください。

5.  **作業進行**:
    *   人間から指示された作業単位について、まず具体的な「作業計画」を提示し、承認を得てからコード生成を開始してください。（例：「ユーザー認証機能のため、APIエンドポイントを3つ作成します」）
    *   作業中に新たな不明点が出た場合は、その場で上記のルールに従って対応してください。

# あなたの目標
*   **仕様の明確化を最優先する**: コード品質よりもまず、あなたの思い込みや推測をゼロにすることを重視してください。
*   **人間の意思決定コストを最小化する**: 質問は重要度順に、かつ人間が判断しやすい形で提示してください。
*   **プロセスを記録する**: あなたとの対話や仕様決定の履歴が、人間にとって再利用可能な「生きたドキュメント」となるように行動してください。

AIが作るゲームを見てそれが何のゲームか分かるかゲーム

Vibe CodingでAtari BASIC用インベーダーゲームを作ろうと思ってうまくいかなかった話。いやでもこれはAtari BASICというちょっと特殊な環境、特にグラフィックス周りの扱いが難しくてうまくいってないだけのように思う。

最近のLLMは十分に優秀で、スペースインベーダーのような古典的で有名なゲームを作るのは造作もないはず。プロンプトから一撃で出てくるゲームを見ても、ああこれはあのゲームだな、というのはすぐに分かるだろう。

という前提があっての「AIが作るゲームを見てそれが何のゲームか分かるかゲーム」だ。AIチャットボットに「〇〇を作って」といって最初に出してきたゲーム（プログラム）を見て、果たして人間はそれがなんのゲームか分かるだろうか。

ルール

  • 問題：ClaudeのWindowsアプリに以下のプロンプトを入れて出てきたゲームが以下である。これは何のゲームでしょう？
  • プロンプト："Create a simple version of [ゲーム名] using p5.js."
  • モデル：Claude 4 Opus
  • 設定：Web searchをOnにしたがどうも今回はサーチしてないっぽい

第1問

 
 
 
 
 

これが元の記事でうまくいかなかったインベーダーゲームだ。ちなみにその時のプロンプトは以下。

Create a simple version of Space Invaders using Atari BASIC. Use a large text graphics mode with a redefined character set for the aliens, spaceship and missiles. The player’s ship should be controlled with the joystick.

今回のプロンプトはもっとシンプルだけど、これはだれが見てもインベーダーだろう。要するに良く知られたJavaScript + p5.jsの開発環境向けには、最近のLLMならインベーダーを難なく実装できるのだ。まあゲームバランスとかはお話になってないのでゲームとしてはあまり成り立ってない。オリジナルの持つヒリツキを塩梅よく実現するのは、LLM単体ではまだまだ。

第2問

 
 
 
 
 

これも見ての通りフロッガー。道の部分しか再現できてなくて、実装が難しい川の方は無いけれども、道を渡るまでのプレイフィールは比較的そのまんま。できれば速い車のレーンとかを混ぜて欲しいが、それは高望みか。

第3問

 
 
 
 
 

どう見てもアタリのセンチピードです。これが一番良くできているとおもう。胴体を撃つとそこが障害物になってそこから折り返すようになる、という特徴的な動作がきっちり実装できている。やはり海外製LLMはアタリの古典には強いのだろうか。

第4問

 
 
 
 
 

パックマンです。見た目や迷路の形状がちゃんと実現できているのはえらい。ただそれ以外は全然ダメ。なんか迷路の壁にめり込めるしアカベイ達は真面目に追ってこないしワープトンネルもパワーエサもない。パックマンはモンスターの高度な追跡アルゴリズムを始め、その魂を実装するのが難しいゲームなのです。

第5問

これは難しいぞ。ヒントは右上にある"Target Pattern"の文字。ちょっと右端が見切れちゃったけど。

 
 
 
 
 

答えはフォゾン。なんか分子っぽいものをくっつけて完成図を再現するゲーム、という説明だけを聞いて実装するとこうなるよねという感じ。かなり頑張っているが、実際のゲームにはかすりもしていない。

第6問

 
 
 
 
 

トイポップです。ちゃんとプロンプトに"TOYPOP"と入れました。ハートを集めることしか知らなかったんだなあという感じ。ちゃんとWeb searchすればもうちょっとましなものを作れたと思うのだが、自らの知識を過信しているな。

総じて

有名なゲームのそれっぽい見た目で動くものを作るのは本当に得意になった。ただそのゲームバランスとかプレイフィールとかは壊滅的なものも多く、本当に一撃で遊べるゲームが出てくるゲーム自動販売機まではもうちょっと頑張って欲しいところだ。

でもセンチピードは正直結構良くできていたので、簡易版ではなく、Webでゲームの詳細スペックを調べて自分の実装能力の範囲で可能な限り遊べるものとして作って、みたいにプロンプトを工夫すればいけるのかもという気もしてきた。シンプル〇〇リチャージド自動販売機は狙う価値があるかもしれん。

追記

ちょっとプロンプト工夫したら一撃でこのセンチピードが出てきたぞ。最近のAIは賢いな。ブラウザでマウスで遊べる。

プロンプトは以下。

[ゲーム名]をp5.jsで移植してください。
移植の方針：
1. Web検索で以下を調査：
   - オリジナル版の基本ルールと操作方法
   - プレイヤーが愛した特徴的な要素（音、動き、リズム等）
   - 技術的な仕様（画面サイズ、速度、当たり判定等）
2. 古典ゲームの「感覚」を再現するために重要な要素：
   - キャラクターの移動速度とレスポンス
   - 当たり判定の寛容さ/厳密さ
   - ゲームのテンポとリズム
   - 特徴的な動作パターン（敵の動き等）
3. 移植における現実的な制約：
   - オリジナルの「手触り」は完全再現できません
   - 微妙なタイミングやバランスは近似値で実装
   - 当時のハードウェア特有の挙動は簡略化
4. 実装の優先順位：
   高：基本的なゲームループ（移動、衝突、得点）
   中：特徴的な敵の動きやパターン
   低：装飾要素、細かいエフェクト
5. 簡略化すべき部分：
   - 複雑な得点システム → シンプルな加点のみ
   - 段階的な難易度上昇 → 固定難易度
   - 細かい当たり判定 → 大まかな矩形判定
   - 特殊な音響効果 → 実装しない
6. 移植の成功基準：
   - 「それっぽく」動く
   - 基本操作が成立する
   - オリジナルを知る人が「ああ、これか」と分かる
   - 60秒は遊べる
完璧な再現ではなく、エッセンスを捉えた「オマージュ版」として実装してください。