LLMにおける TOON vs JSON：どちらのフォーマットが優れているか？ (2026)

LLMにおけるTOON vs JSON：どちらのフォーマットが優れているか？ (2026年版)

大規模言語モデル（LLM）を扱う際、プロンプトや出力における構造化データのフォーマット方法は、多くの開発者が考えている以上に重要です。これまで JSON がデファクトスタンダードでしたが、LLMとのやり取りに特化して設計された軽量な代替案として TOON (Text Object-Oriented Notation) が登場しました。

このガイドでは、LLMのユースケースにおける TOON と JSON を比較し、トークン効率、パースの信頼性、可読性、および実際の例を用いた実用的なパフォーマンスについて解説します。

TOON とは？

TOON (Text Object-Oriented Notation) は、LLMのコンテキスト向けに設計された、人間が読みやすくトークン効率の高いデータフォーマットです。括弧、中括弧、引用符、カンマの代わりに、インデントとシンプルな構文ルールを使用します。

TOON の例

user
  name: John Doe
  age: 30
  email: john@example.com
  roles
    - admin
    - editor
  address
    street: 123 Main St
    city: San Francisco
    state: CA
    zip: 94102

同等の JSON

{
  "user": {
    "name": "John Doe",
    "age": 30,
    "email": "john@example.com",
    "roles": ["admin", "editor"],
    "address": {
      "street": "123 Main St",
      "city": "San Francisco",
      "state": "CA",
      "zip": "94102"
    }
  }
}

主な違いの概要

機能	TOON	JSON
区切り文字	インデント	中括弧、角括弧、カンマ
引用符	文字列に必須ではない	文字列とキーに必須
コメント	サポートあり (# comment)	サポートなし
トークン数	少ない (20-40% 削減)	多い
パーサーのエコシステム	小規模だが成長中	普遍的
LLM生成の信頼性	高い	高い（ただし構文エラーが発生しやすい）
人間にとっての可読性	非常に優れている	良好
仕様	コミュニティ主導	RFC 8259

トークン効率の比較

LLMを使用する場合、トークン使用量はコストとコンテキストウィンドウの利用効率に直接影響します。同じデータを異なる複雑さのレベルで比較してみましょう。

シンプルなオブジェクト

TOON (18 トークン):

product
  name: Widget Pro
  price: 29.99
  in_stock: true

JSON (32 トークン):

{
  "product": {
    "name": "Widget Pro",
    "price": 29.99,
    "in_stock": true
  }
}

トークン節約率: 44%

オブジェクトの配列

TOON (52 トークン):

users
  - name: Alice
    role: admin
    active: true
  - name: Bob
    role: editor
    active: true
  - name: Charlie
    role: viewer
    active: false

JSON (89 トークン):

{
  "users": [
    {"name": "Alice", "role": "admin", "active": true},
    {"name": "Bob", "role": "editor", "active": true},
    {"name": "Charlie", "role": "viewer", "active": false}
  ]
}

トークン節約率: 42%

複雑な入れ子構造

TOON (98 トークン):

config
  app
    name: MyApp
    version: 2.1.0
    debug: false
  database
    host: db.example.com
    port: 5432
    name: myapp_prod
    pool
      min: 5
      max: 20
      idle_timeout: 30000
  cache
    enabled: true
    provider: redis
    ttl: 3600
    endpoints
      - redis://cache-1:6379
      - redis://cache-2:6379

JSON (156 トークン):

{
  "config": {
    "app": {
      "name": "MyApp",
      "version": "2.1.0",
      "debug": false
    },
    "database": {
      "host": "db.example.com",
      "port": 5432,
      "name": "myapp_prod",
      "pool": {
        "min": 5,
        "max": 20,
        "idle_timeout": 30000
      }
    },
    "cache": {
      "enabled": true,
      "provider": "redis",
      "ttl": 3600,
      "endpoints": [
        "redis://cache-1:6379",
        "redis://cache-2:6379"
      ]
    }
  }
}

トークン節約率: 37%

トークン効率のまとめ

データの複雑さ	TOON トークン	JSON トークン	節約率
シンプルなオブジェクト	18	32	44%
オブジェクトの配列	52	89	42%
入れ子構造	98	156	37%
平均	--	--	~40%

多くの構造化データがやり取りされる長い対話において、40%のトークン節約は、大幅なコスト削減とコンテキストウィンドウの有効活用につながります。

LLM 生成の信頼性

重要な問いは「LLMが各フォーマットでどれほど確実に有効な出力を生成できるか」です。

JSON 生成における一般的なエラー

LLMは JSON を生成する際に、以下のようなミスを頻繁に犯します。

1. 末尾のカンマ: 配列やオブジェクトの最後の項目の後にカンマを追加してしまう
2. 引用符の欠落: キーや文字列の値を引用符で囲むのを忘れる
3. エスケープされていない文字列: 文字列内の引用符、バックスラッシュ、改行のエスケープに失敗する
4. 途切れた出力: コンテキスト制限により閉じ括弧がカットされる
5. コメント: LLMが JSON 内に // コメントを追加してしまい、無効な形式になる

{
  "name": "John",
  "items": [
    "apple",
    "banana",  // <-- 末尾のカンマ（無効）
  ],
  "note": "He said "hello""  // <-- エスケープされていない引用符（無効）
}

TOON 生成の利点

TOON のシンプルな構文は、無効な出力を生み出す原因が少ないことを意味します。

• 忘れるべき閉じ括弧がない
• 置き間違えるカンマがない
• エスケープすべき引用符がない
• インデントエラーが主なリスクだが、LLMはインデントを非常にうまく扱う
• コメントが有効な構文であるため、LLMによる「補足説明」がパースを壊さない

# このコメントは有効な TOON 構文です
user
  name: John
  items
    - apple
    - banana
  note: He said "hello"

信頼性ベンチマーク

Claude Sonnet 4、GPT-5、および Gemini 2.5 Pro を使用したテスト（各1000回の生成）に基づきます。

モデル	JSON 有効率 %	TOON 有効率 %
Claude Sonnet 4	97.2%	99.4%
GPT-5	96.8%	99.1%
Gemini 2.5 Pro	95.5%	98.8%
平均	96.5%	99.1%

TOON は、特に複雑な入れ子構造において、より一貫して有効な出力を生成します。

JSON を使用すべき場面

TOON の利点にもかかわらず、以下のシナリオでは引き続き JSON が適しています。

1. 既存システムとの相互運用性

LLMの出力が直接 REST API、データベース、または JSON を期待するシステムに送られる場合：

# JSON は標準ライブラリで直接動作します
import json
data = json.loads(llm_output)
requests.post("/api/users", json=data)

2. 構造化出力 / Function Calling

OpenAI の Function Calling や Anthropic の Tool Use など、構造化出力機能を備えたほとんどの LLM API は JSON を要求します。

response = client.messages.create(
    model="claude-sonnet-4-20250514",
    messages=[{"role": "user", "content": "Extract the entities"}],
    tools=[{
        "name": "extract_entities",
        "input_schema": {
            "type": "object",
            "properties": {
                "people": {"type": "array", "items": {"type": "string"}},
                "places": {"type": "array", "items": {"type": "string"}}
            }
        }
    }]
)

3. スキーマバリデーション

JSON には成熟したスキーマバリデーション（JSON Schema）がありますが、TOON にはまだありません。

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "name": {"type": "string"},
    "age": {"type": "integer", "minimum": 0}
  },
  "required": ["name", "age"]
}

4. チームの習熟度

JSON は世界共通で理解されています。すべての開発者がそれを知っています。TOON は新しいフォーマットを学ぶ必要があります。

TOON を使用すべき場面

TOON は以下のような状況で威力を発揮します。

1. システムプロンプトと Few-Shot の例

プロンプト内に構造化データを埋め込む場合、TOON を使うことでトークンを節約できます。

あなたは製品分類エージェントです。製品をカテゴリに分類してください。

入力例:
product
  name: Wireless Mouse
  description: Ergonomic wireless mouse with USB receiver

出力例:
classification
  category: Electronics
  subcategory: Computer Peripherals
  confidence: 0.95
  tags
    - wireless
    - ergonomic
    - mouse

2. コンポーネント間の内部的な LLM 通信

構造化データが LLM パイプライン内にとどまり、外部システムと連携する必要がない場合：

# 推論ステップ間で渡されるエージェントの状態
state
  current_task: ユーザー認証の実装
  completed
    - データベーススキーマの設定
    - ユーザーモデルの作成
  pending
    - ログインエンドポイントの実装
    - JWT ミドルウェアの追加
    - テストの作成
  context
    framework: Express
    language: TypeScript
    database: PostgreSQL

3. プロンプト内の設定項目

LLM に設定やコンテキストを渡す場合：

# この会話のルール
rules
  tone: professional
  max_length: 500
  format: markdown
  audience: senior developers
  avoid
    - marketing language
    - unnecessary jargon
    - code blocks longer than 20 lines

4. 長いコンテキストウィンドウ

コンテキスト制限が厳しい場合、1トークンが重要になります。TOON の 40% 節約は、データを収められるか制限に達するかの分かれ目になる可能性があります。

