POI検索の失敗ログから見えた「誤字脱字」と「ユーザーの真の意図」

こんにちは、AI技術開発部の齋藤智輝です。

この記事は、GO Advent Calendar 2025 19日目の記事です。

タクシーアプリ『GO』の目的地検索(POI検索)において、私たちはユーザー体験を損なわないよう 「検索速度」 を非常に重視しています。しかし、速度を最優先する検索アルゴリズムを採用しているがゆえに、少しの誤字や脱字が含まれるだけで検索結果が0件になってしまうという課題を抱えていました。

対象ケース: 誤字脱字による検索失敗

今回は、この課題に対して私たちがどのようにアプローチしたか、そして分析を進める中で見えてきた「誤字脱字以外の課題」についてお話しします。

誤字脱字は誰にでも起きる、でも対応は難しい

実際の検索ログを見ていくと、単なる知識不足による間違いだけでなく、スマホならではの入力特性や検索システムの仕様が絡んだ、対応の難しいケースが見えてきました。

1. フリック入力による打ち間違い

スマホ入力特有の現象として、指の滑りによる入力ミスが多発しています。

  • 「東京駅(とうきょうえき)」 → 「とうきょうえひ」

    • 「き」を入力しようとして手元が狂い、誤った文字が入ってしまうパターンです。
  • 「焼肉(やきにく)」 → 「やき「く」

    • (「に」を入力しようとして指の位置が下にずれ、下のキー(や行)をフリックして記号が入ってしまうパターンです。)

これは純粋な操作ミスですが、ユーザー自身も気づきにくい場合があり、検索側でのフォローが求められます。

2. 文字入力中の「途中経過」

さらに判断が難しいのが、インクリメンタルサーチ(一文字打つごとに検索する仕様)における入力途中のクエリです。

  • 「とうきょう」 → 「とうきよう」 (小さい「ょ」にする前)

  • 「おだいば」 → 「おだいは」 (濁点をつける前)

これらは厳密には誤字脱字ではありません。ユーザーは正しく入力しようとしている最中です。しかし、システム側から見れば、この瞬間のクエリは「トウキヨウ」「オダイハ」という誤った文字列として飛んできます。

速度を重視して一文字ごとに検索リクエストを送る仕様上、こうした 「入力過程の文字列」を誤字として許容するかどうか は非常に悩ましい問題です。これらを全てカバーしようとすると検索ノイズが増える可能性もあり、単純な辞書登録だけでは解決できない難しさがあります。

ユーザーの「手動ピン設定」から誤字脱字を抽出する

「東京駅(とうきょうえき)」を「とうきょうえひ」と入力してしまい、候補が出ない。

こうした入力ミスや入力過程での不一致を救い上げるためには、まず「ユーザーがどのような間違いをしているのか」を知る必要があります。しかし、先ほど見たように入力ミスはパターンが無限にあり、想像だけで網羅することは不可能です。

そこで私たちが着目したのは、 「検索を利用したが結果を選ばず、最終的に手動で地図上のピンを動かして迎車位置を設定した」 という行動ログです。

このログには、「ユーザーが入力してしまった誤字(検索クエリ)」と「本来行きたかった正しい場所(手動設定した緯度経度)」の答え合わせが含まれていると考えました。

具体的には以下のステップで分析を行いました。

  1. 正解POIの特定 ユーザーが手動でピンを立てた緯度経度から、その最寄りにあるPOI(施設)を「正解」と仮定する。 step1: 正解POIの特定

  2. クエリとの比較 直前に入力されていた検索クエリと、正解POIの名称を比較する。 step2: クエリとの比較

  3. 類似ペアの抽出 編集距離などを計算し、文字列として似ているものを「誤字・脱字ペア」として抽出する。 step3: 類似ペアの抽出

この分析により、実際のユーザーがつまずいているリアルなパターンを効率的に収集することができました。

誤字脱字だけではなかった、検索失敗の理由

上記の分析を進めていく中で、実は「誤字脱字」として処理するには不適切な、全く別の課題も浮き彫りになってきました。

抽出された「検索失敗クエリ」の中には、単純な文字の間違いではなく、ユーザーの検索意図がシステムと噛み合っていないケースが多数含まれていたのです。

例えば以下のようなパターンです。

  • 「末尾かな」残り

    • 「東京えき」「東京こくさいフォーラム」のように、変換途中の文字列に対して検索結果を表示したいケース。
  • 「住所」の直接入力

    • 施設名ではなく、「東京都新宿区西新宿...」のように住所をそのまま入力しているケース。
  • 「現在地」という入力

    • 「現在地」「今いる場所」といったワードで検索し、現在地周辺の施設を探そうとしているケース。
  • 「1文字」や「記号」

    • 地図上のアイコンを探す意図なのか、「P(駐車場)」や「〒」のような記号のみのケース。

今回得られた対応するげきクエリ種別)

これらは単に「誤字脱字辞書」に登録すれば解決する問題ではありません。「住所が入力されたら住所検索ロジックへ流す」「"現在地"と入力されたら周辺検索モードへ切り替える」といった、クエリの意図(Intent)を正しく分類し、適切な検索ロジックへ振り分けるという、より高度な対応が必要であることがわかってきました。

単に「表記の揺れ」を直すだけでなく、ユーザーが検索窓に何を期待しているのかを深く理解することが、次の改善へのステップだと考えています。

DeNA x GO AI技術共有会で登壇しました

今回の記事でご紹介した「誤字脱字との戦い」の詳細については、先日開催されたDeNAと合同のAI技術共有会にて発表を行いました。

当日のスライドでは、具体的なシステム構成や、誤字脱字対策のより詳細なアプローチについても触れています。ご興味のある方は、ぜひ以下の資料をご覧ください。

POI検索システムにおける 誤字・脱字との戦い - Speaker Deck