サーバー移転したらメール・決済・API連携がすべて止まった！移転前に確認する依存関係チェックリスト

サーバー移転後に「メールが届かない」「決済できない」「外部連携が壊れた」は典型的な失敗パターン。移転前に確認すべき依存関係と具体的なチェック手順を解説します。

こんな経験、ありませんか？

サーバー移転が完了した翌朝、問い合わせフォームからのメールが届いていない——そんな連絡が担当者から入ってくる。確認してみると、決済もエラーになっており、在庫連携しているAPI側のシステムも止まっている。「移転は終わったはずなのに、なぜ？」

これは実際に私たちが過去に対応した案件で起きたことです。リニューアルに合わせてホスティングをさくらインターネットからAWSへ移行した神奈川県内の小売業のクライアントで、移転直後からStripeの決済処理が軒並み失敗し、受注メールも届かない状態が約6時間続きました。原因は複数のサービスに旧サーバーのIPやドメイン設定が紐付いたままだったことです。

サーバー移転は「ファイルを移してDBを移せば終わり」ではありません。現代のWebサービスは外部SaaSや決済プロバイダー、メール配信サービス、CDN、認証サービスなど無数の依存関係を持っています。移転作業そのものより、この依存関係の棚卸しこそが最大の難所です。

なぜ移転後に連携が壊れるのか——依存関係の落とし穴

サーバー移転で発生するトラブルの多くは、「新しい環境に変わった」という情報が外部サービス側に伝わっていないことに起因します。具体的には以下の3つの構造的な問題があります。

1. IPアドレスのホワイトリスト問題

Stripe・PAY.JP・GMOペイメントなどの決済APIや、外部の在庫管理・CRMシステムは、セキュリティ上の理由から接続元IPアドレスを制限していることがあります。旧サーバーのIPはホワイトリストに登録されていたが、新サーバーのIPは未登録——これが即座に決済停止につながります。

2. Webhookエンドポイントの固定登録

StripeやPayPalは、決済完了などのイベントをWebhookで通知します。このエンドポイントURL（例：https://example.com/webhook/stripe）はサービス側のダッシュボードに手動で登録されています。DNSが切り替わる前のサーバーを指したままになっているケースも珍しくありません。

3. メール送信元の認証設定（SPF/DKIM/DMARC）

メールの到達率を担保するSPF・DKIMレコードは、DNSのTXTレコードとして設定されています。旧サーバーのIPがSPFレコードに書かれていた場合、新サーバーから送信するとスパム判定され、受信トレイに届かなくなります。

flowchart TD
    A[サーバー移転完了] --> B{外部サービスへの通知}
    B -->|未対応| C[IPホワイトリスト 旧IP登録のまま]
    B -->|未対応| D[Webhook URL 旧エンドポイントのまま]
    B -->|未対応| E[SPFレコード 旧IPのまま]
    C --> F[決済API接続エラー]
    D --> G[決済完了通知が届かない]
    E --> H[メール未達・スパム判定]
    F --> I[サービス停止・売上損失]
    G --> I
    H --> I

サーバー・インフラでお困りですか？

障害対応・移行・パフォーマンスチューニングなど、ご相談ください

無料で相談する

移転前に実施すべき依存関係チェック——具体的な手順

Step 1：依存サービスの完全リスト作成

まずアプリケーションが連携しているすべての外部サービスを書き出します。.envファイルと設定ファイルが最も確実なソースです。

# .envファイルからAPI系の設定を一括抽出
grep -E '(API_KEY|SECRET|WEBHOOK|SMTP|SENDGRID|STRIPE|SLACK)' .env

# 設定ファイル内の外部URL参照を検索
grep -rn 'https://' config/ --include='*.php' | grep -v '#'

# wp-config.phpと有効化プラグインの外部接続を確認
grep -E '(API|SECRET|KEY|TOKEN)' wp-config.php

# アクティブなプラグイン一覧を取得（wp-cli使用）
wp plugin list --status=active --fields=name,version

この作業で出てくるサービス名をすべてリスト化します。典型的な中規模ECサイトであれば、以下のようなサービスが絡んでいることがほとんどです。

Step 2：新サーバーIPの事前確認とホワイトリスト申請

移転先サーバーのIPアドレスを移転作業の1〜2週間前に確認し、各サービスのダッシュボードで申請を済ませておきます。

# 新サーバーのグローバルIPを確認
curl -s https://checkip.amazonaws.com
# または
dig +short myip.opendns.com @resolver1.opendns.com

