投稿者: testa@admini1

「独自ドメインでメールを使っているけど、迷惑メールに分類されることが多くて」——この悩みを抱えているなら、SPF・DKIM・DMARCの3つが設定されていない可能性が高いです。この3つはメールの「身元証明書」のようなもので、設定されていないドメインからのメールはGmailやOutlookに迷惑メール扱いされます。2024年以降、GoogleとYahooがこれらの設定を送信者に義務付けており、もはや設定は必須です。

SPF・DKIM・DMARCをたとえで説明しましょう。SPFは「このドメインのメールを送っていいサーバーの住所録」（正規の差出人リスト）、DKIMは「メールに押された公証印」（改ざんされていない証明）、DMARCは「偽物のメールが来たときにどう処理するかのルール」（なりすまし対策ポリシー）です。3つ揃って初めてメール認証が完成します。

担当者S：「うちの会社のメールがお客さんの迷惑メールフォルダに入ってしまって、重要な連絡が届いていないことがわかりました」
エンジニアT：「SPFとDKIMは設定されていますか？」
S：「SPFは設定した気がするんですが、DKIMとDMARCは聞いたことも…」
T：「まずdigコマンドで現状を確認しましょう。おそらくDKIMが未設定です。それだけでGmailのスコアが大幅に下がります」

まず現状のメール認証設定を確認してみましょう。

# SPFレコードの確認
dig example.com TXT | grep spf

# DKIMレコードの確認（selectorはメールサービスにより異なる）
# Google Workspaceの場合
dig google._domainkey.example.com TXT

# DMARCレコードの確認
dig _dmarc.example.com TXT

# メール認証チェックツールで総合確認
# https://mxtoolbox.com/emailhealth/ でも確認可能

各レコードの設定例を見てみましょう。DNSのTXTレコードとして追加します。

# SPFレコードの例（Google Workspaceを使用している場合）
# ホスト名: @（ルートドメイン）
# 値:
v=spf1 include:_spf.google.com ~all

# DMARCレコードの例（まず監視モードで始める）
# ホスト名: _dmarc
# 値:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100

# 段階的に強化する場合
# p=quarantine（迷惑メールへ移動）
# p=reject（完全に拒否）

DKIMの設定はご利用のメールサービス（Google Workspace・Microsoft 365・SendGrid等）の管理画面で生成した公開鍵をDNSに追加する形になります。設定後、send実際のメールのヘッダーを確認してAuthentication-Results: dkim=passと表示されれば成功です。メールが届かない・迷惑メール扱いされるという問題の多くは、この3つの設定で解決します。今日中に確認してください。

「プラグインが30個入ってるWordPressサイト、なんか遅いんだよね」——なんか遅い、ではなく「当然遅い」です。WordPressのプラグインは一つ一つがPHPファイルとデータベースクエリを追加します。10個で遅くなり、20個でもっと遅くなり、30個では表示速度が悲惨なことになっていても不思議ではありません。

WordPressのプラグインをたとえで説明すると「バックパックに詰め込む荷物」のようなものです。便利なものを次々と詰め込んでいくと、最終的には重くて歩けなくなります。「このプラグイン便利そう」と入れ続けた結果、サイトが重くて誰も見てくれなくなる——本末転倒です。

クライアントQ：「サイトのPageSpeedスコアが20点しかないんですが」
エンジニアR：「プラグインは何個入ってますか？」
Q：「数えたことないですが…40個くらいかな」
R：「まずそれです。有効化されているだけで読み込まれるプラグインが大量にあります。Query Monitorで実際に何が重いか確認しましょう。おそらく10個以下にできますよ」

まずサイトのパフォーマンスを計測して現状を把握しましょう。

# WordPress CLIでプラグイン一覧を確認
wp plugin list --status=active --fields=name,version

# データベースクエリ数と実行時間を確認（Query Monitor導入後）
# 管理バーの「Query Monitor」から確認可能

# Webページの表示速度をcurlで計測
curl -o /dev/null -s -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://example.com

