マルチエージェントシステムとは？AIを工程で分ける仕組みと製造業の例

「AIに受注処理を任せたい」というご相談を受けたとき、当社はまず、その仕事を工程に分けてお聞きします。受注データの受け取りなのか、見積りなのか、生産計画なのかで、扱う情報も判断の基準も違うからです。

マルチエージェントシステムとは、複数のAIエージェントに工程ごとの担当を持たせ、連携させて一連の業務を進める仕組みです。

一つのAIにすべてを任せるより、どこで間違えたかを追いやすく、工程ごとに人の確認を入れやすくなります。

その代わり、工程の間の受け渡しの設計や、AIの利用料といった手間と費用は増えます。この記事では、中小製造業の受注から出荷までを例に、仕組み・利点・課題と、小さく始める進め方を整理します。

マルチエージェントシステムとは？

まずはシングルエージェントとの違いを表で押さえ、そのうえで前提になる「AIエージェント」という言葉を整理します。

複数のAIが工程を分担する仕組み

一つのAIエージェントがすべての作業を受け持つ構成を、シングルエージェントと呼びます。

これに対して、複数のエージェントがそれぞれ専門の担当を持ち、連携しながら一連の業務を進める構成が、マルチエージェントシステム（Multi-Agent System、略してMAS）です。

二つの構成の違いを、表にまとめました。

比較項目	シングルエージェント	マルチエージェントシステム
AIの数	一つのAIが全工程を受け持つ	工程ごとに担当のAIを置く
指示（プロンプト）	全工程の指示を一つにまとめる	担当の工程に要る指示だけを渡す
間違えたとき	どの工程で誤ったかを追いにくい	工程ごとの結果を見て原因を絞れる
直すとき	一か所の修正がほかの工程に響きやすい	担当のAIだけを直せる
人の確認	全部任せるか、全部人がやるかになりやすい	工程ごとに人の確認を入れられる
手間と費用	作りが単純で、AIの利用料も少ない	受け渡しの設計が要り、利用料も増える

どちらか一方が優れているわけではありません。工程が少なく判断も単純な業務なら、シングルエージェントで足ります。

工程が多く、工程ごとに判断の基準や誤ったときの重さが違う業務ほど、分ける意味が大きくなります。中小製造業の受注業務は、その代表です。

前提となるAIエージェントとは？

生成AIの使い方は、大きく二つに分かれます。

• 指示を出して結果を受け取る使い方：文章の作成・要約・翻訳など、人が指示を出し、AIが答えを返して終わる
• 目的を伝え、途中の手順もAIが進める使い方：「注文書から数量と納期を読み取り、在庫を確かめ、足りなければ調達依頼を出す」のように、次の工程へ自分で進む

後者をAIエージェントと呼びます。答えを返して終わるのではなく、次の工程へ自分で進む点が特徴です。

AIエージェントには、さらに自律型とワークフロー型があります。自律型は進め方そのものをAIが考え、ワークフロー型は業務の流れを人が設計して固定し、工程の中の判断をAIが受け持ちます。

Anthropicのエージェントの作り方の解説でも、決めた道筋で動かす「ワークフロー」と、AIが自分で進め方を決める「エージェント」を分けて説明しています。

受注・見積り・請求のように手順が決まった事務の仕事に向くのは、ワークフロー型です。この記事の工程ごとの分担も、ワークフロー型を前提にしています。

二つの型の違いは、RPA・AIエージェント・マクロの違いでも表で比べています。

一つのAIに全工程を任せると起きること

受注から出荷までの全工程を一つのエージェントに任せるのが、最も単純な形です。ただ、工程が増えるほど、次の四つの問題が出てきます。

