JSON — 機械にとって最も扱いやすい標準
JSON は 3 つの中で最も厳密かつシンプルな文法を持ちます。ダブルクォート文字列・コメントなし・末尾カンマなし・型は string / number / boolean / null / object / array のみ。結果として、曖昧さのないパース、ほぼ全言語のサポート、そして「当たり前のように動く」ツール群が手に入ります。一方、手書きには向かず（引用符・カンマが煩雑）、コメントが書けないため別ファイル README やキー名による疑似コメント（'_comment'）が必要になります。
YAML — 読みやすいが、インデント事故が痛い
YAML は記号を減らしてインデントで構造を表し、値の見た目から型を推論します（'yes' → bool、'01' → 8 進数、'3.14' → float）。小さな設定では美しく読めますが、規模が大きくなると 1 行のインデントずれが意味を静かに変えてしまいます。文字列の暗黙キャスト（有名な「ノルウェー問題」: 国コード 'NO' が false になる）も本番事故の原因になります。YAML 1.2 で一部緩和されましたが、多くのパーサが 1.1 デフォルトのままです。
TOML — 設定ファイル特化
TOML（Tom's Obvious Minimal Language）は設定ファイル専用に設計されました。INI 風のセクション・コメント対応・曖昧でない型（NO → false の罠なし）を持ち、インデントルールなしでも綺麗に読めます。Rust の Cargo・Python の pyproject.toml・Go の modules はすべて TOML を使います。トレードオフとして、深いネスト構造には向かず、配列テーブル構文が冗長になりがちです。
コメント対応
JSON にコメント構文はありません。YAML は '#' で行コメントが書けます。TOML も '#' で行コメントが書けます。注釈・廃止予定キー・ドキュメントリンクをコメントで残したいケースでは、JSON は不格好なワークアラウンドが必要になり、YAML と TOML が有利です。
型システム
- JSON: string / number / boolean / null / object / array。日付型なし、整数/浮動小数の区別なし。
- YAML 1.2: 上記＋timestamp、ただし暗黙の型推論があり驚きが多い。
- TOML: string / integer / float / boolean / datetime（タイムゾーン付き）/ array / table。明示的かつ強い型付け。
エラー耐性
JSON のパーサはどのバイトでエラーが起きたかを正確に指してくれるため、デバッグが最も楽です。YAML のエラーはインデント問題が連鎖して曖昧になりがちで、メッセージから原因に辿り着くのが難しいことで悪名高いです。TOML は文法が厳密なため、JSON に近い品質のエラー表示が得られます。
用途別の推奨
- システム間の通信フォーマット（API・マイクロサービス）: JSON。
- ツールの設定ファイル（Linter、ビルドツール、パッケージマネージャー）: TOML。
- 階層が深いアプリ設定（Kubernetes マニフェスト、GitHub Actions、Ansible）: YAML（厳密パーサーを固定し、暗黙の型推論を避ける）。
- 人間が編集しないデータ交換: JSON。
- 人間が頻繁に編集する小規模設定: TOML、または注意深く書かれた YAML。