ref-verify

ref-verify — 参考文献ハルシネーションガード

このスキルが防ぐ具体的な失敗は、LLM が要旨に実際に書かれている内容ではなく、学習データから想起した論文の内容を説明してしまうことです。論文に含まれていない知見がその論文に帰属されたり、本文のどこにもない主張の根拠として引用されたりします。一貫して適用するルールは次のとおりです。

論文に関する内容の記述はすべて、取得時点で有効な情報源に基づかなければなりません。要旨レベルの主要な主張には要旨を、メカニズム、実装、手順に関する主張には全文を使い、引用または原文に忠実に言い換えてください。必要な情報源を取得できない場合は、そのことを明確に伝えてください。想起した説明で不足を補ってはならず、話題が一致する要旨をメカニズムレベルの主張の根拠にしてはなりません。

---

モードの決定

作業を始める前にモードを選択してください。選択によって、コストと深さが決まります。

User provides DOI(s) for sanity check?
  └─ ≤10 refs → Quick Screen all
  └─ >10 refs → Quick Screen all; Full Audit only MISMATCH/DEAD results

User says "find papers on X" or "cite papers supporting claim Y"?
  └─ Full Audit (searching from scratch requires content verification)

User says "verify/check my reference list" or pre-submission audit?
  └─ CLI available → Pre-submission sweep (below) first: check-bib, then check-file
  └─ ≤5 refs  → Full Audit all
  └─ >5 refs  → Quick Screen all first; Full Audit MISMATCH/DEAD + any ref
                 cited for a specific factual claim

User is writing inline and adds a single citation from memory?
  └─ Quick Screen minimum; Full Audit if citing for a specific claim

コストが高いのは、情報源の深度まで証拠を取得するフル監査（5 層）です。クイックスクリーンは論文 1 件あたり約 5 秒です。タスクで内容の検証が本当に必要な場合にのみ、フル監査に進んでください。

---

実行エンジン

スキルレベルのワークフローとして、これを使用してください。この経路で MCP を構築したり、必須にしたりしないでください。 CLI は、スキルがターミナルから呼び出せる実行エンジンです。手動プロトコルはフォールバックであり、CLI がまだ対応していない層の正式な情報源です。

CLI の利用可否を確認する

このスキルには独自のエンジンが含まれています。npx skills add は src/ フォルダーをこの SKILL.md の隣にコピーします。DOI に基づく確認の前に、次の順にエンジンを一度解決し、ヘルプを表示した最初のコマンドを使ってください。

1. このスキルに同梱（この SKILL.md と同じバージョン。インストール不要。セットアップ時のネットワーク接続も不要）：

   PYTHONPATH="$SKILL_DIR/src" python3 -m ref_verify.cli --help
   

   $SKILL_DIR は、この SKILL.md を含むフォルダーの絶対パスです（Claude Code ではスキルのベースディレクトリとして表示されます。npx skills add -g でインストールした場合は ~/.agents/skills/ref-verify にインストールされます）。相対パスの src は使用しないでください。作業ディレクトリはスキルのフォルダーではなく、ユーザーのプロジェクトです。Python 3.10 以降が必要です。

2. インストール済みコンソールスクリプト（pip install ref-verify または pipx install ref-verify）：

   ref-verify --help
   

   npx skills add は Python CLI を pip でインストールしないため、これが利用できない場合もよくあります。

3. uv 経由で PyPI から実行：

   uvx --from 'ref-verify>=1.3.2' ref-verify --help
   

以下のコマンドでは同梱版を使用します。エンジン 2 または 3 を使う場合は、PYTHONPATH="$SKILL_DIR/src" python3 -m ref_verify.cli を ref-verify（または uvx 形式）に置き換えてください。エンジンを利用できないことは、検証結果ではありません。3 つすべてが失敗した場合は、以下の手動フォールバックプロトコルに従ってください。CLI を実行したふりをしたり、記憶をもとに結果をでっち上げたりしないでください。

