AIエージェント入門② - 発展的な 6 つの設計パターン

# はじめに

前回の記事では、Anthropic の Cookbook で紹介されている代表的な 5 つの AI エージェントパターン（Prompt-Chaining、Parallelization、Routing、Evaluator-Optimizer、Orchestrator-Workers）をまとめました。

https://qiita.com/syukan3/items/5becdc4f786aedbfa80a

しかし実際には、より複雑なタスクや効率化・品質向上を目指すために、さらに多様な設計パターンが研究・実践されています。

本記事では、**拡張的なパターン**としてよく言及される 6 つの方法を追加で紹介します。

1. **ReAct (Reason+Act)**  
2. **Self-Reflective（内省）エージェント**  
3. **Tree-of-Thought (ToT)**  
4. **Plan & Execute**  
5. **Human-in-the-Loop**  
6. **RL（強化学習）ベース or 自己学習エージェント**

前回と同様、それぞれの「概要」「メリット・デメリット」「向いているタスク」を中心に解説していきます。
要件に応じて、基本パターンとこれら拡張パターンを組み合わせると、より柔軟かつ強力なエージェントを構築できるでしょう。

---
# 1. ReAct (Reason+Act)

## 1.1 概要

**ReAct** とは、LLM に「思考（Reason）」「行動（Act）」「観察（Observation）」のステップを明示的に行わせるパターンです。  
単に「推論と行動を交互に実行する」だけでなく、**行動の結果（Observation）を受け取り、それを次の推論に反映する**点が最大の特徴といえます。

一般的なフローとしては下記のようになります。

1. **Reason**: 「いま何をすべきか？」を推論する  
2. **Act**: 推論にもとづき実際にツールを呼び出したり、次のステップへ進む  
3. **Observation**: 行動結果を観察し、次の推論にフィードバックする  

この 3 ステップを繰り返しながら、段階的に答えを導いたりタスクを進める構造になっています。

```mermaid
flowchart LR
    A[User Query] --> B[Reason]
    B --> C[Act]
    C --> D[Observation]
    D --> B
    B --> E[Final Answer]
```

## 1.2 簡単なコード例

以下は簡略化したサンプル実装ですが、**Reason → Act → Observation** の 3 つのステップを明確に扱うことで、ReAct の流れを表現しています。

```python
from typing import Any

def reason_and_act(llm_call, user_input: str, tools: dict) -> str:
    """
    簡単な例: Reason(思考)の出力を解析し、
    'search:' や 'calc:' といった指示があれば該当ツールを呼び出し、
    その観察結果(Observation)を次の推論に反映させる。
    """

    reasoning_log = ""
    observations_log = []
    answer = ""

    while True:
        # --- Step1: Reason（推論） ---
        # 過去の推論と観察情報を踏まえて、次に何をすべきかを考える
        prompt = f"""
        You are an agent that alternates between Reason, Act, and Observation.
        Current reasoning log:
        {reasoning_log}

        Current observations:
        {observations_log}

        Next action or final answer for the user input:
        {user_input}
        """
        response = llm_call(prompt)

        # ここでは "Reason:" と "Act:" を分割してパース（実装は省略）
        reason_part, act_part = parse_reason_act(response)

        # 推論部分をログに追加
        reasoning_log += f"\nReason: {reason_part}"

        # --- Step2: Act（行動） ---
        # "Act"にツール呼び出しがあるか、最終回答があるかをチェック
        if act_part.startswith("search:"):
            query = act_part[len("search:"):].strip()
            # ツールを呼び出して結果を取得
            search_result = tools["search"](query)
            # --- Step3: Observation（観察） ---
            # 行動の結果を次のループの推論に反映
            observations_log.append(f"Search result: {search_result}")

        elif act_part.startswith("calc:"):
            expr = act_part[len("calc:"):].strip()
            calc_result = tools["calc"](expr)
            # 行動の結果をObservationとして記録
            observations_log.append(f"Calc result: {calc_result}")

        else:
            # "Act"が最終回答（FINISH）とみなし、ループを抜ける
            answer = act_part
            break

    return answer
```

### コードのポイント

- **Reason (推論)**  
  - 過去の推論ログ（`reasoning_log`）や行動結果ログ（`observations_log`）をすべて参照しながら、「次にどのツールを使うべきか？ それとももう答えられるか？」を考えさせます。  
- **Act (行動)**  
  - 推論の結果として「search:○○」や「calc:○○」などの指示があれば、対応するツールを呼び出し、結果を取得します。  
- **Observation (観察)**  
  - ツール呼び出しの結果をログに蓄積し、次の推論の材料にします。  
  - これによって「前ステップの行動による新しい情報」を確実に次の Reason に反映できます。

## 1.3 メリット・デメリット

- **メリット**  
  - 推論過程を**段階的かつ可視化**でき、デバッグや品質向上に役立つ。  
  - ツール呼び出しによる外部情報取得を、思考（Reason）と行動（Act）、および観察（Observation）のプロセスに自然に組み込める。

