Reflection（自己批評）

エージェント自身に成果物を批評させ、見つかった問題を修正させてから出力する。テスト実行・lint・データベース照合といった外部の検証源を批評の根拠にすると、効果が大きく上がる。人間が推敲するのと同じ工程を、生成の直後に構造として組み込むパターンである。

別名

呼称	出典
Self-Critique / Self-Correction	一般的呼称
Self-Refine	Madaan et al. の論文名
Reflexion	Shinn et al.。失敗経験を言語化して次試行に活かす発展形

問題

LLMの一発の生成には誤り・抜け・雑さが残る。人間の文章に推敲が要るのと同じで、生成直後の出力をそのまま最終成果物にすると品質の分散が大きい。存在しないAPIを呼ぶコード、要件を1つ取りこぼした文書、退職者を含むレビュアー一覧——いずれも「もう一度見れば気づく」類の欠陥である。

一方で、修正が必要かどうかを判断する材料を生成者自身が持たないと、根拠のない自信で素通りする。「見直して」と指示するだけでは、モデルは生成時と同じバイアスで同じ箇所を見逃し、「問題ありません」と答えて終わることが多い。

コンテキスト

適用する:

生成→検証→修正のサイクルで実測的に品質が上がるタスク（コード生成、構造化文書の作成等）
テスト実行・スキーマ検証・外部データ照合など機械的な検証源がある場合（例: 提案したレビュアー一覧を在籍者DBと照合して退職者を検出する）
1〜2回の再試行で十分な、軽量な品質向上を狙う場合

適用しない（不要な）ケース:

検証源がなく「もう一度見直して」と言うだけになる場合——同じバイアスで同じ見逃しをする
誤出力の損害が致命的な場合——生成と評価を分離する Evaluator-Optimizer に格上げする
時間予算が秒単位の場合——反復は時間を食う

解決

生成ステップの後に、(1) 可能なら決定論的な検証（テスト・照合・lint）を実行し、(2) その結果を批評材料としてLLM自身に問題点を列挙させ、(3) 問題があれば修正版を生成する。反復は少数回（1〜3回）に制限する。

重要なのは Evaluator-Optimizer との境界である。Reflection は同一エージェント（同一の文脈・役割）内での自己批評であり、評価専任の別LLMを立てるのが Evaluator-Optimizer である。役割を分離しないぶん軽量だが、生成時のバイアスからは逃れられない。だからこそ外部検証源の有無が効果を左右する。

python

MAX_REFLECTIONS = 2

def reflect_and_refine(task):
    draft = llm(f"タスク: {task}\n成果物を生成せよ")
    for _ in range(MAX_REFLECTIONS):
        findings = tool("run_checks", draft)     # テスト・lint・DB照合（決定論的な検証源）
        critique = llm(
            f"成果物: {draft}\n検証結果: {findings}\n"
            "問題点を列挙せよ。なければ「問題なし」とだけ答えよ"
        )
        if "問題なし" in critique:
            return draft
        draft = llm(
            f"成果物: {draft}\n指摘: {critique}\n"
            "すべての指摘を修正した版を生成せよ"
        )
    return {"status": "unresolved", "artifact": draft, "critique": critique}

実装の要点:

検証源を自己批評の前に置く。 テスト結果や照合結果という「動かぬ証拠」を文脈に入れてから批評させる。証拠なしの自己批評は生成時と同じ判断の再演になりやすい
反復上限を構造で固定する。 「問題なし」と言うまで回すのではなく、決定論的な上限（1〜3回）で必ず打ち切る（Budget Guard）
上限到達時は残存問題を添えて返す。 修正しきれなかった指摘を黙って捨てると、下流が未検証の出力を完成品として信頼してしまう

トレードオフ

✅ 少ない追加コスト（数回のLLM呼出）で出力品質の底上げができる
✅ 外部検証源と組み合わせると、機械的に検出可能な誤りをほぼ排除できる
⚠️ 生成時と同じバイアスを共有するため、自己批評だけでは系統的な見逃しが残る
⚠️ 検証源のない反復は「自信を強めるだけ」で、コストに見合わないことが多い

クラウドパターンとの対応

クラウドパターン	本パターンでの再定義
Retry	「一時的障害への機械的な再試行」から「検証結果を批評材料として文脈に含めた上での意味論的な再試行」へ。同じリクエストを同じ形で投げ直すのではなく、失敗の内容を次の試行の入力に加える。「同じ主体がもう一度試す」という構造は継承している

出典・参考

Anthropic — Building Effective Agents（テスト結果を環境からの ground truth として反復に使うコーディングエージェントの実践）
Madaan et al. — Self-Refine: Iterative Refinement with Self-Feedback
Shinn et al. — Reflexion: Language Agents with Verbal Reinforcement Learning

Reflection（自己批評） ​

別名 ​

問題 ​

コンテキスト ​

解決 ​

トレードオフ ​

クラウドパターンとの対応 ​

関連パターン ​

出典・参考 ​

Reflection（自己批評）

別名

問題

コンテキスト

解決

トレードオフ

クラウドパターンとの対応

関連パターン

出典・参考