Azure AI Serch(旧Azure Cognitive Search)の機能と料金を徹底解説！

データの検索精度とユーザーエクスペリエンスの向上は、現代のビジネスにおける重要な課題です。その解決策として、Microsoft Azureの革新的な検索サービス「Azure Cognitive Search」が注目を集めています。

本記事では、Azure AI Searchの特徴や利用シーン、活用方法を網羅的に解説します。充実したフィーチャーと高度なスケーリングオプション、強固なセキュリティ対策で企業データを確実に保護する点にも触れつつ、無料プランからエンタープライズレベルのニーズまで対応する柔軟な料金体系についてもご紹介します。

ユーザーエクスペリエンスの向上と業務効率化を目指す企業にとって、Azure AI Searchがもたらす価値と可能性を存分に探っていただける内容となっています。

Azure AI Searchとは

「Azure AI Search」（旧称「Azure Cognitive Search」）は、Microsoft Azureが提供するサービスであり、従来の検索アプリケーションと対話型検索アプリケーションの両方において、ユーザーが所有するコンテンツに対する大規模で安全な情報検索を容易にします。

Azure AI Searchの主な機能

• ベクトル検索、全文検索、検索インデックス上でのハイブリッド検索のための検索エンジン。
• データのチャンキングとベクトル化、テキストの字句解析、コンテンツ抽出と変換のためのオプションのAIエンリッチメントを統合したリッチなインデックス作成。
• ベクトル検索、テキスト検索、ハイブリッド検索、ファジー検索、オートコンプリート、ジオ検索などをサポートする豊富なクエリ構文。
• データレイヤー、機械学習レイヤー、Azure AIサービス、Azure OpenAIなど、さまざまなレイヤーでAzureサービスと統合。

アーキテクチャ

Azure AI Searchのアーキテクチャには、インデックス化されていないデータを含む外部データストアと、検索インデックスにクエリーリクエストを送信しレスポンスを処理する検索サービスが含まれます。検索エクスペリエンスは、Azure AI Searchが提供するAPIを使用して定義され、関連性のチューニング、セマンティックランキング、オートコンプリート、類義語マッチングなどの機能を可能にします。

主なワークロード

• インデックス作成
  検索可能なコンテンツを検索サービスに読み込むプロセス。テキストはトークンに処理されて転置インデックスに格納され、ベクトルはベクトルインデックスに格納されます。JSONはインデックス作成のためのサポートされたドキュメントフォーマットであり、コグニティブスキルを付加してOCR、画像説明、構造推論、翻訳、データチャンキング、ベクトル化などのタスクを実行することができます。
• クエリ
  クエリ要求はクライアントアプリから検索サービスに送信され、検索インデックスから関連情報を取得します。セマンティック・ランキングは、検索結果の処理に言語理解を追加することで、クエリの実行を強化します。

Azure AI Serchの利用シーン

Azure Cognitive Searchを活用することで、ユーザーはドキュメントの内容だけでなく、各ファイルに紐づけられたメタデータも含めて総合的に検索できます。これにより、単なるテキストマッチングを超えた、より文脈に即した検索が可能になります。

例えば、ドキュメント内のキーワードに加え、作成者やドキュメントタイプ、ビジネスへの影響度などのメタデータ属性も検索条件に含めることができます。これにより、ユーザーは必要な情報により的確にアクセスできるようになります。

さらに、Azure Cognitive SearchはBlob Storageとシームレスに連携します。
バイナリ形式のドキュメントをBlob Storageに保存しておけば、組み込みのBlob Storageインデクサーが自動的にテキストを抽出し、その内容を検索インデックスに追加してくれます。

この機能は、膨大なドキュメントの中から特定の情報を効率的に見つけ出すというシナリオで威力を発揮します。ユーザーは欲しい情報にスピーディーにたどり着くことができ、業務の生産性向上につながるでしょう。

Azure Cognitive Searchなら、ドキュメントの内容とメタデータを横断的に検索できる柔軟性と、Blob Storageとの連携による利便性を兼ね備えています。貴社のデータ活用を、より効果的なものへと進化させる強力な味方となるはずです。

Microsoft Azure Cognitive Searchの検索インデックスの定義

