Azure portal のデータのインポート ウィザード

Azure AI Search には、さまざまな検索シナリオでインデックス作成、エンリッチメント、オブジェクトの作成を自動化する 2 つのウィザードがあります。

• データのインポート ウィザードでは、キーワード (非ベクトル) 検索がサポートされます。 生のドキュメントからテキストと数値を抽出できます。 また、適用された AI と組み込みのスキルを構成して、構造を推測し、画像ファイルや非構造化データから検索可能なテキストを生成することもできます。

• データのインポート (新規) ウィザードでは、キーワード検索、RAG、マルチモーダル RAG がサポートされます。 キーワード検索では、 データのインポート ワークフローが最新化されますが、メタデータ フィールドの自動作成などの機能がありません。 RAG とマルチモーダル RAG では、埋め込みモデルのデプロイに接続し、要求を送信し、テキストまたはイメージからベクターを生成します。

違いはありますが、ウィザードはコンテンツ インジェストとインデックス作成に関して同様のワークフローに従います。 次の表は、その機能をまとめたものです。

この記事では、概念実証テストに役立つウィザードのしくみについて説明します。 サンプル データを使用した詳細な手順については、「 ウィザードを試す」を参照してください。

サポートされているデータ ソースとシナリオ

このセクションでは、各ウィザードで使用できるオプションについて説明します。

データ ソース

ウィザードでは次のデータ ソースがサポートされており、そのほとんど で組み込みのインデクサーが使用されます。 例外はテーブルの脚注に示されています。

¹ このデータ ソースでは、組み込みのインデクサーではなく Azure Logic Apps コネクタ (プレビュー) を使用します。

² Logic Apps コネクタを使用する代わりに、Search Service REST API を使用して 、Azure File Storage または SharePoint Online のデータのインデックスをプログラムで作成できます。

サンプル データ

Microsoft は、データ ソース構成のウィザード手順をスキップできるように、次のサンプル データをホストします。

スキル

各ウィザードでは、スキルセットが生成され、選択したオプションに基づいてフィールド マッピングが出力されます。 スキルセットが作成されたら、その JSON 定義を変更してスキルを追加または削除できます。

ウィザードで生成されたスキルセットには、次のスキルが表示される場合があります。

¹ このスキルは、RAG ワークフローとマルチモーダル RAG ワークフローでのみ使用できます。 キーワード検索はサポートされていません。

² このスキルは、既定の解析モードを想定して、Azure Storage BLOB と Microsoft OneLake ファイルで使用できます。 画像には、画像コンテンツ タイプ (PNG や JPG など) やアプリケーション ファイル (PDF など) に埋め込まれた画像を指定できます。

³ このスキルは、ナレッジ ストアを構成するときに追加されます。

⁴ このスキルは、埋め込みモデルを選択するときにデータ チャンク用に追加されます。 非埋め込みスキルの場合、ソースフィールドの細分性をページまたは文に設定すると追加されます。

セマンティック ランカー

セマンティック ランク付けを構成して、検索結果の関連性を向上させることができます。

ナレッジ ストア

エンリッチされた (スキルによって生成された) コンテンツのセカンダリ ストレージのためにナレッジ ストアを生成できます。 ナレッジ ストアは、検索エンジンを必要としない情報取得ワークフローに役立ちます。

ウィザードで作成される内容

次の表に、ウィザードによって作成されたオブジェクトの一覧を示します。 オブジェクトが作成されたら、Azure portal で JSON 定義を確認したり、コードから呼び出したりすることができます。

ウィザードの実行後にこれらのオブジェクトを表示するには:

1. Azure portal にサインインし、検索サービスを選択します。
2. 左側のウィンドウで、[ 検索管理 ] を選択して、インデックス、インデクサー、データ ソース、スキルセットのページを検索します。

メリット

コードを記述する前に、ウィザードを使用してプロトタイプ作成と概念実証テストを行うことができます。 ウィザードでは、外部データ ソースに接続し、データをサンプリングして初期インデックスを作成します。次に、データを JSON ドキュメントとして Azure AI Search のインデックスにインポートし、必要に応じてベクトル化します。

スキルセットを評価する場合、ウィザードは出力フィールドマッピングを処理し、ヘルパー関数を追加して使用可能なオブジェクトを作成します。 解析モードを指定すると、テキスト分割が追加されます。 テキストの結合 は、画像分析を選択すると追加されるため、ウィザードでテキストの説明を画像の内容と再結合できます。 ナレッジ ストア オプションを選択すると、有効なプロジェクションをサポートするために Shaper が追加されます。 これらすべてのタスクには、学習曲線が付属しています。 エンリッチメントを初めて使用する場合は、これらの手順を処理することで、多くの時間と労力を費やすことなくスキルの価値を測定できます。

