日本向けWebサイトのローカライズ：成果を左右するIA・UX・SEOの設計判断

海外企業の日本語サイトに関わっていると、よく出会う光景があります。日本語版を公開し、翻訳はネイティブチェックも済んでいる。日本からのアクセスも来ている。それなのに、コンバージョン率は本国サイトより目に見えて低い。しかも、どこが壊れているのか誰も指摘できない。

たいていの場合、壊れているところはありません。言葉は翻訳されていても、サイトはローカライズされていないのです。日本のユーザーは、ページがどこまで説明してくれるか、会社情報がどこにあるか、フォームで何を聞かれるか、価格がどう表示されるかについて、はっきりした期待を持って訪れます。その期待を外したサイトは「間違っている」というより「よそよそしく」見え、そのよそよそしさはそのまま不安として受け取られます。

翻訳とローカライズは別物です

翻訳はテキストを置き換える作業、ローカライズは体験を置き換える作業です。直訳が見落としがちな期待のうち、影響が大きいのは次の3つです。

1. 情報量。 日本の製品・サービスページは長く、具体的な傾向があります。仕様、料金の詳細、導入事例、よくある質問まで載っているのが普通です。見出しひとつとCTAひとつで終わるミニマルなランディングページは、「何か隠しているのでは」と受け取られかねません。余白はそのままに、スクロールの先や詳細ページで情報の厚みを足しましょう。
2. 信頼の手がかり。 特にBtoBの担当者は、検討を進める前に「どんな会社か」を確認します。導入企業のロゴ、導入事例、プライバシーマーク（Pマーク）やISMSといった認証、対応時間を明記した日本語の問い合わせ窓口は、いずれも効きます。
3. 手順の明示。 申し込んだあと何が起きるのかを書きましょう。営業から連絡が来るのか、トライアルはいつ終わるのか、解約はどうするのか。

マイクロコピー：直訳とローカライズの違い

直訳がいちばん表に出るのはトーンです。英語のプロダクトコピーはカジュアルで命令形が中心ですが、日本語ではです・ます調で具体的に書くのが基本です。

場面	原文（英語）	直訳	ローカライズ後
BtoBのメインCTA	Book a demo	デモを予約	資料ダウンロード（無料）＋お問い合わせ
エラー	Oops! Something went wrong.	おっと！問題が発生しました。	申し訳ございません。エラーが発生しました。時間をおいて再度お試しください。
メールの宛名	Hi Taro,	こんにちは、太郎さん	山田 太郎 様
フォームのボタン	Submit	送信	入力内容を確認する

韓国語から訳す場合は、「신청」を「申請」、「제출」を「提出」とそのまま漢字語で移してしまい、役所の書類のように硬くなる例もよく見かけます。Webでは「お申し込み」「送信」「確認する」が自然です。

なかでも重要なのはCTAの行です。日本のBtoBでは、まず資料をダウンロードする（いわゆる資料請求）のが一般的な第一歩です。営業と話す前に、社内で資料を回覧して検討できるからです。「デモを予約」しか用意していないと、多くの担当者が最初に踏みたいステップを飛ばさせることになります。

IAとナビゲーション：ユーザーが探すラベルを使う

日本の企業サイトにはかなり定型化したナビゲーションの語彙があり、ユーザーはまさにその言葉を目で探します。

目的	定番のラベル	補足
会社について	会社情報 / 企業情報	会社概要、沿革、トップメッセージ、アクセスの入口
製品	製品情報 / サービス	ビジネスモデルに合わせて選ぶ
投資家向け	IR情報	上場企業の場合
採用	採用情報	新卒採用とキャリア採用に分けることが多い
問い合わせ	お問い合わせ	ヘッダーに常設ボタンとして置くのが一般的
FAQ	よくある質問	料金ページやフォームからもリンクする
個人情報	プライバシーポリシー	個人情報保護方針とすることもある
サイトマップ	サイトマップ	フッターからリンクするHTMLページ

GNBとフッターの構造設計については、GNB and Footer Structure Best Practices（英語）で詳しく解説しています。日本語版ができたら、翻訳スプレッドシートを信用するのではなく、本国サイトと構造を突き合わせてください。DeepAnalyzerは両方のサイトをクロールしてScreen ID付きのIA（Excel）を書き出し、検出した言語でラベル（決済、カート、採用情報など）を生成するため、日本側のレビュー担当者も用語集なしで読めます。

会社概要はコンバージョンページです

欧米のサイトでは「About」はブランドストーリーであることが多いのですが、日本の会社概要はファクトシートであり、検討者は実際に読み込みます。会社名、設立、資本金、代表者、所在地、従業員数、事業内容は押さえておきましょう。日本法人を持たない企業の場合は、契約主体がどこなのか、日本の顧客をどうサポートするのかを明記することが欠かせません。

