Terraformとは？2026年の使い方や料金、OpenTofuとの違いを徹底解説

Terraform（テラフォーム）は、HashiCorpが開発するインフラをコード（HCL）で管理するIaCツールで、AWS・Azure・Google Cloudなど数千のプロバイダに対応するマルチクラウド標準です。

2025年2月のIBM買収完了、OpenTofuへのフォーク、そして2026年6月のTerraform MCP Server GAなど、直近1年でエコシステムが大きく動きました。

本記事では、Terraformの基本ワークフローと料金体系、OpenTofuなど他IaCツールとの違い、AIエージェント連携動向まで、2026年7月時点の最新情報で整理します。

Terraformとは？IaCの標準ツールが2026年に迎えた転換点

Terraform（テラフォーム）とは、HashiCorpが開発する、インフラをコードで宣言的に管理するためのIaC（Infrastructure as Code）ツールです。

情報システムでいう「サーバー・ネットワーク・ストレージ・IAMなどのクラウドリソース」を、Webコンソールの手動操作ではなく、テキストファイル（HCL：HashiCorp Configuration Language）で定義し、コマンド一発で構築・更新・破棄できるようにします。

2026年現在、Terraformは単なるIaCツールにとどまらず、マルチクラウド運用の実質標準・そしてAIエージェントとインフラを繋ぐ中核レイヤーとして再定義されつつあります。

AWS・Microsoft Azure・Google Cloudなど主要クラウドに加え、Cloudflare・Datadog・GitHub・Snowflakeなど、公式カウントで4,500以上のプロバイダに対応しており、単一ツールで異種インフラを横串管理できる希少な選択肢です。

HashiCorpからIBM傘下への転換点

Terraformを扱う上で2026年時点で外せないのが、IBMによるHashiCorpの買収完了（2025年2月27日・$6.4B）という事実です。

erraform・Vault・Consul・Nomad・Packer・VagrantはすべてIBM製品となり、Red Hat Ansible、watsonx、Turbonomicなど既存IBMポートフォリオとの統合が進行中です。

• Red Hat Ansibleとの連携強化
  プロビジョニング（Terraform）と構成管理（Ansible）を組み合わせた一気通貫のライフサイクル自動化が公式ロードマップに組み込まれた。
  
  

• watsonx・IBM Bobとの統合
  IBMの生成AIプラットフォームwatsonxおよびAIエージェント「IBM Bob」から、Terraform MCP Server経由でインフラ操作を呼び出す設計。
  
  

• HCPプラットフォームの拡張
  Terraform Cloud後継のHCP TerraformにIBMの製品群（OpenShift、Cloudability、Concert）が接続され、単一グラフでインフラ全体を可視化するProject Infragraphが動き始めた。

ここでのポイントは、Terraformが「HashiCorp単体プロダクト」から「IBMハイブリッドクラウド戦略の中核」へと位置づけを変えた、という点です。

BSLライセンス下でのOSSコミュニティとの距離感、OpenTofuフォークとの共存、AI/エージェント時代のインフラ操作基盤としての役割——2026年のTerraformは、単なる「便利なIaCツール」ではなく、意思決定を要するプラットフォーム選定の対象になっています。

TerraformとIaC（Infrastructure as Code）の基本概念

ここではTerraformを支える基礎概念として、IaCの必要性・宣言的モデルの意味・tfstateの役割を整理します。

Terraformを触ったことがある人も、後段のワークフローや料金比較を理解するうえで前提が揃うため、一度目を通してから次のセクションに進むのを推奨します。

手動運用の限界とIaCの必要性

多くの組織で、クラウドリソースの管理はいまだに「マネジメントコンソールでのポチポチ操作」と「Excelの管理台帳」に依存しています。

この運用が抱える課題は明確です。

• 開発・ステージング・本番で環境が微妙に食い違い、リリース直前の障害を起こす
• 誰がいつ何を変えたかの履歴が残らず、事故時のロールバックができない
• スケール（複数リージョン・複数プロジェクト）に応じて手動作業が指数的に増える
• 属人化により、担当者が離脱すると環境の再現が不可能になる
  
  

IaCは、これらの課題を「インフラ定義をコードにしてGit管理する」ことで解決します。

Terraformのようなツールを使えば、環境そのものを.tfファイルとしてバージョン管理でき、CI/CDパイプラインに組み込んで自動でデプロイできます。

リリースの再現性・監査ログ・変更レビュー・ロールバックがすべて、開発者にとって馴染みのGitフローに乗るのが最大の価値です。

宣言的モデルで差分だけを適用する仕組み

Terraformの設計思想の核は、宣言的定義にあります。

手続き的（Imperative）なスクリプト（「サーバーを1台作れ」「次にネットワークを繋げ」）ではなく、宣言的（Declarative）な定義（「サーバーが2台、ネットワークがこう繋がっている状態にせよ」）を書きます。

