AIの自己反省とは？Reflexionの仕組みと自己修正ループの実装・見送り条件を解説【2026年版】

コード生成ベンチマークHumanEvalで、GPT-4単体のpass@1は80%、失敗を言語で振り返らせて再挑戦させる枠組みでは91%が報告されています（Shinn et al., arXiv:2303.11366）。ところが同じ「自分で直させる」でも、外部からの手がかりを与えない条件では正答が誤答へ書き換わり、成績が下がる場合があると報告した論文もあります（Huang et al., arXiv:2310.01798・ICLR 2024）。分かれ目は自己反省という言葉の中身です。この記事では、AIの自己反省を処理として定義し直し、ReflexionとSelf-Refineの構成、外部フィードバック信号の作り方、反復回数と停止条件、そして入れない条件までを実装目線で整理します。

まとめ：自己反省が効く条件と、単発生成のままでよい境界

AIの自己反省とは、モデルが出した出力を同じモデル（または別のモデル）に批判させ、その批判文を次の生成へ入力として渡す処理を指します。単なる再試行と違うのは、「どこが、なぜ駄目だったか」という言語化された指摘が次の試行に残る点です。Reflexionはこの指摘を記憶バッファに蓄積し、Self-Refineは1本の反復ループの中で回します。

実装上の分岐は1つだけです。批判の根拠になる外部信号があるかどうか。テストの失敗ログ、スキーマ検証のエラー、規則との突き合わせ結果といった機械的に真偽が判定できる材料を批判役に渡せる処理では、反復のたびに出力が正解へ寄ります。根拠がモデルの主観しかない場合、内在的な自己修正は改善せず劣化しうると報告されており、費用と待ち時間だけが増えます。

費用構造も先に押さえてください。生成・批判・再生成で呼び出しは1周あたり3回になり、反復のたびに直前までの出力と指摘を再投入するため入力トークンも積み上がります。応答時間に1秒未満の予算がある画面、正解が一意に決まらない主観評価の課題、単発生成で正答率が足りている処理には入れません。

AIの自己反省の定義と、単純な再生成・外部評価との処理の違い

言葉の輪郭を先に固定します。日本語では自己反省・自己批判・自己修正がほぼ同義で使われ、英語では self-reflection、self-critique、self-correction が対応します。ここで扱うのは学習によって重みを更新する話ではなく、推論時に呼び出しを積んで出力を直す設計です。

生成・批判・再生成の3役に分けた処理と、言語化されたフィードバックの残し方

自己反省は3つの役に分解できます。課題を解いて出力を作る生成役、その出力を点検して不足や誤りを文章で指摘する批判役、指摘を読んで書き直す再生成役です。Self-Refine（arXiv:2303.17651）は3役を同一モデルのプロンプト切り替えで実現し、追加学習なしで成立させています。

設計上の要は、批判の出力形式です。「改善の余地があります」といった総評を返させても、再生成役は何を直すべきか決められません。指摘は「対象箇所・違反した条件・修正の方向」の3点を含む構造化された形で返させ、そのまま次のプロンプトへ貼り付けられる粒度にします。ここを詰めるかどうかで、同じ枠組みでも結果は変わります。

単純なリトライ・温度変更との違いと、記憶バッファが効く条件の線引き

同じ質問をもう一度投げる再試行や、サンプリング温度を下げて出し直す操作も出力は変わります。ただし前回の失敗内容はどこにも残らず、試行は独立です。運が良ければ当たる、という設計になります。

自己反省では、失敗の要約が次の試行の入力に載ります。Reflexion（arXiv:2303.11366）はこれをエピソード記憶バッファに蓄積し、同じ課題に再挑戦する際の手がかりとして参照させました。効くのは、失敗の原因が試行間で共通していて、言語で表現できる場合です。乱数由来のばらつきが原因なら、記憶を積んでも同じ指摘が繰り返されるだけで終わります。

ReflexionのActor・Evaluator・自己反省モデルという3モデル構成

Reflexionは役割を明示的に分けています。行動と出力を担うActor、その軌跡に対して評価信号を与えるEvaluator、評価信号を言語の反省文へ変換する自己反省モデルの3つです。重みは一切更新せず、言語による強化（verbal reinforcement）で次の試行を変える点が設計上の特徴になります。

この分離が実装で効くのは、Evaluatorの中身を差し替えられるからです。単体テストの成否、正解ラベルとの一致、ヒューリスティックな採点関数のいずれをEvaluatorに置いても、後段の反省文生成は同じ形で使えます。1周をどこで終えるか、何周まで許すかというループ側の制御は別の設計論点で、エージェントループの終了条件と自律動作の仕組みを扱った記事に整理しています。

