正確な地図を、正確なままタブレットなどで扱える時代になりました

いとちり先生が、ハザードマップなどの正確な地図を、教育現場でも有用なタブレットなどでも見られるデータ形式にするためのTipsを公開されています。 4回連載です。

• 【連載】地理教師のためのハザードマップ料理法（1）PDFを画像ファイルに: いとちり
• 【連載】地理教師のためのハザードマップ料理法（２）QGISを国土地理院につなぐ: いとちり
• 【連載】地理教師のためのハザードマップ料理法（3)ジオリファレンス: いとちり
• 【連載】地理教師のためのハザードマップ料理法（４) GeoTiffファイルを盛り付ける: いとちり

正直、やっと時代がここまで来たかーという感じで、個人的にすごくうれしいです。 私は不正確な地図を扱うためのソリューションとして、Maplatという技術を開発しており、同種の機能を展開しているStrolyという技術と対抗しています。 もちろん対抗している以上自分の方が使われた方がうれしいですが、ぶっちゃけて言ってしまえば、皆が正確な地図を扱うのにStrolyさえ使わないでいてくれたら、不正確な地図を扱う範囲であれば、Strolyを使おうがMaplatを使おうが私にとっては大した差ではないのです。 なぜなら、Strolyの運営は、正確な地図を正確なまま（GISとして）扱える形で技術を成長させようという提案を一蹴しただけでなく、『Strolyのような最新の技術が、GISのような古臭い劣った技術を導入できるか』と大意で言うような、GISを小馬鹿にした物言いまでしたのですから。

6年ほど前、私はStrolyの中の人だったのですが、GISの技術者でもあったので、不正確な地図を地図システムとして扱えるようにするStrolyの理念には賛同していましたが、一方で、Strolyを通すと正確な地図まで不正確にしか扱えなくなってしまうのを危惧していました。 正確なデータは、正確さを保ったまま扱えるようにすべきだという信念を私は持っていましたので、StrolyはGISデータも正確なまま読み込めるような進化をすべきだ、という主張を当時社内でしておりましたが、それに対して経営陣は先に書いたような言葉で否定してそれを拒んでいました。 結局、それにも端を発した一連の対立の結果、私は経営陣に騙されてStrolyを追い出されるに至ったのですが、そのような事を中で体験していたものですから、Strolyが元が正確な地図データを扱うという事に、非常な嫌悪感を持っていました。

その頃、いとちり先生もStrolyのユーザだったのですが、不正確な観光マップ等をStroly化する分には何の抵抗も感じなかったものの、先生は高校の教師ですから、教育のために正確な地形図やハザードマップ等もStroly化して授業で使おうとされているのに、とても悔しさを感じていました。 先生には先生の立場があり、教育現場でのタブレットの活用などのテーマもある中で、当時は不正確に扱うとはいえ、タブレットの上で自由に地図を表示できるソリューションはStrolyくらいしかありませんでしたから、それを活用して授業をする先生の行為は十分に理解できたのですが、しかし私はStroly運営の内情を知っていますから、先生、その方々はGISの敵なんですよ...ととても悲しい思いで見ていたのを覚えています。

それから月日がたち、記事の最初で引用したように、いとちり先生も正確な地図を正確なままタブレットなどに導入する方法を確立され、正確な地図まで不正確に扱うStrolyを、タブレットで使うためだけに活用するような時代は終わりを告げたようです。 いとちり先生の一連の記事を見た時、私がどれほど嬉しかったか！ あまりに嬉しかった気持ちを残したく、この記事を書かせてもらいました。

記事の本題は以上なのですが、もし不正確な地図と正確な地図を同時一緒に同じシステム上で扱いたいと思われる方は、ぜひMaplatの採用を検討してみてください。 元々Strolyを作っていた人間が、正確な地図も扱えるようにしようと訴えて排除されて、その問題意識を持ったまま新たに作り上げたシステムなので、Maplatは最初から正確なデータも読み込んで一緒に扱える機能がついています。 ぜひ興味のある方は試してみてください。

『宇宙よりも遠い場所』の聖地巡礼マップも含む『ぷらっと館林』好評公開中です！

