用語集は行

本番環境

実際に一般のユーザーや顧客がアクセスする、公開用のサーバー・サイト環境のことです(「プロダクション」「Prod」とも)。検索エンジンにインデックスされ、広告や解析の計測タグが発火し、売上や問い合わせ(CV(コンバージョン))が生まれる「企業の生命線」であり、Web 運用において最も慎重に取り扱うべき聖域です。検証用の「ステージング環境」や、開発者のパソコン内の「ローカル開発環境」と対比されます。

運用の鉄則:ステージング経由の徹底と「先祖返り」の防止

修正や機能追加を行う際は、必ず本番とほぼ同じ条件で作られた「ステージング環境」でテストと公開前確認を行い、問題がないことを確認してから本番環境へ反映します。

絶対にやってはいけないのが「本番環境への直接編集(ファイル書き換え)」です。「これくらいなら大丈夫」と本番環境を直接いじってしまうと、プログラムの履歴を管理するシステム(Git)との間で致命的なズレ(不整合)が発生します。その結果、次に制作会社が正しい手順でデータを更新した際に、過去の古いデータで上書きされて最新の修正が消滅する「データの先祖返り」を引き起こし、元に戻せない(ロールバック不能)連鎖事故に発展します。

実務における重要チェックリスト(運用の論点)

  • アクセス権限の最小化:サーバーへ接続する鍵(SSH キー)や CMS の管理画面情報は、限られた人だけに「最小限の権限」で発行し、適切に管理する。
  • バックアップと保守:万が一のサーバーダウンに備え、定期的に自動でシステム全体を丸ごと保存する「スナップショット(週次などのバックアップ)」を設定する。また、SSL(SSL / TLS) 証明書の自動更新監視や、OS・PHP などの定期的なセキュリティパッチ更新を怠らない。
  • タグの切り分け:Google アナリティクス(GA4)などの計測タグは、テストデータが混ざらないよう「本番用」と「ステージング用」で必ず別の ID を発行して設定する。

現場で担当者が絶対に回避すべき「致命的な落とし穴」

  • 業者の「金曜夕方の本番反映(フライデーリリース)」の承認:制作会社から「今週の作業が終わったので金曜の 18 時に本番反映します」と一方的に通知され、深く考えずに許可してしまうのは大 NG です。土日に不具合が発覚しても連絡がつかず、週末の間ずっとサイトが壊れたまま大炎上するリスクがあるため、リリースは「平日の午前中」など、トラブル対応ができる時間帯を指定してください。
  • 「業者の倒産・契約終了」による締め出し:ドメインやサーバーの本番アクセス権限(マスター権限)を制作会社が所有したままになっていると、契約終了時のトラブルや業者の突然の倒産によって、自社のサイトなのに一切操作できなくなる悪夢が起こります。契約時に必ず所有権を自社に移管させましょう。
  • 「AI ツール」による本番情報の漏洩:近年急増している罠です。ソースコード自動生成 AI や AI エージェントの利便性に負け、本番サーバーの生パスワードや API キーを AI に入力して処理させると、その情報が AI に学習されて世界中に漏洩する深刻なセキュリティ侵害につながります。

言葉をよく利用する人

  • インフラエンジニア
  • 情シス
  • コーダー / フロントエンドエンジニア
  • Web 担当者(発注側)
  • ディレクター

会話上での使用例

本番への直接編集が起きていてディレクターに相談する場面

  • Web 担当者
    社員がちょっとした修正のつもりで、本番環境を直接いじってしまっているんです。
  • ディレクター
    それは原則禁止にしましょう。本番を直接触ると Git との食い違いの温床になります。修正は必ずステージングを経て、Git に通してから本番へ、というルールを社内と業者に共有してください。アクセス権限の見直しも合わせてやっておきたいですね。

本番のアクセス権限が広すぎると情シスから指摘される場面

  • 情シス
    本番環境のアクセス権限ですが、今 4 名がフルアクセスできる状態です。
  • Web 担当者
    最小権限の原則で整理しましょう。デプロイの実行権限は業者の PM とうちの担当者の 2 名だけにして、ほかは読み取りのみに。アクセスログは月次で情シスさんにレビューしてもらう運用にしたいです。

関連 Lesson(本書本文)

Lesson 8-1 公開直前の最終確認