JSONはもう古い？LLM時代の新フォーマット「TOON」がトークンを節約する理由

はじめに

JSONくん、君はちょっと「おしゃべり」すぎるかもしれない。

開発をしていると、JSON (JavaScript Object Notation) とはもう「空気」のような存在ですよね。何かしらどこかしらで付き合いのある感じ。
APIを叩けばJSONが返ってくる。設定ファイルもJSON。何ならログもJSON。
私も長年連れ添った相棒として、彼（JSON）のことは信頼しています。

でも、LLM（大規模言語モデル） と付き合い始めてから、ちょっと気になることが出てきました。
「あれ…？ 君、無駄口多くない…？」

[
  {"id": 1, "name": "user_a", "role": "admin"},
  {"id": 2, "name": "user_b", "role": "member"},
  {"id": 3, "name": "user_c", "role": "member"}
]

丁寧なんです。すごく丁寧。良いやつだ、彼は(彼じゃないかもしれないけれど)
でも、毎回 "id":, "name":, "role": って繰り返すその律儀さが、従量課金のトークン をガリガリ削っていく音が聞こえる気がするんです。
「塵も積もれば山となる」とは言いますが、LLM時代においてその塵は 「お金」 と 「速度」 そのものです。

そこで最近、界隈でふと耳にしたのが TOON (Token-Oriented Object Notation) という概念。
単語が「漫画・アニメ」の意味の方かな？可愛い感じかな？なんて思いますが、中身はかなり合理的でシビアなやつでした。
いいね、そういうの私好きよ。

今回は、この「TOON」について、JSONとの付き合い方に悩み始めた私が調べたことをまとめてみます。

---

LLM時代におけるJSONの「贅肉」問題

JSONは、人間にも機械にも読みやすい、素晴らしいフォーマットです。これは揺るぎない事実。
ですが、「トークン効率」 という観点で見ると、彼はかなりリッチな服を着ています。

具体的にはこのあたりが「贅肉」です：

1. 繰り返されるキー名: 配列の要素が増えるたびに "name": が増殖する。
2. 大量の括弧: {}, [] のオンパレード。
3. 引用符: 文字列を囲む "" も、積み重なれば結構な量。

これらは、従来のWeb APIなら「可読性」として歓迎される要素でした。
しかし、LLMにとっては 「意味のないトークン」 であり、「コンテキストウィンドウの浪費」 でしかありません。

そもそも「トークン」ってどう数えられてるの？

「文字数とトークン数は違う」というのはAIエンジニアの常識ですが、具体的にJSONがどうトークン化されるか、意識したことはありますか？
OpenAIのTokenizer（cl100k_base）を例に見てみましょう。
https://platform.openai.com/tokenizer

例えば {"id": 123} という短いJSON。
人間が見れば「idが123だな」と一瞬ですが、Tokenizerはこれを以下のように分解します。

1. { (1 token)
2. " (1 token)
3. id (1 token)
4. ": (1 token)
5. (1 token)
6. 123 (1 token)
7. } (1 token)

合計7トークンです。
たった一つのデータを送るのに、記号だけで半分以上のトークンを消費しています。
これが1万件のデータリストになったら…想像するだけでゾッとしますよね。

一方、TOON的な発想で |123| と表現した場合：

1. | (1 token)
2. 123 (1 token)
3. | (1 token)

合計3トークン。
この「塵」のような差が、RAGで数千文字のコンテキストを扱う際に、巨大な「山」となって効いてくるのです。

日本語ユーザーには特に「効く」かもと思った話

私たち日本語ユーザーにとって、この問題はさらに深刻です。
英語なら1単語≒1トークンですが、日本語は1文字で1〜2トークン消費する ことがザラにあります。
つまり、ただでさえ「データの中身（日本語）」でトークンを食うのに、その周りを「JSONの記号」でデコレーションするのは、高級な和牛を分厚い衣で包んで揚げるようなもの です。もったいない。そして、深夜に肉の話をしたら、お腹空いてきました、個人ミス…oh。

構造部分（衣）を極限まで薄くするTOONのアプローチは、トークン効率の悪い日本語を扱う私たちにこそ、必要な技術なのかもしれんかもな、と思いました。
採用するかは置いておいて。

---

TOON (Token-Oriented Object Notation) とは？

TOONは、その名の通り 「トークン効率を最優先に設計された」 データフォーマット（というより記法・概念）です。
JSONと互換性のあるデータ構造を持ちながら、極限まで記述を簡素化しています。

イメージとしては、「JSONをダイエットさせて、必要な骨組みだけ残した」 ような感じです。

百聞は一見にしかず、JSON vs TOON

