knowledge-graph-creation

ナレッジグラフの作成

このスキルを使うと、AI エージェントは非構造化テキストを構造化されたナレッジグラフに変換できます。エージェントはエンティティ（人物、組織、技術、概念）を抽出し、それらの関係を特定して、形式的なグラフトリプル（主語・述語・目的語）を生成し、クエリ可能な形式（Neo4j 用の Cypher、JSON-LD）と視覚的な図（Mermaid）の両方でグラフを出力します。ナレッジグラフは、複雑な分野の理解、セマンティック検索の強化、暗黙のつながりの検出、レコメンデーションシステムの構築に役立ちます。

ワークフロー

1. ソース資料を分析する： 入力テキストを読み、その分野、対象範囲、複雑さを判断します。含まれている可能性の高いエンティティの種類（人物、組織、場所、技術的概念、出来事など）と、グラフに適した粒度を特定します。技術アーキテクチャのドキュメントではコンポーネントレベルの細かなエンティティが必要ですが、ニュース記事ではより大まかな行為者レベルのエンティティで十分な場合があります。

2. エンティティを抽出する： テキスト内のすべての固有表現と重要な概念を特定します。各エンティティについて、正式名称、種類（人物、組織、技術、概念、出来事、場所）、言及されている特筆すべき属性（例：設立日、バージョン番号、役割）を記録します。異なる名称や略称で登場するエンティティを重複排除します。

3. 関係を対応付ける： テキスト内で相互に関わるすべてのエンティティの組み合わせについて、その関係を特定します。各関係は、有向トリプル（主語）-[述語]->（目的語）として表します。一貫した語彙から述語を選択します（例：WORKS_AT、DEPENDS_ON、CREATED_BY、PART_OF、COMPETES_WITH）。追跡可能性を確保するため、出典となる文を記録します。

4. グラフトリプルとスキーマを生成する： 抽出したデータを構造化形式にまとめます。次のうち1つ以上の形式でトリプルを出力します：Neo4j 用の Cypher CREATE ステートメント、ウェブ相互運用性のための JSON-LD、または（主語、述語、目的語）の行からなるシンプルな CSV。エンティティの種類と有効な関係の種類を列挙した軽量なスキーマを定義します。

5. グラフを可視化する： 人が読みやすい形式でグラフを可視化します。Markdown に埋め込む Mermaid 構文を使うか、D3.js、Gephi、Neo4j Browser などのツール向けにレイアウトを説明します。中心となるノードと主要な関係のまとまりを強調します。

6. 検証して改善する： グラフの完全性と正確性を確認します。孤立ノード（関係を持たないエンティティ）、テキストから示唆される関係の欠落、より具体的にできる汎用的すぎる述語がないか確認します。特定のサブグラフの確認、修正、拡張をユーザーに依頼します。

使用方法

エージェントにテキストの抜粋、ドキュメント、または複数のドキュメントを渡します。必要に応じて、希望する出力形式（Cypher、JSON-LD、Mermaid）、関心のあるエンティティの種類、グラフの最大サイズを指定します。

Build a knowledge graph from the following text about our microservices architecture.
Output Cypher queries for Neo4j and a Mermaid diagram.

Text: "The API Gateway routes requests to the Auth Service and the Order Service.
The Order Service depends on the Inventory Service and the Payment Service.
The Payment Service integrates with Stripe and PayPal. All services publish
events to the Event Bus, which the Analytics Service consumes."

例

例 1：技術文書からのナレッジグラフ

ユーザーのリクエスト：

このテキストからナレッジグラフを作成してください： 「Kubernetes は、クラスター全体でコンテナ化されたアプリケーションをオーケストレーションします。Pod は Kubernetes における最小のデプロイ可能な単位で、1 つ以上のコンテナを含みます。Pod は Deployment によって管理され、Deployment はレプリカ数を指定された数に維持します。Service は Pod をネットワークトラフィックに公開します。Ingress は外部からの HTTP トラフィックを Service にルーティングします。etcd はクラスターの状態データをすべて保存し、API Server からアクセスされます。kubectl は API Server と通信する CLI ツールです。」

抽出されたエンティティ：

エンティティ	種類	属性
Kubernetes	テクノロジー	コンテナオーケストレーションプラットフォーム
Pod	概念	最小のデプロイ可能な単位
Container	概念	Pod 内のランタイム単位
Deployment	概念	Pod のレプリカを管理
Service	概念	ネットワーク公開レイヤー
Ingress	概念	外部 HTTP トラフィックのルーティング
etcd	テクノロジー	分散キーバリューストア
API Server	コンポーネント	中央管理インターフェース
kubectl	ツール	CLI クライアント

関係とトリプル：

主語	述語	目的語
Kubernetes	ORCHESTRATES	Pod
Pod	CONTAINS	Container
Deployment	MANAGES	Pod
Service	EXPOSES	Pod
Ingress	ROUTES_TO	Service
etcd	STORES_STATE_FOR	Kubernetes
API Server	READS_FROM	etcd
kubectl	COMMUNICATES_WITH	API Server

Cypher クエリ：

