Google ADKを活用したエンタメ翻訳

Google ADKを活用した エンタメ翻訳 合同会社パプカイヤ 増渕 大輔

自己紹介：増渕 大輔 (ますぶち だいすけ) 合同会社パプカイヤ はじめまして、増渕大輔です。 東北大学の情報科学卒で、IBMやMicrosoftに以前勤めていま した。IBM時代は、オンラインチケットシステム、Microsoft 時代はXboxチーム配属で3rdパーティーのオンラインゲーム サーバーをサポートしてましたのでサーバーよりの仕事をし てきました。 現在はITコンサルや技術顧問、ゲーム、AIロボット駆動科学、 看護師業務改善SaaS開発、などをしてます。 趣味は料理やダイビング、歴史めぐり。新しい技術や人との 出会いが大好きです。 文鳥を飼ってます

趣味

ヒッポファミリークラブ 40年以上の歴史 自然習得理論に基づく多言語環境 家族ぐるみ・異年齢での活動 Xin chào 안녕하세요 ホームステイ・交換プログラム 数千の会員数・数百の拠点 Bonjour 你好 สวัสดี Olá

気になったこと

IT + ゲーム+言語 の お仕事をしてみたい

IT業界では翻訳が急速進化 従来型機械翻訳 （Rule-based / Statistical Machine Translation） •ルールベース（Rule-based）: •統計的機械翻訳（Statistical Machine Translation） ニューラル機械翻訳 （Neural Machine Translation: NMT） •エンコーダー-デコーダー構造と自己注意機構 •RNNベース（2014年以前） •Transformerモデル（2017年ー） LLMベースの翻訳 （LLM Based Machine Translation） •GPT-3、T5、Llama、ChatGLM、など。 •T5 → 100言語対応

ゲームの翻訳 プレイヤー選択肢・分岐・ループを含む全シナリオでキャラクターの口調を100 %一貫させる メニュー・アイテム名・UIボタンなど固定幅スペースに収まる長さで翻訳する 同一セリフが吹き替え音声と字幕の両方で使われる場合、両方の制約を同時に満たす プレイヤー名挿入・性別変化・敬称変化にリアルタイムで対応できる文法構造にする 文化的・宗教的タブーや年齢レーティングに応じて表現を削除・置換を行うローカライズ判断 ゲームのジャンルにより、仕事の仕方、癖がかなり違う

過去40年間のローカライズ手法を研究した論文 論文要約: The Localization of Software and Video Games: Current State and Future Perspectives https://www.mdpi.com/2078-2489/15/10/648 ローカライズは国際化（言語対応可能化）を前提とし、 CAT/AIが文脈認識・専門用語適応を向上。課題として 文字サポート、文化保存、ネオロジズム干渉を指摘。 翻訳者 -> プログラマー協力と文化的UI/ストーリーテ リングが鍵。(GDCトレンド) 翻訳者のスキル不足（プログラミング基礎） プログラマのスキル不足（翻訳業務がわからない）

• https://www.mdpi.com/2078-2489/15/10/648

関連分野 データ J-GameLoc Corpus (2023)： 約5万文ペア（日本語-英語）。対話・UI・敬語タグ付き。Hugging Face公開。変数制約対応。 Japanese Visual Novel Parallel Corpus (2024)： ビジュアルノベル（例：『STEINS;GATE』風）から抽出。分岐ナラティブ特化。arXiv付録。 JP-GameSubtitle Dataset (OPUS拡張, 2025)： アニメ/ゲーム字幕。音声-テキストアライメント。 ツール： Textractor + DeepL/GPT Integration： リアルタイム日本語抽出・翻訳。敬語プロンプトで改善。 Ren'Py Localization AI Plugin (GitHub, 2025)： ビジュアルノベルエンジン向け。長さ制約自動調整。 MemoQ with Japanese Domain Model： 商用ツール。NMTファインチューニングで敬語精度向上。

RealLives Life Sim RealLives は、192 か国にわたる人生をシミュレーション 統計や個人の選択から生まれたキャラクターの役割をプレイする 誕生から死まで人生の広大な風景、物語を体験、共感を学ぶ RealLives Foundation

