ウェブサイトの日本語翻訳：文体・文字種・フォーム

日本語のウェブサイトローカライズ：敬語の使い分け、漢字・かな、フォーム、フォント、日本語（ja）のSEO調査。

Grant Davies更新日

ウェブサイトの日本語化：白いグリッド上に漢字・かな・ラテン文字の3段のレーンと/jaのラベルを配置

「ウェブサイトを日本語に翻訳する」という依頼を受けても、辞書で単語を置き換えるだけの作業と考えてはいけません。ウェブ上の日本語では、文体と文字表記の設計が重要です。同じ機能の説明でも、「です・ます」の使い方が一貫しているかどうかで、丁寧にも幼稚にも聞こえます。カタカナの外来語も、SaaSのUIをわかりやすくする場合と、英語を安易に流用したように見せてしまう場合があります。

この記事は、ウェブサイトの日本語版（ja）を公開するためのガイドです。ロケールの選択、文字表記とフォント、クロール可能なURL、フォームと購入手続きの品質確認、MTPEと人によるレビューの使い分け、SEOの落とし穴、そして実際に使えるチェックリストを紹介します。

文字列の置き換えだけではない、ウェブサイトの日本語化に必要なことは？

CMSの各フィールドを翻訳するだけでは不十分です。漢字・ひらがな・カタカナを意図的に使い分ける制作フロー、製品・メール・チャットで統一された丁寧さ、日本語の文字を網羅したフォント、日本の氏名・住所に対応した入力欄、本文が実際に日本語になっているクロール可能なjaのURLが必要です。キーワード調査も、英語の主要キーワードを翻訳ツールにかけるのではなく、ユーザーが実際に入力する外来語の表記も含め、日本語で行う必要があります。

このガイドでわかること

  • 文字列の置き換えだけではない、ウェブサイトの日本語化に必要なことは？
  • 日本語のロケールや地域別の表現はどう選ぶべき？
  • 日本語特有の文字表記・組版・レイアウトの課題とは？
  • 日本語版サイトのURL・hreflang・インデックス登録はどう設計すべき？
  • 日本語のオンボーディングや購入手続きで気をつけるべき点は？
  • 日本語化にはAI翻訳・MTPE・人によるレビューのどれを使うべき？
  • 日本語ページで特に悪影響を及ぼすSEOのミスとは？
  • 日本語版サイトを公開し、効果を測定するには？

要点：ウェブサイトを適切に日本語化するには

公開後も安定して運用できる日本語版にするには、次の点が重要です。

  1. 丁寧さを共通のルールとして設計します。「です・ます」調とくだけた文体のどちらを使うかは、製品UI・メール・チャット全体で統一し、画面ごとにモデル任せで決めないようにします。
  2. ja（多くの場合はja-JP）は、Cookieだけで切り替えるのではなく、クロール可能な独立したURLで公開します。
  3. ナビゲーション、カード、購入手続き、メールを実際の日本語テキストで試作し、改行、代替フォントへの切り替わり、漢字の見切れなどを公開前に確認します。
  4. ヘルプセンターのMTPEに着手する前に、製品名のカタカナ表記ルールを決めます。決めておかないと、同じ機能に対して翻訳会社ごとに異なる表記が生まれます。
  5. 検索クエリは日本語で調査し、それに合ったページタイトルを作成します。日本語のクエリは英語の同等表現より短かったり、外来語の表記が異なったりするためです。
  6. 規模を拡大する前に、相互参照するhreflang、同じ言語のURLを指定するcanonical、サイトマップを設定しましょう。

CSA Researchが29か国の消費者8,709人を対象に行った調査では、76%が母語の情報を見て購入することを好み、40%が他言語のウェブサイトでは一切購入しないと回答しています。英語を読める日本語話者がいても、この傾向は変わりません。購入手続き、請求書、サポートといった場面では、英語だけの対応が販売機会の損失につながります。Googleの有用なコンテンツに関するガイダンスは、ユーザーを第一に考えたページを重視しています。ナビゲーションだけが日本語で本文が英語のままでは、日本語版として不十分です。市場と言語のどちらを軸に戦略を立てるかについては、国際SEOと多言語SEOの違いをご覧ください。

