Azure AI Searchを使用してファイルの内容とメタデータをインデックスする

この記事では、ファイルに関連付けられているメタデータに加えて、ドキュメントをドキュメント コンテンツに基づいて検索できるように検索サービスを作成する方法について説明します。

このサービスは、Azure AI Searchで複数のインデクサーを使用して実装できます。

この記事では、ワークロードの例を使用して、Azure Blob Storage 内のファイルに基づいた、単一の検索インデックスを作成する方法を示します。 ファイル メタデータは、Azure Table Storage に格納されます。

Architecture

このアーキテクチャの PowerPoint ファイルをダウンロードします。

データフロー

1. ファイルは Blob Storage に格納され、場合によっては、限られた量のメタデータ (ドキュメントの作成者など) が一緒に格納されます。
2. 追加のメタデータは Table Storage に格納されます。これにより、各ドキュメントにはるかに多くの情報を格納できます。
3. インデクサーによって、BLOB メタデータと共に各ファイルのコンテンツが読み取られ、データが検索インデックスに格納されます。
4. 別のインデクサーによって、テーブルから追加のメタデータが読み取られ、同じ検索インデックスに格納されます。
5. 検索クエリが検索サービスに送信されます。 クエリから、ドキュメント コンテンツとドキュメント メタデータの両方に基づいて、一致するドキュメントが返されます。

コンポーネント

• Blob Storage から、PDF、HTML、CSV などの形式のデータや Microsoft 365 ファイルのデータなど、ファイル データに対してコスト効率の高いクラウド ストレージが提供されます。
• Table Storage から、非リレーショナル構造化データのストレージが提供されます。 このシナリオでは、各ドキュメントのメタデータを格納するために使用されます。
• Azure AI Search は、豊富な検索エクスペリエンスを構築するためのインフラストラクチャ、API、ツールを提供するフル マネージドの検索サービスです。

代替

このシナリオでは、Azure AI Search のインデクサーを使用して、サポートされているデータ ソース (BLOB ストレージやテーブル ストレージなど) 内の新しいコンテンツを自動的に検出して、検索インデックスに追加します。 または、Azure Cognitive Search から提供される API を使用して、検索インデックスにデータをプッシュすることもできます。 ただし、その場合は、検索インデックスにデータをプッシュし、検索するバイナリ ドキュメントのテキストを解析して抽出するコードを記述する必要があります。 Blob Storage インデクサーは多くのドキュメント形式をサポートしているため、テキストの抽出とインデックス作成のプロセスが大幅に簡素化されます。

また、インデクサーを使用する場合は、必要に応じて、インデックス作成パイプラインの一部としてデータをエンリッチできます。 たとえば、Azure AI サービスを使用して、ドキュメント内の画像の光学文字認識 (OCR) または視覚的分析を実行したり、ドキュメントの言語を検出したり、ドキュメントを翻訳したりすることができます。 独自のカスタム スキルを定義して、ビジネス シナリオに関連する方法でデータをエンリッチすることもできます。

このアーキテクチャでは、コスト効率が高く効率的であることから、BLOB ストレージとテーブル ストレージが使用されます。 この設計により、ドキュメントとメタデータを 1 つのストレージ アカウントに結合して保存することもできます。 ドキュメント自体でサポートされる代替データ ソースには、Azure Data Lake Storage と Azure Files が含まれます。 ドキュメント メタデータは、Azure SQL Database や Azure Cosmos DB など、構造化データを保持する他のサポートされているデータ ソースに格納できます。

シナリオの詳細

ファイル コンテンツの検索

このソリューションを使用すると、ユーザーは、ファイル コンテンツと、ドキュメントごとに個別に格納されている追加のメタデータの両方に基づいてドキュメントを検索できます。 ユーザーは、ドキュメントのテキスト コンテンツを検索するだけでなく、ドキュメントの作成者、ドキュメントの種類 ("紙" や"レポート" など)、またはそのビジネスへの影響 ("高"、"中"、"低") を検索できます。

