回答から住所へ：位置情報に基づくLLMの基盤構築

アプリケーションでは、現実世界に関する質問に答えるために、言語モデルへの依存度が高まっています。例えば、「オフィスの近くにあるおいしいコーヒーショップは？」「新しいレストランまで徒歩15分圏内にあるか？」「空港まで車でどれくらいかかるか？」といった質問です。言語モデルは、学習データに基づいて、こうした質問に流暢に答えることができます。 

しかし、アプリケーションがその回答に基づいて何らかの処理を行う必要が生じた場合――ピンを配置したり、ルートを表示したり、実際に到達可能な場所をフィルタリングしたりする場合など――、流暢な文章だけでは不十分になります。アプリケーションには、住所、座標、ルート設定可能な地点、移動所要時間といった、構造化された位置情報データが必要となります。 

本記事では、LLMを専用の位置情報ソースにグラウンディングすることで、3つの一般的な位置情報タスク（場所検索、到達可能性、移動時間）における結果の質がどのように変化するかを検証します。また、評価では、ウェブ検索を用いたグラウンディングと、Mapbox の位置情報APIを用いたグラウンディングとの間で、コストと実装上のトレードオフを比較しています。

要約すると：3つの機能

LLMを、オープンウェブの代わりに（あるいはオープンウェブと併せて）構造化された位置情報ソースに基づいて学習させると、3つの一般的な位置情報タスクにおける出力結果が変化します：

1. 場所検索： 特定の場所の近くにある場所を検索したり 、名前で検索したりすると、解析やジオコーディングが必要な文章形式ではなく、すべての検索結果に対して構造化された住所と座標が提供されます。このタスクは、コスト面でも最大のメリットをもたらします。
2. 到達可能性： 目的地が徒歩または車でN分圏内にあるかどうかを問い合わせると 、直線距離による推定値ではなく、レンダリングや「点と多角形の交差判定」操作で評価可能な等時間多角形が返されます。
3. 所要時間： AからBまでの所要時間を尋ねたり 、所要時間順に目的地を並べ替えたりすると、ウェブページから要約されたおおよその値ではなく、正確なルートに基づく所要時間が表示されます。

この記事に記載されているすべての測定結果は、GPT-5.5を用いた再現可能な評価に基づいています。この評価では、オープンウェブ検索とMapbox の位置情報APIのいずれかを基盤とした同一のプロンプトを比較しています。結果は、機能別（場所検索、到達可能性、移動時間）に分類されており、その後にコスト比較、実装例、および各アプローチが適切な場面に関する指針が記載されています。

「グラウンディング」の意味

言語モデルは、膨大なテキストコーパスから学習します。その学習した知識をもとに、多くの質問に正確に答えることができます。特に、その情報が長期にわたって安定している場合にはそうです。

「グラウンディング」は、応答を生成する際に外部ソースから情報を取得できるようにすることで、モデルの機能を拡張するものです。モデルは、学習データのみに依存するのではなく、ツールを呼び出して最新の情報を取得し、その情報に基づいて回答を生成します。これにより、応答がモデルの記憶ではなく、信頼性の高いデータソースに基づいているため、誤った情報を生成するリスクが軽減されます。 言語モデルは、リクエストの解釈や自然言語の生成といった、最も得意とするタスクを引き続き実行しますが、その基礎となる事実は、正確かつ最新の位置情報を維持するように設計されたシステムから得られます。

グラウンディングは、単なるAPIの直接呼び出し以上のものです。APIの呼び出しはデータを取得するものです。グラウンディングは、データの取得と言語モデルの推論を組み合わせることで、モデルがどの情報を取得すべきか、またそれを応答にどのように組み込むべきかを判断できるようにします。

1. 検索のあり方：オープンウェブは人々のために作られています

場所の検索は、AIアシスタントにとって最も一般的な位置情報関連のタスクの一つです。「パイク・プレイス・マーケットの近くのコーヒーショップ5軒」や「あのレストランの住所」といったリクエストが挙げられます。地図やルート案内アプリでは、完全な住所と正確な座標の両方が必要となります。

