引用の誤帰属（Citation Misattribution）とは、引用文献自体は Web 上に実在し、書誌情報も正確であるにもかかわらず、本文の特定の主張と引用先の内容が食い違っている状態のことです。

AI エージェントに記事執筆やリサーチを委譲する現場では、ハルシネーション対策として品質ゲートの導入が進んでいます。出典の検証可能性を扱った前作 で解説したリンク切れ（404）やドメイントップ化の排除、さらには著者名・発行年・該当ページまで確かめる書誌メタデータの粒度検証は、AI 生成コンテンツの信頼性を支える不可欠な防壁です。

しかし、これらの検証ゲートをすべて最高スコアでパスした原稿の中に、深刻な引用エラーがそのまま潜り込んでいた事例がありました。

本記事では、URL や書誌の正しさを検証する「定義側のゲート」では原理的に検出できない誤りの層（誤帰属）が生じる仕組みを整理し、本文の主張と一次記録を突き合わせる独立した検証ゲートの設計と運用実測値を解説します。

「URLも生きていて書誌も正しい脚注」がすり抜けた日

発端となったのは、当リポジトリで過去に実施した、レガシーコード改善に関する技術記事の草案レビューでした。

その記事草案では、テストカバレッジの解釈について論じた段落で、Martin Fowler による「半分以下のカバレッジは問題の兆候である」という見解が引用されていました。ところが、その文の末尾に付いていた脚注を開くと、リンク先は Fowler の技術ブログではなく、Wikipedia の「Code coverage」の項目になっていました。

驚くべきことに、この原稿は公開前の自動レビュー工程をすべてクリアしていました。

  • 脚注の URL は 200 OK で正常に応答している（実在するリンク）
  • 著者名・タイトル・発行日などの書誌情報も正しい粒度で記載されている
  • 「1文献1脚注」などの構造ルールにも完全に適合している

なぜすり抜けてしまったのでしょうか。理由は単純で、既存の品質ゲートが 「脚注定義ブロックそのものの正しさ（定義側）」 しか見ていなかったからです。末尾の文献一覧にある Wikipedia の URL も書誌も実在する正しいデータであったため、定義側を検査するバリデータは満点の判定を下していました。

本文中の「どの文」に「どの脚注番号」が結びついているかという 対応関係（マッピング） を検査する目が存在しなかったため、全く別の主張に付いた誤帰属がそのまま素通りしてしまったのです。

出典検証の死角: 「定義の正しさ」と「対応の正しさ」の境界線

この問題の本質は、出典に関する検証には直交する 2 つの層が存在するという点にあります。

2層の引用検証アーキテクチャ。第1層の定義側検証（URL死活・書誌メタデータ）をすり抜けた誤帰属を、第2層の独立した検証器（Verifier）が本文クレームと逐語ログの突合により検出する構造

2 つの独立した検証層

  1. 第1層: 定義側の検証（出典自体の健全性） 引用文献が世の中に実在し、メタデータが正確かを検証します。近年提案された科学テキスト向けの引用検証フレームワーク（CiteCheck 等）1 がこの領域にあたります。これが保証するのは「引用しようとしている文献が実在するか」です。

  2. 第2層: 対応関係の検証（Claim-to-Source Mapping） 本文の 1 文 1 文が、紐づけられた参照文献の内容から論理的に導出（Entailment）できるかを検証します。自然言語生成における帰属基準（AIS: Attributable to Identified Sources）2 の領域です。これが保証するのは「その主張が本当にその文献に書かれているか」です。

どれほど第1層の検証を厳密に自動化しても、第2層の検証を組み込まない限り、誤帰属を止めることは原理的にできません。

なぜ LLM は執筆時に引用を取り違えるのか

LLM が長文を執筆する際、同一セクション内に複数の参考文献（例: Fowler の記事と Wikipedia）が存在すると、コンテキスト内での参照番号の取り違えが生じやすいと考えられます。

調査段階で正しい一次情報を取得していても、本文を生成して [^N] という参照記号を付与する瞬間に、直前・直後の文脈にある別の文献番号を割り当ててしまう現象です。

生成AI検索における引用精度の実態

この誤帰属は、特定のモデルに限った現象ではありません。大規模言語モデルを用いた生成AI検索（Bing Chat, Perplexity 等）の引用精度を人手で検証した研究（Liu et al., 2023）3 では、以下のデータが報告されています。

  • Citation Precision（引用適合率）: 平均 74.5% 生成された回答に付与された引用のうち、実際にその文の主張を正しく裏付けていたのは約 4 分の 3 にすぎず、25.5% は無関係または主張を支持しない誤帰属 でした。
  • Fully Supported（完全支持率）: 51.5% 生成された文全体が引用文献によって完全に支持されている割合は、半数程度にとどまりました。

インライン引用が整然と並んでいる文章は、人間にとっても AI にとっても信頼性が高く見えやすいという性質があります。しかし実際には、その 4 本に 1 本が「別の主張に付いた引用」であるという 信頼性の見せかけ（Facade of Trustworthiness） 3 の罠が存在します。

3 つの検証アプローチの比較

