Google Workspaceが壊れた正規表現ブロックリストで正当なドメインをブロック

Google Workspaceへのサインアップは退屈であるべきだ。ある開発者にとって、それは1週間にわたるサポートの騒動となった。Googleのサインアップフォームが、彼らの会社のドメインを不可解なエラーで拒否したのだ： 「メールプロバイダの代わりに有効なドメイン名を入力してください。」

問題のドメインは、不正使用の履歴がないプレミアムな.oneドメインだった。開発者はドメイン履歴を確認し、Googleのドキュメントを調べ（何もなし）、コミュニティスレッドを見つけた — ウクライナ経済省のものも含まれ、そのme.gov.uaドメインも同じ壁にぶつかっていた。Googleのサポートループはいつものものだった：「別のブラウザを試す」「別のデバイスを試す」、ビデオを録画する。エスカレーションの後、プロダクトエンジニアは、真面目に、別のドメインを使うことを提案した。

そこで開発者は、自尊心のあるエンジニアなら誰でもやることをやった： DevToolsを開き、サインアップページのソースを読んだ。エラーは、入力されたドメインをメールプロバイダのハードコードされた正規表現リストと照合するクライアントサイドの検証関数から来ている。リストにはgmail\..*やhotmail\..*のような明らかなエントリが含まれているが、本当に頭を悩ませるものもある：

• web\..* — web.で始まるドメインをすべてブロックする。これが著者のドメインを引っかけた。
• me\..* — me.で始まるドメインをすべてブロックする。これがme.gov.uaを失敗させた理由だ。
• alice\..* — おそらくAlice、そのメールサービスのため？ 誰も知らない。
• mail\..{1,3}(\..{2})?$ — mail.の後に1〜3文字とオプションのTLDが続くものにマッチする正規表現で、mail.ioを引っかけるが、mail.abc（それが有効なTLDであれば）も引っかける。

完全なリストは何百ものエントリの混乱で、実際のプロバイダ、死んだサービス、teleworm.comやii-ii-ii-ii.comのようなランダムなドメインが混ざっている。検証関数は単純だ： ドメインがこれらのパターンのいずれかにマッチする場合（大文字小文字を区別せず、先頭にアンカー）、拒否される。

キッカー： これはフロントエンドのみの検証だ。開発者はブラウザで関数を無効にし、問題なくサインアップを完了した。サーバーサイドのチェックは存在しない。つまり、ブロックリスト全体はUXのスピードバンプであり、セキュリティ対策ではない — そしてそれは正当なビジネスを積極的に拒否している。

Googleはこれを何ヶ月も知っている。ウクライナ経済省のコミュニティスレッドは2025年初期のもので、著者のケースも複数のサポート階層を経た。2026年8月現在、問題はまだ存在している。

回避策はDevToolsに慣れている人には簡単だが、それが問題ではない。Googleのような会社がweb.*ドメインをブロックするハードコードされた正規表現リストを出荷し — そして顧客に別のドメインを選ぶように言う — のは恥ずかしい。修正は正規表現の1行変更か、あるいはもっと良いのは、フロントエンドのデプロイなしで修正できるサーバーサイドに検証を移すことだ。

今のところ、このエラーに遭遇した場合、2つの選択肢がある： 1週間Googleサポートと戦うか、DevToolsを開いて_.Au関数を見つけ、return falseに設定するか。後者の方が速い。