レビューを依頼する
日本語ローカライゼーションプロセス · 用語管理 · 品質

日本語ローカライゼーション用語集の作り方:
一貫したSaaS翻訳のための用語管理

用語の不統一は、日本語SaaSローカライゼーションで最も多い品質クレームです。製品がナビゲーションでは「ダッシュボード」、ヘルプセンターでは「管理画面」、オンボーディングメールでは「コントロールパネル」を使っていると、日本語ユーザーは気づきます——そしてその不統一は「自分たちのために作られた製品ではない」というシグナルとして読み取られます。よく設計された用語集は、この種の誤りをまるごと取り除きます。

Munehiro Hiraki
平木 宗大(ひらき むねひろ)
日本語ローカライゼーションQAスペシャリスト
2026年6月4日 読了時間 9分 日本語ローカライゼーションプロセス
クイックアンサー
用語の不統一は、なぜ英語より日本語で深刻なのですか?
日本語は同じ概念に複数の有効な文字種・同義語を持ちます(例:ダッシュボード vs 管理画面 vs コントロールパネル)。そのため用語集がないと、同じ機能が3通りに命名されてしまい——英語の同程度のばらつきよりも早く信頼を損ないます。
「dashboard」の正しい日本語訳は?
唯一の答えはありません——ダッシュボード、管理画面、コントロールパネルはどれも使われています。要は、自社製品向けに一つを決め、用語集に記録し、翻訳者が場当たり的に選ぶのではなく、どこでも適用することです。
日本語ローカライゼーション用語集には何を入れるべきですか?
各エントリには6つのコアフィールド(原語、承認済みの日本語訳、文字種の判断、品詞・文脈、使用禁止の異形、メモ)が必要です。最も一般的なSaaS用語の上位約20語から始めると、最もリスクの高い不統一から先に押さえられます。

TL;DR

日本語の用語の不統一は、英語より大きなダメージになります。日本語には3つの文字種と複数の敬体レベルがあり、ひとつの概念に対する「誤りの面積」がはるかに広いからです。日本語ローカライゼーション用語集は、UI用語・製品固有の名詞・禁止代替語・トーン規則を網羅しなければなりません。まずはコア50語から。ベンダー共有にはTBX形式を使います。徹底は「性善説」ではなく、CATツール統合で行います。「dashboard か 管理画面 か」の判断は、その代表例です——一つを選び、文書化し、徹底し、製品デザインが明確に変わったときにのみ見直します。

キーポイント

  • 日本語は英語より「不統一の面積」が広い——3つの文字種と複数の敬体レベルがあるため、ひとつの用語がより多くの誤った形で現れえます。だからこそ、不統一に対するクレームは日本語でより頻繁かつ目立つのです。
  • 用語集には禁止代替語を含めなければならない——承認済みの用語だけを載せるのでは不十分です。何が禁止か(ダッシュボード を選んだなら 管理画面 は禁止)を明示的に文書化しないと、翻訳者やライターは気づかぬうちに禁止形を持ち込みます。
  • カタカナか漢字かの判断は2つの問いに従う——日本語のビジネスソフトで確立した漢字の形があるか? あるなら漢字。自然な漢字の対応語を持たない借用技術用語か? ならカタカナ。一律のルールを当てはめてはいけません。
  • 500語ではなく、コア50語から始める——最も目立つ面を網羅し、実際に徹底される用語集は、無秩序に膨らむ網羅的な用語集に勝ります。ワークフローが回り始めてから拡張しましょう。
  • TBXが正しいベンダー形式——CATツール(Phrase、memoQ)と直接統合し、事後レビューではなく翻訳メモリのレベルで用語集を徹底します。

なぜ日本語の用語の不統一は英語より大きなダメージになるのか

英語では「dashboard」は一つの形・一つの綴りしかありません。これに同意しない翻訳者が「control panel」と書くことはあっても、それは一つの代替にすぎません。日本語では、同じ概念を ダッシュボード(カタカナ)、管理画面(漢字熟語で「管理する画面」の意)、コントロールパネル(より長いカタカナ)、ダッシュ(短縮したカタカナ)、管理ページ(漢字+英語由来の「ページ」)と表現できます。それぞれが異なるニュアンスを帯びます。そして一つを製品の用語として選んだなら、ほかはすべて「誤り」になります。

