Markdownで書いた文書が、ある画面では整って見え、別の画面では記号だらけで崩れる。この現象は使い手の不注意ではなく、Markdownの作者が細部をあえて決めずに残したことの、遅れて届いた請求書です。この記事では、Markdownの考え方と基本の記法、方言が生まれた理由を整理し、同じ構図がAIへの指示を書くときにも起きることを示します。
Markdownは、変換前のまま読めることを最優先に作られた
Markdownは、2004年にジョン・グルーバーが作った軽量マークアップ言語です。目的は、読みやすく書きやすいプレーンテキストで書き、それを構造的に正しいHTMLに変換できるようにすることでした。ファイルは .md などの拡張子を持つ、ただのテキストファイルです。
設計の中心は、変換前のテキストのままでも読めることです。記号は意味が見た目で伝わるように選ばれていて、アスタリスクで囲んだ語は、そのままでも強調に見えます。公開用の形式ではなく、書くための形式だという点が、使いどころと限界を理解する鍵になります。
使われる理由は四つにまとめられます。どの端末のどのエディタでも開ける移植性、アプリが廃れても読み続けられる将来性、GitHubなど多くのサービスが対応している広がり、覚えることが少ない手軽さです。処理は、.md ファイルを作り、対応アプリがHTMLに変換し、ブラウザで表示するかPDFなどに書き出す、という順に進みます。
基本の記法は、見た目で意味が伝わる記号の集まり
- 見出し: 行頭にシャープ記号を置く。数で見出しの階層を表し、6段階まで。記号と文字の間に半角スペースを入れる
- 段落と改行: 空行で段落を分ける。行末に半角スペースを2つ置くと改行になる
- 強調: アスタリスク1つで斜体、2つで太字、3つで太字の斜体。単語の途中ではアンダースコアの扱いがアプリで違うため、アスタリスクが無難
- リスト: 行頭にアスタリスク、プラス、ハイフンのいずれかで箇条書き。数字とピリオドで番号付き。入れ子は字下げで表す
- 引用: 行頭に大なり記号とスペースを置く
- リンクと画像: 角括弧に表示する文字、丸括弧にURL。画像は先頭に感嘆符を付け、角括弧に代替テキストを書く。代替テキストはスクリーンリーダーに欠かせない
- コード: 短いコードはバッククォートで囲む。元の仕様では、行をスペース4つで字下げするとコードブロックになる
- 水平線とエスケープ: 同じ記号を3つ以上並べた行が区切り線。記号をそのまま表示したいときは前にバックスラッシュを置く
Markdownの中には生のHTMLも直接書けます。下線や複雑な表など、Markdownにない表現の抜け道です。
決めずに残した細部が、方言を生んだ
グルーバーは、ソースを読みやすく保つために、細かい特殊ケースをあえて決めずに残しました。決めていない部分は、変換エンジンを作る人がそれぞれ自分の解釈で埋めます。こうして同じテキストでも環境によって表示が変わる状況が生まれました。仕様が決めなかったことは、消えるのではなく、実装する人の数だけ別々に決められるのです。
あいまいさのない標準仕様を作ろうとしたのがCommonMarkです。GitHubは、CommonMarkを土台に、表、タスクリスト、打ち消し線、URLの自動リンクなどを加えたGitHub Flavored Markdown（GFM）を作りました。GFMは最も影響力のある方言とされますが、仕様書に矛盾があり、一部の挙動はGitHub自体の動きに依存するとも指摘されています。
ほかにも脚注、定義リスト、見出しへのID指定、ハイライトなどの拡張があり、対応はアプリによってまちまちです。書く前に、表示する場所がどの方言かを確かめるのが確実です。
チームの中にも、同じ形で方言が生まれる
方言は変換エンジンの間だけの話ではありません。記法のルールを各自の好みでとしか決めていないチームの文書は、書いた人の数だけ方言を抱えています。箇条書きの記号、見出しの深さ、空行の入れ方がそろっていない文書は、読む人と道具に解釈を任せることになります。
長く保守する文書では、GoogleやMicrosoftが公開しているスタイルガイドが参考になります。記法に複数の選択肢があるものは一つに決めて統一する、ブロック要素の間に空行を一つ入れる、見出しのレベルを飛ばさない、1行を80〜120文字程度に収めると変更の差分が読みやすい、といった要点です。markdownlintのようなチェックツールを使えば、決めたルールを自動で守らせられます。エディタは、ソースとプレビューを並べるもの、入力と同時に整形するもの（Typora、Bearなど）、共同編集するもの（StackEdit、HackMDなど）、ノートどうしをつなぐもの（Obsidian、Notionなど）から、文書の寿命と共有の範囲で選びます。
AIへの指示でも、記号より先に意味を決める
ChatGPTなどへの指示をMarkdownで構造化すると、出力の質が上がるとされます。見出しで区切れば、何が依頼で何が材料なのかをAIが取り違えにくくなるからです。返してほしい形をMarkdownで指定することもできます。
次の会議メモを整理してください。出力はMarkdownで、見出し2で「決定事項」「宿題」「次回までの論点」の3つに分け、宿題は担当者と期限の列を持つ表にしてください。ただ、見出しを立てただけで指示が明確になったと思うのは、引き出しにラベルを貼っただけで部屋が片づいたと思うのに近いものがあります。ここでの決定事項は、会議で合意したことだけなのか、ほぼ決まりそうなことも含むのか。そこを書かなければ、AIは変換エンジンと同じように、空いた部分を自分の解釈で埋めます。グルーバーの仕様が経験したことを、指示文は毎回、小さく繰り返しています。項目の名前の横に、その項目に何を入れるかを一行添えておくと、解釈の割れはかなり減ります。
構造化がどこまで効くのかは、まだはっきりしていません。モデルや作業の種類によって効き目は変わり、短い依頼なら普通の文章で十分なこともあります。記号を増やすほど良くなるわけでもありません。確かなのは、決めなかった部分は誰かが代わりに決める、ということだけです。
あなたのチームの文書で、各自の好みで書かれている記法はいくつありますか。AIへの最近の指示に立てた見出しのうち、何を入れる場所なのかを一行で説明できないものはどれでしょうか。
この記事の背景にある考え方は、拙著『ChatGPT はじめてのプロンプトエンジニアリング』の2章2節「プロンプトの基本要素」に書きました。区切り文字で見出しと箇条書きを作り、項目と内容のセットで書く方法を扱った部分で、その形を「語句とその意味を対応付ける辞書の形式のようなものです。」と書いています。この節を読むと、自分の指示文のどこが項目だけでどこに意味が書かれていないのかを、自分で見分けられるようになります。
AIの答えが物足りないとき、疑うべきはAIか、自分の言葉か。
『ChatGPT はじめてのプロンプトエンジニアリング』
AIは言葉でしか動かない。プロンプトを暗記するのをやめ、構成要素に分解して、自分の言葉で意図を込める力を鍛える本です。
読み終えたとき、手元に残るもの
- 必須、任意、形式の三つに分けたプロンプトの構造
- 回答の質を変える、意図を込めた生きたプロンプト
- 発注と検収は人が担う、AIとの役割分担
- 章末の演習プロンプト26題
4刷重版。全国の大学図書館65館が所蔵しています（2026年10月時点）。