【TOON】JSON時代の終わり？話題のTOONを解説してみた

Posted at 2025-11-17

はじめに

LLMのAPIコストが気になったことはないだろうか。プロンプトに大量のデータを渡すと、トークン数が爆発してコストもレスポンスも悪化する。

その原因の一つがJSONだ。JSONは人間が読みやすいように設計されているため、記号や繰り返しが多い。LLMにとっては無駄が多い形式になっている。

そこで登場したのが「TOON（Token-Oriented Object Notation）」。LLM専用に最適化されたデータフォーマットで、JSONと比べて30〜60%のトークンを削減できるらしい。

この記事では、TOONの何がすごいのか、どう使えばいいのかを、具体例を交えて解説する。

JSONの何が問題なのか

具体例で見てみる。商品データをJSONで表現するとこうなる。

{
  "products": [
    { "id": 301, "name": "Mouse", "price": 29.99 },
    { "id": 302, "name": "Keyboard", "price": 89.00 },
    { "id": 303, "name": "Hub", "price": 45.50 }
  ]
}

問題は明らかだ。"id":、"name":、"price":というキー名が、商品の数だけ繰り返されている。

100個の商品があれば、このキー名だけで300回も同じ文字列を送ることになる。これがトークンの無駄遣いだ。

TOONの書き方

TOONは、この繰り返しを削除する。フィールド名を最初に一度だけ宣言し、あとは値だけを並べる。

同じデータをTOONで書くとこうなる。

products{id,name,price}:
  301,Mouse,29.99
  302,Keyboard,89.00
  303,Hub,45.50

たったこれだけ。

何が起きたか:

キー名（"id":、"name":、"price":）を1回だけ宣言
波括弧 {} の繰り返しを削除
引用符 " を最小化
カンマとコロンを最小化

結果、同じ情報を約40%少ないトークンで表現できる。

もう一つの例: ユーザーリスト

もっとシンプルな例を見てみる。

JSON:

{
  "users": [
    {"id": 1, "name": "Alice", "role": "admin"},
    {"id": 2, "name": "Bob", "role": "user"}
  ]
}

TOON:

users{id,name,role}:
  1,Alice,admin
  2,Bob,user

一目瞭然で、TOONの方が圧倒的に短く、読みやすい。

TOONの利点

1. トークン削減とコスト削減

LLMのAPIは、トークン数で課金される。TOONはJSONの冗長な記号を削ることで、同じ情報を30〜60%少ないトークンで送れる。

実測例:

GitHubリポジトリデータ（100件）: JSON 15,145トークン → TOON 8,745トークン（42%削減）
日次分析データ（180日分）: JSON 10,977トークン → TOON 4,507トークン（59%削減）

GPT-4oを使う場合:

入力: $5 per 1M tokens
出力: $15 per 1M tokens

で課金される。毎日100万トークンのデータをLLMに渡している場合、TOONに変えるだけで月75~150$のコスト削減になる。大規模なシステムなら、年間で数十万円から数百万円の差になる。

2. レスポンス高速化とコンテキスト活用

トークン数が減れば、LLMの処理時間も短くなる。特にRAGやエージェントのようにコンテキストウィンドウを大量に使うアプリケーションでは、レスポンスタイムの改善が体感できる。

さらに重要なのは、限られたコンテキストウィンドウをより有効に使えることだ。例えば128Kトークンのウィンドウで、JSONなら約200件の検索結果しか渡せないが、TOONなら約350件渡せる。より多くの情報を使えるため、LLMの回答精度が上がる。

3. 推論精度と検索精度の向上

構造化データをよりクリーンな形でLLMに提供することで、推論の質も向上する。JSONの冗長な記号や繰り返しは、LLMにとって「ノイズ」になる場合がある。TOONはこれを最小化し、データの本質的な構造を明確に示す。その結果、LLMがデータの関係性を正しく理解しやすくなる。

特にRAGシステムでの検索精度向上が報告されている。検索結果をTOON形式でLLMに渡すと、関連する情報を正確に抽出できる確率が高まる。表形式データでは、フィールド名と値の対応関係が明確になるため、LLMが誤解する余地が減るからだ。

実際の効果:

RAGでの関連情報抽出: JSON比で約15%精度向上のケースも
表形式データの集計・分析: フィールド名の誤認識が大幅に減少
複数データソースの統合: 構造の一貫性が保たれやすい

TOONが特に威力を発揮するのは、データベースのクエリ結果、RAGの検索結果、CSVのような表形式データ、ログデータ、時系列データなど、「同じフィールドが繰り返される」構造を持つデータだ。

4. JSONとの完全な互換運用性

