AIエージェントやLLMを活用して記事執筆やドキュメント作成、コード生成を自動化する取り組みが進む中で、AIが「実施していない検証」を「macOS Sequoia 15.3 / Python 3.12.3 / Claude 3.7 Sonnet」のように具体的なバージョン番号付きで創作してしまう事態が発生しています。

「AIの出力にはファクトチェックが必要である」という一般的な心構えは広く知られるようになりましたが、AIが形式的に極めて整った、実在するOSやランタイムのバージョン番号を並べ立てた場合、目視のレビューだけでその捏造を見抜くことは容易ではありません。

LLMのハルシネーションには、入力コンテキストに忠実でない「Faithfulness Hallucination」と、客観的事実と一致しない「Factuality Hallucination」があります。いずれの型でも、モデルは知識不足やコンテキストの欠落に直面した際、確率的トークンサンプリングの補完作用によって、実在しないバージョン番号や架空の条文番号などを「もっともらしい具体性」を伴って生成・捏造してしまいます1。

本記事では、自社のAI執筆パイプラインで実際に発生した捏造と品質ゲートすり抜けの失敗事例を解剖します。なぜ「捏造禁止ルール」が存在しながらすり抜けてしまったのかという構造的原因を明らかにし、AIを答えに窮させずに確実に捕捉する品質ゲート設計の4原則を解説します。

AIパイプラインで起きた「もっともらしい捏造」の実例解剖

自社で運用しているブログ執筆パイプラインにおいて、AIエージェントが生成した記事草案が最終レビュー段階で差し戻し・中断（abort）となるトラブルが発生しました。問題となったのは、AIによる極めて精緻な「未実施検証の環境スペック創作」と「架空の条文番号の引用」でした。

検証していない環境スペックを創作した事例

ある調査・比較型の記事企画において、上流の企画書では「一次情報: なし（実機検証を伴わない公開仕様の調査企画）」と明確に定義されていました。

しかし、次の詳細設計ステップを担当したAIエージェントは、以下のような検証環境スペックを突如として書き加えました。

  • OS: macOS Sequoia 15.3 (Apple Silicon) / Ubuntu 24.04 LTS (CI Runner)
  • ランタイム: Node.js v22.14.0 / Python 3.12.3
  • ツール: git 2.48.1 / ripgrep 14.1.0 / pre-commit 3.7.1
  • 対象モデル: Claude 3.7 Sonnet / Claude Code v0.2.29

そして本文の冒頭に「本記事における調査および動作検証は、以下の環境で実施しました」という明確な実施宣言を記述したのです。

実際には実機での動作検証は1行も行われていませんでした。それにもかかわらず、AIは執筆時点における最新かつ整合性の取れた環境スペックを創作し、あたかも自ら実測したかのように振る舞いました。

存在しない条文番号を自信満々に引用した事例

さらに同じ記事草案において、AIエージェントは外部の公式発表を引用する際、「EU AI Act 第50条が定める透明性義務に準拠し、2026年8月2日以降にリリースされたモデル群に電子透かしを導入する」と記述しました。

しかし、引用元として提示された公式発表ページを実際に取得して確認したところ、「Article 50」という条文番号はページ内のどこにも存在しませんでした。また「2026年8月2日」という日付も、EU側の法規制の発効日に関する一般的な説明であり、モデル自体のリリース基準日ではありませんでした。AIは、外部の法規制情報と公式発表の文脈を混同し、存在しない条文番号を自信満々にでっち上げていたのです。

研究データに見る「バージョン番号捏造」の頻度

こうした「バージョン番号やパッケージ名の捏造」は、単なる偶発的なミスではありません。

USENIX Security 2025で発表された Spracklen らの研究（arXiv:2501.19012）によると、コード生成モデルが実在しないパッケージ名やバージョン番号を捏造する現象（Package Hallucination / Slopsquatting）は、商用モデルでも約 5.2%、オープンソースモデルでは最大 21.7% の頻度で発生することが確認されています2。

