Azure AI Search の Azure Storage のインデクサーを使用した変更検出と削除検出

最初の検索インデックスが作成された後、以降のインデクサージョブでは、新規および変更されたドキュメントのみを取得することができます。 Azure Storage から生成されたインデックス付きコンテンツに対しては、変更検出が自動的に行われます。これは、インデクサーが Azure Storage のオブジェクトとファイルに組み込まれたタイムスタンプを使用して最終更新を追跡しているためです。

変更の検出は指定されていますが、削除検出は指定されていません。インデクサーはデータソースのオブジェクトの削除を追跡しません。孤立した検索ドキュメントが含まれないようにするには "論理的な削除" 方法を実装できます。これにより、最初に検索ドキュメントを削除した後に Azure Storage での物理的な削除が行われます。

論理的な削除方法を実装するには、2 つの方法があります。

ネイティブ BLOB のソフト削除。Blob Storage の機能にのみ適用されます
カスタムメタデータを使用した論理的な削除

削除検出戦略は、最初のインデクサー実行から適用する必要があります。最初の実行の前に削除ポリシーを確立しなかった場合、ポリシーが実装される前に削除されたすべてのドキュメントは、ポリシーを後でインデクサーに追加してリセットしたとしても、インデックス内に残ることになります。これが発生した場合は、新しいインデクサーを使用して新しいインデックスを作成し、削除ポリシーが最初から適用されていることを確認することをお勧めします。

[前提条件]

Azure Storage インデクサー向けの Blob Storage、Table Storage、File Storage、またはData Lake Storage Gen2 を使用
一貫性のあるドキュメントキーとファイル構造を使用します。ドキュメントキーまたはディレクトリの名前やパスを変更すると (ADLS Gen2 に該当)、インデクサーが使用する内部追跡情報が中断されます。インデクサーはこの内部追跡情報を使ってインデックスが作成されたコンテンツと最後にインデックスが作成された日時を認識します。

注

ADLS Gen2 により、ディレクトリの名前を変更できます。ディレクトリの名前が変更されると、そのディレクトリ内の BLOB のタイムスタンプは更新されません。その結果、インデクサーはこれらの BLOB のインデックスを再作成しません。ディレクトリの名前が変更された後にディレクトリ内の BLOB のインデックスを再作成する必要がある場合は、ディレクトリ内のすべての BLOB の LastModified タイムスタンプを更新して、インデクサーが将来の実行中にインデックスを再作成できるようにする必要があります。 Azure Blob Storage 内の仮想ディレクトリは変更できないため、この問題はありません。

ネイティブ BLOB の論理的な削除

この削除検出方法では、Azure AI Search で Azure Blob Storage のネイティブ BLOB の論理的な削除機能を使用して、BLOB が論理的に削除された状態に移行したかどうかを判断します。この状態の BLOB が検出されると、この情報が検索インデクサーで使用され、対応するドキュメントがインデックスから削除されます。

ネイティブの論理的な削除の要件

BLOB は、ADLS Gen2 BLOB コンテナーを含む Azure Blob Storage コンテナー内にある必要があります。 Azure AI Search のネイティブ BLOB ソフト削除ポリシーは、Azure Files でサポートされていません。
BLOB の論理的な削除を有効にします。
インデックス内のドキュメントのドキュメントキーは、"metadata_storage_path" などの.BLOB プロパティと BLOB メタデータのどちらかにマップされている必要があります。
REST API または Azure portal のインデクサーデータソース構成を使用して、論理的な削除のサポートを構成できます。
ストレージアカウントで BLOB のバージョン管理を有効にしないようにする必要があります。そのようにしないと、ネイティブの論理的な削除が設計でサポートされなくなります。

ネイティブの論理的な削除を構成する

BLOB ストレージで、要件ごとに論理的な削除を有効にする場合、保持ポリシーをインデクサー間隔スケジュールよりも大幅に高い値に設定することをお勧めします。インデクサーの実行で問題が発生した場合、またはインデックスを作成するドキュメントの数が多い場合に、インデクサーが論理的に削除された BLOB を最終的に処理するための時間は十分にあります。 Azure AI Search インデクサーでは、論理的に削除された状態の BLOB を処理する場合にのみ、インデックスからドキュメントが削除されます。

Azure AI Search で、データソースに対してネイティブ BLOB の論理的な削除の検出ポリシーを設定します。これは、Azure portal から、または REST API を使用して行うことができます。次の手順では、Azure portal または REST API を使用して削除検出ポリシーを設定する方法について説明します。

Azure Portal
レスト

Azure portal にサインインします。
Azure AI Search サービスの概要ページで、データソース定義を指定するためのビジュアルエディターである [新しいデータソース] に移動します。