以下の表で、宣言的モデルと手続き的モデルの違いを整理しました。

宣言的モデルの実務的な利点は、**同じ.tfファイルを何度applyしても、最終的な状態が同じになる（冪等性）**という点にあります。

「昨日の環境と同じ状態を今日再構築したい」というときに、コマンドを1つ叩けば済むので、手続き的スクリプトのように「途中まで実行済みだった場合の分岐」を書く必要がありません。

tfstateファイルの役割

宣言的モデルを成立させるために、Terraformはterraform.tfstateという状態ファイルを保持しています。

このファイルには、Terraformが管理下に置いているリソースの現状（実際に作られたリソースID、属性値、依存関係）が記録されています。

terraform planを実行すると、Terraformは以下の3つを突き合わせて差分を計算します。

• .tfファイル：あるべき状態
• terraform.tfstate：Terraformが記憶している現状
• クラウドAPIの実状態：refresh処理で最新化された実際の状態
  
  

差分が出た箇所だけがplan結果に現れ、terraform applyでその差分だけが適用されます。

tfstateの管理は運用上の最大の論点です。手元PCに置いたままだと複数人で運用できず、Git管理するとシークレット漏洩リスクが上がります。

実務ではAWS S3+DynamoDB、Azure Storage Account、HCP Terraformのリモートバックエンドなど、チーム共有可能で排他ロックが効くストレージに置くのが定石です。

ここを甘く見て手元管理のまま複数人で運用を始めると、tfstateの競合破損で環境が壊れる事故に直結するため、Step 3で扱う導入判断の重要チェックポイントになります。

Terraformの基本ワークフロー（init/plan/apply/destroy）

ここからは、Terraform
を実際に動かす4ステップのワークフローを、インストール・HCL基礎・コマンドの順で解説します。

初めて触る人が最短で「AWSにEC2を1台立てて壊すまで」を体験できる粒度に絞ります。

インストール——3つの経路

Terraform CLIはHashiCorp公式ページから無料で入手できます。

2026年7月時点の最新安定版は1.15.8で、macOS/Linux/Windowsに加え、Windows ARM64バイナリも公式配布されています。

1.15系ではconvert関数・variable/outputのdeprecationマーカー・Windows ARM64ビルドが導入され、1.16系alphaではterraform graphのMermaid出力などが進行している段階です。

• macOS（Homebrew）
  brew tap hashicorp/tap の後、brew install hashicorp/tap/terraform を実行。Homebrewのパッケージから自動でパス設定される。
  
  

• Linux（apt/yum）
  Debian/Ubuntu系ではHashiCorp公式リポジトリを追加してからapt-get install terraform、RHEL系ではdnf経由でインストール。
  
  

• Windows（Chocolatey or 手動）
  choco install terraformか、公式サイトからzipバイナリを取得して環境変数PATHに追加。

インストール後、terraform -versionで導入確認できれば準備完了です。

ターミナル（Macなら「ターミナル.app」、Windowsなら「コマンドプロンプト」など、黒い画面のツール）を開いて実行する操作です。

HCLの基本構文

Terraformの設定ファイルは、HashiCorp独自の言語HCL（HashiCorp Configuration Language）で書かれます。

構文はJSONやYAMLに近く、初見でもある程度読める設計です。以下は、AWSにEC2インスタンスを1台立てる最小構成のサンプルです。

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "ap-northeast-1"
}

data "aws_ssm_parameter" "amazon_linux_2023" {
  name = "/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64"
}

resource "aws_instance" "web" {
  ami           = data.aws_ssm_parameter.amazon_linux_2023.value
  instance_type = "t3.micro"

  tags = {
    Name = "web-server"
  }
}

output "instance_public_ip" {
  value = aws_instance.web.public_ip
}

このサンプルには、HCLの4大要素がすべて登場しています。

• terraformブロック
  使用するプロバイダ（今回はAWS）とバージョン制約を宣言。プロジェクトルートに置く。
  
  

• providerブロック
  どのクラウド・どのリージョンを対象にするかを指定。AWSならリージョン、Azureならsubscription_idなどを渡す。
  
  

• resourceブロック
  実際に作成するリソースを定義。resource "リソース種別" "識別子"の形式で書く。属性値はプロバイダの仕様に従う。
  
  

• outputブロック
  apply後に表示したい値（今回はEC2のパブリックIP）を宣言。他Terraformモジュールから参照する際にも使う。

サンプル中央の data ブロック（aws_ssm_parameter）は、AWSのSystems Manager Parameter Store経由でAmazon Linux 2023の最新AMI IDを取得しています。

AMI IDはリージョン・時期ごとに変わるため、固定値をハードコードするよりdataソースで引くのが実務標準です。

ここでのポイントは、HCLは「何を作るか」を宣言するだけで、「どうやって作るか」の手順を書かないという点です。命令的なスクリプトと違い、Terraformが依存関係の解析と実行順序を自動で決定します。

