Azure Search インデクサーを使用して Cosmos DB のインデックスを作成する方法How to index Cosmos DB using an Azure Search indexer

この記事では、コンテンツを抽出して Azure Search で検索できるようにするために Azure Comos DB インデクサーを構成する方法を説明します。This article shows you how to configure an Azure Cosmos DB indexer to extract content and make it searchable in Azure Search. このワークフローでは、Azure Search インデックスを作成して、Azure Cosmos DB から抽出された既存のテキストとともに読み込みます。This workflow creates an Azure Search index and loads it with existing text extracted from Azure Cosmos DB.

用語が混乱を招く可能性があるため、Azure Cosmos DB のインデックス作成Azure Search のインデックス作成はそれぞれのサービスに固有の異なる操作であることに注意してください。Because terminology can be confusing, it's worth noting that Azure Cosmos DB indexing and Azure Search indexing are distinct operations, unique to each service. Azure Search のインデックス作成を開始するには、Azure Cosmos DB データベースが既に存在していて、データが格納されている必要があります。Before you start Azure Search indexing, your Azure Cosmos DB database must already exist and contain data.

ポータル、REST API、または .NET SDK を使用して、Cosmos コンテンツのインデックスを作成できます。You can use the portal, REST APIs, or .NET SDK to index Cosmos content. Azure Search の Cosmos DB インデクサーでは、以下のプロトコルを使用してアクセスする Azure Cosmos 項目をクロールできます。The Cosmos DB indexer in Azure Search can crawl Azure Cosmos items accessed through these protocols:

  • MongoDB API (この API の Azure Search のサポートはパブリック プレビュー段階です)MongoDB API (Azure Search support for this API is in public preview)


ユーザーの声に、その他の API サポートについての既存の項目があります。User Voice has existing items for additional API support. Azure Search でサポートされていることを確認したい Cosmos API(Table APIGraph APIApache Cassandra API) を投票していただくことができます。You can cast a vote for the Cosmos APIs you would like to see supported in Azure Search: Table API, Graph API, Apache Cassandra API.

ポータルの使用Use the portal

Azure Cosmos 項目のインデックスを作成する最も簡単な方法は、Azure portal のウィザードを使用することです。The easiest method for indexing Azure Cosmos items is to use a wizard in the Azure portal. コンテナー内のデータをサンプリングしてメタデータを解析することにより、Azure Search のデータのインポートウィザードでは、既定のインデックスを作成し、ソース フィールドをターゲット インデックス フィールドにマップし、1 回の操作でインデックスを読み込むことができます。By sampling data and reading metadata on the container, the Import data wizard in Azure Search can create a default index, map source fields to target index fields, and load the index in a single operation. ソース データのサイズと複雑さによっては、数分で運用可能なフルテキスト検索インデックスを作成できます。Depending on the size and complexity of source data, you could have an operational full text search index in minutes.

Azure Search と Azure Cosmos DB の両方で、可能であれば同じリージョンで、同じ Azure サブスクリプションを使用することをお勧めします。We recommend using the same Azure subscription for both Azure Search and Azure Cosmos DB, preferably in the same region.

1 - ソース データを準備する1 - Prepare source data

Cosmos アカウント、SQL API または MongoDB API にマップされた Azure Cosmos データベース、および JSON ドキュメントのコンテナーが必要です。You should have a Cosmos account, an Azure Cosmos database mapped to the SQL API or MongoDB API, and a container of JSON documents.

Cosmos DB データベースにデータが含まれることを確認してください。Make sure your Cosmos DB database contains data. データのインポート ウィザードでは、メタデータが読み取られ、インデックス スキーマを推論するためにデータのサンプリングが実行されますが、Cosmos DB からもデータが読み込まれます。The Import data wizard reads metadata and performs data sampling to infer an index schema, but it also loads data from Cosmos DB. このデータが見つからない場合、ウィザードは "データ ソースからインデックス スキーマを削除するときにエラーが発生しました:データソース 'emptycollection' がデータを返さなかったため、プロトタイプ インデックスを構築できませんでした" というエラーで停止します。If the data is missing, the wizard stops with this error "Error detecting index schema from data source: Could not build a prototype index because datasource 'emptycollection' returned no data".

