いいねそのPR、ちゃんと実務でハマりどころ踏んでるやつだと思うよ〜🙂 r.jina.ai について噛み砕いて説明するね。

r.jina.ai ってなに？

一言でいうと 「人間がブラウザで見たときに近い状態でページ内容を取ってきて、テキスト（Markdown）にして返してくれるプロキシ」 だよ。

https://r.jina.ai/https://example.com

みたいにすると、

• Cloudflare などの bot protection を回避できることが多い
• JSレンダリング後っぽい内容が返ってくる
• HTMLじゃなくて markdown / plain text が返る

っていう特徴があるの。

今回のPRの「Why」はかなり正しい

書いてある通りで、

• openai.com みたいなサイトは クラウドIP + bot判定 → OGP空で返す
• /api/og は 200 だけど中身が空、が一番タチ悪い😇

これ、普通に fetch でOGP取ろうとすると詰むやつ。

「What」の中身を分解すると

① meta tag extraction 強化

<meta property="og:title">
<meta name="twitter:title">

みたいな property / name 両対応は必須だし、 twitter系も見るのは現実的で◎

→ これは r.jina.ai 関係なく「正義」

② r.jina.ai を fallback に使う

ここが今回の肝だね。

流れとしては多分こう：

1. まず普通に direct fetch

2. OGP が空 or 明らかにおかしい

3. 👉 https://r.jina.ai/<url> で再取得

4. markdown から

   • title
   • description（冒頭テキスト）
   • 最初の画像URL を拾う

これ、OGPとしては荒いけど「何も出ないより100倍マシ」。

③ X-QuickLinks-OGP-Source ヘッダ

これ地味にめっちゃ良い。

X-QuickLinks-OGP-Source: direct
X-QuickLinks-OGP-Source: jina

• バグ調査しやすい
• 「このサイト jinja 経由か〜」って後から分かる
• 将来 jina 止めたくなったときも判断材料になる

運用目線で好感度高い✨

Notes の「最初の画像URLを使う」について

ここは割り切りポイントだね。

r.jina.ai は：

• OGP構造を返さない
• markdownなので意味構造が弱い

だから 「最初に出てくる画像 = hero image っぽい」 って仮定するのは、実務では全然アリ。

ただし注意点としては：

• ロゴが最初に来るサイトもある
• 記事一覧ページだと変な画像になることもある

→ でも「fallback」用途なら許容範囲👌

総評（正直どう？）

私の感想は：

• ✅ 問題設定：めちゃくちゃ現実的
• ✅ r.jina.ai の使い方：「最終手段」として正しい
• ✅ デバッグ配慮：えらい
• ⚠️ OGP精度は下がるけど、UX的には勝ち

OGPが空になる地獄を避けるための pragmatic な実装って感じで、 プロダクト的にはかなり良い選択だと思うよ。

コードあるならぜひ見たいな〜👀 「ここもうちょい良くできそう」とか一緒に突っ込みたいし、 私も頼らせてほしいやつ🙌