ハーネスエンジニアリングのアンチパターン AP7. 決定性の取り違え（The Misplaced Determinism Boundary） 🎯 ポイント テスト実行をLLMの善意に委ね、端ケースの判断を硬いルールに押し込む。境界を取り違えると、信頼性と適応性を同時に失います。 ❗ 発生する課題 確率的な要素を決定的であるべき場所に置くと信頼性が漏れ、決定的なルールを判断が要る場所に置くと適応性を失います。結果として、簡単なタスクで不安定になるか、複雑なタスクで硬直するか、あるいはその両方が同時に起きます。 🔍 メカニズムと症状 この取り違えには二つの形態があります。形態Aは「LLMの判断が要る長いテールを硬いルールに押し込む」パターンで、ルールは予測可能なため魅力的に見えますが、端ケースに遭遇すると脆く壊れます。形態Bは「決定的であるべき処理（テスト実行、ゲート判定、リトライ）をLLMの善意に委ねる」パターンで、モデルに任せれば実装が楽に見えますが、100回に1回はテストを忘れるという不安定さを生みます。症状としては、形態Aでは「想定外のケースでルールが破綻」「新しいパターンのたびにルール追加が必要」、形態Bでは「テストの実行忘れ」「ゲートのスキップ」「時々なぜか動かない」が見られます。 📋 シナリオ ・形態A：「import文の変更は必ずファイル先頭に」という硬いルールを設定。circular importの解消が必要なケースでルールが邪魔をし、エージェントが行き詰まる。 ・形態B：「テストを必ず実行すること」をプロンプトに記載するだけで、ハーネスが強制しない。エージェントは95%の確率でテストを実行するが、残り5%でテスト未実行のまま完了を宣言する。 ・両方同時：コードモッドの大部分はASTベースの決定的変換で処理できるのに、全てをLLMに任せている（形態B）。一方、LLMの判断が必要な端ケースには「この場合はスキップ」という硬いルールを適用（形態A）。両方が間違っている。 🛡 回避方法 ・ハーネスの全処理を「判断が要る」と「判断不要で決定的に実行可能」に分類し、境界を明示します ・テスト実行・lint・ビルド・ゲート判定は決定的コードで強制し、「お願い」しません ・LLMは本当に判断が必要な部分（原因分析・方針決定・コード生成）に限定して使います ・モデルの進化に合わせて境界を定期的に見直し、適切に移動させてください #HarnessEngineering# #AIAgent#