OpenVikingってなんだ？ — AIの記憶をlsとfindで辿るコンテキストDB

Last updated at 2026-08-24Posted at 2026-08-24

この記事の対象読者

RAGを触ったことがあり、ベクトルDBに文書を入れて検索した経験がある方
「チャンクを増やすほど検索精度が落ちる」現象に心当たりのある方

想定レベルはひとつに固定します。ベクトル検索の仕組みは知っているが、エージェント向けのコンテキスト管理は未経験、という地点に立っている方に向けて書きます。

この記事で得られること

OpenVikingが「ベクトルDBの代わり」ではなく「ファイルシステム」を名乗る理由
L0/L1/L2という3階層ロードが、実際に何トークン節約するのかの実測値
手元のクリーン環境で導入したときに実際に踏んだ失敗と、その回避手順

この記事で扱わないこと

商用版やマネージドSaaS版の料金比較
他のメモリ製品との優劣判定
検索精度そのものの再現実験（APIキーが必要なため、公式の公開値を引用するに留めます）

1. 結論を3行で

このセクションで分かること

記事全体の主張を、読み進める前に把握できます。

OpenVikingは、エージェントの記憶・資料・スキルを viking:// という仮想ファイルシステムの上に載せ、ls や find で辿れるようにしたコンテキストデータベースです。
中核は3階層ロードです。要約だけ読む、目次だけ読む、本文を読む、を分離しています。
手元で測ったところ、コーパスを2.64倍に増やしても階層ロードのコストは11.7%しか増えませんでした。全文投入なら当然2.64倍です。ここがこの設計の実質です。

この記事は、その3行を図書館という比喩で最後まで貫きながら説明していきます。

2. OpenVikingとは何者か

このセクションで分かること

OpenVikingの提供元、規模、ライセンス、そして「実在する」ことの確認手順が分かります。

OpenVikingは、ByteDanceのクラウド部門であるVolcano Engineが公開しているオープンソースプロジェクトです。GitHubリポジトリの説明文には、Self-evolving Context Database for AI Agents と書かれています。日本語版READMEでは「AIエージェントのためのコンテキストデータベース」と訳されています。

新しめのプロジェクトなので、実在確認から始めます。以下はすべてGitHub APIとPyPIから取得した値です。

項目	値	確認方法
リポジトリ作成日	2026-01-05	GitHub API `created_at`
Star数	32,961	GitHub API `stargazers_count`（2026-08-25時点）
Fork数	2,513	GitHub API `forks_count`
主要言語	Python 75.4% / Rust 13.7%	GitHub 言語統計
ライセンス	AGPL-3.0	GitHub API `license.spdx_id`
PyPI最新版	0.4.16	PyPI JSON API（2026-08-21公開）
論文	arXiv:2605.29640	VLDB 2026採択

ライセンスには注意点があります。本体はAGPLv3ですが、リポジトリのLICENSE構成を読むと crates/ov_cli と examples はApache 2.0です。ドキュメントのミラーサイトの一部に「Apache 2.0」とだけ書かれた記述が残っていますが、リポジトリ直下のLICENSEファイルが正です。AGPLはネットワーク越しの提供にもソース開示義務が及ぶため、自社SaaSに組み込む場合は事前に確認してください。

図書館という比喩を置きます

ここからの説明は、ひとつの比喩で通します。

エージェントのコンテキストを、図書館だと考えてください。

従来のRAGは、蔵書をすべてシュレッダーにかけて紙片にし、ひとつの巨大な箱に入れた状態です。紙片には「意味の近さ」というタグだけが付いています。質問が来たら、箱の中から意味の近い紙片を上位k枚だけ掴んで返します。

紙片は確かに関連しています。しかし、その紙片が何という本の、何章の、どのページから来たのかは分かりません。前後の文脈も、隣に何が書いてあったかも失われています。

OpenVikingが提案するのは、箱をやめて書架に戻すことです。分類され、棚があり、背表紙があり、目次があり、本文がある。そういう普通の図書館の構造に戻す、という発想です。

