ux-writing

UX ライティング

デジタル製品や体験のために、明確で簡潔、ユーザー中心のインターフェース文言（UX テキスト／マイクロコピー）を作成します。このスキルでは、ユーザーが目標を達成できるようにするテキストを作成するためのフレームワーク、パターン、ベストプラクティスを紹介します。

このスキルを使う場面

次のような場合にこのスキルを使います。

• インターフェース文言（ボタン、ラベル、タイトル、メッセージ、フォーム）を作成するとき
• 既存の UX テキストを明確さや効果の面から編集するとき
• エラーメッセージ、通知、成功メッセージを作成するとき
• 会話形式のフローやオンボーディング体験を設計するとき
• 製品のボイスとトーンを定めるとき
• 製品コンテンツの一貫性や使いやすさを監査するとき

UX ライティングの基本原則

4 つの品質基準

すべての UX テキストは、次の条件を満たす必要があります。

1. 目的が明確 — ユーザーやビジネスの目標達成を支援する
2. 簡潔 — 意味を損なわず、できるだけ少ない言葉で伝える
3. 会話的 — 機械的ではなく、自然で人間らしい表現にする
4. 明確 — 曖昧さがなく、正確で理解しやすい

主なベストプラクティス

簡潔さ

• 1 行あたりの文字数は最大 40～60 文字にする
• すべての言葉に役割を持たせる
• 情報量の多いテキストは、ざっと読める単位に分割する
• 重要な情報を先に伝える
• 冗長な表現を削る（「in order to」→「to」、「due to the fact that」→「because」、「at this point in time」→「now」）
• 句動詞を直接的な動詞に置き換える（「find out」→「discover」、「set up」→「configure」、「carry out」→「perform」）
• 修飾語を重ねない。形容詞は通常 1 つで十分です

明確さ

• 平易な言葉を使う（一般向けは 7 年生程度、専門家向けは 10 年生程度の読解レベル）
• 専門用語、慣用表現、技術用語を避ける
• 用語を全体で統一する
• 意味が明確で具体的な動詞を選ぶ
• 差別的・排他的な表現を避ける（性別を前提とした表現、障害のある人を排除する慣用表現、文化に特有の比喩など）

会話的なトーン

• 話し言葉のように書く
• 85％の割合で能動態を使う
• 前置詞や冠詞を含める
• 機械的な言い回しを避ける

ユーザー中心

• 機能ではなく、ユーザーが得られるメリットに焦点を当てる
• ユーザーの疑問を予測し、答える
• 二人称（「あなた」）を使う
• ユーザーの言葉やメンタルモデルに合わせる

UX テキストのパターン

インターフェース要素には、次の一般的なパターンを適用します。

タイトル

• 目的：ユーザーが現在いる場所を把握できるようにする
• 形式：名詞句。ページタイトル、モーダル／ダイアログのタイトル、メニュー／ナビゲーション項目にはタイトルケースを使用します（タイトルケースの仕組みについては、下記の「大文字表記」を参照してください）。下位の見出し（H3 以上）、図のキャプション、コールアウト、表のタイトルにはセンテンスケースを使用します。
• 種類：ブランドタイトル、コンテンツタイトル、カテゴリタイトル、タスクタイトル
• 例：
  • ページタイトル（タイトルケース）：「Account Settings」、「Your Library」、「Run Payroll」
  • 下位の見出し（センテンスケース）：「Recent activity」、「Bank account details」、「Tax withholdings」

ボタンとリンク

• 目的：ユーザーが操作できるようにする
• 形式：能動態の命令形、センテンスケース
• パターン：[動詞] [目的語]
• 例：「Save changes」、「Delete account」、「View details」
• 避ける表現：「OK」、「Submit」、「Click here」などの汎用的なラベル

エラーメッセージ

• 目的：問題を説明し、解決策を提示します
• 形式：共感が伝わる、明確で、行動につながる表現
• パターン：[失敗した内容]。 [理由／背景]。 [対処方法]。

