Open WebUIでWeb検索はできたが、Deep Researchには足りなかった理由

2026年7月10日 2026年7月10日

ホーリー

はじめに

ローカルLLM環境で、Deep Researchのような調査ができるか。
これを継続して検証しています。

前回の比較検証では、Open WebUIとAnythingLLMのどちらもWeb検索付きの一次調査には使える一方で、後から検証できる調査成果物にするには不十分だと整理しました。

今回はOpen WebUIに絞り、「通常チャット + Web検索ON」という一番シンプルな構成で、どこまで調査ができるのかを確認しました。

先に結論を言うと、Open WebUIでWeb検索はできました。
URLを明示すれば本文取得にも進めました。

それでも、Deep Researchのような「後から検証できる調査成果物」には届きませんでした。

この記事で伝えたいのは、Open WebUIが使えないという話ではありません。
「Web検索ができること」と「検証可能な調査成果物になること」は別物だった、という検証結果です。
この2つは混同されやすいので、今回の検証で確認できた範囲を、できたこと・足りなかったことに分けて整理します。

なお、ここでいうDeep Researchは、単なるWeb検索ではなく、複数のソースを取得・分析・統合してレポートにまとめるタイプの調査機能を指しています。
OpenAIのDeep Researchも、Web browsing と data analysis に最適化され、複数のオンラインソースを取得・分析・統合して包括的なレポートを作るものとして説明されています。
少なくとも、Deep Researchのような調査機能は、単なる検索結果の要約ではなく、探索・分析・統合・レポート化を含む複数工程の仕組みとして見る方が自然です。
ただし本記事では外部サービスの解説には踏み込まず、自分のOpen WebUI検証から見えたことを中心に書きます。

もう1つ、この記事で軸にする「後から検証できる調査成果物」という言葉を先に定義しておきます。
これは、単にそれらしい回答が返ってくることではありません。
どのURLを参照し、どの本文を取得し、回答内のどの主張がどの根拠に基づくのかを、後から人間が確認できる形で残せることを指します。

結論

最初に結論をまとめます。

Open WebUIは、Web検索付きの一次調査には使えました
検索結果のソースURLも表示されました
URLを明示すれば、ページ本文の取得にも進めました
Playwright Web Loaderでも本文取得はできました
ただし、Deep Research的な調査成果物に必要な工程は、通常チャットの外側にありました

今回の検証結果を一覧にすると、次のようになります。

できたこと	判定
Web検索	できた
検索結果URLの表示	できた
検索結果スニペットを使った回答	できた
URL明示時の本文取得	できた
Playwright Web Loaderでの本文取得	できた
表形式データの安定した構造化	不安定
主張と根拠の対応づけ	不十分
後から検証できる調査成果物化	不十分

上半分はできて、下半分が足りない。
この境界線がどこにあるのかが、今回の検証で一番の収穫でした。
検索、本文取得、構造化抽出、根拠保存、主張と出典の対応づけは、それぞれ別工程だったのです。

検証の前提

今回の検証環境は以下です。

項目	内容
実行日	2026年7月7日〜8日
Open WebUI	v0.10.2
Model	gemma4:e4b-it-q4_K_M
Web検索	ON
Web検索バックエンド	DuckDuckGo / Googleを試行
Webローダーエンジン	デフォルト → Playwright
Webローダーをバイパス	OFF
埋め込みと検索をバイパス	OFF

検証観点は次の4つに絞りました。

Web検索が実行されるか
search_web が検索結果スニペットに留まるか
URLを明示すると fetch_url 相当の本文取得に進むか
Playwright Web Loaderで本文取得や構造化抽出が改善するか

この4つを順に確認していきます。

検証1: Open WebUIでWeb検索はできた

まず、Web検索そのものが動くかを確認しました。

Web検索ONの状態でPromptを実行すると、回答に [1] [2] のような参照番号が付き、検索ソースとして複数のURLが表示されるケースがありました。
Web検索付き回答の入口としては、きちんと機能しています。

したがって、この記事は「Open WebUIではWeb検索できない」という話ではありません。
Web検索はできました。

ただ、ここで1つ注意が必要です。
検索結果のURLが表示されることと、そのURL先の本文を実際に読んで回答していることは、別の話です。
参照番号付きのURLが並ぶと、いかにも本文まで確認した回答に見えますが、この時点ではまだそこまで確認できていません。

この点を切り分けるのが、次の検証です。

検証2: search_web は検索結果スニペットに留まる場合があった

「明日の東京の天気を調べて」というPromptで、Web検索が実際に何を取得しているのかを確認しました。
なお、天気予報ページは時間とともに内容が変わるため、ここでは当時の取得ログに基づいて記録しています。

Web検索は search_web というツールとして実行され、戻り値は title / link / snippet の形式でした。
つまり、取得できていたのは検索結果URLと、検索結果一覧に表示される短い説明文（スニペット）です。

search_web の戻り値の例です。

{
  "title": "東京都の天気 - 日本気象協会 tenki.jp",
  "link": "https://tenki.jp/forecast/3/16/",
  "snippet": "あすは、日が差す所もありますが、雲が多く、午後は所々で雨が降る見込みです。最高気温は28度前後の予想です。..."
}

このスニペットには、天気の傾向と最高気温の情報が含まれています。そして、Open WebUIの回答もちょうどその範囲でした。

- 天気: 日が差す所もありますが、雲が多く、午後は所々で雨が降る見込みです
- 最高気温: 28度前後
- 最低気温: 情報なし
- 降水確率: 午後から雨の予報があるとの記載

