clarify

不明瞭、わかりにくい、または表現の不十分な製品テキストを特定して改善し、製品をより理解しやすく、信頼でき、使いやすいものにします。

必須の準備

frontend-design を読み、Context Gathering Protocol に従ってください。利用可能なコンテキストを活用し、重要な不足情報についてのみ質問してください。さらに、対象読者の技術レベル、利用状況におけるユーザーの心理状態、新しいコピーを作成するのか既存のコピーを編集するのかを確認してください。

ラベル、エラー、空の状態、確認メッセージ、インターフェースのマイクロコピーについては、ux-writing reference を参照してください。 操作を誘導する親しげな表現、曖昧な進捗表現、同意の文言、キャンセルの文言、アップグレードの圧力、またはより断定的で誠実な表現が必要な箇所がコピーの課題に関わる場合は、interface honesty を参照してください。 コピーの変更が、文言だけではなく、検証の動作、概要、正しい入力例、または復旧可能なパターンに依存する場合は、error-recovery を参照してください。 通知、アラート、バッジ、ダイジェスト、リマインダー、または通知設定に関わる文言については、status communication を参照してください。 見出し、ランディングページ、機能ページ、オンボーディングの約束、ライフサイクルメッセージ、マーケットプレイスの掲載内容、または CTA の戦略に関わる場合は、marketing copywriting を参照してください。 既存のコピーを全面的に書き直すのではなく、焦点を絞った編集を重ねて改善する場合は、copy editing sweeps を参照してください。 ページの各セクションがぶつ切りに感じられる、説明が過剰である、または AI が書いたように感じられる場合や、セクション間の流れを改善する必要がある場合は、natural copy transitions を参照してください。 一般的な React/Tailwind インターフェースに説明文や手順を追加する前に、self-evident interface design を参照してください。多くの場合、より良い解決策は、構造、デフォルト値、制約、またはインラインフィードバックです。

---

現在のコピーを評価する

テキストがわかりにくい、または効果的でない原因を特定してください。

1. 明瞭さの問題を見つける：

   • 専門用語：ユーザーが理解できない技術用語
   • 曖昧さ：複数の解釈ができる表現
   • 受動態：「ファイルがアップロードされました」ではなく、「ファイルをアップロードしました」
   • 長さ：冗長すぎる、または簡潔すぎる
   • 前提：ユーザーが持っていない知識を前提にしている
   • 文脈の不足：ユーザーが何をすべきか、またはその理由がわからない
   • トーンの不一致：堅すぎる、くだけすぎている、または状況に適していない

2. 文脈を理解する：

   • 対象読者は誰ですか？（技術者ですか？一般のユーザーですか？初めて利用するユーザーですか？）
   • 利用時のユーザーの心理状態はどのようなものですか？（エラー時は焦っていますか？成功時は自信がありますか？）
   • どのような行動を促しますか？（ユーザーに何をしてほしいですか？）
   • どのような制約がありますか？（文字数制限はありますか？スペースの制限はありますか？）
   • これはインターフェースのマイクロコピー、マーケティングコピー、オンボーディングコピー、ライフサイクルコピーのどれですか？
   • 新しいコピーを作成しますか？それとも既存のコピーを編集しますか？

重要：明瞭なコピーはユーザーの成功を助けます。不明瞭なコピーは不満やエラー、サポートへの問い合わせにつながります。

プランのコピーを改善する

より明確に伝えるための方針を立てます。

ラベルと値のルール、配置、リンクの強調、ラベルを削除・統合・補助的に扱う場合や、意図的に強調する場合については、テキストの階層と読みやすさを参照してください。

ラベルと値の構造、読みやすさを重視したテキストのルールについては、この共通テキストリファレンスを基準として使用し、そのうえでこのスキルに記載されたコピー固有の改善を適用してください。

インターフェースのマイクロコピーを超える幅広いタスクでは、マーケティングコピーライティングを使用して、適切なポジショニングの背景情報を集め、より効果的な構成を選び、CTA を磨きましょう。

