ゲーム開発のためのAIハーネスの設計方法：LLMエージェントにゲームを読み取り可能にする

核となる主張：あなたのゲームこそがハーネスである

LLMがゲーム開発に苦戦するのは、コードが苦手だからではなく、ゲームには言語モデルにとって不透明な大量の非コード状態が含まれているからです。その解決策はアーキテクチャにあります。ゲームを決定論的で、アドレス可能で、測定可能にすることで、ゲーム自体がAIエージェントが働くためのハーネスになるのです。

これが、ゲームプログラマーであるKyle Kukshtelによるブログ記事「Your Game Is A Harness」の主張です。この記事は、彼がカルガリーで開催されたIndie Rodeoで行った45分の講演を基にしたもので、2026年10月10日に公開されました。Kukshtelは、この記事が100%人間によって書かれたものであり、講演の書き起こしではなくスライドから作成されたことを明記しています。

Kukshtelの捉え方は率直です。「LLMをゲームでうまく機能させることは、コンテキストの問題であり、ゲームやLLMが『そうである』（または『そうでない』）ことに本質的に結びついたものではない」

なぜLLMはゲームが苦手に見えるのか

LLMがウェブスタックに強いのは、ウェブスタックではすべてがコードであり、学ぶべき高品質なオープンソースのウェブプロジェクトの大規模なコーパスが存在するからです。ゲームはその両方の条件を満たしていません。

Kukshtelの主張は3つの部分から成ります。

1. ゲームはコードだけではない。 ゲームには、ソースコードとして簡単に表現できないアセット、シーン、アニメーション、オーディオ、データが含まれています。これらのコンポーネントは、LLMにとって事実上不透明です。
2. トレーニングデータがはるかに少ない。 Kukshtelは、高品質なオープンなゲームプロジェクトはウェブプロジェクトよりも桁違いに少ないと見積もっており、モデルの事前分布はより弱いものになっています。
3. 標準的なテンプレートがない。 ゲームエンジンは存在しますが、ゲームロジックのための標準化されたツールは事実上存在しません。なぜなら、すべてのゲームがそれぞれ異なるニーズを具体化するからです。

これが、ワンショットのThree.jsデモが機能する理由です。それらはゲームを単純なプリミティブとコードに還元し、アセット生成や適合作業をスキップします。Kukshtelは、これらのデモの多くが「粗製濫造」に感じられるのもこのためだと指摘しています。LLMの中央値以上の作者の声が欠けているからです。

実際的な結果として、ゲームはエージェントにとってブラックボックスであり、見えるのは書かれたコードだけです。ハーネスだけではそれを解決できません。なぜなら、ハーネスはゲームがコードだけではないという事実を変えないからです。

このアプローチを動機付けるコンテキストエンジニアリングの基本

すべてのLLM呼び出しは3つの部分に分解されます。システムプロンプト（すべてのユーザーに共有される一般的なテキスト）、アシスタントプロンプト（モデルの応答ベクトルを形成するサイドカー）、そしてユーザープロンプト（実質的にすべての入力がここに置かれます）。

Kukshtelの重要なメカニズム上の指摘は、セッションが毎回新しいわけではないということです。以前のすべてのメッセージが新しいメッセージごとに再送信されます。これは、各プレイヤーが自分の貢献を追加する前に他の全員の貢献を言い直さなければならない遊び場のゲームのようなものです。その蓄積されたテキストがコンテキストであり、本当に新しいのは最新のメッセージだけです。

以前のコンテンツが新しい作業に影響を与え続けるため、セッションの早い段階での悪いコンテンツは退化した結果を生み出します。これはKukshtelがコンテキスト汚染と呼ぶ失敗モードです。新興のコンテキストエンジニアリングという分野は、できるだけ汚染を少なくして最良の情報をコンテキストに取り込む方法を問うものです。

Kukshtelは、Drew Breunigによるブログ記事「How Contexts Fail and How to Fix Them」を、長いコンテキストの失敗モードに関するさらなる読み物として挙げています。

AIエージェントにゲームを読み取り可能にする

Kukshtelは具体的なチェックリストを提供しています。彼は、これらのプラクティスのほとんどが一般的に優れたゲーム開発であると指摘しています。AIはその見返りをさらに強化するだけです。

固定された乱数

