TL;DR

ツールチップとコンテキストヘルプテキストが日本語ユーザーを失敗させるのには3つの一貫した理由があります。文脈なしで翻訳されること（UIから取り出されたツールチップ文字列は、意味を与える視覚的な錨を失います）、狭いスペースに圧縮されると日本語で曖昧になる英語の文構造が保持されること、そして外来語（カタカナ）と日本語の同等語を同じプロダクト内で混在させて不一致となること、の3点です。最もツールチップを多用する日本のパワーユーザーは、深く探索するすべての機能でこの不一致に遭遇します。

重要ポイント

ツールチップの翻訳が見た目より難しい理由

ツールチップは短いものです。ほとんどは30語未満です。この短さが翻訳を簡単に見せます。素早いバッチ作業、文字列ごとに数分、完了。問題は、ツールチップ翻訳の難しさが文字数にあるのではなく、文脈への依存性にあることです。「Mark as reviewed」と書かれたツールチップは、それが説明しているUI要素を見ることができる翻訳者には完全に明確です。しかし同じ文字列を翻訳ファイルから取り出すと（2,400行中の847行目）、「レビュー済みとしてマーク」と直接的で正確な翻訳として訳されるかもしれません。ところがその特定のUIの文脈とその場所のプロダクト語彙によっては、正しい日本語は「確認済みにする」や「レビュー完了にする」であるかもしれません。

この問題は大きなプロダクト全体で複利的に積み重なります。文脈なしで個別に翻訳されたツールチップの文字列は、それぞれは問題のないものです。しかし日本語ユーザーが一連の関連するUI要素にホバーしながら機能がどのように動作するかを探索するとき、個別に翻訳されたが文脈的につながっていないツールチップの累積した不一致は、「日本向けに作られていないプロダクト」として読まれます。この体験は、各パラグラフを正しく翻訳したが比較し合わなかった複数の人が翻訳した英語文書を読む体験に似ています。

日本のパワーユーザー、最もツールチップを多用するユーザーは、海外のSaaSプロダクトが日本で成功するかどうかを決めるユーザーです。カジュアルなユーザーはツールチップをまったく探索しないかもしれません。チームにプロダクトを推薦するかどうかを評価しているパワーユーザーは、機能探索中にツールチップを多用します。それらのツールチップが一貫性を欠いていたり文脈的にずれていたりすると、信頼感が最も重要な瞬間にパワーユーザーのプロダクトの日本語品質への信頼が下がります。

文字数管理：日本語テキストが収まらないとき

日本語のタイポグラフィは一方の次元では密集しており、他方では幅広です。日本語の文字は正方形のemを占めます。各文字は高さと同じ幅を持ちます。これはラテン文字と比べて、ラテン文字が平均でおよそ半分の幅であることと対照的です。60英語文字のツールチップは、同等の意味のために30〜35日本語文字を含むかもしれませんが、日本語の文字は集合的に英語の同等物よりも多くの水平スペースを占めます。

実際の結果はツールチップのオーバーフローです。英語の文字数を基準に設計されたツールチップは、レイアウトの境界で日本語テキストを頻繁に切り捨てます。これはツールチップの幅がピクセルでハードコードされていて自動折り返しに設定されていない製品、そしてツールチップコピーが開発中に英語でのみテストされたプロダクトで特によく見られます。

日本語のツールチップテキストが切り捨てられると、ユーザーは不完全または誤解を招く切り捨てられた文を見ることがあります。「このフィールドには半角英数字...」と途中で途切れると、ユーザーはツールチップがないよりも少ない情報しか得られません。何かが必要なことはわかりますが、何が必要かはわかりません。文字数制限フィールド、金額フィールド、またはフォーマット要件のあるフィールドでは、切り捨てられたツールチップは直接サポートの負担を生み出します。

よくあるオーバーフローパターン：アイコンボタン（テキストラベルなし、情報アイコンのみ）のツールチップが日本語で最もオーバーフローしやすいです。ツールチップがボタンが何をするかについての唯一の情報源であり、短いラベルではなく完全な文として書かれることが多いです。日本語の文構造は動詞を最後に置きます。動詞の前でツールチップが切り捨てられると、ツールチップ全体が意味的に不完全になります。日本語UIローカライゼーションを監査するときは、アイコンボタンのツールチップを優先的にレビューしてください。

