ux-writing

UX ライティング

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

対応対象： Claude、Codex、Cursor、およびエージェントスキル仕様に対応するその他のエージェント。

注： このスキルは Codex CLI／IDE で動作し、ChatGPT では動作しません。ChatGPT ではスキルをインストールしたり使用したりできません。

このスキルを使う場面

次のような場面で、このスキルを使用します。

• インターフェース文言（ボタン、ラベル、タイトル、メッセージ、フォーム）を作成するとき
• 既存の UX テキストを明確で効果的なものに編集するとき
• エラーメッセージ、通知、成功メッセージを作成するとき
• 会話型のフローやオンボーディングエクスペリエンスを設計するとき
• 製品のボイスとトーンを確立するとき
• 製品コンテンツの一貫性と使いやすさを監査するとき

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

4 つの品質基準

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

1. 目的が明確 — ユーザーやビジネスの目標達成に役立つ
2. 簡潔 — 意味を損なわず、できるだけ少ない言葉で表現する
3. 会話的 — ロボットのようではなく、自然で人間らしく聞こえる
4. 明確 — 誤解の余地がなく、正確で、理解しやすい

主なベストプラクティス

簡潔さ

• 1 行あたり最大 40～60 文字にする
• すべての言葉に役割を持たせる
• 情報量の多いテキストは、拾い読みしやすい単位に分ける
• 重要な情報を先に伝える

明確さ

• 平易な言葉を使う（一般向けは 7 年生、専門家向けは 10 年生程度の読解レベル）
• 専門用語、慣用表現、技術用語を避ける
• 全体を通して用語を統一する
• 意味が明確で具体的な動詞を選ぶ

会話的なトーン

• 話し言葉のように書く
• 85％の場面で能動態を使う
• 前置詞や冠詞を含める
• ロボットのような言い回しを避ける

ユーザー中心

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

UX テキストのパターン

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

タイトル

• 目的：ユーザーが現在いる場所を把握できるようにする
• 形式：名詞句、文頭のみ大文字
• 種類：ブランドタイトル、コンテンツタイトル、カテゴリタイトル、タスクタイトル
• 例：「アカウント設定」、「あなたのライブラリ」、「新しい投稿を作成」

ボタンとリンク

• 目的：ユーザーが操作できるようにする
• 形式：能動態の命令形、文頭のみ大文字
• パターン：[動詞] [目的語]
• 例：「変更を保存」、「アカウントを削除」、「詳細を表示」
• 避ける表現：「OK」、「送信」、「ここをクリック」などの汎用的なラベル

エラーメッセージ

• 目的：問題を説明し、解決策を示します
• 形式：相手に寄り添い、明確で、実行可能な内容にします
• パターン：[失敗した内容]。 [理由や背景]。 [対処方法]。

エラーメッセージの種類

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

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

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

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

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

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

権限エラー

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

避けること

• 説明のない技術コード（「エラー 403」）
• 相手を責める表現（「無効な入力です」「不正な文字です」）
• 機械的な口調（「エラーが発生しました」）
• 解決策のないメッセージ
• あいまいな原因（「問題が発生しました」）

成功メッセージ

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

空の状態

• 目的：コンテンツがない場合にユーザーを案内します
• 種類：初回利用時、ユーザーが消去した場合、エラー／該当結果なし
• 形式：説明 + 入力を促す CTA
• 例：「メッセージはまだありません。チームとつながるには、会話を始めましょう」

フォームの入力欄

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

通知

• 目的：適切なタイミングで価値のある情報を届けます
• 種類：対応が必要（割り込みあり）、受動的（割り込みが少ない）
• 形式：動詞から始まるタイトル + 状況に応じた説明
• 例：「アップデートが必要です。続行するには、最新バージョンをインストールしてください」

ボイスとトーン

ボイス（一貫したブランドの個性）

ボイスとは、製品が一貫して持つ個性です。以下を使ってボイスを確立します。

• コンセプト：ブランドの主要な原則／価値観を 3〜5 個
• ボイスの特徴：各コンセプトを表す形容詞
• Do／Don't の例：ボイスを具体的に示す例

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

トーン（文脈に応じて調整）

トーンとは、特定の状況に合わせて声の調子を調整することです。声の一貫性は保ちながら、ユーザーの状況や感情に応じてトーンを変化させます。

