Terraformの最新バージョンは1.16｜terraform versionでの確認とアップグレード手順・新機能

Terraformはマイナーバージョンが数か月おきに上がり、その間も週単位でパッチ版が出ます。チームで使っていると「いま入れるべきはどれか」「手元のものは古いのか」「上げるなら何を確かめるのか」を判断する場面が繰り返し出てきます。この記事では、最新バージョンとリリースの状況、terraform version による確認方法、古さを機械的に判定する方法、バージョンを固定する書き方、tfenvでの切り替え、1.15系から1.16系へ上げる手順、そして1.16で入った変更までをまとめました。版が上がるたびに更新しています。

まとめ｜最新バージョンと確認・固定・アップグレードの要点

結論から示します。2026年9月29日時点で、Terraformの最新の安定版は1.16.4です（2026年9月23日リリース）。1.16系は2026年8月26日の1.16.0から毎週パッチ版が出ており、次の1.17系はbeta段階にあります。

手元の版は terraform version で確認できます。さらに terraform version -json を使うと、Terraform自身が「古いかどうか」を真偽値で返してくれます。プロジェクト側でバージョンを縛りたい場合は required_version を使い、端末ごとの切り替えはtfenvに任せる形が扱いやすい構成です。

• 最新の安定版：1.16.4（2026年9月29日時点）
• 確認：terraform version（CIでは -json の terraform_outdated を見る）
• 固定：本体は required_version、プロバイダはlockファイル
• アップグレード：本体とプロバイダを分けて上げ、planで差分が出ないことを確かめる
• 判断：新しいマイナー版は x.y.1 以降を待ち、パッチ版は早めに追従する

Terraformの最新バージョンは1.16.4（2026年9月29日時点の安定版）

GitHubのリリース一覧と、Terraform本体が更新確認に使うHashiCorpのCheckpoint APIを確認したところ、2026年9月29日時点で配布されている最新の安定版は1.16.4で、リリース日は2026年9月23日でした。バイナリ自体はreleases.hashicorp.comに版ごとに並んでいます。Terraformのバージョンは1.16.4のように3つの数字で表され、真ん中のマイナー番号が上がるときに新機能が入り、右端のパッチ番号が上がるときは不具合修正が中心です。

1.16系のパッチ履歴と1.17.0ベータの進み具合を表で確認する

2026年9月29日時点の主なリリースを新しい順に並べました。1.16.0以降のパッチ版は、v1.16のCHANGELOGを見るといずれも「BUG FIXES」だけで構成されています。

パッチ版の中身には、1.16.1での create_before_destroy の順序修正や、for_each を使った複数の import ブロックが無視される不具合の修正などが含まれます。1.16.0を入れたまま止めているなら、1.16.4まで上げておく価値があります。

安定版とalpha・beta・rcの違いと本番で選ぶべき版の見分け方

リリース一覧には安定版に加えて、開発途中の版も並びます。-alpha・-beta・-rc の付いた版は検証用で、業務環境での利用には向きません。1.17系は2026年8月27日にalpha、9月9日にbeta1、9月23日にbeta2が出ており、rcを経て1.17.0が出る流れになります。

「最新バージョンはいくつか」という問いへの答えは、通常この安定版のほうを指します。なおバージョン制約の公式リファレンスによると、pre-releaseの版は = で完全一致を指定したときだけ選ばれ、>= や ~> では一致しません。範囲指定をしておけば、ベータ版が勝手に選ばれる心配はありません。

terraform versionコマンドで手元の本体とプロバイダの版を確認する

手元の版は次のコマンドで確認できます。

terraform version

terraform versionコマンドの公式ドキュメントの説明によると、このコマンドはTerraform本体のバージョンに加えて、インストールされている全プロバイダプラグインのバージョンも出力します。プロバイダ側の版ズレが原因の不具合を切り分けるときにも役立ちます。

通常出力で表示される4つの情報と古い版のときに出る警告の読み方

作業ディレクトリで terraform init 済みの状態で実行すると、出力は次のような形になります（版番号は例です）。

$ terraform version
Terraform v1.16.3
on linux_amd64
+ provider registry.terraform.io/hashicorp/aws v6.14.0

Your version of Terraform is out of date! The latest version
is 1.16.4. You can update by downloading from https://developer.hashicorp.com/terraform/install

読み取れるのは、本体の版、実行プラットフォーム（OSとCPUアーキテクチャ）、作業ディレクトリで選択されたプロバイダとその版、そして新しい版やセキュリティ告知があるときの警告の4つです。プロバイダの行は init 前のディレクトリでは表示されないため、「プロバイダが出てこない」ときはまず作業ディレクトリを確かめます。Apple SiliconのMacで darwin_amd64 と出る場合は、Intel版のバイナリをRosetta経由で動かしている状態です。

