Webサイトや業務システムを外注していると、「開発環境」「検証環境」「本番環境」という言葉が出てきます。
環境を分ける目的は、試しに行う変更で本番の業務を止めたり、別の作業場所から重要なデータに触れたりする危険を減らすことです。ただし、サーバーやURLを分けたという説明だけでは、データやアクセス権限まで分かれているかは分かりません。
この記事では、技術担当者ではない事業者が、開発会社や保守会社に確認するときのポイントを整理します。特定の事故の原因を推定するものではありません。
開発環境・検証環境・本番環境の違い
一般的には、次のように使い分けます。会社によって呼び方や分け方は異なります。
- 開発環境： 新しい機能を作ったり、不具合を修正したりする場所。
- 検証環境： 公開する前に、変更した機能が想定どおり動くかを確かめる場所。「ステージング環境」と呼ぶ場合もあります。
- 本番環境： 実際の顧客や従業員が使うサービスの動作場所。
たとえば予約フォームを直す場合、検証環境で試せれば、実際の予約を増やしたり消したりせずに確認できます。AWSも、開発・テストに複数の環境を使い、本番に進める前に変更を確かめることを勧めています。AWSの複数環境に関するガイド
ただし、検証画面から本物の決済や通知先につながっていれば、実際の請求やメール送信が発生する可能性があります。画面の見た目だけでなく、接続先も確認が必要です。
分けて確認したいのは「場所・データ・鍵」
場所は、プログラムが動くサーバーやクラウドの管理単位です。AWSでは、開発・テストと本番を別アカウントで分ける方法を推奨しています。これはAWSでの設計例であり、すべてのサービスで同じ設定が使えるという意味ではありません。AWSの環境分離の考え方
データは、顧客情報、従業員情報、注文履歴などです。本番からコピーしたデータが検証用の場所に残っていれば、本番への侵入がなくても、そのコピーから情報が漏れる可能性があります。
鍵に当たる認証情報は、システムへの接続に使うパスワードやアクセスキーなどです。人が画面にログインするものだけでなく、プログラムが他のサービスに接続するときにも使われます。AWSの認証情報の説明
別のサーバーに移しただけで、同じ本番データと広い権限の鍵を置いていたら、守るべきものはそこにも残っています。
開発会社・保守会社に聞きたい5項目
以下は、自社の管理状況を把握するための質問例です。認証情報そのものをメールで送ってもらう必要はありません。
1. 本番以外に、実際の個人情報があるか
検証用データベースだけでなく、不具合調査で渡したCSV、画面のスクリーンショット、問い合わせ記録なども確認します。
事業者側からは、「どこに、何のために、誰の情報を保管しているか」を一覧にしてもらうと把握しやすくなります。確認用に作った架空のデータで代用できる作業はないか、必要以上の項目を渡していないかも相談しましょう。
2. 開発用の権限で、本番のどこまで触れるか
「開発環境は別です」から一歩進めて、本番の顧客情報を読めるか、変更・削除までできるかを尋ねます。
必要な作業に必要な範囲だけを許可する考え方を、最小権限と呼びます。AWSもこの原則と、使っていない権限や認証情報の見直しを勧めています。AWSの権限管理の指針
本番に触れる必要がある作業は、担当者、目的、許可する期間を決め、通常の開発作業と分けて管理しているか確認します。
3. プログラム用の鍵を、誰が管理しているか
人のログインに多要素認証を付けても、プログラム用の接続キーが同じ仕組みで守られるとは限りません。どの認証情報に、どの保護が適用されるのかを分けて確かめます。
長く使える鍵をむやみに配らず、対応するサービスでは短期間だけ有効な認証情報を使う方法があります。AWSは、可能な場合に一時的な認証情報を使うことを推奨しています。AWSの認証情報管理の指針
確認したいのは、「専用の管理場所があるか」「必要な担当者やプログラムだけが使えるか」「漏えい時に誰が止めるか」です。
4. 作業が終わった後、データと権限をどう扱うか
調査のために渡した情報が、案件終了後も残り続けていないかを確認します。保管期限、削除の担当、バックアップに残る場合の扱いを決めておくと、次の案件でも確認しやすくなります。
退職者や契約終了した委託先の権限も見直します。「担当者が変わった」だけで鍵やアクセス権が自動的に失効するとは限りません。
5. 不審な利用を検知し、対応できるか
誰がいつアクセスしたかという記録を残し、異常が分かったときの連絡先を決めます。記録にパスワードやキーそのものを残さないことも必要です。OWASPのガイドでは、認証情報の利用・変更等を監査できることや、漏えい時の失効手順を扱っています。OWASPの認証情報管理ガイド
「漏れたかもしれない」ときは、削除だけで終わらせない
認証情報が外に出た可能性がある場合、元のファイルを消すだけでは、すでにコピーされた鍵は使える状態のままかもしれません。技術担当者に速やかに連絡し、その鍵を使えなくする対応と、アクセス記録の確認を進めます。OWASPの漏えい時の対応
鍵を止めると、メール送信や外部連携などが停止する可能性もあります。事業者側は、影響を受ける業務と利用者への案内を担当者と確認してください。安全な新しい認証情報への切り替えも必要です。記録や関連ファイルを自己判断で一括削除せず、調査に必要な証拠を残しながら対応します。
まずは、管理の分担を1枚にまとめる
確認結果は、サービスごとに次の項目が分かる形で残すと実用的です。
- 本番・検証・開発それぞれの管理会社と担当者
- 本番以外に保管する実データの種類と目的
- 本番へ接続できる権限の有無と管理責任者
- 作業終了時の削除・権限見直しの方法
- 異常時の連絡先と、業務停止を判断する人
SaaSのように自社で設定を変えられない場合も、提供会社の資料や契約窓口で保守用データの扱いを確かめられます。詳しい鍵や内部構成の提出を求めるのではなく、保管範囲、アクセス制限、削除方針を説明してもらいましょう。
最初の確認は、「本番以外にも、守るべきデータや本番に入れる鍵があるか」です。その答えを管理担当者とそろえることが、外注先に任せきりにしないための出発点になります。
情報確認日：2026年11月7日。本記事は一般的な管理の考え方です。実際の構成や契約に応じた設計・設定は、担当する技術者と確認してください。