要点まとめ

日本語の検索・フィルターUIが崩れる典型パターンは4つあります。日本人ユーザーが決して入力しないような英語の検索例を使ったプレースホルダーテキスト、日本人ユーザーが実際に頭の中で使う用語と一致しないフィルターラベルの翻訳、日本語入力（IME）の動作を無視したオートコンプリート、そして日本人ユーザーが「自分の入力が間違っているのか、システムに問題があるのか」を判断できないゼロ件表示のコピー。これらはいずれもエンジニアリングの変更を必要としません。日本人ユーザーがプロダクト内をどう移動して検索するかを理解したうえで行われるローカライゼーションによって解決できます。

この記事のポイント

プレースホルダーテキストの問題：日本人ユーザーが絶対に入力しない例

検索バーのプレースホルダーテキストは、その検索がどんな入力を受け付けるかを示す暗黙の説明として機能します。英語では「Search contacts, companies, or deals…」や「Type to filter by name」のようなプレースホルダーは自然に機能します。なぜなら例示されている内容が、英語圏ユーザーが検索対象データについて実際に考える方法と一致しているからです。

このプレースホルダーテキストを日本語に翻訳すると、文法的には正しいものの実用的にはズレが生じます。「連絡先、会社名、または取引で検索...」は、どんなカテゴリがあるかは伝わりますが、「どう検索するか」は伝わりません。CRMで検索する日本のビジネスユーザーは、会社名を漢字で、人名をひらがなまたはカタカナで、あるいはメールアドレスで入力する可能性があります。これを（間接的にでも）示すプレースホルダーは、抽象的なカテゴリを列挙するだけのものより確実にコンバージョンが上がります。

より根本的な問題は、日本人の名前が複数の書き方で表現できることです。「田中」（漢字）、「たなか」（ひらがな）、「タナカ」（カタカナ）——連絡先を探す日本人ユーザーはそのどれで入力するかわかりません。プロダクトの検索が音声的な柔軟性を持たないなら、プレースホルダーでその検索の対応範囲と非対応範囲を明示すべきです。「名前（漢字・ひらがな可）で検索」はユーザーに有益な情報を伝えます。「連絡先で検索」は何も教えてくれません。

⚠ 英語からの直訳
連絡先、会社名、または取引で検索...
カテゴリ名を列挙しているだけ。何が存在するかは伝わるが、どう検索するかは伝わらない。日本語の名前入力のバリエーションも考慮されていない。
✓ 日本語を意識したプレースホルダー
名前・会社名・メールアドレスで検索
日本人ユーザーが実際に入力する具体的な入力タイプを明示。コンパクトで実用的。末尾の三点リーダーも不要。
⚠ 汎用翻訳
フィルタリングするには入力してください
「Type to filter」の直訳。文法的にぎこちなく、述語が末尾に来る構造のせいで動作が埋もれてしまっている。
✓ 自然な日本語の操作案内
キーワードで絞り込む
「絞り込む」はフィルタリングを表す自然な日本語動詞。コンパクトかつ行動を促す表現。

フィルターラベルの翻訳：ステータス vs. 状態 vs. 進捗

フィルターラベルは、あらゆるSaaSプロダクトの中で最も用語に敏感なローカライゼーション面のひとつです。多くの場合たった一語で、フィルタリング対象のデータについて日本人ユーザーが頭の中でどう分類するかと正確に対応している必要があります。用語を間違えても機能は止まりませんが、使うたびに小さな引っかかりが生まれます。「ステータス」は社内レポートで見る「状態」と同じものなのか？」という疑問です。

「Status」の日本語訳がこの問題をよく示しています。日本語SaaSには3つの候補があります。「ステータス」（カタカナの外来語）、「状態」（和語の複合語）、「進捗」（前進・進行を表す語）。文脈によっていずれも正確な翻訳です。「ステータス」は、プロジェクト管理ツール・チケットシステム・CRMパイプラインのように「status」が認識されたフィールド名として使われるドメインに適しています。「状態」は接続状態・アカウント状態・ドキュメントの状態といったシステムレベルの状態に向いています。「進捗」はステージを経て進むことを意味し、ワークフローやタスクの文脈に最も合います。

問題は、多くの日本語SaaSプロダクトが文脈に関わらず「ステータス」を使い続けることです。最も直訳しやすく、判断を必要としないからです。その結果、会議や社内文書では「状態」や「進捗」と自然に言うはずの概念に対して、わずかに外来語的な響きを持つフィルターラベルが生まれます。

英語のフィルターラベル よくある翻訳 より適切な代替案 代替案が適切な文脈
Status ステータス 状態 / 進捗 ドキュメントの状態、タスクの進行管理の文脈
Type タイプ 種別 / 種類 ドキュメント分類、チケットのカテゴリ分け
Owner オーナー 担当者 / 所有者 タスクのアサイン、アカウントの責任者管理の文脈
Priority プライオリティ 優先度 あらゆる文脈——「優先度」が日本語ビジネス用語の標準
Category カテゴリー カテゴリ / 分類 どちらも許容範囲。「分類」の方がより正式でネイティブ感がある
Tag タグ タグ（ラベル） タグの概念に不慣れなユーザーがいる場合は括弧書きを添える

IMEを意識した検索：日本語のテキスト入力が標準の検索トリガーを壊す仕組み

PCやモバイルデバイスでの日本語テキスト入力はIME（Input Method Editor）を経由します。ユーザーがローマ字で「tanaka」と入力すると、IMEはSpaceキーやEnterキーを押したタイミングで変換ステップを経てひらがな（たなか）または漢字（田中）に変換します。入力中の変換前の段階では、入力フィールドにはまだ日本語になっていないローマ字が入っています。

キーストロークごとに発火する検索機能——英語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テストを含めてレビューされます。

ミニ診断をリクエストする