Terraform

Terraformで始めるコスト見積もり実務: Infracost活用の型

2026-04-19
NicheeLab編集部

コードに触れず"雰囲気価格"で判断してしまうと、リリース直前に驚くほどの差異が出ます。Terraformの計画出力を単一の真実源として扱い、Infracostで差分まで自動評価するのが安全な型です。

本稿は、Terraformの安定した公式動作(plan/showのワークフロー)に立脚し、Infracostを実務・試験の双方で迷わず使えるように整理しました。

Terraform計画とコスト見積もりの流れ

コスト見積もりは、HCLの静的読解ではなく、変数・モジュール・データソースが具体値に解決された計画結果を基点に行うと精度が上がります。Terraformでは terraform plan で計画を生成し、terraform show -json で機械可読なJSONに変換できます。このJSONをInfracostに渡すのが実務での定番です。

計画を真実源にする利点は、条件分岐(count/for_each)やデフォルト値、プロバイダの解決結果が反映される点です。apply前に差分を把握し、PRでレビューできるため、コストの逸脱を早期に検知できます。

  • planを作る: terraform plan -out plan.out
  • JSON化: terraform show -json plan.out > plan.json
  • 見積もり: infracost breakdown --path plan.json
  • 差分: infracost diff(ベースと比較してPRで可視化)
観点terraform planterraform applyInfracost
入力HCL + 変数 + 状態(参照のみ)計画 + 外部API実行plan.json またはHCL/状態
目的変更案の算出実変更の適用コストの算出/比較
出力plan.out / plan.jsonリソースの実変更とstate更新コスト明細・差分(JSON/表/PRコメント)
試験要点未知値はplanで具体化されるコストはapply不要で見積可plan.jsonを渡すと精度向上

PlanからInfracostまでのデータフロー

Dev
  |
  v
terraform plan  ---->  plan.out  -- terraform show -json -->  plan.json
                                                          |
                                                          v
                                                  Infracost breakdown
                                                          |
                                                          v
                                                    コスト明細/PRコメント

最小手順(ローカル)

terraform init
terraform plan -out plan.out
terraform show -json plan.out > plan.json
INFRACOST_API_KEY=xxxxxxxx infracost breakdown --path plan.json

Infracost導入とTerraformの連携

InfracostはCLIで、クラウド各社の公開価格表を参照して見積もりを計算します。Terraformプロジェクト直下のHCLを直接読むことも可能ですが、精度と再現性の観点ではplan.json経由を推奨します。

組み込みは単純です。APIキーを環境変数に設定し、plan.jsonを指定して breakdown を実行します。CIでは既存のplanアーティファクトを再利用し、PRにコメントする運用が一般的です。

  • 前提: Terraform CLIが動作、クラウドプロバイダの認証はplanが通る状態
  • APIキー設定: 環境変数 INFRACOST_API_KEY をエクスポート
  • HCL直読みより plan.json を推奨(条件分岐・モジュール展開が反映される)
  • 複数ディレクトリ/モジュールは infracost.yml で定義可能

導入スニペット

# APIキー設定(例)
export INFRACOST_API_KEY=xxxxxxxxxxxxxxxx

# 計画の作成とJSON化
terraform plan -out plan.out
terraform show -json plan.out > plan.json

# 見積もり
infracost breakdown --path plan.json --format table

# 複数パスをまとめる infracost.yml(任意)
# version: 0.1
# projects:
#   - path: ./app
#   - path: ./infra/network

見積もり精度を上げる実務のコツ

使用量ベースの料金(ストレージGB月、リクエスト数、データ転送など)はHCLだけでは確定しません。Infracostは usage ファイルで現実的な利用量を与えると精度が大幅に向上します。

変数は var-file で本番相当を渡し、plan時点でサイズや台数が確定するようにします。count/for_eachの条件やデフォルト値が曖昧だと未知のまま推定がぶれます。

  • usageファイルを用意(infracost-usage.yml)し、主要サービスの利用量を明示
  • var-fileでサイズ・台数を固定。ワークスペース/環境ごとに別ファイル
  • リージョン/クラス/ディスク種別など価格に影響する引数はlocalsで集約し一元管理
  • dataソースの解決結果に依存するパラメータはplanで解決されるよう順序を整える

usageファイルとvar-fileの例

