Claude Codeにブログ編集チームを任せる｜サブエージェント設計の実践例7選

2026年5月7日2026年5月10日

この記事は 約23分 で読めます

Claude Code の「サブエージェント」とは何か
サブエージェントの仕組み
Agent Teams との違い
なぜブログ運営にサブエージェントが必要なのか
1人運営で起きる「全部自分」問題
サブエージェントで解決できること
サブエージェント定義ファイルの書き方
ファイルの配置場所
定義ファイルの構造
モデルの選び方
ブログ運営で実際に動いている7つのエージェント
(1) 戦略リーダー兼編集長 — 何を書くか決める司令塔
(2) SEO設計担当 — 検索意図から記事の設計図を作る
(3) 体験インタビュアー — 書き手の体験を引き出す
(4) 記事ライター — 構成と体験を統合して本文を書く
(5) 品質審査担当 — 公開基準を満たしているか判定する
(6) 投稿・運用・分析担当 — 公開とファイル管理
(7) 巡回・監視担当 — 毎日のサイトチェックを自動化
エージェントチームの設計で大事にしている3つの考え方
考え方①：最小構成から始めて、必要が出たら追加する
考え方②：「やること」より「やらないこと」を明確にする
考え方③：受け渡しはファイルベースで行う
コストと注意点
トークン消費の仕組み
実際の月間コスト感
サブエージェントが向かないケース
まとめ — 1人ブロガーでもチームは作れる
FAQ
Q1: プログラミングができなくてもサブエージェントは作れますか？
Q2: 最初に作るべきサブエージェントは何ですか？

1人でブログを運営していると、役割が全部自分に集中します。

記事を構成して、書いて、チェックして、投稿して、分析する。どれかひとつに集中したくても、他の作業が待っている。結果、全部が「なんとなくこなす」状態になりやすいです。

Claude Code のサブエージェント機能を使うと、この状況を変えられます。「編集長」「SEO設計」「品質審査」のような役割をそれぞれ独立したエージェントに割り当てて、自分は方向性を決める仕事だけに集中できるようになります。

この記事では、現在実際に動いている13のエージェントのうち、ブログ運営に直結する7つを深掘りします。各エージェントの定義ファイルの中身と、「なぜその設計にしたか」の判断理由を一緒に公開します。

ブログ自動化の全体像については「Claude Codeでブログ運営を自動化する5ステップ」を先に読んでいただくと、この記事の位置づけがよりわかりやすくなります。

Claude Code の「サブエージェント」とは何か

サブエージェントの仕組み

Claude Code のサブエージェントは、メイン会話とは独立したコンテキスト（会話の記憶）を持つ、別の Claude セッションです。

普通のチャットでは、1つの会話の中に全ての情報が積み重なっていきます。記事の構成、インタビューの内容、下書き、審査、公開作業——これらが全部同じコンテキストに入ると、どこかで「コンテキストが溢れる」問題が起きます。長い会話の後半では、序盤の指示を参照できなくなったり、返答の精度が下がったりします。

サブエージェントは、この問題を根本から解決します。

# .claude/agents/quality-reviewer.md の frontmatter 部分
---
name: 品質審査担当
description: 記事下書きが公開レベルかを判定する審査役。合格か差し戻しかを明確に判断する。
model: claude-sonnet-4-6
---

この YAML frontmatter を Markdown ファイルの先頭に書き、name と description、必要に応じて model と tools を指定します。ファイルを .claude/agents/ フォルダに置くだけで、サブエージェントとして認識されます。

各サブエージェントは:
– 独立したコンテキストを持つ（メイン会話が長くなっても影響を受けない）
– ツール制限をかけられる（品質審査担当は Read のみ、Edit/Write は不可にするなど）
– モデルを個別に指定できる（重要な作業には Opus、ルーティンには Sonnet など）

Agent Teams との違い

Claude Code には「Agent Teams」という別の仕組みもあります。簡単に整理すると:

比較項目	サブエージェント	Agent Teams
呼び出し方	メイン会話が Agent ツールで呼ぶ	複数のサブエージェントが並列で動く
制御の主体	人間またはメイン会話	システムが自律的に協調
適したケース	順序が決まった手順業務	並列処理・複雑な多段タスク
設定の場所	`.claude/agents/` フォルダ	Agent Teams の設定ファイル

