2026.08.19

AIエージェントの種類｜自律度と構成の3軸で業務に当てはめる整理法

AIエージェントの種類を調べると、記事ごとに違う分類が出てきます。単純反射型から学習型まで並べた表、汎用型と特化型で分けたもの、製品の提供形態で切ったもの。どれも間違いではないのですが、読み比べるほど自社の検討には使いにくくなります。

社内で本当に必要になるのは、分類名を覚えることではありません。任せたい業務に対してどこまで自分で判断させるのか、実行の前に人が承認を挟むのか、1体で足りるのか複数で分担させるのか。この3点が決まらないまま製品比較に進むと、機能の多さだけで優劣を判断してしまいます。

本記事では、AIエージェントの種類を内部構造による5分類、自律度による段階、単体かマルチかという構成の3軸で整理します。古くから使われてきた分類は出典を示しながら扱い、最後に業務側の条件から種類を選ぶ判断材料まで接続します。

情報システム部門やDX推進、経営企画で、AIエージェントの検討を任された担当者に向けた内容です。分類の整理から社内説明の準備までを一度に進めたい場合は、お問い合わせからご相談いただけます。

AIエージェントの種類は3つの軸で整理できる

AIエージェントの種類は、内部構造、自律度、構成という3つの軸で整理できます。AIエージェントとは、目標を受け取ると必要な手順を自ら判断し、ツールを使って実行まで進めるAIシステムです。分類が混乱しやすいのは、この3軸が1つの記事の中で混ざったまま並べられているからです。

3つの軸は、それぞれ答えている問いが違います。

軸	答える問い	分類の中身
内部構造	エージェントの中で何をもとに行動を決めているか	単純反射型、モデルベース反射型、目標ベース、効用ベース、学習エージェント
自律度	人がどこで承認を挟むか	単発の呼び出しから、イベントで起動して実行まで進む形まで
構成	1体で担うか複数で分担するか	単体エージェント、マルチエージェント

内部構造の軸は、AI研究の分野で古くから使われてきた分類です。製品や構成がどの設計思想に寄っているかを見分ける物差しとして役立ちます。自律度の軸は、導入検討で最初に決まる部分です。実行の前に人の確認を挟むかどうかで、業務への載せ方も社内の承認の取り方も変わります。構成の軸は、任せたい業務の広さで決まります。

3軸を分けて読むと、製品資料の見え方も変わります。自律型AIエージェントと書かれた製品を見たとき、それが承認の位置を指しているのか、学習によって精度を上げる内部構造を指しているのかを切り分けて確認できるようになります。混ざったまま読み進めると、社内説明の段階で「結局それは何ができるのか」に答えられません。

順序も決まっています。まず自律度、次に構成、最後に内部構造です。自律度は業務の統制に直結するため、社内の合意が必要です。構成は対象業務の広さから決まります。内部構造は、その2つが決まった後に、設計の妥当性を確かめる目線として使います。

世の中で見かける分類には、提供のされ方で分けたものや、用途で分けたものもあります。どちらも購買の判断には役立つ整理ですが、任せ方そのものは説明してくれません。同じ用途の製品でも、承認をどこに置けるかで運用は別物になるからです。本記事の3軸は、購買の前に決めておく設計側の整理として使ってください。

内部構造による5分類｜古典的なエージェント分類

内部構造による分類は、エージェントが行動を決める仕組みの違いで5つに分かれます。単純反射型、モデルベース反射型、目標ベース、効用ベース、学習エージェントの5つで、AI分野の標準的な教科書であるRussell & Norvig『Artificial Intelligence: A Modern Approach』の第2章で扱われている整理です。

同書の目次を見ると、第2章のThe Structure of Agentsという節の下に、Simple reflex agentsからLearning agentsまでの各項が並んでいます。AWSの日本語ドキュメントでも、AIエージェントのタイプとしてこの5つを挙げ、さらに階層型エージェントとマルチエージェントシステムを加えた形で紹介されています。5分類は製品を仕分ける道具ではなく、行動を決める材料が何かを示した整理です。

単純反射型エージェント

単純反射型エージェントは、いま受け取った入力だけを見て行動を決める、最も単純な形です。過去のやり取りは保持せず、条件と行動を結んだルールに従って反応します。

同書では、前の車がブレーキを踏んだら自分もブレーキをかけるという例で説明されています。前の車が制動中なら自分も制動を開始する、という条件と行動の対応をルールとして持っている状態です。人の反射に近い動き方だと考えるとつかみやすくなります。

