Zoteroを開いて、ちょっと眺めてみてください。
1,000本の文献。PDFはすべてローカルに保存され、メタデータは整然と整理され、タグも付いている。この文献ライブラリを作るのに何年もかかりました。
今、大規模言語モデルによるコード生成に関するサーベイ論文を書こうとしています。Google Scholarを開いて検索を始めます。
なぜZoteroで探さないのか？自分が何をダウンロードしたか覚えていないからです。Zoteroは文献管理ツールです——タイトル、著者、年号を管理するものであって、論文の内容ではありません。「few-shot promptingがコード生成に与える影響を議論している文献はどれか」と聞くことはできません。フィールドでフィルタリングするだけです。
これは大規模な文献ライブラリを持つすべての研究者が直面する問題です：大量の資料を持っていても、ないも同然。
従来のワークフローにある4つの壁
研究作業はおおまかに4つのフェーズに分かれ、それぞれに独自の摩擦があります。
文献検索：何をすでにダウンロードしたか覚えていないため、Google ScholarやSemantic Scholarで繰り返し検索します。見つけた後で3ヶ月前にすでにダウンロードしていたと気づきます。
読んで選別する：関連文献を見つけても、どの章が自分の求める具体的な問題を扱っているかわかりません。PDFを開いてctrl+Fするか、最初から読み流すしかありません。
ノート整理：ノートはNotion、Zoteroのアノテーション、様々なPDFのマークアップに散らばっています。統一された視点がありません。
サーベイを書く：ある主張をするとき、どの文献が支持しているかわかっていても、引用のために原文を手作業で探し、正確な言葉、ページ番号、論証ロジックを確認しなければなりません。
この4つの壁が重なると、文献調査の執筆効率は非常に低くなります——努力が足りないからではなく、ツール自体の構造的な限界からです。
別のアプローチ：AIに文献の中で直接探させる
Linkly AIの核心的な考えは：文献を選別してからAIに渡すのではなく、研究者が自由にファイルキャビネットを閲覧するように、AIにあなたの文献を自由に閲覧させる。
各論文に構造化された「カード」（Outline Index）を作成し、AIが3つのツールを使ってローカル文献ライブラリに段階的にアクセスできるようにします：
- search — 文献を検索し、関連ファイルのリストと要約を返す
- outline — 論文の章構造を見て、関連する段落を素早く特定する
- read — 特定の章の原文を精読する
MCPプロトコルを通じて、ClaudeやCursorなどのAIツールがこれらの3つのツールを直接呼び出せます。質問するだけで、AIが何を検索し、何を読み、どれだけ読むかを自分で決めます。
この技術設計の原理については、Outlines Index技術原理を参照してください。
文献ライブラリの構築：5分で設定
ステップ1：PDFを統一フォルダにエクスポート
Zoteroでは、添付ファイルを一括エクスポートするか、ストレージディレクトリを直接見つけることができます（ZoteroはデフォルトでPDFを~/Zotero/storage/に保存し、論文ごとにサブフォルダを作成します）。すべてのPDFを~/research-papers/などの統一ディレクトリに整理することをお勧めします。
ステップ2：Linkly AIでインデックスを構築
Linkly AIをダウンロードしてインストール後、Linkly AIを開いて文献フォルダを選択し、インデックス構築を開始します。バックグラウンドで自動的に以下が実行されます：
- BM25全文インデックス（1〜3分；完了後すぐにキーワード検索が使用可能）
- Outlineインデックス（各PDFから章構造を抽出）
- ベクトルセマンティックインデックス（完了後、クロスランゲージのセマンティック検索をサポート）
ステップ3：AIアシスタントでMCPを設定
MCP設定ドキュメントに従って操作します——約5分で完了します。完了後、AIアシスタントがローカル文献ライブラリにアクセスできるようになります。
動作確認：AIアシスタントに直接「コンピュータでTransformerのアテンションメカニズムに関する知識を検索して」と聞いてみてください。文献ライブラリから関連文献のリストが返ってきたら、設定成功です。
実際の会話例
設定が完了した後の実際の使用体験をご紹介します。
あなた：この文献群に、Transformerのfew-shot学習シナリオでの限界について議論しているものはありますか？
AIアシスタント（操作開始）：
まず関連文献を検索します：
search("transformer few-shot learning limitations")
Found 8 results:
#1 Few-Shot Learning with Transformers: A Survey
doc_id: 2847 | type: pdf | words: 18,400 | lines: 412
has_outline: yes | relevance: 0.94
snippet: "While transformers have demonstrated strong few-shot capabilities,
they face significant challenges including..."
#2 Meta-Learning for Low-Resource NLP Tasks
doc_id: 1923 | type: pdf | words: 9,200 | lines: 218
has_outline: yes | relevance: 0.87
snippet: "Transformer-based models require substantial prompt engineering
to achieve competitive few-shot performance..."
#3 Scaling Laws and Few-Shot Performance in Large Language Models
doc_id: 3341 | type: pdf | words: 22,100 | lines: 489
has_outline: yes | relevance: 0.81
snippet: "Despite impressive few-shot results, we identify three systematic
limitations in transformer architectures..."
... (関連度の低い5件の結果)上位3件が最も関連性が高いです。それらの章構造を確認します：
outline(2847, 1923, 3341)
[doc_id: 2847] Few-Shot Learning with Transformers: A Survey
[2] Background [L18-67, 50行]
[2.1] Transformer Architecture Overview [L18-34]
[2.2] Few-Shot Learning Paradigms [L35-67]
[3] Capabilities and Benchmarks [L68-198, 131行]
[4] Limitations and Challenges [L199-312, 114行]
[4.1] Data Efficiency Constraints [L199-231]
[4.2] Distribution Shift Sensitivity [L232-271]
[4.3] Prompt Sensitivity [L272-312]
[5] Future Directions [L313-390, 78行]
[doc_id: 1923] Meta-Learning for Low-Resource NLP Tasks
...
[3] Transformer-Specific Challenges [L89-156, 68行]
[3.1] Attention Mechanism Limitations [L89-118]
[3.2] Token Representation in Low-Resource Settings [L119-156]
...
[doc_id: 3341] Scaling Laws and Few-Shot Performance...
...
[4] Systematic Limitations [L201-334, 134行]
[4.1] Memorization vs. Generalization [L201-245]
[4.2] Context Length Constraints [L246-289]
[4.3] Task Format Sensitivity [L290-334]
...1本目の第4章と3本目の第4章が限界について直接議論しています。これらのセクションを精読します：
read(2847, offset=199, limit=114)
read(3341, offset=201, limit=134)AIアシスタント（回答を提供）：
あなたの文献ライブラリにある3本の文献に基づき、few-shot学習シナリオにおけるTransformerの限界は主に以下の点に集中しています：
1. プロンプト感度（Prompt Sensitivity）
[Few-Shot Learning with Transformers, §4.3]の研究では、同じタスクに異なる形式のfew-shotサンプルを使用すると、精度の差が15〜30%に達することが分かりました。これはfew-shotの性能がプロンプト設計に強く依存し、再現性が低いことを意味します。
2. データ効率の制約
[同上, §4.1]は、Transformerが少数のサンプルから学習できる一方で、そのデータ効率はfew-shot専用に設計された手法（MAMLなど）を大きく下回ると指摘しています。特に極端な低リソースシナリオ（1〜5サンプル）で顕著です。
3. 分布シフト感度
[Scaling Laws, §4.1]の実験から、few-shotシナリオのTransformerは真の汎化能力よりも訓練データのパターン記憶に依存する傾向があり、分布がシフトしたテストセットで顕著な性能低下をもたらすことが示されています。
これらの問題について3本の文献の実験設定をさらに詳しく比較しましょうか？
このプロセス全体を通じて、AIアシスタントは自律的に3回のツール呼び出しを行いました：search → outline（3本並行） → read（2つのターゲットチャプター）。あなたは1つ質問するだけで、精確な引用元付きの回答が得られました。
高度な使い方
基本的な使い方に慣れたら、より複雑なことができます。
文献横断比較
RLHFに関するこれら5本の文献は、その限界についての評価において
どんな共通点と相違点がありますか？
各文献の具体的なセクションを引用して説明してください。AIアシスタントは各文献のoutlineを呼び出して限界に関するセクションを見つけ、それぞれをreadして総合的な比較を行います。
方法論の抽出
私の文献ライブラリでコントラスト学習（contrastive learning）を使用した
すべての論文を見つけ、エンコーダアーキテクチャ、データセット、
batch sizeを含む実験設定を列挙してください。AIアシスタントはまずsearchを行い、マッチした文献に対してoutlineを呼び出して実験セクションを見つけ、readして具体的なパラメータを抽出します。
サーベイ執筆補助
私の文献ライブラリにあるアテンションメカニズムの進化に関する文献に基づいて、
時系列で整理した800字程度の文献サーベイの初稿を書いてください。
各主張には文献引用を付けてください。これが最も価値の高い使い方です。AIアシスタントは能動的に検索し、読み、統合して、一般的な知識から架空の引用を作るのではなく、真の引用元を持つ初稿を提供します。
重要な注意事項
このワークフローの核心的な価値は：AIアシスタントが読むのはあなたの文献ライブラリに実際に存在する文献であり、引用するのはローカルファイルにある原文です。 読める実際のテキストがあるため、引用を捏造することはありません。
これはAIアシスタントに直接サーベイを書かせることとは根本的に異なります——後者は原文を照合するテキストがないため、しばしば架空の引用（「ハルシネーション」）が発生します。
もちろん、AIアシスタントの要約や総合には誤りが含まれる可能性があります。最終的な引用の前に、原文に戻って重要な主張を確認することをお勧めします。
学術研究だけではない
最後に触れておく価値があること：このワークフローは学術文献だけに限りません。
大量の参考資料を管理する必要があるあらゆる場面で適用できます：
- 弁護士：判例ライブラリ、法規テキスト、契約書テンプレート
- ジャーナリスト：インタビューの書き起こし、業界レポート、背景資料
- コンサルタント：業界調査レポート、クライアントの過去の文書、方法論ドキュメント
- プロダクトマネージャー：競合分析、ユーザーリサーチレポート、内部文書
本質的に、このワークフローはすべての分野で同じ問題を解決します：大量の既存資料があるのに、必要なときにはいつも一から探し始めている。
始める：クイックスタート — インストールから最初の検索まで、約10分。
Linkly AI チーム制作。