Markdownファイルはそのまま開けるべきだ

Markdownファイルはそのまま開けるべきだ

2026年になっても、Markdownドキュメントを特別なソフトウェアをインストールすることなく、ほぼあらゆるコンピューターやスマートフォンで開いて適切に表示されることを期待できないのは奇妙に思えます。Markdownは20年以上前から存在し、ドキュメント作成、執筆、公開、情報共有に不可欠なフォーマットとなっています。シンプルで、ポータブルで、人間が読め、膨大な数のアプリケーションやウェブサイトでサポートされています。それなのに、.mdファイルを受け取るといったごく普通のことが、生のフォーマット構文を眺めたり、表示できるアプリケーションを探したりすることにつながるのです。私たちは、写真を開いたり、動画を再生したり、PDFを読んだり、無数の複雑なファイルフォーマットを認識したりできるオペレーティングシステムを持っていますが、それらがどのように機能するかを考える必要はありません。Markdownも同じように扱われるべきだと私は思います。

私は長年Markdownを使っており、情報を作成し整理するお気に入りの方法の一つとなっています。私の個人ウェブサイトのコンテンツの多くはMarkdownで作成されています。なぜなら、フォーマットではなく執筆に集中できるからです。これらのファイルをGitで管理し、ほぼどんなテキストエディタでも編集し、ウェブページに変換し、独自のアプリケーションに依存することなく元のドキュメントを保存できます。今日書いた言葉が、現在使用しているすべてのアプリケーションが消滅したとしても、数十年後もアクセス可能であるという事実は、非常に心強く感じられます。Markdownドキュメントは、有用であり続けるためにアカウント、サブスクリプション、特定の企業、あるいは複雑なファイルフォーマットを必要としません。そのシンプルさこそが、コンピューティングの世界全体でファーストクラスのドキュメントとして扱われるべきだと私が考える理由です。

私たちはシンプルなものを不必要に複雑にしてしまった

Markdownの背後にある当初のアイデアの一つは、コンピューターがフォーマットを解釈する前にドキュメントが読める状態であるべきだということでした。ジョン・グルーバーは2004年にアーロン・シュワルツの助けを借りてこのフォーマットを導入し、見出し、リンク、強調、その他の一般的なドキュメント構造を表すために通常のテキストの慣習を使用しました。その結果、すべての文章をHTMLタグで囲んだり、特殊なドキュメントエディタ内で作業したりすることなく、構造化された素材を書く方法が生まれました。ソフトウェアリポジトリでREADMEファイルを開いたことがある人なら誰でも、フォーマットの名前を知らなくても、おそらくMarkdownに遭遇したことがあるでしょう。その有用性は、プログラミングを超えて、書籍、技術ドキュメント、学術ノート、出版システム、個人の知識コレクションへと広がり、成功しました。このフォーマットが成功したのは、主に作成に使用するソフトウェアにほとんど何も要求しなかったからです。

それが現在の状況を非常に残念なものにしています。Markdownはすでにプレーンテキストなので、事実上すべてのオペレーティングシステムが技術的には何らかのテキストエディタで開くことができます。欠けているのは、ファイルを単にフォーマットを記述するために使用される文字を表示するだけでなく、ドキュメントとして扱うことです。見出しは見出しのように、テーブルはテーブルのように、リンクはリンクのように表示されるべきです。元のMarkdown構文を見たい場合は、簡単にそのビューに切り替えられるべきです。これらのどれも、見慣れないユーティリティを見つけたり、プレビュー拡張機能をインストールしたり、ドキュメントを別のフォーマットに変換するアプリケーションに移動したりする必要があってはなりません。

PDFを誰かに送れば、相手のコンピューターやスマートフォンがそれに対応できると合理的に期待できます。通常、ファイルを開き、内容を読み、テキストを検索し、ドキュメントをナビゲートできます。デバイスの製造元を気にする必要はありません。Markdownも少なくともそれくらい簡単に読めるべきです。特に、基盤となるフォーマットがいかにシンプルであるかを考えるとそうです。PDFとは異なり、Markdownは直接編集できるように設計されているため、一貫したサポートはさらに価値があります。電話でドキュメントを読み、ラップトップで修正し、タブレットで作業を続けることが、基盤となるファイルを変更することなくできるべきです。これは、最新のオペレーティングシステムに期待すべき体験です。