3. なぜ「ファイルシステム」を名乗るのか

このセクションで分かること

フラットなベクトル検索が具体的にどこで詰まるのか、独立した3つの実例で確認できます。

公式READMEは、エージェント開発で直面する課題として5つを挙げています。そのうち検索に関わる部分を、実際に起きる形に噛み砕くと次の3例になります。

実例1: 同名セクションの取り違え

社内ドキュメントに product-a/setup.md と product-b/setup.md があり、どちらにも「インストール手順」という節があるとします。フラットな箱の中では、この2枚の紙片はほぼ同じベクトルを持ちます。「セットアップ方法を教えて」という質問に対し、どちらが返るかは実質的に運です。

書架なら起こりません。product-a の棚を見に行くと決めた時点で、product-b は候補から外れているからです。

実例2: 文脈の切断

APIリファレンスの「この設定は非推奨です」という1文が、単独のチャンクとして切り出されたとします。この紙片だけを読んだLLMは、何が非推奨なのか分かりません。前後のチャンクを一緒に返せば解決しますが、では何チャンク分を返すのが正解なのかは、事前には決められません。

書架なら、本を開けば前後のページがそこにあります。

実例3: デバッグ不能

「なぜこの回答になったのか」を調べようとして、ベクトルDBのログを見ても、返ってきたのはコサイン類似度の数値の羅列です。閾値を上げても下げても、なぜ改善するのか説明できません。

書架なら、司書がどのフロアを見て、どの棚に寄って、どの本を開いたかという足跡が残ります。OpenVikingはこの足跡を「検索軌跡」として保存すると明記しています。

構造の対比

左は紙片の箱、右は書架です。決定的な違いは、右には現在地という概念があることです。

4. viking:// の中身を覗く

このセクションで分かること

実際のディレクトリ構造と、記憶・資料・スキルがどう配置されるかが分かります。

OpenVikingは、あらゆるコンテキストに viking:// から始まるURIを与えます。公式READMEに掲載されている構造は次のとおりです。

viking://
├── resources/              # 資料: プロジェクト文書、リポジトリ、Webページ
│   └── my_project/
│       ├── docs/
│       │   ├── api/
│       │   └── tutorials/
│       └── src/
└── user/
    └── {user_id}/
        ├── memories/       # 記憶: ユーザーの好み、習慣
        │   └── preferences/
        │       ├── writing_style
        │       └── coding_habits
        ├── resources/      # そのユーザー専用の資料
        ├── skills/         # スキル: 手続き的な能力
        │   ├── search_code
        │   └── analyze_data
        └── peers/          # 他エージェントとの共有領域

図書館でいえば、resources/ が一般開架、user/{id}/memories/ が利用者カード、skills/ が館内の作業マニュアルです。すべてが同じ建物の中に、同じ住所体系で並んでいます。

ここが従来との一番の違いです。メモリはアプリのコード内に、資料はベクトルDBに、スキルはプロンプトの中に、とバラバラだったものが、ひとつの住所体系に統合されます。

peers/ という領域があるのが面白いところです。マルチエージェント構成で、別のエージェントの記憶を参照する経路が最初から設計に入っています。図書館でいえば、他館との相互貸借の窓口にあたります。

5. L0/L1/L2 — 背表紙・目次・本文

このセクションで分かること

3階層ロードの定義と、それがCLIコマンドにそのまま現れていることが確認できます。

コンテキストをプロンプトに全部詰め込むのは、単に高いだけでなく、モデルのウィンドウを超えたりノイズを増やしたりします。OpenVikingは書き込み時に、すべてのエントリを3階層に加工します。

階層	名称	公称サイズ	図書館での対応物	用途
L0	Abstract	約100トークン	背表紙のラベル	関連するかどうかの一次判定
L1	Overview	約2,000トークン	目次と前書き	構造の把握、計画立案
L2	Details	元データ全文	本文	どうしても必要なときだけ