2 - データのインポート ウィザードを開始する2 - Start Import data wizard

Azure Search サービス ページのコマンド バーから、またはストレージ アカウントの左側のナビゲーション ウィンドウの [設定] セクションで [Azure Search の追加] をクリックして、ウィザードを開始することができます。You can start the wizard from the command bar in the Azure Search service page, or by clicking Add Azure Search in the Settings section of your storage account's left navigation pane.

ポータルの [データのインポート] コマンドImport data command in portal

3 - データ ソースを設定する3 - Set the data source


現時点では、Azure portal または .NET SDK を使用して、MongoDB データ ソースを作成または編集することはできません。Currently, you cannot create or edit MongoDB data sources using Azure portal or the .NET SDK. ただし、ポータルでは MongoDB のインデクサーの実行履歴を監視できますHowever, you can monitor execution history of MongoDB indexers in the portal.

データソースのページでは、ソースが次のように指定された Cosmos DB になっている必要があります。In the data source page, the source must be Cosmos DB, with the following specifications:

  • [名前] は データ ソースの名前です。Name is the name of the data source object. 作成されたら、その他のワークロード用に選択できます。Once created, you can choose it for other workloads.

  • [Cosmos DB アカウント] は、AccountEndpointAccountKey を含む、Cosmos DB からのプライマリまたはセカンダリの接続文字列である必要があります。Cosmos DB account should be the primary or secondary connection string from Cosmos DB, with an AccountEndpoint and an AccountKey. アカウントは、データを SQL API または Mongo DB API のどちらとしてキャストするかを決定しますThe account determines whether data is cast as SQL API or Mongo DB API

  • [データベース] は、アカウントからの既存のデータベースです。Database is an existing database from the account.

  • [コレクション] はドキュメントのコンテナーです。Collection is a container of documents. インポートが成功するためには、ドキュメントが存在している必要があります。Documents must exist in order for import to succeed.

  • [クエリ] は、すべてのドキュメントが必要な場合は空にすることができます。それ以外の場合は、ドキュメントのサブセットを選択するクエリを入力できます。Query can be blank if you want all documents, otherwise you can input a query that selects a document subset.

    Cosmos DB データ ソースの定義Cosmos DB data source definition

4 - ウィザードの [認知検索を追加します] ページをスキップする4 - Skip the "Add cognitive search" page in the wizard

ドキュメントをインポートするときは、コグニティブ スキルを追加する必要はありません。Adding cognitive skills is not necessary for document import. インデックス作成パイプラインに Cognitive Services APIs と変換を含める特定のニーズがない限り、このステップをスキップする必要があります。Unless you have a specific need to include Cognitive Services APIs and transformations to your indexing pipeline, you should skip this step.

このステップをスキップするには、先に次のページに移動します。To skip the step, first go to the next page.

コグニティブ検索用の次のページ ボタン

そのページから、インデックスのカスタマイズに進むことができます。From that page you can skip ahead to index customization.

コグニティブ スキル手順のスキップ

5 - インデックスの属性を設定する5 - Set index attributes

[インデックス] ページには、フィールドとデータ型およびインデックスの属性を設定するための一連のチェック ボックスが一覧表示されます。In the Index page, you should see a list of fields with a data type and a series of checkboxes for setting index attributes. このウィザードで、メタデータに基づいてソース データをサンプリングすることで、フィールドの一覧を生成できます。The wizard can generate a fields list based on metadata and by sampling the source data.

