Terraform State Lockエラーは焦ってforce-unlockする前に、まずチームへの状況確認と待機を最優先し、「状況確認→安全な解除→refresh-onlyでDrift修正」の3ステップで対処しましょう。
Terraform実行時に「Error acquiring the state lock」が出て作業が止まった？この記事では、State Lockエラーの4つの原因と安全な解除手順、再発防止策まで現場目線で解説します。
Terraform State Lockエラーとは？
TerraformのState Lockは、複数人やCI/CDプロセスが同時に.tfstateファイルを書き換えてインフラ情報が競合・破損することを防ぐ正常かつ必須の保護メカニズムです。
terraform planコマンドでも内部でRefreshフェーズが走りロックが取得されるため、applyだけでなくplanでもロック競合は発生します。
ロックの実装方式はバックエンドごとに異なります。
| バックエンド | ロック実装方式 |
|---|---|
| AWS S3 + DynamoDB | DynamoDBで排他制御（v1.10以降はS3単体のConditional Writesも対応） |
| GCS | 組み込みオブジェクトロック |
| Azure Blob | Blob Leases機能 |
| ローカル | ファイルシステム上のロックファイル |
State Lockが残る4つの根本原因
ネットワーク切断やCI/CDジョブのタイムアウトでTerraformが異常終了するとクリーンアップが行われず「Orphaned Lock」が残ります。最も多い原因です。
Terragrunt経由でCtrl+C（SIGINT）した際、Terraform本体は終了してもラッパー側のシグナル処理問題でロックが残るケースがあります。
複数のプルリクエストに対してterraform planが同時実行されると、後発プロセスがロック取得に失敗します。
DynamoDBのDeleteItem権限不足でロック解放に失敗するケースや、JFrog Artifactoryでlocked: trueがスタックする事例もあります。
【ステップ別】安全な解除手順
重要：エラー発生直後のforce-unlockは危険です。他メンバーのプロセス実行中に解除するとStateファイルの完全破損（スプリットブレイン）を招きます。
ステップ1：状況確認と待機
Slack等でチームメンバーにTerraform実行状況を確認しましょう。不明な場合は30分〜1時間待機してから再試行するのが最も安全です。
ステップ2：force-unlockの実行
残留ロック（Orphaned Lock）であることが確定したら、エラーメッセージに表示されるLock IDで解除します。
terraform force-unlock a1b2c3d4-e5f6-7890-abcd-ef1234567890Lock IDの役割：この文字列は暗号論的ノンス（Nonce）として機能し、誤って別環境のロックを解除することを防ぐ安全装置です。force-unlock自体はインフラを変更しません。
CI/CDで対話プロンプトをスキップするには-forceオプションを付与します。
terraform force-unlock -force a1b2c3d4-e5f6-7890-abcd-ef1234567890ステップ3：物理的なロック削除（最終手段）
CLIが機能しない場合はバックエンドに直接介入します。
| 環境 | 対処法 |
|---|---|
| S3 + DynamoDB | aws dynamodb delete-itemでレコード削除 |
| S3ネイティブ（v1.10+） | .tflockファイルを手動削除 |
| ローカル | ロックファイル削除 or プロセスをkill |
絶対に避けるべきアンチパターン：terraform apply -lock=falseでロック機構をバイパスするのは厳禁です。同時書き込みによるState破損リスクが極めて高く、公式でも非推奨です。
ロック解除後：Drift（状態の乖離）を修正する
強制終了時、AWSリソースには変更が適用済みなのにStateに未記録の「Drift」が発生している可能性があります。この状態で次のapplyを実行すると予期せぬリソース削除が起こり得ます。
terraform apply -refresh-onlyこのコマンドはインフラに変更を加えず、実態に合わせてStateを安全に同期します。特定リソースのみ対象にする場合は-targetオプションを併用しましょう。
再発防止のベストプラクティス
3つの柱で再発防止：S3バージョニング、CI/CDの直列化、Stateファイルの分割を組み合わせましょう。
S3バージョニングの有効化：State破損時にaws s3api list-object-versionsで正常な状態にロールバック可能です。
CI/CDでの直列化：ローカルPCからのapply実行を禁止しGitHub Actions等に統一。ジョブを直列化して競合を防ぎます。
Stateファイルの分割：環境（Dev/Prod）やサービスごとにStateを分割し、障害時の影響範囲（Blast Radius）を極小化しましょう。
まとめ
「Error acquiring the state lock」はインフラを守るための保護機能です。パニックにならず、「1. 状況確認と待機」→「2. force-unlockで安全に解除」→「3. refresh-onlyでDrift修正」の3ステップで対処しましょう。
S3バージョニング・CI/CD直列化・State分割の予防策で再発リスクも大幅に下げられます。
コメント