Microsoft developer platform更新：Clean up unused Bicep resourcesの変更点と確認ポイント

Microsoft developer platformの「refactor: Clean up unused Bicep resources」は、BicepとARMテンプレートから未使用または不要になったインフラ定義を整理する更新です。結論から言うと、テンプレートをそのまま新規デプロイするだけの読者は大きな作業なしで追従できます。一方で、Azure AI Foundry、Azure AI Search、azdの.env出力、CI/CDスクリプト、独自に改変したBicepテンプレートに依存している場合は、更新前に確認が必要です。

この更新は、Microsoftのcontent-generation-solution-acceleratorに対するPR #834としてマージされ、2026年5月5日リリースのv2.4.3に含まれています。PR本文では、明示的なAI Search接続リソースと関連設定をBicepおよびARMテンプレートから削除し、AI AgentやFoundryプロジェクト関連の一部パラメーター・出力、未使用のストレージ定義も整理したと説明されています。(GitHub)

Microsoft developer platformの「Clean up unused Bicep resources」で何が変わったのか

今回のMicrosoft developer platform documentation updateは、機能追加というよりインフラ定義の整理に近い変更です。対象は主にinfra/main.bicep、infra/main_custom.bicep、infra/main.jsonの3ファイルで、PRのFiles changedでは1行追加、149行削除の差分として確認できます。(GitHub)

変更領域	主な変更内容	実務上の意味
AI Search接続	`aiSearchFoundryConnection`リソースを削除	Azure AI FoundryプロジェクトとAzure AI Searchを結ぶ明示的なプロジェクトレベル接続をテンプレートで作成しなくなる
Bicep/ARM出力	`AI_FOUNDRY_NAME`、`AI_FOUNDRY_RG_NAME`、`AZURE_AI_AGENT_ENDPOINT`、`AZURE_AI_AGENT_API_VERSION`などを削除	`azd`の`.env`やCI/CDでこれらの出力値を参照している場合、参照切れや古い値の残存に注意が必要
パラメーター	`azureAiAgentApiVersion`を削除	AI Agent APIバージョンをテンプレートの入力として渡していた独自環境では見直しが必要
ストレージ定義	`dataContainer`変数と`data`ストレージコンテナー定義を削除	未使用コンテナーを前提にしたデータ投入スクリプトがある場合は確認が必要
ARMテンプレート	`main.json`のテンプレートハッシュも更新	Bicep変更に合わせて生成済みARMテンプレートも同期されたと見てよい

重要なのは、Azure AI Searchサービス自体が不要になったという意味ではない点です。このソリューションは引き続きMicrosoft Foundry、Azure AI Search、Azure Cosmos DB、Azure Blob Storageを使って、クリエイティブブリーフの解釈、商品情報の取得、コンテンツ生成、ブランド準拠チェックを行う構成として説明されています。(GitHub)

影響を受けやすい人と、対応不要に近い人

今回の変更は「未使用リソースの削除」という名前ですが、テンプレートの出力や接続定義に依存している環境では影響が出ます。まずは自分の利用状況を次の表で切り分けてください。

利用状況	対応優先度	確認すべきポイント
v2.4.3以降を新規に試すだけ	低	通常は最新テンプレートの手順どおりにデプロイすればよい
既存環境で`azd up`や`azd provision`を再実行する	中	古い`.env`値が残っていないか、削除された出力をアプリやスクリプトが参照していないか
自社フォークでBicep/ARMを改変している	高	削除されたリソース・変数・出力を独自コードが使っていないか
CI/CDで`AZURE_AI_AGENT_ENDPOINT`などを読んでいる	高	環境変数の取得元を見直す必要がある
Azure AI Foundryプロジェクト内のAI Search接続を手動・コードで参照している	高	プロジェクトレベル接続がなくても検索・生成フローが成立するか
Complete modeやDeployment stacksで削除を管理している	高	テンプレートから消えたリソースが削除対象になる可能性を事前確認する

PR本文では、主要ワークフローとデプロイプロセスは検証済みとされています。ただし、これはリポジトリ側の標準的な経路に対する確認であり、各社のフォーク、追加スクリプト、既存のAzure環境まで保証するものではありません。(GitHub)

