背景
#1123 のナレッジ下書き生成は URL を Worker で fetch し、HTML からタグを剥がして本文を LLM に渡している。SSR / SSG されていない SPA は <body> が空で、<head> の og:description しか拾えない。
実例: https://shujinko-school.jp/ は Nuxt の SPA で、本文 0 文字。下書きは og:description の 1 文だけから作られた。
候補 A: Browser Rendering で描画する
本文が取れなかった（または極端に短い）URL だけ、Cloudflare Browser Rendering の REST エンドポイント（/browser-rendering/markdown）でヘッドレス Chrome に描画させて Markdown を取る 2 段構え。
貼られた URL そのものを読むので、新店舗のようにまだ検索索引に無いページでも取れる
「参照した資料」にその URL がそのまま出る
Workers Paid に月 10 時間分が含まれ、1 ページ数秒なので月に数千ページまで追加費用なし
追加は Browser Rendering 権限の API トークン 1 つ。binding の変更は不要
候補 B: エージェント検索（Gemini googleSearch / OpenAI web search）で補う
本文が取れなかった URL について、モデルに Web 検索させて内容を補う。
取れるのは Google の索引と検索スニペット。索引時点で JS が実行されているので SPA でも内容は出るが、新しいページは索引されておらず空振りしやすい
その URL の本文ではなく検索結果なので「何を読んだか」を職員に見せられない。feat(knowledge): URL・文章・画像から curated ナレッジの下書きを作って保存する #1123
実装は SDK 上にあるツールを付けるだけで軽い。日次の利用上限（D1 か KV でカウンタ）を付ける前提
将来、URL を持たない情報（口頭で聞いた話など）を補う手段が要るなら、そのまま転用できる
判断が要る点
どちらを採るか。A は「貼った URL を読む」機能の穴埋めとして確実。B は URL 以外にも使える汎用手段
フォールバック条件（本文が N 文字未満か、__nuxt / __next などの目印か）
日次利用上限の置き場所と値
ログインが必要なページ（Instagram / X のプロフィール）は描画しても検索しても本文は取れないので対象外にする
参考
背景
#1123 のナレッジ下書き生成は URL を Worker で fetch し、HTML からタグを剥がして本文を LLM に渡している。SSR / SSG されていない SPA は
<body>が空で、<head>のog:descriptionしか拾えない。実例: https://shujinko-school.jp/ は Nuxt の SPA で、本文 0 文字。下書きは og:description の 1 文だけから作られた。
候補 A: Browser Rendering で描画する
本文が取れなかった（または極端に短い）URL だけ、Cloudflare Browser Rendering の REST エンドポイント（
/browser-rendering/markdown）でヘッドレス Chrome に描画させて Markdown を取る 2 段構え。候補 B: エージェント検索（Gemini googleSearch / OpenAI web search）で補う
本文が取れなかった URL について、モデルに Web 検索させて内容を補う。
判断が要る点
__nuxt/__nextなどの目印か）参考