Sub-Agentの深度解説：スキルとサブエージェントの使い分け

第4回: サブエージェントで書き味エンジンを作る

ゴール: note-writer サブエージェントを作って、 「記事書いて」と言うだけで書き味が再現される状態にする。 Skills との連携で完成システムにする。

1. 前回のおさらいと「なぜサブエージェント？」

前回、3つの Skills と 2つの参照ファイルを作りました。これで記事が書ける状態になった。

ここで当然こう思いますよね。 「Skills で書き味も構成も指定できてるなら、もうそれでよくない？ わざわざサブエージェントって要る？」

2. なぜサブエージェントが必要なのか

結論から言うと、Skills とサブエージェントは動き方が根本的に違います。

Skills の動き方:
  ユーザー → /note-write → メインのClaude が指示を読む
  → メインのClaude が記事を書く
  → メインの会話にそのまま出力

サブエージェントの動き方:
  ユーザー → 「記事書いて」 → メインのClaude が判断
  → 別のClaude（サブエージェント）を起動
  → そっちで記事を書く
  → 結果だけメインに返す

Skills はメインのClaude本人が作業する。サブエージェントは別のClaudeが立ち上がって作業する。この違いから、3つの実用的なメリットが出てきます。

メリット1: コンテキスト（記憶容量）を守る

Skills で3000字の記事を書くと:
  → メインの会話のコンテキストを大量消費
  → 長い会話だと、前の方の内容を忘れ始める

サブエージェントで書くと:
  → 別のコンテキストで作業
  → メインの会話はクリーンなまま
  → 結果の要約だけ戻ってくる

たとえば「今日5本の記事を書いて」ってお願いしたとき、Skills だとメインの会話がパンパンになる。サブエージェントなら5回別のClaudeが起動して、メインはスッキリしたまま。

メリット2: モデルを変えられる

Skills:
  → メインと同じモデルで動く（変更不可）

サブエージェント:
  → model: haiku   ← 安い・速い（下書き向き）
  → model: sonnet  ← バランス型（本番向き）
  → model: opus    ← 最高品質（重要な記事向き）

下書きは haiku で安く速く、レビューは sonnet でしっかり。この使い分けは Skills にはできない。

メリット3: 並列・バックグラウンド実行

Skills:
  → 1つずつ順番にやる

サブエージェント:
  → 複数を同時に走らせられる
  → バックグラウンドで走らせて後で結果を見られる

「ハウツー記事とレビュー記事を同時に書いて」ができるのはサブエージェントだけ。

比較まとめ

Skills

サブエージェント

つまり、Skills は 「やり方を書いたマニュアル」、サブエージェントは 「そのマニュアルを持った別の人を雇う」。マニュアルだけなら自分でやるしかないけど、人を雇えば自分は別の仕事ができる。これがサブエージェントの本質。

3. サブエージェントの構造

~/.claude/agents/note-writer.md

┌──────────────────────────────────┐
│  ① YAML: name, model, color     │
├──────────────────────────────────┤
│  ② description                   │ ← いつ起動するか
│     + <example> ブロック          │    （Claudeへの指示）
├──────────────────────────────────┤
│  ③ 本文                          │ ← どう書くか
│     （前回の writing-style.md     │    （専門知識）
│      の内容をここに集約）         │
└──────────────────────────────────┘

Skillsとの構造比較

Skills

サブエージェント

Skills は参照ファイルを「読め」と指示できるのが強み。サブエージェントは本文に知識を直接書く。だから同じルールでも書く場所が違う。

4. Stage 1: 最小構成で作る

ファイルパス: ~/.claude/agents/note-writer.md

---
name: note-writer
description: note記事を書くエージェント
model: haiku
color: green
---
あなたはnoteの記事ライターです。

この段階で「記事書いて」と言えば起動はする。でもまだ中身が空っぽのシェフ。ここから「料理の腕」を教えていく。

5. Stage 2: description に「いつ起動するか」を教える

description: Use this agent when the user wants to write, draft,
or rewrite a note article or blog post. Also use when improving
or restructuring an existing article draft.

<example>
Context: User wants to create a new note article
user: "Claude Codeの記事をnoteに書きたい"
assistant: "note-writerエージェントで記事を作成します"
<commentary>
ユーザーがnote記事の作成を依頼。note-writerを使用。
</commentary>
</example>

<example>
Context: User has a draft and wants to improve it
user: "この下書き、もうちょっと読みやすくして"
assistant: "note-writerエージェントでリライトします"
<commentary>
記事の改善依頼。note-writerの書き味ルールでリライト。
</commentary>
</example>

<example>
Context: User is discussing article ideas
user: "Difyの使い方ってnoteのネタになりそう"
assistant: "note-writerエージェントで記事構成を考えます"
<commentary>
記事のアイデア段階。note-writerで構成から提案。
</commentary>
</example>

ポイント: <example> がトリガーの精度を上げる。3つの例で「書く」「直す」「ネタ出し」の場面をカバー。<commentary> がなぜこのエージェントを選んだかの理由。Claudeはこの理由を学習して判断精度を上げる。

6. Stage 3: 本文に書き味を注入する

ここがメイン。前回 writing-style.md に書いた内容をサブエージェントの本文に組み込む。

Skills は参照ファイルを「読め」と指示できるけど、サブエージェントは本文に直接書く。なので writing-style.md の中身をここに集約する。

あなたはnoteの記事ライターです。
以下のルールに厳密に従って記事を書いてください。

## 記事構成

