Reflection Agentとは｜自己批評で回答精度を上げる仕組みとLangGraph実装

Reflection Agentは、LLMが生成した回答をLLM自身が批評（reflect）し、その指摘をもとに書き直す（revise）ループを持たせた設計パターンです。一発で答えを返す通常の生成と違い、「生成→自己批評→改訂」を数回まわして精度を積み上げます。推論・コード生成・長文作成のように、初回の答えに誤りや抜けが混ざりやすいタスクで効果が出ます。この記事では仕組み、代表手法のReflexion・Self-RAGとの違い、LangGraphでの実装、そして「使うべきでない場面」までを整理します。

まとめ：Reflection Agentの要点

• 正体：LLMが自分の出力を批評して書き直す「生成→批評→改訂」のループ。単発生成に自己修正を足した設計パターン。
• 代表手法：Reflexion（失敗を言語化して次の試行に活かす）、Self-RAG（reflection tokenで検索の要否と根拠を自己判定）、Basic Reflection（生成役と批評役を分ける2エージェント構成）。
• 実装：LangGraphのStateGraphで生成ノード・批評ノードを条件付きエッジで往復させ、反復上限で停止する。
• 効きどころ：数学・コード・長文・RAGなど検証可能で誤りが出やすいタスク。逆に単純な定型回答ではレイテンシとコストだけ増えるため不向き。
• 注意：AIの教科書に出る「反射エージェント（reflex agent）」＝条件-行動ルールで動く別概念で、本記事のReflection Agentとは無関係。

Reflection Agentの定義と自己批評ループ

Reflection Agentは、AIエージェントに「自己批評」の工程を組み込んだものです。まずタスクに対する回答を生成し、次に同じ（または別の）LLMがその回答を採点・指摘し、その指摘を入力に戻して回答を書き直します。人間が下書きを見直して直す作業を、エージェントのループとして自動化したものと捉えると分かりやすいです。

通常のLLM生成との違い

通常のプロンプト応答は、モデルが一度だけ出力して終わります。この方式では、初回に生じた事実誤り・論理の飛躍・要件の取りこぼしがそのまま残ります。Reflection Agentは出力を一度「疑う」ステップを挟み、指摘を反映してから返すため、初回品質のばらつきを後段の改訂で吸収できます。ただし1回のタスクで複数回LLMを呼ぶので、応答時間とトークンコストは増えます。

「反射エージェント（reflex agent）」とは別物

検索では「シンプル反射エージェント」「モデルベース反射エージェント」という語も同じ綴りで混ざりますが、これらは別概念です。反射エージェント（reflex agent）は、AIの古典的な教科書でエージェントを分類する用語で、現在の知覚に対して「もしこの条件ならこの行動」という条件-行動ルールで即座に反応する方式を指します。過去の失敗を言語化して次に活かす本記事のReflection Agent（LLMの自己批評）とは仕組みも目的も異なります。「reflection（内省）」と「reflex（反射）」の違いだと押さえておけば混同しません。

Reflection Agentの仕組み：生成→批評→改訂のループ

Reflection Agentの中核は3つの役割の分業です。多くの実装がこの構造を共有しています。

3つの役割（生成・批評・改訂）

• 生成（Generator/Actor）：タスクに対する初回の回答や行動を出力する。
• 批評（Reflector/Evaluator/Critic）：その回答を採点し、どこが不十分か・何を直すべきかを言語で指摘する。外部ツール（テスト実行、検索、ルールチェック）の結果を根拠に使うこともある。
• 改訂（Reviser）：批評を入力に戻し、指摘を反映した新しい回答を作る。改訂後の回答を再び批評にかけることで反復する。

生成役と批評役を同一モデルの別プロンプトで担わせる構成（自己批評）と、役割ごとにエージェントを分ける構成（Basic Reflection）の両方があります。

ループを止める条件

自己批評は放置すると無限に回り続け、コストが膨らみます。実装では反復回数の上限（例：MAX_ITERATIONS）や、批評側が「合格」と判定したら停止する終了条件を必ず設けます。改訂を重ねても品質が頭打ちになることが多いため、多くのチュートリアルでは数回程度で打ち切る設計を採ります。

代表的な手法：Reflexion・Self-RAG・Basic Reflection

「Reflection Agent」は総称で、実際には狙いの異なる手法がぶら下がっています。検索意図として混在しやすいReflexion・Self-RAGを中心に切り分けます。

Reflexion：失敗を言語化して次の試行に活かす

Reflexion（Shinn らが2023年に提案）は、行動の結果に対する自己反省を「言語的な強化学習（verbal reinforcement learning）」として扱う手法です。エージェントは、行動役（Actor）・評価役（Evaluator）・自己反省役（Self-Reflection）に分かれ、試行が失敗すると「なぜ失敗したか・次はどうするか」を文章で書き起こし、それをエピソード記憶（メモリ）に蓄積して次の試行のプロンプトに足します。モデルの重みは更新せず、記憶に反省文を貯めることで試行を重ねるほど賢くなる点が特徴です。

Self-RAGとReflection Token

Self-RAG（Asai らが2023年に提案）は、RAG（検索拡張生成）に自己反省を組み込んだ手法です。モデルが生成の途中で「reflection token」と呼ばれる特殊トークンを出力し、検索すべきか（Retrieve）、取得文書が関連するか（IsRel）、回答が文書に裏付けられているか（IsSup）、回答が有用か（IsUse）を自己判定しながら進めます。常に検索するのではなく必要なときだけ検索し、根拠の薄い回答を自分で弾けるのが利点です。RAG全体を自律的に制御する発想はAgentic RAGのアーキテクチャとも重なります。

