MENU

Microsoft developer platformのBicepリソース整理とは？AI Agent関連削除の影響と確認ポイント

Azure

Microsoft developer platformの「chore: Clean up unused Bicep resources」は、BicepとARM JSONテンプレートから未使用のAI Agent関連設定、AI Search Connection、不要なストレージコンテナー定義、複数の出力値を削除する更新です。既存環境をすぐ壊す変更とは限りませんが、デプロイ後のoutputsをCI/CDやアプリ設定に流し込んでいる場合は影響が出る可能性があります。まず確認すべきなのは、AZURE_AI_AGENT_ENDPOINT、AZURE_AI_AGENT_API_VERSION、AI_FOUNDRY_NAME、AI_FOUNDRY_RG_NAME、CONTAINER_INSTANCE_IPなどを自社のスクリプトや環境変数で参照していないかです。

今回の更新は、Microsoftのcontent-generation-solution-acceleratorリポジトリで2026年5月5日にマージされたPR #835に含まれ、リリースv2.4.3にも取り込まれています。PRの説明では、AI AgentとAI Search Connectionに関連する構成やリソース定義を、メインおよびカスタムのBicep/JSONインフラテンプレートから削除し、デプロイ構成を簡素化する目的だとされています。(GitHub)

目次

Microsoft developer platformのBicepリソース整理で何が変わったのか

今回の変更は、新機能追加ではなく「未使用リソースの整理」です。対象は主にinfra/main.bicep、infra/main_custom.bicep、infra/main.jsonの3ファイルです。GitHub上の変更内容では、main.bicepとmain_custom.bicepでそれぞれ40行削除、main.jsonで1行追加・69行削除が確認できます。(GitHub)

変更の中心は、以下の3点です。

変更点削除された主な要素確認すべきこと
AI Agent関連設定の削除azureAiAgentApiVersion、AZURE_AI_AGENT_ENDPOINT、AZURE_AI_AGENT_API_VERSIONアプリやCI/CDがこれらの値をoutputsから取得していないか
AI Search Connectionの削除aiSearchFoundryConnection、aiSearchConnectionNameAzure AI SearchとAI Foundryの接続をテンプレート任せにしていないか
不要なストレージ/出力の削除dataContainer、CONTAINER_INSTANCE_IPなどdataコンテナーやコンテナーIPを前提にした処理がないか

特に注意したいのは、「Azure上のリソースが必ず削除される」という単純な話ではない点です。BicepやARMテンプレートから定義が消えた場合でも、通常の増分デプロイではテンプレートに含まれない既存リソースはそのまま残ります。一方、Completeモードを使うと、テンプレートに含まれないリソースが削除対象になる可能性があります。Microsoft Learnでも、Incrementalモードではテンプレート外の既存リソースは変更されず、Completeモードではテンプレートにないリソースが削除されると説明されています。(Microsoft Learn)

削除されたAI Agent関連の項目

今回の更新では、Azure AI Agentサービス向けのAPIバージョン指定であるazureAiAgentApiVersionが削除されています。あわせて、AI AgentエンドポイントやAPIバージョンを出力するoutputsも削除されています。具体的には、main.bicepとmain_custom.bicepでAZURE_AI_AGENT_ENDPOINT、AZURE_AI_AGENT_API_VERSIONの出力が削除され、main.jsonにも同様の反映が行われています。(GitHub)

この変更で最も影響を受けやすいのは、テンプレートのデプロイ結果から環境変数を自動生成している構成です。たとえば、GitHub Actions、Azure DevOps、シェルスクリプト、PowerShellなどで次のような処理をしている場合は要注意です。

AZURE_AI_AGENT_ENDPOINT=$(az deployment group show ... --query properties.outputs.AZURE_AI_AGENT_ENDPOINT.value -o tsv)
AZURE_AI_AGENT_API_VERSION=$(az deployment group show ... --query properties.outputs.AZURE_AI_AGENT_API_VERSION.value -o tsv)

更新後のテンプレートでは、これらのoutputsが存在しないため、値が空になったり、スクリプトが失敗したりする可能性があります。

対応方針

AI Agent関連の値を使っていない場合は、基本的に大きな対応は不要です。ただし、デプロイパラメータファイルやCI/CD変数にazureAiAgentApiVersionが残っている場合は、不要な設定として削除しておくと管理が楽になります。

一方、アプリケーション側でAI Agentエンドポイントを明示的に必要としている場合は、次のどちらかを選びます。

