Claude Code のスタイルガイドの作り方。タスク専用のルールを言語化する
同じ要望を毎回プロンプトに書き直している——そんな違和感が出てきたら、スタイルガイドを書く合図です。CLAUDE.md がプロジェクト全体の取扱説明書なら、スタイルガイドは「特定タスクを同じ品質で頼むためのルール集」。書き方を実例とともに整理しました。
はじめに
Claude Code に依頼を出していて、こんな経験はないでしょうか。
「記事を書いて、と頼むたびに『絵文字を使わないで』『見出しは ## から』『リードは100字以内』を毎回つけ足している」 「コードを書いてもらうたびに『TypeScript で』『関数名は camelCase』『コメントは日本語』を毎回書いている」
毎回同じ要望を打ち直している——これに気づいたら、スタイルガイドを書く合図 です。
スタイルガイドは「特定のタスクを、毎回同じ品質で頼むためのルール集」。書いておけば、Claude が起動するたびに「もう知っているよ」という前提で動いてくれます。前回の記事「CLAUDE.md の書き方」が プロジェクト全体の取扱説明書 だとしたら、スタイルガイドは そこから一段細かい、特定タスクの設計図 にあたります。
スタイルガイドとは何か（CLAUDE.md との違い）
両者の違いを表にまとめると、こうなります。
| 観点 | CLAUDE.md | スタイルガイド |
|---|---|---|
| 範囲 | プロジェクト全体 | 特定のタスク（記事執筆・コーディング・Slack 返信など） |
| 読まれるタイミング | Claude 起動時に自動 | そのタスクを依頼するときに参照される |
| 想定読者 | プロジェクト全員（自分＋ Claude） | そのタスクを頼まれた Claude のみ |
| 例 | 「日本語で返す・強い操作は確認する」 | 「記事は3,000字以内・絵文字禁止・見出しは ## から」 |
CLAUDE.md は 「常に効かせたいルール」。スタイルガイドは 「呼び出した時だけ効かせたいルール」。両者は守備範囲が違うので、片方だけでは足りません。
どこに置くか（3つの選択肢）
スタイルガイドの置き場所には、3つの選択肢があります。
a. CLAUDE.md の中にセクションとして書く
向いているケース：プロジェクト内で1つのスタイルガイドしか必要ない場合。
## 記事執筆のスタイルガイド
- リード文は100字以内
- 見出しは ## から始める
- 絵文字は使わないシンプルで管理しやすい一方、CLAUDE.md が肥大化しやすいのが弱点です。
b. 別ファイルに切り出す
向いているケース：スタイルガイドが長くなる、または複数種類ある場合。
my-project/
├── CLAUDE.md
└── style-guides/
├── article-writing.md
└── code-style.mdCLAUDE.md からは「詳細は style-guides/article-writing.md を参照」とリンクで誘導します。マギのクロゼミではこの方式 を取っています。
c. Skill として独立化する
向いているケース：スタイルガイドを「コマンドで呼び出して」発動させたい場合。
~/.claude/skills/article-writing/
└── SKILL.md/article-writing のように / で呼び出せるようになります。プロジェクトを横断して同じスタイルを使いたいときに最強です。
選択は 頻度と再利用性 で決まります。月数回なら a、毎週使うなら b、複数プロジェクトで使うなら c——という目安です。
書くべき5項目
どこに置くにせよ、書くべき項目は同じです。
1. 目的（なぜこのガイドが存在するか）
最初に1〜2行で書きます。
## 目的
マギのクロゼミの記事を、人間執筆と区別がつかない品質で量産するためのガイド。目的を書かないと、ルールが矛盾したときの判断基準がなくなります。
2. トーン／文体
「どんな空気で書いてほしいか」を1段抽象的に伝えます。
## トーン
- 語尾はです・ます調で統一
- 業界用語には必ず1行の補足を添える
- 「〜と言えるでしょう」のような断定回避は使わない3. 禁則ルール（やらないでほしいこと）
ここが一番効きます。
## 禁則
- 絵文字を使わない
- 「以下に〜を示します」のような前置き定型句を使わない
- 推測・一般論を書かない（実体験ベースのみ）「やってほしいこと」より、「やらないでほしいこと」 のほうが圧倒的に効きます。Claude は親切なので、放っておくと余計なことを足しがちです。先回りして遮断するルールを書いておくと、毎回の修正指示が消えます。
4. 参考例（手本）
言葉だけで伝えづらいトーンは、実例を1〜2本貼る のが手っ取り早いです。
## 参考例
- 既存記事の代表例：[posts/what-is-claude-code.md](posts/what-is-claude-code.md)
- このトーン・この粒度で書く「この記事のトーンに揃えて」と言えるだけで、Claude は迷わなくなります。
5. チェックリスト
書き終わったあとの自己点検項目を、依頼者本人ではなく Claude が自分で確認する形 で書きます。
## 完成チェック
- [ ] 文字数は 3,500〜4,500字に収まっているか
- [ ] 絵文字を使っていないか
- [ ] 見出しは ## から始まっているか
- [ ] 「〜でしょう」が混入していないかこれがあると、Claude が成果物を提出する前にセルフチェックする習慣ができます。
実例：マギのクロゼミの記事執筆スタイルガイド
このメディア（マギのクロゼミ）では、marketing/CLAUDE.md に記事執筆ルールが書かれています。要点を抜き出すと、こんな構成です。
## 記事作成の原則
**全記事、実体験ベースで書く。推測・一般論は書かない。**
### 記事の基本構成
1. 導入：なぜこの記事を書いたか・誰向けか
2. 結論：最初に答えを出す
3. 実体験：メモの内容をストーリー化
4. ハマりポイント・注意点
5. まとめ：向いている人・向いていない人
6. CTA：関連商材への自然な誘導
### 品質基準
- 文字数：3,000〜5,000字
- スクショ・コード例：最低3つ
- 「〜と思われます」「〜でしょう」等の曖昧表現は使わない
- 大げさな収益報告・誇大表現は書かない
- 使ったことのないツールは紹介しない短いですが、5項目（目的・基本構成・禁則・最低要件・参考方針）がほぼ揃っています。ガイドは長くなくていい——必要十分な分量で、迷う余地を消すのが本質です。
ありがちな失敗
スタイルガイドを書いてみたものの、機能しないパターンがあります。
失敗1：暗黙ルールの未言語化
頭の中にあるけれど、書かれていないルール。これは Claude には伝わりません。「読み手がムッとしないトーン」のような感覚的なものは、「！を多用しない」「断言調を避ける」 のように具体に落としましょう。
失敗2：テンプレ流用
他のプロジェクトのスタイルガイドをそのまま貼り付けると、ほぼ機能しません。スタイルガイドは 自分のプロジェクトの「失敗の蓄積」 が言語化されたもの。他人のものを借りても、自分の文脈には合いません。
失敗3：古いまま放置
ルールは、運用しながら追記・削除を繰り返すのが現実的です。書いたら終わり、ではなく、Claude が「やらかした」「気が利いた」を見るたびに1行追加する——この更新頻度が、スタイルガイドの寿命を決めます。
まとめと次回
スタイルガイドは、特定のタスクを毎回同じ品質で頼むためのルール集 です。CLAUDE.md がプロジェクト全体の取扱説明書なら、スタイルガイドは特定タスクの設計図にあたります。置き場所は3つの選択肢から頻度と再利用性で決め、書くべき項目は5つ（目的・トーン・禁則・参考例・チェックリスト）。短くて十分、運用しながら育てていく道具です。
これで Step 4「プロンプト設計」シリーズは3本完結です。次は Step 5「研究室で深掘りする」シリーズで、まずは ハーネス設計 で個別機能を束ねる視点を入れたあと、Skills 自作・MCP サーバー自作・Hooks 実装といった拡張機構の自作へと進みます。すでに公開済みの記事から読むと、プロンプト設計の基本→ハーネス設計→拡張機構の自作、という学習の流れが完成します。
WordPressを実際に動かしてきたサーバー：ロリポップ
Claude Code でWordPressサイトを組み立てるとき、最初に置く先として無理のないレンタルサーバー。月数百円から始められ、WordPressの自動インストールにも対応しています。設定で詰まりがちな初期段階の時間をかなり減らせます。