ウェブサイトのヘブライ語翻訳：RTL・性別表現・現代の正書法

ヘブライ語のウェブサイトローカライズ：RTLマークアップ、母音記号を用いない表記、性別に応じたUI、ヘブライ語（he）のSEO。

Grant Davies更新日

ウェブサイトをヘブライ語に翻訳する：白いグリッド上に、ニクダーの点を付けたヘブライ文字を右から左に並べたブロックカードと、/heのチップ

「ウェブサイトをヘブライ語に翻訳する」という依頼を受けたら、ヘブライ語を「文字が違うだけのアラビア語」として扱うのはやめましょう。ウェブ上のヘブライ語では、RTL対応と異なる文字体系の混在が課題になります。ページ全体は右から左へ流れる必要がありますが、英語の製品名や数字は、左から右に読める独立した領域として保つ必要があります。また、現代のUIテキストでは、ほぼ常に母音記号を使いません。

この記事は、ウェブサイトのヘブライ語（he）版を公開するためのガイドです。ロケールの選択、文字方向と左右反転、クロール可能なURL、購入手続きのQA（請求書やメールを含む）、MTPEと人によるレビューの使い分け、SEOの落とし穴、そして実際に使えるチェックリストを紹介します。

ウェブサイトのヘブライ語翻訳には、文字列の差し替え以外に何が必要？

CMSのフィールドを翻訳するだけでは不十分です。マークアップで文書の文字方向を設定し、テンプレート、メール、PDFを通じてヘブライ文字・ラテン文字・数字が混在する際の並び順を維持する処理フローが必要です。さらに、ステータス表示の動詞や形容詞における文法上の性の扱い、本文も実際にヘブライ語になっている専用URL、正書法の方針（原則として母音記号なし）を、誰かがファイルを開く前に決めておく必要があります。

このガイドでわかること

  • ウェブサイトのヘブライ語翻訳には、文字列の差し替え以外に何が必要？
  • ヘブライ語のロケールや地域別バリエーションは、どれを選ぶべき？
  • ヘブライ語特有の文字、タイポグラフィ、レイアウトの課題とは？
  • ヘブライ語版サイトのURL、hreflang、インデックス登録はどう設計する？
  • ヘブライ語の初回利用案内や購入手続きで注意すべき点は？
  • ヘブライ語にはAI翻訳、MTPE、人によるレビューのどれを使うべき？
  • ヘブライ語ページで特に悪影響を及ぼすSEOのミスとは？
  • ウェブサイトのヘブライ語版をどう公開し、成果を測定する？

要点：ウェブサイトを適切にヘブライ語へ翻訳するには

公開後も安定して運用できるヘブライ語版にするには、次の対応が必要です。

  1. HTMLで基本の文字方向を設定します（文書にdir="rtl"を指定し、ラテン文字の製品名や数字の連続部分にはdir="ltr"も指定）。CSSだけで左右を反転しても、マークアップの代わりにはなりません。
  2. he（多くの場合はhe-IL）は、Cookieだけで切り替えるのではなく、クロール可能な独立したURLで公開します。
  3. ナビゲーション、カード、購入手続き、メール、請求書を実際のヘブライ語テキストで試作し、文字の切れ、コントロールの左右反転、双方向テキストの並び替えによる問題を公開前に洗い出します。
  4. UIの標準は母音記号なしのヘブライ語にします。教育上の目的やブランドのスタイルで明示的に必要とされない限り、「学習者のために」とニクダーを散りばめないでください。
  5. 規模を拡大する前に、相互参照するhreflang、同じ言語のURLを指定するcanonical、サイトマップを設定しましょう。
  6. 製品に関する名詞、文法上の性の扱い、「英語のまま残す」用語を用語集にまとめ、MTPEで文体や性がいつの間にか変わらないようにします。

CSA Researchが29か国の消費者8,709人を対象に実施した調査では、76%が母語の情報で購入することを好み、40%は他言語のウェブサイトでは決して購入しないと回答しました。英語も読めるイスラエルのユーザーが多くても、この傾向は変わりません。購入手続き、請求書、サポートこそ、英語だけの顧客体験では売上を逃しやすい場面です。Googleの有用なコンテンツに関するガイダンスは、ユーザー第一のページを重視しています。ナビゲーションだけをヘブライ語にして本文を英語のまま残したサイトは、ローカライズとして不十分です。市場と言語それぞれの戦略については、国際SEOと多言語SEOの違いをご覧ください。

適切なヘブライ語ロケールを選ぶ

