TerraformのpreconditionはREPLACE_AT_BRINGUPのplaceholderを検知できない

結論

Cloud Runモジュールの precondition は var.image != "" で非空かどうかしか見ていないため、ビルド前に仮置きした REPLACE_AT_BRINGUP のようなplaceholderのimage tagは空文字ではない以上 terraform plan を素通りする。 実際の失敗は plan では起きず、Cloud Run JobやリビジョンがそのタグでイメージをPullしようとする実行時まで先送りされる。この違いを、plan が置換漏れを止めてくれるという誤った前提で書かれていた本番Terraformのコードコメントを、正しい前提に書き直したコミットから読む。

症状

本番環境のCloud Run定義 infrastructure/terraform/envs/prod/main.tf には、もともと次のようなコメントが置かれていた。

# infrastructure/terraform/envs/prod/main.tf:18-19（修正前, sha: cc5385d2）
# web イメージの置換漏れ（REPLACE_AT_BRINGUP のまま）は、下の cloud_run モジュールの
# precondition（image != ""）が plan 時に検知して fail-fast する。

このコメントは「image 変数にビルド前の仮の値を置いたまま apply しようとしても、precondition が plan の段階で止めてくれる」という前提を書いている。しかし image 変数にビルド前の仮置きとして REPLACE_AT_BRINGUP のような文字列を入れた場合、この文字列は空文字ではない。

原因

実際に評価される precondition の中身は、infrastructure/terraform/modules/cloud_run/main.tf にこう書かれている。

# infrastructure/terraform/modules/cloud_run/main.tf:395-398（sha: bf9bc4d7、ロジックは修正前後で不変）
precondition {
  condition     = !var.enabled || var.image != ""
  error_message = "enabled = true のとき image は必須です（build/push 済の web イメージ、apps/web/Dockerfile）。"
}

この条件式は「enabled が true のとき image が空文字でないこと」しか検査していない。REPLACE_AT_BRINGUP という文字列は長さを持つ非空の文字列なので、この条件は true と評価され、precondition は通過する。precondition は変数の型や非空性のような「plan時点で静的にわかること」しか検査できず、「その文字列が実在するイメージのURLかどうか」はクラウド側にリクエストを送らない限り判定できない。plan はローカルでの計画生成であり、この時点でCloud Run側へのイメージ取得（pull）は発生しない。

つまり置換漏れを本当に検知できる場面は、terraform apply によってCloud Run JobやリビジョンがそのタグでイメージをPullしようとする実行時であり、plan の precondition では原理的に検知できない。

直す

このコミット（bf9bc4d7、2026-10-09、author: cometa-kaito）が変更したのはTerraformのロジックではなく、envs/prod/main.tf 側のコメントだけだった。precondition の条件式自体は修正前後で一文字も変わっていない。

# infrastructure/terraform/envs/prod/main.tf:18-19（修正後, sha: bf9bc4d7）
# web イメージの置換漏れ（REPLACE_AT_BRINGUP のまま）は、下の cloud_run モジュールの
# precondition（image != ""）では止まらない（空文字チェックのみ・plan 時点でイメージの
# 実在は検証されない）。実際に失敗するのは Job/リビジョンがそのタグで image を取得する実行時。

同じコミットで、同ファイル内の別の箇所（167行目付近）にあった同種の記述も合わせて訂正されている。直した内容は「precondition が守ってくれる範囲」の認識そのものであり、置換漏れを plan の段階で止めるための新しい検査は、このコミットには追加されていない。

再発防止

このコミットの記録には、置換漏れをplan時点で機械的に止めるための新しい検査やCIガードは含まれていない。書けるのは、なぜ「precondition が守ってくれる」という誤解がコメントとして残っていたかという構造だけだ。

precondition という名前と、error_message に書かれた日本語の説明文（「image は必須です」）は、読み手に「ここでイメージの正当性が検証されている」という安心感を与えやすい。しかし条件式そのものは != "" という最小限の非空チェックに過ぎず、変数名が image であることや、エラーメッセージが具体的であることは、検査の範囲の広さとは無関係だ。precondition ブロックを読むときは、周辺のコメントや変数名から検査範囲を推測するのではなく、condition に書かれた式そのものが何を比較しているかを直接確認する必要がある。