論より証拠。見た方が早いですからね。
同じデータをJSONとTOONで表現して、その差を見てみましょう。

いつものJSON:

[
  {
    "id": 1,
    "name": "Alice",
    "role": "Admin",
    "status": "Active"
  },
  {
    "id": 2,
    "name": "Bob",
    "role": "User",
    "status": "Inactive"
  },
  {
    "id": 3,
    "name": "Charlie",
    "role": "User",
    "status": "Active"
  }
]

TOONの場合:

| id  | name    | role  | status   |
| --- | ------- | ----- | -------- |
| 1   | Alice   | Admin | Active   |
| 2   | Bob     | User  | Inactive |
| 3   | Charlie | User  | Active   |

あるいは、もっと削ぎ落してこう表現することも（実装によりますが）可能です。

#keys: id, name, role, status
1, Alice, Admin, Active
2, Bob, User, Inactive
3, Charlie, User, Active

…圧倒的じゃないですか？
あの大量の { } " key: が消え去り、データの実体だけが残っています。
CSVやMarkdownテーブルに近いですが、これを「構造化データ」としてLLMに認識させるのがTOONの思想です。
むしろMarkdownテーブルと考えると、慣れたら結構読めそうかも。

---

実装してみる：PythonでJSONをTOONに変換

「概念はわかったけど、どうやって使うの？」という方のために、簡単な変換スクリプトを書いてみました。
標準ライブラリだけでサクッと書けます。

def json_to_toon(data: list[dict]) -> str:
    """
    辞書のリストをMarkdownテーブル風のTOON形式に変換する簡易関数
    """
    if not data:
        return ""
    
    # ヘッダー取得
    headers = list(data[0].keys())
    
    # ヘッダー行と区切り行の作成
    header_line = "| " + " | ".join(headers) + " |"
    separator_line = "| " + " | ".join(["---"] * len(headers)) + " |"
    
    lines = [header_line, separator_line]
    
    # データ行の作成
    for item in data:
        # 値を文字列化して結合（Noneなどは空文字にするなどの処理はお好みで）
        values = [str(item.get(h, "")) for h in headers]
        line = "| " + " | ".join(values) + " |"
        lines.append(line)
        
    return "\n".join(lines)

# 試してみる
users = [
    {"id": 1, "name": "Alice", "role": "Admin"},
    {"id": 2, "name": "Bob", "role": "User"}
]

print(json_to_toon(users))

出力結果:

| id  | name  | role  |
| --- | ----- | ----- |
| 1   | Alice | Admin |
| 2   | Bob   | User  |

これをプロンプトに埋め込んで、「以下のデータを元に考えて」とLLMに投げればいいわけです。
受け取る側（LLMからの出力）も、「このフォーマットで返して」と指定すれば、パースも正規表現や split('|') で比較的容易に行えます。

逆もまた然り：TOONをパースしてJSONに戻す

「送るのはいいけど、受け取ったデータをプログラムで扱えないと意味ないじゃん」
その通りです。LLMからTOON形式で出力されたテキストを、Pythonの辞書リストに戻すパーサーも用意しておきましょう。

def toon_to_json(toon_text: str) -> list[dict]:
    """
    TOON形式（Markdownテーブル風）のテキストを辞書リストに変換する
    """
    lines = toon_text.strip().split('\n')
    if len(lines) < 3:
        return []

    # ヘッダー行の解析
    # 先頭・末尾のパイプを除去して分割
    headers = [h.strip() for h in lines[0].strip('|').split('|')]
    
    result = []
    # 2行目はセパレーター（---|---）なのでスキップして3行目から処理
    for line in lines[2:]:
        if not line.strip():
            continue
            
        values = [v.strip() for v in line.strip('|').split('|')]
        
        # 値の数がヘッダーと合わない場合の簡易ハンドリング
        if len(values) != len(headers):
            # ログを出すなり、スキップするなり、Noneで埋めるなり好み
            continue
            
        row_dict = {}
        for i, header in enumerate(headers):
            # 数値変換などは適宜行う（ここでは全部文字列として扱う）
            row_dict[header] = values[i]
            
        result.append(row_dict)
        
    return result

# テストデータ
toon_data = """
| id  | name  | role  |
| --- | ----- | ----- |
| 1   | Alice | Admin |
| 2   | Bob   | User  |
"""

print(toon_to_json(toon_data))
# Output: [{'id': '1', 'name': 'Alice', 'role': 'Admin'}, {'id': '2', 'name': 'Bob', 'role': 'User'}]

もちろん、値の中にパイプ | が含まれる場合のエスケープ処理など、本番運用ではもう少し堅牢な作り込みが必要ですが、基本的なロジックはこれだけです。
「標準ライブラリがない」と言いましたが、これくらいのコード量ならユーティリティ関数としてコピペしても許される範囲ではないでしょうか。多分。

