翻訳メモリは誰のものか: 静かに進むベンダーロックインを避ける
多くのチームは、最悪のタイミングでこの構造を知ります。翻訳の発注先を替えると決め、「これまでの翻訳メモリをいただけますか」と丁寧に依頼し、それが単なるファイルの受け渡しではなく交渉であったと気づくのです。
混乱するのも無理はありません。翻訳メモリは資産に見えないからです。ビルドでもなく、企画書でもなく、社内の誰も開いたことがない。それでもこれは、これまでのすべての更新で費用を払って積み上げてきた「言い回しの決定の記録」です。運営中のタイトルで数年分たまれば、これまで受け取ったどの納品物よりも価値のあるものになっています。
この記事では、それを調達の問題として扱います。実際に何を請求しているのか。誰も意図しないままロックインがどう形成されるのか。何を、どの形式で、どの頻度で受け取るべきか。そして、同じ行にもう一度お金を払わずに発注先を替える手順です。
実際に請求しているのは何か
「翻訳メモリをください」という依頼は、多くの人が思っているより狭い請求です。メモリは原文と訳文の対であり、作業が生んだもののうちの一部にすぎません。全体像は次の4つです。
- 翻訳メモリ — 確定した原文・訳文の対。言語ペアごとの全件
- 用語 — 訳し方を合意した用語集。訳してはいけない固有名詞を含む
- スタイルガイド — トーン、丁寧さの水準、プレイヤーの呼び方、表記規則。言語ごと
- 質問ログ — 翻訳者から来た質問と、こちらが返した回答の記録
過小評価されがちなのが質問ログです。ここには、自明でない判断の理由が入っています。なぜこのキャラクターはこの口調なのか。なぜこの用語だけ一般的な訳語から外しているのか。曖昧な原文が実際には何を指していたのか。これがないと、新しい発注先は、何年も前に社内で答えた質問をもう一度してきます。しかも当時答えた人がすでに退職していれば、違う答えが返ることもあり、それはそのまま出荷されたゲームの中の不整合になります。
スタイルガイドも同じ性質を持ちます。メモリは「何と書かれたか」を教えますが、スタイルガイドは「なぜそう書いたか」を教えます。新しい書き手が、単に真似るのではなく一貫した形で書き足していくために必要なのは後者です。
所有・保持・使えること、その三つの差
「翻訳メモリは誰のものか」という問いには、実際には別々の3つの問いが隠れていて、それを一緒にしていることが不意打ちの原因になります。
1つ目は所有です。契約上、これらの資産の権利が誰にあるのか。2つ目は保持です。現時点の最新のコピーを物理的に誰が持っているのか。3つ目は可用性です。受け取ったコピーを、別の会社が別のツールに実際に読み込めるのか。実務的な意味で「自社のもの」と言えるには、3つとも満たされている必要があります。
よくある失敗の形はこうです。契約書には成果物はすべて発注側に帰属すると明記されている。メモリは発注先のツールの中にしか存在しない。書き出しは誰も一度も依頼したことがない。書面の上では自社のものです。しかし切り替えの瞬間に起きているのは、これから離れようとしている相手に、期限のないお願いをすることです。協力的な相手であっても、他社の繁忙期にそれが最優先になることはありません。
依頼する前に知っておくとよい事情がもう一つあります。発注先が複数の顧客のメモリを統合していたり、自社の汎用メモリに取り込んでいたりする場合、全体をそのまま渡すことはできません。他社のコンテンツが混ざっているからです。これは限定的な回答をする正当な理由であり、同時に「自社案件のメモリを分離して管理してもらう」ことを、終わりではなく始めに合意しておくべき理由でもあります。
ロックインはどう形成されるか
誰かが意図的に囲い込むわけではありません。既定の状態が積み重なって形成され、その仕組みは「保持」ではなく「価格」を通して働きます。
メモリを持っている発注先は、それを前提に新規案件を見積もれます。既出および既出に近いテキストは実作業が軽いので、見積もりにもそれが反映されます。メモリを持たない他社は、同じ分量を新規翻訳として見積もります。その会社にとっては実際に新規だからです。結果として、既存の発注先は毎回の相見積もりで安く見えます。品質が高いからでも、そもそもの単価が低いからでもなく、すでに買ってある作業を再利用できる唯一の当事者だからです。
コストのもう半分は請求書に載りません。既存コンテンツを訳し直すと、すでにプレイヤーの手元にある行に別の言い回しが生まれます。発注先の交代がゲームの中で見える形になる、つまり用語のずれです。スキル名、アイテム名、あるキャラクターの話し方が、あるパッチを境に静かに変わる。シリーズものや長期運営タイトルでは、このずれがタイトルをまたいで蓄積していきます。
どれも劇的ではありません。だからこそ続きます。「ロックインを受け入れよう」と誰かが決める瞬間はなく、あるのは「今回も現状維持が合理的に見える見積もり」の連続だけです。
何を、どの形式で、どの頻度で受け取るか
形式の議論は、可搬性さえ確保されていれば、思われているほど重要ではありません。翻訳メモリには標準的な交換形式があり、用語にもあります。用語については、列構成を双方で合意した表計算でも十分に代替になります。受け入れてはいけないのは、出力元のツールでしか開けない独自形式だけです。
形式より効くのは頻度です。マイルストーンごと、少なくとも四半期ごとに受け取っていれば、手元のコピーが現実から大きく遅れることはなく、引き渡しは「イベント」ではなく定例のファイル転送になります。範囲も決めておきます。全言語ペア、途中で止まった言語や後から外した言語も含めてです。その言語を復活させるときに欲しくなるのは、まさにそれらだからです。
指定の仕方としては、条項の文言よりも「受け取るパッケージの中身」を書くほうが実務的です。次のくらい具体的なら、届いたかどうかを双方が判断できます。
handover-2026-08/
tm/
en-ja.tmx 確定済み全セグメント(全ビルド分)
en-de.tmx
en-zh-Hans.tmx
terminology/
glossary.tbx もしくは合意した列構成の glossary.csv
guides/
style-guide-ja.pdf
style-guide-de.pdf
decisions/
query-log.csv 質問・回答・日付・決定者受け取ったものが本当に使えるか確認する
ファイルが届くことと、資産が移ることは別です。受領時に確認してください。関係がまだ生きていて、質問に答えてもらえるうちにです。2年後、いよいよ必要になった時点ではありません。
- セグメント数が、支払った分量から想定される範囲に収まっているか。言語ペアごとに確認する
- 言語コードが正しく一貫しているか。中国語の2つの書記体系や、中南米とスペインのスペイン語のような地域指定を含めて
- 文字化けせずに開けるか。非ラテン文字が正しく表示されるか
- 変数・プレースホルダ・タグが、削除や別形式へのエスケープをされずに残っているか
- 作成日時や出所などのメタデータが入っているか。出所のわからないメモリは、選別して使うのが難しくなる
- 難しかったと記憶している行を10件ほど抜き取り、合意した訳文で実際に入っているか確認する
- 別のツールに実際に読み込めるか
最後の項目が、他のすべてを決めます。発注先のツールでしか開かないメモリは、拡張子が何であれ可搬性を達成していません。この読み込みテストを関係の初期に一度やっておくと、まだ安く直せる時点で、思い込みが事実に変わります。
全部訳し直さずに乗り換える
資産が手元にあれば、発注先の交代は「やり直し」ではなく「仕入れ先の変更」になります。手順はおおむねこうです。書き出して検証する。メモリと用語集を依頼資料の一部として新しい発注先に渡す。そして、メモリを実際に出荷中のテキストと突き合わせて整合させる。最後の工程が重要なのは、真実はメモリではなくビルドの側にあるからです。長年のホットフィックスやエンジン上での直接修正で両者はずれており、新しい発注先が合わせるべきなのはプレイヤーが見ている表示のほうです。
そのうえで、本番の第1バッチの前に、有償の小さなパイロットを回します。自社の典型的なコンテンツを含む数百セグメント程度を、メモリを渡した状態で訳してもらいます。見ているのは、既存の口調と用語を尊重するのか、黙って「改善」してしまうのか。そして、メモリからの近似一致をどう扱うか — 採用するのか、印を付けて返すのか、書き直すのかです。
このパイロットは、意識的に決めるべき判断を一つ強制してくれます。新しい発注先は、過去の判断のいくつかに異を唱えます。そしてその一部は正しい指摘です。すでにプレイヤーが見ているテキストとの一貫性を優先することもできますし、この機会に長年の用語の問題を直すこともできます。どちらも成り立ちます。最悪なのは、その判断をせずに両方を同時にやることです。ゲームの半分が旧表記、半分が新表記になり、しかもどちらが意図した形なのかの記録が残りません。
この話の恒久的な形は、単純に「最初から資産を手元に持つ」ことです。マイルストーンごとにメモリ・用語集・スタイルガイド・質問ログを受け取っている会社は、他がよければ替えられますし、いまの相手が本当に良ければ続けられます。それは「離れるコストが高いから続けている」状態より、はるかに健全な立ち位置です。