日本語UIの作り方を徹底解説｜ボタン・ラベル・文言で差がつくライティング術

日本語UIとは、画面上のボタン、ラベル、メニュー、エラーメッセージなどを日本語で設計し、ユーザーが迷わず操作できるようにしたものです。良い日本語UIの条件は、動詞で終わる具体的なボタン名、簡潔なメニュー名、原因と解決策を示すエラー文、表記ルールの統一の4点です。加えて、Noto Sans JPなどの可読性の高いフォントと適切な行間、文字あふれへの対策も必要です。本記事では、設計の前提から文言の書き方、表記、フォント、テスト方法までを順に解説します。

1. 日本語UIとは何か　基本の考え方と重要性

日本語UIとは、Webサイト、アプリ、業務システムなどの画面を、日本語で操作し理解できるように設計したユーザーインターフェースのことです。ボタンやメニューの文言だけでなく、エラーメッセージや通知、文字の表記、フォント、レイアウトまでを含みます。この章では、日本語UIの意味と役割、成果に影響する理由、英語UIとの違いを整理します。作り方の詳細は次章以降で扱います。

1.1 日本語UIの定義とUIライティングの役割

「日本語UI」という言葉は、文脈によって次の2つの意味で使われます。

本記事では、後者を中心に、前者の観点も含めて解説します。

画面上の文言を設計する仕事は、UIライティングやマイクロコピーと呼ばれます。UIライティングの役割は、ユーザーが画面を見て、次に何をすればよいかを迷わず判断できるようにすることです。ボタンのラベル、入力欄の説明、エラーの案内、完了時のメッセージなどが対象になります。広告やブログ記事の文章とは目的が異なり、読ませることより、操作を完了させることが優先されます。

日本語の文言を整えるときの指針は、公開されているガイドラインからも確認できます。たとえばMicrosoft Writing Style Guideには、製品の文言を書く際の考え方が示されており、自社のルールを作る際の参考になります。

1.2 日本語UIが使いやすさや成約率に影響する理由

ユーザビリティは、国際規格のISO 9241-11で、特定の利用状況において、利用者が目標を達成できる度合い（有効さ）、その際に使った資源の少なさ（効率）、利用者の満足度の3点から捉えられています。画面の文言は、この3点すべてに関わります。

• 操作の意味が文言から読み取れないと、ユーザーは迷い、途中で離脱しやすくなります。たとえば「次へ」だけでは、確認画面に進むのか、決済が確定するのかが分かりません。
• エラーメッセージで原因や対処法が分からないと、ユーザーは入力をやり直せず、フォームの完了率が下がります。
• 問い合わせや購入に直結するボタンの文言は、クリックや申込みの数に影響し得ます。ただし、効果の大きさはサービスの内容や利用者層によって異なるため、変更の効果はA/Bテストなどで確かめる必要があります。
• 文言が不明確だと、操作の迷いから問い合わせやサポートへの連絡が増える可能性があります。

日本語UIの品質は見た目の好みではなく、操作の完了率、問い合わせ数、ユーザーの安心感といった事業の指標に結びつく要素として扱えます。

1.3 英語UIとの違いと日本語ならではの難しさ

英語UIの文言を単純に日本語へ置き換えるだけでは、不自然な表現や表示崩れが起きやすくなります。日本語の言語的・表記的な特徴が、設計の前提を変えるためです。

日本語は文末に動詞や述語が来る言語で、同じ意味でも、名詞で終える「保存」、動詞で終える「保存する」、丁寧な「保存します」など複数の言い方があります。どれを採用するかを画面ごとに場当たり的に決めると、サービス全体で文言の一貫性が失われます。

こうした難しさがあるため、日本語UIでは、文言を書く前にユーザー像や文体のルールを決めておくことが重要です。その具体的な進め方は、次章で解説します。

2. 日本語UIを作る前に押さえたい設計の前提

画面ごとに文言を書き始めると、同じ機能が「登録」「申し込み」「サインアップ」と別の言葉で表され、敬語の高さも画面ごとにそろわなくなります。これを防ぐには、「誰が」「どんな場面で」「どんな口調で」「どの言葉を使うか」を先に決めておくことが必要です。この章では、そのための3つの前提を順に整理します。

2.1 ユーザー像と利用シーンの整理

文言の最適解は、読む人と読まれる場面によって変わります。たとえば、業務で毎日使う管理画面なら短く専門的な語でも通じますが、初めて使うスマートフォンアプリでは、同じ語が理解の妨げになることがあります。そこで、文言に影響しやすい項目から整理します。

利用シーンは、「いつ、どこで、何をきっかけに、何を達成したいか」の形で書き出すと、文言の判断材料として使えます。たとえば「通勤中に、予約の変更を済ませたい」という場面なら、確認画面の文言は短く、変更内容が一目で分かる形が適しています。一方、「自宅で、時間をかけて保険の申し込み内容を確認する」場面なら、補足説明が多くても許容されます。

ユーザー像は想像だけで決めず、問い合わせ履歴、サイト内検索のキーワード、アンケート、ユーザーインタビューなど、実際のデータや声をもとに作ることが重要です。データが得られない段階では、仮説であることを明記し、公開後に検証できるようにしておきます。たとえば、問い合わせで「ログインIDが分からない」という声が多ければ、ログイン画面のラベルが「ID」だけでは伝わっていない可能性があると判断できます。

