これは何か
環境・配置構成図は、システムを構成する部品（アプリケーション、データベース、連携の仕組み、認証、監視など）が、どの環境（開発・テスト・本番）の、どの場所（クラウドの区画、ネットワークの区分、データセンター）で、何台で動くかを描いた成果物です。
ARC-001 システム全体構成図 が「どのシステムが何を担当し、どうつながるか」の論理の絵なら、この図は「それが実際にどこで、どう動くか」の物理の絵です。障害のとき、性能の問題のとき、環境を増やすとき、必ずこの図に戻ります。
なぜ作るか
- 開発・テスト・本番の環境が、同じ形で作られているか（違いはどこか）を見えるようにする（09-03 開発・テスト・本番をなぜ分けるのか）
- 何が止まると何に影響するか（単一障害点）を、設計の段階で見つける
- どこに何のデータがあり、どの経路で外とつながるかを示し、セキュリティと監視の設計の土台にする
- 復旧の計画（OPS-008 災害復旧計画・訓練結果）で、「どこを、どの順で立ち上げ直すか」の前提にする（06-04 どこまでデータを失ってよいのか）
誰が使うか・いつ作るか
- 作る人：システムアーキテクトと、基盤を担当するベンダーの技術者
- 使う人：各ベンダーの設計者・開発者、セキュリティの担当、運用・監視の担当、本番切替の担当
- 一般的には、全体設計で論理の構成が決まったあとに案を作り、環境が実際に作られるたびに現物と合わせて更新します
- アステリア案件の環境の数、配置、台数、ネットワークの区分は、正本に記載がありません。未確定
CASE FACTFROZEN正本に記載されたアステリア案件の事実
配置に関係する記載
- システムに SYS-06 システム連携基盤、SYS-08 認証・ID基盤、SYS-09 開発・CI/CD基盤、SYS-11 監視・ログ基盤がある
- Vendor B クラウドブリッジの担当範囲は、クラウド基盤、ネットワーク、IAM、連携、CI/CD、監視
- SYS-03 勤怠・工数管理SaaS は Vendor D タイムリンクの担当範囲
- 正本で個別に定義された連携は 12（IF-01〜IF-12）
- P-008 黒田 健 — システムアーキテクト、P-011 山下 恵 — 本番移行・運用リーダー
各システムがクラウドか自社の設備か、どの区画に置かれ、何台で動き、環境がいくつあるかは、正本に記載がありません。未確定 上の人物がこの図を作成・承認したという記載もありません。未確定
主な項目
一般的には、次の項目で構成します。
- 環境の一覧：開発、結合テスト、受入テスト、性能試験、本番、災害時の待機など。環境ごとの目的と、本番との違い
- 配置の絵：環境ごとに、部品（アプリ、データベース、連携、認証、監視、バッチ）がどの区画・どのネットワークの区分に、何台で置かれるか
- 外部とのつなぎ目：SaaS や取引先と、どの経路（インターネット、専用線）で、どの向きにつながるか
- 冗長化と単一障害点：二重化しているもの、していないもの。していないものは、なぜよいとしたか
- データの置き場所：データベース、ファイル、バックアップの保管場所と、保管の世代
- 環境ごとの違い：本番と同じにできない点（台数、データ量、外部接続）と、その影響
- 変更の記録：いつ、何を変えたか。現物と図のずれを防ぐ
教材用サンプル成果物の読み方を学ぶための例
教材用サンプル — 環境ごとの違いと単一障害点の表
この成果物は学習用サンプルです。FROZEN正本に記載されたCASE FACTと、成果物の読み方を学ぶための教材用サンプル値を区別して表示しています。
絵そのものは案件ごとに大きく違うため、ここでは図に添える 2 つの表の書き方を例で示します。内容はすべて教材上の架空の例で、アステリア案件の記録ではありません。
| 環境（教材上の例） | 目的 | 本番との違い | 違いの影響 |
|---|---|---|---|
| 開発 | 開発者が日々変更を試す | 台数は本番の 4 分の 1、外部の SaaS はつながない（模擬応答） | 連携の本当の挙動は確かめられない |
| 結合テスト | システム同士のつながりを確かめる | 台数は本番の半分、SaaS の試験用環境につなぐ | 性能は測れない |
| 性能試験 | 負荷をかけて応答を測る | 本番と同じ台数、データ量は本番相当 | 試験のたびに費用がかかるため期間を限る |
| 本番 | 業務で使う | ― | ― |
| 部品（教材上の例） | 二重化 | 止まったときの影響 | よいとした理由／対策 |
|---|---|---|---|
| 業務アプリのサーバー | あり（2 台） | 1 台停止でも継続 | ― |
| 連携基盤 | あり | 1 系停止でも継続 | ― |
| 夜間処理の実行サーバー | なし（1 台） | 夜間処理が止まる。翌朝までに手動で再開 | 再実行の手順と、朝までの復旧目標を運用手順に書く |
| 外部 SaaS への経路 | なし（SaaS 側の契約） | 工数の取り込みが止まる | 取り込みを翌日にまとめて行える設計にする |
読み方
- 環境ごとに「本番との違い」が書かれているか。違いがテストの結果にどう影響するかが分かるか
- 二重化していない部品が明示され、理由か対策が書かれているか
- 外部とのつなぎ目の経路と向きが書かれているか（どこから入ってくるか）
- データの置き場所と、バックアップの保管場所が分かるか
- 図の日付が新しいか。現物と合っているか
書き方
- 環境の一覧と目的を先に決める。環境の数は費用と期間に直結するため、理由を書く
- 本番の配置を描き、そこから各環境の「違い」を書く（別々に描くと、ずれる）
- 部品ごとに「止まったらどうなるか」を書き、単一障害点の表を作る
- 基盤を担当する会社と、セキュリティ・運用の担当で読み合わせる
- 環境を変更したときに図を直す手順を、変更管理（PRG-008 変更管理台帳）に組み込む
何を書いてはいけないか
- 本番だけの絵。環境の違いが見えないと、テストで見つからない問題の原因が分からない
- 実在の製品名・サービス名を、案件の正式な採用として書くこと（正本に記載がない）
- 接続情報や鍵など、図に書くべきでない秘密情報
- 更新されていない古い図を「最新」として配ること
どこを見るか
- 環境の一覧と、本番との違い
- 単一障害点の一覧と、理由か対策
- 外部とのつなぎ目の経路と向き
- データとバックアップの置き場所
- 図の日付と変更の記録
赤信号
- 環境の違いが書かれておらず、テスト環境で通ったものが本番で違う動きをする理由を誰も説明できない
- 単一障害点の表がなく、「どこが止まると全部止まるか」を聞かれて答えられない
- 図が作られたのは全体設計のときで、その後の環境の変更が反映されていない
- 図に接続先のパスワードやアドレスがそのまま書かれ、広く配られている
よくある失敗
- 性能試験の環境が本番より小さいまま試験し、本番で初めて遅さに気づく。環境の違いを図に書いていれば、結果の読み方を変えられた
- 夜間処理の実行サーバーのように目立たない部品が一台構成で、止まったときの手順が決まっていない
- 図とネットワークの設定が別々に管理され、どちらが正しいか分からなくなる
関係するUnit・成果物・危機演習
- Unit：09-03 開発・テスト・本番をなぜ分けるのか、05-01 システム全体図を読む、06-04 どこまでデータを失ってよいのか、06-03 システムは何時間止められるのか
- 成果物：ARC-001 システム全体構成図、ARC-002 目標システム構成説明書、DEV-004 環境・リリース対応表、OPS-008 災害復旧計画・訓練結果、OPS-002 監視・アラート一覧
- 危機演習：この成果物を直接の題材にする危機演習はありません
AI WORKFLOW
AIは、図に添える表（環境の違い、単一障害点）の抜けを探す下書きに役立ちます。
「次の環境・配置の説明を読み、部品ごとに『二重化の有無』『止まったときの影響』『対策』が書かれているかを表にしてください。書かれていない項目は空欄のまま示し、推測で埋めないでください。対策の良し悪しは判断しないでください。」
REVIEW
- AIが「二重化あり」と読み取った根拠が、元の説明にあるか
- AIに渡した説明に、接続情報や鍵などの秘密情報が含まれていないか（渡す前に取り除く）
- 単一障害点の「よいとした理由」を、人が確かめたか
人間が判断すること
- 環境をいくつ、どの大きさで持つか（費用との釣り合い）
- 二重化しない部品を、どこまで認めるか
- 本番と違う環境でのテスト結果を、どう読むか
設計承認は、AIへ最終委任しない事項です（正本の方針）。
いつ使うか
この教材では STAGE 05｜全体設計を作る の文脈で扱います。 アステリア案件での正式な作成・使用時期（月）は正本に記載がないため、未確定としています。
最後の問い
この図を見た運用担当は、「本番で障害が起きたとき、どの部品がどこで動いていて、何が止まると何に影響するか」を、図を指さしながら説明できますか？