どこか1社を失っても立て直せるアカウント管理 ── Gmail から独自ドメインへの移行と全アカウントの棚卸し

ある日、X で Google アカウントが BAN された、乗っ取られたという話をいくつか見かけた。自分のアカウントを振り返ってみると、多くのサービスに Gmail で登録していて、「Google でログイン」で作ったアカウントが多い。Google アカウントを失えば、それらにまとめて入れなくなる。BAN は自動判定で起きることもあり、自分に落ち度がなくても防げない。Google がログイン手段もメールもデータも一手に担っている状態に、急に危機感を覚えた。

Claude に相談してみると、独自ドメインのメールアドレスに移行することを提案された。調べてみると、独自ドメインと Google 以外のメール事業者を組み合わせて、Google を単一障害点にしないようにしている海外の開発者の事例 ¹ がいくつか見つかり、真似してみることにした。

メールアドレスを変えるならアカウントを1つずつ見直すことになるし、見直すなら認証や復旧の手段も考え直したくなる。結局、パスワード管理ツールやセキュリティキーの扱い方を含めて、アカウント全体を棚卸しすることにした。

この記事では、独自ドメインのアドレス運用の最終的な構成、認証や復旧の手段をどこに置くかの考え方、棚卸しの進め方を個人の事例として記す。

目指した状態

ゴールは、ドメインやメール、パスワード管理ツールなど、アカウントの土台を担っている事業者のうち、どこか1社へのアクセスを失っても、残りから立て直せる構成にすることだ。これに向けて、次の原則を置いた。

• ログインを特定の事業者のアカウントに依存させない: 「Google でログイン」や「Apple でサインイン」で作ったアカウントは、Google や Apple のアカウントを失うと、ログイン手段そのものを失う。ソーシャルログインは解除し、メールアドレスでログインするようにする。
• アドレスの所有権は自分のドメインで持つ: メール事業者は差し替え可能な部品として扱い、事業者を失ってもドメインごと別の事業者に移せるようにする。
• 認証手段を複数登録する: パスキーや TOTP、バックアップコードなど複数の認証手段を登録し、どれかを失っても入れるようにする。
• 復旧手段を、復旧したいものと一緒に失わないようにする: 復旧用のアドレスや認証手段が、復旧したいアカウントが使えなくなったときに一緒に使えなくならないようにする。

全体構成

最終的には、ドメインを Cloudflare、メールを Fastmail、認証情報を 1Password に置き、Gmail は一部のアカウントの復旧窓口として残す形になった。

事業者	役割	ログイン用アドレス	復旧用アドレス
Cloudflare	独自ドメインの管理 (レジストラ + DNS)	@gmail.com	―
Fastmail	メールボックス、サービスごとのアドレス	@fastmail.com	@gmail.com
1Password	全アカウントのパスワード・パスキー	独自ドメイン	―
Google (Gmail)	Cloudflare のログイン用、Fastmail の復旧用	@gmail.com	独自ドメイン

この4つは、他のアカウントを取り戻すときの起点になるので、後述する棚卸しの優先度で最上位の P0 とし、「P0 アカウント」と呼んで扱いを別にしている。

P0 アカウントの認証と復旧経路

P0 アカウントには、それぞれ次のものを登録している (1Password に関しては後述する)。

用途	手段	置き場所
ログイン	パスワード、パスキー	1Password
ログイン	パスキー (Fastmail と Google のみ)	YubiKey
2FA	TOTP	1Password
2FA	セキュリティキー	YubiKey
復旧	バックアップコード	バックアップ用のディスク

普段は 1Password だけでログインできるので、備えておく必要があるのは、1Password にログインしている端末をすべて失うなどして、1Password の中身を見られなくなった場面だ。このときは、新しい端末で 1Password にログインし直す手段や、それが駄目なら各アカウントを復旧する手段が必要になるが、いずれも 1Password の外に用意しておく必要がある。

1Password への再ログイン

まずは、新しい端末で 1Password にログインし直す。それには、1Password アカウントのパスワードと Secret Key に加えて 2FA が要る。パスワードは脳内に、Secret Key は Emergency Kit にある。Emergency Kit は、1Password のリカバリーコードと一緒にバックアップ用のディスクに置いている。

2FA の置き場所は悩んだ。1Password の 2FA には、認証アプリ (TOTP) とセキュリティキーを登録できる。TOTP の置き場所の候補は、だいたい次のとおりだった。

• 1Password の中: 金庫の鍵を金庫にしまうのと同じで、意味がない。
• バックアップ用のディスク: このディスクには、Emergency Kit の他にリカバリーコードがある。リカバリーコードを使えば、登録メールでの確認だけでパスワードを再設定できる ²。ここに TOTP まで置くと、ディスクの中身を取られたときに、残る壁はパスワードか、登録メールの受信箱のどちらか1つだけになり、2FA の意味がなくなる。
• Google Authenticator や Apple の「パスワード」アプリ: 端末をすべて失った場面では、同期を復元するのに Google や Apple のアカウントへのログインが必要になる。そのパスワードは 1Password の中にあるので、循環依存になる。

最終的に、TOTP は YubiKey に保存することにした。YubiKey に登録した TOTP の秘密鍵はキーの外に取り出せないので、PC やディスクの中身を取られても一緒には手に入らない。同期のためのアカウントも要らないので、循環依存にもならない。Yubico Authenticator で、タッチしないとコードが表示されない設定にして登録している。

これでもまだ YubiKey を失ったケースが残っているため、念には念を入れて、TOTP の秘密鍵を紙に控えている。

紙の控えと YubiKey は、ディスクの中身と違ってネットワーク越しには取られない。ディスクは暗号化しているので、仮に物理的にまとめて盗まれたとしても、Secret Key やリカバリーコードまでは読まれない。

各アカウントの個別の復旧

それでも万が一 1Password にログインし直せなければ、考えたくもないが、各アカウントを個別に復旧することになる。1Password のアカウント自体を失った場合も同じだ。

Fastmail と Google には YubiKey にもパスキーを登録しているので、YubiKey があれば PIN を入力するだけでログインできる。YubiKey も使えないときは、次の順に取り戻す。

1. Fastmail を復旧用の電話番号に届く SMS のコードとリカバリーコードで取り戻す ³
2. Google を復旧用の独自ドメインのアドレス宛に届くコードなどで本人確認して取り戻す (Fastmail で受け取れる)
3. Cloudflare をログイン用の Gmail に届くメールで取り戻す

Fastmail の復旧用アドレスにも Gmail を登録しているが、Gmail の復旧には Fastmail の受信箱が要るので、この場面では電話番号を使う。全端末を失っていれば SIM も手元にないので、先に SIM を再発行する必要がある。

Cloudflare のログイン用アドレスに Gmail を使っているのは、独自ドメインのアドレスにすると、ドメインを管理するアカウントの復旧をそのドメインのメールに頼る循環依存になるからだ。他者の事例でも、レジストラ専用に Gmail のアドレスを使っているものが多かった。

アカウントの復旧時の 2FA にはバックアップコードかセキュリティキーを利用する。TOTP は 1Password の中にあるため、この場面では利用できない。

アカウント自体や YubiKey、ディスクを失ったとき

ここまでは、1Password の中身を見られなくなった場面を見てきた。それ以外に、他の P0 アカウント自体を失った場合と、YubiKey やバックアップ用のディスクを失った場合がある。それぞれどう立て直すかをまとめると次のようになる。

失うもの	立て直す手段
Cloudflare	なし。ドメインの登録者は自分なので、ICANN のルールに従ってレジストラに認証コードを請求すれば、他のレジストラへの移管を求められる 4
Fastmail	移行先のメール事業者で全アドレスを受け取れるようにしてから、Cloudflare で MX を移行先に向ける
Google	Cloudflare と Fastmail に 1Password でログインし、Google アカウントを作り直すなどして、Cloudflare のログイン用アドレスと Fastmail の復旧用アドレスを差し替える
YubiKey	ログイン済みの端末から 1Password の 2FA を設定し直す。各アカウントには 1Password 上の認証情報でログインし、新しいキーを登録する
バックアップ用のディスク	ログイン済みの端末から 1Password の Emergency Kit とリカバリーコードを用意し直す。各アカウントには 1Password 上の認証情報でログインし、バックアップコードを発行して保存し直す

独自ドメインのメールの設定

独自ドメインのメールを Fastmail で受け取るには、Fastmail が指定する DNS レコードを、ドメインを管理している Cloudflare に追加する必要がある。Fastmail の設定画面でドメインを追加すると必要なレコードの一覧が表示されるので、それを Cloudflare の DNS の設定画面から1件ずつ追加した。Cloudflare には受信したメールを転送する Email Routing の機能もあるが、メールボックスは Fastmail に置くので使っていない。

実際に設定したレコードは次のとおりだ。

種類	名前	値	用途
MX	hamakou108.com	us1-smtp.messagingengine.com (優先度 10)、us2-smtp.messagingengine.com (優先度 20)	受信
TXT	hamakou108.com	v=spf1 include:spf.messagingengine.com ?all	SPF
CNAME	fm1._domainkey.hamakou108.com (fm2、fm3 も同様)	fm1.hamakou108.com.dkim.fmhosted.com	DKIM
TXT	_dmarc.hamakou108.com	v=DMARC1; p=quarantine;	DMARC

DKIM の CNAME は、Cloudflare のプロキシをオフにしておく必要がある。プロキシを有効にすると、受信側が CNAME をたどって DKIM の公開鍵を取得できなくなる。

DMARC は最初 p=none にして様子を見て、このドメインから送るのが Fastmail だけであることを確認してから p=quarantine に強化した。これで、このドメインを騙ったメールは受信側で迷惑メールとして扱われる。

アカウントの棚卸しの進め方

前述の構成に従って、各サービスのアカウントの登録メールを独自ドメインのアドレスに変え、認証手段を見直していった。使っていないアカウントはこの機会に削除した。

アドレスの設計

人に教える公開用のアドレスを1つだけ作り、サービスの登録にはサービスごとに別のアドレスを使うことにした。アドレスを分けておけば、漏洩したり迷惑メールが届くようになったりしたアドレスだけを無効化できるし、どのサービスから漏れたのかも分かる。