Self-Refine・Reflexionの系譜と、効果が報告された実験条件

手法名だけを並べても選定はできません。押さえるのは、報告された数字がどんな条件で出たかです。3本の論文を、報告値と前提の対で見ていきます。

Self-Refineの反復改善と、7タスク平均で約20ポイントとされた改善幅

Self-Refine（Madaan et al., arXiv:2303.17651・2023年3月提出、同年5月改訂）は、初回出力に対して同一モデルがフィードバックを書き、そのフィードバックで改訂する反復を回します。教師データも追加学習も強化学習も使いません。GPT-3.5・ChatGPT・GPT-4を対象に、7種類のタスクで平均およそ20ポイント（絶対値）の改善が報告されました。

この20ポイントを一般則として読むと事故ります。対象タスクには文章の書き換えや応答の改善など、評価軸が形式面に寄ったものが含まれます。形式や網羅性のように「見れば分かる」欠陥は自己批判で拾えますが、事実の誤りや計算の誤りは同じモデルの目には見えません。

ReflexionのHumanEval pass@1 91%という報告値の前提条件

Reflexion（Shinn et al., arXiv:2303.11366・v1 2023年3月、v4 2023年10月）はコード生成でHumanEvalのpass@1 91%を報告し、同条件のGPT-4の80%を上回りました。数字だけを見ると自己反省の勝ちですが、成立条件があります。

コード生成は、テストを実行すれば成否が機械的に確定する課題です。つまりEvaluatorに真の評価信号を供給できます。自然言語の要約や提案文のように正解が定義できない課題へ同じ構成を持ち込んでも、Evaluatorの位置にモデルの主観が入るだけで、報告値の前提は再現されません。

内在的自己修正が劣化するという報告と、外部信号の有無という分岐点

反対側の証拠も揃っています。Huang et al.「Large Language Models Cannot Self-Correct Reasoning Yet」（arXiv:2310.01798・ICLR 2024）は、外部フィードバックを与えずにモデル自身の判断だけで答えを見直させる内在的自己修正を検証し、改善しないどころか性能が下がる場合があると報告しました。推論課題では、正しかった答えを指摘に引きずられて書き換える挙動が起きます。

CRITIC（Gou et al., arXiv:2305.11738・ICLR 2024）はこの裏返しの立場から、外部ツールの検証結果を根拠に修正する構成を提案し、外部フィードバックの重要性を明示しました。3本を並べると結論は1本の線に収束します。自己反省の成否は手法名ではなく、批判役へ渡す根拠が外部にあるかどうかで決まります。

自己反省ループの実装手順と、外部フィードバック信号3系統の作り方

ここからは実装です。プロンプトの分け方、信号の作り方、止め方、費用の見積もりの順で組み立てます。

3役をプロンプトで分離する実装手順と、批判役へ渡す情報の絞り方

最小構成は次の4手順に収まります。

1. 生成役のプロンプトで初回出力を得る（この時点では自己批判の指示を混ぜない）
2. 批判役に、初回出力と判定基準、そして外部信号の生データ（テスト結果やエラー文）を渡す
3. 批判役の出力を「対象箇所・違反条件・修正方向」の構造で受け取る
4. 再生成役に、元の課題文・初回出力・指摘の3点だけを渡して書き直させる

手順2で渡す情報を絞る意味は大きいところです。会話履歴を丸ごと渡すと、批判役は自分が書いた文章を擁護する方向に引っ張られます。初回出力を「他人が書いた成果物」として提示し、判定基準を箇条書きで与えると、指摘の具体性が上がります。手順4で会話履歴を切るのも同じ理由です。

外部フィードバック信号の3系統：テスト実行・スキーマ検証・規則照合

実務で用意できる外部信号は、おおむね3系統に分類できます。上から順に信頼度が高く、そのぶん適用できる範囲が狭くなります。

3系統のどれも用意できない処理は、そもそも自己反省の適用外です。検索や外部APIの呼び出し結果を根拠にする形も取れますが、その場合はLLMから外部ツールを呼び出す設計と権限の扱いが前提条件になります。信号の質が批判の質を決める、という順序は動きません。

反復回数と停止条件の決め方と、改善が止まった回で打ち切る判断基準

反復は無制限に回しません。停止条件は3つを併記します。外部信号が合格を返した時点、指摘内容が前回とほぼ同じになった時点、そして上限回数に達した時点です。

