注
Azure AI 検索は、Azure ポータル、REST API、およびAzure SDKから使用できます。 また、Foundry IQ は、エンタープライズ コンテンツを、Microsoft Foundry ポータルのエージェントの再利用可能なアクセス許可に対応したナレッジ ベースに変換するマネージド ナレッジ レイヤーです。
ストレージ、ワークロード、インデックスやその他のオブジェクトの数量の上限は、Azure AI 検索 サービスの価格モデルによって異なります。
Azure AI 検索では、2 つの価格モデルがサポートされています。それぞれに関連付けられているサービス レベルがあります。 選択したレベルは、このガイダンスで説明されているサービス制限に影響します。
- 専用: 検索ユニット（SU）に基づく固定料金。 サービス レベルのオプションには、Basic、Standard (S1-S3、S3 HD を含む)、ストレージ最適化 (L1-L2)、および検索サービス機能が制限された Free レベルが含まれます。
- サーバーレス (プレビュー):インデックス付きストレージのコンピューティング ユニット/時間 (CU/時間) および GB/月単位で測定される使用量ベースの価格。 現在のプレビューレベルは、サーバーレス開発者です。 制限は、インデックスごとの上限、サービスごとのオブジェクト数、およびサーバーレス調整の動作によって定義されます。
重要
サーバーレス開発者レベルは現在プレビュー段階です。 このプレビュー版はサービス レベル アグリーメントなしで提供されています。運用環境のワークロードに使用することはお勧めできません。 特定の機能がサポートされていないか、機能が制限されている可能性があります。 詳細については、「 Microsoft Azure プレビューの追加使用条件」を参照してください。
サーバーレス開発者レベルの課金は、2026 年 9 月 13 日に開始されます。 その日以降の使用量の料金は、Azureの請求書に表示されます。 2026 年 9 月 13 日より前の使用には課金されません。 サーバーレス開発者は、課金が開始されると有料レベルです。
サーバーレス開発者レベルでは、他の価格レベルとの間の移行はサポートされていません。また、他のレベルで使用できる一部の機能は、パブリック プレビュー中はサポートされていません。 サービスの制限、サポートされている機能、および価格の詳細は、一般公開前に変更される可能性があります。
プレビュー期間中、サーバーレス価格モデルは 特定のリージョンでのみサポートされます。
詳細については、「 価格モデルとサービス レベルの選択」を参照してください。
クォータ、容量、または制限エラーを診断する
クォータと容量のエラーは、個別の制御から発生します。 完了した操作のエラーを使用して、該当するものを見つけます。
作成、スケール、またはアップグレードの操作がまだ実行されている場合は、プロビジョニング状態が Succeeded または Failedになるまで待ちます。 進行中の操作は、クォータまたは容量の問題の証拠ではありません。 スケール操作が失敗した場合は、「 スケーリング中のエラー」を参照してください。
| Failure | 考えられる原因 | 最初のアクション |
|---|---|---|
| 特定のサブスクリプションとリージョンではサービスの作成がブロックされています | サブスクリプション クォータ | クォータ サービスで、レベルとリージョンの制限を確認し、さらにサービスを要求します。 |
| クォータが使用可能な場合でも、作成、スケーリング、またはアップグレードが失敗する | リージョンの容量の制約 | リージョン のサポート で制約付きレベルの脚注を確認し、 別のリージョンを選択します。 |
| レプリカ、パーティション、層、またはオブジェクトの要求が拒否されました | サービスまたはインデックスの制限 | 構成とオブジェクトの数を 、サービスの制限とインデックスの制限 と比較 します。 |
| 検索サービスは、高負荷時にスロットリング応答を返します | Throttling | 要求率を下げるか、検索単位を追加します。 スロットリングの制限を参照してください。 |
| ストレージまたはベクターの制限に近いインデックス作成に失敗する | ストレージまたはベクター クォータ | ディスクのパーティション ストレージとstorageSizeを比較し、vectorIndexSizeとメモリのベクター インデックス サイズの制限を比較します。 |
| インデクサー、スキル、またはベクターライザーが別のサービスから 429 を報告する | Azure OpenAI またはその他のサービス クォータ | Azure OpenAI など、エラーを発行したサービスのクォータ ガイダンスに従います。 |
利用可能なサブスクリプション クォータでは、リージョンの容量は保証されません。さらにクォータを要求しても容量の制約は解決されません。 エラーが解決しない場合は、サブスクリプション、リージョン、階層、要求された構成、完全なエラー テキスト、UTC 時刻、関連付けまたは操作 ID を含むAzure サポート要求を開きます。
サブスクリプションの制限
各レベルでリージョンあたりに許可されているサービスの最大数まで、複数の "課金対象" 検索サービス (Basic 以上) を作成できます。 たとえば、Basic レベルで最大 16 個のサービスを作成し、同じサブスクリプションとリージョン内の S1 レベルで別の 16 個のサービスを作成できます。 その後、同じサブスクリプションで合計 32 の Basic サービスに対して、別のリージョンに 16 個の Basic サービスを追加作成できます。 サービス レベルの詳細については、「 価格モデルとサービス レベルの選択」を参照してください。
要求によってサービスの上限を引き上げることができます。 同一のサブスクリプション内にさらに多くのサービスが必要な場合は、サポート リクエストを提出してください。
| リソース | 無料 1 | Basic | S1 | S2 | S3 | S3 HD | L1 | L2 | サーバーレス開発者 |
|---|---|---|---|---|---|---|---|---|---|
| リージョンあたりの最大サービス数 | 1 | 16 | 16 | 8 | 6 | 6 | 6 | 6 | 5 |
| 最大検索ユニット (SU) 数2 | N/A | 3 SU | 36 SU | 36 SU | 36 SU | 36 SU | 36 SU | 36 SU | N/A |
1 Azure サブスクリプションあたり 1 つの無料検索サービスを使用できます。 無料レベルは、他の顧客と共有されるインフラストラクチャに基づいています。 ハードウェアは専用ではないため、スケールアップはサポートされておらず、ストレージは 50 MB に制限されています。 より多くのサービスを運用できるようにするために、無料の検索サービスは、長時間非アクティブの場合、削除される可能性があります。
2 検索ユニット (SU) は課金単位であり、"レプリカ" または "パーティション" のいずれかとして割り当てられます。 両方が必要です。 SU の組み合わせの詳細については、「検索サービスの容量を見積もって管理する」を参照してください。
サービスの制限
専用価格モデルでは、レプリカ数にパーティション数（検索ユニット）を掛け合わせて容量を見積もります。
| リソース | Free | Basic | S1 | S2 | S3 | S3 HD | L1 | L2 | サーバーレス開発者 |
|---|---|---|---|---|---|---|---|---|---|
| パーティション数 | N/A | 3 1 | 12 | 12 | 12 | 3 | 12 | 12 | N/A |
| レプリカ数 | N/A | 3 | 12 | 12 | 12 | 12 | 12 | 12 | N/A |
1 Basic レベルでは、2024 年 4 月 3 日以降に作成された 新しい検索サービス で合計 9 つの検索ユニット (SU) に対して、3 つのパーティションと 3 つのレプリカがサポートされます。 以前の Basic サービスは、1 つのパーティションと 3 つのレプリカに制限されています。
検索サービスには、最大ストレージ制限 (パーティション サイズにパーティションの数を掛けたもの) またはインデックスまたはインデクサーの最大数に対するハード制限 (どちらか早い方) が適用されます。
サービス レベル アグリーメント (SLA) は、クエリ ワークロード用のレプリカが 2 つ以上、クエリワークロードとインデックス作成ワークロード用に 3 つ以上のレプリカがある課金対象サービスに適用されます。 SLA では、パーティション数は考慮されません。 詳細については、「Azure AI 検索の信頼性」を参照してください。
無料サービスには固定パーティションやレプリカがなく、リソースを他のサブスクライバーと共有します。
パーティション ストレージ (GB)
サービスごとのストレージ制限は、 サービスの作成日 と リージョンという 2 つの要因によって異なります。 サポートされているほとんどのリージョンでは、 新しいサービスに対してより高い制限が提供されます。
次の表は、時間の経過に伴うストレージ クォータの増加の進行状況を GB 単位で示しています。 2024 年 4 月以降、脚注に記載されているリージョンでは、より高い容量のパーティションがオンラインになっています。 サポートされているリージョンに古いサービスがある場合は、 サービスをアップグレード して、より高いストレージ制限を取得できるかどうかを確認します。
| サービスの作成日 | Basic | S1 | S2 | S3/HD | L1 | L2 | サーバーレス開発者 |
|---|---|---|---|---|---|---|---|
| 2024 年 4 月 3 日より以前 | 2 | 二十五 | 100 | 200 | 1,024 | 2,048 | N/A |
| 2024 年 4 月 3 日から 2024 年 5 月 17 日まで 1 | 15 | 160 | 512 | 1,024 | 1,024 | 2,048 | N/A |
| 2024 年 5 月 17 日より以降 2 | 15 | 160 | 512 | 1,024 | 2,048 | 4,096 | N/A |
| 2025 年 2 月 10 日より以降 3 | 15 | 160 | 512 | 1,024 | 2,048 | 4,096 | N/A |
1 これらのリージョンにおける Basic、S1、S2、S3 向けの大容量ストレージ。 アメリカ: ブラジル南部、カナダ中部、カナダ東部、米国東部、米国東部 2、米国中部、米国中北部、米国中南部、米国西部、米国西部 2、米国西部 3、米国中西部。 ヨーロッパ: フランス中部。 イタリア北部、北ヨーロッパ、ノルウェー東部、ポーランド中部、スイス北部、スウェーデン中部、英国南部、英国西部。 中東: アラブ首長国連邦北部。 アフリカ: 南アフリカ北部。 アジア太平洋: オーストラリア東部、オーストラリア南東部、インド中部、Jio India West、東アジア、東南アジア、東日本、西日本、韓国中部、韓国南部。
2 L1 および L2 用のより高容量のストレージ。 すべての課金対象レベルでより高容量を提供するリージョンが増加しています。 アメリカ大陸： 米国東部 2 EUAP。 ヨーロッパ: ドイツ北部、ドイツ中西部、スイス西部。 Azure Government: テキサス、アリゾナ、バージニア。 アフリカ: 南アフリカ北部。 アジア太平洋: 中国北部 3、中国東部 3。
3 西ヨーロッパでは、より高容量のストレージを使用できます。
重要
現時点では、4 月 3 日より前の制限の対象となる次のリージョンでは、より高いストレージ制限を利用できません。
- イスラエル中部
- カタール中部
- スペイン中部
- インド南部
インデックスの制限
| リソース | Free | 基本 1 | S1 | S2 | S3 | S3 HD | L1 | L2 | サーバーレス開発者 |
|---|---|---|---|---|---|---|---|---|---|
| 最大インデックス | 3 | 5 または 15 | 50 | 200 | 200 | パーティションあたり 1,000、またはサービスあたり 3,000 | 10 | 10 | 30 |
| インデックスあたりの単純型フィールドの最大数 2 | 1000 | 100 | 1000 | 1000 | 1000 | 1000 | 1000 | 1000 | 1000 |
| ベクトル フィールドあたりの最大ディメンション | 4096 | 4096 | 4096 | 4096 | 4096 | 4096 | 4096 | 4096 | 4096 |
| インデックスあたりの複合コレクション フィールドの最大数 | 40 | 40 | 40 | 40 | 40 | 40 | 40 | 40 | 40 |
| ドキュメントあたりの複合コレクション全体での最大要素数 3 | 3000 | 3000 | 3000 | 3000 | 3000 | 3000 | 3000 | 3000 | 3000 |
| 複合フィールドの最大深度 | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| インデックスあたりの最大サジェスター数 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
| インデックスあたりの最大スコアリングプロファイル数 | 100 | 100 | 100 | 100 | 100 | 100 | 100 | 100 | 100 |
| インデックスあたりの最大セマンティック構成数 | 100 | 100 | 100 | 100 | 100 | 100 | 100 | 100 | 100 |
| プロファイルあたりの最大関数 | 8 | 8 | 8 | 8 | 8 | 8 | 8 | 8 | 8 |
| 最大インデックス サイズ 4 | N/A | N/A | N/A | 1.88 TB | 2.34 TB (テラバイト) | 100GB | N/A | N/A | 1 GB |
1 2017 年 12 月より前に作成された Basic サービスは、インデックスでの制限が低くなっています (15 ではなく 5)。 Basic レベルにのみ下限（インデックスあたり 100 フィールド）があります。
2 フィールドの上限には、複合コレクション内の第 1 レベルのフィールドと入れ子になったサブフィールドの両方が含まれます。 たとえば、インデックスに 15 個のフィールドが含まれており、それぞれ 5 つのサブフィールドを持つ 2 つの複合コレクションがある場合、インデックスのフィールド数は 25 になります。 フィールド コレクションが非常に大きい場合、インデックスの処理速度が低下する場合があります。 フィールドと属性を必要なものだけに制限し、インデックス作成とクエリ テストを実行して、パフォーマンスが許容できることを確認します。
3 多数の要素があると、インデックスに必要なストレージは大幅に増えるため、要素には上限があります。 複合コレクションの要素は、そのコレクションのメンバーとして定義されます。 たとえば、Rooms の複合コレクションを含む Hotel ドキュメントを想定します。 Rooms コレクション内の各ルームは要素と見なされます。 インデックス作成時は、インデックス作成エンジンによって、ドキュメント全体で最大 3,000 の要素が安全に処理されます。
この制限は api-version=2019-05-06 で導入され、文字列コレクションや複合フィールドではなく、複合コレクションにのみ適用されます。
4 ほとんどのレベルでは、インデックスの最大サイズは、検索サービスで使用可能なストレージの合計です。 複数のパーティションを持つため、より多くのストレージを備えた S2、S3、S3 HD サービスでは、テーブルに 1 つのインデックスの最大サイズが示されています。 2024 年 4 月 3 日以降に作成された検索サービスに適用されます。 サーバーレス モデル (プレビュー) で設定されたサービスのインデックスには、テーブルに指定された最大サイズが設定されています。
サービスがより強力なクラスターでプロビジョニングされている場合は、上限に多少の違いがあることがあります。 ここでの制限は、共通の分母を表します。 上記の仕様に基づいて構築されたインデックスは、任意のリージョンの同等のサービス レベル間で移植できます。
ドキュメントの制限
各インデックスでは、最大で次の数のドキュメントがサポートされます。
- Basic、S1、S2、S3 で 240 億
- S3 HD で 20 億
- L1 で 2,880 億
- L2 で 5,760 億
各ドキュメントのサイズは最大で約 16 MB です。 ドキュメント サイズの制限は、インデックス作成 API 要求ペイロードのサイズ (16 MB) に実際に適用されます。 そのペイロードには、1 つのドキュメントまたはドキュメントのバッチを指定できます。 バッチ内のドキュメントが 1 つの場合、最大ドキュメント サイズは JSON 形式で 16 MB です。
ドキュメント サイズの制限は、ドキュメントを検索サービスにアップロードする プッシュ モード のインデックス作成に適用されます。 "プル モード" のインデックス作成にインデクサーを使用している場合は、インデクサー制限に従って、ソース ファイルを任意のファイル サイズにできます。 BLOB インデクサーの場合、上位レベルでは、ファイル サイズの制限は大きくなります。 たとえば、S1 の制限は 128 MB、S2 の制限は 256 MB です。
ドキュメントのサイズを見積もる場合は、検索シナリオに値を追加するフィールドにのみインデックスを作成することを忘れないでください。 実行するクエリで目的のないソース フィールドを除外します。
ベクトル インデックス サイズの制限
ベクトル フィールドを使用してドキュメントにインデックスを作成する場合、指定したアルゴリズム パラメーターを使い、Azure AI 検索 によって内部ベクトル インデックスが構築されます。
これらのベクター インデックスのサイズは、次の方法で制限されます。
- 専用プランにおいて、ご利用のサービスのレベル (または
SKU) 向けにベクトル検索用に確保されたメモリ容量。 - サーバーレス価格モデルでのインデックスごとのストレージ制限。
ベクトル ストレージの管理と最大化に関するガイダンスについては、「ベクトル インデックスのサイズと制限以下の維持」を参照してください。
ベクトルの制限は以下によって異なります。
2024 年 4 月以降、追加のキャパシティが提供されるリージョン (大半のリージョン) の新しい検索サービスでは、より高いベクトル制限が存在します。 サポートされているリージョンに古いサービスがある場合は、 サービスを より高いベクター制限にアップグレードできるかどうかを確認します。
サーバーレス価格モデルでは、ベクトルの制限はパーティションごとではなくインデックスごとに定義されます。
-
インデックスあたりの最大ベクター インデックス サイズ (サーバーレス): 300 MB
- このサイズは、専用サービス レベルで使用されるベクターとストレージの比率と一致する、 インデックス ストレージの合計の約 30% を表します。
- このサイズは、インデックスあたりのハード制限です。 インデックス作成中にこの制限を超えようとすると失敗します。
次の表は、時間の経過と共に増加するベクトル クォータの進行を GB で示しています。 クォータはパーティションごとであるため、新しい Standard (S1) サービスを 6 つのパーティションにスケーリングする場合、ベクトル クォータの合計は 35 に 6 を乗算します。
| サービスの作成日 | Basic | S1 | S2 | S3/HD | L1 | L2 |
|---|---|---|---|---|---|---|
| 2023 年 7 月 1 日より前1 | 0.5 | 1 | 6 | 12 | 12 | 36 |
| 2023 年 7 月 1 日から 2024 年 4 月 3 日まで2 | 1 | 3 | 12 | 36 | 12 | 36 |
| 2024 年 4 月 3 日から 2024 年 5 月 17 日まで3 | 5 | 35 | 150 | 300 | 12 | 36 |
| 2024 年 5 月 17 日以降4 | 5 | 35 | 150 | 300 | 150 | 300 |
1 初期プレビュー中の初期ベクトル制限。
2 後期プレビュー期間中の 2 つのベクトル制限。 ドイツ中西部、インド西部、カタール中部の 3 つのリージョンには、より高い制限はありませんでした。
3 サポートされているレベルとリージョンにおけるより大きなパーティションに基づいた、より高いベクトル クォータ。
4 パーティション サイズの更新に基づいた、より多くのレベルとリージョンにおけるより高いベクトル クォータ。
このサービスでは、ベクトル インデックス サイズ クォータが適用されます。
- 専用: 検索サービス内の各パーティションごと
- サーバーレス： インデックスごと
このクォータは、サービスが正常な状態を保つためのハード制限です。 制限を超えると、インデックスの作成がさらに試行され、エラーが発生します。 使用可能なクォータを解放したら、次の方法でインデックス作成を再開できます。
- ベクター ドキュメントの削除
- ベクター サイズまたは次元の縮小
- (専用のみ)パーティションのスケールアウト
重要
ベクターの制限が大きいほど、 大きなパーティション サイズに関連付けられます。 現時点では、7 月から 4 月の制限の対象となる次のリージョンでは、より高いベクター制限を使用できません。
- イスラエル中部
- カタール中部
- スペイン中部
- インド南部
インデクサー制限
サービスに全体としてのバランスと安定性を提供するために、最大実行時間が設けられていますが、より大規模なデータ セットでは、許可されている最大値よりも長いインデックス作成時間が必要になることがあります。 インデックス作成ジョブを最大許容時間内を完了できない場合は、スケジュールで実行してみてください。 スケジューラはインデックスの状態を追跡します。 スケジュールされたインデックス作成ジョブが何らかの理由で中断された場合、インデクサーは、次のスケジュールされた実行時に最後の終了状態を選択できます。
注
サーバーレス価格モデルでは、インデクサーの動作は専用サービスとは異なります。 容量はレプリカまたはパーティションによって定義されていません。 代わりに、サービスごとのオブジェクトの制限、インデックスごとのストレージの上限、サービス レベルの調整によってインデックス作成の制限が制御されます。 サーバーレス開発者インデクサーの実行あたりの最大実行時間は 2 時間です。
インデクサー オブジェクトとスループットの制限
| リソース | 無料 1 | 基本 2 | S1 | S2 | S3 | S3 HD 3 | L1 | L2 | サーバーレス開発者 |
|---|---|---|---|---|---|---|---|---|---|
| 最大インデクサー | 3 | 5 または 15 | 50 | 200 | 200 | N/A | 10 | 10 | 30 |
| 最大データソース | 3 | 5 または 15 | 50 | 200 | 200 | N/A | 10 | 10 | 1サービスあたり30 |
| 最大スキルセット 4 | 3 | 5 または 15 | 50 | 200 | 200 | N/A | 10 | 10 | 30 |
| 呼び出しあたりの最大インデックス作成負荷 | 10,000 ドキュメント | 制限されるのは最大ドキュメント数のみです | 制限されるのは最大ドキュメント数のみです | 制限されるのは最大ドキュメント数のみです | 制限されるのは最大ドキュメント数のみです | N/A | 制限なし | 制限なし | 制限されるのは最大ドキュメント数のみです |
| 最小限のスケジュール | 5 分 | 5 分 | 5 分 | 5 分 | 5 分 | 5 分 | 5 分 | 5 分 | 5 分 |
| インデクサー実行あたりの最大実行時間 5 | 1~ 3 または 3 - 10 分 | 2 または 24 時間 | 2 または 24 時間 | 2 または 24 時間 | 2 または 24 時間 | 2 時間 | 2 または 24 時間 | 2 または 24 時間 | 2 時間 |
| サービスあたりの累積インデクサー ランタイム 6 | N/A | N/A | N/A | N/A | N/A | 24 時間 | N/A | N/A | 24 時間 |
1 Free サービスのインデクサーの最大実行時間は、BLOB ソースの場合は 3 分、その他のすべてのデータ ソースの場合は 1 分です。 インデクサー呼び出しは 180 秒に 1 回です。 Foundry Tools を呼び出す AI インデックス作成の場合、無料サービスはインデクサーあたり 1 日あたり 20 個の無料トランザクションに制限されます。この場合、トランザクションはエンリッチメント パイプラインを正常に通過するドキュメントとして定義されます。 (ヒント: インデクサーをリセットしてカウントをリセットできます)。
2 2017 年 12 月より前に作成された Basic サービスは、インデクサー、データ ソース、およびスキルセットでの制限が低くなっています (15 ではなく 5)。
3 S3 HD インデクサーのサポートはプレビュー段階であり、 2025-11-01-preview REST API バージョン以降が必要です。 S3 HD インデクサーは マルチテナント実行環境 でのみ実行され、 共有プライベート リンク リソースはサポートされません。 プレビュー期間中、S3 HD インデクサーのサポートは、スキルセットがない、または最小限の小規模なワークロード (約 1 GB のインデックス サイズ) に最適です。 集計動作、監視、および計画のガイダンスについては、 サーバーレスおよび S3 HD でのインデクサーの実行に関する記事を参照してください。
4 スキルセットあたり最大 30 スキル。
5 インデクサーの最大期間の 2 時間または 24 時間について: 最長 2 時間が最も一般的であり、それに合わせて計画することをお勧めします。 これは 、パブリック環境で実行されるインデクサーを指します。このインデクサーは、計算負荷の高い処理をオフロードし、クエリのためにより多くのリソースを残します。 24 時間の制限は、検索サービスに割り当てられているインフラストラクチャのみを使用してプライベート環境で実行するようにインデクサーを構成する場合に適用されます。 一部の古いインデクサーはパブリック環境で実行できず、これらのインデクサーには常に 24 時間の処理範囲があります。 スケジュールされていないインデクサーが 24 時間継続的に実行されている場合、それらのインデクサーは、新しいインフラストラクチャに移行できなかったと見なせます。 一般に、2 時間以内に終了できないジョブのインデックス作成では、インデクサーを 5 分間のスケジュール に従って、インデクサーが中断した場所をすばやく取得できるようにします。 Free レベルでは、3-10 分という最大実行時間はスキルセットを持つインデクサーに対するものです。
6 S3 HD およびサーバーレス サービスでは、すべてのインデクサーは、各 24 時間 UTC ウィンドウでサービスごとに 24 時間の累積ランタイムを共有します。 クォータの動作、監視、および計画のガイダンスについては、 サーバーレスおよび S3 HD でのインデクサーの実行に関する記事を参照してください。
BLOB に似たインデクサーのソース ファイルの制限
ファイル処理は段階的に行われ、各ステージには独自の制限があります。
- データ ソース コネクタは、ソース固有のコネクタの制限に従ってソース項目をダウンロードします。
- Azure AI 検索、次の表の最大ソース ファイル サイズと抽出文字の制限に従って、アイテムのコンテンツを抽出します。
- 必要に応じて、スキルセットはそのコンテンツをダウンストリーム サービスに送信します。個々のスキルの入力制限は、インデクサーが抽出する内容よりも小さくすることができます。
次の表の最大ソース ファイル サイズと抽出文字の制限は、Azure Blob Storage、ADLS Gen2、Microsoft 365、OneLake、および Azure Files インデクサーのSharePointに適用されます。 スキルごとの制限については、スキルセット内の 各スキルのリファレンス記事 を確認してください。
| リソース | Free | Basic | S1 | S2 | S3 | S3 HD | L1 | L2 | サーバーレス開発者 |
|---|---|---|---|---|---|---|---|---|---|
| 最大ソース ファイル サイズ、MB 24 | 16 | 16 | 128 | 256 | 256 | N/A | 256 | 256 | 256 |
| ソース ファイルから抽出された最大文字数 134 | 256,000 | 51万2000 | 4 mil | 8 mil | 16 mil | N/A | 4 mil | 4 mil | 16 mil |
1 最大文字数は Unicode コード単位 (特に UTF-16) に基づいています。
2 CSV ファイル delimitedText 解析モードを使用する場合、ファイル行あたり 10 MB のバッファー サイズ制限が適用されます。
3 CSV ファイルに delimitedText 解析モードを使用する場合、"抽出された最大コンテンツ サイズ" の制限は適用されません。
4 つの BLOB に似たインデクサーには、Azure Blob Storage インデクサー (BLOB インデクサー)、ADLS Gen2 インデクサー、Microsoft 365 インデクサーのSharePoint、OneLake インデクサー、Azure Files インデクサーが含まれます。 ファイルの直接アップロード ナレッジ ソースではインデクサーが使用されないため、 個別の制限があります。
共有プライベート リンク リソースの制限
インデクサーでは、共有プライベート リンク リソース API を使用して管理されているプライベート エンドポイント経由で他の Azure リソースにアクセスできます。 このセクションでは、この機能に関連する制限について説明します。
注
サーバーレス価格モデル開発者レベルでは、データ ソースへの共有プライベート リンクまたはネットワーク セキュリティ境界 (NSP) はサポートされていません。 サーバーレス開発者層サービスへのプライベート接続のプライベート エンドポイントと IP ファイアウォール規則がサポートされています。
| リソース | Free | Basic | S1 | S2 | S3 | S3 HD | L1 | L2 | サーバーレス開発者 |
|---|---|---|---|---|---|---|---|---|---|
| プライベート エンドポイント インデクサーのサポート | なし | はい | はい | はい | はい | なし | はい | はい | なし |
| スキルセット 1 を使用したインデクサーのプライベート エンドポイントのサポート | なし | なし | はい | はい | はい | なし | はい | はい | なし |
| 埋め込みスキルがあるスキルセットのプライベート エンドポイントのサポート 2 | なし | はい | はい | はい | はい | なし | はい | はい | なし |
| 最大プライベート エンドポイント | N/A | 10 または 30 | 100 | 400 | 400 | N/A | 20 | 20 | N/A |
| 個別のリソースの最大種類 3 | N/A | 4 | 7 | 15 | 15 | N/A | 4 | 4 | N/A |
1 AI エンリッチメントと画像分析は、コンピューティングを集中的に使用し、使用可能な処理能力を大量に消費します。 このため、検索サービス自体のパフォーマンスと安定性を確保するために、下位レベルではプライベート接続が無効になっています。 Basic サービスでは、サービスの安定性を維持するために、Microsoft Foundry リソースへのプライベート接続はサポートされていません。 S1 レベルの場合は、2024 年 4 月 3 日以降に 、より高い制限 でサービスが作成されたことを確認します。 Azure OpenAI Embedding または Azure Vision マルチモーダル 埋め込みスキルが 2 つを超えるインデクサーは、プライベート環境での実行が制限され、プライベート接続は使用できません。
2 2024 年 4 月 3 日以降に作成された Basic および S1 の大容量検索サービスでは、埋め込みモデルへのプライベート接続がサポートされ、ストレージと計算処理の 上限が高くなります 。
3個別のリソースの種類の数は、リソースの状態に関係なく、特定の検索サービスのすべての共有プライベート リンク リソースで使用される一意の groupId 値の数として計算されます。
シノニムの制限
シノニム マップの最大数は、レベルによって異なります。 各規則には最大 20 の拡張を含めることができます。ここで、拡張は同義語です。 たとえば、"cat" を指定すると、"キティ"、"ネコ"、"フェリス" (猫の属) との関連付けは、3 つの拡張としてカウントされます。
| リソース | Free | Basic | S1 | S2 | S3 | S3 HD | L1 | L2 | サーバーレス開発者 |
|---|---|---|---|---|---|---|---|---|---|
| シノニムマップの最大数 | 3 | 3 | 5 | 10 | 20 | 20 | 10 | 10 | 1サービスあたり20 |
| マップごとの規則の最大数 | 5,000 | 20000 | 20000 | 20000 | 20000 | 20000 | 20000 | 20000 | 20000 |
インデックスの別名の上限
インデックス エイリアスの最大数は、レベルとサービスの作成日によって異なります。 すべてのレベルで、2022 年 10 月以降にサービスが作成された場合、エイリアスの最大数は許可されるインデックスの最大数の 2 倍になります。 2022 年 10 月より前に作成されたサービスの場合、制限は許可されるインデックスの数です。
注
サーバーレス モデルの開発者層では、インデックスエイリアスはサポートされていません。
| サービスの作成日 | Free | Basic | S1 | S2 | S3 | S3 HD | L1 | L2 | サーバーレス開発者 |
|---|---|---|---|---|---|---|---|---|---|
| 2022 年 10 月より前 | 3 | 5 または 15 1 | 50 | 200 | 200 | パーティションあたり 1,000、またはサービスあたり 3,000 | 10 | 10 | N/A |
| 2022 年 10 月以降 | 6 | 30 | 100 | 400 | 400 | パーティションあたり 2,000、またはサービスあたり 6,000 | 20 | 20 | N/A |
1 2017 年 12 月より前に作成された Basic サービスは、インデックスでの制限が低くなっています (15 ではなく 5)。
エージェント取得の制限
ナレッジ ベースでは、エージェント検索用の大規模言語モデル (LLM) 処理のレベルを制御する 1 つ以上のナレッジ ソースと取得の推論作業を指定します。 制限は、価格レベル、API バージョン、推論作業レベルによって異なります。
| リソース | Free | Basic | S1 | S2 | S3 | S3 HD | L1 | L2 | サーバーレス開発者 |
|---|---|---|---|---|---|---|---|---|---|
| サービスあたりのナレッジ ソースの最大数 | 3 | 5 または 15 1 | 50 | 200 | 200 | 0 | 10 | 10 | 30 |
| サービスあたりのナレッジ ベースの最大数 | 3 | 5 または 15 1 | 50 | 200 | 200 | 0 | 10 | 10 | 30 |
| ナレッジベースあたりのナレッジソースの最大数 | 3 | 5 または 10 1 | 10 | 10 | 10 | 0 | 10 | 10 | 10 |
1 2024 年 4 月 3 日より前に作成された基本サービスには、ナレッジ ソースとナレッジ ベースの下限 (5) があります。
検索時のナレッジソースの選択
ナレッジ ベースには、API のバージョンや取得の理由に関係なく、上記のレベル固有の最大値まで含めることができます。 代わりに、API のバージョンと推論作業は、取得中に選択できるナレッジ ソースの数に影響します。
| API バージョン | 検索推論作業 | Free | Basic | S1 | S2 | S3 | S3 HD | L1 | L2 |
|---|---|---|---|---|---|---|---|---|---|
2026-05-01-preview 以降 |
minimal、low、medium |
3 | 5 または 10 1 | 10 | 10 | 10 | 0 | 10 | 10 |
2026-04-01、2025-11-01-preview |
minimal
2 |
3 | 5 または 10 1 | 10 | 10 | 10 | 0 | 10 | 10 |
2025-11-01-preview |
low |
3 | 3 | 3 | 3 | 3 | 0 | 3 | 3 |
2025-11-01-preview |
medium |
3 | 5 | 5 | 5 | 5 | 0 | 5 | 5 |
2025-08-01-previewはレガシ ナレッジ エージェント コントラクトを使用し、retrievalReasoningEffortをサポートしていません。
2minimal 推論作業では、LLM ベースのクエリ計画をバイパスするため、ナレッジ ベース内のすべてのナレッジ ソースが使用されます。
要求ランタイムを取得する
maxRuntimeInSeconds制限は、サポートされているレベル間で同じです。
| 最小値 | Default | 最大値 |
|---|---|---|
| 10 秒 | 90 秒 | 600 秒 (10 分) |
最大値は、Azure AI 検索取得要求にのみ適用されます。 構成例については、「既定の 推論作業をオーバーライドし、要求の制限を設定する」を参照してください。
データの制限 (AI エンリッチメント)
データ制限は、Foundry Tools で Azure Language を呼び出す AI エンリッチメント パイプラインに適用されます。
エンティティ認識スキル、Entity Linking スキル、キー フレーズ抽出スキル、言語検出スキル、および PII 検出スキル の最大入力は、String.Lengthで測定した場合、50,000 文字です。
センチメント スキルの最大文字数は 5,000 文字です。
ダウンストリーム処理の前に大きなテキストを分割する必要がある場合は、テキスト分割 スキル を使用します。
これらの制限は、専用価格モデルとサーバーレス価格モデルの両方に適用されます。
スロットルの制限
スロットリング制限は、API リクエストの頻度を制御することで、サービスの安定性を確保するのに役立ちます。
専用価格モデルでは、調整は検索単位 (レプリカ数 × パーティション数) に基づいて行われます。
サーバーレス料金モデルでは、スロットリングは検索ユニットに基づいていません。 代わりに、サービス レベルの操作の制限と全体的な消費動作によってスループットが制御されます。 使用量とサービスの制限は、レプリカとパーティションの構成ではなく、容量を管理します。
| Operation | 専用 (検索単位ごと) | サーバーレス (サービスごとまたはインデックスごと) |
|---|---|---|
| インデックスの一覧表示 (GET /indexes) | 3 要求/秒/SU | 3 リクエスト/秒 |
| インデックスの取得 (GET /indexes/{index}) | 10 リクエスト/秒/SU | 10 リクエスト/秒 |
| インデックスの作成 (POST /indexes) | 12 リクエスト/分/SU | 1分あたり12リクエスト |
| インデックスの作成または更新 (PUT /indexes/{index}) | 6 リクエスト/秒/SU | 6 リクエスト/秒 |
| インデックスの削除 (DELETE /indexes/{index}) | 12 リクエスト/分/SU | 1分あたり12リクエスト |
| サービス統計 (GET /servicestats) | 4 リクエスト/秒/SU | 4 リクエスト/秒 |
| 検索クエリ (POST /indexes/{index}/docs/search) | SU の数とクエリの複雑さによって異なります | 50 クエリ/秒 (インデックスごとの読み取りスロットルの集計) |
| ドキュメントのインデックス作成 (POST /indexes/{index}/docs/index) | SU の数とインデックス作成のワークロードによって異なります | インデックスあたり 5 要求/秒 |
| 候補の提示 (POST /indexes/{index}/docs/suggest) | SU カウントによって異なります | 明示的に定義されていない |
| オートコンプリート (POST /indexes/{index}/docs/autocomplete) | SU カウントによって異なります | 明示的に定義されていない |
セマンティック ランカーのスロットリング制限
セマンティック ランカーは、キュー システムを使って同時要求を管理します。 このシステムを使用すると、検索サービスは 1 秒あたりに可能な限り最高のクエリ数を取得できます。 同時要求の制限に達すると、システムはキューに追加の要求を配置します。 キューがいっぱいの場合、システムはそれ以降の要求を拒否し、再試行する必要があります。
1 秒あたりのセマンティック ランカー クエリの合計数は、次の要因によって異なります。
- 検索サービスのレベル。 キューの容量と同時要求の制限はどちらもレベルによって異なります。
- 検索サービス内の検索ユニットの数。 セマンティック ランカーの同時クエリの最大数を増やす最も簡単な方法は、検索サービスに検索ユニットをさらに追加することです。
- リージョンでのセマンティック ランカーの合計使用可能容量。
- セマンティック ランカーを使ってクエリを処理するのにかかる時間。 この時間は、検索サービスの混雑状況によって異なります。
次の表では、リージョンで使用可能な容量に応じて、レベルごとのセマンティック ランカー調整の制限について説明します。 制限の引き上げを要求するには、Microsoft サポートにお問い合わせください。
| リソース | Basic | S1 | S2 | S3 | S3 HD | L1 | L2 | サーバーレス開発者 |
|---|---|---|---|---|---|---|---|---|
| 同時要求の最大数 (検索単位ごと) | 2 | 3 | 4 | 4 | 4 | 4 | 4 | 4（サービスごと） |
| 要求キューの最大サイズ (検索ユニットごと) | 4 | 6 | 8 | 8 | 8 | 8 | 8 | 8（サービスごとに） |
API 要求の制限
無制限のクエリは検索サービスを不安定にする可能性があるため、クエリの制限が存在します。 通常、このようなクエリはプログラムによって生成されます。 アプリケーションでプログラムによって検索クエリが生成される場合は、無制限のサイズのクエリが生成されないように設計します。
ペイロードの制限も同様の理由で存在するため、検索サービスの安定性が確保されます。 この制限は、要求全体 (すべてのコンポーネントを含む) に適用されます。 たとえば、要求が複数のドキュメントまたはコマンドをバッチ処理する場合、要求全体がサポートされる制限内に収まる必要があります。
サポートされている制限を超える必要がある場合は、 ワークロードをテストして 、想定される内容を把握します。
特記された場合を除き、次の API 要求は、Azure SDK を含むすべてのプログラミング可能なインターフェイスに適用されます。
全般:
- サポートされている最大ペイロード制限は、REST API と SDK を使用したインデックス作成とクエリ要求に対して 16 MB です。
- 最大 8 KB の URL 長 (REST API のみに適用)。
インデックス作成 API:
- サポートされているインデックスののアップロード、マージ、または削除のバッチあたりの最大ドキュメント数: 1,000。
- 各要求では、1 から 32,000 のインデックス作成アクションがサポートされます。
クエリ API:
- ベクター クエリ内の最大 10 個のフィールド
- $orderby 句の最大フィールド数: 32。
- 検索句の最大文字数: 100,000 文字。
- 検索内の句の最大数は 3,000 です。
- Lucene によって適用される、ワイルドカード と 正規表現 クエリの上限。 パターン、バリエーション、または一致するインスタンスの数が 1,000 個に制限されます。 この制限は、エンジンの過負荷を回避するために設定されています。
検索語句:
- サポートされている検索用語の最大サイズ: UTF-8 でエンコードされたテキストの 32,766 バイト (32 KB - 2 バイト)。 キーワード検索とベクトル検索の text プロパティに適用されます。
- サポートされているプレフィックス検索および正規表現検索での検索用語の最大サイズ: 1,000 文字。
API 応答の制限
- 検索結果の各ページは、最大 1,000 個のドキュメントを返します。
- 各 Suggest API 要求は、最大 100 個の提案を返します。
検索エンジンは既定で 50 件の結果を返しますが、このパラメーターを最大制限にオーバーライドできます。
API キーの制限
サービス認証には API キーを使用します。 2 種類の API キーが存在します。 要求ヘッダーで指定した管理者キーは、サービスへの完全な読み取り/書き込みアクセスを提供します。 URL で指定したクエリ キーは読み取り専用であり、通常はクライアント アプリケーションに配布されます。
- 各サービスは、最大 2 つの管理キーをサポートします。
- 各サービスは、最大 50 個のクエリ キーをサポートします。