HTMLサイトマップページは残す

人が読むためのサイトマップページは欧米のサイトでは減りましたが、日本の企業サイトではいまも定番のフッターリンクです。全体像から目的のページを探すユーザーの助けになり、クローラーにとってもすべてのセクションへの浅い導線になります。手作業で更新するのではなく、IAから生成しましょう。

ECサイト：特定商取引法に基づく表記

日本の消費者にオンラインで販売する場合、特定商取引法は、ネットショップを含む通信販売事業者に対して、事業者の名称、住所、電話番号、販売価格と送料などの付帯費用、支払い・引き渡しの条件、返品の条件といった事項の表示を求めています。一般的な実装は「特定商取引法に基づく表記」というページを作り、フッターと購入画面からリンクする方法です。近年の改正では、申し込みの最終確認画面に表示すべき事項も定められました。コピーライティングの課題ではなく、法務レビューの項目として扱ってください。

フォーム：コンバージョンが静かに漏れる場所

欧米の氏名・住所を前提に作られたフォームは、日本では小さな問題を何重にも引き起こします。海外の本社から届くフォーム仕様をそのまま実装すると、ほぼ確実にどこかでつまずきます。

項目	欧米のデフォルト	日本の慣習	実装のポイント
氏名	First, Last	姓 → 名	2つのフィールドに分け、姓を先に
読み	なし	フリガナ（セイ / メイ）	漢字の氏名は読み方が一つに定まらない
郵便番号	都市名の後	〒を先頭に、7桁（150-0001）	都道府県と市区町村を自動入力
住所	番地 → 都市 → 州	都道府県 → 市区町村 → 番地 → 建物名	大きな単位から。建物名・部屋番号は別フィールド
電話番号	単一の形式	03-1234-5678、090-1234-5678	ハイフンの有無どちらも受け付ける

郵便番号が先頭に来るのには理由があります。7桁で都道府県と市区町村が特定できるので、ユーザーは番地と建物名だけを入力すれば済みます。日本のECに慣れたユーザーは、これがないとすぐに気づきます。

全角入力は弾かずに正規化する

日本語はIMEで入力するため、ユーザーが気づかないまま全角数字（１２３）を入れるのは日常茶飯事です。最悪の対応は、いまだによく見る「半角数字で入力してください」というエラーです。何が入力されても受け付けて、正規化しましょう。

// 郵便番号・電話番号にだけ適用します。氏名欄で「ー」を置換しては
// いけません。カタカナの長音符として実際に使われます（例：ヨーコ）。
const normalizeJaNumber = (value) =>
  value
    .normalize("NFKC")               // １５０－０００１ → 150-0001
    .replace(/[‐‑‒–—―−ー]/g, "-")    // ハイフン類似文字 → "-"
    .replace(/\s+/g, "");

NFKCは半角カナ（ｶﾀｶﾅ）も全角に変換してくれます。フリガナ欄に保存したいのはまさにその形です。さらに2つの慣習も押さえておきましょう。日本のフォームは入力 → 確認 → 完了の3ステップが一般的です。また、自動送信メールでは顧客を名前だけで呼ばず、フルネームに「様」を付けます。

決済・価格・日付

実際に使われている決済手段を用意する

カード決済だけでは、日本の顧客を取りこぼします。現実的な構成は次のとおりです。

• クレジットカード。 国内ブランドであるJCBは必ず含めます。
• コンビニ払い。 顧客が払込番号を受け取り、コンビニのレジで現金で支払います。入金を確認してから発送します。
• QRコード決済。 PayPay、楽天ペイ、d払いなど。
• 銀行振込。 高額の注文やBtoBで一般的です。
• 代金引換と後払い。 いまもこれを求める顧客層があります。

BtoBでは、カード登録よりも見積書と請求書払いが期待されることが多く、「月末締め翌月末払い」のような支払いサイトを前提に稟議が進むこともあります。日本企業に請求書を発行するなら、インボイス制度がどう関係するかも確認しておきましょう。

価格は税込の総額で表示する

2021年4月から、消費者に価格を表示する事業者には税込の総額表示が求められています。11,000円（税込）のように書き、必要に応じて税抜価格を併記します。ただし、税抜価格を大きく目立たせて総額が脇役に見えるような表示は避けてください。海外のドル建てSaaSの料金表をそのまま移すと、税抜表示になりがちなので要注意です。BtoB向けの価格は基本的に対象外ですが、いずれにしても「税込」「税抜」は明記しましょう。

日付と和暦

標準的な表記は「2026年9月23日」で、「2026年9月23日（水）」のように曜日を添えることも多いです。数字だけで書く場合も「2026/09/23」と年が先頭です。和暦（2026年は令和8年）は役所の書類や一部の公的な書式ではいまも使われていますが、マーケティングサイトで必要になる場面は多くありません。

