YAML vs TOML：どちらの設定フォーマットを選ぶべきか？

YAMLとTOMLはどちらも人間が読みやすい設定フォーマットですが、根本的に異なるアプローチを取っています。YAMLはインデントで構造を表現し、TOMLはINIスタイルのヘッダーと明示的なキーバリュー構文を使用します。最適な選択は、プロジェクト、チーム、エコシステムによって異なります。

構文の比較

同じ設定を両フォーマットで表現

YAML:

database:
  host: localhost
  port: 5432
  name: myapp
  ssl: true
  pool:
    min: 5
    max: 20
  
server:
  host: 0.0.0.0
  port: 8080
  workers: 4
  cors:
    origins:
      - https://example.com
      - https://api.example.com

TOML:

[database]
host = "localhost"
port = 5432
name = "myapp"
ssl = true

[database.pool]
min = 5
max = 20

[server]
host = "0.0.0.0"
port = 8080
workers = 4

[server.cors]
origins = [
  "https://example.com",
  "https://api.example.com"
]

主な違い

特徴	YAML	TOML
構造	インデントベース	セクションヘッダー
文字列の引用符	通常は省略可	常に必須
型推論	積極的（リスクあり）	明示的
コメント	`#`（単一行）	`#`（単一行）
複数行文字列	`\|` と `>` ブロック	トリプルクォートブロック
日付/時刻サポート	ISO 8601文字列	ネイティブdatetime型
アンカー/エイリアス	あり	なし
ネストの深さ	無制限（実用的）	無制限（深いと冗長）
テーブルの配列	マッピングのシーケンス	`[[section]]` 構文
仕様	大きく複雑	小さくシンプル

型安全性

YAMLの型推論の問題

YAMLは積極的に型を推論するため、微妙なバグを引き起こします：

version: 1.0     # 浮動小数点数、文字列 "1.0" ではない
country: NO      # ブール値 false、文字列 "NO" ではない
port: '080'       # 8進数 64、文字列 "080" ではない
on: true         # ブール値、文字列 "on" ではない

TOMLの明示的な型

TOMLは明示的な構文を要求し、型の混乱を防ぎます：

version = "1.0"   # 文字列（引用符必須）
country = "NO"    # 文字列（引用符必須）
port = "080"      # 文字列（引用符必須）
on = true         # ブール値（曖昧さなし）

TOMLには日付と時刻のネイティブ型があります：

created = 2024-01-15  # DateTime（ネイティブ型）
date-only = 2024-01-15             # Date
time-only = 10-30-00               # Time

エコシステムのサポート

YAMLが主流

Docker Compose
Kubernetes
GitHub Actions
Ansible
CI/CDパイプライン（CircleCI、GitLab CI、Travis CI）
クラウドサービス（AWS CloudFormation、Azure）
ほとんどのDevOpsツール

TOMLは成長中

Rust（Cargo.toml）
Python（pyproject.toml、PEP 518）
Go（go.modは独自フォーマットだが、設定にはTOML）
Hugo（サイト設定）
Netlify
pip（pyproject.toml）

JSON設定（比較のため）

Node.js（package.json、tsconfig.json）
VS Code設定
ESLint、Prettier
ほとんどのJavaScriptツール

YAMLを使うべき場面

DevOpsとインフラ：Kubernetes、Docker、CI/CD — エコシステムが要求する
複雑なネスト構造：YAMLは深いネストをより自然に処理する
アンカーによる再利用：アンカーとエイリアスによるDRYな設定
チームの慣習：チームがすでにYAMLを広く使用している場合

YAMLに関するヘルプは、YAMLフォーマッターとYAMLバリデーターが必須ツールです。

TOMLを使うべき場面

Pythonプロジェクト：pyproject.tomlが標準
Rustプロジェクト：Cargo.tomlが標準
シンプルな設定：フラットまたは浅いネストの設定
型安全性が重要：TOMLの明示的な引用符が型の混乱を防ぐ
新規プロジェクト：エコシステムの制約がなければ、設定ファイルにはTOMLの方が安全

どちらも使わない場合

機械生成の設定：JSON を使用（パースが最速、最も厳密なフォーマット）
スキーマ付きアプリケーション設定：JSON Schema検証付きのJSONを使用
データ交換：APIにはJSON、表形式データにはCSVを使用

FAQ

YAMLとTOMLの相互変換はできますか？

はい、ただし注意点があります。YAMLのアンカー、エイリアス、複雑な型にはTOMLの同等機能がありません。シンプルなキーバリューやネストされた設定はきれいに変換できます。yj（YAML to JSON）とtoml-cliのようなツールを組み合わせれば、基本的な変換が可能です。

TOMLはYAMLに取って代わりますか？

可能性は低いです。YAMLはDevOpsエコシステム（Kubernetes、Docker、CI/CD）に深く根付いています。TOMLは型安全性が深いネストよりも重要なアプリケーション設定（Rust、Python）で勢力を伸ばしています。2つのフォーマットはそれぞれのエコシステムで支配的な地位を保ちながら共存していくでしょう。