構造化フォーマットはすでに存在する。ではなぜ新しい言語が必要なのか?
最も一般的な反論
AI推論言語の概念に初めて触れた人が最初に言うのはこうだ:
「構造化フォーマットはすでにあるのでは?」
その通りだ。ある。たくさん。
Markdownがある。 JSONがある。 XMLがある。 YAML、TOML、Protocol Buffers、MessagePack、CSV…
世界はデータフォーマットで溢れている。 ではなぜAIはまだ自然言語で思考しているのか?
この問いに答えるには、各フォーマットが何に優れ、 何ができないかを正確に指摘する必要がある。
Markdown:AIエージェントの現在の記憶
2026年現在、AIエージェントが最も広く使っているフォーマットはMarkdownだ。
Claude Codeは .md ファイルで記憶する。
GPTベースのエージェントもMarkdownでメモを残す。
CLAUDE.md、memory.md、notes.md。
AIの長期記憶はこの瞬間、Markdownの上に立っている。
なぜMarkdownか?理由は単純だ。 LLMはMarkdownの読み書きが得意だ。 Markdownは訓練データに豊富に含まれ、 その構造は生成とパースが容易なほど簡潔だ。
しかしMarkdownは人間が読むために作られた文書フォーマットだ。
# プロジェクト状況
## キャッシュ戦略
- SIMDビットマスク採用 (1/28決定)
- GPU加速検討中
## 未解決
- クエリ生成方法 未定
機械はこれをどう解釈するか?
「キャッシュ戦略」というセクション見出しがある。 その下に「SIMDビットマスク採用」という項目がある。 括弧内に日付「(1/28)」がある。
機械はこれを構造的に理解できない。
## から「キャッシュ戦略」がセクション見出しだとわかるが、
「アーキテクチャのサブトピックである」という意味的関係はMarkdownに存在しない。
人間は「1/28」が日付だと知っているが、機械は推測しなければならない。
1月28日なのか、28分の1なのか?
結局、Markdownを「理解」するにはLLMが自然言語の解釈を行わなければならない。 Markdownはインデントを重ねた自然言語であって—— 構造化データではない。
JSON:意味のない構造
JSONはMarkdownより一歩先を行く。
{
"entity": "李舜臣",
"birth": "1545",
"death": "1598",
"occupation": "naval_commander"
}
構造がある。キーバリューペアは明示的だ。 機械はパースできる。フィールドにアクセスできる。
しかし問題がある。
JSONはキー"entity"が何を意味するか知らない。
このJSONを作った人は"entity"が「対象物」を意味すると知っている。 別の人のJSONでは同じ概念が"name"、“subject”、“item"かもしれない。
{"name": "李舜臣"}
{"subject": "李舜臣"}
{"item": "李舜臣"}
{"entity": "李舜臣"}
4つのJSONが同じことを表現しているが、 機械にはそれが同じだとわからない。
JSONには共有された意味論がない。 構造はあるが、その構造が何を意味するかの合意がない。
プロジェクトごとに独自のスキーマを作る。 APIごとに独自のフィールド名を使う。 スキーマAとスキーマBを接続するにはまた別の変換層が必要だ。
これはバベルの塔だ。 構造はあるが、互いの構造を誰も理解していない。
XML:冗長性という税
XMLはJSONの問題を解決しようとした。
名前空間、スキーマ定義(XSD)、文書型定義(DTD)。 構造の意味を定義するメタ構造を提供する。
<entity xmlns="http://example.org/schema">
<name>李舜臣</name>
<birth>
<year>1545</year>
<calendar>lunar</calendar>
</birth>
<death>
<year>1598</year>
<cause>killed_in_action</cause>
</death>
</entity>
意味を定義できる。スキーマで構造を強制できる。 JSONより厳密だ。
しかしXMLには致命的な問題がある。
冗長だ。
上のXMLで、実際の情報は「李舜臣、1545、1598、killed_in_action」だ。 それ以外はすべてタグだ。開始・終了タグが情報量を上回る。
なぜこれがAIにとって問題なのか?
LLMのコンテキストウィンドウは有限だ。 同じ情報を伝えるのに3倍のトークンが必要なら、 コンテキストに入る情報量は3分の1に縮む。
XMLは人間が読みやすいように冗長だ。
AI推論言語にこの無駄があってはならない。
LLMにとって <name> タグは無駄だ。
そしてXMLは2000年代初頭の設計だ。 LLMが存在しない時代に、人間と従来のソフトウェアのために作られた。 AI推論言語として設計されたことはない。
共通の限界
Markdown、JSON、XML。 3つのフォーマットはそれぞれ強みがあるが、共通の限界を持つ。
テキストベースである。 すべて文字列にシリアライズされる。 機械は処理するためにパースしなければならない。 パースはコストだ。
理想的な推論言語はバイナリストリームだ。 16ビットワードの列。パース不要。 読んだ瞬間に解釈可能。
LLM時代以前に設計された。 Markdownは2004年。JSONは2001年。XMLは1998年。。 LLMの概念が存在しない時代に、 人間または従来のソフトウェアのために設計された。
AI推論言語はLLM時代に、LLMのために設計されなければならない。 「1ワード = 1トークン」という設計原則は LLMの存在を前提としている。
統一された意味論システムが不在または不完全である。 Markdownには意味論システムが全くない。 JSONには構造はあるが意味がない。 XMLはスキーマを定義できるが統一されていない。
意味整列インデックスはグローバルに統一された意味IDだ。 どこで使っても、同じSIDXは同じことを意味する。 変換不要。合意が組み込まれている。
まとめ
| フォーマット | 構造 | 意味 | LLMフレンドリー | バイナリ | 主張サポート | 動詞修飾 |
|---|---|---|---|---|---|---|
| Markdown | 弱い | なし | 高い | いいえ | なし | なし |
| JSON | あり | なし | 中程度 | いいえ | なし | なし |
| XML | あり | 部分的 | 低い | いいえ | なし | なし |
| 理想的推論言語 | あり | あり | 高い | はい | あり | あり |
新しいフォーマットが必要なのは、既存のフォーマットが悪いからではない。 既存のフォーマットが別の時代に、別の目的のために作られたからだ。
Markdownは人間が読む文書のために作られた。 JSONはWeb APIのデータ交換のために作られた。 XMLは文書とデータの汎用シリアライゼーションのために作られた。
AIの推論を記録し蓄積するフォーマット。それはまだ存在しない。
目的が異なれば、ツールも異ならなければならない。