ゲームの開始時にシードされた乱数の単一ソースを作成し、すべての非決定的な呼び出しをそれを通してルーティングします。コードがゲームプレイの動作を決定するために30箇所でRandom.Floatを呼び出している場合、30番目の呼び出しは毎回同じ値を生成し、ゲームはほぼすべての状態を決定的に再現できます。

Kukshtelの警告はタイミングに関するものです。生産終了時に決定論を後付けすることは非常に困難であり、土壇場で根本的な変更を必要とする可能性が高いです。最初のコード行の前にその制約を前提としましょう。

スクリーンショットと画像差分

ほとんどのエンジンには組み込みのスクリーンショットAPIがあります。Kukshtelはまた、エージェントが特定のレイヤーで作業するときに視覚的なノイズを減らせるように、UIレイヤーとゲームプレイレイヤーをオン/オフできるようにすることを推奨しています。

しかし、前後のスクリーンショットだけではうまく機能しません。マルチモーダルモデルでさえ、何が変更されたか、変更が目標に向かって進んだかどうかを識別するのに苦労します。Kukshtelはこれを別の形のコンテキスト腐敗として扱います。フレーム内の変更対象ではないすべてのものは、モデルが処理しなければならない汚染です。

解決策は画像差分です。Kukshtelは、無料のコマンドライン画像差分ツールであるodiffを推奨しています。2つの画像が与えられると、odiffは差分画像と「85%類似」などの定量的な類似値を生成します。その数値は、エージェントがターンごとに改善しようとする安定した評価ベースラインを提供します。

決定的な状態とセーブ/ロードを初日から

決定的な状態にどれだけ近いかのテストは簡単です。ゲーム内で正確な状態をどれだけ簡単にセーブおよびロードできるかです。Kukshtelは、セーブとロードは後から追加する機能ではなく、ゲームと一緒に最初からプログラムされた場合の開発のスーパーパワーであると主張します。

シング駆動開発：すべてに1つのオブジェクトタイプ

Kukshtelの中心的なアーキテクチャ推奨は、ゲーム内のすべてのエンティティを同じ種類のオブジェクトとして扱うことです。おそらくThingと型付けされます。彼の例では、Thingはステータスタイプの値、isAliveフラグ、タイプ列挙型を持ちます。実装コードはその列挙型に基づいて分岐します。

この動機となる観察は、成熟したオブジェクト指向のゲームコードベースでは、「木は犬である」が事実上真になるということです。木はメッシュとコライダーであり、犬はメッシュとコライダーと移動です。コードの観点からは、それらは同じコンポーネントの合成です。

エージェントにとっての見返りは、オブジェクトモデルの単一の真実のソースです。Kukshtelは、100のタイプの100のクラスがある場合、AIはそれらすべてとそれらの関係を理解して行動する必要があり、コンテキストを満たし、クラスを拡張するか、タイプを変形するか、新しいクラスを追加するかについての曖昧さを生み出すと書いています。1つのオブジェクトタイプがあれば、「AIは変更を加える場所を毎回正確に知っています」。

シリアライゼーションも1つの入力経路と1つの出力経路に集約され、競合状態やポリモーフィックなデシリアライゼーションの問題を回避します。ゲームはThingの巨大なリストになります。セーブはそれらすべてを1つの経路で保存することであり、ロードはその逆です。Kukshtelはまた、Dreamsのクリエイターが同様のシステムについて議論しているWookashポッドキャストのエピソードを指摘し、Casey Muratoriの、これは見た目ほどメモリを消費しないという議論を引用しています。

アドレス可能な状態とコマンドパターン

1つのオブジェクトタイプがあれば、すべての状態変更は同じ構造をターゲットにします。これにより、コマンドパターンが実用的になります。変更をシリアライズ可能なコマンドオブジェクトとしてキャプチャし、オブジェクトを直接変更するのではなく処理クラスを通過させます。

利点は正確な再現です。開始状態とシリアライズされたコマンドログがあれば、プレイヤーに尋ねる代わりに、プレイヤーが行ったことを正確にリプレイできます。AIエージェントは、コマンドをリプレイして、自分の変更が状態にどのように影響するかを評価することもできます。

コマンドはゲームから発信される必要もありません。テキストエディタやAIで作成し、コンパイルを必要とせずに実行中のインスタンスで再生できます。Kukshtelは、コンパイルなしでゲームを変更できるほど、エージェントのループが緊密になると強調しています。

外部データ管理

