← Back to Blog
Journal

AIが書いた記事をどう信用するか――出典検証を仕組みにする

· Yuki Tachi
AIClaude Code自動化ハルシネーション検証ブログ

はじめに

以前の記事で、Notionのネタを起点にClaude Codeが記事を自動生成するパイプラインを紹介しました。運用を続けて分かったのは、ボトルネックが「書く」ことから「信用する」ことへ移る、という事実です。下書きは毎晩できあがります。問題は、公開ボタンを押す前に、何をどう確かめるかです。

本記事では、生成パイプラインの後段に足した「出典検証」のワークフローと、そこで実際に見つかった誤りの分類を紹介します。結論を先に言えば、AIの誤り方には型があり、型ごとに検出方法が違います。「AIは幻覚を見るので気をつけましょう」という一般論ではなく、自分の記事から出てきた実例で示します。

背景・課題――「書く」の次は「信じる」が詰まる

パイプラインの構成は以前と同じです。Notion「ブログネタ」の1件を、FreeBSDサーバー上のcronが日本時間19時に取り出し、Claude Codeの非対話モードが記事を書いてdraft: trueでGitにコミットします。人間が公開前にレビューする建て付けですが、「レビュー」の中身を決めないままでは、もっともらしい文章を眺めて終わりになりがちです。

LLMがもっともらしく事実と異なる内容を生成する現象は、ハルシネーションとして広く研究されています（Ji et al., 2023）。近年のサーベイでは、世界の事実と食い違う「事実性」の幻覚と、与えた指示や文脈と食い違う「忠実性」の幻覚に大別されます（Huang et al., 2025）。ただ、運用者として欲しいのは生成メカニズムによる分類ではなく、「どう検出するか」で引ける分類です。

そこで、生成の後段に検証ステップを足しました。公開前にWeb検索と原典取得で記事中の出典を洗い、結果をNotionの「公開前チェックリスト」トグルに- [x]（検証済み）と- [ ]（要対応）で残します。修正は人間が手で直すのではなく、構造化した指示書をClaude Codeに渡して適用させます。この検証を数本の記事で回した結果、見つかった誤りは4つの型に分かれました。

本論――失敗モードの分類学

型①：捏造引用――存在しない出典

最も危険で、最も検出しやすい型です。FreeBSDのアップグレード記事の初稿では、著者名・発行年・タイトルの体裁が整った参考文献のうち4件について、該当する記事やIssueの実在が確認できませんでした。検証後は、実際に手順が一致する公式リリースノートや公式フォーラムのスレッドに差し替えています。

検出は単純で、URLを実際に取得することです。開けない、または内容が主張と一致しない出典は、それだけで除外できます。体裁の整い方と実在性はまったく相関しない、というのが実感です。

型②：逐語不一致――引用符の中身が原文と違う

出典は実在するのに、引用句が原文と一致しない型です。1990年代Unixの記事では、OpenBSD 2.7の収載内容として「Latest KAME IPv6」という引用を書いていましたが、リリースページの原文は “Latest KAME IPv6 as of mid-May 2000.” で、末尾が切り詰められていました（OpenBSD Project, 2000a）。最終的には、変更履歴ページの逐語 “Integration of KAME IPv6” に引用句と出典を揃えて解決しました（OpenBSD Project, 2000b）。

検出方法は「引用符の中身を、引用元ページで文字列一致させる」ことに尽きます。ここで筆者自身の誤判定も正直に書いておきます。最初の検証では変更履歴ページだけを見て「この引用句は存在しない」と記録しました。実際にはリリースページのほうに実在していたのです。検証する側も、別のページを見て「存在しない」と断定する誤りを犯します。不在の証明は存在の証明より難しく、検証結果にも検証が要る、という教訓でした。

型③：出典側の記述変更に取り残された古い事実

モデルの学習時点では正しかった（可能性が高い）のに、その後に出典側が書き換わっている型です。Dev Containerの記事では、WSL2のメモリ既定値を「ホストの50%か8GBの小さい方」と書いていましたが、現行の公式ドキュメントの既定値は “50% of total memory on Windows” のみで、8GB上限の記述は見当たりません（Microsoft, 2026）。また、MCPサーバーの記事では、AWSのホワイトペーパーの発行年を2024年としていましたが、実際の発行日は2021年3月8日で、しかも文書冒頭には現在 “for historical reference only”（歴史的参照のみ）と明記されています（Amazon Web Services, 2021）。

