日本語を自然な英文へ翻訳する Memolog の取り組み

Memolog では、日本語の記事と英語の記事を公開しています。多言語対応を始めた当初は、日本語だけを書き、Azure AI Translator で英語版を自動生成していました。

この方法は、英語ページを早く用意するには便利です。しかし記事が増えるにつれて、意味は通じても、英語の記事として読むと不自然な表現が残ることが気になりました。検索結果に表示されるタイトルや説明文が直訳調だと、記事の内容へたどり着く前に読者の信頼を損なう可能性もあります。

そこで現在は、機械翻訳を完成品ではなく初稿として扱い、自然な英文への書き直し、独立レビュー、JA / EN の同期検証を通してから公開する運用へ移行しました。この記事では、以前の仕組みと現在の仕組み、その変更で何を解決しようとしたのかを紹介します。

目次

• 先に結論
• 以前は Azure AI Translator で英語版を自動生成していた
• 機械翻訳だけでは足りないと感じた理由
• 現在の英訳フロー
• 自然な英文にするための工夫
• JA と EN の同期漏れを防ぐ仕組み
• SEO で大切にしていること
• この運用にして分かったこと
• まとめ

先に結論

現在の Memolog では、日本語を事実上の正本とし、機械翻訳は英語初稿を作るためだけに使っています。

英語版は、次の流れで作成します。

1. Azure AI Translator で日本語から英語の初稿を作る
2. Azure OpenAI の GPT モデルで、直訳調の文章を自然な技術英語へ書き直す
3. 独立した編集担当で、記事全体を英語として読みやすく整える
4. 別のレビュー担当で、日本語との意味の一致と英語の自然さを確認する
5. JA / EN 両方のハッシュを記録し、片方だけ変わった状態を CI で拒否する

単純に高性能な翻訳モデルへ置き換えたのではありません。翻訳、編集、事実確認、同期検証を分けたことが、この運用で最も重要な点です。

以前は Azure AI Translator で英語版を自動生成していた

多言語対応を始めた当初は、日本語の記事だけをリポジトリへ保存し、GitHub Actions のビルド中に Azure AI Translator を実行していました。

翻訳スクリプトは、記事の frontmatter にある title と excerpt、そして本文を日本語から英語へ変換します。一方で、コードフェンス、インラインコード、URL、MDX の import などは翻訳対象から外します。翻訳結果は英語版の記事として生成し、英語の URL で配信していました。

認証には API キーではなく、GitHub Actions の OpenID Connect（OIDC）とユーザー割り当てマネージド ID を使っています。Azure へ保存した長期シークレットを GitHub に持たせず、Entra ID のトークンで Azure AI Translator を呼び出す構成です。

この方式には、次のメリットがありました。

• 著者は日本語の記事だけを書けばよい
• 新しい記事にも英語ページを自動で用意できる
• コードや製品名を保護しながら、同じ URL 構造で JA / EN を配信できる
• canonical、hreflang、サイトマップ、inLanguage などの多言語 SEO を共通レイアウトで管理できる

最初の多言語対応としては、運用負荷を抑えながら英語版を提供できる現実的な方法でした。

機械翻訳だけでは足りないと感じた理由

課題は、翻訳が間違っているかどうかだけではありませんでした。文法上は成立していても、英語の記事として読むと不自然な文章が残ります。

たとえば、日本語の語順を保ったまま英語へ置き換えると、主語や結論が見えにくくなります。「先に結論」を Conclusion first のように直訳すると意味は推測できますが、英語の技術記事の見出しとしては Key takeaway の方が自然です。

また、日本語では文脈から省略できる主語や目的語も、英語では補わないと何を指しているのか曖昧になります。逆に、翻訳時に説明を補いすぎると、日本語に書かれていない意味や断定が加わる危険があります。

特に気になったのは、次の部分です。

機械翻訳された文章だから自動的に検索順位が下がる、と単純に考えているわけではありません。問題は、検索で訪れた読者にとって役立つ内容になっているか、タイトルと本文が意図を正確に伝えているかです。

Google Search Central の 有用で信頼性の高い、ユーザー第一のコンテンツを作成するでも、検索エンジン向けではなく、人の役に立つコンテンツを作ることが案内されています。英語ページも同じ記事として公開する以上、「意味が通じる」だけでなく「英語の読者が自然に読める」ことを品質基準にしました。

現在の英訳フロー

現在は、翻訳結果をそのまま公開せず、複数の工程を通します。

1. 日本語を正本として記事を書く

最初に日本語の記事を完成させます。英語で安全に表現できない曖昧さが見つかった場合は、英語側で推測せず、日本語の原稿を先に修正します。

