Markdown for Agents の HTML 変換がエッジ内ストリーミングへ — 上限 2MiB から 6MiB に拡大、x-markdown-tokens と Content-Length は削除
Cloudflare が Markdown for Agents の HTML から Markdown への変換を、エッジ内のストリーミングエンジンによる処理へ切り替えた。従来は HTML レスポンスを全量バッファしてから別の変換サービスへ送っていたが、到着しながら逐次処理するようになり、変換のオーバーヘッドとメモリ使用量が下がる。入力サイズ上限は 2MiB（2,097,152 バイト）から 6MiB（6,291,456 バイト）へ拡大し、この上限は解凍後の HTML に適用される。破壊的変更が2つあり、変換後レスポンスから x-markdown-tokens と x-original-tokens ヘッダが無くなったため依存していたクライアントは自分でトークン数を数える必要がある。また Markdown 本文がストリーミングされるため Content-Length が再計算されず削除された。対象の API 名・バインディング名、HTML 以外の入力形式、性能の具体数値は changelog に記載が無い。
ニュース原文を読む ↗要約
Cloudflare が Markdown for Agents の HTML → Markdown 変換を、エッジ内のストリーミングエンジンによる処理へ切り替えました。
Markdown for Agents は、HTML をエージェントが読みやすい Markdown へ変換する仕組みです。 エージェントに Web ページを読ませるとき、HTML をそのまま渡すとタグとスクリプトでトークンを大量に消費します。 Markdown へ落とせば、本文だけが残ります。
従来の実装は、HTML レスポンスを全量バッファしてから別の変換サービスへ送っていました。 今回到着しながら逐次処理する方式に変わりました。公式は変換のオーバーヘッドとメモリ使用量が下がると説明しています。
入力サイズ上限が 2MiB（2,097,152 バイト）から 6MiB（6,291,456 バイト）へ拡大しました。3倍です。 この上限は解凍後の HTML に適用され、圧縮後のサイズではありません。gzip が効く HTML なら、圧縮後 300KB 程度でも解凍後 6MiB に達しえます。 上限の判定基準がどちらかは、実務で間違えやすい部分です。
ここからが重要です。破壊的変更が2つあります。
1つ目。変換後レスポンスから x-markdown-tokens と x-original-tokens ヘッダが無くなりました。 これらに依存してトークン数を把握していたクライアントは、自分で数える必要があります。
このヘッダが何に使われていたかというと、投げる前の判断です。 変換後のトークン数が分かれば、**「これは大きすぎるからモデルへ渡さない」「要約段を挟む」「モデルを変える」**という分岐が書けました。x-original-tokens と比べれば、変換でどれだけ削れたかも分かりました。 これが消えます。
2つ目。Content-Length が再計算されず、削除されました。 Markdown 本文がストリーミングされるためです。レスポンスを受け取り始める時点で、最終的なサイズが確定していません。
公式の changelog に書かれていないことを明示します。 対象の API 名・バインディング名、HTML 以外の入力形式、性能の具体数値——いずれも記載がありません。公式は Markdown for Agents のドキュメントを参照するよう案内しています。「どこで使っている機能の話か」を changelog だけで特定できない構成になっています。
何が変わったか
- HTML → Markdown 変換が、エッジ内のストリーミングエンジンによる処理に変わった（2026-10-09）
- 従来: HTML レスポンスを全量バッファしてから別の変換サービスへ送る
- 現在: 到着しながら逐次処理。変換のオーバーヘッドとメモリ使用量が下がる
- 入力サイズ上限が 2MiB（2,097,152 バイト）→ 6MiB（6,291,456 バイト）へ拡大
- 上限は解凍後の HTML に適用される（圧縮後のサイズではない）
- 破壊的変更 (1):
x-markdown-tokensとx-original-tokensヘッダが削除された- 依存していたクライアントは自分でトークン数を数える必要がある
- 破壊的変更 (2):
Content-Lengthが削除された（再計算されない）- 理由: Markdown 本文がストリーミングされるため
- changelog に記載が無いもの: 対象の API 名・バインディング名、HTML 以外の入力形式、性能の具体数値
業務インパクト（一般企業向け）
最初にやることは、x-markdown-tokens を参照しているコードの検索です。
理由は、このヘッダが「無くなった」ではなく「undefined になった」形で壊れるからです。 ヘッダが取れなくなったとき、多くの実装はエラーを出さずに undefined や 0 として扱います。 そのまま閾値比較に入ると、undefined > 100000 は false になり、「小さいから投げてよい」と判定されます。 つまり大きすぎるページをモデルへ渡す経路が静かに開きます。
これはコスト事故の形で出ます。 「トークン数を見て弾いていた」仕組みが機能しなくなり、6MiB のページがそのままモデルへ流れる。 上限が3倍になったことと組み合わせると、従来より大きなものが、従来の防御なしで通る状態になります。
検索するキーワードは3つです。 x-markdown-tokens、x-original-tokens、そして Content-Length。後者は変換後レスポンスを扱っている箇所に限ります。
トークン数が必要なら、自分で数える方法を決めてください。 選択肢は2つです。(1) 文字数やバイト数で近似する。 Markdown の本文なら、日本語混在でもおおよその比率は安定します。精度は落ちますが、閾値判定が目的なら十分です。(2) トークナイザを通して正確に数える。 使うモデルのトークナイザが手元にあるなら正確ですが、ストリーミングで受け取っている本文を全量貯めてから数えることになり、せっかく減ったメモリ使用量が戻ります。
閾値判定が目的なら (1) を選ぶのが現実的です。 正確なトークン数が必要になるのは課金の見積もりですが、それは実際のレスポンスの usage から取るのが正しいです。変換時点の推定値で課金を計算する設計は、もともと精度が出ません。
Content-Length の削除は、別の場所に当たります。 プログレス表示、バッファの事前確保、レスポンスサイズのログ記録——どれも Content-Length を前提にしていることが多い部分です。ストリーミングになったので、サイズは受け取り終わるまで分かりません。 プログレス表示は不定（スピナー）に変えるか、受信バイト数の表示に変えるしかありません。
上限 6MiB が「解凍後」である点を、設計に反映してください。 判定が解凍後なので、圧縮後のサイズでは上限に当たるかどうかが分かりません。 HTML は gzip がよく効くため、圧縮後 300KB のページが解凍後 6MiB を超えることはありえます。 「レスポンスが小さいから通るはず」という推測は成立しません。
この拡大で得られるものも押さえてください。 従来 2MiB で弾かれていたページ——大きなドキュメントサイト、長いフォーラムスレッド、データの多い一覧ページ——が変換対象に入ります。エージェントに読ませたいページが弾かれていた経験があるなら、再試行する価値があります。
社内のエラー対応手順書を確認してください。 「2MiB を超えると変換できない」と書かれた資料があれば、それは古くなりました。 サイズ超過のエラーを扱う分岐がハードコードで 2097152 を持っている場合も、定数の更新が必要です。
副業・個人活用視点
この変更は「ヘッダに依存すると壊れる」という一般則の、きれいな実例です。
レスポンスヘッダは、仕様として安定しているように見えて、実装の都合で消えます。 今回は「ストリーミングに変えたので Content-Length を出せなくなった」「変換サービスを分離しなくなったのでトークン数を数える場所が無くなった」——どちらも内部実装の変更が、インターフェースに漏れ出した形です。
記事にするなら、「undefined で静かに壊れる」という挙動を軸にすると価値があります。 公式 changelog は「ヘッダが含まれなくなりました。クライアントは自分で数えてください」と書くだけです。その結果として閾値判定が反転してコスト事故になる、という経路は書かれていません。 実際にこの経路でコストが跳ねた記録があれば、それは確実に読まれます。
保守案件の提案として形にしやすいです。 「Markdown for Agents のトークン数ヘッダが削除されました。現在このヘッダで大きなページを弾いているので、文字数ベースの近似に置き換えます。あわせて Content-Length 依存のプログレス表示を直します」——1〜2時間の作業で、効果が説明できる仕事です。しかも放置するとコストが跳ねるので、緊急度も説明できます。
個人開発では、上限が3倍になったことが実利です。 エージェントに Web ページを読ませる個人プロジェクトで、2MiB の壁に当たっていたページが通るようになります。 大きなドキュメントサイトを読ませる用途なら、差が出ます。
ただし、個人開発でこそトークン数の自前管理が必要になります。 個人の API 予算は小さいので、大きなページがそのまま流れると1回で痛い。 ヘッダに頼っていたなら、文字数ベースの簡単な上限判定を自分で入れてください。 「本文の文字数が N 文字を超えたら投げない」という3行の判定で、事故の大半は防げます。
「公式が書いていないことを数える」という観点も、記事の切り口になります。 changelog は対象の API 名もバインディング名も書いていません。「どこで使っている機能の話なのか」を特定する作業が、読者側に残されています。自分の実装のどこが該当するかを調べた記録は、同じ機能を使う人の手間を省きます。
解凍後サイズで判定されるという細部は、書く価値のある落とし穴です。 「6MiB まで通る」と覚えると、圧縮後のサイズで判断して失敗します。 HTML は gzip が効くので、圧縮後と解凍後で10倍以上の差が出ることは普通です。この種の「どちらのサイズで判定されるか」は、ドキュメントを注意して読まないと取り逃がします。