【AIビルダーの現場】AIが書き、別のAIが検査し「人が決める」　代理店のAI運用

米ノースカロライナ州でWeb制作とマーケティングの代理店を営むJake St. Peter氏が、会社の実務をAIエージェントで回す仕組みを自身のブログで公開した。Claude Codeで下書きを作るAIと、それを検査するAIを分けた。レビューを通っても公開の許可にはならず、定期ジョブの公開も本人が決めた範囲に限る。本人の集計では、9月29日から10月12日までに記録した判断99件は、すべて本人が下した。翌13日の数え直しでも、103件すべてが本人の判断だった。任せる仕事を増やしても、何を人が握るかを先に決めておけば崩れない。少人数のチームがエージェントを使う時の設計図になる事例だ。

AIの「社員」は自分では動かない

St. Peter氏は2011年に代理店Dirigo Creativeを立ち上げた。同氏はまず、「エージェント」という言葉を2つに分けて使う。

1つ目は、調査、SEO、執筆、編集、検証など17の役割を書いた定義ファイルだ。同氏はこれを「作業者ではなく指示書」と位置づける。役割が勝手に動き出すことはない。本人がClaude Codeで作業を始めると、Claudeが仕事に合う役割の指示書を読んで動く。

2つ目は、決まった時刻に人の手を離れて動く定期ジョブだ。本人の集計では10月12日時点で25本あり、ブログの執筆が10本、監視とまとめが9本、広告アカウントの点検が3本などとなっている。

AIの記憶は、ノートアプリのObsidianに置いた。作業のたびに「現状のメモ、索引、必要なページだけ」の順で読ませ、会話が毎回ゼロから始まるのを防ぐ。仕組みの全体は、Claude Code、役割の指示書、Obsidianのノート、作業と判断の記録、スケジューラーの5つでできている。

作ったAIとは別のAIが検査する

大きな仕事は、依頼、作業、下書き、レビュー、本人の判断の順に進む。要は、書くAIと検査するAIを分けることだ。検査役は下書きを作った会話を引き継がず、まっさらな状態のサブエージェント（親から呼び出される別のAI）として立ち上がる。同じ会話の中で役割の名前を変えただけでは、独立したレビューにならないという考え方だ。10月12日には、検査役のサブエージェントがWebサイトの改修を74件のリダイレクトと横スクロールの動きで確かめ、合格を出した。

同氏が事例のページに載せた集計では、10月12日までのレビューは120件あった。合格が80件、「一部合格」が30件、「不合格」が10件だった。作り直した下書きは新しい依頼として改めてレビューを受けるため、80件には作り直して通ったものも含まれうる。数字はいずれも本人の集計で、外部の検証はない。

ただし、レビューに合格しても公開してよいことにはならない。手順書には「どのレビューも公開の権限を与えない」とある。公開するかどうかは、レビューを通った下書きを見て本人が決める。例外は一部の定期ジョブで、本人が用意して補充するキューから、書面で決めた範囲の中だけ公開する。

自動の仕事は1か所で止められる

定期ジョブは、すべてスケジューラーの一覧に並べる。それ以外の場所に定期実行を置かないことで、何が動いているかを1か所で確かめ、止められるようにした。どのジョブも実行のたびに、何をしたか、本人に何が必要かを記録に残す。途中で止まった回も、黙って消えることはない。

ジョブごとに、できることの上限も決めている。広告の点検3本は読み取り専用で、うち1本は変更案を下書きとして出す。本人が承認するまで、広告アカウントには何も届かない。地域の店舗の一覧を保守するジョブは、閉店した店を消すことしかできない。

人との関係とお金も手放していない。ヘンプ（産業用大麻）製品の販売店82店のデータ作りはAIが手伝ったが、7人の記者への売り込みのメールは本人が1通ずつ送った。

失敗から学ぶが、広げすぎない

ルールの多くは失敗から生まれた。ブログを公開するジョブが、処理を終えた後に固まってタイムアウト扱いになったことがある。自動で再試行していれば同じ記事が2回公開されるところだったため、ブログのジョブは再試行を0回にした。作業メモが公開ページに紛れ込む事故も、1回の作業で3回起きた。気づけたのはスクリーンショットだけで、それ以来、読者と同じ見え方で公開ページを確かめてから作業を終える。公開した記事のグラフがWordPressの整形で消えたこともあり、今は公開のたびにスクリプトが実際のページを確かめる（事例のページによる）。

こうした教訓をルールにする手順が、この仕組みで最も慎重な部分だ。作業の終わりに「トレーナー」役のAIが、本人の指摘からルール案を書く。次に別のAIが、その案が本人の発言に基づいているか、発言より広げていないかを検査する。最後に本人が採否を決め、自動でルールになるものはない。

本人の集計では、10月12日時点でルール案は102件あり、採用は38件、却下は56件だった。却下のうち45件は、書き直して出し直す前の版だという。レビュー120件のうち不合格だった10件も、すべてこのルール案だった。

同氏は、この仕組みでどれだけ手間が減るかは「言えない」と書く。いちばんの負担は注意力で、どのジョブにも責任者が要り、指摘を書き残さなければ同じ失敗が戻ってくるという。始めるなら、毎週の投稿のように終わりがはっきりした仕事を1つ選び、レビューに何度か合格してから定期実行に載せるよう勧めている。AIが書き、別のAIが検査し、人が決める。この分担を崩さないことが、仕組み全体を支えている。

編集部の見方

編集部は、この事例で学ぶべき点は、成果物のレビューより「ルール案の審査」にあると見る。不合格の10件がすべてルール案だったことが、それを示している。記事の誤りはその1本で終わるが、広すぎるルールはその後の作業に効き続ける。CLAUDE.mdやスキルにAIの反省を書き足している読者は、その追記が元の指摘より広がっていないかを、書いたAIとは別の目で確かめるとよい。ただし、判断を本人1人に集める形は、9月29日から10月13日までに103件の判断を生んだ。人が増えた組織で同じ形を保てるかは分からない。