結論：まずこれだけ覚える
Salesforceで「この項目を空欄のまま保存させたくない」を実現する代表的な方法は5つあります。使い分けの基準は、どの経路に効かせるか、条件分岐が必要か、単純な入力チェックか複雑な処理かです。
| 方法 | 効く範囲 | 設定場所 | 使いどころ |
|---|---|---|---|
| 項目定義で「必須」にする（普遍的に必須の項目） | 全レコードタイプ・全ページレイアウト・API・データローダ・一括処理まで | オブジェクトマネージャ → 項目とリレーション | 例外なく必ず必要な項目 |
| ページレイアウトで「必須」にする | そのページレイアウトの画面入力のみ | ページレイアウトエディタ | 画面から入れる人にだけ強制したいとき |
| Dynamic Formsで「必須」にする | そのLightningレコードページ上の項目のみ | Lightningアプリケーションビルダー | Lightningページ単位で必須にしたいとき |
| 入力規則（検証ルール） | 保存されるすべての経路。条件付きで制御できる | オブジェクトマネージャ → 入力規則 | 「特定の条件のときだけ必須」にしたいとき |
| レコードトリガーフローの［カスタムエラー］ | フローを起動するレコード変更。エラー時は変更をロールバック | Flow Builder | 複雑な分岐や関連データの確認を伴う入力チェックを行いたいとき |
試験での基本的な覚え方は、無条件・全経路で必須なら項目定義、単純な条件付き必須なら入力規則です。レコードトリガーフローの［カスタムエラー］でも保存を止められますが、単純な入力チェックに不要な複雑さを持ち込まないようにします。
用語をひとつずつ噛み砕く
普遍的に必須の項目（Universally Required Field）
カスタム項目を作るときに表示される［必須］チェックボックスをオンにしたものです。公式ドキュメントは「普遍的に必須の項目は、すべてのレコードタイプで必須になる」「編集ページには、項目レベルセキュリティに関わらず普遍的に必須の項目が常に表示される」と定義しています。 ポイントは3つあります。
- レコードタイプやページレイアウトで逃げられない
- 画面だけでなく、API・データローダ・インポートウィザードからの登録でも空欄なら失敗する
- 標準項目は普遍的に必須にできない（公式に明記されています）。カスタム項目だけの機能です
ページレイアウトの「必須」
ページレイアウトエディタで項目をダブルクリックすると出てくる［必須］チェックボックスです。これはその画面から入力するときだけ効きます。データローダで流し込めば空欄でも通ります。
Dynamic Formsの「必須」
Dynamic Formsを使用するLightningレコードページでは、Lightningアプリケーションビルダーの項目プロパティで［必須］を設定できます。この設定はその項目がそのLightningページに表示される場合だけ効き、同じ項目のすべての表示箇所やAPI更新に適用されるわけではありません。 また、実行時にコンポーネント表示条件で項目が非表示になると、値がなくても保存できます。全経路で必須にする用途ではなく、特定のLightningページ上の入力体験を調整する機能として使います。
入力規則（検証ルール）
「この条件に当てはまったらエラーにする」という式を書く仕組みです。保存のたびに評価され、結果が true になるとエラーメッセージを出して保存を止めます。画面・API・データローダ・フロー、どの経路でも効きます。 条件付きで必須にできるのが大きな強みです。「フェーズが完了のときだけ理由を必須にする」といった単純な要件では、入力規則が第一候補です。現在はレコードトリガーフローの［カスタムエラー］でも保存を止められるため、「入力規則でしか実現できない」という意味ではありません。
レコードトリガーフローの［カスタムエラー］
レコードトリガーフローでは、保存前パスまたは保存後パスに［カスタムエラー］要素を配置できます。エラーが発生すると、フローを起動した変更はロールバックされ、レコードページ全体または特定項目のインラインにエラーメッセージを表示できます。 関連レコードを参照する複雑な判定や、複数段階の分岐と入力チェックを同じ自動化で扱う場合に有効です。一方、空欄判定だけなら入力規則の方が意図を読み取りやすく、保守もしやすいことが一般的です。なお、値を自動補完するフローは「利用者に入力を必須にする」のではなく、システムが値を設定する別の設計です。
落とし穴：必須にできない項目がある
リッチテキスト形式のテキストエリア項目は、項目定義の［必須］チェックボックスを持ちません。数式項目・自動採番項目・チェックボックスなども同様に、必須化の対象外です。
リッチテキスト項目を実質的に必須にしたい場合は、入力規則で「空欄ならエラー」を書きます。Salesforce公式は空欄判定の例として LEN(Rich_Text_Area__c) = 0 を示しています。ただし、画像だけを挿入した場合は文字数で正しく判定できないため、画像利用を含む入力要件ではサンドボックスで挙動を確認し、必要に応じて設計を見直します。
よくある質問
Q. ページレイアウトで必須にしたのに、データローダで空欄が入ってしまいます。 A. 仕様どおりです。ページレイアウトの必須は画面入力にしか効きません。全経路で止めたいなら項目定義の必須か入力規則を使ってください。 Q. レコードタイプごとに必須項目を変えたいです。 A. 項目定義の必須は全レコードタイプに効いてしまうため使えません。レコードタイプごとに別のページレイアウトを割り当てて、そちらで必須にします。全経路で止めたい場合はレコードタイプを条件に含めた入力規則を書きます。 Q. 必須にするとレポートやビューに影響しますか。 A. しません。必須化は保存時の検証だけに関わります。
出典（Salesforce公式）
- Considerations for Universally Required Fields — 「普遍的に必須の項目はすべてのレコードタイプで必須になる」「標準項目は普遍的に必須にできない」「編集ページは項目レベルセキュリティに関わらず普遍的に必須の項目を表示する」
- Require Field Input to Ensure Data Quality — 項目の入力を必須にしてデータ品質を担保するという機能の位置づけ
- Custom Field Attributes — 項目の属性として設定できる内容の一覧
- How to Make a Custom Field Required in Salesforce — 項目定義、ページレイアウト、入力規則、Dynamic Formsという必須化方法の適用範囲と違い
- Required and Read-Only Fields in Dynamic Forms — Lightningアプリケーションビルダーで設定した必須がそのページ上の項目だけに適用され、表示条件で非表示の場合は未入力でも保存できること
- Unable to create a formula field that has a rich text area field — リッチテキストエリアは入力規則で使用でき、空欄判定には
LEN(...) = 0を使う例と、画像だけの場合の制約 - Custom Error Element — レコードトリガーフローの保存前・保存後パスでカスタムエラーを表示し、変更をロールバックできること