🔐 AIエージェントの『言った者勝ち』を止めるCruxible、判断をレビュー必須にする状態層

エージェントに「このサプライヤー、前回のインシデントで影響あったよね?」と聞いたら、答えが毎回微妙に違った。そんな経験はないだろうか。

長期記憶を持たせたはずのAIエージェントが、同じ質問に違う答えを返す。RAGで拾ってくる文書の順序が変わっただけで結論が揺れる。ベクトル検索は「近い」を返すのは得意でも、「正しい」を保証してはくれない。エージェントメモリを業務判断の根拠に使おうとすると、この差がそのまま信用の問題になる。

クレームは全部「宣言済みルール」で検証される

Cruxible(Python製・Apache 2.0)は、この「答えが揺れる」問題に対して、ベクトル検索ではなくオントロジーで殴りにいくツールだ。SQLiteの上に型付きグラフを構築し、エンティティ種別・関係性・書込ルール・クエリをすべてYAMLで宣言する。エージェントが何かを主張(クレーム)するとき、そのクレームは宣言されたルールに照らして検証されてから状態に入る。「人間もエージェントも、同じドメインの同じ型付きモデルを共有する」という設計思想が根っこにある。

書込モードは2つに分かれている。単純な事実の取込は直接書込でいいが、「このインシデントはこのサプライヤーに影響する」のような判断が絡むクレームは、必ずレビューグループを経由する統制提案モードになる。承認されて初めて状態に「ミント」される仕組みだ。

cruxible server start
cruxible init --kit agent-operation --kit supply-chain-blast-radius
cruxible run --workflow build_seed_state
cruxible apply --workflow build_seed_state --from-last-preview

このコマンド列で見えてくるのは、「取込→プレビュー→適用」という決定論的なワークフローだ。同じ状態からは常に同じ答えが返る、というのがCruxibleの核心的な主張になる。

承認1件で下流が全部変わる、という設計

面白いのはsupply-chain-blast-radiusキットの挙動だ。「このインシデントはこのサプライヤーに影響する」という判断を1件レビュー承認すると、そこから先の「インシデントがどのコンポーネントに波及するか」は5ホップの部品表走査で自動的に導出される。上流の判断1つを覆すだけで、下流のクエリ結果が次のアクセスから全部変わる。判断は人間が握り、計算は機械に任せる、という役割分担がはっきりしている。

まだ7スターの若いプロジェクト

正直なところ、GitHubスターはまだ7、コミット数246というごく初期のプロジェクトだ。Pydantic・NetworkX・Polars・FastAPI・FastMCPと依存が多く、YAMLでオントロジーを書く学習コストも軽くはない。ZennやQiitaを検索してもCruxible自体を扱った記事はゼロで、判断材料は英語のREADMEしかないのが正直なところだ。

それでも、「エージェントの記憶」を単なる検索対象ではなく検証可能な状態として扱う発想には惹かれる。次にエージェントメモリの信頼性で悩んだときは、ベクトル検索を足すより先に、こういう型付き状態層を検討してみたい。あなたのプロジェクトでは、エージェントの「言った者勝ち」をどう防いでいる?