クラウド

IaCとは？インフラをコードで管理する考え方をTerraformで解説

2026/10/15 シリーズ「クラウド入門」 第9回 / 全10回

🤖 AIを使用して執筆

手作業で作った構成は、同じものを自動では作り直せない

ソフトウェアの開発者の Martin Fowler は 2012 年、手作業で設定を重ねたサーバーを「スノーフレークサーバー」（雪の結晶のように一つずつ形が違うサーバー）と呼んだ¹。設定は、コマンドの入力、画面の操作、設定ファイルの書き換えを組み合わせて入れる。その結果、どのサーバーも少しずつ違うものになる¹。Fowler は、スノーフレークサーバーの第一の問題を、作り直すのが難しいことだとした¹。設定のどの部分が大事で、どの部分が出荷時のままなのかも分からなくなる¹。

同じ年に Fowler は、記録されない場当たりの設定の変更を「構成のドリフト」と呼び、ドリフトはスノーフレークサーバーへ続く道だと書いた²。AWS も、開発の環境での変更がテストの環境に入れ漏れると、二つの環境の間で設定がずれると説明している³。Microsoft は、IaC がない場合、環境ごとの設定を別々に保つことになり、やがてどの環境も自動では作り直せない固有の構成になると書いている⁴。

クラウドがそれまでのやり方とどう違うかを説明するために、サーバーの扱い方のたとえも使われるようになった。Randy Bias は、2011 年か 2012 年ごろ、顧客にその違いを説明する言い方を探していて、Bill Baker の講演から「ペットと家畜」のたとえを借り、クラウドの文脈で使い始めたと書いている⁵。古いやり方では、サーバーはペットのように名前を付けて手で世話をし、一台が止まると全員で対応する。新しいやり方では、サーバーは家畜のように番号で呼び、一台が止まれば取り替える⁵。取り替えるには、同じものを自動で作り直せなければならない。

クラウドでは、仮想マシンもネットワークも、事業者の API（プログラムから操作するための窓口）を呼べば作れる。そのため、ネットワークの配線のように手で作るしかなかったものまで、テキストで書き表せるようになった。AWS の Well-Architected フレームワークは、運用上の優秀性の柱にある設計原則「可能な場合は安全に自動化する」で、アプリケーションのコードに使うのと同じ工学の原理を環境全体に当てはめられると書く。アプリケーション、インフラ、設定、手順を、コードとして定義して更新できるとしている⁶。

IaC とは：構成をコードで書き、バージョン管理する

IaC は、手作業の操作や設定の代わりに、コードを使ってインフラを用意し管理することである³。Google Cloud は、画面の操作やコマンドラインのスクリプトの代わりにコードを使う方法だと説明し、同じ構成を何度でも適用して、開発、テスト、本番の環境を同じ形で作れるとしている⁷。Microsoft は、同じソースコードが常に同じプログラムを生むように、IaC は適用するたびに同じ環境を生むと書く⁴。変更するときは、実物ではなくコードを書き換える⁴。

IaC の書き方には二つの型がある。

宣言型のツールは、今の構成と書いた形を比べ、足りないものを作り、違うものを直し、管理している資源のうちコードから消えたものを消す⁸。そのため、同じコードを何度適用しても、ツールが管理する範囲は同じ構成になる。始める前の状態にかかわらず同じ結果になるこの性質を冪等性と呼び、Microsoft は IaC の重要な原則に挙げている⁴。Microsoft は、できる限り宣言型を使うべきだとしている⁴。一方で AWS は、命令型は書くのが難しいが、作る順番が重要な複雑な構成では必要になると書いている³。ただし、宣言型のツールも、資源どうしの依存の関係から、作る順番を自分で決める⁸。

構成を自動でそろえる考え方は、クラウドより前からあった。Mark Burgess は 1993 年に、サーバーの設定を管理するツール CFEngine を書き始めた。本人の紹介ページは、Burgess が持ち込んだ「状態の収束」（設定を望む状態へ寄せていくこと）などの考え方が、設定の管理の分野で使われる言葉になったと書いている⁹。CFEngine が扱ったのは、一台一台のサーバーの中の設定だった。クラウドが現れると、サーバーやネットワークそのものをコードで作れるようになった。AWS は 2011 年 2 月に CloudFormation を公開した。資源を「テンプレート」と呼ぶテキストファイルに書けば、CloudFormation が依存の関係を考えて正しい順に作る¹⁰。HashiCorp は 2014 年 7 月に Terraform を公開し、複数の事業者にまたがるインフラ全体をコードで書けるとした¹¹。

Terraform の仕組み：書く、計画する、適用する

Terraform は、クラウドの資源も自社の設備の資源も、人が読める設定のファイルに書いて、バージョン管理し、再利用し、共有できるようにする IaC のツールである⁸。設定のファイルは宣言型で、インフラの最終的な形を書く⁸。