アニメ「宇宙より遠い場所（よりもい）」の聖地巡礼地図作成のために国土地理院に測量成果複製の承認申請出していて、1週間ほど前承認がおりました。 地図への承認文言の追加も完了して、Maplatのデモサイト・ぷらっと館林で公開しています。 もしかすると、アニメの聖地巡礼マップ作るために国土地理院に測量成果複製申請したの、私が初めてだったりするかもしれません。 館林市現地のよりもいを盛り上げようとされている、コテージレザーさん、瞬とぴいぷるさん、大島まんじゅう屋さんをはじめとするたくさんの方々のご協力で完成した地図なので、ぜひ館林現地巡礼で活用していただけると嬉しいです！

で、その巡礼地図を公開しているぷらっと館林ですが、なかなか魅力的な配布用チラシなども完成し、先日館林を再訪問させていただいた際に、いくつかの巡礼拠点にチラシの設置をお願いしてもらってきました。

チラシのダウンロード (A5x2)

先に書いた地図作りに協力いただいた3箇所の他、らーめん厨房 ぽれぽれさん、ラーメンカンさん、小野調髪所さん、まゆ玉うどん もり陣さん等に置かせてもらってます。 チラシを置かせてもらっただけでなく、コテージレザーさんや小野調髪所さんには、ブログで紹介記事まで書いていただきました！（コテージさんの記事、オノトコさんの記事） ありがとうございます！ おかげでそれ以降ぷらっと館林のアクセス数はうなぎのぼりです。

さて、肝心のぷらっと館林の中のコンテンツの方ですが、よりもいの巡礼マップだけでなく、国立国会図書館さんや館林市教育委員会さん、館林城の再建を目指す会さん等から特別な許諾をいただいた魅力的な古地図、絵地図が多く収録されていて、様々な切り口から館林の魅力を知ったり、様々な気付きを得たりする事ができるようになっています。 五宝寺さんのような著名寺院などは当然古地図でも場所が確認できますし、

また街角で偶然見つけた小さな観音堂が、その場所の古地図を見ると昔観音院という寺院があった事がわかり、関係があるのだろうかと思いを馳せたり、そういう気付きを体験することもできます。

機能的にも、PWA (Progressive Web Apps)と呼ばれるアプリ形式に対応しており、Android/iOS共々、ホーム画面にインストールできる仕組みになっていて、その状態だとスマホがオフラインになってもアプリが動作し続ける仕組みになっています。 ぜひ館林の魅力を楽しんでいただければ幸いです。

またそのほかの地域の方も、Maplat技術を使ったぷらっとシリーズには、他にも『ぷらっと奈良』『ぷらっと会津若松』『ぷらっといわき』等の各地のアプリが用意されていて、それぞれ魅力的な地図を取り揃えており、PWA対応などの機能にも同様に対応しています。 ぜひ、各地の魅力を楽しんでいただければ幸いです。 また、同種のアプリを自分の地域でも導入してみたいと言う方がおられましたら、rekishikokudo＠tilemap.jp (＠は半角に直してください)までお問い合わせください。

Strolyの数千件の地図収集アドバンテージをそこまで脅威に思わない理由

古絵地図プラットフォーム技術の普及で重要になるのは大きく2つの視点があげられます。

1. 技術の優劣
2. 収集した古絵地図コンテンツの量

このうち、1. に関しては、先の記事等で広範なStrolyとMaplatの比較をしつつ、個々の優劣はありつつも全般的にはMaplatの方が優れていることを記してきました。残る2. の視点では、私がMaplatで現時点で集めているコンテンツは100点未満であり、日次の増加数などから外形的に観察する限りおそらく3000〜5000点のコンテンツを集めていると思われるStrolyに劣ります。 が、この差について私はさほど脅威とは感じておらず、その理由について本記事で説明してみたいと思います。

そもそも数千件は大きな数ではない

世の中にいくつの古絵地図があるかの統計はありませんが、おそらく十万百万のオーダーだと思われます。 その中で数千件のリードはさして大きな数ではありません。 Googleがクロールで世界中のほぼ全てのWebページを何億と蓄積しているように、既に大半の世に存在するコンテンツをおさえられてしまっているならば後発が覆すのは容易ではありませんが、数千件レベルであれば、たとえばMaplatが（仮に）投資を受けて事業を開始したり、あるいはオープンソースとして多くの人に使ってもらえるようになったならば、十分に覆すことが可能です。 実際、Stroly社のコンテンツ蓄積サイトhttps://stroly.com/を見てみても、そちらの検索フォームで地名から地図を探せますが、「東京」や「大阪」といった大都市でこそ複数の地図がみつかるものの、地方都市の名前を入れるとほぼひとつも地図が見つかりません。 「数千件」というのはその程度の数という事であり、現時点での彼らの優位はその程度でしかありません。