面白いのは、この3階層がCLIコマンドにそのまま対応していることです。実際にインストールして ov --help を叩くと、次の3行が並んでいます。

abstract          Read abstract content (Level 0)
overview          Read overview content (Level 1)
read              Read file content (Level 2)

抽象概念ではなく、3つの別々のコマンドとして触れる形になっています。ディレクトリごとに .abstract と .overview が生成されるため、本を開く前に「この棚は関係あるか」を100トークンで判定できます。

ここまでのまとめ

長くなってきたので、一度整理します。

OpenVikingは、エージェントのコンテキストを書架として組み直す試みです
記憶・資料・スキルは viking:// の下にひとつの住所体系で並びます
各エントリは背表紙（L0）・目次（L1）・本文（L2）の3階層を持ちます
検索は「棚を特定してから本を開く」という2段構えになります

ここまでが設計思想です。ここからは、その設計が実際にどれだけ効くのかを、手を動かして測ります。

6. 実測: 階層ロードは何トークン節約するのか

このセクションで分かること

公称値ではなく、実際のコーパスで測った階層ロードのコストが分かります。

公式は「トークン消費を削減する」と書いていますが、どれくらい削減されるのかは条件次第です。そこで、実際に測りました。

数式やコードが続きますが、やっていることは単純です。図書館で目的の本に辿り着くまでに、何枚の背表紙と何冊の目次を読んだか、を数えているだけです。

測定条件

項目	内容
コーパス	OpenViking公式ドキュメント `docs/` 配下のMarkdown
トークナイザ	BPE、語彙数65,000（オフライン実行のため辞書同梱のものを使用）
L0コスト	100トークン × 走査したディレクトリ数
L1コスト	2,000トークン × 降りた階層数
L2コスト	対象ファイルの実トークン数
比較対象	全文投入（コーパス全体をプロンプトに入れる）

コーパスの実測値

docs/en だけで次の規模でした。

指標	値
Markdownファイル数	90
ディレクトリ数	11
総トークン数	355,455
最大ファイル	32,324トークン
中央値	2,508トークン
512トークンでチャンク化した場合の断片数	744

744枚の紙片。これが箱の中身です。

結果1: 単一ファイルに到達するコスト

3つのファイルを目標に設定し、ルートから辿り着くまでのコストを測りました。

目標ファイル	L0	L1	L2	合計	全文投入比
`api/05-sessions.md`	1,000	4,000	15,470	20,470	-94.2%
`guides/01-configuration.md`	1,000	4,000	23,254	28,254	-92.1%
`agent-integrations/16-capability-reference.md`	1,000	4,000	32,324	37,324	-89.5%

注目すべきは、L0とL1の合計が3件とも5,000トークンで固定されている点です。目標がどこにあっても、辿り着くための「案内料」は変わりません。変動するのは、最後に開いた本の厚さだけです。

結果2: コーパスを膨らませたとき

ここが本題です。同じファイルを目標にしたまま、コーパスの規模だけを変えてみました。

コーパス	総トークン	全文投入	階層ロード	削減率
`en`	355,455	355,455	20,470	94.2%
`en` + `zh`	774,447	774,447	22,670	97.1%
`en` + `zh` + `design`	928,413	928,413	22,770	97.6%
`en` + `zh` + `design` + `superpowers`	939,851	939,851	22,870	97.6%

コーパスが2.64倍になっても、階層ロードのコストは20,470から22,870、つまり11.7%しか増えていません。

図書館が3倍の広さになっても、案内板をもう1枚読むだけで済むのと同じです。全文投入は素直に3倍になります。この差が、蔵書が増え続けるエージェントにとって効いてきます。

案内に使ったのは全体の32.4%です。残りは本当に読みたかった本文です。

計測に使ったコードはパッケージとしてGitHubに置きました。同じ表を手元で再現できます。

クリックで再現手順を展開

git clone https://github.com/hiroki-abe-58/context-tier-bench
cd context-tier-bench
pip install -e ".[tiktoken]"

