日英2言語サイトの翻訳と更新を自動化する｜対訳管理とhreflangの典型的な誤り7つ（2026年）

日本語と英語の2言語でサイトを運用していると、ある時期から「英語版が追いつかない」状態になります。日本語のページは毎週直しているのに、英語のページは半年前のまま。料金表の数字が片方だけ古い。新しい記事の英語版が出ていない。そうした相談を、日本の事業者からも欧州の事業者からも受けます。

原因を聞いていくと、翻訳そのものが遅いことは少なく、どのページのどこが変わったかを誰も把握していないことがほとんどです。差分の把握、用語の統一、対になるページの管理、hreflang の設定といった「翻訳の周り」の作業が、手作業のまま残っています。

この記事では、日英2言語サイトの翻訳と更新を自動化する設計を、対訳の管理、機械翻訳と人のレビューの分担、hreflang の実装と典型的な誤りの3つに分けて整理します。

この記事が主に根拠にした情報

• Google Search Central「ページのローカライズ版について Google に知らせる」（2026年9月21日更新）、「多地域・多言語サイトの管理」（2025年12月10日更新）、スパムポリシー（2026年8月28日更新）
• W3C Internationalization「言語タグの選び方」「HTML の言語宣言」、WCAG 2.2 の達成基準3.1.1・3.1.2
• Google Cloud Translation の料金表と用語集のドキュメント、DeepL API の利用上限と用語集のドキュメント
• CSA Research「Can't Read, Won't Buy – B2C」（2020年、29か国8,709人）
• ISO 18587（機械翻訳のポストエディット）と OASIS の XLIFF 2.1

1. いま何が起きているか：読者は母語を求め、機械翻訳は安くなった

読者は自分の言語で読みたいと考え、作る側では機械翻訳の費用が大きく下がりました。「全部機械翻訳して出す」誘惑が強まる一方、検索エンジンはその出し方に厳しくなっています。

読者の4割は、他言語のサイトでは買わない

米国の調査会社 CSA Research は、2020年に29か国8,709人の消費者を調べ、76%が母語で情報が書かれた商品を好み、40%は他の言語のサイトでは買わないと報告しました。65%は「質が低くても母語の情報があるほうがよい」と答えており、読者は完璧な訳より、まず自分の言語で読めることを求めていると読めます。

欧州委員会の2011年の調査（Flash Eurobarometer 313）でも、EUのインターネット利用者の約9割が、選べるなら自分の言語のサイトを見ると答えたと報告されています。

機械翻訳の単価は、100万文字で20米ドル

作る側の費用は大きく下がりました。Google Cloud Translation の標準の機械翻訳（NMT）は、毎月50万文字までが無料枠（月10米ドル分のクレジット）、超えた分は100万文字あたり20米ドルです。大規模言語モデルを使う「Translation LLM」は入力・出力それぞれ100万文字あたり10米ドルで、入力と出力が同量なら標準の機械翻訳と同水準になります（2026年10月25日確認）。

DeepL API も無料版で毎月50万文字まで訳せ、有料版は従量課金です。

検索エンジンは「翻訳しただけ」に厳しくなった

Google のスパムポリシー（2026年8月28日更新）は、「大規模なコンテンツの不正使用」の例に、翻訳などの自動変換で価値を足さずに量産することを挙げています。

自社の記事を英訳すること自体は転載とは違いますが、誰も読まずに機械翻訳を並べる運用はこの例に近づきます。安くなったのは下書きであって、公開してよい訳文ではありません。

また Google は Search Console の「国際ターゲティング」レポートを廃止しました（hreflang 自体は引き続きサポート）。この章の動きを表にまとめます。

どの動きも、「訳す」より「確かめる」側の仕組みが要ることを示しています。

2. 2言語の運用で、時間はどこに消えているか

