知識グラフ一括生成器
📌 バージョン履歴
| バージョン | 日付 | 変更内容 |
|---|---|---|
| 2.2.0 | 2026-09-02 | 大規模プロジェクト全量アップグレードの実戦知見を反映: ① スケルトンカードのアップグレード戦略——ユーザーから「未記入が多すぎる/ルールが単純」というフィードバックがあった場合に全量アップグレードをトリガーし、分野ごとに並行してサブエージェントを実行 + メインエージェントが成果を監視（grep で残りの未記入数を確認）；エージェントが停滞したら即座に引き継いで補完。② mermaid ノードのラベル内で括弧のネストを禁止（レンダリング失敗の最大の原因）と、一括正規表現修正スクリプト。③ サブエージェントのモジュール間相対パスが間違いやすい（../.. の階層ミス）ため、最終確認では必ず双向リンク検証を実行。④ アップグレード後の統計の書き戻しと README の更新。 |
| 2.1.0 | 2026-09-01 | Obsidian wiki リンクのパス仕様を修正（重要）: Obsidian の [[...]] wiki リンクは ../ 相対パスをサポートしない（../ はノート名として扱われクリック不可になるため）。すべてを知識ベースルートからの絶対パス（`[[領域/モジュール/機能.md |
| 2.0.0 | 2026-08-24 | Obsidian 双向リンクの互換性を修正: 第 5 バッチの品質チェックに「ドット構文なし + リンクごとの相対パス解決検証」を追加。生成されたナレッジベースが Obsidian で正常にジャンプ可能に。 |
| 1.0.0 | 初回バージョン | 5 バッチ一括生成戦略（L1+L2 スケルトン → L3 モジュールインデックス → コア機能カード → 残りの機能スケルトン → 全体品質チェック）の基本機能。 |
概要
大規模プロジェクト向けの知識工学。プロジェクトに完全なコード/ドキュメントがあり、機能ノードが 50 を超え、数百のノードからなる完全な知識ベースを一度に生成する必要がある場合に、バッチ戦略に従って効率的に生成し、1 回の出力過負荷を回避します。すべてのファイル内容は business-knowledge-graph-generator スキルで定義されたテンプレート仕様（references/templates.md）に従う必要があります。
いつ使うか
- 機能数が 50 を超える大規模プロジェクト
- プロジェクトの完全なコードディレクトリ構造 + コアコードファイルの内容がすでにある場合（分割して提供可能）
- 数百のノードからなる完全な知識ベースを一度に生成する必要がある場合
入力要件: プロジェクトの完全なコードディレクトリ構造 + コアコードファイルの内容を提供してください（分割して提供可能）。
バッチ処理戦略
機能数が 50 を超える場合は、以下の順序で 5 バッチに分けて処理します。
第 1 バッチ: L1 + L2 スケルトン（全体構造）—— 想定出力ファイル数 6～20
knowledge/_index.md（L1 全体図）を生成- 各分野に
<分野>/_index.md（L2 分野図）を生成 - 品質チェック: すべての分野とモジュールがカバーされていて、抜け漏れがないことを確認
第 2 バッチ: L3 モジュールインデックス（機能一覧）—— 想定出力ファイル数 20～50
- 各モジュールに
<分野>/<モジュール>/_index.md（L3 モジュール図）を生成 - 品質チェック: 各モジュールの機能一覧が完全で、すべての機能が命名されていることを確認
第 3 バッチ: 高優先度機能カード（コアフロー）—— 想定出力ファイル数 20～30
- システムのコア機能を特定（ユーザーが最もよく使う 20% の機能。例：ログイン、注文、支払い）
- これらの機能に対して完全な L4 カードを生成（フロー、ルール、イベント、依存関係、コード位置を含む）
- 品質チェック: コアフローに異常系の分岐が含まれ、コード位置が行番号まで正確であること
第 4 バッチ: 残りの機能スケルトンカード —— 想定出力ファイル数 50～200+
- 残りの機能に対して最小限のカードを生成（最低限、Frontmatter + 機能説明 + 基本ルールを含む）
状態: 未記入とマークし、後で手動で補完できるようにする- 品質チェック: すべての機能に対応する
.mdファイルが存在し、機能の抜け漏れがないこと
第 5 バッチ: 全体品質チェックとインデックス更新
- すべての双向リンクが Obsidian 互換の相対パス（
[[../モジュール/機能.md|エイリアス]]）であり、[[分野.モジュール.機能]]のようなドット構文がないことを検証 - 各リンクを現在のファイルからの相対パスで解決し、ターゲット
.mdファイルが存在することを確認 - すべての未リンク（浮遊リンク）をマークし、修正リストを生成
- 各階層の
_index.md内の統計数値（モジュール数、機能数）を更新 knowledge/README.mdの使用手順を生成
優先度判定ルール
| 優先度 | 判定基準 | 機能例 |
|---|---|---|
| コア | ユーザーの日常利用 > 80% のシナリオ、資金安全関連 | ログイン、注文、支払い、返金 |
| 重要 | ユーザーの日常利用 30%～80% のシナリオ、データ管理関連 | 注文照会、配送追跡、情報変更 |
| 一般 | 管理バックエンド機能、低頻度操作、設定関連 | 商品カテゴリ管理、ログ照会、レポート生成 |
出力要件
- バッチごとに出力し、各バッチ完了後に進捗を報告し、ユーザーの確認を得てから次のバッチに進む
- 各バッチの出力時に、今回生成されたファイルの一覧をリストアップする
- 第 3 バッチ（コア機能）の生成が完了したら一時停止し、ユーザーが次のバッチの重点分野を指定するのを待つ
- すべてのファイル内容は
business-knowledge-graph-generatorのreferences/templates.mdで定義されたテンプレート仕様に従う必要がある
バッチ報告フォーマット
## 第 X バッチ完了 ✅
**生成ファイル数**: XX 個
**関連分野**: 分野A、分野B
**ファイル一覧**:
- knowledge/分野A/_index.md
- knowledge/分野A/モジュールA/_index.md
- ...
**次回バッチ計画**: XXX 分野のコア機能カードを生成
続行してよろしいですか？
注意事項
- 分割納品: プロジェクトに 100 を超える機能がある場合は、最初に L1 と L2 のスケルトンを完了し、その後徐々に L3 に掘り下げ、最後に L4 を一括生成します
- コード読み取り制限: コードファイルが多すぎる場合は、ユーザーにコアモジュールの主要なファイルを 5～10 個提供してもらい、それ以外はディレクトリ構造の説明のみで問題ありません
- 手動補完: スキルは内容の 80%（構造、フロー、ルールフレームワーク）を生成しますが、具体的な過去のヒヤリハット記録や担当者情報は、ユーザーが手動で補完する必要があることを促します
実戦知見（2026-09-01 jetlinks プロジェクトからの知見）
- Obsidian リンクはナレッジベースルートからのパス +
.md拡張子なし（最重要）: Obsidian の wiki リンクは../相対パスをサポートしません（../はノート名として扱われます）。また.md拡張子もサポートしません（[[Note.md]]は「Note.md」という名前のノートとして扱われ、「Note」とは認識されずクリック不可になります）。すべてのリンクは[[領域/モジュール/機能|エイリアス]]（knowledge/ ルートからのパス、.md は付けない）と統一して記述し、mermaid 図ではプレーンテキストノード（A[機能] --> B[機能]）を使用し、[[...]]構文は禁止します。 - サブエージェントの 429 レート制限ダウングレード: 大規模な探索/生成時にサブエージェントがレート制限（429）をトリガーする可能性があります。その場合は、メインセッションが直接生成するようにダウングレードします。まず Glob/Grep ですべての Controller の
@RequestMappingと HTTP メソッドアノテーションを特定（行番号まで正確に特定可能）し、その後ファイルごとに書き込みます。 - 品質チェックスクリプトはコードブロックをスキップすること: L4 カード内の「リンク仕様」の例は、よくバッククォートのコードブロックに記述されます。品質チェックの正規表現は、まず
`...`とmermaidブロックの内容を取り除いてから処理しないと、例が浮遊リンクとして誤検出されます。 - 機能数書き戻しメカニズム: L2 インデックス内のモジュール機能数は予測値であり、L3 生成後に実際の値に基づいて、第 5 バッチでスクリプトを使用して L2 統計列と L1 規模統計を自動的に書き戻します。
- 一括生成にはスクリプトを使用: 第 4 バッチのスケルトンカード（100+ ファイル）は、Python スクリプトを使用して L3 インデックステーブルから正規表現で機能名/タイプ/説明を抽出し、一括書き込みします。これにより命名とリンクの一貫性が保証され、ファイルごとに手動で記述するよりも効率的でエラーが少なくなります。
実戦知見（2026-09-02 大規模プロジェクト全量アップグレードからの知見）
- スケルトンカードのアップグレードは全量トリガー、指名待ち不要: ユーザーから「未記入/ルールが単純」と不満が出た場合は、全量アップグレードをトリガーし、分野ごとにバッチで、すべてのスケルトンカードを完全なカードの詳細度（business skill の「L4 カード詳細度基準」を参照）にアップグレードします。
- 並行サブエージェントを分野ごとに割り当て + メインエージェントが監視: 各分野に 1 つのサブエージェントを割り当て（プロンプトにはテンプレート例、mermaid の鉄則、コード調査要件を内蔵）、メインエージェントは
grep -rl "状態: 未記入" <分野> | wc -lで残量を定期的にチェックし、エージェントが停滞した場合（一定時間新しいファイルを生成しない場合）は直接引き継いで補完し、待ち時間を発生させません。 - mermaid ノードのラベル内で括弧のネストを禁止（レンダリング失敗の最大の原因）: flowchart ノード
[..]/{..}内に()が現れると（例:A[Foo(x)]）、「Expecting SQE, DOUBLECIRCLEEND...」という解析エラーが発生します。関数シグネチャのパラメータは削除するか、スペースで区切ります。一括修正: 正規表現で mermaid ブロックのみをスキャンし、[label(args)]を[label args]に置換します（括弧を削除、カンマをスペースに変更）。 - サブエージェントのモジュール間相対パスは間違いやすい: サブエージェントがモジュール間リンクを記述する際に
../..の階層を誤るのは高頻度のミスです（例:取引管理/取引ログ/から市況データ/自選株管理/へのリンクは../../市況データ/自選株管理/_index.mdとすべきところを../自選株管理/としてしまう）。最終確認では必ず双向リンク検証スクリプトを実行し、リンク切れのリストを特定して 1 つずつ修正します。 - 最終確認は 3 つを 1 つに: アップグレード完了後、① 双向リンク完全性スクリプト（すべての md ファイルを走査して
[[...]]相対パスを解決し、ターゲットの存在を検証）② mermaid 括弧スキャン ③ 未記入残数カウント（grep -rl "状態: 未記入" | wc -lは 0 であること）を実行。README の統計を更新してから納品します。
スケルトンカード一括アップグレード操作ガイド
knowledge/ に多数のスケルトンカードがすでに存在し、アップグレードが必要な場合:
1. 残数を統計: grep -rl "状態: 未記入" knowledge/*/ | wc -l （分野ごとに詳細化）
2. 分野ごとに並行してサブエージェントを実行（各プロンプトには以下を含める: テンプレート例の絶対パス、mermaid の鉄則、
コード調査要件「少なくとも 1～2 つの実際の関数名と行番号、見つからない場合は未特定とマークして捏造しない」、出力レポート形式）
3. メインエージェントが定期的にチェック: find で最新の mtime ファイル / grep で残りの未記入数を確認。停滞した場合は引き継ぎ
4. 最終確認: 双向リンク検証スクリプト + mermaid 括弧スキャン + 未記入カウントをゼロに
5. README の統計と各層の _index 統計数値を更新
リソース
business-knowledge-graph-generator/references/templates.md: L1～L4 テンプレート仕様（必ず従うこと）