見積もりにある「テスト・STG環境」って何?このまま発注して大丈夫?

見積もりにある「テスト・STG環境」って何?このまま発注して大丈夫?

Webサイト制作の見積もりを見ていると、「テスト環境構築」「STG環境構築」といった項目が入っていることがあります。

金額も数万円〜十数万円ほど載っていて、

「本番サイトとは別に、もうひとつサイトを作るということ?」
「確認用なら、そこまで費用をかける必要があるの?」
「これ、削っても大丈夫な項目では?」

と感じる方もいるかもしれません。

先に結論をお伝えすると、テスト環境やSTG環境は、単なる“確認用のコピーサイト”ではありません。

制作途中の確認はもちろん、公開後のアップデートや機能追加を安全に行うための場所です。今後もサイトを改善していく予定があるなら、むしろ本番サイトと同じくらい大切な基盤になることがあります。

この記事でわかること

  • テスト環境やSTG環境は、単なる確認用のコピーサイトではなく、制作途中の確認やアップデート・機能追加の安全な場所。
  • テスト環境は、本番環境とは別で新しいページや機能を確認する場所。STGは本番公開前の最終確認用。
  • テスト環境の重要性は、本番での修正作業がユーザーに被害を及ぼす可能性を考えた場所である。
  • テスト環境は公開前の確認だけでなく、公開後の保守や運用にも利用される。アップデートの影響を確認し、ユーザーに影響を及ぼさず調査可能。
  • テスト環境がないと、サイトの拡張や改善が困難になる可能性がある。将来的な変更を安心して行うために重要。
  • 見積もりの環境構築費は、単なる確認用ページ作成費用ではなく、安全な作業・確認・公開のための仕組みに対する費用。

そもそも、本番環境と何が違うのか

普段、ユーザーが見ているWebサイトが「本番環境」です。検索結果や広告、SNSなどからアクセスされる、実際に公開されているサイトを指します。

一方、テスト環境は、新しく作ったページや機能を確認するための場所です。

例えば、

  • お問い合わせフォームが正しく送信されるか
  • スマートフォンで表示が崩れていないか
  • 管理画面から問題なく更新できるか
  • 新しい機能を追加したことで、既存機能に影響が出ていないか

といったことを、本番サイトとは別の場所で確認します。

STGは「ステージング」の略で、本番公開前の最終確認に使う環境です。本番とできるだけ近いサーバー構成や設定を用意し、「このまま公開しても問題がないか」を確認します。

ただし、制作会社によって呼び方はまちまちです。

「テスト環境」と「STG環境」を分けている会社もあれば、ひとつの環境を兼用している会社もあります。そのため、見積書の名称だけを見ても、実際にどんな用途で使うのかまでは分かりません。

発注前に確認したいのは、環境の名前ではなく、

  • 誰が
  • どの段階で
  • 何を確認するための環境なのか

という点です。

なぜ本番サイトで直接作業してはいけないのか

小さな修正であれば、「そのまま本番で直してしまえば早いのでは」と思うかもしれません。実際、本番環境で直接作業が行われるケースはあります。

ただし、本番での直接作業には、常に「修正途中の状態や不具合が、そのままユーザーに見える可能性」があります。

例えば、フォームの修正中に送信できない時間が発生したり、ページのレイアウトが一時的に崩れたり、更新したプログラムが既存機能と干渉してエラーになったりすることがあります。

企業サイトでフォームが使えなくなれば、その間の問い合わせを取りこぼすかもしれません。

ECサイトであれば、商品を購入できない時間が発生する可能性もあります。会員サイトであれば、ログインできない、登録情報を変更できないといった問題につながります。

テスト環境は、「きれいに作るため」のものというより、こうした事故を本番で起こさないためのものです。

テスト環境は、サイトを作るときだけ使うものではない

ここは、発注時にはあまり意識されていないポイントかもしれませんが、テスト環境が必要になるのは、サイトを新しく作るときだけではありません。

Webサイトは、公開後もさまざまなソフトウェアの上で動き続けます。

WordPressを使用していれば、WordPress本体やテーマ、プラグインのアップデートがあります。サーバー側では、PHPなどのプログラムやセキュリティ設定が更新されることもあります。

外部サービスと連携している場合は、そのサービス側の仕様変更によって、これまで通り動かなくなることもあります。アップデート自体は、セキュリティを保つために必要です。

ただ、アップデートした結果、

  • 画面が真っ白になった
  • 問い合わせフォームが送れなくなった
  • 管理画面の表示が変わった
  • 今まで使えていた編集機能が使えなくなった
  • 別のプラグインと競合してエラーが出た
  • 担当者が従来通り操作できなくなった

といったことは、決して珍しくありません。

本番環境しかなければ、そこでアップデートを行い、問題が起きてから戻すことになります。

