フィールド設定を構成する

このページでは、構造化データ、メタデータを含む非構造化データ、またはカスタムの構造化属性を含むウェブサイトのデータ用にアプリを設定するスキーマ フィールドを構成する方法について説明します。

フィールド設定は、エージェント検索が結果でフィールドを使用する方法を決定するのに役立ちます。Google Cloud コンソールの [スキーマ] タブを使用して、フィールド設定を構成できます。

フィールド設定の構成は、構造化データまたはメタデータを含む非構造化データを含むデータストアがあるアプリでのみ使用できます。

フィールド設定

次のフィールド設定は、検索データまたはおすすめデータ内の多くのフィールド タイプで使用できますが、すべてのデータタイプで使用できるわけではありません。スキーマには、個々のフィールドの複数のフィールド設定が含まれています。次の表に、スキーマ内のフィールドに適用できる設定を示します。これらのフィールド設定では、構造化データを使用することを強くおすすめします。

設定	定義	目的	ユースケースの例
インデックスを作成可能	フィールドをインデックス可能に設定すると、ドキュメント内の構造化フィールドでフィルタリング、ブースト、ファセットなどのオペレーションが可能になります。 Object タイプのフィールドを Indexable に設定することはできません。	フィールドを Indexable としてマークすると、ルックアップを迅速に行うことができます。 フィールドを Indexable としてマークすると、検索インデックスのサイズが増加し、インデックス登録が遅くなる可能性があります。	ホテル データストアでは、hotel_chain などのフィールドをインデックス登録可能として設定できます。これにより、hotel_chain に対してランキング、フィルタリング、ブーストのオペレーションを適用できます。たとえば、フィルタを適用して、フィルタされたホテル チェーンを含む検索結果のみが表示されるようにすることができます。
検索可能	検索に関連する可能性が最も高いフィールドは Searchable として指定されます。フィールドは、インデックスを作成可能または取得可能でなくても検索可能にできます。 なお、検索可能に設定できるのは、テキスト値を含むフィールドのみです。したがって、数値の価格フィールドはインデックス登録可能（フィルタリングやファセット処理用）ですが、全文検索はできません。	フィールドを [検索可能] に設定すると、検索クエリでそのフィールドの再現率が向上し、ユーザーはこれらのフィールド内のテキストをクエリして、ウェブページなどのコンテンツを見つけることができます。フィールドを検索可能としてマークすると、ランキングを適用できます。そのため、検索可能としてマークするフィールドが多すぎると、ランキング アルゴリズムが過飽和状態になり、結果が多すぎるため、検索精度に悪影響を及ぼす可能性があります。これにより、無関係な検索結果が返される可能性があります。 検索可能なフィールドに相対的な重みを適用できますが、堅牢なデフォルトが設定されているため、これはほとんど必要ありません。下記の体重の検索可能なフィールドをご覧ください。	インターネット サービス プロバイダのサポート チケット システムでは、各チケットが構造化ドキュメントとして保存されます。これらのドキュメントに issue_description や resolution_notes などの検索可能なテキスト フィールドが含まれている場合、サポート エージェントは、これらのフィールドのコンテンツに関連するクエリ（「モデムをリセットした後にインターネットの速度が遅くなるのを修正する方法」など）を実行できます。システムは、issue_description フィールドまたは resolution_notes フィールドのいずれかまたは両方に modem、internet、speed などの検索語句を含むドキュメントを表示します。
接頭辞一致可能 （プレビュー）	フィルタ式で STARTS_WITH 演算子を使用して、接頭辞一致テキスト フィールドを許可します。接頭辞照合可能に設定できるのは、String または String Array タイプのフィールドのみです。 詳細については、下記のプレフィックスと部分一致でフィールドを使用できるようにするをご覧ください。	フィールドをプレフィックス一致可能に設定すると、検索エンジンはフィールドの値のプレフィックスであるクエリ文字列を照合できます。これは、文字列の先頭がわかっている階層識別子、パス、コードを照合する場合に特に便利です。プレフィックス マッチングは、正規化されたフィールド値の最初の 12 文字に制限され、検索インデックスのサイズが増加します。プレフィックス一致可能なフィールドとして設定できるのは 10 個までです。	<country-code><city-code><number> のような形式を使用するフィールド ticket_id があります。たとえば、UKLON100、UKMAN100、UKMAN101、USNY200 などがあります。マンチェスター（英国）のチケットをすべて検索するには、ticket_id フィールドを接頭辞一致可能として設定し、フィルタ ticket_id: STARTS_WITH("UKMAN") を使用します。これにより、UKMAN100 と UKMAN101 が返されます。
部分的に一致可能 （プレビュー）	フィルタ式で CONTAINS 演算子を使用して、テキスト フィールドで文字列の部分一致を許可します。部分一致に設定できるのは、String または String Array タイプのフィールドのみです。 詳細については、下記のプレフィックスと部分一致でフィールドを使用できるようにするをご覧ください。	フィールドを部分一致可能に設定すると、フィールド内でトークンベースのマッチングが可能になり、フィールド値の一部のみがわかっている場合でも、ユーザーがコンテンツを見つけられるようになります。検索エンジンは、クエリトークンとフィールド値のトークンを順序に関係なく照合します。フィールドを部分一致可能としてマークすると、検索インデックスのサイズが増加します。部分一致可能なフィールドとして設定できるのは 10 個までです。	ヨーロッパのリージョンをフィルタする。region の名前には、Central Europe と Eastern Europe が含まれます。フィルタが region: ANY("Europe") の場合、一致するものは見つかりません。ただし、region フィールドが部分一致可能として設定されている場合は、region: CONTAINS("Europe") でフィルタして、Central Europe と Eastern Europe の一致を取得できます。
動的ファセット可能	コンテキスト認識フィルタを提供して、ユーザーの検索をより適切にターゲット設定します。フィールドを Dynamic Facetable に設定すると、フィールドに存在する一意の値に基づいて、インタラクティブ フィルタ（ファセット）が自動的に生成されます。	フィールドを Dynamic facetable に設定すると、ユーザーは、取り込んだデータから直接導出されたカテゴリや属性を選択して、検索結果を動的に絞り込むことができます。可能なすべてのフィルタ オプションを手動で事前定義する必要はありません。これにより、ユーザーは検索対象を非常に具体的なウェブ コンテンツに絞り込むことができます。 検索可能な 動的ファセット可能を使用すると、検索の再現率とユーザーに提供されるファセットの品質の両方が向上し、より良い結果が得られます。	人事ポリシーなどの社内ナレッジベースのページは、department、document_type、last_modified_date などのデータとともに取り込まれます。これらのフィールドに dynamic facetable のタグが付けられている場合、従業員が「経費精算」などの用語を検索すると、関連する検索結果に基づいてインタラクティブなフィルタが動的に生成されます。この場合、ウェブ インターフェースには、[Department: Finance, Travel]（部門: 財務、旅行）、[Document Type: Policy, FAQ]（ドキュメント タイプ: ポリシー、よくある質問）、[Last Modified Date: This Quarter, Last Year]（最終更新日: 今四半期、昨年）などのファセットが表示されます。
取得可能	検索クエリが一致するコンテンツにヒットすると、検索エンジンは取得可能なフィールドの値をプルして、表示したりアプリケーションで使用したりできます。つまり、元のドキュメントの情報が検索結果の一部として表示されます。キーフィールド（ドキュメントの一意の識別子）は、取得可能として設定されます。	取得可能なフィールドは、値を表示できるフィールドと、検索ロジックでのみ使用され、未加工の値がエンドユーザーに表示されないフィールドを区別することで、検索コンテキストを提供します。	販売者サイトでの商品検索では、product_id、name、price、image_url は、通常、取得可能として設定するフィールドです。一方、internal_tracking_code は、管理目的でのみインデックス登録とフィルタリングが可能ですが、一般の検索結果で取得することはできません。
完了可能	フィールドの内容を検索クエリの候補として使用できるようにします。詳細については、予測入力を構成するをご覧ください。	この設定により、ユーザーが入力したときにリアルタイムでクエリ候補を表示するために、そのフィールド内の値を使用できるようになります。この機能により、ユーザーは関連性の高いコンテンツにたどり着きやすくなり、検索プロセスが迅速化されます。自然言語フィルタリングの使用などの要因が、このパフォーマンスに影響する可能性があります。	completable フィールドが product_name、brand、category に設定されている場合、ユーザーが「Tech」と入力すると、オートコンプリートの候補に次のものが表示されます。 TechCo（brand フィールド） TechCo UltraBook X1（product_name フィールド） テクノロジー GameMaster Pro（category 分野の別のプロダクト）
フィルタリング可能	レコメンデーションでフィールドを使用して推奨結果をフィルタし、ユーザーに表示する検索結果を決定できるようにします。レコメンデーションのフィルタリングについては、レコメンデーションをフィルタリングするをご覧ください。	フィールドを Filterable に設定すると、ユーザー向けのおすすめをカスタマイズできます。フィルタリングの上限が適用されることに注意してください。	言語とドラマでフィルタを設定すると、language_code: ANY("en", "fr") OR categories: ANY("drama") のようになります。