4つのコマンドで完結するワークフロー

Terraformで実際に環境を作る流れは、以下の4コマンドに集約されます。

実務で最も重要なのは、apply前に必ずplan結果をレビューするという運用ルールです。

planは何をどう変えるかをドライラン表示するので、意図しない削除（destroy）や置換（replace）が混ざっていないかをここで止められます。

チーム運用では、planをGitHub Actions等で自動実行してPRコメントに貼り付け、レビュアーが承認してからapplyする、というフローが定着しています。
この運用はAzure DevOpsやGitLab CIでも同じパターンが組めます。

モジュール設計——再利用可能な部品に分ける

環境が育つと、.tfファイル1本では手に負えなくなります。

Terraformでは、関連するリソース群をモジュールとして切り出し、複数環境で再利用する設計が推奨されます。

• ネットワーク（VPC・サブネット・SG）をmodules/network/に切り出す
• 計算リソース（EC2・ECS）をmodules/compute/に切り出す
• 環境（dev/staging/prod）ごとにenvironments/dev/main.tfなどから各モジュールを呼び出す
  
  

このディレクトリ構成にすることで、「本番だけインスタンスタイプをt3.largeに変える」といった環境差分を、変数の値だけで表現できます。

Terraform Registry（registry.terraform.io）にはHashiCorp公式・AWS公式・コミュニティ提供のモジュールが多数登録されており、VPCやEKS/AKS/GKEのような複雑な構成は既製モジュールを組み合わせるのが実務標準です。ゼロから書くよりも、実績あるモジュールを活用することで、セキュリティベストプラクティスも同時に取り込めます。

Terraformの料金プラン（OSS CLI vs HCP Terraform）

Terraformには、無料で使えるOSS版CLIと、HashiCorpが提供するSaaS版HCP Terraform（旧Terraform Cloud）の2系統があります。

ここでは両者の位置づけと、2026年時点のHCP Terraform料金体系を整理します。

OSS CLIは完全無料

Terraform CLI本体は、BSL（Business Source License）1.1のもとですべての利用者が無料で使えます。

手元PC・自社サーバー・CI/CDパイプラインなど、どこにインストールしても課金は発生しません。

• 個人開発者が学習で使う
• 中小規模チームがGitHub Actionsで回す
• 大企業が自社データセンター内で完結して使う
  
  

これらの用途では、追加費用ゼロでTerraformの基本機能をフル活用できます。

BSLライセンスの制約は「Terraformと競合するホスティングSaaSを提供してはいけない」という条項に限られ、通常のインフラ運用用途では影響しません。

HCP Terraform——5階層のSaaS版

HCP TerraformはHashiCorpが提供するマネージドSaaS版で、tfstateのリモート管理・plan/applyの実行環境・チーム管理・ポリシー適用・監査ログといった、チーム運用に必要な機能を統合提供します。

2026年6月時点の料金体系は、以下の5階層構成です。

この表が示すのは、HCP Terraformの課金モデルは「Terraformで管理しているリソース数（RUM: Resources Under Management）」ベースで従量課金されるという点です。

100リソース管理していれば、Essentialsなら月$10、Standardなら月$47。1,000リソースならStandardで月$470、Premiumで月$990と、リソース数の増加に比例してコストが上がります。

2026年3月のFree Legacy EOLに注意

HCP Terraformの旧無料プラン（Legacy Free）は、2026年3月31日をもって提供終了となり、残っていた組織は新しいenhanced Free tier（500リソースまで）に移行しています。

• 500リソースを超える運用を続ける場合は、有償プランへの移行や契約条件の確認が必要
• ユーザー数や機能制限は新Freeで緩和されている一方、リソース上限500は継続して運用される
• 移行前に組織のRUMをHCP TerraformのUsageページ（managed resources）で確認しておくのが安全
  
  

RUMのカウントは日々のリソース増減で変動するため、500上限を継続的に超え始めるタイミングでプラン見直しの判断が必要になります。

想定外のプラン切替を避けるには、budget alertとRUMの定期モニタリングを合わせて設計するのが実務的です。

プランの選び方——4つの分岐点

どのプランを選ぶかは、以下4つの分岐点で判断できます。

• リソース500未満・単独運用ならFreeで十分
  学習・PoC・個人プロジェクトはFree枠内で完結する。tfstateもリモート管理される。
  
  

• チーム3〜10名でリソース数百規模ならEssentials
  コスト見積もりと基本ガバナンスが入る。多人数運用の入口プラン。
  
  

• ドリフト検出・監査ログが必要ならStandard以上
  本番環境を含む中規模組織はStandard必須。手動変更で環境が壊れた際の検知に効く。
  
  

• コンプライアンス要件が厳しい・自社ホスティング必須ならEnterprise
  金融・医療・公共はEnterprise（Self-Managed）またはPremium。エアギャップ環境も対応可能。