• https://play.google.com/store/apps/developer?id=RealLives Foundation

変数埋め込みのテキスト翻訳 単純翻訳 ルール＋LLM プロンプト 変数プレースホルダーの完全保持 × ◎ プロンプトに「{var_XXX} は絶対にそのまま残す」 と明記 変数の語順・格変化対応（日本語→英語、韓 国語→ロシア語など） × ◎ プロンプトで「文法的に正しい位置に {var_XXX} を 移動させてもよい」と指示 性別・敬称による動詞/形容詞変化（フラン ス語、ドイツ語、アラビア語など） × ○ LLMに「{var_001} の性別は{{gender}}です」とメ タ情報を渡す 数による格変化・冠詞変化（ロシア語、ポー ランド語、フィンランド語） × ○ 「{var_100} の数は{{count}}個です」と追加情報で ほぼ完璧 キャラクター口調の一貫性維持 △ ◎ 各キャラに「口調タグ」を付与（例：[キャラA: 古 風][キャラB: ギャル]） 文化タブー・ローカライズ判断 × △→○ 禁止ワードリスト＋「この表現は国Xでは削除/置 換」と事前ルール（ルール併用） スペース制限（UI 12文字以内など） × ○ 項目 備考・実用上の到達点 「最大12文字以内で自然な訳にせよ」と明示

機械翻訳はエンタメ コンテンツに使えるの？

小説・戯曲など 物語全体にわたる長距離の伏線・文脈依存関係を完全に把握・反映する 作者固有の文体、リズム、語感、句読点の使い方をターゲット言語で同等に再現する 各登場人物の内面描写・独白に独自の「声」（語彙選択・句構造）を一貫して与える 詩的・感覚的・哲学的な表現を、文化的等価性と同等のイメージ喚起力で置き換える 翻訳後も読者が原作と全く同じ強さで物語世界に没入し、感情移入・想像を働かせられる状態を維持する

ドラマ台本翻訳（吹き替え） 原アニメーションの口形・母音に100 %一致する母音・音節数でセリフを構築する 映像の口パクタイミングに合わせてセリフの長さ・呼吸位置を強制的に調整する 各キャラクターの口調・語尾・言い癖・声優が自然に演じられる形で一貫させる 感情の強弱・間・吐息・笑い声まで含めて、声優が再現可能な自然な日本語にする 文化固有のニュアンス（敬語・方言・時代劇口調など）を声で伝わる形で言い換える

ドラマ・アニメ・字幕キャプション 1画面あたりの文字数、2行以内、など厳格な文字数制限を守る 表示時間3〜4秒以内で全情報を伝えきるため、極端な要約・省略を強いられる 俳優の早口や重ねセリフでも、行分割・タイミングが崩れないよう調整する 日本語の曖昧指示代名詞（彼・あれ・それ）を固有名詞や明示表現に置き換える 一瞬で理解できる読みやすさと、元の感情・ニュアンスを両立させる

漫画翻訳 吹き出しの物理的な大きさ・形に合わせてセリフの文字数を厳密に制限する 「ドドド」「ザーザー」「ニヤリ」など擬音・擬態語を視覚的に等価な表現に変換 縦書き→横書き変換時に改行位置や読み順が崩れないようレイアウトを再設計 絵の表情・構図・効果線とテキストの感情・意味が完全に一致するように調整 フォントサイズ・太字・揺れなどで怒り・恐怖・ささやきなどの感情を視覚的に

AI・機械翻訳はめちゃくちゃ進化したはず エンタメの「難しさ」の事例は枚挙に遑がない 難しさまとめ 翻訳＝変換ではなく「再創造（Re-Creation）」 •意味的に正しいだけでは不十分 •文脈（長距離依存）・感情・演出意図が複雑 •文化・スラング・固有の文体（声）が重要 •マルチモーダル（画像・音声・構造）要素も絡む •無数の正解＝正解が1つに定まらない＝「創造タスク」 •別文化で 同じ感情 を再現する •別言語で 同じ演出効果 を生み出す •別メディア（小説/漫画/映像）で 同じ体験 を届ける

