リソースが見つからないエラーを解決する

[アーティクル]
06/01/2023

この記事では、操作中にリソースが見つからないときに発生するエラーについて説明します。通常、このエラーは、Bicep ファイルまたは Azure Resource Manager テンプレート (ARM テンプレート) を使ってリソースをデプロイするときに表示されます。また、管理タスクを実行しているときに、Azure Resource Manager で必要なリソースが見つからない場合にもこのエラーは発生します。たとえば、存在しないリソースにタグを追加しようとすると、このエラーが発生します。

現象

リソースが見つからないことを示す 2 つのエラーコードがあります。 NotFound エラーでは、次のような結果が返されます。

Code=NotFound;
Message=Cannot find ServerFarm with name exampleplan.

ResourceNotFound エラーでは、次のような結果が返されます。

Code=ResourceNotFound;
Message=The Resource 'Microsoft.Storage/storageAccounts/{storage name}' under resource
group {resource group name} was not found.

原因

Resource Manager でリソースのプロパティを取得する必要がありますが、お使いのサブスクリプション内でリソースを見つけることができません。

解決策 1: リソースのプロパティを確認する

管理タスクの実行中にこのエラーが発生した場合は、リソースに指定した値を確認してください。次の 3 つの値を確認します。

リソース名
リソースグループ名
サブスクリプション

PowerShell または Azure CLI を使用している場合は、リソースが含まれているサブスクリプションでコマンドを実行していることを確認します。 Set-AzContext または az account set を使用して、サブスクリプションを変更できます。多くのコマンドで、現在のコンテキストとは異なるサブスクリプションを指定できるサブスクリプションパラメーターが用意されています。

プロパティを確認できない場合は、Microsoft Azure portal にサインインします。使用しようとしているリソースを検索し、リソース名、リソースグループ、およびサブスクリプションを調べます。

解決策 2: 依存関係を設定する

テンプレートをデプロイするときにこのエラーが発生した場合は、依存関係の追加が必要になることがあります。 Resource Manager は、可能であれば複数のリソースを並行して作成することで、デプロイを最適化しています。

たとえば、Web アプリをデプロイする場合は、App Service プランが存在する必要があります。 Web アプリが App Service プランに依存していることを指定しなかった場合、Resource Manager では同時に両方のリソースが作成されます。 Web アプリは、App Service プランのリソースがまだ存在しないため見つからない、というエラーで失敗します。このエラーは、Web アプリに依存関係を設定することで回避します。

Bicep
JSON

resourceId 関数ではなく、暗黙的な依存関係を使用します。依存関係は、リソースのシンボリック名と ID プロパティを使用して作成されます。

たとえば、Web アプリの serverFarmId プロパティは servicePlan.id を使用して App Service プランへの依存関係を作ります。

resource webApp 'Microsoft.Web/sites@2022-03-01' = {
  properties: {
    serverFarmId: servicePlan.id
  }
}