外来語の一貫性問題

日本語には漢字、ひらがな、カタカナという3つの文字体系があり、さらにローマ字（romaji）も使われます。技術的なソフトウェア用語は慣例によってそれらのいずれにも現れる可能性があり、翻訳者によって異なる選択がなされます。これが日本語SaaSツールチップローカライゼーションで最も目立つ不一致パターンの1つです。

「folder」という単語を考えてみましょう。慣例的な日本語の表記はフォルダまたはフォルダー（末尾に長音符号を付けるかどうか）です。どちらも受け入れられています。日本語のスタイルガイドはどちらを使うかで見解が分かれており、文化庁（Agency for Cultural Affairs）はほとんどの外来語に長母音形を推薦しています。しかし多くのプロダクトは、異なる翻訳者、または同じ機械翻訳ツールの異なる実行が異なる選択をしたために、ツールチップ文字列全体で両方の形式を混在して使用しています。

同様の不一致がファイル / ファイル（file）、フォーム / フォーム（form）、バックアップ / バックアップ（backup）でも見られます。これらは意味上のエラーではありません。どちらの形式も理解されます。しかし日本のユーザーが一方のツールチップで「フォルダ」を見て別のツールチップで「フォルダー」を見たとき、または「ユーザー」と「ユーザ」が混在しているとき、ローカライゼーション作業の質について結論を出します。その結論は間違っていません。

用語 不一致（両方が使われている） 推奨の統一形 注記
Folder フォルダ / フォルダー フォルダー 文化庁推奨の長音符付き形
User ユーザ / ユーザー ユーザー 長音符付きが現代的表記
Server サーバ / サーバー サーバー IT業界では長音符付きが主流
Member メンバー / メンバ メンバー 短縮形は旧式表記
Timer タイマー / タイマ タイマー 長音符付きが現在の標準

オンボーディングツールチップツアー：順序の一貫性

オンボーディングツールチップツアー（新しいユーザーをプロダクトのコア機能に案内するステップバイステップのウォークスルー）は、静的なツールチップとは異なるローカライゼーションの課題を提示します。ツアーの各ステップは前のステップと文脈的につながっており、次のステップにつながっています。ユーザーはナラティブのアークを体験しています。できることはこれ、その方法はこれ、したときにはこうなる、という流れです。

オンボーディングツールチップツアーの文字列が、翻訳者が完全な順序を見ずに個別に、ファイル順で翻訳されると、日本語のナラティブの一貫性が崩れます。ステップ3が、ステップ2が確立するはずだった概念を導入するかもしれませんが、ステップ3の翻訳者がステップ2の文脈なしに作業していた場合、ステップ3で使われる用語はステップ2で導入された用語と異なるかもしれません。連続した指示に注意深く従い、用語を正確に追跡する日本語ユーザーにとって、このような不一致は壊れたチュートリアルとして読まれます。

ツールチップツアーのローカライゼーションの修正は手続き上のものです。翻訳者またはレビュアーは、各ステップの日本語が前のステップから一貫して続いていることを確認するために、実際のプロダクト内でツアーを順番に走破する必要があります。これは文字列ファイルのレビューではありません。プロダクトのウォークスルーです。時間がかかりますが、プロダクトのコアアクティベーションフローにとって、品質の差は顕著です。

日本語ローカライゼーションのツールチップQAチェックリスト

☐

すべてのツールチップが文字列ファイルだけでなく、視覚的な文脈の中でレビューされている

各ツールチップは、視覚的な錨となる要素が見える状態で、翻訳者またはレビュアーによって実際のUIの中で確認されました。文脈なしの文字列翻訳が特定され、修正されています。

☐

外来語の形式がすべてのツールチップを通じて一貫している

各外来語に対して単一のカタカナ形式が選ばれ、すべてのツールチップ文字列に一貫して適用されています。使用された用語集が文書化され、すべての担当者と共有されています。

☐

サポートされているすべてのブラウザで日本語テキストのツールチップオーバーフローがテストされている

ツールチップコンテナは最大長の日本語テキストでテストされています。切り捨てられたツールチップが特定され、コピーが短縮されたかコンテナが調整されています。

☐

オンボーディングツールチップツアーが順番にレビューされている

