ツール連携（CSL / arXiv / 管理ソフト）

参考文献で本当に時間を溶かすのは、.bib を打ち込む作業ではありません。修士論文と投稿論文3本と共著者2人のあいだで、たった一つの .bib を矛盾なく保ち続けることです。だから LaTeX の文献ツールは、ほとんどが「入力を速くする道具」ではなく「入力後に壊れているところを見つける道具」として設計されています。このページでは、DOI や arXiv から書誌情報を取り込み、汚れた項目を洗い、重複を潰し、引用キーを固定して共著者に渡すまでを、Zotero や JabRef のような管理ソフトと、TeX Live に最初から入っている bibcop・checkcites・biber --tool の両方で追っていきます。

DOI や arXiv から BibTeX を取り込む

論文に DOI が付いていれば、.bib の項目は 1 行のコマンドで手に入ります。仕組みは content negotiation（内容交渉） です。doi.org に「BibTeX 形式で返してほしい」と HTTP ヘッダで伝えると、その DOI を登録した機関——学術論文なら多くは Crossref——が書誌データを BibTeX に整形して返します。つまり出版社のページを開いてコピーする必要はなく、DOI そのものが API になっています。

# fetch BibTeX for a DOI; -L follows the redirect to the registration agency
curl -LH "Accept: application/x-bibtex" \
  "https://doi.org/10.1145/3186893" >> refs.bib

-L を落とすと何も返ってきません。doi.org はどの登録機関がその DOI のメタデータを持っているかを判定して リダイレクト するだけの窓口なので、追従しなければ空振りに終わります。コマンドが面倒なら、同じ content negotiation を Web で包んだ doi2bib.org に DOI を貼れば済みます（arXiv ID や PubMed ID も受け付けます）。arXiv のプレプリントはアブストラクトページの「Export BibTeX citation」から直接、Google Scholar は各件の「Cite → BibTeX」から取り出せます。どの経路でも、手で打つ文字はほぼゼロです。

なぜ取り込んだ BibTeX はそのまま使えないのか

書き出し側は、自分のデータベースに入っている文字列をそのまま吐くだけで、LaTeX の都合を知らないからです。結果として、同じ論文を出版社サイト・Crossref・Google Scholar の三か所から取ると、三つとも違う BibTeX になります。よく壊れるのは決まって同じ四か所で、いずれも組版の段になって初めて表面化します。

• 大文字が守られていない — {DNA} や {Fourier} のように波括弧で囲っていないと、plain 系のスタイルはタイトルを小文字化して「dna」「fourier」にしてしまいます。詳しくは文献データベースのページで扱います。
• 誌名が略されている／略されていない — 同じ雑誌が Comput. J. と The Computer Journal の両方で入り、文献リストの中で表記が割れます。投稿規定はたいていどちらかに統一するよう求めます。
• エントリ型が違う — 会議論文が @article や @misc として書き出されることがあり、booktitle が無いまま @inproceedings の体裁で組まれると出力が崩れます。
• arXiv 版と出版版の取り違え — プレプリントの BibTeX には journal も doi も無いことが多く、査読誌に載ったあとも古い方を引き続けてしまいます。

.bib を検査・整形する — bibcop と biber --tool

上の四つは、目視ではなく リンタ に探させるのが確実です。TeX Live には .bib 専用のリンタ bibcop が最初から入っており、追加インストールなしで bibcop refs.bib と打つだけで動きます。返ってくるのは行番号の羅列ではなく、平叙文の指摘です——たとえば Do not shorten the words in the journal, such as Comput.、All major words in the title must be capitalized、A mandatory doi tag for @article is missing。人間が読める文で叱ってくるので、何を直せばよいかで迷いません。

# lint a database in place
bibcop refs.bib

# reformat and sort every entry; also reports duplicate keys
biber --tool --output-align --output-fieldcase=lower \
  --output-file=clean.bib refs.bib