ウェブ検索に基づいたモデルであれば、多くの場合、その両方を提供することができます。課題となるのは、座標の出所を特定することです。ウェブページには通常、住所が掲載されていますが、座標が含まれていることはほとんどありません。これは、座標が機械向けに設計されているのに対し、ウェブコンテンツは主に人間向けに作成されているためです。その結果、モデルは住所から座標を生成するか、クエリと一致すると見られるサードパーティのリストから座標を抽出することになります。どちらのアプローチも決定論的ではありません。 生成された座標は実際の場所からずれてしまう可能性があり、一致したリストは、似たような名前を持つ別の事業所を指している場合もあります。一方、専用の位置情報ソースでは、住所と座標を単一の構造化されたレコードとしてまとめて返します。

この制限は、偶発的なものではなく、体系的なものです。元の出典で座標が明示的に提供されている場合にのみ座標を報告するよう指定したところ、ウェブ検索では26件の評価セットのうち38％について座標が返されましたが、その制約を適用する前は100％でした。 座標のほとんどは特定可能な出典がなく、残りの例も、多くの場合、愛好家による座標データベースや古い企業名簿から導出されたものでした。この制限は言語モデルそのものにあるのではなく、座標が第一級のデータとして公開されることが稀な、オープンウェブの構造に起因するものです。

各情報源が返す位置情報の信頼性はどの程度でしょうか？

独立した比較を行うため、ウェブ検索の結果は、Mapbox ではなく、中立的な基準を用いて評価しました。2つの独立したデータベースによって住所が確認された26か所について、米国国勢調査局のジオコーダーを用いてジオコーディングを行い、公式の座標とウェブ検索で得られた座標との距離を測定しました。

評価の結果、以下のことが判明しました：

• 報告された住所が公式記録と一致したのは、約65％の事例でした。
• 座標誤差の中央値は約270メートルでした。
• 26件の結果のうち8件（31％）は、類似した名称を持つ別の事業所と一致し、その座標は1キロメートル以上離れた場所に位置していました。

座標のずれはどのようなものか

約270メートルの座標誤差の中央値は、地図上で可視化するとより理解しやすくなります。以下の例では、インデックスに登録された位置と、同じ検索クエリに対してウェブ検索で返された座標を比較しています。住所は正しいものの、返された座標は1ブロック分ずれています。

モデルが作用できる対象

重要なのは、ある情報源が正確で、もう一方が正確ではないということではありません。ほとんどの問題において、どちらの情報源も正しい場合の方が多いのです。 重要なのは、構造化された位置情報ソースが、1回の呼び出しで正確かつ型指定された最新の住所や座標、あるいは明確な欠落情報をモデルに提供し、それを基に処理を進められるという点です。また、この方法で位置情報を特定するのは、3つのタスクの中で最もコストが低い方法でもあります。特定の場所の周辺を検索するコストはウェブ検索の3.4倍安く、地名で場所を検索するコストは6.4倍安くなりました。詳細な内訳は、以下のコスト表に記載されています。

2. アクセス可能性：「徒歩15分圏内」とは、単なる推測ではなく、ポリゴンを指します

「到達可能性」とは、よくある場所に関する疑問、すなわち「目的地まで徒歩15分以内か、車で10分以内か」という問いに対する答えです。ウェブ検索に基づいたモデルであれば、2つの場所間の距離を推定することで、多くの場合、妥当な答えを導き出すことができます。しかし、そうした推定値は通常、実際の交通網ではなく、直線距離に基づいています。直線距離による推定では、川や高速道路、一方通行の道路など、人々が実際に移動する際に影響を与える制約条件が無視されてしまいます。

専用のロケーションソースは、基盤となる道路および経路ネットワークから到達可能性を算出します。単に「到達可能」か「到達不可能」かの回答を返すのではなく、等時線――指定された移動時間内に到達可能なすべての場所を表す多角形――を返します。