Kukshtelは、静的な運用データ（タイプ、attackDamage、walkSpeed、boatSpeedなど、物事がどうあるかを記述する値）は、ゲームにコンパイルされるのではなく、ゲームの外部に置くべきだと主張します。データの変更は、データソースを編集してデシリアライズするだけの問題になり、ビルドもエディタへのアクセスも不要になります。

彼はこれをCantataで使用された正確なワークフローとして説明しています。チームの約7人の非プログラマーが、ビルドとDepotと呼ばれるカスタムデータエディタを受け取り、彼が新しいビルドを作成することなく反復処理を行いました。彼は現在、Depotをdepot-editor.comでスタンドアロン製品にしています。他のチームはGoogle Sheetsやカスタムツールを使用しています。Riot Gamesは自社のゲームデータサーバーについて公開しています。

スタンドアロンシミュレーション（ブラックボックスアーキテクチャ）

Kukshtelは、ゲームのシミュレーションをエンジンから完全に分離し、独自のDLLまたはライブラリとして扱うことを推奨しています。エンジンはシミュレーションにコマンドを送信し、更新された状態を受け取り、その状態または以前の状態との差分を解釈します。エンジンは意図的に「愚か」に保たれます。シミュレーションが何かが動いたと言えば、エンジンはそれを動かします。

具体的な例：エンジンはThingの移動リクエストを送信し、シミュレーションはターゲットが有効かどうかを決定して移動を解決し、エンジンは結果をレンダリングします。コアにコマンドを送信できるものは何でもよいため、ネットワークプログラミングははるかに簡単になります。状態はネットワーク、LLM、または他のどこからでも取得できます。

テストも扱いやすくなります。Kukshtelは、ゲームテストが苦痛なのは主に状態、ロジック、データが密結合しているためであり、分離されたシミュレーションはエンジンを実行せずに純粋なC#プロジェクトと標準ツールでテストできると主張します。

彼はこのパターンを「ブラックボックスゲームアーキテクチャ」と呼び、Monster Trainに関するBrian CroninによるRoguelike Celebrationの講演と、Solium InfernumのチームによるGame Data Podcastのエピソードを引用しています。

影響評価：エージェントが読めるプロファイリング

Unity、Unreal、dotMemoryなどのIDEの従来のプロファイラは、人間が消費するために設計されています。コールスタックやグラフです。Kukshtelは、AIはこれらのツールをうまく扱えないと観察しています。なぜなら、それらはエージェントにとって読み取り可能ではないからです。ただし、Unityはプロファイラをよりエージェント読み取り可能にする作業を行っていると述べています。

エージェントが望むのはテキストです。Kukshtelは、キャプチャ出力をコンソールにダンプできる無料のプロファイラであるsamplyを推奨しています。これにより、エージェントはソースとドキュメントを読み、キャプチャを実行し、自分の変更を自律的に評価できます。

完全なループ

これらのテクニックを組み合わせることで、エージェントのターンが生成され、決定論的な入力、コンパイルなしの構造化された状態変更、分離された検証、影響評価というサイクル全体を数秒で実行できます。ループが高速であるため、すべての変更に対して実行でき、「重要」な変更のために予約する必要はありません。

Kukshtelの結論は講演のタイトルです。ハーネスはあなたのゲームです。どんなゲームもこれらすべてが可能であり、つまりどんなゲームもそれ自体がハーネスになり得るということです。

議論からの注意点と反論

Hacker Newsのスレッド（158ポイント、79コメント）では、かなりの反対意見といくつかの拡張が浮上しました。

このアプローチは大規模な3Dゲームには拡張できない可能性があります。 コメンターのavaerは、Thingアプローチは「パフォーマンス予算や階層化されたサブシステムにとって行き止まり」であると主張しました。なぜなら、数千のThingを持つ30のサブシステムを反復してコピーすることはフレーム時間内には不可能であり、唯一の修正は完全な書き直しだからです。彼らはECSとSOAを、異なる種類のハーネスを必要とするアーキテクチャとして指摘し、アートが現代のゲームの制作サイクルを支配しており、独自のカテゴリのハーネスが必要であると述べています。また、samplyはオーバードローを診断できず、GPU作業には独自のアブレーションと属性が必要であると述べています。