サンプリングとは、インデックス スキーマが推論されるプロセスであり、いくつかの制限があります。 データ ソースが作成されると、ウィザードはドキュメントのランダムなサンプルを選択して、データ ソースの一部である列を決定します。 すべてのファイルが読み取られているわけではありません。これにより、大規模なデータ ソースに数時間かかる可能性があるためです。 ドキュメントを選択すると、ソース メタデータ (フィールド名や型など) を使用して、インデックス スキーマにフィールド コレクションが作成されます。 ソース データの複雑さに基づいて、精度を高めるために初期スキーマを編集するか、完全にするために拡張することが必要になる場合があります。 インデックスの定義のページで、変更をインラインで行うことができます。

全体として、ウィザードの利点は明確です。要件が満たされている限り、数分以内にクエリ可能なインデックスを作成できます。 ウィザードでは、データを JSON ドキュメントとしてシリアル化するなど、インデックス作成の複雑な部分を処理します。

制限事項

ウィザードには、次の制限があります。

• ウィザードでは、イテレーションと再利用はサポートされていません。 ウィザードを通過するたびに、インデックス、スキルセット、インデクサーの構成が作成されます。 データ ソースは、データの インポート ウィザードでのみ再利用できます。 ウィザードが完了したら、他のポータル ツール、REST API、または Azure SDK を使用して、作成されたオブジェクトを編集できます。

• ソース コンテンツは、サポートされているデータ ソース内にある必要があります。

• サンプリングは、ソース データのサブセットに対して行われます。 大規模なデータ ソースの場合、ウィザードたちがフィールドを見落とす可能性があります。 サンプリングが不十分な場合は、スキーマを拡張するか、推論されたデータ型を修正する必要があります。

• Azure portal で公開されている AI エンリッチメントは、組み込みのスキルのサブセットに制限されます。

• ナレッジ ストアは、データのインポート ウィザードでのみ使用でき、いくつかの既定のプロジェクションに制限され、既定の名前付け規則を使用します。 プロジェクションと名前をカスタマイズするには、REST API または Azure SDK を使用してナレッジ ストアを作成する必要があります。

セキュリティで保護された接続

ウィザードでは、Azure portal コントローラーとパブリック エンドポイントを使用して送信接続を行います。 プライベート接続または共有プライベート リンク経由で Azure リソースにアクセスする場合、ウィザードを使用することはできません。

制限付きパブリック接続経由でウィザードを使用できますが、すべての機能を使用できるわけではありません。

• 検索サービスでは、組み込みのサンプル データをインポートするにはパブリック エンドポイントが必要であり、ファイアウォール規則は必要ありません。

  Microsoft は、特定の Azure リソースに関するサンプル データをホストします。 Azure portal コントローラーは、パブリック エンドポイント経由でこれらのリソースに接続します。 検索サービスがファイアウォールの内側にある場合、サンプル データの取得を試みると、 Import configuration failed, error creating Data Source、その後に "An error has occured."というエラーが発生します。

• ファイアウォールによって保護されているサポート対象 Azure データ ソースでは、適切なファイアウォール規則が設定されている場合にデータを取得できます。

  Azure リソースは、接続で使用されるデバイスの IP アドレスからのネットワーク要求を許可する必要があります。 また、リソースのネットワーク構成で、信頼できるサービスとして Azure AI 検索をリストに含める必要があります。 たとえば、Azure Storage では、信頼できるサービスとして Microsoft.Search/searchServices をリストに追加できます。

• 指定した Azure AI サービス マルチサービス アカウントへの接続、または Azure AI Foundry ポータルまたは Azure OpenAI にデプロイされた埋め込みモデルへの接続では、検索サービスがプライベート接続の作成日、階層、リージョンの要件を満たしていない限り、パブリック インターネット アクセスを有効にする必要があります。 詳細については、「 共有プライベート リンクを介した送信接続の作成」を参照してください。

  Azure AI サービスのマルチサービス アカウントへの接続は、 課金目的です。 API が組み込みスキルを呼び出した場合 (データの インポート ウィザードまたはデータのインポート (新しい) ウィザードのキーワード検索ワークフロー)、統合ベクター化 ( データのインポート (新規) ウィザード) が無料のトランザクション数 (インデクサー実行あたり 20) を超えた場合に課金されます。

  Azure AI 検索が接続できない場合:

  • データの インポート (新規) ウィザードでは、エラーは "Access denied due to Virtual Network/Firewall rules."。

  • データ インポート ウィザードでは、エラーは表示されませんが、スキルセットは作成されません。