resource servicePlan 'Microsoft.Web/serverfarms@2022-03-01' = {
  name: hostingPlanName
  ...

ほとんどのデプロイでは、dependsOn を使用して明示的な依存関係を作る必要はありません。

不要な依存関係を設定しないようにします。不要な依存関係があると、リソースが並行してデプロイされないので、デプロイの期間が長くなります。また、循環依存関係が作成されてデプロイがブロックされる可能性があります。

リソースを順番にデプロイする必要がある場合は、テンプレートで dependsOn 要素を使用します。

{
  "type": "Microsoft.Web/sites",
  "apiVersion": "2022-03-01",
  "dependsOn": [
    "[variables('hostingPlanName')]"
  ],
  ...
}

reference および list* 関数では、参照されているリソースが同じテンプレートでデプロイされ、(リソース ID ではなく) 名前によって参照されている場合、そのリソースに対する暗黙的な依存関係が作成されます。このため、dependsOn プロパティで指定したよりも多くの依存関係が作成されることがあります。

resourceId 関数は暗黙的な依存関係を作成しません。また、リソースの存在を検証することもしません。 reference 関数および list* 関数は、リソースがリソース ID によって参照されているときは、暗黙的な依存関係を作成しません。暗黙的な依存関係を作成するには、同じテンプレートでデプロイされるリソースの名前を渡します。

デプロイ順

依存関係の問題が発生した場合は、リソースのデプロイ順序を把握する必要があります。ポータルを使用して、デプロイ操作の順序を確認できます。

ポータルにサインインします。
リソースグループの [概要] から、デプロイ履歴のリンクを選びます。
確認する [デプロイ名] で、[関連イベント] を選びます。
各リソースのイベントの順序を調べます。各操作の状態とタイムスタンプに注意してください。たとえば、次の図には、並列でデプロイされた 3 つのストレージアカウントが示されています。 3 つのストレージアカウントのデプロイが同時に開始されたことがわかります。

次の図には、並列でデプロイされていない 3 つのストレージアカウントが示されています。 2 つ目のストレージアカウントは最初のストレージアカウントに依存し、3 つ目のストレージアカウントは 2 つ目のストレージアカウントに依存します。最初のストレージアカウントには、次のストレージアカウントが開始される前に、[開始]、[受け入れ]、[完了] というラベルが付けられます。

Bicep ではシンボリック名を使用して、別のリソースに対する暗黙的な依存関係を作成します。 existing キーワードは、デプロイされたリソースを参照します。既存のリソースがデプロイするリソースとは異なるリソースグループにある場合は、scope を含めて resourceGroup 関数を使用します。

この例では、別のリソースグループの既存の App Service プランを使用する Web アプリがデプロイされています。

resource servicePlan 'Microsoft.Web/serverfarms@2022-03-01' existing = {
  name: hostingPlanName
  scope: resourceGroup(rgname)
}

resource webApp 'Microsoft.Web/sites@2022-03-01' = {
  name: siteName
  properties: {
    serverFarmId: servicePlan.id
  }
}

テンプレートをデプロイするときに、別のサブスクリプションまたはリソースグループに存在するリソースを取得する必要がある場合は、resourceId 関数を使用します。この関数は、リソースの完全修飾名を返します。

resourceId 関数のサブスクリプションとリソースグループのパラメーターは省略可能です。指定しない場合は、既定で現在のサブスクリプションとリソースグループが使用されます。別のリソースグループまたはサブスクリプション内のリソースを操作する場合は、それらの値を指定していることを確認してください。

次の例では、別のリソースグループに存在するリソースのリソース ID を取得します。

"properties": {
  "name": "[parameters('siteName')]",
  "serverFarmId": "[resourceId('plangroup', 'Microsoft.Web/serverfarms', parameters('hostingPlanName'))]"
}

解決策 4: リソースからマネージド ID を取得する

Bicep
JSON

マネージド ID と共にリソースをデプロイする場合は、そのリソースがデプロイされるまで待機してから、マネージド ID の値を取得する必要があります。 ID が適用されるリソースに対して暗黙的な依存関係を使用します。この方法では、Resource Manager が依存関係を使うする前に、リソースとマネージド ID が確実にデプロイされます。

仮想マシンに適用されているマネージド ID のプリンシパル ID とテナント ID を取得できます。たとえば、仮想マシンリソースのシンボリック名が vm である場合は、次の構文を使用します。

vm.identity.principalId

vm.identity.tenantId

マネージド ID と共にリソースをデプロイする場合は、そのリソースがデプロイされるまで待機してから、マネージド ID の値を取得する必要があります。マネージ ID 名を reference 関数に渡すと、Resource Manager はリソースと ID がデプロイされる前に参照の解決を試みます。代わりに、ID が適用されるリソースの名前を渡します。この方法では、Resource Manager が参照関数を解決する前に、リソースとマネージド ID が確実にデプロイされます。

Reference 関数では、Full を使用して、マネージド ID を含むすべてのプロパティを取得します。

パターンは次のとおりです。

"[reference(resourceId(<resource-provider-namespace>, <resource-name>), <API-version>, 'Full').Identity.propertyName]"

重要

次のパターンは使用しません。

"[reference(concat(resourceId(<resource-provider-namespace>, <resource-name>),'/providers/Microsoft.ManagedIdentity/Identities/default'),<API-version>).principalId]"

テンプレートが失敗します。

たとえば、仮想マシンに適用されるマネージド ID のプリンシパル ID を取得するには、次を使用します。

"[reference(resourceId('Microsoft.Compute/virtualMachines', variables('vmName')), '2022-03-01', 'Full').identity.principalId]",

または、仮想マシンスケールセットに適用されるマネージド ID のテナント ID を取得するには、次を使用します。

"[reference(resourceId('Microsoft.Compute/virtualMachineScaleSets',  variables('vmNodeType0Name')), '2022-03-01', 'Full').Identity.tenantId]"

解決策 5: 関数を確認する

Bicep
JSON

リソースのシンボリック名を使って、リソースから値を取得できます。シンボリック名を使って、同じリソースグループまたは別のリソースグループ内のストレージアカウントを参照できます。デプロイされたリソースから値を取得するには、existing キーワードを使います。リソースが別のリソースグループ内にある場合は、resourceGroup 関数と共に scope を使います。ほとんどの場合、reference 関数は必要はありません。

次の例では、別のリソースグループにある既存のストレージアカウントが参照されています。

resource stgAcct 'Microsoft.Storage/storageAccounts@2022-05-01' existing = {
  name: stgname
  scope: resourceGroup(rgname)
}

テンプレートをデプロイするときに、reference または listKeys 関数を使用する式を探します。指定する値は、リソースが同じテンプレート、リソースグループ、およびサブスクリプション内にあるかどうかに応じて異なります。シナリオに必要なパラメーター値を指定していることを確認してください。リソースが別のリソースグループ内にある場合は、完全なリソース ID を指定します。たとえば、別のリソースグループのストレージアカウントを参照するには、次のコードを使用します。

"[reference(resourceId('exampleResourceGroup', 'Microsoft.Storage/storageAccounts', 'myStorage'), '2022-05-01')]"

解決策 6: リソースを削除した後

リソースを削除すると、短時間ですが、リソースがポータルに表示されていても使用できないという場合があります。リソースを選択すると、リソースが見つからないというエラーが表示されます。

リソースの [概要] セクションで、削除されたリソースを '見つかりません' のエラーメッセージと一緒に表示する Azure portal のスクリーンショット。

ポータルを更新すると、削除されたリソースが使用可能なリソースの一覧から削除されます。削除されたリソースが引き続き数分間使用可能と表示される場合は、サポートにお問い合わせください。