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）はほとんどの外来語で長音を付ける形を推奨しています。ところが多くのプロダクトでは、翻訳者が違ったり、同じ機械翻訳ツールでも実行ごとに結果が違ったりしたために、ツールチップ全体で両方の表記が混在しています。

同じ不統一は、サーバ / サーバー（server）、プリンタ / プリンター（printer）、コンピュータ / コンピューター（computer）でも見られます。意味の誤りではなく、どちらの表記でも通じます。しかし日本のユーザーは、あるツールチップで「フォルダ」、別のツールチップで「フォルダー」を見たり、「ユーザー」と「ユーザ」が混ざっているのに気づいたりすると、ローカライゼーション作業の質を見定めます。そしてその見立ては間違っていません。

用語 不一致（両方が使われている） 推奨の統一形 注記
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プラン以上でご利用いただけます。アップグレードについてはプランページをご覧ください。」明確で具体的で、次の行動への道筋があること。料金に関する日本の顧客向けコミュニケーションすべてに通じる基準です。

関連記事

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

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

ミニ診断を依頼する