# 計測対象としてOpenVikingのドキュメントを取得
git clone --depth 1 https://github.com/volcengine/OpenViking /tmp/ov

# 本文中の表をそのまま再現する
context-tier-bench /tmp/ov/docs/en \
  --scale-with /tmp/ov/docs/zh \
  --scale-with /tmp/ov/docs/design \
  --scale-with /tmp/ov/docs/superpowers \
  --scaling-target api/05-sessions.md \
  --format markdown

ライブラリとしても使えます。

from context_tier_bench import FullDump, TieredLoading, load_corpus, resolve_counter

counter = resolve_counter("auto")
corpus = load_corpus("docs/en", counter)

tiered = TieredLoading().cost(corpus, "api/05-sessions.md")
print(tiered.components)    # {'l0': 1000, 'l1': 4000, 'l2': 15470}
print(tiered.total_tokens)  # 20470
print(FullDump().cost(corpus, "api/05-sessions.md").total_tokens)  # 355455

生の出力JSONは results/openviking-docs-2026-08.json に置いてあります。

この計測はトークン予算の構造を測ったものであり、検索精度そのものは測っていません。精度の評価にはEmbeddingとVLMのAPIキーが必要で、今回のクリーン環境では実行できませんでした。精度については公式の公開値を後述します。

7. ディレクトリ再帰検索の仕組み

このセクションで分かること

「棚を特定してから本を開く」という検索戦略の具体的な手順が分かります。

公式ドキュメントは、この検索方式をDirectory Recursive Retrievalと呼んでいます。手順は5段階です。

意図分析: 質問から複数の検索条件を生成する
初期測位: ベクトル検索で、最初の断片が属する高スコアのディレクトリを特定する
精査: そのディレクトリの中で二次検索を行い、候補集合を更新する
再帰降下: サブディレクトリがあれば、二次検索を階層ごとに繰り返す
集約: 最も関連する文脈を返す

最後の1行が重要です。返ってくるのは答えだけでなく、どの棚を経由したかという軌跡も一緒です。結果がおかしいとき、どのパスがその結果を生んだのかを直接確認できます。

先ほどの計測では、この絞り込みの効果も測れました。ルート直下では744チャンクが探索対象ですが、api/ に降りた時点で226チャンクになります。1ホップで69.6%の候補が落ちます。ベクトル検索が競う相手が3分の1以下になる、ということです。

8. 実際に動かしてみる

このセクションで分かること

クリーンなLinux環境での導入手順と、実際に踏んだ失敗が分かります。

ここからは机上の話をやめて、実際にインストールします。環境はクリーンなUbuntu 24.04、Python 3.12.3、Rustツールチェーンなし、メモリ3GBです。

失敗1: システムPythonに直接入れて壊れる

最初に何も考えず入れました。

pip install openviking --break-system-packages

結果です。

ERROR: Cannot uninstall PyJWT 2.7.0, RECORD file not found.
Hint: The package was installed by debian.

OpenVikingはPyJWTの新しいバージョンを要求しますが、Debian系のシステムPythonに入っているPyJWTはaptが管理しているため、pipから削除できません。依存の一部だけがインストールされ、中途半端な状態でシステム環境が汚れました。

167個の依存パッケージが入るライブラリを、システムPythonに直接入れるべきではありませんでした。素直に仮想環境を作ります。

成功: 仮想環境で入れる

python3 -m venv .venv
source .venv/bin/activate
pip install openviking

実測値です。

指標	値
インストール所要時間	92秒
依存パッケージ数	167
仮想環境の容量	1.2GB
インストールされたバージョン	0.4.16

1.2GBというのは、tree-sitterの各言語パーサ、Scrapy、pdfplumber、python-docx、python-pptxなどが同梱されるためです。あらゆる形式の資料を書架に入れられるようにする、という思想の代償でもあります。

READMEにはRustツールチェーンとC++コンパイラが前提条件として書かれていますが、PyPIからの通常インストールではビルド済みwheelが降ってくるため、実際には不要でした。ソースからビルドする場合のみ必要になります。

