「LLM APIの利用料金が高すぎる…」「コンテキストウィンドウの上限にすぐ達してしまう…」
ChatGPTやClaudeなどの大規模言語モデル(LLM)を業務で活用するエンジニアやCTOの方々から、このような悩みをよく耳にします。実は、その原因の一つが「データフォーマット」にあることをご存じでしょうか。
本記事では、2025年に登場した新しいデータフォーマット「TOON(Token-Oriented Object Notation)」について徹底解説します。TOONを活用すれば、従来のJSONと比較して30〜60%のトークン削減が可能です。
この記事を読むことで、TOONの基本的な仕組みから実際の導入方法まで、初心者でもわかりやすく理解できます。LLM APIのコスト削減や、より多くのデータをコンテキストに含める方法を知りたい方は、ぜひ最後までお読みください。
TOON(Token-Oriented Object Notation)とは?
TOON(Token-Oriented Object Notation)とは、LLMへのデータ入力を効率化するために設計された新しいデータフォーマットです。
日本語では「トークン指向オブジェクト記法」と訳されます。2025年に登場し、GitHub上で20,000以上のスターを獲得するなど、開発者コミュニティで急速に注目を集めています。
TOONの最大の特徴は、JSONと同じデータ構造を表現しながら、使用するトークン数を大幅に削減できる点です。従来のJSONでは、波括弧 {}、引用符 "、繰り返されるキー名などが多くのトークンを消費していました。TOONはこれらの冗長な記号を極力排除し、LLMが解釈しやすい形式を実現しています。
【ポイント】TOONは「人間が読みやすい形式」から「モデルが理解しやすい形式」への発想転換を体現したフォーマットです。
TOONには以下の3つの設計思想があります。
- トークン効率の最大化:不要な記号や重複を削減
- スキーマの明示:配列の要素数やフィールド名を冒頭で宣言
- JSONとの完全互換:JSON→TOON→JSONの変換でデータ欠落なし
重要なのは、TOONはJSONを完全に置き換えるものではないという点です。あくまでLLMとのデータ受け渡しを最適化するための「翻訳レイヤー」として位置づけられています。既存のシステムはJSONのまま維持し、LLMに渡す直前だけTOONに変換するという使い方が推奨されています。
TOONが生まれた背景、JSONの課題
TOONが登場した背景には、JSONが抱える「LLM時代の課題」があります。ここでは、なぜJSONがLLMにとって非効率なのかを解説します。
JSONは「人間向け」に設計されたフォーマット
JSON(JavaScript Object Notation)は、2000年代初頭に登場したデータフォーマットです。人間にも読みやすく、機械にも処理しやすいバランスの良さから、Web APIのデータ交換形式として世界標準になりました。
しかしJSONは「人間が読むこと」も想定して設計されているため、LLMにとっては無駄な情報が多く含まれています。
LLMはトークン単位で処理する
LLM(大規模言語モデル)は、テキストを「トークン」という単位で処理します。トークンとは、単語や単語の一部、記号などを指します。
【補足】英語では1単語≒1トークン、日本語では1文字≒1〜2トークン程度が目安です。
LLM APIでは、入力トークン数に応じて料金が発生します。つまり、同じ内容でもトークン数が多いほど費用がかさむのです。
JSONがトークンを浪費する3つの理由
JSONがLLMで非効率な理由は、主に以下の3点です。
| 問題点 | 具体例 | 影響 |
|---|---|---|
| 冗長な構文記号 | {}、[]、""、: 、, | すべてがトークンとしてカウントされる |
| キー名の繰り返し | 配列内の全オブジェクトで同じキー名が出現 | データ量に比例してトークン増加 |
| 引用符の多用 | すべてのキーと文字列値に引用符が必要 | 実質的な情報量の2倍以上のトークンを消費 |
【具体例】以下は商品リストのJSONです。
{
"products": [
{ "id": 301, "name": "Mouse", "price": 29.99 },
{ "id": 302, "name": "Keyboard", "price": 89.00 },
{ "id": 303, "name": "Hub", "price": 45.50 }
]
}このJSONでは、"id"、"name"、"price" というキー名が3回ずつ繰り返されています。商品が1,000件になれば、同じキー名が1,000回繰り返されることになります。
このような冗長性が、LLM APIのコスト増加やコンテキストウィンドウの圧迫を引き起こしているのです。
TOONの特徴・メリット
TOONを導入することで得られるメリットは多岐にわたります。ここでは、主要な4つのメリットを詳しく解説します。
メリット1:トークン数を30〜60%削減できる
TOONの最大のメリットは、同じ情報量を圧倒的に少ないトークン数で表現できる点です。
公式ベンチマークによると、以下のような削減効果が報告されています。
| フォーマット | トークン数 | 削減率(Pretty JSON比) |
|---|---|---|
| Pretty JSON(整形済み) | 235 | — |
| 圧縮JSON(空白除去) | 142 | 約40%削減 |
| YAML | 170 | 約27%削減 |
| TOON | 106 | 約55%削減 |
実際の利用例でも、以下のような効果が確認されています。
- GitHubリポジトリのメタデータ100件:15,145トークン → 8,745トークン(42%削減)
- 日次分析データ180日分:約59%削減
メリット2:コンテキストウィンドウを有効活用できる
LLMには「コンテキストウィンドウ」と呼ばれる入力文脈の上限があります。TOONを使えば、同じウィンドウサイズでより多くの情報を詰め込めます。
【具体例】128Kトークンのコンテキストウィンドウの場合、JSON形式では約200件のデータしか渡せないところ、TOON形式では約350件を渡せたという報告があります。
この差は、RAG(検索拡張生成)システムにおいて特に重要です。より多くの関連ドキュメントをコンテキストに含められることで、回答精度の向上が期待できます。
メリット3:LLMの理解精度が向上する
JSONの繰り返し構造は、LLMにとって「ノイズ」になり得ます。TOONでは、フィールド名の宣言は一度きりで、以降はデータの値のみが並びます。
このクリーンな入力形式により、以下の効果が報告されています。
- RAGによる関連情報抽出:JSON使用時より最大15%精度向上
- 表形式データの分析:フィールド名と値の対応関係が明確になり、誤解が大幅に減少
- データ抽出タスク:46%トークン削減しながら99.4%の高精度を達成
メリット4:スキーマが明示されるため解析ミスが減る
TOONでは、配列の長さやフィールド一覧が先頭で宣言されます。
users[3]{id,name,role}:
1,Alice,admin
2,Bob,user
3,Carol,editorこの [3] や {id,name,role} という明示的な宣言により、「必ず3要素がある」「各行はid, name, roleの順で並んでいる」という情報がデータ自体に含まれます。
LLMがデータ構造を見誤るリスクが低減し、出力の信頼性向上にも寄与します。
TOONのデメリット・注意点
TOONには多くのメリットがありますが、万能なフォーマットではありません。導入前に知っておくべきデメリットと注意点を解説します。
デメリット1:深いネスト構造には不向き
TOONは「同じフィールド構造が繰り返されるデータ」で最も効果を発揮します。逆に、以下のようなデータでは効率が悪化する場合があります。
- 深くネストした複雑な構造
- オブジェクトごとにフィールド構成が異なる非定型データ
- 設定ファイルのような複雑な階層構造
【注意】極端な場合、TOONで表現しようとするとJSONよりトークン数が増えてしまうケースも報告されています。
デメリット2:LLMが学習データで見慣れていない
現在の主要LLM(GPT、Claude、Geminiなど)は、膨大なJSONやXMLを学習しています。一方、TOONは2025年に登場した新しいフォーマットのため、訓練データにはほとんど含まれていません。
そのため、以下の対策が必要です。
- プロンプト内で「これはTOON形式です」と明示する
- LLMに出力させる場合は、フォーマットを厳密に指示する
- 生成後にバリデーション・修正を行う仕組みを組み込む
【補足】入力データとしてTOONを使うことは問題ありません。出力フォーマットとして使う場合に注意が必要です。
デメリット3:エコシステムがまだ発展途上
JSONは数十年の歴史があり、あらゆる言語で高速なパーサーが提供されています。TOONは新しいフォーマットのため、以下の点で成熟度に差があります。
- 標準ライブラリへの組み込みはない
- 一部の言語ではサードパーティ実装のみ
- ベストプラクティスがまだ形成途中
ただし、TypeScript、Python、Go、Rust、.NETなど主要言語の実装は揃いつつあり、急速にエコシステムが成長しています。
デメリット4:可読性はJSONに劣る場合がある
TOONはコンパクトさを優先しているため、人間が直接読む場合はJSONより読みにくく感じることがあります。特に、デバッグやログ確認では引き続きJSONが適しているでしょう。
TOONとJSONの違いを徹底比較
TOONとJSONの違いを、具体的なコード例を交えて比較します。
基本的な構文の違い
| 要素 | JSON | TOON |
|---|---|---|
| オブジェクトの囲み | { } を使用 | インデントで表現 |
| キーと値の区切り | "key": value | key: value(引用符不要) |
| 配列の囲み | [ ] を使用 | [N] で要素数を宣言 |
| 文字列の引用符 | 必須 | 必要な場合のみ |
| 複数フィールドの区切り | , で区切り | 空白または改行 |
実際のコード比較
単純なオブジェクト
JSON
{ "id": 123, "name": "Ada", "active": true }TOON
id: 123 name: Ada active: trueネストしたオブジェクト
JSON
{
"user": {
"id": 123,
"name": "Ada"
}
}TOON
user:
id: 123
name: Ada配列(リスト)
JSON
{ "tags": ["foo", "bar", "baz"] }TOON
tags[3]: foo,bar,bazオブジェクトの配列(表形式データ)
JSON
{
"products": [
{ "id": 301, "name": "Mouse", "price": 29.99 },
{ "id": 302, "name": "Keyboard", "price": 89.00 },
{ "id": 303, "name": "Hub", "price": 45.50 }
]
}TOON
products[3]{id,name,price}:
301,Mouse,29.99
302,Keyboard,89.00
303,Hub,45.50この比較を見れば一目瞭然です。TOONでは、id、name、price というキー名が1回しか登場しません。データ行数が増えるほど、トークン削減効果は大きくなります。
トークン数の比較
上記の商品リストの例で、実際のトークン数を比較すると以下のようになります。
| フォーマット | トークン数(目安) |
|---|---|
| JSON | 約89トークン |
| TOON | 約45トークン |
| 削減率 | 約50% |
TOONの書き方・基本構文
TOONの基本的な構文ルールを、初心者にもわかりやすく解説します。
オブジェクト(連想配列)の書き方
波括弧を使わず、キー: 値 の形式で記述します。
id: 123
name: Ada
active: true複数のフィールドを1行にまとめることも可能です。
id: 123 name: Ada active: trueネスト(入れ子)の書き方
YAMLのように、インデント(字下げ)で階層を表現します。
user:
id: 123
profile:
name: Ada
email: ada@example.com配列の書き方
配列は キー[要素数]: 値1,値2,値3 の形式で記述します。
tags[3]: python,llm,data
numbers[5]: 1,2,3,4,5オブジェクト配列(表形式)の書き方
同じ構造のオブジェクトが並ぶ配列は、ヘッダー行とデータ行で表現します。
users[3]{id,name,role}:
1,Alice,admin
2,Bob,user
3,Carol,editor構文の意味は以下の通りです。
users:配列名[3]:要素数(3件){id,name,role}:各オブジェクトのフィールド名- 各行:カンマ区切りの値
区切り文字の選択
デフォルトはカンマ , 区切りですが、データ内にカンマが含まれる場合は、タブ \t やパイプ | を使うことも可能です。
# パイプ区切りの例
products[2]{name,description}|:
Mouse|A wireless optical mouse
Keyboard|Mechanical keyboard with RGB文字列の引用符
TOONでは、スペースやカンマなどの特殊文字を含まない単純な文字列は引用符不要です。
# 引用符不要
name: Alice
# 引用符が必要なケース
description: "Hello, World!"
message: "This is a test."TOONの活用例・ユースケース
TOONが特に効果を発揮する具体的なユースケースを紹介します。
ユースケース1:プロンプトへのデータ埋め込み
LLMにテーブルデータやリスト構造の情報を渡す際、プロンプト内にJSONをそのまま埋め込むとトークンを大量に消費します。
【具体例】ユーザー情報の一覧から管理者を抽出させるプロンプト
以下のユーザーデータから管理者を抽出してください:
```toon
users[100]{id,name,role,department}:
1,Alice,admin,Engineering
2,Bob,user,Sales
3,Carol,admin,Marketing
...(以下省略)ユースケース2:LLM APIの入出力最適化
既存システムでは内部的にJSONを使いつつ、LLMとやり取りする直前・直後だけTOONに変換するパターンが推奨されています。
[アプリケーション]
↓ JSON
[変換レイヤー] → TOON に変換
↓ TOON
[LLM API]
↓ TOON(または JSON)
[変換レイヤー] → JSON に変換
↓ JSON
[アプリケーション]この方法なら、アプリケーション内部は従来通りJSONのまま保てます。
ユースケース3:RAG(検索拡張生成)システム
RAGシステムでは、外部データベースから取得した検索結果をLLMに渡します。TOON形式に整形してから渡すことで、以下の効果が得られます。
- より多くの検索ヒットを一度に渡せる
- 各項目の属性(タイトル、日付、要約など)が明確になる
- LLMが関連情報を見つけやすくなる
実際に、JSON使用時より関連箇所を正しく抽出できる確率が上がったという報告もあります。
ユースケース4:チャットボットの文脈保存
長い対話履歴やユーザープロファイル情報をTOONで保持すれば、同じ内容でもより少ないトークンでコンテキストに渡せます。長時間の対話でもウィンドウ上限に達しにくくなります。
ユースケース5:ログデータ・時系列データの分析
センサーデータやエラーログなど、項目が固定された時系列データの分析にも有効です。
TOONの導入方法(ツール・SDK紹介)
TOONを実際に導入するためのツールとSDKを紹介します。
公式SDKの一覧
TOONは主要な言語向けに公式・コミュニティ実装が提供されています。
| 言語 | パッケージ名 | インストール方法 |
|---|---|---|
| TypeScript/JavaScript | @toon-format/toon | npm install @toon-format/toon |
| Python | toon-python | pip install toon-python |
| Go | toon-go | 公式GitHubを参照 |
| Rust | toon-rust | 公式GitHubを参照 |
| .NET (C#) | TOON.NET | NuGetを参照 |
| Swift | toon-swift | 公式GitHubを参照 |
TypeScript/JavaScriptでの使い方
import { encode, decode } from '@toon-format/toon';
// JSONデータをTOON文字列に変換
const data = {
users: [
{ id: 1, name: 'Alice', role: 'admin' },
{ id: 2, name: 'Bob', role: 'user' }
]
};
const toonString = encode(data);
console.log(toonString);
// 出力:
// users[2]{id,name,role}:
// 1,Alice,admin
// 2,Bob,user
// TOON文字列をJSONオブジェクトに変換
const jsonObject = decode(toonString);Pythonでの使い方
from toon_python import encode, decode
# JSONデータをTOON文字列に変換
data = {
"users": [
{"id": 1, "name": "Alice", "role": "admin"},
{"id": 2, "name": "Bob", "role": "user"}
]
}
toon_string = encode(data)
print(toon_string)
# TOON文字列をPythonオブジェクトに変換
python_object = decode(toon_string)CLIツールの使い方
Python版にはコマンドラインツールも付属しています。
# JSONファイルをTOONに変換
toon input.json -o output.toon
# TOONファイルをJSONに変換
toon data.toon -o output.json
# 標準入力・標準出力を使用
echo '{"name": "Ada"}' | toon -オンラインツール
プログラミングに不慣れな方向けに、Webブラウザ上で使えるコンバーターも公開されています。
- TOON Kit(https://www.toon-kit.com):JSONとTOONの相互変換、トークン数比較が可能
- Scalevise JSON to TOON Converter:シンプルな変換ツール
TOONに関するよくある質問
- TOONはJSONを完全に置き換えるのですか?
-
いいえ、置き換えではありません。
TOONはJSONの代替ではなく、LLMとのデータ受け渡しに特化した「翻訳レイヤー」です。APIや外部サービスとの連携、データの永続化には引き続きJSONが適しています。「内部はJSON、LLMへの入力だけTOON」という使い分けが推奨されています。
- TOONはどのLLMでも使えますか?
-
はい、主要なLLMすべてで利用可能です。
GPT-4、Claude、Gemini、Grokなど、主要なLLMでTOONを入力として使用できます。ベンチマークでは、TOON形式でも73.9%の精度を達成し、JSON(69.7%)を上回る結果も報告されています。
- どのようなデータでTOONの効果が高いですか?
-
「同じ構造が繰り返されるデータ」で最も効果的です。
具体的には以下のようなデータです。
- データベースのクエリ結果
- ユーザーリスト、商品リスト
- 時系列データ、ログデータ
- CSVファイルの内容
逆に、深いネスト構造や非定型データでは効果が薄い、または逆効果になる場合があります。
- 導入に際してシステムの大幅な改修は必要ですか?
-
いいえ、段階的に導入できます。
LLMに入力を渡す直前でJSONをTOONに変換し、LLMからの出力を受け取ったらJSONに戻す、というフローで導入できます。アプリケーション内部は従来通りJSONのまま維持できるため、システム全体を改修する必要はありません。
- TOONの仕様は安定していますか?
-
仕様は安定していますが、改善は継続中です。
TOONはMITライセンスで公開されており、公式仕様(SPEC.md)も整備されています。ただし、コミュニティ主導で改善が続けられているため、最新情報は公式GitHubリポジトリで確認することをおすすめします。
まとめ
この記事では、LLM向けの新しいデータフォーマット「TOON」について解説しました。
- TOONとは:LLMへのデータ入力を効率化するために設計された新しいデータフォーマット
- 主なメリット:トークン数を30〜60%削減、コンテキストの有効活用、LLMの理解精度向上
- 注意点:深いネスト構造には不向き、LLMの学習データに含まれていない点への対策が必要
- 導入方法:TypeScript、Python等の公式SDKを使い、LLM通信部分だけTOON化するのが推奨
- 適用範囲:繰り返し構造のデータに最適、JSONとの併用が現実的
TOONの導入を検討する方は、以下のステップで始めてみてください。
- 公式SDKをインストールする(TypeScript:
@toon-format/toon、Python:toon-python) - 小規模なデータで変換を試す(オンラインツールも活用可能)
- トークン削減率を計測する(自社データで効果を確認)
- 効果が確認できたら本番導入を検討する
TOONは「JSONの終焉」ではなく、「LLM時代のJSON最適化ツール」として捉えるのが適切です。まずは効果が高い部分から小さく始めて、徐々に適用範囲を広げていくアプローチをおすすめします。
AI時代のデータフォーマットとして、TOONの今後の発展に注目です。


コメント