Azure Cognitive Search での Lucence クエリ構文

Azure Cognitive Search でクエリを作成する場合、ワイルドカード、あいまい検索、近接検索、正規表現など、特殊なクエリ フォームに対して完全な Lucene Query Parser 構文を選択できます。 Lucene Query Parser 構文の多くは、Azure Cognitive Search でそのまま実装されています。ただし、*範囲検索は例外で、これは $filter 式を使って構築されます。

完全な Lucene 構文を使用するには、queryType を "full" に設定し、ワイルドカード、あいまい検索、または完全な構文でサポートされている他のクエリ フォームの 1 つをパターン化したクエリ式を渡します。 REST では、クエリ式はドキュメントの検索 (REST API) 要求の search パラメーターで指定されます。

例 (完全な構文)

次の例は、完全な構文を使用して構成された検索要求です。 この特定の例では、フィールド内検索と用語ブーストが示されています。 カテゴリ フィールドに という用語 budgetが含まれているホテルを検索します。 語句を含むドキュメントはすべて、ブースト "recently renovated" 値 (3) という用語の結果として上位にランク付けされます。

POST /indexes/hotels-sample-index/docs/search?api-version=2020-06-30
{
  "queryType": "full",
  "search": "category:budget AND \"recently renovated\"^3",
  "searchMode": "all"
}

どのクエリの種類にも固有ではありませんが、この例では searchMode パラメーターが関連しています。 クエリに演算子がある場合は常に、すべての条件が一致するように設定searchMode=allする必要があります。

その他の例については、Lucene クエリ構文の例に関する記事をご覧ください。 searchMode を含む、クエリ要求とパラメーターの詳細については、ドキュメントの検索 (REST API) に関するページを参照してください。

構文の基礎

次の構文の基礎は、Lucene 構文を使用するすべてのクエリに適用されます。

コンテキストでの演算子評価

配置によって、記号を演算子と解釈するか、または文字列内の 1 つの文字と解釈するかが決まります。

たとえば、Lucene の完全な構文では、あいまい検索と近接検索の両方にチルダ (~) が使用されます。 引用符で囲まれた語句の後に配置すると、 ~ 近接検索が呼び出されます。 用語の末尾に配置すると、 ~ あいまい検索が呼び出されます。

などの business~analyst用語内では、文字は演算子として評価されません。 この場合、クエリが用語または語句クエリであると仮定すると、字句分析を使用したフルテキスト検索では が~取り除き、2 つの OR analystで用語business~analystが分割されますbusiness。

上の例はチルダ (~) ですが、すべての演算子にも同じ原則が適用されます。

特殊文字のエスケープ

検索文字列の一部として検索演算子を使用するには、円記号 (\) 1 つを前に付けて文字をエスケープします。 たとえば、https:// のワイルドカード検索で、:// がクエリ文字列の一部である場合、search=https\:\/\/* を指定します。 同様に、エスケープされた電話番号パターンは、\+1 \(800\) 642\-7676 のようになります。

エスケープが必要な特殊文字には次の例があります。
+ - & | ! ( ) { } [ ] ^ " ~ * ? : \ /

注意

エスケープすることでトークンが一緒に保持されますが、インデックスを作成するときの字句解析で削除される場合があります。たとえば、標準の Lucene アナライザーでは、ハイフン、スペースなどの文字で単語が分割されます。 クエリ文字列で特殊文字が必要な場合は、それらをインデックスに保持するアナライザーが必要になることがあります。 選択肢には、ハイフンでつながれた単語を保持する Microsoft 自然言語アナライザーや、より複雑なパターン用のカスタム アナライザーなどが含まれます。 詳細については、部分的な語句、パターン、特殊文字に関する記事を参照してください。

URL での安全でない文字および予約文字のエンコード

安全でない文字および予約文字はすべて、URL でエンコードするようにしてください。 たとえば、 # は URL のフラグメント/アンカー識別子であるため、安全でない文字です。 この文字を URL で使用する場合は、%23 にエンコードする必要があります。 &と = は、パラメーターを区切り、Azure Cognitive Searchで値を指定する予約文字の例です。 詳しくは、RFC1738: Uniform Resource Locators (URL) に関するページをご覧ください。

安全でない文字は " ` < > # % { } | \ ^ ~ [ ] です。 予約文字は ; / ? : @ = + & です。

ブール演算子

照合の精度を向上させるために、クエリ文字列にブール演算子を埋め込むことができます。 完全な構文は、文字演算子に加え、テキスト演算子をサポートします。 テキスト ブール演算子 (AND、OR、NOT) は、常に大文字で指定します。