特に確認すべき削除項目

AI Search接続リソースの削除

最も大きな変更は、Microsoft.CognitiveServices/accounts/projects/connections@2025-12-01として定義されていたaiSearchFoundryConnectionの削除です。旧定義では、接続カテゴリにCognitiveSearchを指定し、https://<search-service>.search.windows.netをターゲットにしていました。 (GitHub)

この変更により、新しいテンプレートではAI FoundryプロジェクトとAzure AI Searchの接続を明示的に作成しません。標準構成では問題ない前提で整理されていますが、以下に該当する場合は動作確認が必要です。

エージェントやアプリケーションコードがFoundryプロジェクト内の接続名を直接参照している
foundry-search-connection-...のような命名規則を前提にしたスクリプトがある
Azure Portal上で作成される接続を監査・棚卸し対象にしている
既存のAI Search接続を手動でカスタマイズしている

なお、PR上の旧定義ではif (!useExistingAiFoundryAiProject)という条件が使われていました。つまり、もともと既存のAI Foundryプロジェクトを指定する構成では、この接続リソースがテンプレートから作られないケースがありました。既存プロジェクト利用者は、新規プロジェクトを作る利用者より影響が限定的な可能性があります。(GitHub)

`azd`の`.env`に出力される値の変更

Azure Developer CLIは、Bicepテンプレートのoutputを環境ごとの.envファイルに自動保存できます。つまり、Bicepから出力が削除されると、azd provisionやazd up後に新しい環境で取得できる変数も変わります。(Microsoft Learn)

特に次の名前を参照しているコードやスクリプトは検索してください。

grep -R "AI_FOUNDRY_NAME\|AI_FOUNDRY_RG_NAME\|AZURE_AI_AGENT_ENDPOINT\|AZURE_AI_AGENT_API_VERSION\|CONTAINER_INSTANCE_IP\|aiSearchFoundryConnection\|dataContainer" .

確認対象は、アプリケーションコードだけではありません。GitHub Actions、Azure DevOps Pipeline、PowerShell、Bash、.env.sample、README、社内の運用手順書も対象にしてください。

見落としやすいのは、既存の.azure/<environment name>/.envに古い値が残っていて、ローカルでは動いてしまうケースです。新規環境を作ると変数が存在せず、CIや別メンバーの環境で初めて失敗することがあります。移行確認では、既存環境だけでなくクリーンな環境でもazd upまたはazd provisionを試すのが安全です。

`data`ストレージコンテナーの削除

dataContainer変数とdataコンテナー定義も削除されています。標準テンプレート上は未使用整理と考えられますが、フォークした環境でdataコンテナーにサンプルデータ、投入済みCSV、検証用JSON、検索インデックス作成用ファイルを置いていた場合は注意が必要です。(GitHub)

確認するポイントは次の3つです。

確認項目	見る場所	判断基準
`data`コンテナーに実データがあるか	Azure Portal、Storage Explorer、運用スクリプト	空なら影響は小さい。ファイルがある場合は用途を確認
アプリや初期化スクリプトが`data`を参照しているか	`scripts`、`src`、CI/CD定義	参照がある場合は別コンテナーへ移すか処理を修正
削除ポリシーでコンテナーが消える可能性があるか	デプロイ方式、IaC管理方針	Complete modeや削除管理の方式を確認

既存Azureリソースは自動で消えるとは限らない

BicepやARMテンプレートからリソース定義が消えても、既存のAzureリソースが必ず削除されるわけではありません。Azure Resource Managerの既定はIncremental modeで、このモードではテンプレートに含まれていないリソースは基本的に変更されません。Microsoft Learnでも、Incremental modeが既定であり、テンプレートにないリソースは変更されず残ると説明されています。(Microsoft Learn)

一方、Complete modeではテンプレートに含まれていないリソースが削除される可能性があります。Microsoft LearnではComplete modeは推奨されず、削除を伴う場合はDeployment stacksの利用が案内されています。また、Complete modeでデプロイする前にはwhat-ifを使って作成・変更・削除されるリソースを確認することが推奨されています。(Microsoft Learn)

