#1456: Apple Music の改善提案、Siri の技 14 選、CloudBerry Backup の信頼性に疑問

私は音楽サービスのストリーミングが好きだ。いつでもどこでもほとんどあらゆるものを聴くことができる。そのためなら、毎月の Apple Music 講読料金を喜んで払いたいと思う。とりわけ、わが家では２つの部屋に HomePod を置いているのでなおさらだ。そうは言っても、私は今も Rdio がなくなったのを残念だと思うし (2015 年 10 月 7 日の記事“Rdio に戻る： 私はなぜ Apple Music を止めたか”参照)、もしも Spotify があの馬鹿げた 10,000 トラックまでという上限を撤廃してくれたらどんなに素敵だろうに (2017 年 8 月 30 日の記事“10,000 曲の制限：私が Spotify から Apple Music に乗換えた理由”参照) とも思う。それでもなお、Apple Music はそれなりに動作してくれるし、わが家に何十年も置いてあった寄せ集めのステレオシステムに比べれば HomePod は大きな進歩だ。でも、私が Apple のサービスに求めるようになっているのは、決して「それなり」のサービスではない。私が希望を抱くのは、Apple が再び「めちゃくちゃすごい」ものを目指して挑戦してくれることだ。

Apple は 2019 年 3 月 25 日に Cupertino の Steve Jobs Theater でスペシャルイベントを開催すると発表した。おそらく、新しいビデオサービスが発表されることだろう。そしてもしも幸運が訪れるなら、Apple Music にも更新が施されて欲しいものだ。実現して欲しいと私が思う点のいくつかを、以下に挙げてみよう。

DJ モード

厖大なトラックの保存庫が Apple Music にあるのは多くの意味で嬉しいことだが、ともするとその結果として自分が全然聴いたこともないような曲を聴く羽目になることも多い。とりわけ、Siri に命じて一人のアーティストまたは一つの楽曲をもとにラジオ局を作らせたり ("Play Bruce Springsteen radio")、あるいは自分用のラジオ局を作らせたり ("Play music I like") した場合にそうなりがちだ。

もちろん、いつでも Siri に "What's playing?" と言えば楽曲とアーティストの名前を教えてもらえるのだが、もしも "DJ モード" というものができて、それを有効にすれば個々の曲を再生する前に自動的に Siri がその曲名とアーティスト名を告げてくれるようになったならばどうだろうか？ 言わば、Siri がラジオ局の DJ になってくれる訳だ。聴く曲が分かっていればそのモードをオフにすればよいし、Siri に曲を選ばせたくなればそのモードをオンに戻せばよい。

スタジオに籠るか、コンサートに行くか

オプションの話のついでに、私はライブのパフォーマンスのトラックを再生しないというオプションもあって欲しいと思う。もちろん人によって意見は違うだろう (だからこそオプションとして提案しているのだ) が、私の場合、ライブ録音で曲が始まる前に流れるお喋りが耳障りだと思うことが多い。それに、同じ曲でもスタジオで録音されたものの方がたいてい良いサウンドに聞こえる。

私と違った意見の人たちのために、Apple Music が反対のことをするのも良いだろう。つまり、ライブ録音のトラックだけを再生して、コンサートの臨場感をかもし出すこともできるはずだ。

そのようなオプションを実装するのはそれほど難しくないはずだ。iTunes はもともとライブアルバムを別扱いにしているので (この機能はかなり最近の変更点かもしれないが)、Apple がライブトラックとスタジオセッションを識別できることははっきりしているからだ。

重複を減らす

私がライブトラックを聴いていてイライラする理由の一つは、作品数の多いアーティストの音楽を再生するように Siri に命じると、同じ曲を何度も聴かされることが多いからだ。オリジナルアルバムから一回、ライブ録音から数回、さらにはベストアルバムからまたまた数回、といった具合だ。

一つのセッションの中では、一つの曲は一度聴けば十分だ。もちろん曲は同じであっても内部的には別々の ID が付いているに違いないとは思うが、Apple Music はもっと賢くなって、名前をもとにして曲の重複を避けるようになるべきではないだろうか。

試しに、Siri に命じて Kansas の "Dust in the Wind" に似た曲を選ばせてみたら、この順番で曲が次々に再生された：

1. “Dust in the Wind” (Kansas)
2. “Dust in the Wind” (Kansas)
3. “Stairway to Heaven” (Led Zeppelin)
4. “Dust in the Wind” (Kansas)
5. “Carry on Wayward Son” (Kansas)
6. “Dust in the Wind” (Kansas)
7. “Point of Know Return” (Kansas)
8. “Play the Game Tonight” (Kansas)
9. “Point of Know Return” (Kansas)

全部で９曲のうち、Apple Music は "Dust in the Wind" を４回、"Point of Know Return" を２回再生し、Kansas 以外のアーティストの曲はたった１つだけだ。アルゴリズムとして出来が悪い！

Siri よ、フィードバックを取り入れて、お詫びを口にせよ

この "Dust in the Wind" の失敗例で、私は何度も繰り返して Siri に次のトラックへスキップせよと命じる羽目になり、思わず笑ってしまった。Apple Music のラジオ局が私が好きでない曲を再生するのは別に珍しいことではないが、その度に私は即座にその曲をスキップさせている。たいていの場合、私の声はイライラ感を伴った語調だ。あるいは、もっとひどい例として、時折 Siri は私の言ったことを誤解して、何か恐ろしく耳障りなものの再生を始めることもあるが、そうすると私はすぐさま大声で "Hey Siri, stop!" と叫ぶ。

人間ならば、相手にそんな反応をされれば素直に謝るだろう。だから Siri にも、一つのコマンドの後にそれを取り消すコマンドが興奮した語調で語られたら、同じように謝って欲しい。いったいなぜ Siri は間違いをしても謝らないのか？

その上、Apple Music に話を戻せば、Siri が間違いから学習するようになって、あなたがスキップを命じたものに似たトラックを、少なくともその同一のセッションの中では避けるようになったならば素敵ではないだろうか？ もしも Siri が「すみません Adam、これからはもっとあなたの気に入る曲を再生するように努めます」と言ってくれたなら、私はとても幸せに感じると思う。

