コピーライターの判断ルール抽出｜Skills実装ハンドブック

コピーライターの「自分だけが持っている判断ルール」を、Anthropic Skills（Skills 公式）として外部化する。それを実際に手を動かすための実装ハンドブックとして書きました。読者の悩みは実務上5つに分かれるようです。暗黙知はAI化できるのか、SKILL.md の最初の一歩はどこか、薬機法とブランドボイスをどうSkillに落とすのか、チーム運用の落とし穴、流出リスクと引退後の遺産化。

そこで悩みそれぞれに1セクションを割り当て、SKILL.md サンプル3本、薬機法チェックSkill、クライアント別ブランドボイスSkill、チーム運用ライフサイクル、Trade Secret 保護、Bartz和解を踏まえた社内運用ルールまで、今週末に手を動かせる粒度に落としました。生存戦略の俯瞰はAI時代にコピーライターは要らないのか｜大御所10人の答えに譲り、こちらは実装1本で書き切ります。判断ルールを案件を跨いで育てる新しい選択肢として、Deskrex のナレッジグラフ型リサーチAI「Snorbe」も末尾で紹介します。

悩み1｜自分の暗黙知はAIで再現できるのか、限界はどこか
悩み2｜過去コピー資産をClaude Skillにする具体的な手順
悩み3｜NGワード集とブランドトーンをSkillとして実装する
悩み4｜作ったSkillをチームで運用する時の落とし穴
悩み5｜Skill化した判断ルールの流出リスクと引退後の遺産化
よくある質問
調査手法について

悩み1｜自分の暗黙知はAIで再現できるのか、限界はどこか

「なぜこの一語を選んだのか」を説明できないまま、シニアが引退・退職していく。頭の中にある判断力が組織から失われて、若手は同じ失敗を繰り返す。実装に入る前に、どうしても越えられない壁があります。そもそもAIで暗黙知を再現できるのか、できるとしたら限界はどこか。ここが曖昧なままSKILL.mdを書き始めると、後で「なぜ抽出したルールが薄いのか」という壁にぶつかる気がします。まずここから整理していきます。

Polanyi の「We can know more than we can tell」が意味していること

暗黙知（Tacit Knowledge）の議論は、化学者・哲学者のマイケル・ポランニーが提示した「私たちは語りうる以上のことを知っている（We can know more than we can tell）」という一文が原点です（Wikipedia、Polanyi『The Tacit Dimension』1966年）。自転車の乗り方を全て言語化できないのに乗れる、あの状態です。コピーライターの「なんとなくこの動詞のほうが効く気がする」も、同じ性質を持っている気がします。

野中郁次郎の SECI モデル（GLOBIS 学び放題）は、その暗黙知が組織内で循環するプロセスを、Socialization（共同化）→ Externalization（表出化）→ Combination（連結化）→ Internalization（内面化）の4段階で説明します。AIによる判断ルール抽出は、このうち「表出化（Externalization）」を機械化する試みだと考えると、位置づけがクリアになる気がします。共感を伴う対話（共同化）を全部飛ばして、いきなりLLMで表出化を回すと、薄い形式知しか出てこない、というのが実務で起きがちな失敗のようです。

Polanyi のパラドックスから逃げられない

ここでどうしても向き合わないといけないのが、Polanyi のパラドックス（Bill Parker）です。熟練者の判断を完全にコード化・自動化することは原理的に困難、という理論的な限界。「AIで100%再現」というゴールを最初から捨てて、「AI×ベテランのハイブリッド」を前提に設計する必要が出てきます。実務でよく引用される Nicolas Cole の10/80/10（人間が最初10%と最後10%、AIが真ん中80%）は、この理論的な限界に対する現実的な回答として整合が取れているんじゃないでしょうか。

商用ソリューションはもう立ち上がっている

理論の話だけしていると動けないので、実際に立ち上がっている商用プロダクトを見ておきます。KPMG ジャパンは2026年1月に「暗黙知の形式知化エージェント」（KPMG プレスリリース）を提供開始しました。特徴は複数エージェントで有識者を再現するオーケストレーション型で、経理・営業・インフラ保守を第一波として、製造・金融へ広げる想定になっています。

デロイトトーマツは2025年2月に「AIインタビューエージェント」（デロイトプレスリリース）を出しました。AI がインタビュアーとなって、ベテランの判断プロセスを引き出し、形式知化するというアプローチです。単なる書き起こしではなく、「対話型ヒアリングでの表出化」に振り切っているのが野中モデルとの接続が良いと感じます。

さらに個人・中小規模の現場でも動きが出ています。「濱田式AI品質スタンダード」（MBP-Japan）は、AI対話 → 構造化 → データ化 → ナレッジベース → バーチャル熟練者チャットボット、という5ステップで熟練者を再現する枠組みで、製造業起点ながらコピーライター・デザイナー・企画職への応用を明示しています。コピー領域でもそのまま流用できる粒度になっています。

AIで捕まえられる範囲、絶対に逃げていく範囲