テスト環境があれば、先にアップデートを試し、問題がないことを確認してから本番へ反映できます。何か不具合が起きても、ユーザーが利用しているサイトには影響を出さずに調査できます。

つまり、テスト環境は公開前の確認場所であると同時に、公開後の保守や運用にも使う場所です。

テスト環境がないサイトは、拡張しないことと同義かもしれない

テスト環境がないからといって、すぐにサイトが運用できなくなるわけではありません。

数ページだけの小規模なサイトで、公開後の更新もほとんどなく、問い合わせフォームのような機能もない場合は、費用とのバランスを考えて環境を分けない判断もあり得ます。

ただ、今後も継続的にサイトを改善していくつもりなら、話は変わります。

例えば、

  • フォームの入力項目を見直したい
  • 新しいサービスページを追加したい
  • 資料ダウンロード機能を追加したい
  • 会員機能を導入したい
  • CRMや外部サービスと連携したい
  • デザインや導線を改善したい

といった変更を行うとき、確認できる場所がなければ、すべて本番環境に直接手を入れることになります。すると、変更内容そのものよりも「何か壊れないか」が優先されるようになります。

本来であれば事業やユーザーの変化に合わせて育てていくはずのサイトが、次第に「触ると怖いから現状維持」という状態になっていきます。

そう考えると、現代のWebサイトにおいて、テスト環境がないことは、将来的な拡張や改善を前提にしていないことと、ほとんど同じ意味を持つ場合があります。

テスト環境は、今のサイトを完成させるためだけのものではありません。これから先、安心して変更できる状態を作っておくためのものです。

見積もりの「環境構築費」は、何に対する費用なのか

テスト環境やSTG環境は、本番サイトを複製すれば終わり、というものでもありません。

案件によっては、次のような作業が必要になります。

  • サーバーやデータベースの準備
  • WordPressやプログラムの設定
  • 本番に近い構成の再現
  • 関係者以外が見られないようにするアクセス制限
  • 検索結果に出ないようにする設定
  • テスト用データや個人情報の取り扱い
  • テスト環境から本番へ反映する手順の整理
  • 環境ごとのURLや外部サービス接続先の切り替え

本番環境との差が大きいと、「テストでは動いたのに、本番では動かない」ということも起こります。

そのため、本番に近い状態をどこまで再現するかによって、構築に必要な作業や費用も変わります。

見積書に環境構築費が入っている場合は、単に確認用ページを作る費用ではなく、安全に作業し、確認し、公開するための仕組みに対する費用と考えた方がよいでしょう。

このまま発注していいのか迷ったら

「テスト環境」「STG環境」と書かれているだけでは、その費用が妥当かどうかは判断できません。

発注前に、少なくとも次の点は確認しておくと安心です。

  • 制作中、発注者もその環境を確認できるのか
  • 本番環境とどこまで同じ構成なのか
  • テスト環境とSTG環境を分けるのか、兼用するのか
  • 公開後もその環境は残るのか
  • 保守やアップデートの際にも使用するのか
  • 本番反映は誰が行うのか
  • 公開後にサーバー費用や維持費が発生するのか

反対に、見積もりにテスト環境が含まれていない場合も、すぐに問題だと決めつける必要はありません。

ただし、

「制作中の確認はどこで行いますか」
「公開後のアップデートは、どの環境で検証しますか」
「不具合が起きた場合、どのように本番を元に戻しますか」

と確認しておいた方がよいでしょう。

大切なのは、環境が何個あるかではなく、本番サイトに影響を出さずに確認できる手順が用意されているかどうかです。

テスト環境は、削れる費用ではなく、判断して持つもの

見積書にある「テスト環境」「STG環境」は、発注者から見ると用途が分かりにくく、削減候補に見えやすい項目です。

ただ、その環境を省略すると、制作中だけでなく、公開後のアップデートや機能追加も本番環境で直接行うことになります。

サイトを一度作って終わりにするのか。
今後も改善し、事業に合わせて育てていくのか。

その方針によって、必要な環境は変わります。

もし見積書に環境構築費が含まれていたら、「高いから削る」「書いてあるからそのまま発注する」のではなく、何のために用意され、公開後にどう使われるのかまで確認してみてください。

その説明を聞くことで、制作会社がサイトの公開だけをゴールにしているのか、その後の運用や改善まで見据えているのかも見えてくるはずです。

Mimu Fujiwara

フリーランスのテクニカルPM/Webディレクター。 Webサイトのリニューアルや改善の相談を受ける中で、「本当に解決したいこと」と「依頼内容」が少しずれている場面によく出会います。 依頼されたものをそのまま作る前に、目的や課題、運用状況を整理し、「何を作るべきか」から一緒に考える立場で関わっています。 WordPressやHubSpotなどのCMS案件を中心に、要件整理・情報設計・技術調整・運用改善までを横断して支援。公開して終わりではなく、その後も無理なく運用・改善できる状態をつくることを大切にしています。