Cowork Skills で「自分の文体」を再現する — 個人ブランド向けスタイルガイドの作り方

下書きを読み返していた夜のことです。三段落目まで進んだところで、手が止まりました。内容に誤りはないのに、「この言い回しは、私なら選ばない」という引っかかりが残っていたのです。

直す箇所を探すうちに、問題が個々の文ではなく、文章全体の手触りにあると気づきました。そこで、プロンプトに毎回トーン指定を書き足すのをやめ、Cowork の Skills 機構を「自分専用のスタイルガイド」として使うことにしました。文体の特徴を SKILL.md に固定し、必要なときだけ呼び出す形にすると、自分が書いた文章にかなり近づいていきます。ここではその作り方を、観察 → 定義 → 反証の3ステップでまとめます。

なぜ「指示文」や「メモリ」ではなく Skill なのか

Cowork で文体をコントロールしたい場合、選択肢は3つあります。プロンプトに毎回書く方法、メモリ（CLAUDE.md など）に書き込む方法、Skill として定義する方法です。それぞれに役割があり、混同すると逆効果になります。

• プロンプト直書き: 一度きりのタスク向けです。再現性がなく、長期運用には向きません
• メモリ（CLAUDE.md）: プロジェクト全体に常時適用されます。プロジェクト固有のルールには向きますが、文体のように「記事執筆時だけ」発火させたい指示には強すぎます
• Skill: 特定タスクのときだけ呼び出されます。文体ガイドは「執筆をするときだけ」適用したいので、Skill が最適です

私はメモリには「日英セットで作成」「pushは /tmp/ で」などのプロジェクトルールだけを置き、文体に関する指示は Skill に切り出しています。この分離により、コードレビューの会話には文体ガイドが混ざらず、執筆ツールに切り替えたときだけトーンが立ち上がるようになりました。

ステップ1: 自分の文体を3〜5個の特徴に絞る

観察フェーズが Skill の質をほぼ決めます。漠然と「丁寧に」「個性を持って」と書いても AI には伝わりません。過去に自分が書いた記事を5本ほど開き、共通する癖を抽出します。私の場合、観察結果は次のような形に落ち着きました。

• 敬体で統一: 「〜します」「〜になります」で揃えています。常体が混じると、一気にトーンが崩れてしまいます
• 主観の明示: 一般論ではなく、「私は〜と思います」と主観として書く癖があります
• 段落末の問いかけ: 「〜ではないでしょうか」で読者を巻き込む癖があります
• 奇数の箇条書き: 項目数は3個か5個にまとめがちです
• コード前の一文: コード例の前に、「何のために書くコードか」を必ず1文添えます。コードだけをぶっきらぼうに置くことはありません

ここまで具体化すると、AI に渡せる材料が揃います。逆に「丁寧で温かい文章」のような形容詞ベースの指示は、ほぼ反映されません。観察は退屈な作業ですが、ここを省略すると Skill が機能しないので、最低でも3本の記事を読み返してパターンを抜き出してください。

ステップ2: SKILL.md の骨格を作る

Cowork の Skill は単純なディレクトリ構造です。.claude/skills/personal-voice/SKILL.md のようなパスにファイルを置き、フロントマターでトリガーキーワードを宣言します。最小構成は次のようになります。

---
name: personal-voice
description: "ブログ記事を書くときに発火する個人の文体ガイド。敬体・主観表現・段落末質問形を再現する。トリガー: 記事執筆, ブログ, note, 下書き"
---
 
# 個人ブランド文体ガイド
 
このスキルは、個人で運営しているブログ向けの文章を生成する際に
毎回適用される文体ルール集です。技術的な正確性よりも「自分の声」を優先します。
 
## 必ず守るルール
 
