TOML（Tom's Obvious, Minimal Language）は2013年にGitHub共同創業者のTom Preston-Werner氏が提案した設定ファイル向け言語で、INIファイルの読みやすさを受け継ぎつつ、明確な型システムと階層構造を導入したのが特徴だ。現行仕様は2021年公開のTOML 1.0.0で、Rustのcargo・PythonのpyprojectおよびPoetry設定・Hugo・JuliaのProject.tomlなど、開発者向けエコシステムを中心に標準位置を確立している。
この記事の目次
- TOMLの基本構文と型
- なぜpyproject.tomlが選ばれたのか
- YAML・JSONとの比較ポイント
- TOML採用時の注意点
- まとめ
TOMLの基本構文と型
TOMLはkey = valueの単純な代入を基本とし、[section]ヘッダで階層を区切る。ドット記法でネストが書け、[server.database]のようにツリー状の設定を直感的に表現できる。配列は[1, 2, 3]、テーブル配列は[[items]]ヘッダを繰り返す形で表す。型は文字列・整数・浮動小数・真偽値・日時（RFC 3339）・配列・テーブルが標準でサポートされる。
整数の表現には十進数だけでなく0x（16進）・0o（8進）・0b（2進）を扱え、桁区切りアンダースコアも記述できる。日時もLocal Time／Local Date／Offset Date-Timeなど複数の粒度が標準で定義されており、YAMLで悩む型推論の曖昧さがほぼ存在しない。「読みやすく、かつ機械にも厳密」という設計が現代の開発者文化と合っている。
なぜpyproject.tomlが選ばれたのか
Pythonコミュニティが2017年のPEP 518で導入したpyproject.tomlは、setup.py時代のPython実行任意性の問題（ビルド前にsetup.pyが実行され副作用を起こす）を解決する目的があった。TOMLが選ばれた理由は、INIより型が豊富で、YAMLより仕様が単純、JSONより人間可読、という条件を満たす唯一の選択肢だったためである。
Rust界ではCargo.tomlが2014年から採用され、依存関係のバージョン指定・プロファイル・workspaceなど複雑な構造をTOMLで宣言する。シンプルな構文ながらテーブル配列や日時型まで揃っているため、設定言語としての表現力に不足はない。Hugoのconfig.toml、Juliaのプロジェクト管理、Black・isortなどフォーマッタの設定など、開発者ツールでTOMLを使うのが2020年代以降のスタンダードとなった。
YAML・JSONとの比較ポイント
TOMLはYAMLと比べてインデントへの依存がなく、見た目はINIに近い。リスト中心の深いネストはやや書きにくい反面、設定項目が平坦に並ぶケースでは抜群に読みやすい。型推論の罠もほぼなく、yes/noがboolに勝手変換されるYAMLの「Norway問題」のような事故が起きにくい。
JSONとの違いはコメントが書けることと、日時など設定でよく使う型が標準化されている点だ。一方で複雑なネストや動的構造を書こうとするとテーブル配列の表記がやや独特で、Kubernetesのような多次元構造には向かない。「ドキュメント指向ならYAML、設定指向ならTOML」と棲み分けるのが実務感覚として近い。
TOML採用時の注意点
TOMLはバージョン差に注意したい。1.0.0以前のドラフト仕様で書かれたファイルを現行パーサで読むと、Inline Tableのカンマ末尾やDotted Keyの解釈が異なる場合がある。ツールが採用しているバージョンを確認し、必要に応じてマイグレーションする。
また、設定が肥大化したときに分割しにくい点はTOMLの弱点だ。YAMLのアンカーやJSONのインクルード相当の仕組みがないため、共通設定の再利用はビルド時のテンプレートエンジン側で解決する必要がある。テストを書きにくい性質も含め、設定ファイルが数百行を超えてきたらYAMLや汎用言語ベースの構成管理ツール（Pulumi、CDKなど）への移行を検討するタイミングとなる。
まとめ
TOMLはINIの単純さとモダンな型システムを両立した設定言語で、pyproject.tomlやCargo.tomlを通じて開発者文化の中心に定着した。型の曖昧さがないため運用ミスが起きにくく、小〜中規模の設定では最良の選択肢である。用途と規模に応じてYAMLや汎用ツールと使い分けるのがコツだ。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント