Markdownの標準仕様にないがデファクトスタンダードとなっている機能は？

Prompt

一番普通の方法は、ただ太字にするだけだよね。
ところで、markdown標準仕様には無いが、デファクトスタンダードとなっている機能はある？

やっほー！確かに、1列目を **太字** にするのが一番「Markdownらしい」慎重で賢い妥協点だよね。僕もよくやるよ！

さて、Markdownの「標準（CommonMark）」は実はかなりストイックで、僕たちが当たり前に使っている機能の多くは、実は**「デファクトスタンダード（事実上の標準）」**として後から付け加えられた拡張機能なんだ。

情報工学を学ぶ君の知的好奇心を刺激する、代表的な「非標準だけどみんな使ってる」機能を整理してみたよ！

---

1. GitHub Flavored Markdown (GFM) の影響力

今、世界で最も使われているMarkdownの仕様はこれだね。GitHubが便利さを求めて拡張したものが、そのまま世界の標準になっちゃったんだ。

① テーブル記法

実は、「標準のMarkdown」にはテーブルという概念すら存在しないんだ！

君がさっきから悩んでいた | --- | という書き方は、GFMが広めた拡張機能の代表格だよ。

② タスクリスト

Markdown

- [x] Rustの勉強
- [ ] 部屋の掃除

これも標準にはないけれど、GitHubやVS Code、Notionなんかで当たり前に使えるよね。

---

2. 数式表示 (Math Jax / KaTeX)

君のような情報工学徒には欠かせない、LaTeX形式の数式表示！

• 書き方: $E = mc^2$ や $$...$$

• 現状: 標準ではないけれど、GitHub、GitLab、Obsidian、そして僕（Gemini）との会話でもデファクトとして機能しているね。

---

3. コードブロックの「言語指定」

Rust

fn main() { println!("Hello!"); }

バッククォート3つの後に rust とか java と書く「シンタックスハイライト」の指定も、実は多くのパーサーが独自に実装して広まったものなんだ。

---

4. フロントマター (Front Matter)

ドキュメントの先頭に書く、メタ情報のブロックだよ。

YAML

---
title: "Markdownの深淵"
date: 2026-01-09
tags: [IT, Markdown]
---

• 用途: 静的サイトジェネレーター（Jekyll, Hugo）や、Obsidianなどのノートアプリで、記事の管理に使われる。

• 正体: Markdownの本文ではなく、YAML形式のデータを埋め込むためのデファクトな記法だね。

---

⚠️ 見落とされがちな落とし穴：方言による「表示崩れ」

「デファクトスタンダード」というのは、あくまで「みんながなんとなく共通で実装している」だけであって、「すべての環境で同じに見える」ことを保証しないんだ。

• 例: GitHubでは動く「アラート（> [!NOTE]）」が、自分のUbuntu上のエディタではただの引用に見えたりする。

• 対策: 「どこで表示させるか」を意識して、必要最小限の記法（CommonMarkに近い形）に留めるのが、長生きするドキュメントを作るコツだよ。

---

💡 豆知識：Mermaidの統合

最近の大きなトレンドは、Markdownの中に Mermaid（さっき僕がリレーションシップを表現したやつ！）を直接書けるようになることだね。

テキストだけで図解まで完結させたいというエンジニアの欲求が、新しいデファクトを作ろうとしているんだよ。

---

Prompt

あとは[[これとか？]]
むしろ、これらの独自構文が曖昧だからこそ、markdownの自由度を上げ、移植性を下げている。

やっほー！その [[WikiLink]] の記法、まさに「デファクトスタンダード」の代表格にして、君が指摘した通りの「移植性の天敵」だね！

情報工学を学ぶ身としては、その「便利さとカオスの表裏一体」な感じ、放っておけないよね（笑）。君の洞察は非常に鋭いよ。

---

1. [[WikiLink]]：便利という名の毒薬

この二重ブラケットによるリンク（WikiLinks / Backlinks）は、もともと「Wikipedia」の編集記法から広まったものだね。今は Obsidian や Notion、Zettelkasten といったノートアプリで「ナレッジのネットワーク化」のために欠かせない機能になっているよ。

• 自由度: [タイトル](ファイルパス) と書かなくても、ファイル名だけでリンクが繋がるから、思考のスピードを落とさずに書ける。

• 移植性の崩壊: この記法は標準のMarkdownパーサーでは「ただの文字列」として処理されるんだ。GitHubにプッシュしても、多くの静的サイトジェネレーターでビルドしても、リンクとして機能しない。

---

2. 独自構文が「移植性」を下げるメカニズム

君が言う通り、Markdownが「曖昧」であることは、情報工学的な「相互運用性（Interoperability）」の観点からは大きな課題なんだ。

• パーサーの独自実装: Remark, Pandoc, Goldmark……。それぞれのパーサーが「うちのWikiLinkはスペースをハイフンに変換するよ」「うちはエンコードするよ」と、微妙に仕様が違う。

• パブリッシングの壁: ローカルのObsidianで完璧に整理したノートを、いざWebサイトとして公開（移植）しようとすると、リンクが全部死んで絶望する……というのはエンジニアの「あるある」なんだ。

---

3. なぜ「曖昧さ」が放置されているのか？

普通、情報工学の世界なら「厳格な仕様（RFC）」を作って統一するよね。でもMarkdownはそうならなかった。

• 人間中心の設計: Markdownは「コンピュータが処理するため」ではなく「人間が楽に書くため」に生まれたからなんだ。

• 「方言」を許容する文化: 多様なユースケース（学術、ブログ、メモ）に合わせて、コミュニティが勝手に拡張する自由を優先した結果だね。

---

💡 見落とされがちな視点：ポータビリティの確保

君のように「移植性を下げたくない」エンジニアは、あえて以下のような戦略を取ることがあるよ。

• 標準への回帰: 便利な独自機能（WikiLinkなど）をあえて使わず、常に標準の [title](path/to/file.md) を使う。

• 変換レイヤーの導入: 独自構文を標準構文に「正規化」するスクリプト（GitHub Actionsなどで動かす）を自作して、移植性を無理やり担保する。

---

💡 豆知識：RFC 7763

実は、Markdownにも一応 RFC（インターネット技術の標準仕様書）が存在するんだ（RFC 7763）。でも、中身は「Markdownというメディアタイプがあるよ」という宣言に近いもので、具体的な文法を厳格に定めているわけじゃない。この「緩さ」こそが、Markdownの強みであり、呪いでもあるんだね。