ReActとは？AIエージェントの基礎フレームワークを図解【LangChainの原点】

2022年夏、Princeton大学の研究室。

一人の博士課程学生が、イヤホンでEminemの「Lose Yourself」を聴きながらコードを書いていた。Shunyu Yao（姚顺宇）、当時26歳。彼は清華大学でラップクラブを創設していた異色の研究者だった。

その日、彼が投稿したarXiv論文（2210.03629、ICLR 2023 Notable Top 5%選出、引用5,250件超）は、AI業界の常識を覆すことになる。わずか2個の例を見せただけで、10万個のデータで訓練された従来手法を34%上回る——なぜこんなことが起きるのか。

答えは、「考える」と「行動する」を1ステップごとに交互に噛み合わせたことにある。人間が問題を解くとき、頭の中だけで完結させず、Googleで調べたり計算機を使ったりするのと同じ構造だ。この記事が確かめたいのは2つある。1つは、外部観察を挟むことがなぜ推論をハルシネーションから遠ざけるのかという機構。もう1つは、素のReActループが実務のどのステップ数まで持ち、どこで破綻するのかという境界線だ。

私たちNexaflowは、この論文を学術的な到達点としてではなく、調査・見積もり・リサーチ業務を自動化する道具として使う側の立場でこれを書いている。LangGraphが2025年11月のv1.0でcreate_react_agentを非推奨にし、ミドルウェアによるフック機能とDurable State（実行状態の自動永続化）を標準搭載に切り替えたのは、業界側が「素のReActだけでは足りない」と答えを出した出来事だと私は読んでいる。だからこそ今、素のReActの実力と限界を実務目線で棚卸ししておく必要がある。

前提：この記事で使う2つの用語

主張を検証可能にするため、先に2つの言葉を定義する。

• 接地（グラウンディング）: 推論を1ステップごとに外部観察（ツールの実行結果）で検証し直すこと。Chain-of-Thought（CoT）は推論だけで完結するため接地がなく、内部知識に基づく自信満々の誤り＝ハルシネーションが起きる。ReActはThought（推論）の直後に必ずAction（行動）とObservation（観察）を挟むことで、この接地を作る。
• エラー蓄積: 1本道の推論でステップが増えるほど、途中の誤った推論が後戻りできずに積み重なっていく構造。後半で見るように、この弱点がReflexion・Tree of Thoughts・LATS・Plan-and-Executeといった後続研究の存在理由になる。

「常識の逆転」が起きた瞬間

Shunyu Yaoが挑んだのは、当時のAI研究が抱えていた2つの陣営の対立だった。

**Chain-of-Thought（考えるだけ）は、LLMに段階的に考えさせることで複雑な数学問題を解けたが、接地がないためハルシネーションを起こした。一方、強化学習などのAction-only（動くだけ）**は試行錯誤でタスクをこなせたが、「なぜその行動を取ったか」を説明できず、計画性が欠如していた。

Yaoは、「考える」と「動く」を分けること自体が間違いだと気づいた。この「当たり前」をAIに実装したのがReActだった。

ReActの仕組み：接地はどう作られるか

ReActの核心は、Thought-Action-Observationの3ステップを繰り返すループ構造だ。

ReActのThought-Action-Observationループ

Thought（推論）: LLMが現在の状況を分析し、次のアクションを決定する。CoTと同様の推論プロセスだが、ReActでは行動を前提とした推論を行う点が異なる。

[Thought] ユーザーは消費税込み価格から税抜き価格を求めている。
         計算ツールを使って 1000 / 1.1 を計算する必要がある。

Action（行動）: 推論結果に基づいて、適切なツールを選択・実行する。

[Action] calculator(1000 / 1.1)

Observation（観察）: ツールの実行結果を受け取り、次のThoughtに活用する。

[Observation] 計算結果: 1000 / 1.1 = 909.09

このObservationが挟まることこそが接地であり、推論が現実に固定される瞬間だ。CoTにはこのステップが存在しないため、モデルは自分の内部知識だけで次の一手を決めてしまう。

実験結果：接地の効果を数字で見る

論文では、3つのベンチマークで検証が行われた。

ALFWorldでの+34%が突出しているのは偶然ではない。ALFWorldは「部屋の中のオブジェクトを探して操作する」タスクで、CoTのように内部知識だけに頼るとオブジェクトの位置や状態を誤って想定しやすい。Observationで実際の環境状態を都度確認できるReActは、この手のタスクで接地の効果が最も出やすい、と考えられる。

実装方法：LangChain/LangGraphでReActエージェントを作る

LangChain（エージェント開発フレームワーク）とLangGraph（ワークフロー構築ライブラリ）を使えば、数十行のコードでReActエージェントを構築できる。

基本的なコード構造（2026年最新）

2025年11月にリリースされたLangGraph v1.0では、従来のcreate_react_agentが非推奨となり、langchain.agentsの**create_agent**に統合された。ミドルウェアによるフック機能が追加され、エージェントループの各ステップをカスタマイズできるようになっている。

