日本語UIの文字数制限：
プロダクトチームのための実践ガイド

▶ 60秒スライドサマリー この記事を10枚のスライドで読みたい方はこちら。60秒でチェックできます。 スライドを見る →

要約（TL;DR）

日本語のUIテキストは一様には拡張しません。デザインシステムが想定していない形で拡張します。漢字グリフはラテン文字より視覚的に重く、ボタンラベルは文字数は少なくてもピクセル幅は広くなります。また、フォームラベルは長くなりがちです。コンポーネントごとの文字数制限を設けずに日本語版を出したプロダクトチームは、CTAが切り詰められ、ナビゲーションが崩れ、コンバージョンに直結する画面でユーザーが黙って離脱するという事態に直面します。

重要ポイント

• 拡張は一様ではない — 日本語は英語の文字数比で0.5〜0.7倍になりますが、全角グリフのためピクセル幅は1.0〜1.3倍になります。
• ボタンが最も問題になりやすい — 「Get started」向けに設計された固定幅CTAには、「無料で始める」が収まらないケースが多く、折り返しや切り詰めが発生します。
• フォームラベルは長くなる — 日本語のフォームラベルは、英語の同等表現と比べて1.5倍の横幅が必要になることが少なくありません。
• コンポーネントごとに上限を指定する — 翻訳者に渡すローカライズ仕様書には、文字数制限だけでなく最大ピクセル幅も記載しましょう。
• 実際のUIでQAを実施する — スプレッドシート上では収まる文字列が、本番では崩れることがあります。文字列リストではなく、UIのコンテキストの中で必ずレビューしてください。

日本語UIが英語ベースのレイアウトを壊す理由

ほとんどのSaaSプロダクトは英語で先にデザインされます。そのデザインには、文字幅・行高・単語の区切り・テキストがどのように折り返されるかについて、暗黙の前提が埋め込まれています。日本語は、その言語を読まないデザイナーには見えない形で、こうした前提のほぼすべてを崩してしまいます。

日本語は漢字・ひらがな・カタカナの3つの文字体系を混在させて使います。それぞれの文字はラテン文字2文字分ほどの横幅を持つ全角セルを占有します。英語6文字の「Login」が日本語では「ログイン」（3文字）になりますが、これは短く聞こえても横幅はほぼ変わりません。文字数とピクセル幅は別の話をしています。文字数だけを追いかけているプロダクトチームは、日本語UIの横幅を体系的に過小評価しています。

これは見た目だけの小さな問題ではありません。CTAが切り詰められるとクリック数が落ちます。ナビゲーションの項目がモバイル画面からはみ出すと、メインのアクションが見えなくなります。2行に折り返されたフォームラベルは、サインアップの複雑さを実際より高く感じさせます。そしてこれらの問題のほとんどは、ローカライズの過程でひっそりと入り込みます。デザインレビューでも、QAでも検出されず、諦めた日本語ユーザーに初めて発見されます。

実数値：日本語テキストの拡張がどう機能するか

最もよくある混乱の原因は「拡張率」です。多くのSaaS企業の内部資料には「日本語は英語の1.2倍に拡張する」といった単一の数値が記載されていますが、実際の製品文字列に当てはめると途端に崩れます。

拡張率は3つの変数に依存します。ソースのコンテンツタイプ・ターゲットの文字列スタイル・何を計測しているか（文字数かピクセル数か）です。SaaSの一般的な文字列カテゴリーごとに、実際の数値を示します。

文字列タイプ	英→日 文字数比	英→日 ピクセル幅比	備考
ボタンラベル（CTA）	0.4〜0.7倍	1.0〜1.4倍	文字数は少ないが、1文字あたりの幅が広い。最も多い崩れの発生箇所。
ナビメニュー項目	0.5〜0.8倍	1.0〜1.3倍	幅の広い漢字は意味を圧縮できるが横幅を消費する。
フォームラベル	0.6〜1.0倍	1.1〜1.5倍	丁寧な表現（お名前・ご住所）は敬称接頭辞が加わり幅が増える。
エラーメッセージ	0.8〜1.3倍	1.0〜1.4倍	丁寧な語尾（〜ください・〜してください）が短い警告に長さを加える。
本文段落	0.5〜0.8倍	0.9〜1.1倍	1行あたりの密度が高くなる。レイアウト上の問題になることはほぼない。
ヘルプセンター記事	0.5〜0.7倍	0.9〜1.0倍	通常、レイアウトによる制約を受けない。

パターンは一貫しています。文字列が短くなるほど、ピクセル幅の拡張が深刻になります。単語1語のCTAが最もリスクの高いカテゴリーです。長文の本文コンテンツがレイアウトを壊すことはほとんどありません。これはほとんどのエンジニアリングチームの想定と逆です。

SaaS UIで日本語の文字数制限が最も響く箇所

B2B SaaSプロダクトにおける日本語ローカライズの崩れは、5つのUIコンポーネントに集中しています。私はこうしたプロダクトを何十件もレビューしてきましたが、崩れる箇所はいつも同じです。ローカライズ開始前のデザイン段階で見つければ、本番上の問題のほとんどは防げます。

1. プライマリCTAとサインアップボタン

固定幅のプライマリボタンは、8〜14文字の英語の動詞表現向けに設計されています。日本語の対応表現は入らないことも多く、無理に入れようとすると不格好になります。フォントサイズを縮小したり2行に折り返したりといった回避策は、見た目を損ない、クリック率を下げます。

2. トップナビゲーション

5〜7項目を固定間隔で並べたナビゲーションバーは、日本語モバイル画面でオーバーフローしがちです。「Pricing」（7文字）が「料金プラン」（5文字だが視覚的に広い）になり、「Get a demo」は簡単には圧縮できない複数単語の表現になります。

