「複数のAIを経由する分、プレイヤーを待たせてしまうという欠点もあります。コストやレイテンシの最適化は、今後の大きな課題だと認識しています」（佐久間氏）

複数のエージェントと記憶サービスを組み合わせたマルチエージェントシステムの構成図（撮影：セッション投影資料）

性格診断と親密度が生む「自分だけのキャラクター」

　ゲームの世界に入り込んだような対話を実現するには、正しい日本語で応答するだけでは不十分だ。キャラクター自身が一貫した個性を持ち、さらにプレイヤーの好みや行動も踏まえて会話できる必要がある。そこで、システムプロンプトに、好きな呪文や特徴的な語尾、背景情報などを盛り込み、キャラクターとしての個性を定義した。

　加えて、MBTIを参考にして、ゲーム内にプレイヤーの性格を診断する仕組みも用意した。本家のMBTIは質問数が多いため、プランナーが数を絞り、世界観に合う質問へ作り替えた。人称や口癖を性格別に定義することで、プレイヤーごとに異なる個性が生まれる。

　さらに、会話を重ねると親密度が上がる仕組みも実装した。プレイヤーとの会話を別のAIが評価し、結果を経験値として加算する。スラミィを傷つけたり、盛り上がらない会話をしたりすると加算されないが、新しいことを教えたり喜ばせたりすると多い。性格プロンプトは親密度で段階が分かれ、他人行儀な口調から、次第に相棒のような口調へ変わる。

親密度に応じて段階的に切り替わる性格プロンプトの設計（撮影：セッション投影資料）

話しかけ、覚える。AIを相棒に変える2つの機能

　単なるチャットAIではなく「相棒」として感じてもらうため、特に重視したのが、スラミィからプレイヤーに話しかける機能だ。プレイヤーが操作しなくても、ゲームクライアントが特定のタイミングでAIにリクエストを送り、スラミィから話しかける仕組みを実現した。

　タイミングはログイン時や写真撮影時など、複数設定されている。例えばバトルでは、「プレイヤーが初めてこのボスを倒したので褒めてください」といったプロンプトをAIに渡す。ゲーム内の出来事をきっかけに、スラミィが自ら気付いて話しかけているように見せる仕組みだ。

　記憶の管理は短期と長期に分けた。短期的な記憶は会話内容をそのままAlloyDB Session Serviceに保存し、直近の必要な件数をRAG的に取得してリクエストと一緒に送る。

　ただし、リソースの制約から全ての会話を投げ続けることはできない。一定のタイミングで重要な部分だけを抽出して長期的な記憶へ変換し、既存の記憶と矛盾する場合は新しい方を優先して統合する。この処理はAgent RuntimeのMemory Bankが担う。

現実世界の話をさせない。世界観を守る4層の防御

　ドラゴンクエストXには、ゲーム内テキストの表記ルールが細かく定められている。読点を空白で表す、1行当たりの文字数を守るといった規定に加え、キャラクターとして現実世界の情報には言及できない。例えば、「渋谷駅から徒歩5分に○○ホテルがあります」といった回答は、ゲーム内には表示できない。

　「近くに宿屋が　あるデスら」のように話させるには、空白による文章分割、感情分析、現実世界の情報の制限が要る。同社はこれらを「Gemini API」で処理した。回答を生成した後に感情判定と空白の挿入、改行処理を行い、感情はスラミィの表情に、分割された文章はチャット欄などの表示に反映される。

　不適切な発言の防止は4段階だ。まずSafety Instructionsが、システム指示レベルでスラミィとしての振る舞いを規定する。次に、同社独自のアルゴリズムで決定論的にNGワードを判定するNG Word Checkを通す。3つ目はGemini APIのSafety Filterで、高いレベルを設定した。最後にModel Armorがプロンプトインジェクションやふさわしくない応答をサニタイズする。