スニペットに含まれていた天気と最高気温は回答できました。
一方で、スニペットに含まれていなかった最低気温や降水確率の具体値は「情報なし」となりました。

このことから、今回のケースでは、回答は検索結果スニペットに依存していた可能性が高いと判断しました。
参照URLとして tenki.jp が表示されてはいますが、そのページの本文を読んだ形跡は確認できませんでした。

この節の結論はシンプルです。

URLが出ることと、そのURLの本文を読んだことは別。

検証3: URLを明示すると本文取得に進んだ

では、URLを明示的に指定したらどうなるか。次に、tenki.jp のURLをPromptに直接書いて、本文取得を促しました。

以下のURLを開いて、明日の東京の天気を確認してください。
https://tenki.jp/forecast/3/16/
...
検索結果の説明文だけでなく、URL先ページの本文から具体的な予報情報を抜き出してください。

この場合、Open WebUIは search_web ではなく、URL先ページを取得する fetch_url 相当の処理に進みました。
実際、取得結果には tenki.jp のページ本文由来のテキストが大量に含まれていました。
URLを明示すれば、URL先ページのテキスト取得まではできました。

ただし、取得された本文は、人間がブラウザで見るページと同じ構造ではありませんでした。
特に、天気予報の表の部分は、次のようなテキストになっていました。

千代田区29/2120% 新宿区29/2020% 世田谷区30/2010%

あるいは、こういう形です。

渋谷区
30
/
20
10%

千代田区29/2120% という文字列は、おそらく「29 / 21 / 20%」という表の値が、区切りを失って連結されたものです。
つまり、値そのものは本文に含まれているのに、表の列構造が失われています。
人間なら、これを見て「渋谷区: 最高気温30度 / 最低気温20度 / 降水確率10%」と推測できます。
表のレイアウトを知っているからです。

しかし、Open WebUIの通常チャットでは、この崩れたテキストを安定して構造化できませんでした。
回答では最高気温・最低気温・降水確率が「不明」とされ、ページ内の概況文（「日中の気温は、広い範囲で28度前後まで上がるでしょう」など）だけが抜き出されました。
取得本文の中に数値自体は存在していたにもかかわらず、です。

この節の結論はこうなります。

URL本文は取得できました。
しかし、本文取得できることと、表形式データを正しく構造化できることは別でした。

検証4: Playwright Web Loaderでも表構造化は別問題だった

表の構造が崩れるのはWebローダーの問題かもしれない。
そう考えて、次にWebローダーエンジンをデフォルトからPlaywrightに変更し、同じURL・同じPromptで再検証しました。

Playwrightと聞くと、ブラウザを人間のように操作して、ページ上の情報を読み取ってくれるイメージを持ちやすいと思います。
しかし、Open WebUIのWeb LoaderとしてのPlaywrightは、今回の挙動を見る限り、URLを開いて本文テキストを抽出し、LLMに渡すための仕組みでした。

結果は次の通りです。

Playwright設定後も fetch_url は実行された
本文テキストも取得できた
ただし、取得結果はデフォルトWeb Loader時と大きくは変わらなかった

表由来のテキストは、やはり同じような形で取得されていました。

千代田区30/2120% 新宿区30/2020% 世田谷区30/2010%

渋谷区
30
/
20
10%

そして今回のPlaywright設定後の回答では、天気・最高気温・最低気温・降水確率はいずれも「判別不可」とされました。
取得本文の中に数値は含まれていたのに、それを「明日の東京の天気」として構造化して使うことはできませんでした。

つまり、今回の tenki.jp のケースでは、Playwright Web Loaderに変更しても、表構造の復元や指定項目の抽出について明確な改善は確認できませんでした。

ここで1つ補足しておくと、これはPlaywrightに意味がないという話ではありません。
Playwright自体はブラウザ自動化ツールであり、DOM取得、Network監視、スクリーンショット保存などに使えます。
ただし、次の2つは別物です。

Open WebUIのWeb LoaderとしてPlaywrightを使うこと
Playwrightでブラウザを操作して、DOM / Network / スクリーンショットを調査すること

前者は本文テキスト抽出の手段の1つであり、後者はブラウザ証拠取得のレイヤーです。
今回確認できたのは前者の範囲でした。

この節の結論です。

Playwrightに変更しても、URL先ページ本文を取得できることと、表形式の予報値を正確に構造化できることは別でした。

分かったこと: 検索・本文取得・構造化・根拠保存は別工程

ここまでの検証を抽象化すると、次のようになります。

Web検索できる
検索結果スニペットを使って回答できる
URL先本文を取得できる
本文から必要情報を構造化できる
主張と出典を対応づけられる
後から検証できる成果物として保存できる

これらは全部、別工程でした。

今回の検証では、Open WebUIの通常チャット + Web検索ONは、1〜3には使えました。
しかし4以降は、通常チャットの外側に工程として持つ必要がありました。

Deep Research的な調査成果物、つまり「後から誰でも検証できる調査レポート」にするには、少なくとも以下が必要になります。

検索結果URLを保存する
検索結果スニペットを保存する
URL先本文を取得する
本文取得の成功 / 失敗を記録する
DOMやNetworkログを保存する
表やJSONを構造化抽出する
回答内の主張と根拠を対応づける
未確認情報を分離する
レポートをMarkdownとして保存する

通常チャットの出力は、その場では読みやすい回答になります。
しかし、チャット出力だけでこれらを安定して管理するのは難しい、というのが今回の実感です。
どのURLの本文を取得したのか、回答のどの主張がどの本文箇所に基づくのか、取得に失敗したものはどれか。
こうした記録は、チャットの外側で工程として設計しないと残りません。