たとえば第1話に、組織の兄貴分を「형님(ヒョンニム)」と呼ぶ場面があるとしよう。英語字幕はこれを「boss」と訳した。ところが第12話では「big bro」、第40話では「brother」になる。三つとも意味は間違っていない。それでも視聴者は「あの人の呼び名、なんでコロコロ変わるんだ?」と引っかかってしまう。翻訳が話数を重ねるうちに少しずつズレていくこの現象を、drift(ドリフト、漂流)と呼ぶ。
一文だけ切り出して見れば、三つのうち間違っているものはない。問題は文の外側、シリーズ全体を貫く一貫性のほうにある。SMARTはまさにこの点を狙った字幕翻訳システムだ。役割を分担した複数のAIが協調する構造(マルチエージェント)であり、核心は翻訳を進めている最中に自ら作業のやり方を修正する点にある。著者らが併せて公開した評価環境Subtitle Arenaにおいて、15の翻訳方向すべてで1位を記録した。
まとめると、SMARTが指摘するボトルネックは翻訳モデルの実力ではない。易しいセリフには過剰な工程が浪費され、難しいセリフには肝心の専門家が投入されないという構造的なミスマッチだ。これがなぜ生じるのかは、従来方式の三つの限界に具体的に表れている。
第一に、長い文脈を最後まで保持して一貫性を守る力が弱い。単一のAIを字幕用に調整したり、周辺のセリフとあらすじの要約を一緒に与えたりする方式はあるが、結局は文単位で考える。だから繰り返し登場する呼称や固有名詞が、先ほどの「형님」のように話数を重ねるうちにズレていく。
第二に、協調工程がシーンの難易度と無関係に固定されている。複数のAIが翻訳・検収・修正を分担する方式もあるが、役割と手順をあらかじめ固定してしまっている。単純なあいさつだろうと、文化的な含みの深いジョークだろうと、同じ工程にそのまま載せてしまう。
第三に、ジャンル・時代背景・文化といった制作上の文脈を、その都度引き込んで反映できない。
ここに字幕ならではの物理的な制約がもう一つ加わる。1行に収まる文字数、字幕が画面に留まる時間に対する文字量(読む速度)といった画面表示のルールだ。意味が合っているだけでは失敗だ。訳文が長すぎて画面からはみ出せば、それだけで脱落となる。
SMARTの核心は一文で要約できる。土台となる大規模言語モデル(膨大な文章で学習して文章を生成するAI、LLM)を再学習させず、翻訳を進めている最中に自ら作業のやり方を修正していく。モデルの内部の数値(パラメータ)をいじるのではない。モデルに与える指示文と、「どの文を誰に任せるか」のルールだけを自然言語で書き換える。こうしてサービスが実際に動いている時点で設定を調整することを、テスト時学習(test-time training)、つまり本番作業をしながら行う学習と呼ぶ。
SMARTの進化は二つの活動から成る。一つは翻訳を遂行する仕事(翻訳ループ)、もう一つはその結果を踏まえて作業のやり方そのものを改善する仕事(改善ループ)だ。
一番下に敷かれた仕組みは、翻訳チームが共有する一冊のノートだ。著者らはこれを持続的シリーズ記憶と呼ぶ。ノートには四つが蓄積される。用語プール、登場人物のプロフィール、シーン・ドメイン知識、慣用表現バンクだ。あるエピソードを翻訳する前にこれまでのノートを取り出して読み、新たに確定した情報は翻訳が終わった後にふたたびノートへ統合する。すべての翻訳者とツールがこのノートを参照する。だから「형님」を一度「boss」と確定すれば、第40話の翻訳者も毎回新たに悩まず、ノートから「前回はbossだったな」をすぐに取り出して使う。一貫性が文単位からシリーズ単位へと引き上がる。
なぜノートを別に置くのか。すべての情報を毎回プロンプト(モデルに一度に渡す指示文のまとまり)に詰め込めば、三つの損が出る。一度に入れられる分量(コンテキストウィンドウ)には限界があり、長いシリーズ全体を収められない。仮に収めても、モデルが集中すべき核心を見落としやすい。文字数が増えるほどコストもかさむ。だから全体を抱え込むより、いまこの文に必要な断片だけを選んで取り出して使うほうがよい。ノートは、個々の呼び出しのコンテキストウィンドウを超える長期記憶を外部に別途保管しておく仕組みというわけだ。
ここにシリーズのジャンル・背景・主要人物をまとめた軽量なコンテンツプロフィールも別途置く。曖昧なスラングや文化的な指し示しは外部検索で事実を探してくるが、その事実を現在のシーンの文脈で解釈したうえで保存する。外部知識の「事実」と、字幕に合う「口調・表現」を分けて保管するという発想だ。
その上でルーターが仕事を割り振る。ルーティングとは、どの文をどの翻訳者に送るかを決める作業だ。文ごとにすべての翻訳者を呼ぶわけではない。文の長さ、シーンのトーン、スラングや罵倒といったシグナルを見て、呼ぶ翻訳者を選ぶ。翻訳者たちはそれぞれ異なる強みを担う。ある者は意味の忠実性、ある者は自然さ、またある者は字幕の長さ制御や口語体の処理に特化している。易しい文には少なく、厄介な文には専門家をより多く投入する。
選ばれた翻訳者たちはそれぞれ候補訳を出す。このとき、先に述べたノートから確定済みの用語と、似た訳をした過去の文を選んで取り出し、字幕制約のチェックや目標言語の流暢さ点検といったツールも呼び出す。
候補が集まると、審判役のAIが各候補を五つの軸で評価する。意味の正確さ、流暢さ、文体・語調、長距離の一貫性、字幕表示の制約だ。スコアとともに「何が、なぜ物足りないのか」を突いた批評を出す。最も高いスコアの候補を選んだうえでこの批評でもう一度練り上げ、確定した訳をノートへ反映する。エピソードが終わると全体をもう一度さらって、文を一つだけ見ても捉えにくい残りの一貫性エラーを手直しする。
ここですぐに押さえておくべき盲点がある。審判と翻訳者が同じ土台モデルの上で回っているという点だ。そのモデルがそもそも見えないエラーは、審判にも見えない。自分で書いた答えを自分で採点する構造なので、モデル固有のバイアスを自ら濾し取れないリスクが残る。著者らがより弱いモデルと別の評価者に替えて試したのは、この懸念への応答だと見える。
進化はもう一段上がる。学習のひとまとまりが終わるたびに、候補のスコアと批評を集めて二つを修正する。不振な翻訳者の指示文(繰り返される失敗を是正)、そしてルーティングのルール(スコアが高かった構成のほうへ配分を調整)だ。どちらも自然言語で書き換えられるが、好き勝手にいじるのではなく、制約を設けた書き換えだ。指示文は不振な翻訳者のものだけ手を入れ、役割と流れはそのまま残す。ルーティングは「1カテゴリあたり翻訳者は最低2名」といった下限条件を守ったまま、配分表だけを書き直す。自己修正が暴走しないようにかける安全装置だ。適用は文ごとではなく、学習の1サイクル(エポック、データを一巡する単位)に一度だけ行う。
最後の設計一つが、評価の信頼性を左右する。シリーズを二つのまとまりに分ける。前のまとまりで一部の文を実際に翻訳しながら上記の進化を回し、そうして完成した設定を「凍結」したうえで、残りのエピソードに適用する。理由は単純だ。評価すべき後半の結果をふたたび設定の修正に使えば、試験問題でこっそり勉強するようなもので、成績が水増しされる。ただし、ノートだけは適用中も伸び続ける。
まとめると、SMARTが他の自己改善方式と分かれる地点は「何を変えるか」ではなく「いつ、何を保存しながら変えるか」だ。一つの長い翻訳タスクの中で、すでに積み上げた用語と文体は守りつつ、次の文を改善する。
性能を測るにはまず測る物差しが必要だったが、既存の字幕データセットではシリーズの一貫性を測れなかった。文がばらばらに散らばっていて、同じ呼称が第40話でも維持されているかを測る方法そのものが無かったからだ。そこで著者らは評価環境から新たに作った。
Subtitle Arenaは公開字幕集OpenSubtitles2024から出発するが、決定的な違いが一つある。文を並べるのではなく、エピソード・シリーズ単位で組み直したという点だ。映画データベースの識別子(IMDb)とシーズン・エピソード番号で二言語の対応を復元し、タイムコードを保存しつつ形式エラーを正し、対応が合わないアラインメントは捨てたうえで、同じシリーズ同士でまとめて長い物語構造を活かした。規模は192シリーズ、ジャンル14種、目標言語・地域(ロケール)15種だ。英語の原本6,267本を15のロケールへ移した二言語のエピソード対は合わせて70,664対あるが、これは同じ話数が言語ごとに別々に集計される「対」の数であって、エピソードの本数ではない。制作年は1959年から2023年まで、シリーズあたりのエピソードは2本から198本にわたる。ロケール別では中国語が6,267対で最も多く、韓国語は3,243対が収められている。
スコアを付ける物差しはSubMQMだ。翻訳品質を誤りの減点で測る国際的な尺度MQM(多次元品質指標)を字幕用に翻案したもので、AI評価者が7つの次元にわたって誤りごとに減点を付ける。スコアは低いほど良い。次元別の重みは正確性に最も大きい0.30を置き、用語と流暢さに各0.20、残りを小さく配分する。意味が合っているかを最も重く見るという意味だ。
比較相手は三つのグループだ。コミュニティ字幕(品質がまちまちで正解として扱わない)、単一呼び出しのAI数種、そして役割を分担したエージェント方式のTransAgent・DRTだ。公平性のため、二つのエージェント比較群はSMARTと同じ商用モデルの上で実装し直した。
ただしSubMQMはAIを審判に使う自動評価だ。すべてのシステムに同じ評価者を適用して相対比較の公平性は確保したが、評価者自身のバイアスの可能性は、自動指標の本質的な限界として残る。数字を読むときはこの前提を敷いて見なければならない。
最もはっきりしたシグナルは、難しいセリフに専門家をより多く付ける動的配分が実際に効いたことだ。先に述べた15方向の1位に加え、最も強いエージェント比較群より平均減点を6.9%減らした。別の公開ベンチマーク(MuSC)の4言語ペアでもすべて最高で、人による評価でも最も高かった。ただしこの「5点満点中4.50」は絶対的な品質点ではない。1本の訳文そのものに品質点を付けたのではなく、5つの翻訳候補を人が見比べて1~5点の順位点を割り当て、その平均を取った相対順位のスコアだ。つまりSMARTが候補のなかで最も上位に選ばれやすかったことを示す数字であって、5点=満点の品質という意味ではない。
韓国語が絡んだ代表的な方向を見ると、数字の質感が見えてくる。英語から韓国語へ移すとき、SMARTの総合減点は0.92で、同じ方向のTransAgentの0.97、DRTの0.99より低い。逆に韓国語から英語へ行くときは0.47で、TransAgent 0.52・DRT 0.57より低い。減点は低いほど良いので、両方向とも上回っている。
とはいえ、すべての細かい次元で1位というわけではない。英語からイタリア語へ移すとき、文字数や改行といった技術的な次元では、SMARTは2.37と一部の比較群よりむしろ高い。総合スコアが意味の忠実性に重きを置くため、ある次元の損を別の次元で埋めて総合の優位を取っていく構造だと読める。「6.9%減らした」というのも最も強いエージェントシステムとの平均比較であって、すべての指標・すべての相手に対する全面的な優位ではない。ここは分けて読まなければならない。
それでも一つははっきり示している。モデルを再学習せず、指示文と配分ルールだけを自然言語で進化させても、長尺コンテンツの一貫性問題において、工程が固定されたエージェントを上回れるという実証だ。ここまでが根拠に支えられる範囲だ。運用設計がファインチューニングより優れている、といった一般化は、この結果だけでは言えない。
タダではない。SMARTは文ごとに複数の候補を作り、審判が軸ごとに採点し、批評でもう一度直し、前のまとまりで設定を進化させる。この段階がすべて追加の呼び出しだ。単一の呼び出し一度で終わる翻訳と比べれば呼び出し数が何倍にも増え、その分だけコストと応答遅延が付く。具体的な数値は論文が付録で扱っており、ここに無い数字を作り上げることはしない。方向だけ押さえると、一貫性が金になる長尺コンテンツには値打ちがあり、短く独立した作業には過剰だ。
前提も一つ敷かれる。進化に使う材料がなければならない。SMARTは前のまとまりで設定を進化させるので、エピソードが十分に長いシリーズには有利だが、短いコンテンツは進化に使うデータそのものが少ない。過学習を防いでくれる学習・適用の分離が、同時に「進化する材料がなければならない」という条件も併せて敷く。
翻訳とプロジェクト管理は遠く見えても、根底に敷かれた問題は一つだ。過去の決定を後からも一貫して再利用すること。
具体的な場面に行ってみよう。顧客企業の担当者がAIプロジェクトマネージャーにメッセージを送る。「来週金曜の納期を、その次の週に延ばしてください。」マネージャーは返信を書かなければならない。ところが三か月前、同じ顧客と「納期変更は発注書を再発行して確定した後にのみ反映する」と合意したことがある。毎回白紙から判断するマネージャーなら、この合意を見落として「はい、調整します」と答えてしまう。あとで発注書なしに日程が狂えば、責任の所在がもつれる。
SMARTが翻訳で長い呼吸の一貫性を外部記憶で解いたように、プロジェクト管理も毎回新たに判断する代わりに、過去のやりとりの文脈と用語、合意を体系的に積み上げて取り出して使うとき、成功の確率が上がる。先の場面でマネージャーがその合意をノートから取り出して「変更は発注書の再発行後に確定します」と返信すれば、10回目の依頼で3回目の依頼の決定を一貫して再利用したことになる。
検収段階もそのまま持ってくる価値がある。顧客に返信を送る前に、役割を分けた検収者が用語の一貫性・顧客の口調・依頼の充足を軸に自前の点検を回す。繰り返される失敗が見えたら、役割はそのまま残して指示文だけ制約的に直す。ただし、そのまま取り込むには条件が付く。学習分として使う初期のやりとりが十分に積み上がっていなければならず、検収者が返信生成器と同じモデルであるときの死角は、交差検証で埋めなければならない。翻訳の共有ノートとプロジェクト記憶が重なって見えるからといって、二つが同じシステムなわけではない。持ってくるべきは機能ではなく原理だ。
そのリスクを減らす仕組みが、ノートへ書き込むタイミングにあります。訳は、審判が五つの軸で採点し批評でもう一度練り上げて「確定」してからノートに反映されます。生のままの候補がそのまま保存されるわけではありません。さらにエピソードが終わると全体をもう一度さらって、残りの一貫性エラーを手直しします。それでも審判が濾し取れなかったエラーなら後ろへ伝播しうるのですが、これは審判と翻訳者が同じモデルだという盲点と地続きの点です。
物理的に別々のモデルが複数あるのではなく、一つの土台モデルに異なる役割と指示文を着せて分業させた構造だからです。同じ人が状況に応じて翻訳者の帽子、審判の帽子、配車担当の帽子をかぶり替えるようなものです。役割を分けたおかげで「候補を出す側」と「それを採点する側」を分離できますが、土台が同じ頭なので、共有するバイアスは残ります。
順序には意味があります。SMARTは前のまとまりで設定を進化させてから凍結して後ろに適用し、ノートは話数を経るごとに積み上がり続けます。先の話数で確定した用語や呼称が後の話数の翻訳の材料になる構造なので、文脈が蓄積される流れを守るほうが設計の意図に合います。