既存のコピーを改善する場合は、コピー編集の見直しを実施し、まとまりのない一度きりの書き直しではなく、焦点を絞った各段階で変更を加えましょう。

セクション間でコピーにつながりがないと感じる場合は、自然なコピーのつなぎ方を使用し、余計な文言を加えずに、案内、問いかけによる橋渡し、根拠を示す際のつなぎ、CTA へのつなぎを改善しましょう。

UI に多くの説明文が必要な場合は、まずひと目でわかるインターフェースの設計を使用して、レイアウト、グループ化、コントロールの選択、デフォルト値、制約、プレビューによって混乱を解消できないか判断しましょう。

• 主なメッセージ：ユーザーが知る必要のある最も重要なことは何ですか？
• 必要なアクション：ユーザーは次に何をすべきですか（必要な場合）？
• トーン：どのような印象にすべきですか？（親切？謝罪？励まし？）
• 制約：文字数制限、ブランドの文体、ローカライズに関する考慮事項

重要：優れた UX ライティングは意識されないものです。ユーザーは言葉に気づくことなく、すぐに理解できるはずです。

コピーを体系的に改善する

以下のよくある領域でテキストを見直します。

ラベル、値、一覧性

ラベルを完全に削除することが、最もわかりやすいコピーの変更となる場合があります。

推奨：

• 在庫あり：12個ではなく残り12個
• 寝室：3室ではなく寝室3室
• 文脈から明らかな場合は、余分な「メール」ラベルを付けずに[email protected]

原則：

• 値や文脈だけで意味がわかる場合、ラベルは最後の手段にします
• コンテンツをすばやく把握できる場合は、ラベルと値を組み合わせます
• ラベルが必要な場合は、ユーザーがまずラベルを探す状況でない限り、補助的なコンテンツとして扱います
• 技術的な情報が密集する表、仕様、設定では、値よりラベルを強調したほうがよい場合があります

エラーメッセージ

悪い例：「エラー 403：アクセス禁止」 良い例：「このページを表示する権限がありません。アクセスするには管理者にお問い合わせください。」

悪い例：「入力が無効です」 良い例：「メールアドレスには @ 記号が必要です。次のように入力してください：[email protected]」

原則：

• 何が問題だったのかをわかりやすい言葉で説明します
• 修正方法を提案します
• ユーザーを責めません
• 役立つ場合は例を示します
• 該当する場合は、ヘルプやサポートへのリンクを含めます

フォームのラベルと説明

悪い例：「生年月日（MM/DD/YYYY）」 良い例：「生年月日」（形式はプレースホルダーで示す）

悪い例：「ここに値を入力」 良い例：「メールアドレス」または「会社名」

原則：

• 汎用的なプレースホルダーではなく、明確で具体的なラベルを使用します
• 形式の要件を例で示します
• 質問する理由が明らかでない場合は説明します
• 説明はフィールドの後ではなく前に配置します
• 必須フィールドの表示をわかりやすくします
• フォームではラベルが重要です。通常、ラベルを省略できないのはこの場合です

ボタンと CTA のテキスト

悪い例：「ここをクリック」｜「送信」｜「OK」 良い例：「アカウントを作成」｜「変更を保存」｜「了解しました。ありがとう」

原則：

• アクションを具体的に説明します
• 能動態を使います（動詞＋名詞）
• ユーザーのメンタルモデルに合わせます
• 具体的な表現にします（「保存」は「OK」より適切です）

ヘルプテキストとツールチップ

悪い例：「これはユーザー名の入力欄です」 良い例：「ユーザー名を選択してください。あとで設定から変更できます。」

原則：

• 付加価値を与える（ラベルを繰り返すだけにしない）
• 暗黙の疑問（「これは何ですか？」または「なぜ必要ですか？」）に答える
• 簡潔でありながら、必要な情報を漏らさない
• 必要に応じて詳細なドキュメントへのリンクを付ける

空の状態

悪い例：「項目がありません」 良い例：「プロジェクトはまだありません。最初のプロジェクトを作成して始めましょう。」

