AIエージェント設計、なんとなく理解では詰まる

AIエージェントを実務に組み込もうとすると、すぐに壁にぶつかる。「ReActって聞いたことあるけど、Agentic RAGとどう違うの？」「Multi-Agentにすれば解決する？」——こういう会話、最近やたら増えていないだろうか。

アクセンチュア・ジャパン有志によるZenn記事「AI Agentはこう設計する：実務で使える5つのパターンとその限界」は、そのモヤモヤを整理するのに役立つ内容だった。5つの設計パターンを紹介しているのだが、最初に述べている視点が面白い。

「以下の5つのパターンは、同じレイヤーの概念ではありません」

これ、地味に重要な指摘だ。

5つのパターンは「同列ではない」

記事が整理しているパターンはこの5つ。

  1. ReAct（思考・実行ループ）
  2. CodeAct（実行方式）
  3. Agentic RAG（情報取得）
  4. Self-Reflection（品質改善）
  5. Multi-Agent Planner（システム構成）

並べてみると、確かに「どれにしようか」という比較対象ではない。ReActは推論の進め方の話で、CodeActは実行手段の話で、Agentic RAGは情報取得の話だ。それぞれ違う問いに答えている。

同列のものだと思って「ReActかMulti-Agentか」と議論していたとしたら、そもそも問いの立て方がおかしい。ここが、この記事の一番効いている指摘だと思う。

各パターンを具体的に見る

**ReAct（Reasoning + Acting）**は、「思考→行動→観察→再思考」というループを回しながらタスクを進める手法だ。ユーザーから「最新の市場規模を教えて」と質問が来たとき、LLMがまず「最新情報が必要」と判断し、Web検索ツールを呼び出し、結果を取得・要約し、必要なら追加検索して最終回答を生成する——という流れになる。推論プロセスが可視化されるのでトレーサビリティが高い反面、推論チェーンが長くなるとレイテンシが増加するという留保がある。

CodeActは、タスクをコードに変換して実行させるアプローチ。売上データのCSVを分析する場合、LLMがPythonスクリプトを生成し、集計・グラフ作成を実行し、その結果を回答に反映する。自然言語の回答より正確性と再現性が高いが、実行環境への依存度が高く、リスク回避のために隔離された制御環境での実行が求められる。

Agentic RAGは、従来のRAGに主体性を持たせたもの。従来型RAGは「クエリを受けて検索して返す」だが、Agentic RAGは「クエリを分析し、必要に応じて複数回の検索を実行し、重複情報をフィルタリングし、有用性の高い情報をナレッジベースに書き戻す」ところまでやる。事実性・一貫性・コンテキスト制御の面で従来型より優れているとされ、社内ナレッジQ&Aや最新情報の参照に向いている。

Self-Reflectionは、モデルが初稿を生成した後、自らレビュー・評価して問題点を修正し、改訂版を出す手法だ。幻覚や推論ミスの発生確率を下げられる一方、計算コストと応答レイテンシが増加する。精度が強く求められる場面——高精度レポートやコードレビューなど——に適している。

Multi-Agent Plannerは、大規模タスクを複数のサブタスクに分解し、異なるエージェントに割り当て、結果を統合するアプローチ。市場調査レポートなら「Agent Aがデータ収集、Agent Bが競合分析、Agent Cがトレンド分析、Agent Dが統合」という分業が成立する。拡張性が高い反面、アーキテクチャが複雑になりやすく、コストとレイテンシが増加しやすいという欠点がある。

「組み合わせる前提」で設計する

記事の締めくくりにあるこの一文が、全体の核心を突いている。

「重要なのは、どれを使うかではなく、どう組み合わせるかです」

実際、記事ではこんな組み合わせ例が示されている。

  • ReAct + Agentic RAG → ナレッジ検索型Agent
  • ReAct + CodeAct → 実行特化型Agent
  • ReAct + Self-Reflection → 高信頼Agent
  • ReAct + RAG + Reflection → 高精度QA
  • Multi-Agent + 各種パターン → 分散協調システム

ReActがほぼ全ての組み合わせに入っているのは偶然ではない。「思考して行動する」という基本ループは、どの目的のエージェントにも必要な土台だからだ。その上に、何を実行するか（CodeAct）、どう情報を取るか（Agentic RAG）、どう品質を担保するか（Self-Reflection）、どうスケールさせるか（Multi-Agent）を重ねていく、という設計の考え方が見えてくる。

実務への示唆

この整理が実務で役立つのは、「どこで詰まっているか」を診断しやすくなる点だ。

  • 回答の品質が安定しない → Self-Reflectionの問題
  • 必要な情報が取れていない → Agentic RAGの問題
  • 大きなタスクが処理できない → Multi-Agentの構成問題
  • 数値計算や分析がズレる → CodeActで実行させる問題

こういう切り分けができると、「とりあえずモデルを替えてみる」という無駄な試行を減らせる。問題がどのレイヤーにあるかを先に特定してから、対応するパターンを当てる——この順序で考えることが重要だ。

もちろん、各パターンにはトレードオフがある。レイテンシ、コスト、環境依存、設計の複雑性——どれも無視できない。精度を上げれば遅くなるし、スケールさせれば複雑になる。そこは用途とのバランスで判断するしかない。

AIエージェント設計の話は、まだ「なんとなく動いた」レベルで語られることが多い。でもこうしたレイヤー別の整理を持っておくと、設計の議論がずいぶんクリアになる。少なくとも、パターン名を並べて「どれにしようか」という不毛な比較からは抜け出せる。