terraform version -jsonでCIから古さを機械判定するスクリプト例

最新版と見比べる作業は、実は手作業でやる必要がありません。JSON形式で出力すると、判定結果がそのまま含まれます。

$ terraform version -json
{
  "terraform_version": "1.16.3",
  "platform": "linux_amd64",
  "provider_selections": {
    "registry.terraform.io/hashicorp/aws": "6.14.0"
  },
  "terraform_outdated": true
}

出力には terraform_version、platform、provider_selections に加えて terraform_outdated という項目が含まれます。これが真であれば、より新しい版が出ているという意味です。CIの中では、次のようにjqで値を取り出して警告を出す使い方ができます（GitHub Actionsの注釈形式の例）。

out="$(terraform version -json)"
ver="$(echo "$out" | jq -r '.terraform_version')"
if [ "$(echo "$out" | jq -r '.terraform_outdated')" = "true" ]; then
  echo "::warning::Terraform ${ver} is outdated"
fi

失敗させずに警告に留めておくのが扱いやすい設計です。版の固定は後述の required_version で行い、この判定は「上げ忘れに気づく」ための通知として位置づけると、ビルドが外部要因で止まる事故を避けられます。

更新確認の通信を止める閉域環境ではCHECKPOINT_DISABLEを設定する

古い版の警告は、HashiCorpのCheckpointというサービスへの問い合わせで判定されています。CLIの概要ドキュメントによると、送られるのは利用者や端末を特定できない匿名情報だけで、環境変数 CHECKPOINT_DISABLE に空でない値を入れると全HashiCorp製品で無効化できる仕組みです。CLI設定ファイルの disable_checkpoint = true でも同じ効果が得られます。

外部通信を制限したCI基盤では無効化しておくと待ち時間が出ません。その代わり、判定の元になる問い合わせ自体が止まるため、その環境では terraform_outdated を最新判定の根拠にしない運用に切り替えます。

required_versionとバージョン制約でチームの使用版を固定する方法

チームで版を揃えたい場合や、特定の版でしか動作確認していない場合は、設定側でバージョンを縛れます。terraformブロックのリファレンスにあるとおり、required_version に条件を書くと、条件を満たさないTerraformで実行したときにエラーになります。

