はじめに

Salesforceで「一覧画面でもっと柔軟に検索したい」「複数条件で絞り込める検索画面をコードなしで作りたい」と思ったことはありませんか。

標準のリストビューは、ユーザーが自由に条件を変えるには編集権限が必要で、項目をまたいだ柔軟な検索も得意ではありません。かといってLWCで検索画面をスクラッチ開発するのは工数がかかります。

そこで役に立つのが、Salesforce Labs製の無料パッケージ Record Hunter です。

本記事では、Record Hunterの概要・インストール方法・できること・注意点に加えて、公式ドキュメントに記載のない挙動を実機検証とソースコードの両面から詳細に解説します。

本記事の対象

Record Hunterには複数のコンポーネントが含まれますが、本記事では以下の2つのコンポーネントに絞って解説します。

Search Box (Deprecated) … 検索条件の入力と検索の実行
Data Table with Flow (Deprecated) … 検索結果の一覧表示

RHG - から始まる現行世代のコンポーネント群については、別記事で扱う予定です。

検証環境

項目	内容
パッケージバージョン	Record Hunter G / v2.26（2.26.0）
名前空間プレフィックス	`RHG`
パッケージ種別	1GP マネージドパッケージ
UI	Lightning Experience（アプリケーションページに配置）

記載内容は上記バージョンでの実機検証と、SalesforceLabs/record-hunter の公開ソースコードに基づいています。バージョンによって挙動が変わる可能性はあるため、導入時はご自身の環境でご確認ください。

第1章：Record Hunterとは

概要

Record Hunterは、Salesforceのレコード検索を強化するための無料パッケージです。Lightningアプリケーションビルダーにコンポーネントを配置してプロパティを設定するだけで、任意のオブジェクトに対するカスタム検索画面をノーコードで構築できます。

リスティングで挙げられている主な特徴は次の3点です。

特徴	内容
カスタマイズ可能な検索画面	複雑なクエリを書かずに、任意のオブジェクトを対象とした検索画面を管理者が構築できる
関連レコードの表示	検索結果と関連レコードを同一画面で参照・更新でき、ページ遷移を減らせる
高度なフィルタと検索ロジック	AND / OR を組み合わせた条件ロジックを設定でき、狙った絞り込みができる

パッケージの基本情報

導入判断に必要な情報を整理します。

項目	内容
提供元	Salesforce Labs
価格	完全無料（Never requires payment）
種別	Component
対応エディション	Enterprise / Unlimited / Force.com / Developer
要件	Platform Cloud
対応言語	英語のみ
パッケージが追加するもの	カスタムオブジェクト 0 / カスタムタブ 0 / カスタムアプリ 0
Lightningコンポーネント	Global 9 / App Builder 3 / Community Builder 3
初回公開	2019/08/22
最新リリース	2025/11/13
セキュリティレビュー	最終レビュー対象バージョン 1.7.0（2019/08/03）
分類	Non-SFDC Application

注目すべきポイント

✅ カスタムオブジェクト・タブ・アプリを一切追加しません。 組織のメタデータを汚さずに導入できるため、試しやすいパッケージです。
⚠️ Professional Edition は対応外です。 導入検討時の最初の確認事項になります。
⚠️ 対応言語は英語のみです。プロパティ名やコンポーネント内の一部メッセージは英語のままになります（後述）。

Salesforce Labs製であることの意味

リスティングのProvider Detailsには、Salesforce Labsの位置づけが明記されています。要点は以下の通りです。

Salesforce Labsは、salesforce.comのエンジニアや従業員が作成したアプリをコミュニティに共有するプログラム
無料で使えるが、salesforce.comの公式製品ではなく、コミュニティプロジェクトとして扱うべきもの
公式なテストもドキュメント化もされていない
困った場合はSalesforceのメッセージボードに相談する形で、salesforce.comのサポートは利用できない

