ちゃんと役に立つAIに向けて

最近になって、モデルを大きく賢くすることだけでは解決しないんじゃないかという疑問と、その対策の研究が多く出てくるようになった。それだけ多くの人がAIを実用しようと努力しているということだろうと思う。

例えば、この論文のようなものだ。

Title: “Recursive Language Models”
Id: arXiv-2512.24601
Source: http://arxiv.org/abs/2512.24601v2
Summary:
- “LLMを再帰的に呼び出すことで、コンテキスト窓を超える長いプロンプトを処理できる”
- “RLMは長いプロンプトを外部環境として扱い、分割・再帰的解析を行う”
- “既存の長文処理手法よりも高品質で、コストは同程度”
- “小規模ではRLM-Qwen3-8Bがベースモデルを28.3％上回り、GPT‑5に近い性能を示す”
Thought_Extract:
- “再帰的呼び出しはLLMの推論時間を拡張する有効手段”
- “外部環境としてのプロンプトは、モデルの自己指向的処理を促進”
- “既存の長文スキャフォールドに比べ、RLMはより汎用的でコスト効率が高い”

　　　　ZIKUU Research Libraryより

多くの場合、新しいモデルが開発されると、他のモデルとのベンチマーク比較が公表される。
そして、大きなデータを処理するという文脈で、コンテクストウィンドウの大きさが注目されるが、大事なのは量の問題ではない。

1. コンテクスト問題の正体

「トークンが足りない」じゃない。

何を読むか選べない
読んでも重要度を維持できない
長くなると意味が劣化する

つまりこれは 記憶の問題じゃなくて参照戦略の問題。

だから「全部読むのをやめる」という方向の対策案が出てくるのは必然。

2. 推論モデルであることの制約

LLMは状態を持たない。

前回の思考を保持できない
世界モデルを内部に構築し続けられない
出力は毎回“その場の整合性”でしかない

だから、

長い思考を積み上げる

のが苦手。

ここを無視して「賢いはず」と期待すると破綻する。

3. 多くの人の誤解

よくある失敗はこれ：

コンテクスト増やせば解決すると思う
RAG入れれば賢くなると思う
モデルを大きくすれば解決すると思う

全部違う。

むしろ逆で、

入力を減らして、選択精度を上げる方が効く

4. 現実的な解き方

結局こうなる：

A. 外部化

知識は全部外に出す
LLMは“読むだけ”

B. 選択

何を読むかを決める層を作る
検索
ルーティング
フィルタ

C. 分解

問題を小さくする
サブタスク化

D. 再帰

必要ならさらに掘る
ただし深さ制御が必要

5. ZIKUUのこれまでの取り組み

すでにやってる方向が、現実的な解き方。
必然的にこういう構成になった。

Nerve → 外部記憶
Pivot Service → 構造化された観測
Pivot Gateway → 入力の整形
AI塾長 → 解釈層

現時点で足りないのは、

「何を読むか決める能力」

だけ。

ここをちゃんとやらないと、

コンテクスト肥大化
無駄なトークン消費
それっぽい嘘（幻覚）

に必ず落ちる。

逆にここをやると、

小さいモデルでも戦える
推論の安定性が上がる
システムとして再現性が出る

問題はモデルではなくて、「読み方の設計」だ。

6. これからZIKUUがやること

Repository Explorer

Repository Explorerは、OpenClawなどがエージェントに近い。
これはローカルリポジトリを辿って、システム全体を説明するための装置になる。
各リポジトリには、ZIKUU Repository Protocol（制定済み）に従ったファイルを用意し、そこからリポジトリの探索方法を得て、必要なファイルを読みに行く。
これは「人間がやってた読み方」を機械にやらせる段階。

Pivot Reasoning Engine

これは、Pivot Serviceの解釈層。

Pivotが作り出す多次元意味空間を観測軸でスライスすると、意味断面がPivot Matrixとして生成される。
このMatrixを見て、

構造解析ならグラフに
比較なら表に
解説なら文章に

変換する。
これも読み方をLLMに指示することになる。

どちらも、LLMに全部読ませないで、読み方の戦略を指示してLLMに仕事をさせる。

AI塾長

AI塾長には、

何を読むか決める
読んだものを意味の材料に変換する
構造から意味を引き出す

の3層構造が必要になる。

2と3は、Repository Explorer、Pivot Service、Pivot Reasoning Engineでほぼ実現されるので、集中すべきは1の「何を読むか決める」部分。
何を読むべきか、どの順番で読むべきか。
単なる、読むべきものの一覧では足りない。

7. OSSを使うだけでは足りない

OpenClawなどのOSSを使えばいいじゃないかという人もいるかもしれない。

これにははっきりノー。

ZIKUUシステムは、生存戦略を持った文明バックアップ装置だから、それに合わない方法は採用しない。

文明をバックアップするということは、単なるデータの蓄積だけでは済まない。
蓄積されたデータの活かし方までがバックアップの対象になる。

だから、情報の読み方、考え方などの主要な部分は、外で作られたものに影響を受けるわけにはいかない。
外部に依存すれば、仕様が変わって大事な部分が揺れる、ハードウェアへの要求が変わる。

なので、ZIKUUでは、アプリケーションのフレームワークは極力シンプルなものを使い、アプリケーションのコアやサービスはすべて自前で開発する。これは、交換可能なものと、交換されては困る部分の境界を厳密に設計しているから。

ZIKUUが依拠しているものは、React+Vite、FastAPIといったアプリケーション開発フレームワーク、PostgreSQL、Qdrant、MinIOといったデータベース、LLM Runner (Ollama)、Dockerランタイムくらい。
これらは入れ替わっても悪影響はほぼ無い。