TOKIUM QA、停止基準でCodexレビュー収束

エンジニアはReact/TypeScriptフロントエンドを読み取ってインタラクティブ要素を検出し、E2Eテスト記録と照合して実際にどこまで実行されているかを計測するツールを構築していた。計測ツールにとって、操作されていない要素を網羅済みとみなす誤検知が最悪のエラーであるため、実装は生成コンテキストなしで別ベンダーのAI、Codex CLIに敵対的レビューとして渡された。

初期ラウンドは成果を上げた。レビュアーは別環境からの操作を混同するエラーを再現し、計測レポートで5件の誤った網羅判定を実証した。その後、様相が変わった。修正は入ったが、同じ構文クラスで新しい反例が現れ続け、エンジニアは変数バインディングの解決をTypeScriptコンパイラAPIに移したが、as unknown asやanyによる型偽装値に引っかかった。決定的だったのは、構文的定数のみを信頼する方針により網羅範囲が388要素から1に崩壊したラウンドで、最大限の慎重さが計器を無用にしうることの証明だった。

解決策は、ツールが信頼してよい前提（例えば、テスト識別子を持つ属性オブジェクトにゲッターやセッターがないこと）を書き出し、それぞれをライブラリ実装行で正当化し、違反を検出する構文木検知器を構築することだった。レビュー依頼は再構成され、各指摘を3カテゴリのいずれかに強制分類させた：前提を満たしているのに失敗する、検知器が前提違反を見逃す、前提の根拠が誤っている。ブロッカー数はピーク8件から8回目で3件に減少したが、9回目で5件に戻り、新しい枠組みでも指摘はゆっくりしか減らないことが示された。残るブロッカーは、実データの誤判定のみをブロッカーとし、合成のみの反例はそのパターンが実際のソースに何回現れるかの注記付きで既知の制約として記載し、値フロー追跡を構文許可リスト付きの単一エンジンに切り替えることで解決された。ツールは関連テスト956件すべて成功で採用され、エンジニアは今、敵対的レビューを反例の無限探索ではなくツールを育てる対話と表現している。