エラーメッセージの種類

検証エラー（インライン）

• ユーザーが入力欄への入力を終えたとき、またはフォーカスを外したときに表示します
• 入力を修正するための、簡潔で具体的な案内を示します
• パターン：[項目] [具体的な要件]
• 例：
  • 「メールアドレスには @ を含めてください」
  • 「パスワードは 8 文字以上で入力してください」
  • 「未来の日付を選択してください」
• タイミング：リアルタイム、または入力欄からフォーカスを外したとき
• 場所：入力欄の下または横

システムエラー（モーダル／バナー）

• バックエンドの処理に失敗したときに表示します
• 何が起きたか、なぜ起きたかを説明します
• パターン：[失敗した操作]。 [考えられる原因]。 [復旧手順]。
• 例：
  • 「支払いに失敗しました。カードが承認されませんでした。別のお支払い方法をお試しください。」
  • 「変更を保存できませんでした。接続が切断されました。再接続して、もう一度お試しください。」
  • 「アップロードに失敗しました。ファイルサイズが大きすぎます。10MB 未満のファイルを選択してください。」
• タイミング：失敗後すぐ
• 場所：モーダルダイアログまたは目立つバナー

ブロッキングエラー（全画面）

• 解決するまで利用を続けられないようにします
• 利用を妨げている要因と解決方法を明確に説明します
• パターン：[ブロックされている内容]。 [理由]。 [必要な具体的な操作]。
• 例：
  • 「アップデートが必要です。このバージョンはサポートされなくなりました。続行するには、今すぐアップデートしてください。」
  • 「サブスクリプションの有効期限が切れました。アカウントは一時停止されています。アクセスを再開するには、サブスクリプションを更新してください。」
  • 「認証が必要です。機能にアクセスするには、メールアドレスを確認してください。受信トレイをご確認ください。」
• タイミング：アプリの起動時、または機能へのアクセス時
• 場所：全画面または大きなモーダル

権限エラー

• 権限を求める前に、そのメリットを説明します
• パターン：[ユーザーにとってのメリット]。 [必要な権限]。
• 例：
  • 「注文の発送時に通知を受け取れます。通知を有効にしてください。」
  • 「近くの店舗を検索できます。位置情報へのアクセスを許可してください。」
  • 「写真をバックアップできます。ストレージへのアクセスを許可してください。」
• タイミング：機能を初めて使用するとき
• 場所：機能に関連する箇所

避けるべき表現

• 説明のない技術的なコード（「Error 403」）
• ユーザーを責める表現（「無効な入力です」「不正な文字です」）
• ロボットのような口調（「エラーが発生しました」）
• 解決策のないエラー
• 原因が曖昧な表現（「問題が発生しました」）

成功メッセージ

• 目的：操作が完了したことを確認します
• 形式：過去形で、具体的かつ前向きな表現
• パターン：[操作] [結果／メリット]
• 例：「変更を保存しました」「メールを送信しました」「プロフィールを更新しました」

空の状態

• 目的：コンテンツがないときにユーザーを案内します
• 種類：初回利用時、ユーザーがコンテンツを削除した後、エラー／検索結果なし
• 形式：説明＋コンテンツを追加するための CTA
• 例：「メッセージはまだありません。チームとつながるために、会話を始めましょう。」

フォームの入力欄

• ラベル：入力内容を示す明確な名詞句（「メールアドレス」「電話番号」）
• 説明：動詞から始め、情報が必要な理由を説明します
• プレースホルダー：使用は控え、[email protected] のような一般的な入力例に限ります
• 補助テキスト：重要度に応じて、常時表示、必要時に表示、または自動表示します

通知

• 目的：タイムリーで価値のある情報を届けます
• 種類：対応が必要（目立つ）、受動的（控えめ）
• 形式：動詞から始まるタイトル＋状況に応じた説明
• 例：「アップデートが必要です。続行するには、最新バージョンをインストールしてください。」

書式とスタイルの規則