商用が動いている一方で、Polanyi のパラドックスから逃げられていないので、範囲を最初に切っておく必要があります。実務上、AIで捕まえやすいのは次の3つです。1つ目は明示的なコンテンツ・フォーマット・ルール（文字数、フォーミュラ、業界NG語彙など）。2つ目はパターンで検出できる文体特徴（文末連続、体言止め頻度、平均文長、開き方の癖）。3つ目は5〜10本のサンプルからのVoice DNA抽出（My Writing Twinは150語以上のサンプルを推奨しています）。

一方、AIでは捕まえきれない領域も同じくらい明確です。リズム・間・体験のコンテクスト、審美的判断と情動、そして「書かれない慣例」「例外」「トレードオフ」。ここは形式化しきれない性質を持っています（Duperrin – Nonaka tacit knowledge AI）。だから10/80/10 の最後の10%は、必ず人間シニアが担う必要があります。これは倫理の話でも、遠慮の話でもなく、理論的な帰結なので譲れない気がします。

抽出決断のチェックリスト

ここまでを踏まえて、「じゃあ自分は抽出プロジェクトを始めるべきか」を判断するチェックリストを5つ用意しました。1つ目は自分の判断ルールを言語化する意欲があるか（対話型ヒアリングは60〜90分の録音を10〜20回、というレベルの労力がかかります）。2つ目は過去コピー100本以上の資産があるか（Voice DNA 抽出の下限は5〜10本ですが、判断ルールを条件文レベルで引き出すには2桁後半以上が必要）。3つ目は引退・後継問題が現実にあるか（時期尚早なら Skill 更新が続きません）。4つ目は案件量に対して人手が追いつかないか（余裕がある時期にやらないと、続きません）。5つ目はチームで判断基準を共有したいか（1人利用ならSkill化のオーバーヘッドが割に合わない場面もあります）。

このうち3つ以上に「はい」なら、次のセクションからSKILL.md の実装に入っていく価値がある、というのが現時点の実務感です。1つか2つなら、まずはコピーライティングのリサーチ方法でVoC収集の基礎を回すほうが先かもしれません。

悩み2｜過去コピー資産をClaude Skillにする具体的な手順

過去2年分のコピーが Google Drive と Notion に散らばっていて、没案は個人 Notion に埋もれている。Skill 化したいのは分かるが、最初の一歩がどこなのか分からない。ここが多くの実務者の実感じゃないでしょうか。このセクションでは、SKILL.md サンプル3本をコードブロックにまるっと入れて、そのままコピペで動く形式で提示します。実装ステップと落とし穴も併せて書きます。

SKILL.md の基本構造

Anthropic Skills（Skills 公式ガイド、Claude API Docs）の基本構成は、YAML frontmatter（name と description、合計1024文字以内）＋Markdown 本文＋補助フォルダの references/ と scripts/ です。Claude は description を読んで「今この Skill を起動すべきか」を判断するので、description が全ての起点になります。

書き始めの入り口は、公式メタスキルの skill-creator（Zenn 解説）を Claude Code で叩くのが最速です。対話形式で骨格を作ってくれるので、いきなり YAML から書くより手戻りが減る気がします。

サンプル1｜Voice DNA Skill（過去コピー100本から文体を抽出）

自分の文体を Skill に落とす最小構成です。references/ に過去コピー30〜100本を Markdown で並べておいて、Skill 本体は判断ルールだけ書きます。

---
name: my-voice-dna
description: 自分の日本語コピーの文体を再現する。ヘッドライン、リード、ボディコピーを書く時、または既存ドラフトを自分の声に寄せる時に使う。カジュアル媒体（SNS/note/メルマガ）向け、格式高めの企業広告は別Skillを使う。
---

# 判断ルール

### Always（使用則）
- 平均文長は32〜48字の間に収める
- 文末は「です・ます」と体言止めを交互に、3連続禁止
- 動詞は具体（例：歩む/選ぶ/迷う）、抽象動詞（例：実現する/推進する）は避ける
- ヘッドラインは「動詞終わり」を優先し、名詞終わりは体言止めの意図がある時のみ

### Never（禁止則）
- 「まさに」「実は」「そこで登場するのが」の常套句
- 感嘆符と絵文字
- 「〜させていただきます」の過剰敬語
- 商品名を冒頭12文字以内に置かない（陳腐化する）

### Formality Level（1〜5）
- Lv1（メルマガ/SNS）: 一人称「私」、二人称「あなた」
- Lv3（コーポレートサイト）: 一人称「私ども」、二人称「お客さま」
- Lv5（社史/周年広告）: 一人称「弊社」、二人称は原則使わない

### References
- references/past-copies-100.md（過去コピー100本の swipe file）
- scripts/voice-check.py（文末連続チェック、体言止め頻度計測）

description の書き方が全てで、「マーケコピー」のような抽象語を入れると発火しません。「トリガー動詞＋場面」（この Skill でいえば「書く時／寄せる時」「カジュアル媒体向け」）を入れておくのがコツです（Anthropic Skills Best Practices）。

サンプル2｜大御所引用Skill（Ogilvy の長文広告原則）

巨匠の思想を Claude が案件着手時に自動参照する形にする Skill です。1人1Skill 原則で、Ogilvy と Halbert を同じ Skill に入れると人格が混ざるので分けます。

