AIに渡す文章は、なぜMarkdownが良いとされるのか

AIアシスタントに社内文書を参照させようとすると、「まずMarkdownに変換しましょう」という話をよく耳にします。すでにPDFやWord、Excelで文書が揃っているのに、なぜわざわざ変換する手間をかける必要があるのでしょうか。ここでは、Markdownが良いとされている理由を、根拠となる情報とあわせて整理します。ただし後述の通り、これは「常にMarkdownが唯一の正解」という話ではなく、用途やモデルによって事情が変わる点にも触れます。

構造がそのまま意味になる、とされる理由

Markdownの#や##は、単なる見た目の装飾ではなく、文書の階層構造そのものを表します。「この段落は『料金プラン』という見出しの下にある」という位置づけが、記号として明示的に書かれます。

一方、プレーンテキストやPDFから抽出した文章では、見出しは「文字が大きい」「太字になっている」といった見た目の情報でしか区別されず、テキストとして取り出した時点でその情報が失われやすくなります。AIはこの階層構造を手がかりに、いま読んでいる箇所が文書全体のどの位置づけの情報かを把握しやすくなる、と説明されることが一般的です。

表の対応関係を保ちやすい

Markdownの表記法（パイプ|で区切る表）は、行と列の対応関係を崩さずに保持できます。これに対し、PDFから抽出した表は、レイアウトの都合でセルの区切りが正しく読み取れず、本来別の行にあった値が1行に混ざって抽出されるようなケースが珍しくありません。実際、GPT-4やClaude 3.5を使ったベンチマークで、Markdown形式の表がHTML形式の表より高い精度を示したという報告もあります（Markdown vs. HTML for LLM Context）。料金表や仕様一覧のような、数値の対応関係が重要な情報ほど、この差が回答の正確さに影響しやすいと考えられます。

チャンク分割（RAG）との相性が良いとされる

大量の文書をAIに検索させる仕組み（RAG）では、文書をそのまま渡すのではなく、一定のまとまりに分割（チャンク化）してから検索対象にします。このとき、見出し単位で分割できれば、各チャンクが「1つの意味のまとまり」を保ったまま扱えます。

プレーンテキストを機械的に文字数だけで区切ると、文の途中や表の途中で分割されてしまい、チャンク単体では意味が通らない断片になることがあります。Markdownの見出し構造は、この分割位置を決めるための目印として使いやすく、Markdown形式の入力がRAGの検索精度向上やトークンコスト削減につながったという報告もあります（Why Markdown is the Preferred LLM Output Format）。

トークン効率が良いとされる場面

Markdownは装飾情報が少なく、HTMLやPDFの内部データに比べて、同じ内容をより少ないトークン数で表現できるとされています。PDFの内部データやWordのXML形式には、レイアウトや書式に関する情報が大量に含まれており、テキストだけを抜き出す変換処理を挟んでも、余分な記号やノイズが残ることがあります。AIに読み込ませる文書量が多いシステムほど、この差はコストとコンテキストウィンドウ（一度に読み込める情報量の上限）の消費に影響しやすくなります。

副次的なメリット：人間にとっても扱いやすい

ここは「AIにとって良いか」とは別の、確実に言える利点です。Markdownはプレーンテキストエディタで誰でも編集でき、Gitのようなバージョン管理の仕組みとも相性が良く、変更履歴を追いやすい形式です。AIに読ませるための変換のつもりで整備した文書が、結果として社内のドキュメント管理そのものを整理するきっかけになることも珍しくありません。

留意点：唯一の正解ではない

ここまでの内容は「Markdownが有利になりやすい場面が多い」という話であり、常にMarkdownが最適という意味ではありません。

モデルや用途によって最適なフォーマットは変わります。ある調査では、プロンプトのフォーマットによって性能が最大40%程度変わり、GPT-3.5はJSON、GPT-4はMarkdownで良い結果が出やすいという報告もあります（Markdown vs. XML in LLM Prompts）
Anthropic自身は、プロンプトの指示部分についてはXMLタグでの構造化を推奨しています。「Claudeは構造を意識するようチューニングされている」として、<instructions>のようなXMLタグで指示・文脈・例を区切ることを勧めており（Use XML tags to structure your prompts）、これは今回扱った「参照資料をどう構造化するか」とは少し異なる、「AIへの指示そのものをどう構造化するか」という話です
クレンジング済みHTMLの方が優れるとする研究もあります。2025年に発表されたHtmlRAGの論文では、見出しタグや表タグが持つ意味情報がプレーンテキスト変換で失われることを理由に、クレンジング済みHTMLの方がプレーンテキストよりRAGの精度で上回ったと、複数のQAベンチマークで報告されています（HtmlRAG）

これらを踏まえると、「社内文書をAIのナレッジベースにする」という用途では、Word・PDF・Excelのまま扱うよりMarkdownに寄せる方が扱いやすいとされるケースが多い、という位置づけで捉えるのが実務的です。

万能ではない点

一方で、Markdownで表現しきれない情報もあります。契約書の署名欄のような複雑なレイアウト、図表内に埋め込まれた情報、手書きの注釈などは、Markdown化だけでは救えません。こうした文書は、画像として保持しつつ必要な部分だけテキストで補足する、といった別のアプローチと組み合わせる必要があります。

まとめ

Markdownが良いとされているのは、「見出し構造が階層情報として残りやすい」「表の対応関係を保ちやすい」「チャンク分割の目印になりやすい」「トークン効率が良いとされる場面が多い」といった理由からです。ただしこれは万能の正解ではなく、モデルや用途（指示の構造化か、参照資料の構造化か）によって最適なフォーマットは変わり得ます。社内文書をAIアシスタントのナレッジベースとして整備する用途では、現時点ではMarkdownが有力な選択肢の一つ、という位置づけで捉えるのが実態に近いといえます。実際に社内文書をMarkdown化して整備していく実務的な進め方については、社内ドキュメントをMarkdown化して、AIアシスタントの基盤にするで扱います。