ドキュメントの検索 (REST API のプレビュー)

適用対象: 2023-07-01-Preview、2021-04-30-Preview、2020-06-30-Preview

重要

2023-07-01-Preview は次を追加します。

  • ベクター クエリ要求を指定する "vector" クエリ パラメーター。 各オブジェクトには、クエリのベクター表現、結果で返される最も近い近隣の数 "k"、クエリの実行中に使用するベクター フィールドが含まれている必要があります。

2021-04-30-Preview は次を追加します。

  • "semanticConfiguration" では 、特定のフィールドに対するスコーピング セマンティック ランク付けがサポートされています。
  • "captions" は、意味的にランク付けされた最も高いドキュメント内の重要な箇所から抽出されたフレーズを返します。

2020-06-30-Preview は次を追加します。

  • "queryType=semantic" では 、セマンティックの再ランク付けと応答がサポートされます。
  • セマンティック クエリの "searchFields" は、キャプションと回答の作成に使用されるフィールドの優先順位を確立します。 この方法は、2021-04-30-Preview で "semanticConfiguration" に置き換えられ、現在は廃止されました。
  • "スペル チェック" を使用すると、クエリ入力のスペル修正が可能になります。
  • "queryType=semantic" と "speller" の両方に "queryLanguage" が必要です。
  • "featuresMode" は、検索スコア、フィールドごとの用語頻度、フィールドごとの類似性スコア、および一意の一致のフィールドごとの数に関するレポートをアンパックします。

クエリ要求は、検索サービス上の 1 つのインデックスのドキュメント コレクションを対象とします。 これには、一致条件を定義するパラメーターと、応答を整形するパラメーターが含まれます。 また、インデックス名自体を使用する代わりに、 インデックスエイリアス を使用して特定のインデックスをターゲットにすることもできます。

ほとんどのクエリでは GET または POST を使用できますが、ベクター クエリ パラメーターが URI 内に収まらないため、ベクター検索には POST を使用する必要があります。 クエリ パラメーター は、GET 要求のクエリ文字列と POST 要求の要求本文で指定されます。

GET https://[service name].search.windows.net/indexes/[index name]/docs?[query parameters] 
  Content-Type: application/json   
  api-key: [admin or query key]  

POST を使用している場合は、URI パラメーターとして "search" アクションを追加します。

POST https://[service name].search.windows.net/indexes/[index name]/docs/search?api-version=[api-version]  
  Content-Type: application/json  
  api-key: [admin or query key]  

GET で呼び出された場合、要求 URL の長さは 8 KB を超えることはできません。 この長さは、ほとんどのアプリケーションで十分です。 ただし、一部のアプリケーションでは、特に OData フィルター式が使用される場合に、大規模なクエリが生成されます。 これらのアプリケーションでは、HTTP POST は GET よりも大きなフィルターを許可するため、より優れた選択肢です。

POST 要求のサイズ制限がほぼ 16 MB であるため、POST を使用する場合は、フィルター文字列のサイズそのものではなく、フィルターに含まれる句の数が制限要因になります。 POST 要求サイズの制限が大きい場合でも、フィルター式を任意に複雑にすることはできません。 フィルターの複雑さの制限の詳細については、「 Azure AI Search の OData 式構文」を参照してください。

URI パラメーター

パラメーター 説明
サービス名 必須。 この名前を、検索サービスの一意のユーザー定義名に設定します。
インデックス名/ドキュメント 必須。 名前付きインデックスの documents コレクションを指定します。 インデックス名の代わりに 、インデックスエイリアス の名前を使用することもできます。
クエリ パラメーター (query parameters) クエリ パラメーターは、GET 要求の URI と POST 要求の要求本文で指定されます。
api-version 必須。 現行バージョンは 2023-07-01-Previewです。 その他 のバージョンについては、「API のバージョン 」を参照してください。

URL エンコードに関する推奨事項

GET REST API を直接呼び出すときは、特定のクエリ パラメーターを URL エンコード することを忘れないでください。 ドキュメントの検索操作では、次のクエリ パラメーターに URL エンコードが必要な場合があります。

  • search
  • $filter
  • facet
  • highlightPreTag
  • highlightPostTag

URL エンコードは、個々のパラメーターにのみ推奨されます。 クエリ文字列全体 (? の後の全部) を気付かずに URL エンコードした場合、要求が壊れます。

また、URL エンコードは、GET を使用して REST API を直接呼び出すときにのみ必要です。 POST を使用する場合、またはエンコードを処理する Azure AI Search .NET クライアント ライブラリを使用する場合は、URL エンコードは必要ありません。

要求ヘッダー

次の表では、必須と省略可能の要求ヘッダーについて説明します。

フィールド 説明
Content-Type 必須。 この値を "application/json" に設定します
api-key Azure ロールを使用していて、要求にベアラー トークンが指定されている場合は省略可能。それ以外の場合はキーが必要です。 api-key は、検索サービスに対する要求を認証する一意のシステム生成文字列です。 ドキュメント コレクションに対するクエリ要求では、API キーとして admin-key または query-key を指定できます。 クエリ キーは、ドキュメント コレクションに対する読み取り専用操作に使用されます。 詳細については、「 キー認証を使用して Azure AI Search に接続 する」を参照してください。

要求本文

GET の場合: なし。

POST の場合:

{  
     "answers": "none" (default) | "extractive", 
     "count": true | false (default),
     "captions": "none" (default) | "extractive",
     "facets": [ "facet_expression_1", "facet_expression_2", ... ],  
     "featuresMode" : "disabled" (default) | "enabled",
     "filter": "odata_filter_expression",  
     "highlight": "highlight_field_1, highlight_field_2, ...",  
     "highlightPreTag": "pre_tag",  
     "highlightPostTag": "post_tag",  
     "minimumCoverage": # (% of index that must be covered to declare query successful; default 100),  
     "orderby": "orderby_expression",
     "queryLanguage": "en-us" (default) | (a supported language code), 
     "queryType": "simple" (default) | "full" | "semantic",
     "scoringParameters": [ "scoring_parameter_1", "scoring_parameter_2", ... ],  
     "scoringProfile": "scoring_profile_name",  
     "scoringStatistics" : "local" (default) | "global",
     "search": "simple_query_expression",  
     "searchFields": "field_name_1, field_name_2, ...",  
     "searchMode": "any" (default) | "all",  
     "select": "field_name_1, field_name_2, ...",  
     "semanticConfiguration": "semantic_configuration_name",
     "sessionId" : "session_id",
     "skip": # (default 0), 
     "speller": "none" (default) | "lexicon",  
     "top": #,
     "vectors": [
      {
        "value": "a vector representation of the query",
        "k": an integer (number of nearest neighbors to return as top results),
        "fields": "a comma-delimited list of vector fields to use in the query"
      }
     ]
   }  

部分的な検索応答の継続

