一人の開発者が5役のAIを回す　「完了」は報告でなく状態で確かめる

AIエージェントに仕事を任せると、「終わりました」という報告が本当かどうかを誰が確かめるのかが問題になる。昼は学校の校長、夜は開発者のRehman Ahmad Chaudhry氏は、10月21日付の自分のブログで、5つの役割に分けたAIエージェントと定時の作業で、2つのサイトとコンテンツの自動生成を一人で回す方法を書いた。軸にあるのは、作った側の「完了」の報告を信じず、別の役が実際の状態を読み直して確かめるという決まりだ。

役割を5つに固定する

Chaudhry氏は5つの役割でエージェントを回す方法を書いたブログの記事で、役割を調整役・バックエンド・フロントエンド・デザイナー・QA（品質の確認役）の5つに固定していると説明した。調整役は「コードには触らず、管理だけをする」。計画を持つ役と、手を動かす役を分けているわけだ。同氏はその理由を、自分が書くコードの計画まで立てるエージェントは、コードが難しくなると計画を黙って変えがちだからと説明している。調整役を管理だけに絞ることで、計画が書き手の都合で変わるのを避けている。

バックエンドの役には、作業指示書の文書を先に守るという決まりがある。何を作るかを決めた文書が先にあり、エージェントはそれに従って動く。役割ごとに受け持ちと決まりが違うので、どこで何が起きたかを役割の単位で追える形になっている。

同じ記事は、10月22日に開発者向けの投稿サイトDEV Communityにも同じ内容で転載された。

「完了」は状態を読み直して確かめる

Chaudhry氏の決まりの中心は、「完了」を作った側の報告で決めないことだ。実際の状態を読み直して確かめる。きっかけとして挙げたのは、APIが「push成功」と返したのに、commitが手元にしか無かった件だった。報告は成功を言っていたが、リモートの側には何も届いていなかった。

同じ考え方は役割ごとの決まりにも入っている。フロントエンドは画面を実際に見てから完了とする。QAは、作った側の「テストは緑」という報告を信じず、全部のテストを自分で流し直す。ある時、作った側は単体テストだけを流して緑と報告していたが、その裏で統合テストが58件落ちていた。テストが通ったという報告が、どのテストを指すのかまで確かめないと、こうした食い違いは見逃される。push、画面、テストと場面は違っても、3つの例に共通するのは、報告の言葉ではなく、リモートの中身や実際の画面、全部のテストの結果という状態を見て完了を決める点だ。

10月28日付の検証を軸にした作業の流れを書いた記事で、Chaudhry氏はこれを「エージェントが報告するのは完了であって、真実ではない」と言い切った。

作る役と見直す役を別のモデルに分ける

確かめる役を分けるのは、エージェントの役割の中だけではない。DEV Communityの記事によると、Chaudhry氏は使うモデルも作り手と見直す側で分けている。日々の運用はClaudeが受け持ち、コードの方向づけとレビューはChatGPTとCodexが受け持つ。両者の食い違いはGitHubのissueに残し、解決するまで追う。

Chaudhry氏はこの分け方を「どれも自分の宿題を自分で承認しない」と表した。作ったモデルが自分の成果を合格にする形を、仕組みの上で作らないということだ。食い違いをissueという目に見える場所に置くことで、どこで意見が割れ、どう決着したかが後から読める。

公開と設定は人が決める

コンテンツの側では、定時の作業（cron）が下書きまでを作り、公開はChaudhry氏が文面を承認してからになる。同氏は「承認の関門が契約」と書き、理由を「自分の名前が付くから」と述べた。

任せない範囲も決めている。プロフィール・プライバシー・tokenなどのアカウントの設定は、明示の承認なしにエージェントに触らせない。有料のサービスをエージェントが勝手に有効にすることも禁じている。

出荷の前の確認は6つに絞った。リモートの実際の状態、全部のテスト、変更が頼んだ範囲に収まっているか、人が自分の目で読んだか、元に戻せるか、ログに記録したか、の6つだ。同氏は「提案するのはエージェント、決めるのは自分」とも書いている。5つの役割の記事の末尾には、その記事自体も同じ定時の仕組みで作られ、人が確認してから公開したと書かれている。下書きまでは任せ、外に出す判断だけを手元に残す線引きを、記事そのもので示した形だ。

重複を防ぎ、長い指示書で任せる

並べて動かすエージェントは、同じ仕事を2度しがちだ。DEV Communityの記事によると、Chaudhry氏は題材のログ、枠のログ、既出のリストを持ち、全ての実行の前に照合させている。

指示の書き方にも触れている。同氏が「契約」と呼ぶ長い指示書を書けば、数時間エージェントを放っておけるという。1行の指示で動かすのではなく、何を作り、何を守り、何で完了を示すかまで先に書いておく考え方だ。

なお、記事に出る数字や成果は、どれも本人の申告で、第三者の裏付けはページに無い。こうして見ると、Chaudhry氏の仕組みは、作った側の報告を完了の根拠にせず、別の役が状態を読み直すことで回っている。

編集部の見方

取り入れるかは別として、まず理解するなら、「完了」の報告を信じずに実際の状態を読み直す確認を、作った側とは別の役が受け持つ分け方を見てみるといいかもしれない。Claude CodeやCodexで定時の仕事を回しているなら、リモートの中身を取り直す確認や、全部のテストを別に流す確認を、どの役に持たせるかを書き出す手がかりになる。