Knowledge Base Manager

AI システムと人間の利用のための高品質な知識ベースを構築・維持します。

コア原則

知識ベース = 構造化された情報 + 質の高いキュレーション + アクセシビリティ

知識ベースはデータの単なる集め置きではなく、質がコントロールされ、検証され、バージョン管理された情報で、質問に答え、推論を支援するよう設計されています。

---

知識ベースを使うべき場合

知識ベースを使うべき場合:

• ✅ 事実的な質問に一貫した回答をする必要がある
• ✅ 情報が頻繁に変わり、バージョン管理が必要
• ✅ 複数のソースを統一・調整する必要がある
• ✅ 出所追跡と引用管理が重要
• ✅ 根拠のある検証可能な情報が必要な AI システムを構築している
• ✅ 組織の知識を保存して検索可能にしたい
• ✅ 相互に関連した概念の複雑なドメインがある

知識ベースを使うべきでない場合:

• ❌ 静的なドキュメントで十分 (ドキュメント + 検索を使用)
• ❌ 誰も保守・更新しない (知識の陳腐化が確実)
• ❌ シンプルな FAQ で全て対応できる (<50 項目)
• ❌ 情報が変わらない (静的サイトの方が早く安い)
• ❌ チームのキュレーション資源が不足している

---

知識ベースのタイプ: 決定フレームワーク

1. ドキュメント型知識ベース (RAG)

概要: 意味論的検索のためにチャンク化・埋め込みされたドキュメント集

最適な用途:

• 技術ドキュメント
• サポート記事、FAQ
• ポリシードキュメント
• 研究論文
• ブログコンテンツ
• ユーザーマニュアル

強み:

• 新しいドキュメントの追加が簡単
• 完全なコンテキストを保持
• テキスト主体のコンテンツに適している

弱み:

• 関係を問い合わせるのが難しい (「誰がどこで働いているか?」)
• ドキュメント間での情報重複
• 事実の一貫性を保つのが困難

使用: rag-implementer スキル + vector-database-mcp

---

2. エンティティ型知識ベース (Knowledge Graph)

概要: 人、場所、物などのエンティティが関係でつながったネットワーク

最適な用途:

• 組織図
• 関係を持つ製品カタログ
• ソーシャルネットワーク
• レコメンデーションシステム
• 不正検出
• サプライチェーン追跡

強み:

• 「X と Y はどう関連しているか?」という問い合わせに優れている
• 一貫した事実 (唯一の情報源)
• 強力なトラバーサル (「友人の友人」)

弱み:

• 前提として モデリングが必要 (オントロジー設計)
• 非構造化情報の追加がより難しい
• グラフクエリの習得曲線

使用: knowledge-graph-builder スキル + graph-database-mcp

---

3. ハイブリッド知識ベース (RAG + Graph)

概要: 非構造化知識用のドキュメント + 構造化エンティティ/関係用のグラフ

最適な用途:

• エンタープライズ知識管理
• 引用と関係を持つ研究
• 医療システム (ドキュメント + 患者/医薬品関係)
• 法律システム (判例 + 先例 + エンティティ)
• eコマース (製品 + 仕様 + 関係)

強み:

• 両方の長所
• さまざまな知識タイプに対応可能
• 豊富なクエリ機能

弱み:

• 構築と維持が最も複雑
• RAG とグラフの両方の専門知識が必要
• インフラストラクチャコストが高い

使用: rag-implementer + knowledge-graph-builder スキルの両方

---

決定ツリー: どの KB タイプ?

どのような知識がありますか?

├─ ほとんどが非構造化テキスト (ドキュメント、記事、コンテンツ)?
│  └─ ドキュメント型 KB (RAG)
│     使用: rag-implementer スキル
│
├─ ほとんどが関係を持つ構造化エンティティ?
│  └─ エンティティ型 KB (Graph)
│     使用: knowledge-graph-builder スキル
│
└─ 両方の混合?
   └─ ハイブリッド KB (RAG + Graph)
      使用: 両方のスキル + このスキルで統合

---

6 段階の知識ベース実装

フェーズ 1: 知識監査とアーキテクチャ設計

目標: 既存の知識とその構造化方法を理解する

アクション:

1. 既存の知識ソースをインベントリ化

   • 内部: データベース、ドキュメント、wiki、Slack、メール
   • 外部: 公開データ、API、第三者ソース
   • 暗黙知: SME インタビュー、録音された会話

2. 知識タイプを分類

   • 事実知識: 検証可能な事実 (「製品 X は $50」)
   • 手続き知識: ハウツー知識 (「デプロイ方法」)
   • 概念知識: 定義と説明
   • 関係知識: エンティティ間の接続

3. KB アーキテクチャを選択

   • ドキュメント型? エンティティ型? ハイブリッド?
   • 決定: 上記のフレームワークを使用

