cfn-lintとは？CloudFormationテンプレート検証の導入・設定・CI組み込み【v1.57対応】

cfn-lintは、AWS CloudFormationのテンプレートをデプロイせずに検証するAWS公式の静的解析ツールです。プロパティ名の打ち間違い、列挙値の誤り、上限を超えた数値、存在しないリソースへの参照といった欠陥を、スタック作成の前にコマンド1本で洗い出せます。本記事は2026-10-06公開のcfn-lint 1.57.2をmacOS上のPython 3.13.14に導入し、実際に流した出力をそのまま載せながら、導入・設定・社内ルールの追加・CI組み込みまでを解説します。

まとめ：cfn-lint導入の要点

• 導入はpip install cfn-lintの1行だが、対応Pythonは3.10〜3.14。Python 3.9では半年以上前の1.46.0が黙って入るため、まずPythonの版数を確認する。
• 終了コードはビットORで決まる（エラー2・警告4・情報8の合算）。CIで警告を許容するなら--non-zero-exit-code errorを付ける。
• 抑制は.cfnlintrc.yaml・テンプレートのMetadata・コマンドライン引数の3階層で、後のものが前を上書きする。リソース単位の抑制はMetadataでしか書けない。
• 「SSHを全世界に開けない」「タグを必須にする」といった社内ルールは、1行のカスタムルール（-z）か--override-specで足せる。ただし書式を誤るとエラーにならず黙って何も検査しない。
• CI組み込みはGitHub Actionsとpre-commitの2通り。pre-commitは対象ファイルの既定が広く、CloudFormation以外のYAMLまで検査してしまう。
• VS CodeでUnable to start cfn-lintが出たら、cfnLint.pathを~や環境変数を使わない絶対パスでユーザー設定に書く。

cfn-lintが実行前に落とせる欠陥の範囲

6種類の指摘を1つのテンプレートで再現

cfn-lintは、CloudFormationのリソースプロバイダースキーマ（各リソースタイプのプロパティ定義）とルール群を突き合わせて検査します。抽象的な説明よりも出力を見るほうが早いので、欠陥を仕込んだテンプレート（template.yaml）を用意します。

AWSTemplateFormatVersion: "2010-09-09"
Parameters:
  BucketName:
    Type: String
  UnusedParam:
    Type: String
Resources:
  Bucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketNames: !Ref BucketName
      VersioningConfiguration:
        Status: Enable
  Func:
    Type: AWS::Lambda::Function
    Properties:
      Role: !GetAtt Bucket.Arn
      Runtime: python3.9
      Handler: index.handler
      Code:
        ZipFile: "def handler(e, c): return 1"
      MemorySize: 100000
Outputs:
  Name:
    Value: !Ref MissingResource

これをcfn-lint template.yamlに通すと、次の6件が返り、終了コードは6でした（cfn-lint 1.57.2の実行結果をそのまま掲載しています）。

W2001 Parameter UnusedParam not used.
template.yaml:5:3

E3002 Additional properties are not allowed ('BucketNames' was unexpected. Did you mean 'BucketName'?)
template.yaml:11:7

E3030 'Enable' is not one of ['Enabled', 'Suspended']
template.yaml:13:9

W2531 Runtime 'python3.9' was deprecated on '2025-12-15'. Creation was disabled on '2027-02-01' and update on '2027-03-03'. Please consider updating to 'python3.14'
template.yaml:18:7

E3034 100000 is greater than the maximum of 32768
template.yaml:22:7

E6101 'MissingResource' is not one of ['BucketName', 'UnusedParam', 'Bucket', 'Func', 'AWS::AccountId', 'AWS::NoValue', 'AWS::NotificationARNs', 'AWS::Partition', 'AWS::Region', 'AWS::StackId', 'AWS::StackName', 'AWS::URLSuffix']
template.yaml:25:5

指摘は「ルールID・メッセージ・ファイル名と行:列」の3点セットで、行番号がそのままエディタのジャンプ先になります。E3002はスペルの近い候補まで提示し、W2531はLambdaランタイムの廃止日と代替版を日付付きで返します。参照先のないリソース名（E6101）は、テンプレート内で使える名前の一覧を並べて示します。ルールIDの先頭文字がE（エラー）・W（警告）・I（情報）の重大度で、1.57.2ではcfn-lint -lで329件のルールが列挙されました（内訳はE243件・W66件・I20件）。1.56.0の323件から6件増えており、ルールは月単位で足されていきます。

