翻訳品質とSEO

ここは、その主張が検証されるページです。Docsbookが翻訳について実際に測定する内容、翻訳を修正する方法、検索エンジンやAIアシスタントが翻訳されたドキュメントをどのように扱うか、そして最後に、技術文書において機械翻訳が依然として誤る点を出典とともに説明します。

Docsbookが測定するものと、測定しないもの#

Docsbookは翻訳品質スコアを公開しません。 ページに対するBLEU、COMET、TER、または人手評価の数値は存在せず、このドキュメントがそれを作り出すこともありません。代わりに、この製品が測定するのは網羅性と鮮度です。つまり、ある言語でページが存在するかどうか、そして現在公開されているソースのバージョンから作成されたものかどうかです。

これは「私たちの翻訳は優れている」という主張よりも限定的であり、検証可能な主張です。

カバレッジと鮮度#

保存された各翻訳には、翻訳元となったソースファイルの git blob SHAが保持されます。カバレッジは、HEAD 時点のリポジトリツリーを読み取り、パスごとに比較して算出されます。

カバレッジは (current + manual) / total です。behind と missing がどちらもゼロのとき、その言語は同期済みです。リポジトリを読み取れない場合、カバレッジは null となり、決して確信を持ったゼロにはなりません。そのため、GitHub の読み取りがレート制限されても、正常な言語が誤って不健全と判定されることはありません。

読み方#

• パネルで。 言語ごとに専用のページがあります。そこには、ギャップの種類ごとに分割されたバー上のカバレッジ率、ドキュメントが現在位置しているコミット、実行中のパスを開始した人を示すライブ進捗バー、各実行の終了状況に応じて色分けされた直近12回の実行履歴、そして実行が途中で停止した場合はその理由が言葉で表示されます。その下には、コミットが新しい順に並び、それぞれについて、その言語で各ページがどのような状態にあるかの判定が示されます。これにより、「料金ページの書き換えは火曜日に公開された」ということを、ファイル名から推測するのではなく確認できます。
• MCP経由で。 get_translation_status は言語ごとに、current / behind / missing / manual / orphaned、パーセンテージ、in_sync、実行中の処理があるかどうかとその進捗状況、そして最後の実行で何が行われたか（それを開始したエージェントの実行を含む）を、まさにこの形式で返します。ツール自身の説明では、run_translation_pass の前にこれを読むよう呼び出し元に指示しています。ソースとすでに同じ水準にある言語を再翻訳すると費用がかかるだけで、何も変わらないためです。
• Webhookで。 有効な言語のページが翻訳されようとしているときに translation.needed が、翻訳が永続的に反映されたときに translation.completed が、翻訳がソースに遅れたときに translation.outdated が発火します。translation.completed はページが実際に永続化された場合にのみ発火するため、CMSのインデックスを再作成するリスナーが、存在しない翻訳について通知を受けることはありません。

測定値ではなく比較値である唯一の数値#

Translations ダッシュボードの節約額は、同じ文字数を人間の翻訳者に依頼した場合の料金を1,000文字あたり5.00ドルとして算出し、そこから実際にAI翻訳にかかった費用を差し引いたものです。これには次の2つの点があります。

• 意図的に単語単位ではなく文字単位で算出されています。単語数は対象言語の特性に左右されます。中国語や日本語には空白で区切られた単語がないため、単語単位の指標では、まさに測定すべき言語についてほぼゼロと表示されてしまいます。
• これは請求書ではなく反実仮想です。どちらの金額も実際に支払われたものではありません。この料金はDocsbookで固定された定数であり、受け取った見積もりではありません。この数値は、おおよその規模として捉えてください。

翻訳を修正できますか。また、その修正は保持されますか？#

修正できます。また、その修正は後続のパスによって上書きされないよう保護されます。この部分はデータベースへの書き込み自体で保証されています。ただし、その後読者に修正後のテキストが提供されるかどうかは別の問題であり、正直な回答は以下のとおりです。

修正方法。 Translations パネルで翻訳を編集するか、upload_translation とともに送信します。アップロードされたものはドラフトとして登録されます。list_pending_translations でドラフトを表示し、approve_translation でそのうち1つを公開します。翻訳の内容を編集すると、その行は手動アップロードとしてマークされます。