{
  "name": "name_of_index, unique across the service",
  "fields": [
    {
      "name": "name_of_field",
      "type": "Edm.String | Collection(Edm.String) | Collection(Edm.Single) | Edm.Int32 | Edm.Int64 | Edm.Double | Edm.Boolean | Edm.DateTimeOffset | Edm.GeographyPoint",
      "searchable": true (default where applicable) | false (only Edm.String and Collection(Edm.String) fields can be searchable),
      "filterable": true (default) | false,
      "sortable": true (default where applicable) | false (Collection(Edm.String) fields cannot be sortable),
      "facetable": true (default where applicable) | false (Edm.GeographyPoint fields cannot be facetable),
      "key": true | false (default, only Edm.String fields can be keys),
      "retrievable": true (default) | false,
      "analyzer": "name_of_analyzer_for_search_and_indexing", (only if 'searchAnalyzer' and 'indexAnalyzer' are not set)
      "searchAnalyzer": "name_of_search_analyzer", (only if 'indexAnalyzer' is set and 'analyzer' is not set)
      "indexAnalyzer": "name_of_indexing_analyzer", (only if 'searchAnalyzer' is set and 'analyzer' is not set)
      "normalizer":  "name_of_normalizer", (applies to fields that are filterable)
      "synonymMaps": "name_of_synonym_map", (optional, only one synonym map per field is currently supported)
      "dimensions": "number of dimensions used by an emedding models", (applies to vector fields only, of type Collection(Edm.Single))
      "vectorSearchProfile": "name_of_vector_profile" (indexes can have many configurations, a field can use just one)
    }
  ],
  "suggesters": [ ],
  "scoringProfiles": [ ],
  "analyzers":(optional)[ ... ],
  "charFilters":(optional)[ ... ],
  "tokenizers":(optional)[ ... ],
  "tokenFilters":(optional)[ ... ],
  "defaultScoringProfile": (optional) "...",
  "corsOptions": (optional) { },
  "encryptionKey":(optional){ },
  "semantic":(optional){ },
  "vectorSearch":(optional){ }
}

参考:Schema of a search index

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

• ドキュメントの内容だけでなく、各ドキュメントに関連付けられたメタデータに基づいても検索が可能です。

• メタデータはBlob Storage内のBLOBに直接関連付けることができ、組み込みのBlob Storageインデクサーはこのメタデータを読み取り、検索インデックスに含めることができます。

• ただし、BLOBに直接保存できるメタデータの量はBLOBあたり8 KBに制限されているため、重要な情報のみをBLOBに直接保存することができます。

• この制限を克服するには、追加のメタデータをTable Storageなどの別のデータソースに保存し、より広範なメタデータを収容できます。

• BLOBインデクサーと同じ検索インデックスをターゲットにするように組み込みのTable Storageインデクサーを構成することで、両方のソースからのメタデータを検索インデックス内のドキュメントごとに組み合わせることができます。

インデクサーとインデックス

今回は検索する際のBlob Indexerについて紹介したいと思います。

1. インデクサーの構成

• 実行時の動作を制御するために、入力、パラメーター、プロパティを設定します。
• BLOBのどの部分をインデックス化するかを指定します。

POST https://[service name].search.windows.net/indexers?api-version=2020-06-30
{
  "name" : "my-blob-indexer",
  "dataSourceName" : "my-blob-datasource",
  "targetIndexName" : "my-search-index",
  "parameters": {
      "batchSize": null,
      "maxFailedItems": null,
      "maxFailedItemsPerBatch": null,
      "base64EncodeKeys": null,
      "configuration": {
          "indexedFileNameExtensions" : ".pdf,.docx",
          "excludedFileNameExtensions" : ".png,.jpeg",
          "dataToExtract": "contentAndMetadata",
          "parsingMode": "default"
      }
  },
  "schedule" : { },
  "fieldMappings" : [ ]
}

2. インデクサーの作成または更新

• インデクサーに名前を付け、データソースとターゲットインデックスを参照します。
  
  

3. バッチサイズの設定

• デフォルトのサイズ (10 ドキュメント) が適切でない場合は、batchSizeを調整します。
• デフォルトのバッチサイズはデータソースによって異なります。通常、BLOBインデックス作成では1つのバッチあたり10ドキュメントが推奨されます。
  
  

4. 構成

