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

2025-06-23

この記事では、操作中にリソースが見つからない場合に表示されるエラーについて説明します。通常、このエラーは、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 ポータルにサインインします。使用しようとしているリソースを検索し、リソース名、リソースグループ、およびサブスクリプションを調べます。

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

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

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

二頭筋
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 では、シンボリック名を使用して、別のリソースへの暗黙的な依存関係を作成します。既存のキーワードは、デプロイされたリソースを参照します。既存のリソースがデプロイするリソースとは異なるリソースグループにある場合は、 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 を取得する

二頭筋
JSON

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

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

vm.identity.principalId

vm.identity.tenantId

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

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

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

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

Von Bedeutung

次のパターンは使用しないでください。

"[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:チェック機能

二頭筋
JSON

リソースのシンボリック名を使用して、リソースから値を取得できます。同じリソースグループまたは別のリソースグループ内のストレージアカウントは、シンボリック名を使用して参照できます。デプロイされたリソースから値を取得するには、既存のキーワードを使用します。リソースが別のリソースグループにある場合は、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:リソースを削除した後

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

削除されたリソースと、リソースの [概要] セクションに

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