const d = new Date("2026-09-23T12:00:00+09:00");
new Intl.DateTimeFormat("ja-JP", { dateStyle: "long" }).format(d);
// "2026年9月23日"
new Intl.DateTimeFormat("ja-JP-u-ca-japanese", { dateStyle: "long" }).format(d);
// "令和8年9月23日"

ゴールデンウィーク、お盆、年末年始の配送・サポート体制も、事前に告知しておきましょう。休業期間の告知がないまま問い合わせへの返信が止まると、それだけで不信感につながります。

文字組み：日本語には単語間のスペースがない

日本語は単語の間にスペースを入れないため、行はほぼどこででも折り返されます。

禁則処理。 閉じ括弧や句読点（、。」）は行頭に来てはならず、開き括弧は行末に残してはいけません。ブラウザは基本的な禁則を標準で適用しますが、line-break: strictを指定すると、小書きの仮名（ゃ、っ）や長音符（ー）も行頭に来ないよう、より厳格なルールが適用されます。

文節単位の改行。 本文で単語の途中で折り返されるのは日本語では普通のことですが、大きな見出しでは雑に見えます。Chromium系のブラウザは、lang="ja"が指定されたコンテンツに対してword-break: auto-phraseをサポートしており、BudouXのモデルで自然な文節の切れ目で改行します。非対応のブラウザはこの値を無視するだけなので、いまから導入しても安全です。

html:lang(ja) {
  font-family: "Hiragino Sans", "Hiragino Kaku Gothic ProN",
    "Noto Sans JP", "Yu Gothic", YuGothic, Meiryo, sans-serif;
  line-height: 1.8;
  line-break: strict;
}

h1:lang(ja), h2:lang(ja) {
  word-break: auto-phrase;   /* Chromium。lang="ja" が必要 */
  text-wrap: balance;
}

em:lang(ja) {
  font-style: normal;        /* 和文フォントにイタリック体はない */
  font-weight: 700;
}

• フォントスタック。 ブラウザはWebフォントを実際に使うときにしかダウンロードしないため、ヒラギノを先頭に置けばApple端末はNoto Sans JPを取得しません。Windowsでは游ゴシックの標準ウェイトが細く表示されることがあり、"Yu Gothic Medium"を指定するのが定番の対策です。見出しにはfont-feature-settings: "palt"で字詰めをかけるのもよく使われる手法です。
• フォントの容量。 和文フォントには数千字のグリフが含まれ、1ウェイトだけで数MBになることもあります。サブセット化するかunicode-rangeで分割しましょう（Google FontsはNoto Sans JPを多数の小さなファイルに分割して配信しています）。ウェイトは2つまでに抑えます。
• 行間。 漢字は字面が詰まって見えるため、本文の行間は1.7〜1.9程度が読みやすくなります。
• 疑似イタリックは使わない。 和文書体にはイタリック体がないため、font-style: italicは文字を無理に傾けただけの表示になります。強調には太字や傍点（text-emphasis: filled sesame）を使いましょう。

日本語版のテクニカルSEO

サブディレクトリか .jp か

選択肢	例	トレードオフ
サブディレクトリ	example.com/ja/	評価が1つのドメインに集まり、運用するサイトも1つ。基本はこれ
ccTLD	example.jp、example.co.jp	国内向けのシグナルと信頼感が強い。.jpは原則として国内の住所が、.co.jpは日本で登記した会社が必要で、評価はゼロから

日本のドメインを選ぶのは、日本法人があり、長期的に現地ブランドを育てる場合に限りましょう。.co.jpは「日本に登記された会社である」ことの目印として、BtoBでは安心材料になることもあります。ロケールをURLのどこに置くかはURL Structure Best Practices（英語）を参照してください。

言語を正しく宣言する

すべての言語版を、自己参照とx-defaultを含む相互のhreflangでつなぎます。日本語は実質的に日本でしか使われないためjaで十分で、ja-JPも有効です。jpは国コードであり、指定そのものが無効になります。詳しいルールはhreflangガイド（英語）にまとめています。

<html lang="ja">
<link rel="alternate" hreflang="ja" href="https://example.com/ja/pricing/" />
<link rel="alternate" hreflang="ko" href="https://example.com/ko/pricing/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/pricing/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/pricing/" />

lang="ja"には、漢字を日本語の字形で表示させる役割もあります。これがないと、環境によっては日中韓で共通の漢字が中国語フォントで表示される、いわゆる「中華フォント」問題が起きます。日本のユーザーはすぐに違和感を覚えます。

IPによる強制リダイレクトはしない、スラッグはASCIIで