次に、重複機能を持つプラグインを整理します。よくある重複の例をあげると、SEOプラグインを2個入れている・キャッシュプラグインが複数ある・セキュリティプラグインが重複しているなどです。

# キャッシュのクリア（WP Super Cacheの場合）
wp super-cache flush

# 不要プラグインの無効化と削除
wp plugin deactivate plugin-name
wp plugin delete plugin-name

# オートロードされるオプションの確認（DBが重い原因になることも）
wp db query "SELECT option_name, length(option_value) as size FROM wp_options WHERE autoload=yes ORDER BY size DESC LIMIT 20;"

プラグイン整理の目安は「有効化プラグイン20個以下」です。それ以上になっているなら、一つひとつ「本当に必要か」を見直しましょう。軽いWordPressは速いWordPressです。速いサイトはSEOにも有利です。プラグインを減らすことは、サイトへの投資です。

「自分専用のVPNを持ちたい」「会社のリモートアクセス環境を自前で構築したい」——そう思ったとき、かつてはOpenVPNが定番でした。しかしWireGuardの登場でその常識は変わりました。設定がシンプル、パフォーマンスが高い、コードベースが小さくセキュリティ監査がしやすい——VPNを自前で建てるなら今はWireGuardが最良の選択です。

WireGuardをたとえで説明すると「最新の電気自動車」のようなものです。OpenVPNが「実績豊富だが複雑な仕組みのガソリン車」とすると、WireGuardは「構造がシンプルで高速・省エネな電気自動車」です。設定ファイルはわずか数行、接続速度は従来のVPNより数倍速く、バッテリー消費（CPU負荷）も格段に少ない。

エンジニアO：「OpenVPNの設定ファイルが複雑すぎて管理しきれなくて…」
同僚P：「WireGuardに乗り換えてみなよ。設定ファイルが10行くらいで済むし、接続も一瞬だよ」
O：「本当に？OpenVPNは証明書管理だけで大変だったのに」
P：「WireGuardは公開鍵暗号だけで済む。鍵ペアを生成して相手に公開鍵を渡すだけで接続できる」

VPS（Ubuntu）にWireGuardサーバーを構築する手順を見てみましょう。

# WireGuardのインストール
sudo apt update && sudo apt install wireguard -y

# サーバーの鍵ペア生成
wg genkey | sudo tee /etc/wireguard/server_private.key | \
  wg pubkey | sudo tee /etc/wireguard/server_public.key

# クライアントの鍵ペア生成
wg genkey | tee client_private.key | wg pubkey > client_public.key

# /etc/wireguard/wg0.conf を作成
sudo nano /etc/wireguard/wg0.conf

[Interface]
PrivateKey = サーバーの秘密鍵
Address = 10.0.0.1/24
ListenPort = 51820
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = クライアントの公開鍵
AllowedIPs = 10.0.0.2/32

# IPフォワーディングを有効化
echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

# WireGuardを起動・自動起動設定
sudo systemctl enable wg-quick@wg0
sudo systemctl start wg-quick@wg0

# 接続状態の確認
sudo wg show

クライアント側（スマートフォンやPC）はWireGuardの公式アプリをインストールし、設定ファイルをQRコードで読み込むだけで接続できます。OpenVPNの複雑さに疲れたなら、今すぐWireGuardに移行しましょう。

「rootでログインした方が楽だから」——この一言でLinuxサーバーのセキュリティが崩壊します。rootユーザーはシステム上のあらゆる操作が可能な神アカウントです。rootで直接SSHログインを許可することは、マスターキーを玄関ドアに挿しっぱなしにして外出するようなものです。いつ誰が使っても文句は言えません。

rootとsudoの関係をたとえで説明すると「会社のマスターキーと部門キー」のようなものです。マスターキー（root）はすべての部屋を開けられますが、常に持ち歩く必要はありません。必要なときだけ金庫から取り出す（sudo）——普段は部門キー（一般ユーザー）で十分です。しかもsudoには「誰が・いつ・何をした」という記録が残ります。

