IaCとTerraformの概要

この講座では、IaC（Infrastructure as Code）とTerraformの基本について学びます。

IaC（インフラのコード化）の概念とメリット
従来の手動構築との違い
代表的なIaCツールの紹介
Terraformの概要と特徴

1. IaCの概要

このセクションでは、IaC（Infrastructure as Code）の概要を解説します。

1.1 IaCとは

IaC（Infrastructure as Code）とは、「インフラのコード化」とも呼ばれ、サーバ、ネットワーク、データベースなどのインフラ構築・管理を、手動操作ではなく「コード」によって行う手法のことです。

従来は、OSの設定をコマンド入力で行ったり、AWSのようなクラウド環境を管理画面やCLIで操作して構築したりしていました。そのため、「操作ミスが発生しやすい」「再現がしにくい」「環境差分が起きる」といったリスクがありました。

それに対して、IaCはプログラミング言語のようなコードでインフラの定義を行う手法です。これにより、記述されたコードをレビューすることで、操作ミスが発生しにくいというメリットがあります。

また、Gitなどのバージョン管理システムを利用することで、誰が・いつ・何を変更したかを履歴として管理できるため、インフラ構成を再現しやすくなります。従来の手法では、試行錯誤しながらコマンドを実行したり画面を操作したりすることで、何を行ったかが可視化されず、再現ができないという課題がありましたが、IaCではそれを改善できます。

併せて、同じコードを実行すれば同じ環境が構築されるため、いわゆる「環境差分」を防ぐことができます。例えば、テスト環境で行った設定変更を本番環境に反映し忘れ、本番環境が正常に動作しないといった問題を回避できます。

このように、インフラをコードで管理することで運用上の様々なメリットが生まれます。

1.2 IaCの分類

IaCは、その利用目的と役割によって大きく3つのカテゴリに分類されます。

プロビジョニング

プロビジョニングは、システムの土台となるインフラリソース（サーバ、ネットワーク、データベースなど）の作成・管理を担う領域です。記述のアプローチによってさらに2つのタイプに分けられます。

宣言型（TerraformやCloudFormation）は、独自の定義言語やYAML/JSON形式のファイルを用い、最終的なインフラの「あるべき状態」を記述する方式です。手順ではなくゴールを定義するため、可読性が高く、インフラの状態管理に適しています。

💡 ポイント
「宣言型」とは「こうなっていてほしい」という最終状態を書く方式です。例えるなら、レストランで「ハンバーグ定食をください」と注文するようなイメージです。調理手順は気にせず、結果だけを伝えます。

📝 CloudFormationとは
CloudFormationとは、AWS公式が提供する宣言型のIaCサービスです。JSONまたはYAML形式のテンプレートファイルにAWSリソースの構成を定義し、AWSが自動的にリソースの作成・更新・削除を行います。AWS環境に特化しているため、AWSサービスとの連携が深く、新サービスへの対応も早いのが特徴です。一方、Terraformのように複数のクラウドを横断して管理することはできません。

📝 CloudFormationとは

CloudFormationとは、AWS公式が提供する宣言型のIaCサービスです。JSONまたはYAML形式のテンプレートファイルにAWSリソースの構成を定義し、AWSが自動的にリソースの作成・更新・削除を行います。AWS環境に特化しているため、AWSサービスとの連携が深く、新サービスへの対応も早いのが特徴です。一方、Terraformのように複数のクラウドを横断して管理することはできません。

命令型（CDK、Pulumiなど）は、TypeScriptやPythonなどの汎用プログラミング言語を用いてインフラを定義する方式です。プログラミング言語特有のループ処理、条件分岐、クラス継承などの機能を利用できるため、動的で複雑な構成を効率的に記述できるのが特徴です。一方、宣言型と比べると、コード量が増えやすく「あるべき姿」を一目で把握しにくい場合があります。

💡 ポイント
「命令型」とは「こうしてほしい」という手順を書く方式です。先ほどのレストランの例でいえば、「まずフライパンを熱して、ひき肉を入れて…」と調理手順を1つずつ指示するイメージです。

