マルチエージェントを業務で使う設計。1本の仕事をAIに分ける順番

マルチエージェントを業務で使う設計とは、1体のAIに丸投げすると崩れる1本の仕事を、複数のAIに分けて通す設計のことです。分けるかどうかには順番があります。分けない線を引く、成果物と合格基準で切る、検品するAIを書き手から分ける、受け渡しはコードで決める、壊れた体を切り分ける、コストを覚悟する。この6つの順番で決めれば、分けた仕事は毎朝動き続けます。

僕はAIVESTという会社を経営しながら、自分でも手を動かしてAIの分業を設計しています。このブログの記事は、企画・執筆・画像・検証の4体のAIに分けて毎朝生成されています。検索で出てくるマルチエージェントの解説は、定義、協調パターン、フレームワーク比較、事例までは揃っています。この記事はそこに無い「どこで分けず、何を単位に分け、誰に検品させ、どう受け渡し、壊れたらどう切り分け、コストをどう覚悟するか」の順番を、自社で毎朝動いている分業の現物で埋めます。強化学習やシミュレーションで多数のエージェントを動かす学術のマルチエージェントシステムは、この記事の題材ではありません。

マルチエージェントを業務で使う設計とは。1体に丸投げして崩れる仕事を分けて通す

分ける判断の6つの順番

AIエージェントとは、目標を渡すと道具を使って複数の工程を自分で進めるAIです。マルチエージェントとは、そのAIエージェントを複数組み合わせて、1本の仕事を通す仕組みを指します。AIエージェント1体の定義と、業務のどこに置くかの判断は、別の記事にまとめてあります。

関連記事AIエージェントとは。チャットAIとの違いと業務に置ける範囲AIエージェントとは、目標を渡すと道具を使って複数の工程を自分で進めるAIのことです。チャットAI・生成AI・RPAとの違いを比較表で整理し、自社で毎日動かしている実例から、業務のどこに置けるかの判断基準まで経営者向けに解説します。→

この記事が扱うのは「1体では崩れる仕事を、複数に分けて通す設計」です。僕が自社で分けるときは、毎回この順番で判断します。

1. 分けないほうがよい仕事の線を先に引く。一本道の仕事は1体で通す

2. 分ける単位は「役割」ではなく「成果物と合格基準」で切る

3. 検品するAIを書き手から分ける。自分の出力は審査させない

4. 受け渡しはコードで決める。AI同士に会話させない

5. 失敗したらどの体が壊れたかを切り分ける

6. トークンと時間のコストを覚悟する。分けるほど消費は増える

分けるかどうかを決める順番が先で、ツールや協調パターンを選ぶのはその後です。 上位の解説がパターンの分類から始まるのとは、順番が逆になります。

上位の解説はどこで止まるのか

マルチエージェントの解説記事の多くは、司令塔が指示を出す型、対等に分担する型、階層で管理する型、といった協調パターンの分類を示します。この分類は上位の解説から借りたもので、僕の発明ではありません。パターンは地図としては役に立ちますが、パターンを選んでも「自社のこの仕事を、どこで切るか」は決まりません。切る場所を決めるのは、パターンではなく、成果物と合格基準です。

なぜ1体のAIに丸投げすると仕事が崩れるのか

分ける前に、1体で崩れる理由を3つに絞ります。理由が分かると、分ける場所が決まります。

崩れ方1: 「改善して」型の指示の限界

2026年8月にXで広く読まれた投稿に、AIに「改善して」と言うとよく分からない結果になる、という趣旨のものがありました（出典は末尾）。1体に「改善して」と渡すと、そのAIは何が問題かを自分で決め、自分で直し、自分で良しとします。直す対象と合格の形が定義されていないので、直った理由が誰にも分かりません。1件の指示文に完了・検品・上限を書く設計はAIに仕事を任せるプロンプトの設計に書いたので、ここでは繰り返しません。

崩れ方2: 記憶の容量が溢れる

コンテキストとは、AIが一度に覚えていられる作業記憶の容量です。調査、執筆、検品を1体でやらせると、後半に差しかかるころには調査で読んだ大量の資料が記憶を埋め、最初の指示が薄れます。長い仕事の後半で、冒頭に決めた約束が守られなくなる現象は、この容量の問題です。

崩れ方3: 自分で書いて自分で検品する甘さ

書いたAIに「チェックして」と頼むのは、自己採点です。2024年4月に公開された研究では、大規模言語モデルが評価者になると、自分自身の出力を他のモデルや人間の出力より高く評価する傾向が確認されています（出典は末尾）。書き手と検品者を同じ体にすると、検品は構造的に甘くなります。 これが、分ける最大の理由です。