1. 指示が長くなり、条件を見落とす：すべての工程の指示を一つにまとめると、AIが一部の条件を見落としやすくなります
2. どこで間違えたかが分からない：処理がひとまとまりのため、どの工程で誤ったかが外から見えません
3. 一か所を直すと別の箇所が崩れる：見積りのために指示を直すと、受注の読み取りの結果まで変わることがあります
4. 止めたい工程だけを止められない：「見積りだけは人がやりたい」と言われても、その工程だけを切り離せません

特に「この取引先は単位が違う」といった例外の条件は、長い指示の中に埋もれがちです。現場から「数字が違う」と言われても、どこを直せばよいかが分かりません。

また、直すたびに全体を試し直す必要があり、改善を重ねるほど確認の手間が増えます。「すべてAIに任せるか、すべて人がやるか」の二択になり、段階的に導入しにくくなります。

一つ目の問題については、長い入力の中ほどにある情報ほど使われにくくなる傾向が、スタンフォード大学などの研究者の論文（Lost in the Middle）でも報告されています。

工程が増えるほど、一つのAIでは原因を追いにくく、直しにくく、止めにくくなります。

仕組みは役割分担と束ね役

こうした問題を、工程を分けることで解くのがマルチエージェントシステムです。仕組みは、工程ごとの担当と、全体を束ねる役の二つで成り立っています。

役割分担とオーケストレーター

工程ごとに担当のエージェントを置き、処理の結果を次の工程へ受け渡していきます。人の組織で部署を分けるのと同じ考え方で、営業が受注を取り、設計が図面を描き、製造が作り、出荷が送る、というようにバトンを渡します。

各エージェントは、自分の工程に要る情報だけを持ちます。受注を読み取るエージェントは、出荷の手順まで知らなくて構いません。

工程を分けると、全体の流れを取り仕切る役が要ります。これをオーケストレーターと呼びます。

オーケストレーターは、どのエージェントをいつ動かすかを決め、前の工程が終わったら次を呼び出し、途中で問題が起きたら知らせます。工程を細かく分けること以上に、この束ね方の設計が仕組みの出来を左右します。

当社の開発では、エージェントのつながりと処理の進み具合を画面に映す「現場ボード」を作りました。作り方は現場ボードの開発記録にまとめています。

構成の主な型

エージェント同士のつなぎ方には、主に次の型があります。IBMのマルチエージェント・システムの解説でも、中央で束ねる型、分散する型、階層型に分けて説明しています。

型	つなぎ方	向き・不向き
集中型	中央の一つの役が全体の情報を持ち、各エージェントをつなぐ	流れを追いやすい。中央の役が止まると全体が止まる
分散型	全体を束ねる役を置かず、エージェント同士が近くの相手と情報をやり取りする	一つが止まっても全体は動く。全体の動きをそろえるのが難しい
階層型	上位のエージェントが仕事を分け、下位のエージェントがさらに分担する	工程の中に細かい作業が多い業務に向く。段が増えるほど設計が重い

事務の業務では、流れを人が追いやすい集中型が基本です。この記事の受注から出荷までの例も、オーケストレーターが全体を束ねる集中型です。

構築に使う主なフレームワーク

工程をつなぐ仕組みを、一から作る必要はありません。工程の受け渡し、途中で止めて人の確認を待つ仕組み、状態の保存などを備えたフレームワークが公開されています。

名称	提供元	特徴
LangGraph	LangChain	工程を線でつないだ図（グラフ）として流れを組む。途中の状態を保存し、人の確認を挟める。MITライセンス
CrewAI	CrewAI	役割を持つエージェントのチーム（Crew）と、流れを決めるFlowを組み合わせる。オープンソースで、企業向けの版もある
Microsoft Agent Framework	Microsoft	AutoGenとSemantic Kernelの後継。.NETとPythonで、複数のエージェントの流れをワークフローとして組む
OpenAI Agents SDK	OpenAI	エージェント同士の引き継ぎ（handoff）と、入力と出力の検査（guardrail）を備える
Claude Agent SDK	Anthropic	親のエージェントが、指示と使える道具を絞った「サブエージェント」に仕事を任せる

