AIエージェントの設計パターン — Tool Use・Memory・Planning・Multi-Agent の選び方

前提 — なぜパターンで考える必要があるのか

エージェントを1体組んだ後、多くの人が次にぶつかるのは「もっと複雑なタスクに対応させたいが、何を足せばいいかわからない」という壁です。闇雲に機能を足すと、動作が予測しづらくなり、コストとデバッグの手間だけが増えます。Anthropicのエンジニアリングブログは、まず単一のモデル呼び出しと明確な指示で解決できないかを検討し、複雑な仕組みは成果が明確に上回る場合にだけ導入すべきだと述べています。以下の4パターンは、その判断をするための語彙として使います。

パターン1 — Tool Use（ツール呼び出し）

もっとも基本的なパターンで、モデルが検索・計算・外部APIの呼び出しといった機能を、必要に応じて自分で選んで実行します。単体のツール呼び出しは実装も検証もしやすく、最初に取り組むべきパターンです。ただし、ツールの数が増えるほどモデルがどのツールを選ぶべきか迷いやすくなるため、似た機能のツールを乱立させず、説明文を明確に書き分けることが実務上のポイントになります。

パターン2 — Memory（短期記憶と長期記憶）

短期記憶は、1回のタスク実行中に得た情報（これまでのツール呼び出し結果や中間の判断）を会話の文脈内に保持するものです。長期記憶は、タスクをまたいで使う知識（ユーザーの好みや過去の決定事項など）を、外部のデータベースやファイルに保存して必要なときに取り出す仕組みを指します。短期記憶はコンテキストウィンドウが伸びるほどコストと処理時間が増えるという制約があり、長期記憶は検索の精度がそのまま出力の質に直結するという別の課題を抱えます。両者は目的が異なるため、片方だけで済ませようとすると設計が破綻しやすい点に注意してください。

パターン3 — Planning（ReAct と Plan-and-Execute）

Planningは、エージェントがどう「考えてから動くか」の型です。ReAct（Reasoning and Acting）は、推論（reasoning）とツール実行（acting）を1ステップずつ交互に繰り返す方式で、Yaoらの研究で提案され、途中の観察結果を次の推論に反映しやすいことが報告されています。一方でPlan-and-Executeは、最初に手順全体の計画を立ててから実行に移る方式で、各ステップの見通しが立てやすい反面、実行中に想定外の結果が出た際に計画全体を練り直すコストがかかります。単純な問い合わせ対応にはReAct的な逐次判断で十分なことが多く、複数の外部システムをまたぐような手順が多いタスクではPlan-and-Executeの方が制御しやすい傾向があります。

パターン4 — Multi-Agent（複数エージェント構成）

1つのエージェントに複数の役割を持たせる代わりに、役割ごとに分けた複数のエージェントを協調させる構成です。たとえば「調査担当」と「執筆担当」を分けることで、それぞれの指示文（プロンプト）をタスクに特化させやすくなります。もっとも、エージェント間のやり取り自体がAPI呼び出しの回数とコストを押し上げ、どちらの担当が誤った判断をしたのか原因を切り分けにくくなるという欠点もあります。役割分担が本当にタスクの質を上げるかどうかは、単一エージェントに詳細な指示を与えた場合と比較検証してから判断すべきです。

どう選ぶか

目安としては、Tool Useはほぼすべてのエージェントで必要になる基礎パターンです。Memoryは、タスクが長時間に及ぶか、複数回のやり取りをまたいで情報を使い回す必要があるときに追加します。Planningは、手順の途中で判断が分岐するタスクで効果が出やすく、単純な一問一答的なタスクには過剰な場合があります。Multi-Agentは、単一エージェントの指示文を工夫しても精度や保守性が頭打ちになったときの、最後の選択肢として検討するのが妥当です。エージェントの安全な運用に踏み込む前に、まずこの4パターンのうちどれが実際に必要かを絞り込んでおくと、後続の権限設計やログ設計も対象範囲を絞りやすくなります。運用面の具体策はAIエージェントの安全な運用で扱います。

※本稿は2026年8月時点の情報にもとづきます。エージェント設計のベストプラクティスは各社の公式ドキュメントで随時更新されるため、実装前に最新情報を確認してください。