要点まとめ
日本語の検索・フィルターUIが崩れる典型パターンは4つあります。日本人ユーザーが決して入力しないような英語の検索例を使ったプレースホルダーテキスト、日本人ユーザーが頭の中で実際に使う用語と一致しないフィルターラベルの翻訳、日本語入力（IME）の動作を考慮していないオートコンプリート、そして日本人ユーザーが「自分の入力が間違っているのか、システムに問題があるのか」を判断できないゼロ件表示のコピーです。いずれもエンジニアリングの変更は必要ありません。日本人ユーザーがプロダクト内をどう移動し、どう検索するかを理解した上でローカライズすれば解決できます。
この記事のポイント
- 検索プレースホルダーには日本語のクエリ例を使い、英語を翻訳したものを使わない：「Search by name or email」を「名前またはメールアドレスで検索」と訳せば文法的には正しいものの、どんな文字や書式で入力すればよいのかは日本人ユーザーに伝わりません。
- フィルターラベルは日本人ユーザーが実際に思い浮かべる用語に合わせる：「Status」を「ステータス」と訳すのは正確ですが、プロダクトのドメインによっては「状態」や「進捗」の方が直感的にわかる場合があります。
- IMEを意識した検索コピーは、日本語テキストの実際の入力方法を反映する：日本人ユーザーはローマ字で入力してから変換するため、部分入力で発火する検索は変換が終わる前に動いてしまい、誤った検索クエリが送られます。
- ゼロ件表示はユーザーの誤りとシステム上の制限を区別する必要がある：「No results found」と「Search unavailable」には、まったく異なる日本語コピーが必要です。混同すると信頼を損ないます。
- ソートオプションは日本語SaaSの中で最も一貫性を欠きやすいローカライゼーション箇所のひとつ：「Newest first」「A–Z」「Relevance」の翻訳は、日本語の文字の並び順という文脈で、予期しない挙動につながることがあります。
プレースホルダーテキストの問題：日本人ユーザーが絶対に入力しない例
検索バーのプレースホルダーテキストは、その検索がどんな入力を受け付けるかを暗に説明する役割を果たします。英語では「Search contacts, companies, or deals…」や「Type to filter by name」のようなプレースホルダーが自然に機能します。例示されている内容が、英語圏のユーザーが検索対象のデータについて実際に考えるやり方と一致しているからです。
このプレースホルダーテキストを日本語に翻訳すると、文法的には正しくても実用面ではずれが生じます。「連絡先、会社名、または取引で検索...」では、どんなカテゴリがあるかは伝わっても、「どう検索するか」は伝わりません。CRMで検索する日本のビジネスユーザーは、会社名を漢字で、人名をひらがなかカタカナで、あるいはメールアドレスで入力するかもしれません。これを間接的にでも示すプレースホルダーのほうが、抽象的なカテゴリを並べるだけのものより確実にコンバージョンが上がります。
より根本的な問題は、日本人の名前には複数の書き方があることです。「田中」（漢字）、「たなか」（ひらがな）、「タナカ」（カタカナ）。連絡先を探す日本人ユーザーが、このどれで入力するかはわかりません。プロダクトの検索が読みの揺れに対応していないなら、プレースホルダーで対応範囲と非対応範囲を明示すべきです。「名前（漢字・ひらがな可）で検索」はユーザーに役立つ情報を伝えます。「連絡先で検索」は何も教えてくれません。
フィルターラベルの翻訳：ステータス vs. 状態 vs. 進捗
フィルターラベルは、SaaSプロダクトの中でも特に用語選びがシビアな箇所です。たいていはたった一語で、フィルタリング対象のデータを日本人ユーザーが頭の中でどう分類しているかに正確に合わせなければなりません。用語を誤っても機能は止まりませんが、使うたびに小さな引っかかりが生まれます。「『ステータス』は社内レポートで見る『状態』と同じものなのか？」という疑問です。
「Status」の日本語訳がこの問題をよく示しています。日本語SaaSには3つの候補があります。「ステータス」（カタカナの外来語）、「状態」（漢語）、「進捗」（前進・進行を表す語）。文脈によっていずれも正確な翻訳です。「ステータス」は、プロジェクト管理ツール・チケットシステム・CRMパイプラインのように「status」が認識されたフィールド名として使われるドメインに適しています。「状態」は接続状態・アカウント状態・ドキュメントの状態といったシステムレベルの状態に向いています。「進捗」はステージを経て進むことを意味し、ワークフローやタスクの文脈に最も合います。
問題は、多くの日本語SaaSプロダクトが文脈に関わらず「ステータス」を使い続けることです。最も直訳しやすく、判断を必要としないからです。その結果、会議や社内文書では「状態」や「進捗」と自然に言うはずの概念に対して、わずかに外来語的な響きを持つフィルターラベルが生まれます。
| 英語のフィルターラベル | よくある翻訳 | より適切な代替案 | 代替案が適切な文脈 |
|---|---|---|---|
| Status | ステータス | 状態 / 進捗 | ドキュメントの状態、タスクの進行管理の文脈 |
| Type | タイプ | 種別 / 種類 | ドキュメント分類、チケットのカテゴリ分け |
| Owner | オーナー | 担当者 / 所有者 | タスクのアサイン、アカウントの責任者管理の文脈 |
| Priority | プライオリティ | 優先度 | あらゆる文脈——「優先度」が日本語ビジネス用語の標準 |
| Category | カテゴリー | カテゴリ / 分類 | どちらも許容範囲。「分類」の方がより正式でネイティブ感がある |
| Tag | タグ | タグ（ラベル） | タグの概念に不慣れなユーザーがいる場合は括弧書きを添える |
IMEを意識した検索：日本語のテキスト入力が標準の検索トリガーを壊す仕組み
PCやモバイルデバイスでの日本語テキスト入力はIME（Input Method Editor）を経由します。ユーザーがローマ字で「tanaka」と入力すると、SpaceキーやEnterキーを押したタイミングでIMEが変換を行い、ひらがな（たなか）や漢字（田中）になります。変換が確定するまでの間、入力フィールドにはまだ日本語になっていないローマ字が入っています。
英語SaaSでは即時フィルタリングとしてよく使われる、キーストロークごとに発火する検索は、このIMEの中間状態でも発火します。その結果、日本人ユーザーの画面には「t」「ta」「tan」「tana」それぞれの検索結果が次々と表示されます。どれも有効な日本語の検索語ではなく、「たなか」への変換が完了する前に表示されてしまうものです。変換中は不正確な結果や空の結果が返るため、日本人ユーザーには「検索が動いていない」と映ります。実際には、英語入力を想定した設計どおりに動いているのですが。
解決には、エンジニアリング面の対処（キーアップではなくIMEのcompositionendイベントを待ってから検索を発火させる）と、検索フィールド周辺のコピーでのローカライゼーション面の対処の両方が必要です。検索トリガーがIMEに対応していない場合は、検索フィールドの下に「変換確定後に検索結果が表示されます」のような短い案内文を添えれば、日本人ユーザーは表示内容を正しく理解できます。根本的な解決ではなくその場しのぎですが、IMEの遅延を検索の失敗と受け取るユーザーの割合を大きく下げられます。
モバイルについての注記：モバイルでの日本語入力は、iOSとAndroidでIMEの動作が異なります。iOS日本語キーボードのユーザーはかな直接入力が多く、Androidユーザーはローマ字入力が一般的です。日本語SaaSのモバイル検索は両方のキーボードモードでテストする必要があり、プロダクトのターゲットデバイスを日常的に使用する日本語話者のテスターが少なくとも1人は参加すべきです。これはモバイルのローカライゼーションQAで最もよく見落とされるシナリオのひとつです。
ゼロ件表示のコピー：ユーザーの誤りとシステムの制限を区別する
日本人ユーザーが検索して何も見つからないとき、考えられる状況はまったく異なる2つです。まず、ユーザーが検索語を間違えた、誤った文字体系を使った（システムがひらがなで保存しているのにカタカナで検索した）、システムに存在しない語を使った場合。次に、システムに本当に一致するレコードがない、検索インデックスが利用できない、そのユーザーには一致する結果を表示する権限がない、といった場合です。英語SaaSではどの状況でも同じ「No results found」が表示されがちですが、日本語ではそれぞれに合った対応が必要です。
本当に該当なしの場合は、検索が正常に完了したことを伝え、クエリを絞り込む手がかりを示すコピーが必要です。「「田中」に一致する結果はありませんでした。検索条件を変えてお試しください。」——この一文で「システムは動いた、何もマッチしなかった、別の方法で試してほしい」ことが伝わります。ユーザーを責めず、システムの障害も示唆しない表現です。
レコードは存在するのに、権限のせいでそのユーザーには表示されず空になる場合は、別のアプローチが必要です。文脈上あるはずのレコードが説明もなく「No results」になると、ユーザーは混乱し、サポートへの問い合わせにつながります。「現在の権限では結果が表示されません」は正直で具体的な表現で、次にとるべき行動（権限を確認するか管理者に連絡する）もユーザーに示せます。
ソートオプションのローカライゼーション：意味通りに並ばない並び替え
ソートオプションは、日本語ローカライゼーション作業の最後にレビューされがちな文字列です。短くてシンプルに見え、直訳で済みそうに感じるからです。しかし実際には、ソートオプションの訳し方しだいで微妙な問題が生じ、日本人ユーザーがリストや検索結果を操作するときの使い心地に響きます。
「Newest first」は「新しい順」で、正確かつ自然です。「Oldest first」は「古い順」で、これも正確です。問題は「A–Z」から始まります。「A〜Z順」や「アルファベット順」は英語のアルファベット順ソートという概念を訳したものですが、日本語名のレコードを探している日本人ユーザーはアルファベット順を意識していません。日本語の名前にとって意味のある並び順は、アルファベット順に相当する日本語の音節順、つまり「五十音順」です。日本語で「A〜Z」とラベル付けされたソートは、日本語の名前をローマ字表記順に並べることを意味しますが、実際の実装がそうなっていないことがほとんどです。
正しいやり方は、ソートが実際に何をしているかに合わせて日本語のラベルを付けることです。作成タイムスタンプ基準のソートなら「作成日（新しい順）/作成日（古い順）」が正確です。名前のローマ字表記順でソートするなら、実装されていない五十音順をほのめかすより、「名前（アルファベット順）」と明示するほうが誠実です。
日本語ローカライゼーション 検索・フィルターQAチェックリスト
プレースホルダーテキストに日本語のクエリ例が使われており、英語カテゴリを翻訳したものになっていない
検索プレースホルダーのコピーで、日本人ユーザーが実際に入力する具体的な入力タイプ（名前、メールアドレス、IDなど）を示している。英語から翻訳した抽象的なカテゴリ名になっていない。
フィルターラベルがドメインに適した日本語用語と照合されている
ステータス、タイプ、担当者、優先度など各フィルターラベルが、最も近い辞書的翻訳ではなく、そのプロダクトのドメインにおける日本人ユーザーの思考に合った用語として評価されている。
対象デバイスを使用する日本語話者テスターによるIME動作テストが実施されている
日本語IME入力（ローマ字→ひらがな/漢字変換）で検索をテストし、未変換テキストで検索が発火しないこと、またはIME変換中に適切なコピーが表示されることを確認している。
ゼロ件表示が「マッチなし」「権限制限」「システムエラー」を区別している
3種類のゼロ件シナリオにそれぞれ固有の日本語コピーを用意している。本当にマッチなしの場合は絞り込みの案内、権限によって空になる場合はアクセス制限の説明、システムエラーの場合は問題を認知し復旧方法を提示する。
ソートオプションのラベルが実際のソート動作に合っている
ソートラベルが実装されているソートの実態に正確に対応している。日本語名のアルファベット順ソートは、ローマ字順か五十音順かを明示している。日付ソートはソートに使う日付フィールドを明記している。
検索件数の表示が自然な日本語の数量表現になっている
「3 results」は「3件」と表示され（「3個」や「3つ」ではなく）、日本語のビジネス文脈において案件・レコード・検索結果の標準的な助数詞である「件」が使われている。
よくある質問
外資SaaSにおいて、日本人ユーザーが検索で特に苦労する理由は何ですか？
3つの要因が重なり、日本人ユーザーにとっての検索は英語圏のユーザーより難しくなっています。第一に、日本人の名前は漢字・ひらがな・カタカナと複数の文字体系で書けるため、読みの揺れに対応していない検索では、入力した文字と保存データの文字体系が違うとマッチを見落とします。第二に、IMEによる日本語入力には変換ステップがありますが、キーストロークごとに発火する検索はこれに対応していません。第三に、日本語SaaSのフィルターラベルやソートオプションの語彙は英語ほど標準化されていないため、日本人ユーザーは他のツールで覚えた知識を使い回せず、製品ごとに用語を覚え直す必要があります。
「件」とは何ですか？また、検索件数の表示においてなぜ重要なのですか？
「件」（けん）は、ビジネス文脈において案件・記録・リスト項目・検索結果に使われる日本語の助数詞です。「3件の結果」は「3件の検索結果」を意味し、「件」によってそれらが個別の記録や案件であることが示されます。誤った助数詞（物体に使う「個」や一般的な「つ」）を使うことは文法的には可能ですが、ビジネスソフトウェアの文脈では場違いに聞こえます。英語話者が「3 informations」と言われると不自然に感じるのと同様に、日本人ユーザーも誤った助数詞をネイティブではないと直感的に察知します。
日本語SaaSの検索はひらがな・カタカナの両方の入力に対応すべきですか？
理想的には対応すべきです。これはローカライゼーションの問題であると同時に、プロダクトエンジニアリングの問題でもあります。「ヤマダ」（カタカナ）という名前を探す日本人ユーザーが、「やまだ」（ひらがな）で入力することもあります。文字体系間の正規化に対応していない検索はマッチを見落とし、記録が存在しないと誤解させてしまいます。完全な読みの正規化が難しい場合は、検索プレースホルダーのテキストで、どの文字体系に対応しているかを明示することが大切です。「カタカナまたはひらがなで検索」と示せば、ユーザーはどう入力すればよいかがわかります。検索に失敗して初めて制限に気づかせるより、事前に伝えるほうがUXとして優れています。
高度なフィルターパネルはどのように日本人ユーザー向けにローカライズすればよいですか？
AND/OR論理を組み合わせた複合条件を設定できる高度なフィルターパネルでは、論理演算子と条件ラベルの日本語コピーに特に注意が必要です。AND/ORは、技術に詳しい利用者向けなら英語のまま、一般的なビジネスユーザー向けなら「かつ」/「または」と訳せます。フィルターが有効なときに検索バーの下に出るフィルターサマリー（「3つのフィルターを適用中」）では、日本語の助数詞のルールに従い、レコード数には「件」、フィルター数には「つ」を使います。「Clear all filters」は「フィルターをリセット」または「フィルターを解除」とします。「クリア」のような直訳は、丁寧さが求められるビジネス文脈には合いません。
日本語SaaSにおける最も多い検索ローカライゼーションの失敗は何ですか？
最もよく見られる失敗は、英語の語彙を前提に作られたオートコンプリートが、日本語向けに見直されていないことです。開発時のサンプルデータに由来する「John Smith」や「Q3 2025 Report」が日本人ユーザーへの候補として表示されると、日本語コンテンツでテストされていないプロダクトだと一目でわかってしまいます。対処法はシンプルです。開発・QA環境でも日本語のサンプルデータを使えば、テスト中に表示されるオートコンプリートの候補も、日本人ユーザーにとって自然なものになります。
関連記事
日本人ユーザーはあなたのプロダクトで本当に探しているものを見つけられていますか？
検索・フィルターのコピーは、Hiraki Localizationの全てのミニ診断でIMEテストを含めてレビューされます。
ミニ診断をリクエストする