AIエージェントは増やすほど止まる
一人社長のための「役割・決定・検証」設計図

家事と子育てのスキマで経営する、三方よしAI共創コンサルタントの田中啓之、ひろくんです。

今日はブックマークの棚卸しをしていて、2つの記事が同時に目に留まりました。1つは、海外の開発者が公開した「役割ごとにモデルを使い分けるAIエージェントチーム」の設計記事。もう1つは、リクルートのエンジニアがカンファレンスで語った「AIで開発が速く安くなった後、何が起きるか」という組織論。どちらも私が最近ずっと考えている「AIハーネス（構造設計）」の話で、しかも私自身の失敗談ときれいに重なったので、今日はこの2つを縦に掘って、1本の設計図にまとめてみます。

同じ役割のAIを3体並べたら、仕事は3倍にならず矛盾が3倍になった

結論から言います。私は同じ役割のAIを3体並べて、仕事を速くするどころか、矛盾を3倍にしたことがあります。

これはAI経営術LIVEでも話したことがあるんですが、複数のAIに「同じ作業をやらせれば早く終わるだろう」と思って、似た役割のサブエージェントを並列で走らせたことがありました。結果は真逆でした。それぞれのAIが微妙に違う前提で判断してしまい、出力が食い違い、収拾がつかなくなる——いわば「メタ矛盾」に陥ったんです。頭数を増やしても、同じ仕事の人を3人横に並べただけでは、チームにはならない。むしろ確認作業が増えて、私自身の負荷が上がってしまいました。

この失敗は、以前「AIエージェントを”1体”で使うから仕組みにならない｜Kanban並列で組む経営者OS」という記事でも詳しく書きました。行き着いた答えはシンプルで、「異質な役割を明確に分担させ、指揮系統と可視化装置で束ねる」ことでした。今日紹介する2つの外部記事は、この私の失敗談を、もっと構造立てて裏付けてくれるものでした。

11役のAgent Team設計に学ぶ「誰が決め、誰が実行し、誰が疑うか」

1つ目の元ネタは、エンジニアのdiscus0434さんがZennで公開した「役割ごとにFableとGPT-5.6を使い分けるAgent Teamの設計」という記事です。

この記事の出発点も、私と同じでした。単一のAIエージェントに全部を任せると、コンテキストが肥大化し、自己レビューが甘くなり、途中で別の作業に割り込まれると文脈を見失う——だから、Lead（窓口）・Manager（進行管理）・Architect（設計）・Worker群（実装）・Reviewer群（検証）など、11の役割に責務を分散させたAIエージェントチームのテンプレートを作った、という内容です。

discus0434さんの記事より（要旨）

窓口役のLeadには対話力を重視してClaude系のモデルを、実装層には低コストなモデルを、レビュー層には別系統のモデルを配置する。フロントエンド画面のレビューには、より高性能なモデルを充てる。コストと能力のバランス（Pareto最適化）で、役割ごとにモデルを選ぶ。

出典: discus0434「役割ごとにFableとGPT-5.6を使い分けるAgent Teamの設計」（Zenn）

面白いのは、実例として紹介されている「zenn-manager」というCLIツールの開発で、調査から設計・実装まで42分で完走した、というくだりです。しかも「設計の穴が、実装される前に人間の目に届く」仕組みになっている。これ、私が普段ひろくん憲法で言っている「わからないなら止まれ」を、チーム構造として実装しているようなものです。役割を分けることの意味は、「速くなる」ことだけじゃなくて、「間違いが実装される前に人間に返ってくる」ことなんですよね。

「速くなった後」に何が詰まるのか——大企業のエンジニア組織論から

2つ目の元ネタは、リクルートの黒田樹さんがDevelopers Summit 2026 Summerで発表した「開発が速く安くなった後の話 AI時代のソフトウェアエンジニアリング組織論」という登壇資料です。

ここで語られているのは、「AIで実装コストが下がっても、検証・統合・運用・保守のボトルネックは別の工程に移動するだけ」という指摘です。生成AIの使い方を「協働型（コパイロット）」と「委託型（オーケストレーター）」の2つの流派に整理していて、組織設計の面では「フルスタック×フルプロセスで動く”フルフル人材”」「事前調整を減らす浅い階層化」「保守運用の負荷を集約するKTLOセンター」といった具体策まで踏み込んでいます。全体を貫く考え方は、制約理論（TOC）——プロセス・組織・アーキテクチャの三層で、ボトルネックに他の工程を従属させる設計が鍵だ、というものでした。

