新機能を実装しようとした矢先、同等のロジックが既存コードに存在していた。大規模・並行開発では『新機能=未実装』という暗黙の仮定が危険。設計の前にAIでコード全体を透視する『フェーズ0サーチ』を必須化し、DRY違反と重複工数を着手前に潰す運用の記録。

監視スクリプトは必ず偽陽性を出す。月初の空ディレクトリ、symlinkで0件返すfind、累計ログの閾値超過——これらを『減らす』のではなく『既知パターンとしてSoTに記録』する運用。エラー文字列→即時判定で、本物の障害を見逃さず判断を速くする。

上流データの識別子フォーマットが変わり、旧ロジックが新形式を誤変換して6,848件が一括エラーに。修正は全置換ではなく、旧形式だけが満たす不変条件をガード式1行で囲うこと。API移行・ID体系変更に効く最小修正パターンの記録。

AI agentが「未確認のままだとリスクです」と発言した瞬間は、セッション内で押し切らず、Issue化／Phase分離する合図として扱う。Agentの「ためらい」を無視せず外部化することで、後追いリカバリーコストが激減する運用ルール。

Explore agentが「未参照画像は2枚」と要約したが、直接grepで107枚発覚。AI agentの『該当なし』『網羅した』報告は最も誤りやすい。三層検証で大量削除事故を防ぐ運用ルール。

段階デプロイのcherry-pick前チェックを「全項目OK待ち」の2値判定にすると運用が麻痺する。CONDITIONAL（観察付き実行）を第3の選択肢として導入し、リスク許容度×復帰コストで判断するフレームワーク。

AI agentとの協働で出てくる『後でやる』タスクは、TODOコメントやIssueにすると埋もれる。判断トリガー（いつ・何を見たら判断するか）をcheckpointとして外部記憶に置き、agentが次セッションで思い出す仕組み。

設定値をコードに埋め込むと、書いた瞬間の前提を1年後も引きずる。閾値・タイムアウト・URL・APIバージョンに『最終確認日』を持たせ、staleness をCIで検知する仕組み。AI agentが古い値を踏襲してしまう問題への対処。

ジョブが成功終了しても、生成物が0件・古い・壊れていれば失敗。exit codeとロジック検証は別物だ。Requirements段階で『成功の定義』を生成物の存在・鮮度・件数で固定し、デプロイ後に機械検証する運用ルール。

AIは万能ではなく、特定の領域で系統的に間違えます。新興分野・最新仕様・ニッチドメイン・固有名詞など、AIが弱い領域を地図化して検証フェーズを組み込む方法を実例で解説します。