みなさんの管理しているAWS環境は、属人化のブラックボックスに陥っていませんか？
創業期にスピード優先で手動構築したEC2、作成者不明のセキュリティグループ、ドキュメント化されていないS3の公開設定など、IaC（Infrastructure as Code）への移行を検討する際、既存リソースの取り込みに膨大な手間がかかることは、実務の現場でよく直面する課題です。
生成AIにすべてを任せたいところですが、AIは現在のインフラの「真の姿」を完全に把握しているわけではありません。
そこで今回は、既存の移行ツール「Terraformer」と、生成AI（LLM）の推論能力を組み合わせた「ハイブリッド移行手法」について解説します。理論だけでなく「実際にどう動くか」を重視し、確実な移行とスピーディーな作業を両立させる、極めて実践的なアプローチです。
レガシー環境のIaC化における課題とAIによる解決策
手動で構築された環境をコード化するプロジェクトが難航する最大の理由は、修正作業の多さにあります。
「状態」と「コード」の乖離
AWSのマネジメントコンソールで設定した内容は、複雑な依存関係を持つことがあります。これを記憶や断片的な資料だけでTerraformのコード（HCL）に書き起こすのは、至難の業です。
よくあるアプローチとして、「AIに構成図を読ませてコードを書かせる」という手法がありますが、サブネットIDやVPCのCIDR、セキュリティグループのルールなどを実環境と完全に一致させることは困難です。結果として、terraform plan を実行すると差分が大量に表示され、その修正に多大な時間を奪われてしまいます。
Terraformer単体利用の限界と手修正コスト
そこで、既存リソースからコードを生成するツール「Terraformer」を利用する方法が考えられます。Terraformerは実環境をAPIで解析しコード化するため、現状に即した正確なコードが得られます。
しかし、Terraformerが生成するコードは、決して人間にとって読みやすいものではありません。全ての値がハードコードされ、変数が使われておらず、モジュール化もされていません。そのため、コードを保守可能な状態にリファクタリングする作業に、結局は膨大な工数がかかってしまいます。
生成AI導入によるパラダイムシフト：比較表
ここで発想を転換しましょう。生成AIを「ゼロからコードを書かせる魔法の杖」ではなく、「汚いコードをきれいにする強力なリファクタリング・エンジン」として活用するのです。これにより、プロジェクトの成功確率とスピードは飛躍的に向上します。
以下に、従来の手法とAI活用時の比較をまとめました。
| 比較項目 | 手動書き起こし | ツール単体利用 (Terraformer) | ツール × AI ハイブリッド |
|---|---|---|---|
| 現状の再現性 | 低 (記憶頼り) | 高 (APIベース) | 高 (APIベース) |
| コード品質 | 高 (設計通り) | 低 (ハードコード) | 高 (AIが最適化) |
| 所要時間 | 膨大 | 中 (リファクタリング工数大) | 短 (AIが自動整理) |
| 主なリスク | 設定漏れ、人的ミス | 可読性が悪く保守不可 | AIの誤変換 |
この「ハイブリッド手法」により、正確な現状把握と、質の高いコード設計という、一見相反する要件の両立が期待できます。
アプローチ比較：AI単独生成 vs ツール×AIハイブリッド
技術的な側面から、AIにゼロからコードを書かせる手法と、既存ツールでエクスポートしたコードをAIに修正させる手法を比較分析します。特に最新のプロバイダー更新が頻繁な現在、経営と現場の両視点から「どちらがより本番環境に耐えうるか」を見極めることが重要です。
パターンA：構成図・要件定義からAIにHCLを生成させる
例えば、「t3.microのWebサーバーをパブリックサブネットに立てて」と最新のLLMに指示した場合、AIは以下のようなコードを生成することがあります。
# AIが生成したコード（例）
resource "aws_instance" "web" {
ami = "ami-0c55b159cbfafe1f0" # このAMI IDは実在するか不明
instance_type = "t3.micro"
subnet_id = "subnet-12345678" # 架空のID
tags = {
Name = "WebServer"
}
}
このアプローチには、構造的なリスクが潜んでいます。
- パラメータの幻覚（ハルシネーション）: AMI IDなどはリージョンや時期によって変わりますが、AIは学習データに基づいた（あるいは全く架空の）IDを使用する傾向があります。
- プロバイダーバージョンとの不整合: AWSプロバイダーは急速に進化しており、最新のv6.27.0（2025年12月時点）ではBedrock KnowledgeBaseとの統合や新しいIAM機能が追加されています。しかし、AIの学習データがこれに追いついていない場合、非推奨（Deprecated）な構文や古いリソース定義を出力する可能性があります。
- 実環境との乖離: 既存の
subnet-12345678が環境内に存在しない可能性があります。この状態でterraform applyを実行すれば、当然エラーとなります。
既存環境の「移行」において、コンテキストを持たないAIへのゼロベース指示は、かえって修正コストを増大させる要因となり得ます。
パターンB：Terraformerの出力をAIにリファクタリングさせる
一方、Terraformerなどのツールで現状をダンプすると、以下のような「汚いけれど正確な」コードが得られます。
# Terraformerが出力したRawデータ
resource "aws_instance" "tfer--i-0abcd1234efgh5678" {
ami = "ami-0123456789abcdef0"
instance_type = "t3.micro"
subnet_id = "subnet-0987654321fedcba"
associate_public_ip_address = true
private_ip = "10.0.1.50"
vpc_security_group_ids = ["sg-01234567"]
# ...他50行以上の属性...
}
このコードは実環境を100%反映しています。リソース名が自動生成されていたり、IPアドレスがハードコードされていたりと、可読性や管理性は低い状態ですが、間違いなく「動く」コードです。
ここでAIの役割を「生成」から「リファクタリング」にシフトさせます。「このリソース定義を整理して、変数は variables.tf に切り出して」と指示することで、AIは既存の正確な値を維持したまま構造のみを最適化します。
また、HCP Terraform Free Tierの廃止（2026年3月）に伴い、terraform import コマンドの使用に制限がかかるケースも出てきています。OSSツールであるTerraformerとAIを組み合わせるこのハイブリッド手法は、コストを抑えつつレガシー環境をコード化する、極めて現実的かつスピーディーな解となります。
精度の比較検証：S3バケットとEC2インスタンスの例
一般的な傾向として、AI単独生成の場合、S3バケットの暗号化設定やパブリックアクセスブロック設定において、記述漏れが発生しやすいことが確認されています。AIは「一般的な設定」を出力する傾向があるため、企業独自のセキュリティ要件やニッチな設定を見落としがちです。
さらに、Terraform 1.10で導入された ephemeral リソースのような最新機能や、AWSプロバイダーv6.19.0以降で対応したALBの高度なルーティング設定（URL書き換え等）が必要な場合、AI単独では古い知識に基づいたコードを生成するリスクが高まります。
対してハイブリッド手法では、ツールが現在の設定値を漏らさず出力するため、設定漏れのリスクを最小化できます。AIは、複雑なJSONポリシーを読みやすい aws_iam_policy_document データソースに変換したり、ハードコードされた値を variable に置換したりといった、人間が読みやすくするための作業に注力できるのです。
実践ガイド：Terraformer出力をAIで実用的なモジュールへ変換する
Terraformerが生成したコード（Raw HCL）は、そのままでは可読性が低く、保守運用には向きません。ここでは、AIアシスタントを活用して、これらの「動くだけのコード」を「人間が管理しやすいモジュール」へと昇華させる具体的なプロセスを解説します。まずは手を動かして試してみましょう。
Step 1: Rawデータの取得とクリーニング
まず、Terraformerなどのツールを使用して、既存のクラウドリソース情報をコードとして抽出します。
# AWS環境からEC2、セキュリティグループ、VPCをインポートする例
terraformer import aws --resources=ec2,sg,vpc --regions=ap-northeast-1
このコマンドを実行すると、generated/aws/ec2/instance.tf のようなファイルが生成されます。しかし、このファイルには tfer--instance-002did のような機械的なリソース名や、ハードコードされたIPアドレス、IDなどが大量に含まれています。これらをテキストとしてコピーし、AIへの入力データとして準備します。
Step 2: ハードコードされた値を変数化するプロンプト設計
ここが腕の見せ所です。AIに対して単に「きれいにして」と頼むのではなく、アーキテクトとしての設計意図（Design Intent）をプロンプトに明確に込める必要があります。特に、Claudeの最新モデルやChatGPTなどの高性能なLLMを使用することで、文脈を深く理解したリファクタリングが可能になります。
プロンプト例（Claudeの最新モデル / ChatGPT 推奨）:
あなたはシニアDevOpsエンジニアです。以下のTerraformコード（HCL）は、既存環境からツール（Terraformer）で自動生成されたものです。
これをIaCのベストプラクティスに基づき、保守しやすいようにリファクタリングしてください。具体的な要件:
- ネーミングの適正化: リソース名（
tfer--...）を、リソースに含まれるタグ（Nameタグ等）を参考に、人間が理解できる論理的な名前に変更すること（例:web_server,db_primary）。- 変数の抽出: AMI ID、インスタンスタイプ、VPC ID、サブネットCIDRなどの環境依存値はハードコードせず、
variables.tfで定義する変数を使用すること。- 最新構文の適用: Terraformの最新バージョン（v1.x系）の構文を使用すること。非推奨な記述は修正してください。
- 出力物の整理:
main.tf（リソース定義）とvariables.tf（変数定義）の内容を明確に分けて出力すること。terraformブロックやproviderブロックは今回は省略して構いません。対象コード:
（ここにTerraformerの出力を貼り付け）
このアプローチにより、AIは単なる置換作業だけでなく、タグ情報を読み取って「このインスタンスはWebサーバーである」と推論し、適切な変数名とリソース名を提案してくれます。
Step 3: ディレクトリ構造の最適化提案
コードのリファクタリングができたら、次はディレクトリ構造の設計です。フラットなファイル構造から、再利用可能なモジュール構成への移行をAIに支援させます。
追加プロンプト例:
リファクタリングしたコードに基づき、将来的な拡張性と再利用性を考慮したディレクトリ構成を提案してください。
条件:
- VPCやサブネットなどのネットワーク周りは
networkモジュールとして分離したい。- EC2やセキュリティグループは
appモジュールとして定義したい。- 環境（dev/prod）ごとの差分を管理しやすい構造にしたい。
AIは、一般的に以下のようなスタンダードな構成案を提示します。
.
├── main.tf # ルートモジュール（各モジュールを呼び出す）
├── variables.tf # 全体共通の変数
├── outputs.tf # 重要な出力値
├── modules/ # 再利用可能なモジュール群
│ ├── network/
│ │ ├── main.tf
│ │ ├── variables.tf
│ │ └── outputs.tf
│ └── app/
│ ├── main.tf
│ ├── variables.tf
│ └── outputs.tf
└── envs/ # 環境ごとの設定
├── dev/
│ └── terraform.tfvars
└── prod/
└── terraform.tfvars
このように、AIを単なる「コード生成機」としてではなく、「設計レビューを行うパートナー」として扱うことで、レガシー環境の移行作業における品質とスピードを劇的に向上させることができます。コードの細部は人間がチェックする必要がありますが、構造化の8割をAIに任せることで、エンジニアはビジネス価値を生む本質的なアーキテクチャ設計に集中できるようになります。
整合性確認とリスク管理：terraform planのエラーをAIとデバッグ
コード作成後、terraform plan を実行し、既存環境との整合性を確認します。このフェーズは移行プロジェクトにおける「真実の瞬間」であり、ここで発生する不整合をいかに効率的に解消するかが成功の鍵となります。
importブロックの自動生成
Terraform v1.5から導入された import ブロックは、レガシー移行の強力な武器です。既存のリソースIDとリソース名のマッピングリストさえあれば、AIを活用して import ブロックを大量に生成させることが可能です。
# AIに生成させるimportブロックの例
import {
to = module.app.aws_instance.web_server
id = "i-0abcd1234efgh5678"
}
これにより、手動での terraform import コマンド実行という苦行から解放され、ステートファイル（tfstate）への取り込みをコードベース（IaC）として宣言的に管理できます。
state乖離エラーのパターン別AI修正術
plan を実行すると、既存リソースとの属性不一致による差分やエラーが頻繁に発生します。ここで最新のAIモデル（ChatGPTの最新版やClaudeの最新モデルなど）の推論能力が活きます。
エラーログや差分情報をAIに解析させる際は、単にエラーメッセージを貼り付けるだけでなく、関連するリソース定義もセットで提示してください。AIはTerraformのプロバイダー仕様や依存関係を学習しているため、以下のような高度な修正案を提示できます。
- 属性名の不一致修正: 非推奨になった引数の代替案提示
- 依存関係の解決:
depends_onや参照変数の不足の指摘 - 型エラーの修正: 数値やリスト等の型不整合の自動修正
特に最新の推論モデルを利用することで、複雑な依存関係の解決策もより正確に導き出せるようになっています。
人間が必ずレビューすべき重要パラメータ
AIによる修正はあくまで「構文的な整合性」や「動作すること」を優先する傾向があります。セキュリティやデータガバナンスの観点では、以下の項目を必ず人間がレビューしてください。
- セキュリティグループのルール:
0.0.0.0/0（全開放）が意図せず含まれていないか。AIは接続性を確保するために制限を緩める提案をすることがあります。 - IAMポリシーの権限:
Action: "*"のような過剰な権限（AdminAccess相当）が付与されていないか。最小権限の原則（Least Privilege）に基づきチェックします。 - 削除保護（Deletion Protection）: データベースや重要なインスタンスの削除保護設定が、コード化の過程で外れていないか。
AIは「現状（As-Is）」を再現しようとしますが、その現状自体がセキュリティリスクを含んでいる場合もあります。最終的な安全性の判断と倫理的なAI活用の担保は、我々エンジニアの重要な責務です。
まとめ
レガシー環境のIaC化は決して容易な道のりではありませんが、Terraformerによる「現状の抽出」と、生成AIによる「コードの最適化・デバッグ」を組み合わせることで、効率化と品質向上を同時に実現できます。
最新のAIツールは日々進化しており、エンジニアが構造設計やリスク管理といった本質的な業務に集中するための強力なパートナーとなります。まずは動くプロトタイプを作り、AIを賢く活用しながら、持続可能でセキュアなインフラ構築を目指していきましょう。何か疑問があれば、ぜひチーム内で議論を深めてみてください。
コメント