ウェブサイトを納品したあと、すぐに利用開始できないケースは、納品業務の方にとっては大きなストレス源です。
「動かないのは自分のミスなのか、相手側の環境のせいなのか…」と不安になる前に、まずは原因を整理し、どのように対処すれば再発を防げるかを把握しておくことが重要です。
この記事では、納品後にサイトが使えなくなる主な原因を順を追って解説し、現場ですぐに使える対処法と、同じ問題を防ぐための予防策をまとめました。
納品後にサイトが使えなくなる主な原因
| カテゴリ | 具体例 | トラブルシューティングのヒント |
|---|---|---|
| DNS関連 | ・ドメインが正しいサーバに向いていない ・TTLが長すぎて変更が反映されない | dig や nslookup で NS / A レコードを確認 |
| SSL証明書 | ・証明書が失効している ・証明書チェーンが不完全 | SSL Labs の診断ツールでチェーンをチェック |
| サーバ環境 | ・PHP/Node のバージョンが要件と合わない ・Webサーバの設定ミス | php -v、node -v、nginx -t 等でバージョン・設定を確認 |
| ファイル・ディレクトリパーミッション | ・実行権限が無い ・権限が過剰で読み込み不可 | chmod・chown で権限を修正 |
| データベース接続 | ・ホスト名・ユーザ・パスワードが違う ・データベースが利用不可 | mysql -h で接続テスト、phpMyAdmin で確認 |
| リソースの欠落 | ・画像・JS・CSS ファイルがアップロードされていない ・URL が間違っている | 開発環境で npm run build、grunt などでビルドを実行 |
| ビルド/デプロイ失敗 | ・CI のビルドが成功していても実際にサーバに転送されていない | git のリモート確認、FTP/SFTP のログを確認 |
| 外部API／CDN | ・APIキーが無効 ・CDN が設定ミス | API キーを再発行、CDN のオリジン設定をチェック |
| エラーログ | ・PHP の display_errors がオフでエラーを見逃している |
エラーログ (error_log) を必ず確認 |
ポイント
- 一度に全部調べようとせず、エラー内容・メッセージに沿って順序立てて検証する。
- ログはすぐに確認し、原因の絞り込みに活用する。
対処法：実際に発生した問題を素早く解決する手順
1. サーバ状態（稼働確認）
# サーバが稼働しているか確認
ssh user@hostname
# Nginx の設定チェック
sudo nginx -t
# PHP-FPM の状態確認
sudo systemctl status php-fpm
2. DNS とドメイン確認
# DNS レコードを確認
dig example.com +trace
# TTL が長すぎる場合はレコードを短く設定してもらう
3. SSL 証明書の自動化
- Let’s Encrypt を利用している場合は自動更新になっているか確認
sudo certbot renew --dry-run
4. ファイルパーミッション
# 適切な権限の一例
chmod -R 755 public
chmod -R 644 config
chown -R www-data:www-data .
5. データベース接続テスト
# MySQL なら
mysql -hホスト -uユーザー -pパス db名
# 接続できない場合は接続文字列（ホスト名・ユーザー・パスワード）を見直す
6. スタティックアセット確認
- 画像・フォント・JS の URL が実際に存在するか
# Web ブラウザの devtools で 404 を確認
7. エラーログ解析
access.log・error.logの内容を確認し、エラーメッセージを収集
tail -f /var/log/nginx/error.log
8. 環境差異の再現
- 開発環境と本番環境で同じ PHP/Node のバージョンを使用しているか
# コンテナ化（Docker）で環境を揃えるのがおすすめ
9. ロールバック
- 直前の安定したバージョンに戻せるように、Git タグやバックアップを取得しておく
git tag v1.3.2
git checkout v1.3.2
予防策：再発しないようにするためのベストプラクティス
| 項目 | 実装例 | 効果 |
|---|---|---|
| CI/CD パイプライン | GitHub Actions, GitLab CI, Jenkins | ビルド・テスト・デプロイを自動化し、手作業のミスを削減 |
| 環境構築の自動化 | Docker Compose, Vagrant | 開発・本番が同じ設定で再現可能 |
| 構成管理 | Ansible, Terraform | サーバ構成をコード化し、変更を追跡 |
| 自動テスト | Selenium, PHPUnit, Jest | 主要な機能・ビジーケースを網羅的に検証 |
| ログと監視 | Grafana + Prometheus, ELK スタック | 事前に異常を検知し、アラートで対処 |
| ドキュメント化 | Wiki, Confluence | 設定・操作手順をまとめ、次担当者へのロスを防止 |
| ロールバック計画 | ブルー/グリーンデプロイメント | 本番で問題が起きてもすぐに旧バージョンへ切替 |
| パーミッションの一元管理 | NFS, S3 + IAM | アクセス権限漏れを防止 |
| バージョン固定 | composer.lock, package.json の --save-exact |
依存パッケージの自動更新で動作変化が起きないように |
| DNS への注意 | TTL を短く、レコードを正確に | 変更を即座に反映できるように |
コツ
- 設定ミスは「誰がどこで誤った値を入力した」かを追跡できるように、変更ログを必ず残す。
- 「使えない」事象の原因が明確になったら、同じケースを想定したチェックリストを作成して次回の納品で必ず実行。
まとめ
-
原因を迅速に特定
- エラー内容をログで掴み、DNS・SSL・権限・DB などカテゴリー別にチェック。
-
標準化された対処手順を実行
- サーバ、DNS、SSL、ファイル権限・データベース接続などを一つずつ確認。
-
再発防止策を整備
- CI/CD、コンテナ化、構成管理、監視、ロールバック計画を構築し、変更マネジメントを徹底。
納品後にサイトが使えないときは、一歩踏み込んで「なぜそうなったのか」を理解し、次回以降に活かすルーチンを作ることがカギです。
「すぐに動く」ことだけでなく、「同じミスを繰り返さない」習慣を築けば、ウェブサイトの品質とクライアントの信頼度を同時に高められます。
補足
実際にサイトを納品する際は、納品物の「デプロイ手順書」と「運用マニュアル」を添付し、クライアントに共有しましょう。
さらに、納品後30日以内に「ステータス確認」をスケジュールし、問題があれば早期に対処する体制を整えると安心です。
コメント