検索結果の最適化

検索クエリはコストが高くなる場合があります。検索対象のデータが多く、返す結果が多いほど、操作全体が遅くなります。

検索の遅さを解消するには、無駄のない効率的な検索クエリを定義します。それには、次の 2 つの戦略が関係しています。

• 検索対象となるデータを制限する
• 返されるデータを制限する

ただし、やりすぎもよくありません。効率を求めすぎると、検索が役に立たなくなります。ユーザは、レコードが存在するとわかっているのに「レコードが見つかりません」と表示されることを好みません。ユーザが怒るのを見たくはないものです。

うまく妥協点を見つけるために、次のことをお勧めします。まず、基本概念を理解するために SOSL の例から見てみましょう。

検索対象となるデータを制限するには、IN SearchGroup を使用します。名前、メール、電話番号、サイドバー、またはすべての項目を検索できます。たとえば、メールのみを検索したい場合は、メール項目のみを検索します。

FIND {jsmith@cloudkicks.com} IN EMAIL FIELDS RETURNING Contact

検索結果について説明します。ユーザは、すべての結果を表示したいと考えるものですが、何千件ものレコードがある場合は、その考え方を見直した方がよいでしょう。少なくとも、結果をより小さな、理解しやすいかたまりに分割する方法について考えましょう。

もう一度、SOSL に目を向けると、返されるデータを指定するには、RETURNING FieldSpec を使用できます。これは前の単元で使用しましたが、そこに含まれるより高度な要素について説明します。

• ObjectTypeName — 返すオブジェクトを指定します。
• FieldList — 返す項目を指定します。
• ORDER By — 結果を並び替える基準となる項目を指定します。昇順または降順も指定できます。
• LIMIT n — 指定のオブジェクトで返されるレコードの最大数を設定します。
• OFFSET n — クエリによって返される結果セットへの開始行オフセットを設定します。

多くの要素があってわかりにくいので、順を追って見ていきましょう。

FIND {Cloud Kicks} RETURNING Account

FIND {Cloud Kicks} RETURNING Account(Name, Industry)

FIND {Cloud Kicks} RETURNING Account (Name, Industry ORDER BY Name)

FIND {Cloud Kicks} RETURNING Account (Name, Industry ORDER BY Name LIMIT 10)

FIND {Cloud Kicks} RETURNING Account (Name, Industry ORDER BY Name LIMIT 10 OFFSET 25)

これで使い方がわかったため、次はいくつかの WITH ステートメントを試してみましょう。このステートメントでは、特定の定義済み項目によってレコードを絞り込みます。結果を事前に絞り込むことで、返される結果が少なくなり、パフォーマンスが向上します。さらに、ユーザが多くの結果に目を通す必要がなくなります。SOSL で使用できる WITH 条件の種類は、次のとおりです。

FIND {Cloud Kicks} RETURNING Account (Name, Industry)
    WITH DIVISION = 'Global'

FIND {race} RETURNING KnowledgeArticleVersion
    (Id, Title WHERE PublishStatus='online' and language='en_US')
    WITH DATA CATEGORY Location__c AT America__c

FIND {first place} RETURNING User (Id, Name),
FeedItem (id, ParentId WHERE CreatedDate = THIS_YEAR Order by CreatedDate DESC)
WITH NETWORK = '00000000000001'

Find {shoe} RETURNING Product2 WITH PricebookId = '01sxx0000002MffAAE'

話が見えてきましたでしょうか。SOQL でのこの機能のしくみを学習する準備ができたようですね。幸いにも、SOSL のそれとほとんど同じです。SOQL では、SOSL と同等のことを実現する SELECT を類似する構文で使用できます。データカテゴリまたはネットワークによる制限方法などの完全な構文のリストは、開発者ドキュメントに記載されています。説明したいくつかの構文を比較する便利な表を次に示します。

最初の単元で、レコードの自動推奨とトレイルランニングについての情報を検索するための高度な方法について説明したのを覚えていますか? その概念をもう一度取り上げ、詳しく見ていきましょう。

復習の後、API を使用して、ユーザが検索バーに入力したときに推奨が表示されるようにできます。推奨によって、ユーザが入力している内容とタイトルが一致するレコードが返されます。この機能により、ユーザは行きたい場所に早く移動できます。それこそが検索の本来の目的ですよね。

この機能を利用するために使用する REST リソースを次に示します。各リソースの構文とパラメータは似ていますが、使用事例に最適なものを使用してください。

• Search Suggested Records — ユーザの検索文字列に名前が一致する推奨レコードのリストを返します。推奨リソースは、ユーザが全文検索を実行する前に関連する可能性のあるレコードに直接移動できるショートカットを提供します。
• Search Suggested Article Title Matches — ユーザの検索クエリ文字列にタイトルが一致する Salesforce ナレッジ記事のリストを返します。ユーザが検索を実行する前に、関連する可能性のある記事に直接移動できるショートカットを提供します。
• SObject Suggested Articles for Case — ケースの推奨 Salesforce ナレッジ記事のリストを返します。