さらにSecurity欄では Non-SFDC Application と分類され、品質やセキュリティについて保証しない旨が記載されています。

業務で使う場合は、この前提を許容できるかを最初に判断してください。 不具合が起きてもSalesforceサポートには問い合わせられません。

なぜソースコードを読むのか

Record HunterのWikiには、まだ整備されていないページが存在します。

Installation Guide の「Prerequisites」「Post-Installation Setup」は TBD
Component Breakdown の各Features項目は見出しのみ
FAQ & Troubleshooting は見出しのみ
Version History は TBD

そのため、細かい挙動は実機で試すか、GitHubのソースコードを読むしかありません。本記事はその両方を行った結果をまとめたものです。

なお、GitHubでソースが公開されているのは仕様理解に非常に役立ちますが、インストールされるのはマネージドパッケージ（名前空間 RHG）なので、ApexやJavaScriptを組織側で改修することはできません。 ソースは「仕様書の代わり」として読む、という位置づけになります。

第2章：インストール方法

手順

AppExchangeのRecord Hunterページにアクセス
「Get It Now」 をクリック
インストール先の組織にログインし、画面の指示に従う
インストールユーザーの範囲を選択して 「インストール」 をクリック

選択肢は以下の3つです。

選択肢	内容
管理者のみのインストール	システム管理者プロファイルのユーザーのみが利用可能
すべてのユーザーのインストール	全ユーザーが利用可能
特定のプロファイルのインストール	プロファイル単位でアクセスレベルを指定

インストール前に試せる

リスティングには 「Try It」（テストドライブ）が用意されています。自組織にインストールする前に挙動を確認できるので、導入判断の材料として活用できます。

インストール後に必要な設定

権限セットの割り当ては不要です。
ただし、検索対象がカスタムオブジェクトの場合、利用ユーザーにそのオブジェクトの参照権限と項目レベルセキュリティが必要です。権限がない項目は検索条件として表示されません（詳細は第9章）。

インストールの確認

Lightningアプリケーションビルダーのコンポーネントパレットで、以下の8つが表示されていればインストール成功です。

Data Table with Flow (Deprecated)
Location Filter (Deprecated)
RHG - Action Buttons
RHG - Filter
RHG - List
RHG - Map Filter
RHG - Search
Search Box (Deprecated)

「Deprecated」について

名前に (Deprecated) が付いた3つは旧世代のコンポーネントです。新規構築では RHG - から始まる現行世代のコンポーネントを使うことが推奨されます。

本記事が旧世代を扱うのは、既存実装の保守や、旧世代特有の挙動を把握したいケースがあるためです。新規で作る場合はRHGシリーズを検討してください。

第3章：2つのコンポーネントのプロパティ一覧

Search Box (Deprecated)

検索条件の入力欄を表示し、検索を実行するコンポーネントです。検索ボタンを自前で持っているため、これ単体で検索を実行できます。

プロパティ	必須	内容
Title		カードヘッダーに表示するタイトル
Target Object	✅	検索対象オブジェクトのAPI参照名（カスタムオブジェクトは `__c` 付き）
Field Names		検索条件として表示する項目のAPI参照名。カンマ区切り
Search Button Label	✅	検索ボタンの表示ラベル
Number of Columns		条件入力欄の列数（12の約数のみ選択可）
Show Object Names		項目ラベルにオブジェクトラベルを併記する
Show Field Indexes		項目ラベルの先頭に連番を表示する（Custom Logicで使う番号）
Fold Conditions by Default		初期表示で条件エリアを折りたたむ
Section Headers		条件エリアの見出し。カンマ区切りで6項目ごとに対応（第8章）
Default Values or Field Names		各入力欄の初期値。カンマ区切り（第7章で詳述）
Custom Logic		条件をAND / ORでどう結合するかの論理式（第6章）
Order	✅	実行順序。結果の受け渡しに使う（第4章）

Data Table with Flow (Deprecated)

検索結果を一覧表示するコンポーネントです。

