【LWC】lightning-record-pickerとlightning-record-edit-formの違い - TerraSkyBase | テラスカイを支える人とテクノロジーの情報を発信する基地局

はじめに

こんにちは！エンジニアのT.Kです。
LWCで「レコードを検索して選択するUI」を実装する際、どのコンポーネントを使うべきか迷ったことはありませんか。
少し前までは、LWCで標準のルックアップのような機能を実装しようとすると、「lightning-record-edit-form」の参照項目を使用するか、自作のカスタムコンポーネントを用意するのが一般的でした。

しかし、現在はレコード選択に特化した「lightning-record-picker」がリリースされ、実装の選択肢が広がっています。
「結局、どちらを使えばいいの？」「何が決定的に違うの？」という疑問を解消するため、今回はこれら2つのコンポーネントの機能的な違いと、実務での使い分けのポイントを整理して解説します。

それぞれの画面イメージと挙動の違い

1. 検索を開始した時の挙動（候補の出し方）

まず、検索フィールドをクリックした際の初期挙動に大きな違いがあります。

「lightning-record-picker」の場合、フィールドを選択しただけでは候補リストは表示されません。ユーザーが文字を入力し始めたタイミングで初めての検索が実行される仕様となっています。そのため、特定のキーワードがわかっている状態での検索に適しています。

対して「lightning-record-edit-form」は、フィールドをクリックした瞬間に「最近参照したレコード」が最大5件ほど自動的にリストアップされます。ユーザーが「直前まで作業していたレコード」を再度選択したい場合、文字を入力する手間が省けるため、利便性が高いのが特徴です。

2. 検索結果の表示内容

「lightning-record-picker」は、表示する情報だけでなく、検索の対象項目まで開発者が制御できるのが強みです。「display-info」属性で補足情報を出せるほか、検索の主軸も「matching-info」属性で指定可能です。例えば、Name項目が「自動採番」で検索しづらいオブジェクトでも、代わりに「申請名」などを検索対象に据えることで、実務に即した柔軟な設計が可能です。

※Application__c（カスタムオブジェクト）を使用。Name項目は自動採番（APP-0001等）ですが、primaryFieldに「申請名」を指定することで、Name項目以外での検索を可能にしています。

一方、「lightning-record-edit-form」は、基本的にはSalesforceの標準設定（検索レイアウト）に準拠した形式で表示されます。検索対象も原則として「Name項目」に固定されるため、カスタマイズ性は低いものの、他の標準画面と同じ見え方になることでユーザーに馴染みのある操作感を提供できるメリットがあります。

※Edit-formは検索対象がName項目（自動採番）に固定されるため、申請名の一部を入力してもヒットしません。

3. 「高度な検索」への対応

より複雑な検索を行いたい場合の挙動にも決定的な違いがあります。

「lightning-record-edit-form」では、標準機能である「高度な検索」を利用できます。ドロップダウンのリストだけでは目的のレコードが見つからない場合でも、専用のダイアログ画面を開いて詳細な情報を確認しながらレコードを探せるため、より確実なデータ選択が求められる業務に適しています。

対して「lightning-record-picker」は、このような検索ダイアログには対応していません。あくまで入力ボックス内でのインライン検索に特化した設計となっており、機能がシンプルに削ぎ落とされているのが特徴です。

4. 独自の強みと便利機能

最後に、それぞれのコンポーネントにしかできない決定的な機能差を整理します。

「lightning-record-picker」の大きな武器は、JavaScriptによる「動的なフィルタリング」です。filter 属性を使うことで、画面上の他の入力値に合わせて検索結果をリアルタイムに絞り込めます。標準の参照項目では難しかった「選択肢の動的な制御」を、プログラム側から自由に行えるのが最大のメリットです。

（[キャプチャ⑥挿入位置]：JSで定義した条件に一致するレコードだけが候補に出ている様子）

対して「lightning-record-edit-form」の利点は、「メタデータとの自動同期」です。Salesforce側で設定した「項目ヘルプテキスト」や「必須入力」の設定がそのまま画面に反映されます。自前でラベルや説明文を配置しなくても、Salesforce側での設定変更が即座に画面へ反映されるのが、標準コンポーネントならではの強みです。

実装コードの比較

実装の面でも、コードの構造には大きな違いがあります。

1. 「lightning-record-picker」の場合

このコンポーネントは単体で動作し、属性を追加することで柔軟に機能を拡張できるのが特徴です。

