要点まとめ（TL;DR）
多くの海外SaaSのヘルプセンターは、単語単位で機械翻訳されたまま放置されています。日本語でこれをやると、手順の文体がちぐはぐになり、日本人ユーザーが実際に入力するキーワードでは記事がヒットせず、英語UIのスクリーンショットもそのまま残ります。ユーザーはそうした記事を読み飛ばし、サポートにメールを送ります。その結果、チケット数が膨らみ、製品の問題が見えにくくなり、エンタープライズの購買担当者には「日本語版は放置されている」という印象を与えてしまいます。
この記事のポイント
- 検索キーワードのミスマッチは、気づかれにくい落とし穴です — 日本人ユーザーは「解約」と検索するのに、記事が「サブスクリプションのキャンセル」という表現を使っていれば、その記事は永遠にヒットしません。
- 手順の文体は内容よりも重要です — 「Click Save」を間違った丁寧さのレベルで訳すと、上から目線にも、またはぶっきらぼうにも聞こえます。
- スクリーンショットは日本語UIを映す必要があります — 日本語記事に英語のスクリーンショットが載っていると、ユーザーはその記事が古いか間違っていると受け取ります。
- FAQの言い回しは日本人ユーザーが実際に質問する形に合わせる必要があります — 翻訳された質問は社内用語のように聞こえます。自然な日本語に書き直すと、実際のサポート問い合わせに合致します。
- 「お問い合わせ」CTAの配置には文化的な重みがあります — 日本人ユーザーはエスカレーションを後回しにしがちです。ヘルプセンター内のサポートCTAの文言次第で、チケット数が変わります。
なぜ製品が成功してもヘルプセンターは失敗するのか
海外SaaS企業のローカライゼーションPMがこの問題に気づくのは、たいてい2つのパターンです。ユーザー数で補正しても、日本のサポートボリュームが他市場より異様に多い、あるいは日本のエンタープライズ候補企業が評価フェーズで、日本語ドキュメントが「薄い」と遠回しに指摘してきたのち商談が冷める——どちらも同じ根本原因を指しています。ヘルプセンターは翻訳されたが、ローカライズされていないのです。
プロダクトUIはすべてのステークホルダーの目に触れるので注目されます。マーケティングページはファネル上流のコンバージョンを左右するので注目されます。ヘルプセンターはこの2つの中間にあり、何かが壊れるまで誰も気にかけません。管理しているのがサポート組織なので、ローカライゼーション投資の優先順位はどうしても低くなります。文字列は機械翻訳か汎用の翻訳会社に回され、記事は公開され、チケット数が増えて初めて見直されます。
このパターンは、私が日本でレビューする海外SaaS製品に共通して見られます。ヘルプセンターは製品の中で最も日本語の品質が低くなりがちですが、日本人ユーザーが最も頼りにする場所でもあります。日本のB2Bユーザーはセルフサービスを好み、チケットを開く前にドキュメントを丁寧に読みます。そのドキュメントが役に立たなければ、サポートにエスカレーションする（コストがかかります）か、黙って製品を使わなくなります（これは表に出てきません）。
優れた記事を隠してしまう検索キーワードのミスマッチ
日本語ヘルプセンターでは、検索バーがほとんどの役割を担います。日本人ユーザーは、英語圏のユーザーのようにカテゴリーツリーをたどることはほとんどありません。クエリを入力し、一度で正しい記事が出てくることを期待します。クエリと記事タイトルが同じ概念を別の言葉で表していると、記事はヒットせず、ユーザーはセルフサービスをあきらめます。
このミスマッチは構造的な問題です。ヘルプセンターの記事はたいてい、会社が標準化した正式なプロダクト用語を使った英語の原文タイトルから翻訳されます。一方、日本人ユーザーは、その操作を思い浮かべたときの日常的な日本語で検索します。どちらの言葉も間違いではありません。しかし、ユーザーが実際に入力するのは片方だけです。
この問題を解決するには、記事一覧と日本語サイト内検索のログを突き合わせます。検索ボリュームが大きいのにクリックされていないクエリが、そのままキーワードのずれを示しています。私たちのQA業務では、上位20記事のタイトルを実際の検索意図に合わせて書き直すだけで、他のどの施策よりもヘルプセンターの問い合わせの抑制率が改善することが多いです。
手順説明の文体問題
日本語ヘルプセンター記事の本文も、英語版と同じく番号付きのステップで構成されます。違うのは動詞の語尾です。英語の手順は、感情的なニュアンスを挟まずに命令形を使います。「Click Save」「Enter your email」「Select the option」。日本語には中立的な命令形がありません。指示のたびに文体を選ぶことになります：丁寧な依頼形（してください）、誘導形（しましょう）、辞書形（する）、敬語（なさってください）。
翻訳された日本語ヘルプセンターでは、ほぼすべてのステップが既定で丁寧な命令形「してください」になります。文法的には正しいのですが、ユーザーに「どうかお願いします」と繰り返し言い続けているような、少し不安そうなアシスタントが書いたようなドキュメントになってしまいます。10ステップも続くと、だんだん上から目線に感じられます。50記事が集まると、ヘルプセンター全体が機械翻訳っぽく読めてしまいます。
国内市場向けに作られた日本語SaaSドキュメントの慣習は、もっとシンプルです。標準的なのは、周りの説明には丁寧語（ます形、断定形）を使い、ステップ自体は短い動作動詞で書くパターンです。多くの場合、名詞句か辞書形になります。ユーザーはそのステップを、製品からのお願いとしてではなく、指示として読みます。
2. メニューを開いてください。
3. 「設定」をクリックしてください。
2. メニューを開きます。
3. 「設定」をクリックします。
実践ルール：手順の文体を1つに決めて日本語ヘルプセンターのスタイルガイドに記録し、すべての記事で統一しましょう。プロフェッショナルな既定として最も一般的なのは、手順にも説明の段落にもます形断定形を使うことです。
スクリーンショットのaltテキストと画像のローカライゼーション
日本語ヘルプセンター記事のスクリーンショットには、英語記事にはない2つの問題があります。まず、スクリーンショットが英語UIのものなら、日本語で読んでいる読者には英語がそのまま見えます。これは、記事が古いか、プロダクトUIがまだ日本語化されていないかのどちらかを示しています。どちらだと思われても、信頼を損ないます。次に、画像に付けたaltテキストが英語のままになっていることが多く、日本人のスクリーンリーダーユーザーのアクセシビリティを損ない、日本語クエリのSEOも落とします。
修正そのものは機械的な作業ですが、後回しにされがちです。日本語ヘルプセンター記事のスクリーンショットは、どれも日本語UIのビルドで撮り直す必要があります。altテキストは日本語で書き、日本人ユーザーが分かる言葉でスクリーンショットの内容を説明します。キャプションがある場合も日本語にします。慣習として、altテキストは文としてではなく、画像の内容を説明する名詞句として書きます。
海外SaaSのヘルプセンターでよく見かけるのは、本文では日本語のボタンラベルに触れているのに（「『保存』をクリック」）、スクリーンショットには英語の「Save」ボタンが写っているというパターンです。小さな食い違いですが繰り返し起きるため、日本人読者はドキュメントを信頼できる情報源と見なさなくなります。よくある典型的な矛盾です。
FAQ：日本人ユーザーが実際に質問する言い回し
FAQページはヘルプセンターで最もよく検索されるセクションであり、最もローカライズが進んでいないセクションでもあります。質問はたいてい英語原文の直訳で作られますが、それでは日本人ユーザーが検索バーに入力するような日本語の質問文にはなりません。結果は記事タイトルと同じキーワードのずれです。答えはあるのに、その答えを引き出す質問がユーザーの実際の聞き方と合っていないのです。
日本のB2Bユーザーは、英語話者よりも遠回しで、状況に応じた言い方で質問します。「How do I cancel my subscription?」の自然な日本語は「解約したい場合はどうすればよいですか？」、あるいは単に「解約方法は？」に近いものです。「Can I export my data?」なら、日本人ユーザーは「データをエクスポートできますか？」や「データの書き出しは可能ですか？」と聞くことが多くなります。翻訳は、そのまま訳すのではなく書き直す必要があります。
| 英語のFAQ質問 | 直訳（不自然） | 自然な日本語表現 |
|---|---|---|
| How do I cancel my subscription? | サブスクリプションをキャンセルする方法は？ | 解約したい場合はどうすればよいですか？ |
| Can I get a refund? | 払い戻しを受け取ることはできますか？ | 返金は可能ですか？ |
| What payment methods do you accept? | どのような支払い方法を受け付けていますか？ | 利用できるお支払い方法は？ |
| Is my data secure? | 私のデータは安全ですか？ | データのセキュリティ対策について教えてください |
| Can I change my plan? | プランを変更できますか？ | プラン変更の方法は？ |
ナビゲーション・カテゴリーラベルと「お問い合わせ」CTA
ヘルプセンターのカテゴリー名、トップレベルナビゲーション、サポートCTAといった構造要素は、たいてい翻訳の順番が最後になり、レビューもほとんどされません。しかし、ページ上で最も目立つ要素でもあります。ヘルプセンターのトップページにたどり着いた日本人ユーザーは、まずカテゴリーラベルを読み、そのドキュメントが役に立つかどうかの印象がそこで決まります。
直訳されたカテゴリーラベルは、ユーザー向けの表現というより、社内のプロダクト用語のように聞こえることが多いです。「Getting Started」を「始めましょう」と訳すとマーケティングスローガンのように聞こえますが、日本語のヘルプセンターでは「はじめに」または「ご利用ガイド」が慣例です。「Billing & Plans」を「請求とプラン」と訳すと技術的すぎます。日本語SaaSの競合がこのセクションに付けるラベルは「料金・お支払い」です。これらの違いは個別には小さいものの、積み重なると大きな差になります。
「Contact Support」CTAには特に重みがあります。日本人ユーザーは、多くの市場のユーザーよりも問い合わせるまでに時間がかかり、渋々ながらサポートに上げる傾向があるからです。まずセルフサービスの選択肢を出し尽くそうとし、クリックする前にCTAの文言を注意深く読みます。「サポートに連絡する」というボタンは事務的に響きます。「お問い合わせ」はプロフェッショナルで親しみやすく響きます。文言が違うだけでクリックする気になるかどうかが変わり、チケット数や、会社のサポート姿勢に対する印象にも影響します。
「Billing & Plans」→ 請求とプラン
「Contact Support」→ サポートに連絡する
料金・お支払い
お問い合わせ
日本語ヘルプセンター公開前チェックリスト
日本語ヘルプセンターを公開と見なす前に、ローカライズしたビルドをこの監査で確認してください。ここに挙げたチェックのほとんどは、翻訳のスプレッドシートを見ているだけでは実施できません。日本語UIと並べて表示したヘルプセンターを、実際に目で見る必要があります。
記事タイトルを実際の日本語検索クエリと照合する
日本語のサイト内検索ログ（なければ最も近い英語の同等データ）を取り出し、上位20クエリそれぞれに、同じキーワードをタイトルに含む記事が対応しているかを確認します。クエリとタイトルの言葉がずれている箇所は、タイトルを書き直してください。
記事全体でステップバイステップの文体を統一する
1つの文体を選び（最もよく使われるのはます形断定形）、番号付き手順全体に一貫して適用します。機械翻訳由来の「してください」パターンが残っていないか記事を監査してください。
すべてのスクリーンショットを日本語UIから再キャプチャする
日本語記事の中に英語UIのスクリーンショットがあると、読者の信頼はあっという間に損なわれます。日本語ロケールのステージングビルドからキャプチャし直し、altテキストも日本語の名詞句に更新してください。
FAQ質問を日本人ユーザーの問い方に合わせて書き直す
翻訳されたFAQ質問は社内用語のように読めます。ユーザーが実際に入力するような自然な日本語表現で各質問を書き直してください——状況的で間接的な表現、多くの場合は「場合」や「方法」で終わるものです。
ナビゲーションとカテゴリーラベルを日本語SaaSの慣習に合わせる
トップレベルのカテゴリー名を、日本のSaaSヘルプセンター（Sansan、freee、サイボウズ、Money Forward）のラベルと比べます。いまのラベルが必要以上に独自色を出しているなら、国内の慣習に合わせてください。
「お問い合わせ」CTAとその周辺のコンテキストをローカライズする
CTAラベルには「お問い合わせ」を使用します。ボタンの上下に、ヘルプセンター全体で使用している文体で応答時間とチャネルを説明する短い日本語の文を追加してください——日本人ユーザーはエスカレーション前にこの種の事前情報を特に大切にします。
レンダリングされたページで日本語ネイティブレビューを実施する
レビュアーには文字列のエクスポートではなくURLを渡してください。ヘルプセンターのローカライゼーションの問題の多くは、記事がスクリーンショット、ナビゲーション、CTAと一緒に表示されたときにしか見えません。
日本語ヘルプセンターQAの四半期サイクルを設定する
プロダクトUIは変わり、新機能がリリースされ、記事は稼働中の日本語ビルドと少しずつずれていきます。四半期ごとに定期レビューを行えば、ユーザーの目に触れる前に大きなずれを見つけられます。
なぜヘルプセンターは見た目以上に効果が大きいのか
ヘルプセンターのローカライゼーションは、この領域がほとんどの関係者の目に触れないため、一貫して過小評価されています。製品デモにも登場しません。マーケティングのレビューにも出てきません。サポートが管理していて、翻訳QAの予算は普通ありません。それでいて、多くのSaaS製品が持つ日本語コンテンツのうち最大の塊でもあります。マーケティングサイト、プロダクトUI、法務ページを合わせたより多いこともあります。
この効果は良い方向にも悪い方向にも働きます。きちんとローカライズされた日本語ヘルプセンターは、サポートに流れる問い合わせを減らし、日本でのカスタマー対応コストを下げ、エンタープライズの購買担当者に「この会社は日本市場に本気で投資している」というメッセージを伝えます。逆に、ローカライゼーションがお粗末なヘルプセンターはサポートコストを膨らませ、製品の問題を問い合わせ件数の陰に隠し、日本人ユーザーの推薦意欲を静かに削いでいきます。
海外SaaS企業のローカライゼーションPMにとって、ヘルプセンターは最もROIの高い日本語ローカライゼーション診断の一つです。記事はすでに書かれており、構造はすでに整っており、修正は語彙・文体・スクリーンショットの鮮度に集中しています。上位20〜30記事に対して集中的な日本語QAパスを実施するだけで、たいてい1四半期以内に問い合わせ偏向率とチケット品質の目に見える改善が得られます——新しいコンテンツ投資のわずかな費用で。
チャットや分析タグを載せる前に：外部送信規律から見た日本語ヘルプセンター
日本語ヘルプセンターには、チャットウィジェット、アクセス解析タグ、動画の埋め込み、記事評価のフィードバックツールなど、利用者の端末から第三者のサーバーへ情報を送るプログラムが載りがちです。英語版では本社のプライバシー担当が見ている領域でも、日本向けには電気通信事業法の「外部送信規律」（法第27条の12、電気通信事業法施行規則第22条の2の27〜第22条の2の31）が関係する可能性があります。2022年の法改正で設けられた規律で、所管は総務省です。
規律に従う必要があるのは、電気通信事業者または第三号事業を営む者で、「利用者の利益に及ぼす影響が少なくない電気通信役務」を提供している事業者とされています（総務省「外部送信規律FAQ」問1-8）。自社が該当するかは事業の内容によって変わるため、個別の判断は法務部門や専門家に確認してください。以下は、該当すると整理された場合に、ヘルプセンターの担当者が日本語版で確かめておきたい点を、総務省の解説ページとFAQから拾ったものです。
ヘルプセンターは「サービス案内ページ」と扱いが違う
FAQ問1-18によると、サービスの案内ページは自己の需要によるもので電気通信事業に当たらず、規律の対象外です。一方、ユーザーサポートページやユーザー向けポータルは、元のサービスが規律の対象であれば同じく対象になるとされています。「マーケティングサイトは対象外と整理した」ことは、ヘルプセンターも対象外という意味にはなりません。また問1-7では、Cookieを使っていなくても、外部送信を指令するプログラムを端末に送っていれば対象になると説明されています。
通知・公表する3つの事項
| 事項 | 総務省の説明 | ヘルプセンターでの書き方の例 |
|---|---|---|
| 送信される利用者に関する情報の内容 | Cookieに保存されたIDや広告IDなどの識別符号、閲覧したページのURLなどの行動に関する情報、氏名などが含まれる（問4-1） | 「閲覧した記事のURL」「チャットに入力した内容」「端末を識別するID」のように、ツールごとに具体的に書く |
| その情報を取り扱う者の氏名または名称 | 氏名または名称の明記が求められる。サービス名の方が知られている場合もサービス名だけでは足りず、名称と併記する（問4-2） | 製品名だけの一覧にせず、「提供会社名（サービス名）」の形にする |
| その情報の利用目的 | 上の情報をどの目的で使うか | 「問い合わせへの回答のため」「記事を改善するための閲覧状況の分析のため」など、ツールの役割に合わせて書く |
日本語版で求められる書き方
- 日本語で書く。FAQ問3-3は、日本に住む外国人や旅行者を主な利用者とするサイトでも日本語での記載が必要で、英語など利用者が理解しやすい言語の併記が望ましいとしています。英語のプライバシーポリシーへリンクするだけの構成は、見直しの対象になります。
- 専門用語を使わず、平易な表現にする。判断の基準は、そのサービスで想定される一般的な利用者の知識や理解力です（問3-4）。「SDK」「ピクセル」「ファーストパーティCookie」を説明なしに並べない、という書き方の問題でもあります。
- 拡大・縮小の操作をしなくても、文字が適切な大きさで表示されるようにする。
- 公表の場合（ウェブサイト）は、外部送信のプログラムを送るページか、そのページから容易に到達できるページに3つの事項を表示する。ヘルプ記事の各ページから公表ページへの導線があるかを確認します。
- 通知の場合は、3つの事項か、それを載せた画面の場所（リンクなど）をポップアップなどで表示する。
なお、OS情報や言語設定、ユーザー認証やセキュリティ対策など電気通信役務の提供に真に必要な情報、サービス提供者自身が送った識別符号（First Party Cookieに保存されたIDなど）、所定の事項を公表したうえでオプトアウト措置を講じており利用者がその適用を求めていない情報などは、通知・公表が不要とされています。同意を取る方式でも、チェックボックスにあらかじめチェックを入れておくなど、利用者が能動的に同意したとはいえない方法は取らないよう求められています。
日本語ヘルプセンター公開前の外部送信チェック（5項目）
- 記事ページ、検索結果ページ、お問い合わせフォームをブラウザの開発者ツールで開き、第三者のドメインへの通信を一覧にする。チャット、解析、動画、検索、フィードバックの各ツールを漏れなく拾う。
- 送信先ごとに、情報の内容・取り扱う者の名称・利用目的の3つを日本語で埋める。名称の欄にはサービス名ではなく事業者の名称を書き、必要ならサービス名を併記する。
- 説明文から専門用語を外し、エンジニアではない社内の人に読んでもらう。FAQ問3-4は、ユーザーアンケートや外部の有識者の意見を踏まえることを判断方法の例に挙げています。
- 公表ページへの導線が、ヘルプセンターのすべてのページから迷わずたどれるかを確認する。
- 英語版で新しいツールを入れたときに日本語版の一覧が追いつかないことが多いため、送信先一覧の差分確認を四半期の再監査に組み込む。
出典：総務省「外部送信規律」解説ページ（soumu.go.jp）、総務省「外部送信規律FAQ」（soumu.go.jp）、総務省「法令・ガイドライン・パンフレット」（soumu.go.jp）。本節は一般的な情報の整理であり、法的助言ではありません。自社への適用の有無や具体的な記載内容は、専門家に確認してください。
よくある質問
日本語ヘルプセンターのローカライゼーションで最大の失敗は何ですか？
記事タイトルと、日本人ユーザーが実際に入力する言葉との間の検索キーワードのミスマッチです。英語の原文タイトルから翻訳された記事は正式なプロダクト用語を使いますが、日本人ユーザーは日常的な日本語で検索します（「サブスクリプションのキャンセル」ではなく「解約」、「パスワードリセット」ではなく「パスワード 忘れた」）。記事はあるのに検索でヒットせず、本来は不要なサポートへのエスカレーションが起きます。
ヘルプセンターの手順はプロダクトUIと同じ文体にするべきですか？
必ずしもそうではありません。プロダクトUIのボタンは短く収めるために名詞形や辞書形を使うことが多いのに対し、ヘルプセンターの手順はます形断定形（ログインします、クリックします）で書くのが最適です。用途が違えば慣習も違います。UI要素は操作にラベルを付け、ヘルプ記事は手順を説明します。それぞれの慣習を、ローカライゼーションのスタイルガイドに分けて記録してください。
日本語ヘルプセンター記事のスクリーンショットは本当に再キャプチャが必要ですか？
はい。これは最も見落とされやすい修正です。日本語記事に英語のスクリーンショットがあると、記事が古いか、日本語UIがドキュメントと食い違っているかのどちらかだと読者に伝わります。日本人の読者はこれを低品質のサインとしてすぐに受け止めます。日本語ロケールのステージングビルドからスクリーンショットを撮り直し、日本語のaltテキストを付ける作業は機械的ですが、品質の印象は大きく上がります。
日本語ヘルプセンターの「お問い合わせ」CTAはどうローカライズすればよいですか？
ボタンラベルには「お問い合わせ」を使ってください。日本のB2Bユーザーはクリックする前にこのCTAをよく読むので、文言次第でチケット数が変わります。「お問い合わせ」はプロフェッショナルで親しみやすく聞こえます。「サポートに連絡する」は事務的で、やや冷たく感じられます。ボタンの近くに、応答時間と連絡手段を日本語で短く説明する文を添えてください。日本人ユーザーは、エスカレーションの前にこうした事前情報をとても重視します。
日本語ヘルプセンターはどれくらいの頻度で再監査すべきですか？
アクティブなSaaS製品なら、四半期ごとが現実的な最低ラインです。機能のリリースに合わせて日本語UIは変わり、新しい記事が増え、古い記事は稼働中のビルドとずれていきます。アクセス上位20〜30記事に絞った短い四半期チェックを行えば、ずれの多くを、目に見える品質の差になる前に直せます。UIの変更が多い製品では、最近更新された記事を毎月スポットチェックするのも効果的な投資です。