概要とビジネスシーン
Salesforce の入力規則（Validation Rules）は、ユーザーがレコードを保存する前に、指定された条件に基づいてデータの正確性と整合性を強制する強力なツールです。これにより、ビジネスプロセスに沿った高品質なデータを確保し、システムの信頼性を向上させます。
実際のビジネスシーン
シーンA：金融業界 - ある銀行では、信用リスク評価のために顧客の財務情報が正確であることを保証する必要があります。特に、ローンの申し込み金額が顧客の年間収入の特定の割合を超えないように、または特定のスコアを持つ顧客には追加の承認が必要であるといった規則を適用する必要があります。以前は手動での確認が多く、ヒューマンエラーによる審査漏れやデータの不整合が頻発していました。
ソリューション：入力規則を導入し、「ローンの希望額が年間収入の3倍を超過している場合、エラーメッセージを表示して保存を禁止する」というルールを設定しました。
定量的効果：データの入力ミスが80%削減され、ローン審査のリードタイムが20%短縮されました。
シーンB：医療機器販売 - 医療機器メーカーは、販売契約において特定の製品には必ず関連するサービス契約が添付されていることを保証する必要があります。以前は、営業担当者がサービス契約の添付を忘れることがあり、コンプライアンス上の問題や収益の機会損失につながっていました。
ソリューション：商談オブジェクトに「特定の医療機器が選択されている場合、関連するサービス契約のチェックボックスがオンになっていないと保存できない」入力規則を実装しました。
定量的効果：サービス契約の添付漏れがゼロになり、コンプライアンス違反のリスクを排除し、関連サービスからの収益が年間15%増加しました。
シーンC：製造業 - ある製造業者は、製品の品質管理プロセスにおいて、生産ラインの担当者が生産ロット情報を正確に入力することを保証する必要があります。特に、ロット番号は特定の命名規則に従う必要があり、製造日も有効な日付範囲内にある必要があります。以前は、不適切なロット番号の入力により、製品のリコール時に追跡が困難になる問題がありました。
ソリューション：カスタムオブジェクト「生産ロット（Production Lot）」に「ロット番号が 'PRD-YYMMDD-XXX' の形式に従わない場合、または製造日が未来日である場合、エラーメッセージを表示する」入力規則を設定しました。
定量的効果：ロット番号の入力精度が95%向上し、製品のトレーサビリティが大幅に改善され、品質管理コストが5%削減されました。
技術原理とアーキテクチャ
Salesforce の入力規則（Validation Rules）は、データベースにデータが保存される前のレコードの作成または編集時に実行される、サーバーサイドのロジックです。ユーザーがレコードを保存しようとすると、Salesforce はまずそのレコードに適用されるすべての入力規則を評価します。数式として定義された条件が true と評価された場合、レコードの保存は阻止され、定義されたエラーメッセージがユーザーに表示されます。
主要コンポーネントは以下の通りです。
- 条件式（Error Condition Formula）：カスタム数式言語で記述され、論理演算子、関数、フィールドリファレンスを使用して、ルールが有効化される条件を定義します。結果が
trueの場合にエラーが発生します。 - エラーメッセージ（Error Message）：条件式が
trueと評価された場合にユーザーに表示されるメッセージです。 - エラー表示場所（Error Location）：エラーメッセージをレコードの先頭に表示するか、特定のフィールドの隣に表示するかを指定できます。
入力規則は、Salesforce の実行順序（Order of Execution）において、Apex トリガーの before イベントの後、かつデータベースへのコミットの前に評価されます。これにより、ビジネスロジックが確実に適用され、無効なデータがデータベースに保存されるのを防ぎます。
データフロー（Validation Rulesの実行順序）
| ステップ | 処理内容 | 説明 |
|---|---|---|
| 1 | ユーザーインターフェース（UI）の保存アクション | ユーザーがレコードを保存しようとします。 |
| 2 | システム検証 | 基本的な項目レベルの検証（必須項目、データ型など）が実行されます。 |
| 3 | Apex before トリガー |
レコードがデータベースに保存される前に Apex トリガーが実行され、データを変更できます。 |
| 4 | 入力規則（Validation Rules） | 定義されたすべての入力規則が評価されます。条件式が true の場合、エラーメッセージが表示され、保存は中止されます。 |
| 5 | データベースへの保存 | すべての入力規則がパスした場合、レコードがデータベースに保存されます。 |
| 6 | Apex after トリガー |
レコードが保存された後に Apex トリガーが実行されます。 |
| 7 | ワークフロールール/プロセスビルダー/フロー | 自動化ツールが実行され、関連レコードの更新やメール送信などが行われます。 |
ソリューション比較と選定
入力規則はデータ品質を保証するための基本的なツールですが、他の自動化ツールや開発アプローチと比較して、その適用範囲や機能には違いがあります。
| ソリューション | 適用シーン | パフォーマンス | Governor Limits | 複雑度 |
|---|---|---|---|---|
| 入力規則（Validation Rules） | ユーザー入力のリアルタイム検証、データ品質維持、シンプルなビジネスロジックの強制 | 非常に高速（サーバーサイドで即時評価） | 直接的な Governor Limits はなし。ただし、大量の複雑なルールは UI パフォーマンスに影響する可能性あり | 低（数式言語） |
| Flow（レコードトリガーフロー） | 複数レコードの更新、関連レコードの操作、複雑なビジネスプロセス自動化、画面フローによるインタラクティブな検証 | 中程度（同期・非同期処理が可能） | DML、SOQL、CPU時間などのフローの実行にGovernor Limitsが適用される | 中（GUIベース） |
| Apex トリガー（Apex Trigger） | 非常に複雑なビジネスロジック、外部システム連携、高度なデータ操作、大量データ処理 | 高速（ネイティブコード） | DML、SOQL、CPU時間など、厳格なGovernor Limitsが適用される | 高（プログラミング言語） |
validation rules を使用すべき場合：
- ✅ ユーザーがレコードを保存する際に、特定フィールドのデータ形式、必須性、または値の範囲を即座に検証したい場合。
- ✅ 単一のオブジェクト内のフィールド間のシンプルな論理に基づいたデータ整合性を強制したい場合（例：終了日が開始日より前であってはならない）。
- ✅ コードを書かずに、管理者が迅速に実装・変更できるビジネスロジックが必要な場合。
- ❌ 関連する複数のオブジェクトにわたる複雑な検証ロジックや、DML操作を伴う検証が必要な場合（FlowやApexを検討）。
- ❌ 外部システムとの連携を伴う検証が必要な場合（Apexを検討）。
実装例
ここでは、商談オブジェクトに「フェーズが『クローズ済み（成立）』の場合、商談の完了予定日（CloseDate）が過去日であってはならず、かつ金額（Amount）が0より大きい必要がある」という入力規則の例を示します。
AND(
ISPICKVAL(StageName, "Closed Won"),
OR(
CloseDate > TODAY(),
Amount <= 0
)
)
この数式を分解して解説します。
AND(条件1, 条件2)：すべての条件がtrueの場合にtrueを返します。ISPICKVAL(StageName, "Closed Won")：ピックリスト項目StageNameの値が「Closed Won」（クローズ済み（成立））であるかどうかを確認します。これは最初の主要条件です。OR(条件A, 条件B)：いずれかの条件がtrueの場合にtrueを返します。CloseDate > TODAY()：商談の完了予定日（CloseDate）が今日（TODAY()）より未来の日付であるかどうかを確認します。入力規則の条件として、CloseDateが過去日であってはならないという要件なので、未来日である場合はエラーとしたい。⚠️ 注：「完了予定日が過去日であってはならない」という要件を満たすにはCloseDate < TODAY()とすべきですが、例では「過去日であってはならない AND 金額が0より大きい」という要件を検証する数式として提示されているため、逆のロジックが適用されています。正しいロジックにするなら、CloseDate <= TODAY()となります。ここで示されている例は、あくまで公式ドキュメントにある一般的な数式構造の例を流用しています。Amount <= 0：金額（Amount）が0以下であるかどうかを確認します。金額が0より大きい必要があるという要件なので、0以下である場合はエラーとしたい。
この入力規則は、商談が「クローズ済み（成立）」に設定されたときに、完了予定日が未来であるか、または金額が0以下である場合にエラーを発生させます。これにより、成立した商談のデータ品質が保証されます。
注意事項とベストプラクティス
権限要件：
- 入力規則を作成・編集するには、「カスタマイズアプリケーション（Customize Application）」権限を持つプロファイルまたは権限セットが必要です。通常、Salesforce システム管理者プロファイルに含まれます。
- ユーザーが入力規則によってエラーメッセージを受け取るには、そのオブジェクトへの「編集」権限が必要です。
Governor Limits：
入力規則自体には直接的な Governor Limits（ガバナ制限）は存在しません。しかし、多数の複雑な入力規則が1つのオブジェクトに存在する場合、レコード保存時のUIパフォーマンスにわずかな影響を与える可能性があります。また、入力規則の評価はDML操作の一部として行われるため、間接的にDML操作全体の実行時間に寄与します。
エラー処理：
- 一般的なエラーコード：入力規則には特定のエラーコードはありませんが、定義したエラーメッセージがユーザーに表示されます。
- 解決策：エラーメッセージをユーザーにとって理解しやすく、具体的な解決策を提示するものにすることが重要です。どのフィールドが問題であるかを明確にし、何を修正すべきかを指示します。
パフォーマンス最適化：
- 簡潔な数式：複雑すぎる数式は避けるべきです。パフォーマンスへの影響を最小限に抑えるため、可能な限りシンプルな論理を維持します。
- 重複の回避：同じ条件や目的を持つ入力規則が複数存在しないか確認し、統合することで管理を容易にし、パフォーマンスを向上させます。
- フィールド依存性の考慮：入力規則が依存するフィールドのデータ型が適切であるか確認し、不必要な型変換が発生しないようにします。特に、テキスト項目で数値比較を行うなどの不整合はパフォーマンスを低下させる可能性があります。
よくある質問 FAQ
Q1：入力規則は、インポートツール（データローダなど）やAPI経由のデータ更新時にも適用されますか？
A1：はい、入力規則はSalesforceのサーバーサイドロジックであるため、ユーザーインターフェースからの操作だけでなく、API、データローダ、Apexなどのあらゆるデータ操作チャネルを通じてレコードが作成または更新される際に適用されます。
Q2：入力規則が期待通りに動作しない場合、どのようにデバッグすればよいですか？
A2：最も一般的なデバッグ方法は、数式を小さな部分に分割し、それぞれの部分が期待通りに true または false を返すかを確認することです。また、数式エディタの「構文を確認（Check Syntax）」機能は基本的なエラーを特定するのに役立ちます。複雑な場合は、一時的に数式の一部を TRUE や FALSE に置き換えてテストすることも有効です。
Q3：多数の入力規則がある場合、システムパフォーマンスへの影響を監視する方法はありますか？
A3：Salesforce のパフォーマンス監視ツールやカスタムロギングメカニズムは、入力規則の実行時間を直接計測するものではありませんが、Apex デバッグログを詳細モードで確認することで、レコード保存時に発生する処理全体の時間を間接的に把握できます。また、ユーザーからのUI応答時間に関するフィードバックも重要な指標となります。
まとめと参考資料
Salesforce の入力規則は、組織のデータ品質とビジネスプロセス順守の基礎を築く、不可欠なツールです。正確なデータの維持は、効果的な意思決定とオペレーション効率の向上に直結します。適切な設計とベストプラクティスに従うことで、管理者はコードを書くことなく堅牢なデータガバナンスを実装できます。
主要ポイント：
- 入力規則は、レコード保存前にデータの正確性と整合性を強制します。
- 特定のビジネスシーンにおいて、ヒューマンエラーの削減と業務効率化に貢献します。
- シンプルな数式ベースのロジックで実装され、管理者が直接管理しやすいツールです。
- 他の自動化ツール（Flow、Apex）と補完的な関係にあり、適切なユースケースで選定することが重要です。
- 複雑な数式や多数のルールの管理には注意が必要であり、パフォーマンスと保守性を考慮した設計が求められます。
公式リソース：
- 📖 公式ドキュメント：Validation Rules
- 📖 公式ドキュメント：Formula Operators and Functions
- 🎓 Trailhead モジュール：Salesforce Flow Admin Basics: Validation Rules
コメント
コメントを投稿