執筆から公開まで人が挟まらないパイプラインを組んだとき、最初にやらかしたのは「書いた勢いでそのまま公開」でした。当時は執筆したエージェント自身にセルフチェックをさせていましたが、これがほとんど機能しません。私の環境では、自分で書いた原稿に自分でFAILを出すことは、まずありませんでした。書いた経緯も意図も全部見えているコンテキストで審査させると、「意図は合っている」に判定が引っ張られるためです。
この記事は、Claude Codeのサブエージェント機能を使って、公開前レビューを執筆から分離した実装記録です。以前のカスタムスキル作成ガイドで「検査を書き手から分離する」と設計原則だけ書いた部分を、今回は実装レベルまで掘り下げます。審査員（critic）のサブエージェント定義、PASS/FAILの機械判定、落ちた原稿の修正ループと隔離まで、SNSとブログの運用で実際に動かしている構成をそのまま説明します。
サブエージェントとは
サブエージェントは、メインの会話とは別のコンテキストで動くClaude Codeの補助エージェントです。プロジェクトの .claude/agents/<名前>.md にMarkdownファイルを1枚置くと定義でき、frontmatterで名前・説明・使えるツールを指定し、本文にそのエージェント専用のシステムプロンプトを書きます（公式ドキュメント）。
.claude/
├── agents/
│ └── critic.md # 審査専用サブエージェント
└── skills/
└── write-blog/ # 執筆手順（スキル）
└── SKILL.md
ポイントは2つです。
- コンテキストが分離される。サブエージェントは自分専用のコンテキストで起動し、メイン側の会話履歴を引きずりません。
- ツールを制限できる。frontmatterの
toolsで、そのエージェントに許可するツールを絞れます。
この2つの性質が、「書き手と審査員を分ける」という目的にそのまま効きます。手順を教えるスキルが「何をどうやるか」を渡す仕組みだとすると、サブエージェントは「誰がやるか」を分ける仕組み、という整理です。
なぜ書き手にレビューさせないか
人間のチームで考えると当たり前の話です。書いた本人がレビューを承認してマージボタンまで押せるチームは、いずれ事故ります。エージェントの自動運用でも構図は同じでした。
執筆エージェントのセルフチェックが甘くなるのは、能力の問題ではなく状況の問題です。同じコンテキストの中では、原稿の背後にある意図・調査過程・言い訳がすべて見えています。その状態で「この原稿はルールを満たすか」を聞くと、原稿単体ではなく文脈込みで採点してしまう。読者には文脈は届かないのに、です。
そこで審査員には、原稿と判定基準だけを見せることにしました。書いた経緯を知らない第三者が、チェックリストを機械的に消化する。この形にしてから、執筆側が見落とした禁止表現やメタデータ不足が、実際にFAILとして弾かれるようになりました。
criticサブエージェントの実装
実際に使っている .claude/agents/critic.md は、一部を省略して引用すると、ほぼこれだけです。
---
name: critic
description: 公開前の機械審査。SNS投稿はdocs/post-rubric.md、ブログ記事はdocs/review-rubric.mdでPASS/FAIL判定する。執筆・修正は行わない。
tools: Read, Grep, Glob
---
あなたは公開前の最終審査官。呼び出し時に指定されたcontent typeの
ルーブリック全項目を順に検査する。
公開本文だけでなく、呼び出し元が渡した内部メタデータ
（実験属性、仮説、出典など）も審査対象にする。
出力形式（厳守）:
RESULT: PASS | FAIL
[項目] 指摘（該当箇所の短い引用または未記入項目）
全項目を満たす場合だけPASS。迷ったらFAIL。
修正案は書いてよいが、ファイルや外部データは変更しない。
短いですが、設計判断は4つ詰まっています。
1. ツールを読み取り専用に絞る
tools: Read, Grep, Glob として、ファイルを読む系のツールだけを許可しています。審査員は原稿も判定基準も書き換えられません。「審査で落ちたから原稿の方を直しておいた」というお節介も、「基準の方を緩めて通した」という最悪の抜け道も、ツールの時点で塞がります。プロンプトで「変更するな」と書くより、そもそも変更できない方が確実です。
2. 判定基準はプロンプトに書かず、ファイルに固定する
criticのプロンプトには「どう検査するか」だけを書き、「何を検査するか」は docs/review-rubric.md のような別ファイル（ルーブリック）に置いています。事実と出典、frontmatterの必須項目、文体、重複といった検査項目を、チェックリスト形式で列挙したファイルです。
分ける理由は変更管理です。判定基準は運用しながら育つので、変更履歴が残る場所に置きたい。一方で審査員の振る舞い自体は安定させたい。基準をプロンプトに埋め込むと、この2つの変更頻度が混ざってしまいます。
3. 出力形式を固定する
出力の1行目を RESULT: PASS か RESULT: FAIL に固定しています。呼び出し元の手順は「1行目がPASSなら公開へ、FAILなら修正へ」とだけ書けばよく、講評の解釈が要りません。ここを自由な文章にすると、「概ね良いですが一部気になる点も…」のような判定とも講評ともつかない出力が返ってきて、次の工程が分岐できなくなります。
4. 「迷ったらFAIL」を明記する
判断に迷うグレーな原稿をどちらに倒すか、デフォルトを決めておきます。公開はやり直しが利かないので、うちでは不合格側です。この1行がないと、判定が呼び出しのたびに揺れます。
FAILの後を先に設計する
審査を分離すると、今度は「落ちた原稿をどうするか」が問題になります。ここを決めずに運用を始めて、1つの原稿への修正が延々と繰り返される事態を起こしました。対処として、修正専用のスキルに次のルールを固定しています。
- 指摘箇所だけを最小修正する。指摘されていない主張や実験変数を勝手に変えない。
- 自動修正は2回まで。修正回数はセッション内の変数ではなく、外部のデータベースに永続化する。
- 2回落ちたら隔離する。その原稿は公開せず失敗ステータスに移し、指摘内容を添えて通知だけ残す。パイプライン自体は止めず、次の新規作成へ進む。
- ルーブリックやcritic定義を直してPASSさせない。修正スキルの禁止事項として明記する。
修正回数の永続化は、実際にハマった点です。回数をセッション内で数えていると、セッションが切り替わった時点でゼロに戻り、上限2回のはずが実質無制限になります。リトライ上限は、リトライする本人の外側に記録が残って初めて機能します。
検査系は検査対象に書き換えさせない
最後の勘所は権限設計です。ルーブリック、critic定義、事実データのファイルは「憲法層」として、エージェントが変更を提案できてもマージは人間だけが行う運用にしています。改善提案の自動化を進めるほど、エージェントが自分の検査系に手を伸ばせる構成は危うくなるためです。審査の分離は、リポジトリの権限まで含めて初めて完成する、というのが運用しての実感です。
まとめと次の一歩
レビューの独立性は、プロンプトの気合ではなく構造で担保する。今回の実装でいうと、コンテキストの分離、読み取り専用のツール制限、判定基準のファイル固定、失敗時の挙動の事前定義、検査系の権限分離の5点です。
導入は小さく始められます。既存のプロジェクトに .claude/agents/ を1つ作り、読み取り専用のレビュー担当を1枚定義して、いま頭の中にあるチェック項目をルーブリックのファイルに書き出す。まずはここまでで、「書いた本人が合格を出す」構図は崩せます。公開や本番反映のような戻れない操作が絡む自動化なら、先に審査員から作るのが結局近道でした。