Azure AI Search は、ユーザーが検索できるようにする情報を含む検索インデックスを作成できるフル マネージドの検索サービスです。

このシナリオで検索されるファイルはバイナリ ドキュメントであるため、Blob Storage に格納できます。 その場合は、Azure AI Search の組み込みの Blob Storage インデクサーを使用して、ファイルからテキストを自動的に抽出し、そのコンテンツを検索インデックスに追加できます。

ファイル メタデータの検索

ファイルに関する追加情報を含める場合は、別のストアを使用せずに、メタデータを BLOB に直接関連付けることができます。 組み込みの Blob Storage 検索インデクサーは、このメタデータを読み取って、検索インデックスに配置することもできます。 これにより、ユーザーはファイル コンテンツと共にメタデータを検索できます。 ただし、メタデータの量は BLOB あたり 8 KB に制限されるため、各 BLOB に配置できる情報の量はかなり小さくなります。 最も重要な情報だけを BLOB に直接格納するように選択できます。 このシナリオでは、ドキュメントの "作成者" のみが BLOB に格納されます。

このストレージ制限を克服するために、Table Storage など、サポートされているインデクサーを持つ別のデータ ソースに追加のメタデータを配置できます。 ドキュメントの種類、ビジネスへの影響、その他のメタデータ値を、テーブル内の個別の列として追加できます。 BLOB インデクサーと同じ検索インデックスをターゲットにするように組み込みの Table Storage インデクサーを構成すると、検索インデックス内のドキュメントごとに BLOB ストレージとテーブル ストレージのメタデータが結合されます。

1 つの検索インデックスに複数のデータ ソースを使用する