システム管理者M：「本番サーバーのファイルが突然消えたんですが、誰がやったかわからなくて」
セキュリティ担当N：「全員rootで作業していたんですか？」
M：「はい、共有のrootパスワードで…」
N：「それでは誰がやったか特定できません。全員に個別アカウントを作ってsudoで作業させる体制にしなかったことが根本原因です。sudoなら/var/log/auth.logに全操作記録が残ります」

rootでのSSHログインを禁止して一般ユーザーに切り替える手順です。

# 1. 一般ユーザーを作成してsudoグループに追加
useradd -m -s /bin/bash deployer
passwd deployer
usermod -aG sudo deployer

# 2. sudoの動作確認
su - deployer
sudo whoami  # rootと表示されればOK

# 3. SSHの設定でrootログインを無効化
sudo vi /etc/ssh/sshd_config
# PermitRootLogin no  に変更
# PermitRootLogin prohibit-password  でも可（鍵認証のみ許可）

sudo systemctl reload sshd

# sudoの操作ログを確認
grep sudo /var/log/auth.log | tail -20

# 特定ユーザーのsudo履歴
grep "deployer.*sudo" /var/log/auth.log

# sudoersファイルの安全な編集（visudoを必ず使う）
sudo visudo
# deployer ALL=(ALL:ALL) ALL  を追加

「rootで作業した方が速い」は短期的な楽さと引き換えに、長期的なリスクと監査不能を招きます。チームで運用しているサーバーならなおさら、誰が何をしたかを記録できる体制が必須です。今日、rootログインを無効化して一般ユーザー運用に切り替えましょう。

「CMSはWordPressでいいか」——多くのプロジェクトでそう決断されてきました。しかし2025年現在、「ヘッドレスCMS」という選択肢が急速に普及しており、用途によってはWordPressよりもはるかに優れた体験を提供できます。CMSを選ぶ前に、ヘッドレスCMSという概念を必ず頭に入れておくべきです。

従来のCMSと ヘッドレスCMSの違いをたとえで説明しましょう。従来のCMSは「レストランのセット料理」のようなものです。キッチン（コンテンツ管理）とダイニング（表示）がセットになっていて、変更の自由度が限られます。一方ヘッドレスCMSは「食材の宅配サービス」のようなものです。コンテンツ（食材）だけを提供し、どう料理して（フロントエンド）どう提供するか（Web/アプリ/IoT）は完全に自由です。

プロダクトマネージャーK：「WordPressで作ったサイトをアプリにも展開したいんですが」
エンジニアL：「それ、ヘッドレスCMSにした方が断然楽ですよ。ContentfulとかSanity.ioとかMicroCMSを使えば、同じコンテンツをWeb・iOS・Androidどこにでも同じAPIで配信できます」
K：「WordPressでもREST APIがあるんじゃないですか？」
L：「ありますが、ヘッドレス専用のCMSの方がコンテンツ設計の柔軟性・APIのパフォーマンス・CDN配信の最適化が段違いです」

代表的なヘッドレスCMSのAPIを実際に叩いてみましょう。MicroCMS（日本製）の例です。

# MicroCMS APIからコンテンツを取得
curl "https://YOUR_SERVICE.microcms.io/api/v1/articles" \
  -H "X-MICROCMS-API-KEY: YOUR_API_KEY"

# 特定の記事を取得
curl "https://YOUR_SERVICE.microcms.io/api/v1/articles/CONTENT_ID" \
  -H "X-MICROCMS-API-KEY: YOUR_API_KEY"

# フィルタリング（カテゴリで絞り込み）
curl "https://YOUR_SERVICE.microcms.io/api/v1/articles?filters=category[equals]tech" \
  -H "X-MICROCMS-API-KEY: YOUR_API_KEY"

Next.jsと組み合わせてSSG（静的サイト生成）構成にすれば、表示速度・セキュリティ・スケーラビリティのすべてが向上します。サーバーが不要になるためインフラコストも削減できます。

