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

YAML は JSON のスーパーセットとして設計されており、有効な JSON はすべて有効な YAML です。JSON にはない特徴として、コメント (#)、アンカーとエイリアス (データの再利用)、複数ドキュメントの 1 ファイル格納 (--- で区切り)、ブロックスカラー (複数行テキストの表現) などがあります。Docker Compose、Kubernetes マニフェスト、GitHub Actions ワークフロー、Ansible プレイブック、CloudFormation テンプレートなど、DevOps ツールの設定ファイルとして広く採用されています。DevOps 入門の書籍で YAML の活用方法を学べます。

YAML の構文にはいくつかの注意すべき落とし穴があります。インデントにタブ文字が使えず、スペースのみが許可されています。暗黙の型変換が予期しない動作を引き起こすことがあり、たとえば yes、no、on、off は真偽値に、1.0 は浮動小数点数に自動変換されます。Norway の国コード NO が false に変換される「Norway problem」は有名な例です。文字列を確実に文字列として扱うには引用符で囲む必要があります。

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

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

文字数カウントの観点では、YAML は括弧や引用符が少ないため、同じデータを JSON で表現するよりも文字数が少なくなる傾向があります。ただし、インデントのスペースが文字数に含まれるため、深いネスト構造では YAML のほうが文字数が多くなることもあります。設定ファイルのサイズ最適化を考える際には、データ構造の深さと YAML/JSON の文字数の関係を考慮する必要があります。