writing-for-interfaces

インターフェース向けのライティング

優れたインターフェースの文章は、目に留まりません。言葉がデザインに自然に溶け込んでいると、人はそれに気づかないものです。

ライティングは最初からデザインプロセスの一部であるべきで、最後に埋め合わせるものではありません。レイアウト、インタラクション、ビジュアルデザインと並行して言葉を検討すると、全体が自然につながります。後回しにすると、プロダクトの体験は継ぎはぎのように感じられます。

インターフェース内のテキストはすべて、小さなコミュニケーションの行為です。ユーザーの時間を尊重し、ユーザーの状況に寄り添い、次の行動へ進めるよう支援する必要があります。

---

トリガーされたとき

ステップ 1：ボイスと個性を定める

ボイスは基盤です。何を、どう伝え、何を伝えないかといったコピーに関する判断はすべて、このプロダクトがどのような存在で、誰のためのもので、どのような話し方をするべきかを明確に理解することから導かれます。ボイスが定義されていないと、コピーに一貫性がなくなり、プロダクト全体のまとまりが失われます。

既存のボイス定義を探します。 次を確認してください。

• ボイスやトーンを定義している CLAUDE.md、AGENTS.md、または類似のプロジェクト設定ファイル
• スタイルガイド、デザインシステムのドキュメント、またはブランドガイドライン
• 単語リストまたは用語集

ボイス定義がある場合は、すべてのコピー作業の基準として使用してください。作業中のコピーがその定義から逸脱している場合は、一貫性がないことを指摘します。

ボイス定義がない場合は、既存のコピーから現在のボイスを推測してください。パターンを探します。フォーマルか、カジュアルか。専門的か、平易か。親しみやすいか、率直か。コピーに一貫性がない、または推測するには不十分な場合は、執筆の前にユーザーがボイスを定められるよう支援してください。

対話を通じてボイスを定める

次の質問を順にユーザーに尋ねます。

1. プロダクトは何をするもので、誰のためのものですか？ 専門家向けの銀行アプリと子ども向けの貯蓄アプリは似た目的を果たしますが、話し方はまったく異なるべきです。対象ユーザーによって、語彙、複雑さ、文体が決まります。

2. 人々はなぜ、どこでそれを使いますか？ 危機的な状況で健康アプリを使う人には、落ち着いた明快さが必要です。自宅でゲームを見ている人なら、遊び心のある表現も受け入れられます。利用状況――物理的な環境、感情の状態、注意を奪うもの――によって、人がどれだけの文章を受け止められるか、どのようなトーンが適切かが変わります。

3. プロダクトを人にたとえると、個性を際立たせる特徴は何ですか？ 3～4 つ挙げてください。 自由にアイデアを出し、似た言葉をテーマごとにまとめ、「わかりにくくない」のような最低限の特性は除外し、そのプロダクトならではの個性を本当に際立たせるものを残します。

4. バランスを生み出す緊張関係を探します。 最良のボイス定義には、互いにせめぎ合う特性があります。「親しみやすい」と「簡潔」の組み合わせは、有用な緊張関係を生みます。状況に応じてトーンを調整するときに、この特性を調整の軸として使えます。

5. 記録します。 ボイス定義がセッションをまたいで維持されるよう、AGENTS.md、CLAUDE.md、またはスタイルガイドのドキュメントなど、永続的に残る場所に保存することを提案します。単語リストも併せて作成し、同じファイルに保存するとよいでしょう。

ステップ 2：依頼内容を評価する

必要なコピー作業の種類を特定します。

• 新規作成：画面、フロー、またはコンポーネント用のコピーを一から作成します。
• レビュー：既存のコピーの明快さ、一貫性、トーンを評価します。
• 書き直し：うまく機能していない特定のテキストを改善します。
• 用語：単語リストを作成または維持します。

次に、関連するインターフェースパターンを特定し、該当するセクションを references/patterns.md で確認します。

ステップ 3：ボイスを適用してから、原則を適用する

コピーの各要素について、次の順序で作業します。

1. ボイスに合った表現になっていますか？ 3～4 つの特性と照らし合わせて読んでください。声に出して読んだとき、このプロダクトのものだとわかりますか？
2. この状況では、どの特性を強めたり弱めたりする必要がありますか？ ボイスの各特性を調整つまみとして考えてください。お祝いの場面では温かさを強め、エラーでは明確さを強めて、親しみやすさを弱めます。
3. 基本原則を適用します（目的、先回り、文脈、共感。詳細は以下を参照）。
4. 文章作成のルールを適用します（冗長な表現を削り、繰り返しを避け、具体的にします。詳細は以下を参照）。

この順序には意図があり、優先順位の連鎖を示しています。明確さ > ボイス > 文章作成のルールです。明確さは常に優先されます。ボイスがユーザーの理解を妨げる場合は、ボイスを抑えてください。次にボイスが続きます。ボイスは表現の響きを形作るため、文章作成のルールに従って単語を削ったり、表現を組み替えたりすることで、確立されたボイスが損なわれてはなりません。文章作成のルールはボイスを考慮した指針であり、絶対的な規則ではありません。修正を確定する前に、必ずボイスに照らし合わせて確認してください。