答えは同じですが、Mapbox の結果は、推定値ではなく、レンダリングやジオフェンス設定が可能なポリゴンです。 重要なのは構造そのものであり、判定結果ではありません。これが、アプリ開発において重要な違いとなります。ウェブ検索では「はい」または「いいえ」という同じ結果が返されることがよくありますが、ポリゴンはアプリが実際に活用できるものです。例えば、表示したり、ジオフェンスを設定したり、100カ所の候補地を一度に照合してテストしたりできます。到達可能性ポリゴンは、ウェブ検索では決して返されないフィールドであり、モデルが独自に生成する必要があります。

構造が変わると、答えも変わります

シアトルでは、両情報源の見解が一致していました。しかし、常にそうであるとは限りません。ミルウォーキーにある2つの一般的な住所――ウェスト・ナショナル・アベニュー1100番地とウェスト・カナル・ストリート1100番地――を例に挙げましょう。これら2つの地点は、直線距離で約890メートル離れています。住所からは、その間にメノモニー・バレー――鉄道が頻繁に運行され、川も流れているが、両地点の間には歩行者用横断歩道がない地域――が走っていることは、まったく読み取れません。一方の地点からもう一方の地点まで徒歩15分かどうか、尋ねてみてください：

この件に関しては、ウェブ検索が不運だったわけではありません。単に不安定なだけなのです。 18回の実行のうち、半分のケースで「はい、約12分から14分です」という回答が得られました。これは、この特定の散歩ルートについて記載したページが存在しないため、単純な距離の近さを根拠としたものです。等時線は実際の歩行ルートを追跡しており、毎回、目的地を15分等時線の外側に位置づけています。これこそが「実地検証」の意義です。ウェブ検索が常に間違っているというのではなく、位置情報のソースが決定論的に正しいのは、確信を持って推測しても正確な場所が特定できない場合に限られるということです。

コストの面では、このタスクは場所検索よりも効率的です。ジオメトリがサーバー側で統合されているため――ツールがジオコーディングを行い、等時線計算を実行し、その点を検証して判定結果のみを返す――到達可能性チェックの実行コストは、Web検索に比べて4.2倍低くなりました。ポリゴン自体はモデルのコンテキストに入らないため、トークン数を抑えることができています。

3. 所要時間：正確な数値、かつ最新の数値

3つ目のタスクは移動時間です。A地点からB地点まで移動するのにどれくらいの時間がかかるか、あるいはどの目的地が最も近いかといったことです。このタスクにおいて、ウェブ検索は最も競争力があるように見えます。よく知られた場所については、ルート情報ページから妥当な移動時間の見積もりを表示することが多く、候補地を正しい順序で並べることも概ね可能です。しかし、アプリケーションが計算に利用できるような正確な所要時間を返すことはできず、また現在の道路状況も考慮に入れることはできません。 一方、位置情報ソースはルートマトリックスに基づいて回答し、道路網に基づいて計算された秒単位の正確な所要時間を返します。「走行交通プロファイル」を有効にすると、移動時間は現在の交通状況を反映したものになります。

2つの点に注目すべきです。まず、Mapbox の結果は、リクエスト時の交通速度、事故、通行止めなどの現在の状況に基づいて算出された実際の所要時間です。状況は1日を通して変化するため、表示される所要時間もそれに応じて変化します。これに対し、ウェブ検索では、現在の状況に基づいて算出されたルートではなく、公開済みのページから取得した静的な推定値が表示されます。

第二に、ランキングの例では、どちらの方法も正しい順序を算出しています。違いは、返される値にあります。「Mapbox 」は、1回のルート検索で正確かつ並べ替え可能な所要時間を提供しますが、ウェブ検索は、公共交通機関のブログ、マーケティングページ、PDFなど、複数の情報源から概算の所要時間を集約して表示します。この例では、ウェブ検索によるエンパイア・ステート・ビルへの所要時間の推定値が、ルート検索による所要時間よりも5分短いのは、ルート計算によるものではなく、同ビルが公表している訪問者向け情報に基づいているためです。

3つすべてを合わせた費用はいくらでしょうか

