「おしゃべりスラミィ」を冒険の相棒に進化させた技術的知見

「ドラクエXの世界観を壊さない」Gemini実装　プロンプトからセキュリティ、サーバー設計まで工夫の数々

2026年08月19日 08時00分更新

文● 福澤陽介／TECH.ASCII.jp

サーバーの真の役割は“ゆらぎ”を受け止め、体験価値を最大化すること

　後半は、スラミィの対話体験に加え、多数のプレイヤーによる同時プレイも成立させるためのサーバー設計について、AI&エンジン開発ディビジョン AIプログラマーの深澤優鷹氏が解説した。

スクウェア・エニックス AI&エンジン開発ディビジョン AIプログラマー深澤優鷹氏

　深澤氏が最初に指摘したのが、「AIは必ずゆらぐ」という前提だ。「AIは本質的に不確実性を抱えており、常に同じ応答を返すとは限らない。さらに、オンラインゲーム特有の遅延や切断といったインフラ側のゆらぎも発生する。サーバー設計では、これらのゆらぎを前提に、いかにスラミィの自然な振る舞いを維持し、世界観を守り抜くかが鍵となった」（深澤氏）

　実際には、すべての会話リクエストの入口となるパイプラインサーバーを、Google Cloudの「Cloud Run」で構築。ここで認証処理やユーザーデータの参照を行った後、応答生成をAgent Runtimeのエージェントへ依頼する。テキスト生成後の後処理などもパイプラインサーバーで実行される。

スラミィのサーバー構成

　ここからは、開発中に直面したという5つの課題と解決策を紹介する。

　1つ目の課題は「AI自体が出力するコンテンツのゆらぎ」だ。応答の中身が空・途切れるといった事象にはじまり、AIの思考内容が漏れる「思考リーク」や、“end of sentence”が生成されないことが起因の「音声の無限生成」など、生成AI特有の様々な問題に悩まされたという。

　これらのゆらぎは、プロンプトやモデルのパラメータ調整などで一部は改善するが、根本的な防止は困難だった。そこで、サーバー処理の定石である「リトライ処理」をパイプラインサーバーへ徹底的に組み込んでいる。

　「不確実なAIのゆらぎに対し、リトライ処理は極めて有効。ただし、単純にリトライを繰り返すとAPIのレート制限に引っかかってしまうため、段階的に間隔を引き延ばす指数関数バックオフや回数上限の設定で負荷を最小化した」（深澤氏）

AIのゆらぎに対してリトライ処理が有効に機能した

　2つ目の課題は、リトライの上限に達してもなお失敗するケースだ。ネットワーク不調やユーザーの特殊なテキスト入力など、エラーを回避できない事象はどうしても発生してしまう。ただし、ここで無機質なシステムエラーや英文のエラーコードを返すと、世界観が台無しになってしまう。

　そこで失敗を受け入れた上で、「フォールバック処理」を設計した。どうしてもエラーを回避できない状況下では、スラミィの性格に合わせた定型文を自動選択。例えば、応答に失敗した場合は「ごめんデスら、よく聞こえなかったデスら」と返答する形だ。

失敗を前提とした「フォールバック」を設計

　3つ目の課題は、「基盤側のゆらぎ」だ。クローズドベータの試験において、負荷集中による「resource exhaustedエラー」が確認された。これも基本はリトライやフォールバックで対応可能だが、より高い接続品質と安定性の担保を目指した。

　そこで、Google Cloudの「Provisioned Throughput（PT）」を採用。従量課金のPayGoがアクセス集中時にレイテンシの悪化やエラーのリスクが伴うのに対して、PTでは必要な帯域分を事前購入することで専用の処理リソースを確保できる。

　「購入した範囲内であればエラーを完全に回避し、常に高品質な応答を維持できる。定額課金のため運用コストの予測が容易な点もメリット。ただし、定額であるが故に、買いすぎればコストが膨らみ、足りなければ品質が落ちてしまうというトレードオフが存在する」（深澤氏）

　なお、最適なPTの購入量を決定するためには、ゲーム開発チーム側との協力も重要だ。例えば、負荷のピークに合わせた購入を検討する場合、グループごとにプレイ時間をずらす仕様を採用することで、負荷のピークを平準化して必要な購入量を大幅に抑えられる。

定額課金の「Provisioned Throughput（PT）」

　4つ目の課題は、「AIのゆらぎをどう観測するか」だ。もし「スラミィが変なことを言った」という報告が上がっても、裏側では数多くの処理が走っている上に、AIの出力品質の要因はサーバーログだけでは特定できない。また、ビジネス側からも、「コスト予測のためにトークンの消費傾向を可視化したい」という要望があったという。

　そこで、入出力データやトークン消費量、途中の生成物などあらゆる要素を一元的に追跡できる構造化ログを再設計。「問題が発生した際にも、誰がどんな画像を送って、どのモデルがどう処理し、どう答えたかを追跡して、不具合の原因を特定できる」（深澤氏）という。

実際の取得ログの一部

　最後の課題は、システムとしての「安全性の確保」だ。深澤氏は、「推論や音声合成を伴うAI処理は、1リクエストあたりのサーバー処理が高額。万が一、不正に大量のAPIコールを実行された日には、甚大な経済的ダメージを被るリスクがある」と語る。

　こうした不正利用をブロックするため、ゲームサーバーを介した「ワンタイムトークン認証」を導入。ユーザーが会話する権利があるかをゲームサーバー側で厳格に検証し、発行されたトークンをパイプラインサーバーで照合して、クライアントからの不正なAPIコールをシャットアウト。また、プロンプトインジェクションなどのAI特有のリスクは、前述のようにModel Armorで安全性を担保している。