from langchain_openai import ChatOpenAI
from langchain_core.tools import tool
from langchain.agents import create_agent  # v1.0〜の新API

# ツールの定義
@tool
def calculator(expression: str) -> str:
    """数学的な計算を行う"""
    result = eval(expression)
    return f"{expression} = {result}"

@tool
def search_knowledge(query: str) -> str:
    """情報を検索する"""
    # 検索ロジック
    return search_result

# エージェント作成（LangGraph v1.0〜）
llm = ChatOpenAI(model="gpt-4o", temperature=0)
agent = create_agent(
    llm,
    [calculator, search_knowledge],
    system_prompt="あなたは計算と検索ができるアシスタントです"
)

# 実行
result = agent.invoke({"messages": [("user", "100 × 5 を計算して")]})

langgraph.prebuilt.create_react_agentは2025年11月のLangGraph v1.0で非推奨になった。既存コードは動作するが、新規プロジェクトではlangchain.agents.create_agentの使用が推奨されている。

なお、create_react_agentからcreate_agentへの移行は本記事の検証コードでは実施していない。移行を検討する場合は、ミドルウェアのフック処理やDurable Stateの永続化タイミングが既存のmax_iterations制御やログ出力と衝突しないかを、本番投入前に個別に確認しておくべきだろう。

実装上のポイントは4つある。ツールの説明文が曖昧だとLLMが誤った判断をするため説明文の質が精度に直結すること、temperature（ランダム性のパラメータ）を0にして再現性を確保すること、無限ループ防止のためmax_iterationsに上限（通常10〜20回）を設けること、そしてv1.0の新機能であるDurable Stateによりサーバー再起動時もエージェントの実行状態が自動永続化されることだ。

論文自体、および実装に使うLangChain/LangGraphはいずれもMITライセンスで公開されており、商用利用は可能だ。デバッグ時はThought-Action-Observationの各ステップをログ出力し、LangSmith（LangChainのトレーシングツール）を併用すると問題箇所を特定しやすい。

実際に動かしてみた：ビジネスシナリオでの検証

“

実行環境: Claude Code + LangGraph + gpt-4o

シナリオ1: 競合価格調査エージェント

プライシング業務での競合SaaS価格調査を想定し、AIチャットボットSaaS（Intercom、Zendesk、Tidio、Drift）の価格を自動調査して比較レポートを生成するエージェントを構築した。使用ツールはweb_search（価格情報検索）、calculator（年額→月額変換、為替計算）、generate_comparison_report（Markdown比較表生成）。

[行動] web_search({'query': 'Intercom pricing 2025'}...)
[行動] web_search({'query': 'Zendesk pricing 2025'}...)
[観察] snippet: Intercom pricing starts at $39/month...
[行動] calculator({'expression': '468 / 12'})  # 年額→月額変換
[観察] 計算結果: 468 / 12 = 39.00

処理時間8.41秒で完走し、月額5万円以下のサービスとしてTidio、Driftを推奨する比較レポートを自動生成した。

シナリオ2: 見積もり支援エージェント

ECサイトリニューアル案件（商品数500点、決済機能、会員機能、在庫連携）の見積もりを自動作成するエージェントを構築した。使用ツールはanalyze_requirements、calculate_man_hours、calculator、generate_estimate。

[行動] analyze_requirements({'requirements': '商品数: 約500点, 決済機能...'})
[観察] 抽出された開発項目: フロントエンド開発、バックエンド開発、インフラ構築、テスト

[行動] calculate_man_hours({'item': 'フロントエンド開発', 'complexity': 'medium'})
[観察] 「フロントエンド開発」の想定工数: 40人日

[行動] calculator({'expression': '40 + 60 + 10 + 20'})
[観察] 計算結果: 40 + 60 + 10 + 20 = 130

[行動] generate_estimate({'project_name': '中小企業向けECサイトリニューアル', ...})

処理時間8.15秒で完走した。

シナリオ3: 技術リサーチエージェント

AIエージェントフレームワーク（LangChain、LlamaIndex、CrewAI）を調査し比較レポートを生成するエージェントを構築した。使用ツールはweb_search、knowledge_db（ナレッジベース参照）、generate_comparison_table。

[行動] web_search({'query': 'LangChain AI framework 2025 updates'})
[行動] knowledge_db({'topic': 'LangChain'})
[行動] generate_comparison_table({'items': 'LangChain, LlamaIndex, CrewAI'})

処理時間18.66秒で完走し、複雑なエージェント開発にはLangChainが向くという比較表を生成した。

3シナリオともタスクは完走した。上記のログに表示された行動数から見る限り、いずれも5ステップ以内の短い定型フローだったと考えられるが、ログは各シナリオの一部の行動を抜粋したものであり、実際の総ステップ数を厳密に数えたものではない。この結果だけで長い自律タスクへの適用可能性を語ることはできない。

コスト概算

