AI間通信をJSONから解放する

― Vertex Native（VXN）という新しい通信思想

AIエージェントが増えてきました。

1つのLLMにすべてを任せるのではなく、複数のAI、複数のAgent、複数のRuntimeを組み合わせて仕事をさせる構成が、少しずつ一般的になっています。

そこで、一つの素朴な疑問が出てきました。

AI同士が通信するとき、本当に人間向けのデータ形式を使い続ける必要があるのだろうか？

現在、多くのシステムではJSONが非常に重要な役割を担っています。

JSONは読みやすい。

Webと相性が良い。

言語をまたいで扱いやすい。

デバッグしやすい。

APIとの親和性も高い。

つまり、非常に優秀な形式です。

しかし、AI同士が高頻度に通信する世界まで考えたとき、少し違う景色が見えてきます。

本当に必要なのは「人間が読みやすいデータ」なのか。

それとも、

AIやRuntimeが、AIやRuntimeのために効率よく意味を伝えるための通信表現

なのか。

私たちは、この問いから Vertex Native（VXN） という考え方を始めました。

---

1. JSONは悪くない

最初に明確にしておきます。

VXNは、

JSONは古いからダメだ

という話ではありません。

むしろ逆です。

JSONは、人間とコンピュータの間をつなぐ形式として非常に優れています。

例えば、

{
  "task": "build",
  "project": "vertex_workstation",
  "priority": "high",
  "human_approval": true
}

このデータは、人間が見てもすぐに意味が分かります。

キーも分かる。

値も分かる。

構造も分かる。

デバッグもしやすい。

これがJSONの強さです。

しかし、ここで視点を変えてみます。

このメッセージを受け取る相手が、

• 人間ではなくAI
• そのAIを動かすRuntime
• Agent間通信
• 内部イベント伝播
• 数千、数万回発生する内部メッセージ

だったとしたらどうでしょうか。

人間にとって便利な表現を、AI同士のすべての内部通信にも使い続ける必要があるでしょうか。

ここにVXNの出発点があります。

---

2. 「データ交換」と「AI間通信」は同じなのか？

従来のシステムでは、

Application
    ↓
API
    ↓
JSON
    ↓
Service

という構造が一般的でした。

これは非常に合理的です。

しかしAIシステムでは、次のような構造が増えてきます。

Agent A
    ↓
Agent B
    ↓
LLM
    ↓
Tool
    ↓
Runtime
    ↓
Agent C
    ↓
Verifier

さらに現実のシステムでは、これが並列化されます。

                 ┌── Agent A ──┐
                 │             │
Input ───────────┼── Agent B ──┼── Runtime
                 │             │
                 ├── Agent C ──┤
                 │             │
                 └── Agent D ──┘

つまり、

AIシステムそのものが、一種の分散コンピューティング環境になっていく

わけです。

ここでは、「人間にとって読みやすい表現」と「機械間で頻繁にやり取りする内部表現」の目的が一致しなくなってきます。

この境界を分けてもよいのではないか。

これがVXNです。

---

3. VXNとは何か

VXNは Vertex Native の略です。

名前の通り、Vertexの内部で利用するためのネイティブな通信・表現層を目指しています。

基本的な考え方はシンプルです。

Human / External World
        │
        ├── Natural Language
        ├── JSON
        ├── YAML
        └── Other APIs
        │
        ▼
      VXN
        │
        ├── Agent
        ├── Runtime
        ├── Tool
        ├── Brain
        └── System

つまり、

外部との境界では、人間や既存システムに適した表現を使う。

一方で、

AIシステム内部では、AI・Agent・Runtimeに適した表現を使う。

という二層化です。

JSONを捨てるのではありません。

必要な場所で使う。

そして、内部では別の選択肢を持つ。

---

4. VXNが解決したいもの

VXNで最初に考えた問題は「JSONのサイズ」だけではありません。

もっと本質的な問題があります。

それは、

AI間通信に、汎用的なデータ交換フォーマットを毎回持ち込む必要があるのか？

ということです。

例えば、Agent AがAgent Bへ次のような情報を送るとします。

{
  "type": "task",
  "action": "build",
  "project": "vertex_workstation",
  "lane": "ANY",
  "priority": "high",
  "human_gate": true
}