基本の流れは、三つの段階でできている⁸。

1. 書く： 資源を設定のファイルに書く。書いた後、terraform init で作業のディレクトリを準備する。このとき、設定が使うプロバイダー（後で説明する、事業者ごとの追加の部品）が取り込まれる¹²。
2. 計画する： terraform plan を実行すると、Terraform は既にある資源の今の状態を読み、設定と比べ、何を作り、変え、消すかを示す計画を作る¹³。この段階では、実物は何も変わらない¹³。
3. 適用する： terraform apply を実行すると、計画を示して承認を求め、承認されたら計画どおりの操作を行う¹⁴。操作は、資源どうしの依存の関係に従った順に進む⁸。資源を消す操作も含まれる¹⁴。

HashiCorp は、計画の出力がチームの中で互いの変更を確かめる機会になり、害のある変更を適用の前に見つけられると書いている¹⁵。この流れは一度で終わらず、次に変えたくなったら最初から繰り返す¹⁵。

Terraform は、プロバイダーと呼ぶ追加の部品を通して、クラウドの事業者や SaaS の API とやり取りする¹⁶。資源の種類は、どれもいずれかのプロバイダーが用意している¹⁶。AWS、Azure、Google Cloud のプロバイダーもある⁸。HashiCorp は、事業者ごとに操作の仕方が違うなかで、Terraform は同じ流れで複数の事業者を管理できるとしている¹⁷。ただし、共通なのは流れであって、コードではない。ある事業者の仮想マシンを書いたコードは、その事業者のプロバイダーの資源の種類で書かれているので、別の事業者でそのまま使うことはできない。

状態（ステート）のファイル：コードと実物を結ぶ記録

Terraform は、どのコードの資源が、クラウドのどの実物に当たるかを、状態（state）と呼ぶ記録で覚えている¹⁸。HashiCorp によれば、初期の試作では状態のファイルを持たず、実物に付けた目印（タグ）で対応を探していた。しかし、タグを付けられない資源も、タグを扱えない事業者もあり、すぐに問題に突き当たった¹⁹。

状態のファイルは、既定では手元に置かれる¹⁸。チームで使うと、各自が最新の状態を持ち、同時に二人が実行しないよう気をつける必要がある²⁰。そのため、状態をチームで共有する保存先に置き、書き込む間はほかの人が書けないようにする（ロック）²⁰²¹。ただし、すべての保存先がロックに対応しているわけではない²¹。

状態のファイルには、扱いに注意が要る。状態と計画のファイルには、設定に直接書いた秘密の値だけでなく、データベースの初期のパスワードのように、資源が持つ秘密の値も入る²²。手元の状態のファイルは、暗号化されないまま（平文で）保存される²²。HashiCorp は、状態のファイルを、バージョン管理のリポジトリや、ロックと権限の管理ができない保存先に置かないよう勧めている¹⁸。新しい版の Terraform には、値を状態にも計画にも残さない書き方（ephemeral）もある²²。

コードの外での変更は「ずれ」になる

IaC で管理していても、画面などから資源を直接変えることはできる。AWS は、CloudFormation で管理している資源を、コンソール（管理用の画面）から変えられる例を挙げ、変更には誤って行うものも、障害への対応で意図して行うものもあると書いている²³。実物の設定が、コードから期待される設定と違う状態をドリフトと呼ぶ²³。

ずれを放っておくと、次の更新で困ったことが起きる。AWS は、CloudFormation の管理する資源を外から変えないよう勧め、外から変えた後で更新すると、直接の変更は捨てられ、テンプレートの設定に戻ると書いている²⁴。外での変更が、気づかないうちに消えることがある。

ずれを見つける仕組みは、各ツールにある。Terraform は、既定では計画のたびに、管理している資源の今の値を読み直してから計画を作る。読み直しを止める指定もあり、そのときは外での変更が計画に現れない¹³。障害の対応などで意図して外から変えた場合は、状態だけを実物に合わせる「refresh-only」の計画も作れる。この計画は、最後に適用した後に Terraform の外で変わったものを一覧で示す¹³²⁵。CloudFormation には、スタック（まとめて管理する資源の組）の実際の構成が期待とずれているかを調べる、ドリフトの検出がある²³。

ずれの検出には限りがある。Terraform が読み直すのは、状態に記録されている既にある資源である¹³¹⁸。画面で新しく足した資源は、記録にないので計画に現れない。Terraform には、既にある資源をクエリで探して取り込む手順もあるが、何を探すかは利用者が指定する²⁶。CloudFormation のドリフトの検出も、対応していない種類の資源を調べない²³。Fowler は、設定を当て直す方法は、ツールが管理すると決めた範囲のずれしか見つけられず、その外のずれは直らないと書いている。そのうえで、一から作り直すサーバーなら元の設定からのずれも拾えるとして、両方のやり方を使うことに価値があるとしている²。計画もまた予測である。HashiCorp は、計画を作った後に別の変更が入ると、実際の結果が計画と変わりうるので、適用の直前の計画を確かめ直すよう勧めている¹³。