# infracost-usage.yml(例)
version: 0.1
resource_usage:
  aws_s3_bucket.my_logs:
    monthly_tier_1_requests: 2000000
    storage_gb: 500
  aws_lb.app:
    new_connections: 10000000
    active_connections: 2000

# terraform.tfvars(本番)
instance_type = "t3.large"
volume_size   = 200
replicas      = 3

CI/CDへの組み込みとゲーティング

PRでコスト差分を可視化し、しきい値を超える変更をゲートするのが実運用の定石です。ベースブランチの見積もり結果を保存し、変更ブランチと比較します。

公式アクション(GitHub)や汎用シェルで構成できます。失敗条件は組織ポリシーに合わせ、金額や増加率で判定します。

  • ベースの見積もりを保存(例: .infracost-base.json)
  • 変更ブランチの見積もりを生成し diff で比較
  • 増加が一定割合/金額を超えたらジョブを失敗にする
  • PRに表形式でコメントし、レビュアが即時判断できるようにする

GitHub Actions例(要点のみ)

name: Cost Diff
on: pull_request
jobs:
  infracost:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Terraform Plan
        run: |
          terraform init
          terraform plan -out plan.out
          terraform show -json plan.out > plan.json
      - name: Setup Infracost
        uses: infracost/actions/setup@v2
      - name: Generate Base (main)
        if: github.event.pull_request.base.ref == 'main'
        run: |
          infracost breakdown --path plan.json --format json --out-file .infracost-base.json
      - name: Cost Diff
        env:
          INFRACOST_API_KEY: ${{ secrets.INFRACOST_API_KEY }}
        run: |
          infracost breakdown --path plan.json --format json --out-file current.json
          infracost diff --path current.json --compare-to .infracost-base.json --format table
          # 例: しきい値チェック(単純化)
          infracost diff --path current.json --compare-to .infracost-base.json --format json --out-file diff.json
          python .github/scripts/fail_on_threshold.py diff.json 20 100 # 20%または100通貨単位超で失敗

試験対策で押さえるポイント(Pro向け)

Terraformの試験では、コスト見積もりそのものよりも、見積もりの前提となる計画の正確性と再現性が問われます。planを真実源とし、未知値を減らし、変数・条件分岐を明示化できるかが鍵です。

count/for_each、lifecycle、変数の優先順位、plan出力の解釈(create/replace/destroyの区別)といった基礎が、コスト差分の読み取り精度に直結します。

  • plan.jsonを生成してから外部ツールへ渡す流れを説明できること
  • unknown値(計画時に未確定)を減らすためのvar-file/localsの設計
  • count/for_eachの展開結果が台数に影響=コストに直結
  • lifecycle.prevent_destroy等はコスト見積もりでは適用外だが、計画の結果には影響する
  • dataソースは直接課金対象ではないが、結果がサイズ等に影響しうる点を理解

plan.jsonを出すコマンド(確認)

terraform plan -out plan.out
terraform show -json plan.out > plan.json
# これをInfracostに渡す
infracost breakdown --path plan.json

代表的な落とし穴と対処

複数ワークスペースや環境ごとに変数が変わる場合、意図しないデフォルトでplanしてしまうと見積もりがずれます。CIでも本番相当のvar-fileを必ず指定します。

プロバイダエイリアスやモジュールパスの解決誤りは、計画自体の失敗や未知値の増加を招きます。providersブロックやrequired_providersの整合を確認し、graph/consoleで依存関係を点検します。

  • workspace切替の失念: terraform workspace select を明示
  • var-file未指定: -var-file=prod.tfvars を徹底
  • リージョン不一致: providerのregion/zone指定をlocalsで集中管理
  • データ取得順序: data → resourceの依存を明示(depends_onなど)
  • 価格表にない構成: 同等クラスへマップされる場合があるため注釈を残す

診断のためのコマンド

terraform providers
terraform graph | dot -Tsvg > graph.svg
terraform console
# planの検証
terraform plan -out plan.out && terraform show -json plan.out | jq '.planned_values.root_module.resources[] | .type, .name'

サンプル: マルチ環境の見積もり差分

同一モジュールでdev/prodのサイズが異なる典型例です。両環境のplan.jsonを作り、Infracostで差分を出すと増減の根拠をPRで共有できます。

単一のHCLに対してvar-fileを切り替えるだけで再現できるため、レビューの標準手順として定着させやすい運用です。

  • dev/prodでvar-fileを分け、plan.jsonを2つ生成
  • 各planから見積もりJSONを作成し、diffで比較
  • PRに差分をコメント、しきい値でゲート