業務で対応するのは、判断の分岐が固定されている一次対応です。問い合わせを決められた区分に振り分ける処理、条件に合致した申請を定型のフローに流す処理が当てはまります。履歴を見ないため、前後の文脈をふまえた対応は苦手です。同じ人から3回目の問い合わせが来ても、1回目と同じ扱いになります。

モデルベース反射型エージェント

モデルベース反射型エージェントは、いま見えていない部分を内部の状態として保持しながら行動を決めます。環境の一部しか観測できない状況に対応するための形です。

同書は、この内部状態を保つために2種類の知識が必要になると説明しています。世界が自分の行動とは無関係にどう変化するかという知識と、自分の行動が世界にどう影響するかという知識です。この2つをまとめたものが世界のモデルと呼ばれ、モデルを使うエージェントがモデルベースと呼ばれます。

業務では、状況が時間とともに動く処理に向いています。在庫や稼働状況のように、観測できていない間も変化し続ける対象を扱う場合、直前の状態を保持していなければ判断が成り立ちません。定時実行の処理で前回からの差分を見る設計も、この性質に支えられています。

目標ベースエージェント

目標ベースエージェントは、現在の状態に加えて達成したい目標を持ち、そこから逆算して行動を選びます。同じ状況でも目指す先が違えば選ぶ行動が変わる点が、単純反射型との違いです。

同書では、交差点でタクシーが左折、右折、直進のどれを選ぶかは、どこへ向かっているかによって決まると説明されています。現在の状態の記述だけでは正しい行動が決まらない、という指摘です。

業務で対応するのは、複数の手順を経て完了する処理です。申請の受付から内容確認、システムへの登録までを1つのゴールとして渡す形が近く、途中の手順が案件ごとに変わっても、目標に近づく行動を選ばせられます。目標を渡せるかどうかは、完了条件を言葉で書けるかどうかで決まります。

効用ベースエージェント

効用ベースエージェントは、目標を達成する複数の道筋を比べ、望ましさの度合いで選びます。目標の達成か未達成かという二択では、結果の質の違いを扱えないためです。

同書は、タクシーが目的地に着く行動の並びは複数あり、その中には速いもの、安全なもの、安いものがあると述べています。速さと安全のように目標が競合する場合、どちらをどこまで優先するかを決める尺度が必要になります。この尺度が効用関数と呼ばれるもので、状態の望ましさを数値で表す仕組みです。

業務では、費用と品質、速度と正確さのように、両立しない条件の間で折り合いをつける処理に向きます。ただし、何をどれだけ重く見るかを設計時に決める必要があります。優先順位が社内で合意できていない業務にこの形を持ち込むと、出てきた判断の是非を誰も説明できません。

学習エージェント

学習エージェントは、結果から学んで自分の振る舞いを更新していく形です。前の4つと横並びの別種ではなく、どの形にも後から学習の仕組みを載せられる位置にあるという関係です。

同書は、学習エージェントを4つの部品で説明しています。外部への行動を選ぶ実行部、改善を担う学習部、成果を評価して学習部に伝える評価部、新しい経験につながる行動を促す問題生成部です。評価の基準は外部に固定して置き、エージェント自身が書き換えられないようにする点が重要とされています。自分に都合よく基準を変えられる状態では、改善が測れなくなります。

業務では、応対の品質のように継続的な改善が見込める領域に向きます。逆に言えば、良くなったかどうかを判定する基準を先に決めていない業務では、学習の仕組みを載せても効果を確認できません。

参考：Full Table of Contents for AI: A Modern Approach

参考：Artificial Intelligence: A Modern Approach 第2章 INTELLIGENT AGENTS

参考：AI エージェントとは（AWS）

自律度による5段階｜人がどこで承認するかで分かれる

自律度による分類は、人がどこで承認を挟むかで段階が分かれます。ベンダー各社が公開しているドキュメントの記述を並べ替えると、単発の呼び出しからイベントを検知して実行まで進む形までの5段階として整理できます。製品名に自律型と書かれているかではなく、承認がどこに入るかで実際の運用は決まります。

Anthropicは、あらかじめ決めたコードの経路でモデルとツールを動かす仕組みをワークフロー、モデル自身が処理の進め方とツールの使い方を動的に決める仕組みをエージェントとして区別しています。Microsoftのアーキテクチャガイダンスも、単発のモデル呼び出しからマルチエージェントの連携までを複雑さのレベルとして整理し、要件を満たす最も低いレベルを使うよう勧めています。