すべてのオペレーティングシステムがMarkdownを理解すべきだ

私は当初、Appleのオペレーティングシステム間での一貫性のない体験からこのことを考え始めました。AppleはNotesにMarkdownのインポートとエクスポートを追加しましたが、これは喜ばしいことでした。しかし、ドキュメントをインポートするとNotesで使用されるリッチテキストフォーマットに変換されます。これはアプリケーション間で情報を移動するのに役立ちますが、元のMarkdownファイルを開いて編集し、その場で保存するのと同じではありません。Finder、Quick Look、Filesはすでに多くの種類のドキュメントを表示する方法を理解していますが、macOS、iOS、iPadOS、visionOS全体でMarkdownには完全なネイティブの表示および編集体験がまだありません。私はこの状況が変わることを望んでいます。なぜなら、Markdownドキュメントは、手元にあるAppleデバイスによってワークフローが変わるべきではないからです。

しかし、これはAppleだけの問題ではなく、解決策もAppleのエコシステムに限定されるべきではないと思います。Windows、Linux、Android、その他のすべての最新コンピューティング環境は、Markdownを通常のドキュメントフォーマットとして認識すべきです。Microsoftは、Windows 11のNotepadにMarkdownフォーマットを直接導入し、フォーマットされたテキストとMarkdownソースを切り替える機能を含めるなど、有望な進歩を遂げています。Linuxには素晴らしいテキストエディタとMarkdownツールがありますが、体験はディストリビューション、デスクトップ環境、インストールされているアプリケーションによって異なります。Androidにも多くの有能なサードパーティ製Markdownエディタがありますが、デフォルトのファイル処理システムを通じて一貫したフォーマットされた読み取りおよび編集体験を保証するものではありません。私たちは、業界全体に解決策の断片が散らばっていますが、体験がどこでも機能すべきだという共通の期待がありません。

私は、すべてのオペレーティングシステムがMarkdownを同一のフォント、間隔、またはビジュアルスタイルでレンダリングすることを期待しているわけではありません。実際、プレゼンテーションはユーザー自身のシステム設定とアクセシビリティの好みに従うことを好みます。一貫して保たれるべきは、ドキュメントの構造と、同じ基盤となるファイルで作業できる能力です。Linuxで作成されたMarkdownドキュメントは、Windowsで自然に開き、Androidで編集可能で、iPhoneで正しく表示されるべきです。ファイルを使用する人は、どのアプリケーションが最初に作成したか、またはオペレーティングシステムがどのMarkdownレンダリングエンジンを使用しているかを理解する必要はありません。これは、フォーマットを異なるプラットフォーム間で真に有用にする相互運用性の種類です。

私たちはすでに標準を持っている

興味深いのは、Markdownがどのように動作すべきかについての合意形成における困難な作業の多くがすでに完了していることです。元のMarkdown構文は、一部の動作を解釈の余地を残していたため、最終的にアプリケーションとレンダリングエンジンの間に違いが生じました。CommonMarkプロジェクトは、実装者向けに明確に定義された仕様と広範な例を提供することで、それらの曖昧さに対処しています。GitHub Flavored Markdownは、テーブル、タスクリスト、取り消し線、自動リンクなどの広く使用されている機能で、その基盤を構築しています。これらの規約はすでに、インターネット上で流通している膨大な量のドキュメントと書かれた素材をサポートしています。オペレーティングシステムの開発者は、これを機能させるために別のドキュメントフォーマットを考案する必要はありません。

