はじめに

三菱UFJフィナンシャル・グループ（以下MUFG）の戦略子会社であるJapan Digital Design（以下JDD）で、Tech PM（Technical Project Manager）をしている吉竹です。

JDDではRAG（Retrieval-Augmented Generation）やエージェントなど、LLMを活用したアプリケーションの開発および検討に取り組んでいます。最近も、あるRAGシステムを開発し本番運用を開始しました。
このRAGシステムでは、Azure AI Search を検索エンジンとして利用しています。AI Search については、JDDのDS（データサイエンティスト）メンバーが過去に記事を投稿しており、JDD内でも広く利用されています。

上記の記事ではDS目線で検索機能について解説がされています。
一方、この記事ではAI Searchを使ったシステムを設計、構築、運用する中で得られた知見をエンジニア目線で紹介します。
具体的には、以下の非機能観点についてAI Searchを利用する上で考慮するポイントを前後編に分けてご紹介します。

• 前編（本記事）

  • 性能

  • 信頼性

  • コスト

• 後編

  • 監視

  • セキュリティ

  • 移行・バックアップ

基礎知識

まず、AI Searchに関する基本的な概念を紹介します。これらは、性能、信頼性、コストを検討するためには欠かせない知識です。

サーチユニット (SU)

• AI Searchに割り当てる計算リソースの基本単位です。SUは利用者側で割当量を調整できます。SUが多ければ多いほど、処理能力とコストが増加します。

• SUは、読み取り処理を担う「レプリカ」数と、書き込み（インデックス作成・更新）処理を担う「パーティション」数の積により決定されます。例えば、レプリカ数が3、パーティション数が2の場合、SUは 3 × 2 = 6 となります。

• 検索（読み取り）が多いシステムではレプリカ数を増やし、データの更新や追加（書き込み）が多いシステムではパーティション数を増やす、といったシステムの特性に合わせた調整が可能です。

• また、レプリカ数とパーティション数は後から変更可能です。初期段階で厳密なサイジングが難しくても、性能テストの結果に基づいて調整できます。

