今回の論文
今回取り上げるのは、Noah Shinn、Federico Cassano、Edward Berman らによる論文「Reflexion: Language Agents with Verbal Reinforcement Learning」です。2023 年 3 月に arXiv で公開された論文で、研究分野は AI エージェント、推論、コード生成、試行錯誤学習です。URL は https://doi.org/10.48550/arXiv.2303.11366 です。
この論文を選んだ理由は、モデルを追加学習しなくても、失敗の振り返りを言語化して次の試行に持ち越すだけで性能を大きく改善できるからです。最近のエージェント設計でも「メモリ」「自己改善」「反省ループ」は定番ですが、その原型をかなり明快に示した論文として実務への示唆が多いです。
どんな技術か
Reflexion は、AI エージェントが一度の試行でうまくいかなかったとき、その失敗を自然言語で振り返り、次回の試行でその振り返り文を追加コンテキストとして再利用する技術です。
普通の強化学習では、報酬を使ってモデルの重みを更新します。しかし LLM エージェントでは、そのたびに重み更新を回すのは重く、試行回数も高くつきます。Reflexion はそこを変えて、「失敗の教訓を文章にして覚える」という軽い学習ループに置き換えます。
ひとことで言えば、Reflexion は「重みではなくメモで賢くなるエージェント」です。コード生成、ツール利用、複数ステップのタスク実行のように、何度か試せる場面で特に効きます。
課題
Reflexion が解決しようとしているのは、LLM ベースのエージェントが試行錯誤から学びにくい問題です。
何が難しいのかというと、エージェント型タスクでは一回の応答で終わらず、行動して失敗し、その原因を踏まえて次を変える必要があるからです。たとえばツール呼び出し、Web 操作、コード修正、マルチステップ推論では、単発の出力品質だけでなく「前回の失敗を次回にどう反映するか」が重要になります。
既存の方法には限界があります。通常の CoT や ReAct は、その場の推論や行動計画はできますが、別試行にまたがる継続的な学習は得意ではありません。従来の強化学習を使えば改善の余地はありますが、報酬設計、学習コスト、試行サンプル数の面で重くなります。
なぜこの課題を解く必要があるのかというと、実際の AI システムでは「一発で正解する」より「数回のやり直しで確実に近づく」ほうが現実的な場面が多いからです。開発支援エージェントならテスト失敗から学びたいですし、業務自動化エージェントなら API エラーやフォーマット不一致を次回には避けたいはずです。
つまり Reflexion の問題設定は、「モデルの重みを触らずに、エージェントへ反省の蓄積をどう与えるか」です。
用語解説
- AIエージェント
- LLM が文章を出すだけでなく、外部環境を観測し、行動し、結果を見て次を決める仕組みです。Reflexion はこの「環境とやり取りする主体」をどう改善するかを扱っています。
- エピソードメモリ
- 過去の試行で何が起き、何を学んだかを保存する記憶です。Reflexion では失敗の振り返り文を長期メモリとして持たせ、次回プロンプトに差し込みます。
- Evaluator
- その試行が成功したか、どこが悪かったかを判定する評価器です。Reflexion では正解判定、ヒューリスティック、別 LLM など複数の評価方法を使える点が重要です。
- Self-Reflection
- 失敗結果をそのまま保持するのではなく、「次回どう直すべきか」という文章に要約する処理です。Reflexion の核は、この自然言語の反省文が次の行動改善に効くことです。
- Verbal Reinforcement Learning
- 数値報酬で重み更新する代わりに、言語化されたフィードバックを学習信号として使う考え方です。Reflexion を理解するうえでは、報酬を文章へ変換している点が重要です。
技術の仕組み
Reflexion の基本構成は比較的シンプルです。Actor が行動し、Evaluator が試行結果を評価し、Self-Reflection モデルが改善メモを生成します。そのメモを次回の Actor 入力に追加します。
基本アイデア
論文の中心アイデアは、失敗から得た信号を単なる 0/1 の報酬で終わらせず、「次に活かせる文章」に変換することです。たとえばコード生成なら「括弧の総数だけ見ており順序を確認していない」、意思決定タスクなら「探している物体の位置を取り違えた」といった形です。
この文章は、単なるログではなく、次回の試行時に参照される行動指針です。人間が「前回はここで勘違いしたから、次はそこを先に確認しよう」とメモするのに近い設計です。
モデル構造
Reflexion は 3 つの役割に分かれます。
Actor
Actor は実際に行動や回答を生成する LLM です。論文では CoT や ReAct ベースの Actor を使っています。現在の観測とタスク指示に加えて、過去の reflective text を読んだ上で次のアクションを決めます。
Evaluator
Evaluator は、その試行が成功か失敗かを判定します。タスクによって設計は変わります。推論タスクでは exact match、意思決定タスクではヒューリスティック、プログラミングではコンパイラやユニットテスト、場合によっては別の LLM を使います。
ここで重要なのは、評価器が必ずしも学習済み reward model でなくてよい点です。既存システムにあるテスト、ルール、ログ検証器をそのまま評価器として流用しやすい設計です。
Self-Reflection モデル
Self-Reflection モデルは、軌跡、評価結果、過去メモを入力として「なぜ失敗したか」「次に何を変えるべきか」を自然言語で生成します。論文ではこの文章を experience summary として長期メモリに保存します。
数値報酬よりも文章が有利なのは、どこを直すかを具体的に指示しやすいからです。たとえば「失敗した」だけでは次の行動に落ちませんが、「開き括弧と閉じ括弧の順序を確認していない」は次回の探索方針になります。
処理の流れ
1 回の試行では、Actor がタスクに対して行動列または回答を出します。Evaluator が成功可否や誤りを判定します。失敗した場合、Self-Reflection モデルが反省文を生成し、その文章をメモリへ追加します。次の試行では、そのメモリを含むプロンプトで Actor が再挑戦します。
この流れは、重み更新なしの policy improvement に近いです。論文では、方策を「LLM 本体 + メモリ状態」とみなし、メモリの更新で次回行動を変える形にしています。
重要な工夫
フィードバックを自然言語に増幅する
Reflexion では、二値報酬やテスト結果をそのまま使うのではなく、文章へ変換します。これによって credit assignment、つまり「何が悪かったのか」の解像度を上げています。
タスクごとに評価器を差し替えられる
論文では、意思決定、推論、プログラミングで異なる評価方法を使っています。つまり Reflexion は単一ベンチマーク専用ではなく、評価器を交換できるエージェントループとして設計されています。
メモリを少量でも効かせる
巨大な履歴を全部入れるのではなく、失敗から得た短い教訓を持たせるだけでも性能が伸びます。これは実装上かなり重要で、トークンコストを抑えながら改善ループを作れることを意味します。
実験と結果
論文では、Reflexion を意思決定、推論、プログラミングという 3 種類のタスクで評価しています。狙いは「反省メモ」が特定タスク専用の小技ではなく、広く効く学習インターフェースかどうかを確かめることです。
何を検証したのか
主な検証は 3 つです。1 つ目は、複数試行が必要な環境で行動改善できるかです。2 つ目は、知識推論のような単発生成でも、失敗理由を次回へ渡すことで改善できるかです。3 つ目は、コード生成でテスト結果と自己反省を組み合わせると pass@1 が伸びるかです。
意思決定タスクでの結果
論文では AlfWorld で、Reflexion が 12 回の反復学習ステップを通じて強い改善を示したと報告しています。本文では、強いベースラインに対して絶対値で 22 ポイント改善したと述べています。
この結果から言えるのは、複数ステップ行動では「その場で考える力」だけでなく、「前回どこで取り違えたかを覚える力」が効くということです。ツール利用エージェントや業務フロー実行でも、この性質はかなり重要です。
推論タスクでの結果
HotPotQA では、Reflexion によって 20 ポイントの改善があったと論文で報告されています。推論タスクは環境操作より短いですが、それでも前回の誤答理由を次回へ渡すことで性能が上がる点が興味深いです。
これは「反省」は長い行動列だけに効くのではなく、知識推論や回答生成でも有効な場合があることを示しています。特に、取り違えや早合点が多い QA 系エージェントで参考になります。
コード生成タスクでの結果
もっとも目を引くのは HumanEval です。論文の Table 1 では、HumanEval Python の pass@1 が GPT-4 ベースの 80.1 から Reflexion で 91.0 へ伸びています。Rust 版 HumanEval でも 60.0 から 68.0 へ改善しています。Leetcode Hard の Python でも 7.5 から 15.0 と 2 倍になっています。
一方で MBPP Python では 80.1 から 77.1 と下がっており、常に改善するわけではありません。論文では、自己生成テストの false positive が高いと、誤ったコードを正しいと判定してしまい性能が落ちうると分析しています。
アブレーションでわかったこと
論文の Rust HumanEval のアブレーションでは、自己生成テストも自己反省も両方入れた Reflexion が 0.68 で最良でした。自己反省を外すと 0.60、テスト生成を外すと 0.52 です。つまり、単にテストを回すだけでも、単に書き直させるだけでも足りず、「評価」と「反省」の接続が効いていると読めます。
何に使える？
Reflexion の価値は、失敗ログが取れるエージェントなら比較的広く応用できることです。特に、再試行コストは許容できるが、毎回同じ失敗を繰り返してほしくない場面に向いています。
開発支援エージェント
コード修正、テスト修正、CI エラー対応では、失敗理由が比較的明確です。コンパイルエラー、テスト落ち、型不一致、API シグネチャ誤認を反省メモへ変換すれば、次回の提案で同じミスを減らせます。論文の HumanEval 結果を見ると、この方向はかなり相性が良いです。
業務自動化エージェント
社内 API 連携、入力フォーム処理、請求や申請ワークフローでは、失敗時にルール違反や不足項目が返ってきます。そうしたエラー文をそのまま再投入するのではなく、「次に何を確認すべきか」の教訓に要約して残すと、同種タスクの成功率改善が期待できます。これは論文の直接検証範囲ではありませんが、Evaluator を差し替えられる設計から自然に導ける応用です。
ツール利用型の社内アシスタント
検索、SQL、ドキュメント参照、チケット更新など複数ツールを使うエージェントでは、失敗の多くが手順ミスか前提確認漏れです。Reflexion 的なメモリを入れると、「先にユーザー ID を確認する」「更新前に現状態を読む」といった運用知識を蓄積しやすくなります。
顧客対応やサポート運用
問い合わせ分類や回答案生成でも、「この質問は課金ではなく契約変更」「このケースでは本人確認が先」といった判断ミスの教訓を蓄積できます。実運用では評価器設計が必要ですが、反省メモが FAQ や社内ルールの運用知識として機能する可能性があります。ここは応用上の考察です。
開発や事業へのヒント
この論文から得られる実務上のヒントは、エージェント改善を必ずしもファインチューニングや巨大な履歴ストレージに寄せなくてよいことです。短い反省文の設計だけでも、改善ループをかなり作れます。
まず失敗ログを「次の指示文」に変換する
多くのエージェント実装では、失敗ログを保存して終わりがちです。しかし Reflexion の視点では、必要なのは保存より要約です。自分で AI アプリを作るなら、エラー内容をそのまま渡すのではなく、「次回の実行前に何を確認すべきか」に変換するだけで挙動が安定する可能性があります。
評価器が先、学習は後
Reflexion は、良い評価器があるほど活きます。つまりプロダクト開発では、先に pass/fail 判定、ルール違反検出、期待出力との差分チェックを整備する価値が高いです。モデルを賢くする前に、改善ループの採点系を作るほうが費用対効果が良いケースがあります。
小規模プロダクトでも導入しやすい
この手法は重み更新なしでも成立するため、LoRA 学習や独自基盤がなくても試せます。たとえば 1 タスクごとに 1 行の教訓を残し、次回プロンプトに上位数件だけ入れる実装なら、小さな SaaS や社内ツールでも始めやすいです。
今後注目すべき方向性
今後は Reflexion 単体より、長期メモリ、検索、ワークフロー制御、評価ベンチマークと組み合わせる流れが重要だと考えられます。特に「どの反省を残すか」「どの反省を検索するか」が品質を左右するので、メモリ管理そのものが競争力になりそうです。これは論文の結果を踏まえた将来方向の考察です。
限界
Reflexion にも注意点があります。まず、良い反省文を作るには良い評価器が必要です。誤った評価や曖昧な採点をすると、間違った教訓を記憶してしまいます。
また、メモリが増えすぎるとノイズになります。役に立たない反省や古いルールが残ると、次回推論をむしろ乱す可能性があります。実運用では、どのメモを保持し、いつ捨てるかの設計が必要です。
精度面でも万能ではありません。論文でも MBPP Python のように改善しないケースがあります。自己生成テストや自己評価が弱いと、誤った成功判定が起きて反省ループが壊れます。
さらに、Reflexion は試行を重ねて改善する仕組みなので、一発回答しか許されない場面では恩恵が限定的です。レイテンシや API コストが厳しい本番では、何回まで再試行できるかも設計上の制約になります。
よくある質問
Q. Reflexion は普通の ReAct と何が違うのですか？
A. ReAct は 1 回の試行の中で考えながら行動する枠組みですが、Reflexion は複数試行にまたがって失敗の教訓を持ち越す点が違います。つまり、その場の推論だけでなく「前回の失敗から学ぶ仕組み」を追加しています。
Q. Reflexion を使うにはモデルの追加学習が必要ですか？
A. 論文の中心アイデアでは必須ではありません。重み更新なしで、評価結果を自然言語のメモへ変換し、次回プロンプトへ入れるだけでも改善が起きます。
Q. どんなタスクで特に効きやすいですか？
A. 失敗理由が比較的観測しやすく、再試行できるタスクで効きやすいです。たとえばコード生成、ツール実行、業務フロー自動化、複数ステップの検索や操作です。
Q. なぜ数値報酬より文章の反省が効くのですか？
A. 数値報酬だけでは「何を直すべきか」がわかりにくいからです。文章化すると、Actor が次回の意思決定で参照できる具体的な改善方針になります。
Q. 実運用で導入するなら最初に何を作るべきですか？
A. まずは評価器です。成功失敗の判定、ルール違反検出、期待出力との差分確認がないと、良い反省メモを作れません。その上で、短い教訓を保存して次回へ渡す最小ループから始めるのが現実的です。
今日の学び
この論文は、LLM ベースの AI エージェントが試行錯誤から学びにくい課題を扱いました。これに対して Reflexion は、評価結果を自然言語の反省メモへ変換し、そのメモを次回試行のコンテキストへ入れることで解こうとしました。
ここから得られるヒントは、エージェント改善は必ずしも重い再学習を必要としないということです。失敗を次の行動ルールへ変換する設計を入れるだけでも、開発支援や業務自動化の実装品質をかなり底上げできる可能性があります。