実務での上限は2回から3回に置くのが現実的な出発点になります。改善の伸びは反復1回目が最も大きく、それ以降は逓減するためです。手元の対象データで、反復ごとの合格率と累積トークン量を並べた表を作り、増分が費用に見合わなくなる回を上限に採ります。指摘の重複判定は、批判文の類似度でも「同じ対象箇所を指している回数」でも構いません。判定を入れないと、同じ指摘で永久に回り続ける振動が起きます。

1件あたりの呼び出し回数とコストの見積もりと、待ち時間の増え方

費用は反復回数に対して線形以上に増えます。呼び出し回数が増えるだけでなく、直前までの出力と指摘を再投入するため入力トークンも膨らむからです。

試算の順序は、1件あたりの単価を出してから月間件数を掛ける形にします。バッチ処理で夜間に回す用途なら3周でも成立し、対話画面で人を待たせる用途なら1周でも成立しません。同じ枠組みでも、置き場所で結論が反転します。

自己反省が精度を下げる失敗モードと、劣化を見分けるための判断材料

導入記事の多くは効果の側だけを書きます。実装で時間を取られるのは失敗の側なので、起き方と検出の置き場所を先に押さえます。

正答を誤答へ書き換える劣化の起き方と、検出に使うログの取り方

最も厄介なのは、初回が正解だったのに反省で壊れる事象です。批判役は「指摘せよ」と指示された以上、欠点が無い出力にも何らかの欠点を挙げがちです。その指摘を再生成役が真に受け、正しかった数値や条件を書き換えます。前掲のHuang et al.（arXiv:2310.01798）が報告した劣化は、この構造から生まれます。

検出には、反復ごとの出力を全部残すログ設計が要ります。初回出力と最終出力の両方を評価データに掛け、「初回○→最終×」の件数を独立に数えてください。全体の合格率だけを見ていると、改善分と劣化分が相殺されて気づけません。劣化が一定割合を超えるなら、批判役に「欠点が無い場合は指摘なしと返す」選択肢を明示的に与えます。

批判役が甘くなる偏りと、別モデル・複数回の突き合わせによる緩和

同一モデルが生成と批判を兼ねると、自分の出力に甘い判定が出ます。逆に「厳しく点検せよ」と強めると、些細な表現まで指摘して書き換えを誘発します。どちらもプロンプトの温度差で揺れるため、単一の指示文で固定しきれません。

緩和策は2つあります。批判役だけ別のモデルに割り当てる方法と、同じモデルで複数回批判させて共通して挙がった指摘だけを採る方法です。前者は費用が読みやすく、後者は追加の実装が要りません。どちらを採るにせよ、批判役の判定そのものが妥当かは別途測る必要があり、その手順は評価側の設計に属します。

同じ指摘を繰り返す振動と、費用が跳ねる事故を止める上限の置き方

停止条件を入れ忘れた自己反省ループは、同じ指摘と同じ修正の間を往復します。1件あたり数十回の呼び出しが発生し、テスト実行を伴う構成では外部リソースまで消費します。上限は回数だけでなく、1件あたりの累積トークン量と経過時間の両方に置いてください。

本番前に必ず確認するのは、上限に到達したときの挙動です。最終出力をそのまま返すのか、初回出力へ戻すのか、人の確認へ回すのかを設計で決めておきます。決めていないと、最も壊れた出力が返る実装になりがちです。

自己反省を採用する条件と、見送る3条件・関連工程との責務分担

ここは判断の章です。条件を付けて言い切ります。

採用してよい条件：検証可能な信号と1件単価が見合う処理の見極め

採用してよいのは、次の2つを同時に満たす処理だけです。第1に、テスト実行・スキーマ検証・規則照合のいずれかで合否が機械的に決まること。第2に、1件あたりの呼び出しが3倍から7倍になっても単価が事業として見合うこと。コード生成、SQL生成、構造化データの抽出、帳票の整合チェックはこの条件に収まりやすい領域です。

逆に言えば、この2条件を満たす処理では自己反省は費用対効果の高い改善手段になります。検証の仕組みごと設計して業務へ組み込む段階では、AIエージェント開発の相談という形で外部の実装体制を使う判断も取れます。自前で試作した結果、評価データの整備と信号設計で止まる例が多い工程だからです。

見送る3条件：応答時間の予算・主観評価の課題・単発で足りる処理

入れない条件を3つ挙げます。いずれか1つでも該当するなら、自己反省は見送ります。

• 応答時間の予算が厳しい処理：対話画面で数秒以内に返す要件があるなら、3倍の待ち時間は吸収できない
• 正解が一意に決まらない主観評価の課題：文章の良し悪しや提案の妥当性は外部信号を作れず、劣化側に振れる
• 単発生成で必要な正答率に達している処理：伸びしろが無いところに反復を足すと、費用と劣化リスクだけが増える

