1. はじめに
前回の記事では、Ubuntu環境にPostfixをインストールして「メールを送信する環境」を構築しました。しかし、メールサーバーは送るだけでは片手落ち。「外からのメールを受け取る環境」があって初めて完成します。
そこで今回は、オープンソースのPOP3/IMAPサーバーである「Dovecot（ダブコット）」を使い、Ubuntu上にメールの受信環境を構築する手順を解説します。
メールの保存形式には、管理がしやすく現代のスタンダードである「Maildir形式」を採用し、実際の受信テストを行うところまでを網羅しました。
実は、Dovecotの構築自体は非常にシンプルですが、手順通りに進めたはずなのにメールが一切届かず、謎のエラーで弾かれ続ける「恐怖の落とし穴」が存在します。
この記事では、構築時に見落としがちなその原因と解決策、そして設定が正しいかを一発で確認できる神コマンドまで、実体験をベースに徹底解説します！
2. Dovecotのインストールと基本設定
まずはUbuntuにDovecotをインストールし、メールを受信するための最低限の基本設定を行います。今回は、現代のメール利用で一般的な「IMAP」および「POP3」の両方に対応したパッケージをインストールします。
Dovecotのインストール
SSHでUbuntuサーバーにログインし、以下のコマンドを実行してパッケージをインストールします。
sudo apt update
sudo apt install dovecot-imapd dovecot-pop3d -y基本設定ファイルの編集
インストールが完了したら、Dovecotの設定ファイルを編集して「メールの保存先」を指定します。今回は、メールをユーザーごとのディレクトリに個別のファイルとして保存する「Maildir形式」を採用します。
設定ファイルである /etc/dovecot/conf.d/10-mail.conf をテキストエディタで開きます。
sudo nano /etc/dovecot/conf.d/10-mail.confファイルを開いたら、mail_location という項目を探します（デフォルトではコメントアウトされているか、mbox になっている場合があります）。
以下のように maildir:~/Maildir を指定する形に書き換えて保存してください。
# 30行目付近：Maildir形式でホームディレクトリに保存する設定
# Around line 30: Configure Maildir format to store mail in the user's home directory
mail_location = maildir:~/Maildirこれで、Dovecotが「届いたメールは各ユーザーのホームディレクトリにある Maildir フォルダに片付けるんだな」と認識するようになります。
3. 受信用のユーザー準備とMaildirの作成
送信サーバー（Postfix）の準備ができたら、次は届いたメールをサーバー内に安全に保存し、のちに受信サーバー（Dovecot）がそれを読み出せるようにするための「受け皿」を作ります。
Linuxでメールサーバーを運用する場合、メールを保存する形式には「Mbox形式（すべてのメールを1つの巨大なファイルに追記していく古い方式）」と、「Maildir形式（メール1通ごとに独立したファイルとして保存する新しい方式）」の2種類があります。今回は、メールが壊れにくく同時アクセスにも強いMaildir（メールディル）形式を採用します。
この受け皿をシステム上に構築し、Postfixと連携させるための段取りを踏んでいきましょう。
3-1. mailユーザーのホームディレクトリ設定
Ubuntuには、メール処理を安全に行うための専用アカウントとして、mail というシステムユーザーが最初から標準で用意されています。個人のログインユーザーでメールを管理するのではなく、このメール専用ユーザーにすべての受信メールの管理を一任するのがセキュリティ上のベストプラクティスです。
まずは、この mail ユーザーがメールを扱うための拠点（ホームディレクトリ）を、分かりやすく /home/mail に指定する設定を行います。
VPSのターミナルで以下のコマンドを実行します。
sudo usermod -d /home/mail mailusermod -d：指定したユーザーのホームディレクトリ（活動拠点）を強制的に変更するコマンドです。これにより、mail ユーザーの家が /home/mail にカチッと固定されます。
3-2. 受信フォルダ（Maildir）の作成と所有権の変更
活動拠点が決まったら、その中にメールを格納するためのMaildirフォルダを手動で作成します。
Maildir形式のルールとして、フォルダの中には必ず new（未読メール）、cur（既読メール）、tmp（一時処理用） という3つのサブディレクトリが存在していなければならない、という厳格な決まりがあります。これが1つでも欠けていると、PostfixもDovecotも正常にメールを扱えなくなってしまいます。
1. 3つのフォルダをまとめて作成する
以下のコマンドを実行して、必要な構造を一発でまとめて作成します。
sudo mkdir -p /home/mail/Maildir/{new,cur,tmp}mkdir -p：親フォルダ（/home/mail/Maildir）がまだ存在していなくても、自動で一緒に作りながら、末尾の {new,cur,tmp} を同時に生成する便利なコマンドです。
2. フォルダの管理権限（所有権）を正しく書き換える
今、みなさんは sudo（管理者権限）を使ってこのフォルダを作りました。そのため、現在のままだとフォルダの持ち主が最高管理者の root になっています。このままだと、メールシステム（mail ユーザー）が新しいメールをここに書き込もうとした際に「権限がありません」と拒否されてしまいます。
そこで、フォルダの所有権をメール処理の担当者である mail ユーザーと mail グループへ一括で変更します。
sudo chown -R mail:mail /home/mail/Maildirchown -R：指定したフォルダだけでなく、その中にあるnew, cur, tmpも含めて、配下のすべての所有権を芋づる式に（再帰的に）書き換えるコマンドです。
設定が正しく変更されたか、以下のコマンドで確認してみましょう。
ls -ld /home/mail/Maildirコマンドを実行し、以下のように出力の真ん中あたりが mail mail になっていれば大成功です。
drwxr-sr-x 5 mail mail 4096 Jul 20 06:48 /home/mail/Maildirこれで、メールシステムがいつでも自由にメールを書き込み・読み出しできる「完璧な受け皿」が完成しました。
3-3. Postfixへの配送設定と設定の反映
受け皿ができたら、Postfixに対して「これからは届いたメールを、今作ったMaildirフォルダへ届けるんだよ」という配送指示を書き込み、設定を反映させます。今回はファイルをわざわざ手動で開くことなく、すべてコマンドだけでスマートに完結させます。
1. メールの保存先（Maildir）を指定する
以下のコマンドを実行し、Postfixの設定ファイルにMaildir形式での保存設定を追記します。
sudo postconf -e "home_mailbox = Maildir/"注意：Maildir/ の末尾にあるスラッシュ（/）は必須です。これが無いと、Postfixはフォルダではなく「Maildirという名前の単一のファイル」として処理しようとしてしまい、のちの受信テストやDovecotでの読み出し時に致命的なエラーになります。
2. 自ドメインの受信態勢（mydestination）を有効化する
次に、そもそもPostfixが「mail@test-site.online 宛てのメールは、自分自身が受け取るべきメールだ」と100%認識するための設定を行います。
ここを怠ると、外部からメールを送った際に「お前のサーバーにそんなドメインの箱は無い」と判断され、中継拒否（Relay access denied）のエラーで叩き落とされます。これも以下のコマンドで一発で上書き設定します。
sudo postconf -e "mydestination = \$myhostname, localhost.\$mydomain, localhost, test-site.online"（※コマンド内の $ の前にバックスラッシュ \ が入っているのは、Ubuntuのターミナルに「これはPostfixの変数だから、そのままファイルに書き込んでね」と伝えるためのエスケープ処理です）
3. Postfixの設定を再読み込み（リロード）する
今追加したMaildirの配送指示と、自ドメイン（test-site.online）の受信設定をシステムに完全に有効化させるため、Postfixのプロセスをリロードします。
以下のコマンドを実行してください。
sudo systemctl reload postfix4. Dovecotの設定と起動
メールを受信して手元のスマホやPC（メールクライアント）に届ける役割を持つ Dovecot の設定を行います。今回は、Postfixが受け取ったメールをMaildirへ正しく仕分けられるようにするための最低限の設定を行い、サービスを起動します。
4-1. 認証設定の変更（10-auth.conf）
まずは、メールボックスを開く際のユーザー認証の設定を変更します。Ubuntuのシステムユーザー（今回は mail ユーザー）を使って認証を行うための設定です。
設定ファイル（/etc/dovecot/conf.d/10-auth.conf）をテキストエディタで開きます。
sudo nano /etc/dovecot/conf.d/10-auth.confファイルを開いたら、以下の箇所を探して修正します。
1. 暗号化なしの認証を許可する（テスト用）
標準では、安全のために暗号化（SSL/TLS）されていない通信でのログインが禁止されています。今回はまず基本の受信テストを確実に成功させるため、一時的に暗号化なしのログインを許可します。
# 変更前
#disable_plaintext_auth = yes
# 変更後（コメントアウト「#」を外し、no に変更）
disable_plaintext_auth = no# Before
#disable_plaintext_auth = yes
# After (Remove the "#" comment character and change it to "no")
disable_plaintext_auth = no2. 認証方式の指定
今回はLinuxの標準的なユーザー認証（PAM）を使用するため、以下の行が有効（シャープが付いていない状態）であることを確認します。
auth_mechanisms = plain login※もし login が無ければ、上記のようにスペースを開けて追記してください。
変更が完了したら、ファイルを保存して閉じます（Nanoの場合、Ctrl + O ➔ Enter で保存、Ctrl + X で終了）。
4-2. メールの保存先を指定する（10-mail.conf）
次に、Dovecotに対して「メールはさっき作った /home/mail/Maildir にあるよ」と教えてあげる設定を行います。
設定ファイル（/etc/dovecot/conf.d/10-mail.conf）を開きます。
sudo nano /etc/dovecot/conf.d/10-mail.confmail_location という項目を探し、以下のように書き換えます。
# 変更前（環境によってデフォルト値は異なります）
mail_location = mbox:~/mail:INBOX=/var/mail/%u
# 変更後（Maildir形式に指定）
mail_location = maildir:~/Maildir# Before (The default value may vary depending on the environment)
mail_location = mbox:~/mail:INBOX=/var/mail/%u
# After (Set the mail storage format to Maildir)
mail_location = maildir:~/Maildir解説：~（チルダ）の意味
~ は「そのユーザーのホームディレクトリ」を表します。mail ユーザーの場合、先ほど 3-1 で /home/mail に設定したため、Dovecotは自動的に /home/mail/Maildir を見に行ってくれるようになります。
ファイルを保存して閉じます（Ctrl + O ➔ Enter で保存、Ctrl + X で終了）。
4-3. Dovecotの起動と自動起動設定
設定が完了したので、Dovecotのサービスを起動します。あわせて、サーバーが再起動した際にも自動でDovecotが立ち上がるように設定しておきます。
以下のコマンドを順番に実行します。
# Dovecotを起動する
sudo systemctl start dovecot
# サーバー起動時に自動で立ち上がるようにする
sudo systemctl enable dovecot# Start Dovecot
sudo systemctl start dovecot
# Enable Dovecot to start automatically at boot
sudo systemctl enable dovecot4-4. 起動状態の確認
Dovecotがエラーを起こさず、正常にバックグラウンドで動いているかを確認します。
sudo systemctl status dovecot出力結果の中に、緑色の文字で active (running) と表示されていれば、Dovecotは無事に起動しています！
これでDovecotの基本設定と起動までが完了しました。
5. 受信テストの実施とメールログの確認
すべての準備が整ったので、実際に外部のメールアドレス（Gmailなど）から、今回構築しているサーバー宛てにテストメールを送信し、システムがどのように処理するかログを追いかけてみましょう。
5-1. リアルタイムでのメールログ監視（コマンドの実行）
メールが届く瞬間を捉えるために、まずはサーバー側でメールの動きを記録しているログファイル（/var/log/mail.log）を監視するコマンドを立ち上げます。
VPSのターミナルで以下のコマンドを実行してください。
sudo tail -f /var/log/mail.logtail -f：ファイルの末尾（最後尾）を表示し続け、新しいデータ（ログ）が書き込まれたらリアルタイムで画面に自動追記してくれる、インフラエンジニア必須の超重要コマンドです。
コマンドを叩くと、画面の動きがピタッと止まり、ログの入力待ち状態（待機モード）になります。この画面を開いたままの状態で、次のテスト送信を行います。
ログの監視を終了するには
画面の更新を止めてコマンド入力に戻りたいときは、キーボードの Ctrl + C を押してください。
5-2. テストメールの送信
ログの監視を始めたら、ターミナルを開いているのとは別のブラウザや、普段お使いのスマートフォンなどからGmailやYahoo!メールなどの外部メールアカウントを開きます。
そして、今回受信用に用意したあなたのメールアドレス宛てにテストメールを送信してください。
- 宛先（To）：
mail@test-site.online（※あなたが構築しているメールアドレス） - 件名（Subject）：
Test Mail - 本文：
これは自宅サーバーの受信テストです。
メールの「送信」ボタンを押したら、すぐに先ほど tail -f を実行したVPSのターミナル画面（ログ監視画面）に戻り、どのようなログが流れてくるか注目してください。
5-3. ログに刻まれる処理の記録
メールを送信したら、画面に出力されるログ（/var/log/mail.log）の動きを確認します。ここまでの手順の進捗によって、サーバーは以下のようなリアルな挙動を見せます。
1. エラー：ドメインの不整合による拒否（Relay access denied）
もしPostfix側が新しいドメイン（例: test-site.online）を「自分が受信すべきドメイン」としてまだ認識していない場合、ログには以下のように中継拒否（Relay access denied）が記録され、メールが弾かれます。
2026-07-20T07:51:00.771146+09:00 vm-xxxxxxxx-xc postfix/smtpd[1013490]: connect from gz.d.sender-sib.com[77.32.148.26]
2026-07-20T07:51:01.526874+09:00 vm-xxxxxxxx-xc postfix/smtpd[1013490]: NOQUEUE: reject: RCPT from gz.d.sender-sib.com[77.32.148.26]: 454 4.7.1 <mail@test-site.online>: Relay access denied; from=<bounces-482520922-2161631984@gz.d.sender-sib.com> to=<mail@test-site.online> proto=ESMTP helo=<gz.d.sender-sib.com>注記：ログに混ざる外部からのノイズについて
サーバーを公開していると、ログに SASL LOGIN authentication failed（見覚えのないユーザー名でのログイン失敗）といった外部ボットによる不正アクセスの試行が同時に流れることがありますが、これらは今回の受信テストのエラーとは無関係なので無視して構いません。
このエラーが出た場合は、Postfixの設定（mydestination）に使用するドメインが正しく含まれているかを確認し、sudo systemctl reload postfix で設定を反映させる必要があります。
2. エラー：Maildirに入らず外部へバイパス（forwarded）
ドメインが正しく認識されるとPostfixはメールを受け付けますが、今度は以下のようにローカルに保存されず、外部のGmailアドレスなどへ右から左へ転送されてしまう現象が起きることがあります。
2026-07-20T07:59:12.603288+09:00 vm-xxxxxxxx-xc postfix/local[1013583]: 16012401DA: to=<mail@test-site.online>, relay=local, ..., status=sent (forwarded as 9244C40459)
2026-07-20T07:59:13.936792+09:00 vm-xxxxxxxx-xc postfix/smtp[1013574]: 9244C40459: to=<xxxxxxxx@gmail.com>, orig_to=<mail@test-site.online>, relay=gmail-smtp-in.l.google.com[...], status=sent (250 2.0.0 OK ... gsmtp)ログに status=sent (forwarded as ...) と記録されている場合は、システム内部の転送設定（/etc/aliases など）が生きている証拠です。このままではMaildirにメールがたまらないため、転送ルールをコメントアウト等で解除し、sudo newaliases およびPostfixのリロードを実行してサーバー内に引き留めるように修正します。
3. 成功：Maildirへの完全な配送（delivered to maildir）
すべての設定が正しく噛み合い、Postfixの再読み込みが完了した状態でテストメールを受信すると、ログの結末は以下のように変化します。
2026-07-20T08:02:01.977259+09:00 vm-xxxxxxxx-xc postfix/smtpd[1013640]: connect from gz.d.sender-sib.com[77.32.148.26]
2026-07-20T08:02:02.754145+09:00 vm-xxxxxxxx-xc postfix/smtpd[1013640]: B8073401DA: client=gz.d.sender-sib.com[77.32.148.26]
2026-07-20T08:02:03.262918+09:00 vm-xxxxxxxx-xc postfix/cleanup[1013643]: B8073401DA: message-id=<aa0d5638-8834-4953-9642-5a59aa5c7e08@smtp-relay.sendinblue.com>
2026-07-20T08:02:03.267353+09:00 vm-xxxxxxxx-xc postfix/qmgr[1013635]: B8073401DA: from=<bounces-482520922-2161631984@gz.d.sender-sib.com>, size=3643, nrcpt=1 (queue active)
2026-07-20T08:02:03.282726+09:00 vm-xxxxxxxx-xc postfix/local[1013644]: B8073401DA: to=<mail@test-site.online>, relay=local, delay=0.79, delays=0.77/0.01/0/0.01, dsn=2.0.0, status=sent (delivered to maildir)
2026-07-20T08:02:03.282913+09:00 vm-xxxxxxxx-xc postfix/qmgr[1013635]: B8073401DA: removed末尾の status=sent (delivered to maildir) という記録こそが、Postfixが外部からの接続を正しく受け入れ、どこにも逃がさずにターゲットのMaildirへとメールを無事配送できた証です。
6. 届いたメールファイル（実体）の確認
Postfixが delivered to maildir（Maildirへの配送完了）とログに残した通り、メールはすでにサーバー内のフォルダに「1つのファイル」として物理的に保存されています。
本当にメールが届いているか、コマンドを使って中身を直接覗いてみましょう。
6-1. 新着フォルダ（new）の確認
Maildir形式では、届いたばかりの未読メールは new というフォルダに一時的に格納されます。
以下のコマンドを実行して、new フォルダの中身を表示してみます。
sudo ls -l /home/mail/Maildir/new正しく届いていれば、以下のように長くて複雑なファイル名（タイムスタンプやサーバーのIDが混ざったもの）が1つ表示されるはずです。
-rw------- 1 mail mail 3643 Jul 20 08:02 1784502123.V801I40159M771146.vm-xxxxxxxx-xcファイルが表示されない場合は？
もし何も表示されない（空っぽの）場合は、前述の「外部への転送設定（aliases）」がまだ有効になっているか、あるいはPostfixのリロードが漏れている可能性があります。今一度ログのステータスを確認してください。
6-2. メールの生データ（テキスト）を覗いてみる
表示されたファイル名を指定して、cat コマンドでメールのテキストデータを画面に表示させてみましょう。
※ファイル名の部分は、先ほどご自身の画面に表示された実際の文字列に置き換えてください。
sudo cat /home/mail/Maildir/new/1784502123.V801I40159M771146.vm-xxxxxxxx-xcコマンドを実行すると、メールのヘッダー情報（送信元、宛先、経由したサーバーの記録など）と、送信された本文がずらりとテキストで表示されます。
Return-Path: <bounces-xxx@example.net>
X-Original-To: mail@test-site.online
Delivered-To: mail@test-site.online
Received: from mail-relay.example.net (mail-relay.example.net [77.32.148.26])
by your-domain.com (Postfix) with ESMTP id 4EF9E401DA
for <mail@test-site.online>; Mon, 20 Jul 2026 08:21:12 +0900 (JST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=your-domain.com;
...
From: =?utf-8?q?...?= <mail@gmail.com>
Subject: =?utf-8?q?...?=
Message-Id: <xxxx-xxxx-xxxx@smtp-relay.example.net>
To: <mail@test-site.online>
Date: Mon, 20 Jul 2026 08:21:06 +0900
User-Agent: Mozilla Thunderbird
Content-Type: multipart/alternative; boundary="------------bedxgzrvOfdYuOLGNXNVXqWT"
--------------bedxgzrvOfdYuOLGNXNVXqWT
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8; format=flowed
=EF=BD=B3=EF=BD=AA=EF=BD=B0=EF=BD=B2 =E3=83=BD(=EF=BE=9F=E2=88=80=EF=BE=9F)=
=E4=BA=BA(=EF=BE=9F=D0=94=EF=BE=9F)=E4=BA=BA(=CB=8A=E1=97=9C=CB=8B*)=EF=BE=
=89 =EF=BD=B3=EF=BD=AA=EF=BD=B0=EF=BD=B2
--------------bedxgzrvOfdYuOLGNXNVXqWT
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<!DOCTYPE html><html><head>
...
<body>
<p><font face="メイリオ">ウェーイ ヽ(ﾟ∀ﾟ)人(ﾟДﾟ)人(ˊᗜˋ*)ﾉ ウェーイ</font></p>
</body></html>
--------------bedxgzrvOfdYuOLGNXNVXqWT--ログから読み取れる大成功のポイント
by your-domain.com (Postfix) with ESMTP id 4EF9E401DA外部の配信サーバーから、自分が構築したPostfixがしっかりとメールのバトンを受け取り、固有のキューIDを発行して処理した証跡が刻まれています。- 本文の符号化（Quoted-Printable）について メールの生データ内にある
=EF=BD=B3=EF=BD=AA...のような文字列は、日本語の「ｳｪｰｲ ヽ(ﾟ∀ﾟ)人(ﾟДﾟ)人(ˊᗜˋ*)ﾉ ｳｪｰｲ」がメール送信用にUTF-8でエンコードされたものです。データが壊れているわけではないので安心してください。HTML側を見ると、無事にマルチパートで届いていることが分かります。
7. Dovecotの接続・認証テスト
PostfixがMaildirに保存してくれたメールを外部から読み出すために、ここからは「Dovecot（POP3/IMAPサーバー）」が正しく外を向いて待機しているかを確認していきます。
7-1. Dovecotのサービス起動状態を確認
まずは、Dovecotがサーバー内部でエラーを起こさず、正常にバックグラウンドで動いているかステータスを確認します。
sudo systemctl status dovecot画面に active (running) という緑色の文字が表示されていれば、サービス自体は無事に起動しています。
7-2. ポートの開放状態（Listen）の確認
メールソフトから接続を許可するためには、Dovecotが指定のポート（IMAPなら通常 143 またはセキュアな 993、POP3なら 110 または 995）で通信を待ち受けている（Listenしている）必要があります。
以下のコマンドを叩いて、現在のポートの待機状態を確認してみましょう。
sudo ss -tlpn | grep dovecot実行すると、以下のようにDovecotが各ポートをしっかりと掴んで待機しているログが出力されます。
LISTEN 0 100 0.0.0.0:143 0.0.0.0:* users:(("dovecot",pid=1013448,fd=37))
LISTEN 0 100 0.0.0.0:110 0.0.0.0:* users:(("dovecot",pid=1013448,fd=22))
LISTEN 0 100 [::]:143 [::]:* users:(("dovecot",pid=1013448,fd=38))
LISTEN 0 100 [::]:110 [::]:* users:(("dovecot",pid=1013448,fd=23))※利用するプロトコル（IMAP/POP3）の設定によって、表示されるポート番号は異なります。
7-3. ポートの外部疎通テスト（お使いのPC等からの確認）
サーバーの内部でポートが開いていても、VPS側（ConoHaのコントロールパネルにあるセキュリティグループ等）のファイアウォールでブロックされていると、手元のPCやスマホから接続できません。
外からポートが叩けるかをテストするために、ご自身のローカルPC（MacのターミナルやWindowsのコマンドプロンプト/PowerShellなど）、または別環境の端末から、サーバーのアドレスに対して以下の疎通コマンドを実行してみます。※ test-site.online の部分は、ご自身のドメインに置き換えて実行してください。
IMAP（143番ポート）の疎通確認
nc -zv test-site.online 143または
telnet test-site.online 143成功時の出力例
疎通が成功すると、以下のようなメッセージが返ってきます。
Connection to test-site.online 143 port [tcp/imap] succeeded!もしここで Connection timed out や Connection refused となってしまう場合は、Dovecotが起動していないか、あるいはConoHaのコントロールパネルのセキュリティグループで「143」や「993」といったメール用ポートのインバウンド（受信）規則が許可されていない可能性が高いです。
7-4. コマンドラインでのIMAP認証・受信テスト
外部からのポート疎通が確認できたら、そのまま telnet を使って、Dovecotに対して手動でログイン（認証）を試み、先ほどPostfixが格納してくれたメールがIMAP経由で本当に認識されているかをテストします。
1. サーバーへ接続する
作業PC等の端末から、IMAPポート（143）へ接続します。
telnet test-site.online 143出力例:
Trying xxx.xxx.xxx.xxx...
Connected to test-site.online.
Escape character is '^]'.
* OK [...] Dovecot (Ubuntu) ready.2. ログイン（認証）を実行する
IMAPの仕様に基づき、すべて半角大文字の LOGIN コマンドを使い、ユーザー名（ドメインなし）とパスワードをスペース区切りで入力します。先頭には識別子（a001）を付けます。
a001 LOGIN mail your_password※ mailはご自身が設定したメール用サブドメイン、your_password は設定したパスワードに置き換えてください。
成功時の出力例:
a001 OK [...] Logged in3. 受信トレイ（INBOX）の選択
ログインに成功したら、そのまま受信トレイの状態を確認します。
a002 SELECT INBOX成功時の出力例:
a002 SELECT INBOX
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted.
* 2 EXISTS
* 2 RECENT
* OK [UNSEEN 1] First unseen.
* OK [UIDVALIDITY 1784506101] UIDs valid
* OK [UIDNEXT 3] Predicted next UID
a002 OK [READ-WRITE] Select completed (0.016 + 0.000 + 0.015 secs).💡 勝利のチェックポイント
出力の中に * 2 EXISTS（メッセージが2通存在します）という表示に注目してください！ これは先ほど「第6章」で確認した、Maildir/new 内にある2通のテストメールを、DovecotがIMAPの規格として100%正確にスキャンして認識している証拠です。
4. ログアウト
確認が終わったら、接続コマンドを送信して安全に接続を閉じます。
a003 LOGOUT成功時の出力例:
* BYE Logging out
a003 OK Logout completed (0.001 + 0.000 secs).
Connection closed by foreign host.このように Connection closed と返ってきて自動的に元のプロンプトに戻れば、すべての通信テストが完全大成功で終了です！
8. お名前.comでのDNSレコード登録
メールサーバーへの接続経路を確立し、この後に行うLet’s Encryptによるドメインの所有権認証を通すために、ドメイン管理画面でCNAMEレコードを追加します。この設定を行わない場合、証明書発行の手順でドメインの名前解決ができず、エラーが出て失敗します。
8-1. お名前.comでのCNAMEレコード追加手順
メールサーバーを構築する際、多くの解説サイトでは「AレコードにサーバーのIPアドレスを直接登録する」と書かれています。しかし、今回は mail@test-site.online というメールアドレスを実際に開通させて送受信できるようにするため、メール専用のサブドメイン（mail.test-site.online）に対してCNAMEレコードを設定します。
なぜなら、すでに元のドメイン（test-site.online）がWebサーバーのIPアドレスを正しく指し示しているため、サブドメイン側は「本家のドメインと同じ場所を向いてね」と、本家の設定を使い回す（エイリアス・別名として定義する）方がスマートだからです。こうしておくことで、将来もしサーバーの引っ越しなどでIPアドレスが変更になった際も、本家のAレコードを1箇所書き換えるだけで、メールサーバー側の設定も自動で連動するため、メンテナンスの手間を大幅に減らすことができます。
また、設定値にあるTTL（Time To Live）とは、このDNSレコードの情報を世界中のキャッシュサーバーが「何秒間保持するか」という有効期限の秒数です。今回は標準的な「3600秒（1時間）」を設定します。これを短くしすぎると問い合わせが頻発してDNSサーバーに負荷がかかり、逆に長くしすぎると万が一設定を間違えたときに修正が反映されるまで丸一日待たされるといった事態になります。1時間というバランスは、実用性と変更時の反映速度を両立させるベストプラクティスです。
この仕組みを理解した上で、実際にレコードを追加していきましょう。
8-2. お名前.comでのCNAMEレコード追加手順
まず、お名前.com Naviにログインし、左側メニューの「ネームサーバー/DNS」を選択して対象ドメインの設定画面を開きます。「レコード追加」タブが選択されていることを確認し、以下の手順でCNAMEレコードを追加してください。
- 「入力」エリアにある各項目に、以下の通りに値を入力します。
ホスト名：mail
TYPE：CNAME
TTL：3600
VALUE：test-site.online- ホスト名 (
mail)：メールサーバー専用の窓口としてサブドメインを定義します。これにより、メールの宛先（@test-site.online）を受け取るサーバーの場所（mail.test-site.online）が作られます。 - TYPE (
CNAME)：IPアドレスを直接書くのではなく、他のドメイン名と紐付ける「別名」の規則です。 - TTL (
3600)：世界中のDNSにこの設定を1時間キャッシュさせる設定です。 - VALUE (
test-site.online)：転送先（本家ドメイン）のURLを指定します。
- ホスト名 (
- 右側にある「追加」ボタンをクリックします。これで入力した内容が確定待ちとして下部の「追加」リストに反映されます。
- 画面最下部の「確認画面へ進む」ボタンをクリックし、内容に問題がなければ「設定する」をクリックして確定させます。
- サーバーのターミナルで名前解決の反映を確認します 設定したCNAMEレコードがネットワーク上に浸透するまで、数分から数十分かかります。情報が正しく行き渡ったかをサーバー側から確認するために、以下の「名前解決（nslookup）」コマンドを実行します。
sudo nslookup mail.test-site.onlineコマンドを実行し、以下のように出力されるのを確認します。
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
mail.test-site.online canonical name = test-site.online.
Name: test-site.online
Address: サーバーのグローバルIPアドレスServer: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
mail.test-site.online canonical name = test-site.online.
Name: test-site.online
Address: your-server's-public-IP-address注目べきは「canonical name = test-site.online.」という部分です。これが「mail.test-site.online の正体は test-site.online ですよ」というCNAMEの繋がりを証明しています。さらに、その転送先である本家のIPアドレスまで一発で芋づる式に引けていれば、外部からメールサーバーへの道が完璧に開通した証拠です。
DNSの正常な反映が確認できたら、このドメインを使って次の「SSL証明書の取得」の章へ進みます。
9. Let’s EncryptによるSSL/TLS証明書の新規取得
メールの送受信やログイン情報を暗号化するために、信頼された認証局（Let’s Encrypt）から公式のSSL/TLS証明書を完全新規で発行します。これにより、mail@test-site.online を安全に運用する土台を作ります。
ここまで一連の記事を読んで実践してきた方は、すでにメインのWebサイト用（test-site.online）としてSSL証明書を取得しているはずです。「じゃあ、もう暗号化の設定は終わっているのでは？」と思うかもしれませんが、実はWebサイト用の証明書は、今回新しく作ったメール専用のサブドメイン（mail.test-site.online）には適用されません。メールの送受信を安全に保護するためには、このメール用ドメインに対して、完全に独立した新しいSSL証明書をイチから取得し直す必要があります。
⚠️ 超重要：コマンドを実行する場所について
本環境は「VPSをリレー（リバースプロキシ）として経由し、自宅のHGW（XG-100NE）配下にある自宅サーバーへ繋ぐ」という特殊なインフラ構成をとっています。お名前.comで設定したDNSのアクセス（80/443ポート）を最初に受け止めるのは外部のVPSです。そのため、ここからのCertbotインストールや証明書発行のコマンドは、自宅サーバーではなく必ず「VPS側のUbuntu」にSSH接続した状態で実行してください。自宅サーバー側から叩いてもLet’s Encryptの外部認証が通らず、エラーになります。
この「メールサーバーのための初めての認証」を、以下の手順で進めていきましょう。
9-1. Certbot（Let’s Encryptクライアント）のインストール
まずは証明書を自動発行・自動更新してくれる公式ツール「Certbot」と、今回の環境であるWebサーバー「Nginx」と Certbot を連動させるためのプラグインをシステムに導入します。
💡 一連の記事を実践中の方へ：
前段のWebサイト構築手順などで、すでにVPS側にCertbotとNginxプラグインのインストールを完了している場合は、ここの手順（9-1）はスキップして、次の「9-2. メール用ドメインの証明書発行」へそのまま進んでしまって大丈夫です。このページから読み始めた初見の方は、環境を揃えるためにVPSのターミナルで以下のコマンドを実行してください。
以下のコマンドを順番に実行します。まずはパッケージリストを最新状態に更新します。
sudo apt updateリストが更新されたら、Certbot本体とNginx用プラグインをまとめてインストールします。末尾の -y は、途中で聞かれる「インストールしますか？ [Y/n]」の確認を自動でスキップするためのオプションです。
sudo apt install certbot python3-certbot-nginx -y9-2. メール用ドメインの証明書発行
ここからが本番です。インストールした Nginx用プラグインを利用して、メールサーバーとして使用する専用ドメイン（mail.test-site.online）のSSL証明書を発行します。
以下のコマンドを実行します。--nginx をつけることで、Certbotが自動的にNginxの現在の設定を一時的に読み取って認証（ACMEチャレンジ）を行い、証明書の取得からNginxへの設定追記までを全自動でやってくれます。
sudo certbot --nginx -d mail.test-site.onlineコマンドを実行すると、ターミナル上で対話式の初期設定が始まります。画面の指示に従って入力を進めてください。
- 連絡用メールアドレスの登録（※初回実行時のみ表示） 証明書の有効期限切れ（90日間）が近づいたときの警告や、セキュリティ上の重要な通知を受け取るためのアドレスです。開通させる
mail@test-site.onlineや、普段受け取れるアドレスを入力してEnterを押します。
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Enter email address (used for urgent renewal and security notices)
(Enter 'c' to cancel): mail@test-site.online- 利用規約への同意（※初回実行時のみ表示） Let’s Encryptのサービス利用規約への同意を求められます。同意しないと証明書が発行できないため、大文字の Y を入力してEnterを押します。
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.4-April-3-2024.pdf. You must
agree in order to register with the ACME server. Do you agree?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: Y- 電子フロンティア財団からのメール購読の可否（※初回実行時のみ表示） Certbotの開発元である非営利団体（EFF）からのニュースレターやキャンペーン情報を受け取るか尋ねられます。これは任意なので、不要であれば N を入力してEnterを押します。
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Would you be willing, once your first certificate is successfully issued, to
share your email address with the Electronic Frontier Foundation, a founding
partner of the Let's Encrypt project and the non-profit organization that
develops Certbot? We'd like to send you email about our work encrypting the
web, EFF news, campaigns, and ways to support digital freedom.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: N- 発行完了の確認
Let’s Encryptのサーバーが、お名前.comで設定したDNSレコードを伝ってあなたのサーバーにアクセスし、問題がなければ自動的にNginxの設定ファイルにSSL用の記述が追記されます。処理がすべて成功すると、画面に以下のメッセージが表示されます。
Account registered.
Requesting a certificate for mail.test-site.online
Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/mail.test-site.online/fullchain.pem
Key is saved at: /etc/letsencrypt/live/mail.test-site.online/privkey.pem
This certificate expires on 2026-10-18.
These files will be updated by Certbot when the certificate renews.
Deploying certificate
Successfully deployed certificate for mail.test-site.online to /etc/nginx/sites-enabled/test-site.online
Congratulations! You have successfully enabled HTTPS on https://mail.test-site.onlineログの中に「Certificate is saved at: ...」と、新しく生成された証明書（fullchain.pem）と秘密鍵（privkey.pem）の配置パスが表示され、最後に Congratulations! と表示されればWebサーバーへの紐付けは無事完了です。
9-3. Postfix（送信サーバー）への証明書適用
さきほど Nginx 用に取得したSSL証明書は、メール送信（SMTP）を担う「Postfix」というプログラムにも共有して読み込ませる必要があります。これを行うことで、mail@test-site.online からメールを送信する際の通信内容やパスワードが安全に暗号化されます。
- Postfixのメイン設定ファイルを開きます。
設定を書き換えるために、管理者権限（sudo）でnanoエディタを起動します。
sudo nano /etc/postfix/main.cf- 証明書と秘密鍵のパスを書き換えます。
ファイル内をスクロールして、TLS（暗号化通信）関連の設定項目を探します。既存の古いデフォルト証明書の記述がある箇所、あるいは新規に指定する箇所を、先ほどCertbotが発行してくれた以下の正しいパスにそっくりそのまま書き換えます。
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.test-site.online/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.test-site.online/privkey.pemsmtpd_tls_cert_file：外部に公開する「証明書（正体証明用の看板）」の置き場所を指定します。smtpd_tls_key_file：暗号化を解くための「秘密鍵（絶対に外に漏らしてはいけないマスターキー）」の置き場所を指定します。
- 書き換えが完了したら、変更を確定させるために Ctrl + O を押し、ファイル名を確認して Enter を押します。その後、Ctrl + X を押してエディタを閉じます。
- Postfixに設定を再読み込みさせて適用します。
ファイルを保存しただけでは、まだPostfixは古い設定のまま動いています。書き換えた設定（新しい証明書）をシステムに反映させるために、以下のコマンドでPostfixを再起動（リロード）します。
sudo systemctl reload postfixこれで、送信サーバー（Postfix）側の暗号化基盤の構築はすべて完了です！
10. Dovecot（受信サーバー）への証明書適用
Postfix（送信側）の暗号化が終わったら、次は受信（IMAP/POP3）を担当するDovecotにも同じSSL証明書を読み込ませます。
ここを設定しないと、メールアプリ（OutlookやiPhoneのメールなど）からサーバーに接続してメールを同期しようとした際に「通信が暗号化されていないため接続できません」と拒否されたり、パスワードが暗号化されずにネットワーク上を流れるという非常に危険な状態になってしまいます。安全にメールを読み出すために、DovecotのSSL設定ファイルを書き換えていきましょう。
10-1. DovecotのSSL設定ファイルの編集手順
Dovecotの設定は、機能ごとにファイルが細かく分かれています。今回はSSLに関する設定がまとめられている 10-ssl.conf を編集します。
- DovecotのSSL設定ファイルを開きます。管理者権限（sudo）を使って、nanoエディタで設定ファイルを開きます。
sudo nano /etc/dovecot/conf.d/10-ssl.conf- SSL機能を「有効」に変更します。ファイルを開いたら、まず
ssl =で始まる項目を探します。ここがnoやyes（コメントアウトされている状態）になっている場合は、以下のようにrequiredに書き換えます。
ssl = requiredrequired：暗号化（SSL/TLS）されていない接続を完全に禁止し、安全な接続のみを強制する設定です。
- 証明書と秘密鍵のパスを書き換えます。
次に、証明書と秘密鍵の置き場所を指定している項目を探します。デフォルトでは自己証明書（オレオレ証明書）のパスが入っているので、先ほどCertbotで取得したLet’s Encryptのパスに書き換えます。
【重要】
各行の先頭にある <（不等号記号）を絶対に消さないよう注意してください。 Dovecotの仕様で、この記号は「ファイルから内容を読み込む」という意味を持っています。
ssl_cert = </etc/letsencrypt/live/mail.test-site.online/fullchain.pem
ssl_key = </etc/letsencrypt/live/mail.test-site.online/privkey.pemssl_cert：看板となる「証明書（fullchain.pem）」のパスを指定します。ssl_key：鍵となる「秘密鍵（privkey.pem）」のパスを指定します。
書き換えが終わったら、Ctrl + O ➔ Enter で保存し、Ctrl + X でエディタを閉じます。
- 変更した設定を有効にするために、Dovecotサービスを再起動（リロード）します。
sudo systemctl reload dovecot11. コマンドラインでのIMAP認証・受信テスト
送信（Postfix）と受信（Dovecot）の暗号化設定まで完了したら、外部のクライアントからメールサーバーにアクセスして、メールをIMAP経由で認識できるかを最終テストします。
ただし、テストに移る前に「外部からの接続を許可する壁」をクリアしておく必要があります。
11-1. 自宅サーバー側のインバウンド（受信）規則の確認
外部からメールを読み出す（IMAP接続する）ためには、暗号化されたIMAP通信が通る専用ポート 「993ポート（IMAPS）」 が外から通じる状態になっていなければなりません。
もし、ここまでの設定を完璧に終えているのにこの後のテストで接続エラー（Timeoutなど）になる場合は、VPS側、または自宅のHGW（XG-100NE）側のインバウンド（受信）規則で993ポートの許可が漏れている可能性が極めて高いです。
テストが失敗する場合は、以下の2点を確認してください。
- VPSのファイアウォール（UFWなど）:
外部からの993ポートへの接続が「ALLOW（許可）」されているか。 - XG-100NE（HGW）の静的IPマスカレード設定：
VPSを経由して届いた993ポートのパケットが、自宅サーバーのローカルIPアドレスへ正しく転送されているか。
外部からのポート疎通がしっかりと確認できたら、いよいよ手動での受信テストに移ります。
11-2. サーバーへ接続して手動ログイン（認証）を試す手順
テストには telnet コマンド、あるいはSSL/TLS暗号化通信にそのまま対応できる openssl コマンドを使用します。今回はSSLが必須（ssl = required）に設定されているため、openssl コマンドを使って暗号化を維持したままDovecotに対して手動ログインを試みます。
- 外部の端末（またはVPS側）からメールサーバーの993ポートへ接続します。ターミナルから以下のコマンドを叩き、メールサーバーへ接続を確立します。
openssl s_client -connect mail.test-site.online:993コマンドを実行すると、SSL証明書の検証ログがズラズラと流れたあと、最後にDovecotからの応答メッセージ（* OK ...）が表示されて入力待機状態になります。
(中略)
---
* OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ENABLE ID LEAVE-WORKSPACE ...] Dovecot ready.- 疎通を確認したら、手動でログイン（認証）を試みます 入力待機状態になったら、以下の形式でメールアドレスのユーザー名（例：
mail）とパスワードを入力してEnterを押します。
先頭のa001は、IMAPコマンドの識別番号（タグ）なので、そのまま入力してください。
a001 LOGIN mail あなたが設定したパスワード
a001 LOGIN mail your-configured-password認証が成功すると、以下のように「a001 OK」というログが返ってきます。
a001 OK [CAPABILITY IMAP4rev1 ...] Logged in- 先ほどPostfixが格納してくれたメールが本当に認識されているかを確認します
無事にログインできたら、受信トレイ（INBOX）のステータスを確認して、メールが届いているかを調べます。以下のコマンドを入力します。
a002 EXAMINE INBOXコマンドを叩くと、受信トレイの中身が解析され、以下のようなステータスが返ってきます。
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS ()] Read-only mailbox.
* 1 EXISTS
* 0 RECENT
a002 OK [READ-ONLY] Examine completed (0.001 secs)注目すべきは * 1 EXISTS という部分です。これが「現在、受信トレイにメールが確かに1通存在していますよ」という証拠になります。先ほどPostfixが内部で配送し、格納してくれたメールが、IMAP経由で完全に認識されていることがこれで証明されました。
- テストが完了したら、接続を終了します 確認が終わったら、ログアウトのコマンドを叩いて通信を切断します。
a003 LOGOUT* BYE Logging out
a003 OK Logout completed (0.001 secs)
closed接続が閉じ、通常のターミナル画面に戻ればすべてのテストは合格です！
これで、mail@test-site.online の開通段取り、およびSSL/TLSを用いた安全な送受信の検証がすべて完了しました！
12. メールアプリ（PC・スマホ）へのアカウント設定
サーバー側の準備がすべて整ったら、最後に普段使っているメールアプリ（iPhoneの「メール」アプリ、Androidの「Gmail」アプリ、PCの「Thunderbird」や「Outlook」など）に自分のメールアカウントを設定していきましょう。
手動設定を選択し、以下の情報を正確に入力することで、いつでもどこでもメールの送受信ができるようになります。
12-1. アプリに設定する接続情報一覧
メールアプリの新規アカウント追加画面から「手動設定（マニュアル設定）」を選び、以下の通りにパラメーターを指定します。
| 設定項目 | 入力する値・設定内容 | 補足説明 |
|---|---|---|
| メールアドレス | mail@test-site.online | 今回開通させたあなたのメールアドレスです。 |
| ユーザー名 （アカウント名） | サーバーがあなたを識別するためのIDです。 | |
| パスワード | サーバー側で設定したユーザーのパスワード | 暗号化通信（SSL）の上を通るので、安全に送信されます。 |
| 受信サーバー （IMAP） | mail.test-site.online | お名前.comのCNAMEでVPS（串）を経由して、自宅サーバーへと繋がります。 |
| 受信ポート / 保護 | 993 / SSL/TLS | 先ほどDovecotで設定した、暗号化必須（ssl = required）の安全なポートです。 |
| 送信サーバー（SMTP） | mail.test-site.online | 受信と同じく、暗号化の窓口となるサブドメインを指定します。 |
| 送信ポート / 保護 | 465(または587) / SSL/TLS (またはSTARTTLS) | Postfix側で設定した暗号化送信用のポートです。 |
| 送信の認証 | 「必要」にチェックを入れる | 受信時と同じユーザー名・パスワードを使って送信認証を行います |
12-2. 設定時の注意点とトラブルシューティング
情報を入力して「完了」を押した際、もし接続エラーになってしまう場合は、以下のポイントを上から順番にチェックしてみてください。
- ユーザー名にアドレス全体が入ってしまっている（最頻出）
Thunderbirdなどのメールアプリで手動設定をすると、アプリ側は気を利かせて（あるいは自動で）ユーザー名の欄にメールアドレス全体（mail@test-site.online）をそのまま入力してしまいます。 しかし、今回の環境はLinuxのシステムユーザー（mailユーザー）を使って認証を行う仕組みです。そのため、ユーザー名の欄に@test-site.onlineが残ったままだと、サーバー側で「そんなユーザーはいない」と100%認証エラーになります。アカウント設定画面の「ユーザー名（またはユーザーID）」の欄を、手動で@以降をバックスペースで削って「mail」だけになっているかを必ず確認してください。 - ポートと保護方式の組み合わせ
「ポート993」を選んだら、保護方式は必ず「SSL/TLS」に設定してください。ここが「なし」や「STARTTLS」になっていると、Dovecotが安全性を守るために接続を強制切断します。 - パスワードの打ち間違い
先ほどopensslコマンドのテスト（a001 LOGIN...）で通ったものと全く同じパスワードがアプリ側にも入っているか、大文字・小文字の区別を含めてもう一度見直してみましょう。
アプリ側で設定が正常に保存され、同期マークがぐるぐる回ったあとにテストメールが受信トレイにパッと表示されれば……「VPS串経由×XG-100NE自宅サーバー」による完全自作メールサーバーの開通、これにてコンプリートです！
13. まとめ：自分だけの安全なメールインフラが完成！
長旅、本当にお疲れ様でした。これで「VPSをフロントのリレー（串）として構え、自宅のHGW（XG-100NE）配下の自宅サーバーへとパケットを流し込む」という、非常に堅牢でロマンの詰まったプライベートメールサーバーが完全に開通しました！
ネット上によくある「ただコマンドをコピペして終わり」の記事とは違い、今回の構築を通じてみなさんは以下の本質的なインフラ技術を自分のものにしています。
- IP変更にも強いDNS設計（Aレコード直打ちではなく、運用のしやすさを考えたCNAMEとTTL 3600の意味）
- 本番環境を壊さないための危機管理（お名前.comのネームサーバー初期化トラップを回避し、既存サイトのダウンを防ぐ判断力）
- 通信の完全暗号化（VPS側でCertbotを動かして新ドメインの認証を通し、Postfix/Dovecotへ適用する仕組み）
メールソフトにアカウントを設定し、自分の受信トレイにテストメールがパッと届いたあの瞬間は、自作サーバー構築の中で最も感動するポイントです。大手サービスに依存しない、世界に一つだけの独立したメールインフラ（mail@test-site.online）は、今日からあなたの手で自由にコントロールできます。
次のステップへ
無事に送受信ができるようになったら、自作メールサーバーの旅は次のステップへと進みます。現代のメール運用に欠かせない、「送信ドメイン認証（SPF / DKIM / DMARCレコードの設定）」です。
これらを設定していくことで、あなたのサーバーから送ったメールがGmailやYahoo!メールなどの大手サービスに「迷惑メール」として弾かれるのを防ぎ、サーバーとしての信頼性をさらに引き上げることができます。
仕組みを理解しながら構築したみなさんなら、次のステップも必ずクリアできるはずです。自らの手でインフラを支配する楽しさを、ぜひこれからも存分に味わってください！
次回の記事は2026年8月10日公開です。
コメント