百度网盘と AList で Zotero の添付ファイルを同期する

以前はずっと、坚果云を使って Zotero の添付ファイルを同期していた。一度設定すれば、あとはほぼ放っておけるし、別のパソコンに切り替えてもスムーズに使える。ただ、無料アカウントの転送量では次第に足りなくなってきた。

坚果云のヘルプセンターによると、無料アカウントで毎月使える転送量は、アップロードが 1 GB、ダウンロードが 3 GB。普段、論文を数本ずつ追加する程度なら問題ないが、添付ファイルがたまっていたり、別の端末でまとめてダウンロードし直したりすると、すぐに上限が気になってくる。

少し前にMacBook Pro を買い替えたのだが、新しいパソコンで添付ファイルを同期したら、その月の転送量をあっという間に使い切ってしまった。翌月まで待っても、初日にまた上限に達してしまう。さすがにこのままでは使い続けられなかった。

そこで、また代わりの方法を探し始めた。いろいろ探しても、しっくりくるものが見つからない。論文を同期するためだけに、さらにお金を払うのも避けたかった。

そこで思い出した。もともと百度网盘の有料会員だし、AList もずっと使っている。この二つを組み合わせれば、Zotero の WebDAV 同期をそのまま使えるのではないか。

意外だったのは、AList の百度网盘への接続を、長いことメンテナンスしていなかったのに、まだ使えたことだ。数か月だったか、1 年だったか、それ以上だったか、もう覚えていない。久しぶりに開いてみたら、ちゃんとアクセスできた。接続が生きているなら、試してみよう。

「プラグイン＋フォルダー同期」を選ばなかった理由

Zotero には、添付ファイルを決まったフォルダーに移し、そのフォルダーをクラウドストレージのクライアントで同期する、という定番の方法もある。以前の ZotFile や、今の ZotMoov は、こうした添付ファイルの管理を助けてくれる。ここで必要なのはフォルダーの同期だ。単にファイルをバックアップするだけでは、別のパソコンのファイルまで自動で同じ状態になるわけではない。

この方法では通常、添付ファイルを「リンクファイル」にする。Zotero はファイルの場所だけを記録し、ファイルそのものは別のソフトで管理する仕組みだ。両方のパソコンでフォルダー同期を設定し、それぞれの添付ファイルのパスを Zotero が見つけられるようにする必要がある。両方で新しい添付ファイルを自動的に外部フォルダーへ移したいなら、プラグインもそれぞれ設定しなければならない。ただし、すでにリンクされているファイルを開くだけなら、すべてのパソコンに同じプラグインを入れる必要はない。

これでも目的は果たせるが、私には気を配るところが少し多い。特に、Zotero の公式モバイルアプリはリンクファイルに対応していないし、Zotero 標準のファイル同期でもアップロードされない。パソコン側のフォルダーを整えたからといって、iPad やスマートフォンの公式アプリでもそのまま使えるわけではない。

できれば、これまでの使い方を変えたくなかった。いつもどおり Zotero に添付ファイルを取り込み、別の端末を開いたら、同期されるのを待つだけで済む形がいい。

添付ファイルの保存先だけを変え、Zotero 標準の同期は残す

まず、「同期」を分けて整理しておく。Zotero のデータ同期とファイル同期は別の仕組みだ。

つまり、坚果云を使っていたときも、Zotero のライブラリ全体を坚果云に預けていたわけではない。文献データは引き続き Zotero アカウント経由で同期し、坚果云は主に添付ファイルを担当していた。今回はその部分だけを、AList が提供する WebDAV に置き換える。

内蔵リーダーの注釈は Zotero のデータベースに保存されるので、普段のハイライトやメモのたびに PDF 全体を送り直す必要はない。外部のリーダーで PDF を直接書き換えた場合には、その変更を添付ファイルとともに同期する必要がある。

WebDAV はもともと Zotero が対応しているファイル同期の方式なので、添付ファイル同期用のプラグインを別途入れる必要はない。公式の iOS・Android アプリでも使える。ただし、Zotero Storage とまったく同じではない。WebDAV が扱うのは個人ライブラリだけで、グループの添付ファイルには引き続き Zotero Storage が必要だ。また、Zotero のウェブライブラリから、この WebDAV 上の添付ファイルを直接開くことはできない。私が「公式の同期とあまり変わらない」と言うのは、主にクライアントで個人ライブラリを日常的に使うときの話だ。

いちばん大事なのは、AList サーバーを経由させること

マウントできたからといって、Zotero ですべての添付ファイルを問題なくダウンロードできるとは限らない。分かるのは、AList から百度网盘にアクセスできるということだけだ。

AList の百度网盘ドキュメントによると、該当するダウンロード API を使う場合、おおむね 20 MB を超えるファイルのリクエストに必要なヘッダーは User-Agent: pan.baidu.com。これはダウンロードのリクエストの話であって、「大きなファイルをアップロードするときは必ず UA を変更する」という意味ではない。ファイルサイズについても、ドキュメントに示された経験上の目安であり、今後も変わらないルールではないと考えたほうがよい。