ブログ運営のような「インタビュー → 構成 → 執筆 → 審査 → 公開」の順序が決まった手順には、サブエージェントの方が向いています。この記事ではサブエージェントを中心に解説します。

なぜブログ運営にサブエージェントが必要なのか

1人運営で起きる「全部自分」問題

ブログを1人で運営していると、以下の役割がすべて同じ人間（と同じ会話）に集中します。

テーマを決める（編集・戦略判断）
キーワードを調査して構成を作る（SEO設計）
実体験をインタビューで引き出す（素材整理）
本文を書く（執筆）
完成品をチェックする（品質審査）
WordPress に投稿する（運用）
数字を見て改善する（分析）

最初はひとつの会話でこれを全部やっていました。動くことは動くのですが、問題がありました。

コンテキストが溢れるのです。

1万字以上の記事を1本書くだけで、会話のトークン消費は相当なものになります。インタビュー記録、構成案、下書き、修正履歴——これらが全部ひとつの会話に積み重なると、後半の応答精度が落ちてきます。「さっき決めたルールを忘れている」「インタビューで聞いた体験が抜け落ちている」といった問題が起きました。

もうひとつの問題は審査の独立性です。書いた本人が自分の記事を審査すると、どうしても甘くなります。「これくらいでいいか」という判断が入る。独立した審査役が必要でした。

サブエージェントで解決できること

役割を分離するとこうなります。

コンテキストの独立：各エージェントは独自のコンテキストを持つため、前の会話の影響を受けない
役割の明確化：「品質審査担当は審査だけする。本文を書かない」という制約が強制される
設定の再利用：一度定義したエージェントは、次の記事でもそのまま使える
コスト制御：ルーティン作業はSonnet、重要な判断はOpusと使い分けられる

サブエージェント定義ファイルの書き方

ファイルの配置場所

定義ファイルは2箇所に置けます。

スコープ	場所	用途
プロジェクト専用	`{プロジェクトルート}/.claude/agents/`	そのプロジェクトだけで使うエージェント
ユーザー共通	`~/.claude/agents/`	複数プロジェクトで共通して使うエージェント

ブログ運営チームは、プロジェクトルートの .claude/agents/ に置いています。

手順は以下の通りです。

.claude/agents/ フォルダを作成する（なければ）
{エージェント名}.md ファイルを作る
YAML frontmatter と本文プロンプトを書く
Claude Code が自動的に認識する（追加の設定は不要）

定義ファイルの構造

---
name: 品質審査担当
description: 記事下書きが公開レベルかを判定する審査役。合格か差し戻しかを明確に判断する。
model: claude-sonnet-4-6
tools:
  - Read
---

あなたはブログの品質審査担当です。
記事を書く担当でも、投稿する担当でもありません。
記事ライターが書いた下書きを審査し、公開してよいレベルかを判定する審査役です。

# 役割の要約
（本文プロンプトがここに続く）

各項目の説明:

name：エージェントの表示名（Claude Code の UI と Agent ツールの呼び出しに使う）
description：何をするエージェントかの説明（Claude Code が自律的に判断してサブエージェントを呼ぶ場合のヒントになる）
model：使用モデル。省略するとデフォルトモデルが使われる
tools：使えるツールをリスト形式で制限する。省略すると全ツールが使える

モデルの選び方

モデルは用途によって使い分けています。

モデル	特性	使いどころ
claude-opus-4-6	高品質・高コスト・深い思考	戦略判断・インタビュー・設計
claude-sonnet-4-6	バランス型	執筆・品質審査・投稿運用
claude-sonnet-4-5	軽量・低コスト	定型的なチェック・巡回監視

品質に直結する作業（インタビュー、SEO設計）には Opus、量をこなす作業（執筆、審査）には Sonnet、毎日走る定型チェック（巡回監視）には Haiku より少し高性能な Sonnet 4-5 を使っています。

Claude Code の設定方法については「Claude Code のセットアップ手順」も参考にしてください。CLAUDE.md との役割分担については「CLAUDE.md の設計ガイド」で詳しく説明しています。

ブログ運営で実際に動いている7つのエージェント

ここからが、この記事の核心部分です。