もちろんWordPressが最適な場面もあります。ブログ・コーポレートサイト・ECサイトで非エンジニアがコンテンツ管理するケースや、豊富なプラグインエコシステムを活かしたい場合です。重要なのは「なんとなくWordPress」ではなく「この要件にはWordPressが最適」という意識的な選択をすることです。

「CloudflareのDNSは使ってるけど、Proxyはオフにしてる」——そう言うエンジニアに聞きたいのですが、なぜサーバーのIPアドレスを世界中に公開しているのですか？CloudflareのProxyを無効（DNSのみ）にした状態では、ドメインを調べるだけでサーバーの実IPが丸わかりになります。これはDDoS攻撃者や不正アクセス試行者にとって絶好の標的情報です。

Cloudflare ProxyをたとえればAに説明すると「有名人のボディーガード」のようなものです。ボディーガードがいれば、有名人（サーバー）の自宅住所（IPアドレス）を知られることなく、公の場（インターネット）に立てます。攻撃者はボディーガード（Cloudflare）のIPしか知ることができず、本人（サーバー）には直接近づけません。

エンジニアI：「DDoS攻撃を受けてサーバーがダウンしました」
コンサルタントJ：「CloudflareのProxy設定はオンになってましたか？」
I：「いえ、DNSだけ使っていてProxyはグレーのままでした」
J：「それだとサーバーのIPが丸見えです。Proxyをオレンジ色（有効）にしておけば、攻撃者はCloudflareのIPしかわからないので、サーバーへの直接攻撃はできません」

CloudflareのProxy設定はDNSダッシュボードのレコード一覧で、雲のアイコンをクリックするだけでオン/オフできます（オレンジ=有効、グレー=無効）。APIで操作する場合はこちらです。

# Proxy設定をオンにする（proxied: true）
curl -X PUT "https://api.cloudflare.com/client/v4/zones/ZONE_ID/dns_records/RECORD_ID" \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"type":"A","name":"example.com","content":"1.2.3.4","ttl":1,"proxied":true}'

Proxy有効時に注意すべき点もあります。ポート制限があり、HTTP(80)/HTTPS(443)以外のポートは直接通信できません（Cloudflare Spectrumで対応可能）。またSSL設定は「Full (strict)」が推奨です。オリジンサーバーのIPが漏れないよう、メールサーバーのMXレコードなど他のレコードも確認しましょう。

Cloudflareを使うなら、Proxyを有効にして初めてその真価を発揮します。「DNSだけ使う」はCloudflareを半分しか使っていないと心得てください。

「WordPressをインストールしたのでそのまま公開しました！」——この一文を読んで鳥肌が立ったエンジニアは正しい感覚をお持ちです。素のWordPressは、インターネット上に出た瞬間から攻撃対象になります。デフォルト設定のまま放置することは、玄関ドアを開けっ放しにして外出するようなものです。

WordPressのセキュリティをたとえで説明すると「築古のアパートのリフォーム」のようなものです。住めないわけではないけど、鍵を新しくして、窓に補助錠をつけて、不審者センサーを設置して——ひとつひとつの対策が積み重なって初めて安全な住まいになります。WordPressも同じで、個々の設定変更が積み重なって安全なサイトになります。

ユーザーG：「WordPressのサイトが乗っ取られて、スパムサイトにリダイレクトされるようになってしまいました」
エンジニアH：「ログインURLはデフォルトのwp-login.phpのままでしたか？」
G：「はい、変えてませんでした」
H：「それが原因のひとつです。デフォルトURLへの総当たり攻撃は常に行われています。プラグインとコアのバージョンも古いままでしたか？」
G：「更新の通知は出てたんですが、面倒で…」
H：「その『面倒』が今回のトラブルを招いています」

まず、WordPressの管理画面URLをデフォルトから変更しましょう。WPS Hide Loginプラグインを使うか、wp-config.phpに設定を追記します。

