Azure AI FoundryをTerraformで作成・管理したい場合、今回の公式情報で押さえるべき結論は明確です。Microsoft Foundryリソース、プロジェクト、モデルデプロイ、接続をInfrastructure as Codeとして管理できる手順が整理され、AzAPI ProviderとAzureRM Providerの使い分けが重要になりました。 既存環境をAzureポータルからTerraformコードとしてエクスポートできる点も、管理者にとって大きな確認ポイントです。Microsoft Learn上では、このTerraform関連ページは2026年5月20日最終更新として表示されています。(Microsoft Learn)
特に注意したいのは、単に「TerraformでAzure AI Foundryを作る方法」だけではありません。RBACロール名の変更、Terraform stateファイルの保護、Private EndpointやCMKなどのセキュリティ設定、既存リソースをTerraform管理へ移す際のimport作業まで含めて確認する必要があります。この記事では、Azure AI FoundryをTerraformで展開する管理者・開発者向けに、変更点、影響範囲、実務で確認すべき設定を整理します。
Azure AI Foundryの「Use Terraform to create Microsoft Foundry」で押さえるべき変更点
今回の公式情報で重要なのは、Azure AI Foundryを「ポータルで個別に作るリソース」ではなく、Terraformで継続管理する対象として扱いやすくなった点です。
公式ドキュメントでは、Terraformを使ってMicrosoft Foundryのリソース、プロジェクト、デプロイ、接続を自動化できると説明されています。さらに、すでにAzureポータルで作成済みのFoundryリソースがある場合は、設定をTerraformコードとしてエクスポートできることも示されています。(Microsoft Learn)
実務上の変更点は、次の4つに分けて考えると分かりやすくなります。
| 確認ポイント | 内容 | 実務上の意味 |
|---|---|---|
| Terraformによる作成対象 | Foundryリソース、プロジェクト、モデルデプロイ、接続など | 開発・検証・本番環境をコードで再現しやすくなる |
| Providerの選択 | AzAPI ProviderとAzureRM Providerの両方が利用可能 | プレビュー機能や詳細設定を使うかで選択が変わる |
| 既存環境の移行 | AzureポータルからTerraformコードをエクスポート可能 | 手作業で作った環境をIaC管理へ移しやすい |
| セキュリティ確認 | Terraform state、RBAC、ネットワーク、暗号化を確認 | コード化により設定漏れや権限過多が表面化しやすい |
ここで誤解しやすいのは、「Terraform対応＝すべて自動で安全に構成される」という見方です。Terraformは構成を再現する仕組みであり、セキュリティ設計そのものを代替するものではありません。組織のルールに合わせて、RBAC、Private Endpoint、CMK、Azure Policyなどを明示的に組み込む必要があります。
対象者は管理者、開発者、MLOps担当者
この公式情報の影響を受けるのは、Azure AI Foundryを使うすべてのユーザーではありません。主に影響が大きいのは、環境構築や運用標準化に関わる担当者です。
| 対象者 | 確認すべきこと |
|---|---|
| Azure管理者 | RBAC、サブスクリプション、リソースグループ、ネットワーク、Azure Policy |
| AIアプリ開発者 | Foundryプロジェクト、モデルデプロイ、接続、認証方式 |
| MLOps / Platform Engineering担当 | Terraformモジュール化、環境分離、state管理、CI/CD適用 |
| セキュリティ担当 | APIキー利用、Managed Identity、Private Endpoint、CMK、監査ログ |
| 既存Foundry利用チーム | ポータル作成済みリソースのエクスポート、Terraform import、差分管理 |
小規模な検証だけなら、公式サンプルを使ってリソースを作成するだけでも十分です。一方、社内標準環境や本番環境に展開する場合は、Terraformコードをそのまま流用するのではなく、命名規則、タグ、リージョン、SKU、ネットワーク、暗号化、権限設計を自社の基準に合わせて修正する必要があります。
AzAPI ProviderとAzureRM Providerの使い分け
Azure AI FoundryをTerraformで作成する際に、最初に判断すべきなのがProviderの選択です。公式情報では、AzAPI ProviderとAzureRM Providerの両方が利用できる一方、対応範囲に差があることが示されています。AzAPI Providerはプレビュー機能を含むFoundryのコントロールプレーン構成にアクセスでき、AzureRM Providerは中核的な管理機能に限定されます。(Microsoft Learn)
| やりたいこと | AzAPI Provider | AzureRM Provider |
|---|---|---|
| リソースグループ作成 | 対応 | 対応 |
| Foundryリソース作成 | 対応 | 対応 |
| モデルデプロイ構成 | 対応 | 対応 |
| Foundryプロジェクト構成 | 対応 | 対応 |
| ナレッジやツールへの接続構成 | 対応 | 非対応 |
| capability hostなど高度なツール構成 | 対応 | 非対応 |
判断基準はシンプルです。
まずAzureRM Providerで足りるか確認し、接続や高度なFoundry機能までTerraformで管理したい場合はAzAPI Providerを検討する、という順序が実務では扱いやすいです。
ただし、AzAPI ProviderはARMリソース定義に近い形で書くため、AzureRM Providerよりも記述が抽象的になりやすい場面があります。チーム内で保守するなら、どちらを採用するかをリポジトリ単位で統一し、混在させる場合は責任範囲を明確にしておくべきです。
Provider選定の実務例
検証環境で「Foundryリソース、プロジェクト、gpt-4oのデプロイだけ作りたい」場合は、AzureRM Providerでも始めやすいでしょう。
一方、エージェント、ツール接続、ナレッジ連携、プレビュー機能を含む構成までコード化したい場合は、AzAPI Providerの方が適しています。
本番運用では、次のように分けると判断しやすくなります。
| 環境 | 推奨しやすい選択 | 理由 |
|---|---|---|
| 個人検証 | AzureRM Provider | Terraform初心者でも読みやすい |
| チーム開発 | AzureRM ProviderまたはAzAPI Provider | 管理対象の範囲次第 |
| エンタープライズ本番 | AzAPI Providerを含めて検討 | 接続、セキュリティ、高度な構成を統制しやすい |
| 既存環境の移行 | エクスポート結果に合わせて選択 | AzureRM / AzAPI形式で出力を確認できる |
Terraformで作成される主な構成要素
公式サンプルでは、Azure AI Foundryの基本構成として、リソースグループ、Foundryリソース、モデルデプロイ、Foundryプロジェクトを作成する流れが示されています。AzAPI Providerの例ではMicrosoft.CognitiveServices/accounts@2025-06-01を使い、kind = "AIServices"、システム割り当てマネージドID、プロジェクト管理の有効化、カスタムサブドメインなどを設定しています。(Microsoft Learn)
AzureRM Providerの例では、azurerm_cognitive_accountでFoundryリソースを作成し、project_management_enabled = trueやcustom_subdomain_nameを指定したうえで、azurerm_cognitive_account_projectとazurerm_cognitive_deploymentを使う構成が示されています。(Microsoft Learn)
実務では、次の項目を必ず確認してください。
| 設定項目 | 確認内容 | 注意点 |
|---|---|---|
location | 利用リージョン | モデル、CMK、ネットワーク要件と整合させる |
sku / sku_name | 料金・性能プラン | 検証と本番で同じにしない場合は変数化する |
| Managed Identity | SystemAssignedなど | RBACやKey Vaultアクセスに関係する |
| プロジェクト管理 | allowProjectManagementまたはproject_management_enabled | Foundryプロジェクト利用に必要 |
| カスタムサブドメイン | customSubDomainNameまたはcustom_subdomain_name | 認証やエンドポイント設計に影響する |
| モデルデプロイ | モデル名、バージョン、SKU、capacity | 利用可能リージョンやクォータの確認が必要 |
| タグ | 部門、環境、コスト管理 | Azure Policyで必須化している組織は漏れに注意 |
特にカスタムサブドメインやプロジェクト管理の有効化は、後から簡単に変更できる設定として扱わない方が安全です。環境作成前に、命名規則、サブスクリプション、リソースグループ、DNS、認証方式を決めておきましょう。
Terraform実行時の基本手順
公式手順では、Terraformの初期化、実行計画の作成、適用、デプロイ確認という一般的な流れが示されています。terraform init -upgradeでProviderプラグインを初期化し、terraform plan -out main.tfplanで実行計画を作成し、確認後にterraform apply main.tfplanで適用します。(Microsoft Learn)
実務では、次の順序で進めると失敗しにくくなります。
| 手順 | コマンド例 | 確認すること |
|---|---|---|
| 初期化 | terraform init -upgrade | Providerが想定バージョンで取得されるか |
| 構文確認 | terraform validate | HCLの記述ミスがないか |
| 差分確認 | terraform plan -out main.tfplan | 作成・変更・削除対象が期待通りか |
| 適用 | terraform apply main.tfplan | レビュー済みplanを適用しているか |
| 状態確認 | terraform state list | 作成されたリソースがstateに入っているか |
| 出力確認 | terraform output | エンドポイントやIDが想定通りか |
本番環境では、terraform applyを開発者の手元で直接実行するより、CI/CDでplanレビューを挟む運用が望ましいです。特にAI関連リソースは、モデルデプロイや接続先の変更がアプリケーション動作に直結します。plan結果をPull Requestに添付し、管理者またはリード開発者が確認してから適用する流れにしましょう。
既存のAzure AI FoundryリソースをTerraform管理へ移すときの注意点
すでにAzureポータルでAzure AI Foundryを作成している組織では、「既存環境を壊さずTerraform管理へ移せるか」が重要です。
公式情報では、AzureポータルのExport templateからTerraformタブを選び、AzureRMまたはAzAPI形式のTerraformコードを確認・ダウンロード・コピーできると説明されています。エクスポートにはネットワークルール、ID構成、プロジェクト関連付けなどの現在設定が含まれる一方、一部リソースタイプでは完全なエクスポートに対応せず、警告や手動補完が必要になる可能性があります。(Microsoft Learn)
既存リソースを移行する場合は、次の流れで進めます。
| フェーズ | 作業 | 失敗しやすいポイント |
|---|---|---|
| 現状確認 | ポータルで現在の構成を確認 | 手作業変更が多いと差分の理由が分からなくなる |
| エクスポート | Terraform形式でテンプレートを出力 | 不完全なプロパティを見落とす |
| コード整理 | サブスクリプションID、リソースID、名前を変数化 | 固定値のまま別環境へ流用してしまう |
| import | 既存リソースをTerraform stateへ取り込む | import前にapplyして重複作成しようとする |
| plan確認 | 差分が意図通りか確認 | 既存設定が削除される差分に気づかない |
| 運用開始 | 以後の変更をTerraform経由に統一 | ポータル変更とTerraform変更が競合する |
特に重要なのは、エクスポートしたコードをそのまま本番適用しないことです。公式ドキュメントでも、ハードコードされたサブスクリプションID、リソースグループ名、リソースIDをTerraform変数に置き換え、不要なプロパティやスコープ外リソース参照を調整し、組織のセキュリティ要件に合わせて設定を追加するよう案内されています。(Microsoft Learn)
Terraform import前に確認すべきこと
既存リソースをTerraform stateに取り込む前に、最低限次の点を確認してください。
- 対象リソースのAzureリソースIDを正確に取得しているか
- Terraformコード内のリソース名とimport先アドレスが一致しているか
terraform planで削除や再作成が発生しないか- ネットワーク、ID、暗号化、タグがエクスポート結果に含まれているか
- ポータルでの直接変更を今後どう扱うか決めているか
ありがちな失敗は、importせずにterraform applyしてしまい、既存リソースとは別に新規作成しようとするケースです。既存環境を管理対象にする場合は、「コードを書く」だけでなく「stateに取り込む」作業が必要です。
RBACロール名変更の影響を確認する
管理者が必ず確認すべきなのがRBACです。公式情報では、Foundry RBACロールが最近リネームされ、Foundry User、Foundry Owner、Foundry Account Owner、Foundry Project Managerは、以前のAzure AI User、Azure AI Owner、Azure AI Account Owner、Azure AI Project Managerに相当すると説明されています。ロールIDと中核的な権限は変更されていません。(Microsoft Learn)
この変更は、TerraformやAzure CLIでロール割り当てを自動化している環境に影響します。表示名を前提にしているスクリプトやドキュメントでは、移行期間中に旧名と新名が混在する可能性があります。
公式ドキュメントでは、ロール名変更の展開中に問題を避けるため、コードではロール名ではなくロール定義IDを使うことが推奨されています。(Microsoft Learn)
| 旧名称 | 新名称 | 実務での確認ポイント |
|---|---|---|
| Azure AI User | Foundry User | 開発者やプロジェクト利用者向け |
| Azure AI Owner | Foundry Owner | 強い権限を持つため割り当て対象を限定 |
| Azure AI Account Owner | Foundry Account Owner | リソースやプロジェクト管理者向け |
| Azure AI Project Manager | Foundry Project Manager | プロジェクト作成・管理担当者向け |
実務では、次の対応を優先してください。
- Terraform、Azure CLI、PowerShellでロール名を文字列指定していないか確認する
- 可能であればロール定義IDを使う
- 社内手順書の旧ロール名を更新する
- Microsoft Entraグループ単位で割り当て、個人への直接付与を減らす
- 開発者には必要最小限のFoundry Userを基本にする
また、公式RBACドキュメントでは、キー認証を使うとロール制限なしのフルアクセスになり得るため、より細かなアクセス制御にはMicrosoft Entra ID認証が推奨されています。(Microsoft Learn) TerraformでdisableLocalAuthや認証設計を扱う場合は、セキュリティ方針と矛盾しないように確認しましょう。
Terraform stateファイルは機密情報として扱う
TerraformでAzure AI Foundryを管理する場合、stateファイルの扱いは重要です。公式情報でも、Terraform stateファイルには機密値が含まれる可能性があるため、チーム利用では安全なバックエンドとアクセス制御を使うよう注意されています。(Microsoft Learn)
ローカルPCにterraform.tfstateを置いたまま運用すると、次のようなリスクがあります。
| リスク | 具体例 | 対策 |
|---|---|---|
| 機密情報の漏えい | 接続情報やリソース属性がstateに残る | Azure Storageなどのリモートバックエンドを使う |
| 同時実行による競合 | 複数人が同じ環境を変更 | state lockを利用する |
| 変更履歴の不透明化 | 誰がどの構成を変更したか分からない | CI/CDとレビュー運用に統一 |
| 権限過多 | 全員がstateを読める | state格納先に最小権限を適用 |
Azure AI Foundryは、モデル、接続、エージェント、外部データソースなどを扱うため、一般的なWebアプリ基盤よりもstateの取り扱いに注意が必要です。Gitリポジトリにstateファイルを含める運用は避け、バックエンドの暗号化、アクセス制御、監査ログを確認してください。
Private Endpoint、CMK、Azure Policyは本番前に設計する
Azure AI FoundryをTerraformで作成できるようになると、検証環境の展開は速くなります。しかし、本番環境ではセキュリティ関連の設計を後回しにすると、後から大きな手戻りになります。
公式ドキュメントでは、Terraform構成をカスタマイズする際の関連セキュリティ設定として、Private Endpoint、Customer-managed keys、RBAC、カスタムAzure Policyが挙げられています。(Microsoft Learn)
Private Endpointを使うべきケース
Microsoft Foundryのネットワーク分離では、インバウンドアクセス、Foundryリソースからのアウトバウンドアクセス、Agent clientから依存サービスへのアウトバウンドアクセスという観点で検討する必要があります。Private Endpointを使うことで、Foundryアカウントやプロジェクトへのプライベート接続を構成できます。(Microsoft Learn)
Private Endpointを検討すべき代表例は次のとおりです。
| ケース | 判断基準 |
|---|---|
| 社内ネットワークやVNet内からのみアクセスしたい | Public Network Accessを制限する |
| 機密データを扱うAIアプリを開発する | データソースや依存PaaSもPrivate Link化する |
| 規制業種や監査対象の環境 | DNS、承認フロー、接続経路を明文化する |
| Agent Serviceを本番利用する | BYOリソースや依存サービスへの到達性を確認する |
Private Endpointで見落としやすいのはDNSです。公式ドキュメントでは、Private Endpoint作成後にDNS設定を確認する必要があり、VNet内からはプライベートIPへ解決される構成になると説明されています。(Microsoft Learn) TerraformでPrivate Endpointだけを作っても、名前解決が正しくなければアプリケーションから接続できません。
CMKを使うべきケース
Customer-managed key、つまりCMKは、データの暗号化キーを組織側で管理したい場合に使います。公式ドキュメントでは、FoundryのCMK暗号化により、Key VaultまたはManaged HSMと連携し、プロジェクト成果物、アップロードファイル、評価データなど、関連ストレージアカウントに保存される保存データへ追加の保護レイヤーを適用できると説明されています。(Microsoft Learn)
CMKは、次のような組織で優先度が高くなります。
- 暗号化キーのローテーションや失効を自社統制したい
- データ分類上、Microsoft管理キーだけでは要件を満たせない
- Key VaultまたはManaged HSMを既に標準利用している
- 監査でキー管理の証跡が必要
ただし、CMKは「設定すれば終わり」ではありません。公式ドキュメントでは、キー保管先とFoundryリソースを同一リージョンに配置すること、Key Vaultのsoft deleteとpurge protectionを有効にすること、Managed Identityに必要な権限を付与することなどが前提条件として示されています。(Microsoft Learn)
また、CMK対応リージョンには制約がある可能性があります。公式情報では、Azure AI Search基盤の容量制約により、CMK暗号化は選択されたリージョンのみで利用可能とされています。(Microsoft Learn) 本番設計では、リージョン、モデル提供状況、Key Vault、ネットワーク構成をまとめて確認してください。
Azure Policyで作成ルールを統制する
複数チームがAzure AI Foundryを利用する組織では、Terraformコードだけで統制しようとすると限界があります。コードレビューを通っていないポータル作成や、別リポジトリからの作成が起きるためです。
公式ドキュメントでは、カスタムAzure Policyにより、Foundryのハブ、プロジェクト、接続、capability hostなどの不正な作成を防ぎ、タグやセキュリティ構成、承認済み統合を強制できると説明されています。(Microsoft Learn)
実務で使いやすいAzure Policyの例は次のとおりです。
| ポリシー例 | 目的 |
|---|---|
| 許可リージョンのみ作成可能 | データ所在地や運用対象リージョンを統一 |
| 必須タグがない作成を拒否 | コスト管理、部門管理、環境識別 |
| Public Network Accessを制限 | インターネット露出を防ぐ |
| 承認済み接続カテゴリのみ許可 | 外部サービス連携の統制 |
| APIキー認証を抑制 | Entra ID中心の認証へ寄せる |
Terraformは「作るためのコード」、Azure Policyは「作ってよいものを制限するガードレール」と考えると設計しやすくなります。
開発者が確認すべきモデルデプロイと接続設定
開発者にとって重要なのは、TerraformでFoundryプロジェクトやモデルデプロイが作成された後、実際にアプリケーションから使える状態になっているかです。
公式サンプルでは、OpenAI形式のgpt-4oデプロイ例が示されています。サンプル内ではモデル名、バージョン、SKU、capacityを指定しています。(Microsoft Learn)
ただし、サンプルのモデルやバージョンをそのまま本番標準にするのは避けるべきです。モデル提供状況、クォータ、リージョン、料金、アプリケーション要件は変わる可能性があります。Terraformコードでは、少なくとも次の項目を変数化しておくと運用しやすくなります。
variable "location" {}
variable "model_name" {}
variable "model_version" {}
variable "deployment_capacity" {}
variable "environment" {}変数化しておくと、検証環境では小さなcapacity、本番環境では必要なcapacityを指定できます。また、モデルバージョン変更時もHCL全体を探して修正する必要がなくなります。
開発チーム向けの確認リスト
アプリケーション開発者は、Terraform適用後に次の点を確認してください。
| 確認項目 | 確認方法 |
|---|---|
| Foundryプロジェクトが作成されているか | Foundryポータルまたはterraform state list |
| モデルデプロイ名がアプリ設定と一致しているか | 環境変数、Key Vault、アプリ構成を確認 |
| 認証方式が想定通りか | Entra ID、Managed Identity、APIキー利用方針を確認 |
| 接続先データソースに到達できるか | ネットワーク、RBAC、Private Endpoint、DNSを確認 |
| 本番と検証で設定が混ざっていないか | workspace、backend、変数ファイルを確認 |
特に、モデルデプロイ名の不一致はよくあるトラブルです。Terraformではgpt-4oとして作ったのに、アプリ側では別名を参照していると、認証やネットワークが正しくても呼び出しに失敗します。アプリ設定とTerraform出力を連携させる設計にしておくと、こうしたミスを減らせます。
管理者が本番展開前に確認すべきチェックリスト
Azure AI FoundryをTerraformで展開する前に、管理者は次の項目を確認してください。
| 分類 | チェック項目 | 完了の目安 |
|---|---|---|
| Provider | AzAPIかAzureRMかを決めたか | 管理対象の範囲と理由が文書化されている |
| 権限 | Foundry RBACロールを確認したか | ロール名ではなくID指定を検討済み |
| 認証 | APIキー利用を許可するか決めたか | Entra ID / Managed Identity方針と整合している |
| state | リモートバックエンドを使うか | stateがGitに含まれず、アクセス制御されている |
| 既存環境 | import対象を整理したか | planで意図しない再作成・削除がない |
| ネットワーク | Private EndpointやPNAを設計したか | DNSを含めて接続確認できる |
| 暗号化 | CMKが必要か判断したか | Key Vault、Managed Identity、リージョンが整合 |
| ガバナンス | Azure Policyを適用するか | タグ、リージョン、接続制限が定義済み |
| モデル | モデル名・バージョン・capacityを確認したか | クォータとアプリ要件を満たしている |
| 運用 | CI/CDとレビュー手順を決めたか | planレビュー後にapplyする流れがある |
このチェックリストで特に優先度が高いのは、RBAC、state、ネットワーク、既存リソースのimportです。ここを曖昧にしたままTerraform化すると、「コード化したのに誰が何を変更したか分からない」「ポータル変更で差分が出続ける」「本番環境で通信できない」といった問題が起きやすくなります。
よくある失敗と回避策
Azure AI FoundryをTerraformで作成する際は、次の失敗が起きやすいです。
| 失敗例 | 原因 | 回避策 |
|---|---|---|
| Providerを途中で変えて構成が複雑になる | AzureRMとAzAPIの違いを理解せず開始 | 最初に管理対象を棚卸しする |
| ロール割り当てが失敗する | 旧ロール名・新ロール名が混在 | ロール定義IDを使う |
| 既存リソースが再作成されそうになる | importせずにapplyしている | 先にstateへ取り込む |
| Private Endpoint作成後に接続できない | DNS設定が不足 | Private DNS Zoneと名前解決を確認 |
| CMK設定でエラーになる | Key Vault権限やリージョン不一致 | Managed Identity、RBAC、リージョンを事前確認 |
| stateに機密情報が残る | ローカルstateや共有フォルダ運用 | セキュアなリモートバックエンドを使う |
| サンプルコードを本番に流用する | タグ、認証、ネットワークが未調整 | 環境別変数と社内標準を反映する |
Terraform化の目的は、単に作成を自動化することではありません。誰が見ても構成を理解でき、同じ環境を再現でき、変更前に差分を確認できる状態を作ることです。
Azure AI FoundryをTerraformで展開する次のアクション
Azure AI FoundryのTerraform対応を実務に取り入れるなら、まずは小さな検証環境で始めるのが現実的です。
最初にやるべきことは、次の3つです。
- AzureRM Providerで足りるか、AzAPI Providerが必要かを判断する
- Foundryリソース、プロジェクト、モデルデプロイを最小構成で作成する
- RBAC、state、ネットワーク、暗号化を本番要件に合わせて追加する
既存のAzure AI Foundry環境がある場合は、AzureポータルからTerraformコードをエクスポートし、すぐにapplyするのではなく、変数化、不要設定の削除、import、plan確認の順で進めてください。新規環境の場合も、公式サンプルをそのまま本番化せず、命名規則、タグ、Private Endpoint、CMK、Azure Policyを組み込んだ社内標準テンプレートに育てることが重要です。
TerraformによるAzure AI Foundry管理は、開発スピードを上げるだけでなく、AI基盤の統制を強化する手段になります。まずは検証環境で差分管理とデプロイ手順を固め、その後に本番向けのセキュリティ・ガバナンス設定を段階的に追加していきましょう。
コメント