#1535: Apple が "Hi, Speed" イベントを発表、Function101 の Apple TV 用リモコン、サードパーティ Apple Watch 文字盤がない理由、Mac 用 Gmail クライアント Mimestream

Apple の次の製品発表は 2020 年 10 月 13 日、10 AM PDT に同社の Apple Park 本社で開催される。前回のイベントと同様、Apple はクリック一つでカレンダーに追加できるようにしている。私たちの予想では今回もまたあらかじめ撮影された映像が使われるのだろうと思う。そうすることで、高い制作価値を生み出せるとともに、息つく暇もないペースで発表を進められるからだ。［訳者注： 翻訳時点でこのイベントは既に終了しています。イベントの内容についての記事は来週号をお待ちください。］

先月の "Time Flies" イベントでは iPhone の姿が全く見えず、Apple Watch Series 6 と新型 iPad のみが取り上げられた。(2020 年 9 月 15 日の２つの記事“Apple、Apple Watch Series 6 と Apple Watch SE を発表”と“Apple、iPad Air を再設計、基本モデル iPad を更新”参照。) 水晶球を持っている訳ではないが、今回のイベントで少なくとも新型の iPhone がデビューすることだけは賭けてもよい。"Hi, Speed" というキャッチフレーズが付いたということは、おそらくその次期 iPhone は高速の 5G セルラーサービスと互換になるのだろう。

Apple は 2020 年末までに高パフォーマンス Apple シリコンで構築した Mac を出すとも約束しているので、 このキャッチフレーズはその方面での発表またはアップデートを意味しているのかもしれない。(2020 年 6 月 22 日の記事“Mac、Apple シリコンで ARM へ移行”参照。)

HomePod と AirPods のラインアップへのアップデートもあり得る。Apple は最近 Bose、Sonos その他の競合するオーディオメーカーの製品を店頭から引き上げており、より小型の HomePod や、Apple ブランドのフルサイズヘッドフォンが登場するのではないかという噂が飛び交っている。

その他にも可能性は少し低いが考えられることとして、古くなりつつある Apple TV シリーズや、より安価で機能もそう変わらない iPad Air に比べてますます老いを感じさせている iPad Pro にも何かあるかもしれない。

何が登場するかは分からない！ でも、どうぞ私たちの SlackBITS グループの #events チャンネルに参加して、ご一緒にそれを目撃しませんか。もうかれこれ数年前から私たちはイベントの最中に読者の皆さんとおしゃべりして、毎回楽しい時を過ごしている。グループに参加するには slackbits.herokuapp.com に行き、あなたの電子メールアドレスを入力してから、行動規則に同意して頂くだけでよい。すぐに電子メールで招待状が届くはずだ。

討論に参加

私は、2015 年に Apple が第四世代 Apple TV HD と一緒に出荷し、その後も Apple TV HD と Apple TV 4K 用にデフォルトの選択肢として提供し続けているすべすべした Siri Remote を好きになったことがない。しかし、つい最近になって検討してみる価値がありそうに見える代替品を見つけた：Function101 Button Remote for Apple TV である。

Function101 ボタンリモートの長所

この $29.95 の赤外線リモートコントロールは、Apple TV を制御する時、Siri Remote の機能のほぼ全てを提供する - 少なくとも、私が気に掛けているものは。でも、皆さんが欲する機能のリストは大幅に違うかも知れない！ Function101 リモートのボタン列はより大型であり、受信機、サウンドバー、そして TV セットの音量の赤外線制御を提供するだけでなく、消音したり電源制御まで出来る。素晴らしい！

(Siri Remote にも、サポートする機器の音量を制御させてくれる赤外線送信機が付いている。しかしながら、Siri Remote には、消音ボタンが無いし、それに HDMI-CEC 対応機器の連携が正しく設定されていないと、他の機器の電源オンオフの制御は出来ない。)

Function101 リモートにはタッチ表面はなく、これは私にとっては大きなおまけである。私は Siri Remote のタッチベースの制御には何時も苦労している。私は、巻き戻し/早送りの部分を正しくタップ出来たことが殆ど無い。でも、他のタッチ機器では、例えば iPhone 上の Remote アプリ等、問題はないので、私のせいでは無いと思う。

Function101 リモートでは、前後に 10 秒間飛ばすための正真正銘のボタンがあるし、早送りと巻き戻しのためのボタンも別個にある - 押している間だけ働く。上部にある方位計状の４つの矢印は行き先誘導と他の機能を制御し、そして中央に位置する OK ボタンで選択をしたり、動作を確定したりする。

