OpenVikingとは？

要約

OpenVikingは、AIエージェント向けのオープンソースのコンテキストデータベースで、フラットなベクター格納をファイルシステムパラダイムに置き換えます。コンテキスト（記憶、リソース、スキル）は、`viking://` URIの下に、L0（約100トークン）、L1（約2kトークン）、L2（フルコンテンツ）の3つのレイヤーで整理されます。ベンチマークでは、従来のRAGと比較して91%のトークンコスト削減と43%のタスク完了率向上を示しています。

はじめに

あなたのAIエージェントは物事を忘れがちです。同じAPIエンドポイントを2回尋ねました。ステージング環境の好みを無視しました。昨日どのテストが合格したかを把握できなくなりました。

これが今日のAIエージェント構築の現実です。ほとんどのチームは、RAGパイプライン、ベクターデータベース、カスタムメモリシステムを継ぎ接ぎして使っています。その結果、コンテキストは断片化し、トークンコストは高騰し、サイレントに失敗する検索が発生しています。

データもこれを裏付けています。LoCoMo10データセットを使用したベンチマークテストでは、従来のRAGシステムは、2,400万〜5,100万もの入力トークンを消費しながらも、タスク完了率はわずか35〜44%でした。

OpenVikingは異なるアプローチを取ります。ByteDanceのOpenVikingチームによって開発されたOpenVikingは、フラットなベクター格納をファイルシステムパラダイムに置き換えます。すべてのコンテキストは、階層的なL0/L1/L2ロードを備えた`viking://` URIの下に存在します。その結果、トークンを91%削減しながら52%のタスク完了率を達成しました。

このガイドでは、OpenVikingがどのようにコンテキストの断片化を解決するか、L0/L1/L2モデルが実際にどのように機能するか、そして最初のサーバーを15分でデプロイする方法を学びます。

エージェントのコンテキスト問題

AIエージェントは、従来のアプリケーションでは決して扱わなかったコンテキストの課題に直面しています。

開発者がAPIをテストするのを助けるエージェントを考えてみましょう。1週間で、次のことを追跡する必要があります。

• ユーザー設定（「ステージング環境」、「Pythonよりもcurl」）
• プロジェクトコンテキスト（エンドポイント、認証方法、過去のテスト結果）
• ツールパターン（どのエンドポイントが失敗するか、一般的なスキーマエラー）
• タスク履歴（何がテストされ、どのバグが表面化したか）

従来のRAGは、これをベクターデータベースにフラットなチャンクとして保存します。それをクエリすると、構造も階層もなく、何が欠けているのかも分からない、上位K個の類似フラグメントが得られます。

5つの主要な課題

OpenVikingは、エージェントのコンテキスト管理における5つの主要な問題を特定しています。

これは、「すべてを保存し、漠然と検索する」から「すべてを構造化し、正確に検索する」への転換を表しています。

OpenVikingとは？

OpenVikingは、ByteDanceのOpenVikingチームによってApache 2.0ライセンスのもとで作成された、AIエージェント向けのオープンソースのコンテキストデータベースです。

すべてのコンテキストを仮想ファイルシステムに統合します。記憶、リソース、スキルは`viking://`配下のディレクトリにマッピングされ、それぞれがユニークなURIを持ちます。

viking://
├── resources/              # 外部知識: ドキュメント、コード、Webページ
│   ├── my_project/
│   │   ├── docs/
│   │   │   ├── api/
│   │   │   └── tutorials/
│   │   └── src/
│   └── ...
├── user/                   # ユーザー固有: 設定、習慣
│   └── memories/
│       ├── preferences/
│       │   ├── writing_style
│       │   └── coding_habits
│       └── ...
└── agent/                  # エージェントの能力: スキル、タスク記憶
    ├── skills/
    │   ├── search_code
    │   ├── analyze_data
    │   └── ...
    ├── memories/
    └── instructions/

エージェントは、直接的なコンテキスト操作機能を得ることができます。

