blog

開発メモ

AIが付けた出典URL、開いたら中身は別の話だった——Claude Codeのエージェントに反証させて15件発見

AIが付けた出典URLは実在するのに中身が別の事例にすり替わっていたことを示す図

受託案件のひとつで、AIエージェントの活用事例を集めて資料にする仕事がありました。並列で走らせた15体のエージェントに「数字・事例には必ず出典URLを付けろ」「出典が確認できない数字は書くな」と指示し、出てきた資料は一見申し分ありませんでした。出典URLが整然と並び、数字も具体的です。

ですが、資料を人前に出す前にもう一段検証を挟んだところ、出典URLは実在するのに、開いてもその数字がどこにも書かれていない引用が大量に見つかりました。

先に結論から

AIに「出典URLを付けろ」と指示しても、担保されるのはURLが実在することだけです。そのページの中身が主張と合っているかは、まったく別の問題でした。同じ轍を避ける勘どころは、次の4つに尽きます。

  1. 「出典URLを付けろ」ではなく「原文を一文そのまま引用させろ」。本文を開かないと埋められない形式にすると、捏造の余地が消える。
  2. 検証は「確認して」ではなく「反証しろ・誤りを見つけろ」と、役割を反対向きに与える。同意しがちな確認より、あら探しのほうが実際にページを開きに行く。
  3. 崩れやすいのは「企業名×効果の数字」。公的統計(総務省・帝国データバンク等)は正確に当たりやすいので、検証の手間は前者へ集中する。
  4. 件数が減っても、中身の違う引用を1件残すほうが損失が大きい。裏の取れない事例は落とす。

以下、なぜ「URLは本物なのに中身が別物」という状態が生まれるのか、実際に見つかった例から追っていきます。

URLは本物なのに、中身が別の事例だった

一番わかりやすかった例が、これです。最初の資料にはこう書かれていました。

記載:従業員30名のサービス業/作業時間 50分 → 10分
出典:(実在するURL)

そのURLを実際に開いて原文を確認すると、書かれていたのはこうでした。

原文:従業員28名の製造業A社/1本2.5時間 → 25分/月約27時間・月3,000円

業種・人数・時間、すべてが食い違っています。リンク切れならまだ気づけますが、URL自体は元記事に実在する別の事例のページで、そこに書かれている数字だけが資料の主張とすり替わっていました。この形の引用が、企業の実名事例パートだけで9件、Q&A用の資料で3件、需要予測の資料で3件、合計15件見つかりました。

なぜ起きたか——「出典URLを付けろ」はURLの実在しか保証しない

検索結果のスニペットには「それらしい数字」と「それらしいドメイン」が並びます。エージェントが本文を開かずにこの2つを接合すると、この状態ができあがります。URL自体は検索結果から取ってきた実在ページなので、リンク切れにもならず、URLの存在チェックだけでは気づけません。

興味深かったのは、崩れ方に偏りがあったことです。総務省・帝国データバンク・商工中金・中小機構といった公的統計は、ほぼ全て正確でした。公的統計は数字とページが1対1で結びつくので当たりやすいのだと思います。崩れていたのは、決まって「企業名×効果の数字」の組み合わせ——まとめ記事やSEO記事に何度も転載されて、出所が曖昧になっている領域でした。この偏りが分かってからは、検証の手間をそこに集中投下できるようになりました。

収集役15体の成果物出典URLは整然、数字も具体的=一見して完璧に見える検証役5体が反証者としてURLを実際にWebFetchで開き直す立場=「誤りを見つけて恥を防げ」✗ 出典15件がURLは本物・中身は別事例公的統計は正確/企業名×数字だけ崩れる対処:原文引用を必須フィールドに本文を開かないと埋められない形式に変更✓ 再収集:規模・数字・出典が揃った事例に

効いたのは「URLを付けろ」ではなく「原文を一文引用させろ」

再収集のワークフローでは、出力フォーマット自体を変えました。ポイントは、事例1件ごとの記載項目に「原文引用」を必須で入れたことです。

記載フォーマット:何をしたか / 効果 / 原文引用(一次資料の該当箇所を一字一句そのまま) / 出典URL / 確認日
// 「原文引用できない事例は採用しない」「見つからなければ”見つからなかった”と書く」も明記

「出典URLを付けろ」は、リンクさえ貼れば形式的に満たせてしまいます。ですが「本文中のこの一文を、原文のまま引用しろ」と要求すると、本文を実際に開かない限り埋められません。捏造の余地が構造的に消えるので、これが一番効きました。

もうひとつ効いたのが、検証エージェントへの指示の立て方です。同じ「確認して」でも、頼み方でエージェントの動き方が変わりました。

「この事例の出典を確認してください」
→ 同意しがちで、開かずに”確認済み”と返すことがある
「出典URLをWebFetchで実際に開き、主張が本当にそのページに書かれているか反証してください」
→ 「誤りを見つける」役割を与えると、本当に開きに行く

反証者として立てた5体は、所見を棄却しただけでなく「403で開けなかった」「企業名が非公開だった」「記事が別の会社の話だった」と、不採用にした理由まで自発的に書いてくるという副次効果もありました。取り直した後の資料は、規模・数字・出典URLの原文引用が全部揃った、実際に人前で使える内容に置き換わりました。

件数が減っても、中身の違う引用は残さない

ここでの判断は「件数が減っても、1件でも中身の違う引用が混じるほうが損失が大きい」という一点に尽きます。人前に出す資料は、聴衆が1件の誤りを見つけただけで資料全体を疑います。9件を落とせば事例が薄くなるという迷いより、崩れた引用を残すリスクのほうを重く見て、全部を洗い直す方を選びました。

もう一つの軸は、「出典URLが付いている」という見た目の完成度に安心しないことです。整った形式は、中身の正しさを保証しません。件数を積み増すより、1件ずつ本文を開いて裏を取れる仕組みに時間をかけるほうが、結果的に資料の信頼性を守ります。

URLが実在することと、中身が合っていることは別物

「出典URLを付けろ」という指示は、URLの実在性しか担保しませんでした。中身が本物の主張と一致しているかは別の話で、そこを確かめるには「原文を引用させる」という、開かないと埋められない形式に落とし込む必要があります。人前に出す資料や、顧客に渡す成果物でAIエージェントに事例収集をさせるときは、この一段を挟む価値があると感じています。

複数のエージェントに調査・監査を任せるときに踏んだ別の地雷は、完了報告を信じたら本番には何も反映されていなかった話にも書きました。並列実行そのものの設計面でハマった話は、別の記事でまとめています。ここまでに踏んだものを一通り整理したClaude Code実務運用ガイドもあわせてどうぞ。

制作体制:一次体験・方針判断・最終確認は筆者が担い、構成・執筆・事実照合はAI(Claude)との協働です。
※本記事の内容は2026年8月時点のものです。

Web制作・改善のご相談は、
初回無料で承っています。

無料で相談する

いきなり相談はちょっと、という方へ

まずは無料で費用感を見積もる

オンライン・お電話・対面(福井近郊)対応/無理な勧誘はいたしません