根拠つき文書の検査は、「主張らしい文を拾う」方式ではすり抜けが残る

 文・監修:宮本 太郎

AIが書いた文書の主張に根拠が付いているかをプログラムで検査するとき、「主張らしい文」を正規表現で拾う方式には構造上の穴があります。開発中の設計レビューで見つかった穴と、それを踏まえた設計の考え方をまとめます。

結論:「拾えた文だけ」を検査しない

医学や法律に関する主張に根拠が付いているかを機械で確かめる仕組みを、ここでは「門(ゲート)」と呼びます。この門を作るときに、散文の原稿から「主張らしい文」を正規表現(文字のパターンで文を探す方法)で拾い出す方式をとると、拾えなかった文は検査されないまま通ってしまいます。

そこで原稿を散文のまま持たずに、文ごとに種別を付けたデータとして扱います。種別の既定値は「主張(根拠が必要)」にします。根拠が要らない文として扱うには、人が承認したという記録を残すことにします。根拠のない文を通すかどうかは、まず「通さない」を出発点にして、例外だけを人が明示的に認める、という考え方です。

正規表現で拾う方式で、何がすり抜けたか

2026年9月9日、衛生講話の資料を作るアプリを設計していたときのことです。2つのAIモデルがそれぞれ独立に設計を点検し、どちらも同じ穴を指摘しました。

数値や法律の条番号、「〜とされています」といった目印を手がかりに主張を拾う方式では、次のような文が検査の対象から漏れます。

  • 病気が重くなった場合の危険を言い切る文
  • 特定の働き方と病気のリスクとの関係を述べる文
  • ある対策が有効だと述べる文
  • 法律上の義務があると述べているのに、条番号を書いていない文
  • 「三人に一人」「約半数」のような漢数字の表現や、「50%」のような全角数字

どれも医学的・法的な主張でありながら、数値、条番号、「〜とされています」のいずれも含まない(あるいは、想定とは違う書き方をしている)文です。なお、ここで挙げたのは「すり抜ける文の型」であり、それぞれの内容が正しいかどうかをこのコラムで論じているわけではありません。

主張の文にHTMLの属性(たとえば data-claim-id)を付け、その有無を見る案も検討しましたが、これにも穴がありました。

  • 属性を付け忘れた文は、検査の対象外になる
  • 主張と無関係なIDが付いていても通ってしまう
  • その根拠が主張を本当に支持しているのか、最新版なのかは判定できない

いちばん危ないのは「0件で合格」になること

検査の対象を「拾えた文」に限ると、拾えなかった文は何の警告もなく通ります。さらに危ないのは、抽出が0件だったときに「根拠の付いていない主張は0件」として合格表示になることです。

この状態では、門が実際には何も検査していなくても、表示は合格のままです。動いていない門と、問題がなかった門の見分けがつきません。テストが全部合格なのにシステムが動いていなかった、という形の問題と同じ構造です。

既定を「根拠が必要」にする設計

メモにまとめた設計の考え方は次のとおりです。

  1. 原稿を文ごとの型付きレコードにする。 既定の種別は「主張(根拠必須)」です。「一般論」や「つなぎの文」に格下げするには、人の承認記録を求めます。
  2. 画面に表示される文だけでなく、読み上げられる文も同じ門を通す。 ナレーションや話者ノートのようにHTMLの属性を持たない原稿は、門の外に落ちやすくなります。
  3. 引用文が出典の本文に実在するかを、出典を取得して照合する。 日本語は単語の間に空白がないため、空白で区切る方法は使えません。メモでは隣り合う2文字の組(文字bigram)で照合する方法をとりました。「URLは実在するのに、引用文が本文にない」という作り話を検出する手段の一つになります。

ただし、3つ目の照合で確かめられるのは「その文字列が出典の本文にあるかどうか」までです。その出典が主張を本当に支持しているか、引用が文脈どおりかまでは、文字列の照合だけでは判断できません。

門が動いていることを確かめる

門を作ったら、わざと壊して、正しく失敗するかを見ます。このとき必ず含めておきたいのが「陽性対照」です。陽性対照とは、結果がこうなるはずだと分かっている入力を使った確認のことです。

  • (T1) 主張だと分かっている文を入れて、抽出が0件にならないこと
  • (T2) 根拠を消すと不合格になること
  • (T3) 存在しないIDを指定すると不合格になること

T1がないと、抽出がそもそも動いていない場合に、T2やT3が常に合格のまま残ります。何も拾えていなければ、根拠の欠けた主張も見つからないからです。

もう一つの確認として、門の処理を「常に空の結果を返す」ように書き換えて、検査が不合格を出すことを実際に見ます。この不合格を確かめるまでは、門が動いているとは考えないことにしています。

書いた本人が検査する構図の限界

この穴の根本には、生成する側と検証する側が同じだという構図があります。LLM(大規模言語モデル)が書いた根拠を、同じくLLMが検査している状態です。

この構図を崩す手段の一つが、外部にある正本(出典の原文)との照合です。とはいえ、原文との照合だけで医学的な妥当性や法的な正確性までは担保できません。最終的な内容の確認には、独立した立場の人による査読など、別の系統の確認を組み合わせる必要があると考えています。

健康や法律に関わる文書をAIで作る仕組みを検討している方、検査の仕組みの設計で迷っている方は、お気軽にご相談ください。

まずはお気軽にご相談ください

「AIで何かできそうだが、何から始めればよいか分からない」段階からのご相談を歓迎します。医師×AIの視点で、貴社の課題に合ったアプローチをご提案します。