引用を確かめるには、手元の原文と、それを突き合わせる仕組みの両方が必要
僕のリサーチは、コーディングしてくれているClaude Code（以降Code）が、手順書に沿って進める。その手順書には、「引用は一次ソース（論文の原文や公式の発表）から一字一句そのまま取る」というルールが書いてあった。ただ、守られているかを確かめる仕組みは無かった。
しかもWebページの場合、確かめるための原文がCodeの手元に残っていなかった。Codeの説明では、CodeがWebページを読むと、返ってくるのは読んだ中身の要約で、ページそのものは残らない。引用が原文にあるかを確かめたくても、照らし合わせる先が無い。
このうち、原文が手元に無いという穴の方が先に埋まった。きっかけは、ページの保存についての小さな思いつきだった。
保存ボタンを押す手間を、Codeに任せたかった
僕はリサーチの参考ページを、Obsidian（メモをためておくノートアプリ）に保存している。使っているのはWeb Clipperという、Obsidianのブラウザ拡張機能。ポチっと押すと、本文だけきれいに抜いて、Vault（ノートをまとめて入れておく保管庫フォルダ）にMarkdownで保存してくれる。こうやって保存したページを、ここではクリップと呼ぶ。
特に必要に迫られていたわけじゃなくて、ふと思った。このWeb Clipper、Codeから直接操れないかな。Codeがリサーチしながら自分でページを保存できたら、僕がブラウザを開いてボタンを押す手間がいらなくなる。そのくらいの、思いつきレベルの話だった。
Codeがサブエージェント（Codeが作業を分けて任せる、別のAI）に調べてもらうと、Web Clipperはブラウザの拡張機能でしかなくて、外から動かす入口が無いと分かった。画面を自動で操作するしか手が無く、それでは壊れやすい。ただ、Web Clipperの中で記事の本文を抜き出しているエンジンは、defuddle（github.com/kepano/defuddle）という名前で、単体のツールとして公開されていた。拡張機能を操るのではなく、拡張機能が中で呼んでいる本体を直接呼べばいい。
保存したはずのページの画像が、1枚も手元に無かった
何を作るか決める前に、Codeが僕の実際のVaultの中を見た。クリップの保存先には23本入っていた。画像のところは、こうなっていた。
手元の画像ファイルではなく、外のサーバーのアドレス。23本、全部。画像が1枚も手元に無い。
Web Clipperは、本文は手元に保存するけど、画像は落としていなかった。保存というより、本文の写しと、画像へのリンク。リンクの先は動画サービスやニュースサイトのサーバーで、サイトがリニューアルすれば画像の場所も変わる。半年後、1年後にこのクリップを開いたら、テキストしか残っていない可能性が高い。リンク切れの爆弾を23本抱えていたことになる。
ここで話の向きが変わった。Web Clipperを自動化したい、だったのが、Web Clipperよりいいものが要る、になった。ページの原文を、画像まで含めて丸ごと手元に残せる道具。
Codeが作ったのは、ページを画像ごと手元に落とすツール、web-capture。本文はdefuddleでMarkdownにして、画像はプログラムから取りに行く。ただ、画像を置いているサーバーの中には、ページを見に来たブラウザには画像を渡すのに、プログラムが直接取りに来るとはじくものがある。Codeが試した、ある動画サービスの会社のページでも、画像は1枚も取れなかった。そういうページでは取りに行き直さず、ブラウザでページを開いて、ブラウザが画面に出すために受け取った画像を、そのまま保存する。
これで、ページの原文が画像ごと手元に残るようになった。僕がこれをリサーチの流れにどう入れるか聞くと、Codeが手順書に組み込んだ。一次資料のWebページは、要約で済ませず、web-captureで落としてから読む。
Googleのノートツールと比べて、引用のルールが人まかせだと分かった
手順書を直し終えたあと、僕はどこかで聞いた話をCodeに確かめた。Googleが一次ソースを調べられるツールを出しているらしいけど、本当？ 調べてもらうと、正体はNotebookLM（Googleの、資料を読み込ませて質問できるAIノート）だった。そのまま、僕のリサーチの手順と、良いところ悪いところを比べてもらった。
比べて分かったのは、冒頭の「引用は一次ソースから一字一句そのまま取る」が、人が気をつけて守るルールのままだったこと。NotebookLMの本当の強みは、答えの一節ごとに、それが資料のどこから来たかが付いてくることだった。しかもそれは、使う人が気をつけて守るルールではなく、ツールが自動でやってくれる。
結局NotebookLMそのものは使わないことにした。中身はクラウドにしか置けないし、Markdownで書き出せないし、Webページの画像も取り込まない。比べてCodeが挙げた、取り入れられる点は、ツールそのものではなく「ルールを仕組みで守る」という発想の方だった。
前にドラフトへ偽の数字が入ったのも、突き合わせる仕組みが無かったからだった
Codeが並べ直すと、穴は2つあった。
1つ目は、冒頭に書いた、Webページの原文が手元に残らないこと。クリップでは画像がリンクだけ、AIが読んだページは要約だけ。原文が丸ごと手元に残っていない、という点で、さっきのクリップと同じだった。
2つ目は、原文が手元にあっても、毎回突き合わせる仕組みが無かったこと。少し前に、ディープリサーチ（AIに調べものをまとめさせるやり方）の信頼性を調べるレポートを作った時のこと。その時、論文のPDFは手元に落としてあった。なのに、Codeがドラフトに使った数字は、PDFではなく、ウェブの論文ページの要約や、サブエージェントの読み取りから来ていた。そのどこかで、論文に無い数字が混ざっていた。別のAIにレッドチーム（あえて反論役をさせて、弱いところを探す検証）をやらせたら、その数字は確認したのかと聞いてきた。PDFと突き合わせたのは、それからだった。
1つ目は、web-captureで埋まった。ページを落とせば、Webページでも原文が手元に残り、引用が原文に本当にあるかを確かめられる。ただ、この時点では手順書に組み込んだところまでで、実際のリサーチではまだ使っていない。
残るは2つ目。原文と突き合わせる作業は、毎回決まってやる仕組みになっていなかった。
引用が原文にあるかを、機械が合否で返す
突き合わせる仕組みは、その場でCodeに作ってもらった。引用を確かめるツール、verify_quote。引用の文字列と、手元の原文のファイルを渡すと、一致すれば合格、しなければ不合格を返す。
これで見つけられるのは3つ。原文に無い引用。数字のすり替え（原文は1.4なのに引用は5.0、のような）。そして、否定の有無で意味が反対になっている引用（原文は「示さなかった」のに引用は「示した」）。3つ目は、書いたコードを見直す役のサブエージェントの指摘で足した。このツールは、空白や記号の小さな違いは許して比べるので、そのままだと否定の一文字違いも「ほぼ同じ」として合格してしまう。
手順書には、引用を「原文で確かめた」扱いにするにはverify_quoteの合格が要る、とCodeが書き足した。引用を原文から取るというルールが、書いてあるだけのものから、通るか落ちるかが機械で決まるものになった。
ただ、機械がやるのは合否を返すところまで。毎回このチェックを通すこと自体は、まだ手順書の指示のままだし、引用からどう読み取ったか、その解釈が正しいかまでは見ない。それでも、確かめる手段の無かったルールに、確かめる手段ができた。
最初は、ボタンを押す手間を省きたいだけだった。その思いつきで作った、ページを丸ごと手元に落とすツールが、引用を確かめる仕組みの土台になった。