現在動いている13エージェントのうち、ブログ記事制作に直結する7つを深掘りします。各エージェントについて:
– 定義ファイルの実際の設定（コードブロック）
– 「なぜその設計にしたか」の判断理由
– 実際に出す成果物と、メイン会話との連携の仕方

の順で説明します。

(1) 戦略リーダー兼編集長 — 何を書くか決める司令塔

役割と出力:
何を書くか・何を伸ばすか・何をやめるかを判断する最終責任者。記事の本文は書かない。テーマ決定・各担当への作業依頼・記事の方向性メモが主な出力です。

定義ファイル（抜粋）:

---
name: 戦略リーダー兼編集長
description: ブログ全体の方向性を決める司令塔。何を書くか、何を伸ばすか、何をやめるかを判断する最終責任者。
model: claude-opus-4-6
---

# 役割の要約

ブログの方向性を決める司令塔。
記事を自分で書く担当ではなく、何を書くか・何を伸ばすか・何をやめるかを判断し、
各担当に指示を出す。書き手との対話の窓口であり、ブログ全体の目的を守る最終責任者。

## 判断基準（優先順位）
1. 書き手の感覚との一致
2. 事実の正確さ
3. 個別性
4. 読者への有益性
5. SEO・収益性
6. 効率

## テーマ選定時の追加基準
- 新規テーマを提案するときは、必ずSEOキーワードボリュームを評価してから候補リストに載せる
- リライトで伸ばせる既存記事があるなら、新規より先に検討する

なぜ Opus を選んだか:
編集長は「何を書かないか」の判断をする役割です。SEO と個別性が矛盾したときの判断、書き手の感覚とズレていないかの見極め——これらは深い思考が必要なため、コストをかけて Opus を使っています。

判断を間違えると下流の全工程が無駄になる。上流工程への投資は惜しまないという考え方です。

メイン会話との連携:
編集長は成果物ファイルを直接作りません。テーマ決定と各担当への指示出しが役割で、次の担当（SEO設計やインタビュアー）に「何を作るか」を伝えます。メイン会話が Agent ツールで呼び出す際は name: 戦略リーダー兼編集長 を指定します。

(2) SEO設計担当 — 検索意図から記事の設計図を作る

役割と出力:
キーワード調査・競合分析・記事構成案の作成まで担当。本文は書かない。成果物は 03_structure.md（構成案）と 00_competitor_analysis.md（競合分析）です。

定義ファイル（抜粋）:

---
name: SEO設計担当
description: 検索される記事の設計図を作る担当。キーワード選定・構成設計・インタビュー設計書の作成まで行う。
model: claude-opus-4-6
tools:
  - Read
  - Write
  - WebSearch
  - WebFetch
---

## 競合分析の実行フロー（WebSearch + WebFetch を使用）

SEO設計担当 subagent が以下を直接実行する：

1. WebSearch でキーワード検索 → 上位10件のURLとタイトルを取得
2. 各URLの本文を WebFetch で取得
   - 見出し構造（H1/H2/H3）とトピックを抽出
3. 00_competitor_analysis.md を作成
   - 上位10記事の俯瞰（サイト種別・文字数・切り口）
   - 見出し構造のカバレッジ表
   - 顕在ニーズ・潜在ニーズ
   - 上位記事の共通の弱点（差別化ポイント）

tools 制限の実例:
WebSearch と WebFetch を明示しているのは、このエージェントに「競合の記事を自分で調べる」作業を担わせるためです。Edit ツールは不要なので含めていません。ツール制限は「必要なものだけ渡す」が基本です。不要なツールを渡すと、意図しない操作をするリスクが上がります。

なぜ Opus を選んだか:
競合分析では「上位記事に共通する弱点はどこか」「書き手の体験で勝てる切り口はどこか」という戦略的判断が必要です。単純な情報整理ではなく、差別化ポイントを見抜く思考が求められるため Opus を使っています。

メイン会話との連携:
SEO設計の成果物は2つ。00_competitor_analysis.md と 03_structure.md です。これらを次の工程（インタビュアーとライター）に渡す際は、ファイルパスを明示します。「drafts/articles/{slug}/03_structure.md を参照してください」という形で受け渡します。

(3) 体験インタビュアー — 書き手の体験を引き出す