TOONの重要な特徴の一つが、JSONとの完全な相互変換ができることだ。TOONで表現できるデータは、すべてJSONに戻せる。逆も同様。つまり、既存のJSON資産を捨てる必要はなく、必要に応じてTOONとJSONを行き来できる。

TOON ⇔ JSON の変換で情報が失われることはなく、数値や文字列などの型情報も保たれる。複雑なネスト構造もラウンドトリップ可能だ。この互換性により、APIはJSON、内部処理だけTOONという使い方ができる。

段階的な導入が可能なのも大きい。すべてを一度に切り替える必要はなく、効果が高い部分から徐々にTOON化していける。

図で理解: データの流れ

JSONは変換工程が多く、TOONは最初から効率的なフォーマットで流せる。シンプルな図だが、この違いがレイテンシとコストに直結する。

実際の使い方

JSONからTOONへの変換

TOONは、複数の言語で公式SDKが提供されている:

TypeScript/JavaScript: @toon-format/toon
Python: python-toon
.NET: NIZZOLA.TOON.NET
Elixir、R、Gleamなど

基本的な流れ:

import { stringify, parse } from '@toon-format/toon';

// JSONデータを用意
const data = {
  users: [
    { id: 1, name: 'Alice', role: 'admin' },
    { id: 2, name: 'Bob', role: 'user' }
  ]
};

// TOONに変換
const toonString = stringify(data);

// LLMに渡す
const prompt = `以下のユーザーデータから管理者を抽出してください:\n${toonString}`;

// LLMから返ってきたTOONを元に戻す
const result = parse(llmResponse);

導入パターン

推奨される導入方法:

LLMの入出力だけTOON化する
- 既存のシステムはJSON
- LLMに渡す直前にTOONに変換
- LLMから受け取った直後にJSONに戻す
- データの欠損なく往復できるため、既存システムへの影響ゼロ
段階的に広げる
- まずは最もトークンを消費している部分から試す
- 効果を測定してから範囲を広げる
A/Bテストを必ず行う
- JSONとTOONで精度やコストを比較
- 自社のデータで実測する

向き不向きと注意点

TOONが向いている場面

判断基準はシンプルだ。大量の表形式データをLLMに渡していて、LLM APIのコストが月数万円以上かかっているなら、試す価値がある。RAGシステムの検索結果を数十〜数百件LLMに渡すとき、データベースのクエリ結果をそのまま分析させるとき、ログや時系列データを処理するとき。こういった「同じフィールドが繰り返される」構造で、TOONの効果が最大になる。

コンテキストウィンドウの制限に困っているなら、さらに有力な候補だ。同じウィンドウサイズでも、より多くの情報を詰め込める。

TOONが向かない場面と注意点

一方で、TOONは万能ではない。

1. 複雑なネスト構造には弱い

TOONは表形式データに最適化されている。深くネストしたデータや、構造が不均一なデータには向かない。例えば、会社の組織図のように部門→チーム→メンバーと深くネストする構造では、JSONやYAMLの方が扱いやすい。

2. LLMがTOONに慣れていない

LLMは訓練データで大量のJSONを見ているが、TOONはほとんど見ていない。そのため、単純なデータ取得タスクではTOONが有利だが、複雑な推論タスクではJSONの方が精度が高い場合がある。独立系のベンチマークでは、ネストが深いデータでTOONの精度がJSONやYAMLより低いという結果も報告されている。

3. まだ標準化されていない

TOONは比較的新しい技術で、まだ業界標準ではない。エコシステムは成長中で、主要言語のSDKは揃っているが、ProtobufやJSONほど成熟していない。

4. 慎重になるべき場合

医療や金融など高精度が最優先のドメインでは慎重になるべきだ。LLM APIの使用量が少ない、あるいは既存システムへの統合コストが高い場合は、メリットがコストを上回らない可能性がある。

まとめ

TOONはJSONの代わりではない。LLMに渡すデータを効率化するための専用フォーマットだ。

TOONが解決するのは、LLM APIのトークン数とコスト、コンテキストウィンドウの制限、レスポンスタイムの改善といった実務的な問題だ。特に表形式データ（RAGの検索結果、DB結果、ログなど）を大量に扱う場合に効果が大きい。

一方で、深いネスト構造や複雑な推論タスク、高精度が最優先される場面には向かない。LLMはJSONに慣れているが、TOONにはまだ慣れていないからだ。

JSONの時代が終わるわけではない。TOONは、LLMとの境界で使う最適化ツールとして、JSONと共存する。導入は小さく始めて、効果を測定してから広げる。これがリスクを最小化し、メリットを最大化する賢い使い方だ。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

【TOON】JSON時代の終わり？ 話題のTOONを解説してみた