属性列の上部にあるチェック ボックスをクリックすることで、属性を一括選択できます。You can bulk-select attributes by clicking the checkbox at the top of an attribute column. クライアント アプリに返してフル検索処理の対象にする必要があるすべてのフィールドで、[取得可能][検索可能] を選択します。Choose Retrievable and Searchable for every field that should be returned to a client app and subject to full text search processing. 整数はフルテキスト検索もあいまい検索もできないことに注意してください (数値は逐語的に評価され、多くの場合フィルターで役立ちます)。You'll notice that integers are not full text or fuzzy searchable (numbers are evaluated verbatim and are often useful in filters).

詳細については、インデックス属性言語アナライザーの説明を参照してください。Review the description of index attributes and language analyzers for more information.

時間をかけて選択内容を確認します。Take a moment to review your selections. ウィザードを実行すると、物理データ構造が作成されて、すべてのオブジェクトを削除して再作成しない限り、これらのフィールドを編集することはできません。Once you run the wizard, physical data structures are created and you won't be able to edit these fields without dropping and recreating all objects.

Cosmos DB インデックスの定義Cosmos DB index definition

6 - インデクサーを作成する6 - Create indexer

完全に指定すると、ウィザードによって検索サービスに 3 つの異なるオブジェクトが作成されます。Fully specified, the wizard creates three distinct objects in your search service. データ ソース オブジェクトとインデックス オブジェクトは、Azure Search サービスに名前付きリソースとして保存されます。A data source object and index object are saved as named resources in your Azure Search service. 最後のステップでは、インデクサー オブジェクトが作成されます。The last step creates an indexer object. インデクサーに名前を付けると、インデクサーはスタンドアロン リソースとして存在することができ、同じウィザードのシーケンスで作成されるインデックス オブジェクトやデータ ソース オブジェクトとは独立して、スケジュールを設定したり管理したりできます。Naming the indexer allows it to exist as a standalone resource, which you can schedule and manage independently of the index and data source object, created in the same wizard sequence.

インデクサーに慣れていないユーザーのために説明すると、"インデクサー" とは Azure Search のリソースであり、外部データ ソースで検索可能なコンテンツのクロールを行います。If you are not familiar with indexers, an indexer is a resource in Azure Search that crawls an external data source for searchable content. データのインポート ウィザードで出力されるインデクサーでは、Cosmos DB データ ソースがクロールされ、検索可能なコンテンツが抽出されて、Azure Search のインデックスにインポートされます。The output of the Import data wizard is an indexer that crawls your Cosmos DB data source, extracts searchable content, and imports it into an index on Azure Search.

次のスクリーンショットは、既定のインデクサー構成を示しています。The following screenshot shows the default indexer configuration. インデクサーを 1 回だけ実行する場合は、[1 度] に切り替えることができます。You can switch to Once if you want to run the indexer one time. [送信] をクリックしてウィザードを実行し、すべてのオブジェクトを作成します。Click Submit to run the wizard and create all objects. インデックスの作成はすぐに開始されます。Indexing commences immediately.

Cosmos DB インデクサーの定義Cosmos DB indexer definition

ポータルのページでデータのインポートを監視することができます。You can monitor data import in the portal pages. 進行状況の通知では、インデックス作成の状態と、アップロードされたドキュメントの数が示されます。Progress notifications indicate indexing status and how many documents are uploaded.

インデックスの作成が完了したら、Search エクスプローラーを使用してインデックスのクエリを実行できます。When indexing is complete, you can use Search explorer to query your index.


期待どおりのデータが表示されない場合は、その他のフィールドにその他の属性を設定する必要があります。If you don't see the data you expect, you might need to set more attributes on more fields. 今作成したインデックスとインデクサーを削除し、もう一度ウィザードの手順に従って、手順 5 でインデックス属性の選択内容を変更してください。Delete the index and indexer you just created, and step through the wizard again, modifying your selections for index attributes in step 5.


