1. はじめに：なぜ構築したのか
これまで社内のアンケート収集には MS Forms を利用していました。しかし、フォームが作成者個人のMicrosoftアカウントに紐付いており、異動や退職に伴う管理権限の移譲等の「個人依存」の課題を抱えていました。
そこで、プロジェクトのインフラとして組織的に管理可能で、かつセキュアな独自のアンケート基盤をAWS上に構築することとなりました。
私自身、 Terraformによる一からのIaC（Infrastructure as Code）構築は今回が初挑戦 でした。フロントエンドからインフラ、CI/CDまでを一人で、かつセキュアに完遂することを目指し、その「伴走者」としてAIをフル活用しました。
2. システム構成
プロジェクトの透明性を高めるため、ディレクトリ構造を整理し、各コンポーネントの役割を明確に分けました。
-
フロントエンド (frontend/): Next.js を採用。output: 'export' による静的エクスポートを行い、S3 + CloudFront で配信。
-
バックエンド (backend/): Lambda (Python 3.11) + API Gateway。DynamoDB へのデータ保存を担うシンプルな構成。
-
インフラ (terraform/): 全リソースを IaC で定義。tfstate は S3 backend で管理。
-
CI/CD (.github/workflows/): GitHub Actions を使用。OIDC 連携 により、AWS の認証情報を直接持たずに Assume Role するセキュアなデプロイフローを構築。
3. 初めてのTerraform × AI活用事例
Terraform 初挑戦の身にとって、AIは単なるコード生成ツール以上の存在でした。
知識のギャップを埋める対話
CloudFront 用の WAF を作成しようとした際、東京リージョンでは作成できないという仕様に直面しました。AI と対話し、Terraform の provider alias 機能を使って us-east-1 を併用する設定を導き出すことで、マルチリージョンにまたがるインフラ管理を実装できました。
このWAF用の us-east-1 alias 設定や、リソース間の依存関係など、公式ドキュメントだけでは読み解くのに時間がかかる初歩的かつ重要なポイントを、AIとの対話を通じて一つずつ解消していきました。
ログ解析による爆速トラブルシューティング
terraform apply 時の権限エラーや、WAFのIP制限設定で /32（CIDR表記）を忘れてデプロイに失敗した際、エラーログをそのままAIに投げることで、原因の特定と修正案の提示を数分で得ることができました。
高度なセキュリティ実装
OIDC（OpenID Connect） による GitHub Actions と AWS の連携について、複雑な信頼関係の設定も、AIに概念の解説と定義ファイルのベース作成を依頼することで、容易にセキュアな認証基盤を完遂することができました。
4. 「セキュア」な運用設計
業務利用に耐えうるレベルとするため、以下の実装にこだわりました。
-
WAFによる厳格なアクセス制限: CloudFront に AWS WAF を紐付け、会社の VPN（特定IP）以外からのアクセスをデフォルトでブロックするホワイトリスト方式を採用しました。
-
CI/CDの完全自動化: main ブランチへの push をトリガーに、Terraform によるインフラ更新と、フロントエンドのビルド・S3同期・CloudFront キャッシュ削除を連動して実行します。
-
IaCによる構成の透明化: すべての構築をコード化したことで、構成のブラックボックス化を防ぎ、プロジェクト内での管理を容易にしました。
5. 振り返りと結論
今回の取り組みを通じて感じたのは、「AIがいなければ、Terraform初挑戦でここまで複雑な権限周りやインフラ構成を一人で実装するのはかなり困難だった」 ということです。
AIは、詰まった時にいつでも相談でき、的確なアドバイスをくれる 「24時間稼働のシニアエンジニア」 のような伴走者でした。
AIを適切に活用することで、未知の技術領域への心理的ハードルを下げ、エンジニアとして一歩踏み込んだ「動く、かつセキュアなもの」を作り上げることができたと感じています。