グラフデータベースとAIを用いた組織内のスキル相関図の動的構築

Neo4j×LLMで実装する動的スキル可視化：組織の暗黙知をコードで解き明かす全手順

この記事は急速に進化する技術について解説しています。最新情報は公式ドキュメントをご確認ください。

2026年1月5日約16分で読めます

文字サイズ:

Neo4j×LLMで実装する動的スキル可視化：組織の暗黙知をコードで解き明かす全手順

この記事の要点

グラフデータベースによる複雑なスキル関係の可視化
AI（LLM）を用いたスキル情報の自動抽出・更新
組織内の隠れた才能やスキル連携の発見

Slackのチャンネルで「あのプロジェクトの詳細、誰に聞けばわかるんだっけ？」といった質問が飛び交い、メンションのリレーが続く光景は、多くの組織でよく見られるのではないでしょうか。組織が拡大し、エンジニアの数が増えるにつれ、「誰が何を知っているか（Who knows What）」という情報は不透明になりがちです。

多くの企業がタレントマネジメントシステムを導入し、社員にスキルセットを入力させようと試みます。しかし、エンジニアは自分のプロフィール更新を後回しにする傾向があります。その結果、データベースにあるのは数年前に入力された情報だけで、最近の貢献や社内Wikiの記録は反映されないことがあります。

この記事では、この問題を「運用での努力」ではなく、「エンジニアリング」で解決する方法を解説します。

具体的には、グラフデータベース（Neo4j）と大規模言語モデル（LLM）を組み合わせ、社内の非構造化データ（日報、チャットログ、Gitコミットメッセージなど）から動的にスキル相関図（ナレッジグラフ）を構築するアーキテクチャを紹介します。これは最近、GraphRAG（Graph Retrieval-Augmented Generation）として注目されているアプローチの一種です。

概念論は最小限に、PythonコードとCypherクエリを多用した「実装の手引き」として構成しました。「まず動くものを作る」というプロトタイプ思考で、読み終える頃には具体的な実装イメージを持てるはずです。

1. なぜRDBとキーワード検索では「人材」が見つからないのか

まず、技術的な前提を揃えておきましょう。なぜ既存のSQLベースのリレーショナルデータベース（RDB）や、単純なElasticsearchのような全文検索エンジンでは、この問題が解決できないのでしょうか。

静的なスキルマップが3ヶ月で陳腐化する理由

RDBは「定型化されたデータ」の管理には適していますが、「動的で曖昧な関係性」の管理には不向きです。一般的なタレントマネジメントシステムのテーブル設計を考えてみましょう。

-- よくある残念なテーブル設計
SELECT * FROM employee_skills 
WHERE skill_name = 'Python' AND level >= 3;

このクエリが機能するためには、社員が能動的に「私はPythonレベル3です」と登録し続ける必要があります。しかし、技術の変化はあまりにも高速です。

例えば、AWSのようなクラウドプラットフォームでは、毎週のように新機能のリリースやランタイムの更新が行われています。Lambdaの対応言語バージョンが更新されたり、Amazon Connectに新たなフロー設計機能が追加されたりと、プラットフォームの機能は絶えず拡張し続けています。昨日まで「AWSが得意」と定義されていたスキルセットも、数週間後には「レガシーな設定しか知らない」状態になりかねません。RDBの厳格なスキーマと手動運用は、この流動的な変化に追従するコストが高すぎるのです。

「Javaができる」の解像度問題：文脈の欠落

次に「文脈（Context）」の問題です。単に「Java」というキーワードで検索した場合、以下の2人は区別できません。

10年前のStrutsフレームワークの保守運用が得意なエンジニア。
最新のSpring BootとMicroservicesアーキテクチャで新規開発を行っているエンジニア。

キーワード検索やベクトル検索（Vector Search）単体でも、ある程度の類似性は出せますが、「AさんはBさんと過去に同じプロジェクトにいた」とか、「Bさんの持つサーバーレス開発の知見は、Cさんの持つインフラ構築スキルと補完関係にある」といった構造的な関係性までは理解できません。

