ReActパターンとは？思考と行動を交互に回す仕組みと採用判断を実装目線で解説

ReActパターンとは、LLMに次の一手を言葉で考えさせてから道具を呼ばせ、返ってきた結果をまた考えさせる、推論と行動を交互に並べる手法です。2022年10月に公開された論文が原型で、いまのAIエージェント実装の多くがこの形を踏襲しています。ただし論文の数字を読むと、ReActはあらゆるタスクで既存手法に勝ったわけではありません。この記事では、3要素が1周する構造とプロンプトの雛形、論文が報告した成功率と負けた条件、後続パターンとの選び分け、そして見送るべき場面までを実装者向けに整理します。

まとめ｜ReActパターンの採用条件と関数呼び出し時代の位置づけ

ReActの本体は、モデルに「考え（Thought）」を明示的に出力させてから「行動（Action）」を選ばせ、その「観測（Observation）」を次の入力へ戻す並べ方にあります。狙いは精度そのものより、判断過程が読める形で残ること。どの観測を見てそのツールを選んだのかが履歴に残るため、想定外の動きをしたときに原因を絞り込めます。追跡の必要がない処理にReActを持ち込む理由は薄くなります。

採用判断は3つの条件で切れます。手順を事前に固定できず途中の結果で次の手が変わること、失敗したときに原因を追う必要があること、1回の応答時間が数十秒延びても許容されること。揃わないなら、関数呼び出しに対応したモデルへ道具を渡すだけの素朴な構成か、手順を先に固定したワークフローのほうが速く確実です。2026年8月時点では、LangGraph v1が create_react_agent を非推奨とし、LangChain側の create_agent へ寄せる流れも進んでいます。ReActは常に使う既定形ではなく、追跡可能性と引き換えにトークンと遅延を払う選択肢として扱う。それが実務的な位置づけです。

ReActパターンの定義と思考・行動・観測を1周させる制御構造

名前の由来と1周の中身が分かれば、実装で何を書くべきかはほぼ決まります。

ReActはReasoning and Actingの略で2022年発表の論文が原型

ReActは Reasoning（推論）と Acting（行動）を合わせた造語です。原典は Shunyu Yao らによる「ReAct: Synergizing Reasoning and Acting in Language Models」（arXiv:2210.03629）で、初版の公開は2022年10月6日、v3が2023年3月10日、ICLR 2023のcamera-ready版として公開されています。著者はプリンストン大学とGoogle Researchの共同チーム。論文の主張は単純でした。推論だけをさせる手法と行動だけをさせる手法は別々に研究されてきたが、同じ系列のなかで交互に出力させれば互いの弱点を補える。この2つを1つのプロンプトに同居させた点が原型の発明です。

Thought・Action・Observationが担う3つの役割と1周の流れ

ReActの1周は3つの要素で構成されます。それぞれの役割は明確に分かれています。

1. Thought（思考）：現在分かっていることを整理し、次に何をすべきかをモデル自身が自然文で書き出す
2. Action（行動）：思考にもとづき、呼び出すツールとその引数を1つ決めて出力する
3. Observation（観測）：ツールを実行した結果を受け取り、会話履歴へ追記して次の周の入力に含める

この3行が1組で、目標を満たすか打ち切り条件に達するまで繰り返されます。見落とされがちなのは、Thoughtが機能する相手はモデルだけではない点です。後段の推論に効くと同時に、人間が挙動を読むための記録にもなります。3要素のうちThoughtだけがツール実行に一切影響しない純粋なテキストであり、この「実行に効かないが読める」部分をあえて残すかどうかが、後述する採用判断の核心です。

エージェントループとの関係とReActが担う推論形式の切り分け

