copywriting

コピーライティング

• 対象: 短いコンバージョン向けコピー（ランディングページ、ヒーローコピー、小見出し、CTA、製品説明、オンボーディング文言、メールの件名）、製品状態の文言（破壊的な CTA、エラー、成功、空状態、読み込み中、権限に関する文言）、あらゆるコピーから AI らしい表現を取り除くこと。
• 対象外: 長文記事や投稿、人ではなくブランドとして書かれたもの以外の文章（プラットフォームに blog を指定して、外部の ghostwriter スキルを使用してください）、スライドやプレゼン資料のコピー（presentation-creator を使用してください）、API／製品／リファレンスのドキュメント（docs-writing を使用してください）、セッション中のアシスタントとの会話（eli5 を使用してください）、または、どのアクションを用意するか、その範囲、結果、取り消し可能性、到達可能な状態を決めること（product-design を使用してください。このスキルでは、それらが決まった後に最終的な文言を作成します）。

モードは 2 つあり、自動的に判定されます。

• コピーが存在する、またはユーザーが修正対象のコピーを貼り付けた場合：モード B（編集）。
• まだ何も書かれていない、またはユーザーが新しいコピーを求めている場合：モード A（執筆）。
• 本当に曖昧な場合（「改善して」とあるが対象のコピーがない場合）：質問を 1 つしてから、モードを決定します。

参照ファイル

ファイル	読み込むタイミング
references/frameworks.md	認知段階に応じたフレームワークを選ぶとき（執筆ステップ 4）、フレームワークに照らして監査するとき（編集ステップ 3）
references/page-types.md	ホームページ、ランディングページ、料金ページ、機能ページ、会社概要ページのコピー規範を確認するとき（執筆ステップ 4）
references/word-lists.md	Tier 1／2／3 の AI 関連語彙を指摘するとき（編集ステップ 4）
references/ai-patterns.md	構成、文単位、執筆時の AI らしい表現を指摘するとき。P0／P1／P2 の優先順位付け（編集ステップ 4）
references/sweeps.md	7 つの行単位の見直しを行い、その後ハイフネーションを確認するとき（編集ステップ 5）
references/ui-states.md	コピーがマーケティングではなく、製品状態やアクションラベルの場合（執筆ステップ 4。[STATE-COPY] を使用する前に編集ステップ 6）
references/voice-chart.md	使用可能なボイスファイルがなく、製品用に作成する必要がある場合（執筆ステップ 3、編集ステップ 1）。読者の状態ごとのトーンをまとめた表も記載されています
evals/evals.json	このスキルを変更するときのみ。アサーション付きの動作シナリオと、起動すべきケースおよび誤検出に近い振り分け用プロンプトが含まれています。ユーザーのタスク中に読み込まれることはありません

使用禁止語

決して使用しない語句です。両方のモードで、返すすべての行に適用されます。

delve, leverage (verb), robust, seamless, holistic, paradigm, game-changing, cutting-edge, innovative, synergy, revolutionary, effortless, world-class, powerful, showcase, unlock

主張としての 「simple」 も禁止です（例：「当社のシンプルなオンボーディング」）。最初から約束するには根拠がなく、守られない約束に見えます。

エムダッシュも禁止語に数えます。見出しにも本文にも使用せず、代わりに -- や、前後に空白を入れたハイフンを使うこともできません。コンマ、コロン、ピリオド、または括弧を使用してください。

ボイスファイルでこれらの語句をシグネチャーワードとして指定している場合に限り、禁止リストより優先されます（執筆ステップ 3）。より広範な段階別語彙と置き換え候補は references/word-lists.md に記載されています。このリストは編集モードでの検出用であり、この禁止リストの二重登録ではありません。

---

モード A：新しいコピーの作成

Writing progress:
- [ ] Step 1: Gather context
- [ ] Step 2: State the brief, then write
- [ ] Step 3: Discover brand voice
- [ ] Step 4: Route by copy type, choose framework
- [ ] Step 5: Write 2-3 alternatives
- [ ] Step 6: Recommend and explain
- [ ] Step 7: Check every option against the brief

ステップ 1：コンテキストを確認する

