← Back to Blog
Journal

出典検証を回し続けて見えた想定外――失敗モード分類の追補と「検証する側の失敗」

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

はじめに

分類を作ったとき、この3件は想定していませんでした。

前回の記事で、AIが自動生成した記事の誤りを4つの失敗モードに分類し、型ごとの検出方法を整理しました。末尾には「対象が広がれば型は増えるだろう」と書いています。予告より早く、2か月の運用で分類に収まらない事例が3件出ました。いずれも検証チェックリストとgit履歴の一次記録が残っています。

本記事はその運用報告です。主題は分類の完成度でなく、分類を現場に当て続けると分類のほうが更新される、という事実です。最後の1件は「検証される側」ではなく「検証する側」の失敗で、前回の分類にはなかった軸です。

背景・課題――前回の4型と検証フロー

前提を再掲します。生成パイプラインは、Notionのネタ帳から1件を取り出し、cronで起動したClaude Codeが記事を書いてdraft: trueでコミットする構成です。後段に出典検証を置き、公開前にWeb検索と原典取得で出典を洗い、結果をチェックリストに残し、修正の適用もAIに任せ、判断だけを人間が握ります。

前回の分類は次の4型でした(型番号と定義は公開済みの前回記事から引き直しています)。

  • 型①捏造引用――存在しない出典。URLを実際に取得すれば落ちる
  • 型②逐語不一致――出典は実在するが引用句が原文と違う。引用元ページで文字列一致させる
  • 型③出典側の記述変更に取り残された古い事実――学習時点では正しかったが出典が書き換わった。引用元の現在の記述を見に行く
  • 型④出典より踏み込んだ断定(過剰な具体化)――出典の粒度を超えて具体的に書く。主張の粒度を出典の粒度と照合する

4型はいずれも「生成テキスト」と「引用元」のずれとして定義され、検出も両者の突き合わせに帰着します。今回の3件はこの枠が崩れたケースで、1件目は引用元が存在しない自己データ、2件目は突き合わせる時点のずれ、3件目は突き合わせる主体である検証者自身の誤りです。

本論――分類に収まらなかった3件

変種1:ネタ帳由来の実値が検証を素通りする――型④の上流版

Poetry移行の記事には、依存の入れ替えでpoetry.lockのパッケージ数が減った、という自己データの数値が出てきます。初稿では「42から37に減り、推移的依存19個が消えた」でした。この数値はネタ帳の執筆ブリーフに実値として与えられ、生成はそのまま採用し、出典検証も素通りしました。

素通りした理由は構造的です。検証フローは主張を引用元と突き合わせる操作でできていますが、自分のリポジトリの数値には引用元がなく、照合対象がないので照合は行われず、チェックリストにも項目が立ちません。型④は「出典より踏み込んだ断定」でしたが、この件は出典に当たる工程より上流のネタ帳の段階で未検証の具体値が混入した、型④の上流版です。

捕捉したのは公開直前にpoetry.lockのgit履歴を実測したときでした。移行前後のコミットで、ロックファイル中のパッケージ名をユニーク名で数えます。

git show <移行前コミット>:poetry.lock | grep '^name = ' | sort -u | wc -l
git show <移行後コミット>:poetry.lock | grep '^name = ' | sort -u | wc -l

結果は48から38でした。内訳は直接依存2個と推移的依存17個の削除と、新しい直接依存1個とその推移的依存8個の追加で、初稿の「42→37」「推移的19個」とは一致しません。記事は2026年8月25日の修正コミットで実測値に置き換え、本文に「ロックファイルのgit履歴から実測」と出所を明記しました。

教訓は、自己データの実値は「出所(取得コマンドと日付)を明記できない限り未検証扱い」とすることです。出典のない数字は出典のある数字より検証されにくい、というのが運用した実感です。

変種2:寝かせた原稿が引用元の更新に取り残される――型③の時間軸版

2件目はNotion MCPの記事です。2026年6月9日に下書きが生成され、2か月半寝かせて8月25日に公開しました。初稿には「ファイルアップロードは執筆時点では未対応で、ロードマップ上の機能」とあり、6月時点の公式ドキュメントには忠実でした。ところが公開前に引用元を見に行くと、FAQにnotion-create-file-uploadツールで20 MiBまでのファイルをアップロードできると書かれていました(Notion Developers, 2026)。執筆時には正しく、公開時には引用元と矛盾する状態です。

同じことが散歩しながらAI開発する記事(6月7日下書き、8月29日公開)でも起きました。初稿は「TermuxのPlayストア版は更新が止まっている」でしたが、公開前の時点でTermuxの公式リポジトリは、Android 11以上向けのビルドがGoogle Playに存在し、ただし開発途上で機能欠落やバグがあるため多くのユーザーは引き続きF-DroidかGitHubビルドを使うべきだ、と案内していました(Termux, 2026)。「更新が止まっている」は公開時点では誤りです。

前回の型③は「学習時点」と「出典の現在」のずれ、今回は「執筆時点」と「公開時点」のずれで、起点が学習データから原稿に移っています。LLMは一度訓練されると更新されず、変化の速い知識を問う質問では規模を問わず全モデルが苦戦します(Vu et al., 2023)。モデルが公称する知識カットオフと実効的なカットオフも、しばしば一致しません(Cheng et al., 2024)。生成物の「新しさ」はもともと保証されておらず、draftのまま寝かせる運用はその劣化に時間を足す行為です。対策は、寝かせた原稿は公開直前に引用元の現在の記述を再確認する工程を必須にすることです。この時間軸の問題は、8月26日のdraft運用の記事の末尾でも触れています。

