Terraform入門——インフラをコードで持つとは何か。stateという急所、plan/applyの役割、ライセンス変更とOpenTofuまで発注者目線で解説【2026年版】

「見積書に『インフラ構築(IaC)』という行があって、80万円と書いてあるんです。隣に『サーバー構築』もあるのに、これは二重計上ではないんでしょうか」——システム開発を発注する立場の方から、こうした相談をよく受けます。「Terraform 入門」で検索すると、AWSのアカウントを作ってサーバーを1台立てる手順の記事が並びます。でも、その80万円を払うと自社に何が残るのかは、どこにも書いてありません。

先に答えを書きます。Terraformとは、インフラの構成を設定ファイルに書き、その通りの状態を作って保つための道具です。発注者にとっての意味は一点に尽きます。インフラが「誰かの手で作られた現物」から「読める文書」に変わる。文書であれば、差分が見え、履歴が残り、同じものをもう一度作れて、担当者が辞めても残ります。IaC構築費とは、その文書を作る費用です。

だから、この記事の焦点は手順ではなく所有に置きます。手作業でサーバーを作ると、再現性・履歴・環境の同一性という3つが失われます。厄介なのは、作った直後には気づかない点です。請求が来るのは、環境をもう1つ増やすとき、障害から戻すとき、そして開発会社を替えるとき。5年前に作られた本番環境を誰も説明できない、という相談は珍しくありません。

本記事では、Terraformの定義とIaCという考え方、宣言的に書くという意味とplan/applyの役割、stateファイルという仕組みとその危うさ、モジュールと環境分け、CloudFormation・CDK・Pulumi・Ansibleとの役割の違いとライセンス変更およびOpenTofuという分岐、そして発注者の実務——確認、納品物、引き継ぎ——の順に解説します。クラウドそのもの、デプロイの仕組み、障害対応、マイクロサービスは既存の記事に譲ります。仕様・ライセンスはHashiCorp公式とOpenTofu公式などを2026年9月19日に直接確認した範囲だけを書きます。コードは書きません。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。当社はAWS認定資格11冠のCTOを擁し、対応技術としてDocker / Terraformを公開しています。引き継ぎの相談で私が最初に聞くのは「ソースコードはもらえますか」ではありません。「インフラの構成は、どこかに書いてありますか」です。読み終えるころには、開発会社に何を聞くべきかが決まっているはずです。

Terraformとは——インフラの構成を設定ファイルに書き、その通りの状態を作って保つ道具

Terraformとは、サーバーやネットワークといったインフラの構成を設定ファイルに書き、その通りの状態を作って保つための道具です。手順を自動で実行してくれる道具、と説明されることがありますが、それでは半分しか言い当てていません。もう半分は、インフラの姿を文書として手元に残すという働きです。

公式の定義と「プロバイダー」——AWS専用の道具ではない

HashiCorpの公式ドキュメントは、Terraformを「クラウドおよびオンプレミスのリソースを、安全かつ効率的に構築・変更・バージョン管理できるようにする Infrastructure as Code ツール」と定義しています(2026年9月19日確認)。

「クラウドおよびオンプレミス」という部分が重要です。日本語の入門記事はほぼ例外なくAWSを題材にしますが、Terraform自体はAWS専用ではありません。プロバイダーという仕組みで、操作する相手を切り替えます。公式は「HashiCorpとTerraformコミュニティは、さまざまな種類のリソースやサービスを管理するためのプロバイダーをすでに数千個書いている」と説明しており、AWS・Azure・Google Cloud・Kubernetes・GitHubなどが例として挙げられています(同日確認)。

発注者にとっての意味は、クラウドを1社に決め打ちしなくても、構成の書き方は同じ流儀で通せるということです。ただし「書き方が同じ」であって、AWSの設定をそのままAzureに移せるわけではありません。プロバイダーが違えば書く内容も変わります。ここは誤解しやすい点です。なお、クラウドそのものの仕組みと費用構造については『クラウドとは』の記事に、サーバーの役割分担については『APサーバーとは』の記事にまとめてあります。

Infrastructure as Code(IaC)——インフラを「手順」ではなく「状態」で持つ

Terraformが属する考え方が Infrastructure as Code、略してIaCです。公式はこれを「バージョン管理・再利用・共有ができる、人間が読める設定ファイルでインフラを定義すること」と説明しています(2026年9月19日確認)。