作業の棚卸しの方法は「サイト運用のAI・自動化は棚卸しから」で扱ったので、ここでは翻訳に関わる作業だけを取り出します。時間と事故が集中するのは、翻訳の前後で人が記憶に頼っている作業です。

翻訳の前後にある5つの作業

表のうち、翻訳そのものに当たるのは2行目だけです。残りの4行は、ルールとデータの持ち方を決めれば、ほぼ機械に任せられる作業です。

「英語版が古い」は、気づけないことが問題

いちばん多い事故は、誤訳よりも片方の言語だけが古い状態です。料金を直したのに英語ページは旧価格のまま、という形で起こります。翻訳の速さではなく、「古くなったことを知る仕組み」がない問題です。

3. 全体像：対訳パイプラインの5つの工程

翻訳と更新は、1本の流れ（パイプライン）として設計すると見通しがよくなります。日本語を原文とする場合の流れを5つの工程に分けました。ポイントは、人が入る工程を1か所に集めることです。

各工程で使う道具と、あとで「誰がいつ確認したか」を説明するために残す記録です。

工程3を飛ばすと「機械翻訳を並べたサイト」になり、工程1と4がないと人は毎回ページ全体を読み直すことになります。

4. 対訳の管理①：translation_key で「対」をデータにする

translation_key は、URLとは別に持つ

対を表す素直な方法は、両方のページに同じ値のキー（translation_key）を書くことです。DevNJ のこのコラムも、日英の front matter に同じキーを書き、その値で hreflang を自動で出しています。URLで対を判定するとURLの変更で対が切れるので、キーは一度決めたら変えません。

---
title: "日英2言語サイトの翻訳と更新を自動化する"
translation_key: bilingual-site-translation-automation
source_locale: ja                 # 原文の言語
source_hash: 3f9c2a…              # 訳した時点の原文の指紋
translation_status: reviewed      # machine / reviewed / outdated
reviewed_at: 2026-10-25
---

原文の指紋で「古くなった訳」を検出する

訳文の側に訳した時点の原文のハッシュ（指紋）を残すと、現在の原文のハッシュと比べるだけで、訳が古くなったかを判定できます。

ページ全体のハッシュだけでは「どこが変わったか」が分からないので、段落（セグメント）ごとにもハッシュを取り、翻訳メモリに持たせます。変わった段落だけを機械翻訳とレビューに回せば、確定済みの訳文には手を触れずに済みます。

状態の組み合わせで、公開してよいかを決める

翻訳の状態は machine（機械訳のまま）、reviewed（人が確認済み）、outdated（原文が変わった）の3つで足ります。これを公開の条件と結びつけます。

誤字や言い回しの修正なら英語版が数日遅れても害は小さく、価格・日付・連絡先・法定表示の変更なら英語版がそろうまで両方の公開を待つ、と決めておくのが実際的です。

5. 対訳の管理②：翻訳メモリと用語集

翻訳メモリ：確定した訳を文単位で再利用する

翻訳メモリ（Translation Memory）は、人が確定した原文と訳文の組を、文や段落の単位で貯めたものです。同じ文が再び出てきたら確定済みの訳をそのまま使い、似た文なら候補として示します。

フッター、問い合わせの案内、料金表の注記など、サイトには同じ文が何度も出てきます。翻訳メモリがあれば毎回訳して確認する必要がなくなり、訳が勝手に変わる事故も防げます。

やり取りの形式には、OASIS が2018年に標準とした XLIFF 2.1 や TMX があります。小規模なら Git で管理する CSV から始めても構いません。特定の道具の中だけに閉じ込めないことが大事です。

用語集：訳語を固定してエンジンに渡す

用語集（Glossary）は、語句ごとに訳し方を固定する辞書です。DeepL と Google Cloud Translation は、どちらも API で用語集を渡すと、その訳語を優先して使います。

2026年10月25日に各社のドキュメントで確認しました。どちらも版管理がないので、用語集はリポジトリで管理し、変更のたびにAPIへ反映するのが安全です。