サブエージェントとマルチエージェントは何が違うのか。独立するのは文脈・道具・権限

サブエージェントとは、親のAIが呼び出す、別の記憶と道具を持った子のAIです。僕が自社で主に使っているClaude Codeの公式ドキュメント（2026年9月時点）では、次のように定義されています。

各サブエージェントは、カスタムシステムプロンプト、特定のツールアクセス、および独立した権限を備えた独自のコンテキストウィンドウで実行されます。（中略）サブエージェントはそのタスクを独自のコンテキストで実行し、概要のみを返します。（Claude Code公式ドキュメント「カスタムサブエージェントの作成」2026年9月時点）

経営者の言葉に翻訳すると、独立するのは「記憶（文脈）」「道具」「権限」の3つで、親に返るのは概要だけ、です。使うモデルも子ごとに指定でき、指定しなければ親と同じモデルになります。また、公式ドキュメントはサブエージェントが「単一のセッション内で動作します」と明記しています。1つの作業の中で呼ばれる子、という位置づけです。

マルチエージェントは、この機能名より広い言葉です。サブエージェントは1つのツールの機能名で、マルチエージェントは「複数のAIで1本の仕事を通す設計」全般を指します。マルチエージェントAIと呼ばれるものも、中身はこの設計です。この記事は設計の話なので、使うツールがClaude Codeであっても、他のAIであっても、以降の順番は変わりません。

並列と分業は別物

複数のAIを使う形は2種類あって、混ぜると設計を間違えます。

• 並列: 同じ仕事を同時に走らせる。3つの観点を同時に調べる、3案を同時に書かせる。狙いは速さと幅

• 分業: 違う仕事を順に通す。企画→執筆→検品。狙いは品質で、特に検品の独立

公式ドキュメントも、並列は「研究パスが互いに依存しない場合に最適に機能します」としています（2026年9月時点）。並列の作業場を自分の手元で作る方法はgit worktreeでAIを並列に走らせるに書きました。この記事の主題は分業のほうです。

順番①: 分けないほうがよい仕事の線。一本道の仕事は1体で通す

分業は固定費です。分けた瞬間に、受け渡しと検品の設計が新しい仕事として増えます。だから最初に「分けない」判断を置きます。

一本道は分けても品質が上がらない

途中に検品すべき成果物が無い仕事は、分けても検品の独立が得られません。増えるのは受け渡しの手間だけです。上位の解説にも「一本道の仕事は単一のエージェント向き」という判断基準を持つものがあり、僕も同意見です。

3条件の前に、作るかどうかの4つの質問がある

分ける以前に、そもそもAIエージェントを作るかどうかを決める4つの質問（週1回以上繰り返すか、機械が合否を判定できるか、止める上限はあるか、人間が握る地点はどこか）があります。これは自社業務のAIエージェントの作り方に書いた1体の設計の話なので、ここでは繰り返しません。4つの質問を通った仕事だけが、分けるかどうかの判断に進みます。

順番②: 分ける単位は「役割」ではなく「成果物と合格基準」

「企画担当」「執筆担当」という役割名で分けると、担当の境界が曖昧なまま動き始めます。僕が切る基準は1つで、渡す物と合格の形が書けた所で切る、です。

自社の4体の成果物と合格の形

自社のブログの記事便は、次の4体に分かれています。各体が受け取る物、渡す成果物、機械が判定する合格の形を並べます。

表の右2列が書けない工程は、まだ分けてはいけない工程です。役割名は後からつければよく、先に決めるのは「何を渡し、何なら合格か」です。

成果物は「項目の決まった形」で返す

もう1つ、各体は次の体が読む形式で成果物を返します。自由な文章で返すと、次の体がそれを解釈するところから仕事が始まり、解釈のたびに揺れます。自社では企画の体は項目の決まった記録を、執筆の体は決まった記法の本文を、画像の体は一覧を返し、次の体はその形式だけを読みます。

順番③: 検品するAIを書き手から分ける。自分の出力は審査させない

書き手に自分の出力を審査させると甘くなるので、検品は別の体に分け、その体に規約を持たせます。

独立した評論家の3つの規約

僕の自社の規約では、検品する体を「評論家」と呼び、次の3つを必ず含めています。

既定は却下。進捗のために合格を与えない。判定は二値（合格／要修正）で、証拠の逐語引用を必須にする。引用できない合格は禁止。指摘は「対象物名＋症状＋推定原因」の3点セットで書く。（自社の規約より）

0点から10点の採点は使いません。点数は甘くなりやすく、判定のばらつきも大きいからです。評論家が見るのは、成果物と受け入れ基準の2つだけです。書き手の意図や「たぶん大丈夫」という説明は、判定材料にしません。新鮮な文脈で、成果物と基準だけを見る。 これが検品の独立です。