実務での順序は、まず単発で解かせて誤答を分類することです。誤りが「形式や制約の違反」に集中しているなら自己反省が効きます。「知識が無い」「参照情報が足りない」に集中しているなら、直すべきは反省ループではなく参照情報の与え方です。

エージェント評価・プランニング・ループ制御との責務分担の線引き

自己反省は単独の機能ではなく、エージェント設計の1レイヤーです。混同しやすい隣接工程との境界を引いておきます。効果測定は外部からの評価設計に属し、実行順序の決定は計画側、何周回すかはループ制御側の責務です。

自己反省が担う範囲は「1回の出力を、根拠に基づいて書き直す」という1点だけです。計画の立て直しまで含めた設計はAIエージェントのプランニングと再計画の設計で扱っており、そもそもエージェントを業務に組み込むかどうかの判断はAIエージェントの仕組みと導入判断の基準が入口になります。レイヤーを混ぜたまま設計すると、どこを直せば精度が上がるのか切り分けられなくなります。

よくある質問

実装の相談で繰り返し挙がる質問を、判断に直結する形でまとめます。

自己反省と自己修正・自己批判は同じものですか？

実務上、この3語はほぼ同義です。厳密に分けるなら、自己批判は出力を点検して指摘を生成する処理、自己修正は指摘を受けて書き直す処理、自己反省は両者を含む一連のループを指します。論文では self-reflection、self-critique、self-correction が対応し、Reflexion（arXiv:2303.11366）は反省文を記憶に蓄積する点、Self-Refine（arXiv:2303.17651）は1本のループで反復する点が異なります。設計時に区別すべきは名前ではなく、批判の根拠が外部にあるか内部の主観かという軸です。

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

上がりません。外部フィードバックを与えない内在的な自己修正では、改善しないどころか性能が下がる場合があるとICLR 2024の報告（arXiv:2310.01798）が示しています。初回が正解だった件を指摘に引きずられて書き換える劣化が起きるためです。上がるのは、テスト実行やスキーマ検証のように合否が機械的に確定する信号を批判役へ渡せる処理に限られます。導入前に、初回出力と最終出力の両方を評価データへ掛け、「初回○→最終×」の件数を数えてください。

批判役は同じモデルでよいですか、別モデルにすべきですか？

外部信号が明確なら同一モデルで十分です。テストの失敗ログのように根拠が外にある場合、批判役の仕事は根拠を読んで修正方向へ言い換えることなので、モデルの自己愛が結果に及ぼす影響は限定的です。一方、根拠が薄い処理では同一モデルの判定が甘くなるため、別モデルを充てるか、複数回批判させて共通指摘だけを採る構成にします。費用面では別モデル1回のほうが読みやすく、実装の手数では複数回方式のほうが軽く済みます。

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

出発点は2回から3回です。改善幅は1回目が最も大きく、以降は逓減する一方で、呼び出し回数は1周ごとに2回ずつ増えます。回数の上限に加えて、外部信号が合格を返した時点と、指摘が前回とほぼ同じになった時点でも打ち切ってください。累積トークン量と経過時間にも上限を置き、到達時に何を返すか（最終出力・初回出力・人の確認）を先に決めておきます。決めないまま本番に出すと、最も壊れた出力が返る実装になります。

自己反省の効果はどう測ればよいですか？

単発生成との比較で測ります。同じ評価データセットに対し、単発の合格率、自己反省1周後の合格率、反復ごとの累積トークン量と所要時間を並べます。全体の合格率だけでは改善分と劣化分が相殺されるため、「初回×→最終○」と「初回○→最終×」を別々に数えるのが要点です。エージェントとして動かす場合は、軌跡やツール呼び出しまで含めた指標設計が必要になり、評価側の工程として切り出して設計します。

関連記事

• エージェントループとは？AIエージェントが自律的に動く仕組み・ReActと終了条件の設計を実装者視点で解説【2026年版】：何周回すかというループ制御側の設計
• AIエージェントのプランニングとは？計画を立てる仕組みと再計画の設計を実装目線で解説：計画の立て直しまで含めた層の責務範囲
• AIエージェント評価とは？軌跡・ツール呼び出し・タスク達成を測る指標と実装の進め方【2026年版】：自己反省の効果を外から測る指標の作り方
• LLM評価とは？指標・データセット設計・評価ツールの選び方を実装視点で解説【2026年版】：批判役の判定そのものが妥当かを検証する手順
• AIツール使用（Tool Use）とは？LLMが外部を呼ぶ仕組みと実装の判断基準を解説：外部フィードバック信号の供給元になる呼び出し設計