# wp-config.php に追記してログインURLを変更
define( WPS_HIDE_LOGIN_SLUG, my-secret-login );

# WordPress CLIでコアとプラグインを一括更新
wp core update
wp plugin update --all
wp theme update --all

# ファイルパーミッションの適切な設定
find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;
chmod 600 /var/www/html/wp-config.php

次に、wp-config.phpに以下のセキュリティ設定を追加します。

// ファイル編集を管理画面から無効化
define( DISALLOW_FILE_EDIT, true );

// WordPress バージョン情報を非表示
remove_action( wp_head, wp_generator );

// XMLRPCを無効化（攻撃に悪用されやすい）
add_filter( xmlrpc_enabled, __return_false );

さらに.htaccessで wp-admin への直接アクセスを自分のIPのみに制限するとさらに安全です。WordPressは世界で最も使われているCMSであると同時に、最も攻撃対象になっているCMSでもあります。「素のまま」で公開することの意味を、今一度真剣に考えてみてください。

「VPSを借りた！さっそくアプリをデプロイしよう！」——その気持ちはわかります。しかし初期設定をすっ飛ばしたVPSは、インターネット上に鍵をかけずに置いた家と同じです。VPSを借りてから数分以内に、世界中のボットがSSHポートへの総当たり攻撃を開始します。これは脅しではなく、実際にログを見れば確認できる現実です。

VPSのセキュリティをたとえで説明すると「新居に引っ越したときの最初の作業」のようなものです。鍵を交換し（rootログイン禁止・SSHポート変更）、防犯カメラをつけ（ファイアウォール設定）、不審者を検知する仕組みを入れる（fail2ban）——これらを最初にやるかどうかで、その後の安全性が大きく変わります。

新人エンジニアE：「VPS借りたんですが、何から始めればいいですか？」
シニアF：「まず一般ユーザーを作ってsudo権限付与、rootのSSHログインを無効化、公開鍵認証に切り替え、ファイアウォールを設定する。この4つが最優先だよ」
E：「rootでログインしちゃダメなんですか？」
F：「rootで直接ログインできる状態は危険すぎる。rootへの総当たり攻撃が常に来てると思っていい」

初期セキュリティ設定を順番に見ていきましょう。

# 1. 一般ユーザーの作成とsudo権限付与
adduser deploy
usermod -aG sudo deploy

# 2. 公開鍵をサーバーにコピー（ローカルから実行）
ssh-copy-id deploy@YOUR_SERVER_IP

# 3. SSHの設定変更
sudo nano /etc/ssh/sshd_config
# 以下を変更:
# PermitRootLogin no
# PasswordAuthentication no
# Port 2222  （デフォルト22から変更）

sudo systemctl restart sshd

# 4. UFW（ファイアウォール）の設定
sudo apt install ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 2222/tcp   # 変更後のSSHポート
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

# 5. fail2banのインストール（不正アクセスを自動ブロック）
sudo apt install fail2ban
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

# 攻撃状況の確認
sudo fail2ban-client status sshd

さらに自動セキュリティアップデートを有効にしておくと、既知の脆弱性に対して常に対策が施されます。

sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

VPSを借りたその日のうちにこれらの設定を終わらせる習慣をつけましょう。「後でやろう」は「絶対やらない」と同義です。30分の設定が、後の大きなトラブルを防ぎます。

「サイトが突然見えなくなった」「メールが届かない」「なぜかwwwありとなしで挙動が違う」——こういったトラブルの多くは、DNS設定の問題です。しかしDNSの仕組みを理解していないエンジニアは、原因に辿り着けないまま時間を溶かし続けます。DNSは「インターネットの電話帳」とも呼ばれますが、その仕組みを本当に理解している人は意外と少ないのが現実です。

DNSをたとえで説明すると「住所録の連鎖」のようなものです。あなたが「example.com」にアクセスしようとすると、まずOSのキャッシュを確認し、なければリゾルバ（プロバイダのDNSサーバー）に聞き、リゾルバはルートサーバー→TLDサーバー（.comを管理）→権威DNSサーバーの順に問い合わせて最終的にIPアドレスを返します。この全体の流れを「名前解決」と呼びます。

