ドラゴンクエストX AI機能実装の舞台裏 賢いだけのAIはゲームの「相棒」になれない：世界観を守り抜け！（2/2 ページ）

[宮下明，＠IT]

　相棒として振る舞う上で特に重視したのが、スラミィの側から話しかける機能だ。ログイン時や写真撮影時、バトル勝利時といったタイミングで、プレーヤー自身が気付かないうちに、ゲーム側のプログラムがプレーヤーに代わってAIに裏で問いかける。例えば、初めてボスを倒した際には、褒めるようなプロンプトを送り込むことで、まるでスラミィが自分から声をかけてきたかのように演出する。

　出来事や指示を覚えていてくれることも、相棒には欠かせない。記憶は短期的なものと長期的なものに分けて管理し、短期記憶は会話内容をそのまま「AlloyDB」に保存し、必要な記憶をRAG（検索拡張生成）のように取得する。全ての会話を保持し続けるわけにはいかないため、一定のタイミングで重要な部分だけを抽出して長期記憶へと移行し、既存の記憶と矛盾があれば新しい記憶を優先して統合する。この処理はAgent Runtimeのメモリバンク機能が担う。

世界観を守るテキスト制御とセキュリティ

　ドラゴンクエストXには、ゲーム内のテキスト表記に関するルールがある。世界観を壊さないように現実世界の話題は避け、読点は空白に置き換え、1行の文字数にも上限を設けている。しかもスラミィは、テキストを表示するだけでなく、話す内容に合わせて表情を変える。そこでGemini APIを使い、生成した回答の感情を判定させた上で、改行などの後処理をかけて表示するようにした。こうしたルールは、プログラムで組むのではなく、プロンプトをいじって調整できるようにした。

　プレーヤーの入力は予測できないため、セキュリティは4層構成とした。（1）システムプロンプトでAIの振る舞いをあらかじめ指示し、（2）独自のアルゴリズムでNGワードを判定し、（3）Gemini APIが持つ応答フィルタリング機能のレベルを高く設定し、（4）Google Cloudの「Model Armor」でAIの設定を書き換えさせようとする入力（プロンプトインジェクション）などを無害化する。

　Model Armorは当初、現実の住所を話さないように厳しく設定していたが、ゲーム内の地名「アストルティア」まで言えなくなったので、一部緩めの設定にした。プロンプトインジェクションに対しては応答プロセスを強制的に中断し、「うーん。ごめんなさいデスら。何の話か分からないデスら」ととぼけた定型文で返す仕組みも備えた。

「AIは必ず揺らぐ」を前提としたサーバ設計

　講演の後半は、佐久間氏から深澤氏にバトンタッチし、おしゃべりスラミィを相棒として成立させるためのサーバ設計を解説した。深澤氏は「AIは必ず揺らぐということが、サーバを設計する上で重要な前提だった」と語る。AIは、同じ入力でも同じ応答を返すとは限らない。オンラインゲームに特有のインフラ側の遅延や切断といった不安定要素も重なる。不安定さを前提にした上で、いかにして自然な振る舞いを維持して世界観を守るかが設計思想の鍵になった。

　システムの中心は、Google CloudのCloud Run上に構築したパイプラインサーバだ。会話リクエストの入り口となり、応答の生成をAgent Runtimeのエージェントに依頼し、生成したテキストの改行処理や感情判定、音声生成といった後処理まで実行する。パイプラインサーバを中心に据えたことで、技術の試行錯誤をしやすくし、システム間の通信も最小限に抑えた。

「おしゃべりスラミィ」のサーバ構成（スクウェア・エニックス提供）

応答の乱れから不正利用まで、5つの課題を解決

　開発中は、大きく5つの課題に直面した。

　1つ目は、AI自体の応答が不安定になる問題だ。空の応答を返す、途中で途切れる、NGワードが入る、AIの処理内容がそのまま漏れ出てしまう、音声の終わりを示す信号がうまく出ず延々と流れ続けてしまう、といった事象が頻発した。プロンプトやパラメータの調整だけでは解決が難しかったため、パイプラインサーバにリトライ処理を組み込んだ。単純な再試行はAPIのレート制限に抵触するため、間隔を段階的に引き伸ばし、再試行回数の上限も設けた。これにより、エラーの大部分はプレーヤーに気付かれず裏側でこっそり吸収できるようになった。

対話型AIがうまく応答しない例（スクウェア・エニックス提供）

　2つ目は、リトライの上限に達してもなお失敗してしまうケースへの対策だ。これに対しては、エラーを回避できない場合はシステムエラーを表示せず、性格に合わせた定型文を自動で選んで返す仕組みとした。深澤氏は「応答に失敗した場合、『ごめんデスら、よく聞こえなかったデスら』と、あえてキャラクターがとぼけるように返すことで、世界観を保ったままもう一度話しかけたくなる流れを作った」と説明した。

　3つ目は、Gemini APIの基盤そのものが混み合って応答が不安定になる問題。クローズドβの負荷検証では、アクセスの集中によってGemini APIへのリクエストがエラーコード429「Resource exhausted」（時間当たりのリクエストが多過ぎる）を返す事象を確認した。そこでGoogle Cloudの「Provisioned Throughput」（PT）を使って必要な処理リソースをあらかじめ確保し、429エラーを避けて安定した品質を維持できるようにした。

　4つ目は、AIの応答が乱れたことをどう見つけるかという課題だ。AIの出力品質が低下しても、サーバ側のシステムエラーとしては検知できない。また、従来のログでは原因の特定が難しい。別途、トークンの消費量を可視化したいという要望もあったため、これらの課題を解決するため、入力・出力データやトークン消費量、生成過程まで追跡可能な構造化ログを新たに設計し、原因を特定できる環境を整えた。

構造化ログを新たに設計し、AIの入力・出力や生成過程、トークン消費量まで追跡できるようにした（スクウェア・エニックス提供）

　5つ目は、システムとしての安全性の確保だ。LLMの推論や音声合成を伴うAI処理は、通常のゲームリクエストと異なり、1リクエスト当たりのサーバ処理コストが大きい。不正な大量APIコールによる課金超過の被害を防ぐため、ワンタイム型のトークン認証を導入した。会話する権限をゲームサーバ側で検証し、発行したトークンとユーザーID、リクエスト種別をパイプライン側で照合し、使用済みのトークンは無効化する仕組みとした。

　深澤氏は「サーバの役割は、単にAIを動かす場所でも仲介役でもない。AIが起こす揺らぎを受け止め、プレーヤーの体験価値を最大化するための土台だ」と講演を締めくくった。チャットAIをプレーヤーの相棒として成り立たせる取り組みを、サーバ設計が裏側で支えている。