ウェブページを利用する場合、モデルはページ全体をコンテキストとして入力トークンとして取り込みます。たとえ関連情報がページのごく一部にしか含まれていなくても、モデルは周囲のコンテンツも処理します。一方、専用に設計されたロケーションソースは、代わりにコンパクトで構造化されたレコードを返します。同じ情報が、はるかに小さなペイロードで提供されます。以下の例は、「シアトルのパイク・プレイス・マーケット付近にある、住所が記載されたコーヒーショップを10件見つけてください」というクエリに対して、モデルが受け取る入力を示しています。

4つのタスクすべてにおいて、複数のページ読み取りが1つの構造化された呼び出しに集約され、それに伴ってコストも低下します。Web検索の入力は、ほぼ完全に取得されたページテキストで構成されています。34トークンの質問は、検索コンテンツが追加されると、モデルには約8,700トークンの課金対象入力として送信されますが、構造化されたレコードの場合は数百トークン程度です。 4つのタスク全体で測定すると、入力トークン数は13倍から31倍少なく、エンドツーエンドのコストは3.4倍から6.4倍低くなります。この差が最も大きいのは、2つの幾何学タスクです。これらのタスクでは、ツールが等時線や行列の計算をサーバー側で実行し、判定結果のみを返すため、ポリゴンはモデルのコンテキストに入ることはありません。

Web検索の料金は2つの項目で同時に請求されます。1,000コールあたり10ドルに加え、取得されたコンテンツについてはモデルの入力レートに基づいて課金されます。 ある構成として、推論機能を持たないモデル向けのプレビューツールでは、コンテンツは無料で提供されますが、1,000コールあたり25ドルの料金が設定されています。この料金だけでも、表に記載されているMapbox の完全なクエリのコストを上回ります。GPT-4.1でエンドツーエンドに測定したところ、無料コンテンツの構成でも、Mapbox を通じて実行された同等のタスクに比べて、コストが約3～6倍になる結果となりました。

行動面での重要な違いの一つは、モデルに「web_search」ツールを提供しても、モデルがそれを必ず使用すると保証されないという点です。一部の移動時間に関するクエリでは、モデルはウェブ検索を行う代わりに、記憶に基づいて回答しました。こうした回答はコストは低くなりますが、根拠に裏付けられていません。ここで測定したクエリのように、モデルが実際にウェブ検索を行う場合、検索ごとに検索ごとの料金に加え、追加のページトークンが発生します。

クエリ1件あたりのコストが数セント未満であっても、本番環境の規模になるとその積み重ねは無視できないものとなります。また、Web検索にはトークンコストに加え、検索1回あたりの定額料金も発生します。定価では、1,000回の検索につき10ドルです。 3回の検索を実行するクエリの場合、入力トークンのコストを除いても、検索手数料として約0.03ドルが発生します。本番環境のトラフィック規模では、この手数料は推論コストの重要な要素となります。これがどの程度重要になるかは、トラフィック量や利益率によって異なります。この費用対効果の判断はお客様ご自身で行う必要があります。そのため、ここに記載されている数値はすべて、お客様自身の数値を用いて再現可能な実行結果に基づいています。

コードの形は同じです

どちらのソースを接続しても、配線はほぼ同じです。モデルにはツールが用意されており、必要に応じてそれを呼び出します。以下の例では、Web検索を使用するモデルと、Mapbox がホストするMCPサーバーを介して接続されたモデルを比較しています。このクエリに必要な2つの検索ツール、すなわちランドマークのジオコーディングを行うツールと、指定されたカテゴリの近隣の場所を検索するツールに限定しています。認証には、Mapbox のアクセストークンをBearerトークンとして渡す方式を採用しており、インフラストラクチャの展開は不要です。

LLM ＋ ウェブ検索

import { Agent, run, webSearchTool } from "@openai/agents";

const agent = new Agent({
  name: "web-search",
  model: "gpt-5.5",
  instructions: "Answer the question. Use web_search for current info. Cite sources.",
  tools: [webSearchTool()],
});

const result = await run(agent, "5 coffee shops near Pike Place Market, with addresses");

LLM +Mapbox

import { Agent, run, hostedMcpTool } from "@openai/agents";