ファイアウォール設定によってウィザードのワークフローが成功できない場合は、代わりにスクリプトまたはプログラムによるアプローチを検討してください。

Workflow

どちらのウィザードも、同様の高度なワークフローに従います。

1. サポートされている Azure データ ソースに接続します。

2. (省略可能)コンテンツと構造を抽出または生成するスキルを追加します。

3. ソース データのサンプリングによって推論されるインデックス スキーマを作成します。

4. ウィザードを実行して、オブジェクトの作成、必要に応じてデータのベクター化、インデックスへのデータの読み込み、スケジュールの設定、その他のオプションの構成を行います。

ワークフローは一方向パイプラインです。 ウィザードを使用して作成されたオブジェクトを編集することはできませんが、インデックス デザイナー、インデクサー デザイナー、JSON エディターなどの他のポータル ツールを使用して、許可された更新を行うことができます。

ウィザードの開始

ウィザードを開始するには:

1. Azure portal にサインインし、検索サービスを選択します。

2. [ 概要 ] ページで、[ データのインポート ] または [ データのインポート (新規)] を選択します。

   

   ウィザードがブラウザー ウィンドウで完全に展開されて開き、作業するスペースが増えます。

3. [データの インポート] を選択した場合は、[ サンプル ] を選択して、サポートされているデータ ソースから Microsoft がホストするデータセットのインデックスを作成できます。

   

4. 残りの手順に従って、インデックス、インデクサー、およびその他の適用可能なオブジェクトを作成します。

[Import data (データのインポート)] は、Azure Cosmos DB、Azure SQL Database、SQL Managed Instance、Azure Blob Storage を含む、他の Azure サービスから起動することもできます。 サービスの概要ページの左側のウィンドウで、[ Azure AI Search の追加] を探します。

ウィザードでのデータ ソースの構成

ウィザードは、インデクサーによって提供される内部ロジックを使用して外部で サポートされているデータ ソース に接続します。このロジックは、ソースのサンプリング、メタデータの読み取り、コンテンツと構造の読み取りのためのドキュメントの解読、および後の Azure AI Search へのインポートのために JSON としてコンテンツをシリアル化する機能を備えています。

データの インポート ウィザードでは、サポートされているデータ ソースへの接続を別のサブスクリプションまたはリージョンに貼り付けることができますが、[ 既存の接続の選択 ] ピッカーのスコープはアクティブなサブスクリプションになります。

すべてのプレビュー データ ソースがウィザードで使用できるわけではありません。 各データ ソースはダウンストリームに変更を導入する可能性があるため、プレビュー データ ソースは、スキルセット定義やインデックス スキーマ推論など、ウィザードのすべてのエクスペリエンスを完全にサポートしている場合にのみ追加されます。

インポートできるのは、1 つのテーブル、データベース ビュー、または同等のデータ構造からのみです。 ただし、構造には階層構造または入れ子になったサブ構造を含めることができます。 詳細については、複合型のモデル化の方法に関するページを参照してください。

ウィザードでのスキルセットの構成

データ ソースの種類によって特定の組み込みのスキルが使用可能かどうかが通知されるため、データ ソース定義の後にスキルセットの構成が行われます。 たとえば、Azure Blob Storage からファイルのインデックスを作成する場合、それらのファイルに対して選択した解析モードによって、センチメント分析を使用できるかどうかが決まります。

ウィザードでは、選択したスキルだけでなく、結果を成功させるために必要なスキルも追加されます。 たとえば、 データのインポート ウィザードでナレッジ ストアを指定した場合、ウィザードはプロジェクションまたは物理データ構造をサポートする Shaper スキルを追加します。

スキルセットは省略可能であり、AI エンリッチメントが不要な場合は、ページの下部にスキップするボタンがあります。

ウィザードでのインデックス スキーマの構成

ウィザードでは、データ ソースをサンプリングして、フィールドとフィールドの種類を検出します。 データ ソースによっては、メタデータのインデックス作成用のフィールドも提供される場合があります。

サンプリングは不正確な演習であるため、次の考慮事項についてインデックスを確認してください。

