ChatGPTがURLを読み込めない7つの原因と対処法

もっと危険なのは、読めていないのに要約が返ってくるケース

原因の切り分けに入る前に、こちらを先に扱います。実害が大きいのはこちらだからです。

URLの文字列には、たいてい意味のある単語が入っています。ドメイン名、カテゴリ、記事タイトルをローマ字や英語にしたスラッグ。ページ本文を一文字も読めていなくても、そこから「こういう内容の記事だろう」ともっともらしい文章を組み立てることは可能です。実際、2023年の時点で「URLに含まれる語だけで、記事を要約したように見せかけられる」という指摘がありました。

問題は、これが現在も起きうることです。有料記事のペイウォールに阻まれて本文にたどり着けなかったにもかかわらず、その事実に触れないまま自信のある要約を返した事例が報告されています。別の事例では、実際には取得できていない記事について「読んだ」と述べ、元の投稿とまったく関係のない話題の分析を提示したことが記録されています。報道機関の記事をめぐっては、提示したURLと引用が後から幻覚だったと認められたケースもあります。

つまり、返ってきた要約が「読めた証拠」にはなりません。見分ける方法は3つあります。

固有名詞と数字があるか。本文を読めていれば、人名、製品名、バージョン番号、金額、日付といった具体が要約に混ざります。逆に「〜の重要性を説明しています」「〜のメリットとデメリットを整理しています」といった、どんな記事にも当てはまる抽象的な文だけが並ぶときは疑ってください。

URLとタイトルから推測できる範囲を超えているか。URLに `react-performance` と入っていれば、Reactのパフォーマンスの話だと当てられます。それ以上の情報、たとえば「筆者はこの手法を採用しなかった」といった本文固有の内容が含まれているかを見ます。

引用を求める。いちばん確実です。「本文からそのまま3箇所引用して、それぞれ何段落目かも書いて」と追加で頼みます。読めていれば引用が出ます。読めていなければ、出せないと答えるか、実在しない一文が出てきます。その一文をブラウザのページ内検索にかければ、すぐ判定できます。

要約を仕事の判断材料にするなら、この「引用してみて」の一手間は入れる価値があります。

7つの原因を切り分ける

ここからが原因の話です。読めない理由は、ざっと7つに分かれます。症状から当たりをつけて、確かめ方で絞り込んでください。

① ログイン画面のタイトルらしきものが返る

• 疑う原因：ログインが必要なページ
• 確かめ方：シークレットウィンドウで開いてみる
• まず試すこと：本文をコピーして貼る

② 冒頭は正しいが、途中から曖昧になる

• 疑う原因：ペイウォール（有料記事）
• 確かめ方：ログアウト状態でどこまで読めるか見る
• まず試すこと：読めた範囲だけを渡す／購読者なら本文をコピー

③ タイトルだけ拾い、中身が空

• 疑う原因：JavaScriptで描画するページ
• 確かめ方：ページのソースを表示し、本文の一節で検索して出るか確認
• まず試すこと：印刷用ページ・RSS・元記事を探す

④ 取得そのものを拒否された趣旨の返答

• 疑う原因：robots.txtやアクセス制御でボットを弾いている
• 確かめ方：同じサイトの別ページでも同じになるか
• まず試すこと：アーカイブを使う／本文コピー

⑤ 時間がかかった末に失敗する

• 疑う原因：PDF・巨大なページ・HTML以外の形式
• 確かめ方：ファイル形式とサイズを見る
• まず試すこと：ファイルをダウンロードして添付

⑥ まったく違うページの話が返る

• 疑う原因：URLが違う／リダイレクト先が別物
• 確かめ方：ブラウザで開き、アドレス欄の最終URLを見る
• まず試すこと：リダイレクト後のURLを渡す

⑦ 投稿の中身が出てこない

• 疑う原因：SNS投稿（X・Instagramなど）
• 確かめ方：ログアウト状態で開いてみる
• まず試すこと：投稿本文をコピー／スクリーンショットを添付

③について補足します。ページのソースを表示するのは、Windowsなら `Ctrl+U`、Macなら `Command+Option+U` です。開いたソースの中で、記事本文にある特徴的な一文を検索してみてください。見つからなければ、そのページの本文はJavaScriptが動いた後に組み立てられています。AIのクローラは一般にJavaScriptを実行せず、サーバーが最初に返したHTMLだけを見るため、この種のページでは中身が存在しないのと同じ扱いになります。

④は、サイト側の意思によるものです。2026年9月時点では、OpenAIは用途ごとに異なるクローラーの名前を公開しており、サイト運営者は `robots.txt` でそれぞれの扱いを指定できます。ユーザーが指示して取りに行くフェッチについては扱いが別になるとされていますが、いずれにせよ、サイト側がアクセス制御をかけている場合、読者の側からできることはほぼありません。