起動前の健康診断

OpenVikingには、サーバを起動せずに前提条件を確認するコマンドがあります。設定ファイルを作る前の状態で叩いてみました。

openviking-server doctor

OpenViking Doctor

  Config:         FAIL  Configuration file not found
                  Fix: Create ~/.openviking/ov.conf or set OPENVIKING_CONFIG_FILE
  Python:         PASS  3.12.3 (>= 3.10 required)
  Native Engine:  PASS  variant=x86_avx512
  AGFS:           PASS  AGFS SDK 0.1.7
  Authentication: WARN  Cannot check (no config file)
  Embedding:      FAIL  Cannot check (no config file)
  VLM:            FAIL  Cannot check (no config file)
  Ollama:         PASS  not configured
  Disk:           PASS  8.6 GB free in /root

  3 check(s) failed. See above for fix suggestions.

Native Engine: PASS variant=x86_avx512 の行が示すとおり、CPUの命令セットを判定して適切なネイティブバイナリを選んでいます。この手の「何が足りないかを先に教えてくれる」設計は、依存が167個ある製品では実質必須です。

失敗2: 言語を選ばないと何も動かない

CLIを叩いたところ、いきなり止まりました。

$ ov status
OpenViking needs a display language before running commands.
Run one of:
  ov language en
  ov language zh-CN

初回起動時に表示言語の選択が必須です。READMEには書かれていません。日本語READMEが用意されているプロジェクトですが、CLIの表示言語は英語か中国語の二択でした。

言語を設定してもう一度叩くと、次の壁が出ます。

No ovcli.conf detected. Run ov config to create one before using server commands.

サーバ設定とクライアント設定は別ファイルです。ov config で対話的に作ります。

設定ファイルの最小構成

VLMとEmbeddingの2種類のモデルが必要です。ローカルで完結させたい場合はOllamaが使えます。

openviking-server init   # 対話ウィザード。Ollama検出とモデル取得まで面倒を見る
openviking-server doctor # 設定を検証
openviking-server        # 起動

手書きする場合の ~/.openviking/ov.conf はこの形です。

{
  "storage": {
    "workspace": "/home/your-name/openviking_workspace"
  },
  "embedding": {
    "dense": {
      "api_base": "https://api.openai.com/v1",
      "api_key": "your-api-key",
      "provider": "openai",
      "dimension": 3072,
      "model": "text-embedding-3-large"
    },
    "max_concurrent": 10
  },
  "vlm": {
    "api_base": "https://api.openai.com/v1",
    "api_key": "your-api-key",
    "provider": "openai",
    "model": "gpt-4o",
    "max_concurrent": 64
  }
}

サーバが立ったら、書架に本を入れます。

ov status
ov add-resource https://github.com/volcengine/OpenViking --wait
ov ls viking://resources/
ov tree viking://resources/volcengine -L 2
ov find "what is openviking"
ov grep "openviking" --uri viking://resources/volcengine/OpenViking/docs/en

ls、tree、find、grep。見慣れたコマンドがそのまま並びます。書架に戻すというのは、こういうことです。Linuxを触ったことがある人なら、初日から迷いません。

9. よくあるエラーと対処法

このセクションで分かること

今回踏んだものを含め、導入時に詰まりやすい箇所と回避策が表で確認できます。

症状	原因	対処
`Cannot uninstall PyJWT, RECORD file not found`	Debian系のシステムPythonにaptが入れたパッケージがある	仮想環境を作ってからインストールする
`OpenViking needs a display language`	初回起動時の言語選択が未実施	`ov language en` を実行する
`No ovcli.conf detected`	クライアント設定が未作成	`ov config` で対話的に作成する
doctorで `Embedding: FAIL`	`ov.conf` が未作成、または `OPENVIKING_CONFIG_FILE` 未設定	設定ファイルを作り、環境変数で場所を指定する
`add-resource` 後に `find` が空を返す	セマンティック処理が非同期で未完了	`--wait` を付けるか `ov wait` で完了を待つ
インストールが極端に遅い	167個の依存を取得している	初回は数分かかる想定で待つ。CI環境ではキャッシュを効かせる
再インデックスしたいがモード名が分からない	`semantic` や `full` というエイリアスは存在しない	`--mode vectors_only` / `semantic_and_vectors` / `prune_orphans` の3択