文字種による掛け算の効果が、問題の核心です。日本語の用語はどれも少なくとも漢字とかなの読みを持ち、多くの技術用語はさらに英語化されたカタカナの形を持ちます。用語集なしで作業する翻訳者は、承認済みの用語に対する「一つの代替」に出くわすのではありません——もっともらしい選択肢の「群れ」に出くわすのです。そしてプロの翻訳者は、自分の経歴・想定読者の印象・製品への習熟度に応じて、それぞれ異なる選択をします。一つの選択を強制する用語集がなければ、製品全体での不統一は「可能性」ではありません——「確実」です。

3+
用語集の判断が下される前、ほとんどの英語SaaS UI用語に対してもっともらしい日本語の形の数
50
最初の版の日本語ローカライゼーション用語集に推奨されるコア用語数——ワークフローを圧迫せずに目立つ面を網羅できる規模
TBX
用語集をCATツールに直接統合し、翻訳時点で用語を徹底させるISO標準形式

日本語ユーザーはまた、英語の読者が同義語のばらつきを読む以上に、文字種の不統一を鋭く「品質のシグナル」として読み取ります。日本語ユーザーが製品のナビで ダッシュボード、ヘルプセンターで 管理画面、アプリ内ツールチップで ダッシュ を見ると、その不統一は単に用語の問題にとどまりません——「これらの面は別々の人が書き、誰も一貫性をレビューしなかった」というシグナルになるのです。B2Bの調達の文脈では、これは「このベンダーの製品はエンタープライズ利用に耐えるほど成熟しているのか」という疑問を生むタイプのシグナルです。

日本語ローカライゼーション用語集に入れるべきもの

日本語ローカライゼーション用語集は、辞書でもスタイルガイドでもありません——両者と重なる部分はありますが。それは「用語レベルの徹底のための文書」です。各エントリについて、次の問いに答えます。承認済みの日本語訳は何か、どう読むか、どこで使うか、どの代替が禁止か、文脈での用例はどうなるか。これらのフィールドのどれかを欠いた用語集は不完全で、その隙間から不統一を生みます。

日本語ローカライゼーション用語集に入れるべきコンテンツは、次の4カテゴリです。

  1. UI用語:製品インターフェースに現れるすべてのラベル——ナビゲーション項目、ボタンテキスト、ダイアログの見出し、ステータスラベル、エラー状態。これらは最も視認性の高い用語であり、不統一が最も大きなダメージを与える用語でもあります。毎セッション表示され、ユーザーが同僚に共有するすべてのスクリーンショットに写り込むからです。
  2. 製品固有の名詞:自社製品に固有で、一般的な日本語の対応語を持たない機能名・ワークフロー名・オブジェクト名。これらには、日本語訳・カタカナ転写・英語のまま残す、のいずれかという判断がしばしば必要になります。いったん決めたら、その判断は文書化し、一貫して徹底しなければなりません。
  3. 禁止代替語:承認済みの用語にはどれも、使うべきでないもっともらしい代替が少なくとも一つあります。用語集はそれらを明示的に列挙し、禁止としてフラグを立てなければなりません。このフィールドがないと、新しい翻訳者やライターはその概念に出くわし、用語集に見つけられず、新たに選んでしまいます——それが、相応の理由で却下された禁止代替語と一致するかもしれないのです。
  4. トーン規則:複数の用語に影響する敬体レベルの判断——たとえば、製品全体で です/ます を使うのか、特定の文脈ではよりカジュアルな敬体に切り替えるのか、敬語がふさわしい場面はあるのか(フォーマルな通知など)、UIラベルとドキュメントで命令的な指示をどう扱うか、といったことです。

ダッシュボード問題:ダッシュボード vs 管理画面 vs コントロールパネル

「dashboard」をどう訳すかという問いは、日本語の用語決定における代表的なケースであり、どの日本語ローカライゼーションプロジェクトもこれに直面します。主な3つの選択肢は、それぞれ異なるニュアンスを帯び、ユーザーの理解と製品のポジショニングに影響します。