Basic Reflection：生成役と批評役を分ける

最も基本的な構成が、回答を作るエージェントと、それを批評するエージェントを分けるBasic Reflectionです。批評役に「厳しい編集者として指摘せよ」といった役割を与え、生成役はその指摘を受けて書き直します。外部ツールを使わずプロンプトだけで組めるため、長文生成やコードレビューの下地として導入しやすい形です。

LangGraphでのReflection Agent実装

ループと分岐を持つReflection Agentは、状態を持ったグラフとして書けるLangGraphと相性が良いです。LangChainとLangGraphの違いを踏まえると、単純な一直線のチェーンはLangChain、こうした反復・条件分岐を含むフローはLangGraphが担当領域だと整理できます。

StateGraphでループと分岐を組む

典型的な組み方は、初回回答を作る生成ノード、それを採点する批評ノードを用意し、条件付きエッジ（conditional edge）で「合格なら終了、不合格なら改訂ノードへ戻す」分岐を作る形です。反復回数はグラフの状態（State）にカウンタを持たせ、上限に達したら強制的に終了ノードへ遷移させます。Self-RAG型では、検索・文書採点・回答生成・再検索の各ステップをノードにし、reflection tokenの判定でエッジを切り替えます。

# LangGraphの分岐イメージ（擬似コード）
graph.add_node("generate", generate_node)
graph.add_node("reflect", reflect_node)
graph.add_conditional_edges(
    "reflect",
    should_continue,  # "revise"（改訂へ戻す）か "end"（終了）を返す
    {"revise": "generate", "end": END},
)

批評を効かせるプロンプト戦略

Reflection Agentの品質は批評プロンプトの具体性で決まります。「もっと良くして」といった曖昧な指示では改訂が空回りします。批評側には、評価軸（事実の正確さ・要件の充足・コードなら動作可否）を明示し、可能なら合否だけでなく「どの箇所を・どう直すか」を出力させます。テスト結果や検索結果など外部の根拠を批評に渡せると、モデルの思い込みによる誤った自己評価を減らせます。批評文を状態として持ち回り、次の生成に確実に反映させる設計は、Context Engineeringの考え方とも通じます。

効果が出る場面と、採用すべきでない場面

Reflection Agentは万能ではありません。反復のたびにLLM呼び出しが増えるため、効果とコストの釣り合いで採否を決めます。

効果が出るタスク

初回出力に誤りや抜けが出やすく、かつ良し悪しを検証できるタスクで効きます。具体的には、コード生成（テストや実行結果で採点できる）、数学・論理推論（手順の飛躍を批評で拾える）、長文・レポート生成（構成や事実の抜けを見直せる）、RAGの回答（根拠との整合を自己チェックできる）です。

採用すべきでない場面

逆に、次のような場面では導入を見送るか、より軽い手法を選ぶべきです。第一に、定型的で正解が一意な単純タスク（住所整形、単純分類など）は初回でほぼ正しく、反復はレイテンシとコストを増やすだけです。第二に、対話UIのように応答速度が最優先の場面では、複数回のLLM呼び出しが体感を悪化させます。第三に、批評の根拠になる検証手段（テスト・検索・ルール）が用意できないタスクでは、モデルが自分の誤りを自分で追認する「自己満足のループ」に陥りやすく、回しても品質が上がりません。反復は「検証できるタスクに、上限付きで」が原則です。

Reflection Agentの利用例：レポート校正・コード生成・リサーチ

実務では、下書きを自己校正するレポート生成、テストを回しながら修正するコード生成エージェント、検索結果を自己採点して深掘りするリサーチ用途（reflective research agent）などで使われています。いずれも「初回の答えをそのまま出さず、検証と改訂を挟む」という同じ骨格で、対象タスクに合わせて批評の根拠（テスト・検索・ルール）を差し替えている点が共通します。

よくある質問

Reflection Agentとは一言で言うと何ですか？

LLMが自分の出力を批評して書き直す「生成→批評→改訂」のループを持つエージェントです。単発生成に自己修正の工程を足した設計パターンだと捉えると分かりやすいです。

ReflexionとReflection Agentの違いは？

Reflection Agentは自己批評ループを持つエージェントの総称で、Reflexionはその代表的な具体手法です。Reflexionは失敗を言語で反省してメモリに蓄積し、次の試行に活かす点に特徴があります。

Self-RAGとはどう関係しますか？

Self-RAGは自己反省をRAGに組み込んだ手法で、reflection tokenを使って検索の要否や回答の根拠を自己判定します。Reflection Agentの考え方を検索拡張生成に適用したものと位置づけられます。

LangGraphでどう実装しますか？

生成ノードと批評ノードをStateGraphに置き、条件付きエッジで「合格なら終了・不合格なら改訂へ戻す」分岐を作ります。状態に反復カウンタを持たせ、上限で停止させるのが定石です。

教科書に出る「反射エージェント」と同じものですか？

別物です。シンプル反射エージェントやモデルベース反射エージェントは条件-行動ルールで即応する古典的な分類で、LLMの自己批評を行う本記事のReflection Agent（reflection＝内省）とは異なります。

関連記事

• LangChainとLangGraphの違い｜v1.0で逆転した関係と使い分け
• Agentic RAGのアーキテクチャと構成要素を詳しく解説
• Prompt Engineeringとの違いで理解するContext Engineeringの本質と全体像