HTMLファーストAI駆動開発 — Markdown一択論の4盲点

Cloudflare が「Markdown for Agents」をリリースしてから 3 ヶ月、業界の空気は「AI に渡すなら Markdown 一択」に大きく傾きました ^[1]。一方で、HtmlRAG (WWW 2025)、Google GTIG の indirect prompt injection 観測 (2026-04)、QueryBurst による cloaking 批判 (2026-02) という 3 つの新しい一次情報が、その判断停止に正面から異議を唱えています。本記事は、筆者が先月公開した

Markdown vs HTML — AI 駆動開発 5 配置場所の使い分けの続編として、

RAG 層・Web 配信層・セキュリティ層に絞り、Markdown 一択論の 4 つの盲点を扱います。想定読者は、RAG やコンテキスト注入を本番運用している（または運用直前の）シニア〜ミドルのソフトウェアエンジニアです。

「とりあえず Markdown 変換」で止まる現場

「AI に渡すドキュメントは Markdown 一択」。社内 Slack、X、テックブログ、Zenn の記事タイトルでも、ここ半年でずいぶん聞くようになりました。間違ってはいません。AGENTS.md は Linux Foundation 傘下の Agentic AI Foundation がステアードし、Codex / Cursor / Windsurf / Augment など 24 ツールが対応、リポジトリ採用数は 60,000 件超とされています ^[6]。CLAUDE.md も .cursorrules も Markdown が事実上の唯一解です。

しかし、現場で RAG / コンテキスト注入を運用してみると、引っかかります。たとえば 3 月、契約書ベースの RAG を運用しているチームが社内ナレッジを HTML から Markdown に一括変換した直後、リーガル担当から「第 7 条の機密情報の例外規定が引けない」と Slack DM が飛んできました。原因は、原本の HTML テーブルが

rowspan="2"

他にも、Cloudflare Markdown for Agents を有効化したらトークンは確かに減ったが「ブログのページだけ変換されていない」（無言で HTML が返ってきていた）、セキュリティチームから「ベンダーが indirect prompt injection の検証を要求している」と差し戻されたなど、Markdown 一択を入れた直後に出る引っかかりは複数あります。

このあたりは前回の自記事で扱った「5 配置場所 × 4 判断軸マトリクス」のスコープを超えています。前回は人間が書く CLAUDE.md やシステムプロンプトを含めた俯瞰でしたが、本記事は RAG 層・Web 配信層・セキュリティ層 に絞り、もう一段深く踏み込みます。

3 層と 4 盲点の対応関係はマトリクスで先に提示しておきます。

盲点②③ は同じ Cloudflare 機能の設計面と運用面、盲点④ は層横断という構造です。

Markdown 一択論の現在地（2026 年 5 月）

盲点を見ていく前に、現在の「Markdown 一択」論がどこに立っているのかを整理します。

最も具体的なドライバは Cloudflare の「Markdown for Agents」です。Celso Martinho と Will Allen の連名で 2026-02-12 にリリースされました ^[1:1]。AI エージェントが

Accept: text/markdown

16,180 tokens の HTML が 3,150 tokens の Markdown になり 80% 削減という具体値が示されています

^{。ただしこれは平均値ではなく、Cloudflare 自社ブログ 1 ページの実測値です。}

SearchCans の 2026 年ベンチマークシリーズも Markdown 派の代表的な情報源で、「Markdown ベースのシステムが retrieval precision で 35% 高く、answer accuracy で 28% 高い」と公表しています ^[8]。ただしこの数値はベンダー自社の測定で、ドキュメントセット n=100、使用 embedding モデルと選定基準は非公開と本人たちが付記しています。情報の重みづけは、この透明性を加味して判断してください。

もう一つ、英語圏で広く引用されている「Anthropic 内部では XML 推奨から HTML default 化へ動いている」という言説については、慎重に扱う必要があります。Tarik Davis が 2026-05-11 に書いた "Markdown vs HTML for LLM Agents: 2026 Format Showdown" の中で、Anthropic の Thariq Shihipar による発言として紹介されたものです ^[9]。筆者が WebFetch で一次ソース（Anthropic 公式ブログ・X 投稿・講演動画）を再確認した範囲では、この発言の一次裏付けは取れませんでした。本記事では「Tarik Davis 経由で報じられた二次情報」として扱います。