この成形されゴム化された機器はとても触感が良く、そして私はそのボタンの圧力、正確性、そして柔軟性がとても好きである。これは私が持ったことのあるリモコンの中でもトップクラスで、このレベルの品質と低価格を両立させた逸品である。

Function101 ボタンリモートの短所

技術と設計の制約から、欠けているものも幾つかある。Function101 リモートは赤外線で Apple TV と通信するので、Siri 音声制御には対応出来ない。(そこまで対応しようとすれば、値段はかなり高くなってしまうであろう。) 私は Apple TV 上で何かをするのに Siri を使うことは殆ど無い - 強いて言えば "10 秒巻き戻して" を、タッチパッドが言うことを聞かない時に使うぐらいで - そして、それももう必要ない。私の知っている人達の中には定常的に音声制御を使う人達もおり、これらの人達にはこの代替肢は役に立たない。(余り数は多くないが、私が Siri を使いたいと思う時には、iPhone でスワイプダウンして Control Center を出し、Remote アプリを呼び出す。また、iOS, iPadOS, そして macOS で通常の昔からの Siri を使って Apple TV に対するコマンドを出すことも出来る。)

スワイプすることでストリーミングビデオの全体に亘って早送りや巻き戻しするのは出来ない。これは我が家の下の子供が Siri Remote から離れられなくしている理由だという。私は、同じ事をするのに Function101リモート上でボタンを押し続けるのは厭わない。

これは赤外線コントローラーなので、サウンドシステム、テレビ、或いは Apple TV に対して物理的に見通せなければならない。設置を多少いじらなければならない場合も出るかも知れない。また TV ボタンも無く、その結果 Apple TV のアプリ切り替えは使えず、それが少々気になる人もいるかも知れないが、私が見つけた多くの他の長所が意味をなさなくなるわけでは無い。また、どのボタンも、スクリーンセーバーの場所を見るために、Siri Remote のタッチパッドの様に柔らかなタッチでタップすることも出来ない。

Function101 リモートは、箱から出した状態で Apple TV とは働くが、TV セットやサウンドバーの様なものとの初期設定は面倒な場合もある。と言うのも、このリモートには、遠隔でプログラムする方法も、数字ボタンも無いからである。数字入力を持つリモコンでは、通常マニュアルやオンラインガイドで自分のテレビ、受信機、或いはサウンドバーのモデルを見つけ、正しい赤外線制御組合せを見つける迄一連の数字を打ち込んで試験をする作業をする。それぞれの消費者向け電子機器ブランドは通常各種の機器にまたがって使われる幾つかの組合せを持っている。

Function101 ウェブサイト上の余り分かり易くない説明書には、同じ効果を出す方法が書いてある。まず、リモートを設定モードにし、対象の機器への見通しを失わないよう気をつけながら、一つのボタンを押下したり、繰り返し押したりする。音量上げの制御がリモートが循環して与えてくるコードで働けば、設定は完了で、OK を押す。私は、全ての A/V サウンド出力を経由させている古い Yamaha 受信機でこれを繰り返しやってみたが、最初はどうしても働かせられなかった。

私は顧客サポートに連絡を取ってみたが、初回出荷の量のせいで対応しきれないでいた。回答を得るまで２週間掛かったが、その間、私はこのリモートの Apple TV 機能は全部使った。ようやく回答を手にした時、そこには安っぽい謝罪、直通の電話番号、そして手順毎の助言書が含まれていた。この助言書は以前出版されていた取扱説明書よりは少し分かり易かった。私は、これを貰って数分後には受信機の操作が出来るようになっていた。ええ、その通り。それはユーザーエラーであったが、サポートサイトの出来の悪い説明書にも原因がある。

(私の混乱を解決したやり方？ コードを勧めるために該当するボタンを押下したり繰り返し押したりする間、オーディオ機器を細心の注意を払って見ていなければならない。出てくるコードは沢山あるのでボタンを押下するのには意味がある。しかしながら、２秒間のウィンドウの中で音量の変化に気付くか、或いはそのボタンを素早くリリースしなければ、もう一度最初からやり直さなければならない。)

Function101 ボタンリモートは、あなた向きか？