両方のインデクサーが確実に検索インデックス内の同じドキュメントを指すように、検索インデックス内のドキュメント キーがファイルの一意識別子に設定されます。 この一意識別子は、両方のデータ ソース内のファイルを参照するために使用されます。 BLOB インデクサーにより、metadata_storage_path が既定でドキュメント キーとして使用されます。 metadata_storage_path プロパティに、Blob Storage 内のファイルの完全な URL (例: https://contoso.blob.core.windows.net/files/paper/Resilience in Azure.pdf) が格納されます。 ドキュメント キーに無効な文字がないことを保証するために、インデクサーによって、値に対して Base64 エンコードが実行されます。 結果は、aHR0cHM6...mUucGRm0 のような一意のドキュメント キーです。

metadata_storage_path を Table Storage の列として追加すると、他の列のメタデータがどの BLOB に属するかを正確に把握できるため、テーブルで任意の PartitionKey 値と RowKey 値を使用できます。 たとえば、BLOB コンテナー名を PartitionKey、Blob の Base64 でエンコードされた完全な URL を RowKey として使用して、これらのキーにも無効な文字がないことを保証できます。

その後、テーブル インデクサーのフィールド マッピングを使用して、metadata_storage_pathTable Storage の列 (または別の列) を検索インデックスの metadata_storage_path ドキュメント キー フィールドにマップできます。 フィールド マッピングに base64Encode 関数を適用すると、最終的に同じドキュメント キー (前の例では aHR0cHM6...mUucGRm0) になり、Table Storage のメタデータが Blob Storage から抽出されたのと同じドキュメントに追加されます。

または、RowKey (BLOB の Base64 でエンコードされた完全な URL に設定されている) を metadata_storage_path ドキュメント キーに直接マップすることができ、個別に格納して、フィールド マッピングの一部として Base64 エンコードする必要はありません。 ただし、エンコードされていない URL を別の列に保持すると、参照する BLOB が明確になり、検索インデクサーに影響を与えることなくパーティション キーと行キーを選択できます。

考えられるユース ケース

このシナリオは、コンテンツと追加のメタデータに基づいてドキュメントを検索する機能を必要とするアプリケーションに適用されます。

考慮事項

これらの考慮事項は、ワークロードの品質向上に使用できる一連の基本原則である Azure Well-Architected Framework の要素を組み込んでいます。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

[信頼性]

信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性の重要な要素の概要」を参照してください。

Azure AI Search では、少なくとも 2 つのレプリカがある場合、読み取り (クエリ) に対して高いサービスレベル契約 (SLA) が提供されます。 少なくとも 3 つのレプリカがある場合は、"更新" (検索インデックスの更新) に対して高い SLA が提供されます。 そのため、ユーザーが確実に検索できるようにしたい場合は、少なくとも 2 つのレプリカをプロビジョニングし、インデックスへの実際の変更も高可用性操作とする必要がある場合は、少なくとも 3 つのレプリカをプロビジョニングする必要があります。

Azure Storage は常にデータの複数のコピーを保存し、計画されたイベントと計画外のイベントからデータを保護するのに役立ちます。 Azure Storage には、リージョン間でデータをレプリケートするための追加の冗長性オプションが用意されています。 これらのセーフガードは、BLOB ストレージとテーブル ストレージ内のデータに適用されます。

セキュリティ

セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。

Azure AI Search では、ネットワーク セキュリティ、認証と認可、データ所在地と保護、およびセキュリティ、プライバシー、コンプライアンスの維持に役立つ管理コントロールの実装に役立つ堅牢なセキュリティ制御が提供されます。

可能な限り、Microsoft Entra 認証を使用して検索サービス自体へのアクセスを提供し、マネージド ID を使用して検索サービスを他の Azure リソース (このシナリオでは BLOB ストレージとテーブル ストレージ) に接続します。

プライベート エンドポイントを使用して、検索サービスからストレージ アカウントに接続できます。 プライベート エンドポイントを使用する場合、インデクサーでプライベート接続を使用でき、BLOB ストレージとテーブル ストレージにパブリックにアクセスする必要はありません。

コストの最適化

コストの最適化とは、不要な費用を削減し、運用効率を向上させることです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。

このシナリオを実行するコストの詳細については、Azure 料金計算ツールで構成済みのこの見積もりを参照してください。 ここで説明するすべてのサービスは、この見積もりで構成されています。 見積もりは、Blob Storage の合計ドキュメント サイズが 20 GB、Table Storage のメタデータが 1 GB のワークロードに対するものです。 この記事の「信頼性」セクションで説明されているように、読み取り目的で SLA を満たすために 2 つの検索ユニットが使用されます。 特定のユース ケースについて価格の変化を確認するには、予想される使用量に合わせて該当する変数を変更します。

見積もりを確認すると、BLOB ストレージとテーブル ストレージのコストが比較的低いことがわかります。 ほとんどのコストは、Azure Cognitive Search によって発生します。これは、検索クエリを実行するために実際のインデックス作成と計算が実行されるためです。

このシナリオのデプロイ

このサンプル ワークロードをデプロイするには、「Azure AI Search でのファイル コンテンツとメタデータのインデックス作成」を参照してください。 このサンプルを使用して、次のことができます。

• 必要な Azure サービスを作成する。
• いくつかのサンプル ドキュメントを Blob Storage にアップロードする。
• BLOB に "作成者" メタデータ値を設定する。
• "ドキュメントの種類" と "ビジネスに影響する" メタデータ値を Table Storage に格納する。
• 検索インデックスを維持するインデクサーを作成する。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパル作成者:

• Jelle Druyts | プリンシパル カスタマー エクスペリエンス エンジニア

その他の共同作成者:

• Mick Alberts | テクニカル ライター

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

• Azure Cognitive Search の使用を開始する
• Azure Cognitive Search のセマンティック検索を使用して関連性を高める
• Azure Cognitive Search の結果をトリミングするためのセキュリティ フィルター
• チュートリアル:.NET SDK を使用して複数のデータ ソースのデータにインデックスを付ける

関連リソース

• Azure で検索データ ストアを選択する
• eコマースのインテリジェントな製品検索エンジン