OpenViking入門｜AIエージェント向けコンテキストDBの仕組みとov.conf設定・Docker運用を解説

OpenVikingは、AIエージェントのコンテキスト管理をファイルシステムとして扱うVolcengine（ByteDance）のオープンソースのコンテキストデータベースだ。2026年1月5日の公開から約7か月半でGitHubスター30,132・フォーク2,333（2026年8月20日時点）を記録している。

AIエージェントを本番運用したとき、最初に壁になるのはコンテキスト管理だった。記憶はコードの中に散在し、リソースはベクトルDBに、スキルはまた別の場所に——断片化した状態でエージェントを動かすと、トークンコストが跳ね上がり、検索精度は安定せず、問題が起きても検索の過程が見えない。OpenVikingはこの三重苦に対して、ファイルシステムというシンプルなメタファーで回答する。この領域の選択肢を横断的に見たい場合はAIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証も参照してほしい。

OpenVikingが解こうとしている問題

AIエージェント開発で繰り返し直面する課題は、「コンテキストの断片化」「トークンコストの膨張」「検索のブラックボックス化」の3つに集約できる。

コンテキストの断片化とは、記憶・リソース・スキルという3種類のコンテキストが別々のシステムに分散している状態を指す。長時間タスクでは実行のたびに新しいコンテキストが生まれるが、単純な切り詰めや圧縮では情報の欠落が起きる。

トークンコストの膨張は、すべての関連情報を一度にプロンプトに詰め込む設計から生まれる。プロジェクト全体のドキュメントをRAGで取得して毎回渡すと、関係のある情報もない情報もまとめて送られ、コストが跳ね上がる。

検索のブラックボックス化は従来型RAGの根本的な問題だ。フラットなベクトル空間への類似度検索は、なぜその文書が選ばれたかを説明しにくい。デバッグが困難で、検索ロジックの改善も手探りになる。

OpenVikingはこれらを「ファイルシステムパラダイム」「3段階コンテキストロード」「ディレクトリ再帰検索」「可視化された検索トレジェクトリ」「自動セッション管理」という5つのアプローチで解決しようとしている。

ファイルシステムパラダイム——viking://プロトコルの仮想FS

OpenVikingの最も特徴的な設計は、すべてのコンテキストを仮想ファイルシステムとして扱う点だ。記憶・リソース・スキルをすべてviking://プロトコルのURIにマッピングし、lsやfindのような標準的なファイル操作コマンドでエージェントがコンテキストを操作できる。

viking://
├── resources/              # プロジェクトドキュメント、リポジトリ、Webページ等
│   └── my_project/
│       ├── docs/
│       │   ├── api/
│       │   └── tutorials/
│       └── src/
└── user/
    └── {user_id}/
        ├── memories/
        │   └── preferences/
        │       ├── writing_style
        │       └── coding_habits
        ├── resources/
        │   └── private_project/
        ├── skills/
        │   ├── search_code
        │   └── analyze_data
        └── peers/
            └── web-visitor-alice/

この設計が解決するのは断片化問題だ。記憶・リソース・スキルという異なる種類のコンテキストが、同一の仮想ファイルシステム上に統一されて存在する。エージェントは「ベクトルDBのAPIを呼ぶ」「メモリストアを検索する」という複数のインターフェースを覚える必要がなく、ファイルシステム操作という単一のパラダイムでコンテキスト全体にアクセスできる。

注目したいのは user/{user_id}/ の下に memories だけでなく resources・skills・peers が並んでいる点だ。ユーザーごとに専用のリソースとスキルを持てる構造になっており、peers にはそのユーザーが対話した相手（別のエージェントや訪問者）の情報が入る。単一ユーザー前提のメモリストアではなく、マルチテナントを織り込んだ名前空間設計になっている。

L0/L1/L2の3段階コンテキストロード——トークン削減の核心

OpenVikingがトークンコストを削減できる理由は、コンテキストを3段階の抽象レベルに分けて管理し、必要な情報だけを段階的にロードする設計にある。

コンテキストを追加するとき、OpenVikingはバックグラウンドで3つの表現を自動生成する。

重要なのは、この3層がファイル単位ではなくディレクトリ単位でも生成されることだ。各ディレクトリが自分自身のL0/L1を持つため、配下のファイルを1つも読まずに「このディレクトリは関係あるか」を判定できる。

viking://resources/my_project/
├── .abstract          # L0: 「API認証ガイド、OAuth 2.0・JWT・APIキーを網羅」（〜100トークン）
├── .overview          # L1: 章構成・キーポイント・L2へのナビゲーション（〜2kトークン）
└── docs/
    ├── .abstract      # 各ディレクトリにも対応するL0/L1が存在
    ├── .overview
    └── api/
        ├── auth.md    # L2: フルコンテンツ（オンデマンド）
        └── endpoints.md

