【AI検索のエラー原因を知る！】ChatGPT, Felo, Perplexityに『指定されたURLにアクセスできません😢』と言われたら
FeloやPerplexityのようなAI検索サービスを使っていると、『指定されたURLにはアクセスできません😢』などのエラー回答が返ってくることがあります。最新情報にアクセスできることが強みのサービスなのに残念な気持ちになりますよね。
今回は、このエラーの原因について調査してまとめてきたので、参考にしてみてください。（*なお、調べた限りではAI検索の仕組みは公開されていなかったため、推測が混じった内容となることにご留意ください）
🔰用語解説
①キャッシュ
一度見たデータをすぐに見られるように一時的に保存する仕組み。これで、ページの読み込みが速くなりますが、古い情報になることもあります。
②クロール
ネット上のページを次々と見て、情報を集めること。検索エンジンが使う「クローラー」プログラムが、リンクをたどりながら情報を集めます。
③クローラAPI
クロールで集めたデータを簡単に取り出せるサービス。すでに集めたデータから、必要な情報をすぐに引き出せるので、情報収集が速くなります。
④直接取得
欲しい情報をその場でサイトから取りに行く方法。最新情報がすぐに手に入りますが、アクセスが集中するとエラーが出ることもあります。
*以下長いので、まとめまで飛ばして読めばおおよそ掴めると思います。
■1. AI検索サービスの構造とリクエストの流れ
FeloやPerplexityは、ユーザーが入力した質問やリクエストに応じて、インターネット上から必要な情報を検索して取得し、それを解析・統合して回答を提供します。
ユーザークエリの解析：ユーザーが入力した質問を自然言語処理で解析し、検索に必要なキーワードやクエリ構造を生成します。
外部サイトへのリクエスト送信：インターネット上の情報を取得するため、検索インデックスや外部サイトへリクエストを送信します。
リトリーバルと応答の合成：取得したデータを解析し、最適な応答を合成または要約して提供します。単にデータを生成するのではなく、収集した情報をもとに適切な回答を構築する仕組みです。
・エラー発生の主な要因
AI検索サービスのリクエストに対するエラーが発生する要因は、以下のように7つに分類できます。
2.1 アクセス制御とレートリミッティング（Rate Limiting）
多くの外部サイトは、サーバー負荷を管理するため、レートリミッティングというアクセス制御を導入しています。この仕組みは、特定のIPアドレスやユーザーエージェントからの短期間の大量アクセスを一時的に遮断するものです。
例：Feloが特定のニュースサイトに10回/分以上アクセスすると、そのサイト側がレートリミットを発動し、FeloのIPアドレスからのアクセスを一時的にブロックする場合があります。
2.2 ユーザーエージェントとBot検知
多くのWebサイトは、ユーザーエージェント（アクセス元の種類を示す情報）に基づいて、Botを検出しブロックする仕組みを持っています。FeloやPerplexityはクエリに応じた情報収集エージェントですが、自動化されたアクセスとしてBotとみなされることがあり、アクセス制限がかかることがあります。
例：Perplexityが特定のニュースサイトにBotユーザーエージェントでアクセスしようとした場合、そのサイトが「Botからのアクセス禁止」を設定しているとリクエストがブロックされます。
2.3 IPアドレスの動的制限（IP-Based Blocking）
AI検索サービスは同一IPアドレスから短期間に大量のリクエストを送信するため、特定のサイトで「攻撃」とみなされることがあります。その結果、同一IPアドレスからのアクセスが一時的、または長期間にわたってブロックされることがあります。
例：FeloやPerplexityは複数のIPアドレスを使い回す仕組み（IPプール）を導入していることもありますが、IPアドレス数に限りがあるため、制限を超えると全体的にアクセスが不安定になります。
2.4 CDNとエッジサーバーのキャッシュ・負荷分散の影響
多くのサイトは、**CDN（コンテンツ配信ネットワーク）**を利用し、ユーザーに地理的に近いサーバーからコンテンツを配信します。このため、FeloやPerplexityのリクエストが同じURLに対しても異なるエッジサーバーに振り分けられることがあり、エッジサーバーによってキャッシュの有無やアクセス制御が異なることもあります。
例：FeloがあるWebサイトの情報を取得する際、エッジサーバーにキャッシュがあれば迅速に応答が返りますが、キャッシュがない場合はリクエストがバックエンドに転送され、制限がかかりエラーが発生することがあります。
2.5 HTTPリトライメカニズムと指数バックオフ
FeloやPerplexityには、リクエストが失敗した際に再試行するリトライメカニズムが実装されています。このリトライでは、指数バックオフ（Exponential Backoff）を用いて再試行間隔を段階的に延ばします。ただし、再試行回数や間隔には上限があり、回数が増えすぎるとリクエスト全体が失敗します。
例：Feloが特定のニュースサイトに対して複数回リトライしても、最終的にリトライ制限を超えるとクローリング全体が失敗するケースです。
2.6 タイムアウトとサーバー応答の遅延
外部サイトの応答が遅い場合、FeloやPerplexityが設定しているタイムアウト時間内に応答が得られないことがあります。これはサーバー負荷の影響やインターネット接続状況によりリクエストが遅延している場合です。
例：Perplexityがニュースサイトにアクセスする際、サイト側の応答が遅いため、リクエストがタイムアウトになりエラーが返される場合です。
2.7 認証（セッション管理とトークン）
多くのWebサイトは認証トークン（セッションの鍵のようなもの）を発行し、ユーザーごとにアクセスを管理しています。トークンが無効になると再認証が必要で、それが行われない限りアクセスが拒否されます。
例：Perplexityが特定サイトの情報を取得しようとした際にセッションが切れていると認証エラーが発生し、再認証が必要になることがあります。
・FeloやPerplexityの挙動による影響
これらのAIサービスでエラーが発生した場合、リトライメカニズムやユーザーエージェントの変更、異なるIPアドレスの利用などで、再度アクセスを試みます。成功する場合もありますが、これはエッジサーバーやキャッシュの状態が変わるなどの要因により成功率が変動するからです。
これらの要因が絡み合い、特定のリクエストが失敗する一方で、別のリクエストが成功するなど、アクセスの成否が条件に応じて変動する現象が発生します。
■2. ユーザープロンプトによるクローラAPIと直接取得の切り替え
FeloやPerplexityは、ユーザープロンプト（指示内容）に応じて「クローラAPI経由」と「直接取得」の2つのパターンで情報を検索すると推測されます。各方法の違いとその選択に影響する要因、さらにそれによるエラー原因について解説します。
・クローラAPI経由での取得
・直接取得
1. クローラAPI経由での取得と、直接取得の違い
FeloやPerplexityのようなAI検索サービスで利用される「クローラAPI」は、インターネット上の情報を事前にクローリングし、データベースに保存して提供するAPIサービスを指します。
こうしたAPIは既存のクローリングデータを提供するため、アクセスが安定して速く、エラーが少ないのが特徴です。ただし、リアルタイム性はやや制限されることがあります。代表的なクローラAPIサービスには、Bright Data（旧Luminati）、ScraperAPI、Diffbotなどがあります。
クローラAPI経由：キャッシュデータや事前取得済みデータを提供するため、リアルタイム性はやや低くなりますが、安定して情報が得られます。APIによっては、最新データ取得に対応しているものもあります。
直接取得：特定のURLにリアルタイムで直接アクセスして情報を取得する方法です。最新の情報が得られますが、エラーやレートリミットの影響を受けやすく、安定性が低い場合もあります。
2. 切り替えが発生する主な要因
FeloやPerplexityがクローラAPIと直接取得を動的に切り替える背景には、以下の要因が考えられます。
2.1 プロンプトの意図と情報の「鮮度」
ユーザープロンプトの内容に応じて、情報の鮮度が重要視される場合とそうでない場合があります。たとえば、ニュース記事やリアルタイムのSNS投稿が求められる際には「最新情報」が必要となり、直接取得が優先される傾向があります。
クローラAPIの利用：プロンプトが一般的な質問（例：「犬の飼い方」）の場合、すでに取得済みの情報が利用できるため、クローラAPI経由が選ばれることが多いです。
直接取得の利用：一方で、「昨日のスポーツニュース」や「現在の天気」など最新情報が求められるプロンプトの場合、リアルタイム取得が優先され、直接取得が選ばれます。
2.2 対象サイトのアクセス制限とレートリミットの状態
多くのWebサイトでは、クローラやBotによるアクセスを制限するため、レートリミットやアクセス頻度制限を設けています。クローラAPIはこうした制限を回避するために、以下のようなテクニックを用いることが一般的です：
Bright DataやScraperAPI：これらのサービスはプロキシIPプールを活用し、多数のIPアドレスからアクセスを分散することでレートリミット回避を行います。
Diffbot：対象ページのHTML構造を解析し、必要なコンテンツだけを効率的に抽出する設計で、最小限のリクエストで情報を収集できるようになっています。
一方で、直接取得ではこうした回避策をとりにくく、レートリミットやブロックが頻発しやすいため、エラー発生率が高くなります。
2.3 システム負荷とリソース管理の効率化
FeloやPerplexityでは、アクセス頻度が高く負荷がかかる時間帯に、システムリソースを効率的に管理する必要があります。このため、サーバー負荷が高い場合には、クローラAPIのキャッシュ情報が優先されることが多く、安定的に情報を提供するよう調整されます。
バックオフ（負荷回避）：高負荷時には、Bright DataやScraperAPIといったクローラAPIのキャッシュを利用し、サーバー負荷を分散させます。
直接取得の制限：負荷が少ない時間帯では直接取得が許容されやすく、最新の情報が提供されやすくなります。
この動的な切り替えによって、サーバー負荷の調整とエラー発生リスクの軽減を図っています。
2.4 アクセス成功率と再試行（リトライ）メカニズム
アクセス成功率が低い場合、再試行が必要となるため、以下のリトライメカニズムを利用して成功率を向上させる工夫がされています。
指数バックオフ（Exponential Backoff）：失敗が続いた場合、リトライの間隔を長くする方式です。最初の試行で失敗すると1秒後、次は2秒後といったようにリトライ間隔が延長されます。
APIの優先利用：リトライが一定回数失敗した場合、再試行の代わりに、クローラAPI経由でキャッシュ情報を提供し、安定性を確保する仕組みです。
こうしたメカニズムにより、直接取得が成功しない場合でもキャッシュデータを提供し、ユーザーに対する回答の提供を継続します。
3. 切り替えにより発生する問題
動的な切り替え機能があっても、以下のような要因によってエラーが発生するリスクがあります。
3.1 情報の鮮度とキャッシュの不整合
クローラAPIを利用する場合、キャッシュ情報が古くなることがあります。そのため、最新情報を求めるプロンプトに対してクローラAPI経由が選ばれると、期待するほど新しい情報が得られないリスクがあります。
例：Feloが最新ニュースに関する質問に対しクローラAPIのキャッシュ情報を提供した場合、情報が古くなるリスクがあり、直接取得が必要な場合でも制限によりAPIが選ばれると、鮮度の問題が発生します。
3.2 サイトごとのレートリミッティングとAPIリクエスト制限の競合
多くのクローラAPIには利用制限があり、APIの上限に達するとアクセスエラーが発生します。また、対象サイトのレートリミットに引っかかることもあり、直接取得もAPI経由もエラーが返される場合があります。
例：FeloがAPIと直接取得の両方を試みても制限により情報が取得できない場合、再試行が必要となりユーザーの待ち時間が増加します。
3.3 ユーザープロンプトの意図に応じた切り替えの誤動作
プロンプトの内容が曖昧な場合、システムが最新情報の必要性を誤解し、不適切な経路（API経由や直接取得）を選択する可能性があります。たとえば「今日の天気」といったプロンプトに対しキャッシュデータが提供されると、期待する最新情報が得られません。
例：プロンプト内容の意図解析が不十分だと、API経由のキャッシュが選ばれ、新しい情報が取得できず不満足な回答が返されます。
まとめ
「指定されたURLにはアクセスできません」というエラーが発生する背景には、以下のように複数の技術的要因が絡み合っています。
サイト側のアクセス制御やリクエスト制限：IPやユーザーエージェントによる制限
AIシステムのキャッシュ機構とクエリ処理の効率化：キャッシュとリアルタイムアクセスの競合
エッジサーバーと負荷分散の影響：アクセスするサーバーの違い
再試行メカニズムとアクセス方式の切り替え：異なるアクセス方法での再試行
NATとIPプールの使用状況：異なるIPでのアクセス成功と失敗の変動
サイト側の動的制限や負荷状況：アクセス集中時の動的制限
タイムアウトやリトライポリシー：クライアント側の再試行設定
これらが複合的に影響し、アクセスの成否が条件によって変動する現象が発生します。
また、FeloやPerplexityにおける「クローラAPI経由」と「直接取得」の切り替えは、以下の要因によって行われています。
プロンプトの内容に基づく情報の鮮度要件
対象サイトのレートリミットとBot検出の状態
システムの負荷状態と効率的なリソース管理
再試行回数やリトライメカニズムによるエラー回避
情報の鮮度とキャッシュの不整合
API利用制限とアクセス制限の競合
これらの要因が複雑に絡み合うことで、プロンプトに応じてクローラAPI経由か直接取得かが動的に切り替えられますが、誤判断や負荷状況によりエラーが発生する可能性があります。
結論として、有効な対策は見つけられませんでした。😢
成功するまで繰り返すか、アクセスが集中していない時間帯で使うくらい…
*当記事は、FeloとChatGPTをベースに調査・執筆されています。チェックはしておりますが、不正確な記述についてはご指摘いただけますと幸いです。
M2AI（ミーツ・エーアイ）
https://x.com/M2AI_jp