この方針により、どちらの言語が事実の基準なのかが明確になります。

2. Azure AI Translator で初稿を作る

対象の記事だけを Azure AI Translator へ送り、英語の初稿を生成します。すべての記事を毎回翻訳するのではなく、ファイル名を指定して処理します。

Markdown の構造を壊さないように、次の要素は翻訳前に保護します。

• コードフェンスとインラインコード
• URL と Markdown リンク
• MDX の import とコンポーネント
• 製品名、識別子、置換してはいけない用語
• 目次から参照する見出しと fragment

3. GPT モデルでポストエディットする

Azure AI Translator の出力を、Azure OpenAI の GPT モデルへ断片単位で渡します。ここでは、日本語の意味を変えずに、簡潔で自然な米国英語の技術文書へ書き直します。

ポストエディットでは、単なる英文校正ではなく、機械翻訳を初稿として文の構造から組み直すよう指示しています。一方で、モデルが事実まで書き換えないよう、数値、製品名、識別子、Markdown のプレースホルダーが変わっていないかをスクリプトで検証します。

検証に失敗した断片だけを再試行し、安全に書き直せない場合は警告を残します。

4. 独立した編集担当が記事全体を整える

断片単位のポストエディットだけでは、記事全体の流れや言葉遣いの統一までは保証できません。そこで、別のコンテキストを持つ編集担当に、日本語の全文と英語の全文を渡します。

この編集担当は、GitHub Copilot から起動する新しいサブエージェントとして実現しています。翻訳処理とは会話履歴を共有せず、日本語の原稿、英語の初稿、想定読者、編集ルールを入力として受け取り、英語の記事だけを編集します。翻訳を生成したときの判断に引きずられず、英語の記事として最初から読み直せるようにするためです。

編集では、次を確認します。

• 直訳調の表現が残っていないか
• 技術用語が一般的な英語表現になっているか
• 見出しから本文まで自然に流れているか
• 同じ言葉が段落ごとに別の表現になっていないか
• 日本語にない事実や断定を加えていないか

5. 別のレビュー担当が JA / EN を比較する

編集を担当したコンテキストは、そのまま最終レビューに使いません。新しいレビュー担当が、日本語と英語を比較します。

レビュー担当にも、GitHub Copilot の新しいサブエージェントを使います。編集担当とは別のコンテキストで、完成した日本語と英語を読み取り専用で比較し、意味の違いや不自然な表現と、具体的な英語の修正案だけを返します。編集結果を自分で正当化しないよう、編集とレビューの役割を技術的にも分離しています。

レビューでは、意味の欠落、追加、変更、不自然な英語、用語、表、見出し、例の整合性を確認します。指摘は具体的な英語の修正案として受け取り、反映後にもう一度独立レビューを行います。

この工程を分けるのは、自分で書き直した文章を自分で確認すると、意図を補って読んでしまいやすいためです。

自然な英文にするための工夫

自然な英語を作るために、翻訳モデルへ一度依頼して終わりにはしていません。

文ではなく意図を英語にする

日本語の各文を同じ順番で英語へ置き換えると、翻訳した文章に見えやすくなります。英語版では、段落が何を伝えるために存在するかを保ちながら、主語、文の順番、見出しを組み直します。

ただし、記事の構造や事実を自由に変えてよいわけではありません。読みやすさのための書き直しと、内容の追加は明確に分けます。

機械翻訳らしさをチェックリストで見つける

この運用を続ける中で、意味は正しくても機械翻訳らしく見える表現には、繰り返し現れる傾向があると分かりました。そこで、bilingual-blog-sync Skill に English Naturalness Checklist を追加し、次の観点を英語編集の手順として明文化しました。

• organize を万能動詞として繰り返さず、実際の動作を表す動詞を選ぶ
• 文頭の So が続く場合は、関係を直接表すか接続表現を変える
• 名詞中心の表現を、可能な範囲で動詞を使った文へ戻す
• 日本語の「〜することができる」から生まれた不要な can を外す
• 長い一文を、意味の切れ目で二文に分ける
• 日本語の語順を保つのではなく、原因と結果を英語で自然な順番に並べる

これらは単語を機械的に置き換えるルールではありません。文脈に合う場合だけ使い、著者の主張や事実は変えないことを前提にしています。

同じチェックリストを、記事全体を書き直す新しい編集担当と、JA / EN を比較する別のレビュー担当の両方へ渡します。編集時に不自然さを減らすだけでなく、編集後に見落としが残っていないかを独立した視点で確認できるようにしました。

固有名詞と事実を機械的に保護する