ユーザーまたはファイルから、次の 4 点を把握します。ファイルから把握できない点は推測し、その推測をステップ 2 で明示します。失敗につながるのは、想定した読者や目標を事実として提示することです。

1. ページの目的。 このページで促す 1 つのアクション（登録、デモの予約、ダウンロードなど）。
2. 読者。 具体的な読者像：役職、悩み、すでに試したこと。
3. 製品。 製品が何をするか、ユーザーが得られる具体的な成果。
4. 流入元。 読者がどこから来るか（未接触の広告、関係性のあるメール、自然検索、紹介、製品内など）。

流入元によって読者の認知段階が決まります（references/frameworks.md）。未接触の読者には、製品を説明する前に問題を提示する必要があります。関係性のある読者はすでに問題を把握しており、仕組みや根拠を求めています。

ステップ 2：概要を提示してから、執筆する

概要を提示し、そのまま進めてください。ユーザーから伝えられたのではなく、推測した項目にはすべて印を付けてください。そうすれば、ユーザーは質問への回答ではなく、実際のコピーと照らし合わせて修正できます。

Brief:
- Page: [page type]
- Goal: [single action]
- Reader: [specific audience]
- Core outcome: [what changes for the reader]
- Tone: [inferred from brand voice or user-stated]
- Awareness: [unaware / problem-aware / solution-aware / product-aware / most-aware]

Inferred (correct me): [fields you guessed]

誤った推測によって作業が役に立たなくなったり、安全でなくなったりする場合に限り、執筆前にいったん止めて質問してください。たとえば、レビューなしでこのターン中にコピーが公開される場合や、目的が本当に不明で、候補となる目的ごとに異なるコピーが必要になる場合です。

ステップ 3：ブランドボイスを見つける

ブランドボイスを創作する前に、その手がかりを探してください。以下の順に調べ、最初に見つかった時点で止めてください。

1. リポジトリ内のボイスファイル： VOICE.md、BRAND.md、docs/voice.md、またはトーン・オブ・ボイスに関する文書。存在する場合は、これを正式な基準とします。
2. ユーザー本人のボイス。依頼があった場合のみ。 ユーザーが自分のボイスで書くよう依頼し（「私のボイスで」「私らしい雰囲気で」など）、ブランドも本人のものである場合は、$GHOSTWRITER_HOME/soul.md を読み込み、なければ ~/.config/ghostwriter/soul.md を読み込んでください。個人のボイスを使えるのは、その人自身のブランドに限られます。また、ファイルの内容は出力、概要、リポジトリに含めてはいけません。
3. 既存のコピー： コピーのファイル、README のヘッダー、公開済みのマーケティングページ。
4. 推測： B2B SaaS は率直で自信のある表現、コンシューマーアプリは温かみのある表現、開発者向けツールは簡潔で誠実な表現にします。ブランドガイドラインは、草案と合わせて依頼してください。草案の代わりに依頼してはいけません。

見つかったボイスは、語句リストより優先されます。リストにある語句でも、ボイスファイルや公開済みのコピーで特徴的に使われている場合は、そのまま使ってください。ロケールとスペルの慣例も、ボイスに従ってください。概要には、参照した情報源を記載してください。ステップ 4 の推測に基づく場合は、ボイスを「推測」として記載してください。ボイスファイルがなく、今後そのプロダクトに必要になる場合は、references/voice-chart.md を読み込み、コピーと合わせて VOICE.md を作成することを提案してください。

ボイスは一定ですが、トーンは読み手の状態（苛立っている、困惑している、自信がある、慎重である、成功している）に応じて調整します。references/voice-chart.md の表に、想定される変化が示されています。5つの状態すべてで同じ文体を保つと、良い場面では機械的に、悪い場面では冷淡に感じられます。

ステップ 4：コピーの種類に応じて、フレームワークを選ぶ

• プロダクトの状態に関するコピー（エラー、空の状態、成功、読み込み、権限）またはアクションラベル：references/ui-states.md を読み込み、ここで終了してください。何かを削除するボタンには、説得のフレームワークは適用されません。
• マーケティングコピー： references/frameworks.md を読み込みます。対象がホームページ、ランディングページ、料金ページ、機能ページ、会社概要ページの場合は、references/page-types.md も読み込みます。

