odriveレビュー――すべてのクラウドを統べる、ひとつの同期クライアント

「すべてを統べる、ひとつのクラウド。すべてを見つけ出す、ひとつのクラウド。すべてを束ね、暗闇の中でつなぎとめる、ひとつのクラウド」——そんな感じでしょうか。というわけで今回ご紹介するのは、世の中のさまざまなクラウドサービスに対応したユニバーサル同期クライアント「odrive」。シンプルに使えて、安全で、楽しいツールであるはずのものです。

私がこれを取り上げた理由はまさにそこにあります。正直なところ、私はクラウドストレージにさほど魅力を感じていませんでした。どのプロバイダーも見た目も挙動も似たり寄ったりで、結局のところ、自分のデータを他人の手に委ねることになるからです。それ自体が悪いわけではありませんが、ニュアンスは伝わるかと思います。そういう意味で、odriveは私にとって魅力的であると同時に、完全に不要な存在でもありました。とはいえ、前向きに考えて、何ができるのか見てみることにしましょう。

Fedoraでテスト

このソフトウェアの売りの一つがクロスプラットフォーム対応であるため、Fedora上で試してみることにしました。まずは、大手プロバイダーの既存アカウントでサインインするところから始まります。ここには少し疑問を感じます。たとえば、なぜこうした用途にFacebookログインを使う必要があるのでしょうか？　そして仮に使うとしても、なぜodriveがユーザープロフィールや公開情報、動画、画像といった情報を受け取る必要があるのでしょうか？　これは将来のマーケティング目的のための、純粋に不要なデータ収集のように聞こえてなりません。

ログインすると、非常にシンプルなコントロールパネルが表示され、20以上のプロバイダーからストレージを追加したり、共有を作成したり、暗号化フォルダを作成したりすることができます。さらに、ホストマシンとリモートストレージ間のデータ同期を有効にするクライアントソフトウェアもダウンロード可能です。

実際の動作を確かめるため、まずはDropboxを追加してみました。Dropboxにログインし、odriveによる利用を許可する流れです。ある意味、odriveはこれらのさまざまなサービスへの統合ゲートウェイと言えます。IM/VoIPサービスを一括管理するFranzのようなものだと感じました。Webのほぼあらゆる分野で技術やサービスが爆発的に増えた後の次のステップは、統合と集約なのでしょう。専門家たちが賢そうに口にしたがる「オーケストレーション」という言葉がぴったりかもしれません。

暗号化機能

暗号化フォルダも作成してみました。他の人にデータを見られたくないのであれば、理にかなった機能です。セットアップ自体は簡単でしたが、ローカルマシンのどこに、いつ、どのような形でその暗号化フォルダが現れるのかはっきりわかりませんでした。Dropbox側では確かに作成されていたものの、Fedora側には姿を現しません。

ここからが本番……

この仕組み全体の中で最も弱いリンクは、クライアントソフトウェアです。使用ガイドを見ると、コマンドライン作業が多すぎます。Windowsでさえそうです。Linuxでは、CLIツール一式をダウンロードし、それを使ってodriveをセットアップする必要があります。

od="$HOME/.odrive-agent/bin" && curl -L "https://dl.odrive.com/odrive-py" --create-dirs -o "$od/odrive.py" && curl -L "https://dl.odrive.com/odriveagent-lnx-64" | tar -xvzf- -C "$od/" && curl -L "https://dl.odrive.com/odrivecli-lnx-64" | tar -xvzf- -C "$od/"

極めてオタクじみていると感じざるを得ません。私が欲しいのは、すべてを自動で処理してくれるシンプルなツールであり、できればGUIでのセットアップが望ましいところです。しかも、必要な作業を完了させるための説明書きがひどく混乱を招くものでした。最初の行には常に漠然とした説明しかなく、Pythonスクリプトの一部はインストーラーに含まれていなかったため実際には動作せず、各コマンドの実用的な例も一切ありませんでした。

