Appleがリレーメール用ドメインを変更 ― ただしその半分は撤回

2026年8月24日、Appleは地味なタイトルの開発者向けノート「Update: New domain for Sign in with Apple」を公開しました。その中には本当に興味深い一文が含まれていますが、それは新ドメインについての一文ではありません。

さらなる検討とコミュニティからのフィードバックを踏まえ、iCloud+ Hide My Emailのアドレスはicloud.comのまま維持されます。

これは、Appleが10週間前に発表した決定を撤回したということです。そして撤回の理由は、こうしたプライバシー機能が実際にどう機能するかについて、多くの人が誤解しがちな点をよく示しています。メールエイリアスにとって、識別可能であることこそが失敗の形なのです。

要点まとめ

Sign in with Appleのリレーアドレスが移行します。今年後半から、privaterelay.appleid.comからprivate.icloud.comへと切り替わります。
iCloud+ Hide My Emailのアドレスはicloud.comのまま維持されます。Appleは6月に移行を計画していましたが、8月にそれを撤回しました。
既存の利用には何の影響もありません。 旧ドメインの既存アドレスは引き続き機能し、転送も継続されます。
撤回の理由は、専用ドメインがブロックリストの標的になり得るからです。 サイトはドメイン全体を一括で拒否できます。しかしicloud.comを拒否すれば、実在するiCloudユーザー全員を締め出すことになってしまいます。
フィッシングによる悪用を想定しておいてください。 見慣れない新しいAppleドメインが受信箱に現れることは、攻撃者がキャンペーンを組み立てる格好の材料です。

「プライベート」と呼ばれる3つの異なるもの

まず整理しておく必要があります。6月の計画が直感的に筋が通って見えたのは、このうち2つを混同していた場合に限られるからです。そしてそれが誤りだった理由は、両者が同じ製品ではないという点にあります。

アプリやウェブサイトで「Sign in with Apple」をタップし、アドレスを非表示にする選択をすると、Appleはその特定の開発者専用のリレーアドレスを生成し、届いたメールをあなたに転送します。これはどのApple Accountでも無料で利用できます。

現在のドメイン: @privaterelay.appleid.com
新しいドメイン: 今年後半から新規発行されるアドレスは@private.icloud.com
Macでの管理場所: システム設定 → [あなたの名前] → Sign in with Apple

2. iCloud+ Hide My Email

有料のiCloud+機能です。ニュースレター、フォーム、ショップなど、あらゆる用途に自分でエイリアスを生成でき、ラベルとメモを付けて何のためのものかを後から思い出せます。サインインのフローには一切紐づいていません。

ドメイン: @icloud.com ― 変更なし
Macでの管理場所: システム設定 → [あなたの名前] → iCloud → Hide My Email
SafariやMailでもアドレス欄をクリックしてHide My Emailを選ぶことで、その場で利用できます

3. iCloud Private Relay

これはメールではまったくありません。Safariでの閲覧や一部の非暗号化トラフィックのための二段階リレーで、どの一者からも「あなたが誰か」と「何を見ているか」の両方が見えないように設計されています。共通しているのは「リレー」という言葉だけです。この機能の実際の障害モードについては、iCloud Private Relayが実IPアドレスを漏洩する仕組みで取り上げました。

この混同は読者のせいではありません。最初の2つはどちらも「Hide My Email」というラベルのボタンを表示するのです。 一方はprivaterelay.appleid.comのアドレスを、もう一方はicloud.comのアドレスを発行しますが、Appleはこれまでその違いを大きく打ち出したことがありません。このラベルの共有こそが、6月にドメインを統一する案が整然として見えた理由でほぼ間違いないでしょう。

Appleは両方の発表で何と言ったか

変更内容は正確なので、両方を並べて読む価値があります。

2026年6月15日:

今年の夏後半、AppleはSign in with AppleとiCloud+ Hide My Emailで使われるメールドメインを、単一の共有ドメインであるprivate.icloud.comに統合します。

