# Claude Codeの翻訳パイプラインに流暢さゲートを追加する — Andrew Ngのリフレクションパターンを参考に > 外部のレビューが、このClaude Codeパイプラインの翻訳QAでは見つけられなかった欠陥をzh-TW訳から見つけました。対策として、研究に基づくSection Cゲートを追加しています。 - Source: https://oharu121.com/ja/blog/claude-code-translation-fluency-gate-reflection-pattern/ - Published: 2026-09-01T13:24:53+09:00 - Tags: Claude Code, 国際化, 自動化 --- ## はじめに 外部のAIレビューアーが、このブログの[cloud-publish記事](/blog/claude-code-routine-cloud-publish-hands-free-merge/)のzh-TW訳を読み、実在する二つの欠陥を見つけました。英語の節構造をそのまま持ち込んだ冒頭の一文と、同じ原語が、ある図のキャプションとその直後の段落とで二通りに訳し分けられていた箇所です。このブログの翻訳レビューゲートは、まさにそうした乖離を捉えるために、毎回の公開前に走っています。それでも外部のレビューアーの方が先に見つけたということは、まだ名前の付いていない死角がゲートにあったことを意味します。その死角は、レビューアー自身が提案したロケールごとの専門エージェントより、実は狭いものでした。二つの欠陥のうち一つには、このブログ自身のハウススタイルにすでにルールが書かれていました。**実際の対策は、他の場所でAI翻訳のQAがどう作られているかという研究を参考にした、より狭い第二のレビューパス**でした。この記事では、レビューが見つけたこと、既存のゲートがなぜそれを見つけられなかったのか、対策の背景にある研究、そして今パイプラインに組み込まれているゲートを順に見ていきます。この記事を書いている時点では、まだ実際の翻訳で検証されていません。 ## 外部レビューを一行ずつ確かめる このレビューは、すでに公開済みだったzh-TW訳を採点する、別のAIセッションから届きました。指摘のほとんどは、ファイル自体と照らし合わせても本当のことでした。Introductionの二段落目は**それ自体で論旨が埋もれてしまうほど密度の高い一文**で始まっていましたし、`的`の前には英語の関係節のように修飾語が積み重なっており、同じ英単語「unattended」は、ある図のキャプションでは無人看管、その直後の段落では無人値守と訳し分けられていました。**一つだけ、成立していない指摘がありました。** レビューは、この記事にはまだフロー図がないと述べていましたが、実際にはありました。``という図が初回公開の時点からすでに記事に含まれていて、ローカル側とクラウド側の分かれ目、そしてレビューアーが「無い」と言ったマージの判断分岐を、まさにそのまま示していました。 その一つの誤った指摘は、この先を読むうえでも覚えておく価値があります。**外部レビューは有用な証拠であって、読まずに従う判定ではありません。** ## 既存のゲートが両方とも見逃していた理由 このブログの公開パイプラインは、各ロケールを公開する前にすでに一つの翻訳チェックを走らせています。レビューゲートのSection Bです。原文との正確性、網羅性、見出し文字列の固定、タイトルの作り直し、共有の用語集との突き合わせ、そして訳し漏れの有無をチェックします。**そのどの項目も、意味は何も変えていないのに英語の語順をそのまま映しただけの一文を見つけるようにはできていません**。同じ用語の二通りの訳し分けについても、どちらの訳も間違っておらず、どちらも用語集に載っていない場合、これらの項目のどれも捉えられません。 最初の思いつきは、同じチェックリストに項目を二つ足すことでした。それが持ちこたえたのは、異議を唱えられるまでのわずかな間だけでした。チェックリストで進める客観的なパスに主観的な判断を混ぜると、その主観的な判断は、すでに列の前に並んでいる項目と同じ、表面をなぞるだけの扱いを受けるリスクがあります。**Section Bにはすでに九項目あり、この二つは十番目と十一番目になるだけでした。** ## 他の場所では実際どうなっているか それを決着させるには、この一つのブログの外でAI翻訳のQAがどう作られているかを、推測ではなく実際に見る必要がありました。[Andrew Ngの`translation-agent`プロジェクト](https://github.com/andrewyng/translation-agent)は、同じモデルに対して三つのプロンプトを順番に走らせます。最初の翻訳、四つの観点(正確性、流暢さ、文体、用語)で最初の下書きを批評するリフレクションのパス、そしてその批評を使って書き直すリファインメントのパスです。そのリファインメントのプロンプトは、用語について「文脈に対して不適切、**訳し分けに一貫性がない**」とほぼそのままの言葉で名指ししており、このブログのzh-TWでの一件とほとんど同じです。翻訳ベンダーの側からも、同じ形に収れんしています。**SmartlingとLiltは、どちらも品質レビューを翻訳そのものとはアーキテクチャ上はっきり分かれたパスとして走らせています**。そしてWMTが2021年から自らの人手評価の標準として使っているMultidimensional Quality Metrics(MQM)というフレームワークは、Ngのプロンプトが独立に行き着いたのと同じ四つのカテゴリで採点します。 **そのどれも、専門エージェントのチームを組む根拠にはなりません**。Ngのリフレクションループは、一つのモデルに二つのプロンプトを、一つのセッションの中で走らせるだけで、別々の人格を演じさせているわけではありません。研究で見つかった複数エージェントのアーキテクチャ(CEO、複数の編集者、校正担当者からなる架空の翻訳会社)は、超長文の文芸翻訳に対して効果が確かめられたものであって、ブログ記事向けではありません。比較としてDeepLは、第二のパスを走らせるのではなく、より強力な単一モデルを訓練することで流暢さを得ています。これは、汎用APIを呼び出すだけのパイプラインには取れない選択肢です。 この根拠には現実の限界があり、それを省かず率直に述べておく価値があります。Ng自身のREADMEは、このプロジェクトを「成熟したソフトウェアではない」と述べていますし、節のスタッキングや内部の一貫性の検出率をこの技術について測定した情報源も、調べた範囲では見つかりませんでした。**この設計の根拠は、ベンチマークではなく、プロンプトの文言がこのブログ自身の一件と一致しているという点にあります。** ## すでにファイルの中にあったルール 研究が裏付ける必要のなかったことが一つあります。このブログ自身の[ハウススタイルガイド](https://github.com/oharu121/oharu-tech-blog/blob/main/.claude/skills/blog/house-style.md)には、節のスタッキングの半分についてはすでにルールがあり、まさにこの理由のために何か月も前に書かれていました。ターゲット言語ごとの規約はこう明言しています。*「従属節を二つ以上持つ原文の一文は、そのまま残すのではなく分割する」*。zh-TW記事がこのルールの説明そのものの一文を抱えたまま公開された時点で、**このルールはすでに存在していました**。実際に公開時に走るレビューゲートは、翻訳後の文章に対してこのルールを一度も指し示していませんでした。翻訳者が読むはずのスタイルガイドの中に置かれたままで、レビューパスが実際にたどるチェックリストには入っていなかったのです。 だからこそ、最初の思いつき、すでに長いチェックリストに二行足すというやり方は、それだけでは足りなかったはずです。**ルールは文章としてすでに存在していたのに、それでもチェックされないままでした**。これは、ほかに何も競合しない専用の読み直しを行う根拠であって、読み飛ばしやすいもう一行を足す根拠ではありません。 ## 第二の、より狭いパス 対策は、レビューゲートの新しいセクションとして着地しました。Section Cです。同じロケールに対してSection Bのすぐ後に走り、原文と一文ずつ突き合わせるのではなく、翻訳後のファイル全体をネイティブの読み手として一度読みます。 *Figure — ReviewGatePipeline: Section Cは同じロケールに対して、ファイルが公開される前、Section Bの直後に走ります。* **旧来のチェックリストが一度も触れていなかった三つのことをチェックします**。一文がすでにあるルールに反して原文の節構造を言語の境界を越えてそのまま持ち込んでいないか、用語集が何と言おうと同じ繰り返し出てくる用語が文書全体で同じように訳されているか、そしてトーンが「はじめに」から「まとめ」まで一定に保たれているかです。外部レビューが実際に指摘した内容にこれを当てはめると、何を捉えるためのものかが分かります。 *Figure — SectionCFindings: 外部レビューが見つけた二つの指摘を、Section Cが行う二つのチェックと突き合わせたもの。* 「unattended」のどちらの訳し方も、それ自体は間違っていませんし、どちらもこのブログの用語集には載っていません。だからこそSection Bの用語チェックは、用語集**からの**乖離を捉えるようにできていて、このどちらとも比較する対象を持っていなかったのです。**Section Cは、翻訳が実際に公開される両方の場所に組み込まれています**。ローカルの`/blog publish`コマンドと、ルーチンが記事を無人のまま公開するときに読むタスクリストです。誰も見ていない状態でこれを走らせるルーチンも、人が起動する公開と同じチェックを受けることになります。 ## まとめ このブログの翻訳レビューゲートには、今や三つ目のセクションがあります。翻訳後のファイル全体を読み、流暢さ、用語の内部での一貫性、トーンをチェックするもので、すでに走っていた正確性と網羅性のチェックに上乗せされます。今回のきっかけになった二つの具体的な欠陥、節がスタッキングした一文と、一つの英単語の訳し分けは、Section Cのチェックリストが名指ししている二つのカテゴリそのものです。**実際の翻訳でこのどちらかの欠陥を本当に捉えられるかどうかは、まだ開いたままの問いです**。リフレクション形式のパスがこのどちらかの欠陥をどれだけの割合で検出するかを測定した情報源は、調べた範囲では見つかりませんでした。この設計の根拠は、測定ではなく、今回の一件と、そこから借りてきた公表済みのパターンとの間で文言が一致しているという点にあります。**このブログがフルパイプラインを通して翻訳する次の記事、つまりこの記事自身が、それを試す場になります。** この文章そのものではありません。 ## 参考リンク - [Andrew Ngの`translation-agent`](https://github.com/andrewyng/translation-agent): Section Cが形を借りている、翻訳・リフレクション・リファインメントのワークフロー。 - [Multidimensional Quality Metrics, 2013](https://aclanthology.org/2013.tc-1.6.pdf): WMTが2021年から使っている人手評価のフレームワークで、Ngのプロンプトが独立に行き着いたのと同じカテゴリ分けを持つ。 - [SmartlingのAI品質推定について](https://www.smartling.com/blog/ai-quality-estimation)と[LiltのAI Review](https://lilt.com/ai-review): 二つの翻訳ベンダーが、レビューを生成そのものとは別のパスとしてどう設計しているか。 - [DeepLの次世代言語モデルについて](https://www.deepl.com/en/blog/next-gen-language-model): 対照例。第二のパスではなく、より強力な単一モデルから流暢さを得ている。