コンテンツにスキップ
AI Learning Playground
LinkedInX
日本語
日本語

AIで使う構造化データ入門：JSON・YAML・TOON・TOMLの選び方

約15分

Shiori
対象読者: AIへデータを渡す方法や、設定ファイルの形式選びに迷っている方
前提知識: AIとのやり取りに文章や表を使ったことがある

構造化データはAIとのやり取りを安定させる

構造化データとは、値を項目名、並び順、階層などの決められた形で整理したデータです。このページでは、JSON・YAML・TOON・TOMLの違いを理解し、AIへ渡すデータ、AIから受け取る結果、設定ファイルのそれぞれに適した形式を選べるようになることを目指します。

このページで学べること

  • 同じ内容でも形式によって、人間の編集しやすさ、機械での扱いやすさ、トークン数が変わる理由を説明できる
  • JSON・YAML・TOON・TOMLを、データ交換、設定、AI入力という用途に応じて選べる
  • トークン削減だけで形式を決めず、互換性、検証、データ形状を含めて判断できる
  • 実際に使うモデルとデータで形式を比較し、安全に変換する手順を実行できる

宅配伝票を思い浮かべると、構造化データを見分けやすくなります。「氏名」「住所」という欄が項目名、欄に書かれた内容が値、住所の中にある都道府県や市区町村が階層です。複数の商品明細は、同じ欄を持つ行の繰り返しに当たります。

実務では、形式は伝票のレイアウト、データの意味は記入内容に相当します。レイアウトが正しくても、郵便番号が誤っていれば配送できません。同じように、JSONなどの構文が正しいことと、必須項目や値の意味が正しいことは別です。必要な場面では、スキーマやアプリケーション側の検証も組み合わせます。

JSONは、文字列、数値、真偽値、null、オブジェクト、配列でデータを表す、言語に依存しない交換形式です。[1] YAMLは、人が読み書きしやすいことを重視したデータ直列化形式で、インデントによる階層やコメントを利用できます。[2]

TOMLは、明確な意味を持つ最小限の設定ファイル形式を目指し、データをテーブルへ対応付けます。[3] これらはプログラムに処理を命令するプログラミング言語ではなく、データの書き方を決める形式です。

AI利用では入力・出力・設定で役割が分かれる

AIと構造化データの関係は、1つの用途だけではありません。まず、どの境界で使うデータかを分けると判断しやすくなります。

  • AIへ渡す入力：商品一覧、検索結果、ログ、評価用データなどを、モデルが区別しやすい形に整理する
  • AIから受け取る出力：要約結果、分類、抽出した項目などを、プログラムで再利用できる形にする
  • AIアプリの設定：モデル名、処理順、参照先、評価条件など、人やツールが管理する値を保存する

入力形式によって、モデルの読み取りやすさとトークン数が変わります。出力の優先条件は、パーサーで確実に読めることと、必須項目を検証できることです。設定には、人が変更しやすく、既存ツールが対応し、差分を確認しやすい形式が適しています。同じプロジェクトの中で、境界ごとに異なる形式を使っても問題ありません。

同じデータを4つの形式で見比べる

次の例は、AIへ渡す2件の商品データを同じ意味のまま書き分けたものです。各形式で、項目名の引用符、区切り記号、インデント、繰り返し方がどう変わるかに注目してください。

JSON：機械間のデータ交換を優先する

{
  "products": [
    {"id": 101, "name": "Notebook", "stock": 12},
    {"id": 102, "name": "Pen", "stock": 30}
  ]
}

JSONは、API、データベースとの受け渡し、ツール呼び出しの引数など、機械同士が決められた契約でデータを交換する場面の第一候補です。利用できるライブラリが多く、文字列と数値の違いも明示できます。一方、標準のJSONにはコメントがなく、すべてのキーと文字列を二重引用符で囲むため、人が頻繁に編集する長い設定には冗長に感じることがあります。

YAML：人が読む設定や手順を優先する