---
name: ogilvy-longform-rules
description: David Ogilvyの長文広告原則30項目を参照する。雑誌広告、DM、セールスレター、B2Bホワイトペーパーを書く時、または既存コピーを長文形式に拡張する時に使う。
---

# 使用パターン
- 長文広告（1000語以上）のヘッドライン・リード設計
- 既存の短文コピーを長文形式に拡張する時
- DMのフックとオファー設計

# 原則リスト
- 原則番号ごとに「引用（原文＋日本語訳）」「出典」「適用シーン」「反対原則」の4点セットで書く

# 参照フォーマット例
- 引用: 'On the average, five times as many people read the headline as read the body copy.'
- 日本語訳: 平均するとヘッドラインを読む人はボディコピーを読む人の5倍いる
- 出典: Confessions of an Advertising Man, p.71
- 適用シーン: ヘッドラインに広告費の80%を投じる根拠として使う
- 反対原則: SNS広告など「読み切り前提」でヘッドラインとボディの比率が変わる媒体では調整

# References
- references/ogilvy-30-principles.md（30項目の全リスト）
- references/ogilvy-swipe-file.md（実例スワイプ20本）

英語原典をそのまま入れると出力も英語混じりになるので、必ず原文＋日本語訳のペアで references/ に格納します。name は64文字以内で小文字＋ハイフンのみ、anthropic と claude は予約語で使用禁止という細かい制約もあります（Anthropic Skills Docs）。

サンプル3｜A/Bテスト因果分析Skill（統計的に効いた要素の判定）

過去のA/Bテスト結果を Skill に落として、「効いた気がする」から「統計的に効いた」に格上げするための Skill です。Python sandbox 連携を前提にします。

---
name: ab-test-causal-analysis
description: A/Bテスト結果のCSVから、統計的に効いたコピー要素を特定してルール化する。CTR/CVRの差分を回帰分析し、p値ゲート（p<0.05）とサンプル数ゲート（n>100）を通過した要素だけ抽出する。テスト後の振り返り時に使う。
---

# 入力仕様
- CSVカラム: variant / headline / body / ctr / cvr / n / ci_lower / ci_upper

# 分析手順
1. 各バリアントを言語的特徴でエンコード
   - 数字有無、疑問形、動詞開始、感情語密度、文字数
2. Python sandbox で特徴 × 結果の回帰分析
3. p<0.05 かつ n>100 の要素のみ採用
4. 「IF 〜 THEN CTR +N%（95%CI: +X〜+Y）, n=M」形式で出力

# 出力例
- IF ヘッドラインが疑問形 THEN CTR +18.4%（95%CI: +7.2〜+29.6）, n=54
- IF 冒頭に具体的数字 THEN CVR +11.1%（95%CI: +2.8〜+19.4）, n=72

# ガードレール
- n<100 のテスト結果はルール化せず「参考値」タグをつける
- コピー以外の変数（画像、配信タイミング、オーディエンス）が同時に動いていたら因果分離不可と明示

# References
- scripts/encode_features.py（言語特徴のエンコーダ）
- scripts/regression.py（statsmodels での回帰分析）

ツールは Claude Code Interpreter、Statsig、Braintrust あたりが実務で使われています。

実装ステップ5段階

サンプルを見た上で、実際に自分の資産を Skill に落とすまでの5段階を書いておきます。

1つ目、過去コピーをCSV化します（本文／媒体／クライアント／採用or没／没理由メモの5カラム）。ここで「没理由メモ」を空欄にすると次の抽出で因果推論が成立しないので、可能な限り埋めます。2つ目、Claude Project に投入し、System Instruction で「判断ルールを80〜120件抽出して」と指示します。3つ目、抽出プロンプトを回して、条件文型（IF 〜 THEN 〜）のルール群を吐かせます。4つ目、そのルール群を SKILL.md 化します（3本のサンプルのどれかを土台にすると早いです）。5つ目、Claude Code または API 経由で登録し、動作確認します。

落とし穴と抽出方法5パターン

つまずきやすい罠は3つあります。description に抽象語を入れると発火しない、1つの Skill に複数の巨匠を入れると人格が混ざる（1人1Skill 原則）、name の書式ルール違反（64文字以内・小文字＋ハイフン・予約語禁止）。この3点は最初のリリースでほぼ全員が踏むので、Skill を作る前に押さえておきたいところです。

抽出の入口はSKILL.md だけではなく、5つの方法を組み合わせて使うのが実務のようです。1つ目は対話型ヒアリング（KPMG／デロイト／濱田式共通）。2つ目は過去コピー100本のLLM分析（Voice DNA型）。3つ目はレビュー履歴学習（添削フィードバックを学習素材にする方式）。4つ目は作業分解×IF-THEN（濱田式SECI表出化、情報収集→仮説→たたき台→削り→選択の各工程で判断基準を明文化）。5つ目はVoice of Customer 逆引き（Copyhackers方式、顧客の実言葉から判断ルールを外部化）。