グラフデータベース(Neo4j) × LLMが最適解である技術的根拠

ここでグラフデータベースの出番です。グラフデータベースは、データを「ノード（点）」と「リレーションシップ（線）」で管理します。

ノード: 人、スキル、プロジェクト、ドキュメント
リレーションシップ: [HAS_SKILL], [WORKED_ON], [WROTE], [RELATED_TO]

これにより、「人」と「スキル」だけでなく、「スキル」と「スキル」の関係（例: ReactとTypeScriptは親和性が高い）や、「人」と「人」の関係（例: 同じリポジトリを編集した）を表現できます。

さらに、ここにLLMを組み合わせることで、非構造化テキストからこれらのノードとリレーションシップを自動抽出します。これが今回の肝となるアーキテクチャです。

2. 実装環境の準備とグラフデータモデリング

実装に向けた環境構築と、組織の暗黙知を表現するためのデータモデリングを行います。

Neo4j AuraDBとLangChainのセットアップ

手軽に検証を行う場合、Neo4jのマネージドサービスであるNeo4j AuraDBのFreeプランが適しています。クレジットカード不要で、永続的な無料インスタンスを利用可能です。

ローカル環境で開発を進める場合は、Dockerの利用が効率的です。なお、業務での利用時はDocker Desktopのライセンス条項（従業員数や売上規模による有料化）を確認し、必要に応じて適切なライセンス契約を行うか、Docker Engineの利用を検討してください。

# DockerでのNeo4j起動（APOCプラグイン有効化）
# ※イメージタグは最新の安定版（例: 5系）を指定してください
docker run -d \
    --name neo4j-skill-graph \
    -p 7474:7474 -p 7687:7687 \
    -e NEO4J_AUTH=neo4j/password123 \
    -e NEO4J_PLUGINS='["apoc"]' \
    neo4j:5

次に、Python環境をセットアップします。LLMオーケストレーションにはLangChain、グラフ操作には公式のneo4jドライバを使用します。LangChainは現在、コア機能とコミュニティ機能がパッケージ分割されているため、最新の構成に合わせて必要なモジュールを明示的にインストールします。

# LangChainの最新構成に対応したインストールコマンド
pip install langchain langchain-community langchain-openai neo4j pandas

専門家のアドバイス: LangChainなどのAI関連ライブラリはアップデート頻度が高く、クラスの移動や非推奨化が発生しやすい傾向にあります。本番運用時はpip freeze等でバージョンを固定し、公式ドキュメントで破壊的変更（Breaking Changes）を確認することを強く推奨します。

「人」「スキル」「プロジェクト」「成果物」のノード設計

グラフデータベースのスキーマ設計は、RDBの正規化とは異なり、「どのようなクエリ（質問）に答えたいか」から逆算するアプローチをとります。

本記事の目的である「誰がどのスキルを持っていて、その根拠は何か」を明確にするため、以下のデータモデルを定義します。

Employee (Label): 社員
- id, name, department
Skill (Label): 技術スキル
- name, category (Frontend, Backend, AI, etc.)
Artifact (Label): 成果物（コミットログ、Wiki記事、日報、仕様書など）
- id, content, date, url
Project (Label): プロジェクト
- name, description

エッジ（関係性）の定義とプロパティ設計

グラフデータベースにおいて最も重要な要素がリレーションシップ（エッジ）です。単なるつながりではなく、関係性の「質」や「重み」をプロパティとして持たせます。

(Employee)-[:WROTE]->(Artifact): 成果物の作成者
(Artifact)-[:MENTIONS {confidence: 0.9}]->(Skill): 成果物に含まれるスキルの推定（信頼度スコア付き）
(Employee)-[:HAS_SKILL {level: 'expert'}]->(Skill): 推定または認定されたスキル保有状況
(Skill)-[:RELATED_TO {weight: 0.8}]->(Skill): スキル間の共起関係や関連度