テキスト演算子	文字	例	使用法
AND	+	wifi AND luxury	照合で含める必要がある用語を指定します。 この例では、クエリ エンジンは と luxuryの両方wifiを含むドキュメントを検索します。 プラス文字 (+) を用語の直前に使用して、その用語を必須にすることもできます。 たとえば、+wifi +luxury は、両方の用語が 1 つのドキュメントのフィールド内のどこかに表示されている必要があることを規定します。
OR	(なし) 1	wifi OR luxury	いずれかの用語が見つかった場合に一致を検索します。 この例では、クエリ エンジンは、どちらか wifi 一方または luxury 両方を含むドキュメントに対して一致を返します。 OR は、既定の結合演算子のため、除外することもできます。たとえば、wifi luxury は wifi OR luxury と同等です。
NOT	!, -	wifi –luxury	用語を除外するドキュメントの一致を返します。 たとえば、 wifi –luxury は、 という用語を持つドキュメントを wifi 検索しますが、 は検索しません luxury。

¹| 文字は、OR 演算ではサポートされていません。

NOT Boolean 演算子

重要

NOT 演算子 (NOT、、または -) は、!単純な構文とは完全な構文で動作が異なります。

• 単純な構文では、否定を含むクエリには常にワイルドカードが自動的に追加されます。 たとえば、クエリ -luxury は 自動的に に -luxury *展開されます。
• 完全な構文では、否定を含むクエリをワイルドカードと組み合わせることはできません。 たとえば、クエリ -luxury * は許可されません。
• 完全な構文では、否定が 1 つのクエリは許可されません。 たとえば、クエリ -luxury は許可されません。
• 完全な構文では、否定は、検索モードに関係なく、常にクエリに AND が適用されるかのように動作します。
  • たとえば、完全構文の完全な構文クエリ wifi -luxury では、 という用語 wifiを含むドキュメントのみがフェッチされ、それらのドキュメントに否定 -luxury が適用されます。
• 否定を使用してインデックス内のすべてのドキュメントを検索する場合は、任意の検索モードの単純な構文をお勧めします。
• 否定を使用してインデックス内のドキュメントのサブセットを検索する場合は、完全な構文またはすべての検索モードの単純な構文をお勧めします。

クエリの型	検索モード	サンプル クエリ	動作
シンプル	any	wifi -luxury	インデックス内のすべてのドキュメントを返します。 "wifi" という用語を持つドキュメント、または "luxury" という用語が欠落しているドキュメントは、他のドキュメントよりも上位にランク付けされます。 クエリは に wifi OR -luxury OR *展開されます。
シンプル	all	wifi -luxury	"wifi" という用語を含み、"luxury" という用語を含まない、インデックス内のドキュメントのみを返します。 クエリは に wifi AND -luxury AND *展開されます。
[完全]	any	wifi -luxury	"wifi" という用語を含むインデックス内のドキュメントのみを返し、"luxury" という用語を含むドキュメントが結果から削除されます。
[完全]	all	wifi -luxury	"wifi" という用語を含むインデックス内のドキュメントのみを返し、"luxury" という用語を含むドキュメントが結果から削除されます。

フィールド検索

fieldName:searchExpression 構文を使用して、フィールド検索操作を定義できます。検索式は、単一の単語、単一の語句、またはかっこで囲まれた複雑な式が可能であり、必要に応じてブール演算子も使用できます 例として、次のようなものがあります。

• genre:jazz NOT history

• artists:("Miles Davis" "John Coltrane")

複数の文字列を 1 つのエンティティとして評価する場合は、必ず両方の文字列を引用符で囲んでください。この場合は、artists フィールドで 2 人の異なるアーティストを検索します。

fieldName:searchExpression に指定されるフィールドは、searchable フィールドでなければなりません。 フィールド定義におけるインデックス属性の利用方法の詳細については、「インデックスの作成」を参照してください。

注意

各フィールド検索式にはフィールド名が明示的に指定されるため、フィールド検索式を使用する際は searchFields パラメーターを使用する必要はありません。 ただし、いくつかの部分で特定のフィールドをスコープにし、他の部分は複数のフィールドに適用できるクエリを実行する場合は、searchFields パラメーターを引き続き使用できます。 たとえば、クエリ search=genre:jazz NOT history&searchFields=description は、genre フィールドの jazz のみと一致し、description フィールドの NOT history と一致します。 fieldName:searchExpression に指定されたフィールド名は常に searchFields パラメーターに優先するため、この例では searchFields パラメーターに genre を含める必要はありません。

あいまい検索

あいまい検索を使用すると、2 つ以下の距離条件を満たす用語を最大 50 の用語まで拡張して、似た構造を持つ用語の一致を見つけることができます。 詳細については、あいまい検索に関するページを参照してください。