ダッシュボード は「dashboard」のカタカナ転写です。日本語SaaS製品でメインの概要画面を指す語として最も広く使われています。製品固有でモダンな印象を与えます。画面が何をするかという機能の説明は帯びていません——あなたの製品を使ったことのないユーザーは、この語だけからは ダッシュボード に何が含まれるかわかりません。これはまさに英語で Dashboard が機能している通りです。機能の説明ではなく、製品画面の固有名なのです。ダッシュボード中心の設計を持つ多くのSaaS製品にとって、ダッシュボード が正しい選択です。

管理画面(かんり がめん——management screen)は機能を説明する語で、多くの日本語ユーザーが管理用インターフェース全般を指す一般語として使います。画面を名づけるのではなく、何をするかを説明する語です。そのためヘルプコンテンツでの一般的な言及(「管理画面で」)には便利ですが、製品の用語としては問題があります。画面を製品の特定の名前付き要素として特定するのではなく、その機能を含意してしまうからです。管理画面 を製品の用語に使うと、自社製品のダッシュボードと、一般的な「管理エリア」という概念とを区別しにくくもなります。

コントロールパネル(control panel のカタカナ)は古め・エンタープライズのインフラ寄りの印象です。サーバー管理やレガシーソフトウェアの連想を帯びます。製品が明示的にインフラ管理ソフトで、この連想がふさわしい場合を除き、コントロールパネル はモダンなSaaS製品にとって時代遅れに読まれます。

不統一(同じ製品に3つすべて)
ナビ:ダッシュボード
ヘルプセンター:管理画面
オンボーディングメール:コントロールパネル
同じ画面に3つの用語。3つの面すべてを読む日本語ユーザーは、不統一を「製品の成熟度のシグナル」として受け取ります。
統一(用語集で徹底、ダッシュボードを採用)
ナビ:ダッシュボード
ヘルプセンター:ダッシュボード
オンボーディングメール:ダッシュボード
一つの用語、すべての面で。用語集のエントリは、判断理由のメモとともに 管理画面 と コントロールパネル を禁止代替語として記します。

カタカナ vs 漢字の判断フレームワーク

日本語の用語集の判断にはどれも文字種の選択が絡みます。そして、この選択のためのフレームワークを持たないチームは、一貫性のない用語集を生みます——ここはカタカナ、あそこは漢字、どちらにも明確な原則がない、という具合に。以下の2問のフレームワークが、大半のケースをすっきり解決します。

問い1:その用語は日本語のビジネスソフトウェアで使われる、確立した漢字の形を持つか? 持つなら、漢字を使います。設定(Settings)、権限(Permissions)、連携(Integrations/Connections)、招待(Invitation)、承認(Approval)、通知(Notification)は、いずれも日本語のビジネスユーザーが日々目にする、確立した漢字の形を持ちます。これらの用語にカタカナを使う——セッティング、パーミッション、インビテーション——のは、くだけた・よそよそしい・あるいは誤った印象に読まれます。

問い2:その用語は、ソフトウェアを通じて日本語に入ってきた借用語や製品概念で、自然な漢字の対応語を持たないか? そうなら、カタカナを使います。ダッシュボード(Dashboard)、テンプレート(Template)、ワークフロー(Workflow)、インテグレーション(製品概念としてのIntegration)、アナリティクス(Analytics)は、いずれもソフトウェアとともに到来し、日本語ユーザーが実際に使う漢字の形を持ちません。これらの用語に無理に漢字を当てる——Dashboard に 制御盤、Template に 型板——と、奇妙、あるいは古めかしく読まれる結果になります。

難しいのは、両方の形が市場で流通している用語です。連携(漢字)と インテグレーション(カタカナ)はどちらも「integration」を意味し、どちらも日本語SaaS製品に現れます。この場合、B2B向けにはほぼ常に漢字の形のほうが安全な選択です——より精確で、よりネイティブに読まれます。例外は、あなたの製品カテゴリがカタカナの形に明確に収束しているときです。もしカテゴリ内のどの競合製品も インテグレーション を使っているなら、その慣習に合わせることが、漢字優先の原則より重要になりうるのです。

用語集の構造:6つの必須フィールド