- **デメリット**  
  - Reason と Act の往復（さらに Observation を含む）が増えるほど、**トークン消費・APIコスト**が高くなりがち。  
  - 推論ログ（Reason）や観察ログ（Observation）をどこまで保持するかなど、情報管理に注意が必要。

## 1.4 向いているタスク

- **検索や計算など、途中でツール呼び出しを行う必要がある複雑タスク**  
  - ユーザーの質問に答えるために追加情報が必要になるケースなど  
- **推論プロセスの可視化**が重要なシナリオ  
  - （例）エビデンスを含む解答、教育向けのステップバイステップ解説  


---

# 2. Self-Reflective（内省）エージェント

## 2.1 概要

**Self-Reflective エージェント** は、生成した回答を一度自分で評価・内省し、問題点があれば修正して再出力するフローを持つものを指します。  
Evaluator-Optimizer Workflow（前回紹介）に似ていますが、こちらは**同一の LLM が内省も担当**する点が違いです。
わざわざ「評価モデル」を別に用意しないため、シンプルに導入できる場合があります。

```mermaid
flowchart LR
    A[First Draft] --> B[Self-Reflect]
    B -- revise --> A
    B -- final --> C[Final Answer]
```

## 2.2 簡単なコード例

```python
def self_reflective(llm_call, user_input: str) -> str:
    """
    1) 初回回答
    2) 自己チェック＆修正
    3) 結果を返却
    """
    # ステップ1: 初回回答
    draft_prompt = f"Draft an answer for: {user_input}"
    draft_answer = llm_call(draft_prompt)

    # ステップ2: 内省・改善
    reflect_prompt = f"""
    Here's your first draft:
    {draft_answer}
    Please critique your own answer.
    Identify mistakes or unclear parts, then output a revised version.
    """
    final_answer = llm_call(reflect_prompt)

    return final_answer
```

## 2.3 メリット・デメリット

- **メリット**  
  - **別モデルを用意しなくても**自動校正が可能。  
  - 回答のミスをある程度**自己修正**できるため、品質向上が期待できる。

- **デメリット**  
  - 1回のプロンプトだけで済むところを、2回以上呼ぶため**コスト増**。  
  - 内省プロンプトの設計によっては、形だけの修正しか行われないケースもある。

## 2.4 向いているタスク

- **初稿 → チェック → 再稿**が自然に行われるタスク  
  - （例）文章校正、要約、ドキュメント制作  
- **モデル単体で完結させたいシナリオ**  
  - （例）Evaluator-Optimizer のように二段構えにするほど要件が厳しくない場合

---

# 3. Tree-of-Thought (ToT)

## 3.1 概要

**Tree-of-Thought** は、LLM が思考を「木構造のように複数分岐」させ、各分岐を評価しながら進む手法です。  
ReAct が「順次の思考と行動」を交互にたどるのに対し、ToT は**複数の思考パスを並行して試し**、最良の経路を採択する形をとります。

```mermaid
flowchart TB
    A[Start] --> B1[Thought 1]
    A[Start] --> B2[Thought 2]
    A[Start] --> B3[Thought 3]
    B1 --> C1[...Evaluation...]
    B2 --> C2[...Evaluation...]
    B3 --> C3[...Evaluation...]
    C1 & C2 & C3 --> D[Best Path Selection]
    D --> E[Final Output]
```

## 3.2 メリット・デメリット

- **メリット**  
  - 1本の思考が行き詰まっても、他のパスが成功する可能性があるため**解答の精度向上**が期待できる。  
  - 創造的なタスクや複数解法が考えられる問題で有効。

- **デメリット**  
  - 分岐数を増やすほど**指数的にトークン消費が膨大**になる。  
  - 実装が複雑になりがち（分岐の評価と統合が必要）。

## 3.3 向いているタスク

- **論理パズル、複数のアイデアをブレストして評価**するようなタスク  
- **複雑な問題解決で最善策を探索**したい場合  
  - （例）戦略的な提案やシナリオプランニング

---

# 4. Plan & Execute

## 4.1 概要

**Plan & Execute** は、大きな目標や複雑なタスクに対して、まず「計画 (Plan)」を立て、その計画に沿って**段階的に実行 (Execute)** していくパターンです。  
「まずはやるべきサブタスクをすべて洗い出す → そのサブタスクを一つずつLLMやツールで処理 → 最終的に成果を統合」という流れが特徴です。

```mermaid
flowchart LR
    A[Goal] --> P[Plan Phase]
    P --> E[Execute Phase Step1]
    E --> E2[Step2...]
    E2 --> E3[Step3...]
    E3 --> F[Final Output]
```

## 4.2 メリット・デメリット

- **メリット**  
  - **大きなタスクを小分け**にでき、進捗や成果物を管理しやすい。  
  - チーム開発や複数エージェントの協調など、**並行作業や役割分担**が自然に行える。

