AI×Terraformで進化する、柔軟でシンプルなIaC

参考になった

会員限定コンテンツです。無料登録すると制限なしでお読みいただけます。

無料登録してアーキテクチャを見る

レビュー投稿日の情報になります

株式会社WiseVine / 高見道人

メンバー / SRE / 従業員規模: 51名〜100名 / エンジニア組織: 11名〜50名

最終更新日2025/12/04投稿日2025/12/09

ツールの利用規模	ツールの利用開始時期	事業形態
51名〜100名	2024年	B to B

ツールの利用規模	51名〜100名
ツールの利用開始時期	2024年
事業形態	B to B

アーキテクチャ

会員限定コンテンツ無料登録してアーキテクチャを見る

アーキテクチャの意図・工夫

ディレクトリ構成など

モジュール側との責務の分離の徹底

infra/
├── terraform/          # DnR Terraformコード
│   ├── envs/          # 環境別設定
│   │   ├── dev/       # 開発環境
│   │   ├── stg/       # ステージング環境
│   │   └── prod/      # 本番環境
│   └── modules/       # 再利用可能モジュール
│       ├── networking/  # VPC、サブネット、ゲートウェイ
│       ├── aurora-db/   # RDS
│       ├── ...
└── docs/               # アーキテクチャドキュメント

公式terraformモジュールの活用・環境ごとのファイルの肥大化の抑制

module "aurora" {
  source = "git::https://github.com/terraform-aws-modules/terraform-aws-rds-aurora.git?ref=4025104de5268fe6063a9a95269a4e290692aa0d" # v9.15.0

