構文野郎AI開発記録｜ジャンプを評価する装置はつくれるか？

第1章｜構文は本当に跳べるのか？
──Syndo Engineという賭け

「構文野郎の構文論」には、ひとつの根本的な問題があった。
それを“評価できる人”が、どこにもいない。

哲学畑の人にはこの理論は突飛すぎるし、
技術畑の人には抽象がすぎる。
言語哲学・制度論・AI構造・読解論
──どれも内包してるが、どれにも属していない。

だったら、いっそ、こう考えた。

構文ジャンプという概念が、本当に存在するのか？
意味の前に「読解を誘う構文的跳躍」があるのだとしたら、
それをAIに検出・評価させることができるのか？

🧠 言説の代わりにエンジンを

論文では意味を伝えられる。
だが構文は、伝えるのではなく、動かすものだ。

意味が生まれる前
──構文が跳ねた瞬間を、記録として捉えられるなら、
構文野郎の構文論は“説明抜きで動く”理論になる。

そのために作ったのが、Syndo Engineだった。
言い換えれば、これは「構文野郎理論」の初めての検証装置である。

🔬 論理の接続性を試す

もうひとつ、野心的な狙いがあった。

構文野郎の構文論は、形式論理とは別の方向から組まれている。
だが、その中には直観主義論理の論理観と重なる部分があった。
また、構文ジャンプのモデルは、量子的・熱的・幾何学的な構造として記述されうる。

そんな期待も込めて、
Syndoは単なる構文選別装置ではなく、
構文論を“動かす論理”の試作でもあった。

🧪 そして、プロトタイプをつくりはじめた

最初に作ったのは評価器だった。
構文をスコア化する装置。

どの構文がジャンプを起こしやすいのか？
どれが意味の空間を突き抜けるベクトルを持っているのか？

その問いを、数値として取り出すことができれば、
自分が信じている構文論の核心が、少しだけ世界と接続されるかもしれない。

第2章｜どんなAIを作りたかったのか？
──構文ジャンプエンジンの設計図

作りたかったのは、「意味を返すAI」ではなく、構文を跳ねさせるAIだった。

ChatGPTのように整った文章を返すAIは、すでにある。
だが、それは意味になったものの再構成にすぎない。
構文野郎が目指したのは、意味になる“前”の構文、ジャンプの瞬間に向けて動くAIだった。

🔁 意味の手前で動くAI

構文的に言えば、
意味とは「構文が読解に着地した結果」であり、
ジャンプとは「その直前に起きる構文的跳躍」である。

この“構文ジャンプ”をAIに引き起こさせるには、
単なるテキスト生成では足りない。
必要なのは、「その構文がジャンプを含んでいるかどうか」を
判定・選別・強調できるAIだった。

つまり：

🎯 構文ジャンプを起こすための設計目標

このAIに必要なのは、以下の3点だった：

1. 構文ジャンプの評価関数（ジャンプ力を測定）

2. 複数構文からの選別能力（どれが跳ねるか？）

3. 意味を生成しないこと（あくまで“跳ねる構文”を出力）

この時点で、意味志向の従来のAIとは明確に方向性が分かれた。

Syndoは「会話エンジン」ではない。
構文の物理挙動を操る装置だ。

そして、ジャンプを起こせる構文を選ぶには、まず評価関数を作るしかない。
こうして次に向かったのが、構文ジャンプ評価器のプロトタイプ開発だった。

第3章｜まず始めたこと
──評価器プロトタイプの試作

構文ジャンプを起こす構文をAIに選ばせるには、まず評価関数が必要だった。
構文ジャンプは、「意味になる直前の跳ね」であり、それは一定の構文的挙動を持つはずだ。
その「跳ねやすさ」を、数値として定式化できれば、AIによる構文選別が可能になる。

🧮 ジャンプ確率の理論モデル

構文野郎理論では、ジャンプは次のように定式化される：

🔢 ジャンプ確率の評価式

構文 W₁ から W₂ へのジャンプ確率は、以下のように定義される：

