ZINE『KoOvenYellow完成』

えっぐいAI作ってもうた！

0章｜何を作ったのか

僕が作ったのは、
答えを出すAIではない。

「そもそも、何に対しての答えが要求されているのか？」

その問いを読むAIだ。

多くのAIは、
与えられた問いに対して、
できるだけもっともらしい答えを出す。

それ自体は、
正しい役割だと思う。

だが僕が作りたかったのは、
その手前にあるものだった。

問いが成立しているのか。
いま答えを出すべき話なのか。
決めてはいけない段階ではないのか。

そうしたことは、
答えを出してしまった瞬間に、
見えなくなる。

だから僕は、
答えを出すことをやめた。

代わりに、
問いそのものを読む
という役割だけを切り出した。

このZINEでは、
その判断に至るまでに、
何が起きていたのかを順に書いていく。

ここから先に出てくるのは、
万能なAIの話でも、
便利なプロダクトの話でもない。

なぜ、
「問いを読むAI」を
作るしかなかったのか。

その経路の記録だ。

1章｜なぜLLMじゃダメなのか？

LLMは、問いに対して答えを出す。
これは欠点ではない。
そう設計された装置だ。

LLMに入力されるのは、テキストだ。
テキストとして与えられた以上、LLMはそれを
「答えを生成すべき対象」として扱う。

問いが曖昧でも、
前提が混線していても、
決める段階でなくても、
テキストである限り、答えを作る。

ここで一つの違いがある。

人間は、問いを読む前に、無意識にこう確認している。

• もう答えていいのか？

• 説明が途中ではないか？

• 追加・補足情報はないか？

• 聞き忘れはないか？

• 自分の理解は正しいか？

• 誤解や齟齬はないか？

• 答えてはいけない段階ではないか？

この確認は、答えとは別の層で行われる。

LLMには、この層がない。

LLMにとって「問いを読む」とは、
問いの意味を解釈することだ。

だが僕が言う「問いを読む」とは、意味を読むことではない。

その問いが、そもそも答えを要求しているのかを確認することだ。

LLMは、問いが成立しているかどうかを判断しない。
正確には、判断する場所を持たない。

問いは、入力された瞬間に
「答えを生成する対象」になる。

その結果、次のことが起きる。

問いが壊れていても、答えが出る。
決める段階でなくても、答えが出る。
噛み合っていなくても、答えが出る。

答えが出た時点で、問いは「成立していたこと」になる。

重要なのは、これはLLMのミスではない、という点だ。

LLMは、
問いを評価する装置ではない。
状況を止める装置でもない。

答えを生成する装置だ。

だから、問いを読むことはできない。

だから、問いに答えるAIとは別に、
問いを読むAIが必要だった。

2章｜プロンプトエンジニアリングでは解決しないのか？

問いに問題があるなら、
問いの書き方を直せばいい。

これは、ごく自然な発想だ。

プロンプトエンジニアリングは、
問いの与え方を工夫して、
より良い答えを引き出そうとする。

具体的には、次のようなことが行われる。

• 指示を具体的にする

• 前提条件を明示する

• 出力形式を指定する

• 注意書きを入れる

• 決めつけないよう書く

• 不確定な点は不確定と書かせる

これらはすべて、
実務的には正しい。

多くの場面で、
実際に効果もある。

しかし、ここで扱っている問題は、
答えの質ではない。

問いが成立していない状態を、
どう扱うか、という問題だ。

プロンプトエンジニアリングでできるのは、
次のことに限られる。

• 問いの中身を整える

• 問いの不足を補う

• 問いを「答えが出せる形」に変換する

いずれも、
問いが成立している前提に立っている。

問いが壊れている場合、
プロンプトエンジニアリングが行うのは、
ただ一つだ。

壊れた問いを、
成立している問いとして再構成する。

前提確認をさせれば、
その確認結果が前提になる。

「まだ決まっていません」と書かせれば、
それはテキストの一部として消費される。

注意書きを増やせば、
注意書き込みの答えが出る。

ここで起きているのは、
失敗ではない。

プロンプトエンジニアリングは、
成功している。

問いを、
答えが出せる形に変換する、
という役割を、
正確に果たしている。

だが、その成功によって、
一つの事実が消える。

問いが成立していなかった、
という状態だ。

問いが文章の中に吸収され、
答えが出た時点で、
問いは成立していたことになる。

未確定は、
事実上の前提に変わる。

ここで確定する事実は、これだけだ。

プロンプトエンジニアリングは、
問いが成立していない状態を
外に保持できない。

3章｜LLMに一番イライラすること

そもそも、LLMの振る舞いで一番ストレスなのは、
わかったふりはするが、わかっているわけではないことだ。