よく使用される設定の違い

「インデックス登録可能」、「検索可能」、「取得可能」の各フィールド設定には、重要な違いがあります。これらの違いを次の表にまとめます。

機能	インデックスを作成可能	検索可能	取得可能
主な役割	フィールドのコンテンツを検索エンジンで利用できるようにします。	フィールド コンテンツに対する全文検索を許可します。	フィールドの値を検索結果で返すことを許可します
分析	コンテンツが処理され、インデックスに格納されます。	通常、広範な語彙分析が行われます。	値は表示用にそのまま保存されます。
考えられる原因
...検索可能ですか？	はい（前提条件であることが多い）	なし	必ずしもそうではありません（検索可能でなくても取得できる場合があります）。
...取得可能ですか？	必ずしもそうとは限りません	必ずしもそうとは限りません	なし
...フィルタ可能/並べ替え可能/ファセット可能か？	はい（通常、これらにも前提条件があります）	直接はできません。これらは、インデックス作成可能なフィールドに基づいて構築されることが多い、別個の属性です。	直接は関係ありません。これらの属性は、フィールドのインデックス登録とクエリの方法に関連しており、表示方法だけに関連しているわけではありません。

実際には、ユーザー エクスペリエンスに不可欠な多くのフィールド（タイトル、説明、識別情報など）は、indexable、searchable、retrievable に設定されることがよくあります。

