「繰り返し登録されたら昇格・提案する」型のパイプライン（知識候補のスキル化提案、摩擦ログの同型検知、エラーの重複カウント等）では、登録する側が『小さすぎる』『一回きりだろう』と自己判断で候補を間引くと、下流の頻度カウントに材料が一度も届かず、昇格・提案が構造的に発火しなくなる（入口飢餓）。繰り返しは複数セッション・複数時点を跨いでしか観測できないのに、間引き判定は単一時点の情報しか持たないのが原因。

実測例

スキル化提案の前提となる手順記録の登録数が各プロジェクト1件前後・提案ゼロという状態が続いた。ユーザー体感では『同じ指示を何度もしている』のに、登録時の品質バー（繰り返し可能な手順として十分か）が毎回『登録不要』と判定し、サーバー側の反復カウンタ（重複登録の拒否時にカウント増分・閾値で提案生成）が一度も動いていなかった。

判断基準

• 入口の登録判定は『十分に大きいか・確実に再利用されるか』でなく『下流が数えられる形で残るか』で行う。頻度・重複の判定は単一時点では不可能なので、集計は蓄積側（サーバー・DB）の責務に置き、登録側は候補を素通しする
• 重複が心配でも、蓄積側に重複検知があるならクライアント側で畳まない。出現ごとに登録を試み、拒否＝カウント増分として設計すると、逐語的な反復ほど確実にカウントに乗る
• 蓄積側の重複検知が無い場合のみ、入口での集約が正当化される

落とし穴

• 間引かれた候補は後から遡れない（元データはセッションログ等の一次ソースにしか残らず、回収には高コストな再走査が要る）。入口バーの設計ミスは気づいた時点で過去分の損失が確定している
• 品質バー自体は必要。ただし『内容の質（機密・無関係）』のフィルタと『規模・反復見込みの自己判断』を区別し、後者を入口から外す

検証

登録数と昇格・提案の発火数を対で観測する。利用者が反復を体感しているのに提案がゼロなら、下流ロジックより先に入口の登録数を疑う（登録が数件なら飢餓が確定）。