verify-citations

引用の検証

参考文献リストのためのハルシネーション防止ゲートです。.bib ファイルを受け取り、実際の学術インデックス（Crossref、DBLP、Semantic Scholar、arXiv、DataCite）で各エントリーを検証し、エントリーごとに VERIFIED、MISMATCH、UNRESOLVED（捏造の可能性あり）、または RETRACTED の判定を出します。投稿論文に捏造された引用が一つあるだけで、査読、あるいは評判を損なう可能性があります。ここでは厳密に確認してください。

解決できることは必要条件ですが、十分条件ではありません。 識別子が解決できても、そのエントリーが実在するレコードを指していると分かるだけで、名前が示す著作物の正しい版であることや、独自に追加した参考文献が話題に関連していることまでは証明されません。そのため、このゲートでは解決確認に加えて、捏造を伴わない2つのヒューリスティックを用います。正規版チェックでは、同じタイトルのものが、たとえば会議論文と後のRFC／技術報告書／プレプリントの両方として存在する場合、引用数とともに候補を示し、その分野で引用されている成果物を引用できるようにします。また、オプトインの関連性ゲートでは、追加した参考文献が話題にどの程度適合するかをスコア化し、適合度が低いものを人手による確認のためにフラグ付けします。さらに、権威あるインデックスにアクセスできない場合、実行結果はクリーンな PASS ではなく、必ず PARTIAL-PASS を報告し、実行されなかったチェックを明示します。これにより、「確認できなかった」が「確認済みで問題なし」と誤認されることはありません。

使用する場面

• ユーザーが引用／参考文献／参考文献リスト／.bib ファイルの検証、確認、妥当性チェック、監査を求めた場合。
• 執筆スキル（draft-related-work、literature-review、write-rebuttal など）が引用を追加または編集した場合、その作業を完了とする前にこのゲートを実行します。
• preflight-check／投稿、カメラレディ版の作成、arXiv へのアップロードの前。
• ユーザーが AI 生成の参考文献を疑っている場合（「これらの論文は実在しますか？」）。

入力

• .bib ファイル（ユーザーが指定したパス、またはファイルを検索します。メインの .tex と同じ場所にある *.bib、あるいは \bibliography{...}／\addbibresource{...} で指定されたファイル）。
• CONTACT_EMAIL 環境変数 — 実在するメールアドレスを指定します。API プロバイダーがブロックせず連絡できるよう、User-Agent に含めます。未設定の場合はユーザーに尋ねてください。決して作り出してはいけません。
• 任意の S2_API_KEY — Semantic Scholar の専用レート枠を利用します（共有の匿名枠は負荷が高いと 429 を返しますが、スクリプトは自動で待機し、他のプロバイダーにフォールバックします）。

プロセス

1. チェッカーを実行します。 決定的な処理はスクリプトに任せます。エントリーを手作業や記憶で検証してはいけません。

   export [email protected]   # ask the user
   python3 scripts/check_bibtex.py path/to/refs.bib --json /tmp/citecheck.json
   

   便利なオプション：

   • --offline — 解析と重複／静的チェックのみを実行します（ネットワークを使用しません。ユーザーが接続できない場合や構造上のチェックだけを希望する場合に使用します）。
   • --key smith2024 — 修正後に単一のエントリーを再チェックします（繰り返し指定可能）。
   • --no-retraction-check — 非常に大きなファイルでリクエスト数を半減します。最終的な投稿前の実行では、撤回チェックを必ず有効にしてください。
   • --strict — 警告に加えて PARTIAL-PASS の場合もゼロ以外の終了コードを返します（CI ゲートモード：インデックスにアクセスできなかったゲート実行は、実行されていないものとして扱います）。
   • --refresh — .cache/ にある24時間のレスポンスキャッシュを無視します。
   • --thesis-file thesis.txt --core-key dean2008 --core-key vaswani2017 — 独自に収集した追加文献に対して関連性ゲートを有効にします。プレーンテキストの論文テーマ／要旨と、主要文献であることを確認済みのキーを指定します。話題との適合度が低いエントリーには、確認用の LOW_RELEVANCE フラグが付きます。別のスキル（draft-related-work、literature-review）が参考文献を追加し、適切な追加文献と無関係なものを区別する必要がある場合に使用します。
   • --no-canonical-instance — CANONICAL_INSTANCE による誤った成果物のチェックに使う、同一タイトルの追加検索をスキップします（デフォルトでは有効です）。
   • --no-soft-fail — インデックスにアクセスできない場合、PARTIAL-PASS に移行せず、直ちに中断します（終了コード 1）。
   • --self-test — ENTRY_TYPE_MISMATCH、HTTP のリトライ上限到達、PARTIAL-PASS の JSON レポートを対象とする、同梱のオフライン回帰テストを実行します（ネットワーク不要、.bib 不要）。テストが成功すると終了コード 0 を返します。 終了コード：0 は問題なし、2 は問題あり、1 は運用上の失敗（ファイル不正、ネットワークなし、CONTACT_EMAIL が未設定）です。原因を修正してください。チェックをスキップしてはいけません。50 件のファイルの場合、所要時間は約 2～4 分です。スクリプトは設計上、ホストごとに最大 1 リクエスト／秒に制限されています。並列実行したり、この節度ある制限を回避したりしないでください。