注: 用語や動作は、検索エンジン テクノロジー（Elasticsearch、Apache Solr、Azure AI Search、 Google Cloud Search など）によって若干異なる場合がありますが、基本的なコンセプトはほぼ同じです。

制限事項

フィールド設定には次の制限があります。

• 最大 50 個のフィールドを、インデックスを作成可能、検索可能、取得可能、動的ファセット可能として構成できます。
• フィールドを動的ファセット可能として構成するには、まずインデックス登録可能として構成する必要があります。
• インデックスを作成可能な設定を変更するには、データのインデックスを再登録する必要があります。特に大規模なデータストアの場合、この処理に数時間かかることがあります。

メディア検索アプリのフィールドを構成していて、スキーマのフィールドに関する詳細情報が必要な場合は、メディア ドキュメントとデータストアについてをご覧ください。

フィールド設定を更新する

フィールド設定を更新するには:

1. Google Cloud コンソールで、[AI Applications] ページに移動します。

   AI Applications

2. 編集するアプリの名前をクリックします。

3. [データ] をクリックします。

4. [スキーマ] タブをクリックします。このタブには、現在のフィールド設定が表示されます。

   データストアに基本的なウェブサイト データやメタデータのない非構造化データが含まれている場合、[スキーマ] タブは表示されません。

5. [編集] をクリックします。

6. 更新する必要があるフィールド設定を選択または選択解除します。一部のフィールド設定はサポートされていません。たとえば、数値フィールドを [検索可能] に設定することはできません。

7. [保存] をクリックして変更を適用します。

検索可能なフィールドの重み付け（プレビュー）

プレビュー

この機能は、サービス固有規約の「一般サービス規約」セクションの「一般提供前のサービス規約」の対象となります。pre-GA の機能は「現状のまま」で提供されるものであり、サポートが制限されることがあります。 詳細については、リリース ステージの説明をご覧ください。

フィールドを検索可能としてマークすると、検索結果での相対的な重要度を示す重みを指定できます。ほとんどの場合、デフォルトの重み付けで十分なため、個々のフィールドの重み付けを指定する必要はありません。

ただし、次のような状況では、重みの調整が必要になることがあります。

• 重み付けフィールドをすでに使用している既存の検索プラットフォームからデータを移行する。

• デフォルトの重み付けでは満足のいく検索結果が得られない場合。具体的には、検索可能なフィールドが多数あり、その一部が他のフィールドよりも明らかに重要である場合に発生する可能性があります。

  たとえば、検索で最も重要なフィールドが概要であるため、そのテキストを優先したいとします。

  また、検索結果の優れた予測因子となる関連性の高いキーワードを含むフィールドがスキーマにあるものの、このフィールドは他のフィールドよりもはるかに短いため、その影響が長いフィールドによって覆い隠されてしまうこともあります。重みを大きくすると、意図した影響を確実に与えることができます。

重みレベル

重みは次のレベルに分類されます。

フィールドの重要度	説明
非常に低い	すべてのフィールドのスコアを組み合わせる際にシステムが考慮する低い値。効果が無視できるほど重みを小さくしたい場合は、フィールドを検索可能にしないでください。
低い	デフォルトよりも低い重み。
デフォルト	検索可能フィールドの標準の重み。この重み付けにより、ほとんどのケースでかなり良好なパフォーマンスが得られます。
高い	デフォルトよりも著しく高い重み。
非常に高い	支配的な重み。通常、この予約は最大 1 つのフィールドに対して行います。

スキーマの更新と再インデックス登録

検索可能なフィールドに重みを追加するには、スキーマの更新と、データストア内のデータの再インデックス登録が必要です。スキーマの更新には数時間かかり、インデックス登録の完了を知らせる信頼できる指標がないため、インデックス登録時間を過大に見積もる必要があります。

フィールドの重みレベルを設定する

フィールドの重みレベルを設定する作業は、小さな変更のみを行い、その後検索結果を慎重に確認して意図しない結果がないか確認する必要があるため、面倒な作業になる可能性があります。変更のたびに、再インデックス登録が完了するまで待ってから、変更の影響を評価する必要があります。

注: title や description などのキー プロパティであるフィールドに重みを適用することはできません。エージェント検索では、キー プロパティとしてマークされたフィールドにすでに高い重みが適用されています。

検索フィールドの重み付けは、API を介してのみ構成できます。この機能は Google Cloud コンソールでは使用できません。

重みを設定するには、API projects.locations.dataStores.schemas.patch メソッドを使用してデータストアのスキーマを更新する必要があります。

1. スキーマがまだない場合は、スキーマ定義を表示するの手順に沿ってスキーマを取得します。

2. スキーマをプログラムで更新する手順に沿って操作します。次の例のように、1 つ以上の検索可能なフィールドに重みを追加します。

   "summary": {
      "type": "string",
      "searchable": true,
      "weight": "high"
    },
    "uri": {
      "type": "string",
      "searchable": true,
      "weight": "low"
    },
   

   この例では、summary フィールドは通常の重みよりも高い重みに設定され、uri フィールドは低い重みに設定されています。重みをデフォルト値に戻す場合は、default に設定します。

   重みパラメータに指定できる値は次のとおりです。

   • very_low
   • low
   • default
   • high
   • very_high

   コマンドの例と結果

   curl -X PATCH \
   -H "Authorization: Bearer $(gcloud auth print-access-token)" \
   -H "Content-Type: application/json" \
   "https://discoveryengine.googleapis.com/v1beta/projects/my-project-123/locations/global/collections/default_collection/dataStores/my-data-store/schemas/default_schema" \
   -d '{
   "structSchema": { "$schema": "https://json-schema.org/draft/2020-12/schema", "properties": { "amenities": { "items": { "completable": true, "dynamicFacetable": true, "indexable": true, "retrievable": true, "searchable": true, "type": "string", "weight": "high" }, "type": "array" }, "available_date": { "indexable": true, "retrievable": true, "type": "datetime" }, "id": { "dynamicFacetable": false, "indexable": true, "retrievable": true, "type": "number" }, "location": { "indexable": true, "retrievable": true, "type": "geolocation" }, "non_smoking": { "dynamicFacetable": true, "indexable": true, "type": "boolean" }, "price_per_night": { "indexable": true, "retrievable": true, "type": "number" }, "rating": { "dynamicFacetable": true, "indexable": true, "retrievable": true, "type": "number" }, "room_types": { "items": { "dynamicFacetable": true, "indexable": true, "retrievable": true, "searchable": true, "type": "string", "weight": "low" }, "type": "array" }, "title": { "keyPropertyMapping": "title", "retrievable": true, "type": "string" } }, "type": "object" }
   }'
   
   {
   "name": "projects/123456/locations/global/collections/default_collection/dataStores/my-data-store/schemas/default_schema/operations/update-schema-123456",
   "metadata": {
   "@type": "type.googleapis.com/google.cloud.discoveryengine.v1beta.UpdateSchemaMetadata"
   }
   }
   

   この例では、amentities フィールドに通常の重み付けよりも高い重み付けが与えられ、room_types フィールドには低い重み付けが与えられます。

3. 再インデックス登録が完了するまで待ってから、検索行動をテストします。

接頭辞と部分一致でフィールドを使用できるようにする（プレビュー）

プレビュー

この機能は、サービス固有規約の「一般サービス規約」セクションの「一般提供前のサービス規約」の対象となります。pre-GA の機能は「現状のまま」で提供されるものであり、サポートが制限されることがあります。 詳細については、リリース ステージの説明をご覧ください。

string タイプのフィールドの場合、スキーマを編集して、プレフィックス一致または部分一致でフィールドを使用できるようにすることができます。これにより、フィルタ式で STARTS_WITH または CONTAINS を使用できます。

スキーマの更新と再インデックス登録

フィールドをプレフィックスまたは部分一致で使用できるようにするには、スキーマの更新と、それに続くデータストア内のデータの再インデックス登録が必要です。スキーマの更新には数時間かかり、インデックス作成の完了を知らせる信頼できる指標がないため、インデックス作成時間を過大に見積もる必要があります。

プレフィックスと部分一致のスキーマを更新

注: 接頭辞と部分一致は、API を介してのみ構成できます。この機能は Google Cloud コンソールでは使用できません。

フィールドをプレフィックス マッチングまたは部分一致に使用できるように指定するには、API の projects.locations.dataStores.schemas.patch メソッドを使用してデータストアのスキーマを更新する必要があります。

1. スキーマがまだない場合は、スキーマ定義を表示するの手順に沿ってスキーマを取得します。