REST API を使用して、Azure Search のすべてのインデクサーに共通する 3 部構成のワークフロー (データ ソースを作成し、インデックスを作成して、インデクサーを作成する) で、Azure Comos DB データのインデックスを作成できます。You can use the REST API to index Azure Cosmos DB data, following a three-part workflow common to all indexers in Azure Search: create a data source, create an index, create an indexer. Cosmos ストレージからのデータ抽出は、インデクサーの作成要求を送信するときに行われます。Data extraction from Cosmos storage occurs when you submit the Create Indexer request. この要求が完了すると、クエリ可能なインデックスが作成されます。After this request is finished, you will have a queryable index.

MongoDB を評価する場合は、REST API を使用してデータ ソースを作成する必要があります。If you are evaluating MongoDB, you must use the REST API to create the data source.

ご自分の Cosmos DB アカウントで、コレクションですべてのドキュメントのインデックスを自動的に作成するかどうかを選択できます。In your Cosmos DB account you can choose whether you want the collection to automatically index all documents. 既定では、すべてのドキュメントのインデックスが自動的に作成されますが、自動インデックス作成を無効にすることができます。By default, all documents are automatically indexed, but you can turn off automatic indexing. 自動インデックス作成が無効になっている場合、自己リンクまたはドキュメント ID を使用したクエリでのみドキュメントにアクセスできます。When indexing is turned off, documents can be accessed only through their self-links or by queries by using the document ID. Azure Search では、Azure Search によってインデックスが作成されるコレクションで、Cosmos DB の自動インデックス作成が有効化される必要があります。Azure Search requires Cosmos DB automatic indexing to be turned on in the collection that will be indexed by Azure Search.


Azure Cosmos DB とは、次世代の DocumentDB です。Azure Cosmos DB is the next generation of DocumentDB. 製品名が変更されていますが、下位互換性のために Azure Search インデクサーの documentdb 公文は Azure Search API とポータル ページの両方に依然として存在します。Although the product name is changed, the documentdb syntax in Azure Search indexers still exists for backwards compatibility in both the Azure Search APIs and portal pages. インデクサーを構成するときには、この記事の説明に従って必ず documentdb 構文を指定します。When configuring indexers, be sure to specify the documentdb syntax as instructed in this article.

1 - 要求に対する入力をアセンブルする1 - Assemble inputs for the request

要求ごとに、Azure Search サービス名と管理者キーを (POST ヘッダーに) 指定し、BLOB ストレージのストレージ アカウント名とキーを指定する必要があります。For each request, you must provide the service name and admin key for Azure Search (in the POST header), and the storage account name and key for blob storage. Postman を使用して、Azure Search に HTTP 要求を送信できます。You can use Postman to send HTTP requests to Azure Search.

次の 4 つの値をメモ帳にコピーして、要求に貼り付けることができるようにします。Copy the following four values into Notepad so that you can paste them into a request:

  • Azure Search サービス名Azure Search service name
  • Azure Search 管理者キーAzure Search admin key
  • Cosmos DB の接続文字列Cosmos DB connection string

これらの値はポータルで調べることができます。You can find these values in the portal:

  1. Azure Search のポータル ページで、[概要] ページから Search サービスの URL をコピーします。In the portal pages for Azure Search, copy the search service URL from the Overview page.

  2. 左側のナビゲーション ウィンドウで [キー] をクリックし、プライマリまたはセカンダリのいずれかのキー (どちらも働きは同じです) をコピーします。In the left navigation pane, click Keys and then copy either the primary or secondary key (they are equivalent).

  3. Cosmos ストレージ アカウントのポータル ページに切り替えます。Switch to the portal pages for your Cosmos storage account. 左側のナビゲーション ウィンドウで、[設定][キー] をクリックします。In the left navigation pane, under Settings, click Keys. このページには、1 つの URI、2 組の接続文字列、および 2 組のキーが表示されます。This page provides a URI, two sets of connection strings, and two sets of keys. 接続文字列のいずれかをメモ帳にコピーします。Copy one of the connection strings to Notepad.

2 - データ ソースを作成する2 - Create a data source

