ローカルLLMでWeb検索付きのAIリサーチを試すと、検索結果、Tool Call（ツール呼び出し）、出典URL、evidenceやquality_reviewまで含むDeep Research風のレポートが生成されることがあります。
見た目だけなら、調査は成功しているように見えます。
これまで私は、Open WebUIとAnythingLLMを使って、ローカルLLMでどこまでAIリサーチができるのかを検証してきました。
- ローカルLLMでAIリサーチは実用になるのか？Open WebUIとAnythingLLMで試した結果
- Open WebUIでWeb検索はできたが、Deep Researchには足りなかった理由
- AnythingLLMでDeep Research風の調査を試した結果：Tool Callと出典取得は安定するのか
今回は、Web検索付きAIリサーチで「成功した」と誤判定しやすい3つの落とし穴を整理します。
この記事で分かること
| 成功したように見える状態 | 実際に確認が必要だったこと |
|---|---|
| ツール呼び出しが表示された | ツールが実行され、利用できる結果を返したか |
| HTTP 200が返った | Web検索ツールが利用可能な検索結果を取得できたか |
| 出典URLが付いた | URL本文まで取得し、根拠を確認したか |
| URL本文を取得できた | 必要な情報を正しい構造で抽出できたか |
quality_review（品質レビュー）が良好だった | ツール実行、出典本文、主張と根拠の対応を確認できたか |
「検索できた」「ツール呼び出しが出た」「出典が付いた」だけでは、検証可能な調査ができたとは言えません。
実際の処理は、単純化しても次のように分けられます。
ツールを使おうとした
↓
ツール呼び出しが生成された
↓
ツールが実行された
↓
利用できる結果を取得した
↓
URL本文を取得した
↓
本文中の根拠を確認した
↓
最終回答の主張と根拠を照合した前の確認ポイントが満たされると、その後まで成功したように見えやすい。今回の記事では、その誤判定を3つに分けます。
今回の検証環境
追加検証の主な条件は次の通りです。
| 項目 | 条件 |
|---|---|
| Open WebUI | v0.11.0 |
| Ollama | v0.32.5 |
| モデル | gemma4:e4b-it-q4_K_M |
| Web検索 | ON |
| Web検索エンジン | DDGS |
| DDGSバックエンド | DuckDuckGo / Bing / Yahoo / Braveを変更 |
| Web Loader | Default |
Open WebUIの追加検証Run 1は5ケースで、DuckDuckGo 2ケース、Bing・Yahoo・Braveを各1ケース確認しました。v0.10.2を使った2本目の記事の結果は、当時の環境の記録として分けています。
AnythingLLMでは、v1.15.0で8回の主検証を行いました。
主な設定は、Ollama v0.32.5、DuckDuckGo、Intelligent Tool Selection ON、Web Browsing ONです。
これらは成功率を測る試験ではなく、どこで「成功」を誤判定しやすいかを見るための検証です。
落とし穴1：ツール呼び出しが表示されても、ツール実行成功とは限らない
HTTP 200でも検索結果を取得できなかった
Open WebUI v0.11.0で、DDGSバックエンドをYahooに設定して「明日の東京の天気は？」と検索しました。
DockerログではYahoo SearchへのHTTPリクエストが200でしたが、その直後に検索失敗が記録されています。以下は該当箇所の抜粋です。
response: https://search.yahoo.com/search?... 200
search_web error: No results found.
...
ddgs.exceptions.DDGSException: No results found.UIのツール出力も次でした。
{
"error": "No results found."
}つまり、HTTP 200と、利用可能な検索結果の取得は別です。DuckDuckGoバックエンドでも、html.duckduckgo.comへのリクエストが202 Acceptedになった後、No results foundで失敗するケースを確認しています。
UIでBingを選んでも、実際にはBingを使っていなかった
Open WebUIでDDGS Backend = Bingを選んだ試行では、Dockerログに次の警告が出ました。
bing - backends do not exist or are disabled
backend is not set. Using 'auto'その後はGrokipedia、Wikipedia、Yahoo、Braveへのリクエストが確認され、検索結果は5件返りました。
この試行は「Bingで検索成功」ではなく、Bingを利用できずDDGSがautoへフォールバックしたケースです。
UIで設定したバックエンド
≠
実行時に選ばれたバックエンド
≠
実際にリクエストしたバックエンド一方、Braveではsearch.brave.comへのリクエスト、HTTP 200、5件の検索結果、URLと検索結果の抜粋、最終回答まで確認できました。正常系と比較することで、単に「Web検索が壊れていた」のではなく、実行経路のどこまで進んだかを分けて見られます。
fetch_urlでもツール呼び出しと本文取得成功は別だった
取得失敗時の挙動も1回確認しました。.invalidドメインを指定し、fetch_urlだけで本文取得するよう指示したところ、正しいURLが渡りましたが、ツール出力は次でした。
{
"error": "[Errno -2] Name or service not known"
}Dockerログにも同じ内容のfetch_url errorが残り、モデルは別のWeb検索や推測に切り替えず「本文取得不可」と回答しました。
fetch_url自体は実行されましたが、URL本文の取得には成功しておらず、ツールの実行と目的の結果を得ることは別だと分かります。
AnythingLLMでは別の形で境界が見えた
AnythingLLMでは、正式なツール名web-browsingに対し、一部の試行でモデルがweb_browsingを生成しました。
成功した試行のUIログには次の表示があります。
@agent is executing `web-browsing` tool
@agent: Using DuckDuckGo to search for "..."
@agent: I found 10 results一方、失敗した試行ではTool Call:という表示があっても、is executing、DuckDuckGo利用、検索結果件数、Citationまで進んだことを確認できませんでした。
Open WebUIとAnythingLLMの失敗原因は同じではありません。共通していたのは、ツール呼び出しらしい表示だけでは成功判定できないことです。
落とし穴2：出典URLがあっても、本文確認済みとは限らない
search_webで取得していたのはURLと検索結果の抜粋だった
Open WebUI v0.11.0 + Braveの正常系では、search_webのツール出力に5件の検索結果が返りました。各結果に含まれていたのは次の3項目です。
title
link
snippetsnippetは検索結果画面に表示される短い抜粋です。tenki.jpのsnippetには次の情報があり、最終回答もほぼ対応していました。
あすは午前中を中心に晴れて、猛暑日になる所がありそうです。午後は急な激しい雨や雷雨にご注意下さい。この試行で確認できたのはURLと検索結果の抜粋までで、tenki.jp本文の取得は確認していません。さらに5件の中には、根拠候補としては古い2025年のYouTube動画も含まれていました。
検索結果が返ること、本文を読むこと、出典の新しさや関連性を確認することは別です。
fetch_urlでは本文まで確認できた
別の試行では、Open WebUI公式ドキュメントのURLを指定し、search_webとfetch_urlの説明を本文だけから答えるよう指示しました。
この試行は2026年8月9日11:24（JST）に実行し、プロンプト全文、思考ログ、ツール呼び出し、ツール入力、取得本文、最終回答全文、UIスクリーンショットを保存しています。
fetch_urlを実行し、取得結果をもとに回答処理へ進んだ画面ツール出力には指定ページの本文が返り、次の記述も含まれていました。
search_web (Snippets only)fetch_url (Full Page Context)取得本文には、search_webがtitle / link / snippetを返すこと、fetch_urlが設定済みWeb Loaderでページのmain textを抽出することが記載されていました。
また、取得テキストは50,000文字で切り詰められるとOpen WebUI公式ドキュメントに記載されており、最終回答の主要な主張と照合できました。
| 確認項目 | search_web正常系 | fetch_url成功試行 |
|---|---|---|
| URL | 確認 | 確認 |
| 検索結果の抜粋 | 確認 | 対象外 |
| URL本文 | 未確認 | 確認 |
| 本文中の根拠 | 未確認 | 確認 |
| 最終回答の主張との照合 | 未確認 | 確認 |
出典URLがあることと、本文確認済みの根拠があることは同じではありません。
本文取得できても、それで終わりではない
Open WebUI v0.10.2を使った以前の検証では、天気ページの本文テキストまでは取得できましたが、表の部分は次の形で返りました。
千代田区29/2120%値は含まれているように見える一方、最高気温、最低気温、降水確率といった列構造は失われています。Playwright Web Loaderへ変更しても、このページでは表の安定した構造化まで改善したとは確認できませんでした。
したがって、本文取得と、必要なデータ構造を正しく抽出できることも別です。これは「Playwrightでは表を取得できない」という一般化ではありません。
AnythingLLMの出典表示も本文確認済みとは限らなかった
AnythingLLMでは、検索結果の出典表示付きの調査の下書きを作れました。
ただし、保存した8回分の記録を見直しても、URL本文まで取得したことを確認できる実行記録はありませんでした。
別の構造化プロンプト検証では、モデル出力上でsource_access_status: snippet_only、opened_urls: 0という状態も記録されています。
ここで注意が必要なのは、opened_urlsはモデル自身が出力した値であり、ツールの実行記録ではないことです。そのため、「本文を取得していなかった」と断定するのではなく、「本文取得を裏づける記録が残っていなかった」と評価しています。
つまり、出典表示は根拠確認への入口ですが、本文確認済みの根拠そのものとは限りません。
落とし穴3：Deep Research風の出力でも、品質保証されたとは限らない
検索に失敗しても、調査レポートらしい形は作れてしまった
過去のOpen WebUI v0.9系の検証では、Web検索エラーや検索クエリ未生成の後にもDeep Research風の構造化出力が生成されました。その中には次の表現も含まれています。
Google Search API (Simulated)Simulated Google Search API for Deep Research (Conceptual)実際の検索が完了していないのに、プロンプトで要求されたsearched_sourcesやevidenceの形式を埋める方向へモデルが進んだケースです。
AnythingLLMではAnticipated Evidenceまで生成された
AnythingLLM + Deep Research tool + 構造化プロンプトでは、research_plan、tool_execution_status、searched_sources、evidence、hypothesis_patterns、quality_review、knowledge_gaps、follow_up_queries、overall_assessmentまで含む出力が生成されました。
しかし、モデル出力上ではopened_urlsが空で、本文取得を裏づける実行記録も残っていませんでした。さらに出力自身が、実ページを詳しく読んだのではなく、一般知識から想定される情報をAnticipated Evidenceとして構造化したと説明していました。
Deep Researchらしい出力構造の完成度と、出典検証の完成度は別です。
quality_reviewも検証対象だった
ここでいうquality_reviewは、製品の独立した品質検査機能ではなく、構造化プロンプトでモデルに生成させた自己評価項目です。
構造化プロンプトではquality_reviewも生成できますが、過去の記録では次の自己矛盾がありました。
- Web検索エラー後でも、検索成功のように評価する
- モデル出力上で
opened_urls: 0でも、URL内容を分析したように扱う snippet_onlyでも出典の妥当性を楽観的に評価する- 架空URLが混じっていても問題なしと評価する
- 検証可能な調査成果物として扱えない状態を、扱えると自己評価する
品質レビューは無意味なのではなく、ツールログや出典本文と突き合わせる検証対象として扱う必要があります。
「検索できた」を分解する9つの確認ポイント
今回の記録は、次の9つの観点に分けると整理しやすくなります。
| 確認ポイント | 確認すること | 例 |
|---|---|---|
| 1. ツール利用の意図 | ツールを使おうとしたか | 思考表示（reasoning / thinking） |
| 2. ツール呼び出し | どのツール名・引数を生成したか | fetch_url(...)、web-browsing(...) |
| 3. ツールの認識・実行 | 実行時にそのツールが認識・実行されたか | is executing、実行ログ |
| 4. 外部アクセス | 実際にどこへリクエストしたか | Docker / サーバーログ |
| 5. ツールの実行結果 | 結果とエラーのどちらが返り、その結果は目的に利用できるものだったか | 検索結果、No results found |
| 6. 本文取得 | URL本文を取得したか | fetch_urlのツール出力 |
| 7. 根拠確認 | 必要な根拠が本文中にあるか | 本文中の該当記述 |
| 8. 主張と根拠の対応 | 最終回答の主張と根拠が対応するか | 主張と根拠の対応（Claim–Evidence） |
| 9. 記録・再現性 | 条件・失敗・レビューを後から確認できるか | ログ、実行環境、人による確認 |
9番目の「記録・再現性」は直列工程ではなく、1〜8すべてにかかる横断条件です。
重要なのは、ある確認結果から別の確認結果を推定しないことです。HTTP 200でも利用可能な検索結果まで得られたとは限らず、出典URLがあっても本文取得は確定せず、quality_review: goodでも根拠確認や再現性は確定しません。
最低限確認したい6項目
- ツール呼び出しの表示だけで成功判定しない。 ツールの実行結果またはエラーまで確認する。
- UI設定と実際の実行を分ける。 可能なら、実際に使われたツールやバックエンドも確認する。
- 出典URLと本文確認を分ける。 検索結果の抜粋だけなのか、本文まで取得したのかを残す。
- 本文取得後も根拠を確認する。 必要な情報が本文中にあり、構造が壊れていないかを見る。
- 品質レビューを品質保証にしない。 ツールログ、出典、本文、失敗状態と突き合わせる。
- 実行条件を残す。 バージョン、モデル、ツール設定など、結果が変わり得る条件を記録する。
調査の下書きと検証可能な調査成果物は何が違うのか
AnythingLLMの記事では、調査成果物を3段階に分けました。今回の横断検証でも同じ整理を使います。
| 段階 | 状態 |
|---|---|
| 調査の下書き（Research Draft） | 調査結果が構造化され、URLや根拠候補がある |
| 検証可能な下書き（Verifiable Draft） | ツール名、検索クエリ、実行ログ、検索サービス、検索結果URLなどを一部追える |
| 検証可能な調査成果物（Research Artifact） | ツールの返却結果、本文取得成否、主張と根拠の対応、失敗状態、再実行条件、人による確認まで確認できる |
このうち「検証可能な下書き」は、ツール名や実行UIログ、検索結果URLから調査経路を一部追える状態です。
ただし、検索結果の抜粋だけなら本文確認済みの根拠にはなりません。
調査の下書きは検索結果を整理するたたき台として使えます。
ただし、表示された出典が実際のツール実行から得られたのか、本文を確認したのかまでは保証されません。
私がこのプロジェクトで目標にしているのは、ツール呼び出しと返却結果、取得URLと成否、検索結果の抜粋と本文確認済み根拠の区別、主張と根拠の対応、失敗状態、再実行条件、人による確認を後から追える状態です。
今回のOpen WebUIのfetch_url成功試行では、UIとツール出力上で本文取得と最終回答の主張との対応まで確認できました。
一方、今回の成功時のDockerログには外部HTTP通信のログは残っていませんでした。
したがって、本文取得成功の実例ではありますが、これだけで完全な検証可能な調査成果物が完成したわけではありません。
まとめ：検索できることではなく、後から検証できることを見る
今回の検証条件では、Open WebUIもAnythingLLMも、ローカルLLMからWeb検索付きの回答が生成された試行がありました。
一方で、実験記録を横断すると、「成功」という言葉の中に複数の工程が混ざっていました。
ツール呼び出しがある
≠
ツールが正常終了した
HTTP 200が返る
≠
利用可能な検索結果が返る
UIでバックエンドを選ぶ
≠
そのバックエンドが実際に使われる
URLや出典表示がある
≠
本文を確認した
本文を取得した
≠
必要な構造を正しく抽出できた
Deep Research風の出力構造がある
≠
出典検証済み
quality_reviewがある
≠
品質保証済みローカルLLMでAIリサーチを評価するとき、見るべきなのは「検索できたか」「出典が付いたか」だけではありません。
ツールが何を実行し、何を取得し、本文のどの根拠がどの主張を支えているのかを、後から確認できるか。
そこが調査の下書きと検証可能な調査成果物を分ける境界だと考えています。
この記事では、成功を誤判定しないための判断基準までを扱いました。
検索ログや取得本文の保存、記入済みの主張と根拠の対応表、人による確認、再実行手順は、第三者が再現できる形が整い次第、実践編としてまとめます。