AI総研の支援現場では、まずFreeで始めて「500リソースが見えたタイミングで有償プランに移る」設計を推奨しています。

最初からPremiumを選んでも、機能を使いこなす前にコストが先に立つため、段階的な移行のほうが投資対効果が読みやすくなります。

2026年の現在地——IBM買収・OpenTofu分岐・Terraform Stacks GA

Terraformを理解するうえで避けて通れないのが、2023年8月以降にエコシステム全体で起きている構造変化です。

ここでは、IBM買収・OpenTofuフォーク・Terraform Stacks GA・Terraform Searchの4つを、時系列で整理します。

BSLライセンス移行がすべての起点

2023年8月、HashiCorpはTerraformのライセンスをMPL 2.0（Mozilla Public License）からBSL 1.1（Business Source License）に変更しました。

BSLの下では、Terraformを「HashiCorpと競合するホスティングSaaS」として再販することが禁じられます。

エンドユーザーの通常利用には影響しませんが、Spacelift・env0・Scalr・Terraform Cloud競合を作りたい事業者にとっては死活問題でした。

• 通常のインフラ運用ユーザー：影響なし。従来どおり無料で使える
• 競合SaaS事業者：Terraformを組み込んだ有償サービス提供が制限される
• OSSコミュニティ：OSI準拠のオープンソースライセンスから外れた点に強い反発
  
  

このライセンス変更が引き金となり、Linux Foundation配下でOpenTofuというTerraformの直接フォークが発足しました。

OpenTofuは機能面でも独自進化中

OpenTofuは、MPL 2.0を維持したまま、Terraform 1.5系からフォークして独立進化を続けているOSSプロジェクトです。
Linux Foundation下の技術ステアリングコミッティが運営し、複数組織からの貢献を集めています。

2026年時点でもTerraformからOpenTofuへの移行検討は業界で広がっている状況で、単なるBSL回避のフォークにとどまらず機能面での独自進化が続いています。

以下の表で、Terraform安定版1.15.8には未提供のOpenTofu独自機能を整理しました。

1.16系alphaで一部の機能はTerraform側にも取り込まれ始めているため、正確には「安定版時点での差分」として読んでください。

この表が示すのは、OpenTofuは単なる「BSL回避のフォーク」ではなく、機能面でTerraform本家を追い越し始めているという点です。

state暗号化はセキュリティ要件の厳しい組織にとって、外部KMS連携より運用負荷が低く、providers for_eachはマルチリージョン・マルチアカウント運用でコード量を大幅に削減します。

「セキュリティ・スケーラビリティ機能でOpenTofuを選ぶ」という意思決定が2026年時点で成立する状況です。

Terraform Stacks GAで複数環境を統合管理

一方、Terraform本家も2025年9月のHashiConfで大きな一手を打ちました。それが**Terraform Stacksの一般提供（GA）**です。

Terraform Stacksは、複数のTerraformモジュールと複数の環境（dev/staging/prod）を1つのユニットとして管理する仕組みです。

従来は各環境ごとに別workspaceで運用していたところを、Stack定義でまとめてデプロイできます。

Terraform Stacksが管理するDeployment GroupとComponents（出典：HashiCorp Blog）

構造図では、1つのStackの下にDeployment Group A（Dev環境）・B（Stage環境）・C（Prod環境）が並列で並び、各グループの中にKubernetesとNamespaceといったComponentsが配置される姿が示されています。

この単位でStackを宣言することで、環境ごとにworkspaceを手動で分岐させていた運用がまとめて宣言的に扱えるようになります。

• 依存関係の自動追跡
  複数モジュール間のクロス依存を明示宣言し、上流モジュールの変更で下流を自動再実行。
  
  

• 環境横断デプロイ
  同じStackをdev→staging→prodに順次展開。各環境の入力値だけを変数で差し替える。
  
  

• プロダクション適合
  APIの後方互換性がGA保証されており、本番運用に投入可能。

ただし重要な制約として、Terraform Stacksは現行HCP Terraformプラン（Essentials/Standard/Premium/Enterprise）で利用可能・旧Teamプランは対象外となっています。

GA後はStacksで管理されるリソース数もRUMに合算される課金設計で、OSS版CLIやOpenTofuには実装されていないため、この機能を使いたい組織はHCP契約が実質必須です。

「BSL vs MPLの選択」がライセンス面での分岐だとすれば、Stacks GAは「機能面でHCPを縛る」設計です。

Terraform本家がOpenTofuに対して打ち出す差別化戦略として、極めて明確な線引きになっています。

Terraform Searchで一括インポート

同じくHashiConf 2025で発表されたTerraform Searchは、既存のクラウドリソースを検出してTerraform管理下に一括で取り込む機能です。

「Terraform導入前から手動で作ってきたAWSリソース群」を、Terraform管理下に段階的に取り込むリファクタリング作業は、これまで手作業でterraform importを1件ずつ叩く必要がありました。
Terraform Searchはこれを一括化し、レガシー環境のIaC化を大幅に加速します。