Strolyの古地図の大半は著作権の切れた「オープンデータ」であり、誰でも使える

Stroly社が揃えている古地図データの大半は、著作権の切れた「オープンデータ」であり、彼らが独占的に使えるデータではありません。 私のMaplat技術での利用含め、誰でも再利用可能なデータです。 ですので囲い込み効果がありません。

絵地図は著作権があるものが多いですが、基本的に個別Strolyユーザが著作権者と一致しているケースが大半であり、個別ユーザが利用技術を乗り換えればそのまま利用権も移るようなものが大半なので、これも囲い込み効果は薄いです。

古絵地図と位置の対応付データの著作者／ライセンス規約があいまい

しかし、地図画像データだけでは古絵地図アプリは動きません。 Stroly / Maplatとも、動作させるためには古絵地図と位置の対応付データを作成する必要があります。 そのようなデータの利用権は囲い込み効果があるものといえますが、Stroly社が独自に作成したデータは間違いなくStroly社の著作物ですが、StrolyのユーザがStroly社のツールを使って作成したデータは、誰の著作物かという明確な規約を現在Stroly社は整備していません。 ですので、ツールはStroly社が提供していても、ユーザが作成したデータはユーザのもの、と判断されれば、ユーザが使用するツールをStrolyからMaplatに乗り換えた場合に、作成したデータをそのまま移動させることができる可能性があります。

もちろん、今後Stroly社が、Strolyのツールで作ったデータはStroly社が著作権を要する、あるいはStrolyでのみ利用できるものとする、といった規約を整備してくる可能性はありますが、元々オープンデータ界隈で支持を得てきた会社/ソリューションだけに、そのような規約変更にユーザが納得するかは疑問が残るところです。

不正確なStrolyのデータは正確なMaplatでは使えない事が多い

一番大きな脅威でない理由で、Maplatの技術的優位性とも繋がってくる問題です。 Strolyと比較してMaplatの方が双方向全単射変換を保証するなど、正確に位置情報を扱えるのですが、それを保証するためデータ作成時においても、正確さを担保するためにトポロジーエラーチェックなど多くの検証処理をMaplatツールでは実施しています。 その検証処理を経ていないStrolyツールで作成されたデータは、そもそも不正確すぎてMaplatでは使えない事が多いです。 正確に言うと、「使えない」のではなく「正確に扱おうとするとエラーが出てしまう＝Strolyと同程度の変換精度しか出せない」なので、動かないわけではないのですが…。 つまり、Strolyがデータを何千件、何万件先行して蓄積したとしても、その多くはMaplat的精度では要求に満たない、不正確な不良データが大半（悪く言えばゴミの山）になります。

以上のような理由により、何千件程度のStrolyのコンテンツ量優位は、さほどの脅威ではなく、もし後発で事業化したとしても、簡単に覆せるものであると言えます。

StrolyとMaplatの長短比較

StrolyとMaplatの長所短所比較を聞かれることが何度かあったので、その際に都度答えた内容をいくつか組み合わせて、記事として起こしてみました。

全体として、技術的な面と運用的な面での長短に分けて記載します。

技術的な面での比較

双方の長短がわかりそうな代表的な地図をセレクトしてみました。

Stroly:
https://m.stroly.com/a/i#1522409396

Maplat:
https://s.maplat.jp/r/naramap/

Stroly - 1つの画像に複数の地図が共存可能

まず、Strolyにアクセスしてみると、日本地図が見えますが、周辺に北海道や台湾、東京や大阪の拡大図などがメインの画面と区切られた地域に存在します。
そういった、メインの地図と区切られた地域に地図の中心を持っていって、地図を現代地図に切り替えると、ちゃんと台湾や大阪が表示されます。
別の言い方をすると、Strolyは一枚の画像の中に複数の地図が存在する場合、それぞれに対応できます。
残念ながら、Maplatは現状、まだこれには対応しておらず、 一枚の画像の中の単一の地図にしか対応できません*1。

Maplat - 古地図絵地図と現代地図をぴったり重ね合わせ、半透過重ね合わせも可能