パス後も保持される理由。 自動パスでは、競合句が origin が docsbook_ai の行のみを上書きするデータベースの upsert を通じて書き込みが行われます。手動アップロードとしてマークされた行はその書き込みでスキップされ、カバレッジでは manual として数えられます。これは決して「遅れている」状態ではありません。人が書いたページの鮮度は、ハッシュ比較ではなく、その人が判断するものだからです。この方法で稼働中の AI 翻訳を置き換えると、呼び出し元には replaced_ai_translation: true も返されるため、エージェントは、読者がすでに見ていたものをたった今置き換えたことを人間に警告できます。

要確認。 Docsbook のドキュメントには、修正をアップロードすると「以後、Docsbook はあなたのバージョンを提供する」と記載されています。 検証可能なこと: 修正された行は保存され、後続の自動パスで上書きされることはなく（upsert の競合句は origin が docsbook_ai の行のみを上書きします）、カバレッジでは古いものではなく manual として数えられます。 検証できないこと: それが読者に提供されることです。現状のコードに照らすと、反対方向を示す点が3つあります。読者向けページはホットキャッシュから翻訳を読み取り、キャッシュミス時には origin = 'docsbook_ai' に絞り込んだ保存済みの行から読み取ります。同じフィルターによって、ロケールがこのページの hreflang クラスターに属するかどうか、およびその URL がサイトマップに含まれるかどうかも決まります。また、キャッシュ無効化の処理には、手動行と外部行は「SSR Redis のページキーに書き込まない」と明記されているため、最初の読み取りで見つけられるキャッシュ済みコピーも存在しません。手動でアップロードまたは編集された行は、そのいずれにも該当しません。修正されたページが実際に提供されたという測定結果は公開しておらず、現在記述されている仕組みもそれを予測していません。したがって、手動アップロードはページの再翻訳を防ぐ方法や外部パイプラインを駆動する方法であって、読者に表示される内容を変更する方法ではないと考えてください。今すぐ特定の文が自分にとって誤っている場合、確実な対処法はソースページを変更し、パスで再翻訳させることです。

これはまさに、私たちの証拠ルールが、黙って削除するのではなく印を付けることを求めている種類の主張です。

翻訳されたドキュメントに対して検索エンジンが行うこと#

言語ごとの個別URLと、ページ単位の hreflang クラスター#

各言語にはそれぞれ固有のURLパスがあり、サブドメインやクエリパラメータは決して使用しません。さらに、すべてのドキュメントページは hreflang セットを <link rel="alternate"> alternate として出力し、原文言語のURLを指す x-default と en も出力します。

これを機能させるルールは相互性であり、サイト単位ではなくページ単位で適用されます。

Docsbook は、URLをルーティングする関数と同じ関数から canonical と alternate を生成します。そのため、提示するアドレスはリダイレクトするものではなく、200を返すものになります。リダイレクト先を指す canonical は、Google によってページを除外する形で処理されます。

同じルールの下には、もう1つの仕組みがあります。Google は明確に、「ページの言語を判断するために、ページの目に見えるコンテンツを使用する」、そして「lang 属性やURLなど、コードレベルの言語情報は使用しない」と述べています。したがって、完全に翻訳されたページであっても英語の <title> をそのまま配信すると、ページ上で最も強いシグナルを誤った言語で送ることになります。Docsbook は、すでに保存している翻訳済みHTMLからタイトルを復元し、そのページ自身の翻訳済み <h1> を読み取ります。追加のモデル呼び出しは必要ありません。その場合、meta description は意図的に原文のままにします。メタデータのビルドでその翻訳を新たに作成することはできず、原文言語の説明文に正しいタイトルを組み合わせる方が、両方が誤っている状態よりも適切だからです。

これらのルールがそれぞれ正しい理由#

最後から2番目の行が有効なタグについて示唆している点に注意してください。es-419は完全に正当なBCP 47タグです。W3Cはこれを実例として使用しています。しかしGoogleはhreflangでは明示的に受け付けていません。有効な言語タグと有効なhreflang値は、同じ集合ではありません。

機械翻訳はGoogleのルールに違反しますか？#

いいえ — しかも、その答えは一般的な議論のどちら側よりも具体的です。正確に理解しておく価値があります。

翻訳されたページは重複ページではありません。 Googleはその境界を1文で示しています。「ページの主要なコンテンツが翻訳されていない場合に限り、ページのローカライズ版は重複ページと見なされます」。完全に翻訳されたページは独立したページです。元の本文を提供するロケールURLは重複ページです。そのため、Docsbookはそのケースを代替ページとして公開するのではなく、元のページを正規ページとして指定します。また、重複全般について、Googleは長年、「サイト上の重複コンテンツは、重複コンテンツの意図が欺瞞的で検索エンジンの検索結果を操作するものと見られる場合を除き、そのサイトに対する措置の根拠にはなりません」と説明しています（重複コンテンツに対するペナルティの誤解を解く、2008年）。