完全なツールチップツアーが日本語レビュアーによって順番に走破され、用語がステップごとに一貫していて、ナラティブの論理が日本語で成立することが確認されています。

☐

アイコンボタンのツールチップが優先的にレビューされている

アイコンのみのボタンのツールチップ（ボタンの機能についての唯一の情報源となるもの）は、オーバーフローリスクが高くユーザー依存度が高いことを考慮して、優先的にレビューされています。

☐

機能レベルにわたる文体の一貫性が確認されている

ツールチップの文体（カジュアル vs フォーマル、初心者向け vs 技術的）は機能エリアによって意図的に適用されており、異なる翻訳者の作業の間で翻訳の副産物として変化していません。

よくある質問

日本語ツールチップは普通語と丁寧語のどちらを使うべきですか？

B2B SaaSプロダクトでは、ツールチップには一貫した丁寧な文体を使うべきです。完全な文にはです・ます体を、1行のラベルには体言止めを使うのが基本です。平易体と丁寧体の選択はツールチップの種類によります。UIの要素に表示されるホバーツールチップは通常、短い名詞句（動詞なし、文体の選択不要）です。説明文を含むコンテキストヘルプパネルは全体を通じて丁寧語を使います。同じツールチップパネル内で平易体の文と丁寧体の文を混在させるパターンが最も避けるべきことです。

日本語ツールチップ監査で最も重要なチェック項目は何ですか？

文脈の正確さが最も重要です。日本語ツールチップが、プロダクトで確立した語彙を使って、接続先の要素を正確に説明しているかどうかです。これは文字列ファイルだけでは確認できません。レビュアーはUIの中でツールチップを実際に見る必要があります。文脈の正確さの次に優先すべきはプロダクト全体との用語の一貫性です。ナビゲーションや設定ページの機能名と異なる用語を使っているツールチップは、プロダクトのメンタルモデルを構築しようとしている日本語ユーザーに方向感覚の喪失をもたらします。

確立した日本語の専門用語がない機能のツールチップはどう扱えばよいですか？

最善のアプローチは、初出時に英語の用語をカタカナで記し、その後に簡潔な日本語の説明を添えることです。「バックフィル（過去データの一括取り込み）」のように、カタカナ語に続けて括弧内に平易な日本語の説明を加えます。日本のITプロフェッショナルを対象とした高度な機能では、日常業務で使っている英語の専門用語をそのまま使っても構いません。判断の基準はそのツールチップのユーザー層です。そのツールチップのユーザーが英語用語を知っている可能性が高ければそのまま使い、一般的なビジネスユーザーが多い場合は日本語の説明を添えましょう。

ツールチップを翻訳せず英語のままにすべき場合はありますか？

特定のケースではあります。フィールド名（JSONキー、パラメータ名）を参照するAPIドキュメントのインラインツールチップは、周囲の説明が日本語であっても技術的な識別子は英語のまま維持すべきです。「application_id — アプリケーションを一意に識別するID（英数字32文字）」のような形です。フィールド名を英語のまま保つことで、ユーザーがコードにコピーする際の混乱を防げます。同様に、キーボードショートカットのインジケーター（Cmd+K、Ctrl+Shift+P）のツールチップは、UI言語に関わらずショートカット表記を英語のまま維持すべきです。日本で使われるほとんどのキーボードのキーは英語表記だからです。

料金やプランの制限を説明するツールチップはどのようにローカライズすべきですか？

プランの制限や機能の利用可否を説明するツールチップは、販売と信頼の観点から重要度が高いものです。グレーアウトした機能にホバーした日本のユーザーは「なぜ使えないのか」と問いかけています。そのツールチップが答えです。答えが不明瞭だったり機械翻訳のように聞こえたりすると、不信感を生みます。これらのツールチップは制限と解決策への道を明示すべきです。「この機能はProプラン以上でご利用いただけます。アップグレードについてはプランページをご覧ください。」明確で具体的、かつ次のアクションへの道があること。これは料金に関するあらゆる日本の顧客向けコミュニケーションと同じ基準です。

関連記事

あなたのツールチップは日本のパワーユーザーに機能していますか？

プロダクト内ガイダンスの文字列は、最も深く探索する日本語ユーザーの信頼をプロダクトが勝ち取るか失うかを決める場所です。

ミニ診断を依頼する