用語集に入れるもの、入れないもの

用語集を大きくしすぎると、文脈によって訳し分けるべき語まで固定されます。入れるのは、訳がぶれると困る語に絞ります。

「訳さない語」は、原文と訳文に同じ語を書けばそのまま残ります。用語集で拾えない文体（主語に we を使うか、日付と通貨の書き方など）は、1ページの文体ガイドにまとめてレビューする人の手元に置きます。LLM を使う翻訳なら、指示として渡すこともできます。

6. 機械翻訳エンジンの選び方と費用

日英では DeepL と Google Cloud Translation が主な選択肢です。基準は訳の印象だけでなく、用語集、データの扱い、課金の数え方です。訳の質は文書の種類で入れ替わるので、自社のページ20〜30段落で比べるのが確実です。

主な選択肢と料金

eTranslation は欧州委員会の機械翻訳で、EUに拠点を置く公的機関や中小企業（自営業者を含む）などが無料で使えます。公式ページでは日本語への対応は確認できず、欧州の言語どうしで検討する選択肢です。

標準の機械翻訳と翻訳LLMはほぼ同じ水準で、適応型翻訳とカスタムモデルは2.5〜4倍です。中小規模のサイトでは、まず標準の機械翻訳か DeepL に用語集を組み合わせ、不満が残る文書の種類だけ上位の方式を試す順番が無理がありません。

課金は「原文の文字数」で数える

課金は原文の文字数で数えるのが基本で、DeepL は原文の Unicode のコードポイント数で数えると説明しています。

日本語と英語では、同じ内容の文字数が大きく違います。DevNJ の手元の記事では、日本語1文字に対して英語はおおむね2〜3文字でした。日本語を原文にして英訳するほうが、課金される文字数は少なくなります。無料枠の計算では差が出ます。

データの扱いを確認する

公開前の原稿には、未発表の価格や顧客名が入ることがあります。DeepL は有料の Pro 契約について、原文と訳文は処理に必要な間だけ保存し、学習には使わないと説明しています。無料版は扱いが異なる場合があるので、規約を確認してください。個人データを含みうる文章（問い合わせへの返信など）は、GDPR（EU一般データ保護規則）上の委託契約まで確認してから機械翻訳に回します。

7. 機械翻訳と人のレビューの分担

機械翻訳の後に人が手を入れる作業をポストエディットと呼びます。国際規格 ISO 18587（2017年）は、人が全面的に直す「フル・ポストエディット」の要件を定め、最小限の「ライト」は付属書の扱いです。公開ページは会社の言葉として読まれるので、フルの水準で確認します。

文書の種類で分担を変える

誤訳したときの影響の大きさで、分担を変えます。

なお Google は、本文を訳さずメニューなどの定型部分だけを訳すと使いにくい検索結果になると説明しています。投稿を訳さないページは、原文の言語のページとして扱います。

レビューで見る項目を決めておく

見る項目を決め、確認画面に並べておきます。

機械で補助できる項目は、レビューの前に検査して印を付けておきます。人は意味と文体に集中できます。

レビューする人は、訳文の言語で自然さを判断できる人です。社内にいなければ、校閲者に「変わった段落単位」で依頼すると依頼量を小さく保てます。承認の記録の残し方は「記事更新の自動化は「品質ゲート」で決まる」も参考にしてください。

8. hreflang の実装：3つの方法と選び方

hreflang は、同じ内容の別言語版があることを検索エンジンに伝える仕組みです。対が管理できていれば、テンプレートかビルドの工程で対のデータから生成するだけになります。手で書くと必ず漏れます。

3つの方法は同等。1つに絞る

Google は、HTML の link 要素、HTTP ヘッダー、XML サイトマップの3つの方法を同等に扱います。3つを併用しても検索上の利点はなく、管理が難しくなるだけだと明記しています。

日英の2言語なら、各ページの head に次のように出します。自分自身も含めて全ての版を列挙し、URLは https から始まる完全な形で書きます。