1. フィールドの一覧は正確ですか。 サンプリングで取得されなかったフィールドがデータ ソースに含まれている場合は、ミスしたフィールドを手動で追加できます。 検索エクスペリエンスに値を追加しないフィールドや、 フィルター式 または スコアリング プロファイルで使用されないフィールドを削除することもできます。

2. データ型は受信データに適していますか。 Azure AI Search では、Entity Data Model (EDM) データ型がサポートされています。 Azure SQL データの場合、同等の値をレイアウトする マッピング グラフ があります。 詳細については、「 フィールド マッピングと変換」を参照してください。

3. "キー" として使用できるフィールドが 1 つありますか。 このフィールドは、ドキュメントを一意に識別する Edm.String である必要があります。 リレーショナル データの場合は、主キーにマップされていることがあります。 BLOB の場合、metadata-storage-path であることがあります。 フィールド値にスペースまたはダッシュが含まれている場合は、[インデクサーの作成] ステップの [詳細オプション] で Base-64 エンコード キーオプションを設定して、これらの文字の検証チェックを抑制する必要があります。

4. 属性を設定して、インデックスでのこのフィールドの使用方法を指定します。

   インデックス内のフィールドの物理的な表現が属性によって決定されるため、この手順に時間をかけてください。 後でプログラムを使用しても属性を変更する場合は、ほとんどの場合、インデックスを削除して再構築する必要があります。 Searchable や Retrievable などのコア属性では、ストレージへの効果は無視できる程度です。 フィルターを有効にして suggester を使用すると、ストレージの要件が増えます。

   • Searchable では、全文検索が有効になります。 自由形式のクエリまたはクエリ式で使用されるすべてのフィールドには、この属性が必要です。 Searchable としてマークしたフィールドごとに、逆インデックスが作成されます。

   • Retrievable の場合、検索結果にフィールドが返されます。 検索結果にコンテンツを提供するすべてのフィールドに、この属性が必要です。 このフィールドを設定しても、インデックス サイズに大きな影響はありません。

   • Filterable は、フィルター式でフィールドを参照できるようにします。 $filter 式で使用されるすべてのフィールドに、この属性が必要です。 このフィルター式は完全一致用です。 テキスト文字列はそのまま残るため、逐語的なコンテンツに対応するには、追加のストレージが必要です。

   • Facetable は、ファセット ナビゲーションにフィールドを使用できるようにします。 Filterable としてもマークされているフィールドのみを、Facetable としてマークできます。

   • Sortable は、並べ替えでフィールドを使用できるようにします。 $Orderby 式で使用されるすべてのフィールドに、この属性が必要です。

5. 字句解析が必要ですか。 検索可能な Edm.String フィールドの場合、言語拡張インデックス作成とクエリが必要な場合は、アナライザーを設定できます。

   既定値は Standard Lucene ですが、不規則な名詞や動詞の形式の解決など、高度な字句処理に Microsoft のアナライザーを使用する場合は、 Microsoft 英語 を選択できます。 Azure portal では、言語アナライザーのみを指定できます。 キーワードやパターンなど、カスタム アナライザーまたは言語以外のアナライザーを使用する場合は、プログラムで作成する必要があります。 詳細については、「 言語アナライザーの追加」を参照してください。

6. オートコンプリートまたは候補の結果の形式の先行入力機能が必要ですか。 選択したフィールドで先行入力クエリ候補とオートコンプリートを有効にするには、[Suggester] チェック ボックスをオンにします。 Suggesters は、インデックス内のトークン化された用語の数に追加されるため、より多くのストレージを消費します。

ウィザードでのインデクサーの構成

ウィザードの最後のページでは、インデクサーの構成に関するユーザー入力が収集されます。 スケジュールを指定し、データ ソースの種類によって異なるその他のオプションを設定できます。

内部的には、ウィザードによって次の定義が設定されます。この定義は、作成されるまでインデクサーには表示されません。

• データ ソースとインデックスの間のフィールド マッピング。
• スキルの出力とインデックスの間の出力フィールド マッピング。

ウィザードを試す

ウィザードの利点と制限事項を理解する最善の方法は、ウィザードの手順を進んでみることです。 次のクイックスタートは、ウィザードを基にしています。

• クイックスタート: 検索インデックスを作成する
• クイックスタート: テキスト翻訳とエンティティ スキルセットを作成する
• クイック スタート: ベクトル インデックスを作成する
• クイック スタート: マルチモーダル インデックスを作成する