AI基盤の拡大に伴い、「インフラドリフト」——実際の状態と定義した望ましい状態のズレ——が静かに組織のリスクを高めている。Microsoftが公開した実践ガイドは、マルチリポジトリ構成のAzure AIインフラを「自己修復型」に設計するアーキテクチャパターンを詳解する。単なる運用ベストプラクティスではなく、スケールするAI基盤の信頼性を根本から支える設計思想として注目したい。

インフラドリフトとは何か

IaC（Infrastructure as Code）が普及し、TerraformやBicepでインフラを定義する組織が増えた。しかし「コードで定義した」だけでは安心できない。誰かが緊急対応でAzureポータルから直接設定を変更した、自動スケールの過程で意図しないリソースが生まれた、APIバージョンがサイレントに更新された——こうした積み重ねが「ドリフト」を生む。

AI基盤では特に深刻だ。Azure OpenAIのモデルバージョン、Azure AI Foundryのエンドポイント設定、ネットワークルール、マネージドID（Managed Identity）の権限スコープ。どれか一つがズレれば、モデルの応答品質が下がるだけでなく、セキュリティポスチャが崩れる可能性もある。

マルチリポジトリ構成が複雑さを倍増させる

大規模AIインフラが必然的にマルチリポジトリ構成を取ることが問題を複雑にする。

  • 基盤リポジトリ: VNet、サブネット、Entra IDの構成
  • AIプラットフォームリポジトリ: Azure AI Foundry、Azure OpenAI、Cognitive Services
  • アプリケーションリポジトリ: モデルを呼び出すアプリ層

これらが独立したライフサイクルで動く。あるリポジトリの変更が別のリポジトリの期待値を崩す「クロスリポジトリドリフト」は、単純な差分チェックでは検知できない。

自己修復アーキテクチャの3つのパターン

ガイドが示す自己修復の主要パターンは次の3軸だ。

1. GitOpsによる継続的調整

「コードリポジトリが唯一の真実（Single Source of Truth）」という原則をAzure環境に適用する。Azure Arc + Flux CDなどを使い、Gitの状態から環境が逸脱したら自動的に再適用する。人手による修正は「PRを通してコードを変更する」という形に統一される。

2. Azure PolicyとDeployment Stacksの連携

Azure Policyのコンプライアンス評価を「検知」として使い、非準拠リソースにはDeployment Stacksで管理された状態への強制ロールバックをかける。ネットワーク設定や診断ログのように「いつの間にか消えている」パターンに特に有効だ。

3. カスタム状態スキャナー＋Event Grid連携

よりきめ細かい要件には、Azure Functionsで定期的な状態スキャナーを実装し、ドリフト検知をEvent Gridに発行。下流のLogic Apps / Azure Automation Runbookが自動修復を実行するパターンが示されている。

実務への影響

日本のエンタープライズでAzure AIを本番展開するチームにとって、実践ポイントは3つある。

① マネージドIDの権限スコープをドリフト監視の対象に含める 「誰が何にアクセスできるか」はAI基盤のセキュリティの根幹だ。最小権限原則（PoLP）から逸脱したマネージドIDは、気づかないうちにセキュリティホールになる。Entra ID + Azure Policyでの定期監査をデプロイパイプラインに組み込むことを推奨する。

② 「修復前に通知」ではなく「修復後に通知」の設計に変える 多くのチームは「異常を検知 → 担当者へアラート → 人間が修正」というフローを取る。しかしAI基盤の規模が大きくなると人間はボトルネックになる。「修復を先に実行し、内容をレポートする」設計に転換することで、オンコール担当者への疲弊を防ぎつつ信頼性を向上できる。

③ Deployment Stacksで「孤児リソース」を防ぐ Azure AI Foundryやその周辺リソースを手動で削除・再作成を繰り返す運用では、紐付きのストレージアカウントやKey Vaultが孤児化しやすい。Deployment Stacksを使えばリソースのライフサイクルをスタック単位で管理でき、削除漏れによるコスト増やセキュリティリスクを防げる。

筆者の見解

「今動いているから大丈夫」という感覚が危険なのは、インフラの世界では昔からの常識だ。しかしAIの時代には、その危険度が一段上がっている。AIモデルを動かすインフラは、従来のWebアプリとは比べ物にならないほど設定の微妙な差異が出力品質に直結する。エンドポイントのモデルバージョン、レート制限の設定値——これらが「なんとなく精度が落ちた」「エラー率が上がった」という霧の中の原因になりうる。

今回のガイドが示すアーキテクチャは、GitOps・Azure Policy・Deployment Stacksの組み合わせであり、決して派手な技術ではない。しかし、標準的で再現性のある仕組みこそが大規模AI基盤の信頼を支える。奇をてらった構成は後任者が理解できず、結果としてドリフトの温床になる。道のド真ん中を歩く構成が、長期的にもっとも強い。

もう一点、見逃せない観点がある。自己修復アーキテクチャが本当に機能するためには、修復を実行するマネージドIDやサービスプリンシパル——いわゆるNHI（Non-Human Identity）——が適切な権限を持ち続けることが前提になる。自己修復の自動化と、それを支えるNHI管理は表裏一体だ。この視点を欠いた設計は、「修復を実行するはずのIDが権限を失って止まる」という本末転倒な状況を招く。

Azureプラットフォームとしての成熟度は、こうしたアーキテクチャパターンの充実に表れていると思う。AI基盤を安全に大規模運用するための地盤は着実に整いつつある。この方向性は正しい。あとはこの仕組みを実際に組み込む側——私たちエンジニア——が腰を上げるだけだ。

出典: この記事は From Drift to Self-Healing: Building a Multi-Repo Azure AI Infrastructure You Can Actually Trust の内容をもとに、筆者の見解を加えて独自に執筆したものです。