Azure AI Search

解決する課題

大量の文書やデータに対して、キーワード一致と意味的な近さの両方で「関連する情報を素早く返す」検索層を、自前でクラスターを運用せずに提供します。特に生成 AI と組み合わせる RAG（検索拡張生成）で、LLM に渡す根拠文書を取り出す検索エンジンとして使われます。

• 全文検索だけでは拾えない 言い換えや意味的な近さ でも文書を見つけたい（ベクトル検索）
• キーワード一致と意味検索を 組み合わせて精度を上げたい（ハイブリッド検索 + セマンティックランカー）
• Blob Storage や SQL などの データ源から定期的に自動でインデックスを更新 したい（インデクサー）
• 取り込み時に 文書の分割・埋め込み生成・OCR・エンティティ抽出 を自動化したい（スキルセット）
• LLM アプリに 根拠付きの回答 を返すための検索基盤がほしい（RAG）

主要概念と用語

• インデックス（Index）: 検索対象のドキュメント集合とスキーマ（フィールド定義）。検索可能・フィルター可能などの属性をフィールドごとに設定する
• ドキュメント（Document）: インデックス内の 1 件のレコード。フィールドの集合として表現される
• フィールド属性: フィールドが searchable（全文検索対象）、filterable、sortable、facetable、retrievable のいずれであるかを定義する設定
• インデクサー（Indexer）: Blob Storage、Azure SQL、Cosmos DB などのデータ源を巡回し、ドキュメントをインデックスへ取り込むクローラー
• データソース（Data source）: インデクサーが接続する元データの定義
• スキルセット（Skillset）: インデクサー実行中に走らせる AI エンリッチメントのパイプライン。テキスト分割、埋め込み生成、OCR、キーフレーズ抽出などのスキルを連結する
• ベクトル検索: ドキュメントとクエリを埋め込みベクトルに変換し、近傍探索で意味的に近い文書を返す検索方式
• ハイブリッド検索: 全文検索（BM25 系）とベクトル検索を併用し、結果を統合する方式
• セマンティックランカー: 一次検索結果を言語モデルで並べ替え、関連性を高めるリランキング機能
• アナライザー（Analyzer）: 全文検索のためのトークン化・正規化処理。言語別アナライザーを指定できる
• 検索ユニット（Search Unit）: 課金とスケールの単位で、レプリカ数とパーティション数の積で決まる
• レプリカ / パーティション: レプリカはクエリ処理能力と可用性、パーティションはインデックス容量とインデックス作成スループットを担う

仕様・制限・クォータ

• SKU（価格レベル）でリソース上限が決まる: Free、Basic、Standard 系（S1/S2/S3 など）、ストレージ最適化系があり、SKU ごとにインデックス数・ストレージ容量・ベクトル容量の上限が異なる
• スケールはレプリカとパーティションで行う: 課金対象の検索ユニット数はレプリカ数とパーティション数の積になる
• SLA を満たすには冗長構成が必要: クエリ用に複数レプリカ、インデックス作成も含めるならレプリカとパーティションをそれぞれ複数にするのが一般的（Free にはサービス SLA がない）
• ベクトル検索には次元数や容量の制約がある: 埋め込みの次元はモデルに依存し、ベクトルデータはストレージとは別枠の容量上限が SKU ごとにある
• インデクサーには実行時間やドキュメントサイズの上限がある: 大量データはバッチ分割やスケジュール実行で対応する
• 作成後に変更しにくい設定がある: 一部のフィールド属性やアナライザーはインデックス作成時に決める設計対象で、変更にはインデックスの作り直しが必要になる場合がある
• 具体的な上限値は SKU と時期で変わるため、最新値は公式ドキュメントで確認すること

内部の仕組み

Azure AI Search は、取り込み（インデックス作成）と検索（クエリ実行）の 2 つの経路を持ちます。取り込み側では、インデクサーがデータソースを巡回し、必要に応じてスキルセットでテキスト分割や埋め込み生成などのエンリッチメントを行ってからインデックスへ書き込みます。検索側では、クエリをアナライザーで処理（全文）またはベクトル化（ベクトル検索）し、転置インデックスと近傍探索の結果を統合して返します。

• 全文検索は 転置インデックス と BM25 系のスコアリングで、キーワード一致に基づく関連度を算出する
• ベクトル検索は埋め込み空間での 近似最近傍（ANN）探索 により、意味的に近い文書を返す
• ハイブリッド検索では両者のスコアを統合し、さらに セマンティックランカー で上位結果を並べ替えて精度を上げられる
• パーティション がインデックスのデータを分割保持し、容量とインデックス作成スループットを担う。レプリカ が各パーティションのコピーを保持し、クエリの並列処理と可用性を担う
• インデクサーは差分追跡（変更検出）に対応し、データソースの更新分だけを取り込める

