AIを5役に分けるのをやめた。捨てたのではなく、使う場面を絞った

きっかけ

2026-08-31に、AIの作業を5つの役に分ける進め方を正式なやり方として決めた。その8日後の2026-09-08に、通常の作業は1体のAIで進めることを既定にする、という別の決定を入れている。

8日で方針が裏返ったように見えるが、前の決定は取り消していない。5つの役の定義はそのまま残っていて、いまも条件を満たしたときには起動する。変えたのは「毎回それを起動するか」だけだった。

5役に分けていたのは、作る役と確かめる役を同じAIにやらせないためだ。実装した本人に合否を決めさせると、判定が甘くなる。

引っかかったのは、記事を1本作るのに5つの役を順番に起動していると、記事本体より段取りのほうが長く感じる場面が増えてきたことだった。計画役が書いた方針を実装役が読み、実装役が作ったものを検証役が読み、検証役の結果をレビュー役が読む。そのたびに同じ前提を最初から読み直す。

同じ時期に、単体で長い工程を最後まで抱えられるモデルが使えるようになっていた。以前は、1体に企画から検証まで通してやらせると途中で前提を見失うことがあり、それも役を分ける理由の一つだった。その前提が変わったなら、分け方も見直せるはずだった。

5役の価値は「役を分けたこと」そのものではなく、「作る役と確かめる役を独立させたこと」にあるはずだった。だとすれば、独立性が要らない規模の作業では、役を減らしても品質は落ちない。減らした分だけ、受け渡しのコストが消える。

先に断っておくと、5役と1体で同じ記事を作ったときの所要時間・使用量・品質の差は、同じ条件で比べていない。ここに書くのは、運用を変えた理由と、変えたあとに実際に起きたことだけになる。

やったこと

手順は4つ。

1. 5役で記事7本を作り切る。 2026-08-24から09-03までの期間に、企画・本文・図の実装・表示確認・レビューを役ごとに分けて回した。
2. 役を分けたことが実際に効いた場面を記録する。 「分けたから見つかった」と言える指摘だけを数え、分けなくても気づいたはずのものは数えない。
3. 通常の作業を1体へ戻す。 2026-09-08に決定として記録し、以降の作業に適用した。5つの役の定義は消さず、起動条件だけを変えた。
4. 戻したあとに何が起きたかを見る。 下書きの本数、止まった場所、止まった理由を記録する。

5役で作った期間

記事7本はすべて公開まで到達した。役を分けたことが直接効いた場面は、記録に残っている範囲で3件ある。

記事	分けたことで出た指摘	対応
記事4	図の初版が説明イラストではなく模式図に寄っている、とまとめ役が判断	差し戻して作り直し
記事5	まだ終わっていない人間の目視確認の結果を、本文が先取りして断定していた	該当箇所を是正
記事7	本文の言い回しが、前の記事と同じ型の対句になっている	1文を差し替え

どれも、作った本人が読み返して気づくのは難しい種類の指摘だった。記事5の「まだ出ていない結果を断定している」は特にそうで、書いた側には通ったつもりの文になっている。

1体へ戻したあとの期間

1体での運用に切り替えたあと、2026-09-13に、まとまった作業1回から記事の下書きが5本出た。5役で7本に11日かかっていたことと比べると、下書きに届く速さははっきり変わった。

ただし、この5本はいまも下書きのままで公開されていない。止まっているのはAIの作業ではなく、人間がブラウザで実ページを見る確認のほうだった。

• 常用していたころ

  段取りに時間を取られていた

  記事1本ごとに役の受け渡しが要り、作業の中身より段取りのほうが時間を使う。そのかわり公開までは一直線で進んだ

• 1体へ戻したあと

  人間の確認待ちで詰まるようになった

  下書きは短時間で複数出るようになったが、目視確認の順番待ちが溜まる。詰まる場所がAI側から人間側へ移った

わかったこと

5役の本体は「5つに分けること」ではなく「作る役と確かめる役が独立していること」だった。独立性は作業の規模と関係なく効く。ただ、役の数に比例して増える受け渡しのコストは、作業が小さいほど相対的に重くなる。だから小さい作業では、独立性の要る場面だけ残して役の数を削れる。

問いの立て方も違っていた。5役が正しかったか間違っていたかではなく、どの規模の作業に対して割に合うかのほうだった。記事1本の制作は、当時のやり方では十分に大きい作業で、受け渡しのコストを払っても独立した確認の価値のほうが大きかった。割に合わなくなったのは、作業の側が小さくなったからでもあり、1体が抱えられる工程が長くなったからでもある。

いまの使い分けはこうなっている。

作業の大きさ	いまの進め方
数行の修正・元に戻せる文書の更新	1体で完結させる
複数のファイルや画面にまたがる変更	実装と検証を分ける
重要な設計変更・外部公開の前・失敗コストが高い変更	5役を起動する

普段から動かしておく設備ではなく、必要なときだけ立ち上げる大型の設備として残した。

予想外だったのは、速くなった結果として、詰まる場所が人間側へ移ったことだった。下書きは短時間で増えるが、それを見て公開してよいと判断するのは人間のままだ。AI側の段取りを軽くしたぶん、順番待ちの列が人間の前にできた。ここは今のところ解けていない。

弱いところもある。モデル側が強くなったことと運用を変えたことが同時に起きているので、どちらがどれだけ効いたのかを分離できていない。1体で量産した下書き5本がまだ公開に至っていないので、「1体でも公開品質に届く」とはまだ言えない。届かないとも言えない。止まっているのが人間の確認待ちだからだ。

ここまでが、1人・約1か月の運用で見たことだ。