データ ソースは、インデックスを作成するデータ、資格情報、およびデータの変更を識別するためのポリシー (コレクション内の変更または削除されたドキュメントなど) を指定します。A data source specifies the data to index, credentials, and policies for identifying changes in the data (such as modified or deleted documents inside your collection). データ ソースは、複数のインデクサーから使用できるように、独立したリソースとして定義します。The data source is defined as an independent resource so that it can be used by multiple indexers.

データ ソースを作成するには、POST 要求を作成します。To create a data source, formulate a POST request:

POST https://[service name]
Content-Type: application/json
api-key: [Search service admin key]

    "name": "mydocdbdatasource",
    "type": "documentdb",
    "credentials": {
        "connectionString": "AccountEndpoint=;AccountKey=myCosmosDbAuthKey;Database=myCosmosDbDatabaseId"
    "container": { "name": "myCollection", "query": null },
    "dataChangeDetectionPolicy": {
        "@odata.type": "#Microsoft.Azure.Search.HighWaterMarkChangeDetectionPolicy",
        "highWaterMarkColumnName": "_ts"

要求の本文には、次のフィールドを含むデータ ソースの定義が含まれている必要があります。The body of the request contains the data source definition, which should include the following fields:

フィールドField 説明Description
namename 必須。Required. データ ソース オブジェクトを表す名前を選択します。Choose any name to represent your data source object.
typetype 必須。Required. documentdbである必要があります。Must be documentdb.
credentialscredentials 必須。Required. Cosmos DB の接続文字列でなければなりません。Must be a Cosmos DB connection string.
SQL コレクションでは、接続文字列の形式は AccountEndpoint=<Cosmos DB endpoint url>;AccountKey=<Cosmos DB auth key>;Database=<Cosmos DB database id> ですFor SQL collections, connection strings are in this format: AccountEndpoint=<Cosmos DB endpoint url>;AccountKey=<Cosmos DB auth key>;Database=<Cosmos DB database id>
MongoDB コレクションの場合は、ApiKind=MongoDb を接続文字列に追加します。For MongoDB collections, add ApiKind=MongoDb to the connection string:
AccountEndpoint=<Cosmos DB endpoint url>;AccountKey=<Cosmos DB auth key>;Database=<Cosmos DB database id>;ApiKind=MongoDb
エンドポイント URL では、ポート番号の使用を避けてください。Avoid port numbers in the endpoint url. ポート番号を含めると、Azure Search では、Azure Cosmos DB データベースのインデックスを作成できなくなります。If you include the port number, Azure Search will be unable to index your Azure Cosmos DB database.
containercontainer 次の要素が含まれます。Contains the following elements:
name:必須。name: Required. インデックスを作成するデータベース コレクションの ID を指定します。Specify the ID of the database collection to be indexed.
query: 省略可能。query: Optional. 任意の JSON ドキュメントを、Azure Search がインデックスを作成できるフラット スキーマにフラット化するクエリを指定できます。You can specify a query to flatten an arbitrary JSON document into a flat schema that Azure Search can index.
MongoDB コレクションの場合、クエリはサポートされません。For MongoDB collections, queries are not supported.
dataChangeDetectionPolicydataChangeDetectionPolicy 推奨。Recommended. 変更されたドキュメントのインデックス作成」セクションを参照してください。See Indexing Changed Documents section.
dataDeletionDetectionPolicydataDeletionDetectionPolicy 省略可能。Optional. 削除されたドキュメントのインデックス作成」セクションを参照してください。See Indexing Deleted Documents section.

インデックス作成するデータの処理にクエリを活用するUsing queries to shape indexed data

SQL クエリを指定すると、ネストされたプロパティや配列のフラット化、JSON プロパティのプロジェクション、インデックスを作成するデータのフィルター処理を行うことができます。You can specify a SQL query to flatten nested properties or arrays, project JSON properties, and filter the data to be indexed.


MongoDB コレクションではカスタム クエリはサポートされていません。container.query パラメーターは null に設定するか、省略する必要があります。Custom queries are not supported for MongoDB collections: container.query parameter must be set to null or omitted. カスタム クエリを使用する必要がある場合は、ユーザーの声 Web サイトでお知らせください。If you need to use a custom query, please let us know on User Voice.

ドキュメントのサンプル:Example document:

    "userId": 10001,
    "contact": {
        "firstName": "andy",
        "lastName": "hoh"
    "company": "microsoft",
    "tags": ["azure", "documentdb", "search"]

フィルター処理クエリ:Filter query:

SELECT * FROM c WHERE = "microsoft" and c._ts >= @HighWaterMark ORDER BY c._ts

平坦化クエリ:Flattening query:

SELECT, c.userId,,,, c._ts FROM c WHERE c._ts >= @HighWaterMark ORDER BY c._ts

プロジェクション クエリ:Projection query:

SELECT VALUE { "id", "Name", "Company", "_ts":c._ts } FROM c WHERE c._ts >= @HighWaterMark ORDER BY c._ts

配列を平坦化するクエリ:Array flattening query:

SELECT, c.userId, tag, c._ts FROM c JOIN tag IN c.tags WHERE c._ts >= @HighWaterMark ORDER BY c._ts

3 - ターゲット検索インデックスを作成する3 - Create a target search index

まだない場合は、ターゲットの Azure Search インデックスを作成しますCreate a target Azure Search index if you don’t have one already. 次の例では、ID と説明のフィールドを持つインデックスを作成します。The following example creates an index with an ID and description field:

POST https://[service name]
Content-Type: application/json
api-key: [Search service admin key]

   "name": "mysearchindex",
   "fields": [{
     "name": "id",
     "type": "Edm.String",
     "key": true,
     "searchable": false
   }, {
     "name": "description",
     "type": "Edm.String",
     "filterable": false,
     "sortable": false,
     "facetable": false,
     "suggestions": true

ターゲット インデックスのスキーマがソース JSON ドキュメントのスキーマまたはカスタムのクエリ プロジェクションの出力と互換性があることを確認します。Ensure that the schema of your target index is compatible with the schema of the source JSON documents or the output of your custom query projection.


パーティション分割されたコレクションの場合、既定のドキュメント キーは Azure Cosmos DB の _rid プロパティですが、フィールド名の先頭にはアンダースコア文字を使用できないため、この名前は Azure Search によって rid に自動的に変更されます。For partitioned collections, the default document key is Azure Cosmos DB's _rid property, which Azure Search automatically renames to rid because field names cannot start with an undescore character. また、Azure Cosmos DB の _rid 値には、Azure Search キーでは無効な文字が含まれています。Also, Azure Cosmos DB _rid values contain characters that are invalid in Azure Search keys. そのため、_rid 値は Base64 でエンコードされます。For this reason, the _rid values are Base64 encoded.

MongoDB コレクションの場合、_id プロパティ名は、Azure Search によって doc_id に自動的に変更されます。For MongoDB collections, Azure Search automatically renames the _id property to doc_id.

JSON データ型と Azure Search データ型間のマッピングMapping between JSON Data Types and Azure Search Data Types

JSON データ型JSON data type 互換性のあるターゲット インデックス フィールドの型Compatible target index field types
BoolBool Edm.Boolean、Edm.StringEdm.Boolean, Edm.String
整数などの数値Numbers that look like integers Edm.Int32、Edm.Int64、Edm.StringEdm.Int32, Edm.Int64, Edm.String
浮動小数点などの数値Numbers that look like floating-points Edm.Double、Edm.StringEdm.Double, Edm.String
StringString Edm.StringEdm.String
プリミティブ型の配列。例: ["a"、"b"、"c"]Arrays of primitive types, for example ["a", "b", "c"] Collection(Edm.String)Collection(Edm.String)
日付などの文字列Strings that look like dates Edm.DateTimeOffset、Edm.StringEdm.DateTimeOffset, Edm.String
GeoJSON オブジェクト。例: { "type": "Point", "coordinates": [long, lat] }GeoJSON objects, for example { "type": "Point", "coordinates": [long, lat] } Edm.GeographyPointEdm.GeographyPoint
その他の JSON オブジェクトOther JSON objects 該当なしN/A

4 - インデクサーを構成して実行する4 - Configure and run the indexer

インデックスとデータ ソースを作成したら、インデクサーを作成できます。Once the index and data source have been created, you're ready to create the indexer:

POST https://[service name]
Content-Type: application/json
api-key: [admin key]

  "name" : "mydocdbindexer",
  "dataSourceName" : "mydocdbdatasource",
  "targetIndexName" : "mysearchindex",
  "schedule" : { "interval" : "PT2H" }

このインデクサーは 2 時間ごとに実行されます (スケジュールの間隔が "PT2H" に設定されています)。This indexer runs every two hours (schedule interval is set to "PT2H"). インデクサーを 30 分ごとに実行するには、間隔を "PT30M" に設定します。To run an indexer every 30 minutes, set the interval to "PT30M". サポートされている最短の間隔は 5 分です。The shortest supported interval is 5 minutes. スケジュールは省略可能です。省略した場合、インデクサーは作成時に一度だけ実行されます。The schedule is optional - if omitted, an indexer runs only once when it's created. ただし、いつでもオンデマンドでインデクサーを実行できます。However, you can run an indexer on-demand at any time.

インデクサー作成 API の詳細については、「 インデクサーの作成」をご覧ください。For more details on the Create Indexer API, check out Create Indexer.

.NET の使用Use .NET

.NET SDK は REST API と完全に同等です。The .NET SDK has fully parity with the REST API. 前の REST API セクションを確認し、概念、ワークフロー、要件を理解することをお勧めします。We recommend that you review the previous REST API section to learn concepts, workflow, and requirements. その後は、次の .NET API リファレンス ドキュメントを参照して、マネージド コードで JSON インデクサーを実装できます。You can then refer to following .NET API reference documentation to implement a JSON indexer in managed code.

変更されたドキュメントのインデックス作成Indexing changed documents

データ変更の検出ポリシーの目的は、変更されたデータ項目を効率的に識別することです。The purpose of a data change detection policy is to efficiently identify changed data items. 現在、唯一サポートされているポリシーは、次に示すように、Azure Cosmos DB によって指定される _ts (タイムスタンプ) プロパティを使用した High Water Mark ポリシーです。Currently, the only supported policy is the High Water Mark policy using the _ts (timestamp) property provided by Azure Cosmos DB, which is specified as follows:

    "@odata.type" : "#Microsoft.Azure.Search.HighWaterMarkChangeDetectionPolicy",
    "highWaterMarkColumnName" : "_ts"

インデクサーの優れたパフォーマンスを確保するのには、このポリシーを使用することが推奨されます。Using this policy is highly recommended to ensure good indexer performance.

カスタム クエリを使用している場合、_ts プロパティはクエリによって投影されていることを確認します。If you are using a custom query, make sure that the _ts property is projected by the query.

増分の進行状況とカスタム クエリIncremental progress and custom queries

インデックスの作成中に増分の進行状況を利用すると、一時的な障害や実行の制限時間によってインデクサーの実行が中断された場合、次の実行時に、最初からコレクション全体のインデックスを再作成するのではなく、中断したところからインデックスを作成することができます。Incremental progress during indexing ensures that if indexer execution is interrupted by transient failures or execution time limit, the indexer can pick up where it left off next time it runs, instead of having to reindex the entire collection from scratch. 大規模なコレクションのインデックスを作成する場合、この機能は特に重要です。This is especially important when indexing large collections.

カスタム クエリを使用するときに増分の進行状況を有効にするには、クエリを使用して _ts 列で結果を並べ替えておきます。To enable incremental progress when using a custom query, ensure that your query orders the results by the _ts column. こうすることで Azure Search が使用する定期的なチェックポイントが作成され、エラーが発生した場合に増分の進行状況を利用できます。This enables periodic check-pointing that Azure Search uses to provide incremental progress in the presence of failures.

ただし状況によっては、クエリに ORDER BY [collection alias]._ts 句が含まれる場合でも、クエリ結果が _ts で並べ替えられることを Azure Search で推論されない可能性があります。In some cases, even if your query contains an ORDER BY [collection alias]._ts clause, Azure Search may not infer that the query is ordered by the _ts. assumeOrderByHighWaterMarkColumn 構成プロパティを使用して結果が並べ替えられるように Azure Search に指示することもできます。You can tell Azure Search that results are ordered by using the assumeOrderByHighWaterMarkColumn configuration property. このヒントを指定するには、次のようにインデクサーを作成または更新します。To specify this hint, create or update your indexer as follows:

 ... other indexer definition properties
 "parameters" : {
        "configuration" : { "assumeOrderByHighWaterMarkColumn" : true } }

削除されたドキュメントのインデックス作成Indexing deleted documents

コレクションから行が削除されると、通常、検索インデックスからも同様に行を削除する必要があります。When rows are deleted from the collection, you normally want to delete those rows from the search index as well. データ削除の検出ポリシーの目的は、削除されたデータ項目を効率的に識別することです。The purpose of a data deletion detection policy is to efficiently identify deleted data items. 現在、唯一サポートされているポリシーは、Soft Delete ポリシー (削除されると何らかのフラグでマークされる) のみです。このポリシーは、次のように指定します。Currently, the only supported policy is the Soft Delete policy (deletion is marked with a flag of some sort), which is specified as follows:

    "@odata.type" : "#Microsoft.Azure.Search.SoftDeleteColumnDeletionDetectionPolicy",
    "softDeleteColumnName" : "the property that specifies whether a document was deleted",
    "softDeleteMarkerValue" : "the value that identifies a document as deleted"

カスタム クエリを使用している場合、softDeleteColumnName から参照されているプロパティはクエリによって投影されていることを確認します。If you are using a custom query, make sure that the property referenced by softDeleteColumnName is projected by the query.

次の例では、ソフト削除ポリシーとともにデータ ソースを作成します。The following example creates a data source with a soft-deletion policy:

POST https://[service name]
Content-Type: application/json
api-key: [Search service admin key]

    "name": "mydocdbdatasource",
    "type": "documentdb",
    "credentials": {
        "connectionString": "AccountEndpoint=;AccountKey=myDocDbAuthKey;Database=myDocDbDatabaseId"
    "container": { "name": "myDocDbCollectionId" },
    "dataChangeDetectionPolicy": {
        "@odata.type": "#Microsoft.Azure.Search.HighWaterMarkChangeDetectionPolicy",
        "highWaterMarkColumnName": "_ts"
    "dataDeletionDetectionPolicy": {
        "@odata.type": "#Microsoft.Azure.Search.SoftDeleteColumnDeletionDetectionPolicy",
        "softDeleteColumnName": "isDeleted",
        "softDeleteMarkerValue": "true"

次の動画をご覧くださいWatch this video

若干古いこの 7 分のビデオでは、Azure Cosmos DB のプログラム マネージャーである Andrew Liu が、Azure Search インデックスを Azure Cosmos DB コンテナーに追加する方法を紹介しています。In this slightly older 7-minute video, Azure Cosmos DB Program Manager Andrew Liu demonstrates how to add an Azure Search index to an Azure Cosmos DB container. ビデオに表示されるポータル ページは古くなっていますが、情報はまだ古くなっていません。The portal pages shown in the video are outdated, but the information is still relevant.

次のステップNext steps

お疲れさまでした。Congratulations! インデクサーを使用して、Azure Cosmos DB を Azure Search と統合する方法についての説明は以上で終了です。You have learned how to integrate Azure Cosmos DB with Azure Search using an indexer.