IPによるリダイレクトは、別の言語版を見たいユーザーを閉じ込めるうえ、主に日本国外からクロールするクローラーから日本語ページを隠してしまうおそれがあります。代わりに、閉じられる言語案内バナーを表示しましょう。

日本語のスラッグはアドレスバーでは親しみやすく見えますが、共有した瞬間にパーセントエンコードされます。/ja/料金プラン/は/ja/%E6%96%99%E9%87%91%E3%83%97%E3%83%A9%E3%83%B3/になり、LINEやメールに貼ると一気に怪しく見えます。すべてのロケールで同じASCIIスラッグ（/ko/pricing/、/ja/pricing/）を使えば、hreflangの対応付けも簡単になります。

メタデータ、Yahoo! JAPAN、OGP

• タイトルとディスクリプション。 検索結果のスニペットはピクセル幅で切り詰められ、全角文字は幅を取ります。目安として、タイトルは30〜35文字程度、ディスクリプションは120文字前後とし、重要な語を前に置きましょう。英語のメタタグを訳すのではなく、日本語で書き起こしてください。
• Yahoo! JAPAN。 ウェブ検索の結果はGoogleの検索技術によって提供されているため、Googleを軸にしたSEOで両方をカバーできます。
• OGP。 日本ではリンクがLINEやXで盛んに共有されるため、プレビューカードが第一印象になることが少なくありません。og:title、og:description、日本語が読めるog:image、og:locale（ja_JP）、twitter:card（summary_large_image）を設定しましょう。LINEはOGPをキャッシュするので、公開後に画像を差し替えた場合はLINE公式のPagePokerでキャッシュを更新します。JavaScriptで描画するサイトなら、これらのメタデータがサーバーのレスポンスに含まれているか確認が必要です。通常のクロールとStrong Mode（ヘッドレスブラウザ）でのクロール結果を比べれば、レンダリングしないボットが何を見落としているかがすぐにわかります。

公開前チェックリスト

• GNBとフッターに定番のラベル（会社情報、製品情報、採用情報、お問い合わせ）を使っているか
• 会社概要に設立、資本金、代表者、所在地、従業員数を載せているか
• HTMLのサイトマップページをフッターからリンクしているか
• （EC）特定商取引法に基づく表記をフッターと購入画面からリンクし、法務の確認を受けたか
• フォームに姓 → 名、フリガナ、郵便番号からの住所自動入力、全角入力の正規化を実装したか
• コンビニ払い、QRコード決済、銀行振込を必要に応じて用意したか
• 消費者向けの価格をすべて税込の総額で表示しているか
• lang="ja"、line-break: strict、見出しの文節改行、フォントのサブセット化を適用したか
• x-defaultを含む相互のhreflangを設定し、IPでの強制リダイレクトをせず、ASCIIスラッグを使っているか
• タイトル、ディスクリプション、OGP画像を日本語で作り直したか
• マイクロコピーを、翻訳者の校正ではなくネイティブのライターが書き直したか

よくある質問

日本語サイトに機械翻訳を使ってもよいですか？

たたき台としては使えますが、そのまま公開できる品質にはなりません。いちばん大きな差が出るのは、トーン、マイクロコピー、そして日本のユーザーが期待しているのに原文には存在しないコンテンツです。主要ページ、CTA、フォームはネイティブの編集者が書き直す前提で予算を組みましょう。

/ja/ のサブディレクトリと .jp ドメインのどちらがよいですか？

多くの企業にとっては/ja/がよい選択です。評価が1つのドメインに集まり、運用するサイトも1つで済みます。日本法人があり、長期的に現地ブランドを育てる計画があるなら、.jpや.co.jpを選ぶ意味があります。

hreflangの値は ja と ja-JP のどちらにすべきですか？

どちらも有効で、日本語は実質的に日本でしか使われないため、通常はjaで十分です。それよりも大切なのは相互参照で、すべての言語版が自分自身を含むすべての版を列挙している必要があります。国コードであるjpは使わないでください。

特定商取引法に基づく表記のページは必要ですか？

日本の消費者にオンラインで商品やサービスを販売するなら、特定商取引法にもとづき事業者情報や取引条件の表示が求められるのが一般的で、専用ページを設けるのが標準的な方法です。純粋なBtoBサイトや取引機能のないサイトでは、事情が異なる場合があります。具体的な義務は日本の法律の専門家に確認してください。

Yahoo! JAPAN向けに別のSEO対策は必要ですか？

必要ありません。Yahoo! JAPANの検索結果はGoogleの検索技術によって提供されているため、Google向けの施策がそのまま効きます。その分、日本語で書き起こしたメタデータと、LINEやXで共有されたときに見栄えのするOGPに力を注ぎましょう。