条件分岐の先まで追う静的解析

cfn-lintの検査は宣言の字面だけでは終わりません。次のテンプレート（billing.yaml）は、本番環境のときだけBillingModeがPROVISIONEDになるDynamoDBテーブルです。

AWSTemplateFormatVersion: "2010-09-09"
Parameters:
  Env:
    Type: String
    AllowedValues: [dev, prod]
    Default: dev
Conditions:
  IsProd: !Equals [!Ref Env, prod]
Resources:
  Table:
    Type: AWS::DynamoDB::Table
    Properties:
      BillingMode: !If [IsProd, PROVISIONED, PAY_PER_REQUEST]
      AttributeDefinitions:
        - AttributeName: id
          AttributeType: S
      KeySchema:
        - AttributeName: id
          KeyType: HASH

$ cfn-lint billing.yaml
E3639 'ProvisionedThroughput' is a required property
billing.yaml:12:5

PROVISIONEDを選んだ分岐ではProvisionedThroughputが必須になるため、dev環境で何度デプロイしても表面化しない欠陥をcfn-lintは事前に指摘します。--parameters Env=devで値を固定して実行しても同じ指摘が出ました。到達しない分岐も検査対象に含める挙動で、条件分岐を多用したテンプレートほど価値が出ます。CloudFormationのテンプレート構文そのものはAWS CloudFormationの書き方とスタック操作の解説で確認してください。

cfn-nag・CloudFormation Guard・Checkovとの守備範囲の違い

cfn-lintは仕様どおりに書けているかを見るツールで、既定のルールにもパスワード設定を確認するW2501などのセキュリティ関連チェックがありますが、組織固有のセキュリティ基準や社内ポリシーを網羅するものではありません。混同しやすい周辺ツールとの関係は次のとおりです。

最終更新はGitHubリポジトリの最終push日（2026-10-17確認）です。cfn_nagは2024年8月から更新が止まっており、新しいリソースタイプへの追随は期待しにくい状態にあります。実務では「cfn-lintで仕様違反を落とし、cfn-guardかCheckovでポリシー違反を落とす」という二段構えが素直です。ただし判定が「このプロパティがこの値でないこと」程度で済むなら、後述するcfn-lintのカスタムルールだけで足ります。静的解析そのものの考え方は静的解析の仕組みとツールの選び方にまとめています。なおAWS CDKで記述したインフラを検査したい場合も、cdk synthがcdk.out配下へ出力するJSONテンプレートを渡せば同じルールで検査できます。

cfn-lintのインストールと対応Python版

macOS標準のPythonで入る1.46.0という落とし穴

cfn-lintはPython 3.10から3.14までをサポートします（PyPIのメタデータは>=3.10,<3.15）。ここを見落とすと事故になります。macOSに標準で入っているPython 3.9.6の仮想環境でpip install cfn-lintを実行すると、エラーにはならず1.46.0がそのまま導入されます。1.46.0（2026-03-02公開）のPython要件は>=3.9で、pipが3.9で動く最後の版を選ぶためです。

Python 3.9のサポートを切ったのは1.47.0（2026-03-17公開）で、それ以降の約7か月分のルール追加とリソーススキーマ更新が丸ごと抜け落ちます。新しいリソースタイプが「存在しない」と誤検出されたら、まずcfn-lint --versionを疑ってください。

# Python 3.10〜3.14を導入済みの環境（ここでは3.13）
$ python3.13 -m venv .venv
$ source .venv/bin/activate
$ pip install cfn-lint
$ cfn-lint --version
cfn-lint 1.57.2

プロジェクト直下の仮想環境に入れておくと、CIとローカルで版数を揃えやすくなります。SARIF形式やJUnit形式で出力する場合は、追加依存を含むpip install "cfn-lint[sarif]"やpip install "cfn-lint[full]"を指定します（追加依存の名前はgraph・junit・sarif・fullの4つ）。

WindowsとHomebrew、コンテナでの導入