言い換えると、IaCとはインフラの正解を、人の記憶や画面操作ではなく、テキストファイルに置くという選択です。テキストファイルであることには、3つの副作用があります。

• 差分が見える。前回との違いが行単位で分かる
• 履歴が残る。誰がいつ何を変えたのかが記録される
• 複製できる。同じファイルを使えば、同じ構成をもう一度作れる

いずれもソースコードの管理では当たり前のことです。IaCは、その当たり前をインフラにも持ち込むという、ただそれだけの発想と言ってよいでしょう。

手作業でサーバーを作ると、3つのものが失われる

では、コードにしないとどうなるのか。管理画面を手で操作してサーバーを作る——いわゆる手作業の構築では、次の3つが失われます。

厄介なのは、作った直後には一つも困らないことです。困りごとは数か月から数年遅れてやってきます。しかも、そのころには作った本人が異動していたり、退職していたりする。5年前に作られた本番環境の構成を誰も説明できない、という状態は、こうして生まれます。

これを「担当者が悪い」と言っても始まりません。管理画面での操作は記録に残らないのが普通で、残そうとすればスクリーンショットを撮って手で貼るしかない。その作業を数年続けられる組織はほとんどないからです。手作業が悪いのではなく、手作業は記録を残せない。ここが本質です。

ここまでが、Terraformが何であり、なぜIaCという考え方が出てきたかという話です。ここから先は、「コードで持つ」ことの中身を分解していきます。まずは、その書き方の性格——宣言的とは何か——から見ていきます。

「宣言的に書く」とはどういうことか——手順書ではなく完成図を渡す

Terraformの説明には必ず「宣言的(declarative)」という語が出てきます。ところがこの語は、説明されないまま使われることが多い。ここを飛ばすと、この後のplanもapplyもstateも腑に落ちません。ひとことで言えば、やり方ではなく、あるべき姿を書くということです。

命令的と宣言的——同じ指示を2回出したときに何が起きるか

違いがいちばんはっきり出るのは、同じ指示を2回出したときです。

命令的の代表はシェルスクリプトです。書いた通りの順番で実行されるので、何が起きるかは分かりやすい。ただし2回流すと2回分のことが起きる。これが運用では効いてきます。「このスクリプト、もう流したんだっけ」という確認が毎回必要になるからです。

宣言的なコードにはその確認がいりません。書いてあるのは完成図なので、何回流しても結果は同じ。すでに完成図どおりなら、Terraformは「変更なし」と返します。冪等(べきとう)という言葉で説明されることがありますが、要するに「何度やっても同じところに落ち着く」という性質のことです。

plan と apply——変更を先に見せてから実行する2段構え

では、Terraformはどうやって「今の状態」と「あるべき姿」の差を埋めるのか。ここで2つのコマンドが登場します。

公式ドキュメントによれば、terraform plan は3つのことを行います(2026年9月19日確認)。

1. すでに存在するリソースの現在の状態を読み、記録が最新かどうかを確かめる
2. 現在の設定と、直前まで記録されていた状態を比較して、違いを洗い出す
3. その違いを埋めるために必要な変更案を提示する

そして公式は、続けてこう明記しています。「planコマンド単体では、提案された変更を実際に実行することはない」。plan は見積書であって、工事ではありません。実際に手を入れるのは terraform apply のほうです。

この2段構えが、Terraformのいちばん実務的な美点です。本番環境に何が起きるかを、起きる前に文章で読める。手作業の構築にはこの工程が存在しません。管理画面で「削除」を押した瞬間に、削除は終わっています。

なお、plan の結果はファイルに保存して後から適用することもできますが、公式は保存したプランファイルについて「機密性のあるデータが平文で含まれるため、機密性のある成果物として扱うべき」と注意しています(同日確認)。この「平文で含まれる」という論点は、次章のstateでもう一度出てきます。

発注者がplanの出力から読み取れること——「作る・変える・壊す」の数

planの出力は技術者向けですが、発注者が読める部分が一か所だけあります。最後の1行です。そこには作成するリソースの数、変更するリソースの数、破棄するリソースの数が並びます。

意味は単純です。