エージェントが情報を探すとき、まずL0の100トークンのサマリーで関連性を判定し、有望なディレクトリのみL1の2,000トークンで詳細を確認し、最後に必要なファイルだけL2でフル取得する。従来のRAGがすべての関連チャンクを一度にプロンプトに詰め込んでいたのに対し、このアプローチは「まず概要を把握し、必要な詳細だけを取得する」という人間の情報収集行動に近い。

ディレクトリ再帰検索——従来RAGとの根本的な違い

従来のRAGが「フラットなベクトル空間でTop-K検索」というシンプルな手法に依存しているのに対し、OpenVikingのディレクトリ再帰検索は5段階のプロセスで動作する。

1. インテント分析: クエリから複数の検索条件を生成する
2. 初期ポジショニング: ベクトル検索でスコアの高いディレクトリを特定する
3. 精緻化探索: そのディレクトリ内でセカンダリ検索を行い、高スコア結果を候補セットに追加
4. 再帰ドリルダウン: サブディレクトリが存在する場合は、同じ手順をレイヤーごとに繰り返す
5. 結果集約: 最も関連性の高いコンテキストを集めて返す

この「まず高スコアディレクトリを絞り込み、その中で内容を精緻化探索する」という戦略は、意味的に最適なフラグメントを見つけるだけでなく、その情報が存在するコンテキスト全体（ディレクトリ構造）を理解することで、検索の全体性と精度を向上させる。

可視化された検索トレジェクトリ

従来のRAG最大の問題のひとつが、「なぜこの情報が取得されたのか」がわからないことだった。OpenVikingはすべてのコンテキストがviking://のURIを持つ階層的な仮想ファイルシステムで管理されるため、検索の過程——どのディレクトリを閲覧し、どのファイルを特定したか——が完全に記録される。

このトレジェクトリの可視性は、実際の開発で2つの効果をもたらす。1つは問題の根本原因特定が容易になること。2つ目は、どのディレクトリ構造が検索精度に影響しているかを分析して、コンテキスト整理のロジックを改善できることだ。

自動セッション管理——使うほど文脈が溜まる

OpenVikingには、セッションのコミット後に非同期でメモリを抽出・更新する「自動セッション管理」機能が組み込まれている。システムは会話履歴を分析し、以下の2種類のメモリを自動更新する。

・ユーザーメモリ更新（viking://user/配下）: ユーザーの好みや習慣に関するメモリを更新し、エージェントの応答をユーザーのニーズに合わせる
・エージェント経験蓄積: タスク実行経験から操作のコツやツール活用の知見を抽出し、後続タスクの効率的な意思決定を支援する

後述するtau2-benchの結果は、この「経験メモリ」がタスク成功率そのものを押し上げることを示している。

インストールと初期設定——init/doctorウィザードとov.conf

Python 3.10以上が必要になる。公式が案内する導入手順は、設定ファイルを手書きする方式から init ウィザードに切り替わっている。

pip install openviking --upgrade
openviking-server init      # 対話型ウィザード：プロバイダー・モデル・ov.conf を生成
openviking-server doctor    # 設定の検証（サーバー起動不要）
openviking-server           # 起動

init はプロバイダーの設定を対話形式で進め、~/.openviking/ov.conf を書き出す。対応するのはVolcengine・OpenAI・Codex OAuth・Kimi・GLM・ローカルOllamaで、Ollamaを選んだ場合はランタイムの検出・インストールとハードウェアに見合ったモデルのプルまでウィザードが面倒を見る。

doctor はサーバーを起動せずに、設定ファイル・Pythonバージョン・プロバイダーへの疎通・ディスク容量を検査する。先に doctor を通してから openviking-server を叩くのが、原因の切り分けが最も速い順番だ。

バックグラウンド起動と動作確認は次の通り。CLIクライアント ov はサーバーと同じインストールに同梱されている。

nohup openviking-server > openviking.log 2>&1 &

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

--wait を付けるとセマンティック処理の完了までブロックする。付けない場合、add-resource 直後の ov find は索引がまだ構築されておらず空振りすることがある。

Dockerとサーバー運用

本番環境向けには、リポジトリ同梱の docker-compose.yml を使ったデプロイが用意されている。

git clone https://github.com/volcengine/OpenViking.git
cd OpenViking
docker-compose up -d

公式DockerイメージはVikingBotを同梱し、サーバーとコンソールUIと一緒にデフォルトで起動する。VikingBotはOpenViking上に構築されたエージェントフレームワークで、単体では次のように使う。

pip install "openviking[bot]"
openviking-server --with-bot
ov chat

