AIが書いた記事の誤りと、公開前に置いた機械の検査

AI で記事を書き、記事の生成から公開までを自動で回す仕組みを、2つのサイトで動かしています。AI ニュースの解説サイト「AIBloom」（2026年3月31日に開始）と、テクノロジーと暮らしのウェブマガジン「Chronicle AI」（4月10日に今の形で開始）です。動かし始めて数週間のうちに、架空の型番、「推奨モデルA」のような仮の製品名、元記事に無いモデル名、存在しない出典 URL が記事に出ました。Chronicle AI では、同じ仕組みの中の AI の採点が、誤りのある記事にも100点満点の95点を付けていました。そこで、決まった形の誤りを機械で調べる検査を、公開の前に足していきました。分かったのは、AI の自己評価では誤りが止まらないことと、機械の検査が止められるのは一度見た形の誤りだけだということです。2つのサイトの自動の公開は今も続いていますが、warp-studio.com からは利用の案内をしていません。この記事は、AI 記事を増やす方法の紹介ではなく、出た誤りと検査の記録です。

2つのサイトの仕組み

Chronicle AI の運用メモ（4月18日）は、1回の生成を、素材集め、生成、編集の採点、検査、ビルド、公開の6つの段に分けています。そのうえで、検査とビルドは、失敗したら公開を止める側に置いています。

出た誤り

「（想定）」の付いた型番

4月15日、Chronicle AI はスマートウォッチの比較記事を公開しました。比べる製品は「Galaxy Watch 8 Pro (想定)」のように書かれ、スペックの表も想定の値でした。記事の末尾は、文の途中で切れていました。この記事に AI の編集長が付けた点は、100点満点の95点です。

翌16日に記事を書き直し、訂正の履歴には「架空の型番表記を削除し、2025年発売の実在モデル（Series 11 / Ultra 3 / Galaxy Watch8 / Pixel Watch 4）の公式情報をもとに全面改訂。」と残しました。その5分後に、レビュー記事の本文に「（想定 ...）」の形があれば公開を止める検査を足しています。

「推奨モデルA」という仮の名前

4月20日に公開したスマートリングの比較記事は、製品を「推奨モデルA」「推奨モデルB」と呼んだまま、結論まで書いていました。「（想定）」の形ではないので、前の検査は通っています。編集長の点は、ここでも95点でした。

翌21日のコミットは、原因を「AI が実在モデルを特定できない時に placeholder で埋めて形だけ整えていた」と書いています。記事は実在の製品名で作り直し、訂正の履歴を付けました。

元記事に無いモデル名

AIBloom では、話題の背景として、AI のモデル名の一覧を毎回 Gemini に渡していました。4月14日のコミットによると、Gemini はこの一覧から GPT-5.4 などの名前を拾い、元記事が一度も触れていない製品について、そのモデルとの連携が決まったかのように書いていました。一覧は背景の理解のためだけに渡すと指示に明記し、元記事が名前を挙げていない限りモデル名を事実として書かない、という決まりを足しました。

存在しない出典 URL

4月16日には、公開済みの記事の出典 URL が、実在しないページを指していたとして、別の媒体の記事に差し替えています。同じ日に、Gemini の検索機能が返す中継用の URL も、本来の出典に置き換えるようにしました。置き換えられない項目は、記事にしません。

AI の採点は誤りを止めなかった

Chronicle AI の運用メモには「LLM は自分の出力を甘く評価しがちなので、公開判定を 1 つの自己評価だけに依存させない。」とあります。Anthropic の記事を参考に書いたメモで、日付は4月18日です。仮の製品名の記事が公開されたのは、その2日後でした。採点の段は別にあっても、製品名について機械の検査が知っていたのは「（想定）」の形だけでした。

AIBloom でも、10月1日に AI の作業者が公開前の判定を試しています。元記事に忠実な記事にも、作業者が元記事に無い内容を含むと判定した2本にも、判定の AI は同じ「PUBLISH」の9点を返しました。判定の指示文に入っているのは原稿だけで、元記事の本文は渡していません。

公開の前に置いた機械の検査

足していった検査は次のとおりです。どれも機械が決まりどおりに調べ、引っかかれば公開に進めません。

仮の製品名の検査は、次の正規表現です。