• 作成の数だけが増えている: 新しく足す作業。既存への影響は原則ない
• 変更の数がある: 既存の設定に手を入れる。無停止で済むものと、いったん止まるものがある
• 破棄の数がある: 既存のものが消える。意図した破棄かどうかを必ず確認する

とくに3番目です。設定の書き方によっては、変更のつもりが「作り直し」になることがあります。データベースが作り直しになれば、中のデータは戻ってきません。破棄の数がゼロでないplanを、内容を読まずに承認するのは失敗のもとです。

発注側からできる依頼は1つだけです。本番環境に変更を入れる前に、planの出力を見せてもらい、破棄の数がいくつかを説明してもらう。技術の知識はいりません。数字を1つ確認するだけです。アプリケーションを本番に反映する作業そのものの流れは『デプロイとは』の記事に、コードの変更履歴をどう残すかは『GitHubとは』の記事にまとめてあります。

stateファイル——Terraformの心臓部であり、いちばん壊してはいけない場所

ここが本記事の中心です。Terraformを使った現場で起きる事故は、書き方の失敗よりも、stateの扱いの失敗に集中します。そして厄介なことに、「入門」を名乗る記事の多くは「terraform.tfstate というファイルができます」と一行触れて先へ進みます。実務の急所はそこではありません。

stateは何を持っているのか——コードと実物を突き合わせる対応表

公式ドキュメントは、stateの第一の目的を「リモートのシステム上にあるオブジェクトと、設定で宣言されたリソースとの結びつきを保存すること」と説明しています(2026年9月19日確認)。あわせて、Terraformがstateを必要とする理由として4つが挙げられています。

つまりstateは、コードと現実のあいだにある対応表です。コードは「こうあってほしい姿」、クラウドの実物は「現実の姿」、stateは「このコードのこの行は、この実物のことだ」という名簿にあたります。

名簿だと考えると、危うさの正体が見えてきます。名簿が失われても、現実のサーバーは動き続ける。ただしTerraformから見ると、そのサーバーは存在しないことになるのです。

stateが消える・ずれると何が起きるか——二重作成と、取り残されたリソース

stateを失ったまま terraform apply を実行すると、Terraformは「コードに書かれたリソースが一つも作られていない」と判断します。結果として起きるのは、次の2つです。

1. 二重作成。 すでに動いているものと同じ構成が、もう一組作られる。クラウドの請求額が倍になり、どちらが本物か分からない状態が生まれる
2. 取り残されたリソース。 元からあった実物は、Terraformの管理から外れる。以後、コードを直しても反映されず、誰も消せない置物になる

本番環境でこれが起きると、復旧は「どのリソースが本物か」を人が1つずつ判定する作業になります。数十のリソースがあれば数日仕事です。stateは、消えても誰も即座には気づかず、気づいたときには手遅れに近い。ここが「壊すと復旧が難しい」と言われる理由です。

ずれ方はもう一つあります。stateはあるが、実物のほうが手で変えられている場合です。Terraformを入れた後に誰かが管理画面から設定を触ると、コード・state・実物の三者がずれます。次のplanでその差が「元に戻す変更」として出てくるため、善意の手作業が、次のapplyで打ち消されるという事故が起きます。IaCを入れた組織が最初に決めるべき運用ルールは、技術ではなくこれです。「管理画面から本番を触らない」。

どこに置き、どう共有するか——リモートバックエンドとロック

stateの置き場所には選択肢があります。公式は明確な警告を出しています。「stateのロックと安全なアクセス制御に対応していない保存先にstateを置くことは避けること。データの損失や、state内に保存された機密情報の露出につながる可能性がある」(2026年9月19日確認)。そのうえで「stateを安全に保存し、チームで共同作業するには、HCP Terraformまたはリモートバックエンドへの保存を推奨する」と続けます。

ここで出てくるロックという仕組みも押さえておく価値があります。公式は「バックエンドが対応している場合、Terraformはstateに書き込む可能性があるすべての操作でstateをロックする」と説明しています。2人が同時にapplyを実行すると、対応表が壊れるからです。ただし「すべてのバックエンドがロックに対応しているわけではない」とも書かれており、どこに置くかによって守られ方が変わります。

