データテーブルはほとんどのB2B SaaS製品で最も情報密度が高く、多くのチームが最後にローカライズする画面です。列ヘッダーの簡潔さと折り返し制御、ソート・フィルターコントロールのコピー、絞り込みvsフィルターの判断、一括操作ボタンの表現、エンプティ・ローディングステート、ページネーションラベル、数値・日付列——それぞれに日本のビジネスユーザーが期待する慣習があります。本記事では、グリッドが「ローカライズされた製品」として読まれるか「翻訳されたもの」として読まれるかを左右するテーブルレベルの判断を解説します。
ローカライゼーションの労力のほとんどは、見えやすい表面に向けられます——マーケティングサイト、オンボーディングフロー、設定ページなどです。データテーブルが最後にローカライズされる理由は、製品の内側に埋め込まれており、コピーとして書かれるのではなくコンポーネントライブラリで生成され、列ヘッダーを翻訳した瞬間に「完成」と見なされるからです。しかしテーブルは、パワーユーザーが業務時間のほとんどを過ごす場所です。エクスポートグリッドで作業する財務アナリストや、チケットテーブルを使うカスタマーサクセスのリーダーは、製品の他のどの画面よりも頻繁にローカライゼーション品質を目にします。
テーブルはまた、直訳に特に対応しにくい表面でもあります。英語のテーブルUIは英語の組版的特性を前提に設計されています——短い単語、きれいな折り返しを可能にするスペース、助数詞が不要な計数文法。日本語にはそのいずれもありません。文字はラテン文字のほぼ2倍の幅があるため、英語ではすっきり収まっていたヘッダーが列をはみ出します。スペースがないため、ブラウザは任意の文字間でヘッダーを折り返します。そして日本語は行を助数詞で数えます——件——英語に相当する語はなく、すべてのカウント・選択・ページネーションラベルの自然な表現が変わります。
つまりテーブルのローカライゼーションは翻訳パスではありません。レイアウトの再設計です。語彙、省略戦略、改行制御、計数文法——これらすべてを意図的に決定する必要があります。翻訳メモリと英語形状のコンポーネントライブラリに任せてデフォルトで決定された場合、日本のエンタープライズユーザーが一目で見抜く「半分ローカライズされたグリッド」になります。
列ヘッダーは製品の中で最もスペースが制約されたテキストです。英語では、ヘッダーがはみ出したり列幅を広げたりする前に使える文字数はわずかです。日本語は1文字の幅がより広いため使える文字数はさらに少なく、直訳はほぼ常に長すぎます。
最初のルールは積極的な簡潔化です。英語のヘッダーは、列の位置が既に示している言葉で埋め尽くされていることが多いです。「Last Updated Date」は3語ですが、列には日付が表示されているので、更新日（3文字）で意味が完全に伝わります。「Customer Name」は顧客名であり、顧客の名前ではありません。「Registration Date」は登録日です。英語が文法的完成のために含める冗長な名詞は、日本語には不要です。
2番目のルールは改行制御です。日本語にはスペースがないため、収まらないヘッダーをブラウザに任せると任意の文字間で折り返します。最終ログイン日時というヘッダーが最終ログ / イン日時と表示されることがあります——カタカナ語のログインが2行に分断されており、日本語読者には壊れたテキストとして見えます。優先度の高い順に3つの修正方法があります。1行に収まるようヘッダーを短くする。2行ヘッダーが避けられない場合は意味のある境界で改行するよう設計する（最終ログイン / 日時）。そしてCSSのword-breakルールやワードジョイナー文字を使ってカタカナ語が分断されないようにする。最悪の結果はブラウザに任せることです——語の途中で改行が入ります。
3番目のルールは単位の配置です。計測値を表示する列では、すべてのセルに単位を繰り返すのではなく、日本語の慣習に従ってヘッダーの括弧内に単位を付記します——金額（円）、容量（GB）、利用率（%）。これによりセルがすっきりし、列のスキャンが容易になります。英語のテーブルでもこの方法が使われることがありますが、日本のビジネステーブルではほぼ普遍的であり、省略するとその列が未完成に見えます。
テーブルの上下に配置されるコントロール——ソート、フィルター、検索、グループ化——は短いラベルです。短いからこそ見落とされます。主要なコピーデッキではなくコンポーネントレベルのUIに埋め込まれているため、本文のコピーに集中した翻訳パスではそのまま通り過ぎてしまいます。また、これらは日本のユーザーが20年間あらゆる日本のビジネスアプリケーションで読んできたラベルであるため、慣習に反する選択は即座に摩擦を生じさせます。
最も重要な判断はフィルタリングです。行を条件で絞るアクションには、絞り込みが日本のビジネスソフトウェアで確立した用語であり、完全にネイティブに読まれます。フィルターは認知されており、英語由来の用語が期待される開発者向けやアナリティクス重視のツールでは許容されますが——一般的なエンタープライズSaaSでは絞り込みがより安全なデフォルトです。明らかな誤りはフィルタリングをラベルとして使うことです。これは動名詞形の「フィルタリングをしている」であり、ボタンやコントロールとしてはインターフェース要素ではなく直訳として読まれます。コントロールには絞り込みを使い、適用アクションには絞り込むまたはフィルタを適用を使います。
他のテーブルコントロールも直訳ではなく日本のソフトウェア慣習に従います：
これらはスタイルの好みではありません。日本のユーザーが機能に自動的に結びつけているラベルです。正確でも非標準の代替表現を使うと、ユーザーは既に知っているコントロールの使い方を再学習させられます——これはローカライゼーションが目指すものとは正反対です。
ユーザーが行を選択して一括操作バーが表示されたとき、2つのコピーが重要です——選択件数と操作ボタン。英語のソースが日本語と共有しない文法を使うため、どちらも一般的に誤った処理がされます。
英語は行を素の数字で数えます——「3 selected」。日本語はレコードや行に助数詞の件が必要です——3件を選択中（3件が選択されています）。ここで個やつを使うのは誤りです——それらは物理的なモノや一般的な項目に使うものであり、テーブルのレコードには使いません。選択状態は3件を選択中または3件選択しましたと自然に読まれ、件によってカウントが行を指していることが明確になります。
操作ボタンでは、ユーザーが実行しようとするアクションを動詞で示し、オプションで件数を組み込みます。英語の「Delete selected (3)」は選択した3件を削除、またはよりコンパクトに、3件を選択中インジケーターの横に削除ボタンとなります。すべての一括操作に一括（bulk）をプレフィックスとして付ける衝動は抑えるべきです。一括削除は一括性が強調ポイントである場合（専用の「すべてを一括削除する」機能など）には適切ですが、現在の選択に対して操作するボタンには、削除だけの方がすっきりして読みやすいです。
破壊的な一括操作の確認ダイアログでは件数を再掲します——選択した3件を削除しますか？（選択した3件のレコードを削除しますか？）確認での件数の明示はユーザーに範囲を再確認させます——日本のエンタープライズ環境では、誤った一括削除が深刻な問題であり、確認コピーには明示的な表現が期待されているため、特に重要です。
テーブルが空になる理由は全く異なる2つがあり、日本語の慣習——そして優れたUXライティング全般——はそれらを区別します。誤りは両方に同じメッセージを使うことで、ユーザーはデータが消えたのかフィルターで除外されただけなのか判断できなくなります。
まだレコードが存在しない真のエンプティテーブルはデータがありません、またはより温かみのあるまだデータがありません（「まだデータがありません」——やがて来ることを示唆）と表示します。初回表示のエンプティステートには、アクション指向の形がさらに優れています——最初のデータを追加してください。フィルターで何も一致しない不一致状態は、フィルターを認識した表現にする必要があります——条件に一致するデータがありません（「条件に一致するデータがありません」）。この1つの区別が、フィルターを適用したらシステムがレコードを削除したと思い込むパニックを防ぎます。
ローディング状態は3番目のケースです。翻訳されていない「Loading...」はコンポーネントライブラリの内部に存在するため、よくある見落としです。日本語の形は、汎用的な読み込みには読み込み中...、長めのフェッチにはデータを取得しています（「データを取得しています」）で、両方ともです/ます体。ページネーションやレイジーロードを行うテーブルでは、さらに読み込み中...（「さらに読み込み中」）が増分ロードと最初の読み込みを区別します。
ページネーションラベルは計数文法で詰まっているため、不自然な日本語が頻繁に生まれます。英語の「1–20 of 348」は348件中 1〜20件に対応します——日本語は合計（348件中、「348件のうち」）を表示範囲の前に置きます。英語の順序と逆です。「Rows per page」は表示件数または1ページあたりの表示件数となり、ここでも件を使います。「Next」と「Previous」は次へと前へで、へ助詞が自然な方向感を与えます。素の次と前だと唐突に読まれます。
| 英語のページネーションラベル | 推奨される日本語 | 備考 |
|---|---|---|
| 1–20 of 348 | 348件中 1〜20件 | 合計が先で範囲が後——英語の語順と逆。範囲には波ダッシュ（〜）を使います。 |
| Rows per page | 表示件数 | スペースがある場合は1ページあたりの表示件数。件が行カウンターです。 |
| Next / Previous | 次へ / 前へ | へ助詞が自然な方向感を加えます。素の次 / 前だと唐突に読まれます。 |
| Page 3 of 18 | 18ページ中 3ページ目 | 目で序数にします（「3ページ目」）。合計優先の語順で範囲ラベルと統一。 |
| Showing all 348 results | 全348件を表示 | 全（「すべて」）＋件カウント。結果は不要——件が既にレコードを意味しています。 |
数値と日付の列にはそれぞれ独自の慣習があります。通貨列は円単位を使い、大きな数値は漢数字のグルーピング期待があります。オーディエンスが財務担当者の場合は万グルーピングで表示することが多いです（12,500,000ではなく1,250万）ただし、カンマ形式は生のトランザクショングリッドでは許容されます——列がサマリーか台帳かによって選択が変わります。数値は右揃えです。どのテーブルでも同様ですが、レイアウト移植中に数値列が左揃えに変わっていないか確認します。左揃えになっていると日本の経理担当者には壊れているように見えます。日付列は日本語の順序を使います——2026/05/31または2026年5月31日（05/31/2026は使いません）。同じ列の中でISO形式の日付とローカライズされた日付が混在しているとエンタープライズ評価でただちに問題として指摘されます。
この14項目チェックリストは、多くのチームが見落とすテーブルレベルの判断をカバーしています。日本語ミニ診断（Mini Audit）では、ヘッダーのはみ出しと語中折り返し、絞り込みvsフィルターの一貫性、一括操作のカウンター文法、エンプティと不一致状態の区別をグリッド全体で検証します。ほとんどの製品は14項目のうち5〜9項目に課題が見つかります。
ミニ診断を依頼する日本語データテーブルのフィルターコントロールには絞り込みとフィルターのどちらを使うべきですか？
行を条件で絞るアクションには、絞り込みが日本のビジネスソフトウェアで定着した用語であり、ネイティブに読まれます。フィルターは認知されており、英語由来の用語が期待される開発者向けやアナリティクス向けツールでは許容されますが、一般的なエンタープライズSaaSでは絞り込みがより安全な選択です。避けるべき誤りはフィルタリングをボタンラベルとして使うことです——これは動名詞形であり、コントロールラベルではなく「フィルタリングを行っている」という直訳として読まれます。コントロールには絞り込みを使い、適用アクションにはフィルタを適用または絞り込むを使います。
英語の列ヘッダーを日本語テーブル向けに短縮するにはどうすればよいですか？
日本語の文字はラテン文字より幅が広く、テーブルはスペースが制限されているため、日本語の列ヘッダーはデータが許す限り短くする必要があります。「Last Updated」は、実際にタイムスタンプが表示される列でなければ更新日または最終更新とし、最終更新日時にはしません。「Created Date」は登録日または作成日にします。冗長な語を省きます。Status列はステータスまたは状態であり、ステータス状況とはしません。どちらも存在する場合は、カタカナ表記より漢字の複合語を優先します。漢字は1文字あたりの情報密度が高いからです。
日本語の列ヘッダーの折り返しはどのように発生し、不適切な改行を防ぐにはどうすればよいですか？
日本語にはスペースがないため、制御しないとブラウザは任意の文字間でヘッダーを折り返します。最終ログイン日時というヘッダーが最終ログ / イン日時と折り返されることがありますが、これは日本語読者には壊れた表示に見えます。非折り返しアプローチを使います——ヘッダーを1行に収まる長さに保つか、ワードジョイナー制御文字やCSSのword-breakルールを挿入して意味のある境界で折り返すようにします（最終ログイン / 日時）。2行ヘッダーの場合は、ブラウザに任せるのではなく意図的に改行位置を設計します。
テーブル上部の一括操作ボタンに適切な日本語の表現は何ですか？
一括操作ボタンは、ユーザーが実行しようとするアクションを動詞で示し、多くの場合選択件数を含めます。「3 selected · Delete」は3件を選択中の横に削除ボタン、または選択した3件を削除となります。すべてのボタンに一括をプレフィックスとして付けることは避けます——一括削除は一括性が強調ポイントである場合に適切ですが、現在の選択に対して操作するボタンには削除だけの方がすっきりして読みやすいです。行またはレコードのカウンターには件を使い、個やつは使いません。
テーブル内のエンプティステートとローディングステートを日本語でどのように書くべきですか？
3つの状態を区別します。レコードがまだ存在しない真のエンプティテーブルはデータがありませんまたはまだデータがありませんと表示します。一致するものがないフィルター結果は条件に一致するデータがありませんと表示し、テーブルが壊れているのではなくユーザーのフィルターを認識した表現にします。ローディングステートはです/ます体で読み込み中...またはデータを取得していますと表示し、翻訳されていない「Loading...」は使いません。エンプティ状態と不一致状態を混同することが最も多いエラーで、ユーザーがデータが失われたと勘違いします。