プロパティ	必須	内容
Title		カードヘッダーに表示するタイトル
Target Object	✅	対象オブジェクトのAPI参照名
Column Fields	✅	一覧の列として表示する項目のAPI参照名。カンマ区切り
Table Height	✅	テーブルの高さ（px）。既定 500
Page Size	✅	一度に取得するレコード件数。既定 50
Label for True	✅	チェックボックス項目が true のときの表示文字。既定 `true`
Label for False	✅	チェックボックス項目が false のときの表示文字。既定 `false`
Flow Names		呼び出すフローのAPI参照名
Flow Labels		Flow Namesに対応する表示ラベル
Flow Input	✅	フローへの入力形式（`RECORD` / `ID`）
Order	✅	実行順序

本記事ではフロー連携機能（Flow Names / Flow Labels / Flow Input）は扱いません。 検索結果の表示のみを目的とした構成を前提に解説します。

なお、フローを設定していない場合、一覧の行選択チェックボックス列は表示されません。 これはソースコード上、チェックボックス列の表示がフロー設定の有無に連動しているためです。

第4章：2つのコンポーネントが連携する仕組み

Record Hunterで最もつまずきやすいのがここです。「検索しても結果が表示されない」の多くはOrder設定が原因です。

処理の流れ

1. Search Box の Field Names で指定した項目
   → 検索条件の「入力欄」として画面に表示される

2. 検索ボタンをクリック
   → 条件に一致するレコードを検索し、「レコードIDの配列」だけを取得

3. IDの配列を SearchResult というアプリケーションイベントで
   ページ全体にブロードキャストする

4. Data Table with Flow がそのイベントを受け取り、
   自身の Column Fields の設定を使ってレコードを再取得して列表示する

イベントの定義は次のようになっており、渡されているのはレコードIDの配列と送信元のOrder値だけです。

<aura:event access="global" type="APPLICATION" description="Record Hunter's Search Result Event">
    <aura:attribute access="global" type="String[]" name="recordIds" />
    <aura:attribute access="global" type="String" name="origin" />
</aura:event>

ここから導かれる重要な結論があります。

「検索条件に使う項目（Field Names）」と「一覧に表示する列（Column Fields）」は完全に独立した設定です。

検索条件に指定した項目が自動的に列として表示されるわけではありません。両方に表示したい項目は、両方のプロパティに書く必要があります。

Orderは「検索側 + 1 = 表示側」

Data Table側は、受け取ったイベントの送信元Order値が 自分のOrder - 1 と一致する場合のみ処理します。

onSearchResultEvent: function(c, e, h) {
    const order = parseInt(c.get('v.order'));
    const origin = e.getParam('origin');
    if (origin + 1 === order) {   // ← 一致しないと結果を受け取らない
        const recordIds = e.getParam('recordIds');
        c.set('v.recordIds', recordIds);
        c.find('datatable').setRecordIds(recordIds);
    }
},

したがって、正しい設定は次の通りです。

コンポーネント	Order
Search Box (Deprecated)	1
Data Table with Flow (Deprecated)	2

Orderがズレたときの挙動（実機検証）

Data Table側のOrderを 2 から 3 に変更して検索ボタンを押すと、次のようになります。

エラーメッセージは一切表示されない
検索条件を空にしても 0件のまま（本来なら全件表示される）

つまり、設定ミスに気づく手がかりが「結果が0件」しかありません。 結果が出ないときは、まずOrderを疑ってください。

同じページに検索処理を2セット配置したい場合は、Orderの系列を分けます（例：1と2の組、4と5の組）。

第5章：検索条件の指定方法（Field Names）

基本

Field Names に、検索条件として表示したい項目のAPI参照名をカンマ区切りで指定します。

Name,Amount,CloseDate,StageName

指定した順に入力欄が並び、Number of Columns で指定した列数でレイアウトされます。

参照関係（Lookup）項目はドット記法が必須

