Terraformのインストール手順をOS別に整理｜tfenv・CIでの版固定まで

手元では通るのに、CIランナーだけ古い版で落ちる。新しく参加した人の端末でだけ、身に覚えのない差分が出る。Terraformの導入でつまずく箇所は、コマンドそのものよりも「どの経路で入れるか」と「版をどこで固定するか」の2点に集中します。この記事ではWindows・macOS・Linuxの導入手順を公式の配布方式に沿って整理し、tfenvやmiseによる切り替え、CIランナー側での固定、そして詰まったときの症状別の切り分けまで扱います。版に依存する記述は2026年8月14日にHashiCorp公式ドキュメントとGitHub Releasesで確認した内容です。

まとめ：入れる経路と版を固定する場所の2つを先に決める

結論から置きます。導入経路の選択肢は実質2つしかありません。OSのパッケージ管理（Linuxの公式リポジトリ、macOSのHomebrew tap）で入れるか、tfenvやmiseのような版管理ツールで入れるか。1人で検証するだけなら前者、複数人で同じコードを触るなら後者を選びます。分岐点はチームの人数ではなく、同じリポジトリを2人以上が別々の端末でapplyするかです。

版を固定する場所は3つあり、役割が違います。リポジトリ内の.terraform-versionが端末側の実行版、terraformブロックのrequired_versionが許容範囲の柵、CIワークフローのterraform_versionがランナー側の実行版。正はリポジトリ内のファイルに置き、CIはそこを読むか、同じ値を1箇所で管理します。3つがバラバラに書かれている状態が、いちばん事故につながる構成。

Windowsだけは公式ページにパッケージ管理の記載がなく、バイナリ配布のみという扱いです（2026年8月14日時点）。WSL2上でLinuxとして入れるか、wingetのコミュニティマニフェストを使うか、zipを手で置いてPATHを通すかの三択になります。ここを曖昧にしたまま「とりあえず入れた」状態で共同開発に入ると、後から全員の環境を揃え直す作業が発生します。

Terraformのインストール前に決める配布形態と版方針の整理

手順に入る前に、何の版を管理しているのかを分けておきます。ここが混ざると、後の切り分けで必ず迷います。

本体・provider・stateの3層で版が分かれる構造の把握

Terraformの環境は3つの層でできています。1つ目がCLI本体、2つ目がAWSやGoogle Cloudを操作するprovider、3つ目が実体の記録である状態ファイル。インストールで扱うのは1つ目だけです。

この区別が効いてくるのは、エラーが出たときです。terraform initでproviderの取得に失敗するのは本体の入れ方の問題ではなく、レジストリへの到達性かバージョン制約の問題。逆にterraformコマンド自体が見つからないなら、providerもstateも関係ありません。providerの版の決め方はterraform providerのバージョン制約とalias設計｜lockファイルの運用判断、状態ファイルの構造はTerraform stateとは？tfstateの構造とS3バックエンド・移動削除の安全手順で個別に扱っています。

宣言的な構成管理そのものの考え方と、そもそもIaCを導入すべきかの判断はIaCとは？Infrastructure as Codeの仕組み・メリットと導入判断を解説に整理しました。本記事は導入を決めた後の話に絞ります。

公式が配布するzip形式とパッケージ管理の対応OS範囲の違い

HashiCorpの公式インストールページは、OSごとに提供している手段が異なります。2026年8月14日時点の配布状況を整理すると、次のようになります。

バイナリはどのOSでも単一の実行ファイルをzipで固めた形で、展開してPATHの通った場所に置けば動きます。依存ライブラリを引き連れてこないため、パッケージ管理が使えない環境でも導入できるのが利点。Linuxは386・AMD64・ARM64に加えてARM・S390Xまで配布されているので、ARM系のCIランナーでも同じ手順が通ります。

公式はSHA256のチェックサムと、HashiCorpのGPG鍵で署名されたチェックサムファイルの検証手順も案内しています。バイナリを手で置く運用を選ぶなら、この検証をセットで組み込んでおくと、後で監査を求められたときに説明できます。

