遊べるゲームをLLMに一発で作らせる、現在打率3割くらい

このリポジトリREADMEの'Zero-Touch Generation Examples'にあるゲーム群が、LLMにプロンプト・ツールと'Create a game'という指示を与えて一発で出てきたものだ。バランスなどに多少難ありだが、一応遊べるワンボタンゲームになっている。この程度のゲームが作られる確率がだいたい3割くらい。10個のうちの3つは遊べる。

今までは一発で遊べるゲームが出てくることはほぼ無かったので、3割といえども大したものだ。3割程度まで打率が上がった理由は、Claude Opus 4.5の能力の高さによるところが大きいが、今回作成したワークフローによるところもある。

LLM向けミニゲーム制作ワークフロー

LLMに、タグ選択 → 設計 → 実装 → 評価 → 改善という5段階のワークフローでゲームを生成させた。使用したプロンプトやツールは上記リポジトリにある。特徴的な点としては以下が挙げられる。

タグ駆動の発想

107種類のゲームメカニクスタグ （player-rotate, on_pressed-jump, field-auto_scrollなど）からランダムに数個を選び、それをインスピレーションの種としてLLMに渡す。重要なのは、タグを仕様として扱わないことである。矛盾するタグが選ばれた場合でも、それを創造的なチャレンジとして活用する。

強い制約による品質確保

  • ワンボタン操作: 押す・離す・長押しの3パターンのみ
  • 約150行のコード: スコープの肥大化を防ぐ
  • 単一フレームワーク: crisp-game-lib のAPIのみ使用

LLMは自由度が高すぎると一貫性を失いやすい。強い制約を課すことで、出力の品質を安定させている。

自動評価による客観的判定

生成されたゲームを攻略可能な入力パターンを遺伝的アルゴリズム（GA）で生成、プレイさせ、「上手いプレイ」のスコアと「単調入力」（連打、放置、押しっぱなし）のスコアを比較する。

GA比率 = GAのベストスコア / 単調入力の最高スコア

この比率が1.5を超えれば「スキルが報われるゲーム」として合格とする。比率が低ければ、詳細ログを分析して改善を行う。

でもまだ人手でのバランス調整が必要

GA評価を通過したゲームでも、人間がプレイしてバランスを調整することはまだ必要である。自動評価で「スキルが報われる」ことは確認できても、「適切な難易度か」「スコアの伸びがプレイヤースキルを反映しているか」は人間が判断せねばならぬ。スコアリングシステムや難易度曲線の調整はこの段階で行う。

バランス調整後、再度LLMに今度はそのゲームを「ジューシー」に、遊んでいて楽しい視覚的フィードバックを加えることを依頼する。このように「ルール・メカニクス」と「手触り・演出（ジューシーさ）」を分けて生成させることで、まずは純粋な「ゲームシステム」の生成にLLMを集中させることができる。LLMに「ゲームフィール」を加えさせるのはその後だ。

上記リポジトリの'Enhanced Game Feel Versions'にこれら調整を行った版がある。元のバージョンよりはだいぶ遊びやすく、また見た目に楽しくなっている、はず。

LLMにうまくゲームを作らせるコツ

このようなワークフローがそこそこうまくいったことを考えると、LLMに一発でゲームを作らせるには以下のような内容がカギになるだろう。

  • 制約は味方：LLMに「何でも作れる」状況を与えると、出力は発散しがちである。出力形式、使用技術、コード量を厳しく制限することで、品質が安定する。これはゲームに限らず、コード生成全般に適用できる話。

  • 評価の自動化が重要：「良いゲーム」の定義は曖昧だが、「スキルが報われるか」という一側面に絞れば数値化できる。何らかの測定可能な指標を設計できれば、LLMの出力を自動で評価・改善できる。

  • ドメイン知識は外部化：crisp-game-libのAPIや衝突検出の仕様、ワンボタンゲームの設計パターンなどは、すべてマークダウン文書として外部化されている。LLMの事前学習に頼らず、必要な知識をプロンプトとして明示的に与えることで、再現性と制御性が高まる。

  • 反復ループを設計：一発で完璧な出力を期待しない。評価 → 分析 → 修正のループを何回かまわすことを前提としてワークフローを設計した方が良い。

  • 関心の分離：メカニクスとジューシーさを別々のフェーズで扱うことで、各フェーズのタスクが明確になる。LLMは曖昧な指示より具体的な指示で良い結果を出す。「面白いゲームを作れ」より「このゲームにジャンプエフェクトを加えよ」のほうが成功率が高い。

ワンボタンミニゲーム以外のゲームも作れる？

たぶんまだ難しい。現状のワークフローにはいろいろ制約がある。

評価できるのは一側面のみ

GA比率は「スキルが報われるか」を測定するが、驚きや新規性、ゲームバランスの適切さは測定できない。評価数値が良くても、人間がプレイして面白くないゲームは存在する。

ドメイン固有の準備コストが高い

今回のワークフローが機能するのは、ワンボタンゲームという十分に制約されたジャンル、ヘッドレス実行可能なテスト環境、crisp-game-libという適切な抽象度のフレームワークを揃えたからである。これらを揃えるのはそこそこ大変であり、別のジャンルに適用するには同等の準備が必要になる。

シミュレーションの限界

GAは「最適なプレイ」を近似するが、人間のプレイとは異なる。人間が発見しにくい抜け道を見つけたり、逆に人間には自明な操作を見逃したりする。またワンボタンゲーム以外は「最適なプレイ」をさせることがそもそも難しい。

