Terraform/PulumiをAIアシストで書く：コード品質を保つプロンプト戦略
Terraform や Pulumi といった IaC（Infrastructure as Code）をAIに書かせると、開発速度は上がる一方、 不要なリソースの作成や、危険な設定値の混入といった品質面の問題が起きやすい。 レビュー・静的解析・プロンプト設計の3層でこれを防ぐ考え方を解説する。
背景・現状の課題
AIが生成するIaCコードは、動くコードとしては成立していても、以下のような問題を含みやすい。
- セキュリティグループが必要以上に広い範囲を許可している
- 使われなくなったリソースがコードに残り続ける
- モジュール間の依存関係が不必要に密結合になる
3層の品質担保アプローチ
| アプローチ | 役割 | トレードオフ |
|---|---|---|
| コードレビュー | 人が設計意図・妥当性を確認する最終防衛線 | AI生成コードの量が増えるとレビュー工数が線形に増える |
| 静的解析（tflint / Checkov 等） | 既知のアンチパターン・セキュリティリスクを機械的に検出 | ツールが検出しない意図の誤りは見逃す |
| プロンプト設計 | 生成段階で問題のあるコードそのものを作らせない | プロンプトの精度に効果が依存し、過信は禁物 |
プロンプト設計の具体例
「セキュリティグループは必要最小限のポートのみ開放すること」「命名規則は既存モジュールの `{env}-{service}-{resource}` 形式に従うこと」「削除保護（`prevent_destroy`）が必要なリソースには 明示すること」といった、プロジェクト固有の制約をプロンプトに含めることで、生成コードの手直し量を 大きく減らせる。制約は一度書いたら終わりではなく、レビューで頻出する指摘をプロンプトへ反映し続ける 運用にすると、時間とともに生成品質が上がっていく。
導入の進め方
いきなり全モジュールをAIアシストに切り替えるのではなく、まずは影響範囲の小さいモジュール （開発環境用のリソース定義等）から試し、レビューで頻出する指摘パターンを蓄積してからプロンプトに 反映していくと、本番環境のクリティカルなモジュールに適用する頃にはプロンプトの精度が十分に 上がった状態になる。
実装上の落とし穴と対策
静的解析ツールの警告を「AIが出したものだから」と鵜呑みにして無視する、あるいは逆に全て人力で 再確認するというのは非効率である。静的解析で機械的に弾ける項目（ポート開放範囲、暗号化設定の有無等）は CI でブロックし、人のレビューは「なぜこの設計にしたか」という意図の妥当性確認に絞ることで、 AIアシストのスピードを活かしながら品質を落とさない運用になる。
まとめ
AIアシストによるIaC生成は、レビュー・静的解析・プロンプト設計を組み合わせることで品質を保てる。 特にプロンプトへの制約の反映を継続的に行うことが、生成コードの手直しコストを下げる最も効果的な投資になる。
公式ドキュメント: Terraform Docs / Pulumi Docs