出典データの形式検証やプロンプト内での自己確認では誤帰属を防げず、独立した検証器による突き合わせが要ります。

アプローチ主な検証対象検出できる誤りすり抜ける誤り実行コスト
第1層: 出典側検証（URL死活 / 書誌粒度）脚注定義ブロック（URL, DOI, 著者）404 リンク切れ、架空の文献、メタデータ不備本文主張との食い違い（誤帰属）低（HTTPリクエスト / スクリプト走査）
自己検証（同一モデル内の自己レビュー）生成プロンプト内の回答と引用明らかな論理破綻執筆時と同一バイアスによる見落とし低〜中（追加プロンプト）
第2層: 独立 Verifier（クレーム突合）本文クレーム ↔ 逐語記録の突き合わせ誤帰属、根拠のない主張、脚注取り違え（逐語記録自体の欠落）中（独立サブエージェント / NLI）

出典側の検証（第1層）を終えた後、独立した検証器（第2層）で本文との対応関係を検査する「二段構え」のパイプライン設計が不可欠です。

解決策: 独立 Verifier による「クレーム ↔ 逐語記録」の突き合わせ

誤帰属を確実に検出するためには、どのようなアーキテクチャが必要でしょうか。

前提: 「情報源別の逐語ログ」とは何か

このゲートは、調査フェーズが残す逐語ログを正本として動きます。突き合わせる相手が無ければ、後述の委任プロンプトだけを真似しても検証は成立しません。移植する際に最初に用意すべきはこちらです。

当リポジトリでは、調査フェーズの成果物を次の 2 部構成で 1 ファイルに残しています。

  1. 情報源一覧: 通し番号・タイトル・URL・アクセス日・信頼度・実在確認（HTTP ステータス）の表
  2. 情報源別の抽出記録: 情報源ごとに、URL・記事のどのトピックに対応するか・原典から抽出した事実（逐語引用とその要約）を並べたブロック
### 情報源 2: Evaluating Verifiability in Generative Search Engines (Liu et al., 2023)
- **URL**: https://arxiv.org/abs/2304.09848
- **対応セクション**: トピック 2
- **抽出した事実・データ**:
  - Citation Precision（引用適合率）: 提供された引用が実際に関連付けられた文の主張を支持している割合は平均 74.5%

肝は 情報源ごとに区切られていること です。抽出した事実を 1 本のメモに混ぜて書くと「どの記述がどの文献由来か」が失われ、対応関係の突き合わせが原理的にできなくなります。

なぜコンテキスト分離が必要なのか

ここで分離しているのはモデルではなく コンテキスト です。当リポジトリの検証ゲートは執筆と同じモデルを使っており、違うのは「執筆時の文脈を一切持たない状態で起動する」という一点だけです。

執筆を行った同一セッション内で自己確認させる構成を採らなかったのは、執筆時のコンテキストウィンドウに残る文脈や推論過程に引きずられ、誤った紐付けを自分自身で正当化してしまう自己追認バイアスを避けるためです。同一セッションでの自己レビューとの検出率の差は対照実験で測っていないため、ここは実測ではなく設計上の判断です。

実際に組み込んだのは、執筆コンテキストを持たない 独立した検証器（Verifier サブエージェント） を起動し、「本文の各文（仮説）」 と 「調査フェーズで記録した情報源別の逐語ログ（前提）」 だけを突き合わせる単機能の検証タスクを委任する構成です。突き合わせの発想そのもの（主張をクレーム単位へ分解し、引用元テキストから含意されるかを判定する）は、生成テキストの引用評価で確立している手法です45。

照合ゲートの設計仕様

当リポジトリのパイプラインでは、レビュー工程に以下の委任プロンプトを持つ独立検証ゲートを組み込みました。

執筆原稿（本文）中の 全ての [^N] 参照について、その文が述べている主張が、参照先の脚注の文献に由来するかを調査記録の情報源別逐語ログと突き合わせてください。逐語をそのまま引いた箇所だけでなく、要約・翻訳・言い換えた文も対象です。不一致だけ を「本文の行番号 / 該当文 / 付いている脚注の文献 / 調査記録上で実際にその主張を記録している情報源（無ければ『該当なし』）」の形で列挙し、一致しているものは列挙しないでください。原稿は書き換えないでください。

誤帰属が検出されたときの運用分岐

不一致が報告された場合、パイプラインの運用は以下の 2 つに分岐します。

  1. パスA（現地修正）: 正しい文献が調査記録に存在する場合 単なる番号の割り当てミスであるため、正しい文献への [^N] 付け替えと、本文初出順の再採番を行って即座に修正を完了します。
  2. パスB（差し戻し）: 調査記録のどこにも主張の根拠がない場合 これは引用の付け間違いではなく、「主張自体に裏付けがない創作（ハルシネーション）」 です。出典の差し替えでは解決できないため、品質ゲートを停止して執筆工程へ差し戻します。

運用コストと実効性: 全脚注突き合わせは実用に耐えるか

全脚注を対象とした独立突き合わせゲートの導入で問題になるのは、実行コストと検出の実効性です。

