AIエージェントのアーキテクチャ設計パターン

LLMを使ったアプリケーション開発は、すでに多くの現場で行われています。チャットボット、文書要約、コード生成、データ分析の補助。これらの多くは「LLMにプロンプトを渡し、応答を受け取る」という単純な構造で動作しています。

しかし、タスクが複雑になるにつれて、この「1回のLLM呼び出し」では対応しきれない場面が増えてきます。複数のデータソースから情報を収集する、段階的に分析を深める、外部ツールを組み合わせて結果を返す。こうした要件に対して、「LLMを中核に、自律的に推論・判断・行動を繰り返すシステム」としてAIエージェントを設計するアプローチが注目されています。

本記事では、AIエージェントの基本アーキテクチャを構成する4つの要素を整理し、それぞれの設計パターンと判断基準を解説します。「LLMを呼ぶだけ」のシステムから「エージェントとして設計する」システムへの転換を、実務レベルで理解することを目指します。

AIエージェントのアーキテクチャは、以下の4つの構成要素で整理できます。

以下、各構成要素ごとに設計パターンと判断のポイントを掘り下げます。

推論ループは、AIエージェントの中核です。「観察する→考える→行動する→結果を評価する→次の行動を決める」というサイクルを繰り返すことで、単発の応答ではなく、段階的にタスクを遂行するシステムが成立します。

ReActは、最も基本的かつ広く採用されている推論ループのパターンです。LLMが「思考（Thought）」を言語化し、次に「行動（Action）」を決定し、行動の「結果（Observation）」を受け取って次の思考に進む。このThought → Action → Observationのサイクルをタスクが完了するまで繰り返します。

ReActの最大の強みは透明性です。LLMが「なぜその行動を選んだか」の推論過程が明示的にログに残るため、デバッグや品質改善が行いやすい。一方で、各ステップでLLM呼び出しが発生するため、ステップ数が増えるとレイテンシーとコストが累積します。

OpenAIのFunction CallingやAnthropicのTool Useに代表されるパターンです。LLMが「次にどのツールを、どんな引数で呼ぶか」を構造化された形式（JSON）で出力し、システムがそのツールを実行して結果をLLMに返す。

ReActとの違いは、推論と行動の境界がAPI仕様として明確に定義されている点です。ReActはLLMの自由記述に依存するため、出力のパースに失敗するリスクがありますが、Function Callingは出力形式が構造化されているため、システム実装がより堅牢になります。

多くのプロダクション環境では、ReActの思考プロセスとFunction Callingの構造化された実行を組み合わせたハイブリッドなアプローチが採用されています。

LLMの推論に全面的に委ねるのではなく、あらかじめ定義した状態遷移（ステートマシン）に基づいてエージェントの行動を制御するパターンです。LangGraphがこのアプローチを採用しています。

各状態（ノード）でLLMを呼び出し、その結果に応じて次の状態に遷移する。遷移のルールは開発者が明示的に定義するため、LLMの「予想外の行動」を制御しやすい。一方で、状態遷移の設計が必要なため、柔軟性はReActに劣ります。

実務上の判断基準：タスクの流れが比較的固定的で、品質と制御性を重視する場合はステートマシン型。タスクの流れが動的で事前に予測しにくい場合はReAct型。多くの実務プロジェクトでは、ステートマシンの骨格にReActのノードを組み込むハイブリッドが現実的です。

LLM単体は、テキストの生成・理解には優れていますが、「外の世界」に対する操作はできません。API呼び出し、データベース検索、ファイル操作、計算実行。これらの機能をツール（Tool）としてエージェントに統合することで、エージェントが実世界のタスクを遂行できるようになります。

原則1：1ツール1責務。1つのツールが担う責務は1つに限定します。「データベースを検索して結果をCSVに書き出す」は1つのツールではなく、「データベース検索」と「CSV書き出し」の2つに分離する。ツールの粒度が細かいほど、LLMが正確にツールを選択できます。

原則2：明確な説明文。ツールの名前と説明文（description）は、LLMがツールを選択する際の唯一の手がかりです。「search」ではなく「Search the product database by product name or category and return matching items with prices」のように、入力・出力・用途を明確に記述します。ツール設計の品質の大部分は、この説明文の精度で決まります。

原則3：エラーハンドリングをツール側で処理する。ツールの実行が失敗した場合に、その失敗をLLMに理解可能な形で返す設計が重要です。Pythonの例外メッセージをそのまま返すのではなく、「検索結果が0件でした。別のキーワードで試してください」のような、LLMが次の行動を判断できる形式で返します。

エージェントに統合するツールの数は、パフォーマンスに直接影響します。ツールが多すぎると、LLMはどのツールを選ぶべきか迷い、誤ったツール選択の確率が上がります。一般的に、1つのエージェントに統合するツールは5〜10個程度が実務的な上限です。

ツール数が10を超える場合は、エージェントを分割して複数のエージェントにツールを分散させるアプローチが有効です。ここで本記事の設計論は、ID1（マルチエージェント設計）につながります。

