Toon(Token-Oriented Object Notation)とは？

Toon（Token-Oriented Object Notation）は、「トークン（Token）」を最小単位として構造化データを表現するテキストフォーマットです。見た目はJSONやYAMLに近く、設定ファイルや構成ファイル向けに、人にもマシンにも扱いやすく設計されています。
また基本的に、圧倒的にJsonでデータを扱うよりもデータ量を減らすことが可能です。

Toonのコンセプトと特徴

• 人間が読み書きしやすい
  • インデントと改行ベースで、YAMLに近い感覚
  • コメントやメタ情報を自然に書ける
• マシンにとって扱いやすい
  • シンプルな構造でパーサー実装が容易
  • トークン単位で扱えるため、diff・merge・静的解析に向く
• 設定・構成ファイルに特化
  • アプリ設定、インフラ構成、ワークフロー定義などに最適
  • 「宣言的にどう振る舞うかを書く」用途が主戦場

Toonフォーマットの基本

基本の構成要素

Toonは次の3つで構成されます。

• オブジェクト（キーと値の集合）
• リスト（配列）
• スカラ値（文字列・数値・真偽値など）

config:
  version: 1
  app:
    name: "sample-app"
    debug: false
    ports: [80, 443]

  database:
    host: "db.example.com"
    port: 5432
    user: "app_user"
    password: @env.DB_PASSWORD

# コメントも書ける
features:
  - auth
  - billing
  - analytics

キーと値・リスト・スカラ

• オブジェクト：key: value形式でネスト可能
• リスト：
  • 読みやすさ重視：行頭 - 形式
  • コンパクト重視：[1, 2, 3] 形式
• スカラ値：
  • 数値：int: 42 など
  • 真偽値：flag: true
  • 文字列：クォート省略可、スペースを含む場合は"..."

トークン指向の表現

Toonでは、特別な意味を持つ「トークン」を定義して拡張できます。

db:
  password: @env.DB_PASSWORD   # 環境変数参照

paths:
  root: "/var/app"
  logs: @ref.paths.root + "/logs"  # 他のキーを参照

• @env.*：環境変数参照トークン
• @ref.*：同一ドキュメント内参照トークン

これらはパーサー側のルールで柔軟に解決できるため、環境ごとの設定や共通値の再利用に強いフォーマットになります。

Toonが得意なこと

• 設定ファイル・構成ファイル
  • アプリ設定、インフラ定義、CI/CDワークフロー、マニフェストなど
• 人間と機械の両方に優しい構造
  • トークンの切れ目が明確でエディタ支援や自動整形と相性が良い
  • 差分（diff）やマージ（merge）が扱いやすい
• コメント・ドキュメント性の高い設定
  • JSONが苦手なコメントを自然に扱える
• コード生成・テンプレートとの連携
  • Toonから型定義やインフラコード、最終設定ファイルを生成しやすい

Toonが苦手・不向きな用途

• バイナリデータの格納
  • 画像・動画などは、パスやメタ情報のみを持たせるのが現実的
• 超大規模データのストレージ
  • 数百万レコード級の本格的なデータ保存にはRDBMSや専用バイナリフォーマットを使用すべき
• 本番APIレスポンス
  • クライアントやブラウザはJSON前提が多く、性能面でもJSON/Protobuf等に劣る
• 複雑なロジック記述
  • Toonは宣言的フォーマットであり、ループや条件分岐などはアプリコード側の責務

JSON・YAMLとの使い分け

JSONとの比較

• JSONの強み
  • 事実上の標準フォーマット
  • ブラウザや各言語ランタイムが強力サポート
• Toonが向く場面
  • コメント付きの設定ファイル
  • 環境変数参照やドキュメント内参照などトークン拡張を多用する設定
• 使い分けイメージ
  • 外部公開APIのレスポンス → JSON
  • 内部の設定・構成ファイル → Toon

YAMLとの比較

• YAMLの強み
  • 人が読みやすく、既に多くの設定フォーマットで採用
• YAMLの弱点
  • 仕様がリッチで曖昧さもあり、ツール実装が複雑になりがち
  • インデントやタブ・スペースの違いによるトラブルが多い
• Toonの立ち位置
  • YAML並の可読性を維持しつつ、仕様をシンプルにして機械処理しやすくする
  • トークン指向で静的解析やコード生成などに向けた設計

採用を検討するポイント

採用しやすいケース

• 設定ファイルを人が頻繁に編集する
• コメントや説明をしっかり残したい
• 参照・環境変数・テンプレートなどのトークン拡張を使いたい
• 将来的に静的解析やコード生成を行いたい

様子見がよいケース

• JSON/YAML資産がすでに膨大
• 連携ツールがJSON/YAML前提でしか動かない
• プロジェクト寿命が短く、新フォーマット導入コストが見合わない

まとめ

• Toonは、トークン指向で設計された構造化データのテキストフォーマット。
• コメントやトークン拡張に強く、設定・構成ファイル向けに最適化されている。
• 一方で、バイナリ格納・大規模データストレージ・本番APIレスポンス・複雑ロジックには不向き。
• JSON/YAMLをすべて置き換えるのではなく、「人が編集する設定・構成レイヤー」で併用・使い分けるのが現実的なポジション。