AIエージェント設計パターン7選 — ReActからマルチエージェントまで

「AIエージェントを導入したい」と言われたとき、最初に確認すべきは製品名ではなく、誰が処理順を決めるのかです。コードが決めるならワークフロー、LLMが観測結果を見て次の行動を決めるならエージェントです。両者を混同すると、定型処理に高価な自律性を足したり、探索が必要な仕事を硬いフローに押し込めたりします。

この記事では、代表的な構成を7つに分け、選択基準を比較します。結論から言えば、固定フローから始め、評価で必要性を示せた部分だけ自律化するのが本番への最短距離です[1]。

まずワークフローとエージェントを分ける

種類	処理順を決める主体	得意な仕事	主なリスク
固定ワークフロー	アプリケーションコード	手順が既知、監査が必要	例外への弱さ
エージェント	LLM	手順が未知、探索が必要	暴走、累積誤差、費用
ハイブリッド	コードとLLM	現実の業務システム	境界設計の難しさ

自律性は能力ではなく権限です。検索結果を読むだけのエージェントと、顧客データを更新できるエージェントでは、同じモデルでも事故半径が違います。設計では「考えられるか」より先に「何を実行できるか」を決めます。

1〜3: 固定経路で品質を上げるパターン

1. プロンプト連鎖

タスクを「抽出→検証→文章化」のような固定ステップに分けます。各呼び出しが単純になり、中間出力を型検証できるのが強みです。翻訳、帳票処理、記事生成など、工程を先に書ける仕事に向きます。途中の形式は構造化出力パターンで固定します。

2. ルーティング

入力を分類し、問い合わせ、障害対応、返金などの専門フローへ振り分けます。分類結果には信頼度とunknownを持たせ、曖昧な入力を無理に送らないことが重要です。軽い質問を小さいモデルへ、難問を高性能モデルへ送るコスト制御にも使えます。

3. 並列化と投票

独立した調査を同時実行する「分割」と、同じ問題を複数回解いて集約する「投票」があります。速度や再現率を上げられる一方、呼び出し回数は増えます。セキュリティ、事実性、文章品質を別々の評価器で確認する構成は、1回の巨大プロンプトより原因を追いやすくなります[1]。

4〜6: ループで探索するパターン

4. ReAct型ツールループ

LLMが状況を判断し、ツールを呼び、結果を観測して次の行動を決めます。ReActは推論と行動を交互に扱う枠組みとして提案されました[2]。現代のツール呼び出しAPIでは、内部の思考文を保存するのではなく、tool_callと結果、最終回答をイベントとして記録するのが実装しやすい形です。

適するのは、必要な検索やAPIが質問ごとに変わる仕事です。停止条件、最大ステップ、許可ツール、引数検証がないループは本番に出せません。最小実装はPythonで作るツール実行ループで扱います。

5. 計画実行(Planner–Executor)

最初に計画を作り、実行器が各ステップを処理します。長い仕事の進捗が見えやすく、ステップ単位で再実行できます。ただし計画を守りすぎると、環境が変わっても古い手順を続けます。「3ステップごと」「ツールエラー時」など再計画の条件を決めます。

6. 評価改善(Evaluator–Optimizer)

生成役と評価役を分け、基準を満たすまで改善します。翻訳、コード、調査のように良否を説明できる仕事に向きます。Reflexionは失敗から言語的なフィードバックを作り、次の試行へ反映する考え方を示しました[3]。評価器もLLMなら誤るため、テスト、型、検索の正解データなど決定的な信号を優先します。

7: オーケストレータとマルチエージェント

中央のオーケストレータがタスクを分解し、専門ワーカーへ委譲して結果を統合します。サブタスクが事前に分からないコード変更や、多方面の調査に向きます。AutoGenは、役割を持つ複数エージェントの会話でアプリケーションを構成する枠組みを提示しました[4]。

ただし、エージェント数を増やすだけでは賢くなりません。コンテキストの重複、意見のループ、責任の曖昧さが増えます。導入条件は次の3つです。

1. 役割ごとに異なるツール・権限・評価基準がある
2. サブタスクを並列化する価値がある
3. 統合結果を検証する客観的な方法がある

条件を満たさないなら、単一エージェントに複数ツールを持たせる方が安く、追跡も容易です。

選定表: 自律性ではなく不確実性で選ぶ

要件	第一候補	次に試す方式
手順が固定、監査重視	プロンプト連鎖	ルーティング
入力種別が明確	ルーティング	専門ワーカー
独立した観点が必要	並列化	評価改善
呼ぶツールが毎回変わる	ReAct	計画実行
長い探索、途中復旧が必要	計画実行	ReActとの併用
合否基準が明確	評価改善	決定的テストとの併用
未知のサブタスクが多い	オーケストレータ	マルチエージェント

方式を決めたら、成功率だけでなく、1タスク当たりのモデル呼び出し回数、p95遅延、ツールエラー率、人手介入率、権限違反のブロック数を測ります。モデル評価設計と同じく、平均点だけでは運用の危険箇所が隠れます。

まとめ

• AIエージェントの第一の設計変数は、処理順をコードとLLMのどちらが決めるか
• 固定工程は連鎖・ルーティング・並列化で十分なことが多い
• ReAct型には許可ツール、引数検証、最大ステップ、観測ログが必須
• 計画実行は長い仕事、評価改善は合否基準を言語化できる仕事に向く
• マルチエージェントは役割ごとの権限と評価基準が違う場合にだけ採用する
• 評価で改善を確認できた範囲だけ自律性を上げる

次はPythonで作るツール実行ループで、フレームワークに隠れがちな実行・観測・停止の仕組みをコードから確認してください。