AIコーディングエージェントが同じ種類の問題で何度も失敗するのを見た後、根本原因を特定しました。ここでは、エージェントの実行の大半を開始前にダメにするものを挙げます:
C1 — 列挙型(enum)の不完全な取り扱い。エージェントがコードベースに存在しないステータス値を参照する。
C2 — サイレントなnullパス。任意パラメータが、ドキュメントなしに何もせずスキップされる。
C3 — SSE認証パターンの不一致。ブラウザのEventSourceはカスタムヘッダーを送れないため、エージェントが誤った認証を使う。
C4 — 無制限のテキストフィールド。タスク説明や差分(diff)を受け取るカラムに切り詰めがなく、長大な入力が入る。
C5 — イベント/DBの競合状態。SSEイベントがDBへの書き込み完了前に発火する。フロントエンドのクエリで行が空になる。
C6 — スキーマ/ORMの不一致。SQL型はnullableだが、ORMのフィールドはrequiredになっている。
C7 — テスト可能でない期待値。仕様(spec)に実装への道筋がないテスト要件。
C8 — 冪等でない(non-idempotent)インサート。リトライのロジックが重複行を作る。
C9 — ハルシネーションしたインポート。モジュールがコードベースに存在しない。
現在は、計画(planning)の後、実行の前にこの内容を検証パスとして走らせています。コードが1行も実行される前に、約70%の失敗を検出できます。
他にも、エージェントのパイプラインに事前実行バリデーションを組み込んでいる方はいますか?
実行前にLLMコーディングエージェントの失敗を検知する9項目のチェックリストを作りました
Dev.to / 2026/3/27
💬 オピニオンDeveloper Stack & InfrastructureTools & Practical Usage
要点
- この記事では、誤ったenum/statusの扱いや幻覚的なimport(存在しないimport)など、実行前に発生するLLMコーディングエージェントの失敗のよくある原因を9つの根本要因として特定します。
- サイレントなnullパス、SSE認証パターンの不一致、そしてイベント/DBの競合(レースコンディション)といった問題が、ワークフローの初期段階でエージェントを頻繁に頓挫させることを説明します。
- 無制限のテキストフィールド、スキーマ/ORMの不一致、検証不能な期待値などのデータ取り扱いおよび仕様整合性の問題が、信頼性の低いエージェント挙動につながることを強調しています。
- 著者らは、計画の後、実行の前に行う事前実行バリデーションとして用いる9項目のチェックリストを紹介し、報告によれば失敗の約70%を検知できるとしています。
- 記事の最後には、他のビルダーに対して、同様の事前実行バリデーションをエージェントのパイプラインに取り入れるよう呼びかけています。