CLI 優先のワークフロー

ユーザーが DOI を提示した場合、または DOI に紐づく要旨が特定の事実に関する主張を裏付けるか尋ねた場合は、まず CLI を使用してください。現在の CLI は、CrossRef のメタデータ検証と、DOI に紐づく要旨の主張チェックに対応しています。主張チェックでは、まず CrossRef を確認し、CrossRef に要旨がない場合は DOI に紐づく OpenAlex、Semantic Scholar、PubMed の順にフォールバックします。

CrossRef メタデータのスクリーニング：

PYTHONPATH="$SKILL_DIR/src" python3 -m ref_verify.cli verify-doi <doi> \
  --title "<provided title>" \
  --first-author <provided-first-author-last-name> \
  --year <provided-year> \
  --json

verify-doi は PASS の場合のみ終了コード 0 を返します。WARN と REJECT の場合は、ゼロ以外の終了コードを返します。 DOI のみを指定した場合、CrossRef で解決できることは確認されますが、メタデータ検証を通過するには不十分です。

結果に応じて、次のように対応してください。

• PASS：メタデータが一致したことを報告し、選択したモードで必要な場合は、引き続きレイヤー 4 の DOI ランディングページ解決とレイヤー 5 の撤回確認を行ってください。
• WARN：メタデータが欠けている、または弱いことを報告し、参照文献を黙って受け入れるのではなく、不足している層を手動フォールバックで確認してください。DOI_NOT_IN_CROSSREF の場合、DOI は CrossRef 以外（arXiv、Zenodo、KISTI）に登録されています。doi.org でタイトルと著者を確認し、DOI が無効だとは決して判断しないでください。
• REJECT：その引用を検証済みとして扱うのを中止してください。不一致を報告し、ユーザーが代替案を明示的に求めていない限り、正しい DOI または引用情報を尋ねてください。

参考文献リストの確認（BibTeX、RIS、またはプレーンテキスト／Markdown 形式の参考文献一覧）。ユーザーから参考文献リストを受け取った場合は、まずこれを実行してから主張を確認してください。

PYTHONPATH="$SKILL_DIR/src" python3 -m ref_verify.cli check-bib <references.bib|.ris|.txt|.md>

ユーザーが読む／共有する資料（アドバイザー、共著者など）を求めている場合は、--report <name>.html（または .md）を追加します。HTML には、まず確認が必要な項目と、それぞれの判定理由が平易な言葉で記載されます。レポートのパスをユーザーに伝えてください。

各結果への対応：

• PASS：参照文献が CrossRef のレコードと一致しています（DOI による一致、または REFERENCE_RESOLVED と resolved_doi を伴う検索による一致）。
• WARN と REFERENCE_UNMATCHED（status: UNVERIFIED）：CrossRef の検索で一致するレコードが見つかりませんでした。未検証として報告し、手動のクイックスクリーンを実施してください。この結果だけを根拠に捏造と判断してはいけません。
• WARN と DOI_NOT_IN_CROSSREF（status: UNVERIFIED）：DOI は別の登録機関（DataCite 経由の arXiv／Zenodo、KISTI、JaLC）に登録されているため、メタデータは比較されていません。doi.org で確認し、無効と判断してはいけません。
• その他の WARN：メタデータの一部が異なる、参照文献の情報が少なすぎて確認できない、または（status: MISMATCH）プレーンテキストの参照文献に記載された DOI が reason に記載された論文のものです。reason を報告し、手動で確認してください。
• REJECT：無効な DOI（DOI_NOT_FOUND）、撤回済み論文（PAPER_RETRACTED）、または別の論文を示す DOI です。検証済みのものとして使うのを中止してください。

DOI の要旨に対する単一の主張の確認：

PYTHONPATH="$SKILL_DIR/src" python3 -m ref_verify.cli check-claim <doi> --claim "<specific factual claim>" --json

