外部のAI駆動開発プラクティス（記事・公開スキル・他チームの事例）を自分の開発手法へ取り込むか判断するとき、記事・手法の単位で採否を決めず、構成要素に分解して1要素ずつ3分類で判定する。

判断基準（3分類）

• カバー済み: 既存手法の対応物と1対1で突き合わせる。調査→計画→承認→実装→レビュー収束というループ構造は同型が多く、名前が違うだけの要素を新規導入しない。対応表を作ると「取り込むべきは差分だけ」が明確になる。
• 実態不一致: その要素が効く工程が自分の運用に実在するかを、成果物の実測で確認する。手順書・規定に書いてあるかではなく、計画ドキュメントやログなど実際の成果物を数える。「規定上あるはずの工程」が実際にほぼ使われていなければ、その工程向けの改善は死文になるので取り込まない。むしろ規定側を実態に合わせて直す契機として扱う。
• 採用（基準だけ salvage）: 対話モデルや工程全体は文脈が合わず却下する場合でも（例: チームのスキル均一化が目的の手法は個人開発に合わない）、内側にある判定基準・定義 — 特に正の列挙と負の除外ルールの両面を持つフィルタ — だけを取り出し、既存手法の曖昧な箇所に接ぎ木する。

落とし穴

• 手法全体を「ほぼカバー済み」と一括却下すると、内側の切れ味ある基準を拾い損ねる。逆に検証せず形から取り込むと、対象工程が実在しない死文が手順書に増え、以後の読み手のコストになる。
• 実在確認を記憶や印象で済ませない。実測例では、計画ドキュメント52件中、規定に書かれた選択肢提示形式を使ったものは2件しかなく、取り込む予定だった形式ルールの採否が逆転し、規定側の改訂に転じた。数える前の印象では「使っている工程」に見えていた。

検証

取り込み後の数件で、対象工程の成果物に新基準が実際に参照・反映されているかを確認する。変化がなければその要素も死文化しており、規定と実態の乖離が再発している。