マルチクラウド戦略が加速する現在、ビジネスの要求スピードに応えるため、AWSに加えてAzureやGoogle Cloudへの対応を迫られる場面が増えています。しかし、インフラエンジニアやSREにとって、新しいクラウドプロバイダーの学習コストは決して小さくありません。
ここで経営的にも技術的にも致命傷になり得るのが、AWSの知識が通用しないことによる設定ミス（セキュリティホール）のリスクです。
最近では生成AIを「コード生成機」として使うケースも増えましたが、単に「AWSのコードをAzureに書き換えて」と指示してそのまま本番投入するのは、あまりにも危険です。AIはもっともらしい顔をして存在しないパラメータをでっち上げたり、セキュリティリスクのある設定を平然と選択したりするからです。
本記事では、長年の開発現場で培った知見をもとに、AIを単なる「翻訳機」としてではなく、「翻訳機」兼「検査員」として活用する、より安全で実践的なワークフローを解説します。まずは動くプロトタイプを作り、高速に検証を回すアプローチを見ていきましょう。
1. マルチクラウド化における課題とAIによる設計
クラウド間のコード変換は、一筋縄ではいかない複雑な作業です。
単なる「翻訳」ではリスクがある理由
インフラコード（IaC）の「翻訳」は、自然言語の翻訳以上に厄介です。例えば、AWSの Security Group はステートフル（戻りの通信も自動許可）ですが、Azureの Network Security Group (NSG) も基本はステートフルでありつつ、適用範囲（サブネット単位かNIC単位か）のベストプラクティスが異なります。
AIに単に「変換して」と依頼すれば、構文的には正しいTerraformコードが瞬時に出力されるでしょう。しかし、そこには組織のセキュリティポリシーやアーキテクチャの意図までは考慮されていません。結果として、terraform apply は通るものの、ビジネス要件を満たさない脆弱なインフラが構築されてしまう恐れがあります。
AIをペアプログラマーとして使う「検証駆動変換」
そこで提案したいのが、AIの能力を多角的に利用し、仮説検証を高速に回す「検証駆動変換（Verification-Driven Conversion）」です。
- 翻訳（Generate）: AIにAWSのコードをAzure/GCP向けに変換させる。
- 検査（Verify）: 変換が正しいか、セキュリティポリシーに違反していないかをチェックする「テストコード」もAIに作成させる。
- 実行（Apply）: コードの内容を詳細に確認する代わりに、テストが成功するかどうかを確認する。
このフローの肝は、AIが生成したテストコードでAI自身の誤りを検出する仕組みを構築することです。AI同士を相互監視させることで、人間はより高度な検証やビジネスロジックに集中できます。まさに、安全性と開発スピードを両立させる実践的なアプローチと言えるでしょう。
2. 変換環境のセットアップとAIプロンプト設計
安全かつスピーディーな変換プロセスを実現するためには、適切なツール選定と、AIに「文脈」を深く理解させるための準備が不可欠です。
必要なツール群（Terraform, OPA/Conftest, LLM API）
今回のワークフローでは、以下のツールを使用します。
- Terraform: IaCの標準ツール。HCL（HashiCorp Configuration Language）で記述します。
- GitHub Copilot / ChatGPT (ChatGPT class): コード生成と変換を行うAIエンジン。ChatGPTやClaudeの最新モデルのような高性能モデルが推奨されます。
- Open Policy Agent (OPA) / Conftest: 生成されたTerraformコードに対して静的解析を行うためのポリシーエンジン。
OPAは、インフラの設定ルールをコード（Rego言語）として記述し、自動判定するための強力なツールです。「このポートが開いていたらNG」「必須タグがなければNG」といったルールを機械的にチェックし、ガバナンスを効かせることができます。
「文脈」をAIに伝えるコンテキスト注入テクニック
AIエージェントの挙動を研究する中で痛感するのは、コード変換の品質は前提条件（コンテキスト）をどれだけ的確に与えられるかで劇的に変わるということです。単に「変換して」と丸投げするのではなく、以下のようなプロンプトで明確な指針を与えることが成功への最短距離です。
推奨プロンプトテンプレート例:
あなたはAzureとAWSの両方に精通したインフラアーキテクトです。
以下のAWS Terraformコードを、Azure向けのTerraformコードに変換してください。
【制約条件】
1. プロバイダー: `azurerm` の最新バージョンを使用すること。
2. 命名規則: リソース名は `prj-env-region-resource` の形式（例: `myprj-prod-japaneast-vnet`）に統一すること。
3. タグ付け: 全リソースに `Environment`, `Owner`, `ManagedBy = Terraform` のタグを付与すること。
4. セキュリティ: パブリックアクセスは原則禁止。必要な場合は明示的に理由をコメントすること。
5. リソースグループ: 新規に作成せず、変数 `var.resource_group_name` を使用すること。
【入力コード (AWS)】
(ここにAWSのコードを貼り付け)
このように、命名規則、タグ戦略、セキュリティ基準を明文化してプロンプトに組み込む手法を「コンテキスト注入」と呼びます。これにより、AIは単なる翻訳機から、組織のルールを理解した優秀なアシスタントへと進化します。
3. 実践：AWS VPCからAzure VNetへのコード変換
それでは、実際に手を動かして検証してみましょう。最も基本的なネットワークリソースであるAWSのVPC（Virtual Private Cloud）を、AzureのVNet（Virtual Network）へ変換するケースをプロトタイプとして扱います。
変換元：AWS VPCのTerraformコード
まず、変換元となるAWSのコードです。一般的なVPC構成です。
# aws_vpc.tf
resource "aws_vpc" "main" {
cidr_block = "10.0.0.0/16"
enable_dns_hostnames = true
enable_dns_support = true
tags = {
Name = "main-vpc"
Environment = "production"
}
}
resource "aws_subnet" "public" {
vpc_id = aws_vpc.main.id
cidr_block = "10.0.1.0/24"
map_public_ip_on_launch = true
availability_zone = "ap-northeast-1a"
tags = {
Name = "public-subnet"
}
}
変換後：AI生成されたAzure VNetコード
次に、高度な推論能力を持つ最新のLLMを用いて生成されたAzure向けのコードを見てみましょう。AIが先ほどのコンテキストをどう解釈し、変換したかに注目してください。
# azure_vnet.tf (AI生成)
resource "azurerm_virtual_network" "main" {
name = "myprj-prod-japaneast-vnet" # 命名規則が適用されている
address_space = ["10.0.0.0/16"] # cidr_blockからの変換
location = var.location
resource_group_name = var.resource_group_name # 制約条件通り変数を使用
tags = {
Environment = "production"
Owner = "InfraTeam" # 追加されたタグ
ManagedBy = "Terraform"
}
}
resource "azurerm_subnet" "public" {
name = "myprj-prod-japaneast-snet-public"
resource_group_name = var.resource_group_name
virtual_network_name = azurerm_virtual_network.main.name
address_prefixes = ["10.0.1.0/24"]
# AWSの map_public_ip_on_launch はAzureではSubnetプロパティではなく
# NICやPublic IPリソース側で制御するため、ここでは記述されない。
}
パラメータマッピングの解説
ここで技術の本質として見極めるべきは、AIがAWSとAzureのアーキテクチャの差異をどう処理したかです。
- リソースグループの扱い: AWSにはリソースグループという概念がありませんが、Azureでは必須です。プロンプトで指示した通り、変数を参照する形で補完されています。
- DNS設定: AWSの
enable_dns_hostnamesは、Azure VNetではデフォルトの挙動（Azure提供のDNS利用）と異なるため、明示的な設定が必要な場合があります。確認が必要です。 - パブリックIPの割り当て: AWSの
map_public_ip_on_launchはサブネットの設定ですが、Azureではサブネット設定に相当するものはありません。AIはこの設定を無視（削除）しましたが、AzureではVM作成時やNIC作成時にPublic IPを紐付ける設計のため、正しい判断です。
このように、優秀なAIモデルは単純な文字列置換ではなく、プラットフォームの特性に合わせた構造的な変換を行ってくれます。しかし、「本当にビジネス要件を満たしているか」は別問題です。そこで、次章の「検証テスト」で確実性を担保します。
4. 安全性を確保する：AIによる検証テストコードの生成
変換されたコードを人間の目視確認だけで済ませるのは、あまりにもハイリスクです。特に知見の浅いクラウド環境では、思わぬ落とし穴が待っています。
そこで、AI自身にコードが組織のポリシーに準拠しているかを自動チェックするテストコード（Rego）を作成させ、検証プロセスを自動化します。
「変換が正しいか」をAI自身に監査させる
以下のプロンプトをAIに投げかけます。RegoはOPAで使用する言語ですが、これもAIに書かせることで、エンジニアの学習コストを大幅に削減し、最短距離で実装へ向かうことができます。
作成された `azure_vnet.tf` に対して、以下のポリシーを検証するOPA (Open Policy Agent) 用のRegoコードを作成してください。
【検証ポリシー】
1. すべてのリソースに `ManagedBy` タグが含まれていること。
2. Virtual Networkの `address_space` が `10.0.0.0/16` を含んでいること（AWS側の設計と一致するか確認）。
3. SubnetにNetwork Security Group (NSG) が関連付けられていない場合、警告を出すこと（セキュリティリスク）。
OPA(Open Policy Agent)によるポリシー実装例
AIは以下のようなRegoコード（.regoファイル）を生成します。
package main
# タグの強制チェック
deny[msg] {
resource := input.resource_changes[_]
tags := resource.change.after.tags
not tags.ManagedBy
msg := sprintf("Resource %v is missing the 'ManagedBy' tag", [resource.address])
}
# アドレス空間の整合性チェック
deny[msg] {
resource := input.resource_changes[_]
resource.type == "azurerm_virtual_network"
address_space := resource.change.after.address_space[_]
not startswith(address_space, "10.0.")
msg := sprintf("VNet address space %v must start with 10.0.", [address_space])
}
このRegoファイルを使って、terraform plan の出力結果（JSON形式）に対して conftest test を実行します。
terraform plan -out=tfplan
terraform show -json tfplan > tfplan.json
conftest test tfplan.json -p policy.rego
AIが生成したTerraformコードに不備があれば、このテストは容赦なく失敗（FAIL）します。AIが作成したコードを、AIが作成したテストで相互チェックすることで、ヒューマンエラーのリスクを劇的に軽減できます。もちろんテストコード自体のレビューは必要ですが、膨大で複雑なTerraformの仕様を隅々まで目視するより、論理的なルール（Rego）の妥当性を確認する方がはるかに効率的で確実です。
Terraform test機能の活用
Terraform 1.6以降であれば、ネイティブのテストフレームワークも利用できます。AIに .tftest.hcl を生成させることも可能です。
# AIに生成させたテスト定義
run "verify_vnet_cidr" {
command = plan
assert {
condition = azurerm_virtual_network.main.address_space[0] == "10.0.0.0/16"
error_message = "VNet CIDR block does not match the requirement."
}
}
これにより、実際にデプロイする前に、仕様通りの変換ができているかを高速かつ安全に検証することが可能になります。
5. エラーハンドリングと継続的改善のサイクル
どれほど完璧なプロンプトとテストを用意しても、初回から一発で成功することは稀です。プロバイダーのバージョンアップによる仕様変更や、隠れた依存関係によるエラーは日常茶飯事です。重要なのは、失敗を恐れず、エラーを効率的に解決して前に進むことです。
よくある変換エラーとAIへの修正指示
よく直面するエラーとして、廃止された引数（Deprecated Argument）の使用が挙げられます。AIの学習データが古い場合、最新のAzureプロバイダーでは既に削除されたパラメータが出力されることがあります。また、旧世代のモデルを使用していると、最新のTerraform仕様に追いついていないコードが生成されるリスクも高まります。
エラーが発生したら、迷わずそのエラーログをAIにフィードバックしましょう。最新のAIモデルは、エラーメッセージを的確に解析し、具体的な修正案を提示する能力が飛躍的に向上しています。
修正プロンプト例:
以下のTerraformコードを実行したところ、エラーが発生しました。
エラー内容を解析し、修正版のコードを提示してください。
【エラーログ】
Error: Unsupported argument
on azure_vnet.tf line 12, in resource "azurerm_subnet" "public":
12: enforce_private_link_endpoint_network_policies = true
An argument named "enforce_private_link_endpoint_network_policies" is not expected here.
AIは瞬時にエラーの原因を特定し、修正コードを提示してくれます。この「生成→テスト→エラー→修正」のループを圧倒的なスピードで回せることこそが、AI駆動開発の最大のメリットであり、プロトタイプ思考の真骨頂です。
チームで共有すべき「変換レシピ」
プロジェクトが進行するにつれ、「このパターンのAWSリソースは、Azureではこう変換するのが最適」という実践的な知見が蓄積されていきます。このナレッジを属人化させず、チーム全体で共有することが組織の力となります。
例えば、「S3バケットをAzure Blob Storageに変換する際のセキュリティ設定」や「Route53をAzure DNSへ移行する際のマッピングルール」などをMarkdown形式でリポジトリに保存し、プロンプトのコンテキストとして再利用することで、チーム全体の変換精度と開発スピードはさらに加速します。
まとめ
AIを活用したIaCのマルチクラウド変換は、単なる作業時間の短縮にとどまりません。それは、不慣れな環境におけるリスクを可視化し、ガバナンスを効かせて制御するための強力な戦略となります。
- AIを翻訳機兼検査員にする: コード生成と同時に検証用ポリシー（Rego/Test）も生成させる。
- コンテキストを注入する: 組織の命名規則やセキュリティ基準をプロンプトに含め、品質をコントロールする。
- 循環型フローを回す: エラーをAIにフィードバックし、変換精度を高め続ける。
この実践的なプロセスを回すことで、新しいクラウド環境に対する不安を払拭し、自信を持ってプロジェクトを推進できるはずです。技術の本質を見極め、AIを強力なパートナーとして活用することで、ビジネスの成功への最短距離を描いていきましょう。
コメント