特定のアプリケーションがサポートし、他のアプリケーションがサポートしない拡張機能は常に存在します。一部のライターは、脚注、数学的表記、図、埋め込みHTML、またはCommonMarkとGitHub Flavored Markdownを超える特殊な出版構文を使用します。私は、すべての組み込みドキュメントビューアが、可能なすべての拡張機能を正確に再現することを期待しているわけではありません。私が期待するのは、通常のMarkdownを正しくレンダリングし、アプリケーションが理解しないものをすべて保持する信頼性の高いベースラインです。ファイルを開いたり保存したりする際に、組み込みエディタがそれを表示する方法を知らないという理由だけで、見慣れない構文をサイレントに破棄してはなりません。ポータブルテキストフォーマットを使用する目的は、アプリケーションがドキュメントを保存するためにすべての可能な機能を制御する必要がないことです。

オペレーティングシステムが未知のソースからのドキュメントをレンダリングする際には、常に sensible なセキュリティ上の考慮事項があります。Markdownプレビューは、任意のスクリプトを実行したり、適切な保護なしに信頼できないコンテンツを読み込んだり、ファイルが外部リソースを参照しているという理由だけで情報にさらしたりすべきではありません。これらは、オペレーティングシステムがPDF、HTML、その他のドキュメントフォーマットを提示する際にすでに処理している馴染みのある問題です。レンダラーは、基盤となるファイルを信頼できないコンテンツとして扱いながら、有用なフォーマットを提供できます。また、数個の見出しや段落を解釈するためにクラウドサービスを必要とせず、通常のドキュメントの場合は完全にオフラインで動作することもできます。Markdownのシンプルさは、安全なネイティブ体験を構築することを容易にするはずであり、ドキュメント処理を誰かのサーバーに移動させるための言い訳にはなりません。

人工知能がMarkdownをさらに重要にしている

過去数年間の予期せぬ展開の一つは、人工知能の成長するエコシステムにおいてMarkdownがどれほど目立つようになったかということです。言語モデルは、見出し、リスト、テーブル、コード、その他の構造化情報を通常のテキストで便利に伝達できるため、応答を整理するためにMarkdown規約を頻繁に使用します。開発者は、エージェントの指示、プロジェクトドキュメント、技術仕様、およびAIツールが作業しているソフトウェアを理解するのに役立つ多くのファイルにMarkdownを使用します。コードを書いたことのない人々は、エクスポートされた会話、生成されたレポート、およびAIサービスによって作成されたドキュメントを通じてMarkdownに遭遇しています。このフォーマットは、事実上、人間とソフトウェアが構造化された書面情報を交換するための共通言語の一つとなっています。AIがより多くの日常的なワークフローの一部になるにつれて、この可視性はさらに高まると私は予想しています。

これにより、ネイティブサポートがさらに遅れているように感じられます。私たちは、膨大なドキュメントを解釈し、複雑な研究を要約し、ソフトウェアを書き、レポート全体を生成できる、ますます洗練されたツールを構築していますが、普通のコンピューターでさえ、結果のMarkdownファイルを整形されたドキュメントとして表示するために別のアプリケーションが必要になる場合があります。私はその対比を少しばかばかしいと感じます。ハッシュ記号で書かれた見出しを表示する方法を理解するために、人工知能を必要とするべきではありません。オペレーティングシステムはすでにそれを知っているはずです。Markdownをドキュメント体験の通常の part にすることで、通常のユーザーが技術的な規約を理解することなく、フォーマットの恩恵を受けられるようになります。

また、アプリケーションやサービスが、人々を独自のフォーマットに押し込めるのではなく、実際のドキュメントを交換することを奨励するでしょう。AIシステムにレポートの生成を依頼した場合、開いて、編集して、アーカイブして、好きな場所に公開できるMarkdownドキュメントを受け取りたいと思います。そのドキュメントの有用性が、作成したサービスに戻ることに依存したくありません。これは、ライティングアプリケーションからエクスポートされたノート、ウェブサイトからダウンロードされたドキュメント、同僚間で共有された情報についても同様です。Markdownは、すべての参加者が同じソフトウェアを使用することを要求することなく、構造化されたコンテンツを交換するための簡単な方法を提供します。オペレーティングシステムは、この体験をすべての人にとって親しみやすいものにするだけでよいのです。