4. 知識スキーマを定義

   • ドキュメント: メタデータフィールド (ソース、日付、著者、カテゴリ)
   • エンティティ: オントロジー (エンティティタイプ、関係タイプ、プロパティ)

検証:

• すべての知識ソースがインベントリ化され、優先順位付けされている
• KB アーキテクチャが選択され、正当化されている
• スキーマが定義され、ユーザーで検証されている
• 成功指標が確立されている

---

フェーズ 2: 知識キュレーションと取り込み

目標: 生の情報を高品質な知識に変換する

アクション:

1. ソースから知識を抽出

   • 自動化: スクレイピング、API 取り込み、ファイル解析
   • 手動: 専門家入力、アノテーション、検証

2. クリーニングと正規化

   • 重複を削除
   • フォーマットを統一
   • 不一致を修正
   • メタデータで充実

3. 知識を構造化

   • ドキュメント: 意味論的な境界でインテリジェントに分割
   • エンティティ: エンティティ、関係、プロパティを抽出

4. 出所情報を追加

   • ソース URL または参照
   • 最終更新タイムスタンプ
   • 著者/貢献者
   • 信頼スコア (該当する場合)

キュレーションのベストプラクティス:

• 唯一の情報源: 1 つの質問に対して 1 つの正規の答え
• 重複排除: 類似した知識エントリをマージ
• 矛盾解決: ソースが一致しない場合、優先順位ルールを確立
• メタデータの充実: メタデータが多いほど、フィルタリングと検索が向上

検証:

• 知識が抽出され、構造化されている
• 品質指標が閾値以上 (精度 >95%)
• すべてのエントリの出所が追跡されている
• サンプルクエリが関連する結果を返している

---

フェーズ 3: ストレージと検索機能のセットアップ

目標: 知識アクセスのための技術的インフラを実装する

アーキテクチャパターン:

ドキュメント型 KB の場合:

// 意味論的検索用ベクトルデータベース
interface DocumentKB {
  store: 'Pinecone' | 'Weaviate' | 'pgvector'
  chunks: {
    content: string
    embedding: number[]
    metadata: {
      source: string
      title: string
      updated_at: string
      category: string
    }
  }[]
}

エンティティ型 KB の場合:

// 関係クエリ用グラフデータベース
interface EntityKB {
  store: 'Neo4j' | 'ArangoDB'
  nodes: {
    id: string
    type: 'Person' | 'Organization' | 'Product' | 'Concept'
    properties: Record<string, any>
  }[]
  relationships: {
    from: string
    to: string
    type: string
    properties: Record<string, any>
  }[]
}

ハイブリッド KB の場合:

// ベクトル DB + グラフ DB の両方
interface HybridKB {
  vectorDB: DocumentKB
  graphDB: EntityKB
  linker: {
    // ドキュメントを内部に記載されているエンティティにリンク
    linkDocumentToEntities(docId: string): string[]
    // エンティティを言及しているドキュメントにリンク
    linkEntityToDocuments(entityId: string): string[]
  }
}

アクション:

1. データベースを選択

   • ドキュメント: Pinecone、Weaviate、pgvector
   • エンティティ: Neo4j、ArangoDB
   • ハイブリッド: 両方 + リンク層

2. 検索/クエリレイヤを実装

   • ベクトル類似度検索 (ドキュメント用)
   • グラフトラバーサル (エンティティ用)
   • ハイブリッドクエリ (両方を結合)

3. キャッシュと最適化を追加

   • 頻繁なクエリをキャッシュ
   • 一般的なアクセスパターンに最適化

検証:

• データベースが展開され、アクセス可能
• 検索/クエリ機能が動作している
• パフォーマンスが要件を満たしている (<100ms ほとんどのクエリ)

---

フェーズ 4: 品質管理と検証

目標: 知識ベースの精度と信頼性を確保する

品質指標:

1. 精度: テスト質問の正解率 %
2. カバレッジ: 回答可能なユーザー質問の %
3. 新鮮さ: 知識の平均経過日数
4. 一貫性: 矛盾/矛盾の %
5. ソース品質: 信頼できるソースからの %

検証戦略:

1. テスト質問セット 既知の正解を持つ 100 以上のテスト質問を作成:

interface TestQuestion {
  question: string
  expected_answer: string
  category: string
  difficulty: 'easy' | 'medium' | 'hard'
}

2. 人間によるレビュー

• ランダムに知識エントリをサンプリング
• 主題の専門家による検証
• ユーザーフィードバックループ

3. 自動チェック

• 重複検出: ほぼ同一のエントリを検出
• 矛盾検出: 矛盾した事実を検出
• 陳腐化検出: 古い情報にフラグを付ける
• 引用検証: ソースが依然として存在するか検証

4. 継続的な監視