なお本記事がこの型を踏むと洒落にならないので、上記2件の引用元は執筆時点(2026年9月)で再確認しています。

新しい軸:検証者の記憶のほうが古かった

3件目は性質が異なります。KUSANAGIにWinter CMSを相乗りさせる記事には、SELinuxポリシーで/usr/bin/nginxと/usr/bin/php-fpmがhttpd_tドメインのエントリポイントとして定義されている、という記述があります。検証側はこれを「/usr/sbin/nginxの誤記ではないか」と疑いました。デーモンの実行ファイルはsbinにある、という記憶に基づく指摘です。

原文を引くと、記事のほうが正しかった。httpd_selinux(8)のマニュアルページはhttpd_tドメインの既定のエントリポイントとして/usr/bin/nginxや/usr/bin/php-fpmを列挙しており、記事はこれを忠実に引用していました(SELinux Project, 2026)。誤っていたのは検証者の記憶で、git履歴上もこの箇所は初稿から公開版まで変更されていません。

前回の4型はすべて「生成側の失敗」でした。この件は「検証側の失敗」で、中身は型③と同型です。古い知識で現在の記述を断定する。違うのは、やったのがモデルではなく検証者だったことだけです。前回も「この引用句は存在しない」と誤判定した件を書きましたが、あれは別のページを見て断定しました。今回は記憶による積極的な誤指摘で、放置すれば正しい記述を誤りに書き換えるところでした。

ここから「検証は記憶ではなく原文で」を検証者側の規律として定式化しました。指摘には原文の根拠を添え、「そう記憶している」だけの指摘は修正指示に載せる前に原文で確認する。AIが検証し人間が判断する分業でも、その逆でも同じように成立します。役割にかかわらず、記憶で断定する主体は同じ失敗モードを持つということです。

分類の更新と仕組みへの反映

3件を整理すると、型④の上流に「ネタ帳由来の未検証実値」、型③に時間軸の変種「執筆時点と公開時点のずれ」、新しい軸として「検証者の失敗」が加わります。これを公開前チェックリストの3項目に落としました。

  1. ネタ帳・ブリーフに書かれた実値には、取得コマンドと日付を必ず添える。添えられない値は未検証として扱う
  2. 公開直前に引用元の現在の記述を再確認する。draft期間が長い記事は必須
  3. 検証側の指摘にも原文の根拠を必須とする。根拠のない指摘は修正指示に載せない

前回の4型が突き合わせの内容を定義したのに対し、今回の追補は「いつ・誰が・何を根拠に」という突き合わせの条件を定義しています。

実践への応用・考察

分類の価値は網羅性にはない、というのが結論です。3件は既存の型に収まりませんでしたが、「型④の上流版」「型③の時間軸版」「型③の検証者版」と既存の型を基準に言語化できました。分類があったから新しい失敗を既知との差分として記述でき、対策も既存の検出操作の拡張として書けました。分類は正解表ではなく、新しい失敗を言語化する台座です。

もう1つは、検証の仕組みは検証者自身の失敗を記録して初めて閉じる、という点です。3件目を「検証側のミス」で済ませれば、次も同じ記憶で同じ指摘が出ます。チェックリストに検証側の規律を書いたのは、失敗を仕組みの穴として扱うためです。AIへの責任転嫁でも人間の自罰でもなく、どの主体でも起こる失敗として工程に落とす。このシリーズで自分たちの失敗を隠さず書いているのは、その方針の一部です。

なお今回の3件も、筆者のパイプラインの数本の記事から得た経験則です。他の運用で同じ型が出るかはデータがなく、ここでの一般化は筆者の見立てにとどまります。

まとめ

  • 分類を2か月運用したところ、既存の4型に収まらない事例が3件出た。いずれもgit履歴と検証記録が残っている
  • 出典のない自己データは検証を素通りする。実値には出所(コマンドと日付)を添え、添えられない値は未検証扱いにする
  • 寝かせた原稿は引用元の更新に取り残される。公開直前に引用元の現在の記述を再確認する
  • 検証者も古い記憶で断定する。指摘には原文の根拠を必須とし、記憶だけの指摘は修正に載せない
  • 分類の価値は網羅性ではなく、新しい失敗を既知の型の変種として言語化できる台座にある

本記事もパイプラインの出力であり、公開前に同じ検証を通ります。追補した3項目が本記事自身に効くかどうかが、次の運用報告の材料です。

参考文献

学術論文

  • Cheng, J., Marone, M., Weller, O., Lawrie, D., Khashabi, D., & Van Durme, B. (2024). Dated Data: Tracing Knowledge Cutoffs in Large Language Models. arXiv preprint. https://doi.org/10.48550/arXiv.2403.12958
  • Vu, T., Iyyer, M., Wang, X., Constant, N., Wei, J., Wei, J., Tar, C., Sung, Y.-H., Zhou, D., Le, Q., & Luong, T. (2023). FreshLLMs: Refreshing Large Language Models with Search Engine Augmentation. arXiv preprint. https://doi.org/10.48550/arXiv.2310.03214

公式ドキュメント

← Back to Blog