📝 AWS CDKとは
AWS CDK（Cloud Development Kit）とは、AWS公式が提供するIaCツールで、TypeScriptやPythonなどの汎用プログラミング言語を使ってAWSインフラを定義できるフレームワークです。CDKで記述したコードは、内部的にCloudFormationのテンプレートに変換されて実行されます。そのため、記述方法は「命令型」のプログラミングですが、最終的な動作は「宣言型」として処理されるという特徴があります。

📝 AWS CDKとは

AWS CDK（Cloud Development Kit）とは、AWS公式が提供するIaCツールで、TypeScriptやPythonなどの汎用プログラミング言語を使ってAWSインフラを定義できるフレームワークです。CDKで記述したコードは、内部的にCloudFormationのテンプレートに変換されて実行されます。そのため、記述方法は「命令型」のプログラミングですが、最終的な動作は「宣言型」として処理されるという特徴があります。

構成管理

プロビジョニングによって作成されたサーバ（OS）の内部に対して、詳細な設定を行う領域です。 OSの設定変更、ミドルウェアのインストール、設定ファイルの配置、ユーザ管理などを行い、アプリケーションが動作可能な状態に整えます。代表的なツールとして、AnsibleやChefなどが挙げられます。特にAnsibleはエージェントレスで動作し、構成手順をシンプルに記述できるため広く利用されています。

📝 Ansibleとは
Ansibleとは、Red Hat社が開発・提供するオープンソースの構成管理ツールです。YAML形式のPlaybookと呼ばれるファイルに、サーバに対して行いたい設定内容を記述します。エージェントレスで動作するため導入が容易で、SSHさえ接続できれば対象サーバを管理できます。学習コストが比較的低く、小規模な環境から大規模な環境まで幅広く利用されています。

📝 Ansibleとは

Ansibleとは、Red Hat社が開発・提供するオープンソースの構成管理ツールです。YAML形式のPlaybookと呼ばれるファイルに、サーバに対して行いたい設定内容を記述します。エージェントレスで動作するため導入が容易で、SSHさえ接続できれば対象サーバを管理できます。学習コストが比較的低く、小規模な環境から大規模な環境まで幅広く利用されています。

📝 エージェントレスとは
「エージェントレス」とは、管理対象のサーバに専用のソフトウェア（エージェント）を事前にインストールする必要がない方式のことです。例えば、AnsibleはSSH接続を利用して対象サーバを操作するため、対象サーバ側にはAnsible用の特別なソフトウェアを導入する必要がありません。一方、ChefやPuppetなどは対象サーバにエージェントをインストールして管理する「エージェント型」の方式です。エージェントレスは、管理対象が増えてもエージェントの導入・更新が不要なため、運用の手間が少ないというメリットがあります。

📝 エージェントレスとは

「エージェントレス」とは、管理対象のサーバに専用のソフトウェア（エージェント）を事前にインストールする必要がない方式のことです。例えば、AnsibleはSSH接続を利用して対象サーバを操作するため、対象サーバ側にはAnsible用の特別なソフトウェアを導入する必要がありません。一方、ChefやPuppetなどは対象サーバにエージェントをインストールして管理する「エージェント型」の方式です。エージェントレスは、管理対象が増えてもエージェントの導入・更新が不要なため、運用の手間が少ないというメリットがあります。

オーケストレーション

コンテナ化されたアプリケーションの運用管理を担う領域です。複数のサーバ（ノード）にまたがるコンテナの配置（デプロイ）、負荷に応じた数の増減（スケーリング）、障害時の自動復旧（セルフヒーリング）などを統合的に指揮・管理します。この領域の事実上の標準（デファクトスタンダード）として、Kubernetesが挙げられます。

📝 Kubernetesとは
Kubernetes（クバネティス／クーバネティス）とは、Google社が開発し、現在はCNCF（Cloud Native Computing Foundation）が管理するオープンソースのコンテナオーケストレーションツールです。略称としてK8s（「K」と「s」の間の8文字を省略した表記）とも呼ばれます。YAMLファイルでコンテナの構成を宣言的に定義し、デプロイ、スケーリング、障害復旧などを自動的に行います。AWS（EKS）、Google Cloud（GKE）、Azure（AKS）など主要クラウドがマネージドサービスとして提供しています。

📝 Kubernetesとは