単独よりも組み合わせが強いです。対話型と過去コピー分析は補完関係にあって、両方回すと同じルールに異なる根拠が並ぶので、後で四半期承認する時に判断が付きやすくなります。リサーチ側の道具立てはコピーライター向けリサーチAI 5選で整理しています。

悩み3｜NGワード集とブランドトーンをSkillとして実装する

Nicolas Cole・電通AICO2・Copyhackers 自作AIエージェント

薬機法対応で毎回コンサル外注、クライアント別のブランドガイドを毎回貼り直し、担当替えで認識ズレ。ここが実務でいちばん面倒な部分じゃないでしょうか。特に化粧品・美容・健康食品の案件を持っている方は、法令チェックの手戻りだけで週に何時間も溶けている実感があるはずです。このセクションでは、薬機法チェック Skill とクライアント別ブランドボイス Skill を実装丸ごと、今日から使える形で書きます。

薬機法チェックSkillの実装

対象法令の PDF（薬機法66〜68条、化粧品広告ガイドライン、健康食品広告表示ガイドライン、景表法優良誤認、業界自主基準あたり）を RAG に載せます。方法は2つあって、法令 PDF をベクトル DB（Pinecone や Supabase pgvector）に投入する方式と、Claude Projects に直接ロードする方式です。個人〜中小事務所なら後者のほうが軽く始められる気がします。

Skill の内部構造は、NG カテゴリ別に「禁止語彙／代替語彙／根拠条文」の3点セットで作ります。呼び出しは「生成前チェック」と「生成後チェック」の2ステップフックにしておくと、書き始めの段階と納品前の両方でガードが効きます。

---
name: yakkiho-guardrail-cosme
description: 化粧品コピーの薬機法66〜68条・景表法優良誤認への適合性をチェックする。ヘッドライン・リード・ボディコピーを書く前と書いた後の2ステップで発火。医薬品的効能表現、有効成分の言及基準、体験談表現の適法性を判定し、High/Mid/Low の3段階でリスクを返す。参照法令: 令和6年3月改正版薬機法。
---

# 判定カテゴリ
### High（禁止・要修正）
- 医薬品的効能表現（治す、根本から消す、改善する、若返る等）
- 承認外の効能・効果の断定
- 医師・薬剤師の推奨表現

### Mid（有効成分配合時のみ許容）
- 「メラニンの生成を抑え、しみ・そばかすを防ぐ」（美白有効成分配合時）
- 「肌荒れを防ぐ」（抗炎症有効成分配合時）

### Low（表現調整で許容）
- 「くすみ印象にアプローチ」
- 「透明感のある肌へ導く」

# 判定フォーマット
- 該当箇所: [引用]
- リスク: High/Mid/Low
- 根拠条文: 薬機法XX条／化粧品ガイドラインXX項
- 代替案1: [書き換え案]
- 代替案2: [書き換え案]

# References
- references/yakkiho-articles.md（薬機法66〜68条の条文全文）
- references/cosme-guideline.md（化粧品広告ガイドライン抜粋）
- references/past-warnings.md（過去の行政指導・課徴金事例）

具体的にどう動くかというと、「シミの原因を根本から消す」というコピーを投入した場合、「医薬品的効能（薬機法66条抵触）」として High 判定になり、代替案1「くすみ印象にアプローチ」、代替案2「メラニンの生成を抑え、しみ・そばかすを防ぐ（有効成分配合時のみ）」が返る、という挙動になります。この Skill は化粧品・美容業界のリサーチ実務にそのまま接続できるので、化粧品・美容業界のリサーチAI実例と併用すると案件全体の型がまとまってきます。

商用の薬機法チェックツール（Yakkinaviなど）と並用する運用が現実解のようです。AI チェックだけで納品する運用は危険で、薬事担当や外部弁理士の最終レビューは絶対に残します。

クライアント別ブランドボイスSkillの実装

もう1つの実務的な悩み、「クライアントAとBで別人格、ブランドガイドを毎回貼らずに Claude が自動で切り替える」を Skill で解きます。構成は、トーンサンプル10〜15本＋NG表現リスト＋使うべき語彙＋使わない語彙＋トーンの5軸評価を1つのドキュメントに集約する、というものです。

---
name: client-x-brand-voice
description: クライアントXの専属コピーライターとして書く。ヘッドライン、リード、ボディコピー、SNS投稿を書く時と、他クライアント向けドラフトをXのトーンに寄せる時に使う。生成後は必ずブランド適合スコア（10段階）を自己評価し、7点未満なら再生成する。
---

# トーン5軸評価
- 格式: 8/10（丁寧語＋敬語ベース、口語は控えめ）
- 具体: 6/10（数字と固有名詞は好むが感覚語も混ぜる）
- 平均文長: 42字（短文乱発は品位を欠く）
- 説明的-示唆的: 4/10（示唆的寄り、言い切らず余韻を残す）
- 権威-対話: 6/10（権威を保ちつつ読み手と目線を合わせる）

# 必須語彙
- 皆さま／ご検討／歩み／信頼／これから／お客さま

# NG語彙
- あなた（二人称は「お客さま」）
- 絶対／完璧／最高（断定と誇張は避ける）
- めっちゃ／マジ／ヤバい（口語）
- 感嘆符