両機能で新規に生成されるアドレスは、この新ドメインで発行されます。例えば:

これまでprivaterelay.appleid.comで発行されていたSign in with Appleのアドレスは、private.icloud.comで発行されるようになります。

これまでicloud.comで発行されていたiCloud+ Hide My Emailのアドレスは、private.icloud.comで発行されるようになります。

旧ドメインの既存アドレスは、中断なく引き続き機能し、ユーザーへのメール転送も継続されます。

2026年8月24日:

今年後半から、これまでprivaterelay.appleid.comで発行されていた新規のSign in with Appleアドレスは、private.icloud.comで発行されるようになります。privaterelay.appleid.comの既存アドレスは、中断なく引き続き機能し、メール転送も継続されます。

さらなる検討とコミュニティからのフィードバックを踏まえ、iCloud+ Hide My Emailのアドレスはicloud.comのまま維持されます。

両者の間には2つの変更があります。Hide My Emailは移行対象から外れました。そしてスケジュールも「今年の夏後半」から「今年後半から」へと変わっています ― 当初の予定はすでに過ぎており、これを踏まえて予定を立てている場合は注意が必要です。

Hide My Emailをicloud.comに留めておくことが正しい判断である理由

その仕組みを見ていきましょう。これはあらゆるエイリアスサービスに一般化できる話なので、理解しておく価値があります。

メールエイリアスがあなたを守ってくれるのは、受け取った側がそれをエイリアスだと安価に見分けられない場合に限られます。あるサービスがエイリアスアドレスを識別できるようになった瞬間、そのサービスはそれを拒否できるようになります。そしてサービス側には拒否する強い動機があります。エイリアスは再識別できず、データブローカーの記録と照合できず、アドレスを破棄されれば二度と連絡が取れない顧客だからです。

撤回が発表された際、John Gruberはユーザー側の視点をこう率直に表現しています。

私たちはしばしば、こうした隠されたメールアドレスを、それらをブロックして「本物の」アドレスを使わせようとするサイトでこそ使いたいのだ

専用のprivate.icloud.comドメインは、たった1つの文字列です。どんなサインアップフォームも、検証コード1行でこれを拒否できてしまいます。その1行を追加したサイトでは、Appleがこれまで発行してきたすべてのエイリアスが一斉に無価値になってしまうのです。

icloud.comはそのようには扱えません。これは何億もの人々が日常のパーソナルメールに使っているドメインです。エイリアスを止めるためにicloud.comをブロックするサービスは、実際の顧客の大部分をも締め出してしまいます。Hide My Emailの保護は暗号的なものではなく、エイリアスが本物のアドレスの中に紛れ込んでいるという点にあります。 別ドメインへ移すことは、この隠れ場所を奪うことに等しかったのです。

これがAppleの至った結論のようであり、正しい結論でもあります。また、一度発表した計画が技術的な理由ではなくプライバシー上の論点によって撤回された、珍しい事例でもあります。

そしてSign in with Appleの移行が同じ問題ではない理由

ここまでの議論から、Appleが Sign in with Appleのユーザーを無防備なまま放置したと結論づけるのは簡単です。しかしそれは正しくありません。その理由を正確に見ておく価値があります。

Sign in with Appleのリレーアドレスは、もともと専用の、明らかに識別可能なドメイン上にありました。privaterelay.appleid.comはそれ自体が正体を語っています。これを拒否したいサービスは2019年からずっとそうできたのです。private.icloud.comへの移行は、この軸で見れば横移動にすぎません ― 新たに識別可能になったのではなく、別の識別可能なドメインに変わっただけです。

この露出があまり問題にならない構造的な理由もあります。Sign in with Appleのリレーアドレスは、フォームに自分で入力するものではありません。サイト側が提供を選んだ認証フローの一部として発行されるものです。リレーアドレスを望まないサイトは、そもそもSign in with Appleを実装しません。Hide My Emailを脆弱にしているようなブロックのシナリオは、ここでは実質的に起こり得ないのです。

率直にまとめると、Appleは保護が必要な機能を保護し、その必要のない機能だけを移行した、ということです。6月の計画は一方を損なうものでしたが、Appleはそれに気づいたのです。

Appleのプライベートメールシステムの比較

実際に何が変わるのか

ほとんどの人にとって、変わることはごくわずかです ― とはいえ、驚かされる前に詳細を知っておく価値はあります。

既存のアドレスは変わりません。 すでに持っているprivaterelay.appleid.comのアドレスは、すべて引き続き機能し、転送も続きます。Appleは両方の発表で明確にそう述べています。何かを更新したり、どこかに再登録したり、アカウントを移行したりする必要はありません。

新規のサインインでは、見慣れないドメインが発行されます。 変更後、新しいサービスでSign in with Appleを使うと、private.icloud.comのアドレスが発行されます。どのエイリアスをどのサービスに使ったか記録している場合、今後はそのリストに2つのドメインが混在することになります。

一部のサイトは新ドメインを拒否するでしょう。 サインアップ時の検証、許可リスト、不正利用対策のルールにprivaterelay.appleid.comをハードコードしているサービスは、更新されるまでprivate.icloud.comを認識できません。Appleのノートは開発者に対して両方を受け入れるよう明確に求めていますが、全員がそれを読むわけではありません。

企業のメールフィルタリングでメッセージが保留される可能性があります。 仕事関連の何かにSign in with Appleを使っていて、組織が送信元や宛先ドメインでフィルタリングしている場合、まったく新しいドメインは隔離フォルダに振り分けられることがあります。

フィッシングの隙

ここが実際にセキュリティ上の影響がある部分であり、他の誰も書いていない部分でもあります。

Appleはこれを開発者向けに公開しました。一般ユーザー向けの告知はなく、設定アプリでの通知もなく、ユーザーへのメールもありません。ほとんどの人が初めてprivate.icloud.comに出会うのは、それが何の前触れもなく現れたとき ― 差出人欄で、アカウント設定画面で、あるいはパスワードマネージャーのエントリで、ということになるでしょう。

本物のApple所有ドメインが、何の予告もなく、しかも公表済みの移行期間中に現れる ― これはフィッシングキャンペーンにとってほぼ理想的な条件です。文面はほとんど自動的に書けてしまいます。*「あなたのAppleリレーアドレスが移行されます。サインインしたサービスへのアクセスを失わないよう、アカウントを確認してください」*といった具合です。

この変更に関係なく成り立つ、いくつかの鉄則があります。

Appleはこの移行に際して、あなたに何かを求めることはありません。 リレーアドレスの確認・検証・移行・再認証を求めるメッセージは、すべて不正です。ユーザー側の作業は存在しません。存在しないからこそ、そう言い切れます。
Apple Accountに関するメール内のリンクを操作しないでください。 自分でシステム設定を開いて確認しましょう。変更が本物であれば、そこに反映されているはずです。
リンクの実際の遷移先を確認してください。 private.icloud.comはApple本物のドメインです。private-icloud.com、privateicloud.com、private.icloud.com.example.net、icloud-private.comは違います。攻撃者はまさにこうした瞬間のために、そっくりなドメインを登録します。
自分から始めていないパスワード入力プロンプトは、警戒すべき合図です。 正規のmacOSのパスワードプロンプトは、直前に自分が取った操作に続いて表示されます。これがどれほど巧妙に偽装され得るかは、偽のMacクラッシュレポート・パスワードプロンプトで取り上げました。

より広範な対策を行いたい場合は、Macのセキュリティとプライバシーガイドで周辺の設定を取り上げています。

自分が実際に何を持っているか確認する

ほとんどの人はまだ確認したことがないはずなので、今が見直すよい機会です。