Kubernetesへのデプロイには examples/k8s-helm/ にHelmチャートが、監視には examples/grafana/ にダッシュボード設定が同梱されている。スタンドアロンのHTTPサービスとして運用する構成は公式のDeployment guideにまとまっている。

ポートと環境変数

同梱の docker-compose.yml を読むと、運用上おさえておくべき値がそのまま書かれている。サーバーの既定ポートは 1933 で、OPENVIKING_SERVER_PORT で上書きできる。ホストの ~/.openviking がコンテナの /app/.openviking にマウントされるため、設定と作業領域はコンテナを作り直しても残る。ヘルスチェックは openviking-entrypoint --healthcheck で行われる。

CLI側の接続先は ovcli.conf で指定する。Dockerで別ポートに変えた場合や、サーバーを別ホストで動かしている場合は、ここを合わせないと ov status が疎通しない。クライアント設定の詳細は公式ドキュメントのClient configurationにある。VikingBotを止めたいときは --without-bot フラグか OPENVIKING_WITH_BOT=0 を使う。

AIコーディングエージェントへの統合

初版の執筆時点では統合例が4種類だったが、現在は11種類に増えている。いずれも「エージェントのコンテキストにOpenVikingのリコールを注入し、セッションのメモリを自動コミットする」という同じ役割を担う。

OpenClaw完全ガイド2026｜GitHub35万★AIアシスタントOSSのインストールから運用までとHermes Agent 使い方｜Telegram・Discord・Slack対応、LLM300+種切替は、いずれも後述のベンチマークで「素の状態」と「OpenViking統合後」を比較された当事者だ。エージェント側の記事と合わせて読むと、どのレイヤーが何を担当しているかが掴みやすい。

Claude Code統合の場合、2つのフックで動作する。UserPromptSubmitフックがユーザー発話ごとにOpenVikingを検索して関連メモリをsystemMessageへ注入し、Stopフックがレスポンス完了ごとにトランスクリプトを解析してメモリを抽出・保存する。エージェント側からのツール呼び出しは不要で、透過的に効く。

メモリ管理そのものを比較検討したい場合は、agentmemory徹底解説｜Claude Code・CursorのAIエージェントに永続メモリを与えるMCPサーバーのようなMCPサーバー単体の実装と並べると、OpenVikingが「メモリ」だけでなくリソースとスキルまで同じ名前空間に載せている点の違いがはっきりする。

OpenViking Helper（ベータ）

macOSとWindows x64向けに、デスクトップコンソール「OpenViking Helper」がベータ提供されている。OpenViking CLI・Claude Code・Codex・Cursor・Trae・OpenCodeを検出して、プラグイン／MCP／フック／CLIの統合設定をGUIで行う。加えて、Claude Code・Codex・Traeのセッションを解析して、リコール・プロンプト注入・MCP呼び出し・キャプチャ・コミットの各イベントを追跡できる。設定を手書きせずに統合の動作確認をしたい場合の入口になる。

OpenVikingのベンチマーク——LoCoMo・tau2-bench・HotpotQA

計測に使われたのはOpenViking 0.3.22（READMEの記載。現行リリースは0.4.15なので、以下の数値もいずれ更新されうる点は織り込んでおきたい）。

ユーザーメモリ（LoCoMo） では、3つのエージェント統合すべてが80〜83%の精度に着地している。素の状態からの伸び幅が大きいのはOpenClawで、24.20%から82.08%へ跳ね上がる。

注目すべきは、トークン削減率と精度向上が比例していない点だ。Hermesはトークン削減が34.3%と最も小さいのに、精度は82.86%と3つの中で最も高い。逆にOpenClawは91.0%削減しながら82.08%に届いている。「削れば削るほど良い」のではなく、素のエージェントがどれだけ非効率な文脈の積み方をしていたかによって、削減余地と精度の伸びが別々に決まっていると読むのが自然だ。すでに文脈管理が洗練されているClaude Code（素で57.21%）は、伸び幅が最も小さい。

エージェント経験（tau2-bench） では、経験メモリの追加によりタスク成功率がRetailで70.94%→77.81%（+6.87ポイント）、Airlineで54.38%→66.25%（+11.87ポイント）に改善している。同一LLMでメモリの有無だけを変えた比較なので、前節の「自動セッション管理」が効いていることの裏付けになる。

ナレッジベースQA（HotpotQA） では、取得件数の設定がそのまま精度とコストのトレードオフになる。top-5構成は72.75%・QAあたり3,154トークン・0.22秒だが、top-20構成は91.00%・12,533トークン・0.23秒に上がる。遅延はほぼ変わらないままトークンを4倍払って精度を18ポイント買う、という構図だ。

