今回の論文
今回取り上げるのは、Shunyu Yao らによる 2023 年の論文「ReAct: Synergizing Reasoning and Acting in Language Models」です。公開元は ICLR 2023 で、研究分野は LLM エージェント、推論、逐次意思決定です。URL は https://openreview.net/forum?id=WE_vluYUL-X です。
この論文を選んだ理由は、いまの AI エージェント実装で広く使われている「考えてからツールを呼ぶ」という流れを、かなり早い段階で整理して示した論文だからです。RAG、検索エージェント、Web 操作エージェント、社内業務自動化のような実装に直接つながりやすく、読んだあとに設計へ落とし込みやすい技術です。
どんな技術か
ReAct は、LLM に「思考」と「行動」を交互に出力させるプロンプト設計です。ここでいう思考は、次に何を調べるべきか、どの情報が足りないか、いま何を確かめるべきかを言語で整理する短い推論トレースです。行動は、検索 API を呼ぶ、環境にコマンドを送る、Web ページを観察する、といった外部アクションです。
従来は、Chain-of-Thought のように内部で考える手法と、WebGPT などのように外部環境へ行動する手法が別々に扱われがちでした。ReAct はこの 2 つを分けずに、Thought -> Action -> Observation を繰り返す形にします。すると、思考は行動計画を作る役割を持ち、行動は不足情報を取りに行く役割を持つようになります。
要するに ReAct は、LLM を一発回答器として使うのではなく、途中で外部世界を見に行きながら問題を解くエージェントへ変える技術です。
課題
この技術が解決しようとしているのは、LLM が複数ステップの問題を解くときに、内部推論だけでも外部行動だけでも不安定になりやすいという課題です。
何が難しいかというと、複雑なタスクでは「まず何を確認するか」「次にどの情報を取りに行くか」「今ある情報で十分か」を逐次判断しないといけないからです。たとえばマルチホップ質問応答では、1 回の検索だけでは答えが出ず、複数の事実をたどる必要があります。Web 操作や環境操作でも、途中の観察結果を見てから次の行動を変える必要があります。
既存手法にも限界がありました。Chain-of-Thought は、考える筋道を作るのは得意でも、知らない事実を外から取りに行けません。そのため、もっともらしいが誤った推論を積み重ねる hallucination や error propagation が起きやすくなります。逆に、行動だけを出す方式は、検索やクリックはできても、長い手順の中で「なぜ今その行動をするのか」を保ちにくく、方針を見失いやすいです。
この課題を解く必要があるのは、実際の AI システムが閉じたベンチマークだけでなく、検索、API 利用、Web ナビゲーション、業務フロー処理のような外部環境つきタスクへ広がっているからです。エージェントを実用に近づけるには、考える能力と動く能力を別々ではなく、ひと続きのループとして扱う必要があります。
用語解説
- Chain-of-Thought
- 最終回答の前に中間推論を自然言語で出させる手法です。ReAct はこの考え方を土台にしていますが、思考だけで終わらず、その途中で実際に外部アクションを挟む点が重要です。
- Observation
- Action を実行した結果として返ってくる観測情報です。検索結果、環境状態、ページ内容などがここに入ります。ReAct ではこの観測を次の Thought の入力に戻すため、推論が外界と接続されます。
- Hallucination
- モデルがもっともらしい誤情報を作ってしまう現象です。ReAct は必要に応じて外部情報源を参照することで、内部知識だけに頼った誤りを減らそうとしています。
- Multi-hop Question Answering
- 複数の事実をたどって答えを作る質問応答です。ReAct の価値が見えやすい代表例で、1 回の推論や 1 回の検索では足りず、段階的な探索が必要です。
- Few-shot Prompting
- 少数の例をプロンプトに含めてモデルの振る舞いを誘導する方法です。ReAct は大規模追加学習ではなく、この few-shot 例を使って Thought と Action の交互出力を引き出します。
技術の仕組み
ReAct の中核は、推論を「頭の中だけの説明」にせず、次の行動を決める制御信号として使うことです。論文では、質問応答と意思決定タスクの両方で、同じ基本構造を保ちながらプロンプトを設計しています。
基本アイデア
基本の流れは単純です。モデルはまず Thought を出し、次に Action を出します。環境や API がその Action を実行すると Observation が返ります。その Observation を読んだうえで、また次の Thought を作ります。これを必要な回数だけ繰り返し、最後に Answer を出します。
この構造のポイントは、推論と行動が一方向ではないことです。思考が行動を導くだけでなく、行動で得た観測が次の思考を修正します。論文でも、これを「reason to act」「act to reason」の相互作用として捉えています。
出力フォーマット
論文中の ReAct では、各ステップを明示的なテキスト形式で表します。たとえば QA タスクなら、Thought: まず人物の所属先を調べる必要がある、Action: Search[人物名]、Observation: ... のように並びます。
これは見た目以上に重要です。なぜなら、モデルの内部状態を専用アーキテクチャで制御しているのではなく、あくまで言語列として逐次方針を保持しているからです。つまり、追加の推論モジュールを作らずに、既存 LLM のプロンプトだけでエージェント風の制御を作っています。
質問応答タスクでの使い方
HotpotQA や FEVER では、モデルは Wikipedia API を使えます。ただし最初から答えを知っている前提ではなく、必要なページを検索し、得られた文を見て、次にどのページや事実を追うかを判断します。
ここで ReAct が効くのは、途中で「今の検索では足りない」「別名で検索したほうがよい」「2 つの事実をつないで考える必要がある」といった方針転換がしやすい点です。CoT だけだと、最初に立てた推論筋書きが誤っていても、そのまま誤答へ進みやすくなります。ReAct は途中で外部証拠を取り直せるので、誤った内部仮説を修正しやすくなります。
意思決定タスクでの使い方
ALFWorld や WebShop のような逐次意思決定タスクでは、ReAct はさらにエージェントらしい形で動きます。ALFWorld では、家の中で「物を取る」「洗う」「温める」といったテキスト環境のタスクを進めます。WebShop では、商品検索や絞り込みをしながら、条件に合う商品を探します。
このとき思考は、単なる説明文ではなく、サブゴール管理の役割を持ちます。たとえば「まずキッチンにある対象を探す」「すでにナイフは見つけたので次は果物を取る」といった形です。行動だけの方式だと、いま何が終わっていて何が未完了かを失いやすいのですが、ReAct は自然言語の思考をワーキングメモリとして使っています。
推論と行動を分ける意味
ReAct の重要な示唆は、エージェント制御を全部 Action に押し込まないことです。たとえば 10 個くらいのアクション候補がある環境で、いきなり行動だけを選ばせると、モデルは短期的にもっともありそうな操作へ流れがちです。そこで Thought を 1 行入れるだけでも、次の行動を長めの文脈に沿って選べるようになります。
これは実装上かなり重要です。今でもエージェント設計では、ツール選択、検索クエリ生成、途中要約、サブゴール更新を別々のステップに分けることが多いですが、ReAct はその最小構成をかなりシンプルに示しています。
学習ではなくプロンプト中心
この論文の ReAct は、後年のエージェント研究でよくある追加学習ベースの方法とは少し違い、主に few-shot prompting で成立しています。つまり大規模な教師データで専用微調整したのではなく、少数の軌跡例を見せてその振る舞いを引き出しています。
これは利点でもあり限界でもあります。利点は、すぐ試せることです。限界は、例示の品質やタスク形式にかなり依存することです。ただし「推論トレースを行動制御に使う」という発想自体は、その後のエージェント設計に強く影響しています。
実験と結果
論文では、知識アクセスを伴う言語タスクと、外部環境を操作する逐次タスクの両方で評価しています。ここが ReAct の面白いところで、単一ベンチマーク向けの小技ではなく、異なる種類の問題に共通する制御パターンとして試されています。
質問応答と事実検証
HotpotQA と FEVER では、PaLM-540B をベースモデルに使い、Standard prompting、Chain-of-Thought、Act-only、ReAct を比較しています。OpenReview 掲載の結果では、HotpotQA の EM は Standard 28.7、CoT 29.4、Act 25.7、ReAct 27.4 でした。一方 FEVER の accuracy は Standard 57.1、CoT 56.3、Act 58.9、ReAct 60.9 でした。
この結果から言えるのは、ReAct が常に CoT 単体を大きく上回るわけではないということです。実際、HotpotQA では CoT-SC のほうが高い値を出しています。ただし FEVER では ReAct が強く、また論文著者は CoT が作る内部推論の強さと、ReAct が持つ外部根拠づけの強さが別の長所だと見ています。そのため、CoT-SC と ReAct を切り替えるハイブリッドも試しており、HotpotQA 35.1、FEVER 64.6 の設定が報告されています。
つまりこの論文の主張は、「ReAct が何でも最高性能」というより、「外部情報と逐次推論をつなぐと、少なくとも hallucination を抑えやすく、特定タスクではかなり効く」というものです。この読み方のほうが実務的です。
ALFWorld での結果
ALFWorld では、テキストベースの家庭内タスクに対して、ReAct が imitation learning 系の BUTLER や、思考なしの Act-only を大きく上回りました。OpenReview PDF では、最良試行の平均成功率が ReAct 71%、Act 45%、BUTLER 37% と報告されています。
差が大きい理由は、環境操作では「途中経過を見て計画を更新する」ことが重要だからです。たとえば対象物が見つからなかったときに別の部屋を探す、すでに加熱が終わったので次は配置へ進む、といった分岐が必要になります。ReAct は Thought を使ってサブゴールを保持できるため、行動だけの方式よりも長手順タスクに強く出ています。
WebShop での結果
WebShop では、商品の条件文を読み、サイト内検索や閲覧をしながら適切な商品を選ぶタスクを扱っています。論文では ReAct が前ベースラインより絶対値で 10 ポイント高い成功率を出したと報告しています。OpenReview PDF の表では、WebShop の task success rate が IL 29.1、IL+RL 28.7、Act 30.1、ReAct 40.0 でした。
この設定は、現在の EC エージェントや業務検索エージェントの原型として見るとわかりやすいです。自然言語の条件を少しずつ構造化し、検索し、候補を比較し、途中で条件を修正する必要があるからです。ReAct の強みは、検索と比較の途中経過を思考として保持しながら進められる点にあります。
結果から何が言えるか
全体として、ReAct は「外部行動があるタスク」で特に効果が大きいと読めます。知識問題では CoT 系がまだ強い場面もありますが、環境と相互作用するタスクでは、推論と行動を分けて交互に回す構造がかなり効いています。
また、論文が few-shot prompting ベースでここまで出している点も重要です。大規模な task-specific 学習なしでも、思考と行動のフォーマットを整えるだけで性能が伸びるというのは、プロダクト開発の観点でも再現しやすい示唆です。
何に使える？
ReAct の考え方は、いまの AI アプリ開発でもかなり直接的に応用できます。特に、1 回の回答では終わらず、検索・操作・確認を挟むシステムに向いています。
RAG の検索制御
RAG では「毎回検索する」のではなく、「何を検索し、いつ再検索し、何が取れたら十分か」を決める部分がボトルネックになります。ReAct の形を使うと、検索前に仮説を立て、検索後に Observation を読んで次のクエリを変える流れを作れます。複数段の検索が必要な問い合わせや、検索結果の不足を検知したいケースで役立ちます。
社内業務エージェント
社内ドキュメント検索、チケット参照、CRM 確認、在庫問い合わせのような業務では、回答前にいくつかの社内 API を順番に呼ぶことがあります。ここで ReAct 的な設計を使うと、「まず顧客 ID を確認する」「次に注文履歴を検索する」「情報が足りないので配送情報 API も呼ぶ」といった中間判断を残しながら処理できます。障害調査や監査のしやすさにもつながります。
Web 操作エージェント
ブラウザ自動化や管理画面操作では、途中で UI 状態が変わるため、固定スクリプトだけでは壊れやすいです。ReAct の Observation 中心のループを使えば、画面状態を読みながら次アクションを決める構造にしやすくなります。特に、フォーム入力、一覧からの候補選択、途中エラーへの再試行で有効です。
コード支援と開発自動化
コードエージェントでも、設計書検索、関連ファイル探索、テスト実行、エラーログ確認を順番に回す場面があります。ReAct の発想は、その一連の流れを Thought と Action に分けて扱うのに向いています。たとえば「まず失敗テストの原因候補を言語化し、その仮説に沿って grep や test を打つ」という設計は、かなり ReAct 的です。
開発や事業へのヒント
この論文から得られるヒントは、エージェントの価値を上げる鍵が、モデルに大きな自由度を与えることではなく、途中判断を言語として露出させることにある、という点です。
ツール呼び出しの前に短い仮説を置く
自分で AI アプリを作るなら、いきなり function calling させるより、「何を確かめたいからそのツールを呼ぶのか」を 1 行で出させるだけでも挙動が安定しやすいです。これは ReAct の一番手軽な応用です。検索クエリや API 引数の質も上がりやすくなります。
中間状態を残すと改善しやすい
既存サービスを改善する観点では、Thought、Action、Observation をログとして残すだけでも価値があります。失敗したときに、検索が悪かったのか、観測の解釈が悪かったのか、次アクションの選択が悪かったのかを切り分けやすくなるからです。これは単なる精度向上だけでなく、運用改善にも効きます。
小規模プロダクトでも部分導入できる
ReAct は大掛かりな学習基盤がなくても試せます。たとえば SaaS のサポートボットで、検索前に確認事項を一言出させる、検索後に「情報は十分か」を判定させる、といった 2 ステップ追加だけでも導入できます。特に FAQ と内部ドキュメントが混ざるような場面では、内部知識だけで答えさせるより安全です。
今後注目すべき方向性
今後は、ReAct の基本ループに加えて、メモリ、検証、再計画をどう組み合わせるかが重要になります。これは論文を少し超えた見方ですが、現在のエージェント研究でも、単発の Thought/Action だけでなく、長期タスク向けの状態管理や自己修正が大きなテーマです。ReAct はその出発点として理解しておく価値があります。
限界
ReAct にもはっきりした限界があります。まず、few-shot prompting ベースなので、例示の品質に強く依存します。どんな Thought を良しとするか、どの Action 形式を使うかで挙動が変わりやすく、安定運用にはテンプレート設計が必要です。
次に、計算コストとレイテンシの問題があります。ReAct は 1 回で答えず、Thought、Action、Observation のループを何回も回すため、通常の単発生成よりトークン消費もツール呼び出し回数も増えます。RAG や API 利用と組み合わせると、推論コストと待ち時間は無視できません。
また、外部観測の品質に依存します。検索結果が悪い、API が不完全、Web ページの観察が壊れていると、その後の思考も簡単にずれます。つまり ReAct は内部 hallucination を減らす一方で、外部観測のノイズには新たに依存します。
精度面でも、論文の結果が示す通り、知識タスクでは常に CoT 系より強いわけではありません。内部推論だけで十分解ける問題では、わざわざ行動を挟むことで遠回りになることもあります。したがって実運用では、毎回 ReAct にするのではなく、検索やツール利用が必要そうな問い合わせに限定する設計も重要です。
最後に、実装面では権限制御や安全性も課題です。検索だけならまだしも、業務 API やブラウザ操作まで許すと、誤操作や過剰アクセスのリスクが出ます。論文は制御構造の有効性を示したものであり、プロダクションの権限設計まで解決しているわけではありません。
よくある質問
Q. ReAct は Chain-of-Thought と何が違うのですか？
A. Chain-of-Thought は主に内部推論を言語化する手法です。ReAct はその途中で検索や環境操作のような Action を実際に挟み、返ってきた Observation を次の推論へ戻します。つまり、考えるだけでなく、外部世界を見ながら考え直せる点が違います。
Q. ReAct は RAG と同じものですか？
A. 同じではありません。RAG は主に外部文書を取得して回答へ渡す枠組みで、ReAct はその前後を含めた制御パターンです。RAG を使う前に何を検索するか、検索後に追加検索するかを決める部分で ReAct 的な設計が活きます。
Q. いまの function calling エージェントにも ReAct は必要ですか？
A. 必要になる場面は多いです。function calling だけだと「どの関数をなぜ呼ぶか」が暗黙になりやすいですが、ReAct 的に短い Thought を入れると、ツール選択の意図が明示され、失敗分析や再計画がしやすくなります。
Q. ReAct は学習しなくても使えますか？
A. 元論文の中心は few-shot prompting なので、専用学習なしでも試せます。ただし、本番品質に近づけるには、プロンプト例の整備、ログ評価、ツール仕様の安定化が必要です。すぐ試せる一方で、雑に導入しても安定しない点は注意が必要です。
Q. どんなタスクでは ReAct を使わないほうがよいですか？
A. 単純な一問一答や、外部情報を参照しなくても解ける処理では、ReAct の多段ループが過剰になることがあります。ツールを呼ぶ必要が薄いタスクでは、通常の回答や軽い CoT のほうが速くて安いです。
今日の学び
この論文は、LLM が外部情報や環境操作を必要とするタスクで、内部推論だけでも行動だけでも不安定になりやすい課題を扱いました。そこに対して ReAct は、Thought、Action、Observation を交互に回すことで、推論と外部行動をひとつのループに統合しました。
ここから得られるヒントは明確です。エージェントを強くしたいなら、単にツールをつなぐだけでは不十分で、途中判断をどのように言語化し、観測結果でどう更新するかを設計する必要があります。ReAct は、その最小構成を理解するのにちょうどよい論文です。