皆さんのお考えは？

もしもあなたが Apple Music 購読者なら、あなたは Apple Music を気に入っているだろうか？ もしもあなたが別のストリーミングサービスをお使いなら、それはどれか？ あるいは、トラックをリッピングして iTunes でお聴きだろうか？ 一問だけの読者アンケートを実施中なので、どうぞ投票をして、さらにもっと踏み込んだ回答をコメントにも書き込んで頂きたい。

討論に参加

質問に答える、電話をかける、そして (ひょっとすると) 冗談を言う等が、Siri について考えた時に思いつくことかもしれないが、この Apple のデジタル助手はもっともっと多くの隠し技を持っている。

あなたが特に決まった領域に属さない様なことをする時に、Siri が手助け出来る一番クールなものを、文章を外国語に翻訳することから、自分のスマートホームを制御することまで挙げてみる。(Mac, iPhone, HomePod, AirPods, そして Apple TV を始めとする自分の持っている全ての機器上でどうやって Siri を呼び出すかについて確かでなければ、この Apple サポートページを参照されたい。)

でも Siri に関して言えば、これらのことは水面から顔を出している氷山のほんの一角に過ぎない。Siri が出来ることの全ては私の本 Take Control of Siri で詳細に学べる。値段は $14.99 に過ぎず、更に HomeKit にも気を惹かれているのであれば、Josh Centers によるアップデートされたばかりの Take Control of Apple Home Automation とバンドルすることで、両方を $20 で買える。こちらの本も単独の定価は $14.99 である

1. あなたの Apple 機器を探す

iCloud.com にログインし、気まぐれな Apple 機器を探して地図に目をこらすのは結構大変であり、通常は、漏れ聞こえてくる呼び出し音を求めて家の周りを歩き回ることになる。(私の場合、その呼び出し音は冷凍庫から聞こえてきたことがある。私の iPhone は、アルミフォイルで丁寧に包まれ鎮座ましましていた。小さい子供は何をするか分からない)。

Siri なら手間は取らせない。Siri を呼び出し、"時計を鳴らして" とか "iPhone を探して" と試されたい。Siri は、あなたの iCloud アカウントに現在サインインしていて近くにある機器があるかどうかを教えてくれ、そして音を鳴らしてそこへ導くことも出来る。私は、これを HomePod で使うのをとても便利だと思っている。"Hey Siri, 私の iPhone は何処？" と言うだけである。

2. パスワードを引き出す

時々、Safari AutoFill がうまく働かなくて、或いは他の機器上でパスワードをタイプする必要があり、Web サイト用のパスワードを調べる必要に迫られることがある。iOS 12 や macOS 10.14 Mojave で、Siri はこの作業をとても簡単にやってくれる。Siri を呼び出し、名前を言ってパスワードを直接求めるのである。例えば、"Netflix のパスワードは何？" とか "Dropbox パスワードは何？" と聞く。或いは、"私のパスワードを見せて" と言い、リスト全体を引き出す。心配はご無用：パスワードにアクセスするためには、Mac 上で自分のログインパスワードを入力しなければならない。iOS 機器は Touch ID か Face ID を使って認証出来る。

ヒント：Wi-Fi パスワードは Siri のパスワードを思い出す力の範疇には含まれないが、簡単に共有する術はある。"iPhone、iPad、iPod touch で Wi-Fi のパスワードを共有する" を参照のこと。

3. アプリを起動する

Mac 或いは iOS 機器上で、Siri はアプリに簡単にアクセスさせてくれる。Siri を呼び出し次の様に言う："(アプリ名) を開く"、"(アプリ名) を起動"、"(アプリ名) をする" 或いは、ただアプリ名だけでも。(ひょっとすると、"Sims をする" と言う様に "Photoshop をする" と言えば、仕事に対する我々の態度も改善すると Apple は思ったのかもしれない。) しかしながら、Siri はアプリを閉じることは出来ない。

ヒント：Siri を使って App Store を検索することも出来る。"お金管理のアプリを見せて" とか "子供のゲームを見せて" とか、その様なことを言えば、App Store がそのカテゴリーのものを示す。

4. タイマーをセットする

オーブンから物を取り出す時間を気にかけているにしろ、或いは試験の時間を計っているにしろ、Siri は Apple Watch, 或いは HomePod の様な iOS 機器を使って、数分或いは数時間をカウントダウンする手伝いをしてくれる。やることは簡単で、Siri を起動し "タイマーを 20 分に設定" と言うだけである。

残り時間を見るには、Siri を呼び出し "タイマーをチェック"、キャンセルするには "タイマーを止める" と言う。

HomePod には、余分の隠し技がある - これを使って複数のタイマーを設定出来るので、料理している時にはとても便利である。名前をつければ、どれがどれだか区別出来る。"Hey Siri, ラザニヤタイマーを 45 分に設定" と言い、そして "Hey Siri, ソースタイマーを 5 分に" と言う。どのタイマーにどれだけ時間が残っているのか見るには、"Hey Siri, ラザニヤタイマーをチェック" と言う。取り消すには、"Hey Siri, ラザニヤタイマーを取り消す" と言う。全ての動作中のタイマーを消去するには、"Hey Siri, 全てのタイマーをキャンセル" と言う。

Siri と台所にある HomePod を使ってどんな素晴らしいことが出来るかの私のデモビデオをご覧あれ："How to Use Siri in the Kitchen"。

5. 目覚ましをかける

好きな人も嫌いな人もいるだろうが、目覚ましは時間通りに起きて出かける手助けをしてくれる。iPhone, iPad, Apple Watch, 或いは HomePod で Siri を使って目覚ましをかけよう。Siri を起動して、"明日の 6 PM に起こして" 或いは "目覚ましを 5 AM に設定して" と言う。その時間になると、たとえ iPhone が Do Not Disturb に、或いは Ring スイッチが無音に設定されていても、目覚ましは音を鳴らす。

