ReAct：推論と行動を交互に回すエージェントの基本形

横にスクロール

どんなパターンか

ReAct（Reasoning + Acting）は、LLMを使うエージェントの最も基本的な動かし方だ。名前のとおり、推論（Reasoning）と行動（Acting）を一つのループの中で交互に進める。2022年にYaoらが発表した論文「ReAct: Synergizing Reasoning and Acting in Language Models」で提案され、以後、ツールを使うエージェントの土台として広く使われている。

素朴にLLMへ問題を投げると、モデルは頭の中だけで答えを組み立て、一気に出力する。これは知識だけで解ける問いには十分だが、最新の情報を検索したり、計算をツールに任せたり、外部システムの状態を確認したりする必要がある問いには弱い。モデルの内部知識は学習時点で止まっており、確実な計算も得意ではないからだ。

ReActはこの弱点を、行動と観察をループに組み込むことで補う。モデルはまず「何をすべきか」を短く言語化し（Thought）、次に具体的なツールを一つ呼び出し（Action）、その戻り値を受け取る（Observation）。得られた結果を手がかりに、また次のThoughtへ進む。推論だけでも行動だけでもなく、両者を噛み合わせるのがこのパターンの本質だ。

仕組み

ReActのループは、3つの役割の繰り返しでできている。Thought（思考）は、現状を踏まえて次に何をするかの方針を自然言語で書き出す部分。Action（行動）は、あらかじめ用意されたツールのうち一つを、引数を添えて呼び出す部分。Observation（観察）は、そのツールが返した結果を受け取ってコンテキストに書き戻す部分だ。

動きを1回のタスクで追ってみる。ユーザーが「東京の今日の最高気温は、昨日より何度高いか」と尋ねたとする。モデルには天気を調べるツールが一つ与えられているとしよう。

Question: 東京の今日の最高気温は、昨日より何度高いか

Thought: 今日と昨日の最高気温が必要だ。まず今日の値を調べる。
Action: get_weather(city=Tokyo, day=today)
Observation: 今日の最高気温は 31℃

Thought: 次に昨日の値を調べる。
Action: get_weather(city=Tokyo, day=yesterday)
Observation: 昨日の最高気温は 28℃

Thought: 31 から 28 を引くと 3。答えが出た。
Action: finish(今日は昨日より3℃高い)

ここで大事なのは、各ターンでモデルが生成するのはThoughtとActionの1組だけだという点だ。Actionを実際に実行するのは、エージェントを動かす外側のプログラム（オーケストレータ）であって、モデル自身ではない。プログラムはツールを呼び、その結果をObservationとして履歴の末尾に追記し、更新した履歴をふたたびモデルへ渡す。モデルは伸びた履歴を読んで、次の1組を出す。この受け渡しが、終了条件（finishの呼び出しや反復上限）に達するまで続く。

つまりReActは、モデルの「考えて次の一手を選ぶ」役割と、プログラムの「実際に手を動かして結果を返す」役割を、明確に分担させる仕組みだと言える。モデルは行動そのものを実行できないが、どの行動を取るかは決められる。この分担があるから、途中で得た事実を次の推論へ確実に反映できる。

Actionでどんなツールを呼べるか、その結果をどう構造化してモデルへ渡すかは、それ自体が一つの設計テーマになる。詳しくはツール利用で扱う。

素朴な一括生成と何が違うのかを並べて整理する。

一括生成はプロンプトから答えまでを一息に出すので速くて安いが、途中で事実を確かめる術がない。ReActは1手ごとに現実からのフィードバックを挟むぶん遅く高くつくが、確かさを要する調査には向く。どちらが優れているという話ではなく、外部の事実を参照する必要があるかどうかで選び分ける。

使いどころと注意

ReActが力を発揮するのは、答えを出すまでに外部から情報を集める必要があるタスクだ。Web検索で最新情報を引く、データベースへ問い合わせる、電卓やコード実行で正確に計算する、社内APIの状態を確認して次を決める。こうした「調べながら進める」種類の問いに向く。手順の数があらかじめ読めず、途中の結果しだいで次が変わる場合ほど、逐次判断できる強みが生きる。

一方で、万能ではない。第一に、コストと遅延が積み上がる。ループのたびに、これまでのThoughtとObservationをすべて含む履歴をモデルへ送り直すので、反復が増えるほど入力トークンが膨らみ、応答も遅くなる。第二に、ループが暴走することがある。誤ったObservationに引きずられて同じActionを何度も繰り返したり、いつまでも終了条件に達しなかったりする。反復回数の上限を設ける、想定外のツール結果をどう扱うかを決めておく、といった歯止めが要る。

第三に、手順が長くなるほど不利になる。ReActは常に「次の1手」だけを見て進むため、十手も二十手も要する複雑なタスクでは、全体の見通しを失いやすい。あらかじめ大きな計画を立ててから個々の手順を実行する計画と実行のような、上位に構造を持つパターンと組み合わせると、この弱点を補える。ReActは単体で完結するというより、より大きなエージェント設計の基本部品と捉えるとよい。

まとめ

ReActは、Thought・Action・Observationの3ステップを繰り返し、推論と外部行動を交互に進めるエージェントの基本形だ。途中結果を見てから次の一手を選べるため、外部ツールを使う調査型のタスクに強い。反面、反復に伴うコストと遅延、ループ暴走のリスクを抱えるので、反復上限や終了条件による歯止めが欠かせない。まずはこの基本ループを押さえ、そこから設計パターン一覧にある各手法へ広げていくとよい。