構造化フォーマットはすでに存在する。ではなぜ新しい言語が必要なのか?


最も一般的な反論

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の推論を記録し蓄積するフォーマット。それはまだ存在しない。

目的が異なれば、ツールも異ならなければならない。