段階	動き方	人の関与
1	1回のモデル呼び出しで完結する	依頼と結果確認の両方を人が行う
2	決められた手順を順にたどる	手順そのものを人が設計する
3	ツールを選んで実行し、結果を提示する	実行の前に人が承認する
4	影響の小さい操作は自分で実行する	機密性の高い操作だけ承認を挟む
5	イベントを検知して起動し、実行まで進む	起動条件と権限の設計で制御する

段階1｜1回のモデル呼び出しで完結する

段階1は、よく書かれた指示を1回渡して終わる使い方です。エージェントの仕組みもツールへのアクセスも持ちません。分類、要約、翻訳のように、1回の処理で完了する作業が対象になります。

Microsoftのガイダンスは、この段階を最も単純な選択肢として挙げ、プロンプトの工夫で解決できるならエージェントは要らないと述べています。種類を検討する前に、そもそもエージェントが必要かを確かめる位置づけの段階です。ここで足りる業務にエージェントを載せると、費用と運用の手間だけが増えます。

段階2｜決められた手順を順にたどる

段階2は、人が設計した手順をなぞる形です。どのツールをどの順に呼ぶかがあらかじめ決まっており、途中の分岐も設計に含まれます。Anthropicの区分ではワークフローに当たり、エージェントとは区別されます。

予測できる作業で安定して動く点が利点です。同じ入力に対して同じ経路をたどるため、検証もしやすくなります。反面、想定していない状況が来ると処理は止まってしまう点に注意が必要です。止まった箇所が特定しやすいという意味では、運用の初期に向いた形でもあります。

段階3｜ツールを選んで実行し、結果を提示する

段階3は、エージェントが自分でツールを選び、結果を人に提示するところまでを担う形です。実行の前に人の承認が入るため、誤った操作が業務データに反映される前に止められます。

社内の検討で最初に置く段階として現実的な選択肢です。承認の記録が残るので、業務としての妥当性を後から確認できます。注意したいのは件数の増加です。承認が1日に何十件も溜まる状態になると、人の確認が業務の詰まりになります。次の段階に進む条件を最初に決めておくと、承認の滞留を前提にした運用から抜け出せます。

段階4｜影響の小さい操作は自分で実行する

段階4は、影響の小さい操作は承認なしで進め、機密性の高い操作にだけ承認を挟む形です。Microsoftのガイダンスは、承認のゲートをエージェントの出力全体ではなく特定のツール呼び出しに絞ることで、リスクの低い操作は自律的に進められると説明しています。

この設計に移ると、承認の待ち時間がボトルネックになりにくくなります。前提として、どの操作なら影響が小さいのかを業務側で線引きしておく必要があります。読み取りと下書きの作成は自律、送信と確定は承認、という切り分けが分かりやすい例です。

段階5｜イベントを検知して起動し、実行まで進む

段階5は、人の指示を待たずにイベントを検知して起動する形です。Microsoft Copilot Studioのドキュメントは、自律型エージェントを、定義されたトリガーと指示、ガードレールを用いてイベントを認識し、判断して自律的にタスクを実行するものと説明しています。会話の中で応答するのではなく、背後でデータを監視し続ける動き方です。

同ドキュメントは、権限を業務に必要な範囲だけに限定すること、リスクが高い操作の前には人に承認や確認を依頼するよう構成すること、責任範囲は一度に広げず段階的に拡大することを勧めています。段階5に置いたとしても、承認が完全になくなるわけではありません。起動条件と権限の設計が、承認の代わりに効いてくるという理解が近くなります。

参考：Building Effective AI Agents（Anthropic）

参考：自律エージェント機能を設計する（Microsoft Copilot Studio）

単体エージェントとマルチエージェントの違い

構成による分類は、1体のエージェントで担うか、複数のエージェントで分担するかの違いです。任せたい業務が1つの領域に収まるなら単体、部門や専門領域をまたぐならマルチエージェントが候補になります。複数にすれば性能が上がる、という関係ではありません。

Microsoftのアーキテクチャガイダンスは、直接のモデル呼び出し、ツールを使う単体エージェント、マルチエージェントの連携という3つのレベルを示し、そのうちツールを使う単体エージェントを企業のユースケースで適切な既定値として位置づけています。

単体エージェントで足りる範囲