このモデルの最大の特徴は、EmployeeとSkillを直接結ぶ推論結果だけでなく、その間にArtifact（証拠）を介在させている点です。これにより、AIがスキルを判定した際に「なぜそのスキルを持っていると判断したのか（どのドキュメントに基づいているか）」という説明可能性（Explainability）をデータ構造レベルで担保できます。

3. 非構造化データからのスキルエンティティ抽出パイプライン

実装環境の準備とグラフデータモデリング - Section Image

ここがエンジニアリングの要となる部分です。テキストデータから構造化データへ変換するパイプラインを構築します。システム思考に基づいて全体像を捉えつつ、各コンポーネントの精度を高めていくアプローチが有効です。

社内ドキュメント・日報・Gitログのデータ前処理

入力データとして、例えばエンジニアの日報（Markdown形式）を想定しましょう。

# 202X-10-25 日報
今日はNext.jsのApp Routerへの移行検証を行った。
Server Actionsの挙動が不安定で、Vercelのログを追いかけるのに苦労した。
Redisのキャッシュ戦略も見直す必要がありそう。

このテキストから、「Next.js」「Server Actions」「Vercel」「Redis」といった技術用語を抽出し、さらに「苦労した」「見直す」といった文脈から習熟度や感情を読み取る必要があります。非構造化データにはノイズが多く含まれるため、前処理段階でのクリーニングが下流タスクの精度を左右します。

LLMを用いた固有表現抽出（NER）と正規化

LangChainのPydanticOutputParserを使用して、LLMの出力を厳密なJSON形式に固定します。ここで重要なのは表記揺れの正規化です。「JS」「Java Script」「Javascript」をすべて「JavaScript」に統一するよう指示を出します。

なお、LangChainのエコシステムは急速に進化しています。2026年現在、langchain-coreやlangchainパッケージは頻繁にアップデートされており、スキーマ処理の防御強化やツールの安定性が向上しています。特にシリアライズ処理に関するセキュリティパッチ（CVE-2025-68664等）が報告されているため、本番環境では必ず公式情報を確認し、最新バージョン（langchain-core 1.2.7以降など）を利用することが推奨されます。

以下は、抽出ロジックの実装例です。

from langchain.output_parsers import PydanticOutputParser
from langchain.prompts import PromptTemplate
from langchain_openai import ChatOpenAI
# Pydantic v2対応の最新ライブラリ構成を推奨
from langchain_core.pydantic_v1 import BaseModel, Field
from typing import List

# 抽出したいデータ構造の定義
class SkillExtraction(BaseModel):
    skills: List[str] = Field(description="抽出された技術スキル名のリスト。表記は公式名称に正規化すること（例: JS -> JavaScript）")
    context: str = Field(description="スキルが使用された文脈の要約")
    confidence: float = Field(description="スキル保有の確信度(0.0-1.0)")

parser = PydanticOutputParser(pydantic_object=SkillExtraction)

# プロンプトテンプレート
prompt = PromptTemplate(
    template="""
    以下のエンジニアの日報から、技術スキルを抽出し、JSON形式で出力してください。
    文脈から、単に言及しただけか、実際に使用・検証したかを判断し、確信度(confidence)に反映させてください。
    
    日報:
    {report_text}
    
    {format_instructions}
    """,
    input_variables=["report_text"],
    partial_variables={"format_instructions": parser.get_format_instructions()}
)

# 最新のモデルを指定（例: ChatGPT, ChatGPTなど利用可能なモデル）
model = ChatOpenAI(model="ChatGPT", temperature=0)
chain = prompt | model | parser

# 実行例
report_text = "今日はNext.jsのApp Routerへの移行検証を行った..."
result = chain.invoke({"report_text": report_text})
print(result)
# Output: skills=['Next.js', 'Vercel', 'Redis'], context='App Router移行検証とキャッシュ戦略見直し', confidence=0.85

