YAML lint
YAML バリデーター
YAMLのどこが、なぜ間違っているかを突き止めます。
YAMLをここに貼り付けるか、ファイルをページにドロップ
入力するとJSONがここに表示されます
無料・無制限 · 登録不要 · すべてのエラーに正確な行と列、平易な説明、修正案が付きます。
チェック内容
構文
インデント、タブ、閉じられていない括弧と引用符、不正なマッピングとシーケンス。
構造
YAMLが拒否し、JSONでは黙って潰れてしまう重複キー。
参照
存在しないアンカーを指すエイリアスと、名前なしで宣言されたアンカー。
安全性
ページを固まらせる前に検出する、暴走するエイリアス展開（「billion laughs」型）。
移植性
YAML 1.1と1.2で意味が変わる値を、各バージョンの解釈結果とともに警告。
タグ
!Ref や !GetAtt のような、固有のツールの外では標準的な意味を持たないカスタムタグ。
有効なYAMLが正しいYAMLとは限らない
ドキュメントは完璧に解析できても、意図と違う意味になりうる。典型例が country: no で、どちらのYAMLバージョンでも有効ですが、一方では文字列 "no"、もう一方では真偽値 false になります。
だからこのバリデーターは2種類の結果を報告します。エラーは、ドキュメントがまったく解析できないことを意味します。警告は、解析はできるが別のツールでは値が異なって読まれることを意味します — Kubernetesマニフェストがクラスターに届く前に知っておく価値があります。
修正する前にエラーを理解したいなら、ガイドよくあるYAMLエラーと修正方法が、ほぼすべての解析失敗の背後にある6つのミス — タブ、引用符なしのコロン、閉じられていない括弧、重複キー、存在しないアンカー、不揃いなインデント — を修正前後の例付きで解説しています。
よくある質問
このYAMLバリデーターは何をチェックしますか？
まず構文です。インデント、タブ、閉じられていない括弧や引用符、形の崩れたマッピングやシーケンスを検出します。次に構造です。重複したキー、宣言されていないアンカーを指すエイリアス、際限なく展開されるエイリアスを検出します。最後に移植性です。!Ref のようにツールの外では意味を持たないカスタムタグと、YAML 1.1 と YAML 1.2 で読み方が変わる引用符なしの値をすべて報告します。各問題には行と列、平易な説明、修正案、エディター上のマーカーが付きます。
YAMLは有効なのに、なぜ意図どおりに動かないのですか？
有効であることと正しいことは別だからです。country: no はどちらのバージョンでもエラーなく解析されますが、YAML 1.2 では文字列 "no"、YAML 1.1 では真偽値 false になります。こうして国がリストから何のエラーもなく消えます。022、12:30、1e3 も同じです。このバリデーターはこれらをエラーではなく警告として報告します。文書は解析できるものの、別のツールでは値の読み方が変わるためです。値を引用符で囲めば曖昧さはなくなります。
「mapping values are not allowed in this context」とはどういう意味ですか？
すでに値を読んでいる場所で、パーサーがコロンと空白の並びを見つけたという意味です。よくある原因は、title: Deploy: production のように値自体にコロンを含む引用符なしの値や、引用符なしで書かれた URL です。値を引用符で囲んでください。もう一つの原因は、周囲のキーとインデントが異なるキーで、パーサーはそれを前の値の続きとして読んでしまいます。
「found character that cannot start any token」とはどういう意味ですか？
ほぼ常に、インデントにタブ文字が使われています。YAML ではタブによるインデントは禁止です。タブを空白に変換するエディターでは、別の環境でファイルを編集するまで問題が隠れたままになります。タブを空白に置き換え、同じ階層のキーはすべて同じ幅にしてください。バリデーターは正確な行を指し示します。同じメッセージは、紛れ込んだ制御文字や、値の先頭にある @ やバッククォートでも表示されます。
「did not find expected key」とはどういう意味ですか？
パーサーがマッピングを読んでいて、次の行にも同じインデントのキーがあると期待したのに、別のものを見つけたという意味です。報告された行の一つ前を見てください。兄弟より空白一つ分深くインデントされた値、キーが期待される場所でリストを始めるハイフン、引用符で囲むべきだった値のいずれかです。閉じられていない括弧や引用符は多くのパーサーがこのメッセージで誤って報告しますが、このバリデーターは本当の原因を復元します。
Kubernetes や OpenAPI のようなスキーマに対して検証しますか？
いいえ。文書が正しい形式の YAML であり、どのパーサーでも同じ意味になることを確認しますが、Deployment や OpenAPI 文書にどのキーが許されるかは知りません。Kubernetes では kubectl apply --dry-run=client -f file.yaml がクラスターのスキーマに対してマニフェストを確認します。OpenAPI、GitHub Actions、JSON Schema については、ここでの確認を通過した後にそれぞれの形式のスキーマバリデーターにかけてください。
検証するとき、YAMLはアップロードされますか？
いいえ。検証はブラウザ内で実行されます。文書を送信するサーバーエンドポイントは存在せず、接続を切ってもページは動き続けます。設定ファイルはホスト名や内部パス、時には秘密情報を含むものだからこそ、このツールはそのように作られています。
コマンドラインでYAMLを検証するには？
yamllint file.yaml は構文エラーとスタイルの問題を報告し、CI での定番です。yq . file.yaml は文書を出力するか、解析エラーで失敗します。Python では python -c "import sys, yaml; yaml.safe_load(sys.stdin)" < file.yaml が無効な YAML で失敗しますが、PyYAML は YAML 1.1 を読むため no も false として扱います。どれも上のバリデーターのようにはエラーを説明してくれません。パイプラインを失敗させるにはこれらを、理由を知るにはこのページを使ってください。