正解は **B** と **C** です。

### 領域の確認

* **領域:** **2. プロセスの自動化とロジック (Process Automation and Logic)**
* **トピック:** データの整合性確保、バリデーション（入力規則 vs トリガー）

-----

### 正解の解説

**B. 検証ルール (Validation Rules) を使用します。**

これが最も一般的で推奨される宣言的（ノーコード）な方法です。
「以前の値が Closed/Won であれば、変更を許可しない」という数式を定義することで、レコードの編集（保存）をブロックできます。

* **数式の例:**
```text
AND(
ISPICKVAL(PRIORVALUE(StageName), "Closed Won"),
NOT($Profile.Name = "System Administrator") // 管理者のみ除外する場合
)
```
このルールがTrueになると、ユーザーが保存ボタンを押した瞬間にエラーメッセージが表示され、編集が阻止されます。

**C. 保存前の Apex トリガー (Save-before Apex Trigger) を使用します。**

これは検証ルールのプログラム版です。複雑な条件（例：関連レコードの状態もチェックしたい、特定のユーザーグループだけ許可したいなど、検証ルールでは記述しきれないロジック）がある場合に使用します。

* **実装イメージ:**
`before update` トリガー内で、変更前の値 (`Trigger.old`) が "Closed/Won" であるかを確認し、そうであれば `addError()` メソッドを使用して保存を阻止します。
```apex
trigger OpportunityTrigger on Opportunity (before update) {
for (Opportunity opp : Trigger.new) {
Opportunity oldOpp = Trigger.oldMap.get(opp.Id);
if (oldOpp.StageName == 'Closed Won') {
opp.addError('成約済みの商談は編集できません。');
}
}
}
```

-----

### 不正解の解説

**A. 自動的に起動される承認プロセスを使用します。**
承認プロセスには「レコードのロック」機能がありますが、通常は「承認を申請中」のレコードをロックするために使われます。「Closed/Won（完了）」になった後に、ロックのためだけにダミーの承認プロセスを自動起動するのは、設計として過剰かつ不自然（ハック的な手法）です。単純な編集不可要件には検証ルールが適しています。

**D. 自動応答ルールを使用します。**
自動応答ルール（Auto-response...

正：B、C

正：B、C