別系統のAIに併走させる。片方でもP0なら差し戻す

同じ系統のAIは、文脈を独立させても「自分の書き癖を好む」傾向が残ります。そこで2026年9月、自社の規約に次の運用を追加しました。

• 同じ成果物を、別系統のAI（別の会社のモデル）にも併走してレビューさせる

• どちらか一方でもP0（公開を止めるべき最重要の指摘）を出したら差し戻す

• 両者の指摘を突合し、「両者一致」「片方のみ」「矛盾」を明示して報告する

代替ではなく併走で、狙いは第二意見です。別の会社のモデルであること自体に意味があります。2つのAIを併用する実際の使い分けはClaude CodeとCodexの比較に書いています。

順番④: 受け渡しはコードで決める。AI同士に会話させない

体と体の間で渡すのは、前工程の成果物とその置き場所だけです。渡すのは決定論的なコード（同じ入力なら必ず同じ動きをするプログラム）で、AI同士に会話で引き継がせません。

会話で引き継ぐと何が起きるか

会話で引き継ぐと、要約のたびに情報が欠けます。「執筆の体が企画の体に質問してよい」と許すと、質問と答えのやり取りが記録に残らず、壊れたときにどこで欠けたかを追えません。自社では、各体は前工程の成果物のファイルを読む以外に、前工程のことを知りません。最終工程の体に渡している指示は「判断せず、決定的コードを順に実行して結果を報告する係」です。判断はAIに、順番と受け渡しはコードに、と分けています。

最初は体どうしに相談させたくなるんですよね。でも、やめました。会話の記録より、成果物のファイルが残っているほうが、翌朝の僕が読めるんです。

機械ゲートが先に止め、人は24時間以内に事後レビュー

受け渡しの最後には機械ゲートがあります。検査の終了コード（プログラムが正常に終わったかを返す数字）が0でなければ、記事は公開されません。失敗したときは最小修正のやり直しを1回だけ許し、再び失敗すればそこで止まります。人間は公開後24時間以内の事後レビューです。2026年7月に決めた運用で、2026年9月時点も同じです。ゲートの検査項目そのものはAI記事の品質ゲートにまとめました。

順番⑤: 失敗したらどの体が壊れたかを切り分ける

分けた仕事は、分けた数だけ壊れる場所が増えます。だから体ごとに状態を記録し、止まった段で止めます。

体ごとの状態記録

自社の記事便は「企画済み」「執筆済み」「画像済み」「投稿済み」の状態を記事ごとに記録し、検査で止まれば「検査で停止」と記録します。翌朝に見るのはこの記録で、どの体で止まったかが1行で分かります。「全部やり直し」にしないのが切り分けの目的です。 企画済みで止まっていれば執筆からやり直し、検査で止まっていれば本文の最小修正から再開します。

縮退して完走する

画像の体が失敗しても、本文だけで縮退して完走し、劣化を正直に記録します。壊れた体が1つあるときに全体を止めるか、縮退して通すかは、体ごとに先に決めておきます。止まった記録を合格基準に昇格させる運用は自社業務のAIエージェントの作り方の順番⑤に、改善の輪全体はループエンジニアリングに書いています。

「どの体が壊れたか」が言えない設計は、直せない設計です。

順番⑥: トークンと時間のコストの覚悟。分けるほど消費は増える

トークンとは、AIが読み書きする文字の単位で、利用料と利用上限はこの単位で決まります。分けた体の数だけ、同じ成果物の読み直しが起きます。公式ドキュメントも次のように警告しています。

サブエージェントが完了すると、その結果がメイン会話に返されます。詳細な結果を返す多くのサブエージェントを実行すると、かなりのコンテキストを消費できます。（Claude Code公式ドキュメント 2026年9月時点）

倍率は書かない。書けるのは実記録だけ

「分けると消費が何倍になるか」は、僕の会社では工程別に実測していないので書きません。自社のコスト台帳にあるのは画像の枚数の記帳だけです。書けるのは、分けるほど消費が増えるという定性と、次の実記録です。

2026年8月15日から17日の3日間、月間の利用上限に達し、自社の無人の便（記事、資料、週次診断）がすべて起動できなくなりました。18日に上限が更新されて自然復旧しています（社内記録）。上限に当たったときに何が止まるか、どう備えるかはAIサブスクの利用上限に書きました。

工程ごとにモデルを固定する

消費を抑える手段として、自社では工程ごとに使うモデルを固定しています。調査は中位、検出は上位、事実の照合は下位、という割当です。割当の考え方はClaude Codeのモデル選択に、料金の実際はClaude Codeの料金と業務導入にまとめています。