2.2 トーン＆マナーの設計と敬語レベルの決め方

トーン＆マナーは、サービス全体で一貫させる言葉づかいの方針です。日本語は文末表現や敬語の選択だけで印象が大きく変わるため、英語以上に事前の取り決めが影響します。まず、次のような対になる軸で、サービスの立ち位置を決めます。

• フォーマル か カジュアル か
• 親しみやすさ と 信頼感 のどちらを優先するか
• 簡潔さ と 丁寧さ のどちらを優先するか

この方針は、金融・行政・医療のように誤解が損失につながる分野では丁寧で正確な側に、日常的に使う娯楽・生活系アプリでは親しみやすい側に寄せるのが一般的です。ただし、これは傾向であり、ブランドの方針やターゲットによって最適な位置は変わります。

次に、敬語レベルを具体的な文末表現で定義します。

敬語を使う場合は、文化庁の敬語の指針が、敬語を尊敬語・謙譲語・丁重語・丁寧語・美化語の5つに分けて整理しています。UIで特に注意したいのは、「ご利用になられる」のような二重敬語を避け、「ご利用いただく」「お使いになる」など一つの敬語表現に整えることです。丁寧にしようとして敬語を重ねると、文が長くなるだけでなく、不自然な印象も与えます。

もう一つ決めておきたいのが、ユーザーの呼び方と画面上の主語です。「お客様」「会員の方」「ユーザー」「あなた」のどれを使うかで、サービスと利用者の距離感が変わります。また、「マイページ」のようにユーザー視点の語を使う場合は、「私の設定」「あなたの設定」など同じ視点の語を他の画面でも使うようにし、視点が混在しないようにします。

トーンは、すべての場面で同じ強さにする必要はありません。通常の操作では標準的な文体を使い、エラーや警告では要点を先に述べて簡潔にお詫びするというように、場面ごとの強弱をあらかじめ決めておくと、文言を書く人が変わっても印象がぶれません。場面ごとの具体的な書き方は、後続の章で扱います。

2.3 用語集とライティングガイドラインの作成

用語集は、サービス内で使う言葉を統一するための一覧です。同じ機能に複数の呼び名があると、ユーザーは別の機能だと誤解することがあり、デザイナー、エンジニア、サポート担当者の間でも認識がずれます。用語集には、採用する語だけでなく、使わない語とその理由も併記しておくと、後から参加した人も判断しやすくなります。

上記は一例であり、実際にどの語を採用するかは、ユーザーが普段目にしている言葉と、既存の画面や規約で使っている語を調べて決めます。

ライティングガイドラインには、用語集に加えて次の内容を盛り込みます。

• トーン＆マナーの方針と、敬語レベルの定義
• 主語やユーザーの呼称のルール
• ボタンやラベルなど、要素ごとの文字数の目安
• 良い例と悪い例を並べた書き換え例
• 表記ルール(漢字・かな、全角・半角、記号の扱いなど)の方針

表記ルールの細かな基準は、後続の章で詳しく扱います。この段階では、基準を決める担当者と、判断に迷ったときの相談先を決めておけば十分です。

ガイドラインは作って終わりではなく、運用の仕組みも合わせて決めます。たとえば、Googleスプレッドシート、Notion、Figmaのコメント機能など、チームが日常的に開く場所に置き、更新の責任者と、新しい用語を追加するときの承認フローを決めておくと、内容が古くなることを防げます。また、ゼロから作るのが難しい場合は、デジタル庁が公開しているデジタル庁デザインシステムのように、公開されている資料を参考に、自社サービスに合う部分を取り入れる方法もあります。

3. 日本語UIのボタン文言の書き方

ボタン文言は、ユーザーが押す前に「押すと何が起きるか」を判断するための情報です。日本語は名詞だけでも動詞でも書けるため、文言の形が画面ごとにばらつきやすくなります。この章では、ボタンラベルの基本形、定番ワードの使い分け、CTAの工夫、注意が必要なボタンの書き方を扱います。

3.1 動詞で終わる分かりやすいボタンラベルの基本

ボタンラベルは、押した結果として起きる動作を、短い語句で具体的に示すのが基本です。AppleのHuman Interface Guidelines（ボタン）でも、ボタンのタイトルはアクションを説明する簡潔な語句にするよう示されています。

日本語では「保存」「送信」のようにサ変動詞の語幹だけで終える形と、「保存する」「送信する」のように動詞で終える形があります。どちらが正しいということはありません。プロダクト全体でどちらかに統一し、ライティングガイドラインに記載しておくことが重要です。ボタンごとに形が異なると、ユーザーには操作の性質が違うように見えてしまいます。

「OK」「はい」「いいえ」のような汎用的な語は、何に対する返答なのかが文脈に依存します。ダイアログの本文を読み飛ばしたユーザーは、結果を予測できません。対象が分かる場合は、動作に目的語を加えると誤操作を減らせます。

文字数に決まった基準はありませんが、ボタンの幅に収まり、折り返さずに読める長さが目安です。スマートフォンでは横幅が限られるため、目的語を含めて長くなる場合は、画面の見出しや直前の文脈で対象を示し、ボタン側は動作だけに絞る方法もあります。

3.2 「送信」「登録」「購入」など定番ワードの使い分け