ReActとエージェントループは、しばしば同じものとして語られます。正確には包含関係です。エージェントループは「観測して考え、動き、また観測する」反復そのものを指す制御構造の総称で、ReActはその1周のなかで推論と行動をどう並べるかを定めた具体形の1つにあたります。器がループ、中身の並べ方がReAct。したがって、いつ止めるかという終了条件（最大反復回数・ゴール判定・費用上限）はReActの規定範囲ではなく、ループ側が担う設計領域です。この境界を曖昧にしたまま実装すると、プロンプトを直せば暴走が止まるはずだと考えて時間を溶かします。ループ側の制御と終了条件はエージェントループの解説で扱っているため、本記事はReActという推論形式そのものに絞ります。

ReActのプロンプト形式と出力をツール呼び出しへ変換する実装

実装で詰まるのは書式と出力の解釈です。原型のテキスト方式と関数呼び出し方式では書くコードが変わります。関数呼び出し側のツール定義と結果返却の型はAIツール使用（Tool Use）の解説にまとめています。

Thought・Action・Observationを並べるプロンプト雛形

原型のReActは、特別なAPIを使わず、プロンプトの書式だけで成立します。システム側の指示に使えるツール名と説明を列挙し、続けて出力の型を固定した見本を数例置く。モデルはその型を真似て続きを書きます。典型的な雛形は次の並びです。

• Question：解くべき入力。ユーザーの質問や指示をそのまま置く
• Thought：不足している情報と次の一手を1〜2文で書く行
• Action：呼び出すツール名と引数。lookup_docs[請求書 締め日] のような固定書式にする
• Observation：モデルではなく実行側が埋める行。ツールの戻り値を短く整形して差し込む
• Final Answer：Thoughtが「答えられる」と判断した時点で出力する終端の行

指示文の組み立て方はプロンプト設計の基本と共通で、書式を守らせるには型の見本を置くのが効きます。ツールの説明文は長いほど選択が正確になる一方、毎周のトークンに乗り続けるため、1ツール1〜2文が落としどころです。

テキスト解析による停止語制御と関数呼び出しへの置き換えの判断

テキスト方式で必ず実装するのが、生成を Observation: の直前で止める処理です。止めなければ、モデルは観測結果まで自分で創作して書き進みます。停止語（stop sequence）に Observation: を指定し、そこで生成を打ち切ってから実際のツールを呼び、戻り値を追記して再度モデルへ渡す。この「モデルに書かせない行を人間側が埋める」制御を落とすと、実在しない検索結果にもとづく回答が平然と出てきます。関数呼び出し（function calling）に対応したモデルなら、Action行の解析は不要です。ツール名と引数が構造化データで返るため、書式崩れによる解析失敗という失敗要因が丸ごと消えます。対象モデルが構造化ツール呼び出しに対応しているなら原則そちらを使い、対応していない自前ホストのモデルを使う場合だけテキスト方式を残す、という切り分けになります。

ReAct論文が示した実測結果とCoT・Act単独との勝ち負けの分布

ReActを万能の改善策とする解説は多いものの、原典の数字はもう少し込み入っています。どこで勝ち、どこで届かなかったかを押さえます。

ALFWorldとWebShopで報告された成功率の差と適用条件

はっきり差が出たのは、環境を操作する対話的な意思決定タスクです。家庭内の指示を実行するALFWorldでは、ReActの成功率が71%、行動のみのActが45%と報告されています。オンラインショッピングを模したWebShopでは、ReActが40.0%、Actが30.1%でした。いずれも文脈内の事例は1〜2個です。この2タスクに共通するのは、環境からの観測が毎回変わり、直前の結果を踏まえて次の行動を組み立て直す必要がある点。思考を挟むと、モデルは「いま何を探していて、どこまで進んだか」を自分の出力として保持でき、行動の系列が目標から逸れにくくなります。観測が変化せず行動の選択肢も固定的なタスクでは、この差は生まれません。

HotpotQAでCoT-SCに届かなかった事実と併用が推奨された理由

質問応答タスクの結果は単純な勝利ではありません。論文のTable 1（PaLM-540B）は次の値を報告しています。

