ハーネスエンジニアリングのプラクティス P12. 意味的サーキットブレーカーと「文脈ごと捨てる」リスタート 🎯 ポイント 同じエラーを3回繰り返すエージェント、見たことがありますか？「押し通す」より「教訓つき仕切り直し」の方が圧倒的に速いです。 📝 概要 単なる最大反復数ではなく、「同じエラーが二度」「二つの編集を振動」「正味の進捗なし」を意味的に検出して停止します。行き詰まったら、汚染された文脈でこね続けず、最後の正常チェックポイントへロールバックし、失敗の経緯を文脈から捨て、一行の教訓だけ携えて別アプローチで再起動します。 🔍 解説 エージェントが行き詰まったとき、最も非効率な対応は「同じ文脈でもう少し頑張る」ことです。失敗の経緯がコンテキストに蓄積すると、エージェントはそれに引きずられて同じ轍を踏みやすくなります。意味的サーキットブレーカーは、単なる反復回数制限ではなく、「進捗があるか」を実質的に判定します。振動（AをBに変えてまたAに戻す）や同一エラーの反復を検出したら、gitで最後の正常状態にロールバックし、新しい文脈で「前回はXで失敗した。別のアプローチを試す」という一行の教訓だけを持って再起動します。gitはエージェントのUndoです。 🛠 実践方法 ・エラーメッセージやテスト結果を比較し、「同じエラーが2回」「編集のAB振動」を検出するロジックをハーネスに実装します ・停止時にgit checkoutで最後のクリーンなコミットにロールバックし、汚染された文脈を破棄します ・リスタート時に「前回はXで失敗した」という一行の教訓だけを新しい文脈に持ち込みます ・サーキットブレーカーの閾値をタスクの難易度に応じて調整します（簡単なタスクは厳しく、難しいタスクは余裕を持たせる） 💼 ユースケース ・issue-to-PRエージェントが同じテスト失敗を修正できずループする場面 ・コンパイルエラーの修正で、修正→別のエラー→戻す→の繰り返しを検出する場面 ・レガシーコード改修で、アプローチの根本的な変更が必要だと判断する場面 ⚠ 落とし穴 サーキットブレーカーが敏感すぎると、あと一歩で解決するところで打ち切ってしまいます。逆に鈍感すぎると、コストを浪費するだけの無限ループになります。「進捗」の定義をタスクに合わせて調整することが重要です。また、リスタート時に教訓を正確に蒸留することも難しく、間違った教訓を持って再起動すると、別の失敗パターンに陥ることがあります。 #HarnessEngineering# #AIAgent#