- 翻訳しただけのオンボーディングで、なぜ日本のユーザーは離脱するのですか？
- 最初のセッションは、ユーザーが製品を実際に使う最初の機会です。翻訳しただけのフローは、欧米のサンプルデータ、1つの氏名欄、MM/DD形式の日付、ドル金額、堅いガイダンス文といったロケール前提を一度に表に出します。小さなズレの一つひとつが「この製品は日本向けに作られていない」とユーザーに伝わります。するとユーザーは静かにタブを閉じ、セッションはそこで終わります。
- ローカライズされた日本語オンボーディングには、実際に何が必要ですか？
- 翻訳だけでは足りません。姓→名の順の日本語氏名、7桁の郵便番号を入力すると自動で入る住所、「2026年6月25日」形式の日付、整数の円、氏名／ふりがなのフォーム欄、全角・半角の許容、そしてウェルカムモーダル・空の状態・コーチマーク・エラーを通した一貫した一つの丁寧な語り口が要ります。
- なぜオンボーディングを独立したローカライゼーション対象として扱うのですか？
- 短い時間に集中していて、ユーザーも時間に追われている場面だからです。初回起動は数分のうちに起き、2回目のセッションがあるかどうかを左右します。設定ページの翻訳がよくできていても、ウェルカム画面が欧米のデータ構造を前提にしているために、そこでユーザーを失う製品があります。
要点（TL;DR）
多くの海外SaaS製品は、オンボーディングを翻訳しただけでそのまま出荷します。文字列は正しくても、最初のセッションで日本のユーザーを失います。オンボーディングこそ、あらゆるロケール前提が一度に表面化する場所だからです。ウェルカム画面は英語のテンポとトーンを残し、サンプルダッシュボードには John Smith・ドル金額・MM/DD/YYYY形式の日付が並び、登録フォームは氏名欄を1つと手入力の住所を想定し、コーチマークは過度に長い逐語訳、ガイダンス文は丁寧体とカジュアルが混在しています。一つひとつのズレは小さくても、初回起動はユーザーが「この製品は自分のために作られたか」を判断する瞬間です。しかもユーザーはこの時点で、留まる理由になるものをまだ何も注ぎ込んでいません。初回起動エクスペリエンスのローカライズとは、日本語のサンプルデータ、氏名とふりがなの欄、郵便番号オートフィル、全角／半角の許容、正しい日付・通貨形式、そして静かで一貫した一つの丁寧な語り口を用意することです。どれもデータを捏造する話ではなく、すべて日本のユーザーが実際に最初のセッションに期待する挙動を反映したものです。
キーポイント
- 最初のセッションが評価そのもの — 日本のユーザーは、ヘルプを読む前、製品を実際に使う最初の数分で「使い続けるか」を決めます。
- ユーザーはサンプルデータを丁寧に読む — デモデータに欧米の氏名・ドル金額・MM/DD形式の日付が並んでいれば、その製品は日本で本格的に使われたことがないという手がかりになります。
- フォームは日本語入力を想定すべき — 姓名を分けた欄＋ふりがな欄、7桁郵便番号のオートフィル、全角／半角の許容は、例外ではなく標準の前提です。
- 一貫した一つの丁寧な語り口 — ウェルカムモーダル・ツールチップ・エラーで文体がばらつくと、雑に見えます。ローカライズしたマイクロコピーは、英語の原文より短くなるのが普通です。
- オンボーディングは独立した対象 — 短い時間に操作が集中する領域なので、文字列単位ではなく、日本のユーザーが実際にたどる流れのまま初回起動全体を検証します。
なぜ日本では最初のセッションの重みが増すのか
アクティベーションが重要だと、どのSaaS製品も分かっています。それでも、初回起動エクスペリエンスは日本のユーザーにとって特に重い意味を持ちます。最初のセッションが、ユーザーが製品について読むのではなく、実際に何かを操作する最初の機会だからです。マーケティングページなら多少ぎこちない言い回しも許されますが、初回起動はそうはいきません。ここでユーザーは「この製品は本当に自分のために作られたのか」という判断を下し始め、しかもその判断は素早く固まります。
海外のSaaSチームは通常、オンボーディングも他のすべてと同じようにローカライズします。文字列を抜き出し、翻訳し、出荷する。その結果は、単独で読めば正しくても、実際に動かすと挙動がおかしい。ウェルカムモーダルは文法的には正しいのに、英語のリズムが残っている。デモデータはアメリカのユーザーに見せるものと同じ。登録フォームは氏名が1つで、住所は自由入力の想定。どれも文字列単位のQAでは捕まらない「バグ」ではなく、それぞれが小さなサインです。5分の初回起動のあいだに積み重なると、はっきりした印象になります。これは翻訳しただけで、ローカライズされていない海外製品だ、と。
これは、ログインと認証のフローや、製品が日本語のテキスト入力とIMEをどう扱うか、紹介・招待のエクスペリエンスなど、操作の多い他の領域で結果を左右するのと同じパターンです。オンボーディングはそのすべての入り口に位置します。最初のセッションを正しく作れば、その先のローカライゼーションにも、向き合うべきユーザーが残ります。
サンプルデータ・デモデータ：日本のユーザーが最初に読むもの
ユーザーが空の製品にたどり着いたとき、何ができるかを最も早く示してくれるのが、サンプルデータやデモデータです。事前入力されたダッシュボード、サンプルプロジェクト、入力済みの請求書などがそれにあたります。これは同時に、日本のユーザーが最初に読む具体的なコンテンツでもあります。自分の本物のデータをこの製品に預けてよいかを見極めながら読むので、読み方は丁寧です。明らかにアメリカ的なデモデータは、その答えを先に明かしてしまいます。
ローカライズされたサンプルデータは、本物の日本のアカウントらしく見える必要があります。氏名は、翻訳された欧米名ではなく、山田 太郎 や 佐藤 花子 のように姓→名の順の日本語氏名にします。住所は大きい単位から小さい単位へ、〒NNN-NNNN形式の7桁郵便番号から始めて、都道府県、市区町村、と続けていきます。日付は 06/25/2026 ではなく、日本語の「2026年6月25日」形式で表示します。金額は整数の円にします。円には日常的に使う小数の補助単位がないため、¥1,500 や 1,500円 が正しく、$1,200.00 や ¥1,200.00 は誤りです。
運用ルール：サンプルデータをテスト用フィクスチャではなくローカライズ対象コンテンツとして扱う。氏名は姓→名の順、住所は〒NNN-NNNNの郵便番号で大きい単位から小さい単位へ、日付は「2026年6月25日」、金額は整数の円。デモデータ中の説明用の人物や企業は、実在の顧客として提示せず、必ず明確に架空のものとする。
フォーム：氏名、ふりがな、郵便番号、文字幅
初回起動の登録フォームやプロフィールフォームは、日本のユーザーが最初に本物のデータを入力する場所です。日本のユーザーはここに、英語のフォームにはない、具体的で強い期待を持ち込みます。それらを無視するフォームは、ユーザーが最も離脱しやすい、まさにその瞬間に摩擦を生みます。
まず氏名です。日本のフォームでは、氏名を「姓」欄と「名」欄に分けるのが一般的で、その横にふりがな（読み）欄を添えることもよくあります。読みを入力しておけば、氏名の発音を取得してレコードを正しく並べ替えられます。「氏名」欄が1つでも動作はしますが、ローカライズされていない印象になり、多くの日本のシステムが保存しようとする読みの情報が失われます。次に住所です。日本のユーザーは、まず7桁の郵便番号を入力し、そこから都道府県と市区町村が自動入力されることを期待します。これは日本のサイトでほぼ普遍的な慣習で、よく知られたライブラリでもサポートされています。郵便番号でほとんど補完できるはずなのに、ユーザーに住所をすべて手入力させると、壊れたフォームのように受け取られます。
3つ目は文字幅です。日本語入力では全角（ぜんかく）と半角（はんかく）の文字が混在し、ユーザーが常にどちらを入力するかを制御できるとは限りません。全角で入力された電話番号を、正規化もせずにはじくフォームは、ユーザーが何も悪いことをしていないのにエラーにします。両方を受け入れて正規化する寛容な入力処理は、任意のおまけではなく、フォームのローカライズの一部です。
空の状態、ウェルカム画面、コーチマーク
空の状態（エンプティステート）は、ユーザーがまだ何も作成していない段階で最初に目にするもので、役割は2つあります。何も壊れていないと安心させることと、次に何をすべきかを伝えることです。英語では、空の状態の文は軽く励ますトーンに寄りがちです。「まだ何もありません！さあ始めましょう 🎉」といった具合です。これを逐語訳すると、その軽快さは日本のB2Bの文脈では軽率な印象を与えることがあり、同じ場面には、ユーザーの時間を尊重した明確で丁寧な指示のほうがふさわしいのです。
ウェルカム画面とコーチマークには、特有のローカライゼーションの罠があります。新規ユーザーにインターフェースを案内するツールチップやハイライト表示のことです。罠は長さにあります。英語のコーチマークの文は、会話的で少し冗長なことがよくあります。それを逐語訳すると、ツールチップを埋め尽くし、ユーザーの手を止める長く堅い日本語になります。よくローカライズされた日本語のマイクロコピーは、英語の逐語訳より短く直接的になるのが普通です。仕事は次の操作をすっきり伝えることであって、英語の文を再現することではありません。ステップ数も見直す価値があります。英語では遊び心に感じられる5ステップのコーチマークツアーも、各ステップが丁寧でフォーマルな日本語の文で、しかもユーザーがいちいち閉じなければならないとなると、障害物のように感じられかねません。
最後に進捗インジケーターです。曖昧なスピナーではなく「ステップ 2 / 4」のように、明確で正直な進捗を示す初回起動は、いまプロセスのどこにいるのかを知りたいという日本のユーザーの好みに合います。日本のチェックフローがすべてのステップを示すのと同じ感覚が、オンボーディングにも当てはまります。終わりが見えれば、人は最後までやり遂げます。
トーンと文体：静かで一貫した一つの語り口
ローカライズされたオンボーディングで最もよくある文体の失敗は、不統一です。ウェルカムモーダルは丁寧な「ですます」の敬語で書かれている。数クリック先のツールチップは、別の翻訳者やAIが担当したために、カジュアルな常体に滑り込んでいる。エラーメッセージはぶっきらぼうな命令形。個別には許容できるかもしれませんが、数分のあいだに続けて出会うと、揺れ動く文体は雑に見えます。最初のセッションの語り口を、誰も責任を持って決めていなかったかのように。
解決方法は、初回起動全体で一つの文体（通常は丁寧な「ですます」）を決め、ウェルカム文、空の状態、コーチマーク、ボタン、エラーを通してそれを守ることです。これは、へりくだった言い方や尊敬語を盛り込むという意味ではありません。過度にフォーマルなオンボーディング文は、過度にカジュアルな文が信頼を損なうのと同じくらい、ユーザーの手を止めます。目指すのは、邪魔をせず、ユーザーに敬意を払う、静かで丁寧な一貫した語り口です。その語り口を一度決めて、フロー全体をそれに照らしてQAするほうが、どれか一つの文字列を磨き上げるより価値があります。
初回起動を、ローカライズすべき項目に対応づける
オンボーディングには多くのロケール前提が短い時間に詰まっています。初回起動の各場面を、そこで必要になるローカライゼーション作業に対応づけると整理しやすくなります。下の表は、よくある失敗がどこに潜んでいるか、ローカライズされた最初のセッションが代わりに何をすべきかを示す実務モデルです。
| 初回起動の場面 | ローカライズされていないフローがすること | ローカライズされた最初のセッションがすること |
|---|---|---|
| ウェルカム／登録 | 氏名欄1つ、住所は自由入力 | 姓/名＋ふりがな欄、〒郵便番号オートフィル |
| 空の状態 | 軽快な英語トーンを逐語訳 | 明確で丁寧な次ステップ指示 |
| コーチマーク／ツールチップ | 長く堅い逐語訳の文 | 短く直接的な日本語の微文 |
| サンプル／デモデータ | John Smith、$1,200.00、06/25/2026 | 山田 太郎、¥1,200、2026年6月25日 |
| フォーム入力処理 | 全角の数字をはじく | 全角/半角を許容し正規化 |
| 進捗インジケーター | 曖昧なスピナー、または表示なし | 正直なステップ表示（ステップ 2 / 4） |
| ガイダンスの文体 | 丁寧／カジュアル／命令形が混在 | 一貫した一つの「ですます」の語り口 |
これらの場面で日本語のテキスト入力を正しく扱えるかどうかは、IMEと入力挙動をきちんと押さえられるかにかかっています。ユーザーの入力方式と戦うフォームは、他のすべての作業を台無しにします。
公開前の日本語オンボーディング・チェックリスト
日本語の初回起動エクスペリエンスを準備完了と判断する前に、日本のユーザーと同じように、実際のアカウントを実際のデバイスで作りながら一通り歩いて、このチェックにかけてください。ここに挙げた多くは、スプレッドシートで文字列をレビューするだけでは捕まりません。
デモデータを日本語サンプルデータに置き換える
氏名は姓→名の順、住所は〒NNN-NNNNの郵便番号で大きい単位から小さい単位へ、日付は「2026年6月25日」、金額は整数の円。説明用の人物や企業は明確に架空と分かるようにする。
氏名欄を分割し、ふりがなを追加する
「氏名」欄を1つにするのではなく、日本のシステムが期待する箇所に姓・名の欄とふりがな（読み）欄を用意する。
郵便番号による住所オートフィルを実装する
ユーザーが先に7桁の郵便番号を入力し、都道府県・市区町村を自動入力できるようにする。住所をすべて手入力させると、日本のユーザーには壊れたフォームに見える。
全角・半角の入力を受け入れる
全角／半角の違いだけで有効な入力をはじかず、正規化して受け付ける。電話・郵便番号・数値の欄では特にそうする。
コーチマークを短い日本語のマイクロコピーに書き直す
英語のツールチップを逐語訳しない。次の操作をすっきり簡潔に伝え、ツアーの各ステップが本当に必要か見直す。
空の状態のトーンを直す
軽いノリのまま逐語訳された文を、明確で丁寧な指示に置き換える。次に何をすべきかを伝え、何も壊れていないと安心してもらえるようにする。
正直な進捗を示す
曖昧なスピナーではなく、明確なステップ表示（ステップ 2 / 4）を使う。終わりが見えるフローなら、日本のユーザーは最後までやり遂げる。
文体を一つにそろえて徹底する
初回起動全体で使う「ですます」の語り口を一つ決め、ウェルカム文・ツールチップ・ボタン・エラーをそれに照らして確認する。カジュアルな言い方やぶっきらぼうな命令形を例外として混ぜない。
ネイティブの日本語レビュアーに、実際のユーザーとして初回起動を完了してもらう
文字列のエクスポートではなく、動くフローを渡す。アカウントを作成して最初の価値にたどり着いてもらい、外国製らしさ・引っかかり・文体のずれを感じた瞬間をすべて記録する。
なぜ初回起動のローカライズは早く回収できるのか
オンボーディングの効果が大きいのは、下流のすべてがそこに依存しているからです。最初のセッションで離脱したユーザーは、その先のローカライゼーションが扱う機能には決してたどり着けず、有料顧客にもならず、同僚を紹介することもありません。初回起動を直す作業は、そのうえ範囲が異例なほど限られています。有限の画面、いくつかのフォーム、決まった範囲のガイダンス文、そしてサンプルデータ一式です。広大な製品領域と違って、初回起動エクスペリエンスは集中して端から端まで検証できます。
修正の多くは、日本のユーザーがもともと最初のセッションに期待している挙動に合わせるだけです。日本語のサンプルデータ、氏名とふりがなの欄、郵便番号オートフィル、文字幅の許容、正しい日付・通貨形式、そして一つの静かな文体。どれも主張やデータを捏造する必要はなく、確立された日本の慣習を反映したものです。その見返りは、最も重要な場所で測れます。最初の5分で静かにタブを閉じるユーザーが減り、製品が手放せないものになる瞬間に到達するユーザーが増えるのです。
海外SaaS本社のローカライゼーションPMにとって、これはまさに集中的な日本語ローカライゼーション監査が想定している領域です。範囲は限られ、継続率への影響は桁違い、しかも修正の対象は辞書ではなく、ユーザーの最初の5分です。
サインアップの「利用規約に同意」画面を、民法の定型約款の条文で見直す
初回起動の途中には、たいてい「利用規約に同意して始める」というボタンがあります。海外本社のフローをそのまま訳すと、英語版で使っていた「ボタンを押せば同意したことになる（browsewrap に近い）」置き方や、規約本文へのリンクが英語ページのままといった状態が残りがちです。日本では、不特定多数の利用者と画一的な条件で結ぶ取引の規約は、2020年4月施行の改正民法で「定型約款」（民法548条の2〜548条の4）として扱われています。日本側の担当者が画面を社内でレビューするときは、訳文の自然さとは別に、この3か条の文言と画面の要素を1対1で照らし合わせておくと、法務への相談が具体的になります。
下の表は、e-Gov法令検索に掲載されている条文の要点と、オンボーディング画面で確認できる項目を対応させたものです。条文の要約は筆者によるもので、原文は各条を直接ご確認ください。
| 条文（民法） | 条文が定めていること（要点） | 初回起動画面で確認すること |
|---|---|---|
| 548条の2 第1項 | 定型約款を契約の内容とする旨の合意をしたとき、または準備者があらかじめその旨を相手方に「表示していた」とき、個別の条項にも合意したものとみなす | ボタンの近くに「本規約を契約の内容とします」と読める一文があるか。規約へのリンクが同じ画面にあり、日本語の規約に着地するか |
| 548条の2 第2項 | 相手方の権利を制限し、または義務を加重する条項で、信義則（民法1条2項）に反して相手方の利益を一方的に害すると認められるものは、合意しなかったものとみなす | 自動更新、解約の制限、データ削除、免責などの条項が、訳文で原文より重く読める表現になっていないか |
| 548条の3 第1項・第2項 | 合意の前、または合意後相当の期間内に請求があれば、遅滞なく相当な方法で内容を示す。合意の前に請求を拒んだ場合は、548条の2を適用しない（一時的な通信障害その他正当な事由がある場合を除く） | サインアップ前の未ログイン状態でも規約全文を開けるか。問い合わせ窓口に「規約を見せてほしい」と来たときの回答手順があるか |
| 548条の4 第1項〜第3項 | 相手方の一般の利益に適合する変更、または合理的な変更であれば、個別の合意なしに変更できる。その際は効力発生時期を定め、変更する旨・変更後の内容・効力発生時期をインターネットの利用その他の適切な方法で周知する。第1項第2号による変更は、効力発生時期までに周知しないと効力を生じない | 規約改定のお知らせ（アプリ内バナー・メール）の日本語テンプレートに「変更する旨」「変更後の規約へのリンク」「効力発生日」の3点が入っているか |
消費者向けのサービスでは、消費者契約法10条も並べて見ておくと安心です。同条は、消費者の不作為をもって新たな申込みや承諾をしたとみなす条項などを例に挙げ、法令の任意規定に比べて消費者の権利を制限し、または義務を加重する条項で、信義則に反して消費者の利益を一方的に害するものを無効としています。「何もしなければ有料プランに移行したものとみなす」といった初回特典の文言は、英語原文を訳す段階で一度立ち止まる対象になります。
社内レビューで使う確認手順
- サインアップ画面のスクリーンショットを撮り、同意ボタン・チェックボックス・規約リンク・周辺の説明文を番号付きで書き出す。
- 規約リンクを未ログインの状態で開き、日本語の規約全文が表示されるか、英語版や404に着地しないかを確かめる（548条の3の「内容の表示」との対応）。
- 同意の一文が「本規約を契約の内容とすること」に同意する形で読めるかを確認する。チェックボックスの初期値（オン／オフ）も記録しておく。
- 英語原文と訳文で、自動更新・解約・免責・データの扱いの条項を並べ、訳文の方が利用者に不利に読める箇所がないかを拾う。
- 規約改定のお知らせテンプレートに、変更する旨・変更後の規約へのリンク・効力発生日の3点がそろっているかを確認する（548条の4第2項との対応）。
この手順は、画面と条文の対応を整理して法務担当に渡すためのものです。ある画面が「表示」の要件を満たすか、ある条項が548条の2第2項や消費者契約法10条に当たるかは、事業内容や取引の実情によって判断が分かれるとされています。個別の判断は弁護士などの専門家にご確認ください。出典：民法（e-Gov法令検索）、消費者契約法（e-Gov法令検索）。
よくある質問
翻訳しただけのオンボーディングで、なぜ日本のユーザーは離脱するのですか？
最初のセッションが、日本では成り立たない前提の上に作られているからです。翻訳しただけのウェルカム画面は、英語の文章量・トーン・テンポをそのまま残し、欧米の氏名・MM/DD/YYYY形式の日付・ドル金額を含むサンプルデータを使い、姓名が1つの氏名欄・住所が自由入力のフォームを提示します。日本のユーザーにとって、こうした小さなズレの一つひとつが「この製品は自分たちのために作られていない」という合図になります。オンボーディングは、ユーザーがマーケティングページを読むのではなく実際に何かを操作する最初の場面です。だからこそ、信頼が最も早く得られ、また最も早く失われます。初回起動エクスペリエンス——氏名、住所、日付、通貨、フォームの期待値、ガイダンス文の敬語の度合い——をローカライズすれば、黙ってタブを閉じられて終わる事態を防げます。
オンボーディングの日本語サンプルデータ／デモデータはどうあるべきですか？
翻訳されたアメリカのアカウントではなく、本物の日本のアカウントのように見えるべきです。氏名は姓→名の順（例：山田 太郎）、住所は7桁の郵便番号（〒NNN-NNNN）から始めて大きい単位から小さい単位へ書き、日付は「2026年6月25日」形式、金額は小数のない円の整数（¥1,500 または 1,500円）にします。John Smith、123 Main St、$1,200.00、06/25/2026 が並んだデモダッシュボードは、その製品が日本で本格的に使われたことがないと日本の評価担当者に伝えてしまいます。サンプルデータが最初のセッションで丁寧に読まれるのは、ユーザーが自分の本物のデータをその製品に預けてよいか判断しているからです。
オンボーディングのフォームは、日本の氏名や住所をどう扱うべきですか？
日本のフォームは氏名を「姓」と「名」に分けることが一般的で、さらに読み方を取得して正しく並べ替えられるよう、ふりがな欄を添えることがよくあります。住所は7桁の郵便番号から入力し、そこから都道府県・市区町村が自動入力されることをユーザーは期待します。郵便番号でほとんど補完できるのに住所をすべて手入力させると、壊れたフォームのように受け取られます。また、全角・半角の不一致で入力をはじくのではなく、両方を受け入れて正規化する寛容さも必要です。これらは日本では例外的なケースではなく、ごく当たり前の期待です。初回起動のフォームがこれらを無視すると、ユーザーが最も離脱しやすいまさにその瞬間に、引っかかりが生まれます。
オンボーディングのガイダンス文は、日本語でどんなトーンを使うべきですか？
オンボーディング文は、丁寧で一貫した敬語——通常は「ですます」体——を使い、ユーザーの操作を遅らせるほど堅苦しかったり、へりくだりすぎたりしない範囲にとどめるべきです。よくある失敗は不統一です。ウェルカムモーダルはフォーマルな日本語、数クリック先のツールチップはカジュアルな常体、エラーはぶっきらぼうな命令形、というように。この不統一は雑な印象を与えます。また、英語のコーチマークを逐語訳した、長すぎて堅い文も避けるべきです。日本語の操作微文（マイクロコピー）は、適切にローカライズすれば英語ソースより短く直接的になるのが普通です。目指すのは、最初のセッション全体を通して、落ち着いた丁寧な語り口を一つに保つことです。
オンボーディングのローカライゼーションは、製品の他の部分の翻訳と違うのですか？
違います。オンボーディングは短時間に凝縮され、時間に追われ、操作が中心になるからです。製品の他の部分は数週間かけて使い込まれますが、初回起動は数分で終わり、そもそも2回目のセッションがあるかどうかを左右します。さらに、氏名・住所欄、サンプルデータ、日付、通貨、空の状態、進捗インジケーターといったロケールの前提が一度にすべて表に出ます。設定ページがよく翻訳されていても、ウェルカム画面が欧米のデータ構造を前提にしていたために、オンボーディングでユーザーを失う製品はあります。初回起動エクスペリエンスを独立したローカライゼーション対象として扱い、日本のユーザーが実際に辿る通りに端から端まで検証すれば、最初のセッションでの離脱を減らせます。