ステップ 4：変更を提示する

タイトル、本文、ボタン、ラベルなど、コピーを要素ごとに確認し、元の文、修正案の順に、ボイスと原則に基づく簡潔な理由を添えて提示します。表現を磨く前に、ユーザーを混乱させたり、作業を妨げたりする箇所の変更を優先します。フロー全体を確認する際は、用語の不統一を指摘し、最後に用語リストへの追加候補を提案します。

---

ボイスとトーン

ボイスとトーンの違い

ボイスは、プロダクトの一貫したパーソナリティです。常にどのような表現をするかを定める 3～4 つの特性であり、変わることはありません。

トーンは、状況に応じたボイスの調整方法です。ボイスの各特性を調整つまみとして考え、その場面に応じて強めたり弱めたりします。

• 節目を祝うときは、温かさを強め、簡潔さを弱めます。
• エラーを伝えるときは、明確さと親切さを強め、親しみやすさを弱めます。
• 新しいユーザーをオンボーディングするときは、親切さと温かさのバランスを取ります。
• 破壊的な操作を確認するときは、率直さを強め、落ち着いた簡潔な表現を保ちます。

実際のトーンの適用方法

状況ごとに、どのボイスの特性を強調し、どの特性を控えめにする必要があるかを判断します。

例：ネットワークに接続できないというエラーでは、明確さと親切さを大きく強めます。最も重要な詳細を伝える必要があるため、わかりやすさは中程度に保ちます。温かみのある表現より、ユーザーが問題を解決できるようにすることが重要なため、親しみやすさは弱めます。

パーソナリティを発揮する場面

パーソナリティは、歓迎画面、節目、空の状態など、表現の余地がある場面で力を発揮します。エラーメッセージ、破壊的な操作、重要なフローでは、ボイスを控えめにし、明確さを優先してください。ステップ 3 の優先順位の連鎖に従い、常に明確さを最優先します。

---

基本原則

目的、先回り、文脈、共感は、何を書くか、どう書くか、いつ書くかを定めるフレームワークです。ボイスの視点から適用してください。

1. 目的

書き始める前に、次のことを考えます。今、ユーザーが知る必要のある最も重要なことは何ですか？

• 情報に優先順位を付けます。 見出しとボタンで主要なメッセージを伝え、補足テキストで詳細を加えます。見出しとボタンだけを読んでも、ユーザーが状況を理解できるようにしてください。
• この場面に必要のない内容は削ります。 別の場所に移すか、削除してください。画面に情報を詰め込みすぎている場合は、その画面の目的に立ち返り、それ以外の内容を取り除きます。
• 目的をユーザーに伝えます。 機能を紹介するときは、その機能がなぜ存在し、ユーザーにとってなぜ重要なのかを伝えてください。

2. 先回り

インターフェースを会話だと考えてください。会話がうまくいくときは、自然なやり取りがあります。相手の話を聞き、返答し、相手が次に何を知りたいかを先回りします。

• 問題を伝えたら、解決方法も伝えます。「Wi-Fiに接続できません」→「Wi-Fiに接続できません。接続を確認して、もう一度お試しください。」
• 何かをしてもらうよう頼んだら、どうすればよいかを明確に示します。「本人確認をしてください」→「本人確認をしてください」と表示し、手続きを開始するための明確なボタンやリンクを用意します。
• 何かを完了したら、それを伝え、次に何をすればよいかを示します。「パスワードを変更しました」→「パスワードを変更しました。新しいパスワードでサインインできるようになりました。」
• 「理由」を先に伝えます。 手順の前に、メリットや理由を示します。「［メリット］のため、［手順］してください。」動機を先に伝えると、指示が命令ではなく、もっともな依頼として受け取られます。

3. 文脈

人々が製品を使う状況はさまざまです。利用時の文脈によって、どのような文章が適切かが変わります。

• アプリの外にも目を向けます。 身体的、感情的な状況を考慮します。
• 使える注意力に合わせて情報量を調整します。 作業中に表示するテキストはごく短くします。初期設定の流れでは、もう少し長くてもかまいません。
• タイミングが重要です。 情報は必要なときに表示し、早すぎるタイミングでは表示しません。利用者が見ている場所に手順を配置します。
• デバイスに合わせて書きます。 操作を正しく表現します（タッチ操作では「クリック」ではなく「タップ」）。スマートフォンでは簡潔さが求められます。共有画面（テレビなど）では、大きく、ひと目で読めるテキストが必要です。

4. 共感

この製品を使う可能性のあるすべての人に向けて書きます。能力、言語、文化、技術への習熟度、感情の状態は人によって異なります。

• わかりやすく、率直な言葉を使います。 専門用語、慣用句、文化に特有の表現は避けます。
• 最初からアクセシビリティを考慮して設計します。 ラベル、説明、代替テキストは後回しにできるものではありません。一部の人にとって、それらが体験そのものです。詳しいガイダンスについては、パターンのリファレンスを参照してください。
• 誰もが受け入れやすい、中立的な言葉を使います。 性別、年齢、能力への不要な言及は避けます。
• ローカライズを考慮します。 長い文章を圧縮するのではなく、短い文章を書きます。翻訳後の文字数の増加や、RTL言語も考慮します。