私以外の我が家の家族は Function101 リモートを好まない。何故ならば、彼らは Siri 音声制御とアプリ切り替えが欲しいからである。幸いにして、私は自分の直感に従わず、Function101 リモートを手にした後は Siri Remote を使わない事とした。従って、我が家族は Apple TV の箱に入ってきたものを使い続けられる。

しかし、Apple TV を制御するのに、優れた設計のボタンの気持ちいい押し心地を楽しみたい人のためには、私はこれを心底からお薦めする。これは、Apple からのもの以外で 2020 年に買った一番お気に入りのテック製品である。

討論に参加

Apple が 2015 年に Apple Watch をデビューさせて以来、そのユーザーたちはサードパーティ製の時計文字盤を望み続けてきたし、開発者たちも同じくらい長期間にわたってカスタム文字盤を作りたいと思ってきた。けれども、ユーザーや、開発者や、著名なポッドキャスターがいくら願っても、おそらくそれは実現されないだろう。

私は Apple のソフトウェアエンジニアとして watchOS の最初の２つのリリースで仕事をしてきた。だから、Apple Watch の内部的な得失の多くについて私は熟知している。現行バージョンの watchOS や Apple Watch ハードウェアについての内部情報は何も知らないけれども、Apple がサードパーティ製の時計文字盤をサポートする可能性が (皆無ではないとしても) 当面の間はないと考えられる理由が少なくとも４つある。

理由 #1： バッテリー寿命

Apple がサードパーティ製の時計文字盤を認めない主たる理由は、バッテリー寿命だ。Apple Watch Series 5 と Series 6 で、文字盤がほとんど常時表示されるようになった。文字盤を駆動するコードが可能な限り最小限の電力しか消費しないようにすることが、ここで極めて重要となる。Apple エンジニアたちはあらゆる努力を惜しまず注ぎ込んで文字盤のコードが電力効率の良いものであるようにした。

そうした努力の中には、静止表示よりアニメーションの方が電力を食うからという理由で秒針を隠そうといったような単純なトリックをはるかに超えるレベルのことが含まれている。Apple エンジニアたちは、watchOS がどのようにしてグラフィックスを表示するか、Apple Watch の GPU がどのように働くかについて詳しい知識を持ち合わせているし、好むと好まざるとにかかわらず、その情報は社内だけのものだ。彼らはどのグラフィックステクニックが最小の電力で働くかを知っている。彼らのアニメーションテクニックは可能な限り最高の電力効率を持つ。彼らは社内専用のグラフィックス API にアクセスすることができ、これはサードパーティの開発者たちの手の届かないところにある。加えて彼らは社内用のテストツールや測定ツールを持っており、それらのツールはサードパーティの開発者たちには提供されない。

Apple Watch が丸一日のバッテリー寿命を獲得したのは偶然ではない。Apple エンジニアたちは膨大な時間を費やしてコードを微調整することで電力効率を上げてきたのだ。毎晩、Apple の自動化されたビルドシステムが、ソースコントロールにチェックインされたコードの変更を使ってwatchOS の新しいビルド (daily build と呼ばれる) を構築する。(これはすべての Apple オペレーティングシステムについて言える、2020 年 7 月 8 日の記事“Apple のバージョン番号とビルド番号を解読する方法”参照。) Apple エンジニアたちはこの daily build を使うので、全員が最新バージョンの watchOS を走らせている。

この daily build は電力テスト用実験室に並んだ Apple Watch にもロードされる。そこでは通常の使用をシミュレートした一連のスクリプトを走らせて、バッテリーがどの程度保ったかがチェックされる。テストの結果は社内用のウェブダッシュボードに掲載され、ここですべての watchOS ビルドでのバッテリー寿命が追跡される。もしもバッテリー寿命が短くなれば、その原因を見つけて修正する仕事がエンジニアたちに割り当てられる。Apple Watch チームにとって、バッテリー寿命は強迫観念に近い。

いくら有能で勤勉であったとしても、サードパーティの開発者たちにはまず何より内部的なグラフィックスの知識も、プライベートな API へのアクセスも、テスト用ツールもないので、Apple が要求する程度までバッテリー寿命について厳密にはなれない。仮に Apple が今すぐ文字盤の開発をサードパーティの開発者に開放したならば、まず間違いなくバッテリー寿命が落ちることになり、ユーザーにとっての Apple Watch 体験が悪化することになるだろう。

理由 #2： バグのあるコード