これが技術的にStrolyのMaplatに勝っている部分ですが、逆にStrolyの欠点は、Stroly側で地図を切り替えてもらえばわかりますが、地図がぴったりとサイズ一致しないと思います。
絵地図と、現代地図と、双方が微妙に違うサイズに表示され、ぴったり重ならないはずです。
また地図の表示ズームだけでなく、朝鮮半島のあたりで切り替えてもらえばわかりますが、絵地図側の方角が少しズレているのも、切り替えても双方の傾きがズレたままで、ぴったり合わないと思います。
これは、StrolyのWeb版は今表示している範囲の中心点で位置が合うだけで、地図全体でズームをぴったり合わせたり、方角をぴったり合わせたりする機能がない事が原因です。
それに対し、Maplatの方は、地図を切り替えてもらえばわかりますが、中心点だけでなく、地図のスケールや方角も比較的ぴったり合わせて地図を切り替える事ができます。
都度ぴったり合わせるよう計算しているので、リアルタイムに背景画像として現代地図を表示することもできますし、古地図側を透過表示して重なり具合を確かめる事も出来ます。
これによって、実際に古地図や絵地図と切り替えた現代地図が、本当に同じ場所を表している地図である、ということが視覚的直感的にわかりやすいというのがMaplatの長所です。

Maplat - 地図間の座標変換で1対1変換、必ず元の場所に戻ってくる

また、ちょっとわかりにくいMaplatの利点なのですが、Maplatは絵地図と現代地図（或いは絵地図と絵地図間でも可能）で座標を変換する際、ある地点を変換して、もう一度逆変換した際、絶対に元の場所に戻ってくるよう設計されています*2。

jsfiddle.net

こちらのサイトを見てみてください。
右下に地図とその上にメッシュが出てくると思いますが、StrolyとMaplatで同じデータを使って、絵地図の上の格子状の点を経緯度に変換し、その経緯度をさらに絵地図上の座標に逆変換した結果を描画しています。
深紅がMaplatの結果で、黄色がStrolyの結果です。
双方向きちんと元の場所に戻ってくるように変換されていれば、ちゃんと格子になるはずなのですが、Strolyの方は特に右下付近などでぐちゃぐちゃに変換されているのに対し、Maplat側は綺麗に格子に戻っています。

技術的な優劣はこんな感じですが、この辺の内容はだいたいこちらのプレゼンにまとめてあります（ただしMaplatの方が優れている部分の視点のみ）。

Maplat - 双方向非線形全単射変換を保証する古地図アプリケーション from 恒平 大塚

www.slideshare.net

運用的な面での比較

Stroly - 手軽に始めて手軽に配信、オールインワンのウェブエディタ

運用的な面でのStrolyの優位性は、何と言っても手軽さにあるでしょう。 企業が十分に労力をかけて整備しているサービスですから、Twitterアカウントなどでログインすればすぐに使い始められて、チュートリアル等も豊富、編集が終わればデータはすぐ地図をサービス提供できる手軽さは、一人の開発でドキュメントの整備なども手が回らないMaplatでは全く太刀打ちできません。
Maplatで地図を提供しようと思うと、ドキュメントも不十分なエディタを使ってデータを作成し、一部エディタがまだ対応しきれていない部分は手作業でデータを作り、それをサーバ等に適切に配置して、初めて提供できるようになります。
手軽さの度合いは比べるべくもありません。

Maplat - オープンソースライブラリ故の自由度、カスタマイズもオフライン環境でも自由自在

が、Strolyはサービスです。
サービスであること、またその手軽さとの引き換えとして、使い方の自由度がありません。
決まった地図UIでしか地図を提供できませんし、もちろんカスタマイズは可能ですが、そのためにはStroly社と契約して、カスタマイズ費用を払い、特別に専用UIを開発してもらうしかありません。

それと比べて、Maplatはライブラリです。
自由度はStrolyと比べ物になりません。
普通にデフォルトの設定で使って標準のUIを出すこともできますが、UI表示をオフにして、メソッドとイベント経由で動作を制御して、完全にオリジナルなUIで動作するようにすることもできます。
地図だけのページではなく、普通のHTMLページの中の一部分にだけ表示するようにもできます。
表示の自由度だけでなく、配信の方法も、Stroly社のサーバからサービスとしてオンラインでしか配信できないStrolyと違い、Maplatはライブラリなので配信に必要な材料さえ揃っていればどこの会社のサーバからでも、完全オフラインな環境（例えばネットワークの繋がっていない街頭のデジタルサイネージなど）からですら地図コンテンツを配信できます。
ドキュメントなどが揃ってない分ハードルは高いですが、理解して使っていただければ自由度はStrolyとは比べ物になりません。
しかも、オープンソースなので、どんなにカスタマイズしても利用は無料です*3。