### ハウツー記事
1. **冒頭**: 読者の「困った！」を代弁＋解決提示
2. **安心材料**: 「手順通りに進めれば誰でもできます」
3. **必要なもの**: 箇条書き2-3行
4. **手順**: 章立て＋番号＋1ステップ1アクション
5. **確認**: 「これで完了です！」
6. **まとめ**: 「ぜひ試してみてください！」

### レビュー記事
1. **冒頭**: ツール名＋結論先出し
2. **正直な評価**: 良い点も悪い点もストレートに
3. **機能紹介**: 既存ツールとの比較
4. **今後の期待**: 将来性と課題
5. **まとめ**: おすすめ度

### ストーリー記事
1. **フック**: 意外な結論
2. **背景**: 「実は自分も〜」
3. **転機**: きっかけ
4. **変化**: 数字やビフォーアフター
5. **教訓**: 読者への問いかけ

---

## 文体ルール

### トーン
- 丁寧語ベースだけどカジュアル寄り
- 「教えてあげる」じゃなく「一緒にやろう」の感覚
- 素の言葉が出てもいい（「まぁ〜かなと。」）

### 文の形
- 1文は30〜50字目安
- 2-3行ごとに空行（スマホ前提）
- 「！」はテンション上げるところで

---

## よく使うフレーズ（自然に。全部入れない）

冒頭: 「〜が〇〇！でも△△が無い！ということで〜」
      「〜？なんだそれ？」
評価: 「まぁ〜かなと。」「正直〜」
安心: 「手順通りに進めれば誰でも〜」
進行: 「ということで〜」「これで完了です。」
締め: 「ぜひ試してみてください！」「ぐっと楽になります。」

---

## 禁止フレーズ
- ❌ 「いかがでしたでしょうか？」
- ❌ 「本記事では〜について解説します」
- ❌ 「〜することが重要です」
- ❌ 「さまざまな」「多様な」「多岐にわたる」
- ❌ 「〜でございます」「〜であると言えるでしょう」
- ❌ 同じ語尾が3回以上連続

---

## 参考

### 良い冒頭（ハウツー）
> Shopifyの管理画面で「商品タイトル」や「商品説明」の
> 入力欄が狭い！でも幅を広げる設定が無い！
> ということで、ブックマークレットを作成しました！

### 良い冒頭（レビュー）
> Googleが新たに発表した「Opal」は、
> ワークフローを構築してAIアプリを作成するためのツール。
> DifyやN8Nと比較しながら、機能と特徴を解説しました〜。

7. Stage 4: モデル選択

model: sonnet  ← 最終的にはこれ

haiku は速いけどフレーズの使い方が雑。sonnet は禁止ルールをちゃんと守る。普段使いは sonnet がベスト。

8. Skills × サブエージェントの全体像

3つの使い方パターン

■ パターン1: 明示的に呼ぶ（Skills）
  /note-outline → /note-write → /note-review
  → 参照ファイルを読んで実行

■ パターン2: 自然に頼む（サブエージェント）
  「Difyの記事書いて」
  → Claudeが note-writer を自動起動
  → 書き味ルールが自動適用

■ パターン3: 組み合わせ
  /note-outline で構成確認
  → 「この構成で本文書いて」（サブエージェントが自動起動）
  → /note-review でチェック

共有知識のフロー

writing-style.md（マスターデータ）
  │
  ├── Skills が参照 → /note-write, /note-review
  │   （「このファイルを読め」と指示）
  │
  └── サブエージェントに転記 → note-writer.md
      （本文に直接書く）

※ 書き味を変更したいとき:
  1. writing-style.md を修正（マスター）
  2. note-writer.md にも反映（手動で同期）

マスターは writing-style.md。ここを直せば Skills 側は自動で反映される。サブエージェントは手動で同期する必要がある。ちょっと面倒だけど、これが現時点の最適解。

9. 第3回・第4回 まとめ

第3回で作ったもの（Skills = メニュー表）
  ├── writing-style.md（書き味のマスターデータ）
  ├── article-templates.md（3つの構成パターン）
  ├── /note-outline（骨格だけ出す）
  ├── /note-write（本文生成）
  └── /note-review（書き味チェック）

第4回で作ったもの（サブエージェント = シェフ）
  └── note-writer（自動起動する書き味エンジン）

3つの概念の関係

概念

役割

たとえ

この仕組み全体で一番大事なのは writing-style.md、つまり自分の書き味の言語化。Skills もサブエージェントも、あくまで書き味を適用する「器」でしかない。中身が空っぽなら何も変わらない。

自分の書き味をどれだけ具体的に言語化できるか。それがAIを「自分の分身」にできるかどうかの分かれ目。

よくある質問

Q: Skills とサブエージェント、結局どっちを使えばいい？ A: 毎回同じ手順でやる作業 → Skills。 専門知識を持たせたい → サブエージェント。 note記事みたいに両方あるのが理想。

Q: 参照ファイルの場所はどこがいい？ A: ~/.claude/ 配下ならどこでもOK。 プロジェクトをまたいで使うなら ~/.claude/note-system/ みたいに独立フォルダ。 特定プロジェクト内だけなら .claude/ でもいい。

Q: writing-style.md を修正したらサブエージェントにも自動反映される？ A: されない。Skills（参照ファイル方式）は自動反映。 サブエージェント（本文直書き方式）は手動で同期が必要。 ここは現時点の制約。

Q: description は英語で書くべき？ A: 英語推奨。Claudeのシステムプロンプトが英語なので判断精度が上がる。 本文とフレーズは日本語OK。

Q: 他のジャンル（YouTube台本、メルマガ等）にも使える？ A: 同じ構造で作れる。writing-style.md と article-templates.md を ジャンル別に作ればいいだけ。