ReActはFEVERでCoTを上回った（60.9対56.3）一方、HotpotQAではCoTにわずかに届いていません（27.4対29.4）。自己整合性を取るCoT-SCの33.4とは6ポイント差。論文が最終的に推したのは単独採用ではなく、ReActとCoT-SCを切り替える構成でした。ReActを先に走らせ、規定回数内に答えが出なければCoT-SCへ引き継ぐ形が35.1で最高値です。実務上の含意は明確で、内部知識だけで答えられる推論問題にReActを被せても得はありません。外部の事実を引きに行く必要があるかどうかが分岐点になります。

事実誤りの抑制と引き換えに増える検索失敗という典型的な失敗形

論文はReActの誤りの内訳にも触れており、ここが実装者にはいちばん実用的な情報です。CoT単独の主な失敗は、もっともらしい嘘を作る事実誤りでした。ReActはツールで外部を参照するため、この種の誤りは減る傾向です。代わりに増えるのが検索の失敗。渡した語が拾えず空の観測が返り推論が止まる、あるいは同じ語で何度も引き直して周を空費します。誤りを消したのではなく、発生箇所をモデルの内部から外部インターフェースへ移したのが実態です。投資先も変わります。プロンプトを磨くより、ツール側が曖昧な語でも何か返すよう作り込むほうが効きます。

ReActとCoT・Reflexion・Plan-and-Executeの選び分け

ReActの後には、その弱点を1つずつ潰す派生パターンが登場しています。何を足し何を削ったかで整理すると、選定の物差しになります。

推論のみのCoTと行動のみのAct単独に対するReActの位置

3つの関係は「外部と接触するか」「思考を残すか」の2軸で切れます。CoTは思考を残すが外部に触れない。Actは外部に触れるが思考を残さない。ReActは両方を持ちます。ここから導けるのは、ReActが常に上位互換ではないという事実。呼ぶべきツールが1つに決まっていて判断の余地がない処理なら、Actどころかツールを直接呼ぶコードのほうが確実です。ReActが要るのは、複数のツールから毎回選び直す場合に限られます。

Reflexionが足す自己反省とPlan-and-Executeが足す事前計画

後続パターンは、ReActが持たない要素を1つずつ補います。

Reflexionは、失敗した試行の振り返りを言語化して次の試行へ持ち越す仕組みで、同じタスクを何度もやり直せる環境で効きます。Plan-and-Executeは先に手順表を作ってから順に実行する形。周ごとにLLMへ全体を問い直さないぶん費用が下がり、途中で目標を見失う事故も減ります。一方、計画を先に固定するほど途中の観測に応じた軌道修正は弱くなる構造です。計画を状態として持たせる側の設計はAIエージェントのプランニングで、方式ごとの費用差まで整理しています。手順を人間側で標準化して与える方向へ振り切ると、Agent SOPによる標準作業手順での制御のような設計に接続します。どこまでをモデルに考えさせ、どこからを固定した手順で縛るかという配分の問題として捉えると選びやすくなります。

ReWOOとCodeActが削るもの、トークン量と表現力の交換

ReWOOは、観測が返るたびにLLMへ問い直す往復そのものを削ります。最初に必要な行動を一括で計画し、まとめて実行してから統合する構成で、呼び出し回数が減るぶん費用と遅延で優位に立ちます。代償は柔軟性。途中で計画を変える余地がないため、前段の結果に応じて次の道具が変わるタスクでは破綻しやすい設計です。CodeActは行動の表現形式を変える派生で、ツール名と引数の組ではなく実行可能なコードとして行動を書かせます。条件分岐や複数ツールの連結を1回の行動で表現できるため、集計や加工を伴う処理では周の数が目に見えて減ります。ただしコードを実行する以上、隔離された実行環境の用意が前提。まず素直なReActで組み、費用が問題ならReWOO方向、行動が単純すぎて周が増えるならCodeAct方向へ寄せる順序が失敗しにくくなります。

LangGraphとLlamaIndexでのReAct実装と非推奨化への対応方針

実装手段は、自分でループを書くか既製の部品に任せるかの二択です。主要ライブラリの提供形が動いているため、版と時点を確かめてから決めます。

create_react_agentの非推奨とcreate_agentへの移行の現況

