---
title: "Reflection Agentとは？Reflexion・Self-Refineとの違いとLangGraph実装"
url: "https://www.issoh.co.jp/tech/details/4055/"
published: 2024-11-04
updated: 2026-10-28
categories: ["AIエージェント・MCP"]
publisher: "株式会社一創"
---

# Reflection Agentとは？Reflexion・Self-Refineとの違いとLangGraph実装

Reflection Agentは、LLMが出した回答をLLM自身（または別のLLM）に批評させ、その指摘を入れて書き直すループを持たせたエージェントの設計です。効果の報告ははっきりしています。Reflexionの論文は、コード生成のベンチマークHumanEvalでpass@1 91.0%を報告し、GPT-4単体の80.1%を上回りました。一方で別の論文は、外部からの手がかりを与えずにGPT-4に2回見直させると、算数の文章題GSM8Kの正答率が95.5%から89.0%に下がったと報告しています。この記事では、手法ごとの違い、効く条件と効かない条件、langgraph 1.2.18で実際に動かした実装、教科書に出てくる「反射エージェント」との違いまでを整理します。

## まとめ：Reflection Agentの要点

- **正体**：生成→批評→改訂のループを持つエージェント。重みは更新せず、推論時の呼び出しを重ねて出力を直す。
- **代表手法**：Basic Reflection（生成役と批評役の往復）、Self-Refine（同じモデルで反復）、Reflexion（反省文を記憶に積んで再挑戦）、CRITIC（ツールの検証結果で直す）、Self-RAG（reflection tokenで検索と根拠を自己判定）、LATS（反省と木探索の組み合わせ）。
- **効く条件**：テスト実行・スキーマ検証・規則照合など、合否を機械で決められる信号を批評役に渡せること。根拠がモデルの主観だけなら、正しい答えを書き換えて精度が下がることがある。
- **実装**：LangGraphのStateGraphで生成ノードと批評ノードを条件付きエッジで往復させ、合格・上限回数・同じ指摘の繰り返しで止める。
- **入れない場面**：応答時間の予算を超える対話、評価基準を用意できない主観評価、単発生成で正答率が足りている処理。呼び出しが1周ごとに2回増える。
- **別概念**：AIの教科書に出る「シンプル反射エージェント」「モデルベース反射エージェント」はreflex agent（条件と行動の規則で即応する分類）で、Reflection Agentとは関係がない。

## Reflection Agentの定義と生成・批評・改訂の3役

Reflection Agentは3つの役に分けると理解しやすくなります。課題を解いて出力を作る生成役（Generator・Actor）、その出力を点検して誤りや抜けを言葉で指摘する批評役（Critic・Evaluator）、指摘を読んで書き直す改訂役（Reviser）です。改訂した出力をもう一度批評にかけることで、ループになります。同じモデルにプロンプトを切り替えて全部を担わせる構成と、役ごとに別のモデルやエージェントを置く構成の両方があります。

