0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@SK5uta

LM Studio + Qwen Code + DuckDuckGo MCPでWeb検索を実現する

0
Posted at

はじめに

LM StudioでローカルLLMを動かし、別PCのQwen
Codeから利用する環境を構築していたところ、Web検索周りで少し分かりにくい問題に遭遇した。

LM StudioのChat上ではDuckDuckGo MCPを使ったWeb検索が正常に動作する。

ところが、別PCからQwen Code経由で同じモデルを利用すると、

  1. 「Web検索して」と指示する
  2. DuckDuckGo検索を実行しない
  3. LLMがURLを推測する
  4. WebFetchでそのURLへアクセスする

という挙動になった。

場合によっては存在しないURLまで生成してしまう。

調査した結果、

  • LM StudioのMCPとQwen CodeのMCPは別管理
  • MCPがConnectedでも、モデルがそのToolを選択するとは限らない
  • WebSearchとWebFetchは役割が異なる
  • 小～中規模のローカルモデルではTool選択を明示的に誘導した方が安定する

ということが分かった。

この記事では、実際に行った切り分けを順番に整理する。

1. 環境

今回の構成は以下。

Client PC
┌────────────────────────────┐
│ Qwen Code                  │
│                            │
│ MCP Client                 │
│ └─ duckduckgo-mcp          │
└──────────────┬─────────────┘
               │
               │ OpenAI Compatible API
               ▼
┌────────────────────────────┐
│ LM Studio PC               │
│                            │
│ LM Studio Server           │
│ └─ qwen/qwen3.5-9b         │
└────────────────────────────┘

使用したモデル：

qwen/qwen3.5-9b

Qwen CodeからLM StudioのOpenAI互換APIを利用している。

2. 最初に起きていた問題

最初はLM Studio側にDuckDuckGo MCPを設定していた。

LM Studio Chatでは、

User
 ↓
LM Studio
 ↓
Qwen
 ↓
DuckDuckGo MCP
 ↓
Web Search

という流れで正常に検索できた。

しかしQwen CodeからLM Studio
API経由で利用すると、Web検索を指示してもQwenがURLを推測し、WebFetchを直接実行することがあった。

問題はWebFetchそのものではなく、検索結果からURLを取得せず、LLM自身がURLを推測していたことだった。

3. LM StudioのMCPとQwen CodeのMCPは別管理

LM StudioはMCP Hostとして動作できるが、LM Studio Chatに設定したMCPがQwen
Codeへ自動的に継承されるわけではない。
Qwen Code自身もMCP Clientであり、独自のMCP設定を持っている。
つまり、LMStudioのMCP設定とQwenCodeのMCP設定は別管理として考える必要がある。

4. Qwen CodeにDuckDuckGo MCPを追加

Qwen Codeの ~/.qwen/settings.json のmodelとmodelProvidersの間に mcpServers
を追加した。（正しいかどうかわからんけど）

{
  "mcpServers": {
    "duckduckgo": {
      "command": "uvx",
      "args": [
        "duckduckgo-mcp-server"
      ],
      "env": {
        "DDG_REGION": "jp-ja",
        "DDG_SAFE_SEARCH": "MODERATE"
      }
    }
  }
}

確認：

qwen mcp list

結果：

Configured MCP servers:
✓ duckduckgo: uvx duckduckgo-mcp-server (stdio) - Connected

これでQwen CodeからDuckDuckGo
MCPへのstdio接続自体は正常であることを確認できた。

5. OAuthエラーに惑わされた

途中、Qwen Code上で以下のエラーも確認した。

Cannot perform dynamic registration without authorization URL

しかし今回のDuckDuckGo MCPは command: "uvx"
を使うstdio構成であり、qwen mcp list でも (stdio) - Connected
と表示されていた。

そのため、今回の問題の中心はOAuthではなく、MCP
Toolがモデルに認識され、適切に選択されているかどうかだと判断した。（紛らわしいからやめてくれ）

