ReActパターンとツール呼び出しの基礎 — Thought→Action→Observationを初心者向けに整理する

Posted at 2026-09-02

2026年9月3日時点の公開論文・公式ドキュメントを根拠に、ReActパターンと**ツール呼び出し（function / tool calling）**の関係を初心者向けに整理します。用語だけ先に覚えるより、「モデルが考える→外の世界に手を伸ばす→結果を見てまた考える」というループを押さえるのが近道です。

この記事のゴールは、チャット1往復で終わる応答と、ツールを挟むエージェントループの違いを説明でき、設計時に「何をツールにするか」を決められる状態になることです。

結論：ReActは「考えながら動く」ための型

概念	一言で	実務での位置づけ
Chain-of-Thought（CoT）	推論の痕跡を文章で出す	考える力は強いが、外部事実に接地しにくい
Acting（行動のみ）	ツールや環境に命令を出す	動けるが、なぜその行動かを追跡しにくい
ReAct	Thought と Action を交互に出す	計画更新と外部情報取得を同じ軌跡で扱う
Tool calling	モデルが「この関数を呼べ」と返すAPI仕組み	ReActの Action を実装する現代的な手段

原文: "we explore the use of LLMs to generate both reasoning traces and task-specific actions in an interleaved manner"
日本語訳: 「LLMに推論の痕跡とタスク固有の行動を交互に生成させる使い方を探る」（出典: Yao et al., ReAct, arXiv:2210.03629）

迷ったら次の一文で十分です。

ReActは設計パターン（どうループするか）、ツール呼び出しは実装手段（どう外の世界に触るか）。

ReActパターンとは何か

確認できる事実

2022年、Yao らが論文 ReAct: Synergizing Reasoning and Acting in Language Models（arXiv:2210.03629、ICLR 2023）で提案した手法です。
推論（reasoning）と行動（acting）を別々に扱うのではなく、交互に生成させます。推論トレースは計画の誘導・追跡・更新や例外処理に、行動は知識ベースや環境とのインタフェースに使います。
HotpotQA / FEVER では、Wikipedia API とやり取りすることで、CoT で起きやすい幻覚や誤差伝播を抑え、解釈しやすい軌跡を出せる、と論文は報告しています。
ALFWorld / WebShop では、模倣学習や強化学習ベースラインより成功率を絶対値で最大34%・10%上回った、と論文 abstract に記載があります（few-shot の in-context 例のみ）。

実務解釈：ループの形

典型的な ReAct の1サイクルは次のとおりです。

Thought  : いま分かっていることと、次に必要な情報・行動を言語化する
Action   : 使うツール名と引数を決める（検索 / API / 計算 など）
Observation : ツールや環境からの戻り値を受け取る
（必要なら Thought → Action → Observation を繰り返す）
Final Answer : ユーザーへの最終回答

ステップ	役割	失敗しやすい点
Thought	計画と根拠の可視化	長すぎてコスト増、または空で飛びすぎる
Action	外部への手の伸ばし方	存在しないツール名・不正な引数
Observation	事実の接地	生ログをそのまま文脈に載せすぎる
停止	いつ答えて終わるか	無限ループ、コスト上限なし

プロジェクトサイト（https://react-lm.github.io/）でも、reason-only（CoT）は外部に接地せず誤情報を抱えやすく、act-only は同じ行動でも最終答えを合成しにくい、という対比が示されています。

ツール呼び出し（function / tool calling）とは何か

確認できる事実

OpenAI の公式ガイドでは、function calling（tool calling）は、モデルが学習データ外のデータや外部システムに接続するための仕組み、と説明されています。
用語の整理（同ガイド）:
- Tool: モデルに「使える機能」として渡すもの
- Tool call: モデルが「このツールをこの引数で呼べ」と返す特別な応答
- Tool call output: アプリ側がツールを実行した結果を、call_id などで紐づけてモデルに返すもの
高レベルの流れは 5ステップです。
1. ツール定義付きでモデルにリクエストする
2. モデルが tool call を返す
3. アプリ側でツールを実行する
4. ツール出力をモデルに返す
5. 最終のテキスト応答（または次の tool call）を受け取る
LangChain の Agents ドキュメントでは、エージェントを「タスク完了までツールを呼び続けるループ」と定義し、create_agent がそのハーネスだと説明しています（旧 create_react_agent からの移行先）。

