【Terraform】Azure OpenAIからAI Foundryへの移行完全ガイド：ダウンタイムゼロの「接続」アーキテクチャ

Azure Portalの「アップグレード」がTerraformでは危険な理由

リソースが再作成されると、本番環境では以下の致命的な問題が連鎖します。

• エンドポイントURLの変更：アプリケーション側の接続設定を緊急更新する必要があります。
• アクセスキーの無効化：既存のAPIキーが即座に失効し、サービスダウンが発生します。
• デプロイ済みモデルの消失：GPT-4oなどのモデルデプロイ設定がすべて削除されます。
• tfstateの不整合：Terraformのステート管理が壊れ、以後のplan/applyが不安定になります。

したがって、とるべき戦略は「リソースの変換」ではなく、「既存リソースへの接続（Integration）」です。

推奨戦略：「Hub & Spoke」アーキテクチャによる統合

Azure AI Foundryの本質は、既存のAIサービスを置き換えるものではなく、それらを統合管理する「ハブ」です。既存のAzure OpenAIリソース（kind="OpenAI"）には一切手を加えず、その外側に管理層としての「AI Hub」と「AI Project」を構築し、そこから既存リソースを参照（Link）させる構成が正解です。

【実践】Terraformによる移行実装コード

azurerm プロバイダー（v4.0系以上推奨）と、細かい設定を補完する azapi プロバイダーを併用した実装例を紹介します。

1 プロバイダー設定

AI Foundry関連の新しいリソースに対応するため、azurerm はv4.0以上を使用し、Connection設定のために azapi を定義します。

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = ">= 4.0.0"
    }
    azapi = {
      source  = "Azure/azapi"
      version = "~> 1.13"
    }
  }
}

2 AI Hub と Project の作成

既存のOpenAIリソースとは別に、新規にHubとProjectを作成します。v4.0系では専用リソース azurerm_ai_foundry が利用可能です。Hub作成には Storage Account・Key Vault・Application Insights の依存リソースが必要な点に注意してください。

# AI Hub (管理プレーン)
resource "azurerm_ai_foundry" "hub" {
  name                    = "hub-foundry-prod"
  location                = azurerm_resource_group.example.location
  resource_group_name     = azurerm_resource_group.example.name

  storage_account_id      = azurerm_storage_account.foundry_sa.id
  key_vault_id            = azurerm_key_vault.foundry_kv.id
  application_insights_id = azurerm_application_insights.foundry_ai.id

  identity {
    type = "SystemAssigned"
  }
}

# AI Project (作業プレーン)
resource "azurerm_ai_foundry_project" "project" {
  name               = "prj-genai-app-01"
  location           = azurerm_resource_group.example.location
  ai_services_hub_id = azurerm_ai_foundry.hub.id
}

3 【重要】既存リソースとの接続 (Connection)

ここが移行の肝です。AI Hubに対して「既存のOpenAIリソースを使いたい」という設定を投入します。現状、この部分は azapi_resource を用いてREST APIを直接叩くのが最も安定的かつ柔軟です。

resource "azapi_resource" "openai_connection" {
  type      = "Microsoft.MachineLearningServices/workspaces/connections@2024-04-01-preview"
  name      = "conn-existing-openai"
  parent_id = azurerm_ai_foundry.hub.id

  body = jsonencode({
    properties = {
      category      = "AzureOpenAI"
      target        = azurerm_cognitive_account.existing_openai.endpoint
      authType      = "AAD"  # Managed Identity認証 (キー管理不要)
      isSharedToAll = true
      metadata = {
        ResourceId = azurerm_cognitive_account.existing_openai.id
      }
    }
  })

  depends_on = [azurerm_role_assignment.hub_openai_contributor]
}

4 権限の付与 (RBAC)

AI HubのManaged Identityが既存のOpenAIリソースを操作できるよう、適切なロールを割り当てます。depends_on で権限付与を先行させることが重要です。

resource "azurerm_role_assignment" "hub_openai_contributor" {
  scope                = azurerm_cognitive_account.existing_openai.id
  role_definition_name = "Cognitive Services OpenAI Contributor"
  principal_id         = azurerm_ai_foundry.hub.identity.principal_id
}

よくある質問（FAQ）

まとめ：IaCにおける「Link & Extend」戦略

Azure AI Foundryへの移行は、既存リソースを破壊することなく、管理レイヤーを追加する「Link & Extend（接続と拡張）」のアプローチで安全に実現できます。

1. 既存の OpenAIリソースはそのまま 維持する（kind="OpenAI" を変更しない）
2. Terraformで AI Hub / Project を新規作成する（azurerm_ai_foundry）
3. Connectionリソース で両者を紐付ける（azapi_resource + AAD認証）
4. RBACで 最小権限の原則 を守りながら権限を付与する

この手順を踏むことで、本番環境の安定稼働を守りつつ、最新のAIプラットフォームの恩恵（Prompt Flowやモデル評価機能など）を即座に享受できます。次はTerraformのチーム運用体制についても整備してみてください。

インフラをコードで管理するIaCは、再現性・安全性の面で圧倒的に優れています。VPS環境でTerraformの検証環境を手軽に用意したい場合は、以下のサービスもチェックしてみてください。