2. すべてのフラグをトリアージします。 各フラグの意味、既知の誤検出（オンライン版と印刷版の年の 1 年違い、会場名の別名、arXiv 版と出版版、著者リストの省略）、それぞれに対する具体的な修正方法については、references/triage-guide.md をお読みください。重要度の概要は次のとおりです。

   フラグ	重要度	意味
   UNRESOLVED / DOI_NOT_FOUND / ARXIV_NOT_FOUND	ERROR	いずれのインデックスでも見つかりません — 捏造の可能性があります
   TITLE_MISMATCH / AUTHOR_MISMATCH / YEAR_MISMATCH	ERROR	識別子が別の論文を指しているか、メタデータが誤っています
   RETRACTED	ERROR	この DOI について撤回通知があります
   DUPLICATE_KEY / DUPLICATE_DOI / DUPLICATE_TITLE	ERROR	同じ論文またはキーが重複しています
   MALFORMED_DOI / MALFORMED_ARXIV_ID	ERROR	識別子として有効な形式ではありません
   POSSIBLE_ID_TYPO / MISSING_DOI / VENUE_MISMATCH / AUTHOR_LIST_DIFFERS / TITLE_PARTIAL_MATCH / NOT_IN_INDEXES / EXPRESSION_OF_CONCERN	WARN	実在する論文ですが、エントリに不備があります — 修正するか、理由を示してください
   ENTRY_TYPE_MISMATCH	WARN	BibTeX のタイプが解決されたレコードと矛盾しています（例：ジャーナル論文や単行本が @inproceedings として記載されている、booktitle にジャーナル名や出版社名が記載されている、または @inproceedings に journal= が含まれている） — 正規の type フィールドに基づいてタイプを設定してください
   CANONICAL_INSTANCE	WARN	解決できましたが、フィールドが引用しているのは同じ著作物の別の成果物です — 正規の版を選んでください
   LOW_RELEVANCE	WARN	解決できましたが、論文とのトピック上の関連性が低いと評価されました — 重要な根拠になっているか確認し、自動削除はしないでください
   UNVERIFIABLE_TYPE / RESOLVED_VIA_SEARCH / HAS_CORRECTION / RELEVANCE_OK / CHECK_SKIPPED	INFO	手動で判断する際の参考情報

3. 正規レコードに基づいてのみ修正します。 不備のあるエントリは、権威あるソース（DBLP の .bib エンドポイント、または doi.org のコンテンツネゴシエーション）から取得した BibTeX に置き換えてください。正確なコマンドは references/triage-guide.md を参照してください。メタデータを記憶に頼って再入力してはいけません。それが、幻覚が「修正」として紛れ込む原因です。プロバイダーの詳細、各インデックスが何を権威ある情報としているか、会場名の別名に関する問題については、references/verification-sources.md を参照してください。

