リフレクション：出力を自己批判して直すループ

横にスクロール

どんなパターンか

大規模言語モデル（LLM）は、一度の生成で完璧な答えを出すとは限らない。長いコードや込み入った推論では、もっともらしいが誤った出力を平然と返す。リフレクション（自己批判・自己改善）は、この弱点を「一発勝負をやめる」ことで補う設計パターンだ。モデルにまず下書きを作らせ、その出力を批評にかけ、指摘を踏まえて作り直す。この生成→評価→修正を数回繰り返し、後段の工程で誤りを削って品質を底上げする。

発想は、人間の書き手が下書きを推敲するのと同じだ。違いは、批評も修正も同じモデル、あるいはもう一体のモデルに担わせ、ループとして自動化する点にある。評価役には二通りある。生成したモデル自身に振り返らせる自己批判と、判定専用の別の検証エージェントに点検させる方式だ。代表的な手法にReflexionがあり、失敗の原因を言語化して文脈に残し、次の試行の方針を書き換えていく。

リフレクションは特定のタスクに限らず、あらゆる生成の外側にかぶせられる汎用の枠だ。コード生成・数理的な推論・文章作成のいずれでも、品質の底上げが報告されている。同じ入力から出力を何度もサンプリングし、多数決や最良の一つを選ぶ手法（自己整合性やbest-of-N）とは似て非なるものだ。これらが互いに独立した複数案から選ぶのに対し、リフレクションは前の失敗を明示的に読み込み、それを踏まえて次の一手を組み直す。過去の批評を文脈に積み上げる点が、単なる引き直しとの決定的な違いになる。

仕組み

リフレクションのループは、三つの役割から成る。生成は下書きや解答を作る。評価はその出力を採点し、どこがなぜ悪いかを言葉にする。修正は批評を入力に加え、出力を作り直す。オーケストレータ（制御コード）がこの三つを順に呼び、停止条件を満たすまで回す。要は、生成の外側に「点検して直す」工程を足した制御系だ。肝心なのは、批評を単に眺めて捨てるのではなく、次の生成の文脈に書き戻すことだ。過去の指摘が作業メモリとして残るからこそ、モデルは同じ誤りを避けて前進できる。

制御ループの骨組み:
  draft = 生成(タスク)
  for i in 1..N:                    # N は反復上限
      score, critique = 評価(draft)  # 自己批判 または 検証役
      合格なら:            return draft   # 停止条件1: 目標到達
      改善が頭打ちなら:    return best    # 停止条件2: 伸び止まり
      draft = 修正(draft, critique)  # 批評を反映して作り直す
  return best                        # 停止条件3: 上限で打ち切り

具体的な流れを、コード生成を例に追う。評価に単体テストという外部の物差しを使う点に注目してほしい。

擬似トレース: 「配列を昇順に並べる関数を書け」

[反復1]
  生成: 実装を出力（空配列の扱いを誤る）
  評価: 単体テストを実行 → 3件中1件が失敗（空配列）
  批評: 「空配列のとき早期リターンが無い」
  修正: 空配列のガードを追加

[反復2]
  生成: ガードを足した実装
  評価: 単体テストを実行 → 3件すべて成功
  停止: 合格条件を満たしループ終了、出力を確定

批評は、具体的で行動につながるほど良い。「良くない」ではなく「空配列で例外が出る」と場所と理由を名指せてこそ、修正が的を射る。ここで効くのが、評価を誰にやらせるかの選択だ。自己批判は手軽だが、生成時と同じ思い込みを引きずりやすい。対して、批評専用の別の検証エージェントに判定させると、生成側の視点から独立して誤りを見られるため、精度が上がりやすい。役割を分けて協調させる構えは マルチエージェント構成 の一形態でもある。

使いどころと注意

向いているのは、評価が生成より易しく、しかも自動化できる課題だ。コード生成はテストの合否という信号があり、数学や論理の問題は検算や形式的検証で確かめられる。文章でも、要件チェックリストや評価基準を用意できれば効く。逆に、正解の検証手段がそもそも無い課題では、モデルは自分の誤りに気づけず、自信満々の誤答を批評で追認してしまうことがある。この場合、反復はコストを増やすだけで品質を上げない。たとえば、事実確認の手段が無いまま歴史や統計を述べさせる課題や、明確な評価基準を欠く創作では、自己批判は的外れな「改善」を繰り返し、初稿より劣化させることさえある。

もう一つの代償が、コストとレイテンシの増大だ。素の生成が1回のモデル呼び出しで済むのに対し、リフレクションは反復ごとに評価と修正の呼び出しを重ねる。検証役を別に立てれば、その分さらに増える。3回のループなら、呼び出し回数は単純計算で数倍に膨らむ。しかも品質の伸びは反復とともに逓減するため、回すほど良いわけではない。二、三回で頭打ちになる例は珍しくない。

だからこそ、停止条件を明示的に設計することが要になる。ループを必ず有限化し、無限リトライを防ぐ仕組みを、生成の外側に置く。

実務では、これらを併用する。合格でいち早く抜け、改善が頭打ちなら粘らず打ち切り、最後の砦として反復上限と予算上限で必ず止める。こうした「暴走を防ぐ枠」をエージェント全体で束ねる話題は ガードレール設計 に詳しい。

まとめ

リフレクションは、生成を一発勝負にせず、評価と修正のループで品質を後段から引き上げるパターンだ。効果の源泉は「評価は生成より易しい」という非対称性にあり、テストやコンパイラのような独立した検証器を組み込めるほど強く効く。批評を別の検証エージェントに任せれば、生成側の思い込みから独立して誤りを指摘でき、精度はさらに上がりやすい。

一方で、反復はコストとレイテンシを確実に増やし、品質の伸びは逓減する。検証手段の無い課題では、誤答の追認や無限ループに陥る危険もある。合格・伸び止まり・反復上限・予算上限という停止条件を多層で設け、ループを必ず有限化することが、実用の前提になる。ほかのパターンとの使い分けは AIエージェント設計パターン の一覧から辿れる。