「AIに記事の下書きを任せると、どうしても自分の声から離れていく」——個人で運営しているブログや note を持っている方なら、一度はこの違和感を抱いたことがあるのではないでしょうか。私自身、4 つのドメインで AI を活用しながら執筆していますが、最初の頃は「便利だが自分の文章ではない」という感覚に悩まされました。
そこで切り替わったきっかけが、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本に当ててみた結果が次の通りです。
| 記事 | 敬体率 | 主観マーカー | 段落末の問い |
|---|---|---|---|
| 本記事の初稿 | 88%（56/64文） | 13 箇所 | 0/18 段落 |
| 4サイト自動運用の記録 | 86%（76/88文） | 0 箇所 | 0/51 段落 |
| Skills の日常的な使い分け | 100%（56/56文） | 8 箇所 | 0/25 段落 |
面白かったのは敬体率が 100% に届かない記事があったことです。中身を確認すると常体が混じっていたわけではなく、体言止めと箇条書きの断片が文として拾われていました。つまりこの指標は「常体の混入」ではなく「文末の型のばらつき」を測っています。私はしきい値を 95% に置いていますが、体言止めを好んで使う方は 85% あたりの方が実態に合うはずです。
もっと効いたのは主観マーカーの列でした。0 箇所だった記事を読み返すと、たしかに解説調に寄っていて、自分の判断がどこにも書かれていません。書いている最中は気づかず、数値が先に違和感を教えてくれた形です。段落末の問いかけが全記事で 0 だったのも同じで、SKILL.md にルールとして書きながら自分が守っていませんでした。ルールを疑うか自分を疑うか、判断する材料が数字で出てきます。
ひとつ釘を刺しておくと、この種の指標は満たすほど良いというものではありません。問いかけを機械的に増やせば、段落末が全部「〜ではないでしょうか」になり、かえって読みにくくなります。私は数値を合否ではなく「読み返す場所の当たりをつける道具」として扱っていて、しきい値を割った箇所だけを目で確認する運用に落ち着きました。
個人的に効いた工夫: 「自分の声サンプル」を埋め込む
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」「個人ブランド」のような、明らかに個人発信の文脈でのみ使うキーワードに絞るのが安全です。
文体を Skill 化することは、AI を「自分の代筆者」ではなく「自分の声を理解する共同編集者」に変える作業に近いと私は感じています。代筆させたいのではなく、自分が書いたものを自分の基準で見てほしい。そう考えるようになってから、Skill に書くルールの粒度が変わりました。
次に試してほしいこと
まずは過去記事を3本読み返し、共通する癖を5個書き出してみてください。それだけで、自分が「無意識に守っていたルール」が言語化されます。書き出したルールを SKILL.md の最小構成に流し込み、トリガーキーワードを「ブログ」「note」のように絞った状態で発火テストをすれば、その日のうちに「自分っぽい下書き」が出せるようになります。本格運用に入ってから細部を調整する流れの方が、最初から完璧を目指すよりずっと早く成果が見えるはずです。
Skill のファイル構造そのものに不慣れな場合は、Markdown 基礎から始める Skill 執筆ガイド が下地になります。