定番ワードは似た意味に見えても、ユーザーが想定する「その後の状態」が異なります。画面の目的に合わせて選び、同じ操作に別の語を当てないようにします。

特に注意が必要なのは、金銭の支払いや契約が発生する最終画面です。特定商取引法の対象となる通信販売では、最終確認画面で、そのボタンを押すと申込みになることがユーザーに分かるように表示する必要があります。そのため、最終ボタンは「注文を確定する」「購入を確定する」「申し込む」のように、申込みであることが明確に伝わる文言にします。一方、手前のカート画面では「購入手続きへ進む」のように、まだ確定ではないことが分かる表現にします。具体的な表示要件は、事業形態や契約内容によって異なります。実装前に法務担当者や最新のガイドラインで確認してください。

3.3 CTAボタンでクリック率を高める文言の工夫

CTA（Call To Action）ボタンは、資料請求や無料体験など、ユーザーに次の行動を促すための主要なボタンです。文言を工夫する方向性は、行動の具体化、得られるものの明示、不安の解消の3点です。

「こちら」「詳細」だけの文言は、遷移先や動作が分からないため避けます。画面を読み上げソフトで確認するユーザーには、ボタンやリンクだけが一覧で読み上げられることもあり、文脈なしでも意味が通る文言が望ましいです。

補足文は事実と一致していることが前提です。「無料」「いつでも解約可」「クレジットカード不要」などは、実際の条件と同じ場合にのみ使います。「今すぐ」「限定」などの緊急性を強調する語も、実際の条件がない状態で使うと信頼を損なうため、避けた方が安全です。

1つの画面に主要なCTAが複数あると、ユーザーはどれを選ぶべきか迷います。主ボタンは原則1つに絞り、副次的な行動は「あとで見る」のように控えめな文言にします。クリック率への影響は、サービスや対象ユーザーによって異なります。どの文言が効果的かは、実際にテストして判断します。

3.4 キャンセルや削除など注意が必要なボタンの書き方

取り消しや削除など、データの喪失や契約の終了につながるボタンでは、操作の対象と結果を文言で明示します。誤操作による損害が大きいため、曖昧さを残さないことが重要です。

日本語の「キャンセル」には、「いま開いている操作をやめる」と「予約や注文を取り消す」の2通りの意味があります。確認ダイアログに「キャンセル」と「予約をキャンセル」が並ぶと、どちらが何を指すのか分かりません。そこで、操作を中止する意味では「やめる」「戻る」、取り消す意味では「取り消す」と書き分けると、意味が重複しません。

「退会」と「解約」は、サービスによって指す範囲が異なります。会員資格の削除とデータの消去を同時に行うのか、課金だけを止めるのかは、サービスごとに定義して統一します。定義は用語集に記載し、ボタンと説明文で同じ語を使います。

元に戻せない操作では、「完全に削除する」「元に戻せません」のように、取り消しができないことを文言で伝えます。ゴミ箱に移動するだけで復元できる操作であれば、「ゴミ箱に移動」と書き、削除とは区別します。結果が異なる操作を同じ「削除」で表すと、ユーザーは必要以上に不安になるか、逆に不用意に押してしまいます。

ダイアログの本文側では、影響を受ける対象と結果を説明します。たとえば「この写真を削除しますか？」という問いと「削除する」「やめる」というボタンを組み合わせると、本文を読まなくても操作の意味が分かります。ボタンの色や配置などの視覚的な設計は、別の観点で検討します。

4. 日本語UIのラベル・見出し・メニューの書き方

ラベル、見出し、メニュー名は、ユーザーが操作の前に目にする文言です。ボタン文言のように行動を促すものではなく、「どこに何があるか」「何を入力するか」を伝える役割を持ちます。ここでは、画面の骨格となるこれらの文言について、日本語で書く際の具体的な基準を整理します。

4.1 ナビゲーションやメニュー名を簡潔にするコツ

メニュー名は、2〜6文字程度の名詞で、ユーザーが普段使う言葉を選ぶのが基本です。長くなると、スマートフォンのタブバーやヘッダーで折り返しや省略が起こり、読み取りにくくなります。「料金」「機能」「導入事例」「お問い合わせ」のように、内容が一目で想像できる語を使います。

社内の部署名やプロジェクト名、抽象的な言葉は避けます。「ソリューション」「サービス」「その他」のような語は、押した先に何があるかが分かりません。メニュー名とリンク先ページの見出しは同じ語にそろえると、ユーザーは遷移後に正しいページへ来たと確認できます。「料金プラン」を押して「ご利用価格について」と表示されると、別のページに来たのではないかという迷いが生じます。

名詞止めが基本ですが、ドロップダウンやコンテキストメニューのように操作そのものを選ぶメニューでは動詞を含む形が適しています。たとえば「名前を変更」「ファイルを複製」「ごみ箱に移動」のように、選んだ結果が分かる表現にします。ボタンの文言設計は前章で扱っているため、ここでは「閲覧先を示すメニューは名詞、操作を選ぶメニューは動詞を含める」という使い分けだけを押さえてください。

画面内の見出しも同じ考え方で書けます。見出しは、その下にある内容を端的に言い表す名詞句にし、画面ごとに「〜について」「〜のご案内」などの定型句を付けるかどうかを統一します。「お」「ご」などの接頭語は、「お問い合わせ」「お知らせ」「お気に入り」のように定着している語に限って使うと、全体が過剰に丁寧にならず読みやすくなります。