適切な日本語ロケールを選ぶ

最初の販売対象が日本市場であれば、多くのチームにとって、日本向けのja-JPのURLでjaを公開するのが適切です。初回リリースとして妥当な選択ですが、一般消費者向けのくだけた表現、B2B向けの堅い敬語、未翻訳の英語を1つのファイルに混在させて「日本語ロケール」と呼んでよいわけではありません。

ウェブサイトの日本語では、ほとんどの製品UIに共通の標準的な書き言葉を使います。話し言葉には地域差がありますが、最初に決めるべきなのは方言ではなく文体です。ほぼすべてのB2Bと大半の消費者向けSaaSでは、丁寧な「です・ます」調を使います。くだけた文体を選ぶのは、ブランドが明確に若者向けであり、エラーや請求の案内を含むすべての場面で統一できる場合に限ります。B2Bでは、遊び心のある消費者向けアプリよりも、ほぼ例外なく整った丁寧な表現が求められます。特に料金やセキュリティの画面で文体が混在すると、信頼感を損ないます。

海外にも日本語の読者はいますが、円での価格表示、住所形式（郵便番号・都道府県・市区町村・番地）、法的事項のページは、販売対象市場に合わせる必要があります。日本拠点のバイリンガル社員が使う英語を、日本向け販売サイトの絶対的な基準にしないでください。

氏名と住所の扱いも決めておきましょう。日本の氏名は姓・名の順であり、「名／姓」の欄に米国式の住所欄を組み合わせればよいわけではありません。米国向けフォームのラベルを翻訳するだけでは、ローカライズとはいえません。

日本語の文字表記・組版・レイアウトで押さえるべき点

日本語のUIでは、3種類の文字を意図的に使い分けます。

  • 漢字 — 短いスペースに多くの意味を凝縮
  • ひらがな — 文法的なつながりや、やわらかな表現
  • カタカナ — 外来語、強調、多くの技術用語やブランド関連用語

フォントスタックに必要な漢字が含まれていないのは、軽微な不具合ではありません。ページの表示が破綻する問題です。ラテン文字を前提にしたテーマで、日本語に対応していないフォントにフォールバックすると、文字が四角い記号になる「豆腐」、文の途中でのフォント混在、文字の上下が切れるといった問題が起こります。

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

  • 漢字の多い見出しやカタカナの製品名も含め、実際の日本語テキストを使って主要画面を試作します。
  • 日本語は英語よりも文字あたりの情報密度が高くなります。ラテン文字を前提にしたカードは、余白が目立ったり、予想外にはみ出したりします。英語の40文字制限を、そのまま日本語に適用できると考えないでください。
  • 改行や約物の扱い（全角・半角）は、ラテン文字のレイアウトとは異なります。モバイル画面の幅で、ボタン、バッジ、表の見出しをテストします。
  • ラテン文字を前提にしたテーマよりも行の高さを広げ、ルビのない本文や複数の文字種が混在する文章にも、上下に余裕を持たせます。
  • UI、メール、PDFの本番環境には、日本語の文字を網羅したフォントを用意します。メールクライアントがラテン文字用フォントに置き換えてしまうと、エラーが出ないまま表示が崩れます。
  • 英語と同じ感覚で、単純な文字数だけを基準にテキストを省略しないでください。熟語の途中で切れたり、助詞だけが末尾に残ったりします。

日付と数値も、レイアウト設計の要件に含まれます。日本では通常、年月日順の日付表記、必要に応じた法的文書での和暦対応、UIでの全角・半角数字の使い分け、実際に日本で販売する場合の円表記、日本の住所に合った郵便番号欄が求められます。日本語のリストを英語のASCII文字列と同じように並べるだけでは、適切な照合・並べ替えルールを定めたことにはなりません。

文章のリズムも重要です。英語のCTAは、短くそっけない表現がよく使われます。日本語の製品コピーでは、堅苦しくならない範囲で、もう少し言葉を補うのが自然な場合が多くあります。一方、決済やエラーの案内は、わかりやすく、一貫して丁寧に書きます。