ファイルは作成者に属するべきだ

これは、私が個人ウェブサイトを運営し、独立したウェブを探求する中で、かなり考えていることにつながります。私は、人々が自分の書いたもの、写真、ドキュメント、個人のアーカイブを含む、自分が作成したものに対するより大きな所有権を持つことを望んでいます。私たちのデジタル生活のあまりにも多くが、そのエコシステムの外部では簡単にアクセスできないフォーマットで情報を保存するアプリケーションやサービスに依存するようになっています。サービスを提供する企業は、ビジネスモデルを変更したり、価格を上げたり、機能を廃止したり、完全にシャットダウンしたりする可能性があります。時にはエクスポート機能が提供されますが、エクスポートされた素材は、それを解釈できる別のアプリケーションを見つけなければ、使用が困難になる場合があります。私たちが保持している会社が次に進むことを決定した後、自分たちの書いたものをまだ読めるかどうかを心配する必要はありません。

Markdownは、まさにその依存性を回避するため、魅力的です。ドキュメントは、ハードドライブ、USBスティック、ホームサーバー、クラウドドライブ、またはGitリポジトリに置くことができ、それを維持するために特別なサービスを必要としません。コピー、検索、バージョン管理、バックアップ、そして何年も前から存在するツールを使用して他のフォーマットに変換することができます。もし明日、あるライティングアプリケーションの使用をやめたとしても、複雑な移行を実行することなく、同じファイルを別のアプリケーションで開くことができます。この自由は、特に長期間保存したい素材にとって重要になります。私は、将来を制御できない企業のデータベースよりも、理解可能なファイルを中心に個人のアーカイブを構築することをはるかに好みます。

ネイティブMarkdownサポートは、ポータブルファイルを選択する際の残りの不便さを一つ取り除くことで、その自由を強化するでしょう。人々は、受信者が同じソフトウェアをインストールしているかどうかを心配することなく、好きなアプリケーションを使用できるようになります。オペレーティングシステムの組み込みビューアは、信頼できるフォールバックを提供し、専門のエディタは、それらを必要とする人々のために追加機能を提供し続けるでしょう。これは開発者にとって良いことですが、ドキュメントを作成する作家、学生、教師、そして特定のアプリケーションに依存しないドキュメントを保持したい人にとっても良いことでしょう。ファイルフォーマットは、それを開くのに特別な知識を必要としない場合に、はるかに親しみやすくなります。私はこれが、デジタル所有権を単に可能であるだけでなく、実践的なものにするための重要な part だと考えています。

別の独自のドキュメントエコシステムは望まない

私が最後に望むのは、Apple、Microsoft、Google、あるいは他の誰かがMarkdownを取り上げて、自社製品内で最もよく機能する、わずかに互換性のないバージョンを作成することです。私たちは何十年もの間、どのアプリケーションが作成したか、どのバージョンのソフトウェアがインストールされているか、どのオペレーティングシステムが開こうとしているかによって動作が異なるドキュメントフォーマットに対処してきました。Markdownは、反対方向に進む機会であるべきです。共通の規約、オープンな仕様、プレーンテキストストレージはすでに、業界全体が共有できる基盤を提供しています。各オペレーティングシステムは、ドキュメントフォーマットの所有権を主張することなく、これらの規約を中心にネイティブ体験を構築できます。元のファイルは、現在どのアプリケーションが表示しているかに関わらず、真実の源であり続けるべきです。

また、ネイティブサポートが専用のMarkdownアプリケーションの必要性をなくすとは思いません。出版ツール、構文拡張、ドキュメント管理、コラボレーション、テーマ、ワークフローを提供する優れたエディタがあり、これらはオペレーティングシステムの基本的なドキュメントビューアから期待するのは不合理でしょう。人々は間違いなく、それらのアプリケーションを構築し、使用し続けるべきです。ネイティブサポートは、追加ソフトウェアなしで誰もが期待できる最小限の体験を確立するだけです。画像ビューアはPhotoshopを置き換えるものではなく、組み込みPDFリーダーはプロフェッショナルなドキュメントツールの必要性をなくしません。ネイティブMarkdownビューアは同じ目的を果たし、より専門的なアプリケーションが共通の基盤の上に構築できるようにします。

