Skip to content

ReAct(単一エージェント・ツールループ)

LLMが「推論→行動(ツール実行)→観察」のループを回し、環境からのフィードバックを根拠に次の行動を自ら決める。解決パスを事前定義できないタスクのための、最も基本的な自律エージェント構成である。

別名

呼称出典
Agents / Autonomous AgentAnthropic「Building Effective Agents」
Single Agent with ToolsMicrosoft「AI Agent Orchestration Patterns」の複雑度区分
Reason + ActYao et al. の原論文。ReAct の語源
Tool-Use Loop一般的呼称

問題

必要なステップ数や手順を事前に予測できないオープンエンドなタスク——たとえば「このバグを修正せよ」「この障害の原因を特定せよ」——は、固定ワークフローとして書き下せない。どのファイルを何回読むか、どのコマンドを試すかは、途中で得られる情報に依存して初めて決まる。

一方、環境からの実測フィードバック(ground truth)なしにLLMへ計画と実行を委ねると、幻覚した前提のまま突き進む。存在しないAPIを呼ぶ計画を立て、失敗を検知する手段がないため誤りの上に次の誤りを積み重ねる。

コンテキスト

適用する:

  • 解決パスを事前定義できず、実行経路の決定をモデルに委ねる必要があるタスク
  • ツール実行結果・コード実行結果・テスト結果など、環境からの検証可能なフィードバックが毎ステップ得られる
  • 単一ドメインで完結し、サンドボックス等の信頼できる環境でモデルの意思決定をある程度信頼できる

適用しない(不要な)ケース:

  • 経路を事前定義できるタスク——Prompt Chaining 等のワークフロー系パターンの方が予測可能で安価
  • フィードバック源がなく、進捗を検証する手段がないタスク
  • 誤行動のコストが高いのに、承認ゲートや予算上限などの制御構造を用意できない場合

解決

システムプロンプトでツール群と目標を与え、LLMの推論(thought)→ツール呼出(action)→実行結果の観察(observation)を、タスク完了条件を満たすまで反復する。本質は毎ステップ環境から ground truth を取得することにある。観察が次の推論の根拠になるため、幻覚した前提は次のツール実行の失敗として即座に露呈し、補正される。制御を維持するために、節目や障害時に人間へ確認するチェックポイントと、最大反復回数などの停止条件を必ず併設する(Anthropic)。

python
def run_agent(task, tools):
    context = init_context(task, tool_definitions(tools))
    while True:
        step = llm(context)                   # 推論と行動の決定はモデルが行う
        if step.is_final:
            return step.result                # 完了条件を満たしたら終了
        observation = tool(step.action)       # 環境に対する行動の実行
        context.append(step.thought, step.action, observation)  # 観察 = ground truth
        if at_checkpoint(step) or is_blocked(observation):
            context.append(human_feedback(context))  # 節目・障害時の人間チェックポイント
        # 最大反復・トークン等の停止条件はループ外側の Budget Guard として実装する

実装の要点:

  • ツール設計(ACI: Agent-Computer Interface)に最も投資する。 ツールの定義・説明・引数設計の品質がループ全体の性能を決める。誤用しにくい引数(相対パスでなく絶対パスを要求する等)に矯正し、多数の入力例でモデルの使い方をテストする
  • 検証可能なフィードバックが取れない行動をループに入れない。 観察が ground truth にならない行動は幻覚の補正機構が働かず、このパターンの前提が崩れる
  • 継続判断のすべてをモデルに委ねない。 停止条件はループ外側の決定論的な構造(Budget Guard)として置き、不可逆な行動の前には Approval Gate を挟む

トレードオフ

  • ✅ 事前定義不能なオープンエンドタスクに対応できる、最大の柔軟性が得られる
  • ✅ 環境フィードバックにより幻覚が毎ステップ補正され、誤った前提のまま進み続けることを防げる
  • ⚠️ コストが高く、実行時間・トークン消費の分散が大きい。同じタスクでも数ステップで終わる場合と数十ステップかかる場合がある
  • ⚠️ 自律性ゆえに誤りが複合しうる。サンドボックス・Budget Guard・ガードレールなしの本番投入は危険であり、Anthropic も広範なテストと適切なガードレールの併用を推奨している

クラウドパターンとの対応

このパターンには直接の系譜となるクラウドデザインパターンはない。LLMの登場によって初めて成立した構成である。あえて構造の近い先例を挙げるなら、Kubernetes 等の制御ループが該当する。

クラウドパターン本パターンでの再定義
Reconciliation Loop(制御ループ)「宣言された望ましい状態へ現在状態を収束させる制御ループ」から「目標状態の解釈も遷移の選択もLLMが行うセマンティックな制御ループ」へ。収束ロジックが決定論的コードから非決定論的な推論に変わった

関連パターン

  • Budget Guard — 自律ループには必須の暴走遮断。継続判断をモデルに委ねず、外側の構造で打ち切る
  • Approval Gate — 不可逆なアクションの実行前に人間の承認を挟み、誤行動のコストを制御する
  • Reflection — ループが生む成果物を自己批評させ、品質を向上させる
  • Orchestrator-Workers — タスクが複数ドメインに広がり単一エージェントで抱えきれない場合の発展形
  • Layered Guardrails — ツール呼出とその応答を多層で検証し、有害な行動・出力を遮断する

出典・参考

本文: CC BY 4.0 / コード片: MIT。GitHub で寄稿を受け付けています。