どのアプリがSign in with Appleを使っているか:

Macでシステム設定を開き、サイドバー上部の自分の名前をクリックして、Sign in with Appleを選びます。これまでSign in with Appleを使ったすべてのアプリとサイトが一覧表示され、それぞれ個別に利用を停止できます。

何かを取り消す前に、そのリストをよく確認してください。あるサービスに対してSign in with Appleをオフにすると、リレーアドレスが機能しなくなり、パスワードリセットを含めてそのサービスからあなたに連絡できなくなります。他のログイン方法をそのサービスに登録していない場合、自分自身をロックアウトしてしまう可能性があります。先に代替のサインイン方法を設定しておきましょう。

どのHide My Emailエイリアスが存在するか:

システム設定 → [あなたの名前] → iCloud → Hide My Email。各項目には、ラベル、メモ、そして転送先アドレスが表示されます。不要になったエイリアスは無効化でき、その配信を止めつつ、何のためのものだったかという記録は削除せずに残せます。

メールがどこへ転送されるか:

同じ画面で確認できます。Apple Accountに複数の個人用アドレスを登録している場合、そのうちの1つがすべてのエイリアスの転送先になっています。今も読んでいるアドレスであることを確認してください。使わなくなった転送先アドレスは、アカウント復旧のメッセージが必要になったときに初めて表面化する、静かな失敗の原因になります。

ついでにやっておく価値のある2つのこと

エイリアスにきちんとラベルを付けましょう。 メモ欄が用意されているのは、2年後でもそのエイリアスが何のためのものか分かるようにするためです。ラベルのないエイリアスは、無効化するのが怖くなってしまうアドレスになります。

復旧経路がリレーに依存していないか確認しましょう。 重要なアカウントの唯一の連絡先アドレスがSign in with Appleのリレーで、後にそのアプリのアクセスを取り消してしまうと、そのアカウントの復旧手段も一緒に失われます。オフにする可能性のあるリレーを経由しない経路を、少なくとも1つは残しておきましょう。

開発者と管理者向けに

メールアドレスを扱う何かを運用しているなら、ここには具体的にやるべき作業があります。Appleの要請は次の通りです。

Sign in with Appleを利用するアプリやウェブサイトの開発者は、自社のアカウントシステム、メールの検証ロジック、許可リストが、既存のprivaterelay.appleid.comドメインに加えて、新しいprivate.icloud.comドメインのアドレスも受け入れられるようにしておくべきです。

具体的には:

両方のドメインを受け入れる。 置き換えではなく、両方です。privaterelay.appleid.comの既存アドレスは無期限に有効なままです。
ハードコードされた文字列を見つける。 コードベースと設定をprivaterelay.appleid.comでgrepしましょう。検証用の正規表現、不正対策ルール、分析用のセグメンテーション、配信可否を判定する許可リスト、サポートツールなどに出てくるはずです。
メール配信サービスのルールを確認する。 ドメインベースのルーティング、サプレッションリスト、レピュテーションルールはリポジトリの外側にあり、見落とされやすい場所です。
private.icloud.comを新たにブロックの対象にしない。 自社のユーザーに敵対的であるだけでなく、サインアップ時に拒否したアドレスは獲得できなかった顧客そのものです。そしてSign in with Appleは、あなたのアプリが自ら提供を選んだ認証方式です。
フロー全体をテストする。 サインアップ、確認メール、パスワードリセット、アカウント復旧まで一通り確認しましょう。登録時にはアドレスを受け入れるのに、パスワードリセット時には拒否してしまう検証ルールは、実際に厄介なバグであり、この種の失敗によくあるパターンです。

管理者向け: 受信メールをドメインでフィルタリングしている場合は、privaterelay.appleid.comがすでに登録されているリストにprivate.icloud.comを追加してください。ユーザーからメールが届かないという報告が来る前に対応しましょう。

