【ITニュース解説】YAML document from hell (2023)

システムエンジニアを目指す上で、YAML（ヤムル）というデータ形式に触れる機会は非常に多いだろう。YAMLは「YAML Ain't Markup Language」の略であり、「人間にとって読みやすく、コンピューターにとっても扱いやすいデータ形式」を目指して設計された。特に、プログラムの設定ファイルや、システム間でデータをやり取りする際の形式として、多くのプロジェクトで利用されている。その見た目のシンプルさから、初めて触れる人にとっては非常に親しみやすい印象を与えるかもしれない。しかし、この簡潔な見た目とは裏腹に、YAMLには数々の複雑な側面と、予期せぬ問題を引き起こす可能性が潜んでおり、時には「YAML地獄（YAML document from hell）」とまで呼ばれることがある。

この「YAML地獄」とは具体的に何を指すのだろうか。その根源にあるのは、YAMLの仕様自体の極めて高い複雑性だ。一見するとシンプルなルールで記述できるように見えるYAMLファイルだが、その背後にある正式な仕様書は、一般的なプログラミング言語の仕様書と比較しても遜色ないか、それ以上に広範で難解なものだ。これほど複雑な仕様であるため、YAMLファイルを読み込んでその内容を解釈するプログラム、すなわち「YAMLパーサー」を完全に仕様通りに実装することは非常に難しい。結果として、世の中に存在する様々なYAMLパーサーは、それぞれが仕様の一部しかサポートしていなかったり、特定の解釈に違いがあったりすることが少なくない。

特に問題を引き起こしやすいのが、YAMLのデータ型の扱いに起因する部分だ。YAMLは、データ型を明示的に指定しなくても、パーサーがデータの見た目から適切な型を自動的に推測してくれるという便利な特徴を持つ。例えば、「123」は数値、「hello」は文字列といった具合だ。しかし、この自動的な型推論が、開発者の意図とは異なる結果を招くことが頻繁に発生する。「YES」や「NO」といった単語は、真偽値（true/false）として解釈されてしまう場合がある。また、ソフトウェアのバージョン番号である「1.0」や「2.0」などは、単なる浮動小数点数ではなく、特定の意味を持つ文字列として扱いたい場合が多いが、パーサーによっては数値として扱われることがある。さらに、「007」のように先頭にゼロがある数字が八進数として解釈されたり、特定の形式の文字列が意図せず日付や時刻として解釈されたりすることもある。このような誤った型推論は、データの意味を根本から歪め、プログラムが開発者の期待とは異なる動作をする原因となる。

異なるシステム間でYAMLファイルを受け渡して利用する場面では、パーサー間の非互換性が大きな障壁となる。あるシステムでは問題なく解釈されたYAMLファイルが、別のシステムではエラーを発生させたり、全く異なるデータとして処理されたりすることがあるのだ。これは、各YAMLパーサーが、複雑なYAML仕様のどの部分をどのように解釈するか、あるいはどの機能を実装しているかによって差異が生じるためだ。このような状況では、開発者はYAMLファイルがなぜ正しく動作しないのかを突き止めるために、各パーサーの具体的な挙動を詳細に調査する必要が生じる。これはシステム間の連携において予期せぬバグを生み出し、開発における時間と労力を著しく増大させる。

さらに、YAMLが持つ一部の強力な機能は、セキュリティ上のリスクにつながる可能性もはらんでいる。YAMLは、特定のタグを使用することで、プログラミング言語のオブジェクトを直接データ形式に変換（シリアライズ）し、またそのデータ形式から元のオブジェクトに戻す（デシリアライズ）機能を持っている。この機能は、正しく使えば非常に便利だが、悪意を持って作成されたYAMLファイルを処理した場合、システム上で予期しないコードが実行されてしまう「リモートコード実行」といった脆弱性を引き起こす可能性がある。特に、信頼できないソースから提供されたYAMLファイルを扱う際には、このセキュリティリスクを十分に考慮し、細心の注意を払う必要がある。PythonのPyYAMLライブラリなど、過去にこのようなセキュリティ問題が指摘され、対策が講じられた事例も存在する。

YAMLには、アンカーやエイリアスといった、同じデータをYAMLドキュメント内の複数箇所で再利用できる機能や、マージキーと呼ばれる、既存のマップ（キーと値のペアの集まり）の内容を別のマップに統合できる機能など、非常に豊富な表現力がある。これらの機能は、設定ファイルの重複を減らし、記述を簡潔にする上で役立つ一方で、YAMLドキュメントの構造をより複雑にし、初心者だけでなく経験豊富なエンジニアにとってもその内容を理解することを難しくする側面がある。アンカーがどこを参照しているのか、マージキーが最終的にどのようなデータ構造を作り出すのかを正確に把握するためには、ドキュメント全体を注意深く分析する必要がある。

システムエンジニアを目指す者は、YAMLの見た目のシンプルさに惑わされることなく、その根底にある潜在的な複雑性と落とし穴を深く理解することが重要だ。YAMLを使用する際には、いくつかの点に注意を払うことで、これらの問題を回避できる可能性が高まる。まず、可能な限りシンプルな記述を心がけ、アンカー、エイリアス、マージキーなどの複雑な機能は、その必要性を十分に検討した上で慎重に利用することだ。次に、データ型が誤って解釈されないように、数値と見られがちな文字列や、真偽値と間違われやすい文字列（例: バージョン番号の「1.0」、単語の「NO」など）は、ダブルクォーテーション（"）などで明示的に囲んで文字列として扱う工夫が必要だ。また、自身が使用するYAMLパーサーがどのような挙動をするのか、その特性や制限を事前に把握しておくことも欠かせない。そして、信頼できないソースから受け取ったYAMLファイルを処理する際には、セキュリティリスクを十分に認識し、オブジェクトのデシリアライズ機能を無効にするなど、適切なセキュリティ対策を講じるべきだ。

YAMLはその利便性から、これからも多くのシステムで利用され続けるだろう。しかし、その裏に潜む「地獄」の存在を理解し、その特性を熟知した上で賢く付き合っていくことが、安定したシステムを構築するためには不可欠となる。YAMLの代替となりうるJSONのようなデータ形式も存在するが、それぞれの特性を理解し、プロジェクトの要件やチームのスキルレベルに合わせて最適なツールを選択する判断力も、これからのシステムエンジニアには求められる重要な能力の一つである。