サービスごとのアドレスには、Fastmail の Masked Email ⁵ を独自ドメインで作って使っている。Fastmail のアプリや Web からランダムなアドレスをすぐに作れて、アドレスごとに無効化もできる。Masked Email のアドレスはランダムな文字列になるので、どのサービスでどのアドレスを使っているか一目で分からないのが難点だが、サービス名を含むエイリアスを毎回手動で作るのは運用コストが高すぎるので諦めた。

Masked Email は 1Password と連携して作ることもできるが、連携にはブラウザの拡張機能が必要で、スマホではアプリから登録する場面などで使えない。自分はスマホでアカウントを作る場面が多いので、PC でもスマホでも Fastmail で作って 1Password に保存する手順に統一した。

なお、+ を付けるプラスアドレスは使わないことにした。+ を受け付けない国内のサービスがあるし、+ 以降を削れば本来のアドレスが分かってしまう。

アカウント整理の優先度付け

アカウントの数がかなり多かったため、次のように優先度を付け、優先度の高いものから少しずつ進めることにした。

優先度	基準	例
P0	他のアカウントを取り戻す起点になる	Cloudflare、Fastmail、1Password、Google
P1	被害が連鎖する、または大きい	Apple、GitHub、金融機関や決済サービス、携帯キャリア、行政系、従量課金のクラウド、クレジットカードを登録した EC サイト、個人情報を多く登録したサイト
P2	それ以外	―

P1 の基準は、作業しながら具体化していった。たとえば、定額のサブスクは乗っ取られても被害の額が限られるので P2 に格下げし、開発用に作っただけのクラウドのアカウントでも、従量課金で請求額に上限がなければ P1 に格上げしている。

この優先度付けがあったおかげで、重要なアカウントの移行は終わらせることができた。P2 は「失っても被害が小さいもの」なので、急がなくてよい。実際、この記事を書いている時点でもまだ終わっていない。しばらくは Gmail と Fastmail を併用し、地道に少しずつ移行を進めている。

各アカウントの作業

各アカウントについて、主に次のことを行った。

• 登録メールを Masked Email に変更し、1Password のアイテムも更新する
• 「Google でログイン」「Apple でサインイン」を、メールとパスワードのログインに置き換えてから解除する
• 対応しているサービスではパスキーを追加し、1Password に保存する
• TOTP を 1Password に登録し、バックアップコードをバックアップ用のディスクに保存する
• パスキーや TOTP を設定したら、SMS による 2FA を無効化する
• 不要な電話番号、住所、支払いカード、連携アプリ、使っていない端末のログインセッションを削除する

パスワードでのログインを無効化できるサービスもあるが、その際はメールでの復旧手段かバックアップコードがあるかどうか確認している。パスキーしかない状態にすると、1Password を失ったときにそのサービスに入れなくなる。今のところ、パスワードを無効化すると復旧手段がなくなるようなサービスには遭遇していない。

やらなかったこと

リスクと手間を比べて、次のことは見送った。

• 過去のメールの移行とバックアップ: Gmail の過去のメールを Fastmail にインポートすることや、Fastmail のメールをバックアップすることはしていない。万が一の状況で過去のメールを見返せないのは不便だが、致命的な問題は生じないだろうと割り切った。
• レジストラと DNS の分離: Cloudflare のレジストラを使うと DNS も Cloudflare から動かせないので、Cloudflare アカウントへのログイン手段を失うとドメインの更新と DNS の変更が同時に止まる。このリスクは、認証の強化と復旧経路の確保で抑えることにした。
• 控えの分散保管: バックアップ用のディスクと全端末を同時に失う場面は、まれなケースとして許容した。

おわりに

構成を決めるまでに何度も考え直したが、最終的には「何を握って、何を手放すか」を考えるのが一番の判断基準になった。どこにも穴のない完璧なアカウント管理は到底実現できない。Cloudflare のログインと Fastmail の復旧が Google に依存したままになっている、Cloudflare のアカウントを失ったときは ICANN のルール頼みになる、バックアップ用のディスクと全端末を同時に失ったら詰むなど、今回の構成にはいくつも穴がある。どこにトレードオフのラインを引くかが肝心で、穴があること自体よりも、穴の場所を自分で把握できていることの方が大事なのだろう。

この構成は放っておくと崩れていく。人間なので、新しく作ったアカウントにうっかり Gmail で登録したり、YubiKey が知らないうちに壊れていたりする可能性がある。このため、年に1回、認証手段やバックアップが使える状態かを点検することにしている。

AI の進化に伴って、手の込んだフィッシングや情報漏洩への懸念は増す一方で、正直なところ辟易している。とはいえ、アカウントを持たずに暮らすわけにもいかないので、こうして地道に備えながら向き合っていくしかないのだろう。

Footnotes

1. Removing Google as a single point of failure: Gmail - Jake Wharton ↩

2. Generate and use recovery codes - 1Password Support ↩

3. Multiple ways in: keeping password reset secure - Fastmail ↩

4. Transfer Policy - ICANN ↩

5. Masked Email - Fastmail ↩