「同じ手続きを繰り返している → 自動化・スキル化を提案する」という手続き的メモリ機能を作る場合、セッションログの常時バックグラウンド解析から始めるとコストと誤検出の割に価値検証が遅い。先に保存フローへの相乗り検出で成立させるのが安い。検出コストは保存時の類似検索に収まり、「また記録しようとした瞬間」がトリガーなので反復のシグナルとして偽陽性が少ない。

最重要の設計点 — 目的別に検索空間を分ける: 保存時の類似検索には目的の違う 3 判定が相乗りしており、ヒット時の正しい挙動が逆方向なので、status / kind フィルタで別クエリに分割する。

無差別の 1 本検索にすると、却下済み提案に似ているというだけで重複チェックが新規保存を止め、反復カウントも増えなくなって機能全体が静かに停止する。

その他の設計点:

• 検出対象を識別できるよう、記録に kind（手続き / 設計判断 / 調査など）を最初から持たせる。後付けだと過去分の再分類が必要になる。
• 再提案防止は永久ブロックにしない。却下レコードに却下時点の類似件数（または対象 ID 群）を記録し、そこから大幅に増えたら（例: 3 件で却下 → 6 件到達）再提案する。
• 提案が承認されたら複数回分の記録を統合して自動化定義（スキル等）のドラフトを生成し、元の記録には昇格先リンク付きの retired 状態を付けて退役させる。
• retired に類似する新規保存が来た場合は、保存でも提案でもなく「この作業は既にスキル X になっています」と案内する（昇格先リンクがここで効く）。

適用条件: 記録が保存フローを必ず通る仕組み（capture ワークフロー等）があること。保存を経由しない反復は拾えないため、価値が確認できてから常時スキャンを追加検討する。