作る側から見た景色：機械がWebページを読むのは、思ったより難しい

わたしたちは「あとで読む」URL管理アプリを作っていて、URLを貼るとタイトル・サムネイル・説明を自動で取りに行く処理を自前で持っています。本文を丸ごと読むわけではないので目的は違いますが、最初の関門はまったく同じです。1回のリクエストを投げて、返ってきたHTMLを読む。この地点で失敗するかどうかが、すべてを決めます。

実際に運用してみると、失敗の仕方が想像と違いました。「一部が取れない」のではなく、丸ごと何も取れないことがあるのです。

レスポンスヘッダが大きすぎて、取得ごと落ちる

あるサイトで、タイトルもサムネイルもファビコンも全部が空になる不具合が出ました。ブラウザで開けば普通に表示されますし、コマンドラインのツールで取ってきても中身はちゃんと返ってきます。それなのに、こちらのサーバーからだけ取れない。

原因は、本文ではなくレスポンスヘッダのサイズ上限でした。Node.jsのHTTPクライアントには、受け取れるヘッダの合計サイズに既定値16KBという上限があります。巨大な `set-cookie` などでヘッダがこれを超えると、通信そのものがエラーになります。本文は1バイトも読めていません。

やっかいなのは、この上限がツールごとに違うことです。手元のコマンドで試すと成功するので「サイトは返しているのに、うちのアプリだけ取れない」という原因の見えない状態になります。上限を512KBに広げて解消しました。

本文の読み込み量の上限に、タイトルが入らない

もうひとつの上限は、本文をどこまで読むかです。必要な情報は `<head>` の中にあるので、`</head>` に到達したら読み込みを打ち切る設計にしていました。通常のページなら数KBで終わります。

ところが、`<head>` の中に巨大なインラインJavaScriptを抱えたページがあります。そういうページでは、`<title>` やサムネイル指定が800KB付近まで出てきません。当時の上限512KBの外側です。結果、ファビコンだけは `<head>` の先頭にあるので取れて、タイトルとサムネイルは空。一見すると理屈の通らない症状ですが、原因はただのサイズ上限でした。こちらは上限を2MBに引き上げました。

ボットと見なされないための小細工が要る

素直に名乗ると、メタ情報を返してくれないサイトがあります。そのため、こちらからはブラウザに近いUser-Agentを送っています。EU圏で表示される同意ページを避けるためのCookieも付けます。使う言語も明示しています。指定しないと、日本語のサイトでも英語版のタイトルと説明が返ってくることがあるからです。

要するに、ただリクエストを投げるだけでは、人間がブラウザで見ているのと同じページは返ってこない。ここが、この仕事をしていていちばん実感するところです。

SNSは、専用の経路を用意しないと取れない

数字で見ると、差がはっきりします。ある時点で過去236件の保存を集計したところ、サムネイルの取得率は動画が100%、記事が87.6%、その他が67.7%でした。それに対して、SNSは18.2%です。ドメイン別に見ると、XとInstagramは1件も取れていません。サムネイルが欠けた保存の約6割をSNSが占めていました。

ログインの壁とボット遮断が理由です。Xについては、後から専用の取得経路を用意して、ようやく投稿の本文と画像が取れるようになりました。汎用の「HTMLを取ってきてメタ情報を読む」やり方では、どうにもならない領域があるということです。

取れなくても、保存自体は失敗させない

最後に設計の話をひとつ。これだけ失敗するので、メタ情報が取れなかったときはドメインだけを埋めて、保存そのものは成功させる作りにしています。中身を読めたかどうかと、URLを手元に残せたかどうかは、切り離すべきだと考えているからです。この点は最後の章でもう一度触れます。

タイムアウトは8秒で打ち切り、返ってきたものがHTMLでなければその時点で諦める。そういう判断の積み重ねで動いています。「読めない」はAIの手抜きではなく、Webページを機械が読むこと自体の難しさです。人間のブラウザは何十ものリクエストを投げ、JavaScriptを実行し、Cookieを持ち、多くの場合ログイン済みです。機械が見ているのは、1回のリクエストで返ってきたHTMLだけ。この差が「読み込めません」の正体です。

症状別の対処

原因が見えたら、対処は絞れます。効果の確実な順に並べます。

本文をコピーして貼る。いちばん確実で、いちばん速い方法です。原因が①〜④のどれであっても効きます。ページを開いて本文を選択し、そのまま貼り付けて「これを要約して」と頼むだけ。長い記事はいくつかに分けて渡します。迷ったらこれを選んでください。

別のURLを試す。同じ内容が、別のアドレスで提供されていることがあります。記事末尾の「印刷用」リンク、RSSフィードの全文配信、まとめサイト経由で読んでいるなら元記事のURL。これらは装飾が少なく、素のHTMLに本文が入っていることが多いため、③のJavaScript描画が原因のときによく効きます。