3. フォームラベルとフィールドのプレースホルダー

日本語のフォームラベルは、B2Bコンテキストでは丁寧さを示すために敬称接頭辞（お、ご）を使います。「Name」が「お名前」になり、ほとんどのレイアウトで英語より横幅が広くなります。短い英語ラベルを想定した2カラムのフォームレイアウトは、日本語では縦積みレイアウトに切り替える必要があることが多いです。

4. 空のステートとオンボーディングツールチップ

短い空のステートメッセージ（「No projects yet」）は日本語では長くなります（「プロジェクトがまだありません」）。特定のUI要素を指すツールチップの矢印は、特定のバブル幅を前提としています。日本語がデザイン上の想定を超えて拡張すると、どちらも崩れます。

5. テーブルとダッシュボードのサマリーカード

列ヘッダー・サマリーカードのタイトル・ダッシュボードウィジェットのラベルは、英語よりも日本語のほうがピクセル幅が広くなることがほぼ常にあります。数値のフォーマットも異なります。日本語では数字を万（10,000）単位でグループ化することが多く、これが列幅の割り当てに影響します。

ハード制限・ソフト制限・ローカライズ仕様書に書くべき内容

ほとんどのローカライズ仕様書では、1文字列あたり1つの文字数制限を指定します。しかし、これは間違った抽象化です。プロフェッショナルな日本語ローカライズ仕様書では、3種類の制約を区別しています。これを正しく設定すれば、TMS（翻訳管理システム）やローカライゼーションプラットフォームにおける手戻りのほとんどをなくせます。

• ハード文字数制限：収まる文字の絶対最大数。翻訳者はこれを超えてはなりません。データベースの列制約がある場合（例：display_name VARCHAR(40)）に有効です。
• ソフト文字数制限（推奨値）：翻訳者が目標とすべき推奨値。簡潔な出力を促しつつも、ある程度の柔軟性を持たせたい場合に有効です。
• 最大ピクセル幅：実際のレンダリング制約。UIの文字列に対して最も有用な数値です。文字数では把握できない漢字幅の問題を捉えることができます。

主要なローカライゼーションプラットフォーム（Phrase・Lokalise・Crowdin・Transifex）の多くは、メタデータとして文字列ごとの文字数制限をサポートしています。ピクセル幅のメタデータはサポートされていても活用しているチームはほとんどありません。それはデザインシステム側がその値を公開していないからです。デザイントークンにこのメタデータを追加するのは一度きりの投資ですが、それ以降のすべてのローカライズで効果を発揮します。

エンジニアリングチームが陥りやすいアンチパターン

日本語UIの崩れに対する一般的なエンジニアリング上の対応策の中には、問題を長期的に悪化させるものがあります。よくある対応とその逆効果について解説します。

日本語だけフォントサイズを小さくする

すべて収まるように見えるため試みたくなりますが、漢字は小さいサイズでは読みにくくなります。漢字を幅広にしている視覚的な複雑さは、最小限の判読サイズへの依存をも意味します。Noto Sans JPで12px未満になると、線の細部が失われ始めます。この変更はユーザーリサーチで「日本語版は使いにくい」という形で現れることが多く、ユーザー自身もその理由を言語化できません。

省略記号で自動切り詰めする

CSSの切り詰め（text-overflow: ellipsis）は手早い対処策ですが、不完全なプロダクトのサインです。日本語ユーザーはこの切り詰めを、日本語版が後回しにされた証拠と受け取ります。さらに悪いことに、切り詰められた部分は最も重要な単語であることが多いです。日本語の文章構造は動詞を文末に置きますが、その文末こそが最も切り詰められやすい部分です。

日本語ビルドに圧縮フォントを使う

日本語の縦長フォントは存在しますが、大きなサイズでの印刷向けに設計されています。通常のUIサイズでは読みにくく、日本語読者にはデザイン上の判断ミスとして伝わります。ヒーローの大見出しにのみ使い、本文テキストやインタラクティブなUIには絶対に使わないでください。

デザインのフィードバックなしに翻訳者任せにする

翻訳者は制約が与えられれば短い表現を選べますが、ソースのデザイン自体を書き換えることはできません。ボタン幅が全角6文字に対応しているなら、翻訳者はその目標に合わせられます。しかし制約を与えずにソース文字列だけを渡すと、意味的には正確だがUIに入らない日本語が生成されます。

ローカライズ前のデザイン監査：QA前に行う8つの確認

日本語UIに関して最もコストパフォーマンスが高い作業は、ローカライズ開始前です。初めて日本語版をリリースする前に、デザインシステムにこの監査を実施することで、下流の手戻りを大幅に削減できます。

ローカライゼーションQAとの効果的な協働

このワークフローで最も重要な関係は、プロダクトチームと日本語QAレビュアーの間にあります。レンダリングされたUIを見たことがない翻訳者はレイアウトの問題を助けられません。文字列しか見ていないQAレビュアーは文脈上の問題を見つけられません。最良の日本語UIを出しているチームは、ローカライゼーションQAを最終的な翻訳チェックではなく、デザインレビューの一段階として位置づけています。

初めて日本語版をリリースするSaaSチームへ：初回リリースの前・最中・後にネイティブ日本語QAを関与させてください。最後だけではありません。ローンチ前のデザイン監査は、後から修正するとコストがかかる構造的な問題を見つけます。本番UIでのローンチ後QAは、文字列リストのレビューでは必ず見落とされる文脈上の問題を見つけます。

すでに日本語版を出しているチームにとって次に最も有効な判断は、文字列ごとの最大幅メタデータをデザイントークンとローカライゼーションプラットフォームに追加することです。これにより、将来の文字列を実際に意味のある制約に対して自動的に検証できるようになります。

よくある質問