1. 敬体（です/ます調）で統一する。常体が1文でも混じったら全文を見直す
2. 「私は〜と思います」「私の場合は〜」のように主観の所在を明示する
3. 段落の最後の文を「〜ではないでしょうか」「〜かもしれません」で締めることが多い
4. 箇条書きは3個または5個。4個・6個は避ける
5. コード例の直前に必ず「何のために書くコードか」を1文で添える
 
## やってはいけないこと
 
- 「〜することが可能です」のような冗長表現（→「〜できます」に短縮する）
- 「〜を整理します」で始まる導入文
- 機能リストを羅列するだけの構成
 
## 検証方法
 
生成した本文を再読し、上記5ルールに違反していないかセルフチェックする。
1つでも違反があれば該当箇所を書き直してから出力する。

ポイント: description のトリガーキーワードを具体的にすること、ルールを数値化（3個または5個など）すること、そして「やってはいけない例」を具体的に列挙することの3点が効きます。特に「禁止例」は、AI が陥りやすい無難なテンプレートをピンポイントで潰せるので必ず書き込んでください。

ステップ3: 反証テストで Skill を検証する

ここが多くの方が省略しがちな最重要ステップです。Skill を作ったら、必ず「過去の自分の記事と同じテーマで、Skill 経由で書き直してみる」ことをおすすめします。たとえば私は、以前 note に書いた「個人開発で詰まったときの再起動ルーチン」という記事を題材に、Skill 適用前と適用後の差分を比較しました。

# Skill なしで生成
claude "個人開発で詰まったときの再起動ルーチンについて2000字で書いて"
 
# Skill ありで生成（トリガーキーワードを含めて発火させる）
claude "個人ブランド向けに、ブログ記事として『個人開発で詰まったときの再起動ルーチン』を2000字で書いて"

期待する出力の差分は3点です。第一に、敬体が崩れず常体への混入がないこと。第二に、「私は〜と感じています」のような主観表現が3回以上出現すること。第三に、段落末に「〜ではないでしょうか」が複数回現れること。これら3点が満たされていなければ、SKILL.md のルールが具体化不足です。曖昧な箇所を具体例で書き換えてから再テストします。

ルール遵守を機械で測る — 50行の検証スクリプト

反証テストは目視での比較なので、記事の本数が増えると続きません。私は下書きを数値で殴れるようにしたくて、SKILL.md に書いたルールをそのまま判定する小さなスクリプトを用意しました。外部ライブラリは使っていないので、Python が入っていればそのまま動きます。

#!/usr/bin/env python3
"""voice_check.py — SKILL.md のルールを下書きに対して機械的に測る。
   使い方: python3 voice_check.py draft.md
"""
import re, sys
 
text = open(sys.argv[1], encoding="utf-8").read()
body = re.sub(r"```.*?```", "", text, flags=re.S)         # コードブロックは対象外
body = re.sub(r"^---\n.*?\n---\n", "", body, flags=re.S)  # フロントマターも除外
paras = [p.strip() for p in body.split("\n\n")
         if p.strip() and not p.lstrip().startswith(("#", "-", "*"))]
sentences = [s.strip() for s in re.split(r"(?<=。)", body) if s.strip()]
 
polite  = sum(1 for s in sentences
              if re.search(r"(です|ます|ました|でした|ません|でしょう|ください)[。」]?$", s))
opinion = len(re.findall(r"(私は|私自身|私の場合|と感じ|と思いま)", body))
soft_q  = sum(1 for p in paras if re.search(r"(でしょうか|かもしれません)。?$", p))
blocks  = re.findall(r"(?:^[-*] .+\n?)+", body, flags=re.M)
bullets = [len([l for l in b.strip().split("\n") if l.strip()]) for b in blocks]
odd_ok  = all(n % 2 == 1 for n in bullets)
 
rate = polite / max(len(sentences), 1)
print(f"敬体率      : {polite}/{len(sentences)} = {rate:.0%}")
print(f"主観マーカー: {opinion} 箇所")
print(f"段落末の問い: {soft_q}/{len(paras)} 段落")
print(f"箇条書き項目: {bullets} -> 奇数統一 {'OK' if odd_ok else 'NG'}")
 