Windowsではランチャー経由で版数を明示すると確実です。py -3.13 -m venv .venvで仮想環境を作り、PowerShellでは.\.venv\Scripts\Activate.ps1、コマンドプロンプトでは.venv\Scripts\activate.batで有効化してからpip install cfn-lintを実行します。PowerShellでcfn-lintが見つからない場合は、仮想環境を有効化せずにグローバルへ入れた結果、ScriptsディレクトリがPATHに載っていない可能性があります。未インストールや別のPython環境へのインストールも確認してください。.venv\Scripts\cfn-lint.exeのように実行ファイルを直接指定すればPATHの設定を待たずに動かせます。python -m cfnlintという呼び出し方は用意されておらず、1.57.2でもNo module named cfnlint.__main__で失敗します。

macOSではHomebrewの公式formulaも用意されており、2026-10-17時点で1.57.2が配布されています。Homebrew側のPython（[email protected]）に依存して動くため、システムのPython版数に引きずられません。コンテナで動かす場合は、公式リポジトリのDockerfileからdocker build --tag cfn-lint:latest .でイメージを作り、検査対象のディレクトリを/dataにマウントして実行する手順が公式READMEに記載されています。

日本語テンプレートの文字コードと読み込みエラー

Windowsで導入した人がつまずきやすいのが文字コードです。古い解説記事では「日本語のコメントを書くと読み込めない」とされていますが、1.57.2のソースではYAMLとJSONのどちらもencoding="utf-8"を明示してファイルを開きます。つまり今の失敗条件は「日本語を書いたこと」ではなく、テンプレートをShift_JIS（CP932）で保存したことです。日本語コメント入りの同じテンプレートを3通りの文字コードで保存して試した結果は次のとおりでした。

$ cfn-lint ja_sjis.yaml
2026-10-17 11:49:58,134 - cfnlint.decode.decode - ERROR - Cannot read file contents: ja_sjis.yaml
E0000 Cannot read file contents: {filename}
ja_sjis.yaml:1:1

E0000の行はファイル名の置き換えが効かず{filename}のまま表示されるため、どのファイルが原因かは直前のERROR行か末尾の位置表示で読み取ります。対処はエディタの保存形式をUTF-8に変えるだけで、Windowsの「ワールドワイド言語サポートでUnicode UTF-8を使用」を有効にしたり、日本語コメントを削ったりする必要はありません。

終了コードと出力形式の読み方

終了コードはビットOR

CIに組み込むうえで最重要の仕様が終了コードです。cfn-lintは検出した重大度ごとにビットORで値を積み上げます。エラーが2、警告が4、情報が8で、エラーと警告が同時に出れば6になります。実測値は次のとおりでした。

情報レベルの指摘があればさらに8が加算され、3種類そろうと14になります。「未使用パラメータ（W2001）だけでビルドを落としたくない」という要件は珍しくありません。その場合は--non-zero-exit-code errorを付けると、エラー以上だけが非ゼロになります。先ほどの6件が出るテンプレートで試すと、終了コードは6から2へ変わりました。値にnoneを指定すると、構文エラー以外は常に0で返ります。

$ cfn-lint --non-zero-exit-code error template.yaml; echo "EXIT=$?"
EXIT=2

出力形式6種類とSARIF・JUnitの追加依存

-fで選べる形式はquiet・parseable・json・junit・pretty・sarifの6種類です。GitHubのコード スキャン画面に指摘を出したい場合はSARIFを選びます。ここに落とし穴があり、SARIFとJUnitは追加依存を入れていないと実行時に失敗します。素のpip install cfn-lintのまま-f sarifを指定すると、次の例外で停止しました。

ImportError: Missing optional dependencies sarif

JUnit形式も同様で、-f junitはMissing optional dependencies junitで止まります。CIのログでこの行だけを見ると原因を追いにくいため、これらの形式を使うワークフローではpip install "cfn-lint[sarif]"のように追加依存を明示してください。なお情報レベル（Iで始まるルール）は後方互換のため既定で無効で、公式READMEでは-c I（--include-checks I）で有効化すると案内されています。

設定ファイルとMetadataによる抑制の3階層

.cfnlintrcへの対象と除外の集約

