TOML vs YAML：同じ設定を3つの形式で比較
TOML vs YAML
TOML vs YAML（とJSON）：同じ設定を3通りで | We.Inc
同じ設定ファイルをTOML、YAML、JSONで並べて比較します。pyproject.tomlやCargo.tomlからcompose.yamlまで、それぞれの形式が必須になる場面も確認できます。
TOMLは設定ファイルのために作られたINI風の形式で、明示的な [table] ヘッダー、引用符で囲む文字列、本物の日付型を持ち、インデントに意味はありません。YAMLはインデントに頼り、裸の値から型を推測し、アンカーや複数ドキュメントの機能を加えています。浅い設定ならTOMLのほうが壊れにくく、深い入れ子ならYAMLのほうが読みやすくなります。
TOML、YAML、JSONの概要
- 入れ子
- [table] や [a.b] のヘッダー
- インデント
- 波かっこ
- 文字列
- 常に引用符で囲む
- 引用符は省略可能
- 常にダブルクォートで囲む
- 日付と時刻
- 組み込みの型
- 1.2のコアスキーマにはない
- 文字列のみ
- メディアタイプ
- application/toml
- application/yaml
- application/json
たいていは選ぶ余地がありません。Pythonのパッケージングはpyproject.tomlを、RustはCargo.tomlを読み込み、GitHub ActionsとDocker ComposeはYAMLを読み込みます。自分で選べる場合は、1つの設定を3つの形式すべてで見比べると、トレードオフがはっきりわかります。下のサンプルを選んで比べてみましょう。
- アプリの設定、パッケージのマニフェスト、サーバーの一覧の中から、サンプルの設定を1つ選びます。
- 同じデータをTOML、YAML、JSONで並べて読みます。
- TOMLでヘッダー（[[servers]]）が必要になる箇所と、YAMLで慎重なインデントが必要になる箇所に注目します。
- 使っているツールが求める形式のものをコピーします。
- 似たレコードの長いリストでは、TOMLは冗長になります。各項目にそれぞれ [[name]] ヘッダーが必要だからです。
- TOMLでは同じキーやテーブルを2回定義できません。そのため、パーサーによってはYAMLで見逃されるコピー&ペーストのミスを検出できます。
- YAMLではバージョン番号を引用符で囲みましょう。TOMLでは裸のテキストが有効な文字列になることはないので、このような落とし穴はありません。
- できるだけ1つのリポジトリでは1つの形式に統一しましょう。形式が混在してよいのは、ツールごとに独自の形式を要求する場合だけです。
よくある質問
TOMLはYAMLより優れていますか？
どちらかが常に勝つわけではありません。TOMLの明示的なヘッダーと必須の引用符により、小規模から中規模の設定ファイルは読み間違えにくくなります。YAMLは深い入れ子や長いリストを少ない記号で扱えますが、空白に敏感な構文と暗黙の型付けという代償があります。
Pythonはなぜpyproject.tomlを使うのですか？
Pythonのパッケージングガイドでは、pyproject.tomlを3つのテーブルで定義しています。ビルドバックエンド用の [build-system]、名前、バージョン、依存関係などのメタデータ用の [project]、そしてリンターなど個別のツールの設定用の [tool] です。
TOMLはYAMLで表せるものをすべて表現できますか？
すべてではありません。TOMLにはアンカーやエイリアスがなく、1ファイルに複数のドキュメントを入れることもできず、すべてのキーに値を与える必要があるためnullもありません。設定ファイルではほとんど問題になりませんが、これらの機能に頼るYAMLのデータは1対1には変換できません。
Docker ComposeとGitHub Actionsはどの形式を受け付けますか？
どちらもYAMLを使います。GitHub Actionsのワークフローは .github/workflows に .yml か .yaml の拡張子で置き、Composeはデフォルトでcompose.yamlを探しますが、古いプロジェクト向けにdocker-compose.yamlも引き続き受け付けます。
TOMLは複数行の文字列に対応していますか？
対応しています。ダブルクォート3つで、エスケープを使える複数行の基本文字列が始まり、シングルクォート3つで、書いたとおりの内容をそのまま保つ複数行のリテラル文字列が始まります。
各形式が必須になる場面
- Pythonのプロジェクトはpyproject.tomlで、RustのクレートはCargo.tomlで自身を記述するため、これらのエコシステムではTOMLが標準です。Hugoも、+++ の行で囲んだTOMLのフロントマターを受け付けます。
- CIパイプライン、コンテナの構成、デプロイのマニフェストはYAMLに頼っています。GitHub ActionsのワークフローもDocker ComposeのファイルもYAMLで、どの拡張子を選ぶかは主に統一性の問題です。
TOMLが安全のために手放したもの
- TOMLの仕様に書かれている目標は、ハッシュテーブルに曖昧さなく対応付けられることです。つまり推測はしません。テキストには引用符が必要で、真偽値はtrueとfalseだけで、すべてのテーブルはヘッダーで名前が付けられます。
- その代償は、入れ子のデータでの繰り返しです。3階層の深さになると、TOMLファイルはすべてのヘッダーでテーブルのパスを繰り返しますが、YAMLはインデントするだけです。
どのファイルがどの形式を使うか
よくある設定ファイルと必要な形式
- TOML
- Pythonのビルドツールとパッケージング
- Cargo.toml
- TOML
- Rustのパッケージマネージャー、Cargo
- .github/workflows/*.yml
- YAML
- GitHub Actions
- JSON
- npmなどのNodeのパッケージマネージャー
- Markdownのフロントマター
- YAML（Hugoでは +++ で囲んだTOML）
- 静的サイトジェネレーター
知っておきたいTOMLの構文
ドット付きキー、インラインテーブル、日付
ドット付きキーとインラインテーブルを使えば、小さなまとまりのために余分なヘッダーを書かずに済みます。日付は文字列ではなく、型を持つ値です。
1つの設定をTOML、YAML、JSONで
サンプルを選んでください。3つのバージョンはまったく同じデータを持っているので、各形式がそれをどう書き表すかを比べられます。
サンプルの設定
TOML
YAML
JSON
アプリ設定のサンプルでは、TOMLはopensを本物のローカル時刻として保存しますが、YAML版とJSON版では文字列のままです。
アプリの設定
パッケージのマニフェスト
サーバーの一覧
無料で始める · クレジットカード不要
関連: ガイド｜Webマーケティングと集客を学ぶ
製品
ご利用いただける方
機能
リソース
会社情報
サイトマップを見る