サンプル構成と比較実行

# main.tf(抜粋)
variable "instance_type" {}
variable "replicas" { type = number }
resource "aws_instance" "app" {
  count         = var.replicas
  ami           = data.aws_ami.ubuntu.id
  instance_type = var.instance_type
}

data "aws_ami" "ubuntu" {
  most_recent = true
  owners      = ["099720109477"]
  filter { name = "name" values = ["ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-*"] }
}

# dev.tfvars
instance_type = "t3.micro"
replicas      = 1

# prod.tfvars
instance_type = "t3.large"
replicas      = 3

# 実行
terraform init
terraform plan -var-file=dev.tfvars -out dev.out && terraform show -json dev.out > dev.json
terraform plan -var-file=prod.tfvars -out prod.out && terraform show -json prod.out > prod.json

# 見積作成
infracost breakdown --path dev.json --format json --out-file dev.cost.json
infracost breakdown --path prod.json --format json --out-file prod.cost.json

# 差分
infracost diff --path prod.cost.json --compare-to dev.cost.json --format table

問題で確認

Pro

問題 1

チームはPR時点で正確なコスト見積もりと差分をレビューしたい。モジュールや変数の解決結果を反映した見積もりを得る、最も再現性の高い手順はどれか。

  1. terraform plan -out plan.out の後、terraform show -json plan.out > plan.json を作成し、infracost breakdown --path plan.json に infracost-usage.yml を併用する
  2. infracost をソースディレクトリに直接向け、apply 後の state から見積もる
  3. terraform refresh-only を実行し、infracost に state ファイルだけを渡す
  4. terraform apply を実行してから、infracost で差分を計算する

正解: A

計画をJSON化したplan.jsonを真実源にすると、モジュール展開や変数の具体値が反映され、apply不要で正確かつ再現性のある見積もりが可能。usageファイルで使用量を補足すればさらに精度が上がる。state単独やapply前提は要件に合致しない。

よくある質問

HCLディレクトリを直接Infracostに渡すのと、plan.jsonを渡すのは何が違いますか?

HCL直読みは静的解析のため、条件分岐やデータソース解決の結果が反映されにくく、未知値が増えがちです。plan.jsonはTerraformが解決した結果を含むため、見積もりの再現性と精度が上がります。

使用量に依存する料金はどう指定すればよいですか?

infracost-usage.yml などのusageファイルで、ストレージ容量やリクエスト数など現実的な値を与えます。これにより"使用量次第"の項目が具体化され、過小・過大見積もりを避けられます。

applyしなくても正確な見積もりは可能ですか?

はい。terraform plan と terraform show -json で得たplan.jsonを基にInfracostで見積もれば、apply不要で差分まで確認できます。applyはコスト見積もりの前提ではありません。

この記事で学んだ内容を問題で確認しましょう

16,000問以上の問題で実力チェック

無料で問題を解いてみる
この記事の著者

NicheeLab編集部

データエンジニアリング・クラウド資格の専門家。Databricks・Snowflake等の認定資格を保有し、実務経験に基づいた問題作成・解説を行っています。NicheeLab運営。


関連記事
Terraform

Terraform HCL 構文の基礎:Block / Attribute / Expression を正しく使い分ける

Terraform Associate で頻出の HCL 構文を、ブロック・属性・式の3視点で整理。実務で迷いがちな書き...

Terraform

Terraform Authoring & Ops Pro: 上位資格の範囲と対策

上位レベルを想定したTerraformの設計・運用ドメインを整理し、実務で通用する対策を提示。モジュール設計、ステート運...

Terraform

Terraform Providers の基本: プラグイン型アーキテクチャを正しく使いこなす

Associate レベルで押さえるべき Provider の基礎、インストール、バージョニング、認証、エイリアス運用を...

Terraform

Terraform Resourceブロック徹底ガイド: 最小単位のリソース定義

Associateレベルで押さえるべきResourceブロックの構造、依存関係、メタ引数、ライフサイクル制御を実務目線で...

Terraform

Terraform Data Source徹底理解:既存リソースの参照で壊さず足す

Terraform Associate向けに、Data Sourceを用いた既存リソース参照の基本、選択基準、評価順序、...

Terraformの記事一覧 (102件)
© 2026 NicheeLab All rights reserved.