# 主語ルール
- 一人称: 私ども（「弊社」は堅すぎる）
- 二人称: お客さま（原則）、「皆さま」は複数呼びかけ時のみ

# 生成後のセルフチェック
1. トーン5軸それぞれで目標±1点に収まっているか
2. NG語彙が混入していないか
3. 必須語彙のうち最低2つが使われているか
4. ブランド適合スコアが7点以上か

# References
- references/tone-samples-15.md（クライアントX の過去コピー15本）
- references/off-brand-examples.md（過去に差し戻された案5本）

「格式：8／10」のような数値化は、若手が Skill を使ってドラフトを書いた後に、シニアが「なぜ差し戻したか」を伝えるコストを大きく下げます。「格式が2点足りない」と言えるようになると、感覚的な「なんか違う」が消えていく感覚があります。広告代理店の運用に落とす時の応用先は広告・マーケティング業界のAI事前リサーチも参照してみてください。

Skill vs Project vs Style の使い分け

ここまで書いてきた Skill と、Claude Projects と Style（Anthropic Styles Docs）は役割が違います。恒常的な判断ルール（薬機法、ブランドボイス）は Skill、案件・クライアント単位のコンテキスト（案件ブリーフ、競合資料、過去やりとり）は Projects、その場限りのトーン調整（キャンペーン限定の口調変更）は Styles、という三層構造で捉えると整理が付く気がします。2026年に Styles は Skills に統合される予定なので、長期的には二層に集約される流れです。

薬機法・ブランドボイスSkill 運用の落とし穴

法令改正の版管理を Skill 本文に明記します（「参照法令: 令和6年3月改正版」の1行）。改正が入ったら Skill の references/ 側の PDF も差し替えて、Skill 本文にも改訂履歴を残しておくと、後で監査証跡になります。業界別に基準が違うので、Skill は業界別に分割します（化粧品用と食品用を1つの Skill に混ぜると誤爆します）。

意外と危ないのが「行き過ぎた NG 検出でコピーがつまらなくなる」現象です。ゼロリスクを狙うと、代替案がどれも「効能を言ってない普通の言葉」になって、広告として機能しなくなります。商用リスクの範囲でトーンを設計する、というのが実運用の落とし所のようです。ブランドボイス Skill 側も、サンプルが10本未満だと抽出精度が急落するので、最低10〜15本は集めます。四半期でトーンサンプルを追加更新するサイクルも、忘れずに Skill 本文にスケジュール化しておきたいところです。

悩み4｜作ったSkillをチームで運用する時の落とし穴

自分だけで使う分にはいいが、若手や他のクリエイターに展開すると「作った Skill が師匠の思想と別物」になっていく。更新が続かない、若手が Skill に頼りすぎて自分で書けなくなる。ここが Skill 導入の後で必ずぶつかる壁のようです。このセクションでは、チーム運用ライフサイクル4段階、Projects と Skills の役割分担、TRACE 論文の教訓、を実務ハンドブックとしてまとめます。

チーム運用ライフサイクル4段階

Skill をチームで動かす時のライフサイクルは、4段階に分けると回りやすい気がします。1つ目は「抽出」（対話型ヒアリング＋過去コピー分析の並行）。2つ目は「SKILL.md 化と検証」（サンプル10本をシニアが手動でも書いてみて、Skill の出力と一致度を確認）。3つ目は「チーム展開と使用ルール」（誰がどの案件で使うか、Skill の呼び出しログをどう残すか）。4つ目は「継続更新」（月次で師匠承認・四半期で Voice DNA 再抽出）。

この4段階目がいちばん難しくて、多くの現場が3段階目で止まる印象があります。「作ったが更新されず、半年後に古くなる」という結末を避けるには、更新サイクルをカレンダーに入れて、月次の師匠承認を仕組みで縛るしかないんじゃないでしょうか。

Claude Projects と Skills の役割分担

Skill が判断ルール本体、Projects が案件・クライアント別のコンテキスト、Style がキャンペーン用の一時トーン変更、という三層で分担するのが実務の基本形です。もう少し具体的に書くと、Skill には「文末連続禁止」「薬機法66条抵触ワード」のような、案件が変わっても不変のルールが入ります。Projects には「クライアントXの2026年上期ブリーフ」「競合A/B/Cの直近3ヶ月広告」のような、案件固有の情報が入ります。Style は「今回の周年キャンペーンだけ格式Lv5で書く」のような、一時的な上書き用です。

この分担が曖昧なままだと、「案件情報が Skill に混入して他クライアントに漏れる」というリスクが発生します。個人名・クライアント名・案件名が Skill 本体に残っていないか、リリース前に必ず grep で確認するのが安全側の運用です。

添削記録のAI化ワークフロー

若手が師匠の Skill でセルフ添削できる仕組みを作るには、添削記録を継続的に AI に食わせる必要があります。ワークフローは、Before／After／理由コメントを1件1行フォーマットで記録して、週次で50〜100件を Claude Project に投入、「同じ指摘の繰り返し」を AI に検出させて共通ルールを抽出、そのルールを既存の SKILL.md に追記する、という流れです。