つまり、今回の更新で注意すべきポイントは次の2つです。

デプロイ方式	起こりやすいこと	対応
Incremental mode	旧`aiSearchFoundryConnection`や`data`コンテナーがAzure上に残る可能性がある	不要なら手動削除や管理方針に沿った棚卸しを行う
Complete modeまたは削除管理あり	テンプレートから消えたリソースが削除対象になる可能性がある	what-ifで削除対象を確認してから適用する

コスト削減を期待している場合も、テンプレート整理だけで既存リソースが消えるとは限りません。Azure上のリソース一覧、ストレージコンテナー、Foundryプロジェクト接続、検索サービスを実際に確認してください。

更新前後で実施したい確認手順

まず差分とリリースを確認する

この更新はv2.4.3に含まれ、リリースノートにはrefactor: Clean up unused Bicep resources、remove aiSearchFoundryConnection resource、update template hash in main.jsonなどの関連コミットが並んでいます。運用環境で利用しているブランチやタグがv2.4.3以降か、またはPR #834の内容を取り込んでいるかを確認してください。(GitHub)

確認観点は次のとおりです。

確認対象	見るべき内容
リポジトリのタグ	v2.4.3以降を参照しているか
フォーク済みテンプレート	`infra/main.bicep`、`infra/main_custom.bicep`、`infra/main.json`に独自差分がないか
デプロイ手順	`azd up`、`azd provision`、Azure CLI、Azure DevOpsなど、どの経路で適用しているか
環境変数	削除されたBicep outputを前提にしていないか

what-ifで削除・変更を事前確認する

Bicepを使っている場合、適用前にwhat-ifを実行すると、デプロイ時に予測される変更を確認できます。what-ifは実リソースを変更せず、Bicepファイルをデプロイした場合の変更を予測する機能です。(Microsoft Learn)

リソースグループスコープで確認する例は次のとおりです。

az deployment group what-if \
  --resource-group <resource-group-name> \
  --template-file infra/main.bicep

デプロイ時に確認プロンプト付きで実行したい場合は、次のように--confirm-with-what-ifを使えます。

az deployment group create \
  --resource-group <resource-group-name> \
  --template-file infra/main.bicep \
  --confirm-with-what-if

what-ifの結果では、Delete、Modify、Createだけでなく、IgnoreやNoChangeも確認してください。特にComplete modeを使っている場合、削除予定のリソースにAI Search接続、ストレージコンテナー、関連する権限設定が含まれていないかを見落とさないことが重要です。

`.env`とアプリ設定を確認する

azdを使っている場合は、現在の環境変数を確認します。

azd env get-values

削除された出力に依存しているかを調べる場合は、次のような観点で確認します。

変数名	確認ポイント
`AZURE_AI_AGENT_ENDPOINT`	アプリがAgent endpointをこの変数から取得していないか
`AZURE_AI_AGENT_API_VERSION`	APIバージョンをこの変数で固定していないか
`AI_FOUNDRY_NAME`	Foundryプロジェクト名をスクリプトで参照していないか
`AI_FOUNDRY_RG_NAME`	リソースグループ名を自動取得する処理が壊れないか
`CONTAINER_INSTANCE_IP`	ネットワーク疎通確認やプロキシ設定で使っていないか

本番相当の確認では、既存の.envを使い回すだけでなく、新しいazd環境を作ってデプロイし、必要な値が不足していないかを見ると安全です。

動作確認で見るべきアプリ側のシナリオ

このソリューションは、クリエイティブブリーフの解釈、商品データに基づくコンテンツ生成、ブランド準拠チェックなどを行うAIエージェント型の構成です。READMEでは、Microsoft Agent Frameworkによる専門エージェントのオーケストレーションや、Azure AI Searchを含むAzureサービスの利用が説明されています。(GitHub)

テンプレート更新後は、単にデプロイが成功しただけで完了にしないでください。次の順番で確認すると、問題の切り分けがしやすくなります。