• `ls viking://resources/my_project/docs/`でディレクトリをナビゲートする
• `find "authentication methods"`でセマンティック検索を行う
• `read viking://resources/docs/auth.md`で全文を読み込む
• `abstract viking://resources/docs/`で簡単な要約を取得する

これは、ハードドライブ全体を検索するのと、ファイルがどのディレクトリにあるかを正確に知っているのとの違いと考えてください。

主要機能1：ファイルシステム管理パラダイム

ファイルシステムパラダイムは、すべてのコンテキストタイプを単一のモデルの下に統合することで、コンテキストの断片化を解決します。

3つのコンテキストタイプ

各タイプは独自のディレクトリに存在します。

• `viking://resources/`: 製品マニュアル、コードリポジトリ、ドキュメント
• `viking://user/memories/`: ユーザー設定、エンティティ記憶、イベント
• `viking://agent/skills/`: ツール定義、MCP設定
• `viking://agent/memories/`: 学習されたパターン、ケーススタディ

UnixライクなAPI

OpenVikingは、使い慣れたコマンドライン操作を提供します。

from openviking import OpenViking

client = OpenViking(path="./data")

# すべてのコンテキストタイプに対するセマンティック検索
results = client.find("user authentication")

# ディレクトリの内容を一覧表示
contents = client.ls("viking://resources/")

# 全文を読み込む
doc = client.read("viking://resources/docs/auth.md")

# 簡単な要約を取得（L0層）
abstract = client.abstract("viking://resources/docs/")

# 詳細な概要を取得（L1層）
overview = client.overview("viking://resources/docs/")

このAPIは、Python SDKまたはHTTPサーバーを介して機能し、あらゆるエージェントフレームワークと互換性があります。

主要機能2：L0/L1/L2階層コンテキストロード

プロンプトに大量のコンテキストを詰め込むのは高価でエラーが発生しやすいです。OpenVikingはすべてのコンテキストを自動的に3つの階層レイヤーに処理します。

仕組み

リソース（PDFドキュメントファイルなど）を追加すると、OpenVikingは次の処理を行います。

1. ドキュメントをテキストに解析します（まだLLM呼び出しはありません）
2. AGFSストレージにディレクトリツリー構造を構築します
3. セマンティック処理を非同期でキューに入れます
4. L0の概要とL1の概要を下から上に生成します

その結果、階層構造が生まれます。

viking://resources/my_project/
├── .abstract.md               # L0: 「認証、エンドポイント、レート制限をカバーするAPIドキュメント」
├── .overview.md               # L1: セクションナビゲーション付きの詳細な要約
├── docs/
│   ├── .abstract.md          # 各ディレクトリにはL0/L1があります
│   ├── .overview.md
│   ├── auth.md               # L2: 全文
│   ├── endpoints.md
│   └── rate-limits.md
└── src/
    └── ...

トークン予算への影響

この階層は大幅なコスト削減を可能にします。

# 従来のRAG：すべてのコンテンツをロードする
full_docs = retrieve_all("authentication")  # 5万トークン

# OpenViking：L1から開始し、必要に応じてのみL2をロードする
overview = client.overview("viking://resources/docs/auth/")  # 2kトークン

if needs_more_detail(overview):
    content = client.read("viking://resources/docs/auth/oauth.md")  # 特定のL2をロードする

ベンチマークテストでは、このアプローチにより、従来のRAGと比較して入力トークンコストが91%削減され、タスク完了率は43%向上しました。

主要機能3：ディレクトリ再帰検索

単一のベクター検索は複雑なクエリに対応するのが困難です。OpenVikingは**ディレクトリ再帰検索戦略**を実装しています。

5つのステップのプロセス

1. 意図分析
   ↓
2. 初期配置（高スコアディレクトリを見つける）
   ↓
3. 精緻化された探索（ディレクトリ内を検索する）
   ↓
4. 再帰降下（サブディレクトリを深く掘り下げる）
   ↓
5. 結果の集約（ランク付けされたコンテキストを返す）

ステップ1：意図分析

クエリ「ユーザーを認証するにはどうすればよいですか？」は、以下のことを特定するために分析されます。