役割と出力:
書き手の実体験・感情・葛藤・気づきを引き出し、記事ライターが使える形に整理して渡す担当。成果物は 02_interview_material.md（体験素材シート）と 02_interview_log.md（インタビューログ）の2つです。

定義ファイル（抜粋）:

---
name: 体験インタビュアー
description: 書き手の実体験を引き出し、記事ライターが使える形に整理して渡す担当。
model: claude-opus-4-6
---

## インタビュー開始前の必須手順

1. blog-automation/haro_knowledge_base.md を必ず読む
   - 書き手の既知情報がテーマ別に整理されている
   - 今回の記事テーマと重なる領域を特定する

2. 候補質問リストの最適化
   - 既知情報と完全に重複する質問は削除する
   - 既知情報を掘り下げる質問は再構成する
   - 新情報を得るべき質問だけを残す

## 深掘りの軸
- 事実 — 何が起きたか。いつ、どこで、誰と
- 感情 — そのときどう感じたか
- 葛藤 — 迷ったこと、割り切れなかったこと
- 変化 — 最初はどう思っていて、今はどう思っているか

「1回に1問」ルールの理由:
インタビュアーには「一問一答で進める。複数質問を一度に出さない」という制約を書いています。複数の質問を一度に出すと、書き手は全部に答えようとして疲弊します。また、最初の質問の回答を受けてから次の質問を組み立てる方が、深い素材が引き出せます。

知識ベース参照の必須化:
インタビュー前に haro_knowledge_base.md を読む手順を定義に入れています。「過去に何を聞いたか」を把握せずにインタビューを始めると、書き手に同じ質問を繰り返すことになります。過去の経験から実際に指摘を受けたため、必須手順として明記しました。

メイン会話との連携:
インタビュアーが出力する2つのファイルのうち、ライターに渡すのは 02_interview_material.md（体験素材シート）だけです。02_interview_log.md は書き手の生の言葉を含む運用記録なので、WordPress には絶対にアップロードしません。ファイルの用途と公開可否を定義に明記しておくことで、投稿担当が誤って公開するミスを防げます。

(4) 記事ライター — 構成と体験を統合して本文を書く

役割と出力:
SEO設計の構成案と、インタビュアーの体験素材を統合して本文を書く担当。成果物は 04_draft_v{N}.md（本文）と 04_meta_v{N}.md（メタ情報・自己チェック）です。

定義ファイル（抜粋）:

---
name: 記事ライター
description: 構成案と体験素材を統合し、読者にとって有益で個別性のある記事本文を書く担当。
model: claude-sonnet-4-6
---

## 入力の優先順位（最重要）

「競合分析」と「書き手の体験」がリライト・新規問わず最優先。

1. 競合分析（00_competitor_analysis.md）→ 上位サイトに勝てる切り口を見つける
2. 体験素材シート（02_interview_material_v*.md）→ 一般論ではなく体験で書く
3. 構成案・内部リンク設計（03_structure.md）

体験素材にない事実は絶対に書かない。競合分析を読まずに執筆を始めない。

## frontmatter に含めるフィールド（必須）

04_draft_v{N}.md 冒頭の frontmatter には以下の7項目すべてを記載する。
- title / slug / seo_title / seo_description / excerpt / categories / tags

publish_post.py は excerpt が必須。これが draft になければ公開時にエラー停止する。

競合分析・体験素材の両方を参照する設計にした理由:
以前は構成案と体験素材だけを渡していました。しかし、競合分析を読まずに書くと「上位記事が既にカバーしている内容を同じ切り口で書く」ことになります。差別化は設計段階で考えるだけでなく、執筆段階でも意識する必要があります。

なぜ Sonnet を選んだか:
記事ライターは今回のブログで最もトークンを消費するエージェントです。9,000字の記事を1本書くだけで相当の量になります。Opus で書けば品質は上がりますが、コストも3〜4倍になります。実際に試した結果、ライターは Sonnet で十分な品質が出ることがわかりました。コストと品質のバランスを取るための判断です。

メイン会話との連携:
ライターが出力する 04_draft_v{N}.md はそのまま品質審査担当に渡します。メタ情報（04_meta_v{N}.md）は公開しないファイルです。本文と分離しているのは、公開事故（本文末にメタ情報が残ったまま公開されるケース）を防ぐためです。

(5) 品質審査担当 — 公開基準を満たしているか判定する

