課題：散在するドキュメントと「暗黙知の退職リスク」
IT企業では以下のような状況がよく見られます。
- 障害報告書がPowerPoint、設計書がExcel、手順書がConfluence、ログはKibana——バラバラに存在
- 「このサービスが止まると何に影響するか」が、特定のエンジニアの頭の中にしかない
- 新人が「過去に似た障害はありましたか？」と聞いても、ベテランのSlack検索頼み
- 生成AI（ChatGPT等）に相談しようにも、「社内システム構成」の情報を与えられない
この状態が LV1（生データ） です。ドキュメントは存在しますが、AIが構造的に理解できる形になっていません。
GraphDBを使う理由：「関係性」こそがナレッジの本質
ITシステムのナレッジには「関係性」が重要です。
WebサーバーA→DBサーバーBに依存しているマイクロサービスX→マイクロサービスY→バッチZの順で処理が流れる
こうした「AはBに依存する」「CはDをトリガーする」という関係性は、RDB（テーブル形式）よりもグラフDB（Neo4j等） が得意とする領域です。
JDMC講演Q&Aでいただいた質問への回答
「GraphDBの構築にはどんなスキルが必要ですか？」
ITリテラシー高めのエンジニア2名体制で開始できます。グラフDBは「スキーマレス」に見えますが、事前のスキーマ設計（ノードの種類・リレーションの種類の定義）が品質を左右します。「とりあえず入れてから考える」ではなく、「システム構成の概念モデルを先に描く」ことを強く推奨します。
AI-Readyレベル診断
| データ種別 | 現状レベル | 問題点 | |---|---|---| | システム設計書 | LV1（PowerPoint） | AIが読めない形式 | | 障害報告書 | LV1（Excel・Confluence混在） | 検索はできるが構造化されていない | | インシデント対応履歴 | LV1（Slack・メール） | 非構造化テキスト | | システム依存関係 | LV0（頭の中のみ） | ドキュメントすら存在しない |
体制面：誰が何をするか
| 役割 | 人数 | 求めるスキル | |---|---|---| | インフラ/SREエンジニア | 1名 | システム構成を把握している担当者。プログラミング経験があると望ましい | | バックエンドエンジニア | 1名 | Cypher（Neo4jのクエリ言語）を学習できる意欲があればOK | | プロジェクトオーナー | 1名 | 「社内AIナレッジベース」の価値を経営に説明できる技術マネージャー |
スキーマ設計について重要な注意
Neo4jはスキーマレスのため「データを自由に入れられる」のが利点ですが、ノードラベル（例：
:Server、:Service、:Incident）とリレーションタイプ（例：DEPENDS_ON、TRIGGERS、CAUSED_BY）は事前に設計してから投入することを強く推奨します。後から変更するコストが高くなります。
技術面：何のツールで・どの手順で
ステップ1：ITシステム構成の概念モデリング（第1〜2週）
Mode-aiでシステム構成図（概念モデル）を描きます。
- ノードの種類を決める：
サーバー、サービス、バッチ処理、外部API、DB - リレーションの種類を決める：
DEPENDS_ON（依存）、TRIGGERS（トリガー）、DEPLOYED_ON（デプロイ先） - この概念モデルがNeo4jのスキーマ設計書になる
ステップ2：Neo4jスキーマ設計と初期データ投入（第3〜5週）
概念モデルをもとに、Cypherでノード・リレーションを定義して投入します。
// ノード作成例
CREATE (s1:Server {id: "web-01", name: "Webサーバー01", environment: "production"})
CREATE (s2:Service {id: "user-api", name: "ユーザーAPIサービス", language: "Node.js"})
CREATE (db:Database {id: "main-db", name: "メインDB", type: "PostgreSQL"})
// リレーション作成例
CREATE (s2)-[:DEPENDS_ON {criticality: "high"}]->(db)
CREATE (s1)-[:DEPLOYED_ON]->(s2)
既存のExcel設計書からPythonスクリプトで一括投入も可能です。
ステップ3：障害報告書のLV2構造化（第6〜8週）
過去の障害報告書（PowerPoint・Excel）をLLM（GPT-4等）でNeo4jのデータとして構造化します。
- 障害報告書のテキストから「影響を受けたサービス」「根本原因」「対応手順」を抽出
- Neo4jの
Incidentノードとして投入し、AFFECTEDリレーションでサービスと紐付け
ステップ4：GraphRAGで社内LLM連携（第9〜12週）
GraphRAGを使って、Neo4jのグラフ情報を生成AIへの文脈として渡します。
- 「WebサーバーA が停止した場合の影響範囲を教えて」 → GraphDBで依存関係をトラバースし → LLMに渡す文脈を自動生成 → 回答
- 「過去に似たインシデントはありましたか？」 → 障害Incidentノードをベクトル検索 → 類似事例をGraphで展開 → 回答
効果（After）
| 指標 | Before | After | |---|---|---| | 障害影響範囲の把握 | ベテランエンジニアへのヒアリング（30〜60分） | GraphDB検索で即座（秒単位） | | 過去インシデントの参照 | Slackで全文検索・記憶頼み | GraphRAGで類似事例を自動提案 | | 新人のシステム理解 | 先輩に何度も聞く | 「このサービスは何に依存していますか？」とLLMに質問 | | ドキュメント更新 | リリースごとに忘れられる | Cypherクエリで差分確認・更新チェックが自動化 |
よくある質問
Q：Confluenceやその他のナレッジベースがすでにあります。GraphDBは必要ですか？
A：Confluenceは「ドキュメント検索」には優れていますが、「AはBに依存する」という構造的な関係性の分析には向いていません。影響範囲分析や依存関係の可視化が必要な場合、GraphDBとの組み合わせが効果的です。Confluenceは「テキストコンテンツのLV2」として、GraphDBは「構造関係のLV3」として併用できます。
Q：Neo4j以外のグラフDBは使えますか？
A：Amazon Neptune（AWS）、Azure Cosmos DB（グラフAPI）なども選択肢です。既存クラウドインフラとの統合性で選ぶことを推奨します。ただし、概念モデリング（スキーマ設計）のアプローチはDBに依存しないため、ツール選定前にモデリングを先行させることが重要です。