つまり 2026 年 5 月時点で「Markdown 一択」を支える主要根拠は、(1) Cloudflare の 1 ページ実測 80% 削減、(2) ベンダー発表のベンチマーク、(3) AGENTS.md のエコシステム拡大、の 3 つです。これらは強力ですが、配置場所が変わると効き目も変わります。次節からは、それぞれの配置場所で「Markdown 一択」が漏らす盲点を見ていきます。

盲点①: HtmlRAG は「raw HTML を渡せ」とは言っていない

最初の盲点は、HtmlRAG (arXiv 2411.02959, WWW 2025) の読解です ^[2:1]。「HTML のほうが retrieval で精度が高い」と要約されがちですが、論文を読むと、提案手法は

HTML を pruning した上で渡すものです。

著者は中国人民大学の Tan, Dou, Wang, Wang, Chen, Wen の 6 名で、WWW 2025 main conference に採択されています。評価には ASQA、HotpotQA、Natural Questions、TriviaQA、MuSiQue、ELI5 の 6 つの QA データセットが使われています。

論文の核心は圧縮率の数値です。元 HTML を基準としたとき、変換後のサイズは次のようになります。

単純な大小関係で読むと「Plain Text が最小なら Plain Text でいいのでは」となりますが、論文の貢献は 圧縮率と精度の pareto front を 6% 帯で取ったことにあります。Plain Text は確かに最小ですが、後述の retrieval 精度で ASQA Hit@1 を 8.75pt 失います。HTML-Clean は Markdown より小さく、かつ retrieval 精度が高い領域に立っている、というのが正確な読解です。さらに 2-step block-tree pruning を適用すると最終 HTML はもっと縮みます。

retrieval 精度は Llama-3.1-70B-Instruct (4K context window) で評価され、ASQA の Hit@1 は HTML 68.50 / Plain 59.75、ELI5 の Exact Match は HTML 13.25 / Plain 8.75 と HTML 側が優位です ^[2:2]。なお Llama 系と Claude / GPT 系では HTML タグの扱いに違いがあると報告されており、この優位がそのまま転写できる保証はありません（限界の節で再述）。Markdown 側との比較は論文の表で別軸ですが、HTML が retrieval 用の構造手がかり（heading、table、list ネスト）を活かしている点が一貫しています。

ここからの実務的な教訓は 2 つあります。

• 「HtmlRAG だから raw HTML を渡せばよい」は誤読。pruning ロジックを実装する責任は利用者にあります。pruning しない raw HTML はトークンを食うだけで、論文の効果を出しません。
• 構造手がかりが効くタスクで Markdown へ早く落とすと、論文の優位を捨てる。HTML→Markdown 変換は heading の階層、table の rowspan/colspan、list のネストを失わせることがあります。

実装の選択肢としては、Jina の Reader-LM v2 のような専用モデルで HTML→Markdown 変換するか、HtmlRAG ライクな block-tree pruning を自前で組むかの 2 つに大別できます。Reader-LM v2 は 1.54B パラメータ（公称 1.5B）、512K context、29 言語対応で、Jina の公表ベンチマークでは ROUGE-L 0.84、Jaro-Winkler 0.82、Levenshtein distance 0.22 と報告されています ^[10]。v1 を「selective copy」と捉えていたのを v2 では「翻訳タスク」として再定義したと公式ブログにあります。ただしこれらはすべて Jina 自社測定値であり、自社の HTML 集合で再測定してください。

「pruning を自前で組む」コストが許容できないなら、HtmlRAG をそのまま採用するのではなく「ベンチマーク優位を捨てて Markdown に倒す」判断のほうが現実的です。Markdown 一択論の落ち着けどころとして悪くありません。ただ「HtmlRAG 論文が出たから raw HTML で行ける」と早合点した状態で実装に入ると、トークン上限を踏み抜きます。

盲点②: Markdown 配信は cloaking を工業化する

視線を配信側に移します。2 つ目は、Cloudflare Markdown for Agents の運用上の副作用です。批判の急先鋒は David McSweeney の QueryBurst 記事「How Cloudflare's "Markdown for Agents" Unintentionally Breaks the Web's Trust Model」(2026-02-13) です ^[3:1]。

主張は 3 点に整理できます。

• cloaking の工業化: Cloudflare が

  Accept: text/markdown

  ヘッダを origin サーバに転送する設計のため、origin 側で「AI からのリクエスト」と「人間からのリクエスト」を区別しやすくなり、別コンテンツを返すことが容易になる。
• 抽出 boundary の short-circuit: Trafilatura のような既存のコンテンツ抽出ツールが、変換済み Markdown を別物として扱い、SEO や品質シグナルが歪む。
• One Web 原則の崩壊: 同じ URL に対して人間と AI が異なる体験を得る状態が「規格化」される。

