エラーの内容
terraform plan または terraform apply を実行すると、突然止まってしまいます：
Error: Inconsistent dependency lock file
The following dependency selections recorded in the lock file are inconsistent with the current configuration:
- provider registry.terraform.io/hashicorp/aws: locked version selection 4.67.0 doesn't match the
constraint "~> 5.0" recorded in the configuration
To update the locked dependency selections to match a changed configuration, run:
terraform init -upgrade
ほとんどの場合、原因はシンプルです。誰かが versions.tf の required_providers を編集した — バージョン制約を変更した、プロバイダーを追加した、など — にもかかわらず、その後 terraform init を実行しなかったというケースです。
根本原因
Terraform は .terraform.lock.hcl ファイルを管理しています。これはレシートのようなもので、最後に terraform init を実行した時点で固定された、正確なプロバイダーバージョンと暗号化チェックサムが記録されています。
.tf ファイルがその固定されたピンと矛盾する制約を宣言した瞬間、Terraform は処理を停止します。暗黙的に別のバージョンを選択することはありません。これは意図的な動作です — 暗黙のバージョンドリフトこそが、本番環境を追跡困難な形で壊す原因になるからです。
よくある原因：
required_providersのバージョン制約を更新した（例：~> 4.0→~> 5.0）- ロックファイルにエントリが存在しない新しいプロバイダーブロックを追加した
- チームメンバーがプロバイダー制約またはロックファイル自体を変更したコミットを git から取得した
.terraform/キャッシュを削除したが、古いロックファイルを残してしまった- 異なるOS上で実行している — CI が Linux/amd64 で開発機が macOS/arm64 — ロックファイルに一方のプラットフォームのチェックサムしか含まれていない場合
修正方法
方法1：Terraform にロックファイルをアップグレードさせる（最も一般的な修正）
Terraform はエラー出力に実行すべきコマンドを表示しています：
terraform init -upgrade
これにより、現在の制約に対してすべてのプロバイダーが再解決され、.terraform.lock.hcl が最初から書き直されます。すぐにコミットしてください。
git add .terraform.lock.hcl
git commit -m "chore: update terraform provider lock file"
方法2：既存のピンに触れずに新しいプロバイダーを追加する
新しいプロバイダーを追加したばかりで、他のものをバンプするリスクを避けたい場合は、-upgrade フラグを省略してください：
terraform init
通常の terraform init は、ロックファイルに存在しないプロバイダーのみをダウンロードします。すでにピン留めされているバージョンはそのまま維持されます。変更が純粋に追加のみである場合は、こちらの方が安全な選択です。
方法3：クロスプラットフォームのチェックサム不一致を修正する
CI パイプライン（Linux/amd64）では失敗するが、MacBook（macOS/arm64）では正常に動作する場合があります。ロックファイルにはノートパソコンのアーキテクチャ用のチェックサムしかなく、CI ランナー用のものがありません。バージョンを変えずに修正するには：
terraform providers lock \
-platform=linux_amd64 \
-platform=darwin_arm64 \
-platform=darwin_amd64
結果をコミットしてください。これでロックファイルにチームが使用するすべてのプラットフォームのチェックサムが含まれ、CI が文句を言わなくなります。
方法4：ドリフトを防ぐために正確なバージョンをピン留めする
-upgrade が aws プロバイダー 5.89.0 を取得したが、まだその準備ができていない場合は、versions.tf で明示的にロックダウンしてください：
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "= 5.31.0" # exact pin, no drift
}
}
}
再度 terraform init -upgrade を実行してください。チームメンバーが自分のマシンで -upgrade を使っても、Terraform は 5.31.0 にロックされます。
方法5：ロックファイルを削除してゼロから始める（最終手段）
本当に破損したロックファイルや、ゼロからブートストラップする全く新しい環境の場合に限り使用してください：
rm .terraform.lock.hcl
terraform init
Terraform はすべてをゼロから再生成します。コミットする前に新しいピンを確認してください — 今どのバージョンを実行しているかを把握することが重要です。
修正の確認
上記のいずれかの修正後に、2つの簡単な確認を行います：
# エラーなしで完了するはずです
terraform init
# ロックファイルエラーなしでプランが表示されるはずです
terraform plan
ロックファイルに期待するプロバイダーバージョンが実際に含まれていることを確認します：
grep -A3 'provider "registry.terraform.io/hashicorp/aws"' .terraform.lock.hcl
次のような出力が表示されるはずです：
provider "registry.terraform.io/hashicorp/aws" {
version = "5.31.0"
constraints = "~> 5.0"
hashes = [
予防策
.terraform.lock.hclは必ずコミットしてください。package-lock.jsonと全く同じように扱ってください。オプションではなく、ノイズでもなく、.gitignoreに追加するものでもありません。.tfファイルに触れるすべての pull の後にterraform initを実行してください。 特にversions.tfの変更後は習慣にしてください。- 最初の CI コミットの前にプラットフォームのチェックサムを追加してください。 ローカルで
terraform providers lock -platform=linux_amd64を実行しておくことで、初日から CI ランナーが不一致に遭遇しなくなります。 - 共有環境や本番環境では
= x.y.z形式の正確なピンを使用してください。~> 5.0のような範囲制約は開発では便利ですが、チームメンバーの-upgradeが暗黙的に新しいマイナーバージョンを取得した際に問題を引き起こす可能性があります。 versions.tfの YAML ブロックでバージョン制約の構文を検証する必要がある場合は、ToolCraft の YAML ↔ JSON コンバーターが便利です — ブラウザ上で完全に動作し、アップロード不要です。
クイックリファレンス
# 新しいプロバイダーを追加した場合 → 通常の init
terraform init
# バージョン制約を更新した場合 → ロックファイルをアップグレード
terraform init -upgrade
# クロスプラットフォームの CI 不一致 → プラットフォームのチェックサムを追加
terraform providers lock -platform=linux_amd64 -platform=darwin_arm64
# 最終手段（破損したロックファイル）
rm .terraform.lock.hcl && terraform init
# 変更後は必ずロックファイルをコミット
git add .terraform.lock.hcl && git commit -m "chore: update lock file"