• 意図タイプ：手続き的なHow-toの質問
• 主要エンティティ：「認証」、「ユーザー」
• 期待されるコンテンツ：認証ガイド、OAuthフロー

ステップ2：初期配置

ベクター検索は高スコアのディレクトリを迅速に特定します。

• `viking://resources/docs/auth/` (スコア: 0.92)
• `viking://resources/docs/security/` (スコア: 0.78)

ステップ3：精緻化された探索

最上位ディレクトリ内で、二次検索により特定のファイルが検索されます。

• `viking://resources/docs/auth/oauth.md` (スコア: 0.95)
• `viking://resources/docs/auth/jwt.md` (スコア: 0.88)

ステップ4：再帰降下

サブディレクトリ（`auth/providers/`など）が存在する場合、プロセスは再帰的に繰り返されます。

ステップ5：結果の集約

最終的な結果は集約され、関連性によってランク付けされ、検索トレースが保持されます。

この「まずディレクトリをロックし、次にコンテンツを探索する」戦略は、孤立したチャンクだけでなく、情報の完全なコンテキストを理解することで、検索精度を向上させます。

主要機能4：可視化された検索トレース

従来のRAGはブラックボックスです。検索が失敗した場合、それがベクター類似性の問題なのか、チャンキングの問題なのか、データが欠落しているのかを判断することはできません。

OpenVikingのファイルシステム構造により、検索は**観測可能**になります。

クエリ「OAuthトークンの更新」の検索トレース

├── viking://resources/docs/
│   ├── [スコア: 0.45] .abstract.md: スキップ（関連性が低い）
│   └── [スコア: 0.89] auth/: 選択済み（関連性が高い）
│       ├── [スコア: 0.92] oauth.md: 返されました
│       ├── [スコア: 0.34] jwt.md: スキップ
│       └── [スコア: 0.78] providers/
│           └── [スコア: 0.85] google.md: 返されました

このトレースは次のことを示しています。

• どのディレクトリが訪問されたか
• なぜ特定のファイルが選択またはスキップされたか
• 検索がたどった正確なパス

デバッグにとって、これは非常に貴重です。エージェントが間違ったディレクトリにいたため、L0の概要が悪かったため、またはスコア閾値を下回ったためにコンテキストを見逃したかどうかを確認できます。

主要機能5：自動セッション管理

OpenVikingには組み込みのメモリ自己反復ループがあります。各セッションの終わりに、システムは記憶を抽出し、エージェントの知識を自動的に更新できます。

6つのメモリカテゴリ

メモリ抽出の仕組み

# セッションを開始する
session = client.session()

# メッセージを追加する（会話のやり取り）
await session.add_message("user", [{"type": "text", "text": "I prefer dark mode in the UI"}])
await session.add_message("assistant", [{"type": "text", "text": "Got it. I'll use dark mode for all future screenshots."}])

# ツール使用を記録する
await session.add_usage({
    "tool": "screenshot",
    "parameters": {"theme": "dark"},
    "result": "success"
})

# セッションをコミットする：メモリ抽出をトリガーする
await session.commit()

コミットされると、OpenVikingは次の処理を行います。

1. セッションを圧縮します（最近のNターンを保持し、古いものをアーカイブします）
2. LLM分析を使用して記憶を抽出します
3. 適切な記憶ディレクトリを更新します
4. 新しい記憶コンテンツのL0/L1を生成します

これにより、エージェントは使用するにつれて賢くなります。ユーザーの好みから学習し、タスクの経験を蓄積し、時間の経過とともに意思決定を改善します。

アーキテクチャの概要

OpenVikingのシステムアーキテクチャは、複数のレイヤー間で関心事を分離します。

デュアルレイヤーストレージ

OpenVikingはコンテンツとインデックスを分離します。

この分離は次のことを保証します。

• すべてのコンテンツの読み込みは単一のソース（AGFS）から行われる
• ベクターインデックスは軽量な参照のみを保存する
• ベクターストレージでの大規模なテキストブロブの重複がない