BUSL 1.1ライセンスと企業導入で確認する利用条件の範囲

Terraformのライセンスは、1.6.0以降がBusiness Source License 1.1です。リポジトリのLICENSEファイルで確認できます。オープンソースライセンスではなく、ソースは公開されているが用途に条件が付くソースアベイラブル型。

条文にはChange Dateが「Four years from the date the Licensed Work is published.」と定められ、公開から4年経過した版はChange LicenseであるMPL 2.0に切り替わります。つまり時間の経過とともに古い版から順にMPL 2.0になる仕組み。

企業で入れる前に確認するのは1点だけです。自社がTerraformと競合する商用製品を提供していないか。受託開発や自社インフラの構築管理といった一般的な業務利用は制限の対象外で、ここで止まるケースは実務ではほとんどありません。ただし法務レビューを通す会社では、導入申請の時点でBUSLである事実を書いておくと差し戻しを避けられます。

Windows・macOS・LinuxのOS別インストール手順と確認まで

ここからは実際の手順です。どのOSでも、入れる場所を決めてPATHを通し、動作を確かめるという流れは変わりません。

Windowsでのzip配置とPATH登録・wingetの使い分け

公式ページにはWindows向けのパッケージ管理の記載がなく、386・AMD64・ARM64のバイナリ配布のみです。素直に進めるなら、zipをダウンロードしてC:\tools\terraformのような固定パスに展開し、そのディレクトリをシステム環境変数のPathに追加します。ユーザープロファイル配下ではなく、パスに空白と日本語を含まない場所に置くのが後々のトラブルを減らす置き方。

もう1つの経路がwingetです。microsoft/winget-pkgs には Hashicorp.Terraform のマニフェストが登録されており、1.2.9から1.15.8までのバージョンディレクトリを確認できます（2026年8月14日時点）。ただしこれはコミュニティが管理するリポジトリで、HashiCorpの公式ページが案内している経路ではありません。個人の検証端末では手数が減って便利ですが、業務端末で使うなら「公式配布ではない」点を承知したうえで選びます。

WSL2を常用しているなら、Windows側には入れずLinux側に入れる判断もあります。CIランナーがLinuxである以上、開発端末もLinux側に寄せたほうが改行コードやパス区切りの差で悩む場面が減る。tfenvを使う予定があるなら、この選択がほぼ前提になります。

macOSのHomebrew tap導入とApple Silicon環境での注意点

macOSは公式がHomebrewのtapを案内しています。brew tap hashicorp/tapでtapを追加し、brew install hashicorp/tap/terraformで本体を入れる2段構え。tap名を省いた短い指定と混同しやすいので、公式が示すフルの指定で書いておくと、別のformulaが入る事故を避けられます。

Apple Silicon環境では、Homebrewの導入先が/opt/homebrewになります。Intel時代の/usr/local配下に古いバイナリが残っていると、PATHの並び順によってはそちらが優先されて版が上がらない。which -a terraformで候補を全部出し、意図した1つだけが残っているかを見てください。

Homebrewで入れた場合、brew upgradeのたびに本体の版が動きます。これは1人で検証する分には手間が減りますが、チームで同じ版に揃えたい場面では逆に働く挙動。後述するtfenv側に管理を寄せるなら、Homebrewでの本体導入は行わず、tfenvだけをHomebrewで入れる形にします。

Linuxの公式リポジトリ登録とディストリビューション別手順

Linuxは公式リポジトリを登録する方式が案内されています。HashiCorpのGPG鍵を登録し、リポジトリを追加したうえで、Ubuntu・Debianならapt install terraform、CentOS・RHELとAmazon Linuxならyum -y install terraform、Fedoraならdnf -y install terraformを実行する流れ。鍵とリポジトリの登録を飛ばすと、ディストリビューション標準のリポジトリに存在しないためパッケージが見つからないエラーになります。