文字盤を駆動する watchOS のコードは毎日 24 時間走り続け、それが何か月も休みなく続く。だから、可能な限り完全にバグがなくなっていなければならない。腕時計をちらっと見たら文字盤がフリーズしたり、クラッシュしたり、表示の不具合が見えていたり、といったことは許されない。Apple Watch チームは時計のコードに膨大な量のテストを施している。エンジニアたちは自動化されたテストも手動のテストも走らせ、何千人もの Apple 従業員たちを採用して watchOS のベータ版を使わせ、問題が起これば報告させている。

私が Apple で働いていた年月の間に、私は Apple の Software Quality Assurance (SQA) エンジニアたちに深い敬意を抱くようになった。彼らは素晴らしい仕事をする。ソフトウェアがバグを持ったまま出荷されてしまった場合、たいていそれは SQA が問題を報告しなかったからではなくて、スケジュール上そのバグを追跡して修正するだけの時間がなかったからだ。(2020 年 6 月 17 日の記事“修正が実現するように Apple にバグ報告する方法”参照。)

これに匹敵するテスト用リソースを備えているのは最大規模のサードパーティ開発者、例えば Microsoft や Google などだけだ。小規模の開発者たちはおそらく時計文字盤のコードのために必要な品質を保証することができないだろう。たとえできたとしても、あっという間に App Store にどっと出回るであろう時計文字盤をテストするためにあまり多くの時間を費やしていては経済的に採算が取れないだろう。また Apple の側でも、サードパーティの時計文字盤を App Store に受け入れることに伴い自らもそこまでのレベルのテストをしなければならないのは受け入れにくいだろう。

理由 #3： Apple のイメージ

いくら控えめに言っても、Apple がイメージを極めて重視する会社であることに間違いはない。Apple は自らの公的人格のあらゆる細かな点に気を配る。それは Mac の Desktop 背景画像から iPhone のカラー、さらには Apple ストアのテーブル板の微妙な色調にまで及ぶ。Steve Jobs は iPod と iPhone 用のイヤーバッドの白の色調を選ぶ際に、白いケーブルの色調を実際に何十も見比べて検討した。

時計文字盤は、Apple Watch の公的な外観だ。誰かが Apple Watch を身に着けていれば、人がまず見るのはその文字盤だ。だから文字盤は美しく、現代的で、洗練されていなければならない。

確かに、美しいアプリを作っているサードパーティの開発者たちはいる。しかしながら App Store をざっと見渡せば分かる通りに、つまらないデザインのアプリはたくさんあり、どうしようもなく醜悪なものはもっと多い。

Apple は Apple Watch がケバケバしい、イライラする、あるいはまったくもって不快な文字盤を備えることを望まない。たとえそれがあなたが望むものであったとしても。また、Apple は文字盤が時計に表示された状態でも十分に洗練されて見えるか否かを判断するビジネスに参入することも望んでいない。Apple は自社のデザイナーたちが高度にカスタマイズ可能な幅広い種類の文字盤を作る際に良い仕事をしていると考えており、実際 watchOS のアップデートごとに新たな文字盤を追加している。

理由 #4： 著作権の懸念

Apple 社内で関わり合いになりたくない部門を一つ挙げよと言われたなら、それは Apple Legal (法務部) だ。Apple は、時計文字盤を巡って著作権侵害の訴訟を争うために時間と資金を費やすことを望まない。クラシックな文字盤の多くには、例えば Apple Watch Hermès のために Apple がライセンスを受けている Hermès 文字盤には、著作権が伴っている。ビンテージの文字盤もスマートウォッチが存在するより前の時代にデザインされているので、そのような文字盤にデジタル使用のライセンスを受けるためにはデジタルなライセンスのことなど理解していないかもしれない著作権所有者と交渉する必要がある。さらに悪いことに、App Store は何十もの国に対応しているので、著作権所有者が国ごとに違う可能性もある。これはまさに、法律的悪夢だ。

Apple は文字盤の著作権について熟知している。Apple Watch が存在するより何年も前に、Apple はスイス連邦鉄道サービスに 2,100 万ドルものライセンス料金を支払わなければならなかった。その象徴的な Mondaine 時計文字盤を iOS 6 用に“脚色”したからだ。

個々の時計文字盤を販売できる法律的権利を持っていることを開発者が証明するようにと Apple が義務付けることもできるだろう。けれども Apple にはその開発者が真実を言っていることを検証できる手段が何もないし、Apple に資金が大量にあるというだけの理由であらゆる著作権侵害訴訟で Apple が名指しされることは避けられないだろう。

