サーバー移転前に必須！「依存関係マップ」の作り方

サーバー移転の失敗は「見えない依存関係」から始まります。移転前に必ず作るべき依存関係マップの作り方を、実案件ベースで解説します。

こんな悩み、ありませんか？

「サーバーを移転したら、突然メールが届かなくなった」「本番環境に移したら決済が動かない」「APIの外部連携が全部切れた」——。サーバー移転のプロジェクトで、こういった声を聞くことは珍しくありません。

移転作業そのものは完璧だったのに、誰も把握していない「隠れた依存関係」が原因で、本番公開直後に障害が発生する。これがサーバー移転における最も典型的な失敗パターンです。

この記事では、Fivenine Designが実際の案件で活用している「依存関係マップ」の作り方を、具体的な手順とともに解説します。移転作業を始める前にこのマップを完成させておくだけで、トラブルの8割は未然に防げます。

なぜ「依存関係の見落とし」が起きるのか

多くの現場では、サーバー移転の計画時に「ファイルとDBを移せば完了」と認識されがちです。しかし現代のWebシステムは、驚くほど多くの外部サービス・設定・環境変数に依存して動作しています。

特に問題になりやすいのが、以下のような暗黙知として運用されてきた設定群です。

• .env に書かれた外部APIキー（決済、SMS、メール配信など）
• サーバーの /etc/hosts や DNS に依存したドメイン解決
• cron で動いているバッチ処理
• sendmail や postfix のメール送信設定
• IP制限がかかった外部APIへのアクセス（旧サーバーのIPが許可リストに入っている）
• ファイルパスのハードコード（例：/var/www/html/uploads）

あるクライアントでは、移転後に「注文完了メールが届かない」という問題が発生しました。原因を調査すると、決済代行会社のIPホワイトリストに旧サーバーのIPアドレスしか登録されておらず、新サーバーからのアクセスがブロックされていたのです。このような依存関係は、コードを読むだけでは発見できません。「何が何に依存しているか」を事前に可視化することが、移転成功の鍵を握ります。

依存関係マップの作り方：4つのステップ

STEP 1：システムの「入口」と「出口」を洗い出す

まず、システムへのリクエストの入口（インバウンド）と、システムから外部への接続（アウトバウンド）を列挙します。

flowchart LR
    A[ユーザー] -->|HTTPS| B[Webサーバー]
    C[外部決済API] -->|Webhook| B
    D[管理者] -->|SSH| B
    B -->|SMTP| E[メールサーバー]
    B -->|API call| F[Stripe / PAY.JP]
    B -->|API call| G[SendGrid / Mailgun]
    B -->|DB接続| H[(MySQL / PostgreSQL)]
    B -->|cron| I[バッチ処理]
    I -->|ファイル出力| J[ストレージ / S3]

このような図を最初に描くだけで、チーム全員が「このシステムがどこに繋がっているか」を共有できます。

STEP 2：.env と設定ファイルを棚卸しする

依存関係の多くは .env ファイルや設定ファイルに隠れています。以下のコマンドで、現在の環境変数と設定を一括確認しましょう。

# .envファイルの内容を確認（機密情報のため取り扱いに注意）
cat .env | grep -v '^#' | grep -v '^$'

# cronの登録内容を確認
crontab -l

# Apacheのバーチャルホスト設定を確認
apachectl -S

# Nginxの設定を確認
nginx -T 2>/dev/null | grep -E 'server_name|listen|root'

# 外部への通信を確認（どのIPに接続しているか）
ss -tnp | grep ESTABLISHED

// config/services.php の依存サービスを確認
// 以下のようなサービス定義が依存関係のヒントになる

return [
    'mailgun' => [
        'domain' => env('MAILGUN_DOMAIN'),
        'secret' => env('MAILGUN_SECRET'),
        'endpoint' => env('MAILGUN_ENDPOINT', 'api.mailgun.net'),
    ],
    'stripe' => [
        'key' => env('STRIPE_KEY'),
        'secret' => env('STRIPE_SECRET'),
        'webhook' => [
            'secret' => env('STRIPE_WEBHOOK_SECRET'),
        ],
    ],
];

// .envで使われているキーを全て抽出するコマンド
// php artisan env（本番では使用注意）

STEP 3：依存関係チェックシートに記録する

洗い出した情報を、以下の形式で一元管理します。スプレッドシートでもNotionでも構いませんが、必ずチームで共有できる場所に置いてください。