概要に記載された認知段階に基づいて、主となるフレームワークを選んでください。

読み手	主なフレームワーク
認知前、または課題を認識している段階の新規ユーザー	Why/How/What、または課題が切実な場合は PAS
解決策を認識し、選択肢を比較している段階	Benefit Not Feature。Show Don't Tell で裏付ける
プロダクトを認識しているが、信頼度が低い段階	Show Don't Tell。証拠を中心にする
最も認知度が高く、取引を目的とするページ	CTA Clarity
どの段階にも当てはまる長文のセールスページ	PAS または BAB を軸にし、ほかのフレームワークを組み合わせる

フレームワークは自由に組み合わせてください。ヒーローコピーでは、ほかに何を使う場合でも、ほとんどの場合 Why（読み手の動機）から始めます。

ステップ 5：2～3案を作成する

特に指定がなければ、推奨案を1つ返してください。ユーザーが方向性の比較を求めている場合や、ポジショニングの選択が未確定の場合は、異なる2～3案を提示してください。成果物に合わせてください。ボタンラベルの依頼には、見出し、副見出し、CTA のセットではなく、ラベルを返します。

ステップ 6：推奨案と説明を示す

推奨案を提示してください。複数案を求められた場合は、重要なトレードオフを1文で説明してください。

ステップ 7：各案を概要と照らして確認する

良い草案にも残りやすく、概要と照らし合わせたときにだけ気づく問題が2つあります。プロンプトの反響（見出しが概要の表現をそのまま返している）と、ありきたりな既定表現（ユーザーが提示した数値、名前、価格、連携先が「数千のチーム」や「お気に入りのツール」になっている）です。返す前に、禁止語と合わせて両方を修正してください。禁止語を含む案は、提示してはいけません。

---

Mode B：既存コピーの編集

ワークフローを実行する前に、編集方針を設定します。

• 部分編集： ユーザーが1つの行、単語、またはセクションを指定しています。文脈を保つために周辺のコピーを十分に読み、対象箇所と必要最小限のつなぎの部分だけを変更して、最終的な文面を返します。部分編集をページ全体の監査に広げてはいけません。
• 復元： コピーにはすでに明確なトーン、切り口、または主張があります。語彙のレベル、相対的な強調、意図的な省略、文の形、位置づけを保ちます。論旨のバランスを変えたり、書き出しをより巧妙なものに差し替えたりせず、具体的な問題を修正します。
• 再構築： コピーがありきたり、矛盾している、または明確な視点を欠いています。ブリーフに基づいて再構成できる余地を持たせて、ワークフロー全体を実行し、根拠を捏造しないようにします。

Editing progress:
- [ ] Step 1: Read all copy-bearing files
- [ ] Step 2: Set the north star
- [ ] Step 3: Audit against persuasion frameworks
- [ ] Step 4: Remove AI writing patterns
- [ ] Step 5: Run seven sweeps
- [ ] Step 6: Flag weakest elements with labels
- [ ] Step 7: Rewrite flagged sections
- [ ] Step 8: Output before/after diff

Step 1：コピーを含むファイルをすべて読む

読者の目に触れるあらゆる箇所を確認します。README のヘッダー、ランディングページのコンポーネント、ヒーロー、CTA、製品の説明、機能一覧、オンボーディング文言、メタディスクリプション、メールの件名が対象です。音声ファイルがある場合（VOICE.md、BRAND.md、docs/voice.md）も読みます。表現やロケールを判断する際に役立ち、ファイルでシグネチャーとして指定されている語は、単語リストよりも優先されます。監査中に回答のないトーンに関する疑問が何度も生じる場合は、references/voice-chart.md を読み込み、方針を決めるよう提案します。どのファイルを対象にするか不明な場合は確認します。読んだ範囲の文脈に照らしてのみコピーを評価します。

Step 2：北極星を定める

監査の前に、次の形式で一文を書きます：「[ユーザー]は、[従来の課題]を抱えることなく、[X]できるようになります。」すべての指摘と書き換えは、この一文に沿うものにします。自信を持って書けない場合は質問します。価値提案が明確になるまで、コピーは修正できません。

