ゲーム開発のためのAIハーネスのエンジニアリング方法

私は9月12日（26日）にカルガリーで開催されたIndie Rodeoで、「Your Game Is A Harness」というタイトルの45分間のプレゼンテーションを行いました。講演後、多くの方々と話した結果、私がそこで発表したアイデアを、カンファレンスに参加した人以外にも広く楽しめる形で共有するのは良いことだと思いました。また、このブログでAIについてよく話しているので、人々は私がAIを使って書いていると Assume しますが、これは真実ではありません！以下のすべては100%人間が執筆したもので、私が提示したスライドを基本的に参照として、この投稿を書いています（これはトランスクリプトではありません）。コードやツールの作成にAIを使うのを楽しむのと同じくらい、私は「昔ながらの方法」で書くことにも同様の楽しみを得ています。特に、このプロセスの一部をより効率的にしようとする理由はありません。それでは、私が初めて講演した内容をブログ記事にしたものをお届けします。お楽しみください！ はじめに [ここでは、私のウェブサイトをご覧になっている方のために、私自身と私の仕事についての簡単な紹介を省略します] ゲーム開発におけるLLMの使用について話したいと思います。Twitterでクールに見えるワンショットデモではなく、実際の開発についてです。つまり、1日8時間、週5日働くような場合です。そして、これに入る前に、LLMについてレベルを設定しておくと便利だと思います。少なくとも、ここで話すことの残りが理解できるように、いくつかの基本に入りましょう。この多くはレビューになるだろうということは認識していますが、開発ループの話題にすぐに移りたい場合は、次のセクションにスクロールしてください。 開発作業にLLMを使い始めた私の旅は、mood.siteというムードボードサイトを作ったことから始まりました。これは「エージェンティック」なものより前のことですが、当時のChatGPTが実際にコードを書けるかどうかをテストしたかったのです。そのプロセスは、私が盲目的にコードをChatGPTのWebインターフェースにコピー＆ペーストするだけのものでした。そのプロセスはひどかったですが、結果には驚きました。私はそのサイトを構築しました！それは機能しました！まだ多くのことを自分で検証する必要がありましたが、それは私を納得させるには十分でした。もしLLMにアクセスできなかったら、私が費やした時間（夜間の約2〜3週間、おそらく合計20時間）の半分もかからずにそのサイトを完成させることはできなかったでしょう。おそらく今日でも最初のバージョンを構築する作業を続けているでしょう。 それ以来、moodは私がLLMの作業を進めるためのテストベッドとなり（そしてそれ自体で中程度の成功を収めたプロジェクトです！）、同様のスタックを使用する他の多くのプロジェクトを立ち上げるきっかけとなりました。さらに、LLMは改善されており、特にClaude Codeやその後のClaudeモデルのようなものではそうです。私の経験から、Webベースのスタックに関しては、LLMができないことはほとんど、あるいは全くないと感じています。ソフトウェアの多くはWebソフトウェアであるため、LLMは何でもできると言いやすいかもしれません。しかし、非Webゲームの構築にLLMを使おうとすると、それは響き渡るような結論でした。「LLMはゲームが苦手」 ゲームのようなものにLLMを使おうとするたびに、それはうまくいきませんでした。これは私の自身の偏見かもしれません。私は15年近くゲームプログラマーをしており、物事がどのように機能するかを知っていると思います。私は「悪い」ゲームコードを遠くからでも嗅ぎ分けることができます。しかし、Svelte Webアプリに関しては、私は明らかにそれほど熟練しておらず、LLMが生成するコードは「良い」ものだと考える傾向があります。実際にはゴミかもしれません。しかし、SvelteとWebスタックのものが高品質であると信じる理由があります。その一部は、オンラインでソースが利用可能な高品質のWebプロジェクトがたくさんあるという事実によるものです。ゲームと比較すると、トレーニングデータは桁違いに少ないと想像できます。それだけでなく、ゲームにはコード以外のものがたくさん含まれています。ゲームは、静的な画像やテキストをレイアウトに入れるだけではありません。ゲームには、コードで容易に表現できないものがたくさんあります。そしてさらに、Webの同じテキストレイアウトの作業すべてがありますが、それはゲームが必要とする他の100のシステムの一部にすぎません。これが、多くの人々がThree.jsでゲームを作成している理由の一部です。彼らはアセットを単純な箱型のプリミティブとして容易に表現でき、ゲームで通常必要とされるアセット生成/適合作業や処理の多くをスキップできます。その結果、その多くはLLMの平均値以外の実際の作者的な声がないため、スロップ（不出来なもの）になります。 しかし、彼らには一理あるのかもしれません。ワンショットのThree.JSワークフロー（およびWebアプリ構築におけるLLMの習熟度）の重要なアイデアは、すべてがコードであるということです。物事がコードであるため、LLMはそれを推論したり、変更を加えたりすることが非常に容易です。しかし、従来のゲームでは、これはそうではありません。少なくとも、それがすべてではありません。ゲームには明らかにコードがありますが、コードではないものもたくさんあります。これは、ゲームの重要なコンポーネントがLLMにとって事実上不透明であることを意味します。もしあなたのゲームが、その不透明なものを効果的に操作し、変換することに依存しているなら、LLMはあなたのゲームに取り組む際に失敗するでしょう。 私は、多くのゲーム開発コミュニティがしばらく前にLLMを試してみて、直接この問題に直面したのではないかと思います。「LLMは悪い/役に立たない/など」という感情（社会を終わらせる可能性のある影響ではなく、能力のみについて話しているという大きな注意点があります）は、これらの制限に正面からぶつかったことから来ています。これは、構造的に、LLMはゲームを読むのが苦手であるということです。少なくともデフォルトの状態では。 LLMの基本 なぜそうなのか、そしてそれに対して何ができるのかについて、もっと話しましょう。どのLLMサービスへの呼び出し/プロンプトも、3つの基本的なコンポーネントに分解されます。システムプロンプト、アシスタントプロンプト、ユーザープロンプトです。 システムプロンプト：サービスのすべてのユーザー間で共有される一般的なテキストです。これは通常、LLM自体の基本を説明しており、「あなたはAnthropicによって作成されたインテリジェントな大規模言語モデル、Opus 5です…」といった内容です。これらが重要でないということではありません（重要です）が、私たちのユースケースにはそれほど関連性がありません。モデルの投稿された（および流出した）システムプロンプトの例をここで見ることができます。 アシスタントプロンプト：これは、AIが応答している内容をガイドするのに役立つサイドカープロンプトセクションのようなものです。これは基本的に、プロンプトに対するモデルの「相互作用」ベクトルと考えることができ、何らかの入力に基づいたモデルのユーザーへの「応答」を表します。通常、これについて考える必要はありません。 ユーザープロンプト：これが本当に「モノ」です。どのAIツールに入力するほとんどすべてがここに配置されます。送信されたチャット、コードなどはすべてこのセクションにダンプされます。人々が「コンテキスト」について話すとき、それは主に「プロンプトのユーザー（およびアシスタント）部分に保存されているトークン数」を指しています。各チャットが上記の「新鮮な」バージョンであると考えるのは簡単かもしれませんが、実際には、特定のセッション（「セッション」の境界は、使用しているサービスによって異なります。これは、Webホスト型モデルのサイドパネルでアクセス可能な「チャット」や、閉じる前の単一のClaude Codeセッションなどです）でモデルとやり取りするにつれて、モデルに送信したすべての以前のメッセージが毎回再送信されます。これは、あなたの番で、次の人が追加するために自分のものに追加する前に、他のすべての人のものをもう一度言う必要がある古い遊び場ゲームをプレイするようなものです。 コンテキストとコンテキストの汚染 これを何度も繰り返すと、作業しているセッションの「コンテキスト」が構築されます。これはすべて良いことですが、ここで注意すべき重要な点は、コンテキストの「最新の」ものにしか実際に対処できないということです（つまり、新しいメッセージを送信します）。以前のメッセージからのものは、繰り返しモデルに送信されます。したがって、コンテキストに入っているものが「良い」ことを確認したいのです。そうしないと、コンテキストが「悪い」ものによって汚染され、新しい作業に継続的に影響を与えるという、退行的なシナリオに陥る可能性があります。したがって、コンテキストを管理することは、LLMを扱う上で重要なことであり、これらの制約に照らして「コンテキストエンジニアリング」という新しいエンジニアリングプラクティスが登場しました。コンテキストエンジニアリングは