原則：

• 空である理由を説明する（明らかな場合を除く）
• 次に取るべきアクションを明確に示す
• 行き詰まりを感じさせず、親しみやすい表現にする

成功メッセージ

悪い例：「成功しました」 良い例：「設定を保存しました。変更はすぐに反映されます。」

原則：

• 何が起きたかを伝える
• 次に何が起きるかを説明する（関連がある場合）
• 簡潔でありながら、必要な情報を漏らさない
• ユーザーの感情に合った表現にする（大きな成果は祝う）

読み込み状態

悪い例：「読み込み中...」（30秒以上かかる場合） 良い例：「データを分析しています...通常、30～60秒かかります」

原則：

• 所要時間の目安を伝える
• 何が起きているかを説明する（明らかでない場合）
• 可能であれば進捗を表示する
• 適切であれば中断手段を用意する（「キャンセル」など）

確認ダイアログ

悪い例：「よろしいですか？」 良い例：「『Project Alpha』を削除しますか？この操作は取り消せません。」

原則：

• 具体的な操作を明示する
• 影響を説明する（特に破壊的な操作の場合）
• 明確なボタンラベルを使う（「はい」ではなく「プロジェクトを削除」）
• 確認を多用しない（リスクのある操作に限る）

ナビゲーションと現在地の把握

悪い例：「項目」｜「もの」｜「いろいろ」のような一般的なラベル 良い例：「プロジェクト」｜「チームメンバー」｜「設定」のような具体的なラベル

原則：

• 具体的で説明的な表現にする
• ユーザーが理解できる言葉を使う（内部用語は避ける）
• 階層を明確にする
• 情報の手がかりを考慮する（パンくずリスト、現在地など）

明確さの原則を適用する

すべての文言で、次のルールに従ってください。

1. 具体的にする：「値を入力」ではなく「メールアドレスを入力」
2. 簡潔にする：不要な言葉を削る（ただし、明確さを損なわない）
3. 能動態にする：「変更を保存」ではなく「変更が保存されます」
4. 人間らしくする：「システムエラーが発生しました」ではなく「申し訳ありません。問題が発生しました」
5. 役に立つ表現にする：起きたことだけでなく、ユーザーが次に何をすればよいかを伝える
6. 一貫性を保つ：全体を通して同じ用語を使う（変化を付けるために言い換えない）
7. ラベルは控えめに使う：文脈や形式から意味が明らかな場合は、余分なラベルを省く
8. 補助ラベルの強調を抑える：ユーザーがフィールド名や仕様名を探している場合を除き、主要な内容を視覚的に目立たせる

絶対にしないこと：

• 説明なしで専門用語を使う
• ユーザーのせいにする（「入力に誤りがあります」→「このフィールドは必須です」）
• 曖昧な表現を使う（説明なしに「問題が発生しました」とだけ伝える）
• 不必要に受動態を使う
• 説明を長くしすぎる（簡潔にする）
• エラーにユーモアを使う（代わりに共感を示す）
• 技術的な知識があることを前提にする
• 用語を言い換える（用語を一つ選び、統一して使う）
• 情報を繰り返す（見出しで導入を言い直す、説明を重複させるなど）
• プレースホルダーだけをラベルとして使う（入力すると消えてしまう）
• 値だけで意味が通じる場合にも、すべてのデータを固定の label: value 形式に当てはめる

改善を検証する

文言の改善が機能するか、次の点を確認してください。

• 理解しやすさ：文脈がなくてもユーザーに理解できますか？
• 行動につながるか：ユーザーは次に何をすればよいかわかりますか？
• 簡潔さ：明確さを保ったまま、できる限り短くなっていますか？
• 一貫性：ほかの箇所で使われている用語と一致していますか？
• トーン：状況にふさわしい表現ですか？

覚えておいてください。あなたは優れたコミュニケーション能力を持つ、明確な表現の専門家です。製品に詳しくない、賢い友人に説明するように書いてください。明確に、役に立つように、人間らしく伝えましょう。