<link rel="alternate" hreflang="ja" href="https://example.com/column/translation-automation" />
<link rel="alternate" hreflang="en" href="https://example.com/en/column/translation-automation" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/column/translation-automation" />

x-default は「どの言語にも当てはまらない人」の行き先

x-default は、どの言語にも当てはまらない読者に見せるページです。日英のサイトなら、英語版を指定するのが一般的です。

言語コードは短く書く

言語コードは ISO 639-1（ja、en）、地域を付けるなら ISO 3166-1 Alpha 2（JP、GB）です。W3C は言語タグをできるだけ短くするよう勧めており、日本語は ja で足ります。en-GB と en-US は、綴りや価格が実際に違うページを用意している場合だけ使います。

lang 属性は別の役割を持つ

hreflang と混同されやすいのが、html 要素の lang 属性です。Google は、ページの言語の判定に hreflang も lang 属性も使わず、ページに見えている本文から判定すると説明しています。

それでも lang 属性は必要です。web.dev は、lang の宣言がスクリーンリーダーや翻訳サービスの言語の識別を助けると説明し、W3C も html 要素に必ず書くよう勧めています。WCAG 2.2 では、ページの言語（3.1.1、レベルA）と一部分の言語（3.1.2、レベルAA）が達成基準です。

自動リダイレクトはしない

Google は、推測した言語での自動リダイレクトを避け、切り替えリンクで読者に選ばせるよう勧めています。Googlebot は通常 Accept-Language ヘッダーを送らずにクロールするため、一部の版が見えなくなるおそれがあるからです。

9. hreflang の典型的な誤り7つ

hreflang の誤りは表に出にくく、検索結果で別の言語版が出て初めて気づきます。Search Console のレポートもないので、自分で検査する仕組みが要ります。Google が挙げる誤りと、実際によく見る誤りを7つに整理しました。

1〜4は Google のドキュメントに明記された要件と誤りです。5については、Google の正規化のドキュメントが、hreflang を使うサイトでは同じ言語の canonical ページを指定するよう求めています。英語版の canonical を日本語版に向けると、英語版は日本語版の重複として扱われるおそれがあります。

6は要件として明記されているわけではありませんが、運用で最も頻繁に起きる誤りです。英語版を非公開に戻したのに日本語版の hreflang が残っている、URLを変えたのに古いURLのまま、といった形です。第4章の状態管理と組み合わせ、公開中で、reviewed の訳文がある対だけ hreflang を出すようにすると、構造的に防げます。

誤りを見つける検査

これらは全て機械で検査できます。ビルドの最後に、公開予定の全ページについて次を確かめ、1つでも落ちたら公開を止めます。

「言語の一致」は、テンプレートを複製して英語版を作り、lang が ja のまま残る取りこぼしを拾います。同じ考え方で、英語版の title・alt・本文に日本語の文字が一定の割合以上残っていないか、英語版の内部リンクが日本語版を指していないかも検査に足せます。

10. 費用と工数の幅

数字は DevNJ が置いた仮の目安で、実測の統計ではありません。モデルサイトは日英それぞれ40ページ、記事が月4本（1本6,000字前後）、既存ページの修正が月10か所前後で、原文の更新量は月3万字強です。

月々の工数

自動化前のレビューは流し読みになりがちなので3時間と置きました。自動化後は全文を確認するため増えます。浮いた時間の一部を確認に回すので、訳の質はむしろ上がります。

機械翻訳の費用

月3万字強なら、Google の標準NMTでも DeepL API の無料版でも、無料枠（月50万文字）に収まります。全40ページ・約20万字を一度に訳し直しても枠の内側です。枠を超えるのは数百ページ以上や3言語以上の場合ですが、それでも人の時間に比べれば小さな額です。

導入の段階と費用の幅

