AIが「静かに失敗する」3パターンと、それを検知する仕組み

AIを使った生成処理をしばらく運用していると、「最近、前より精度が落ちていない？」と感じることがあります。モデルやプロンプトを疑って設定を見直したくなりますが、調べてみると原因がそこにないことも少なくありませんでした。

自分の環境で続けて見つかったのは、仕組みがエラーを出さないまま止まっていたケースです。画面上は正常、ログにも例外はなし。それでも成果物だけが少しずつおかしくなる。特に見つけにくかった3つのパターンをまとめます。

パターン1：配線切れ

上流で値を用意しても下流へ届いていない状態です。トークンを多数定義したのにCSSへ一部しか届かない、採点を実装したのにログは空配列のまま、警告フラグを計算しても表示箇所がない、といった例があります。各部分は正常なので例外は出ません。

パターン2：fail-open

必須検査が実行できないとき、黙ってスキップする状態です。「検査して指摘0件」と「検査できず0件」が同じ表示になると発見が遅れます。未採点の null を合格として保存する処理も同じ問題です。

パターン3：ループのデッドロック

昇格しないと効果測定が始まらない
    ×
昇格の判断には効果データが必要

設計どおりでも初期条件のため一周も回らないことがあります。

下流を実測して見つける

「反映されているはず」ではなく成果物を数えます。

grep -o '#[0-9a-fA-F]\{6\}' dist/app.css | sort -u | wc -l

計算したフィールドが消費されているかも検索します。

rg "prototypeDirty" src/

レジストリは設計の有無ではなく、effectiveness や promotedAt に実値が入った実績で判定します。

見つけた問題は手順書ではなくテストへ落とします。「再生成後のdiffがゼロ」「フォールバック警告が0件」「必須フィールドがnullではない」をassertすれば再発を機械的に止められます。

こうした問題を見つけると、すぐ新しい監視機構を足したくなります。でも、止まっている仕組みの上に仕組みを重ねても、止まる場所が増えるだけでした。それより、既存の検査が一度でも動いた実績を持つか、下流の成果物へ値が届いているかを定期的に数えるほうが効きます。

「AIの精度が落ちた気がする」とき、最初に見る場所はモデル設定とは限りません。生成されたCSSの色数や、ログへ入った採点件数のように、末端で数えられるものからたどると、切れた配線は案外早く見つかります。

今回は以上です。