【技術用語調査】TOON

調査のきっかけ

大規模言語モデル（LLM）を活用したAI技術が注目される中で、AI用途に最適化された新しいデータ形式「TOON」が頻繁に目にするようになったので、調査した。

定義・概要説明

用語: TOON（Token-Oriented Object Notation）
分類: データ形式（フォーマット）
主な分野: 大規模言語モデル（LLM）とその入出力データ管理
初出・提唱者: 2020年代半ば頃、AIのトークン効率向上を目指すコミュニティや企業により提唱

TOONは、LLMが扱いやすく、APIのトークン使用量を削減するために設計された新世代のデータ形式のこと。JSONやYAMLのような従来のデータ形式が持つ冗長性を排除し、トークン消費を30〜60％以上削減しながらデータの構造や意味を保つことが特徴となっている。

読み方は「トゥーン」。
読み方を聞いて、別なことを連想する人が多いはず。俺は遊戯王のペガサス・J・クロフォードが使ったトゥーン・ワールドが脳裏から離れない。

構造・仕組み

TOONはトークン効率を最大化することに重点を置いているため、以下の仕組みを持ちます。

データのキー（フィールド名）を一度だけ宣言し、その後はCSVのような値の並びで表現。
配列の長さとフィールドスキーマ（フィールド名の一覧）を明示的に書き、冗長なキー表記を排除。
YAML形式のインデントにより階層構造を表現しつつ、配列などの複雑なデータはより簡潔な表形式で記述。
LLMがトークン単位で読みやすい形でデータを整理し、トークン消費を最小化。

例

「トムの勝ちデース」をjson的な表現とTOON的な表現で比較してみた。　

{
  {id: 1,name: Pegasus,role: admin},
  {id: 2,name: Tom, role: winner},
  {id: 3,name:Keith, role: loser}
}

上記JSONをTOONで表すと以下になる

users[3]{id,name,role}:
1,Pegasus,admin
2,Tom,winner
3,Keith,loser

確かに削減されているのは、視覚的に分かるが、jsonよりは人間には分かりにくくなったという印象。

geminiさんにトークン数がどうなるか聞いた感じだと以下。
一般的なLLMの一つであるGPTモデルのトークナイザー（例：cl100k_base）を仮に適用した場合の目安という話だったので、使うトークナイザー次第では変動あるかもだが、大きくブレることはないと思われる。

形式	文字数 (スペース・改行を除く)	トークン数 (概算)	削減の理由
JSON	94文字	約 35〜45 トークン	冗長な記号とキー名の繰り返し
TOON	56文字	約 20〜30 トークン	スキーマ宣言と記号の削減

約30%程度の節約になりそう。

メリット・デメリット

観点	メリット	デメリット
性能	トークン消費を大幅削減し、処理速度とコスト効率向上	専用フォーマットのため既存エコシステムとの互換性は低い可能性
開発効率	データ量削減によりAPIコール負荷を軽減	習熟までにフォーマット理解の学習コストが必要
保守性	フィールド構造が明確で一貫した運用が可能	柔軟性がJSONほど高くない場合がある

関連技術・比較

類似技術: JSON, YAML
対比される概念: JSONの冗長を排した新世代データフォーマット
補完し合う技術: LLM用のトークン管理ツールやプロンプト最適化フレームワーク

選択基準として、トークン消費がコストやパフォーマンスに直結するLLM連携アプリではTOONが有利であり、一般的な用途や既存ツール連携ではJSONやYAMLが依然として有用である理解でいる。
調査した内容から自分なりの答えをだすと、TOONが出てきたらといって、JSONは不要なんてことにはならないと思う。
WebAPIは、依然としてJSON利用が多い状態になるはず。ただ、利用者想定がAIとかになってくると、レスポンスとしてTOONを返すAPIが出てきそうな気がする。

疑問：TOONよりCSVの方がいいのでは？

TOONのことを調べてるうちに、「これって、csvの方がトークン圧縮できるのでは？」と感じたので、調査の途中だったが、情報収集を実施した。

調べた結果をまとめると下記の通り。

単純でフラットな表形式データならCSVが最適でトークン効率も良いが、LLMに渡す複雑な構造付きの表データやネストを扱う場合はTOONが有効になる。
CSVはシンプルであるが、データの構造や型を厳密に定義していない。この曖昧さが、LLMの推論エラーを引き起こす要因になり、ハルシネーションを起こすリスクが上がる。

特徴	TOON (Token-Oriented Object Notation)	CSV (Comma-Separated Values)
主な目的	LLMへの入力データの最適化、トークン削減	表形式データの汎用的な保存・交換
データ構造	ネスト（階層構造）を表現可能 (YAML的な構造)	基本的に平坦な表形式（フラット）のみ
メタ情報/スキーマ	配列長やフィールド定義を明示	ヘッダー行にフィールド名がある程度
LLMの理解度	高。明示的な構造によりハルシネーション（誤認識）抑制効果がある	中。構造が不明確で、区切り文字や値の解釈で誤りが生じやすい
冗長性	低。キー名や記号を一度しか書かないためコンパクト	低。データ値のみを区切り文字で並べるためコンパクト

|汎用性|比較的低。主にLLMパイプライン向け|高。ほぼすべてのシステムで読み書き可能|

JSONのデータ表現を残しつつ、CSVのようなシンプルな表現をしたかったために生まれたものと認識。JSONとCSVの中間が欲しかったという感覚でいる。
そのうち、用途によってデータ形式が分かれるような気がしてる。日本の電子決済が増えたみたいな感覚でボコボコ形式が増えるのではないかという気がした。

実際の使用例

AIチャットやテキスト生成APIで、ユーザーデータや文脈情報をTOON形式で管理し、API呼び出し時のトークン数を削減してコストと処理時間を圧縮するケースが増えつつある。

注意点・よくある誤解

TOONは従来のJSONやYAMLとは互換性がないため、変換や専用パーサが必須。
トークン削減効果が大きい反面、フォーマットの自由度は低く柔軟性に制約がある。
まだ新しいため、エコシステムやツールの整備は進行中。

所感・まとめ

データ形式ついて理解できたが、CSVとの差別化点があまり納得はできてない。
TOON見たとにCSV見ると、そこまで構造情報があるように見えないのだが、ちょっとした違いがLLMで読むこむ際は重要らしい。出力にどれくらい影響があるのか分かってないので、差別化点になっているのか判断できてないのだろうと感じてる。
実際にCSV食わしてLLM構築してないので、本当にそうなのかが分からないってのがモヤッてる理由だと思う。

JSONよりは記載量が少ないってのは明白なので、トークンが削減できますってのは、理解できたし直感的にも分かりやすい。
JSON見てると、すごい冗長だなって思うことはよくある。
ただ、それが障害対応とかで解析する際に分かりやすいってのはあるので、必ずしも、すべてのケースでTOONがいいってわけではない。
とりあえず、JSONの知識が無駄にならないって理解できたのでホッとしている。

TOON使うかと言われると、まだ手は出せないかなと思ってる次第。
パースできるライブラリも少ないみたいだし、利用用途がLLM向けなので、自分は該当しにくい気がしてる。LLMを本格的にカスタマイズしたり、ゼロから作ってみたいとかあれば使うかも知れないが、現状だと利用は考えてない。