はじめに
CloudFormation のテンプレート（YAML）を書いていたら、文法的に正しいはずの行がエディタで赤や黄色になりました。表示に従って直すと、今度は別の行が赤くなる…の繰り返しで、迷いました。
「赤いから直す」を一回やめて、何を基準にすべきか考え直しました😅
結論から言うと、その赤の多く（全部ではない）は エディタ側の誤検知で、CloudFormation テンプレートの確認では、汎用の YAML 拡張よりも cfn-lint を優先するのが安全でした。同じところでモヤッとした人向けに、再現と仕組みと対処を残します。
※
cfn-lintは、CloudFormation テンプレート専用のチェックツールです。YAML としての形だけでなく、CloudFormation の書き方として問題がないかを見てくれます。
環境
- macOS / エディタ（VS Code 系）
- 拡張機能：
- YAML 拡張（汎用の YAML 文法＋スキーマでチェック）
-
CloudFormation Linter 拡張（裏で
cfn-lintを呼ぶ）
-
cfn-lint1.51 - 対象ファイル：
template.yaml（AWS::EC2::VPCなどを定義）
起きたこと（迷いの経緯）
順番に3回ハマりました。
① !Ref が「不明なタグ」で赤くなる
Outputs:
VpcId:
Value: !Ref StudyVpc # ← ここが赤
でもターミナルで cfn-lint template.yaml を回すと エラーなし（この記事では以後「緑」と呼びます）。
② アベイラビリティゾーンのベタ書きが黄色（警告）
AvailabilityZone: ap-northeast-1a # ← 黄色
cfn-lint でも警告が出ました。
W3010 Don't hardcode ... Availability Zone ...
「ベタ書きはやめてね」という助言です。そこで関数で書き直すと——
③ 直したら、今度はそこが赤くなる
AvailabilityZone: !Select [0, !GetAZs ""] # ← 今度はここが赤
なのに cfn-lint は緑。
この時点では「エディタが赤いなら直さないといけない」と思い込んでいました。ただ、直すたびに別の場所が赤くなって、何を基準にすればいいのか分からなくなりました。
原因：チェックしている主体が2つあって、得意分野が違う
私の環境では、テンプレートを見ている「チェッカー」が実質2ついました。
| チェッカー | 中身 | CloudFormation の関数（!Ref 等）の理解 |
|---|---|---|
| YAML 拡張 | 汎用の YAML 文法＋JSON スキーマ | 苦手（知らないと誤検知する） |
| cfn-lint | CloudFormation 専用の検査 | 得意（テンプレートの問題がなければ緑） |
エディタの赤には、さらに2種類ありました。
-
パースの段階の赤：
!Refのような CloudFormation 独自タグを YAML 拡張が知らず「不明なタグ」として弾く（①）。 -
スキーマの段階の赤：YAML 拡張の JSON スキーマでは
AvailabilityZoneは「文字列」と決められている。そこに!Select [...]（＝関数＝文字列ではない構造）を書くと「型が違う」と怒る（③）。
どちらも YAML 拡張の知識が CloudFormation に追いついていないだけで、テンプレート自体は正しい。だから cfn-lint は緑でした。
ポイント：「エディタが赤い ＝ 間違い」とは限らない。CloudFormation 専用の確認としては、まず
cfn-lintの結果を見るのが安全。
解決
1. まず「本当に間違いか」を cfn-lint で確かめる（最重要）
赤を見たら、反射で直す前にターミナルで：
cfn-lint template.yaml
# 何も出なければエラーなし（緑）＝テンプレートとしては問題なし
AWS 側のテンプレート構文チェックもできます（このコマンドだけではリソースは作りません）。
aws cloudformation validate-template --template-body file://template.yaml --region ap-northeast-1
判断フロー：
エディタが赤 → cfn-lint を実行
├─ エラーなし（緑）→ エディタ側の誤検知の可能性が高い。
│ 設定で消すか、内容を確認したうえで先に進む
└─ エラーあり → 本物のエラーの可能性が高い。直す
⚠️ ただし
cfn-lintが緑でも「必ずデプロイ成功」ではありません。権限・リージョン・クォータ・既存リソース・パラメータ値などにより、デプロイ時に失敗することはあります。確認は段階的に考えると安全です：
① cfn-lint（書き方）→ ② validate-template（AWS構文）→ ③ deploy（実際に作れるか）。緑はあくまで①②の段階を通った、という意味です。
2. !Ref 等の「不明なタグ」赤 → YAML 拡張にタグを教える
エディタ設定（settings.json）の yaml.customTags に CloudFormation のタグを登録すると、YAML 拡張が受け入れます。
"yaml.customTags": [
"!Ref scalar",
"!Sub scalar", "!Sub sequence",
"!GetAtt scalar", "!GetAtt sequence",
"!GetAZs scalar",
"!Select sequence",
"!Join sequence",
"!FindInMap sequence",
"!ImportValue scalar",
"!If sequence", "!Equals sequence", "!Not sequence", "!And sequence", "!Or sequence",
"!Base64 scalar", "!Cidr sequence"
]
3. 入れ子の短縮タグが赤い → Fn:: の長い書き方にする
!Select [0, !GetAZs ""] のように短縮タグを入れ子にすると、YAML 拡張が読みづらく赤くしがち。同じ意味の Fn:: 形式に変えると誤検知が消えます。
# 短縮形（入れ子で誤検知されやすい）
AvailabilityZone: !Select [0, !GetAZs ""]
# 長い形（誤検知されにくい・意味は同じ）
AvailabilityZone:
Fn::Select:
- 0
- Fn::GetAZs: ""
4. それでも残る「型違い」赤は、cfn-lint 緑なら割り切る
スキーマ由来の赤（②③系）は、設定で完全には消えないこともあります。その場合は cfn-lint が緑であることを確認したうえで先に進むのが現実的でした。
補足：トレードオフ
AZ は、どちらを取るかで赤/黄の出方が変わりました。
| 書き方 | エディタ | cfn-lint |
|---|---|---|
ap-northeast-1a（ベタ書き） |
きれい | ⚠️ W3010 警告 |
Fn::GetAZs で動的取得 |
赤が出ることあり（誤検知） | ✅ 緑 |
cfn-lint 的には動的取得（Fn::GetAZs）が良い書き方（移植性が上がる）。エディタの見た目より cfn-lint を優先しました。
学び
-
症状（エディタの赤）≠ 真実。テンプレートの確認は、汎用 YAML 拡張より CloudFormation 専用の
cfn-lintを優先するのが安全。 - ただし
cfn-lintも万能ではない。緑＝テンプレート上 OK であって、デプロイ時条件（権限・クォータ等）での失敗は別途ありうる。最終確認はdeploy。 - エディタの赤には 「不明なタグ（パース）」と「型違い（スキーマ）」の2種。前者は
yaml.customTags、後者は cfn-lint 緑なら割り切る。 -
!短縮形とFn::長い形は同じ意味。入れ子はFn::の方が誤検知されにくい。 - 「赤いから全部直す」より、まず
cfn-lintで確かめるのが近道。
おわりに
エディタの赤に振り回されそうになったら、一度ターミナルの cfn-lint に聞く——という習慣メモです😅 CloudFormation を書き始めて「エディタと cfn-lint で言うことが違う」と迷った人の役に立てば嬉しいです🙌