日本語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文字分ほどの幅がある全角のマスを占めます。英語5文字の「Login」は日本語で「ログイン」（4文字）になり、文字数は減っても横幅はかえって広がります。文字数とピクセル幅は別物です。文字数だけを追うプロダクトチームは、日本語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は、文字列リストのレビューでは必ず見落とされる文脈上の問題を見つけます。

すでに日本語版を出しているチームが次に打つべき最も有効な手は、文字列ごとの最大幅メタデータをデザイントークンとローカライゼーションプラットフォームに追加することです。そうすれば、今後の文字列を意味のある制約に照らして自動で検証できるようになります。

よくある質問