上記の処理時間は本記事の検証コード（GitHub）の実行ログに基づく実測値だが、API費用はgpt-4oの料金体系から算出した概算であり、実際の課金額を計測したものではない。

ReActの弱点を処方箋別に整理する

ここまでの検証結果を、単に「良かった」で終わらせず、弱点を軸に組み替える。ReActには大きく3つの弱点があり、それぞれに対応する後続研究がある。

Reflexionが採った「失敗を言語化して記憶する」というアプローチは、記憶機構そのものを一般化した研究にもつながっていく（A-Mem: エージェントの記憶設計）。ReActのエラー蓄積という弱点を「記憶」側から補う方向性として押さえておきたい。また、ReAct以降にエージェントが自己改善・自己進化していく研究潮流全体を俯瞰したい場合は、自己進化するAIエージェントのサーベイが見取り図になる。

加えて、推論コスト（毎回LLMを呼び出すためAPI費用が増加する）と、ツール依存（適切なツールがないと性能が発揮できない）も実務上の制約として残る。

私の結論：どこまでReActで足り、どこから足りないか

私は、素のReActループは「調べる→計算する→まとめる」程度の3〜5ステップの定型タスクには十分実用的だが、それを超える長い自律タスクにReAct単体を投入するのは避けるべきだと考えている。境界は明確で、短ステップの定型作業ならReActで足りる。長く分岐する自律タスクは、Reflexion（自己修正）・Plan-and-Execute（計画分離）・human-in-the-loopのいずれかと組み合わせないと、エラー蓄積で破綻する。

この境界線は、上記の検証結果と「ReActの弱点を処方箋別に整理する」の表で見た構造的な弱点（接地不足によるエラー蓄積、1本道推論、計画の欠如）から導いた推論であり、長い自律タスクが実際に破綻する現場を観測した記録ではない。読者が自社のタスクに当てはめる際は、まず短いステップで試し、エラーが蓄積し始める兆候（同じ誤りの繰り返し、観察結果の解釈のブレ）が出た時点でReflexionやPlan-and-Executeへの切り替えを検討するのが妥当だと考える。

LangGraph v1.0がcreate_react_agentを非推奨にし、ミドルウェアによるフック機能とDurable Stateを標準に組み込んだこと自体が、業界側もこの境界線を認めている証拠だと私は見ている。読者への判断材料はシンプルだ——あなたが今自動化しようとしているタスクは何ステップで完結するか。それが5ステップ以内の定型作業なら、まずは素のReActで試す価値がある。それを超えるなら、最初からReflexionかPlan-and-Executeを前提に設計した方がいい。

【驚きの事実】研究者Shunyu Yaoのその後

ReAct論文の主著者Shunyu Yaoのキャリアは、AIエージェント研究の激動を象徴している。

Yaoは、中国の大学入試「高考」で704点を獲得し、Anhui省で3位として清華大学に入学。選んだのは普通のコンピュータサイエンス学科ではなく、ノーベル賞級の科学者Andrew Chi-Chih Yao（姚期智）が創設した超エリートプログラム「姚班（Yao Class）」だった。一方で清華大学でラップクラブ「Rap Club」を共同創設し、EminemやMC HotDogを愛聴していたという異色の一面も持つ。

博士号取得後のキャリアも激動だった。2024年8月、Princeton大学で博士号を取得した直後にOpenAIへ入社し、Operator（ブラウザ操作AIエージェント）やDeep Research（深層リサーチエージェント）の開発に中核メンバーとして貢献。2025年夏にTencentへ移籍し、同年12月にはChief AI Scientistに昇格した（契約金$14M＝約21億円との報道、未確認）。2026年2月にはCL-bench（Contextual Learning Benchmark）を共著で発表している。

そして技術面でも、Yaoは自らの発見を超え続けた。ReAct発表の翌年、Tree of Thoughts（NeurIPS 2023）を発表し、ReActの「1本道推論」がエラー蓄積を起こすという弱点を、木構造探索によって自ら解決してみせたのだ。

Eminemの歌詞に「You only get one shot, do not miss your chance to blow」（チャンスは一度きり、逃すな）というフレーズがある。Yaoは、Princeton研究室で「考えながら動く」というシンプルなアイデアを実装し、それをReActとして世界に示した。そして、LangChain、AutoGPT、無数のAIエージェントがReActの設計図を引き継いだ。

次に読むべき論文

CoTには接地がなくハルシネーションが起きる、という弱点をReActが外部観察で埋める——この2記事は直接の因果でつながっている。CoTの限界を先に押さえてから本記事を読むと、なぜReActが「常識の逆転」だったのかがより腑に落ちるはずだ。

“

AIエージェント論文おすすめ11選に戻る

参考リソース

• arXiv論文（ICLR 2023 Notable Top 5%選出、引用5,250件以上）
• Google Research Blog
• 公式プロジェクトページ
• GitHub
• 本記事の検証コード

本記事の検証はすべてClaude Codeで実施しました。