AIに書かせた記事の品質チェック：出典・捏造・定型文を見抜く

このサイトのリニューアル準備で、過去記事の書き直しをAIに手伝わせました。テーマだけ渡せば下書きが返ってくるので作業は速く、気づけば数十本単位でファイルが溜まっていました。タイトルも日付もfrontmatterも揃っていて、フォルダを一覧で見ると「あとは公開するだけでは」という見た目です。

ところが、公開前に通して読んでみると、どうもおかしい。文章としては破綻していないのに、読み終わっても何も残らない記事が多かったのです。結局この一群は公開を取りやめ、出典の確認と中身の書き直しを品質条件にして、作り直すことにしました。

この記事は、そのときに「どこを見てダメだと判断したか」を整理したものです。AIに記事の下書きを頼んでいる人の、公開前のひと確認に使えると思います。

中身がない記事に共通していたこと

一番分かりやすかったのは、定型文の繰り返しでした。見出しごとに「要点だけ控えました」「詳しくは公式ドキュメントを参照してください」と書いてあるのに、その要点自体が本文のどこにも出てこない。具体的な手順も、つまずきやすい場面もない。文章の形はしているけれど、情報としては見出しの言い換えでしかありませんでした。1本だけなら「薄い記事だな」で済みますが、これが何十本も並ぶと、型で量産されたことがはっきりします。

もっと困ったのは、やっていないはずの作業が一人称の体験談として書かれていたことです。「実際に試してみたところ」「移行してみて分かったのは」といった書きぶりなのに、その作業自体をそもそもやっていない。体験談らしい文体を書くのはAIの得意分野なので、流し読みだと素通りしてしまいます。でも、やっていないことを「やった」と書くのは読み手への嘘になるので、ここは言い回しの問題ではなく、記事の信用の問題です。

技術記事なのに、コード例がほぼ無いのも目立ちました。考え方や心構えの話で字数が埋まっていて、「で、実際にはどう書くのか」が最後まで出てこない。例を出すには、そのテーマについて具体的に知っていることが必要です。逆に言えば、例が書けないテーマは、まだ記事にする材料が揃っていないということでもあります。

一覧で見たときの兆候もありました。ファイルサイズが、数種類の決まった大きさにきれいに揃っている。参照URLの件数が、どの記事も同じ。本来、テーマが違えば分量も参照の数もばらつくはずで、揃いすぎていること自体が怪しい。1本ずつ読んでいたときには気づかなかったものが、並べて見ると一目で分かりました。日付も、記事によって新しい・古いの整い方だけは立派で、中身が伴っていませんでした。

公開前にやっているチェック

下書きが返ってきたら、最低でも次の6つを見ます。全部を毎回フルでやるのは大変なので、時間がなければ「出典」「体験談」「定型句」の3つだけでも先に通す、という運用にしています。

6項目の早見表がこちらです。時間がないときに先に通す3つには「優先」と付けています。

チェック	見るもの	危ないサイン
1. 出典のURL（優先）	参照URLを実際に開き、記事の主張とそのページの中身が対応しているか	リンク切れ、主張と無関係なページが貼られている、参照の件数が全記事で同じ数に揃っている
2. 数字と固有名詞	バージョン番号、料金、件数、日付を公式ドキュメントなどの一次情報で確認できるか	一次情報で確認できない数字が入っている、固有名詞の表記ゆれ、実在しない機能名
3. 一人称の体験談（優先）	「試してみた」「使ってみた」という文が、自分が実際にやった作業かどうか	やっていない作業が一人称の体験談として書かれている
4. 定型句（優先）	本文を検索して、同じ言い回しが何度も出てくる箇所	見出しごとに「整理しました」「まとめると」「重要です」といった句が繰り返されている
5. 構造と分量	複数本を並べて、見出しの数、段落の長さ、参照の件数、ファイルサイズを比べる	不自然に均一に揃っている
6. 具体例	技術記事ならコード例や実際のコマンド、設定値。手順の記事なら画面や操作の具体的な段取り	具体例がひとつもない

1. 出典のURLは実在するか、内容が合っているか

URLを実際に開いて、記事の主張とそのページの中身が対応しているか確認します。リンク切れは論外ですが、開けても主張と無関係なページが貼られていることがあります。参照の件数が全記事で同じ数に揃っている場合は、内容を見て選んだのではなく件数だけ合わせた可能性が高いので、特に念入りに見ます。

2. 数字と固有名詞を裏取りする

バージョン番号、料金、件数、日付のような具体的な情報ほど、そのまま信じないことにしています。公式ドキュメントなどの一次情報で確認できない数字は、記事から落とすか、書き方を変える。数字が入ると文章は一気に説得力を増すので、間違った数字が混ざっている記事ほど危険です。固有名詞の表記ゆれや、実在しない機能名が混ざっていないかもここで見ます。一次情報で裏取りする手順自体は、AIの回答を一次情報で検証する手順に分けました。

3. 一人称の体験談は、本当にやったことか

「試してみた」「使ってみた」という文は、自分が実際にやった作業かどうかで機械的に切り分けます。やっていない作業の体験談は、表現を柔らかくしても捏造のままです。心当たりのない体験談が入っていたら、その段落だけ直すのではなく、記事全体の他の記述も疑うようにしています。指示の段階で「体験談は書かない。事実と手順だけを書く」と決めておくのも、予防としては効きます。

4. 定型句が繰り返されていないか

同じ言い回しが見出しごとに出てくるのは、内容が足りていないサインです。本文を検索して、「整理しました」「まとめると」「重要です」といった句が何度も出てくる箇所を探します。見つけたら、その段落は具体例に置き換えるか、段落ごと削る。言い換えでごまかしても中身は増えません。

5. 構造と分量が揃いすぎていないか

これは1本だけ読んでも分からないので、複数本を並べて見ます。見出しの数、段落の長さ、参照の件数、ファイルサイズが不自然に均一なら、同じ型で生成された可能性が高い。厄介なのは、均一な下書きは1本だけ直しても意味が薄いことで、同じ問題が他の記事にも並んで残ります。並べて見る習慣は、量産された下書きへの一番安い検出方法だと思っています。

6. 具体例が本文にあるか

主張だけの記事はどうしても薄くなります。技術記事ならコード例や実際のコマンド、設定値があるか。手順の記事なら、画面や操作の具体的な段取りがあるか。具体例がひとつもない記事は、その場で例を足そうとするより、「このテーマで書ける材料が本当にあるのか」から見直した方が早いことが多いです。

1つ当たったら即ダメ、というわけではない

正直なところ、上の項目は1つだけなら人間が書いた記事でも当たります。締めの言い回しが被ることもあるし、参照の数がたまたま揃うこともある。

危ないのは複数が重なったときで、とくに「体験談の捏造」と「出典の裏付けなし」が重なった記事は、部分的な修正では直りません。自分のケースでは、その重なり方が一群全体に広がっていたので、直すのではなく作り直す判断になりました。下書きを全部捨てるのはもったいなく感じますが、中身のない記事を公開してしまう方が、後から取り返すのが大変です。テーマの選び方自体は使えることが多いので、タイトルとテーマだけ残して本文は書き直す、という落としどころもあります。

AIに書かせること自体は、やめてはいません。今も下書きや調べものの整理には使っています。変わったのは位置づけで、下書きが溜まったことを進捗と数えるのをやめました。チェックを通って初めて下書き、通らなければテーマだけのメモ。このチェックリスト自体、その失敗の副産物です。そもそもAIにどこまで任せるかという線引きは、AIに任せる作業・任せない作業の線引きで整理しています。