--source crossref|openalex|semantic-scholar|pubmed を指定すると、単一のソースを強制的に使用します（CrossRef を経由しません）。これは、単一ソースの障害をデバッグする場合に使用します。

結果への対応：

• ACCEPT：CLI の根拠を引用し、必要な手動での DOI 解決、別ソースによる存在確認、撤回確認の各段階を続けます。
• WARN または PARTIAL：選択した要旨ソースが何を裏付け、何を裏付けなかったかを報告し、さらに確認が必要な段階があれば手動の代替手順を続けます。
• UNVERIFIABLE：試行した CLI ソースから、信頼できる DOI に紐づく要旨の根拠を得られませんでした。主張を却下または裏付け済みとみなすのではなく、以下の手動の代替手順を続けてください。

CLI の ACCEPT は要旨レベルの根拠に限られます。主張に含まれるすべての数値について、単位、符号、方向が同じ要旨の一文で裏付けられていることを意味します。一つの数値でもその文で裏付けられていなければ、別の数値が一致していても ACCEPT にはなりません。主張がメカニズム、実装、手順について述べている場合は、その結果を Full Audit の判定に昇格させないでください。Layer 3 で主張を分類し、まず必要な全文の根拠を入手してください。

JSON 出力では、次のステップを判断するために abstract_source、source_attempts、error_code を使用してください。

• CLAIM_SUPPORTED：要旨に明示的な裏付けが見つかりました。
• CLAIM_NOT_EXPLICIT：要旨は取得できましたが、主張を明示的には裏付けていませんでした。
• CLAIM_AMBIGUOUS：数値的な根拠または文脈はありますが、対応関係が曖昧です。
• NO_ABSTRACT：試行した DOI 紐付け済みソースから要旨のテキストを取得できませんでした。
• DOI_NOT_FOUND：CrossRef と doi.org のどちらも DOI を認識しないか、選択したソースで DOI に紐づくレコードが見つかりませんでした。
• PAPER_RETRACTED：CrossRef がその DOI の撤回通知を掲載しています。要旨を読む前に主張は却下されます。
• DOI_MISMATCH：主要な DOI 紐付け済みレコード、または明示的に選択したレコードが、指定された DOI と一致しませんでした。
• SOURCE_API_ERROR、SOURCE_TIMEOUT、SOURCE_RATE_LIMITED、SOURCE_UNSUPPORTED：ソースの検索に失敗した、タイムアウトした、レート制限を受けた、または使用できませんでした。
• REFERENCE_RESOLVED、REFERENCE_UNMATCHED（check-bib のみ）：DOI のない参照文献が CrossRef のレコードと一致したかどうかを示します。
• DOI_NOT_IN_CROSSREF（verify-doi、check-claim、check-file、check-bib）：DOI は別の登録機関（DataCite、KISTI、JaLC）に存在するため、無効ではなく未検証です。check-claim では、OpenAlex または Semantic Scholar から要旨を取得できた場合は引き続き主張を判定します。取得できなかった場合は、doi.org で文献を確認してください。

CLI は Layer 4 の DOI ランディングページ解決や、2 つのソースによる存在確認の代わりにはなりません。また、CrossRef が撤回通知として記録している撤回しか検出できません。選択したモードでこれらの段階が必要な場合は、手動のプロトコルを続けてください。

提出前の総点検

両方の作業にエンジンを使います。参照文献についてはCrossRefとdoi.orgを、要旨についてはCrossRef、続いてOpenAlex、Semantic Scholar、PubMedを検索し、キャッシュも使用します。これらのためにcurlの呼び出しを手書きしないでください。

