TOON が他のフォーマットよりも優れている理由
LLM アプリケーション、特に大規模なデータセットを消費する検索拡張生成 (RAG) システムまたはエージェントを構築している場合は、トークン コスト と コンテキスト ウィンドウの制限 という 2 つの面で絶えず戦争を繰り広げている可能性があります。
長年にわたり、JSON はデータ交換のデフォルトの共通言語でした。 これは人間が（ほとんど）判読可能であり、どこにでもあります。 しかし、500 行の JSON 配列をプロンプトに貼り付けると、特定の行のセマンティック値がゼロである繰り返しフィールド名 ("id":、"name":、"email":) に何千ものトークンが書き込まれます。
トゥーンと入力してください。 これは、LLM 入力における S/N 比の問題を解決するために特別に設計された形式です。 最新のベンチマークを調査してきましたが、その結果は驚くべきものでした。TOON は単にスペースを節約しているだけではありません。 実際、GPT-5-nano や Gemini-2.5-flash などのモデルがデータを_より良く理解するのに役立ちます。
TOON が有力企業 (JSON、CSV、YAML、XML) に勝っている理由を分析し、生の数字を見てみましょう。
冗長性の罠: JSON 対 TOON
トークン効率の最大の敵は構造の繰り返しです。 標準の Time-Series Analytics データセットを見てみましょう。 JSON では、すべての単一データ ポイントがそのスキーマの荷物を運びます。
JSON (標準) ベンチマークで使用されたトークン: 22,250
それはとても無駄なスペースです。 次に、TOON に相当するものを見てください。 TOON はヘッダーでスキーマを定義し、その後、値の高密度の CSV スタイルのレイアウトに切り替えます。
トゥーン ベンチマークで使用されたトークン: 9,120
結果: トークンの使用量が大幅に 59.0% 削減されました。
TOON では、繰り返されるキーを取り除くことで、より多くの履歴をモデルのコンテキスト ウィンドウに収めることができます。 ただし、CSV とは異なり、ヘッダー定義 metrics[5]{...} を通じて型認識と明示的な構造が維持されることが重要です。
CSV を使用しないのはなぜですか?
これは最も一般的な反論です。 「フラットなデータが必要な場合は、CSV を使用してください。」
問題は、現実世界のデータが完全に平坦であることはほとんどないことです。 CSV は、ネストされた構造、オブジェクト内のリスト、またはカンマや引用符を含む複雑な説明を含む瞬間に完全に機能しなくなります。
ベンチマーク、特に 混合構造トラック (電子商取引の注文とイベント ログを含む) では、CSV は非可逆平坦化なしではデータを表現できないため、完全に除外されました。
TOON はこれを丁寧に処理します。 配列を最適化しながら、ネストされたオブジェクトが可能になります。 100 個の GitHub リポジトリ (テキストの説明とメタデータが混在している) のテストでは、効率の差は明らかでした。
- JSON: 15,145 トークン
- TOON: 8,745 トークン (42.3% 節約)
JSON Compact (縮小版) に対してさえ、TOON はさらに 24% 近く多くの節約を実現しました。 100 万トークンごとに支払うと、それが即時の ROI となります。
精度: 意外な勝者
ここが私が驚いた部分です。 通常、データを圧縮すると、明瞭さが失われます。 LLM は、より密度の高い形式を解析するのに苦労することが予想されます。 ベンチマークはその逆を示しています。
Claude Haiku、Gemini Flash、GPT-5-nano などのモデルでテストされた 209 のデータ検索質問全体で、TOON は 73.9% の検索精度**を達成しました。これに対し、標準 JSON の 69.7% でした。
なぜ？ おそらく、認知負荷 (または LLM に相当するもの) に帰着します。
- ノイズの軽減: モデルは、何千もの反復する「key」` トークンに注意を払う必要がありません。 関連する値は、注意メカニズム内でより近くなります。
- 明示的なメタデータ: TOON ヘッダーには、カウント (
[N]) とフィールド名が明示的に含まれます。
- 構造認識: データセットの構造について尋ねるテスト (例: 「行は何行ありますか?」) では、TOON は 88% の精度を達成しましたが、JSON と XML は遅れをとっていました。 TOON ヘッダー (
repositories[100]) の明示的なカウントは、LLM が苦手とすることで有名な、モデルが手動でトークンを「カウント」する必要を防ぐヒントとして機能します。
XML と YAML の疲労
他の候補者についても簡単に言及しておきます。
XML はここで大きな敗者です。 冗長で読みにくく、処理にコストがかかります。 ベンチマークでは、XML が一貫して最も多くのトークンを使用し (TOON が約 2,700 で表す統一従業員レコード セットに対して 5,000 以上)、精度は最も低かった (67.1%)。
YAML は XML よりもパフォーマンスが優れていますが、それでも TOON に比べてトークンの肥大化に悩まされています。 YAML は人間による構成ファイルには最適ですが、空白に依存する性質とキーの繰り返しが多いため、大容量のデータ コンテキストには最適とは言えません。 「電子商取引の注文」テストでは、YAML は TOON よりも最大 14% 多くのトークンを使用しました。
いつ切り替えるか?
データはかなり決定的です。 次のような問題を扱っている場合:
- オブジェクトのリスト: ログ、トランザクション履歴、検索結果、または製品カタログ。
- RAG パイプライン: DB からデータのチャンクを取得してプロンプトにフィードします。
- 大容量 API: 帯域幅と遅延が重要な場合。
TOON は、「両方の長所を生かした」シナリオを提供します。 JSON の構造的整合性を備えた CSV の密度が得られます。
ベンチマークでは、GPT-5-nano は TOON 形式のデータで驚異的な 90.9% の精度を達成しました。 これは、より新しい、よりスマートなモデルがこれらの最適化された形式の解析にますます熟練していることを示唆しています。これは、マシンにとって JSON から離れることによる「可読性のペナルティ」が事実上ゼロであることを意味します。
RAG コンテキストを依然として「JSON.stringify(data, null, 2)」としてフォーマットしている場合、事実上、単一の API 呼び出しごとに「可読性税」を支払っていることになります。 フォーマットを切り替える時期が来たのかもしれません。