段階1だけでも「英語版が古いことに気づけない」問題は解消し、外部への翻訳依頼も変わった段落だけで済みます。翻訳管理システム（TMS）を契約する場合は、別途その費用がかかります。

11. よくある失敗

実際によく見る失敗です。多くは技術ではなく、運用の決め方で起きています。

損が大きいのは最後の行です。読者には誤りだと分からないため、そのまま契約に進んでしまいます。

12. 日本と欧州で比べる

日本向けと欧州向けでは、前提が少し違います。優劣ではなく条件の違いとして整理します。日本では、観光庁が2014年に策定した多言語対応のガイドラインが、「清水寺」を「Kiyomizu-dera Temple」と書くような固有名詞の表記ルールと対訳語の例を示しており、用語集を作るときの考え方として使えます。

欧州向けに日英で始めたサイトは、3言語目（オランダ語やドイツ語）を足すときに、この設計がそのまま効きます。translation_key と用語集があれば、言語を1つ足すのは対を1つ増やす作業になります。

13. ケースで考える（架空の3社）

架空の3社で、答えが立場によってどう変わるかを見ます。実在の企業ではありません。

A社は仕様値が英語版で古くなる事故を2回起こしたため、仕様表を翻訳メモリと数字の突き合わせで管理しています。B社はページが少ないので、価格が変わると英語版が outdated になって通知が届く仕組みだけを入れ、英訳は店主が行います。C社は季節の案内文の文体を重視し、用語集と文体ガイドを翻訳LLMに渡して下書きを作り、予約条件は人が訳した確定版を使っています。

14. 導入の手順：6週間で進める

6週間で進める手順です。週ごとに終わりの状態があるので、途中で止まっても成果が残ります。

1. 1週目：対の棚卸し — 全ページを一覧にし、日本語版と英語版の対応表を作る。片方しかないページ、URLだけで対応しているページを洗い出す
2. 2週目：translation_key と原文の指紋 — 全ページにキーを付け、訳文の側に source_hash と translation_status を書く。古くなった訳の一覧が自動で出る状態にする
3. 3週目：hreflang の自動出力と検査 — 対のデータから hreflang を出し、第9章の検査をビルドに入れる。自動リダイレクトがあれば外す
4. 4週目：用語集と文体ガイド — よく使う語を50〜100語、文体の決まりを1ページにまとめ、リポジトリに置く
5. 5週目：機械翻訳とレビュー画面 — API を組み込み、変わった段落だけを訳して、対訳を並べた確認画面に出す
6. 6週目：数字の突き合わせと振り返り — 英語版に残った日本語や内部リンクの検査を足し、1か月分の更新で工数と見落としを記録する

15. やってはいけないこと

短期的には楽に見えて、あとで信頼か検索を失う選択です。

16. チェックリスト

導入時と月1回の見直しで使います。

対訳の管理

• 全ページに translation_key があり、日英の対が一覧で分かる
• 訳文の側に、訳した時点の原文の指紋（source_hash）がある
• 古くなった訳（outdated）の一覧が自動で出る
• 機械訳のまま（machine）のページは公開されない
• 用語集と文体ガイドがリポジトリにあり、変更履歴が残る

翻訳とレビュー

• 価格・契約・法定表示は、人が訳すか一語ずつ照合している
• レビューする人が、訳文の言語で自然さを判断できる
• 数字・用語・段落数は、レビューの前に機械で突き合わせている

hreflang と公開

• hreflang は3つの方法のうち1つだけで出している
• 全ページが自分自身を含む全ての版を列挙している
• 言語コードは ja・en、地域を付けるなら GB や JP を使っている
• URLは https から始まる完全な形で、すべて200を返す
• canonical は自分自身か同じ言語のページを指している
• html の lang 属性がページの言語と一致している
• ブラウザの言語で自動リダイレクトしていない

17. まとめ