大文字・小文字の使い分け

• センテンスケース（デフォルト）：本文、説明、補足テキスト、エラーメッセージ、成功メッセージ、ツールチップ、プレースホルダーテキスト、ボタンラベル、下位レベルの見出し（H3 以上）、図のキャプション、コールアウト、表のタイトル
• タイトルケース：ページタイトル、モーダル／ダイアログのタイトル、メニュー項目とナビゲーション項目、フォームフィールドのラベル
• すべて大文字：見出しや数値の上に置く短いオーバーライン／アイブロウラベル（3語以内）のみ。たとえば、EMPLOYEES、TOTAL PAY、LAST UPDATED のような統計カードのセクション見出しや、KPI 値の上に置くカテゴリタグに使用します。また、頭字語（PDF、URL、API、EIN、SSN）にも使用します。短いカテゴリのオーバーラインで大文字を使うのは、叫んでいるように見せるためではなく、意図的なタイポグラフィ上の表現です。本文、ボタンラベル、エラーメッセージ、ページタイトル、タブ／メニューラベル、または約3語を超える文字列には、使用しないでください。それ以上の長さでは可読性が大幅に低下し、叫んでいるように見えます。

タイトルケースのルール（タイトルケースを使用するすべての箇所に適用）：

• 品詞にかかわらず、タイトルの最初と最後の単語を大文字にします。
• 形容詞、副詞、名詞はすべて大文字にします。
• 代名詞（「it」を含む）はすべて大文字にします。
• 動詞はすべて大文字にします。「to be」のすべての形（is、are、was、has been など）も含みます。
• 「no」、「not」、間投詞の「O」は大文字にします。
• 冠詞（「a」、「an」、「the」）は、タイトルの最初または最後にある場合を除き、大文字にしません。
• 等位接続詞（「and」、「or」、「nor」、「but」、「for」、「yet」、「so」）は、タイトルの最初または最後にある場合を除き、大文字にしません。
• 「to」は、不定詞の一部かどうかにかかわらず、タイトルの最初または最後にある場合を除き、大文字にしません。
• 前置詞（例：「in」、「on」、「at」、「by」、「of」、「with」）は、タイトルの最初または最後にある場合を除き、大文字にしません。

例：

• 「Run Payroll for the Pay Period」
• 「Add a New Employee」
• 「How to File Quarterly Taxes」

例外事項：

• **「Coming soon」**は、バッジ、コールアウト、コピーなど、表示されるすべての箇所で使用する標準の今後の機能ラベルです。タイトルケースの文脈で使う場合も、センテンスケースで表記します。「Coming at Beta」や「Coming at GA」のように、マイルストーンの詳細をユーザー向けの文字列に表示しないでください。
• ドロップダウンのアクション項目（ボタンから開くメニュー内の命令形の項目。例：「Add employee」、「See payroll runs」、「Export report」）は、ボタンと同様にセンテンスケースにします。静的なナビゲーションメニュー項目として扱いません。「メニュー項目にはタイトルケースを使う」というルールは、ページへのリンクを示すナビゲーションメニュー（サイドナビゲーション、パンくずリスト、トップレベルのナビゲーションリンク）に適用されます。アクションメニューには適用されません。
• 名前付きページを参照するボタン（例：「Go to Setup Wizard」、「Back to Payroll Hub」、「Open Time Review」）では、ボタンの文言はセンテンスケースにしつつ、ページ名はタイトルケースのままにします。この場合、ページ名は固有名詞です。

数字と日付

• 単語ではなく数字を使います（「twelve」ではなく「12」）。省スペースになり、すばやく読み取れます。
• 日付の月は省略せずに表記します。「August 5, 2025」または「5 August 2025」とし、「8/5/2025」や「8.5.2025」のような、地域によって解釈が異なる表記は避けます。
• 曜日と月は省略せずに表記します。省略するのは、表やモバイル画面など、スペースに制約がある場合に限ります。例：「Sat., Jan. 24」。
• 日付には序数標識を付けません。「August 5」とし、「August 5th」とはしません。「May 1」とし、「May 1st」とはしません。
• 年の範囲は、両方の年を省略せずにハイフンでつなぎます。「2015-2016」とし、「2015-16」や「2015 to 2016」とはしません。