確認シナリオ	確認内容	失敗時に見る場所
デプロイ完了	`azd up`または`azd provision`が成功する	デプロイログ、ARMエラー、権限
商品情報の取得	AI Searchに依存する検索・参照が動く	Search service、インデックス、接続設定
ブリーフ解析	入力テキストが構造化される	バックエンドログ、Agent設定
コンテンツ生成	テキストや画像生成が成功する	Azure AI Services、モデルデプロイ、クォータ
ブランド準拠チェック	ガイドラインに基づく検証が返る	Cosmos DB、Blob Storage、アプリログ
再デプロイ	2回目以降のデプロイで不要な差分が出ない	what-if、Bicep差分、`.env`

特に「商品情報の取得」は、AI Search接続リソース削除の影響を受けやすい確認ポイントです。検索サービスそのもの、インデックス、アプリ側の接続方法を分けて確認してください。

移行時に起きやすい失敗と対策

失敗しやすいポイント	原因	対策
ローカルでは動くがCIで失敗する	ローカルの`.env`に古い出力値が残っている	クリーン環境で`azd up`を実行し、必要な変数を洗い出す
Azure上に旧リソースが残り続ける	Incremental modeではテンプレート外リソースが残る	棚卸し後、不要と判断したものだけ削除する
想定外にリソースが削除される	Complete modeや削除管理の設定でテンプレート外リソースが削除対象になる	what-ifで削除対象を確認してから適用する
AI Searchを消してしまう	「AI Search接続削除」を「AI Searchサービス不要」と誤解する	削除対象はプロジェクトレベル接続であり、検索サービスの役割は別途確認する
自社フォークのBicepがコンパイルできない	削除された変数や出力を別ファイルで参照している	`grep`で参照箇所を探し、現行テンプレートに合わせて修正する
運用手順書が古い	旧出力名や旧接続名を前提にしている	README、CI/CD手順、監視手順を更新する

対応方針：そのまま追従するか、独自定義を残すか

標準テンプレートを使っているなら、まずはv2.4.3以降の構成に追従するのが自然です。PRでは未使用Bicepリソースの整理として扱われ、標準ワークフローの検証も記載されています。(GitHub)

一方で、次の条件に当てはまる場合は、削除された定義を安易に消さず、独自に残すか別の形で管理する判断もあります。

判断材料	推奨対応
AI Foundryプロジェクト内の検索接続を明示的に監査している	接続作成を独自Bicepまたは運用手順に分離する
アプリが`AZURE_AI_AGENT_ENDPOINT`を必須としている	アプリ設定の取得方法を最新テンプレートに合わせる。必要なら独自outputを追加する
`data`コンテナーを実データ置き場として使っている	別コンテナーへ移行するか、独自ストレージ定義として残す
本番でComplete modeを使っている	what-ifと承認フローを必須化し、削除対象をレビューする
社内テンプレートとして再配布している	変更点をリリースノート化し、利用者に参照切れの確認を促す

独自定義を残す場合も、上流テンプレートにそのまま戻すのではなく、「なぜ必要か」「誰が使うか」「削除してよい条件は何か」をコメントやドキュメントに残すことが重要です。未使用リソースの掃除は、短期的には差分対応ですが、長期的には運用コストとトラブル調査時間を減らすための作業です。

まず実施すべきアクション

今回のMicrosoft developer platform documentation updateで最初にやるべきことは、デプロイではなく依存関係の確認です。特に、aiSearchFoundryConnection、AZURE_AI_AGENT_ENDPOINT、AZURE_AI_AGENT_API_VERSION、AI_FOUNDRY_NAME、AI_FOUNDRY_RG_NAME、dataContainerを参照している箇所を検索してください。

そのうえで、Bicepのwhat-ifを実行し、既存環境で何が変更・削除・無視されるかを確認します。標準構成に近い環境なら、v2.4.3以降へ追従して問題ない可能性が高いです。一方、自社フォーク、CI/CD、.env、Foundry接続、ストレージコンテナーに独自利用がある場合は、更新前にテスト環境でデプロイと主要ワークフローを確認してから本番へ反映してください。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。