YAML フォーマッター
YAMLを一貫したインデント幅に整形したり、JSONに変換したりできるツールです。タブ混入やインデントの不整合も検出します。
Tips
- このツールは自前実装の軽量パーサーのため、キー: 値・ネスト・リスト・インラインの
[a, b, c]や{a: 1}形式に対応しています。 - インデントが3スペースや5スペースなど不揃いなYAMLを貼り付けても、解析に成功すればスペース2または4に統一して出力し直せます。
- 「JSONに変換」モードでは、YAMLの内容をそのままJSON形式に変換したプレビューを確認できます。CI設定やAPIレスポンスとの比較に便利です。
- エラーが出た場合は行番号が表示されるので、該当行のインデントやコロンの後ろのスペース忘れを確認してください。
- YAMLではタブ文字によるインデントが禁止されています。エディタの設定で「タブをスペースに変換」を有効にしておくとトラブルを防げます。
よくある質問
人間が手で編集・レビューする設定ファイル（CI設定・Kubernetesマニフェスト等）にはコメントが書けて可読性の高いYAMLが向いています。一方、プログラム同士がやり取りするAPIレスポンス等には、曖昧さが少なく高速にパースできるJSONが向いています。
YAMLの仕様上、インデントにタブ文字を使うことは禁止されています。多くのパーサーは構文エラーとして処理を中断します。エディタの設定でタブ入力を自動的にスペースへ変換するようにしておくと安全です。
対応していません。このツールはDocker Compose・GitHub Actions等でよく使われる「よくある部分集合」（マッピング・リスト・インラインフロー・基本スカラー型）を対象としており、アンカー・エイリアス・複数ドキュメント・ブロックスカラー（
|・>）といった高度な機能は非対応です。クォートなしで
no や yes・on・off と書くと、多くのYAML実装がノルウェーの国コードなどの文字列ではなく真偽値として解釈してしまう有名な落とし穴です。文字列として扱いたい場合は "no" のようにクォートで囲む必要があります。
余談ですが ― YAMLが設定ファイルの主流になった理由
YAML（YAML Ain't Markup Language）は2001年に登場したデータ直列化フォーマットです。XMLに比べて閉じタグが不要で見た目がシンプルなことから、2010年代以降はDocker Compose・GitHub Actions・Kubernetesマニフェストなど、インフラ関連の設定ファイル形式として広く採用されるようになりました。
一方でYAMLの「インデントで構造を表す」という設計は、人間にとって読みやすい反面、コピー＆ペースト時にインデントが崩れやすいという弱点も抱えています。特にタブとスペースが混在すると、多くのパーサーがエラーを出さずに誤った構造として解釈してしまうことがあり、意図しない設定ミスの温床になりやすい点は注意が必要です。
また「Norway Problem」と呼ばれる有名な落とし穴もあります。国コード no をクォートなしで書くと、多くのYAML実装が真偽値の false と解釈してしまう問題です。YAML 1.1と1.2で真偽値として扱われる文字列の範囲が異なることも、実装間の互換性トラブルの一因になっています。