トーンを左右する要素

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

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

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

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

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

• 辛抱強く、説明を加える
• 手順を明確に分ける
• 背景情報とガイダンスを提供する
• 例：「利用状況の分析を見るには、銀行口座を連携してください。手順をご案内します。」

自信がある場合（日常的なタスク、再訪時）

• 効率的で簡潔にする
• 説明は最小限にする
• すばやく確認する
• 例：「保存しました」

慎重な場合（重要度の高い操作、データ損失）

• 真剣で透明性のある表現にする
• 結果を明確に伝える
• ユーザーの決定を尊重する
• 例：「アカウントを削除しますか？すべてのデータが失われ、この操作は取り消せません。」

成功した場合（完了、達成）

• 前向きに励ます
• 達成内容に応じた表現にする
• 簡潔に祝う
• 例：「プロフィールを更新しました。変更が反映されました。」

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

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

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

成功メッセージ：前向きで具体的に励ます

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

手順：明確で直接的、役に立つ表現にする

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

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

• 圧倒させずに歓迎する
• 価値に焦点を当てる
• 初期の成功を称える

確認：真剣で透明性があり、敬意を示す

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

空の状態：希望を持たせ、行動を促し、案内する

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

編集プロセス

UX テキストは、次の 4 つの段階で編集します。

Phase 1: 目的に沿った内容

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

Phase 2: 簡潔さ

• 不要な言葉を削除する
• 重複する情報をまとめる
• すべての言葉に意味を持たせる
• 重要な概念を最初に示す

Phase 3: 会話調

• 声に出して読む——実際にこのように話しますか？
• 能動態を使う（受動態のほうが明確な場合を除く）
• 自然なつなぎの言葉を入れる
• 企業特有の専門用語を避ける

Phase 4: 明確さ

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

ワークフロー

1. 状況を把握する

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

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

   • 会話を出発点にする（どのように話すか）
   • 適切なパターンを適用する
   • 声の調子とトーンを考慮する
   • 重要な情報を最初に示す

3. 繰り返し編集する

   • Phase 1: 目的に沿った内容
   • Phase 2: 簡潔さ
   • Phase 3: 会話調
   • Phase 4: 明確さ

4. テストして測定する

   • チームでレビューする
   • 可能であればユーザーでテストする
   • タスクの完了率と理解度を測定する
   • フィードバックに基づいて改善を繰り返す

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

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

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

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

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

認知アクセシビリティ

• 1 文あたり 8～14 語を目安にします（8 語なら理解度 100％、14 語なら 90％）
• 複雑な情報は、ひと目で確認しやすいまとまりに分けます
• 明確な見出しと論理的な階層を使います
• 一貫性があり、予測しやすいパターンを提供します

複数の方法による情報伝達

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

誰にとってもわかりやすい表現

• 一般向けの文章は、7～8 年生程度の読解レベルを目安にします
• 技術用語は、初めて使う際に説明します
• 慣用句、比喩、文化的な言及は避けます
• 日常的によく使う言葉を選びます

アクセシブルな表現の例

ボタン

• ❌ 悪い例：「送信」（スクリーンリーダーで文脈がわかりません）
• ✅ 良い例：「申請を送信」

リンク

• ❌ 悪い例：「詳細についてはこちらをクリック」
• ✅ 良い例：「プライバシーポリシーを読む」

エラーメッセージ

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

フォームのラベル

• ❌ 悪い例：プレースホルダーだけの入力欄
• ✅ 良い例：表示されるラベルと任意のプレースホルダー

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 文字

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

対象読者別

• 一般の人々：7～8 年生程度（Flesch-Kincaid）
• 業務用ツール：9～10 年生程度
• 技術製品：10～11 年生程度
• 専門分野：11～12 年生程度（必要な場合のみ）

テストツール

• Hemingway Editor：複雑な文章を強調表示します
• Readable.com：複数の読みやすさスコアを表示します
• Microsoft Word：Flesch-Kincaid のスコアを標準で算出できます

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

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

クイックリファレンス

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

リソース

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

• 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：わかりやすいオンボーディング体験を設計するためのフレームワーク
• docs/figma-integration.md：Figma MCP（Claude Code、Codex、Cursor）でこのスキルを使用するためのガイド