---
title: "インフラのコード化（IaC）とは。手作業の構築をやめる理由｜アメリア・テクノロジー株式会社"
url: https://www.ameliatechnology.co.jp/blog/infrastructure-as-code-why/
description: "インフラのコード化（IaC）とは、クラウドのサーバーやネットワークの構成をファイルに書き、そのファイルから構築する方法です。手作業の構築で起きやすい問題、各クラウドの仕組み、変更の前の確かめ方、始め方を説明します。"
updated: 2026-11-14
publisher: "アメリア・テクノロジー株式会社"
---
# インフラのコード化（IaC）とは。手作業の構築をやめる理由

インフラのコード化（IaC）とは、クラウドのサーバーやネットワークの構成をファイルに書き、そのファイルから構築する方法です。手作業の構築で起きやすい問題、各クラウドの仕組み、変更の前の確かめ方、始め方を説明します。

2026.11.14 [クラウドと運用](https://www.ameliatechnology.co.jp/blog/category/cloud/)

執筆 [石田誠](https://www.ameliatechnology.co.jp/blog/author/ishida/)（グループCTO）

クラウドと運用（CLOUD & OPERATIONS）のコラム

## この記事の要点

- IaC は、構成をテキストのファイルで残すため、変更の履歴を追え、同じ環境を何度でも作り直せます。
- AWS は CloudFormation、Azure は Bicep、Google Cloud は Terraform を動かす Infrastructure Manager を提供しています。
- 画面から手で変えた設定は、コードとの食い違い（ドリフト）になるため、変更はコードを通す決まりとあわせて運用します。

インフラのコード化（IaC：Infrastructure as Code）とは、クラウドのサーバー・ネットワーク・データベースなどの構成をファイルに書き、そのファイルから環境を作る方法です。手作業で画面を操作して構築するやり方をやめる理由は、構成の記録が残り、同じ環境を何度でも同じように作り直せるようになるためです。

[インフラのコード化](https://www.ameliatechnology.co.jp/glossary/infrastructure-as-code/)は、開発と運用を近づける[DevOps](https://www.ameliatechnology.co.jp/glossary/devops/)の考え方とあわせて広まりました。この記事では、クラウドの構築と運用を担当する方や、委託先にどう頼むかを考える方に向けて、考え方と始め方を説明します。

## 手作業の構築で起きやすいこと

クラウドの管理画面は、操作すればすぐに資源ができるため、最初は手作業で構築されることが少なくありません。ただ、環境が大きくなり、担当者が入れ替わると、次のような問題が出てきます。

- どの設定を、いつ、誰が、なぜ変えたのかが分からない
- 本番の環境と検証の環境で、設定が少しずつ違ってしまう
- 障害や設定の誤りで環境を作り直すとき、元の設定を思い出せない
- 構成図や手順書が、実際の環境と合わなくなる

クラウドで起きる事故には、設定の誤りが原因になるものがあります。設定の誤りを防ぐ考え方は、[クラウドの設定ミスによる情報漏えいと、防ぎ方](https://www.ameliatechnology.co.jp/blog/cloud-misconfiguration/)にまとめていますが、手作業の構築を続ける限り、誤りに気づく手がかりそのものが残りにくくなります。

## IaC で何が変わるか

IaC では、構成を書いたファイルが、環境の「正しい姿」になります。

AWS の CloudFormation の説明では、必要な資源をすべて書いたテンプレートを作ると、CloudFormation が資源の用意と設定を担う、とされています。テンプレートはテキストのファイルなので、開発者がソースコードの版を管理するのと同じように、テンプレートの差分を追えば、インフラの変更を追えます。変更を戻したいときは、前の版のテンプレートを使えます。テンプレートから作った資源のまとまり（スタック）は、まとめて消すこともできます。

出典：[What is AWS CloudFormation?（AWS）](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)

テンプレートから環境を作る（AWS CloudFormation の例）

作る

必要な資源をすべて書いたテンプレート

CloudFormation が用意と設定を担う

資源のまとまり（スタック）

変更を追う

テンプレートの差分

ソースコードと同じように版を管理する

**インフラの変更を追える**。前の版のテンプレートで戻せる

この性質から、IaC には次の利点があります。

| 利点 | 中身 |
|---|---|
| 変更の履歴が残る | ファイルの差分で、何が変わったかを確かめられる |
| 同じ環境を作り直せる | 本番と同じ構成の検証の環境を、同じファイルから作れる |
| 変更の前に確かめられる | ファイルの変更を、ほかの人が確かめてから当てられる |
| 記録が実際と合う | 構成を書いたファイルそのものが、いまの構成の記録になる |

構成を書いたファイルは、[構成図と運用の記録を「生きた資料」にする](https://www.ameliatechnology.co.jp/blog/living-architecture-docs/)ための土台にもなります。

## 各クラウドの仕組み

3つのクラウドは、それぞれ IaC の仕組みを提供しています。

### AWS：CloudFormation

上で説明したとおり、テンプレートに資源を書き、スタックとして作ります。

### Azure：Bicep

Bicep は、Azure の資源を書くための言語で、作りたいインフラを Bicep のファイルに書き、開発のあいだ同じファイルを使って何度でも同じインフラを作れる、と Microsoft は説明しています。同じファイルを何度当てても同じ状態になる作りで、すでに書いたとおりの状態なら変更は起きません。当てる前に「what-if」という操作で、作る・変える・消す資源と、変わる設定を確かめられます。状態は Azure が保存するため、別に状態のファイルを管理する必要はない、とされています。

出典：[What is Bicep?（Microsoft Learn）](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/overview)

### Google Cloud：Infrastructure Manager

Infrastructure Manager は、Google Cloud の資源の作成と管理を自動にする管理型のサービスで、Terraform（HashiCorp の IaC の道具）の構成ファイルを、Google Cloud の中で実行します。構成ファイルはインフラの最終的な姿を書くもので、実行ごとのログ、使った構成、作った資源、状態のファイルが残ります。変更を当てる前に、どう変わるかを見るプレビューも作れます。

出典：[Infrastructure Manager overview（Google Cloud）](https://docs.cloud.google.com/infrastructure-manager/docs/overview)

Terraform は、AWS・Azure・Google Cloud のいずれにも使えるため、複数のクラウドを使う会社や、一つの書き方にそろえたい会社が選ぶことがあります。どの道具を選ぶかは、運用する人が慣れているか、ほかのシステムとそろえるかで決めます。

## 手で変えた設定は「ドリフト」になる

IaC を始めても、画面から手で設定を変えると、ファイルと実際の環境が食い違います。この食い違いを、ドリフトと呼びます。

AWS は、CloudFormation で作ったサーバーを EC2 の画面から直接変えるなど、CloudFormation の外での変更が起きうること、そうした変更はスタックの更新や削除を難しくすることを説明しています。CloudFormation のドリフトの検出は、テンプレートとパラメーターから期待される値と、いまの資源の値を比べ、違えばドリフトと判定します。資源が消されている場合も含みます。ただし、テンプレートやパラメーターで明示した値だけが比べる対象で、既定の値は対象外です。

出典：[Detect unmanaged configuration changes to stacks and resources with drift detection（AWS）](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html)

ドリフトを防ぐには、道具だけでなく運用の決まりが要ります。

1. 本番の環境の変更は、コードの変更を通して行う
2. 障害の対応などで手で変えた場合は、あとでコードに戻す
3. ドリフトを定期的に確かめ、見つかったら原因を記録する
4. 画面から変更できる権限を、必要な人に絞る

4つ目の権限の絞り方は、[最小権限の原則](https://www.ameliatechnology.co.jp/glossary/least-privilege/)にもとづきます。

## どこから始めるか

すでに手作業で作った環境がある場合、すべてを一度にコードへ書き直す必要はありません。

1. これから作る環境（新しい検証の環境など）から、コードで作る
2. 変更の多い部分（ネットワークの許可の設定、サーバーの台数など）をコードに移す
3. コードの変更を、ほかの人が確かめてから当てる流れを作る
4. 残りの部分を、変更の機会にあわせて少しずつ移す

委託先に構築を頼む場合は、成果物として「構成を書いたファイル」を受け取れるかを、契約の前に確かめておくと、後で別の会社に運用を引き継ぐときにも役立ちます。引き継ぎの考え方は、[開発会社を替えるときの引き継ぎと、そろえておく資料](https://www.ameliatechnology.co.jp/blog/vendor-switch-handover/)で説明しています。

## 当社のご支援

当社がクラウドの環境を構築する場合は、構成を書いたファイルとして残し、お客様の手元にも記録が残る形をご提案しています。手作業で作られた環境のコード化や、ドリフトの確かめ方を含む運用の決まりづくりは、[クラウドの構築と運用管理](https://www.ameliatechnology.co.jp/service/cloud/)でお手伝いしています。いまの環境の状態を整理したい場合は、[クラウドの自己診断](https://www.ameliatechnology.co.jp/diagnosis/cloud/)（無料）もお使いいただけます。

- IaC
- クラウド
- 運用
- DevOps

## この記事に出てくる用語

- [Infrastructure as Code（IaC）](https://www.ameliatechnology.co.jp/glossary/infrastructure-as-code/)
- [クラウド](https://www.ameliatechnology.co.jp/glossary/cloud/)
- [サーバー](https://www.ameliatechnology.co.jp/glossary/server/)
- [データベース](https://www.ameliatechnology.co.jp/glossary/database/)
- [DevOps](https://www.ameliatechnology.co.jp/glossary/devops/)
- [AWS（Amazon Web Services）](https://www.ameliatechnology.co.jp/glossary/aws/)
- [Microsoft Azure](https://www.ameliatechnology.co.jp/glossary/azure/)
- [Google Cloud](https://www.ameliatechnology.co.jp/glossary/google-cloud/)

この記事を書いた人

[石田誠](https://www.ameliatechnology.co.jp/blog/author/ishida/) グループCTO

インターネットの黎明期から、ホスティング事業の立ち上げや、インフラ・セキュリティのプロジェクトに携わってきました。現在は、AWS・Azure へのクラウド移行の支援と、業務アプリケーションの要件定義から実装までを担っています。

このコラムは一般的な情報の提供を目的としたもので、個別の状況への助言ではありません。製品・サービスの名前と内容は、記事の更新日の時点のものです。

## あわせて読みたい

- [Windowsサーバーと Active Directory を Azure へ移すときの考え方](https://www.ameliatechnology.co.jp/blog/windows-ad-to-azure/)
- [Google Cloud を選ぶ場面。データ分析と Google Workspace とのつながり](https://www.ameliatechnology.co.jp/blog/when-to-choose-google-cloud/)
- [Well-Architected の柱で、いまの構成を確かめる](https://www.ameliatechnology.co.jp/blog/well-architected-review/)

[クラウドと運用のコラムを見る](https://www.ameliatechnology.co.jp/blog/category/cloud/) [コラムの一覧に戻る](https://www.ameliatechnology.co.jp/blog/)

## 次の一歩

### クラウドの構築と運用を任せる

AWS・Microsoft Azure・Google Cloud の設計・構築・移行から、監視・運用・セキュリティまでを一つのチームで受け持ちます。監視は仕組みで24時間365日自動に回し、原因の調査と再発の防止は当社が担います。

[クラウドの構築と運用管理を見る](https://www.ameliatechnology.co.jp/service/cloud/)

### クラウドの状態を、無料で確かめる

15の設問に答えると、構成と管理・権限・守り・障害への備え・費用と体制の5つの分野の点数と、最初に取り組むことをまとめたレポートをその場でお届けします。

[クラウドの自己診断（無料）を受ける](https://www.ameliatechnology.co.jp/diagnosis/cloud/)

## ご関心に合わせて、お選びください。

[情報を集めている方へ会社案内、AI開発の例、セキュリティ診断の報告書の見本をお送りします。資料をダウンロード](https://www.ameliatechnology.co.jp/download/)[課題が見えている方へオンラインで30分、お話をうかがいます。費用はかかりません。無料で相談する](https://www.ameliatechnology.co.jp/contact/)[進め方を決めたい方へ2〜4週間で、優先順位と計画をまとめるAI活用の診断です。診断について見る](https://www.ameliatechnology.co.jp/pricing/#diagnosis)

---

出典：アメリア・テクノロジー株式会社「インフラのコード化（IaC）とは。手作業の構築をやめる理由｜アメリア・テクノロジー株式会社」 https://www.ameliatechnology.co.jp/blog/infrastructure-as-code-why/