OnlyTranslate が今は AI 翻訳強化を追加しない理由
翻訳品質を高めることは、OnlyTranslate が以前から取り組みたいと考えてきた課題です。
同種の製品も継続して調べています。最近は「AI 翻訳強化」「高品質翻訳」「意味のリライト」といった機能が増えました。より多くのページ文脈を取り入れるものや、異なる Prompt で自然な表現を強く求めるものがあります。
OnlyTranslate も同様の機能を追加したいと考えてきました。すぐに実装しなかったのは、こうした発想を見落としていたからではありません。初期の試行で、翻訳結果の振れ幅が大きいという問題が分かったためです。
同じ Prompt でもモデルを変えると結果が大きく異なります。数行の指示が一つのモデルには効いても、別のモデルでは品質が下がることがあります。タイトルや前後の文章が曖昧さを解消する場合もあれば、かえって注意をそらす場合もあります。数件の優れた訳文だけでは、方式全体が本当に良いかを判断できません。
同種の製品がこの領域へさらに力を入れるようになったため、印象だけで議論せず、評価実験を行うことにしました。
まず「良くなる」の基準を決めた
実験を始める前に、製品としての条件を決めました。
意味のリライトや二回目の推敲を、すべての段落で常に実行すべきではありません。多くの場合、読者が望むのは記事を滞りなく読み進めることであり、すべての訳文を出版品質に仕上げることではありません。一文が少し自然になる可能性のために全段落でモデルをもう一度呼び出せば、待ち時間、Token、API 費用が大きく増えます。
そこで、候補には次の条件を設けました。
- 既定ではモデル呼び出しを一回に保つ
- 利用者が理解すべき新しい設定を増やさない
- 特定の翻訳専用モデルに依存しない
- Token と待ち時間を質的に増やさない
- 複数の汎用モデルで、明確かつ安定して現行方式を上回る
最後の条件が最も重要です。「時々良い」だけなら、増えるのは信頼できる価値ではなく複雑さです。
実験1：文脈を増やせば、一回の翻訳で明確に良くなるか
実験仮説
最初の実験は、モデルが誤訳するのは情報が足りないからではないか、という直感的な仮説から始まりました。
ページタイトル、段落、翻訳対象の関係を明確にし、正確さと自然さの条件を加えれば、呼び出し回数を増やさずに曖昧さや翻訳調の表現を減らせるかもしれません。
実験設計
バージョン 1.8.2 のシンプルな翻訳を基準 L とし、文脈そのもの、Prompt の書き方、対象位置の効果を分けて比べるため、三つの候補を用意しました。
- A：構造化した文脈。 ページタイトル、翻訳対象、対象を含む段落を分けて渡します。
- B：短い文脈と自己確認。 Prompt を短くし、正確さと自然さを両立したうえで出力前に確認するよう求めます。
- C：対象位置のマーク。 原文段落内で翻訳対象の位置を示し、指示対象や語義を理解しやすくします。
小規模なサンプルでは、どの方式にも優れた訳と明らかな失敗がありました。感覚で選ばないため、テストを次の規模へ広げました。
- 実際の記事 11 出典から各 5 断片、合計 55 テスト単位
- 3 つの汎用翻訳モデル
- 温度とリクエスト条件をそろえた L、A、B、C の 4 方式
55 × 3 × 4 = 660回の翻訳
評価時には方式名をランダムな匿名ラベルへ置き換えました。各翻訳モデルの出力は、残る二つのモデルが独立して順位付けし、同順位も認めました。さらに、同じ記事の 5 断片を完全に独立した 5 出典として扱わないよう、記事単位で集計しました。意見が分かれた訳文は人手でも確認し、Token、待ち時間、重大エラー、形式エラーを記録しました。
実験結果と考察
L と同等を表す 50% を基準にした結果は次のとおりです。
| 方式 | L に対する相対得点率 | 主な問題 |
|---|---|---|
| A：構造化した文脈 | 53.0% | 95% 信頼区間が 50% をまたいだまま。平均総 Token は約 100 から 234 へ増加 |
| B：短い文脈と自己確認 | 50.0% | モデルによって優劣の方向が逆転し、重大エラー率は 15.2% |
| C：対象位置のマーク | 31.8% | 形式エラー率は 42.4%。弱いモデルではマーカーや不正な形式が出力された |
53.0% は「翻訳品質が 3% 上がった」という意味ではありません。勝ち・引き分け・負けの比較点が、基準と同等の 50% をわずかに上回っただけで、信頼区間からは実質的な差がない可能性を排除できませんでした。
第1ラウンドでは、現行翻訳を安定して明確に上回る候補はありませんでした。
A だけが良い方向の傾向を示しましたが、差は小さく、Token は二倍以上になりました。B からは、自然な表現や自己確認を強く求めても、モデルをまたいで通用するとは限らないことが分かりました。C からは、理論上は正確な文脈構造でも、モデルが出力形式を守れなければ製品上の不具合になることが分かりました。
この実験の重要な結論は「文脈に価値がない」ではありません。一部の文が文脈によって改善しても、既定の翻訳全体を安定して改善できるとは限らないということです。
実験2：文脈を抑制的に使えば、より安定するか
実験仮説
すぐには諦めませんでした。第1実験の問題は、文脈そのものではなく、量が多すぎること、構成が複雑なこと、または Prompt が同時に多くの仕事を求めすぎたことかもしれません。
新しい仮説では、完全な段落を翻訳単位として維持し、タイトル、選択テキスト、単独の短文だけに的を絞った文脈を追加しました。Prompt も、一回の呼び出しで正確さを優先し、情報を増減しないという簡潔な指示へ戻しました。これなら文脈による曖昧さ解消を残しつつ、複雑な指示が生む振れを減らせるかもしれません。
実験設計
第2実験では同じ 11 出典、55 断片、3 モデルを使い、基準と新しい候補だけを比較しました。
- 各断片について基準訳と候補訳を一つずつ生成し、合計 330 回翻訳
- 165 組の一対一比較
- 匿名順位付けと二つの独立した評価モデルを継続し、勝ち・同等・負けを 1、0.5、0 点として計算
- 総合得点率だけでなく、モデル別の方向、平均品質点、人が読んだときの印象も比較
50% は候補と基準が全体として同等であることを表します。この線を明確に上回り、複数モデルで同じ方向に改善して初めて、新しい既定方式の候補になります。
実験結果と考察
第2ラウンドで最良だった候補の結果は次のとおりです。
| 結果 | 件数 | 割合 |
|---|---|---|
| 候補が良い | 52 | 31.5% |
| 同等 | 90 | 54.5% |
| 基準が良い | 23 | 13.9% |
勝ちを 1 点、引き分けを 0.5 点とした相対得点率は 58.8% で、50% の同等線を 8.8 ポイント上回りました。これは「翻訳品質が 8.8% 上がった」という意味ではなく、この一対一の採点方式で候補がより多くの比較点を得たという意味です。5 点満点の平均品質スコアも 0.23 点上がりました。数値上は、これまでで最も有望な結果でした。
しかし、通常の読書と人手による確認では、根本的な問題が残りました。90 組、つまり半数を超える訳文に明確な違いがなく、同じ文でもモデルによって反対方向の結果になることがあります。23 組の後退は、誤訳、欠落、不自然な言い換えとして現れました。
ここで二つを分けて考える必要がありました。実験全体で優位であることと、製品で一貫して体感できる改善であることは同じではありません。 58.8% は研究を続ける理由にはなっても、連続して読むときに改善をはっきり感じられる証明にはなりませんでした。
もう一つの仮説：不満のある段落だけを改善する
実験仮説
常時強化のコストが高いなら、通常翻訳は変えず、気に入らない段落だけ「精密翻訳」や「訳文を改善」で処理する方法はどうか――これは実験中に私たち自身が発展させた案です。既存の競合機能をそのまま取り入れたものではなく、品質とコストの別の均衡点を探す試みでした。
追加呼び出しを少数の段落へ限定でき、理論上は記事全体を遅くしません。
実際に起きた問題
しかし、新たな問題がすぐに現れました。
- モデルが明確な問題を見つけて直すのではなく、別の言い方へ変えるだけになりやすい
- 見出し、カード、ナビゲーション、GitHub のホームのような記事以外のページでは、操作を置く自然な場所がない
- 本文段落だけに表示するには、まず本文を高精度で判定する必要がある
- 「先に審査し、維持か修正かを決める」構造化出力にしても、モデルの判断自体が安定しない
考察
ボタンを作ることは簡単でも、押した後にたいてい良くなると証明することは簡単ではありません。必要時だけの精密翻訳は追加呼び出しを減らしましたが、「本当に改善したとどう確認するか」という核心は解決せず、配置と本文判定の複雑さも増やしました。
現在の答え：通常翻訳は安定させ、難しい箇所は選択翻訳へ
最終的に、AI 翻訳強化を既定機能にはせず、効果が安定しない「精密翻訳」操作も残しませんでした。
よりシンプルな現在の方針は、実際の読み方にも合っています。
- 通常のページ翻訳は安定性と速度を優先します。 ページタイトルは弱い文脈としてのみ使い、モデルが返せるのは翻訳対象だけです。
- 分かりにくい、または訳に不満がある箇所には選択翻訳を使います。 単語、句、文だけを選択し、段落内の局所的な文脈で解釈し直せます。
- 選択結果には範囲保護があります。 モデルが誤って段落全体を返した場合、その結果を表示もキャッシュもせず、段落の文脈を外して一度だけ自動再試行します。
選択翻訳は「高品質モード」の名前を変えただけのものではありません。対象が明確で、利用者が意図して実行し、本当に理解が必要な箇所だけに追加コストを使えることが利点です。すべての記事と段落で Prompt や呼び出しを増やし続けるより、OnlyTranslate が重視する品質、性能、コストのバランスに合っています。
注視は続けるが、当面の重点にはしない
今後もモデル、Prompt、文脈技術の最新動向を追い、適切な時期に新しい方法を改めて検証します。ただし、これまでの実験結果を踏まえると、AI 翻訳強化を当面の重点にする予定はありません。より安定し、目的が明確で、利用者が変化を実感しやすい改善に力を注ぎます。