理由コメント入力が続かない、というのがこのワークフローの一番のリスクです。1件30秒で書ける定型テンプレを用意します。「◯行目：主語不在／修正：ユーザーが→主語を明示」くらいの粒度で、Slack ワークフローや Notion データベースの1行フォーマットに落とすと、心理的ハードルが下がります。

添削の Skill 化は copy-self-review-junior のような名前で、チェック順1「主語不在」／2「情報過多冒頭：冒頭15字で3情報以上入れていないか」／3「動詞の弱さ」という並びで作っておくと、若手が自分の初稿を投げた瞬間にセルフレビューが返ってきます。VoC 収集や下調べのフェーズはコピーライティングのリサーチ方法で押さえた上で、書いた後の添削を Skill 化する、という順序が実務に馴染みやすい印象です。

TRACE 論文の教訓

チーム運用でどうしても効いてくるのが、TRACE論文（arXiv:2606.13174, 2026）の指摘です。「指示をプロンプトに書き込むだけ」だと遵守率が55%止まり、というもの。SKILL.md に「文末は3連続禁止」と書いても、実運用では若手のドラフトに文末連続がしばしば残る、という現象は経験的にも起きます。

論文が提示する解法は「ユーザー修正 → 実行時チェック（フック）」への自動コンパイル、というものです。Anthropic Skills 側でもフック機能（Hooks in skills and agents）が公式に用意されていて、SKILL.md の frontmatter に Stop フックを埋め込むと、ターン完了前に検証スクリプトが走ります。非ゼロ終了で完了できなくなるので、修正が強制される、という設計です。

実装例としては、文末連続チェックのスクリプトを scripts/voice-check.py に置いて、Stop フックで発火させると、若手が「なんとなくOK」を通したくても Skill 側で止まる、という運用ができます。四半期ごとの Skill 再抽出も、この「実行時ガード」の思想に近い実践で、TRACE の教訓を運用リズムに落とす、という捉え方で整理が付く気がします。

評価ゲートと若手のセルフ添削

チーム展開の設計で、絶対に外せないゲートが2つあります。1つ目は「AI 抽出ルールを人間が四半期承認する」ステップ。抽出した80〜120件のルールを、シニアが全件目を通し、「これは残す」「これは削る」「これは修正」の判断を入れる、という定期ゲートです。KPMG やデロイトの商用エージェントも、この人間承認ゲートを組み込んだ形で提供されているようです。2つ目は「若手が Skill でセルフ添削してからシニアに投げるルート」の徹底。Skill をバイパスして初稿をシニアに送るのを禁じる、というのは強い運用ですが、Skill の存在意義を担保するには必要な気がします。

落とし穴：スキル空洞化リスク

最後に、いちばん深い落とし穴を書いておきます。判断ルールを外部化した結果、書き手自身のスキルが退化する、という現象です。Joanna Wiebe（Copyhackers）が Air France 447 の比喩で警告している「自動化への過依存で人間の問題解決能力が退化する」という論点そのものです（Master of AI Copy）。

対策としては、月に1回は Skill を切って手書きする「素振り日」を作る、若手には「Skill 出力を写経してから自分で書き直す」トレーニングを課す、シニアは3ヶ月に1回は自分の Skill を意図的に無視して新規スタイルを試す、あたりを運用に組み込むと、退化のスピードを遅らせられる感じがします。Skill は判断ルールを保存する道具であって、判断そのものを外部化する道具ではない、という区別が実務では効いてくるようです。

悩み5｜Skill化した判断ルールの流出リスクと引退後の遺産化

判断ルールを Skill 化した結果、元社員が持ち出す、同業他社に流出する。将来的には「引退後の自分」を AI として遺したいが、法整備はどうなっているのか。ここが5つの悩みの中でいちばん重い部分で、法的な不確実性が10年続くと弁護士側も認めている領域です。このセクションでは、Trade Secret 保護と Bartz 和解、人間著作性要件、社内運用ルール雛形、デジタル遺産化の順で、実装の観点から書きます。

流出リスク対策 4戦略

判断ルールの流出リスクへの対策は、実務では4つの戦略に分解できる気がします。

1つ目は Trade Secret 保護。プロンプトライブラリ・SKILL.md 一式を trade secret として明示的にラベリングし、アクセス制限と NDA を適用します。経済的価値と機密保持措置の両方を実装しないと、法的に trade secret として認められないので、この2点セットは外せません（National Law Review）。2026年は o9 Solutions v. SAP、AlphaSense v. Daloopa、iyO v. OpenAI/io など、AI関連の trade secret 訴訟が急増した年でもあります。

2つ目はプロンプト移植性への防御。SaaStr が指摘した「Prompts are portable」（SaaStr）という論点。ルール単体は競合優位の堀にならず、table stakes 化します。だから「ルール＋入力仕様＋出力フォーマット＋バリデーション＋運用ワークフロー＋業界データ」の統合パッケージにして、単なるルール売りではなくルール実装の運用能力ごと囲い込みます。