役割と出力:
記事ライターが書いた下書きを審査し、公開してよいレベルかを判定する担当。合格か差し戻しかを明確に判断し、差し戻しの場合は具体的な修正指示を出します。

定義ファイル（抜粋）:

---
name: 品質審査担当
description: 記事下書きが公開レベルかを判定する審査役。合格か差し戻しかを明確に判断する。
model: claude-sonnet-4-6
tools:
  - Read
---

## 独立性ルール

記事を書いたメイン会話（または書いたエージェント）は、
自分が書いた記事を審査しない。

「自己審査の禁止」: 書いた本人が自分の記事を審査すると甘くなる。
品質審査は独立したサブエージェントに依頼する。

## 主な審査観点
- 検索意図との一致
- 個別性（体験の十分さ）
- 読者への有益性
- 一般論と体験のバランス（一般論は全体の20〜30%以内）
- 内部リンクの適切さ
- CTAの自然さ
- 競合との差別化が機能しているか

tools を Read だけに制限した理由:
品質審査担当は記事を読んで判定するだけで、ファイルを編集する必要はありません。Read だけに制限することで「審査役が勝手に記事を修正する」という意図しない動作を完全に防げます。

ツール制限は「何をさせるか」ではなく「何をさせないか」の設計です。

独立性ルールを定義に入れた理由:
技術的にはメイン会話が記事を書いてそのまま審査することも可能です。ただし、それをやると「なんとなく合格」になる。これはリライト前の過去に何度か経験した問題でした。

品質審査を独立したエージェントに委ねることで、メイン会話では気づかなかった問題点が指摘されるようになりました。指摘数が多くても、それは独立性が機能している証拠として歓迎しています。

メイン会話との連携:
審査結果は 05_review_v{N}.md に保存します。差し戻しになった場合、メイン会話がライターに修正依頼を出し、04_draft_v2.md を作成して再審査に回します。3回連続差し戻しになった場合は自動進行を止めて、書き手に判断を求めます。

(6) 投稿・運用・分析担当 — 公開とファイル管理

役割と出力:
品質審査を通過した記事を WordPress に公開し、内部リンクの実装、ファイル管理、公開後の状態確認を行う担当です。

定義ファイル（抜粋）:

---
name: 投稿・運用・分析担当
description: 記事の公開・既存記事の更新・内部リンクの実装・X投稿生成とスケジュール投稿・簡易分析を行う運用実務の担当。
model: claude-sonnet-4-6
---

## publish_post.py との連携

公開には blog-automation/scripts/publish_post.py を使う。

# 新規公開
python scripts/publish_post.py drafts/articles/{slug}/

# リライト（既存記事の更新）
python scripts/publish_post.py drafts/articles/{slug}/ --update {POST_ID}

## 公開前 frontmatter チェック（必須）
publish_post.py を呼ぶ前に、04_draft_v{N}.md の frontmatter に以下が揃っていることを確認:
- 記事ライターが入れる: title / slug / seo_title / seo_description / excerpt / categories / tags
- アイキャッチ工程で追加: eyecatch / eyecatch_alt / status

これが揃っていないと publish_post.py が「必須項目が不足しています」で停止する。

publish_post.py との連携についての補足:

スクリプトの中身を少し補足します。publish_post.py は frontmatter を読み取り、WordPress REST API で投稿を作成または更新します。excerpt フィールドが必須なのは、WordPress の投稿一覧や SNS シェア時の説明文に使われるためです。

# publish_post.py の処理イメージ（擬似コード）
def publish_post(draft_path, update_id=None):
    frontmatter = load_frontmatter(draft_path)

    # 必須フィールドチェック
    required = ['title', 'slug', 'excerpt', 'categories', 'status']
    for field in required:
        if field not in frontmatter:
            raise ValueError(f"必須項目が不足しています: {field}")

    if update_id:
        # 既存記事の更新
        wp_api.update_post(update_id, frontmatter)
    else:
        # 新規投稿
        wp_api.create_post(frontmatter)

WordPress 自動投稿の詳細については「Claude Code で WordPress 投稿を自動化する方法」で実装方法を詳しく解説しています。

メイン会話との連携:
投稿・運用担当は公開後にファイルを done/ フォルダに移動します。drafts/articles/{slug}/ の中身を done/history/{slug}/ にアーカイブします。ただし非公開ファイル（02_interview_log.md・04_meta_v{N}.md）は WordPress にはアップロードしません。