分けるほど消費は増える。上限に当たった朝にどの便を止めるかまで含めて、覚悟です。

最初の1本は企画→執筆→検品の3体で通す

4体から始める必要はありません。最初の1本は3体で通します。

自社の実例。このブログの記事便は4体で毎朝動いている

読んでいただいているこのブログ自身が、この順番で分けた現物です。自社には2種類の型があります。

直列の分業: 企画→執筆→画像→検証

2026年7月から、記事は企画、執筆、画像、検証の4体で毎朝生成されています。各体は前工程の成果物だけを受け取り、間をつなぐのは決定論的なコードです。最終の体は判断せず、決まったコードを順に実行して結果を報告します。2026年9月時点も同じ構成で動いています。成果の数値は計測中で、実測していないものは書きません。

並列の調査: 観点に分解し、並列に調べ、主張ごとに敵対的に検証する

もう1つは調査の型です。問いを調査の観点に分解し、観点ごとに別の体が並列に調べ、出てきた主張を1件ずつ複数のレンズで「誤りを探す姿勢で」検証し、生き残った主張だけで報告をまとめます。検証の体に渡している指示は、厳格な事実検証者として誤りを探す姿勢で裏取りし、主張が誤り・誇張・出典不一致なら棄却する、というものです。事実照合の型は生成AIのハルシネーション対策に書きました。

前者は違う仕事の直列で、後者は同じ仕事の並列です。分業は検品の独立のため、並列は幅と速さのため。狙いが違うので、混ぜずに設計します。

マルチエージェントのよくある質問

まとめ。分けない線を引き、成果物で切り、検品者を分ける

マルチエージェントを業務で使う設計は、パターンやツールの選択ではなく、分ける判断の順番です。

1. 分けない線を先に引く。一本道、1回きり、機械が合否を判定できない仕事は1体で通す

2. 分ける単位は役割ではなく、成果物と合格基準。渡す物と合格の形が書けた所で切る

3. 検品するAIを書き手から分ける。既定却下、二値判定、証拠引用必須。別系統のAIを併走させ、片方でもP0なら差し戻す

4. 受け渡しはコードで決める。前工程の成果物だけを渡し、AI同士に会話させない

5. 失敗したらどの体が壊れたかを切り分ける。体ごとに状態を記録し、止まった段から再開する

6. トークンと時間のコストを覚悟する。分けるほど消費は増え、上限に当たれば便は止まる

最初の1本は3体から。1本が毎朝通るようになってから、4体目を足してください。自社のどの仕事を分け、どこで切るかを一緒に設計したい場合は、お問い合わせからご連絡ください。分業設計の伴走はAI顧問サービスで承っています。

付録。分ける判断の順番チェック表と受け渡しの雛形

出典

線引きを先に書きます。分ける判断の6つの順番、成果物と合格基準で切る考え方、検品者の分離と別系統AIの併走レビュー、受け渡しをコードで決める設計、体ごとの状態記録、自社の記事便と調査の型、2026年8月の利用上限による3日間の停止は、僕の自社運用の記録（分業の規約、記事便の設計、レビューの規約、週次診断の記録。いずれも社内記録・2026年9月時点）に基づく一次情報です。借りた部分は次のとおりです。

• Claude Code公式ドキュメント「カスタムサブエージェントの作成」（2026年9月7日確認）: サブエージェントの定義（独自のコンテキストウィンドウ、ツールアクセス、独立した権限、概要のみを返す、単一セッション内で動作、モデル指定と既定値）と、コンテキスト消費に関する警告文を引用しました。バージョンごとの挙動の違いは本記事では扱っていません

• Arjun Panickssery, Samuel R. Bowman, Shi Feng「LLM Evaluators Recognize and Favor Their Own Generations」（2024年4月公開・arXiv 2404.13076・リンクは省略）: 大規模言語モデルが評価者になると自分自身の出力を高く評価する傾向がある、という知見を「自己優遇バイアス」として借りました。本記事の貢献は、それを打ち消す規約（独立した文脈、既定却下、証拠引用、別系統の併走）として置いたことです

• 協調パターンの分類（司令塔型、分担型、階層型）は、上位の解説記事で広く使われている分類を借りました（各社のリンクは省略・2026年9月7日確認）。本記事はパターンではなく「どこで切るか」の判断順に絞りました

• @suthio_ の投稿（x.com）（2026年9月3日確認）: AIに「改善して」と言うとよく分からない結果になる、という趣旨。1体に丸投げする操作側の限界の需要として用いました

• @connect24h の投稿（x.com）（2026年9月3日確認）: AI研修は成果物より、誰が回しても再現できる工程に価値がある、という趣旨。分業を再現できる工程として書く、という本記事の出発点に用いました