新規性の保証がない

LLMは学習データに含まれる既存ゲームの影響を受ける。タグを「インスピレーションの種」として扱い、類似ゲームとの差異を明示させる工程を設けているが、真に斬新なメカニクスが生まれる保証はない。

LLM自動ゲーム生成の時は近くて遠い

LLMによるゲーム自動生成は、強い制約と自動評価の組み合わせによって「遊べるゲーム」を生成できる段階には達している。現状のワークフローでは人間によるバランス調整を含むが、ゲーム評価指標の多様化、既存ゲームとの比較による新規性担保、プレイ動画などのマルチモーダル評価などを組み合わせれば、完全自動化に近づける可能性はある。

ただし、「面白さ」の完全な数値化は本質的に困難である。人間が面白いと感じる要素には、驚き、達成感、フロー状態への誘導など、単純な指標では捉えきれないものが含まれる。LLMがこれらを捉えるのがすぐそこか、あるいは本質的に難しいままなのか、その辺はまだまだ未知数である。

ゲームのアイデアはふわっと思いつき、その過程は言語化できない。なので、AIには任せられない

ワンボタンアクションミニゲームをAIにワンショットで生成させる試み は相変わらず続けている。今回はゲーム発想の基本方針 をGemini 3 Flashに与えて5つのゲームアイデアを出させた。その中から私はなんとなく以下が一番面白くできそうだと思い選んだ。

５. 角度制御：『ジグザグ・スライサー（Zig-Zag Slicer）』

「Direction Change」を極限までシンプルにした、反射と精度のゲーム。


ビジュアル: 狭い通路（壁は単純な直線）。自機は鋭い矢印。


操作（Press）: 進行方向の90度転換。


ルール: 自機は常に斜め45度の方向に直進する（右上または右下）。 ボタンを押すたびに、進行方向が右上から右下（またはその逆）へ切り替わる。 壁にぶつかると、物理法則に従って跳ね返る。


ゲームオーバー条件: 通路内に配置された静止した赤い球体（地雷）に接触する。


リスク・リターン: 通路の角（コーナー）にある狭い隙間を通ると「テクニカルボーナス」が入るが、わずかな入力遅延が壁への激突や地雷接触に繋がる。

このアイデアを見てうーんと考えているうちに、私の頭の中には以下のような、実際のゲームが動いている絵が直接浮かんできた。

screenshot

画面両端から複数の壁が迫るフィールドの中で、ボタンを押すたびに上下の進行方向が切り替わる自機を操作するゲーム。自機は壁に当たるとX軸方向に跳ね返る。自機が壁に潰されたり、画面左右から外に出るとミス。画面上下はつながっていて、上から出た自機は下から出現する。壁に跳ね返るたびにスコアが入り、またマルチプライヤーが1加算される。マルチプライヤーは1秒ごとに1つ減らされる。左右から迫る壁の間に入って素早くマルチプライヤーを稼ぐのが重要だが、壁に潰されるリスクもある。

ごく基本的なアイデアからこの具体的なゲームプレイ に至るまでの過程は、完全に直観的なもので、なぜ上記のアイデアがこのゲームになるのかはまるで説明できない。無理やり解釈すると、以下のようになるだろうか。

  • 物理法則に従って跳ねるボールを、進行方向をタップで変えながら動かすのは、ありがちだがベースのアイデアとしては良い
  • フィールドを工夫しないとあまりにもありがちなゲームになりそう
  • 左右から迫る壁というフィールドは、ブロック崩し的なフィールドとして分かりやすく、かつ潰されないようにするリスクもあって良さそう
  • 潰されるギリギリまで狭まった壁の間を素早く反射するのは楽しそう。じゃあこれに高得点を与えたい
  • 壁にあたるとマルチプライヤー獲得、だがマルチプライヤーは時間で減る、とするだけで、これに高得点を与えられるし、リスクリターンとして良くできているではないか

ただ、これは実際の発想を無理やりエミュレートしているだけで、本当のひらめきからはほど遠い物だ。こういったエミュレートからは、真に豊かなゲームアイデアの発想は得られないだろう。私がゲームの元となるルール群から、直接唐突に実際のゲームプレイに至るのは、今まで遊んだり作ったりしてきたゲームたちの経験、もっと言えばそれとも関係ない様々な経験に基づいて、謎の直観・直感というものでたどり着いている。この飛躍を今のAIでエミュレートする方法、それを考えることは面白そうだが、その結果得られるプロセスは実際のプロセスとは似ても似つかないものになる。

なぜ人にはこのような謎の考えの飛躍があるのか。結局、その人が今までの経験で得た、マルチモーダルかつその時の感情なども含んだ長大な学習データに基づく思考の連鎖から得られている、なんとも得体の知れない思考の帰結があるのだろう。地球上にいる膨大な人が個々の経験を持ち、かつそれらを組み合わせて物事を考えている。その結果多種多様な考えが世の中に散らばっている。

それに対して今のAIはインターネットという単一の経験に基づいて様々な発想をしなければいけないわけで、その制約はだいぶ大きい。ワンショットでのゲーム制作を可能にするためにも、AIには早く色々な経験をできるようになってもらって、無限ゲーム制作機として働いて欲しい。まずはオールアバウトナムコ掲載のゲームを全て遊んでもらって、その楽しさを分かるようになりたまえ。

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側から提案してくれるのは助かる。最初の発想の幅が広がれば、自分だけでアイデア発想するより色々なバリエーションのゲームが作れそうだ。