信頼性更新日 2026-06-21 · バージョン 1.0

リフレクション

リフレクションは、モデルに自身の出力を批判（レビュー）させ、その批判をフィードバックとして使用して修正させる手法です。これは、追加の呼び出しコストと引き換えに、推論、コーディング、執筆タスクにおける誤りを検出し、品質を向上させるための、単一モデルによる軽量なアプローチです。

エビデンス: 業界での観察確信度: 高ソース: 業界での観察ソース: 論文
機械可読: JSON

定義

リフレクションは、モデルが明示的な基準に照らして自身の出力をレビューおよび批判し、それを修正するパターンであり、追加の推論コストと引き換えに、より高い品質を得る手法です。

課題

モデルは、自身の成果物をレビューするように促されれば改善できるような、欠陥のある初期回答を出力しがちですが、1回のパス（シングルパス）だけではその機会がありません。

適用対象

自己レビューのステップによって出力が測定可能なほど改善され、2つのモデルを使用するエバリュエーター（評価者）ループに代わるよりシンプルな方法を求めるときに、リフレクションを使用します。これは推論やコーディングのタスクで一般的です。

解決策

回答を生成した後、同じモデルに対して、目標（およびテスト結果やエラーなどのツールからのフィードバック）に照らし合わせてそれを批判し、その批判を踏まえて修正された回答を生成するようにプロンプトを提示します。これを制限された回数だけ繰り返します。

リフレクション（自己省察）は、過信につながるおそれのある純粋な自己評価よりも、実行エラー、テスト出力、取得された事実などの実際のシグナルに基づいている場合に最も効果的に機能します。

コンポーネント

初期生成自己批判ステップグラウンディングシグナル（エラー / テスト / 事実）修正イテレーションバジェット

メリット

  • 単一のモデルで品質を向上させることができます。第2のシステムは不要です。
  • ツールやテストのフィードバックに基づいている場合に効果的です。
  • 既存の呼び出しに簡単に追加できます。

リスク

  • 自己批判は過信に陥ったり、自身の誤りを見落としたりすることがあります。
  • 追加の呼び出しにより、レイテンシーとコストが増加します。
  • グラウンディングがない場合、得られる効果は限定的です。

非推奨のケース

  • 客観的な外部チェックがある場合：evaluator-optimizer（評価者-最適化者）パターンを使用してください。
  • 1回のパスで既に基準を満たしている場合。
  • レイテンシーバジェットが非常に厳しい場合。

テクノロジー

LangGraphAgent frameworksLLM-as-judge

事例

  • テストの失敗を読み取り、自身のパッチを修正するコーディングエージェント。
  • 回答する前にモデルが自身のステップを再確認する推論タスク。
  • 最終化する前に、モデルがギャップがないかレビューする下書き。

本番環境での実績

コンテキスト
レイテンシーやコストよりも出力品質が重視され（下書き作成、コード生成、分析など）、レビュー時にエラーを検出できるタスク。
シナリオ
最初の回答を生成した後、モデル（または別の批判者）が具体的な基準に照らし合わせてそれを評価し、修正版を生成します。このループは1回または2回のパスに制限されます。
テクノロジー
批判した後に修正するプロンプトチェーン。重要な業務においては、外部シグナル（テスト、ツール、別の評価者）に裏付けられていることが理想的です。
負荷
リフレクションのパスを実行するたびに呼び出し回数が少なくとも2倍になるため、オーバーヘッドに見合う出力に対してのみ選択的に適用されます。
結果
観察されたパターン：リフレクションは、モデルが実際に自身の誤りを検出できる場合に品質を向上させますが、正しい回答を過剰に修正してしまう可能性があり、コストは少なくとも2倍になります。信頼する前に評価セットに対して品質の向上を測定し、リスクが高い場合は外部シグナルを優先してください。

KPI

リフレクションによる品質向上
リフレクションステップがある場合とない場合での出力品質の測定された改善度。測定できない場合、そのステップはコストに見合っていません。
自己修正率
モデルがレビュー時に検出し、修正した本質的なエラーの割合（表面的な編集とは区別されます）。
追加のレイテンシーとコスト
リフレクションは呼び出し回数を少なくとも2倍にします。得られる品質に対してオーバーヘッドを追跡してください。
過剰修正率
リフレクションが、すでに優れた回答を疑うことによって、かえって品質を低下させてしまう頻度。

観察された失敗パターン

  • 自己評価の盲点：モデルは自身の誤りに気づかないことが多く、リフレクションでそれらを見落とします。
  • 過剰修正：モデルが正しい回答を「修正」して、より悪いものにしてしまいます。
  • 品質の向上がわずかであるか、まったくないにもかかわらず、コストとレイテンシーが2倍（またはそれ以上）になります。
  • 誤った自信：出力が正しくないにもかかわらず、モデルが「正しくなった」と主張します。

得られた教訓

  • 向上度を測定すること。リフレクションは、品質が明らかに向上する場合にのみ価値があります。
  • リスクが高い場合は、純粋な自己批判よりも外部シグナル（テスト、ツール、別の評価者）を優先してください。
  • リフレクションは1回または2回のパスに制限すること。収益は急速に減少し、コストは累積します。
  • リフレクションステップには、曖昧な「これを改善して」ではなく、具体的な基準を与えてください。

FAQ

リフレクションとevaluator-optimizerのどちらを選ぶべきですか？
リフレクションは1つのモデルを使用して自己批判を行います（よりシンプル）。evaluator-optimizerは別の評価者を使用します（より鋭く、偏りが少ない）。タスクにおける自己評価の信頼性に基づいて選択してください。
リフレクションは常に役立ちますか？
テスト結果やエラーなどの実際のフィードバックに基づいている場合に最も役立ちます。純粋な自己評価は過信につながりやすく、ほとんど効果がありません。
リフレクションは何回行うべきですか？
回数を制限してください。通常は1回または2回です。収穫逓減とコストの増加により、長いループが価値に見合うことはほとんどありません。

参考文献