IaC でも、誤りは一度に広がり、秘密の値はコードに入りうる

自動化した操作では、誤った入力の影響も一度に広がる。2017 年 2 月 28 日、AWS の S3 の担当者は、決められた手順書に沿って、少数のサーバーを外すコマンドを実行した。入力の一つが誤っていて、意図より多くのサーバーが外れた²⁷。これは IaC のツールではなく運用のツールの事例だが、AWS が出した対策は自動化の全般に通じる。AWS は、そのツールがサーバーを外す速さを落とし、最低限の能力を下回る操作を止める安全の仕組みを足した²⁷。AWS の Well-Architected フレームワークも、自動化には、変更の速さの制限、エラーの上限、承認のような安全の仕組みを設けるよう勧めている⁶。

コードそのものにも、セキュリティの欠陥が入る。Rahman らは 2019 年、オープンソースのプロジェクトの Puppet（サーバーの設定を書く宣言型の言語）のスクリプト 15,232 本を、自分たちの検査ツールで調べた。セキュリティの弱さを示す書き方が 21,201 か所見つかり、そのうち 1,326 か所はパスワードを直接書いたものだった²⁸。直接書かれた秘密の値が残っていた期間の中央値は、データの組によって 15〜34 か月で、長いものは 98 か月だった²⁸。ただし、対象は Puppet でオープンソースのものに限られ、著者らも、命令型の言語や企業の中のコードには当てはまらないかもしれないと書いている²⁸。

IaC には始めて続ける手間がかかり、効果の根拠は調査に限られる

Microsoft は Well-Architected フレームワークで、IaC の代償として、新しい言語を学ぶ負担、特定のツールに縛られるおそれ、コードとツールを保守する手間を挙げている²⁹。画面やコマンドなら書く時間もテストも要らないので、設定の変更にかかる時間も増えるとしている²⁹。ソフトウェアの開発と運用の成果を調べている DORA も、IaC に移るには大きな工学の手間と進め方の変更が要るとして、小さく始めるよう勧めている³⁰。Guerriero らが 2019 年に 44 社の開発者に聞き取った研究では、今あるツールの支えはまだ限られ、IaC のコードをテストし保守する新しい方法が要るという声が出ている³¹。

IaC を勧める根拠として、DORA の 2019 年の報告は、それまでの調査で、システムの設定やスクリプトまで含めてバージョン管理することが成果を高めると分かっている、と書いている³²。ただし、DORA の調査は回答者へのアンケートを相関に基づく手法で分析したもので、効果を実験で確かめたものではない³²。

三社とも宣言型のツールを持ち、Terraform はどれにも使える

• AWS： CloudFormation（2011 年公開）がテンプレートから資源を作る¹⁰。更新の前に、変更がどの資源にどう効くかを確かめる変更セットもある²⁴。AWS CDK は、一般のプログラミング言語でインフラを書き、CloudFormation を通して作る³³。
• Azure： Resource Manager の JSON のテンプレートと、宣言型の言語の Bicep がある。Bicep で書いたファイルは、適用のときに JSON のテンプレートに変換される³⁴。適用の前に変化を予測して見せる what-if の操作もある³⁵。
• Google Cloud： Terraform を使って資源を作る Infrastructure Manager がある⁷。以前の Deployment Manager は 2026 年 3 月 31 日でサポートを終えた。新しい利用者は 2026 年 6 月 30 日から使い始められず、既にある利用者も 2027 年 6 月 30 日までしか使えない³⁶。

Terraform のライセンスは、2023 年に変わった。HashiCorp は 2023 年 8 月 10 日、今後の版のライセンスを Mozilla Public License 2.0 から Business Source License（BSL）1.1 に変えると発表した。HashiCorp と競合する製品を提供する場合を除けば、商用でも使い続けられるとしている³⁷。これに対して Linux Foundation は、同年 9 月 20 日、OpenTF と名乗っていたプロジェクトを OpenTofu として立ち上げ、ライセンスの変更への応えとなるオープンソースの代わりだとした³⁸。OpenTofu は 2024 年 1 月、Terraform から分かれたものとして最初の安定版を出した³⁹。IBM は 2025 年 2 月 27 日、HashiCorp の買収を完了した⁴⁰。

構成をコードにしても、別の事業者へは持ち運べない

構成をコードにすると、同じ環境を何度でも作り直せ、変更を適用の前に確かめられる。ただし、ツールが管理する範囲の外での変更と、コードそのものの誤りは防げない。また、Terraform のように複数の事業者に使えるツールでも、コードは事業者ごとの資源の種類で書かれている。コードがあるからといって、別の事業者へ移れるわけではない。特定の事業者に縛られることを、どこまで受け入れるのか。これが次の問いである。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。