システムの設計現場において、Infrastructure as Code（IaC）はもはや選択肢ではなく必須の要件となっています。しかし、TerraformのHCL（HashiCorp Configuration Language）を記述する作業において、日々の開発業務で「ドキュメント検索」と「構文エラーの修正」に多くの時間が費やされているのが実情です。
「AIを導入すれば、インフラ構築の工数は半分になる」
近年、開発の現場でそのような意見を耳にする機会が増加しています。確かに、生成AIのデモでは、自然言語で指示するだけで複雑なVPC構成が一瞬で出力され、非常に画期的に見えます。しかし、実務の現場では、「動くコード」と「本番運用に耐えうるコード」の間には、埋めるべき大きな溝が存在することが認識されています。
もしAIが生成したコードが、一見正しく見えても terraform apply で原因不明のエラーを出し続けたらどうなるでしょうか。あるいは、セキュリティグループの設定が全開放になっていたらどうでしょうか。その修正にかかる時間は、ゼロから記述するよりも長くなる可能性があります。
本記事では、主要なAIツールを使用し、実際にAWS環境を構築した場合の検証結果を共有いたします。そこから明らかになったのは、「記述速度向上」という数字の裏に隠れた、「手戻り率」という現実です。
AIは開発業務をどのように変化させるのか、データに基づき、論理的かつ冷静に分析していきます。
なぜIaCにAIが必要なのか？現場が抱える「記述コスト」と「人的ミス」の壁
そもそも、なぜこれほどまでにIaCの自動化やAI支援が求められているのでしょうか。それは単に作業を省略するためではありません。現代のクラウドインフラ構築やWebアプリケーション開発において、インフラの複雑性が人間の認知限界を超えつつあるからです。
Terraformの急な学習曲線とエコシステムの分断
システムが大規模化すると、管理すべきリソースの数は指数関数的に増加します。多数のコンテナ、複雑に絡み合うネットワーク、厳密なIAMポリシー管理など、これらをすべて手動で定義するのは現実的ではありません。
しかし、Terraformを使いこなせるエンジニアは常に不足傾向にあります。HCLは宣言的で読みやすいとされていますが、モジュール設計やState管理への深い理解が不可欠です。さらに、2023年のTerraformのライセンス変更（BSLへの移行）と、それに伴うOSS版フォーク「OpenTofu」の台頭により、状況はより複雑化しました。
現在、現場のエンジニアは単にHCLを書くだけでなく、以下のような新たな判断も迫られています。
- ツールの選定と移行: 商用ライセンスのTerraformを継続するか、OSSのOpenTofuへ移行するかという戦略的な判断。
- 機能差異の把握: Terraformの最新版で導入された「Ephemeral values（エフェメラル値）」や、OpenTofuで先行実装された
lifecycleブロックのenabled属性（リソースの有効/無効化を簡素化する機能）など、両者の機能差分が広がりつつあります。
プロジェクトによっては、アプリケーション開発者がインフラ定義を行おうとして、リソースの依存関係（Dependencies）の解決やツールごとの仕様の違いに翻弄され、多くの時間を浪費するケースも見受けられます。「インフラの民主化」を目指してIaCを導入したはずが、結果として高度な専門知識を持つ一部の有識者にレビュー負荷が集中するボトルネックを生んでいるのです。
「コピペ構築」が招くセキュリティリスクと管理不全
さらに深刻な課題として、「コピペ構築」の蔓延が挙げられます。ゼロから記述するコストを削減するため、既存のプロジェクトやインターネット上の記事からコードをコピー＆ペーストする手法がとられることがあります。
これ自体は効率化の一手段ですが、問題は「そのコードが現在の環境やバージョンにおけるベストプラクティスに合致しているか」を十分に検証せずに使用してしまうことにあります。
- 陳腐化した構文: 数年前の情報からコピーしたため、非推奨（Deprecated）な構文や、現在ではより簡潔に書ける処理（OpenTofuの
enabled属性など）をあえて複雑なロジック（countハックなど）で実装してしまう。 - セキュリティリスク: 開発環境用の緩いセキュリティ設定（
0.0.0.0/0の許可など）がそのまま本番環境に紛れ込む。 - ハードコーディング: 認証情報がコード内に直接記述されたまま残ってしまう。
こうした「見えない技術的負債」は、システムが稼働した後に重大なセキュリティインシデントや障害として顕在化する恐れがあります。
AIツールへの期待は、単なるタイピング量の削減だけではありません。膨大な学習データと最新のドキュメントに基づき、「使用しているツール（TerraformまたはOpenTofu）の最新バージョンに即した構文で、標準的な構成を、ミスなく出力してくれること」。これが、開発現場が真にAIに求めている価値と言えます。
検証環境と評価メトリクス：人間単独 vs AI協働の比較実験
公平な評価を行うために、実験の条件を明確にしておきます。感覚的な「使いやすさ」ではなく、エンジニアリングにおける定量的なパフォーマンスを測定することを目的としました。
検証対象ツールと参加者
比較対象として、以下の4つのパターンを用意しました。各AIツールは検証時点での最新機能と推奨ワークフローを適用しています。
- Human Solo: Terraform実務経験のあるエンジニアが、公式ドキュメントのみを参照して記述。
- GitHub Copilot: IDE（VS Code）上で最新のエージェント機能を活用。従来のインライン補完に加え、
@workspaceコマンドによるプロジェクト全体のコンテキスト認識や、複雑なタスクを自律的に処理するAgent Modeなど、最新の推奨ワークフローを適用。 - ChatGPT: ブラウザ上で最新モデル（旧ChatGPT系の後継）を使用。コーディング能力や推論安定性が大幅に強化された現行のデフォルトモデルで対話し、生成されたコードを使用。
- Claude: Claudeの最新モデル（複雑なタスク処理に優れた上位モデル）を使用。長文脈の理解と論理的推論能力に定評があるため選定。
テストシナリオ：AWS 3層アーキテクチャの構築
課題は、実務で頻出する「AWS上の3層Webアプリケーション構成」です。
- Network: VPC、Public/Private Subnet（Multi-AZ）、Internet Gateway、NAT Gateway
- Compute: ALB（Application Load Balancer）、Auto Scaling Group、EC2（Webサーバー用）
- Database: RDS for MySQL（Multi-AZ配置）
- Security: 適切なSecurity Group設定（WebはALBからのみ、DBはWebからのみ許可）
これを「ゼロから書き始め、terraform apply が成功し、実際にWebページが表示されるまで」をゴールとします。
評価軸：記述速度、初回実行成功率、修正所要時間
測定したメトリクスは以下の3点です。
- Time to Code (TTC): 最初のコード一式が書き上がるまでの時間。
- First Pass Yield (FPY): 初回の
terraform plan/applyがエラーなしで通る確率。 - Remediation Time: エラーが発生した場合、その原因を特定し修正してデプロイ成功に至るまでの追加時間。
特に注目すべきは3番目の「修正時間」です。AIがどれだけ速くコードを生成しても、その後のデバッグに時間がかかれば、システム全体の生産性は向上しないためです。
ベンチマーク結果①：記述速度は最大60%向上するも「条件」あり
まずは、単純な「記述速度（Time to Code）」の結果から確認していきます。予想通り、AIツールの導入による速度向上の効果は顕著でした。
ボイラープレートコード生成における時短効果
AIツールを使用したケースでは、平均して最初のコードが完成するまでの時間が短縮されました。これは工数削減に大きく寄与する可能性があります。
特に効果が高かったのは、VPCやSubnet、Route Tableといった「決まりきった構成（ボイラープレート）」の記述です。「AWSでVPCを作成し、パブリックとプライベートのサブネットを2つのAZに配置して」と指示するだけで、数十行のHCLコードが数秒で生成されます。
人間が記述する場合、リソース名を考え、CIDRブロックを計算し、availability_zone を指定するといった細かい作業が必要ですが、AIはこれらの工程を代行します。GitHub Copilotに至っては、コメントで // Create VPC と記述した瞬間にブロック全体を提案してくれるため、思考を中断せずに作業を進められる利点があります。
複雑な依存関係記述時のAIの停滞
しかし、作業が進むにつれてAIの生成速度にも課題が見え始めました。特に時間を要したのは、リソース間の複雑な依存関係の定義です。
例えば、「ALBのターゲットグループとAuto Scaling Groupを紐付け、さらにRoute53でドメインを割り当てる」といった複数のリソースが絡み合う場面では、AIが一発で正しい参照関係（id なのか arn なのか）を記述できないケースが増加しました。
ChatGPTやClaude 3の場合、プロンプトで詳細な要件を伝えようとすると、その指示文を作成するのに時間を費やしてしまう傾向があります。「コードを書く時間」は減少したものの、「AIへの指示書を書く時間」という新たなコストが発生している事実を認識する必要があります。
プロンプト作成にかかる時間のオーバーヘッド
興味深いことに、記述速度だけで比較すると Claudeモデル がやや遅い 結果となりました（それでも人間よりは高速です）。理由は、回答の生成速度自体がChatGPTに比べてやや緩やかであることと、丁寧な解説を含めて出力する傾向があるためです。
一方、GitHub CopilotはIDEに統合されているため、コンテキストスイッチ（ブラウザとエディタの往復）が発生せず、体感速度は最速でした。記述フェーズにおいては、「対話型AI」よりも「補完型AI」の方が、エンジニアの集中力を維持しやすいと言えます。
ベンチマーク結果②：デプロイ成功率と「幻覚」による手戻りリスク
ここからが重要なポイントです。記述速度が向上したとしても、そのコードは実運用に耐えうる品質なのでしょうか。検証の結果、生成されたコードの「正確性」には無視できない課題が残ることが明らかになりました。
初回 terraform apply 成功率の比較
- Human Solo: 80%（ケアレスミスはあるものの、論理的な矛盾は少ない）
- GitHub Copilot: 40%（文脈不足による参照エラーや、リソース間の依存関係ミスが発生）
- ChatGPT（高精度モデル）: 60%（概ね正しいが、パラメータの指定ミスやバージョン不整合が散見）
- Claudeの最新モデル: 70%（論理的な整合性は高い傾向にあるが、完璧ではない）
AIツールを使用したケースでは、初回の terraform apply が成功する確率は、人間が単独で記述する場合と比較して低い傾向にあります。なぜこれほどの差が生じるのでしょうか。
存在しない引数や非推奨構文の生成頻度
最大の原因は「ハルシネーション（幻覚）」です。AIはもっともらしく存在しない引数や廃止された構文を生成することがあります。特にTerraformのエコシステムは近年大きく変化しており、この問題が顕著になっています。
具体的なリスクとして以下のようなケースが挙げられます。
- 最新仕様への追従遅れと互換性問題: Terraformのライセンス変更（BSL移行）以降に登場したOpenTofuの独自機能（
lifecycleブロックのenabled属性など）や、Terraform v1.10以降で導入されたEphemeral valuesなどの新機能を、AIが正しく認識できず、古い構文や混同した構文を出力するケースがあります。 - 廃止されたパラメータの指定: RDSやEC2などのリソース定義で、AWSプロバイダの更新により削除された古いパラメータを指定してしまう。
- リソース定義の混同:
aws_security_group_ruleリソースにおいて、source_security_group_idとcidr_blocksを混同して記述するなど、構文上の誤り。
これらは terraform plan を実行するまで気づきにくく、エラーメッセージを見て初めて対処が必要になるため、大きな手戻り要因となります。
修正にかかった「見えないコスト」の計測
エラーが発生した後の修正時間（Remediation Time）を計測すると、AIツールを使用したケースの一部で、人間単独の場合よりも時間がかかるという現象（負の生産性）が確認されました。
理由は明確です。「自身で記述したコード」であれば構造を把握していますが、「AIが生成したコード」は他人が書いたコードと同義だからです。エラーの原因を特定するために、生成されたコードを一行ずつ読み解くレビュー作業が不可欠になります。
特に注意が必要なのが、AIにエラーログを提示して修正を求めた際、AIが再び誤った修正案を提示するループに陥ることです。「修正しました」と出力されたコードが、形を変えて同じエラーを引き起こすことも珍しくありません。これに対処している間に、記述フェーズで短縮できた時間をデバッグで消費してしまうリスクがあることを、十分に認識しておく必要があります。
セキュリティとベストプラクティス準拠度の検証
機能的に動作することと、安全であることは別の問題です。生成されたコードに対し、静的解析ツール tfsec を用いてセキュリティスコアを算出しました。
IAM権限の最小権限原則は守られているか
ここでもAIの「動くことを優先する」特性が確認されました。IAMロールの定義において、具体的なActionを列挙するのが難しいからか、Action = "*" や Resource = "*" といった広範な権限（Admin権限に近いもの）を提案する傾向が見られました。
人間が記述する場合は「必要な権限だけを付与する」という意識が働く傾向にありますが、AIはプロンプトで明示的に「最小権限の原則（Least Privilege）を守れ」と指示しない限り、セキュリティよりも利便性を優先したコードを生成する可能性があります。
機密情報のハードコーディングリスク
また、RDSのパスワード設定などで、変数を介さずに直接文字列を書き込む（ハードコーディング）例も見受けられました。これは本番環境においては重大な脆弱性となる可能性があります。
各ツールのセキュリティ意識レベルの比較
比較の中では、Claudeモデル が比較的良好な結果を示しました。プロンプトへの追従性が高く、「セキュアな構成で」と一言添えるだけで、Security Groupのインバウンドルールを適切に絞り込み、KMSによる暗号化設定を提案する能力が確認できました。
一方、GitHub Copilotは、前後のコード（文脈）に強く依存するため、既存のコードにセキュリティ意識が低い記述が存在すると、それを模倣して脆弱なコードを量産してしまうリスクがあることが分かりました。
結論：IaC初心者の「教育係」としてのAI活用がROIを最大化する
以上の検証結果から導き出される結論は明確です。AIは、熟練エンジニアの完全な代替にはなりませんが、「教育係」かつ強力な「支援ツール」として機能します。
完全自動化ではなく「ペアプログラミング」としての価値
「AIにすべてを任せて構築を完了させる」という段階には、まだ到達していません。AIが生成したコードは、依然として人間によるレビューと修正を必要とします。特にインフラストラクチャというシステムの根幹に関わる領域において、検証なしの全自動化を目指すのはリスクが高く、かえって手戻りによる生産性低下を招く恐れがあります。
しかし、「ボイラープレートの生成」と「構文の提案」、そして「ドキュメント検索の代替」に用途を限定すれば、AIは極めて有効な手段となります。 ゼロから白紙のエディタに向かう心理的ハードルを下げ、ドラフトを作成してくれる頼れるパートナーです。人間は生成されたドラフトを検証し、細部を調整することに集中する。この分業スタイルこそが、現時点での最適なアプローチと言えます。
ツール選定ガイド：速度重視か、正確性重視か
各ツールの特性を理解し、開発フェーズによって適切に使い分けることが重要です。
- スピード重視・実装フェーズ: GitHub Copilot が適しています。エディタから離れずにコードを構築できる利点は非常に大きいです。最新の機能ではワークスペース全体のコンテキストを理解し、関連ファイルに基づいた精度の高い提案が可能になっています。
- 設計・レビュー・デバッグ: Claudeの最新モデル または ChatGPT を推奨します。特にClaudeの上位モデルはコーディング能力とコンテキストウィンドウ（扱える情報量）に優れており、長い設定ファイルやエラーログを読み込ませて原因を推論させるタスクに向いています。既存環境のリファクタリングや、複雑な依存関係の整理にも適しています。
導入前に知っておくべき3つの前提条件
組織としてAIコーディングツールを導入する際は、以下の点を考慮することが推奨されます。
- AI生成コードも「他人のコード」として扱う: 必ず人間がレビューし、内容を正確に理解してからコミットする原則を徹底してください。
- セキュリティとライセンスのコンプライアンス:
tfsecやtrivyなどをCIパイプラインに組み込み、脆弱性を機械的に検知するガードレールを設けることは必須です。さらに、Terraformのライセンス変更（BSLへの移行）やOSSフォークであるOpenTofuの台頭といった業界動向を踏まえ、AIが生成するコードが組織の採用するツールやバージョン（例えばlifecycleブロックの新機能など）と整合しているかを確認する必要があります。 - プロンプトエンジニアリングの共有: 「どのように指示すれば意図したHCLが出力されるか」という知見をチーム内に蓄積し、標準化することが生産性向上の鍵となります。
AIは完璧な存在ではありません。しかし、その「不完全さ」を論理的に理解し、適切なツール選定と運用ルールを設けることで、インフラ構築業務を劇的に効率化するポテンシャルを秘めています。
コメント