CiteTrue と Google Scholar の比較
怪しい参考文献を手で確認するとき、多くの人がまず開くのが Google Scholar です。1 件だけならこれで十分に通用する方法です。40 件になった瞬間、方法として成立しなくなります。
判定が信頼できる理由
多くの引用チェックツールは判断そのものを言語モデルに丸投げし、モデルの言い分をそのまま見せます。しかしモデルは幻覚を起こす —— それこそがこの分野が存在する理由です。だから私たちはモデルを最初ではなく最後に置いています。
- 01
1. 推測せず、構文解析する
どの参考文献も、著者・タイトル・年・掲載誌・DOI といった要素に分解します。分解するのは引用形式のために作られたパーサーであって、「タイトルは何だと思うか」をモデルに尋ねているわけではありません。
- 02
2. 権威あるデータベースで照合する
分解した参考文献を Crossref と OpenAlex に照会し、DOI がない場合はオープンウェブにも当たります。返ってくるのは、実在する識別子を持つ実在のレコードです。
- 03
3. 一致度を決定的に採点する
候補レコードは、タイトルのトークンに対する Sørensen-Dice 類似度で採点します。一致と認めるのは、タイトルのスコアが 0.7 を超え、かつ著者リストが合致した場合だけです。年の不一致は注意として報告し、黙って受け入れることはありません。同じ参考文献なら、必ず同じスコアになります。
- 04
4. そこで初めてモデルに尋ねる
言語モデルを呼ぶのは、決定的な処理で本物の一致が見つからなかったときだけです。候補と原文を読ませ、当てはまるものがあるかを判断させます。モデルは最後の手段であって、裁定者ではありません。この順序だからこそ、幻覚による判定が入り込む余地がありません。モデルが登場する時点で、証拠はすでに出そろっているからです。
実際上の意味はこうです。ここで「実在する」と判定された参考文献は、タイトルと著者の両方で実在のレコードと一致しており、そのレコードは実際に開けます。「それらしく見える」というモデルの印象ではありません。
参考文献一覧を処理する速さ
1 件を確認するだけでも、複数の情報源に何度も問い合わせます。それを 1 件ずつ順番にやることが、長い文献一覧で遅く感じる原因です。私たちは並列に走らせ、終わったものから順に返します。
- 並列で処理する参考文献数
- アプリでは 20 件ずつ、API では 100 件ずつ
- 50 件の参考文献リスト
- 50 件を順番待ちにするのではなく、3 波の並列照会として送ります
- 届いた順に結果を表示
- 参考文献ごとに逐次配信 —— 残りが処理中でも、先に終わった判定から読めます
- 大量処理
- 指導教員が抱える論文の山は、アプリの 5 倍の並列度で API を通ります
役割の違いを比べる
| 比較する項目 | CiteTrue | Google Scholar |
|---|---|---|
| 何のために作られているか | すでに手元にある参考文献リストを検証する | まだ手元にない文献を探す |
| 参考文献 40 件を確認する | 1 回貼り付けて数分、手元に残るレポートが 1 本 | 手作業の検索 40 回と、40 回の判断 |
| その出典は主張を裏づけているか | Deep Verify が原文を読み、その問いに答えます | 自分で読んで判断します |
| でっち上げ参考文献の検出 | 参考文献ごとに明示的な判定と、その根拠 | 「結果が出ない」という事実 —— その解釈は自分に委ねられます |
| 費用 | 1 日 30 件まで無料、その後は $5.99/月から | 無料 |
| 手軽さ | 参考文献リストを一括で、さらに拡張機能・アプリ・API も | ブラウザのタブで 1 件ずつ |
では、どちらを使うべきか
論文を探すなら Google Scholar、40 件をまとめて確認するなら CiteTrue —— それぞれ得意な場面が違います。結局は両方使う人がほとんどです。執筆中は Scholar、投稿前は CiteTrue。