取得したIPをもとに、以下の作業を事前に実施します。

Stripe / PAY.JP：ダッシュボードの「開発者設定」でIPホワイトリストを更新
外部API（在庫・CRM連携など）：連携先ベンダーにIP変更をメールで申請（審査に数日かかることも）
社内システム連携：VPN・セキュリティグループのアクセス許可ルールを更新

Step 3：DNS切り替え前にWebhookエンドポイントを更新

Stripeを例にすると、Webhookエンドポイントの登録はダッシュボードから行います。移転後も同一ドメインを使用する場合は問題ないように見えますが、切り替え直後のDNS伝播中に旧サーバーへ届いてしまうケースがあります。対策として、StripeダッシュボードでテストWebhookを手動送信して疎通確認を行うことを必ず実施してください。

# Stripe CLIで新環境へのWebhook疎通テスト
stripe webhook-endpoints list
stripe events resend evt_xxxxxxxxxxxxxxxxx

# Webhookの署名検証（Laravel側）
// app/Http/Controllers/StripeWebhookController.php
$payload = $request->getContent();
$sigHeader = $request->header('Stripe-Signature');
try {
    $event = \Stripe\Webhook::constructEvent(
        $payload, $sigHeader, config('services.stripe.webhook_secret')
    );
} catch (\Stripe\Exception\SignatureVerificationException $e) {
    return response()->json(['error' => 'Invalid signature'], 400);
}

Step 4：メール認証設定（SPF/DKIM）の更新

新サーバーのIPを含むSPFレコードへの更新と、DKIMの再設定はDNS切り替えと同タイミングで行います。SendGridやAmazon SESを使っている場合は、送信ドメイン認証の設定を再確認してください。

# SPFレコードの確認（移転後）
dig TXT example.com | grep spf

# 期待される出力例（新サーバーIP 203.0.113.10 を含む）
# "v=spf1 ip4:203.0.113.10 include:sendgrid.net ~all"

# DKIMの確認
dig TXT default._domainkey.example.com

よくある失敗パターンと対処法

失敗①「.envを新サーバーにコピーしたから大丈夫」

最もよくある思い込みです。.envのコピーでAPIキーは移せますが、サービス側のIP制限やWebhook設定は変わりません。アプリ側の設定と外部サービス側の設定、両方を同期させる必要があります。

失敗②「TTLを短くせずにDNSを切り替えた」

DNSのTTL（キャッシュ保持時間）をデフォルト（86400秒＝24時間）のまま切り替えると、一部のユーザーが旧サーバーへ長時間アクセスし続けます。移転の3〜7日前からTTLを300秒（5分）程度に短縮しておくのが定石です。

# TTL確認
dig A example.com | grep -A1 'ANSWER SECTION'
# 移転前はTTLを300に変更しておく

失敗③「SSL証明書の再発行を忘れた」

新サーバーで独自SSL証明書を使っている場合、移転後に証明書が旧環境のものを参照していたり、Let's Encryptの自動更新設定が引き継がれていないケースがあります。移転後は必ず https:// でのアクセスと証明書の有効期限を確認してください。

失敗④「本番環境で直接切り替えた」

ステージング環境で十分にテストせず、本番のDNSを切り替えた後に問題が発覚するパターンです。/etc/hostsにエントリを追加して新サーバーを擬似的に本番として確認する方法が有効です。

# /etc/hosts に追記して新サーバーを事前テスト（Mac/Linux）
# 203.0.113.10  example.com
sudo echo "203.0.113.10 example.com" >> /etc/hosts

# 確認後は必ず削除
sudo sed -i '' '/example.com/d' /etc/hosts

サーバー・インフラでお困りですか？

障害対応・移行・パフォーマンスチューニングなど、ご相談ください

無料で相談する

サーバー管理、丸ごとお任せください

サーバー保守・運用

監視・障害対応・パフォーマンス改善まで、安定稼働をサポートします

200件以上の制作実績顧客満足度97% 初回相談無料

サービス詳細 30秒で送信 — 無料で相談する

※ 通常1営業日以内にご返信します

まとめと次のステップ

サーバー移転は「インフラ作業」ではなく「サービス全体の依存関係を整理する作業」です。コードやDBを正しく移せても、外部連携の設定が一つ抜け落ちるだけで、メール・決済・API連携のすべてが止まります。特に決済停止は直接的な売上損失につながるため、移転前の依存関係チェックは徹底して行ってください。

私たちが実案件で構築した移転前チェックリストを以下にまとめます。印刷して壁に貼ることをおすすめします。