2. スキーマをプログラムで更新する手順に沿って操作します。次の例のように、スキーマで照合可能なパラメータを true に設定します。

   "zone": {
      "type": "string",
      "searchable": true,
      "prefixMatchable": true
    },
    "region": {
      "type": "string",
      "searchable": true,
      "partialMatchable": true
    },
    "model": {
      "type": "string",
      "searchable": true,
      "prefixMatchable": true,
      "partialMatchable": true
    },
   

   この例では、zone フィールドがプレフィックス一致可能に設定されています。フィルタ式では、フィールド値を照合するために、大文字と小文字を区別しない 12 文字までの文字列を使用できます。region フィールドは部分一致可能に設定されています。

   コマンドの例と結果

   curl -X PATCH \
   -H "Authorization: Bearer $(gcloud auth print-access-token)" \
   -H "Content-Type: application/json" \
   "https://discoveryengine.googleapis.com/v1beta/projects/my-project-123/locations/global/collections/default_collection/dataStores/my-data-store/schemas/default_schema" \
   -d '{
     "structSchema": { "$schema": "https://json-schema.org/draft/2020-12/schema",
     "properties": { "amenities": { "items": { "completable":
     true,"partialMatchable": true, "dynamicFacetable": true, "indexable": true,
     "retrievable": true, "searchable": true, "type": "string" },
     "type": "array" }, "available_date": { "indexable": true, "retrievable": true,
     "type": "datetime" }, "id": { "dynamicFacetable": false, "indexable": true,
     "retrievable": true, "type": "number" }, "location": { "indexable": true,
     "retrievable": true, "type": "geolocation" }, "non_smoking": {
     "dynamicFacetable": true, "indexable": true, "type": "boolean" },
     "price_per_night": { "indexable": true, "retrievable": true, "type": "number"
     }, "rating": { "dynamicFacetable": true, "indexable": true, "retrievable":
     true, "type": "number" }, "room_types": { "items": { "dynamicFacetable": true,
     "prefixMatchable": true, "indexable": true, "retrievable": true,
     "searchable": true, "type": "string" }, "type": "array" }, "title": {
     "keyPropertyMapping": "title", "retrievable": true, "type": "string" } },
     "type": "object" } }'
   
   {
   "name": "projects/123456/locations/global/collections/default_collection/dataStores/my-data-store/schemas/default_schema/operations/update-schema-123456",
     "metadata": {
       "@type": "type.googleapis.com/google.cloud.discoveryengine.v1beta.UpdateSchemaMetadata"
     }
   }
   

   この例では、amentities フィールドは部分一致可能です。つまり、CONTAINS("outdoor pool") は値が outdoor swimming pool のアメニティと一致します。room_type フィールドはプレフィックス一致が可能です。つまり、STARTS_WITH("lux") のフィルタは Luxury Room の客室タイプと一致しますが、Deluxe とは一致しません。

3. 再インデックス登録が完了するまで待ちます。

プレフィックス照合の詳細

エージェント検索のプレフィックス一致を使用すると、フィールドの値が特定の文字列で始まるかどうかに基づいて結果をフィルタできます。この機能は STARTS_WITH 演算子によって実現されます。この機能を使用するには、スキーマでターゲット テキスト フィールドを prefixMatchable として構成する必要があります。

正規化と照合のロジック

パフォーマンスを最適化し、整合性を確保するため、システムはフィールド値（インデックス作成時）とクエリ文字列（検索時）の両方に特定の正規化プロセスを適用します。

1. 小文字化: すべての文字が小文字に変換されます。これにより、大文字と小文字が区別されなくなります。

2. 12 文字の切り捨て: 文字列の最初の 12 文字のみが考慮されます。この上限を超える文字は、プレフィックス照合の目的では無視されます。

仕組み

インデックス登録時に、prefixMatchable としてマークされたフィールドに対して、最初の 12 文字の接頭辞トークンが生成されます。asia-south1-c などの値の場合、インデックスには a、as、asi、asia、asia- などのトークンが 12 文字目（asia-south1-）まで保存されます。

