> For the complete documentation index, see [llms.txt](https://support.bridge-funeral.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://support.bridge-funeral.com/salesforce-ji-chu/12-validation-rules.md).

# 入力規則とエラーメッセージ

「保存しようとしたらエラーが出る」 — その大半は **入力規則 (Validation Rule)** によるものです。データの整合性を保つために、Salesforce ではレコード保存時に **業務上のルール** で値をチェックできます。管理者が組織独自ルールを追加することで、誤入力を未然に防げます。

## 入力規則とは

レコードを保存しようとした時に、**条件式で値をチェック** し、不適切な値ならエラーメッセージを表示して保存をブロックする機能です。

### 例

* 「葬儀日が通夜日より前」になる入力をブロック
* 「死亡日が生年月日より前」になる入力をブロック
* 「金額が 0 円未満」になる入力をブロック
* 「自分の所属支店以外の発行元」を選択することをブロック

## 設定方法

`Setup → オブジェクトマネージャ → [オブジェクト名] → 入力規則`

1. **「新規」** をクリック
2. **ルール名** (内部用、英数字)
3. **エラー条件式** を入力 (Salesforce 数式言語)
4. **エラーメッセージ** を入力 (ユーザーに表示する日本語)
5. **エラー表示位置** を選択 (フィールド単位 / 上部全体)
6. 保存

## エラー条件式の例

### 例 1: 葬儀日が通夜日より前

```
ceremonyDate__c < tsuyaDate__c
```

> 注: 実際の項目名は組織のカスタムに合わせる。`AND` `OR` `ISBLANK` `ISCHANGED` などの関数も利用可能。

### 例 2: 死亡日が生年月日より前

```
AND(
  NOT(ISBLANK(BirthDate__c)),
  NOT(ISBLANK(DeathDate__c)),
  DeathDate__c < BirthDate__c
)
```

### 例 3: 必須項目チェック (条件付き)

```
AND(
  Status__c = "見積確定",
  ISBLANK(BillingAddress__c)
)
```

「見積確定にする時は請求先住所を必須」というルール。

## エラーメッセージの書き方

ユーザーが理解できる日本語で書くのが大切です。

| 悪い例                            | 良い例                           |
| ------------------------------ | ----------------------------- |
| `Error: validation_001 failed` | `葬儀日は通夜日より後の日付を指定してください`      |
| `INVALID_VALUE`                | `死亡日は生年月日より後の日付を入力してください`     |
| `フィールド XX が無効`                 | `「請求先住所」を入力してください (見積確定時に必須)` |

> ユーザーが何を直せばいいかが、メッセージから分かることが重要。

## ブリッジ葬儀パッケージの入力規則

ブリッジ葬儀パッケージ自体は、ベース部分にいくつかの入力規則を含んでいます (例: 価格タイプの「同カテゴリでデフォルトは 1 つだけ」ルール → `PriceTypeDefaultEnforcer`)。

組織独自の入力規則は、組織で追加していきます。

## 組織独自ルールの導入例

ブリッジ葬儀の運用でよくある追加ルール:

### 1. 喪主は必須

```
AND(
  RecordType.DeveloperName = "Sougi",
  ISBLANK(Moshu__c)
)
```

エラーメッセージ: `葬儀施行情報には喪主の指定が必須です`

### 2. 同じ家族に重複お客様

(これは入力規則だけでは難しく、Apex Trigger との併用)

### 3. 価格 0 円の見積を見積確定にできない

```
AND(
  Status__c = "見積確定",
  TotalAmount__c <= 0
)
```

### 4. 死亡日が将来の日付

```
AND(
  NOT(ISBLANK(DeathDate__c)),
  DeathDate__c > TODAY()
)
```

## 入力規則をユーザーに伝える

入力規則は **画面遷移時には見えない** ため、ユーザーが「保存して初めて知る」状態になります。これを避けるには:

1. **エラーメッセージを丁寧に**
2. ユーザーガイドの **「よくあるエラー」セクション** に明記
3. 該当項目を **必須マーク** (見た目で分かるよう) にする
4. オンボーディング時にルールを説明

## 入力規則の運用ルール

### 厳しすぎないこと

ルールを増やしすぎると、ユーザーが必要な情報を後で追加できなくなります。例えば、「受電直後は喪主未確定でも保存できる」運用なら、喪主必須ルールは「ステータスが見積確定の時だけ」など条件付きに。

### 例外対応の運用

業務上、ルールを一時的に外したい場合 (システム移行など):

* 入力規則を **「無効」に切り替え** て一時無効化 (管理者作業)
* 完了後すぐに「有効」に戻す
* 影響範囲を Sandbox で先に確認

## 入力規則の確認 / 検証

新しいルールを追加する時の確認手順:

1. **Sandbox で先に作成** → 動作確認
2. 既存データに矛盾がないか確認 (`SOQL` で抽出)
3. ユーザーへの **事前通知**
4. 本番にデプロイ

## エラーメッセージのデバッグ

ユーザーから「エラーが出る」と相談を受けたら:

1. **エラーメッセージ全文** をスクリーンショットで受け取る
2. メッセージから入力規則 (Validation Rule) を特定
   * `Setup → オブジェクトマネージャ → [オブジェクト名] → 入力規則`
3. 条件式を確認 → どの項目が条件に該当しているかを再現
4. ユーザーに「この項目をこう直せば OK」と案内

## こんなときは

### パッケージの入力規則を変えたい

→ 直接編集不可。組織独自の入力規則として上書きする方法も推奨されません (パッケージ更新時の衝突)。代わりに、新しいカスタム規則として追加する形で対応。

### ユーザーから「エラーで保存できない」と言われた

→ エラーメッセージを正確に取得 → 該当の入力規則を特定 → 対応案内 (上述の「デバッグ」)

### 一時的に入力規則を外したい

→ 入力規則の編集画面で **「有効」のチェックを外す** → 保存 → 作業後に必ず再度有効化

### 入力規則が機能しない

* ルールが「無効」になっていないか確認
* 条件式の構文を再確認 (`AND` / `OR` の括弧)
* データ移行の場合は **入力規則をスキップするオプション** がある (Data Loader / API)

## 入力規則と他の自動処理との関係

入力規則は **保存「直前」** にチェックされる、最後の関門です。

```
ユーザーが「保存」を押す
      ↓
[1] Trigger (before save) — 値の自動補正
      ↓
[2] 入力規則 (Validation Rule) — エラー判定
      ↓ (合格すれば)
[3] Trigger (after save) — 関連レコード更新
      ↓
[4] Flow (Record-Triggered) — 自動処理
```

つまり Trigger で自動補正された値も、入力規則のチェック対象。「Trigger で補正される予定でも、入力規則の条件式は補正後の値を見る」 ことに注意。

## 次に進む

* [ユーザーとプロファイル・権限](/salesforce-ji-chu/13-users-profiles-permissions.md)
* [データ共有モデル](/salesforce-ji-chu/14-data-sharing-model.md)
* 一般ユーザー: [困ったときの対処](/nori/21-troubleshooting.md) — エラーメッセージ別の対処

***

📅 最終更新日: 2026-06-16


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://support.bridge-funeral.com/salesforce-ji-chu/12-validation-rules.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.