AIのNPCをブラウザゲームに組み込む｜Function callingと状態管理

NPCの役割は、一つの会話場面から始める

最初のNPCには、町の案内や一つのクエストの説明など、役割を絞ってみましょう。何でも質問できるNPCにすると、知らないはずの情報をどう扱うか、物語と矛盾する返答をどう防ぐかが広い課題になります。依頼を受ける前、進行中、達成後の三つの場面を選び、それぞれで必要な情報を決めます。

NPCへ渡す文脈も必要な範囲にします。採集するアイテムの名前、必要な個数、現在の達成状況など、今回の会話に必要な事実をゲーム側で用意します。世界全体の内部情報や他のプレイヤーの情報を、台詞の生成に必要だからとまとめて渡す必要はありません。公開してよい設定と内部の状態を分けます。

文章の雰囲気は、短い例で共有します。親切な案内役なら、行く場所を一つ示してから補足する、といった方針です。長い会話を生成すると、プレイ中に読み切れないことがあります。NPCの目的、台詞の長さ、知っている範囲を設定し、対話の自由さと遊びの進めやすさの両方を確認します。

Function callingは、提案を受けてコードが実行する流れ

OpenAIの公式資料では、モデルがツールへの入力を返し、それをアプリケーション側のコードが処理する流れを説明しています。ゲームでも、AIの出力だけで所持品を書き換えるのではなく、呼び出しの種類と引数を検証してから処理します。返ってきた提案を実行するかどうかは、ゲームのルールで判断します。

当ブログの構成例では、NPCに「クエストの状態を読む」「報酬を受け取れるか確認する」という限定した入口を用意します。任意のデータを書き換える入口や、自由なプログラムを実行する入口から始めません。扱える行動が少なければ、正常な入力と不正な入力の両方を具体的に確認できます。

会話中にプレイヤーの状態が変わる場合も考えます。アイテムを消費した後に古い返答が届くと、最初に渡した情報と実際の所持数が違うかもしれません。報酬を処理する直前に最新の条件を読み、達成済みか、すでに受け取ったかを確認します。台詞の内容を唯一の記録として扱わない設計にします。

報酬は、達成条件と重複を確認してから渡す

たとえば薬草三個を集めるクエストなら、対象のクエストを受けたか、必要な個数を持っているか、報酬を受け取り済みでないかをゲーム側で確認します。NPCが「達成です」と話しても、条件に合わなければ状態を変えません。進行を更新できた結果を台詞側へ返し、実際の処理と表示をそろえます。

同じ報酬の要求が二回届く場合に備え、処理の識別子や受け取り済みの記録を使う方法を検討します。二つのタブを開く、応答が遅く再試行する、会話ボタンを連続で押す、といった条件で確認します。所持品の更新と報酬の記録を別々に途中まで終えると、後から整合しなくなる可能性があります。

以下の文章は実装前に使う仕様の例で、APIの正式な引数形式ではありません。実際の保存先や同時実行の仕組みに合わせて処理を設計します。オンラインゲームでは、クライアントが送った所持数をそのまま信じるのではなく、サーバーで管理する状態を確認する工程も必要になります。

行動：薬草クエストの報酬を受け取る
入力：クエストID、要求を区別するID
確認：受注済み／薬草が三個以上／報酬は未受領
成功：薬草の消費と報酬の付与、受領記録を確定する
失敗：不足、未受注、受領済みを区別して返す
表示：処理結果に合わせてNPCの台詞を作る

会話の失敗で、プレイ全体を止めない

APIを使う構成では、キーを公開するブラウザのコードへ入れず、サーバー側で管理します。OpenAIの運用資料もキーを安全に扱う方針を説明しています。ゲーム側には応答待ちの状態を用意し、同じ要求が重複して送られないようにします。待ち続けずに会話を閉じられる画面も検討しましょう。

応答がないときは、確認済みの短い案内を表示できます。「依頼は薬草三個です。集めたら戻ってきてください」といった固定文なら、クエストの条件を伝えられます。どこまでをAIの表現に任せるかと、どの情報を必ず伝えるかを分けることで、会話が失敗しても遊びを続ける道を用意しやすくなります。

公開前の確認には、未受注、不足、達成、受領済み、通信の中断を含めます。台詞だけでなく、所持品と進行の記録が期待通りかも見ます。この構成は当ブログの設計案で、応答速度や会話品質を実測した保証ではありません。一つのNPCで成立する範囲を確認してから、役割を増やしていきましょう。