iOS 機器では、目覚ましは削除しない限り Clock アプリの中に留まるので、再度利用するのには便利である。それに名前をつけておくと、後で Siri を使って、オンオフするのは簡単である。例えば、別の日に "School Day 目覚ましを 6:45 AM に設定" と言っておけば、"School Day 目覚ましをオン" とか "School Day 目覚ましを止める" とか言える。同様に、夏が来たら、ただ単に "School Day 目覚ましを削除" と言えば良い。いろいろ溜まったアラーム全部を削除するには、"全部のアラームを削除" と言う。

6. 文章を翻訳する

iPhone, iPad, 或いは HomePod 上の Siri に、どんな英語の言い回しでも (深呼吸) Arabic, Brazilian Portuguese, French, German, Italian, Japanese, Mandarin Chinese, Russian, 或いは Spanish に翻訳するよう頼める。iOS 機器は、これらの翻訳を音声でも、文字でもどちらででも出来る。Siri は未だあなたに話し返されたものを英語に戻すことは出来ないが、旅に出ていて朝食を注文したり、トイレを探したい時にはとても役に立つ。その上、それは我々を Star Trek の未来に一歩近づけてくれる。(誰か万能翻訳機を持っていないか？) 訳したい言葉の前に "How do I say" 或いは "Translate" を付ける。例えば、"Translate where is the nearest bathroom in French" (一番近いトイレは何処ですかをフランス語に翻訳して)。

7. 単語を調べる

言葉に詰まっても、Dictionary アプリを開いたり、Google 検索をするまでもない。Siri を呼び出して、"rhythm のスペルを教えて" とか "flibbertigibbet の定義" と聞けば良い。私は、私の 10 代の子供と読書している時に、言葉を調べるために、Apple Watch の Siri をよく使う。(Dickens には風変わりなものが結構ある。)

8. 友人や家族を見つけ出す