以前よく名前が挙がったAutoGenは、新しい機能を追加しない保守のみの状態になり、新しく使う人にはMicrosoft Agent Frameworkが勧められています。古い記事や提案書でAutoGenが出てきたら、後継に移る前提で考えてください。

システム開発を外に頼むときに、経営者がこれらを細かく比べる必要はありません。ただし、開発側から「一から自作する」と提案されたら、将来の保守や費用の面から、その理由を確かめておくと安心です。

当社がLangGraphで組んだワークフロー型の例は、LangGraphで組むワークフロー型AIエージェントで紹介しています。

受注から出荷までを工程で分ける

金属加工の会社を例に、工程ごとの分担を見てみましょう。受注から出荷までを六つの工程に分け、人が承認する工程と、確認を軽くできる工程を決めていきます。

工程ごとの分担の例

それぞれの工程で、AIが行うこと、人が確かめること、誤ったときの影響を並べました。

工程	AIが行うこと	人が確かめること	誤ったときの影響
受注の受け取り	FAX・メール・電話の注文から、品番・数量・納期を取り出す	読み取れなかった項目、読みにくい手書き	数量や品番の取り違え
見積り	材質・寸法・数量が近い過去の案件を探し、金額の案を出す	金額が妥当か（決めるのは人）	安すぎる見積りを出して赤字になる
図面と仕様の確認	注文と図面の材質・公差・表面処理を突き合わせる	図面に書かれない取り決めや、取引先ごとの慣習	加工のあとで仕様違いが分かる
生産計画	設備の空きと納期を照らし合わせ、割り当ての案を作る	段取り替えの手間、職人の得意・不得意	納期に間に合わない計画になる
進捗の記録	現場の完了報告を受けて、次の工程へ進める	異常や遅れが出たときの判断	記録と実際の進み具合がずれる
出荷と請求	出荷指示書と請求書の案を作る	請求の内容（社外に出す書類は人が承認）	誤った請求

同じ受注業務の中でも、人の確認の重さは工程ごとに違います。一つのAIにまとめると、この違いを付けられません。

図面と仕様の確認は、図面に書かれない前提が多いため、人の確認の比重が高い工程です。取引先ごとの慣習を知る担当者が、最後に目を通す形にします。

受注の読み取りと見積りから始める進め方は、次の記事で詳しく紹介しています。

人が承認する工程を決める

マルチエージェントシステムでも、すべての工程を自動にしてよいわけではありません。社外に出る情報と、あとから取り消せない処理には、人が承認する工程（Human-in-the-loop）を必ず挟みます。

• 見積りの金額を取引先に出す
• 資材や部品を発注する
• 納期を回答する
• 請求の金額を確定する

これらは誤ると、取引先に直接迷惑がかかります。AIが案を作り、人が確かめて承認してから社外に出す流れにしてください。

工程ごとに承認を置くかどうかは、「社外に出るか」「取り消せるか」の二つで決めると整理しやすくなります。記入例は次のとおりです。

工程	社外に出るか	取り消せるか	扱い
受注の読み取り	出ない	直せる	読めなかった項目だけ人が確かめる
見積り	出る	出したあとは取り消しにくい	金額を人が承認してから送る
生産計画	出ない	直せる	割り当ての案を人が見て決める
資材・部品の発注	出る	取り消しにくい	人が承認してから発注する
納期の回答	出る	取り消しにくい	人が承認してから回答する
進捗の記録	出ない	直せる	AIに任せ、異常のときだけ人が判断する
請求	出る	取り消しにくい	金額を人が承認してから送る

一方で、データの整理、進捗の記録、社内資料の下書きのように、社内で完結し、誤っても直せる処理は、AIに任せる範囲を広げやすい工程です。

