数百人規模のシステム子会社を抱え、オンプレミスと複数クラウドを併用する製造業のインフラ担当者を想像してほしい。同社は数年前からTerraform Cloudでインフラ構成を一元管理し、年次の内部統制監査でも「構成変更の証跡が残る」ことを評価材料にしてきた。ところが2026年に入り、無料枠の終了、terraform importの有償プラン限定化、Resources Under Management（RUM、管理下のリソース数に応じた従量課金）方式への一本化が相次ぎ、契約更新の見積り額が読みにくくなっている。
Terraform CloudおよびTerraform Enterprise（IBM傘下のHashiCorpが提供するIaC＝Infrastructure as Code、インフラ構成をコードで宣言的に管理する仕組みの商用SaaS/オンプレ版）は、2023年6月にRUM課金へ移行済みだが、2026年はその上に無料枠の縮小と機能制限が重なった年になった。本稿は、この価格変化の実態を一次情報ベースで整理したうえで、オープンソースフォークであるOpenTofuへの移行を検討する境界線を示す。
予備知識
- IaC（Infrastructure as Code）: サーバーやネットワークの構成をコードで宣言し、バージョン管理・自動適用する手法。
- RUM（Resources Under Management）: Terraform Cloud/Enterpriseの課金方式。state（状態ファイル）で管理中のリソース数×時間で課金される。
- BUSL（Business Source License）: HashiCorpが2023年にTerraformへ適用したライセンス。競合SaaS事業者による再販的利用を制限する条項を持つ。
- OpenTofu: BUSL移行に反発したコミュニティがLinux Foundation傘下で立ち上げたTerraformのフォーク。完全なドロップイン互換を掲げる。
契約形態を見直す前に、まず自社のTerraform運用がベストプラクティスから外れていないかを確認したい担当者向け。
2026年に何が変わったか
まず事実関係を確認する。HashiCorpの公式価格ページ［1］および競合SaaS事業者Scalrがまとめた変更履歴［4］によると、Terraform Cloud（HCP Terraform）は2026年時点でEssentials（1リソースあたり月0.10ドル）、Standard（同0.47ドル）、Premium（同0.99ドル）の3段階のRUM課金で、Enterpriseは個別見積りとなっている。後者は移行先を売る立場のまとめである点は割り引いて読む必要がある。
2026年に入ってからの変化点は主に3つである。第一に、無料で使えていた旧「Free（Legacy）」プランが2026年3月31日にEOL（提供終了）となり、以降は管理リソース500件・同時run1件までの縮小版Freeプランへ自動移行された［4］。第二に、terraform import（既存インフラをTerraform管理下に取り込むコマンド）が上位プラン限定になっているとの報告が2026年1月に広まった。ただしScalrの整理では制限そのものは2025年1月に告知なく入っており［4］、2026年の新規変更というより、この時期に周知が進んだものと見るのが正確である。第三に、2026年2月19日付でEssentials/Standard/Premiumの単価が正式に公開され［4］、料金体系の透明性は上がった一方、実効コストは管理リソース数に比例して増える構造が明確になった。
仮に5,000リソースを一定期間管理する環境を想定すると、Essentialsで月額500ドル、Standardで2,350ドル、Premiumで4,950ドル相当という試算になる（下図参照）。IBMによるHashiCorp買収（2025年2月完了）後、Enterprise版の更新見積りが前年より増加したという報告も業界メディアに複数見られるが、具体的な増加率は一次ソースで確認できておらず、本稿では数値を明記しない。
TerraformとAWS CDKを実装レベルで比較しており、ツール選定の判断軸を広げたい人に向く。
OpenTofuという選択肢 — Fidelityの移行実例
価格構造の変化を受けて選択肢に上がるのがOpenTofuである。Linux Foundation傘下で開発され、公式サイトによれば3,900以上のプロバイダーと23,600以上のモジュールをレジストリで提供し［3］、既存のTerraform構成をそのまま読み込める「ドロップイン互換」を掲げる。
実例として参考になるのが、米大手金融サービス企業Fidelity Investmentsの移行事例である。2023年のBUSL移行を機に社内検討が始まり、2025年10月に公開された移行記録がその経緯を残している［2］。同社は2,000超のアプリケーションで合計5万件超のstateファイル、400万件超のクラウドリソースをTerraform/OpenTofuで管理しており、1日あたり4,000件規模のstate更新が発生する運用規模を持つ［2］。同社ブログによれば、移行はまず社内IaCプラットフォーム上でCI/CD・ガバナンス・アーティファクト保管を含む本番同等のPOCから始め、state数の多いチームを優先的に巻き込みながら社内のDevOps評議会・プラットフォームエンジニアリングギルドで合意形成を進めた［2］。合意ができたあとに先行プロジェクト（lighthouse project）で再検証し、そこで広く開放している。移行ツール群は「Bento」というコード名でパッケージし、社内で語りやすくした点も明かしている。全体の70%のプロジェクトで移行が完了した段階でデフォルトCLIをOpenTofuへ切り替え、以降は明示的なオプトアウトがない限りOpenTofuが標準になっている［2］。
Fidelityでクラウド自動化・ツーリングを統括するVPのDavid Jackson氏は「OpenTofuは我々の価値観とプラットフォームエンジニアリング戦略に合致する」と述べており、同社の動機はライセンス費用の逼迫というより、単一ベンダーへの過度な依存を避けるガバナンス上の判断だったとされる。この点は、コストだけでなく「誰が将来のロードマップを握るか」という統制上の論点として読み替える価値がある。
IaC（Infrastructure as Code）ツールの主流を長年担ってきたTerraformは、2023年8月のBSL（Business Source License）ライセンス変更を境に、商用利用の制約が明確化した。2025年2[…]
移行判断のフレームワーク
とはいえ、すべての企業がFidelity規模の移行体力を持つわけではない。移行判断は次の3軸で整理すると実務に落としやすい。
第一にコスト軸。RUM課金の実額は前述の試算どおりリソース数に比例するため、まず自社の管理リソース数と成長見込みを棚卸しし、Essentials/Standard/Premiumのどの段階に該当するかを確認する。第二に運用軸。Terraform CloudやEnterpriseが提供するSSO連携・監査ログ・run履歴などのマネージド機能を、OpenTofu移行後は自前運用（Spacelift、Scalr、env0などのサードパーティプラットフォーム、または自社CI/CD）で代替する必要があり、この運用コストを移行判断に含め忘れると比較が歪む。第三に互換性軸。プロバイダーやモジュールの多くはTerraformとOpenTofuの双方で動作するが、HashiCorp製品固有の拡張機能（Sentinel後継のtfpolicy等）を使っている場合は個別に移行経路を確認する必要がある。
| 判断軸 | Terraform Cloud/Enterprise継続 | OpenTofu移行 |
|---|---|---|
| コスト構造 | RUM従量課金（単価公開済み・予測可能） | ライセンス費ゼロ。運用基盤を自前で持つか、Spacelift・Scalr・env0等の有償プラットフォームを使うかで実額が決まる |
| ガバナンス | HashiCorp（IBM）のロードマップに依存 | Linux Foundation傘下、コミュニティ主導 |
| 移行負荷 | なし | state・CI/CD・ポリシーの検証が必要（Fidelityはプロジェクトの70%到達時点でデフォルトCLIを切り替え） |
| サポート体制 | ベンダー公式サポート | サードパーティ（Spacelift等）または自前 |
従業員数2,000〜3,000人規模でMicrosoft EA（Enterprise Agreement、大規模組織向けの複数年ボリュームライセンス契約）を数年ごとに更新してきた企業の情シス・調達担当者は、次回の契約更新で従来どおりの手続[…]
日本企業のIaC契約はどこで判断が止まるか
海外の分析はコストとガバナンスの二択で語られることが多いが、日本企業では判断のボトルネックがもう一段手前にある。
第一に、Terraform Cloud/Enterpriseの導入・運用をSIerに委託しているケースでは、契約はSIerとの保守契約に組み込まれていることが多い。この場合、HashiCorp側の価格改定がいつ自社の請求額に反映されるかは保守契約の更新条件しだいで、改定の事実を知っていても、対応の意思決定権が調達部門とSIerの双方にまたがって判断が遅れやすい。自社がどちらの立場かは、まず契約書の料金改定条項を読むところからしか分からない。第二に、内部統制監査でIaCツールの構成変更履歴・承認フローが監査対象になっている企業では、OpenTofuへの切り替えは単なるツール変更ではなく「統制文書の更新」を伴う。金融機関であれば、システムの開発・運用に関する安全対策をまとめたFISC「金融機関等コンピュータシステムの安全対策基準・解説書」（第12版）が事実上の参照基準になっており［5］、使用するツールを差し替えれば、対象の規程と証跡の取り方を書き直したうえで監査側の確認を受ける工程が発生する。監査対応のコストを移行コストに含めずに比較すると、机上の試算より実際の移行負荷は大きくなる。第三に、既存システムの年数が長い企業ほどTerraform管理下にないレガシーリソースが混在しており、移行前の棚卸し工数がFidelityのような大規模事例よりも相対的に重くなる傾向がある。
整理すると、判断のタイミングは契約更新の3〜6カ月前に来る。そこで管理リソース数と契約構造を棚卸ししておかないと、更新月には選択肢が「そのまま継続」しか残らない。比較すべきなのは値上げ額と移行費用ではなく、監査対応まで含めた総移行コストと、継続した場合の増分である。
よくある質問（FAQ）
Q. TerraformからOpenTofuへの移行にライセンス費用はかかりますか。
A. OpenTofu自体はオープンソースで無償です。ただし移行検証やCI/CD再構築の人件費、サードパーティ運用基盤を使う場合はその利用料が別途発生します。
Q. 既存のTerraform構成ファイルはそのままOpenTofuで使えますか。
A. 多くの場合はほぼそのまま利用できますが、HashiCorp製品固有の拡張機能（Sentinel後継のtfpolicy等）を使っている構成は個別に代替策を検討する必要があります。
Q. 無料プランだけで小規模なTerraform運用を続けることはできますか。
A. 2026年3月31日のEOL以降も、管理リソース500件・同時run1件までの縮小版Freeプランは存在します。ただしこの上限を超える運用では有償プランへの移行が必要です。
まとめ
2026年に起きたのは値上げというより、無料で使える範囲の縮小と、単価が公開されたことによる「見えるようになった」という変化である。単価が見えた結果、管理リソース数がそのままコストになる構造がはっきりした。移行の境界線は、この構造とOpenTofu側の運用負担が交差するところにある。ただしFidelityの事例が示しているのは、その交差点の位置を測ることより、社内で合意を作る工程のほうが長いという事実のほうだ。技術的な互換性は移行判断の前提であって、決め手ではない。
出典
[1] https://www.hashicorp.com/en/pricing/terraform[2] https://opentofu.org/blog/fidelity-investment-migration/
[3] https://opentofu.org/
[4] https://scalr.com/learning-center/hcp-terraform-free-tier-is-being-discontinued-what-you-need-to-know
[5] https://www.fisc.or.jp/publication/book/006241.php