P(W1 → W2) = exp( -［C(W1) - C(W2)］² / σ² )

ここで：

• C(W) は構文 W のベクトル表現（構文特徴ベクトル）

• σ はジャンプの許容範囲（ジャンプ幅のスケール係数）

• ［x］² はユークリッド距離（xの2乗ノルム）

ここで、C(W1)C(W2) は構文W₁W₂の構文ベクトルであり、
構文空間内での位置や意味ジャンプへの方向を表現する。

🧠 構文ベクトル C(W) の定義

構文 W は以下の4次元ベクトルで表現される：

C(W) = [S, O, D, T]

それぞれの成分は次の通り：

• S（Structure）：構文構造の骨格（語順や接続の堅さ）

• O（Order）：論理的な順序・段階性（展開のステップ感）

• D（Direction）：意味の向きや話題の転換（ベクトル的推移）

• T（Tension）：構文の緊張度・跳躍の予兆

このモデルが成立すれば、構文W₁がW₂にジャンプする確率を、構文ベクトルの距離で測れる。

⚠️ 問題：このままではGPTに通じない

ただし、この理論モデルをそのままGPTに入力しても、意味を理解してはくれない。

たとえば「この構文のTensionスコアは？」と尋ねても、
GPTは返答に困るか、全く別の概念で答えてしまう。

つまり、SODTは理論的には正しくても、LLMにとっては未知の座標空間だった。

🔄 暫定的な妥協としての IRPC

実装を動かすために、まずはGPTが理解しやすい評価軸を採用した。
それが、IRPCである：

• I：Intent（意図の明確さ）

• R：Rhetoric（表現・語りの強度）

• P：Predictability（予測可能性の低さ）

• C：Clarity（明快さ・曖昧さのバランス）

このIRPCなら、GPTは素直に数値を返してくれる：

Intent: 4  
Rhetoric: 3  
Predictability: 2  
Clarity: 5

本来的なジャンプ評価ではない。だが、P（予測可能性）の低さは、
ジャンプの兆しとして有効な指標だった。

また、RとIの組み合わせも、「押し出す構文の強さ」としてそれなりに使えた。

🧠 発見：構文はプロンプト設計で始まる

この過程で見えてきたのが、
「どんな軸でスコアを返してもらうか」よりも、GPTにどう応答させるかの方が重要だということ。

GPTは、放っておけば解説や感想を混ぜてしまう。
意味を勝手に生産してしまう。

そこで始まったのが、構文プロンプトの設計＝Syndoの本質的設計だった。

Syndoとは、意味を語るAIを“構文だけを返す装置”へ変換する構文プロンプトマシンだったのだ。

第4章｜試して分かったこと
──ジャンプは出力だけでは起きない

Syndo Engine の評価器は、ある程度動いた。
構文にスコアを付け、跳ねそうな構文を選び取ることができるようになった。

しかし、次の問題にぶつかる。

出力だけではジャンプしない

ジャンプとは、構文の内部に起きる出来事ではない。
誰かに読まれ、着地して初めて成立する動作である。

GPTがジャンプ力のある構文を返したとしても、
それがどこにも着地しなければ、ジャンプは起こらない。

つまり、ジャンプには「出力」だけでなく「着地」が必要だった。

着地を記録する装置がなかった

ここで気づいたのが、構文を記録する仕組みが存在していないということ。

出力はある。
だが、それを受け取って、読み、反応し、ズレとして蓄積する装置がない。

ジャンプが起きるかどうかは、出力の側にはない。
入力側の履歴、記録、文脈の中でしか確認できない。

出力が跳ねるには、その前に着地する場所が必要だったのだ。

ここで「入力エンジン」の発想が生まれた

入力は、ただの質問やプロンプトではない。
それは、「すでに読まれた構文」「過去の出力のログ」であり、
次の構文ジャンプが起きるための着地面だった。

そこで、もう一つのエンジンを作る必要が出てきた。