Azure AI Search が、要求されたすべての結果を 1 つの Search 応答で返さない場合があります。 部分的な応答は、$topを指定しない、または大きすぎる $ top の値を指定することによって、クエリから返されるドキュメントの数が多すぎる場合など、さまざまな理由で発生する可能性があります。 このような場合、Azure AI Search には応答本文に注釈が含まれ、POST 要求の場合も@search.nextPageParameters含@odata.nextLinkまれます。 これらの注釈の値を使用して別の Search 要求を作成して、検索応答の次の部分を取得できます。 この動作は、元の Search 要求の 継続 と呼ばれ、注釈は 継続トークンと呼ばれます。 これらの注釈の構文と、それらが応答本文に表示される場所の詳細については、「応答」セクションの例を参照してください。

Azure AI Search が継続トークンを返す理由は実装固有であり、変更される可能性があります。 堅牢なクライアントでは、返されたドキュメントが予想よりも少なく、ドキュメントの取得を継続するために継続トークンが含まれている場合を処理する準備が常にできている必要があります。 また、継続するためには、元の要求と同じ HTTP メソッドを使用する必要がある点にも注意してください。 たとえば、GET 要求を送信した場合、送信する継続の要求でも GET を使用する必要があります (POST の場合も同様です)。

注意

と @search.nextPageParameters の@odata.nextLink目的は、ページングの一般的なメカニズムを提供するのではなく、要求する結果が多すぎるクエリからサービスを保護することです。 結果をページングする場合は、$topと$skipを一緒に使用します。 たとえば、サイズ 10 のページが必要な場合、最初の要求には $top=10、$skip=0、2 番目の要求には $top=10、$skip=10、3 番目の要求には $top=10 と $skip=20 などが必要です。

クエリ パラメーター

クエリでは、GET を使用して呼び出された場合は URL に対して複数のパラメーターを受け入れ、POST で呼び出された場合は要求本文の JSON プロパティとして受け取ります。 いくつかのパラメーターの構文は、GET および POST の間で多少異なります。 これらの違いを次の表に示します。

名前 説明
回答 (プレビュー) string 省略可能。 有効な値は "none" と "extractive" です。 既定値は "none" です。 このパラメーターは、クエリの種類が "セマンティック" の場合にのみ有効です。 "extractive" に設定すると、クエリは、最も高い意味でランク付けされたドキュメントの主要な箇所から回答を作成して返します。 既定値は 1 つの回答ですが、カウントを追加することで最大 10 個を指定できます。 たとえば、"answers": "extractive|count-3" は 3 つの回答を返します。 回答を返すには、対象フィールドに回答のような逐語的なコンテンツが存在する必要があります。 回答に使用される言語モデルは、回答を生成せずに認識するようにトレーニングされます。 さらに、クエリ自体は質問のように見えます。
api-version string 必須。 要求に使用される REST API のバージョン。 サポートされているバージョンの一覧については、「API の バージョン」を参照してください。 この操作では、GET と POST のどちらを使用して ドキュメントの検索 を呼び出すかに関係なく、API バージョンが URI パラメーターとして指定されます。
captions (プレビュー) string 省略可能。 有効な値は "none" と "extractive" です。 既定値は "none" です。 このパラメーターは、クエリの種類が "セマンティック" の場合にのみ有効です。 "extractive" に設定すると、クエリは、最上位のランク付けされたドキュメントの主要な部分から抽出されたキャプションを返します。 キャプションが 'extractive' に設定されている場合、強調表示は既定で有効になり、パイプ文字 '|' の後に 'highlight-true</false>' オプション ("extractive|highlight-true" など) を追加して構成できます。
$count boolean 任意。 有効な値は true または false です。 既定値は "false" です。 POST を使用して呼び出されると、このパラメーターは $countではなく count という名前になります。 結果の合計数を取得するかどうかを指定します。 この値は、$topと$skipを無視して、検索パラメーターと$filterパラメーターに一致するすべてのドキュメントの数です。 この値を "true" に設定すると、パフォーマンスが低下する可能性があります。 インデックスが安定している場合、カウントは正確ですが、アクティブに追加、更新、または削除されたドキュメントの下または過剰レポートが行われます。 ドキュメントなしでカウントのみを取得する場合は、$top=0 を使用できます。
ファセットまたはファセット string 省略可能。 ファセットの対象となるフィールド。フィールドは "ファセット可能" として属性付けされます。 GET を使用して呼び出された場合、 facet はフィールド (facet: field1) です。 POST で呼び出されると、このパラメーターの名前 facets は ではなく facet 、配列 (facets: [field1, field2, field3]) として指定されます。 文字列には、コンマ区切りの名前と値のペアとして表されるファセットをカスタマイズするためのパラメーターを含めることができます。

有効な値は、"count"、"sort"、"values"、"interval"、および "timeoffset" です。

"count" はファセット用語の最大数です。既定値は 10 です。 用語の数に上限はありませんが、値が大きいほどパフォーマンスが低下します。特に、ファセット フィールドに多数の一意の用語が含まれている場合です。 たとえば、"facet=category,count:5" はファセット結果の上位 5 つのカテゴリを取得します。 count パラメーターが一意の用語の数より少ない場合、結果が正確でない可能性があります。 これは、ファセット クエリがシャード間に分散される方法のためです。 すべてのシャードで正確な数を取得するには、count を 0 に設定するか、ファセット可能フィールドの一意の値の数以上の値に設定できます。 トレードオフは待機時間が長くなります。

"sort" は"count"、"-count"、"value"、"-value" に設定できます。 count を使用して count で降順に並べ替えます。 count で昇順に並べ替えるには、-count を使用します。 value を使用して値で昇順に並べ替えます。 値で降順に並べ替えるには、-value を使用します (たとえば、"facet=category,count:3,sort:count" はファセットの上位 3 つのカテゴリを取得し、各都市名を持つドキュメントの数で降順になります)。 上位 3 つのカテゴリが Budget、Motel、Luxury、Budget の 5 つのヒット数、モーテルのヒット数が 6、ラグジュアリーが 4 の場合、バケットはモーテル、予算、ラグジュアリーの順になります。 -value の場合、"facet=rating,sort:-value" は、可能なすべての評価のバケットを値順に降順で生成します (たとえば、評価が 1 から 5 の場合、バケットは、各評価に一致するドキュメントの数に関係なく、5、4、3、2、1 という順序になります)。

"values" は、ファセット エントリ値の動的なセットを指定するパイプ区切りの数値または Edm.DateTimeOffset 値に設定できます (例: "facet=baseRate,values:10 |20" は、3 つのバケットを生成します。1 つは基本レート 0 から 10 までで、1 つは 10 個までで、20 個は含まれません。1 つは 20 以上の場合は 1 つ)。 文字列 "facet=lastRenovationDate,values:2010-02-01T00:00:00Z" は、2010 年 2 月より前に改装されたホテル用と、2010 年 2 月 1 日以降に改装されたホテル用の 2 つのバケットを生成します。 期待される結果を得るには、値を昇順で一覧表示する必要があります。