リレーが実際に隠しているもの

正確に理解しておく価値があります。人々はこうした機能に対し、その機能が実際にカバーする範囲を超えて信頼を寄せがちだからです。

開発者が手に入れられないもの: あなたの本物のメールアドレスです。開発者が手にするのはリレーアドレスであり、そこにメールを送ることはできますが、Appleがそれを転送します。アクセスを取り消せば、リレーは停止し、開発者が持っていたあなた宛のアドレスは使えなくなります。

開発者が実際に手に入れるもの:

そのアプリ内であなたを表す安定した識別子。Sign in with Appleは開発者ごとのユーザー識別子を発行し、これはセッションやデバイスをまたいで維持されるため、開発者はあなたをリピーターとして認識できます。この識別子は開発者ごとにスコープされており、同じApple Accountでも開発者が違えば別の識別子が生成されるため、2つのアプリがこれを手がかりに記録を突き合わせることはできません。
あなたが共有することを選んだ場合の氏名。サインインの時点で編集することもできます。
その後あなた自身が伝えるすべての情報。リレーが隠すのはあなたのアドレスであって、あなたの行動ではありません。プロフィール欄に本名を入力すれば、それは渡してしまったことになります。
開発者の分析ツールが収集するあらゆる情報。デバイスフィンガープリンティング、IPアドレス、広告識別子は、この機能の対象範囲に一切含まれません。

Appleが手に入れるもの: メールは転送のためにAppleのサーバーを経由します。Appleは、配信に必要な範囲を超えて内容を読んだり保持したりしないとしていますが、リレーはその構造上Appleを迂回する経路ではなく、Appleを通る経路です。

整理して考えるならこうです。リレーアドレスとは、匿名性ではなく取り消し可能なチャネルである。 これは「この会社が私のアドレスをデータブローカーに売り、メールを止められなくなった」という問題を解決します。しかし「この会社は私が誰か知っている」という問題は解決しません。

これは解決する価値が本当にある問題であり、その「取り消し可能性」こそが過小評価されがちな半分です。ほかのどこであなたのアドレスを変えることもなく、ある一社があなたに連絡する力だけを断ち切れる ― これは通常のメールボックスがこれまで一度も提供できなかったことです。

サードパーティのエイリアスサービスとの比較

Appleだけが選択肢ではなく、比較することで「ブロックされやすさ」という論点がよく見えてきます。

専用のエイリアスサービス ― SimpleLoginやAnonAddyなど ― は無制限にエイリアスを発行できますが、通常は他の全ユーザーと共有のドメイン上に発行されます。この共有ドメインこそ、6月の計画がHide My Emailに対して生み出そうとしていたのと同種のブロックリストの標的であり、これらのサービスが多くのサインアップフォームで広く拒否されている理由でもあります。優れたサービスでは自分のドメインを持ち込むことができ、これによりブロックされにくさを取り戻せますが、その代償としてドメインの登録と維持費用がかかり、誰かに紐づけられた場合はそのドメインが一意にあなたのものだと分かってしまいます。

Fastmailなど同種のプロバイダーも、自分のドメインか、あるいはプロバイダー自身のドメイン上でマスクされたアドレスを提供しており、同じトレードオフを抱えています。

AppleのiCloud+ Hide My Emailが異例なのは、まさに今回維持されたその点にあります。エイリアスはicloud.com上に存在し、何億人もの一般ユーザーと同じ場所に置かれています。これは、本物のアドレスと見分けがつかないアドレスを発行する唯一の主要なエイリアスサービスです。これはどの競合も再現できない構造的な優位性です。なぜなら、その規模でコンシューマー向けメールドメインを運用している競合が存在しないからです。