4.2 フォームラベルとプレースホルダーの使い分け

フォームでは、ラベルは入力欄の外に常に表示し、プレースホルダーは入力例の補助にとどめるという役割分担にします。プレースホルダーは文字を入力した時点で消えるため、入力中に「この欄に何を入れるのか」を確認できません。また、薄いグレーで表示されることが多く、背景とのコントラスト比が不足しやすい点も課題です。WCAG 2.2 では、通常サイズのテキストに最低でも4.5:1のコントラスト比を求めています。詳細はW3CのWCAG 2.2を参照してください。

プレースホルダーに入力済みの値のような文字が表示されていると、入力が済んでいる欄だと誤認されることもあります。そのため、プレースホルダーには「例：」を付けて、実際に入力する値の見本であることを示すと誤認を防げます。

日本語のフォームでは、氏名・フリガナ・住所・電話番号など、日本特有の入力項目でラベルの粒度を決めておく必要があります。氏名は「姓」「名」に分けるのか、「お名前」の1欄にするのかを、システム側の保持形式に合わせて決めます。フリガナは「セイ」「メイ」のように全角カタカナで入力させるのか、ひらがなでもよいのかを補足テキストで明示します。単位や接尾語（「円」「歳」「件」）は入力欄の右側に置くと、ラベルを短くできます。

「必須」「任意」の表記は、項目の大半が必須ならば「任意」だけに印を付ける、反対に任意が多ければ「必須」だけに印を付けると、画面上のノイズを減らせます。いずれの場合も、フォームの冒頭で「必須」の意味を示しておくと迷いが生じません。入力内容が誤っていた場合のメッセージの書き方は、エラーメッセージの章で扱います。

4.3 アイコンとテキストを組み合わせるときの注意点

アイコン単体では意味が伝わらない場合があります。たとえば封筒のアイコンは、メール、お知らせ、お問い合わせのいずれにも使われるため、ユーザーによって解釈が分かれます。意味が一意に決まらないアイコンには、必ずテキストのラベルを併記するのが原則です。アイコンだけで通用しやすいのは、「×（閉じる）」や虫眼鏡（検索）のように広く定着したものに限られます。

テキストの併記は、アクセシビリティの面でも効果があります。WCAG 2.2 の達成基準 2.5.3「名前に含まれるラベル」では、画面に表示されているラベルの文字列を、音声入力や支援技術が使う名前にも含めることを求めています。アイコンのみのボタンには、スクリーンリーダーで読み上げられる名前（aria-label など）を設定し、表示するテキストと同じ語を使うと、音声操作でも呼び出せます。一方、テキストと並べて表示する装飾的なアイコンには空の代替テキスト（alt=””）などを指定し、同じ語が二重に読み上げられるのを防ぎます。

ホバー時に表示されるツールチップは、タッチ操作のスマートフォンやタブレットでは見られません。そのため、ツールチップだけに説明を頼らず、画面上に常時見えるラベルで意味を伝える必要があります。

レイアウト面では、アイコンは文字の左に置き、ラベルは1〜2語に収めます。スマートフォンの下部タブのように幅が限られる場所では、ラベルを「マイページ」ではなく「マイ」、「お気に入り」ではなく「保存」のように短縮する場合があります。ただし、短縮によって意味が変わらないか、他のメニューと見分けがつくかを確認してから採用します。文字の折り返しや切れを防ぐ具体的なレイアウト方法は、フォントとレイアウトの章で扱います。

5. エラーメッセージ・ヘルプ・通知の日本語UIライティング

エラーメッセージ、ヘルプ、通知は、いずれもユーザーが操作の途中で目にする文言です。エラーメッセージは操作が失敗したとき、ヘルプは迷いが生じそうな場面、通知は操作の結果や状態の変化を知らせる場面で表示されます。表示される場面が異なるため、同じ画面でも求められる文言の長さや温度感が変わります。ここでは、この3種類の文言を書くときの型と判断基準を整理します。

5.1 原因と解決策を伝えるエラーメッセージの型

エラーメッセージは、「何が起きたか」「なぜ起きたか」「どうすればよいか」の3要素で構成すると、ユーザーが次の行動を判断しやすくなります。ユーザビリティ調査会社のNielsen Norman Groupも、エラーメッセージのガイドラインで、問題を明確に示し、解決策を前向きに提案することを推奨しています。WCAG(ウェブコンテンツ アクセシビリティ ガイドライン)にも、入力エラーを検出した場合は修正方法を示すという達成基準3.3.3があります。

3要素のうち、原因がユーザーに分からない場合や、画面上の位置で原因が明らかな場合は、原因を省いて解決策だけを書いても構いません。たとえば、メールアドレス欄の直下に「@を含むメールアドレスを入力してください」と表示すれば、どの項目が問題かは位置で伝わります。

書き方の違いは、次の例で確認できます。

改善例に共通するのは、「不正」「無効」「エラー」といったシステム側の用語を避け、ユーザーが取れる行動を示している点です。条件(8文字以上、10MB以下など)がある場合は、エラー表示のあとではなく、入力前のヘルプテキストとしても示しておくと、エラー自体の発生を減らせます。

エラーの種類によって、書くべき内容と重点は変わります。