10. 公式が公開しているベンチマーク

このセクションで分かること

検索精度についての公式の主張と、その読み方の注意点が分かります。

トークン効率は自分で測れましたが、精度は測れていません。公式が0.3.22で公開している値を引用します。

LoCoMoは、長い会話の履歴に依存する質問に答えられるかを測るベンチマークです。

統合先	精度	平均クエリ時間	総入力トークン
OpenClaw ネイティブメモリ	24.20%	95.14s	392,559,404
OpenClaw + OpenViking	82.08%	38.8s	37,423,456
Claude Code 自動メモリ	57.21%	49.1s	353,306,422
Claude Code + OpenViking	80.32%	20.4s	129,968,899

この表を読むときの注意点をひとつ挙げます。これは開発元自身が公開した数値であり、第三者による再現ではありません。ただし再現用スクリプトはリポジトリの benchmark/ に置かれており、検証手順は公開されています。数値をそのまま信じるのではなく、再現できる形で出していることを評価する、という読み方が妥当です。

トークン削減率の91.0%という値は、先ほど自分で測った97.6%と桁が合っています。異なる条件・異なる測り方で同じオーダーの結果が出ている、という点は補強材料になります。

背景となる研究は、VLDB 2026に採択された論文で公開されています。Memory Baseという概念を提唱し、それをVikingDBというベクトルエンジンの上に実装した、という構成です。

11. どこで使い、どこで使わないか

このセクションで分かること

導入判断の材料になる、向く場面と向かない場面が分かります。

書架の比喩を最後まで引っ張ります。図書館が有効なのは蔵書が多いときであって、机の上に本が3冊しかないなら、分類も目次も要りません。

向いている場面

長期間動き続けるエージェントで、セッションをまたいだ記憶が要る場合
資料が数百ファイル規模あり、階層構造に意味がある場合
検索結果がおかしいときに、原因を追跡する必要がある場合
複数のエージェントで同じコンテキストを共有したい場合

向いていない場面

文書が数十件しかない場合。フラットなベクトル検索で十分です
単発の質問応答で、記憶の蓄積が不要な場合
AGPLv3が受け入れられない商用製品への組み込み。この場合はマネージド版や商用ライセンスの検討が必要です
1.2GBの依存を許容できない軽量環境

Dockerイメージが公式提供されているので、依存の重さはコンテナに押し込むのが現実的です。MCPクライアントからも接続できるため、既存のエージェント構成に後付けする経路もあります。

12. 用語集

用語	意味
コンテキストデータベース	エージェントが参照する記憶・資料・スキルを一元管理する仕組み。ベクトルDBより上位の概念
`viking://`	OpenVikingの仮想ファイルシステムを指すURIスキーム
L0 / Abstract	約100トークンの要約。関連性の一次判定に使う
L1 / Overview	約2,000トークンの概要。構造把握と計画立案に使う
L2 / Details	元データの全文
ディレクトリ再帰検索	高スコアのディレクトリを特定してから階層を降りる検索戦略
検索軌跡	どのディレクトリを経由して結果に到達したかの記録
VLM	Vision Language Model。画像を含む資料の理解に使う
Embedding	テキストをベクトルに変換するモデル
AGFS	OpenVikingが内部で使うファイルシステム抽象レイヤ
セッション	エージェントとの一連のやりとり。終了時に記憶が抽出される

13. 学習ロードマップ

ここまで読んで手を動かしたくなった方向けの順路です。書架を作る前に、まず何がどこにあるかを知る必要があります。

