n8nとZoteroを連携したい人の検索意図は、大きく分けると「Zoteroの文献情報をn8nで取り出したい」「論文やDOIを自動でZoteroに登録したい」「ZoteroのハイライトやメモをAI・RAG・Notion・Google Sheetsなどに流したい」の3つに集約できます。今回調査した範囲では、n8n公式テンプレートにもZoteroライブラリから書誌データを取得するワークフローがあり、TelegramからDOIを送ってZoteroへ登録するテンプレートも確認できました。
この記事では、n8n zotero連携で何ができるのか、どこから始めればよいのか、APIキー・USER ID・コレクションキー・差分取得・PDF添付・RAG化まで、初めての人にもわかるように整理します。体験談ではなく、公開されているワークフロー、Zotero APIまわりの議論、Notion連携やファイル分類の事例をもとに、「実装するときに迷いやすいポイント」を中心にまとめます。
| この記事のポイント |
|---|
| ✅ n8nとZoteroでできる自動化の全体像がわかる ✅ Zotero APIキー・USER ID・コレクションキーの役割がわかる ✅ DOI登録、文献取得、RAG化、Notion連携の違いがわかる ✅ 差分取得やPDF添付など、つまずきやすい注意点がわかる |
n8nとzotero連携の基本理解
- n8n zoteroの答えは「Zotero APIをHTTP Requestで動かす文献自動化」である
- Zoteroから文献データを読むにはUSER IDとAPIキーを先に用意する
- コレクション単位で取得すると論文整理の自動化が扱いやすい
- DOIやarXivを入口にするとTelegramからZotero登録まで自動化できる
- ZoteroのハイライトはRAG化すると第二の脳として使いやすい
- NotionやGoogle Sheets連携ではZoteroを情報の親にすると破綻しにくい
- APIでデータが足りないと感じたら別アイテム取得や指定ミスを疑うべきである
n8n zoteroの答えは「Zotero APIをHTTP Requestで動かす文献自動化」である
n8n zoteroで検索している人がまず知るべき結論は、n8nにZotero専用ノードがなくても、HTTP Requestノードを使えばZotero APIを呼び出せるという点です。つまり、n8n側では「APIを呼ぶ自動化ツール」として動かし、Zotero側では「文献データを保管している親データベース」として使う形になります。
n8n公式テンプレートには、Zoteroライブラリから書誌データを取得するワークフローが公開されています。このテンプレートでは、ZoteroのUSER IDとPrivate Keyを使い、指定したコレクション内の文献メタデータを読み取る流れが紹介されています。最後のノードでフィルターやフィールド編集を行えるため、Notion、Google Sheets、RAG用データベースなどへつなげやすい構成です。
参考：Zoteroライブラリから文献メタデータを取得するn8n公式テンプレート
https://n8n.io/workflows/2444-get-bibliographic-data-from-your-zotero-library/
n8nとZoteroの連携は、難しそうに見えて、考え方はかなりシンプルです。ZoteroのAPIから文献一覧を取り出す、必要なら加工する、別の場所へ渡す。この3段階で整理すると、最初の設計で迷いにくくなります。
📌 n8n zotero連携でできること
| やりたいこと | n8nでの考え方 | 主な接続先 |
|---|---|---|
| Zoteroの文献一覧を取得 | HTTP RequestでZotero APIを呼ぶ | Notion、Sheets、DB |
| DOIから文献を登録 | DOIを解析して外部APIでメタデータ取得 | Zotero |
| PDFを添付 | PDFリンクやバイナリを扱う | Zotero、外部ストレージ |
| ハイライトをAI検索 | テキスト化してベクトル保存 | Supabase、OpenAI |
| 要約を返す | LLMで抽象やメモを要約 | Telegram、Slackなど |
特に重要なのは、Zoteroを「最終的な保管場所」としてだけ見るのではなく、研究ワークフロー全体の中心データベースとして扱うことです。Zoteroに入っているタイトル、著者、DOI、タグ、添付ファイル、コレクション情報をn8nで取り出せれば、他ツールへの同期やAI検索の起点にできます。
一方で、n8n zotero連携は魔法のようにすべてを自動で整えてくれるものではありません。どのコレクションを対象にするか、どのフィールドを使うか、重複をどう避けるか、削除や更新をどう扱うかは設計が必要です。最初から大きく作り込むより、まずは1つのZoteroコレクションを読み取るだけの小さなワークフローから始めるのが現実的です。
✅ 最初に作るべき最小構成
| ステップ | 内容 |
|---|---|
| 1 | Zoteroで専用コレクションを作る |
| 2 | Zotero APIキーを発行する |
| 3 | n8nのHTTP Requestで文献一覧を取得する |
| 4 | 取得結果をテーブル表示で確認する |
| 5 | 必要な項目だけ抽出する |
| 6 | NotionやSheetsなどへ送る |
この最小構成が動けば、次に「新規文献だけ同期する」「タグで分岐する」「要約を追加する」「AI検索用にベクトル化する」といった発展がしやすくなります。n8n zoteroの本質は、ZoteroをAPI経由で読み書きし、研究作業の繰り返し部分をワークフロー化することだと考えると理解しやすいです。
Zoteroから文献データを読むにはUSER IDとAPIキーを先に用意する
Zoteroからn8nで文献データを取得するには、まずUSER IDとAPIキーを用意する必要があります。n8n公式テンプレートでは、Zoteroのセキュリティ設定ページからUSER IDを確認し、同じ画面でNew Private Keyを作成する流れが説明されています。
USER IDは、Zotero APIのURLに入る利用者識別子です。APIキーは、n8nがZoteroにアクセスするための鍵です。この2つがないと、n8n側でHTTP Requestを作ってもZoteroライブラリを正しく読み取れません。
Zotero APIキーは、扱いとしてはパスワードに近いものです。記事内のサンプルやスクリーンショットにそのまま載せたり、n8nの公開ワークフローに埋め込んだりするのは避けたほうがよいです。一般的には、n8nのCredential機能や環境変数のような仕組みに入れて管理します。
🔑 Zotero連携で必要になる認証情報
| 項目 | 役割 | どこで使うか |
|---|---|---|
| USER ID | Zoteroユーザーを識別する番号 | API URL |
| Private Key | APIアクセス用の秘密キー | HTTP Header |
| Collection Key | 対象コレクションを指定するキー | API URLやフィルター |
| Library Type | 個人ライブラリかグループかの区別 | API設計時 |
n8n公式テンプレートでは、Credential TypeとしてHeader Authを使い、名前にZotero-API-Key、値にPrivate Keyを設定する形が紹介されています。実際のHTTPリクエストでは、Zotero APIの仕様に合わせてヘッダーへキーを渡す必要があります。
参考：Zotero APIキーとUSER IDを使うn8nテンプレート
https://n8n.io/workflows/2444-get-bibliographic-data-from-your-zotero-library/
初めて設定する人が混乱しやすいのは、ZoteroのWeb画面で見えるIDやURLの文字列と、APIで使うIDやキーが別物である点です。USER IDは設定ページで確認し、Collection Keyはコレクション取得結果やURLから確認する、というように役割を分けて見たほうが安全です。
🧭 初期設定チェックリスト
| 確認項目 | 状態 |
|---|---|
| Zotero Webアカウントにログインできる | ✅ |
| Desktop版ZoteroとWeb同期が有効 | ✅ |
| USER IDを控えた | ✅ |
| Private Keyを作成した | ✅ |
| n8nにCredentialとして保存した | ✅ |
| まずは読み取り権限だけで試した | ✅ |
権限については、最初から広く付与しすぎないほうが管理しやすいです。読み取りだけで足りるワークフローなら、読み取り中心の権限で始めるのが無難です。Zoteroへ新規登録や削除まで行う場合は、必要に応じて書き込み権限を検討します。
また、会社や研究室で使う場合は、個人ライブラリとグループライブラリの違いにも注意が必要です。今回の提供データでは個人ユーザー向けの例が中心ですが、グループライブラリを扱う場合はAPI URLの形が変わる可能性があります。一般的には、Zotero公式APIドキュメントで対象ライブラリのURL形式を確認してからn8n側へ反映します。
コレクション単位で取得すると論文整理の自動化が扱いやすい
n8nとZoteroを連携するなら、まずはZoteroのコレクション単位で文献を取得する設計が扱いやすいです。すべてのライブラリを一度に取得すると、文献数が増えたときにフィルターや重複管理が複雑になります。研究テーマ、論文執筆プロジェクト、授業、顧客案件などでコレクションを分けておくと、n8n側の処理もきれいになります。
n8n公式テンプレートでも、対象コレクションのKEYをコピーして使う流れが説明されています。具体的には、まずCollectionsノードでコレクション一覧を取り、Select Collectionノードで対象のKEYを確認し、そのKEYを使って文献データを読み取る流れです。
コレクション単位の設計は、あとからNotionやGoogle Sheetsへ同期するときにも効きます。たとえば「修士論文用コレクション」だけをNotionに同期する、「AI論文コレクション」だけをRAGに入れる、といった整理がしやすくなります。
📚 コレクション単位で運用するメリット
| メリット | 説明 |
|---|---|
| 対象範囲が明確 | どの文献を処理するか迷いにくい |
| 同期先を分けやすい | Notion、Sheets、DBごとに分岐できる |
| API負荷を抑えやすい | 全件取得より小さく始められる |
| 人間の整理とも一致しやすい | Zotero上のフォルダ感覚と近い |
| トラブル調査が楽 | どのコレクションで失敗したか追いやすい |
一方で、コレクション運用には注意点もあります。1つの文献が複数コレクションに入っている場合、同期先で重複して見えるかもしれません。これを避けるには、Zoteroのアイテムキーを同期先にも保存し、同じキーなら更新扱いにする設計が必要です。
🧩 同期先に保存しておきたい項目
| 項目 | 保存する理由 |
|---|---|
| Zotero item key | 重複判定に使う |
| title | 表示名として使う |
| creators | 著者情報として使う |
| date | 年代や並び替えに使う |
| DOI | 外部照合に使う |
| tags | 分類や絞り込みに使う |
| dateModified | 更新検知の参考に使う |
Notion連携の記事でも、Zoteroをメインの情報源とし、Notionを操作やメモのためのリポジトリとして扱う考え方が紹介されています。これはn8nでもそのまま応用できます。つまり、Zotero側を親、Notion側を見やすく加工した作業画面として使う発想です。
参考：ZoteroとNotionをAPI経由で同期する考え方
https://www.simonesmerilli.com/life/zotero-notion
コレクション単位で扱う場合、最初に決めておきたいのは「Zoteroと同期先のどちらを正とするか」です。一般的には、文献情報の正はZoteroに置いたほうがわかりやすいです。NotionやSheets側でメモや評価を追加する場合も、文献そのもののタイトルやDOIはZoteroから来た情報として扱うと、あとから整合性を保ちやすくなります。
DOIやarXivを入口にするとTelegramからZotero登録まで自動化できる
n8n zotero連携は、Zoteroから文献を取り出すだけではありません。逆に、外部から届いた論文情報をZoteroへ登録することもできます。n8n公式テンプレートには、TelegramでDOIリンクを送ると、Crossref、DataCite、Unpaywallなどからメタデータを取得し、Zoteroへ登録するワークフローが公開されています。
この仕組みの面白いところは、スマホからでも使いやすい点です。論文を見つけたときにTelegram BotへDOIやarXiv識別子を送るだけで、n8nが文献情報を取りに行き、Zoteroに親アイテムを作成し、可能であればPDFリンクも添付する流れになります。
さらに、LLMを使ってabstractの短い要約を作り、Telegramへ返す構成も紹介されています。これにより、「あとで読む論文をZoteroへ入れる」だけでなく、「読むべきかどうかの一次判断」まで自動化できます。
📨 TelegramからZoteroへ登録する流れ
| 段階 | 処理内容 | 使われるもの |
|---|---|---|
| 1 | Telegram BotへDOIを送る | Telegram API |
| 2 | DOIやarXiv IDを抽出する | n8nの文字列処理 |
| 3 | メタデータを取得する | Crossref、DataCiteなど |
| 4 | PDF候補を探す | Unpaywall、arXivなど |
| 5 | Zoteroに親アイテムを作る | Zotero API |
| 6 | abstractを要約する | LLM |
| 7 | 結果をTelegramへ返す | Telegram Bot |
参考：TelegramからDOIを送りZoteroへ登録するn8n公式テンプレート
https://n8n.io/workflows/7676-import-research-papers-from-telegram-to-zotero-with-ai-abstract-summaries/
このタイプの自動化で重要なのは、メタデータ取得元を複数持つことです。Crossrefだけで十分な場合もありますが、DataCiteやUnpaywallを組み合わせることで、DOIの種類やオープンアクセスPDFの有無に対応しやすくなります。ただし、提供情報の範囲では、すべての論文でPDFが取得できるとは限りません。
🧠 DOI登録ワークフローの向き不向き
| 向いているケース | 向いていない可能性があるケース |
|---|---|
| 論文をよくスマホで見つける | すでにZotero Connectorだけで十分 |
| DOIリンクを大量に保存する | DOIがない資料が多い |
| 要約も同時に見たい | PDF添付を必ず成功させたい |
| 研究チームで共有したい | APIキー管理が難しい環境 |
| Telegramを日常的に使う | Telegramを使っていない |
Zotero登録系のワークフローでは、重複登録にも注意が必要です。同じDOIがすでにZoteroにある場合、新規作成してしまうとライブラリが散らかります。n8n側で事前にDOIやタイトルを検索し、既存アイテムがあれば更新やスキップにする設計が望ましいです。
また、abstract要約は便利ですが、要約結果をそのまま論文の結論として扱うのは避けたほうがよいです。LLM要約は短時間で概要をつかむには役立ちますが、研究判断では原文確認が必要になる場面もあります。記事としては、Zotero登録と要約は「読む前の整理」を助けるものと考えるのが現実的です。
ZoteroのハイライトはRAG化すると第二の脳として使いやすい
Zoteroに保存した論文は、読むだけでなく、ハイライトやメモを残していくほど価値が増えます。ただし、文献数が増えると「どの論文に何を書いたか」を思い出せなくなりがちです。そこで出てくるのが、n8nとRAGを組み合わせる発想です。
RAGとは、簡単にいうと自分の資料を検索してからAIに答えさせる仕組みです。Zoteroのハイライトやノートをテキストとして取り出し、短い塊に分け、ベクトルという検索しやすい形に変換して保存します。質問すると、関連するメモを先に取り出し、それをもとにAIが回答します。
Mediumの記事では、Zoteroのハイライトやノートを1つのテキストファイルとしてエクスポートし、n8nで区切り文字を使って論文ごとにグループ化し、長い場合は分割して、OpenAIの埋め込みモデルとSupabase Vector Storeに保存する流れが紹介されています。
参考：Zoteroハイライトをn8nとRAGで第二の脳にする記事
https://medium.com/@yongjinL/build-a-second-brain-from-zotero-highlights-with-n8n-and-rag-c761c2887fde
RAG化の利点は、単なる全文検索よりも「意味が近い情報」を探しやすい点です。たとえば「授業中の動機づけについて何を読んだか」と聞いたとき、完全一致する単語がなくても、近い内容のハイライトが見つかる可能性があります。
🧠 ZoteroハイライトRAGの構成
| 工程 | 内容 | 目的 |
|---|---|---|
| エクスポート | Zoteroからハイライトやノートを出す | 入力データを作る |
| グループ化 | 論文ごとに分ける | 文脈を保つ |
| 分割 | 長い文章を小さくする | 検索精度を上げる |
| 埋め込み | テキストをベクトル化する | 意味検索できるようにする |
| 保存 | Supabaseなどに入れる | 後から検索する |
| 質問 | チャットUIから聞く | 回答を得る |
記事内では、2,000文字を超えるグループは200文字の重なりを持たせて分割する例が紹介されています。これは、分割によって文脈が途切れすぎるのを避けるための工夫です。ただし、最適な文字数は資料の種類や言語によって変わるため、一般的にはログを見ながら調整する必要があります。
⚙️ RAG設計で調整する項目
| 調整項目 | 小さくすると | 大きくすると |
|---|---|---|
| チャンクサイズ | 細かく検索できる | 文脈を保ちやすい |
| オーバーラップ | 重複は減る | 文脈切れを防ぎやすい |
| 区切り文字 | 厳密に分けやすい | 柔軟に扱える |
| 埋め込みモデル | コストを抑えやすい | 品質が上がる場合がある |
| 検索件数 | ノイズが減る | 見落としを減らせる |
n8nを使うメリットは、こうした調整をノード単位で見える化できることです。コードだけで作る場合より、どこで分割しているか、どのモデルを使っているか、どのDBへ保存しているかを後から確認しやすくなります。
一方で、RAG化は最初から完璧に作ろうとすると重くなります。まずは数本の論文ハイライトだけで試し、「質問に対して欲しいメモが出てくるか」を確認するのがよいです。Zoteroの全文PDFではなく、まず自分が線を引いたハイライトから始めると、回答の密度が高くなりやすいかもしれません。
NotionやGoogle Sheets連携ではZoteroを情報の親にすると破綻しにくい
Zoteroの文献情報をNotion、Coda、Airtable、Google Sheetsなどへ流したい人も多いはずです。調査した記事ではMakeを使ったZoteroとNotionの同期が紹介されていましたが、考え方はn8nにも応用できます。重要なのは、Zoteroを文献情報の親データとして扱い、NotionやSheetsは見やすく扱うための作業場所にすることです。
Notion連携の記事では、Zoteroで参照文献を保存し、Notion側で論文執筆やメモ管理をしやすくする使い方が説明されています。Zotero APIからコレクション内の文献を取得し、Notion側で既存データを検索し、あれば更新、なければ作成する流れです。
参考：ZoteroとNotionをMakeで同期する記事
https://www.simonesmerilli.com/life/zotero-notion
n8nで同じことを行う場合も、発想はほぼ同じです。HTTP RequestでZotero APIを呼び、IteratorやSplit系のノードで1件ずつ処理し、NotionやGoogle Sheetsのノードへ渡します。Notion側では、Zotero item keyやDOIを一意キーとして保存しておくと、重複を避けやすくなります。
🗂️ Zoteroと外部ツールの役割分担
| ツール | 役割 | 向いている使い方 |
|---|---|---|
| Zotero | 文献の正本 | DOI、著者、PDF、引用管理 |
| Notion | 思考と執筆の作業場 | 読書メモ、評価、関連付け |
| Google Sheets | 一覧と共有 | 進捗管理、簡易レビュー |
| Airtable | 構造化DB | 大量文献の分類 |
| Supabase | AI検索用DB | RAG、ベクトル検索 |
この分担を決めずに双方向同期を始めると、どちらの情報が正しいのか迷いやすくなります。たとえばNotion側でタイトルを修正し、Zotero側でも別の修正をした場合、次回同期でどちらを優先するかという問題が起きます。最初はZoteroから外部ツールへの片方向同期にしたほうが設計しやすいです。
🔁 同期設計の比較
| 同期方法 | メリット | 注意点 |
|---|---|---|
| Zotero → Notion | 文献情報が安定する | Notion側の修正は戻らない |
| Zotero → Sheets | 共有しやすい | 複雑なメモには弱い |
| Notion → Zotero | 作業画面から登録できる | 文献精度の担保が難しい |
| 双方向同期 | 柔軟 | 衝突処理が難しい |
| RAG用DBへコピー | AI検索しやすい | 更新・削除の反映が必要 |
Google Groupsのzotero-devでは、n8nからZotero APIを使って外部データベースへ新規文献だけ流したいという相談も確認できました。そこで重要になるのが、差分取得の考え方です。Zotero APIのsinceパラメータはタイムスタンプではなくバージョン番号を使う、という回答がありました。
参考：n8nでZoteroから新規文献だけ取得したいという相談
https://groups.google.com/g/zotero-dev/c/XRD3BuQNl4s
この点はかなり重要です。日付で「この日時以降のものだけ」と考えたくなりますが、Zotero APIの同期設計では、一般的にはバージョン番号ベースで変更を追う仕組みが使われます。実装時はZotero公式の同期ドキュメントを確認し、n8n側に「前回取得したバージョン」を保存する設計が必要になるかもしれません。
APIでデータが足りないと感じたら別アイテム取得や指定ミスを疑うべきである
n8nでZotero APIを呼んだとき、「タグやDOIなど一部のデータが返ってこない」と感じるケースがあるかもしれません。Zoteroフォーラムでは、n8nからAPIを呼んだ際に一部メタデータが取れないように見えるという質問がありました。Zoteroチーム側の回答では、APIがメタデータを省略しているというより、見ているアイテムとAPIで取得しているアイテムが違う可能性が高い、という趣旨の説明がされています。
参考：Zotero APIで全データが返らないように見える相談
https://forums.zotero.org/discussion/125081/api-call-not-returning-all-data
この話からわかるのは、n8n側で期待したデータが取れないとき、すぐに「APIの制限」と判断しないほうがよいということです。URLのitem key、collection key、ユーザーID、取得対象のアイテム種別などを確認する必要があります。
Zoteroには、親アイテム、添付ファイル、ノートなど、複数の種類のアイテムがあります。たとえばPDF添付アイテムを取得しているつもりで親文献を見ていたり、逆に親文献ではなく添付ファイル側のアイテムを取っていたりすると、期待するDOIやタグが見えないことがあります。
🔍 データ不足に見えるときの確認表
| 確認項目 | 見るポイント |
|---|---|
| USER ID | 正しいユーザーのAPIを呼んでいるか |
| item key | Zotero画面で見ている文献と一致するか |
| collection key | 対象コレクションが合っているか |
| item type | 親アイテムか添付ファイルか |
| format | JSON取得になっているか |
| 権限 | APIキーに必要な権限があるか |
特に、ZoteroのAPI結果をn8nのテーブル表示で見ると、ネストされたデータ構造が見えにくいことがあります。タイトルやDOIはdataの中にあり、タグは配列として含まれるなど、階層構造を理解する必要があります。n8nでは、SetノードやEdit Fieldsノードを使って必要な項目だけ平らにしてから次のノードに渡すと扱いやすくなります。
🧱 n8nで整形しておきたいフィールド例
| 整形後の名前 | Zotero側の想定データ |
|---|---|
| zoteroKey | item key |
| title | data.title |
| doi | data.DOI |
| year | data.date |
| creatorsText | data.creatorsを加工 |
| tagsText | tags配列を加工 |
| url | data.url |
| abstractNote | data.abstractNote |
また、Zotero APIの結果には、文献の種類によって存在しないフィールドもあります。書籍、論文、Webページ、レポートでは持っている項目が異なるため、すべてのアイテムにDOIがあるとは限りません。n8nでは、空欄のときにエラーにしない処理や、代替フィールドを見る処理を入れておくとワークフローが止まりにくくなります。
最初の検証では、1件の文献だけを対象にしてAPI結果をじっくり見るのがおすすめです。想定どおりのデータが取れることを確認してから、コレクション全体、差分取得、外部同期へ広げるほうがトラブルを減らしやすいです。
n8nとzotero活用の実装設計
- 差分取得は日時ではなくZoteroのバージョン管理を前提に考える
- PDFや添付ファイルを扱うならn8nのバイナリデータ仕様を理解する必要がある
- n8n difyと比べるならZotero連携は研究データの入口として使い分ける
- ファイル分類からZotero取り込みまで広げると研究資料整理の自動化になる
- LLM要約は便利だがZotero登録前後の補助として扱うのが現実的である
- 小さく始めるなら「取得」「整形」「保存」の3ノード設計がよい
- 総括：n8n zoteroのまとめ
差分取得は日時ではなくZoteroのバージョン管理を前提に考える
n8nとZoteroを本格的に連携すると、必ず出てくるのが「新しく追加された文献だけ取りたい」という要望です。毎回全件取得してNotionやSheetsへ流すだけなら簡単ですが、文献数が増えると重くなり、重複や更新漏れも起きやすくなります。
zotero-devのGoogle Groupsでは、n8nからZotero APIを使ってGoogle Sheetsへ新規文献だけ送りたいという相談がありました。相談者はsinceに日時を入れようとしていましたが、Zotero側の回答では、sinceはタイムスタンプではなくバージョン番号を取るという説明がされています。
参考：Zotero APIのsinceはタイムスタンプではなくバージョン番号
https://groups.google.com/g/zotero-dev/c/XRD3BuQNl4s
この点は、n8nでZotero同期を作るうえでかなり重要です。一般的な業務システムでは「updated_atが前回以降のデータを取る」と考えがちですが、Zoteroの効率的な同期ではバージョン番号を使う設計になります。つまり、n8n側で前回のバージョンを保存しておき、次回はそのバージョン以降の変更を取る、という考え方です。
🕒 差分取得で混同しやすい考え方
| 考え方 | 使い方 | 注意点 |
|---|---|---|
| タイムスタンプ | 2026-05-19以降など | Zoteroのsince用途とは異なる |
| バージョン番号 | 前回同期時点の番号 | Zotero API同期で重要 |
| dateAdded | 文献が追加された日 | 並び替えには使える |
| dateModified | 文献が変更された日 | 補助的に確認できる |
| item key | 文献単位の識別子 | 重複防止に使える |
n8nで差分取得を実装する場合、どこに前回のバージョン番号を保存するかを決める必要があります。小規模ならn8nのStatic Dataや外部のGoogle Sheets、Notion、簡単なDBなどでもよいかもしれません。安定運用を考えるなら、同期状態だけを保存する専用テーブルを用意するのも選択肢です。
💾 同期状態の保存先候補
| 保存先 | 向いているケース | 注意点 |
|---|---|---|
| n8n Static Data | 小規模・単一ワークフロー | 移行時に注意 |
| Google Sheets | 状態を目で確認したい | 手修正リスクあり |
| Notion | 既にNotion運用がある | API制限に注意 |
| Supabase | RAGやDB運用もする | 初期設定が必要 |
| ローカルファイル | 自ホストで簡単に保存 | バックアップが必要 |
差分同期では、追加だけでなく更新と削除も考える必要があります。Notion連携の記事では、Zoteroで削除された文献をNotion側でも削除するには、Zoteroのtrash系エンドポイントを見て、Notion側の対応データを削除する流れが紹介されています。n8nで同じことをする場合も、削除をどう扱うかは事前に決めておくべきです。
ただし、最初から削除同期まで入れると複雑になります。まずは「追加と更新だけ同期」「削除は手動確認」でも十分な場合があります。研究文献は誤削除の影響が大きいので、最初は削除せずアーカイブ扱いにする設計も現実的です。
PDFや添付ファイルを扱うならn8nのバイナリデータ仕様を理解する必要がある
Zotero連携で文献メタデータだけを扱うなら、n8nのHTTP RequestでJSONを取得すれば済みます。しかし、PDF添付やファイルアップロードまで扱う場合は、n8nのバイナリデータの理解が必要になります。
n8n Communityでは、HTTP RequestノードでPDFのようなバイナリファイルを送る方法について相談がありました。回答では、Send Bodyを有効にし、Body Content TypeをForm-Dataにして、Parameter Typeにn8n Binary Fileを選ぶ方法が説明されています。サーバー側が期待する形式によっては、Form-Dataではなくバイナリファイルそのものを送る場合もあるようです。
参考：n8n HTTP Requestでバイナリデータを扱う相談
https://community.n8n.io/t/how-to-use-binary-data-in-http-request/94724
ZoteroにPDFを添付するワークフローを考えると、PDFのURLを添付するだけでよい場合と、実ファイルをダウンロードしてアップロードする場合があります。提供データ内のTelegram連携テンプレートでは、利用可能なPDFリンクを探してZoteroに添付する流れが紹介されていますが、すべてのケースでフルテキストPDFが得られるとは限りません。
📎 PDF処理のパターン
| パターン | 内容 | 難易度 |
|---|---|---|
| PDF URLを保存 | Zoteroにリンク情報を残す | 低 |
| PDFをダウンロード | n8nでPDFを取得する | 中 |
| PDFをZoteroに添付 | APIやCLIで添付する | 中〜高 |
| PDFをOCRする | テキスト抽出する | 高 |
| PDFをRAG化する | 分割・埋め込み・保存する | 高 |
ファイル処理でつまずきやすいのは、n8nのノード間でバイナリデータのフィールド名が変わることです。あるノードではdataという名前で存在していたPDFが、SwitchやMergeを通したあとに参照できなくなることがあります。Communityの関連トピックにも、SwitchやMerge後にバイナリがundefinedになる話題が見られます。
🧪 バイナリデータ処理の確認ポイント
| 確認項目 | 内容 |
|---|---|
| Binary Property名 | 通常はdataなど |
| 前ノードの出力 | バイナリが残っているか |
| Merge/Switch後 | フィールドが消えていないか |
| Content Type | form-dataかraw binaryか |
| ファイル名 | 添付時に必要か |
| サーバー側仕様 | どの名前で受け取るか |
ZoteroへのPDF取り込みを安定させたいなら、最初はAPIだけで完結させようとせず、Zotero CLIや既存ツールを使う方法も検討できます。提供データのファイル分類記事では、Zotero向けにzt importやzt create:item、zt attachのようなCLIコマンドを使う構成が紹介されています。ただし、その記事内のztはカスタムCLIと説明されているため、一般環境でそのまま使えるとは限りません。
PDFを扱うワークフローは便利ですが、メタデータ取得よりも失敗要因が増えます。まずは文献メタデータだけを安定させ、その後にPDFリンク、最後に実ファイル添付へ進むほうが、ワークフロー全体を壊しにくいです。
n8n difyと比べるならZotero連携は研究データの入口として使い分ける
関連検索ワードとして「n8n dify」が出ていることから、n8nとDifyを比較しながら、Zotero連携を考えている人もいるはずです。提供データ内にDifyそのものの詳しい情報はありません。そのため断定は避けますが、一般的には、n8nはワークフロー自動化、DifyはAIアプリやチャットボット構築寄りのツールとして比較されることが多いです。
n8n zoteroの文脈では、n8nはZoteroからデータを取り出す、加工する、別の場所へ流す部分に向いています。一方、DifyのようなAIアプリ基盤は、おそらく「ユーザーが質問する画面」や「ナレッジベースに対する回答生成」に向いている可能性があります。
つまり、n8nとDifyは競合というより、役割を分けて考えたほうが自然です。n8nがZoteroのデータを収集・整形・同期し、Difyや別のAIチャット基盤がそのデータを使って回答する、という構成が考えられます。
🤖 n8nとDifyを比べる視点
| 観点 | n8n | Dify |
|---|---|---|
| 主な役割 | 自動化ワークフロー | AIアプリ構築 |
| Zotero API取得 | 向いている | 直接は要確認 |
| データ整形 | ノードで柔軟に処理 | 用途次第 |
| チャットUI | n8nにも可能性あり | 得意な可能性あり |
| RAG基盤 | Supabase等と接続 | ナレッジ機能がある可能性 |
| 運用思想 | パイプライン | AIアプリ |
ZoteroのハイライトをRAG化するMedium記事では、n8n内でチャットトリガーを使い、「Second Brain」として質問できるUIを作る流れが紹介されています。つまり、Difyを使わなくてもn8nだけで簡易的な第二の脳は作れる可能性があります。
参考：n8nでZoteroハイライトをRAG化する事例
https://medium.com/@yongjinL/build-a-second-brain-from-zotero-highlights-with-n8n-and-rag-c761c2887fde
ただし、実際に研究室やチームで長く使うなら、UI、権限管理、会話履歴、ナレッジ更新、回答の引用表示なども考える必要があります。n8nだけで十分なケースもあれば、DifyのようなAIアプリ基盤と組み合わせたほうが見やすいケースもあるかもしれません。
🧭 使い分けの目安
| やりたいこと | 向いている構成 |
|---|---|
| Zoteroから文献を取得 | n8n |
| DOIからZoteroへ登録 | n8n |
| NotionやSheetsへ同期 | n8n |
| ハイライトをベクトルDBへ保存 | n8n + DB |
| 研究メモにチャットで質問 | n8n単体またはDify等 |
| チーム向けAIアプリ化 | Dify等も検討 |
n8n difyを比較している人は、最初に「どちらが優れているか」ではなく、「Zoteroデータの入口を誰が担当し、回答画面を誰が担当するか」で考えると整理しやすいです。n8n zotero連携は、少なくともデータ取得と自動化の入口として非常に相性がよい領域だといえます。
ファイル分類からZotero取り込みまで広げると研究資料整理の自動化になる
Zotero連携をさらに広げると、単に文献APIを読むだけでなく、PC上のPDFやダウンロードファイルを自動分類してZoteroへ取り込む方向にも発展できます。提供データの中には、n8nとUpstage APIを使ってDownloads、Documents、Desktopのファイルを分類し、PDFはZotero、画像や動画はEagle、その他はDEVONthinkへ振り分ける事例がありました。
この事例では、ファイルを10分ごとにスキャンし、PDFはZoteroへ、画像・動画はEagleへ、その他の資料はDEVONthinkへ送る構成が説明されています。ZoteroはPDFの保管先として位置づけられ、ファイル名の整形やフォルダ分類にはAIが使われています。
参考：n8nとUpstageでファイルを分類しZoteroなどへ取り込む事例
https://berom.net/Articles/Taming-the-Folder-Hell-with-Upstage-and-N8N
このタイプの自動化は、研究者や学生だけでなく、資料を大量に扱う人にとっても役立ちます。ダウンロードフォルダに論文PDF、スクリーンショット、レポート、請求書、スライドなどが混ざってしまう問題を、n8nの定期実行で整理する発想です。
🗃️ ファイル分類ワークフローの全体像
| 段階 | 処理 | 目的 |
|---|---|---|
| スキャン | Downloadsなどを確認 | 新規ファイルを見つける |
| 事前フィルター | 隠しファイルや壊れたPDFを除外 | 無駄な処理を減らす |
| 拡張子判定 | PDF、画像、動画などに分ける | 送信先を決める |
| テキスト抽出 | PDFや画像から内容を読む | 分類精度を上げる |
| AI分類 | フォルダやファイル名を決める | 整理を自動化 |
| インポート | Zoteroなどへ登録 | 保管する |
| ログ記録 | 成否を残す | 運用確認する |
この事例で特に参考になるのは、最初にファイルをステージング領域へ移動する設計です。ファイルを見つけてから処理が終わるまでの間に、別アプリがファイル名を変えたり移動したりするとエラーになります。そのため、発見したファイルを一時フォルダへ移し、そこから処理することで安定性を上げています。
🛡️ 安定運用の工夫
| 工夫 | 理由 |
|---|---|
| ステージングへ移動 | 処理中のファイル消失を防ぐ |
| PDF数に上限 | OCRやAPI処理の重さを抑える |
| 10分間隔実行 | 重複実行を避けやすい |
| フォルダリストをキャッシュ | 毎回取得する負荷を減らす |
| 失敗時はInboxへ移動 | 手動確認できる |
| JSONLログを残す | 後から原因を追える |
ただし、この事例に出てくるzt、eg、dtといったCLIはカスタムツールと説明されています。つまり、読者の環境でそのまま同じコマンドが使えるとは限りません。考え方としては参考になりますが、実装時は自分の環境で利用可能なZotero取り込み手段を確認する必要があります。
ファイル分類型の自動化は魅力的ですが、いきなり全フォルダを対象にすると危険です。まずはテスト用フォルダを作り、数個のPDFだけで動作確認するのがよいです。成功時に削除する設計も便利ですが、初期段階では削除ではなく「処理済みフォルダへ移動」にしておくと安心です。
LLM要約は便利だがZotero登録前後の補助として扱うのが現実的である
n8n zotero連携では、LLMを使った要約もよく組み合わせられます。TelegramからDOIを送ってZoteroに登録するテンプレートでは、abstractをLLMで短く要約し、Telegramへ返す構成が紹介されています。これにより、論文を登録した直後に概要をつかめます。
LLM要約の便利な点は、読む前の判断を速くできることです。タイトルとabstractだけでは読むべきか迷う論文でも、短い要約が返ってくれば、今すぐ読むか、あとで読むか、Zoteroに保存だけするかを判断しやすくなります。
一方で、LLM要約は補助として扱うのが現実的です。abstractだけを要約している場合、本文全体の主張や限界までは十分に反映されない可能性があります。また、モデルによって表現やニュアンスが変わるため、重要な引用や研究判断では原文確認が必要です。
📝 LLM要約の使いどころ
| 使いどころ | 期待できる効果 |
|---|---|
| DOI登録直後 | 読む優先度を決めやすい |
| abstract整理 | 内容を短く把握できる |
| Telegram返信 | スマホで確認しやすい |
| Notion同期 | メモ欄を初期化できる |
| RAG前処理 | 大まかな分類に使える |
Zotero連携でLLMを使う場合、どのタイミングで要約するかも設計ポイントです。登録前に要約するなら、保存する価値があるかを判断できます。登録後に要約するなら、Zotero item keyと紐づけて外部ツールへ保存しやすくなります。RAG化するなら、要約だけでなく元のハイライトやabstractも保存したほうが回答の根拠を保ちやすいです。
⚖️ 要約タイミングの比較
| タイミング | メリット | 注意点 |
|---|---|---|
| Zotero登録前 | 保存前に選別できる | 後から追跡しにくい |
| Zotero登録後 | item keyと紐づく | 処理数が増える |
| Notion同期時 | 作業画面に表示しやすい | 更新時の再要約が必要 |
| RAG投入時 | 検索補助になる | 要約だけでは情報が薄い |
| 質問時 | 文脈に合わせて要約できる | コストが増えやすい |
LLM要約をZoteroのどこに保存するかも悩みどころです。Zoteroのノートとして保存する方法、Notion側に保存する方法、Google Sheetsに要約列を作る方法、RAG用DBにメタデータとして保存する方法があります。どれがよいかは運用次第ですが、Zoteroを文献情報の親にするなら、要約は外部作業場に置くほうが管理しやすい場合もあります。
LLM要約を使うときは、プロンプトも重要です。「3行で要約」だけではなく、「研究目的」「方法」「結果」「限界」を分けて出すようにすると、後から比較しやすくなります。ただし、提供データ内では具体的なプロンプトまでは示されていないため、ここは一般的な設計上の提案です。
小さく始めるなら「取得」「整形」「保存」の3ノード設計がよい
n8n zotero連携を始めると、DOI登録、PDF添付、RAG、Notion同期、差分取得など、やりたいことが増えがちです。しかし最初から全部を作ると、どこで失敗しているのかわからなくなります。小さく始めるなら、取得・整形・保存の3段階だけで十分です。
最初のワークフローは、Zotero APIから特定コレクションの文献を取得し、必要なフィールドだけ整形し、Google SheetsやNotionに保存する構成がわかりやすいです。この構成なら、API認証、データ構造、外部同期の基本を一気に確認できます。
n8n公式テンプレートでも、最後の2ノードを編集・削除して出力をパーソナライズできると説明されています。つまり、テンプレートをそのまま完成品として使うより、自分の必要なフィールドに合わせて編集する前提で見るとよいです。
🧩 最小ワークフロー設計
| ノード | 役割 | 確認すること |
|---|---|---|
| HTTP Request | Zotero APIから取得 | 認証とURLが正しいか |
| Edit Fields / Set | 必要項目だけ整形 | title、DOI、tagsなど |
| Notion / Sheets | 保存する | 重複せず入るか |
この3段階が動いたら、次に分岐や差分取得を足していきます。たとえば、タグに「important」がある文献だけNotionへ送る、DOIが空のものは別シートへ送る、abstractがあるものだけLLM要約する、といった拡張です。
🚦 段階的な拡張順
| 段階 | 追加する機能 |
|---|---|
| 1 | 特定コレクションの全件取得 |
| 2 | 必要フィールドの整形 |
| 3 | NotionやSheetsへ保存 |
| 4 | item keyで重複チェック |
| 5 | 前回同期との差分取得 |
| 6 | DOI登録やPDF処理 |
| 7 | LLM要約 |
| 8 | RAG化 |
n8nでは、ワークフローが複雑になるほど、ノード名の付け方が重要になります。「HTTP Request」だけでは後から何をしているかわからないため、「Get Zotero Collection Items」「Normalize Zotero Fields」「Upsert Notion Reference」のように、処理内容がわかる名前にすると管理しやすくなります。
また、エラー時の扱いも初期段階で決めておくとよいです。APIキーが切れた、Zotero APIのレスポンスが変わった、同期先のNotion DB項目名が変わった、PDFが取れなかった、などの失敗は起こりえます。最低限、失敗した文献のitem keyやタイトルをログに残すだけでも、あとから修正しやすくなります。
最終的には、n8n zotero連携は「一度作って終わり」ではなく、研究スタイルに合わせて育てるワークフローです。最初はシンプルに、動くことを確認しながら、必要な自動化だけを追加していくのが長続きしやすいです。
総括：n8n zoteroのまとめ
最後に記事のポイントをまとめます。
- n8n zotero連携の基本は、Zotero APIをn8nのHTTP Requestで呼び出すことである。
- 最初に必要なのは、ZoteroのUSER ID、Private Key、対象コレクションのKEYである。
- 文献取得は、ライブラリ全体よりコレクション単位で始めるほうが扱いやすい。
- Zoteroを文献情報の親、NotionやSheetsを作業用の表示先として分ける設計がよい。
- TelegramからDOIやarXiv IDを送れば、メタデータ取得からZotero登録まで自動化できる。
- Crossref、DataCite、Unpaywallなどを組み合わせると、文献情報やPDF候補を拾いやすい。
- Zoteroのハイライトやメモは、n8nとRAGを組み合わせるとAI検索に使いやすい。
- 差分取得では、日時ではなくZoteroのバージョン番号を前提に考える必要がある。
- API結果にデータが足りないように見える場合は、item keyや親アイテムと添付アイテムの違いを確認すべきである。
- PDFや添付ファイルを扱う場合は、n8nのバイナリデータ仕様を理解する必要がある。
- n8n difyを比較するなら、n8nはZoteroデータ取得と整形、DifyはAIアプリ側として役割分担を考えるとよい。
- LLM要約は便利だが、研究判断の最終根拠ではなく、読む前後の補助として扱うべきである。
- 最初の実装は「取得」「整形」「保存」の3段階に絞るのが現実的である。
- 運用を広げる場合は、ログ、重複判定、失敗時のInbox退避、削除同期の方針を決める必要がある。
記事作成にあたり参考にさせて頂いたサイト
- https://n8n.io/workflows/2444-get-bibliographic-data-from-your-zotero-library/
- https://medium.com/@yongjinL/build-a-second-brain-from-zotero-highlights-with-n8n-and-rag-c761c2887fde
- https://n8n.io/workflows/7676-import-research-papers-from-telegram-to-zotero-with-ai-abstract-summaries/
- https://forums.zotero.org/discussion/125081/api-call-not-returning-all-data
- https://www.reddit.com/r/macapps/comments/1k68jh4/how_i_supercharged_my_phd_workflow_with_zotero/
- https://www.simonesmerilli.com/life/zotero-notion
- https://www.reddit.com/r/zotero/comments/1ofy944/a_new_zotero_plugin_to_support_multilingual/
- https://groups.google.com/g/zotero-dev/c/XRD3BuQNl4s
- https://community.n8n.io/t/how-to-use-binary-data-in-http-request/94724
- https://berom.net/Articles/Taming-the-Folder-Hell-with-Upstage-and-N8N
各サイト運営者様へ
有益な情報をご公開いただき、誠にありがとうございます。
感謝の意を込め、このリンクはSEO効果がある形で設置させていただいております。
※リンクには nofollow 属性を付与しておりませんので、一定のSEO効果が見込まれるなど、サイト運営者様にとってもメリットとなれば幸いです。
当サイトは、インターネット上に散在する有益な情報を収集し、要約・編集してわかりやすくお届けすることを目的としたメディアです。
私たちは、情報の収集や整理を通じて「情報をまとめてわかりやすく伝える」という形で新たな価値を提供できるのではないかと考え、運営しております。
なお、引用や参照の方法には不備、あるいはご不快に感じられる点がございましたら、迅速に対応いたしますので、お手数ですがお問い合わせフォームよりご連絡いただければ幸いです。
今後とも、どうぞよろしくお願いいたします。
当サイトでは、インターネット上に散らばるさまざまな情報を収集し、AIを活用しながら要約・編集を行い、独自の切り口で見解を交えながらわかりやすい形でお届けしています。
情報の整理・編集にあたっては、読者やオリジナル記事の筆者へご迷惑をおかけしないよう、細心の注意を払って運営しておりますが、万が一、掲載内容に問題がある場合や修正・削除のご要望がございましたら、どうぞお気軽にお問い合わせください。
迅速に対応をさせていただきます。
その際には、該当記事の URLやタイトルをあわせてお知らせいただけますと、より速やかに対応 することができますのでそちらもご協力いただけますと大変幸いでございます。
今後とも当サイトをよろしくお願いいたします。