著者自身が Hanlon's Razor（「悪意で説明できることを愚かさで説明するな」）を引いて「Cloudflare の architectural oversight（設計上の見落とし）の可能性が高い」と限定しているのは公平な姿勢です。Cloudflare 公式の反論ポイントも整理しておきます ^[4:1]。

• 機能は Opt-in 専用で、デフォルト無効。
• 利用できるプランは Pro / Business / Enterprise + SSL for SaaSに限定。Free プランは対象外。
• Origin 2MB 上限。これを超えるページは変換対象にならない。
• レスポンスには

  vary: accept

  、

  x-markdown-tokens

  、

  content-signal: ai-train=yes, search=yes, ai-input=yes

  の各ヘッダが返る。
• JSON-LD は変換後 Markdown の末尾に

  ```json

  フェンスドコードブロックとして「唯一」保持される。逆に言うとmicrodata / RDFa などの属性ベース構造化データは失われる。

ここから読み取れるのは「機能のオプトインは厳格に守られているが、有効化したテナントは『同一 URL に対する二面性』を運用に組み込むことになる」という事実です。SEO の世界では cloaking はガイドライン違反として厳しく扱われてきました。AI 文脈でこれを許容する場合、社内で「人間向け HTML と AI 向け Markdown の同一性原則」を明文化しないと、半年後にコンプライアンス監査で吊し上げになります。

判断軸として、次の 2 ケースのどちらに当てはまるかでスタンスを決められます。

• コーポレートサイト / SEO 重視: 同一性原則をテストする CI を組み込めないなら、Markdown for Agents は有効化しない。トークン削減は Reader-LM の自前変換でカバー。
• API ドキュメント / ヘルプセンター: 元から「人間向けと AI 向けで差が出ない」と保証できるコンテンツのみオプトイン。

  content-signal: ai-train=no

  を必要に応じて返す。

QueryBurst の 3 論点はベストプラクティスとして取り込み、Cloudflare の Opt-in 設計を「免責」と読み違えない姿勢が必要です。

盲点③: silent failure と tokenizer ずれ

3 つ目は地味ですが、見逃すと最も痛い類の事故です。「Markdown 化したつもりが、変換されていなかった」というやつで、Cloudflare Markdown for Agents の制約から自然に発生します。

具体的には次の経路で silent failure が起こります。

Accept: text/markdown

Accept

エージェント側で受信したペイロードが Markdown か HTML かを判定しないと、RAG のチャンク分割や embedding に渡る前に「期待は Markdown だが実体は HTML」という状態が発生します。HTML タグごと embed されると、tokenizer はタグごとに余分にトークンを消費し、トークン上限を踏み抜くか、unrelated なタグ部分が semantic 類似度に紛れ込みます。

対策はシンプルですが、明示的に組み込む必要があります。

• : Free プラン / 2MB 超過 /

  x-markdown-tokens

  ヘッダ +

  content-type

  の両観測

  Accept

  ヘッダ未送信などのケースでは HTML フォールバックが起こります。

  x-markdown-tokens

  の有無と

  content-type: text/markdown

  を両方チェックし、片方でも欠ければ変換失敗として扱うのが安全です。[4:3]
• Levenshtein 等の差分計測を CI に組み込む: Reader-LM v2 の公表値 (ROUGE-L 0.84, Jaro-Winkler 0.82, Levenshtein 0.22) は自社環境で再測定し、しきい値超えで CI 失敗にする。[10:1]
• tokenizer 一致確認: 配信側の tokenizer（OpenAI / Anthropic / Llama）と CI 側の概算 tokenizer が異なる前提で、ヘッダの

  x-markdown-tokens

  を「下限」として扱う。

特に 3 は陥りがちです。社内で Markdown の長さを行数や文字数で測っていると、実際の API 課金トークンと乖離します。

x-markdown-tokens

x-markdown-tokens

silent failure を許容するか、検出して止めるかは、配信先のコストモデルで決まります。AI assistant 統合のように出力単価が固定されているなら緩めて良いですが、エンドユーザーに従量課金で渡している（RAG ベースの法務 SaaS 等）なら、変換失敗を検出して

503

盲点④: 形式選択は indirect prompt injection の対策にならない

4 つ目は安全性です。「Markdown ならコメントタグが目立つから安全」という直感は、ここ半年の観測で完全に崩れました。

Google の Threat Intelligence Group が 2026-04-23 に公開した報告「AI threats in the wild」(Brunner / Liu / Pande) では、Common Crawl ベースで月 2〜3 B ページをスキャンした結果、悪意ある indirect prompt injection を含むページが 2025 年 11 月から 2026 年 2 月までの 4 ヶ月で約 32% 増加したと報告されています ^[5:1]。観測例には、ページ内の不可視 HTML 要素（1px サイズ・透明色）に「PayPal の取引を実行せよ」という命令が埋め込まれていたものがあり、AI エージェントが PayPal 連携を持つ場合に直接実行を促す経路として悪用されうるものです。

報告では攻撃の意図を 6 つに分類しています。harmless pranks（無害ないたずら）、helpful guidance（誘導）、SEO、deterring AI（クローラの妨害）、data exfiltration（データ抽出）、destruction（破壊）。手口は HTML / Markdown 両方にあります。

<div style="display:none">{命令}</div>

<span style="font-size:1px;color:#fff">{命令}</span>

<meta>

<title>

<!-- 命令 -->

[安全な説明](javascript:悪意ある命令)

原典は Greshake らの「Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection」(arXiv 2302.12173, 2023-02-23) ^[11]。OWASP は 2025 年版で

LLM01:2025 Prompt Injectionを最上位リスクとして掲載しています

^{。なお「OWASP LLM Top 10 2026」は本記事執筆時点で公式に存在しません。改訂版が出るまでは LLM01:2025 が現行です。}

ここから引き出せる結論は、形式選択だけでは IPI 対策にならないということです。Markdown に変換しても、コメント

<!-- -->

display:none

visibility:hidden

font-size:1px

color:#fff

• 入力サニタイズ層: Markdown のコメント、HTML の

  style="display:none"

  系を削除する前処理。
• 権限境界: AI エージェントが取れる action（決済・送信・PR マージ等）に対する人間承認ゲート。MEMORY-rich なエージェントほど威力が高くなる罠を、権限の側で塞ぐ。
• 観測・検知: LLM の入出力ログから疑わしいパターン（

  PayPal

  ×

  transfer

  のような業務外語彙の組み合わせ）を検知する。

形式選択は「安全側に倒したい」気持ちの錯覚であって、IPI 対策の代替にはなりません。

Markdown 一択を「むしろ維持すべき」3 ケース

ここまで「Markdown 一択」の盲点を 4 つ見てきましたが、本記事のスタンスは「常時 HTML」ではありません。Markdown 一択を停止すべきなのは RAG / 配信 / セキュリティの 3 層に限られ、それ以外では Markdown 一択を維持してください。逆方向の判断軸として、Markdown を維持すべき 3 ケースを挙げます。

• CLAUDE.md / AGENTS.md を HTML 化
  • 理由: Linux Foundation 傘下の AAIF がステアードする AGENTS.md 規格に対応するツールは現時点で 24 種、リポジトリ採用 60,000 件超とされています。エコシステム整合性を捨てる判断は、自前で 24 ツール分のローダを書く覚悟が必要です。[6:1]
  • 撤退条件: 「Markdown 形式で表現できない仕様が複数発生し、しかも社内エコシステムが Anthropic / Cursor の片方に固定できる」と判明した時点で再評価。
• 理由: Linux Foundation 傘下の AAIF がステアードする AGENTS.md 規格に対応するツールは現時点で 24 種、リポジトリ採用 60,000 件超とされています
• チャットプロンプト内テキストを HTML 化
  • 理由: 前回の自記事のマトリクス通り、ユーザープロンプト層では Markdown / XML タグ / プレーンの使い分けが基準であり、HTML を入れる利得が薄い。[7:1]
  • 撤退条件: 「特定タスク（NER 等）で arXiv 2411.10541 系のベンチマーク上 HTML が優位」と自社で再現できた時のみ部分的に切り替え。
• 理由: 前回の自記事のマトリクス通り、ユーザープロンプト層では Markdown / XML タグ / プレーンの使い分けが基準であり、HTML を入れる利得が薄い
• トークン上限が逼迫しているとき HTML を選ぶ

これら 3 つは「Markdown 一択」を残しておくべき領域です。本記事の主張は「すべて HTML にせよ」ではなく「4 つの盲点を回避するために、RAG 層・Web 配信層・セキュリティ層では Markdown 一択論を停止せよ」です。

4 盲点を実務に落とす — 月曜の朝の判断フロー

ここまでの議論を、月曜の朝に動ける形にまとめます。

前提: CLAUDE.md / AGENTS.md / システムプロンプト層は前回記事に委譲。以下は本記事スコープの 3 層に該当する場合の判断です。

配置場所はどこか?
├─ RAG コンテキスト   → 盲点① をチェック（pruning は誰が組むか?）
├─ Web 配信(Cloudflare 等)  → 盲点②③ をチェック（cloaking 同一性原則 / silent failure 検知）
└─ それ以外           → セキュリティ層として盲点④ を必ず通す

具体的に観測すべき指標は 3 つです。

x-markdown-tokens

usage.input_tokens

usage.input_tokens

<table>

<pre>

<code>

責務と工数の目安は規模別に整理します。

content-signal

「盲点を全部見るのは重い」と感じる場合、優先順位は配信規模 × 監査義務の高い領域から始めるのが現実的です。SLA 保証付きでエンタープライズに RAG SaaS を売っているなら盲点②③ から、社内ナレッジベースなら盲点① から、規制業種（金融・医療・公的領域）の compliance 監査基準は本記事の射程外なので 金融システム × Claude Code ガードレール設計 2026 を参照してください。

なお、本記事の月曜のアクションは shadow mode で観測 → baseline 取得 → enforce へ段階移行 が前提です。いきなり enforce すると、HTML→MD 変換の Levenshtein 閾値で大量に CI が落ちる、IPI 検出ルールの false positive で業務停止する、といった事故が起こります。shadow mode で 2 週間以上 baseline を取り、false positive 率が業務影響範囲内になってから enforce してください。

限界と向き合う

最後に、本記事の主張の限界を 4 つ明示します。

• モデル依存性: HtmlRAG の数値は Llama-3.1-70B-4K、Cloudflare の 80% 削減は同社ブログ 1 ページ、Reader-LM v2 のベンチマークは Jina 自社測定。自社環境で再測定するまで信用してはいけません[2:4][1:3]。とくに Llama 系と Claude / GPT 系では HTML タグの扱いに違いがあり、HtmlRAG の優位がそのまま転写できる保証はありません。[10:4]
• 配置場所の射程外: arXiv 2411.10541 系の Plain / Markdown / YAML / JSON / XML 形式比較は前回の自記事の領域です。本記事は RAG / Web 配信 / セキュリティ層に絞っており、ユーザープロンプトやシステムプロンプトの議論は対象外です。[7:2]
• OWASP 2026 改訂版の不在: LLM01:2025 が現行で、本記事執筆時点（2026-05-16）で 2026 版の改訂は公開されていません。「OWASP 2026」と表記している二次情報には、年号と版番号の混同があります。[12:1]
• Cloudflare 機能の陳腐化リスク:

  x-markdown-tokens

  や

  content-signal

  ヘッダ、

  Accept: text/markdown

  の挙動はベータ的な側面が残っており、半年で仕様が変わる可能性があります。本記事の指標を CI に組み込むなら、Cloudflare の changelog 監視も合わせて行ってください。[4:4]

「4 盲点はあくまで 2026 年 5 月時点のスナップショット」と読んでください。半年後に何が陳腐化しているかは、半年後に観測する以外ありません。

まとめ

Markdown 一択論を停止すべきは RAG 層・Web 配信層・セキュリティ層 の 3 層、盲点は (1) HtmlRAG は pruning 派 / (2) Markdown 配信は cloaking を工業化 / (3) silent failure と tokenizer ずれ / (4) 形式選択は IPI 対策にならない、の 4 つです。「Markdown 一択」も「HTML ファースト」も判断停止であり、配置場所 × タスク × 防御層の 3 軸で選び分けるのが、2026 年 5 月時点の誠実な落とし所です。

関連記事:

• Markdown vs HTML — AI 駆動開発 5 配置場所の使い分け（本記事の前提となる配置場所マトリクス）
• 金融系の IPI 対策: 関連自記事「金融システム × Claude Code ガードレール設計 2026」
• Hook セキュリティの考え方: 関連自記事「Mini Shai-Hulud × SessionStart Hook ガードレール 2026」

• Cloudflare Blog, "Introducing Markdown for Agents", Celso Martinho and Will Allen, 2026-02-12.

  https://blog.cloudflare.com/markdown-for-agents/／ 16,180 tokens → 3,150 tokens は同記事内 Cloudflare 自社ブログ 1 ページの実測値、平均化禁止。↩︎↩︎↩︎↩︎

• Jiejun Tan, Zhicheng Dou, Wen Wang, Mang Wang, Weipeng Chen, Ji-Rong Wen (Renmin University of China), "HtmlRAG: HTML is Better Than Plain Text for Modeling Retrieved Knowledge in RAG Systems", arXiv:2411.02959, WWW 2025 main conference accepted.

  https://arxiv.org/abs/2411.02959／ 圧縮比率 HTML-Clean 5.93% / Plain 3.29% / Markdown 9.68%、Llama-3.1-70B-4K で ASQA Hit@1 68.50 vs 59.75、ELI5 EM 13.25 vs 8.75。↩︎↩︎↩︎↩︎↩︎

• David McSweeney (QueryBurst), "How Cloudflare's 'Markdown for Agents' Unintentionally Breaks the Web's Trust Model", 2026-02-13.

  https://queryburst.com/blog/cloudflare-markdown-for-agents/／ 著者本人が Hanlon's Razor で limitation を明示。↩︎↩︎

• Cloudflare Developers, "Markdown for Agents",

  https://developers.cloudflare.com/fundamentals/reference/markdown-for-agents/／ Pro/Business/Enterprise + SSL for SaaS、Origin 2MB 上限、JSON-LD は fenced code block で保全、レスポンスヘッダ

  vary: accept

  、

  x-markdown-tokens

  、

  content-signal

  。確認日 2026-05-16。↩︎↩︎↩︎↩︎↩︎

• Google Online Security Blog, "Mitigating prompt injection attacks with a layered defense strategy" 系の調査記事「AI threats in the wild」, 2026-04-23, Brunner / Liu / Pande 共著として Google GTIG が公開。

  https://blog.google/security/prompt-injections-web/／ 月 2〜3 B Common Crawl ページスキャン、悪意ある IPI が 2025-11 → 2026-02 で 32% 増、PayPal 取引指示の不可視 HTML 埋め込み観測例、6 分類（harmless pranks / helpful guidance / SEO / deterring AI / data exfil / destruction）。↩︎↩︎

• agents.md (Agentic AI Foundation, Linux Foundation steered),

  https://agents.md/／ 60,000+ OSS 採用は同ページが提示する GitHub search スナップショット (path:AGENTS.md NOT is:fork NOT is:archived) に基づく、確認日 2026-05-16。対応ツール 24 種（Codex / Jules / Cursor / Windsurf / Augment 等）。↩︎↩︎

• 本ブログ前回記事「Markdown vs HTML — AI 駆動開発 5 配置場所の使い分け」, 2026-05-10 公開。配置場所マトリクスは本記事の前提として扱う。

  ↩︎↩︎↩︎

• SearchCans, "Markdown vs. HTML: Which is Better for RAG Ingestion? (2026 Benchmark)",

  https://www.searchcans.com/blog/markdown-vs-html-rag-benchmark/／ ベンダー自社測定、ドキュメントセット n=100、embedding モデル選定基準は記事内で非公開と明記。↩︎

• Tarik Davis, "Markdown vs HTML for LLM Agents: The 2026 Format Showdown", 2026-05-11,

  https://www.tarikdavis.co.uk/blog/markdown-vs-html-for-llm-agents-the-2026-format-showdown/／ Anthropic Thariq Shihipar の HTML default 化発言は同記事経由の二次情報、筆者の WebFetch 範囲で一次裏付けは取れず。↩︎

• Jina AI, "ReaderLM v2: Frontier Small Language Model for HTML to Markdown and JSON", 2025-01-15.

  https://jina.ai/news/readerlm-v2-frontier-small-language-model-for-html-to-markdown-and-json/／ 1.5B parameters、512K context、29 言語、ROUGE-L 0.84、Jaro-Winkler 0.82、Levenshtein 0.22（小さいほど良い）。v1 を "selective copy"、v2 を "translation process" として再定義。Jina 自社測定値。↩︎↩︎↩︎↩︎↩︎

• Kai Greshake, Sahar Abdelnabi, Shailesh Mishra, Christoph Endres, Thorsten Holz, Mario Fritz, "Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection", arXiv:2302.12173, v1 2023-02-23 / v2 2023-05-05.

  https://arxiv.org/abs/2302.12173↩︎

• OWASP GenAI Security Project, "LLM01:2025 Prompt Injection",

  https://genai.owasp.org/llmrisk/llm01-prompt-injection/／ 2026 改訂版は本記事執筆時点（2026-05-16）で未公開。HTML / Markdown injection 例は OWASP Cheat Sheet Series 側に詳細あり:https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html↩︎↩︎

GitHubで編集を提案