CREATE (k:Technology {name: 'Kubernetes', description: 'Container orchestration platform'})
CREATE (pod:Concept {name: 'Pod', description: 'Smallest deployable unit'})
CREATE (container:Concept {name: 'Container', description: 'Runtime unit'})
CREATE (deploy:Concept {name: 'Deployment', description: 'Manages Pod replicas'})
CREATE (svc:Concept {name: 'Service', description: 'Network exposure layer'})
CREATE (ing:Concept {name: 'Ingress', description: 'External HTTP routing'})
CREATE (etcd:Technology {name: 'etcd', description: 'Distributed key-value store'})
CREATE (api:Component {name: 'API Server', description: 'Central management interface'})
CREATE (ctl:Tool {name: 'kubectl', description: 'CLI client'})

CREATE (k)-[:ORCHESTRATES]->(pod)
CREATE (pod)-[:CONTAINS]->(container)
CREATE (deploy)-[:MANAGES]->(pod)
CREATE (svc)-[:EXPOSES]->(pod)
CREATE (ing)-[:ROUTES_TO]->(svc)
CREATE (etcd)-[:STORES_STATE_FOR]->(k)
CREATE (api)-[:READS_FROM]->(etcd)
CREATE (ctl)-[:COMMUNICATES_WITH]->(api)

---

例 2：ナレッジグラフの Mermaid による可視化

ユーザーのリクエスト：

このテキストから Mermaid ダイアグラムを使ってナレッジグラフを作成してください： 「Alice は Backend Team を率いています。Bob は Backend Team のメンバーで、Payment Service を保守しています。Payment Service は PostgreSQL Database と Redis Cache に依存しています。Carol は Frontend Team を率いており、Dashboard App を開発しました。このアプリは Payment Service API を呼び出します。」

抽出されたエンティティと関係：

主語	述語	目的語
Alice	LEADS	Backend Team
Bob	MEMBER_OF	Backend Team
Bob	MAINTAINS	Payment Service
Payment Service	DEPENDS_ON	PostgreSQL Database
Payment Service	DEPENDS_ON	Redis Cache
Carol	LEADS	Frontend Team
Carol	BUILT	Dashboard App
Dashboard App	CALLS	Payment Service

Mermaid ダイアグラム：

graph LR
    Alice["Alice (Person)"] -->|LEADS| BT["Backend Team"]
    Bob["Bob (Person)"] -->|MEMBER_OF| BT
    Bob -->|MAINTAINS| PS["Payment Service"]
    PS -->|DEPENDS_ON| PG["PostgreSQL Database"]
    PS -->|DEPENDS_ON| RC["Redis Cache"]
    Carol["Carol (Person)"] -->|LEADS| FT["Frontend Team"]
    Carol -->|BUILT| DA["Dashboard App"]
    DA -->|CALLS| PS

この可視化により、Payment Service が高い接続性を持つ中心ノードであることがすぐにわかります。Bob が保守し、Dashboard App が依存し、さらに 2 つのデータストアに依存しています。そのため、Backend Team と Frontend Team の両方にとって、重要なリスク領域となります。

ベストプラクティス

• 述語の語彙を一貫させます。 グラフを構築する前に、関係の種類（DEPENDS_ON、CREATED_BY、PART_OF など）を管理されたセットとして定義します。これにより、意味のあるクエリが可能になり、類義語の分散を防げます。
• エンティティ名を正規化します。 別名、省略形、共参照を 1 つの標準名に統一します。区別が重要でない限り、「JS」、「JavaScript」、「ECMAScript」は 1 つのノードに対応させます。
• エンティティの属性を含めます。 名前しかないノードよりも、種類、説明、メタデータ属性を持つノードのほうが有用です。情報量の多いノードを使うことで、より強力なクエリが可能になります。
• 関係の方向性を優先します。 関係は常に、主語と目的語が明確な有向エッジとしてモデル化します。双方向の関係で方向ごとに意味が異なる場合は、2 つの有向エッジとして表します。
• グラフの焦点を保ちます。 すべての名詞をエンティティにする必要はありません。ユーザーの目的に関連するエンティティに焦点を当て、洞察につながらずノイズを増やす一般的な用語は除外します。

エッジケース

• 曖昧なエンティティ参照： テキストに代名詞や漠然とした参照（「それ」「システム」など）が含まれる場合は、文脈に基づいて具体的なエンティティを特定します。特定に確信が持てない場合は、曖昧さを指摘し、ユーザーに確認を求めます。
• 暗黙の関係： 明示されていなくても暗示される関係があります（例：「Alice と Bob は Acme Corp に勤めている」は、両者の WORKS_AT 関係を示唆します）。これらも抽出しますが、明示された情報ではなく推定であることを明記します。
• 非常に長いソーステキスト： 数千語を超える文書は、チャンクに分けて処理し、処理を進めながらエンティティグラフを統合し、重複を除去します。生成されたグラフが実用的な可視化サイズ（およそ50ノード以上）を超える場合は、ユーザーに警告します。
• 矛盾する情報： ソーステキストに関係性について矛盾する記述が含まれている場合（例：ある段落では「Service A は Service B に依存する」とあり、別の段落では「Service A に外部依存はない」とある）、両方を含め、矛盾があることを明記します。
• ドメイン固有の用語： 専門分野（医療、法律、金融など）では、既存のナレッジベースとの相互運用性をユーザーが求める場合、エンティティタイプと関係性の述語に、その分野のオントロジー（医療分野の SNOMED CT、金融分野の FIBO など）を反映させる必要があります。