if (topic.type === 'review') {
  const placeholderPattern = /推奨モデル\s*[A-Z]|候補\s*[A-Z1-9１-９](?![A-Za-z0-9])|モデル\s*[A-Z](?![A-Za-z0-9])|製品\s*[A-Z](?![A-Za-z0-9])|機種\s*[A-Z](?![A-Za-z0-9])|リング\s*[A-Z](?![A-Za-z0-9])/g;
  const placeholderMatches = body.match(placeholderPattern);
  if (placeholderMatches && placeholderMatches.length > 0) {
    const samples = [...new Set(placeholderMatches)].slice(0, 3).join('、');
    errors.push(`review記事に匿名記号での製品参照が含まれています（検出例: ${samples}）。実在の製品名・ブランドラインで書き直してください`);
  }
}

あわせて、AI の編集長にも、仮の製品名が1か所でもあれば書き直しと判定するよう指示を足しました。検査のほうには9つのテストを付けました。「製品Aは優秀です。」は引っかかり、「このモデルは最高の体験を提供します。」や「Oura Ring 4 は...」は通ります。誤りを拾うかだけでなく、ふつうの文を止めないかも試しています。

AIBloom の出典の確かめ方は、次のとおりです。ボット除けで 403 が返る記事と、そもそも存在しない記事を分けるため、ブラウザとして取り直します。

// 403 はボット弾きの場合と記事が存在しない場合の両方があるため、
// ブラウザ UA で再確認して 404 なら架空URLと判定して除外する
if (!html && fetched.status === 403) {
  const verify = await fetchHtml(resolvedDiscoveredUrl, true);
  if (verify.status === 404) {
    return null;
  }
  // ブラウザ UA で HTML が取得できた場合はそちらを使う
  if (verify.html) {
    html = verify.html;
  }
}

今の AIBloom の公開処理では、出典 URL、雛形の残り、画像の置き場所を機械で調べてから、AI の判定に回します。検査や対策のコードは、AI のコーディング支援を使って書いています。

検査が止められるのは一度見た形だけ

「（想定）」の検査は「推奨モデルA」を止められませんでした。この記事で挙げた4つの誤りへの対策は、どれも誤った記事が出てから足したものです。正規表現は、知っている形しか探せません。

内容が元記事と合っているかは、こうした検査では分かりません。AIBloom では10月1日に、元記事の URL を Gemini に直接読ませて書く方式を先に使い、読めないときだけ検索で調べて書く方式に替えました。同じ日に AI の作業者がモデルを比べたところ、それまでの検索で調べて書く方式の記事にも、元記事に無い内容を含むものがあり、作業者は元記事を読ませる方式を勧め、私がその案で進めることにしました。

warp-studio.com での扱い

2026年10月の動作確認では、AI の作業者が作品ごとに扱いの案を作り、10月6日に私が案のとおりに決めました。Chronicle AI は「休止中」、AIBloom は「記録のみ」です。どちらも 過去の制作の一覧のうち Chronicle AI の項目と AIBloom の項目に制作の記録だけを載せ、利用先へのリンクは出していません。止めたのはこのサイトからの案内で、2つのサイトの自動の公開は止めていません。動作確認をした10月6日にも、どちらも当日の記事が公開されていました。AIBloom の案の理由には、他の媒体の記事を AI が要約する形で「独自性が薄く大量生成に近い（推測）」とあります。

Google 検索のスパムに関するポリシー（別タブで開きます）は、ユーザーをサポートすることではなく、検索ランキングの操作を主な目的として大量のページを生成することを、「大量生成されたコンテンツの不正使用」としています。この不正行為は通常、価値がほとんど無く独自性のないコンテンツを、作成方法を問わず大量に作るもので、例の一つに、生成 AI を使って価値を付加せずに大量のページを作ることが挙がっています。機械の検査が見ているのは決まった形の誤りで、記事に独自の中身があるかどうかは見ていません。AdSense と広告の選び方の経緯は、AdSense に落ちたサイトを数え直した制作ノートに書いています。

作った本人に採点させない考え方は、英会話アプリ「イエタ」の開発でも使っています。AI が書いたコードを別の AI が操作して採点する仕組みは、改善ループのゲート設計についての制作ノートにまとめました。