このコードにより、非構造化テキストが「クエリ可能なオブジェクト」に変換されました。Google Vertex AIを利用する場合は、最新のgoogle-genaiパッケージへの移行が進んでいる点にも留意してください。

「経験年数」や「熟練度」のメタデータ推定ロジック

単に抽出するだけでなく、時系列データを考慮することで「経験年数」を推定できます。例えば、2020年の日報から「React」が出現し始め、現在も出現しているなら、「経験年数3年以上」と推論可能です。

これはLLM単発の推論ではなく、抽出されたデータを時系列で集計する決定論的なロジックとして実装するのが賢明です。LLMに複雑な期間計算をさせると、ハルシネーション（もっともらしい嘘）による誤った情報生成のリスクがあるためです。データガバナンスの観点からも、計算処理と推論処理の役割分担を明確にすることをお勧めします。

4. スキル相関の動的構築とグラフへの格納

データが構造化できたら、いよいよNeo4jに流し込み、グラフを成長させていきます。

Cypherクエリによるノード・エッジの自動生成

PythonからNeo4jへデータを書き込む際は、MERGE句を使用します。MERGEは「存在すればマッチし、存在しなければ作成する（Upsert）」という動作をするため、何度実行してもデータが重複しません。

def ingest_to_graph(driver, employee_name, extraction_result, artifact_id):
    query = """
    // Employeeノードの確保
    MERGE (e:Employee {name: $name})
    
    // Artifact（証拠）ノードの作成
    MERGE (a:Artifact {id: $artifact_id})
    SET a.context = $context, a.date = date()
    MERGE (e)-[:WROTE]->(a)
    
    // Skillノードとの紐付け
    WITH e, a
    UNWIND $skills AS skill_name
    MERGE (s:Skill {name: skill_name})
    MERGE (a)-[r:MENTIONS]->(s)
    SET r.confidence = $confidence
    
    // EmployeeとSkillの直接リンク（ショートカット）を更新
    MERGE (e)-[hs:HAS_SKILL]->(s)
    // 既存のスコアに加算して更新（単純な上書きではない）
    ON CREATE SET hs.score = $confidence
    ON MATCH SET hs.score = hs.score + ($confidence * 0.1) 
    """
    
    with driver.session() as session:
        session.run(query, 
                    name=employee_name, 
                    artifact_id=artifact_id,
                    skills=extraction_result.skills,
                    context=extraction_result.context,
                    confidence=extraction_result.confidence)

このロジックのポイントは、ON MATCH SET hs.score = hs.score + ... の部分です。何度もそのスキルについて言及するほど、HAS_SKILLリレーションのスコアが蓄積され、より強い結びつきになっていきます。

共起関係に基づく「スキル間の関連度」の計算

さらに、グラフデータベースならではの分析として、スキルの共起ネットワークを構築します。「同じArtifact内で頻繁に一緒に登場するスキルは、関連性が高い」という仮説に基づきます。

// スキル間の共起関係を構築する定期バッチ用クエリ
MATCH (s1:Skill)<-[:MENTIONS]-(a:Artifact)-[:MENTIONS]->(s2:Skill)
WHERE id(s1) < id(s2) // 重複排除
WITH s1, s2, count(a) AS frequency
WHERE frequency > 3 // 3回以上一緒に登場したら関連ありとみなす
MERGE (s1)-[r:RELATED_TO]-(s2)
SET r.weight = frequency

このクエリを定期的に実行することで、組織独自の「技術マップ」が自動生成されます。例えば、世間一般では「Python」と「Django」がセットですが、特定の組織では「Python」と「FastAPI」の結びつきが強い、といった組織固有の技術文化が可視化されます。

ベクトル埋め込みを用いた類似スキルのクラスタリング

Neo4jは現在、ベクトルインデックスをサポートしています。スキル名や説明文をEmbedding（ベクトル化）して格納しておけば、「意味的に近いスキル」を検索できます。

例えば、「機械学習」というキーワードで検索したときに、直接その単語が含まれていなくても、「TensorFlow」「PyTorch」「Scikit-learn」といったノードを類似度検索でヒットさせることができます。これをグラフ構造と組み合わせることで、精度の高いスキルマッチングが可能になります。