毎回コマンドラインへオプションを並べる代わりに、リポジトリ直下の.cfnlintrc・.cfnlintrc.yaml・.cfnlintrc.ymlのいずれかへ設定を書けます（ホームディレクトリの~/.cfnlintrcも読まれます）。

# .cfnlintrc.yaml
templates:
  - template.yaml
ignore_checks:
  - W2531
regions:
  - ap-northeast-1

この状態で引数なしのcfn-lintを実行すると、templatesに書いたファイルが検査され、W2531だけが結果から消えます。regionsを指定すると、そのリージョンで提供されていないリソースタイプやプロパティを検出できます。CIの設定ファイルにオプションを埋め込むより、リポジトリの設定ファイルへ寄せたほうがローカルとCIの結果が一致します。

リソース単位の抑制はテンプレートのMetadata

.cfnlintrcのignore_checksはテンプレート全体に効くため、「このリソースだけは意図的に仕様外」という抑制には向きません。リソース単位で消すには、対象リソースのMetadataへ書きます。

Resources:
  Bucket:
    Type: AWS::S3::Bucket
    Metadata:
      cfn-lint:
        config:
          ignore_checks:
            - E3030
    Properties:
      VersioningConfiguration:
        Status: Enable

この記述を加えると、当該リソースのE3030だけが消え、他のリソースのE3030は残ります。抑制の理由をコメントで残せるのも利点です。ただしSAMテンプレートのAWS::Serverless::*リソースは、SAM変換の過程でMetadataが失われる場合があると公式READMEに注記されています。

適用順は設定ファイル、Metadata、コマンドライン

3つの設定元が競合したときの優先順位は、設定ファイル → テンプレートのMetadata → コマンドライン引数の順で後のものが上書きします。CIだけルールを厳しくしたいなら、共通設定を.cfnlintrcへ、CI固有の上書きを引数へ置く形が扱いやすくなります。逆に「テンプレートに書いた抑制がCIで効かない」と感じたときは、CI側の引数が上書きしていないかを確認してください。

社内ルールを足す：カスタムルールとoverride-spec

既定のルールは「CloudFormationの仕様として正しいか」しか見ません。SSHポートを0.0.0.0/0へ開けたセキュリティグループも、タグの無いS3バケットも、仕様上は正しいので素通りします。実際、下のセキュリティグループ（sg.yaml）は既定のままでは指摘0件・終了コード0でした。ここに組織のルールを足す手段が2つ用意されています。

AWSTemplateFormatVersion: "2010-09-09"
Resources:
  WebSg:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: web
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 22
          ToPort: 22
          CidrIp: 0.0.0.0/0

1行で書くカスタムルールと書式の落とし穴

1つ目はカスタムルールです。「リソースタイプ・プロパティ・演算子・値・重大度・メッセージ」を1行に並べたテキストファイル（custom_rules.txt）を作り、-z（--custom-rules）で渡します。演算子はEQUALS・NOT_EQUALS・REGEX_MATCH・IN・NOT_IN・大小比較・IS DEFINEDなどが使えます。

AWS::EC2::SecurityGroup SecurityGroupIngress.CidrIp NOT_EQUALS "0.0.0.0/0" ERROR "SSHなどを全世界へ開放しない"

$ cfn-lint sg.yaml -z custom_rules.txt
E9001 SSHなどを全世界へ開放しない
sg.yaml:11:11

ルールIDはファイルの行番号からE9001のように自動で振られ、終了コードは2になりました。CidrIpを10.0.0.0/16に変えたテンプレートでは指摘0件です。日本語のメッセージもそのまま表示されます。

注意すべきは書式の誤りがエラーにならない点です。公式ドキュメントは書式を<Property[*]>と表記していますが、これは記法の説明で、配列の要素を指すつもりでSecurityGroupIngress[*].CidrIpと書くと、何も検出せず終了コード0で終わりました。配列はドット区切りのまま書けば要素ごとに検査されます。もう1つ、AWS::S3::Bucket Tags IS DEFINED WARN "..."でタグの付け忘れを探すと、Propertiesブロックを持つバケットは検出されたものの、Properties自体を書いていないバケットは見逃されました。ルールを足したら、違反を仕込んだテンプレートで本当に落ちるかを一度確かめてから運用に乗せてください。