整形そのものは biber --tool が担当します。biber には文書を処理する普通のモードとは別に tool モード があり、.bib を入力して .bib を出力する単体のフィルタとして働きます。フィールドを揃えて並べ直し、エントリを整列し、重複キーがあれば Duplicate entry key: ... skipping と警告して片方を落とします。ただし ここに一つ罠があります。tool モードの出力は既定で biblatex のフィールド名に正規化されるので、year が date に、journal が journaltitle に化けます。biblatex を使っているなら望ましい変換ですが、素の BibTeX に食わせるつもりの .bib を通すと文献リストから年も誌名も消えます。

重複エントリと、宙に浮いた引用キーを見つける

同じキーが二度現れると BibTeX は Repeated entry---line 8 of file refs.bib と言って後から来た方を捨て、biber は Duplicate entry key と警告します。厄介なのはむしろ キーが違うのに中身が同じ 重複のほうで、これは誰も警告してくれません。共著者がそれぞれ Zotero から書き出した .bib を結合したとき、smith2020 と Smith2020a として同じ論文が二度並ぶ——文献リストに同じ行が二つ出て初めて気づく類の事故です。

内容による重複判定でいちばん頼りになる手がかりは DOI です。著者名やタイトルは表記が揺れますが、DOI が同じなら同じ論文だと断定できます。bibtex-tidy はまさにこれを実装していて、--duplicates doi（あるいは key／abstract／citation）で判定基準を選び、--merge を足せば片方に統合します。反対側の問題——.bib に無いキーを引用してしまい、本文に [?] が出る——には checkcites が効きます。--undefined は「引用したのに定義が無いキー」を、--unused は「定義したのに誰も引用していない項目」を挙げます。

# BibTeX projects read the .aux; biblatex projects read the .bcf
checkcites paper.aux
checkcites --backend biber paper.bcf

# keys cited but missing from the database
checkcites --undefined paper.aux

文献管理ソフトはどれを選ぶか — Zotero / JabRef / BibDesk

数十件までは .bib を手で編集しても回りますが、数百件になると管理ソフトが要ります。分かれ道は .bib を「原本」と見るか「書き出し結果」と見るか です。JabRef と BibDesk は .bib そのものを開いて保存するので、テキストエディタで直接いじる作業と両立します。Zotero は独自のライブラリを原本とし、.bib はそこから生成される派生物になります。

• Zotero — 無料・オープンソースの定番。ブラウザ拡張で論文ページから 1 クリック取り込み、PDF の保存、共有グループライブラリまで揃います。LaTeX で使うなら拡張の Better BibTeX をほぼ必須と考えてください。
• Better BibTeX（Zotero 拡張） — 引用キーを規則から生成し、ライブラリの変更を .bib に自動反映する auto-export を提供します。.bib を「常に最新の生成物」として扱えるようになるのがこの拡張の要点です。
• JabRef — .bib をネイティブに扱うオープンソースの管理ソフト。独自形式を持たず、DOI・arXiv・ISBN から項目を取得し、まとめて整形する一括クリーンアップ機能も備えます。Windows・macOS・Linux で動きます。
• BibDesk（macOS） — Mac 用の BibTeX フロントエンドで、MacTeX に同梱されています（/Applications/TeX/BibDesk.app）。.bib を直接編集し、PDF の自動整理や外部データベース検索に対応します。
• Mendeley — 従来の Mendeley Desktop は 2022 年 9 月 1 日に配布終了 となり、.bib を自動同期する機能もそこで失われました。後継の Mendeley Reference Manager でも BibTeX への書き出しはできますが、手動操作です。
• Paperpile — Google Docs 連携に強い有償サービス。BibTeX の書き出しに対応します。

