概要
AIに書かせた記事を、AEO審査で採点して、その指摘を次の改善再生成へ渡す。
この「書く→採点する→直す」を自動で回す仕組みを作っていました。
ある日、そのループを通した記事の本文に、架空の日付と金額が、あたかも自分の体験のように書き込まれていたんです。
原因は、採点する側が出したアドバイスの中の「例文」でした。
この記事では、その混入がどう起きたのかと、防ぎ方をどう整理したかを、手順の形でまとめます。
こんな人に向けて書いています
- レビュー→自動修正ループを組む人
この記事でわかること
- 審査コメントの例文が、次の生成で「事実」に昇格する経緯
- 体験談保護では、架空内容の追記を防げなかった理由
- 対策として整理した2つ（審査側の指示の書き方／改善後の一次情報チェック）
なお、混入した日付や金額そのものは架空の値なので、この記事には転記していません。
前提
- 「生成 → 採点 → 再生成」を自動で回す構成を想定しています。
AEO審査の指摘を、次の「改善を反映して再生成」へ渡す構成にしていました。
一言でいうと、採点の出力が、次の生成の入力になる構造です。
この記事で扱う事故は、まさにこの「つなぎ目」で起きました。
図にすると、こういう並びです。
生成 → AEO審査（採点・指摘）→ 改善を反映して再生成 → 公開へ
└──────── 指摘をそのまま渡す ────────┘
何を作ったか
記事の改善再生成パイプラインです。
その工程のひとつに、記事を採点して改善指摘を返すAEO審査のステップがあります。
そして次の工程が「改善を反映して再生成」。
審査が返した指摘を読んで、本文を書き直します。
この2つを直列につないだ構成です。
なぜ問題だったか
今回は、E-E-A-Tを目的とした体験談の中で事実が捏造されました。
記事の信頼性を上げるために厚くした部分が、いちばん嘘を含みやすい場所になっていた、ということです。
何が起きたか：審査の「例文」が本文の「実体験」になった
審査が返してきた指摘は「使用期間・金額を明示せよ」というものでした。
そして審査は、その指摘に説明用の例文を添えています。
その例文には、移管した時期・請求書の年月・金額といった具体値が並んでいました。どれも実在しません。審査役が例として提案した値です。
次の工程は、この指摘を読んで本文を書き直します。
結果、この日付と金額が、筆者の実体験として本文に書き込まれました。
審査コメントの例文が、改善再生成によって、記事本文の「事実」になっていたわけです。
このときパイプラインには、生成済みの体験談を勝手に書き換えさせないためのガード（体験談保護）も入っていました。
けれどこれは既存の記述を保持するためのもので、新しく架空の記述が追記されるのは止められません。
既存内容は守れたが、新規追記は対象外だった、ということです。
その記事は、手作業で実データに置き換えてから公開しています。
値がどう渡っていったかを並べると、こうなります。
[AEO審査の指摘]
「使用期間・金額を明示せよ」
例：移管時期 / 請求書の年月 / 金額 ← 説明用の例文（実在しない値）
↓ 指摘を丸ごと次の工程へ
[改善を反映して再生成]
例文の値を「筆者の体験」として本文に記述 ← ここで例文が事実に昇格
↓
[体験談保護]
既存の体験談の書き換え → 防げる
新しい架空の記述の追記 → 防げない ← 守備範囲の外
E-E-A-Tのために厚くした体験談の部分で、事実が捏造される。
目的と事故が同じ場所で起きるのが、この構成のいやなところでした。
手順：対策として整理した2つ
手順1. 審査側に、架空の具体データを書かせない
改善指摘の例文に、架空の日付や金額を書かせないようにする、ということです。
実行するのは入口側、つまり審査が指摘を組み立てるタイミング。
本文を直す前、改善再生成へ指摘を渡すより手前で効かせます。
確認する対象は、審査が返す指摘そのもの。
とくに「例として」「たとえば」の形で添えられた文の中に、日付・金額・使用期間のような具体値が入っていないかを見ます。
今回混入したのは、まさにこの位置に置かれた値でした。
手順2. 改善ループのあとに、一次情報チェックを挟む
もうひとつは出口側です。
改善後に、本文の内容が一次情報にあるかを確認します。
タイミングは、改善再生成が終わった直後。
採点を通ったかどうかに関係なく、公開へ進む前に必ず一度通す位置に置きます。改善を何周か回す構成なら、周回ごとに見るのが安全です。
確認する対象は、本文に出てくる日付・金額・使用期間・体験の記述。
それぞれについて「この値は一次情報のどこに書いてあるか」を答えられるかどうかで判定します。答えられないものは、書き手が知らないうちに増えた記述です。
前者は混入を減らす対策、後者は混入したものを見つける対策です。
チェックを置く位置
2つを置く位置を、さっきの並びに重ねるとこうなります。
生成 → AEO審査（採点・指摘）→ 改善を反映して再生成 → 公開へ
▲ ▲
│ 対策1：入口側 │ 対策2：出口側
│ 指摘の例文に具体値を書かせない │ 本文の値が一次情報にあるか確認
そのまま使えるよう、確認項目の形にすると次の2ブロックです。
[入口：審査の指摘を渡す前]
- 指摘の中に「例として」「たとえば」で始まる文はあるか
- その文に 日付 / 金額 / 使用期間 の具体値が入っていないか
- 入っていたら、具体値を外してから次の工程へ渡す
[出口：改善再生成の直後・公開の前]
- 本文の 日付 / 金額 / 使用期間 / 体験の記述を洗い出す
- それぞれ「この値は一次情報のどこに書いてあるか」を答えられるか
- 答えられない記述は、ループ中に増えたものとして扱う
結び
採点と生成をつなげてループにすると、片方の「たとえ話」が、もう片方にとっての「事実」になる瞬間があります。
もうひとつ効いたのは、ガードの守備範囲が片側だけだったことです。
体験談保護は既存内容の保持には効きましたが、架空内容が追記されるのは防げませんでした。
守りたいものを言葉にするときは、何を禁止しているのかを確認しないと、守れていない方向が残ります。
個人でAIツールや業務自動化を作っているMiyokiといいます。
記事の生成パイプラインのように、自分の作業を楽にするための小さなツールを作っては、その開発ログをZennとQiitaに書いています。
作ったものやポートフォリオはこちらです。