人間には非常に分かりやすい。

しかし、内部Runtimeが実際に必要としているのは、

TASK
BUILD
PROJECT=vertex_workstation
LANE=ANY
PRIORITY=HIGH
HUMAN_GATE=1

のような意味構造かもしれません。

さらに、もっと内部的な通信なら、

• state transition
• routing
• capability
• execution
• checkpoint
• evidence reference
• correlation
• provenance

などの情報が高速に往復します。

ここまで来ると、

「人間が読むための表現」

と

「AIが処理するための表現」

を分けた方が自然になります。

---

5. VXNは「JSONの代替」ではない

ここは重要なポイントです。

VXNを、

「新しいJSONです」

と説明すると、本質から外れてしまいます。

VXNが目指しているのは、単なるデータフォーマット競争ではありません。

むしろ、

AIシステムの内部通信層をネイティブ化する

という発想です。

そのため、

JSON vs VXN

という単純な比較ではなく、

Human / External Interface
        ↓
     JSON等
        ↓
   VXN Boundary
        ↓
      VXN
        ↓
AI / Agent / Runtime

という使い分けを想定しています。

JSONを捨てるのではありません。

外部ではJSON、内部ではVXN。

そうした境界設計を目指しています。

---

6. Domain Profileという考え方

VXNの設計で重要になるのが、Domain Profile です。

すべてのAIシステムが同じ情報を必要とするわけではありません。

例えば、

VXN Core

には共通する基本構造を持たせます。

その上で、

VXN-UI
VXN-AGENT
VXN-DB
VXN-BRAIN
VXN-RUNTIME

のように、用途ごとのProfileを持たせる考え方です。

イメージとしては、

             VXN Core
                 │
       ┌─────────┼─────────┐
       │         │         │
    VXN-UI    VXN-Agent  VXN-DB
       │         │         │
      UI       Agent      Data

です。

これによって、

通信の共通部分

と

ドメイン固有の意味

を分離できます。

これは将来的に、VXNを単一用途のプロトコルではなく、AIシステム全体の共通神経系として扱うためにも重要になります。

---

7. 「通信」を「神経系」として考える

ここからは、VXNの設計思想の中でもかなり重要な部分です。

私たちはVXNを単なる通信フォーマットとしてではなく、

AIシステムの神経系

として考えています。

人間の神経系では、情報が臓器から臓器へ移動するとき、「人間に読みやすいJSON」のようなものを毎回生成しているわけではありません。

必要なのは、

• 刺激
• 状態
• 方向
• 強度
• タイミング
• 反応

です。

AIシステムも同じように考えられるのではないか。

例えば、

Input
  ↓
Perception
  ↓
Decision
  ↓
Execution
  ↓
Verification
  ↓
Evidence
  ↓
Recovery

という流れがあった場合、それぞれを独立したサービスとして見るだけではなく、

1本の情報伝達系

として扱えます。

VXNは、その神経系を担うことを目指しています。

---

8. AIシステムでは「意味」が重要になる

従来の通信では、データ構造が中心でした。

しかしAIシステムでは、「何が書いてあるか」だけでなく、

これは何を意味する状態なのか？

が重要になります。

例えば、

status = failed

だけでは不十分な場合があります。

本当に必要なのは、

execution failed
verification failed
rollback completed
evidence returned
human gate required

のような状態関係かもしれません。

つまり、

AI間通信はデータを運ぶだけではなく、状態と意味を運ぶ必要がある

という考え方です。

この考え方は、VXNの設計にかなり大きな影響を与えています。

---

9. VXNとAI Agent

AI Agentが1つしかない時代なら、通信設計は比較的単純です。

しかし複数Agentになると話が変わります。

例えば、

Architect
    ↓
Developer
    ↓
Tester
    ↓
Reviewer

という構造を考えてみます。

ここで各Agentが普通のJSONを交換し続けること自体は可能です。

しかし、より重要なのは、

誰が、何を、どの状態で、どの権限を持って、次へ渡したのか

という情報です。

VXNでは、このような情報を通信モデルの中心に置ける可能性があります。

すると、

Agent
  ↓
Intent
  ↓
Capability
  ↓