1. 参照文献 → check-bib。 参照文献のリストだけを保存します（Referencesセクション、または.bib）。本文の段落を含めると、UNVERIFIEDの行が誤って追加されます。テキスト出力には、参照文献ごとに判定と理由が1つずつ表示されます。--jsonの出力は1回のツール結果には大きすぎるため、ファイルに書き出し（--json > refs-check.json）、分割して読み取ります。
2. 数値を含む主張 → check-file。 claims.jsonlを作成し、数値を含む引用文ごとに{"id", "doi", "claim"}を1つずつ記述します。DOIには、参照文献またはcheck-bibで解決されたDOIを使います。数値、単位、方向を示す語は原稿のとおりに正確に転記します（\SI{172.3}{\joule\per\mole}は172.3 J/molです）。転記時に主張を訂正してはいけません。PYTHONPATH="$SKILL_DIR/src" python3 -m ref_verify.cli check-file claims.jsonlを実行します。テキスト出力には、各主張の判定と一致した要旨の文（Evidence）が表示されます。
3. 各主張は、記憶やラベルだけでなく、その文に基づいて判断します。
   • 値、単位、または方向が異なる場合、ACCEPTであっても原稿の記述は論文の内容を誤って伝えています。その文を引用し、正しい値を示します。
   • 値、単位、方向が一致する場合、引用した要旨が根拠となるため問題ありません（どの判定表でもラベルはWARNのままです）。
   • その文が別のことについて述べている場合、または主張の一部しか扱っていない場合は、要旨がその内容を述べていないと書く前に、要旨全体を確認します（check-claimはpaperの下に要旨全体を出力します）。
4. エンジンが判断できなかった項目（REFERENCE_UNMATCHED、DOI_NOT_IN_CROSSREF、UNVERIFIABLE）だけを手作業で調べます。 Layer 1の情報源とdoi.orgを使います。タイトルのない引用は、著者名と掲載誌に、その引用元の文に含まれるトピックの語句を加えて検索します。該当しそうな記録でも巻またはページが異なる場合、引用の巻またはページが誤っています。メカニズムに関する主張には引き続きLayer 3bが必要であり、モードで必要な場合はLayers 4–5も適用します。

---

クイックスクリーニング — メタデータとDOIの妥当性チェック

ユーザーがDOIまたは完全な引用情報を提示し、妥当性チェックを求めている場合に使用します。

1. CrossRefにアクセスします：https://api.crossref.org/works/{DOI}
2. 返されたタイトルと筆頭著者の姓を、ユーザーの提示内容と比較します。
3. https://doi.org/{DOI}にアクセスし、正しく解決され、該当論文にたどり着くことを確認します。
4. 参照文献ごとに1行で報告します。

Smith et al. (2021) 10.1234/example — PASS (title/author match, DOI resolves)
Jones (2019) 10.5678/other — MISMATCH (CrossRef: Jones & Lee 2019, not Jones alone)
Kim (2023) 10.9999/fake — DEAD DOI

次の場合はFull Auditに進みます：DOIが別の論文に解決される、いずれかの項目が一致しない、またはユーザーが特定の事実に関する主張の根拠として引用している。

---

Full Audit — 文献検索または提出前チェック

次の場合に使用します：主張を裏付ける論文を検索する場合、または最終的な引用文献の総点検を行う場合。

論文ごとに5つのレイヤーすべてを実行します。レイヤーは検出できる項目の順に並んでいるため、先のレイヤーを飛ばしてはいけません。

Layer 1 — 存在確認

2つの情報源をそれぞれ独立して検索します。

• CrossRef：https://api.crossref.org/works?query.bibliographic={title+author}&rows=5
• OpenAlex：https://api.openalex.org/works?search={title+author}&per-page=5
• プレプリントの場合はarXiv：https://export.arxiv.org/api/query?search_query=ti:{title}&max_results=3
• これらの情報源で項目を特定できない場合に限り、Semantic Scholar（共有クライアントにレート制限を適用します）：https://api.semanticscholar.org/graph/v1/paper/search?query={title+author}&fields=title,authors,year,externalIds,abstract&limit=5

タイトルがほぼ一致し、2つの情報源で筆頭著者の姓も一致した場合にのみ、論文の存在が確認されたものとします。