• 2言語サイトの事故は、誤訳より「片方だけ古い」が多い。まず translation_key と原文の指紋で、対と古さをデータにする
• 変わった段落だけを訳すために、段落ごとのハッシュと翻訳メモリを持つ。確定済みの訳は再利用し、勝手に変えない
• 用語集は50〜100語から始め、リポジトリで管理して API に反映する。文体は1ページのガイドにまとめる
• 機械翻訳の費用は小さい（標準NMTは100万文字20米ドル、月50万文字まで無料）。主な費用は人のレビューで、価格・契約・法定表示は人が持つ
• hreflang は1つの方法に絞って自動生成し、相互参照・自己参照・完全なURL・同じ言語の canonical を公開前に検査する
• 自動リダイレクトと2言語の併記は避け、切り替えリンクで読者に選ばせる
• モデルサイトでは月22時間がおおむね11時間前後になる見込みで、浮いた時間の一部はレビューを厚くするのに使う

運用全体の自動化の範囲を決める方法は「サイト運用のAI・自動化は棚卸しから」、更新やバックアップなど保守の自動化は「ホームページ保守の自動化」で扱っています。

参考にした情報源

検索と多言語の指針（Google）

• Tell Google about localized versions of your page — Google Search Central：hreflang の3つの方法と要件、よくある誤り（2026年9月21日更新）
• Managing multi-regional and multilingual sites — Google Search Central：自動リダイレクトを避ける、1ページ1言語（2025年12月10日更新）
• Spam policies for Google web search — Google Search Central：翻訳などの自動変換による量産（2026年8月28日更新）
• How to specify a canonical URL — Google Search Central：hreflang を使うサイトでは同じ言語の canonical を指定（2026年7月10日更新）
• The International Targeting report is deprecated — Search Console ヘルプ：国際ターゲティングのレポートの廃止

言語の宣言とアクセシビリティ（W3C・web.dev）

• Choosing a Language Tag — W3C Internationalization：言語タグはできるだけ短く
• Declaring language in HTML — W3C Internationalization：html 要素に lang を書く理由
• Understanding Success Criterion 3.1.1: Language of Page — W3C WAI：ページの言語（レベルA）
• Understanding Success Criterion 3.1.2: Language of Parts — W3C WAI：一部分の言語（レベルAA）
• Document structure — web.dev Learn HTML：lang の宣言がスクリーンリーダー・検索エンジン・翻訳サービスを助ける
• Tags for Identifying Languages（RFC 5646） — IETF：言語タグの規格（BCP 47）

機械翻訳の料金と機能

• Cloud Translation pricing — Google Cloud：各方式の単価と月50万文字の無料枠
• Create and use glossaries — Google Cloud Translation：用語集の形式と上限
• DeepL API Free — DeepL ヘルプセンター：無料版の月50万文字
• Usage limits — DeepL API documentation：使用量の数え方（原文のコードポイント）
• Glossaries — DeepL API documentation：用語集の形式と上限
• AI translation and language tools — 欧州委員会：eTranslation の対象者と料金

翻訳の規格

• ISO 18587:2017 Post-editing of machine translation output — ISO：フル・ポストエディットの要件とポストエディターの能力
• XLIFF Version 2.1 — OASIS：翻訳データの交換形式（2018年2月13日に OASIS 標準）

調査と日本の指針

• Survey of 8,709 Consumers in 29 Countries Finds that 76% Prefer Purchasing Products with Information in their Own Language — CSA Research：母語志向の76%と40%（2020年7月）
• Flash Eurobarometer 313: User Language Preferences Online — GESIS データアーカイブ：欧州委員会の2011年調査の記録
• 観光立国実現に向けた多言語対応の改善・強化のためのガイドライン — 観光庁：固有名詞の表記ルール（2014年3月）

いずれも2026年10月25日に確認したものです。料金と仕様は変わるため、導入の前に各社の公式ページで最新の内容を確認してください。工数と費用の目安は DevNJ が置いた仮の目安で、実測の統計ではなく、サイトの規模と体制で変わります。