3つ目は層別管理。公開する Skill と絶対に外に出さない「奥の型」を分けます。ヒアリング設計、クライアント別カスタマイズロジック、失敗事例からの回避ルールは非公開層。表向きは大御所引用 Skill や公開スワイプ集を出しても構いません。層別することで、公開部分からのリバース抽出を織り込んだ設計になります。

4つ目は特許化の検討。USPTO は2026年に AI関連特許の適格性を拡張する方針を出しています（IPWatchdog）。「mental process 例外」の過剰適用を見直す方向で、従来「単に頭で考えるプロセス」として拒絶されていた AI 活用の判断アルゴリズムに、特許保護の可能性が広がっています。中核的なルール群のうち、技術的な新規性が主張できるものは特許化も選択肢に入ります。

Bartz v. Anthropic 15億ドル和解が意味すること

法的リスクの背景として押さえておきたいのが、Bartz v. Anthropic の15億ドル和解（Norton Rose Fulbright、Cleary Gottlieb）です。約50万作品を対象に、1作品あたり約3,000ドル、米国著作権和解として過去最高額。判決の要点は、AI 学習は fair use の側面があるが、海賊版コピーの保有は違法、というものでした。

コピーライター側の実務への含意は3つあります。学習素材の合法性を証明できる形で確保する必要があること（勝手にスクレイピングした swipe file は Skill に載せられません）。生成物の監査証跡を残す必要があること。契約書テンプレの改訂が必要なこと。この不確実性は今後10年続くと弁護士側も認めているので、走りながら対応する構えになります。

人間著作性要件と監査証跡

もう1つ重要な判例が、米最高裁が2026年3月2日に certiorari 却下した件です（Neal & Leroy）。人間著作性が著作権の基盤要件であることが再確認され、Copyright Office は「反復的プロンプト調整で目的の出力に到達すること」を著作権保護根拠として認めない、と判断しています。「sweat of the brow」主張には該当しない、というロジックです。

つまり、AI が生成したコピーそのものは著作権保護されず、人間による実質的な選択・編集・アレンジの部分のみが保護対象になります。10/80/10 の最後の10%を人間が握ることは、法的にも意味を持つ設計になっている、という整理です。実務では監査証跡（誰が、いつ、どのプロンプトで、どの部分を選び、どこを編集したか）を残せる仕組みを Skill 側に組み込んでおくと、後の権利主張の根拠になります。

社内運用ルール雛形

ここまでを踏まえた社内運用ルールの雛形を4項目で書いておきます。

1つ目、Skill バージョン管理と改訂履歴。SKILL.md 本体に「version: 1.3.0 / 2026-07-06 更新」の1行を必ず入れ、改訂履歴を references/changelog.md に残します。2つ目、アクセスログと退職時ラップアップ。誰がどの Skill をいつ呼び出したか、退職時に何を持ち出す権利があるか、を契約書と運用ドキュメント側に落とします。3つ目、生成物と Skill 使用の記録。fair use 準拠の監査証跡として、生成物ごとに「使用 Skill」「人間編集箇所」「編集理由」を残せる仕組みを持ちます。4つ目、契約書テンプレの改訂。AI 生成物の著作権帰属条項、Skill 使用制限、退職後のプロンプトライブラリ保持ルールを、業務委託契約と雇用契約の両方に反映します。

この4項目を全部同時に整えるのは重たいので、優先順位は1→3→2→4の順で回すと現場が動きやすい感覚です。

デジタル遺産化：AI Cole という近似実装例

「引退後の自分を AI として遺す」という実装の最も近い例は、Nicolas Cole の Ghostbase G1 と AI Cole（Ghostbase）です。15年分の SNS・ニュースレターを学習素材化して、月額$50 でチャット提供するモデル。本人存命ですが、構造は「引退後も AI が働き続ける」設計に近い、という位置づけです。詳細な生存戦略論はAI時代にコピーライターは要らないのか｜大御所10人の答えに委ねます。

隣接領域では TalkMemorial.AI、TOKIAI、AIQCAP のような「故人再現サービス」が2025〜2026年に相次いでローンチしています。日本国内では2036年成立想定の「デジタル遺産法」で、SNS・メッセージ履歴・AIメモリアルデータの管理継承が法制化される見込み、という予測記事も出てきています（Deep Thought 未来ニュース）。

現時点では、AI で自分を遺す実装は「私的な資産として管理する」段階で、法整備はこれから、という認識で走るのが安全側のようです。

Snorbeという新しい選択肢

判断ルール抽出の周辺で、案件を跨いだ知識の連結が要になる場面がいくつかあります。1つ目は案件を跨いだ「判断根拠」の記憶連結（過去のこの判断はどの案件のどの結果に基づいていたか、という因果連鎖）。2つ目は過去 A/B テスト結果の因果分析ソース検索（W4 の A/B テスト Skill をチームで回す時、過去テストのソース CSV を横断的に引き当てる）。3つ目は VoC・スワイプファイル収集の一次リサーチ（案件着手時に、業界別の顧客の声と過去の秀作を一気に集める）。

