「なぜその判断になったのか」と後から聞かれて、ログを漁っても答えが出てこない。
AIエージェントを業務に載せると、だいたいここで詰まります。
semanticaは記憶をベクトルではなくグラフで持つことでそこを設計から変えにきたOSSで、GitHubのスターは執筆時点で8,995まで来ています。
AIエージェントの記憶を、なぜ監査できないのか
今のエージェントの記憶は、ほとんどがベクトルです。
文章を埋め込みに変えておいて、質問が来たら意味の近いものを引っ張ってくる。
この仕組みは「思い出す」には強いんですが、「証明する」には設計上向いていません。
返ってくるのは意味の近いチャンクであって、「この判断の根拠はこの文書のこの記述だ」ではないからです。
類似度スコアは根拠ではなく、距離ですね。
社内デモならこれで十分通ります。
止まるのは、金融や医療、法務や公共のように「その判断を第三者に説明できるか」を先に聞かれる場所です。
semanticaのREADMEはそこを名指ししていて、"In regulated domains, every AI decision must be traceable to a source and defensible to an auditor"(規制領域では、すべてのAIの判断が出所まで追跡でき、監査人に説明として通らなければならない)と書いています。
ここまで言い切っている以上、中身は確かめておきたくなります。
semanticaとは 判断をノードとして記録するグラフ基盤
名乗りは "Graph-Native Infrastructure for Context and Accountable AI Systems"、そして副題が "The Open Source Palantir for AI Agents" です。
Palantirを名指ししているのは、散らばったデータを繋いで「誰がいつ何を根拠に決めたか」を後から辿れるようにする、あの領域をOSSでやるという宣言ですね。
機能は4本柱で整理されています。
書き味はこんな感じです。
from semantica.context import ContextGraph
graph = ContextGraph(advanced_analytics=True)
decision_id = graph.record_decision(
category="vendor_selection",
scenario="Choose cloud provider for HIPAA workload",
reasoning="AWS offers BAA, mature HIPAA tooling",
outcome="selected_aws",
confidence=0.93,
)目を引くのはconfidenceまで引数に持たせているところです。
判断を記録するだけならログでもできますが、確信度と根拠と結果をセットで構造化して置いておくと、後から「確信度0.9以上で外した判断」のような引き方ができる。
ログはgrepできても、こういう問いには答えられません。
ライセンスはMIT、言語はPythonです。
ベクトル検索とグラフの違いは、出所が残るかどうか
並べるとこうなります。
ここで効いてくるのがW3C PROV-Oです。
semanticaの独自仕様ではなく、2013年にW3Cが勧告した来歴記述のオントロジーで、「このデータはどのエンティティから、どの活動を経て、誰の手で生まれたか」を機械可読に書くための語彙が定義されています。
自前のJSONに来歴っぽいフィールドを生やすのと、この標準語彙に載せるのは、監査を受ける側から見ると別物なんですよ。
多くのコンプライアンス枠組みが規制当局への提出形式として受け付けるのがこの形式だ、とREADMEも書いています。
推論エンジン側も思想は同じです。
forward chainingやDatalog、SPARQLで引くというのは、結論に至るまでに「どの規則がどの順で適用されたか」が残るということですから。
LLMに「なぜそう判断したか説明して」と後から書かせるのとは、まったく別の話ですね。
あれは説明ではなく、説明の生成なので。
LangGraph CrewAI LlamaIndexで統合の深さが違う
対応フレームワークの一覧だけ見ると全部横並びに見えるんですが、READMEを開くと深さが2段階に割れています。
ネイティブのツールキットが用意されているのは、AgnoとCrewAIの2つだけです。
pip install semantica[agno] / semantica[crewai]python -m semantica.mcp_serverネイティブ側はfrom integrations.agno import AgnoSharedContext, AgnoDecisionKitのように、共有コンテキストと判断記録がエージェントの部品として最初から出てきます。
対してLangGraphやLlamaIndexには専用ツールキットがありません。
繋がらないわけではなく、REST APIかMCP Server越しに叩く形になります。
この差は実装量よりも、設計の持ち場に出ますね。
ネイティブ側は「記録する」がフレームワークの流儀で用意されているのに対し、MCP経由だと「いつ何を記録するか」の設計を自分で持つことになるからです。
LangGraphで使うつもりなら、ステートグラフのノードから明示的に叩く前提で見積もっておいたほうがいいです。
「対応しています」の一行では、ここまで見えません。
pip installからMCP Serverまで
入り口自体は軽いです。
pip install semantica # コア
pip install semantica[all] # フルスイート
python -m semantica.mcp_server # MCP Serverを起動extrasはかなり細かく切ってあって、グラフDBが[graph-neo4j]や[graph-amazon-neptune]、RDF側が[tripletstore-oxigraph]、そのほかベクトルストアやSnowflake Databricksからの取り込みまで別々に生えています。
最初に決めることになるのは、グラフの持ち方ですね。
プロパティグラフ(Neo4j、FalkorDB、Apache AGE、AWS Neptune)と、RDFトリプルストア(Oxigraph、Blazegraph、Apache Jena、Eclipse RDF4J)の2系統があります。
SPARQLで引きたいなら後者です。
Oxigraphは埋め込みで動くので、外部のDBを立てずに手元で試せます。
MCP Serverを起動すると、エンティティ抽出、判断の記録、因果チェーンの取得、グラフ分析がツールとして生えてきます。
公式はここまで30秒と言っていて、semantica doctorによるインストール確認が5秒。
ただ、pipが通る速さと業務に載る速さは別ものです。
重いのはインストールではなく、どのグラフDBに寄せるかと、既存のデータをどうノードに落とすかの設計のほうですから。
スター8,995に対してウォッチが50という数字
GitHub APIで実測すると、2026年8月19日時点でスターが8,995、フォークが925、オープンなissueとPRを合わせて99でした。
公開は2025年6月25日なので、約14か月でここまで来たことになります。
直近のpushは8月18日で、開発は今も動いていますね。
ただ、私が引っかかったのはウォッチャーの数でした。
50です。
スター8,995に対して1%を切っています。
スターは「あとで見る」で押せますが、ウォッチは通知が飛ぶので、押すには追いかける意思が要る。
つまり今のsemanticaは、気になってブックマークした人が大量にいて、業務で追っている人はまだ薄い位置にいると読めます。
一方でフォークは925あって、スターの1割強です。
眺めているだけでなく、手元に落として動かしている層はそれなりにいますね。
公称値のほうも触れておくと、READMEにはノード検索が6,000倍速い(118,000ノードで24ms→0.004ms)、意味的な重複排除が6.98倍という数字が並んでいますが、これは自社ベンチマークです。
線形に舐めていたところをインデックス経由に変えたときに出る差、くらいに読んでおくのが安全だと思っています。
そもそもこの基盤の本体は速さではなく、来歴が標準語彙で残ることのほうなので。
入れる価値があるのは、判断の根拠を後から人に説明する必要がある領域です。
金融や医療、法務や公共に加えて、社内でエージェントの決定を承認フローに載せたいときにも効きます。
逆に、個人開発や社内ツールで検索が当たれば十分という用途なら、急ぐ必要はありません。
ただ「エージェントの記憶を、検索できる状態から説明できる状態へ持っていく」という方向自体は、規制業界の外にも遅れて降りてきます。
グラフで記憶を持つ設計を一度手元で通しておくと、その時に慌てずに済みますね。
💬 コメント
ログイン か 会員登録 するとコメントできます