AI エージェントを 1 体動かしてみた会社が、次に突き当たる問いがあります。「1 体で足りるのか。複数にすべきなのか。分けるなら、何で分けるのか」。製品の説明にも「マルチエージェント」の語が並ぶようになり、複数にすればもっと賢く、もっと大きな仕事ができる、という印象が先に立ちます。私たちは AI エージェントの開発と導入支援を行う会社で、自社の日常業務を司令塔 1 体と担当十数体の構成で毎日回していますが、先に結論を書きます。複数にしても、AI は賢くなりません。1 体ずつの頭脳は同じです。それでも分けるのは、1 体では持てない「独立性」を作るためです。作った本人には持てない疑う目、権限を体ごとに付けることで生まれる止まる場所、長い実務に戦略の判断を混ぜない汚れない文脈、1 つのモデルや経路に全部を載せない止まらない可用性 ── この 4 つは、どれほど賢い 1 体にも設計では持たせられません。この記事では、マルチエージェントの定義と語の幅、1 体に全部やらせない 4 つの理由、分ける線を役割・権限・文脈・モデルの 4 つに整理した設計、自社の構成(書く側と検品を同じモデルに載せていて止まりかけた経験を含む)、分けて失敗する 3 つの型、明日から 2 体で始める最小構成までを、設計の順番で書きます。
- マルチエージェントとは、複数の AI エージェントが役割を分けて 1 つの仕事を進める仕組み。複数にしても 1 体ずつの賢さは上がらない ── 変わるのは頭脳ではなく働き方
- 分ける理由は 1 体では持てない 4 つの独立性 ── 疑う目・止まる場所・汚れない文脈・止まらない可用性。どれも「賢さ」では代わりにならない
- 分ける線は 4 つ ── 役割・権限・文脈・モデル。最初に引く 1 本は「作る側と通す側を同じ頭にしない」
- 分ける理由を 1 行で言えない分割はしない。体の数だけ手順書と運用が増える。2 体から始め、3 体目は理由を書けたときだけ足す
マルチエージェントとは ── 複数のAIエージェントが役割を分けて、1つの仕事を進める仕組み
土台の言葉を 1 文だけ置きます。AI エージェントとは、目的を与えると必要な手順を自分で組み立てて実行し、結果まで進める AI のことです。1 体のエージェントの仕組みや「答える AI」との違いは「AIエージェントとは」にまとめているので、ここでは繰り返しません。その記事の中で「複数の AI が役割分担して大きな仕事をこなす仕組みを指すこともあります」と 1 文だけ触れた形が、この記事の主題です。マルチエージェントとは、複数の AI エージェントがそれぞれ役割を持ち、受け渡しをしながら 1 つの仕事を進める仕組みのことを指します。
この語には幅があるので、先に切り分けておきます。研究の分野で「マルチエージェント」と言うと、多数の主体が相互に作用する様子を模擬する手法や、複数の学習主体を同時に訓練する手法を指すことが多く、検索の隣に並ぶ語にもその意味のものが混じっています。この記事が扱うのはそちらではなく、業務で AI エージェントを使う側が、仕事をどう複数の体に分けるかという設計の話です。もう 1 つ、「オーケストレーション」という語もよく並びます。これは、どの体に何を振り分け、結果を誰が受け取り、どこへ戻すかを束ねる仕組みのことで、この記事ではその役を司令塔と呼びます。司令塔は AI であることも、最初のうちは人であることもあります。
そして、いちばん多い誤解をここで片づけます。「複数にすれば賢くなる」── これは成り立ちません。同じモデルを 3 体並べても、1 体ずつの推論の力は 1 体のときと同じです。違うモデルを混ぜても、いちばん賢い 1 体より賢い体は生まれません。マルチエージェントで変わるのは頭脳ではなく、働き方です。1 体では構造的に持てないものを、分けることで作る。それが何なのかを、次のセクションで 4 つに分けて書きます。
なぜ1体に全部やらせないのか ── 1体では持てない4つの独立性
1 体のエージェントに手順書を厚くしていけば、たいていの仕事は 1 体で進められます。それでも私たちが分けているのは、次の 4 つが「1 体の賢さをいくら上げても手に入らないもの」だからです。
- ①疑う目。作った本人は、自分の成果を疑えません。人も AI も同じで、AI の場合はさらに、自分の出力の直後に「確認して」と頼まれると、同じ前提のまま確認するので、前提の誤りはそのまま通り抜けます。コードを書いた AI に同じ会話の続きでテストを書かせると、仕様の読み違いがそのままテストに写って両方が緑になる、という形を「ソフトウェアテストのAI活用」に書きました。前提そのものの誤りは、作った側とは別の目にしか見えない ── 「AIエージェントの評価」でも、評価の 3 層のうち最も効いているのがこの 1 点だと書いています。別の目は、別の体でしか作れません。
- ②止まる場所。権限は、会話ではなく体に付きます。1 体に読む・書く・送る・消すの全部を持たせると、どの仕事の途中でも全部ができてしまい、誤った判断が止まらずに実行まで届きます。読むだけの体、社内に書くだけの体、外へ出す操作は持たない体、と分けておくと、誤りが起きても「その体には権限が無い」という場所で止まります。独立性とは、事故の「有無」を消すことではなく、事故が通る「経路」を減らすことです。
- ③汚れない文脈。1 つの会話に、調べものの結果も、長い実務の途中経過も、会社の方針の判断も全部入れていくと、判断が濁ります。長い作業の末尾で「この案件を受けるべきか」を問われた AI は、直前まで読んでいた作業の都合に引きずられます。判断が要る仕事を独立した文脈に置き、実務の文脈と混ぜないことは、賢さではなく分け方でしか守れません。
- ④止まらない可用性。1 つのモデル、1 つの経路に全部を載せると、そのモデルの利用上限に当たった日、その経路が止まった日に、全部が一緒に止まります。書く体と検品する体を別のモデルに載せておけば、「今日は書けないが、書けたものは通せる」という状態が残ります。これは独立性の中でいちばん地味で、止まった日に初めて効きます。
人のチームに置き換えると、4 つとも当たり前のことです。実装した人とテストする人を分ける、新任の担当者に送金の権限を渡さない、現場の作業中に経営判断を求めない、1 人が休んだら全部が止まる体制にしない。AI エージェントでも同じで、分ける理由は「賢さ」の側にはなく、「独立性」の側にある。この 4 つのどれを作りたいのかが言えない分割は、後のセクションで書くとおり、ただの複雑さになります。
分ける線は4つ ── 役割・権限・文脈・モデル
分ける理由が 4 つの独立性なら、分ける線もそれに対応して 4 つあります。どの線で分けると、どの独立性が手に入り、分けすぎると何が起きるか。先に表にします。
| 線 | 何を分けるか | 得られる独立性 | 分けすぎると起きること |
|---|---|---|---|
| 01 役割 | 作る・疑う・調べる・突き合わせる、など仕事の種類 | ① 疑う目 | 体の数だけ手順書と運用が増え、誰が何を決めたか追えなくなる |
| 02 権限 | 読める範囲・書ける場所・呼べる道具 | ② 止まる場所 | 権限が足りずに毎回人に戻ってきて、任せた意味が消える |
| 03 文脈 | 独立した判断が要るか、手順の中で済むか | ③ 汚れない文脈 | 受け渡しのたびに前提を書き直す手間が増え、情報が落ちる |
| 04 モデル | 人の心に響く・深い判断 / 実装・突合・検品 | ④ 止まらない可用性 | 体ごとに癖が違い、同じ手順書でも出力の形がそろわない |
役割の線は、仕事の種類で引きます。作る・疑う・調べる・突き合わせる・取り込む・集計する。このうち最初に引くべき 1 本が、作る側と通す側を分ける線です。疑う役は、作る役とは別の会話で、作る役の説明を読まずに、成果物と仕様だけを見て、通すか止めるかを返す。これだけで独立性 ① が手に入ります。役割の線は増やしやすいので、2 本目以降は「その役を分けると、どの独立性が増えるか」を 1 行で言えたときだけ引きます。
権限の線は、役割の線と重ねて引きます。疑う役は読み取り専用にして、直す権限を持たせない。外部から取り込む役は読むだけで、返信も削除もできない。無人で動く役は、隔離された置き場にしか書けない。権限を会話の指示(「書き換えないでください」)ではなく仕組みの側で付ける考え方と、読む・書く・動かすの 3 層の作り方は「AIエージェントのセキュリティ」に書きました。マルチエージェントで足すのは、その 3 層が体ごとに別々に付くという 1 点です。1 体のときは「この仕事では書かない」と手順で縛るしかなかったものが、分けると「この体は書けない」になります。
文脈の線は、いちばん迷う線です。私たちが使っている判定の問いは 1 つで、「司令塔の文脈を汚さずに済むか」。独立した文脈で判断が要るもの(レビュー・調査・執筆)は別の体に出し、手順が決まっていて司令塔の文脈の中で実行したいもの(定型の取り込み・集計)は、体を分けずに手順として司令塔が実行します。体を分けると、結果だけが司令塔に戻り、途中の長い作業は司令塔の会話に残りません。これが独立性 ③ の正体で、司令塔が判断に使う文脈を、実務の途中経過で埋めないための線です。
モデルの線は 2 つの意味で引きます。1 つは費用と質の線で、人の心に響く文章を書く役と、設計の深い判断をする役には上位のモデルを使い、実装・突合・取り込み・検品には上位を使わない。全部を上位に載せると、夜間の自動処理まで上位の利用枠を食います。もう 1 つは可用性の線で、書く役と検品する役を同じモデルに載せない。同じモデルに載せると、上限に当たった日に書く側と通す側が一緒に止まり、その日の鎖が丸ごと止まります。モデルの線は独立性 ④ のためのもので、「どのモデルが賢いか」ではなく「どれが止まっても全部は止まらないか」で引きます。
自社の運用 ── 司令塔1つと担当十数体を、どう分けているか
ここからは、私たちが自社で回している形を、一般化して書きます。構成は司令塔 1 体と、領域ごとの担当が十数体。コラムの執筆、コラムの独立レビュー、提案書の骨子、メールの取り込み、議事録の要約、帳簿の突合、経営指標の導出、システムの実装、実装の独立レビュー、といった役が、それぞれ別の体として定義されています。司令塔が何を誰に任せているかは、領域・担当・状態の一覧を 1 枚で持ち、任せた仕事が今どの状態にあるかを見える形にしています。その見える化の設計は「AIエージェントの管理」に書いたので、ここでは分け方の側だけ書きます。
1 つ目の線は、司令塔は実務を持たない、です。司令塔の仕事は、方針の判断、人との対話、全体の整合の確認に絞っています。作る仕事 ── 記事を書く、仕組みを実装する、資料を大量に生成する ── は司令塔が自分でやらず、該当する担当に出します。ここで決めているのが、「自分でやった方が速い」を例外の理由にしない、という規律です。司令塔が自分で書き始めると、司令塔の文脈が実務で肥大し、しかも「書いた本人しか見ていない成果物」が増えます。引き継げず、レビューも通らない。速いことは、司令塔が実務を持つ理由になりません。司令塔が直接書いてよいのは、数行で終わる即応だけです。
2 つ目の線は、担当ごとに定義ファイルを持ち、実行するモデルを固定する、です。私たちはこの構成を Claude Code の上で組んでいて、担当ごとの定義ファイルで、その担当が使うモデルを固定できます。執筆の担当には上位のモデル、実装・突合・検品の担当にはそれ以外、という割当です。そのうえで執筆の担当には、仕事の最初に 1 つの関門を置いています。ファイルを 1 つも読む前に自分の実行モデルを確かめ、想定のモデルでなければ、何も読まず、何も書かず、1 行の報告だけ残して中断する。上位のモデルの利用上限に当たった日に、別のモデルで書かれた記事が「できあがった顔」で承認の列に乗ると、水準を割ったものがそのまま公開まで通る経路ができるからです。待つ代償より、水準を割ったものが流れる代償のほうが高い。関門は「書けない日は書かない」を仕組みにしたものです。
3 つ目の線は、正直に書くと、一度踏み外しかけた線です。コラムの鎖は、書く担当が書き、独立レビューの担当が検品し、機械の条件と合わせて承認に進む、という形です。ある日、上位のモデルの上限に当たり、書く担当と、実装の独立レビューの担当が同時に止まりました。そのとき、コラムの独立レビューの担当も同じ上位のモデルで定義してしまっていたことに気づきました。そのままなら、書く・検品する・承認する、の鎖が 1 つのモデルに丸ごと依存していたことになります。同じ日に、検品の担当を別のモデルへ移しました。モデルを分けるのは「書く側と通す側を別の頭にする」独立性のためだと思っていましたが、可用性の分離でもある、と気づいたのはこの日です。今は、書く側が止まった日でも、書けたものは通せます。
4 つ目の線は、疑う役は読み取り専用で、直さず、通すか止めるかだけを返す、です。コラムの独立レビューの担当は、書く担当とは別の文脈で、ドラフトとブリーフだけを初見で読み、通す・止める・人が読むべき、の 3 つのどれかを返します。修正も承認もしません。「よく書けている」と感じたら、その感覚こそ疑うように、定義に書いてあります。この担当の判定を、機械の条件(画像の実在・リンクの検証・需要の記録・効果数値の有無・禁止語・製品の範囲)と合わせて承認の判定に使い、承認からは人の判子を外しました。代わりに人が持っているのは、公開までの止める窓です。承認された記事は朝の報告に 1 行並び、人は窓の間に止める権利を持ち、何もしなければ出ます。止める窓を持てるのは、書く側と通す側が別の頭で、通す側が直す権限を持たない、という分け方があるからです。
5 つ目の線は、委譲しても必ず司令塔と人に戻すものを先に決めている、です。戦略の判断、お金の支出、外への送信、人に関する判断の 4 つは、どの担当にも完結させません。担当は下書きと判断材料まで作り、最後の一手は司令塔を経て人に届きます。無人で動く担当は、隔離された置き場にしか書けないよう、書き出し先を環境の側で物理的に縛っています。「書かないでください」ではなく「書けない」。それと、担当ごとに手順書と「作法」の記録を持ち、司令塔が委譲するときはその作法を指示に添え、担当は読んだら報告に 1 行入れる、という決まりにしています。読んだかどうかが外から見えないと、読み飛ばしても成果物は普通に出てくるからです。手順書に判断の基準や禁止事項をどう書くかは「AIに渡す手順書の書き方」に、動かした後に「動いていること」をどう確かめるかは「AIエージェントの運用」に書きました。
マルチエージェントで失敗する3つの型
分けることには代償があります。分けて失敗する形を、私たちが自分の構成で線として守っている順に 3 つ書きます。どれも AI の性能の問題ではなく、線の引き方の問題です。
役割の線は引きやすいので、「調べる担当」「まとめる担当」「整える担当」と、仕事の工程ごとに体を増やしたくなります。体が増えると図は立派に見えますが、独立性は 1 つも増えていません。増えるのは、体の数だけの手順書・作法・上限の運用と、どの体が何を決めたかを追う手間です。打ち手は 1 つで、分ける前に「この分割で増える独立性はどれか」を 1 行で書くこと。4 つのどれでもなければ、分けずに、1 体の手順書を厚くするほうを選びます。
担当 A の出力を担当 B が直接受け取り、B の出力を C が受け取る、という鎖を組むと、速く回りますが、途中で誰かが判断を変えたとき、どこで変わったかを誰も見ていません。私たちは、受け渡しを司令塔の 1 か所に通しています。担当は結果を司令塔に戻し、司令塔が次の担当に渡す。遅くなりますが、「どの体が何を決めたか」が司令塔の記録に全部残ります。オーケストレーションを 1 か所に置くのは、速さのためではなく、追えるようにするためです。
疑う役を別の体にしても、作る役が書いた「こういう意図でこう作りました」という説明を一緒に渡すと、疑う役はその前提を共有してしまい、別の頭ではなくなります。体は 2 つでも、頭は 1 つです。疑う役に渡すのは、成果物と仕様だけ。作る役の説明は読ませません。実装の担当とレビューの担当を分けて、レビュー側は読み取り専用で通すか止めるかだけを返す形は「AIエージェントの開発」にも書きました。分けた後に、何を渡さないかまでが、役割の線です。
明日から始める最小構成 ── 2体から
最後に、明日から始められる最小構成を、手順 4 つで書きます。新しい道具を入れる必要はありません。1 体のエージェントが 1 つの業務で動いていることが前提で、その手前の、最初の 1 業務の選び方は後ろで預けます。
手順 1: 「作る」と「疑う」に分ける
今動いている 1 体を「作る役」とし、別の会話で「疑う役」を立てます。疑う役に渡すのは、作る役の成果物と、作る役に渡したのと同じ仕様(手順書)だけ。作る役の会話の履歴や説明は渡しません。疑う役の仕事は、仕様に照らして成果物を読み、通すか止めるかと、その理由を返すことです。これが役割の線の最初の 1 本で、独立性 ① がここで手に入ります。
手順 2: 疑う側を読み取り専用にし、直させない
疑う役には、成果物を書き換える権限を持たせません。指摘だけを返させ、直すのは作る役です。疑う役が直し始めると、次の瞬間からその体は「作る役」になり、自分の直しを疑えなくなります。権限の線をここで引くと、独立性 ② も同時に手に入ります。手順書の 1 行(「直さず、指摘だけ返す」)で始めて構いませんが、仕組みで書けなくできる環境なら、そちらにしてください。
手順 3: 司令塔を 1 つ置き、体同士を直接つながない
作る役の成果物を疑う役へ渡し、疑う役の指摘を作る役へ戻すのは、司令塔の仕事です。最初の司令塔は人で構いません。あなたが成果物を受け取り、疑う役に渡し、指摘を作る役に戻す。これだけで、受け渡しが 1 か所を通り、どの体が何を決めたかがあなたの手元に残ります。司令塔を AI にするのは、この往復の形が固まってからで遅くありません。
手順 4: 3 体目は、分ける理由を 1 行書けたときだけ足す
2 体が回り始めると、3 体目を足したくなります。足すときは、「この体を分けると、4 つの独立性のどれが増えるか」を 1 行で書いてから足してください。書けなければ、作る役の手順書を厚くするほうを選びます。体を増やす順は、独立性の順に ── 疑う目(作ると疑う)→ 止まる場所(外へ出す操作を持つ体だけを分ける)→ 汚れない文脈(判断の要る仕事だけを独立した体へ)→ 止まらない可用性(書く側と通す側を別のモデルへ)── と進めると、分ける理由を毎回書けます。そもそもどの業務から始めるか、試用から本番までどう進めるかは「AIエージェント導入の進め方」にまとめています。
この記事で持ち帰っていただきたいのは、マルチエージェントは賢さではなく独立性のために分けること、そして分ける理由を 1 行で言えない分割はしないこと、の 2 つです。
Livune は、「作業を AI に任せる仕組み」を構築している会社です。人の仕事を「作業」から「考えること」へ移す、というのが私たちの掲げていることで、マルチエージェントの文脈で言えば、作る・疑う・調べる・突き合わせるを別の体に渡し、人の手元に判断と止める窓だけを残すことが、その具体的な形です。
Livune は、AI エージェントの開発・導入支援を行う会社です。4 つの独立性のどれが要るかの整理、役割・権限・文脈・モデルの線の引き方、作る役と疑う役の分け方、司令塔の置き方 ── この記事に書いた形をそのまま、御社の業務に当てはめるところからご相談ください。自社で司令塔 1 つと担当十数体を毎日回している型を、そのままお話しします。
Livune の AI エージェント導入について相談する →よくある質問
上がりません。複数にしても 1 体ずつの推論の力は同じで、いちばん賢い 1 体より賢い体は生まれません。上がるのは独立性です。作った本人には持てない疑う目、権限を体ごとに付けることで生まれる止まる場所、判断の文脈を実務で汚さない分け方、1 つのモデルが止まっても全部は止まらない可用性。結果として誤りが通り抜ける経路が減るので「出てくるものの質が上がった」ように見えることはありますが、それは賢くなったのではなく、疑う目が別にあるからです。
2 体からです。今動いている 1 体を「作る役」にし、別の会話で「疑う役」を立て、成果物と仕様だけを渡して、通すか止めるかを返させる。疑う役は読み取り専用で直させません。この 2 体で、独立性のうち最も効く「疑う目」が手に入ります。3 体目以降は、「分けると 4 つの独立性のどれが増えるか」を 1 行で書けたときだけ足してください。書けない分割は、体の数だけ運用を増やすだけです。
体同士に決めさせません。作る役と疑う役の意見が食い違うのは、分け方が効いている印で、どちらが正しいかを AI 同士の話し合いで決めると、独立性が消えます。司令塔が両方の材料(成果物・仕様・疑う役の指摘と理由)をそろえ、責任を伴う判断は人が下します。最初のうちは司令塔が人なので、自然にそうなります。司令塔を AI にした後も、食い違いが残った案件は人の判断に回す形を手順書に書いておいてください。
1 人ほど意味があります。1 人が仕組みを組み、同じ 1 人が使い、同じ 1 人が確かめる形は、二重に属人化していて、疑う目がどこにもありません。司令塔を自分が務め、作る体と疑う体の 2 席を AI に置くだけで、「作った本人が確かめる」から抜け出せます。作る人と疑う人を別にする最小の形は「属人化をAIで解消する方法」でも書いたとおりで、疑う役は成果物を読むだけなので、作る役より短い時間で済むことが多くあります。