AI for Scienceとは？ #9 ─ 【実践】Docling + Microsoft GraphRAGで学術論文から「新しい知識」を発見する

Last updated at 2026-01-29Posted at 2026-01-29

はじめに：AI要約では見つからない「知識」がある

ChatGPTに論文を要約させたことはありますか？便利ですよね。でも、こんな経験はないでしょうか？

「BERTとGPTの関係性を教えて」と聞いたら、各論文の要約が返ってきただけで、論文間の関係性は分からなかった...

これはAI要約の本質的な限界です。

NotebookLMでも同じ問題が起きます

GoogleのNotebookLMに複数の論文PDFを登録すれば、各論文の要約や質問応答は優秀にこなします。しかし、「論文Aと論文Bの技術的な関係性は？」「3つの論文に共通するテーマは？」といった横断的な質問には、断片的な回答しか返ってきません。

これはNotebookLMがBaseline RAG（類似文章の検索・引用）を採用しているためです。登録した論文を「検索可能なデータベース」として扱いますが、論文間の関係性を構造化していないのが原因です。

手法	できること	できないこと
AI要約	1つの論文の内容を圧縮	複数論文の横断的な関係性発見
NotebookLM / Baseline RAG	類似文章の検索・引用・要約	明示的に書かれていない関係性の推論
GraphRAG	知識グラフによる関係性の発見	ー

本記事では、Docling（PDF→Markdown変換）とMicrosoft GraphRAGを組み合わせて、複数の学術論文から論文には明示的に書かれていない新しい知識を発見する方法をハンズオン形式で解説します。

本記事のゴール

Transformer、BERT、GPT-2の3つの論文PDFから、以下のような横断的な知識を発見します。

質問: BERTとGPTの関係性は？アーキテクチャの違いは？

GraphRAGの回答:
- BERTは双方向Transformer、GPTは一方向Transformer
- BERTはMasked LM、GPTはCausal LMで訓練
- 両者は相補的：BERTは理解タスク、GPTは生成タスクに適する
- 両者ともVaswaniのTransformer論文に基づいている

これは単なる要約ではありません。3つの論文を横断して初めて得られる知識です。

システムアーキテクチャ

本記事で構築するシステムの全体像です。

Step	処理	入力	出力
1	Docling	論文PDF 3件	Markdown 3件
2	GraphRAG Indexing	Markdown	エンティティ 684件 / 関係性 24,784件 / コミュニティ 60件
3	Query	質問文	横断的な知識・関係性

処理フロー詳細：

📄 論文PDF (Transformer, BERT, GPT-2)
    │
    ▼ [Step 1: Docling]
📝 Markdown変換（構造保持）
    │
    ▼ [Step 2: GraphRAG Indexing]
    ├── チャンク分割（1200 tokens）
    ├── エンティティ抽出（gpt-4o-mini）
    ├── コミュニティ検出（Leiden Algorithm）
    ├── レポート生成
    └── ベクトル埋め込み（text-embedding-3-small）
    │
    ▼ [ストレージ]
    ├── entities.parquet（684件）
    ├── relationships.parquet（24,784件）
    ├── communities.parquet（60件）
    └── LanceDB（ベクトルストア）
    │
    ▼ [Step 3: Query]
    ├── Local Search（詳細な関係性）
    └── Global Search（俯瞰的な知識）
    │
    ▼
💡 横断的な知識の発見

📊 詳細アーキテクチャ図（クリックで展開）

対象読者

研究者・大学院生（プログラミング経験は浅くてOK）
複数の論文を効率的に読み解きたい方
RAGの次のステップを探している方

環境構築

必要なもの

Python 3.10以上
OpenAI APIキー（GPT-4o-miniとtext-embedding-3-small使用）

セットアップ

ターミナル

# プロジェクトディレクトリ作成
mkdir academic-knowledge-discovery && cd academic-knowledge-discovery

# 仮想環境作成
python -m venv .venv
source .venv/bin/activate  # Windows: .venv\Scripts\activate

# ライブラリインストール
pip install docling graphrag pandas

Step 1: 論文PDFをMarkdownに変換（Docling）

1.1 論文PDFのダウンロード

今回は以下の3論文を使用します。

論文	URL
Attention Is All You Need	https://arxiv.org/pdf/1706.03762
BERT	https://arxiv.org/pdf/1810.04805
GPT-2	https://cdn.openai.com/better-language-models/language_models_are_unsupervised_multitask_learners.pdf

ターミナル

mkdir -p papers
curl -L -o papers/transformer.pdf "https://arxiv.org/pdf/1706.03762"
curl -L -o papers/bert.pdf "https://arxiv.org/pdf/1810.04805"
curl -L -o papers/gpt2.pdf "https://cdn.openai.com/better-language-models/language_models_are_unsupervised_multitask_learners.pdf"