BSLライセンス継続下でも、OSS版だけでは得られない付加価値（Stacks・Search・MCP Server・Infragraph）をHCP Terraform側に集約する——これがIBM時代のHashiCorpの明確な製品戦略と読めます。

Terraform × AI——MCP Server・Copilot・Claude Code連携

2026年のTerraformエコシステムで最も動きが速いのが、AIエージェントとの統合領域です。

ここでは、Terraform MCP Server GA・対応AIアシスタント・連携手順・Project Infragraphの4トピックを整理します。

Terraform MCP Server 1.0のGA

Terraform MCP Serverが2026年6月11日に1.0でGAに到達しました。HCP TerraformおよびTerraform Enterprise向けに提供され、Model Context Protocol（MCP）を通じてAIアシスタントとTerraformが標準プロトコルで会話できる状態になりました。

HashiCorp公式blogでのTerraform MCP Server 1.0 GA発表（出典：HashiCorp Blog）

MCP Serverが提供する主要機能は以下のとおりです。

• プライベートレジストリへの直接アクセス
  社内モジュールをAIアシスタントから直接検索し、コード生成に取り込める。
  
  

• ワークスペースのデータ・設定クエリ
  既存ワークスペースの状態や設定をAI経由で参照。
  
  

• plan結果の自然言語解説
  terraform planの実行結果をAIが読み解き、「何が変わるか」「なぜ変わるか」を自然文で説明する。
  
  

• セキュリティ・バイ・デザイン
  Terraform MCP Serverが既存のHCP Terraform／Terraform Enterpriseの認証・認可境界を使い、ツール実行を制御・監査しやすくする設計。ただしプロトコル層で完全に越権を禁じるわけではなく、plan結果の人間レビューやポリシー適用などの実行前ゲートは引き続き必要。

MCP Serverは**ローカル実行（開発者PC）と共有サービス（チームサーバー）**の両方に対応しており、個人開発者から大規模チームまで柔軟に構成できます。

対応する主要AIアシスタント

Terraform MCP Serverの公式deployドキュメントで導入手順が確認できる主なクライアントは以下のとおりです。

MCPプロトコル準拠のAIエージェントであれば他のクライアントからも接続は可能ですが、公式で手順化されているのはこの一群です。

この対応幅の広さが示すのは、Terraform MCP Serverは特定ベンダーロックインを避け、AIエージェント選定は各組織の既存契約に合わせられるという設計思想です。

Microsoft/GitHubスタックの組織はVS Code＋GitHub Copilot、Anthropic Claude系を使っている組織はClaude Desktop、AWS中心の組織はAmazon Q Developer、IBM顧客はBob Shell/IDEと、既存のAIアシスタント投資をそのままインフラ運用に転用できます。

Claude CodeなどMCP対応の他CLIクライアントも接続候補になりますが、公式deployドキュメントに手順が載っていないクライアントは自組織側で動作検証を挟んでから採用するのが安全です。

実装フロー——Copilot＋MCPで実際に動かす手順

GitHub Copilot Agent ModeとTerraform MCP Serverを連携させる最小手順は以下の6ステップです。

• Terraform MCP Serverを docker run hashicorp/terraform-mcp-server でローカル起動
• HCP TerraformのAPIトークン（TFE_TOKEN）と組織URL（TFE_ADDRESS）を環境変数に設定。TFE_TOKENに付与する権限（workspace read/write / plan / apply）はやりたいスコープ最小に絞る
• 通常の create_run（plan_and_apply）や plan 確認は標準機能で動作。auto_approve・destroy・action_run などの破壊的操作まで委ねる場合のみ、環境変数 ENABLE_TF_OPERATIONS=true を明示的に設定する
• VS Codeの.vscode/mcp.jsonにMCP Serverのエンドポイントを追加
• GitHub Copilot Agent ModeをVS Codeで有効化
• Copilot Chatで「本番環境のRDSインスタンスタイプをdb.r6g.largeに変更するTerraformを書いて、planまで実行してほしい」等の指示を出す
  
  

この構成が組めると、開発者は自然言語でインフラ変更を指示し、CopilotがHCLコード生成→plan実行→結果解説までを一気通貫で行います。

HCP TerraformのworkspaceポリシーやSentinel/OPAでのapply承認ゲート、plan結果の人間レビューを必ず併用することで、AIによる意図しない破壊的変更が本番に流れるリスクを抑えられます。

Claude Codeでも同様の構成が可能で、Claude Code Advisorのようなアドバイザーモードと組み合わせれば、コスト影響やセキュリティリスクを別モデルにレビューさせる二段構えも組めます。

Project Infragraphの位置づけ

2025年9月のHashiConfでは、Project Infragraphも同時に発表されました。

