AzureRM 5.12.0でAPIMのサンプリング0送信を修正：更新後のログ減少を検証する

結論：プロバイダー更新を監視設計の変更として受け入れる

編集上の判断：azurerm_api_management_diagnosticでsampling_percentage=0を指定している構成を先に抽出します。設定値をAzureに正しく渡す修正でも、従来の実値と異なれば、適用後の観測結果は変わり得ます。Terraformのplanだけで完了とせず、Azure側設定の読取りとテストリクエストの到着確認までを受入条件にすることを提案します。

編集上の設計提案：通常リクエストの統計的な観測と、障害調査・監査で必要な証跡を分けて設計します。ログ件数が減っただけで、業務リクエストやエラーが減ったとは判断しません。本記事は個別環境の設計保証や法的助言を行いません。実装適用には検証環境での事前テスト、および委託・支援を含む業務範囲の確認が必要です。

背景と技術的要因：数値0と未設定の扱いが送信結果を分けた

確認済み事実：HashiCorp公式のAzureRM 5.12.0リリースノートは、azurerm_api_management_diagnosticでsampling_percentageが0の場合に正しく送信する修正を掲載しています。対応するPR #33718は2026-10-26にマージされ、従来はgetOk()が0に対して0,falseを返し、値を無視していたと説明しています。

編集上の技術評価：この説明から、設定ファイル上の0と、Azureが実際に保持している値を同一視しない点検が必要です。ただし、参照資料だけでは全旧バージョンの影響範囲、各環境で残る値、実際の収集量までは確定できません。旧動作が必ず100%になる、更新するだけで全環境のログが消える、といった一般化は行いません。

日付・数値・対象：修正版公開日と環境への適用日を分ける

確認済み事実：修正版のリリース公表日は2026-10-29、対象はAzureRMプロバイダー5.12.0のazurerm_api_management_diagnosticとsampling_percentageです。PRのマージ日は2026-10-26であり、製品のリリース日とは異なります。環境への一律適用日、非推奨化期日、影響する最初の旧版、PR本文の最終更新日は確認できずnullです。本記事の公開日・確認日は2026-11-01です。

確認済み事実：日本語RESTリファレンスのDiagnostic - Create Or UpdateはAPIバージョン2024-05-01を示し、properties.sampling.percentageの範囲は0から100、samplingTypeはfixedです。alwaysLogのallErrorsはサンプリング設定に関係なくエラーを記録するとされています。これはAPI仕様の参照版であり、AzureRM 5.12.0内部の採用APIバージョンを確認したものではありません。

確認済み事実：Microsoft Learn日本語のApplication Insights統合資料は、サンプリング0%では記録しないと説明する一方、エラーを常に記録する設定も案内しています。同資料の表示更新日は2026-09-17です。REST参照ページの公表日・更新日は確認できずnullとし、API版の日付で代用しません。

設計・実装：Terraform設定、Azure実値、収集先を照合する

編集上の確認事項：実行環境のterraform providersと.terraform.lock.hclを確認し、CI/CDで使用するプロバイダー版を記録します。既存のバージョン制約・メジャー更新方針に従い、5.12.0への更新を検証してください。本記事は他のメジャー版からの互換性を保証するものではなく、この一件の修正だけを理由に未検証の一括更新は行いません。

編集上の提案：更新前に診断リソースID、sampling_percentage、ロガー参照、Azure側のsampling.percentageとalwaysLogを保存します。値が0、未設定、0以外であるケースを区別し、plan、承認したapply、適用後の読取りを対応付けます。Terraformのstateだけを最終的な実設定の証明とせず、Azure側の値も確認します。

確認済み事実：Microsoft Learnは、個別APIのロガーが既定では全APIのロガーを上書きすると説明しています。編集上の提案：本記事の修正対象と個別APIレベルの設定を混同せず、APIごとの上書き・ロガー宛先も棚卸しします。Bicep・ARMテンプレートやポータルから同じリソースを変更している場合は、設定の管理元を確定し、競合する変更を避けます。

運用・監視・DR・責任分界：ログ減少を正常系とエラーに分けて評価する

編集上の検証手順：検証環境で識別可能なテストIDを付け、成功リクエストと意図したエラーを別々に送ります。承認したサンプリング値とエラー記録の設定に対して、Application Insightsへの到着、遅延、アラート発火を比較してください。allErrorsが有効な状態で、サンプリング0だけを全テレメトリ停止の保証として扱わないことが要点です。

編集上の運用提案：ログ件数を分母とするエラー率や、ログがないことを条件にしたアラートは再評価します。ゲートウェイの要求数・エラー指標や独立した疎通監視も使い、収集設定の変更と業務障害を切り分けてください。費用削減量や性能改善率は実測前に約束せず、ログ量と業務トラフィックを同じ期間で比較します。

編集上のDR・責任分界整理：復旧先のTerraform実行版、診断値、ロガー宛先、エラー記録、通知経路を再現試験します。プロバイダーを旧版に戻すだけでAzure側の以前の値も復元されるとはみなさず、承認済みの監視設定へ戻す手順を用意します。IaC担当、API運用担当、監視担当、委託先の間で、変更承認・試験・証跡保存の担当を確定してください。