あいまい検索を行うには、1 つの単語の末尾にあるチルダ ~ 記号を使用し、編集距離を指定する省略可能なパラメーター (0 ~ 2 の数値 (既定値)) を指定します。 たとえば、 blue~ または は、、blues、および を返しますblueglue。blue~1

あいまい検索は、引用符で囲まれた語句ではなく、用語にのみ適用できますが、複数の部分で構成される名前または語句で各用語にチルダを個別に追加できます。 たとえば、 Unviersty~ of~ Wshington~ は で一致します University of Washington。

近接検索

近接検索は、ある文書で互いに近くにある言葉を検索します。 語句の末尾にチルダ ~ 記号を挿入し、その後に近接境界を作成する単語の数を挿入します。 たとえば、 は、 "hotel airport"~5 文書内の用語 hotel と airport 、互いの 5 つの単語内を検索します。

用語ブースト

用語ブーストとは、ブーストされる用語を含むドキュメントに、それを含まないドキュメントより高い順位を付けることです。 これはスコアリング プロファイルとは違います。スコアリング プロファイルは、特定の用語ではなく、特定のフィールドをブーストします。

次の例はその違いを示しています。 特定のフィールドの一致をブーストするスコアリング プロファイルがあるとします。たとえば、musicstoreindex の例の genre です。 用語ブーストでは、特定の用語に他の用語より高い順位を与えます。 たとえば、 rock^2 electronic ジャンル フィールドの検索語句を含むドキュメントを、インデックス内の他の検索可能なフィールドよりも上位に昇格します。 また、検索用語 ロック を含むドキュメントは、用語ブースト値(2)の結果として 電子 の他の検索用語よりも上位にランク付けされる。

用語をブーストするには、検索する用語の末尾にブースト係数 (数値) を含むキャレット ^記号を使用します。 語句をブーストすることもできます。 ブースト係数が高いほど、用語が他の検索語句に対して相対的に関連性が高くなります。 既定のブースト係数は 1 です。 ブースト係数は正数にする必要がありますが、1 未満 (0.20 など) の数字にすることができます。

正規表現検索

正規表現検索では、RegExp クラスに関するページで説明されているように、Apache Lucene で有効なパターンに基づいて一致が検出されます。 Azure Cognitive Search では、正規表現はスラッシュ / で囲まれます。

たとえば、 または hotelを含むドキュメントをmotel検索するには、 を指定します/[mh]otel/。 正規表現検索では、単一の単語に対して照合が行われます。

一部のツールと言語では、他のエスケープ文字要件が適用されます。 JSON の場合、スラッシュを含む文字列は、後方スラッシュを使用してエスケープされます。 microsoft.com/azure/ は正規表現を設定する場所search=/.* <string-placeholder>.*/になりsearch=/.*microsoft.com\/azure\/.*/、microsoft.com\/azure\/エスケープされたスラッシュを含む文字列です。

正規表現クエリの 2 つの一般的な記号は、. と * です。 . は任意の 1 文字に一致し、* は前の文字に 0 回以上一致します。 たとえば、 /be./ は 用語beeと一致し、 bet は /be*/ 、bee、、 beee と一致しますが、 は一致beしませんbet。 を一緒に使用すると、.*任意の一連の文字を一致させることができます。これにより/be.*/、 などbetter、 で始まる任意の用語とbe一致します。

ワイルドカード検索

複数 (*) または単数 (?) の文字のワイルドカード検索で、一般に認識されている構文を使用できます。 完全な Lucene 構文では、プレフィックス、挿入辞、およびサフィックスの一致がサポートされています。

Lucene Query Parser では、これらの文字を語句ではなく 1 つの用語に利用することにご注意ください。

接辞型	説明と例
prefix	用語の断片が * または ? の前にあります。 たとえば、 のクエリ式は search=alpha* または alphabeticalを返しますalphanumeric。 プレフィックス一致は、シンプルな構文と完全な構文の両方でサポートされています。
suffix	用語の断片が * または ? の後にあります。スラッシュを使用してコンストラクトを区切ります。 たとえば、search=/.*numeric/ では alphanumeric が返されます。
挿入辞	用語の断片が * または ? を囲みます。 たとえば、 search=non*al は と を返しますnon-numericalnonsensical。

演算子をひとつの式に結合できます。 たとえば、 980?2* は と 98052-1234で98072-1222一致します。ここで、 は ? 1 つの (必須) 文字で一致し*、その後に続く任意の長さの文字で一致します。

サフィックスの一致には、正規表現のスラッシュ / 区切り記号が必要です。 一般に、/ なしで、用語の最初の文字として * または ? 記号を使用することはできません。 正規表現クエリの外部で使用する場合は、 の動作が異なることも重要 * です。 正規表現のスラッシュ / 区切り記号の外部では、 * はワイルドカード文字であり、正規表現と同様 .* に任意の一連の文字と一致します。 例として、 search=/non.*al/ は と同じ結果セットを search=non*al生成します。