プライベートベータは2025年12月開始で、2026年6月30日には「HCP Terraform powered by Infragraph」として限定提供（Limited Availability）が開始され、対象はUSインスタンスのStandard/Premium顧客まで広がっています。

Project Infragraphの3レイヤー構造と接続対象（出典：IBM Newsroom）

中央のProject infragraphが「DATA ENRICHMENT」「DATA CONSUMERS」「ECOSYSTEM INTEGRATION」の3レイヤーで構成されていることが読み取れます。左側のDATA ENRICHMENTにはAWS/GCP/Azureといったクラウドプロバイダ・Self hosted・HCP hosted・K8s operatorsが接続され、上のDATA CONSUMERSにはPackerやTerraform importといったHashiCorp製品群、右のECOSYSTEM INTEGRATIONにIBMのエコシステムが接続する構造です。

Project Infragraphは、Terraform state・クラウドAPI・Kubernetesクラスタ・構成管理ツールから集めたメタデータを、リアルタイム更新されるリレーショナルグラフとして保持する基盤です。

各ノードがリソース、各エッジが依存関係と所有権を表現し、AIエージェントがインフラ全体を「見渡した上で」判断できる文脈を提供します。

• インフラ・アプリ・サービス・オーナーシップ・ポリシーを1つのグラフに統合
• Red Hat Ansible・OpenShift・watsonx Orchestrate・Concert・Turbonomic・Cloudabilityと接続予定
• AIエージェントに組織インフラの文脈を提供する基盤として設計されている
  
  

Terraform MCP Serverが「1つのTerraformプロジェクトをAIから操作する」入口だとすれば、Project Infragraphは「組織のインフラ全体を1つのグラフとしてAIに見せる」土台です。

IBM買収後のHashiCorpが最も投資しているのがこの領域で、AIエージェントが判断に使うインフラ文脈をどう組織で持つかが、Terraform周辺のプラットフォーム議論の中心に移りつつあります。

他のIaCツールとの比較（OpenTofu／CloudFormation／Pulumi／Bicep）

Terraformを検討する上で、比較対象になる主要4ツール（OpenTofu・CloudFormation・Pulumi・Bicep）との違いを整理します。

選定判断のインプットとして、各ツールの強みと弱みを一覧できる形にしました。

4ツール比較の全体像

以下の表で、Terraformと主要4ツールの特性を並べました。前段で触れた製品固有の機能は再掲していないので、各項目の詳細は前後のセクションを参照してください。

この表が示すのは、マルチクラウドか単一クラウドか・DSLか汎用言語か・OSSライセンスの厳格性の3軸で選定軸が分かれるという点です。以下、各ツールの立ち位置を1本ずつ掘り下げます。

OpenTofu——Terraformとの棲み分け

OpenTofuは、既に述べたとおりTerraformの直接フォークで、tfstateもコマンド体系もほぼ互換です。
公式移行ガイドに沿ってstateをバックアップしたうえで、tofu init→tofu plan→tofu applyの順で差分確認とstate更新を行います。

Terraform 1.5系以下からの移行では、公式ガイドの1.5.x-or-lower手順に従いOpenTofu 1.6.2を経由するのが安全です。

• 選ぶ理由：ライセンスの純OSS要件、機能先行（state暗号化・for_each）、コミュニティ主導
• 選ばない理由：HCP Terraform・Stacks・HCP/TFE workspace操作を伴うTerraform MCP連携などの有償エコシステム機能が使えない（Registry参照だけならOpenTofu側のRegistry MCP Serverも利用可能）
  
  

「HCP連携やStacksを使わず純OSSで固めたい」組織にとっては、OpenTofuの方が2026年時点で機能面でも有利です。

AWS CloudFormationはAWS完結向け

AWSのマネージドIaCで、YAML/JSONでスタック定義を書きます。tfstateの管理が不要で、AWS内部でスタックの状態を持ちます。

• 選ぶ理由：100%AWSで、Organizations・StackSets・Service Catalogとの純正統合を活かしたい
• 選ばない理由：マルチクラウド展開の予定がある、HCLの記述性を評価する
  
  

AWSベンダーロックインを許容できるなら、追加ツールを増やさずに済む点で選択肢に入ります。

ただしAzure・GCP等が絡んだ瞬間にTerraformへの再移行が必要になるため、将来のクラウド戦略と併せて判断すべき論点です。

Pulumi——汎用プログラミング言語派

PulumiはPython・TypeScript・Go・C#・Javaといった汎用プログラミング言語でインフラを定義できるIaCツールです。DSLではないため、既存の言語スキルをそのまま使えます。

• 選ぶ理由：ソフトウェアエンジニアが主体でインフラを書く、型安全性・テスタビリティを重視、アプリコードとインフラコードを共有したい
• 選ばない理由：TerraformのRegistry資産の方が広く、ニッチSaaSやTerraform互換プロバイダはPulumi側の対応可否を個別確認する必要がある、インフラチームがHCLに慣れている
  
  