terraform {
  required_version = "~> 1.16.0"

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

これを書いておくと、メンバーの端末やCIで意図しない版が使われる事故を防げます。条件を満たさない版で plan や apply を実行すると、Terraformは処理に進まずエラーで停止する仕様です。バージョンを上げるときは、この記述もあわせて更新する運用にしておくと管理が楽になります。設定ファイルの書き方全般についてはTerraformコーディング規約（スタイルガイド）｜fmt・命名規則・ディレクトリ構成の統一ルールで解説しています。

制約演算子の意味の違いとルートと再利用モジュールでの書き分け

制約の書き方は数種類あり、どこまでの更新を許すかが変わります。公式リファレンスの定義をもとに整理しました。

~> は右端の要素だけを増やせる演算子で、~> 1.16.0 ならパッチ版の追従だけを許し、~> 1.16 なら1.17以降のマイナー更新も許します。公式のベストプラクティスでは、複数のプロジェクトから呼ばれる再利用モジュールは下限（>=）だけを書き、上限の管理は呼び出す側のルートモジュールに任せる形が推奨されています。再利用モジュールで上限を縛ると、呼び出し側が本体を上げられなくなるためです。

プロバイダの版は.terraform.lock.hclで本体とは別に固定される

required_version が縛るのはTerraform本体だけで、プロバイダの版は別の仕組みで決まります。依存関係ロックファイルの公式ドキュメントのとおり、terraform init で選ばれたプロバイダの版とハッシュは .terraform.lock.hcl に記録され、次回以降の init でも同じ版が使われます。このファイルはリポジトリにコミットしておくのが前提です。

ロックされた版を制約の範囲内で上げたいときは terraform init -upgrade を使います。本体の版上げとプロバイダの版上げを同じ変更に混ぜると、planに差分が出たときにどちらが原因か切り分けにくくなるため、別々のプルリクエストに分けるのが安全です。プロバイダ側の制約の書き方とaliasの設計はterraform providerのバージョン制約とalias設計｜lockファイルの運用判断で詳しく扱っています。

tfenvで複数のTerraformバージョンを切り替えてプロジェクトごとに使う

複数のプロジェクトを並行して扱うと、プロジェクトAは1.15系、プロジェクトBは1.16系という状況が起きます。そのたびにバイナリを入れ替えるのは手間がかかるため、版の切り替えツールであるtfenvを使うのが定番です。tfenvのリポジトリの説明に沿うと、基本の操作は次のとおりです。

# 配布されている版の一覧（新しい順）
tfenv list-remote | head -5

# 版を入れて切り替える
tfenv install 1.16.4
tfenv use 1.16.4

# 今の版をプロジェクト直下の .terraform-version に書き出す
tfenv pin

# required_version の下限に合う版を入れる
tfenv install min-required

プロジェクト直下に .terraform-version を置いてコミットしておけば、そのディレクトリではtfenvが書かれた版を自動で選びます。required_version と .terraform-version の両方を持つと二重管理に見えますが、役割は別です。前者は「この範囲でしか動かさない」という制約、後者は「普段はこの版を使う」という既定値にあたります。OS別のインストール手順とCIでの版固定の書き方はTerraformのインストール手順をOS別に整理｜tfenv・CIでの版固定までにまとめています。

1.15系から1.16系へアップグレードする手順と事前に確かめる項目

1.16のアップグレードガイドには、1.16はv1.0系列の安定したマイナーリリースで、v1.0の互換性保証を守ると書かれています。1.16固有の追加手順は記載されていません。そのため手順自体は単純ですが、stateを持つ本番環境では次の順番で進めると事故が起きにくくなります。

1. 現状の版を記録する（terraform version の出力をプルリクエストに貼る）
2. 現行の版で terraform plan を実行し、差分が無い状態から始める
3. 新しい版を入れて required_version と .terraform-version を更新する
4. 新しい版で terraform init と terraform plan を実行し、差分が出ないことを確かめる
5. CIのTerraformの版も同じ変更で上げ、ローカルとCIの版をそろえる
6. 問題が無ければ適用し、プロバイダの版上げは別の変更で行う

手順2と4は、終了コードで判定するとCIに組み込みやすくなります。-detailed-exitcode を付けると、差分なしで0、エラーで1、差分ありで2が返ります。

terraform init
terraform plan -detailed-exitcode
echo "exit=$?"   # 0なら差分なし、2なら差分あり

planの差分の読み方や、init・apply・destroyを安全に回す手順はterraform planの差分の読み方｜init・apply・destroyの安全手順で解説しています。

1.x互換性保証の範囲とアップグレード前に差分ゼロを確かめる理由

v1.x互換性保証の公式ページでは、1.0向けに書かれたモジュールは1.x系列の後続版でも設定変更なしにplanとapplyができることを目標にすると述べています。保証の対象は言語機能の大部分、CLIのワークフローコマンドの一部、本体とプロバイダの間の通信プロトコルなどです。

一方で、互換性の問題はバグとして扱うと書かれている程度で、あらゆる挙動が変わらないとは約束されていません。1.16でも create_before_destroy の順序や import の扱いがパッチ版で修正されています。挙動の修正は、以前の版で偶然通っていた構成のplan結果を変えることがあります。上げる前後で差分ゼロを確かめる手順は、この種の変化を適用前に拾うためのものです。

1.16で入った主な変更（モジュール内import・store・destroy無効化）

1.16.0では、状態の扱いとモジュール構成まわりに追加が入りました。公式の変更履歴に挙げられている新機能のうち、実務で影響が大きいものは次のとおりです。

• terraform_data に store ブロックが追加され、一時的な値や機微な値をplanとapplyをまたいで保持できるようになりました
• モジュールの内側に import ブロックを書けるようになりました
• プロバイダが計画時の非公開データを保存できるようになり、plan と apply の間でプロバイダ固有の状態が保たれます
• リソースの lifecycle ブロックで destroy = false を指定し、リソースの削除を防げるようになりました
• アクションのトリガーで on_failure に halt・taint・continue を指定できるようになりました
• contains() 関数で null を判定できるようになりました
• Linux s390x（zLinux）向けのビルド済みバイナリが提供されるようになりました

このうちモジュール内の import 対応は、既存リソースの取り込みをモジュール単位で完結させられるようになるため、大きめの構成を扱っているチームには効きます。destroy = false は、データベースのように消えると困るリソースを守る手段として、従来の prevent_destroy と並ぶ選択肢になります。

出力の機械可読化とterraform graphのMermaid形式出力への対応

既存コマンドの改善では、機械可読な出力への対応が進みました。state show と workspace list がそれぞれ -json フラグに対応し、スクリプトから扱いやすくなっています。terraform console には -scope フラグが加わり、特定のモジュールの中で式を評価できるようになりました。

また terraform graph に -format=mermaid が追加され、依存関係グラフをMermaid形式で出力できるようになりました。ドキュメントにそのまま貼り付けられる形式のため、構成図の維持コストが下がります。

terraform graph -format=mermaid > graph.md

ドキュメント生成そのものを自動化したい場合はterraform-docsの使い方｜README自動生成と設定ファイル、CIでの陳腐化チェックもあわせて参照してください。

すぐ上げるべき場面とパッチ版を待って見送るべき場面の判断条件

最新版が出たら常に上げればよいかというと、そうではありません。stateを持つ本番環境では、ここまでの仕組みを前提に次の条件で判断することをおすすめします。

採用する条件は、同じ系列のパッチ版であること、または必要な新機能が入っていて検証環境でplanの差分ゼロを確認できたことです。1.16系のように、x.y.0の直後の数週間は修正版が毎週出る傾向があります。新しいマイナー版は、x.y.1以降が出て不具合の報告が落ち着いてから本番へ入れるのが無難です。

見送る場面は、リリースの締め切り直前、プロバイダの大きな版上げと時期が重なるとき、そしてCIとローカルの版をそろえる手当てが済んでいないときです。自動で上げる仕組みを入れる場合は、RenovateによるTerraform依存自動更新の仕組みと対応範囲のように、本体とプロバイダの更新を別々のプルリクエストとして出させる設定にしておくと、判断を人が挟める形になります。

ライセンスの観点で版を選ぶ場合もあります。TerraformはBSLライセンスで配布されており、MPLのまま分岐したOpenTofuとは版番号も機能も別々に進んでいます。両者の違いと移行の判断はOpenTofuとは？Terraformとのライセンス・機能差と移行判断を実装視点で解説で整理しました。版上げの方針づくりやIaCの基盤整備を外部に任せたい場合は、一創のインフラ構築（AWS・Google Cloud・Azure）でTerraformによる構築と運用設計を承っています。

過去バージョンの変更点と各版のアップグレードガイドを調べる方法

この記事は最新の版と、版に依存しない確認・固定・アップグレードの方法を扱っています。個別の版で何が変わったかは、公式の一次情報をたどるのが確実です。

• 各系列の変更履歴：GitHubの v1.15・v1.14 などのブランチにある CHANGELOG.md
• 系列ごとの注意点：アップグレードガイドのページにある版の切り替えから、過去系列のガイドを選ぶ
• 配布物そのもの：releases.hashicorp.comの版ごとのディレクトリ

複数の系列をまたいで上げる場合は、各系列のアップグレードガイドを順に確認します。なお、TerraformはHashiCorpが開発しているツールで、同社は他にもVaultなどの製品を持っています。製品全体の位置づけや同社の動向はHashiCorp（ハシコープ）とは？主要製品の違い・IBM買収後の変化・BSLライセンスを解説で解説しました。

よくある質問

Terraformの最新バージョンはいくつですか？

2026年9月29日時点で1.16.4です。2026年9月23日にリリースされました。1.17系はまだbeta段階で、安定版ではありません。

自分が使っているバージョンを調べるには？

terraform version を実行します。Terraform本体に加えて、実行プラットフォームと、作業ディレクトリで選択されているプロバイダのバージョンも表示されます。

使っているバージョンが古いかどうかを自動で判定できますか？

できます。terraform version -json の出力に terraform_outdated という項目が含まれ、より新しい版が出ていれば真になります。CIでこの値を見て警告する運用が可能です。ただしCheckpointを無効化した環境では判定の元になる問い合わせが止まる点に注意します。

バージョンを固定するにはどうすればよいですか？

terraform ブロックの required_version に条件を書きます。条件を満たさない版で実行するとエラーになるため、チーム内やCIでの版ズレを防げます。プロバイダの版は別途 .terraform.lock.hcl で固定する仕組みです。

1.16で特に注目すべき変更はありますか？

モジュール内で import ブロックが使えるようになった点と、terraform_data の store ブロックで機微な値をplanとapplyをまたいで保持できるようになった点です。lifecycle の destroy = false や、terraform graph のMermaid出力対応も運用面で便利です。

関連記事

• Terraformのインストール手順をOS別に整理｜tfenv・CIでの版固定まで
• terraform providerのバージョン制約とalias設計｜lockファイルの運用判断
• terraform planの差分の読み方｜init・apply・destroyの安全手順
• Terraformコーディング規約（スタイルガイド）｜fmt・命名規則・ディレクトリ構成の統一ルール
• terraform-docsの使い方｜README自動生成と設定ファイル、CIでの陳腐化チェック
• HashiCorp（ハシコープ）とは？主要製品の違い・IBM買収後の変化・BSLライセンスを解説