コンテンツにスキップ
Reports
Deep Analysis Zenn Dev Xiushu53 News Knowledge Graph Neo4j Llm

Deep Analysis: ニュース記事から「文脈」を可視化する——LLM × Neo4j によるナレッジグラフ構築

date: 2026-06-10 analyst: deep-analysis skill（壁打ち） sources: 1件（Zenn / xiushu53 氏 個人技術記事） total_claims: 5件 total_counterargs: 採用2件 / 却下2件

概要

本記事は、112件の政治ニュース記事を LLM（gpt-4o-mini）と Neo4j を組み合わせてナレッジグラフ化するパイプラインの設計・実装報告である。Entity/Canonical 2層構造による名寄せ、Pydantic Structured Output、2ステップ解析（名寄せ → 構造化抽出）、MCP 経由での Claude Code 連携が主な技術的知見。

本プロジェクト（waribashi_konbu）が抱える「ニュース記事の文脈蓄積・エンティティ管理・重複排除」という課題と問題意識が完全に一致しており、グラフDB移行を除けば即座に応用可能な知見が複数含まれている。

抽出クレーム（5件）

ID主張Tierstatus
2026-06-10-W001LLM + Neo4j ナレッジグラフパイプラインが112件ニュースで実用化できたTier 3unverified
2026-06-10-W002Pydantic Structured Output のスキーマ定義が LLM への「最強の指示書」になるTier 3unverified
2026-06-10-W0032ステップ解析（Step1: 名寄せ → Step2: 構造化抽出）により構造化品質が劇的向上したTier 3unverified
2026-06-10-W004既知イベントのコンテキスト注入（RAG的）でイベントノード重複が大幅削減された（複数→8件に収束）Tier 3unverified
2026-06-10-W005LLM はプロンプト先頭の一文で文脈バイアスが強く形成される（因果関係抽出ゼロ問題の根因）Tier 3unverified

詳細

W001: 112件ニュースでの実用化

政治ニュース112件を処理し、Entity・Event・Statement・Organization・Policy・LogicRelation を含むグラフを構築。Docker 上の Neo4j 5.26 Community を使用。実証規模は小さいが、設計思想・スキーマ・クエリパターンは汎用的。

W002: Pydantic スキーマ = LLM 指示書

extra='forbid' 付きの Pydantic モデルを Structured Output に渡すことで、「フィールド名・型・ネスト構造」がそのまま LLM への暗黙的なプロンプトとして機能する。型定義が要件定義を兼ねる設計。

W003: 2ステップ解析

Step1 で人物の canonical_name を確定させ、Step2 でその確定情報をプロンプトに注入して構造化抽出を行う。LLM が1回の推論で「名寄せ」と「関係抽出」を同時に行おうとすると精度が落ちる問題を分割で回避。

W004: 既知コンテキスト注入（RAG 的）

記事公開日前後60日の既存イベントをDBから取得し「現在DBにあるイベントリスト」としてプロンプトに渡す。LLM に「既存IDを再利用せよ」と指示することでイベントノード増殖を防ぐ。本プロジェクトの manifest.tsv による重複排除と同じ問題意識。

W005: プロンプト先頭一文バイアス

logic_analysis セクションの冒頭が「エンティティ間の対立・支持・妥協を抽出せよ」という文で始まっていたため、LLM が「人間関係セクション」と認識し因果関係（CAUSES/PRECEDES）を抽出しなかった。先頭に「イベント間因果も対象」と明記し、日本語因果表現（「〜を受けて」「これを踏まえ」）を例示して解消。

反論と判定

反論 C001: Neo4j 依存でありプロジェクト移行コストが高い

  • 判定: 採用
  • 理由: Neo4j + Docker 導入、Cypher クエリ習得、グラフスキーマ設計は非自明なコストを伴う。本プロジェクトはマークダウン wiki で安定運用中であり、全面移行の優先度は低い。
  • 採用時の処置: 「Neo4j 導入」は推奨度★1に引き下げ。Pydantic/2ステップ/RAG注入など「グラフDB不要の知見」は個別に★3推奨とする。

反論 C002: 112件という実証規模が小さく大量記事でのスケーラビリティが未検証

  • 判定: 採用
  • 理由: 本プロジェクトはすでに数百件規模で運用中。LLM API コスト・名寄せ精度の劣化・グラフクエリ性能は報告されていない。
  • 採用時の処置: 統合結論でスケール未検証を明示し、段階的実験を推奨する。

反論 C003: Entity/Canonical 2層構造は wiki/entities/ + wiki/persons/ の分離と等価で新規性なし

  • 判定: 却下
  • 理由: 既存設計はテキスト wiki であり、「役職付き人物の変遷追跡」「横断検索」「グラフクエリ」は実装されていない。同じ問題意識の異なる実装レベルであり等価ではない。2層構造の「Entity=役職付きインスタンス、Canonical=人物本体」という概念は wiki/persons/ 設計改善に直接応用できる。

反論 C004: LLM の先頭一文バイアスは既知事実であり知見としての新規性はない

  • 判定: 却下
  • 理由: 「既知」でも「日本語特有の因果表現を具体例示して解決した」実装記録は本プロジェクトの deep-analysis プロンプトに直接適用可能。知見の新規性より再現性と具体性を評価する。

統合結論

本記事は本プロジェクトと問題設定が高度に一致しており、特に Pydantic 型定義によるスキーマ駆動抽出・2ステップ解析（名寄せ先行）・既知コンテキスト注入による重複排除・プロンプト先頭一文バイアス対策 の4技術は即座に応用可能である（採用反論: C001, C002 あり）。

ただし、以下の不確実性に留意する：

  • 実証112件はスモールスケール。本プロジェクトの規模での精度・コスト検証が必要
  • zenn.dev は Tier 3 ソース（個人記事）であり、技術的主張は著者の実装経験に基づく。外部検証なし

Neo4j 本格導入は優先度低。まず scripts/fetch_articles.py または deep-analysis スキルのプロンプト設計に 2ステップ解析・RAG注入・先頭一文バイアス対策を取り込むことが現実的な第一歩。

当プロジェクトへの取り込み推奨度

技術/知見推奨度（★1-3）具体的アクション
2ステップ解析（名寄せ先行）★★★deep-analysis プロンプトの claim 抽出を「人物確定 → 関係抽出」の2フェーズに分割
既知コンテキスト注入（RAG的）★★★wiki/entities・persons の既知エンティティリストを deep-analysis プロンプトに渡し重複生成を防ぐ
プロンプト先頭一文バイアス対策★★★deep-analysis・wiki-signal の各プロンプトで「先頭文に全対象を列挙」する習慣を徹底
Pydantic Structured Output★★★fetch_articles.py の構造化出力に Pydantic スキーマ導入を検討（現在は自由形式出力）
Entity/Canonical 2層設計★★☆wiki/persons/ に「役職インスタンス」概念を追加し変遷追跡を強化（中規模改修）
MCP + Neo4j 自然言語クエリ★★☆将来的な拡張として有望。wiki 蓄積量が増えた段階で検討
Neo4j グラフDB フル移行★☆☆コスト・破壊的変更大。現時点では非推奨

参考ソース

ReportsLayerx Ai Agent Authorization