Semantica（semantica-agi/semantica）は、AIエージェントが参照する文脈を「ベクトル検索」ではなく「グラフ」として持たせるためのオープンソースのコンテキストグラフ基盤だ。テキストやイベントからエンティティと関係を決定論的に抽出してグラフ（Context Graph）を構築し、そのグラフを根拠にした推論（Decision Intelligence）と、W3C PROV-O準拠の来歴管理（Provenance）までを一体化している。GitHubスターは約7,899、ライセンスはMIT（2026年8月時点）。同名の Hawksight-AI/semantica という無関係の別リポジトリも存在するため、本記事の対象が github.com/semantica-agi/semantica であることをまず明記しておく。
- ・正体：semantica-agi製のグラフ型コンテキスト基盤OSS。GitHubスター約7,899、ライセンスはMIT。
- ・何ができる：LLM不要でエンティティ・関係を決定論的に抽出しContext Graphを構築、その上でDecision Intelligence（推論）とPROV-O準拠のProvenance（来歴）管理を行う。
- ・何を代替できる：置き換えではなく併用が前提。ベクトルRAGの下に敷く監査可能な基盤層として機能する。
- ・実測：
pip install semantica（追加オプション無し）だけで153パッケージ・約3.1GBのダウンロードが発生（torch/transformers/spaCy/faiss-cpu/sentence-transformers等を含む）。「core」という名称に反して軽量ではない。 - ・注意：
Hawksight-AI/semanticaという無関係の同名リポジトリが存在する。
この記事ではグラフ型のコンテキスト基盤としてSemanticaを解説します。RAG全般の仕組み・構築・ベクトルDB選定は RAGとは？仕組み・構築・ベクトルDB選定までの2026年実装マップ をご覧ください。
Semanticaとは：LLM不要で動く決定論的なコンテキストグラフ基盤
Semanticaが解決しようとしているのは、「AIエージェントに文脈を持たせる」ときに起きがちな2つの弱点だ。1つはベクトル検索ベースのRAGが関係性を扱いにくいこと、もう1つはLLMに何かを判断させた際に「なぜその結論に至ったか」を後から追跡しづらいことである。Semanticaは、この両方をLLMを介さない決定論的な処理として実装している点が特徴になる。テキストやイベントを入力すると、エンティティと関係を抽出してグラフを構築し（Context Graph）、そのグラフ上での推論を記録し（Decision Intelligence）、意思決定の根拠をW3C PROV-O準拠の来歴情報として残す（Provenance）。この3つが一体化したインフラ層、というのがSemanticaの実体だ。
開発元は getsemantica.ai という専用サイトを運営する企業（Semantica）で、Discordコミュニティも持つ。README・公式サイトでは自らを「Open Source Palantir for AI Agents」と称しているが、これは開発元自身のキャッチコピーであり、Palantir社との提携や客観的な第三者評価を示すものではない。本記事ではこの自称をそのまま事実として扱わず、機能面（Context Graph・Decision Intelligence・Provenance）の実体で評価する立場を取る。
「Open Source Palantir for AI Agents」は開発元の自称コピーであり、Palantir社との提携を裏付ける一次情報ではない。当サイトはこの表現をそのままの評価として採用しない。
この位置づけは、いわゆる「エージェント向けメモリ層」や「ナレッジベース自動構築OSS」とも隣接するが、Semanticaが強調しているのは再現性だ。同じ入力データを与えれば同じグラフ構造が得られる決定論的な処理を軸にしているため、LLMの出力揺らぎに左右されずにグラフの一貫性を保てる、というのが開発元の主張である。読者にとって重要なのは、この主張を鵜呑みにせず「実際にどこまでLLMを使わずに動くか」「重い処理をどこまで肩代わりしているか」を自分の手元で確認することだ。次章のインストール実測は、その確認の第一歩として行った。
プロジェクトの実測値は次のとおり（2026年8月16日、GitHub API実測）。
・⭐ スター数：約 7,899（フォーク約810）
・📄 ライセンス：MIT（LICENSEファイル実体とREADMEの宣言は一致）
・🕒 最終コミット：2026年8月15日（リサーチ当日時点で現役稼働中）
・🛠️ 総コミット数：2,000件超（ページネーション末尾から概算。正確な総数は未確認）
・👥 コントリビュータ：約 30人
・📦 直近リリース：v0.6.5（2026-08-11）／v0.6.0（2026-07-21）／v0.5.1（2026-06-29）／v0.5.0（2026-05-11）／v0.4.0（2026-04-08）。総リリース数は未確認
・🧩 主要言語：Python
作成から約14か月でスター約7,899・コミット2,000件超・前日にもプッシュがあるという開発速度は、スター数と開発実態が伴っている部類に入る。ただし最新版は0.x系（v0.6.5）で、README上に「実験的」との明記は無いものの、0.4.0→0.6.5がおよそ4か月というマイナーバージョンの更新頻度からは、まだ仕様変更が活発な pre-1.0 のフェーズだとうかがえる。コントリビュータ30人・コミット2,000件超という規模から単独開発者への集中は薄いと推測されるが、コアメンテナーが何人でどの程度の比率を占めるかは本記事の調査範囲では未確認である。
インストールとQuick Start実測：pip install semanticaで何が起きるか
Semanticaはcoreインストールであれば外部のグラフDB・ベクトルDBを別途用意しなくても、ローカルのPython環境だけで試せる。
pip install semantica
実際にクリーンな仮想環境でこのコマンドを実行したところ、依存解決の結果として153個のパッケージ、合計約3.1GBのダウンロードが発生した。内訳には torch・transformers・spacy・faiss-cpu・sentence-transformers・複数の nvidia-* CUDAランタイムパッケージなどが含まれており、いわゆる機械学習フルスタックに近い依存量になる。検証を行ったサンドボックス環境ではディスク容量が不足し、インストールの最終工程（ファイルのコピー）で OSError: [Errno 28] No space left on device により完走しなかったため、後述のQuick Startコード自体の実行結果（ContextGraph初期化の成否）までは確認できていない。これは環境側の制約であり、Semantica自体の欠陥ではない。ただし読者への実用的な示唆として、「LLM不要」という設計思想と裏腹に、core（追加オプション無し）の時点で軽量とは言えないという事実は明記しておく必要がある。導入前に最低でも数GB以上の空きディスクを用意しておくのが安全だ。
Quick Startとして公式README・本記事のブリーフで確認されているのは、以下のようなContextGraphの初期化コードである。
from semantica.context import ContextGraph
graph = ContextGraph(advanced_analytics=True)
print(graph)
advanced_analytics=True という引数名から、標準の抽出・グラフ構築に加えてより踏み込んだ分析機能を有効化するオプションだと推測されるが、その内部挙動の詳細までは本記事の調査範囲では検証できていない。ここは実際に手元で print(graph) の出力やログを見ながら確認するのが確実だろう。
READMEにはグラフDB・ベクトルDB・トリプルストアそれぞれのextras（追加インストールオプション）が用意されていることが示されているが、フルスタック相当の pip install "semantica[all]" のような形は、上記の実測結果（core単体で150超の依存）を踏まえるとさらに重くなる可能性が高い。何を使うか決めていない段階では、まずcoreだけを入れてContextGraphが動くかを確認し、実際に接続したいバックエンド（例えばNeo4j用のドライバ）が必要になった時点で個別に追加する方が無難だろう。
# 特定バックエンド向けのextrasが必要になった場合のみ追加する
# （extrasの正確な名称は公式ドキュメントで確認。coreだけでも重いため、必要な分だけ足す）
pip install "semantica[all]"
① 何ができる：LLM無しでもテキスト・イベントからグラフを構築し、推論と来歴を記録できる。 ② 何を解決する：ベクトル検索だけでは追えない「関係性」と「なぜその結論に至ったか」の監査可能性。 ③ 何を代替できる：ベクトルRAGそのものではなく、その下に敷く基盤層として機能する。
Context Graph・Decision Intelligence・Provenanceの仕組み
Semanticaの中核は3つの機能が積み重なる構造になっている。
Context Graph は、入力されたテキストやイベントからエンティティ（人・組織・概念など）と、それらの間の関係を抽出してグラフ化する層だ。LLMによる曖昧な要約ではなく、決定論的な抽出ロジックでノードとエッジを作る点が設計上の特徴になる。
Decision Intelligence は、構築したContext Graphを根拠にした推論を扱う層である。グラフ上のノード・エッジを辿ることで、単なる類似度スコアではなく構造的な関係に基づいた判断材料を提供する。
Provenance（来歴管理） は、いつ・何のデータから・どのような処理を経てその結論に至ったかを、W3C標準のPROV-O（Provenance Ontology）に準拠した形で記録する層だ。PROV-Oは「Entity（対象）」「Activity（処理）」「Agent（実行主体）」という3種類の要素とその関係で来歴を表現するオントロジーで、金融・医療・法務のように「なぜその判断をしたか」を後から説明する義務がある領域と相性が良い。
(実行主体：ユーザー/エージェント)"] -->|"associatedWith"| B["Activity
(処理：グラフ構築・推論)"] B -->|"used"| C["Entity
(入力データ)"] B -->|"generated"| D["Entity
(出力：Context Graph上の判断)"] D -->|"wasDerivedFrom"| C
この3層構造により、Semanticaは「グラフを作って終わり」のツールではなく、「グラフを作り、そのグラフで判断し、判断の根拠を残す」までを一気通貫で担うインフラとして設計されている。特にProvenance層が標準規格であるPROV-Oに準拠している点は実務上のメリットが大きい。独自フォーマットで来歴を記録するツールだと、監査担当者や規制当局に説明する際にフォーマットの解説から始める必要があるが、PROV-Oのような広く使われるオントロジーに準拠していれば、その分野に詳しい第三者との橋渡しがしやすくなる。裏を返せば、PROV-Oという語に馴染みが無いチームにとっては学習コストが発生する部分でもあり、導入前に「自分たちに来歴の標準化が本当に必要か」を見極める価値がある。
ベクトルRAGとの違い：検索の代替ではなく下に敷く監査可能な基盤
「知識グラフを使うRAG」と聞くと、GraphRAGのようにベクトル検索を補強する仕組みを連想しやすい。しかしSemanticaの位置づけは少し異なり、検索の代替品ではなく検索の下に敷く基盤層として設計されている。
両者の違いを整理すると次のようになる。
| 観点 | ベクトルRAG | Semantica |
|---|---|---|
| 主な役割 | 近傍検索でチャンクを取得する | エンティティ・関係を決定論的に抽出しグラフ化する |
| 関係性の扱い | チャンク単位のためエンティティ間の関係は保持しにくい | グラフ構造として関係を明示的に保持する |
| 来歴（なぜその結論か） | 一般的には記録しない | PROV-O準拠でProvenanceとして記録する |
| LLMの要否 | 埋め込み生成・応答生成でLLMが前提になりやすい | グラフ構築・推論はLLM無しでも動作する設計 |
| 想定用途 | 類似文書・チャンクの高速検索 | 監査性が求められる意思決定基盤（金融・医療・法務等） |
ベクトルRAGを既に使っている場合でも、Semanticaは置き換えではなく併用が前提になる。検索で得たチャンクの背後にある関係性や、エージェントが下した判断の来歴を残したい場面で、RAGの下層に据える基盤として検討する、という位置づけで捉えるのが実態に近い。
なお、知識グラフを使ってRAGの検索品質そのものを底上げする「GraphRAG」系の手法と混同しないよう注意したい。GraphRAGは主に検索対象の構造化によって回答精度を上げることを狙うのに対し、Semanticaは検索精度そのものよりも「その判断がどう導かれたか」の記録と再現性に重心を置いている。両者は同じ「グラフ」という語を使うが、狙っている効果の軸が異なる点は区別しておくべきだろう。
対応するグラフDB・ベクトルDB・トリプルストア：バックエンド選定
Semanticaはグラフの永続化先を自前実装で抱え込まず、複数のバックエンドへプラガブルに接続できる設計になっている。README上で確認できる対応範囲は次のとおりだ。
| 種別 | 具体的な選択肢 | 主な役割 |
|---|---|---|
| グラフDB | Neo4j / FalkorDB / Apache AGE / AWS Neptune | エンティティ・関係のグラフクエリ |
| トリプルストア | Oxigraph / Blazegraph / Apache Jena | RDF/SPARQL準拠のセマンティック照会 |
| ベクトルストア | FAISS / Pinecone / Weaviate / Qdrant / Milvus / PgVector | 埋め込みベースの類似検索 |
この3種類を横断的に選べる点が、Semanticaを単なる「グラフDBのラッパー」ではなく「コンテキスト管理のためのインフラ層」たらしめている部分だ。既にNeo4jやPineconeなど既存のデータ基盤を運用しているチームであれば、それらを差し替えずにSemanticaを追加できる可能性がある一方、この柔軟性の分だけ依存パッケージも増えやすい（前述のインストール実測を参照）。どのバックエンドを使うにせよ、まずはcoreインストールでContextGraphの挙動を確認してから、必要なバックエンド用のドライバ・extrasを個別に追加するのが安全な進め方になる。
チーム構成別に考えると、既にNeo4jのようなグラフDBを運用実績のあるチームは学習コストが最小で済む一方、トリプルストア（Oxigraph・Blazegraph・Apache Jena）はRDF/SPARQLの知識が前提になるため、オントロジー設計の経験が薄いチームにはハードルが高い。ベクトルストアはFAISS・Pinecone・Weaviate・Qdrant・Milvus・PgVectorと選択肢が広く、既存のRAG基盤で使っているベクトルDBをそのまま流用できる可能性が高い点は導入のハードルを下げる要素になる。
同名の別リポジトリ「Hawksight-AI/semantica」との違いに注意
「semantica」という名称は珍しくなく、GitHub上には本記事の対象である semantica-agi/semantica とは無関係の Hawksight-AI/semantica というリポジトリも存在する。両者の関係（フォークか無関係かを含む）は本記事の一次ソース調査の範囲では確認できていない。
| リポジトリ | ライセンス | ⭐ | 特徴 |
|---|---|---|---|
semantica-agi/semantica（本記事の対象） |
MIT（確認済み） | 7,899 | LLM不要のグラフ構築・決定論的推論・PROV-O準拠の来歴管理を一体化したインフラ層 |
Hawksight-AI/semantica（同名の別リポジトリ） |
未確認 | 未確認 | 名称が同じだけの別プロジェクト。本記事の対象より小規模と推測されるが未実測 |
導入時にリポジトリを検索する際は、必ず github.com/semantica-agi/semantica のURLとオーナー名（semantica-agi）を確認してから pip install semantica に進んでほしい。パッケージ名の semantica はPyPI上で一意だが、GitHub上のリポジトリ名は同名でも別プロジェクトが存在しうる、という一般的な注意点がここでも当てはまる。
このような同名衝突は「コンテキストグラフ」「セマンティック」のような一般的な語をプロダクト名に採用したOSSでは珍しくない。README・スター数・最終コミット日・コントリビュータ数といった一次情報を確認できるページを開いているかを都度チェックする癖をつけておくと、検索結果やAIの要約から誤ったリポジトリに誘導されるリスクを減らせる。特に本記事のようにAIエージェント関連のOSSを検索エンジンやAIアシスタントで探す場面では、生成される要約が同名の別リポジトリの情報と混ざっている可能性もゼロではない点に留意したい。
まとめ：Semanticaが向いている用途・向いていない用途
Semanticaが向いているのは、AIエージェントの判断根拠を後から説明する必要がある領域——金融・医療・法務のように「なぜその結論に至ったか」の監査性が求められる用途だ。LLMを介さず決定論的にグラフを構築し、PROV-O準拠で来歴を残す設計は、単純な文書検索の高速化を目的とするなら過剰装備になりやすい。
逆に向いていないのは、「とにかく軽く類似文書を探したい」というシンプルなベクトル検索のユースケースだ。coreインストールだけで150超の依存パッケージ・約3GBのダウンロードが発生する実測結果を踏まえると、依存を最小限に抑えたい環境や、ディスク容量が限られたCI環境では負担が大きい。既存のベクトルRAG基盤を置き換える目的ではなく、その下に監査可能な基盤を足す目的で検討するのが実態に合っている。
知識グラフ・図解生成・構造化抽出まわりのOSSを横断的に比較したい場合は ドキュメント/ナレッジ系OSSの選び方｜知識グラフ・図解生成・構造化抽出マップ も参考になる。RAGの発展系（Naive・Advanced・Graph・Agentic RAG）を仕組みから理解したい場合は RAGの進化｜Naive・Advanced・Graph・Agentic RAGの仕組みと選び方2026、会話ログを知識ベースへ自動コンパイルする隣接ジャンルのOSSとしては Claude Memory Compilerとは｜会話を知識ベースに自動コンパイルするOSS も合わせて確認してほしい。
参照ソース
・semantica-agi/semantica（公式リポジトリ・README） — 機能一覧・インストール手順・Quick Start・実測値の一次情報
・Semantica 公式サイト — プロダクト概要・想定ユースケース（金融・医療・法務等）