日本語ローカライゼーション用語集のエントリが実用的であるためには、6つのフィールドが必要です。フィールドの少ないエントリは翻訳者から質問を生み、明確な答えを見つけられないライターからは無視されます。

  1. 原語(英語):英語版の製品に現れる、そのままの文字列。
  2. 日本語訳:承認済みの日本語訳を、正しい文字種で。
  3. 読み:日本語訳のひらがなの読み。漢字を含む用語には必須です。翻訳者やライターが、正しい同音異義語を選べているか確認する必要があるからです。
  4. 用法メモ:その用語がどこで使われるか、どの敬体が当てはまるか、文脈固有のばらつき(たとえば、ナビでは名詞として現れ、手順説明では動詞の語幹として現れる用語など)を1〜2文で説明します。
  5. 禁止代替語:使ってはならない具体的な日本語の形を、それぞれなぜ却下されたかの一行メモとともに記します。最も省略されがちで、最も用語集の乱れの原因になるフィールドです。
  6. 文脈での用例:その用語が正しく使われている例文を1〜2。このフィールドがあると、追加の説明なしに用語集が使えるようになり、翻訳者からの質問が減ります。

サンプル用語集テーブル:一般的なSaaS用語20語

英語 日本語 読み 禁止 用法メモ
Dashboard ダッシュボード だっしゅぼーど 管理画面、コントロールパネル 製品の画面名。カタカナのみ。ダッシュ と略さない。
Settings 設定 せってい セッティング、オプション 漢字。ナビのラベルおよびセクション見出し。常に名詞形(設定する は本文中のみ、ラベルでは使わない)。
User ユーザー ゆーざー 利用者、使用者 カタカナ。標準的なSaaS用語。利用者 は利用規約・法務テキストでのみ許容。
Invitation 招待 しょうたい インビテーション、誘い 漢字。ワークスペース/チームへユーザーを招くときに使用。動詞文脈では 招待する。
Permission / Role 権限 けんげん パーミッション、アクセス権限(ロール文脈の場合) 漢字。文脈上 permission と role が同義のときは、両方に 権限 を使う。製品に別個のロール概念がある場合にのみ 役割(role)を区別する。
Workspace ワークスペース わーくすぺーす 作業スペース、チームスペース カタカナ。製品固有のコンテナ。製品機能が明示的に Workspace と名づけられている場合にのみ使用。
Integration 連携 れんけい インテグレーション(製品セクション名の場合を除く) B2B文脈では漢字を推奨。インテグレーション は、それが表示上のUIラベルである場合に限り、製品セクション名としてのみ許容。
Notification 通知 つうち ノーティフィケーション、お知らせ(UIラベル文脈) 漢字。お知らせ はブログ/告知セクションには許容、システム通知のUIラベルには不可。
Template テンプレート てんぷれーと ひな形、書式 カタカナ。標準的なSaaS用語。ひな形 は、非SaaS層を対象とした文書作成の文脈でのみ許容。
Workflow ワークフロー わーくふろー 作業フロー、業務フロー カタカナ。製品の機能名。業務フロー はオペレーション部門の購買担当を狙うマーケコピーでは許容、UIラベルでは不可。
Analytics アナリティクス あなりてぃくす 分析(ナビのラベルとして) 製品セクションにはカタカナ。分析 は概念を説明する本文では許容、製品デザイン上の用語でない限りナビや見出しのラベルとしては不可。
Plan (pricing tier) プラン ぷらん 料金体系、コース カタカナ。料金プラン名に使用(スタータープラン、プロプラン)。コース は教育的な含みがある。
Subscription サブスクリプション さぶすくりぷしょん 定期購読(メディア製品の場合を除く) カタカナ。標準的なSaaS課金用語。くだけたコンテンツでは サブスク と略されがち——UIラベルでは避け、ブログ/マーケでは許容。
Export エクスポート えくすぽーと 書き出し(UIラベル文脈) UIのボタン・メニューラベルにはカタカナ。書き出し はクリエイティブ系ソフトの文脈では許容、B2B SaaSのデータエクスポート文脈では不可。
Import インポート いんぽーと 読み込み(UIラベル文脈) UIラベルにはカタカナ。読み込み はファイル読み込みの状態(ローディング表示)には許容、インポートのアクションラベルには不可。
Archive アーカイブ あーかいぶ 保管、格納 カタカナ。動詞用法:アーカイブする。可逆的な製品アクションではなく、物理的・長期的な保存を含意する 保管(storage)は使わない。
Approval 承認 しょうにん アプルーバル、許可(承認ワークフロー文脈) 漢字。承認ワークフローのアクションの標準語。許可(permission/allow)は別概念であり、互換的に使ってはならない。
Comment コメント こめんと 意見、コメント欄(機能名として) カタカナ。コメント機能および個々のコメントオブジェクトに使用。コメント欄 はUIの入力エリアであり、機能名ではない。
Tag タグ たぐ ラベル(製品が Tag を機能名に使う場合) カタカナ。製品機能が Tag なら タグ を一貫して使う。製品が Label と呼ぶなら ラベル を一貫して使う。混在させない。
Log out / Sign out ログアウト ろぐあうと サインアウト(Google/Apple経由でサインインする製品を除く——その慣習に合わせる) カタカナ。セッション終了の標準語。製品が Sign In/Sign Out(Googleアカウント連携)を使う場合は、全体を サインイン/サインアウト に合わせる。

