欠損をゼロとして足していた — 自作リサーチ基盤を2週間動かして出た3つの欠陥

自分のコード関心領域に関連するGitHubのリポジトリを自動的に監視し、週に3件だけ提示するCLIツール「Evolver Engine」を2週間動かしてみた。記録するのは採用、保留、棄却の判断だけで、知識グラフもLLM呼び出しもない、シンプルな設計だ。初週は採用ゼロ、関連性スコアは0.25〜0.36だった。仮説は二つ立てていた。スコア設計が悪い可能性か、それとも探している場所に物が少ない可能性か。2週目のデータが片方の仮説を潰した。母数が3倍に増えた356件のなかで、スコアはむしろ低下した0.21〜0.29。探索地が増えるほど一般的な語で拾える候補が増え、固有の技術語を持つ候補が相対的に押し下げられている。つまり在庫の問題ではなく、スコア計算そのものに欠陥がある。

詳しく検査すると、三つの欠陥が見つかった。第一は、測定できないデータをゼロとして計算していることだ。複数回の観測から算出される信号「momentum」は、新着リポジトリの大半が観測1回きりなので、81%のデータでは計算できない。その側をゼロとして扱えば、たまたま観測されたことがある1件が自動的に上位に上がる。ExtremeRouterが首位になった理由は、実力ではなく「以前にも見た」だけだった。第二は、語彙抽出の範囲だ。職務に「MANDARA MACHINE」というVJシステム名を入れたのに、実際にマッチしたのはそれではなく、スキャフォールダの自動生成コメント行だった。自分のシステムが既に読んでいるテキストの中身を、実測するまで知らなかった。第三は、既定値の危険性だ。採用のコマンド既定値が「最も強い選択肢」に設定されていた。追記専用の設計では、取り消せない書き込みへの既定値は、最も弱い選択肢か、既定値を持たせないのが鉄則だ。

ここに見えるのは、自動化システムの隠れた欠陥がいかに潜みやすいかということだ。欠損とゼロを区別しない計算、意図しない語彙の混入、取り消せない書き込みへの強い既定値。これらは単なるコーディングミスではなく、設計思想に根ざしている。システムが「正しく動いている」ように見えても、内部の仮定が間違っていれば、何週間もそれに気付かない。中小企業が自社のAI関連ツールやシステムを運用するなら、実データでどう壊れるかを見つめ、既定値がいかに破壊力を持つかを知ることが、堅牢性への最短路だ。