適切な検索ソリューションの選択
学習の目的
この単元を完了すると、次のことができるようになります。
- どのような場合にカスタマイズした検索ソリューションを作成するかを説明する。
- SOSL と SOQL の相違点を説明する。
- 検索に使用できる API プロトコルを特定する。
Salesforce 流の検索
最もよく使用される Salesforce 機能は何か知っていますか? そう、検索です。検索とは、何千件ものデータの中からユーザーが求める 1 つのレコードを見つけるための手段です。
Trailhead のこのモジュールでは、Salesforce 検索のしくみの概要と、カスタム検索ソリューションが適しているかどうかを判断する方法について学習します。また、数種の一般的なユースケースについて、Salesforce API を使用してカスタムソリューションを作成 (または再作成) する方法も習得します。最後に、検索クエリを最適化して、より絞り込んだ関連性の高い結果を得る方法を確認します。つまり、このモジュールを修了すると、検索と、それがユーザーの生産性向上にどのように役立つかについて、理解を深めることができます。
まず始めに、検索全体のしくみについて説明します。
すべてのレコードは、組織のデータベース内にデータ項目として保存されています。レコードを更新または作成すると、検索エンジンが連動してデータのコピーを作成し、コンテンツをトークンと呼ばれる小さな要素に分割します。これらのトークンは、元のレコードへのリンクと共に検索インデックスに保存されます。
ユーザーの観点から見ると、検索プロセスはレコードが作成されるときと似ています。ユーザーが検索項目に検索語を入力すると (1)、検索エンジンが検索語をトークンに分割します (2)。そして、それらのトークンを検索インデックスに保存されているレコード情報と照合し (3)、関連するレコードを関連性によってランク付けし (4)、ユーザーがアクセスできる結果を返します (5)。
ここで、検索インデックスについて考えてみましょう。組織のデータベースを検索できるのに、なぜわざわざトークンを作成するのでしょう。その理由は、検索インデックスではどの結果をユーザーに返すかが極めてスマートな方法で決定されるためです。
検索インデックスとトークンを使用することによって、検索エンジンは、スペル修正、ニックネーム、見出語化、シノニムグループなどの高度な機能を適用することができます。これらの機能を使用することで、ユーザーの検索語のバリエーションが含まれるレコードも表示して、検索結果の幅を広げることができます。(ところで、見出語化 (lemmatization) は、ふわふわした動物のレミング (lemming) とは何の関係もありません。見出語化とは、検索結果内の検索語のバリエーション (add、adding、added など) を識別して返すことです。)
また、検索インデックスによって、関連性ランキングを導入することができます。こうすれば、ユーザーが探しているレコードを見つけて順位を付けることができます。この処理には、検索語の頻度、順序、ユニーク性、レコードアクティビティ、アクセス権限、その他の要素が必要です。
比較してみましょう。「bunny slippers (ウサギのスリッパ)」のデータベース検索では、「bunny slippers」と完全一致するレコードのみが返されます。他方、検索インデックスを使用した場合は、「bunny slippers」を含むレコードも返されます。けれども、「rabbit slippers」や「bunny slipper」(単数形) などの類似する語句を含むレコードも表示されます。さらに、「slippers bunny」と入力したり、bunny のスペルを間違えたとしましょう (そういうことも起こり得ます)。その場合も、順不同一致とスペルチェックによって、関連する結果が表示されます。そして、すべての結果は、検索を実行した個々のユーザーへの関連性の順に表示されます。
こんなふうに思われているかもしれません。「Salesforce の標準検索は優れているように思える (実際にそうです) し、ほとんどのユースケースでうまくいくのに、どのような場合にカスタムソリューションが必要になるのか?」
一般的には、カスタム検索ソリューションが必要になるのは、組織で標準の Salesforce UI の代わりにカスタム UI が使用されている場合です。自家製 UI の例は、顧客向けの知識ベースや従業員向けの社内商品データサイトなどです。ただし、カスタムユーザーインターフェースの構築は、誰にでも適したものではなく、追加作業が必要です。幸いにも、カスタム検索を使用すれば、Salesforce 検索の高度な機能の一部を利用できます。ですから、会社がカスタム UI を構築することを決定し、カスタム検索が必要な場合は、このモジュールを学習してください。
Salesforce 検索の基礎を説明したので、次はカスタム検索ソリューションでレコードを見つけるための API について説明します。
API を使用した検索への接続
2 つの主な API について覚えておく必要があります。(他の 2 つの API については後ほど説明します。)
- Salesforce Object Query Language (SOQL)
- Salesforce Object Search Language (SOSL)
SOQL と SOSL の両者とも、指定された API 内でテキストクエリの形式を設定するものですが、似ているのはそこまでです。SOQL クエリは、SQL の SELECT ステートメントと同等で、組織のデータベースを検索します。一方、SOSL は、プログラムによって検索インデックスに対するテキストベースの検索を実行する方法です。SOSL では、前述した検索インデックスの優れた機能をすべて使用します。
SOQL と SOSL は構文も異なります。参考に、「リソース」セクションの開発者向けドキュメントへのリンクが記載されています。ここでは、SOQL または SOSL を選択する状況に関するガイドラインを示します。
データがどのオブジェクトまたは項目に存在しているかがわかっていて、次のことを実行したい場合は、SOQL を使用します。
- 1 つのオブジェクトまたは互いに関連付けられている複数のオブジェクトからデータを取得する。
- 指定した条件を満たすレコード数を数える。
- クエリの一部として結果を並び替える。
- 数値、日付、またはチェックボックス項目からデータを取得する。
データがどのオブジェクトまたは項目に存在しているかが不明で、次のことを実行したい場合は、SOSL を使用します。
- 項目内に存在することがわかっている、特定の語のデータを取得する。SOSL は 1 つの項目内の複数の語をトークン化してそこから検索インデックスを構築できるので、SOSL 検索ではより高速でより多くの関連する結果を返すことができます。
- 相互に関連している、または関連していない複数のオブジェクトおよび項目を効率的に取得する。
- ディビジョン機能を使用して、組織の特定のディビジョンのデータを最も効率的な方法で取得する。
次に、さらに 2 つの API 種別を見ていきましょう。
1 つ目は、推奨レコード API です。推奨レコードは、自動推奨、インスタント結果、先行入力と称されることもあります。その動作にも馴染みがあるでしょう。最高に格好良いランニングシューズを販売している Web サイトを使用しているとします。そのサイトでは、ランナーのコミュニティを促進するために、知識ベースにカスタマイズされた Salesforce 検索ソリューションが使用されています。あなたはトレイルランニングにどの靴を購入すればよいか知りたいと思っています。検索バーに「trail running」(トレイルランニング) と入力し始めると、タイトルに検索語を含む記事の選択肢が表示されます。
検索ボックスは、あなたが何を読みたいか正確に知っていました!
Search Suggested Records および Search Suggested Articles REST メソッドを使用すれば、これと同じようにユーザーを即座に満足させることができます。このメソッドの使用方法については後ほど詳しく説明します。
Salesforce 内でレコードを検索する方法について説明してきましたが、ユーザーが業務のためにアクセスするレコードが Salesforce の外部に保存されている場合はどうなるでしょうか? もちろんソリューションが用意されています。Salesforce 統合検索です。これはユーザーが Salesforce 外に保存されている項目を検索するための新しい方法で、Salesforce Classic、Salesforce コンソール、Lightning Experience を開いたまま実行できます。
Salesforce 統合検索を使用すれば、グローバル検索ボックスが外部検索エンジンになります。Salesforce 統合検索が設定されていると、ユーザーのクエリは外部エンジンに転送され、そこで外部ソースが検索されます。結果は、Salesforce 検索結果に直接返されます。この機能は、Salesforce 統合検索コネクタを通じて実現されます。コネクタは OpenSearch 仕様を用いて構築されているため、この業界標準に準拠する任意の検索エンジンに接続できます。
Salesforce 統合検索では、Salesforce 検索インデックスが使用されないため、Salesforce のさまざまな便利で高度な機能は適用されないことに留意してください。代わりに、結果は外部検索プロバイダーに従って返されます。それもまた便利ですね。
次に、プロトコルを使用して SOSL クエリと SOQL クエリを送信する方法を見ていきます。
プロトコルを使用したクエリの送信
いくら素晴らしい検索クエリを書いたとしても、REST、SOAP、Apex といった API プロトコルを使用して実際に送信しなければ何の役にも立ちません。
プロトコルと API には相性があります。ここでは全般的に、SOQL によるクエリと SOSL による検索について説明します。
- Query (REST) と query() (SOAP) — 指定されたオブジェクトに対して SOQL クエリを実行し、指定された条件に一致するデータを返します。
- Search (REST) と search() (SOAP) — 組織のデータに対して SOSL テキスト文字列検索を実行します。
レコード、記事、クエリの自動推奨など、その他の一般的な検索タスクを実行するリソースも使用できます。そして、SOSL や SOQL を使用したくない場合は、REST で Parameterized Search を使用することを検討します。その場合、URL 内で検索文字列を使用する代わりに、URL 内でパラメーター (名前はここから来ています) を使用します。
Apex では、ステートメントを角括弧で囲んで、SOQL または SOSL をその場で使用できます。また、Search クラスを使用して動的 SOSL クエリを実行したり、Search 名前空間を使用して検索結果や推奨結果を取得したりできます。
「リソース」セクションに、便利なリストがあります。さらに、次の単元では、作業を開始できるように、プロトコルの使用方法についての概要を説明します。開発者用ドキュメントをよく読んで、すべての情報や例について把握してください。
リソース
- SOQL および SOSL リファレンス
- REST API 開発者ガイド
- SOAP API 開発者ガイド
- Apex 開発者ガイド
- Salesforce ヘルプ
- Federated Search Developer Guide (統合検索開発者ガイド)