Kubernetes（クバネティス／クーバネティス）とは、Google社が開発し、現在はCNCF（Cloud Native Computing Foundation）が管理するオープンソースのコンテナオーケストレーションツールです。略称としてK8s（「K」と「s」の間の8文字を省略した表記）とも呼ばれます。YAMLファイルでコンテナの構成を宣言的に定義し、デプロイ、スケーリング、障害復旧などを自動的に行います。AWS（EKS）、Google Cloud（GKE）、Azure（AKS）など主要クラウドがマネージドサービスとして提供しています。

💡 ポイント
オーケストレーションをIaCの一種として分類することに違和感を覚える方もいるかもしれません。実際、Kubernetesが管理するのはサーバやネットワークといった「インフラそのもの」ではなく、その上で動作する「コンテナ化されたアプリケーションの配置や運用」です。しかし、KubernetesもYAMLファイルで「あるべき状態」を定義し、コードとしてバージョン管理できるという点では、広義のIaCと同じ考え方に基づいています。そのため、本講座ではIaCの一分類として紹介しています。

💡 ポイント

オーケストレーションをIaCの一種として分類することに違和感を覚える方もいるかもしれません。実際、Kubernetesが管理するのはサーバやネットワークといった「インフラそのもの」ではなく、その上で動作する「コンテナ化されたアプリケーションの配置や運用」です。しかし、KubernetesもYAMLファイルで「あるべき状態」を定義し、コードとしてバージョン管理できるという点では、広義のIaCと同じ考え方に基づいています。そのため、本講座ではIaCの一分類として紹介しています。

1.3 IaCのメリット

IaCのメリットについて、技術的な観点で説明します。

再現性の向上

まず1つ目のメリットは「再現性の向上」です。

手動でインフラを構築している場合、手順書には書かれない「暗黙の手順」が発生したり、障害対応などで緊急で行った一時的な変更が記録に残らず埋もれてしまったりすることがあります。その結果、インフラのリプレイス時や再構築が必要になった際に、元と全く同じ環境を再現することが困難になるケースが少なくありません。

一方、IaCでは「同じコードを実行すれば、必ず同じ構成が作られる」ため、インフラの再現性を大きく向上させることができます。原則として「修正は必ずコードで行う」というルールを徹底することで、緊急時の変更もすべてコードとして記録に残るため、いつでも確実に同じ環境を再構築できるようになります。

また、特にTerraformなどのツールでは、コードと実際の環境の差分を検出する機能が備わっています。万が一、やむを得ず手動で緊急対応を行った場合でも、あとからコードとの不整合（設定のズレ）をツールが検知してくれるため、修正漏れに気づきやすく、環境の整合性を維持しやすい仕組みになっています。

環境差分の解消

2つ目に挙げられるのが「環境差分の解消」です。

システム開発の現場では、開発環境、検証環境、本番環境といった複数の環境を用意して開発を進めるのが一般的です。手動でこれらの環境を構築する場合、それぞれの環境で個別に設定作業を行う必要があるため、どうしてもオペレーションのミスや設定漏れにより、環境間で微妙な設定の「ズレ」が生じやすくなります。その結果、「検証環境では問題なく動作したのに、本番環境にリリースしたら動かない」といった、いわゆる環境差分に起因するトラブルが発生します。

IaCを導入した場合、基本的には「同じコード」を使用してすべての環境を構築することになります。例えば、サーバのスペックや台数といった一部のパラメータのみを変数として切り出し、OSの設定やネットワーク構成といった基本構造は全く同じコードを利用します。これにより、人間が意識せずとも環境ごとの構成差異を極めて小さくすることが可能です。

結果として、検証環境でのテスト結果に対する信頼性が大幅に高まり、安心して本番環境へのリリースを行うことができるようになります。

あるべき状態の定義

3つ目に挙げられるのが「あるべき状態の定義」です。

従来のシェルスクリプトや手動操作による管理は、いわゆる「命令型」のアプローチでした。これは、「サーバを作成する」「パッケージをインストールする」といった、実行すべき「手順（プロセス）」を記述する方式です。この場合、実行する人間が現在の環境の状態を把握し、「現在Aの状態だから、Bの手順を実行してCにする」という差分の計算を頭の中で行う必要があります。

一方、Terraformなどに代表される「宣言型」のIaCでは、最終的なゴールとなる「あるべき状態（Desired State）」をコードに記述します。例えば、「Webサーバが5台稼働している状態」と定義した場合、現在のサーバが3台であれば、ツールが自動的に「2台追加が必要」と判断して実行します。逆に、既に5台ある場合は「変更なし」と判断し、何も実行しません。