6. MCPがConnectedでもToolを使うとは限らない

ここが今回一番重要だったポイント。

Connected が保証するのは、Qwen CodeからMCP
Serverへ接続できていること。

一方、

「この質問にはDuckDuckGo Searchを使おう」

と判断するのはモデル側である。

MCP接続
    ↓
Tool公開
    ↓
Tool選択
    ↓
Tool実行

は別々の段階として切り分ける必要がある。

今回の状態は、

MCP接続     → OK
Tool公開     → OK
Tool選択     → 不安定

だった可能性が高い。
正直、設定されていれば特に問題なく使用するもんだろうと勝手に思い込んでました。

7. Toolの使用を明示したら正常に動作した

以下のプロンプトでテストした。

duckduckgo MCPで公開されている検索ツールを使用して、
LM Studioの2026年8月時点の最新情報を検索してください。

URLを推測してWebFetchするのは禁止です。
最初にDuckDuckGo検索ツールを実行してください。

するとQwen Codeは mcp__duckduckgo__search
をToolSearchで発見し、実際にDuckDuckGo MCP検索を実行した。

8. 実際のWeb検索フロー

正常動作時の流れは以下。

User
 ↓
Qwen
 ↓
ToolSearch
 ↓
mcp__duckduckgo__search
 ↓
DuckDuckGo Search
 ↓
検索結果
 ↓
公式URLを発見
 ↓
WebFetch
 ↓
ページ内容取得
 ↓
追加検索
 ↓
回答生成

DuckDuckGo検索でLM
Studio公式Changelogを発見した後、そのURLに対してWebFetchを実行していた。

つまりWebFetchを使うこと自体は問題ではない。

問題だったのは、

検索せずにURLを推測してWebFetchする

という順序だった。

9. Web SearchとWebFetchは役割が違う

Web Search

「どのURLを見るべきか探す」ためのTool。

DuckDuckGo Search
 ↓
検索結果
 ↓
実在するURL

WebFetch

「すでに分かっているURLの内容を取得する」ためのTool。

実在するURL
 ↓
WebFetch
 ↓
ページ本文

理想的なWeb調査は、

Search
 ↓
URL発見
 ↓
Fetch
 ↓
内容分析

となる。

10. Tool Useとして考える

LLM自身がDuckDuckGoへアクセスしているわけではない。

モデルは「このToolを使いたい」というTool Callを生成し、Qwen
Code側が実際のToolを実行する。

今回の構成は概念的には以下。

┌──────────────────────────────┐
│ Qwen Code                    │
│                              │
│ Agent                        │
│ ├─ ToolSearch                │
│ ├─ WebFetch                  │
│ └─ MCP Client                │
│      └─ DuckDuckGo Search    │
└───────────────┬──────────────┘
                │
                │ LLM inference
                ▼
┌──────────────────────────────┐
│ LM Studio                    │
│                              │
│ qwen/qwen3.5-9b              │
│                              │
│ 「どのToolを使うか判断」       │
└──────────────────────────────┘

したがって、

Toolが登録されていること

と、

モデルが適切なToolを選択できること

は別問題である。

System PromptやQwenCodeのハーネスで設定する必要があるが、別で調べて記事にしようと思います

12. 検索できても情報統合を間違える

今回のセッションではWeb検索自体は正常になったが、別の問題も確認できた。

Web検索の仕組みは正常ですが、最終回答の情報統合でQwenがミスっています。

つまり、

Web Search       → 成功
WebFetch         → 成功
情報取得          → 成功
情報源の比較       → 失敗
最終判断          → 一部失敗

という状態だった。

これはMCPの問題ではなく、LLMの情報統合・情報源評価の問題である。

そのためWeb検索Agentを実用化するなら、

  1. 公式一次情報を最優先する
  2. 情報の日付を比較する
  3. 複数ソースが矛盾した場合は自動的に片方を採用しない
  4. 矛盾を明示する
  5. 最新情報では更新日時を確認する