なお、FinanceBench・NaturalQuestions・ClapNQ・Qasper・SyllabusQAを横断した単ターンRAGの平均では、OpenViking自身は66.87%・0.19秒で、精度だけならLightRAG（76.00%）に劣る。ここでOpenVikingが際立つのはインデックス構築コストのほうで、8,671,538トークンはLightRAG（62,705,469トークン）の約13.8%にあたる。「どの条件でも最強」ではなく、投入コストに対する効率で効くツールだと読むのが公平だろう。

設計思想の学術的な裏付けとしては、VikingMem: A Memory Base Management System for Stateful LLM-based Applications（arXiv:2605.29640、VLDB 2026採択）が公開されている。OpenVikingはこの論文で述べられたコア機能のサブセットをオープンソース化したもの、という位置づけだ。

ライセンス構成——AGPLv3とApache-2.0が混在する

OpenVikingを「AGPLだから商用利用は避ける」と一括りに判断するのは正確ではない。リポジトリはコンポーネントごとに異なるライセンスを適用している。

実務上の意味は小さくない。自社プロダクトに組み込む可能性が最も高い「CLIクライアント」と「各エージェント向け統合プラグイン例」がApache-2.0側にあるためだ。AGPLv3の伝播を検討すべきなのはサーバー本体を改変して提供する場合であり、examples/claude-code-memory-plugin などを土台に自社の統合を書く行為とは、ライセンス上の扱いが分かれる。

商用エディションとオープンソース版の境界

READMEは「オープンソース版は機能制限版ではない」と明言している——機能ゲートなし、アカウント不要、アクティベーションキー不要で、本番運用も自前で完結できるとしている。有償の2エディションが答えているのは「誰がどこで運用するか」であって「使えるかどうか」ではない、という整理だ。

中国以外の地域向けグローバルホスティングはBytePlusで提供予定とされている。オープンソース版から移行するためのマイグレーションツールも用意されている。

他のコンテキスト管理ツールとの比較

ナレッジグラフ型と比べると、OpenVikingはグラフの関係性抽出よりも「ファイルシステムという直感的な階層構造」と「段階的なコンテキストロード」を優先している。どちらが適切かは用途次第で、複雑な関係性の把握が重要ならグラフ型に分があり、コスト効率と検索の透明性を重視するならOpenVikingが選択肢になる。基礎となる検索側の設計を整理したい場合はRAGとは？仕組み・構築・ベクトルDB選定までが下地になる。

対応プロバイダー

ローカル完結にこだわる場合はOllama構成が現実的な出口になる。init がランタイム検出からモデルのプルまで進めてくれるため、APIキーを持たずに一通り動かして挙動を確かめられる。

エコシステムとパートナー

OpenVikingは他のOSSプロジェクトとの連携を「パートナープロジェクト」として明示している。長期タスク向けハーネスの deer-flow、AIネイティブ分散ファイルシステムのNoKV、ループエンジニアリングのステートカーネル loopx、そして前掲のHermes Agentが確認済みパートナーとして挙がっている。コンテキストDBを中心に、ハーネス・ストレージ・状態管理を組み合わせる構想が読み取れる。

まとめ：どこから触るか

OpenVikingが提示するのは「コンテキストもファイルのように扱う」という、シンプルだが強力なパラダイムシフトだ。仮想ファイルシステムによる構造的整理、L0/L1/L2の段階的ロード、ディレクトリ再帰検索、トレジェクトリの可視化という4つの仕組みを組み合わせて、コスト削減と検索精度向上を同時に取りにいっている。公式ベンチマークでLoCoMo精度80%超・入力トークン34.3〜91.0%削減という数字が出ていることが、その裏付けになる。

触り始める順番としては、次の3段が最もハードルが低い。

・まずインストールなしで OpenViking Studio を開き、コンテキストツリーと /find の挙動を掴む
・ローカルで試すなら pip install openviking --upgrade → openviking-server init（Ollama選択でAPIキー不要）→ openviking-server doctor の順で通す
・既存ワークフローに載せるなら Claude Code・Codex・Cursorなど手元のエージェント向け統合から入る。設定をGUIで済ませたい場合はOpenViking Helperを使う

ライセンスは本体AGPLv3とCLI／examplesのApache-2.0が混在するため、商用利用を検討する場合は「どのコンポーネントを、どう配布するか」を切り分けたうえで現物のLICENSEを確認してほしい。

参照ソース

• volcengine/OpenViking — GitHub公式リポジトリ
• OpenViking公式ドキュメント（docs.openviking.ai）
• OpenViking Benchmark Results — 公式ブログ
• Configuration guide — ov.conf とプロバイダー設定
• Deployment guide — 本番デプロイ
• VikingMem: A Memory Base Management System for Stateful LLM-based Applications（arXiv:2605.29640, VLDB 2026）
• openviking — PyPI（バージョン・対応Python）
• LoCoMo: Long-context Conversational Memory（評価データセット）