override-specによるスキーマの必須項目追加

2つ目は--override-spec（-o）で、cfn-lintが持つリソーススキーマ自体にJSON Patchを当てます。公式の説明にあるS3バケットのタグ必須化をそのまま試しました。

{
  "Patches": {
    "AWS::S3::Bucket": [
      { "op": "add", "path": "/required", "value": ["Tags"] }
    ]
  }
}

この方式では、カスタムルールで見逃したPropertiesの無いバケットもE3003 'Tags' is a required propertyとして検出されました。このS3バケットの例では、Properties自体を省略した場合もoverride-specで検出できます。ただし、スキーマ構造の更新でパッチが適用できなくなる場合があるため、cfn-lintの更新時には違反例を再検査してください。使えるリソースタイプを絞るIncludeResourceTypes・ExcludeResourceTypesもあり、AWS::EC2::*のようなワイルドカードが使えます。ここにも落とし穴が2つあります。

• 同じドキュメントの本文はExcludedResourceTypes（edが付く）と書いていますが、このキーで書くと何も起きず終了コード0でした。効くのはJSON例と同じExcludeResourceTypesです。
• 除外したリソースタイプを使うと、E3006 Resource type 'AWS::EC2::SecurityGroup' does not exist in 'us-east-1'と「リージョンに存在しない」という文面で報告されます。社内ルールで禁止した結果だと気づけるよう、READMEやPRテンプレートに書き添えておくと混乱を防げます。

.cfnlintrcによるCIとエディタの設定共有

どちらの設定も.cfnlintrc.yamlに書けます。custom_rules: custom_rules.txtとoverride_spec: override.jsonを足して引数なしで実行すると、コマンドラインで渡したときと同じ指摘が出ました。リポジトリに設定を置けばローカル・pre-commit・CIの結果が揃います。複数のアカウントやチームでテンプレートの書き方を統一したい場合、ルールの設計からCIへの組み込みまでを含めてAWSのインフラ構築支援として相談いただくこともできます。

CI組み込み：GitHub Actionsとpre-commit

GitHub Actionsでの実行とSARIFの取り込み

GitHub Actionsでは、cfn-lintをランナーのPATHへ通すアクションを使う方法と、pipで直接入れる方法があります。前者で広く使われているのがscottbrenner/cfn-lint-actionで、最新リリースはv2.8.0（2026-08-14）です。

name: Lint CloudFormation Templates
on: [push]
jobs:
  cfn-lint:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      security-events: write
    steps:
      - uses: actions/checkout@v6
      - uses: scottbrenner/[email protected]
        with:
          version: "[sarif]==1.57.2"
      - run: cfn-lint --non-zero-exit-code error -t ./template.yaml

version入力を省略すると、最新版が追加依存込みで導入されます。逆に1.57.2のような素の版数だけを書くと追加依存が付かないため、SARIF出力を使うワークフローでは[sarif]==1.57.2のように追加依存と版指定をまとめて渡します（この書式はv2.4.8以降で使えます）。アクションは一時的な仮想環境へcfn-lintを導入するため、後続ステップでpip installしたプラグインは同じ環境に入りません。プラグインを足す場合は、アクションが返すcfn_lint_venv出力のパスを使います。

指摘をコード スキャンのアラートとして残すなら、上の例の最後のrunステップを、次の3ステップに置き換えます。アップロードには上の例のようにsecurity-events: write権限が必要です（非公開リポジトリではcontents: readも要ります）。cfn-lintは指摘があると非ゼロで終了するため、生成ステップにcontinue-on-error: trueを付けないとアップロードまで進みません。ただし付けただけではジョブが成功扱いになるので、最後のステップで生成ステップの結果（outcome）を見てジョブを失敗させます。

      - id: lint
        run: cfn-lint --non-zero-exit-code error -f sarif --output-file cfn-lint.sarif -t ./template.yaml
        continue-on-error: true
      - uses: github/codeql-action/upload-sarif@v4
        if: always()
        with:
          sarif_file: cfn-lint.sarif
      - if: steps.lint.outcome == 'failure'
        run: exit 1

pre-commitフックと対象ファイルの絞り込み

