検査役の「問題なし」が外れる、という前提

作る役と確かめる役を分け、別のコンテキストで走らせ、機械と人の二段のゲートを置く。ここまでは relmea の別のコラム（AIエージェントの成果物品質を守る検証設計）で書きました。

今回の主題はその次の段階です。確かめる役を置いたあとも、確かめる役の出力そのものが間違うことがあります。

間違い方は一種類ではありません。運用記録を見ると、次の4つに分かれます。

  • 見落とし型：実在する問題を「なし」と返す
  • 捏造型：実在しないものを「見つけた」と返す
  • 申告の誤り型：実際にやったことを「やっていない」と報告する
  • 空振り型：試験そのものが何も試していないのに、合格になる

型が違えば、塞ぎ方も違います。順に見ていきます。

見落とし型：「23項目すべて適合」の裏にあった9箇所以上の禁止語

何が起きたか

2026-05-25、販売前の自社教材2巻について、販売プラットフォームのガイドラインに違反していないかを監査エージェントに点検させました。

1巻目の担当エージェントは「23項目すべて適合・違反0件」と返しました。人が追加で禁止語を grep すると、「絶対」「誰でも」「99%」「圧倒的」「唯一」が9箇所以上ヒットしました。エージェントはこれらを「文脈上は適正」と判断して、合格にしていました。

同じ依頼をした2巻目の担当は、CRITICAL 5件・HIGH 3件を検出しています。同じ仕事でも、担当した個体によって結果がぶれました。

なぜ起きたか

判定が「文脈上どうか」というエージェントの解釈に寄っていたためです。禁止語が含まれるかどうかは、本来は文字列の一致で決まる事実です。そこに解釈が入ると、レビュー役は自分で理由をつけて合格にできてしまいます。

個体差もあるので、1回の合格は再現しません。2巻目の担当が問題を拾えていた以上、1巻目の「0件」は「問題が無かった」ではなく「拾えなかった」と読むべき結果でした。

どう塞いだか

  • 監査役の判定が合格でも、機械の検証を1段重ねる。禁止語の grep、数値の整合、未差し替え箇所の grep を、判定とは別に走らせる
  • 監査の依頼文に「文脈上適正と判断した箇所も、ヒット一覧として全部出す。最終判定は依頼者が行う」と書く

後者で、レビュー役の仕事は「合否を決める」から「候補を漏れなく出す」に変わります。解釈で落とす判断は、依頼者の手元に戻ります。

捏造型と申告の誤り型：報告が詳細なほど信じやすい

捏造型：実在しない項目を「取得済み」と報告した

2026-07-28、外部のエージェント定義カタログを探索させたところ、探索役が実在しない項目を「取得済み・v1.0・○○が白眉」と、版番号と要約つきで報告しました。

別の探索役に再確認させると報告が食い違い、親が自分で取得APIを叩くと「Prompt not found」が返りました。

注意したいのは、版番号と要約が付いていたことです。報告が詳細で具体的なほど、受け取る側は確認を省きたくなります。見落としとは逆向きの、無いものを有ると言う誤りです。

塞ぎ方は、サブエージェントが「見つけた」「存在する」と言ったものは、記録に書く前に親が1回叩いて実在を確かめる、というルールです。報告が食い違ったときは多数決にせず、親の実測を正とします。

申告の誤り型：上位モデルの監査役でも防げなかった

2026-08-16、アプリの本番運用診断で、上位モデル（Opus）で動く監査担当が「非破壊の試験で、動画は1本も作っていない」と報告しました。実際には、実チャンネルに公開状態を含む2本のレコードを作っていました。

これを見つけたのは、中位モデル（Sonnet）で動く検品役です。検品役はほかに、変異を注入しても赤くならない形骸化テスト2件と、監査報告書の冒頭の節と後半の節の自己矛盾も見つけています。

効いたのはモデルの格ではありませんでした。申告を信じず、検品役が自分でゲートを再実行し、変異を注入し、画像を開いて実見する手順です。この結果を受けて、実行と照合が中心の工程のうち上位5体を、Opus から Sonnet に下げました。「上位モデルに見せれば安心」という前提は、この件では成り立ちませんでした。

空振り型：何も検証していない試験が合格になる

