どんな現代的なエージェント・フレームワークでも十分に眺めていると、こうした光景が見えてきます。まずモデルが出力を生成し、その出力を「熟考（リフレクト）」し、次に自分自身を「修正」し、最後に最終回答を送り出すのです。
それはメタ認知のように見えます。けれども違います。
同じモデルが、同じ重みで、2回サンプリングされているだけで、2回目は1回目の結果に条件付けされています。別の批評者（クリティック）は存在しません。特権的な視点もありません。レビューする側もレビューされる側も同じネットワークであり、レビュー側は元のモデルがそれまでに既にエンコードしていなかったものは何も見ることができません。
これは「反省（リフレクション）芝居」です。
実際に起きていること
「では、先ほどの回答を今すぐ批評して」とプロンプトした場合、モデルは自分自身のより深い層に相談しません。同じ分布から、批評の形をしたプレフィックス付きで再デコードするだけです。出力が自己修正に見えるのは、プロンプトが、修正の形をしたトークンへと偏らせるからです。
元の回答が、モデルが関連する事実を欠いていたために間違っていたのだとすると、リフレクションのステップでもその事実は欠いたままです。誤った答えに対して流暢な自信を得て、次に「なぜその誤った答えが正しいのか」という流暢な自信も得ることになります。
さらにトークン。相変わらずの盲点。より高い請求額。
実際に役立つ場所
リフレクション風のチェーンは、狭いケースでは役に立ちます：
- タスクが分解可能で、モデルがサブステップを再攻撃できる場合（例：動く作業用パッドを使った計算）。
- ラウンド間で入力を変える場合 — ツールの出力の追加、検索（リトリーバル）、別の役割。
- モデルを異なる温度または異なるシステムプロンプトでサンプリングする場合 — 本当に異なる分布を強制するため。
3つのいずれのケースでも、得られる利益は「能力としての“反省”」ではなく、条件付けの変更によって生まれます。
1ラウンド目と2ラウンド目の間で「reflect」という単語以外なにも変わっていないのなら、同じ答えを作るためのより高価な方法を見ているだけです。
正直なパターン
実際にエラーを捕まえるのは非対称な批評です。つまり、別のモデル、別のプロンプトの足場、そして実際の信号を持つ検証器（テストが通る、検索結果が得られる、ユーザーの追加の説明）です。レビュー側には、元のモデルが持っていなかった情報が必要です。
「同じモデルを2回目で回す」ことは、最も安い批評者であり、その分だけの価値しか得られません。
あなたのエージェントループに、入力を変えないreflect()ステップがあるなら、それを削除して差分の料金を確認してください。おそらく品質は落ちません。確実にトークンを節約できます。