単体エージェントは、1体が複数のツールと知識源にアクセスし、1つの領域の中でさまざまな依頼を処理する構成です。複数構成よりデバッグとテストが容易で、状況に応じた動的な判断も維持できます。

同ガイダンスは、1体で確実に解決できるならその方法を採るよう勧めています。判断とフロー制御にかかる負荷が、分割によって得られる利点を上回る場合が多いためです。あわせて、ツールを無限に呼び続ける状態を防ぐために繰り返しの上限を設けることも挙げられています。ツールと知識源が増えるほど、動きを予測しにくくなる点も指摘されています。

判断の目安になるのは、任せたい業務が1つの部門の中で完結しているかどうかです。問い合わせ対応であれば、参照する知識も更新するシステムもサポート部門の中に収まります。一方で、受注から在庫の確認、出荷の手配までを一続きで任せる場合は、部門ごとに扱えるデータと権限が変わるため、単体では収まりにくくなります。

マルチエージェントで得られること

マルチエージェントは、複数の専門化したエージェントが役割を分けて連携する構成です。同ガイダンスは、1体の大きなエージェントと比べた利点として、専門化、拡張性、保守性、最適化の4点を挙げています。

専門化は、各エージェントが特定の領域に集中することで、指示とコードの複雑さが下がることを指します。拡張性は、全体を作り直さずにエージェントを追加や変更できること。保守性は、テストと調査の対象を個別のエージェントに絞れることで、最適化は、エージェントごとに違うモデルやツールを割り当てられることを意味します。セキュリティの境界をエージェント単位で分けたい場合も、この構成が必要になります。

複雑さは必要な最小限から上げる

複雑さのレベルは、要件を満たす最も低いところから始めるのが基本です。調整の負荷、待ち時間、費用は、レベルが上がるたびに積み増しになります。

マルチエージェントを正当化できるのは、指示の複雑さやツールの過多、セキュリティの要件によって1体では確実に処理できない場合です。同ガイダンスは、意味のある専門化を提供しないエージェントを増やすことを、よくある落とし穴として挙げています。1体で無理な理由を言葉で説明できるかどうかが、構成を上げる判断の基準になります。

分類の議論より先に、承認を誰が持つのかを決めていないために検討が止まる例も見てきました。malnaはAI導入・コンサルティングおよびIT・DX分野で累計40社以上の導入事例に関わっており、構成の選定と承認の設計をあわせて整理する形でご支援しています。自社の業務に当てはめる段階から相談したい場合は、お問い合わせをご利用ください。

マルチエージェントの5つの連携パターン

マルチエージェントの連携は、代表的な5つのパターンに分けられます。Microsoftのアーキテクチャガイダンスが示すシーケンシャル、コンカレント、グループチャット、ハンドオフ、マゼンティックの5つで、どれを選ぶかによって待ち時間と費用の出方も変わります。

シーケンシャル

シーケンシャルは、決められた順にエージェントをつなぐパターンです。前のエージェントの出力を次が受け取り、専門化した処理のパイプラインを作ります。次に呼ばれるエージェントはワークフローの一部として決まっており、エージェント側が選ぶわけではありません。

段階的に品質を上げていく作業に向きます。下書き、レビュー、仕上げのように依存関係が明確な流れが典型です。前半で誤りが出ると後段まで伝わるため、累積した誤りを止める手立てがない場合は避けるよう説明されています。

コンカレント

コンカレントは、同じ入力を複数のエージェントが同時に処理するパターンです。各エージェントが独立した観点から分析し、結果を集約します。エージェント同士が結果を受け渡すことはありません。

同じ問題に対して複数の視点が必要な場面や、並列化で待ち時間を縮めたい場面に向きます。集約の方法は、多数決、重み付けの統合、要約による調整などをタスクに合わせて選びます。結果が矛盾したときの解決方針を決めないまま採用すると、集約の段階で行き詰まってしまうため、先に方針を置いてください。

グループチャット

グループチャットは、共有された会話の場に複数のエージェントが参加し、議論を通じて結論に近づくパターンです。チャットマネージャーが次に発言するエージェントを決めて進行を管理します。人が観察者として加わったり、進行役を引き受けたりできる形でもあります。

派生として、作成役と検査役を分けるメーカーチェッカーのループがあります。検査役が定めた条件で結果を評価し、不足があれば具体的な指摘とともに作成役へ戻します。受け入れ基準を明確にし、繰り返しの上限を決めておくことが前提です。同ガイダンスは、制御を保つためにエージェント数を3体以下に抑えることも挙げています。