WebDAV で 302 リダイレクトを使うと、AList は実際のダウンロード URL をクライアントに渡す。その後はクライアントが百度网盘から直接ファイルをダウンロードする。添付ファイルは AList サーバーを経由しないので、サーバーの帯域は節約できるが、必要なリクエストヘッダーはクライアント側で付けなければならない。

Zotero の通常の同期設定には、UA を入力する欄がない。添付ファイルの同期のために、さらに Surge のようなネットワークツールでリクエストを書き換え、端末ごとに設定するのは、考えるだけでも少し面倒だ。

そこで選んだのが、WebDAV のローカルプロキシだ。ここでいう「ローカル」は、AList を動かしているサーバーを指す。クライアントは AList にだけ接続し、AList が百度网盘にファイルをリクエストして、それをクライアントへ送る。AList の百度网盘ドライバーは、公式 API で生成したダウンロードリンクに、必要な UA の情報を付ける。プロキシ側のリクエストがその情報を使うので、Zotero 自体でヘッダーを書き換える必要はない。

二つの経路を並べると、違いが分かりやすい。

図：上の 2 段は、データと添付ファイルの転送経路。302 の段は、操作の順に左から右へ読む。最後は百度网盘から Zotero へ直接添付ファイルが送られ、AList は経由しないため、クライアント側で UA の要件を満たす必要がある。302 との比較はダウンロードのみで、アップロードはどちらも AList を経由する。

特に注意したいのは、AList の「Web プロキシ」と「WebDAV ポリシー」は別々の設定だという点だ。前者はウェブ上のプレビューやダウンロードなどに影響するが、Zotero が使うのは後者だ。「Web プロキシ」を有効にするだけでは、Zotero 用の中継設定を済ませたことにはならない。設定については、公式の WebDAV ポリシーの説明を参照してほしい。

具体的な設定方法

以下では AList の導入が済んでいることを前提に、私のドメイン pan.xxu.do とマウントパス /Baidu を例に説明する。実際に設定するときは、自分のドメインとマウントパスに置き換えてほしい。バージョンによって画面の表記は多少異なる場合がある。

1. 百度网盘をマウントする。AList の百度网盘ドキュメントに沿って認証を済ませる。ダウンロード API で選ぶのは Official。私が AList で使っているマウントパスは /Baidu。まず、このフォルダーのファイル一覧が正常に表示され、アップロードとダウンロードもできることを確認してから、Zotero の設定に進む。
2. このストレージの WebDAV ポリシーを「ローカルプロキシ」にする。画面によっては「本机代理」または「本地代理」と表記されているが、どちらも AList のサーバーを経由させる設定だ。ここでは 302 は選ばず、別のダウンロード用プロキシサーバーを指定する必要もない。
3. Zotero 専用の AList アカウントを用意する。同期フォルダー内のファイルを読み取り、作成・アップロード、更新、削除できるようにする。AList のドキュメントでは「Webdav 読み取り」と「Webdav 管理」を有効にし、対応する基本的なファイル操作の権限も設定するよう求められている。読み取り専用アカウントでは同期できない。新しい AList では、操作できるフォルダーをロールのスコープで制限する。「基本パス」を変えるだけでは権限の制限にはならない。詳しい項目名は、WebDAV ドキュメントとユーザー権限の説明を参照してほしい。
4. 利用できる HTTPS の URL を用意する。私の AList の URL は https://pan.xxu.doで、同期するすべての端末からアクセスできる必要がある。公式モバイルアプリには平文 HTTP の利用に制限があるので、有効な証明書を使った HTTPS にしておくほうが手間がかからない。理由は Zotero の説明を参照してほしい。
5. Zotero で WebDAV を選ぶ。まず自分の Zotero アカウントでログインし、「設定 → 同期」を開く。「マイライブラリ」の添付ファイルの同期方式を WebDAV に変更し、AList の URL と、先ほど用意した AList のユーザー名・パスワードを入力する。ここで使うのは百度アカウントでも、Zotero アカウントのパスワードでもない。

AList の WebDAV のエンドポイントは /dav/。このアカウントで WebDAV にアクセスしたときのルートフォルダーが AList の / に対応している場合、私のドメインと /Baidu のマウントを使うと、URL は次のようになる。

スクリーンショットでは、URL 入力欄の右側に、あらかじめ /zotero/ と表示されている。これは Zotero が自動的に追加する部分だ。プロトコルには https を選び、アドレス欄には pan.xxu.do/dav/Baidu だけを入力する。末尾に手動で zotero を付け足してはいけない。Baidu の大文字・小文字はマウントパスと一致させる。アカウントの WebDAV ルートがすでに /Baidu に割り当てられている場合は、アドレス欄には pan.xxu.do/dav だけを入力し、マウントパスを重ねて追加しない。

