このユニットの結論
システムは、作る場所（開発）、確かめる場所（テスト）、実際の業務で使う場所（本番）を分けて動かします。
本番で試さない、本番で直接直さない、変更は同じ順番で環境を通してから本番へ出す。環境を分けるのは、業務と本番のデータを守り、何を本番に出したかを説明できるようにするためです。
1. 何の話か
このユニットは、環境の分け方の話です。
ここでいう環境とは、システムが動いている場所（サーバーや設定、データ、接続先のまとまり）のことです。一般的には、次のように分けます。
| 環境 | 役割 | 使う人（一般的な例） |
|---|---|---|
| 開発環境 | プログラムを作り、試す | 開発の担当 |
| テスト環境 | 決めた手順で、変更を確かめる | テストの担当、業務の担当 |
| 本番前の確認環境 | 本番にできるだけ近い条件で、最後に確かめる | テスト・運用の担当 |
| 本番環境 | 実際の業務で使う | 利用者、運用の担当 |
環境の数と名前はプロジェクトによって異なります。本番前の確認環境（ステージングと呼ぶことがあります）を置かない場合もあります。
2. なぜ必要か
環境を分けないと、
- 作りかけのプログラムが、業務の画面に出てしまう
- 試しに動かした処理で、本番のデータが変わる
- 本番で直接直した内容が、開発の側に残らず、次の変更で元に戻る
- 何を、いつ本番に出したかを説明できない
ということが起きます。経理にたとえると、下書きの伝票と、承認済みの正式な伝票を、同じ綴りに混ぜて保管している状態です。
3. このユニットで分かること
- 環境を分ける目的
- 環境の間で違ってよいもの・そろえるもの
- 本番へ変更を出す順番
- 環境の使い方で、AIに任せてよいことと人間が決めること
4. 環境を分ける目的
- 業務を守る：試す・壊す・やり直すのは、本番の外で行う
- データを守る：本番のデータは本番の中で扱う。開発・テストで使うデータの扱いは 08-05 開発者は本番データを自由に見てよいのか で学びました
- 確かめた結果を信じられるようにする：テスト環境で確かめた変更と、本番に出す変更が同じであること
- 説明できるようにする：どの変更を、いつ、誰の承認で本番に出したかを残す
5. 違ってよいもの・そろえるもの
| 区分 | 例（一般的な例） |
|---|---|
| そろえるもの | プログラムの版、設定の項目、処理の手順 |
| 違ってよいが、管理するもの | データ（本番のデータをそのまま使わない）、つなぎ先（テスト用の相手先）、利用者 |
| 違いを記録するもの | 規模（サーバーの数や性能）、つなぎ先の一部が用意できない場合 |
特につなぎ先に注意します。テスト環境の処理が、本番の相手のシステムや取引先につながっていると、テストのデータが本物として届いてしまいます。
6. 本番へ出す順番
一般的には、同じ変更を「開発 → テスト → 本番前の確認 → 本番」の順に通し、前の環境で確かめてから次へ進めます。
- 本番に出すのは、テスト環境で確かめたものと同じ版にする
- 本番で直接直さない。急ぎでも、手順を短くした緊急の手順を事前に決めておく
- 本番への反映は、決められた人が、承認を得てから行う
自動でテストし、自動で配布する仕組みは 09-04 自動テストと自動配布 のテーマです。
CASE FACTFROZEN正本に記載されたアステリア案件の事実
アステリア案件に関係する記載
- システムに SYS-09 開発・CI/CD基盤、SYS-10 AI開発エージェントがある
- Vendor B / クラウドブリッジ — クラウド基盤、ネットワーク、IAM、連携、CI/CD、監視
- AIによる本番直接変更は禁止（正本の危機演習 CR11 の項に記載）
- AIへ最終委任しないことに「本番移行承認」がある
- 成果物に DEV-004 環境・リリース対応表がある
アステリア案件の環境の数と名前、環境ごとの使い方、本番へ反映する手順と承認者は、正本に記載がありません。未確定
7. THINK — 「本番で1行直せば早い」
本番で、画面の表示に小さな誤りが見つかりました。開発の担当者が言いました。
「本番のサーバーで1行直せばすぐ終わります。開発の環境には、あとで同じ修正を入れておきます。」
問題
この進め方でよいでしょうか。
判断例を開く
判断
このままではよくありません。
確認すること:
- 急ぎの修正のための手順（誰が承認し、どう確かめ、どう記録するか）は決まっているか
- 「あとで同じ修正を入れる」を忘れると、次の変更を本番に出したときに、誤りが元に戻らないか
- 本番で直接直した内容を、誰が確かめるか
- その修正は、本当に今すぐ必要か。通常の順番で出せないか
本番で直接直すと、環境の間で中身がずれ、「テストで確かめたものを本番に出す」という前提が崩れます。
8. よくある失敗
- テスト環境のつなぎ先が、本番の相手のシステムのままになっている
- テスト環境と本番で設定が違い、本番で初めて動かない
- 本番で直接直し、開発の側に反映し忘れる
- テスト環境で確かめた版と、本番に出した版が違う
- 環境ごとの違いを、誰も一覧で把握していない
9. 成果物との接続
- DEV-004 環境・リリース対応表：環境ごとの役割・違い・本番へ反映する手順を1つの表にまとめる
- SEC-003 本番特権アクセス管理表：本番に直接触れる強い権限を、誰がいつ使ったかを管理する
- AI-002 AIエージェント権限表：AIが、どの環境で何をしてよいかを決める
AIに渡す権限の考え方は 09-06 AIにどこまで権限を渡すか で学びます。
10. AI WORKFLOW — 環境の設定の違いを洗い出させる
AIは、環境ごとの設定を比べる下書きに役立ちます。
指示例:
「次のテスト環境と本番環境の設定の一覧を比べ、①値が違う項目、②片方にしかない項目、③つなぎ先が本番の相手になっているテスト環境の項目、を表にしてください。違いが問題かどうかは判断しないでください。」
11. REVIEW — AIの比較を確認する
- 表の値が、元の設定と合っているか
- 違いのそれぞれが、意図した違いかを担当が確かめたか
- 設定の一覧に、パスワードなどの秘密の情報が含まれていないか（AIに渡す前に確かめる）
12. 人間が判断すること
- 環境をいくつ、どう分けるか
- 環境の間の違いを受け入れるか
- 本番へ反映してよいか。急ぎの修正の手順を使うか
本番移行承認は、AIへ最終委任しない事項です（正本の方針）。稼働後の個々のリリースの承認をどう扱うかは、正本に記載がありません。未確定
13. 判断演習
あなたは、テスト環境を準備する担当です。
テスト環境の処理が、本番の相手のシステムや取引先に誤って届かないようにするために、準備のときに確かめることを3つ挙げてください。
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
開発・テスト・本番を分けるのは、業務とデータを守り、確かめたものだけを本番に出すためです。
本番で試さない、本番で直接直さない。環境の違いは一覧で管理します。