Azure AI 検索で Azure Storage のインデクサーを使用した変更および削除の検出

注

Azure AI 検索は、Azure ポータル、REST API、およびAzure SDKから使用できます。また、Foundry IQ は、エンタープライズコンテンツを、Microsoft Foundry ポータルのエージェントの再利用可能なアクセス許可に対応したナレッジベースに変換するマネージドナレッジレイヤーです。

Important

これらの機能は、他のMicrosoft サービスおよびサードパーティのサービスへの接続をサポートします。これらのサービスの利用は各サービスの利用規約に従うものとし、データが Azure コンプライアンス境界の外部で処理または保存されたり、Azure コンプライアンス境界内に流入したりする場合があります。

データが組織のコンプライアンスと地理的境界の外部に流れるかどうか、および関連する影響、および適切なアクセス許可、境界、承認がプロビジョニングされるかどうかを管理するのは、お客様の責任です。

特定のユースケースのコンテキストで構築したアプリケーションを慎重に確認およびテストし、すべての適切な決定とカスタマイズを行う責任があります。これには、メタプロンプト、コンテンツフィルター、その他の安全システムなどの独自の責任ある AI 軽減策の実装や、アプリケーションが適切な品質、信頼性、セキュリティ、信頼性の標準を満たしていることを確認する機能が含まれます。詳細については、「Azure AI 検索透過性に関するメモを参照してください。

最初の検索インデックスが作成された後、以降のインデクサージョブでは、新規および変更されたドキュメントのみを取得することができます。 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 検索で Azure Blob Storage のネイティブ BLOB の論理的な削除機能を使用して、BLOB が論理的に削除された状態に移行したかどうかを判断します。この状態の BLOB が検出されると、この情報が検索インデクサーで使用され、対応するドキュメントがインデックスから削除されます。

ネイティブのソフト削除の要件

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

ネイティブのソフト削除を構成する

Blob Storage で、要件に従って論理的な削除を有効にする場合は、保持ポリシーをインデクサーの間隔スケジュールよりもはるかに高い値に設定します。インデクサーの実行に問題が発生した場合や、インデックスを作成するドキュメントの数が非常に多い場合、インデクサーがソフト削除された BLOB を最終的に処理する時間は十分にあります。 Azure AI 検索インデクサーは、ソフト削除状態にある BLOB を処理する場合にのみ、インデックスからドキュメントを削除します。

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

Azure Portal
レスト

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

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

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

PUT https://[service name].search.windows.net/datasources/blob-datasource?api-version=2026-04-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"
   }
}

リファレンス:データソースの作成または更新 (REST API)

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

ネイティブのソフト削除ポリシーを使用して削除されていないBLOBのインデックスを再作成する

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

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

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

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

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

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

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

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

PUT https://[service name].search.windows.net/datasources/file-datasource?api-version=2026-04-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 タイムスタンプを確認して、それが最後のインデクサーの実行よりも新しいことを確認します。既存のメタデータを再保存することで、強制的に現在の日付と時刻に更新することができます。
インデクサーを実行します。

制限事項

一対多のインデックス作成シナリオを使用する場合、ネイティブ BLOB の論理削除もカスタムメタデータによる論理削除も適用されません。ドキュメントエントリを削除するには、 REST API の削除操作を使用してインデックスに削除要求を送信する必要があります。

次のステップ

フィードバック

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

Last updated on 2026-07-03