スクエニ開発陣が「ドラゴンクエストX」の世界観を守るのに「Gemini」が必要だったワケ

対話型AIをゲームに組み込む際、最大の壁となるのがキャラクターや世界観との両立だ。「ドラゴンクエストX オンライン」は、この難題にどう挑んだのか。スクエニ開発陣が、その設計思想と工夫を明かした。

[平 行男，キーマンズネット]

　対話型AIを自社サービスに組み込む企業が増えている。だが、既存のIP（Intellectual Property：知的財産）やブランドの世界観を維持しながらAIを組み込むには、単にAIを導入する以上の難しさがある。AIはあらかじめ設定した通りの発言や応答を常にするとは限らず、想定外の発言や応答の失敗が起こり得るためだ。さらに、利用量に応じて変動するコストも見通しにくく、こうした課題はいずれもユーザー体験を損なう要因となる。

スクウェア・エニックスの佐久間隆友氏（編集部撮影）

　「ドラゴンクエストX オンライン」の開発チームは、この課題に正面から取り組んだ。2026年3月末にゲーム内で参加者を募り、同年4〜5月にクローズドベータテスト（CBT）として、ドラゴンクエストX オンラインに組み込んだ対話型AIパートナー「おしゃべりスラミィ」を配信した。スクウェア・エニックス AI＆エンジン開発ディビジョンの佐久間隆友氏（プログラマー）と深澤優鷹氏（AIプログラマー）が、この対話型AIサービスの開発・実装のプロセスを明かした。

「単なるLLM」では出せないドラクエ感をGeminiで再現？

　おしゃべりスラミィにテキストを送ると、音声付きで返事が返ってくる。文字を入力せず、スタンプを押すだけでも会話が成立する。さらに特徴的なのが、プレイヤーの行動をAIが認識し、自ら反応する仕組みだ。例えば、装備を変更した直後には「ほう　とっても　鮮やかな　装いデスら！」と変化を認識して褒める。

　CBTでは、こうした対話体験を実現するため、5つの機能要件を設定した。「問いかけに音声付きで回答する」「画面を見ながら回答したり実況したりする」「初心者が迷わないようクエストを提案する」「指示や前日に話した内容を覚えている」「特定のタイミングで自ら話しかける」といったものだ。佐久間氏は「単純に生成AIのLLMを使うのではなく、さまざまな工夫を行いました」と語る。

対話型AIパートナー「おしゃべりスラミィ」の開発中画面（撮影：セッション投影資料）

　こうした機能を支えているのが、複数のAIを組み合わせたマルチエージェントシステムだ。入口と出口にはセキュリティのレイヤーを設け、ゲーム内に表示すべきでない内容をカットする。

　セキュリティを通過したリクエストは、スラミィとの会話を担うエージェントと、スラミィ側から話しかけるエージェントに振り分けられる。さらに、カテゴリーごとに用意されたサブエージェントが回答を生成する。その回答をそのまま返すのではなく、自然言語処理や感情判定、音声生成などの処理を加えることで、スラミィらしい応答に仕上げている。

　基盤には「Gemini Live API」を採用した。マルチモーダルな入力に対応し、ボイスとテキストを同時に生成できるため、低レイテンシで利用できる。当初は音声合成（TTS）も検討したが、人間の発話としての品質は十分でも、キャラクターとしては物足りない。プロンプトでボイスのイントネーションやテンションを調整できる点が決め手となり、「デスら」という語尾も自然に聞こえるよう調整した。

　エージェント開発には、Googleが提供するオープンソースの「Agent Development Kit」（ADK）を活用した。サブエージェントやツール、記憶管理を組み合わせるだけでハーネス部分を構成でき、浮いた工数をセキュリティや面白さの作り込みに回せた。Live APIとADK、Agent Runtimeの採用で、開発期間は数カ月に収まった。

　複数のAIを組み合わせることで対話の品質を高められる一方で、処理が複雑になることによる代償もある。

　「複数の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が起こす揺らぎを受け止め、ユーザーの体験価値を最大化するための土台です。これが、今回私たちが得られた知見でした」と総括した。

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

本稿は、2026年7月30〜31日に開催された「Google Cloud Next Tokyo」（主催：グーグル・クラウド・ジャパン）の講演「『ドラゴンクエストX オンライン』の世界観を守り抜くGemini実装の全貌。『チャットAI』を『相棒』にする技術とは」における解説内容を基に、編集部で再構成した。