4. 修正できないものはエスカレーションします。 UNRESOLVED の各エントリについて、根拠をユーザーに示し、次のいずれにするか尋ねてください。保持する（ユーザーが信頼する手動の情報源を提示）、修正する（正しい参考文献をユーザーが提示）、または削除する（\cite も削除し、前後の文章も調整する）。黙って判断したり、黙って削除したり、似ているだけの別の論文に差し替えたりしてはいけません。

   CANONICAL_INSTANCE と LOW_RELEVANCE（どちらも WARN）については、references/triage-guide.md と references/relevance-gate.md を参照してください。これらはコパイロット向けのプロンプトであり、自動操縦の処理ではありません。代替の成果物や関連性の低いスコアを示し、ユーザーに判断してもらってください。スクリプトの語彙的な関連性スコアは決定論的な代替指標です。埋め込みモデルを利用できる場合は、助言する前に自分でアブストラクトの埋め込み類似度を計算し、より確かな判断材料を得てください。詳しくは relevance-gate のリファレンスを参照してください。成果物を自動で差し替えたり、関連性の低い参考文献を自動で削除したりしてはいけません。

5. 終了コードが 0 になるまで再実行します（または、残るフラグについてユーザーが明示的に承認するまで再実行します）。修正したエントリだけを --key で再確認してから、最後に全件を一度チェックしてください。インデックスに到達できず PARTIAL-PASS となった場合は完了ではありません。チェックをクリーンと宣言する前に、接続が復旧してからスキップされたチェックを再実行してください。

6. 報告。 スクリプトは、正規の VERDICT-LINE:（判定と未加工の件数 — 検証済み数、エラー数、警告数、スキップ数 — に加え、フラグ別の WARN 内訳）を出力し、同じ文字列を JSON の verdict_line として書き込みます。その行を一字一句そのまま要約に、また作成する README やステータス行にもコピーしてください — 記憶を頼りに再構成したり、丸めたりしないでください。その前後に、適用した修正の一覧（変更前 → 変更後）、ユーザーが下した判断、ユーザーが現状のまま受け入れたフラグ、ユーザーの判断を仰ぐために提示した誤った成果物／関連性の低い項目を記載してください。この実行結果が別のスキルの出力を左右する場合は、同じ verdict_line を変更せずに引き継いでください。PARTIAL-PASS を「合格」に格上げしたり、「PARTIAL-PASS, 11 WARN, 1 skipped」を「検証済み、エラー 0 件」にまとめたり、受け入れられることやレビューで問題がないことを約束したりしてはいけません。

出力

• stdout に出力されるスクリプトのエントリーごとのレポート。末尾には、変更せずに再掲する正規の VERDICT-LINE: が含まれます。また、--json を指定した場合は、呼び出し元のスキルが利用できる、エントリーごとのステータスとフラグ、解決済みの DOI／URL、同じ verdict_line、summary.warnings_by_flag の件数を含む機械可読レポートも出力されます。
• 正規レコードに基づいて修正を適用した .bib（ユーザーの承認を得たうえで編集）と、1 行目に変更せずそのまま記載した VERDICT-LINE を置き、その後に変更点と未解決事項を記載した簡潔な人間向け要約。

厳格なルール