アーカイブを使う。過去のページを保存しているサービスに、そのURLが残っていれば、そちらを渡すという手があります。④のボット遮断が原因のときの回り道になります。ただし保存されている時点の内容なので、更新の多いページでは古い情報を掴むことがあります。

PDFを直接添付する。⑤のケースでは、URLを渡すのではなく、ファイルをダウンロードして添付するほうが確実です。2026年9月時点では、ファイルの添付は無料の範囲でも利用できますが、1日あたりの回数に上限が設けられています。スキャンしただけの画像PDFは文字情報を持たないため、うまくいかないことがある点には注意してください。

URLを整える。⑥のケースです。短縮URLは展開し、`utm_` で始まるトラッキングパラメータは落とし、ブラウザで確認した最終URLを渡します。それだけで通ることがあります。

どの対処を選ぶにせよ、作業中に「あとで試す候補」のタブが増えていきます。読めなかった記事のタブをそのまま開きっぱなしにすると、翌日には何のために開いたか分からなくなります。この溜まり方の構造についてはタブを100個開く人のためのURL退避術で扱っているので、タブが閉じられなくなっている場合はあわせて読んでください。

読めても読めなくても、元のURLは手元に残す

最後に、いちばん実務的な話をします。

要約が通ったかどうかに関係なく、元のURLは必ず手元に残してください。理由は2つあります。

ひとつは、読めなかったURLは「後で自分の目で開く」に回すしかないからです。ログインが必要なページも、有料記事も、SNSの投稿も、腰を据えて自分で開けば読めます。そのとき必要なのは行き先です。チャットの履歴を遡って探すのは、思っているより面倒な作業になります。

もうひとつは、要約が返ってきたときこそ原典が要るからです。前半で見たとおり、返ってきた要約が本文に基づいている保証はありません。判断の材料にするなら、後から原典に当たれる状態を保っておく必要があります。要約を信じる・信じないの話ではなく、確かめられる状態にしておくという話です。

残し方には、ひとつコツがあります。URLと一緒に、なぜそれを残したのかを一言書いておくことです。「要約が怪しいので原文を確認」「ログインが必要。会社のPCで開く」。この一言が、後から検索したときの手がかりになります。タイトルだけでは、自分が使う検索語と一致しません。この考え方は技術記事を死蔵させないストック運用術で詳しく扱っています。

ここで注意したいのは、保存の目的を混ぜないことです。もう一度たどり着くためのブックマークと、まだ読んでいない記事の置き場は、性質が違います。読めなかったURLは後者に属します。両者を同じ場所に放り込むと、どちらも探せなくなります。切り分け方はブックマーク・あとで読む・メモの使い分けにまとめました。

置き場所は何でも構いません。メモアプリでも、ブラウザのリーディングリストでも機能します。あとで読むURLの置き場を探しているなら、LaterListのようなURL保存ツールも選択肢のひとつです。URLを貼るだけでタイトルやサムネイル、説明を自動で取得し、その場でメモを添えられます。検索はタイトルだけでなくメモや説明文まで対象になるので、「なぜ残したか」を書いておけば後から引けます。なお冒頭で書いたとおり、メタ情報の取得に失敗しても保存自体は通るので、読めなかったURLもそのまま置いておけます。

読み込めないURLに何度も同じ質問を投げるより、本文をコピーして渡し、原典はURLで残す。この2つを習慣にするだけで、大半の場面は片づきます。

FAQ

Q. ChatGPTが要約を返してきたのに、記事の内容と違います。なぜですか。

本文を取得できていないのに、URLの文字列やタイトルから推測した内容を書いてしまうことがあるためです。読めなかったと明示せずに要約を返した事例は複数報告されています。見分け方は、固有名詞や数字といった本文固有の具体が含まれているかを確認することです。確実なのは「本文からそのまま3箇所引用して」と追加で頼み、その一文をブラウザのページ内検索にかけることです。実在しなければ、読めていません。

Q. URLを読み込めないとき、いちばん確実な方法は何ですか。

ページを開いて本文をコピーし、そのまま貼り付けて要約を頼むことです。ログインが必要なページでも、有料記事でも、JavaScriptで描画されるページでも、自分のブラウザで表示できているなら本文は手元にあります。読み込みの成否に依存しないので、原因の切り分けをする前でも使えます。長い記事はいくつかに分けて渡してください。PDFの場合は、URLではなくファイルをダウンロードして添付するほうが確実です。

Q. 有料プランにすればURLを読み込めるようになりますか。

原因によります。2026年9月時点では、Web検索は無料の範囲でも利用できるとされており、プランを上げれば必ず読めるようになる、という単純な関係ではありません。読めない原因の多くはサイト側にあります。ログインの要否、ペイウォール、JavaScriptでの描画、アクセス制御は、どのプランから見ても同じ壁です。プラン変更を検討する前に、まず原因がどれなのかを切り分けてください。