入力したら「サーバーを検証」をクリックし、検証に通ってから同期を始める。URL の追加ルールや設定項目は、Zotero の同期設定ドキュメントで確認できる。

既存の添付ファイルを移すときは、もうひと確認

坚果云から移行する際、WebDAV の URL を変えれば、古いサービスにある添付ファイルも自動で新しいサービスへ移る、と思ってはいけない。特に、それまで「必要に応じてダウンロード」を選んでいた場合、手元にはアイテムしかなく、PDF は古いサービスに残っている可能性がある。

安全を期すなら、まず 1 台のパソコンで古い設定を残したまま、添付ファイルのダウンロード方法を「同期時にダウンロード」に変える。ダウンロードが完了するのを待ち、既存の添付ファイルが開けるか確認する。Zotero を終了し、データフォルダーを別途バックアップしてから WebDAV の URL を切り替え、そのパソコンからローカルの添付ファイルを新しい保存先へ同期する。別の端末でも確認が取れるまでは、古いサービスのファイルを残しておく。

もともとリンク添付ファイルを使っていた場合は、「ツール → 添付ファイルを管理」から保存済み添付ファイルに変換する必要もある。そうして初めて WebDAV の同期対象になる。Zotero のデータフォルダー全体をクラウドストレージのクライアントでリアルタイム同期するのは避けよう。使用中のデータベースファイルは、そのような扱いには向いていない。

「サーバーの検証に成功」しても、すべての添付ファイルをテストしたことにはならない。実際のファイルでも確認しておくのがおすすめだ。1 台の端末から、小さな PDF と、明らかに 20 MB を超える実際の添付ファイルを追加する。アップロードが終わったら、まだそのファイルを保存していない別の端末でダウンロードして開く。さらに内蔵リーダーで注釈を一つ追加し、もう一方にも反映されるか確認する。小さなファイルは問題なく、大きなファイルだけ失敗する場合は、まず WebDAV がまだ 302 経由になっていないか調べる。

アイテムは同期されたのに既存の添付ファイルが届かない場合は、まず Zotero の添付ファイル同期のトラブルシューティングに沿って、ローカルファイル、アップロード結果、両側の設定を確認する。「オンラインライブラリを置き換える」を、添付ファイルの移行手順として使ってはいけない。それは別の操作だ。

便利さと引き換えに、サーバーが通信量を引き受ける

ローカルプロキシは、クライアント側の面倒をサーバーにまとめて引き受けさせる。その分、添付ファイルの転送では必ずサーバーを通ることになる。

ダウンロード時は、ファイルが百度网盘から AList サーバーへ、さらにサーバーから端末へと送られる。アップロード時はその逆だ。どちらかの経路が遅かったり、パケットロスが多かったり、接続が不安定だったりすると、全体の使い勝手に響く。百度网盘の有料会員だからといって、この二つの経路がどちらも最高速度で動くわけではない。

帯域から速度の目安も計算できる。サーバーから端末へ送る帯域が 10 Mbps なら、理論上の上限は約 1.25 MB/s で、実際にはプロトコルのオーバーヘッドも差し引かれる。普通の論文ならさほど気にならなくても、複数の端末で同時に同期したり、ライブラリ全体を移したりするときには、はっきり差が出る。

また、プロキシ経由のダウンロードでは、サーバーが同じ添付ファイルを受信し、送信する。クラウドサーバーの通信量がどう計算されるか、送信分だけが課金されるかどうかは、契約プラン次第だ。初回に大量のファイルを移すときは、クラウドストレージの API のレート制限や、リバースプロキシのアップロードサイズ制限、タイムアウトに引っかかることもある。問題が起きたら、まずどの区間でエラーが出ているかを確認しよう。いきなり同時接続数を増やす必要はない。

そのため、この組み合わせは、すでに百度网盘の有料会員で、ネットワーク環境がよく、AList を常時動かせるマシンもある人に向いている。このためだけに有料会員になったり、サーバーを借りたりするなら、改めて費用を計算したほうがいい。私にとっての魅力は、まさにどれもすでに使っていたものだったことだ。

今のところ、使い心地は上々

設定が済んでしまえば、普段の使い方に特別なことはない。いつもどおり文献を取り込み、PDF を開き、注釈を付けて、Zotero が同期するのを待つだけだ。今のところ、同期速度は坚果云を使っていたときと大きく変わらない。保存先を変えるために、添付ファイル用のフォルダーや同期プラグインを別途管理する必要もなかった。

もちろん、これは今の私の環境での感想だ。百度网盘の API や認証、サーバーへの通信経路が、今後も変わらないとは限らない。それに、同期は独立したバックアップの代わりにはならない。

それでも少なくとも今は、坚果云の月間無料転送量を使い切って、Zotero の横に容量不足を知らせる赤い感嘆符が出ることはなくなった。すでにお金を払っていて、すでに動かしているものを活用するだけで、ずっと気になっていた小さな問題が片付いた。なかなかいい気分だ。