1.2 Doclingで変換

convert_papers.py

from docling.document_converter import DocumentConverter
from pathlib import Path

# 変換器を初期化
converter = DocumentConverter()

# 出力ディレクトリ
output_dir = Path("markdown")
output_dir.mkdir(exist_ok=True)

# PDF一覧
papers = [
    ("papers/transformer.pdf", "attention_is_all_you_need.md"),
    ("papers/bert.pdf", "bert.md"),
    ("papers/gpt2.pdf", "gpt2.md"),
]

# 変換実行
for pdf_path, output_name in papers:
    print(f"Converting: {pdf_path}")
    result = converter.convert(pdf_path)
    
    # Markdown出力
    md_path = output_dir / output_name
    md_path.write_text(result.document.export_to_markdown())
    print(f"  -> {md_path} ({md_path.stat().st_size / 1024:.1f} KB)")

print("\n✅ 変換完了！")

ターミナル

python convert_papers.py

出力例：

Converting: papers/transformer.pdf
  -> markdown/attention_is_all_you_need.md (49.2 KB)
Converting: papers/bert.pdf
  -> markdown/bert.md (69.8 KB)
Converting: papers/gpt2.pdf
  -> markdown/gpt2.md (126.9 KB)

✅ 変換完了！

Doclingは表や数式も構造を保持してMarkdownに変換します。OCRベースの変換より高品質です。

Step 2: GraphRAGでナレッジグラフ構築

2.1 GraphRAGプロジェクト初期化

ターミナル

mkdir graphrag_project && cd graphrag_project

# 初期化（settings.yamlが生成される）
graphrag init --root .

