そもそも、なぜ作ろうと思ったのか
きっかけは、自分で先行研究を探していたときのことでした。
AIのリサーチ機能を使うと、短時間でかなりの数の論文や関連研究が出てきます。最初は便利だと思ったのですが、いざ一件ずつ確認し始めると、思った以上に大変でした。
検索すると、それらしい論文は出てくる。でも、本当に存在するのかよく分からないものがある。タイトルは見つかるのにDOIが合わない。DOIはあるけれど、著者名や発表年、論文タイトルとの対応をもう一度確認したくなる。逆に、検索で見つからないからといって、その論文や先行研究が存在しないとも言えません。
結局、AIが出してきた結果をそのまま使うことはできず、DOIを確認し、書誌情報を照合し、検索語を変えてもう一度探す、という作業をかなり手でやることになりました。
そのときに困ったのは、単に「正しい論文を探す」ことだけではありませんでした。
何を検索して、何が出てきて、どこまで確認して、それでも見つからなかったのか。
そこが残っていないと、あとから自分でも「なぜ先行研究がないと思ったのか」を説明できません。
「見つからない」と「存在しない」の間には、思っていたより大きな距離がありました。
この面倒な確認作業を、もう少し仕組みにできないか。
そこが、Renotoriの一番最初の出発点です。
最初に作ろうとしていたのは、Research Gap Auditor(RGA)という名前のツールでした。研究のギャップ(まだ誰も手を付けていなさそうな領域)を探すのを手伝うもの、というつもりです。
ところが実装を進めるほど、「ギャップを判定する」という看板が重くなっていきました。最終的に出来上がったのは、Research Gapを判定しないツールです。名前もRenotori(レノトリ)に変えました。
この記事では、その過程で何を諦めて、何を残したのかを書きます。研究支援の話ですが、LLMやAIエージェントを作っている人が一度はぶつかる「どこまでAIに判断させるか」という問題として読んでもらえたら嬉しいです。
最初はこう考えていた
研究テーマ(Research Question、以下RQ)を入れると、関連しそうな文献を集めて、手薄な領域を整理してくれる。そういうツールを想像していました。
ギャップを「発見する」とまでは思っていませんでしたが、名前に Gap と Auditor(監査する人)を入れた時点で、ツールに判定役を持たせるつもりだったのだと思います。
実装してみると、この境界が危ないと気づいた
違和感が出たのは、検索まわりを具体的に書き始めたときです。
たとえば、ある検索語で文献がほとんど出てこなかったとします。これを見て「ここは研究ギャップだ」と言えるでしょうか。
言えません。検索語の選び方が悪かっただけかもしれません。表記ゆれで取りこぼしているのかもしれません。そもそも検索先のデータベースにその分野が入っていない可能性もあります。「見つからなかった」は、「存在しない」の根拠にはなりません。
ここでLLMに「ギャップがありそうです」と書かせることはできます。それらしい文章も出てきます。でも、「検索で見つからなかった」だけでは、その結論を支える根拠になりません。ツールがもっともらしい断定を出してしまうと、使う人はそれを信じてしまうかもしれない。そこが怖いと思いました。
同じ構造は、検索結果の扱いにもありました。検索エンジンが返したヒットは、あくまで「検索語に反応したもの」です。それがRQに関連するかどうかは、また別の判断になります。
つまり、このツールの中には混ぜてはいけないものが何層もありました。検索すること、返ってきたものを候補として持つこと、それが本当に関係あるかを判断すること、そして「ギャップがある」と結論すること。後ろの層ほど、ツールが責任を持てなくなります。
判断ではなく、判断までの過程を残すことにした
そこで、プロダクトの責任範囲を狭めました。
Gapを判定するのをやめて、次のことを追跡できる形で残すツールにしました。
- 何を検索したか
- 何が返ってきたか
- 人がどう判断したか
- 次に何を検索したか
RGAからRenotoriへの名称変更は、ブランディングというより、この方針転換の結果です。実際に責任を持てる範囲に、プロダクトの説明を合わせました。できることは少し狭くなりましたが、そのぶん説明できることが増えたと感じています。
Renotoriが記録するのは、元のRQ、実際に使った検索語、検索計画、Crossrefから返ってきた結果、文献候補、人による関連性の判断、次に追加した検索語、各Roundの履歴です。検索が失敗したときや、探索が終わった状態も記録の対象になります。
全体の流れ
流れを図にするとこうなります。
Research Question(原文のまま保存)
↓
Query Plan
↓
Search Query
↓
外部検索(Crossref)
↓
Candidates(文献候補)
├─→ 人が関連性を判断(関連あり / 判断保留 / 関連なし)
│
└─→ 人が次の検索語を提案・送信 ──→ 次のRoundへ
すべてが Search Trace に記録される
ポイントは、判断と次の検索を一本のベルトコンベアにしていないことです。関連性の判断は候補ごとに人が付けます。次の検索語も、人が考えて送信します。どちらもシステムが自動で進めることはありません。
検索結果は「候補」として持つ
検索で返ってきた文献は、まずCandidate(候補)として保存します。「RQに関連する文献」とは呼びません。
そのうえで、人が一件ずつ、関連あり、判断保留、関連なしのどれかを付けます。理由の記入も必要です。この判断は上書きではなく追記で持っていて、あとから判断を変えても、前の判断が残ります。
エンジニア向けに雑に言うと、概念的には、DBに入った行と、人がレビューした結果を別のテーブルで持っているようなものです。検索結果は事実の記録、レビューは人の判断の記録で、混ぜません。
関連性の判断までLLMに任せる設計も考えられます。でも、あるRQにとって何が関連するかは、研究者がどんな観点で探しているかに左右されます。そこをAIに確定させる設計にはしませんでした。
探索の経路を第一級のデータにする
Renotoriは、最終的な文献リストだけを保存するツールではありません。
リストだけなら、あとから同じものを作れるかもしれません。でも、どの検索語から始めて、何が返ってきて、何を関連ありと見て、次に何を探したのかは、リストからは分かりません。こちらの経路のほうを、データとしてきちんと残すことにしました。
provenance(来歴)や traceability(追跡可能性)、auditability(あとから検証できること)に近い考え方です。ここでは「あとで見返して、どうやってそこに辿り着いたか説明できる」という意味で使っています。
何をシステムに任せ、何を人に残したか
Round 1では、役割をこう分けています。
RQは原文のまま保存します。ユーザーがRQの中から主要語を選び、必要なら表記ゆれも入力します。それをもとに、Renotoriが規則ベースでQuery Planを作ります。LLMが検索式を作る、という作りにはしていません。作られた計画は、実行前に画面で確認できます。
Round 2以降は、人が追加の検索語を一件ずつ提案します。システムが「次はこれを探しましょう」と勝手に決めることはありません。
上限も付けています。Public Betaは、1回の調査で最大5 Roundまでです。完全に自律的に走り回るエージェントにはせず、Roundごとに人が結果を見て、次の検索語を決める形にしました。どこまで探索したかを人が把握しやすく、探索の経路も追いやすいと考えたからです。
現在のPublic Betaでは、検索計画は規則ベースで作り、実行前に人が確認できるようにしています。検索計画の生成にもLLMは使っていません。
ただ、LLMを使わないこと自体が目的ではありません。重要なのは、AIやシステムにどこまで判断を任せるか、その境界を決めることです。
検索先はCrossrefだけ
現在のPublic Betaの検索先は、Crossrefのみです。J-STAGEやCiNiiは、現在の検索対象には含まれていません。
もうひとつ、Crossrefの検索は、入力した語をすべて含むものだけを返す厳密なAND検索ではなく、関連度に基づく検索です。たとえば「継続賃料 ゲーム理論」のように入れても、両方の語を含む文献だけが並ぶとは限りません。この点は、画面にも注意書きを出しています。
検索先の挙動を知らないまま結果を読むと、「ヒットが少ない」を「研究が少ない」と取り違えやすくなります。制約を先に見せることも、設計の一部だと考えています。
実装して分かったこと
一番の学びは、実装が追いつかない看板を、実装のほうで追いかけなかったことです。
「Gapを監査する」という名前に実装を寄せていくと、根拠の足りない判定を、判定のような顔でユーザーに見せることになります。反対に、責任を持てる機能に説明を合わせると、できることは減ります。でも、減った分だけ、ツールの言うことを信じていい範囲がはっきりしました。
最近は、ツールが何を言い切らないかを決めるのも、設計の仕事だと思うようになりました。
開発は一人でしていますが、複数のAIに役割を分けて、実装とレビューを回しています。ここは今回の主題ではないので、別の記事で書くつもりです。
現在の限界
Renotoriにできないこと、やらないことを、まとめて書いておきます。
- Research Gapが存在するかどうかを判定しません
- 先行研究が存在しないことを証明しません
- 網羅的な検索を保証しません
- noveltyを保証しません
- 論文の主張が正しいかどうかを判定しません
- 研究上の最終判断をAIに任せません
- 検索先は現在Crossrefのみです
ここに挙げたのは、ツールが責任を持たない範囲です。ここが曖昧だと、使う人が「ツールがそこまで見てくれた」と思ってしまうかもしれません。
試してもらえるとうれしいです
今回書いた仕組みは、Renotoriとして Japanese Public Beta を公開しています。登録は不要で、当面は無料で試せます。Public Betaのため、利用上限があります。
まだBetaなので、実際に使ってみて、次のようなことがあれば、ぜひ教えてください。
- 分かりにくかったところ
- こういう記録も残せるとよい、と思ったこと
- 研究探索の流れとして使いづらかったところ
LP: https://renotori.vercel.app/
アプリ: https://research-verification-core.onrender.com/
お知らせ（2026/10/９追記）
金沢シーサイドFMの番組「社長！あなたの会社教えてください。」に
出演させていただくことになりました。
2026年11月20日ごろ放送予定です。
HP：https://kanazawa-seasidefm.co.jp/
番組（spotify）：https://open.spotify.com/show/2vgzg9tW45iW4jZnZAnaRR