MarkdownがLLMを賢くする理由——コスト削減だけではない
MarkdownがLLMを賢くする理由——コスト削減だけではない
多くの人がMarkdown-to-AIワークフローを発見するきっかけはコスト削減です。WebページをHTMLからMarkdownに変換するとトークン使用量が80〜90%削減されると知り、計算してすぐに乗り換えます。
その見方は正確ですが、不完全です。トークン削減は副作用に過ぎません。MarkdownがLLMにとって優れている本当の理由は構造的なものです。Markdownは文書構造と意味的な意味が同一のフォーマットです。HTMLはそうではありません。その違いは文字数よりもはるかに重要です。
LLMがコンテンツを実際にどう読むか
なぜMarkdownが優れているかを説明する前に、言語モデルがテキストを処理するときに実際に何をしているかを理解することが役立ちます。
LLMは人間のように「読む」わけではありません。入力をトークン——それぞれ約3〜4文字のかたまり——に変換し、それらのトークンをアテンション層で処理してトークン間の関係を学習します。モデルには視覚的なレンダラーがありません。ブラウザで大きく太字に表示されているからといって、それが見出しであると推測することはできません。受け取ったトークンシーケンスだけを使って処理します。
つまり、入力テキストのシグナル品質——構造がトークン自体にどれほど明確にエンコードされているか——が、モデルがコンテンツをどれほどよく理解できるかを直接左右します。
問題：HTMLは構造と意味を分離する
HTMLはブラウザ向けに設計されており、言語モデル向けではありません。ブラウザは <div class="article-headline"> を大きな太字の見出しとしてレンダリングします。モデルはこれを見ます：
<div class="article-headline">Why Markdown Makes LLMs Smarter</div>
これはおおよそ次のようにトークン化されます：
< div class = " article - headline " > Why Markdown Makes LL Ms Sm arter </ div >
構造的なシグナル——「これがメインの見出しだ」——はクラス名の文字列の中に埋もれています。モデルは学習を通じて article-headline が重要性を示すと理解しなければなりません。たいていは正しく理解しますが、フォーマットと戦っているのであり、フォーマットを活かしているわけではありません。
さらに深いネストを考えてみてください。これは実際のWebページでは一般的です：
<div class="container">
<div class="content-wrapper">
<article class="post">
<div class="post-body">
<h2 class="section-title">Key Findings</h2>
<p>The results showed...</p>
</div>
</article>
</div>
</div>
モデルが Key Findings に到達するまでに、4つのレベルの構造的なノイズを処理しています。実際の <h2> タグだけが意味のあるシグナルであり、それはクラス名（section-title）と競合していますが、このクラス名がそれを補強するかどうかも分かりません。
MarkdownはなぜStructure（構造）とSemantics（意味）を統合できるのか
Markdownはこの問題を、構造と意味を同一にすることで解決します。「どう見えるか」と「何を意味するか」の間に分離はありません。
## Key Findings
The results showed...
## プレフィックスそのものが意味的なシグナルです。「第2レベルの見出し」という意味を明確に持ちます。クラス名も、ラッパーのdivも、競合するシグナルも一切ありません。モデルはトークンシーケンスに直接エンコードされた、必要な情報だけを受け取ります。
このパターンはすべてのMarkdown要素に当てはまります：
| コンテンツタイプ | HTMLシグナル | Markdownシグナル |
|---|---|---|
| メイン見出し | <h1> または <div class="title"> または <span id="headline"> | # |
| サブ見出し | <h2> から <h6>、またはスタイル付きdiv | ## から ###### |
| 強調テキスト | <strong>、<b>、<span class="bold"> | **text** |
| コード | <code>、<pre>、<div class="highlight"> | `code` またはフェンスブロック |
| リスト | <ul>/<li>、または <div class="list-item"> | - item |
| リンク | 周辺マークアップ付きの <a href="..."> | [text](url) |
HTMLでは各意味要素をエンコードする方法が通常3〜5通りあり、実際の使い方はサイトによって異なります。Markdownでは1通りです。その一貫性は単に整然としているだけでなく——モデルがMarkdownをより確実に処理できる理由そのものです。
実際にどう見えるか
ここに実際のテクノロジー記事の一節を2通りの方法で処理し、同じプロンプトでClaudeに送った例があります：「3つの主要な結論を要約してください」
入力A：HTMLの生の抽出（4,200トークン）
<div class="article-body">
<div class="content-section" data-section="conclusions">
<h3 class="section-heading" id="section-3">Conclusions</h3>
<div class="paragraph-wrapper">
<p class="body-text">First, the researchers found that response latency...</p>
</div>
...
</div>
</div>
結果：モデルは3つの結論のうち2つを正しく特定しました。3つ目は、モデルが非主要コンテンツと認識できなかった近くの <aside> タグの方法論的注記と混同されました。
入力B：変換済みMarkdown（890トークン）
## Conclusions
First, the researchers found that response latency...
結果：3つの結論をすべて正しく特定。<aside> のコンテンツはコンバーターによって補足的なものとして正しく除外されていたため、モデルに到達しませんでした。
トークン数は79%削減されました。精度はこの例で67%から100%に向上しました。どちらの変化も同じ原因から来ています：構造エンコードのクリーン化です。
トークン数（そしてそれが結果ではなく原因でない理由）
コストが重要なので、1,500語の技術記事を処理したデータを示します：
| 入力フォーマット | トークン数 | コスト（Claude Sonnet） | シグナル対ノイズ比 | |---|---|---|---| | 生のHTML | 16,820 | $0.050 | 約6% | | プレーンテキスト（タグ除去） | 3,450 | $0.010 | 約35% | | クリーンなMarkdown | 1,890 | $0.006 | 約92% |
コストの差は現実的です——生のHTMLより88%安くなります。しかし、プレーンテキスト（HTMLタグを単純に除去するだけ）もトークン数を大幅に削減しますが、シグナル対ノイズ比は35%のままです。プレーンテキストはすべての構造情報を失います：見出しも、強調も、リスト階層もありません。コストは下がりますが、モデルが扱える情報も減ります。
Markdownは最適点に達しています：最小トークンコストで最大の構造情報。だからこそMarkdownは単に安いだけでなく、LLM入力に適した正しいフォーマットなのです。
フォーマット品質が結果を変える3つのシナリオ
1. 要約
長い記事を要約するとき、モデルはどのセクションが主要コンテンツでどれが補足的かを特定する必要があります。Markdownの見出し階層（#、##、###）はこれを明示的にします。プレーンテキストや構造の悪いHTMLでは、コンテンツだけから推測することをモデルに強いることになり、サイドバーのコールアウト、著者プロフィール、関連記事の一文が要約に含まれる可能性が高まります。
2. Webコンテンツへの質問応答
Webページを貼り付けて特定の質問をすると、モデルはまず関連するセクションを見つけなければなりません。クリーンなMarkdownドキュメントでは、見出しトークンがモデルがナビゲートできる目次として機能します。生のHTMLでは、コンテンツに到達する前にラッパーdivとクラス属性を解析する必要があり、コンテキストウィンドウを圧迫してモデルが誤った領域に注目する可能性が高まります。
3. コード抽出
技術的なページには、散文の説明と混在したコード例がよく含まれています。Markdownのフェンスコードブロック（```）は明確な境界を作ります。モデルはコードがどこで始まりどこで終わるかを正確に知っています。HTMLでは、コードが <pre>、<code>、<div class="highlight">、または標準タグのないカスタムコンポーネントでラップされる場合があります——同じ意味コンテンツに対してすべて異なるトークンパターンです。
実践的なポイント
LLMにWebコンテンツを渡す場合——リサーチ、要約、質問応答、データ抽出のいずれであっても——使用するフォーマットは書くプロンプトと同じくらい重要です。クリーンなMarkdownはあれば良い程度のものではありません。LLMが最もよく理解するよう暗黙的に訓練された入力フォーマットです。なぜなら、学習コーパスの大部分（GitHub、Wikipedia、ドキュメントサイト、Stack Overflow）がすでにMarkdownまたはMarkdownに近いフォーマットだからです。
コスト削減はボーナスです。品質向上こそが本質です。
ワンクリックで任意のWebページをクリーンでLLM対応のMarkdownに変換。Web2MDを試す — Chrome向け無料。