自然さをモデルに任せても、次の項目はプログラムで検査します。

• 数値と日付
• Azure、GitHub、Microsoft などのブランド名
• Azure AI Translator などの製品名
• 大文字の識別子
• Markdown を復元するためのプレースホルダー

自然な言い換えを許可する範囲と、一文字も変えてはいけない範囲を分けることで、流暢さと正確性の両方を守ります。

自動処理の結果を人が確認できるファイルにする

確認済みの英語は、一時的な生成結果として扱わず、日本語記事と対応するソースファイルとしてバージョン管理します。

これにより、Pull Request の diff で英語本文を確認でき、次回の修正でも既存の英語表現を保ちながら必要な部分だけを更新できます。公開される英語が、ローカルで確認した英語と同じであることも比較できます。

JA と EN の同期漏れを防ぐ仕組み

自然な英語を手で確認する運用にすると、次の課題が生まれます。日本語だけを更新し、英語の修正を忘れる可能性です。

Memolog では、同期済みの日本語と英語それぞれの SHA-256 ハッシュを同期管理ファイルに記録します。

npm run sync:blog-en -- <slug>.mdx

同期記録後にどちらかのファイルが変わると、次の検証が失敗します。

npm run check:blog-en

CI では、次の状態を拒否します。

• 新しい日本語記事に、確認済みの英語 override がない
• 日本語だけ、または英語だけが同期後に変更された
• 英語 override があるのに同期記録へ登録されていない
• 記事の削除や rename で片方だけが残っている

既存記事は、一度にすべてを移行していません。まだ英語 override がない記事は、固定した日本語のハッシュを持つ legacy 記事として扱い、従来の自動翻訳で補完します。その記事を次に更新した時点で、レビュー済みの新しい方式へ移行します。

この段階移行により、既存の英語ページを消さずに品質を上げられます。

SEO で大切にしていること

技術的な多言語 SEO と、英語そのものの品質は別の課題です。

Memolog では、言語ごとに URL を分け、canonical、hreflang、サイトマップ、Open Graph の locale、JSON-LD の inLanguage を設定しています。Google Search Central の ローカライズ版のページについて Google に知らせるにあるように、言語の異なるページの関係を検索エンジンへ伝えるためです。

ただし、この設定だけで英文が読みやすくなるわけではありません。英語ページでは、検索結果や SNS で最初に見える title と excerpt、ページ内で内容を探すための見出し、技術的な判断を支える本文が一つの流れとして自然である必要があります。

現在は、次のように役割を分けています。

SEO のために英単語を増やすのではなく、英語の読者が検索意図に合う内容か判断でき、訪問後も迷わず読めることを目指しています。

この運用にして分かったこと

実際に仕組みを作り直して、翻訳品質は一つのモデルだけでは決まらないと分かりました。

Azure AI Translator は、短時間で記事全体の英語初稿を作る役割に向いています。GPT モデルは、その初稿を自然な文章へ書き直す役割に向いています。ただし、どちらも事実の追加や表記変更を完全には防げないため、機械的な検証と独立レビューが必要です。

また、最も難しいのは英訳そのものより、記事を更新し続ける運用でした。公開時に一度だけ自然な英語を作っても、日本語の更新が反映されなければ、JA / EN で異なる情報を公開してしまいます。ハッシュによる同期検証は、文章の質を直接高めるものではありませんが、確認済みの品質を維持するために欠かせません。

この方式は、自動翻訳だけよりも時間と処理が増えます。そのため、既存記事は必要になった時点で移行し、新規記事と更新記事から品質基準を適用しています。すべてを一度に完璧にするより、公開中のページを維持しながら段階的に改善する方が、このサイトには合っていました。

まとめ

Memolog の英訳は、日本語から英語へ変換するだけの処理から、英語の記事として品質を確認する運用へ変わりました。

現在は、日本語を正本とし、Azure AI Translator で初稿を作り、Azure OpenAI の GPT モデルで自然な技術英語へ書き直します。その後、独立した編集とレビューを行い、JA / EN のハッシュを記録して同期漏れを CI で防ぎます。

多言語 SEO の技術設定は必要ですが、それだけでは読まれる英語記事にはなりません。機械翻訳を便利な出発点として使いながら、自然さ、意味の一致、更新時の同期までを一つの運用として設計することが大切でした。

参考資料

• Google Search Central: 有用で信頼性の高い、ユーザー第一のコンテンツを作成する
• Google Search Central: ローカライズ版のページについて Google に知らせる
• Microsoft Learn: Azure AI Translator documentation
• Microsoft Learn: OpenID Connect を使用した Azure ログイン