Maplat - オリジナルモバイルアプリの開発の中にもライブラリとして組み込み可能

またモバイル対応も、StrolyはiOSとAndroidに対応していますが、Stroly社独自のアプリとしての実装しかありません。
カスタマイズで機能をつけようと思うとStroly社に開発を依頼する必要があり、地図表示機能だけを提供して、あとは別の会社が自由に機能を開発できるようなモバイルライブラリの提供はありません。
が、Maplatは、モバイルで自由なアプリを開発していただけるライブラリの形で提供しています*4。
なので、Maplatの機能を一部として埋め込んだ、独自のアプリを自由に作っていただけます。

以上が、運用面でのStrolyとMaplatの比較です。

結論：長短を把握して、用途によって使い分け

以上がStrolyとMaplatを比較した、長短の提示になります。
私はMaplatの開発者ですので、当然Maplatの利用が伸びればいいと思っていますが、やはり現状一長一短があり用途によって向いている向いていないがありますので、この記事を参考に向いているソリューションを選んでいただければと思います。
Maplatを利用されるにあたり不明な点などあれば、ぜひrekishikokudo@tilemap.jpにご連絡いただくか、Maplatレポジトリのissueページなどで質問してみてください。

*1:技術的には対応可能です。もともとStrolyの複数地図対応仕様を考えたのは私ですので。ただ、開発が追いついておらず、また結構な量の開発工数がかかるので、すぐに対応するのはほぼ不可能です。

*2:Maplatはこの実現手法で特許出願中です。特願2017-218223

*3:もちろん、私にヘルプを要求される場合は実働に応じて人件費は請求いたしますが...ライセンス費用的なものは不要です

*4:正確には、Androidはモバイルライブラリ化が完成していますが、iOSは7月末完成予定です

1月22日の大雪パニックは「日本的危機管理のなさ」のせいじゃなくて「合成の誤謬」のせいだと思う

昨日、薬が切れたためどうしても医者に行く必要があり、新横浜=>目黒=>町田と帰ったせいで、東急線とJR横浜線だけだが15時ごろの電車運行状況と18時ごろの状況、20時ごろの状況を全部見た立場から語ると、
昨日の大混乱って多くの人が八甲田山なんかを例に挙げて日本的危機管理のなってなさの表れのように語るけど、皆が共通の指揮系統で動いてるわけでもない群衆の危機管理をそんな見方したって何も役に立たないわけで、私はそうじゃなくて合成の誤謬の結果だと思う。

だって、19時半～20時頃に乗ったら、運行こそ普通しか走ってないけれど、ちょっと混雑してる程度でしかなかったわけですよ。
危機管理できてなくて長時間働かせてたから大パニックが起こったんじゃなくて、みんなが「おい、早く帰れ」となったから合成の誤謬で大パニックが起こったわけで、普通にみんながそこそこ残業して帰る時間がバラけてたらスムーズに流れてたわけです（残業がいいことという意味じゃないよ）。
いや、定時で帰らせるからパニックになったんだ、もっと早く早退させてたらパニックにならなかったはずだ、という人もいるだろうけど、私15時台にも乗ってるから知ってるけど、その頃ですらもう相当混んでたわけで、これは早く帰してる会社が相当数あったからなわけだから、
もし全ての会社が昼過ぎとかに帰してたら、パニックが起こる時間が早まってるだけで別にパニックが起こらなかったわけじゃないはず。

私は15時台ですら相当混んでたの知ってた上で、医者に行った後18時台に帰ろうとしたら、どうにもこうにもホームで身じろぎもできないくらい人があふれてて、列に並んでても5台くらい電車を見逃さないと乗れない状況なの見て、
『別に普段の日に比べて出勤してる人の総数が増えてるわけないし、15時台にもあれだけの大人数が吐けてたのに今大混雑するという事は、普段ならバラける帰宅時間がこの時間に集中してるだけだから、30分～1時間も時間つぶしてこの混雑が吐けるの待ってれば空くはず』と思って、腹もすいてきたし飯食って時間つぶしてたら、案の定ホームに戻ると空き空きで、その後入構してきた最初の電車に余裕で乗れた。
だから、雪降ってきた早く帰れ、じゃなくて普段通りもっと自然に散ってたら、パニックにはならなかっただろうし、とはいえこんな非常時に共通の指揮系統にないバラバラの群衆がそんなうまく動くわけがないので、それで生じたパニック見て「日本的危機管理がどうだこうだ」言ってもしゃあないと思う。