products:
  - id: 101
    name: Notebook
    stock: 12
  - id: 102
    name: Pen
    stock: 30

YAMLは括弧や引用符を省きやすく、コメントを書けるため、人が管理するワークフロー設定やデプロイ設定に向きます。インデントが構造そのものになるので、空白のずれや、利用するパーサーの型解釈には注意が必要です。既存ツールがYAMLを指定している場合は、その仕様と利用可能な検証機能を優先します。

TOML：明示的なアプリ設定を優先する

[[products]]
id = 101
name = "Notebook"
stock = 12

[[products]]
id = 102
name = "Pen"
stock = 30

TOMLはkey = valueとテーブルを使い、設定項目を明示的に書けます。文字列、数値、真偽値に加えて日時の型も仕様に含まれており、アプリや開発ツールの設定に適した特徴です。[3] 大量のレコードをAIへ渡す用途では、テーブル宣言の繰り返しが増えるため、通常は最初の候補ではありません。

TOON：同じ形のレコードをAIへ渡す

products[2]{id,name,stock}:
  101,Notebook,12
  102,Pen,30

TOON（Token-Oriented Object Notation）は、JSONのデータモデルを、行とインデントを中心に表す形式です。同じ項目を持つオブジェクト配列では、項目名を先頭で一度だけ宣言し、各行で繰り返さないため、AIへ渡す入力を短くできる場合があります。[4]

ただし、TOON 4.1はWorking Draftであり、仕様自身も公開APIや一般的な保存形式の置き換えを目的としていません。項目が行ごとに異なるデータや深い入れ子では、JSONのほうが短くなる場合もあります。[4] そのため、TOONはJSONなどで保持したデータをAI入力の直前で変換する「変換層」として扱うのが現実的です。

トークン数は記号の少なさだけでは決まらない

トークンとは、AIモデルが文章や記号を処理するときの分割単位です。1文字が必ず1トークンになるわけではなく、単語の一部、空白、句読点、記号のまとまりがトークンになることがあります。分割規則はモデルやTokenizerによって異なるため、文字数だけでは正確な入力トークン数を判断できません。[6]

構造化データでは、同じキーの繰り返し、引用符、括弧、カンマ、空白、改行も入力に含まれます。そのため、同じ項目を持つ行が大量にある場合は、キーを一度だけ書くTOONや、単純な表であればCSVが短くなる可能性があります。一方、レコードが少ない場合や構造が不均一な場合は、形式を説明する追加指示や変換処理まで含めると利点が小さくなります。

TOONの公開ベンチマークでは、項目がそろったデータでTOONが整形済みJSONより少ないという結果です。一方、ネストした注文データや半構造化ログでは、圧縮JSONのほうが少なくなりました。絶対値はTokenizer固有であり、形式名だけでは優劣を決められません。[5]

比較するときは、同じ内容、同じ項目、同じ文字コードのデータを用意し、実際に利用するモデルまたは提供元のトークンカウンターで測ります。整形済みJSONだけでなく圧縮JSONとも比べ、トークン数に加えて、モデルが必要な値を正しく読み取れるかも確認が必要です。

用途から形式を選ぶ

形式選びでは、最初に接続先の仕様を守り、その次に人の編集頻度とデータ形状を見ます。トークン数は、選択肢が複数残ったときの測定項目です。

利用場面第一候補選ぶ理由確認すること
外部APIとの送受信JSON相手のデータ契約とライブラリに合わせやすい必須項目、型、エラー時の応答
AIの出力をプログラムで処理JSONパースとスキーマ検証を組み合わせやすい出力形式の強制方法、検証失敗時の再処理
人が編集するワークフロー設定YAML階層を読みやすく、コメントを残せるインデント、パーサーの型解釈、既存ツールの仕様
アプリや開発ツールの設定TOML値とテーブルが明示的で、設定用途に絞りやすい対応ライブラリ、配列テーブルの読みやすさ
大量の均一レコードをAIへ入力TOON項目名の繰り返しを減らせる場合がある実測トークン数、モデルの読取精度、JSONへの復元
入れ子のない表データCSV行と列だけなら簡潔区切り文字、改行、型、欠損値の扱い
この表は横方向にスクロールできます。キーボードでは、表にフォーカスして左右の矢印キーを使用してください。