最初の販売対象市場がイスラエルなら、多くのチームはイスラエル向けのhe-IL URLでheを公開するとよいでしょう。初回リリースとしては妥当な選択です。ただし、母音記号付きの典礼用ヘブライ語、スラング交じりのチャット表現、英語を多用するスタートアップ風の文章を1つのファイルに混在させ、それを「ヘブライ語ロケール」と呼んでよいわけではありません。

現代イスラエルのヘブライ語には、共通の書き言葉の標準があり、日常的な製品の語り口と正式な法律文書のヘブライ語などで文体が異なります。初日からheのメッセージファイルを1つにまとめる設計は可能です。ただし、軍隊のように堅い用語が一般消費者向けの購入手続きにもそのまま適しているとか、スラングの多いマーケティング用ホームページの表現が銀行のエラー表示にもふさわしいと考えてはいけません。

ニクダー（母音記号）は、現代のUIではほとんど使われません。ウェブサイト、アプリ、メールでは、母音記号なしのヘブライ語が標準です。「分かりやすくするため」に記号を加えると、古めかしい、見づらい、あるいは児童書のような印象になりがちです。制作要件には、明示された例外がない限り母音記号を使わないと定めておきましょう。例外としては、語学学習製品などが挙げられます。

氏名、住所、電話番号の扱いも決めておきましょう。ヘブライ文字を受け付けない、氏名をASCII文字に限定する、欧米式の「名・姓」の順序を前提とするといったフォームは、文字列が「翻訳済み」になっても使い物になりません。イスラエルの電話番号や郵便番号の形式も、ロケールの要件に含めてください。

文法上の性もロケール戦略の一部です。ヘブライ語の動詞や形容詞は、性によって形が変わることがよくあります。テンプレートに男性形の既定値を固定してしまう前に、ネイティブの言語専門家と相談し、包摂的な表現、男女両形の併記、性別を限定しにくい構文の活用などの方針を決めてください。

ヘブライ文字、タイポグラフィ、レイアウトの注意点

ヘブライ語は、右から左へ読む独自の文字を使います。W3Cは、CSSだけの工夫ではなく、HTMLマークアップで基本の文字方向を設定するよう推奨しています（文書全体と、逆方向の表示が必要な独立領域にdirを指定）。埋め込まれた英語の製品名、SKU、多くの数値文字列は、RTLページ内でも左から右（LTR）のまま表示します。こうした独立領域を設けないと、「GlotEO 2.0」や請求書の合計金額の並び順が変わり、データが壊れたように見えてしまいます。

公開直後に不具合のスクリーンショットが出回らないためのレイアウトルール：

  • 長い複合語、母音記号のない見出し、ラテン文字のブランド名が混在する文章など、実際のヘブライ語テキストで主要画面を試作してください。
  • ウィザード、メディアカルーセル、戻る操作の表示、タイムライン、チェックリスト、進行方向を示す山形矢印など、操作パターンは意図的に左右反転させましょう。RTLページで「戻る」矢印が左を向いているのは、デザインの好みではなく製品の不具合です。
  • ボタン内のテキストは折り返せるようにしましょう。英語のCTAと同じ1行に収めるために文字を小さくしてはいけません。
  • UI、メール、PDFには、ヘブライ文字をカバーする本番用フォントを組み込んでください。ラテン文字中心のフォント構成では、代替フォントへの切り替えによってUIが未完成に見えてしまいます。
  • カードのタイトル、バッジ、表の見出しに注意してください。文字の切れや、左右の配置ミスが最初に表れやすい箇所です。
  • 方向性を持つアイコン（再生、共有、パンくずリストなど）は、「全言語共通のUI装飾」ではなく、各言語版の一部として扱ってください。

日付や数値も、レイアウトの要件に含まれます。イスラエルでは通常、本文中の日付は日・月・年の順で表示し、現地で販売する場合はILSに適した通貨表記を使い、電話番号欄では現地の形式を受け付けることが求められます。ヘブライ語のリストを英語のASCII順で並べても、適切な照合・ソートの方針とはいえません。

性によって変化するステータステキストは、表示幅も変わります。「招待されています」のような文字列は、性に応じて長くなることがあります。長い方の表現も収まるテンプレートを設計してください。英語の原文が1つならヘブライ語の表示幅も1つで済む、とは考えないでください。

クロール可能なURL、hreflang、インデックス登録

