偽の数字を見つけたのは、「確認しましたか?」の一問と手元のPDFだった
ディープリサーチは、AIに論文やウェブを集めさせて、レポートにまとめさせるやり方。標準のやり方では、1つのAIが作業を分けて、別のAIたちに任せる。速いし、出てくるものは立派に見える。でも僕は、その中身をあまり信じていなかった。
前に、AIがまとめた文献調査を、コーディングしてくれているClaude Code（以降Code）に、原典と1件ずつ突き合わせてもらったことがある。柱になる主張10件のうち、4件が間違っていた。他の調べものでも、似た感触があった。だから仮説はこうなった。AI任せのディープリサーチは、40%が嘘。だからもう詰んでる。半分ジョーク、半分本音。
それと並行して、リサーチの手順をCodeと一緒に作っていた。手順は軽い方と重い方の2つ。軽い方のQuick Flowは5ステップで、どこを調べればいいか当たりをつけるためのもの。確かめるステップは無い。重い方のReport Flowは10ステップで、重要な主張は全部、一次資料（論文の原文や公式の発表）で確かめる。Report Flowを最後まで飛ばさずに通すのは、今回が初めてだった。
その初回のテーマを、ディープリサーチの信頼性そのものにした。ディープリサーチを疑うレポートを、ディープリサーチの手順で作る。
ドラフトには、「AIのリサーチは4割が嘘」に合う論文の数字が揃っていた
Report Flowの最初のステップでは、仮説を僕の言葉のまま書き出す。Codeが自分の言葉でまとめ直すと、少しずつ問いがずれていくから。
書き出してみると、自分では一つの問いのつもりだったのに、主張が2つ入っていた。嘘の割合は本当に40%くらいなのか（主張A）。その原因はサブエージェント（Codeが作業を分けて任せる、別のAI）なのか（主張B）。サブエージェントは、冒頭で書いた、作業を任される別のAIたちのこと。進め方は、仮説を支える証拠を集めるのではなく、崩す証拠を積極的に探す方にした。仮説を立てた本人は、どうしても自分に都合のいい証拠を集めたくなるから。
Codeがサブエージェントに候補を集めさせて、使う資料を11本に絞った。その中の一本、DeepHalluBenchという論文だけは、CodeがPDFをダウンロードして手元に置いていた。
Codeがまとめたドラフトには、文献が40%近くを裏付けている、と読める文が入っていた。根拠は、DeepHalluBenchの数字として書かれた、嘘の主張の割合「23–38%」と、この論文が使っているという「PIES」という、誤りの種類の分類の名前。数字は揃っている。論文名も並んでいる。一見、筋が通っていた。
別のAIに「確認しましたか?」と聞かれて手元のPDFを開いたら、その数字はどこにも無かった
Report Flowの9ステップ目は、レッドチーム（あえて反論役をさせて、弱いところを探す検証）。ドラフトを書いたCode自身に審査させると、自分の結論をかばいたくなる癖が抜けない。だから、このやり取りを知らない別のClaudeにドラフトを渡して、その役をさせる。
レッドチームから来た問いの中に、これがあった。
レッドチーム「DeepHalluBenchの『嘘の主張23–38%』と『PIESという分類』は確認しましたか?」
Codeは確認していなかった。PDFは手元にあって、中の表も直接読んでいたのに、ドラフトに使ったのは、ウェブの論文ページを読み込ませた結果（ページの中身は、小さいモデルが要約して返してくる）と、サブエージェントの読み取りの方だった。
Codeが手元のPDFの表（Table 2）を開き直した。分類の名前はPING。PIESじゃない。載っていたのは、この論文が独自に決めた、誤りの多さを表す点数（0.15–0.21）で、そもそもパーセントですらない。23–38%という数字は、この論文のどこにも無かった。
Codeの見立てでは、ウェブページの要約やサブエージェントが論文を読んだ時、関連論文の引用や要旨のまわりの文を混ぜて、「PIES」と「23–38%」を作ってしまった可能性が高い。本物の論文に、存在しない数字が、きちんとした体裁で付いていた。
このレポートが調べていたのは、確かめていない読み取りが、確かめた資料のような顔をして混ざる問題だった。作った手順を初めて自分で最後まで使ってみたら（開発の世界でいう「自分のドッグフードを食べる」。自分で作ったものを、まず自分で使ってみること）、その問題がレポート自身の中で起きた。
4割が多いか少ないかは、何を分母にするかで変わる
偽物の数字を外して直していくと、それが見えてきた。
| 何を測ったか | 割合 |
|---|---|
| 存在しないURLを出す割合（Raoらの研究） | 3.5–13.3% |
| 引用が主張を支えていない割合（ディープリサーチの評価用の問題集、DeepResearch Bench） | 10–22% |
| 柱になる主張のうち、原典と合わない割合 | 約40%（僕の前回の照合。10件中4件） |
3.5%と40%は矛盾しない。測っているものが違う。僕の40%は、柱になる主張そのものが原典と合っているかを見た、一番厳しい物差しの数字。今回集めた文献の中に、この物差しで測った研究は無かった。文献は40%を確認も否定もしない。論文が40%を裏付けてくれた、というドラフトの書き方は間違いだった。
もう一つの主張B（原因はサブエージェントか）も、言い過ぎをレッドチームに指摘されて削った。言えるのはここまで。サブエージェントに投げて、返ってきた結果をそのまま信じる作りだと、原典からずれやすくなる。Claudeを作っているAnthropic自身も、公式の説明でこれを「telephone game（伝言ゲーム）」と呼んでいる。逆に、複数のAIに議論させて互いに確かめさせる作りだと良くなる。議論させる作りの方は、Duらの研究で実際に成績が上がっていた。じゃあ、使うAIの数を減らせば良くなるのか。AIの数だけを変えて比べた研究は無かった。だから、サブエージェントが原因とまでは言えない。言えるのは、問題はサブエージェントそのものではなく、サブエージェントへの丸投げの方、まで。
さっきの偽の数字も、入口はそこだった。サブエージェントとウェブページの要約を、確かめずにそのまま使った。
正直に言える数字は1つだけで、調べる場所の目安にはなっても、引用はできない
レポートができてから、数字についてCodeにもう少し突っ込んで聞いた。Codeの説明には、URLの3.5–13.3%と引用の10–22%を足した、13–35%という数字が出ていた。それは足していいのか、と聞くと、Codeは誤りだと認めた。分母も定義も違う数字を足すと、同じ誤りを二重に数えることになる。じゃあ平均は、と聞くと、平均はもっとまずい、という答えだった。測っている物が違う数字を平均しても、何の割合でもない数字が出てくるだけだから。正直に1つの数字として言えるのは、引用が主張を支えていない割合の10–22%だけだった。
引用のおよそ10本に1〜2本が、書かれた主張を支えていない。この数字をどう見ればいいのか、Codeに聞いた。その時、忖度は要らない、気分良くなりたくて聞いてるんじゃない、とも言った。Codeの答えは「悪い」。引用してそのまま人に出す用途には不合格。でも、どこを掘ればいいか当たりをつける地図としてなら合格。
効いたのは、別のAIが審査したことより、PDFを確かめさせたことだった
なぜ今回は見つけられたのか。後でCodeが、この一件を振り返った。Codeの見方はこうだった。
レッドチームが効いたのは、別のClaudeが審査したからじゃない。別のClaudeが、実際のPDFを確かめたかと聞いたからだった。もしレッドチームがドラフトだけ読んで通していたら、レッドチームもドラフトの偽の数字を見て「確かにそう書いてある」と思うだけで、PIESはそのまま通っていただろう。Codeはこれを一言で、検証役は、元の資料に当たれる分しか強くならない、と言った。
軽い方の手順にも、元の資料に当たるステップを足した
Report Flowは重い。毎日の判断に使うには向かない。一方で、軽いQuick Flowは確かめるステップが無いので、大事な数字が捏造のまま通ってしまう。
そこで僕から、Quick Flowにレッドチームを足して、Report Flowを軽くしたような中間の手順を作ろう、と提案した。名前はQuick+。形にしてみると、足したのは反論役そのものより、確かめるステップの方だった。
変えたのは1点。途中に、検証のステップを1つ足した。全部の主張を確かめるとReport Flowと変わらなくなるし、何も確かめないと、どこを信じていいか分からないまま。だから、具体的な数字、引用、判断の根拠になる主張、つまり結論を支える主張だけを一次資料と突き合わせる。さっきの、地図としては合格、引用には不合格、の線引きをそのまま手順にした形。
一番大事なルールとして、Codeが手順書にこう書いた。確かめる時は、ウェブページの要約ではなく、一次資料の本文を実際に読むこと。要約を読んで「確認済み」にしても、要約に混ざった捏造はそのまま通ってしまう。PIESが入ってきたのも、その道だった。
誰が確かめるかも分けた。数字や引用の照合は、同じCodeがやってもいい。PDFに0.15と書いてあれば0.15で、判定するのはAIではなく資料の方だから。「何が原因か」「どう捉えるか」のように解釈が入る主張だけ、別のClaudeに回す。レッドチームの役は、ここに残った。
Quick+は、手順書と、Codeがその手順どおりに動くための設定まで作ったが、まだ一度も使っていない。ただ、足したステップがやることは、今回偽の数字を見つけた時と同じ。結論を支える数字ごとに「確認しましたか?」と問い、手元の原典を開いて確かめる。
（出てきた論文と資料: DeepHalluBench〈arXiv 2601.22984〉、DeepResearch Bench、Raoらの研究、Duらの研究、Anthropicの公式の説明）