TOONってなんだろう?

概要

最近 Twitter で TOON 使おうぜという話題をちらほら見かける。
なんか LLM に最適化されたデータフォーマットらしいが、何も分からんので調べてみる。

TOON って何者?

公式によると

トークン指向オブジェクト表記法（Token-Oriented Object Notation）は、JSONデータモデルをコンパクトかつ人間が読める形式でエンコードしたものです。トークンを最小限に抑え、モデルが構造を理解しやすくします。LLMの入力として、既存のJSONをそのままロスレスで表現することを目的としています。

TOONは、YAMLのインデントベースのネストされたオブジェクト構造と、CSVスタイルの表形式レイアウトを組み合わせた、ユニフォーム配列です。TOONの優れた点は、オブジェクトのユニフォーム配列（行ごとに複数のフィールド、項目間で同じ構造）であり、CSVのようなコンパクトさを実現しながら、LLMによるデータの解析と検証を確実に行うための明示的な構造を追加します。

つまりデファクトスタンダートである JSON に対し、より LLM にて入出力を行う際のトークン消費量を削減出来るフォーマットとのこと。
何となく JSON の派生型と思っていたが、YAML と CSV の長所を受け継いだ別個のフォーマットらしい。

とりあえず見てみる

公式で JSON との比較例が公開されていたため見てみる。
まずは標準的な JSON 形式。

{
  "context": {
    "task": "Our favorite hikes together",
    "location": "Boulder",
    "season": "spring_2025"
  },
  "friends": ["ana", "luis", "sam"],
  "hikes": [
    {
      "id": 1,
      "name": "Blue Lake Trail",
      "distanceKm": 7.5,
      "elevationGain": 320,
      "companion": "ana",
      "wasSunny": true
    },
    {
      "id": 2,
      "name": "Ridge Overlook",
      "distanceKm": 9.2,
      "elevationGain": 540,
      "companion": "luis",
      "wasSunny": false
    },
    {
      "id": 3,
      "name": "Wildflower Loop",
      "distanceKm": 5.1,
      "elevationGain": 180,
      "companion": "sam",
      "wasSunny": true
    }
  ]
}

これは友人とハイキングへ行った思い出を記録したデータ。
構造はざっくりこんな感じ。

• context: テーマや場所、季節などのメタ情報(「Boulder」「spring_2025」など)
• friends: 一緒に行った友人の一覧("ana", "luis", "sam")
• hikes: 各ハイキングの記録(id, name, distanceKm, elevationGain, companion, wasSunny)

確かに改めてみると冗長で可読性も悪く感じる。
(ただ明示的に構造化されたデータという面では寧ろ LLM のデータ理解には良さそうな気も...?)

このデータを YAML で表現してみると以下になる。

context:
  task: Our favorite hikes together
  location: Boulder
  season: spring_2025

friends:
  - ana
  - luis
  - sam

hikes:
  - id: 1
    name: Blue Lake Trail
    distanceKm: 7.5
    elevationGain: 320
    companion: ana
    wasSunny: true
  - id: 2
    name: Ridge Overlook
    distanceKm: 9.2
    elevationGain: 540
    companion: luis
    wasSunny: false
  - id: 3
    name: Wildflower Loop
    distanceKm: 5.1
    elevationGain: 180
    companion: sam
    wasSunny: true

格段に JSON よりも可読性が高くなっている！
特にインデントベースの構造が直感的な理解を助けている気がする。
トークン的な面ではブレース分のトークン消費量が削減されている。

そしてこの可読性の高い YAML 形式に CSV の表形式を振りかけると

context:
  task: Our favorite hikes together
  location: Boulder
  season: spring_2025
friends[3]: ana,luis,sam
hikes[3]{id,name,distanceKm,elevationGain,companion,wasSunny}:
  1,Blue Lake Trail,7.5,320,ana,true
  2,Ridge Overlook,9.2,540,luis,false
  3,Wildflower Loop,5.1,180,sam,true

こんな感じになる。
構造的には

1. context
   • key:valueの集合
2. friends[3]
   • 配列構造で[3]の様に要素数を示す
3. hikes[3]{id,name,distanceKm,elevationGain,companion,wasSunny}
   • フィールドと要素数を宣言し、{...}でスキーマを宣言
   • 以降は各行 1 レコードでカンマ区切りに値を格納

つまりフィールド宣言の繰り返しと連続するブレースを省きトークン消費量を抑えているっぽい。
公式にはこの構造化により

TOON は、4 つのモデルにわたる混合構造ベンチマークで、トークンを約 40% 削減しながら、74% の精度 (JSON の 70%) を達成します。

40% 程のトークン消費量を削減出来るらしい。
精度的にも多少 JSON に勝っていそう?

いつ使うの?

トークン消費量の文脈で言うと csv の表形式が威力を発揮している?
csv は単一の表を表すのでデータの形式的には少し差異があるが、基本的には以下認識になった。

• 単一の表形式 -> CSVが最小トークン
• データに係るコンテキストと複数表 → TOONが総合的に有利
• 深いネストや可変構造 → JSONの構造が最も明確

具体的に TOON をいつ使いたいかというと...難しい。

まとめ

正直現状は JSON を使うかな〜
LLM 自体 JSON をスタンダードとして学習しているだろうし、明確にここに使いたいというシーンが思い浮かばない。
ただ現状はまだ発展途上のフォーマットなので、これからの最適化に期待しています！