Apple が初めて iTunes Music Store を開始した時点で、Apple が運用をしているすべての国でそれらの楽曲を販売する法律的権利を獲得するために Apple は弁護士たちのちょっとした大軍を必要とした。Apple Music が曲の歌詞を提供できるようになるために非常に長い時間がかかった理由の一つは、歌詞が音楽とは別にライセンスされているからだ。

コンプリケーションが救いの手に？

Apple は時計の文字盤をカスタマイズしたいというユーザーの欲求を満足させられる機能を自らが備えていると考える。その機能とは、サードパーティ製のコンプリケーションだ。コンプリケーション という用語は機械式時計の世界から来たもので、文字盤に表示される時刻以外の追加情報のことだ。機械式時計によく見られるコンプリケーションには、日付、曜日、別のタイムゾーンでの時刻などがある。

Apple Watch のコンプリケーションは、サードパーティのアプリが Apple の文字盤の上に追加情報 (通常はごく少量のテキストかグラフィックス) を表示することを許容する。watchOS はコンプリケーションのための図形やスタイルをいくつか提供しており、大多数の文字盤はその上にいくつかの異なるコンプリケーションを表示することができる。

コンプリケーションが表示できないものは時刻だ。それは時計文字盤そのもののために取り置かれている。人気ある Apple Watch コンプリケーションとしては天気があり、気温とともに現在の天候を示す小さなアイコンを表示する。

これらのコンプリケーションはアプリの一部ではあるが、そこには特別な制約がある。コンプリケーションのコードはデータ (例えばその日の天気予報) を集めて、それを静的なデータ構造として watchOS に渡す。そのデータ構造には個々のデータ記録をいつ表示するかの詳細情報も含まれる。watchOS は一度に一つずつのデータ記録のみを表示し、時間が経てば表示を更新し、コンプリケーションがさらなるデータをロードする時が来るまでそれを続ける。このシステムは予測可能な、ゆっくりと変化するデータ、例えば天気や、海の潮汐や、月の満ち欠けなどに適している。例えば株価のように頻繁に更新される必要のあるデータには適していない。

Apple がサードパーティのコンプリケーションをこの方法でデザインしたのは、バッテリー寿命を保護するためだ。コンプリケーションのコードが走るのはほんの数秒間、一時間あたりほんの数回ずつであって、電力を消費し過ぎないようになっている。ほとんど常時、watchOS はただ静的なデータを使ってコンプリケーションの表示をしているだけだ。通常はこれでうまく行くが、コンプリケーションの中に表示できるものの範囲に限界があることは間違いない。

watchOS 7 がカスタマイズを拡張

watchOS 7 になって、サードパーティの文字盤を望む声に対して Apple が実際にそこまで行くことはせずに応えたいとどれほど真剣に考えているかが見て取れる。変更された点としては、同じアプリからの複数個のコンプリケーション、文字盤の共有、かなり多数の新しい文字盤がある。

• 一つの時計文字盤の中に同じアプリから複数個のコンプリケーションを表示できるのは比較的マイナーな変更と感じられるかもしれないが、結果としてアプリに対してずっと多くの柔軟性が与えられ、複数のコンプリケーションを使ってずっと多くのデータを表示でき、ユーザーがそれらのコンプリケーションを好きなやり方で配置できるようになる。
• 文字盤の共有も、何となく大したことがないように思えるかもしれないが、ユーザーたちは多くの時間を費やして文字盤とコンプリケーションをカスタマイズするものだ。ものごとがきちんとなるためにはかなりの労力がかかることもあるので、自分がカスタマイズした文字盤を友だちに見せびらかしてきた人は、これからは手軽にその人たちと共有できる。
• Apple は watchOS 7 で 7 つの新しい文字盤を追加した。今回の新しい文字盤は Artist、Chronograph Pro、Count Up、GMT、Memoji、Stripes、それに Typograph だ。ご覧の通り Artist、Memoji、Typograph の 3 つは比較的機能の少ない文字盤と言えるが、それ以外の 4 つは多数のコンプリケーション用スロットを提供し、他にもいろいろカスタマイズの機会を提供している。

これらの新機能により、ユーザーは自分の腕時計をかつてないほどパーソナルなものにすることができる。将来のバージョンの watchOS でも、きっとさらなるカスタマイズのオプションが予定されているに違いない。それでもなお、サードパーティ製の時計文字盤はおそらく登場しないだろう。

討論に参加