Note

原則として、パターン マッチングは低速であるため、用語内の文字シーケンスのトークンを作成するエッジ n-gram トークン化など、別の方法を検討することもできます。 n-gram トークン化では、インデックスのサイズは大きくなりますが、パターンの構成やインデックスを付ける文字列の長さによっては、クエリの実行速度が速くなる場合があります。 詳細については、「部分的な用語検索と特殊文字を含むパターン」をご覧ください。

ワイルドカード クエリに対するアナライザーの影響

クエリの解析中には、プレフィックス、サフィックス、ワイルドカードとして定式化されたクエリ、または正規の式は、語彙分析をバイパスして、クエリ ツリーにそのまま渡されます。 クエリで指定した形式の文字列がインデックスに含まれている場合に限って、一致が検出されます。 ほとんどの場合、部分的な用語とパターン マッチングが成功するように、文字列の整合性を保持するインデックス作成中にアナライザーが必要です。 詳細については、「Azure Cognitive Search クエリでの部分一致検索」を参照してください。

検索クエリterminal*で、 などのterminateterminationterminates用語を含む結果を返す場合があるとします。

en.lucene (English Lucene) アナライザーを使用する場合、各用語の語幹処理が積極的に適用されます。 たとえば、 terminateはterminationterminates、すべてインデックス内のトークンtermiにトークン化されます。 一方、ワイルドカードまたはあいまい検索を使用するクエリの用語はまったく分析されないため、クエリに一致 terminat* する結果はありません。

一方、Microsoft analyzers (この場合、en.microsoft アナライザー) はもう少し高度であり、語幹処理の代わりに見出し語選定が使用されます。 つまり、生成されたトークンはすべて正しい英単語になります。 たとえば、、terminateterminates、 termination は主にインデックス全体に残り、ワイルドカードとあいまい検索に大きく依存するシナリオに適した選択肢となります。

ワイルドカード クエリと正規表現クエリのスコアリング

Azure Cognitive Search では、テキスト クエリに、頻度に基づいたスコアリング (BM25) を使用します。 ただし、用語のスコープが広くなる可能性があるワイルドカード クエリと正規表現クエリでは、出現頻度が低い用語の一致に対する優先度付けに偏りが発生するのを避けるために、頻度の係数は無視されます。 すべての一致は、ワイルドカード検索と正規表現検索で同等に扱われます。

特殊文字

場合によっては、"❤" のような絵文字や "€" のような記号などの特殊文字を検索することが必要です。 そのような場合は、使用しているアナライザーによってそれらの文字が除外されないことを確認します。標準アナライザーでは多くの特殊文字が無視され、インデックスから除外されます。

特殊文字をトークン化するアナライザーには、空白アナライザーが含まれます。これは、空白で区切られた文字シーケンスをトークンとして考慮します (そのため、 ❤ 文字列はトークンと見なされます)。 また、Microsoft English アナライザー ("en.microsoft") のような言語アナライザーでは、"€" という文字列がトークンとして見なされます。 アナライザーをテストして、特定のクエリに対して生成されるトークンを確認できます。

Unicode 文字を使用する場合は、クエリ URL で記号が正しくエスケープされていることを確認します (たとえば ❤ 、 ではエスケープ シーケンス %E2%9D%A4+を使用します)。 Postman では、この変換が自動的に行われます。

優先順位 (グループ化)

かっこを使用して、かっこで囲まれたステートメント内に演算子を含むサブクエリを作成できます。 たとえば、motel+(wifi|luxury)用語と wifiluxury または (またはその両方) を含むmotelドキュメントを検索します。

フィールドのグループ化は似ていますが、グループ化のスコープを 1 つのフィールドに設定します。 たとえば、 hotelAmenities:(gym+(wifi|pool)) は、 フィールドgymhotelAmenitiesで、 とwifi、または gym を検索しますpool。

クエリ サイズの上限

Azure Cognitive Search では、無制限のクエリによって検索サービスが不安定になるおそれがあるため、クエリのサイズと構成に制限が適用されます。 クエリのサイズと構成 (句の数) には制限があります。 制限は、プレフィックス検索の長さと、正規表現検索およびワイルドカード検索の複雑さにもあります。 アプリケーションがプログラムで検索クエリを生成する場合は、無制限のサイズのクエリが生成されないように設計することをお勧めします。

クエリの制限の詳細については、「API 要求の制限」を参照してください。

関連項目

• 単純な検索のクエリ例
• 完全な Lucene 検索のクエリ例
• ドキュメントの検索
• フィルターと並べ替えの OData 式の構文
• Azure Cognitive Search でのシンプルなクエリ構文