明確なルール、記憶、プレイヤーの選択肢を備えたAIボットゲームの設計方法
プレイ可能なAIボットゲームを設計するには、小さく反復可能なループを定義し、会話の外部にゲーム状態を保存し、プレイヤーの各行動に明確な結果を与えます。ボットにはリクエストの解釈とイベントの描写を任せ、明確なルールによってコスト、進行状況、エンディングを決定させます。このガイドは、AIキャラクターやナレーターを用いたテキストベースのゲームを制作するゲーム制作者向けです。ここでのタスクは、プレイヤーが自分の選択肢を理解し、自分の決定が重要であることを実感し、正当なエンディングに到達できる、短くテスト可能なセッションを1つ作成することです。以下の配達ゲームは例示的な設計であり、テスト済みの製品や報告されたケーススタディではありません。
AIなしでプレイできるコア・ループから始める
ループを1文で記述します：状況の提示 → 行動の受付 → ルールの確認 → 状態の更新 → 結果と次の選択肢の提示。すべてのターンでこのループを完了するか、進行できない理由を説明する必要があります。
ペルソナ（性格）のプロンプトを書く前に、目的、実行可能な行動、行動コスト、終了条件を定義してください。情報カードやスプレッドシートだけでゲームを実行できる状態にしておく必要があります。これにより、生成された対話によってバリエーションが加わる前に、メカニクスを検証することが可能になります。
『*フェスティバル・パーセル（Festival Parcel）*』という小さなゲームを考えてみましょう。プレイヤーは小包を配達するために5単位の時間を持っています。直接ルートか庭園ルートを選択でき、出発前に装飾用のリボンを集めることもできます。ボットはフェスティバルの配達員として振る舞い、ルートを説明し、配達についてコメントします。
提案されるルールは、意図的にコンパクトにまとめられています：
最初の選択の前にこれらのルールを提示します。配達アクションを行うとセッションが終了するため、リボンは事前に集めておく必要があることを説明します。最後の1時間単位を消費する配達であっても、成功判定が最初に行われるため、配達は成功します。
このプロトタイプには、完全な始まり、意思決定空間、そしてエンディングが備わっています。キャラクターやロケーションを追加する場合は、そのループに有意義な意思決定を追加することによって、その存在意義を示す必要があります。
明示的な状態を結末の権威（判定基準）にする
状態（ステート）を「ゲームにおいて何が真実であるか」の記録として扱います。会話テキストはその記録を説明することはできますが、暗黙のうちに変更してはなりません。
ロバート・ナイストロム（Robert Nystrom）著『*Game Programming Patterns*』の「State」の章（https://gameprogrammingpatterns.com/state.html）では、有限状態機械（FSM）を状態、入力、許可された遷移によって説明しています。また、不用意に組み合わせたブール型フラグがいかにして無効な組み合わせを生み出すかも実証しています。この原則をゲームのライフサイクルに適用し、定義された遷移を持つ単一のセッション状態（アクティブ、配達済み、失敗など）を使用してください。
この配達プロトタイプには、小さな状態仕様で十分です：
庭園のポストカードは、矛盾する可能性のある別の値として保存するのではなく、選択されたルートから導出します。同様に、現在選択可能なアクションも状態とルールから算出します。
固定された処理順序を使用します：リクエストを解釈し、そのアクションとパラメータを検証し、結果を計算し、状態の変更を確定（コミット）してから、それをナレーション（描写）します。確定した結果と許可された次のアクションをナレーターに渡します。ナレーターが独自に別の計算を捏造してはなりません。
たとえばリボンを集めた後、確定的な結果は「残り時間4単位、リボン回収済み、両方のルートが選択可能」となります。ボットは、その色がゲーム上のメカニクスに影響を与えない限り、リボンの色を描写できます。ただし、予告のない時間コストを追加したり、2つ目のリボンを与えたりすることはできません。
既存のインタラクティブナラティブツールを使って、これらの条件をプロトタイプ化できます。Inkleの公式インタラクティブフィクションチュートリアル（https://www.inklestudios.com/ink/web-tutorial/）では、条件付きの選択肢、過去に訪れたコンテンツの追跡、変数、明示的なエンディングについて説明されています。これらの機能は、AIによるナレーションを追加する前に、作成したゲームをテストするための有用な基盤となります。
プレイヤーに理解可能で、結果に影響を与えられる選択肢を提供する
この設計において、主体性（エージェンシー）の有無は、プレイヤーが意味のある違いを事前に予測でき、その結果を実際に観察できるかどうかで判断します。文言が異なるだけで同じ結果につながるボタンをいくつか用意しても、その検証にはほとんど役立ちません。
『*フェスティバル・パーセル*』では、ルートの決定がプレイヤーの異なる好みをサポートします：
これらは提示されたルールに基づいた計算例です。これらはシンプルな意思決定の指針を提供します。早く終わらせるなら直接配達を、装飾したいならリボンを回収し、ポストカードが欲しいなら庭園ルートを選びます。ここでの残り時間はエンディングの詳細であり、隠しスコアが加算されるようなものではありません。
もしゲームが後から特定の結末に対して報酬を与える場合は、決定を行う前にそのスコアリング方法を開示してください。そうでなければ、プレイヤーは開発者が意図したトレードオフを評価できません。
目に見える選択肢アクションと並行して自由入力をサポートします。「景色のいい道を行こう」は庭園配達にマッピングできます。「特別にして」は曖昧です。リボンを集めること、庭園ルートを行くこと、あるいはその両方を意味する可能性があります。時間を消費せずに短い確認を行ってください。
最初のプロトタイプでは、1メッセージにつき1つのゲームプレイアクションを受け付けます。プレイヤーが一連の行動を要求した場合は、その手順を提示し、最初のアクションを選択するよう求めます。これにより、後半のステップが利用不可能であることが後から判明するような計画を中途半端に実行してしまうのを防げます。
サポートされていないリクエストに対しても、有益な情報を提供します。プレイヤーが「空を飛ぶ」と要求した場合、利用可能なルートは直接と庭園であり、それぞれのコストがどれくらいかを説明します。自由入力によって表現の幅を広げつつ、アクションシステムによって予測可能な能力の範囲を維持します。
ボットが記憶すること、知り得ることを定義する
記憶をそれぞれ異なる目的を持つ3つの層に分割します。
権威あるセッション状態（Authoritative session state）は、リソース、進行状況、選択されたルート、およびエンディングを保持します。これはセーブやリロードを行っても維持され、検証されたアクションを通じてのみ変更されます。
セッションイベントログ（Session event log）は、確定したアクションとその結果を記録します。例えば「アクション2でリボンを回収し、時間が5から4に減少した」といったエントリーです。これはデバッグや正確な要約をサポートします。重複したリクエストが同じイベントを2回適用しないよう、アクション識別子（ID）を保持します。
ナラティブコンテキスト（Narrative context）には、トーンや連続性を維持するために使用される最近の対話と簡潔な要約が含まれます。これは、実際のゲーム状態を削除することなく短縮できます。
Anthropicの効果的なコンテキストエンジニアリングのガイド（https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents）では、会話履歴の要約と、コンテキストウィンドウの外部に永続的なメモを保持することの両方について解説しています。また、過度な要約によって重要な詳細が失われる可能性があることにも警告しています。ここでの設計上の示唆は、厳密なメカニクス的事実は構造化されたストレージに保持し、会話の連続性の維持には要約を使用するということです。
ストレージの境界だけでなく、知識の境界も設定します。キャラクターは、知ることが許可されている事実のみを受け取るべきです。将来のバージョンに隠しルートが含まれる場合、その発見条件が満たされるまで、そのキャラクターのコンテキストからは除外しておきます。ゲームエンジンが利用できる状態のすべてを、ナレーターが利用できるようにする必要はありません。
この小さなゲームでは、進行状況は保存されたセッション内に保持し、新しいゲームを開始する際にクリアします。一度のルート選択からプレイヤーの永続的な好みを推測することは避けてください。「説明を短くする」などの保存される設定を追加する場合は、明示的かつ編集可能にしてください。
具体的な一連の流れで記憶をテストします：リボンを回収し、セーブし、リロードし、ステータスを尋ね、庭園配達を選択します。リボンは回収されたままであり、配達前の残り時間は4単位、最終的な時間は0でなければなりません。
ゲーム上の失敗とシステムエラーに対する応答を分けて設計する
目的を達成できないことはゲームの一部です。テキスト生成リクエストの失敗は実装上の問題です。それぞれに異なる結末（結果）を与えてください。
ゲーム上の失敗については、プレイを終了させたルールを明示します。3回待機すると残り時間は2単位しかなく、どちらの配達ルートも選択できなくなります。プレイヤーを勝利不可能なアクティブセッションに残したままにするのではなく、明確な説明と再開の選択肢を提示して即座に終了させます。
実装上の失敗については、凝ったナレーションを追加する前に回復処理（リカバリ動作）を定義します：
読み取れないセーブデータを、黙って新しいゲームに置き換えないでください。それでは失われた進行状況が隠蔽され、その後の応答が誤解を招くものになってしまいます。
すべての行動に対して、「何が起きたか」「何が変わったか」「次に何が利用可能か」を示すプレーンなテキストの結果メッセージを用意します。ボットの表現豊かなナレーションはこの結果に添えることができます。タイムアウトや矛盾した応答が発生した場合でも、このプレーンなメッセージがあればプレイヤーはゲームを続行できます。
エンディングは正確な振り返りで締めくくります。リボンは回収した場合のみ言及し、ポストカードは庭園ルートの場合のみ言及します。生成される文章は、プレイヤーがセッションを通じて選択した違いを忠実に維持する必要があります。
まずルールをプレイテストし、次にボットの解釈をテストする
最初に固定テキストを使用してゲームをテストします。各アクション、エンディング、境界条件を網羅します。その後、ボットを追加し、さまざまな言い回しを使用してそれらのテストを繰り返します。これにより、壊れたルールと誤解されたリクエストを切り分けることができます。
想定されるプレイヤー層に近いテスターを招き、指示を出さずに配達を完了してもらいます。選択する前に何を期待しているか、選択した後に何が変わったと思うかを説明してもらいます。Nielsen Norman Groupの思考発話法ユーザビリティテストのガイド（https://www.nngroup.com/articles/thinking-aloud-the-1-usability-tool/）では、代表的な参加者とタスクを設定し、参加者自身に発話させることが推奨されています。また、ファシリテーターの促しが行動に影響を与える可能性があることにも注意を促しています。
アクションログと並行して観察を活用します。試みられたアクション、確認のリクエスト、予期せぬ結果、ナレーションと確定した状態の不一致を記録します。プレイヤーが選択肢を理解できたかどうかと、その中から選ぶことを楽しめたかどうかは、分けて質問してください。
簡易プレイテストチェックリスト。世界観を広げる前に、ルールと状態管理の不備を修正してください。プレイヤーが選択肢を理解しているものの面白みを感じていない場合は、トレードオフを変更します。決定を楽しんでいるもののコストが予測できない場合は、提示方法を改善します。異なる言い回し、セーブされたセッション、失敗の経路を通じても既存の選択肢が分かりやすく機能し続けるようになってから、プロトタイプを拡張してください。