"interval" は、数値の場合は 0 より大きい整数の間隔、日付の時刻値の場合は分、時、日、週、月、四半期、年です。 たとえば、"facet=baseRate,interval:100" は、サイズ 100 の基本レート範囲に基づいてバケットを生成します。 基本レートがすべて $60 から $600 の間にある場合は、0 から 100、100-200、200-300、300-400、400-500、500-600 のバケットがあります。 文字列 "facet=lastRenovationDate,interval:year" は、ホテルの改装時に毎年 1 つのバケットを生成します。

"timeoffset" は ([+-]hh:mm、[+-]hhmm、または [+-]hh) に設定できます。 timeoffset パラメーターを使用する場合は、Edm.DateTimeOffset 型のフィールドに適用する場合にのみ、timeoffset パラメーターを interval オプションと組み合わせる必要があります。 この値によって、時間の境界の設定における UTC 時刻のオフセットを指定します。 たとえば、"facet=lastRenovationDate,interval:day,timeoffset:-01:00" は、01:00:00 UTC (ターゲット タイム ゾーンの午前 0 時) から始まる日の境界を使用します。

count と sort は同じファセット仕様で結合できますが、間隔または値と組み合わせることはできません。interval と値を組み合わせることはできません。

日時の間隔ファセットは、時刻オフセットが指定されていない場合、UTC 時刻に基づいて計算されます。 たとえば、"facet=lastRenovationDate,interval:day" の場合、日の境界は UTC の 00:00:00 から始まります。
featuresMode (プレビュー) boolean 任意。 有効な値は "enabled" と "disabled" です。 既定値は "無効" です。 フィールドごとの類似性など、クエリに関連するドキュメントの関連性スコアを計算するために使用されるクエリ 結果機能を結果に含めるかどうかを示す値。 "enabled" を使用して、より多くのクエリ結果機能 (フィールドごとの類似性スコア、フィールド用語の頻度、一致する一意のトークンのフィールド数ごと) を公開します。 詳細については、「 類似性とスコアリング」を参照してください。
$filter string 省略可能。 標準の OData 構文で構造化された検索式です。 フィルターで使用できるのは、フィルター可能なフィールドだけです。 POST を使用して呼び出されると、このパラメーターは $filterではなく filter という名前になります。 Azure AI Search でサポートされている OData 式文法のサブセットの詳細については、「Azure AI Search の OData 式構文」を参照してください。
highlight string 省略可能。 ヒット ハイライトに使用する一連のフィールド名で、コンマで区切ります。 検索可能なフィールドのみを、ヒット強調表示に使用できます。 既定では、Azure AI Search はフィールドごとに最大 5 つの強調表示を返します。 フィールド名の後に "-<max # の強調表示" を追加することで、>フィールドごとに制限を構成できます。 たとえば、"highlight=title-3,description-10" は、タイトル フィールドから最大 3 つの強調表示されたヒットを返し、説明フィールドから最大 10 件のヒットを返します。 強調表示の最大数は、1 から 1000 までの整数である必要があります。
highlightPostTag string 任意。 既定値は "</em>" です。 強調表示された用語に追加する文字列タグ。 highlightPreTag を使用して設定する必要があります。 URL の予約済みの文字は、パーセントでエンコードする必要があります (たとえば、# ではなく %23)。
highlightPreTag string 任意。 既定値は "</em>" です。 強調表示された用語の先頭に付加する文字列タグ。 highlightPostTag を使用して設定する必要があります。 URL の予約済みの文字は、パーセントでエンコードする必要があります (たとえば、# ではなく %23)。
minimumCoverage 整数 (integer) 省略可能。 有効な値は 0 ~ 100 の数値で、クエリを成功として報告する前にクエリを処理するために使用できるインデックスの割合を示します。 既定値は "100" です。

100% のカバレッジは、すべてのシャードが要求に応答したことを意味します (サービス正常性の問題もメンテナンス アクティビティもカバレッジが減少しません)。 既定の設定では、フル カバレッジ未満では HTTP 状態コード 503 が返されます。

minimumCoverage を下げると、503 エラーが発生していて、クエリが成功する可能性を高めたい場合 (特に、1 つのレプリカに対して構成されているサービスの場合) に役立ちます。 minimumCoverage を設定し、Search が成功すると、HTTP 200 が返され、クエリに含まれていたインデックスの割合を示す値が応答に含まれます @search.coverage 。 このシナリオでは、一致するすべてのドキュメントが検索結果に表示されるとは限りませんが、検索の可用性がリコールよりも重要な場合は、カバレッジを減らすことが実行可能な軽減戦略になる可能性があります。
$orderby string 省略可能。 結果を並べ替える式の一覧で、コンマで区切ります。 POST で呼び出されると、このパラメーターの名前は、$orderbyではなく orderby になります。 各式には、フィールド名または geo.distance() 関数の呼び出しを指定できます。 各式の後に "asc" を続けて昇順を示し、降順を示す "desc" を指定できます。 並べ替えフィールドに null 値がある場合、null は最初に昇順で、最後は降順で表示されます。 既定値は昇順です。 結び付きは、ドキュメントの一致スコアによって切り離されます。 $orderbyが指定されていない場合、既定の並べ替え順序はドキュメント一致スコアの降順になります。 $orderbyには 32 個の句の制限があります。
queryLanguage (プレビュー) string 省略可能。 有効な値は 、サポートされている言語です。 既定値は "en-us" です。 speller=lexicon または queryType=semantic を使用する場合は、このパラメーターを設定する必要があります。 queryLanguage で指定された言語は、スペル チェックと、結果を再ランク付けしてキャプションまたは回答を抽出するセマンティック モデルの両方に使用されます。 queryLanguage に使用されるライブラリは、インデックス作成やフルテキスト検索に使用される 言語アナライザー など、他のロケールベースのフィールド属性とは無関係です。
queryType string 省略可能。 有効な値は、"simple"、"full"、または "semantic" (プレビュー) です。 既定値は "simple" です。 この値はベクター検索では無視されますが、ハイブリッド シナリオのテキスト検索に適用されます。

"simple" は、 などの+*シンボルを許可する単純なクエリ構文を使用してクエリ文字列を""解釈します。 クエリは、既定で各ドキュメント内のすべての検索可能なフィールド (または searchFields で示されているフィールド) で評価されます。

"full" は、完全 な Lucene クエリ構文 を使用してクエリ文字列を解釈します。これにより、フィールド固有の加重検索が可能になります。 Lucene クエリ言語での範囲検索は、同様の機能

を提供する$filterを優先してサポートされていません。"semantic" は、キーワードではなく自然言語で表現されたクエリに対して、Bing コーパスでトレーニングされたランク付けモデルを使用して上位 50 件の一致を再ランク付けすることで、検索結果の精度を向上させます。 クエリの種類を semantic に設定する場合は、queryLanguage と semanticConfiguration も設定する必要があります。 クエリ入力が自然言語で定式化された場合に上位 3 つの回答も返す場合は、必要に応じて回答を設定できます。また、必要に応じてキャプションを設定して、最もランクの高いドキュメントから主要な部分を抽出することもできます。
scoringParameter string 省略可能。 "name-value1,value2,..." の形式を使用して、スコアリング関数 (referencePointParameter など) で定義されている各パラメーターの値を示します。POST で呼び出されると、このパラメーターの名前は scoringParameter ではなく scoringParameters になります。 また、各文字列が個別の名前と値のペアである文字列の JSON 配列として指定します。

関数を含むスコアリング プロファイルの場合は、関数を入力リストから文字で - 区切ります。 たとえば、 という "mylocation" 関数は "&scoringParameter=mylocation--122.2,44.8" になります。 最初のダッシュは関数名を値リストから区切り、2 番目のダッシュは最初の値 (この例では経度) の一部です。

コンマを含めることができるタグブーストなどのスコアリング パラメーターの場合は、一重引用符を使用してリスト内のそのような値をエスケープできます。 値自体に単一引用符が含まれる場合は、2 個入力することでエスケープできます。 という名前のタグブースト パラメーター "mytag" があり、タグ値 "Hello, O'Brien" と "Smith" をブーストする場合、クエリ文字列オプションは "&scoringParameter=mytag-'Hello, O'Brien',Smith" になります。 引用符は、コンマを含む値にのみ必要です。
scoringProfile string 省略可能。 結果を並び替えるために一致ドキュメントの一致スコアを評価するスコア付けプロファイルの名前。
scoringStatistics string 省略可能。 有効な値は "local" または "global" です。 既定値は "local" です。 より一貫性のあるスコアリングを行うために、ドキュメントの頻度などのスコアリング統計をグローバルに (すべてのシャードにわたって) 計算するか、待機時間を短くするためにローカル (現在のシャード) で計算するかを指定します。 「Azure AI Search でのスコアリング統計」を参照してください。 スコアリング統計は、 あいまい検索 ('~') を使用する用語に対して常にローカルで計算されます。
search string 省略可能。 検索するテキストです。 この値はベクター検索では無視されますが、ハイブリッド シナリオのテキスト検索に適用されます。 REST API では、searchFields が指定されていない限り、検索可能なすべてのフィールドが既定で検索されます。 インデックスでは、検索可能なフィールド内のテキストはトークン化されるため、複数の用語を空白で区切ることができます (例: 'search=hello world')。 任意の語句と一致させるには、 * を使用します (これはブール型フィルターのクエリに便利です)。 このパラメーターを省略することは、 *に設定するのと同じ効果を持ちます。 検索構文の詳細については、 簡単なクエリ構文 に関するページを参照してください。

検索可能なフィールドに対してクエリを実行すると、結果が驚くことがあります。 トークナイザには、アポストロフィや数字の中のコンマのように、英語のテキストによく使用されているケースを処理するロジックが含まれています。 たとえば、'search=123,456' は、個々の用語 '123' と '456' ではなく、単一の用語 '123,456' と一致します。これは、コンマは英語の大きな数値の桁区切り記号として使用されるためです。 このため、検索パラメーターで用語を区切るために句読点ではなく空白を使用することをお勧めします。
searchMode string 省略可能。 有効な値は "any" または "all" です。既定値は "any" です。 一致ドキュメントをカウントする上で、検索用語の一部が一致すればよいか、それともすべて一致する必要があるかを指定します。
searchFields string 省略可能。 指定したテキストを検索するフィールド名の一覧であり、コンマで区切ります。 ターゲット フィールドは、インデックス スキーマで検索可能としてマークする必要があり、型 Edm.Stringは 、 Edm.ComplexType、または Collection(Edm.String)である必要があります。
$select string 省略可能。 結果セットに含めるコンマ区切りのフィールドの一覧。 この句には、取得可能としてマークされたフィールドのみを含めることができます。 指定しない場合、または *に設定した場合は、スキーマで取得可能とマークされているすべてのフィールドが含まれます。 POST を使用して呼び出されると、このパラメーターには、$selectではなく select という名前が付けられます。
semanticConfiguration (プレビュー) string 省略可能。 queryType="semantic" の場合は必須です。 セマンティックランク付け、キャプション、強調表示、回答に使用するフィールドを一覧表示するセマンティック構成の名前。 詳細については、「セマンティック クエリを作成する」を参照してください。
sessionID string 省略可能。 sessionId を使用すると、複数のレプリカを持つ検索サービスの関連性スコアの一貫性を向上させることができます。 マルチレプリカ構成では、同じクエリに対する個々のドキュメントの関連性スコアに若干の違いがある場合があります。 セッション ID が指定されると、サービスは、特定の要求をそのセッションの同じレプリカにルーティングするためのベスト エフォートを行います。 同じセッション ID 値を繰り返し再利用すると、レプリカ間での要求の負荷分散が妨げられ、検索サービスのパフォーマンスに悪影響を及ぼす可能性があります。 sessionId として使用される値は、'_' 文字で始めることはできません。 サービスにレプリカがない場合、このパラメーターはパフォーマンスやスコアの一貫性には影響しません。
$skip 整数 (integer) 省略可能。 スキップする検索結果の数です。 POST で呼び出されると、このパラメーターの名前は、$skipではなく skip になります。 この値は 100,000 を超えることはできません。 ドキュメントを順番にスキャンする必要があるが、この制限により$skipを使用できない場合は、インデックス内のすべてのドキュメントに一意の値を持つフィールド (ドキュメント キーなど) に対して$orderbyを使用し、代わりに範囲クエリで$filterすることを検討してください。
スペル チェック (プレビュー) String 省略可能。 有効な値は、"none" と "lexicon" です。 既定値は "none" です。 個々の検索クエリ用語をスペル修正することで、呼び戻しを改善します。 単純、完全、セマンティックのクエリ型で使用できます。 スペル チェック パラメーターを使用する場合は、queryLanguage が必要です。 詳細と例については、「クエリにスペル チェックを追加する」を参照してください。
$top 整数 (integer) 省略可能。 取得する検索結果の数です。 既定値は 50 です。 POST で呼び出されると、このパラメーターの名前は、$topではなく top になります。 1000 より大きい値を指定し、結果が 1,000 を超える場合は、最初の 1000 件の結果のみが、結果の次のページへのリンクと共に返されます (次の例の「@odata.nextLink」を参照してください)。

Azure AI Search では 、サーバー側のページングを 使用して、クエリが一度に取得するドキュメントが多すぎるのを防ぎます。 既定のページ サイズは 50 で、最大ページ サイズは 1000 です。 つまり、$topを指定しない場合、既定で 検索ドキュメント は最大 50 件の結果を返します。 結果が 50 を超える場合、応答には最大 50 件の結果の次のページを取得するための情報が含まれます (以下の の「@odata.nextLink」および「@search.nextPageParameters」を参照してください)。 同様に、$topに 1000 より大きい値を指定し、結果が 1000 を超える場合は、最初の 1,000 件の結果のみが返され、最大 1,000 件の結果の次のページを取得する情報も返されます。
ベクトル (プレビュー) array 省略可能。 配列内のオブジェクト型はベクター クエリです。 ベクター クエリのクエリ パラメーター。

"value" は、検索クエリのベクター表現です。 この表現は、外部で形成する必要があります。 Azure AI Search では埋め込みは作成されません。

"k" は、トップ ヒットとして返される最も近い近傍の数を指定する整数です。 既定値は 50 です。 最小値は 1、最大値は 10,000 です。

"fields" は、ベクター データを含むコンマ区切りのリスト フィールド名です。 型の Collection(Edm.Single) フィールドのみを "fields" リストに含めることができます。

Response

状態コード: 応答の成功に対して「200 OK」が返されます。 この記事には、セマンティック検索と featuresMode の 2 つのサンプル応答があります。

セマンティック クエリの応答のサンプル

最初の例は、セマンティック クエリ "how do cloud form" の最上位の結果に対する完全な応答を示しています。

  • "@search.answers" は、answers パラメーターを指定し、クエリとインデックス内の対象フィールドに回答として認識できるコンテンツが含まれている場合に表示されます。 @search.answersキー、テキスト、強調表示を含む配列。 スコアは、回答の強さを示す指標です。

  • "value" は応答の本文です。 @search.rerankerScoreはセマンティック ランク付けアルゴリズムによって割り当てられ、結果のランク付けに使用されます (@search.score は、最初の結果をスコア付けするときに使用される BM25 類似性アルゴリズムからのものです)。 キャプションには、プレーン テキストと強調表示されたバージョンが含まれます。 この例は、OCR とエンティティ認識スキルを使用して作成されました。 抽出されたコンテンツとマージされたコンテンツのフィールドが応答に含まれます。

{
    "@search.answers": [
        {
            "key": "aHR0cHM6Ly9oZWlkaXN0YmxvYnN0b3JhZ2UuYmxvYi5jb3JlLndpbmRvd3MubmV0L25hc2EtZWJvb2stMS01MC9wYWdlLTQ1LnBkZg2",
            "text": "Sunlight heats the land all day, warming that moist air and causing it to rise high into the atmosphere until it cools and condenses into water droplets. Clouds generally form where air is ascending (over land in this case),   but not where it is descending (over the river).",
            "highlights": "Sunlight heats the land all day, warming that moist air and causing it to rise high into the   atmosphere until it cools and condenses into water droplets. Clouds generally form<em> where air is ascending</em> (over land in this case),   but not where it is<em> descending</em> (over the river).",
            "score": 0.94639826
        }
    ],
    "value": [
        {
            "@search.score": 0.5479723,
            "@search.rerankerScore": 1.0321671911515296,
            "@search.captions": [
                {
                    "text": "Like all clouds, it forms when the air reaches its dew point—the temperature at which an air mass is cool enough for its water vapor to condense into liquid droplets. This false-color image shows valley fog, which is common in the Pacific Northwest of North America.",
                    "highlights": "Like all<em> clouds</em>, it<em> forms</em> when the air reaches its dew point—the temperature at    which an air mass is cool enough for its water vapor to condense into liquid droplets. This false-color image shows valley<em> fog</em>, which is common in the Pacific Northwest of North America."
                }
            ],
            "content": "\nA\nT\n\nM\nO\n\nS\nP\n\nH\nE\n\nR\nE\n\nE\nA\n\nR\nT\n\nH\n\n34\n\nValley Fog\nCanada\n\nFog is essentially a cloud lying on the ground. Like all clouds, it forms when the air reaches its dew point—the temperature at  \n\nwhich an air mass is cool enough for its water vapor to condense into liquid droplets.\n\nThis false-color image shows valley fog, which is common in the Pacific Northwest of North America. On clear winter nights, the \n\nground and overlying air cool off rapidly, especially at high elevations. Cold air is denser than warm air, and it sinks down into the \n\nvalleys. The moist air in the valleys gets chilled to its dew point, and fog forms. If undisturbed by winds, such fog may persist for \n\ndays. The Terra satellite captured this image of foggy valleys northeast of Vancouver in February 2010.\n\n\n",
            "metadata_storage_path": "aHR0cHM6Ly9oZWlkaXN0YmxvYnN0b3JhZ2UuYmxvYi5jb3JlLndpbmRvd3MubmV0L25hc2EtZWJvb2stMS01MC9wYWdlLTQxLnBkZg2",
            "people": [],
            "locations": [
                "Pacific Northwest",
                "North America",
                "Vancouver"
            ],
            "merged_content": "\nA\nT\n\nM\nO\n\nS\nP\n\nH\nE\n\nR\nE\n\nE\nA\n\nR\nT\n\nH\n\n34\n\nValley Fog\nCanada\n\nFog is essentially a cloud lying on the ground. Like all clouds, it forms when the air reaches its dew point—the temperature at  \n\nwhich an air mass is cool enough for its water vapor to condense into liquid droplets.\n\nThis false-color image shows valley fog, which is common in the Pacific Northwest of North America. On clear winter nights, the \n\nground and overlying air cool off rapidly, especially at high elevations. Cold air is denser than warm air, and it sinks down into the \n\nvalleys. The moist air in the valleys gets chilled to its dew point, and fog forms. If undisturbed by winds, such fog may persist for \n\ndays. The Terra satellite captured this image of foggy valleys northeast of Vancouver in February 2010.\n\n\n",
            "text": [],
            "layoutText": []
        }
    ]
}

featuresMode の応答のサンプル

この例では、featuresMode を含むクエリからの "@search.features" 出力を示します。

  {
    "@odata.count": # (if $count=true was provided in the query),
    "@search.coverage": # (if minimumCoverage was provided in the query),
    "@search.facets": { (if faceting was specified in the query)
      "facet_field": [
        {
          "value": facet_entry_value (for non-range facets),
          "from": facet_entry_value (for range facets),
          "to": facet_entry_value (for range facets),
          "count": number_of_documents
        }
      ],
      ...
    },
    "@search.nextPageParameters": { (request body to fetch the next page of results if not all results could be returned in this response and Search was called with POST)
      "count": ... (value from request body if present),
      "facets": ... (value from request body if present),
      "featuresMode" : ... (value from request body if present),
      "filter": ... (value from request body if present),
      "highlight": ... (value from request body if present),
      "highlightPreTag": ... (value from request body if present),
      "highlightPostTag": ... (value from request body if present),
      "minimumCoverage": ... (value from request body if present),
      "orderby": ... (value from request body if present),
      "scoringParameters": ... (value from request body if present),
      "scoringProfile": ... (value from request body if present),
      "scoringStatistics": ... (value from request body if present),
      "search": ... (value from request body if present),
      "searchFields": ... (value from request body if present),
      "searchMode": ... (value from request body if present),
      "select": ... (value from request body if present),
      "sessionId" : ... (value from request body if present),
      "skip": ... (page size plus value from request body if present),
      "top": ... (value from request body if present minus page size),
    },
    "value": [
      {
        "@search.score": document_score (if a text query was provided),
        "@search.highlights": {
          field_name: [ subset of text, ... ],
          ...
        },
        "@search.features": {
          "field_name": {
            "uniqueTokenMatches": feature_score,
            "similarityScore": feature_score,
            "termFrequency": feature_score,
          },
          ...
        },
        key_field_name: document_key,
        field_name: field_value (retrievable fields or specified projection),
        ...
      },
      ...
    ],
    "@odata.nextLink": (URL to fetch the next page of results if not all results could be returned in this response; Applies to both GET and POST)
  }

その他の例については、「 Azure AI Search の OData 式構文」を参照してください。

例: 単純検索

簡単なクエリ構文を使用して、インデックス内のドキュメントを検索します。 このクエリは、検索可能なフィールドに語句 "comfort" および "location" が含まれていて "motel" が含まれないホテルを返します。

Get /indexes/hotels/docs?search=comfort +location –motel&searchMode=all&api-version=2021-04-30-Preview
POST /indexes/hotels/docs/search?api-version=2021-04-30-Preview
    {  
      "search": "comfort +location -motel",  
      "searchMode": "all"  
    }  

ヒント

searchMode=all を使用すると、既定の searchMode=any がオーバーライドされ、-motel が「OR NOT」ではなく「AND NOT」を意味します。 searchMode=allを指定しないと、検索結果を制限するのではなく拡大する "OR NOT" になり、一部のユーザーにとっては直感に反している可能性があります。

例: 完全な Lucene 検索

Lucene クエリ構文を使用して、インデックス内のドキュメントを検索します ( 「Azure AI Search での Lucene クエリ構文」を参照してください)。 このクエリは、カテゴリ フィールドに "budget" (低料金) が含まれ、すべての検索可能なフィールドに "recently renovated" (最近改修済み) というフレーズが含まれるホテルを返します。 "recently renovated" というフレーズを含むドキュメントは、用語のブースト値 (3) の結果、高いランクになります。

GET /indexes/hotels/docs?search=Category:budget AND \"recently renovated\"^3&searchMode=all&api-version=2021-04-30-Preview&querytype=full`
POST /indexes/hotels/docs/search?api-version=2021-04-30-Preview
    {  
      "search": "Category:budget AND \"recently renovated\"^3",  
      "queryType": "full",  
      "searchMode": "all"  
}  

例: セマンティック検索

回答、キャプション、強調表示されたコンテンツを使用してセマンティック ランク付けモデルを呼び出します。 このクエリの応答は、前のセクションで確認できます。

POST /indexes/hotels/docs/search?api-version=2021-04-30-Preview
{
  "search": "how do clouds form",
  "queryType": "semantic",
  "semanticConfiguration": "my-semantic-config",
  "queryLanguage": "en-us",
  "answers": "extractive",
  "captions": "extractive",
  "count": "true"
}

例: ベクター検索

Collection(Edm.Single) のフィールドとベクター構成を持つインデックスの場合は、ベクター クエリ パラメーターを指定できます。 ベクター クエリ パラメーターには、クエリのスコープ内にあるベクター フィールド、返される上位ヒットの "k" 数、クエリ入力のベクター表現が含まれます。

"select" パラメーターの追加は、インデックスにテキスト フィールドが含まれている場合に役立ちます。 照合と関連性はベクトルに基づいていますが、人間が判読できるコンテンツを含むフィールドは、結果を読む人にとってより便利です。 または、検索結果のベクター データをテキストに変換するコードを記述することもできます。

POST https://{{search-service-name}}.search.windows.net/indexes/{{index-name}}/docs/search?api-version={{api-version}}
Content-Type: application/json
api-key: {{admin-api-key}}
{
    "search": (this parameter is ignored in vector search),
    "vectors": [{
        "value": [
            -0.009154141,
            0.018708462,
            . . . 
            -0.02178128,
            -0.00086512347
        ],
        "fields": "contentVector",
        "k": 5
    }],
    "select": "title, content, category"
}

例: orderby

インデックスを検索し、日付順に並べ替えられた結果を返します。

GET /indexes/hotels/docs?search=*&$orderby=LastRenovationDate desc&api-version=2021-04-30-Preview
POST /indexes/hotels/docs/search?api-version=2021-04-30-Preview
    {  
      "search": "*",  
      "orderby": "LastRenovationDate desc"
    }  

例: OData 式を使用してフィルター処理する

特定のフィルター式に一致するドキュメントを取得します。

GET /indexes/hotels/docs?$filter=(Rooms/BaseRate ge 60 and Rooms/BaseRate lt 300) or HotelName eq 'Fancy Stay'&api-version=2021-04-30-Preview
POST /indexes/hotels/docs/search?api-version=2021-04-30-Preview
    {  
      "filter": "(Rooms/BaseRate ge 60 and Rooms/BaseRate lt 300) or HotelName eq 'Fancy Stay'"  
    }  

例: ファセット検索

ファセット検索では、インデックスを検索し、カテゴリ、評価、タグ、および特定の範囲の baseRate を持つ項目のファセットを取得します。

GET /indexes/hotels/docs?search=*&facet=Category&facet=Rating&facet=Tags&facet=Rooms/BaseRate,values:80|150|220&api-version=2021-04-30-Preview
POST /indexes/hotels/docs/search?api-version=2021-04-30-Preview
    {  
      "search": "test",  
      "facets": [ "Category", "Rating", "Tags", "Rooms/BaseRate,values:80|150|220" ]  
    }  

最後のファセットがサブフィールド上にあることに注意してください。 ファセットは親ドキュメント (Hotels) をカウントし、中間サブドキュメント (Rooms) はカウントしないため、応答によって各価格バケットに部屋があるホテルの数が決定されます。

例: ファセット クエリを絞り込む

フィルターを使用して、ユーザーが Rating 3 とカテゴリ "Motel" を選択した後に、前のファセット クエリ結果を絞り込みます。

GET /indexes/hotels/docs?search=*&facet=tags&facet=Rooms/BaseRate,values:80|150|220&$filter=Rating eq 3 and Category eq 'Motel'&api-version=2021-04-30-Preview  
POST /indexes/hotels/docs/search?api-version=2021-04-30-Preview 
    {  
      "search": "test",  
      "facets": [ "tags", "Rooms/BaseRate,values:80|150|220" ],  
      "filter": "Rating eq 3 and Category eq 'Motel'"  
    }  

例: 各カテゴリに制限があるファセット検索

ファセット検索で、クエリで返される一意の語句に上限を設定します。 既定値は 10 ですが、ファセット属性でカウント パラメーターを使用することで、この値を増減できます。 この例では、5 に制限された、都市のファセットを返します。

GET /indexes/hotels/docs?search=*&facet=Address/City,count:5&api-version=2021-04-30-Preview
POST /indexes/hotels/docs/search?api-version=2021-04-30-Preview
    {  
      "search": "test",  
      "facets": [ "Address/City,count:5" ]  
    }  

例: フィールド内検索

特定のフィールド (言語フィールドなど) 内のインデックスを検索する

GET /indexes/hotels/docs?search=hôtel&searchFields=Description_fr&api-version=2021-04-30-Preview
POST /indexes/hotels/docs/search?api-version=2021-04-30-Preview
    {  
      "search": "hôtel",  
      "searchFields": "Description_fr"
    }  

複数のフィールドでインデックスを検索します。 たとえば、複数の言語の検索可能なフィールドをすべて同じインデックスに格納してクエリできます。 同じドキュメントに英語とフランス語の説明が共存する場合は、クエリ結果の一部またはすべてを返すことができます。

GET /indexes/hotels/docs?search=hotel&searchFields=Description,Description_fr&api-version=2021-04-30-Preview
POST /indexes/hotels/docs/search?api-version=2021-04-30-Preview
    {  
      "search": "hotel",  
      "searchFields": "Description, Description_fr"
    }  

クエリを実行できるのは、一度に 1 つのインデックスのみです。 一度に 1 つずつクエリを実行する予定がない限り、言語ごとに複数のインデックスを作成しないでください。

例: ページングの結果

アイテムの最初のページを取得します (ページ サイズは 10)。

GET /indexes/hotels/docs?search=*&$skip=0&$top=10&api-version=2021-04-30-Preview
POST /indexes/hotels/docs/search?api-version=2021-04-30-Preview
    {  
      "search": "*",  
      "skip": 0,  
      "top": 10  
    }  

アイテムの 2 ページ目を取得します (ページ サイズは 10)。

GET /indexes/hotels/docs?search=*&$skip=10&$top=10&api-version=2021-04-30-Preview
POST /indexes/hotels/docs/search?api-version=2021-04-30-Preview
    {  
      "search": "*",  
      "skip": 10,  
      "top": 10  
    }  

例: 結果セット内のフィールドを制限する

特定のフィールドのセットを取得します。

GET /indexes/hotels/docs?search=*&$select=HotelName,Description&api-version=2021-04-30-Preview
POST /indexes/hotels/docs/search?api-version=2021-04-30-Preview
    {  
      "search": "*",  
      "select": "HotelName, Description"
    }  

例: 結果の強調表示をヒットする

インデックスを検索し、ヒット ハイライトでフラグメントを返します。

GET /indexes/hotels/docs?search=something&highlight=Description&api-version=2021-04-30-Preview
POST /indexes/hotels/docs/search?api-version=2021-04-30-Preview
    {  
      "search": "something",  
      "highlight": "Description"  
    }  

例: 地理空間検索

インデックスを検索し、参照場所に近いものから順番に並べられたドキュメントを返します。

GET /indexes/hotels/docs?search=something&$orderby=geo.distance(Location, geography'POINT(-122.12315 47.88121)')&api-version=2021-04-30-Preview
POST /indexes/hotels/docs/search?api-version=2021-04-30-Preview
    {  
      "search": "something",  
      "orderby": "geo.distance(Location, geography'POINT(-122.12315 47.88121)')"
    }  

例: "自分で検索" (近くの場所の関連性を高める)

"geo" というスコアリング プロファイルがあり、2 つの距離スコアリング関数があり、もう 1 つは "currentLocation" というパラメーターを定義し、もう 1 つは "lastLocation" というパラメーターを定義している場合にインデックスを検索します。 次の例では、"currentLocation" には 1 つのダッシュ (-) の区切り記号があります。 その後に経度と緯度の座標が続きます。経度は負の値です。

GET /indexes/hotels/docs?search=something&scoringProfile=geo&scoringParameter=currentLocation--122.123,44.77233&scoringParameter=lastLocation--121.499,44.2113&api-version=2021-04-30-Preview
POST /indexes/hotels/docs/search?api-version=2021-04-30-Preview
    {  
      "search": "something",  
      "scoringProfile": "geo",  
      "scoringParameters": [ "currentLocation--122.123,44.77233", "lastLocation--121.499,44.2113" ]  
    }  

例: シャードではなく完全なインデックスに対してクエリを実行する

より短い待機時間で一貫したスコアリングを優先しながら、インデックス内のドキュメントを検索します。 このクエリは、インデックス全体のドキュメント頻度を計算し、同じ "セッション" 内のすべてのクエリに対して同じレプリカをターゲットにすることをベスト エフォートで行います。これにより、安定した再現可能なランク付けが生成されます。

GET /indexes/hotels/docs?search=hotel&sessionId=mySessionId&scoringStatistics=global&api-version=2021-04-30-Preview
POST /indexes/hotels/docs/search?api-version=2021-04-30-Preview
    {  
      "search": "hotel",  
      "sessionId": "mySessionId",
      "scoringStatistics" :"global"
    }  

例: 統計のスコア付け (featuresMode)

インデックス内のドキュメントを検索し、一致するドキュメントとクエリの間のスコアリングを記述する各結果の情報取得機能の一覧を返します。 クエリでは、インデックス全体のドキュメント頻度も計算され、より一貫性のあるスコアリングが生成されます。

GET /indexes/hotels/docs?search=hotel&featuresMode=enabled&scoringStatistics=global&api-version=2021-04-30-Preview
POST /indexes/hotels/docs/search?api-version=2021-04-30-Preview
    {  
      "search": "hotel",  
      "featuresMode": "enabled",
      "scoringStatistics" :"global"
    }  

を含む search.features 応答の例は、次のようになります。

    "@search.score": 0.91875637,
    "@search.features": {
        "Description": {
            "uniqueTokenMatches": 1,
            "similarityScore": 0.2917966,
            "termFrequency": 2
        },
        "HotelName": {
            "uniqueTokenMatches": 1,
            "similarityScore": 0.44458693,
            "termFrequency": 1
        }
      . . .

定義

このセクションでは、メイン テーブルで扱うのが複雑すぎるパラメーターについて詳しく説明します。

Link 説明
queryLanguage スペル チェックとセマンティック検索でサポートされている言語の一覧。

queryLanguage

queryLanguage パラメーターの有効な値は、次の表の "queryLanguage" 列に用意されており、大文字と小文字は区別されません。 パラメーター全体の既定値は "en-us" です。 各言語には、2 文字の言語コードごとに既定のバリアントがあります。 たとえば、"es" を指定した場合、既定では "es-us" が使用されます。 queryLanguage パラメーターは、"queryType=semantic" または "speller=lexicon" を含むクエリ要求に必要です。 要求全体に対して queryLanguage 値は 1 つだけあり、その値はセマンティック ランク付け、キャプション、回答、スペル チェックに使用されます (個々の機能にオーバーライドはありません)。

現時点では、言語のサポートは機能によって異なります。 機能の完全なセットでは、英語、スペイン語、フランス語、ドイツ語のみがサポートされていますが、スペル チェックでは実装されるバリエーションが少ないことに注意してください。

スペル チェックを使用した EN-GB など、特定の機能でサポートされていない言語コードを指定すると、サービスは HTTP 400 を返します。

各機能の使用方法の詳細については、「セマンティック ランク付けとキャプションを有効にする」、「セマンティック回答を返す」、および「クエリにスペル チェックを追加する」を参照してください。

"(プレビュー)" 指定は、すべての機能 (セマンティック ランク付け、キャプション、回答、スペル チェック) の検証テストが進行中または保留中であることを示します。 次の表のすべての言語バリアントを使用することをお勧めしますが、結果がコンテンツに対して有効であることを確認するために、プレビュー言語のテストを増やすることをお勧めします。 チェックマークを持ち、プレビューの指定がない言語は、同等のデータセットを使用して検証されており、関連性が測定可能です。

Language queryLanguage セマンティック ランカーとキャプション セマンティック回答 スペル チェック
英語 [en] en, en-US(既定値)、en-GB、、en-IN、、 en-CAen-AU ✔️ ✔️ ✔️ (en, en-US)
フランス語 [fr] frfr-FR (既定値) fr-CA ✔️ ✔️ ✔️ (fr, fr-FR)
ドイツ語 [de] de, de-DE (既定値) ✔️ ✔️ ✔️ (de, de-DE)
スペイン語 [es] es, es-ES (既定値)、es-MX ✔️ ✔️ ✔️ (es, es-ES)
イタリア語 [it] it, it-IT (既定値) ✔️ ✔️
日本語 [ja] ja, ja-JP (既定値) ✔️ ✔️ (プレビュー)
中国語 [zh] zh, zh-CN (既定値)、zh-TW ✔️ ✔️ (プレビュー)
ポルトガル語 [pt] pt, pt-BR (既定値)、pt-PT ✔️ ✔️ (プレビュー)
オランダ語 [nl] nl, nl-BE, nl-NL (既定値) ✔️ (プレビュー) ✔️ (プレビュー) ✔️ (nl, nl-NL)
アラビア語 [ar] ar, ar-SA (既定値)、ar-EG, ar-MA, ar-KW, ar-JO ✔️ (プレビュー) ✔️ (プレビュー)
アルメニア語 hy-AM (既定値) ✔️ (プレビュー) ✔️ (プレビュー)
ベンガル語 bn-IN (既定値) ✔️ (プレビュー) ✔️ (プレビュー)
バスク語 eu-ES (既定値) ✔️ (プレビュー) ✔️ (プレビュー)
ブルガリア語 [bg] bg, bg-BG (既定値) ✔️ (プレビュー) ✔️ (プレビュー)
カタロニア語 [ca] ca, ca-ES (既定値) ✔️ (プレビュー) ✔️ (プレビュー)
クロアチア語 [hr] hr, hr-HR (既定値)、hr-BA ✔️ (プレビュー) ✔️ (プレビュー)
チェコ語 [cs] cs, cs-CZ (既定値) ✔️ (プレビュー) ✔️ (プレビュー)
デンマーク語 [da] da, da-DK (既定値) ✔️ (プレビュー) ✔️ (プレビュー)
エストニア語 [et] et, et-EE (既定値) ✔️ (プレビュー) ✔️ (プレビュー)
フィンランド語 [fi] fi, fi-FI (既定値) ✔️ (プレビュー) ✔️ (プレビュー)
ガリシア語 gl-ES (既定値) ✔️ (プレビュー) ✔️ (プレビュー)
ギリシャ語 [el] el, el-GR (既定値) ✔️ (プレビュー) ✔️ (プレビュー)
グジャラート語 gu-IN (既定値) ✔️ (プレビュー) ✔️ (プレビュー)
ヘブライ語 he-IL (既定値) ✔️ (プレビュー) ✔️ (プレビュー)
ヒンディー語 [hi] hi, hi-IN (既定値) ✔️ (プレビュー) ✔️ (プレビュー)
ハンガリー語 [hu] hu, hu-HU (既定値) ✔️ (プレビュー) ✔️ (プレビュー)
アイスランド語 [is] is, is-IS (既定値) ✔️ (プレビュー) ✔️ (プレビュー)
インドネシア語 [id] id, id-ID (既定値) ✔️ (プレビュー) ✔️ (プレビュー)
アイルランド語 ga-IE (既定値) ✔️ (プレビュー) ✔️ (プレビュー)
カンナダ語 kn-IN (既定値) ✔️ (プレビュー) ✔️ (プレビュー)
韓国語 [ko] ko, ko-KR (既定値) ✔️ (プレビュー) ✔️ (プレビュー)
ラトビア語 [lv] lv, lv-LV (既定値) ✔️ (プレビュー) ✔️ (プレビュー)
リトアニア語 [lt] lt, lt-LT (既定値) ✔️ (プレビュー) ✔️ (プレビュー)
マラヤーラム語 ml-IN (既定値) ✔️ (プレビュー) ✔️ (プレビュー)
マレーシア語 [ms] ms, ms-MY (既定値)、ms-BN ✔️ (プレビュー) ✔️ (プレビュー)
マラーティー語 mr-IN (既定値) ✔️ (プレビュー) ✔️ (プレビュー)
ノルウェー語 [no] no、no-NO (既定値)、nb-NO ✔️ (プレビュー) ✔️ (プレビュー)
ペルシャ語 fa-AE (既定値) ✔️ (プレビュー) ✔️ (プレビュー)
ポーランド語 [pl] pl, pl-PL (既定値) ✔️ (プレビュー) ✔️ (プレビュー)
パンジャーブ語 pa-IN (既定値) ✔️ (プレビュー) ✔️ (プレビュー)
ルーマニア語 [ro] ro, ro-RO (既定値) ✔️ (プレビュー) ✔️ (プレビュー)
ロシア語 [ru] ru, ru-RU (既定値) ✔️ (プレビュー) ✔️ (プレビュー)
セルビア語 [sr] (キリル語またはラテン) sr, sr-BA (既定値)、sr-ME, sr-RS ✔️ (プレビュー) ✔️ (プレビュー)
スロバキア語 [sk] sk, sk-SK (既定値) ✔️ (プレビュー) ✔️ (プレビュー)
スロベニア語 [sl] sl, sl-SL (既定値) ✔️ (プレビュー) ✔️ (プレビュー)
タミル語 [ta] ta, ta-IN (既定値) ✔️ (プレビュー) ✔️ (プレビュー)
スウェーデン語 [sv] sv, sv-SE (既定値) ✔️ (プレビュー) ✔️ (プレビュー)
テルグ語 te-IN (既定値) ✔️ (プレビュー) ✔️ (プレビュー)
タイ語 [th] th, th-TH (既定値) ✔️ (プレビュー) ✔️ (プレビュー)
トルコ語 [tr] tr, tr-TR (既定値) ✔️ (プレビュー) ✔️ (プレビュー)
ウクライナ語 [uk] uk, uk-UA (既定値) ✔️ (プレビュー) ✔️ (プレビュー)
ウルドゥ語 ur-PK (既定値) ✔️ (プレビュー) ✔️ (プレビュー)
ベトナム語 [va] va, vi-VN (既定値) ✔️ (プレビュー) ✔️ (プレビュー)

こちらもご覧ください