• ファイルの種類に基づいて、どのBLOBをインデックス化するかを制御します。指定がない場合、すべてのBLOBがインデックス化されます。
• インデックス付きと除外されるファイル名の拡張子を定義します。
  
  

5. 抽出するデータ

• BLOBのどの部分をインデックス化するかを指定します。
• "contentAndMetadata": BLOBから抽出されたすべてのメタデータとテキストコンテンツがインデックス化されます (既定)。
• "storageMetadata": 標準のBLOBプロパティとユーザー指定のメタデータのみがインデックス化されます。
• "allMetadata": 見つかったコンテンツタイプの標準BLOBプロパティとメタデータが抽出され、インデックスが付けられます。
  
  

6. 解析モード

• BLOBコンテンツの解析モードを指定します。
• デフォルトモード: BLOBごとに1つの検索ドキュメント。
• プレーンテキスト解析: プレーンテキストBLOBのパフォーマンスが向上します。
• 1対多の解析: BLOBを複数の検索ドキュメントにマッピングします。JSONドキュメントとCSVファイルでサポートされます。
  
  

7. フィールドマッピング

• フィールド名やタイプの違いに対応するためのフィールドマッピングを定義し、検索インデックスにソースフィールドの複数のバージョンを作成します。

詳しくはこちらの記事をご覧ください。Index data from Azure Blob Storage

柔軟なプログラミングとAPI

1. GETリクエスト

• GETリクエストは、検索サービス内の単一のインデックスのドキュメントコレクションを対象とします。
• マッチ条件を定義し、レスポンスの形状を整えるパラメータが含まれます。
• クエリパラメータは、クエリ文字列に指定されます。

GET https://[サービス名].search.windows.net/indexes/[インデックス名]/docs?[クエリパラメータ]
Content-Type: application/json
api-key: [管理者またはクエリキー]

2. POSTリクエスト

• POSTでは、URIパラメータとして「search」アクションが追加されます。
• パラメータはリクエストボディに含まれます。
• URLの長さ制限がないため、大きなクエリに適しています。

POST https://[サービス名].search.windows.net/indexes/[インデックス名]/docs/search?api-version=[APIバージョン]
Content-Type: application/json
api-key: [管理者またはクエリキー]

• URIパラメーター

[service name] 必須。検索サービスの一意のユーザー定義名を設定します。
[index name]/docs 必須。指定されたインデックスのドキュメントコレクションを指定します。
[query parameters] クエリパラメータはGETリクエストのURIに指定され、POSTリクエストのリクエストボディに指定されます。
api-version 必須。現在の安定版のバージョンはapi-version=2020-06-30です。他のバージョンについてはAPIバージョンを参照してください。クエリに対しては、api-versionは常にGETとPOSTの両方のURIパラメータとして指定されます。
詳しくはこちら Search Documents (Azure AI Search REST API)

Azure AI Searchの料金体系

Azureの料金体系についてはこちらの記事で詳しく解説しています。
➡️Azureの料金体系を解説！サービスごとの料金例や確認方法も紹介

Freeプラン

初めてAzure Cognitive Searchを試してみるには、Freeプランが適しています。制限があるため、大規模なプロジェクトには不向きかもしれませんが、サービスを使ってみる際には、コストをかけずに試すことができます。

• 小規模プロジェクト向け。
• 制限付きの検索サービスを作成可能。
• インデックス数は1つまで。
• インデクサー数は3つまで。
• 利用可能ストレージは50MBまで。
• 企業向けではなく、まずはサービスを試してみたい方に適している。

Basicプラン

Basicプランでは、少しのコストをかけて、より多くの機能を利用できます。レプリカの作成やセキュリティ強化のために使いたい場合に適しています。このプランは小規模なビジネスには十分な機能を提供しますが、大規模なプロジェクトには不十分かもしれません。

• インデックスのレプリカ作成が可能。
• 暗号化キーの作成やファイアウォールの使用にも対応。
• 価格は1インデックスあたり毎時間18.79円から。
• 基本インデックスは1つだが、3つのレプリカを作成可能。

料金について詳しくはこちら

Standardプラン

災害対策が可能で、より頑強なシステムを構築したい場合に適しています。S1～S3のタイプがあり、用途に合わせて選択できます。大規模なビジネスやデータドリブンなプロジェクトには最適なプランです。

