iOS 6 Map
iOS 6

位置情報処理の困難さを解剖する―Appleはこの5点の解決が必要

次の記事

iOS 6 App Storeの5大変更点(およびデベロッパーがすべきこと)

GrantRitchie

編集部: 寄稿者のGrant RitchieはLocationaryのファウンダー、CEO 。同社はローカル・ビジネス向けの情報分析共有プラットフォーム、Saturnの開発元。Locationaryの公式Twitterアカウントはこちら。

ここしばらくテクノロジー業界はAppleがGoogleとの競争を試みた結果、位置情報処理の困難に遭遇していることについての議論で盛り上がっている。その困難はたとえば次のようなものだ。

地図製作専門家のMike DobsonはAppleが直面している困難を分析し、5つの重要な分野において問題を解決する必要があることを的確に指摘した。

しかし読者の多くはDobsonが指摘した問題を解決するのがどれほど難しいか理解できないだろうと思う。そこで私は私は実例を交えてその困難さを解説してみるとことにした。

1. 異なるプロバイダからの位置情報データを統合するのは難しい
位置情報をできるかぎり完全なものにするためには各地域で基礎的な地図データ・セットを少なくとも数種類用意する必要がある。たとえばAppleはアメリカではLocalezeInfoGroupAxciomCompassの各地図データ・プロバイダと契約している。企業、店舗等の情報は1500万件に上る。データ・プロバイダはそれぞれに長所と短所がある。だからAppleなどの大規模な地図アプリ開発者は複数のプロバイダと契約する必要があるのだ。

2. 異なるプロバイダからのビジネス位置情報データを統合するのはさらに難しい
地図サービスを作るためには基礎的な地図データの上にさまざまなカテゴリー別に地域ビジネスその他の情報を載せていく必要がある。Appleは飲食店や小売店舗のレビューではYelp、ホテルや観光ではHotels.com、TripAdvisor、HotelsCombinedなどの既存サービスと提携してデータの提供を受けている。またWal-mart、Starbucksなどの全国チェーンからも独自情報を得ている。Apple地図のようなアプリを開発するためには数十もの別個の情報源が必要になる。大規模検索エンジンの場合、100以上の情報源を利用することも珍しくない。

3. さまざまな位置情報を標準化することは予想をはるかに超えて難しい
さまざまな情報源から各種の位置情報を得た後で、それらを単一のアプリで役立てるためには、まず共通フォーマットに落としこむ必要がある。しかしながら、上記のプロバイダはそれぞれに独自の情報フォーマットを持っており、それらの間に互換性はまったくない。フォーマットはおそろしく複雑であり、そのデータベースは簡単に扱えるようなものではない。

たとえば、企業や店舗の電話番号というようないちばん簡単そうなデータでさえ、フォーマットは情報源によって異なる。ある情報源は電話番号を3つのエントリーに分割している(地域局番= 212、市内局番=555、個別番号=1212など)。単一のエントリー(2125551212)とするデータベースもあれば、 (212) 555-1212と分割するデータベースもある。住所の表示フォーマットはさらに複雑なバリエーションがある。

次にビジネス・カテゴリーを統一する必要がある。一部のプロバイダはNAICS(北米産業分類システム)を利用しているが、SIC(標準産業分類)コードを利用しているプロバイダもあり、自社独自の分類を採用しているプロバイダもある。Appleはこうしたばらばらの分類を独自の統一フォーマットに落とし込まねばならない。カテゴリーの分類方法には多くの場合、数百もの種類がある。

データフィールドが統一できたら、次にユーザーが簡単に正しく目的のデータを検索できるようにする必要がある。 ユーザーがどんな単語で検索しても正しい検索ができるよう、すべてのカテゴリーについて同義語を網羅しなければならない。Appleが優れた地図サービスを提供するためにはこれらの作業すべてが必要だ。しかし〔買収や委託によって外部のサービスの力を借りようとしても〕位置情報専門企業の多くは専門分野に特化している。

多様なフォーマットやカテゴリーの統一はそれ自身でも難題だが、もしAppleが月単位、週単位でのバッチ処理によるアップデートに満足せず、リアルタイム・アップデートを目指すとするなら、それがまた大きな課題となる。

4. 位置情報データの処理ルールには必ず例外が存在する
データの標準化をした後、Appleは店舗、公共施設その他のあらゆるPOI(興味を引く地点)ごとに適切な情報源から情報を収集した複雑な情報ファイルを作成しなければならない。しかしその作業にかかる前に、異なる情報源が同一の現実の対象を指していることを確認する必要がある。

現実の対象に割り振られた統一的IDが存在しない以上、これは非常に困難な作業になる。同一の現時的対象であっても地図データ・プロバイダごとに名称も住所も緯度経度も異なる。たとえば、同じホテルが次のようにまったく異なったデータを与えられている。

プロバイダ #1:
Days Inn Cedar Point South Milan (Ohio)
11410 State Rt 250, Milan (Ohio), Ohio

プロバイダ #2:
Sandusky Days Inn Cedar Point South Turnpike
11410 SR 250, Milan, Ohio

こうしたデータを分析して整合性を確保するのは非常に時間のかかる困難な作業になる。POIプロファイルを解析する高度なアルゴリズム、ユーザーのフィードバックを吸い上げるレポート・システムによる大規模なクラウドソシーシング、強力な機械学習などが必要だ。しかも以上に見てきたように、こうしたタスクは一つが完成しないと次のステップに進むことができないようなシーケンシャルな性質を持っている。つまり30人のデベロッパーが同時に作業すれば1人のデベロッパーより30倍開発は速くなるというわけにはいかない。

これ以外にも位置情報処理に関連した困難はさまざまだ。

こうした処理を一つでも誤るとたちまち下記のSears店舗のように際限なく重複が生じる。

5. 複数の位置情報を統合して複合データベースを完成させるのはそれだけで一大産業を必要とする

役に立つ地図サービスを提供するためには、個々のPOIに関連するテキスト、写真などの情報を異なるデータベースから抽出し、適切なものを選択して複合ファイルを作成し、最終的にデータベース化する必要がある。そのためには、まず項目ごとにどの情報が最適であるかを判定しなければならない。

たとえばクローラーでネットから収集した電話番号はcall-tracking番号(オンライン広告の効果を判定するため設定された臨時の番号。短期間で無効になったり、他の会社に転送されたりする)であり、その店舗の本当の番号ではないことが多い。電話帳をコピーした場合は、電話帳が編集された後の変更が得られない。こうした情報の処理を間違えると、クリックしても正しいサイトが表示されず、間違った電話番号を教えられ、間違った場所に案内され、あるいは行った店はすでに廃業していたといった不愉快な経験を味わうことになる。

真にリアルタイムな世界への展望

地図、ディレクトリその他位置情報サービスにとってデータの整理統合は地味だが死活的に重要で複雑きわまりない作業だ。この作業の重要性にユーザーが気づくのは与えられた情報が間違っていることを発見したときだけだ。上で見たように、名称、住所、電話番号というような一見単純なデータでさえ統合は容易ではない。

将来、レストランのメニュー、店舗の在庫、バーゲンセール、イベントから求人情報にいたるまであらゆる情報がリアルタイムで適切に位置情報と統合されるようになるためには、利用するソフトウェアやデバイスとは独立な位置情報の規格化、標準化が必要になってくるだろう。

[原文へ]

(翻訳:滑川海彦 Facebook Google+