• 2つの情報源で一致 → CONFIRMED
• 1つの情報源で一致 → SINGLE-SOURCE ⚠ — 注意して進め、出力にその旨を記します
• 0件 → NOT FOUND ✗ — ここで終了します。明確に報告し、代替文献を捏造してはいけません

Layer 2 — メタデータ 確認済みの情報源から抽出して照合します。タイトル、著者全員（姓）、年、雑誌の正式名称、DOI、巻・ページを記載します（情報源にない場合は [NOT IN SOURCE] と記載）。情報源によって項目が異なる場合は、両方を示します。片方を黙って選んではいけません。

レイヤー 3 — 内容の追跡可能性 ← 最も重要なレイヤー

ここにこのスキルの中核的な価値があります。目的は、単に「この論文が存在するか」ではなく、「この論文に、引用されている主張が実際に含まれているか」です。

ステップ 0 — 主張を分類します。

情報を取得する前に、検証対象の主張がどの種類に当たるかを分類します。

• 概要・主要な主張 — 通常、抄録に記載される種類の知見（全体的な結果、主要な数値、一般的な結論）。この種類では、抄録のみを根拠とすることが正当な情報源となります。
• メカニズム・実装・手順に関する主張 — 具体的なメカニズム、アルゴリズム、アーキテクチャ、パラメーター、実験手順、対照条件、または要約結果ではなく表・図・方法の節に関連付けられた数値など、何かが「どのように」機能したか、または実施されたかを説明する主張です。論文がこの内容を裏付けていても、抄録には記載されないことがよくあります。見分けるための語句：「メカニズム」「方法」「アーキテクチャ」「アルゴリズム」「実装」「手順」「プロトコル」「パラメーター」「対照群」「アブレーション」「表」「図」、または一段落の要約に収まる範囲を超えた具体的な主張。

主張がメカニズム・実装に関するものであれば、抄録のみの確認では不十分です。抄録が関連する話題を扱っていても同様です。論文の存在と話題の一致を示す証拠として抄録を取得しますが、抄録だけで判定を確定してはいけません。以下のレイヤー 3b に進んでください。

エンジンを使って抄録を取得します（check-claim／check-file は情報源 1～3 と PubMed を試します）。エンジンが利用できない場合、または抄録が見つからない場合は、手動で次の優先順位に従います。

1. CrossRef の生 JSON：https://api.crossref.org/works/{DOI} — abstract フィールドを確認します
2. OpenAlex：https://api.openalex.org/works/doi:{DOI}?mailto={contact_email} — abstract_inverted_index を再構成します
3. Semantic Scholar：https://api.semanticscholar.org/graph/v1/paper/DOI:{DOI}?fields=abstract — abstract を確認します
4. オープンアクセスのフォールバック：https://api.unpaywall.org/v2/{DOI}?email={contact_email} — is_oa と oa_locations を確認します
5. プレプリントの arXiv フォールバック：https://export.arxiv.org/api/query?id_list={arxiv_id}
6. 生命科学・生物学の論文については PubMed Central：https://www.ncbi.nlm.nih.gov/pmc/articles/{PMCID}/

連絡先メールアドレスが必要な API では、{contact_email} を設定から取得した、ユーザーが使用を許可した実在のアドレスに置き換えます。プレースホルダーのアドレスを送信してはいけません。

取得後、抄録に引用対象の具体的な主張が含まれているかを確認します。

• 抄録に主張が明示的に含まれている（原文をそのまま引用する）→ CONTENT: SUPPORTED
• 抄録は関連する話題を扱っているが、具体的な主張には触れていない → CONTENT: PARTIAL — 実際に述べられている内容を引用する
• 抄録が主張に反している → CONTENT: CONTRADICTED — この引用は使用しない
• すべての情報源を試しても抄録にアクセスできない → CONTENT: UNVERIFIABLE — ユーザーが全文を確認する必要がある
• 主張がメカニズム・実装に関するもので、レイヤー 3b のすべての情報源を試しても全文を取得できなかった → CONTENT: ABSTRACT-ONLY — 全文を取得できず、検証不十分。このラベルを SUPPORTED／ACCEPT に格上げしてはいけません。

