日本のB2Bユーザーがそのプロダクトを使い続けるかどうかは、オンボーディングで決まります。ところがオンボーディングは、急いでローカライズしたまま見直されずに残りやすい部分でもあります。信頼を損なう問題がいちばん多く見つかるのも、そのためです。
当社のQA業務では、AI翻訳された日本語のオンボーディングフローを30分間集中して診断すると、ほぼ毎回同じ7つの問題が出てきます。偶然の一致ではありません。いずれも、オンボーディング体験としてのQAをせずに文字列だけを翻訳した場合に起こる、予測可能な結果です。
以下がそのチェックリストです。自社のオンボーディングフローをこれに照らし合わせれば、約30分で確認できます。
問題1 — 書かれたのではなく「翻訳された」ウェルカム画面
ウェルカム画面で第一印象が決まります。英語の明るいコピーをそのまま訳すと、日本のB2Bの場面では馴れ馴れしく聞こえてしまいます。日本のエンタープライズユーザーがここで見ているのは熱量ではありません。「きちんと作られた信頼できるツールだ」と思えるかどうかです。
温かみをなくせという話ではありません。日本のB2Bユーザーが好意的に受け取るのは、感嘆符で盛り上げる温かみではなく、落ち着いた言葉から伝わる有能さと分かりやすさです。そちらを選ぶということです。
問題2 — 間違った丁寧さレベルのサインアップフォームラベル
フォームラベルは短いので、真っ先に訳され、ほとんどレビューされません。しかしサインアップフォームは、ユーザーが個人情報を預ける場面です。ここで表記が揺れていると、よりによってこのタイミングで「雑さ」を感じさせてしまいます。
簡単に確認する方法があります。サインアップフロー内のすべてのフィールドラベルとボタンが、同じ語尾パターンになっているかどうかを見ることです。1つでもカジュアルな表現があれば目立ちます。そしてサインアップフォームは、悪目立ちして一番困る場所です。
問題3 — カジュアルすぎるプライマリCTA
オンボーディングのCTAは、プロダクトのトーンに合った文体で、次に何が起きるのかを正確に伝えなければなりません。曖昧でカジュアルなCTAだと、ユーザーに先へ進んでほしいまさにその場面で、手が止まってしまいます。
鍵は「次に何が起きるか」です。「設定を始める」「アカウントを作成する」のように結果をはっきり示すCTAなら、ユーザーにはクリックする具体的な理由ができます。曖昧なCTAは、とりあえず一歩踏み出すようユーザーに求めることになります。そして日本のB2Bユーザーは、その一歩を踏み出しません。
問題4 — 英語のままのエンプティステート
「No projects yet」「Nothing here」「Get started by adding your first item」といったエンプティステートの文字列は、コードベースの別の場所から読み込まれるため、翻訳作業からごっそり漏れがちです。日本語ユーザーが最初のダッシュボードを開いて英語を目にした瞬間、ローカライゼーションが中途半端だとはっきり伝わってしまいます。
これは翻訳ではなくプロセスの問題です。エンプティステートの文字列も、主要なUIコピーと同じローカライゼーションチェックリストに入れてください。後回しは禁物です。量が少なく見落としやすいからこそ、はっきりリストに載せておく必要があります。
問題5 — 直訳で不安を与えるバリデーションエラー
バリデーションエラーは、ユーザーが作業している途中で出てきます。サインアップの最中に直訳の荒っぽいエラーメッセージが出ると、ユーザーはプロダクトに責められているように感じます。良いメッセージは、どのフィールドかを示し、何を直せばよいかを伝え、穏やかな口調を崩しません。
日本語のバリデーションコピーの原則は、良いエラーメッセージ一般と変わりませんが、求められる水準はさらに高くなります。具体的に、穏やかに、そしてユーザーが何か悪いことをしたとは決してほのめかさないこと。サインアップ中に責められたと感じたユーザーは、途中でやめてしまうことが多いのです。QAレビューで一文を書き直しただけで改善したケースを、私たちは何度も見てきました。
問題6 — かえって混乱させるツールチップとヘルパーテキスト
ヘルパーテキストを直訳すると、説明している中身より日本語のほうが長く回りくどくなりがちです。オンボーディング中のユーザーはすでに多くの情報を受け取っているので、分かりにくいツールチップは無いほうがましです。原文に忠実に訳すより、分かりやすさを優先して書き直してください。
簡単な試し方があります。ツールチップを日本語で声に出して読んでみてください。その機能を実際に試すより時間がかかるようなら、そのツールチップはオンボーディングを助けるどころか邪魔をしています。短くするか、なくしてしまいましょう。
問題7 — ロボットのような成功メッセージ
オンボーディングの成功メッセージは、ユーザーに勢いをつける場面です。平板で機械的な確認文では、その機会を無駄にしてしまいます。きちんとローカライズされたメッセージなら、達成を伝えたうえで、ユーザーを次のアクションへ自然に導けます。
成功メッセージは、どれも次のアクションへの布石だと考えてください。何かを達成した直後のユーザーは、もう一つやってみようという意欲がいちばん高まっています。「完了」とだけ伝えるメッセージでは、その瞬間を逃してしまいます。
共通のパターン： 7つの問題はいずれも、日本語ユーザーとしてオンボーディングフローを歩かずに文字列を翻訳したことから生まれています。自社フローを日本語で5分クリックするだけで、そのほとんどが見えてきます。
30分でできる自己診断の進め方
日本語のオンボーディングフローを開き、新規ユーザーが歩むように進んでください。サインアップ、ウェルカム画面、最初のエンプティステート、最初のアクション、最初のエラー、最初の成功——各ステップで3つの問いを立てます。この文体はB2Bツールとして合っているか？まだ英語のままの箇所はないか？このコピーは前進を後押しするか、それとも躊躇させるか？気になった瞬間をすべてメモしてください。おそらく、上記7つのほとんどが見つかるはずです。
自己診断の精度を高める2つのポイントがあります。まず、実際のデバイスで実際のサイズで行うこと——文字の切れやレイアウト崩れは実際のUIにしか現れません。次に、そのプロダクトを初めて見るつもりでコールドに行うこと——オンボーディングを損なう問題は第一印象の問題だからです。さらに効果的なのは、日本語ネイティブの同僚に試してもらうことです。躊躇した瞬間が、そのまま発見になります。
日本側の担当者向け：サインアップ画面を条文と規格に照らす4項目
上の7項目は「読んでどう感じるか」の診断です。日本法人や国内の導入担当者が社内で修正を通すときは、それに加えて「どの条文・どの規格に照らして直すのか」を示せると話が早くなります。オンボーディングの中で個人情報を最初に受け取るサインアップ画面について、一次資料と突き合わせる項目を4つにまとめました。
1. 送信ボタンの手前で利用目的が読めるか（個人情報保護法 第21条第2項）
フォームで本人から直接個人情報を受け取る場合、第21条第2項は「あらかじめ、本人に対し、その利用目的を明示しなければならない」と定めています（e-Gov法令検索）。条文の「書面」には電磁的記録が含まれます。個人情報保護委員会のガイドライン（通則編）3-3-4は、自社のホームページ上での明示を例に挙げたうえで、送信ボタン等をクリックする前に利用目的が本人の目に留まる配置が望ましいとしています（個人情報保護委員会）。
海外SaaSの日本語版でよく見るのは、英語版の「By signing up, you agree to our Privacy Policy」を訳した一文だけがあり、リンク先のプライバシーポリシーが英語のまま、という状態です。診断では、日本語の画面だけを見て送信前に利用目的までたどり着けるかを確認します。リンク表示で足りるかどうかは個別の判断になるため、迷う場合は専門家に確認してください。
2. 利用目的の訳が原文より粗くなっていないか（同法 第17条第1項）
第17条第1項は、利用目的を「できる限り特定しなければならない」としています。翻訳の段階で、英語原文にある利用目的の列挙が「サービス向上のため」などの一語にまとめられてしまうことがあります。英語版と日本語版のポリシーを項目ごとに並べ、日本語版で抜けた目的がないかを照合します。
3. 入力欄にラベルがあるか（JIS X 8341-3:2016 達成基準3.3.2・レベルA）
JIS X 8341-3:2016は国際規格ISO/IEC 40500:2012の一致規格で、本文はWCAG 2.0と同じ内容です（ウェブアクセシビリティ基盤委員会）。達成基準3.3.2「ラベル又は説明」は、入力を求める箇所にラベルか説明を付けることを求めています（W3C WCAG 2.0）。入力すると消えるプレースホルダーだけで項目名を示しているフォームは、この基準に照らして確認が必要です。
4. エラー文が項目と直し方を示しているか（達成基準3.3.1・レベルA／3.3.3・レベルAA）
3.3.1「エラーの特定」は、自動で検出した入力エラーについて、どの項目が誤りかを特定し、エラー内容をテキストで伝えることを求めています。3.3.3「エラー修正の提案」は、修正方法が分かっている場合にそれを提示することを求めています。問題5で挙げた「無効な入力です」は項目名も直し方も含まないため、言葉づかいの問題であると同時に、この2つの基準に照らしても直す理由が立ちます。
社内説明の背景として、改正障害者差別解消法が令和6年4月1日に施行され、事業者にも合理的配慮の提供が義務化されたことも押さえておくとよいでしょう（内閣府）。ただし、これはウェブサイトのJIS準拠そのものを義務づけるものではありません。修正の優先度を説明する材料の一つとして扱うのが適切です。
- 診断メモの各指摘に「第21条第2項」「3.3.1」のように根拠の番号を添えておくと、稟議や開発チケットにそのまま転記できます。
- 法令に関わる指摘（1・2）は法務部門へ、規格に関わる指摘（3・4）は開発・デザイン部門へ、と回付先を分けておくと手戻りが減ります。
次のステップ
自己診断で問題の場所はわかります。日本語ウェブサイトミニ診断では、その修正方法まで明確にします。Before/Afterの修正例、品質スコア、オンボーディングフロー向けの優先度付きアクションリストを、3〜5営業日以内にお届けします。