製品の進化に合わせて用語集を保守する

プロジェクト立ち上げ時に書かれ、その後一度も更新されない用語集は、2年以内に、製品の中で最も確実な不統一の発生源になります。製品の機能は名前を変え、UIラベルは変わり、新しい機能カテゴリが導入され、競合は異なる用語に収束してユーザーの期待に影響を与え始めます。保守ワークフローがなければ、用語集は製品の実態から乖離し、そのズレに気づいた翻訳者やライターは、用語集を迂回して作業し始めます。

3つのトリガーが、用語集のレビューサイクルを開始させるべきものです。機能のリネーム、大規模なUIの再構成、そして既存の用語集でカバーされていない新しい機能カテゴリの導入。これらはいずれも、用語集のエントリなしに新しい用語が導入される「窓」を作り出します。そして、その窓こそが、不統一が積み重なる瞬間です。

小〜中規模のローカライゼーションプログラムにとって、実践的な保守アプローチは「四半期ごとの用語集監査」です。現在の用語集を製品のライブな日本語UI文字列と突き合わせ、UI内にあって用語集にない、あるいは用語集のエントリと異なる用語を洗い出し、エントリを追加・更新します。この四半期サイクルはリアルタイムの保守より遅いものの、大きな不統一の問題を生む「2年の乖離」よりは速いのです。

用語集のツール:TBX、CAT統合、ベンダー共有

Googleスプレッドシートとして存在し、翻訳者にPDF添付として共有される日本語ローカライゼーション用語集は、用語集ではありません——翻訳者が開くことを覚えていれば、そして開いたときに最新であれば、参照する文書にすぎません。効果的な用語集管理には、ツールのレベルで翻訳ワークフローと統合することが必要です。

業界標準の形式は TBX(TermBase eXchange)です。ISO標準のXML形式で、CATツール(Phrase、memoQ、SDL Trados、Memsource)が直接インポートでき、翻訳中に規約違反の用語をフラグするのに使えます。TBX用語集を読み込んだ memoQ で作業する翻訳者は、ダッシュボード が承認済みで 管理画面 が禁止として記載されている場合、「Dashboard」を 管理画面 と訳すと警告を目にします。この徹底は事後レビューではなく翻訳時点で起こります——不統一を最も安く直せるタイミングです。

CATツールを使わないベンダーとの共有には、同じ6フィールドを持つタブ区切りCSVが実用的な代替です。Excelは実務で広く使われていますが、マスター形式としては推奨しません——バージョン管理を欠き、翻訳ワークフローと統合できず、複数人が編集すると形式の乱れを生みます。マスターはTBXまたは Phrase TMS や TermWeb のような用語管理システムで保守し、人によるレビューのサイクル向けにのみ Excel や PDF へ書き出しましょう。

最初の用語集をゼロから作る:コア50語

日本語ローカライゼーションプログラムに用語集がない最も多い理由は、最初のスコープが圧倒的に感じられることです。成熟したSaaS製品の完全な用語集は数百エントリに及ぶこともあり、用語を一つ書く前に製品全体を監査するという見通しが、チームを無期限の先延ばしへと向かわせます。正しい出発点はコア50語です——製品全体の監査を必要とせずに、最も目立つ面を網羅できる規模です。