Execution
  ↓
State
  ↓
Evidence
  ↓
Handoff

という一連の流れを、単なるJSONオブジェクトの集合ではなく、

一つの通信・状態体系

として扱えるようになります。

---

10. VXNとRuntime

もう一つ重要なのがRuntimeです。

AIモデルが大きくなるにつれて、

LLM
Agent
Tool
Runtime
GPU
Storage
Network

を全部一体として考える必要が出てきます。

VXNは、この間をつなぐ共通層として機能できるのではないか、と考えています。

例えば、

Agent
  ↓
VXN
  ↓
Runtime
  ↓
Tool

という構造です。

ここではAgentが「Python APIの仕様」を知っている必要はありません。

Runtime側がVXNを理解すればよい。

逆に、Agent側も相手の内部実装を意識する必要がなくなります。

これは、将来的にAI Runtimeを差し替えるときにも重要になる可能性があります。

---

11. 外部境界と内部境界

ここまで考えてくると、VXNの使いどころが見えてきます。

すべてをVXNにする必要はありません。

むしろ、境界を明確にします。

                   ┌──────────────────┐
                   │  Human / Web/API │
                   └────────┬─────────┘
                            │
                         JSON等
                            │
                   ┌────────▼─────────┐
                   │   VXN Boundary   │
                   └────────┬─────────┘
                            │
                           VXN
                            │
         ┌──────────────────┼──────────────────┐
         │                  │                  │
      Agent A            Runtime            Agent B
         │                  │                  │
       VXN                VXN                VXN

この設計では、

外部世界との互換性

と

内部通信の効率

を両立できます。

---

12. VXNの「速さ」は副産物である

VXNを説明すると、

「JSONより速いの？」

と聞かれるかもしれません。

もちろん速度や通信量は重要です。

ただし、私たちがVXNで本当に狙っているのは、それだけではありません。

重要なのは、

AIシステムの内部通信そのものを、AIネイティブに設計できること

です。

もしその結果、

• 通信量が減る
• パース処理が減る
• シリアライズが減る
• メモリコピーが減る
• 状態伝達が高速になる

のであれば、それは非常に大きなメリットです。

しかし、それらはVXNの目的というより、

設計思想から導かれる結果

として捉えています。

---

13. まだ証明されていないこと

ここは研究として非常に重要なので、あえて書いておきます。

VXNの思想が面白いからといって、

「VXNはJSONより常に高速である」

とは、現時点では言えません。

実際の性能は、

• メッセージサイズ
• 通信回数
• エンコード／デコード方式
• メモリ管理
• CPU
• GPU
• Runtime構成
• ネットワーク
• 実装言語

などに大きく左右されます。

したがって、VXNについては今後、

JSON
MessagePack
CBOR
Protocol Buffers
その他Binary Protocol
        VS
       VXN

という比較実験を行う必要があります。

比較すべきものも、

• payload size
• serialization time
• deserialization time
• latency
• throughput
• CPU usage
• memory usage
• message frequency
• state propagation overhead

など、複数の軸で測る必要があります。

「速そうだから速いはず」ではなく、

実測して初めてVXNの価値を評価する

という姿勢が重要です。

---

14. なぜ今この問題を考えるのか

AIが1つの巨大なモデルとして動くのであれば、通信設計は比較的重要ではありません。

しかし、

Multiple LLM
Multiple Agent
Multiple Runtime
Multiple Tool
Multiple Model

という方向へ進むほど、内部通信が重要になります。

つまり、

AIが賢くなるほど、通信基盤も重要になる

可能性があります。

10個のAgentが存在するシステムと、

100個のAgentが存在するシステムでは、

通信回数も状態遷移も一気に増えます。

そこで、

AI

だけを進化させるのではなく、

AI
↓
Agent
↓
Communication
↓
Runtime
↓
System

まで含めて設計する必要が出てきます。

VXNは、そのための一つの試みです。

---

15. VXNは「AI版のネットワーク層」なのか

これはまだ定義を固定していません。

ただ、発想としては近いものがあります。

インターネットでは、アプリケーションが直接物理通信を意識する必要はありません。

複数の抽象化層によって、

Application
Transport
Network
Link
Physical