次のスクリーンショットは、Azure portal でこの機能が見つかる場所を示したものです。
[新しいデータソース] フォームで、必須フィールドに入力し、[削除の追跡] チェックボックスをオンにして、[ネイティブ BLOB の論理的な削除] を選択します。次に、[保存] をクリックして、データソースの作成で機能を有効にします。

データソース定義で論理的な削除検出ポリシーを設定します。データソースを作成または更新するときに、API バージョンを指定します。

PUT https://[service name].search.windows.net/datasources/blob-datasource?api-version=2025-09-01
Content-Type: application/json
api-key: [admin key]
{
   "name" : "blob-datasource",
   "type" : "azureblob",
   "credentials" : { "connectionString" : "<your storage connection string>" },
   "container" : { "name" : "my-container", "query" : null },
   "dataDeletionDetectionPolicy" : {
   "@odata.type" :"#Microsoft.Azure.Search.NativeBlobSoftDeleteDeletionDetectionPolicy"
   }
}

インデクサーを実行するか、またはスケジュールに基づいて実行するようにインデクサーを設定します。インデクサーが実行され、論理的な削除状態の BLOB が処理されると、対応する検索ドキュメントがインデックスから削除されます。

ネイティブの論理的な削除ポリシーを使用して削除が取り消された BLOB のインデックスを再作成する

論理的に削除された BLOB を BLOB ストレージに復元する場合、インデクサーでインデックスが常に再作成されるとは限りません。これは、インデクサーで BLOB の LastModified タイムスタンプを使用してインデックス作成が必要かどうかが判断されるためです。論理的に削除された BLOB の削除が取り消されたとき、その LastModified タイムスタンプは更新されないため、インデクサーによって最新の LastModified タイムスタンプを持つ BLOB が既に処理されている場合、削除が取り消された BLOB のインデックスは再作成されません。

削除が取り消された BLOB のインデックス再作成が確実に行われるようにするには、BLOB の LastModified タイムスタンプを更新する必要があります。これを行う 1 つの方法は、その BLOB のメタデータを保存することです。メタデータを変更する必要はありませんが、メタデータを再保存すると BLOB の LastModified タイムスタンプが更新され、インデクサーでそれを選択する必要があることが認識されます。

カスタムメタデータを使用した論理的な削除方法

この方法ではカスタムメタデータを使用して、検索ドキュメントをインデックスから削除する必要があるかどうかを示します。ここでは、インデックスから検索ドキュメントを削除した後、Azure Storage でファイルを削除するという 2 つの個別のアクションが必要です。

この機能は一般提供されています。

Azure Storage と Azure AI Search の両方で実行する手順がありますが、その他の機能の依存関係はありません。

Azure Storage では、カスタムメタデータのキーと値のペアをファイルに追加して、ファイルに削除のフラグが付けられていることを示します。たとえば、プロパティに "IsDeleted" という名前を指定し、それを false に設定できます。ファイルを削除する場合は、true に変更します。

Azure AI Search では、データソースの定義を編集して "dataDeletionDetectionPolicy" プロパティを含めます。たとえば、次のポリシーでは、ファイルのメタデータプロパティ IsDeleted の値が true のときに、そのファイルが削除されるものと見なされます。

PUT https://[service name].search.windows.net/datasources/file-datasource?api-version=2025-09-01
{
    "name" : "file-datasource",
    "type" : "azurefile",
    "credentials" : { "connectionString" : "<your storage connection string>" },
    "container" : { "name" : "my-share", "query" : null },
    "dataDeletionDetectionPolicy" : {
        "@odata.type" :"#Microsoft.Azure.Search.SoftDeleteColumnDeletionDetectionPolicy",
        "softDeleteColumnName" : "IsDeleted",
        "softDeleteMarkerValue" : "true"
    }
}

インデクサーを実行します。インデクサーがファイルを処理し、検索インデックスからドキュメントを削除したら、Azure Storage で物理ファイルを削除できます。

削除が取り消された BLOB とファイルのインデックスを再作成する

元の物理的なソースファイルが Azure Storage にまだ存在する場合は、論理的な削除を取り消すことができます。

Azure Storage で BLOB またはファイルの "softDeleteMarkerValue" : "false" を変更します。
BLOB またはファイルの LastModified タイムスタンプを確認して、最後のインデクサーの実行よりも新しいものにします。既存のメタデータを再保存することで、強制的に現在の日付と時刻に更新することができます。
インデクサーを実行します。

次のステップ

フィードバック

このページはお役に立ちましたか?

Last updated on 2025-10-09