デスクトップコンピュータ、例えば Mac の上で、ウェブブラウザのウィンドウの中で Gmail を使うのは簡単なことだ。それこそまさに、Google が意図している利用方法だ。

でも、多くの Gmail ユーザーたちはウェブブラウザの中でなくデスクトップの電子メールアプリを使いたいと思っている。例えば、Apple の備え付けの Mail アプリがまず頭に浮かぶ。それもまあまあ使えるやり方だが、完全とは言えない。それは、Gmail のラベルと、電子メールクライアントが使う IMAP 標準の持つ制約との間のアーキテクチャ上の食い違いによるものだ。Joe Kissell は著書 Take Control of Apple Mail の中でまるまる一つの章を割いて Gmail と Apple Mail が協力して働くようにする方法を論じているが、それでもなお非互換性は残る。

そのような問題点を一掃することを目指す新しいデスクトップ用電子メールアプリがある。Mimestream という名前で、元 Apple エンジニアの Neil Jhaveri が作っている。これは Gmail のために最初からデザインされた Swift アプリだ。ただログインするだけで動き出し、電子メールを適切に動作させるためにいじくり回すことなど一切必要なく、お馴染みの Gmail 機能が期待通りに働く。Apple に在職中の 2010 年から 2017 年までの間、Jhaveri は (他の製品でも働いたが) Apple Mail に取り組んでいた。

Mimestream はまだ開発中の、紛れもなく未完成品であり、Jhaveri は現時点で未対応の Gmail 機能を数多く記したリストを出している。それでもこのアプリは既に私たちの興味をそそるものを十分備えているので、ここで紹介したいと思う。言うまでもなく、この記事はアプリの公式なレビューではない。

Mimestream はいずれ有料アプリになるけれども、ベータ版である間は無料で使える。

Mimestream は macOS 10.15 Catalina またはそれ以降でしか動作しない。なぜなら、Jhaveri によれば最新バージョンの macOS でしか利用できない API や機能 (例えば SwiftUI) を使っているからだ。「Mimestream は Mac にある最良のものを披露することを意図しています。ですから新しいバージョンならば一般的に最新バージョンの macOS を必要とするのです」と Jhaveri は言う。

どの程度 Mimestream は似ているか

表面的には、Mimestream は他の Mac ネイティブな電子メールプログラムとそれほど違っては見えない。

３つの縦長の枠があって、ほとんど Apple Mail と見間違えそうだ。左側にあるサイドバーで自分の Gmail アカウントやそれぞれのさまざまのメッセージ保管場所や識別子をナビゲートし、メッセージのリストを表示する真ん中のカラムと、個々のメッセージが開く右側の枠がある。

ネイティブな Mac アプリなので、Mimestream はそこに期待される機能を持つ。例えば、メッセージのキャッシュ、オフライン対応、macOS 通知、キーボードショートカット、ツールバーのカスタマイズなどがある。

Jhaveri によれば Mimestream ユーザーはかなり良いパフォーマンスを期待でき、それにはいくつかの理由があるという。具体的には、Mac の複数コアを活用することでこのアプリはマルチスレッドに対応し、ユーザーのアクションと並行してバックグラウンド同期を実行できる。

どの程度 Mimestream は違うか

Mimestream と Apple Mail との違いは IMAP (Internet Message Access Protocol の略語) から始まる。一般的にデスクトップの電子メールプログラムはこのプロトコルを使ってメールサーバとの間でメッセージを同期している。Apple Mail が Gmail にアクセスする際にもこれを用いる。それは従属的になされるが、そのやり方は不十分かつ奇妙なものだ。

Joe Kissell が上記の著書の中で次のように書いている：

Gmail による IMAP の実装は極めて非標準的なものだ。どんな風に切り取ってみても、Mail の中で Gmail を使う体験は従来型の IMAP サーバを使っているようには感じられないし、ウェブブラウザの中で Gmail を使っていて慣れ親しんだ感覚で期待するものを反映しない。それはこの両者を奇妙に、かつフラストレーションを起こしやすい具合に混ぜ合わせたものとし、それを全く気にしない人はいるけれども、あまりにも苛立たしいと感じて Mail か Gmail のどちらかを使うのをやめてしまう人もいる。

公平を期して言えば、Google はデスクトップの電子メールクライアントを使いたい人たちの便宜を図って Gmail に IMAP 対応を後付けしたのであり、その根幹において Gmail は決してメールを IMAP と同じやり方では見ていない。