Googleは、Cookieやブラウザの言語設定だけに頼るのではなく、言語版・地域版ごとに異なるクロール可能なURLを用意することを推奨しています。Googleは主に画面に表示されるコンテンツからページの言語を判断するため、ナビゲーションだけを翻訳して本文を英語のままにしたページは、ヘブライ語版として不十分です。ヘブライ語専用のフォルダまたはホストのパターン（/he/、/he-il/）を設け、テンプレート、アクセス解析、内部リンクのすべてで統一してください。ヘブライ語の検索に対して、そのURLをヘブライ語版として機能させたいなら、クロール可能なURLと、大部分がヘブライ語で書かれたメインコンテンツが必要です。

hreflangアノテーションは、指定した代替ページ群の間で相互に設定する必要があります。各ロケールのURLには明確なcanonicalを設定し、重複ページがある場合は同じ言語の優先URLを指定してください。ヘブライ語ページのcanonicalを、対応する英語ページに向けてはいけません。

Bingのウェブマスターガイドラインは、クロール可能で有用なコンテンツと、明確なサイト構造を重視しています。Googleは、推測した言語や所在地に基づいてユーザーを自動転送しないよう助言しています。代わりに、ヘブライ語版のURLにリンクする分かりやすい切り替えメニューを用意してください。IPから推測して「イスラエル → /he」と振り分けると、旅行者、VPN利用者、クローラーが意図しないページに誘導されてしまいます。

URLの方針とページ内の表記方針は、別に考えて構いません。運用上の理由でスラッグをパーセントエンコードしたり、ASCII文字に置き換えたりすることはできますが、タイトル、H1、本文はヘブライ文字のままにするべきです。運用のためにスラッグをASCII化したうえで、/he/に英語の本文を載せても、言語版とはいえません。スラッグをASCII化する場合は、リダイレクトを一貫して設定してください。canonicalを指定せず、競合する2つのヘブライ語URLを公開してはいけません。

対象言語でのオンボーディング、信頼構築、購入手続き

ヘブライ語で信頼を築くためのページは、翻訳した機能一覧以上に重要です。イスラエル向けに販売するサイトでは通常、プライバシー、利用規約、必要に応じて決済やアフターサービスの案内を、英語テンプレートの残り物ではなく、独立したページとして自然に読める形で用意する必要があります。これは検索順位を上げるための施策ではありません。購入手続きが信頼できるかを判断するときに、ユーザーが確認する情報です。これらのページも、重要なローカライズ対象として扱ってください。

厄介な不具合は、サイトの外で起こることがよくあります。文字方向が混在する領収書、PDFの請求書、パスワード再設定メール、SMSコードでは、ヘブライ文字、数字、ラテン文字の製品名の順序が入れ替わることがあります。マーケティング用のホームページだけでなく、こうした生成物もユーザー受け入れテストに含めてください。ストアの表示が正しくても、請求書の₪001.99が誤った順序で表示されれば、購入手続きへの信頼は損なわれます。

ヘブライ語版のコンバージョンを確認する実践チェック項目：

  • ホームページ、広告、製品UIで文体が統一されている（日常的な表現か、正式な法律文書調か）。
  • フォームの氏名・住所欄でヘブライ文字を受け付けるか、ラテン文字での入力が必要な理由を説明している。
  • Cookieや同意に関する文言を、実際のバナー上で確認している。こうした文言は長くなりやすく、RTLでは不自然に折り返されがちです。
  • 価格表示、請求書、通貨に関する表記が、対象として掲げる市場に合っている。
  • サポートの定型文やトランザクションメールでも、RTLマークアップと母音記号なしの表記を維持している。「安全のためASCIIのみ」にしたメールテンプレートは、ローカライズの抜け穴になります。
  • エラーメッセージは、丁寧なだけの中身のない謝罪ではなく、解決方法を示しており、文法上の性に関する方針にも従っている。
  • ラテン文字のSKUが混在する表示と、ヘブライ語での直接入力の両方を、モバイル端末でQA確認している。

公開初日からすべてのブログ記事をそろえる必要はありません。ただし、ホームページ、製品説明、認証、料金、購入手続き、プライバシーに関する基本情報、サポート窓口、そしてその市場で求められる法的情報のページは必要です。イスラエルのユーザーの中には英語のドキュメントを読む人もいますが、英語では購入手続きやサポートのやり取りを完了しない人も少なくありません。そのため、英語のみの対応では売上の機会を逃してしまいます。

フランス語のAI翻訳、MTPE、人によるレビュー