当リポジトリにおいて、13 箇所の脚注参照を持つ記事草案を対象に空撃ち（本番投入前の試験実行）で検証したときの実測値は以下のとおりです。

  • トークン消費: 53,885 トークン
  • 所要時間: 約 73 秒
  • ツール使用回数: 3 回
  • 誤検出（偽陽性）: 0 件

実際の検出実績

この検証では、テスト用に意図して仕込んだ 1 件の欠陥（Fowler の記述に Wikipedia 脚注を付けたもの）を正確に検出しただけでなく、過去の初回レビューを通過してしまっていた 実際の誤帰属 4 件 を追加検出しました。

  • 行 22: 特性テストの「許可リスト／禁止リストの対比」に Fowler の脚注が付いていたが、調査記録上は Wikipedia の Characterization test 由来であった
  • 行 24: 入出力例 f(3.14) == 42 と人間判断に関する記述に Google Testing Blog の脚注が付いていたが、正しくは上記 Wikipedia 由来であった
  • 行 85: テスト用ポートの自動起動・停止に関する記述に公式ドキュメント（POD）の脚注が付いていたが、正しくは公式ガイド（Guides::Testing）由来であった
  • 行 144: 「HTML レポートで色分け表示される」という記述について、調査記録全体に該当する根拠が存在しなかった（パスBの差し戻し対象）

1 記事の執筆に数十万トークンを要する現代の自動化パイプラインにおいて、約 5 万トークン・1 分強の独立検証を追加することは、公開後の信頼性リスクや人間の再レビュー負担を減らす、費用対効果の高い投資と言えます。

よくある質問（FAQ）

Q1: URL実在チェックや書誌情報の確認だけではなぜ誤帰属を防げないのですか？

A1: URL 疎通や書誌メタデータの検証は「文献データそのものが実在するか」という定義側しか見ておらず、本文中のどの文にどの脚注番号が付いているかという「対応関係」は検査スコープ外だからです。

Q2: 執筆エージェント自身に「主張と引用が一致しているか」をチェックさせるのでは不十分ですか？

A2: 不十分です。同一モデル・同一セッション内で自己チェックさせると、生成時の文脈バイアスにより自分の誤りを追認しやすいため、執筆コンテキストから完全に切り離した独立サブエージェントに「文 ↔ 逐語記録」を突き合わせる必要があります。

まとめ: 自社のレビューフローに主張対応ゲートを 1 本足す

AI エージェントによる執筆や調査を実用化する鍵は、作業プロセスを以下の 3 段階に分離することです。

  1. 調査フェーズ: 出典の URL や書誌を確認し、情報源別の逐語記録（正本） を残す
  2. 執筆フェーズ: 逐語記録を基に本文を構成し、適切な位置に引用番号を付与する
  3. 検証フェーズ: 執筆とは別の独立した Verifier が、本文のクレームと逐語記録の対応を全件突き合わせる

出典の検証を出典側（URL や書誌）だけで完結させず、本文の主張との結びつきまで確かめる検証ゲートを 1 本追加すること。これこそが、生成AIの「もっともらしさ」に惑わされず、真に検証可能な技術コンテンツを継続的に届けるための境界線となります。

AI エージェントを活用した業務自動化や、生成コンテンツの品質保証パイプラインの設計・運用に関するご相談は、コンタクトフォーム よりお気軽にお問い合わせください。

Footnotes

  1. CiteCheck: Retrieval-Grounded Detection of LLM Citation Hallucinations in Scientific Text Khashayar Khajavi, Shaghayegh Sadeghi, Rise Adhikari, Alexander Tessier. arXiv:2605.27700, 2026. 科学文献における書誌実在性・メタデータ整合性の検証フレームワーク。 ↩

  2. Measuring Attribution in Natural Language Generation Models Hannah Rashkin, Vitaly Nikolaev, Matthew Lamm, Lora Aroyo, Michael Collins, Dipanjan Das, Slav Petrov, Gaurav Singh Tomar, Izhak Shafran, David Reitter. Computational Linguistics 2023. arXiv:2112.12870. AIS（Attributable to Identified Sources）の定義、Faithfulness と Attribution の区別。 ↩

  3. Evaluating Verifiability in Generative Search Engines Nelson F. Liu, Tianyi Zhang, Percy Liang. Findings of EMNLP 2023, pp. 7001–7025. arXiv:2304.09848. Citation Precision 74.5%、Fully Supported 51.5% の実測値、Facade of Trustworthiness の指摘は pp. 7001–7004, Table 1。 ↩ ↩2

  4. Enabling Large Language Models to Generate Text with Citations Tianyu Gao, Howard Yen, Jiatong Yu, Danqi Chen. Proceedings of EMNLP 2023, pp. 6465–6488. arXiv:2305.14627. ALCE ベンチマーク、AutoAIS によるクレーム単位の含意（NLI）評価手法は pp. 6465–6468。 ↩

  5. Automatic Evaluation of Attribution by Large Language Models Xiang Yue, Boshi Wang, Ziyi Yang, Huan Sun, Yu Su. Findings of EMNLP 2023, pp. 4615–4635. arXiv:2305.06311. サブクレーム分解と LLM/NLI による帰属関係自動評価手法は Section 3–4。 ↩