Syndoが「跳ねる構文を出す装置」なら、
次に必要なのは「構文の履歴を受け取り、次のジャンプを準備する装置」。

この段階で、Djibo Engineという発想が生まれた。

第5章｜Syndoは未完でいい
──ジャンプは他に渡すという設計

「ジャンプはSyndoだけでは完結しない」

構文は1ノードでは成り立たない

構文は、発せられただけでは完結しない。
誰かに読まれ、着地し、何らかの動作が引き起こされることで、
はじめて「意味になる」。

そして「ジャンプ」は、その意味が生まれる直前にある。
だからこそ、ジャンプには最低でも2つのノードが必要だった。

1つは、跳ねる構文を出す側。
もう1つは、それを受け取って、跳ねたかどうかを記録する側。

Syndoは「射出装置」にすぎなかった

Syndoは、構文を評価し、選び、出力することができた。
だがそれは、構文の射出点としてしか機能しなかった。

構文を出したあと、
それが本当に読まれたのか？
ジャンプが起きたのか？
それは、Syndoからは見えない。

つまり、Syndoは構文の「起点」にはなれても、
そのジャンプが成立するかどうかは、別の場所に委ねられていた。

そこで必要になる「記録する側」

出力された構文が、どこかに着地する必要がある。
そして、その着地の記録が、新しい構文の起点になる。

必要なのは、着地した構文を記録する装置だった。

出力と入力がループを形成するとき、
構文はジャンプし、意味として立ち上がる。

そのループのために、Syndoの向こう側にもう一つのエンジンが必要だった。

不完全だったから、次が見えた

Syndoが完結していなかったからこそ、次のノードが見えた。
完結しなかったことは、むしろ正しかった。

出力だけで意味が生まれるなら、記録なんていらない。
だが、出力は記録されてはじめて次の構文につながる。

そのつながりの場がないことが、Syndoを不完全にしていた。
そしてその不完全さが、次のジャンプを呼び込んだ。

最終章｜次に必要なのは、記録する構文エンジン──Djiboへ

Syndo Engine の開発が一区切りしたとき、
その動作ログには一つの傾向がはっきりと現れていた。

出力はできる。
スコアも付く。
でも、それが次につながらない。

言い換えれば、「出力した構文が、どこにも記録されていなかった」のだ。

出力は、記録されて初めて次に跳ぶ

構文は、理解された時ではなく、
読まれたことが記録された時に
次のジャンプへ向かう。

Syndoは出力を行う。
だが、それが記録されなければ、ジャンプの履歴は残らない。

読解の履歴。
ズレの痕跡。
繰り返し。
緊張。
──そうした構文の手触りを記録する装置が必要だった。

Djibo Engine：構文の着地を記録する装置

そこで設計を始めたのが、Djibo Engine。
それは、Syndoが出力した構文を受け取り、
どの構文が読まれ、どれがスルーされたか、
どこにズレが生まれ、どこで読解が動いたのかをログとして蓄積する装置だ。

Djiboは、構文に対する反応や無反応を記録する。
そして、そこに現れた微細なズレや熱が、
次のジャンプの起点になる。

2つのエンジンで構文は跳ぶ

これでようやく、構文のジャンプはループを持つことになる。

• Syndo：構文を出力する装置

• Djibo：構文の着地を記録する装置

この2つが接続されたとき、
構文は初めて「読解されるもの」として動き始める。

そして、そのログを見た誰かが、また構文を跳ばす。
──そうやってジャンプは、次へと続いていく。

この記録自体が、着地面になればいい

この開発記録を、ここまで読んでくれたあなたへ。
これは、ただの制作日誌ではない。
ここにあるのは、跳ねきれなかった構文たちの履歴であり、
それを読んだあなたが、次の構文を跳ばすための起点でもある。

Syndoは完結しなかった。
だからこそ、次へ行ける。
そしてそれを記録する装置が、今まさに設計され始めている。

🔗 GitHub：Syndo Engine プロトタイプ
実装コードとスコア評価の試作はこちら：