前提を固める: LLMとTransformerの基礎、特にコンテキストウィンドウという制約の意味を押さえる
触る: 公式のStudioでインストールせずに挙動を見る
入れる: 仮想環境を作り、Ollamaでローカル完結の構成を組む
測る: 自分の資料を add-resource で入れ、ov abstract と ov read のトークン差を実際に確認する
繋ぐ: MCPクライアントか、使っているエージェントの統合機能で接続する
運用する: Dockerでコンテナ化し、HTTPサービスとして常駐させる

まとめ

OpenVikingの主張は、突き詰めると「コンテキストを箱ではなく書架として扱え」という一点です。

紙片の箱は、少量なら速くて安いです。しかし蔵書が増えると、どの紙片がどの本から来たのか分からなくなり、精度もデバッグ可能性も落ちていきます。書架に戻すと、案内板を読む手間が固定費として発生する代わりに、蔵書がいくら増えてもその手間はほとんど増えません。

今回の実測がまさにそれを示していました。コーパスが2.64倍になっても、辿り着くコストは11.7%しか増えませんでした。案内板を1枚多く読んだ、それだけです。

一方で、この設計にはコストもあります。167個の依存、1.2GBの環境、書き込み時にVLMを回してL0とL1を生成する前処理。机の上に本が3冊しかない段階で図書館を建てるのは、明らかに過剰です。

書架が必要になるほど蔵書が増えたら、そのときに思い出す価値のあるプロジェクトだと思います。

参考文献

以下はすべて、この記事を書く際に実際に参照した一次情報です。各行に何が書いてあるかを添えます。

GitHubリポジトリ本体。README、ライセンス構成、benchmark/ 配下の再現スクリプトが置かれています。この記事のStar数・Fork数・作成日はここのAPIから取得しました。

公式日本語README。この記事で使った日本語訳の用語は、原則としてこのファイルの表記に合わせています。

PyPIパッケージページ。バージョン0.4.16、Python 3.10以上という要件、依存関係の一覧が確認できます。

VikingMem論文のarXivページ。Memory Baseという概念の定義と、VikingDBの上への実装が記述されています。VLDB 2026採択、2026年5月28日投稿。

OpenViking Studio。インストールせずにブラウザ上で挙動を確認できる公式のホスト版デモです。

context-tier-bench。この記事の階層ロード計測に使った自作ツールです。ソース、テスト、生の出力JSONが入っています。

技術メモや検証結果はXでも発信しています。

本文の実測パートを、より踏み込んで書いた記事です。計測設計の詳細、導入時に踏んだ失敗の全記録、公式ベンチマークの読み方を扱っています。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

OpenVikingってなんだ？ — AIの記憶をlsとfindで辿るコンテキストDB

この記事の対象読者

この記事で得られること

この記事で扱わないこと

1. 結論を3行で

このセクションで分かること

2. OpenVikingとは何者か

このセクションで分かること

図書館という比喩を置きます

3. なぜ「ファイルシステム」を名乗るのか

このセクションで分かること

実例1: 同名セクションの取り違え

実例2: 文脈の切断

実例3: デバッグ不能

構造の対比

4. viking:// の中身を覗く

このセクションで分かること

5. L0/L1/L2 — 背表紙・目次・本文

このセクションで分かること

ここまでのまとめ

6. 実測: 階層ロードは何トークン節約するのか

このセクションで分かること

測定条件

コーパスの実測値

結果1: 単一ファイルに到達するコスト

結果2: コーパスを膨らませたとき

7. ディレクトリ再帰検索の仕組み

このセクションで分かること

8. 実際に動かしてみる

このセクションで分かること

失敗1: システムPythonに直接入れて壊れる

成功: 仮想環境で入れる

起動前の健康診断

失敗2: 言語を選ばないと何も動かない

設定ファイルの最小構成

9. よくあるエラーと対処法

このセクションで分かること

10. 公式が公開しているベンチマーク

このセクションで分かること

11. どこで使い、どこで使わないか

このセクションで分かること

12. 用語集

13. 学習ロードマップ

まとめ

参考文献

関連記事