その最小限の体験には、ファイルマネージャーでのフォーマット済みプレビュー、適切な閲覧ビュー、基本的なエディタ、基盤となるソースへのアクセス、および元の.mdファイルに直接変更を保存する機能が含まれるべきです。見出し、段落、リスト、リンク、テーブル、画像、コードブロックを含むドキュメント構造をサポートし、異なるニーズを持つ人々にとってコンテンツが有用になるアクセシビリティ機能が必要です。ローカルファイルとオペレーティングシステムがサポートするファイルプロバイダーで動作し、別のアプリケーションの内部ストレージに変換する必要はありません。これらの機能のどれも特にエキゾチックではなく、多くはすでに個々のアプリケーションで利用可能です。欠けているのは、それらをユーザーが自分で発見しなければならないオプションの追加ではなく、オペレーティングシステムの信頼できる part にすることです。

Markdownは普通のドキュメントになるに値する

主要なオペレーティングシステムがMarkdownをネイティブドキュメントフォーマットとして一貫して扱うことに同意することなく、Markdownをこれほど有用にできたことは驚くべきことです。ソフトウェア開発コミュニティはそれを採用し、出版システムはそれに依存し、独立したウェブサイトはそれを使用し、AIツールはそれをまったく新しいオーディエンスに紹介しています。その寿命は、このフォーマットが何か正しいことをしていることを示唆しています。特にテクノロジーが数年で登場し消えていく業界ではそうです。既存のオフィスドキュメント、PDF、または特殊な出版フォーマットをMarkdownに置き換える必要はありません。それらはすべて異なる問題を解決するため、それらのツールのすべてに場所があります。私はMarkdownが、誰でも開いて使用できるドキュメントフォーマットとして、それらの隣に場所を得るに値するとただ考えています。

Apple、Microsoft、Google、Linuxデスクトップコミュニティ、その他のオペレーティングシステム開発者が、ここにある機会を認識してくれることを願っています。それぞれがすでにドキュメントの表示、テキストの編集、ファイルの同期、情報のアクセス可能性の向上に必要なインフラストラクチャの多くを構築しています。Markdownを適切にサポートすることは、これらの機能を、すでに広く使用されており、誰もがドキュメントの制御を譲る必要のないフォーマットに接続することになります。これにより、異なるデバイスやオペレーティングシステム間での情報共有が少し容易になります。これは、コンピューティング業界が依然として不必要に複雑にしていることです。また、人々が長年保持したいものを作成する際に、オープンフォーマットを選択することを奨励するかもしれません。ほとんどのユーザーが基盤となるテクノロジーについてまったく考えなくても、それは意味のある改善となるでしょう。

これが大規模な新しいイニシアチブになったり、私たちの注意を引く別の複雑なアプリケーションになったりする必要はないと思います。コンピューターでMarkdownファイルをダブルクリックして、ドキュメントとして開きたいです。スマートフォンで受け取って、何もインストールせずに読みたいです。修正をして、ファイルを保存し、元のMarkdownが次に開く場所でも機能することを知りたいです。最も重要なのは、人々がそのオープンさがなぜ重要なのかを理解することなく、オープンなドキュメントフォーマットの恩恵を受けられるようにしたいということです。Markdownをコンピューティングの普通の part にするには20年以上かかりましたが、ついにそれを実行する時が来たと思います。

さらに読む

CommonMarkは一貫したMarkdown仕様を文書化しており、GitHub Flavored Markdown specificationは広く使用されている拡張機能を定義しています。MicrosoftのWindows Notepad Markdown announcementとAppleのMarkdown import and export documentationは、フォーマットを組み込みアプリケーションに取り込むための2つの異なるアプローチを示しています。