カタカナの外来語は、SaaSのUIを現代的に見せることもあれば、英語を安易に流用した印象を与えることもあります。どの製品用語を英語やカタカナのまま使い、どれを日本語に置き換えるかを決めましょう。ヘルプセンターのMTPEに入る前に、その一覧を用語集にまとめます。

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

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

hreflangは、指定した代替ページ群の間で相互に設定する必要があります。各ロケールのURLには、明確なcanonicalを設定し、重複がある場合は同じ言語の優先URLを指すようにします。日本語ページのcanonicalに、対応する英語ページを指定してはいけません。

Bing Webmaster Guidelinesは、市場を問わず、クロール可能で有用なコンテンツと明確なサイト構造を重視しています。Googleは、推測した言語や所在地に基づいてユーザーを自動転送しないよう助言しています。代わりに、日本語版URLへのリンクを備えた、見つけやすい言語選択機能を用意しましょう。IPアドレスから「日本 → /ja」と推測して振り分けると、旅行者、VPN利用者、クローラーが意図しない転送から抜け出せなくなります。

URLのルールとページ内コンテンツのルールは、分けて考えられます。運用上の理由でASCIIのスラッグを維持することはできますが、タイトル、H1、本文は日本語にする必要があります。「エンコードが面倒だから」という理由で、jaのURLに英語のタイトルを掲載するのは、品質上の問題です。日本語スラッグをパーセントエンコードする場合は、リダイレクトを一貫して設定し、canonicalを指定しないまま競合する2つの日本語URLを公開しないでください。

日本語の検索クエリは、英語の同等表現より短かったり、外来語の表記が異なったりします。翻訳を介すのではなく、日本語で調査しましょう。そうすることで、日本語の検索結果になじむタイトルを作れます。ただし、検索順位を保証するものではありません。

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

日本語版では、信頼性を支えるページが、翻訳された機能一覧以上に重要な役割を果たします。日本向けに販売するサイトでは通常、プライバシーポリシー、利用規約、該当する場合は特定商取引法に基づく表記、支払いや購入後のサポートに関する案内が必要です。英語のテンプレートが残ったままではなく、きちんと整えられたページとして読める内容にしましょう。これは検索順位を上げる施策ではありません。ユーザーが安心して購入手続きを進められるかどうかを判断する際に確認する情報です。これらのページも、主要ページと同じ優先度でローカライズしてください。

日本語版のコンバージョンに関する実践的な確認項目：

  • ホームページ、広告、製品UI、メールで、丁寧さのレベルが統一されている。
  • フォームでは、日本のユーザーが想定する姓・名の順で氏名を入力でき、郵便番号、都道府県、それ以降の住所欄が用意されている。ラテン文字での入力が必要な場合は、その理由が説明されている。
  • Cookieや同意に関する文言を、実際のバナー上で確認している。複数の文字種が混在すると、改行の位置が変わるためです。
  • 料金、請求書、消費税の表記、そして日本で販売する場合の円表示が、対象として掲げる市場に合っていること。
  • サポートの定型返信や取引関連メールでも文体を統一します。「です・ます」調の購入手続きの後に、くだけた文体のエラーメールが届くようでは、一貫性が損なわれます。
  • エラーメッセージでは、曖昧に謝るのではなく、解決方法を明示します。セキュリティ関連の画面で常体と敬体が混在していると、信頼を損ないます。
  • 支払い方法や、提供している場合はコンビニ決済・国内決済サービスに関する文言も、プロダクトのコンテンツとしてレビューします。英語のまま放置してはいけません。

公開初日からすべてのブログ記事をそろえる必要はありません。ただし、ホームページと製品説明、認証、料金、購入手続き・請求、プライバシーに関する基本情報、サポート窓口、そして対象市場で求められる法務関連ページは必要です。

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

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

  • 未編集の機械翻訳：使えるのは社内向けの下書きまでです。モデルの出力は常体と敬体の間でぶれやすく、カタカナを多用し、料金画面では不自然に堅い表現や幼稚な表現になることがあります。
  • MTPE（機械翻訳＋ポストエディット）：用語集で製品関連の名詞、カタカナ表記、丁寧さの基準を固定していれば、多くの製品ページやサポートページで標準的な手法として安心して採用できます。
  • 人による翻訳／ブランド観点での編集：ホームページ、料金、キャンペーン、Cookie・同意に関するページ、法的事項に関わるあらゆるページに適しています。

