【デスクトップ・チャットマスコット】AIは優秀なナビゲーターになれるか？🗺️

前回の「デスクトップ・チャットマスコットの今後」の記事で、以下が課題として残っていました。

結論は、Gemini APIのGroundingを使って経路探索が可能なことが確認できました。

今回はこの検証内容を記事にまとめてみました。

Gemini APIのGroundingとは

Gemini APIには「Google検索」をツールとして持たせる機能（Grounding）があります。

• 仕組み: Geminiが「これ検索が必要だ」と判断したら、Google検索を実行して、その検索結果（乗り換え案内や地図情報）を読んで回答を作ります。

• できること:

  • 「〇〇病院の住所は？」→ 検索して回答（OK）

  • 「ここからそこへのルートは？」→ 検索結果から概要を回答（OK）

  • 「電車の時間は？」→ ジョルダンやYahoo!路線の検索結果から読み取る（精度はそこそこ）

• メリット: 実装が超簡単。追加のAPI契約が不要（Gemini APIのオプションで完結）。

ちなみに「Grounding」＝「Google検索そのもの」 なので、経路検索に留まらず、Google で検索できるものは Grounding で解決できます。

つまり、ローカルLLM内に無い情報は「とりあえずGemini (Grounding) に投げれば解決する」ということです。

料金の仕組み（二重課金に注意！）

Gemini API で Grounding（検索）を使う場合、料金は一般的に以下の 「2階建て」 になります。

推論コスト（トークン課金）:

• ユーザーが送った文字数（入力） ＋ Geminiが答えた文字数（出力）。

• これは Gemini 1.5 Flash なら 激安 です。

※GroundingではGemini 1.5系は使えませんでした（404 Not Found）
　Gemini 2.0以降（gemini-2.0-flashなど）が使えます。

Grounding利用料（検索クエリ課金）:

• ここが落とし穴です！

• 検索機能（Google Search）を1回呼び出すごとに、「検索手数料」 が追加でかかります。

• （※一般的に1000回あたり数ドル程度＝1回数円のイメージ）

つまり、「普通の会話」よりも「検索付き会話」の方が、1回あたりの単価は高くなります。

Gemini (Grounding) に投げるべきこと（課金対象）

• 「明日の天気は？」

• 「最新のAIニュース教えて」

• 「ここから病院までのルートは？」

• 「ドラクエの発売日は？」

こうやって 「情報の鮮度が必要なときだけGeminiを叩く」 という制御をローカルLLMが行えば、
「機能は最強（ネット検索可能）なのに、維持費は最小（Flash価格）」 という、夢のようなシステムが運用できます！

Groundingの検索例：

検証シナリオ

目的：

複数の訪問先を巡回する経路をAIが的確に提案できること。（訪問先は時間条件の有無を混在する）

検証シナリオ：

1. 「Gemini API の Grounding（検索連携）」の利用準備、設定

2. 「Gemini API の Grounding（検索連携）」に接続するための簡易チャットボットの作成

3. 検証１：予め作成したプロンプトを「Grounding」に与えて、想定通りの巡回経路が回答できるか？

4. 検証２：検証１の情報を元にして、AIにプロンプトを作成させる

5. 検証３：検証２で作成したプロンプトを「Grounding」に与えて、巡回経路の取得までの一連の検証評価を行う

Grounding（検索連携）の利用準備

必須条件:

• npm install @google/generative-ai していること

• Gemini APIキーを取得していること

テスト用コード

※目的地は架空の施設名です。「仙台市民病院」は存在しませんが
　サンプルとして仮に記載しています。

// test_grounding.js
const { GoogleGenerativeAI } = require("@google/generative-ai");

// APIキーを設定（環境変数か直接記述）
const genAI = new GoogleGenerativeAI("YOUR_API_KEY");

async function runTest() {
  // ★ポイント: tools に googleSearch を設定するだけ！
  const model = genAI.getGenerativeModel({
    model: "gemini-2.0-flash",
    tools: [
      {
        googleSearch: {}, // これを書くだけで検索機能が有効化されます
      },
    ],
  });

  // ③検証1用のプロンプト（仮）
  const prompt = `
    あなたは秘書です。以下の予定をこなすための移動ルートを検索して教えて。
    現在地：仙台駅
    目的地：仙台市民病院
    希望到着時間：本日(2026/1/6)の10:00
    移動手段：公共交通機関
  `;

  console.log("🤖 検索中...（ちょっと待ってね）");
  
  try {
    const result = await model.generateContent(prompt);
    const response = await result.response;
    
    console.log("\n====== 💬 回答結果 ======");
    console.log(response.text());
    
    // 検索に使ったソース元などのメタデータが見たい場合
    // console.log(result.response.candidates[0].groundingMetadata);
    
  } catch (error) {
    console.error("❌ エラーが発生しました:", error);
  }
}

runTest();

検証１：予め作成したプロンプトを「Grounding」に与えて、想定通りの巡回経路が回答できるか？

ユーザー側で作成したプロンプトで想定した経路検索ができるかを試してみました。

検索条件：
- 出発地：〇〇駅
- 目的地：〇〇病院（2026/1/6 10:00到着予定）

検索結果：
目的地に予定時間までに到着するため、最寄り駅の電車の時間を検索してくれました。
検証結果は合格と判断しました。

検証２：AIに経路検索させるためのプロンプトを作成させる

今度はローカルLLMを使って「Grounding」に経路検索させるためのプロンプトを作成させました。

プロンプト：

ポイントはいかにユーザーに配慮したプロンプトを作れるかです。
以下のプロンプトをローカルLLMの Qwen3-32Bに指示しました。

出力結果：

Qwen3はちゃんと「答え」を書かずに、「Geminiへの命令書（クエリ）」を作成することに成功しています。

これも検証結果は合格と判断しました。

検証３：検証２で作成したプロンプトを「Grounding」に与えて、巡回経路の取得までの一連の検証評価を行う

検証2で出力された情報を Grounding のテスト用コードに貼り付けて、期待した巡回経路が取得できるかを検証してみました。

出力結果：

①LLM→ Grounding へのバトンパス（Relay）

• Qwen3（脳）: 地図を持っていないのに、「病院の近くで薬をもらって」「そのあと銀行へ」「雨だから濡れないルートで」という「ユーザーに配慮した指示書」を書きました。

• Gemini（目と足）: その指示を正確に理解して、「アイン薬局」や「七十七銀行 仙台駅前支店」という「実在する具体的な場所」を検索して埋め込みました。

②「雨対策」への執念

• 回答の中に何度も「ペデストリアンデッキ」「屋根のあるルート」「駅直結」「エスパル」という言葉が出てきます。

• ただのルート検索なら「徒歩○分」で終わるところを、ちゃんと「濡れないこと」を最優先してナビゲートしてくれています。

③スケジューリングの正確さ

• 「10:00到着目標なら、9:30頃に出発」というアドバイスも的確です。

• ランチを「駅ナカ（牛たん通り）」に誘導したのも、移動コストと雨リスクを最小限にする判断をしてくれています。（ただし、病院に行く程度で牛タン食べには行きませんが…笑）

結果として、Gemini API を使って「ユーザーに配慮した的確な経路検索」ができたため、検証は合格と判断しました。

中略

以上の検証によって、
「ローカルLLM（Qwen3）にユーザーの事情を汲み取らせ、Geminiに現実世界を検索させる」
という目的は達成できました。

あとは、AIに「ユーザーの好みDB」などを作ってもらって、その情報を元にランチの店を探してもらうこともできるかなと🤭

課金状況によって、Gemini（Grounding）を実装するか、別の仕組みを構築するかを検討してみます。