AIが書いた文章の作り話をAIにチェックさせるなら点数で合否を決めない|1文ごとに裏付けの引用を返させ、引用の無い文を機械的に落とす仕組み
AIが書いた文章の作り話をAIにチェックさせるなら点数で合否を決めない|1文ごとに裏付けの引用を返させ、引用の無い文を機械的に落とす仕組み
AIにブログやSNS投稿を書かせると、実際には起きていない出来事や、誰も言っていない感想が、自然な文章の中に混ざることがあります。人が毎回すべて読んで確かめるのは続かないので、「書くAI」とは別に「確かめるAI」を置きます。
問題は、その確かめ方です。先に結論を書きます。
AIに文章を採点させ、点数で合否を決める方式では、作り話は止まりません。 点数は文章全体の印象に引っ張られるので、読みやすく筋の通った作り話ほど高得点になります。
合否は、1文ごとの裏付けで決めます。 事実を述べている文を1つずつ取り出し、「この文の根拠になる記述を、渡した事実の一覧から原文のまま引用して返す」ことをAIに求めます。引用が空の文が1つでもあれば、プログラム側で不合格にします。AIに合否を言わせません。
チェックの前に、作り話が生まれる原因を上流で潰します。 原因は3つあります。題材に合わない文章の型(失敗談の型など)を当てていること、書き手の人物設定と題材がぶつかっていること、そして書く側への指示そのものが作り話を勧めていることです。
この記事では、SNS投稿の下書き生成と店舗ブログの生成で使っている検品の仕組みと、そこで測った数字をもとに、チェックの作り方を順に説明します。生成から承認・投稿までの流れ全体はAIで店舗ブログを自動投稿するなら「下書き→検品→承認→投稿」にするにまとめています。そこで書いた「書き手とは別の呼び出しで検品する」は前提として必要です。本記事は、その別呼び出しの検品に何を返させ、どこで合否を決めるかを掘り下げます。
チェックの方式を比べる
AIが書いた文章の確かめ方は、大きく4つあります。
| 方式 | やり方 | 作り話に対する強さ |
|---|---|---|
| 総合点方式 | 別のAIに全文を渡し、点数と講評を返させて点数で合否を決める | 弱い。自然な作り話は高得点になる |
| 一括指摘方式 | 別のAIに全文を渡し、「問題を全部挙げて」と頼む | 中。目立つ矛盾は拾うが、同じ種類の表現を続けて見逃すことがある |
| 引用必須方式 | 事実を述べる文ごとに、裏付けの引用を返させる。引用が空なら機械的に不合格 | 強い。引用の無い文は残らない(抜け道は後述) |
| 小さな質問への分解 | 段落ごとに「実在しない感想が書かれているか」のような、はい・いいえの質問を1つずつ聞く | 強い。基準ごとに判定が分かれるので、見逃しの種類が分かる |
おすすめは、一括指摘方式に下の2つを足し、その前段に機械チェックを置く形です。上の2つだけで運用すると、合否をAIの印象に預けることになります。
なぜ点数方式では作り話が通るのか
点数を付けるAIは、文章を「読み物としての出来」で評価します。話の筋が通っているか、具体的か、読みやすいか。作り話は、この3つをすべて満たします。事実だけで書いた文章より具体的で、起承転結がはっきりしていることもあります。
総合点方式では、次のような下書きが合格します。SNS投稿の下書き生成で、実際に確認した例を2つ挙げます。
- 「ある仕組みが規約違反になっていたので設計を直した」という内容。実際にはそのような違反はしていません。やっていない違反を自分から告白する文章です。
- 「ある業務ツールの送信だけは人がボタンを押すことにしている」という内容。そのような判断をした事実はありません。
どちらも文章としては自然で、教訓もはっきりしています。だからこそ点数が高くなります。前者がそのまま公開されれば、自社の信用を自分で傷つける投稿になります。点数で合否を決めない理由は、この種類の文章を止められないからです。
引用必須方式の作り方
引用必須方式は、次の3つの部品でできています。
1. 事実の一覧(台帳)を先に用意する
書いてよい事実を、1行1事実で並べた一覧を用意します。「いつ・何を・どうした・結果の数字」が短い文で入っていれば十分です。書くAIにも確かめるAIにも、同じ一覧を渡します。
この一覧には、事実の種類を書き分けておきます。
- 自分たちが実際にやったこと(作った、直した、測った)
- 公式の文書や規約に書いてあること(一般的な情報)
この区別が、後で説明する「型の選び方」と「動詞のチェック」で効いてきます。
2. 確かめるAIには、点数ではなく引用を返させる
確かめるAIへの指示は、「採点して」ではなく次の形にします。
本文を1文ずつに分けてください。
各文について、次を返してください。
- kind: 「事実」か「意見・つなぎ」か
- quote: 「事実」の場合、裏付けになる記述を事実一覧から原文のまま抜き出す。
見つからなければ空文字にする。
合否や点数は返さないでください。
返ってくるのは、文ごとの「種類」と「引用」の一覧です。
3. 合否はプログラムで決める
返ってきた一覧を、プログラムで機械的に判定します。
- 「事実」に分類された文のうち、引用が空のものが1つでもあれば不合格
- 引用が事実の一覧に実在するかを、文字列の照合で確かめる
2つ目を省くと、確かめるAIが返した引用が一覧に無い文言でも、裏付けとして通ってしまいます。私たちの仕組みでは、引用を8文字ずつの断片に区切り、その8割以上が事実の一覧の中に見つからなければ、裏付けとして認めない条件にしています。
この方式の利点は、不合格の理由がそのまま書き直しの指示になることです。「この文には根拠がありません」と文単位で返せるので、書くAIはその文を削るか、根拠のある内容に置き換えればよくなります。
引用があっても通ってしまう場合と、機械チェックの足し方
引用必須方式にしても、まだ抜け道があります。
規約の解説のように、一般的な情報しか事実の一覧に無い題材では、「以前はこういう画面を作っていたが、規約を読んで直した」という作り話が、引用必須方式でも合格し得ます。実際に確認した例では、確かめるAIは規約の内容(一般的な情報)を、「自分たちが直した」という文の裏付けとして引用していました。規約にそう書いてあることと、自分たちがそれを踏まえて何かを直したことは、別の事実です。AIの判定は、この区別で揺れます。同じ文が、ある回は不合格、別の回は合格になりました。
ここは機械チェックを足して塞ぎます。
- 題材ごとに「自分たちの行動の事実があるか」を、はい・いいえで持たせる
- 「いいえ」の題材では、本文に行動の動詞(作った、直した、変えた、など)が出た時点で、AIの判定を待たずに不合格にする
一般的な情報しか無い題材で「私たちは〜を直しました」と書ける根拠は、もともとありません。迷う余地のないものは、AIに聞かずにプログラムで決めます。店舗ブログの数字も同じで、本文中の金額・時刻・所要時間が公式の記載に無ければ、機械的な突き合わせで落とします。
判定が揺れる部分を残したまま、合格が出るまで再実行する運用にはしません。揺れる判定は機械チェックに移すか、人の確認に回します。
作り話を生む原因は、チェックの手前にある
検品を強くするだけでは、不合格と書き直しが増えるだけです。作り話が出てくる理由を上流で潰すと、検品に回る前の段階で作り話が減ります。原因として確認できたものは3つあります。
原因1:題材に合わない「型」を当てている
「失敗した→原因はこうだった→こう直した」という型は読み物として使いやすく、書くAIへの指示に標準として入れたくなります。
ところが、失敗が起きていない題材にこの型を当てると、AIは型を埋めるために失敗を作ります。先ほどの「規約違反になっていた」という作り話は、この組み合わせから生まれます。指示に従おうとした結果であって、AIの気まぐれではありません。
対策は、題材ごとに使ってよい型を絞ることです。失敗の事実がある題材だけに失敗談の型を許し、無い題材には「手順の紹介」や「原文を引いた解説」の型だけを許します。
原因2:書き手の設定と題材がぶつかっている
「実際に体験したことだけを語る。評論はしない」という人物設定は、一般的な情報しか無い題材と組み合わさると、作り話を生みます。設定を守ろうとすると、体験が無い題材では1本も書けません。それでも書くよう求められているので、体験を作る方向に押し出されます。
人物設定のルールと、題材が持っている事実の種類が矛盾していないかを、先に確かめます。一般的な情報しか無い題材には、「原文を引いて解説する」型だけを許す、と題材側に印を付けておくと解消します。
原因3:書く側への指示が、作り話を勧めている
お客様向けの文章では、「〜と感じる方もいらっしゃいます」のような、実在しないお客様の声を思わせる表現が問題になります。書くAIへの指示文に、「『〜と感じる方もいます』程度の言い方に留める」のような一文があると、その一文自体が発生源になります。検品の基準では重大な不合格として扱っていても、書く側が同じ表現を勧めている状態です。
同じ種類の不合格が繰り返し出るときは、検品を強くする前に、書く側への指示を読み直します。 禁止したい表現が、例文や「この程度なら可」という形で指示の中に残っていることがあります。
あわせて、基準の置き場所を1つにまとめます。書くAIへの指示、確かめるAIへの指示、機械チェックの正規表現が、それぞれ別の場所に別の言い回しで書かれていると、片方だけ直して片方が古いまま残ります。私たちは基準を1つのファイルにまとめ、そこから3つすべてを組み立てる作りにしています。まとめた時点の中身は、基準10項目、不合格の例文32、合格の例文25、正規表現40です。人が承認や破棄をしたときの理由も記録し、判定の例として使います。基準と判断例は、AIのモデルを替えても残ります。
小さな質問に分解する方式と、調整で測った数字
店舗ブログの検品では、判定だけを行うAIに「はい・いいえ」の質問を1つずつ聞く方式も組み合わせています。全文を渡して「問題を全部挙げて」と頼むのではなく、段落ごとに次のような質問を別々に聞きます。
- 実在しないお客様の感想や発言が書かれているか
- 公式の記載に無い、その店固有の事実が書かれているか
- 公式の記載に無い接客の手順が書かれているか
返ってくるのは、質問ごとの「はい」の確からしさ(0〜1の数値)です。最初の設定では、段落ごとの最大値を記事の値とし、すべての質問で0.3未満なら承認可、1つでも0.3以上があれば人の確認に回しました。0.5以上は明確な引っかかりとして扱います。
この方式は、公開の可否には使わず判定を記録するだけの試運転から始めました。検証用の記事48本で測ると、最初の設定では承認可5本、人の確認に回るものが43本でした。判定の費用は48本で約0.03ドルです。
ここで分かった課題は誤検知です。公式の記載を言い換えただけの文に、「店固有の事実の創作」として0.4〜0.6の値が付くことがありました。人の確認に回る記事が多すぎると、結局ほとんどを人が読むことになります。そこで2段階で調整しました。
| 段階 | 調整の内容 | 結果(同じ48本) |
|---|---|---|
| 1 | 基準を1つにまとめ、判定の質問と不合格・合格の例文を組み立て直す | 言い換えへの誤検知(0.3以上)が10から4に減少。作り話と判定済みの126段落のうち、0.5以上で検出できた数が96から121に増加。承認可は4本 |
| 2 | 作り話の定義を「具体的な体験・発言の創作」に絞る。0.3〜0.5の判断がつかない帯だけ、別のAIにもう一度確かめさせて最終判定にする | 承認可が4本から15本に増加 |
段階2のあと、試しに5店ぶん新しく生成した記事は、すべて1回目で検品に合格しました。
この範囲の数字から言えるのは、基準と例文を組み立て直した段階で検出と誤検知の両方が改善したこと、承認可の本数は作り話の定義と、判断がつかない帯の扱いを変えた段階で動いたことです。
導入の順番
これから検品を組む場合は、次の順で進めると手戻りが少なくなります。
- 書いてよい事実の一覧を作り、「自分たちの行動」と「一般的な情報」を分けておく
- 題材ごとに、使ってよい文章の型を決める。失敗の事実が無い題材に失敗談の型を許さない
- 書くAIへの指示を読み直し、禁止したい表現が例文として残っていないか確かめる
- 機械チェックを先に置く。数字の照合、行動の動詞、実在しない声を思わせる言い回しの正規表現
- 確かめるAIには、点数ではなく文ごとの引用を返させ、引用の実在を文字列で照合する
- 合否はプログラムで決める。確かめるAIが実行できなかったときは不合格側に倒す
- 最初は判定を記録するだけにして公開の可否には使わず、人の判断と一致する割合を見る
7つ目は省かないでください。検品の判定と人の判断が食い違う箇所は、基準の言葉が足りていない箇所です。
制作会社や担当者に任せている場合は、次の3点を聞けば、検品の作りが分かります。
- 合否を決めているのはAIの点数か、プログラムの条件か
- 書いてよい事実の一覧は、どこに、誰が更新できる形で置いてあるか
- 検品が動かなかったとき、記事は止まるのか、そのまま進むのか
想定されるつまずき
検品が厳しすぎて1本も通らない。 作り話の定義が広すぎる状態です。一般的な前置きや、公式の記載の言い換えまで落としていないかを確かめ、「具体的な体験・発言の創作」に絞ります。
確かめるAIが返した引用が、一覧に無い。 引用の実在を文字列で照合していないと、そのまま裏付けとして通ります。照合は必ずプログラムで行います。
再実行すると合格する。 合否をAIの判断に預けている部分が残っています。合格が出るまで回す運用にせず、揺れる判定は機械チェックに移すか、人の確認に回します。
同じ不合格が何度も出る。 書く側への指示か、文章の型か、人物設定のどれかが、その表現を求めています。検品ではなく上流を直します。
まとめ
- AIが書いた文章の作り話は、別のAIに点数を付けさせても止まらない。自然な作り話ほど高得点になる
- 事実を述べる文ごとに裏付けの引用を返させ、引用が空の文が1つでもあれば機械的に不合格にする。引用の実在も文字列で照合する
- 一般的な情報しか無い題材では、行動の動詞が出た時点で落とす。迷う余地のない判定はAIに聞かない
- 作り話の原因は上流にある。題材に合わない型、体験しか語れない人物設定、作り話を勧める例文を先に直す
- 基準は1か所にまとめ、書く側・確かめる側・機械チェックのすべてをそこから組み立てる