Visual Studio CodeでAzure向けTerraformを使うなら、今回押さえるべき結論は「Microsoft Terraform Visual Studio Code extensionを入れるだけでなく、認証方式・実行場所・AzAPI移行支援まで確認する」ことです。公式情報では、Microsoft Terraform拡張機能とAzure Resources拡張機能を使い、VS CodeからTerraform構成の作成、実行、Azureリソースグループの作成・確認・削除まで行う流れが整理されています。特に、従来のAzure Account拡張機能に依存した認証から、VS Code組み込みのMicrosoft Authentication ProviderとAzure Resources拡張機能を使う方向に変わっている点は、管理者・開発者ともに確認が必要です。(Microsoft Learn)
まず押さえるべきポイント
Microsoft Terraform Visual Studio Code extensionは、Azure向けTerraform作業をVS Code内で進めやすくする拡張機能です。公式のインストール手順では、拡張機能の導入、Terraformコードの作成、init、plan、apply、リソース確認、destroyまでの基本的な流れが示されています。別の利用ガイドでは、AzureRMとAzAPIプロバイダーの言語支援、Azure Export for Terraform、プレフライト検証、AzureRMからAzAPIへの移行支援も説明されています。(Microsoft Learn)
実務で重要なのは、次の3点です。
| 確認ポイント | 影響 | 取るべき対応 |
|---|---|---|
| Azure Account拡張機能への依存が前提ではなくなる | サインインやCloud Shell利用の手順が以前と異なる可能性がある | Azure Resources拡張機能の有無とサインイン状態を確認する |
| Terraformコマンドの実行場所 | Cloud Shell前提の手順をそのまま使うと失敗する可能性がある | 現在の拡張機能ではローカル統合ターミナル実行を前提に確認する |
| AzAPI関連機能の拡充 | AzureRMからAzAPIへの移行や既存AzureリソースのTerraform化に使える | 生成コードとTerraform stateを必ずレビューする |
Microsoft Terraform拡張機能のMarketplaceおよびGitHub READMEでは、Cloud Shell連携は現在利用できず、Terraformコマンドはローカルの統合ターミナルで実行されると明記されています。一方、インストール記事にはCloud Shellに関する手順も残っているため、チーム展開時は「実際の拡張機能バージョンではどのターミナルで動くか」を先に確認するのが安全です。([Visual Studio Marketplace][2])
何が変わるのか
認証はAzure Account拡張機能中心からAzure Resourcesと組み込み認証へ
公式のインストール記事では、Azure Account拡張機能の非推奨化に伴い、認証はVS Code組み込みのMicrosoft Authentication ProviderとAzure Resources拡張機能で処理されると説明されています。Azure Account拡張機能自体も、2025年1月に非推奨になる案内が出され、拡張機能側は組み込みMicrosoft Authentication Providerへ移行する必要があるとされています。(Microsoft Learn)
この変更の実務上の影響は、単に「別の拡張機能を入れる」だけではありません。AzureポータルやAzure CLIではサインイン済みでも、VS Code側のAzure Resourcesビューでは再ログインが必要になる場合があります。また、プレフライト検証やエクスポートなどAzure CLI認証を使う機能では、az login済みであることも確認する必要があります。(Microsoft Learn)
Cloud Shell前提の運用は見直しが必要
インストール記事ではMicrosoft Terraform: PushでCloud Shellへワークスペースファイルを送る流れが説明され、azureTerraform.files設定に合致するファイルがCloud Shellへコピーされるとされています。(Microsoft Learn)
ただし、現在のMarketplace/READMEではCloud Shell連携が利用できず、Terraformコマンドはローカル統合ターミナルで実行されると案内されています。拡張機能の設定にもazureTerraform.terminalがありますが、説明上は有効な設定としてintegratedが示されています。([Visual Studio Marketplace][2])
そのため、チーム内の手順書に「VS CodeからCloud Shellで実行」と書かれている場合は、次のように修正しておくと混乱を避けられます。
| 旧手順でありがちな前提 | 見直し後の推奨 |
|---|---|
| Terraform CLIはCloud Shellにあるのでローカル不要 | ローカルまたはDev Container内にTerraform CLIを入れ、PATHに通す |
| Azure認証はAzure Account拡張機能で完結 | Azure Resources拡張機能とVS CodeのMicrosoft認証、必要に応じてaz loginを確認 |
Push後にCloud Shellで実行 | 現在の拡張機能では統合ターミナル実行を前提に検証 |
| Cloud Shellにコピーされるファイルだけを気にする | ローカル実行時の作業ディレクトリ、状態ファイル、環境変数も確認 |
対象者と影響範囲
この更新で影響を受けるのは、Terraformコードを書く開発者だけではありません。拡張機能の配布、許可、更新管理を行うIT管理者や、AzureRMからAzAPIへの移行を検討するプラットフォームチームにも関係します。
| 対象者 | 影響する作業 | 確認すべきこと |
|---|---|---|
| Azure開発者 | VS Code上でのTerraform作成、init、plan、apply | Terraform CLI、Azure CLI、Azure Resources拡張機能、認証状態 |
| IaC担当者 | 既存AzureリソースのTerraform化、AzAPI移行 | 生成されたHCL、type、api-version、Terraform state |
| 管理者 | 拡張機能の許可、更新、ネットワーク制御 | extensions.allowed、VSIX配布、プロキシ、更新ポリシー |
| セキュリティ担当 | 拡張機能の権限、認証、RBAC | 拡張機能の信頼、最小権限、az loginの対象テナント |
| 教育・標準化担当 | チーム向け手順書、研修資料 | Cloud Shell前提の記述、ローカル実行前提の記述差分 |
VS Code拡張機能はVS Code本体と同じ権限で動作するため、企業環境では「便利だから全員に自由に入れさせる」のではなく、許可する拡張機能、バージョン、更新タイミングを管理する視点が必要です。VS Codeでは組織向けに許可拡張機能やプライベートMarketplace、ポリシー管理を利用できます。(Visual Studio Code)
インストール前に確認する前提条件
Microsoft Terraform拡張機能を安定して使うには、拡張機能だけでなく周辺ツールもそろえる必要があります。公式情報では、Visual Studio Code、Microsoft Terraform拡張機能、Terraform CLI、Azure CLIとaz loginが前提として示されています。また、インストール記事ではAzureサブスクリプション、Terraform環境、Node.jsの準備も挙げられています。(Microsoft Learn)
| 項目 | 確認コマンド・確認方法 | 不足している場合の症状 |
|---|---|---|
| Visual Studio Code | VS Codeを起動できるか | 拡張機能を利用できない |
| Microsoft Terraform拡張機能 | 拡張機能ビューでMicrosoft Terraformを検索 | コマンドパレットにMicrosoft Terraform:系コマンドが出ない |
| Azure Resources拡張機能 | 拡張機能ビューでAzure Resourcesを確認 | Azure認証やリソース選択で詰まる |
| Terraform CLI | terraform -version | initやplanが実行できない |
| Azure CLI | az version、az login | エクスポート、認証、プレフライト検証で失敗する |
| GraphViz | dot -V | visualize機能でグラフ生成できない |
| Node.js | node -v | 依存関係のインストールや一部処理でプロンプトが出る可能性がある |
Marketplaceでは、Terraformコマンド実行にはTerraform、visualize機能にはGraphVizが必要で、どちらもPATHに含めるよう案内されています。([Visual Studio Marketplace][2])
Visual Studio CodeにMicrosoft Terraform拡張機能をインストールする手順
画面からインストールする
基本手順はシンプルです。
- Visual Studio Codeを起動する
- 左側の拡張機能ビューを開く
Microsoft Terraformを検索する- 発行元がMicrosoftの
Microsoft Terraformを選び、インストールする - 続けて
Azure Resourcesを検索し、Azure Resources拡張機能も確認する - 検索ボックスに
@installedを入力し、両方がインストール済みか確認する
公式手順でも、Microsoft Terraform拡張機能とAzure Resources拡張機能の両方がインストール済み一覧に表示されることを確認する流れが示されています。(Microsoft Learn)
コマンドラインでインストールする
複数端末や開発用VMに展開する場合は、VS Code CLIを使うと確認しやすくなります。VS Codeではcode --install-extensionで拡張機能をインストールでき、拡張機能はpublisher.extension形式のIDで指定します。(Visual Studio Code)
code --install-extension ms-azuretools.vscode-azureterraform
code --install-extension ms-azuretools.vscode-azureresourcegroups
code --list-extensions --show-versionsチームで標準化する場合は、リポジトリの.vscode/extensions.jsonに推奨拡張機能を書く方法もあります。VS Codeはワークスペースを初めて開いたユーザーに推奨拡張機能のインストールを促せます。(Visual Studio Code)
{
"recommendations": [
"ms-azuretools.vscode-azureterraform",
"ms-azuretools.vscode-azureresourcegroups"
]
}Azureリソースグループを作成して動作確認する
インストール後は、最初に小さなAzureリソースグループを作成して、認証、Terraform CLI、拡張機能コマンドが正しく動くか確認するのがおすすめです。公式インストール記事でも、拡張機能を使ってAzureリソースグループを作成し、確認し、最後に削除する流れが扱われています。(Microsoft Learn)
サンプル用フォルダーを作成する
任意の作業フォルダーを作り、VS Codeで開きます。
mkdir tf-vscode-rg-demo
cd tf-vscode-rg-demo
code .providers.tfを作成する
AzureRMプロバイダーを使う最小構成です。公式サンプルではAzureRMプロバイダーに~>4.0が使われています。(Microsoft Learn)
terraform {
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = "~> 4.0"
}
}
}
provider "azurerm" {
features {}
}main.tfを作成する
日本リージョンで試す場合の例です。社内標準リージョンがある場合は、japaneastを適切なリージョンに変更してください。
variable "resource_group_name" {
type = string
default = "rg-vscode-terraform-demo"
}
variable "location" {
type = string
default = "japaneast"
}
resource "azurerm_resource_group" "demo" {
name = var.resource_group_name
location = var.location
}
output "resource_group_name" {
value = azurerm_resource_group.demo.name
}VS Codeのコマンドパレットから実行する
コマンドパレットを開き、次の順に実行します。
| 実行順 | コマンドパレットの項目 | CLIでの対応 |
|---|---|---|
| 初期化 | Microsoft Terraform: Init | terraform init |
| 構成確認 | Microsoft Terraform: Validate | terraform validate |
| 実行計画 | Microsoft Terraform: Plan | terraform plan |
| 適用 | Microsoft Terraform: Apply | terraform apply |
| 削除 | Microsoft Terraform: Destroy | terraform destroy |
公式ガイドでは、Microsoft Terraform: Initはterraform initを実行するのと同じ位置づけで、Microsoft Terraform: Planは現在のディレクトリのTerraform構成から実行計画を作成すると説明されています。ApplyやDestroyでは確認プロンプトにyesを入力する流れです。(Microsoft Learn)
Azure CLIで作成結果を確認する
apply後、次のコマンドでリソースグループを確認します。
az group show --name rg-vscode-terraform-demo確認が終わったら、不要な課金やリソース残存を避けるために削除します。
terraform destroyサンプルでも、作成したリソースグループはテスト完了後にMicrosoft Terraform: Destroyで削除する流れが案内されています。(Microsoft Learn)
実務で使うときの便利な機能
AzAPIプロバイダーの入力支援
Microsoft Terraform拡張機能は、AzAPIプロバイダー向けにリソースタイプやAPIバージョン、プロパティ名、値の候補表示、ホバー説明、スキーマ検証を提供します。azapi_resourceを書く場面では、AzureのREST API仕様に近い構成をHCLで扱うため、入力ミスや必須プロパティ漏れを早期に見つけられるのが利点です。(Microsoft Learn)
特に便利なのは、次のようなケースです。
| 利用シーン | 効果 |
|---|---|
| 新しいAzureリソースをAzAPIで扱う | リソースタイプとAPIバージョンの候補を見ながら記述できる |
| ARM JSONやREST APIレスポンスをもとにTerraform化する | JSONを貼り付けてazapi_resource形式へ変換できる |
手書きのbodyが複雑 | スキーマエラーや型の誤りを入力中に発見しやすい |
ただし、ARMテンプレートに複数リソース、パラメーター、変数が含まれる場合は、変換後に手動クリーンアップが必要とされています。生成されたtype、body、parent_idは、apply前に必ず確認してください。(Microsoft Learn)
既存AzureリソースのTerraform化
拡張機能はAzure Export for Terraform、つまりaztfexportと統合され、既存のAzureリソースをTerraform構成とstateにエクスポートできます。出力プロバイダーとしてAzureRMまたはAzAPIを選べるため、Terraform管理されていない既存リソースをIaC管理へ移す入口として使えます。(Microsoft Learn)
実務では、エクスポート直後のコードをそのまま本番管理に入れないことが重要です。次の観点でレビューしましょう。
| レビュー項目 | 確認内容 |
|---|---|
| 命名 | リソース名、変数名、モジュール名がチーム標準に合っているか |
| state | 既存リソースが正しくTerraform stateに関連付いているか |
| provider | AzureRMで管理するのか、AzAPIで管理するのか |
| 差分 | terraform planで意図しない更新や再作成が出ないか |
| 機密情報 | 生成コードや.tfvarsに秘密情報が含まれていないか |
AzureRMからAzAPIへの移行支援
利用ガイドでは、azurerm_*リソースブロックに対してAzAPI相当の構成を生成する機能が説明されています。ただし、この機能はHCL作成を支援するもので、Terraform stateファイルは更新しません。stateを更新しないままazurerm_*をazapi_resourceへ置き換えると、Terraformが既存リソースを削除済み、新しいAzAPIリソースを新規作成対象として扱い、基盤リソースの再作成につながる可能性があります。(Microsoft Learn)
移行時は、次の順番を守ると事故を減らせます。
- 既存構成とstateをバックアップする
- 対象リソースを1種類または1モジュールに絞る
- 拡張機能でAzAPI構成を生成する
type、api-version、bodyを公式スキーマやプロバイダー文書と照合するterraform state mvまたはimportブロックでstate移行を行う- 1回ごとに
terraform planを実行し、再作成が出ないことを確認する
管理者が確認すべき展開・運用ポイント
許可する拡張機能を明確にする
企業環境では、Microsoft Terraformと似た名前の拡張機能、HashiCorp製のTerraform拡張機能、個人発行の補助ツールなどが混在しやすくなります。VS Codeではextensions.allowedアプリケーション設定を使い、組織でインストール可能な拡張機能を制御できます。設定されている場合、一覧にない拡張機能はインストールがブロックされます。(Visual Studio Code)
管理対象端末では、少なくとも次を明文化しておくとよいでしょう。
{
"extensions.allowed": {
"ms-azuretools.vscode-azureterraform": true,
"ms-azuretools.vscode-azureresourcegroups": true
}
}実際のポリシー形式や配布方法は組織の管理方式に依存します。VS CodeはIntune、Active Directory Group Policy、macOSのMDMなどを通じたポリシー展開に対応しています。(Visual Studio Code)
更新タイミングを管理する
VS Codeは拡張機能の更新を自動確認し、既定では自動更新します。手動更新にしたい場合は、拡張機能ビューやextensions.autoUpdate、extensions.autoCheckUpdatesを使って更新確認や自動更新の扱いを制御できます。(Visual Studio Code)
本番IaCを扱うチームでは、次の運用が現実的です。
| 環境 | 推奨運用 |
|---|---|
| 個人検証端末 | 自動更新を許可し、新機能を早めに確認 |
| チーム標準端末 | 月次またはスプリント単位で更新確認 |
| 本番運用端末 | 検証済みバージョンを固定し、更新前にplan結果を確認 |
| オフライン環境 | VSIXで配布し、更新手順を別途管理 |
VSIXから拡張機能をインストールすることも可能ですが、VSIX経由でインストールした拡張機能は既定で自動更新が無効になります。閉域網や固定バージョン運用では便利ですが、セキュリティ修正の取り込み漏れに注意が必要です。(Visual Studio Code)
ローカル実行前提の開発環境を用意する
現在の拡張機能ではTerraformコマンドがローカル統合ターミナルで実行されるため、端末側にTerraform CLI、Azure CLI、必要に応じてGraphVizを入れてPATHに通す必要があります。Dev ContainerやWSLを使うチームでは、コンテナ内またはWSL側に同じツールを入れ、VS Codeがどの環境で拡張機能とターミナルを動かしているかを確認してください。([Visual Studio Marketplace][2])
開発者が失敗しやすいポイント
VS Codeでサインイン済みでもAzure CLIは未認証
Azure Resources拡張機能でサインインできていても、ターミナルで実行するTerraformやaztfexport、プレフライト検証がAzure CLI認証を必要とする場合があります。利用ガイドでも、Azure CLIのインストールとaz loginが前提として示されています。(Microsoft Learn)
作業開始時は、次を習慣化するとトラブルを減らせます。
az account show
terraform -version
code --list-extensions --show-versions複数テナントや複数サブスクリプションを扱う場合は、az account set --subscription <subscription-id>で対象を明示してからplanを実行しましょう。
生成されたTerraformコードをそのまま本番適用する
拡張機能の候補表示、ARM JSON変換、Azure Export for Terraformは便利ですが、生成結果は「レビューの出発点」です。特に、既存Azureリソースを取り込む場合は、命名、モジュール分割、変数化、タグ、state管理、RBACを整理しないまま適用すると、あとから保守しにくい構成になります。
まずは開発サブスクリプションでterraform planまで確認し、本番では差分レビューを必ず挟みましょう。
AzAPI移行でstateを動かし忘れる
AzureRMからAzAPIへの移行では、HCLの置換だけでは不十分です。公式ガイドでも、状態を移行するにはterraform state mvを使うかimportブロックを追加し、各状態変更後にterraform planで意図しない再作成がないか確認するよう説明されています。(Microsoft Learn)
移行作業では、次のようなチェック表を使うと安全です。
| チェック | OK条件 |
|---|---|
| 移行対象を限定した | 1回の変更で複数種類のリソースをまとめて移行していない |
| state移行方法を決めた | state mvかimportブロックのどちらを使うか決めている |
plan結果を保存した | 再作成、削除、意図しない変更がない |
| ロールバック方法がある | 変更前のHCLとstateバックアップがある |
| レビュー済み | type、api-version、bodyを確認している |
プレフライト検証の使いどころ
Microsoft Terraform拡張機能はaztfpreflightと連携し、Terraform planをAzureのリソース制約に照らして検証できます。無効なプロパティ値、クォータ違反、ポリシーコンプライアンス違反などを、リソース作成・変更前に検出できると説明されています。(Microsoft Learn)
使いどころは、次のような場面です。
| 場面 | 期待できる効果 |
|---|---|
| 新しいリージョンやSKUを使う | 値の誤りや制約違反を早めに見つける |
| Azure Policyが厳しい環境に展開する | ポリシー違反をapply前に把握する |
| 大きな変更を本番前に確認する | クォータや制約で失敗するリスクを下げる |
| AzAPIで細かいプロパティを扱う | スキーマや値のミスを減らす |
ただし、プレフライト検証はレビューや承認プロセスの代替ではありません。検証を通過しても、コスト、命名規則、セキュリティ、運用監視、削除保護などは別途確認が必要です。
チーム展開時の推奨チェックリスト
| 項目 | 確認内容 |
|---|---|
| 拡張機能 | ms-azuretools.vscode-azureterraformとAzure Resourcesを標準化している |
| 実行環境 | Terraform CLI、Azure CLI、GraphVizが必要な端末またはコンテナに入っている |
| 認証 | VS CodeのAzureサインインとaz loginの両方を確認している |
| ターミナル | Cloud Shell前提ではなく、ローカル統合ターミナル実行を検証している |
| 更新管理 | 自動更新、手動更新、VSIX配布の方針が決まっている |
| 拡張機能制御 | extensions.allowedやプライベートMarketplaceの要否を判断している |
| state管理 | ローカルstateではなく、チームで管理できるバックエンドを使っている |
| 移行作業 | AzAPI移行時にstate移行とterraform plan確認を必須にしている |
| サンプル削除 | 検証用リソースグループはdestroyで削除している |
次に取るべき行動
新規に始める場合は、まずVS CodeにMicrosoft Terraform拡張機能とAzure Resources拡張機能を入れ、ローカル統合ターミナルでterraform init、plan、apply、destroyまで小さなリソースグループで確認してください。既存チームで運用している場合は、Cloud Shell前提の手順、Azure Account拡張機能前提の認証、AzureRMからAzAPIへの移行手順、拡張機能の更新管理を見直すのが優先です。
Microsoft Terraform Visual Studio Code extensionは、Azure向けTerraformの作成、検証、既存リソースの取り込み、AzAPI移行を効率化できます。ただし、拡張機能が生成・補助する内容をそのまま本番に反映するのではなく、実行環境、認証、state、RBAC、terraform planを確認することで、安全に活用できます。
[2]: https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-azureterraform “
Microsoft Terraform – Visual Studio Marketplace
“
コメント