LangChainの公式ブログ[「Reflection Agents」](https://www.langchain.com/blog/reflection-agents)（2024年2月21日）は、reflectionを「エージェントの品質と成功率を上げるためのプロンプト戦略」と位置づけ、Basic Reflection・Reflexion・LATSの3つをLangGraphで実装しています。

### 単発生成・単純なリトライとの違い

同じ質問をもう一度投げる再試行や、温度を変えて出し直す操作でも出力は変わります。ただし前回どこが駄目だったかはどこにも残らず、試行は互いに独立です。Reflection Agentでは「どこが、なぜ駄目か」という指摘が次の生成の入力に載ります。この差が効くのは、失敗の原因が言葉で表せて、次の試行でも同じ原因が起きる場合です。効果を確かめるときは、単純な再試行と、前回の出力と指摘を渡す構成を同じ呼び出し回数で比べます。

### 「リフレクションAI」「reflection」が指す別の対象

「リフレクションAI」「reflection llm」で調べると、性格の違う対象が混ざります。この記事が扱うのは1行目の推論時のループです。

| 呼び方の対象                 | 中身                 | 本記事での扱い  |
| ---------------------- | ------------------ | -------- |
| Reflection Agent・自己反省  | 推論時に批評と書き直しを回す     | 主題       |
| Reflection-Tuning      | 誤りの検出と修正を学習させたモデル  | 学習側の話    |
| Reflection AI社         | オープンなモデルを開発する企業    | 企業名      |
| reflex agent（反射エージェント） | 条件と行動の規則で即応する古典的分類 | 下の章で切り分け |
| プログラミングのリフレクション        | 実行時に型やメソッドの情報を読む   | AIと無関係   |

Reflection-Tuningは、[Reflection Llama-3.1 70Bのモデルカード](https://huggingface.co/mattshumer/Reflection-Llama-3.1-70B)が説明している学習手法で、推論中の誤りを見つけて直す動作を学習させ、思考を`<thinking>`、修正を`<reflection>`、最終回答を`<output>`のタグで出力させます。同じモデルカードの冒頭には、最初の公開時にモデルに問題があったという注記があります。重みを変える話なので、本記事のループ設計とは別物です。プログラミング用語のほうは[リフレクションとは？実行時にクラス情報を操る仕組みを言語横断で解説](/tech/details/15262/)で扱っています。

## 反射エージェント（reflex agent）との違いとエージェントの5分類

「シンプル反射エージェント」「モデルベース反射エージェント」は、Russell と Norvig の教科書『Artificial Intelligence: A Modern Approach』（AIMA）がエージェントを分類するときの用語です。reflection（内省）ではなくreflex（反射）で、LLMの自己批評とは仕組みも目的も違います。

| 分類             | 行動を決める材料         | 例                  |
| -------------- | ---------------- | ------------------ |
| シンプル反射エージェント   | 現在の知覚と条件-行動規則だけ  | 温度が閾値を超えたら冷房を入れる   |
| モデルベース反射エージェント | 知覚の履歴から保つ内部状態と規則 | 見えない車線の車を覚えて車線変更する |
| ゴールベースエージェント   | 達成したい目標と行動の結果予測  | 目的地までの経路を探索する      |
| 効用ベースエージェント    | 結果の望ましさを数値化した効用  | 速さと安全を比べて経路を選ぶ     |
| 学習エージェント       | 経験から性能要素を改善する仕組み | 結果の評価から規則を更新する     |

AIMAの[公式目次](https://aima.cs.berkeley.edu/contents.html)では2.4.2〜2.4.6節がこの5つに当たります。本文は上の4つを基本のエージェントプログラムとし、どれも学習エージェントに作り替えられると説明しているので、5つ目は並列の種類というより4つに学習の仕組みを足したものです。シンプル反射エージェントは過去を持たず、今見えているものだけで動きます。モデルベース反射エージェントは、見えない部分を内部状態で補います。Reflection Agentは、出力を言葉で振り返って次に活かすという点で、むしろ表の最下段の学習エージェントの考え方に近い位置です。ただし重みや規則を書き換えるのではなく、反省文をプロンプトに足すだけなのが違いです。

## 代表手法の比較：Self-Refine・Reflexion・CRITIC・Self-RAG・LATS

「Reflection Agent」は総称で、狙いの違う手法がぶら下がっています。名前より先に、批評の根拠をどこから取るかで見分けると選びやすくなります。

| 手法                | 批評の根拠                   | 記憶       | 報告値の例                      |
| ----------------- | ----------------------- | -------- | -------------------------- |
| Basic Reflection  | 批評役LLMの判断               | 反復内の会話履歴 | なし（実装パターン）                 |
| Self-Refine（2023） | 同じモデルの自己フィードバック         | 反復内のみ    | 7タスク平均で約20ポイント改善           |
| Reflexion（2023）   | Evaluatorの信号（テスト結果など）   | エピソード記憶  | HumanEval pass@1 91.0%     |
| CRITIC（2023）      | 検索・コード実行などのツール          | なし       | ツール検証で修正                   |
| Self-RAG（2023）    | reflection tokenによる自己判定 | なし       | 専用に学習したモデルが前提              |
| LATS（2023）        | 反省と価値評価＋木探索             | 探索木      | HumanEval pass@1 92.7%（v3） |

### Reflexion：反省文をエピソード記憶に積んで再挑戦

[Reflexion（Shinn ら、arXiv:2303.11366）](https://arxiv.org/abs/2303.11366)は、重みを更新せずに言葉のフィードバックで言語エージェントを強化する枠組みです。行動を担うActor、結果を採点するEvaluator、採点を反省文に変えるSelf-Reflectionモデルの3つに分かれ、反省文をエピソード記憶に保持して次の試行のプロンプトに足します。論文の表1では、HumanEval（Python）のpass@1がGPT-4の80.1%に対しReflexionが91.0%です。同じ表で、別のコード生成ベンチマークMBPP（Python）ではGPT-4の80.1%に対しReflexionが77.1%と、逆に下がっています。テストという外部信号があっても、必ず上がるわけではありません。

この数字には前提があります。この実験では、モデルが自己生成した単体テストの実行結果をEvaluatorに渡します。テスト自体が誤る可能性があり、最終評価に使う非公開テストの正解信号を修正中に得ているわけではありません。また、pass@1は内部で修正を重ねた後の提出解を評価した値で、LLMの1回の呼び出しを意味しません。正解を定義できない要約や提案文に同じ構成を持ち込んでも、Evaluatorの位置にモデルの主観が入るだけで、報告値の条件は再現されません。実装は[著者のGitHubリポジトリ](https://github.com/noahshinn/reflexion)で公開されています。

### Self-Refine：同一モデルによる生成・批評・改訂の反復

[Self-Refine（Madaan ら、arXiv:2303.17651）](https://arxiv.org/abs/2303.17651)は、1つのLLMが出力を作り、その出力にフィードバックを書き、フィードバックで改訂する反復を回します。教師データも追加学習も強化学習も使いません。対話応答の生成から数学的推論まで7種類のタスクで、1回だけの生成より平均で約20ポイント（絶対値）良い結果になったと報告されています。

この平均をそのまま一般則にすると外れます。論文の表1でGPT-4の内訳を見ると、コード最適化は27.3%から36.0%へ8.7ポイント伸びた一方、数学的推論は92.9%から93.1%で0.2ポイントしか動いていません。形式や網羅性のように見れば分かる欠陥は自己フィードバックで拾えますが、計算や事実の誤りは同じモデルには見えにくいということです。

### Self-RAG：reflection tokenで検索と根拠を自己判定

[Self-RAG（Asai ら、arXiv:2310.11511）](https://arxiv.org/abs/2310.11511)は、RAG（検索拡張生成）に自己判定を組み込んだ手法です。モデルが生成の途中でreflection tokenという特殊トークンを出し、検索するか（Retrieve）、取ってきた文書が関連するか（IsRel）、回答が文書に裏付けられているか（IsSup）、回答が役に立つか（IsUse）を判定しながら進みます。値は、Retrieveがyes・no・continue、IsRelがrelevant・irrelevant、IsSupがfully supported・partially supported・no support、IsUseが5〜1の5段階です。常に検索するのではなく必要なときだけ検索する点が通常のRAGとの違いです。トークンを出せるように学習したモデルを使う前提なので、プロンプトだけで組むReflection Agentとは実装の入口が違います。検索の要否をエージェントが決める構成は[Agentic RAGとは？従来RAGとの違い・設計パターンとLangGraph実装の落とし穴](/tech/details/8079/)で扱っています。

### LATS：反省と木探索の組み合わせ

[LATS（Zhou ら、arXiv:2310.04406）](https://arxiv.org/abs/2310.04406)は、モンテカルロ木探索の選択・展開・評価・シミュレーション・逆伝播に反省（reflection）を加えた6つの操作で、1本の試行ではなく複数の行動の枝を探索します。LangChainのブログは、Reflexionが1本の軌跡しか追わないため途中の誤りが後の判断に響くと指摘し、LATSをその弱点への答えとして紹介しています。HumanEvalのpass@1は、2024年6月の改訂版（v3）でGPT-4を使い92.7%と報告されています（2023年の初版では94.4%）。ただし枝ごとに呼び出しが増えるので、費用はReflexionより重くなります。

## 自己修正が効かない条件：外部フィードバックの有無

反対側の証拠もあります。[Huang ら「Large Language Models Cannot Self-Correct Reasoning Yet」（arXiv:2310.01798、ICLR 2024）](https://arxiv.org/abs/2310.01798)は、外部のフィードバックを使わずにモデル自身の判断だけで回答を見直させる「内在的な自己修正」を検証し、推論課題では改善せず、見直し後に成績が下がる場合もあると報告しました。2023年8月29日にアクセスしたGPT-4を用い、GSM8KとCommonSenseQAは各200問、HotpotQAは100問を検索なしで評価した結果です。2回の自己修正後、正答率は順に95.5%から89.0%、82.0%から80.0%、49.0%から43.0%へ下がりました。批評役は「指摘せよ」と言われると、正しい答えにも何か欠点を挙げがちで、改訂役がそれを真に受けて正解を書き換えるからです。

[CRITIC（Gou ら、arXiv:2305.11738）](https://arxiv.org/abs/2305.11738)は逆の立場から、検索やコード実行といった外部ツールの結果を根拠に出力を直す構成を提案しました。Reflexionの91.0%も、テスト実行という外部の合否信号があっての数字です。これらの報告から、外部フィードバックは採用判断で確認すべき条件の一つです。ただし、それだけで効果は決まりません。課題、モデル、批評の正確さ、停止条件をそろえて単発生成と比較する必要があります。

## LangGraphによるReflection Agentの実装

ループと分岐を持つReflection Agentは、状態を持つグラフとして書けるLangGraphと相性が良い題材です。単純な一直線の処理と、反復や分岐を含むフローの書き分けは[LangChainとLangGraphの違いと使い分け｜v1.0以降の関係をコードで確認](/tech/details/4059/)を参照してください。

### 生成・批評ノードと条件付きエッジによる反復制御

次のコードは、langgraph 1.2.18・langchain-core 1.7.0（Python 3.12）で実行を確かめたものです。APIキーなしで動くように、生成役は決まった応答を順に返す `GenericFakeChatModel` にしてあります。本番では `init_chat_model` などで実際のモデルに差し替えます。批評役はLLMに頼らず、「60文字以内」「必須語を含む」という機械で確かめられる条件で採点しています。

```
from typing import TypedDict
from langgraph.graph import StateGraph, START, END
from langchain_core.language_models.fake_chat_models import GenericFakeChatModel
from langchain_core.messages import HumanMessage

MAX_ITERATIONS = 3
REQUIRED = ["LangGraph", "上限"]  # 必ず含める語
LIMIT = 60                         # 文字数の上限

class State(TypedDict):
    task: str
    draft: str
    feedback: str
    iterations: int

# 動作確認用の偽モデル。本番は init_chat_model("<プロバイダ>:<モデル名>") などに差し替える
llm = GenericFakeChatModel(messages=iter([
    "Reflection Agentは生成と批評を繰り返して回答の質を高める設計パターンで、さまざまなタスクに使えます。",
    "LangGraphで生成と批評を往復させ、反復の上限で止める設計です。",
]))

def generate(state: State) -> dict:
    prompt = state["task"]
    if state["feedback"]:
        prompt += "\n\n前回の下書き:\n" + state["draft"] + "\n\n前回への指摘:\n" + state["feedback"]
    draft = llm.invoke([HumanMessage(prompt)]).content
    return {"draft": draft, "iterations": state["iterations"] + 1}

def critique(state: State) -> dict:
    # 批評はLLMの自己評価ではなく、機械で確かめられる条件で行う
    problems = []
    if len(state["draft"]) > LIMIT:
        problems.append(f"{len(state['draft'])}文字ある。{LIMIT}文字以内に削る")
    for word in REQUIRED:
        if word not in state["draft"]:
            problems.append(f"「{word}」が入っていない")
    return {"feedback": "\n".join(problems)}

def should_continue(state: State) -> str:
    if not state["feedback"]:
        return "end"      # 合格
    if state["iterations"] >= MAX_ITERATIONS:
        return "end"      # 上限で打ち切り
    return "revise"

builder = StateGraph(State)
builder.add_node("generate", generate)
builder.add_node("critique", critique)
builder.add_edge(START, "generate")
builder.add_edge("generate", "critique")
builder.add_conditional_edges("critique", should_continue,
                              {"revise": "generate", "end": END})
graph = builder.compile()

for update in graph.stream({"task": "Reflection Agentを60文字以内で説明して",
                            "draft": "", "feedback": "", "iterations": 0},
                           stream_mode="updates"):
    print(update)
```

実行すると、各ノードの更新が次の順で出ます。1回目の下書きは必須語が2つ抜けているので批評で差し戻され、2回目で指摘が空になって終わります。この例は分岐と停止の動作確認用で、モデルが批評を理解して改善したことを検証するものではありません。同じ指摘の繰り返しによる停止は未実装で、MAX\_ITERATIONSは初回を含む生成回数の上限です。

```
{'generate': {'draft': 'Reflection Agentは生成と批評を繰り返して回答の質を高める設計パターンで、さまざまなタスクに使えます。', 'iterations': 1}}
{'critique': {'feedback': '「LangGraph」が入っていない\n「上限」が入っていない'}}
{'generate': {'draft': 'LangGraphで生成と批評を往復させ、反復の上限で止める設計です。', 'iterations': 2}}
{'critique': {'feedback': ''}}
```

押さえどころは3つです。合否を決めるのがモデルではなくコードであること。反復回数を状態に持ち、上限で必ず抜けること。批評は「どこを・なぜ・どう直すか」が分かる文で返し、次の生成のプロンプトにそのまま貼れる形にすることです。批評役をLLMにするときも、テスト結果や検証エラーの生データを渡して、根拠のない評価をさせないようにします。エージェント全体の状態設計や承認フローまで含めた組み方は[LangGraphでAIエージェントを実装する手順：状態管理から承認フローまで](/tech/details/17447/)にまとめています。

### langgraph-reflectionのcreate\_reflection\_graphを使う場合

LangChainは、本体のグラフと批評用のグラフを渡すだけでループを作る[langgraph-reflection](https://github.com/langchain-ai/langgraph-reflection)も公開しています。批評グラフが `HumanMessage` を返すとそれを指摘として本体グラフへ戻し、何も返さなければ終了します。上限は再帰回数の残り（`remaining_steps`）で判定されます。

注意点があります。PyPIの版は2025年3月10日公開の0.0.1だけで、langgraph 1.2.18と組み合わせて既定のまま呼ぶと `AttributeError: 'StateGraph' object has no attribute 'schema'` で止まりました（2026年10月28日に実行して確認）。`create_reflection_graph(graph, reflection, state_schema=MessagesState)` のように状態の型を明示し、返されたStateGraphをcompileしてから実行します。公式リポジトリはアーカイブ済み（読み取り専用。2026年10月28日にGitHubで確認）なので、本番では上のように自分でStateGraphを組むほうが挙動を追いやすいと判断します。

## 批評役に渡す外部信号の3系統

実務で用意できる外部信号は、おおむね次の3系統です。上ほど判定が確かで、そのぶん使える範囲が狭くなります。

| 系統     | 信号の中身         | 向く処理        | 限界          |
| ------ | ------------- | ----------- | ----------- |
| テスト実行  | 単体テストの成否と例外   | コード生成・SQL生成 | テストの網羅性に依存  |
| スキーマ検証 | 型・必須項目・列挙値の違反 | 構造化出力・API連携 | 形式だけで内容は見ない |
| 規則照合   | 禁止語・数値範囲・文字数  | 文書生成・帳票チェック | 規則を作り込む手間   |

検索結果や外部APIの応答を根拠にする形も取れますが、その場合はLLMからツールを呼ぶ設計と権限の扱いが先に要ります（[AIツール使用（Tool Use）とは？LLMが外部を呼ぶ仕組みと実装の判断基準を解説](/tech/details/16314/)）。この3系統を用意できない場合は、検索による根拠照合や人による評価など、別のフィードバックを検討します。評価手段を用意できず、改善と劣化を区別できない処理では採用を見送ります。

批評のプロンプトは、評価軸を箇条書きで与え、指摘を「対象箇所・違反した条件・修正の方向」の3点で返させます。「もっと良くして」のような総評では改訂役が何を直せばよいか決められません。会話履歴を渡す構成と、課題・評価基準・対象出力だけを渡す構成を比較し、指摘の正確さを評価します。「他人が書いた成果物」として提示する方法も、効果を検証してから採用します。批評文を状態として持ち回り、次の生成に確実に入れる設計は[コンテキストエンジニアリングとは？プロンプトエンジニアリングとの違いと4つの実装手法](/tech/details/11165/)の考え方と同じです。

## 失敗モードと止め方：正答の書き換え・甘い批評・振動

### 正しい答えを誤答に書き換える劣化

Huangらの論文（arXiv:2310.01798）では、自己修正によって正答が誤答に変わる事例が分析されています。全体の正答率だけを見ていると、改善した件と劣化した件が打ち消し合って見えなくなります。初回出力と最終出力の両方を評価データにかけ、「初回○→最終×」の件数を別に数えてください。劣化が目立つなら、批評役に「直すべき点が無ければ指摘なしと返す」選択肢をはっきり与えます。

### 批評が甘くなる・厳しすぎる偏り

同一モデルで生成と批評を行うSelf-Refineのような構成では、批評が実際の欠陥を検出できるか、欠陥のない出力にも指摘してしまわないかを評価します。批評役に「厳しく点検せよ」と強く指示すると、言い回しまで指摘して不要な書き換えを招くこともあります。緩和策は、批評役だけ別のモデルにするか、同じモデルに複数回批評させて共通して挙がった指摘だけを採るかです。批評役の判定そのものが妥当かは、別に測る必要があります。測り方は[AIエージェント評価とは？軌跡・ツール呼び出し・タスク達成を測る指標と実装の進め方](/tech/details/15942/)で扱っています。

### 同じ指摘を繰り返す振動と、止める条件

停止条件の無いループは、同じ指摘と同じ修正の間を行き来します。止める条件は次の3つを並べて置きます。外部信号が合格を返したとき、指摘が前回とほぼ同じになったとき、上限回数に達したときです。上限は2〜3回から始め、手元の評価データで反復ごとの合格率と累積トークン量を並べ、増分が費用に見合わなくなった回に決めます。上限に達したときに何を返すか（最終出力・初回出力・人の確認へ回す）も先に決めておかないと、最も壊れた出力が返る実装になりがちです。エージェントのループ一般の止め方は[エージェントループとは？止まる条件とSDK別の反復上限を実測で解説](/tech/details/13602/)を参照してください。

### 呼び出し回数と待ち時間の見積もり

費用は呼び出し回数と各回の入出力トークン数に依存します。履歴をすべて保持すれば1回あたりの入力も増えますが、直前の出力と指摘だけを渡して長さを制限する構成では、反復回数におおむね比例する場合もあります。以下は初回生成の後に、LLMによる批評と改訂を1周として数えた例です。

| 観点        | 単発生成  | 1周       | 3周          |
| --------- | ----- | -------- | ----------- |
| LLM呼び出し   | 1回    | 3回       | 最大7回        |
| 入力トークン    | 課題文のみ | 出力と指摘を追加 | 反復ごとに累積     |
| 待ち時間の概算条件 | 生成1回  | 生成＋批評＋改訂 | 生成＋批評・改訂各3回 |

批評をコードで行う上のサンプルなら、LLM呼び出しは1周あたり1回で済みます。夜間のバッチなら3周でも成り立ち、人を待たせる対話画面なら1周でも成り立たないことがあります。

## Reflection Agentを採用する条件と見送る条件

採用してよいのは、次の2つを同時に満たす処理です。1つ目は、テスト実行・スキーマ検証・規則照合・検索による照合などで、改善したか劣化したかを確かめられること。2つ目は、採用する構成で呼び出し回数・入出力トークン数・待ち時間を測り、品質の改善が追加費用に見合うこと。コード生成、SQL生成、構造化データの抽出、帳票の整合チェックがこれに当たります。

次のどれか1つに当てはまるなら見送ります。

- **応答時間の予算が厳しい**：対話画面で数秒以内に返す要件があるなら、反復を含む応答時間を測り、その予算を超える構成は見送る。
- **評価基準の無い主観評価**：文章の良し悪しや提案の妥当性を評価する基準や人による比較評価を用意できない場合は、改善と劣化を判別できないため採用を見送る。
- **単発で正答率が足りている**：伸びしろが無いところに反復を足しても、費用と書き換えのリスクだけが増える。

判断の手順は、まず単発で解かせて誤りを分類することです。誤りが形式や制約の違反に集中しているならReflection Agentが効きます。知識不足や参照情報の不足に集中しているなら、直すべきはループではなく検索や参照データの渡し方です。思考と行動を交互に回すReActとの使い分けは[ReActパターンとは？思考と行動を交互に回す仕組みと採用判断を実装目線で解説](/tech/details/16312/)で整理しています。検証の仕組みまで含めて業務に組み込む段階では、[AIエージェント開発の支援](/service/ai/agent/)のように外部の実装体制を使う選択肢もあります。

## よくある質問

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

LLMが自分の出力を批評して書き直す「生成→批評→改訂」のループを持つエージェントです。モデルの重みは変えず、推論時の呼び出しを重ねて出力を直します。

### ReflexionとReflection Agentの違いは？

Reflection Agentは自己批評ループを持つエージェントの総称で、Reflexionはその代表的な手法の1つです。Reflexionは失敗を反省文にしてエピソード記憶に積み、同じ課題に再挑戦するときに参照させる点が特徴で、HumanEvalでpass@1 91.0%を報告しています。

### 自己反省を入れれば精度は必ず上がりますか？

上がりません。外部フィードバックを使わない内在的な自己修正では、推論課題の成績が下がる場合があるとICLR 2024の論文（arXiv:2310.01798）が報告しています（GPT-4のGSM8Kで95.5%から89.0%）。上がりやすいのは、テスト実行やスキーマ検証のように合否を機械で決められる信号を批評役へ渡せる処理です。

### 反復は何回まで回すのが現実的ですか？

2〜3回から始めます。上限回数に加えて、合格したとき・指摘が前回とほぼ同じになったときにも打ち切り、上限に達したときに何を返すかを先に決めておきます。

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

別物です。シンプル反射エージェントやモデルベース反射エージェントは、AIMAの教科書が使うreflex agent（条件と行動の規則で即応する方式）の分類で、LLMの自己批評を行うReflection Agent（reflection＝内省）とは関係がありません。

## 関連記事

- [LangChainとLangGraphの違いと使い分け｜v1.0以降の関係をコードで確認【2026年10月】](/tech/details/4059/)
- [LangGraphでAIエージェントを実装する手順：状態管理から承認フローまで](/tech/details/17447/)
- [ReActパターンとは？思考と行動を交互に回す仕組みと採用判断を実装目線で解説](/tech/details/16312/)
- [Agentic RAGとは？従来RAGとの違い・設計パターンとLangGraph実装の落とし穴](/tech/details/8079/)
- [AIエージェント評価とは？軌跡・ツール呼び出し・タスク達成を測る指標と実装の進め方【2026年版】](/tech/details/15942/)

---

出典: [Reflection Agentとは？Reflexion・Self-Refineとの違いとLangGraph実装](<https://www.issoh.co.jp/tech/details/4055/>)（株式会社一創）