YAML (YAML Ain't Markup Language) は、インデントで階層構造を表現する人間に読みやすいデータシリアライゼーション形式です。もともとは「Yet Another Markup Language」の略でしたが、マークアップ言語ではないことを強調するため現在の再帰的頭字語に改名されました。設定ファイルやデータ交換に広く使われており、特に DevOps 分野では事実上の標準です。

YAML はバージョン 1.2 で JSON を正式な部分集合として取り込み、有効な JSON はそのまま有効な YAML として読めるようになりました (1.1 以前は完全な互換ではありません)。JSON にはない特徴として、コメント (#)、アンカーとエイリアス (データの再利用)、複数ドキュメントの 1 ファイル格納 (--- で区切り)、ブロックスカラー (複数行テキストの表現) などがあります。Docker Compose、Kubernetes マニフェスト、GitHub Actions ワークフロー、Ansible プレイブック、CloudFormation テンプレートなど、DevOps ツールの設定ファイルとして広く採用されています。

YAML の構文にはいくつかの注意すべき落とし穴があります。インデントにタブ文字が使えず、スペースのみが許可されています。もう一つは暗黙の型変換です。1.0 は浮動小数点数として読まれ、yes、no、on、off は真偽値に変換されます。ノルウェーの国コード NO が false になる「Norway problem」はその代表例です。ただしこの挙動はバージョンによって変わります。真偽値として扱う語を true / false (とその大文字形) に絞ったのはバージョン 1.2 の既定の型解釈で、Yes や No は文字列として読まれます。一方で実装側は 1.1 の解釈を残しているものが多く、Python の PyYAML 6 系では yes、no、on、off、NO がすべて真偽値になります (2026 年時点で実測)。仕様の版だけを見て安心せず、実際に使うパーサーで確認してください。文字列を確実に文字列として扱うには引用符で囲むのが最も確実です。さらに重複キーも落とし穴です。同じキーを 2 回書いてもエラーにならず後ろの値で上書きされる実装があり、PyYAML はその挙動です (同じく実測)。長い設定ファイルで設定が効かないときは、同じキーが下の方にもう一度書かれていないかを疑ってください。

YAML と JSON の使い分けは、用途によって判断します。YAML は人間が読み書きする設定ファイルに適しており、コメントが書ける点が大きな利点です。JSON はプログラム間のデータ交換に適しており、構文が単純な分パーサーの実装が小さく済み、暗黙の型変換のような解釈のゆれが起きにくい利点があります。API のレスポンスには JSON、CI/CD の設定には YAML という使い分けが一般的です。

セキュリティの観点では、YAML のデシリアライゼーションに注意が必要です。一部の YAML パーサーは任意のオブジェクトを生成できるため、信頼できないソースからの YAML を安全でないパーサーで読み込むとリモートコード実行の脆弱性につながる可能性があります。Python の PyYAML では yaml.safe_load() を使い、yaml.load() は避けるべきです。

文字数カウントの観点では、YAML は括弧や引用符が少ないため JSON より文字数が少なくなる傾向がありますが、これは比較相手が字下げ付きの JSON である場合の話です。名前と年齢とタグの配列を 1 段ネストした同じデータで数えると、YAML は 52 文字、字下げ 2 スペースの JSON は 95 文字、空白を詰めた JSON は 50 文字でした (Python 3 で実測)。つまり読みやすい形どうしを比べれば YAML が有利で、機械が読む前提で空白を詰めた JSON とはほぼ並びます。YAML はインデントのスペースが必ず文字数に入るため、ネストが深くなるほどこの差は縮み、逆転もします。設定ファイルの文字数を気にするなら、比較相手が字下げ付きなのか詰めた形なのかを先にそろえて数えてください。