危険な操作を文字列一致でブロックするdenyルールに、構造的な穴がありました。`cmd target`を禁止しても`cmd --flag target`はフラグ前置ですり抜け、REST経路を塞いでもGraphQL経由は素通りします。テストが『存在』しか確認しないと『守れている』という誤った安心感を生む、という多層防御の記録です。

AIセッションの開始時に注入されるメモリやタスク文は、観察から着手までの間に陳腐化します。それを信じて着手すると、すでに完了済みの作業を二重実装したり、もう存在しない前提を追いかけたりします。着手の直前に実ファイルやIssueラベルからSoTを再取得する規律で、複数の陳腐化事故を防いだ記録です。コードの中の重複を、書き始める前に探す手順も併せてまとめます。

PRのCIが8ジョブすべて失敗と表示されましたが、どのジョブも2〜4秒で落ち、ステップは空でした。ローカルで143件のテストを流して偽ブロッカーと確定した記録を軸に、無効化した機能のテストが通り続ける偽グリーン、ツール同士の答えの食い違い、実際の戻り値と違うdocstringの例という、検証結果をそのまま信じてはいけない場面をまとめます。

本番でのみ実行すべき外部APIコールが、無効にしたはずのレコードに対して走りうるバグがありました。修正のガードは1経路にしか置かれていなかったため、フォローアップで全呼び出し経路を追い、残りは定期実行から到達できないと確かめてガードを足さないと決めました。あわせて、下流の「値は正」という制約が不正な0を止めたのに、その例外が握り潰されて記録が100%抜けていた例から、入口と出口の守り方をまとめます。

毎朝のヘルスチェックが同じ偽陽性を出し続けるので、エラー文字列・原因・確認方法・修正案を1枚のドキュメント（SoT）に記録し、AI に一次判定を任せました。判定は速くなりましたが、思い込みで記録しかけたパターンが本物の障害だったこと、修正案まで書いたのに直さなかった偽陽性が4か月後に別の場所で再発したことも起きました。記録の書き方と、記録したあとに必要だったことをまとめます。

上流のIDに新しい形式が混ざり、検証環境のログに1日6,848件のエラーが出ました。同じ入力に対して、不変条件をガード式で書いた正規化関数は無傷で、許可する形式を1つしか書いていなかった検証は全件を弾いていました。修正のレビューでは、同じ役割なのにガードの無いもう1つの正規化関数も見つかりました。3つの関数の違い、検出から本番反映までの4週間、3か月後に出た2つめの形式までを記録し、後方互換の書き分け方をまとめます。

Plan エージェントが計画の最後に添えた「この分析を含めるのはリスクです」という一文を、読み流さずに計画から外しました。外した判断が正しかったと分かるまでの経緯、外した理由をどう書き残したか、そして「後日起票」と書いたまま半年起票されなかった反省から、エージェントのためらいを判断の分岐点として扱う手順をまとめます。

Explore agentの「未参照画像は2枚」は直接grepで107枚、AIの集計「+1.4万pt」は検証でマイナスに。AIの『該当なし』と『綺麗な数字』は最も誤りやすい報告です。削除事故と誤った意思決定を防ぐ三層検証と数値検証の4作法をまとめます。

段階デプロイのcherry-pick前チェックを「全項目OK待ち」の2値判定にすると、運用が止まります。CONDITIONAL（観察付き実行）を3つ目の選択肢にし、影響範囲・復帰コスト・観察手段で判断するルールと、約200行の衝突で機械的なcherry-pickができなくなったときに3案を比べて検証環境を飛ばした判断を記録します。

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