Mimestream は大体において IMAP を避けて通り、その代わりに Google の Gmail API を利用して Gmail のウェブ機能を Mac デスクトップの上により忠実に再現しようとする。結果として、Gmail の機能の多くが既に Mimestream の中に見事に移されている。具体的には：

• ラベル： これは Gmail の看板機能の一つだ。ラベルとはあなたがメッセージに付与するタグで、あとでそれを見つけやすくするためのものだ。一つのメッセージが複数個のラベルを持つことができる。Apple Mail はここで困難に行き当たる。なぜなら、Apple Mail はラベルをメールボックスとして扱おうとするが、それらは同じものでないからだ。(一つのメッセージは同時に一つのメールボックスにしか存在することができない。) Mimestream はネイティブにラベルをサポートする。
  
• エイリアス： これは、メールを送信する際に他のアカウントからのアドレスを有効な From アドレスとして認める Gmail のオプションのことだ。Apple Mail の中でこれが動作するようにするためには少々手を加えることが必要で、Joe Kissell の本にその方法の説明がある。けれども Mimestream では自動的かつシームレスに動作する。
• 検索： 標準的な Gmail の検索クエリーがサポートされており、キャッシュされたメッセージを通じてオフライン検索ができる利点もある。
• 署名： 驚いたことに、私のさまざまの Gmail アカウントで苦労して作り上げた署名が、Mimestream ではすべて Gmail のウェブアプリの中と全く同じに現われた。(ただし Mimestream の中で署名を編集することはできない。) 一方 Apple Mail では Gmail の署名は現われず、改めて作り直さなければならない。
• Inbox カテゴリー： これは比較的最近 Gmail に登場した機能で、受信箱を Social、Promotions、Updates、Forums と呼ばれる 4 つの区分に切り分けることができるオプションだ。Mimestream の中にもこのオプションを使える柔軟性があって、たとえあなたが Gmail ウェブアプリの中でそのように設定していなかったとしても使える。

Mimestream は大体において IMAP を避けて通るので、職場や学校のアカウントで Gmail を使っている人を悩ます可能性のある問題が解決する。ネットワーク管理者は IMAP をオフにすることがあるが、その場合はユーザーがデスクトップのアプリを使いたくても Gmail のウェブアプリを使わざるを得なくなる。実際私の職場でもそうなっているのだが、Mimestream は何の問題もなく電子メールをダウンロードしてくれる。

ただしそこにはちょっとした欠点がある。Mimestream は電子メールの push には IMAP を利用するのだが、バックエンドで IMAP が無効化されているアカウントではその機能が欠落している。その結果として、私は仕事用のメッセージを時々手動で取りに行かなければならない。

メッセージのダウンロードに際しての IMAP ブロックに対するこの回避策は、必ずしもいつまでも使えるとは限らない。Jhaveri は次のように説明する：

_IMAP がオフの状態でさえも Gmail API がオープンのままであるという事実は、おそらく Google がうっかり見落としたものでしょう。なので、将来のどこかの時点で塞がれてしまったとしても驚くには当たりません。私が計画した利点でないことは確かですし、ましてや予期してなどいませんでした。_

それを念頭に置いた上で、Jhaveri は IMAP 接続を必要とせずに Gmail API で直接 push が働くようにする方法を探しているところだと述べた。

Mimestream はどこへ向かうのか

さきほど述べた通り、Mimestream はまだ Gmail ウェブアプリの代替として使える段階には至っていない。数多くの重要な機能が欠けているからだ。そのいくつかは Jhaveri の計画表に載っていて今後のバージョンで実現されるだろうが、Gmail API によってサポートされておらず当面の間は実現の見込みがないものもある。欠けている機能のすべてをここに列挙するつもりはないが、Mimestream の FAQs ページに行けば詳しい説明がある。

将来のバージョンの Mimestream に含められる予定の機能としては次のようなものがある：