参照関係項目をそのまま指定すると、エラーになります。

The type 'REFERENCE' for 'AccountId' of 'Opportunity' is unsupported.

参照関係項目は内部的には関連レコードのID（18桁）を保持しているだけで、画面上で見えている「取引先名」は関連先レコードの表示ラベルです。検索したいのは名前（テキスト）なのに、項目が持っているのはIDなので、そのままでは条件になりません。

対処法は、ドット記法で参照先の項目まで指定することです。

❌ AccountId          → エラー
✅ AccountId.Name     → 取引先名で検索できる

この記法は Column Fields（表示列）でも同様に必要です。Data Table側でも同じ型チェックが働くため、ドットなしで指定すると同じエラーになります。

多階層のドット記法も使える

ドットは何段でも辿れます。

AccountId.CreatedById.Name    → 取引先の作成者の氏名で検索

参照先オブジェクトを明示する `:` 記法

WhoId や WhatId のように複数のオブジェクトを参照できる項目（多態参照） では、どのオブジェクトを辿るかを : で指定できます。

Status,WhoId:Contact.Name

上記をTaskオブジェクトに指定すると、「状況」の選択リストと「取引先責任者の名前」のテキスト入力欄が表示されます。

この記法は公式Wikiに記載がありません。 多態参照項目を検索条件にしたい場合に有効です。

検索条件に使えないデータ型

以下のデータ型は、検索条件として明示的にサポート対象外です。指定すると is unsupported エラーになります。

内部型	Salesforce上の表記
`REFERENCE`	参照関係 / 主従関係（→ ドット記法で回避可能）
`ADDRESS`	住所（複合項目）
`COMBOBOX`	コンボボックス
`ANYTYPE`	anyType
`BASE64`	Base64
`DATACATEGORYGROUPREFERENCE`	データカテゴリグループ参照
`ENCRYPTEDSTRING`	暗号化されたテキスト
`LOCATION`	位置情報（複合項目）

実際に踏みやすい例1：住所の複合項目

取引先の「請求先住所」をそのまま指定するとエラーになります。

The type 'ADDRESS' for 'BillingAddress' of 'Account' is unsupported.

回避策は、構成項目を個別に指定することです。 以下は問題なく動作します。

Name,BillingCity,BillingPostalCode

実際に踏みやすい例2：ToDoの「件名」

ToDo（Task）の「件名」は COMBOBOX 型のため、検索条件に使えません。

The type 'COMBOBOX' for 'Subject' of 'Task' is unsupported.

もう1種類ある別のエラー：queryable でない項目

型のサポート以前に、そもそもSOQLの条件に使えない項目を指定した場合は別のエラーが出ます。リッチテキストエリア項目などが該当します。

The type 'MyRichText__c' of 'Opportunity' is not a queryable field.

⚠️ このエラーメッセージには注意点があります。 文面は The type '...' となっていますが、実際に表示されるのは項目のAPI参照名です（データ型ではありません）。パッケージ側のメッセージの作りによるものなので、「type」と書かれていても項目名として読んでください。

なお、数式項目はエラーにならず、通常の条件として使えます。

項目名を間違えたときのエラー

存在しない項目名を指定すると、そのオブジェクトの有効な項目名がすべて列挙されたエラーが表示されます。

'accountid' of 'MyObject__c' is not a valid field. Valid fields are id, ownerid, isdeleted, name, ...

API参照名を調べる手段としては便利ですが、実際のページではこれがトースト通知として表示されます。内部の項目名が一覧で出てしまうため、設定ミスを本番環境に持ち込まないよう注意してください。

第6章：一致方針と条件の結合ルール

Search Boxには2種類の検索欄があり、一致方針が異なります。ここを理解していないと「検索できない」という問い合わせにつながります。

種別	画面上の位置	内部の検索方式	一致方針
キーワード検索	検索ボタン横の入力欄	SOSL（全項目横断の全文検索）	部分一致
項目検索	項目ごとの入力欄	SOQL（`WHERE`句）	デフォルトは完全一致