Maplatディストリビュータ企業募集

会津若松版や奈良版など展開しています古地図アプリMaplatですが、オープンソースなので誰でも自分でデータ作って自分のサーバ上で公開できるものの、技術ある人やある程度勘のある人しか設定できないので、市井の方が公開したいと思ってもまだハードル高い状態です。
ですので、Maplat普及のためにも、導入したい方の相談に乗って代わりに設定導入作業する（もちろん商売として）、Maplatディストリビュータとでもいうべき立場になっていただける企業を募集しています。
ご興味あれば、rekishikokudo@tilemap.jpまでご連絡ください。

私が語らないと歴史に残らない「位置ゲー事件簿」その2:Willcomと京ぽん - ユーザからの熱愛を受けたキャリアと名機

その1より1年以上を経てしまったが、その2を書いてみたいと思う。

位置ゲー黎明期は同時にケータイWebサイト黎明期（は少し過ぎてたかも）でもあったが、開発者とユーザの間がとにかく近かった。
黎明期の位置ゲーはほぼほぼ企業ではなく個人が作っていた、というのも一つの理由ではあろう。
それゆえに、開発者が動作検証できる各キャリアの端末を全部揃えていないこともあったし、また揃えていても機種依存等で動作が同じキャリアで異なることもあった*1。
そうなると、勢い問題の発生している機種を持っているユーザの助けを借りないと、デバグすらできない事もあった。
プログラムを少し変えて、変えた事を当該機種を持つユーザにメールや電話で連絡して、動作の変化を教えてもらって、変化と仕様書を付き合わせながら起きている現象を想像して、また少し変えて...というようなボトルシップの組み立てのようなデバグを繰り返したりもした。
ゲームが少しおかしな動作をすればクレームの嵐というような今現在から振り返ると想像もつかないような、おおらかな時代だった...ひとつには、開発側だけでなく遊ぶ側も、自分たちがコンテンツを作っているという意識があったのだと思う。

また単にゲームのデバグだけでなく、ゲームの前提となる機能の利用方法のハックなども、開発側とユーザ側が一緒になって行ったりもした。
たとえば、auケータイでの位置情報は、アンテナ基地局の位置情報を取得する方法は公開されていたが、GPSで位置情報を取得する方法は長らくezwebでのコンテンツキャリア以外には公開されなかった。
それをハックして、htmlタグの記述方法と、種々のパラメータの意味を明らかにしたのは、我々黎明期の位置ゲー開発者とユーザとの連携の功績だ。
そんな仕様ハックを楽しんでいたユーザの中でも、特に熱かったのが、PHSである「Willcom(当時DDIポケット)」のユーザ達と、その愛した名機「京ぽん」である。

その1で書いた通り、日本の位置ゲーの走りのひとつである「アンテナ奪取」は、端末が返すアンテナの基地局位置情報を元に、それを奪い合うゲームだった。
ということは、当然のことながら位置情報が取れない機種/キャリアでは遊べないだけではなく、位置情報が取れてもそれがGPS位置情報などの正確な位置情報だと遊べない、「アンテナ位置情報でないと」ゲームが定義できないゲーム性だった。
当時そのようなアンテナ位置情報を取れたのは、へなさんが「アンテナ奪うのれす」を作った「J-Phone（現Softbank）」と、「au」しかなかった。
Willcomの位置情報は、端末がその時受信できている複数のアンテナとそのアンテナからの電波強度を元に、三角測量的な手法で推定した位置情報を返していた。
当然、Willcomは少しでも正確な位置を返すためによかれと思ってそうしていたのだが、その三角測量をしているがゆえに、Willcomでは「アンテナ奪取」は原理的に遊べないはずだったのである。
熱いWillcomユーザが、名機「京ぽん」をハックし倒すまでは。

