概要

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に書いています。

作ったものやポートフォリオはこちらです。