クイックスタート：最初のOpenVikingサーバーをデプロイする

前提条件

• Python: 3.10以上
• Go: 1.22+ (AGFSコンポーネント用)
• C++コンパイラ: GCC 9+またはClang 11+
• OS: Linux、macOS、またはWindows

ステップ1：OpenVikingをインストールする

pip install openviking --upgrade --force-reinstall

必要に応じて、ターミナルアクセス用にRust CLIをインストールします。

curl -fsSL https://raw.githubusercontent.com/volcengine/OpenViking/main/crates/ov_cli/install.sh | bash

ステップ2：モデルを設定する

OpenVikingには2つのモデル機能が必要です。

• VLMモデル: 画像とコンテンツの理解用
• エンベディングモデル: ベクトル化とセマンティック検索用

`~/.openviking/ov.conf`を作成します。

{
  "storage": {
    "workspace": "/home/your-name/openviking_workspace"
  },
  "log": {
    "level": "INFO",
    "output": "stdout"
  },
  "embedding": {
    "dense": {
      "api_base": "https://api.openai.com/v1",
      "api_key": "your-openai-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-openai-api-key",
    "provider": "openai",
    "model": "gpt-4o",
    "max_concurrent": 100
  }
}

サポートされているプロバイダー：

LiteLLMのサポートにより、Anthropic、Google、ローカルのOllamaモデル、または任意のOpenAI互換エンドポイントを使用できます。

ステップ3：サーバーを起動する

openviking-server

またはバックグラウンドで実行します。

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

ステップ4：最初のリソースを追加する

# Rust CLIを使用する
ov add-resource https://docs.example.com/api-guide.pdf

# またはPython SDKを使用する
from openviking import OpenViking

client = OpenViking(path="./data")
client.add_resource("https://docs.example.com/api-guide.pdf")

ステップ5：検索と取得

# セマンティック処理を待ってから検索する
ov find "authentication methods"

# ディレクトリの内容を一覧表示する
ov ls viking://resources/

# ディレクトリツリーを表示する
ov tree viking://resources/docs -L 2

# 特定のコンテンツをgrepする
ov grep "OAuth" --uri viking://resources/docs/

ステップ6：VikingBotを有効にする（オプション）

VikingBotはOpenViking上に構築されたAIエージェントフレームワークです。

pip install "openviking[bot]"

# ボットを有効にしてサーバーを起動する
openviking-server --with-bot

# 別のターミナルでインタラクティブチャットを開始する
ov chat

パフォーマンスベンチマーク

OpenVikingは、LoCoMo10データセット（1,540件の長距離対話ケース）を使用して、従来のRAG（LanceDB）およびネイティブメモリシステムと比較してベンチマークテストされました。

タスク完了率

主要な調査結果

• ネイティブメモリと比較して43%の改善と91%のトークン削減
• LanceDBと比較して17%の改善と92%のトークン削減
• OpenVikingの階層検索は、より少ないトークンを消費しながら、より関連性の高いコンテキストを見つけました。

これらの結果は、OpenVikingをオープンソースのAIコーディングアシスタントであるOpenClawにプラグインとして統合することで得られました。テストデータセットは、メモリ保持が重要となる長距離対話に基づいています。

OpenVikingとApidogの統合

APIテスト用のAIエージェントを構築するApidogユーザーは、OpenVikingを活用して、会話コンテキストを維持し、APIドキュメントを保存し、セッション間でユーザー設定を記憶することができます。

ステップ1：OpenVikingサーバーをセットアップする

上記のクイックスタートに従って、お好みのVLMモデルとエンベディングモデルでOpenVikingをデプロイしてください。

ステップ2：Apidog APIドキュメントをインポートする

# Apidogプロジェクトのドキュメントをリソースとして追加する
ov add-resource https://docs.apidog.com/overview
ov add-resource https://docs.apidog.com/api-testing

これにより、Apidogのドキュメントが自動的なL0/L1/L2処理と共に`viking://resources/`にインポートされます。

ステップ3：ユーザー設定を保存する

from openviking import OpenViking

client = OpenViking(path="./apidog-agent-data")
session = client.session()

# ユーザーのデフォルトの環境設定を記録する
await session.add_message("user", [{
    "type": "text",
    "text": "Always use the staging environment for API tests"
}])
await session.commit()  # 設定記憶を自動的に抽出します

ステップ4：テスト中にコンテキストをクエリする

# テストを実行する前に、関連するAPIエンドポイントを見つける
results = client.find("authentication endpoints")
for ctx in results.resources:
    print(f"Found: {ctx.uri}")

# ユーザーの環境設定を取得する
prefs = client.find("staging environment preference", target_uri="viking://user/memories/")

ステップ5：エージェントフレームワークに接続する

OpenVikingはPython SDKとHTTP APIの両方を提供します。

# Python SDK
from openviking import OpenViking
client = OpenViking(path="./data")

# またはHTTP API
import httpx
response = httpx.post(
    "http://localhost:1933/api/v1/search/find",
    json={"query": "authentication endpoints"},
    headers={"X-API-Key": "your-api-key"}
)

高度なテクニックとベストプラクティス

実稼働デプロイメントのためのプロのヒント

1. 頻繁にアクセスされるコンテキストを事前にウォームアップする

エージェント操作中のレイテンシーを削減するため、ピーク時間外に重要なドキュメントをL0/L1にロードします。

# セマンティック処理を即座にトリガーする
ov add-resource https://docs.example.com --wait

2. コンテキストの有効期限を実装する

古いセッションデータの自動クリーンアップを設定します。

# 7日以上前のセッションをアーカイブする
await session.archive(max_age_days=7)

3. ベクターインデックスの健全性を監視する

インデックスサイズとクエリレイテンシーを追跡します。

ov debug stats

避けるべき一般的な間違い

1. L2コンテンツの時期尚早なロード: トークンを節約するために常にL0/L1から開始してください
2. セッションコミットのスキップ: メモリ抽出はコミット時にのみ発生します
3. 単一ディレクトリへの過負荷: 大規模なリソースはトピックベースのサブディレクトリに分割してください
4. 検索トレースの無視: 可視化されたトレースを使用して悪い結果をデバッグしてください

パフォーマンス最適化

セキュリティのベストプラクティス

• APIキーは環境変数またはシークレットマネージャーに保存する（設定ファイルには絶対に保存しない）
• すべてのHTTPサーバーデプロイメントでHTTPSを有効にする
• 公開エンドポイントにレート制限を実装する
• 開発用と本番用に別々のAPIキーを使用する

実際の使用事例

1. AIコーディングアシスタント

ある開発チームは、OpenVikingを社内コーディングアシスタントと統合しました。エージェントは現在：

• `viking://resources/my_project/src/`を介してプロジェクト構造をナビゲートする
• ユーザーのコーディング設定（命名規則、テストフレームワーク）を記憶する
• コード生成中に適切なAPIドキュメントを検索する

結果: エージェントの「忘れっぽい」行動が67%減少し、トークンコストが43%削減されました。

2. カスタマーサポートエージェント

あるSaaS企業は、サポートチャットボットにOpenVikingをデプロイしました。

• 製品ドキュメントは`viking://resources/product/`に保存される
• 顧客の会話履歴は`viking://user/memories/past_issues/`に保存される
• サポートプレイブックは`viking://agent/skills/`にスキルとして保存される

結果: 初回解決率が52%から71%に向上しました。

3. リサーチアシスタント

ある研究室は、OpenVikingを使用して論文とノートを整理しています。

• トピック別に分類された論文（`viking://resources/papers/nlp/`）
• スキルとして保存された研究方法論
• 主要な発見のメモリへの自動抽出

結果: 研究者はセマンティック検索により、関連論文を3倍速く見つけられるようになりました。

代替案と比較

OpenVikingは唯一のコンテキスト管理ソリューションではありません。代替案との比較は次のとおりです。

OpenViking vs. 従来のベクターデータベース

OpenViking vs. LangChainメモリ

代替案を検討すべき時

従来のベクターデータベースを使用すべきケース：

• 100ms未満の検索レイテンシーが必要な場合
• ユースケースが単純なキーワード検索である場合
• 既に問題なく機能するRAGパイプラインがある場合

OpenVikingを使用すべきケース：

• 長期間実行されるエージェントの会話を構築している場合
• 複数タイプ（ドキュメント+設定+ツール）のコンテキストが必要な場合
• トークンコストの最適化が重要な場合
• 観測可能でデバッグ可能な検索を求める場合

従来のRAGとの比較

本番環境へのデプロイ

本番環境では、OpenVikingをスタンドアロンのHTTPサービスとして実行します。

推奨インフラストラクチャ

• クラウド: Volcengine ECSまたは同等
• OS: veLinuxまたはUbuntu 22.04以上
• ストレージ: AGFS用のSSDバックアップボリューム
• ネットワーク: モデルAPIへの低レイテンシー接続

セキュリティに関する考慮事項

• APIキーは環境変数またはシークレットマネージャーに保存する
• HTTPエンドポイントの認証を有効にする
• すべてのクライアントとサーバー間の通信にHTTPSを使用する
• 悪用を防ぐためにレート制限を実装する

監視

OpenVikingはロギングとメトリクスをサポートしています。

{
  "log": {
    "level": "INFO",
    "output": "file",
    "path": "/var/log/openviking/server.log"
  }
}

監視対象：

• セマンティック処理キューの深さ
• ベクター検索のレイテンシー
• AGFSの読み書き操作
• メモリ抽出の成功率

制限事項と考慮事項

現在の制限事項

• Python中心: 主要SDKはPython; 他の言語はHTTP統合が必要
• モデル依存性: 外部のVLMおよびエンベディングモデルが必要（組み込み推論なし）
• 学習曲線: ファイルシステムパラダイムは従来のベクターDBとは異なる
• 初期段階: プロジェクトは活発に開発中; APIは変更される可能性あり

OpenVikingを使用すべき時

適しているケース：

• 記憶を必要とする長期間実行されるエージェントの会話
• 複数タイプのコンテキスト（ドキュメント+設定+ツール）
• 観測可能でデバッグ可能な検索の必要性
• トークンコストの最適化が重要である

代替案を検討すべきケース：

• 単純な単発Q&Aアプリケーション
• 既に問題なく機能するRAGパイプラインがある
• 100ms未満の検索レイテンシーが必要な場合（OpenVikingは処理オーバーヘッドを追加する）

今後の展望

OpenVikingは初期開発段階にあります（2025年初頭現在バージョン0.1.x）。ロードマップには以下が含まれます。

• マルチテナントサポート: チーム向けの分離されたワークスペース
• 高度な分析: 検索品質メトリクス、メモリ使用量ダッシュボード
• プラグインエコシステム: 人気のエージェントフレームワークとの事前構築済み統合
• エッジデプロイメント: ローカルファーストアプリケーション向けの軽量モード
• 強化されたMCPサポート: ネイティブModel Context Protocol統合

OpenVikingのチームは、コミュニティ貢献者を積極的に募集しています。このプロジェクトはApache 2.0の下でオープンソースであり、ドキュメントも利用可能です。

結論

OpenVikingは、AIエージェントがコンテキストを管理する方法における転換点を表しています。情報をフラットなチャンクではなくファイルシステムとして整理することで、従来のRAGシステムを悩ませていた断片化、トークン無駄、ブラックボックス検索の問題を解決します。

主要なポイント

• ファイルシステムパラダイムがコンテキストを統一: すべての記憶、リソース、スキルを`viking://` URIの下に
• L0/L1/L2ロードによりトークンを91%削減: すべてをプロンプトに投入するのではなく、段階的なロード
• ディレクトリ再帰検索が精度を向上: まず高スコアのディレクトリをロックし、次にコンテンツを探索
• 可視化されたトレースがデバッグを可能に: 検索がたどった正確なパスを確認
• 自動セッション管理が学習を可能に: エージェントはすべての会話から記憶を抽出