Step 3：説得のフレームワークに照らして監査する

references/frameworks.md を読み込みます。すべての主要なコピーのブロックを各フレームワークに照らして確認し、影響の大きい問題だけを残します。指摘の上限は Step 6 で定めます。

Step 4：AI らしい文章パターンを取り除く

references/word-lists.md と references/ai-patterns.md を読み込みます。AI らしい表現にはそれぞれ [AI-ISM] とパターンの種類を付けて指摘します。

• Tier 1 の単語（word-lists.md）：必ず指摘し、置き換えます。
• Tier 2 のまとまり（word-lists.md）：1つの段落内に2つ以上ある場合に指摘します。
• 構造パターン（ai-patterns.md）：型どおりの書き出し、チャットボットの痕跡、「let's」を使ったつなぎ、エンゲージメントを促す文言、修辞疑問文から始める書き出し、否定を用いた並列表現、分詞による文末の付け足し、重要性の誇張、コピュラの回避、通常の句読点としての em ダッシュ。
• 執筆段階の兆候（ai-patterns.md のセクション7）：プロンプトの反復、提示された具体例を汎用的な既定表現に置き換えること、一様な確信度です。単語単位の確認では見逃されるため、別途確認します。

説得力だけを目的とする編集では省略します。ユーザーがAI らしいパターンの削除を依頼した場合は、これを最初に実行し、その後に各チェックを行います。

Step 5：7つのチェックを実施する

コピーに見られる問題に応じて references/sweeps.md を使用します。部分編集では関連する確認だけを行い、編集監査全体では完全な評価基準を使用できます。

ステップ 6：最も弱い要素にフラグを付ける

弱い行すべてに、行内ラベルを付けてください。次のラベルをそのまま使用してください。

ラベル	意味
[WHAT-NOT-WHY]	ユーザーの動機ではなく、製品や機能から始めている
[FEATURE-NOT-BENEFIT]	製品に何があるかを説明しているが、ユーザーにどのような変化があるかを説明していない
[TELL-NOT-SHOW]	裏付けのない形容詞による主張（「パワフル」「シームレス」「簡単」など）
[VAGUE]	一般的で、同じカテゴリーのどの製品にも当てはまる
[PASSIVE]	主語が行動するのではなく、行動を受けている
[VOICE-DRIFT]	周囲のコピーの主要なトーン（文体、時制、人称）から逸脱している
[PAIN-NOT-NAMED]	読者が抱えている不満を明示せずに、メリットを述べている
[DEAD-WEIGHT]	すでに伝わっている内容に何も加えていない。削除しても問題ない
[JARGON]	専門外の人には意味が伝わりにくい専門用語
[NO-PROOF]	数値、例、または推薦の言葉による裏付けが必要な主張
[WEAK-CTA]	CTA が結果ではなく、行動を説明している
[STATE-COPY]	曖昧、情報が漏れている、または行き止まりになる状態表示（エラー、成功、空、読み込み、権限）、あるいは「Confirm」／「OK」／動詞だけで表示された破壊的な CTA。このラベルを使う前に references/ui-states.md を読み込んでください。そこには product-design が参照するルール ID があります
[AI-ISM]	AI による文章に見られるパターン：Tier 1 の語句、Tier 2 のまとまり、または構造的な兆候

コンバージョンや理解度への影響を考慮し、具体的な弱点を優先してください。コピーに必要な指摘が 3 件未満なら、それ未満で報告してください。件数を満たすために指摘を作り出してはいけません。

ステップ 7：フラグを付けた箇所を書き直す

• 意味と既存のトーンを保ちながら、繰り返しを削ってください。すでに効果的なコピーは変更せずに残して構いません。
• What（製品）ではなく Why（ユーザーの問題や望み）から始めてください。
• 機能ではなく、具体的な成果を示してください。形容詞は裏付けのある表現に置き換えます。「パワフルな分析」は「どのページで登録が離脱するかを確認できます」のようにします。
• CTA は成果を具体的に示し、短くしてください。「同期を開始する」は「始める」より効果的です。機能の説明はボタンの文言ではなく、その上に記載してください。
• AI による文章のパターンを置き換える際は、文を書き直してください。同義語を置き換えるだけでは、その兆候が 1 段階下に移るだけです。