# 入力ディレクトリにMarkdownをコピー
cp ../markdown/*.md input/

2.2 settings.yaml の設定

生成された settings.yaml を以下のように編集します。

settings.yaml

### LLM settings ###
completion_models:
  default_completion_model:
    model_provider: openai
    model: gpt-4o-mini
    auth_method: api_key
    api_key: ${OPENAI_API_KEY}  # 環境変数から取得
    retry:
      type: exponential_backoff

embedding_models:
  default_embedding_model:
    model_provider: openai
    model: text-embedding-3-small
    auth_method: api_key
    api_key: ${OPENAI_API_KEY}
    retry:
      type: exponential_backoff

### Document processing settings ###
input:
  type: text
  file_pattern: ".*\\.md$$"

chunking:
  type: tokens
  size: 1200
  overlap: 100
  encoding_model: cl100k_base

### Storage settings ###
input_storage:
  type: file
  base_dir: "input"

output_storage:
  type: file
  base_dir: "output"

vector_store:
  type: lancedb
  db_uri: output/lancedb
  index_schema:
    entity_description:
      vector_size: 1536
    text_unit_text:
      vector_size: 1536
    community_full_content:
      vector_size: 1536

api_key を直接書く場合は、絶対にGitにコミットしないでください。環境変数 OPENAI_API_KEY を使うことを推奨します。

2.3 インデックス作成

ターミナル

export OPENAI_API_KEY="sk-your-api-key-here"
graphrag index --root .

出力例：

Starting pipeline with workflows: load_input_documents, create_base_text_units, 
create_final_documents, extract_graph, finalize_graph, extract_covariates, 
create_communities, create_final_text_units, create_community_reports, 
generate_text_embeddings

Starting workflow: load_input_documents
Workflow complete: load_input_documents

Starting workflow: extract_graph
  1331 / 1331 ............
Workflow complete: extract_graph

Starting workflow: create_community_reports
  60 / 60 ............
Workflow complete: create_community_reports

Starting workflow: generate_text_embeddings
  3 / 3 ............
Workflow complete: generate_text_embeddings

Pipeline complete

処理内容の解説：

extract_graph: 論文からエンティティ（人名、モデル名、概念など）と関係性を抽出
create_communities: 関連するエンティティをクラスタリング
create_community_reports: 各クラスタの要約レポートをLLMで生成

Step 3: 知識発見クエリの実行

3.1 Local Search（詳細な関係性の発見）

ターミナル

graphrag query --root . --method local \
  "What is the relationship between BERT and GPT? What are the key architectural differences?"

回答：

Relationship Between BERT and GPT

BERT and GPT are both foundational models in NLP built on the transformer architecture, yet they serve different purposes:

Key Architectural Differences

Architecture Type:

BERT: bidirectional transformer - understands context from both left and right

GPT: unidirectional (left-to-right) transformer - predicts next word based on preceding words

Training Objective:

BERT: Masked Language Model - predicts masked words from context

GPT: Causal Language Model - predicts next token in sequence

Use Cases:

BERT: Understanding tasks (classification, NER, QA)

GPT: Generation tasks (text completion, storytelling)

Complementary Strengths

BERT and GPT complement each other: a system can use BERT for understanding and extracting features, then GPT for generating responses.

3.2 Global Search（俯瞰的な知識の発見）

ターミナル

graphrag query --root . --method global \
  "What are the main themes and innovations across the Transformer, BERT, and GPT-2 papers? How did they collectively advance NLP?"

回答：

Main Themes and Innovations

The Transformer Architecture

The Transformer introduced attention mechanisms as the sole computation method, replacing recurrence. This enabled parallelization and processing of longer contexts.

Bidirectional Context in BERT

BERT introduced bidirectional training through masked language modeling, dramatically improving understanding of context and word relationships.

GPT-2 and Zero-Shot Learning

With 1.5 billion parameters, GPT-2 demonstrated zero-shot learning - performing tasks without explicit training, showing generalization capabilities.

Collective Advancements

These models established the transfer learning paradigm in NLP:

Pre-train on large corpora (BooksCorpus, WebText)

Fine-tune for specific tasks

Evaluate on benchmarks (GLUE, SQuAD)

This approach set new standards across sentiment analysis, translation, and summarization.

AI要約・Baseline RAG・GraphRAGの比較

同じ質問に対する各手法の回答を比較します。

観点	AI要約	Baseline RAG	GraphRAG
回答の情報源	1つの論文	類似度の高い断片	知識グラフ全体
横断的関係性	❌ 発見不可	△ 偶然含まれれば	✅ 構造的に発見
技術系譜	❌	❌	✅ Transformer→BERT→GPT
相補性の説明	❌	△	✅ 明確に説明
引用の根拠	なし	チャンク番号	コミュニティレポート

GraphRAGの強み：

「BERTもGPTもVaswaniのTransformerに基づく」という論文横断的な知識を発見
「BERTは理解、GPTは生成に適する」という相補性を構造的に説明
各主張の根拠（Data: Reports）を明示

生成されたナレッジグラフの可視化

GraphRAGが抽出した知識をMermaidで可視化すると：

抽出された統計情報

analyze_graph.py

import pandas as pd

entities = pd.read_parquet('output/entities.parquet')
relationships = pd.read_parquet('output/relationships.parquet')
communities = pd.read_parquet('output/communities.parquet')

print(f"📄 入力文書: 3件（Transformer, BERT, GPT-2）")
print(f"🏷️  エンティティ: {len(entities):,}件")
print(f"🔗 関係性: {len(relationships):,}件")
print(f"🏘️  コミュニティ: {len(communities):,}件")

出力：

📄 入力文書: 3件（Transformer, BERT, GPT-2）
🏷️  エンティティ: 684件
🔗 関係性: 24,784件
🏘️  コミュニティ: 60件

📚 3論文から得られた知見の詳細

GraphRAGによる探索で、単独の論文を読むだけでは気づきにくい横断的な知見が多数得られました。以下に詳細をまとめます。

🔬 発見1: 技術の系譜と進化の流れ

GraphRAGは3論文間の技術的な継承関係を明確に抽出しました。

知見：

Transformerは「Encoder-Decoder」構造を提案したが、BERTはEncoderのみ、GPTはDecoderのみを採用
これにより、BERTは双方向文脈理解に特化、GPTは逐次生成に特化という分化が生まれた
ELMoの「文脈依存の単語埋め込み」という概念が、両モデルの設計思想に影響を与えている

🔬 発見2: 訓練手法の対照的なアプローチ

観点	BERT	GPT
訓練目的	Masked Language Model (MLM)	Causal Language Model (CLM)
マスク率	入力の15%をマスク	マスクなし（次トークン予測）
文脈の方向	双方向（左右両方を参照）	一方向（左のみ参照）
追加タスク	Next Sentence Prediction (NSP)	なし

知見：

BERTのMLMは「穴埋め問題」、GPTのCLMは「続きを書く問題」と捉えられる
この違いが、BERTは理解タスク（分類、QA）、GPTは生成タスク（文章生成、対話）に適するという特性を生んだ
BERTのNSPタスクは、文間の関係理解を強化する目的で導入された

🔬 発見3: ベンチマークとデータセットの共通基盤

GraphRAGは、3論文が共通して参照しているベンチマーク・データセットを抽出しました。

ベンチマーク/データセット	Transformer	BERT	GPT-2	用途
GLUE	-	✅	✅	言語理解の総合評価
SQuAD	-	✅	✅	質問応答
BooksCorpus	-	✅	✅	事前学習データ
WMT	✅	-	-	機械翻訳
WebText	-	-	✅	事前学習データ

知見：

GLUEとSQuADがNLPモデル評価の標準ベンチマークとして確立されている
BooksCorpusは800万冊の書籍テキストで、BERTとGPT両方の事前学習に使用
GPT-2はWebTextというインターネットテキストを使用し、より多様なテキスト分布を学習

🔬 発見4: 研究者・機関のネットワーク

GraphRAGは人名と所属機関もエンティティとして抽出し、研究コミュニティの構造を可視化しました。

主要な研究者（接続度Top10）：

研究者	所属	関連論文	接続度
Jakob Uszkoreit	Google	Transformer, BERT	155
Ilya Sutskever	OpenAI	Transformer, GPT	147
Yoshua Bengio	MILA	参照論文多数	144
Geoffrey Hinton	Google/Toronto	参照論文多数	143
Mike Schuster	Google	Transformer	154

知見：

Transformerの著者がBERTの開発にも関与（Google内での技術継承）
Ilya Sutskeverは「Attention Is All You Need」の共著者であり、OpenAIでGPTシリーズを主導
Bengio、Hintonといった深層学習の先駆者が、引用ネットワークを通じて間接的に影響

🔬 発見5: Attentionメカニズムの進化

知見：

Self-Attentionは「文中の全単語ペア間の関係性を計算」する機構
Multi-Head Attentionは「複数の視点から同時に関係性を捉える」拡張
BERTは全方向のAttention、GPTは因果的（過去→未来）のAttentionを使用

🔬 発見6: モデルサイズとスケーリング則の萌芽

モデル	パラメータ数	層数	Hidden Size	Attention Heads
Transformer (base)	65M	6	512	8
BERT-Base	110M	12	768	12
BERT-Large	340M	24	1024	16
GPT-2 (largest)	1.5B	48	1600	25

知見：

2年間でパラメータ数が約23倍に増加（65M → 1.5B）
GPT-2論文では「モデルサイズを大きくするとZero-Shot性能が向上」と報告
これが後のGPT-3（175B）、GPT-4へのスケーリング研究の基盤となった

🔬 発見7: Zero-Shot / Few-Shot学習の概念

GPT-2論文の重要な発見（GraphRAGが抽出）：

「GPT-2は明示的に訓練されていないタスクでも、タスクの説明を与えるだけで実行できる」

学習パラダイム	説明	例
Fine-tuning	タスク専用データで追加学習	BERT + SQuAD訓練データ
Zero-Shot	タスク説明のみで実行	"Translate to French: Hello"
Few-Shot	数例の入出力を提示して実行	"Q: 2+2 A: 4, Q: 3+5 A: ?"

知見：

BERTはFine-tuningパラダイムを確立（事前学習→タスク特化学習）
GPT-2はZero-Shotの可能性を示唆（タスク特化学習なしで汎化）
この発見がGPT-3のIn-Context Learningへ発展

📊 知見のまとめ：論文横断で見えた「大きな絵」

┌─────────────────────────────────────────────────────────────────┐
│                    NLPの転換点（2017-2019）                      │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  [Transformer 2017]                                             │
│      │                                                          │
│      ├──→ Self-Attention機構の確立                               │
│      │                                                          │
│      ├──────────────┬──────────────┐                            │
│      │              │              │                            │
│      ▼              ▼              ▼                            │
│  [Encoder採用]  [Decoder採用]  [両方採用]                        │
│      │              │              │                            │
│      ▼              ▼              ▼                            │
│   BERT           GPT-1/2        T5, BART                        │
│      │              │                                           │
│      ▼              ▼                                           │
│  理解タスク特化   生成タスク特化                                  │
│  (MLM, NSP)     (Causal LM)                                     │
│      │              │                                           │
│      └──────┬───────┘                                           │
│             │                                                   │
│             ▼                                                   │
│      転移学習パラダイムの確立                                     │
│      - 大規模事前学習                                            │
│      - Fine-tuning / Zero-Shot                                  │
│      - ベンチマーク評価（GLUE, SQuAD）                            │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

GraphRAGの価値： 上記の知見は、3論文を個別に読んでも得られる情報ですが、関係性を構造化して提示することで、「なぜBERTとGPTが分岐したのか」「どのようにスケーリング則の発見につながったのか」といったストーリーが見えてきます。これが単なる要約との違いです。

3つの論文から684のエンティティと24,784の関係性が抽出されました！

コスト目安

OpenAI API使用料金（2026年1月時点）：

項目	使用量	料金
gpt-4o-mini（インデックス作成）	~500K tokens	~$0.15
text-embedding-3-small	~200K tokens	~$0.004
gpt-4o-mini（クエリ）	~10K tokens/query	~$0.003

合計: 約$0.20（約30円）で3論文の知識グラフを構築できます。

まとめ

本記事で実現したこと

DoclingでPDF論文をMarkdownに高品質変換
GraphRAGでナレッジグラフを自動構築
Local/Global Searchで横断的な知識を発見

🔬 AI for Science Challenge における研究支援への応用

本記事で紹介した Docling + GraphRAG の仕組みは、AI for Science Challenge プログラムにおける研究活動を大幅に加速させる可能性を秘めています。以下に、具体的なユースケースと期待される効果を詳述します。

🎯 AI for Science Challenge とは

AI for Science Challengeは、AIを活用して科学研究を加速することを目的としたプログラムです。材料科学、創薬、気候科学、生命科学など、様々な分野で膨大な論文や実験データから知見を抽出し、新たな発見につなげることが求められています。

📊 従来の研究プロセスの課題

課題	詳細	影響
論文の洪水	年間数百万本の論文が出版	関連研究の見落とし
サイロ化した知識	分野ごとに文献が分断	学際的発見の困難
暗黙知の埋没	論文間の関係性が明示されない	技術系譜の把握困難
時間コスト	文献レビューに数ヶ月	研究サイクルの長期化

🚀 GraphRAGによる研究支援の具体例

1️⃣ 文献サーベイの自動化・高速化

従来: 100本の論文を読む → 3ヶ月
GraphRAG: 100本の論文をインデックス化 → 1日
         → 任意の質問に即座に回答

具体的なシナリオ：

# 材料科学の例：ペロブスカイト太陽電池の研究動向を調査
graphrag query --method global \
  "What are the main approaches to improve perovskite solar cell stability? 
   How do different passivation techniques compare?"

期待される回答：

各手法（2D/3D構造、添加剤、界面工学）の比較
研究グループ間の技術的な系譜
未解決の課題と有望な方向性

2️⃣ 学際的な知識の橋渡し

AI for Scienceの多くのブレークスルーは、異分野の知識の融合から生まれます。

GraphRAGの貢献：

材料科学の論文と機械学習の論文を同一のナレッジグラフに統合
「AlphaFoldで使われた手法は材料探索に応用できるか？」といった横断的な質問に回答
意外な共通点（例：結晶構造予測とタンパク質折りたたみの類似性）を発見

3️⃣ 研究仮説の生成支援

GraphRAGは単なる検索ツールではなく、新しい研究仮説の発見を支援します。

例：気候科学 × 機械学習

graphrag query --method local \
  "What machine learning techniques have been successful in weather prediction? 
   Could similar approaches be applied to long-term climate modeling?"

GraphRAGが発見しうる知見：

Transformerが気象予測で成功した理由（時系列の長期依存性）
気候モデリングの現状の課題（計算コスト、解像度）
潜在的な研究機会：「Transformerの効率化手法を気候モデルに適用」

4️⃣ 実験設計の知識ベース構築

┌─────────────────────────────────────────────────────────────────┐
│          GraphRAG を活用した実験設計支援                          │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  [論文から抽出される情報]                                         │
│      │                                                          │
│      ├── 実験条件（温度、圧力、試薬濃度など）                      │
│      ├── 使用機器・手法                                          │
│      ├── 成功/失敗のパターン                                     │
│      └── 最適化のヒント                                          │
│                                                                 │
│  [研究者への支援]                                                │
│      │                                                          │
│      ├── 「この材料の合成で最も成功率が高い条件は？」            　 │
│      ├── 「過去に失敗した条件と原因は？」                        　│
│      └── 「類似材料で有効だった手法は？」                        　│
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

📈 期待される研究加速効果

研究フェーズ	従来の所要時間	GraphRAG活用後	削減率
文献サーベイ	2-3ヶ月	1-2週間	75-90%
関連研究の特定	数週間	数時間	95%
技術動向の把握	継続的な努力	オンデマンド	-
学際的アイデア発見	偶然に依存	体系的に可能	-

🔧 AI for Science Challenge での実装ロードマップ

💡 研究者へのメッセージ

「論文を読む」から「論文に質問する」へ

GraphRAGは、研究者の知的パートナーとして機能します：

時間の解放: 文献調査の時間を実験・思考に充てられる
視野の拡大: 普段読まない分野の知見にもアクセス可能
発見の体系化: 偶然の発見を再現可能なプロセスに

AI for Science Challengeの目標である「AIによる科学研究の加速」は、このような知識発見インフラの構築から始まります。本記事のDocling + GraphRAGパイプラインは、その第一歩となるでしょう。

研究室・ラボでの導入を検討されている方へ：
本記事のコードはGitHubリポジトリで公開予定です。カスタムエンティティタイプの定義や、特定分野向けのプロンプトチューニングについても、今後記事を追加していく予定です。

GraphRAGが有効なユースケース

ユースケース	説明
文献レビュー	数十の論文から研究動向を俯瞰
特許分析	技術間の関係性を発見
競合分析	複数企業のIR資料から戦略を比較
法令調査	関連法規の横断的な解釈

次のステップ

より多くの論文を追加して知識グラフを拡張
カスタムエンティティタイプ（研究手法、データセットなど）を定義
Drift Searchで対話的な知識探索

❓ FAQ（よくある質問）

Q1: 学術論文をGraphRAG化する際の著作権は大丈夫？

⚠️ 著作権に関する重要な注意事項

学術論文には著作権が存在します。GraphRAGでの利用にあたっては、以下の点に注意してください。

利用形態	著作権上の扱い	注意点
個人研究目的	私的使用として許容される場合が多い	商用利用は不可
教育目的	引用の範囲内で許容	出典明記が必須
商用利用	原則として許諾が必要	ライセンス確認必須
社内利用	グレーゾーン	法務確認を推奨

推奨される対応：

オープンアクセス論文を優先的に使用
- arXiv、PubMed Central、DOAJなどのOA論文を活用
- Creative Commons（CC）ライセンスの論文を選択
著者版（Author's Accepted Manuscript）の確認
- 多くの出版社は著者版の利用を許可しています
Text and Data Mining（TDM）権の確認
- 学術機関は出版社との契約でTDM権を持つ場合があります
- 所属機関の図書館に確認してください
生成物の公開には注意
- GraphRAGの出力（要約、レポート）を公開する場合は引用ルールに従う

本記事で使用した論文について：

Transformer論文（arXiv）: arXiv Licenseに基づき再配布可能
BERT論文（arXiv）: 同上
GPT-2論文（OpenAI）: 公開されている研究論文として引用可能

いずれも学術・教育目的での利用が想定されています。

Q2: 論文PDFを合法的にダウンロードできるサイトは？

以下のサイトから無料かつ合法的に論文PDFを取得できます。

サイト	URL	特徴
arXiv	https://arxiv.org	物理・数学・CS・統計などのプレプリント
PubMed Central	https://www.ncbi.nlm.nih.gov/pmc/	生命科学・医学のオープンアクセス論文
Semantic Scholar	https://www.semanticscholar.org	AI搭載の学術検索、OA論文へのリンク
DOAJ	https://doaj.org	オープンアクセスジャーナルのディレクトリ
Unpaywall	https://unpaywall.org	ペイウォール論文のOA版を検索（ブラウザ拡張）
CORE	https://core.ac.uk	世界最大のOA論文アグリゲータ
J-STAGE	https://www.jstage.jst.go.jp	日本の学術論文（多くがOA）
CiNii Research	https://cir.nii.ac.jp	日本の論文・研究データ検索
Google Scholar	https://scholar.google.com	OA版へのリンクを表示（[PDF]マーク）

⚠️ 違法サイトに注意：
Sci-Hub等の論文海賊版サイトは著作権法違反となるため、使用しないでください。

Tip: Unpaywall拡張機能
ブラウザにUnpaywallをインストールすると、論文ページを開いた際に合法的な無料版があれば自動的に表示されます。研究者必携のツールです。

Q3: 論文を追加するたびにインデックスを再作成する必要がある？

はい、現状のGraphRAGでは論文追加時にインデックスの再構築が必要です。

[現状の仕組み]

論文A,B,C → インデックス作成（30分）→ 検索可能

論文Dを追加 → 全体を再インデックス（30分）→ 検索可能
              ※ A,B,Cも再処理される

なぜ再構築が必要か：

コミュニティ検出の再計算: 新しいエンティティが既存のクラスタ構造を変える可能性
関係性の再評価: 新論文が既存エンティティとの新しい関係を持つ
コミュニティレポートの再生成: 各クラスタの要約が変わる

対策・Tips：

対策	説明
バッチ追加	論文を1本ずつ追加せず、まとめて追加してからインデックス作成
インデックスのバージョン管理	`output/`をGitで管理し、必要に応じて過去版に戻す
増分インデックス（将来）	GraphRAGの今後のバージョンで対応予定（Issue参照）

参考: 処理時間の目安（gpt-4o-mini使用時）

10論文: 約30分、$0.50程度
50論文: 約2時間、$2.00程度
100論文: 約4時間、$4.00程度

論文数が増えてもコストは線形に増加するため、大規模な知識ベース構築も現実的です。

Q4: GraphRAGではなくLazyGraphRAGを使うべき？

LazyGraphRAGはMicrosoftが2024年後半に発表した、GraphRAGの軽量版です。

観点	GraphRAG	LazyGraphRAG
インデックス作成	重い（LLMでエンティティ抽出）	軽い（NLPベースの抽出）
コスト	高い（LLM API多用）	低い（LLM使用を最小化）
精度	高い	やや低い
クエリ時	事前構築済みグラフを使用	クエリ時にグラフを動的構築
適用シーン	繰り返しクエリする知識ベース	一度きりの調査

選択の指針：

どちらを選ぶべきか？	GraphRAG	LazyGraphRAG
同じ文書群に繰り返しクエリする	✅	-
高精度な回答が必要	✅	-
知識ベースを長期運用する	✅	-
チームで共有する	✅	-
一度きりの調査・分析	-	✅
コストを最小化したい	-	✅
素早く結果が欲しい	-	✅
文書が頻繁に更新される	-	✅

LazyGraphRAGの試し方（2026年1月時点）：

# GraphRAGと同じリポジトリに含まれています
graphrag query --method lazy \
  --root . \
  "What is the relationship between BERT and GPT?"

注意: LazyGraphRAGは比較的新しい機能のため、APIが変更される可能性があります。本番利用前に最新ドキュメントを確認してください。

Q5: ローカルLLM（Ollama）でも動作する？

はい、動作しますが制限があります。

項目	OpenAI API	Ollama（ローカル）
セットアップ	APIキーのみ	モデルのダウンロード（数GB）
コスト	従量課金	無料（電気代のみ）
速度	高速	GPUがないと遅い
精度	高い	モデル依存（やや低い傾向）
プライバシー	データがOpenAIに送信	完全ローカル処理

Ollama設定例（settings.yaml）：

completion_models:
  default_completion_model:
    model_provider: ollama
    model: llama3.1:8b  # または mistral, mixtral など
    api_base: http://localhost:11434

embedding_models:
  default_embedding_model:
    model_provider: ollama
    model: nomic-embed-text
    api_base: http://localhost:11434

注意: Ollamaでのコミュニティレポート生成は、モデルの出力フォーマットが不安定なため失敗することがあります。その場合は --method fast オプションを試すか、OpenAI APIの使用を検討してください。

Q6: 本番運用ではどのLLMサービスを使うべき？

推奨: Azure OpenAI Service（Microsoft Azure AI Foundry経由）

本記事ではテスト目的でOpenAI APIを使用していますが、本番運用ではAzure OpenAI Serviceの利用を強く推奨します。

Azure OpenAI Serviceを推奨する理由：

観点	OpenAI API	Azure OpenAI Service
データプライバシー	OpenAI社にデータ送信	Azureリージョン内で処理完結
コンプライアンス	SOC 2のみ	ISO 27001, SOC 2, HIPAA, GDPR等
データ保持	30日間保持される可能性	オプトアウト可能、保持なし設定可
SLA	なし（ベストエフォート）	99.9% SLA保証
リージョン選択	不可	日本リージョン（東日本/西日本）選択可
企業契約	クレジットカード払い	Enterprise Agreement対応
監査ログ	限定的	Azure Monitor連携、詳細ログ取得可
ネットワーク	パブリックのみ	Private Endpoint対応

特に研究機関・企業での利用において重要な点：

論文データの機密性
- 未発表の研究データをGraphRAG化する場合、データがどこに送信されるかは重要
- Azure OpenAIはマイクロソフトのモデル改善にデータを使用しないことを明示
学術機関のコンプライアンス要件
- 多くの大学・研究機関はクラウドサービスの利用に厳格なポリシーを持つ
- Azure OpenAIは日本の学術機関向けセキュリティ要件に対応しやすい
コスト管理
- Azure OpenAIは予算アラート、コスト分析がAzure Portal上で容易
- 研究費の執行管理が必要な場合に適している

Azure OpenAI設定例（settings.yaml）：

completion_models:
  default_completion_model:
    model_provider: azure_openai
    model: gpt-4o-mini  # デプロイ名
    auth_method: api_key
    api_key: ${AZURE_OPENAI_API_KEY}
    api_base: https://your-resource.openai.azure.com/
    api_version: "2024-08-01-preview"

embedding_models:
  default_embedding_model:
    model_provider: azure_openai
    model: text-embedding-3-small  # デプロイ名
    auth_method: api_key
    api_key: ${AZURE_OPENAI_API_KEY}
    api_base: https://your-resource.openai.azure.com/
    api_version: "2024-08-01-preview"

Azure AI Foundryについて：
2024年にAzure OpenAI StudioはAzure AI Foundryに統合されました。モデルのデプロイ、プロンプトエンジニアリング、評価がより統合的に行えるようになっています。

Q7: 日本語論文でも使える？

はい、使えます。 ただし以下の点に注意が必要です。

観点	対応状況	備考
Docling	✅ 日本語PDF対応	OCRモードでより高精度
GraphRAG	✅ 日本語対応	プロンプトは英語ベース
エンティティ抽出	△ 英語より精度低下	日本語特有の固有表現に弱い
クエリ	✅ 日本語で質問可能	回答も日本語で返る

日本語論文での精度向上Tips：

settings.yamlでプロンプトをカスタマイズ

extract_graph:
  prompt: "prompts/extract_graph_japanese.txt"

エンティティタイプを日本語研究向けに定義

entity_types:
  - 研究者
  - 研究機関
  - 手法
  - データセット
  - 評価指標

日本語に強いLLMの使用
- GPT-4o（日本語性能が高い）
- Claude 3（日本語対応良好）

GiNZAベースの日本語チャンカーの使用（推奨）

日本語は英語と異なり単語間にスペースがないため、トークンベースのチャンク分割では文脈が不自然に切れる可能性があります。GiNZA（日本語NLPライブラリ）を使った文境界ベースのチャンク分割を推奨します。

GiNZAを使うメリット：

観点	トークンベース	GiNZAベース
文境界認識	❌ 不可	✅ 「。」「！」「？」で正確に分割
形態素解析	❌ なし	✅ 単語単位で分割可能
専門用語保持	△ 分断リスク	✅ 複合語を保持
文脈の一貫性	△	✅ 文単位で保持

GiNZAのインストール：

pip install ginza ja-ginza

カスタムチャンカーの実装例：

japanese_chunker.py

import spacy
from pathlib import Path

# GiNZAモデルをロード
nlp = spacy.load("ja_ginza")

def chunk_japanese_text(text: str, max_sentences: int = 10) -> list[str]:
    """
    日本語テキストを文境界ベースでチャンク分割する
    
    Args:
        text: 入力テキスト
        max_sentences: 1チャンクあたりの最大文数
    
    Returns:
        チャンクのリスト
    """
    doc = nlp(text)
    sentences = list(doc.sents)
    
    chunks = []
    current_chunk = []
    
    for sent in sentences:
        current_chunk.append(sent.text)
        
        if len(current_chunk) >= max_sentences:
            chunks.append("".join(current_chunk))
            # オーバーラップ: 最後の2文を次のチャンクに含める
            current_chunk = current_chunk[-2:] if len(current_chunk) >= 2 else []
    
    # 残りの文を追加
    if current_chunk:
        chunks.append("".join(current_chunk))
    
    return chunks

# 使用例
if __name__ == "__main__":
    sample_text = Path("markdown/japanese_paper.md").read_text()
    chunks = chunk_japanese_text(sample_text, max_sentences=8)
    
    for i, chunk in enumerate(chunks):
        print(f"--- Chunk {i+1} ({len(chunk)} chars) ---")
        print(chunk[:200] + "..." if len(chunk) > 200 else chunk)

GraphRAGとの統合方法：

GiNZAでチャンク分割した結果を個別のMarkdownファイルとして保存し、GraphRAGの入力として使用します。

preprocess_japanese.py

from pathlib import Path
from japanese_chunker import chunk_japanese_text

input_dir = Path("markdown")
output_dir = Path("graphrag_project/input")
output_dir.mkdir(exist_ok=True)

for md_file in input_dir.glob("*.md"):
    text = md_file.read_text()
    chunks = chunk_japanese_text(text, max_sentences=8)
    
    for i, chunk in enumerate(chunks):
        output_path = output_dir / f"{md_file.stem}_chunk{i:03d}.md"
        output_path.write_text(chunk)
        print(f"Created: {output_path}")

言語	推奨チャンク方式	推奨サイズ	理由
英語	トークンベース	1200 tokens	単語境界が明確
日本語	GiNZA文境界ベース	8-10文	文脈・専門用語を保持

GiNZAの特徴：

spaCyベースの日本語NLPライブラリ
形態素解析、係り受け解析、固有表現抽出に対応
学術論文の専門用語も比較的正確に処理
商用利用可能（MIT License）

日本語論文のチャンク分割で起こりがちな問題：

「機械学習を用いた自然言語処理」→「機械学習を用いた自然言」「語処理」と分断
文脈が失われ、エンティティ抽出の精度が低下
対策: GiNZAで文境界を正確に検出し、文単位でチャンク分割する

参考資料

シリーズ記事

📎 すべての記事一覧は著者ページをご覧ください

この記事が役に立ったら、いいね👍とストックをお願いします！

📖 AI for Science に関するご相談は nahisaho@microsoft.com 宛にお願いします。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up