項目検索はデフォルトで完全一致

直感に反しやすいポイントです。テキスト系の項目は、何も装飾せずに入力すると完全一致になります。部分一致にするには、半角のアスタリスク（*） を自分で付けます。

入力例	生成される条件	一致方針
`株式会社サンプル`	`= '株式会社サンプル'`	完全一致
`サンプル`	`LIKE '%サンプル%'`	部分一致（前後どちらも）
`サンプル*`	`LIKE 'サンプル%'`	部分一致（前方一致）
`*サンプル`	`LIKE '%サンプル'`	部分一致（後方一致）

⚠️ 全角の「＊」ではなく、必ず半角の * を使ってください。全角では判定されず、その文字を含む文字列との完全一致として扱われます。

全角・半角の扱い（実機検証）

Record Hunter自体は入力値を変換しませんが、Salesforce基盤側の文字照合により、一部は同一視されます。 実際に検証した結果は次の通りです。

検索入力	データ側	結果
`ＡＢＣ`（全角英字）	`ABC`	ヒットする
`１２３`（全角数字）	`123`	ヒットする
`abc`（小文字）	`ABC`	ヒットする（大文字小文字は区別されない）
`ＡＢＣ`（全角スペース）	`A B C`	ヒットする
`ＡＢＣ`（全角＋部分一致）	`ABC`	ヒットする（`LIKE` でも同様）
`ｱｲｳ`（半角カナ）	`アイウ`	ヒットしない
`アイウ`	`ｱｲｳ`（半角カナ）	ヒットしない
`あいう`（ひらがな）	`アイウ`	ヒットしない

まとめると、英数字とスペースの全角・半角、および大文字小文字は区別されませんが、カナの全角・半角、ひらがなとカタカナは別扱いになります。

日本語環境では半角カナの混入が問題になりやすいので、データ登録時に表記を統一するルールを設けるのが現実的な対策です。パッケージはマネージドのため、コード側で正規化することはできません。

データ型ごとの入力欄と一致方針

データ型	入力欄	一致方針
テキスト / メール / URL / 電話 / ロングテキストエリア / ID	1つ（テキスト）	完全一致（`*` で部分一致）
数値 / 通貨 / パーセント	2つ（min / max）	範囲指定（以上・以下）
日付	2つ（From / To の日付ピッカー）	範囲指定
日付/時間	2つ（日時ピッカー）	範囲指定
時間	2つ	範囲指定
選択リスト	ドロップダウン（先頭に空の `-`）	完全一致
複数選択リスト	複数選択UI	選択した値を含む
チェックボックス	チェックボックス	後述

日付項目は単一日付での完全一致ができません。 必ずFrom / Toの範囲指定になります（片方だけの入力も可能です）。

チェックボックス項目は「false検索」ができない

実機検証の結果、次の挙動になります。

操作	結果
チェックを入れずに検索	その条件は無視される（チェックあり・なし両方のレコードがヒット）
チェックを入れて検索	チェックあり（true）のレコードのみヒット

つまり「チェックが入っていないレコードだけを検索する」ことはできません。 これは仕様なので、false側を絞りたい場合は選択リスト項目で設計するなどの回避が必要です。

未入力の条件は自動的に無視される

値を入れていない条件欄は、条件から自動的に除外されます。使いたい条件だけ入力すればよい作りです。

そして、有効な条件が1つもない場合は WHERE 句なしのクエリになり、全件が返ります。

条件の結合ルール（Custom Logic）

Custom Logic が未指定の場合、内部で以下の論理式が自動生成されます。

0 AND 1 AND 2 AND 3 ...

0 は「キーワード検索」を指す予約番号
1 以降は Field Names に指定した項目の番号（指定順に1から連番）

項目の番号は、Show Field Indexes を有効にすると画面のラベル先頭に表示されるので、それを見ながら組み立てられます。

