生成AIでリアルタイム多言語翻訳を実装した「三國志戦陣」の開発事例

コーエーテクモゲームスはMMO戦略シミュレーションゲーム「三國志戦陣」でAmazon Bedrockを活用したチャット翻訳機能を実装。開発過程と課題解決の設計を開発メンバーがAWS Summit Japan 2026で公開した。

日本ニュース 2026/08/05 22:06

生成AIでリアルタイム多言語翻訳を実装した「三國志戦陣」の開発事例 — 生成AIでリアルタイム翻訳を実装した「三國志戦陣」

コーエーテクモゲームスは、MMO戦略シミュレーションゲーム「三國志戦陣」において、Amazon Bedrockを活用したチャット翻訳機能を実装した。その開発過程と課題解決の設計を、開発メンバーが「AWS Summit Japan 2026」で明らかにした。

ゲーム内チャットのリアルタイム翻訳機能

「三國志戦陣」は、ギルド対ギルド（GvG）の攻防戦を繰り返して中核拠点を目指すMMO戦略シミュレーションゲームだ。ユーザー間の連携が勝敗を大きく左右するため、ゲーム内チャットでの緊密なコミュニケーションが極めて重要となる。

同ゲームは日本語版が2020年9月に、繁体字版が2021年7月にリリースされ、長らく別々のサーバ環境で独立して運営されてきた。しかし、運営を継続する中で、対戦相手やライバル、陣営間に新たな変化を生み出すため、双方のユーザーが同一環境でプレイする「統合サーバ」の構想が立ち上がった。

—

コーエーテクモゲームスの開発メンバーである矢野田直人氏（エンタテインメント事業部シブサワ・コウブランドシニアリーダー）は「攻防戦が重要なゲームであるため、ユーザー同士のチャットでのコミュニケーションが大切です。それには言語の壁を超える必要があり、手軽に翻訳でき、スムーズに意思疎通ができなければ、サーバを統合する意味がありません」と話す。

言語が異なるユーザー同士がリアルタイムに戦略を共有できなければ、GvGのゲーム性は成立しない。この課題をクリアするため、同社はチャット翻訳機能の開発に着手した。

生成AI利用における法務リスクの評価とコンプライアンスの確保

プロジェクトは、翻訳基盤の選定からスタートした。システムが「Amazon Web Services」（AWS）上に構築されていることから、AWSの従来型の機械翻訳サービスである「Amazon Translate」と、担当ソリューションアーキテクトから提案された生成AIサービス「Amazon Bedrock」の2つが候補に挙がった。開発は、プログラマが周辺アーキテクチャの構築やAPI検証を担当し、プランナーが法的リスク評価や仕様策定を担う体制で進行した。

初期段階で最も重視されたのはセキュリティとコンプライアンスの確保だ。ユーザーのチャットデータを翻訳のため外部のAPIへ送信する必要があることから、プランナー主導で社内法務部へ確認を行った。

「機密情報の漏えいや著作権上のリスクは少ないものの、プライバシーや通信の秘密をきちんと扱える環境であるかどうかを確認するよう法務部から指示されました。これに関しては、プロンプトやレスポンスをモデルのトレーニングに使用せず、第三者への配布も実施しないというAmazon Bedrockの仕様を説明することで承諾を得ました」と矢野田氏は話す。

AWSの公式ドキュメントを根拠に法務の要件をクリアした後、プライバシーポリシーを改定した。利用規約にデータ送信の旨を明記し、ユーザーから同意を得る運用プロセスを確立させた。

既存システムへの影響を極小化する非同期的アーキテクチャを採用

システム設計では、チャット翻訳の実行エンジンとなる「翻訳機コア」の完成を待たずに、周辺のインタフェースから先行して着手する並行開発の手法を採用した。アプリケーションサーバやバッチサーバ、ソケットサーバから成る既存のシステム構成は維持し、そこに翻訳機コアや翻訳用バッチ処理などからなる翻訳モジュールを非同期的に連携させるという設計だ。

データベースの設計でも、既存環境への影響を考慮して慎重に進めた。チャットデータを保持する既存のテーブルには膨大なデータが格納されており、そこに翻訳結果を格納するためのカラムを追加すれば、その作業のために長時間のサービス停止を伴うメンテナンスが避けられない。そのため、既存のテーブルには一切手を加えず、翻訳結果専用の新規テーブルを追加する方針をとった。

「翻訳機コアの実装には時間がかかるため、テーブルを分けておけば、この部分だけを切り出して別のプログラマに任せることも可能だと考えました。まずは固定的な『仮翻訳済みテキスト』を返すだけのモックアップを組み込み、システム全体の外側の仕組みを先に構築しています」と矢野田氏は説明する。

具体的なデータフローとして、ユーザーが都度、翻訳ボタンを押すのではなく、システム側のバッチ処理が未翻訳データを定期的に翻訳APIへ送信する仕組みを採用した。チャット画面にはまず原文のまま発言が表示され、翻訳結果がテーブルに格納されたタイミングで順次クライアントへプッシュ通知され、翻訳済みのテキストに切り替わる。この非同期的な構成により、API側の翻訳に時間がかかったり失敗したりした場合でも、チャット本来のスムーズさが損なわれることはない。

コストと精度の両面でAmazon Bedrock（Claude 3 Haiku）の優位性を確認

