3つのLLMでブラインド多数決！構築中の Claude Sonnet 4.6 翻訳パイプラインを検証してみた

DevelopersIO では 2025 年末より、Amazon Bedrock と Claude を活用した記事の自動英訳機能を提供しています。

https://dev.classmethod.jp/articles/developersio-bedrock-translation-launch/

従来のパイプラインでも Markdown の構造を保持した翻訳はある程度実現できていましたが、本記事では Claude の最新モデル Sonnet 4.6 を採用し、さらなる翻訳品質の向上と、API の効率的な利用を目指す取り組みについて紹介します。

構成

構築中の翻訳パイプラインの構成です。

Structured Outputs で翻訳+要約+推薦文を 1 コールで

翻訳以外の情報、検索などに役立つ要約なども、1 回の LLM 実行から取得したい。その手段として最適だったのが、Bedrock の Structured Outputs でした。

https://dev.classmethod.jp/articles/amazon-bedrock-structured-outputs-json/

スキーマ設計

Bedrock の output_config.format.json_schema を使い、1 回の API コールで 9 フィールドを返させます。

{
  "type": "object",
  "properties": {
    "title":          { "type": "string" },
    "excerpt":        { "type": "string" },
    "content":        { "type": "string" },
    "summary_en":     { "type": "string" },
    "rag_en_s":       { "type": "string" },
    "rag_en_m":       { "type": "string" },
    "rag_en_l":       { "type": "string" },
    "recommendation": { "type": "string" },
    "confidence":     { "type": "integer" }
  },
  "required": ["title", "excerpt", "content", "summary_en",
               "rag_en_s", "rag_en_m", "rag_en_l", "recommendation",
               "confidence"],
  "additionalProperties": false
}

additionalProperties: false を指定することで、スキーマ外のフィールドが混入することを防いでいます。

Bedrock 呼び出し

body = {
    "anthropic_version": "bedrock-2023-05-31",
    "max_tokens": 60000,
    "system": [{"type": "text", "text": system_prompt,
                "cache_control": {"type": "ephemeral"}}],
    "messages": [{"role": "user", "content": user_prompt}],
    "output_config": {"format": {"type": "json_schema", "schema": SCHEMA}}
}
response = bedrock.invoke_model(modelId="us.anthropic.claude-sonnet-4-6", body=json.dumps(body))

翻訳プロンプトのポイント

翻訳プロンプトは system prompt に配置しています。全文は長いため、ポイントとなるルール指示を抜粋します。