といったルールも必要になる。

14. 最終的な切り分け結果

項目 結果

Qwen Code → LM Studio ✅
Qwen Code → DuckDuckGo MCP ✅
MCP stdio接続 ✅
MCP Tool公開 ✅
ToolSearch ✅
DuckDuckGo Search実行 ✅
検索結果からURL取得 ✅
WebFetch ✅
Search → Fetchの順序 ✅
MCP Toolの自発的選択 ⚠️ 不安定
複数ソースの情報統合 ⚠️ 改善余地あり

最初はMCPが動いていないように見えていたが、実際には、

MCPは正常
 ↓
Toolも公開されている
 ↓
モデルがToolを選択していなかった

という可能性が高かった。

15. トラブルシューティング手順

Step 1: MCP設定を確認

qwen mcp list

期待値：

✓ duckduckgo: uvx duckduckgo-mcp-server (stdio) - Connected

Step 2: Qwen Code内でも確認

/mcp

DuckDuckGo MCPがConnectedになっていることを確認する。

Step 3: Toolが公開されているか確認

mcp__duckduckgo__search などの検索Toolが認識されているか確認する。

Step 4: Tool使用を強制してテスト

duckduckgo MCPで公開されている検索ツールを使用してください。

URLを推測してWebFetchするのは禁止です。
最初にDuckDuckGo検索ツールを実行してください。

LM Studioの最新情報をWeb検索してください。

Step 5: Tool Callを見る

期待する流れ：

ToolSearch
 ↓
mcp__duckduckgo__search
 ↓
DuckDuckGo Search
 ↓
WebFetch

ここまで動けばMCP自体は正常。

Step 6: 通常プロンプトで試す

LM Studioの最新情報をWeb検索してください

これでDuckDuckGo Searchを使わない場合、MCP接続ではなくTool
Selectionの問題を疑う。

16. 今回学んだこと

今回一番大きかったのは、

「MCP Connected = LLMがToolを適切に使う」

ではないということ。

より正確には、

MCP Connected
 ↓
Toolを取得できる
 ↓
モデルにToolを提示できる
 ↓
モデルがToolを選択する
 ↓
クライアントがToolを実行する
 ↓
結果をモデルへ返す

という複数段階になっている。

「Web検索できない」ときは、

接続
 ↓
Tool Discovery
 ↓
Tool Selection
 ↓
Tool Execution
 ↓
Result Interpretation

に分解して調査すると原因を見つけやすい。

まとめ

LM Studio + Qwen Code + DuckDuckGo
MCPでWeb検索環境を構築した結果、最終的には以下のフローで正常に動作した。

User
 ↓
Qwen Code
 ↓
Qwen 3.5 9B on LM Studio
 ↓
Tool Selection
 ↓
DuckDuckGo MCP
 ↓
Web Search
 ↓
検索結果
 ↓
WebFetch
 ↓
ページ取得
 ↓
Qwen
 ↓
回答

今回の問題はMCPの接続障害ではなく、

モデルがDuckDuckGo Searchを選択せず、
WebFetchだけで解決しようとしていた

ことが主な原因だった可能性が高い。

Tool使用を明示したところ、

ToolSearch
 ↓
DuckDuckGo Search
 ↓
WebFetch

という期待したフローになった。

今後の改善ポイントは、

  1. Web検索ルールのSystem Prompt化
  2. Qwen Code側への恒久的なTool利用ルール設定
  3. LM Studio側からAPI利用時にルールを強制できるか検証
  4. 情報源の優先順位付け
  5. モデルサイズによるTool Selection精度の比較

特に、

「Toolが存在すること」と「モデルが適切なToolを選択できること」は別問題

という点は、ローカルLLMでAgent環境を構築するときに覚えておきたい。

参考資料

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?