CloudflareのMarkdown Conversionは、Markdownだけでなく記法を除いたplain textを返せるようになった。conversionOptions.output.formatにtextを指定し、結果のformatもtextになる。既定値はmarkdownなので互換性は維持されるが、後段が暗黙にMarkdownを期待するpipelineでは、形式を切り替えた瞬間にchunk境界、link、table、見出し、citationへ影響が出る。
何が変わったか
Workers bindingのenv.AI.toMarkdownとREST API /ai/tomarkdownで、conversionOptionsへoutput: { format: "text" }を指定できる。Markdown syntaxが除去されたplain textが返り、各resultのformat fieldもtextになる。指定しなければ従来どおりmarkdownである。HTML selector、image description language、PDF metadata除外などの既存optionとも組み合わせられる。
変更前後の差
従来はMarkdownを受け取り、必要なら利用側で記法を除去していた。text出力ではCloudflare側でplain text化でき、全文検索、分類、speech、PII scanの前処理を減らせる。一方heading hierarchy、link destination、code fence、table cell境界などMarkdownが保持した意味は弱くなる。API名はtoMarkdownのままなので、関数名だけで返却形式を推測してはいけない。
誰に影響するか
Workers AIでdocument conversionを行い、AI Search、Vectorize、自社vector database、LLM context、DLPへ渡す開発者が対象である。Markdown parserを後段に持つsystemはtext resultを同じschemaへ投入しない。accessibility、voice、全文検索ではtextが有利な場合があり、citationや章構造が必要なRAGではmarkdown維持を検討する。
対応期限
強制移行期限はなく、既定はmarkdownのままである。現在の呼び出しにoutputを追加しなければ挙動は変わらない。新規pipelineでは暗黙既定に依存せずmarkdownまたはtextを明示し、段階導入時はcacheとindexを別versionにする。
必要な対応
変換結果のformatをvalidateし、markdownとtextで異なる処理へroutingする。用途別に構造保持、token量、空白、list、table、link、code、OCR結果を比較する。plain textを採用しても元file、page、sectionなどcitation metadataは別fieldで保存する。cache keyへoutput formatとconversion optionsを含める。
実装・移行手順
- HTML、PDF、office文書、imageをGolden setにする。
- 同じ入力をmarkdownとtextで変換する。
- parser、chunker、embedding、検索、citationの差を測る。
- schemaにcontent_formatとconverter versionを追加する。
- text用indexをshadow構築する。
- 用途ごとにformatを固定して段階切替する。
失敗しやすい点
plain textをMarkdownから記号を消しただけとみなし、tableやcode blockの境界消失を見落としやすい。result.formatを確認せずMarkdown parserへ渡すと誤chunkが生じる。既存cacheにmarkdownが残ったままtextへ切り替えると混在する。HTML selectorとtext出力を同時変更すると、品質差の原因を切り分けられない。
リスク
構造情報の消失でcitation精度や回答根拠が低下する可能性がある。Markdown記法がpromptへ混入していたsystemではtoken削減が期待できるが、plain text化だけでprompt injectionが無害化されるわけではない。元文書の個人情報や機密情報は残るためDLPとaccess controlを維持する。
評価方法
文書種別ごとに文字数、token数、heading再現率、table再現率、link保持、chunk数、embedding cost、top-k recall、citation正確性を比較する。分類や要約用途ではtask accuracyとlatencyを見る。自前のMarkdown-to-text処理との差分も確認し、空白正規化やlist連結が意味を変えていないかspot reviewする。
ロールバック
output.formatをmarkdownへ戻せば従来形式へ戻せる。indexはformatごとにnamespaceまたはversionを分け、失敗時にmarkdown indexへroutingする。cache purgeをformat単位で行い、元文書とconversion optionを保存して再生成可能にする。consumerがtext専用schemaへ依存する前にdual-read期間を置く。
編集部の見解
plain textは単純な出力だが、RAGでは単純さが常に品質向上を意味しない。構造をLLMへ渡したい用途と、文字列だけを高速処理したい用途を分けることが重要である。APIの既定互換が保たれている今こそ、formatを明示する契約と評価setを整備すべきだ。
実務チェックリスト
- output.formatを明示した
- result.formatをvalidateする
- Markdownとtextのschemaを分けた
- cache keyへformatを含めた
- table・link・codeの差を確認した
- citation metadataを別保存した
- 検索品質とtoken量を比較した
- markdownへ戻すroutingを用意した