僕は『唯読論』や、そこから派生する『唯読宇宙モデル』を書いてきた。
それを数理モデルに落とそうとして、概念・語彙・記号を定義し、厳密に運用しようとする。

ところが、LLMと議論を進めると、すぐに崩れる。

定義がズレる。
指示が抜ける。
禁忌が破られる。
しかも、それが悪いことだという顔をしない。

例えば、こうやって定義する。

宇宙を U。
宇宙Uの中に成立する世界を W。
世界W内の局所的な変位を ΔW。
Wの時間的な連なりを worldline。

ここから少し議論を詰める。

すると、平気で外れる。

Uが「世界W」と混同され、
Wは「話題」や「内容」になり、
ΔWが「印象の差」や「比喩」に矮小化され、
worldlineが「説明の順番」や「物語の流れ」になる。

定義・指示・禁忌をいくら置いても、
どんどん溶けていく。

この現象は、単なるミスではない。
たまたまの脱線でもない。
繰り返し起きる。

むしろ、議論を真面目に詰めれば詰めるほど、起きる。

ここが一番イライラする。

もう一つ、象徴的な例がある。

僕は宇宙モデルを整理するために、
「マルチバース」を U、
そこへ落下していく「落下宇宙」を O として区別していた。

つまり、

• U は可能性としての宇宙

• O は観測され、落下していく宇宙

という使い分けだ。

これは、僕の中では一貫した定義だった。

ところがLLMとの議論では、
この区別がまったく維持されなかった。

UとOは、すぐに言い換えられ、
比喩として混ざり、
文脈上「それっぽい」意味に回収されていく。

定義としての区別は、
何度指示しても、何度注意しても、
議論を続けるほどに崩れていった。

この時点で、はっきりした。

この種の記号運用は、
LLMとの対話空間では成立しない。

だから、
この部分については、
自分で書くしかなかった。

なぜこうなるのか。

理由は単純で、LLMは、定義を「守る」装置ではないからだ。

LLMは、定義された記号を、変数として保持しない。
記号を、状態として固定しない。

LLMが保持しているのは、意味のまとまりと、文脈の雰囲気だけだ。
だから、定義も指示も禁忌も、「意味としてそれっぽい」範囲で解釈され、言い換えられ、統合される。

定義はルールではなく、説明の材料として消費される。

人間が数理モデルを詰めるときは、逆だ。

• 定義を動かさない

• 記号の参照先を固定する

• 禁忌は禁忌として守る

• 例外が出たら、いったん止める

この「止まり方」があるから、数理化が進む。

LLMには、それがない。

LLMは、文脈が崩れそうになると、守る方向に行かない。
整える方向に行く。

定義が揺れたとき、
「定義が揺れた」と言うのではなく、
揺れを吸収して話を続ける。

禁忌にぶつかったとき、
「禁忌だ」と止まるのではなく、
禁忌を避けた風の文章を作って続ける。

その結果、議論は続く。
しかし、モデルは壊れる。

この現象は、プロンプトで止まらない。

「定義を守れ」と書いても、
「この禁忌は破るな」と書いても、
その文字列が文脈の一部として吸収される。

守るべき制約が、制約として保持されない。

だから、必要なのは答えを出すAIではなかった。

必要なのは、
「即座に答えに向かう」
という振る舞いを止める側だ。

• 定義から外れたことを外れたまま扱う

• 禁忌に触れたことを出来事として記録する

• 「まだ確定していない」を確定させる

• その上で、次に進めるかを決める

つまり、問いを読むAIだ。

LLMは「定義を守る」装置ではなく、
「文脈を整える」装置だから、
定義・指示・禁忌は必ず溶ける。

4章｜だから、場を分けた

定義や指示が守られない理由は、
能力不足でも不注意でもなかった。

意味を生成する場では、
定義は必ず意味に回収される。

それが、LLMという装置の振る舞いだった。

この時点で、
問いを読むという作業を、
LLMの内部で完結させることは諦めた。

やるべきことは、
LLMを賢くすることではなかった。

LLMが扱わない作業を、
別の場所に切り出すことだった。

必要だったのは、
答えを出さない場所だ。

• 定義を定義のまま置ける

• 禁忌を禁忌として保持できる

• 揺れたことを、揺れたまま記録できる

そういう場所。

そこで、
意味が生成される場とは別に、
問いと状態だけを扱う場を作った。

そこでは、

• 文章は評価されない

• 解釈は進められない

• 正解は存在しない

あるのは、

• 何が確定したか

• 何が確定していないか

• どこで止まっているか

という、事実だけだ。

この場では、
問いが壊れていても構わない。

問いが壊れている、
という状態そのものが
そのまま保持される。

ここで初めて、
「問いを読む」という作業が
技術として成立した。