新人エンジニアC：「Aレコードを変えたのに、まだ古いIPに繋がるんですけど」
ベテランD：「TTLの値はいくつだった？」
C：「TTL？なんですか、それ」
D：「Time To Live。DNSレコードをキャッシュしておく時間のことだよ。TTLが86400（24時間）なら、変更しても24時間は古い情報がキャッシュされたまま世界中に残る。変更前にTTLを短くするのが定石だよ」

実際にDNSの動きをコマンドで確認してみましょう。

# Aレコードの確認
dig example.com A

# 権威DNSサーバーへ直接問い合わせ（キャッシュを使わない）
dig example.com A @8.8.8.8

# TTLの確認（+nocmd +noall +answer で見やすく）
dig example.com A +nocmd +noall +answer

# MXレコード（メール設定）の確認
dig example.com MX

# NSレコード（ネームサーバー）の確認
dig example.com NS

# TXTレコード（SPF/DKIM等）の確認
dig example.com TXT

よく使うDNSレコードの種類を整理しておきましょう。AレコードはドメインをIPv4アドレスに紐付けるもの、AAAAはIPv6、CNAMEは別のドメイン名へのエイリアス、MXはメール受信サーバーの指定、TXTはSPF・DKIM・サイト認証などテキスト情報の格納、NSはそのドメインの権威DNSサーバーの指定です。

「DNSの変更が反映されない」というトラブルの9割はTTLとキャッシュの問題です。変更作業の前日にTTLを300（5分）に下げておき、作業後に元の値に戻す——この手順を習慣にするだけで、DNSトラブルの大半は防げます。DNSを理解することは、インターネット上でものを動かすすべての基礎です。今日、digコマンドを打つところから始めましょう。

「ドメインを取ったけど、とりあえずレジストラのままでいいか」——そう思って放置しているエンジニアは少なくありません。しかしそれは、高性能なエンジンを積んだ車にノーマルタイヤを履かせたまま走るようなものです。ドメインを取得したら、まず最初にすべきことは「Cloudflareへの移管」です。無料で使えるのに、セキュリティ・パフォーマンス・管理性のすべてが劇的に向上します。

Cloudflareをたとえで説明すると「賢い門番兼配達員」のようなものです。あなたのサーバーへの通信を一度Cloudflareが受け取り、悪意のあるトラフィックを弾いてから届けてくれる。さらに世界中にあるCDNノードがコンテンツをキャッシュして高速に配信してくれます。しかも無料プランでこれだけのことができます。

友人A：「Cloudflareって移管が面倒くさそうで…」
エンジニアB：「実際やってみると30分もかからないよ。移管後はDNS管理がめちゃくちゃ楽になる」
A：「ネームサーバーを変えるだけ？」
B：「そう。レジストラのネームサーバーをCloudflareのものに変えるだけ。その後はCloudflareのダッシュボードでDNSをすべて管理できる」

Cloudflare CLIを使ったDNSレコード確認の例です。

npm install -g wrangler
wrangler login

# DNSレコードの一覧確認
curl -X GET "https://api.cloudflare.com/client/v4/zones/ZONE_ID/dns_records" \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Content-Type: application/json"

GUIでの移管手順：Cloudflareダッシュボードで「サイトを追加」→ドメイン入力→プラン選択（Freeで十分）→既存のDNSレコードが自動スキャン→表示されたネームサーバー2つをレジストラ側に設定→反映を待つ（最大24時間、多くは数分）。

移管後にまずやるべき設定はSSL/TLSを「Full (strict)」に変更し、「常にHTTPS使用」を有効にすることです。さらにDDoS保護・ボット管理・WAFが自動で有効になります。ドメインを持っているなら、Cloudflareへの移管は「やるかやらないか」ではなく「いつやるか」の問題です。今日やりましょう。