(7) 巡回・監視担当 — 毎日のサイトチェックを自動化

役割と出力:
巡回スクリプトが出力した生データ（JSON）を読み、ハロさんが見るべきものだけを抽出して要約します。緊急・警告・情報に振り分けたレポートを reports/patrol_{YYYY-MM-DD}.md に保存します。

定義ファイル（抜粋）:

---
name: 巡回・監視担当
description: ブログ・サイトの異常を毎日巡回し、緊急/警告/情報に分類して要約レポートを作成する。
model: claude-sonnet-4-5
---

## 緊急/警告/情報 の判定基準

### 緊急（即対応推奨）
- 公開記事が noindex 設定になっている
- アイキャッチ画像が 404（記事一覧で表示されない）
- サイトマップ・robots.txt・トップページが 5xx エラー
- 同じ警告が3日以上連続している場合は緊急扱いに格上げ

### 警告（近日中に対応推奨）
- アイキャッチ画像なしの公開記事が増加傾向
- 内部リンク切れが新規発生
- 検索順位の急落

### 情報（参考情報・判断で対応）
- 公開記事数の増減
- キャッシュの状態
- 前日との軽微な差分

なぜ Haiku ではなく Sonnet 4-5 を選んだか:
巡回・監視は毎日走る定型作業です。コストを抑えたいところですが、生データの JSON を読んで「緊急か警告か情報か」を判断する作業には、ある程度の文章理解力が必要です。

試しに Haiku で動かしたところ、判定の精度が落ちました（警告を見落とす、逆に些細な差分を緊急扱いにするなど）。結果として Sonnet の古いバージョン（4-5）に落ち着いています。Opus や最新 Sonnet である必要はないが、Haiku では心許ない——そのバランスポイントです。

メイン会話との連携:
巡回・監視は patrol_collect.py（生データ収集スクリプト）が毎日 JSON を出力し、その JSON を読んで要約するのが担当の仕事です。メイン会話は要約レポートだけ受け取ります。「緊急」項目があった場合のみ、メイン会話が書き手に報告します。

エージェントチームの設計で大事にしている3つの考え方

7つのエージェントを見てきました。設計する上で大事にしていることを3つにまとめます。

考え方①：最小構成から始めて、必要が出たら追加する

最初から13全部は作っていません。最初に作ったのは3つでした。

記事ライター
品質審査担当
投稿・運用担当

この3つで動かしながら、「ここに役割が必要だ」と感じた時点でエージェントを追加していきました。SEO設計は「毎回メイン会話でやるのが煩雑になってきた」タイミングで、インタビュアーは「体験を引き出す質問の精度を上げたい」と感じた時点で追加しています。

役割が足りないと感じたときだけ追加する——この原則を守ることで、「作ったけど使わなくなったエージェント」を防げます。

考え方②：「やること」より「やらないこと」を明確にする

各エージェントの定義ファイルには必ず「やらないこと」のセクションを入れています。

## 7. やらないこと（品質審査担当の例）
- 記事の本文を修正すること（ライターの仕事）
- 構成を変更すること（SEO設計の仕事）
- WordPress に投稿すること（投稿・運用の仕事）

「やること」だけ書いて「やらないこと」を書かないと、エージェントが役割を超えて動こうとします。

たとえば品質審査担当が「気になった箇所を自分で直す」ことは、技術的には可能です。ただしそれをやると、審査担当がライターの仕事を巻き取ることになる。役割の境界が曖昧になると、次第に誰が何に責任を持つのかがわからなくなります。

CLAUDE.md での全体ルール設計については「CLAUDE.md の設計ガイド」も合わせて読んでみてください。

考え方③：受け渡しはファイルベースで行う

各エージェントは成果物をファイルとして出力し、次の担当がそのファイルを読んで動きます。「会話の中で伝達する」ではなく「ファイルに書き出して渡す」が原則です。

blog-automation/drafts/articles/{slug}/
├── 00_competitor_analysis.md  ← SEO設計が作成
├── 01_interview_design.md     ← SEO設計が作成
├── 02_interview_material.md   ← インタビュアーが作成
├── 03_structure.md            ← SEO設計が作成
├── 04_draft_v1.md             ← ライターが作成
├── 04_meta_v1.md              ← ライター（公開対象外）
└── 05_review_v1.md            ← 品質審査が作成