ユーザー自身では解決できないエラーでは、解決策の代わりに「データは保存されています」「時間をおいて再度お試しください」など、現状と次の選択肢を書くことで不安を軽減できます。問い合わせが必要な場合は、問い合わせ先と一緒にエラーコードを表示すると、サポート担当者が原因を特定しやすくなります。ただし、コードだけを単独で表示しても、ユーザーには何も伝わらない点に注意が必要です。

複数の項目でエラーが出る場合は、画面上部に件数と該当項目へのリンクをまとめ、各項目の近くに個別のメッセージを表示する方法が一般的です。エラーを赤色だけで示すと色の区別が難しい人に伝わらないため、アイコンや「エラー」などのテキストも併用します。アクセシビリティ全体の観点は、後続の章で扱います。

5.2 ユーザーを責めない表現とやわらかい言い回し

エラーの原因がユーザーの入力にある場合でも、主語をユーザーにして「あなたが間違えた」と受け取られる文にしないことが基本です。「入力が間違っています」「正しく入力してください」は命令や否定の響きが強く、「〜ていただけますでしょうか」のような過剰な丁寧表現は、文が長くなって要点が埋もれます。事実と依頼を短く伝える書き方が適しています。

システム側に原因がある場合は、「申し訳ございません」などのお詫びを簡潔に添えると、ユーザーの受け止め方が和らぎます。ただし、入力ミスのような軽微なエラーにまでお詫びを付けると、かえって画面全体が大げさな印象になります。お詫びを入れる基準は、「ユーザーの作業が失われた」「サービスが利用できない」など、ユーザーに実害が出る場面にしておくと運用しやすくなります。

なお、ログイン失敗時の表示では、やわらかさよりも安全性への配慮が必要です。「パスワードが違います」と表示すると、そのメールアドレスのアカウントが存在することを第三者に推測されるおそれがあります。そのため、「メールアドレスまたはパスワードが一致しません」のように、どちらが誤りかを特定できない表現にする方法が広く採用されています。

ユーモアや擬音語、絵文字は、決済の失敗やデータ消失など、ユーザーが困っている場面では避けたほうが無難です。トーンの全体設計はあらかじめ決めておき、エラー時は通常画面より一段落ち着いた表現にすると、方針がぶれません。

5.3 空の状態や完了画面で使えるマイクロコピー

エラー以外の場面でも、短い文言がユーザーの次の行動を左右します。ここでは、データがまだない「空の状態」、操作が終わった「完了画面」、操作結果を知らせる「通知」の3つを扱います。

空の状態は、検索結果が0件のとき、初回利用でデータが何もないとき、通知や履歴がまだないときに表示されます。ここで「データがありません」とだけ表示すると、ユーザーは何をすればよいか分かりません。空の理由と、最初に取れる行動を1組にして示すと、画面が行き止まりになりません。

空の状態でも、「検索結果なし」のように状況が一目で分かり、ユーザーが取るべき行動もない場合は、案内を増やす必要はありません。案内の量は、ユーザーが次に迷うかどうかで決めます。

完了画面では、何が完了したか、次に何が起こるか、ユーザーが何かする必要があるかの3点を示します。「送信しました」だけでは、返信がいつ来るのか、確認メールが届くのかが分かりません。たとえば問い合わせフォームなら、「お問い合わせを受け付けました。ご入力いただいたメールアドレスに、確認メールをお送りしました。回答までに3営業日ほどお時間をいただく場合があります」のように、具体的な情報を加えます。回答までの日数のような情報は、実際の運用実態と一致する内容だけを書きます。

操作結果を知らせる通知は、表示方法によって適した文言の量と、ユーザーが読み逃す可能性が変わります。

トーストは自動で消えるため、見逃すと困る情報や、ユーザーの操作が必要な情報をトーストだけで伝えないことが重要です。消えるまでの時間が短いと、読み終える前に消える場合もあります。エラーや重要な通知は、ユーザーが閉じるまで表示するバナーやインライン表示を選びます。

ヘルプテキストは、フォームの項目名の下などに置く補足説明で、エラー予防の役割も担います。入力例、文字数や形式の条件、入力しない場合の影響など、入力前に知っておくと迷わない情報に絞って書きます。入力欄の使い分けは別の章で扱うため、ここでは、エラーメッセージで初めて入力条件を示すのではなく、ヘルプテキストで先に示しておくという考え方だけを押さえておきます。

6. 読みやすい日本語UIにするための表記ルール

日本語は、漢字・ひらがな・カタカナ・英数字・記号を混在させて書く言語です。そのため、同じ意味の文言でも表記の選び方で読みやすさが変わります。画面内で表記がばらつくと、ユーザーは別の機能だと誤解することがあります。ここでは、UIの文言に適用できる表記ルールを4つの観点から整理します。

6.1 ひらがな・カタカナ・漢字のバランス

UIの文言は、画面を一瞥して意味を判断できることが求められます。漢字が連続すると語の切れ目が見えにくくなり、ひらがなが連続すると文節の区切りが分かりにくくなります。どちらかに偏らず、読み手が語の単位を瞬時に拾える配分にします。

6.1.1 漢字とひらがなの使い分け

漢字の連続は、助詞や動詞を補って分割すると読みやすくなります。たとえば「個人情報保護設定変更」は、「個人情報の保護設定を変更」とすると、語のまとまりが明確になります。連続する漢字の長さに厳密な上限はありませんが、4〜5文字を超える複合語が並ぶ場合は、分割できないか確認するという運用は有効です。

