zotero-AI-Butler レビュー：Zotero に論文を放り込むだけで LLM 要約ノートを作らせる AGPL プラグイン
【Zotero AI 管家】调用大模型，自动精读论文库里的论文，总结为Zotero笔记。支持主流大模型平台！您只需像往常一样把文献丢进 Zotero， 管家会自动帮您精读论文，将文章揉碎了总结为笔记，让您“十分钟完全了解”这篇论文！
ひと目でわかる
- これは何？
- Zotero の新規 PDF を自動検知し、大模型 API で Markdown ノートを生成するプラグイン。仕組みは「ローカルから API を直接叩く」方式で、設定項目は多いが、その分モデルとプロンプトを自分で選べる。
- 誰に向いている？
- 採用すべきなのは、Zotero を文献管理の中心に据えていて、自分で大模型 API キーを用意でき、要約プロンプトを自分で調整する気がある研究者だ。逆に、API キーの管理を外部に任せたい人、プラグインに安定したサポート契約を求めたい人、あるいは PDF の中身を外部に送ること自体を避けたい人には向かない。
- 商用利用できる？
- 厳しい条件付きでできます。AGPL-3.0 はネットワーク型コピーレフトのライセンスで、改変版をホスティングサービスなどとしてネットワーク越しに利用させる場合、その利用者にソースコードを同じライセンスで提供する必要があります。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
このプラグインが埋めるのは「読む時間」ではなく「読む順番」の穴
README が挙げる痛点は 3 つで、論文が多すぎて読み切れないこと、読んでも忘れて読み直しになること、翻訳があっても長文の要点をつかめないことだ。ここで実際に解かれているのは要約そのものではなく、要約を回す手間である。既存の LLM でも論文 1 本の要約はできる。問題は 1 本ごとに PDF をコピーしてチャットに貼り、プロンプトを打ち直す作業で、これが文献 50 本になると現実的でなくなる。
zotero-AI-Butler は Zotero の内部に常駐し、PDF の追加を検知して要約をノートとして同じ条目に書き戻す。生成物が Zotero のノートである点が効いていて、要約は Zotero の検索、タグ、エクスポートの対象になる。外部のチャット履歴に散らばらない。想定読者は、Zotero をすでに文献管理の中心にしている大学院生と研究者である。逆に、文献管理を Mendeley や EndNote で済ませている人がこのプラグイン単体のために Zotero へ移る理由は薄い。
処理の流れは「キューに積む、ワーカーが API を叩く、ノートを書き戻す」
README によれば、すべての論文分析は生産者と消費者のモデルで動く。タスクキュー画面で待機中、実行中、完了、失敗の状態を確認できる。投入経路は 3 つあり、条目を右クリックして即時投入する方法、仪表盘の界面设置で自動扫描新文献を有効にして新規 PDF を自動で拾わせる方法、仪表盘の扫描未分析论文で既存の未処理論文をディレクトリ構造ごと一覧して選ばせる方法である。
自動扫描はデフォルトで無効になっている。README はその理由を Zotero 本体の性能への影響を最小化するためと説明している。有効にすると、PDF を Zotero にドラッグした後、Zotero がメタデータ検索を終えるのを待ってから分析が始まる。待つ理由は書かれていないが、タイトルや著者などのメタデータがノートに埋め込まれる以上、それが揃うまで動かない方が都合がよいという設計判断だと読める。処理速度は 1 分あたりの論文数として設定でき、API のレート制限を避けるための項目だと説明されている。
PDF の渡し方には 2 通りある。Base64 で PDF をそのまま送る多模态处理と、テキストを抽出して送る文字提取模式である。README は前者を Gemini 2.5 Pro のような多模态モデル向けとし、画像、数式、表の理解に優れるとしている。後者は多模态非対応モデル向けで、Ollama の項目ではテキスト抽出または MinerU で PDF を処理すると書かれている。ここは実務上の分岐点で、数式の多い論文をテキスト抽出モードに通すと式が崩れる可能性がある。逆に Base64 は入力トークンを大きく消費する。どちらが自分の分野に合うかは、数本試して出力を見る以外に判断材料がない。
導入はプラグインのインストールと API キー設定の 2 段階
配布は GitHub Releases で行われており、README のバッジは最新リリースを指している。Zotero プラグインの一般的な手順として、リリースから .xpi を取得して Zotero にインストールすることになるが、README 本文にはインストール手順の記述がなく、詳細は AI Butler Wiki に委ねられている。ここは読者にとって摩擦になる。本体の README だけでは導入手順が完結しない。
設定は Zotero の 编辑 → 设置 → AI管家 タブ、または任意の条目を右クリックして AI管家仪表盘 から開く。仪表盘 は 仪表盘、任务队列、快捷设置、提示词模板 の 4 ページ構成だと説明されている。快捷设置 に API 配置があり、OpenAI、Gemini、Anthropic、OpenAI 兼容 の 4 系統に加え、表では 火山方舟 と Ollama も挙げられている。キーを入れた後は 测试连接 ボタンで疎通を確認できる。
プロンプトは 提示词模板 で管理し、{{title}} や {{authors}} のような変数を埋めた結果を編集時にプレビューできる。組み込みプリセットの切り替え、自定义プリセットの保存、系统默认への一键恢复 が用意されている。多轮对话 用のプロンプトも設定でき、研究背景与问题、研究方法与技术、实验设计与结果、结论与展望 といったラウンドごとの指示を書いて、最後に 1 本の要約へまとめる構成が README の表で示されている。プロンプトを自分で書き換えられることがこのプラグインの実質的な差別化点で、要約の質はここで決まる。
API キーはローカルから出るが、PDF は出る
README の冒頭に隐私声明がある。このプラグインは大模型の代理サービスを提供せず、ユーザーが自分で API キーを取得して設定する必要がある。プラグイン自体は個人データ、文献、API キーを収集、保存、送信しない。すべてのリクエストはローカル端末から設定した大模型サービスへ直接送られると書かれている。
この説明は正確だが、安心材料として読むには範囲が狭い。キーが開発者のサーバーを経由しないという話であって、論文の本文が外部に送られないという話ではない。Base64 モードでは PDF そのものがモデル提供元へ送られる。テキスト抽出モードでも抽出後の全文が送られる。未発表の原稿、査読中の論文、企業の機密を含む資料を扱うなら、送信先は自分で選んだ API プロバイダであり、その先の保持ポリシーはこのプラグインの管轄外である。Ollama を使う構成だけがこの経路を閉じられる。README は Ollama をローカルまたは LAN のモデルサービスとして挙げ、PDF はテキスト抽出か MinerU で処理するとしている。機密性が要件なら選択肢はここに絞られる。
一图总结と思维导图は要約とは別の賭けである
3.0 系で追加された機能として、Nano Banana Pro で論文 1 本を学術ポスター風の画像にまとめる 一图总结 がある。加えて、論文の階層構造を可視化する 思维导图 を自動生成し、拡大縮小、PNG 書き出し、OPML 形式でのエクスポートに対応する。OPML が出せるのは実用的で、他のアウトラインツールへ構造を移せる。
ただし 一图总结 は要約テキストとは性質が違う。ポスター画像は検索できないし、Zotero のノートとしての編集も効かない。記憶の取っ掛かりを作る用途だと README は説明しているが、後から内容を参照する目的には向かない。また、この機能は Nano Banana Pro に依存しており、他のモデルでの代替が可能かどうかは README からは読み取れない。思维导图 も同様に、生成のトリガーや失敗時の挙動について README に記述がない。この 2 機能は、要約ノートが既に安定して動いていることを前提に試す追加要素として扱うのが妥当である。
向かない場面：安定版を求める人と、手順の少なさを求める人
リリース履歴を見ると、v4.1.0-beta.2、v4.1.0-beta.1、v4.0.3-beta.8 と beta 表記のリリースが並ぶ。最新の機能はまず beta として出る運用だと推測できる。研究の締め切り前に、文献 200 本の一括処理をこのプラグインに賭けるのは勧められない。タスクキューに失敗状態がある以上、失敗は起きる前提で設計されている。失敗したタスクをどう再投入するかは README に記述がない。
もう 1 つの制約は手順の分散である。README は機能説明としては分量があるが、インストール手順とトラブルシューティングは Wiki 側にある。README には gcli2api を使って Gemini 3 pro の無料枠を得る構成が discussion へのリンクとして紹介されている。これは回避策であって公式の提供経路ではない。サードパーティの API 中継に依存する構成は、その中継が止まれば動かなくなる。設定を再現可能な形で残しておきたい人には、この依存関係の見えにくさが負担になる。
さらに、生成されるノートの品質はモデルとプロンプトに完全に依存する。プラグイン側が要約の正確さを保証する仕組みは README には書かれていない。ハルシネーションの検査機能も見当たらない。要約を読んで終わりにするのではなく、原文と並べて確認する運用が前提になる。README 自身が、原文を読みながらノートを並べて表示する使い方を案内している。
代替手段との違いは「ノートを Zotero に残すか、チャットに残すか」
比較対象として分かりやすいのは、Zotero の外部で動く文献要約ツール、たとえば PDF をアップロードして要約を得るタイプのウェブサービスや、汎用チャットに PDF を貼る運用である。違いは生成物の置き場所にある。外部サービスは要約をそのサービスの画面に残す。Zotero に戻すには手でコピーする必要がある。zotero-AI-Butler はノートを条目に直接書き込み、Zotero の検索とエクスポートの対象にする。文献 100 本の要約を後から横断検索したいなら、この差は運用の差ではなくなる。
もう 1 つの比較軸はモデルの選択権である。外部サービスは自社が選んだモデルで要約する。このプラグインは OpenAI、Gemini、Anthropic、OpenAI 兼容、火山方舟、Ollama を設定から選べる。プロンプトも書き換えられる。代わりに、キーの取得、レート制限の管理、モデルごとの PDF 対応の確認はすべて利用者の作業になる。手間を引き受ける代わりに制御を得る取引だと理解しておきたい。Ollama を選べる点は、外部送信を避けたい場合に外部サービスにはない選択肢になる。ただしその場合、要約の品質はローカルで動かせるモデルの能力に縛られる。
ライセンスと保守コストの見積もり
ライセンスは AGPL-3.0 である。Zotero プラグインとして自分の研究に使う分には通常の利用になるが、改変したものをネットワーク経由で提供する形態を取る場合は AGPL の条件が関わってくる。ここで具体的な法的判断を示すことはできない。組織で導入するなら、法務あるいはライセンス担当に AGPL-3.0 の該当条項を確認してもらうのが先である。
保守コストは 3 つの外部要因に連動する。Zotero 本体のバージョンアップ、大模型 API の仕様変更、そして Nano Banana Pro など特定モデルへの依存である。リポジトリは Zotero Plugin Template を使っていると README のバッジが示しており、Zotero 側の変更に追随する必要がある構造だ。API 側では OpenAI の新接口と旧接口が別項目として扱われており、プロバイダの API 変更が設定の作り直しを要求しうることが読み取れる。
アップグレードの際に確認すべきは、リリースノートで PDF 処理方式とプロンプト変数の仕様が変わっていないかである。変数名が変われば自作プロンプトは黙って壊れる。README には 一键恢复 で系统默认に戻す導線があるので、挙動がおかしくなったらまず既定プロンプトで同じ論文を処理し直し、自作プロンプトとの差分を切り分けるのが早い。
編集部の結論
採用すべきなのは、Zotero を文献管理の中心に据えていて、自分で大模型 API キーを用意でき、要約プロンプトを自分で調整する気がある研究者だ。逆に、API キーの管理を外部に任せたい人、プラグインに安定したサポート契約を求めたい人、あるいは PDF の中身を外部に送ること自体を避けたい人には向かない。導入前に確認すべきは 3 点で、第一に自分の Zotero のバージョンで動くリリースがあるか、第二に選んだモデルが Base64 の PDF 投入に対応しているか、第三に AGPL-3.0 の下で自分の利用形態が問題ないか。特に 2 点目は、テキスト抽出モードに落とすと数式と図表の扱いが変わるため、自分の論文の種類でどちらを使うかを先に決めておきたい。
コミュニティノート