• 災害対策が可能。
• S1～S3までのタイプがあり、最大インデックス数や利用可能ストレージ容量が異なる。
• 料金はMicrosoftの公式ページを参照。

Storage Optimizedプラン

テラバイト規模の大量のデータを扱う場合に最適です。変更頻度が低いが、大規模なデータ処理が必要な場合に有用です。コストが高いため、よく計画を立ててから導入する必要があります。

• テラバイト規模の大量のデータを利用する場合に適している。
• 変更頻度が低く、大規模なインデックスに推奨。
• 用途に合った契約を行うために、変更頻度や検索の待ち時間などを確認することが重要。

Azure AI Serchのデベロッパーガイド

クイック スタートとチュートリアル

前提条件として、Active Subscriptionを持つAzureアカウントを持っていることが大前提です。アカウントはここから無料で作ることができます。
任意の階層と任意の地域のAzure AI Searchサービス。サービスを作成するか、現在のサブスクリプションで既存のサービスを検索します。このクイックスタートでは、無料のサービスを使用できます。

• スペースの確認
  多くのお客様は無料サービスから開始します。無料層では、3つのインデックス、3つのデータソース、3つのインデクサに制限されています。
  始める前に、余分な項目のためのスペースがあることを確認してください。このクイックスタートでは、各オブジェクトを1つずつ作成します。
  サービスの「概要」>「使用状況」タブで、すでに持っているインデックス、インデクサー、データソースの数を確認します。

セキュリティとコンプライアンス

データフロー（ネットワークトラフィックパターン）

Azure AI Searchサービスは通常、パブリックネットワーク接続を介してクライアントアプリケーションからアクセスされます。これが一般的なパターンですが、注意する必要があるのはこれだけではありません。すべてのエントリーポイントとアウトバウンドトラフィックを理解することは、開発および本番環境をセキュアにするための基本的な情報です。

Azure AI Searchには次の3つの基本的なネットワークトラフィックパターンがあります：

1. クライアントからサービスへの入力要求（主要なパターン）
2. サービスからAzureおよびその他のサービスへのアウトバウンド要求
3. 内部サービス間の要求（Microsoftの安全なバックボーンネットワークを介したもの）
   
   

• インバウンドトラフィック
  インデックス、インデクサー、データソース、スキルセット、シノニムマップの作成または管理、インデクサーまたはスキルセットの実行のトリガー、インデックスのロードまたはクエリなど、検索サービスエンドポイントを対象とするインバウンド要求は次のように特徴付けられます。少なくともすべてのインバウンド要求は認証される必要があります。
  
  
  

• アウトバウンドトラフィック
  検索サービスから他のアプリケーションへのアウトバウンド要求は、通常、テキストベースのインデックス作成、スキルベースのAIエンリッチメント、およびベクトル化のためにインデクサーによって行われます。アウトバウンド要求には読み取りおよび書き込み操作の両方が含まれます。以下は、検索サービスによって行われるアウトバウンド要求の完全な列挙です。
  
  

• 内部トラフィック
  内部要求はMicrosoftによってセキュリティが確保され、管理されます。これらの接続を構成または制御することはできません。
  
  

• ネットワークセキュリティ
  ネットワークセキュリティは、ネットワークトラフィックに対して制御を適用することで、リソースを不正なアクセスや攻撃から保護します。Azure AI Searchは、未承認のアクセスに対する最初の防衛線となるネットワーキング機能をサポートしています。

詳しくはこちら Security overview for Azure AI Search

コミュニティサポート

Azureコミュニティサポートでは、質問をする、回答を得る、MicrosoftのエンジニアやAzureコミュニティの専門家とつながることができます。

Azure on Q&Aの紹介
Azureサービスに関する技術的な質問をする、Microsoftやコミュニティの専門家とつながる、回答を見つけることができます。

• サポートされているコミュニティチャンネル
  Stack Overflow: 開発に関する質問に対するコミュニティの回答を探索することができます。
  Twitter上のAzureサポート: Azureの顧客をリソースやサポートにつなぎます。

まとめ

この度は、Azureのサービスに関する情報をご紹介しました。Azureは、ビジネスやプロジェクトに組み込むことで、強力なツールとなります。豊富な機能やサポート体制を活用して、さまざまなニーズに応えることができます。ぜひ、Azureを活用して、ビジネスやプロジェクトの成果を最大限に引き出してください。