一方で、形式名詞、補助動詞、接続詞、副詞の多くはひらがなで書くと、文章が柔らかく読みやすくなります。以下は、ガイドラインに定めておくと判断が揃いやすい例です。

想定ユーザーに子どもや高齢者、日本語を第二言語とする人が含まれる場合は、使用する漢字の範囲を狭める判断が必要です。その場合はルビや言い換えも選択肢になります。漢字の範囲は、対象ユーザーと提供する画面の性質に応じて決め、ガイドラインに明記します。

6.1.2 カタカナ語の扱いと長音表記

カタカナ語は、ユーザーに定着しているかどうかで扱いを分けます。「ログイン」「ダウンロード」「パスワード」のように広く使われている語は、そのまま使って問題ありません。業界内でしか通じない語や、画面上の操作と結びつきにくい語は、日本語に言い換えるか、初出時に補足を添えます。たとえば、社内用語の「アサイン」は「割り当て」にすると、誰にでも伝わります。

語末の長音は、表記ゆれが起きやすい代表例です。「ユーザー」と「ユーザ」、「フォルダー」と「フォルダ」が同じ画面に並ぶと、別の概念に見えることがあります。Microsoftの日本語スタイルガイドのように、語末の長音を表記する方針を公開しているガイドもあります。どちらを採用するかより、プロダクト全体で一つに決め、用語集に登録して運用することが重要です。

ひらがなと漢字の使い分け、カタカナ語の言い換え、長音の有無は、用語集で一覧化しておくと、複数人で文言を書く場合でも判断を揃えやすくなります。

6.2 全角と半角、英数字の表記ゆれ対策

全角と半角の混在は、見た目の揃わなさだけでなく、検索や読み上げ、データ連携の不具合につながります。文字種ごとに全角か半角かを先に決め、例外を作らないことが、表記ゆれを減らす基本です。

6.2.1 文字種ごとの基本ルール

UIでは、以下のルールを基本にすると運用しやすくなります。

半角カタカナは、環境によって文字化けしたり、全角カタカナとの検索結果が一致しなかったりすることがあります。表示文言では半角カタカナを使わないルールにしておくと、こうした問題を避けられます。

ハイフン類にも注意が必要です。長音「ー」、ハイフン「-」、マイナス「−」は見た目が似ていますが、別の文字です。電話番号や型番に長音を混ぜると、コピーして使う場面で不具合が出ることがあります。

6.2.2 半角英数字と日本語の間隔、単位の書き方

日本語と英数字の間に半角スペースを入れるかどうかは、プロダクトごとに方針が分かれます。どちらが正しいというものではないため、入れる、入れないのどちらかに決めて全画面で統一することが重要です。単位も同様で、「10GB」と「10 GB」が混在しないよう揃えます。

用語の揺れは、文字種だけでなく語そのものにも起きます。たとえば「メール」「Eメール」「e-mail」、「ログイン」「サインイン」、「削除」「消去」などです。意味が同じ語は一つに絞り、用語集に正式表記と使用しない表記を並べて載せます。

表記の統一は、人の目だけに頼ると漏れが出ます。日本語の文章校正ツールである textlint と、表記ゆれ用の辞書ルール prh を組み合わせると、文言ファイルに対して機械的に表記ゆれを検出できます。文言をコードや翻訳リソースの中で一元管理しておけば、修正も一か所で済みます。

入力フォームでは、ユーザーが全角で数字を入力することもあります。表示文言のルールとは別に、入力値を受け取る側で全角を半角に変換するなどの対応をしておくと、エラーの発生を抑えられます。

6.3 句読点や記号の使い方

UIでは文章量が限られるため、句読点や記号の使い方が表示のリズムに大きく影響します。要素の種類ごとに、句点の有無や記号の用途を決めておくことが、画面全体の統一感につながります。

6.3.1 句点と読点の扱い

句点は、文言の種類によって付ける、付けないを分けると統一しやすくなります。以下は一例です。

読点は、意味の切れ目と、ひらがなが続く箇所に打ちます。「ここではきものをぬいでください」は区切り方によって意味が変わりますが、「ここで履物を脱いでください」と漢字を使えば解決できます。読点で補うより先に、漢字や語順を調整して誤読を防げないかを検討すると、文が整理されます。

6.3.2 記号を使うときの注意点

記号は、意味が伝わりやすい反面、使いすぎると画面がうるさくなり、スクリーンリーダーでも読み上げが冗長になることがあります。主な記号の扱いは以下のとおりです。

感嘆符や疑問符は、全角か半角かも決めておきます。日本語の文中では全角が自然に見えやすいですが、前項の文字種ルールとあわせて、プロダクトとして一つに統一します。

6.4 一文の長さと改行位置の調整

画面上の文章は、紙の文章より短く区切るほうが読み取りやすくなります。ユーザーは、操作の途中で必要な情報だけを素早く探すためです。一文には一つの内容だけを入れ、ユーザーが次に取る行動を文の前半に置くと、読み取りの負担が減ります。

6.4.1 一文を短くする書き換え

一文が長くなる主な原因は、理由、条件、操作の指示を一つの文に詰め込むことです。以下のように分けると、それぞれの情報が独立して伝わります。

