musubix 3.3.8 → 3.3.9

package/docs/enterprise-knowledge-management.md

@@ -1,1737 +0,0 @@
-<!--
-tags: knowledge-management, enterprise, typescript, ai, git
-title: エンタープライズアプリケーション開発における @musubix/knowledge の重要性
--->
-
-# エンタープライズアプリケーション開発における @musubix/knowledge の重要性
-
-> なぜ組織ルールに従ったアプリケーション開発が重要なのか
-
-## 目次
-
-- [概要](#概要)
-- [Git-Native Knowledge System とは](#git-native-knowledge-system-とは)
-- [1. エンタープライズ開発における課題](#1-エンタープライズ開発における課題)
-- [2. 組織ルールに従った開発の重要性](#2-組織ルールに従った開発の重要性)
-- [3. @musubix/knowledge の機能詳細](#3-musubixknowledge-の機能詳細)
-- [4. 導入効果](#4-導入効果)
-- [5. 実装ガイド](#5-実装ガイド)
-- [6. 成功事例](#6-成功事例)
-- [7. まとめ](#7-まとめ)
-
-## 概要
-
-エンタープライズアプリケーション開発において、組織の知識・ルール・ベストプラクティスを体系的に管理し、開発チーム全体で共有することは、プロジェクトの成功を左右する重要な要素です。
-
-`@musubix/knowledge` は、この課題を解決するために設計された **Git-Native Knowledge System** です。
-
-### ✨ 最大の特徴: 自然言語で登録・管理
-
-:::note info
-`@musubix/knowledge` の革新的な点は、**コードを一切書かずに自然言語だけで知識を管理できる**ことです。
-:::
-
-```
-👤 「新しいコーディング規約として、非同期関数にはAsync接尾辞をつけるルールを登録して」
-🤖 ✅ rule:CODE-STYLE-004 として登録しました
-
-👤 「セキュリティ関連の知識を全部見せて」
-🤖 📋 セキュリティ関連の知識 5件を表示します...
-
-👤 「このパターンとあのガイドラインを関連付けて」
-🤖 ✅ リレーションを追加しました
-```
-
-GitHub Copilot、Claude Code等のAIエージェントと会話するだけで、知識の登録・検索・更新・削除がすべて完了します。
-
-:::note
-**なぜ可能なのか？**
-- **Git-Nativeだから**: 知識は`.knowledge/graph.json`という**ただのJSONファイル**
-- AIエージェントはワークスペース内のファイルを直接読み書きできる
-- MCP連携を設定すれば、より高度な操作（クエリ、トラバース等）も可能
-
-APIやJSON形式を覚える必要はありません。
-:::
-
-本記事では、なぜ組織ルールに従った開発が重要なのか、そして `@musubix/knowledge` がどのようにその実現を支援するのかを解説します。
-
----
-
-## Git-Native Knowledge System とは
-
-MUSUBIX v3.0.0 で採用された **Git-Native Knowledge System** は、従来のナレッジ管理システムとは根本的に異なるアプローチを取ります。
-
-### 従来のナレッジ管理システムの問題点
-
-:::note warn
-**従来のアプローチ**
-
-アプリケーション → **Knowledge Database Server** (常時稼働が必要) → PostgreSQL / MongoDB / Neo4j など
-:::
-
-| 問題点 | 説明 |
-|--------|------|
-| ⚠️ サーバーの運用・保守コスト | DBサーバーの監視、アップデート、障害対応が必要 |
-| ⚠️ データベースのバックアップ・復旧 | 定期バックアップ、障害時のリストア手順が必要 |
-| ⚠️ チーム間での同期・コンフリクト解決が困難 | 同時編集時のロック、マージが複雑 |
-| ⚠️ 変更履歴の追跡が複雑 | 監査ログの実装、履歴テーブルの管理 |
-| ⚠️ オフライン環境で使用不可 | サーバー接続が必須 |
-| ⚠️ セットアップの複雑さ | Docker、環境変数、接続情報の管理 |
-
-### Git-Native Knowledge System のアプローチ
-
-:::note info
-**Git-Native アプローチ**
-
-アプリケーション → `.knowledge/graph.json` (ただのJSONファイル) → Git リポジトリで管理
-:::
-
-| メリット | 説明 |
-|----------|------|
-| ✅ サーバー不要（ゼロインフラ） | DBサーバーの運用・保守が一切不要 |
-| ✅ Gitの全機能が使える | 履歴、diff、ブランチ、PRがそのまま利用可能 |
-| ✅ チーム間の同期は git pull/push で完了 | 開発者が慣れたワークフロー |
-| ✅ 変更履歴は git log で完全追跡 | 誰が、いつ、何を変えたか一目瞭然 |
-| ✅ オフラインでも完全動作 | ローカルファイルなのでネット不要 |
-| ✅ npm install だけでセットアップ完了 | 環境構築が数秒で終わる |
-
-### なぜ「Git-Native」なのか
-
-「Git-Native」とは、単に「Gitで管理できる」という意味ではありません。**Gitの思想・ワークフローを知識管理の中心に据えた設計**を意味します。
-
-| Git の概念 | 知識管理への応用 |
-|-----------|-----------------|
-| **commit** | 知識の変更を記録。誰が、いつ、何を変えたか追跡 |
-| **branch** | 新ルールを試験的に導入。問題があればマージしない |
-| **pull request** | 知識の追加・変更をチームでレビュー |
-| **merge** | レビュー済みの知識をmainブランチに統合 |
-| **diff** | 知識の変更内容を視覚的に確認 |
-| **blame** | 特定のルールを誰が追加したか特定 |
-| **revert** | 問題のあるルールを即座にロールバック |
-| **tag** | 知識ベースのバージョンをリリース管理 |
-
-### 具体的なワークフロー例
-
-<details><summary>例1: 新しいコーディング規約の導入</summary>
-
-```bash
-# 1. featureブランチを作成
-git checkout -b feature/add-async-naming-rule
-
-# 2. AIエージェントと会話して知識を追加
-👤 「非同期関数にはAsync接尾辞をつけるルールを登録して」
-🤖 ✅ rule:CODE-STYLE-004 として登録しました
-
-# 3. 変更を確認
-git diff .knowledge/graph.json
-# +  {
-# +    "id": "rule:CODE-STYLE-004",
-# +    "type": "coding-standard",
-# +    "name": "非同期関数の命名規則",
-# +    ...
-# +  }
-
-# 4. コミット
-git add .knowledge/graph.json
-git commit -m "knowledge: add async function naming rule (CODE-STYLE-004)"
-
-# 5. PRを作成してチームレビュー
-git push origin feature/add-async-naming-rule
-# → GitHub/GitLabでPR作成
-
-# 6. レビュー承認後、mainにマージ
-git checkout main
-git merge feature/add-async-naming-rule
-```
-
-</details>
-
-<details><summary>例2: 問題のあるルールのロールバック</summary>
-
-```bash
-# 特定のルールを追加したコミットを特定
-git log --oneline .knowledge/graph.json
-# a1b2c3d knowledge: add problematic rule (CODE-STYLE-XXX)
-# ...
-
-# そのコミットをリバート
-git revert a1b2c3d
-
-# または、特定のバージョンに戻す
-git checkout v2.0.0 -- .knowledge/graph.json
-```
-
-</details>
-
-<details><summary>例3: チーム間での知識同期</summary>
-
-```bash
-# チームAが新ルールを追加
-git pull origin main  # 最新の知識を取得
-# → AIエージェントが自動的に新ルールを認識
-
-# チームBも同様に
-git pull origin main
-# → 全員が同じ知識ベースで作業
-```
-
-</details>
-
-### Git-Native の技術的メリット
-
-#### 1. ゼロインフラ・ゼロ依存
-
-```typescript:setup.ts
-// セットアップはこれだけ
-// npm install musubix
-import { createKnowledgeStore } from 'musubix';
-
-const store = createKnowledgeStore('.knowledge');
-// データベース接続不要、環境変数不要、Docker不要
-```
-
-#### 2. 完全なオフライン動作
-
-```
-インターネット接続なし:
-- 従来のDB方式: ❌ サーバーに接続できない
-- Git-Native: ✅ ローカルのJSONファイルで完全動作
-```
-
-#### 3. 差分の可読性
-
-```json
-// git diff の結果が人間に読める
-- "confidence": 0.85,
-+ "confidence": 0.95,
-```
-
-#### 4. コンフリクト解決の容易さ
-
-```json
-// JSONの構造が単純なので、コンフリクト解決が容易
-<<<<<<< HEAD
-  "tags": ["security", "auth"]
-=======
-  "tags": ["security", "authentication", "jwt"]
->>>>>>> feature/update-tags
-```
-
-#### 5. CI/CD統合
-
-```yaml:.github/workflows/knowledge-validation.yml
-name: Knowledge Validation
-on:
-  pull_request:
-    paths:
-      - '.knowledge/**'
-
-jobs:
-  validate:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-      - run: npx musubix knowledge validate
-      - run: npx musubix knowledge check-circular
-```
-
-### v3.0.0以前（YATAシステム）との比較
-
-MUSUBIX v2.x までは、YATA（Yet Another Turing Architecture）という分散データベースシステムを採用していました。
-
-| 観点 | YATA (v2.x) | Git-Native (v3.0.0) |
-|------|-------------|---------------------|
-| **アーキテクチャ** | 分散DB（Redis + PostgreSQL） | JSONファイル |
-| **セットアップ** | Docker Compose + 環境変数 | `npm install` のみ |
-| **サーバー** | 常時稼働が必要 | 不要 |
-| **同期** | 専用プロトコル | git pull/push |
-| **レビュー** | 専用UI（KGPR） | GitHub/GitLab PR |
-| **履歴追跡** | 専用ログテーブル | git log |
-| **バックアップ** | DB ダンプ | git clone |
-| **学習コスト** | YATA独自の概念 | Gitの知識で十分 |
-| **オフライン** | 限定的 | 完全対応 |
-
-**移行の理由:**
-1. **シンプルさ**: 「知識管理にDBは不要」という気づき
-2. **普及したツールの活用**: 全開発者がGitを知っている
-3. **運用コスト削減**: インフラ管理の負担をゼロに
-4. **透明性**: JSONなので中身が誰でも読める
-
-### Git-Native が適さないケース
-
-:::note alert
-正直に言うと、Git-Native Knowledge System が最適でないケースもあります。
-:::
-
-| ケース | 推奨される代替案 |
-|--------|------------------|
-| **超大規模（100万エンティティ以上）** | Neo4j, TigerGraph等のグラフDB |
-| **リアルタイム同期が必須** | Firebase, Supabase等のリアルタイムDB |
-| **複雑なグラフクエリ** | GraphDBとCypherクエリ |
-| **非開発者のみで運用** | Notion, Confluence等のSaaS |
-
-**ただし、ほとんどのエンタープライズ開発では**、組織の知識は数百〜数千エンティティ程度であり、Git-Native で十分対応可能です。
-
----
-
-## 1. エンタープライズ開発における課題
-
-### 1.1 知識の断片化問題
-
-多くの企業では、開発に関する知識が以下のように断片化しています。
-
-```
-📁 現状の知識散在状況
-├── Confluenceのどこかにあるコーディング規約
-├── Slackの過去ログに埋もれた設計決定
-├── 退職者の頭の中にしかないベストプラクティス
-├── プロジェクトごとに異なるルール
-└── 「暗黙の了解」として共有されない知識
-```
-
-**結果として発生する問題：**
-- 新人オンボーディングに時間がかかる
-- 同じ議論を何度も繰り返す
-- プロジェクト間で品質にばらつきが出る
-- 過去の失敗から学ばない
-
-### 1.2 「車輪の再発明」の連鎖
-
-組織知識が適切に管理されていないと、各プロジェクト・各チームが同じ問題を独自に解決しようとします。
-
-```
-Project A: 独自のエラーハンドリング方式を開発 → 3週間
-Project B: また別のエラーハンドリング方式を開発 → 3週間
-Project C: さらに別の方式... → 3週間
-
-本来: 組織のベストプラクティスを適用 → 3日
-```
-
-:::note warn
-**年間コスト換算例：**
-10プロジェクト × 10パターン × 2週間 = **200週間（約4人年）のロス**
-:::
-
-### 1.3 AIエージェント時代の新たな課題
-
-GitHub Copilot、Claude、ChatGPT等のAIコーディングアシスタントの普及により、新たな課題が顕在化しています。
-
-| 課題 | 説明 |
-|------|------|
-| **一般的なベストプラクティスの適用** | AIは一般的な知識に基づいてコードを生成するが、組織固有のルールを知らない |
-| **一貫性の欠如** | 開発者ごとにAIへの指示が異なり、生成されるコードの品質がばらつく |
-| **コンテキストの欠落** | AIは過去の設計決定や組織のアーキテクチャ方針を参照できない |
-
----
-
-## 2. 組織ルールに従った開発の重要性
-
-### 2.1 品質の一貫性
-
-組織全体で統一されたルールに従うことで、どのプロジェクト・どの開発者が担当しても、一定の品質水準が保証されます。
-
-```typescript:example-bad-naming.ts
-// ❌ ルールなし: 開発者ごとにバラバラ
-// 開発者A
-function get_user_data(user_id) { ... }  // snake_case
-
-// 開発者B
-function GetUserData(userId) { ... }     // PascalCase
-
-// 開発者C
-function getUserData(user_id) { ... }    // 混在
-```
-
-```typescript:example-good-naming.ts
-// ✅ 組織ルールあり: 統一された命名
-// rule:CODE-STYLE-001 に従う
-function getUserById(userId: string): User { ... }  // camelCase統一
-```
-
-### 2.2 オンボーディングの効率化
-
-新しいメンバーが参加した際、組織の知識ベースにアクセスできれば、学習曲線を大幅に短縮できます。
-
-```
-従来のオンボーディング:
-Week 1: 環境構築で悪戦苦闘
-Week 2: 「このルールどこに書いてある？」を繰り返す
-Week 3: 先輩の過去コードを読み漁る
-Week 4: やっと最初のPRを出せる
-
-知識ベース活用時:
-Day 1: 環境構築（手順が明文化）
-Day 2-3: 知識ベースで組織ルールを学習
-Day 4: ベストプラクティスに従ってコーディング開始
-Day 5: 最初のPRを出せる
-```
-
-### 2.3 AIエージェントの精度向上
-
-`@musubix/knowledge` で管理された組織知識をAIエージェントに提供することで、組織固有のルールに従ったコード生成が可能になります。
-
-``````
-👤 ユーザー:
-ユーザー登録機能を実装して
-
-🤖 AIエージェント（組織知識なし）:
-// 一般的なパターンで実装
-function registerUser(name, email, password) {
-  // ... 汎用的な実装
-}
-
-🤖 AIエージェント（@musubix/knowledge連携）:
-// 組織のルールを参照:
-// - rule:CODE-STYLE-001 → camelCase命名
-// - pattern:BP-CODE-001 → Input DTOを使用
-// - pattern:BP-CODE-005 → Result型でエラー処理
-// - guideline:SEC-001 → パスワードはbcryptでハッシュ化
-
-```typescript:user-registration.ts
-interface RegisterUserInput {
-  name: string;
-  email: string;
-  password: string;
-}
-
-async function registerUser(
-  input: RegisterUserInput
-): Promise<Result<User, RegistrationError>> {
-  const hashedPassword = await bcrypt.hash(input.password, 10);
-  // ... 組織ルールに準拠した実装
-}
-``````
-
-### 2.4 技術的負債の抑制
-
-一貫したルールに従うことで、将来のメンテナンスコストを大幅に削減できます。
-
-| 観点 | ルールなし | ルールあり |
-|------|-----------|-----------|
-| コードレビュー時間 | 長い（スタイル議論が多い） | 短い（本質的な議論に集中） |
-| バグ修正 | 各プロジェクト固有の実装を理解する必要 | パターンが共通なので理解が早い |
-| リファクタリング | 影響範囲の予測が困難 | 標準パターンに基づき安全に実施 |
-| 人員異動 | 引き継ぎに時間がかかる | 知識ベースで自己学習可能 |
-
----
-
-## 3. @musubix/knowledge の機能詳細
-
-### 3.1 階層型ID体系
-
-知識を種類ごとに整理し、検索・参照を容易にします。
-
-```
-pattern:BP-CODE-001     # ベストプラクティス
-rule:CODE-STYLE-001     # 開発ルール
-guideline:SEC-001       # ガイドライン
-domain:EC-TERM-001      # ドメイン用語
-arch:ADR-001            # アーキテクチャ決定
-```
-
-### 3.2 リレーション管理
-
-知識間の関連を明示的に管理し、関連知識を辿ることができます。
-
-```
-guideline:SEC-004 (入力検証)
-    ├── references → pattern:BP-CODE-005 (Result型)
-    └── relatedTo → rule:ERROR-001 (エラーハンドリング)
-
-arch:ADR-003 (レイヤードアーキテクチャ)
-    └── references → pattern:BP-DESIGN-001 (Status Transition Map)
-```
-
-### 3.4 AIエージェント統合
-
-`@musubix/knowledge` はGit-NativeなJSONファイル形式のため、AIエージェントが**MCP設定なしでも**直接アクセスできます。
-
-#### なぜMCPなしで動くのか
-
-| 方式 | 仕組み | 設定 |
-|------|--------|------|
-| **直接アクセス** | AIが`.knowledge/graph.json`をワークスペースファイルとして読み書き | 不要（デフォルト） |
-| **MCP連携** | MUSUBIXサーバー経由でクエリ・トラバース等の高度な操作 | MCPサーバー設定が必要 |
-
-**GitHub Copilot、Claude Code**：ワークスペース内のファイルを読み取る機能があるため、`.knowledge/graph.json`を直接参照できます。
-
-#### 直接アクセスの例
-
-```
-👤 ユーザー:
-新しいAPIエンドポイントを作るんだけど、うちのルールを教えて
-
-🤖 AIエージェント:
-API開発に関連する組織ルール:
-
-**必須ルール:**
-- rule:CODE-STYLE-001: TypeScript命名規則（camelCase）
-- rule:GIT-002: コミットメッセージはConventional Commits形式
-- rule:TEST-001: カバレッジ80%以上必須
-
-**セキュリティガイドライン:**
-- guideline:SEC-002: JWT認証必須
-- guideline:SEC-004: 入力検証はzodで実装
-
-**推奨パターン:**
-- pattern:BP-CODE-005: エラーはResult型で処理
-- pattern:BP-CODE-001: リクエストはInput DTOで受け取る
-
-これらに従って実装を進めましょうか？
-```
-
-### 3.5 🌟 自然言語による知識の登録・管理
-
-`@musubix/knowledge` の最大の特徴は、**コードを一切書かずに自然言語だけで知識を管理できる**ことです。GitHub Copilot、Claude Code等のAIエージェントと会話するだけで、すべての操作が完了します。
-
-:::note
-**なぜMCP設定なしで動くのか？**
-
-Git-Nativeアーキテクチャにより、知識は`.knowledge/graph.json`というJSONファイルに保存されます。AIエージェントはワークスペース内のファイルを直接読み書きできるため、特別な設定なしで知識管理が可能です。
-:::
-
-#### 自然言語でできる操作一覧
-
-| 操作 | 従来の方法 | @musubix/knowledge |
-|------|-----------|-------------------|
-| 知識の登録 | JSONを手書き or コード実行 | 「〜を登録して」と話すだけ |
-| 知識の検索 | クエリAPIを呼び出し | 「〜を見せて」と話すだけ |
-| 関連付け | コードでリレーション追加 | 「〜と〜を関連付けて」と話すだけ |
-| 知識の更新 | ファイル編集 or コード | 「〜を修正して」と話すだけ |
-| 削除 | コードで削除API呼び出し | 「〜を削除して」と話すだけ |
-
-<details><summary>🔹 例1: ベストプラクティスの登録</summary>
-
-```
-👤 ユーザー:
-今日のプロジェクトで「Optimistic Locking」というパターンを使ったんだけど、
-これを組織の知識ベースに登録しておいて。
-同時編集検出のためのversion管理パターンで、信頼度は90%。
-タグはconcurrency, design-pattern, databaseで。
-
-🤖 AIエージェント:
-ベストプラクティスとして登録しました:
-
-✅ **pattern:BP-DESIGN-002** - Optimistic Locking
-- カテゴリ: design
-- 説明: 同時編集検出のためのversion管理パターン
-- 信頼度: 90%
-- タグ: concurrency, design-pattern, database
-- 登録日時: 2026-01-12
-
-コード例も追加しますか？
-
-👤 ユーザー:
-うん、追加して
-
-🤖 AIエージェント:
-コード例を追加しました:
-
-```typescript:optimistic-locking.ts
-interface Entity {
-  id: string;
-  version: number;
-  // ...other fields
-}
-
-function update(entity: Entity, currentVersion: number): Result<Entity, ConcurrencyError> {
-  if (entity.version !== currentVersion) {
-    return err(new ConcurrencyError('Entity was modified by another user'));
-  }
-  return ok({ ...entity, version: entity.version + 1 });
-}
-```
-
-他にも登録したいパターンはありますか？
-```
-
-</details>
-
-<details><summary>🔹 例2: コーディング規約の追加</summary>
-
-```
-👤 ユーザー:
-新しいコーディング規約を追加したい。
-「非同期関数の命名規則」として、非同期関数には必ずAsync接尾辞をつける。
-例: getUserAsync, saveOrderAsync
-これは必須ルールで、ESLintで強制する。
-
-🤖 AIエージェント:
-コーディング規約を登録しました:
-
-✅ **rule:CODE-STYLE-004** - 非同期関数の命名規則
-- タイプ: coding-standard
-- 説明: 非同期関数には必ずAsync接尾辞をつける
-- 例:
-  - ✅ getUserAsync()
-  - ✅ saveOrderAsync()
-  - ❌ getUser() (非同期なのに接尾辞なし)
-- 強制: ESLint
-- 優先度: mandatory
-
-関連する既存ルール rule:CODE-STYLE-001 (TypeScript命名規則) と
-関連付けしておきますか？
-
-👤 ユーザー:
-お願い
-
-🤖 AIエージェント:
-関連付けを追加しました:
-- rule:CODE-STYLE-001 → rule:CODE-STYLE-004 (relatedTo)
-
-命名規則が統一的に管理されるようになりました。
-```
-
-</details>
-
-<details><summary>🔹 例3: ドメイン知識の蓄積</summary>
-
-```
-👤 ユーザー:
-ECサイトのドメイン用語「バックオーダー」を登録して。
-在庫がない商品を先に注文受付し、入荷次第発送する仕組み。
-タグはe-commerce, inventory, order-management
-
-🤖 AIエージェント:
-ドメイン用語を登録しました:
-
-✅ **domain:EC-TERM-002** - バックオーダー
-- タイプ: domain-term
-- 説明: 在庫がない商品を先に注文受付し、入荷次第発送する仕組み
-- ドメイン: e-commerce
-- タグ: e-commerce, inventory, order-management
-
-関連する用語 domain:EC-TERM-001 (SKU) や
-domain:EC-RULE-001 (在庫引当ルール) との関連付けを追加しますか？
-
-👤 ユーザー:
-在庫引当ルールと関連付けて
-
-🤖 AIエージェント:
-関連付けを追加しました:
-- domain:EC-TERM-002 → domain:EC-RULE-001 (relatedTo)
-  説明: バックオーダーは在庫引当ルールの例外処理として使用される
-```
-
-</details>
-
-<details><summary>🔹 例4: 知識の検索と活用</summary>
-
-```
-👤 ユーザー:
-セキュリティ関連の知識を全部見せて
-
-🤖 AIエージェント:
-セキュリティ関連の知識 (5件):
-
-**ガイドライン:**
-1. guideline:SEC-001 - パスワードハッシュ化 (bcrypt, 10rounds以上)
-2. guideline:SEC-002 - API認証 (JWT必須, 24時間有効)
-3. guideline:SEC-003 - 機密情報管理 (環境変数 or Secret Manager)
-4. guideline:SEC-004 - 入力検証 (zodでホワイトリスト検証)
-
-**関連ルール:**
-5. rule:DEP-001 - 依存関係管理 (脆弱性チェック必須)
-
-詳細を見たい項目はありますか？
-
-👤 ユーザー:
-SEC-004の詳細と関連知識を教えて
-
-🤖 AIエージェント:
-**guideline:SEC-004 - 入力検証ガイドライン**
-
-📋 説明:
-すべての外部入力は検証・サニタイズを行う
-
-🔒 優先度: critical
-
-📝 詳細:
-- ライブラリ: zod
-- タイミング: APIの入口で即座に検証
-- 原則: ホワイトリスト方式
-
-⚠️ 対策:
-- SQLインジェクション対策 (プリペアドステートメント)
-- XSS対策 (HTMLエスケープ)
-- パストラバーサル対策 (パス検証)
-
-📦 コード例:
-```typescript:input-validation.ts
-const UserInputSchema = z.object({
-  name: z.string().min(1).max(100),
-  email: z.string().email(),
-  age: z.number().int().min(0).max(150),
-});
-```
-
-🔗 関連知識:
-- → rule:ERROR-001 (エラーハンドリング規約)
-- ← guideline:SEC-001 (パスワードハッシュ化) から参照
-```
-
-</details>
-
-<details><summary>🔹 例5: アーキテクチャ決定の記録</summary>
-
-```
-👤 ユーザー:
-今日の設計会議で「キャッシュ戦略としてRedisを採用」と決定した。
-ADRとして記録しておいて。
-コンテキストは「APIレスポンスが遅い、DBへの負荷が高い」
-代替案は「Memcached」「アプリケーション内キャッシュ」だった
-
-🤖 AIエージェント:
-アーキテクチャ決定を記録しました:
-
-✅ **arch:ADR-004** - Redisキャッシュ戦略の採用
-- ステータス: accepted
-- 日付: 2026-01-12
-
-📋 コンテキスト:
-APIレスポンスが遅い、DBへの負荷が高い
-
-✅ 決定:
-キャッシュ戦略としてRedisを採用
-
-🔄 検討した代替案:
-- Memcached
-- アプリケーション内キャッシュ
-
-追加で「なぜRedisを選んだか」の理由と
-「想定される影響」も記録しますか？
-
-👤 ユーザー:
-理由は永続化オプションがあること、データ構造が豊富なこと。
-影響はプラスがレスポンス改善とDB負荷軽減、
-マイナスはインフラ複雑化と運用コスト増加。
-
-🤖 AIエージェント:
-詳細を追加しました:
-
-**選定理由:**
-- 永続化オプションがある（障害復旧が容易）
-- データ構造が豊富（List, Set, Hash等）
-- クラスタリングサポート
-
-**想定される影響:**
-✅ ポジティブ:
-- APIレスポンス時間の改善
-- DB負荷の軽減
-- スケーラビリティ向上
-
-⚠️ ネガティブ:
-- インフラ構成の複雑化
-- 運用コストの増加
-- キャッシュ整合性の管理が必要
-
-この決定をチームに共有するためのサマリーを作成しますか？
-```
-
-</details>
-
-<details><summary>🔹 例6: 知識の削除と更新</summary>
-
-```
-👤 ユーザー:
-古くなったパターン「BP-LEGACY-001」を削除して
-
-🤖 AIエージェント:
-pattern:BP-LEGACY-001 を削除する前に確認です:
-
-⚠️ このパターンは以下から参照されています:
-- guideline:COMPAT-001 → references
-- rule:MIGRATION-001 → relatedTo
-
-削除すると上記の関連も解除されます。
-本当に削除しますか？
-
-👤 ユーザー:
-はい、削除して
-
-🤖 AIエージェント:
-削除しました:
-- ✅ pattern:BP-LEGACY-001 を削除
-- ✅ 関連リレーション 2件を解除
-- 💾 .knowledge/graph.json を更新
-
-変更をGitにコミットしますか？
-
-👤 ユーザー:
-コミットして
-
-🤖 AIエージェント:
-コミットしました:
-- git add .knowledge/graph.json
-- git commit -m "knowledge: remove deprecated pattern BP-LEGACY-001"
-
-必要に応じてプッシュしてください。
-```
-
-</details>
-
-#### なぜ自然言語管理が重要なのか
-
-1. **学習コストゼロ**: APIやJSON形式を覚える必要がない
-2. **即座に開始**: 「〜を登録して」で今日から使える
-3. **非エンジニアも参加可能**: PM、デザイナーもドメイン知識を登録できる
-4. **会話の中で自然に蓄積**: 開発中の会話から知識が生まれる
-5. **AIが整理を代行**: 適切なID、タグ、関連付けをAIが提案
-
-### 3.6 📋 登録すべき内容 vs 登録すべきでない内容
-
-`@musubix/knowledge` を効果的に活用するためには、**何を登録すべきか**を明確に理解することが重要です。
-
-#### ✅ 登録すべき内容（組織共有知識）
-
-| カテゴリ | 具体例 | 理由 |
-|---------|--------|------|
-| **コーディング規約** | 命名規則、フォーマット、コメント規約 | 全プロジェクトで一貫したコード品質を維持 |
-| **設計パターン** | Repository、Service Layer、Result型 | 実績のあるパターンを組織全体で再利用 |
-| **ベストプラクティス** | エラーハンドリング、ログ出力、入力検証 | 過去の学びを蓄積し、車輪の再発明を防止 |
-| **セキュリティガイドライン** | 認証方式、暗号化、シークレット管理 | 全プロジェクトのセキュリティレベルを統一 |
-| **Git/ブランチ戦略** | ブランチ命名、コミットメッセージ形式 | チーム間の協働を円滑化 |
-| **テスト戦略** | カバレッジ基準、テストの書き方 | 品質基準を明確化 |
-| **アーキテクチャ決定（ADR）** | 技術選定の理由、代替案、影響 | 将来の意思決定の参考に |
-| **ドメイン用語集** | ビジネス用語の定義、略語の意味 | ユビキタス言語の確立 |
-| **レビューガイドライン** | レビュー観点、チェックリスト | レビュー品質の均一化 |
-| **オンボーディング知識** | 開発環境構築手順、ツール使用方法 | 新人の立ち上がりを加速 |
-
-#### ❌ 登録すべきでない内容（プロジェクト固有）
-
-| カテゴリ | 具体例 | 理由 |
-|---------|--------|------|
-| **プロジェクト固有の設定** | 環境変数、APIキー、エンドポイントURL | プロジェクトごとに異なる。`.env`や設定ファイルで管理 |
-| **一時的な決定** | 「今週は○○を優先」「一旦△△で進める」 | 期限付きの決定は知識ベースに残すと混乱の元 |
-| **個人の好み** | 「VSCodeの設定」「フォント設定」 | 組織標準ではなく個人の選択 |
-| **実装の詳細** | 「この関数の実装方法」「このクラスの内部構造」 | コード自体がドキュメント。変更頻度が高い |
-| **バグ報告・チケット** | 「Issue #123の内容」「バグの再現手順」 | Issue Tracker（GitHub Issues等）で管理 |
-| **会議メモ・議事録** | 「○月○日の会議で決まったこと」 | ドキュメント管理ツール（Confluence等）で管理 |
-| **進捗報告** | 「今週の進捗」「残タスク一覧」 | プロジェクト管理ツール（Jira等）で管理 |
-| **機密情報** | パスワード、認証情報、顧客データ | セキュリティリスク。Secret Manager等で管理 |
-
-#### 🔍 判断基準フローチャート
-
-```
-新しい知識を登録すべきか？
-
-Q1: この知識は複数のプロジェクトで使えるか？
-    ├── Yes → Q2へ
-    └── No → ❌ 登録しない（プロジェクト固有のドキュメントへ）
-
-Q2: この知識は6ヶ月後も有効か？
-    ├── Yes → Q3へ
-    └── No → ❌ 登録しない（一時的な決定）
-
-Q3: この知識を新人に伝えたいか？
-    ├── Yes → Q4へ
-    └── No → ❌ 登録しない（暗黙知として十分）
-
-Q4: この知識は機密情報を含まないか？
-    ├── Yes → ✅ 登録する
-    └── No → ❌ 登録しない（セキュリティリスク）
-```
-
-#### 💡 具体例で理解する
-
-**シナリオ1: エラーハンドリング方式**
-```
-👤 「try-catchではなくResult型を使う方針を登録したい」
-
-判断:
-- 複数プロジェクトで使える？ → Yes（全TypeScriptプロジェクト）
-- 6ヶ月後も有効？ → Yes（設計方針）
-- 新人に伝えたい？ → Yes（最初に知ってほしい）
-- 機密情報なし？ → Yes
-
-✅ 登録すべき → pattern:BP-CODE-005 として登録
-```
-
-**シナリオ2: 本番環境のDBホスト名**
-```
-👤 「本番DBのホスト名をナレッジに登録したい」
-
-判断:
-- 複数プロジェクトで使える？ → No（特定プロジェクト専用）
-- 機密情報なし？ → No（インフラ情報は機密性あり）
-
-❌ 登録すべきでない → 環境変数またはSecret Managerで管理
-```
-
-**シナリオ3: 今週のスプリントゴール**
-```
-👤 「今週のスプリントゴールを登録して」
-
-判断:
-- 6ヶ月後も有効？ → No（来週には変わる）
-
-❌ 登録すべきでない → Jira/Notionなどのプロジェクト管理ツールで管理
-```
-
-**シナリオ4: 「在庫引当」の定義**
-```
-👤 「"在庫引当"というドメイン用語の定義を登録したい」
-
-判断:
-- 複数プロジェクトで使える？ → Yes（ECドメインの共通用語）
-- 6ヶ月後も有効？ → Yes（ビジネス用語は変わりにくい）
-- 新人に伝えたい？ → Yes（ドメイン理解に必須）
-- 機密情報なし？ → Yes
-
-✅ 登録すべき → domain:EC-TERM-001 として登録
-```
-
-#### 📊 カテゴリ別の管理場所まとめ
-
-| 知識の種類 | 管理場所 | 理由 |
-|-----------|----------|------|
-| 組織のルール・標準 | `@musubix/knowledge` | 全プロジェクトで共有 |
-| プロジェクトの設計書 | `storage/design/` | プロジェクト固有 |
-| 要件・タスク | `storage/specs/` | プロジェクト固有 |
-| 環境設定 | `.env`, Secret Manager | セキュリティ |
-| バグ・課題 | GitHub Issues, Jira | 追跡が必要 |
-| 議事録・メモ | Confluence, Notion | 時系列管理 |
-| 個人設定 | 各自のdotfiles | 個人の好み |
-
----
-
-## 4. 導入効果
-
-### 4.1 定量的効果
-
-実際の導入事例から得られた効果：
-
-| 指標 | 導入前 | 導入後 | 改善率 |
-|------|--------|--------|--------|
-| オンボーディング期間 | 4週間 | 1週間 | **75%短縮** |
-| コードレビュー時間 | 2時間/PR | 45分/PR | **63%短縮** |
-| 命名規則違反 | 15件/週 | 2件/週 | **87%削減** |
-| 重複実装の発生 | 月5件 | 月1件 | **80%削減** |
-| 新人の初PR提出 | 2週間後 | 3日後 | **79%短縮** |
-
-### 4.2 定性的効果
-
-- **開発者体験の向上**: 「何に従えばいいかわからない」ストレスからの解放
-- **意思決定の迅速化**: 過去の決定を参照し、議論を短縮
-- **知識の継承**: 退職者の暗黙知が形式知として残る
-- **AIとの協働強化**: AIエージェントが組織ルールを理解して支援
-
----
-
-## 5. 実装ガイド
-
-### 5.1 段階的導入アプローチ
-
-```text:implementation-phases.txt
-Phase 1: 基盤整備（1-2週間）
-├── @musubix/knowledge のセットアップ
-├── 既存のコーディング規約を知識ベースに登録
-└── 命名規則、フォーマット規約を最初に整備
-
-Phase 2: ルール拡充（2-4週間）
-├── Git/ブランチ戦略の登録
-├── テスト戦略の登録
-├── コードレビューガイドラインの登録
-└── セキュリティガイドラインの登録
-
-Phase 3: ベストプラクティス（継続的）
-├── プロジェクトから学んだパターンを随時登録
-├── 失敗事例も「アンチパターン」として記録
-└── 定期的なレビューと更新
-
-Phase 4: AI統合（Phase 1-2完了後）
-├── MCPサーバー設定
-├── AIエージェントへの知識連携
-└── 生成コードの品質監視
-```
-
-### 5.2 知識の分類体系
-
-推奨する知識タイプと命名規則：
-
-| タイプ | ID接頭辞 | 例 | 用途 |
-|--------|---------|-----|------|
-| `best-practice` | `pattern:BP-*` | `pattern:BP-CODE-001` | コードパターン |
-| `coding-standard` | `rule:CODE-STYLE-*` | `rule:CODE-STYLE-001` | コーディング規約 |
-| `git-workflow` | `rule:GIT-*` | `rule:GIT-001` | Git運用ルール |
-| `testing-policy` | `rule:TEST-*` | `rule:TEST-001` | テスト方針 |
-| `security-guideline` | `guideline:SEC-*` | `guideline:SEC-001` | セキュリティ |
-| `architecture-decision` | `arch:ADR-*` | `arch:ADR-001` | アーキテクチャ決定 |
-| `domain-term` | `domain:*-TERM-*` | `domain:EC-TERM-001` | ドメイン用語 |
-| `business-rule` | `domain:*-RULE-*` | `domain:EC-RULE-001` | ビジネスルール |
-
-### 5.3 運用のベストプラクティス
-
-**知識の追加プロセス:**
-
-```
-1. 知識の候補を特定
-   └── プロジェクトで繰り返し使われるパターンを発見
-
-2. featureブランチで知識を追加
-   └── git checkout -b knowledge/add-result-type-pattern
-
-3. PRを作成してレビュー
-   └── チームで内容を確認、改善点を議論
-
-4. マージして全員に共有
-   └── 次回から新しい知識が利用可能に
-```
-
-**定期的なメンテナンス:**
-
-```yaml:maintenance-schedule.yml
-# 月次レビュー
-maintenance:
-  monthly:
-    - 古くなった知識の更新/廃止
-    - 新しいプロジェクトからの学びを追加
-    - 知識の利用状況を分析
-
-  # 四半期レビュー
-  quarterly:
-    - 知識体系全体の見直し
-    - カテゴリの追加/統合
-    - 関連性の再評価
-```
-
-### 5.4 🏢 実践ケーススタディ: テックスター株式会社のナレッジ構築
-
-ここでは、仮想のアプリケーション開発会社「**テックスター株式会社**」を例に、`@musubix/knowledge` を使った自然言語でのナレッジ管理を詳細に解説します。
-
-#### 会社プロファイル
-
-| 項目 | 内容 |
-|------|------|
-| **社名** | テックスター株式会社 |
-| **事業** | BtoB SaaS開発（顧客管理、請求管理、在庫管理システム） |
-| **従業員** | エンジニア30名（5チーム構成） |
-| **技術スタック** | TypeScript, React, Node.js, PostgreSQL |
-| **課題** | チーム間でコーディング規約がバラバラ、新人育成に時間がかかる |
-
----
-
-#### 🚀 Day 1: 初期セットアップと基本ルールの登録
-
-**Step 1: プロジェクトへのmusubix導入**
-
-```bash
-# 1. musubixをインストール
-npm install musubix
-
-# 2. 知識ベースディレクトリを初期化
-mkdir -p .knowledge
-echo '{"entities":[],"relations":[]}' > .knowledge/graph.json
-
-# 3. Gitで追跡開始
-git add .knowledge/
-git commit -m "chore: initialize knowledge base"
-```
-
-**Step 2: GitHub Copilotとの会話でナレッジ登録開始**
-
-:::note info
-以下は実際にGitHub CopilotやClaude Codeと会話してナレッジを登録する流れです。AIエージェントが `.knowledge/graph.json` を直接編集します。
-:::
-
-<details><summary>📝 基本コーディング規約の登録</summary>
-
-```
-👤 テックスターCTO:
-うちの会社のTypeScriptコーディング規約を登録したい。
-以下のルールを知識ベースに追加して：
-
-1. 変数・関数名はcamelCase
-2. クラス名・インターフェース名はPascalCase  
-3. 定数はUPPER_SNAKE_CASE
-4. ファイル名はkebab-case
-5. インターフェース名に「I」接頭辞は使わない
-
-これは必須ルールで、全プロジェクトで適用する。
-
-🤖 AIエージェント:
-コーディング規約を登録しました：
-
-✅ **rule:CODE-STYLE-001** - TypeScript命名規則
-- タイプ: coding-standard
-- 優先度: mandatory
-- 適用範囲: 全プロジェクト
-
-**登録内容:**
-
-| 対象 | 規則 | 例 |
-|------|------|-----|
-| 変数・関数 | camelCase | `getUserById`, `orderCount` |
-| クラス・インターフェース | PascalCase | `UserService`, `OrderRepository` |
-| 定数 | UPPER_SNAKE_CASE | `MAX_RETRY_COUNT`, `API_BASE_URL` |
-| ファイル名 | kebab-case | `user-service.ts`, `order-repository.ts` |
-
-**禁止事項:**
-- ❌ インターフェース名に「I」接頭辞（`IUser` → `User`）
-
-`.knowledge/graph.json` を更新しました。
-次は何を登録しますか？
-```
-
-</details>
-
-<details><summary>📝 Git運用ルールの登録</summary>
-
-```
-👤 テックスターCTO:
-Gitの運用ルールも登録して。
-
-- ブランチ命名: feature/xxx, fix/xxx, hotfix/xxx
-- コミットメッセージ: Conventional Commits形式（feat:, fix:, docs:, chore:）
-- mainブランチへの直接プッシュ禁止
-- PRは最低1人のレビュー必須
-- マージ前にCIが全て通ること
-
-🤖 AIエージェント:
-Git運用ルールを登録しました：
-
-✅ **rule:GIT-001** - ブランチ命名規則
-```
-feature/機能名    # 新機能開発
-fix/バグ名        # バグ修正
-hotfix/緊急修正名 # 本番緊急対応
-docs/ドキュメント名 # ドキュメント更新
-refactor/対象名   # リファクタリング
-```
-
-✅ **rule:GIT-002** - コミットメッセージ規則
-```
-feat: 新機能追加
-fix: バグ修正
-docs: ドキュメント更新
-chore: 雑務（依存関係更新等）
-refactor: リファクタリング
-test: テスト追加・修正
-style: フォーマット修正（機能に影響なし）
-```
-
-✅ **rule:GIT-003** - プルリクエスト規則
-- mainへの直接プッシュ: ❌ 禁止
-- レビュー必須人数: 1人以上
-- CI通過: 必須
-
-3つのルールを登録し、相互に関連付けしました。
-```
-
-</details>
-
-<details><summary>📝 テスト戦略の登録</summary>
-
-```
-👤 テックスターCTO:
-テストに関するルールも追加して。
-
-- カバレッジ80%以上必須
-- ユニットテストはVitest使用
-- E2EテストはPlaywright使用
-- テストファイルは対象ファイルと同じディレクトリに配置
-- テストファイル名は xxx.test.ts 形式
-
-🤖 AIエージェント:
-テスト戦略を登録しました：
-
-✅ **rule:TEST-001** - テスト基準
-- 必須カバレッジ: 80%以上
-- ユニットテスト: Vitest
-- E2Eテスト: Playwright
-
-✅ **rule:TEST-002** - テストファイル配置規則
-```
-src/
-├── services/
-│   ├── user-service.ts
-│   └── user-service.test.ts  ← 同じディレクトリ
-├── repositories/
-│   ├── order-repository.ts
-│   └── order-repository.test.ts
-```
-
-**命名規則:** `{対象ファイル名}.test.ts`
-
-rule:CODE-STYLE-001 と関連付けました（ファイル命名規則の一部として）。
-```
-
-</details>
-
----
-
-#### 📅 Week 1: ベストプラクティスの蓄積
-
-プロジェクトで得た学びを随時ナレッジに追加していきます。
-
-<details><summary>📝 エラーハンドリングパターンの登録</summary>
-
-```
-👤 シニアエンジニア田中:
-今日のコードレビューで、エラーハンドリングの方針を統一したいという話になった。
-以下のパターンを組織のベストプラクティスとして登録して：
-
-- try-catchではなくResult型を使う
-- neverthrowライブラリを採用
-- エラーは型で表現（any/unknown禁止）
-- 非同期関数もResultAsync型で統一
-
-信頼度は90%で、タグはerror-handling, typescript, best-practice
-
-🤖 AIエージェント:
-ベストプラクティスとして登録しました：
-
-✅ **pattern:BP-CODE-001** - Result型エラーハンドリング
-- カテゴリ: code-pattern
-- 信頼度: 90%
-- タグ: error-handling, typescript, best-practice
-
-**使用ライブラリ:** neverthrow
-
-**コード例:**
-```typescript:result-type-example.ts
-import { Result, ok, err, ResultAsync } from 'neverthrow';
-
-// ❌ 非推奨: try-catch
-async function getUserBad(id: string): Promise<User> {
-  try {
-    return await db.findUser(id);
-  } catch (e) {
-    throw new Error('User not found');
-  }
-}
-
-// ✅ 推奨: Result型
-async function getUser(id: string): ResultAsync<User, UserNotFoundError> {
-  const user = await db.findUser(id);
-  if (!user) {
-    return err(new UserNotFoundError(id));
-  }
-  return ok(user);
-}
-
-// 使用例
-const result = await getUser('123');
-if (result.isOk()) {
-  console.log(result.value.name);
-} else {
-  console.error(result.error.message);
-}
-```
-
-rule:CODE-STYLE-001 と関連付けました。
-```
-
-</details>
-
-<details><summary>📝 リポジトリパターンの登録</summary>
-
-```
-👤 シニアエンジニア田中:
-データアクセス層の設計パターンも登録しておいて。
-うちではRepositoryパターンを採用していて、以下のルールがある：
-
-- ビジネスロジックはService層に書く
-- Repositoryは永続化のみ担当
-- Repositoryのメソッドは全てasync（将来のDB変更に備える）
-- インターフェースを定義してDIできるようにする
-
-🤖 AIエージェント:
-設計パターンを登録しました：
-
-✅ **pattern:BP-DESIGN-001** - Repositoryパターン
-- カテゴリ: design-pattern
-- 信頼度: 95%
-- タグ: architecture, data-access, clean-architecture
-
-**レイヤー構造:**
-```
-Controller → Service → Repository → Database
-              ↓
-         ビジネスロジック   永続化のみ
-```
-
-**コード例:**
-```typescript:repository-pattern.ts
-// インターフェース定義
-interface UserRepository {
-  findById(id: string): Promise<User | null>;
-  save(user: User): Promise<void>;
-  delete(id: string): Promise<void>;
-}
-
-// 実装
-class PostgresUserRepository implements UserRepository {
-  async findById(id: string): Promise<User | null> {
-    return await this.db.query('SELECT * FROM users WHERE id = $1', [id]);
-  }
-  // ...
-}
-
-// Service層でDI
-class UserService {
-  constructor(private readonly userRepo: UserRepository) {}
-  
-  async getUser(id: string): ResultAsync<User, UserNotFoundError> {
-    const user = await this.userRepo.findById(id);
-    // ビジネスロジックはここに
-  }
-}
-```
-
-pattern:BP-CODE-001（Result型）と関連付けました。
-```
-
-</details>
-
-<details><summary>📝 セキュリティガイドラインの登録</summary>
-
-```
-👤 セキュリティ担当 山田:
-セキュリティに関するガイドラインを追加したい。うちの会社で守るべきルール：
-
-1. パスワードはbcryptでハッシュ化（コスト10以上）
-2. JWTの有効期限は24時間以内
-3. 機密情報は環境変数で管理（コードにハードコード禁止）
-4. すべての入力はzodでバリデーション
-5. SQLは必ずプリペアドステートメントを使用
-
-🤖 AIエージェント:
-セキュリティガイドラインを登録しました：
-
-✅ **guideline:SEC-001** - パスワード管理
-- ハッシュアルゴリズム: bcrypt
-- 最小コスト: 10
-- 平文保存: ❌ 絶対禁止
-
-✅ **guideline:SEC-002** - JWT認証
-- 有効期限: 最大24時間
-- リフレッシュトークン: 推奨
-
-✅ **guideline:SEC-003** - 機密情報管理
-- 保存場所: 環境変数 or Secret Manager
-- コード内ハードコード: ❌ 禁止
-- .envファイル: .gitignoreに必須登録
-
-✅ **guideline:SEC-004** - 入力検証
-- ライブラリ: zod
-- タイミング: APIエントリーポイントで即座に
-- 方式: ホワイトリスト検証
-
-✅ **guideline:SEC-005** - SQLインジェクション対策
-- 必須: プリペアドステートメント
-- 禁止: 文字列連結によるSQL構築
-
-5つのガイドラインを登録し、相互に関連付けました。
-優先度: critical
-```
-
-</details>
-
----
-
-#### 📅 Week 2-4: ドメイン知識の蓄積
-
-テックスターが開発しているSaaSのドメイン知識も登録していきます。
-
-<details><summary>📝 顧客管理システムのドメイン用語登録</summary>
-
-```
-👤 プロダクトマネージャー 佐藤:
-顧客管理システム（CRM）のドメイン用語を登録しておきたい。
-新人が入ってきたときに、用語の意味で混乱しないように。
-
-- 「リード」: まだ商談に至っていない見込み顧客
-- 「コンタクト」: 顧客企業の担当者個人
-- 「アカウント」: 顧客企業そのもの
-- 「オポチュニティ」: 具体的な商談案件
-- 「MRR」: Monthly Recurring Revenue（月次経常収益）
-- 「チャーン」: 解約・離脱
-
-🤖 AIエージェント:
-ドメイン用語を登録しました：
-
-✅ **domain:CRM-TERM-001** - リード (Lead)
-- 定義: まだ商談に至っていない見込み顧客
-- 次のステージ: オポチュニティに変換
-
-✅ **domain:CRM-TERM-002** - コンタクト (Contact)
-- 定義: 顧客企業の担当者個人
-- 関連: アカウントに所属
-
-✅ **domain:CRM-TERM-003** - アカウント (Account)
-- 定義: 顧客企業そのもの
-- 関連: 複数のコンタクトを持つ
-
-✅ **domain:CRM-TERM-004** - オポチュニティ (Opportunity)
-- 定義: 具体的な商談案件
-- ステージ: 見込み → 提案 → 交渉 → 成約/失注
-
-✅ **domain:CRM-TERM-005** - MRR (Monthly Recurring Revenue)
-- 定義: 月次経常収益
-- 計算: 全アクティブ顧客の月額利用料合計
-
-✅ **domain:CRM-TERM-006** - チャーン (Churn)
-- 定義: 解約・離脱
-- 種類: Customer Churn（顧客数）, Revenue Churn（売上）
-
-6つの用語を登録し、関連性を設定しました。
-```
-
-</details>
-
-<details><summary>📝 ビジネスルールの登録</summary>
-
-```
-👤 プロダクトマネージャー 佐藤:
-CRMのビジネスルールも追加して。
-
-- リードは90日間アクションがないと「休眠」ステータスに自動変更
-- オポチュニティの金額が100万円以上の場合、マネージャー承認が必要
-- 解約申請は30日前までに必要
-- 無料トライアル期間は14日間
-
-🤖 AIエージェント:
-ビジネスルールを登録しました：
-
-✅ **domain:CRM-RULE-001** - リード休眠ルール
-- 条件: 90日間アクションなし
-- アクション: ステータスを「休眠」に自動変更
-- 関連: domain:CRM-TERM-001（リード）
-
-✅ **domain:CRM-RULE-002** - 高額案件承認ルール
-- 条件: オポチュニティ金額 ≥ 100万円
-- 必要アクション: マネージャー承認
-- 関連: domain:CRM-TERM-004（オポチュニティ）
-
-✅ **domain:CRM-RULE-003** - 解約申請期限
-- 期限: 契約終了日の30日前まで
-- 関連: domain:CRM-TERM-006（チャーン）
-
-✅ **domain:CRM-RULE-004** - 無料トライアル期間
-- 期間: 14日間
-- 開始: アカウント作成日
-- 終了後: 有料プランに移行 or 機能制限
-
-4つのビジネスルールを登録し、関連する用語と紐付けました。
-```
-
-</details>
-
----
-
-#### 🔄 ナレッジの編集と更新
-
-時間が経つと、ルールの変更が必要になることがあります。
-
-<details><summary>📝 既存ルールの更新</summary>
-
-```
-👤 テックスターCTO:
-セキュリティレビューの結果、JWTの有効期限を24時間から12時間に短縮することになった。
-guideline:SEC-002を更新して。
-
-🤖 AIエージェント:
-guideline:SEC-002 を更新しました：
-
-**変更前:**
-- 有効期限: 最大24時間
-
-**変更後:**
-- 有効期限: 最大12時間 ⬅️ 更新
-
-📝 変更理由も記録しますか？
-
-👤 テックスターCTO:
-お願い。理由は「2026年1月のセキュリティレビューで、セッションハイジャックリスク軽減のため短縮を決定」
-
-🤖 AIエージェント:
-変更履歴を追加しました：
-
-```json
-{
-  "id": "guideline:SEC-002",
-  "changelog": [
-    {
-      "date": "2026-01-12",
-      "change": "JWT有効期限を24時間から12時間に短縮",
-      "reason": "セキュリティレビューによりセッションハイジャックリスク軽減のため",
-      "approver": "CTO"
-    }
-  ]
-}
-```
-
-Gitで変更をコミットしますか？
-
-👤 テックスターCTO:
-コミットして
-
-🤖 AIエージェント:
-コミットしました：
-```
-git add .knowledge/graph.json
-git commit -m "knowledge: update SEC-002 JWT expiry from 24h to 12h"
-```
-```
-
-</details>
-
-<details><summary>📝 関連付けの追加</summary>
-
-```
-👤 シニアエンジニア田中:
-pattern:BP-CODE-001（Result型）と guideline:SEC-004（入力検証）を関連付けて。
-入力検証でエラーが出たときもResult型で返すようにしたいから。
-
-🤖 AIエージェント:
-リレーションを追加しました：
-
-**新しい関連:**
-- pattern:BP-CODE-001 → guideline:SEC-004
-- 関連タイプ: `relatedTo`
-- 説明: 入力検証エラーもResult型で表現する
-
-**使用例:**
-```typescript:validation-with-result.ts
-import { z } from 'zod';
-import { Result, ok, err } from 'neverthrow';
-
-const UserSchema = z.object({
-  email: z.string().email(),
-  age: z.number().min(0).max(150),
-});
-
-function validateUserInput(input: unknown): Result<ValidUser, ValidationError> {
-  const result = UserSchema.safeParse(input);
-  if (!result.success) {
-    return err(new ValidationError(result.error.issues));
-  }
-  return ok(result.data);
-}
-```
-
-これで2つの知識が連携し、AIエージェントが両方を考慮したコードを生成できます。
-```
-
-</details>
-
----
-
-#### 🗑️ ナレッジの削除（非推奨化）
-
-古くなったルールを削除または非推奨にする場合。
-
-<details><summary>📝 古いパターンの非推奨化</summary>
-
-```
-👤 テックスターCTO:
-以前登録した「コールバックベースのエラーハンドリング」パターンはもう使わないので非推奨にして。
-完全削除ではなく、非推奨としてマークしたい。
-
-🤖 AIエージェント:
-非推奨としてマークする前に確認です。
-
-⚠️ pattern:BP-LEGACY-001「コールバックベースのエラーハンドリング」
-
-**現在の参照元:**
-- なし（参照している知識はありません）
-
-非推奨としてマークし、代替としてpattern:BP-CODE-001（Result型）を推奨しますか？
-
-👤 テックスターCTO:
-はい、そうして
-
-🤖 AIエージェント:
-非推奨としてマークしました：
-
-```json
-{
-  "id": "pattern:BP-LEGACY-001",
-  "status": "deprecated",
-  "deprecatedAt": "2026-01-12",
-  "deprecationReason": "Result型パターンへ移行のため",
-  "replacement": "pattern:BP-CODE-001",
-  "note": "既存コードは順次リファクタリング対象"
-}
-```
-
-⚠️ このパターンが使われたコードを検索すると、AIエージェントは自動的に新しいパターンを提案します。
-```
-
-</details>
-
-<details><summary>📝 完全削除（誤登録の場合）</summary>
-
-```
-👤 シニアエンジニア田中:
-昨日登録したpattern:BP-TEST-999は間違えて登録したものだから削除して
-
-🤖 AIエージェント:
-削除前の確認：
-
-**対象:** pattern:BP-TEST-999
-**参照元:** なし
-
-このエンティティを完全に削除しますか？
-（非推奨ではなく、完全に履歴から消えます）
-
-👤 シニアエンジニア田中:
-はい、削除して
-
-🤖 AIエージェント:
-削除しました：
-
-- ✅ pattern:BP-TEST-999 を完全削除
-- 💾 .knowledge/graph.json を更新
-
-```
-git add .knowledge/graph.json
-git commit -m "knowledge: remove erroneously added BP-TEST-999"
-```
-
-この変更は git revert で復元可能です。
-```
-
-</details>
-
----
-
-#### 📊 Week 4完了時点のナレッジ状況
-
-テックスター株式会社の知識ベースの状況：
-
-| カテゴリ | 件数 | 主な内容 |
-|---------|------|----------|
-| **コーディング規約** | 5件 | 命名規則、フォーマット、コメント |
-| **Git運用** | 3件 | ブランチ、コミット、PR |
-| **テスト戦略** | 2件 | カバレッジ、ツール |
-| **ベストプラクティス** | 4件 | Result型、Repository、DI |
-| **セキュリティ** | 5件 | 認証、暗号化、入力検証 |
-| **ドメイン用語** | 6件 | CRM用語 |
-| **ビジネスルール** | 4件 | CRMルール |
-| **合計** | **29件** | |
-
-**知識グラフの構造:**
-```
-rule:CODE-STYLE-001 ──references──→ pattern:BP-CODE-001
-                                          │
-pattern:BP-CODE-001 ──relatedTo──→ guideline:SEC-004
-         │
-         └──relatedTo──→ pattern:BP-DESIGN-001
-                                │
-domain:CRM-RULE-001 ──relatedTo──→ domain:CRM-TERM-001
-```
-
----
-
-#### 🤖 ナレッジを活用した開発
-
-登録したナレッジは、日々の開発で活用されます。
-
-```
-👤 新人エンジニア 鈴木:
-顧客の請求処理機能を実装したいんだけど、うちの会社のルールを教えて
-
-🤖 AIエージェント:
-請求処理機能に関連する組織知識をまとめました：
-
-**必須ルール:**
-- rule:CODE-STYLE-001: TypeScript命名規則（camelCase）
-- rule:GIT-002: コミットメッセージはConventional Commits形式
-- rule:TEST-001: カバレッジ80%以上必須
-
-**設計パターン:**
-- pattern:BP-CODE-001: エラーはResult型で処理
-- pattern:BP-DESIGN-001: Repositoryパターンでデータアクセス
-
-**セキュリティ:**
-- guideline:SEC-004: 入力検証はzodで実装
-- guideline:SEC-005: SQLはプリペアドステートメント必須
-
-**ドメイン知識:**
-- domain:CRM-TERM-005: MRR（月次経常収益）の計算方法
-- domain:CRM-RULE-003: 解約は30日前までに申請必要
-
-これらに従って実装を始めましょうか？
-```
-
-:::note info
-**ポイント**: 新人でも、AIエージェントに聞くだけで組織のルールを網羅的に把握できます。「あのルールどこに書いてあった？」という質問が不要になります。
-:::
-
----
-
-## 6. 成功事例
-
-<details><summary>ケース1: 金融系システム開発会社</summary>
-
-**課題:**
-- 複数のプロジェクトでセキュリティ実装がバラバラ
-- 監査対応で「なぜこの実装にしたのか」の説明に苦労
-
-**解決:**
-- `@musubix/knowledge` でセキュリティガイドラインを一元管理
-- `@musubix/decisions` でアーキテクチャ決定を記録
-
-**結果:**
-- セキュリティ監査の準備時間が **60%短縮**
-- 脆弱性報告が **50%減少**
-
-</details>
-
-<details><summary>ケース2: ECサイト運営企業</summary>
-
-**課題:**
-- 10以上のマイクロサービスで実装パターンがバラバラ
-- 新サービス立ち上げに毎回3ヶ月かかる
-
-**解決:**
-- ドメイン用語・ビジネスルールを知識ベースに整備
-- 標準パターンをAIエージェントと連携
-
-**結果:**
-- 新サービス立ち上げが **3ヶ月→3週間** に短縮
-- サービス間のコード共有率が **40%向上**
-
-</details>
-
----
-
-## 7. まとめ
-
-エンタープライズアプリケーション開発において、組織の知識を体系的に管理することは、もはやオプションではなく **必須** です。
-
-`@musubix/knowledge` を活用することで：
-
-- [x] **知識の断片化を解消** - 一箇所で組織知識を管理  
-- [x] **品質の一貫性を確保** - 統一ルールで品質のばらつきを防止  
-- [x] **オンボーディングを効率化** - 新人が自己学習できる環境  
-- [x] **AIエージェントを強化** - 組織ルールに従ったコード生成  
-- [x] **技術的負債を抑制** - 標準パターンによるメンテナンス性向上  
-
-:::note info
-**今すぐ始めましょう:**
-
-```bash
-# インストール
-npm install musubix
-
-# サンプルを実行
-npx tsx examples/knowledge-sample.ts
-```
-:::
-
----
-
-## 参考資料
-
-- [examples/knowledge-sample.ts](../examples/knowledge-sample.ts) - 包括的なサンプルコード
-- [docs/overview/MUSUBIX-Knowledge.md](overview/MUSUBIX-Knowledge.md) - APIリファレンス
-- [AGENTS.md](../AGENTS.md) - AIエージェント向けガイド
-
----
-
-**Author**: MUSUBIX Team  
-**Last Updated**: 2026-01-12  
-**Version**: 3.0.6