この考え方は、他のIaCツールでも同様です。例えば、プログラミング言語を使用するAWS CDKの場合、記述方法自体はプログラムですが、最終的にはCloudFormationという「宣言型」の定義ファイルを生成するため、本質的には「あるべき状態」を定義していることになります。また、Ansibleのような構成管理ツールも、処理自体は上から順に実行されますが、個々のタスクにおいて「このパッケージがインストールされている状態（state: present）」といった記述を行うことで、何度実行しても同じ結果になるよう設計されています。

このように、「現状がどうなっているか」や「どういう手順で変更するか」という複雑な判断をツール側に任せ、人間は「最終的にどうなっていて欲しいか」の定義のみに集中できる点は、運用の複雑さを下げる上で非常に大きなメリットとなります。

1.4 IaCのリスク

IaCのメリットや特徴を説明してきましたが、残念ながらリスクも多少存在します。ここでは、IaCのリスクをいくつか紹介します。

習得コストがかかる

IaCの導入における主な課題として、習得コストの高さが挙げられます。ツールを使いこなすためには専門知識が必要です。例えば、TerraformであればHCLという独自の記述言語、CDKであればPythonやJavaScriptなどのプログラミング言語への理解が不可欠です。直感的に操作できるGUI（管理画面）と比較すると、この学習コストが導入初期のハードルとなります。

しかし、ITエンジニアのキャリアという視点では、このハードルはメリットにもなり得ます。専門知識が必要であるということは、すなわち「参入障壁」が高く、誰でもすぐにできるわけではないため、習得することでITエンジニアとしての市場価値を高めることにつながります。

また、近年ではClaude CodeやGitHub CopilotなどのAIコード生成ツールが普及しており、従来よりも低いコストでコードを作成できるようになっています。もちろんAIに完全に依存することは推奨されませんが、生成されたコードの内容を理解した上で補助的に活用するのであれば、学習コストを抑えつつ効果的にIaCを導入することが可能です。

コードの管理が必要

IaCではインフラの管理主体が「コード」となるため、アプリケーション開発と同様に、コードの品質担保、テストの実施、バージョン管理といったルール作りが不可欠になります。

普段からコード管理に慣れている開発チームであればスムーズに導入できますが、従来のインフラ運用を主体としてきたチームの場合、Gitなどのツール操作やフローに慣れていないことも多く、導入初期に管理がうまくいかずトラブルになるリスクがあります。

しかし、これらのコード管理を適切に行うことは、IaCのメリットを最大化するための重要なステップでもあります。例えば、GitHubなどのプラットフォームを活用することで、変更履歴の追跡が容易になるだけでなく、チーム内でのコードレビューや、静的解析ツールによる自動チェックを必須化するなど、堅牢な運用フローを構築することが可能になります。これは結果として、手動運用では実現できなかった高い品質と安全性をインフラにもたらします。

IaC特有の運用リスク

IaCには、従来の手動運用にはなかった特有のミスやリスクも存在します。

例えば、Terraformのような「宣言型」の場合、インフラの現在の状態を記録した「Stateファイル（状態ファイル）」という重要なファイルを持ちます。手動操作などが原因で、このファイルと実際の環境の間にズレ（ドリフト）が生じると、ツールが現状を正しく認識できず、誤った修正や意図しない削除が行われるリスクがあります。

📝 ドリフトとは
「ドリフト（Drift）」とは、コードで定義した状態と実際のクラウド環境の間に生じる「ズレ」のことです。例えば、Terraformで「サーバ2台」と定義しているのに、誰かがAWS管理画面から手動で1台追加してしまった場合、「3台ある」という現実と「2台あるべき」というコードの間にドリフトが発生します。特に、複数人で運用する場合、適切に管理を行わないと「他人の修正を上書きしてしまう」「最新の状態が反映されていないことに気付かない」といった競合トラブルも発生しやすくなります。

📝 ドリフトとは