  name            = var.cluster_name
  engine          = "aurora-postgresql"
  engine_version  = var.db_engine_version
  master_username = var.db_user
  database_name   = var.db_name
  port            = var.db_port
  instances       = var.db_instances

ベストプラクティス準拠

Checkov / Trivy / Renovate等によるセキュリティ強化・ベストプラクティス準拠
pre-commitによる各種チェックの自動化
SOPS + SMSパラメータストアによる、シークレットキーのリポジトリ管理

AI活用

AIへの実装ルールの細かな指定、調整
- レビュー時の確認事項の詳細化
  - 例：モジュール側に環境独自の項目はないか？
  - 例：環境側に環境共通コードが漏れて、肥大化していないか？
- デバッグ時の権限確認の手法の記載
  - aws cliのコマンドの利用の読み込み系コマンドの許可／書き込み禁止
GithubActions CIでの自動レビュー

導入の背景・解決したかった問題

導入背景

ツール導入前の背景

当社では、AWS CDK による IaC(Infrastructure as Code) の導入は比較的早い段階から進めており、もともと存在しないわけではありませんでした。また、CI/CDパイプラインなどの基盤もそれなりに整備されていたと言えます。

しかし、こうした環境下にあっても、時間の経過とともに様々な技術的負債が蓄積しつつありました。

具体的な課題

私たちが直面していた課題の核心は、主にAWS CDK Pythonを用いたインフラ統合管理の複雑さと、初期設計の拙さにありました。複数のアプリケーションや開発環境（DEV, STG, PRDなど）のインフラストラクチャを一つのコードベースで管理していたため、以下のような問題が発生していました。

複雑なモジュール化とスパゲッティ化、そして属人化： コードのモジュール化を進めるほどに複雑になり、特定の環境やアプリケーションのみを対象とした修正が困難になっていきました。「このアプリのDEV環境だけ設定を変えたい」といった要望に対応しようとすると、モジュール内部の条件分岐が際限なく増え、コード全体が読みづらい「スパゲッティコード」と化していきました。
レガシー環境への引きずられ： 新しいアプリケーションのインフラを構築する際、過去のアプリケーションの環境設定や制約に引きずられてしまうことが多々ありました。細かく修正したい、あるいはモダンな設定にしたい箇所は山ほどあったものの、影響範囲の大きさを考えると、リスクを鑑みて実行できないケースも多くありました。
CloudFormation特有の制約： CDKが出力するCloudFormationスタックは、特に運用面で厄介でした。インフラコードの修正を行う前に、「軽い気持ちでDEV環境でコンソールから手動で設定を試す」という検証が事実上できなくなっていました。コードを修正すれば、その影響が全体に及ぶリスクが高まる一方、事前にコンソールで試行錯誤することも許されない、という二重の制約がありました。
学習コスト： AWS CDKを導入した当初のメンバーの退職に伴い、残ったメンバーのスキルセット的にHSC Terraformの方が良かった。CDKのみならず、CloudFormationの学習コストも結構高くつく状況でした。
ナレッジの適応コスト： 外部にインフラに関するナレッジは豊富なように見えましたが、弊社のコード設計上、気軽に適応出来なものも多くなっていました。既存のインフラを壊さずに利用可能な、柔軟性のあるインフラ構成の設計やモダンなIaCの知見は少なく、最新のナレッジをうまく取り込めない状況に陥っていました。

目指すべき理想の姿

こうした負債と制約を解消し、開発効率とインフラの保守性を高めるために、私たちは以下のような状態を目指しました。

柔軟性とシンプルな構成の両立： 新しいアプリケーションや環境ごとに、必要な調整を一定の範囲で許可する柔軟な構成を目指しました。それと同時に、コード自体はシンプルで、修正の意図が誰にでも分かりやすい構成に刷新したかったのです。
Terraformへの移行判断： どうせ新規アプリケーションのインフラを再構築するのであれば、将来的、汎用性やシンプルさ、担当者たちのスキルセット等を考慮し、既存のCDKではなくTerraformを採用する、という判断に至りました。
モノレポ化とインフラコードの独立： 最終的な目標として、アプリケーションコードと同じリポジトリ（モノレポ）の中にインフラコードも閉じ込め、アプリケーションとインフラストラクチャの責任範囲をより明確にしたいと考えていました。

比較検討したサービス

AWS Cloud Development Kit

比較した軸

管理しやすい仕組みかどうか
後任者が見ても、どこをどう操作すれば分かる
アプリケーションや環境ごとに柔軟にインフラ変更を出来る

選定理由

インフラ担当者(2名)がcdkに慣れていない
cdkの学習コストが高めの印象
- cdk自体だけではなく、CloudFormation自体の学習もほぼ必須。
インフラ担当者(2名)もナレッジや思想的にterraformの方が好きだった
- 宣言的なコードで、インフラとコードの対応が明確

導入の成果

改善したかった課題はどれくらい解決されたか

ほぼ解消したと思われる

どのような成果が得られたか

インフラ実装のリードタイム短縮
AI によるたたき台＋公式 Terraform モジュールの活用で、0→1 のインフラ実装にかかる時間が大幅に短縮された。
セキュリティ事故予防の「一次フィルタ」が常時稼働
Checkov / Trivy / tflint などの自動チェックにより、本番前に権限過多・セキュリティホールとなる設定を機械的に弾けるようになった。
「どこを触ればいいか」が誰にでも分かる構成へ
環境ごとに root module を分離したことで、「このアプリのこの環境を変更するには、このディレクトリ」という対応関係が明確になり、属人性が低下した。
インフラ担当のボトルネック解消とチーム全体の自走化
AI レビューと自動チェックが一次審査を担うことで、人間レビューは本質的な設計・要件に集中でき、インフラ担当2名に負荷が集中しづらくなった。

導入時の苦労・悩み

TrivyやCheckov等で、セキュリティを強化したインフラ構成を目指したが…暗号化や権限管理が複雑化
デプロイは出来るがアクセスが出来ないが頻発
- 丁寧な動作確認と権限チェックが必要
- AIを活用することで、デバッグはかなりやりやすかった
- とりあえず全権限を渡して…とか、とりあえずResourceは"*"でみたいな雑な設定は防げている

導入に向けた社内への説明

上長・チームへの説明

SREチームでのMTG

活用方法

新規アプリケーション立ち上げが安定するまでは、何かしら操作予定

よく使う機能

Claude Codeの自動レビューはみんなよく使っている

ツールの良い点

インフラ管理がわかりやすい

ツールの課題点

最新機能への対応が遅い場合がある
- awsccを併用しながら記述している

ツールを検討されている方へ

今回Terraformが採用されたのは、たまたま弊社メンバーのスキルセットや思想とTerraformがマッチしていただけです。もし、既存のAWS CDKでのインフラ管理が適切に設計・構成されていたら、そもそも置き換えを検討していませんでした。とりあえず書いていった初期コードに実稼働のインフラが引きずられ、身動きがとりづらくなった結果のTerraformの採用です。しかし、これはAWS CDKに限らずに、新規に構成するTerraformでも同じ轍を踏む可能性はあります。

「とりあえず書いてみる」はNG
初期の適切な設計・構成が大事
- ディレクトリ構成やモジュール構成のベストプラクティスの調査・検討
- セキュリティやCI/CDのベストプラクティスの調査・検討
設計を怠ると後々構成変更が困難になり、沼にハマる
後々セキュリティ対策をしようと思っても、限界が生じてしまう
Terraformはベストプラクティスが非常に多く、初期設計もやりやすいので、しっかり調べてから作り出して欲しい