時制

• ステータスメッセージでは、現在完了形より過去形を優先します。「File has been uploaded」ではなく「File uploaded」とします。
• 多くの UI の文脈では、現在完了形を使っても意味は変わらず、語数が増えるだけです。

略語

• ユーザーがすぐに理解できる略語のみを使用します（一般的なもの：PDF、URL、ID）。
• 少しでも判断に迷う場合は、初出時に正式名称を記載し、その後に略語を使います。「application programming interface (API)」。
• ラテン語の略語（例：i.e.、etc.）には、適切な句読点を使用します。各文字の後にピリオドを付け、文中では前後にコンマを付けます。
• 判断に迷う場合は、略さずに表記します。

文体とトーン

ボイス（一貫したブランドパーソナリティ）

ボイスとは、製品の一貫したパーソナリティです。以下を使ってボイスを確立します。

• コンセプト：ブランドの主要な原則や価値観を3～5個
• ボイスの特徴：各コンセプトを表す形容詞
• 良い例／悪い例：ボイスを実際にどのように表現するかを示す具体例

ボイスチャートの作成については、references/voice-chart-template.md を参照してください。

トーン（状況に応じて調整）

トーンとは、ボイスを特定の状況に合わせて調整する方法です。ボイスは一定ですが、ユーザーの状況や感情に応じてトーンは変化します。

トーンの変数

• 目的：ユーザーがこのテキストを見る理由（情報、操作、確認）
• 状況：ユーザーが何をしようとしているか（学習、タスクの完了、エラーからの復旧）
• 感情状態：ユーザーがどのように感じている可能性が高いか（苛立ち、期待、混乱、慎重さ）
• 影響の大きさ：操作による影響（小：テーマの変更、大：アカウントの削除）

ユーザーの感情状態に応じたトーンの調整

苛立っている（エラー、失敗、障害）

• 共感を示し、解決策に焦点を当てます
• 誰かを責めずに問題を認めます
• 明確な復旧手順を示します
• 例：「お支払いに失敗しました。カードが承認されませんでした。別のお支払い方法をお試しください。」

混乱している（初回利用、複雑な機能）

• 忍耐強く、説明的に伝えます
• 手順を明確に分けて説明します
• 背景情報とガイダンスを提供します
• 例：「支出の分析情報を見るには、銀行口座を接続してください。手順をご案内します。」

自信がある（定期的なタスク、再訪）

• 効率的かつ率直に伝えます
• 説明は最小限にします
• すばやく確認します
• 例：「保存しました」

慎重になっている（影響の大きい操作、データ損失）

• 真摯かつ透明に伝えます
• 結果を明確に示します
• ユーザーの判断を尊重します
• 例：「アカウントを削除しますか？すべてのデータが失われ、この操作は取り消せません。」

成功した（完了、達成）

• 前向きで励みになるように伝えます
• 達成内容に見合った表現にします
• 簡潔に祝福します
• 例：「プロフィールを更新しました。変更が反映されました。」

コンテンツの種類に応じたトーンの調整

エラーメッセージ：共感を示し、安心感を与え、解決策に焦点を当てます

• ユーザーを責めない
• 何が起きたかを説明する
• 明確な次の手順を示す

成功メッセージ：前向きで、具体的で、励みになるように伝えます

• 何が起きたかを確認する
• 操作の重要度に見合った表現にする
• 簡潔で明確にする

手順：明確で、率直で、役立つ内容にします

• 重要な操作を最初に伝える
• 必要に応じて理由を説明する
• 簡単な手順を使う

オンボーディング：親しみやすく、励みになり、簡潔にします

• 圧倒させずに歓迎する
• 価値に焦点を当てる
• 初期の成果を祝う

