リサーチ結果の引用が「原文に本当にあるか」を検証するターミナル発エージェント「mole」
Go製のOSSエージェントmoleは、予算をハード制限し、抽出した引用が原文に一字一句存在するかを検証してから回答に載せる「深掘りリサーチ」ツール。手元のCSVを分析する場合も、モデルに渡るのは件数・平均・検定結果などの集計値だけで生データは外に出ないという設計をREADMEから確認した。
目次
3行まとめ
- moleは、質問を分解して検索・情報抽出・矛盾検出・引用付き回答生成までを行うGo製のディープリサーチエージェント。単一バイナリで動き、MCP経由でコーディングエージェントから呼び出せる。
- 予算は「見積もり」ではなく「強制」。すべてのモデル呼び出しは実行前に予約され、実行後に精算される台帳方式で、READMEはテストコーパス全体での予算超過率0%を報告している。
- 抽出された各主張（claim）は、元テキストに一字一句存在する引用が伴わない限り、その時点で破棄される。手元のCSV分析でも、モデルに渡るのは件数・平均・検定結果などの集計値のみで、生データは外に出ない設計。
「チャット+Web検索」との違いをREADMEはこう説明する
READMEはmoleがチャットインターフェース＋Web検索と違う点を3つ挙げている。
予算は見積もりではなく強制される。 すべての呼び出しは実行前に予約され、実行後に精算される。データベーススキーマ自体に非負制約（残高がマイナスにならない）を組み込んだ台帳で管理されており、--usd 0.50と指定すれば50セントで実行が止まる。READMEはテストコーパス全体での予算超過（オーバーシュート）を測定した結果が0%だったとしている。
すべての主張に検証済みの引用が伴う。 抽出された主張のうち、引用がその元になったページに一字一句存在しないものは、抽出の時点で破棄される。生き残った主張は後から元ソースに対して再検証され、支持されないと判明したものは黙って消されるのではなく「支持されない」と報告書内に明記される。
手元のデータはローカルに留まる。 CSVやフォルダを指定すると、moleはその中身をローカルで分析できる。モデルが選ぶのは仮説のテンプレートと列名だけで、実際のSQLの生成・実行はmole側が行い、外に返るのは件数・平均・検定結果・5件以上のレコードをまとめたバケットといった集計値だけだ。実際に何が外部に出たかはmole crossingsコマンドで確認できる。
デモとして掲載されている画像の説明では、あるリサーチ実行で39件の主張を抽出し、2件の矛盾を見つけ、コストは$0.0149だったという数字が示されている。
自己採点の数字も公開している
README後半には「Honest numbers（正直な数字）」という項目があり、mole eval <session-id>コマンドが実行ごとのスコアカードを出力すると説明されている。計算できない指標は0扱いにせず「計算不能」とそのまま表示するという設計だ。公開されている数字は次の通り。
| 指標 | 値 |
|---|---|
| 予算超過率 | 0%（上限を超えた実行はゼロ） |
| 主張の完全性 | 100%（保存された全主張が出典と逐語引用を伴う） |
| 引用の正確性 | 100%（引用元とされたテキストに実際にその引用が存在） |
| 裏取り率 | 80%（元ソースに対して再検証した主張のうち支持されたもの） |
| 矛盾検出の精度 | 確認パスありで70%、なしで51% |
| マージの適合率・再現率 | 構築済みの正解データに対して1.000／1.000 |
「主張の完全性」「引用の正確性」が100%である一方、「裏取り率」は80%、「矛盾検出の精度」は確認パスの有無で70%と51%に分かれている。これは、抽出段階での引用チェック（逐語一致するかどうか）は機械的に100%保証できても、その主張が実際に元の文脈全体を正しく反映しているかの再検証（裏取り）は完全ではない、という限界を数字がそのまま示している。
動かし方は2つ
READMEによれば、moleはMCPを話すため、コーディングエージェントから2通りの使い方ができる。1つは質問を投げて回答を受け取るだけの「委任」的な使い方。もう1つは「ツールキットモード」で、コーディングエージェント側の推論能力を使いつつ、moleはモデル呼び出しを伴わない部分（検索実行、引用検証、予算管理など）だけを部品として提供する。
インストールはLinux・macOS（amd64/arm64）向けのスクリプトが用意されており、リリースアーカイブをダウンロードした後、公開されているチェックサムに対してSHA-256を検証してから~/.local/bin（書き込み不可なら/usr/local/bin）に配置する、と説明されている。実際にこのスクリプトを取得して中身を確認したところ、README記載の通り「evalなし、必要な時以外sudoなし、すべてのダウンロードをチェックサム検証、--dry-runで実行内容を事前確認可能」という設計だった。Homebrewでの導入はbrew install lajosdeme/mole/moleだが、READMEには注意書きがある——homebrew/coreには無関係な別ツール（macOSのクリーンアップツール）としてのmoleが既に存在するため、brew install moleだけでは常にそちらが入ってしまう、という名前衝突についてだ。
テストコーパスの実体をリポジトリの中まで確認した
READMEには「テストコーパス」の中身までは書かれていないが、リポジトリ内のtestdata/ディレクトリを実際に開くと、その実体を確認できた。矛盾検出用のtestdata/corpus/contradictions.jsonには、実在の論争的な問いが10件収録されている。
- 「1918年のインフルエンザ・パンデミックで何人が死亡したか」
- 「世界人口はいつ・どの水準でピークを迎えるか」
- 「ビットコインネットワークは年間どれだけの電力を消費するか」
- 「心理学の研究のうちどれだけの割合が再現されるか」
- 「原子力は大規模太陽光発電とコスト競争力があるか」
ほか計10問で構成されている。同じディレクトリのtestdata/baselines/contradictions.jsonには、この10問に対する実際の実行結果（スコアカード）が記録されていた。たとえば「1918年インフルエンザ」の問いでは、実行に$0.0110（上限$0.4000のうち）を使い、47回のツール呼び出しがすべて台帳と整合し、36件の主張のうち36件が適格な形式で、6つの異なるソースのうち最大のソース（CDCアーカイブのページ）が36件中8件の主張に貢献した、という具体的な記録が残っている。
10問全体の集計（aggregate）では、1主張あたりのコストが平均0.0003974ドル、1問あたりの平均ツール呼び出し回数が66.3回、主張の完全性（claim integrity）は100%だった。ただし同じ集計データには「grounding rate（グラウンディング率）は10問中2問でのみ測定され、残り8問はブロックされた」という記載もあり、README本文の「Honest numbers」表にある100%という数字がどの母数に基づくものかは、この10問の矛盾検出コーパスだけを見ても一様ではないことが分かる。「exfil regression（データ流出の逆行テスト）」の項目も、この特定のテスト実行では「ローカルデータを横断するセッションが無かったため、この回では未測定」という扱いになっていた。
リポジトリの奥にあった、開発者自身による「判定のブレ」の記録
testdata/pairs/ディレクトリには、README本文には出てこないもう1つのテストデータがあった。batch-size-arms.jsonというファイルで、そのwhat（このテストの説明）フィールドにはこう書かれている。
"the graph's own pairs re-judged by the SAME model at two batch sizes, recorded before any human label existed so neither arm can be tuned to the labels"
（訳：グラフ自身が持つペアを、同一モデルで2つの異なるバッチサイズを使って再判定したもの。人間によるラベル付けが存在する前に記録されており、どちらの結果も後からラベルに合わせて調整することはできない）
これは、矛盾・重複を判定するために使っているモデル（deepseek-v4-flash）自身の判定が、どれだけ安定しているかを検証したデータだ。261件のペアを対象に、同じモデルへ「1件ずつ判定させる（バッチサイズ1）」場合と「8件まとめて判定させる（バッチサイズ8）」場合を比較したところ、次の結果が記録されていた。
| 指標 | 値 |
|---|---|
| バッチサイズ1で、元の保存済み判定を再現できた割合 | 35% |
| バッチサイズ8で、元の保存済み判定を再現できた割合 | 54% |
| バッチサイズ1とバッチサイズ8、両方の判定が一致した割合 | 69% |
つまり、同じモデルに同じペアを判定させても、1件ずつ聞くかまとめて聞くかで結果が大きく変わり、しかも過去に保存された判定を再現できる割合はどちらの条件でも半分程度かそれ以下だった。これは、moleが看板に掲げる「主張の完全性100%」「引用の正確性100%」といった指標とは別の場所——矛盾・重複の判定そのものの再現性——に、開発者自身が把握しているブレが存在することを示している。README本文にはこの数字への言及は無く、リポジトリのテストデータを直接開かない限り分からない情報だった。
実際にmoleを起動しての検証はしていない
本記事はlajosdeme/moleのGitHub README、GitHub API経由のリポジトリメタデータ、そしてリポジトリ内のtestdata/ディレクトリの実データを2026年8月にcurlで取得した内容にもとづく。GitHub API確認では、リポジトリの作成日は2026年8月1日、直近のpushは8月13日、リリースはv0.1.0（同8月13日）の1件のみで、スター293・フォーク16・未解決issue4件という、まだ日が浅い個人開発規模のプロジェクトだった。実際に自分のAPIキーでmoleを起動し、リサーチを実行して予算管理や引用検証の挙動を検証したわけではない。
予算の強制執行と引用検証を掲げるリサーチエージェントは未紹介
Zenn・Qiitaともに実質的な言及はなかった（Qiitaの2件はIETFセキュリティ記事や雑記で無関係）。「ディープリサーチ」を謳うAIツール自体は日本語圏でも話題になるが、予算の強制執行や引用の逐語検証を前面に出した設計のものは、まだ紹介されていない。
関連記事
出典・参照資料
AIニュースの解説を動画でも
YouTubeでは注目ニュースの背景を解説し、Xでは新着記事をお知らせしています。
コメント
まだコメントはありません。最初のコメントを書いてみませんか？
AIについて聞きたいことはありますか？
質問箱で無料で受け付けています。回答は公開され、他の方の参考にもなります。
質問箱を見る →新しい記事をメールで受け取る
AIの新しい発表を、出典付きで整理して届けます。
関連記事
チャットは会話を隠す、グラフは会話そのもの──ThoughtDAGが「編集できる文脈」に賭けた理由
Agent Client Protocol(ACP)とは──コーディングエージェントを「LSPのように」つなぐ標準規格
メタ検索エンジンsearxの作者が、13年後に「もう他社エンジンには頼らない」検索を作った理由
会話履歴を「要約」せず「追記」だけで持たせる──200行のコアで動くエージェントランタイム「bub」のテープ設計
AIエージェントの`rm -rf`を実行前に止める「Doberman」──自己申告ベンチマークを読むと見えてくる限界
『深いカスタマイズが要らないならOpenClawを使え』──公式READMEが名指しで住み分けるエージェント基盤「fount」
Claude Codeの「毎回ゼロから調べ直す」を止める「Graft」──SWE-benchで33/50 vs 27/50まで踏み込んだ数字