日本語向けの実践的なレビューサイクル：

  1. 用語集に準拠したMTPEの原稿を作成する（文体とカタカナ表記を固定）。
  2. ブランド担当の編集者がホームページ、料金ページ、主要なランディングページを確認する。
  3. プロダクトに精通した言語担当者が、エラー、請求、動的UIの文言をレビューする。特に助詞と変数が埋め込まれる文字列を重点的に確認する。
  4. ステージング環境で、モバイルの画面幅を使って日本語のQAを行う。メールとPDFの表示確認、実機でのフォント確認も含める。
  5. 公開前チェックを追加し、jaのURLで本文に英語が残っている箇所や、同じテンプレート内で「です・ます」調とくだけた文体が混在している箇所を検出する。

機械翻訳だけで作られた低品質な日本語ページは、CMS上では完成しているように見えても、ユーザーの役に立たず、ユーザーを第一に考えた有用なコンテンツとしての要件も満たしていないことがあります。

日本語SEO特有の落とし穴

日本語で検索するユーザーが求めているのは、自分が読んで理解できる言葉です。英語の主要キーワードを逐語訳したり、jaのURLで英語のタイトルを検索結果に表示させたりしても、実際の検索行動には合いません。漢字・かな・カタカナの外来語などの表記の違いも含めて日本語のキーワード調査を行い、日本語の検索結果になじむタイトルとH1を作成しましょう。

日本語URLごとに、タイトル、メタディスクリプション、見出しをローカライズします。英語のメタデータ一式を、複数のロケールで使い回してはいけません。

日本語ページで特に悪影響を及ぼすミス：

  1. タイトル、ボタン、メールで丁寧さが統一されていない。
  2. 共通部分だけの翻訳。ナビゲーションなどのUIは日本語でも、本文は英語のまま。
  3. 本番環境のフォント、メール、PDFで必要な漢字が表示できない。
  4. カタカナ表記が管理されていないため、同じ機能の表記がページごとに異なる。
  5. Cookieだけに依存した言語切り替えにより、クローラーが日本語URLを見つけられない。
  6. 不備のあるhreflang（相互参照リンクの欠落）。
  7. 地域に応じた自動リダイレクトによって、ユーザーやボットが別の地域版にアクセスできなくなる。
  8. 機械翻訳だけで内容の薄い言語版を作り、有用なコンテンツとしての基準を満たせない。
  9. 英語だけのキーワード調査を日本語のタイトルに当てはめる。

コンテンツ量を増やす前に、文体、フォント、フォーム、サイト構造を整えましょう。ツールはプロセスを確実に運用するためのものであり、検索順位の向上を根拠なく約束するためのものではありません。

公開前のチェックリスト

日本語版の公開準備が整ったら、このチェックリストを使いましょう。

GlotEOが担う役割

日本語は翻訳メモリの活用に適しています。製品関連の名詞は繰り返し登場するため、次に英語の更新版が届いたときも、カタカナ表記や丁寧さを変えてはいけません。ウェブサイトローカライズプラットフォームの用語集と翻訳メモリを使えば、文体、文字表記、機能名の一貫性を保ちながら、レイアウト確認済みの文言を公開できます。さらに多言語SEOツールを組み合わせれば、展開を広げても日本語URL、hreflang、メタデータをレビューしやすい状態に保てます。初回のjaリリースの範囲を検討する際は、GlotEOの料金とプランを比較してください。まだ対応言語を選んでいる段階なら、より広い視点でウェブサイト翻訳のワークフローを検討するところから始めましょう。

文体が混在した機械翻訳の下書きや、必要な漢字を表示できないフォントでは、jaを安心して公開できないと感じたら、GlotEOのウェブサイトローカライズをご検討ください。

参考文献