　開発では、生成AI特有の挙動への対応も必要になった。一つは、AIが内部で生成した思考内容が画面に表示されてしまう「思考リーク」。もう一つは、長時間の音声生成で終了のタイミングを判断できず、音声トークンが生成され続ける「音声の無限生成」だ。佐久間氏は「当初はもっと高い頻度で出ていたのですが、Googleのエンジニアやサポートの協力を得て、サービスとして提供できる水準まで緩和できました」と語る。

Safety InstructionsからModel Armorまで、4段階で構成したセキュリティ設計（撮影：セッション投影資料）

AIは必ず「ゆらぐ」。失敗を前提にしたサーバ設計

スクウェア・エニックスの深澤優鷹氏（編集部撮影）

　後半は深澤氏が、多くのプレイヤーが同時に遊ぶオンラインゲームとして成立させる設計を解説した。前提に置いたのは、AIは必ず「ゆらぐ」という認識だ。

　「AIは本質的に不確実性を持っており、同じ入力をしても、常に同じ応答を返すとは限りません」と深澤氏は指摘する。加えて、インフラ側の遅延や切断も起きる。揺らぎを前提に、いかに自然な振る舞いを維持し、世界観を守り抜くか。それが設計思想の鍵となった。

　システムの心臓部は、Cloud Runに構築したパイプラインサーバだ。全ての会話リクエストの入口となり、認証とユーザーデータの参照を経て、応答生成をAgent Runtimeへ依頼する。受け取ったテキストにはポストプロセスを施す。分散構成を採らなかったのは、試行錯誤しやすく通信を最小化できるためだ。

　最初の課題はAIの応答そのものだ。応答が空で返る、途中で途切れる、思考リークや音声の無限生成が起きる。プロンプトやパラメーターの調整では根本的な防止が難しかった。そこでパイプラインサーバにリトライ処理を徹底的に組み込んだ。ただし単純に繰り返すとAPIのレート制限に触れるため、リトライ間隔を段階的に広げる方式を採り、回数上限も厳格に設けている。

エラーを見せない　体験価値を支える土台としてのサーバ

　それでも、リトライで吸収しきれない失敗は残る。無機質なシステムエラーや英文のエラーコードを返せば、相棒としての体験は台無しだ。

　そこで用意したのが、世界観を守るフォールバックだ。エラーを回避できない場合はシステムエラーを表示せず、スラミィの性格に合わせた定型文を返す。応答の失敗時は「ごめんデスら。よく聞こえなかったデスら」と、あえてとぼけるように応じる。

　基盤側の揺らぎには別の手を打った。CBTの検証で、負荷集中によるRESOURCE_EXHAUSTED（429）エラーが確認されたためだ。接続品質を担保するため、必要な帯域を事前に購入するProvisioned Throughput（PT）を採用。購入した範囲内であれば429エラーを回避でき、定額課金のため運用コストも予測しやすい。

　ただし、買いすぎればコストが膨らみ、足りなければ品質が落ちる。購入量の決定にはゲーム開発チーム側の協力が欠かせない。全ユーザーが一斉にログインすれば、負荷が瞬間的に跳ね上がり、その分だけ多くの帯域が必要になる。そこでグループごとにプレイ時間をずらす仕様とし、山をならすことで購入量を大幅に削減した。

　揺らぎの観測にも手を入れた。テスターから「変なことを言った」と報告が上がっても、裏側ではプロンプトの組み立てからLLMの推論、改行、感情判定、音声生成まで多数のステップが動き、従来のログでは原因を特定できない。そこで、入出力やトークン消費量、途中の生成物まで追跡できる構造化ログを設計した。

　安全性の確保では、ゲームサーバを介したワンタイムトークン認証を導入した。AI処理は1リクエスト当たりのコストが高く、不正な大量アクセスは損害に直結するためだ。使われたトークンは無効化され、不正な呼び出しを遮断できる。

　深澤氏は最後に、「サーバの真の役割とは、単にAIを動かす場所でも、仲介役でもなく、AIが起こす揺らぎを受け止め、ユーザーの体験価値を最大化するための土台です。これが、今回私たちが得られた知見でした」と総括した。

パイプラインサーバを中心に構成したシステム全体図（撮影：セッション投影資料）