OR条件やカッコを使いたい場合は、Custom Logic に論理式を書きます。

0 OR 1
1 AND (2 OR 3)

⚠️ 最重要の落とし穴：0 を書き忘れるとキーワード検索が無効になる

Custom Logic を手動で指定すると、自動生成が行われなくなります。そのため 0 を含めない論理式を書くと、キーワード欄に入力してもキーワード条件が完全に無視されます。

実際に Custom Logic を 1 OR 2 に設定し、どのレコードにも一致しないキーワードを入力して検索したところ、全件がヒットしました（キーワード条件が無視され、かつ項目条件も未入力だったため、条件なしのクエリになった）。

キーワード検索も併用したい場合は、必ず 0 を論理式に含めてください。

第7章：最大の罠「Default Values or Field Names」

これは知らないと必ずハマるポイントです。

プレースホルダーではありません

Default Values or Field Names は、入力ヒント（プレースホルダー）を設定するプロパティではありません。各入力欄の「初期値」＝実際に検索される値を設定するプロパティです。

Search Boxのキーワード入力欄には、そもそもプレースホルダーを設定する仕組みが実装されていません。

何が起きるか

たとえば入力例を表示するつもりで、以下のように設定したとします。

検索したい名称を入力してください（部分一致可）

すると、1つ目の値は必ずキーワード欄の初期値になるため、検索実行時に以下のような全文検索が走ります。

FIND '検索したい名称を入力してください（部分一致可）' IN ALL FIELDS RETURNING Opportunity (Id ORDER BY Id)

当然この文字列を含むレコードは存在しないので、何をしても検索結果が0件という状態になります。

対処法は、この欄を空欄にすることです。 入力例を案内したい場合は、Title に含める、ページ内にリッチテキストコンポーネントを置く、項目ラベル自体を工夫する（例：「取引先名（完全一致）」）といった方法を取ります。

値の消費ルールが型によって違う

もう一つの罠です。カンマ区切りの値は位置で対応するのですが、消費される個数がデータ型によって異なります。

対象	消費する値の数
キーワード欄	常に1つ（先頭の値）
数値 / 通貨 / パーセント / 日付 / 日付時間 / 時間の項目	2つ（min と max）
上記以外の項目	1つ

実際に検証してみます。Field Names の2番目に日付項目がある構成で、次のように設定します。

,,2026-01-01,2026-12-31

結果は次のようになります。

値の位置	入る先
1つ目（空）	キーワード欄
2つ目（空）	1番目の項目（テキスト欄）
3つ目 `2026-01-01`	日付項目の From
4つ目 `2026-12-31`	日付項目の To

日付項目が2つ分の値を消費するため、それ以降の項目の位置が1つズレます。 数値や日付を含む構成で初期値を設定する場合は、この点に注意してください。

なお、項目レベルセキュリティで非表示になった項目も値を消費します（表示されないのに位置は消費される）。ユーザーによって初期値の入る位置が変わる可能性があるため、権限差があるユーザーが使う画面では特に注意が必要です。

第8章：検索条件エリアのレイアウト

Section Headers は「6項目ごと」

Section Headers はカンマ区切りで複数の見出しを設定できますが、適用される単位は6項目ごとに固定されています。このグループサイズは設定で変更できません。

見出しの位置	対応する項目
1つ目	1〜6項目目の上
2つ目	7〜12項目目の上
3つ目	13〜18項目目の上

実機で Field Names に7項目を指定し、Section Headers に A,B と設定したところ、B は7項目目の上に表示されました。

「3項目ごとに見出しを付けたい」といった細かい制御はできないため、見出しで区切りたい単位に合わせて、6項目単位になるよう項目の並び順を設計する必要があります。

Number of Columns は12の約数のみ

内部的に「12 ÷ 指定列数」でレイアウト幅を計算しているため、選択できるのは12の約数（1・2・3・4・6・12）だけです。実際に 5 は設定できません。

