正解は **B、C、E** です。

---

### 【解説】

この問題は、CI/CD がなく、やむを得ず「本番環境での直接変更（レポート、ダッシュボード、リストビュー、一部の低リスクな設定など）」を許可する場合の、**現実的な運用ルール（ガバナンス）**を問うています。アーキテクトとして、理想（すべてSandboxからデプロイ）と現実のバランスを取りつつ、リスクを最小化する助言が求められます。

* **B. マイナーな変更は徹底的に文書化され、ある種の標準的なリズムに従う必要があります。(正解)**
* **理由:** 本番直接変更はログが追いにくいため、「誰が、いつ、なぜ、何を変えたか」の記録（変更ログ）が必須です。また、「いつでもやっていい」とすると業務中に予期せぬトラブルを招くため、「毎週金曜日の夜」や「承認されたメンテナンス枠」など、リリースのリズム（スケジュール）を定義するのがベストプラクティスです。


* **C. すべての変更をテストする必要があります。(正解)**
* **理由:** 「低リスク」と「ノーリスク」は違います。例えば選択リストの値を追加するだけでも、連携している外部システムや入力規則に影響を与える可能性があります。Sandboxでの事前確認、あるいは本番適用直後の動作確認（Sanity Check）プロセスを省略してはいけません。


* **E. 本番環境が変更されても、ダウンストリーム環境は自動的に更新されません。(正解)**
* **理由:** アーキテクトとして最も警告すべき技術的リスクです。本番で直接変更を行うと、開発用Sandbox（ダウンストリーム）のメタデータと差異（Configuration Drift）が生じます。これを認識し、**「手動でSandboxにも同じ変更を加える（バックポート）」**か、**「定期的にSandboxをリフレッシュする」**という運用を組み込まないと、次回の正規デプロイ時に本番の変更を古いSandboxの状態で上書き（先祖返り）してしまう事故が起きます。



#### 【不正解の理由】

* **A. 軽微な変更は文書化する必要がなく、いつでも変更できます。**
* **理由:** ガバナンスの欠如であり、アンチパターンです。これが許されると、システムはすぐに「誰にも管理できない状態（カオス）」になります。


* **D. マイナーな変更を適切に管理するには、CI/CD が必要です。**
* **理由:** 問題の前提は「CI/CDがない組織での対応」です。また、レポート作成などの軽微な変更に対して、高コストなCI/C...