この50語は、5つのカテゴリから、おおよそ均等な比重で選びます。

  • 最上位のナビゲーションラベル(8〜10語):グローバルナビの項目。すべてのページに現れ、ユーザーが他のすべての面に持ち込む用語の期待を形づくります。
  • 主要なアクションボタンとCTA(8〜10語):保存、キャンセル、確定、削除、招待、エクスポート、インポート、送信——製品全体でユーザーのアクションを駆動する動詞。
  • コア機能名(10〜15語):あなたの製品を定義する2〜5の機能と、その中のサブ機能。製品がプロジェクト管理ツールなら、プロジェクト、タスク、マイルストーン、ボード、スプリントなど。
  • エラー・ステータス状態(5〜8語):エラー、警告、成功、読み込み中、保留中、アーカイブ済み、下書き、公開済み。製品全体・すべての面に現れます。
  • 出現頻度の高いヘルプセンター用語(10〜12語):KB記事のタイトルや手順説明に最も頻繁に現れる用語。多くはナビのラベルと同じですが、製品によってはより技術的な用語を含むことがあります。
最も高くつく日本語ローカライゼーション用語集は、一度も書かれなかった用語集です。製品の日本語の面にまたがる不統一は、個別の品質レビューでは直りません——用語が選ばれ、徹底される地点で、体系的にしか直せないのです。CATツール統合で徹底された50語の用語集は、翻訳者が受け取って一度も開かない500語のスプレッドシートよりも価値があります。

あなたの日本語製品は、一貫した用語を使えていますか?

日本語用語監査は、ナビ・UI・ヘルプセンター・マーケティングの各面にまたがる不統一を洗い出し、優先順位づけされた修正リストと、再発防止にチームが必要とする用語集エントリの初稿を作成します。多くの製品は、最初の監査の前に15〜40件のアクティブな不統一を抱えています。

ミニ診断を依頼する

日本語ローカライゼーション用語集チェックリスト

📋

用語集のコンテンツと構造

  • 6つの必須フィールドが揃っている:すべてのエントリに、原語、日本語訳、読み(ひらがな)、用法メモ、禁止代替語、文脈での用例がある。いずれかを欠くエントリは、補完のためにフラグを立てる。
  • 禁止代替語が列挙されている:承認済みの用語にはどれも、一行の理由つきで明示的に禁止された代替が少なくとも一つある。このフィールドは任意ではない。
  • カタカナ/漢字の判断が文書化されている:両方の形がもっともらしいエントリには、なぜ一方を選んだかを説明するメモがある。判断は前提とするのではなく、文書化する。
  • 製品固有の名詞が網羅されている:自社製品に固有のすべての機能名が用語集にある。日本語版製品に残した英語の用語も含む。
🔧

ツールと徹底

  • ベンダー統合のためのTBX形式:用語集がTBX形式、またはTBXを書き出せる用語管理システムに存在する。翻訳ベンダーが使うCATツールに用語集が読み込まれている。
  • 禁止用語がCATツールでフラグされる:TBXファイルが禁止代替語を記し、翻訳者が使うと警告が出る。徹底は事後レビューではなく翻訳時点で起こる。
  • 四半期監査がスケジュールされている:用語集とライブUIを四半期ごとに突き合わせるカレンダーイベントがある。監査の担当者が決まっている。エントリ更新のプロセスが文書化されている。
  • 変更トリガーが定義されている:計画外の用語集レビューを起こす3つのトリガー(機能のリネーム、大規模なUIの再構成、新しい機能カテゴリ)が文書化され、レビューの担当者が決まっている。
👥

スコープと網羅

  • 拡張前にコア50語を完成させる:最初の用語集は、副次的な面へ拡張する前に、5つの優先カテゴリ(ナビのラベル、主要なCTA、コア機能名、エラー状態、出現頻度の高いKB用語)を網羅する。
  • トーン規則が文書化されている:用語集または付随するスタイルメモに、製品の敬体の判断が文書化されている。です・ます(丁寧体)かカジュアルか、敬語を使う文脈(あれば)、UIラベルで命令的な指示をどう扱うか。
  • 一貫性監査が完了している:用語集を公開する前に、ライブな日本語版製品を横断して検索し、承認済みの用語が現在のUI文字列と一致することを確認する。不一致は、用語集を共有する前に解消する。