これ、私が最近感じていることそのものでした。以前「大きなループの中に、小さなループがある——鬼速PDCAとループエンジニアリングをつなぐ構造」という記事で書いたんですが、AIチームの最大のボトルネックは「AIの出力量が、人間の味見（レビュー）量を超えてしまうこと」でした。AIを増やせば増やすほど、人間側の確認作業が追いつかなくなる——これは黒田さんの「ボトルネックは移動するだけ」という指摘と、まったく同じ構造です。

比較：元ネタの設計図 と 私の実践

2つの記事を並べてみると、私が実際にやってきたことと、ほぼ同じ骨格をしていることがわかります。表にして比べてみました。

正直な現在地——3体並列の失敗を、次の分身AIレビューで防いだ話

ここは正直に書きます。役割分担の大事さに気づいたあとも、私は同じ失敗をゼロにはできていません。

以前「分身AIを並列化したら、別の分身AIに地雷を教えてもらった話｜分身AI日記 DAY48」という記事で書いたんですが、私が作業手順書を「順次処理」から「並行処理」に切り替えようとしたとき、自分ひとりの判断で進めず、別の分身AIにレビューを依頼したことがあります。すると、見た目は独立している2つの処理工程の間に、実は依存関係（後工程が前工程の出力ファイルを読む構造）があることが発覚しました。並行実行していたら、毎回「1日遅れのデータ」で動く致命的なバグを、本番に出す前に防げたんです。

この経験から、私は「並列化していいかどうか」を判断する3条件を持つようになりました。出力ファイルが独立しているか、入力データが独立しているか、外部サービス（API上限など）に余裕があるか。この3つが揃わないうちに並列化すると、今回紹介したAgent Team設計のような綺麗な役割分担どころか、また「メタ矛盾」を再現するだけになります。11役の完全なテンプレートを真似すること自体が目的になってはいけない、と自分に言い聞かせています。

これはエンジニアだけの話じゃない——一人社長にも同じ壁がある

ここまで読んで「専門的すぎる」と感じた方もいると思います。でも、この話は技術者だけのものじゃありません。

入院中に配信業務を仲間に委ねた経験を「DXOをAIエージェントチームに導入。思想は効かず、仕組みだけが効いた」という記事に書いたことがあります。そこで気づいたのは、人間には「思想」（心理的安全性・主体性）が効くけれど、AIには「仕組み」（情報の流れ・決定権の設計）のほうが強く効く、という非対称性でした。同じ「役割分担しよう」という言葉でも、人間チームとAIチームでは効き方がまるで違うんです。

一人社長やスタッフの少ない会社にとって、この話の要点はシンプルです。「調査〜実装42分で完走した」という数字は、エンジニアの自慢話じゃなくて、「秘書に指示を分けたら仕事が42分で終わった」という感覚に近い。AIを何体使うかより、誰に何を決めさせ、誰に何を疑わせるか——この設計だけが、事業のスピードを本当に変えます。

今日から始められる3ステップ——完コピしない設計図

Zenn記事の11役割をそのまま真似することは、私はおすすめしません。まずは最小構成から始めるのが現実的です。

この3役ができたら、次に足すべきは「役割を増やすこと」ではなく「実装後に移動したボトルネックを測ること」です。人間の確認作業がどこで詰まっているかを見つけて、そこにだけ役割を足していく。順番を間違えると、黒田さんの資料が指摘していた通り、ボトルネックが移動するだけで解決しません。

私自身も「ハーネスエンジニアリングとは？知らずにAI憲法を作っていた私の話｜分身AI日記 DAY35」で書いた通り、最初から「ハーネスエンジニアリング」という言葉を知っていたわけではありません。がんの手術で入院していたとき、「自分がいなくても止まらない仕組み」が必要だと痛感して、チーム全体でAI憲法を起草したのが始まりでした。専門用語を先に覚える必要はなくて、目の前で困っていることから逆算して、役割を分けていけばいいんです。