---

なぜ今、TOONなのか？

「いやいや、CSVでいいじゃん」と思った方。鋭いです。
でも、TOON（という概念）を採用するメリットは、単なる「文字数削減」以上の意味があります。

1. お財布に優しい（APIコストの削減）

LLMのAPI利用料はトークン従量課金が一般的です。
特に入力（Prompt）よりも出力（Completion）の方が高いケースが多いですよね。
RAG（検索拡張生成）などで、大量のドキュメントリストをLLMに渡すとき、JSONだとすぐにトークン上限に達してしまいますが、TOONなら 30%〜60% 近く圧縮できるケースもありえそうです。

RAGに関しても割とデカい情報を持たせることが増えてきたので結構ここは知識として押さえておかんとかなあ、と思ったのが今回の記事書く切っ掛けです。へへ。

これは、「同じお金で、より多くの情報を処理できる」 ということです。

コスト削減シミュレーション

「30%削減」と言われてもピンとこないかもしれないので、お金の話をしましょう。
例えば、GPT-4oを使って、毎日1万件のユーザーデータを処理するバッチ処理を走らせるとします。

• JSONの場合: 1件あたり平均500トークン × 1万件 = 500万トークン
• TOONの場合: 1件あたり平均300トークン × 1万件 = 300万トークン

GPT-4oの入力価格（$5.00 / 1M tokens）で計算すると…

• JSON: $25 / day
• TOON: $15 / day

1日で$10（約1,500円）の差。
「なんだ、ランチ代くらいか」と思いました？
これが月間だと 45,000円。年間だと 54万円 の差になります。
スタートアップとかのサーバー代としては、無視できない金額になってきませんか？
必要経費とも言えなくもないけど、うーん、というラインですね。
さらに、RAGで参照するドキュメント量が10倍になれば、この差額もそのまま10倍になります。
RAG側はそれこそ出力の質に影響するので、変に削ると品質に影響しますし。

2. 爆速になる（推論速度の向上）

LLMはトークンを一つずつ生成します。
つまり、「生成するトークンが減れば、レスポンスは速くなる」。
"name": "Alice", と書くのと、Alice と書くのでは、生成にかかる時間が物理的に違います。
リアルタイム性が求められるチャットボットやエージェント開発では、この数ミリ秒の積み重ねがUXに直結します。
離脱率とか結構馬鹿に出来ないんですよねぇ。

3. 「もっと覚えていられる」（コンテキストウィンドウの有効活用）

LLMが一度に扱える情報量（コンテキストウィンドウ）には限りがあります。
データフォーマットを軽量化することで、その分、より多くのプロンプト指示や、参考情報（Few-shot事例など）を詰め込むことができます。
「トークンが足りなくてエラーが出た…」というあの絶望から、少しだけ解放されるかもしれません。

認知負荷の軽減も多少ありそうだよなあ、なんて思います。
実際に、「Lost in the Middle」（重要な情報がコンテキストの中間にあるとLLMが見落としやすくなる現象）という研究結果も報告されています。
ノイズ（無駄な記号）を減らして情報の密度を高めることは、LLMが「大事なこと」に集中するのを助ける効果も期待できそうです。

https://arxiv.org/abs/2307.03172

---

ライバルたちと比較。YAMLやCSVじゃダメなの？

ここで当然の疑問が湧きます。
「JSONが重いのはわかった。でも、軽量フォーマットならYAMLとかCSVもあるじゃん？」

その通りです。彼らも優秀な候補です。
なんならいつもお世話になってるシリーズだよ。
比較してみましょう。GOGO！

vs YAML

YAMLはJSONより括弧が少なくて読みやすいですが、「インデント」 という見えない敵がいます。
LLMにとってインデント（スペースの連続）は、意外とトークンを食いますし、生成時にインデントがズレてパースエラーになるリスクも高いです。
TOON（表形式）は区切り文字が明確なので、構造崩れのリスクがYAMLより低い（と個人的には感じています）。
あと一般(非エンジニア)に引継ぎする時にYAMLファイルを触らせる事になるの不安で不安で仕方なかった(スペース1つで死ぬファイルと5000回くらい言った記憶)。

vs CSV

CSVは最強のトークン効率を誇ります。1,Alice,Admin。これ以上削れません。
しかし、CSVには 「ヘッダーと値の対応関係が遠い」 という弱点があります。
列数が多くなると、LLMが「あれ、3番目のカラムって何だっけ？」と迷子になりやすく、ハルシネーション（幻覚）の原因になります。
TOON（Markdownテーブル）は視覚的に列が揃っているため、LLMが構造を理解しやすく、CSVとJSONの「いいとこ取り」ができるバランスの良さがあります。