推奨のしくみの例として Search Suggested Article Title Matches を使用しましょう。基本構文は次のようになります。使用できるパラメータの完全なリストについては API ドキュメントを参照してください。

/vXX.X/search/suggestTitleMatches?q=search string&language=article language&publishStatus=article publication status

次に、その構文で具体的な例を使用します。要求は次のようになります。

/vXX.X/search/suggestTitleMatches?q=race+tips&language=en_US&publishStatus=Online

そして、JSON 応答は次のようになります。

{
  "autoSuggestResults" : [ {
    "attributes" : {
    "type" : "KnowledgeArticleVersion",
    "url" : "/services/data/v30.0/sobjects/KnowledgeArticleVersion/ka0D00000004CcQ"
    },
  "Id" : "ka0D00000004CcQ",
  "UrlName" : "tips-for-your-first-trail-race",
  "Title" : "race tips",
  "KnowledgeArticleId" : "kA0D00000004Cfz",
  "isMasterLanguage" : "1",
  } ],
  "hasMoreResults" : false
}

検索結果の最適化はチームスポーツのようなものです。幸いにも、誰に助けを求めればよいかわかっています。MVP システム管理者です。検索結果の強化において、簡単に得点するためのシステム管理者との連係プレーを次に示します。

最初のステップは、シノニムグループを設定し、最適化することです。シノニムグループには、検索において同等に扱われる語句が含まれます。シノニムグループのいずれか 1 つの用語を検索すると、グループ内のすべての用語に対する結果が返されます。たとえば、「USB」 を検索すると、シノニムグループ内のすべての用語、「USB」、「USB メモリ・フラッシュドライブ」、「フラッシュスティック」、「メモリスティック」の結果が返されます。シノニムグループの価値は、おそらくすでにおわかりでしょう。ユーザは、1 つの語を使用して検索した場合に、それが「正しい」検索語でなかったとしても、求める結果が得られます。商品の名前を変更する必要はありません。

メモ

Salesforce が提供する標準シノニムグループはデフォルトで有効になっています。

膨大な量 (正確には 9,586 個) のシノニムをインポートする必要がある場合は、参考資料セクションに記載されているメタデータ API を利用しましょう。一括アップロードが勝利への道です。

シノニムグループの処理が完了したら、次のステップは、ナレッジ記事の昇格済み検索語です。

昇格済み検索語は、よく使用される記事がより注目されるようにして、サポート問題を解決するのに役立ちます。設定は簡単です。システム管理者が最適な記事を見つけ、[昇格済み検索語] 関連リストに検索語を追加します。それらのキーワードをユーザが入力すると、検索結果の最上部に選択された記事が表示されます。

たとえば、サポートチームが、サイズが合わない靴を返品する方法についての完璧な記事を作成したとします。サポート記事のモナリサです。システム管理者は、その記事を更新して、「返品」と「サイズが合わない」の昇格済み検索語を含めました。ユーザがそれらの語を検索すると、記事がポップアップ表示されます。

システム管理者が昇格済み検索語を調整するためのヒントを次に示します。

• 1 語あたりの最大文字数は 100 文字です。ユーザの検索語を照合するときに最良の結果を得られるように、各昇格済み用語は数個のキーワードに制限します。
• やりすぎないようにしましょう。最良の結果を得るには、昇格済み用語を選択的に使用します。つまり、昇格済み用語および用語あたりの昇格済み記事の数を制限して作成します。昇格済み検索語を追加しすぎると、ユーザに対する関連性ランキングに影響を及ぼし、不要な結果につながります。組織で最大 2,000 個の昇格済み用語を作成できます。
• 用語内のすべてのキーワードがユーザの検索語に含まれていると、記事の検索は任意の順序で昇格済み用語と一致します。キーワードは、完全に一致する必要があります。

検索は、Salesforce の最も華々しい機能ではないかもしれませんが、最も頻繁に使用される機能です。

ここまでのいくつかのユニットで、検索の背後にある力を理解できたことでしょう (そして高く評価していると言ったら言い過ぎでしょうか?)。検索のアーキテクチャ、いくつかの一般的な使用事例に対して検索ソリューションを作成する方法、そして効率的な検索クエリを作成する方法を学習しました。次は、ユーザをあっと言わせる検索を作成しましょう。ユーザは気づかないかもしれませんが、忍び足で活躍する検索ニンジャになるのです。

• SOQL および SOSL リファレンス
  • Salesforce Object Query Language (SOQL)
  • Salesforce Object Search Language (SOSL)
• REST API 開発者ガイド
  • Search Suggested Records
  • Search Suggested Article Title Matches
  • SObject Suggested Articles for Case
• メタデータ API 開発者ガイド
  • SynonymDictionary
• ヘルプドキュメント
  • 検索結果の記事の昇格