状況推奨対応
AI Agent機能を使っていない参照している環境変数・outputs取得処理を削除する
AI Agent機能を独自に使っているBicepテンプレートとは別に、必要なエンドポイント取得方法を明示する
既存コードがoutputs前提デプロイ後処理を見直し、存在しないoutputsに依存しないよう修正する
将来的に再利用予定独自Bicepモジュールや別パラメータで管理するか検討する

ここでやってはいけないのは、「削除されたoutputsをそのまま戻せばよい」と短絡的に判断することです。PRの目的は未使用または非推奨要素の整理なので、戻す場合は自社アプリで本当に必要かを確認してからにしましょう。

AI Search Connectionの削除で確認すべきポイント

今回の変更では、AI SearchとAI Foundryプロジェクトの接続を表すaiSearchFoundryConnectionリソース定義も削除されています。削除対象のリソース型はMicrosoft.CognitiveServices/accounts/projects/connectionsで、接続カテゴリはCognitiveSearch、接続先はhttps://${aiSearchName}.search.windows.netという構成でした。 (GitHub)

PRの説明では、このAI Search Connectionリソース定義をmain.bicep、main_custom.bicep、生成済みARMテンプレートのmain.jsonから削除したとされています。(GitHub)

この変更は、検索インデックスそのものの削除ではありません。azureSearchIndexやAI Searchサービス全体が削除されたというより、AI Foundry側との「接続リソース」がテンプレート管理から外れたと見るのが適切です。

影響を受けやすい構成

次のような環境では、更新前後の動作確認を丁寧に行うべきです。

  • AI FoundryプロジェクトからAzure AI Searchを参照する処理を使っている
  • 初回デプロイ後に、接続設定が自動作成されることを前提にしている
  • 既存の検索接続をIaCで完全管理したい
  • テスト環境を毎回クリーンに作り直している
  • foundry-search-connection-...という名前をスクリプトで参照している

特に、検証環境を頻繁に作り直すチームでは、「以前はデプロイ直後に検索接続が存在したが、更新後は存在しない」という差分が発生する可能性があります。デプロイ後にAI Foundryやアプリケーションから検索機能を使う場合は、接続が別経路で作成されるのか、手動設定が必要なのかを確認してください。

dataストレージコンテナーの削除はどう見るべきか

ストレージ関連では、dataContainer変数と、それに対応するdataコンテナー定義が削除されています。一方、product-imagesやgenerated-imagesのコンテナーは残っています。PRの説明でも、未使用のaiSearchConnectionNameとdataContainer変数、関連するストレージコンテナー定義をBicepとJSONファイルから削除したとされています。(GitHub)

この変更で確認したいのは、アプリや運用スクリプトがdataというコンテナー名を直接参照していないかです。

たとえば、次のような処理がある場合は見直しが必要です。

az storage blob upload \
  --container-name data \
  --file ./seed/products.json \
  --name products.json

また、アプリケーション設定で次のような値を持っている場合も確認対象です。

STORAGE_DATA_CONTAINER=data
DATA_CONTAINER_NAME=data
AZURE_STORAGE_CONTAINER=data

既存のストレージアカウント内にdataコンテナーが残っている場合でも、今後の新規デプロイではテンプレートから作成されない可能性があります。新規環境、検証環境、本番復旧環境で同じ手順を使う場合は、dataコンテナーを本当に使っているかを確認し、必要であれば別途作成手順を用意してください。

outputs削除によるCI/CDへの影響

今回の更新は、リソース定義だけでなくoutputsの削除も含んでいます。outputsはAzureリソースそのものではありませんが、デプロイ後の自動化では非常に重要です。

削除されたoutputsのうち、特に確認したいのは次の項目です。

削除されたoutputs影響が出やすい場所確認方法
AI_FOUNDRY_NAMEアプリ設定、ログ出力、後続スクリプトgrep -R "AI_FOUNDRY_NAME" .
AI_FOUNDRY_RG_NAME別リソースグループ参照grep -R "AI_FOUNDRY_RG_NAME" .
AZURE_AI_AGENT_ENDPOINTAI Agent呼び出し設定環境変数、.env、GitHub Actions secretsを確認
AZURE_AI_AGENT_API_VERSIONAPI呼び出しバージョン指定APIクライアントの初期化処理を確認
CONTAINER_INSTANCE_IPACIへの直接アクセスIP固定前提の疎通確認や監視設定を確認

この種の変更では、Bicepのデプロイ自体が成功しても、後続の「値を取り出す処理」で失敗することがあります。たとえば、GitHub Actionsでoutputsを取得して.envへ書き出すステップがある場合、テンプレート更新直後にアプリ起動エラーへつながることがあります。

まず実行したい検索コマンド