Fold Conditions by Default

有効にすると、初期表示で条件エリアが折りたたまれます。キーワード欄の左に表示されるボタンで、ユーザーが展開・折りたたみを切り替えられます。条件項目が多い画面では、有効にしておくと画面がすっきりします。

Show Object Names

有効にすると、項目ラベルの後ろにオブジェクトラベルが併記されます。ドット記法で他オブジェクトの項目を条件にしている場合、どのオブジェクトの項目か区別しやすくなります。

第9章：エラー表示と権限まわりの挙動

エラーの表示方法が画面によって違う

同じエラーでも、表示のされ方が2通りあります。

状況	表示方法
アプリケーションビルダーで編集中	コンポーネント内に赤いエラーボックス
実際のページ（利用者が見る画面）	トースト通知（自動では消えない）

設定ミスの検証はアプリケーションビルダー上で行うと確認しやすい一方、本番で設定ミスがあるとエンドユーザーにトースト通知が出てしまいます。 公開前に必ず実ページで動作確認してください。

項目レベルセキュリティで参照できない項目は「黙って消える」

実行ユーザーが参照権限を持たない項目は、エラーも表示されずに入力欄が消えます。

そのため、管理者には見えている条件欄が、一般ユーザーには存在しないという状態が起こり得ます。「一部のユーザーだけ条件欄が少ない」という問い合わせが来たら、まず項目レベルセキュリティを確認してください。

共有ルールは尊重される

パッケージ内のApexクラスはすべて with sharing で宣言されています。つまり共有設定を迂回してレコードが見えるようになることはありません。

ただし、これまで一覧では目にしなかったデータが検索で見つかるようになるため、運用開始前にアクセス権の設計を再確認することをおすすめします。

SOQLインジェクション対策

入力値には String.escapeSingleQuotes() が適用されており、シングルクォートによるインジェクションは考慮された実装になっています。

第10章：Data Table with Flow の表示仕様

列の設定

Column Fields に指定した項目が列として表示されます。ドット記法も使えます（AccountId.Name など）。Search Box の Field Names とは独立した設定です。

サポート対象外のデータ型は Search Box と共通です。参照関係項目をドットなしで指定すると同じエラーになります。

件数表示は「総ヒット件数」

カードヘッダーに表示される件数は、検索でヒットした総件数です（画面に読み込まれている行数ではありません）。

スクロールで追加読み込みされる

Page Size で指定した件数を初回に読み込み、テーブルを下までスクロールすると同じ件数ずつ追加読み込みされます。全件読み込むと自動的に停止します。

名前項目はクリックできる

オブジェクトの標準の名前項目（Name項目）はボタンとしてレンダリングされ、クリックするとそのレコードの詳細画面に遷移します。一覧から詳細へ移動する導線として使えます。

全列がソート可能・行番号が表示される

すべての列にソート機能が有効になっており、列ヘッダーをクリックして並び替えできます。また行番号列が表示されます。

データ型ごとの表示整形

データ型	表示
チェックボックス	`Label for True` / `Label for False` に指定した文字列
パーセント	パーセント書式（小数桁数は項目定義に従う）
時間	`HH:mm` 形式
日付/時間	年月日 + 時分
日付	日付書式

Label for True / Label for False を活用すると、true / false の代わりに「済」「未」などの表記にできます。

0件時のメッセージは英語固定

検索結果が0件のときは、警告アイコンと No Records Found というメッセージが表示されます。このメッセージは変更できません。 パッケージの対応言語が英語のみであることに起因します。

行選択チェックボックスはフロー設定時のみ

前述の通り、Flow Names を設定していない場合、行選択のチェックボックス列は表示されません。検索結果の表示のみを目的とする構成では、行を選択する操作はできません。

第11章：トラブルシューティングチェックリスト

検索結果が何も表示されない

