LLMがMarkdownを標準とする理由
ChatGPTやClaude、あるいはほとんどのチャット型モデルに構造化された回答を求めると、デフォルトでMarkdown形式——見出し、太字、番号付き手順、フェンス付きコードブロック——で返してきます。これは偶然ではありません。Markdownはごくわずかな追加文字だけで構造を示せます。見出しのコストは#と半角スペース1つだけ、リスト項目のコストは-と半角スペース1つだけです。同じことをHTMLで表現すると——<h2>, </h2>、 <li>, </li>——になり、同じ内容を伝えるのにはるかに多くのトークンを消費します。規模が大きくなるほど、余分なトークン1つひとつがコストとレイテンシに直結します。
Markdownは、これらのモデルが学習したテキストの中にも非常に多く含まれています。GitHubのREADME、Stack Overflowの回答、技術文書、数え切れないフォーラム投稿——いずれもMarkdownを使っているため、モデルは見出しやリスト、コードフェンスが実際の構造にどう対応するかを膨大な数の例から学習しています。この馴染み深さのおかげで、Markdownはモデルが確実に生成でき、かつ自分自身（やユーザー）のテキストから曖昧さなく読み取れる構文になっています。
プロンプトの中のMarkdown
この構造的な明快さは、出力だけでなく入力側でも役立ちます。プロンプトを明確にラベル付けされたセクションに分ける——たとえば ## Context 見出し、## Task 見出し、そして## Constraints 見出しを使う——ことで、プロンプトの各部分が何のためのものかをモデルに明示できます。1つのまとまった段落から推測させる必要がなくなるのです。
- 順番通りに従ってほしい指示には、箇条書きまたは番号付きリストを使いましょう——モデルはリスト項目をひとまとめにせず、個別に扱う傾向があります。
- モデルにそのまま扱ってほしい（書き換えたり要約したりしてほしくない）コードやログ出力、テキストはフェンス付きコードブロックで囲みましょう。3つのバッククォートによる境界は、ほとんどのモデルが尊重する明確な境界です。
- 同じ形式の例をいくつもモデルに与えるときはテーブルを使いましょう——要約すべき文章ではなく、構造化データとして読み取られます。
RAG向けのドキュメント変換
検索拡張生成（RAG）パイプラインを構築するチームは、チャンク分割と埋め込みの前に、Wordファイル、Confluenceページ、Google Docs、スクレイピングしたHTMLといったソースドキュメントを日常的にMarkdownへ変換します。この変換には2つの理由があります。第一に、Markdownは見出しやリスト、テーブルといった構造的なシグナルを保持するため、チャンクの区切りとして自然で一貫性のある場所を選べます——見出しは新しいチャンクを始めるのに自然な位置です。第二に、視覚的なノイズを取り除けます。インラインスタイルやクラス名、トラッキング属性、レイアウト用のマークアップは、検索システムやモデルが利用できる意味を何も追加しないままトークン数だけを膨らませます。
こうしたパイプラインを構築しているなら、 HTMLをMarkdownに変換 と WordをMarkdownに変換 が、まさにその最初の変換ステップをブラウザ内だけで処理します——インデックス化する前にソースドキュメント自体を外部に出したくない場合に便利です。
llms.txtとは？
llms.txtは、古くからあるrobots.txtを手本にした提案中の規約で、サイトのルートに置く、最も重要なページやドキュメントを短く構造化した形式で一覧にするプレーンなMarkdownファイルです。 robots.txtがクローラーに何をインデックスしてよいかを伝えるのに対し、 llms.txtは推論時に検索を行う言語モデルやAIエージェント向けのものです——それらのモデルがすでに最も得意とする形式で書かれた、サイトのコンテンツの厳選されたマップです。
MarkdownLabも、まさにこの理由から独自のllms.txtを公開しています——ツールセットの増加に合わせて更新され続ける、このサイトのツールとリファレンスページのプレーンテキストの索引です。
実践的なパターン
- プロンプトでもドキュメントでも、モデルにセクションごとに順序立てて考えてほしい場合は、見出しで階層構造を示しましょう。
- 表形式のデータには、手で整列させたASCIIアートより本物のMarkdownテーブルを使いましょう——きれいにパースでき、トークン数も少なく済みます。
- フェンス付きコードブロックには必ず言語タグを付けましょう（
```python,```json）——コストはかかりませんし、モデルにコンテンツの構文についての明確なヒントを与えられます。 - 可能な限り深いネストのリストは避けましょう。パーサーやプロンプト処理パイプラインの中には、1〜2階層を超えるネストを平坦化してしまうものがあります。
- リンクテキスト自体に保持したい意味がある場合は、裸のURLではなく明示的なリンク構文（
[text](url)）を使いましょう。
次に読むべきもの
構文自体がまだ初めてなら、 Markdownとは や、完全な Markdownチートシートから始めてください。書く準備ができたら、 エディタ を開いて実際に試してみましょう。