コミット前に検査するなら、公式リポジトリが提供するpre-commitフックを使います。用意されているIDは3つで、cfn-lintが標準、cfn-lint-rcは.cfnlintrcのtemplatesに任せる版（ファイル名を渡さない）、cfn-python-lintは旧名を残した互換IDです。

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/aws-cloudformation/cfn-lint
    rev: v1.57.2
    hooks:
      - id: cfn-lint
        files: ^cfn/.*\.(json|yaml|yml)$

filesの指定を省略できない理由があります。フック定義の既定値は\.(json|yaml|yml)$で、リポジトリ内のすべてのYAMLとJSONが検査対象になります。試しにdocker-compose.ymlをそのまま渡すと、CloudFormationテンプレートではないという指摘が2件返り、終了コードは2でした。

$ cfn-lint docker-compose.yml
E1001 'Resources' is a required property
docker-compose.yml:1:1

E1001 Additional properties are not allowed ('services' was unexpected)
docker-compose.yml:1:1

「テンプレートとして壊れている場合の指摘を無視する」オプションの-b（--ignore-bad-template）を付けても、この2件は消えませんでした。テンプレート専用のディレクトリを切ってfilesで絞るのが確実です。同じ思想のTerraform向けツールについてはTFLintの導入とCI組み込みの解説もあわせて参照してください。

VS Code拡張で指摘が出ないときの確認順

エディタ上で赤線を出すには、拡張機能「CloudFormation Linter」（識別子はkddejong.vscode-cfn-lint、2026-07-09公開の0.27.0）を入れます。この拡張はcfn-lintコマンドを子プロセスとして呼び出す薄い層で、「入れたのに何も出ない」「起動エラーが出る」という詰まり方の原因は次の4つに集約されます。

• cfn-lint本体が入っていない。Pythonパッケージの導入は別途必要です。ターミナルでcfn-lint --versionが通るかを先に確認します。
• cfnLint.pathに~や環境変数を書いている。0.27.0は拡張のソース上、シェルを介さずに（shell: falseで）cfn-lintを起動するため、~/.venv/bin/cfn-lintや%USERPROFILE%は展開されません。このとき出るのが[cfn-lint] Unable to start cfn-lint (Error: spawn ~/.venv/bin/cfn-lint ENOENT). Is cfn-lint installed correctly?というエラーで、同じ起動方法をNode.jsで再現すると一字一句同じ文面になりました。絶対パスで書き、空白を含むパスは引用符で囲みます。WindowsのC:\...\Scripts\cfn-lint.exeはバックスラッシュのままで構いません。
• cfnLint.pathをワークスペース設定に書いている。拡張の設定説明には「起動する実行ファイルを決めるキーなので、セキュリティ上ユーザー設定またはリモート（マシン）設定で指定し、ワークスペースやフォルダーの設定からは反映しない」と書かれています。仮想環境のcfn-lintを指定したいときは、プロジェクト直下の設定ではなくユーザー設定に書くのが確実です。同じ注意書きがcfnLint.appendRulesとcfnLint.ignoreRulesにもあります。
• ファイルの言語モードがYAMLでもJSONでもない。拡張の起動条件はonLanguage:yamlとonLanguage:jsonで、独自拡張子のテンプレートをPlain Textとして開いていると拡張自体が起動しません。

設定が正しくても保存時まで結果が更新されないことがあるため、判断に迷ったらターミナルで同じファイルを検査して出力を比べてください。手元のIntel Mac上では6件の指摘が出るテンプレート1本の検査に約1.4秒かかりました（マシン性能に左右される値です）。大量のテンプレートを一括検査すると、エディタ側の反映が遅れて見えます。

SAMテンプレート検証で指摘が40件に膨らむ理由

cfn-lintはAWS SAMのテンプレートにも対応しており、内部でSAM変換を行ってから検査します。AWS SAMの基本とCLIの使い方を押さえていれば、追加の設定なくcfn-lint template.yamlがそのまま通ります。ただしSAM特有の読み方が要ります。次の例は、API Gatewayのイベント定義でMethodをMethdoと打ち間違えただけのテンプレートです。

AWSTemplateFormatVersion: "2010-09-09"
Transform: AWS::Serverless-2016-10-31
Resources:
  Api:
    Type: AWS::Serverless::Function
    Properties:
      Handler: app.handler
      Runtime: python3.13
      CodeUri: ./src
      Events:
        Get:
          Type: Api
          Properties:
            Path: /items
            Methdo: GET

この綴りの誤りに対して、cfn-lintは40件の指摘を返しました（1.57.2でも件数は同じ）。SAMのEventsは「S3・SNS・SQS・Schedule…」という複数のイベント型のいずれかに一致すればよい構造で定義されているため、どの型としても解釈できなくなった時点で全候補の不一致が個別に報告されるためです。先頭には「どの定義にも当てはまらない」というE3017が出て、その後に'Api' is not one of ['S3']のような一見無関係な行が並びます。これは全候補を順に試した記録です。

E3017 {'Type': 'Api', 'Properties': {'Path': '/items', 'Methdo': 'GET'}} is not valid under any of the given schemas
sam.yaml:11:9

E3030 'Api' is not one of ['S3']
（中略）
E3002 Additional properties are not allowed ('Methdo' was unexpected. Did you mean 'Method'?)
sam.yaml:15:13

読む順序を変えるだけで解決します。Did you meanを含む行と、行番号が最も深い位置を指す行から読むのが定石です。上の例では最後の1行が真因を的確に示していました。件数の多さに驚いて設定で抑制する前に、末尾を確認してください。

よくある質問

cfn-lintとcfn-python-lintは別のツールですか？

同じツールの旧称です。PyPIにcfn-python-lintというパッケージは存在せず、導入はpip install cfn-lintで統一されています。旧名が残っているのはpre-commitのフックIDだけで、既存の設定を壊さないためにcfn-python-lintというIDが互換用に維持されています。

pip install cfn-lintで古い版が入るのはなぜですか？

多くはPython 3.9で実行しているためです。cfn-lintは1.47.0（2026-03-17公開）でPython 3.9のサポートを終了しており、pipはエラーを出さずに条件を満たす最後の版である1.46.0を選びます。macOS標準のpython3は3.9系のことがあるため、python3 --versionとcfn-lint --versionの両方を確認してください。

CIで警告は無視してエラーだけ止めたいのですが？

--non-zero-exit-code errorを付けます。cfn-lintの終了コードは重大度のビットOR（エラー2・警告4・情報8）で決まるため、このオプションを付けないと未使用パラメータの警告だけでもビルドが落ちます。特定のルールだけ黙らせたい場合は-i W2001のようにIDを指定するか、.cfnlintrcのignore_checksに列挙します。

cfn-lintでセキュリティの問題も検出できますか？

既定のルールでは限定的です。0.0.0.0/0へのSSH開放のような設定は仕様上正しいため指摘されません。「特定のプロパティが特定の値でないこと」「特定のプロパティを必ず書くこと」程度の判定なら、本文で紹介したカスタムルールやoverride-specで足せます。複数のプロパティを組み合わせた条件や、組織全体のポリシーを体系的に管理したい場合はcfn-guardかCheckovを併用してください。パイプラインではcfn-lintを最初に置いて仕様違反で早く落とし、通過したテンプレートだけをポリシー検査へ回す並べ方が無駄がありません。

cfn-lintはインターネットに接続できない環境でも使えますか？

使えます。リソーススキーマはリージョンごとにパッケージへ同梱されており、プロキシ設定を到達できないアドレスに向けて通信を塞いだ状態でも、冒頭のテンプレートで同じ6件の指摘が出ました。通信が必要になるのは、スキーマを手動で最新化する--update-specs（-u）を使うときです。閉域網ではスキーマの更新がcfn-lint本体の更新と同時になるため、版数を定期的に上げる運用にしてください。

関連記事

• AWS CloudFormationとは？テンプレートの書き方・スタック操作と更新で消える設定の防ぎ方
• AWS SAMとは？CloudFormationとの違い・CLIの使い方をわかりやすく解説
• TFLintとは？Terraform静的解析の導入・設定・CI組み込み【v0.64.0対応】
• 静的解析とは？実行せずに欠陥を見つける仕組みとツールの選び方
• AWS CDK（cdk）とは？仕組み・使い方とCloudFormation・Terraformとの違い