Azure AI 検索では、検索サービスへの接続に対して、ID ベースの認証とキーベースの認証 (既定) の両方がサポートされます。
検索サービス エンドポイントに対して行われた要求は、要求と API キーの両方が有効であり、検索サービスが要求で API キーを許可するように構成されている場合に受け入れられます。
重要
検索サービスを作成する際には、キーベース認証が既定値となりますが、これが最も安全な選択肢というわけではありません。 これをロールベースのアクセスに置き換えることをお勧めします。
[前提条件]
キーを表示または管理するには、所有者、共同作成者、または Search Service 共同作成者 である必要があります。
既定で有効
Azure ポータルでは、認証は Settings>Keys ページで指定されます。
API キー (既定) または両方に設定されたオプションは、要求で API キーを許可します。
キーの種類
API キーは、ランダムに生成された 52 個の数字と文字から成る一意の文字列です。 管理者キーとクエリ キーに見た目の違いはありません。 アプリケーションで指定されているキーの種類を把握できない場合は、Azure ポータルでキー値を確認。
要求の認証には、次の 2 種類のキーが使用されます。
| タイプ |
アクセス許可レベル |
作成方法 |
最大値 |
| 管理者 |
すべてのデータ プレーン (コンテンツ) 操作に対するフル アクセス (読み取り/書き込み) |
プライマリとセカンダリの 2 つの管理キーは、サービスの作成時に生成され、必要に応じて個別に再生成できます。 2 つを使用すると、サービスへの継続的なアクセスに 2 番目のキーを使用しながら、1 つのキーをロールオーバーできます。 |
2 |
| クエリ |
検索インデックスのドキュメント コレクションを対象とした読み取り専用アクセス |
サービスで 1 つのクエリ キーが生成されます。 検索サービス管理者は、さらに必要に応じて作成できます。 |
50 |
既存のキーを見つける
API キーは、Azure ポータル、PowerShell、Azure CLI、または REST API を使用して表示および管理できます。
次のコマンドを実行して、それぞれ管理者キーとクエリ API キーを返します。 REST のヘルプについては、「 REST API を使用してAzure AI 検索 サービスを管理するを参照してください。
管理者キーを返します。
POST https://management.azure.com/subscriptions/{{subscriptionId}}/resourceGroups/{{resource-group}}/providers//Microsoft.Search/searchServices/{{search-service-name}}/listAdminKeys?api-version=2025-05-01
クエリ キーを返します。
POST https://management.azure.com/subscriptions/{{subscriptionId}}/resourceGroups/{{resource-group}}/providers//Microsoft.Search/searchServices/{{search-service-name}}/listAdminKeys?api-version=2025-05-01
リファレンス:管理キー - 取得、 クエリ キー - Search サービス別リスト
PYTHONのAzure SDKを使用して、API キーをプログラムで取得します。 管理 SDK をインストールします。
pip install azure-mgmt-search azure-identity
管理者キーとクエリ API キーを返すには、次のコードを実行します。
import os
from azure.identity import DefaultAzureCredential
from azure.mgmt.search import SearchManagementClient
# Set up variables
subscription_id = os.environ["AZURE_SUBSCRIPTION_ID"]
resource_group = "your-resource-group"
search_service_name = "your-search-service"
# Create the management client
credential = DefaultAzureCredential()
client = SearchManagementClient(credential, subscription_id)
# Get admin keys
admin_keys = client.admin_keys.get(resource_group, search_service_name)
print(f"Primary admin key: {admin_keys.primary_key}")
print(f"Secondary admin key: {admin_keys.secondary_key}")
# Get query keys
query_keys = client.query_keys.list_by_search_service(resource_group, search_service_name)
for key in query_keys:
print(f"Query key '{key.name}': {key.key}")
Reference:SearchManagementClient | AdminKeys | QueryKeys
次のコマンドを実行して、それぞれ管理者キーとクエリ API キーを返します。 PowerShell のヘルプについては、「 PowerShell を使用してAzure AI 検索 サービスを管理する」を参照してください。
Az.Search モジュールをインストールします。
Install-Module Az.Search
管理者キーを返します。
Get-AzSearchAdminKeyPair -ResourceGroupName <resource-group-name> -ServiceName <search-service-name>
クエリ キーを返します。
Get-AzSearchQueryKey -ResourceGroupName <resource-group-name> -ServiceName <search-service-name>
次のコマンドを実行して、それぞれ管理者キーとクエリ API キーを返します。 Azure CLIのヘルプについては、「 Azure CLIを参照してください。
管理者キーを返します。
az search admin-key show --resource-group <myresourcegroup> --service-name <myservice>
クエリ キーを返します。
az search query-key list --resource-group <myresourcegroup> --service-name <myservice>
接続でキーを使用する
キーベースの認証は、インデックスの作成やクエリ、 Search Service REST API を使用して実行されるその他のアクションなど、データ プレーン (コンテンツ) 要求にのみ使用されます。
ソース コードでは、要求ヘッダーで API キーを直接指定できます。 または、 環境変数またはアプリ 設定としてプロジェクトに格納し、要求で変数を参照することもできます。
- 管理キーは、オブジェクトの作成、変更、または削除に使用されます。
- 管理キーは、 LIST インデックス や GET サービス統計などの GET オブジェクト定義とシステム情報にも使用されます。
- 通常、クエリを発行するクライアント アプリケーションにクエリ キーが配布されます。
キー認証は既定で有効になっており、インデックス作成やクエリなどのデータ プレーン操作をサポートしていることを思い出してください。
ただし、API キーを無効にするとロールの割り当てを設定すると、Azure ポータルでは代わりにロールの割り当てが使用されます。
要求ヘッダーに管理者キーを設定します。 URI または要求の本文で管理者キーを渡すことはできません。
インデックス作成要求での管理者 API キーの使用方法の例を次に示します。
@baseUrl=https://my-demo-search-service.search.windows.net
@adminApiKey=aaaabbbb-0000-cccc-1111-dddd2222eeee
### Create an index
POST {{baseUrl}}/indexes?api-version=2025-09-01 HTTP/1.1
Content-Type: application/json
api-key: {{adminApiKey}}
{
"name": "my-new-index",
"fields": [
{"name": "docId", "type": "Edm.String", "key": true, "filterable": true},
{"name": "Name", "type": "Edm.String", "searchable": true }
]
}
POST の要求ヘッダーまたは GET の URI にクエリ キーを設定します。 クエリ キーは、index/docs コレクションを対象とする操作 (ドキュメントの検索、オートコンプリート、提案、またはドキュメントの取得 (GET)) に使用されます。
ドキュメントの検索 (GET) 要求でのクエリ API キーの使用方法の例を次に示します。
### Query an index
GET /indexes/my-new-index/docs?search=*&api-version=2025-09-01&api-key={{queryApiKey}}
注
api-key などの機密データを要求 URI で渡すことは、セキュリティ上推奨されません。 このため、Azure AI 検索はクエリ文字列内の api-key としてのみクエリ キーを受け入れます。 一般的なルールとして、api-key は要求ヘッダーとして渡すことをお勧めします。
API キーを環境変数として設定することをお勧めしますが、わかりやすくするために、この例では文字列として表示します。 この例では、クエリ操作にクエリ API キーを使用します。
# Import libraries
from azure.search.documents import SearchClient
from azure.core.credentials import AzureKeyCredential
from azure.identity import DefaultAzureCredential, AzureAuthorityHosts
# Variables for endpoint, keys, index
search_endpoint: str = "https://<Put your search service NAME here>.search.windows.net/"
credential = AzureKeyCredential("Your search service query key")
index_name: str = "hotels-quickstart-python"
# Set up the client
search_client = SearchClient(endpoint=search_endpoint,
index_name=index_name,
credential=credential)
# Run the query
results = search_client.search(query_type='simple',
search_text="*" ,
select='HotelName,Description,Tags',
include_total_count=True)
print ('Total Documents Matching Query:', results.get_count())
for result in results:
print(result["@search.score"])
print(result["HotelName"])
print(result["Tags"])
print(f"Description: {result['Description']}")
次の構文を使用して、要求ヘッダーに API キーを設定します。
$headers = @{
'api-key' = '<YOUR-ADMIN-OR-QUERY-API-KEY>'
'Content-Type' = 'application/json'
'Accept' = 'application/json' }
変数を使用して、完全修飾クエリを格納します。
$url = '<YOUR-SEARCH-SERVICE>/indexes/hotels-quickstart/docs?api-version=2025-09-01&search=attached restaurant&searchFields=Description,Tags&$select=HotelId,HotelName,Tags,Description&$count=true'
検索サービスに要求を送信します。
Invoke-RestMethod -Uri $url -Headers $headers | ConvertTo-Json
その他の操作のスクリプト例については、「Quickstart: REST API を使用して PowerShell でAzure AI 検索インデックスを作成するを参照してください。
クエリ キーを作成する
クエリ キーは、ドキュメント コレクションをターゲットとする操作のために、インデックス内のドキュメントへの読み取り専用アクセスに使用されます。 検索、フィルター、および推奨クエリは、いずれもクエリ キーを取得する操作です。 インデックス定義やインデクサーの状態など、システム データまたはオブジェクト定義を返す読み取り専用操作には、管理者キーが必要です。
クライアント アプリでアクセスと操作を制限することは、サービスで検索アセットを保護するために不可欠です。 クライアント アプリから発信されたクエリには、常に管理者キーではなくクエリ キーを使用します。
Azure ポータルで検索サービスに移動します。
左側のウィンドウで、[設定]>[キー] を選択して API キーを表示します。
[クエリ キーの管理] で、サービス用に既に生成されているクエリ キーを使用するか、新しいクエリ キーを作成します。 既定のクエリ キーには名前はありませんが、生成された他のクエリ キーには、管理を容易にするために名前を付けることができます。
Management REST API のクエリ キーの作成を使用します。
API キーを作成または管理するには、有効なロールの割り当てが必要です。 Azure AI 検索 サービスの管理を REST API で行う方法については、REST API を使用したガイダンス を参照してください。
POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Search/searchServices/{searchServiceName}/createQueryKey/{name}?api-version=2025-05-01
管理者キーを再生成する
ビジネス継続性のためにセカンダリ キーを使用しているときに、プライマリ キーをローテーションできるように、サービスごとに 2 つの管理者キーが作成されます。
Azure ポータルで検索サービスに移動します。
次に、左側のペインで [設定]>[キー] を選択します。
セカンダリ キーをコピーします。
すべてのアプリケーションについて、セカンダリ キーを使用するように API キーの設定を更新します。
プライマリ キーを再生成します。
新しいプライマリ キーを使用するように、すべてのアプリケーションを更新します。
誤って両方のキーを同時に再生成すると、それらのキーを使用するすべてのクライアント要求が HTTP 403 Forbidden で失敗します。 ただし、コンテンツは削除されず、永続的にロックアウトされることはありません。
引き続き、Azure ポータルまたはプログラムからサービスにアクセスできます。 管理機能は、サービス API キーではなくサブスクリプション ID を使用して操作するため、自分の API キーがない場合でも使用できます。
ポータルまたは管理レイヤーを介して新しいキーを作成した後に、要求時にそのキーを指定すると、アクセスがコンテンツ (インデックス、インデクサー、データ ソース、シノニム マップ) に復元されます。
キーからロールへの移行
ロールベースのアクセスに移行する場合は、Azure AI 検索組み込みロールにどのようにマップされるかを理解すると役立ちます>
- 管理キーは、 Search Service 共同作成者 ロールと 検索インデックス データ共同作成者 ロールに対応します。
- クエリ キーは、 検索インデックス データ閲覧者 ロールに対応します。
セキュリティで保護されたキー
ロールの割り当てを使用して、API キーへのアクセスを制限します。
カスタマー マネージド キー暗号化を使用して API キーを暗号化することはできません。 CMK で暗号化できるのは、検索サービス自体内の機密データ (データ ソース オブジェクト定義のインデックス コンテンツや接続文字列など) のみです。
Azure ポータルで検索サービスに移動します。
左側のウィンドウで、[ アクセス制御 (IAM)] を選択し、[ロールの 割り当て ] タブを選択します。
[ロール] フィルターで、キーを表示または管理するアクセス許可を持つロール (所有者、共同作成者、Search Service 共同作成者) を選択します。 これらのロールに割り当てられたセキュリティ プリンシパルは、検索サービスに対する主要なアクセス許可を持ちます。
予防措置として、[クラシック管理者] タブを確認して、管理者と共同管理者がアクセス権を持っているかどうかを確認します。
ベスト プラクティス
運用ワークロードの場合は、Microsoft Entra ID ロールベースのアクセスに切り替えます。 また、API キーを引き続き使用する場合は、API キーに アクセスできるユーザーを 常に監視し、定期的に API キーを再生成 してください。
データ漏えいのリスクがない (サンプル データを使用する場合など) 場合や、ファイアウォールの背後で操作している場合にのみ、API キーを使用します。 API キーを公開すると、データと検索サービスの両方が不正使用のリスクにさらされます。
API キーを使用する場合は、Azure Key Vault。 API キーは、コード内に直接含めないようにし、絶対に公開しないでください。
コード、サンプル、トレーニング資料は公開前に必ず確認し、API キーを誤って公開しないようにしてください。
関連コンテンツ