Zotero 側の事情は 2026 年に大きく動きました。Zotero 8 で citation key が Zotero 本体のフィールドになり、Better BibTeX が持っていたキー欄はそれに置き換わっています。キーは常に固定（pinned）扱いで端末間を同期するので、以前のように 1 件ずつ「Pin BibTeX Key」する儀式は無くなりました。ただし Zotero 自身はキーを生成しません——規則からキーを作り、auto-export で .bib を吐き続ける役目は、引き続き Better BibTeX が担っています。なお Better BibTeX の Zotero 7 対応は打ち切られているので、この構成を使うなら Zotero も上げておく必要があります。

引用キーを固定して .bib を共著者と共有する

引用キーは原稿と文献データベースのあいだの API です。だからキーだけは絶対に動かしてはいけません。書き出しのたびにキーが振り直される設定になっていると、本文の \cite{...} が一斉に解決できなくなり、PDF は [?] だらけになります。命名規則は何でも構いませんが、著者姓 + 西暦 + タイトル短縮（knuth1984literate のような形）にしておくと衝突しにくく、キーを見ただけで何の論文か分かるという副産物も付いてきます。

共著者との共有では、.bib を原稿と同じ Git リポジトリに入れる のが最も事故が少ない方法です。.bib はプレーンテキストなので差分が読め、誰がどの項目を足したか履歴に残ります。ただしそのままだと衝突が頻発するので、出力順を固定しておく ことが効きます。全員が biber --tool を通してから commit する、あるいは Better BibTeX の auto-export 先を一か所に決めておく——どちらでも、行の並びが安定すれば merge conflict は劇的に減ります。逆にやってはいけないのは、各自のローカルの .bib をメールで送り合うことです。二週間後には四つの異なる .bib が存在します。

# ship only the entries this paper actually cites
pdflatex paper.tex
bibexport -o submission.bib paper.aux

投稿の直前には、逆に .bib を切り出す 作業が必要になります。多くの雑誌は原稿一式の提出を求めますが、そこに 800 件入りの個人データベースを添えるわけにはいきません。bibexport は .aux を読んで 実際に \cite された項目だけ を新しい .bib に書き出すので、この用途にちょうど当てはまります（bibtool でも .aux を解析して同じことができます）。同じ理由で、日常的には一つの大きな master .bib を持ち、原稿ごとに切り出す運用が扱いやすくなります。

LaTeX を使わない相手に渡す — CSL と pandoc

共著者が Word で書いていても、.bib を捨てる必要はありません。CSL（Citation Style Language） という、引用と文献リストの体裁を記述する XML 形式があり、その最大の特徴は 組版エンジンに依存しないこと です。BibTeX の .bst は BibTeX 専用、biblatex のスタイルは LaTeX 専用ですが、.csl はどの系にも縛られません。実際の整形は citeproc という処理系が担当し、Zotero・Word 用プラグイン・各種変換ツールがそれぞれの citeproc 実装で同じ .csl を解釈します。学術誌ごとのスタイルは Zotero の style repository に数千点あり、自由に使えます。

pandoc paper.md --citeproc \
  --bibliography=refs.bib \
  --csl=ieee.csl \
  -o paper.pdf

この CSL をもっともよく使うのが pandoc です。Markdown で書いた原稿を --citeproc を付けて変換すると、本文中の [@knuth1984] のような引用キーが整形済みの引用に置き換わり、末尾に文献リストが生成されます。--bibliography には .bib をそのまま渡せて（複数回指定して束ねられます）、--csl を省略すると Chicago author-date が使われます。要するに、LaTeX を経由せず Markdown から直接 PDF・Word・HTML へ、同じ .bib を入力として出力できるわけです。

結局、このページのツールはすべて同じ前提の上に立っています——資産は .bib そのものであって、出力経路ではない ということです。DOI から取り込み、bibcop で叱られ、biber --tool で整え、キーを固定して Git に置いた一つのデータベースがあれば、そこから先は biblatex で PDF を出すのも、pandoc で共著者に Word を渡すのも、単なる出口の選択にすぎません。ツールを増やすより、データベースを一つに保つほうがずっと効きます。