これは厳密にはハルシネーションと呼びにくい型です。知識が架空なのではなく、出典そのものが動いたのですから。検出方法は「引用元の現在の記述を見に行く」こと。URLが生きているかどうかではなく、いま何と書いてあるかを確認します。

型④：出典より踏み込んだ断定――過剰な具体化

出典の粒度を超えて具体的に書いてしまう型です。Vine Linux 1.0のベースを本文で「Red Hat Linux 5.2」と書いていましたが、引用元であるProject Vineのプレスリリースの実記載は「RedHat Linux 5.x ベース」でした（Project Vine, 1998）。5.2という値はもっともらしく、事実としても大きくは外れていないのでしょう（これは筆者の推測です）。しかし出典が5.xとしか言っていない以上、記事も5.xに留めるべきです。

検出方法は「主張の粒度を出典の粒度と照合する」こと。文は自然で、出典も実在し、引用も壊れていないため、4つの型のなかで最も見落としやすいと感じています。

一次資料は「格上げ」ではなく「検算」になる

検証の過程で最も面白かった発見です。Unix史の記事はWikipedia中心の出典で書かれていたため、USL v. BSDi訴訟の段落に当事者McKusickの一次資料を併記することにしました。出典を権威づけする、いわば「格上げ」のつもりの作業でした。ところがその一次資料は和解について “a settlement was finally reached in January 1994” と述べており（McKusick, 1999）、本文が二次情報から引いていた「1994年2月和解」と食い違ったのです。複数の情報源を突き合わせたうえで、和解月は1月に修正しました。

二次情報だけで固めた記述は、内部では整合していても、一次資料を一枚当てると矛盾が露出することがあります。一次資料の価値は飾りではなく、独立した系統の情報源として検算に使えることにある――そう捉え直しました。

実践への応用・考察

検証ループの運用は、次の分業に落ち着いています。検証はAI（Web検索と原典取得）、記録はNotionのチェックリスト（何を確かめ、何が未確認かを追跡可能にする）、修正の適用もAI、判断だけを人間が握る。修正指示書には、対象ファイルの特定方法、置換前後の一意な文字列、修正の根拠、スコープ外（変更してはいけない箇所）の明示、適用後のgrepでの確認手順を書きます。曖昧な「直しておいて」ではなく、レビュー可能な差分に落ちる指示にするのが要点です。

型ごとの検出方法をまとめると、次の3つの操作で大半の誤りは落ちます。

  • 引用符の中身は、引用元ページで文字列一致させる（型①・型②を検出）
  • 引用元の現在の記述を見に行き、主張の粒度を出典の粒度に合わせる（型③・型④を検出）
  • 二次情報で固めた重要な事実には、一次資料を一枚当てる（検算）

なお、この4分類は筆者が自分の記事数本を検証して得た経験則であり、網羅的である保証はありません。対象が広がれば型は増えるだろう、というのが正直な見立てです。

まとめ

  • 記事生成を自動化すると、ボトルネックは「書く」から「信用する」へ移る。
  • 誤りには型がある。捏造引用・逐語不一致・出典側の記述変更・過剰な具体化の4型は、それぞれ検出方法が違う。
  • 一次資料は権威づけではなく検算に使う。二次情報同士が整合していても正しさは保証されない。
  • 検証する側も誤判定する。「存在しない」という断定には、存在の確認以上の慎重さが要る。
  • 自動生成の信頼性はモデルの優秀さではなく、検証ループの有無で決まる。

生成パイプラインの全体像は「この記事はAIが自動生成しています」を参照してください。生成と検証はセットで、ようやく一つの仕組みです。なお本記事もそのパイプラインの出力であり、公開前に同じ検証を通ります。

参考文献

学術論文

  • Huang, L., Yu, W., Ma, W., Zhong, W., Feng, Z., Wang, H., Chen, Q., Peng, W., Feng, X., Qin, B., & Liu, T. (2025). A Survey on Hallucination in Large Language Models: Principles, Taxonomy, Challenges, and Open Questions. ACM Transactions on Information Systems, 43(2). https://doi.org/10.1145/3703155
  • Ji, Z., Lee, N., Frieske, R., Yu, T., Su, D., Xu, Y., Ishii, E., Bang, Y. J., Madotto, A., & Fung, P. (2023). Survey of Hallucination in Natural Language Generation. ACM Computing Surveys, 55(12), Article 248. https://doi.org/10.1145/3571730

公式ドキュメント

Web記事

← Back to Blog