生産計画や進捗の記録といった工程管理の部分にAIを使うときも、AIが出すのは割り当ての案までにし、決めるのは現場の担当者にします。段取り替えの手間や人の配置は、設備のデータだけでは分からないからです。

進捗の記録は、誤っても次の報告で取り戻しやすいため、人の確認を軽くしやすい工程です。確認を軽くする工程と、承認を必ず置く工程を分けておくことが、工程を分ける意味そのものです。

送る前に止める仕組みは、承認の画面を通らないと社外に出ない作りにするのが基本です。作り方は次の記事で紹介しています。

マルチエージェントシステムの利点

工程を分けると、次のことができるようになります。一つずつ見ていきましょう。

• 工程ごとに正しく動いているかを測れる
• 問題のある工程だけを直したり、差し替えたりできる
• 特定の工程だけを人の担当に戻せる
• どこで処理が止まっているかが分かる

工程ごとに作業の精度を測って修正できる

「受注の読み取りの精度は高いが、見積りの精度は低い」といった判断ができます。全体に対して漠然と「うまくいかない」と悩むのではなく、どこを直すべきかがはっきりします。

精度の測り方も具体的になります。受注の読み取りなら「品番と数量を正しく読み取れた割合」、見積りなら「人が直さずに承認できた割合」のように、工程ごとに指標を決められます。

数字が出れば、社内の話し合いも変わります。たとえば「AIは使えない」ではなく、「見積りの精度が7割にとどまっているので、ここを直そう」という会話ができます。

工程ごとの数字を毎月どう見るかは、AIエージェント導入後の運用と保守で紹介しています。

見積りの計算方法を変えたいときは、見積り担当のエージェントだけを作り直せます。ほかの工程には影響しません。

業務の前提は変わっていきます。新しい取引先が増えれば注文の様式が変わり、設備を更新すれば生産計画の立て方も変わります。

工程を分けておけば、変わった箇所だけを直せて、仕組み全体を作り直さずに済みます。この差は、将来の保守の費用にもそのまま響きます。

人が受け持つ工程を決められる

「見積りだけは当面、熟練の職人が担当したい」という運用ができます。その工程だけを人が引き受け、前後の工程はAIに任せる、という段階的な使い方を進められます。

これは導入のときの、現場の抵抗感を減らすうえでも役立ちます。「すべての業務をAIに任せる」と聞くと現場は身構えますが、「まずは受注票の読み取りだけ試す」なら合意を得やすくなります。

また、不具合が起きたときも、問題のある工程だけを手作業に戻し、ほかの工程は動かし続けられます。業務全体を止めずに済むのも、工程を分けた利点です。

工程ごとに、どこで人の確認が要るかを決められます。「金額と数量は人が承認し、それ以外のデータの整理はAIに任せる」といった線引きを、工程の単位で設定できます。

人が承認して責任を持つ工程と、AIが処理する工程が分かれるため、責任の所在もはっきりします。「AIが勝手に処理してトラブルになった」という事態を防げます。

情報を絞り、同時に動かせる

受注を読み取るエージェントに、出荷の手順まで教えておく必要はありません。担当する工程に要る、最小限の情報だけを渡します。

渡す情報を絞ると、関係のない指示が混ざらなくなり、精度が上がりやすくなります。

Claude Agent SDK（AIエージェントを作る開発キット）のサブエージェントの説明でも、専用の指示を持たせることと、使える道具を絞って意図しない操作を防ぐことを利点に挙げています。

社外に出せない情報も管理しやすくなります。たとえば単価の計算ルールを知る必要があるのは見積りのエージェントだけで、ほかの工程のエージェントには持たせずに済みます。

お互いの結果を待たなくてよい工程同士は、同時に進められます。たとえば「図面と仕様の確認」と「過去の似た案件の検索」は、どちらも受注の内容さえあれば始められます。

一つのエージェントが上から順に処理すると、待ち時間が積み重なります。同時に動かせば、全体はいちばん時間のかかる工程の分だけで終わるため、案件が重なる繁忙期ほど差が出ます。