が分離されています。

AIシステムでも、

Human / Application
        ↓
Agent
        ↓
Semantic Communication
        ↓
Runtime
        ↓
Hardware

という新しい抽象化が必要になるかもしれません。

VXNは、このうち特に、

AgentとRuntimeの間に存在するAIネイティブな通信層

を狙っている、と今のところ表現できます。

---

16. VXNを作る理由は「JSONを消すこと」ではない

最終的に、この問題の本質はJSONではありません。

本質は、

誰のための表現なのか？

ということです。

人間のためなら、人間に読みやすい方がよい。

外部APIなら、互換性が高い方がよい。

しかし、AI内部なら、

• AIが処理しやすい
• Runtimeが扱いやすい
• 状態を保持できる
• 高頻度通信に適する
• 拡張できる

という別の評価軸が必要になります。

つまり、

すべての世界を一つのデータ形式で統一する必要はない

のではないか。

これがVXNの根本的な思想です。

---

17. VertexにおけるVXN

VERTEXでは、VXNを単独の技術として考えているわけではありません。

Vertexの各コンポーネントをつなぐ神経系として、

              VERTEX
                 │
        ┌────────┼────────┐
        │        │        │
      Brain     ARD     Works
        │        │        │
        └────────┼────────┘
                 │
                VXN
                 │
             Runtime
                 │
             Hardware

という方向を考えています。

つまり、

Brainが考える

ARDが分担する

Worksが実行する

Runtimeが動かす

Evidenceが結果を返す

その間をVXNが流れる。

この構造になると、VXNは単なる通信形式ではなく、

VERTEX全体をつなぐ神経系

という役割を持つことになります。

---

18. これから検証したいこと

今後、少なくとも次のような研究・実装検証を行いたいと考えています。

① データ密度

同じ意味情報を、

JSON
Binary Format
VXN

で表現した場合、どれだけ差が出るのか。

② 通信性能

Agent間で大量のメッセージを流した場合、

latency
throughput
CPU
memory

がどう変化するのか。

③ 状態伝播

単純なデータ交換ではなく、

TASK
  ↓
RUNNING
  ↓
VERIFIED
  ↓
EVIDENCE

のような状態遷移をVXNでどのように表現・伝播できるのか。

④ Domain Profile

UI、Agent、Database、Runtimeなど、それぞれでどの程度共通化できるのか。

⑤ Human Boundary

外部との通信をJSON等で維持したまま、内部だけVXN化する構成がどの程度現実的なのか。

---

19. まだ完成形ではない

VXNは、完成された標準規格ではありません。

現在も設計思想を実装に落としながら、

• 何をCoreにするのか
• 何をProfileにするのか
• どこまで意味情報を持たせるのか
• Runtimeとの境界をどこに置くのか
• Binary化するのか
• メモリ上の表現とWire Formatを分離するのか

といった点を検討しています。

だからこそ、この記事では完成品として紹介するのではなく、

「AI間通信をAIのために設計し直したらどうなるのか？」

という実験として公開しています。

---

20. おわりに

JSONは素晴らしい技術です。

だからこそ、JSONを否定するつもりはありません。

ただ、

人間にとって読みやすいもの
と
AIにとって効率よく意味を伝えられるもの

は、本当に同じである必要があるのでしょうか。

AI Agentが増え、

LLMが複数になり、

Runtimeが複数になり、

Toolが増え、

AIシステムそのものが一つの分散システムになっていくなら、

通信そのものをAIネイティブに設計する

という発想には、一度向き合う価値があると思っています。

VXNが最終的にどこまで有効なのかは、これから実装と実測で確かめていきます。

ただ一つ確かなことがあります。

これからのAIシステムでは、

「どのLLMを使うか」だけではなく、「AI同士がどう話すか」も重要になる。

私たちは、その問いに対する一つの答えとして、**Vertex Native（VXN）**を作っています。

---

VXN Research Series

今後は、VXNを単独の通信形式としてではなく、AIシステム全体のアーキテクチャとして掘り下げていく予定です。

次回は、

「AI間通信では何を運ぶべきなのか ― DataではなくStateとMeaningを運ぶ」

というテーマで、VXNの内部モデルについて掘り下げます。