AIエージェント向けWebコンテンツ最適化：Acceptヘッダに基づくMarkdown配信の実装と落とし穴
本記事は、WebサイトのコンテンツをAIエージェントが最も効率的に読み取れる形式、すなわちMarkdown（text/markdown）で配信するための技術的な検証結果を詳細に報告しています。Webサイトの所有者や、HTTPの高度な仕様に関心を持つ開発者を対象としています。
【背景と目的】AIエージェントがWebページをクロールする際、HTMLにはナビゲーション、広告、スタイル、JavaScriptなど、本文以外の大量の要素が混入します。エージェントはこれらのノイズを解析し、本文を抽出する作業に多大な処理能力とトークンを消費します。この負担を大幅に軽減するため、同じURLに対して、クライアントがMarkdown形式を要求した場合に、本文のみをMarkdown形式で提供することが目的です。
【実装と検証】筆者は、Node.js/Express環境を用いて、クライアントの`Accept`ヘッダを解析し、`text/markdown`または`text/html`を出し分けるサーバーを構築しました。この実装は、`Accept`ヘッダの解析に`req.accepts()`のようなフレームワークの機能に頼ることで、複雑なパース処理を回避しています。
【重要な技術的落とし穴】検証の結果、以下の3つの重要な落とし穴が明らかになりました。
1. **Varyヘッダの欠如（キャッシュ層の問題）:** `Vary: Accept`ヘッダをサーバーが宣言しないと、CDNやプロキシなどのキャッシュ層が、異なるコンテンツ形式（HTMLとMarkdown）を混同し、エージェントが本来要求した形式とは異なるコンテンツを返してしまう危険性があります。これはローカル環境では再現しにくい、本番環境特有の問題です。
2. **候補配列の順序の誤解:** サーバー側のコンテンツ候補配列の順序は、クライアントが具体的な`q`値（優先度）を指定している場合や、ブラウザが標準的な`text/html`を明示的に要求している場合には影響しません。配列順が影響するのは、クライアントがワイルドカード（`*/*`や`text/*`）のみを送信した場合に限定されます。
3. **406エラーの誤判定:** クライアントの`Accept`ヘッダを単純な文字列判定（`includes`）で行うと、「なんでもいい」という意味のワイルドカード（`*/*`）を送信したボットやスクリプトを、本来は受け入れられるはずなのに406（Not Acceptable）で弾き出すという、致命的な誤動作を引き起こします。
結論として、この技術はAIエージェントとWebコンテンツの効率的な連携を可能にしますが、HTTPの高度なヘッダ（Vary, q値）の挙動を深く理解し、キャッシュ層を考慮した実装が不可欠であることが示されています。
背景
近年、AIエージェントがWebサイトの情報を読み取る機会が増加する中で、従来のHTML形式では本文以外のノイズ（広告、ナビゲーションなど）が多すぎることが課題となっています。この技術は、AIが最も処理しやすい構造化されたデータ形式（Markdown）を、HTTPの標準仕様（Acceptヘッダ）を用いて提供するための高度な対応策です。
重要用語解説
- Acceptヘッダ: クライアント（ブラウザやエージェント）が、受け取りたいコンテンツのメディアタイプ（例: text/markdown）とその優先度（q値）をサーバーに伝えるHTTPヘッダ。
- Content Negotiation: クライアントが要求する形式に応じて、サーバーが最適なコンテンツ形式を動的に選択し、提供する仕組み。
- Varyヘッダ: レスポンスが特定のHTTPリクエストヘッダ（例: Accept）の値に依存する場合、キャッシュ層に対しその依存関係を明示的に宣言するヘッダ。キャッシュの誤動作を防ぐために必須。
- 影響: 本技術が普及することで、Webサイトのコンテンツ配信がAIエージェントの利用効率を最大化する方向に進化します。開発者は、単にHTMLを公開するだけでなく、AIの読み取り特性を考慮した「データ形式の提供」を意識する必要が生じ、Web標準の進化を促すでしょう。