Snorbeは Deskrex が開発している、ナレッジグラフ型のリサーチ AI エージェントで、このような「案件を跨ぐ知識の連結」を主戦場にする新しい選択肢です。Skill が「判断ルール本体」、Projects が「案件コンテキスト」だとすると、Snorbe は「判断根拠のグラフとリサーチ源」を担う、別軸の武器という位置づけになります。無料の先行アクセスはSnorbeから入れます。しかも、SnorbeでもSKILL.mdを使うこともできます。

月曜日から始める最小構成

長くなりましたが、最後に「月曜日から手を動かす」ための最小構成を4つに絞ります。1つ目、今週末に SKILL.md サンプルを1本だけ書く（Voice DNA Skill か薬機法チェック Skill のどちらか）。2つ目、過去コピー10本を Claude Project にアップして、抽出プロンプトを1回だけ回してみる。3つ目、Trade Secret ラベリングと社内公開範囲を決める（自分のリポジトリの private/public を分ける）。4つ目、3ヶ月後のカレンダーに「添削記録から Voice DNA 再抽出」を入れる。

この4つが動き出せば、6ヶ月後には自分の判断ルールが80〜120件の Skill 資産になっている感覚がつかめる気がします。抽出の入り口で迷ったらコピーライター向けリサーチAI 5選、法令周りの応用先で迷ったら化粧品・美容業界のリサーチAI実例や広告・マーケティング業界のAI事前リサーチを、それぞれ横に置いて進めてみてください。

よくある質問

Q1. SKILL.md を書き始めるのに必要な過去コピーは何本ですか？

Voice DNA 抽出の下限は5〜10本のフルコピー（My Writing Twinは150語以上のサンプルを推奨）です。判断ルールを80〜120件のレベルで引き出すなら、Claude Project に直近2年分（100〜200本）を投入する構成が実務では多いです。1クライアント25本を超えたらサブセット分離が偏り回避のコツになります。

Q2. 薬機法 Skill と一般的な薬機法AIチェックツールの違いは何ですか？

一般ツール（Yakkinaviなど）は法令適合性の判定に特化していますが、Skill は「NG検出→自社ブランドボイスに合った代替案の提示→書き直し→再チェック」まで一気通貫で回せる点が違います。商用ツールで発火→Skill で代替案生成、という並用が現実解のようです。AI 単独で納品する運用は薬事担当の最終レビュー必須という点は共通します。

Q3. クライアント別ブランドボイス Skill は何案件から作る価値がありますか？

継続案件で年間3〜5本以上、かつトーンサンプル10〜15本が揃えられる規模から、抽出のオーバーヘッドが割に合う印象です。スポット単発の案件で作ると、Skill の維持コストが取れずに古くなります。四半期でトーンサンプルを追加更新するサイクルを組めるかどうか、が実質的な判断基準になる気がします。

Q4. Claude Projects と Skills、どちらを先に作るべきですか？

順序としては Projects → Skills が実務向きです。Projects で案件・クライアント別のコンテキスト（ブリーフ・過去やりとり）を整理してから、案件を跨いで不変な判断ルールを Skill に切り出す、という流れです。いきなり Skill から作ると「案件情報が Skill 本体に混入する」リスクが出やすいので、Projects で境界を切ってからのほうが安全側です。

Q5. 自分の判断ルールが Skill 化して流出した場合の法的対応は？

Trade Secret として明示的にラベリングし、NDA・アクセス制限・経済的価値と機密保持措置を実装しておくと、不正競争防止法（日本）や DTSA（米国）に基づく差止・損害賠償請求の余地が出ます。ラベリングも NDA もない状態だと、法的保護は非常に弱いです。事前準備の有無で法的救済の可否が大きく変わるので、Skill 作成と同時に契約書側も整えるのが安全側です。

Q6. Nicolas Cole の AI Cole を日本で真似する費用感は？

学習素材の準備が最大コストで、過去100〜500本のコピーに1件30秒の注釈をつける作業が数十時間かかります。ツール代は Claude Pro（$20/月）か Team（$25/月）＋API 従量課金で数千〜数万円/月。フルスケール月$50モデルの日本市場での売上見立ては、単体プロンプト販売ではなく教材＋Skills＋伴走コンサルの3点セットで単価を上げる設計が現実解のようです。

Q7. SKILL.md の description に書くべきトリガー動詞の例は？

「書く時／推敲する時／寄せる時／チェックする時／拡張する時／再生成する時／振り返る時」あたりが実務でよく効きます。抽象語（「マーケコピー」「文章生成」）だと発火せず、動詞＋場面（「ヘッドラインを書く時」「セールスレターを長文形式に拡張する時」）にすると発火率が上がります。詳細はAnthropic Skills Best Practicesを併せて参照してみてください。

Q8. Snorbe は判断ルール抽出のどの工程で刺さりますか？

案件を跨いだ「判断根拠」の記憶連結、過去A/Bテスト結果の因果分析ソース検索、VoC・スワイプファイル収集の一次リサーチ、の3工程で刺さる設計になっています。Skill が判断ルール本体、Projects が案件コンテキストだとすると、Snorbe は判断根拠のグラフとリサーチ源を担う別軸の武器、という位置づけです。無料先行アクセスはSnorbeから入れます。