OpenClawナレッジベースとRAG検索拡張チュートリアル

はじめに

デフォルトでは、AI モデルはトレーニングデータと現在の会話コンテキストのみに基づいて質問に回答します。しかし実際のシーンでは、AI に社内ドキュメント、製品マニュアル、個人のノートを参照させて回答してほしい場合が多くあります。RAG（Retrieval-Augmented Generation、検索拡張生成）技術は、まさにこの問題を解決する鍵となるものです。本記事では、OpenClaw のためのナレッジベースシステムの構築方法を手順を追って解説します。

一、RAG の原理概要

1.1 RAG とは

RAG のワークフローは以下の通りです：

ユーザーが質問
  │
  ├── ① 質問をベクトルに変換（Embedding）
  │
  ├── ② ベクトルデータベースで最も関連性の高いドキュメント断片を検索
  │
  ├── ③ 関連ドキュメント断片をコンテキストとしてプロンプトに注入
  │
  └── ④ AI モデルがコンテキストに基づいて回答を生成

1.2 RAG vs 直接ファイルアップロード

ほとんどのチームにとって、RAG は最もコストパフォーマンスの高いソリューションです。

二、ナレッジベースディレクトリの設定

2.1 基本設定

// ~/.config/openclaw/openclaw.json5
{
  "knowledgeBase": {
    "enabled": true,
    // ナレッジベースドキュメントディレクトリ（複数対応）
    "directories": [
      {
        "path": "/data/knowledge/company-docs",
        "name": "社内ドキュメント",
        "description": "社内ポリシー、フロー、規範など"
      },
      {
        "path": "/data/knowledge/product-docs",
        "name": "製品ドキュメント",
        "description": "製品マニュアル、API ドキュメントなど"
      },
      {
        "path": "/home/user/notes",
        "name": "個人ノート",
        "description": "個人の学習ノートとメモ"
      }
    ],
    // ファイル変更の監視
    "watchChanges": true,
    // 変更後に自動で再インデックス
    "autoReindex": true
  }
}

2.2 ナレッジベースディレクトリの作成

# ドキュメントディレクトリの作成
sudo mkdir -p /data/knowledge/company-docs
sudo mkdir -p /data/knowledge/product-docs
sudo chown -R $USER:$USER /data/knowledge

# ドキュメントを配置
cp ~/Documents/社内規程.pdf /data/knowledge/company-docs/
cp ~/Documents/API文档.md /data/knowledge/product-docs/
cp -r ~/Documents/技術仕様/ /data/knowledge/company-docs/

三、対応ファイル形式

3.1 ファイル形式サポート一覧

3.2 ファイル形式の設定

{
  "knowledgeBase": {
    "fileTypes": {
      "include": [".md", ".txt", ".pdf", ".docx", ".html", ".csv"],
      "exclude": [".tmp", ".bak", ".log"],
      // 単一ファイルの最大サイズ
      "maxFileSize": "10MB",
      // 無視するディレクトリ
      "ignoreDirs": ["node_modules", ".git", "__pycache__"]
    }
  }
}

3.3 PDF 処理の最適化

# PDF 処理の依存関係をインストール（PDF 解析に問題がある場合）
sudo apt install -y poppler-utils

# PDF 抽出のテスト
pdftotext /data/knowledge/company-docs/規程.pdf -

四、ベクトルストレージの設定

4.1 内蔵ベクトルストレージ（デフォルト）

OpenClaw には軽量なベクトルストレージエンジンが内蔵されており、中小規模のナレッジベースに適しています：

{
  "knowledgeBase": {
    "vectorStore": {
      "type": "builtin",
      "storagePath": "/var/lib/openclaw/vectors",
      // ベクトル次元（Embedding モデルに依存）
      "dimensions": 1536,
      // 類似度アルゴリズム
      "similarityMetric": "cosine"
    }
  }
}

4.2 ChromaDB の使用

より大規模なナレッジベースには ChromaDB がお勧めです：

