AIというのは、得手不得手があって、RAGなどの外部知識を参照するテクニックを使っても、実際の業務では使い物にならないことが多いです。あてずっぽうのいい加減な知識を提供されても人は迷うだけです。
最近は、その対策として、OpenClawなどのエージェント技術、LLM Wikiといった考え方などが出てきましたが、ZIKUUのNerveやPivot Serviceで実現しているように、知識を整理して構造化し、その構造に従ってAIが動くとした方が実用性と正確性は上がります。
ZIKUUでは、ZIKUU v1.0というシステムが、自分で自分を説明できる能力が持てるようにします。開発者である私の寿命は永遠ではないし、ZIKUU MiniのようなものがあればZIKUU以外の場所で使われることになります。だから、私がいなくてもシステムを理解できるように、システム自身がその能力を持つべきだと考えています。
今回紹介するのは、そのために開発を予定しているZIKUU Node Agentの一部です。
このアプリケーションはzikuu-mapというリポジトリの中に書かれていることを案内板として使い、システム全体を説明します。
zikuu-map
上のスクリーンショットは、zikuu-mapのREADME.mdを表示した様子です。
zikuu-mapには、ノードの自己紹介、責務、稼働するソフトウェアの一覧が記載されています。
各ソフトウェアのリポジトリには、ZIKUU Repository Protocolという規約に従って、いくつかのファイルが置かれます。
ZIKUU Repository Protocol
ZIKUU Repository Protocolが定めているのは、
- リポジトリの内容を理解するための文書
- 文書を読む順番
です。
これはソフトウェアを調査するための手順書のようなものです。
ZIKUU v1.0で稼働するすべてのソフトウェアは、GitHub上の開発用プライベートリポジトリで管理されていますが、ローカルで稼働するGiteaには、そのミラーが置かれます。
Pull Mirrorですから、GitHub –> ローカルミラーへの一方通行で、その逆はありません。
規約に示されている文書は、
- README
- TECHDOC
- ARCHITECTURE
- APIDOC
- TREE
- TODO
の６つ。
README
ソフトウェアの概要が書かれている。
TECHDOC
ソフトウェアの技術説明が書かれている。
ARCHITECTURE
ソフトウェアのコンポーネント図、クラス図などの構造がわかる文書。
APIDOC
外部公開しているAPIの呼び出し方の説明文書。
TREE
リポジトリのディレクトリ/ファイルのツリー。
TODO
開発済、開発中、開発予定、将来計画などの開発に履歴。
調査手順
調査手順は２段構えです。
どちらも、人とAIが迷わないための調査地図になっています。
zikuu-mapには、調査ガイドが書かれていて、それを読んだ上で調査を実施すると効率が上がります。
ZIKUU Repository Protocolには、典型的な調査手順が示されています。
システムの説明なら、機能拡張の際に調査なら、トラブルの原因究明なら、この順番で読めという指示です。
ZIKUU Node Agent
これは、AIアプリケーションで、zikuu-mapとZIKUU Repository Protocolに従って、システムを調査し、人の質問に答えます。
いずれ、このアプリケーションは、ZIKUU Node Protocolをしゃべるようになり、ZIKUU Mini間で互いを説明できるように拡張する予定です。そうなると、ZIKUU Miniクラスターは、意味的に接続されたクラスターになります。
ZIKUU v1.0が完成する頃には、ZIKUU Node Agentが動き出すでしょう。