リポジトリ全体で、削除された名前を検索してください。

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

Windows PowerShellなら、次のように確認できます。

Select-String -Path .\* -Pattern "AZURE_AI_AGENT_ENDPOINT","AZURE_AI_AGENT_API_VERSION","AI_FOUNDRY_NAME","AI_FOUNDRY_RG_NAME","CONTAINER_INSTANCE_IP","dataContainer","aiSearchFoundryConnection" -Recurse

検索結果がゼロであれば、影響は限定的と判断しやすくなります。結果が出た場合は、その参照が「実際に必要な処理」なのか「古い設定の残骸」なのかを切り分けましょう。

更新前に確認すべきチェックリスト

Microsoft developer platformのBicepテンプレートを使っているチームは、更新を取り込む前に以下を確認してください。

チェック項目判断基準対応
削除されたoutputsを参照しているかCI/CD、.env生成、アプリ設定で使っている参照削除または代替取得方法を用意
azureAiAgentApiVersionをパラメータ指定しているか.bicepparam、JSONパラメータ、GitHub Actions入力に残っている不要なら削除
AI Search接続をテンプレート作成に依存しているかデプロイ後にFoundry側の接続が必要別の作成手順や手動確認を追加
dataコンテナーを使っているかBlobアップロードや初期データ投入で参照必要なら明示的な作成手順を用意
Completeモードでデプロイしているか--mode CompleteやPowerShellの-Mode CompleteがあるWhat-ifを必ず実行し、削除対象を確認
生成済みmain.jsonを直接使っているかBicepではなくARM JSONをデプロイしている更新後のJSON差分も確認

特にCompleteモードは注意が必要です。Microsoft Learnでは、Completeモードを使う場合は意図しない削除を避けるためWhat-if操作を使うよう案内されています。(Microsoft Learn)

安全に取り込むための実務手順

本番環境へ直接反映する前に、次の順序で確認すると失敗を減らせます。

変更差分をローカルで確認する

まず、更新前後のテンプレート差分を確認します。見るべきポイントは「リソース」「パラメータ」「outputs」の3つです。

git diff HEAD~1 -- infra/main.bicep infra/main_custom.bicep infra/main.json

テンプレートをフォークしている場合は、Microsoft側の変更を取り込んだあと、自社カスタマイズと衝突していないかを確認します。特にmain_custom.bicepを編集している環境では、削除されたoutputsを独自処理で使っているケースがあります。

BicepからJSONを再生成して確認する

Bicepを編集している場合は、生成済みARMテンプレートとの整合性も確認しましょう。Microsoft Learnでは、bicep buildコマンドはBicepファイルをJSON ARMテンプレートへ変換するコマンドとして説明されています。(Microsoft Learn)

bicep build infra/main.bicep
bicep build infra/main_custom.bicep

生成後にmain.jsonの差分が想定どおりかを確認します。自社でmain.jsonを直接配布・デプロイしている場合、この確認は必須です。

What-ifでAzure側の変更を確認する

次に、Azure Resource ManagerのWhat-ifを使って、デプロイした場合の変更を確認します。Microsoft Learnでは、What-ifはデプロイ前にリソースがどのように変わるかを予測し、既存リソースには変更を加えない操作だと説明されています。(Microsoft Learn)

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

ここで確認すべきなのは、作成・変更・削除の一覧です。特にDeleteが出ている場合は、Completeモードやデプロイ対象スコープを確認してください。

検証環境でデプロイ後処理まで確認する

Bicepのデプロイ成功だけで判断しないでください。今回のようにoutputsが削除される変更では、デプロイ後のアプリ設定反映、シークレット更新、コンテナー起動、疎通確認で問題が出ることがあります。

最低限、次の流れまで検証しましょう。

手順確認内容
Bicepデプロイエラーなく完了するか
outputs取得CI/CDで参照している値が存在するか
アプリ起動環境変数不足で落ちないか
検索機能Azure AI Searchを使う処理が動くか
ストレージ処理Blobアップロードや画像保存が想定どおりか
監視・疎通ACIのIPではなくFQDNや別の接続方式で確認できるか

移行時に起きやすい失敗

古いパラメータを残したままデプロイする

azureAiAgentApiVersionがパラメータファイルに残っている場合、デプロイツールやバリデーション設定によっては「テンプレートに存在しないパラメータ」として扱われる可能性があります。必ず.bicepparam、JSONパラメータ、CI/CDの入力値を確認してください。

outputsが消えたことに気づかない

Bicepテンプレートのリソース削除は目立ちますが、outputs削除は見落とされがちです。アプリケーションの設定値をAzureデプロイのoutputsから自動取得している場合、更新後に空文字やnullが入ることがあります。