先人の知恵を調査し、NotebookLM を使って、Vibe理解 完全に理解した 完全に理解した 完全に理解した 完全に理解した

どうしようか悩んでいるうちに、 世の中は、Agent の時代に

エージェントが解決する曖昧領域（他業種） ゲームAI・対戦AI （Game Theory / RL） ゲームは本質的に非決定論（相手がいる） •AlphaStar（StarCraft II） •OpenAI Five（Dota2） •Multi-Agent Diplomacy（Meta AI） 都市計画・交通制御 （City/Traffic Systems） •車はそれぞれ“独自の意図”を持つ •信号、交差点、歩行者なども別Agent •“最適解が一つではない” コールセンター・接客AI （産業用会話システム） 複数エージェント方式 •“感情エージェント” •“オペレーション規則エージェント” •“説明責任エージェント” •“安全性エージェント” 自律ロボット・ドローン群 （Swarm Robotics） •ドローンの協調飛行 •倉庫ロボットの経路取り •自動運転車の集団挙動

エンタメ翻訳にも使えるかもしれない ビジネス・産業翻訳（Tool向き？） エンタメ翻訳（Agent向き？） • 目的が 単一（意味の正確性・用語統一） • 電圧・規格・安全表記など、揺らぎを許容しない • 翻訳調になっても実務上問題がない • 成果物の評価基準が 固定されている • 目的が 複数／衝突する • 意味 • 文体 • キャラ口調 • 感情 • 読者体験 • 文化的自然さ •用語一致チェック •文法・構文修正 •スペルチェック •数値・単位の正確さ •文意の忠実保持 •BLEU / TER などの定量評価が機能する •プログラミング、決定論的？ •“キャラらしく”聞こえるか •感情の強さは合っているか •ユーモア・メタファー・スラングの処理 •読者体験の最適化 •媒体制約（UI枠、字幕秒数）とのバランス •原作トーンとローカライズ品質のトレードオフ “人間”+”エージェント” のすり合わせが自然？

理想系を、チャッピー達との対話の中で検討 非エンタメの翻訳 • ◆ ビジネス翻訳システム（Tool） • 大型翻訳モデル → ポストエディット • QAチェッカー • 用語管理ツール • 翻訳メモリ エンタメ翻訳の理想系 • 翻訳者は“複数の声”を同時に聞いている： • 文脈エージェント：伏線、話者意図 • 文体エージェント：語り手の声 • キャラエージェント：口調・性格 • 文化エージェント：文化変換 • 制約エージェント：UI/字幕 • 批評エージェント：作品として良いか？ → 直列処理のパイプラインで完成するタスク → Agentではなく固定的なToolで十分 人間の認知自体が Multi-Agent 的 なので、これらの AIを育てていったら翻訳家が楽になるかも

Google 提供・エージェント開発キット：Agent Development Kit

エージェントをどう繋ぐか Workflow Agent（決め打ちパイプライン） LLM駆動型の動的ルーティング（転送）

Vibe理解 →「完全に理解した」→「何もわからない」 → 「チョットデキル」

初期の練習システム 30個ほどの論文（AiXivなど） いくつかのコーパス RenPyや青空文庫のデータ 英語・ハムレット → シーン特定 走れメロス → キャラクター特定 坊ちゃん＆こころ → 長文理解・階層構造化 Google ADK Ollama /GCP など マルチエージェントシステムを エンタメ翻訳に活用する アイディア群（チャッピー）

MELT-ADK = Multi-agent Entertainment Localization Tool - Agent Development Kit

MELT-ADK = Multi-agent Entertainment Localization Tool - Agent Development Kit

