こんにちは、インフラエンジニアのryuです。
インフラの世界で、この2〜3年でいちばん静かに、けれど根っこから景色が変わった分野はどこか。私は迷わず「IaC（Infrastructure as Code）」だと答えます。
きっかけは技術の進歩そのものではありませんでした。ライセンスの一行が変わったこと。そして、その道具を作っていた会社が別の巨大企業に買われたこと。
「たかがライセンスでしょう？」と思うかもしれません。でも、あなたのチームが毎日触っている道具の使用条件が、ある日いきなり書き換わったら、どう感じるでしょうか。
2026年のいま、Terraform と、そのフォークとして生まれた OpenTofu は、どちらを選ぶのが正解なのか。これから学ぶ人はどちらから触ればいいのか。
今日はこの話を、専門用語をなるべくかみ砕きながら、歴史と実務の両面から整理してみます。
そもそもIaC（Infrastructure as Code）って何だっけ？¶
まず土台の確認からいきましょう。
昔のサーバー構築を、引っ越しにたとえてみます。新しい家に着いて、家具を一つひとつ手で運び、コンセントの位置を確かめ、棚を組み立て、本を並べる。全部が手作業です。
クラウドのサーバー構築も、以前は似たようなものでした。管理画面をポチポチとクリックし、ネットワークを引き、仮想マシンを立て、権限を設定する。人間が一つずつ手で操作していたわけです。
この手作業には、二つの困りごとがあります。
一つは、同じ環境をもう一度作るのがとても大変なこと。「本番とまったく同じ検証環境をください」と言われても、記憶とメモを頼りに再現するしかありません。
もう一つは、誰がいつ何を変えたのか、あとから追いにくいこと。気づいたら設定がバラバラで、「この設定、誰が入れたの？」が始まります。
IaCとは、こうしたインフラの構成を、手作業のクリックではなく「コード（設定ファイル）」として書き、そのコードから環境を自動で組み立てる考え方です。
引っ越しの例で言えば、「どの部屋に何を置くか」を紙の図面にきっちり書いておき、その図面どおりに全自動で家が組み上がるイメージですね。
なぜ手作業ではダメなのか¶
コードにしておくと、うれしいことがいくつも生まれます。
図面（コード）をコピーすれば、同じ環境を何度でも作れます。図面をGitで管理すれば、変更履歴が全部残ります。レビューもできます。壊れたら図面から作り直せばいい。
つまりIaCは、インフラを「職人の勘と手作業」から「再現できるソフトウェア開発」へ引き上げる技術なのです。GitやGitHubの知識がインフラエンジニアにも必須になったのは、まさにこの流れが背景にあります。
もう一つ大きいのは、チームで働くときの安心感です。手作業だと「触れるのはあの人だけ」という属人化が起きがちですが、コードならレビューを通して知識を共有できます。誰かが休んでも、図面さえ読めれば別の人が引き継げる。インフラを一人の記憶から解き放つ——これもIaCの静かな、しかし大きな価値です。
そして、このIaCの世界で長らく王様だったのが Terraform でした。クラウドの種類（AWS、Azure、Google Cloud…）を問わず、同じ書き方で環境を定義できる。この「どこでも同じ」の便利さで、Terraformはデファクトスタンダードになっていったのです。
2023年、何が起きたのか？ ライセンス変更とOpenTofuの誕生¶
さて、ここから話が動きます。
2023年8月、Terraformを開発するHashiCorp社が、突然ライセンスを変更しました。それまでの MPL 2.0（誰でも自由に使える、いわゆるオープンソースの代表的なライセンス）から、BSL 1.1（Business Source License）へ切り替えたのです。
BSLは、少しクセのあるライセンスです。個人の学習や社内利用なら基本的に使えます。でも「Terraformと競合するサービスを作って商売してはいけない」という制限が付きました。
オープンソースだと思って安心して土台に据えていた道具に、ある日「商用の使い方には条件があります」という但し書きが付いた——コミュニティはこれを、そう受け止めました。
この変更に、Terraformを事業の土台にしていた企業やエンジニアたちが強く反発します。
BSLって、何がそんなに問題だったの？¶
問題の本質は「予測できなさ」でした。
いま使えているからといって、明日も同じ条件で使える保証はどこにあるのか。会社の方針一つで、また条件が変わるかもしれない。事業の根っこを、一社の判断に委ねてよいのか——という不安です。
そこでコミュニティが取った行動が、フォークでした。フォークとは、あるソフトウェアのコードをまるごと複製して、そこから別のプロジェクトとして育てていくことです。
2023年9月、Linux Foundationのもとで OpenTofu が誕生します。ライセンスがまだ自由だった最後の時点のTerraformのコードを引き継ぎ、MPL 2.0のまま歩み続けるプロジェクトです。名前は違いますが、出発点はTerraformそのものでした。
IBM、Alibaba、Spacelift、Gruntworkといった企業が支援に名を連ね、OpenTofuは思いのほか速いスピードで育っていきます。
2025〜2026年の地殻変動：IBM買収とCNCF入り¶
ここで、話はさらに大きく動きます。
2025年2月27日、IBMがHashiCorpの買収を完了しました。金額はおよそ64億ドル、1株あたり35ドルの現金による取得です。TerraformもVaultも、いまやIBMという巨大企業の傘の下にある——これは業界にとって小さくない出来事でした。
一方のOpenTofuも、静かに存在感を増していきます。2025年4月、OpenTofuはCNCF（Cloud Native Computing Foundation）にSandboxプロジェクトとして受け入れられました。KubernetesやPrometheusを育ててきた、あの中立的な団体の一員になったわけです。
つまり2026年の構図は、こう整理できます。
| Terraform | OpenTofu | |
|---|---|---|
| 開発の主体 | HashiCorp（IBM傘下） | コミュニティ／CNCF |
| ライセンス | BSL 1.1（商用に制限） | MPL 2.0（自由） |
| ガバナンス | 一社が主導 | 中立団体が運営 |
| 立ち位置 | 老舗のデファクト | 勢いのある挑戦者 |
片方は巨大企業に支えられた安定、もう片方は中立的なコミュニティが支える自由。どちらが良い悪いではなく、性格の違う二つの選択肢が並び立ったのが、いまという時代なのです。
このあたりのクラウドネイティブの潮流は、Kubernetesとは何かを知っておくと、より立体的に見えてきます。CNCFはまさにその中心にいる団体だからです。
OpenTofuとTerraform、実際どう違うの？¶
「歴史はわかった。でも中身はどれくらい違うの？」というのが、いちばん気になるところですよね。
正直に言うと、日々の書き方はほとんど同じです。OpenTofuはTerraformのコードから枝分かれしたので、基本的な文法（HCLという記述言語）も、コマンドの使い勝手もそっくりです。
たとえば、こんな小さな仮想マシンの定義は、どちらでも通用します。
# シンプルなサーバー1台の定義（イメージ）
resource "example_server" "web" {
name = "web-01"
size = "small"
tags = {
env = "learning"
}
}
コマンドの流れも、plan（変更内容の下見）→ apply（実際に反映）→ destroy（片付け）という三拍子は共通です。
tofu init # OpenTofuの場合。terraform init に相当
tofu plan # これから何が変わるかを事前に確認
tofu apply # 確認して実際に環境へ反映
では違いはどこにあるのか。ここ数年、OpenTofuは独自の便利機能を先んじて足してきました。
- 状態ファイルの暗号化（
stateを暗号化して保存できる。機密情報の保護に有効） - 変数の早期評価や、より柔軟な繰り返し記法
- 特定のリソースだけ除外して実行する
-excludeオプション
なかでも注目されたのが、状態ファイル（state）の暗号化です。IaCは環境の「現在の姿」をstateというファイルに記録しますが、ここには接続情報など機密が含まれがち。それを標準で暗号化できるのは、実務で地味にありがたい進化でした。
こうした「片方にしかない機能」が少しずつ増えていくと、二つの道具は名前が違うだけの双子から、少しずつ性格の異なる兄弟へと変わっていきます。とはいえ、初心者がいきなりこの細かな違いを気にする必要はありません。まずは共通の土台を身につけ、必要になったときに「そういえば、こんな違いがあったな」と思い出せれば十分です。
移行はどれくらい大変？¶
「じゃあ乗り換えは一苦労では？」と身構えるかもしれません。
もちろん規模の大きな本番環境なら、慎重な検証は必要です。プロバイダの対応状況や、独自機能への依存など、確認すべき点はあります。
ただ、出発点が同じなので、小さな構成なら驚くほどすんなり動くことも多いです。多くのチームがまず試すのは、いきなり本番を切り替えるのではなく、新しく作る検証環境や小さなプロジェクトから片方を採用してみる、というやり方です。既存の環境はそのままにしておき、うまくいったら少しずつ範囲を広げていく。急がず、影響の小さいところから確かめる。これはIaCに限らず、インフラの道具を入れ替えるときの鉄則ですね。
まずは学習用の小さな環境で tofu コマンドを叩いてみて、感触を確かめる——その一歩から始めるのが現実的です。手を動かすと、記事を何本読むよりも「あ、こういうことか」と腑に落ちる瞬間が必ず来ます。
このあたりのクラウド構築の基礎は、AWSのEC2とは何かのような、まず一台のサーバーを立てる感覚から積み上げると理解が早いです。IaCは結局、その「一台を立てる作業」をコードに置き換えているだけだからです。
これから学ぶ人は、どっちを触ればいい？¶
さて、本題の一つ。「初心者はどちらを選ぶべき？」です。
結論から言えば、入り口はどちらでも構いません。文法もコマンドもほぼ共通なので、片方を学べばもう片方の知識はそのまま活きます。学んだことが無駄になる心配は、ほとんどありません。
大切なのは、道具の名前より「IaCという考え方」を身につけることです。手作業をコードに置き換え、Gitで管理し、レビューして反映する。この一連の流れこそが、これからのインフラエンジニアの共通言語になります。
採用の現場を見ていても、「TerraformかOpenTofuか、どちらの経験がありますか」と細かく問われる場面はまだ多くありません。それよりも「IaCで環境を構築した経験はありますか」「Gitでインフラを管理したことはありますか」という、考え方のレベルで聞かれることのほうが圧倒的に多いのです。ここでも、名前より本質、というわけですね。
順番としては、いきなりIaCから入るより、まずクラウドとLinux、ネットワークの土台を固めるのがおすすめです。IaCは「何を自動化するか」がわからないと、コードを書いても意味がつかめないからです。
InfraAcademyでは、Linux・ネットワーク・クラウドの基礎から順に手を動かして学べる道筋を用意しています。IaCに進む前の土台として、まずはAWSの学習ロードマップから始めてみてください。クラウドの操作に慣れてくると、「これをコードで自動化したい」という気持ちが自然に芽生えてきます。そうなったら、IaCの学びどきです。
Terraform自体の理解を深めたい人は、Terraformの入門書の話や、実際のクラウドでのIaC事例としてAzureでのIaCの記事ものぞいてみてください。まずは全体像をつかむ、そのためのインフラ学習ロードマップもあわせてどうぞ。
まとめ¶
長くなったので、要点を振り返りましょう。
IaCは、インフラの構成をコードで書いて自動で組み立てる技術で、いまや現場の当たり前になりました。その王様だったTerraformは、2023年のライセンス変更（MPLからBSLへ）をきっかけに、コミュニティのフォークであるOpenTofuを生み出しました。
2025年にはIBMがHashiCorpを買収し、同じ年にOpenTofuはCNCF入り。2026年のいまは、「巨大企業の安定」と「中立コミュニティの自由」という、性格の違う二つの選択肢が並び立つ時代です。
そして初心者にとっての朗報は、どちらを学んでも土台の知識は共通だということ。名前選びに悩むより、まずIaCという考え方と、その手前にあるクラウド・Linux・ネットワークの基礎を固めること。それが遠回りに見えて、いちばんの近道です。
道具は移り変わります。でも「手作業を、再現できるコードに変える」という発想そのものは、これからも消えません。今日の主役がOpenTofuとTerraformだったように、数年後には別の名前が並んでいるかもしれません。それでも、身につけた土台の知識は、きっとその新しい道具の理解を助けてくれます。焦らず、土台から一歩ずつ積み上げていきましょう。