ハンドオフ

ハンドオフは、手元のタスクを自分で処理するか、より適したエージェントに渡すかを各エージェントが判断するパターンです。並列には動かず、1体から次の1体へ制御が完全に移ります。

最適なエージェントが事前には分からず、処理の途中で必要な専門性が判明する場面に向きます。振り分け先が決定的なルールで決まるなら、このパターンではなく単純な振り分けで足ります。行き先が往復し続ける状態を防ぐ設計も欠かせません。

マゼンティック

マゼンティックは、進め方を事前に決められない問題に向けたパターンです。マネージャー役のエージェントがタスクの台帳を作り、専門エージェントと相談しながら計画を組み立て、進行を追跡します。

外部システムへ変更を加えるツールを持つエージェントが関わる場面で、実行の前に人が計画を確認できる点が特徴です。収束が遅く、目標が曖昧だと停滞しやすいため、時間の制約が厳しい処理には向きません。

パターン	進み方	経路の決まり方	向いている場面
シーケンシャル	直列につないで順に処理する	事前に決めた順序	依存関係が明確な段階的改善
コンカレント	同じ入力を並列で処理する	事前指定または動的な選択	複数視点の独立した分析
グループチャット	共有の会話で議論する	マネージャーが発言順を管理	合意形成、作成と検査の反復
ハンドオフ	1体ずつ制御を引き継ぐ	エージェントが移す時期を決める	処理中に専門性が判明する業務
マゼンティック	計画を組みながら実行する	マネージャーが動的に割り当て	解き方が事前に決まらない問題

参考：AI エージェントオーケストレーションパターン（Microsoft Azure Architecture Center）

業務から種類を選ぶ3つの判断材料

種類は、業務側の条件から決めるのが実務的な順序です。完了条件が書けるか、手順が固定か変動か、実行の影響がどこまで及ぶか。この3点を確認すると、自律度、構成、内部構造の3軸がそれぞれ決まります。

完了条件が書けるか

完了条件が言葉で書けるかどうかで、目標を渡せる種類かが分かれます。何をもって終わりとするかを定義できない業務は、目標ベース以上の形に載せても成否を評価できません。

書ける場合は、目標を渡して手順を任せる形に進めます。書けない場合は、判断の分岐を固定した処理として切り出すところから始めるほうが早く、単純反射型に近い設計で足ります。完了条件は、件数や状態のように後から確認できる言葉にしておきましょう。担当者の感覚に依存した表現のままでは、評価の場面で必ず揺れが生じます。

手順が固定か変動か

手順が毎回同じかどうかで、自律度の段階が決まります。固定なら段階2のワークフロー型で足り、案件ごとに手順が変わるなら段階3以上で判断を任せる形が必要になります。

判断の材料になるのは、過去の処理履歴です。同じ入力から同じ手順で終わっている業務は固定と見なせます。例外処理が一定割合で混ざる業務なら、例外だけを人に回す設計にしておくと、自律度を上げても安全に運用できます。

実行の影響範囲

実行の影響がどこまで及ぶかで、承認を挟む位置が決まります。読み取りだけで終わる処理と、外部システムへ書き込む処理では、同じ業務でも設計が変わります。

書き込みや送信を含む場合は、その操作だけに承認のゲートを置く形が現実的です。読み取りと下書きの作成までを自律で進め、確定の操作だけ人が押す形にすれば、待ち時間と統制の両方が折り合います。影響範囲の線引きは、種類の選定というより権限の設計に近い作業です。

業務の性質	内部構造の目安	自律度の目安	構成の目安
分岐が固定された一次対応	単純反射型	段階2	単体
状態が時間で変化する管理業務	モデルベース反射型	段階3	単体
複数手順を経て完了する処理	目標ベース	段階3から4	単体
条件が競合する調整業務	効用ベース	段階3	単体またはマルチ
部門や専門領域をまたぐ調査	目標ベースに学習を付加	段階3から4	マルチ
定時や検知で起動する定型処理	モデルベース反射型	段階5	単体

3軸が決まると、製品に確認する項目も具体化します。段階4以上を想定するなら承認のゲートを操作の単位で設定できるか、マルチを想定するなら連携のパターンをどこまで選べるか。この2つを聞くだけで、資料の読み比べより早く候補が絞れます。