LLM自体にはセッションをまたいだ記憶がありません。AIエージェントが複数ステップのタスクを遂行するには、過去の行動結果や対話の文脈を保持する仕組み、つまりメモリの設計が必要です。

現在のタスク実行中に発生する情報を保持する仕組みです。推論ループの各ステップの結果、ツール呼び出しの出力、中間的な分析結果。これらをコンテキストウィンドウ内に保持し、次のステップの判断材料とします。

短期メモリの設計で最も重要な判断は、コンテキストウィンドウの管理戦略です。タスクが進むにつれてコンテキストは膨張し、LLMのトークン上限に達するリスクがあります。要約による圧縮、古い情報の選択的な削除、重要度に基づく優先度管理など、プロジェクトの特性に応じた戦略を設計します。

セッションをまたいで持続する記憶です。ユーザーの過去の対話履歴、学習したパターン、蓄積された知識。ベクトルデータベース（Pinecone、Weaviate等）を用いてエンベディングとして保存し、関連性の高い記憶をリトリーブする設計が一般的です。

長期メモリの設計判断として押さえるべき点は以下です。

• 何を記憶するか：すべてのやりとりを保存するのか、重要な事実だけを抽出するのか。保存量とリトリーブ精度のトレードオフ
• いつ記憶を呼び出すか：毎回のLLM呼び出しでリトリーブするのか、特定の条件下でのみ呼び出すのか。リトリーブの頻度はコストとレイテンシーに影響
• 記憶の鮮度管理：古い情報の減衰や更新の仕組み。長期間のエージェント運用では、古い記憶が新しい判断を歪めるリスクがある

単純なタスク（1回のツール呼び出しで完結するもの）であればプランニングは不要ですが、複雑なタスクに対しては「まず全体を計画し、段階的に実行する」能力がエージェントに求められます。

タスク開始時にLLMが全体の実行計画を立て、その計画に沿って順番にステップを実行するパターンです。計画の変更はステップの実行結果に応じて行いますが、基本的には事前の計画をベースに進行します。

メリットは実行の見通しが立ちやすいこと。デメリットは、事前の計画が誤っていた場合に修正コストが大きいこと。タスクの構造が比較的安定しており、事前に見通せる場合に適しています。

各ステップの実行結果を踏まえて、計画を動的に修正するパターンです。事前計画型に比べて柔軟性が高く、予想外の結果にも対応できます。一方で、計画の修正にLLM呼び出しが追加で必要になるため、コストは増加します。

実務上の判断基準：タスクの不確実性が低い（情報収集→分析→レポート等の定型フロー）場合は事前計画型。不確実性が高い（ユーザーの質問に応じて調査方針が変わる等）場合は動的再計画型。多くのプロダクションシステムでは、大枠の計画を事前に立て、ステップごとの微調整を動的に行うハイブリッドが採用されます。

明示的な計画を立てず、各ステップでLLMが「次に何をすべきか」をリアクティブに判断するパターンです。最もシンプルですが、タスクが複雑になると効率が悪く、同じ処理を繰り返すループに陥るリスクがあります。

シンプルなQ&Aエージェントや、ステップ数が少ないタスクにはReactive型で十分です。5ステップ以上の複雑なタスクでは、何らかの計画能力を持たせることを推奨します。

4つの構成要素を個別に理解した上で、実際のプロジェクトではこれらをどう組み合わせるかの設計判断が求められます。以下のフレームワークで判断すると整理しやすくなります。

設計の基本原則は、ID1（マルチエージェント設計）と同様に「シンプルに始める」ことです。最初からすべての構成要素を最も高度なパターンで設計する必要はありません。まずはFunction Calling＋短期メモリ＋Reactive型で最小限のエージェントを構築し、実際のタスクで限界を感じた要素から段階的に高度化していくアプローチが、過剰設計を避ける上で有効です。

本記事では、AIエージェントのアーキテクチャを4つの構成要素（推論ループ・ツール統合・メモリ・プランニング）に分解し、それぞれの設計パターンと判断基準を整理しました。

• 推論ループ：ReAct / Function Calling / ステートマシンの3パターン。品質と柔軟性のトレードオフで選択
• ツール統合：1ツール1責務、明確な説明文、エラーハンドリングの3原則。ツール数は5〜10個が実務的な上限
• メモリ：短期（セッション内）と長期（セッション横断）を分けて設計。コンテキストウィンドウの管理戦略が鍵
• プランニング：事前計画 / 動的再計画 / Reactive。タスクの複雑性と不確実性に応じて選択

「LLMを呼ぶ」だけのシステムから「エージェントとして設計する」システムへの転換は、単にコードを複雑にすることではありません。タスクの性質を分析し、必要な構成要素を見極め、適切なパターンを選択し、段階的に構築する。この設計プロセスを明確に持てるかどうかが、AIエージェントのプロジェクトの成否を分けます。

本記事で扱ったのは「1体のエージェント」の設計です。複数のエージェントを協調させるマルチエージェントのアーキテクチャについては、関連記事で詳しく解説しています。