fail = rate < 0.95 or opinion < 3 or soft_q < 2 or not odd_ok
sys.exit(1 if fail else 0)

やっていることは単純です。コードブロックとフロントマターを落とし、句点で文に割り、敬体で終わる文の比率・主観マーカーの出現数・段落末の問いかけ・箇条書きの項目数を数えているだけ。しきい値を割ったら exit 1 を返すので、push 前のフックにそのまま挟めます。

自分の記事3本に当ててみた結果が次の通りです。

面白かったのは敬体率が 100% に届かない記事があったことです。中身を確認すると常体が混じっていたわけではなく、体言止めと箇条書きの断片が文として拾われていました。つまりこの指標は「常体の混入」ではなく「文末の型のばらつき」を測っています。私はしきい値を 95% に置いていますが、体言止めを好んで使う方は 85% あたりの方が実態に合うはずです。

もっと効いたのは主観マーカーの列でした。0 箇所だった記事を読み返すと、たしかに解説調に寄っていて、自分の判断がどこにも書かれていません。書いている最中は気づかず、数値が先に違和感を教えてくれた形です。段落末の問いかけが全記事で 0 だったのも同じで、SKILL.md にルールとして書きながら自分が守っていませんでした。ルールを疑うか自分を疑うか、判断する材料が数字で出てきます。

ひとつ釘を刺しておくと、この種の指標は満たすほど良いというものではありません。問いかけを機械的に増やせば、段落末が全部「〜ではないでしょうか」になり、かえって読みにくくなります。私は数値を合否ではなく「読み返す場所の当たりをつける道具」として扱っていて、しきい値を割った箇所だけを目で確認する運用に落ち着きました。

数字の次に、読み返す場所を絞る

敬体率や主観マーカーの合計は、記事全体の傾向を教えてくれます。ただ、「どこを直すか」までは教えてくれません。最初のうち、私は合計値が出るたびに全文を頭から読み直していました。時間がかかる割に、直した手応えは薄いままでした。

いまは、主観マーカーが5段落以上続けて現れない区間だけを列挙する小さなスクリプトを、voice_check.py の隣に置いています。

#!/usr/bin/env python3
"""voice_where.py — 主観マーカーが 5 段落以上続けて現れない区間を列挙する。
   使い方: python3 voice_where.py draft.md
"""
import re, sys
 
text = open(sys.argv[1], encoding="utf-8").read()
text = re.sub(r"```.*?```", "", text, flags=re.S)
text = re.sub(r"^---\n.*?\n---\n", "", text, flags=re.S)
MARK = re.compile(r"(私は|私自身|私の場合|私も|と感じ|と思いま|気づ)")
 
paras = [p.strip() for p in text.split("\n\n")
         if p.strip() and not p.lstrip().startswith(("#", "-", "*", "<"))]
run_start = None
for i, p in enumerate(paras + ["私は"]):          # 末尾に番兵を置く
    if MARK.search(p):
        if run_start is not None and i - run_start >= 5:
            print(f"段落 {run_start + 1}〜{i}: {i - run_start} 段落連続で主観なし")
            print(f"  先頭: {paras[run_start][:30]}…")
        run_start = None
    elif run_start is None:
        run_start = i

末尾に「私は」だけの番兵を足しているのは、記事の最後まで主観が現れない場合にも、その区間を拾うためです。

手順と原因分析を中心にした運用記録の一本に当てたところ、主観のない区間が6つ出ました。いちばん長いものは12段落続いています。出力の先頭は次のとおりでした。

段落 5〜16: 12 段落連続で主観なし
  先頭: 原因を大きく分けると3つのパターンに収まります。…