クエリ時にも、STARTS_WITH 演算子に指定された文字列は小文字に変換され、12 文字に切り捨てられます。その後、クエリが保存された接頭辞トークンと照合されます。

例

次の例は、12 文字の正規化が検索結果にどのように影響するかを示しています。

• インテント マッチ: STARTS_WITH("A") は、「a」で始まる任意の値（大文字と小文字を区別しない）と一致します（asia、australia、africa など）。

• 部分接頭辞: STARTS_WITH("asia-south") は、指定された 10 文字の文字列で始まる asia-south1-a と asia-southeast1-b の両方に一致します。

• 切り捨ての動作: 最初の 12 文字のみが照合されるため、STARTS_WITH("asia-south1-a") は asia-south1-c のフィールド値と一致します。これは、両方の文字列が同じ 12 文字の接頭辞 asia-south1- に正規化されるためです。

部分一致の詳細

エージェント検索の部分一致を使用すると、フィールドの値に特定の単語やトークンが含まれているかどうかに基づいて結果をフィルタできます。この機能は CONTAINS 演算子によって実現されます。この機能を使用するには、スキーマでターゲット テキスト フィールドを partialMatchable として構成する必要があります。

正規化とトークン化のロジック

エージェント検索では、フィールド値（インデックス登録時）とクエリ文字列（検索時）の両方が正規化され、トークン化されます。

• 小文字化: エージェント検索は文字を小文字に変換します。これにより、大文字と小文字が区別されなくなります。

• トークン化: エージェント検索は、スペースなどの文字を区切り文字として使用して、文字列を個々のトークン（単語）に分割します。

  • 標準区切り文字: スペースと一般的な句読点が区切り文字として機能します。これには、ハイフン（-）、スラッシュ（/）、カンマ（,）、ピリオド（.）、アスタリスク（*）、中かっこ（{ }）、角かっこ（[ ]）、丸かっこ（( )）、アポストロフィ（'）が含まれます。

  • 区切り文字以外: アンパサンド（&）とアンダースコア（_）は区切り文字として機能しません。これらの記号で結合された文字は、1 つのトークンとして処理されます。

  • メールの区切り文字（@）: @ 記号は、メールアドレスの認識を支援する特別な区切り文字として機能します。システムは、個々のコンポーネントと組み合わせた形式の両方に対してトークンを生成します。たとえば、[e-mail] を support、tier1、example、com、[e-mail]、[e-mail] にトークン化します。

仕組み

インデックス作成時に、partialMatchable としてマークされたフィールドの場合、システムはフィールド値を正規化してトークン化し、結果のトークンをインデックスに保存します。たとえば、フィールド値 25-meter, outdoor, swimming pool を [25, meter, outdoor, swimming, pool] にトークン化します。

クエリ時に、CONTAINS 演算子に渡された文字列は同じ正規化とトークン化のプロセスを経ます。検索エンジンは、結果として得られたすべてのクエリトークンが、フィールドの保存済みトークンと一致することを確認します。トークンの順序は影響しません。

例

次の例は、トークン化が部分一致の結果にどのように影響するかを示しています。

• 基本的なトークン マッチング: フィールド値が 25-meter, outdoor, swimming pool の場合、CONTAINS("Outdoor pool") のフィルタが一致します。システムはクエリを [outdoor, pool] にトークン化します。どちらもフィールドのトークンに存在します。

• 順序の独立性: CONTAINS("pool outdoor") のフィルタは、各トークンの存在を順序に関係なく個別にチェックするため、フィールド値 25-meter, outdoor, swimming pool にも一致します。

• メールアドレスの一致: フィールドにメール [e-mail] が保存されている場合、@ 記号の特別なトークン化により、CONTAINS("support")、CONTAINS("example.com")、CONTAINS("[e-mail]") などのフィルタはすべて正常に一致します。

次のステップ

• 構造化データのスキーマを更新する
• 検索結果を構成する
• 検索結果をプレビューする