「開発者中心組織でIaCを書く」文脈ではPulumiが第一候補になりますが、大企業のインフラチームでは依然としてTerraformが優勢です。

Azure Bicep——Azure完結の第一候補

Bicepは、Microsoftが提供するAzure専用のIaC DSLです。Azure Resource Manager（ARM）テンプレートより簡潔に書け、状態管理も不要です。

• 選ぶ理由：100%Azureで、Microsoft純正サポート・シンプル文法・状態管理不要を評価する
• 選ばない理由：マルチクラウドを含む、Terraformのモジュール・レジストリエコシステムを活用したい
  
  

小規模Azureチームで専任インフラエンジニアがいない場合、Bicepが最短距離になります。一方、Azure以外への拡張性を残したい場合は、最初からTerraformで書いておくほうが後々の書き換えコストが省けます。

Terraform選定で見落とされやすい判断軸

ここまで整理してきたエコシステムの状況を踏まえ、2026年時点でTerraformを選定・運用する上で見落とされやすい判断軸を、AI総研の支援現場からの観察を交えて整理します。

BSLとMPL、新規導入時の判断軸

「これから新規にIaCを導入する」組織にとって、Terraform（BSL）とOpenTofu（MPL）のどちらを選ぶかは、ライセンスの純OSS要件だけでなく、エコシステム機能の優先順位で決まります。

• Terraformを選ぶべきケース
  HCP TerraformのStacks・Search・MCP Serverを使いたい、IBM・Red Hat・watsonxとの統合を活用したい、Terraform Registry公式モジュールの安心感を重視する組織
  
  

• OpenTofuを選ぶべきケース
  純OSSライセンス要件がある、state暗号化・providers for_each等の機能先行を評価する、コミュニティ主導のOSSプロジェクトを支援したい組織

既にTerraformで運用中の組織にとっては、「今すぐ移行する必要はないが、tfstate互換なので、いつでも移行の選択肢はある」というポジション取りが現実的です。

BSLに変わった段階で契約更新やライセンス精査が必要な業種（金融・公共）は、法務レビューを先行させておくのが安全です。

HCP TerraformプランはRUMベースで見積もる

HCP Terraformの料金は前述のとおりリソース数連動です。プラン選定時に見落とされやすいのは、Freeの500リソース上限を超えた瞬間の料金インパクトです。

• 現在のRUM（Resources Under Management）を把握する
• 半年後・1年後のRUM想定を見積もる
• Free枠500を超える月がいつ来るかを予測する
• 500超え月からEssentials/Standardのどれに移るかを事前決定
  
  

「使い始めてから請求が跳ねて焦る」という事故を避けるには、RUM予測を月次でモニターする体制が有効です。

特に本番環境をTerraform管理下に置く際、依存リソース（サブネット・SG・IAMロール）を含めた実カウントを事前に測定しないと、想定の2〜3倍のリソース数になることがあります。

AI連携（MCP）をいつ入れるか

Terraform MCP Serverは強力ですが、組織のTerraform運用が成熟していない段階で導入するのは危険です。

以下の順序を推奨します。

• Phase 1：TerraformのGit管理・plan/applyの承認フロー・tfstateリモート管理を整備
• Phase 2：モジュール化とTerraform Registryの活用を定着
• Phase 3：CI/CDパイプライン（GitHub Actions等）でplan/applyを自動化
• Phase 4：Terraform MCP ServerをローカルモードでAIアシスタントと接続、コード生成・plan解説から使い始める
• Phase 5：チーム共有モードに移行し、権限管理・監査ログと合わせて本格運用
  
  

Phase 1〜3が固まっていない段階でMCPを入れると、AIが生成したコードのレビュー基準が定まらず、意図しない設定変更が本番に流れるリスクがあります。

MCPは「Terraformが分かる人が、より速く動くための拡張」であって、「Terraformを知らない人が触るための魔法」ではない、と現場では位置づけたほうが安全です。

導入で詰まる3つの実務論点

新規Terraform導入プロジェクトで、実際に手が止まりやすいポイントを3つ挙げます。

• tfstateの共有ストレージ設計
  チームで共有するtfstateをどこに置くか（S3+DynamoDB、Azure Storage、HCP Terraform）、暗号化・排他ロック・世代バックアップをどう組むか。ここが甘いと環境破壊事故の温床になる。
  
  

• 既存リソースのimport戦略
  Terraform導入前から手動で作ってきたクラウドリソースをどこまで管理下に取り込むか。全部importするのか、新規分だけTerraformで管理するのか、明確な線引きが必要。HashiConf 2025のTerraform Searchはこの作業を大幅に楽にする。
  
  

• provider・moduleのバージョン管理
  ~> 5.0のような柔軟指定にするか= 5.42.0で固定するか。柔軟指定は将来の破壊的変更で環境が壊れるリスクがあり、固定指定はセキュリティパッチ取り込みが遅れる。バージョン更新のレビュー運用と併せて設計する。