「ドリフト（Drift）」とは、コードで定義した状態と実際のクラウド環境の間に生じる「ズレ」のことです。例えば、Terraformで「サーバ2台」と定義しているのに、誰かがAWS管理画面から手動で1台追加してしまった場合、「3台ある」という現実と「2台あるべき」というコードの間にドリフトが発生します。特に、複数人で運用する場合、適切に管理を行わないと「他人の修正を上書きしてしまう」「最新の状態が反映されていないことに気付かない」といった競合トラブルも発生しやすくなります。

また、CDKのような「プログラム記述型」の場合、コードのロジックや記述順序がリソースの定義に密接に関わります。そのため、わずかなコードの構造変更が、予期せぬ「リソースの作り直し（削除と新規作成）」を引き起こすことがあり、プログラミング特有の注意が必要です。

これらIaC特有の挙動やリスクは、座学だけではすべてを把握しきれません。そのため、本講座ではこの後、実際にTerraformを操作していただきながら、現場でよくあるミスの事例や、それを回避・改善するための具体的な方法について解説します。

2. Terraformの概要

2.1 Terraformとは

Terraformとは、HashiCorp社が開発した、世界で最も人気のあるオープンソースのIaCツールの一つです。独自のHCLという言語を使って、「どんなインフラを作りたいか」を記載していきます。

まずはTerraformの位置づけについて説明します。

プロビジョニングが目的

Terraformは、インフラの土台を構築する「プロビジョニング」を主目的としたIaCツールです。

そのため、サーバ内部の設定やミドルウェア管理を行うAnsibleのような「構成管理ツール」や、コンテナの運用管理を担うKubernetesのような「オーケストレーションツール」とは、明確に役割が異なります。

プロビジョニングツールとしてのTerraformの役割は、AWSやGoogle Cloudといったクラウドプラットフォーム上で、ネットワーク、サーバ、データベースなどのインフラリソースそのものを作成・管理することにあります。

宣言型である

Terraformのもう一つの大きな特徴は、「宣言型（Declarative）」のアプローチを採用している点です。

Terraformでは、HCLにより最終的にインフラがどうなっていて欲しいかという「あるべき姿（Desired State）」を定義します。

これは、CDKや従来のシェルスクリプトなどの「命令型」とは対照的です。命令型では、「サーバがなければ作成する」「既に起動していればスキップする」といった具体的な「手順」や「条件分岐」を人間が記述する必要がありました。一方、宣言型であるTerraformでは、「サーバが1台ある状態」と「あるべき姿」を定義するだけで済みます。

現在の環境と比較して「何を変更すべきか」、あるいは「どのような手順で実行すべきか」といった複雑な処理はすべてTerraformが自動的に計算・実行します。そのため、利用者は裏側の複雑な操作手順を意識することなく、シンプルにインフラの構成定義に集中することができます。

マルチプラットフォーム対応

Terraformの非常に強力な特徴として、「マルチプラットフォーム対応」が挙げられます。

例えば、AWS公式のIaCツールであるAWS CloudFormationは、原則としてAWS環境の構築に特化しており、他のクラウドを管理することはできません。対してTerraformは、特定のクラウドベンダーに依存しない中立的なツールです。そのため、AWS、Google Cloud、Microsoft Azureといった主要なパブリッククラウドを、単一のツールで統一的に管理することができます。

さらに、Terraformの対応範囲はクラウドインフラ（IaaS）だけにとどまらず、「Provider（プロバイダ）」と呼ばれる連携プラグインの仕組みを利用することで、GitHubなどのバージョン管理ツール、DatadogやNew Relicといった監視ツール、さらにはKubernetes上のリソースなど、APIを持つ様々なSaaSやソフトウェアも同じ「コード」として管理対象に含めることが可能です。

これにより、クラウドベンダーや外部サービスが混在する複雑なシステム全体を、Terraformという一つの共通言語（HCL）とワークフローで効率的に管理できる点が、実務における大きなメリットとなります。

2.2 Terraformの構成要素

Terraformの主要な構成要素の関係を以下に示します。

flowchart LR
  HCL["HCLファイル（.tf）"] --> Core[Terraform Core]
  Core --> Provider[Provider]
  Provider --> API[クラウドAPI]
  STATE[tfstate] -- "現在の状態" --> Core
  Core -- "状態を更新" --> STATE

Terraformを構成する主要な要素として、「HCL」「Provider」「tfstate」の3つを紹介します。これらが連携することで、Terraformはインフラを管理しています。