const mapbox = hostedMcpTool({
  serverLabel: "mapbox",
  serverUrl: "https://mcp.mapbox.com/mcp",
  authorization: process.env.MAPBOX_TOKEN, // a Mapbox access token, sent as Bearer
  allowedTools: ["search_and_geocode_tool", "category_search_tool"],
  requireApproval: "never",
});

const agent = new Agent({
  name: "mapbox-search",
  model: "gpt-5.5",
  instructions: "Answer location questions only from the Mapbox tools. To find a " +
    "category of place near a landmark, geocode the landmark first, then " +
    "category-search that category around the point. Give addresses and coordinates.",
  tools: [mapbox],
});

const result = await run(agent, "5 coffee shops near Pike Place Market, with addresses");

必要な労力は同じです。違いは、その結果として得られるものです。モデルが言い換えた文章か、それともモデルやあなたのコードが直接利用できる構造化されたフィールドか、という点です。他の2つの機能が必要な場合、同じサーバーがアイソクロンと伝播時間行列を関連ツールとして公開しています。また、具体的な手順を知りたい方のために、検索ツールの自作バージョンが、付属のリポジトリに同梱されています。

いつ、どれを使うか

これらのアプローチは競合するものではなく、互いに補完し合うものであり、どちらを選ぶべきかは課題によって異なります。構造化された位置データは、座標、ポリゴン、および経路に基づく移動時間を返すように設計されていますが、オープンウェブにはそのような機能はありません。この比較は、そうした設計目標の違いを反映したものです。より興味深いのは、ここで評価した3つの課題において、それぞれのアプローチがどのようなパフォーマンスを発揮するかという点です。

• 場所の検索と周辺検索。これは、構造化された情報源が最も明確に優位性を発揮する分野であり、しかも2つの側面において同時にその強みを発揮します。すなわち、オープンウェブには存在しない、入力された住所や座標を返すことができる上、1回の構造化された呼び出しで複数のページ読み込みを置き換えることができるため、コストを3.4～6.4倍削減できるのです。ここでは、デフォルトで構造化された情報源を活用するようにしましょう。

• 所要時間の検索について。最も微妙な回答ですが、有名な場所であれば、ウェブ検索では妥当な目安となる数値と、通常は正しい順位が得られます。しかし、ウェブ検索ではリアルタイムの交通状況を確認できず、放っておくと検索を一切行わずに記憶に基づいて回答してしまう可能性があるため、その回答が事実に基づいているかどうかさえ確信が持てません。 構造化された情報源からは、正確でソート可能な数値が得られます。さらに、走行交通プロファイルを活用することで、実際の速度、事故、通行止めなどを反映した「現在の状況に基づく」所要時間が得られます。これは、モデルだけでは得られない情報です。コードで計算に利用できる値や、現在の道路状況を反映した数値が必要な場合は、この情報源をご利用ください。おおよその静的な回答で十分な場合は、ウェブ検索を妥当な代替手段としてご利用ください。

• 到達可能性。ある有名な2つの場所について「はい」か「いいえ」の答えだけが必要な場合は、多くの場合、ウェブ検索で十分です。しかし、その答えをアプリで表示したり、ジオフェンスを設定したり、多数の候補に対して検証したりする必要がある場合は、構造化された情報源のみがポリゴンを返します。ウェブ検索では、それを独自に生成しなければならないからです。

ウェブ検索は、その本来の強みである「広範さ」「ニュース」「オープンウェブのロングテール」、そしてどこかのページに存在するあらゆる情報を、依然として維持しています。また、この記事では意図的に除外した質問のカテゴリーがあります。それは「拡張クエリ」です。「街で一番おいしいタコス店」「生演奏が楽しめる本格的なダイブバー」といったものです。 構造化されたインデックスは、この点において正直すぎるほど正直です。最上級表現や雰囲気といった要素は、そのインデックスが扱うフィールドには含まれていません。なぜなら、そうした情報は、オープンウェブ上のレビューやリスト記事、地域密着型の記事などに存在しているからです。 こうした質問に答えるパターンは、2つの情報源を順次活用するものです。まずウェブ検索がクエリを拡張して候補を発見し、次に位置情報ソースが各候補を具体化し、アプリが処理するために必要な住所、座標、アクセス可能性、移動時間といった情報を付加します。この記事はシリーズの第1弾です。次回は、そのパイプラインを構築し、具体的な数値データを用いて検証します。

