AIに企画・実装・確認を分担させてみた。効いたのは分担そのものではなかった

ひとつのAI環境の中で、企画する係・実装する係・確認する係を分けた。役割を分ければ成果物の品質が上がるはずだ、という想定だった。

2回運用してみて、品質の底上げには効いた。ただ、効いた理由は「役割を細かく分けたこと」そのものではなかった。効いたのは、そのうちのたった一点、「実装した本人に、できたかどうかを判定させない」という部分だった。

きっかけ・仮説

AIに作業を任せていると、同じ相手が「作る」も「これで合っているか確かめる」も担当することになる。すると、自分で作ったものを自分で「できました」と判定する形になり、抜けや思い込みがそのまま残りやすい。

そこで、ひとつのAI環境の中に5つの係を置いた。全体を回す「まとめ役」と、その下に「計画役」「実装役」「検証役」「確認役」の4つだ。

5つの係の関係。まとめ役が上、4つの係はその下で対等に置く

まとめ役全体を回す。工程の割り振りと、最後に完了かどうかを決める役。自分では作らない

計画役やることと「これができたら完了」の条件を決める
実装役計画に沿って手を動かす
検証役実装役とは別に、動作と完了条件を確かめ直す
確認役最初の要求と成果物がズレていないかを見る

まとめ役は「5人目の作業役」ではなく、他の4つの係に仕事を渡して回す役。実装役は、自分の成果物の合否を自分では決めない。

ポイントは、まとめ役を「もう1人の作業者」にしないことだ。まとめ役は手を動かさず、渡す・受け取る・次へ回すことに徹する。実装役は、自分が作ったものを「できました」で終わらせられない。合否は必ず別の係が判断する。

仮説は「役割を分けるほど品質が上がる」。

やったこと（検証方法）

5つの係を、次の6ステップの流れで動かした。

依頼何を作りたい・確かめたいかを、まとめ役に渡す
計画計画役が、やることと「これができたら完了」の条件を書き出す
実装実装役が計画に沿って作る
独立検証検証役が、実装役の申告とは関係なく、完了条件を自分で確かめ直す
確認確認役が、最初の要求と成果物がズレていないかを第三者の視点で見る
完了判定まとめ役が、ここまでの結果を見て完了かどうかを決める

この流れを、性質の違う2つの作業で回した。

1回目は、ある説明文の古くなった状態記述を現状に合わせる小さな修正。2回目は、この記事そのものの制作で、文章の構成・図・根拠の整理をこの流れに乗せた。

5工程フローを2回まわした記録の再構成図。1回目・2回目それぞれで、完了条件を文章化する工程が独立した記録になっている — 5工程フローを実際に2回まわしたときのコミット履歴を、社内の識別子を除いて再構成したもの（実画面のスクリーンショットではない）。上が1回目（ある説明文の状態記述を現状に合わせる小さな修正）、下が2回目（この記事の制作）。見てほしいのは1回目——本文側の修正はごくわずか（数行）なのに、その前に「これができたら完了」という条件を約100行の別の記録として書き出している。小さい作業ほどこの手順が重くなる、という後述の結果は、この手順のことを指している。

品質を測る数値指標は用意していない。成果物にどんな差が出たか、手間はどう変わったかを、その場で見て記録した。

起きたこと（検証結果）

1回目・小さな修正
完了条件が作業より大きくなった

直す量はわずかなのに、完了条件を文章で書き出す手間のほうが本体を上回った
2回目・記事制作
自己申告だけでは通らなかった

実装役が「できた」と言った後、検証役と確認役が別の根拠で見直し、直しが入った

1回目の小さな修正では、流れは最後まで回ったものの、完了条件を書き出す工程が明らかに過剰だった。直す行数より、完了条件を説明する文章のほうが長い。

2回目の記事制作では、実装役が「ひととおりできた」と申告した。そのあと検証役が完了条件を1つずつ自分で確かめ直し、確認役が最初の依頼内容と照らし合わせた。実装役の申告だけでは見えていなかったズレが出てきて、修正に戻った。作ったものが破綻していたわけではない。作った本人の「できた」だけでは完了にならない構造が、実際に機能した。

2回目の独立検証の記録の再構成図。実装役の自己申告、検証役によるビルド・差分の確認と独立PASS、確認役による差し戻し — 2回目の記事制作で、実装役の「できた」という申告のあと、別の役が成果物そのものを確かめ直したときの記録を、社内の識別子を除いて再構成したもの（実画面のスクリーンショットではない）。検証役は実装役の言葉を使わず、ビルドが通るか・下書きから何が変わったか・調べた知識が実装に入っているかを自分で当たり直して独立に PASS を出し、そのあと確認役が最初の依頼と照らして、実装役の申告では見えていなかった点を指摘して差し戻した。ビルドの成否・変更ファイル数・PASS と差し戻しの有無は実際の結果。

わかったこと

効いた
合否を本人に決めさせない

作った係とは別の係が判定する。この一点が品質の底上げにつながった
効きにくい
分担の細かさ・反復回数の固定

係を細かく割ること自体や、やり直し回数を固定ルールにすることの効果は薄かった

2回動かして見えたのは、品質に効いたのが「役割を細かく分けたこと」ではなく、「実装した本人に合否を判定させない」という一点だったことだ。作る人と、できたと判断する人を分ける。そこだけで、抜けや思い込みが後工程で拾われるようになった。

逆に、係をどこまで細かく割るか、やり直しを何回までにするかといった部分は、成果への影響が小さかった。やり直し回数はむしろ固定ルールにしないほうがよく、作業の内容に応じて決めるのが合っていた。

そして、この流れは小さい作業には重い。完了条件をきちんと書き出す工程は、ある程度以上の大きさの作業でないと割に合わない。

この記事は「AIに役割を持たせて動かせばうまくいく」という話ではない。役割の分け方のうち、どこが効いてどこが無駄だったかを、実際に回して見分けた記録だ。

実際どうなん？（まとめ）

速度は上がらない。工程が増えるぶん、むしろ遅くなる。小さい修正では、完了条件を用意する手間が作業本体を超えた。向いているのは、大きめの作業や、間違えると影響が大きい作業だ。

今回の答えは「品質の底上げには効いたが、速くはならない。小さい作業ではむしろ重い」。役割分担は、全部の作業に一律で使う道具ではなく、作業の大きさとリスクを見て使い分けるものだった。

補足・注記

この記事で扱ったのは、ひとつのAI環境の中で役割を分担する取り組みだけだ。複数のAI環境をまたいで情報を共有する仕組みについては、別の記事で扱っている。

検証はひとつのAI環境の中の役割分担に限っていて、複数のAIサービスやツールを比較したものではない。動かしたのは数日間、運用は2回、作業者は1人。品質は数値で測っておらず、長期間運用したときの結果も見ていない。ここに書いたのは、その範囲で確認できたことだけだ。