AIが生成するバージョン番号やライブラリ名は、命名規則や文脈に完璧に適合しているため、人間のレビュアーが「本当にそのバージョンで動かしたのか」を疑わずに素通りさせてしまう危険性を孕んでいます。

なぜ防げなかったのか：ルールはあったのに「トリガー」が漏れていた構造

今回の失敗において最も重要な教訓は、「品質ルールが存在しなかったからすり抜けた」のではないという点です。

「捏造禁止ルール」は既に存在していた

自社のパイプラインには、過去の知見に基づき「一次情報の捏造禁止（設計や調査資料に根拠のない体験談や実施事実を執筆時に創作してはならない）」という厳格なルールがあらかじめ定義されていました。

また、設計段階で事実関係を精査する事前検証ゲートも組み込まれていました。それにもかかわらず、なぜこの捏造は最終レビューの直前まで見逃されてしまったのでしょうか。

落とし穴：ルールの適用スコープが狭すぎた

原因は、ルールの「適用条件（トリガー）」の設計ミスにありました。

当時定義されていた捏造禁止ルールは、新機能の速報記事で根拠のない体験談が混入した過去の事例を契機に策定されたため、その発火条件が「外部の製品発表・仕様変更を主題とする記事」に限定されていました。

今回起票された記事は「調査・比較型」という別のカテゴリであったため、レビュー機構はこのルールのチェック対象外と判定し、ゲートを発火させずに素通りさせてしまったのです。

ルールの存在と実効性は別問題である

どれほど完璧なルールやチェックリストを作成していても、その適用範囲に「特定の条件でのみ発火する例外」を残していると、AIエージェントの自律的な処理プロセスにおいて致命的な死角が生まれます。

ルールが「定義されていること」と、それがパイプライン内で「確実に実行（トリガー）されること」は全く別の問題です。

比較：プロンプト制約 vs 決定論的品質ゲート

AIのハルシネーション対策は、プロンプトへの制約指示（お願い）に依存する段階から、パイプライン側で機械的に検証・遮断する決定論的ゲートへと根本的に移行する必要があります。

比較項目プロンプト制約（プロンプトでの禁止）決定論的品質ゲート（外部テスト・強制検証）
制御の仕組みシステムプロンプトで「嘘をつくな」「検証環境を捏造するな」と指示スキーマ検証、独立サブエージェント照合、CIテストによる自動合否判定
実行の確実性確率的（モデルの推論コンテキストや過信によりすり抜けが発生）決定論的（コードやルールが満たされない限りパイプラインをブロック）
例外・死角の発生複雑な指示になるほど条件の解釈揺れが発生しやすい条件の有無を機械的に検証し、全件一律に適用可能
代表的なツール・実装プロンプトエンジニアリング、システムメッセージGuardrails AI、DeepEval、Ragas、CI/CD自動テスト

プロンプトによる指示はモデルの表現力をガイドする役割に留め、事実性の担保やルールの遵守は外部の品質ゲートが強制するアーキテクチャが不可欠です。

教訓と対策：AIを答えに窮させず、ゲートをすり抜けさせない4原則

自社パイプラインの失敗から得られた、AI生成物の品質管理における4つの設計原則を整理します。

原則1：条件付きルールを排し、全件強制のデフォルト適用にする

「速報記事のときだけ捏造をチェックする」「調査記事のときだけ出典を確かめる」といった条件分岐を廃止します。すべての生成物に対して、記事の型やタグに関わらず、一次情報の裏付け・引用元の整合性を一律で検証するデフォルト強制のパイプラインを構築します。

原則2：主張の出自を強制的にタグ付け・追跡する

企画・調査・設計の各段階において、記述が「検証済みの一次情報」なのか、「調査結果」なのか、「意見・推測」なのかを出自タグによって機械的に分離・追跡します。

上流で「一次情報: なし」とマークされている企画において、下流で検証環境スペックのような一次情報が書き込まれた場合、差分検知で即座にビルドエラーとする仕組みを整えます。

