Markdownで文献出典を扱う実用的な方法

Share

Markdownで文章を書いていると、学術的な小論や技術記事など、ある程度の正確さを求められる文書で文献出典をどう扱うかという問題に直面する。Markdownの仕様には脚注や参考文献を管理する標準的な仕組みがなく、エディタごとの独自拡張に頼ると将来の移行時に困る。本稿では、プレーンテキストとしての可搬性を保ちながら文献出典を扱う方法を比較し、実用的な選択肢を検討する。

前提と要件

文献出典の記法に求められる性質は以下の通りである。

  • 可搬性: 特定のエディタやプラットフォームに依存しない。プレーンテキストとして意味が通じる
  • 執筆時の効率: 書いている途中で文献リストとの間を行き来する必要がない
  • 可読性: 出典の挿入が本文の読みやすさを大きく損なわない
  • 検索性: 後から特定の文献を参照している箇所を検索できる
  • 自己完結性: リンクや外部参照に依存せず、テキスト単体で出典情報が完結する

リンクベースの参照([[]] やハイパーリンク)は、リンク先が移動・消失すると出典情報そのものが失われるため、長期的な文書管理には不向きである。

主な方法の比較

インライン括弧方式(著者年スタイル)

本文中に著者名と出版年を括弧で挿入する方法である。APAやシカゴスタイルなどの学術引用規格に準拠しており、最も広く認知されている。

認知負荷理論によれば (Sweller 1988)、作業記憶の容量は限られている。

本文の流れを大きく妨げず、どの出典に基づく記述かが明確になる。ただし、括弧内の情報だけでは論文タイトルが分からないため、末尾に参考文献リストを別途用意する必要がある。

段落末尾集約方式

段落全体の出典を末尾にまとめて記載する方法である。

認知負荷理論によれば、作業記憶の容量は限られている。より近年の研究ではこの理論が実証されている。
[Sweller 1988; Kirschner et al. 2006; Clark 2010]

本文中に括弧が現れないため読みやすいが、どの記述がどの出典に対応するかが曖昧になるという欠点がある。厳密な引用が求められる場面には不向きである。

セクション末尾方式

セクションの末尾に出典をまとめる方法である。段落末尾集約方式をさらに粗い粒度にしたものといえる。カジュアルな技術記事やメモには適しているが、学術的な正確さは期待できない。

インライン完全記載方式

出典情報を括弧内にすべて書き込む方法である。

認知負荷理論によれば (Sweller, J. (1988). Cognitive load during problem solving. Cognitive Science, 12(1), 257-285)、作業記憶の容量は限られている。

自己完結性は最も高いが、本文の可読性を著しく損なう。

実用的な妥協案

上記の方法を踏まえると、実用上はインライン括弧方式を拡張し、著者年に加えて論文タイトルの一部も括弧内に含める方法がバランスがよい。

認知負荷理論によれば (Sweller 1988: Cognitive Load Theory)、作業記憶の容量は限られている。

この方法には以下の利点がある。

  • 著者年だけの場合と異なり、括弧内を見るだけで何の文献かが分かる
  • 完全記載方式ほど冗長にならず、本文の可読性を保てる
  • 執筆中に参考文献リストを参照する必要がない
  • プレーンテキストとして自己完結しており、エディタを問わず意味が通じる
  • 正式な参考文献リストが必要な場合は、末尾に追加すればよい

詳しさの度合いは文書の性質に応じて調整すればよい。個人的なメモであれば著者年のみで十分であり、公開する文書であればタイトルを含めた方が読者に親切である。いずれにしても、プレーンテキストの可搬性を維持するという原則に従えば、特定のツールやプラットフォームに縛られずに文献出典を扱うことができる。

Read more

Dependabotの対応が面倒なのでRenovateを導入する

Dependabotくんはある程度の依存関係の更新を通知してくれるが、山のようにprojectを抱えているとなんとも痒いところに手が届かない。 ということで、Renovateを使ってみる。 Build software better, togetherGitHub is where people build software. More than 150 million people use GitHub to discover, fork, and contribute to over 420 million projects.GitHub ここからGitHub Appを入れる。 あとは、指示に従ってポチポチするだけで、超かんたんだった。 感想 自動化最高。

By Sakashita Yasunobu

nodejsのバグを見つけたのでPRを投げてみた

概要 要するに、node --testで特定のバイナリを標準出力に書くと、テストランナーが固まったり、異常終了したりするバグです。 バグ自体は既知のものだったようで、修正がされていました。 test_runner: infinite loop in FileTest#drainRawBuffer when child stdout contains FF 0F followed by large size bytes · Issue #62693 · nodejs/nodeVersion v25.9.0 (also reproduced on v24.14.1 LTS, v22.21.0 LTS, v23.4.0) Platform Darwin 25.

By Sakashita Yasunobu
青空文庫のParser

青空文庫のParser

青空文庫のParserを作ってます。 GitHub - P4suta/aozora: Pure-functional Rust parser for 青空文庫記法 (Aozora Bunko notation): ルビ, 傍点, 縦中横, 外字, 返り点, indent containers, page breaks.Pure-functional Rust parser for 青空文庫記法 (Aozora Bunko notation): ルビ, 傍点, 縦中横, 外字, 返り点, indent containers, page breaks. - P4suta/aozoraGitHubP4suta Rustで作ってますが、配布物はcargoのほかにnpm/pypiでも入手できます Documentation * Playground — try it in

By Sakashita Yasunobu