文の長さに決まった基準はありませんが、ガイドラインにボタンは1行に収める、ダイアログ本文は数文までにする、といった目安を書いておくと、レビューの観点が揃います。目安は、画面幅やユーザー層に合わせて調整します。

6.4.2 改行位置の考え方

日本語は単語の間にスペースがないため、画面幅によって語の途中で改行されることがあります。「ご利用/ありがとうございます」のように文節で切れるのは自然ですが、「パスワー/ド」のように語の途中で切れると読みにくくなります。

改行位置を揃えるために、文言の中へ手動で改行を入れる方法は避けます。手動の改行は、画面幅の変更、文字サイズの拡大、多言語化のたびに不自然な位置で崩れる原因になるためです。代わりに、次のような対応を検討します。

• CSSの word-break: auto-phrase を使い、文節単位で改行させる。対応ブラウザーが限られるため、事前に対応状況を確認する
• CSSの text-wrap: balance を使い、見出しや短い文の行の長さを均等に近づける。こちらも対応状況の確認が必要
• 途中で切れてほしくない語は、inline-block を指定した要素で囲む

ユーザー名や商品名のように、表示のたびに内容が変わる変数を含む文言にも注意が必要です。短い名前だけで確認すると、長い名前が入ったときに改行位置が崩れます。想定される最も長い値と最も短い値の両方を入れて、表示を確認する運用にすると、公開後の崩れを防げます。禁則処理や文字あふれへのデザイン面の対処は、フォントとレイアウトの章で扱います。

7. 日本語UIに適したフォントとレイアウトのポイント

日本語は、ひらがな・カタカナ・漢字・英数字が混在し、1文字あたりの画数も欧文より多くなります。そのため、同じ文言でもフォントの選び方や文字サイズ、行間、折り返しの設定で読みやすさが変わります。この章では、画面上で日本語を表示するときのデザインと実装の判断基準を扱います。

7.1 Noto Sans JPやメイリオなど日本語フォントの選び方

フォントは見た目の好みだけでなく、利用者の端末に入っているか、必要なウェイトがそろっているか、ライセンスと読み込み容量が許容範囲かという条件で選びます。OSごとに標準の日本語フォントが異なるため、指定したフォントがない端末では次の候補に切り替わり、表示が変わります。

CSSでは、読み込んだWebフォントを先頭に書き、その後ろに各OSの標準フォントと総称フォントを並べます。

欧文や数字だけ別のフォントにしたい場合は、欧文フォントを先頭に置きます。欧文フォントに含まれない日本語の文字は、後ろの日本語フォントで表示されます。

ウェイトについては、本文はRegular(400)、強調や見出しはMedium(500)からBold(700)を目安にし、小さい文字には細いウェイトを使わないようにします。画数の多い漢字は、細い線のまま小さく表示すると潰れて読みにくくなります。

7.2 文字サイズ・行間・字間の目安

以下は一般的に使われる目安で、フォントや画面サイズ、表示する情報量に応じて調整します。

実装では、文字サイズをrem、line-heightを単位なしの数値で指定すると、ユーザーがブラウザの文字サイズ設定を変えたときに、レイアウトが追従しやすくなります。

見出しやボタンなど短い文字列には、OpenTypeの「palt」(プロポーショナルメトリクス)で字間を詰める方法もあります。対応しているフォントでのみ有効なので、使うフォントで表示を確認してから適用します。

ユーザーが行間や字間を独自に広げて読む場合もあります。WCAGの達成基準1.4.12「テキストの間隔」では、行間を文字サイズの1.5倍、字間を0.12倍などに変更しても、内容や機能が失われないことを求めています。固定の高さや幅で文字を切り詰める設計は、この点でも避けるべきです。

7.3 禁則処理と文字あふれを防ぐデザイン

禁則処理とは、句読点や閉じ括弧「」）を行頭に置かず、開き括弧「（」を行末に置かないといった、日本語の組版ルールです。ブラウザは標準で一定の禁則処理を行いますが、細かな挙動はCSSで調整できます。

折り返しを制御する主なCSSプロパティは次のとおりです。ブラウザごとの対応状況は、MDN Web Docsのword-breakの解説で確認できます。

日本語でword-break: keep-allを指定すると、文字の間で改行できなくなり、枠からはみ出す原因になるため、日本語の本文には安易に使わないようにします。

文字あふれは、ユーザーが入力する氏名や商品名、翻訳による文言の長さの変化、OSやブラウザの文字サイズ拡大によって起こります。ボタンやカードの高さと幅を固定せず、min-heightとpaddingで余白を確保し、文字数に応じて枠が伸びるようにすると、多くの崩れを防げます。

省略表示は、一覧のタイトルなど、全文が見えなくても操作に支障がない箇所に限定します。text-overflow: ellipsisやline-clampで省略する場合は、詳細画面や文字列全体を確認できる手段を用意します。「削除」「購入」のように、ユーザーの判断に必要な文言は、省略せず折り返して全文を表示します。

8. 日本語UIの品質を高めるチェックとテスト

日本語UIの文言は、書き終えた時点では品質が確定しません。公開前に社内の基準で確認し、実際の利用者の反応で検証し、公開後は数値で改善するという段階を踏みます。確認の目的が違う手法を、工程に合わせて使い分けることが品質を安定させる条件です。