価格レベル (SKU）

• AI Searchの価格レベルのことです。大きく分けると4種類（Free, Basic, Standard, Storage Optimized）、細分化すると7種類のSKUが存在します。

• 価格レベルにより、割り当てられるSUの上限値やSUあたりのコスト、ストレージサイズが変わります。例えばBasicの価格帯では、SUの上限値は9となります。

• 従来は一度AI Searchのインスタンスを構築すると、価格レベルは変更できませんでしたが、2025/4のアップデートにより制約はありつつも変更がサポートされるようになりました。（参考：公式ドキュメント）

• サービスレベルごとの上限値の詳細は、価格に関する公式サイト、または公式ドキュメントをご確認ください。

スロットル制限

• AI Searchが提供するAPIの種類に応じて、同時リクエスト数のスロットル制限が設けられています。

• 最も利用頻度が高いクエリAPI（検索など）は、システムの負荷状況やリクエスト内容により動的に制限が行われます。一方、インデックスを操作するAPIの多くは静的な上限値が存在します。例としては、以下のような制限があります。

  • インデックスの作成または更新：6件/秒

  • インデックスの削除：12件/秒

• 上記の通り、特にインデックスへの操作について同時リクエスト数の要件が存在する場合、スロットル制限の範囲内か精査する必要があります。その他の制限値は、公式ドキュメントを参照ください。

• 制限はSU単位なので、割り当てるSUを増やせば上限値も上がります。

セマンティックランカー利用時の注意

• セマンティックランカーを利用する場合、AI Searchはキューシステムを使って同時リクエストを管理します。キューシステムを使った場合の性能を考えるには、以下2つの仕様を把握する必要があります。これらはサービスレベルごとに容量が決まっています。

  • 最大同時リクエスト数 (Maximum Concurrent Requests)

  • 最大リクエストキューサイズ (Maximum Request Queue Size)

• 「最大同時リクエスト数」を超えた分のリクエストは、キューに格納されます。処理が終わり次第、リクエストはデキューされ処理されます。キューサイズを超えたリクエストはエラーとなるため、アプリケーション側でのリトライ等の考慮が必要となります。

• 例として、サービスレベルがS1（Standard S1）でSUが2の場合、上記の表と照らし合わせるとそれぞれ以下の数字となります。

  • 最大同時リクエスト数：3 × 2 SU = 6

  • 最大リクエストキューサイズ：6 × 2 SU = 12

  • この場合、7件目以降のリクエストはエンキューされ、19件目以降はキューにも入らずエラーとなる挙動になることが想定されます。

• あくまで理論上であり、実際は検索クエリやデータ特性、負荷状況にも依存します。期待する性能が出るかどうかは、利用者側で性能テストを行い検証する必要があります。

• また、キューでの待機時間が加わることで、エンドユーザーが体感するレスポンスタイムが長くなる可能性があります。

前置きが長くなりましたが、これらの概念を踏まえて、性能、信頼性、コストについて考慮点を紹介します。

性能

詳細は「基礎知識」に記載していますので、ここでは要点のみを記載します。
性能を検討する上での要点をまとめると以下の通りです。

信頼性

信頼性を考慮するうえでいくつかの概念を補足します。なお、信頼性の詳細については、以下の公式ドキュメントを確認することをおすすめします。

AI Search の 可用性

• AI Search では、レプリカ数に応じてSLAが決定されます。

• 以下表の通り、書込みまで含めて99.9%のSLAを求める場合には、3つ以上のレプリカが必要となります。書込みのSLAも、パーティションではなくレプリカ数で決まるため誤解しないよう注意ください。

• なお、価格レベルがFreeの場合にも、SLAは提供されません。

一般的なRAGシステムで言えば、AI Search は読取り（クエリ）のユースケースがメインであり、本番システムではレプリカ2つ以上が望ましいと言えます。
一方、書込みに高いSLAを要求するかは慎重に検討すべきと思われます。実際に、私達が構築したRAGシステムでも、検索インデックスへの書込み処理が行われる頻度は少なく、書込みについては障害時に影響のあるユーザーが少ないという特性はありました。
もちろん、3つ以上のレプリカが要件上必要であれば良いですが、SLAという数字にこだわり必要以上のレプリカ数を用意するのは、不要なコストを生むだけです。
また、障害が起きることを前提にシステムを設計すること（Design for Failure）が、高い信頼性に繋がると筆者は考えています。例えば、エラー時のリトライ処理やユーザーフレンドリーなメッセージ等の表示、更新処理については冪等性を担保する、といった工夫です。

可用性ゾーン（Availability Zones）

• 2つ以上のレプリカを利用する場合、それぞれのレプリカは同一リージョン内の別データセンターまたはゾーンに配置されます。レプリカの数が多い場合はできるだけ均等に配置されます。

• 可用性ゾーンが適用されるには、価格レベルはStandard以上である必要があります。但し、可用性ゾーンによりSLAには変化はありません。

• 本記事執筆時点（2025/4）で西日本リージョンではサポートされていません。

「基礎知識」と合わせて要点をまとめると以下の通りです。

コスト

AI Searchのコストは、先ほど説明した価格レベル及びSUと、一部の従量課金要素により決定されます。詳細は公式サイトも参照ください。

• 価格レベル

  • レベルごとにSUの単価が異なります。例えば、Basicの場合1SUあたり $97.09/月ですが、S1では$324.12/月です。

• SU

  • コストは、SU単価 × ユニット数で計算されます。

  • 先述の通り、SUは積で表されるので、パーティション数を1増やしたら、既に存在するレプリカの数だけSUは増加します。

• 従量課金要素

  • カスタムエンティの利用、画像を含むドキュメントからの画像抽出、セマンティックランカーの利用時に、従量課金が発生します。

コストの見積もりに関しては、Azure公式から提供されている料金計算ツールが活用できます。実際のところ、価格レベルが決まればあとはSUをどれだけ追加するかが主要なコスト要因ですので、比較的AI Searchのコストは見積もりやすいかと思います。

なお、SUの追加などシステムのキャパシティをいつ変更すべきかは、公式からドキュメントも出ていますので、こちらも参考にしてください。

「基礎知識」と合わせて要点をまとめると以下の通りです。

まとめ

本記事では、AI Search の基礎知識をもとに、性能、信頼性、コストの観点での検討ポイントをご紹介しました。つまるところ、性能、信頼性はコストとのトレードオフになるので、プロジェクトの非機能要件と予算に見合った設計を行うことが重要です。

後編では、監視、セキュリティ、移行・バックアップについて紹介する予定なので、興味がある方はそちらもお待ちいただければと思います。
本記事がどなたかのお役に立てば幸いです。

Japan Digital Design株式会社では、一緒に働いてくださる仲間を募集中です。カジュアル面談も実施しておりますので下記リンク先からお気軽にお問合せください。

この記事に関するお問い合わせはこちら

Japan Digital Design 株式会社
Technology & Development Div
Naoki Yoshitake