ヘブライ語には、AI翻訳、MTPE、人によるレビューのどれを使うべきでしょうか。ワークフローはツールのブランドではなく、リスクに応じて選びましょう。

  • 未編集の機械翻訳：社内向けの下書きに限って使いましょう。モデルはニクダーを挿入したり、文法上の性を取り違えたり、ヘブライ語の単語に英語の構文をそのまま当てはめたりします。また、数字と名前が混在する文字列では、双方向テキストの表示順序を崩すこともあります。
  • MTPE（機械翻訳＋ポストエディット）：用語集で製品関連の名詞と英語のまま残す用語を固定し、さらに文法上の性と正書法のチェックを行うなら、多くの製品ページやサポートページで有力な標準手法になります。
  • 人による翻訳／ブランド観点での編集：ホームページ、料金、キャンペーン、Cookie・同意に関するページ、法的事項に関わるあらゆるページに適しています。

ヘブライ語の実用的なレビュー手順は次のとおりです。まず、用語集に照らしてMTPEを実施します（原則として母音記号を付けず、文法上の性の扱いを統一し、英語の製品名は変更しません）。次に、ブランド担当の編集者がホームページと料金ページを確認し、言語の専門家がエラーメッセージ、請求関連の文言、文法上の性を伴うステータス表示を確認します。その後、ステージング環境でモバイル画面幅でのQAを行い、左右両方向のテキストが混在するメールやPDFも確認します。公開時には、heのURLで本文の大半が英語になっていないか、UIの文字列に意図しないニクダーが含まれていないかもチェックしましょう。

ユーザーを第一に考えた有用なコンテンツという要件は、どの言語にも当てはまります。機械翻訳だけで作ったヘブライ語のページは、CMS上では完成しているように見えても、ユーザーの役に立たないことがあります。

ヘブライ語特有のSEOの落とし穴

ヘブライ語で検索する人が求めているのは、自分が読める言語です。ヘブライ文字でヘブライ語のキーワード調査を行い、ヘブライ語の検索結果になじむタイトルとH1を作成しましょう。ヘブライ語のURLごとにタイトル、メタディスクリプション、見出しをローカライズし、英語のメタデータ一式をそのまま使い回さないでください。

ヘブライ語のページで特に悪影響を及ぼすミスには、次のようなものがあります。

  1. マークアップにdir="rtl"を設定していない、LTR専用のテンプレート。
  2. 英語の製品名や連続する数字に対する、LTR表示領域の欠落。
  3. 古めかしく見えたり、見た目が煩雑になったりする、一般消費者向けUIでのニクダーの使用。
  4. すべてのステータス行に既定の男性形を使って公開してしまう、文法上の性を考慮しないテンプレート。
  5. それ以外はヘブライ語化されているページに残る、左右反転されていないUI要素（戻る操作、タイムライン、チェックリスト）。
  6. 共通部分だけの翻訳。UIはヘブライ語でも、本文は英語のままです。
  7. ヘブライ語のURLをクローラーから見えなくしてしまう、Cookieだけに依存した言語切り替え。
  8. 不備のあるhreflang（相互参照リンクの欠落）。
  9. 地域に応じた自動リダイレクトによって、ユーザーやボットが別の地域版にアクセスできなくなる。
  10. ヘブライ語のURLでの、英語ページを指すcanonicalの指定。
  11. 「対象外」として扱われる、メール、SMS、PDFでの双方向テキストの表示不具合。
  12. 機械翻訳だけで内容の薄い言語版を作り、有用なコンテンツとしての基準を満たせない。

コンテンツ量を増やす前に、文字の表示方向、フォント、文法上の性の扱い、サイト構造を整えましょう。ツールはプロセスを確実に実行するためのものであり、検索順位向上の根拠のない約束を生み出すためのものではありません。

公開前のチェックリスト

ヘブライ語版を公開する準備ができたら、このチェックリストを活用してください。

GlotEOが担う役割

ヘブライ語は翻訳メモリの活用に非常に適しています。製品関連の名詞は繰り返し登場し、英語のまま残す用語はラテン文字を維持する必要があります。また、次に英語版が更新されても、文法上の性や正書法のルールをぶらしてはいけません。ウェブサイトローカライズプラットフォームの用語集と翻訳メモリを使えば、表示方向に配慮したコピー、文体、機能名の一貫性を保ちながら、レイアウト検証済みの文字列を公開できます。さらに多言語SEOツールを組み合わせることで、展開規模が拡大しても、ヘブライ語のURL、hreflang、メタデータを確認しやすい状態に保てます。初回のheリリースの範囲を検討する際は、GlotEOの料金とプランを比較してください。まだ対象言語を選んでいる段階なら、より広い視点でウェブサイト翻訳のワークフローから検討を始めましょう。

Cookieによる言語切り替えや、機械翻訳であることを明示していない下書きでは、heを安心して公開できなくなったら、GlotEOのウェブサイトローカライズをご検討ください。

参考文献