「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 のルールが具体化不足です。曖昧な箇所を具体例で書き換えてから再テストします。
個人的に効いた工夫: 「自分の声サンプル」を埋め込む
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 執筆ガイド でも解説しています。Skill 全般の運用感をつかみたい方は Cowork スキルと自動化の入門 も併せてご覧ください。