- 投稿日：2026/04/19
はじめに
ある朝、ふとメールを確認しようとしたら、受信トレイに1ヶ月前までのメールしか残っていなかった。
「あれ、おかしいな」
最初は単なる表示バグだと思った。
メールはビジネス用のGmailなので、Gmailアプリを再起動して、また開いて——それでも変わらない。
ゴミ箱やアーカイブを見ても何も残っていない。
Claude Coworkで整理したから？
いや、まだ整理してなかったはず。
PerprexityAIに聞いてみると
>Google Workspace ステータスを確認する。Gmail 側の障害があると送受信できません 。
試しに、
普段使いのGmailからビジネスメールを送る→受信できない
ビジネスメールから普段使いのGmailへ送る→送信できない
そうやっている間にも普段使いのGmailにはメールが来るので、ビジネスメールに問題があるのが分かった。
PerprexityAIの通り、Google Workspace（ビジネス用Gmail）のアカウントを見ると
「Gmailを有効にします」
という表示になっていた。
つまり、無効になっていた。
ここから、原因を探る小さな冒険が始まった。
Googleの画面に表示された指示
Google Workspace の管理画面もある「Gmailを有効にします」は、リンクにもなっていて、開くと
> 「Gmailアクティベーションコードを追加」の画面が表示された。
"MXレコード"——聞き慣れない言葉だ。簡単に言うと、「このドメイン宛てのメールをどこに届けるか」を指定する設定のことだ。
たとえば `info@ xxxx.com` というメールアドレスがあった場合、MXレコードがないと「このメールをどこに転送すればいいか分からない」状態になる。つまりメールが届かない。
Googleの案内に従い、まずドメインを管理している "Squarespace" のDNS設定画面を開いた。
Squarespaceで設定したのに……反映されない
Squarespaceの画面には、たしかにDNS設定のセクションがあった。そこに指定されたMXレコードを入力して、保存した。
ところが、しばらく待ってもGoogleの画面は「確認済み」にならない。
それどころかエラーになってしまった。
おかしい。
ここで外部ツール "mxtoolbox.com" を使って、実際にどのDNSサーバーがドメインを管理しているかを調べてみた。
結果に表示されたのは：
awsdns——これはAmazon Web Services（AWS）のDNSサービスだ。
なぜAWSが出てくるのか？
本当のDNS管理場所はSquarespaceではなかった
本当の管理場所は別にある。
AWSのコンソールにログインして、DNS管理サービスの "Route 53 を開いてみた。しかしホストゾーンの一覧は"空"だった。
謎が深まる。
犯人はAmazon Lightsailだった
「ホストゾーンがないのに、なぜAWSのDNSが使われているのか？」
ここでひとつの記憶が蘇った。
1ヶ月前、Amazon LightsailでWebサイトを立ち上げていた。
LightsailはAWSが提供する、比較的手軽にWebサーバーを立てられるサービスだ。そして「Claude Cowork」を使って、自動的にWebサイトをセットアップしていた。
その時、Lightsailが「ドメインをこのサーバーに自動接続します」という設定を行った。この処理の中で、"ネームサーバーがSquarespaceからLightsailのDNSに書き換えられていた"のだ。
AWSコンソールで "Lightsail"のページを開き、「ドメインとDNS」タブを確認すると——
あった。
`xxxx.com` のDNSゾーンが、Lightsailの中にひっそりと存在していた。
構造を図解すると
今起きていたことを整理するとこうなる。
■正しいルート（設定後）
送信者のメール
↓
Lightsail DNS（MXレコード確認）
↓
smtp.google.com
↓
Google Workspace（受信✅）
■壊れていたルート（1ヶ月間）
送信者のメール
↓
Lightsail DNS（MXレコードを確認）
↓
MXレコードが存在しない ❌
↓
エラー → 送信者に「配信失敗」が返る
■Squarespaceは関係なかった
送信者のメール
↓
Squarespaceは完全にスルーされる
（ネームサーバーがLightsailを向いているため）
Squarespaceで設定を変えても、実際のDNSはLightsailが管理しているため、何も反映されていなかった。これが約1ヶ月間、メールが届いていなかった根本原因だった。
解決：LightsailにMXレコードを追加
原因が分かれば、解決策はシンプルだ。
Lightsailの「DNSレコード」画面で「＋ レコードの追加」をタップし、Google Workspaceの指定のレコードを追加する。
これを保存。
DNSの変更が世界中のサーバーに伝わるまで数十分〜数時間かかる（これを「DNS伝播」と呼ぶ）。しばらく待てば、Google Workspaceの画面が「確認済み」になるはずだ。
…実際には変更した瞬間に反映され、Gmailが有効になった。
失われた1ヶ月のメールはどうなった？
残念ながら、MXレコードが設定されていない間に送られてきたメールはほぼ戻ってこない。
復旧したら次から次に受信メールが届くと期待したが、そんなことは起こらなかった。
MXレコードがない状態でメールを送ると、送信側のサーバーは即座に「配信不可」と判断し、送信者にエラーメールを返す。メールはサーバー上に保留されるわけではなく、そもそも存在しなかったことになってしまう。
一部のメールサーバーは数日間リトライ（再送）してくれることもあるので、設定直後に届くメールもあるかもしれない。しかし基本的には、重要な連絡は相手に再送をお願いするしかない。
この経験から学んだこと
1. AIによる自動セットアップは「裏側で何をしているか」を確認する
今回の原因は、Claude Coworkを使ってWebサイトを自動構築した際に、"ネームサーバーが書き換えられたこと"だ。便利な自動化ツールは多いが、ドメインやDNSのような「インフラ的な設定」が変更される場合、必ず何が変わったかを確認する習慣をつけたい。
2. DNSの管理場所は定期的に確認する
「どこでDNSを管理しているか」は、意外と把握できていないことが多い。mxtoolbox.com などのツールで定期的に確認しておくと、今回のような問題を早期発見できる。
3. MXレコードとWebサイトは独立している
「メールの設定を変えたらWebサイトに影響するのでは？」と心配する人もいるかもしれないが、"MXレコード（メール）とAレコード（Webサイト）は完全に独立している"。同じドメインでも、メールとWebは別々のサーバーに向けることができる。
4. DNS変更後は反映に時間がかかる
DNSの設定変更は、即座に反映されるわけではない。早くて数十分、長ければ72時間かかることもある。「設定したのに動かない」と焦る前に、まず時間を置いて確認してみよう。
おわりに
「メールが見れない」という小さな異変から始まり、Squarespace → AWS Route 53 → Lightsail と調査を進めた結果、1ヶ月前のWebサイト自動構築が原因だったと判明した。
技術的な知識がなくても、AIやクラウドサービスを使えば簡単にWebサイトやメールが作れる時代になった。それはとても素晴らしいことだ。でも同時に、"自動化によって「気づかないうちに設定が変わる」リスク"も増えている。
便利さと引き換えに、少しだけ「裏側で何が起きているか」に興味を持つ——そのバランスが、これからのデジタル時代を生き抜くコツかもしれない。
*この記事が同じ問題で困っている人の助けになれば幸いです。*