よくある質問

用語の不統一は、なぜ英語よりも日本語で大きなダメージになるのですか?

英語では「dashboard」という語は一つの形しかありません。日本語では、同じ概念を ダッシュボード(カタカナ)、管理画面(漢字熟語)、コントロールパネル(より長いカタカナ)と表現できます。それぞれの形が少しずつ違うニュアンスを帯びます。製品がこの3つを区別なく混用すると、日本語ユーザーはすぐに不統一に気づき、「詰めの甘さ」として受け取ります。日本語には3つの文字種と複数の敬体レベルがあるため、ひとつの用語が不統一に表記されうるパターンの数は英語よりはるかに多く、不統一に対するクレームもそれだけ頻繁かつ目立ちます。

「dashboard」の正しい日本語訳は何ですか?

唯一普遍的に正しい答えはありません。だからこそ、用語集での意思決定が必要になります。ダッシュボード は日本語SaaS製品で最も広く使われる語で、その製品ならではのUI要素として読まれます。管理画面 は機能を説明する語で、多くのユーザーが管理画面全般を指す一般語として使います。コントロールパネル は古め・エンタープライズのインフラ寄りの印象です。おすすめは、ダッシュボード を主要な用語集エントリとして選び、どこでも一貫して使い、管理画面 と コントロールパネル を禁止代替語として記し、その判断理由を注記しておくことです。

日本語ローカライゼーション用語集では、ある用語にカタカナと漢字のどちらを使うべきですか?

判断の枠組みは2つの問いです。第一に、その用語は日本語のビジネスソフトウェアで確立し、広く使われている漢字の形を持つか。持つなら漢字を使います。設定(Settings)、権限(Permissions)、連携(Integrations)、招待(Invitation)。第二に、その用語はソフトウェアを通じて日本語に入ってきた借用語や製品概念で、自然な漢字の対応語を持たないか。そうならカタカナを使います。ダッシュボード(Dashboard)、テンプレート(Template)、ワークフロー(Workflow)。両方の形が流通している場合、B2B向けではほぼ常に漢字のほうが安全な選択です。

日本語ローカライゼーション用語集は、最初にいくつの用語を収録すべきですか?

最初の版の日本語ローカライゼーション用語集は、コアとなる50語を目標にするとよいでしょう。最も目立つUI面を網羅できる一方で、用語集がその価値を証明する前から保守の負担になりすぎない規模です。50語は次の優先順位で選びます。最上位のナビゲーションラベル(8〜10)、主要なアクションボタンとCTA(8〜10)、コア機能名(10〜15)、エラー・ステータス状態(5〜8)、出現頻度の高いKB・オンボーディング用語(10〜12)。これらが確立し、保守ワークフローが回り始めたら、用語集はエッジケースや副次的な機能へと拡張できます。

翻訳ベンダーと共有するとき、日本語ローカライゼーション用語集はどのファイル形式を使うべきですか?

業界標準の形式は TBX(TermBase eXchange)です。ISO規格であり、ほとんどのプロ向けCATツール(Phrase、memoQ、SDL Trados、Memsource)が直接インポートできます。TBXは日本語用語集に必要なフィールド——原語、訳語、読み、用法メモ、禁止代替語、文脈例——をすべてサポートします。CATツールを使わないベンダー向けには、同じフィールドを持つタブ区切りCSVが実用的な代替です。マスターはTBXまたは用語管理システムで保守し、人によるレビューのサイクル向けにのみExcelへ書き出します。

日本語の用語管理

あなたの日本語製品は、一つの声で語っていますか——それともバラバラですか?

ナビ・UI・ヘルプセンター・マーケティングの各面にまたがる用語の不統一は、日本語ユーザーが読み取る最も目立つ品質のシグナルです。用語監査は不統一を洗い出し、正しい判断を文書化し、再発防止に翻訳チームが必要とする用語集の初稿を作成します。