LoginSignup
3
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@syukan3

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

Last updated at Posted at 2024-12-28

はじめに

前回の記事では、Anthropic の Cookbook で紹介されている代表的な 5 つの AI エージェントパターン（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 自己学習エージェント

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

1. ReAct (Reason+Act)

1.1 概要

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

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

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

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

1.2 簡単なコード例

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

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 が内省も担当する点が違いです。
わざわざ「評価モデル」を別に用意しないため、シンプルに導入できる場合があります。

2.2 簡単なコード例

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 は複数の思考パスを並行して試し、最良の経路を採択する形をとります。

3.2 メリット・デメリット

  • メリット

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

  • デメリット

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

3.3 向いているタスク

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

4. Plan & Execute

4.1 概要

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

4.2 メリット・デメリット

  • メリット

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

  • デメリット

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

4.3 向いているタスク

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

5. Human-in-the-Loop

5.1 概要

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

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」など、タスクの性質や制約、要求精度に応じて最適なワークフローを選んでみてください。

次のアクション

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

3
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
3
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?