2026年8月9日時点のPyPI公開版は、langgraph 1.2.10、langchain 1.3.14、llama-index 0.14.23です。押さえるべきは、LangGraph v1の移行ガイドが create_react_agent を非推奨（deprecated）とし、後継として LangChain 側の create_agent を案内している点。削除時期は明示されておらず、既存コードが即座に動かなくなるわけではありません。新規に組むなら後継側から入るのが素直です。移行時の注意として、旧実装にあった状態に応じて履歴を書き換える機能が後継側に見当たらないという報告も上がっています。履歴の加工に依存した実装なら、移行前に代替手段の有無を確認してください。LlamaIndex系にもReActエージェントの実装があり、選択肢は1つではありません。どの土台に載せるかの比較はAIエージェントフレームワークの選定基準に整理しています。

自前のwhileループで組む最小構成と既製部品へ任せる境界線

最小構成は驚くほど短く書けます。ツール定義を渡してモデルへ問い合わせ、返ってきたツール呼び出しを実行し、結果を履歴へ足して再度問い合わせる。この繰り返しは数十行で動きます。既製の部品へ移す判断基準は3つ。分岐や再試行の制御が入り組んできたとき、人間の承認待ちを途中に挟む必要が出たとき、複数のツール呼び出しを並列で走らせたいときです。行動段階の接続部分は、MCPで外部ツールを接続する実装手順の考え方をそのまま流用できます。

思考の軌跡ログとツール呼び出し回数を測る評価指標の組み込み方

ReActを選ぶ最大の理由が追跡可能性である以上、その追跡を実際に残す仕込みまでが実装範囲です。最低限、周ごとにThought本文・呼び出したツール名と引数・観測の戻り値・累積トークン数の4点を構造化ログとして記録します。ここまで残せば、後から「何周目で道具の選択を誤ったか」「同じ検索を何度繰り返したか」を機械的に集計できます。指標はタスク成功率だけでなく、1タスクあたりの平均周回数と無駄なツール呼び出しの比率を並べて見るのが実用的。周回数が想定より多いなら、ツールの説明文か観測の返し方に原因があります。軌跡ベースの評価指標の設計はAIエージェント評価の指標と進め方で扱っています。

ReActを採用すべき条件と関数呼び出し前提では見送るべき場面

どこで採用しどこで見送るかを条件付きで言い切ります。判断を保留したまま実装に入ると、動くデモは作れても本番で費用と遅延の問題が噴き出します。

手順が事前に読めず途中結果で道具を選び直す多段タスクという適所

ReActが効くのは、処理を紙のフローチャートに落とそうとすると分岐が描き切れないタスクです。調べた内容次第で追加調査に回るか結論を書くかが変わる調査業務、実行結果のエラーを見てから修正する反復作業、相手の回答で次に聞くべき項目が変わる問い合わせ対応。いずれも「やってみないと次の一手が決まらない」性質を持ちます。失敗時に人間が原因を追う運用が前提の業務なら、Thoughtを残す価値が費用に見合います。始め方は、ツールを2〜3個に絞った小さなループから組む順序が安全。最初から10個のツールを渡すと、モデルは選択に迷い、誤ったツールを選ぶ確率が上がります。

思考の出力が費用と応答遅延に跳ね返るため見送るべき定型業務処理

見送るべき場面もはっきりしています。第一に、手順が最初から確定している定型処理。承認フローや帳票の変換にReActを被せると、LLM呼び出しの往復が増えるだけで、通常のコードより遅く、検証もしにくくなります。第二に、応答速度が体験を左右する対話用途。Thoughtは実行に効かないテキストで、その生成時間はそのまま待ち時間です。1〜2秒の応答が求められる画面では採用しません。第三に、外部参照が不要な純粋な推論・生成タスク。論文のHotpotQAの結果が示すとおり、内部知識で答えられる問題ではReActを挟んでも精度は上がらず、むしろCoT系に劣る場合があります。

PoCから本番運用へ移す段階で外部に相談すべき基盤設計の論点

