Obsidian は数年で数百万ユーザーを獲得し、Notion は企業の標準ツールとなり、GitHub の README はほぼすべて Markdown で書かれている――この「プレーンテキスト復活」は偶然ではない。Word や Google Docs が長年主流だったにもかかわらず、なぜ多くの人が「より原始的」に見えるプレーンテキスト形式に回帰しているのか？答えは形式設計そのものの哲学にある。
1. 形式の戦争：.docx vs プレーンテキスト
Microsoft Word が普及する以前、エンジニアや研究者は長くプレーンテキストで文書を書いていた。Word の登場は WYSIWYG（見たままが得られる）編集という利便性をもたらしたが、同時にいくつかの長期的な問題も生んだ：
- 形式ロックイン：.docx はクローズドなバイナリ形式であり、Word や Google Docs なしでは正常に開いたり編集したりすることが難しい
- 形式の破損：バージョンの違い、フォントの欠如、スタイルの乱れはクロスプラットフォーム共有での典型的な悩みだ
- バージョン管理の困難さ：Git などのバージョン管理ツールはバイナリ形式に対してほぼ無力で、「誰が何を変えたか」を効果的に追跡できない
- 検索とインデックスの制限：バイナリ形式は全文検索を複雑にし、バックアップにも多くのストレージを必要とする
プレーンテキストにはこれらの問題がまったくない。どのテキストエディタでも開け、どのOSでも検索でき、どのバージョン管理システムでも1文字単位で変更を追跡できる、真にユニバーサルな形式だ。
2. Markdown：プレーンテキストとリッチ形式の絶妙なバランス
プレーンテキストの問題は、タイポグラフィのセマンティクスが欠如していることだ。# 見出し と書いても、レンダリングなしでは単なる一行のテキストに過ぎない。
2004年、John Gruber と Aaron Swartz は Markdown を設計した。目標は「プレーンテキストを最終的なレンダリング結果にできるだけ近い見た目にする」こと。鍵となる設計決定は：レンダリングしなくても、Markdown のソースコード自体が読みやすくなければならないということだ。
# 見出し は見出しのように見える。**太字** は強調されたテキストのように見える。- リスト項目 はリストのように見える。この「視覚的一貫性」により、Markdown はレンダリングなしでも構造が理解しやすく、ツールへの依存度が低い。
3. Markdown はどこで使われているのか？
Markdown の活用範囲は多くの人が思うより広い：
- GitHub / GitLab：すべての README、Issue、Pull Request、Wiki が Markdown をサポート
- 技術文書：Docusaurus、MkDocs、Sphinx などのドキュメントフレームワークが Markdown を中心に据えている
- ブログプラットフォーム：Hugo、Jekyll、Hexo などの静的サイトジェネレーターは Markdown で記事を書く
- ノートアプリ：Obsidian、Logseq、Joplin、Bear などは Markdown ファイルでノートを保存する
- コラボレーションツール：Notion、Confluence、Slack、Discord はいずれも Markdown 構文をサポート
- 学術執筆：Pandoc が Markdown を LaTeX、PDF、DOCX に変換でき、研究者の間で採用が増えている
4. エンジニアがとりわけ Markdown を好む理由
エンジニアにとって、Markdown は核心的な問題を解決する：ドキュメントはコードと同じ場所に置かれ、同じバージョン管理のワークフローを経るべきだ。
プロジェクトのドキュメントが Markdown であれば：
git diffでドキュメントの変更内容を行単位で確認でき、誰が何を変えたかが一目でわかる- Pull Request でコードレビューと同じツールを使ってドキュメントの変更をレビューできる
- CI/CD パイプラインでドキュメントの形式やリンクの有効性を自動検証できる
- ドキュメントとコードが同じリポジトリで共に進化し、「ドキュメントがコードに追いつかない」状況を防げる
Markdown がバージョン管理に適している根本的な理由は、プレーンテキスト形式が「2つのバージョンの差異を比較する」という作業を意味のあるものにするからだ。Word ドキュメントの差分は読みにくく、専用ツールが必要な場合もある。プレーンテキストの差分（diff）は標準化されており、どのツールでも処理でき、人間が読んで理解できる。
5. Obsidian はなぜ急成長したのか？プレーンテキストの実用的優位性
Obsidian は 2020 年にリリースされ、2年以内に100万ユーザーを超えた。核心的な設計決定は：すべてのノートをローカルの Markdown ファイルとして保存すること——クラウドデータベースではなく。
この設計は具体的なメリットをもたらす：
| 特性 | 従来のクラウドノート（Evernote 等） | Obsidian（ローカル Markdown） |
|---|---|---|
| データの所有権 | データはベンダーのサーバーに | データは自分のマシンに |
| オフライン利用 | ネットワーク同期が必要 | 完全オフラインで動作 |
| エクスポートの柔軟性 | 多くの場合有料プランが必要 | .md ファイルに直接アクセス可能 |
| 検索速度 | サーバーに依存 | ローカル全文検索で即座に応答 |
| ベンダーロックイン | 高（ツール移行に多大な労力） | 低（どのエディタでも開ける） |
Obsidian の急成長は、ある意味でベンダーロックインへの反発だ——ユーザーは、何年分ものノートを独自形式に閉じ込めることが潜在的なリスクだと気づき始めた。
6. プレーンテキストの長期保存性：20年後も読めるか？
多くの人が考えたことのない問いがある：今日書いたノートは、20年後も読めるだろうか？
1990年代の .doc ファイルは、現代の Word で開こうとすると「互換モード」が必要になることが多く、書式が崩れている場合もある。一方、1990年代のプレーンテキストファイルは、今日のどのテキストエディタでも完全に開ける——プレーンテキスト形式にはバージョンも依存関係もないからだ。
長期保存が必要な知識（日記、研究ノート、個人の知識ベース）には、プレーンテキストが現在最も時代を超えて読み続けられるデジタル形式だ。
7. Markdown の限界
Markdown は万能ではなく、適さないシナリオも存在する：
- 複雑なレイアウト：多段組、精密な画像とテキストの混在、ヘッダー・フッターのデザインには Word や InDesign が必要
- リアルタイム共同編集：複数人が同時に同じ文書を編集する場合、Google Docs のライブコラボレーション体験はほとんどの Markdown ツールを上回る
- 非技術ユーザー：構文に不慣れな人には、
**太字**よりツールバーのボタンの方が直感的だ - 複雑な表：Markdown の表構文はセルの結合や数式の設定に対応していない
ツールに優劣はなく、適材適所の問題だ。Markdown が最も輝くのは、バージョン管理、長期保存、クロスプラットフォーム共有、またはコードと共存するテキストコンテンツを扱うときだ。
8. 文字数カウント：Markdown 執筆における見落とされがちな落とし穴
Markdown で書くとき、見落とされがちな問題がある：文字数はレンダリング状態によって大きく異なる可能性がある。
生の Markdown には構文記号（#、**、[] など）が含まれており、これらはレンダリング後に消えるが、プレーンテキスト状態では文字数にカウントされる。原稿料の計算、SEO の記事長の要件、投稿規定など、正確な文字数が必要な場合は、「生の Markdown の文字数」と「レンダリング後のプレーンテキストの文字数」のどちらを数えるかを意識することが重要だ。
9. まとめ
プレーンテキストと Markdown の復活は、デジタルコンテンツに対する人々の再考を反映している：
- データの所有権：自分のノートは自分のものであり、ベンダーの形式に閉じ込められるべきではない
- 長期的な読みやすさ：プレーンテキストは時代を超えて読み続けられるデジタル形式だ
- バージョン管理との親和性：コードとドキュメントは同じワークフローを使うべきだ
- クロスプラットフォームの汎用性：Markdown はほぼすべての現代的な執筆・開発ツールでサポートされている
まだ Markdown でノートや文書を書いたことがないなら、シンプルな README や日記から始めてみよう。余分な書式設定ノイズを取り除くことで、むしろ思考がクリアになることに気づく人は多い。