設計パターン / ベストプラクティス

• RAG の検索層として使う: データを Azure AI Search に取り込み、ユーザー質問でハイブリッド検索 → 上位文書を LLM のプロンプトに根拠として渡す（グラウンディング）
• インデクサー + スキルセットで取り込みを自動化: Blob Storage などのデータ源を起点に、分割・埋め込み生成を組み込んだパイプラインを組む
• チャンク（分割）設計を最適化: 文書を適切なサイズに分割してから埋め込むことで、検索の粒度と回答の根拠精度を両立させる
• フィルターとファセットを併用: ベクトル/全文の関連度に加え、メタデータ（部門・日付など）でのフィルターやファセットで絞り込み体験を作る
• セキュリティトリミング: ユーザーの権限に応じてアクセス可能な文書だけを返すよう、フィルターで結果を絞る設計を検討する
• 再現性のあるインデックス定義: インデックス・インデクサー・スキルセットの定義をコード（JSON など）として管理し、再構築できるようにしておく

運用・監視

• Azure Monitor / 診断設定 でクエリのメトリクスとログを Log Analytics に送り、レイテンシやスロットリングを可視化する
• 監視の要点は クエリのレイテンシ、1 秒あたりのクエリ数、スロットリング（調整）された要求の割合。これらが悪化したらレプリカ追加を検討する
• インデクサーの実行履歴とエラー を確認し、取り込み失敗や警告（ドキュメントのスキップなど）を追跡する
• 容量逼迫やインデックス作成の遅さには パーティション追加、クエリ負荷の増大には レプリカ追加 と、ボトルネックに応じて軸を分けてスケールする
• インデックスのスキーマ変更は影響が大きいため、新インデックスへの再作成とエイリアス切り替え を運用パターンとして用意しておく

コスト

課金は主に SKU（価格レベル） と 検索ユニット数（レプリカ数 × パーティション数） で決まります。サービスは稼働している限り課金され、クエリ件数による従量課金が主体ではない点に注意します。セマンティックランカーや、スキルセットから呼び出す外部 AI（埋め込み生成など）は別途コストが発生し得ます。

セキュリティ

• Microsoft Entra ID + RBAC によるデータプレーン認証に対応し、API キーのハードコードを避けられる（API キー認証も利用可能だが原則は Entra ID を推奨）
• マネージド ID を使って、インデクサーやスキルセットから Blob Storage・Azure OpenAI などへキーレスで接続する
• プライベートエンドポイント / ネットワーク規則 で公開アクセスを制限し、データ源への接続も含めて閉域化できる
• 保存データはサービス側で暗号化され、カスタマーマネージドキー（Key Vault） にも対応する
• 検索結果は フィルターによるセキュリティトリミング で、ユーザーが閲覧してよい文書だけに絞る設計が重要

Well-Architected の観点

• オペレーショナルエクセレンス: インデックス・インデクサー・スキルセットの定義をコード化し、再現可能なデプロイとインデックス再構築（エイリアス切り替え）の運用手順を整える
• 信頼性: SLA を満たすために複数レプリカ（必要に応じてパーティションも複数）を構成し、インデクサー失敗時の再試行とエラー監視を備える
• パフォーマンス: クエリ負荷にはレプリカ、容量とインデックス作成にはパーティションと、ボトルネックに応じて軸を分けてスケールする
• コスト: 常時課金である点を踏まえ、検証リソースの削除と冗長度の適正化でムダを抑える
• セキュリティ: Entra ID 認証・マネージド ID・閉域化・セキュリティトリミングで、認証情報とデータの露出を最小化する

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# リソースグループを作成
az group create --name demo-rg --location japaneast

# Azure AI Search サービスを作成（Basic レベル、レプリカ1・パーティション1）
az search service create \
  --resource-group demo-rg \
  --name demo-search-0614 \
  --location japaneast \
  --sku basic \
  --replica-count 1 \
  --partition-count 1

# クエリ用の API キー（読み取り専用）を発行してフロントから利用する
az search query-key create \
  --resource-group demo-rg \
  --service-name demo-search-0614 \
  --name frontend-query-key

# クエリ負荷に合わせてレプリカを増やし、可用性とスループットを高める
az search service update \
  --resource-group demo-rg \
  --name demo-search-0614 \
  --replica-count 2