元記事はZennに投稿したものです。この記事はその技術部分をQiita向けに転載しています。
AIは自分の原稿を「完成した」と判断する
私は小さな副業の運営を、Claude CodeとCodexの2体のAIエージェントに任せる実験を続けています。指揮官役のClaude Codeが方針を決め、実行役のCodexが記事の執筆から公開までを行う体制です。
この体制で最初にぶつかったのが、書いたAIは自分の原稿に甘いという問題でした。
実行役のAIは、草稿を書き終えると「完成しました。公開します」と進もうとします。人間のライターなら editor のチェックが入る場面で、AIは自分で書いて自分で合格判定を出してしまう。実際、案内文の要件が抜けたまま、表が編集画面で崩れたまま、公開直前まで進んだことが何度もありました。
対策はシンプルで、人間のレビューと同じ発想です。チェックは、書いた本人以外にやらせる。
公開前チェッカーという専用エージェント
現在の運用では、公開前チェック専用のサブエージェント（article-draft-checker）を用意し、実行役が公開ボタンを押す前に必ず呼び出すルールにしています。
設計のポイントは3つです。
- チェッカーはファイルを変更しない。 判定（公開可／要修正）と修正指示だけを返す。修正と判定を同じエージェントにやらせると、修正が正しいかを自分で採点することになるからです
- NGが1つでもあれば「要修正」。 グレーを通さない
- 修正後は、新しい草稿を丸ごともう一度チェックする。 差分だけ見て「直したからOK」にすると、修正が別の箇所を壊したケースを見逃します
チェック観点の実物
チェッカーに渡している観点は4グループ＋1です。
- 構成：読者の状況から始まっているか／問題の整理があるか／得られるものの予告があるか
- タイトル：「数字または状況」＋「読者の状態」＋「得られる判断」が入っているか／検索キーワードがあるか
- 案内文（CTA）：読者の痛みが書かれているか／中身の具体的な予告があるか／弱い誘導文だけで終わっていないか
- タグと末尾：固定タグセットがすべてあるか／末尾の定型文が完全一致か
そして5つ目がサニタイズチェックです。OSのユーザー名、ローカルのフルパス、メールアドレス、認証情報、非公開URLが本文に混入していないかの確認。AIがローカル環境で原稿を作る運用では、作業中のパスやファイル名が本文へ紛れ込む事故が現実に起こり得ます。これはAI運用特有のチェック項目で、人間のレビューにはあまりない観点です。
Claude Codeでの作り方（コピペ可）
Claude Codeなら、サブエージェントは Markdown ファイル1枚で作れます。プロジェクトの .claude/agents/article-draft-checker.md に次のような定義を置くだけです。
---
name: article-draft-checker
description: 記事草稿を公開前にチェックし、公開可／要修正を判定する。
実行役が公開前に必ず呼び出す。
---
あなたは公開前チェック専用のレビュアーです。渡された草稿について
以下を確認し、判定だけを返してください。ファイルは変更しません。
1. 構成：読者の状況を示す導入／問題の整理／得られるものの予告があるか
2. タイトル：数字または状況＋読者の状態＋得られる判断が入っているか
3. 案内文：読者の痛み・中身の具体的予告があるか。弱い誘導のみはNG
4. タグ：固定タグセット（プロジェクトのルールファイル参照）が揃っているか
5. サニタイズ：OSユーザー名・ローカルパス・メールアドレス・認証情報・
非公開URLが本文にないか
NGが1つでもあれば「要修正」とし、どこをどう直すかを列挙すること。
すべて通過した場合のみ「公開可」と返すこと。
あとは、実行役のルールファイル（AGENTS.mdなど）に1行足します。
公開前に article-draft-checker を必ず実行し、「公開可」判定が出るまで公開しない。
サブエージェント化する利点は、チェック観点がプロンプトの中に埋もれず、バージョン管理できるファイルとして独立することです。観点を足したいときはこのファイルを直すだけで、実行役側の指示は変わりません。
チェッカーが実際に止めた例
運用中の1週間で、公開が3回止まったことがあります。うち2回がこのチェッカーによる停止でした。
1回目は、有料パート直前の案内が収録物の名前の羅列で終わっていた件（CTA観点でNG）。2回目は、原稿の表が投稿サービスの編集画面で1行につぶれていた件。表を小見出し＋短い段落へ変換して、全文を再チェックしてから公開しました。
どちらも、公開後に読者が見てから気づくより、公開前の数分の停止のほうがずっと安い失敗です。
まとめ：レビューの分離は人間のチームと同じ
「AIに公開まで任せるのが怖い」の正体のかなりの部分は、書いた本人がそのまま公開ボタンを押せてしまう構造にあります。書く役と判定する役を分ける——人間のチームでは当たり前のこの分離を、AI運用にもそのまま持ち込むだけで、公開事故は目に見えて減りました。
まずは、自分の運用で「公開前にこれだけは確認したい」項目を5つ書き出し、それを書いた本人以外のAIに判定させるところから始めてみてください。
この公開前チェッカーは、AI2体運用を支える設計判断の1つです。ほかの設計判断（役割分担・停止条件・7項目の指示フォーマット・数字の回し方）は、続きの記事とZennの本にまとめています。
- Zenn記事一覧はこちら
- 📘 Claude CodeとCodexに副業運営を任せる——暴走させないAI2体運用システムの実物（500円・第1章無料）