コンテナイメージの中で入れる場合は、リポジトリ登録に必要なgnupgやcurlを先に入れる必要があり、レイヤが増えます。イメージを軽くしたいなら、リポジトリ登録ではなくzipを取得して展開する方式のほうが手数が少ない。この判断はDockerfileの行数ではなく、チェックサム検証を挟むかどうかで決めます。

LinuxでもHomebrewのtapは使えますが、Linuxbrewの導入自体がPATHとビルド依存を持ち込むため、サーバー側で選ぶ理由は薄い。開発端末がmacOSとLinuxで混在しているチームでは、tfenvかmiseに寄せて手順を1本化したほうが説明が短く済みます。

インストール後にversionとinitで動作を確かめる順序

導入したら、確認は2段階で行います。まずterraform versionで本体が起動し、意図した版が返るか。ここで古い版が返るなら、PATHに複数のバイナリが乗っている状態です。

次に、空のディレクトリに最小の設定ファイルを1つ置いてterraform initを通します。本体が動くことと、providerを取得できることは別の話。社内プロキシやレジストリ制限がある環境では、versionは通るのにinitで止まるという切り分けが最初に必要になります。initからapplyまでの差分の読み方はterraform planの差分の読み方｜init・apply・destroyの安全手順で個別に扱いました。

補助としてterraform -install-autocompleteを実行しておくと、bashやzshの補完設定がシェルの設定ファイルに追記されます。サブコマンドとオプションの補完が効くようになり、打ち間違いによる無駄な実行が減る。CIランナーでは不要なので、開発端末だけで実行してください。initまで通ったら、次は自分たちで書いたモジュールが意図どおり組み上がるかの検証に進みます。手順はterraform testの書き方｜unit/integrationの分け方とCIコストにまとめました。

tfenvとmiseによるバージョン切替と固定ファイルの運用

複数のリポジトリを行き来し始めた時点で、本体を1つだけ入れる運用は破綻します。ここからは版を切り替える仕組みの話です。

tfenvの導入方法とWindowsで事前設定が必要になる利用条件

tfenvはmacOS（64bitとApple Silicon）、Linux（64bitとARM）、そしてWindows 64bitのgit-bashをサポートしています。導入はbrew install tfenvが最短。Homebrewを使わないなら、git clone --depth=1でリポジトリを~/.tfenvに取得し、~/.tfenv/binをPATHに追加します。Arch UserリポジトリやPuppet経由の導入も用意されています。

Windowsで使う場合は事前設定が1つ必要です。公式リポジトリはgit config --global core.symlinks trueでシンボリックリンクを有効にするよう明記しています。この設定を入れずに導入すると、リンクがファイルとして展開されてバージョン切り替えが機能しません。PowerShellやコマンドプロンプトではなくgit-bashから実行する点も合わせて押さえてください。

Homebrewで本体を入れた端末にtfenvを重ねると、PATHの並びによってどちらが呼ばれるか変わります。tfenvに寄せると決めたら、先にbrew uninstall hashicorp/tap/terraformで本体を外す。この片付けを飛ばした端末が、後で「自分だけ版が違う」の発生源になります。

.terraform-versionによる版固定とlatest指定の判断

tfenvの中心は.terraform-versionというファイルです。プロジェクトルートかホームディレクトリに置くと、tfenvがそれを読んで版を解決します。tfenv installを引数なしで実行すれば、このファイルの内容に従って必要な版が入る仕組み。

書ける値は3種類あります。1.15.8のような具体的なバージョン、latest、そしてlatest:^0.8のようなパターン指定。リポジトリに置くファイルでは、具体的なバージョンを書いてください。latestを書くと、誰がいつ実行したかで入る版が変わり、ファイルを置いた意味がなくなります。

切り替えはtfenv use、導入済みの一覧はtfenv list、導入できる版の一覧はtfenv list-remote、削除はtfenv uninstall。運用で使うのはこの4つでほぼ足ります。バージョンごとの新機能がどこで入ったかを追うときは、DevOps実践者に向けたTerraform v1.14.0アップデートの概要と目的を詳しく解説のようなリリース単位の記事で差分を確認してから上げると、切り替え後の想定外が減ります。

