ストーリー
田
田中VPoE
ReActとPlan-and-Executeを学んだが、もう1つ重要なパターンがある。「Reflection」パターンだ
あなた
リフレクション…自己振り返りですか？
あ
田
田中VPoE
その通り。エージェントが自分の出力を評価し、不十分なら改善する。人間がコードレビューで「ここもっと良くできるな」と修正するのと同じ発想だ
あなた
LLMが自分自身の出力を批評するということですか？
あ
田
田中VPoE
そうだ。1回目の出力で満足するのではなく、「この回答は正確か？」「もっと良い方法はないか？」と自己評価して、品質を反復的に高めていく。特に、コード生成や文章作成など品質が重要なタスクで威力を発揮する
Reflectionパターンとは
基本概念
Reflectionパターンは、エージェントが自身の出力を自己評価（Self-Evaluation）し、改善点を特定して出力を反復的に改善するパターンです。
Reflectionの基本ループ:
[初期生成]
→ タスクに対する最初の出力を生成
↓
[自己評価（Reflection）]
→ 出力の品質を評価
→ 改善点を特定
→ 評価スコアを算出
↓
[品質基準を満たすか？]
├── Yes → 最終出力として返却
└── No → [改善（Refinement）]
→ 評価結果を基に出力を修正
→ 自己評価に戻る（ループ）具体例：APIドキュメント生成
ユーザー: NetShop社の注文APIのドキュメントを作成してください
--- 初期生成 ---
# 注文API
POST /api/orders で注文を作成できます。
パラメータ: product_id, quantity
レスポンス: order_id
--- 自己評価 ---
評価結果:
- 正確性: 60/100 - 必須パラメータが不足（user_id, shipping_address）
- 完全性: 40/100 - エラーレスポンス、認証方法の記載なし
- 可読性: 50/100 - 具体的なリクエスト/レスポンス例がない
- 総合: 50/100（基準: 80/100）→ 改善が必要
改善点:
1. 全パラメータを網羅する
2. リクエスト/レスポンスのJSON例を追加する
3. エラーケースを記載する
4. 認証ヘッダーの説明を追加する
--- 改善（1回目）---
# 注文API
## エンドポイント
POST /api/orders
## 認証
Authorization: Bearer <token>
## パラメータ
| パラメータ | 型 | 必須 | 説明 |
|...(詳細なテーブル)...|
## リクエスト例
{...}
## レスポンス例
{...}
## エラーレスポンス
{...}
--- 自己評価（2回目）---
評価結果:
- 正確性: 90/100 - パラメータが網羅されている
- 完全性: 85/100 - レート制限の記載を追加するとよい
- 可読性: 85/100 - 構造化されて読みやすい
- 総合: 87/100（基準: 80/100）→ 基準クリア
→ 最終出力として返却Reflectionの実装パターン
パターン1: Self-Reflection（自己評価型）
同じLLMが生成と評価の両方を担当します。
async function selfReflectionAgent(
task: string,
maxIterations: number = 3,
qualityThreshold: number = 80
): Promise<string> {
// 初期生成
let output = await llm.generate(task);
for (let i = 0; i < maxIterations; i++) {
// 自己評価
const evaluation = await llm.evaluate(output, task);
if (evaluation.score >= qualityThreshold) {
return output; // 品質基準を満たした
}
// 改善
output = await llm.refine(output, evaluation.feedback);
}
return output; // 最大反復回数に達した
}パターン2: Critic-Generator（批評家-生成者型）
生成と評価に異なるプロンプト（または異なるモデル）を使い分けます。
┌──────────────────────────────────┐
│ │
│ Generator（生成者） │
│ → タスクに対する出力を生成 │
│ │
│ ↓ 出力 │
│ │
│ Critic（批評家） │
│ → 出力の品質を厳密に評価 │
│ → 改善点を具体的にフィードバック │
│ │
│ ↓ フィードバック │
│ │
│ Generator（改善） │
│ → フィードバックを基に修正 │
│ │
└──────────────────────────────────┘パターン3: Reflexion（経験学習型）
過去の試行から学びを蓄積し、次の試行に活かす高度なパターンです。
[試行1] → 実行 → 結果 → 振り返り → 教訓を記録
[試行2] → 教訓を参照 → 実行 → 結果 → 振り返り → 教訓を更新
[試行3] → 教訓を参照 → 実行 → 成功！評価基準の設計
Reflectionの品質は評価基準の設計に大きく依存します。
タスク別の評価基準例
| タスク | 評価基準 | 重み |
|---|---|---|
| コード生成 | 正確性、テスト通過率、可読性、パフォーマンス | 正確性 > テスト > 可読性 |
| 文章作成 | 正確性、完全性、可読性、トーン | 正確性 > 完全性 > 可読性 |
| データ分析 | 正確性、網羅性、洞察の深さ、可視化 | 正確性 > 網羅性 > 洞察 |
| API設計 | RESTful準拠、一貫性、ドキュメント品質 | 一貫性 > RESTful > ドキュメント |
評価プロンプトの設計
以下の出力を評価してください。
[元のタスク]
{task}
[生成された出力]
{output}
以下の基準で0-100のスコアをつけ、改善点を具体的に列挙してください:
1. 正確性（0-100）: 事実に基づいているか、誤りはないか
2. 完全性（0-100）: 必要な情報が網羅されているか
3. 可読性（0-100）: 読みやすく構造化されているか
4. 実用性（0-100）: 実務で使える品質か
総合スコア: (各スコアの加重平均)
改善が必要な点:
1. ...
2. ...
3. ...Reflectionの利点と課題
利点
| 利点 | 説明 |
|---|---|
| 品質向上 | 反復的な改善で初回出力より高品質な結果を得られる |
| 自律的改善 | 人間のフィードバックなしに品質を自動改善 |
| 透明性 | 評価基準と改善点が明示されるためデバッグが容易 |
| 汎用性 | コード、文章、設計など幅広いタスクに適用可能 |
課題
| 課題 | 説明 | 対策 |
|---|---|---|
| コスト増大 | 反復のたびにAPI呼び出しが増える | 最大反復回数の制限、品質閾値の調整 |
| 自己評価の限界 | LLMが自身のミスに気づかない場合がある | Critic-Generator型の採用、外部検証 |
| 収束の保証なし | 改善が進まずループする可能性 | 改善幅が小さい場合のスキップ条件 |
| 過修正 | 改善しすぎて本来の意図から逸脱 | 元のタスクとの一貫性チェック |
まとめ
| ポイント | 内容 |
|---|---|
| Reflectionの定義 | 自己評価と反復改善で出力品質を高めるパターン |
| 3つの実装パターン | Self-Reflection、Critic-Generator、Reflexion |
| 評価基準の重要性 | タスクに応じた適切な評価基準の設計が品質の鍵 |
| 適するタスク | コード生成、文章作成など品質が重要なタスク |
チェックリスト
- Reflectionパターンの基本ループ（生成→評価→改善）を理解した
- 3つの実装パターンの違いを説明できる
- 評価基準の設計方法を理解した
- Reflectionの利点と課題を把握した
次のステップへ
次は「演習：エージェントパターンを選定しよう」です。NetShop社の業務シナリオに対して、学んだ3つのパターンから最適なものを選定する演習に取り組みます。
推定読了時間: 30分