Claudeのux-copyスキルでエラー文言と空状態文言を書く手順
Anthropicのdesignプラグインにあるux-copyスキルで、エラーメッセージ・空状態・確認ダイアログの文言を作る手順。導入、渡す情報、日本語UIでの補い方、出力の検証まで。
ux-copyは、画面に出す短い文言を書く・見直すためのスキルです。エラーメッセージ、空状態、ボタンのラベル、確認ダイアログが主な対象で、Anthropicが公開するdesignプラグインの一部として配られています。
この記事では、導入からスキルの呼び出し方、渡すと出力が良くなる情報、型ごとの書き方、日本語のUIで補う点までを順に扱います。最後に、出てきた文言をコードの側で検査する方法も置きます。
ux-copyスキルは何を書いてくれるのか
ux-copyは、knowledge-work-plugins リポジトリの design/skills/ux-copy にある SKILL.md 1枚のスキルです。frontmatterの説明は「UXコピー(マイクロコピー、エラーメッセージ、空状態、CTA)を書く、またはレビューする」という趣旨で、次のような場面が起動の目安として列挙されています。
- 「write copy for」(〜の文言を書いて)と頼むとき
- 「what should this button say?」(このボタンには何と書くべきか)と尋ねるとき
- 「review this error message」(このエラーメッセージを見直して)と頼むとき
- CTAの名前付け、確認ダイアログの文言、空状態の穴埋め、オンボーディング文の作成
つまり、新しく書く依頼と、既にある文言のレビューの両方を受けます。スキルの本文は英語で書かれており、出力も英語を前提にしたテンプレートです。日本語のUIにそのまま当てる場合の補い方は後の節で扱います。
同じプラグインに入っている兄弟スキル
designプラグインは、ux-copy以外にも6つのスキルを持ちます。ディレクトリ名で並べると、accessibility-review、design-critique、design-handoff、design-system、research-synthesis、user-research です。プラグインのバージョンは1.2.0で、作者はAnthropicと記載されています。
プラグインのREADMEは、これを「主にCowork向けに設計されたが、Claude Codeでも動く」デザイン生産性プラグインと説明しています。Claude Codeでコードを書きながら、UI文言だけをこのスキルに任せる使い方が、この記事の主題です。画面そのものの出来を点検したいときは、同じ系列のfrontend-designプラグインが別の役割を持ちます。
designプラグインを入れて呼び出す
導入はREADMEに書かれた2コマンドです。マーケットプレイスの追加と、プラグインのインストールを分けて実行します。
claude plugin marketplace add anthropics/knowledge-work-plugins
claude plugin install design@knowledge-work-pluginsClaude Codeのドキュメントによると、claude plugin install は既定でユーザースコープに入ります。リポジトリの全員に配りたいときは --scope project を付け、各自が一度ずつ同じコマンドを実行します。設定ファイルにエントリをコミットしただけでは、プラグイン本体は協力者の手元にダウンロードされません。
呼び出し名は /ux-copy か /design:ux-copy か
READMEの例は /ux-copy と書かれています。一方、Claude Codeではプラグインのスキルが /プラグイン名:スキル名 の名前空間付きで呼ばれます。designプラグインのux-copyなら /design:ux-copy が正式な形です。
補完候補に /ux-copy が出ないときは、名前空間付きで打つと確実です。個人用のスキルやプロジェクトのスキルと名前が重なっても、プラグインのスキルは名前空間で区別され、両方が読み込まれます。
/design:ux-copy 決済に失敗したときのエラーメッセージ(カード会社に拒否された場合)引数はそのままスキルに渡されます。スキルのfrontmatterには argument-hint: "<context or copy to review>" があり、「文脈」か「見直したい文言」を渡す想定です。
文言の依頼だけなら呼び出しは不要なこともある
説明文に起動の目安が書かれているので、「このボタンには何と書くべきか」と普通に尋ねるだけで、Claudeがスキルを読み込む場合があります。確実に使いたいときや、出力の形式を揃えたいときは、スラッシュで明示的に呼ぶほうが安定します。
渡す情報が出力の質を決める
スキルは冒頭で、依頼者に4つの情報を求めています。
| 項目 | 内容 | 渡し方の例 |
|---|---|---|
| Context | 内容どの画面・フロー・機能か | 渡し方の例「請求設定画面の支払い方法の追加」 |
| User state | 内容ユーザーが何をしようとし、どんな気持ちか | 渡し方の例「期限内に払いたいのに失敗して焦っている」 |
| Tone | 内容堅い、親しみ、遊び、安心させる | 渡し方の例「丁寧で落ち着いた調子」 |
| Constraints | 内容文字数制限やプラットフォームの指針 | 渡し方の例「ボタンは全角8字まで」 |
Tipsの節にも同じ趣旨が並んでいます。「決済が失敗したときのエラーメッセージ」のように場面を特定すること、ブランドの声(「専門的だが温かい」など)を伝えること、ユーザーの感情を考慮すること、の3点です。
5つの原則が文言の判断軸になる
スキルが挙げる原則は、明確(曖昧さと専門用語を避ける)、簡潔、一貫(同じものには同じ語)、有用(すべての語が目的の達成に役立つ)、人間的(ロボットでなく助けてくれる人のように書く)の5つです。レビューを頼むときは、この5つの軸で既存の文言が崩れていないかを見る形になります。
型ごとの書き方と、スキルが示す例
スキルは文言の種類ごとに型を持っています。ここが他の汎用的な「文章を直して」との違いです。
| 種類 | 型 | スキルの例(原文は英語) |
|---|---|---|
| CTA | 型動詞で始め、具体的に、結果とラベルを一致させる | スキルの例(原文は英語)「Start free trial」「Create account」(「Submit」ではなく) |
| エラー | 型何が起きたか + なぜ + どう直すか | スキルの例(原文は英語)「Payment declined. Your card was declined by your bank. Try a different card or contact your bank.」 |
| 空状態 | 型これは何か + なぜ空か + どう始めるか | スキルの例(原文は英語)「No projects yet. Create your first project to start collaborating with your team.」 |
| 確認ダイアログ | 型操作を明示し、結果を説明し、ボタンに動作名を付ける | スキルの例(原文は英語)「Delete 3 files?」「This can't be undone」「Delete files / Keep files」 |
| ツールチップ | 型簡潔で役に立ち、自明なことは書かない | スキルの例(原文は英語)(例なし) |
| 読み込み中 | 型見通しを示し、不安を減らす | スキルの例(原文は英語)(例なし) |
| オンボーディング | 型段階的に、一度に1つの概念 | スキルの例(原文は英語)(例なし) |
調子は場面で変える
声と調子の節は、成功は「祝うが大げさにしない」、エラーは「共感的で役に立つ」、警告は「明確で行動につながる」、中立は「情報的で簡潔」と整理しています。エラーを面白くしない、成功を過剰に盛り上げない、という二つの失敗を避ける目安になります。
確認ダイアログをスキルの型で直す
直す前
「本当によろしいですか?」と、ボタンは「OK」「キャンセル」。何を消すのか、戻せるのかが画面から読めません。
直した後
「ファイル3件を削除しますか?」「この操作は元に戻せません」。ボタンは「ファイルを削除」「削除しない」で、押した結果がラベルから分かります。
この例は、スキルの確認ダイアログの型(操作の明示、結果の説明、動作名のラベル)を日本語に当てはめた一例です。スキルが日本語の出力を保証しているわけではありません。
出力のかたち — 代替案と翻訳メモまで付く
ux-copyの出力は、次の構成で返すよう指定されています。
- 推奨する文言(要素ごと)
- 代替案の表(案A〜C。文言、調子、向く場面の列)
- 理由(ユーザーの文脈、明確さ、行動の促し)
- ローカライズの注記(翻訳者が知るべきこと。避けるべき慣用句、文字数の増加、文化的な背景)
代替案が調子付きで並ぶため、「丁寧」「親しみ」「簡潔」のどれを採るかを、その場で比べて選べます。理由が一緒に出るので、デザインレビューで「なぜこの文言か」を問われたときの下書きにもなります。
ローカライズの注記を日本語化の入口にする
出力の最後にあるローカライズの注記は、英語の文言を日本語に直す前の確認に使えます。文字数が増える言語では、ボタンの幅に収まらないことがよくあります。注記を見て、日本語に直したときの長さと言い回しの差を先に洗えます。
ただし、スキルは日本語の敬体・常体の使い分けや、ボタン文言の体言止めのような日本語UI固有の慣習を持っていません。そこは次の節のように、プロジェクト側のルールで補います。
日本語のUIで使うときにCLAUDE.mdで補う
スキルの例文はすべて英語で、日本語の指針は含まれていません。日本語のプロダクトでは、文体と語彙のルールをCLAUDE.mdに書いておくと、スキルの出力がそのルールに沿います。次は、そのための断片の一例です。
## UI文言のルール
- 文体は「です・ます」。命令形や体言止めはボタンのラベルだけに使う
- ボタンは「動詞 + 目的語」(例: 「ファイルを削除」)。「OK」「はい」「送信」は使わない
- エラーは「何が起きたか → 原因 → 次の操作」の順。謝罪は1文まで
- 用語は locales/glossary.md の表記に統一する(「ログイン」と「サインイン」を混在させない)
- ボタンは全角10字以内、エラー本文は全角60字以内/design:ux-copy を呼ぶときは、「CLAUDE.mdのUI文言のルールに従って、日本語で」と一言添えます。スキルが求める4情報のうち、ToneとConstraintsをこのファイルが肩代わりする形です。
用語集を知識ベースとして渡す
スキルは、知識ベース系のコネクタ(例としてNotion)が繋がっていれば、ブランドの声のガイドや既存の文言パターン、用語の標準を引くと書いています。コネクタを使わない場合は、同じ内容をリポジトリ内の locales/glossary.md に置き、依頼文で参照させる運用でも近いことができます。
Figmaが繋がっている場合
デザインツール系のコネクタが繋がっていれば、Figmaで画面の全体の流れを見たり、デザインに設定された文字数や配置の制約を確認したりできる、とスキルは説明しています。designプラグインの設定には、Figma、Notion、Slack、Linearなどを指すMCPサーバーが同梱されています。FigmaをClaude Codeに繋ぐ手順はFigma MCPサーバーの使い方にあります。
出てきた文言をコードで検査する
文言は、書かせて終わりにするとリポジトリの中で徐々に崩れます。禁止ラベルの混入だけでも、機械的に拾えます。次は、翻訳ファイルに「OK」や「キャンセル」だけのボタン文言が残っていないかを検査する、小さなシェルの例です。
# locales/ja.json に、ラベルとして「OK」「キャンセル」「はい」が単独で残っていないか
grep -nE '"(OK|キャンセル|はい|送信)"' locales/ja.json \
&& echo "動作名のラベルに直してください" \
|| echo "禁止ラベルなし"Claude Codeに「このスクリプトの結果を見て、該当キーをux-copyの型で直して」と頼めば、検査 → 修正 → 再検査の反復になります。CIに入れれば、後から追加された文言にも同じ基準が効きます。
効かない場面と注意点
- README表と実際のスキル名にずれがある: READMEのスキル表には
ux-writingやdesign-system-managementが出ますが、リポジトリのスキルのディレクトリ名はux-copyとdesign-systemです。呼び出し名はディレクトリ側(/design:ux-copy)で考えるのが確実です - 日本語の出力は保証されない: スキルの本文は英語で、例も英語です。日本語化にはCLAUDE.mdか依頼文でのルール補足が前提です
- ファイルは書き換えない: スキルの出力はMarkdownの提案で、翻訳ファイルへの反映は別の指示で行います。反映範囲を決めたうえで依頼します
- Cowork中心の設計: READMEは主な対象をCoworkと述べています。Claude Codeでも動作するとされていますが、画面のスクリーンショットを渡して見直させる使い方は、READMEがスタンドアロンの入力として挙げています。Coworkでのプラグイン運用はcowork-plugin-managementの解説にあります
- コネクタは任意: 何も繋がなくても、文脈を文章で渡せばスキルは動きます。Figmaなどを繋ぐと、画面の制約を読みに行けるようになるだけです
最初の1回をどう試すか
最初は、既にあるエラーメッセージ1本をレビューに出すのが手軽です。新規作成より、直す前後の差が見えやすくなります。
最初の1回の進め方
- 1
直したい文言を1つ選ぶ
利用者から問い合わせの多いエラー、または「OK / キャンセル」のままの確認ダイアログが向いています。
- 2
4つの情報を添えて呼ぶ
場面、ユーザーの状態、調子、文字数の制約を1〜2文で書き、
/design:ux-copyに渡します。 - 3
代替案の表から選ぶ
案A〜Cの調子と向く場面を見て、プロダクトの声に近いものを採ります。理由の欄は、PRの説明にそのまま使えます。
- 4
検査を足して固定する
禁止ラベルの検査をCIに入れ、同じ型から外れた文言が増えないようにします。
ux-copyの価値は、文言の「型」を毎回呼び出せる点にあります。「何が起きた → なぜ → どう直す」の骨格がチームで揃うので、書き手によって文言の質がぶれにくくなります。文体の細部はCLAUDE.mdで、制約の検査はコードで持たせると、スキルの出力がプロジェクトの基準に収まります。文章の文体規格を使い分けたい場合は、writing-skillsプラグインも併せて見ると役立ちます。