便利だと思うか、気持ち悪いと思うかは人によると思うが、iOS 機器や Mac 上の Siri で、Apple の Find My Friends を使ってあなたの愛する人を見つけ出すことが出来る。Siri を呼び出して、頼む："私の友人達は何処？" "一番近い友人を探して"、"Graham は何処？" 或いは "Dave が仕事場に着いたら教えて" と。 あなたに許可を与えている人なら誰でも見つけ出すことが出来る - 例えば、あなたの Family Sharing グループに属する人 (設定の詳細については、Apple のサポート記事"「友達を探す」を設定して使用する" と "家族と位置情報を共有する"を参照されたい。

9. 写真 (或いは自撮り) を撮る

iPhone を手にしてスナップショットを撮るのはそんなに難しい話ではないが、Siri はそれを少々だがより簡単にそしてより早くすることが出来る - シャッターチャンスを逃してしまいかねない数ステップを省略出来る。iPhone 又は iPad で、Siri を呼び出し、以下をやってみる："自撮り"、"写真を撮る"、"四角い写真を撮る"、"パノラマを撮る"、"ビデオを撮る"、"スローモーションビデオを撮る" 或いは "コマ撮りビデオを撮る" とかである。(Siri は Portrait モードは呼び出せない。) Siri は Camera アプリを開き、希望の設定にする。準備をして写真を撮る。その通り、写真は自分で撮らなければならない - Siri はあなたに代わってシャッターボタンを押すことは出来ない。

Apple Watch があれば、これはさらに面白くなる。iPhone を背面カメラを被写体に向けて設定し、離れる。時計上の Siri を起動して、"写真を撮る" と言う (Siri の他の Camera コマンドでも良い)。Bluetooth の範囲内にいる限り、iPhone のカメラは起動される。

時計上の白いシャッターボタンをタップすれば、写真は即座に撮られるが、3s アイコンをタップすれば３秒のカウントダウンが始まる。

Mac では、カメラ設定がもっと簡素化されていて出来ることは限られるが、"写真を撮る" は、Photo Booth を立ち上げ、iSight カメラを起動する。

10. 写真を探す

写真を探しているのであれば、Siri は手助け出来る。頼んでみよう："February 27 の写真を見せて"、"Portland, Oregon で撮ったビデオを見つけて"、"私の好みの写真を見せて" (Photos でハートアイコンをクリックしたり、タップしたりして印をつけたもの)、或いは "David の写真を見せて" (Siri は Photos の People データを参照する)。

Siri は基本的なことを超えて、手でやるには大変そうな、或いは不可能と思えそうな検索すらも出来る。Siri に、Photos Advanced Computer Vision 機能を活用する質問をし、あなたの画像を光の速度でくまなく探させる。例えば、"コリーのいる写真を見せて" と言えば、Photos が開いて、それがマッチすると考える一連の画像を示す。

珍しいそして素晴らしい対象物も見つけ出せる。例えば、木 ("オークの写真を見せて")、植物 ("バラの写真を見せて")、ランドマーク ("浜辺の写真を見せて")、そして子供たち ("赤ちゃんの写真も見せて") - Apple によれば、4432 の対象物があるという。あなたの写真の中に合うものが見つからない場合、Siri は、代わりに Web での画像検索を行う。

Mac 上では、あなたの Siri への頼みは、Photos ウィンドウの上部に大きな書体で現れる。iOS 機器上では、あなたの Siri への頼みは、あなたを Photos 検索画面へと誘い、そして言ったことは検索フィールドに置かれる。

11. 送金する、或いは送金を依頼する

Apple Pay, PayPal, 或いは Venmo を iPhone で使っているのであれば、Siri を使って送金するのは早くて簡単である。(Apple Pay は Apple Watch 上の Siri でも働く。) iPhone を解錠して次の様なことを言う："$5 を Mary にコーヒー代として Venmo を使って送る" とか "$25 を Kabir を夕食代として Apple Pay"。必要に応じて、送金先を名前で確認し、そして "Yes" と言って送金を承認する。

また、友人からの Apple Pay を使った支払いを iPhone や Apple Watch 上の Siri から依頼出来る。こんな感じである："Eowyn に $17 を T シャツ代として頼んで"。Apple Pay の設定と使い方についての更なる詳細については、この Apple サポート頁を参照されたい。

12. ヘッドラインを聞く

米国では、iOS 機器や HomePod で、最新ニュースを遅れずに手にするのは簡単な (時として、気が滅入る) 話しである。ただ Siri にそのニュースについて聞けば良い。Apple の Podcasts アプリがインストールされている限り、Siri は Bloomberg, CNBC, CNN, ESPN, Fox News, NPR, そして Washington Post からのニュースダイジェストや要約を再生出来る。そのメディア出版社の最新番組から情報を取り寄せる。

Siri を呼び出して "ニュースヘッドラインを再生" とか "NPR からのニュースを再生" と言って、NPR News Now ポッドキャストからの最新版を聞く。何か別のものの方が良ければ、"Fox News に切り替えて" とか "Washington Post に切り替えて" と言う。或いは、次回に (上記のリストから) 名前を言って好みの情報源を頼む。

ヒント：地元の NPR 局を名前で指定することも出来る、例えば、"OPB ラジオを再生" のように。

場合によっては、次の様な命令を使ってより具体的に絞り込むことも出来る、"ESPN からのスポーツ番組" とか "Bloomberg からのビジネス番組" とかである。しかし、色々な話題を頼めるわけではないことに気付くことになる - 例えば、科学、技術、或いは世界のニュース - これらは、新聞で普通にみられるものである。

勿論、好きなニュースポッドキャストが既にあるのであれば、Siri に名前を言って再生させられる。例えば、"the Daily を再生" と言って、New York Times ポッドキャストを聞ける。(ポッドキャストの再生に苦労しているのであれば、要求に "ポッドキャスト" という言葉を付け加える。例えば、"the Daily ポッドキャストを再生" のように。) 終わったら、"ニュースを止める" 或いは単純に "停止" と言う。

13. 家を制御する

iOS の Siri は、大分前からスマートホームの設備、例えば、照明、セキュリティカメラ、温調器等を Apple のホームオートメーションプラットフォームである HomeKit 経由で制御出来ていた。Mojave の登場で、我々は Mac 上でもこの Home アプリの力を利用する能力を手に入れた。HomeKit 対応の設備 - HomePod もその内の一つ！ - があるとして、 次の様な命令を試してみる："台所に音楽を流して"、"全部の灯りを点けて"、"屋根裏部屋の温度は何度"、"ファミリールームを青にして" そして "車庫の扉を開けて" 等である。

14. フラッシュライトを点ける

フラッシュライトが欲しい？ ただ Siri を起動して "フラッシュライトを点けて" と言えばよい。これは、皆さんが iOS 12 のフラッシュライトボタンが働く様子に慣れていない場合には、とりわけ有用である。

音声操作を有効にしていれば、夜中に何かを見つけようとする時にこの魔法を使える。ただ "Hey Siri, フラッシュライトを点けて" と言うだけで、あなたの iPhone は光りだす。たとえそれが部屋の反対側の充電器の上にあったとしてもである。あなたのつま先は、暗い中で探り回らなくと良いことに感謝するであろう。

Siri をもっと色々なやり方で使う方法を Take Control of Siri で学んで欲しい。

Scholle McFarland は、1996 年以来、MacUser マガジン、後には Macworld の編集者として Mac を取り上げてきた。彼女はその間に、誰もが好む "死にかけた" 会社から、誰もが実際に好む会社へと Apple が変遷するのを見てきたし、今でも全てのことに目を見張っている。フリーランスの記者そしれ編集者として働いていない時、Scholle ("Sholly") は、風光明媚な Portland, Oregon で、家族、友人、そして多くの動物とのんびりと時を過ごすのが好きである。

討論に参加

完璧なバックアップ戦略には、三つのタイプのバックアップが含まれる：

1. ブート可能な複製： これは、あなたの内蔵ドライブをそのまま、起動可能な状態のクローンを作るので、ドライブやコンピュータが壊れた場合でも可能な限り素早く元の状態で動かすことができる
2. バージョン化されたバックアップ： これは、ファイルが変更されるに応じて複数個のバージョンを保存しておくので、いつでも時間を戻した状態のファイルが得られる
3. オフサイトのバックアップ： これは、あなたの自宅や職場とは違う場所にあなたのデータをコピーしておくので、万一の盗難、火事、洪水といった場合にも保護される

それぞれの必要のために、これまでに数限りない製品が登場してきた。それらの製品の中で最良のものたちを詳しく調査し、それらをどのように組み合わて全体的なバックアップ戦略を構築するべきかを解説しているのが、Joe Kissell の Take Control of Backing Up Your Mac だ。その付録には、本編で取り上げなかった他の多くのアプリについても比較した表が載っている。

ブート可能な複製については、Carbon Copy Cloner と SuperDuper の二つが Mac の世界を支配している。また、ChronoSync はその同期機能に加えてブート可能な複製を作ることもできる。バージョン化されたバックアップについては、Time Machine が間違いなく最もよく知られている一般的な解決法だが、Time Machine も決して完璧ではない。結果として、それに競合するアプリたちのカテゴリーが出現した。その先頭に立つ Arq はバージョン化されたバックアップを作成してそれをオフサイトに保存することもできる (2018 年 5 月 18 日の記事“Arq と B2 で自分用にクラウド・バックアップを展開する”参照) ので、別途インターネット専用のバックアップサービスをオフサイトのバックアップ用に使う必要がない。でも、その種のアプリにはそれなりの難点もある。

そういう訳で、CloudBerry Lab が TidBITS に話を持ちかけて CloudBerry Backup for macOS をレビューしてくれないかと言って来た時、私たちはその魅力的な機能一覧を見て大いに乗り気になった。これは、バージョン化されたバックアップとオフサイトのバックアップの両方の必要を満たす、魅力的な解決法になるのではないかと思ったからだ。でも残念ながら、その夢の実現までにはもう少し待たなければならないようだ。

魅力的な機能一覧

CloudBerry Backup for macOS は無料で利用できる。この製品を評価するには、なかなか良いやり方だ。でも、たった $29.99 を払うだけで Pro 版が得られて、暗号化、圧縮、電子メールサポート、200 GB 以上の保存など、重要な機能が使えるようになる。(ここで述べた価格にはストレージ料金が含まれておらず、ストレージはあなたが自分でどこかで見つけなければならない。) 私はテスト用に Pro 版を使った。

CloudBerry という名前は、クラウドベースのストレージと、ロシア北部原産のフルーツであるクラウドベリー (ホロムイイチゴ) とから来ている。この会社の主要な従業員の何人かがロシア北部出身だからだ。CloudBerry はバックアップの保存先として幅広い選択肢を提供することでたちまち私に強い印象を与えた。

私のテストは主としてクラウドベースのバックアップ先として Wasabi を使った。私は既に Wasabi のアカウントを持っていたからだ。また、ローカルなドライブへバックアップするオプションである File System も使った。

CloudBerry はファイルの選択や除外のオプションとして標準的なものを提供し、一連の柔軟な保持パラメータも持っていてファイルをどれだけの期間保持するか、個々のファイルに何個までのバージョンを保持するかなどを指定できる。ただし目立って欠落しているものが一つあって、保存先ボリュームが一杯になるまでは古いファイルを削除しないという (Time Machine のデフォルト設定でもある) 単純なオプションが存在していない。

加えて、CloudBerry はスケジュールのオプションも豊富に備えていて、バックアップが走るべき日付や時刻を指定したり、走る頻度を指定したりもできる。ここでも目立った欠落が一つあって、例えば CrashPlan が提供している「必要に応じて常時走る」という単純なオプションが存在していない。

圧縮や暗号化のオプションや、バックアップが完了した際に電子メールで通知するオプションもあり、電子メールのフォーマッティングにもいくらかのコントロールができる。

バックアップはインクリメンタルに走る。つまり、最初にバックアップした後では、CloudBerry はその後に変更を受けたファイルのみをバックアップする。今どきはこの業界全体にわたってこれが基本的な機能となっている。また、ブロックレベルのバックアップをするオプションもあって、これを使えばインクリメンタルなバックアップよりもさらに細かな仕分けが提供される。つまり、巨大なファイルにほんの小さな変更のみを施せば、その変更が存在しているファイルシステムのブロックのみ (ひょっとするとたった 8 KB のデータだけかもしれない) がバックアップされ、(それより 1000 倍も大きいかもしれない) ファイル丸ごとのバックアップをせずに済む。

これらのさまざまなオプションすべてを集めたものを CloudBerry はプランと呼び、さまざまの異なるファイルを異なる保存先へ異なる方法でバックアップできるように、好きなだけの個数のプランを作成することができる。

個々のプラン特定の設定だけでなく、それとは別にグローバルな設定もできて、symlink の処理の方法、バンド幅のスロットル、バックアップがアクティブな間は Mac をスリープさせずにおくか否か、などを指定できる。さらに、内部的なアプリケーション設定を使ってスレッド数、チャンクのサイズ、メモリ占有量などもコントロールできる。

これほど多くのパワーと柔軟性が非常に魅力的なユーザーインターフェイスの中に提供されているので、これから始めるバックアップに対して、本当の意味でフル・コントロールが得られるという気持ちにさせられた。

ハネムーンは短い

けれども残念ながら、うきうきした喜びの気持ちでいられたのはほんの短い間だけであった。私が遭遇した問題点のいくつかはマイナーなものだったが、いくつかは深刻なものだった。それらのすべてが合わさると、この製品に対する私の信頼は突き崩された。それでは、私が見つけたことのいくつかを、順々に見て行こう。

バックグラウンドでの挙動がまずい

バックアップの設定を済ませると、私は CloudBerry が走る様子を見守った。時々、そのメインのプロセス cbbWorker が CPU サイクルの 40% 以上を消費することがあり、私の生産性を大いに妨げた。例を挙げれば CrashPlan は私が Mac をインタラクティブに使用していることを探知して、その際には自らの CPU 消費を絞ってあらかじめ設定した敷居値以下に抑え、ユーザーの生産性に影響を与えないようにする。けれども CloudBerry はその種のコントロールを一切提供しておらず、これではバックグラウンドプロセスとして良い挙動とは言えない。

CloudBerry はネットワークバンド幅の制限機能を提供するけれども、あまり賢い動作はしないので私が Mac から離れていてもフル・スロットルにはならない。結果として、素早く実行を完了するサービスか、あなたの仕事を邪魔しないサービスか、どちらか一方を選ばなければならず、両方を取ることができない。

統計数字が不正確

バックグラウンドの挙動の問題はフラストレーションが溜まるけれども、それよりもっと重大な問題は、すべてのデータが含まれたかどうかが分からないという懸念だ。

私はバックアップのソースとしてよくある選択、つまり /Users ディレクトリを選んだ。CloudBerry がバックアップを走らせる際、あらかじめソースファイルのサイズ合計を表にして示す。でも、そこに示されたのはたった 1 GB ほどで、/Users ディレクトリがそんなに小さくないことを私は知っていた。自分が思い違いをしていないことを確認するため、私は Finder で調べてみた。するとやはり、CloudBerry の示す合計量は実際とは遥かに隔たっていた：

私のプランを確認して、除外ファイルの設定とか、その他この食い違いの原因となり得るような設定があるかどうか調べたが、そんなものはなかった。では、何が CloudBerry の合計量を減らしていたのか？ バックアップ終了後に、私のデータのすべてが安全に保存されたかどうか、どうすれば確信できるのか？

そこで、私はバックアップの進行状況を注意深く観察してみた。その際に気付いたのは、進行状況バーが普通通りに左から右へと次第に伸びて行くのではなくて、時とともに縮んだり伸びたりを繰り返していることだった。もしも、例えば Carbon Copy Cloner でオプションとして選べる設定の下でのように、バックアップすべき量を計算し終える前にバックアップ作業を始めるのであれば、このような進行状況バーの挙動も納得できる。けれどもそれは CloudBerry の動作方法とは違う。CloudBerry は、最初にまずその Total File Size の数字を計算して表示するのだ。さらに状況を悪化させているのが、進行状況バーの長さがそのすぐ脇に表示されている完了部分のパーセント表示と合っていないことだ。スクリーンショットでは「94%」が完了したと表示しているにもかかわらず、進行状況バーの方は３分の１程度しか青くなっていない。

私は CloudBerry のサポート担当者にこの進行状況バーのことについて問い合わせてみたが、進行状況バーの表示は不正確なので信用してはいけないという返事が返ってきた。そのサポート担当者はこの問題を修正する予定があるかどうかについて何もコメントできず、そのためこのアプリに対する私の信頼度が一段階下がったが、結局私はこのことだけですべてを放り投げるほどではないと心を決めた。

居眠り厳禁の場面は２つ： 自動車の運転と、データのバックアップ

その後しばらくして私は戻って来て、ログインし、バックアップが未完了のままなのにもはや動作しておらず、それなのに何の通知も出ていないことに気付いた。幸いにも CloudBerry のログはとても読みやすく、それを読んだ結果、Mac がスリープに入ったことによってバックアップが中断していたことが分かった。そこで私はこの問題を修正するためにアプリの設定の中で「バックアップ中にはスリープしない」というオプションをチェックした。

でも、読みやすかろうとそうでなかろうと、いちいちログを読む人がどれだけいるだろうか？ 私がそれをしたのは、私が経験を積んだソフトウェアのプロであるから、しかも現在テクノロジー系のレビュー記事を書いている最中だからだ。大多数のユーザーはそんなことをしないし、そんなことをすると期待されるべきでもない。バックアップというのは問題なく働くべきものであって、バックアップには (とりわけ初回のバックアップには) 長い時間がかかることが多いので、アプリの側から「バックアップ中にはスリープしない」というオプションをチェックせよという推奨が出ないのは、正気の沙汰とは思えない。それに、少なくともバックアップの妨げになる何らかの問題が起こったならば、CloudBerry からあなたに対して、例えて言えば火災報知器のようにはっきりと、問題を修正せよという警告が出されるべきだ。なぜなら、あなたのデータがリスクに瀕しているからだ。

不可解な遅さ

私はバックアップを再開させた。すると、CloudBerry がソースファイルのサイズ合計として前と違った (前よりも正確な) "‾300 GB" という数字を示したので、私は困惑してしまった。でも、とりあえず今はその優柔不断の数字を無視することにして、そのままバックアップを走らせた。それから 24 時間後になって見ると、CloudBerry はファイルのほんの一部 (300 GB のうち 17 GB) しかまだスキャンしていなかった。このペースでは、初回のバックアップ (総量はそれほど大きくない) を始める準備段階のスキャン作業に 20 日間もかかり、その後でやっとコピーが開始されることになってしまう。

この遅さは、尋常じゃない。CPU の観点を言えば、私は 2017 年型の 27 インチ Retina ディスプレイ iMac を使っていて、cbbWorker はその時点で利用可能な CPU のうちほとんど常に 8% 以下しか使っていなかった。どうやら、当初のように CPU の 40% 以上を占める状態からは脱していたようだ。それに、使える CPU の空き部分もたっぷりあった。

バンド幅の観点を言えば、私が使っている Fios サービスは下り・上りの双方で 100 Mbps を提供し、別に他のデータを忙しく転送したり受信したりしている訳でもなかった。速度テストをしてみると、この Mac 上の他のアプリが大量のデータをアップロードできることが示された。

同じように、ソースファイルが置かれている内蔵の Fusion Drive も、大量のデータを動かせる状態にあった。

明らかに、今述べたもののどれも、ボトルネックの原因になるとは思えなかった。そこから推察すれば、問題はクライアントソフトウェアにあるか、遠隔のサーバソフトウェアにあるか、そのローカルネットワークにあるかのいずれかだ。私がバックアップすべきデータを 1.5 TB 以上も持っていることを考えれば、糖蜜の中のようなのろのろしたパフォーマンスでは CloudBerry は使い物にならないと言う他はない。

偽陰性： 実際には失敗したのに成功と主張

それまでに出会った他の問題と同様に、私はとりあえずこのパフォーマンスの問題も脇に置くことにして、まずはちゃんと成功裏にバックアップを完了させようと思った。そうしてバックアップは成功した。いや、本当にそうなのか？

私はクラウドへのバックアップを諦めて、ほんの 10 GB ほどのずっと小さなソースファイルセットを選び、バックアップの保存先を外付けハードドライブに指定した。CloudBerry はほとんど即座にバックアップを終え、素敵な緑色の小さなチェックマークを表示して、バックアップは成功と主張した。

でも、これではあまりにも早過ぎるように見えた。そこで私はコンソールで統計数字をチェックした。(誰でもそうするでしょう、ね？) すると分かったのは、CloudBerry がたった 1 個のファイル (データ量は 110 バイト) をバックアップしただけに過ぎないという事実だった！ 10 GB をバックアップせよと指定したのに、どの面下げてこれを成功だと言うのか？

この後を読み続けて下さればお分かりのように、私はその後もトラブルシュートを続けて、CloudBerry がなぜ何千個もあるファイルのうちたった一個しかバックアップしなかったのか、その理由を探ろうとした。もちろん、エラーは起こるものだ。でも、明らかにバックアップが成功していないにもかかわらず成功と報告して顧客に自分のデータが安全にバックアップされたと信じ込ませるのは、あまりにも危険なほどに怠慢だ。顧客によっては、ソースとしたハードドライブを再フォーマットするためにこのバックアップをしているのかもしれない。そんな場合、もしも CloudBerry バックアップから元通りにリストアしようとする段になって、バックアップにはたった一個のファイルしかなく、それ以外のファイルはどこにもないと知ったなら、いったいどうなるのか！ そんな目にあった人たちが「この緑色のチェックマークは何なんだよ?!?」と叫ぶ声が、まざまざと聞こえるような気がする。

コマンドラインで切り刻む荒技が必要

CloudBerry は素敵なグラフィカル・ユーザー・インターフェイスを備えているにもかかわらず、どうやら CloudBerry Lab で働く人たちの共通認識は、実際に使い物になるバックアップを持つためにはコマンドラインを使う必要があるということのようだ。

私は CloudBerry Lab のサポートチームと協力してバックアップが失敗に終わった原因のトラブルシュートを続けていたが、何人かの技術者たちが、私がバックアップしようとしていたファイルの一部について、私の Mac 上でのファイルの「所有権」が、CloudBerry を走らせていたユーザーとは違うユーザーのものになっていたことに気付いた。そして、ログに記載されたエラーがアクセス権の問題を示唆していると私に指摘してくれた：

「デフォルトでは、あなたがユーザー X として作成したバックアッププランは、ユーザー X が持つアクセス権の下で動作します。ただし、バックアッププランの設定ファイルの所有権を変更すればその動作を変更できます。」

sh-3.2# ls -l
total 32
-rw-r--r--  1 dkitabji staff  3826 Nov 24 12:16 {0d1d4a65-4776-4fd4-8bcd-d8425a71e91c}.cbb
sh-3.2# sudo chown root:wheel /opt/local/CloudBerry\ Backup/plans/*
sh-3.2# ls -l
total 32
-rw-r--r--  1 root wheel  3826 Nov 24 12:16 {0d1d4a65-4776-4fd4-8bcd-d8425a71e91c}.cbb

つまりは、Unix の chown コマンドを使ってプランのファイルの所有権を変更することで初めて、Mac 上のファイルをバックアップするという作業が可能になる、ことほどさように高度で専門的な (!!) 作業には、chown コマンドが必須ということらしい！

私に言わせれば、とんでもない話だ。そんな議論がまかり通るならば、それは例えばピカピカの新車のキャデラックの鍵を手渡しながら「お客様、ご自宅に帰られたら、今後は長いドライブ旅行にお出かけの度に、エンジンの下に潜り込んで、スパナを使ってボルトをいくつか調節して車が正しく走るようにして頂く必要があります。それを怠れば車が壊れるかもしれません」と告げるようなものだ。ユーザーのためにこの変更を施すのは CloudBerry にとって朝飯前のことのはずだ。基本的な機能を有効化するためにユーザーが Unix コマンドをタイプしなければならない理由など、どこにもあるはずがない。

ファイルのトワイライト・ゾーン

でも、どうやら私は酷使されることが大好きな人間のようだ。単純な Terminal コマンドだけで CloudBerry が私のファイルを成功裏にバックアップできるようになるのならば、パワーユーザーを自認する私としては、この製品を (おそらく見当違いの) プライドを持って使うことに吝かでない。でも、CloudBerry は強情で、参加賞トロフィーを求めて私がどんなに試みても頑固に私の邪魔をした。

私は CloudBerry Lab サポートチームの助言に従って、新規にバックアッププランを作成してから、空白のフォルダを保存先に指定して、完全にまっさらの状態から始められるようにした。始める前にそのプランファイルのアクセス権を変更しておいてから、プロセスを起動し、バックアップを完了させた。

これもまた、疑わしいほど素早く作業を完了したし、ファイルサイズの統計情報も、前と同様に極めて普通でない数字を示していた。コマンドラインで変更を加えた後であっても、私は統計数字の真実性に信用が置けないことを承知していたが、どこが悪いのかを示す証拠となるものが欲しかった。私はその昔の 2009 年に Time Machine を試した際にも同様の懸念を感じたことがあって、その折にソースと保存先のファイルの違いを調べる Unix シェルスクリプトを書いていた。私は Time Machine が作業を怠っていたファイルの明々白々なるリストを Apple に送って報告し、テストの結果をオンラインに共有したものだった。そこで私は今回も、同様のバックアップ整合性検査のスクリプトを CloudBerry のために書くことに決めた。

検査の正確性を確保するため、私はもう一つ別のバックアッププランを作って保存先を指定し、圧縮・暗号化・ファイル除外などがすべて無効となっていることを確認した。そしてそのプランをたった一度だけ走らせて、CloudBerry のバージョン化機能が前回の動作以後に変更を受けたファイルという理由でファイルの複数個のコピーを作ることがないようにした。幸いにも、圧縮も暗号化もしない設定の下では、CloudBerry は単純にファイルやディレクトリのツリーをそのままミラーして保存先にコピーする。その結果、Time Machine を検査するために書いた時とほぼ同じ手間で、単純なスクリプトを書いてソースフォルダと保存先フォルダをファイル対ファイルで比較し、マッチしなかったものを報告するようにできた。

その結果は、あまり元気の出るものではなかった。私の検査スクリプトが出力した、明らかに要点のみのぶっきらぼうな結果をここにそのまま載せておこう。(そのスクリプト cb_audit.sh は皆さんもご自分でダウンロードして試して頂けるが、洗練されたユーザー体験とは程遠いものであることをあらかじめお断りしておきたい。) これは、私の Mac 上にある三つのホームディレクトリを、それぞれソース (/Users) と外付けドライブ上 (読みやすいように保存先のフルパス名を短縮して /Volumes/3T Spare と記してある) とで比較したものだ：

Daves-iMac-27:~ dkitabji$ sudo ./cb_audit.sh
Password:
----------------------------------
Auditing: /Users
----------------------------------
--------------------------
Listing: audrey
--------------------------
--------------------------
Listing: jack
--------------------------
--------------------------
Listing: ernie
--------------------------
sorting...
----------------------------------
Auditing: /Volumes/3T Spare/.../Users
----------------------------------
--------------------------
Listing: audrey
--------------------------
--------------------------
Listing: jack
--------------------------
--------------------------
Listing: ernie
--------------------------
sorting...
Calculating diffs...
File count in /Users: 307958
File count in /Volumes/3T Spare/.../Users: 7854
Directory size diffs:
1c1
< 106G audrey
---
> 309M audrey
1c1
< 3.4G jack
---
> 379M jack
1c1
<  21G ernie
---
> 2.1M ernie

出力のうち、次の２行に注目して頂きたい：

File count in /Users: 307958
File count in /Volumes/3T Spare/.../Users: 7854

ソースには 307,958 個のファイルがあるが、バックアップツリーの中でこのスクリプトが見つけたファイルはたった 7854 個しかなかった。まさにその通り、あなたの見間違いではない。

さて、ファイルの個数以外にも、私のスクリプトはそれぞれのディレクトリの全体としてのサイズも比較している。その結果の一つがこれだ：

< 106G audrey
---
> 309M audrey

つまり、ソースの方の audrey のホームディレクトリには 106 GB のデータが含まれているのに、CloudBerry がコピーしたのはたった 309 MB だけだということだ。私が圧縮機能を無効にしておいたこと、除外ファイルの指定も一切していないことを思い出して頂きたい。

皆さんもとてつもなく不安な気持ちになられただろうか？

私はこれらの結果を新着伝票として CloudBerry Lab へ送った。当初、サポート技術者たちは symlink に関係した問題ではないかと疑った。symlink とは Unix の世界で Finder のエイリアスに相当するもので、まだ正しく処理されていなかったからだ。幸いにも、上に示した出力とは別に、私のスクリプトは調べた対象のファイルすべてに関する詳細情報を舞台裏で保存していたので、ソースにあるのに保存先にないファイルがどれかを調べることも簡単だった。私は自分の職業的キャリアの大半をソフトウェアのトラブルシューティングに費やしてきたので、広範に存在する問題を解決するためにはたった一つか二つの具体的なケースに集中して問題の奥底を見極めることがいつも重要であることを知っていた。

そこで私は、一つの具体的なファイルにサポートチームの注意を向けた。それは写真で、バックアップされなかったのだが、これが symlink でないことは Terminal のリストを見れば一目瞭然だ (もちろん下記の出力の読み取り方を知っている人にとってはという意味だが、行の最初がダッシュ線であることから分かる)：

sh-3.2# ls -l 'audrey/Pictures/iPhoto Library.migratedphotolibrary/Thumbnails/2015/03/20/20150320-180831/1ZghV9P+TAWtlZPsw6uUNQ/IMG_8764.jpg'
-rw-r--r--@ 1 audrey  staff 47053 Mar 20 2015 audrey/Pictures/iPhoto Library.migratedphotolibrary/Thumbnails/2015/03/20/20150320-180831/1ZghV9P+TAWtlZPsw6uUNQ/IMG_8764.jpg

彼らはその伝票を一人のエンジニアへと昇格させ、そのエンジニアは会社の顧問会議のメンバーの一人にも CC で送った。そして彼らは私にさらなるトラブルシューティングの手順を踏むことを依頼し、この特定のファイルのみに注意を集中させた。最終的に彼らから届いた返事は、「この問題が Mojave のデータ保護メカニズムによって引き起こされていることに、私たちはかなりの確信があります」というものだった。

私は High Sierra を使っているのであって Mojave ではない、と私は指摘した。すると彼らは High Sierra ユーザーからも同種の問題の報告が届いていて、Apple が Mojave のセキュリティメカニズムの一部を High Sierra に逆移植しているからではないかと考えている (もしそうなら私たちも初めてその種の話を聞いたことになるが) と返答してきた。また、彼らは CloudBerry のエンジニアリングチームが修正のために取り組んでいるけれども、それより前に修正の必要なアップデートの未処理分が控えているとも言い添えた。

私はこの問題の緊急性を訴えた。私自身のためではなくて、彼らの会社の Mac 顧客たちのためだ。CloudBerry Lab が本当にこの問題の重大さを認識しているのかどうか知りたいと思って、私は自分が書いたメッセージの末尾に次のように付け加えた：

「現状では、これは壊れていて、信頼できず、私たち消費者にとって危険なデータ保護の幻想となっています。」

すると、CloudBerry Lab のエンジニアは私のこの主張には同意してくれた。

レビュー期間を通して、私は CloudBerry Lab のマーケティング・コミュニケーション・マネージャの Artem Kolesnikov と連絡を取り合っていた。私が経験したこの問題の本質を彼に説明した上で、私は彼にこのレビュー記事に彼自身の言葉で何か付け加えることがあればぜひ声明を提供してもらいたい、と持ちかけた。すると彼は次のような言葉を寄せてくれた：

「現在のところ、macOS のデータ保護メカニズムのため、一部の個人用ファイルがバックアップされないという問題があります。つまり "/Users/$USER/Library/" ディレクトリの内容です。

この問題は現在調査中で、近いうちに修正を出せるはずです。修正がすべてのテストを通過し次第、直ちに出版するつもりでおります。ご迷惑をおかけしていることを、公式にお詫び申し上げます。」

しかしながら、私が上で挙げた一つの実例でさえ、問題が ~/Library の内容のみに限られたものでないことを示している。どうか、CloudBerry Lab のエンジニアたちが私が提出した一連の詳細な伝票をよく吟味して、問題点の詳細を正しく理解し、適切な修正を施してくれるようにと願いたい。けれども、これほどはっきりした問題を私自身が見つけなければならなかったこと、彼らがこの問題についてユーザーたちに何ら情報を出していないことを思えば、将来にわたって CloudBerry を信頼できるという気持ちには到底なれない気もする。

バックアップ (一歩後退) して考え直そう

CloudBerry をレビューした他の記事で、楽しげにその機能一覧の多数のチェックボックスを一つ一つチェックした上で好意的な評価を付けているレビュー記事を私はいくつも見たことがある。それらのレビュー記事の筆者たちのうち何人が実際にこの製品を使って非自明なバックアップを実行してみたのか、それが本当に正しく動作したかを時間をかけて評価したのか、と私は思案せざるを得ない。

私だって、TidBITS コミュニティーに向けて、またもう一つ新たな素晴らしいバックアップ用アプリが登場したぞと告げる一人になりたいと心から思っていた。でも、私がそう思ったのは読者の皆さんがご自分のデータを保護するための手助けになりたいと思っているからなので、現時点で私にできる最良の助言は、CloudBerry Backup for macOS を使わないようにとお勧めすることだけだ。

今は亡き、人々の哀悼を集めた Dantz Development の言葉を引用しておこう。「前進するためには、まず一歩後退 (バックアップ) しなければならない。」皆さん、安全を第一に！

[Dave Kitabjian はもうかれこれ 30 年間にわたってソフトウェアを書き、インターネットと通信のサービスをデザインしてきた。1984 年以来の Mac オーナーで、自宅では 5 台の Mac を使いつつ、仕事場では Linux と Windows の開発をしている。時々は O'Reilly Media からテクノロジー系執筆の仕事を引き受け、キーボード、ベース、ギターを弾きこなして即興のジャズ演奏を楽しむこともある。]

討論に参加