原文: "Function calling (also known as tool calling) provides a powerful and flexible way for OpenAI models to interface with external systems and access data outside their training data."
日本語訳: 「Function calling（tool callingとも呼ばれる）は、OpenAIモデルが外部システムと接続し、学習データ外のデータにアクセスするための強力で柔軟な手段である。」（出典: OpenAI Function calling ガイド）

実務解釈：ReActのActionをどう実装するか

論文時代の ReAct は、プロンプト上で Action: Search[...] のようなテキスト形式で行動を出させることが多かったです。いまの実務では、同じ「行動」を多くの場合 構造化された tool call（JSONスキーマ付き）で表現します。

観点	テキスト形式の Action（古典的ReAct）	APIの tool calling
形式	自然言語／決め打ちフォーマット	JSONスキーマで引数を制約
パース	正規表現や自前パーサが必要になりやすい	ランタイムが構造化応答を返す
検証	壊れやすい	スキーマ検証・型チェックと相性が良い
監査	軌跡は読みやすい	call_id・ツール名・引数をログしやすい

どちらも「モデルが次の一手を決める」点は同じです。違いは、Action の表現がプロンプト規約か、プラットフォームのツールAPIかです。

最小のツール定義イメージ

天気を聞く例（概念のみ。プロダクト固有の実装ではありません）。

{
  "type": "function",
  "name": "get_weather",
  "description": "指定した都市の現在の天気を返す",
  "parameters": {
    "type": "object",
    "properties": {
      "location": {
        "type": "string",
        "description": "都市名（例: Tokyo）"
      }
    },
    "required": ["location"]
  }
}

アプリ側の疑似コード:

# 1) ツール定義 + ユーザー質問をモデルへ
# 2) モデルが tool_call(name="get_weather", arguments={"location":"Paris"}) を返す
# 3) アプリが get_weather("Paris") を実行 → {"temperature":"25","unit":"C"}
# 4) 結果をモデルへ返す
# 5) モデルが「パリの気温は25℃です」と最終回答

OpenAI ガイドの説明どおり、ツールを実行するのはモデルではなくアプリケーション側です。ここを取り違えると「エージェントが勝手にDBを書き換える」誤解が生まれます。

初心者が最初に決めるべき3点

#	決めること	具体例
1	ツールの境界	検索は可、課金APIは不可、など
2	Observationの要約方針	生HTML全部ではなく、必要フィールドだけ返す
3	停止条件	最大ターン数・タイムアウト・コスト上限

LangChain が示す基本ループも同じ骨格です。モデルを呼ぶ → ツールを選ばせる → 必要なら実行 → ツール呼び出しが終わったら完了。ReActの Thought は、システムプロンプトや中間メッセージとして明示する場合もあれば、モデル内部の推論に寄せる場合もあります。重要なのは「観察結果を次の判断に戻す」ことです。

実装チェックリスト

概念の確認

CoT（考えるだけ）と ReAct（考えつつ外に触る）の違いを説明できる
Tool / Tool call / Tool call output の3語を区別できる
「実行主体はアプリ側」と説明できる

最初のプロトタイプ

ツールは1〜3個から始める（検索・計算機・社内FAQ取得など）
各ツールに description と必須引数を書く
戻り値は短く構造化する（長文ログの丸投げを避ける）
max_turns（または同等の上限）を必ず付ける

運用前

書き込み系ツールは読み取り専用と分離する
失敗時の Observation（エラー文）をモデルに戻す方針を決める
Thought / Action / Observation のログを監査可能な形で残す

失敗パターン

パターン1：ツールなしで「エージェント」と呼ぶ → 対策: 外部操作が不要ならチャット＋RAGで足りるか先に検討する。

パターン2：Thoughtを省略してActionだけ連打する → 対策: なぜそのツールかをログに残す。失敗時の切り分けが難しくなるのを防ぐ。

パターン3：Observationに機密や巨大ペイロードをそのまま載せる → 対策: フィールドを絞り、マスキングし、トークン予算を守る。

パターン4：停止条件がない → 対策: 最大ループ・タイムアウト・コスト上限を必須にする。

パターン5：スキーマが曖昧で不正引数が頻発する → 対策: required・型・descriptionを厳密にし、エラーを Observation として返して再試行させる。

パターン6：古典的ReActのテキストActionを自前パースし続ける → 対策: 可能ならプラットフォームの tool calling に寄せ、構造化応答を使う。

参考リンク

この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表 / AIアーキテクト
Next.js / TypeScript / n8nを活用した自律型アーキテクチャ設計を専門としています。
日々の自動化の検証結果や、ビジネス側の視点（ROI等）に関するより深い考察は、以下の公式サイトおよびnoteで発信しています。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up