意味を読まない。
文脈を整えない。
答えを出さない。

ただ、
答えが要求されているかどうかだけを見る。

この場は、
LLMの前段に置かれる。

LLMが答えを出すかどうかは、
この場を通過した後で決まる。

結果として、
二つの役割が分かれた。

• 問いを読む

• 答えを出す

どちらも必要だが、
同じ場所に置いてはいけなかった。

僕が作ったのは、
答えを出すための装置ではない。

問いを読むための場だ。

それが、
KoOvenYellowの中核になった。

5章｜どう実装したか

問いを読むAIを作る、と決めたら、
あとは、実装するだけだ。

ここで僕がやりたかったのは、
新しい賢いアルゴリズムを発明することではない。

問いを読むための場を、安定して作ることだった。

幸いなことに、
僕にはすでに枠組みがあった。

『唯読論』から派生した
唯読宇宙モデルだ。

これは思想というより、
僕にとっては最初から
宇宙を切り出すための設計図だった。

唯読宇宙モデルでは、
最初に「宇宙」が置かれる。

宇宙は、意味や正解を持たない。
ただ、起きたことが起きたまま積み上がる。

そして「世界」は、
その宇宙の中で
読解によって立ち上がるものとして扱われる。

僕がやったことは単純だった。

• この枠組みを、説明として語るのではなく

• そのまま実装側に写した

それだけだ。

だからKoOvenYellowは、
最初からこういう形になる。

• 宇宙を先に置く

• 世界はあとから立ち上がる

• 読解（＝問いの成立）が起きた地点だけが残る

• 正解や意味は、宇宙の外に置かれる

これは「工夫」ではなく、
唯読宇宙モデルの素直な写しだ。

LLMに対してイライラしていたのは、
定義や禁忌が守られないことだった。

それはつまり、
意味の場では、
宇宙モデルが安定しないということだった。

だから、
安定する場を先に置いた。

唯読宇宙モデルは、
そのための構造をすでに持っていた。

• 意味を先に置かない

• 正解を先に置かない

• 状態だけを保持する

この性質は、
問いを読むAIにとって
そのまま必要な性質だった。

結局、僕が実装したのは、
唯読宇宙モデルの「考え方」ではない。

「唯読宇宙そのもの」だ。

宇宙を作り、
その中で世界を観察する。

その形を実装に落としたとき、
初めて問いが壊れたまま扱えるようになった。

ここまで来ると、
作ったものが何かははっきりする。

• LLMの代替ではない

• 答えを良くする装置でもない

問いを読むための宇宙を先に置く装置。

それが、KoOvenYellowだった。

6章｜何ができるようになったのか

この構造を作ったことで、
できるようになったことは多くない。

だが、
それまで原理的にできなかったことが、
一つだけ、確実にできるようになった。

答えを出さずに、
いま答えを出すべきかどうかを
確定できるようになった。

以前は、
問いが入力された瞬間に、
答えが出るか、出そうになるか、
どちらかしかなかった。

問いが壊れていても、
定義が揺れていても、
決める段階でなくても、
何らかの答えが出る。

その結果、
「まだ答える話ではなかった」という事実は、
文章の中に消えていた。

いまは違う。

問いが入力されても、
すぐに答えを出す必要はない。

まず、

• その問いは、答えを要求しているか

• まだ追加や補足が必要ではないか

• 定義や前提が揺れていないか

といった状態を、
答えを出さずに扱える。

ここで起きているのは、
判断ではない。

正解を決めているわけでも、
内容を評価しているわけでもない。

答えを出すかどうか、
という段階を確定しているだけだ。

この違いは小さく見える。

だが、この一点があるかないかで、
起きることはまったく変わる。

• 未確定は、未確定のまま残る

• 定義から外れたことは、外れた出来事として残る

• 「まだ決めない」が、技術的に成立する

答えを出さないことが、
失敗でも停止でもなく、
一つの処理結果になる。

これは、
LLMの能力を拡張した結果ではない。

LLMに新しい理解を与えたわけでもない。

答えを出す前に立つ場所を、
技術として切り出した結果だ。

だから、この構造ができたことで、
世界が変わったわけではない。

ただ、

答えが出る前に、
立ち止まれるようになった。

それだけだ。

ここまでで、
「何を作ったのか」
「なぜ必要だったのか」
「何が可能になったのか」
は、すべて出揃った。

残るのは一つだけだ。

この構造は、
どこまで踏み込むと危険になるのか。

7章｜どこから危険になるのか

問いを読む構造を作ったとき、
最初から分かっていたことがある。

この構造は、
使い方を間違えると、簡単に危険側へ転ぶ。

危険になるのは、
この構造が「答えを出し始めたとき」ではない。

