この記事は、公私共にGoogle Workspace 1 から何とか離脱するための、個人的な検討の記録です。
はじめに
パブリック利用について
公私共に、ということで、まずは公、すなわち仕事用のGoogle Workspaceの件となります。私は、職業・職種の関係でIEEEに加入しています。加えて、所属組織というよりは個人名で仕事をすることが多いです。そして、所属組織はコロコロ変わります。このため、IEEEに加入していると利用できる、GoogleApps@IEEEを用いて、以下のような運用をしていました。
- 永続性が高いと判断したxxxx@ieee.org (i.e., GMailバックエンド)を、仕事における外部組織や関係者とのコミュニケーション、また各種仕事用サービスのアカウントに利用。外部での講演や発表した論文などにも、連絡先として記載。
- カレンダーによる仕事スケジュール管理。
- Driveでの仕事用データの管理・共有。
- メールデータが4GB程度、Driveで6GB程度を利用。
高めの会費2を払っており、契約段階では30GBがIEEEメンバーベネフィットとして利用可能ということで、上記のようにどっぷりと浸かっていました。しかし、2022年8月1日付で、GoogleとIEEEとの契約が変更になり、30GBの容量が2GBに削減され、なおかつ追加課金による容量増加は不可能 となってしまいました。3
IEEEからは「2023年8月1日までは30GB利用可能なように交渉しました」4 というメッセージがありましたが、Twitter検索をすると、すでに容量超過によりメール受信が不可能になっているという報告もあります。職業柄、外部公開しているメールアドレスは生命線と言っても差し支えないことから、私も一刻も早い対応をしなければならないという状況です。よって、パブリック利用については、まずは以下が条件となります。
- ieee.orgアドレスのメールデータ移行先・転送先サーバの確保(複数端末から参照するため、IMAP前提)。任意のアドレスへのメールリアルタイム転送は可能なたなめ、ieee.orgアドレスでのメール送信が可能な手法を確立する。
- カレンダーも利用可能な事。これはデータ量が多くないため、そのままGoogleApps@IEEEに残しておいても可。
- Driveのデータの移行先の確保。これは共有にも利用するため、ieee.orgアドレスでの共有招待などが可能な事。
- 1サービスに一極集中すると今回のようにサービスデグレーションの際に被害甚大なため、メール・Driveのサービスを分離する。
ただし、あくまで上記は暫定的・応急処置的な対処の条件であることを付け加えます。
プライベート利用について
次に、私事の部分。2022年1月に通知があった「G Suite Legacy」の終了の件となります。結局5月に非営利・個人であれば継続利用可能となりましたが、今後いつ利用不可能となってもおかしくありません。現状での利用形態は、
- 独自ドメインメールアドレス2つを運用。現在はそれぞれネットサービスのアカウント運用のための利用が主で、メール送信にはあまり使っていない。ただし、たまに友人とやり取りしたり、VPSで運用するサーバからlogwatchの報告を送るなど、SMTP自体の利用は低頻度で存在する。アドレス毎で1GBから2GBのデータがあるため、合計5GB程度あればしばらくは問題ない。
- 1つのメールアドレスで、カレンダーを利用してプライベートのスケジュール管理。
- Driveの利用はなし。
という状況です。よって、プライベート利用については、以下の2つが移行先の条件となります。
- 独自ドメインのメールアドレスを2つ運用可能。エイリアスでも可。SMTPも送信元を指定しつつ、何らかの形で利用可能であること。
- カレンダーも利用可能。メールアドレスと同じサービスでなくても構わない。
こちらは全く焦らなくても良いのですが、仕事用Google Workspaceの一件から、永続性を重要視して、今後の運用方法をまとめて検討していくこととしました。
暫定的な対処
メールデータについて
データ退避先・転送先
仕事用のieee.orgアドレスのメールデータについては、一刻も早い退避が必要です。このため、退避先および今後のメール転送先として、比較的早く移行できそうな以下の選択肢を検討しています。それぞれ、個人用の独自ドメインアドレスを受ける新サーバとしても検討しています。
- さくらのメールボックス
- ConoHa VPSメールサーバ(アプリケーションサーバ)
- 個人のGMailアドレス
- 個人のiCloudアドレス
- iCloud+
- VPSでのメールサーバのセルフホスト
検討に際して、前提条件としてieee.orgのSMTPサーバは利用可能、独自ドメインはCloudflareをレジストラ・NSとしてドメインのみ保持しているという状況を想定しています。レジストラやNSの移管が必要なサービスは除外します。
費用 / 年 | 全体容量 | クオータ/アカウント | 独自ドメインIMAP | 独自ドメインSMTP | 独自ドメインアドレス(エイリアス)数 | ieee.org SMTP経由での送信 | その他 | |
---|---|---|---|---|---|---|---|---|
さくらのメールボックス | 1,048円 | 20GB | 2GB | ○ | ○ | 無制限 | X | SPF対応 |
ConoHa VPSメールサーバ | 6,600円 | 10GB | 10GB | ○ | ○ | 無制限 | X | SPF+DKIM対応 |
個人GMailアドレス | 0円 | 15GB | 15GB | X | X | - | △ (GMail設定から可能) | 独自ドメインのメール受信は転送サービスで可能 |
個人iCloudアドレス | 0円 | 5GB | 5GB | X | X | - | X | 独自ドメインのメール受信は転送サービスで可能 |
iCloud+ | 1,560円 | 50GB | 50GB | ○ | ○ | 3 | X | Apple IDアドレスは利用不可 |
VPSでのセルフホスト | 5,000〜10,000円前後 | ?GB | ?GB | ○ | ○ | 無制限 | △ (SMTP-Relay) | 運用に難 |
GMailおよび無料のiCloudの場合は、Cloudflare Email Routingなどを介すれば、独自ドメインアドレスが受信可能となります。iCloud+の場合は、AppleIDに利用している独自ドメインのアドレスは利用不可能という制限があります。
GMailでは、別のSMTPサーバを経由したメール送信が可能ですので、ieee.orgのアドレスに対しては、退避先・転送先としてだけではなく、送信元としても稼働させることができます。ただし、ieee.orgからの送信は、後述するように既存のGoogleApps@IEEEのSMTPサーバを叩けば問題ありません。一方で、独自ドメインのメールを送信するためには、いわゆる「メールホスティング」を利用しなければならないです。
検討した結果、暫定対策および各種サービスを実際に利用して検討するため、以下の運用を開始しました。
- プライベートの独自ドメインメールアドレス
-> さくらのメールボックス - 仕事用ieee.orgアドレスの転送先
-> ConoHa VPSメールサーバ
これらに決めた理由は、ただでさえ依存しているGoogleやAppleにさらに依存してメールを運用することで、サービスデグレ時のダメージが甚大になることを防ぐ意味が大きいです。もちろん、さくらやConoHa、特にConoHaも5、いつサービスを打ち切っても不思議ではないです。ただ、単なるIMAP接続・Webインターフェース不使用・Push配信も利用しない、というダムパイプ的な使い方をする分には、何か起きても移行ダメージが少ないかなという判断です。
それ以外の理由として、移行するデータ量に合わせて、クォータサイズで選んでいます。加えて、ConoHaは利用期間が1ヶ月に満たない場合は時間課金となるため、一旦データを退避させてから移行先に移すというような使い方がしやすいのが選択理由となります。
もちろん一番融通が効くのはいわゆる「自鯖」なのですが…Cloudronとか使えば多少は楽なんでしょうが…
SMTPについて
仕事用アドレスについてはieee.orgとしての送信となるため、Google WorkspaceのSMTPサーバ(smtp.gmail.com)以外からの送信は、「なりすましメール」と見做される可能性があります。それを回避する方法として、
- smtp-relayにより、smtp-relay.gmail.comへ、別のsmtpサーバを介した接続を行う
- 直接メールクライアントからsmtp.gmail.comへ接続
の2つを検討しました。前者については、postfixをセルフホストする以外、前節で検討したサービスでは設定できないため、今回は除外しました。後者は、GoogleApps@IEEEの設定を端末(Mac/iOS)に残しておけば、SMTPを流用可能なため、大して手間はかかりません。IMAPは非Google、SMTPはGoogleを使うというキメラ状態とはなりますが、ひとまず問題なく送受信可能です。
カレンダーについて
プライベート用は個人のGMailアカウントへ、仕事用はそのままIEEEのGoogle Workspace上に残しておいてもよかったのですが、Googleにサービスをデグレされることに強い懸念があるため、今回はiCloudカレンダーで対処します6。カレンダーデータの共有等を行なっていないため、特に悩むこともありません。「Personal」「Work」の2つのカレンダーを作成し、そこへプライベート用カレンダー・IEEEカレンダーのそれぞれ全データを移行させました。
他、メールサービスと統合したカレンダーの選択肢として、
- Proton Calendar
- Tutanota
- FastMail
等も存在します。今回、これらは将来的な選択肢として採用を保留し、すでにアカウントを持っていたiCloudへの移行を行いました。
Drive上のデータについて
仕事用ieee.orgアドレスのみに関係する、ということで、これは特に考えませんでした。アカウントに利用するアドレスに加えて、ieee.orgのアドレスを含めて複数のアドレスが共有招待先として利用可能な、Dropboxを利用します。Dropbox Plusライセンスを追加購入しました。Google Drive同様に利用者が多いので共有で困ることもないと思います。Office365サブスクリプションのOne Drive (1TB) という手もあったかとは思いますが、買い切りのOffice Home & Business 2021を利用しているため、今回は検討していません。
NextCloudも検討はしましたが、ひとまずデータを逃しつつ今すぐ必要な共有データをどうにかするため、Dropboxを使うという判断を下しました。
今後について
今回検討した内容は、あくまで暫定対処となります。時間をかけてでも実現すべき、最も重要な条件は外部公開したメールアドレスに対する高い永続性の確保です。IEEEのアドレスは高い永続性があると考えていますが、今回のGoogleとIEEE間の突然の契約変更を鑑みると、それも懐疑的にならざるを得ません。このため、最終的には、
- メインとすべき、永続性の高い外部公開メールアドレスの新規確保。ieee.orgのメールが存続している限り、このアドレスへの転送を行う。
- 特許性なども含む可能性のある、秘匿性の高いメールを扱うため、プライバシ性が高いとなお良い。
というのが到達条件となります。表面的な解としては、プライベートのメールアドレス同様に、独自ドメインでのメールアドレス運用しかない7とは思いますが、そのバックエンドは何を使っていけばいいのかを検討する必要があります。
というわけで、現状、とにかくメールが気持ち悪いです。仕事用アドレスについてはIMAP/SMTPがキメラ状態であること、また結局GMailバックエンドに頼っていることに忌避感を覚えます。これについては、非IEEEかつ永続性の高い個人メールアカウントの運用に移行してIEEE利用をシュリンクしていくこと、およびプライバシを考慮したサービスを利用 or セルフホストを検討していくしか解決策がなさそうです。
個人用アドレスについては、さくらインターネットでお安くて十分ですが、クォータの2GB制限やDKIM非対応がネックです。こちらについては、ConoHaに移すか、いっそ「Cloudflare Email Routing + 受信用メールサービス」の方が良いかもしれません。この場合、SMTPがネックです。SendGrid使うなどの検討が必要です。
今回は、緊急性を要した暫定対処 (+ おまけでプライベートも対処) ということだったため、検討が足りていません。あらためて複数選択肢を並べて検討・実験して、「Google Workspace から離脱するための検討ログ (2)」を公開したいと思います。
参考
- https://zenn.dev/yakumo/articles/662f8e5a818d2d
- https://kylepiira.com/2020/01/09/why-i-quit-google/
- https://restoreprivacy.com
-
この記録では、G Suite, GoogleApps等をまとめてこう呼ぶこととします。 ↩
-
更新価格は現在183USD。毎年上がってます… ↩
-
通知は2022年8月4日にきました…。事後の規約変更通知ということで、おそらく相当に交渉が拗れたのではないかと予測しています。 ↩
-
交渉の結果への言及はなし… ↩
-
シンガポールリージョンの打ち切りでダメージを食らったばかりです ↩
-
五十歩百歩なんですが、Appleの方がGoogleに対してサービスの継続性については多少「マシ」感はあります。プライバシについてもマシだと思いますが、暫定対処については想定していません。 ↩
-
とりあえず頼むから、お金払ってる限り、死ぬまであるいは引退するまで有効なアドレスを確保させてくれ… ↩