「機械翻訳はスパム」という古いルールはなくなりました。 Googleのスパムポリシーには機械翻訳に関する項目はまったくなく、「machine translation」や「automatically translated」という文字列もページ内に登場しません。そこにあるのは大規模なコンテンツの不正利用であり、「ユーザーにほとんど、あるいはまったく価値を提供しない独自性のないコンテンツを、どのように作成されたかにかかわらず大量に作成すること」と定義されています。翻訳という言葉が残っているのは、同じポリシーにおけるスクレイピングの一例の中だけです。「フィード、検索結果、その他のコンテンツをスクレイピングして、多数のページを生成すること（同義語への置換、翻訳、その他の難読化技術などの自動変換によるものを含む）。その結果、ユーザーにほとんど価値が提供されない場合」。Googleの変更履歴には、2025年6月11日に行われた整理が記録されています。「robots.txtを使用して自動翻訳されたすべてのページをブロックする方法について、多言語ドキュメントからセクションを削除しました」、「2024年3月のスパムポリシー更新に合わせるためです」（Search Centralのドキュメント更新）。

現在の見解は、方法ではなく品質を条件としています。 自動翻訳がランキングに悪影響を与えるかを直接尋ねられたGary Illyesは、「自動翻訳の品質が低ければ、そうかもしれません」と回答し、サイトに対して「その言語を母語とする人が翻訳を確認し（必要であれば修正する）ようにしてください」と助言しました。同じセッションでJohn Muellerは、翻訳が機械によるものだと宣言するためにページへ追加できる「特別なマークアップはありません」、確認すべきなのは「ページが適切に翻訳されているかどうか」であり、「優れたローカライズは、単に単語や文を翻訳するだけのものではありません」と述べました。また、出力品質が低い場合には「そのページにnoindex robotsメタタグを含めるだけでもよいでしょう」とも説明しています（Google SEOオフィスアワー、2024年6月）。

ドキュメントチームにとって実務上の解釈は次のとおりです。

• ペナルティの対象となるのはツールではなく、価値のない大量生成です。読者が実際に必要としているドキュメントを100ページ翻訳することは大規模なコンテンツの不正利用ではありません。一方、誰にも求められていないロケールページを生成することは不正利用に当たります。
• Googleが挙げている変数はレビューです。 Docsbookには、言語ごとのカバレッジページ、list_pending_translations と approve_translation、そして公開前にすべてのページを独自のパイプラインに通して処理するための external モードという機能がありますが、それらの使用を強制することはありません。auto モードでは処理しながら公開します。理解したうえで選択してください。
• 有効なレビューを最も安く行う方法は、すべてのページを確認することではありません。重要なのは、収益に直結するページ、つまりクイックスタート、料金に関係するページ、その言語でアクセス解析上の上位にあるページ、そして誤訳された指示によって読者のセットアップが失敗する可能性のあるページです。ある言語の品質が悪く、修正するつもりもない場合は、noindex が認められた対応策です。

AIアシスタントはそれらをどのように扱うか#

特別なことは何もありません。それが重要な点です。生成エンジンは、クローラーが読み取るものと同じ静的HTMLを取得します。言語を有効にすると、その言語でページが作成され、その言語で質問されたときにアシスタントが取得して引用できるようになります。元の言語だけのコーパスでは、これはできません。さらにDocsbookは、翻訳されたテキストをその言語コードでサイト内の全文検索用にインデックス化するため、ドイツ語で検索する読者には英語の元ページではなくドイツ語のページが一致します。ページ自体に追加される内容については、GEOを参照してください。

限界 — 機械翻訳が技術文書で今なお間違えること#

このセクションは、ページの他の部分と同じように真剣に受け止めてください。