• 引用、DOI、arXiv ID、BibTeX フィールドを決して捏造しないでください。 参照を検証できない場合は、その旨を伝えてください。自信たっぷりの偽物より、正直に空欄を残すほうが適切です。
• 未解決の項目を、どの実在する論文を指しているのか推測して「修正」しないでください。 検索して候補を提示し、ユーザーに選んでもらってください。
• 解決できたからといって、推奨されたことにはなりません。 DOI／ID の解決によって記録が実在することは確認できますが、それが適切な 版 であることや、主題に関連していることまでは証明されません。CANONICAL_INSTANCE と LOW_RELEVANCE はコパイロットへのプロンプトとして扱ってください。根拠を提示し、成果物を自動で差し替えたり、参照を自動で削除したりしないでください。
• 引用数、代替の成果物、関連性スコアを決して捏造しないでください。 正規版チェックで示すすべての代替候補は、実際にインデックスが返した記録でなければなりません。関連性の数値は、スクリプトまたは実際に実行した埋め込みモデルから得たものでなければならず、記憶に基づくものであってはなりません。
• PARTIAL-PASS は PASS ではありません。 権威あるインデックスに到達できなかった場合は、PARTIAL-PASS と報告し、省略したチェックを列挙して、書誌情報を検証済みとして扱う前に再実行してください。「確認できなかった」を「問題なし」と受け取れる表現にしてはいけません。
• 人間向けの要約には、機械による判定を一字一句そのまま記載してください。決して言い換えて整えないでください。 作成する文章の要約、README、ステータス行には、スクリプトによる正確な判定（PASS／PARTIAL-PASS／FAIL）と生の件数（検証済み N 件、警告 M 件（フラグ別）、チェック省略 K 件）を必ず含めてください。「PARTIAL-PASS、警告 11 件、チェック省略 1 件」を「検証済み、エラー 0 件」にまとめてはいけません。要約対象の報告と食い違う、問題がなさそうに見える要約そのものが失敗です。実際にインデックスを照会し、そのセッションでラウンドトリップを確認して、種別／掲載先／DOI を（再版ではなく）正規の記録と照合できた項目のみを「検証済み」とします。古いチェックや省略されたチェックに基づいて検証済みとしてはいけません。また、検証済みとしたファイルに「まだ信頼できない」というバナーを残してはいけません。
• RETRACTED の結果は、撤回通知の DOI とともに、ユーザーに一字一句そのまま提示してください。撤回論文を承知のうえで引用することが正当な場合もあります（例：撤回の研究）。それを判断するのはユーザーであり、その場合は引用に撤回の事実を明記してください。
• メタデータのみを扱います。このスキルが取得して比較するのは、タイトル、著者、年、掲載先、DOI です。取得した抄録や論文本文をリポジトリに保存しないでください。
• 撤回の検出範囲はベストエフォートです（Crossref／Retraction Watch のデータとタイトルのマーカーを使用）。フラグがないからといって、論文が撤回されていない証拠にはなりません。重要な場合はその旨を伝えてください。
• venues/ のプロファイルを使って VENUE_MISMATCH を判断する場合、プロファイルはあくまで出発点として扱ってください。ユーザーにその項目が誤りだと伝える前に、根拠とする掲載先の情報を、プロファイル内のライブの cfp_url で再確認してください。

同梱リソース

• scripts/check_bibtex.py — 検証ツールです。再実装せず、実行してください。
• references/triage-guide.md — フラグごとの解釈、誤検出、正確な修正コマンドを説明します（CANONICAL_INSTANCE と PARTIAL-PASS 判定を含みます）。
• references/relevance-gate.md — 関連性ゲートによる主題適合性のスコア付け、モデルが利用可能な場合に実行する埋め込み類似度のアップグレード、LOW_RELEVANCE への対応方法を説明します。
• references/verification-sources.md — プロバイダー API、情報源の優先順位、掲載先の別名処理、撤回データ、レート制限、ライセンスについて説明します。

メモリ

このスキルは、ユーザーの論文ディレクトリにある共通の .paper-memory/ 規約を使用します。必須のメモリ規約はスキルに同梱されているため、単独でインストールした場合も機能します。 references/paper-memory.md

• 開始時： .paper-memory/lessons.md を読み、このサイクルですでにユーザーが解決した項目を再度指摘しないようにします。また、この著者について記録された recurring な引用の傾向があれば、最初に伝えます（例：「現在は出版済みの arXiv プレプリントを引用する傾向があるため、出版済みの記録を優先してください」）。
• 終了時： 共通形式 - [YYYY-MM-DD] (verify-citations | <scope>) issue -> recommendation で、長期的に役立つ知見を追記します。reflect-and-improve がインストールされている場合は、重複を排除して日付を付与するために、その reflect_log.py append を使用します。インストールされていない場合は、references/paper-memory.md に記載された重複排除と日付のルールに従い、1 行の項目を手作業で追記します。参考文献一覧全体または複数の論文に見られるパターンは recurring、1 件だけ修正した項目は this-paper とします。メモリには捏造したメタデータを記録せず、パターンと正規の修正方法のみを記録します。
• .paper-memory/ が存在しない場合は必要に応じて作成し、プロジェクトの .gitignore に追加することを提案します。これはローカル専用です。アップロードしたり、このリポジトリにコピーしたりしないでください。

任意の補助機能。 verify-citations は単独で動作します。paper-profile（論文の位置付けと .paper-memory/profile.yml）および reflect-and-improve（reflect_log.py メモリヘルパー）は、任意の拡張機能です。引用の確認にも、上記の手動によるメモリ運用にも、どちらも必要ありません。