ロックが外れなくなったときに強制解除するコマンドもありますが、公式の注意は率直です。「このコマンドの扱いには十分に注意すること」「他の誰かがロックを保持している状態で解除すると、複数の書き手が同時に存在する状態を招きかねない」。自分のロックが自動で外れなかった場合にだけ使うもの、という位置づけです。

当社では、インフラのコードもアプリケーションのコードと同じく、Gitのプルリクエストによるレビューを経てから反映する形を標準にしています。stateを誰が触れるかという権限設計と、コードを誰が承認するかというレビュー設計は、セットで決めるものだからです。

stateには秘密情報が平文で入る——だから置き場所が契約の話になる

もう一つ、発注者が知っておくべき事実があります。公式の警告文にある「state内に保存された機密情報」という部分です。

stateはクラウド上の実物の情報をそのまま写し取るため、データベースの接続情報のような秘密が、そのまま記録されることがあります。前章で触れたplanの保存ファイルについても、公式は機密性のある成果物として扱うよう求めていました。

ここから、発注者にとっての論点が2つ生まれます。

• stateはどこに保管されているのか。 開発会社が自社のアカウント内に置いているのか、発注者名義のクラウドアカウント内に置いているのか。後者でなければ、契約終了時に中身が手元に残りません
• 誰が読めるのか。 秘密が入っている以上、閲覧できる人の範囲は限定されているべきです。委託先の全社員が読める場所に置かれていないか

この2点は技術の話に見えますが、実態は契約と権限の話です。機密情報を外部チームと扱うときの考え方は『オフショア開発のセキュリティ対策』の記事に、障害が起きたときの一次対応や保守契約の決め方は『サーバー障害の原因と対応』の記事にまとめてあります。

stateは「実行すると勝手にできる中間ファイル」ではありません。インフラの名簿であり、秘密の入った金庫でもあります。どこに置き、誰が鍵を持つかを決めないまま運用を始めるのは、要注意です。

モジュールと環境分け——同じ構成を本番と検証で作り分ける

「検証環境をもう1つ増やしたい」と伝えたら、構築に2週間と40万円と返ってきた。同じものを作るだけなのに、なぜそんなにかかるのか——この疑問に答えるのが本章です。手作業なら2週間かかる作業が、コードで持っていれば別の話になります。

モジュール——ルートモジュールと子モジュール

公式はモジュールを「Terraformがまとめて管理するリソースの集まり」と定義しています(2026年9月19日確認)。設定ファイルを置いた一番上のディレクトリが「ルートモジュール」、その中から呼び出される部品が「子モジュール」です。

部品化する利点として、公式は次の3つを挙げています。

• 標準化——インフラの作り方をそろえられる
• 再利用——似た構成を繰り返し作る場面で、素早く、予測どおりに用意できる
• 一貫性——構成を部品として共有することで、チーム間で同じパターンを保てる

発注者の言葉に置き換えると、こうなります。「ネットワークとサーバーとデータベースの一式」を部品として1度書いておけば、2つ目・3つ目の環境は、その部品に値を渡すだけで作れる。2週間が数時間になるのはこの仕組みによるものです。ただし、最初の1回は逆に時間がかかります。部品として整理する作業が乗るからです。見積書の「IaC構築費」は、多くの場合この最初の1回分です。

なお、部品として切り分ける粒度の議論は、アプリケーション側の設計論(サービスをどう分けるか)とは別の話です。後者に関心がある場合は『マイクロサービスとは』の記事を参照してください。

環境の分け方は2通り——ディレクトリで分けるか、ワークスペースで分けるか

本番・検証・開発をどう作り分けるかには、大きく2つのやり方があります。

どちらが正解というものではありません。ただし発注者として聞いておく価値があるのは、「本番と検証を取り違えない仕組みはどうなっていますか」という一点です。ワークスペースで分ける方式は手軽な反面、人が切り替えを忘れる余地があります。

そしてここでも、鍵になるのはstateです。環境を分けるとは、実質的にstateを分けることにほかなりません。前章で見たとおり、stateはコードと実物の対応表ですから、対応表が1つしかなければ環境も1つしか持てません。

すでに手作業で作ってしまった環境はどうするか——importという入口

ここまでは「これから作る」話でした。しかし現実の相談の多くは逆です。すでに手作業で作られた本番環境があり、誰もその構成を説明できない。この状態からIaCに移れるのか、という問いです。

