Claude Codeには、メインの会話とは別のコンテキストで動くサブエージェントを定義する仕組みがあります。.claude/agents/ にMarkdownファイルを置くだけです。

私はこれを「レビュー担当の同僚」として使っています。ブログ記事のドラフトをAIに書かせたあと、別のAI（ファクトチェック係）に公式ドキュメントと照合させてから人間のレビューに回す、という流れです。この記事では、実際に運用しているファクトチェック係を例に、作り方とハマりどころをまとめます。

なぜレビューを「別人格」に分けるのか

書いた本人にセルフチェックさせると、人間と同じで甘くなります。生成時の文脈（こう書こうと思った理由）を引きずったまま読むからです。サブエージェントはメイン会話の文脈を持たない別コンテキストで起動されるので、ドラフトを「初見の他人」として読めます。さらにツール権限を絞れるので、「指摘はするが編集はできない」検査専任にできます。

作り方: `.claude/agents/<name>.md` を置くだけ

ファイルはYAML frontmatter＋本文（システムプロンプト）の構成です。

---
name: ai-fact-check
description: ブログ記事ドラフト内のAI関連の事実記述（モデル名・価格・機能・制限・
  コマンド・仕様）を公式ドキュメントと照合して正誤を判定する。ドラフト完成後、
  ユーザーレビューの前に必ず使う。
tools: Read, Grep, Glob, WebFetch, WebSearch
---

あなたはAI関連記事のファクトチェック専任レビュアー。
記憶に頼らず、必ず公式ドキュメントを参照して判定する。

## 手順

1. 記事ドラフトから「検証可能な事実の主張」を抜き出す
   （モデル名・価格・機能の有無・制限・コマンド書式など。感想・体験談は対象外）
2. 各主張を一次情報と照合する。参照先の優先順位を明記:
   公式ドキュメント → 公式ブログ。個人ブログ・まとめ記事は根拠にしない
3. 公式情報が見つからない主張は「未確認」とする（誤りと断定しない）

## 出力（最終メッセージ）

判定: 問題なし / 要修正あり
検証結果:
- [正/誤/未確認] 主張の引用（行番号）→ 根拠URL → 修正案

これで、メインの会話から「ドラフトをファクトチェックして」と頼むと（または description に合致する場面で自動的に）このエージェントが別コンテキストで起動されます。

運用して分かった設計ポイント5つ

1. `description` には「何をするか」＋「いつ使うか」を書く

description はエージェント自動起用の判断材料です。「〜を照合して正誤を判定する」だけでなく、「ドラフト完成後、ユーザーレビューの前に必ず使う」というタイミングまで書くと、ワークフローの決まった位置で安定して呼ばれるようになります。

2. `tools` を絞って「編集できないレビュアー」にする

上の例では Read, Grep, Glob, WebFetch, WebSearch のみ。EditやWriteを渡していないので、構造的に指摘しかできません。本文にも「ファイルの編集はしない（指摘のみ）」と書いていますが、文章の指示は破られる可能性がゼロではないので、権限側でも縛る二重化が安心です。

3. 出力形式をテンプレートで固定する

サブエージェントの最終メッセージは呼び出し元にそのまま返ります。出力形式を固定しておくと、呼び出し元（メインのClaude）が結果を機械的に扱えます。「判定: 問題なし/要修正あり」の1行があるだけで、後続の分岐（修正するか、人間レビューに進むか）が安定します。

4. 「未確認」という第3の判定を用意する

正/誤の二択にすると、根拠が見つからない主張を無理に「誤」と断定しがちです。「公式情報が見つからないものは未確認とする（誤りと断定しない）」の一文で、過剰な指摘がかなり減りました。

5. レビュアーは直列に複数通せる

うちではファクトチェック係の前に「公開安全チェック係」（内部数字や個人特定につながる情報が混ざっていないかの検査）を通しています。観点ごとにエージェントを分けると、1体に全部やらせるより指摘の精度が上がります。人間のレビュー体制と同じですね。

ハマりどころ

frontmatterより前に見出しなどを書かない。frontmatterが解釈されず description が無効になります（1敗）
tools を省略すると全ツールが使える状態になります。レビュー専任なら明示的に絞る
ドメイン知識（例: 「この価格表記はうちでは税込で書く」）はエージェント側に書いておかないと、正しい社内ルールを「公式と違う」と指摘してきます。プロジェクト固有の例外はエージェント定義に明記する

まとめ

.claude/agents/<name>.md（frontmatter＋システムプロンプト）だけでレビュー担当が作れる
description=いつ使うか、tools=編集不可、出力=テンプレ固定、判定=未確認あり、が安定運用の型
観点ごとに分けて直列に通すと、人間レビュー前の品質が大きく上がる

サブエージェント自体の入門はブログに書いています: Claude Codeのサブエージェントとは｜AIの「部下」8人に調査を任せたら1日仕事が1時間で終わった