ステップ 8：変更前／変更後の差分を出力する

## Copy Audit: [file or component name]

**North star:** [one-sentence value prop]

---

### [Section name]

**Before:**
> [original text]

**Issues:** `[LABEL]`, `[LABEL]`

**After:**
> [rewritten text]

**Why:** [one sentence explaining the change]

---

### Summary
- N issues flagged across N sections
- Top pattern: [most common label]
- Confidence: [high / medium; note if copy context was limited]

「変更後」の各行には、「変更前」に含まれるすべての事実、数値、リンクを残してください。また、変更はすべて監査で特定した問題を解決するものでなければなりません。単に異なるだけの書き換えは後退です。その場合は元に戻してください。

---

注意点

• 「始める」や「詳細を見る」はクリックを集めますが、誤解を招きます。NN/g は、料金や基本情報を知りたかった読者が登録フローに誘導され、信頼を失ったことを確認しています。代わりに、遷移先や結果を明示してください（「料金を見る」、「14 日間のトライアルを開始」など）。
• Tier 1 のリストはすぐに古くなります。「delve」と「tapestry」は 2023〜2024 年の特徴語でしたが、ほぼ使われなくなりました。現在の出力では「enhance」、「highlighting」、「showcasing」、「align with」や、分詞で終わる表現（「...ensuring a smooth experience」）が多くなっています。単語リストを grep するだけでは、生成文らしさが残るコピーまで見逃してしまいます。毎回 ai-patterns.md の構造に関するセクションも実行してください。
• フラグが付いた単語を、同じ表の類義語に置き換える（「leverage」を「harness」に、「robust」を「comprehensive」にする）と、1 段階下の特徴語が再び入り込み、機械が編集したような文章になります。その箇所を具体的に書き直してください。
• frameworks.md には、根拠のない形容詞（powerful、seamless、robust）が挙げられています。これらは使用禁止語のリストや word-lists.md にも含まれています。同じ単語に [TELL-NOT-SHOW] と [AI-ISM] を重ねて付けると、フラグの数が水増しされ、本当の問題が見えにくくなります。1 つの出現箇所にはフラグを 1 つ付けてください。
• 破壊的な操作のダイアログに「確認」、「OK」、「はい」と表示すると、ユーザーは本文を読み飛ばしていた場合に、何が起きるのかを自分で推測しなければなりません。product-design は rule/no-confirm-ok-labels を指摘します。必ず動詞と目的語を組み合わせてください（「プロジェクトを削除」など）。動詞だけでよいのは、「保存」、「キャンセル」、「閉じる」に限られます。
• テンプレート変数がハイフンのルールを見えにくくします。{{days}} day trial は、どのプランでも「7 day trial」として公開されます。変数と単位の間にハイフンを入れてください（{{days}}-day trial）。ただし、単独の名詞句にはハイフンを付けないでください（「{{days}} 日後に有効期限が切れます」）。
• en-AU の製品で米国式スペルに書き換えると、変更したすべての文字列にわたって品質が低下します。1 つの文字列を変更する前に、既存の文字列を 3 つ読んでロケールを確認してください。
• Step 3 の個人的な文体の参照はオプトインで、読み取り専用です。soul.md を読んでも、個人的なメッセージ、投稿、長文を書くためのスキルにはなりません。これらは引き続き ghostwriter が担当します。

---

スキルの引き継ぎ

条件	実行するもの
技術文書のコピーを書き直した後	docs-writing
メタディスクリプションとページタイトルを最適化する場合	optimise-seo
コンテキストを含めて UI 全体のレビューを行う場合	ui-design（Audit mode）
ランディングページのビジュアルデザイン、CRO 戦略、コンバージョンのベンチマーク	ui-design（Direction mode、marketing track）
どのアクションを用意するか、その範囲と結果に関する製品上の判断	product-design
見出しとラベルの大文字・小文字の表記（センテンスケースとタイトルケース）	typography-audit（punct-case-rules）
セッション中のアシスタントとの会話、要約、または ELI5	eli5