このレイヤーもモデルに依存しません。グラウンディングは優れた言語モデルの代わりになるものではなく、優れた入力データを提供するものです。モデルが優れていればいるほど、その基盤となるクリーンで最新のソース情報があればあるほど、より正確な結果が得られます。

ぜひご自身の目で確かめてみてください

ここにある数値はすべて、再現可能な実行結果に基づいています。 付属のキット（GitHub上の実行可能スクリプトで、各主張ごとに1つずつ用意されています）は、皆様ご自身のキーを用いて各比較を行います。具体的には、トークン税領収書、および場所検索のための座標出所・座標ドリフト・型付きフィールドのプローブ；等時線到達可能性チェックとミルウォーキーの判定反転；運転交通量と移動時間のランキングに関する実行；そして、各図の背後にある結果ファイルを含む、タスクごとの完全なコストベンチマークです。 READMEには、各ケースがどのように発見されたかも記載されています。これらを実行して、検証結果をご確認ください。

方法に関する注記、および誤りの可能性がある点

位置情報の信頼性。「場所検索」テーブルの「web」列については、2つの独立したデータベースで記録上の住所が一致している26件の場所を対象に、米国国勢調査局のジオコーダー（ベンチマーク：Public_AR_Current）を用いて評価を行いました。国勢調査の座標は屋上位置ではなく道路位置で補間されているため（数十メートルの誤差が生じます）、閾値を500 mに設定しました。この幅があれば、参照データの誤差によって誤って合格判定されることはありません。 「Mapbox 」列は意図的にテキスト形式となっています。その住所と座標はインデックス化されたレコードそのものであり、地名に基づいて評価を行うことで、正確性ではなく地名の重複を測定しています。

到達可能性と所要時間。経路設定の行は、実際のキャパビリティ実行から得られた単一の処理事例であり、各回答の傾向を示すために提示されたもので、大規模なサンプルではありません。所要時間に関する注意点については、表にも明記されている通り、実際のものです。すなわち、自動車交通の所要時間は現在の状況をリアルタイムで捉えたスナップショットであるため、1日を通して変化します。また、順位付けの事例については、両方のソースが場所を正しく並べ替えていますが、「Mapbox 」のエッジは、区間ごとの正確な（ソート可能な）所要時間（分）を示しており、順序そのものを示しているわけではありません。

ばらつきとコストの基準について。Web検索は、1回、数回、あるいはまったく行われない場合があります。モデルが自由に選択した「移動時間機能のベースライン」では、実行回数の3分の1のみ検索を行い、残りはメモリから回答しました。 コストテーブルを用いた実行では、クエリごとに1回検索が行われたため、これらの比較は同等の条件下での比較となります。Web検索の料金は、1,000コールあたり10ドルに加え、モデルの入力レートに基づく取得コンテンツの料金が課金されます。ここでのトークン数は、APIが報告する課金対象のカウント数です。 コストの数値は、gpt-5.5 において、公表された定価に 1 コールあたりの料金を加算した条件で、3 回のベンチマーク実行（各 3 回繰り返し）の中央値です。2 つの幾何学関連の行では、ジオコーディングと等時線または行列の計算をサーバー側で実行し、コンパクトな結果を返す統合ツールを使用しているため、ポリゴンはモデルのコンテキストに入ることはありません。

以下のツールを使用してビルドしてくださいLocation AI

AIエージェントやAIネイティブアプリケーションの開発、あるいは既存の製品にロケーションインテリジェンスを追加する場合でも、Mapbox （Location AI ）の「はじめに」ガイドをご覧いただき、ご自身のデータを使って付属のベンチマークをお試しください。ユースケースについてご相談したい場合や、アーキテクチャのアプローチを検討したい場合、あるいは共同で開発を進めたい場合は、 Mapbox チームまでお問い合わせください。