Willcomユーザというのは、まあぶっちゃけ変わり者が多かった。
普通にほぼ同じ技術を使っている（CDMA oneとかPDCとかは置いておいて）ケータイの間で利用料金などで3社を乗り換えている一般ユーザと違い、明確に毛色の違う「PHS」を選んでいる彼らは、どこか普通と違っており、またこの技術のここが好きだからこれを選んだ、と明確な意志を持ちかつ技術に詳しい人が多かった。
実際、アンテナから得られる電波の強度を測定してロギングしたデータをデータベース化したり、そういった活動を楽しんでいるユーザが多かった。
そのWillcomユーザから熱狂的に愛されたのが、京セラから発売された「京ぽん」だった*2。

その京ぽんを使って、位置情報測位時の電波強度パラメータの測定等を遊んでいたWillcomユーザが、ある日気づいた。
普通に位置取得すれば、必ず複数箇所のアンテナの電波強度が返ってくるのに対し、ある手順で位置取得すれば、再現性を持って必ず1ヶ所の電波強度しか返ってこない（つまりは三角測量してないのでそのアンテナの位置が得られている）というファームウェアバグに。
その手順自体は、昔のことすぎて私もよく覚えていないが、確か1度httpリクエストを投げて、そのレスポンスが完了する前に、リクエストをキャンセルしてすぐに位置情報取得リクエストを投げるとか、そんな手順だったと思う。
そのやり方は変わったもの好きなWillcomユーザの間ですぐに広まって、すぐにWillcomユーザではなかったものの位置情報サイトや位置ゲーをやっていた私の耳にも届いた（というかそもそも私のサイトのユーザさんが見つけたのだったかもしれない。そこまでの細部は忘れた）。
その手順がシステム的に再現できれば、Willcomでもアンテナ奪取ができる！と思った私は、いろいろ実装してみて、もちろん私はWillcomユーザじゃないので京ぽんを持っているユーザさんにテストしてもらって、最終的にシステム的にも再現できる事を導くのに成功した（たしか、味ぽんは当時では珍しくクライアントサイドのでJavaScriptも使えたので、空のページを読み込んで、その上でJavaScriptで位置取得URLにリダイレクトする、といった手順だったように思う）。
その技術の確立で、晴れてWillcomでも、京ぽん限定だがアンテナ奪取を遊べるようになったのだった。

一度Willcom版アンテナ奪取が実現すると、弱小キャリアで元々ユーザが少ない上に、機種限定というハンデがあったにも関わらず、Willcom版はJ-phone版やau版に引けを取らない盛り上がりを見せた。
元々変わったものが好き、というユーザ特性があったし、自分たちで作り上げるコンテンツが好き、というところもうまくはまったのだと思う。
驚くのは、公開後しばらくして京ぽんのファームウェアアップデートがあり、そのファームウェアアップデートを施すと単独アンテナ位置を返すというバグが直ってしまい、アンテナ奪取が遊べなくなる、という情報が出回った時だ。
それを聞いた京ぽんアンテナ奪取ユーザ達は、ファームウェアアップデートをすれば様々な動作が改善されるにも関わらず、ファームウェアアップデートを施さず、その後何年も古いファームのままアンテナ奪取を遊び続けた。
すごい位置ゲー愛だと思う。

アンテナ奪取の元管理者という立場から、私がWillcomと京ぽんについて語れるのはここまでだが、Willcomと京ぽんコミュニティーからは、他にも多くの黎明期位置ゲーコンテンツが生まれている。
いまや日本を代表する企業に育っているコロプラも、その元になっているコロニーな生活はWillcomから生まれたコンテンツだし、同じく黎明期の位置ゲーである電波の杜のゲーム群も、Willcom起源。
位置ゲーではないけどKamoTOWNやGPSMANなどいろいろジオメディア界隈に影響を与えたコンテンツを作成した、ふぇちゅいんさんもWillcom起源。
今や残っていない企業ですが、あの頃のWillcomという会社とその名機京ぽん、そしてその熱いユーザ達は、日本の位置ゲーの歴史に大きな爪痕を残したと思える。

*1:私もできる限り4キャリア揃えていたが、やはり限界はあった。ちなみにその頃の後遺症か、いまだにiOSとAndroid両方持ってないと不安だし、もう触ることはないだろうとはいえWindowsフォンもあったりする。

*2:京ぽんの名称は、当時のWillcomのネット利用可能電話ブランドが「Air-H"（エアーエッジ）」であったため、Willcomの電話全体が「味ぽん」の略称で呼ばれていたことによる。「京セラ」が発売した「味ぽん」なので「京ぽん」。