ローカルLLMとWeb Search MCP、その先に見えたもの
ローカルで動かす大規模言語モデル（LLM）と、外部情報を引き込む Model Context Protocol (MCP)。
この組み合わせを手にした瞬間、「ChatGPTを模した体験がローカルで完結する」という未来像が一気に現実味を帯びました。
筆者も実際に gpt-oss + LM Studio + Web Search MCP を組み合わせて検証し、先日記事にまとめたばかりです。
その時点での理解はシンプルでした。
- 公式ドキュメントのUsageに従い、
full-web-search({"query":"..."})のように「ツール名＋JSON形式」で呼び出す。 - つまり「自然文で“調べて”と聞くだけではツールは動かない」 → 呪文必須である。
実際、検証初期は自然文からWeb Search MCPを起動しようとしても「安全上の理由で答えられません」と断られる場面が多く、ドキュメントの記述とも符合していたため、「gpt-ossは呪文を唱えるのが前提」だと理解していました。
ところが──。
その後の継続検証で、意外な発見をしました。
Gemma3 をテストした際、自然文で「秋葉原のDDR5メモリの最安値を調べて」と投げかけたところ、Web Search MCPが自動で呼び出されたのです。
「たまたまワーディングがハマっただけか？」と思いきや、繰り返すうちに再現性があるとわかり、さらに gpt-oss でも条件を整えれば自然文から自動発動することを確認しました。
この結果は、前回記事の前提をひっくり返すものではありません。
あの記事は 公式Usageに従った検証であり、当時の認識としては正しい。
ただし、使い込むうちに「自然文でも走る」という“裏ワザ的挙動”を掴んだ、というのが今回の位置づけです。
そしてもうひとつ大きな進展がありました。
index.jsの軽量カスタムを施すことで、同じ検索でも消費トークン量が劇的に減少したのです。
実測では、Web Search の未最適化で 9,972 tokens に達していた処理が、最適化後はわずか 1,786 tokens。
およそ 1/5以下 にまで削減できました。
つまり今回の記事は、前回の続編であると同時に、
- 「実はgpt-ossも自然文で動いた」
- 「最小限のカスタムでトークン消費が激減した」
という二つの発見を整理して共有するものになります。
本稿では、これらの検証プロセスを具体的なプロンプトと結果ログを交えながら紹介し、最後に「自然文でも安定させる作法」と「上級者向け呪文Tips」をまとめてお伝えします。
前回のおさらい：「呪文必須」と理解した理由
まず、前回の記事で強調したのは 「gpt-ossでWeb Search MCPを呼び出すには呪文が必要だ」 という点でした。
これは筆者が勝手にそう思い込んだのではなく、公式ドキュメントのUsageサンプルがそのような形をとっていたためです。
公式ドキュメントのUsage例
公式リポジトリに掲載されていたコード例は以下のようなものでした。
full-web-search({"query":"NVIDIA RTX 5090","limit":3})自然文で「RTX5090について教えて」と書くのではなく、
「ツール名＋JSON形式」 で明示的に呼び出す。
これが「正しい呼び出し方法」として説明されていたのです。
実際の初期検証結果
筆者もそれを踏襲し、呪文スタイルで検証を進めました。
当時の挙動はこうです。
- 自然文で質問 → 「安全上の理由で答えられません」と断られる
- 呪文形式でツール指定 → 安定してWeb Search MCPが発動
つまり、自然文では動かず、呪文なら動く。
この結果を受けて「gpt-ossでは呪文必須」という結論を導いたわけです。
当時の結論
前回記事では、以下のようにまとめました。
- ChatGPTのように自然文から自動的にツールを呼び出す体験はできない
- 公式ドキュメント通りに「呪文スタイル」を徹底すれば安定する
- したがって、gpt-ossはお作法に従う必要がある
──これが「第1段階の認識」でした。
この認識自体は、公式仕様に準じて検証したものなので、決して誤りではありません。
今回の検証でわかったこと──自然語でもWeb検索を発火させることができる
前回は「gpt-oss＝呪文必須」という前提で検証を終えましたが、さらに使い込むうちに 「実は自然文でもツールが発動する」 という挙動が確認できました。
しかもそれは偶然の一発ではなく、再現性を持った現象だったのです。
1. Gemma3で自然文からWeb-searchが発動
最初のきっかけは、Gemma3 を利用した際の実験でした。
「秋葉原のショップでDDR5メモリの最安値を調べてください」と自然文で投げてみたところ、なんと Web Search MCP が自動的に走り、検索結果が返ってきました。
これまで「自然文では動かない」と思い込んでいたため、筆者自身が驚きました。
再度試したところでも同様の動作を確認でき、「ワーディング次第で自然文からでもツールが起動する」 という再現性を掴みました。
2. gpt-ossでも自然文から発動するケースを確認
Gemma3での挙動を確認したのち、改めて gpt-oss でも検証しました。
すると、条件を整えた場合には gpt-oss でも自然文からWeb-search MCPが発動することがわかりました。
特に有効だったのは以下の工夫です。
- 新規スレッドから開始（過去文脈に引きずられないようにする）
- 「公式」「URL必須」「推測禁止」 など、検索タスクを明確に指定する
- 出力フォーマットをあらかじめ指定（例：「表題 / 公式URL / 公表日 / 概要50字」など）
この程度の工夫を添えるだけで、自然文ベースでも安定してツールが走るようになったのです。
3. PDFは弱点、HTMLは安定
ただし万能ではありません。Gemma3でもgpt-ossでも、PDFを読めないのはモデルの不得意分野ではなく、Web Search MCP の実装仕様の制約です（Playwright経由でDOM抽出するためPDFは対象外）。一方で、HTML公開されている統計資料やプレスリリースは比較的安定して要約できます。回答として、PDFを返すことは儘あるため、注意が必要でしょう。
将来的には、MCPサーバーにPDF専用パーサーを追加すれば改善可能ですが、現状はHTML資料を優先的に利用するのが安全です。
例えば、総務省統計局の家計調査速報を検索すると、最新月の公表日・概要・公式URLを自動抽出できました。
これは「政府統計などの公式情報を引く用途には実用的」と評価できる結果です。
4. 実例：Gemma3とgpt-ossでの自然文発動
- Gemma3のケース：「今日の天気を調べて」→ Web Search MCPが自動で呼ばれ、東京都の気温や降水確率を返した
- gpt-ossのケース：「埼玉県で9月に家族で日帰りできるイベントは？」→ 自然文でもイベント情報を検索し、URLつきで複数候補を返した
いずれも「呪文を書かなくても動いた」ことで、ChatGPT的な使用感に大きく近づきました。
トークン消費の劇的削減：index.jsカスタムの威力
もうひとつ大きな進展として、トークン消費の大幅削減が挙げられます。
ローカルLLMでMCPを使うときに気になるのが、返答の「冗長さ」と、それに伴うトークンコストの高さです。
この問題は、とりわけ full-web-search を使った際に顕著でした。
未最適化の状態
実際、未カスタムの index.js をそのまま使った場合、
「RTX5090について調べて」という単純なリクエストでも、
- 消費トークン数：9,972 tokens
という異様なコストを記録しました。
このままでは 1回の検索でコンテキスト上限の大半を浪費 してしまい、
・会話の途中で急に「忘れっぽく」なる
・長い議論や複数クエリを重ねられない
・最悪の場合、回答が途中で途切れる
といった実害を招きます。
実際に 12,288 トークン上限のうち 9,972 を一度に消費し、1回のサーチで会話が破綻しかけるという危うさを体感しました。
そこで、この「冗長整形」をカットして軽量化するのが今回の対応策です。
カスタム後の改善
そこで筆者は index.js に 軽量化カスタム を加えました。
具体的には、
- 結果レスポンスの冗長なヘッダや説明を削除
- 出力をタイトル／URL／概要に絞り込む
- 不要な「Status」「Debug行」をレスポンスから外す
といった調整を施しました。
この最小限の改修によって、同じ「RTX5090」検索での消費は：
- 消費トークン数：1,786 tokens
まで削減できました。
およそ 1/5以下 です。
Gemma3での測定
このカスタムの効果は gpt-ossだけでなくGemma3でも同様に現れました。
Gemma3はもともと自然文でもツール発動する「気軽さ」が強みでしたが、
同時にレスポンスが冗長になりやすく、消費トークンの多さが弱点でした。
しかしカスタム後の測定では、
Gemma3でも 9,972 → 1,786 tokens という削減が確認され、
「軽く聞いてサクッと答える」体験がより現実的になりました。
実用的な意味
ローカルLLMはクラウドの従量課金とは異なり、トークンコストがそのまま財布に響くわけではありません。
とはいえ、
- 推論時間の短縮（冗長テキストの生成が減る）
- コンテキスト圧迫の回避（トークン枠を消費しにくくなる）
という観点で、軽量化は大きな実用的メリットを持ちます。
特に長時間の検証や複数プロンプト連投では、消費の差が積み重なり、快適さが段違いになります。
Web Search MCPの軽量カスタムでトークン消費を劇的削減
以下のカスタム例は、web-search-mcp/dist/index.js 内でレスポンスを整形している箇所が対象です。
「full-web-search」「get-web-search-summaries」など、this.server.tool(...) の非同期関数内で responseText を組み立てている部分を書き換えます。
（※MCPサーバーそのものの動作には影響せず、出力の見せ方だけを軽量化しています）
1) full-web-search の返却整形を最小にする
冗長なヘッダ／Status行／Full Content（本文全文）を出さず、タイトル＋URLだけ返す。
// …(検索処理のあと)
// Minimal text response: 1行1件、タイトルとURLのみ
let responseText = '';
result.results.forEach((r, i) => {
const t = r.title ? r.title.replace(/\s+/g, ' ').trim() : '(no title)';
responseText += `${i + 1}. ${t} - ${r.url}\n`;
});
return {
content: [{ type: 'text', text: responseText }],
};ポイント
Status:や---区切り、Full Content:／Content Preview:を出力しない- まずはリンク列だけ返す → 必要な時だけ単頁抽出で掘る（省トークン）
2) get-web-search-summaries も同じくリンク列だけ
スニペット（description）も省略可。まずはURL確定を優先。
// …(検索処理のあと)
let responseText = '';
summaryResults.forEach((s, i) => {
const t = s.title ? s.title.replace(/\s+/g, ' ').trim() : '(no title)';
responseText += `${i + 1}. ${t} - ${s.url}\n`;
});
return {
content: [{ type: 'text', text: responseText }],
};3) 既定値を省エネ化（見落としがちな3箇所）
- ツール定義：
limit = 3、includeContent = false - 引数バリデーション：
limit = 3、includeContent = false - 実行側（handleWebSearch）：
const { query, limit = 3, includeContent = false } = input;
これで「最初は軽く」→「必要時のみ詳細」の流れがデフォルト動作になります。
4) 単一ページ抽出は個別に（必要時だけ掘る）
get-single-web-page-content を使って、必要になったURLだけ本文を取得。maxContentLength を2–4k程度にキャップすると、さらに安定します。
const content = await this.contentExtractor.extractContent({
url: obj.url,
maxContentLength: typeof maxContentLength === 'number' ? Math.min(maxContentLength, 4000) : 3000,
});5) 運用メモ（Systemに一行）
まず軽量検索でURLを3件。十分でない場合のみ詳細抽出。URL必須、推測しない。この最小カスタムだけで、未最適化 ~9,972 tokens → 最適化後 ~1,786 tokens（Gemma3実測）まで落ちました。
gpt-ossでも自然文運用＋この整形で ~2.4k tokens 程度に収束します。
実例で検証：ビジネスにも日常にも効く「ローカルLLM検索」
軽量化と運用Tipsを組み合わせることで、ローカルLLM＋MCPが「実用域」に入ることが確認できました。ここでは ビジネス用途とプライベート用途、両方で試した実例を紹介します。
ビジネス編：政府統計の公式ソースを直に引く
ローカルLLM × Web Search MCP が輝く場面の一つが、公的資料の裏取りです。
例：総務省統計局の家計調査。
プロンプト：
総務省統計局の家計調査（最新月）を、公式サイトから3件だけ。
出力は「表題 / 公式URL / 公表日 / 概要50字」。Gemma3を用いた結果：
- 家計調査 – 統計局ホームページ / 公式URL / 2025年8月8日 / 最新の家計調査結果を提供
- 家計調査報告（家計収支編）2025年版 / 公式URL / 2025年8月8日 / 結果概要を簡潔に提示
- 家計調査 2025年6月分 / 公式URL / 2025年8月8日 / 詳細統計データを収録
要点を短く整形して返すので、そのまま業務文書に転用できる品質でした。
プライベート編：家族旅行プランの参考に
実際に gpt-oss に「2025年9月の連休に埼玉県内で家族向けイベントを教えて」と聞いてみた結果を、原文のまま以下に掲載します。gpt-oss が返した結果は圧巻。
埼玉県で9 月に開催される、家族向けの日帰りイベント（2025年）
日付 イベント名・場所 料金 特徴・おすすめポイント 9 月 6日（土） 「LOVE JAZZ TIME 2025」 <br>（さいたまスーパーアリーナ／けやきひろば） 無料 大人も子どもも楽しめるジャズライブ。子ども向けのワークショップが併設されていることがあります。 9 月 7日（日） 「TOKYO GENERATIONS COLLECTION」 <br>（さいたまスーパーアリーナ／メインアリーナ） 1,200円〜 若手歌手やアイドルが集結するライブ。子ども向けのミニコンサートも開催されることがあります。 9 月 7日（日） 「第80回 TOIRO寄席 三遊亭萬橘独演会」 <br>（TOIRO） 1,500円〜 親子で楽しめる日本の伝統芸能。お笑いや漫才が中心なので、子どもも大人も笑顔になること間違いなし。 9 月 7日（日） 「振袖店 Sweetpea 展示会」 <br>（TOIRO） 無料 伝統的な日本の美しさを体感できる展示。子どもにとっては色彩豊かなアイテムが目印です。 9 月 8日（月） 「たまーりん謎解き探偵クラブ vol.4」 <br>（けやきひろば） 1,200円〜 家族で参加できるインタラクティブなミステリーパーティ。子どもが主人公になって謎を解く楽しさがあります。 9 月 12日（金） 「埼玉県警察音楽隊コンサート」 <br>（けやきひろば） 無料 地域の安全と協力をテーマにしたライブ。子どもが見守るパフォーマンスは心温まります。 9 月 13日（土）～15日（月） 「ATEEZ 2025 WORLD TOUR」 <br>（さいたまスーパーアリーナ／メインアリーナ） 1,200円〜 K‑POPファンなら必見！親子でエネルギッシュなライブを楽しめます。 9 月 18日～28日 「第40回『私たちの自然を守ろう』コンクール受賞作品展」 <br>（けやきひろば） 無料 子どもの創作活動に触れられる展示。自然への関心を育む良い機会です。
どう選ぶかのポイント
選択基準 推奨イベント 子どもが楽しめるライブ／音楽 LOVE JAZZ TIME、TOKYO GENERATIONS COLLECTION、ATEEZ 体験型・インタラクティブ たまーりん謎解き探偵クラブ、TOIRO寄席 無料で気軽に参加したい LOVE JAZZ TIME、振袖展示会、警察音楽隊コンサート 自然や学びをテーマにした展示 第40回「私たちの自然を守ろう」
予約・チケット情報
- Saitama Arena（けやきひろば）
- チケットは公式サイトまたはチケット販売窓口（TICKET ONE、e+Ticketなど）で購入できます。
- 早期割引やファミリーパックがある場合がありますので、事前にチェックしてください。
- TOIRO
- 無料イベントも多いですが、座席指定の場合は公式サイトから予約可能です。
- たまーりん謎解き探偵クラブ
- 公式サイト（nazoad.com）でチケットを購入。子ども向けのワークショップが併設されている場合があります。
まとめ
9 月は埼玉県内でも多彩なイベントが開催されています。家族みんなが楽しめる音楽ライブから、インタラクティブなミステリーパーティまで、選択肢が豊富です。
おすすめは「LOVE JAZZ TIME」や「たまーりん謎解き探偵クラブ」です。 どちらも無料・有料問わず家族での参加に適しており、日帰り旅行にぴったりです。ぜひ、事前に公式サイトでスケジュールとチケット情報を確認し、楽しい一日を計画してください！
──ご覧の通り、単なるリストではなく「特徴」「おすすめポイント」「料金」「どう選ぶか」まで整理されて返ってきました。ローカルLLMがここまで「お節介な親切」をしてくれるのは、gpt-oss ならではの強みです。
しかも、Web検索後にこれだけの要約を書いた時点での消費Tokenは 2444 に収まっていた。軽量化による実用性が十分確保できていることを確認できました。
Gemma3は「最低限のURLを早くほしい人」、gpt-ossは「選択肢を比較検討したい人」──こう使い分ければ、どちらもローカルLLMらしい活用になります。
まとめと展望
今回の検証では、ローカルLLM＋Web Search MCPが実用レベルで「AI秘書」として使えることを確認しました。
- Gemma3：マルチモーダル対応という強みがあり、PDF分析などにも応用が期待できます。一方で、返答は淡泊にまとまりがちで、必要最低限をシンプルに返してくれる傾向。
- gpt-oss：GPT-4系譜らしく、お節介なくらい丁寧な情報整理や推奨を含んだ回答が特徴。イベント一覧や比較指針など、読み手にやさしいまとめ方をしてくれる。
- 共通点：いずれのモデルも、そのままではトークン消費が激しいが、
web-search-mcp/index.jsの出力整形を軽量化することで 消費トークンを1/5以下に削減。実用的に日常利用できるレベルになった。
ビジネスにもプライベートにも
- ビジネス：政府統計や省庁のリリースを、公式URLつきで取得。報告書づくりに安心して使える。
- プライベート：週末のお出かけ先を、日程・料金・おすすめポイントつきで提案してくれる。
展望
PDF直接要約は仕様制限でまだ弱いですが、HTML情報に限れば「ChatGPT感覚」で利用可能。
TTSやスケジューリング系MCPと組み合わせれば、ローカル完結のフル機能AI秘書への道も見えてきました。
付録：gpt-ossは自らの意思で、Webへ飛び立つ
今回の検証で最も驚いたのは、gpt-ossが“自らの意思”でWebに飛び立つことを確認できた点です。
通常、Web Search MCPを発動させるには「最新」「今日」「今週」といった“時のワード”をプロンプトに含めるのが定石とされてきました。公式の利用ガイドでも、そのような形での「呪文」が半ば必須とされていました。
しかし実際には、gpt-ossは自然文だけの問いかけでも、裏付けが必要だと判断するとWebへ飛ぶのです。
実際に「自由意志は存在するのか？」という哲学的な問いかけに対し、彼はためらいなく検索を開始し、複数の哲学辞典・研究記事を参照しながら丁寧に議論を整理してくれました。
これは偶然ではなく、歴史・哲学・社会問題といった“解釈が日々変わり得る領域”では、モデルが自律的に裏取りを試みるように見えます。
OpenAIが最適化した閉じたモデルならともかく、オープンソース系のgpt-ossでここまで“Webの翼”を見事に使いこなすとは、まさに驚きでした。
この発見は、「呪文必須」という従来の思い込みを覆し、ローカルLLM＋MCPの組み合わせが想像以上に柔軟であることを示しています。
