YAML（YAML Ain't Markup Language）は2001年にClark Evans・Ingy döt Net・Oren Ben-Kikiの3人が設計を始めた人間可読のデータシリアライズ言語で、現行仕様は2009年に公開されたYAML 1.2である。JSONを上位互換に取り込む形で進化したため、JSONはすべて有効なYAMLとして解釈できる。Kubernetes・Ansible・GitHub Actions・Docker Composeなど現代のインフラ自動化を支える設定言語のデファクトとして広く使われている。
この記事の目次
- YAMLの構文と型推論
- アンカーとマージ機能
- JSON・TOMLとの位置づけ
- YAMLを安全に書くための原則
- まとめ
YAMLの構文と型推論
YAMLはインデントで構造を表現し、ハイフンでリスト、コロンでマップを表す。波括弧やカンマを省略できるため、JSONより圧倒的に視認性が高く、コメント（#）も書ける。複数行の文字列はパイプ（|）でリテラルブロック、大なり（>）で折りたたみブロックとして表現でき、長文の埋め込みもしやすい。
型はスカラ値からの自動推論が基本で、true/false/yes/no/onなどがboolに、数字列がintやfloatに、日付風文字列がtimestampに変換される。これが俗に言う「Norway問題」（no→false変換）の原因で、YAML 1.2では明示的な型タグ（!!str、!!int）やフロースタイルで回避するよう仕様改善された。実装によってはYAML 1.1互換モードのままなのでハマりやすい。
アンカーとマージ機能
YAMLには他フォーマットにない強力な構文として、アンカー（&）とエイリアス（*）がある。あるノードに名前をつけ、別の場所から参照することで重複定義を避けられる。さらに「<<:」のマージキーを使うとマップを差分展開でき、Docker ComposeやGitLab CIなど、似た設定が並ぶYAMLでDRYを保つ手段として活用される。
ただし2022年にGitHub Actionsが採用するYAMLライブラリでアンカー機能を制限する事例があったように、YAML爆弾（巨大なネスト展開によるDoS）のリスクと表裏一体だ。また仕様上、マージキーはYAML 1.1の機能でYAML 1.2では非標準扱いになる微妙な位置づけがあり、互換性問題のもとにもなっている。アンカー機能はパーサ実装で挙動がばらけやすく、相互運用するシステムでは利用範囲を絞るのが安全だ。
JSON・TOMLとの位置づけ
YAMLは人間が編集しやすい設定言語として、JSONとTOMLの中間に位置する。JSONは機械間通信向けで人間編集には向かず、TOMLは設定特化でシンプルだが深いネストにやや弱い。YAMLは深いネストとリスト中心のデータを編集しやすく、Kubernetesのように多次元的な設定を扱う領域に最適化される。
一方でJSONより文法が複雑で、パーサ実装間の差も大きい。Kubernetes界隈ではYAMLの代替としてCUE、Pulumiの世界では汎用プログラミング言語そのもの、設定を厳密に型付けしたい場合はDhallといった選択肢も存在する。YAMLは「最大公約数として広く読まれる」点が最大の利点で、当面は地位を保つと見られる。
YAMLを安全に書くための原則
YAMLでハマらないための原則は、まず「曖昧なスカラはクォートする」ことだ。国コード「NO」「version: 1.10」などは推論で意図しない型に化けるため、文字列として扱うべき値はシングルクォートかダブルクォートで明示する。またPython等の言語ではyaml.safe_loadを必ず使い、yaml.loadは任意コード実行の危険性があるため避ける。
インデント幅は2スペースに統一し、タブ文字は厳禁である。CI上ではyamllint・kubeval・ajvなどでスキーマ検証を必ず行うべきだ。マルチドキュメント（---で区切る）や複雑なアンカーは便利だが、初学者には読みづらいため、運用ルールでフォーマットをそろえることがチーム全体のミス削減につながる。
まとめ
YAMLは人間が読み書きしやすい設定言語として、現代インフラ自動化の必須スキルとなっている。JSON上位互換の柔軟さと、アンカー・マージといった独自機能が魅力だが、型推論の罠やパーサ実装差もある。クォートとスキーマ検証を徹底し、設定の取り違えがプロダクションに到達しない仕組み作りが鍵だ。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント