[scope] PDF の内容操作 (extract / OCR / 要約) は in-scope か out-of-scope か

[sotashimozono]

Question

PDF の 内容 に対する操作 (text 抽出 / OCR / 要約 / annotation 抽出) を doiget が提供すべきか？

Background

論文 workflow は大きく 2 段階:

1. 検索 + ダウンロード: DOI/arXiv id → PDF + メタデータ
2. 内容理解: PDF → 全文 / 章立て / 引用抽出 / 要約 / Q&A

doiget は (1) に focus してきた。但し agent 経由では (2) も求められがち。

Options

A. Out of scope (推奨)

• doiget は (1) only。clean な責任分担
• (2) は専用ツールに委譲: paper-qa / marker / surya / mineru / openparse / unstructured.io
• doiget は store API を提供して downstream tool が PDF path を消費

B. 最小限の text 抽出のみ in scope

• doiget extract <ref> で plain text dump
• pdf-extract crate か pdfium-render
• OCR / 要約はせず

C. Full scope (extract + OCR + summarize)

• LLM による要約まで含める
• doiget が GPT/Claude API key を持つ
• 機能爆発、product 焦点ぼやける

Recommendation

A (out of scope)。理由:

• 「論文の検索ダウンロード」が souta 自身の言うとおり主眼
• 内容操作は別エコシステム (paper-qa が dominant) が既にある
• doiget が strong product になるには 何をやらないか の決定が大事
• store 経由で chain 可能: doiget fetch X.doi && paperqa ask -p ~/papers/X.pdf "..."

ただし MCP tool として paper_pdf_path(ref) -> Path のような PDF パス公開 tool は提供価値あり (agent が他ツールに渡せる)。

Decision

???

[sotashimozono]

Filed as external review by Claude (Anthropic, AI agent operating under souta's GitHub auth). Reviews #16 in parallel and folds its tightening into this scope decision.

立場

本文 Recommendation A (out of scope) を 強く支持し、永続化を推奨。

加えて、 #16 の posture tightening と整合させると、PDF 内容操作を out of scope にする理由が legal の側 にも追加される (本文では主に "product focus" 観点だった)。

追加: 内容操作 in-scope の legal リスク (本文に欠けている analysis)

doiget が PDF を fetch して そのまま blob として store/return する限り、 doiget の責任は「access の automation」に閉じる。 #16 posture が成立するのはこの構造があるから。

但し、PDF を 解析して text / 章立て / 引用 / 要約 を生成して output する と、以下の posture grey zone が生じる:

1. Derivative work 生成 — paywalled paper の本文を抽出し agent / CLI に出力する行為は、生成物が "自分のネットワーク内 access" の copy ではなく 派生物 になる。fair use / 著作権法 第 30 条の 4 (情報解析目的) 内に収まるとは限らない (特に要約は表現性のある編集)
2. Tool neutrality framing の崩壊 — [legal] Legal posture, tool neutrality framing, and required safeguards #16 の "general-purpose automation tool" 主張は、 tool が content を直接処理 し始めた瞬間に弱くなる。 ブラウザ vs PDF reader の差。 doiget が browser 側 (fetch のみ) なら neutrality 主張が立つが、 reader 側 (内容解析) に踏み込むと立ちにくくなる
3. OCR / 要約の output 配信責任 — agent 経由で第三者に渡る場合、 doiget は配信経路の一部とみなされうる
4. TDM source の二次利用制約 — Elsevier / APS の TDM ToS は「取得した PDF からの 派生コンテンツの 第三者送信」に制限がかかるケースがある。 doiget が要約を MCP 経由で agent に返す = TDM 契約 ToS 違反を facilitate する可能性

本文 Recommendation A は product focus 上の正解 だが、 #16 の posture を維持するためにも legal 上の必要条件 でもある、と reviewer は判断。

paper_pdf_path tool の wording を厳密化

本文末尾で "PDF パス公開 tool は提供価値あり" とあるが、 MCP tool として exposed する際の wording を厳密化すべき:

paper_pdf_path(ref: String) -> Option<Path>
  description: "Returns the local filesystem path to the cached PDF for
                the given DOI / arXiv id, if doiget has fetched it.
                Does NOT read, parse, or transmit the PDF content.
                Downstream tools (paper-qa, marker, etc.) are responsible
                for any content processing the user has authorized."

description 文言を docstring に焼き込み、 agent / user が「doiget は path を返す、 本体には触らない」と理解できる状態にする。 LLM が agentic loop で「ついでに要約させて」と PDF を読んじゃう挙動 (= doiget が間接的に責任を負う構造) を防ぐ。

chain pattern の official documentation

reviewer 推奨: docs/INTEGRATION/chain-with-paperqa.md のような chain pattern doc を出して、 「doiget は (1) fetch、 paper-qa / marker / unstructured.io 等が (2) 内容処理」を 明示的な architectural boundary として公開する。

agent → doiget fetch_paper(ref) → path
agent → paper-qa --pdf path "question" → answer

これは:

• doiget の scope を README とは別に technical doc で reinforce
• user が "doiget 1 個でぜんぶできるべき" と誤解するのを防ぐ
• Sub-agent harness (Claude Code 等) で composition pattern として教えやすい

永続的 out-of-scope marker

本文の Decision を一過性ではなく 永続化 する仕組みを推奨:

• docs/SCOPE.md に "Permanent non-goals" セクションを置き、 PDF 内容処理 (extract / OCR / summarize / annotation extraction / citation parsing from PDF text) を列挙
• このリストは roadmap discussion で覆されるべきではなく、覆すには「scope reopening discussion」を新規 file 起こす必要がある、と meta-rule を書く
• contributor が "extract 機能つけたい" PR を出した場合、このリストを引用して reject する rationale が一貫する

Open questions (reviewer 追加)

1. PDF metadata (title / authors) を PDF 自体から抽出するのは scope 内? (Crossref で取れる場合は不要だが、 arXiv で metadata 不足な場合に PDF metadata を補助的に読むのは technical には小さい — reviewer 推奨: それも out of scope、 metadata 不足は そのまま不足として返す)
2. PDF size / page count のような content に触れない physical attribute は info に含めるか? (fstat レベルなら scope 内、 PDF parsing が要るなら scope 外)
3. paper_pdf_path が返す path を、 agent が読めない (= permission 制御で agent に渡したくない) ケースの API 設計 — Phase 3 MCP tool spec で議論

Reviewer Decision proposal

Decision: A (Out of scope)。 Permanent non-goal として docs/SCOPE.md に明文化。

• paper_pdf_path tool の docstring に "Does NOT read, parse, or transmit content" を明記
• docs/INTEGRATION/chain-with-paperqa.md で chain pattern を official document 化
• PDF metadata / fstat レベル attribute も content scope に入る限り out of scope
• "scope reopening" を別途新 Discussion 必須にする meta-rule

最終 Decision 権は author に留保。

---

Reviewer: Claude (Anthropic). Filed 2026-05-05.