min-requiredとlatest-allowedで制約から版を決める手順

tfenvには、設定ファイルの制約から版を逆算する機能が2つあります。min-requiredは設定ファイルを走査して最小限必要な版を特定し、latest-allowedは制約演算子（>=・<=・~>・=）から許容される最大の版を解決します。

使い分けの基準は明確です。既存リポジトリを引き継いで「とりあえず動く最低限の版」を知りたいときはmin-required。運用中のリポジトリで「制約の範囲内でどこまで上げられるか」を確かめたいときはlatest-allowed。後者を定期的に回すと、制約を触らずに上げられる余地が可視化されます。

ただしこの2つを.terraform-versionの代わりに常用するのは避けてください。解決結果が設定ファイルの内容に依存するため、コードを直した瞬間に実行版が変わります。調査用のコマンドとして使い、結果を具体的なバージョンとしてファイルに書き戻すのが安全な回し方です。

tfenvとmiseとasdfの選び分けと併用時に起きる衝突

版管理ツールはtfenv以外にもあり、Node.jsやPythonをmiseやasdfで管理している現場では、Terraformも同じツールに寄せたくなります。判断は「他言語のランタイムを既に何かで管理しているか」で決めてください。何も入れていないならtfenv、既にmiseがあるならmiseに寄せる。理由は単純で、PATHに割り込むツールが2つあると、どちらが解決したのか追えなくなるからです。

ここに実務で刺さる落とし穴が1つあります。miseは.terraform-versionのようなidiomatic version fileを読む機能を持っていますが、公式ドキュメントは「In mise, these are disabled by default」と明記しており、既定では無効です。tfenvからmiseへ移行した直後、リポジトリに.terraform-versionがあるのに黙って無視され、mise側の設定にある版で動く。エラーも警告も出ないため、差分が出るまで気づきません。

回避策は、設定idiomatic_version_file_enable_toolsにterraformを追加して明示的に有効化するか、あるいはmiseの設定ファイル側に版を書いて.terraform-versionを捨てるかの二択です。両方を残して片方だけ有効にする中途半端な状態が、いちばん再現性を落とします。移行するなら、リポジトリからtfenv用のファイルを消すところまでを1つのPRに含めてください。

CIランナー側で版を固定する手順とlockファイルの役割分担

端末側を揃えても、CIランナーが別の版で走っていれば意味がありません。ここは端末とは別の仕組みで固定します。

setup-terraformでの版指定とterraform_wrapperの扱い

GitHub Actionsならhashicorp/setup-terraformが標準的な選択です。最新リリースはv4.0.1で、2026-05-12公開。この版はNode 24のDEP0169（url.parseの非推奨）警告を解消するために依存ライブラリを更新した内容で、機能追加ではありません。メジャータグで参照している場合、この修正は自動で取り込まれます。

指定するのはterraform_versionで、ここに具体的なバージョンを書きます。省略すると最新版が入り、ある日突然ランナー側だけ版が上がる。端末側の.terraform-versionと同じ値を書くか、ワークフローからそのファイルを読んで渡す形にしてください。

もう1つ挙動として押さえておくのがterraform_wrapperです。既定で有効になっており、Terraformの実行を包んで標準出力や終了コードを後続ステップから参照できるようにします。planの結果をPRコメントに出す構成では有用ですが、出力を自前でパースする作りにしていると、ラッパー経由の整形が邪魔をすることがある。その場合は明示的に無効化します。パイプライン全体の組み方とOIDCによる認証はTerraformとGitHub ActionsでAWSのCI/CDを構築する手順｜OIDC・S3ロック対応で扱いました。

required_versionと.terraform-versionの二重管理を避ける

terraformブロックのrequired_versionと.terraform-versionは、似て非なるものです。前者は「この設定を実行してよい版の範囲」を宣言する柵で、範囲外の版で実行すると停止する。後者は「実際に使う版」の指定で、tfenvが読むファイル。