決定論は制限的です。 コメンターのbob1029は、「LLMはゲーム開発のコーディング側を完全に解決しました。しかし、これは決して難しい部分ではありませんでした。それどころか、まったく違います」と書き、多くのプラットフォームにわたって決定論を維持することが厄介な部分になると主張しました。彼らは、エンジン統合を完全に回避する代替手段として拡散モデルを提案しました。

エージェントは直感に反する方法で一貫性がない場合があります。 コメンターのandaiは、フロンティアモデルが、数週間の作業で単純なPongゲームに機能を変更または追加できず、何かを壊してしまった一方で、あるモデルは約100倍複雑なゲーム全体をワンショットで作成したと報告しました。彼らは、その違いが分布内行動にあるかどうかを推測しました。

一部の開発者は同じテクニックで強力な結果を報告しています。 コメンターのvanyleは、スクリーンショットを撮って入力をシミュレートする自動テストシステムを作成し、それをvectarineengine.comのエンジンのガイドに文書化しました。コメンターのtheptipは、この投稿が自分が独立に到達したものと一致し、スクリーンショットと分離されたシミュレーションが最大の成果であり、エージェントは無限に忍耐強いため、「各ゲームメカニックのビデオ付きのインタラクティブなデザインドキュメントを構築する」のようなプロンプトが変更のレビューを容易にすると付け加えました。また、ゲーム開発におけるオブザーバビリティへの投資不足を指摘し、DPSやヘルスのためのエクスポートされた時系列メトリクスがエージェントに不釣り合いに利益をもたらすと示唆しました。

エージェントはゲーム自体を計測できます。 コメンターのTeMPOraLは、Claude Codeを使用して1997年のPCゲームを最新のハードウェアで30分で実行し、その後その大部分を段階的に逆コンパイルし、シムされたDirectX DLLを拡張してWindowsの「プライベートデスクトップ」機能を使用してヘッドレスで実行し、複数のゲームインスタンスを並行して実行したと説明しました。彼らは次のように結論付けました。「LLMにゲームを計測させて、自分で理解させるだけでいいのです。」

これらのプラクティスは古いプラクティスです。 コメンターのhatthewは次のように観察しました。「AIを発明したからといって、人々が優れたソフトウェアエンジニアリングのプラクティス（デバッグ可能性、反復速度、信頼性など）を気にし始めたのはおかしなことです。」コメンターのKolibriFlyも同じ点を指摘しました。「エージェントのための優れたアーキテクチャを構築することは、結局、時を経て検証されたソフトウェアエンジニアリングのプラクティスを反映することになります。」コメンターのmarcus_holohanは、この投稿を「『エンティティの分離101』のツアー」と表現し、ゲームが本当にハードコードされたスパゲッティなのかと尋ねました。

創造的な上限についての懐疑論。 5年間のゲーム開発者であるコメンターのYesBoxは、多くの小さな詳細を磨くことは手作業の方が速いままであり、開発の一部は言葉で説明できないため、LLMがゲーム開発を引き継ぐことはないと予測しました。元MMOおよびインディー開発者であるコメンターのdudeinhawaiiは、AIモデルは常に「平凡な中間」を作り出し、ゲームを作ることはそれを楽しくすることと同じではなく、モデルは再利用可能な大規模アーキテクチャの構築が苦手であると主張し、人間がコアアーキテクチャを構造化し、AIを使用してその中のコードを書くことを推奨しました。

ドメインの専門知識は出力の判断方法を変えます。 コメンターのtransitorykrisは、特定の形のゲルマン・アムネジアを説明しました。専門知識を持つ分野での悪い仮定を見つけ、その後、専門知識のない分野ではモデルをはるかに信頼しなければならないというものです。

著者自身の注意点。 Kukshtelは、現在これらのテクニックをまったく使用していないプロジェクトを出荷していると述べて投稿を締めくくっています。なぜなら、そのプロジェクトは非常に小さいからです。彼はハーネスアプローチをより大きなプロジェクトに関連するものとして位置付け、読者に何がうまくいき、何がうまくいかなかったかを共有するよう呼びかけています。

要約

Kyle Kukshtelの「Your Game Is A Harness」は、LLMがゲーム開発に失敗するのはゲームがコードだけではないからであり、その解決策はゲームの状態を決定論的で、アドレス可能で、差分可能にし、ゲーム自体をエージェントのハーネスにすることだと主張しています。

タイトル

ゲーム開発のためのAIハーネスの設計方法：LLMエージェントにゲームを読み取り可能にする