🛺
LLM 時代のプロンプト管理――結局どのフォーマットがイケてるの？
評価フレームワーク（10 × 10 点）
| # | 軸 | ざっくり説明 |
|---|---|---|
| 1 | 可読性 | 自然文・階層の見やすさ |
| 2 | 書きやすさ | エスケープ頻度・タイポ耐性 |
| 3 | コメント | 公式に書けるか？ |
| 4 | 複数行文字列 | 長文プロンプトを素直に書ける？ |
| 5 | 文法エラー耐性 | スペース 1 個で崩壊しない？ |
| 6 | エコシステム | ライブラリ・ツールの量 |
| 7 | パース性能 | スピード命の API で有利か |
| 8 | 表現力 | アンカー等の高度機能 |
| 9 | 安全性 | RCE や仕様ギャップ |
| 10 | LLM 採用実績 | Cargo, pyproject など実戦投入度 |
各項目 0–10 点、合計 100 点で採点しました。
フォーマットをざっくりおさらい
JSON ― API 王者だけどお堅い
- 超 標準フォーマット。ほぼ全言語で即パース可
- 公式仕様でコメント禁止。「// ダメ、絶対」
- 構文が最小ゆえに高速パース
YAML ― 表現力モンスター
- アンカー & エイリアスで DRY な継承が可能
- ただし「タブ使用不可」。インデント 1 文字ズレたら死亡
-
!!python/object系で RCE 事故例も。SafeLoader 必須
TOML ― “人間のための設定ファイル”
- 2013 年に Tom Preston-Werner 氏が公開、2021/01 に v1.0 で安定化
- Rust の
Cargo.tomlで一気に知名度 UP - Python 3.11 から標準モジュール tomllib で読み取りネイティブ化
-
pyproject.tomlは PEP 518 公式仕様としてビルド設定を統一
採点結果とコメント
| 軸 | JSON | YAML | TOML |
|---|---|---|---|
| 可読性 | 7 | 8 | 9 |
| 書きやすさ | 7 | 6 | 9 |
| コメント | 2 | 10 | 10 |
| 複数行文字列 | 5 | 10 | 9 |
| 文法エラー耐性 | 8 | 5 | 8 |
| エコシステム | 10 | 9 | 7 |
| パース性能 | 10 | 6 | 9 |
| 表現力 | 7 | 10 | 6 |
| 安全性 | 9 | 5 | 9 |
| LLM 実績 | 9 | 8 | 8 |
| 合計 | 74 | 77 | 84 |
- JSON — 速い・道具が多い。でもコメント書けないのは痛い。
- YAML — 表現力最強。ただし “スペース厨” と “脆弱性おじさん” が同居。
- TOML — 読みやすさと安全性が高バランス。表現力は控えめだが LLM 用のテンプレ管理には十分。
10 項目×10 点＝100 点でガチ採点してみたら、総合トップは TOML 84 点、次点に YAML 77 点、そして JSON 74 点。
「コメント不可の JSON」と「インデント地獄の YAML」のあいだを TOML がスルッと通り抜けた、という結果になりました。
プロンプトエンジニアはこう使い分ける
🎯 小～中規模テンプレをチームで回す
→ TOML 一択。# で気軽にメモを残せて、インデント事故ゼロ。
🚀 超高速 API 呼び出し & 自動生成
→ JSON 継続利用。機械同士の会話ならコメント不要、エコシステムの旨味を最大化。
🏗️ 巨大 IaC 的テンプレ & 継承地獄
→ YAML。アンカーで共通プロンプトを継承。ただし CI に yamllint & SafeLoader を必ず仕込むべし。
まとめ
- 「コメント不可 vs インデント地獄」問題を TOML が中和
- Rust/Cargo や Python/pyproject が後押しし、LLM 用フォーマットとしても採用例が拡大中
- YAML は表現力、JSON はスピードとツール、それぞれの牙城は固い
- 結論: 迷ったら TOML、特定用途は JSON/YAML と三すくみで使い分けよう！
Zenn で記事書くときも --- で区切りまくってサクサク読める TOML っぽさを取り入れてみると、読者体験がワンランク上がるかもしれません。
Discussion