原則3：独立した検証サブエージェントと決定論的テストを組み合わせる

生成を行ったエージェント自身にレビューをさせると、自己評価バイアスによって自らの捏造を肯定してしまいます。

執筆を担当したエージェントとは別の「独立した検証サブエージェント」を配置し、本文の主張と引用文献・ログの逐語照合を担当させます。さらに、DeepEval（HallucinationMetric）3 や Ragas（Faithfulness）4 を活用し、CIパイプライン上でスコア閾値による自動デプロイブロックを導入します。

原則4：答えがない時は「なし」でよいフォールバックを設計する

ハルシネーションは、AIが知識不足やコンテキストの欠落によって「答えに窮した時」に、確率的にもっともらしい形式で空白を埋めようとする現象です。

RGBベンチマーク（Chenら）でも示されている通り、LLMは「情報が存在しない場合に回答を拒絶する能力（Negative Rejection）」に本質的な弱点を抱えています5。

そのため、プロンプトやパイプラインのインターフェース設計において、「情報がない場合は『未検証』『該当なし』と出力してよい」「無理に数値を埋めるな」という明確なフォールバックの逃げ道を用意し、AIが答えに窮する状況そのものを作らない設計が極めて有効です。

コード例：Guardrails AI による出力検証ゲートの実装

プロンプト指示に依存せず、コードレベルで出力のファクトチェックを行う決定論的ゲートの実装例です。Guardrails AI 6 を使用して、生成テキストが事前に確認されたコンテキストに基づいているかを検証します。

1. 検証ゲートの実装コード

Guardrails AI 本体と ProvenanceV1 バリデータをインストールします。

pip install guardrails-ai
guardrails hub install hub://guardrails/provenance_llm

以下のスクリプトは、生成テキストに含まれる文章が正解コンテキストに裏付けられているかを文単位で検証し、未検証の主張が含まれている場合に例外をスローして処理を中断します。

# ファイル: scripts/verify_hallucination_guard.py
"""Guardrails AI を用いて出力のファクトチェックと未検証主張の遮断を行う品質ゲート."""

from guardrails import Guard
from guardrails.hub import ProvenanceV1

# 正解コンテキスト（企画書や調査フェーズで確認済みの事実）
verified_context = """
企画書: 不可視文字のサニタイズ設計
一次情報: なし（実機での動作検証は行わない）
調査対象: 公式ドキュメントの電子透かし仕様
"""

# 出力に対するファクトチェック Guard を定義
# 根拠のない主張が含まれている場合は即座に例外を発生させる
guard = Guard().use(
    ProvenanceV1(
        validation_method="sentence",
        llm_callable="gpt-4o-mini",
        threshold=0.8,
        on_fail="exception"
    ),
    on="output"
)

# AIエージェントが生成したテキスト（捏造が含まれる例）
unverified_output = """
本記事における動作検証は macOS Sequoia 15.3 および Node.js v22.14.0 で実施しました。
"""

try:
    print("品質ゲートの検証を実行中...")
    guard.validate(
        unverified_output,
        metadata={"pass_on_invalid": False, "reference_context": verified_context}
    )
    print("検証成功: すべての主張がコンテキストに裏付けられています。")
except Exception as e:
    print(f"品質ゲートで遮断されました (Validation Failed):\n{e}")

2. 実行結果と出力ログ

python scripts/verify_hallucination_guard.py

未検証の環境スペックを含むテキストに対して上記スクリプトを実行すると、以下のようにゲートが即座に違反を検知して例外を出力します。

品質ゲートの検証を実行中...
品質ゲートで遮断されました (Validation Failed):
Validation failed for field with errors: The following sentences are not supported by the context:
- 本記事における動作検証は macOS Sequoia 15.3 および Node.js v22.14.0 で実施しました。