答えは、移れます。Terraformには、すでに存在するリソースをstateに登録して管理下に置く仕組み(import)があります。実物を作り直す必要はありません。対応表に「この実物は、このコードの行のことだ」と書き足す操作だと考えると分かりやすいでしょう。

ただし、次の2点は率直にお伝えしておきます。

1. リソースの数だけ手間がかかる。 自動的に全部が取り込まれるわけではなく、どの実物をどのコードに対応させるかは人が決めます。数十のリソースがあれば、相応の工数が乗ります
2. 取り込んだ後にplanを流すと、差分が大量に出るのが普通。 手で作られた現物には、コードに書いていない設定が付いています。その差を1つずつ潰す作業が本番です

したがって、既存環境のIaC化は「1日で終わる作業」ではなく、小さなプロジェクトとして見積もるべきものです。目安の期間や金額は構成の規模で大きく変わるため、ここでは数字を置きません。

とはいえ、IaCは「これから新しく作る人のためのもの」という前提は誤りです。すでにブラックボックスになっている環境こそ、コードに起こす価値が大きい。構成が読める文書になった時点で、引き継ぎの話が資料探しから受け渡しに変わるからです。

Terraform以外の選択肢と、2023年のライセンス変更

インフラをコードで持つ道具はTerraformだけではありません。そして2023年、Terraformにはライセンスの変更という大きな出来事がありました。発注者として知っておくべきことは多くありませんが、聞かれたときに答えられないと困る種類の話です。

CloudFormation・CDK・Pulumi——同じ「作る」でも守備範囲が違う

まず、よく比較される3つを公式の定義で並べます。すべて2026年9月19日に各社の公式ドキュメントで確認しました。

読み取ってほしい軸は2つです。

1. AWS専用か、そうでないか。 CloudFormationとCDKはAWSの中の道具です。AWS以外を使わないと決まっているなら、追加のツールを増やさない理由になります
2. 宣言的な設定ファイルか、プログラミング言語か。 CDKとPulumiは、開発者が普段使う言語でインフラを書きます。条件分岐や繰り返しが自然に書ける反面、書ける自由度が高い分、読み手に言語の知識を要求します

発注者の視点で効くのは2つ目です。引き継ぎを考えたとき、「設定ファイルを読めばよい」のと「TypeScriptのプログラムを読み解く」のとでは、次のチームに求める前提が変わります。どちらが良い悪いではなく、保守する人の顔ぶれが変わる前提で選ばれているかが論点になります。

Ansibleは役割が違う——「作る」道具と「整える」道具

比較表に並べられることが多いものの、Ansibleは目的がずれます。Red Hatの公式説明では、Ansibleは「プロビジョニング、構成管理、アプリケーション展開、オーケストレーション、その他多くのITプロセスを自動化する、オープンソースのIT自動化エンジン」とされています(2026年9月19日確認)。管理対象にソフトウェアを入れる必要がなく(エージェントレス)、SSHで接続して処理を実行します。設定はプレイブックと呼ばれるYAMLのファイルに書き、「システムのあるべき状態を定義するために使う」と説明されています。

ざっくり分けると、次のようになります。

• Terraform: 箱を作る。 サーバー、ネットワーク、データベースといった「入れ物」そのものを用意する
• Ansible: 箱の中を整える。 できあがったサーバーにソフトを入れ、設定ファイルを配り、サービスを起動する

実務では併用されることもあります。「TerraformとAnsibleのどちらがよいか」という問いは、多くの場合問いの立て方が噛み合っていないと考えてよいでしょう。業務自動化ツール全般の考え方については『n8nとは』の記事も参考になります。

ライセンス変更(BSL/BUSL)——何が、いつから、どこまで

ここからが、発注者から実際によく聞かれる話です。先に結論を書きます。自社のシステムを作って運用するために使う分には、制限はかかりません。

事実を整理します。HashiCorpは2023年8月10日、公式ブログで、今後リリースする自社製品のライセンスを Mozilla Public License v2.0(MPL 2.0)から Business Source License(BSL / BUSL)v1.1 へ変更すると発表しました。同発表では「HashiCorpのAPI、SDK、およびその他ほぼすべてのライブラリはMPL 2.0のままとする」とも述べられています(2026年9月19日確認)。