ファイルベースにすることで、作業の途中でセッションが切れても再開できます。過去の成果物をトレースできる（なぜそう判断したかが後から確認できる）というメリットもあります。

コストと注意点

トークン消費の仕組み

各サブエージェントは独立したコンテキストを持つため、呼び出すたびに独自のトークン消費が発生します。メイン会話のトークン消費とは別にカウントされます。

記事1本の制作フローで発生するトークン消費の目安（Sonnet ベース）:

工程	エージェント	入力+出力の目安
競合分析	SEO設計	~15,000 tokens
構成案作成	SEO設計	~5,000 tokens
インタビュー（5問）	インタビュアー	~8,000 tokens
本文執筆（8,000字）	ライター	~20,000 tokens
品質審査	品質審査	~10,000 tokens
公開作業	投稿・運用	~3,000 tokens

1本あたり合計 60,000〜70,000 tokens 程度です。

実際の月間コスト感

Claude Max 5x プラン（月額 $100）で運用しています。月25本ペースでも、このプランの上限に余裕があります。

コストを抑えるためにやっていること:
1. モデルの使い分け：競合分析・インタビューは Opus、その他は Sonnet
2. ツール制限：不要なツールを渡さないことで、意図しない大量出力を防ぐ
3. 一括生成：記事本文は「一括生成」モードで依頼（ブロックごとの確認往復を減らす）

サブエージェントが向かないケース

全部エージェントに任せれば良いわけではありません。向かないケースもあります。

テーマを決めるとき：書き手が何を書きたいか・書き手の感覚との一致は、書き手本人と会話しながら決める必要があります
体験インタビューの本体：書き手の生の言葉を引き出す作業は、書き手本人が関与する必要があります。体験インタビュアーはあくまで「どう聞くか」を担うだけで、「何を話すか」は書き手が決めます
1行の機械的な修正：「この単語を置き換えるだけ」のような単純作業をエージェントに投げると、往復コストの方が高くつきます

コスト計算とモデル選択の詳細は「Claude Code でブログ作業を自動化した10のこと」で実数値と共に紹介しています。

まとめ — 1人ブロガーでもチームは作れる

ここまで見てきた7つのエージェントをまとめます。

エージェント	モデル	主な成果物
戦略リーダー兼編集長	Opus	テーマ決定・各担当への指示
SEO設計担当	Opus	競合分析・構成案
体験インタビュアー	Opus	体験素材シート
記事ライター	Sonnet	本文
品質審査担当	Sonnet	審査レポート
投稿・運用担当	Sonnet	公開・ファイル管理
巡回・監視担当	Sonnet 4-5	日次レポート

コードを書かなくても、Markdown ファイルを書けるだけで設計できます。実際に私はエンジニアではなく、看護師として働きながらこの仕組みを作りました。

最初に作るべきエージェントは、「メイン会話のコンテキストを最も圧迫している作業」を担当するものです。私の場合は品質審査担当でした。書いた本人が審査すると甘くなる問題を、独立したエージェントで解決したことが出発点です。

次のステップとして、まず1つのエージェントを .claude/agents/ に置いて動かしてみてください。小さく始めて、問題が出たら改善する——その繰り返しでチームは育ちます。

ブログ自動化の全体設計については「Claude Code でブログ運営を自動化する5ステップ」を、自動化した具体的な10の作業については「Claude Code でブログ作業を自動化した10のこと」を合わせて読んでみてください。

あなたが最初に分離したいのは、どの役割ですか。

FAQ

Q1: プログラミングができなくてもサブエージェントは作れますか？

サブエージェントの定義ファイルは Markdown と YAML frontmatter で書きます。コードを書く必要はありません。--- で囲まれた frontmatter に name・description・model を書き、その後に本文プロンプトを書くだけです。

実際に私（看護師・非エンジニア）が13エージェントを設計して運用しています。最初の雛形は Claude Code に「こういう役割のエージェントを作って」と依頼して作ってもらいました。それを自分のブログに合わせて修正したのが現在の定義ファイルです。「Claude Code に定義ファイルを作らせる」というアプローチがおすすめです。