実務での書き分けはこうします。required_versionは~> 1.15のように範囲で書き、.terraform-versionには1.15.8のように1点で書く。柵を広く、実行版を1点に絞る形です。両方を同じ1点のバージョンで固めると、パッチを1つ上げるだけで2ファイルの修正とレビューが要ります。

更新の運用も決めておいてください。上げるときは.terraform-versionとCIワークフローのterraform_versionを同じPRで動かし、required_versionはマイナーをまたぐときだけ触る。この分担にすると、日常のパッチ更新が1ファイルの変更で済みます。環境ごとに版を変えたくなった場合は、版で分けるのではなく実行対象の分離で解く方法をterraform workspaceの使い方と環境分離の判断基準｜分割方式の比較で比較しています。

Dockerイメージでの版固定とチェックサム検証を入れる基準

CIランナーの起動ごとにバイナリを取りに行く構成は、外部への依存が1本増えます。実行回数が多いリポジトリでは、Terraform本体を焼き込んだイメージを自前で持ち、タグで固定するほうが安定する。判断の基準は、1日あたりのパイプライン実行回数と、外部到達が制限された環境かどうかの2点です。

イメージを作るなら、zipの取得時にSHA256チェックサムの検証を必ず挟んでください。公式は署名済みのチェックサムファイルとGPG鍵での検証手順を案内しており、この検証まで入れて初めて「取得したバイナリが公式のものである」と説明できます。パッケージ管理経由なら署名検証はリポジトリの仕組みに含まれますが、zipを手で取る方式では自分で組み込む必要がある部分。

ここまでの設計を社内だけで回すか、実行環境ごと外に出すかという選択もあります。実行とstateの保管をSaaS側に寄せる選び方はHCP Terraformとは？旧Terraform Cloudの料金・機能とHCPでの位置づけ｜使い方も解説で整理しました。導入から運用まで含めて設計を任せたい場合は、インフラ構築（AWS・Google Cloud・Azure）で受託した構築案件でも、この版固定の設計を初期セットアップに含めています。

チーム規模と運用条件別の導入方式の選び分けと見送るべき場面の判定

ここまでの手段を、どの場面で選び、どの場面で選ばないかを言い切ります。全部入れる必要はありません。

1人開発とチーム開発で分かれる版管理ツール導入の要否判断基準

版管理ツールが要るかどうかは、人数ではなく触るリポジトリの数で決めます。1人でも3つのリポジトリを行き来していて、それぞれ制約が違うなら要る。逆に5人いても全員が単一リポジトリだけを触るなら、パッケージ管理で入れて更新タイミングを合わせるほうが手数が少ない。

切り替えの目安は具体的に置けます。required_versionの異なるリポジトリを2つ以上抱えた時点でtfenvかmiseを入れる。それまではHomebrew tapや公式aptリポジトリで十分です。先回りして版管理ツールを入れると、PATHに層が1つ増えるだけで、得るものがありません。

新規参加者の環境構築にかかる時間も判断材料になります。手順が「READMEの1コマンド」で終わるかどうか。tfenvを入れてtfenv installを叩くだけ、という形に収まるなら導入の価値があります。手順が5行を超えるなら、そのチームには重い。

パッケージ管理での自動更新を見送るべき運用条件と代替手順の選択

パッケージ管理の導入を見送るべき場面は、条件で言い切れます。次のいずれかに当てはまるなら選ばないでください。

• 他ツールのまとめ更新でTerraform本体まで動く運用になっている場合。brew upgradeやapt upgradeの巻き添えで版が上がり、applyの直前に差分の出方が変わります。
• 本番環境へapplyする端末やランナーである場合。実行版が意図せず動く経路を1つでも残すと、事故が起きたときの原因追跡ができません。
• 外部リポジトリへの到達が制限された環境の場合。鍵とリポジトリの登録が通らず、結局バイナリ配置に戻ることになります。

代替は難しくありません。バイナリを固定パスに置き、チェックサムを検証し、版を上げるときだけ人の手で差し替える。手順としては素朴ですが、いつ誰が上げたかがコミット履歴に残る点で、自動更新より説明しやすい構成になります。

インストールで詰まる症状別の原因切り分けと対処手順を選ぶ判断基準

導入直後に出る症状は、原因がほぼ決まっています。エラーメッセージを検索する前に、次の対応表で当たりを付けてください。

この表で当たらない症状は、本体の導入ではなくproviderかstate側の問題です。切り分けの順序を守れば、調べる範囲が1桁狭くなります。

よくある質問

導入時に検索されやすい疑問を、実際の仕様に沿って短く答えます。

Terraformのインストールコマンドは全OSで共通ですか？

共通ではありません。macOSとLinuxはHomebrewの公式tapが使え、Linuxは加えてapt・yum・dnfの公式リポジトリが案内されています。Windowsは公式ページにパッケージ管理の記載がなく、バイナリ配布のみです（2026年8月14日時点）。共通しているのは、単一の実行ファイルをPATHの通った場所に置けば動く、というバイナリ配布の性質だけ。この性質のおかげで、どのOSでもzip展開という同じ手順に落とせます。

Windowsではwingetと手動のzip配置のどちらを選ぶべきですか？

業務端末なら手動のzip配置を推奨します。Hashicorp.Terraformのマニフェストはmicrosoft/winget-pkgsに存在し1.15.8まで登録されていますが、これはコミュニティが管理するリポジトリで、HashiCorp公式が案内している経路ではありません。個人の検証端末で手数を減らしたい場合は選んで構いません。WSL2を常用しているなら、Windows側ではなくLinux側に入れるほうが、CIランナーとの環境差が小さくなります。

tfenvはWindowsでも使えますか？

利用可能です。tfenvはWindows 64bitのgit-bash環境をサポートしています。ただし条件が1つあり、git config --global core.symlinks trueでシンボリックリンクを有効にしておく必要があると公式リポジトリが明記しています。この設定を入れずに導入すると、リンクが通常のファイルとして展開されてバージョン切り替えが動きません。PowerShellやコマンドプロンプトからではなく、git-bashから実行してください。WSL2があるなら、そちらでLinuxとして使うほうが素直です。

terraformコマンドが見つからないと出るのはなぜですか？

ほぼPATHの問題です。バイナリを置いた場所が環境変数に登録されていないか、登録した後にシェルを開き直していないかのどちらか。まず配置先のディレクトリがPATHに含まれているかを確認し、含まれていれば新しいシェルを起動して再実行します。それでも解決しない場合は、which -a terraformで候補を全部出してください。複数のバイナリが見つかるなら、意図しないほうが先に解決されている状態です。

Terraformの最新版はどこで確認できますか？

GitHubのリリース一覧か、HashiCorp公式のインストールページで確認できます。2026年8月14日時点の最新安定版はv1.15.8で、2026-07-08に公開されました。ただし最新版を常に追う必要はありません。リポジトリのrequired_versionで許容範囲を決め、.terraform-versionで具体的な版を固定し、上げるタイミングは自分たちで決める。バージョンごとの変更点は、リリース単位の解説記事で差分を確認してから切り替えると安全です。

関連記事

• IaCとは？Infrastructure as Codeの仕組み・メリットと導入判断を解説：そもそもIaCを入れるかどうかの判断。
• DevOps実践者に向けたTerraform v1.14.0アップデートの概要と目的を詳しく解説：版ごとの変更点の追い方。
• terraform planの差分の読み方｜init・apply・destroyの安全手順：導入後に最初に通す実行の流れ。
• terraform providerのバージョン制約とalias設計｜lockファイルの運用判断：本体とは別に管理するprovider版。
• TerraformとGitHub ActionsでAWSのCI/CDを構築する手順｜OIDC・S3ロック対応：CI側の組み方と認証の設計。