• 用語の一貫性は管理されておらず、これは分野全体で測定された弱点です。 Docsbook には、提供可能な用語集、用語ベース、翻訳禁止リストがありません。一貫性は、より弱い3つの要因から生じます。リクエストは温度0で実行されること、編集されていないセクションはキャッシュからそのまま提供されるため揺らぎようがないこと、そしてナビゲーションラベルとタイトル／説明がセットとして翻訳されることです。同じ用語を使う2つの異なるページは独立して翻訳されるため、食い違う可能性があります。

  それがどの程度重要かは測定されています。Moslem et al.（「Domain Terminology Integration into Machine Translation: Leveraging Large Language Models」、WMT 2023、arXiv:2310.14451）は、DE-EN、EN-CS、ZH-ENのブラインドセット全体で、「ブラインドデータセットの翻訳に組み込まれた用語の数は、汎用モデルでの平均36.67%から、プロセス終了時には平均72.88%に増加した」、つまり「3つの言語ペア全体で用語の有効利用がほぼ倍増した」と報告しています。この指標は正確に読み取る必要があります。これは必要な用語が使用されたかどうかを数えるものであり、72.88%はその目的のために構築された4段階のパイプラインの終了時点の値であって、モデル単体がより強力になった結果ではありません。

  WMT25 terminology shared taskは、同じコインのもう一方の側に数値を示しています。そのTrack 1のデータは、SAPがオンラインヘルプポータルから作成したものです（EN→DE/RU/ES、言語ペアごとにテストインスタンス500件、13チームの20システム）。そして「強力なシステムは97%を超える非常に高い用語正確性を達成する」のですが、これは推論時に正しい用語集をシステムに渡した場合に限られます。まさにその入力をDocsbookは持っていません。このタスクでは、同じシステムをランダムな辞書を使った場合と辞書なしの場合でも実行しています。最高性能のシステムのスコアは、正しい用語集では99.1、ランダムな用語集では49.2、用語集なしでは44.4です。より長いテキストでは、「システムは頻繁に基準に届かない」、また「文書トラックは依然としてより困難なタスクである」と報告されています。これは、用語の忠実性は組み込まれるものであって自然に備わるものではなく、Docsbookにはまだそれが組み込まれていない、という意味に受け取ってください。

  一般的な捉え方も同じです。WMT24の一般翻訳タスク（Kocmi et al.）は、11の言語ペアについて「8つの異なる大規模言語モデル（LLM）と4つのオンライン翻訳プロバイダー」から翻訳を収集したもので、タイトルは「LLM時代は到来したが、機械翻訳はまだ解決されていない」です。その対象分野はニュース、文学、音声、ソーシャルメディアであり、技術文書ではありません。そのため「未解決である」ことの根拠として引用し、ドメインテキストに関することには上記2つを引用してください。テストスイートでは用語の弱点も報告されていますが、範囲は限定的です。その文は1つの方向と1つのシステムについて述べたもので、「英語からロシア語では、Yandexは固有表現と用語に弱い」という内容であり、LLM翻訳全般に関する知見ではありません。

• 文章中の裸の識別子は、指示によってのみ保護されます。フェンスやバッククォート内のコードはリクエストから削除され、バイト単位でそのまま復元されます。これは機械的な処理です。バッククォートのない通常の文章として書かれたパラメーター名はモデルに届き、ソース言語のまま保持されるのは、プロンプトがそう指示しているからにすぎません。識別子をコードとしてマークアップすることが、自分の翻訳に対してできる最も価値の高い対策です。LLM翻訳がコード識別子を具体的にどの程度頻繁に壊すかを測定した公開資料を探しましたが、見つかりませんでした。最も近い公開エビデンスは、上で引用した用語研究です。このリスクの大きさは小さいのではなく、未測定だと考えてください。

• 画像の alt テキストは翻訳されません。これはHTML属性であり、hrefとidを保護する規則によって、altも保護されます。

• Docsbookは独自の測定結果を公開していません。正確性の数値も、エラー率も、言語ごとのランキングもありません。自分のコーパスについてそれが必要なら、信頼できる方法は、自分のページのサンプルを流暢な読者にレビューしてもらうことです。そしてカバレッジによって、どのページをサンプリングする価値があるかが分かります。

• モデルは予告なく変わる可能性があります。デフォルトの翻訳モデルは設定定数であり、選択画面から変更できます。先月翻訳されたページは、その時点で選択されていたモデルによって翻訳されています。モデルが改善したからといって、ページが再翻訳されることはありません。

• 地域別のバリエーションはモデル化されていません。ブラジルとポルトガルで1つのpt、簡体字と繁体字で1つのzhです。この区別が製品の売上を左右する場合、これは丸め誤差ではなく、現実の制限となります。

関連#

• AI翻訳 — パイプラインそのもの：チャンク分割、保護、失敗処理
• 翻訳設定 — 言語の有効化、モデル、モード、ロケールURL
• SEO — すべてのページのカノニカル、サイトマップ、構造化データ
• GEO — アシスタントがページを引用可能にする要素
• Docsbookが主張をどのように証明するか — このページが従うルール