interface KBHealthMetrics {
  accuracy_score: number // 0-100
  coverage_score: number // 回答されたクエリの %
  freshness_score: number // 最終更新以来の平均日数
  consistency_score: number // 矛盾なしの %
  user_satisfaction: number // フィードバック評価
}

アクション:

1. テスト質問検証を実行 (目標: >90% 精度)
2. 人間レビューを実施 (エントリの 10% をサンプリング)
3. 検出された問題を修正 (重複、矛盾、陳腐化)
4. 監視ダッシュボードを確立

検証:

• テスト質問での精度が >90%
• ユーザー質問のカバレッジが >80%
• 矛盾情報が <5%
• 監視ダッシュボードが操作可能

---

フェーズ 5: バージョン管理と進化

目標: 知識の変化を時間とともに追跡し、ロールバック機能を有効にする

バージョン管理が重要な理由:

• 知識が変わる (事実が更新される、ポリシーが変更される)
• 監査証跡が必要 (誰が何をいつ変更したか)
• ロールバック機能 (悪い更新を元に戻す)
• 履歴クエリ (「2023 年のポリシー X は何だったか?」)

バージョン管理戦略:

1. スナップショットバージョン管理

interface KnowledgeEntry {
  id: string
  content: string
  version: number
  created_at: string
  updated_at: string
  updated_by: string
  changelog: string
  previous_version?: string // 前バージョンの ID
}

2. イベントソーシング

interface KnowledgeEvent {
  event_id: string
  entity_id: string
  event_type: 'created' | 'updated' | 'deleted'
  timestamp: string
  changes: {
    field: string
    old_value: any
    new_value: any
  }[]
  author: string
}

3. Git スタイルのバージョン管理

• 知識をコードのように扱う
• コミットベースの変更
• 実験的知識のためのブランチ
• 検証時にマージ

アクション:

1. バージョン追跡を実装
2. すべての更新にチェンジログを追加
3. ロールバック機構を作成
4. バージョン比較ツールを構築

検証:

• すべての変更がバージョンで追跡されている
• ロールバックがテストされて動作している
• 履歴クエリが対応されている
• 監査証跡が完成している

---

フェーズ 6: 保守とガバナンス

目標: 長期にわたって知識ベースの健全性を保つ

保守タスク:

日次:

• エラーと故障を監視
• ユーザーフィードバックをレビュー
• 緊急の修正に対応

週次:

• 新しいコンテンツ投稿をレビュー
• 時間依存の知識を更新
• 自動品質チェックを実行

月次:

• 知識の新鮮さを監査
• 矛盾をレビューして解決
• 使用パターンを分析
• 古い内容を更新

四半期ごと:

• 包括的な品質監査
• スキーマ/オントロジーのレビュー
• パフォーマンス最適化
• ユーザー満足度調査

ガバナンスフレームワーク:

1. 役割と責任

• 知識所有者: コンテンツに責任を持つドメイン専門家
• キュレーター: 変更をレビューして承認
• 貢献者: 新しい知識を投稿
• 利用者: 知識を使用してフィードバックを提供

2. 変更プロセス

投稿 → レビュー → 承認 → 公開 → 監視

3. 品質基準

• 最小ソース品質要件
• 引用要件
• 更新頻度要件
• 矛盾解決プロセス

アクション:

1. 保守スケジュールを確立
2. 役割と責任を割り当て
3. ガバナンスドキュメントを作成
4. プロセスについてチームをトレーニング

検証:

• 保守スケジュールが実施されている
• ガバナンスが文書化され、伝達されている
• チームがプロセスについてトレーニングされている
• 品質が向上傾向

---

知識ベースのアンチパターン

❌ アンチパターン 1: キュレーションなしのデータダンプ

問題: すべてを品質フィルタリングなしに取り込む

影響: 信号対ノイズ比が低い、検索結果が悪い、ユーザーの不満

解決: 取り込む前にキュレーション。品質 > 量

---

❌ アンチパターン 2: バージョン管理なし

問題: 知識が変わってもhistoryが追跡されない

影響: 変更を監査できない、エラーをロールバックできない、説明責任なし

解決: フェーズ 5 からバージョン管理を実装

---

❌ アンチパターン 3: 古い知識

問題: 知識ベースが古い日付だが、誰も知らない

影響: AI システムが古い事実を使って幻覚を見る、ユーザーが間違った答えを得る

解決: 新鮮さ監視 + スケジュール更新

---

❌ アンチパターン 4: 重複情報

問題: 同じ事実が複数の場所にあり、矛盾する

影響: 矛盾した答え、ユーザーの混乱

解決: 重複排除 + 唯一の情報源

---

❌ アンチパターン 5: 出所情報なし

問題: ソース引用なしの知識

影響: 精度を検証できない、エラーを追跡できない