文章による方針や例外条件まで無理に構造化する必要はありません。自然言語の指示はMarkdown、厳密に再利用する値はJSONなど、内容の役割に合わせて組み合わせるほうが管理しやすくなります。

実務では境界で変換し、正本を1つにする

ケース1：AIから注文情報を受け取る

AIが抽出した注文番号、商品ID、数量を後続プログラムへ渡す場合は、JSONを出力形式にします。受信後に「注文番号は文字列」「数量は正の整数」のようなルールで検証し、失敗したデータをそのまま登録しません。ここでは数トークンを減らすより、確実にパースできることを優先します。

ケース2：AIワークフローの設定をチームで管理する

処理順、参照ファイル、実行条件を人が頻繁に編集し、利用するツールがYAMLを前提としているならYAMLが自然です。アプリ固有の設定を明示的なキーとテーブルで管理し、ツールがTOMLを標準としているならTOMLが合います。好みだけで形式を増やさず、既存ツールの契約とチームの検証方法を優先してください。

ケース3：検索結果をまとめてAIへ渡す

数百件の商品やログをAIに比較させる場合は、元データをJSONなどの正本として保持します。AIに不要な項目を削り、同じ項目が並ぶ部分だけTOONへ変換して、圧縮JSONとトークン数・読取結果を比較します。TOONから元のJSON相当へ戻せない、またはモデルの回答精度が下がるなら採用しません。

この運用では、保存、API、AI入力のすべてを1つの形式へ統一しません。意味を保持する正本を決め、接続先で必要なときだけ変換することで、互換性とトークン効率を両立しやすくなります。

5つの手順で選択を検証する

  1. 接続先の契約を確認する：API、ツール、ライブラリが要求する形式を最優先にします。
  2. データ形状を確認する：均一な表、深い入れ子、行ごとに異なる項目のどれかを見分けます。
  3. 人の編集頻度を確認する：手作業が多い設定では、コメント、差分、エラーメッセージの読みやすさを評価します。
  4. 同じデータで測る：候補形式を同じ項目から生成し、利用するモデルのTokenizerで入力トークン数と読取結果を比較します。
  5. 往復変換と検証を試す：変換後のデータを正本の構造へ戻し、値、型、件数、必須項目が保たれていることを確認します。

完了の目印は、「なぜこの形式か」を用途、接続先、データ形状、測定結果のいずれかで説明でき、変換後も必要な値が失われていないことです。判断材料が不足しているなら、最も広く接続先が対応しているJSONから始め、実測で問題が見つかった部分だけ別形式を試します。

要点

JSONは機械間の交換とAI出力、YAMLとTOMLは人が管理する設定、TOONは大量で均一なJSON形状データをAIへ渡す変換層に向きます。ただし、接続先の仕様が最優先であり、TOONやYAMLが常にJSONより少ないトークンになるわけではありません。

形式選びを確定する前に、実際のデータを実際のTokenizerで測り、パース、必須項目、型、件数、往復変換を確認します。トークン削減は、意味と互換性を保てた場合にだけ有効な改善です。

参考文献

  1. Internet Engineering Task Force, RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format, 2017年12月
  2. YAML Language Development Team, YAML Ain’t Markup Language (YAML™) revision 1.2.2, 2021年10月1日
  3. TOML, TOML v1.0.0
  4. TOON Format, TOON Specification v4.1, 2026年7月26日
  5. TOON Format, Benchmarks
  6. OpenAI, Counting tokens

最新のリリースやアップデートの詳細は、公式サイト・公式ドキュメントを確認してください。

クイズ