OpenViking は、AIエージェントが持つ知識・記憶・スキルを一つの仮想ファイルシステム viking:// として統合管理する「コンテキストデータベース」です。Rustコア(ragfs)とPythonパッケージ、CLI、MCPサーバー、Web Studioから構成されています。mem0やsupermemoryなど既存メモリ製品と比較するベンチマーク群(locomo、longmemeval、RAGなど)も同梱されています。
コンテキストは viking://resources、viking://user/{id}/memories、skills のようなパス配下に配置され、エージェントは ls・tree・read・write・grep といったファイル操作でアクセスします。各ディレクトリにはL0(要約)・L1(概要)・L2(本文)の3層があり、エージェントは要約を先に読んでから本文を開くかを判断できます。Rust側は crates/ov_cli と crates/ragfs、crates/ragfs-python がワークスペースとして cargo でビルドされ、Python側の setup.py から呼び出されます。Dockerfile ではRustツールチェーン、Node(web-studio)、uv(Python)を多段ビルドでつなぎ、CLIとネイティブ拡張とStudioバンドルを1つのイメージにまとめています。agent-plugins ディレクトリには MCP プロキシ(mcp-proxy.mjs)とSKILL.md群があり、Claude Code や Codex からメモリ・スキル機能をMCP経由で呼び出せるよう設計されています。セッションをコミットすると会話がアーカイブされ、記憶がMarkdownとして抽出されるため、人が直接読んで編集できます。
- STEP 01
Dockerfileを使ってビルドすると、Rustツールチェーン、Node(web-studio)、uvによるPython環境が多段で構築され、ov CLIとネイティブ拡張とStudioバンドルが1枚のイメージに収まる様子を確認できます。
- STEP 02
cargo build または uv sync を実行すると、crates/ov_cli・ragfs・ragfs-pythonがビルドされ、rustc 1.91.1以上が要求されることに気づきます。
- STEP 03
ov CLIで viking:// 配下を ls や tree、read で辿ると、記憶・リソース・スキルがディレクトリ構造として見え、ベクトルDBのような不透明さがないことを体感できます。
- STEP 04
agent-plugins/mcp.json や .claude-plugin/marketplace.json をClaude CodeやCodexに登録すると、openviking-memoryなどのスキルがMCP経由で使えるようになります。
- STEP 05
benchmark/locomo や benchmark/longmemeval 配下のrun_eval.pyを実行すると、mem0・supermemory・vikingbotなど他手法との比較評価が走り、judge結果の統計が出力されます。
- STEP 06
web-studio/README.mdに従ってセルフホストすると、ブラウザ上でコンテキストの閲覧とセマンティック検索を試せます。
手元に残るのは、viking://として閲覧・編集可能な記憶・知識・スキルのディレクトリ構造と、それを操作するov CLI、MCP経由でエージェントに接続できるプラグイン群です。加えてlocomoやlongmemevalなどのベンチマークスクリプトを動かせば、他社メモリ製品との比較結果(judge統計)も得られます。
ビルドにはRust 1.91.1以上、Node 24、uv(Python3.13)が同時に必要で、Dockerfileも多段構成のため準備コストが高めです。
ragfs-pythonはネイティブ拡張のコンパイルを伴うため、環境によってはビルド時間やccache設定の影響を受けやすいです。
ライセンスはAGPLv3のため、改変版をネットワーク経由で提供する場合はソース公開義務が発生する点に注意が必要です。
ベンチマークコードは各社サービス(mem0、supermemoryなど)のAPIキーを前提にしている箇所があり、それらを用意しない限り一部の比較検証は再現できません。
エージェントの記憶・知識・スキルを「見える形」で管理したいチーム、特にベクトルDBのブラックボックス性に不満があり、viking://のようなファイルシステム的な透明性を求める開発者に向いています。README、Cargo.toml、Dockerfile、agent-plugins配下のテストファイル(plugin.test.mjs)、複数のベンチマークREADMEが整合的に同じアーキテクチャ(viking://・L0/L1/L2・MCPプラグイン)を裏付けているため、実機を動かさなくても構造と挙動の判断はこの資料だけで十分に信頼できます。