The DX Leaders
AI活用のグローバル・トレンドや日本の市場動向を踏まえたDX、生成AIの最新情報を毎月お届けします。登録の際はIBMプライバシー・ステートメントをご覧ください。
Terraformとは
公開日 2025年04月15日
更新日 2026年07月13日
Terraformは、HashiCorpが開発したエンタープライズ・グレードのインフラストラクチャ・アズ・コード（IaC）製品です。Terraformは、複数のクラウド（AWS、Azure、Google Cloud）、ネットワーク、プライベート・データセンター、SaaS環境に対応した、インフラストラクチャーのライフサイクルを統合的に管理するインターフェースと、インフラ・コンポーネントをプロビジョニングするための単一のワークフローを提供します。
Terraformを使用すると、ユーザーは人間が読める構成ファイルを作成することで、インフラストラクチャー・コンポーネントを作成、更新、破棄できます。これらの構成ファイルは、手続き型言語ではなく宣言型言語を使用します。ユーザーはインフラ・リソースの望ましい最終状態を記述し、Terraformは残りの部分を処理します。Terraformは実行計画を自動的に作成し、リソース間の依存関係を特定したうえで、コンポーネントを正しい順序でプロビジョニングします。
たとえば、仮想マシン（VM）が仮想プライベートクラウド（VPC）に依存している場合、TerraformはVMをプロビジョニングする前にVPCが作成されるようにします。
対照的に、手続き型言語では、開発者はインフラストラクチャーをプロビジョニングするための段階的な指示を記述する必要があります。
Terraform構成ファイルはバージョン管理、再利用、共有が可能です。Terraform は、コンピューティング・リソースやストレージ・リソース、S3バケットなどの下位コンポーネントと、ドメイン・ネーム・システム（DNS）の項目やサービス型ソフトウェア（SaaS）の主要な機能などの上位コンポーネントを管理します。
Terraformは、Amazon Web Services（AWS）、Microsoft Azure、Google Cloud、GitHub、IBM Cloud、Dockerなど、アクセス可能なアプリケーション・プログラミング・インターフェース（API）を備えた、ほぼすべてのプラットフォームやサービスに対応しています。
Terraformの主要ワークフローは3つの段階で構成されています。
- 作成
- プラン
- 適用
1. 作成
開発者は、人間が読める構成ファイルを作成し、希望するインフラのリソース構成を定義します。ファイルは宣言型です。開発者は、実現したいインフラを記述しますが、それをどのようにプロビジョニングするかまでは記述しません。
たとえば、開発者がクラウド・ホスト型アプリケーションを展開するためのインフラストラクチャーをプロビジョニングしたい場合、関連するセキュリティー・グループとロードバランサーとともに、仮想プライベートクラウド内の仮想マシンが必要であると指定することがあります。
単一の構成ファイルで、複数のクラウド・プロバイダーやサービスにまたがるリソースを管理できます。
2. 計画
Terraformは、開発者が定義した構成と、組織のインフラストラクチャーの現在の状態の両方を分析します。次に、現在の状態から望ましい最終状態に到達する方法を示す実行計画を作成します。
この計画は、実際のインフラストラクチャーを開発者が記述した構成に一致させるために、Terraformが作成、更新、または破棄するインフラストラクチャーを一覧にしたものです。
開発者が仮想プライベートクラウド内の仮想マシンにアプリケーションを展開する先ほどの例を考えてみましょう。Terraformの実行計画には、次のようなアクションが含まれることがあります。
- アプリケーションをホストする新しい仮想マシンをプロビジョニング
- 新しい仮想マシンへのトラフィックを許可するように既存のセキュリティー・グループを変更
- 仮想マシン間でトラフィックを分散させるためにロード・バランサーをプロビジョニング
開発者は、Terraformが実行する前に、実行計画をレビュー、変更、検証できます。
3. 適用
計画が承認されると、Terraformはリソースの依存関係を守りながら、操作を正しい順序で実行します。つまり、リソースAがリソースBに依存する場合、TerraformはリソースBがリソースAの前に作成されるようにします。
例えば、ある開発者がVPCのプロパティーを更新し、そのVPC内の仮想マシンの数を変更したとします。Terraformは仮想マシンをスケーリングする前に、更新後のプロパティーでVPCを再作成します。
Terraform の主な構成要素は次のとおりです。
- 構成ファイル
- モジュール
- 状態ファイル
- プロバイダー
- レジストリー
- Terraform CLI
構成ファイルは、開発者がオンプレミス環境やクラウド環境で必要なリソースを定義するためのものです。これらのファイルは、使用するプロバイダー、作成するインフラストラクチャー、取得するデータをTerraformに指示します。開発者は、構成ファイルを変更、再利用、共有することができます。
開発者は、JSONまたはHashiCorp Configuration Language（HCL）で構成ファイルを記述できます。HCLでは宣言型構文を使用します。開発者は、実現したいインフラストラクチャーを記述し、それをどのようにプロビジョニングするかは指定しません。HCLはJSONのキーと値のペアに似ていますが、人間が読みやすいように最適化されています。
モジュールは、共同で使用される複数のリソースの再利用可能なコンテナです。たとえば、モジュールには、仮想マシン、データベース、ネットワーク構成、セキュリティー設定がオールインワン・パッケージで含まれている場合があります。モジュールは構成ファイルの集まりとして保管されます。
Terraformモジュールを使用すると、開発者は毎回ゼロから始めることなく、複雑なインフラストラクチャーを構築できます。代わりに、必要なインフラストラクチャーの配置をすでに記述しているモジュールを使用できます。
Terraform状態ファイルは、コンポーネント、構成、リソース間の関係など、インフラストラクチャーの現在の状態を表したものです。
Terraformが計画を作成するときは、まず構成ファイルと状態ファイルを比較します。この比較により、Terraformは現在のインフラストラクチャーを目的の構成に一致させるために必要な変更を判断できます。
Terraformプロバイダー は、Terraformが外部サービスやプラットフォームのAPIと対話するために使用するプラグインです。プロバイダーにより、TerraformはInfrastructure as a Service（IaaS）、Platform as a Service（PaaS）、Software as a Service（SaaS）環境でリソースを管理できます。各プロバイダーには、Terraformがサービスに接続し、リソースを認証およびプロビジョニングするために必要なすべてのコードが含まれています。
開発者は独自のプロバイダーを作成できますが、HashiCorpや他のTerraformユーザーが作成した既存のプロバイダーを使用することもできます。ほとんどの主要なプライベートクラウド・サービスとパブリッククラウド・サービス、ならびにデータベース、ネットワーク・ソリューション、その他の一般的なツール向けに事前構築されたプロバイダーがあります。
Terraformは既存のインフラストラクチャーも管理できます。インポート・ブロックを使用すると、開発者はTerraformの外部で作成されたリソースをTerraformの管理下に置くことができるため、新しいリソースだけでなく環境全体をコード化して管理できるようになります。
Terraform Registryは、プロバイダー、モジュール、ポリシー・ルール、リューションのリポジトリーです。
誰でもパブリックのTerraform Registryでリソースやテンプレートを公開し、利用できます。このレジストリのプロバイダーまたはモジュールを使用するには、ユーザーはそれを設定に追加します。terraform initを実行すると、Terraformは必要なものをすべて自動的にダウンロードします。
組織はプライベート・レジストリーを作成して、独自のモジュールやリソースを社内で共有することもできます。
Terraform CLIは、Terraformでインフラストラクチャーを管理するためのコマンドライン・インターフェース（CLI）ツールです。開発者はこれを使用して、コマンドの実行、実行計画の生成、変更の適用、および構成ファイル、状態ファイル、プロバイダー、モジュールなどの主要なTerraformコンポーネントとのやり取りを行います。
組織はTerraformを使用して、ライフサイクル全体にわたってインフラストラクチャーのプロビジョニングと管理を行います。一般的なユースケースには、次のようなものがあります。
- ハイブリッド環境とマルチクラウド環境の管理
- アプリケーション・インフラストラクチャー管理
- 開発者セルフサービス
- ポリシーとコンプライアンスの管理
- チームのコラボレーション
ハイブリッドクラウド環境とマルチクラウド環境の管理
ハイブリッドおよびマルチクラウド環境は、各クラウド・プロバイダーが独自のインターフェース、ツール、 ワークフローを持っているため 、複雑になる可能性があります。このような環境では、重要なクラウド・リソースがパブリッククラウド、プライベートクラウド、複数のデータセンターに分散している場合があります。
組織はTerraformを使用して、複雑で大規模なクラウド・インフラストラクチャーの管理と編成を簡素化できます。具体的には、Terraformを使用すると、組織は同じ構成言語を用いて、パブリッククラウド、プライベートクラウド、オンプレミス環境全体にわたるリソースを、一つの統一されたワークフローでプロビジョニングおよび管理できます。
大規模なインフラ管理を支援するために、Terraform Stacksは、相互に依存するTerraform構成の調整、デプロイメント、ライフサイクル管理を自動化・最適化し、インフラ管理にかかる時間とオーバーヘッドの削減に役立ちます。
スタックは、Terraformの従来のルート・モジュール構造を、Terraformモジュールの上に構築された新しいコンポーネントベースのアーキテクチャーに置き換えます。スタックを使用すると、ユーザーは大規模なインフラストラクチャーのライフサイクルをプロビジョニングおよび調整でき、Infrastructure as Code（IaC）のアプローチをさらに発展させる、整理された再利用可能な仕組みを利用できます。
アプリケーション・インフラストラクチャー管理
Terraformは多層アプリケーションのインフラストラクチャーを展開し、管理できるため、組織は依存関係を尊重しながら、統合されたワークフローで各層のリソースを管理できます。
例えば、多層アプリケーションは、Webサーバーのプール、データベース層、API層、キャッシュ・サーバー、ルーティング層で構成される場合があります。Terraformは、データベース層に依存するWebサーバーをプロビジョニングする前に、データベース層をプロビジョニングします。
開発者セルフサービス
開発者セルフサービスは、単なるインフラストラクチャーのプロビジョニングにとどまらず、環境の設定からデプロイメント、継続的なオペレーションまで、アプリケーションのライフサイクル全体を網羅するように進化しています。
Terraformは、この最新のセルフサービス・モデルの基盤を提供します。Backstage、Port、Cortexなどの開発者ポータル、ServiceNowやJiraなどのITSMシステム、GitHub ActionsやJenkinsなどのCI/CDパイプラインプラットフォームと統合されています。
Terraformのワークフロー内で作業を進めたいチームにとって、WaypointはTerraformネイティブの開発者セルフサービス・ポータルとして機能し、一貫したポリシー駆動型のアプリケーション展開を実現します。
AWS、Azure、GCP全体で、Terraformはこれらのエントリー・ポイントを統合する制御レイヤーとして機能し、ガバナンスと運用の一貫性を維持しながら、開発者がより迅速に作業を進められるようにします。
ポリシーおよびコンプライアンス管理
Terraformを使用すると、プロビジョニングや使用可能なリソースの種類についてセキュリティー・ポリシーとコンプライアンス・ポリシーを適用できます。
Sentinelは、HashiCorpのポリシー・アズ・コード・フレームワークであり、インフラストラクチャー全体にわたってきめ細かなロジックベースのガバナンスを適用するためのものです。また、すぐに利用できる制御機能（例えば、NIST SP 800-53へのマッピング）を提供する、あらかじめ用意されたポリシー・ライブラリーも備えています。これらのポリシーは、すべてのポリシーを最初から作成することなく、共通のコンプライアンスの制約を適用するのに役立ちます。
例えば、Terraformモジュールを使用して、組織全体でのリソースの展開や管理に関する標準をコード化できます。他のチームがこれらの承認済みモジュールを使用すれば、組織の標準に準拠した形でリソースを展開できます。
チームの連携
組織は、Terraformコードと構成ファイルをGitリポジトリーなどのバージョン管理システム（VCS）に保存できます。この仕組みにより、DevOpsチームはコードを共同で開発し、定義をレビューし、インフラストラクチャーの変更を追跡し、必要に応じて以前のバージョンへロールバックできるようになります。
TerraformとAnsibleは、インフラのプロビジョニングを超えた自動化を拡張するためにしばしば併用されます。Terraformは、クラウド環境やハイブリッド環境向けの複雑なリソースの準備やプロビジョニングなど、インフラストラクチャーのプロビジョニングに優れています。Ansibleは、既存のインフラストラクチャーを一貫して構成管理、変更、保守するための強力なツールです。
YAMLで記述されたAnsibleプレイブックを使用すると、ソフトウェアのインストールやシステム設定の更新などの作業をきめ細かく制御できます。
この2つのツールは、インフラストラクチャー・ライフサイクルの異なるが関連する段階に対応しているため、環境間の一貫性を求める組織に最適です。
TerraformとAnsibleの統合は、リソースの作成と構成管理の間のギャップを埋めるのに役立ちます。例えば、Terraformのアクションはイベントをディスパッチして、Ansible Automation Platform（AAP）のイベント駆動型自動化機能を起動し、Terraform applyを1回実行するだけで、Ansibleによる動的な自動化ワークフローをトリガーできます。
この相互接続性は、インフラ・ツールセットの統合に役立ち、パッチ適用、スケーリング、廃止措置といったDay 2オペレーションに伴う運用上の摩擦を軽減します。TerraformとAnsibleは、インフラストラクチャーとアプリケーションのライフサイクルのあらゆる段階での一貫性と信頼性の維持に役立ちます。
KubernetesとTerraformはクラウド環境の一般的なコンポーネントであり、どちらもインフラストラクチャー関連のタスクの自動化を支援します。ただし、両者の主な違いを挙げると、Kubernetesはコンテナ化されたワークロードに重点を置いているのに対し、TerraformはKubernetesクラスター自体を含むあらゆる種類のインフラストラクチャー・コンポーネントを管理する点です。
Kubernetes は、コンテナ化されたアプリケーションの展開、管理、スケーリングをスケジュール設定し、自動化するためのオープンソースのコンテナ・オーケストレーション・プラットフォームです。Terraformは、インフラストラクチャーのプロビジョニングと管理を自動化するインフラストラクチャー・アズ・コード（IaC）ツールです。
これらのツールはそれぞれ異なる役割を担っていますが、クラウド・バックエンドでは連携して利用されることがよくあります。たとえば、Terraformはクラウド・プラットフォーム上のKubernetesクラスターのプロビジョニングを自動化し、Kubernetesはそのクラスター内のアプリケーションの展開を管理します。