2026年、私のAIコーディングエージェントにはもう一つのルールを加えたい：やめときめるタイミングを知る
AIエージェントは常に失敗することはない
時には継続することで失敗する
これは実際のブランドシステム用にカスタムのキリル文字フォント拡張を作る際に直面した問題だった。タスクは具体的に見えた：キリル文字、ラテン文字、数字、特殊記号が一つの編集タイプファミリーのように感じさせる
Claude CodeとCodexは引き続き動いていました。ファイルを生成し、証明書をエクスポートし、進捗を報告し、最後の目に見える不満を修正しました.
しかし、同じ欠陥の種類が繰り返し発生していました.
これはAIエージェントの失敗ループの危険なバージョンです：ワークフローは生産的に見えますが、実際の品質問題は生存しています.
失敗ループとは何ですか？
失敗ループとは、エージェントが同じ根本的な欠陥が解決されないまま、新しい候補の修正を繰り返し生成するパターンです。
通常、以下の5つのステップで構成されています：
- ユーザーが同じ種類の欠陥を再度拒否します。
- エージェントが最新の症状を修正します。
- 証明ゲートは問題を捉えるのに十分に弱いです。
- エージェントが別の手動レビューを要求します。
- 同じ問題にまた一つのサイクルを費やす.
一つの間違いは普通.
実際のプロセスのバグは、エージェントが検証システムがすでに失敗した後に続けたときに現れる.
なぜ通常の証明ループが失敗するのか
証明ループは有用だ。テスト、スクリーンショット、ビルドチェック、リンティング、差分、生成報告書などがすべて重要だ.
しかし証明ループは、測るものが間違っている場合にも芝居のようになる。
私のフォントプロジェクトでは、エージェントがフォントがコンパイルされたことを証明し、PDFがレンダリングされたことを証明し、スクリーンショットが存在することを証明し、バウンダリングボックスが変更されたことを証明し、数値スコアが向上したことを証明した。
しかし、それは文字が正しく見えたことを証明していなかった。
ユーザーは別のものを拒否していた：視覚的な一貫性。
ルシアン文字の一部がラテン文字と比べて、あまりにも短く、太すぎ、間隔が広すぎ、または構造的に間違って見えた。
ゲートが人間が見ている欠陥を見ることができないならば、ゲートは作業完了を宣言するのを許されない。
今私は使っているルール
同じ可視的な欠陥のクラスが2回現れた後、通常の実装を停止する。
もう一つ推測的なパッチを作らない。
閾値を緩めるな.
他の候補物を確認するようユーザーに尋ねるな.
失敗ループブレーカーモードに切り替えろ.
失敗ループブレーカーがやること
失敗ループブレーカーはAIエージェントの作業のためのハードモードスイッチだ.
より良い次の出力は候補の修正ではなく診断パッケージだ.
それは次のものを含むべきだ:
- 繰り返し失敗するクラス；
- 拒否された既知の悪い例のコーパス；
- それらの例で失敗する赤い最初のゲート；
- ゲートを緑にする修正；
- 著者が答えを見たときの無視または独立した検証；
- 明確な続行、停止、または人間の決定推奨；
これは再試行の制限だけではない。
リトライ制限はコスト増加を防ぐ。失敗ループブレーカーは作業そのものを変更する.
赤優先ゲートは重要
有用なゲートは修正される前に失敗しなければならない、なぜならそうでなければ古い失敗を見ることができるかを証明していないから.
エージェントが以前の不良アーティファクトで新しいチェックャーを失敗させることができない場合、それは真の問題のためにチェックャーを構築していない.
多くのエージェントワークフローはこの部分をスキップする。
新しい指標を追加し、新しい候補がより高いスコアになったのを見て、それを進歩と呼ぶ。この指標は決して古い失敗を拒否する必要はなかった。
主観的または視覚的なタスクでは、これがさらに重要になる because 拒否されたコーパスは人間の好みと決定的な検証の橋となる。
エージェントが汚染されたとき
別の落とし穴は汚染された検証です：同じエージェントが修正を書き、ターゲットを知り、結果を評価します
それはイテレーション中には有用かもしれませんが、それは独立した検証ではありません。
エージェントがすでに期待される答えを見た場合、最終的なチェックには保留された例、盲目のレビュラー、作成者の推論を受け取らない別のモデル、または要求が計算ではなく好みである場合の人的決定という確定的なゲートが必要です.
同じ著者の検証はしばしば自己一貫性であり、証明ではありません.
これは小さな公開スキルとしてパッケージ化しました
ルールを小さな公開リポジトリに変換しました：
https://github.com/g-shevchenko/agent-failure-loop-breaker
Claude Code、Codex、Cursor、およびWindsurf用にコンパクトなスキルとリポジトリローカルルールをインストールします。
インストールされるルールは意図的にシンプルです：
同じ欠陥クラスが2回出現した場合、エージェントは通常のパッチングを停止し、拒否されたコーパスと赤を優先するゲートを構築してから続行する必要があります。
このパッケージはモデルをより賢くするために作られたものではありません.
それはワークフローが動きを進歩と混同しにくくするものです.
会社が間違えるところ
チームは通常、エージェントの持続性を資産として扱います.
明確な範囲で実装されたタスクに強いテストがある場合、それは合理的です。受け入れ基準が視覚的、編集的、アーキテクチャ的、または運用的な作業ではリスクがあります。
Claude Code、Codex、Cursor、またはWindsurfが同じ種類のレビューで常に失敗する場合、次の投資は検証契約に向けたべきです。
世界で最も良いプロンプトでも、ゲートが間違ったアーティファクトを報酬するとループします。
この点で役立つ
このパターンはUIポリッシュループ、ビジュアルリグレッション作業、PDFとプレゼンテーション生成、タイポグラフィシステム、コンテンツQA、および同じバグが繰り返されるエージェントコーディングタスクに有用です。
ここにシグナルがあります：
ユーザーが「これがまだ同じ問題だ」と2回言うと、プロセスは変わるべきです。
実用的な要点
AIエージェントに「続けろ」と永遠に頼まないで
そのチェックャーが最後の失敗した試行を捉えることを証明するように頼んで
もしできなければ、次のタスクは実装ではない
その時点で、次のタスクはより良いゲートを作ること
詳細な記述:
https://gregshevchenko.com/notes/ai-agent-failure-loop-breakers/