該当区間を開くと、確認した状況と手順が並ぶだけで、「なぜその対処を選んだのか」という私の判断がどこにもありませんでした。手順そのものは短文のままで構いません。足すのは、判断の理由をひと言だけです。手順のあいだに「ここで再起動を選んだのは、〜だったからです」と一文入れるだけで、記事の読み味が変わりました。

もちろん、手順書は元々主観の少ない文章です。5段落という目安は、記事の種類に合わせて動かしてください。大切なのは合否を決めることではなく、読み返す場所を数分で絞り込めることです。

個人的に効いた工夫: 「自分の声サンプル」を埋め込む

SKILL.md の末尾に、自分が書いた段落をそのまま ## 声のサンプル として2〜3個コピペしておくと、再現精度が一段上がります。AI は抽象的なルールよりも具体的な文例から学ぶ方が得意なので、ルールと実例をセットで提示するのがコツです。私は note や dolice.design から「これは自分らしいと感じる段落」を抜き出して貼り付けています。

文体を Skill に固定する作業は、自分の声を言語化する作業でもあります。AI に渡すために言語化したルールは、自分自身が記事を書くときの判断基準にもなり、書き手としての軸が締まる副次効果がありました。

Skill は四半期に1回見直す（毎日触らない）

文体は静かに変わっていきます。3月に作った Skill は8月にはどこかしら違和感が出てきます。書き手としての自分が変化していることもありますし、扱うテーマが変わっていることもあるからです。私は voice 系の Skill を四半期に1回だけ見直すルールにしていて、この頻度がちょうど良いと感じています。

見直し作業は短時間で終わります。直近で満足している記事3本と、なんとなく違和感が残っている記事3本を読み比べ、満足記事の中にあって Skill に書かれていない癖を1つだけ追加します。違和感記事の方は、ルールには違反していないのに何か足りない場合に注目し、テンポや書き出しの定型に欠けている制約を探します。実例ベースで差分を当てる流れだと、机上で「もっといい SKILL.md」を作ろうとするより早く改善が効きます。

ひとつだけ注意点があります。ルールは増やし続けないでください。10 個を超えたあたりから矛盾しはじめ、AI はすべてを満たそうとして妙に硬い文章を出すようになります。新しい制約と既存の制約がぶつかったら、どちらを残すか即決し、片方は思い切って削除します。信頼できる小さなルール群の方が、網羅的だが当てにならないルール群より使えます。

落とし穴: トリガーキーワードを広く取りすぎない

Skill が暴発する一番の原因は、description のトリガーが広すぎることです。「執筆」「記事」だけにすると、コード解説の会話やドキュメント整理の会話でも発火してしまい、技術的な正確性が必要な場面で文体ガイドが優先されてしまいます。「ブログ」「note」「個人ブランド」のような、明らかに個人発信の文脈でのみ使うキーワードに絞るのが安全です。

トリガーを絞りすぎると、今度は発火しなくなります。疑わしいときは、トリガー語を含む依頼と含まない依頼で同じテーマを書かせ、2つの出力を voice_check.py に通して見比べます。数値にほとんど差が出なければ、その Skill は効いていません。

文体を Skill 化することは、AI を「自分の代筆者」ではなく「自分の声を理解する共同編集者」に変える作業に近いと私は感じています。代筆させたいのではなく、自分が書いたものを自分の基準で見てほしいのです。そう考えるようになってから、Skill に書くルールの粒度が変わりました。

次に試してほしいこと

まずは過去記事を3本読み返し、共通する癖を5個書き出してみてください。それだけで、自分が「無意識に守っていたルール」が言語化されます。書き出したルールを SKILL.md の最小構成に流し込み、トリガーキーワードを「ブログ」「note」のように絞った状態で発火テストをすれば、その日のうちに「自分っぽい下書き」が出せるようになります。本格運用に入ってから細部を調整する流れの方が、最初から完璧を目指すよりずっと早く成果が見えるはずです。

Skill のファイル構造そのものに不慣れな場合は、Markdown 基礎から始める Skill 執筆ガイド が下地になります。