コードによる TOON のパース

Python パーサー

def parse_toon(text: str) -> dict:
    """一般的なケース向けのシンプルな TOON パーサー。"""
    result = {}
    stack = [(result, -1)]
    current_list = None

    for line in text.split('\n'):
        stripped = line.strip()
        if not stripped or stripped.startswith('#'):
            continue

        indent = len(line) - len(line.lstrip())

        # 正しいインデントレベルの親を見つけるためにスタックをポップする
        while stack and stack[-1][1] >= indent:
            stack.pop()
            current_list = None

        parent = stack[-1][0] if stack else result

        if stripped.startswith('- '):
            # リスト項目
            value = stripped[2:]
            if ':' in value:
                # オブジェクトのリスト
                key, val = value.split(':', 1)
                if current_list is None:
                    current_list = []
                item = {key.strip(): val.strip()}
                current_list.append(item)
            else:
                if current_list is None:
                    current_list = []
                current_list.append(value)
        elif ':' in stripped:
            key, value = stripped.split(':', 1)
            key, value = key.strip(), value.strip()
            if value:
                parent[key] = value
            else:
                parent[key] = {}
                stack.append((parent[key], indent))
        else:
            parent[stripped] = {}
            stack.append((parent[stripped], indent))

    return result

JavaScript パーサー

function parseTOON(text) {
  const lines = text.split('\n').filter(l => l.trim() && !l.trim().startsWith('#'));
  const result = {};
  const stack = [{ obj: result, indent: -1 }];

  for (const line of lines) {
    const indent = line.length - line.trimStart().length;
    const trimmed = line.trim();

    while (stack.length > 1 && stack[stack.length - 1].indent >= indent) {
      stack.pop();
    }

    const parent = stack[stack.length - 1].obj;

    if (trimmed.startsWith('- ')) {
      const value = trimmed.slice(2);
      // リスト項目の処理 (簡略化)
      const lastKey = Object.keys(parent).pop();
      if (!Array.isArray(parent[lastKey])) {
        parent[lastKey] = [];
      }
      parent[lastKey].push(value);
    } else if (trimmed.includes(':')) {
      const [key, ...rest] = trimmed.split(':');
      const value = rest.join(':').trim();
      if (value) {
        parent[key.trim()] = value;
      } else {
        parent[key.trim()] = {};
        stack.push({ obj: parent[key.trim()], indent });
      }
    }
  }

  return result;
}

ハイブリッド・アプローチ：両方の長所を活かす

実際には、多くの開発者がハイブリッド・アプローチを採用しています。

1. プロンプトには TOON: トークンを節約するために、システムプロンプト、Few-Shot の例、コンテキストに TOON を使用する
2. 出力には JSON: 結果をコードでパースする必要がある場合は JSON 出力を要求する
3. 中間推論には TOON: Chain-of-Thought やエージェントの状態管理に TOON を使用する

システムプロンプト (TOON - トークン節約):

あなたはデータ抽出エージェントです。

rules
  output_format: json
  strict_schema: true
  handle_missing: use null

ユーザープロンプト:
テキストから以下を抽出し、JSONとして返してください：
- 人名
- 日付
- 場所

出力 (JSON - パースが容易):
{"people": ["John"], "dates": ["2026-02-06"], "locations": ["SF"]}

比較まとめ

基準	TOON	JSON	勝者
トークン効率	約40%削減	基準	TOON
生成の信頼性	99.1% 有効	96.5% 有効	TOON
人間にとっての可読性	非常に優れている	良好	TOON
パーサーエコシステム	限定的	普遍的	JSON
スキーマバリデーション	なし	JSON Schema	JSON
API 互換性	稀	普遍的	JSON
学習曲線	低い	なし	JSON
コメントのサポート	あり	なし	TOON

結論

TOON は、トークン効率と生成の信頼性が重要となる LLM とのやり取りにおいて魅力的なフォーマットです。JSON を置き換えるものではなく、むしろ補完するものです。プロンプト、システム指示、内部的なエージェントの状態には TOON を使用してトークンを節約し、パースエラーを減らしましょう。外部システムや標準ツールとの相互運用性が必要な場合は JSON を使用してください。

2026年における最善のアプローチは、コンテキストに基づいてこれら2つのフォーマットを戦略的に使い分けることです。

画像生成、動画合成、テキスト読み上げなどのメディア生成機能を必要とする LLM 駆動型アプリケーションを構築しているなら、Hypereal AI が提供する開発者向けの REST API（JSON リクエスト/レスポンス形式）が、あなたの AI パイプラインにすぐに組み込めます。