Markdown のリンクスタイル比較：inline / reference / shortcut / autolink の使い分け
Markdown のリンクは「[text](url) で書く」とだけ覚えている人が多いですが、実は 4 種類の記法があります。長い記事や仕様書を書くと「同じ URL を 5 回書きたくない」「URL を脚注にまとめたい」「メールアドレスを自動リンク化したい」といった場面で、他の記法のほうが圧倒的に書きやすいケースが出てきます。本記事では 4 種類を比較し、用途別の選び方を整理します。
4 種類の記法
1. Inline link
最も一般的な記法：
詳しくは [公式ドキュメント](https://example.com/docs) を参照してください。[テキスト](URL "オプションのタイトル") の形式。タイトル属性は HTML の title= に出力され、ホバー時のツールチップになります（多くの Markdown 実装でサポート）。
2. Reference link
URL を本文と分離し、末尾の参照定義に書く形式：
詳しくは [公式ドキュメント][docs] を参照してください。
さらに [API リファレンス][api] もあります。
[docs]: https://example.com/docs
[api]: https://example.com/api 'API リファレンス'[テキスト][参照名] で本文を書き、別の場所で [参照名]: URL として URL を定義します。参照名はドキュメント全体で一意であれば、定義の位置はどこでも構いません。
3. Shortcut reference
参照名を省略する形式：
詳しくは [公式ドキュメント] を参照してください。
[公式ドキュメント]: https://example.com/docs[テキスト] だけ書くと、テキスト自体が参照名として使われます。reference link の最短形。
4. Autolink
URL やメールアドレスをそのまま <> で囲む：
詳しくは <https://example.com/docs> を参照してください。
連絡先は <admin@example.com> です。URL がそのまま表示され、リンクにもなります。テキストと URL を別にしたい場合は使えません（テキスト = URL）。
比較表
| 観点 | Inline | Reference | Shortcut | Autolink |
|---|---|---|---|---|
| 記法 | [t](url) | [t][ref] + 後方定義 | [t] + [t]: url | <url> |
| 可読性（ソース） | △（URL が混じる） | ◎（本文が読める） | ◎ | △ |
| URL 長への耐性 | ✗（行が長くなる） | ◎ | ◎ | ✗ |
| 同じ URL の再利用 | ✗（コピペ） | ◎（参照 1 つ） | ◎ | ✗ |
| URL を最後にまとめる | ✗ | ◎ | ◎ | ✗ |
| テキストと URL を分けたい | ◎ | ◎ | △（テキスト = 参照名） | ✗ |
| メアド・URL のクイック表示 | ✗ | ✗ | ✗ | ◎ |
用途別の推奨
ブログ記事・READMEの本文 → Inline
短めの文章で、URL が 1-2 個ずつポツポツ出てくる場合：
[GitHub リポジトリ](https://github.com/owner/repo) を見てください。ソースが読みやすく、書く側も慣れている形式。Markdown の入門者が最初に覚えるのもこれ。
仕様書・長い記事・複数ページ → Reference
同じ URL を複数回参照する、URL が長い、本文を URL 抜きで読みたい場合：
本機能は [RFC 7519] および [RFC 8259] に準拠する。詳しくは [RFC 7519] §4 を参照。
[RFC 7519]: https://datatracker.ietf.org/doc/html/rfc7519
[RFC 8259]: https://datatracker.ietf.org/doc/html/rfc8259利点：
- 本文は短く、URL が視界を遮らない
- URL を後でまとめて確認・修正できる
- 同じ参照名で 5 回書いても URL は 1 箇所だけ
“URL なしで本文を読みたい” → Shortcut
参照名を考えずに、テキストそのままで参照：
本機能は [RFC 7519] に準拠する。
[RFC 7519]: https://datatracker.ietf.org/doc/html/rfc7519「[RFC 7519][rfc7519]」と書くより「[RFC 7519]」のほうが本文が読みやすい。同じ書き方を別の場所で 5 回しても、定義は 1 つだけ。
URL そのものを見せる → Autolink
「ここにアクセスして」と URL を見せたい場面：
GitHub Issues は <https://github.com/owner/repo/issues> で受け付けています。CommonMark / GFM では https://... を裸で書くだけでもリンク化される実装が多いですが、< > で囲むほうが仕様準拠で、改行や周囲の文字に頼らず確実にリンクとして解釈されます。
CommonMark / GFM の細かい仕様
参照名の大文字小文字
参照名は大文字小文字を区別しない：
[Foo][BAR] と [foo][bar] は同じリンクになる。
[bar]: https://example.com正規化は ASCII 範囲の caseless（CommonMark §6.6）。ただし Unicode 文字を含む参照名は、実装によって挙動が分かれます。
Shortcut reference + テキスト内の []
[Foo] というテキストの後に [Bar] が来る。
[Foo]: https://foo.example
[Bar]: https://bar.exampleこれは [Foo] [Bar] の 2 つのショートカット参照として正しく動作します。[] を文字として書きたい場合はバックスラッシュエスケープ：
配列 [0] は最初の要素。CommonMark と “linkify”（GFM 拡張）
GitHub Flavored Markdown は < > なしで URL を書いても自動リンクします（linkify 拡張）：
詳しくは https://example.com を参照。 ← GFM では自動リンクCommonMark の標準仕様には含まれていません。Hugo や Jekyll などジェネレータごとに対応状況が違うので、仕様に依存させたくないなら明示的に <> か []() を使うのが安全。
reference link の上級テク
URL を巨大なファイル末尾にまとめる
長い記事では本文と URL を完全に分離できます：
本機能は次の RFC に準拠する：
- HTTP の概要は [RFC 7230]
- セマンティクスは [RFC 7231]
- 認証は [RFC 7235]
詳細：[RFC 7230] §5、[RFC 7231] §6、[RFC 7235] §3。
<!-- 末尾にまとめて定義 -->
[RFC 7230]: https://datatracker.ietf.org/doc/html/rfc7230
[RFC 7231]: https://datatracker.ietf.org/doc/html/rfc7231
[RFC 7235]: https://datatracker.ietf.org/doc/html/rfc7235URL が壊れたとき、末尾だけ確認すればよい。
参照名の命名規則
[Foo Bar Documentation][foo-bar-docs]
[foo-bar-docs]: https://example.com/foo-bar- 参照名は kebab-case か snake_case で統一
- ドキュメント全体で一意に
- 短く（タイプ量を減らす）
編集ツールでの取り扱い
- VS Code：標準で reference link の URL ジャンプ・補完あり
- prettier：reference link の参照名を整列、未使用の参照定義を検出（
prose-wrap設定で挙動が変わる） - markdownlint：参照定義の未使用 (MD053)、重複 (MD024) などをルール化
まとめ
Markdown の 4 種類のリンク記法は、本文と URL の分離度合いで並べると Autolink → Inline → Reference → Shortcut の順に分離が深まります。短い文章なら Inline、長い文書や仕様書では Reference / Shortcut、URL を見せたいなら Autolink、というのが基本指針です。reference link と shortcut reference を覚えると、長い記事の Markdown ソースが劇的に読みやすくなるので、本サイトのブログや GitHub の README を書くときは積極的に使うと良いです。
書いた Markdown を実際にレンダリングして確認したいときは Markdown プレビューツール を利用してください。