AI向けMarkdown配信の4条件

WebページをAIエージェントへ渡すとき、HTMLのナビゲーションや装飾まで毎回読ませる必要はありません。同じURLでも、ブラウザにはHTML、`Accept: text/markdown`を送るクライアントにはMarkdownを返す方法があります。

ただし、本文をMarkdownへ変換するだけでは不十分です。CDNやブラウザのキャッシュへ別形式が混ざらないよう、HTTPのコンテンツネゴシエーションとして実装する必要があります。

先に結論

導入判断では、次の4条件を一組で確認します。

1. Markdown応答の`Content-Type`が`text/markdown`である

2. 応答に`Vary: Accept`があり、キャッシュが形式を区別できる

3. `q`値でHTMLを優先した場合はHTMLが返る

4. 対応しないメディアタイプだけを指定した場合は`406 Not Acceptable`になる

今回の実測では、検証用サイトのMarkdown応答は2,201バイト、HTML応答は24,214バイトで、約90.9%小さくなりました。一方、現在の当ブログは`Accept`を変えても常にHTMLを返します。したがって、すぐ本番へ入れるのではなく、ステージングで4条件とCDNキャッシュを確認してから限定導入するのが妥当です。

一次情報で確認したこと

AcceptMarkdownは、クライアントが`Accept: text/markdown`を送るとMarkdownを返し、通常のブラウザにはHTMLを返す実装例です。同サイトは`Vary: Accept`、品質係数である`q`値、未対応形式への406応答も示しています。

HTTPの根拠はIETFのRFC 9110: HTTP Semanticsです。`Accept`は利用できるレスポンスのメディアタイプをクライアントが伝える要求ヘッダーで、`Vary`は選択結果へ影響した要求ヘッダーをキャッシュへ知らせます。

Markdownのメディアタイプ自体はRFC 7763で`text/markdown`として定義され、IANAの登録情報からも確認できます。独自の`application/markdown`ではなく、登録済みの型を使うのが前提です。

実際に試したこと

2026年8月27日に、検証用サイトと当ブログの記事URLへ4種類の`Accept`ヘッダーを送り、ステータス、`Content-Type`、`Vary`、UTF-8本文サイズを記録しました。

“`powershell

curl.exe -sS -D – -H “Accept: text/markdown” https://acceptmarkdown.com/

curl.exe -sS -D – -H “Accept: text/html” https://acceptmarkdown.com/

curl.exe -sS -D – -H “Accept: text/markdown;q=0.5, text/html;q=1.0” https://acceptmarkdown.com/

curl.exe -sS -D – -H “Accept: application/json” https://acceptmarkdown.com/

“`

|—|—|—:|—|—|—:|

| AcceptMarkdown | `application/json` | 406 | なし | `Accept` | 0バイト |

検証用サイトでは4条件をすべて確認できました。Markdown応答はHTML応答より22,013バイト小さく、削減率は90.9%です。ただし、これは1ページの転送サイズ比較であり、LLMのトークン数や処理時間が同じ比率で減ることを意味しません。

当ブログでは`text/markdown`を要求してもHTMLが返り、`Vary`にも`Accept`がありませんでした。これは不具合ではなく、現時点でコンテンツネゴシエーションを実装していない状態です。

WordPressへ入れる前の設計

1. 同じURLを維持する

`/article.md`のような別URLを量産すると、canonical、内部リンク、更新履歴を二重管理しやすくなります。同じ記事URLのまま`Accept`で表現だけを切り替え、HTMLを標準表現として残します。

2. Varyを必ず付ける

CDNがURLだけでキャッシュすると、Markdownを要求したAIへHTMLが返ったり、通常のブラウザへMarkdownが返ったりします。オリジンだけでなく、CDNが`Vary: Accept`を尊重するかを実レスポンスで確認します。

3. Markdownを本文だけにする

Markdown版にはタイトル、公開日、著者、本文、出典、関連記事を残し、グローバルナビゲーション、広告、追従ボタン、装飾用DOMは除きます。本文の意味を削るのではなく、ページ操作のための要素を分離します。

4. 観測可能にする

`Accept`、返した`Content-Type`、ステータス、本文バイト数をログへ残します。キャッシュヒット時も形式の組み合わせを追えるようにし、HTMLとMarkdownの混在を異常として検出します。

今日から行う3つのアクション

1. ステージングの1記事へHTML版とMarkdown版を用意し、4種類の`Accept`でステータス、`Content-Type`、`Vary`を確認する

2. CDNを経由してHTML、Markdown、HTMLの順に取得し、前の応答が次の形式へ混ざらないことを確かめる

3. 20記事でHTMLとMarkdownの本文バイト数、抽出失敗、出典リンク欠落を記録し、導入効果と品質を判断する

AI向けの出力を増やす前に、モデルごとの処理を分ける基準は「AIモデル運用を分ける3基準」で整理しています。エージェントへ渡す権限と停止条件は「AIルールを曖昧にしない4条件」も参照してください。

判断基準

最初の20記事で、形式の取り違えが0件、Markdown版の出典リンク欠落が0件、HTML版より本文サイズが継続して小さい場合だけ対象を広げます。いずれかを満たさなければ、AI向け別表現を増やす前にキャッシュ設定か変換処理を直します。

出典

Serve Markdown to AI Agents with Accept Headers / AcceptMarkdown
RFC 9110: HTTP Semantics / IETF
RFC 7763: The text/markdown Media Type / IETF
Media Types: text/markdown / IANA

著者情報

執筆・検証: しろのあ。一次情報、2026年8月27日のHTTP実測、当ブログでは未実装の内容を分けて記載しています。