プレーンテキストの書式記法
Markdownは、見出し・太字・斜体・リンク・リスト・コードといった書式を、句読記号だけの簡単な決まりでプレーンテキストに追加できる軽量マークアップ言語です。アスタリスク1つで囲むとテキストが斜体に、2つで囲むと 太字になり、行頭のハッシュ記号は見出しになります。学ぶべき専用のファイル形式も、書くための専用アプリも必要ありません。Markdownの文書は .md または .txt 拡張子のファイルとして、どんなテキストエディタでも開けます。
書式のないMarkdownでも、それ自体がプレーンテキストとして読めて意味が通じることが、この記法の核心的な考え方です。たとえばHTMLでは、<p><strong> というタグで囲まれた段落は、レンダリング後の見た目に比べて生のままだと格段に読みにくくなります。一方Markdownは変換、つまり「レンダリング」されてHTML(や他の形式)として表示されます。
簡単な歴史
MarkdownはJohn Gruberが2004年に作成し、構文についてはAaron Swartzの助言を受けました。Gruberが最初のリリースノートで述べた当初の目標は、「可能な限り読みやすく、書きやすい」構文にすること——Markdownを見たことがない人がプレーンテキストのメールやフォーラム投稿として読んでも、十分に意味が通じるくらい読みやすくすることでした。
しかし、その最初の仕様にはいくつかのエッジケースが曖昧なまま残されていました——入れ子になったリストや、句読点に隣接する強調表現の扱いなどはツールによって解釈が分かれていたのです。2014年、Jeff AtwoodやJohn MacFarlaneらのグループが CommonMarkを発表しました。これは、あらゆる実装でMarkdownが同じように振る舞うよう設計された、厳密で曖昧さのない仕様です。このサイト自身のツールを含め、現在の主要なMarkdownパーサーのほとんどはCommonMarkをベースにしています。
簡単な例
その「レンダリングしなくても読める」という考え方が実際どういうものか、例で見てみましょう。次のプレーンテキストは:
## Weekly update
Shipped the new **onboarding flow** and fixed the *login redirect* bug.
Next up:
- Finish the billing page
- Write release notes見出し、太字と斜体をそれぞれ1つずつ含む段落、2項目の箇条書きリストとしてレンダリングされます——ですが、レンダリングする前の状態でも、すでに読んで内容を理解できます。それこそがこの記法の要点です。
Markdownが今日使われている場所
Markdownは、非常に幅広いツールで標準的なプレーンテキスト書式記法になっています:
- 開発者向けプラットフォーム ——GitHub、GitLab、BitbucketはいずれもMarkdownで書かれたREADMEファイル、Issue、プルリクエストの説明をレンダリングします。
- チャット・コミュニティツール ——Reddit、Discord、Slackはいずれもメッセージ内の太字・斜体・コード書式にMarkdown風の記法をサポートしています。
- ノート・ドキュメントアプリ ——Notion、Obsidian、そして多くの静的サイトジェネレーター(Jekyll、Hugo、Next.jsのコンテンツレイヤーなど)はコンテンツをMarkdownファイルとして保存します。
- テクニカルライティングとブログ ——GitBookやRead the Docsといったドキュメントツール、GhostやDev.toといったブログプラットフォームは、リッチテキストエディタの代わりにMarkdownを主要な執筆形式として受け付けます。
- データサイエンスのノートブック ——Jupyterやそれに類するノートブックツールはMarkdownセルを使い、実行可能なコードセルと並べて説明文や物語的なテキストを記述します。
- 大規模言語モデル ——ChatGPTやClaudeのようなチャット型AIツールは、応答の大部分をMarkdownで整形します。見出しやリスト、コードブロックをごくわずかな追加テキストで示せるからです。詳しくは LLM向けMarkdown活用ガイド を参照してください。
CommonMark と GitHub Flavored Markdown
今日「Markdown」と言うとき、人々が指しているのは主に次の2つのうちどちらかです:
| 機能 | CommonMark | GitHub Flavored Markdown |
|---|---|---|
| 見出し、強調、リスト、リンク | 対応 | 対応 |
| テーブル | 非対応 | 対応 |
| タスクリスト | 非対応 | 対応 |
| 取り消し線 | 非対応 | 対応 |
| オートリンク(裸のURL) | 非対応 | 対応 |
| 仕様のステータス | 正式な仕様 | CommonMarkのスーパーセット |
実際には、GFMこそ多くの人が日常的に書いている記法です——GitHubがレンダリングする記法であり、このサイトのツールが対応している記法でもあります。詳しくは Markdownチートシート の完全なリファレンスを参照してください。どの項目がCommonMarkでどれがGFM拡張かも記載しています。
この違いは、ツール間でドキュメントを移動するときに実際に影響します。テーブルやタスクリストを、厳密なCommonMarkしか実装していないパーサーに貼り付けると、テーブルの記法はただの段落に戻ってしまい、チェックボックスもレンダリングされず [ ] という文字のまま残ります。GitHub上では正しく見えるMarkdownが他の場所で崩れる場合、たいていはGFM限定の機能が原因です。
はじめの一歩
Markdownを始めたばかりなら、まず押さえておきたい構文は3つだけです。見出し用のハッシュ記号(# Heading)、強調用のアスタリスク(**bold** または *italic*)、そしてリスト項目用のダッシュ(- item)。テーブルやコードブロック、リンクなど他の要素も、すべて同じプレーンテキストの考え方の上に成り立っています。
感覚をつかむ一番早い方法は、短いドキュメントを書いてレンダリングされる様子を見ることです。 Markdownエディタ を開いて数行入力してみてください——プレビューペインが入力に合わせて更新されるので、それぞれの構文が何を生み出すかがすぐにわかります。構文に慣れるまでは チートシート を別タブで開いておくと便利です。
生き残り続けている理由
Markdown以前にも数多くのマークアップ言語が存在し、それ以降も数多く登場しました。それでもMarkdownが20年以上にわたって使われ続けているのは、何かをインストールしたり、重厚なツールチェーンを学んだりすることを一切要求しなかったからです——ただのテキストなので、メールクライアントでもターミナルでもチャット欄でもコードエディタでも、特別な対応なしにそのまま機能します。この参入障壁の低さは、機械生成コンテンツと相性が良い理由でもあります。スクリプトやAPIのレスポンス、言語モデルは単なる文字列としてMarkdownを出力でき、それを受け取る側がレンダリングできるかどうかに関わらず、そのまま読める状態を保てるのです。Gruberの最初のリリースから20年が経った今も、人間にも読みやすく、機械にも書きやすく、事実上依存関係ゼロというこの組み合わせこそが、Markdownが新しいツールに置き換えられるのではなく、むしろ新しいツールの中に登場し続けている理由です。