- **デメリット**  
  - 計画が間違っていると、**全工程がズレる**リスク。  
  - 計画の更新が必要になった場合、手戻りが発生。

## 4.3 向いているタスク

- **工程が多いドキュメント作成やデータ分析**  
  - （例）「要件定義 → 情報収集 → 下書き作成 → 推敲 → 仕上げ」のような流れ  
- **中長期的なゴール**を見据えた**分割型タスク**

---

# 5. Human-in-the-Loop

## 5.1 概要

「すべて自動化する」のではなく、**要所で人間（ユーザーやオペレーター）がチェックや修正を行う**仕組みです。  
LLM が出力した結果をそのまま利用するのはリスクが高い場合でも、**人間のレビューを挟む**ことで安全性や品質を保つことができます。

```mermaid
flowchart LR
    A[LLM Output] -- Human Checks --> B{Accept or Revise?}
    B -- revise --> A
    B -- accept --> C[Final]
```

## 5.2 メリット・デメリット

- **メリット**  
  - リスクの高い分野（法務・医療等）でも、**人間が最終確認**できるため事故を減らしやすい。  
  - **トークン節約**：必要な部分だけLLMに任せて、判断は人間が行う。

- **デメリット**  
  - 人間の工数が増えると、**全体のスループットが下がる**。  
  - リアルタイム性や完全自動化を求めるケースには不向き。

## 5.3 向いているタスク

- **品質重視の文書作成や法的リスクの大きい書類**  
- **クリエイティブな分野**（広告コピーなど）で、最終案を人間が微調整するシナリオ

---

# 6. RL（強化学習）ベース or 自己学習エージェント

## 6.1 概要

**強化学習 (Reinforcement Learning)** のフレームワークを組み込み、エージェントが**報酬 (Reward)** を受け取りながら試行錯誤する仕組みです。  
Auto-GPT や BabyAGI などの実装では、外部環境からのフィードバックやタスク進捗度を報酬とし、エージェントが段階的に学習・行動を最適化していく例も見られます。

## 6.2 メリット・デメリット

- **メリット**  
  - エージェントが**自律的に改善サイクル**を回せる余地がある。  
  - 「試行錯誤が本質」のタスク（ゲームAI、シミュレーション等）で大きな効果。

- **デメリット**  
  - **報酬設計が難しい**。不適切な報酬で学習が進まない or 意図しない方向に暴走するリスク。  
  - 運用コストが大きく、LLM と RL を組み合わせるための技術的ハードルも高い。

## 6.3 向いているタスク

- **ゲーム AI、ロボティクス、継続的最適化**（マーケティング戦略最適化など）  
- **ゴールと報酬が定量化しやすい領域**  
  - （例）売上、クリック率などの指標を最大化するタスク

---

# まとめ

Anthropic の Cookbook で紹介された 5 つのパターン（Prompt-Chaining、Parallelization、Routing、Evaluator-Optimizer、Orchestrator-Workers）に加え、本記事では **6 つの拡張パターン** をご紹介しました。

1. **ReAct (Reason+Act)**  
   - 思考と行動を交互に明示化し、ツール連携を自然に組み込む。  

2. **Self-Reflective（内省）エージェント**  
   - 同一モデルで自分の回答を批判的に見直し、再度回答する。  

3. **Tree-of-Thought (ToT)**  
   - 複数の思考パスを並行しながら評価し、最善の解を導く。  

4. **Plan & Execute**  
   - 大きなゴールに向けて「計画→実行」のプロセスを分離し、可視化・管理する。  

5. **Human-in-the-Loop**  
   - 要所で人間がレビューや修正を行うことで、品質・安全性を確保する。  

6. **RL（強化学習）ベース or 自己学習エージェント**  
   - 報酬を介した試行錯誤で、自律的にタスク完遂を目指す。

いずれのパターンも、**単独で使うだけでなく、複数を組み合わせる**ことでより強力なエージェントを構築できる可能性があります。  
たとえば「Plan & Execute + ReAct」「ToT + Evaluator-Optimizer」など、タスクの性質や制約、要求精度に応じて最適なワークフローを選んでみてください。

# 次のアクション

本記事の続編・関連記事があるので、ご参考にしてみて下さい。

https://qiita.com/syukan3/items/5becdc4f786aedbfa80a

https://qiita.com/syukan3/items/153409d7f387ea8c3065

https://qiita.com/syukan3/items/3f9e857dc0203430ea76

https://qiita.com/syukan3/items/174e43235bde8a1a0694

---
### 会社紹介

**株式会社 Mosaica**  
最先端テクノロジーで社会課題を解決し、持続可能な未来を創造する IT カンパニー。
AI ソリューション、クラウド統合、DX 推進、経営コンサルティングなど包括的なサービスでビジネス変革を支援しています。  

詳しくは [公式サイト](https://mosaica.co.jp/) までお気軽にご相談ください。
公式サイト： https://mosaica.co.jp/