対策は、outputs取得処理に「存在チェック」を入れることです。

value=$(az deployment group show \
  --resource-group <resource-group-name> \
  --name <deployment-name> \
  --query "properties.outputs.AZURE_AI_AGENT_ENDPOINT.value" \
  -o tsv 2>/dev/null)

if [ -z "$value" ]; then
  echo "AZURE_AI_AGENT_ENDPOINT is not available. Skip AI Agent configuration."
fi

dataコンテナーが新規環境に作られない

既存環境ではdataコンテナーが残っているため問題に気づきにくいことがあります。しかし、新しく環境を作ったときに、初期データ投入スクリプトが失敗する可能性があります。

この場合は、dataコンテナーが本当に必要かを確認してください。必要なら、Bicepへ独自に戻すのではなく、用途を明確にしたうえで専用のコンテナー定義や初期化スクリプトを管理するのが安全です。

ACIのIPアドレスを前提にしている

CONTAINER_INSTANCE_IPのoutputが削除されたため、コンテナーインスタンスのIPアドレスを後続処理で参照している場合は見直しが必要です。更新後もCONTAINER_INSTANCE_FQDNは残っているため、非プライベートネットワーク構成ではFQDN参照へ切り替えられる可能性があります。ただし、プライベートネットワークや独自ネットワーク構成では、環境ごとの確認が必要です。

対応が必要な人・不要な人

今回の変更は、すべての利用者に大きな作業を求めるものではありません。影響は、テンプレートの使い方によって変わります。

利用状況対応優先度理由
これから新規デプロイする中新テンプレートで作られない接続・コンテナーがあるため
既存環境で増分デプロイする低〜中既存リソースは残る可能性が高いが、outputs参照は要確認
Completeモードでデプロイする高テンプレート外リソースが削除対象になる可能性がある
CI/CDでoutputsを使っている高削除されたoutputs参照でパイプラインが失敗しやすい
AI AgentやAI Search接続を独自利用している高接続やエンドポイント取得方法の再確認が必要
サンプルを軽く試しているだけ低使っていない機能の整理で済む可能性が高い

実務では、まず「削除された名前を参照しているか」を検索し、次にWhat-ifでAzure側の変化を確認する流れが最短です。

今回の更新を前向きに活かすポイント

今回の「Clean up unused Bicep resources」は、一見すると地味な整理です。しかし、インフラテンプレートでは未使用のパラメータやoutputsが残るほど、運用時の判断ミスが増えます。

たとえば、使われていないAZURE_AI_AGENT_ENDPOINTがoutputsに残っていると、開発者は「AI Agent機能がこのテンプレートで正式に管理されている」と誤解しやすくなります。使われていないdataコンテナーが自動作成されると、何のための保存先なのか分からないまま運用対象が増えます。

つまり今回の変更は、単なる削除ではなく、テンプレートの責務を整理する更新です。自社でフォークやカスタマイズをしている場合も、この機会に次の観点で棚卸しすると効果があります。

  • 使っていないパラメータを残していないか
  • outputsをアプリ設定として本当に使っているか
  • リソース名をスクリプトに直接書いていないか
  • 初回デプロイと既存環境更新で手順が分かれていないか
  • Bicepと生成済みARM JSONの差分を管理できているか

まず取るべき行動

Microsoft developer platformの今回のBicepリソース整理を取り込む場合は、最初に削除されたパラメータ、リソース、outputsを自社リポジトリ内で検索してください。次に、検証環境でaz deployment group what-ifを実行し、意図しない削除や変更が出ていないかを確認します。

特に、AZURE_AI_AGENT_ENDPOINT、AZURE_AI_AGENT_API_VERSION、AI_FOUNDRY_NAME、AI_FOUNDRY_RG_NAME、CONTAINER_INSTANCE_IP、dataContainer、aiSearchFoundryConnectionを参照している環境では、更新前にCI/CDとアプリ設定を見直しましょう。

今回の変更は、未使用リソースを減らしてテンプレートを分かりやすくするための更新です。ただし、outputsや接続リソースに依存しているチームにとっては、デプロイ後処理の修正が必要になる可能性があります。安全に進めるなら、「検索で依存箇所を洗い出す」「What-ifで差分を見る」「検証環境でデプロイ後処理まで確認する」の3ステップを実行してから本番へ反映してください。

Azure
Azure ARMテンプレート Bicep Microsoft developer platform AI Foundry

この記事を書いた人

佐藤健司のアバター 佐藤健司

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

関連記事

コメント

コメントする

目次