AI記事生成 ハルシネーション ファクトチェック プロンプト設計

AIは料金を捏造する — 記事自動生成のファクトチェック三層設計

AIに記事を書かせると、料金を捏造します。それも「月額99,800円」のような明らかに怪しい数字ではなく、「月1,500円・最低5人から」のような実在しそうな数字を書くから厄介です。本記事は、長文コンテンツの自動生成を運用する中で実際に起きた料金捏造と、その後に組んだ三層のファクトチェック（資料同梱・数値照合・AI照合と判定別の自動修正）の設計をまとめたものです。

実際に起きた捏造 — 実在しそうな料金プランを2回書いた

ある業務SaaSの紹介コンテンツを自動生成したところ、公式には存在しない月額と最低利用人数の組み合わせが、断定調で本文に載りました。公式の価格ページと突き合わせてようやく気づくレベルの「それらしさ」で、修正して再生成したら今度は別の実在しない金額を書きました。つまり偶発ではなく、構造的にそうなります。

原因は分かっていて、AIは学習時点の記憶から「その製品の料金っぽい数字」を再構成するからです。旧料金・他プランの金額・似た製品の料金が混ざった「うろ覚えの変形」が出力されます。バージョン番号や上限値（○件まで、○人まで）も同じ理屈で化けます。検証可能な数値は、AIの記憶に書かせてはいけない——これが出発点です。

三層の防御 — 書かせる前・書いた後・照合のあと

第一層: 資料を同梱し「資料に無い数値は書くな」と縛る

生成時のプロンプトに一次資料（公式ドキュメント、ソースコードの抜粋など）を同梱し、「日付・料金・バージョン等の検証可能な事実は資料からのみ使う。資料に無い詳細は書かずに迂回する」というルールを課します。これだけで捏造の大半は消えますが、「大半」止まりです。資料が薄い部分では、やはり記憶で埋めようとします。

第二層: 生成後に「資料に無い数値」を機械的に検出する

生成された本文から金額・時間・個数などの数値をプログラムで抽出し、同梱した資料の中に存在するか突き合わせます。資料に無い数値が見つかったものは自動公開を止めて、人間のレビュー待ちに落とします。AIを使わない単純な文字列照合ですが、「うろ覚えの変形」はこの層で引っかかることが多い。捏造は数字に出るからです。

第三層: AIに照合させ、判定を3種類に分けて自動修正する

数値以外の主張（「この関数はこう動く」「この設定が既定」など）は文字列照合では検査できないので、本文と資料を並べてAIに照合させます。ここで重要なのが、判定を白黒の2値にしないことです。

  • incorrect（資料と矛盾） → 指摘に沿って最小限だけ書き直す
  • unverifiable（資料からは確認できない） → 削除禁止。断定を弱めるか、根拠の帰属を明示する形（「〜の標準動作として」）に直すだけ
  • confirmed（再確認で裏が取れた） → 逆に「〜とされる」等のぼかしを外して断定に昇格させる

「未確認だから消す」を自動化すると、正しい情報から消えていく

三層目の設計で一度失敗しているので、その話を書いておきます。最初は「確認できない主張は削除」に近い挙動にしていました。安全側に倒したつもりでしたが、実際に起きたのは価値のある正しい情報が真っ先に削られることでした。

理由は単純で、コンテンツの価値は「公式ドキュメントの言い換え」ではなく「資料の外にある経験則や補足」にあるからです。資料の外にあるものは定義上unverifiableになる。つまり「未確認は消す」は「コンテンツの独自性を消す」と同じ操作です。誤った断定を出さないことと、価値ある情報を残すことは、削除ではなく表現の強度調整（断定→根拠つきの限定表現）で両立させる必要があります。

逆方向の「昇格」も同じ発想です。照合を恐れてAIがヘッジ（「〜と思われます」）だらけの文章を書くようになると、正確でも読者の信頼感を損ないます。そこで、いったんunverifiableになった主張を資料から引き直して、裏が取れたものは断定に書き戻させます。ヘッジ→検証→昇格、という往復です。

おまけ: 「検証済みです」とAIに書かせてはいけない

照合を通ったコンテンツに「ソースコードと照合済み」という注記を出したくなりますが、この文をAIに書かせると照合していないコンテンツにも同じ文を書きます。注記の文言そのものが捏造対象になるわけです。うちでは、照合が実際に走ったことをプログラム側がデータとして記録し、表示時にテンプレート側で差し込む形にしました。「事実の記録はプログラム、文章はAI」という分担は、この種の仕組み全般で効く原則だと思います。

まとめ — 捏造は「たまに起きる事故」ではなく仕様

AIの文章生成を運用に載せるなら、料金・数値の捏造は前提条件です。対策は生成前（資料同梱と禁止ルール）・生成後（数値の機械照合）・照合後（判定別の自動修正）の三層に分け、そして「未確認＝削除」ではなく「未確認＝断定の緩和」に倒す。この設計にしてから、公開前に人間が見るのは「照合層が残した警告のレビュー」だけになり、料金事故は再発していません。