難所はPoCの後にあります。手元で動いたReActループを業務に載せるには、打ち切り条件の作り込み、周ごとのログとトレースの保管、費用の上限管理、危険な行動を実行前に止める確認処理、ツール側の失敗をどう観測として返すかの設計が同時に要ります。どれも対象業務の性質に依存する部分です。自社にエージェント基盤の設計・運用の蓄積が薄いなら、AIエージェント開発の支援のように、業務のどの工程をループへ渡し、どの工程を決まった手順のまま固定するかの棚卸しから入ると、PoC止まりや過剰なエージェント化を避けられます。そもそもエージェントを業務へ組み込むべきかという上流の判断は、AIエージェントとは何かの解説で全体像を押さえてから技術選定に降りると手戻りが減ります。

ReActパターンの実装と採用判断で実務によく挙がる質問と回答

ReActを設計・実装する際に、現場で繰り返し挙がる疑問へ答えます。

ReActパターンとは何ですか？

LLMに、次の行動を決める前の思考（Thought）を文章として出力させ、続けて行動（Action）と観測（Observation）を並べる形式で処理を進める手法です。Reasoning and Actingの略で、2022年10月公開の論文が原型にあたります。推論だけでは外部の事実を確かめられず、行動だけでは判断の理由が残らない。双方の弱点を同じ系列に同居させて補い合う設計です。

ReActとChain-of-Thoughtはどう使い分けますか？

外部の情報を取りに行く必要があるかどうかで分けます。内部知識だけで解ける推論問題ならCoTのほうが軽く、論文のHotpotQAの比較でもReAct単独（27.4）はCoT（29.4）やCoT-SC（33.4）に届いていません。最新情報の参照や環境の操作が要るタスクではReActが優位で、FEVERでは60.9対56.3と逆転します。両方を切り替える構成が最高値（35.1）を示した点も、単独採用にこだわらない根拠です。

関数呼び出しに対応したモデルでもReActは要りますか？

Action行を解析する目的では不要です。ツール名と引数が構造化データで返るため、書式崩れによる解析失敗という要因は消えます。残る論点はThoughtを出力させるかどうかで、これは追跡可能性への投資と考えてください。挙動の理由を後から追う運用があるなら思考を残す価値があり、そうでなければ省いて呼び出しだけを回すほうが速く安く済みます。

LangGraphのcreate_react_agentは使い続けて問題ありませんか？

2026年8月時点では非推奨（deprecated）の扱いで、削除時期は公表されていません。既存コードが直ちに動かなくなる状況ではないものの、新規実装はLangChain側の create_agent から入るのが妥当です。移行にあたっては、状態に応じて履歴を書き換える機能など、旧実装固有の挙動に依存していないかを先に確認してください。

ReActエージェントが同じ検索を繰り返すときはどう直しますか？

プロンプトより先にツール側を疑ってください。典型的な失敗は、渡した語が拾えず空の観測が返り、モデルが同じ語で引き直す形で起きます。候補が見つからない旨を明示的に返す、部分一致でも近い候補を返す。この作り込みで、モデルは語を変えて再挑戦できます。それでも収束しないなら、同一引数での再呼び出しを実行側で検知して打ち切る歯止めを入れます。

関連記事

• エージェントループとは？AIエージェントが自律的に動く仕組み・ReActと終了条件の設計を実装者視点で解説【2026年版】：ReActを載せる器の制御と終了条件を扱います。
• AIエージェントフレームワークとは？主要8種の比較と受託開発視点の選定基準【2026年版】：実装する土台の選び方を比較で整理しました。
• エージェントメモリとは？短期記憶と長期記憶の設計・実装判断を実装者向けに解説【2026年版】：周をまたいで何を覚えさせるかの設計です。
• マルチエージェントオーケストレーションとは：責務が過積載になったとき複数へ分ける判断を扱います。
• AIエージェントとは？生成AIとの違い・仕組みと業務に組み込む判断基準を解説：技術選定の前段にある導入判断の基準です。