5. 実践アプリケーション：チームビルディング支援AIの実装

スキル相関の動的構築とグラフへの格納 - Section Image

データがグラフ構造として格納されれば、次はそれを活用するアプリケーション層の実装です。ここでは、LLMオーケストレーションツールとしてデファクトスタンダードであるLangChainを活用し、自然言語による柔軟な問い合わせ機能（Text2Cypher）を構築します。

「Reactが得意で金融知識がある人」を探す検索クエリ

自然言語で質問を投げると、LLMがそれをCypherクエリに変換し、グラフデータベースに問い合わせて結果を回答する仕組みを実装します。

LangChainのコミュニティパッケージに含まれるGraphCypherQAChainを使用することで、このパイプラインを簡潔に記述できます。

from langchain_community.chains import GraphCypherQAChain
from langchain_community.graphs import Neo4jGraph
from langchain_openai import ChatOpenAI

# Neo4jへの接続
# ※本番環境では環境変数から認証情報を読み込むことを強く推奨します
graph = Neo4jGraph(
    url="bolt://localhost:7687", 
    username="neo4j", 
    password="password123"
)

# Graph QA Chainの作成
# 複雑な推論を要するため、高性能なモデル（ChatGPTの最新モデル等）の利用を推奨
chain = GraphCypherQAChain.from_llm(
    ChatOpenAI(temperature=0, model="ChatGPT"), # 利用可能な最新モデルを指定
    graph=graph, 
    verbose=True,
    return_direct=True, # 検索結果をそのまま返すか、LLMに要約させるか
    allow_dangerous_requests=True # 実環境ではセキュリティリスクを評価の上設定
)

# 実行
query = "Reactが得意で、かつ過去に決済システムのプロジェクトに関わったことがあるエンジニアは誰？"
response = chain.invoke(query)
print(response)

このコードを実行すると、LLMはスキーマ情報を参照し、内部で以下のようなCypherクエリを生成します。

MATCH (e:Employee)-[:HAS_SKILL]->(s:Skill {name: 'React'})
MATCH (e)-[:WORKED_ON]->(p:Project)
WHERE p.description CONTAINS '決済' OR p.name CONTAINS 'Payment'
RETURN e.name, s.name, p.name

専門家としての注意点：
Text2Cypherは強力ですが、生成されたクエリがデータベースに対して意図しない操作を行うリスク（プロンプトインジェクション等）を考慮する必要があります。本番運用時には、Neo4j側の接続ユーザーに対して読み取り専用（ReadOnly）権限を付与し、書き込み操作を物理的に防ぐ設計が不可欠です。また、LangChainや関連ライブラリは頻繁にアップデートされるため、最新のセキュリティパッチ（CVE情報など）を常に確認してください。

GraphRAGを用いたコンテキスト認識型の人材推薦

単なるキーワード検索だけでなく、GraphRAG（Graph Retrieval-Augmented Generation） として機能させることで、より高度な推論が可能になります。

例えば、「新規のECサイト構築プロジェクトに最適なチームを提案して」と問いかけた場合、システムは以下のような複合的な判断を行えるようになります。

スキル要件の分解: ECサイト構築に必要な「Frontend」「Backend」「Infra」「Security」のスキルセットを定義。
関係性の考慮: 単にスキルを持つだけでなく、過去に同じプロジェクトで協業経験があり（WORKED_WITH関係）、コミュニケーションコストが低い組み合わせを優先。
説明可能性: 「AさんとBさんは過去に決済システムで成功体験があるため、今回の決済モジュール開発に適しています」といった根拠を提示。

これは、RDBの単純なフィルタリングや、従来のベクトル検索（Vector RAG）だけでは実現が難しい、グラフ構造（人間関係とスキルのつながり）を理解したAIならではの価値です。

最短パス探索による「誰に聞けばわかるか」の特定