表記ゆれのチェックは、校正ツールを使うと工数を減らせます。日本語の文章校正では、オープンソースの「textlint」が広く使われており、用語集に合わせたルールを組み込めます。ただしツールが検出できるのは表記の不一致までです。文言が伝わるかどうかは、次のテストで確かめます。

8.1 ユーザビリティテストで文言を検証する方法

ユーザビリティテストでは、対象ユーザーに具体的な課題を与えて操作してもらい、文言が原因で手が止まる場面や誤解が起きる場面を観察します。「このボタンは分かりやすいですか」と直接尋ねると、好みの回答になりがちです。「商品を注文してください」のように、目的だけを伝えて自力で操作してもらう形が適しています。

進め方は次のとおりです。

1. 確認したい文言を決め、それが現れる画面と、そこに至る課題を設計します。
2. 想定ユーザーに近い人を集めます。社内の関係者は用語に慣れているため、被験者には向きません。
3. 操作中に考えていることを声に出してもらい(思考発話法)、迷った箇所と発言を記録します。
4. 終了後に、迷った箇所で何を期待していたかを聞き取ります。
5. 問題を「文言」「配置」「機能」に分類し、文言に起因するものから修正案を作ります。

人数については、ユーザビリティ研究者のヤコブ・ニールセンが、1回のテストは5人前後で十分に問題を発見でき、修正と再テストを繰り返すほうが効果的だと述べています。ただし、利用者の層が大きく異なる場合は、層ごとに人数を確保する必要があります。

文言の検証では、次の観点で記録すると原因を切り分けやすくなります。

画面全体の完成前でも、文言だけを切り出して確認できます。例えば、ボタンやメニュー名だけを見せて「押すと何が起きると思うか」を答えてもらう方法があります。回答が想定とそろうかどうかで、そのラベルの意図がどの程度伝わるかを判断できます。

8.2 A/Bテストで改善するUIライティング

A/Bテストは、公開中の画面で文言Aと文言Bをユーザーにランダムに表示し、どちらが指標を改善するかを比べる手法です。ユーザビリティテストが「なぜ迷うのか」を明らかにするのに対し、A/Bテストは改善案の効果を実際の行動データで判定するのに向いています。

実施前に、次の項目を決めておきます。

文言と配色を同時に変えると、結果が変わった原因を特定できません。また、途中経過で差が出たからといって早期に打ち切ると、偶然の差を成果と誤認するおそれがあります。終了条件は開始前に決め、途中の数値で判断を変えないことが大切です。

クリック率だけを主要指標にすると、誤解を招く表現でも数値が上がる場合があります。例えば、「無料」を強調して押下数が増えても、その後の登録完了や継続利用が下がっていれば改善とは言えません。クリックの後に続く指標も、あわせて確認します。

アクセス数が少ないサイトでは、統計的に差を判定するまでに長い期間が必要です。その場合は、ユーザビリティテストで仮説を絞り込んでから実施すると、試行回数を抑えられます。結果は、勝った文言とその理由を、用語集やライティングガイドラインに反映して蓄積します。

8.3 アクセシビリティとユニバーサルデザインの観点

日本語UIの文言は、視覚だけでなく、スクリーンリーダーによる読み上げや音声操作でも利用されます。日本のウェブアクセシビリティの規格であるJIS X 8341-3:2016は、ウェブアクセシビリティ基盤委員会(WAIC)が解説しているとおり、国際規格のWCAG 2.0に対応しています。文言に関わる主な達成基準は次のとおりです。

確認では、実際にスクリーンリーダーで読み上げて聞くことが有効です。PCではNVDA、iPhoneではVoiceOver、AndroidではTalkBackが使えます。画面上では自然な文言でも、「こちら」「詳細」のようなリンク文言は読み上げ時に前後の文脈を失うため、リンク先が判断できません。ボタンやリンクの名称は、単独で聞いても意味が通るかを基準に確認します。

漢字の読みも確認対象です。スクリーンリーダーは文脈によって、地名や固有名詞、同形異音語を誤読することがあります。重要な語が誤って読まれる場合は、表記を変えるか、読みを補う方法を検討します。

ユニバーサルデザインの観点では、文言を平易にすることも品質の一部です。専門用語を避け、一文を短くし、状況や手順を明確に書くことは、高齢者、日本語を母語としない人、一時的に急いでいる人にも役立ちます。国の取り組みとしては、デジタル庁デザインシステムが、行政サービス向けのコンポーネントや利用上の考え方を公開しており、文言やアクセシビリティの検討時に参照できます。

アクセシビリティの確認は、公開前に1回行えば終わりではありません。文言を更新するたびに、ラベルの変更でエラー表示や読み上げが崩れていないかを確認する運用を、チェックリストに組み込みます。

9. まとめ

日本語UIは、ユーザー像と利用シーンを整理し、トーン＆マナーや用語集を決めたうえで文言を作ることで、画面ごとの表現のぶれを減らせます。ボタンは「購入する」のように動詞で結果が分かる形にし、削除などの操作では対象と影響を明記します。エラーメッセージは原因と解決策を示し、ユーザーを責めない表現にします。表記ルールとフォントの設定を統一し、文字あふれも確認してください。公開後はユーザビリティテストやA/Bテストで文言を検証し、アクセシビリティにも配慮して改善を続けます。