引き継ぎと説明がしやすくなる

工程が分かれていると、仕組みが「何をしているか」を人に説明しやすくなります。「この工程では、注文書から品番を読み取っています」のように、現場の担当者にも動きを伝えられます。

仕組みが特定の担当者にしか分からない状態になると、Excelマクロの属人化と同じ問題が起きます。事業承継を控えた会社ほど、業務の仕組みを説明できる状態にしておくことが、引き継ぎの前提になります。

マルチエージェントシステムの課題

マルチエージェントシステムは、良い面ばかりではありません。導入の前に、次の手間と費用を知っておきましょう。

受け渡しと見える化を設計する

工程Aの出力が、そのまま工程Bの入力になります。「何をどの形式で渡すか」を前もって決めておく必要があり、ここがあいまいだと、工程の境目で必要な情報が抜け落ちます。

エージェント同士でどこまで情報を共有させるかの設計も大切です。すべての情報を共有させると、結局はシングルエージェントと同じ構造に戻ってしまいます。

工程を細かく分けるほど、案件全体の進み具合が見えにくくなります。「今どの案件が、どの工程で止まっているか」をひと目で確かめられる画面が要ります。

当社の開発では、案件ごとの処理の記録を並べて見られる画面も、現場ボードに用意しました。

手間とAIの利用料が増える

たとえば六つの工程に分けるなら、六通りの指示を作って調整する必要があります。運用を始めてからも、工程ごとに動きを確かめる手間がかかります。

最初からすべての工程を一気に分けようとすると、設計が終わりません。後で紹介する、小さく始める進め方をおすすめします。

エージェントの数が増えれば、AIを呼び出す回数も増えます。Anthropicは、自社の調べもの用のマルチエージェントシステムについて、チャットのおよそ15倍のトークン（AIの利用料の単位）を使うと報告しています。

同じ報告では、その分だけ調べものの成績が上がったとも述べていて、増える費用に見合う業務かどうかを見極めることが前提です。利用料の見方は、業務用途のLLM使用料金で整理しています。

分けないほうがよい業務もある

すべての情報を全員が共有しないと進まない業務や、工程同士が細かく依存し合う業務は、分けても利点が出にくくなります。Anthropicも同じ報告で、そうした業務は今のマルチエージェントシステムに向かないと書いています。

Anthropicの解説でも、できるだけ単純な作りから始め、結果が良くなるときだけ複雑にすることを勧めています。

小さく始める進め方

最後に、マルチエージェントシステムを業務に取り入れるときの進め方です。最初から完成形を目指さず、一つの工程から広げていきます。

1. 最初から全工程を分けない：すべての工程を一度に作ろうとすると、設計だけで数か月かかり、現場に効き目が届くまでが長くなります
2. 手戻りの多い一工程から始める：「受注票の読み取りの誤りが多い」「見積りに時間がかかりすぎる」など、現場の困りごとがはっきりした工程を一つ選びます
3. 一つ目が安定してから次を足す：目安として1か月ほど、最初の工程が安定して動くのを確かめてから、次の工程を足します。同時に複数を変えると、問題が起きたときに原因を切り分けられません

製造・建設・物流の業務で、どこから自動にするかを並べた一覧は、業務自動化でできること一覧にまとめています。

まとめ

工程が多く、工程ごとに判断の基準や誤ったときの重さが違う中小製造業の受注業務は、マルチエージェントシステムの考え方が生きる領域です。一方で、工程が少ない業務なら、一つのエージェントで足ります。

どの工程から分けるか、どこに人の承認を置くかは、業務の流れを書き出してみると見えてきます。当社では、業務の流れをお聞きしたうえで、どの工程からAIに任せるかを一緒に考えています。

中部地方の製造業でAIエージェントの導入を検討している方は、次の記事もご覧ください。