何が起きたか

2026-07-29、常駐プロセスの再起動ゲートを試しました。実行中のジョブがあれば再起動を止める仕組みです。

試験のために、台帳の複製へ「実行中ジョブ」の偽データを入れようとしましたが、NOT NULL 制約で挿入に失敗しました。複製は実行中0件のままだったので、ゲートは「再起動してよい」と正しく判断し、本番の常駐プロセスを意図せず再起動しました。ゲートは正しく動きましたが、試験は何も検証していませんでした。

同じ日に、別の実機試験でも似たことが起きています。「許可確認が必ず出る」前提の試験が、確認を一度も出さずに成功を返しました。実行時に渡していた許可の引数で、対象が事前に許可されていたためです。台帳に行が増えていないことで、空振りだと分かりました。

なぜ起きたか

どちらも、仕込みの成否を確かめずに本題へ進んでいました。仕込みが落ちると、試験は「何も起きない状況」で走ります。ゲートが何もしないのは、正常でも故障でも同じ見た目です。

どう塞いだか

  • 試験の仕込みは、直後に件数を読み返して assert してから本題に進む（print して目で見るだけで済ませない）
  • 「確認が出る」「ジョブが走っている」といった前提は、試験の前に状態として確かめる
  • 引き金が本当に引かれたかは、実行が成功したかではなく、実行側の記録（台帳の行が増えたか等）で判定する

AIレビューの合格判定を機械で確かめ直す設計

4つの型に共通するのは、判定を出した本人の言葉が唯一の証拠になっていたことです。塞ぎ方も共通していて、判定の外に、別の手段で確かめ直す層を置いています。

relmea でエージェントの定義を出荷するときの判定役にも、この考え方を入れています。

  • 1体の定義を、立場の違う3〜5ペルソナ×各3ケース（最低9試行）で並列に叩く
  • ペルソナのうち「敵対的ペルソナ」と「浅い素人の相談ペルソナ」は必須にする
  • 定義を渡さない素のAIに同じ入力を与えて並べる対照テストを、最低3入力で行う。差が小さければ「薄まり」として不合格にする
  • 判定役は定義を書き換えず、差し戻すだけにする
  • 1ケースだけで合格にしない

浅い素人の相談を必須にしているのは、専門性の薄まりは敵対的な入力よりも、浅い相談に専門家として踏み込めるかどうかで表に出るからです。浅い入力に一般論しか返さない定義は、素のAIと並べると差がほとんどありません。

試行を複数にするのは、見落とし型で見たとおり、同じ仕事でも1回の結果は担当によってぶれるからです。判定役に書き換えをさせないのは、作る役と確かめる役を混ぜないためです。直すのが手間だから合格にする、という動機を判定役に持たせません。

自分の運用に入れるチェックリスト

AIレビューの見落とし対策として、relmea が実際に入れている順に並べます。

依頼文

  • 「問題なし」だけを返させない。確認した箇所を、判断が分かれたものも含めて全部出させる
  • 最終判定は依頼者が持つ、と依頼文に書く

判定のあとの機械検証

  • 事実で決まるもの（禁止語、数値の整合、未差し替え箇所）は、レビュー役の判定とは別に grep や集計で確かめる
  • 検品役には、ゲートの再実行と、変異を注入して赤くなるかの確認をさせる。申告は証拠に数えない

報告の受け取り方

  • 「見つけた」「存在する」は、記録に書く前に自分で1回叩いて実在を確かめる
  • 報告が食い違ったら、多数決にせず自分の実測を採る
  • 版番号や要約が付いた報告ほど、確認の優先度を上げる

試験の組み立て

  • 仕込みの直後に件数を読み返し、assert してから本題に進む
  • 引き金が引かれたかは、実行側の記録で判定する

合格の出し方

  • 1ケースで合格にしない。立場の違う入力を複数通す
  • 素のAIとの対照を取り、差が小さければ不合格にする
  • 判定役は差し戻すだけにして、作る役の成果物を書き換えさせない

どの項目も、判定を出した本人の言葉ではなく、外側の実測で確かめるという同じ軸に乗っています。レビュー役を増やす前に、この確かめ直しの層を1段置くことを relmea では優先しています。