ハーネスエンジニアリングのプラクティス P14. 独立した自己批評パス（生成器と批評器の文脈を分ける） 🎯 ポイント 自分が書いたコードを自分でレビューして「良さそう」と言うエージェント、信頼できますか？レビューは作者と切り離して初めて機能します。 📝 概要 実装後、別の文脈（できれば別の役割プロンプト）で差分を仕様に照らして批評させます。「自分が今書いたから正しいはず」というバイアスを避けるには、生成器と批評器が文脈を共有しないことが鍵です。 🔍 解説 人間のコードレビューが作者以外の人間によって行われるのと同じ理由で、エージェントの自己批評も文脈を分離する必要があります。同じ文脈で生成と批評を行うと、生成過程で持った「なぜこう書いたか」のバイアスがそのまま批評に持ち込まれ、問題を見逃しやすくなります。別の文脈（理想的には別のプロンプト、別のモデルインスタンス）で、変更差分と仕様だけを見せて批評させると、フレッシュな視点でのレビューが可能になります。これは計算コストが追加されますが、流出欠陥を防ぐ効果は大きいです。 🛠 実践方法 ・実装完了後に別の文脈（新しい会話セッション）を起動し、差分と仕様だけを渡してレビューさせます ・批評器には焦点を絞った役割を与えます（「仕様との乖離」「セキュリティリスク」「リグレッション可能性」等） ・可能であれば生成と批評に異なるモデルやプロンプトを使用し、視点の多様性を確保します ・批評結果を構造化フォーマットで出力させ、ハーネスが自動的に対応（修正指示の送付・人間への報告）を判断します 💼 ユースケース ・issue-to-PRエージェントが完了前に、別のプロンプトで自己レビューを行う場面 ・自律バグ修正で、修正の妥当性を別の文脈で検証する場面 ・コード生成で、セキュリティ観点のレビューを別のエージェントとして実行する場面 ⚠ 落とし穴 批評器が「何でも指摘する」設計だと、瑣末な指摘が大量に出て実装→修正→批評→修正の無限ループに陥ります。批評器には「仕様との乖離」「セキュリティリスク」「リグレッション可能性」など、焦点を絞った役割を与えることが重要です。また、批評器の品質が低いと、正しい実装を不必要に修正させるリスクもあります。 #HarnessEngineering# #CodeReview#