実はクライアントの起動にはnohupを使うのですが、これは正しい方法とは言えません。ソフトウェアはきちんとインストール・設定されるべきものです。systemdフレームワークを使って多数のディストリビューション向けバイナリを作成するのが大変で時間がかかる、ということなのでしょうが、やや素人っぽい解決策に思えてしまいます。

基本的なコマンドをいくつか試してみると、クライアントが認証されていないことが判明しました。まず認証キーを作成し、ノートPC上のエージェントにそれを使用させる必要があります。いわゆる標準的な秘密鍵の仕組みですね。

python "$HOME/.odrive-agent/bin/odrive.py" authenticate
b8595fe0-caf1-42dc-80fa-04bffa9dfa1d-55af68a1
Hello Johnny Cash

次に、ローカルドライブをマウントしてodriveと同期させる必要がありました。この手動プロセスには本当にうんざりさせられました。退屈で、ギーク向けで、無意味です。しかも私はPythonを使いたくないのです。

python "$HOME/.odrive-agent/bin/odrive.py" mount "$HOME/odrive-agent-mount" /
/home/roger/odrive-agent-mount is now synchronizing with odrive.

では、少し同期してみましょう。ところが、そうは問屋が卸しません。

python "$HOME/.odrive-agent/bin/odrive.py" sync "\$HOME/odrive-agent-mount/Encryptor.cloudf"
Unable to sync Encryptor.cloudf. This file is not inside an odrive folder.

なぜかodriveは私の試みを受け付けてくれません。公式フォーラムを読んでみると、odriveフォルダの内容を更新（リフレッシュ）すればよいという助言があったので、早速試してみました。しかし、何の役にも立ちませんでした。バイナリ版とPython版の違いにも注意してください。結果は変わらずです。

"$HOME/.odrive-agent/bin/odrive" refresh "$HOME/odrive-agent-mount/"
Synced
Encryptor.cloudf
Facebook.cloudf
VLC-3.0.0.gitfeb851a.glibc2.17-x86-64.AppImage
Dropbox.cloudf

「not inside an odrive folder（odriveフォルダ内にありません）」というエラーが出続け、それでおしまいでした。

まとめ

コンセプトとしては、odriveは最高です。十数個もの異なるクラウドストレージを管理する手間とオーバーヘッドから人々を解放してくれる、優れた小さなツールになる潜在力を本当に秘めています。実に素晴らしい。しかし、そのコンセプトの実装には欠陥があります。

ええ、ベータ版だとか、そんなことは重々承知しています。しかし問題は単なる成熟度の話ではありません。第一に、このアプリケーションがSNSアカウントをログインに使う理由がどうしても見当たりません。そこに価値はないのです。第二に、コマンドラインは構いませんが、それは普通の人が快適に使える安定したGUIの「補完」としてあるべきです。第三に、Wikiページ、使用ガイド、その他のドキュメントはすべて完璧でなければなりません。明確で、正確で、実例を伴っているべきです。私が苦労したのは特別なケースではありませんが、全体的な体験にプラスに働く要素は一切ありませんでした。

本当に、なぜコマンドラインで認証したり、マウント操作をしたりする必要があるのでしょうか？　対抗例としてDropboxを挙げましょう。迅速かつ簡単に仕事をしてくれます。Copyも同様です。いくつかのクラウド系ツールを試してきましたが、どれもかなりシンプルで直感的でした。odriveには同じことを期待します。いや、倍以上に期待したい。すべてのストレージプロバイダーを合わせたものよりも、より優れた、よりエレガントな存在でなければならないのですから。

それでも今後も注視していきます。このアイデアがとても気に入っているからです。ただ現時点では、odriveに実際的で具体的な価値は見出せません。本当の問題は、ソフトウェアを動かすまでの技術的な難しさ、きちんとしたサービスの欠如、そして不完全なドキュメントにあります。いつの日か、また会いましょう。

それでは。