現在のTerraformのリポジトリに置かれているライセンス本文を直接確認すると、次のようになっています(同日確認)。

ライセンサーがIBMになっているのは、IBMが2025年2月27日にHashiCorpの買収を完了したためです(IBMの公式発表・同日確認)。

読み解きは3点です。第一に、制限がかかるのは「Terraformそのものを商品として第三者に提供する事業者」であって、自社のインフラを構築・運用する一般の利用者ではありません。第二に、1.5.x以前のバージョンはMPL 2.0のままです。第三に、4年経てばMPL 2.0に戻る設計になっています。

なお、BSLの条文解釈そのものは法律の領域です。自社が第三者にサービスとして提供する側に当たる可能性がある場合は、書かれている内容を持って法務に確認してください。ここで断定的な助言を書くことはしません。

OpenTofu——Linux Foundationの下にあるフォークと、有料版の料金

このライセンス変更を受けて生まれたのが OpenTofu です。OpenTofuの公式FAQは、HashiCorpがTerraformのライセンスをMPLからBUSLへ切り替えたことへの対応としてフォークが作られたこと、そしてこのプロジェクトを Linux Foundation に委ねることでリスクを最小化していると説明しています(2026年9月19日確認)。Linux Foundationは2024年1月に、OpenTofuが正式版(GA)に到達したことを発表しています。

互換性について、OpenTofu公式FAQは「Terraform 1.5.x までに作られた既存のstateファイルで動作する」としています。また、既存のTerraformプロバイダーは動作するものの、レジストリ(取得元)は別のものを使うとも明記されています。

有料版の料金についても触れておきます。HashiCorpの公式料金ページで確認できた範囲では、HCP Terraformは管理対象のリソース数に応じた課金で、Essentialsが1リソースあたり月0.10USDから、Standardが0.47USDから、Premiumが0.99USDから、自社運用のEnterpriseは個別見積もりとなっています(2026年9月19日確認。1USD=150円換算目安)。リソース数が費用に直結する体系である点は、構成を決めるときの判断材料になります。なお、これ以外の細かな条件や無料枠の有無については公式ページで確認できなかったため、ここには書きません。

まとめると、道具の選定は技術の優劣だけでは決まりません。AWSしか使わないのか、どの言語なら保守できる人がいるのか、そしてライセンスの前提に自社が当てはまるのか。選定理由を説明できる開発会社かどうかのほうが、どれを選んだかより重要です。

発注者の実務——開発会社がIaCを使っているか、コードとstateは納品物か

ここまでの話を、発注の現場で使える形に落とします。技術を評価する必要はありません。確認すべきことは、コードがあるか、誰のものか、渡してもらえるかの3つに集約できます。

「インフラはコードで管理していますか」と聞く意味——確認する5点

この質問の目的は、開発会社の技術力を測ることではありません。将来、その会社と別れるときに何が手元に残るかを先に知っておくことです。

とくに3番です。クラウドアカウントが開発会社の名義だと、コードをもらっても環境は手元に残りません。アカウントの名義は、IaC以前の土台にあたります。

もう一つ、逆の注意も書いておきます。小規模な構成に無理にIaCを入れると、割に合わないことがあります。サーバー1台とデータベース1つで、今後数年ほぼ触らないと決まっている案件で、部品化まで作り込むのは過剰です。この場合に確認すべきは「コードがあるか」ではなく「構成の記録が実物と合っているか」になります。要件を数値で決める考え方は『非機能要件とは』の記事にまとめてあります。

納品物一覧に何を書くか——コード、state、そしてアカウント

契約書や発注書の納品物一覧に、インフラの項目が1行もない。これは珍しいことではありません。アプリケーションのソースコードは書かれていても、インフラは「構築作業」としてしか現れないためです。

書き足すのは3行で足ります。

1. インフラ構成コード一式(保管場所と、引き渡しの方法を明記する)
2. stateの引き渡し、または発注者名義の保管先への移管(どちらかを選ぶ)
3. クラウドアカウントおよび管理者権限の所在(誰の名義で、誰が管理者か)

あわせて決めておくとよいのが、秘密情報の扱いです。前章までに見たとおり、stateには接続情報のような秘密が入ることがあります。引き渡しの方法を「メールに添付」で済ませるわけにはいきません。