<lightning-record-picker
    label="取引先"
    object-api-name="Account"
    placeholder="取引先名または電話番号で検索..."
    display-info={displayInfo}
    matching-info={matchingInfo}
    filter={filterCriteria}
></lightning-record-picker>

recordPicker.html

import { LightningElement } from 'lwc';

export default class RecordPickerTrial extends LightningElement {
    // 1. 表示内容の設定（リストに何を出すか）
    displayInfo = {
        primaryField: 'Name',           // メイン表示（太字）
        additionalFields: ['Phone']     // サブ表示（電話番号）
    };

    // 2. 検索対象の設定（何でヒットさせるか）
    matchingInfo = {
        primaryField: { fieldPath: 'Name' },
        additionalFields: [{ fieldPath: 'Phone' }]
    };

    // 3. フィルター条件の設定（例：IndustryがBankingのレコードのみ）
    filterCriteria = {
        criteria: [
            {
                fieldPath: 'Industry',
                operator: 'eq',
                value: 'Banking',
            },
        ],
    };
}

recordPicker.js

JavaScript側で各プロパティ（displayInfoやfilterなど）を定義する手間はかかりますが、その分、表示内容や検索対象、絞り込み条件をプログラムから自由自在にコントロールできるのが最大の強みです。

2. 「lightning-record-edit-form」の場合

このコンポーネントはSalesforce側の設定（メタデータ）をそのまま利用するため、JSでの定義を介さず、HTMLだけで完結するのが大きな特徴です。

<lightning-record-edit-form object-api-name="Contact">
    <lightning-input-field field-name="AccountId"></lightning-input-field>
</lightning-record-edit-form>

editForm.html

JavaScriptの記述をほとんど必要とせず、HTMLだけで「Salesforce標準のようなルックアップ機能」を即座に実装できる手軽さが最大のメリットです。

使い分けのポイント

これまで見てきた通り、これら2つのコンポーネントは「どちらかが優れている」というわけではなく、「何を実現したいか」という目的によって選ぶべきコンポーネントが決まります。判断基準を一覧表にまとめました。

機能・特徴	lightning-record-picker	lightning-record-edit-form
最近参照したレコード	表示されない	表示される
検索範囲の絞り込み	JSで動的に制御可能	オブジェクト設定に従う
高度な検索	非対応	対応
検索項目の指定	自由（2項目まで設定可能）	標準の検索レイアウトに従う
実装のスタイル	HTML + JS（詳細設定が必要）	基本HTMLのみ（手軽）

1. どちらを採用すべきか？

「lightning-record-picker」が最適なケース
　・【柔軟な検索】動的に検索結果を絞り込みたい場合
　　pickerならfilter属性ひとつで実装可能です。

　・【柔軟な検索軸の設定】 Name項目以外で検索させたい場合
　　matching-infoを使い、電話番号や顧客番号などを検索対象に据えることができます。

　・【UIパーツとしての利用】レコード保存が目的ではない場合
　　選択したIDを使って、グラフ更新や計算に利用する「ツール的な画面」に向いています。

「lightning-record-edit-form」が最適なケース
　・【入力負荷の軽減】「最近参照したレコード」から選ばせたい場合
　　ユーザーが直近で作業したレコードを即座に選択できるため、入力の手間を大幅に省けます。

　・【メンテナンス性の向上】Salesforce側の設定（メタデータ）を活用したい場合
　　ヘルプテキストや必須設定など、Salesforce側での変更がプログラムの修正なしで即座に画面へ反映されます。

　・【標準UIの提供】高度な検索など「いつもの操作感」が必要な場合
　　「高度な検索」ダイアログを含め、Salesforceの標準ルックアップと同じ体験をユーザーに提供したい場合に最適です。

さいごに

いかがでしたでしょうか。
LWCでレコード選択機能を実装する際、以前は「lightning-record-edit-form」を使用するのが一般的でしたが、「lightning-record-picker」という選択肢が増えたことで、より要件に合わせた柔軟な開発が可能になりました。

・「検索項目のカスタマイズ」や「動的なフィルタリング」など、特定の条件に絞った高度な検索UIを作りたいなら「lightning-record-picker」
・「最近参照したレコード」や「高度な検索」など、標準の利便性をそのまま提供したいなら
「lightning-record-edit-form」

このように、それぞれの強みを正しく理解して使い分けることが、ユーザーにとって使いやすい画面を作る近道です。
今回ご紹介した機能差を参考に、ぜひ日々の開発で最適なコンポーネントを選んでみてください！