---

デメリットと限界

いいこと尽くめに聞こえますが、もちろん弱点もあります。
技術選定において「トレードオフ」を無視するのは危険ですからね。
もういつものシリーズ。

• ネスト（階層構造）に弱い:
  • JSONの得意技である「オブジェクトの中に配列があって、その中にまたオブジェクト…」という構造は、TOON（表形式）では表現しづらいです。無理やり表現しようとすると逆に複雑になります。フラットなデータリスト向きです。
  • 個人的にSQLの深いネスト構造とは因縁があります。私もToonと同じ気持ちです、となった。
• 型情報の曖昧さ:
  • JSONなら true (bool) と "true" (string) は別物ですが、TOON（テキスト表）にすると全部文字列に見えてしまうことがあります。厳密な型定義が必要な場合はスキーマ定義を別途渡すなどの工夫が必要です。これが場合によっては面倒な事になるな、と思いました。
• 標準ライブラリがない:
  • import json して json.load() 一発、とはいきません。自前でパーサーを書くか、LLMにパースさせる必要があります。

---

実際の使いどころ：どこで使うのが正解？

既存のWeb APIのレスポンスを明日から全部TOONに変えろ！なんて暴論は言いません。
というかそんな工数どこから生えてくるんだ問題。
JSONのエコシステムは偉大です。

TOONが輝くのは、「LLMとの対話」 という閉じた世界の中です。

• RAG (Retrieval-Augmented Generation):
  • 検索結果としてヒットした100件のドキュメント情報をLLMに渡すとき。JSONだと溢れるけど、TOONなら入る！というケースは多々ありえてきそうだな、と。
• AI Agent間の通信:
  • Planner AgentがWorker Agentにタスクリストを渡すとき。機械同士の会話なら、丁寧なJSONより効率的なTOONの方が「話が早い」です。昨今の大エージェント時代を考えるとまあ徐々にAI Agentのやり取りに限ればToonにしようか、はあり得ていくのかも、と思った次第です。
  • 過去まだgeminiがスレッドの限界で、応答が不適切になった時に別のスレッドに移行する時に「人間への配慮はいらないから適切に内容を別スレッドに引き継ぐためのプロンプト出して」なんて指示をしていた事と同様に機械同士のやり取りを考えるとAIファーストじゃないですけど、人間を置いてけぼりにしても良いケースであれば良いものだと思います。
• 構造化データの抽出:
  • LLMに「この文章からデータを抽出して」と頼むとき。出力フォーマットをTOON指定にすることで、生成速度を上げつつ、パース可能な形式で受け取れます。あくまでこれも抽出に限ったはなしですが。

---

でも、流行るかと言われると…？ 現実的な運用ライン

ここまでTOONを褒めちぎってきましたが、「じゃあ明日からチーム開発でTOON導入しようぜ！」 となるかというと、正直難しいだろうな、と思ってます。今は。

以前書いた「数式×論理構造」でプロンプトを圧縮する話でも触れましたが、「AIにとって読みやすい形式」は、往々にして「人間にとって読みにくい（認知負荷が高い）形式」 です。

チーム開発において、JSONの「冗長だけど誰でも読める」というメリットは計り知れません。
誰でも読める、もまあ正直エンジニア層たちに甘えているというか、エンジニアたちは少なくともどこかしらでJSONと接触している率が高いので読める、という認識ではあります。

「これTOON形式だからパースしてね」とドキュメントに書くコスト、新メンバーへの学習コスト、デバッグのしにくさ…これらを天秤にかけると、多くのプロジェクトでは 「多少トークン代がかかっても、JSONの方が安全で楽」 という結論になるはずです。

既存のAPIシステムもJSONで動いていますし、それをひっくり返すのは現実的ではありません。

TOONが輝く「現実的な」ライン

なので、TOONの現実的な運用ラインは、以下のような 「局所的な最適化」 に落ち着くと思います。

1. APIコストが事業の生命線になるレベルの大規模運用
2. 個人開発や小規模チームで、意思決定のスピードが速い場合
3. LLM内部の処理（ユーザーの目に触れない部分）でのデータ受け渡し

「JSONを置き換える次世代スタンダード」というよりは、「ここぞという時の必殺技（局所最適化ツール）」 として懐に忍ばせておく。
それくらいの距離感が、今のところちょうど良さそうな認識です。
そんなハイブリッドな使い分けができるのが、令和のエンジニアの処世術なのかもしれません。

参考リソース

• TOON (Token-Oriented Object Notation) - X
• Format Tokenization Exploration