Markdown vs HTML vs RTF — 軽量ドキュメントフォーマットの選び方
README / 議事録 / メール下書き / Word 共有 で Markdown / HTML / RTF をどう使い分けるかを、可搬性 / 表現力 / 編集ツール対応 / 配布先での見え方 で比較します。
どの軸で選ぶか — 4 つの判断基準
Markdown / HTML / RTF はどれも「文字に書式を付ける」ためのフォーマットですが、設計思想がかなり違います。判断軸は 4 つあります。可搬性 は別ソフト / 別 OS / 別環境にコピーしたときに崩れるかどうかを左右します。表現力 はテーブル・画像埋め込み・スタイル指定・スクリプト埋め込みまでどこまでカバーするかを決めます。編集ツール はテキストエディタで開けるか専用ソフトが要るかを切り分けます。配布先のレンダリング は GitHub / Slack / Word / メールクライアントなど、最終的に読まれる環境の挙動です。
「とりあえず Markdown」「とりあえず HTML」と決め打ちする前に、配布先が何を期待しているか確認するのが事故を減らす近道です。たとえば技術ブログなら Markdown、社内ニュースレターなら HTML、Word を使うクライアントへの提出物なら RTF、というように向き不向きがはっきり分かれます。
3 フォーマットの比較表
| 項目 | Markdown | HTML | RTF |
|---|---|---|---|
| 書式の付け方 | 軽量記法 (# h1, **bold**) | タグ + CSS (<h1>, <p>, <a>) | 制御語 (\b, \par, \fs24) |
| 標準仕様 | CommonMark (2014) / GFM | W3C HTML Living Standard | Microsoft RTF Specification 1.9.1 (2008 で更新停止) |
| 開発年 | 2004 (John Gruber) | 1993 (Tim Berners-Lee) | 1987 (Microsoft) |
| 編集ソフト | 任意のテキストエディタ | テキストエディタ / 専用 IDE | Word / TextEdit / Pages / WordPad |
| Word 互換 | △ (貼り付け時に書式喪失) | △ (貼り付け可、再現度はクライアント依存) | ◎ (Word のネイティブ中間形式) |
| GitHub 表示 | ◎ (README として自動レンダリング) | △ (raw 表示、レンダリングされない) | × |
| メール添付 | △ (受信側で表示不可なことが多い) | ◎ (HTML メール) ただしクライアント差大 | ◎ (Outlook / 古いメールで標準的) |
| 画像 | 外部リンクで参照 | 外部リンク or Base64 埋め込み | バイナリ埋め込み可 |
| ファイルサイズ | 最小 (プレーンテキスト) | 中 (タグ分のオーバーヘッド) | 大 (制御語 + 埋め込み画像) |
実務での違いを 1 行ずつ補足します。Markdown は GitHub / Notion / Slack / Discord / Zenn / Qiita で標準的に解釈される一方、エンジン (CommonMark / GFM / kramdown / Pandoc) ごとに方言があります。HTML はブラウザ内で開く前提なら表現力が最大ですが、メール用 HTML はクライアント差 (Gmail / Outlook / Apple Mail) が大きく、CSS の対応範囲がそれぞれ違うので注意が必要です。RTF は Microsoft Word のネイティブな中間形式で、書式情報がプレーンテキスト形式の制御語 (バックスラッシュ記法) として埋め込まれており、TextEdit / Pages / Word / WordPad / LibreOffice いずれでも開けます。
ユースケース別の推奨
README / 技術ブログ / OSS ドキュメント: Markdown 一択です。GitHub / GitLab / Bitbucket / Notion / Zenn / Qiita / Docusaurus が標準でレンダリングします。GitHub Flavored Markdown (GFM) のテーブル・タスクリスト・コードブロック (シンタックスハイライト) を覚えると 80% カバーできます。
自社サイト / ランディングページ / アプリ画面: HTML + CSS。SEO 上の構造化情報 (<article>, <nav>, <header>) や JavaScript との連携、レスポンシブデザインを考えると HTML が前提になります。Markdown はビルド時に HTML へ変換する形 (Astro / Next.js MDX など) で挟むのが現代的です。
ニュースレター / マーケティングメール: HTML メール。ただしクライアント差を吸収するためインライン CSS、テーブルレイアウト、Outlook の VML 対応などレガシーなテクニックが必要で、専用エディタ (Stripo / MJML) を使うのが一般的です。
Word を使う相手への提出物 / 法務・行政文書: RTF が無難。Word の .docx (Office Open XML) は完全互換性が高い反面、バージョン差で崩れることがあります。RTF はもう仕様が更新されない代わりに、互換性のベースラインとしてはむしろ安定しています。
API ドキュメント / OpenAPI / Swagger UI: Markdown。OpenAPI の description フィールドは Markdown を受け付け、Swagger UI / Redoc / Stoplight いずれも CommonMark でレンダリングします。
ブラウザだけで完結する変換 / 落とし穴
Markdown と HTML の往復はブラウザ内で完結できます。markdown-html-convert は Markdown ↔ HTML を双方向に変換し、CommonMark と GFM のテーブル・タスクリストにも対応します。書きながら見た目を確認したいなら markdown-preview でリアルタイムプレビューが可能、長い文書の目次を作るなら markdown-toc が見出し階層を抽出してアンカーリンク付きの目次 Markdown を吐きます。
落とし穴は 3 つあります。1 つ目は Markdown 方言の混在 で、GFM のタスクリスト (- [ ]) や脚注 ([^1]) は CommonMark には無く、レンダリングエンジンによっては素通しされます。配布先のエンジンを事前に確認してください。2 つ目は HTML メールの CSS 対応差 で、flexbox / grid / 一部の擬似クラスはメールクライアントでサポートされず、いまでも <table> レイアウト + インライン CSS が現実解です (Outlook のために mso- プレフィックスや条件付きコメントも必要)。3 つ目は RTF の文字コード で、古い RTF は CP1252 / Shift_JIS 想定の制御語が残っており、日本語環境とのやり取りで文字化けすることがあります。Unicode を確実に通したい場合は \u エスケープが含まれる新しい RTF を使うか、.docx への移行を検討します。実装は GitHub で公開しており、変換中に文書が外部に送信されないことを DevTools の Network タブで確認できます。