【AI開発】エージェントAIの設計パターン入門

Wed, 22 Apr 2026 01:10:00 +0900

LLMを単発のチャットとして使う段階から一歩進むと、外部ツールを呼び出し、結果を観察し、必要なら計画を修正する「エージェントAI」の設計が重要になります。この記事では、実装時に迷いやすい代表的な設計パターンを、個人開発や業務自動化に使いやすい形で整理します。

まずは拡張LLMから始める

Anthropicは、エージェントシステムの基本部品を「検索、ツール、メモリで拡張されたLLM」と整理しています。Building effective agents でも、いきなり複雑なフレームワークに入るより、まずはシンプルなLLM呼び出し、RAG、明確なツール定義から始めることが推奨されています。

重要なのは、AIに何でも自由にやらせることではなく、観察できる環境を渡すことです。たとえばコード生成ならテスト実行、調査なら検索結果、運用自動化ならAPIレスポンスが「現実からのフィードバック」になります。

基本パターン

ReAct: 考えて、動いて、観察する

ReActは Reasoning and Acting の略で、思考、行動、観察を繰り返すパターンです。Machine Learning Masteryの記事では、複雑で手順が固定しづらいタスクの出発点として紹介されています。

このパターンは、調査、デバッグ、問い合わせ対応のように「次に何をすべきか」が途中結果で変わるタスクに向いています。一方、入力と出力が安定している処理なら、普通のワークフローで十分です。

Reflection: 出力を批評して直す

Reflectionは、生成、批評、修正を回す品質改善パターンです。Andrew Ng氏も、エージェント的ワークフローの代表例として Reflection、Tool use、Planning、Multi-agent collaboration を挙げています。Andrew Ng氏の投稿では、コードや文章を生成した後に別プロンプトで批評し、改善版を作る流れが説明されています。

ただし、Reflectionはコストと待ち時間を増やします。常に入れるのではなく、記事、コード、契約書レビューのように品質基準を定義しやすい場面で使うのがよさそうです。

複雑さを足すタイミング

Planning: 先に分解する

Planningは、目的をサブタスクに分解してから実行するパターンです。複数システムを順番に操作する処理、長い調査、実装からテストまで含む開発タスクでは、最初に依存関係を見える化すると失敗しにくくなります。

Multi-Agent: 専門家を分ける

Multi-Agentは、調査担当、実装担当、レビュー担当のように役割を分けるパターンです。Anthropicの資料では、単一エージェント、マルチエージェント、ワークフロー型の使い分けが重要だとされています。Building Effective AI Agents のような実践資料でも、複雑さとビジネス価値を釣り合わせる視点が強調されています。

ただし、最初からマルチエージェントにすると、責任範囲、共有状態、ルーティング、結果の統合が難しくなります。まず単一エージェントで詰まりを確認し、明確なボトルネックが見えたら分割するくらいが現実的です。

まとめ

エージェントAI設計のコツは、最初から自律性を最大化しないことです。拡張LLM、ReAct、Reflection、Planning、Multi-Agentの順に、必要な複雑さだけを足していくと、デバッグしやすく安全なシステムになります。特に本番運用では、停止条件、人間の承認ポイント、ツールの権限境界を設計に含めることが大切です。

ツール利用 on hagizo.io