初期のADKへのアプローチ「Tool 的 Agent」から • いきなり Multi-Agent を実装すると多くのチームがつまずく。 • エージェント同士の調停ロジックがイマイチイメージがつきにくい • どの Agent が何を判断しているのかも、イメージがつきにくい • 初学者には“エージェントの概念”自体が重い • 今回の MELT-ADK は、 “Tool 的 Agent” からスタート 1. 全体像は、APIを呼ぶだけ 2. 次に、オーケスとレーター（ルーター）と、LLMなしAgent に置き換える 3. 次に、めちゃくちゃ単純なLLM実装をする

初期 • ADKのお天気Botチュートリアルと同じレベル（LLMなし）

I/Fと全体概要だけを先に設計 Agent 名 役割（何をするか） 目的（どんな価値 を提供するか） 初期実装の性質 （Tool的） 将来の拡張方向 （Agent的） ToneChecker 訳文の「口調の一致 度」をスコア算出 （0–100）。リスク レベルを返す。 キャラ口調・文体 のブレを検知し、 翻訳者に「ズレ」 を可視化する。 計算ロジック + ルールベース。 LLMなし。単純 デトミスティック 評価。 LLMによる理由説明、 キャラの声モデル、 シーン文脈の反映、 アドバイス生成。 LengthGuardi an 字幕やUIの文字数制 ゲームUI/字幕など 約をチェックし、超 「容れ物の制約」 過を検知する。 違反を早期発見。 完全な決定論（文 字数計算）。Tool の典型。 UIの幅推定、句読点 調整、LLMによる自 然な短縮案の生成。 CulturalGapD etector 文化的参照・NG 異文化圏で不自然/ ワード・ローカライ 危険な表現をフラ ズリスクを検知する。 グ立て。 キーワード/パ LLMを使った文脈判 ターンマッチ中心。 断、国別ポリシーに LLMなし。静的 基づく提案生成。 チェック。 OverrideMem ory 翻訳者が採用した訳 （最終訳）を記録・ 保存する。 「人間の最終判断 を絶対優先」する データ基盤をつく る。 DB書き込み専用 の保存Tool。判断 なし。 過去の判断のパター ン抽出、Copilot的補 助、キャラ別スタイ ル記憶。 ParallelCandi date 1つの原文に対して 複数の訳候補を並列 生成する（Natural / Literal / Emotional etc）。 「意味」「文体」 「自由度」など複 数の翻訳観点を翻 訳者に提示。 LLMは使うが、 独自の意思やメモ リは持たない。 Tool的生成器。 複数Agent（スタイル 別）による“意見の違 う”候補生成。対話型 生成。 FeedbackLog ger（v1） 翻訳者の修正ログを Firestore に保存す るだけ。 翻訳者の編集履歴 完全な Tool（保 を「後で学習する 存だけ）。判断な 基盤」として残す。 し。 類似例検索、修正パ ターン抽出、アドバ イス、ルール提案＝ 真のFeedback Agent 化。

アプリとしての主な機能

エージェント成熟表（進化イメージ） エージェント名 Lv1 Tool（初期） Lv2 LLM補足説明 ToneChecker 口調一致度スコア （0–100）算出。リ スク判定のみ。 “ずれの理由”を一行コ シーン文脈・キャラ関係か Culture/Emotion Agentと協調し、 メント（LLM or テン ら「適切な調整案」を返す。 トーンの優先順位を調停。 プレ）。 LengthGuardian 文字数・UI幅チェッ ク。完全ツール。 短縮/圧縮の自然な提 案をLLMで生成。 UIデザイン情報を読み取り、 Draft Agentと交渉し、自然さと 最適な文長を提示。 制約の最適解を合意形成。 CulturalGapDete ctor NGワード・危険な文 化参照の単純検出。 “なぜ危険か” の説明 コメントを返す。 Tone/Emotionと連携し、物語の 文化背景をLLMが推定し、 意図を壊さない文化変換案を調 安全な置き換え表現を提案。 停。 OverrideMemory 最終訳の保存だけ （判断なし）。 過去の同キャラの決 定をLLMが一行で要 約して返す。 一貫性維持のための「パー ソナル翻訳スタイル提案」 を返す。 全Agentの判断に“翻訳者の最終 意志”を反映する調停役へ昇格。 ParallelCandidate LLMで複数候補生成 （スタイル別）。 候補ごとに「意図」 や「向き不向き」コ メントを返す。 作品文体やキャラ設定を踏 まえた候補バリエーション を増やす。 Tone・Culture・Lengthと“合議 して”最適候補を生成。 修正ログ保存のみ。 類似例を返し、LLM で1行アドバイス。 Vector Search＋LLMで 「過去の自分のパターン」 を学習して提案。 Tone/Parallel と協調し、過去の 判断をリアルタイム反映。 FeedbackLogger → FeedbackAgent Lv3 ちょっとだけAgent Lv4 Multi-Agent（開発中）