緩和できないルール：「論文が示す」「実証する」「報告する」と述べる場合は、必要な深さに応じて、取得した情報源のテキストを引用するか、直接言い換えなければなりません。たとえ確信があっても、記憶に基づいて要約することは認められません。

レイヤー 3b — 全文による確認（メカニズム・実装に関する主張のみ）

ステップ 0 で主張がメカニズム・実装に関するものと分類された場合、または抄録の要約レベルを超える具体的な主張に対する抄録の判定が PARTIAL の場合は、必ず実施します。抄録から直接 CONTENT: SUPPORTED と判定された概要の主張に限り、省略できます。 以下の優先順位で論文本文を取得し、最初に成功した時点で終了してください。

1. ローカルのZotero PDF — Zoteroライブラリが設定されている場合は、データベースを検索してこのDOIを確認し、添付ファイルキーを特定して、リンク先のPDFを読み込みます。一般的なデフォルトのパスは~/Zotero/zotero.sqliteで、添付ファイルは~/Zotero/storage/{key}/にありますが、決めつけずに実際のパスを特定してください。
2. research-wikiボルト — research-wikiスキルを利用できる場合は、設定済みのボルトを検索して、すでに取り込まれている全文を探してください。マシン固有のボルトパスを決めつけないでください。
3. オープンアクセスのリンク — 実際の全文を特定して取得します（利用可能かどうかを示すフラグだけでは不十分です）。
   • Unpaywall：https://api.unpaywall.org/v2/{DOI}?email={contact_email} → best_oa_location.url_for_pdf（または任意のoa_locations[].url_for_pdf）を取得します。
   • arXiv：https://export.arxiv.org/api/query?id_list={arxiv_id} → <summary>フィールドだけではなく、論文全文を取得します。
4. 取得失敗 — 上記のいずれでも読める全文が得られない場合、抄録だけで十分だと見なさないでください。上記で定義されているCONTENT: ABSTRACT-ONLYラベルを適用してください。

全文を取得できた場合は、主張を支持、一部支持、または否定する箇所を引用してください。メカニズム／実装に関する主張の場合、CONTENT: SUPPORTEDとするには全文からの引用が必要です。抄録で話題が一致するだけでは不十分です。

レイヤー4 — DOIの解決

https://doi.org/{DOI}を取得します。ランディングページが対象の論文と一致することを確認してください。タイトルと巻号を含むURLスラッグから403（ボットによるブロック）が返された場合、リンク切れではありません。ペイウォールによるものとして記録してください。無関係なページへのリダイレクトは重大な失敗です。

レイヤー5 — 撤回

"{first author last name}" "{journal name}" retractionを検索し、DOIのランディングページに撤回のバナーがないか確認してください。撤回された論文を主要な出典として使用してはいけません。

---

出力形式

クイックスクリーニング：参照文献ごとに1行（上記を参照）。

投稿前の確認：判断を先に示します。問題ごとに、引用された参照文献、問題点、根拠（エンジンの理由、CrossRefの記録、または抄録からの引用文）、修正案を示してください。次に、未確認の項目（学位論文、インデックス未登録のプレプリント）を「自動では確認できませんでした — ご自身で調べてください」という別の短いリストにまとめます。ツール、再試行、レート制限についての説明は不要です。

詳細監査：論文ごとにカードを1枚作成し、その後に要約表を示します。

REFERENCE AUDIT
────────────────────────────────────────────────
Paper:   [Title from live source — not from memory]
DOI:     [DOI] — [✓ Resolves | ✗ Dead | ✗ Wrong paper | ⚠ Paywalled-403]
Authors: [Full list from CrossRef/OpenAlex/S2]
Year:    [Year] — Source: CrossRef | S2 | arXiv
Journal: [Full name]