AI総研の支援現場でも、この3つは初期のPoC段階で必ず論点になります。特にtfstateの共有ストレージ設計は、「動けばいい」で始めた組織がスケール後に必ず組み直す羽目になる箇所です。最初から適切な設計で始めるか、Phase 1で組み直すかの明確なマイルストーンを持って進めるのが実務的な進め方になります。

TerraformだけでなくAIエージェント運用を全社に広げるなら

TerraformとMCP Serverの組み合わせで、インフラ操作の一部をAIエージェントに任せる段階に入りました。ただしAI活用の本命は、インフラ管理だけでなく、経費精算・請求書処理・CRM操作といった業務システム全体をAIエージェントが横断する運用にあります。そこで問われるのが、複数のAgentを一元管理し、権限・実行ログ・セキュリティを統制する基盤の設計です。

このレイヤーを担うのが、自社のAzureテナント内で動くエンタープライズAIエージェント基盤です。AI総合研究所のAI Agent Hubは、Teamsから呼び出せる業務特化Agent群を1つのダッシュボードで統合管理する運用基盤として機能します。

• Terraformで整備したインフラ上に業務Agentを積層
  Terraform MCPで加速するインフラ操作Agentと、経費・請求書・図面等の業務特化Agentを、1つの管理基盤で運用。全社のAgent資産を統合ガバナンス下に置けます。
  
  
• PoCから本番運用まで段階設計で伴走
  記事で紹介したTerraform MCPの段階導入と同じ発想で、AIエージェント運用もHuman-in-the-Loopで人間の承認を組み込みながら段階的に整備できます。
  
  
• 構築基盤が違っても管理は1つ
  Copilot Studioやn8nなど複数の構築基盤で作ったAgentを1つのダッシュボードに集約。実行ログ・アクセス権限・セキュリティスキャンを一元管理します。
  
  
• データは100%自社テナント内に保持
  AIの学習対象から完全除外。Azure Managed Applicationsとして自社テナント内で動作が完了する設計です。

AI総合研究所の専任チームが、TerraformとAIエージェント運用の統制設計を一貫して支援します。AI Agent Hubのサービスページで、インフラと業務システムを一体運用する具体像をご確認ください。

Terraform運用にAI Agentを統合

インフラも業務も1つの基盤で統制

Terraform MCPで加速するインフラAgentも、経費・請求書などの業務Agentも、1つの管理基盤で統合運用する設計を支援します。PoCから本番運用への段階設計とセキュリティ・権限管理を、AI Agent Hubで実現できます。

▶ ▶ AI Agent Hubの詳細を見る

まとめ

本記事では、Terraformの基本ワークフロー・料金プラン・2026年の現在地・AIエージェント連携・他IaCツール比較・選定判断までを、2026年7月時点の最新情報で解説しました。要点を改めて整理します。

• TerraformはIBM買収後もマルチクラウドIaCの実質標準で、4,500以上のプロバイダに対応。HashiCorp単体プロダクトから「IBMハイブリッドクラウド戦略の中核」へと位置づけを変えた
  
  

• 基本ワークフローはinit→plan→apply→destroyの4コマンドで完結、宣言的モデル＋tfstate＋モジュール設計が現場で機能する三本柱
  
  

• HCP TerraformはRUM連動の5階層料金、Free 500リソース／Essentials $0.10／Standard $0.47／Premium $0.99／Enterprise個別見積で、旧Legacy Freeは2026年3月にEOL
  
  

• 2026年の現在地はIBM買収・OpenTofu分岐・Stacks GA・Search・MCP Server・Project Infragraph、Terraform本家とOpenTofuの機能面での分岐が明確化
  
  

• Terraform MCP Server 1.0が2026年6月GA、VS Code＋Copilot・Cursor・Claude Desktop・Amazon Q Developer・Bob Shell/IDEなど公式手順のあるクライアントから通常のrun作成／plan確認が可能に。auto_approve・destroy・action_runなどの破壊的操作はENABLE_TF_OPERATIONS=true＋人間承認ゲート併用が必要で、Terraform運用の成熟度に応じた段階導入が前提
  
  

• 他IaC比較ではAWS完結ならCloudFormation、Azure完結ならBicep、汎用言語で書きたいならPulumi、マルチクラウド・エコシステム最大化ならTerraform、純OSS要件ならOpenTofuが分岐点

2026年のTerraform選定は、単なる「IaCツールを選ぶ」作業ではなく、BSLライセンス下でIBMエコシステムに乗るか、MPLのOpenTofuでコミュニティ主導路線に乗るかという戦略選択になっています。既存資産・チームのスキルセット・AI連携の投入時期をセットで考え、まずは現行環境のtfstate管理とplan/apply承認フローを固めるところから着手するのが、最も実用的な第一歩になります。