Claude Code でブランド校正を仕組みにする発想
校正はこれまで、書き手か編集者が読み返して直す作業でした。Claude Code はターミナルで動く AI コーディング支援ツールで、CLI からリポジトリの md ファイル群を直接触れます。
つまり、原稿を「コード」と同じ扱いで処理できます。基準を書いておけば、その基準に沿って反応します。
Anthropic の公式ドキュメントによると、Claude Code はターミナル / IDE / デスクトップアプリ / Web の複数のサーフェスで動きます。どのサーフェスでも同じ CLAUDE.md 群を読み込むので、一度組んだ校正の型はどこからでも走らせられます。
編集チームが VS Code で原稿を触っても、デスクトップアプリで別セッションを立てても、同じ基準が走ります。ブランド運用で一番厄介な「人によって基準が違う」問題を、リポジトリの一枚に寄せられます。
制作の現場でどう使うかの全体像は、Claude Code をクリエイティブに使う実装ガイド で並べています。ブランド校正はその中でも「編集の目を助ける」層に位置づきます。
基準を CLAUDE.md に書き下ろす
Claude Code はセッション開始時に CLAUDE.md を読み込みます。対象はプロジェクト直下の CLAUDE.md、ユーザーホームの ~/.claude/CLAUDE.md、ローカル用の CLAUDE.local.md です。
公式ドキュメントは 200 行を目安に絞ることを推奨しています。書くほど文脈を食い、指示の追従率が落ちるためです。
書き方は具体的にします。「フォーマットを整える」ではなく「2 スペースインデントを使う」の水準です。ブランド校正では次のように落とします。
- 「〜させていただく」は使わない
- 「お客様」は本文で使わず「読者」に置き換える
- 「クリエイティブ」の直後に「制作物」を並べない
- 月や年度を名指す時期依存の言い方は避ける
- 疑問符は 1 段落に 1 個までにする
こう書いておくと、原稿を触るセッションのたびに読み込まれます。人が同じ指示を繰り返し伝える手間が消えます。
禁止語彙は grep で機械的に見つける
Claude Code は Bash ツールを持っています。grep を叩けます。まず「禁止語彙一覧」を .claude/rules/ の中に置きます。
.claude/rules/ は公式が用意しているルール格納ディレクトリです。md ファイルを置くと、CLAUDE.md と同じ扱いで読み込まれます。
用途を絞ったスラッシュコマンドを組んで、次のように渡すのが分かりやすい形です。
- /tone-lint を叩く
- articles/ 配下の md を対象にする
- 禁止語彙一覧に載っている語を grep で走査する
- 見つかった語と行番号を短い一覧で返す
書き手は「見つかったのはここ 2 か所」と結果だけ受け取ります。全文を読み返さなくても、当たりが付きます。
grep を使う長所は、判断が入らないことです。正規表現に載っているかどうかで機械的に落ちるので、書き手も編集者も結果の見方でぶれません。表記揺れ、社名の綴り、伏せておきたい旧サービス名など、正解が一つに決まる項目はまず grep 側に寄せます。
代わりに、意味の判定は次の Skills 側に回します。「言葉が載っているか」と「言い方として合っているか」で層を分けるのが安定した設計です。
社内で同時に走らせる姉妹ワークフローは Claude Code でブランドコンテンツを大量制作する にまとめています。制作側と校正側が同じ .claude/rules/ を共有する形が組めます。
口調の統一を Skills 化する
Claude Code の Skills は SKILL.md を書いて、その手順を Claude Code 側に持たせる仕組みです。バンドルされた /doctor や /code-review と同じ形で、自分の型を追加できます。
保存先はプロジェクト直下の .claude/skills/tone-check/SKILL.md か、ユーザーホームの ~/.claude/skills/ です。プロジェクト直下に置いた場合はリポジトリで共有されます。
SKILL.md 側には次の粒度で書きます。
- 敬体と常体が同じ段落に混ざっている箇所を挙げる
- 一文の字数が 45 字を超えている箇所を挙げる
- 読点が一文に 2 つ以上入っている箇所を挙げる
- 疑問符が段落に 2 つ以上入っている箇所を挙げる
判定はモデル側の読解に任せます。grep より柔らかい代わりに、意味を読んだ上で返してきます。
同じ Skills の考え方でブログ記事の量産に振ったパターンが Claude Code でブログ記事を一括生成する です。校正ルールを共有すれば、生成と校正が同じ規則の上で回ります。
表記揺れと用語集を .claude/rules/ に常駐させる
用語集を md で書いておくと、常に読み込まれます。「Claude / クロード / Claude Code / クロードコード」といったカタカナ 4 種の canonical 形を書き並べる場所として、rules は便利です。
path-scoped rules も使えます。frontmatter の paths フィールドに */.md と書けば、md ファイルを触るときだけそのルールが有効になります。
コードには関係のない校正ルールを、文脈を消費せずに待機させられます。書き手が原稿を開いた瞬間に反応させる用途に合います。
用語集を「資産」として管理する発想は Claude Design 企業導入ガイド と同じ流れです。片方は言葉の統一、片方は色や書体の統一という並びで、ブランドの土台を組みます。
校正専用の subagent を分ける
subagent は Claude Code の別コンテキストで動くサブエージェントです。校正のような読解タスクを主会話から切り離して、結果だけ戻せます。
.claude/agents/brand-tone-reviewer.md を作って、frontmatter に次を書きます。
- name: brand-tone-reviewer
- description: 原稿の md を読み、禁止語彙と口調揺れを見つけて位置と語を返す
- tools: Read, Grep
- model: haiku
Write と Edit を外しておくと、subagent は指摘だけを返し、勝手に書き換えません。ブランド校正の初動は「発見」に閉じるのが安全です。書き換えは書き手の判断に残します。
haiku を指定すると、料金を抑えられます。校正は探索が主で生成量が少ないため、軽いモデルで足ります。
さらに permissionMode: default を指定しておくと、subagent が想定外の tool を触ろうとしたときに書き手側で止められます。ブランド校正は誤検出よりも「勝手に書き換えられた」事故のほうが影響が大きいので、権限は狭く握るのが基本です。
複数のブランドを並行で扱う場合、~/.claude/agents/ にプロフィールごとの subagent を並べておくと、切り替えのたびに CLAUDE.md を書き直さなくてすみます。ブランドを跨いだ書き手ほどこの分離が効きます。
FileChanged hook で執筆中に検出する
Claude Code の Hooks は、セッション内のライフサイクルイベントに処理を差し込む仕組みです。PreToolUse や PostToolUse に加えて、FileChanged というイベントも用意されています。
FileChanged は、Claude Code がファイルの変更を検知したときに走ります。原稿の md を保存した直後に、校正の subagent を呼び出す構成が組めます。
書き手にとっては、編集画面で字幕が出るような感覚に近い体験です。段落を書き終えた瞬間に、禁止語彙と表記揺れの候補が短く返ってきます。
Hooks の出力は exit code と JSON の両方で表現できます。禁止語彙が見つかったら exit code 2 を返して次の tool 呼び出しを止める、あるいは JSON で「decision: block」を返して人に判断を促す、といった分岐を設計できます。
編集のリズムを崩さないコツは、指摘の粒度を段落単位に絞ることです。行単位で毎回止めると書き手が疲弊します。段落を書き終えたタイミングで、その段落に閉じた指摘だけを短く返す、という設計が長続きします。
PR にコメントとして返す
Claude Code は GitHub Actions と連携できます。公式ドキュメントには GitHub Code Review という項目があり、PR のたびに Claude Code を走らせる形が案内されています。
原稿を md で管理してブランチ運用にしていれば、PR ごとにブランド校正が走ります。指摘は PR の inline コメントとして返せます。
編集チームでレビュー会を挟む前に、機械的なチェックを済ませておけます。会議の時間は判断が必要な箇所に集中できます。
運用の最初は、Actions を「読むだけ」に絞るのが穏当です。指摘は PR に返しつつ、CI を落とすのは表記揺れの重い項目に限る。基準に慣れてきた段階で、禁止語彙の一部を CI 失敗条件に格上げする、といった段階運用ができます。
外部の校正 SaaS を借りるよりも、自社のリポジトリ内に基準を持ち続けられるのが Claude Code の強みです。基準の更新履歴が Git のコミットに残るので、なぜこの語を禁止にしたかを後から辿れます。
型として運用する 判断は人に残す
ブランド校正を仕組みにしても、全自動にしないほうが安全です。意図的に基準を外している段落や、書き手が息を入れるために置いた破調は、機械には見分けが付きません。
「Claude Code が挙げた指摘のうち、7 割は反映する」くらいの温度で運用するのが現実的です。3 割の余白が、ブランドの息づかいを残します。
判断そのものを外注しないでください。校正の型は、書き手の目を助ける仕組みとして置くのが安定します。
デザイン領域で同じ発想を先に走らせた例が Claude Artifactsでブランドブックを作る手順 です。言葉の校正と絵の校正は、同じ「基準を書いて反応させる」構造で組めます。
もう一つ大切なのは、基準そのものを更新し続ける前提を持つことです。ブランドは動きますし、書き手も入れ替わります。禁止語彙リストや Skills の内容を月一で見直す時間を、編集フローの中に組み込んでおくと、機械の目が古びません。
FAQ
Q1. Claude Code でブランド校正を始めるには何から手をつければよいですか
A. 禁止語彙と表記揺れの一覧を、.claude/rules/ の md に一枚書くところから始めます。基準を書き出すだけで、セッションのたびに読み込まれます。Skills や subagent の追加は、その一枚が回り始めてから足しても間に合います。
Q2. CLAUDE.md と .claude/rules/ の使い分けは何ですか
A. CLAUDE.md はプロジェクト全体で必ず読み込ませたい基準を書く場所です。.claude/rules/ はトピック別に分けて書ける場所で、path-scoped rules を使うと対象ファイルを触ったときだけ読み込まれます。校正ルールは触った瞬間に読み込ませたいので rules 側が向きます。
Q3. 禁止語彙のリストはどこに置くのがよいですか
A. .claude/rules/brand-glossary.md のような分かりやすい名前で置きます。禁止語と canonical 形を並記し、grep で拾えるように箇条書きにしておくのが安全です。用語集は資産として扱ってください。
Q4. 校正専用 subagent を作るときに絞るべき tool は何ですか
A. Read と Grep に絞るのが安全です。Write と Edit を外しておくと、subagent は勝手に書き換えず、指摘だけを返します。校正の初動は「発見」に閉じたほうが、書き手の判断が残ります。
Q5. 執筆中に自動でチェックするには何を組めばよいですか
A. FileChanged hook を使います。原稿の md を保存した直後に校正の subagent を呼び出す形にすると、段落ごとに候補が返ってきます。編集の速度を落とさずに、機械の目を横に置く運用が組めます。