「高コスト」な JSON の先へ：LLM パイプラインにおける TOON の実務とトレードオフ

XML から JSON、そして LLM 前提の表現へと、シリアライズは「人間が読む」ことと「モデルが扱うコスト」の間で揺れ続けています。TOON（Token-Oriented Object Notation）は LLM 向けのコンパクト表現として注目されていますが、本稿では 実装と運用 に焦点を当て、Token 削減、ネストとモデル差、変換・解析の CPU を切り分けます。

注：以下の割合・遅延・トークン数は 代表的なサンプルに基づく示意 です。自社データと tokenizer で必ず再測定してください。

要約

TOON は JSON の冗長な区切りを減らし、ヘッダ + 行 型のレイアウトで同質のコレクションを圧縮しやすくします。LLM 入力側の投影として有効ですが、公開 REST API や正規データの保存形式として JSON を置き換えるものではありません。

---

1. 見落としがちな情報コスト

深いネストと注意予算

JSON の {}・引用符・: は tokenizer とコンテキストにそのまま乗ります。深いネストや AST 断片では、構文がノイズになり、括弧整合の負荷も増えがちです。

TOON は繰り返し構造でフィールド名を行間で共有できますが、層ごとに形が異なると 宣言コスト が利益を食います。

tokenizer 差

同じバイト列でもモデルごとにトークン数は変わります。大語彙モデルでは短い記号が相対的に有利に見えたり、長文モデルでは列揃えの効き方が変わったりします。一律の削減率は存在しません。

---

2. JSON / YAML / TOON の比較軸

---

3. 三つの落とし穴

1. 深い異種ネストでは優位が縮む

AST 的・多態的リストでは JSON のままが現実的、という判断が多くなります。

2. モデル間の理解度差

OSS/ローカルで行揃えが不安定なら JSON 優先。フラッグシップでコストと精度のゲートを通した上で TOON を検討。

3. 変換・解析の CPU

ゲートウェイ高頻度パスではキャッシュやオフライン変換を検討。

---

4. 例：EC 注文リスト

{
  "order_id": "992831",
  "items": [
    {"sku": "A12-B", "price": 99.0, "qty": 1},
    {"sku": "C34-D", "price": 45.5, "qty": 2},
    {"sku": "E56-F", "price": 12.0, "qty": 5}
  ],
  "customer": "John Doe"
}

order_id: 992831
items[3]{sku, price, qty}:
  A12-B, 99.0, 1
  C34-D, 45.5, 2
  E56-F, 12.0, 5
customer: John Doe

ブラウザは TOON をネイティブ解析しないため、BFF/ゲートウェイで JSON 往復しキャッシュとフォールバックを設計。

---

5. FAQ

Q1: TOON を使うとハルシネーションが増えますか？

列定義（ヘッダ）が明確で、列数とデータ型が揃っている場合は、JSON 時と同等のフィールド一致度になりやすいです。一方、ヘッダを省いた極小表記は、スキーマがコードとプロンプトの双方で固定されている場合に限定してください。

Q2: レイテンシのボトルネックはどこですか？

現状は JSON→TOON の変換とパーサ実装 に寄りがちです。巨大ペイロードはエッジで毎回変換せず、静的コーパスはオフライン変換、動的レスポンスはキャッシュ層で TOON 化するのが無難です。

Q3: 多態（フィールド集合が行ごとに違う）な配列は？

TOON の強みが薄れます。JSON に戻すか、スキーマごとにテーブルを分割してください。

---

6. 選定指針

• • JSON を選ぶ：公開 API、JSON Schema による契約テスト、深い異種ネスト、検証リソースが限定的、Llama 系などで TOON を十分に検証していない場合。

• • TOON を検討：トークン課金とコンテキスト上限が支配的で、データが同質テーブル型に寄っており、モデル別の精度回帰が済んでいる場合。

---

関連ツール

• • JSON ⇄ TOON コンバーター

• • JSON ビューティファイア

• • JSON バリデーター

• • JSON ミニファイア

まとめ：TOON は JSON の後継ではなく、LLM コンテキスト向けの圧縮投影。トークン意識の表現設計が単一の削減率より重要です。