ソースコードや成果物の権利が誰に帰属するかという論点は『システム開発の著作権・ソースコードは誰のもの』の記事に、契約書のどの条項で決めるかは『システム開発の業務委託契約書』の記事にまとめてあります。

引き継ぎのとき、IaCがあると何が楽になるか——ある場合とない場合の対比

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。開発会社の乗り換えや引き継ぎの相談で、最初に聞くのは「ソースコードはもらえますか」ではありません。「インフラの構成は、どこかに書いてありますか」です。アプリケーションのコードはGitにあることがほとんどですが、インフラは人の頭の中にしか残っていないことが珍しくないためです。

差が出るのは移行そのものより、移行の見積もりを取る段階です。現状が説明できないと、受ける側はリスク分を上乗せせざるを得ません。それが実情です。継続的な改修を誰が持つかという観点は『システム改修・開発保守の外注』の記事に、乗り換えの進め方そのものは『開発会社の乗り換えと引き継ぎ』の記事にまとめてあります。

当社の担い方——AWS認定11冠の体制と、向かない案件

当社はホーチミンを拠点に、日本人PMまたはブリッジSEをフロントに置いたラボ型で開発体制をご提供しています。2,000名以上のIT人財データベースから直接アサインするため、協力会社や紹介経由の仲介マージンは発生しません。対応技術として AWS / Azure / Google Cloud、Docker / Terraform、CI/CD を公開しており、AWS認定資格11冠のCTOがクラウド設計を担当します。品質管理は3点——日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェック——を標準としています。インフラのコードもアプリケーションと同じ流れでレビューする形です。

体制はパターンA(日本人PM/ブリッジSE+エンジニア・推奨)とパターンB(エンジニアのみ)の2通り。1名から、最短2週間で開始でき、増員は約1週間、縮小・交代は1か月単位です。最小構成は日本人PMフロント+2〜3人月で月額約80万円から。公開単価は実務3年目安で1,500USD(約22.5万円)、5年で2,000USD、10年・ブリッジSEで3,000USD(1USD=150円換算目安)。契約・支払いは日本国内法人・日本法準拠で、海外送金は不要です。時差は2時間、ベトナムの祝日は2026年で年12日(労働法112条の法定は11日で、2026年からベトナム文化の日が加わります)、2026年のテトは2月14日から22日です。

インフラをコードで持つことの効き目は、体制が続くかどうかと直結します。専属チームが同じコードを触り続ける形であれば、構成の変更履歴がそのまま引き継ぎ資料になります。逆に、案件ごとに担当が入れ替わる形では、コードがあっても「誰も読んだことがないコード」になりかねません。

ただし、向かない案件もあります。サーバー1台で完結し、今後数年ほぼ触らないと決まっている構成に、部品化された設計を作り込むのは過剰です。また、すでに手作業で作られた大規模な本番環境を、稼働を止めずに一気にコード化するという進め方も勧めません。取り込みの過程で差分が大量に出るためで、範囲を区切って少しずつ移すほうが安全です。一度にやろうとするのは失敗のもとです。

【FAQ】Terraformとインフラのコード管理に関するよくある質問

最後に、相談の場で実際によく出る5つの質問に短く答えます。本文で詳しく扱った論点は、該当する章を参照してください。

Q1. Terraformを一言でいうと何ですか

インフラの構成を設定ファイルに書き、その通りの状態を作って保つ道具です。公式の定義は「クラウドおよびオンプレミスのリソースを、安全かつ効率的に構築・変更・バージョン管理できるようにする Infrastructure as Code ツール」(2026年9月19日確認)。発注者にとっての意味は、インフラが「誰かが作った現物」から「読める文書」に変わることです。

Q2. IaCの導入には、どれくらい時間と費用がかかりますか

構成の規模で大きく変わるため、一般的な目安の数字は出せません。確かなのは最初の1回に最も時間がかかり、2回目以降が劇的に短くなるという形になることです。見積書の「IaC構築費」は、その最初の1回分だと考えてください。判断材料としては、「今後この環境を複製する予定があるか」「構成を知っている人が辞める可能性があるか」の2つが効きます。

Q3. stateファイルを消してしまったらどうなりますか

コードと実物の対応表が失われるため、Terraformは実物を「存在しないもの」として扱います。その状態で実行すると、同じ構成がもう一組作られ(二重作成)、元の実物は管理から外れて誰も消せない置物になります。復旧は、どのリソースが本物かを人が1つずつ判定する作業です。だからこそ、公式もロックとアクセス制御に対応した保管先を使うよう警告しています。詳しくは本文のstateの章を参照してください。

Q4. TerraformとOpenTofuのどちらを選ぶべきですか

自社でインフラを構築・運用する目的であれば、ライセンス上の制限はどちらにもかかりません(Terraformの追加使用許諾は本番利用を認めており、除外されるのは有償版と競合する形で第三者に提供する場合です)。したがって選定基準は、保守する人がどちらに慣れているかになります。OpenTofuはLinux Foundationの下で開発され、Terraform 1.5.xまでに作られたstateで動作すると公式FAQに明記されています。開発会社が選んだ理由を説明できるかどうかを確認してください。

Q5. 小規模なシステムでもIaCは必要ですか

必須ではありません。サーバー1台で完結し、今後数年ほぼ触らないと決まっている構成なら、部品化まで作り込むのは過剰です。その場合に確認すべきは、コードの有無より構成の記録が実物と合っているか、そしてクラウドアカウントが自社名義になっているかの2点。判断の分かれ目は、環境を複製する予定があるかどうかと、構成を知る人が入れ替わる可能性があるかどうか。

まとめ: インフラをコードで持つと、現物が文書になる——代わりにstateという責任が生まれる

Terraformとは、インフラの構成を設定ファイルに書き、その通りの状態を作って保つための道具です。公式は「クラウドおよびオンプレミスのリソースを、安全かつ効率的に構築・変更・バージョン管理できるようにする Infrastructure as Code ツール」と定義しています。書き方は宣言的——手順ではなく、あるべき姿を書く——なので、同じコードを何度流しても結果は同じところに落ち着きます。planは変更案を見せるだけで実行せず、applyが実行する。この2段構えのおかげで、本番に何が起きるかを起きる前に文章で読めます。発注側が見るべきは技術の中身ではなく、planの最後に出る「作る・変える・壊す」の3つの数、とくに破棄の数です。

一方で、コードで持つと新しい責任が1つ増えます。stateファイルです。これはコードに書いたリソースとクラウド上の実物を結びつける対応表で、失われるとTerraformは実物を知らないものとして扱い、同じ構成をもう一組作ってしまいます。公式も「ロックと安全なアクセス制御に対応していない保存先にstateを置くことは避けること——データ損失や機密情報の露出につながる」と警告しています。stateには接続情報のような秘密が平文で入ることがあり、置き場所と閲覧権限は技術ではなく契約の話になります。なお、ライセンスはTerraform 1.6.0以降がBUSL 1.1(ライセンサーはIBM、公開から4年でMPL 2.0へ)ですが、自社のインフラを構築・運用する分には制限はかかりません。Linux Foundationの下にOpenTofuという選択肢もあります。

だからこそ、インフラを含む開発を外部チームに任せるときに発注側が握るのは、この3つです。コードがあるか(インフラの構成はコードで管理されているか)、誰のものか(stateの保管場所と、クラウドアカウントの名義)、渡してもらえるか(契約終了時の引き渡しが納品物一覧に書かれているか)。技術ではなく取り決めの話なので、非エンジニアでも判断できます。乗り換えと引き継ぎの進め方そのものは開発会社の乗り換えと引き継ぎに、専属チームを月額で持つ契約形態はラボ型開発とはにまとめてあります。当社はホーチミンを拠点に、AWS認定資格11冠のCTOを擁し、対応技術としてDocker / Terraformを公開しています。日本人PMをフロントに置いたラボ型で、同じチームが構成を触り続ける形をとっているため、変更履歴がそのまま引き継ぎ資料になります。1名から、最短2週間で開始でき、最小構成は日本人PMフロント+2〜3人月で月額約80万円から。契約・支払いは日本国内法人・日本法準拠で、海外送金は不要です。ただし、サーバー1台で完結し今後数年ほぼ触らないと決まっている構成なら、作り込んだIaCは過剰です。現在の体制と要件をお聞かせいただければ、その判断を含めて概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。