外部の連携が整った段階で、Amazon TranslateとAmazon Bedrockの本格的な比較検証が始まった。コンソールからの簡易的な実行を避け、「AWS SDK for PHP」を導入して正式なコードへとリファクタリングを実施した。「ランニングコスト」と「翻訳精度」の2軸で両サービスを厳密に評価した。

1サーバ、1カ月当たりの平均発言数に基づく試算では、文字数課金のAmazon Translateが約500ドルだったのに対し、トークン課金のAmazon Bedrock（生成AIモデルは「Claude 3 Haiku」を利用）は約120ドルに収まった。コスト面でおおよそ1対4という圧倒的な優位性が確認された。

精度の検証は、日／繁両言語を理解する社内メンバーの目視で実施された。攻防戦中の緊迫したチャットや、君主からのコメントなど多様なサンプルを用意した。プロンプトを自由に変更して結果を確認できる専用の管理ツールを開発し、検証サイクルを高速化させた。ここで最も重視されたのは、「攻防戦の指示や文章が正確に読み取れるか」という点だ。

「コストの優位性に加えて、翻訳精度でもAmazon Bedrockで利用可能なClaude 3 Haikuに軍配が上がりました。特定の場所への集中攻撃といった戦術指示が誤訳されてしまったら連携が崩壊します。Claude 3 Haikuは誤訳によって意味がおかしくなる頻度が低く、会話の文章が崩れにくいことが採用の決定打となりました」と矢野田氏は説明する。

API呼び出し制限の回避とゲーム固有記法の保護

実装で最大の懸念となったのがAPIの呼び出し制限（Quota）だった。当時の東京リージョンにおけるClaude 3 Haikuの上限は1分間に200回であり、ピークタイムの発言数がこれを超過するリスクが高かった。制限の緩い米国リージョンを利用する案もあったが、日本／米国間の通信レイテンシによる遅延はリアルタイム性が命の攻防戦では致命的となる。複数モデルの併用案もプロンプト管理の複雑化を招くため見送られ、最終的に1回の呼び出しに複数メッセージを格納するバッチリクエスト方式を採用して呼び出し回数を削減した。

もう一つの技術的問題が、ゲーム固有の記法の保護だ。":smile:"といったシステム依存の絵文字コードや、[100, 200]のようなマップ座標を示す文字列が、生成AIによって意図せず翻訳、破壊されてしまう問題が発生したのだ。

この問題に対しては、翻訳APIへ渡す前にPHPのpreg_replace_callback関数などの正規表現を利用して、特殊な文字列を一時的なプレースホルダー（例えば、coordinate01）に置換する事前処理を実装した。生成AIには「プレースホルダーは翻訳せず維持すること」をプロンプトで厳格に指示し、結果を受信した後にプログラム側で元のコードや座標へバインドする仕組みを開発している。

最適な出力を導くプロンプトエンジニアリング

生成AIから意図した通りの出力を安定して得るために、プロンプトエンジニアリングも高度化させていった。初期の投機的な指示から、テストを繰り返して要件を厳密に定義する条件書きの形式へと進化している。

最終的なプロンプトは、大きく5つのルールで構成される。具体的には、「翻訳対象を特定のタグで明示すること」「日本語の文章を深く理解してネイティブな繁体字表現を選択すること」「出力をJSONフォーマットに限定すること」の他、「中括弧で囲まれた英数字はプレースホルダーであるため翻訳せず元の位置に配置すること」「入力と出力でプレースホルダーの数を完全に一致させること」を指示している。

プロンプトの調整は試行錯誤の連続となったが、結果を迅速に確認できるツールを早期に構築したことが功を奏した。また、AWSやAnthropicの公式ドキュメントに記載されたベストプラクティスをプロンプト構築に反映させたことも精度の向上に貢献している。

「生成AIベンダーが提供している公式文書は情報が豊富です。プロンプトチューニングを行う際はきちんと読んでおくと良い結果につながります」と矢野田氏は語る。

空応答や出力数の不一致など、生成AI特有のトラブルに対処

各種の検証を終えると、2024年12月の定期メンテナンスにおいて翻訳機能は本番環境へリリースされた。しかし、その直後に想定外のトラブルが発生する。翻訳失敗のエラーログが頻発したのだ。原因は、生成AIの特性上、空のJSONなど想定外のレスポンスが返されるケースが存在したことにある。

「想定外のレスポンスに対して自動的に3回のリトライを行う仕様にしていたため、エラーが発生する度に処理待ちのキューが急速に蓄積していました。これを解消するため、すぐにリトライ処理を廃止する修正を適用しました」と矢野田氏は説明する。

リトライ廃止に加えて、1回のリクエストに同梱するメッセージの数を初期の5個から3個へと削減した。一度に送信するメッセージの数を減らせば無応答の発生率が改善するのではないかという仮説に基づくもので、これによってエラーレートを大幅に低下させることに成功している。

また、翻訳機コアに入力したメッセージ数と、出力のメッセージ数が一致しないケースへの対応も見られた。3つのメッセージの翻訳をリクエストしたのに結果が2つしか返ってこない、あるいは1つのリクエストに対して結果が2つ返ってくるといったケースだ。これに対しては、1つのメッセージを入力したケースで2つの結果が返った場合は最初の要素を採用し、複数のメッセージを入力したケースで数が合致しない場合は全体をエラーとして扱い、該当チャットの翻訳をスキップする設計へと修正した。