HCL

まず1つ目はHCLです。これはTerraformの設定ファイルを記述するための、HashiCorp社独自の定義言語です。 JSONと互換性を持ちつつ、人間が読み書きしやすいように設計されています。プログラミング言語のような複雑な構文を極力排除し、シンプルにリソースの定義を行えるのが特徴です。 Terraformでは、このHCLを使って拡張子 .tf のファイルを作成し、インフラのあるべき姿を記述していきます。

Provider

2つ目はProviderです。これはTerraform本体と、操作対象となるクラウドサービスなどを繋ぐ「プラグイン」のような役割を果たします。 Terraformのコア機能自体は、AWSやGoogle Cloudの具体的な操作方法を知りません。それぞれのクラウドサービスのAPIに対して、「AWS用プロバイダ」や「Google Cloud用プロバイダ」が通訳として間に入ることで、リソースの作成や変更が可能になります。このProviderを切り替える仕組みがあるからこそ、Terraformはマルチプラットフォーム対応を実現できています。

tfstate

3つ目はtfstate（ティーエフステート）です。これはTerraformが管理しているインフラの「現在の状態」を記録したファイルです。 Terraformは、コード（HCL）に書かれたリソースと、実際のクラウド上に作成されたリソース（インスタンスIDなど）の紐付け情報を、このtfstateファイルに保存しています。次回実行時には、このファイルとコードを比較することで「何が変更されたか」や「差分はあるか」を判断します。Terraformが正しく動作するための「台帳」や「データベース」にあたる、非常に重要なファイルです。

2.3 Terraformの実行フロー

Terraformの3つの実行ステップとtfstateの関係を以下に示します。

flowchart LR
  INIT["terraform init（初期化）"] --> PLAN["terraform plan（実行計画）"]
  PLAN --> APPLY["terraform apply（実行・反映）"]
  APPLY -- "状態を記録" --> STATE[tfstate]
  STATE -- "現在の状態を参照" --> PLAN

Terraformを用いた実際の作業フローは、大きく分けて「初期化」「実行計画」「実行・反映」の3つのステップで行われます。それぞれの工程について解説します。

初期化

まず最初に行うのが「初期化」です。コマンドは terraform init を使用します。これは、作業ディレクトリを利用可能な状態にするための準備工程です。記述したコード（HCL）を解析し、そこで指定されているAWSやGoogle Cloudなどの「Provider（プラグイン）」をインターネットから自動的にダウンロード・インストールします。新しい環境で作業を始める際や、利用するプロバイダを追加した際には、必ずこの初期化を実行する必要があります。

実行計画

次に行うのが「実行計画」の確認です。コマンドは terraform plan を使用します。これは、実際の変更を行う前に、どのような操作が行われるかをプレビューする工程です。 Terraformは、記述されたコードと、現在の状態ファイル（tfstate）、そして実際のクラウド環境を比較し、「どのリソースが追加され、変更され、削除されるのか」という実行計画を詳細に表示します。この段階では実際の変更は行われません。意図しない削除や設定ミスがないかを事前にチェックできるため、安全な運用のための非常に重要なステップです。

実行・反映

最後に行うのが「実行・反映」です。コマンドは terraform apply を使用します。先ほどの実行計画（Plan）の内容に基づき、実際にクラウドプロバイダのAPIを呼び出してリソースの作成や変更を行います。処理が完了すると、作成されたリソースの最新情報（IDやIPアドレスなど）が tfstate ファイルに書き込まれ、Terraformの管理状態が最新化されます。このコマンドが完了して初めて、実際のインフラ構築が完了します。

3. まとめ

この講座では、IaCとTerraformの概要について学びました。

IaC（Infrastructure as Code）とは、インフラをコードで管理する手法であり、再現性の向上・環境差分の解消・あるべき状態の定義といったメリットがある
IaCは「プロビジョニング」「構成管理」「オーケストレーション」の3つに分類される
TerraformはHashiCorp社が開発した宣言型のプロビジョニングツールであり、マルチプラットフォームに対応している
Terraformの主要な構成要素は「HCL」「Provider」「tfstate」の3つ
Terraformの実行フローは「初期化（init）」「実行計画（plan）」「実行・反映（apply）」の3ステップで行われる