EXISTENCE:  ✓ Confirmed (sources) | ⚠ Single-source | ✗ Not found
METADATA:   ✓ Consistent | ⚠ Discrepancy: [field: value-A vs value-B]
CONTENT:    ✓ Supported — "[verbatim excerpt — abstract for topline, full text for mechanism claims]"
            ⚠ Partial — source says: "[what it actually says]"
            ⚠ Abstract-only — mechanism/implementation claim, full text unavailable after Zotero/research-wiki/OA attempts
            ✗ Contradicted | — Unverifiable (tried CrossRef/OpenAlex/S2/Unpaywall/arXiv/PubMed)
RETRACTION: ✓ None found | ✗ Retracted

VERDICT: ACCEPT | WARN | REJECT
Reason: [one sentence — what's missing or wrong]
────────────────────────────────────────────────

CONTENTフィールドには、逐語的な抜粋か、ABSTRACT-ONLYやUNVERIFIABLEなどの明示的な非支持ステータスのいずれかを必ず記載してください。記憶をもとに書いた要約は決して記載しないでください。

ACCEPT：2つの出典で確認済みであり、DOIが正しい論文に解決され、必要な出典の深さで内容が支持されており（概要レベルの主張には抄録、メカニズム／実装／手順に関する主張には全文）、撤回されていない状態です。 WARN：解決可能な問題がある状態です。出典が1つだけ、内容が部分的にしか一致しない、すべての代替手段を試しても抄録にアクセスできない、または（メカニズム／実装に関する主張の場合）Zotero／research-wiki／OAの代替手段を試しても全文にアクセスできない場合が該当します。全文にアクセスできない場合は、要約表にABSTRACT-ONLYラベルを付ける必要があります（例：WARN (ABSTRACT-ONLY: mechanism claim, PDF unreachable)）。この場合、決してACCEPTとして報告してはいけません。ユーザーがフラグの付いた項目を確認すれば、安全に使用できます。 REJECT：DOIが無効、または別の論文に解決される、論文がどこにも見つからない、内容が否定されている、または撤回が確認された状態です。

すべてのカードの後に要約表を記載します。

SUMMARY
────────────────────────────────────────────────
1. Smith et al. (2021)  — ACCEPT
2. Kim & Park (2019)    — WARN (abstract unverifiable; try PMC or institutional access)
3. Zhang (2023)         — REJECT (DOI resolves to different paper)
────────────────────────────────────────────────
X / Y verified.  Z need attention.

---

ハルシネーション防止ルール

• DOIを記憶から思い出してはいけません。CrossRefまたはOpenAlexから取得してください。
• 引用に必要な深さのソーステキストを取得していない場合、論文の内容を説明してはいけません。
• 不足しているメタデータを推測やパターン照合で補ってはいけません。
• 2つのソースの内容が異なる場合は、両方を示してください。黙って一方を選んではいけません。
• 主張に必要な深さのソースに、あらゆるフォールバックを試してもアクセスできない場合は、上記の定義に従ってUNVERIFIABLEまたはABSTRACT-ONLYと記してください。記憶に基づく説明で代用してはいけません。
• メカニズムや実装クラスに関する主張を、要旨のトピックが一致することだけで判断してはいけません。Layer 3b経由で全文を取得するか、ABSTRACT-ONLYと記してそこで止めてください。

---

エッジケース

プレプリント版と出版版：両方のDOIを記録し、引用には出版版を優先してください。バージョン間でタイトルが変更されている場合は、その旨を記してください。

著者名の表記揺れ：「J. Smith」と「John Smith」などは、フラグを立てても統合しないでください。ユーザーに確認してください。

会議録：CrossRefに巻やページが記載されていないことがよくあります。推測せず、[NOT IN SOURCE]と記してください。

レート制限（HTTP 429、例：Semantic Scholar）：429は、どちらの判断を裏付ける証拠にもなりません。他のソースを基に判断してください。項目の判断がつかない場合に限り、429について言及してください。また、429を理由に判定を弱めてはいけません。