• 未読によるフィルタ分け： これを必須の機能だと思う人たちもいる。TidBITS 出版者の Adam Engst は現在の形の Mimestream が使い物にならない理由を「一つのラベルの中の未読のメッセージだけを表示する方法がないからで、これは私には重要な点だ」と述べた。
• Priority Inbox： Inbox のカテゴリーはサポートされているけれども、Mimestream はまだそれに似た Priority Inbox (優先トレイ) 機能を処理することができない。これは、メッセージを自動的に重要、未読、スター付き、およびその他のメールに並べ替える機能だ。
• Move To メニューコマンド： 現時点ではメッセージをラベルの上へドラッグする必要があるが、これは必ずしも一番楽なやり方ではない。
• 送信取り消し： 送信ボタンをクリックしたとたんにメッセージに何か書き加えなければならなかったと思い出す、というのはよくあることだ。送信取り消しは、キューに入れたばかりのメッセージの配送を中止する機会をごく短時間だけ提供する。
• サーバ側フィルタの編集： 現状では、フィルタの管理は Gmail ウェブアプリの中でするしかない。Gmail にログインする必要なしにフィルタの作成や変更ができれば素敵だろう。
• 購読中止のショートカット： 販売促進の電子メールには多くの場合購読中止のヘッダが含まれており、電子メールアプリがそれを使って手軽に購読中止をできるインターフェイスを作ることができる。
• 不在通知の自動返信の編集： これもやはり、現状では Gmail にログインしなければならないが、そうである必要はないはずだ。

さて、Gmail API でサポートされておらず当面の間は Mimestream に登場する見込みがない Gmail 機能としては次のようなものがある：

• メッセージのスヌーズ： Gmail のウェブアプリでは手軽にメッセージにスヌーズコマンドを使ってそのメッセージを隠し、指定した日時に再び見えるようにすることができる。Mimestream 専用のスヌーズ機能を現在考慮中だ。
• スケジュール送信： 時には、キューに入れたメッセージが将来の特定の時刻に送信されるようにしたいこともある。
• 会話のミュート： 会話があまりにも盛り上がって、通知の連続に圧倒されてしまうこともあるだろう。

他の分野で Mimestream と Gmail のウェブアプリが急激に、劇的に相違しつつあるところもあることを知っておくことは重要だ。例えば、Google は最近になって Meet ビデオ会議や Chat メッセージングを Gmail のウェブアプリの中へ統合した。以前には、Calendar、Tasks、および Keep ノートで同じことをしている。この種の統合は少なくとも Mimestream の短期的な計画表には載っていない。

Mimestream はあなたに向いているか？

この質問には、おそらくあなたがご自身ですぐに答えられるだろう。なぜなら、Gmail ファンたちの間で、Mimestream は２つの直感的反応のいずれかを引き起こす傾向が強いからだ。片方は「おお、この素敵な奴が完成するのが待ちきれない」というもの、もう片方は「どうでもいい」というものだ。

Mimestream に興味をそそられてはいるものの、正直に言えば私は後者の仲間に属する。私としては、Gmail のウェブアプリが 14 年以上の期間を経て魅力的で、柔軟で、パワフルなものになっていると思う。

けれどももしあなたがデスクトップアプリの方を好むのならば、Mimestream 以外にも選択肢はある。その中にはアプリというのは名ばかりで、単に Gmail のウェブインターフェイスを独立の Mac ウィンドウの中に埋め込んだラッパーに過ぎず、使用体験にほとんど何も追加されていないものもいくつかある。

そういうものとは別に、もっと野心的で Gmail のウェブインターフェイスを Mac の機能と組み合わせてハイブリッドな体験を生み出しているものもある。その一例が Mailplane で、Adam も私もかなり長期間これを使ったことがある。(2020 年 8 月 17 日の記事“Mailplane が Chrome 化して機能を追加”参照。)

それからまた Kiwi もある。こちらもハイブリッドの Gmail アプリで、特に Google の他のウェブアプリ、例えば Google Drive、Google Docs、Google Sheets、Google Slides といったものを多用する人に向いている。それぞれが独立のウィンドウの中に現われるので生産性が高まり、そのため Google のサービスを全部使っていてウェブ環境の中でマルチタスクの快適さを望む人には Kiwi が良い選択と言えるだろう。

Mailplane と同様、Kiwi も Gmail のウェブインターフェイスを出発点としているので、さきほど述べた Google 統合、例えば Chat、Meet、Tasks、Keep も問題なく働く。

けれども Mimestream はオフラインでもフルに動作する Gmail フレンドリーなデスクトップアプリという隙間分野を確保することができるかもしれない。これは、ビジネスで旅行する人など、Gmail のウェブアプリがまともに使えないほど不確かなインターネット接続に対処しなければならない人にとっては理想的と言えるだろう。

Mimestream はまだ発展の初期の段階にあり、決定的な判断を下すにはあまりにも早過ぎる。でも、私たちはその進展を心待ちにしつつ見守りたいと思う。

討論に参加