L1〜L4で「意味の枠組み（TBox）＋実データ（ABox）＝ナレッジグラフ」を作れるようになりました。 L5では、そのグラフをLLMの推論にどう接続するかを学びます。 詳しい用語定義は リファレンス を参照してください。
通常のRAGは文書チャンクの類似度検索です。次のような問いには弱くなります。
| パターン | 流れ | 向いている問い |
|---|---|---|
| A. KG-grounded RAG （グラフ検索→LLM生成） |
質問 → グラフから部分グラフ取得 → その事実だけをLLMに渡して回答生成 | 影響分析・経路説明。「なぜそう言えるか」の根拠提示が必須な業務 |
| B. Text2SPARQL （LLMがクエリを書く） |
質問 → LLMがSPARQLを生成 → グラフDBで実行 → 結果をLLMが文章化 | 集計・一覧・条件検索。「サポート切れの全サーバーを列挙」のような厳密回答 |
| C. ハイブリッド （ベクトル＋グラフ） |
ベクトルで候補文書を拾い、グラフで関係・制約を検証して絞り込む | 社内横断検索。文書は大量、でも「権限・部門・契約関係」で絞りたい場合 |
質問: 「営業部門のサポート切れサーバーを全部挙げて」
# LLMが生成するSPARQL（骨格）
SELECT ?server ?contractEnd WHERE {
?server a :Server ;
:belongsTo :SalesDept ;
:contractEndDate ?contractEnd .
FILTER (?contractEnd < NOW())
}ポイント: LLMは文章を「創作」せず、クエリだけ書いて実行結果に忠実に答えるため、ハルシネーションが構造的に抑えられます。 ただし生成クエリの検証（存在しないプロパティを使っていないか等）が必須です。
Salesforceの「顧客A」とSAPの「得意先A」が同一実体だと宣言しない限り、グラフは分断されたままです。
owl:sameAs で同一性を明示するか、IDマッピングテーブルを経由して正規URIに寄せます。これがMissionの「意味的統合」の核心作業です。
OWLは推論のための「開世界」（書いてない≠間違い）でした。対して SHACL は検証のための「閉世界チェック」です。「ServerはipAddress必須」「contractEndDateは日付型」といったShapeを定義し、投入データを検証してからグラフに入れます。 ゴミが入ったグラフをLLMに読ませないための関所です。
L2〜L4のCQ起点はトップダウン（あるべき概念から設計）。実務では既存DB・CSVからのボトムアップ（RDBテーブル→クラス、外部キー→プロパティへの機械的マッピング）と組み合わせます。 推奨手順: CQで骨格を決める → 既存スキーマをマッピングして肉付け → CQの受け入れテスト（SPARQLで回答できるか）で検証。
問: 「サポート契約が切れた全サーバーを漏れなく列挙せよ」という問いに対する最適な連携パターンはどれか？
Mission達成への推奨順序です。
全5回、お疲れさまでした。不明点・次に深掘りしたいテーマ（RDFlib実装、SHACL実例、自社データでの設計レビュー等）があれば、遠慮なく質問してください — それが次の学習記録になります。