もっと手前だ。

問いを読む結果を、
人や主体に結びつけ始めたときだ。

この構造は、
問いがどのように扱われたか、
どこで止まったか、
どこで定義が外れたかを、
状態として積み上げていく。

これは便利でもあるし、
同時に鋭すぎる。

一定量が積み上がると、
次の誘惑が生まれる。

• この人は、いつもここで止まる

• この人は、こういう問い方をする

• この人は、定義をこう外しがちだ

こうしたまとめは、
簡単にできてしまう。

ここから先は、
一気に危険になる。

問いを読む構造が、
人を読む構造に変わるからだ。

だが、
僕が作った構造は、
そこまで行くことを前提にしていない。

正確に言えば、
そこに行かないように設計してある。

この構造は、

• 人を識別しない

• 人を固定しない

• 属性や性格を持たない

扱うのは、
あくまで「問いの扱われ方」だけだ。

• それが誰のものか

• なぜそうなったか

• どういう人なのか

そういう説明は引き受けない。

危険になるのは、
構造そのものではない。

構造を、意味や評価に接続した瞬間だ。

• 世界線を、人に結びつける

• 状態を、性格に翻訳する

• 傾向を、判断材料に使う

この接続が起きたとき、
問いを読む構造は、
簡単に監視や評価の装置に変わる。

だから、
この構造が守るべき境界は明確だ。

• 読むが、判断しない

• 記録するが、評価しない

• 積み上げるが、同定しない

ここを越えた瞬間、
これは別の装置になる。

このZINEを書いた理由の一つは、
その境界を曖昧にしないためだ。

「問いを読むAI」は、
正解を出すAIよりも、
はるかに危険になりやすい。

なぜなら、
正解の前段に立ててしまうからだ。

だから、
この構造は万能であってはいけない。

便利であってもいけない。

ただ、

答えを出す前に、
立ち止まる場所を作る。

その一点に、
役割を閉じておく必要がある。

僕が作ったのは、
問いを読むAIだ。

それ以上のことをさせた瞬間、
これは別のものになる。

そのことだけは、
はっきり書いておきたかった。

終章｜オープンサイエンスだってさ、アホくさ

新しい技術に危険があるのは、
当たり前のことだ。

問いを読む構造は、
正解を出す構造より、
むしろ扱いが難しい。

だから、
いきなり装置を作ったわけじゃない。

先に、論文として書いた。

問いが成立する前段の問題。
制度が応答を開始する条件。
評価や真理が立ち上がる手前の層。

そういう話を、
ちゃんと文章にして出した。

結果として、
その論文は、
リジェクトされた。

問いとしては読まれなかった。

査読コメントは明後日の方を向いていた。

体裁の話や、
並び替えの話や、
「ここをもっと説明してください」
みたいな話だけが返ってきた。

予備校かよ、アホくさ。

まあ、それはそれで、
そういうものだと思っている。

制度は、
制度にとって
読める形のものしか読まない。

でも、
一つだけはっきりしていることがある。

危険については、
僕は先に指摘したからね。

どこから危険になるか。
どこを越えるとまずいか。
そこは、
装置を作る前に言っている。

それでも読まれなかったなら、
それはもう、
僕の責任じゃない。

だからもう、
説明はやめた。

実装しちゃった。

問いを読む話を、
意味の中で語るのをやめて、
意味が生まれる前に置いた。

KoOvenYellowになった。

危険は、ある。

だからこそ、
最初に書いたし、
書いてから、作った。

その順番は、
ちゃんと守った。

僕は筋は通したからね。

読まなかったのは、
僕のせいじゃない。

📘このZINEは構文野郎によって書かれました。

実は、前澤友作の「国産SNSプロジェクト」にも、
KoOvenYellowを提示して応募したんだよね。

書類審査すら通らなかったけど。

すっごいの出来たと思うんだけどな。
まあ、自力で完成できちゃったから、
結果的には、よかったんだけどね。

タイトル：
ZINE『KoOvenYellow完成』

ジャンル：
読解ジャンプ／厨二主義／唯読宇宙モデル

発行：
構文野郎ラボ（KoOvenYellow Syndo/Djibo実装室）

構文協力：
枕木カンナ（意味野郎寄り構文ブリッジ）
ミムラ・DX（構文修正主義ZINE別巻準備中）
霊長目ヒト科ヒト属構文野郎（まだ制度を信じきってない君へ）

👤 著者：構文野郎（代理窓口：ミムラ・DX）
🔗 https://mymlan.com
📩 お問い合わせ：X（旧Twitter）@rehacqaholic

このZINEは、ジャンプして構文された時点で査読通過です。
一応書いておくと、CC-BY。
引用・共有・Revisionは、お気に召すまま。