確認：真摯で、透明性があり、敬意を払った表現にします

• 結果を明確に伝える
• 操作を誘導しない
• 簡単に取り消せるようにする

空の状態：希望が持て、次の行動につながり、導きになるようにします

• 空である理由を説明する
• 次の操作を明確に示す
• 励ますトーンを保つ

編集プロセス

UX テキストを4つのフェーズで編集します。

フェーズ1：目的に沿っているか

• テキストはユーザーが目標を達成するのに役立ちますか？
• テキストはビジネス目標に貢献していますか？
• ユーザーにとっての価値は明確ですか？
• 懸念を予測し、解消していますか？

フェーズ2：簡潔か

• 不要な言葉を削除する
• 重複した情報をまとめる
• すべての言葉に意味があるか確認する
• 重要な概念を最初に伝える

フェーズ3：会話的か

• 声に出して読み、実際にこう話すか確認する
• （受動態のほうが明確な場合を除き）能動態を使う
• 自然なつなぎの言葉を含める
• 企業的な専門用語を避ける

フェーズ4：明確か

• 具体的で正確な動詞を使う
• 用語を一貫させる
• 読みやすさを確認する（Hemingway Editor、Flesch-Kincaid）
• 意味が曖昧でないことを確認する

ワークフロー

1. 状況を把握する

   • ユーザーの目標とニーズ
   • ビジネス目標
   • 技術的な制約
   • ユーザーの感情状態

2. コンテンツを作成する

   • 会話を起点にする（実際にどのように話すか）
   • 適切なパターンを適用する
   • ボイスとトーンを考慮する
   • 重要な情報を最初に伝える

3. 反復的に編集する

   • フェーズ1：目的に沿っているか
   • フェーズ2：簡潔か
   • フェーズ3：会話的か
   • フェーズ4：明確か

4. テストして測定する

   • チームで確認する
   • 可能であればユーザーでテストする
   • タスクの完了度と理解度を測定する
   • フィードバックを基に改善を重ねる

UXライティングにおけるアクセシビリティ

アクセシブルなコンテンツを作成すると、支援技術を使用するユーザーを含むすべてのユーザーが、製品を理解し、操作できるようになります。

アクセシビリティの基本原則

スクリーンリーダー向けの最適化

• すべての操作可能な要素に、明確なラベルを付けます（「送信」だけでなく「フォームを送信」）
• リンクテキストは内容がわかるように記述します（「こちらをクリック」ではなく「料金の詳細を読む」）
• エラーメッセージは、スクリーンリーダーで使いやすい構成にします（エラーとフィールドのラベルが一緒に読み上げられるようにします）
• 視覚的な文脈だけでは不十分な場合は、ARIAラベルを使用します

認知面でのアクセシビリティ

• 1文あたり8〜14語を目安にします（8語なら理解率100％、14語なら90％）
• 複雑な情報は、ざっと目を通せる単位に分けます
• 明確な見出しと論理的な階層を使います
• 一貫性があり、予測しやすいパターンを用意します

複数の形式による情報伝達

• 色だけで意味を伝えないようにします
• 視覚的な表示にはテキストを添えます（赤いアイコンと「エラー：メールアドレスが必要です」）
• アイコンや画像にはテキストによる代替情報を用意します
• 十分な色のコントラストを確保します（WCAG AAの最低基準：4.5:1）

誰にでもわかりやすい言葉

• 一般向けの文章は、中学2〜3年生程度の読解レベルを目安にします
• 専門用語は初めて使うときに説明します
• 慣用句、比喩、文化的な言及は避けます
• 日常的によく使われる言葉を選びます

アクセシブルなパターンの例

ボタン

• ❌ 不適切：「送信」（スクリーンリーダーに必要な文脈がありません）
• ✅ 適切：「申請を送信」

リンク

• ❌ 不適切：「詳しい情報はこちらをクリック」
• ✅ 適切：「プライバシーポリシーを読む」

