AZ-400 Lab03 で GitHub Actions と Bicep を使い 2 リージョンに Web アプリをデプロイすると、1 つ目は成功するのに 2 つ目だけ「Content for this resource was already consumed」「Deployment failed」で止まることがあります。この記事では、原因の切り分け手順、2 リージョン向けのパラメータ設計と命名ルール、GitHub Actions／Azure CLI 側の落とし穴まで、再発しない形で解決する考え方をまとめます。
まず結論：そのエラーメッセージは「原因」ではなく「症状」であることが多い
「Content for this resource was already consumed」は、Bicep や ARM デプロイの失敗理由そのものというより、デプロイが失敗したときに詳細エラーを表示しようとして、途中でメッセージ構築に失敗してしまい、肝心の原因が隠れるときに出やすい症状です。実際、Azure CLI のエラー処理まわりの不具合や、GitHub Actions（azure/arm-deploy など）経由の表示不全で詳細が見えなくなるケースが報告されています。
そのため、最優先は「原因当て」ではなく、どのリソース／どのパラメータで失敗しているかを可視化することです。Microsoft Q&A でも、まずは --debug と what-if で詳細を確認し、リソースグループ、必須パラメータ、命名衝突などを点検する手順が案内されています。
状況整理：AZ-400 Lab03 の「2 リージョン」デプロイでハマりやすい構造
Lab03 は、GitHub Actions と Bicep（IaC）で App Service（Web アプリ）を作り、別リージョンにも同等構成をもう 1 セット作る、という流れになりがちです。ここで典型的に起きるのが次のパターンです。
| 現象 | 起きやすい原因 | ポイント |
|---|---|---|
| 1 リージョン目は成功、2 リージョン目だけ失敗 | 2 つ目のパラメータファイルの差分ミス／命名衝突 | コピーして location だけ変えたつもりが、名前や RG を変え忘れる |
| GitHub Actions のログが「already consumed」で終わる | Azure CLI／Action 側が詳細エラーを表示し損ねている | 本当の原因は Azure 側のデプロイ履歴に残っていることが多い |
| 2 リージョン目で App Service Plan 作成に失敗 | 同名の Plan を別 location で再作成しようとしている | Plan はリージョンに紐づくため、名前・構成の分離が必要 |
| 突然 B1 などの SKU が通らない | トレーニング用サブスクリプション／Azure Pass の制限や割当不足 | ラボ側の前提が変わることがある（例：B1→F1 へ） |
原因を特定する：詳細ログを「確実に」取る方法
Azure CLI で手動実行し、--debug で本当の失敗理由を掘り出す
GitHub Actions のログが簡略化されている場合、まずは同じ Bicep とパラメータで Azure CLI を手元（または Cloud Shell）から実行し、--debug を付けて どこで落ちているかを確認します。
az deployment group create \
--resource-group YOUR_RESOURCE_GROUP \
--template-file main.bicep \
--parameters @params-region2.json \
--debugここで「already consumed」が出ても、--debug の途中に ARM 側のエラーコード（例：名前重複、パラメータ不足、ポリシー違反、クォータ不足）が含まれることがあります。特に 2 リージョン目だけ失敗する場合、2 リージョン目用のパラメータ差分が原因である確率が高いです。
what-if でドライランし、作成・更新されるリソースを比較する
2 リージョン目のパラメータが「何を作ろうとしているか」を見える化するのに、what-if は非常に有効です。デプロイ前に差分が見えるので、命名衝突や、意図しない既存リソース更新を早期に発見できます。
az deployment group what-if \
--resource-group YOUR_RESOURCE_GROUP \
--template-file main.bicep \
--parameters @params-region2.jsonMicrosoft Q&A でも、what-if を使って 2 つ目のリージョン用設定を事前確認する流れが案内されています。
ポータルの「デプロイ履歴」も必ず見る
GitHub Actions 側で詳細が見えないときほど、Azure ポータルのリソースグループにある「デプロイ（Deployments）」を確認してください。ARM の失敗理由（どのリソースが、どんなエラーコードで、どのプロパティが問題か）が残ります。
特に、Action 側が「already consumed」で落ちるケースは、CLI がレスポンス本文の読み出しで失敗し、元のエラーを隠してしまう挙動として報告されています。ポータルはこの影響を受けにくいため、原因特定が速いです。
2 リージョン目で失敗しがちな「よくある原因」と対処
リソースグループ名／スコープの取り違え
- 2 リージョン目用の Workflow やパラメータで、別のリソースグループを想定しているのに、1 つ目の RG を参照している
- そもそも RG が作られていない、スペルが違う
対策としてはシンプルで、まず RG の存在確認（一覧やポータル）を行い、Workflow の変数とパラメータを「1 リージョン目」「2 リージョン目」で明確に分けます。
必須パラメータが null になっている（コピー時に起きやすい）
ラボではテンプレートに必須パラメータがあり、2 リージョン目用パラメータファイルをコピーした際に未設定（null）が混ざると失敗します。代表例として adminPassword が挙げられており、Azure は null を受け付けないため、強固なパスワードへ置換が必要です。
注意
- パスワードや秘密情報は、パラメータファイルに直書きせず GitHub Secrets などで渡す設計が安全です。
--debugのログには情報が多く出るため、機密値が混ざらないように運用も見直してください。
命名の重複（特に Web アプリ名は「全世界でユニーク」）
2 リージョン目だけ失敗する最頻出が「名前の衝突」です。1 つ目で作ったものと同じ名前を 2 つ目でも作ろうとすると、ARM で衝突します。ここで重要なのは、リソースごとに “ユニーク要件の範囲” が違うことです。
| リソース例 | 名前のユニーク範囲 | 2 リージョンでの設計ポイント |
|---|---|---|
| App Service（Web アプリ / site） | グローバル | リージョン名・環境名・乱数サフィックスで必ず分ける（例：myapp-eastus / myapp-westeurope） |
| App Service Plan | リソースグループ内 | Plan 自体がリージョンに紐づくため、リージョンごとに別 Plan として名前も分離 |
| Storage Account（使っている場合） | グローバル | 短い制約があるので、uniqueString 等で衝突しない命名が必須 |
| NIC / NSG / VM（ラボ構成により） | リソースグループ内 | パラメータファイルをコピーしたら、関連リソース名も一括で変更 |
Microsoft Q&A でも「VM、NIC、NSG などの名前をユニークにする」ことが原因対処として挙げられています。Web アプリ名はさらに厳しくグローバルユニークなので、2 リージョン化では最優先で見直してください。
App Service Plan を “同名・別リージョン” で作り直そうとしている
1 つ目のリージョンで planName=app-plan を作り、2 つ目でも同じ app-plan を使って location だけ変えると、ARM は「同じリソースを別場所で作る」形になり、失敗につながります。
対策は、2 リージョンで App Service Plan を 完全に別物として扱うことです。たとえば次のように分けます。
- plan-eastus / web-eastus
- plan-westeurope / web-westeurope
テンプレートとパラメータファイルの不整合（必須パラメータの渡し忘れ）
「テンプレートにある必須パラメータが、2 リージョン目用パラメータファイルに存在しない」も定番です。必須は必ず埋める、オプションなら既定値をテンプレート側に持たせる、という方針に寄せると事故が減ります。Microsoft Q&A でも「テンプレートの全パラメータに対し、パラメータファイルが揃っているか」を確認するよう案内されています。
サブスクリプション制限・SKU 制限（ラボ環境で起きやすい）
ラボ用のサブスクリプション（Azure Pass 等）では、リージョンによって SKU が通らない、割当（コア／リソース）が不足する、といった環境要因が混ざることがあります。実際に、ラボで App Service Plan の SKU が B1 だと通らず F1 に切り替える回避や、「insufficient Cores」系のエラー報告が GitHub 側に残っています。
この場合も「already consumed」は本質ではなく、本当のエラー（SKU 不可／割当不足）が別に存在します。ポータルのデプロイ履歴か --debug の中に “本当の理由” が出るので、そこから手を打つのが最短です。
2 リージョン対応を成功させるパラメータ設計と命名ルール
「リージョンごとの違い」をパラメータファイルに閉じ込める
2 リージョン展開では、Bicep 本体を分岐だらけにするより、パラメータファイル（region1 / region2）で差分管理する方が壊れにくいです。具体的には次の項目をリージョン別にします。
- location（リージョン）
- webAppName（グローバルユニーク）
- appServicePlanName（リージョンごとに分離）
- （構成により）Storage / KeyVault / Insights などの名前
命名は “人間に分かる” ＋ “衝突しない” を両立する
おすすめは「固定プレフィックス + リージョン + 短いサフィックス」です。運用上の見分けやすさと衝突回避を両立できます。
| リソース | 悪い例 | 良い例 | 理由 |
|---|---|---|---|
| Web アプリ | myapp | myapp-web-eastus / myapp-web-westeurope | グローバルユニーク＋見分けやすい |
| App Service Plan | myapp-plan | myapp-plan-eastus / myapp-plan-westeurope | 同名で location 変更すると失敗しがち |
| （必要なら）短いサフィックス | なし | -a1b2 など | 同名が既に存在する場合の衝突回避 |
Bicep 側で衝突耐性を上げる（uniqueString を活用）
ラボの目的上、固定名で進めるケースもありますが、実務寄りにするなら Bicep の uniqueString() を使って「同じテンプレートを何度流しても衝突しにくい」形に寄せるのがおすすめです。
param location string
param baseName string
var suffix = uniqueString(resourceGroup().id, location)
var webAppName = '${baseName}-web-${location}-${suffix}'
var planName = '${baseName}-plan-${location}-${suffix}'こうしておけば、2 リージョン目のパラメータファイルで location を変えるだけでも衝突確率が下がります。ただしラボでは命名が手順とズレる場合もあるため、採用するなら「どこまで自動化するか」を意識して調整してください。
GitHub Actions 側でハマるポイント：Azure CLI／Action のバージョン問題
「本当のエラーが見えない」なら、まず Azure CLI バージョンを出力する
GitHub Actions でデプロイしている場合、ログ冒頭に Azure CLI のバージョンを出すだけで、切り分けが急に楽になります。
- name: Show Azure CLI version
run: az version実際に、Azure CLI のエラー処理が原因で「The content for this response was already consumed」が出て、元のエラーが隠れる挙動は GitHub Issues としても報告されています。
改善策：CLI を最新へ上げる／安定版へ寄せる
Azure CLI のリリースノートには、この系統の「エラーが隠れる」問題への修正が含まれています。たとえば、Azure CLI 2.78.0（2025-10-14）では「テンプレート検証失敗時にエラーメッセージが隠れる問題の修正」が記載されています。
また 2.76.0（2025-08-05）のリリースノートでも、「the content for this response was already consumed」系の修正が記載されています。
つまり、GitHub Actions でこのメッセージが出続ける場合は、テンプレートの問題だけでなく、実行環境（Azure CLI）の更新状況も疑う価値があります。
ワークフロー上でバージョンを固定したいときの現実的な方法
GitHub Actions の標準ランナーはプリインストールされた Azure CLI が「常に最新寄り」へ更新されるため、完全に自由にピン留めできないことがあります。
ラボや検証で「どうしても特定バージョンで再現／回避したい」場合は、次のいずれかが現実的です。
- ジョブをコンテナで実行（例：
mcr.microsoft.com/azure-cli系のイメージを使い、CLI の差分を減らす） - ワークフロー内で Azure CLI を再インストール（安定版へ寄せる／最新版へ上げる）
- PowerShell（Az）でデプロイし、CLI 特有の表示不全を回避（PowerShell では影響しないという報告あり）
「already consumed」自体はデプロイ失敗時に出る“表示上の問題”として説明され、回避として --debug／what-if や特定バージョンへの切り替えが言及されています。
azure/arm-deploy を使っている場合の注意
もし Lab03 の手順や自分のワークフローが azure/arm-deploy を使っているなら、「テンプレートは以前動いていたのに、突然 already consumed だけ出て失敗する」という報告もあります。Action 自体が内部で Azure CLI を使うため、CLI 側の挙動に引っ張られる可能性があります。
最短で直すためのチェックリスト（2 リージョン目だけ失敗するとき）
| チェック項目 | 確認方法 | 直し方の例 |
|---|---|---|
| 2 リージョン目のパラメータが “本当に” 切り替わっているか | workflow の引数・参照ファイル名をログに出す | region2 用 params を別名で固定（params-eastus.json / params-westeurope.json） |
| Web アプリ名がグローバルで重複していないか | 2 リージョン目の webAppName を目視 | リージョン名を含める（myapp-web-eastus 等） |
| App Service Plan が同名で別リージョン扱いになっていないか | what-if の差分で Plan の location を確認 | planName をリージョン別に分ける |
| 必須パラメータが欠けていないか（null/空） | what-if / debug / パラメータファイル | 必須は必ず設定、秘密は Secrets に寄せる |
| サブスクリプション制限（SKU/割当）に引っかかっていないか | ポータルのデプロイ履歴でエラーコード確認 | SKU を見直す、リージョン変更、割当のある環境へ切替 |
| Azure CLI の表示不全で原因が隠れていないか | az version を出す／ポータルで原因を見る | CLI 更新、コンテナ実行、PowerShell へ切替 |
どうしても直らない場合：ラボ教材側の更新・不具合を疑う
AZ-400 のラボは Azure 側の仕様変更やサブスクリプション条件の変化の影響を受けることがあります。Microsoft Q&A でも「公式リポジトリに Issue を登録する」選択肢が案内されています。
ただし、AZ-400 の旧ラボリポジトリ（MicrosoftLearning/AZ400-DesigningandImplementingMicrosoftDevOpsSolutions）は 2025-11-14 にアーカイブされ、現在は読み取り専用です。新しい DevOps ラボのリポジトリとして MicrosoftLearning/mslearn-devops が案内されています。
報告するときは、次の情報が揃っているとトリアージが早くなります。
- Lab 名（Lab03）と実行した手順の範囲（どの Exercise / Task まで進んだか）
- GitHub Actions の該当 Run のログ（already consumed の直前まで）
- Azure ポータルのデプロイ履歴に出ている “本当のエラーコード” とメッセージ
- 使用した Bicep とパラメータファイルの差分（特に region1/region2 の命名）
- az version（または azure/arm-deploy 等の action バージョン）
まとめ：2 リージョン目だけ失敗したら「差分」と「表示不全」を同時に疑う
「Content for this resource was already consumed」は、2 リージョン目デプロイでよく見る一方で、原因を直接示さないことが多いメッセージです。まず --debug と what-if、そしてポータルのデプロイ履歴で “本当のエラー” を掘り起こし、次に 2 リージョン目パラメータの差分（特に命名）を潰すのが最短ルートです。さらに GitHub Actions の実行環境（Azure CLI／Action のバージョン）によっては、原因が隠れること自体が問題になるため、バージョン出力と更新・回避策もセットで持っておくと、ラボだけでなく実務でも再現性高くトラブルシュートできます。
コメント