AI エージェントに業務判断の一部を任せ始めると、遅かれ早かれ「なぜその結論になったのか」を後から説明する場面がやってきます。社内のリスク部門から聞かれることもあれば、顧客や監督官庁から問われることもあります。ところが多くの構成では、エージェントが参照していたのはベクトルストアに入った埋め込みであり、「似ている文書が上位に来た」という事実しか残っていません。判断そのものと、その根拠となった文脈を再構成する手段がないのです。
とはいえ、判断のたびに独自のログ設計を積み上げていくのは相応の負荷がかかります。ナレッジグラフを導入すれば構造は残せますが、今度はスキーマ設計と初期構築のコストが読めません。そもそも、どのツールを選べば「監査に耐える」形になるのか、判断材料自体が乏しいという方も多いはずです。
Semantica は、この領域を正面から扱う Python 製の OSS です。LLM・ベクトルストア・エージェントフレームワークの下に敷く決定論的なインフラ層として位置づけられており、エージェントの判断そのものをグラフのノードとして記録し、すべての事実に W3C PROV-O の来歴を付けるという設計になっています。2026 年 8 月時点でスター数は 10,791、ライセンスは MIT です。
本記事では、公開情報をもとに Semantica の設計思想・主要機能・類似 OSS との違い・採用前に確認しておきたい点を整理します。本記事の内容はすべて README・公式ドキュメント・GitHub API から取得した公開情報に基づいており、動作検証は行っていません。 コマンドやコードは「ドキュメントに記載されている手順」として提示します。数値も特記のない限り 2026 年 8 月時点の公開値です。
なお、GitHub には Hawksight-AI/semantica という同名の別リポジトリも存在します。本記事が扱うのは semantica-agi/semantica の方です。
- Semanticaとは｜AI判断の証跡をグラフで残すOSS
- AIエージェントの判断が後から説明できなくなる理由
- SemanticaがベクトルRAG・LLMメモリと異なる設計
- Decision Intelligence｜判断を第一級のグラフノードとして記録する
- W3C PROV-O準拠の来歴管理とオントロジーガバナンス
- アーキテクチャと主要モジュール｜取り込みから出力までの一本道
- 導入方法と周辺ツール｜CLI・Knowledge Explorer・MCP
- cognee・Graphiti・GraphRAGとの違い｜どこで選び分けるか
- 採用前に確認したい5つのポイント
- Semanticaが向くケースと向かないケース
- 関連情報
Semanticaとは｜AI判断の証跡をグラフで残すOSS
Semantica は、AI システムが扱う文脈（コンテキスト）と、そこから生まれた判断をグラフとして構造化し、クエリ可能・監査可能にするインフラ層です。GitHub のリポジトリ説明は "Graph-Native Infrastructure for Context and Accountable AI Systems"（文脈と説明責任ある AI システムのためのグラフネイティブなインフラ）と設定されています。詳細は GitHub リポジトリ と 公式ドキュメント で公開されています。
README にはさらに強いコピーとして "The Open Source Palantir for AI Agents"（AI エージェント向けのオープンソース版 Palantir）という表現も掲げられています。ただし、このコピーが何を意味し、何を意味しないのかを最初に確定させておかないと、期待値を見誤ります。この点は後述します。
リポジトリの基本情報
項目 | 値 |
|---|---|
リポジトリ | semantica-agi/semantica |
主要言語 | Python |
ライセンス | MIT |
スター数 | 10,791 |
フォーク数 | 1,178 |
最終更新（push） | 2026-08-25 |
リポジトリ作成 | 2025-06-25 |
最新リリース | v0.6.6（2026-08-20 公開） |
対応 Python | 3.8 以上 |
open issues | 107 |
（GitHub API および PyPI の公開値、2026 年 8 月時点）
このリポジトリはアーカイブされておらず（archived: false）、他リポジトリのフォークでもありません（fork: false）。オリジナルの、現在も更新が続いているリポジトリです。直近のコミットには fix(pipeline) fix(export) perf(explorer) といった修正・改善が並び、PR 番号は 1,200 番台に達しています。
「システムレベルの説明可能性」という限定条件
Semantica を検討するうえで最初に押さえておきたいのが、README 自身が警告ブロックとして明記している限定条件です。README には次の趣旨の記述があります。
System-level explainability, not foundation-model explainability.（システムレベルの説明可能性であって、基盤モデルの説明可能性ではありません）Semantica は LLM の内部で起きていることを露出したり再構成したりはしません。内部の推論や思考連鎖は、他の外部システムに対してと同様に不透明なままです。Semantica が説明するのはモデルの外側、すなわち投入された文脈とデータ、生成された判断、その来歴、関連する関係性、適用されたポリシー、そして実行の全証跡です。 — README（原文は英語、訳は筆者による）
つまり「LLM がなぜそう答えたのか」というモデル内部の説明を得られるツールではありません。得られるのは「どのデータを、どのルールのもとで、どういう判断につなげ、その判断が何に波及したか」というシステム側の証跡です。監査対応の文脈では後者で足りるケースが多い一方、モデルの解釈可能性そのものを求めている場合は用途が合いません。この線引きは、採用判断の最初の分岐点になります。
どんなチームを想定しているか
README の "Who it's for" には想定ユーザーとして 6 類型が挙げられています。重要判断を下すエージェントに構造化された文脈を与えたい AI/ML プラットフォームチーム、Databricks や Snowflake 上のテーブルを外部 SaaS に出さずにナレッジグラフ化したいデータプラットフォームチーム、規制当局が受け取る形式で「なぜ AI はそう判断したのか」に答える必要があるコンプライアンス・リスク・監査チーム、金融やヘルスケアなどの規制産業、推論基盤を自己ホストで差し替え可能にしたいプラットフォームエンジニア、多源データからグラフを構築するデータ／ナレッジエンジニアの 6 つです。
裏を返せば、社内向けの軽量なチャットボットや、説明責任の要件が薄い用途では過剰な選択肢になり得ます。
AIエージェントの判断が後から説明できなくなる理由
README は課題設定を一文で言い切っています。"Most AI agents act without a trail. They store embeddings, not meaning"（ほとんどの AI エージェントは証跡を残さずに動作します。保存しているのは埋め込みであって、意味ではありません）。続けて、説明できない文脈と監査できない判断が残る、と指摘しています。融資審査を例に、「引受エージェントの承認が数ヶ月後に規制当局の『なぜ』に耐えられなければならない」という具体的な場面も挙げられています。
この問題はベクトル検索の性質そのものに由来します。埋め込みが答えられるのは「何が似ているか」であり、「何と何がどうつながっていて、なぜそうなったのか」には答えられません。エージェントが 3 件の文書を参照して結論を出しても、後から残るのは検索ログとレスポンスだけで、判断に至った関係性やそのとき適用されたルールは記録されていません。
日本語圏でも、この論点は制度面から具体化しつつあります。EU AI Act では高リスク AI システムの提供者に技術文書とログの保持が義務づけられ、規制当局の監査に備えた記録の整備が求められます（PwC Japan グループ「欧州（EU）AI規制法」の解説）。透明性義務に関する第 50 条は 2026 年 8 月から適用が始まっています（CloudNative BLOGs「EU AI Act第50条 透明性義務の実務対応ガイド」）。国内企業であっても、EU 市場に製品やサービスを提供する場合は無関係ではありません。
ただし、すべてのプロジェクトがこの課題に直面しているわけではありません。判断の根拠を後から再構成する必要がない用途であれば、以降で述べる仕組みは必要ないと言えます。自分の環境で「判断の証跡が求められる場面があるか」を先に確認しておくと、無駄な検討を避けられます。
SemanticaがベクトルRAG・LLMメモリと異なる設計
README には「Why Semantica」という比較表が掲載されており、ベクトル DB + RAG、素の LLM メモリ、Semantica の 3 者を 10 の観点で並べています。以下は同表の要点を日本語に整理したものです。
観点 | ベクトルDB + RAG | 素のLLMメモリ | Semantica |
|---|---|---|---|
想起の方法 | 埋め込みの類似度 | トークンウィンドウ | グラフ走査 + 意味検索 |
判断履歴 | 保存されない | 保存されない | クエリ可能な第一級オブジェクト |
来歴 | なし | なし | W3C PROV-O・出所リンク付き |
推論 | なし | ブラックボックス | 前向き連鎖・Rete・Datalog・SPARQL |
矛盾検出 | 黙って上書き | 黙って上書き | 検出・フラグ付け・解決 |
時点参照 | 不可 | 不可 | 時点スナップショット |
コンプライアンス出力 | なし | なし | PROV-O・SHACL・OWL・RDF |
ポリシー適用 | なし | なし | 内蔵ルールエンジン + SHACL |
エンティティ解決 | 不可 | 不可 | ブロッキング + 意味的重複排除 |
マルチエージェント文脈 | エージェントごとに分離 | エージェントごとに分離 | 単一の共有インテリジェンス層 |
（出典: README「Why Semantica」）
この表を見て「既存のベクトルストアを捨てる必要があるのか」と考える方もいるかもしれませんが、README はその点を明確に否定しています。"Semantica complements your existing stack rather than replacing it"（既存スタックを置き換えるのではなく補完します）とあり、LLM もベクトルストアもエージェントフレームワークもそのままに、判断記録・因果推論・来歴・オントロジーガバナンス・矛盾検出・監査証跡を上に載せる構成が想定されています。
なお、グラフ型アプローチとベクトル RAG の一般論としての違いや、導入判断のチェックリストについてはGraphRAGとは？従来型RAGとの違いと導入判断チェックリストで扱っています。ここでは Semantica 固有の設計に絞ります。
想起の方法が「類似度」から「グラフ走査」に変わる
Semantica の Context Graph は、README では「RAG に欠けている構造化メモリ層」と位置づけられています。フラットな埋め込みが答えるのが "what is similar?"（何が似ているか）であるのに対し、Context Graph が答えるのは "what is connected, why, and how?"（何がつながっていて、なぜ、どのように）であるという整理です。
API としては add_node / add_edge でグラフを構築し、get_neighbors(hops=2) で幅優先探索により多ホップ先の近傍を取得できるとされています。直接は結びついていない事実同士の関係も辿れます。エージェントメモリ向けには AgentContext(vector_store=..., knowledge_graph=...) という高レベル API が用意されており、ベクトルストアとナレッジグラフを併用する構成が前提です。
グラフ構築・推論・来歴にLLMを必須としない
Semantica の設計上もっとも特徴的なのが、この点です。README には "no LLM required for graph construction, reasoning, or provenance"（グラフ構築・推論・来歴に LLM は不要）と明記されています。推論エンジン、ナレッジグラフ構築、来歴レイヤーはいずれも決定論的に動作するという説明です。
これが効いてくるのは 3 つの側面です。第一にコストで、グラフの構築や更新のたびに LLM を呼ぶ必要がないため、データ量に比例した API 料金が発生しません。第二に再現性で、同じ入力からは同じグラフが構築されるため、監査時に「なぜこの関係が引かれたのか」を説明しやすくなります。第三にデータの持ち出しで、外部 LLM プロバイダにデータを送らずにグラフ化できるため、自己ホスト要件のある環境と相性が良くなります。
ただし、LLM がまったく使えないわけではありません。semantica.llms モジュールを通じて OpenAI・Anthropic・Gemini・Mistral・Ollama など多数のプロバイダに LiteLLM 経由で接続でき、固有表現抽出（NER）などの工程では LLM ベースの手段も選択肢に含まれます。「必須ではない」という設計であって、「使えない」わけではない、という理解が正確です。
矛盾は上書きされず検出され、過去の状態も再現できる
多源のデータを 1 つのグラフに統合すると、必ず矛盾する事実が出てきます。README によれば、Semantica は矛盾を黙って上書きせず、検出してフラグを立て、複数の解決戦略のもとで処理します。矛盾の分類は値・型・関係・時間・論理の 5 種類とされています。
また、時間軸の扱いとして時点スナップショットが用意されており、state_at("2024-01-01") のように指定して過去のある時点のグラフ状態を再現できるとされています。「その判断を下した時点で、システムは何を知っていたのか」を再現できることは、事後の説明において重要な意味を持ちます。バイテンポラルな事実管理や、時間区間の関係を表す Allen の区間代数（13 関係）にも対応していると README には記載されています。
Decision Intelligence｜判断を第一級のグラフノードとして記録する
Semantica の技術的な中核のひとつが Decision Intelligence です。README は「Semantica において判断はログの 1 行ではなく、完全なライフサイクルを持つ第一級のグラフノードである」と説明しています。record_decision() が生成するのは永続的で構造化されたレコードであり、W3C PROV-O としてエクスポートできる、という位置づけです。PROV-O は多くのコンプライアンスフレームワークが規制当局への提出形式として受け入れているフォーマットである、とも記されています。
README の Quick Start には、判断の記録と、その判断に対する 4 種類の問いかけが 1 つのコード例にまとまっています。
from semantica.context import ContextGraph
graph = ContextGraph(advanced_analytics=True)
# Every agent decision becomes a queryable, auditable knowledge node
decision_id = graph.record_decision(
category="vendor_selection",
scenario="Choose cloud provider for HIPAA workload",
reasoning="AWS offers BAA, mature HIPAA tooling, and existing team expertise",
outcome="selected_aws",
confidence=0.93,
)
# Ask "why did this happen?" and get a real, structured answer
chain = graph.trace_decision_chain(decision_id) # full causal ancestry
similar = graph.find_similar_decisions("cloud vendor", max_results=5) # precedents
impact = graph.analyze_decision_impact(decision_id) # downstream influence map
compliant = graph.check_decision_rules({"category": "vendor_selection"}) # policy gate
判断を記録する
record_decision() に渡されているのは、判断のカテゴリ（category）、どういう状況での判断か（scenario）、その理由（reasoning）、結果（outcome）、確信度（confidence）です。上の例では「HIPAA 対象ワークロードのクラウドプロバイダ選定」という場面で、BAA の提供・成熟した HIPAA 対応ツール・既存チームの知見を理由に AWS を選び、確信度 0.93 で記録しています。任意のメタデータも付与できるとされています。
重要なのは、これがアプリケーション側のログテーブルではなくグラフのノードとして保存される点です。後から関係を辿れる構造の中に置かれるため、他の判断や、根拠となった事実と接続できます。
因果チェーンを組む
判断同士は add_causal_relationship() で接続します。README のコード例では、relationship_type に指定できる値が CAUSED / INFLUENCED / PRECEDENT_FOR の 3 種類であるとコメントで明示されています。「引き起こした」「影響した」「先例となった」という 3 段階の強度で因果を表現する設計です。README では融資審査を例に、与信申込（credit_application）から引受判断（loan_underwriting）、金利決定（interest_rate）へとチェーンを組む記録例が示されています。
任意の関係名を許すのではなく 3 種類に限定していることは、グラフの一貫性という観点では利点になりますが、自社の業務モデルをこの 3 種にマッピングできるかは事前に確認しておきたいところです。
記録した判断に問いを立てる
記録した判断に対して立てられる問いは、README の一覧では 7 つの操作として整理されています。過去の類似判断を意味検索で探す find_similar_decisions()（判例検索）、根本原因まで因果の祖先を遡る trace_decision_chain()、その判断が影響を与えた下流をマップ化する analyze_decision_impact()、設定可能なルールセットに対してポリシー適合をチェックする check_decision_rules()、そして W3C PROV-O・CSV・JSON での監査証跡エクスポートです。
実務の問いに置き換えると、「なぜこの承認をしたのか」には因果チェーンの遡上が、「過去に似た判断はどうだったか」には判例検索が、「この判断はどこまで波及したか」には下流影響マップが対応します。監査対応でどこまで答えられるようになるかを見積もる際は、この 4 つの問いを自社のユースケースに当てはめてみると判断しやすくなります。
W3C PROV-O準拠の来歴管理とオントロジーガバナンス
もうひとつの中核が、来歴（プロヴェナンス）とオントロジーによるガバナンスです。判断を記録できても、その判断の根拠となった事実がどこから来たのかを示せなければ、監査証跡としては不完全です。Semantica は「すべての事実に W3C PROV-O の来歴を付ける」という方針を掲げています。
README には、規制対象の判断に対する監査証跡を作るフラッグシップパターンがレシピとして掲載されています。流れとしては、ContextGraph.record_decision() で判断を記録し、add_causal_relationship() で因果を接続し、ProvenanceManager.track_entity() で事実に来歴を紐づけ、graph.to_kg_dict() で変換したうえで RDFExporter().export(kg, "audit_trail.ttl", format="turtle") として Turtle 形式で出力する、というものです。README では医薬品相互作用チェックを例に説明されています（README の監査証跡レシピ）。
事実に出所を紐づける
来歴の追跡は ProvenanceManager が担当し、エンティティ単位・関係単位で出所を記録します。記録した来歴は get_lineage / trace_lineage で遡ることができ、監査証跡は JSON・CSV・RDF の各形式にエクスポートできるとされています。
エクスポート時に押さえておきたいのが to_kg_dict() です。README のレシピでは RDFExporter が期待する形にグラフを変換する公式アダプタとして登場しており、独自に辞書を組み立てず、この変換を経由するのが想定された使い方です。
W3C 標準に乗る利点は 2 つあります。出力が RDF である以上、他の RDF ツールチェーンでそのまま扱えるためベンダーロックインを避けられること。そして、社内にすでに RDF やオントロジーの資産がある場合、接続の難易度が下がることです。
オントロジーと制約でグラフの品質を保つ
グラフは放っておくと構造が崩れます。Semantica の semantica.ontology モジュールは、OntologyGenerator による OWL の生成、SHACL による制約検証、SKOS による語彙管理を提供するとされています。SHACL 制約を定義しておけば、想定外の形のデータが混入した時点で検出できます。
GUI 面では Ontology Hub が用意されており、SHACL Studio・ビジュアルエディタ・クロスオントロジーの整合チェック・ヘルスダッシュボードが含まれると README には記載されています。オントロジー設計に不慣れなチームにとって、テキストエディタで SHACL を書くだけでない選択肢があるのは実務上の助けになります。
矛盾検出の分類
先ほど触れた矛盾検出は、semantica.conflicts モジュールが担当します。値の矛盾（同じ属性に異なる値）、型の矛盾、関係の矛盾、時間の矛盾、論理の矛盾という 5 分類で検出し、複数の解決戦略を選べる設計です。多源データを統合する際、どのソースを優先するかというポリシーを持てるかどうかは、グラフの信頼性に直結します。
アーキテクチャと主要モジュール｜取り込みから出力までの一本道
README はアーキテクチャについて「マーケティング上の名前が付いた単一ライブラリではなく、実際のエンドツーエンドパイプラインである」と述べ、各段階が独立してインポート可能な出荷済みモジュールであることを強調しています。パイプラインは次のように図示されています。
Sources → Ingest → Parse → Normalize → Split → Extract → Conflict Detection → Deduplication
→ Knowledge Graph → [ Ontology · Reasoning · Provenance · Decisions ] → Enriched KG
→ Vector Store + Polyglot Graph Store (RDF & LPG) → Export / Visualize / REST · MCP · CLI
左から順に、多様なソースからの取り込み、文書のパース、テキスト・エンティティ・日付・数値の正規化、グラフ構築を意識したチャンキング、固有表現・関係・イベントの抽出、矛盾検出、重複排除を経てナレッジグラフが構築されます。その上にオントロジー・推論・来歴・判断のインテリジェンス層が乗り、エンリッチされたグラフがベクトルストアとポリグロットなグラフストアに保存され、エクスポート・可視化・REST/MCP/CLI 経由のアクセスに供される、という流れです。より詳細な Mermaid 図は ARCHITECTURE.md に掲載されています。
主要モジュールは README の Module Reference にまとめられています。
モジュール | 役割 |
|---|---|
| ファイル・Web・DB・API・ストリーム・メール・Git・Parquet・Databricks・Snowflake・MCP からの取り込み |
| NER・関係抽出・イベント検出・トリプレット生成 |
| グラフ構築・中心性・コミュニティ検出・リンク予測 |
| 前向き連鎖・Rete・Datalog・SPARQL（説明可能な導出） |
| FAISS・Qdrant・Weaviate・Milvus・Pinecone・PgVector・ハイブリッド検索 |
| エンティティ／関係／オントロジーを意識したチャンキング |
| W3C PROV-O 来歴 |
| OWL 生成・SHACL 検証・SKOS 語彙 |
| 多源間の矛盾検出・解決 |
| 大規模エンティティ解決 |
| テキスト・エンティティ・日付・数値の正規化 |
| 宣言的・並列パイプライン DSL |
| RDF・OWL・Parquet・Cypher・JSON-LD |
| 力学配置グラフ・オントロジー階層・時系列ダッシュボード |
なお README には注意書きとして、DuckDBIngestor / ElasticIngestor / GDriveIngestor / HuggingFaceIngestor / MongoIngestor / PandasIngestor は同梱されているものの semantica.ingest のトップレベル名前空間から再エクスポートされていないため直接 import が必要であること、NER のバッチ処理は ner.process_batch([...]) であることが記載されています。この種の細かい差異は、実装時に最初につまずきやすい箇所です。
ポリグロットなグラフストレージ
Semantica のストレージ層は「設計としてポリグロット」と説明されています。RDF トリプルストアとしては埋め込みの Oxigraph・Blazegraph・Apache Jena・Eclipse RDF4J（SPARQL）、ラベル付きプロパティグラフ（LPG）としては Neo4j・FalkorDB・Apache AGE・AWS Neptune（Cypher）、加えてベクトルストアが挙げられており、いずれもコードに手を入れずに差し替え可能とされています。
RDF と LPG の両方を扱えることは、この分野では珍しい部類に入ります。既存資産が Neo4j にある組織でも、監査提出用の出力は RDF で行う、といった構成が取れる設計です。
エンタープライズデータ基盤との接続
Databricks については Unity Catalog と Delta Lake に対応し、PAT および OAuth M2M による認証、カタログ・スキーマ・テーブル・リネージの内省が可能とされています。Snowflake についてはウェアハウス・データベース・スキーマへの接続と、キーペア認証・OAuth 認証に対応しているという記載です。
設計意図としては「ウェアハウスのテーブルを外部 SaaS に出さずにガバナンス付きでナレッジグラフ化する」という点が README に明示されています。あわせて Security Note として、token / password / private_key といった認証情報をハードコードせず、環境変数または Secrets Manager 経由で扱うよう指示されています。
推論エンジンの選択肢
semantica.reasoning には前向き連鎖、Rete ネットワーク、Datalog、SPARQL の 4 方式が用意されており、導出パスを説明可能にする ExplanationGenerator が併せて提供されます。「なぜこの結論が導かれたか」をルールの適用順として示せることが、説明責任の観点では意味を持ちます。ただし Rete エンジンには README が明記する現時点の制限があり、この点は後述します。
導入方法と周辺ツール｜CLI・Knowledge Explorer・MCP
導入の入口は Python パッケージのインストールです。README には次の手順が記載されています。
pip install semantica
semantica # startup dashboard
semantica doctor # health check
semantica --help # full grouped command reference
出典: README の CLI。CLI はパッケージに同梱されており、別途インストールは不要と記載されています。パッケージ自体は PyPI の semantica で配布されています。
semantica doctor はインストール検証用のコマンドで、README には次のような出力例が掲載されています。以下は README に記載されている例であり、本記事の執筆環境で実行した結果ではありません。
semantica doctor
# Python 3.11.9 pass
# semantica 0.6.6 pass
# faiss vector store pass
# Config file pass ~/.semantica/config.yaml
インストールとextrasの考え方
pip install semantica はコア機能のみで、必要な接続先を extras として追加していく設計です。pip install semantica[all] で全部入りにもできます。README に挙げられている主な extras には agno / crewai / llm-litellm / graph-neo4j / graph-falkordb / graph-apache-age / graph-amazon-neptune / tripletstore-oxigraph / vectorstore-qdrant / vectorstore-pinecone / db-snowflake / db-databricks / ingest-parquet / ingest-arrow / viz / watch / explorer があります。RDF トリプルストアのうち Blazegraph・Apache Jena・Eclipse RDF4J は SPARQL over HTTP で接続するため extra 不要とされています。
ここで見落としやすいのが、試すコストと本番運用コストが別物である点です。README は本番デプロイについて、ローカルの pip install ではなく Docker / Kubernetes を使い、SEMANTICA_SECRET_KEY を設定し、永続的な LPG グラフストアおよび／または RDF トリプルストアを構成し、ベクトルストアはホスト型バックエンドを指すよう明記しています。ローカル環境での確認だけを前提に工数を見積もると、本番の構築規模を見誤ります。
CLIとKnowledge Explorerで何が見えるか
CLI のコマンドグループは ingest extract kg reason decision provenance ontology export visualize pipeline server explorer mcp など 22 種類あり、モジュール構成にほぼ対応する形で用意されています。
GUI としては Knowledge Explorer というブラウザベースのグラフワークベンチが提供されています。React 19 と Sigma.js で構築されており、pip install "semantica[explorer]" の後に semantica-explorer --graph my_graph.json を実行すると http://127.0.0.1:8000 で起動する、Node.js は不要、と README に記載されています。
ワークスペースは 7 つで、Knowledge Graph（Sigma.js キャンバス・ForceAtlas2 レイアウト・Ego Mode・意味距離ヒートマップ）、Timeline、Decisions、Registry（全グラフ変更の監査ログ）、Entity Resolution、Ontology Hub、Lineage（PROV-O の可視化）が用意されています。監査部門との会話で Decisions と Lineage の画面をそのまま示せるかどうかは、実務上の負荷に直結します。
エージェント基盤への組み込み
エージェントフレームワークとしては Agno と CrewAI がファーストクラス対応とされています。CrewAI 統合は最新の v0.6.6 で追加された機能です。加えて MCP サーバーと REST API が用意されており、Claude Code / Cursor / Codex CLI 向けのネイティブプラグインバンドル、Windsurf / Cline / Continue / VS Code / OpenClaw 向けの MCP サーバー + プラグインも提供されていると記載されています。
cognee・Graphiti・GraphRAGとの違い｜どこで選び分けるか
「AI エージェント向けのナレッジグラフ」という括りで見ると、Semantica の近隣には複数の有力な OSS があります。ここでは代表的な 3 件と比較します。
主要3リポジトリとの比較
項目 | Semantica | cognee | Graphiti | microsoft/graphrag |
|---|---|---|---|---|
スター数 | 10,791 | 30,264 | 30,301 | 35,678 |
ライセンス | MIT | Apache-2.0 | Apache-2.0 | MIT |
主眼 | 判断の記録と監査提出 | エージェントの永続長期記憶 | リアルタイムのテンポラルグラフ | グラフベース RAG のインデックス作成 |
LLM 依存度 | グラフ構築・推論・来歴には不要 | 抽出パイプラインが LLM 前提 | 抽出に LLM を使用 | コミュニティ要約等で LLM を多用 |
来歴・監査エクスポート | W3C PROV-O / SHACL / OWL / RDF | 該当機能は主眼でない | 該当機能は主眼でない | なし |
時間軸の扱い | バイテンポラル・Allen 区間代数・時点スナップショット | 対応 | 中核機能（多ホップの時系列クエリ） | 主眼でない |
（スター数は GitHub API の 2026 年 8 月時点の値）
まず押さえておきたいのは、この 3 件はいずれも Semantica より 3 倍前後多くのスターを集めており、日本語の解説記事も豊富にあるという事実です。Semantica のリポジトリ作成は 2025 年 6 月で、明確に後発にあたります。したがって比較は「成熟度」ではなく「機能の焦点」で行うのが妥当です。エコシステムの厚みや事例の入手しやすさを重視するなら、この差自体が判断材料になります。
cognee は「エージェント向け AI メモリプラットフォーム」を掲げ、会話や PDF・Slack・Notion・画像・音声といった多様な入力から LLM を用いて実体と関係を抽出し、セッションをまたぐ永続的な長期記憶を作ることを主眼にしています。cognee 側の設計と導入についてはAIエージェントの永続メモリにcogneeが選ばれる理由で個別に扱っています。
Graphiti（Zep）は、リアルタイムのテンポラル・ナレッジグラフに特化しており、「いつ何が変わったか」を追う多ホップの時系列クエリが強みです。自己ホストする場合は Neo4j / FalkorDB / Kuzu といったグラフ DB を自前で運用します。Semantica もバイテンポラルな事実管理と時点スナップショットを持ちますが、RDF と LPG を同時に扱うポリグロット構成と、規制提出を意識したエクスポート形式を備える点が異なります。
microsoft/graphrag は、コーパスに対するグラフベース RAG のインデックス作成パイプラインです。コミュニティ要約などに LLM を多用して検索精度を高める設計で、判断記録や来歴ガバナンスといった説明責任の層は持ちません。目的が「検索精度の底上げ」に置かれています。
選び分けの目安
整理すると、エージェントに長期記憶を持たせることが主目的なら cognee、時系列での事実の変化を追跡したいなら Graphiti、既存の検索精度を底上げしたいなら microsoft/graphrag、判断そのものを記録して来歴付きで監査に提出できる形にすることが要件なら Semantica、という切り分けになります。
これらは排他的ではありません。README が「既存スタックを補完する」と述べているとおり、cognee や Graphiti で記憶層を作りつつ、Semantica で判断記録と来歴を担うという組み合わせも構成としては成立します。ただし運用対象が増える分、チームの体力とは相談が必要です。
採用前に確認したい5つのポイント
ここまで機能面を整理してきましたが、採用判断では引っかかりやすい論点も同時に見ておく必要があります。以下は README・リリース履歴・GitHub API の公開情報から確認できる事実です。価値判断は読者の状況によって変わるため、事実と出典のみを提示します。
1. まだ 0.x 系である。 最新リリースは v0.6.6（2026-08-20 公開）で、その前は v0.6.5（2026-08-11）、v0.6.0（2026-07-21）、v0.5.1（2026-06-29）、v0.5.0（2026-05-11）と続きます。2026 年 5 月以降で 5 リリースというペースは開発の活発さを示す一方、0.x 系である以上、公開 API が変わる可能性は残ります。バージョン固定とアップグレード時の回帰テストの体制を、導入時点で決めておく必要があります。リリース内容は RELEASE_NOTES.md と CHANGELOG.md で公開されています。
2. Rete エンジンには README 明記の制限がある。 README には次の但し書きがあります。「Current limitation: ReteEngine のアルファノード条件マッチャーは本リリースでは意図的に単純です。本番のコンプライアンスゲートに組み込む前に、実際のルールセットに対して match_patterns() の出力を検証してください。より選択的な条件評価はロードマップ上にあります」（README の reasoning セクション より、訳は筆者による）。ポリシー適用を Rete で組む予定がある場合、この検証は必須の作業になります。
3. 公開ベンチマークには測定条件がある。 README の Performance セクションには、118,000 ノードの本番グラフでノード検索が 24 ミリ秒から 0.004 ミリ秒へ 6,000 倍高速化した、埋め込みキャッシュのヒットでスループットが 10 倍になった、意味的重複排除が 6.98 倍高速化した、候補生成が 63.6% 高速化した、という数値が掲載されています。ただし同じ箇所に但し書きがあり、これらは v0.5.0 時点の AMD EPYC / 64GB RAM 環境での測定値であること、重複排除と候補生成の数値は CHANGELOG.md に記録された過去の測定値であって tests/ の自動アサーションではないこと、結果はハードウェア・データ形状・バックエンド選択によって変動することが明記されています。README 自身が pytest tests/vector_store/test_performance_benchmarks.py -s による自環境での測定を案内しており、公表値をそのまま自社環境の期待値にはできません。
4. コントリビューションが単独メンテナに集中している。 GitHub API で取得したコントリビューター分布では、上位 1 名が 1,890 コミット、次点が 255 コミット、以下 96・87・26 コミットと続きます。README の CONTRIBUTING も「PR を開いて @KaifAhmad1 をタグ付けする」と指示しており、レビュー経路も同一人物に集約されています。open issues は 107 件です。いわゆる bus factor の観点では、長期的な依存先として採用する際に検討しておきたい構造です。
5. v0.6.6 はセキュリティリリースである。 README には v0.6.6 について「セキュリティリリース。アップグレードを強く推奨」と明記されており、非公開で報告された脆弱性群の修正が含まれます。具体的には、semantica backup restore の tarball パストラバーサル、DataExporter.export_table_data() の潜在的な SQL インジェクション、共有 SSRF ガードにおける DNS リバインディングの TOCTOU、HTML レポート生成の Stored XSS、AnzoStore の SPARQL インジェクション、リダイレクト時の Authorization ヘッダ漏洩、Explorer API の HTTP レスポンスヘッダインジェクションと非有界メモリ DoS などが挙げられています。すでに旧バージョンを利用している場合は更新が必要ですし、これから導入する場合も、脆弱性報告と修正のサイクルが回っている段階のプロジェクトであるという理解が前提になります。
Semanticaが向くケースと向かないケース
最後に、ここまでの内容を採用判断の軸に圧縮します。
向いているケースは次のような状況です。規制産業に属していて、監査部門や監督官庁への説明責任が明確な要件になっている。データを外部 SaaS に出せない制約があり、自己ホストでナレッジグラフを構築したい。すでに RDF 資産や Neo4j、Databricks・Snowflake の資産があり、それらと接続したい。エージェントの判断履歴を検索し、影響範囲を分析する必要がある。こうした条件に複数当てはまるなら、Semantica の設計は素直に効いてきます。
向かないケースもはっきりしています。検索精度を上げたいだけであれば microsoft/graphrag のような検索特化の選択肢の方が近道です。エージェントに長期記憶を持たせたいだけなら cognee の方が目的に合致します。グラフやオントロジーのモデリングに割ける工数がないチームでは、SHACL 制約やオントロジー設計の負荷が導入の壁になります。API の安定性を最優先する場合、0.x 系であることは無視できません。そして、LLM 内部の推論そのものを説明したい場合、Semantica は要件を満たしません。
検討を次に進めるなら、以下の 3 点を確認するところから始めるとよいでしょう。第一に、自社で「判断の根拠を後から示さなければならない」場面が本当に存在するかどうか。存在しないなら、ここまでの機能は過剰です。第二に、記録したい判断を CAUSED / INFLUENCED / PRECEDENT_FOR の 3 種の因果関係でモデリングできるかどうか。第三に、本番構成として Docker / Kubernetes 上に永続グラフストアとホスト型ベクトルストアを用意する体力があるかどうか。この 3 点が揃うなら、公式ドキュメント の Getting Started から評価を始める価値があります。
関連情報
AI エージェント基盤の設計や、監査に耐えるログ・来歴管理の実装をご検討中の場合は、お問い合わせフォーム からご相談いただけます。要件が固まっていない構想段階からのご相談にも対応しています。