Default Values or Field Names に説明文やヒントを入れていないか（入れると常に0件になる）
Search Box の Order + 1 = Data Table の Order になっているか（エラーは出ない）
Target Object のAPI参照名が正しいか（カスタムオブジェクトは __c が必要）
Column Fields に表示したい項目を設定しているか（Field Names とは別設定）
Custom Logic を手動指定している場合、意図した論理式になっているか

エラーが表示される

The type 'REFERENCE' ... is unsupported. → ドット記法（AccountId.Name）に修正
The type 'ADDRESS' ... is unsupported. → 住所の構成項目（BillingCity など）を個別に指定
The type 'COMBOBOX' ... is unsupported. → その項目は使用不可（例：Taskの Subject）
... is not a queryable field. → SOQL条件に使えない項目（例：リッチテキストエリア）
... is not a valid field. → API参照名の誤り。エラー文に有効な項目名が列挙される

特定の条件でヒットしない

部分一致したい場合、半角の * を入力しているか
参照項目の条件でヒットしない → 参照先レコードが紐付いているか（未設定のレコードはどんな条件でもヒットしない）
半角カナ・ひらがな/カタカナの表記ゆれがないか（英数字は同一視されるがカナは別扱い）
キーワードも使っている場合、Custom Logic に 0 が含まれているか
チェックボックス項目で false 側を絞ろうとしていないか（不可能）

ユーザーによって画面が違う

項目レベルセキュリティで参照不可の項目は、エラーなしで入力欄が消える

第12章：導入前に押さえておくべき注意点

#	注意点
1	Salesforceの公式サポート対象外。 Salesforce Labs製のコミュニティプロジェクトで、公式なテスト・ドキュメント化も行われていない
2	Professional Edition は対応外。 Enterprise / Unlimited / Force.com / Developer のみ
3	マネージドパッケージ（名前空間 `RHG`）なので、挙動をコードで変更できない。全角・半角の正規化などはデータ側の運用ルールで対応する必要がある
4	対応言語は英語のみ。プロパティ名や `No Records Found` などのメッセージは英語のまま
5	公式Wikiは整備途中。細かい挙動は実機検証かソースコードの確認が必要
6	検索条件に使えないデータ型がある。特に住所・位置情報の複合項目、コンボボックス
7	`(Deprecated)` 付きのコンポーネントである。新規構築では `RHG -` シリーズを検討する
8	セキュリティレビューの最終対象はバージョン 1.7.0（2019年）。最新リリースは2025年だが、レビュー済みバージョンは古い

一方で、カスタムオブジェクト・タブ・アプリを一切追加しないため、組織への影響が小さく試しやすいパッケージでもあります。まずは Sandbox か Developer Edition、あるいはリスティングの「Try It」で挙動を確認するのがおすすめです。

まとめ

Record Hunter の Search Box / Data Table with Flow は、ノーコードで実用的な検索画面を構築できる強力な組み合わせです。標準機能では実現しにくい柔軟な複数条件検索を、開発工数をほぼかけずに用意できます。

一方で、公式ドキュメントに記載のない挙動が多く、以下のポイントを知らないと確実にハマります。

Default Values or Field Names はプレースホルダーではない（入れると常に0件）
Order は「検索側 + 1 = 表示側」（ズレてもエラーが出ない）
参照関係項目はドット記法が必須（多階層・: によるオブジェクト指定も可能）
項目検索はデフォルト完全一致、部分一致には半角 * が必要
Custom Logic を手動指定するなら 0（キーワード条件）を忘れない
英数字の全角・半角は同一視されるが、カナは別扱い
チェックボックスで false 検索はできない
Section Headers は6項目ごと、Number of Columns は12の約数のみ

そして、挙動に疑問を持ったときにGitHubで実装を確認できるのが、このパッケージの大きな利点でした。マネージドパッケージなので改修はできませんが、「仕様書の代わり」として読めば十分に役立ちます。

同じところで悩んでいる方の助けになれば幸いです。

参考リンク