グラフ理論のアルゴリズムである「最短経路探索（Shortest Path）」をアプリケーションに組み込むことで、組織内の「サイロ化」を打破する支援が可能です。直接の知り合いでなくても、「誰を経由すればそのエキスパートに繋がれるか」を提示できます。

// あなた(User A)からエキスパート(Target B)への最短紹介ルートを探す
MATCH path = shortestPath((me:Employee {name: 'User A'})-[*]-(target:Employee {name: 'Target B'}))
RETURN path

このクエリにより、「Bさんに技術的な相談をしたいが面識がない…あ、同期のCさんがBさんと同じプロジェクトにいたんだ！Cさんに紹介してもらおう」という具体的なアクションプランが提示されます。

このように、Neo4jとLLMを組み合わせることで、単なる「データベース検索」を超えた「組織のコラボレーション支援エンジン」を構築できるのです。

6. 持続可能な運用とガバナンス設計

システムを作って終わりではありません。むしろ、運用設計が重要です。

継続的なデータ更新と古い情報の減衰処理

スキルは使わなければ錆びつきます。グラフ上のスコアも時間とともに減衰させる必要があります。Neo4j側で定期的に以下のクエリを実行し、古い情報の重みを下げます。

// 最終更新から半年以上経過したスキルのスコアを20%減衰させる
MATCH (e)-[r:HAS_SKILL]->(s)
WHERE r.last_updated < date() - duration({months: 6})
SET r.score = r.score * 0.8

これにより、「昔取った杵柄」だけで検索上位に来てしまうことを防ぎ、「現役感」のあるスキルマップを維持できます。

社員によるスキル情報の修正・承認フロー（Human-in-the-loop）

AIによる自動抽出は100%完璧ではありません。時には誤検知もありますし、本人が「このスキルは公にしたくない（自信がない）」と思う場合もあるでしょう。

したがって、AIが構築したドラフト版のスキルプロフィールを、社員本人が確認・修正できるUI（Human-in-the-loop）が求められます。Slackボットなどで「最近、Go言語のコミットが多いですね。プロフィールに『Go』を追加しますか？」と通知し、ワンクリックで承認/拒否できる仕組みが良いでしょう。

アクセス権限管理と個人情報保護の実装

「誰が何を知っているか」はセンシティブな情報になり得ます。特に人事評価に関わる場合、慎重な取り扱いが必要です。

Neo4j Enterprise版であれば、ラベルやプロパティレベルでのアクセス制御が可能です。しかし、アプリケーション層（API）で制御するのが一般的です。例えば、自分のチームメンバーの詳細スキルは見れるが、他部署のメンバーは概要しか見れない、といった制御を実装します。

まとめ：埋もれた才能を発掘する旅へ

4. スキル相関の動的構築とグラフへの格納 - Section Image 3

ここまで、Neo4jとLLMを用いた動的スキル可視化の実装手順の全体像を解説しました。

RDBの限界: 静的なテーブルでは動的なスキルと文脈を捉えきれない。
グラフの力: 人、スキル、成果物をネットワークとして表現し、関係性を可視化する。
LLMの役割: 非構造化データから意味を抽出し、グラフへの入力を自動化する。
GraphRAG: 構造化された知識を用いて、高度なチームビルディングや人材検索を実現する。

このアーキテクチャを実装すれば、組織の中に眠っている「暗黙知」や「隠れた才能」が浮かび上がってくる可能性があります。それは、新しいプロジェクトの成功率を上げ、社員のモチベーションを高めるための強力な資産となるはずです。

まずは小さく、特定のチームやプロジェクトのデータを使ってPoC（概念実証）を始めてみてください。「えっ、あの人こんなこと知ってたの？」という驚きがあるかもしれません。

ぜひ、組織の可能性を解き放つ第一歩を踏み出してください。

Neo4j×LLMで実装する動的スキル可視化：組織の暗黙知をコードで解き明かす全手順 - Conclusion Image

コメントは1週間で消えます

コメントを読み込み中...