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

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

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

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

フィールド設定

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

設定	定義	目的	ユースケースの例
インデックスを作成可能	フィールドをインデックス可能に設定すると、ドキュメント内の構造化フィールドでフィルタリング、ブースト、ファセットなどのオペレーションが可能になります。 Object タイプのフィールドを Indexable に設定することはできません。	フィールドを Indexable としてマークすると、ルックアップを高速化できます。 フィールドを Indexable としてマークすると、検索インデックスのサイズが増加し、インデックス登録が遅くなる可能性があります。	ホテルのデータストアでは、hotel_chain などのフィールドをインデックス登録可能に設定できます。これにより、hotel_chain に対してランキング、フィルタリング、ブースト オペレーションを適用できます。たとえば、フィルタを適用して、フィルタされたホテル チェーンを含む検索結果のみが検索で返されるようにできます。
検索可能	検索に関連する可能性が最も高いフィールドは Searchable として指定されます。フィールドは、インデックス登録可能または取得可能でなくても検索可能です。 検索可能としてマークできるのは、テキスト値を含むフィールドのみです。したがって、数値の価格フィールドはインデックス登録可能（フィルタリングまたはファセット用）ですが、全文検索はできません。	フィールドを [検索可能] に設定すると、検索クエリでのそのフィールドの再現率が向上し、ユーザーはこれらのフィールド内のテキストをクエリして、ウェブページなどのコンテンツを見つけることができます。フィールドを検索可能としてマークすると、ランキングを適用できます。したがって、過剰な数のフィールドを検索可能としてマークすると、ランキング アルゴリズムが過飽和状態になり、結果が多すぎるため、検索精度に悪影響を及ぼす可能性があります。これにより、無関係な検索結果が返される可能性があります。 検索可能なフィールドに相対的な重み付けを適用できますが、堅牢なデフォルトが設定されているため、これはほとんど必要ありません。下記の重み付け可能な検索フィールドをご覧ください。	インターネット サービス プロバイダのサポート チケット システムでは、各チケットが構造化ドキュメントとして保存されます。これらのドキュメントに issue_description や resolution_notes などの検索可能なテキスト フィールドが含まれている場合、サポート エージェントは、これらのフィールドの内容に関連するクエリ（「モデムのリセット後にインターネットの速度が遅くなるのを修正する方法」など）を実行できます。システムは、issue_description フィールドまたは resolution_notes フィールドのいずれかまたは両方に「モデム」、「インターネット」、「速度」などの検索キーワードを含むドキュメントを返します。
接頭辞一致可能 （プレビュー）	フィルタ式で 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 のタグが付けられている場合、従業員が「経費精算」などの用語で検索すると、関連する検索結果に基づいてインタラクティブなフィルタが動的に生成されます。この場合、ウェブ インターフェースには [部門: 財務、出張]、[ドキュメント タイプ: ポリシー、よくある質問]、[最終更新日: 今四半期、昨年] などのファセットが表示されます。
取得可能	検索クエリが一致するコンテンツにヒットすると、検索エンジンは取得可能なフィールドの値をプルして、表示したりアプリケーションで使用したりできます。つまり、元のドキュメントの情報が検索結果の一部として表示されます。キーフィールド（ドキュメントの一意の識別子）は取得可能として設定されます。	取得可能なフィールドは、値を表示できるフィールドと、検索ロジックでのみ使用され、元の値がエンドユーザーに表示されないフィールドを区別することで、検索コンテキストを提供します。	販売者サイトの商品検索では、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") のようになります。

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

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

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

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

制限事項

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

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

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

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

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

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

   AI Applications

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

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

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

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

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

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

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

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

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

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

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

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

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

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

重みレベル

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

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

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

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

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

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

検索フィールドの重み付けは、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. 再インデックス登録が完了するまで待ってから、検索行動をテストします。

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

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

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

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

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

フィールドをプレフィックス マッチングまたは部分一致に使用できるように指定するには、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 つのトークンとして扱われます。

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

仕組み

インデックス登録時に、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 にも一致します。

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

次のステップ

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