n8n
ReAct / Plan-and-ExecuteノーコードでReAct・Plan-and-Executeを構築可能。AIエージェントノードで即座にプロトタイピングできる。
エンタープライズ対応: セルフホスト対応、閉域網運用可能。CoE（Center of Excellence）での標準化に最適。
制約: 複雑なMulti-Agent間の動的通信は別途設計が必要。
02 / 04AIエージェント入門シリーズ
アーキテクチャパターン
ReAct・Plan-and-Execute・Multi-Agent
AIエージェントのアーキテクチャパターンとは、LLMの推論・行動・協調を制御する設計方式です。エンタープライズ導入では、ReAct・Plan-and-Execute・Multi-Agent・Supervisorの4パターンが主流であり、タスクの複雑さ・品質要求・ガバナンス要件に応じて選定します。本ガイドでは、各パターンの動作原理・選定基準・実装ツールを、n8n・LangGraphの実装アプローチとともに解説します。
最終更新: 2026年2月·読了時間: 約12分·対象: テックリード・アーキテクト・DX推進部門
目次
なぜアーキテクチャパターンが重要か
AIエージェントは「LLMにツールを渡せば動く」ほど単純ではありません。同じLLM・同じツールセットでも、推論と行動の制御方式（アーキテクチャパターン）によって、タスクの成功率・処理速度・コストが大きく変わります。
homulaがエンタープライズ400社超の導入支援で得た知見によると、PoCが本番化に至らない原因の約40%はアーキテクチャ選定のミスマッチに起因します。単純なタスクに重厚なMulti-Agentを適用してコストが合わない、あるいは複雑な業務をReActで無理に処理して品質が安定しない——どちらも「パターン選定」の問題です。
正しいパターンを選定することで、プロトタイプ構築の期間を最短5日に短縮しつつ、本番化への移行コストを最小化できます。本ガイドでは、各パターンの動作原理を理解したうえで、自社の業務要件に最適なパターンを選定するためのフレームワークを提供します。
4つのパターン概観
エンタープライズで実績のある4つのアーキテクチャパターンを、シンプルなものから順に解説します。
Complexity Spectrum
低ReAct— 思考→行動→観察のループ
中Plan-and-Execute— 計画→段階的実行→再計画
高Multi-Agent— 専門エージェントの協調
高Supervisor— 監督者による統括・品質管理
原則: 最もシンプルなパターンで始め、要件に応じてスケールアップする
ReAct（Reasoning + Acting）
複雑さ: 低考えて、動いて、観察する
LLMが「推論（Reason）→ 行動（Act）→ 観察（Observe）」を1ステップずつ繰り返すパターンです。最もシンプルかつ汎用性が高く、単一エージェントの基本形として広く採用されています。
動作メカニズム
ユーザーの指示を受け取ったLLMが、まず「何をすべきか」を推論し、次に外部ツール（API呼び出し、DB検索等）を実行し、その結果を観察して次のアクションを決定します。この思考→行動→観察のループを、タスクが完了するまで反復します。
Example Flow — ReAct（Reasoning + Acting）
Thoughtユーザーの注文状況を確認する必要がある
Action注文管理APIに注文番号を問い合わせ
Observationステータス: 配送中、到着予定: 2月25日
Thought配送追跡URLも取得すべき
Action配送業者APIに追跡番号を問い合わせ
Observation追跡URL取得完了
Answerご注文は現在配送中で、2月25日到着予定です。追跡URLはこちらです。
適したユースケース
- ツール呼び出しが3〜5回程度の単一タスク
- カスタマーサポートの一次対応
- 社内FAQの検索・回答
- データ取得→整形→返答の定型フロー
限界・注意点
- 10ステップ以上の複雑なタスクではループが発散しやすい
- 事前に全体計画を立てないため、非効率な試行錯誤が発生する
- エラー発生時のリカバリーが場当たり的になりがち
主な実装ツール: n8n（AI Agentノード）、LangChain ReAct Agent、OpenAI Function Calling
Plan-and-Execute
複雑さ: 中計画してから、実行する
最初にタスク全体の計画（サブタスクへの分解）を立ててから、各ステップを順次実行するパターンです。ReActの「走りながら考える」アプローチに対し、「考えてから走る」ことで複雑なタスクの成功率を高めます。
動作メカニズム
Plannerモジュールがユーザーの指示を分析し、完了に必要なサブタスクのリストを生成します。Executorモジュールが各サブタスクを順次実行し、結果をPlannerにフィードバック。必要に応じてPlannerが残りの計画を修正する「Re-plan」機能を持つ実装が一般的です。
Example Flow — Plan-and-Execute
Plan①競合3社のIR情報を取得 → ②売上・利益率を抽出 → ③比較表を作成 → ④サマリーを執筆 → ⑤レビュー
Execute①Web検索APIで競合A社・B社・C社のIR資料URLを取得
Execute②各PDFから売上高・営業利益率・従業員数を抽出
Re-planC社のIRが未公開 → 代替として決算短信から推計する計画に修正
Execute③比較表をMarkdown形式で生成
Execute④⑤サマリー執筆 → ファクトチェック → 完成
適したユースケース
- 5〜15ステップの複数工程タスク
- 調査レポートの作成（情報収集→分析→構成→執筆）
- データパイプラインの構築と実行
- 複数システムを横断する業務プロセスの自動化
限界・注意点
- 初期計画の精度がタスク全体の品質を左右する
- 計画フェーズのトークン消費が大きい
- リアルタイム性が求められるタスクには不向き
主な実装ツール: LangGraph Plan-and-Execute、n8n + サブワークフロー分岐、Dify ワークフロー
Multi-Agent（マルチエージェント）
複雑さ: 高専門家チームで協働する
役割の異なる複数のエージェントが協調して1つの目標を達成するパターンです。リサーチ担当・執筆担当・レビュー担当のように専門性を分離することで、単一エージェントでは困難な高品質の出力を実現します。
動作メカニズム
各エージェントが独自のシステムプロンプト・ツールセット・メモリを持ち、メッセージパッシングで連携します。エージェント間の通信はグラフ構造で定義され、順次実行・並列実行・条件分岐などのフロー制御が可能です。
Example Flow — Multi-Agent（マルチエージェント）
Researcher市場データと競合情報を収集・整理
Analyst収集データをもとに財務分析と市場動向レポートを作成
Writer分析結果を経営層向けのプレゼン資料に変換
Reviewerファクトチェック・論理整合性を検証し、修正指示を出す
Writerフィードバックを反映し最終版を出力
適したユースケース
- 品質要求の高い業務（契約書レビュー、技術文書作成）
- 部門横断プロセス（営業→法務→経理の承認フロー）
- 複雑な分析（市場調査 + 財務分析 + 戦略提言）
- Human-in-the-Loopが必要なワークフロー
限界・注意点
- エージェント間通信のオーバーヘッドが大きい
- デバッグの難易度が高い（どのエージェントが誤ったか特定しにくい）
- 全体のコスト（トークン消費量）がパターン中最大
主な実装ツール: LangGraph Multi-Agent、AutoGen、CrewAI、n8n + 複数AIエージェントノード
Supervisor（監督者パターン）
複雑さ: 高マネージャーがチームを統括する
マルチエージェントの発展形で、監督者（Supervisor）エージェントがタスクの割り振り・進捗管理・品質検証を統括するパターンです。人間の組織構造に最も近く、エンタープライズでの全社展開に適しています。
動作メカニズム
Supervisorエージェントがユーザーの指示を受け取り、タスクを分解して最適なワーカーエージェントに割り振ります。各ワーカーの出力をSupervisorが検証し、品質基準を満たさない場合は差し戻し・再実行を指示します。Supervisorがすべてのコミュニケーションのハブとなるため、ガバナンスと監査が容易です。
Example Flow — Supervisor（監督者パターン）
Supervisor「月次経費レポート作成」を受領し、3つのサブタスクに分解
→ Worker A経費データをERPから抽出・集計
→ Worker B部門別の予算消化率を計算・異常値を検出
→ Worker Cレポートを指定テンプレートで生成
SupervisorWorker Bの異常値フラグを検証 → 閾値超の項目をHuman-in-the-Loopに回付
Human承認 → Supervisorが最終レポートを確定
適したユースケース
- 全社展開で複数部門が関わる大規模ワークフロー
- ガバナンス・監査要件が厳格な業務
- 品質管理にHuman-in-the-Loopを組み込む必要がある業務
- 動的にワーカーの追加・削除が必要な業務
限界・注意点
- Supervisorのプロンプト設計が全体の品質を決定する
- Supervisorがボトルネックになりやすい（スケーラビリティの課題）
- 初期設計・テストの工数が最も大きい
主な実装ツール: LangGraph Supervisor、Agens Control、n8n + ルーティングロジック
選定マトリクス
6つの判断軸でパターンを比較します。自社の業務要件を各軸に当てはめ、最も適合するパターンを選定してください。
| 判断軸 | ReAct | Plan & Execute | Multi-Agent | Supervisor |
|---|---|---|---|---|
| タスクの複雑さ | 単純（3-5ステップ） | 中程度（5-15ステップ） | 複雑（部門横断） | 大規模（全社規模） |
| 品質要求 | 標準（FAQ回答等） | 中〜高（レポート等） | 高（契約書等） | 最高（監査対応等） |
| レイテンシ要件 | 数秒（リアルタイム可） | 数十秒〜数分 | 数分〜数十分 | 数分〜数十分 |
| トークンコスト | 低 | 中 | 高 | 高〜最高 |
| 実装難易度 | 低（1-2日） | 中（3-5日） | 高（1-2週） | 最高（2-4週） |
| ガバナンス対応 | 限定的 | 中程度 | 可能（設計次第） | 最適（監査ログ統合） |
※ Supervisorパターンのハイライトは、エンタープライズの全社展開フェーズで最も推奨される選択肢であることを示しています。
実装ツール比較
各アーキテクチャパターンを実装する際に選択肢となる主要ツールを、エンタープライズ要件の観点で比較します。homulaは特定ツールに依存しない「コンポーザブルAI」のアプローチを採り、要件に応じて最適な組み合わせを設計します。
LangGraph
Multi-Agent / Supervisorグラフ構造でエージェント間の通信を精密に制御。状態管理・チェックポイント・Human-in-the-Loopを標準サポート。
エンタープライズ対応: Pythonベースのため開発者スキルが必要。高度なカスタマイズに対応。
制約: ノーコードではないため、内製化には開発チームが必要。
Dify
Plan-and-Execute / ReActワークフローエディタでPlan-and-Executeを視覚的に構築。RAGパイプラインとの統合が容易。
エンタープライズ対応: Docker対応でセルフホスト可能。ただし大規模運用にはチューニングが必要。
制約: Multi-Agent・Supervisorパターンの構築には制約あり。
Agens
ReAct（自動）/ Supervisor（Control）構築ゼロ（Build-less）でReAct相当の処理を自然言語指示のみで実行。フロー設計不要。
エンタープライズ対応: MCP Hub経由で200+ツールと即座に接続。Agens Controlで監査ログ・権限管理・DLPをカバー。
制約: 高度なカスタムMulti-Agentフローは個別設計が必要。
エンタープライズ導入の実践ガイドライン
1. 最小パターンで開始し、段階的にスケールアップする
PoCフェーズではReActで動作するプロトタイプを最短5日で構築します。本番要件が明確になった時点でPlan-and-Executeに移行し、全社展開フェーズでSupervisorパターンを導入するのが、コストとリスクの両面で最適なアプローチです。最初からMulti-Agentを設計すると、PoC段階で過剰なコストが発生し、経営層の投資判断を遅らせます。
2. パターン移行を前提としたアーキテクチャを設計する
ReActで始めたエージェントを後からPlan-and-ExecuteやMulti-Agentに移行できるよう、ツール呼び出しのインターフェースとメモリ層を標準化しておくことが重要です。MCP（Model Context Protocol）を採用すると、ツール接続が標準化され、パターン移行時の再実装コストを最小化できます。
3. 監査可能性をDay 1から組み込む
すべてのパターンにおいて、エージェントの思考ログ（Reasoning Trace）・ツール呼び出しログ・最終出力を記録する設計をPoCフェーズから組み込んでください。パターンの複雑さが増すほど「なぜその判断をしたか」の追跡が困難になります。Agens ControlやLangGraphのチェックポイント機能を活用することで、監査対応を効率化できます。
よくある質問
ツール呼び出しが5回以下のシンプルなタスクにはReAct、5回以上の複数工程タスクにはPlan-and-Executeが適しています。ReActは即応性に優れますが、複雑なタスクでは非効率な試行錯誤が発生します。Plan-and-Executeは事前計画により成功率が高まりますが、計画フェーズの分だけ初期レイテンシが増えます。迷ったらReActで始め、品質が不足する場合にPlan-and-Executeに移行するのが実践的なアプローチです。
Multi-Agentはエージェント間が対等に通信するピアツーピア型です。Supervisorパターンは監督者エージェントがハブとなり、タスク割り振り・品質検証・進捗管理を一元的に行います。エンタープライズでは監査ログの一元管理やガバナンス要件からSupervisorパターンが推奨されます。homulaのAgens Controlは、このSupervisorパターンをエンタープライズグレードで実現するコントロールレイヤーです。
「最もシンプルなパターンで始める」が鉄則です。初期のPoCにはReActで十分であり、業務要件が明確になった段階でPlan-and-Executeに移行します。全社展開フェーズでガバナンスが必要になった時点でSupervisorパターンを導入するのが、コスト効率とリスク管理の両面で最適です。homulaのブートキャンプでは、5日間でReActのプロトタイプを構築し、本番移行の設計書にはスケールアップ後のパターン移行計画も含めます。
n8nはノーコードでReAct・Plan-and-Executeを素早く構築でき、CoE（Center of Excellence）での標準化に適しています。LangGraphはPythonベースでMulti-Agent・Supervisorパターンの精密な制御が可能で、高度なカスタマイズが求められる場合に選択します。homulaは「コンポーザブルAIアーキテクト」として、要件に応じてn8n・LangGraph・Dify・Agensを最適に組み合わせ、特定ツールにロックインしない設計を提供します。
実際のエンタープライズ運用ではパターンの組み合わせが一般的です。例えば、Supervisorパターンの各ワーカーがReActやPlan-and-Executeで動作する多層構造や、フロントエンドはReActで即応しつつバックグラウンドでPlan-and-Executeの長時間タスクを非同期実行する構成があります。重要なのはパターンの純粋性ではなく、業務要件に合った制御レベルを選択することです。