# ChromaDB のインストール
docker run -d \
  --name chromadb \
  --restart=always \
  -p 8000:8000 \
  -v chroma-data:/chroma/chroma \
  chromadb/chroma:latest

{
  "knowledgeBase": {
    "vectorStore": {
      "type": "chroma",
      "url": "http://localhost:8000",
      "collection": "openclaw_knowledge"
    }
  }
}

4.3 Qdrant の使用

Qdrant はより強力なフィルタリングと検索機能を提供します：

# Qdrant のインストール
docker run -d \
  --name qdrant \
  --restart=always \
  -p 6333:6333 \
  -v qdrant-data:/qdrant/storage \
  qdrant/qdrant:latest

{
  "knowledgeBase": {
    "vectorStore": {
      "type": "qdrant",
      "url": "http://localhost:6333",
      "collection": "openclaw_knowledge"
    }
  }
}

4.4 ベクトルストレージの比較

五、チャンク分割戦略

ドキュメントを適切な小さなチャンク（Chunk）に分割する必要があります。これにより効果的なインデックス作成と検索が可能になります。

5.1 チャンク分割パラメータの設定

{
  "knowledgeBase": {
    "chunking": {
      // チャンク分割戦略
      "strategy": "recursive",
      // 各チャンクの目標サイズ（文字数）
      "chunkSize": 1000,
      // 隣接チャンクのオーバーラップサイズ
      "chunkOverlap": 200,
      // セパレーターの優先順位（高い順）
      "separators": ["\n## ", "\n### ", "\n\n", "\n", "。", ".", " "],
      // ドキュメントメタデータを保持
      "preserveMetadata": true
    }
  }
}

5.2 チャンク分割戦略の説明

5.3 チャンクサイズの選択

チャンクが大きすぎる場合（> 2000文字）：
  ✗ 検索精度が低く、無関係な内容を含む
  ✗ コンテキストウィンドウをより多く消費

チャンクが小さすぎる場合（< 200文字）：
  ✗ コンテキストが不足し、情報が不完全
  ✗ 検索回数が増加

推奨範囲：500-1500 文字、オーバーラップ 100-300 文字

六、Embedding モデルの設定

6.1 Embedding モデルの選択

{
  "knowledgeBase": {
    "embedding": {
      // OpenAI Embedding を使用
      "provider": "openai",
      "model": "text-embedding-3-small",
      "dimensions": 1536,
      "batchSize": 100
    }
  }
}

6.2 各 Embedding モデルの比較

6.3 ローカル Embedding の使用（Ollama）

# Embedding モデルのダウンロード
ollama pull nomic-embed-text

{
  "knowledgeBase": {
    "embedding": {
      "provider": "ollama",
      "model": "nomic-embed-text",
      "dimensions": 768,
      "baseUrl": "http://localhost:11434"
    }
  }
}

七、インデックス管理

7.1 インデックスの構築

# ナレッジベースインデックスの初回構築
openclaw knowledge index

# 出力例：
# ディレクトリをスキャン中: /data/knowledge/company-docs
# ファイル発見: 45 件
# 処理中... ████████████████████ 100%
# ベクトル生成: 1,234 件のドキュメントチャンク
# インデックス完了！所要時間: 2分15秒

# インデックスの更新（変更されたファイルのみ処理）
openclaw knowledge index --update

# インデックスの再構築（クリア後に全量再構築）
openclaw knowledge index --rebuild

7.2 インデックス状態の確認

# ナレッジベースの状態を確認
openclaw knowledge status

# 出力例：
# ┌──────────────────┬────────┬──────────┬──────────────┐
# │ ナレッジベース     │ ファイル数 │ チャンク数 │ 最終更新      │
# ├──────────────────┼────────┼──────────┼──────────────┤
# │ 社内ドキュメント   │ 45     │ 892      │ 2026-04-09   │
# │ 製品ドキュメント   │ 23     │ 342      │ 2026-04-08   │
# │ 個人ノート        │ 67     │ 234      │ 2026-04-09   │
# ├──────────────────┼────────┼──────────┼──────────────┤
# │ 合計             │ 135    │ 1,468    │              │
# └──────────────────┴────────┴──────────┴──────────────┘

