フレームワーク活用ガイドひとことで言うと#
サーバーやネットワークなどのインフラ構成をコード（設定ファイル）として記述・管理し、手動操作をなくしてバージョン管理・レビュー・自動化を可能にするプラクティス。「手順書」ではなく「実行可能なコード」でインフラを定義する。
押さえておきたい用語#
- 宣言的IaC
- 「あるべき状態」を記述し、ツールが現状との差分を自動で解消するアプローチ。TerraformやCloudFormationが代表例。
- 手続き的IaC
- 「実行手順」を記述し、順番に処理を実行するアプローチ。AnsibleやChefが代表例。
- ドリフト（Drift）
- コードで定義した状態と実際のインフラ構成が乖離している状態。手動変更が主な原因。
- 状態ファイル（State）
- Terraformなどが管理する、現在のインフラ構成を記録したファイル。これとコードの差分で変更を検出する。
- モジュール化
- インフラコードを再利用可能な部品に分割すること。VPCモジュール、ECSモジュールなどを組み合わせて環境を構築する。
Infrastructure as Codeの全体像#
こんな悩みに効く#
- 手動でサーバーを構築しているため、環境ごとに微妙な差異がある
- 「この設定、誰がいつ変えたの？」が追跡できない
- 開発環境・ステージング・本番で構成が違い、環境依存のバグが発生する
基本の使い方#
プロジェクトに合ったIaCツールを選ぶ。
- Terraform: マルチクラウド対応。宣言的な構成管理
- AWS CDK / Pulumi: プログラミング言語でインフラを記述
- Ansible: 構成管理とプロビジョニング。手続き的
- CloudFormation: AWS専用の宣言的IaC
ポイント: 「宣言的 vs 手続き的」「マルチクラウド vs 単一クラウド」の軸で選定する。
現在のインフラ構成をコードに書き起こす。
- 既存リソースのインポート機能を活用する（terraform import等）
- 小さな単位から始め、徐々にカバー範囲を広げる
- コードで管理するリソースとしないリソースの境界を明確にする
ポイント: 一度に全部コード化しようとせず、重要なリソースから段階的に進める。
IaCコードをGitリポジトリで管理し、変更にはコードレビューを必須にする。
- PRベースでインフラ変更をレビューする
terraform planの結果をPRにコメントとして表示する- 変更履歴がGitに残るため、「誰が・いつ・何を変えたか」が追跡可能に
ポイント: インフラの変更もアプリケーションコードと同じプロセスで管理する。
IaCの適用（apply）をパイプラインで自動化する。
- PRマージ時に自動で
terraform applyを実行 - 環境ごとに適用順序を制御（dev → staging → production）
- ドリフト検出（手動変更の検知）を定期的に実行する
ポイント: 「手で触らない」を徹底する。コンソールからの手動変更を禁止するルールを作る。
具体例#
Before: AWSコンソールでEC2、RDS、ALBを手動構築。手順書はConfluenceにあるが最終更新は半年前。本番とステージングで微妙にセキュリティグループの設定が違う。
コード化: Terraform で VPC、サブネット、セキュリティグループ、ALB、ECS、RDS を記述。モジュール化して環境ごとの差分は変数ファイルで管理。
レビュープロセス: PRを作成すると、CIが terraform plan を実行し、変更内容をPRコメントに投稿。チームメンバーが「+2 EC2インスタンスが追加される」ことを確認してApprove。
結果: 新環境の構築が手順書を見ながら2日かかっていたのが、terraform apply の15分で完了するようになった。
状況: 金融系SaaS。東京リージョンの障害時に大阪リージョンでDR環境を立ち上げる必要がある。従来は手順書ベースで構築に8時間。RTO（目標復旧時間）4時間を満たせない。
IaC対応:
- 全インフラをTerraformモジュールで記述
- 東京と大阪で同一モジュールを使い、リージョンとサイズだけ変数で切り替え
- DR起動は
terraform apply -var="region=ap-northeast-3"を実行するだけ
結果: DR環境の構築時間が8時間から45分に短縮。RTOを大幅に下回り、金融庁の監査でも「再現性のある復旧手順」として高評価。
状況: 開発チーム15名が3つの共有開発環境を奪い合い。「俺のブランチでテストしたいから触らないで」が日常茶飯事。環境待ちで1日2時間のロス。
IaC対応:
- Terraformで開発環境テンプレートを作成
- GitHub Actionsで
/create-env feature-xxxコメントを打つと個人環境が自動生成 - PR クローズ時に環境を自動削除（コスト管理）
- 月間のAWSコストは共有環境比で+15%だが、環境待ちゼロ
結果: 開発者1人あたり日2時間の環境待ちが解消。15名 x 2時間 x 20営業日 = 月600時間の生産性向上。AWS追加コスト月10万円に対し、エンジニア人件費換算でROIは約30倍。
やりがちな失敗パターン#
- 手動変更を許容してしまう — 緊急対応でコンソールから直接変更し、コードとの差分（ドリフト）が発生する。手動変更は必ず後からコードに反映するルールを徹底すること
- 状態ファイル（tfstate）の管理を怠る — ローカルにtfstateを置いたまま複数人で作業し、状態が壊れる。リモートバックエンド（S3+DynamoDB等）で状態を共有管理すること
- モジュール化せずに巨大な1ファイルを作る — 数千行のmain.tfは読めないしテストもできない。リソースの種類や環境ごとにモジュールを分割すること
- シークレットをコードにハードコードする — DBパスワードやAPIキーがGitに残ると重大なセキュリティリスク。AWS Secrets ManagerやVaultで管理し、参照のみをコードに書くこと
まとめ#
Infrastructure as Codeは 「インフラもコードで管理する」 というシンプルだが強力なプラクティス。再現性、追跡可能性、自動化の3つを手に入れることで、インフラ運用の品質が劇的に向上する。まずは最も重要なリソースをコード化するところから始めよう。