とはいえ制約も実在します。Appleのエイリアスは1つのアドレスにしか転送されず、Appleデバイス上のApple Mail以外からエイリアスとして送信することはできず、自分のドメインを使うこともできません。細かなルーティングや任意のクライアントからの返信を求めるなら、専用サービスの方が高機能です。一方、どこでも問題なく受け入れられるエイリアスが欲しいなら、Appleのものが今のところ最も強力な選択肢であり、そして今回それがそのまま維持されたのです。

簡単な歴史と、旧ドメインが以前から不自然だった理由

Sign in with Appleは2019年に登場しました。AppleのApp Storeレビューガイドラインは、サードパーティのサインインオプションを提供するアプリに対してこの機能も併せて提供するよう求めていたため、徐々にではなくほぼ一斉にあらゆる場所で見かけるようになりました。プライベートメールリレーはその最も特徴的な機能でした。他のサインインプロバイダーは開発者にあなたのアドレスをそのまま渡しますが、Appleはそうしない選択肢を提供したのです。

その代わりに配布されたのが@privaterelay.appleid.comというアドレスでした。長ったらしく、ほとんどのユーザーが他では目にしたことのないドメイン上にあり、しかもその性質を自ら物語ってしまっています。Apple側から見れば理にかなっていました ― appleid.comはアカウント基盤が置かれていた場所だからです ― しかしユーザー側から見ると、これは以前からどこかフィッシングキットが作り出しそうなものに見えていました。

private.icloud.comへの統合は、この点を解決します。icloud.comは一般の人々が見慣れたドメインであり、そのサブドメインはprivaterelay.appleid.comがついに実現できなかった形で、正当なものとして読み取られます。サインインリレーにとって、これは分かりやすい改善であり、おそらくこの一連の取り組み全体の背景にある理屈でもあるでしょう。

ところが6月の計画は、この理屈を過剰に適用してしまいました。統合は、もともと目立っていたアドレスにとっては良いことです。しかし、目立たないことにこそ価値があったもう一方にとっては、明確に害となるものでした。この修正に10週間と世論からの反発が必要だったという事実は、名前とボタンを共有する一方の製品を改善する変更が、もう一方をひっそりと劣化させ得るという、小さいながらも示唆に富む事例です。

よくある問題のトラブルシューティング

新しいAppleリレーアドレスがウェブサイトで無効と判定される

問題: サイト側のメール検証がまだprivate.icloud.comを認識していません。

解決策: サイトに報告しましょう ― これはサイト側のバグであり、Appleはすでに対応方法を公開しています。差し当たっては、icloud.com上のiCloud+ Hide My Emailエイリアスなら受け入れられます。このドメインは変更されておらず、ごく普通のiCloudアドレスと見分けがつかないからです。これこそ、Appleが今回維持した性質そのものです。

Appleでサインインしたサービスからのメールが届かなくなった

問題: いくつかの可能性があります。Apple Accountの転送先アドレスがもう読んでいないものになっている、そのアプリに対してSign in with Appleを取り消してしまった、あるいはメールプロバイダーが見慣れないドメインをフィルタリングしている、などです。

解決策: システム設定 → [あなたの名前] → Sign in with Appleでそのアプリが有効なままか確認し、次にHide My Emailで転送先アドレスを確認してください。それでも見つからなければ、新ドメインからのメールが迷惑メールや隔離フォルダに入っていないか確認しましょう。

問題: アクセスを取り消すとリレーアドレスが無効になります。そのアドレスがアカウントの唯一の連絡手段だった場合、パスワードリセットの送り先がなくなってしまいます。

解決策: そのサービスのサポートに直接連絡して事情を説明しましょう ― これはよくある状況で、たいていのサービスには手動での対応手段があります。これを避けるには、何かを取り消す前に代替のサインイン方法を登録しておいてください。

Appleリレーアドレスの変更に関するメールを受け取った

問題: Appleはこの件についてユーザーにメールを送っていません。この移行はあなたに何も求めません。

解決策: フィッシングとして扱ってください。リンクはクリックしないこと。気になる点は、自分でシステム設定を開いて確認しましょう。