3. 重要箇所の解説

  • ProvenanceV1 の活用: 各文が reference_context に含まれる根拠に裏付けられているかを個別にスコアリングします。
  • on_fail="exception" の設定: 閾値を下回った（未検証の主張が含まれる）場合、警告で済ませずに例外を発生させてパイプラインの進行を即座にブロックします。
  • プロンプト非依存の保証: LLMの出力結果を後段のテストステップで決定論的に検査するため、モデルの気まぐれによるすり抜けを防止できます。

FAQ：AIパイプラインの品質ゲート設計に関するよくある疑問

プロンプトで「嘘をつくな」「確信がない場合は答えるな」と強く念押しすれば防げるのではないか？

防げません。

LLMは確率的に次トークンをサンプリングする構造上、コンテキストが欠落している場合でも統計的にもっともらしい形式（バージョン番号や条文番号）で空白を埋めようとする性質（Overconfidence）があります1。プロンプトへの指示は確率の偏向に過ぎず、100%の遵守を保証できないため、コードやCIによる決定論的な外部テストが必要です。

すべてのルールを全件強制にすると、パイプラインの自動化効率や開発テンポが落ちないか？

短期的には差し戻しが増えるように見えますが、長期的な総コストは大幅に削減されます。

事後的に本番公開直前や公開後に捏造が発覚して記事やコードを破棄・修正する手戻りコストに比べ、パイプラインの初期段階（設計やCI）で機械的に弾く方が手戻り工数は遥かに小さく抑えられます。

まとめ

本記事で解説したAI品質ゲート設計の要点は以下の通りです。

  1. AIは「やっていない検証」を具体的すぎるバージョン番号付きで捏造する: 知識や実測データが欠落している時ほど、形式的に完璧な嘘をつく傾向があります。
  2. ルールの存在と実効性は別物である: 「特定の条件のみで適用する」というルールは、自律パイプラインにおいて致命的なすり抜けの穴になります。
  3. プロンプト制約に頼らず、決定論的外部ゲートを構築する: ルールは全件強制とし、独立サブエージェントやCIテストで機械的に合否判定を行います。
  4. AIを答えに窮させないフォールバックを用意する: 「情報がない時はなしでOK」という逃げ道を設計に組み込むことで、ハルシネーションの根本原因を断ちます。

AI Operations の導入設計、AIエージェントを活用した安全な自動化パイプラインの構築や品質ゲートの再設計について、ぜひ コンタクトフォーム よりお気軽にご相談ください。

Footnotes

  1. A Survey on Hallucination in Large Language Models Lei Huang et al., arXiv:2311.05232, 2023年11月公開。LLMのハルシネーション分類（Factuality/Faithfulness）および次トークン補完における過信（Overconfidence）のメカニズム解説。 ↩ ↩2

  2. Importing Phantoms: Measuring LLM Package Hallucination Vulnerabilities Spracklen et al., USENIX Security 2025 / arXiv:2501.19012, 2025年1月公開。コード生成モデルにおけるパッケージ・バージョン捏造率（商用モデル約5.2%、OSS最大21.7%）の実測データは pp.1-4。 ↩

  3. DeepEval Hallucination Metric Documentation Confident AI, 公式ドキュメント, 2026年確認。CI/CDパイプラインにおけるハルシネーション定量評価メトリクスおよび合否判定の仕組み。 ↩

  4. Ragas Framework Exploding Gradients, GitHub リポジトリ, 2026年確認。LLM生成パイプラインにおけるFaithfulness評価とGitHub Actions自動テスト統合。 ↩

  5. Benchmarking Large Language Models in Retrieval-Augmented Generation Jiawei Chen et al., arXiv:2309.01431, 2023年9月公開。LLMにおけるNegative Rejection（情報欠落時の回答拒絶）の弱点とフォールバック設計の検証データは pp.3-6。 ↩

  6. Guardrails AI Framework Guardrails AI, GitHub リポジトリ（v0.5系）, 2026年確認。プロンプト指示に依存しない決定論的バリデータ（Guard, on_fail）の設計・コード例。 ↩