- Preserve all Markdown formatting symbols (#, *, _, [], (), etc.) in their exact positions
- Never edit, modify, or translate URLs. Keep all URLs exactly as they appear in the original
- Preserve the line break structure of the original document
- Do not start the content translation with a heading

Markdown の構造保持を明示的に指示しています。URL の改変禁止は、翻訳モデルが URL 内の日本語パスを英訳してしまう問題を防ぐためです。

要約フィールドについては、用途ごとに語数と内容の粒度を指定しています。

- summary_en: 3 lines in English, max 50 words per line, Markdown bullet format (- )
- rag_en_s: ~200 words, 1 paragraph. First 80 words MUST contain what the article covers and key outcome
- rag_en_m: ~150 words, dense factual summary. Include technologies used, problem solved, approach taken

実行結果

13,479 文字の技術記事（コードブロック 8 個、Mermaid 図、テーブル多数）で検証しました。

Structured Outputs により、長文 Markdown を含む JSON でもパースエラーはゼロでした。Markdown 内のバッククォートやエスケープ文字が JSON を壊す心配がなく、後続処理がシンプルになります。

機械的 QA: 4 項目の品質チェック

翻訳結果に対して、以下の 4 項目を自動チェックしています。

前処理として改行コードを正規化（\r\n → \n）しています。

これに加えて、前述の confidence スコア（0-100）を組み合わせて異常検知に使います。confidence が低い記事は人間レビューの対象とする運用です。

パイロット記事では全項目 pass、confidence 93 でした。

LLM-as-a-Judge: 3 モデルブラインド多数決で品質検証

なぜ LLM-as-a-Judge か

機械的 QA は「見出しが消えた」「URL が変わった」といった構造的な問題は検出できますが、「翻訳が自然か」「技術用語の選択が適切か」は測れません。かといって人間評価は 50 件規模でもコストと時間がかかります。

そこで、複数の LLM に翻訳品質を採点させ、多数決で判定する LLM-as-a-Judge を採用しました。

評価モデルの選定

3 つのモデルを評価者として使用しました。Nova Pro と gpt-oss-120b は Amazon Bedrock 上で利用可能で、Gemini 3.1 Pro は Bedrock 外で手動実行しました。各モデルの特性は評価結果のセクションで詳しく紹介します。

バイアス排除の設計

LLM-as-a-Judge には 2 つの強いバイアスがあります。

バージョン番号バイアス（アンカリング）: プロンプトに「Sonnet 3.7」「Sonnet 4.6」と書くと、LLM は「新しいバージョンの方が優れているはず」という事前知識に引きずられる可能性があります。

位置バイアス: 翻訳の提示順序（A/B）が判定に影響する傾向が報告されています。

これらを排除するため、以下の対策を実施しました。

1. モデル名マスキング: プロンプトには「Translation A」「Translation B」とだけ記載し、モデル名・バージョン情報は一切含めない
2. A/B 順序ランダム化: 記事ごとに A/B の割り当てをランダムに入れ替え、評価後にスクリプト側で結果を自動反転

評価プロンプト

評価プロンプトは英語で記述しました。評価モデルは英語をより得意とする傾向にあるため、評価の精度と安定性を優先しています。

以下が実際に使用したプロンプトの全文です。

You are an expert bilingual (Japanese-English) technical translation evaluator.
Compare two machine translations of the same Japanese technical blog article.
You MUST choose a winner — ties are NOT allowed.

## Evaluation Criteria (1-10 scale)
1. Accuracy — faithful meaning, correct technical terms, preserved numbers/data
2. Naturalness — reads like native English engineer writing, not "translated Japanese"
3. Technical Precision — AWS/API/code terms handled correctly
4. Structural Fidelity — Markdown structure (headings, tables, code blocks) preserved
5. Readability — easy to follow, logical flow

## Response Format
Return ONLY valid JSON (no markdown fences):
{
  "accuracy_a": <int>, "accuracy_b": <int>,
  "naturalness_a": <int>, "naturalness_b": <int>,
  "technical_a": <int>, "technical_b": <int>,
  "structural_a": <int>, "structural_b": <int>,
  "readability_a": <int>, "readability_b": <int>,
  "winner": "A_much_better" | "A_slightly_better" | "B_slightly_better" | "B_much_better",
  "summary": "<one paragraph explaining the key differences that determined the winner>"
}

---
## Original Japanese

### Title
{ja_title}

### Excerpt
{ja_excerpt}

### Body
{ja_content}

---
## Translation A

### Title
{a_title}

### Excerpt
{a_excerpt}

### Body
{a_content}

---
## Translation B

### Title
{b_title}

### Excerpt
{b_excerpt}

### Body
{b_content}

5 軸（Accuracy, Naturalness, Technical Precision, Structural Fidelity, Readability）で各 1-10 のスコアを付けさせ、総合勝者と差分の要約を JSON で返させています。

評価結果

品質検証のため、Sonnet 4.6 による翻訳と既存の翻訳パイプラインによる翻訳結果を A/B 比較しました。

Nova Pro + gpt-oss-120b 評価

最初の評価では Tie（引き分け）を許容するスキーマで実施しましたが、Nova Pro が 72% の記事で Tie と判定し、評価として機能しませんでした。LLM は差が僅差の場合、最も安全な選択肢である Tie を選ぶバイアスがあるようでした。

そこで Tie を排除した Forced Choice（強制二択）に切り替え、4 段階評価（A_much_better / A_slightly_better / B_slightly_better / B_much_better）で再評価しました。

モデル別の内訳です。

Nova Pro は Forced Choice にしたことで全件に明確な判定を出すようになり、Sonnet 4.6 を圧倒的に支持しました。gpt-oss-120b も Sonnet 4.6 優勢ですが、旧翻訳を選んだ記事が 21 件ありました。

gpt-oss-120b が旧翻訳を選んだ理由の分析

gpt-oss-120b が旧翻訳を選んだ 21 件の summary を分析したところ、明確なパターンがありました。

特に空だった Excerpt のハルシネーションは、プロンプトに 1 行追加するだけで 7 件が改善する可能性が高く、具体的な改善ポイントとして有用な発見でした。

Gemini 3.1 Pro 詳細評価

AIアシスタントのKiro (Opus 4.6) に以下の方針でサンプルを8件選定させ、出力された判定用プロンプトをWebブラウザ版の Gemini に入力して評価しました。

• 最長記事（33,330 文字）と最短記事（415 文字）を含める
• 機械的 QA が fail した記事を含める
• 技術記事だけでなく非技術記事（入社ブログ）も含める
• Nova と gpt-oss で判定が割れた争点記事を含める

Gemini が指摘した Sonnet 4.6 の強み

意訳力: 日本語の略語や口語表現を、英語圏で通じる表現に変換していました。

「LT」は日本の技術コミュニティでは一般的な略語ですが、英語圏では通じません。Sonnet 4.6 は "lightning talk slides" と展開しており、Gemini はこれを高く評価しました。「差分として検出され」を "detected as a diff" と訳した点については「Terraform を実際に書く人が翻訳したように読める」とコメントしています。

構造保持: Sonnet 4.6 は :::message や :::details といったカスタム Markdown ブロックを正確に保持していました。旧翻訳では :::message ブロックが丸ごと削除されるケースがありました。

文章の再構成: 日本語の長い一文を、英語圏の慣習に合わせて "First... Second... Third..." と分割するなど、単なる翻訳を超えた編集を行っていました。

改善が必要なケース

Gemini 3.1 Pro の詳細評価で旧翻訳が勝利した NocoDB の記事（1,589 文字）から、具体的な改善ポイントが見つかりました。

• 空フィールドのハルシネーション: 原文の Excerpt が空だったにもかかわらず、Sonnet 4.6 は本文の冒頭をコピーして Excerpt を埋めてしまいました
• 全角括弧の未変換: （） を半角 () に変換しなかった

空フィールドのハルシネーションは前述のバッチ評価でも 7 件で確認されており、プロンプトに「空なら空文字を返す」を明記するか、コード側の前処理で対処できます。全角括弧の変換は後処理の str.replace で機械的に解決すべき問題であり、LLM に任せるべきではありません。

プロンプトチューニングの実施と再評価

上記の評価結果を受けて、翻訳プロンプトに以下の 4 項目を追加しました。

- If a field (title, excerpt) is empty in the source, return an empty string. Never fabricate content
- Translate image alt-text (e.g. ![日本語テキスト](...) → ![English text](...))
- Adapt section headings to natural English conventions rather than translating word-for-word
- Proofread your output for typos and grammatical errors before responding

デプロイ後、旧翻訳に負けた NocoDB 記事と Tie だった FSx 記事を再翻訳し、同じ評価スクリプトで再評価しました。

NocoDB 記事の具体的な改善点です。

なお、ハルシネーションで生成された Excerpt の内容を確認したところ、記事を適切に要約した内容でした。今回は翻訳の忠実性を優先し「空なら空を返す」というプロンプトチューニングを実施しましたが、翻訳の前工程で日本語の Excerpt が存在する状態とする方向の調整も予定しています。

各評価モデルの特性比較

Nova Pro: 高速（2-5 秒）で低コストです。Tie を許容するスキーマでは 72% が Tie に逃げましたが、Forced Choice に切り替えたところ全件で明確な判定を出しました。ただし slightly_better がほとんどで、差の程度は控えめです。大量記事の一次スクリーニングに向いていると思われます。

gpt-oss-120b: reasoning（思考過程）付きで、1 セクションずつ丁寧に比較します。空 Excerpt のハルシネーションや構造の微差など、具体的な改善ポイントを summary から読み取れるのが強みです。一方、reasoning モデル特有の出力形式により JSON パースに失敗するケースがあり（初回 15/51 件、リトライで 1/51 件に改善）、出力の安定性には注意が必要でした。

Gemini 3.1 Pro: 最も詳細な評価を返しました。具体的なフレーズを引用し、「なぜその訳が良いのか」を説明してくれます。typo の検出、ハルシネーションの指摘、さらには「Terraform を実際に書く人が翻訳したように読める」といった文脈を踏まえたコメントまで含まれていました。判断に迷うケースでは Gemini の評価が最も参考になりました。

まとめ

構築中の Sonnet 4.6 の翻訳パイプラインについて、従来版の品質を上回る目処をつけることができました。特に意訳力、カスタム Markdown ブロックの保持、英語圏の文章慣習への適応において優れた結果を示しています。

一方で、gpt-oss-120b や Gemini の評価から、空フィールドに起因するハルシネーションなど、前処理やプロンプトチューニングで対処すべき具体的な課題も明らかになりました。実際にプロンプトを修正して再評価したところ、旧翻訳に負けていた記事も Sonnet 4.6 勝利に逆転しています。今回導入した LLM-as-a-Judge は、修正後の品質を素早く判定できるため、改善サイクルの効率化が期待できます。

Sonnet 4.6 へのアップデートと併せて、LLM を活用した評価・改善の仕組みの基盤を整えることができました。今後も翻訳品質の継続的な向上を通じて、より多くの方に技術情報を届けていきたいと考えています。