---

ライティングの技術

文章を引き締めるための実践的な編集方法です。声とトーンが適切であることを確認してから適用します。

不要な言葉を取り除く

インターフェースのテキストに、最低限必要な単語数はありません。一語一語に意味を持たせます。ただし、言葉を削る前に、その言葉が声の表現に役立っているか確認してください。一般的な文章作法では「不要」とされる言葉でも、声を支える重要な役割を果たす場合があります。「まだ何もありません」の「まだ」は温かさと落ち着きを伝え、削ると空の状態を突き放した印象にします。判断基準： その言葉を削ってみて、意味も意図したトーンも変わらなければ削除します。

• 副詞・形容詞：「ライセンスプレートを簡単に入力できます」→「ライセンスプレートを入力してください。」「簡単に」「すばやく」「容易に」「ただ」「正常に」などの言葉は、保証できないことを約束してしまう場合があります（「ペットに自動で餌をあげます」のように）本当に明確さを高める言葉は残します。
• 感動詞：エラーメッセージでの「おっと！」「あら！」は、問題を軽く扱っているように感じられます。削除します。
• 丁寧なあいさつ表現：自動メッセージの「申し訳ありません」「お願いします」は、誠意がないように聞こえることがあります。本当に温かさを加える場合にだけ使います。
• 句読点：
  • 感嘆符：めったに使いません。本当に祝うべき場面に限ります。
  • ダッシュ（en/em）：インターフェースの文章では避けます。読み進めるのを妨げるためです。代わりに、別の行や文に分けます。
  • 三点リーダー：進行中の処理（「読み込み中...」など）にだけ使い、言葉を濁す表現には使いません。

繰り返しを避ける

重複する内容をひとつの明確な文にまとめます。画面上の各要素は、新しい情報を伝える必要があります。見出しと本文が言い換えで同じことを伝えている場合は、ひとつにまとめます。

「遅れが出ています。配達員は時間どおりに到着できません。10分後に到着します。」→「配達が10分遅れています。アプリで配達員の位置を確認してください。」

あいまいにせず、具体的に書く

• 対象を明示します。「このファイルを開けません」ではなく、「『Quarterly Report.pdf』を開けません」とします。
• 操作を明示します。「はい」／「いいえ」ではなく、「サブスクリプションを解約」／「サブスクリプションを継続」とします。
• 実際の情報を伝えます。「決済エラーが発生しました」ではなく、「末尾が4242のカードは承認されませんでした」とします。

用語リストを作る

対象を何と呼ぶかを決め、一貫して使います。ある画面で「エイリアス」と呼んだら、別の画面で「ユーザー名」と呼ばないでください。用語リストは、使う表現／使わない表現／定義のシンプルな表です。ボタンのラベルは、特にリストに入れるのに適しています。「次へ」でフローを進めるなら、どこでも「次へ」を使います。

代名詞と視点

「お気に入り」は「あなたのお気に入り」と同じことを伝えます。「私たち」は避けてください。実際に何が起きたのかが曖昧になるためです（「問題が発生しています……」→「コンテンツを読み込めません」）。

細部にも気を配る

正しいスペル、文法、句読点は信頼につながります。製品の語調に合った大文字・小文字のルール（タイトルケース＝フォーマル、センテンスケース＝カジュアル）を決め、一貫して適用します。利用できるスペースに合わせて書きます。短くする必要がある場合は、長い文を圧縮するのではなく、短い文を書きます。

動的コンテンツを想定して書く

テンプレート文字列（"${count} items selected"）もインターフェースの文言です。どのような出力になっても自然に読めるように書きます。

• 0件、1件、複数件に対応します。「結果はありません」、「1件の結果」、「24件の結果」のようにします。「0件の結果が見つかりました」と表示する単一のテンプレートは使いません。
• 実際の値を入れて確認します。 短い名前と長い名前、小さい数値と大きい数値に置き換えてみます。「おかえりなさい、Christopher-Montgomery！」ではレイアウトが崩れるかもしれません。「3秒前」と「2日前」のどちらも自然に読めるようにします。
• テンプレートはシンプルにします。 自然に読ませるために複雑な条件分岐が必要なら、1つの要素に求めすぎている可能性があります。

表現のパターンを整える

よくある場面での表現を決めます。フローの開始（「始める」）、進行（「次へ」または「続ける」のどちらか一方）、終了（「完了」）などです。一貫して使います。

---

最も簡単なテスト

書いたものを声に出して読んでみます。友人に説明するように、明確で自然で、余計な言葉がなければ、おそらく問題ありません。ロボットのよう、法律文書のよう、または小論文のように聞こえる場合は、さらに推敲します。

---

パターンのリファレンス

アラート、エラー、空の状態、オンボーディング、通知、アクセシビリティラベル、破壊的操作、ボタン、操作説明の詳しいガイダンスについては、references/patterns.mdを参照してください。