この表は目安であり、同じ業務名でも社内の運用によって当てはまる行は変わります。たとえば同じ請求書の照合でも、金額の相違を担当者が判断している職場なら段階3が妥当で、判定の基準が規程として決まっている職場なら段階4まで上げられます。表を見るときは業務名ではなく、判断がどこまで文書化されているかを手がかりにしてください。

種類の見分けで起きやすい3つの誤解

種類の理解でつまずくのは、分類名の暗記ではなく分類の使い方です。検討の現場で繰り返し見かける誤解を3つ挙げます。

マルチエージェントほど高性能とは限らない

複数構成が単体より優れているという理解は、実際の設計とずれています。エージェントを増やすほど、調整の負荷と待ち時間、モデル呼び出しの費用が積み上がります。

Microsoftのガイダンスは、意味のある専門化を提供しないエージェントの追加を落とし穴として挙げ、単純なパターンで足りる場面で複雑なパターンを採用しないよう促しています。まず単体で試し、1体では確実に処理できない理由が言えるようになってから広げる順序が安全です。

自律型という表記は自律度を保証しない

製品名や資料にある自律型という表記だけでは、どの段階に当たるかは判断できません。承認をどこに置けるか、起動の条件を何で定義できるかを確かめないと、運用の姿は見えてきません。

確認したい点は3つあります。実行の前に承認を挟めるか、承認を操作の単位で設定できるか、動作の記録を後から追えるか。この3つが揃っていれば、運用しながら段階を上げていける製品だと判断できます。

分類は厳密な線引きではなく設計思想の物差し

実際の製品は、内部構造の5分類のどれか1つに収まるわけではありません。学習の仕組みを持つ目標ベースの形のように、複数の性質を組み合わせて設計されています。

分類の役目は、その製品や構成がどの性質を重く見て設計されているかを見分けることです。自社の業務がどの性質を必要としているかを先に決めておけば、資料を読み比べる段階で迷いにくくなります。生成AIの基礎から確認したい場合は、関連記事もあわせてご覧ください。

よくある質問

AIエージェントの種類について、検討の初期に挙がりやすい質問をまとめました。

AIエージェントの種類はいくつに分けられますか

分類の軸によって数が変わります。内部構造では単純反射型、モデルベース反射型、目標ベース、効用ベース、学習エージェントの5つ、構成では単体とマルチエージェントの2つに分かれます。自律度は人が承認を挟む位置で段階が変わるため、固定の数ではありません。

マルチエージェントは単体のAIエージェントより性能が高いのですか

構成の違いは性能の順位ではありません。Microsoftのアーキテクチャガイダンスは、ツールを使う単体エージェントを企業のユースケースで適切な既定値とし、要件を満たす最も低い複雑さを選ぶよう勧めています。1体で確実に処理できない理由が明確な場合にマルチを選びます。

古典的な5分類は実際の製品のどれに当てはまりますか

多くの製品は複数の性質を組み合わせているため、1対1では対応しません。分類は製品を仕分けるためではなく、その製品がどの性質を重く見て設計されているかを見分けるために使います。自社の業務が必要とする性質を先に決めておくと判断しやすくなります。

どの種類から導入を始めるのがよいですか

完了条件が言葉で書ける業務を1つ選び、単体エージェントで実行前に人が承認する形から始める進め方が現実的です。運用が安定してから、影響の小さい操作だけ承認を外す、対象を広げる、といった順に段階を上げていきます。

まとめ

AIエージェントの種類は、内部構造、自律度、構成の3軸で整理すると混乱しません。内部構造は単純反射型からモデルベース反射型、目標ベース、効用ベース、学習エージェントまでの5分類で、AI分野の標準的な教科書で扱われてきた整理です。自律度は人がどこで承認を挟むかで段階が分かれ、構成は単体とマルチエージェントに分かれます。

マルチエージェントを選ぶ場合は、シーケンシャル、コンカレント、グループチャット、ハンドオフ、マゼンティックのどのパターンで組むかまで含めて設計します。要件を満たす最も低い複雑さから始める順序が、費用と運用の両面で無理がありません。

自社に当てはめるときに見るのは、完了条件が書けるか、手順が固定か変動か、実行の影響がどこまで及ぶかの3点です。ここが決まれば3軸はほぼ自動的に決まります。最初の1つを選ぶ段階で判断がつかない場合は、お問い合わせからご相談ください。AI導入・コンサルティングおよびIT・DX分野で累計40社以上の導入事例をもとに、対象業務の選定から承認設計までご一緒します。