7.3 検索効果のテスト

# 検索テスト
openclaw knowledge search "有給休暇のポリシーは何ですか"

# 検索された関連ドキュメント断片と類似度スコアが出力される
# [0.92] company-docs/従業員ハンドブック.pdf (第3章)
#   "正社員は入社1年後に5日間の有給休暇を取得できます..."
# [0.87] company-docs/HRポリシー.md
#   "有給休暇の申請は3営業日前までに..."

八、検索の最適化

8.1 クエリ最適化設定

{
  "knowledgeBase": {
    "retrieval": {
      // 最も関連性の高い Top K 件の結果を返す
      "topK": 5,
      // 最低類似度閾値（この値未満の結果は除外）
      "minScore": 0.7,
      // クエリの書き換えを有効化（AI が検索キーワードを最適化）
      "queryRewrite": true,
      // ハイブリッド検索を有効化（ベクトル + キーワード）
      "hybridSearch": true,
      "hybridWeight": 0.7  // ベクトル検索の重み
    }
  }
}

8.2 検索結果のプロンプトへの注入

{
  "knowledgeBase": {
    "promptTemplate": {
      // 検索結果をシステムプロンプトに注入するテンプレート
      "prefix": "以下の参考資料に基づいてユーザーの質問にお答えください。参考資料に関連する内容がない場合は、その旨を正直にお伝えください。\n\n---\n参考資料：\n",
      "suffix": "\n---\n\n上記の参考資料に基づいてお答えください：",
      // 注入する最大 Token 数
      "maxTokens": 4000
    }
  }
}

九、実際の活用シナリオ

9.1 企業内部ナレッジベース

# 社内ドキュメントをナレッジベースに配置
/data/knowledge/company-docs/
├── 従業員ハンドブック.pdf
├── 経費精算フロー.md
├── 技術仕様/
│   ├── コーディング規約.md
│   ├── デプロイフロー.md
│   └── セキュリティ規範.md
└── 製品ドキュメント/
    ├── ユーザーガイド.pdf
    └── API文档.md

ユーザーが Telegram で「経費精算のフローはどうなっていますか？」と質問すると、OpenClaw が自動的に関連ドキュメントを検索し、正確な回答を返します。

9.2 個人ノートアシスタント

# Obsidian ノートを直接接続
/home/user/notes/
├── 技術学習/
│   ├── Docker入門.md
│   ├── Kubernetesノート.md
│   └── Linuxコマンドクイックリファレンス.md
├── 読書ノート/
└── プロジェクト記録/

9.3 カスタマーサポートナレッジベース

{
  "knowledgeBase": {
    "directories": [
      {
        "path": "/data/knowledge/faq",
        "name": "よくある質問",
        "description": "お客様からのよくある質問と標準回答"
      },
      {
        "path": "/data/knowledge/product-manual",
        "name": "製品マニュアル",
        "description": "製品機能の説明と使い方チュートリアル"
      }
    ]
  }
}

十、メンテナンスとベストプラクティス

10.1 ドキュメント品質が検索品質に影響する

• ドキュメントの構造を明確にする（見出し、リストなどを使用）
• 大量の重複コンテンツを避ける
• 古くなったドキュメントを定期的にクリーンアップ
• Markdown 形式を使用すると最適なチャンク分割効果が得られる

10.2 定期メンテナンス

# 毎週インデックスを再構築（cron）
0 3 * * 0 openclaw knowledge index --rebuild >> /var/log/openclaw-index.log 2>&1

# インデックスの健全性をチェック
openclaw knowledge status

10.3 パフォーマンスの最適化

ナレッジベースと RAG システムを構築することで、OpenClaw は汎用 AI アシスタントから専属のナレッジ Q&A エキスパートにアップグレードされ、自社ドキュメントに基づいたさまざまな質問に正確に回答できるようになります。