STEP 4：移転後の動作確認スクリプトを用意する

依存関係マップが完成したら、それをそのまま「チェック用スクリプト」に変換します。移転後に手動で確認するのは漏れが発生しやすいため、スクリプト化しておくことを強く推奨します。

#!/bin/bash
# dependency_check.sh - 移転後の依存関係確認スクリプト

echo "=== 依存関係チェック開始 ==="

# 1. データベース接続確認
echo "[DB] 接続確認..."
php artisan db:show --only=connection 2>&1 | grep -q 'Successfully' && echo "✓ DB接続OK" || echo "✗ DB接続NG"

# 2. メール送信テスト（SendGrid）
echo "[MAIL] SendGrid到達確認..."
curl -s -o /dev/null -w "%{http_code}" \
  -X POST https://api.sendgrid.com/v3/mail/send \
  -H "Authorization: Bearer ${SENDGRID_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{"from":{"email":"[email protected]"},"subject":"test","content":[{"type":"text/plain","value":"test"}],"personalizations":[{"to":[{"email":"[email protected]"}]}]}' \
  | grep -q '202' && echo "✓ メールAPI接続OK" || echo "✗ メールAPI接続NG"

# 3. Stripe Webhook疎通確認
echo "[STRIPE] Webhook URLの確認..."
STRIPE_WEBHOOK_URL="https://$(hostname -f)/webhook/stripe"
curl -s -o /dev/null -w "%{http_code}" "${STRIPE_WEBHOOK_URL}" | grep -q '405\|200' \
  && echo "✓ Webhook URL到達OK" || echo "✗ Webhook URL到達NG"

# 4. cronの登録確認
echo "[CRON] スケジュール設定確認..."
crontab -l | grep -q 'artisan schedule:run' && echo "✓ cronジョブ登録済み" || echo "✗ cronジョブ未登録"

echo "=== チェック完了 ==="

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

実際の案件で遭遇した、移転失敗の代表的なパターンを紹介します。

❌ 失敗1：「.envをコピーすれば完了」と思い込む

.env ファイルをそのままコピーしても、IPアドレスに紐づいた権限設定は引き継げません。特に決済代行サービスや社内DBへのVPN接続は、IPホワイトリストの更新申請を移転完了前に行う必要があります。申請には数日かかるケースも多く、移転スケジュールに組み込んでおくことが必須です。

❌ 失敗2：ステージング環境で確認して「大丈夫」と判断する

ステージング環境では外部APIをモックやサンドボックスに向けていることが多く、本番移転後に実際のAPIキーで動かすと挙動が変わるケースがあります。本番キーを使った最終確認を、切り替え前の旧サーバーで一度行うのがベストプラクティスです。

❌ 失敗3：WordPressのサイトURLを更新し忘れる

WordPressはDBに siteurl と home を保持しています。移転後にこれを更新しないと、管理画面が旧ドメインにリダイレクトされ続けます。

-- WordPressのURL設定を更新
UPDATE wp_options 
SET option_value = 'https://new-domain.example.com' 
WHERE option_name IN ('siteurl', 'home');

-- コンテンツ内の旧URLも一括置換
UPDATE wp_posts 
SET post_content = REPLACE(
  post_content,
  'https://old-domain.example.com',
  'https://new-domain.example.com'
);

❌ 失敗4：SSL証明書の自動更新設定を忘れる

Let's Encryptで証明書を取得した場合、certbot renew の自動更新がcronに登録されているか確認しましょう。移転直後は証明書が有効でも、90日後に切れてサイトがHTTPS接続不可になる事例が後を絶ちません。

まとめと次のステップ

サーバー移転の成功率を高めるのは、技術力よりも事前の情報整理です。依存関係マップは一度作れば次回の移転でも再利用でき、属人化の解消にも繋がります。

移転作業の目安となるタイムラインは以下の通りです。

依存関係の洗い出しは「やれば必ずできる」作業ですが、普段の業務と並行しながら網羅的に行うのは、思いのほか時間と手間がかかります。「移転スケジュールが迫っているが依存関係の整理が追いつかない」「何が繋がっているか把握できていない」という状況でご相談いただくケースが、Fivenine Designには少なくありません。

移転計画の初期段階からご相談いただければ、依存関係マップの作成から移転後の動作確認まで、一貫してサポートします。まずは現状のシステム構成をお聞かせください。