設定内にHide My Emailが見当たらない

問題: これはiCloud+の機能であり、有料のiCloud+またはApple Oneのサブスクリプションが必要です。加入していない場合、利用できるのは無料のSign in with Appleリレーのみです。

解決策: システム設定 → [あなたの名前] → iCloudでサブスクリプションの状態を確認してください。加入していなくても、Sign in with Appleのアドレス非表示オプションは無料で引き続き使えます。ただし、あらゆる場面で使えるわけではなく、サインインのフローに限定されます。

よくある質問

何かする必要はありますか？

いいえ。既存のアドレスは引き続き機能し、この変更は新規に発行されるSign in with Appleのアドレスにのみ適用されます。ユーザー側で行うべき移行手順は存在しません。だからこそ、それと異なる主張をするメッセージはすべて不正だと言えるのです。

古いprivaterelay.appleid.comのアドレスは使えなくなりますか？

いいえ。Appleは両方の発表で、既存アドレスは中断なく引き続き機能し、転送も続くと述べています。Appleはこれらの終了日をまだ発表していません。

なぜAppleはHide My Emailについて方針を変えたのですか？

Apple自身の言葉では「さらなる検討とコミュニティからのフィードバックを踏まえ」とされています。そのフィードバックの実質的な内容は、専用ドメインではエイリアスアドレスが簡単にブロックされてしまい、機能そのものが破綻するというものでした。icloud.comのまま維持することで、通常のiCloudアドレスと見分けがつかない状態が保たれます。

Hide My EmailはSign in with Appleの非表示アドレスと同じものですか？

いいえ、ただしどちらも同じ名前のボタンを表示します。Hide My Emailは有料のiCloud+機能で、任意の用途向けにicloud.comのエイリアスを作成できます。一方Sign in with Appleのリレーは無料で、特定のアプリに紐づいており、private.icloud.comへ移行するのはこちらです。

変更は正確にはいつ実施されますか？

Appleは「今年後半から」としています。6月の発表では「今年の夏後半」とされていたため、スケジュールはすでに一度変更されています。具体的な日付はまだ公開されていません。

これはiCloud Private Relayに影響しますか？

いいえ。iCloud Private Relayは、Safariでの閲覧のためのネットワークプライバシー機能であり、言葉が似ていてもメールアドレスとは一切関係がありません。

重要なアカウントはHide My Emailに切り替えるべきですか？

重要なアカウントについては、より有益な問いは「エイリアスをオフにしても復旧経路が生き残るか」です。どちらの仕組みもしっかりしています。両者に共通するリスクは同じで、エイリアスがアカウントの唯一の連絡手段になっていて、後にそれを無効化してしまうと、復旧が困難になるという点です。失うわけにいかないものについては、必ず第2の経路を確保しておきましょう。

まとめ

見出しになる変更自体は小さく、あなたには何も求められません。新しいSign in with Appleのアドレスはprivate.icloud.comで発行され、古いアドレスは引き続き機能し、実際にやるべき作業があるのはどこかにドメイン文字列をハードコードしていた開発者だけです。

覚えておく価値があるのは、Appleが取り消した部分です。誰もが識別できるプライバシー機能は、もはやプライバシー機能ではありません。そしてAppleの6月の計画は、一見理にかなった統合に見えましたが、保護のすべてが「普通のメールに紛れ込むこと」にあるエイリアスシステムに対して、誰でもフィルタリングできるラベルを与えてしまうところでした。それは公に指摘され、10週間で撤回されました。これは良い結末であると同時に、「ボタンを共有する2つのものを統合する」というデザイン上の直感は、そのうちの一方が「目立たないこと」に依存している場合には、もう一度見直す価値があるという教訓でもあります。

そしてもう一つ ― Appleはこの件についてあなたにメールを送ることはありません。もし送ってくる者がいれば、それはApple本人ではありません。