解決: ソース + タイムスタンプ + 著者を常に追跡

---

他のスキルとの統合

rag-implementer との統合

• ハイブリッド KB のドキュメント型部分に使用
• RAG 実装フェーズに従う
• ベクトル検索を KB クエリと統合

knowledge-graph-builder との統合

• ハイブリッド KB のエンティティ型部分に使用
• グラフ設計パターンに従う
• グラフトラバーサルを KB クエリと統合

data-engineer との統合

• ETL パイプライン用 (知識の抽出、変換、ロード)
• データ品質監視用
• パフォーマンス最適化用

quality-auditor との統合

• 自動品質チェック用
• テストと検証用
• 継続的な監視用

technical-writer との統合

• 知識ドキュメント用
• KB 使用ガイド用
• ガバナンスドキュメント用

---

ツールとテクノロジー

ドキュメント型 KB スタック

• ベクトル DB: Pinecone、Weaviate、pgvector
• 埋め込み: OpenAI、Cohere、カスタム
• 検索: 意味論的 + キーワードハイブリッド

エンティティ型 KB スタック

• グラフ DB: Neo4j、ArangoDB
• クエリ: Cypher、AQL
• 可視化: Neo4j Bloom、Gephi

キュレーションツール

• 重複排除: カスタムアルゴリズム、ファジーマッチング
• 矛盾検出: ルールベース、ML ベース
• 検証: テスト質問セット、人間によるレビュー

監視

• メトリクス: カスタムダッシュボード (Grafana)
• ログ: 構造化されたクエリ/更新ログ
• アラート: 新鮮さ、精度、エラー率アラート

---

成功指標

知識品質

• 精度: テスト質問で >90%
• カバレッジ: 回答されたユーザー質問の >80%
• 新鮮さ: 平均経過日数 <30 日
• 一貫性: 矛盾情報 <5%

ユーザー満足度

• 関連性: クエリ結果の >85% が関連ありと評価
• 有用性: >80% のユーザーが KB を価値ありと判断
• 速度: 中央値クエリ時間 <100ms

運用健全性

• 稼働時間: >99.9%
• 更新頻度: 最低週 1 回
• チームエンゲージメント: 定期的な貢献

---

一般的な落とし穴と解決策

落とし穴 1: 「構築すれば彼らは来る」

問題: ユーザー検証なし、KB がニーズを満たさない

解決: ユーザー調査から始め、継続的に検証

落とし穴 2: 完璧主義

問題: KB が「完璧」になるまで開始を待つ

解決: カバレッジ 80% で開始し、使用に基づいて反復

落とし穴 3: 過度なエンジニアリング

問題: シンプルなドキュメントで十分な場合に複雑なハイブリッドシステムを構築

解決: シンプルから始め、必要な場合にのみ複雑さを追加

落とし穴 4: 保守の放置

問題: 1 度構築したら、更新しない

解決: 初日から保守スケジュールを確立

---

クイックスタートチェックリスト

開始前:

• このスキル全体を読む
• ドキュメント型 KB を使う場合は rag-implementer をレビュー
• エンティティ型 KB を使う場合は knowledge-graph-builder をレビュー
• 明確なユースケースと成功指標がある

フェーズ 1 - アーキテクチャ (1 週目):

• 知識ソースをインベントリ化
• KB タイプを選択 (ドキュメント/エンティティ/ハイブリッド)
• スキーマ/オントロジーを定義
• インフラストラクチャをセットアップ

フェーズ 2 - 初期構築 (2-3 週目):

• 初期知識を取り込んでキュレーション
• 検索/クエリ機能を実装
• テスト質問セットを作成
• ユーザーと検証

フェーズ 3 - 反復 (継続中):

• 使用に基づいてより多くの知識を追加
• 品質メトリクスを監視
• 発見されたときに問題を修正
• 保守ケイデンスを確立

---

関連リソース

• スキル: rag-implementer、knowledge-graph-builder、data-engineer、quality-auditor
• MCP: vector-database-mcp、graph-database-mcp、knowledge-base-mcp、semantic-search-mcp
• パターン: STANDARDS/architecture-patterns/rag-pattern.md、knowledge-base-pattern.md (近日公開)
• 統合: INTEGRATIONS/pinecone/、INTEGRATIONS/graph-databases/neo4j/

---

さらに詳しく

• The Knowledge Graph Cookbook
• Building Knowledge Bases with LLMs
• RAG: Retrieval-Augmented Generation
• Knowledge Management Best Practices

---

覚えておいてください: 知識ベースの価値はそのキュレーションの質と同等です。初日から品質に投資し、保守プロセスを確立し、ユーザーフィードバックに基づいて反復してください。目標は全ての知識を持つことではなく、正しい 知識を、よく整理され、容易にアクセス可能な形で持つことです。