Agent のイメージはまさにこんな感じでした • 調停役がいないと、あんまり楽になった感じしないよね

Google 提供・エージェント開発キット：Agent Development Kit Vibe理解 →「完全に理解した」→「何もわからない」 → 「チョットデキル」 辛かったこと • いつまで経ってもADKの価値がわからなかった • 初期はエージェント間の調停が実感しにくい • チュートリアル（お天気Bot）ではADKの価値はわかりにくい （ふつうのPython ツール書いたほうが楽） • 文字数カウントなどのツールのシナリオでは、全く Code 減らない • ADKの抽象化で逆に迷子になる • 用語 オーケストレーター ＝ ルーター ＋ 調停レイヤー

Google 提供・エージェント開発キット：Agent Development Kit Vibe理解 →「完全に理解した」→「何もわからない」 → 「チョットデキル」 良かったこと • Vibe理解を脱して「完全に理解した」 に移行！ • エージェントの基本構造が定義済み • ボイラープレート回避 • Phase 4 まで行くと効果が徐々に実感される # 本来毎回書く必要があるやつ class エージェントHOGEHOGE: def __init__(self): self.llm = LLMの設定を一から書く() # 毎回同じ self.memory = メモリの設定を一から書く() # 毎回同じ self.tools = ツールの登録を一から書く() # 毎回同じ self.logger = ロギングの設定() # 毎回同じ self.error_handler = エラーハンドリング設定() # 毎回同じ self.retry_logic = リトライ処理を書く() # 毎回同じ # ……まだまだ続く（50〜100行くらいになることも）

各Agent内部処理イメージ ( 将来 )

それぞれのエージェントが「意図」を共有する未来 各エージェントに「役割と目的関数」を与えられる • 例：Tone Agent 「キャラ口調と関係性の一貫性」を最大化 • Culture Agent 「文化的な違和感の最小化」目的にする エージェント間の対話・調停を設計できる • 例：「直訳だと文化的にキツい」 （ Culture Agent が警告） Tone Agent と Translation Agent が、 別案を検討する 改善サイクルをまわす（未実装） 状態（メモリ）と学習を役割ごとに持てる • Feedback Agent が翻訳者の修正パターンから ルール案を抽出し、 Rule Agent に渡す、などの長期的学習が可能 になる。ACLアソシエーション+1 説明可能性（Explainability）が得られる • 「なぜこの訳になったのか？」を • Translation Agent の案 • Tone Agent のスコア • Culture Agent の警告 という形で分解して提示できる。

• https://aclanthology.org/2024.ctt-1.pdf?utm_source=chatgpt.com

未来その2 LlmAgent Prompt: この小説のこの部分を翻訳して • LlmAgent: 分析中… • まずキャラ情報が必要 → ToneAgentを呼ぶ • 次に文化参照を検知 → CultureAgent呼ぶ • 最後に候補を生成 → ParallelAgent呼ぶ •Workbench：Workflow Agent（順番が決まっている） •Concierge：LlmAgent（その場でルーティングを決める）

まとめ • Google ADK • 個人が「小さな会社」を持てる時代がくると言われています • そのような仕組みを、体感するには、Google ADK は面白いツール • エンタメ翻訳 • 今回エンタメ翻訳について少し調べました • AIで簡単に太刀打ちできるものではありませんでした • 同時に[高度で負荷の高い人間の作業]を AI技術で軽減できる可能性も感じた ご清聴ありがとうございました。