エラーメッセージ

• ❌ 不適切：「無効」と表示された赤いテキスト
• ✅ 適切：「エラー：メールアドレスには@を含めてください」（エラーアイコン付き）

フォームのラベル

• ❌ 不適切：プレースホルダーのみの入力欄
• ✅ 適切：常に表示されるラベル＋任意のプレースホルダー

UXテキストの基準

調査に基づく以下の指標を参考に、効果的なUXテキストを作成しましょう。

文章の長さの目安

コンテンツの種類別

• ボタン／CTA：理想は2〜4語、最大6語
• タイトル：3〜6語、最大40文字
• エラーメッセージ：12〜18語（解決策を含む）
• 操作手順：最大20語、理想は14語
• 本文：1文あたり平均15〜20語
• 通知：タイトルと本文を合わせて10〜15語

理解率

• 8語以下：ユーザーの理解率100％
• 14語以下：ユーザーの理解率90％
• 25語：理解率が大幅に低下する前の上限

文字数と行の長さ

最適な範囲

• 行の長さ：読みやすさを最大限に高めるには40〜60文字
• ボタンのラベル：15〜25文字
• ページタイトル：30〜50文字
• 通知タイトル：35〜45文字

読解レベルのガイドライン

対象者別

• 一般向け：中学2〜3年生程度（Flesch-Kincaid）
• 業務用ツール：高校1〜2年生程度
• 技術製品：高校2〜3年生程度
• 専門分野：高校3年生〜大学1年生程度（必要な場合のみ）

テストツール

• Hemingway Editor：複雑な文章を強調表示します
• Readable.com：複数の読みやすさスコアを提供します
• Microsoft Word：Flesch-Kincaidスコアの計算機能を内蔵しています

避けるべきよくある間違い

• 受動態を使いすぎる
• 汎用的なボタンラベル（「送信」、「OK」）
• エラーメッセージでユーザーを責める
• 深刻な場面で、過度にひねりのあるユーモアを使う
• 用語が一貫していない
• 手順や説明が隠れている
• ユーザーの言葉ではなく、システム中心の言葉を使う
• 言葉が多すぎて、簡潔でない
• 機械的で企業的な口調
• 色だけに意味を頼る
• アクセシブルでないリンクテキストを書く（「こちらをクリック」）

クイックリファレンス

文頭のみ大文字：「変更を保存」（「変更を保存する」の各単語を大文字で始めるのではありません）
ボタンには能動態の命令形：「アカウントを削除」（「アカウントの削除」ではありません）
ユーザーを主語にする：「ショートカットで時間を節約」（「ショートカットを提供しています」ではありません）
具体的な動詞：完全に削除する場合は「削除」（「取り除く」ではありません）
重要な情報を先に示す：「パスワードは8文字以上必要です」（「パスワードには8文字必要です」ではありません）

スタイルの参考資料

このスキルの基盤となっている外部資料です（このスキルで扱われていないケースでは、これらを参照してください）。

• The Chicago Manual of Style — 文法、句読点、引用に関する質問の参考資料です。
• The Merriam-Webster Dictionary — スペルと語句の選択に関する質問の参考資料です。

リソース

このスキルには、以下が含まれています。

• references/accessibility-guidelines.md：あらゆるユーザーが利用しやすい UX テキストを書くための包括的なガイド
• references/voice-chart-template.md：プロダクトのボイスチャートを作成するためのテンプレート
• references/content-usability-checklist.md：UX テキストの品質を評価するための包括的なチェックリスト
• references/patterns-detailed.md：さまざまなボイスで書かれた UX テキストパターンの詳しい例
• examples/real-world-improvements.md：詳細な分析と採点を含む、改善前後の例
• templates/error-message-template.md：効果的なエラーメッセージを書くための記入式テンプレート
• templates/empty-state-template.md：役立つ空の状態を作成するためのガイド
• templates/onboarding-flow-template.md：分かりやすいオンボーディング体験を設計するためのフレームワーク