【Salesforce】入力規則のエラーメッセージが想定と違う時の本番反映前の切り分け

Salesforceの入力規則を実装する際、エラーメッセージが想定と異なる動作をすることがあります。本番環境に反映する前に、適切に切り分けを行わないと、ユーザーに混乱を招く原因になります。特に、エラーメッセージが表示されない、別のメッセージが表示される、または多言語で意図しない表記になるなどの問題は、事前にチェックしておく必要があります。この記事では、入力規則のエラーメッセージに関するトラブルを、本番反映前に効率的に切り分ける方法を解説します。

1. エラーメッセージが想定と違う:よくある原因と比較表

入力規則のエラーメッセージが想定通りに動作しない原因は、大きく分けて以下の3つです。まずは、自身の状況に当てはめて確認してください。

症状	主な原因	チェックポイント
エラーメッセージが表示されない	入力規則が無効、条件に合致しない、権限でスキップ	入力規則の有効化状態、数式の論理、プロファイルの「入力規則の除外」設定
エラーメッセージが別の文言で表示される	翻訳設定が競合、トリガーやフローが上書き	翻訳作業台帳、Apexトリガー、画面フローのエラーハンドリング
エラーメッセージが英語など固定で表示される	ユーザの言語設定がデフォルト、翻訳が未適用	ユーザの言語とロケール、翻訳が正しく設定されているか
エラーメッセージが表示された後に別のエラーが出る	複数の入力規則が同時に動作、フローやトリガーで別の制約	レコードの保存処理全体のログを確認

2. 最初に行うべき基本手順

切り分けを始める前に、必ず以下の基本手順を実施してください。これらは開発者コンソールや設定画面を使って簡単に確認できます。

1. 開発者コンソールを開く: 右上の歯車アイコン →「開発者コンソール」をクリックします。
2. 実行ログの設定: 「デバッグ」メニュー →「実行ログを開く」→「新規実行ログ」を選択し、対象ユーザとイベント(例:Apex、入力規則)を指定します。
3. 問題の操作を再現: レコードの作成・編集など、エラーが発生する操作を実行します。
4. ログを確認: 実行ログに「VALIDATION_RULE」という行があるか確認します。エラーメッセージが正しく評価されているか、数式の結果が想定通りかをチェックします。
5. 匿名Apexで数式をテスト: 開発者コンソールの「デバッグ」→「匿名Apexを開く」で、入力規則の数式を直接実行し、エラーメッセージが取得できるか確認します。

2.1 数式の直接テスト

匿名Apexで数式をテストする方法を具体的に説明します。例えば、入力規則が「IF(Amount > 1000, true, false)」の場合、以下のコードでエラーメッセージを取得できます。

Boolean result = (Boolean) SObjectType.Opportunity.Fields.Amount.getDescribe().getDefaultValueFormula(); // 事前準備が必要な場合あり

実際には、数式を直接評価するには、Schemaクラスを使ったより正確な方法があります。詳細はSalesforceヘルプを参照してください。

3. 原因別の切り分け手順

3.1 表示されない場合の確認

• 入力規則が有効か: 設定 →「オブジェクトマネージャ」→対象オブジェクト →「入力規則」で、該当ルールがアクティブであることを確認します。
• 条件に合致しているか: 開発者コンソールで数式の評価結果を確認します。期待する条件でtrueになっているかどうかを見ます。
• プロファイルの除外設定: 設定 →「プロファイル」→対象プロファイル →「オブジェクト設定」→該当オブジェクト →「入力規則の除外」にチェックが入っていると、エラーがスキップされます。

3.2 別のメッセージが表示される場合

• 翻訳設定の競合: 設定 →「翻訳作業台帳」で、入力規則のエラーメッセージが正しく翻訳されているか確認します。標準の翻訳が優先される場合があるため、カスタム翻訳が適用されているかをチェックします。
• トリガーやフローの上書き: 同じタイミングで動作するApexトリガーや画面フローが、エラーメッセージを別のものに置き換えていないか確認します。ログでaddErrorメソッドやエラーハンドリングを探します。

3.3 言語が固定で表示される場合

• ユーザの言語設定: 設定 →「ユーザ」→該当ユーザ →「言語」と「ロケール」が期待する値になっているか確認します。
• 翻訳が未適用: 入力規則のエラーメッセージに翻訳が設定されていないと、デフォルトの言語で表示されます。翻訳作業台帳で該当メッセージが登録されているか確認します。

4. 失敗パターンと管理者へ伝える情報

実際の現場でよくある失敗パターンを紹介します。これらの事例を知っておくことで、切り分けがスムーズになります。

• パターン1: 入力規則の数式が複雑で、参照フィールドが空の場合に予期しない結果になる。 → 数式でISBLANK関数を使って空の場合を明示的に処理する必要があります。
• パターン2: Apexトリガー内でaddErrorを呼ぶ際に、入力規則のメッセージが上書きされる。 → トリガーの処理順序を見直し、エラーメッセージを統合する必要があります。
• パターン3: 画面フローのエラーハンドリングで、独自メッセージが入力規則のメッセージより優先される。 → フロー内の「エラー表示」要素の設定を確認します。
• パターン4: ブラウザの自動翻訳機能がSalesforceのエラーメッセージを意図せず変換する。 → ブラウザの翻訳設定をオフにしてテストします。

管理者へ伝えるべき情報として、以下の項目をまとめておくと原因調査が迅速に進みます。

• 発生している具体的な画面(オブジェクト、レコードタイプ、ボタン操作)
• エラーメッセージのスクリーンショットまたは正確な文言
• ユーザのプロファイルと権限セット、言語設定
• 実行ログ(該当部分抜粋)
• 再現手順(サンドボックスで可能かどうか)

5. よくある質問(FAQ)

Q1: 入力規則のエラーメッセージを動的に変更できますか?

標準の入力規則では、エラーメッセージは固定の文字列です。ただし、カスタム数式を使って条件に応じたメッセージを表示するテクニックとして、数式内でCASE関数などで文字列を動的に生成する方法があります。例えば、IF(条件, ‘メッセージA’, ‘メッセージB’)のようにします。ただし、翻訳が必要な場合は注意が必要です。

Q2: この切り分けはSandboxでも同じ手順で使えますか?

はい、同じ手順が使えます。むしろ、本番環境への反映前にSandboxで徹底的にテストすることを推奨します。Sandboxであれば、プロファイルや権限セットの変更も自由に行えます。ただし、Sandboxのデータ量やユーザ設定が本番と完全に一致しない場合があるため、最終確認は本番に近い環境で行いましょう。

Q3: エラーメッセージが表示されない原因として、他に考えられるものはありますか?

設定の確認に加えて、ブラウザのポップアップブロックやSalesforceの権限「API使用可能」が有効でないために、画面が正常に動作しないケースも報告されています。また、レコードタイプごとに入力規則が異なる場合、対象レコードタイプに適用されているかも確認してください。

6. まとめ

入力規則のエラーメッセージのトラブルは、本番反映前に適切に切り分けることで、ユーザへの影響を最小限に抑えられます。開発者コンソールでのログ確認、数式の直接テスト、プロファイルや翻訳設定のチェックを習慣化しましょう。また、管理者と共有する情報を整理しておくことで、問題解決が迅速になります。特に、トリガーやフローの干渉は見落としがちなので、ログの確認を徹底してください。本番環境に変更を加える前に、必ずSandboxで十分な検証を行い、意図したエラーメッセージが正しく表示されることを確認することをお勧めします。