2011年07月25日

地デジからラジオへの出力は、7000円くらいでできるんじゃないだろうか

まだ試していないので、できるかどうかは未確認だけどアイデアだけ。
というか、誰でも思いつくレベルの事だとは思うけど、誰も思いつかなかったらアレなので、一応共有。

視覚障害者ため息…地デジ音声、ラジオで聞けず

何か方法ないのかちょっと調べてみた。

 

単純に考えると、地デジチューナーとアナログテレビをつなげるI/Fに音声出力があれば、それをラジオのAUX INに繋げてやれば、地デジ放送でもラジオで音声だけ聞くことはできるはず。
というか、画像いらないのだからB-Cas不要のワンセグチューナーの方がいいのか?
地デジとワンセグの放送領域が同じなのかどうか、判らないので両方調べてみる。

まず、よく売られてる安い地デジチューナー。
安いっつっても6000-7000円するんだけれども。
例えばこんな感じの。

Uniden ユニデン 地上デジタルチューナー ブラック DTH11

これによると、アナログテレビとの取り合いはRCAオーディオケーブルらしい。
というか、当たり前なのかもしれんけどAV周りはあまり詳しくないので一応確認。

同様にワンセグチューナーも見てみる。

KAMOS(カモス) フィルムアンテナ式 ワンセグチューナー

車載型だけど電源変換は何とでもなるだろう。
やはり出力はRCAオーディオケーブル。

 

なら、RCAと3.5mmプラグの変換さえかましてやれば(この手の)、地デジorワンセグチューナーの出力をラジオで聞く事も可能だろう。
7000円という出費は決して小さくないし、本来単一機器で動いた方がいいのは確かだけど、とりあえずの逃げとしてはあり得るのではないか。

 

しかしそれにしても、この件以外にも、地デジって本当穴だらけだよね…。
データ放送とかいうけれど、ああいう事するんだったら、災害速報なんかでもよく問題になる、テロップとかL字放送とかこそデータ領域で流して、緊急性の高いデータが受信された時は表示モードを強制的にデータ放送をスーパーインポーズする代わりに、コンテンツ領域にはゴミを流さない(DVDへの記録などには、テロップデータが流れないようにする)ような仕組みを作ればいいのに。
そしたらDVD記録でのテロップテロなんかの問題もなくなるのに。
CPRMでコンテンツ流通制御とか考える前に、そのコンテンツの質を高めるための仕組みをまず考えろよ。

災害速報の2秒遅れもひどいよね。
あれも、そういう用途のための非暗号化パケット作っておけば、問題なかっただろうに。
災害速報用途なんかで、今後FMラジオが見直されたりするんじゃないかな。
実際、インターネットにつながってないクローズドネットワークでのネットワーク内NTSの時間合わせ用途なんかで、電波時計による時刻合わせ機器と並んで、FM放送の時報を捉えて時刻合わせするような機器もよく売られてるんだわ。
同じような形で、FM放送での緊急地震速報の音を拾って地震速報をテロップインするような地デジ対応テレビも、そのうち出るんじゃないかな。

2011年07月25日

さよなら初代ケータイ国盗り合戦プラットフォーム&オープンソースにできないですかねマピオンさん

Posted by nene2001 at 12:25 / Tag: 位置ゲー Perl 国盗り / / 0 TrackBack / Google Maps このエントリーを含むはてなブックマーク

7月3日-6日にかけての長期間、ケータイ国盗り合戦がメンテナンス後、リニューアルされました。
見た目はあまり変わっていませんが、バックエンドのプラットフォームは言語はPerlからPHPへ(Perlは技術者確保が大変なため、との事。JPAやYAPCに支援とかすればよかったと思うんですが)、ストレージはTokyoTyrant等種々混在からMySQL一本へ(個々の局面での小さなパフォーマンス差より、一元化によるメンテナンスコスト削減)、インフラは社内インフラからAmazonAWS(移行理由等はこちらの資料で紹介)へと、大幅な変化をしたようです。
私が退職した1年半前頃からリニューアル準備に入り、 半年ほど前からクイズ、城下町等いくつかのコンテンツから先行移行していたようですが、ついにこの7月頭に完全移行し、私の遺産だった旧プラットフォームは払拭され、新プラットフォームに完全移行したようです。
(この辺の情報は、特定の個人から教えてもらったものではなく、局面局面でちらっと教えてもらったもの+Amazon事例のように発表資料等+一部機能だけドメイン名が変わった、のように外形仕様の変化から判る事、を総合して、こちらで再構成したものです)

新プラットフォーム開発に尽力された人々、お疲れ様でした。
同時に、役目を終えた旧プラットフォームにも、お疲れ様でした、と言いたい。
2007年10月に企画が始まってから設計始めて、半年後の翌2008年4月にはサービスインしていたプラットフォーム、設計は私だけ、実装は私と協力いただいた開発者(チートレベルの技術者ですが)一人の二人、私は企画やデータ整備なども並行してやっていたので、まさに突貫工事というのがふさわしい開発でした。
おまけに位置情報詐称対策からキャリア別絵文字共通化と独自絵文字変換テーブル、CSS対応、キャリア別コンテンツ自動出し分け機構等、それまでのマピオン社内には存在しなかったさまざまな外部ノウハウ、或いは個人ノウハウまでつぎ込んだ代物だったので、カタログスペックはよくとも、それこそ喩えて言うならば中国版新幹線のようになっても全くおかしくはなかったような物でした。
一応いろいろな意味での将来性は考えていましたし、また途中何度もリファクタリングは入ったとはいえ、まさかスタート時の8万人の10倍以上、90万人に使ってもらえるところまで持つとは思っていませんでした(一応、開発時のユーザ数目標は100万人というのが掲げられていたのですが、私自身経験した事のない数字でしたので、ほぼそれに近いところまで利用実績が出せたのは、単純にうれしく思います)。
本当にお疲れ様でした。

 

と思うと同時に、単純にこのまま国盗りの初代プラットフォームを、お蔵入りさせるのも勿体ないなー、とも感じています。
すでにマピオン社内でdeprecated扱いになっているプラットフォームであるなら、公開してオープンソースにしてくれないかなー、と思います。
位置ゲーに必要な位置詐称対策だけでなく、ケータイアプリに必要な絵文字変換やキャリア別出し分け(含むiPhone。Androidは、退社後にアプリで対応なのでネイティブへの対応状況は未確認ですが、オープンソースになれば対応させます)、その他のモバイルに必要な機能への対応も一通りできるようになっており、90万人のサイトで稼働していた実績があるので、ちょっとしたサイトが各キャリア対応モバイルサイトを作るのであれば、それが位置ゲーでなくてもコスト削減につなげられると思います。

残念ながらマピオン社内では国盗りにしか使われなかったプラットフォームですが、主要機能はApacheモジュールとして組んである(リンク先の記事のPSGI化は結局行われなかった)ので、バックエンドの開発言語がPerlでなくても、一応使えるようになっているはずです(実績がないので、実際に使われるといろいろ手直しがいるかもしれませんが)。
マピオン内で他プロダクトに使われなかった理由は、「重すぎると思われた」ためだと思っており、社内にその印象を持たれた原因としては、2008年4月の国盗りのサービスイン初日に、アクセス集中でサーバダウンを引き起こした事が原因と思っているのですが、そのサーバダウンの原因追及は結局うやむやになってしまったものの、個人的には原因はこれだと思っています(当時は私もよく理解していなかったので、MaxClients500とかでサーバ投入していた)。

実際、その後原因追及うやむやになった=サービスイン時の事象について根本対策していないにも関わらず、その後90万人を収容するまで微修正で乗り切れたという実績が、もちろん最適ではないにしても(突貫工事で作ったので、ムリムダムラはいくらでもあるのは否定しない)、十分実用に耐える事は証明できていると思っています。
むしろ、オープンソース化する事で、そういうムリムダムラをもっと優秀な人に最適化してもらえれば、という思いもあるので、ムリムダムラのあるコードを出すのは恥ずかしいという思いはありつつも、やはりオープンソース化してくれればなあ、と感じています。

後は、退社後の国盗りの進化方向で残念だった部分を、個人的に追及してみたいので、その基盤にもさせてもらえたら、とも思います。
例えば、国盗りはAndroid版でキャリア毎の絵文字互換を切り捨て(Android版から絵文字は入力できない)したようなのですが、これは私から見ると非常に残念で、絵文字は日本のケータイサイトの生んだ文化の一つだと思っていますし、だからこそ絵文字を使ってユーザが自由にコミュニケーションを採れるように、単に技術的に変換できる機構を作るだけでなく独自の変換テーブルを作ってまで、全キャリア、iPhoneを含め自然な絵文字双方向コミュニケーションを採れる基盤を提供する事に血道をあげて来ました。
なので、Android版国盗りで絵文字が切り捨てられてしまったのは、個人的には非常に残念に思います…特に、Android版国盗りの提供後、私が個人的に全キャリアのAndroid端末を操作してみたところ、厳密な調査はしていないので絶対とは言い切れませんが、各キャリアともAndroidで絵文字を使えるようにする基盤は整っているっぽいだけに、余計に。
その辺を、オープンソース化された暁には、追及してみたいと思います。

 

3月8日に横浜であった、経済産業省主催の「G空間プロジェクト報告会」で、マピオンの国盗り担当取締役であるところの浜矢さんが、位置ゲーでの位置詐称ノウハウをオープンにする事について問題提起をされたそうです。
私個人は、位置詐称対策ノウハウとはどういうものかという現場を知っているだけに、必ずしもオープンにする事がよいとは思っていません。
みんなで鍵のありかを共有しよう!等と言ってしまうと、泥棒にも鍵のありかが判ってしまうので無意味になってしまう、というようなところもあるので。
オープンにするのではなく、ノウハウとしてはブラックボックスのまま他社にも利用させる事も十分可能であり、そしてそういう基盤はすでにコロプラ社さんがコロプラ+プラットフォームというものを作られているので、そちらのアプローチの方がよいと個人的には思っております。
が、ノウハウも含めて共有する事に価値を見出すのであれば、まず隗より始めよと言いますから、問題提起されたマピオンさんから、まずプラットフォームのソースコードをオープンソース化して、共有されてはいかがでしょうか。
まさに今回お役御免になった国盗り旧プラットフォームには、そのような位置詐称対策のノウハウが全て入っていますから、それを公開する事には大きな価値があると考えております。

取締役としての、有言実行、英断を期待したいところです。

2011年06月05日

Androidの自由と帝国性について

Posted by nene2001 at 18:25 / Tag: iPhone Android / / 0 TrackBack / Google Maps このエントリーを含むはてなブックマーク

同僚のツイート。

Androidは開発者を自由にするか、それとも多様なデバイスとバージョニングの奴隷にするか。理論的には自由、実践的には不自由。

Androidの自由はよく語られるし私も何度か採り上げたりするけど、開発者視点のそれってそれほど語られてるかなあと感じた。
AppMarketでの胴元の取り分とか、審査の恣意性とかの視点で若干語られてるかもしれないけど、あまり印象にない。
というより、私はiOSの開発しか経験したことなくてAndroidの開発は経験したことないので、iOSの開発の不自由さはいくらでも語れるけど、Androidの開発が自由か不自由か、と言われれば「よく分からん」としか言えないな。

個人的な印象だけど、Androidの自由が語られる文脈って、Android rulesの下での開発者が自由かどうか、とかの視点じゃなくて、社会そのものの中でのAndroidの位置付け、役割が自由、という事じゃないかと思うんだけど、違ってるかな。
少なくとも私は、その文脈で捉えていろいろ考えてる。

自由な発想での多様なデバイスの基盤になれるAndroid

例えば、最近話題になった、ジョブスの講演(ジョブス氏が言う、つまらないものは捨てろの意味)。
もっとも商売的にマスになる部分にだけ注力するという事であり商売的には全く正しいのだけど、逆にそこで捨てられた部分こそ大切な立場の者にとっては、この先iOSの恩恵を受けることはなくなってしまうという事も意味する(ニーズに気付いてないから対応してないのではなく、意図的に捨てているのだから)。
もちろん、マルチタスクにしろフォルダ構成にしろ、最初はいらないと捨てたものが後から付けられるケースもあるので、絶対にないとは言い切れないのだけど、少なくともiOSでは主体的に行動することはできなく、自分たちのニーズも考慮してもらえた、という福音を待つ事しかできない。

iPhone/iPadが出たばかりの頃、これは子供や老人にも使いやすいデバイスだね、とかの話が出てて、それは全く事実なのだけど、だけどデジタルディバイド解消するにはまだ、PCがないとアクティベートやアップデートができないとか、無線LANの接続を簡易化するとか、ほんのラストワンマイルが必要だね、という話もした事がある。
が、そのほんのわずかなラストワンマイルを、iOSが乗り越える方向に進むとはあまり期待できない…ジョブスは、そういう方向性を狙う製品としてiPhone/iPadをデザインをしてるわけではないと思うし、である以上、切り捨ててくるからだ。
なので、iPhone/iPadに感銘を受け、これをあと一歩進めれば理想のデジタルディバイド解消デバイスが作れる、と志をもった起業家がいたとしても、その実現プラットフォームとしてiOSを選ぶことはできず、そのようなデバイスの実現プラットフォームとして選び得る現実的な選択肢というと、Androidしかない[*1] 。
この、(ジョブス以外の誰かが)何か新しいイノベーションを呼ぶデバイスを、と思った際に、その基盤として選択できるという点が、Androidの自由の真骨頂じゃないかと個人的には考えてる。

ケータイデバイスだけでなく、社会基盤にまで食い込みうるAndroid

こういう写真が話題を呼んだ事があって、まさか自販機の中身がWindowsだったとは、と驚きの声が上がっていたけど、この手の業界にいた事もある個人的にはむしろ普通Windowsだろ、と思ってた[*2]。
自販機/券売機/ATMといった端末系装置のGUIにしろ、工場の生産装置(たとえばこんな感じの奴のね)のタッチパネルにしろ、装置系でグラフィカルな表示を行いタッチパネルで操作する、といった部分には、思っている以上にWindowsが食い込んでる、むしろWindowsが主流だろう。
理由はよく判らないけど多分、『中身大した事してるわけではないけど、単に綺麗なグラフィックユーザインタフェースを見せて、GUIも処理できて操作に合わせて信号さえ出せればそれでいい、技術者もスキルは大した事なくていいから数集めて確保できる』ようなプラットフォームが、実質Windowsしか存在しないからだろうと思う。
Linux系の技術者とか、数いてもほとんどがGUI系の経験も少ない、単価の高いWeb系の技術者だと思うし。

でも、そのように選択肢がなかったから必然的に選択したWindowsだけど、一つ一つにかかるライセンス費用は、製品単価が高くなくコストダウン要請の大きいこの手の業界では、必ずしもベストの選択肢とは思われていなかっただろうと思う。
たかだかユーザにタッチパネルボタンを押させて信号ON/OFFするだけの事に、何でWindowsみたいな図体のでかいもん載せて高いライセンス料払って、という自問は、その手のに関わってた私自身思ってた事がある(もちろん実際には、重くオーバースペックでもそれをベースに開発した方が、1から作るより遥かに安いので、意味のない問いなのだけど)。
しかし今なら、『綺麗なグラフィカルなGUIがそこそこ表示できて、タッチパネルでのユーザイベントも取れて、技術者もそこそこ数確保できる、その上ライセンス料不要のプラットフォーム』があるんじゃないか?

そう、Android。
私が昔いたような装置系製造業者の、経営陣レベルがこれに気付いたら、その手の装置の表示/タッチパネル制御は、どんどんWindowsからAndroidに代わっていくんじゃないかと思ってる。
実際そのように動き始めている例多数(以下では上に述べたようなGUI系だけでなく、組み込み系も一緒に事例として挙げているが、要するにAndroidはケータイのOSでiOSと対比する、だけではすまない事の例なので、一緒に挙げます)。

ケータイOSとしての機能が、iOSがどうAndroidがどう、という狭い視点で話している間に、全然知らないところで、AndroidはWindowsを駆逐して、目に見えにくい縁の下の力持ち的なところで、社会全体を支える基盤になっている可能性がある、という事。
それを受け入れうる可能性が、Androidの自由というものではないかと。

技術者が食いつなげるエコシステムへ

そうなってくると、かつてWindowsがそうだったように、技術者がもし失敗しても、別の分野で食いつなげるようなエコシステムができるようになる。
ケータイ電話のアプリなんて、iPhone AppStoreとAndroidマーケットの間にはいまだに越えようのないくらい大きな差があるのは事実だけど、そのiPhoneの方ですら、アプリでホームランを打ってウハウハ、なんてのは相当確率の低い夢物語、というのは薄々判って来始めている。
となると、ギャンブル打ってアプリにかけるのはいいとして、失敗した後の事も割とリアルに考えるべきという事になるのだが、その場合、iOS/Objective-Cでの開発経験は、そのままでは別の業界で活かす事ができない。
プログラマなら環境や使用言語が変わっても…みたいな精神論根性論はおいておくと、実際のところ企業も自社で使っているプラットフォームでの開発経験でフィルタして求人をかけるところがほとんどだし、という事は、iOSでの開発というのは、失敗も織り込んだ上でのリスクとしてはかなり大きくなってくる。

しかし、Androidがこの先社会基盤分野での浸透を深めると、ケータイアプリでギャンブルかけて失敗しても、そういったインフラ業界での開発従事で食いつなぎ、気が向けばまた再起を図る、といったこともできるようになる。
企業側でも、泥臭いインフラ分野の開発であっても、用いるプラットフォームとしては花形のケータイOSを使っている、技術を学べると喧伝する事で、若くて優秀な人材を確保しやすくなる。
企業側、開発者側、双方の利点で、Android技術者が食いつなげられる/生き続けられるエコシステムが成立し始める。
エコシステムが発生すると、当然そこに集まる人の数は多くなるし、人が多くなると才能の層も厚くなり、裾野も広くなる。
残念ながらiOSでは、Appleが今の戦略を採っている限り、絶対にそうはならない(OS自体の優劣ではなく、社会の中で採っている戦略の違いによるものなので、Appleが戦略を変えてくればまた別の話になるが)。
そのような背景が整えば、ケータイアプリの分野でも、AndroidがiOSを上回る可能性もあるのではないかな、と思っている。

Androidは帝国的、iOSは単民族国家的

1週間ほど前に思いついてTwitterでつぶやいて以来、気に入って使ってるんだけど、Microsoft/Windowsにしても、それを置き換えようとしてるAndroid/Googleにしても、良くも悪くも『帝国的』なんだよね。
帝国というと悪いイメージを持ってしまうけれども、広大な版図、数多くの民族や宗教、多様な価値観を束ねて一つにするにはそれなりの技術や哲学、精神が必要で、異なる価値観への寛容や費用対効果の悪くともニーズがある分野への注力等、必ずしも価値観を一つにしない存在をも束ねていく責任と覚悟、気概が必要なんだよね。
MicrosoftやGoogleには、意識してるかしてないかは別としてそのようなものを感じる事ができた。
一方でApple、iOSにはそれを感じなくて、ジョブス自身が「つまらないものは捨てる」と言ってる通り、すごく純化された一部(とはいえそれが的確にマスを掴んでいるところが、ジョブス/Appleの鬼才だろうとは思うのだけれど)にとっては統一されてて気持ちよい、熱狂的に受け入れられるのだけど、その純化された状況を受け入れたくない、或いはそもそも構造的に受け入れられない一部にとっては、酷くストレスを感じさせる存在なんだと思う。
帝国との比喩でいうなら、単民族国家的というかね。
その民族の祭祀を受け入れ、民族神話のイニシエーションを受け入れた人にとっては心地よい統治、その元で最大限の自由を感じるのだろうけど、受け入れられない人にとっては最悪の、不自由の極みと言っていい統治と言っていいと思う。

で、Appleに対してなんだかなあと思うのは、だいたい、あのくらいの規模で世界に影響を与える会社になれば、世界の価値観は多様でニーズも多様なのだから、なんだかんだで帝国的な統治方法も身に付けるもんだと思うのだけど、Appleに関してはあんなに大きくなってもいつまでも単一民族国家的なところ。
その辺が将来、Appleの弱点にもなるんじゃないかと思ったり。
単一民族国家的な熱狂は、優秀な祭祀王が強力なイニシエーションで引っ張っていく限り、多様なニーズに応えなくとも自分たちでニーズを作っていく限りは、持続的に発展する事もできるだろう。
でも、祭祀王が失われ、中心となるカリスマ性が失われて、内部から生み出されるニーズに人々をひきつける魅力がなくなったら?
もし、カリスマの力でひきつけるシステムが失われたら、広大な版図を統治ずるための、多様なニーズに応えて帝国的に統治するシステムができていない分、瓦解も早いような気もする。

 

まあ、単なる妄想なんですが。

 

*1: 実際、IS03に入ってたAndroid2.1では、無線LAN接続を簡単にするためのAOSS連携機能がついていた。Androidの標準でついたのか、SHARPがAOSS対応を作りこんできたのか知らないが、こういう事ができるのがAndroid。
*2: ただし、グラフィカルな表示やタッチパネル制御などのみ。実際の機器全体の制御などはマイコンが行っているものが多いと思われる。

2011年02月22日

Google Analytics SDK for iOSでUserAgentの変更

プロジェクトで、iPhone/iPadアプリでページ遷移ロギングできる方法が何かないかと探していたところ、同僚がGoogle Analytics SDK for iOSというのを見つけてくれた。
アプリ上のページ毎にURLを与えてやって表示されるごとにメソッドを叩いてやれば、WebページでのGoogle Analyticsと同様に遷移情報を分析/管理できる。
これは便利。

ただ、気にいらない点が一つだけ。
アクセスに使われるUserAgentが変更できなくて、「GoogleAnalytics/1.0」固定なのね。
これが自由に変えれたら、同じページでも有料版と無料版、iPhone版とiPad版といった感じで違うアプリが存在する場合に、UserAgentでどの版からのアクセスか見分けたり、またUserAgent中のバージョン番号で、アップデートされたアプリの拡散状況を把握したり、といった事にも使えそうなのに、変えられないばかりにそれらの事を調べるには他の手を打たないといけない。

これが変えられると変えられないでは使い勝手があまりにも違うので、何とかして変更する方法がないか試してみました。
GA SDK for iOSはソースコードではなくバイナリで配布されているので、オープンソースのように中身書き換えるというわけにはいかなかったのですが、iOS SDK Hacksに載っていたMethod Swizzlingというテクニックを使って、UserAgentを変更できるようにしてみました。

iOS SDK Hacks ―プロが教えるiPhoneアプリ開発テクニック
吉田 悠一 高山 征大 UICoderz
オライリージャパン
売り上げランキング: 12376

コードは記事末尾に引用します。
使い方は、

#import "UAGANTracker.h"

UAGANTracker* uaGan = (UAGANTracker*)[UAGANTracker sharedTracker];
[uaGan setUserAgent:@"YourApp"];
[uaGan setVersion:@"1.2.3"];

みたいな感じで、後はオブジェクトの呼び出しだけ

UAGANTracker* uaGan = (UAGANTracker*)[UAGANTracker sharedTracker];

で行えば、普通のGoogle Analytics SDK for iOSの使い方と一緒です。
また、setUserAgent、setVersionは省略でき、省略した場合、前者はCFBundleIdentifierで設定された値の最後の部分、後者はCFBundleVersionで設定された値が使われます。

誰かのお役に立てばうれしいです。

UAGANTracker.h
//
//  UAGANTracker.h
//
//  Created by 大塚 恒平 on 11/02/22.
//

#import <Foundation/Foundation.h>
#import "GANTracker.h"

@interface UAGANTracker : GANTracker
{
    NSString* userAgent;
    NSString* version;
    NSString* fullUA;
    NSRegularExpression* regexp;
}

@property(nonatomic,retain) NSString* userAgent;
@property(nonatomic,retain) NSString* version;
@property(nonatomic,readonly) NSString* fullUA;

-(NSString*)changeUserAgent:(const char *)arg1;

@end


@protocol GANTCPSocketDelegate <NSObject>
- (void)socketConnectDidSucceed:(id)arg1;
- (void)socketConnectDidFail:(id)arg1 withError:(id)arg2;
- (void)socketBecameReadable:(id)arg1;
@end

@interface GANTCPSocket : NSObject
{
    id <GANTCPSocketDelegate> delegate_;
    struct __CFReadStream *readStream_;
    struct __CFWriteStream *writeStream_;
}

- (id)initWithDelegate:(id)arg1;
- (void)connect:(id)arg1 port:(int)arg2;
- (int)read:(char *)arg1 length:(int)arg2;
- (int)send:(const char *)arg1 length:(int)arg2;
- (void)close;
- (void)dealloc;
@property(nonatomic,assign) id <GANTCPSocketDelegate> delegate;

@end

@interface GANTCPSocket (origMethod)

- (int)mySend:(const char *)arg1 length:(int)arg2;

@end
UAGANTracker.m
//
//  UAGANTracker.m
//
//  Created by 大塚 恒平 on 11/02/22.
//

#import "UAGANTracker.h"
#import <objc/runtime.h>

static BOOL installed = NO;

@implementation UAGANTracker

-(id)init
{
    [super init];

    if (!installed) {
        installed = YES;
        Class klass = objc_getClass("GANTCPSocket");

        Method orgMethod = class_getInstanceMethod(klass, sel_registerName("send:length:"));
        Method myMethod  = class_getInstanceMethod(klass, sel_registerName("mySend:length:"));
        method_exchangeImplementations(orgMethod, myMethod);
    }

    return self;
}

-(void)setUserAgent:(NSString*)aUserAgent
{
    userAgent = [aUserAgent retain];
    fullUA    = nil;
}

-(void)setVersion:(NSString*)aVersion
{
    version   = [aVersion retain];
    fullUA    = nil;
}

-(NSString*)userAgent
{
    if (!userAgent) {
        userAgent = [[[NSBundle mainBundle] infoDictionary] objectForKey:@"CFBundleIdentifier"];
        NSRegularExpression *regexp_l =
         [NSRegularExpression regularExpressionWithPattern:@"^.+\\.([^\\.]+)$"
                                                   options:0
                                                     error:nil];
        userAgent = [[regexp_l stringByReplacingMatchesInString:userAgent
                                                        options:0
                                                          range:NSMakeRange(0, userAgent.length)
                                                   withTemplate:@"$1"] retain];
    }
    return userAgent;
}

-(NSString*)version
{
    if (!version) {
        version = [[[[NSBundle mainBundle] infoDictionary] objectForKey:@"CFBundleVersion"] retain];
    }
    return version;
}

-(NSString*)fullUA
{
    if (!fullUA) {
        fullUA = [[NSString stringWithFormat:@"%@/%@",[self userAgent],[self version],nil] retain];
    }
    return fullUA;
}

-(NSString*)changeUserAgent:(const char *)arg1
{
    NSString* string = [NSString stringWithUTF8String:arg1];

    if (!regexp) {
        NSString* regex = @"GoogleAnalytics/[\\.0-9]+";
        regexp = [[NSRegularExpression regularExpressionWithPattern:regex
                                                            options:0
                                                              error:nil] retain];
    }
    string = [regexp stringByReplacingMatchesInString:string
                                              options:0
                                                range:NSMakeRange(0, string.length)
                                         withTemplate:[self fullUA]];
    return string;
}

-(void)dealloc
{
    [userAgent release];
    [version   release];
    [fullUA    release];
    [regexp    release];

    [super dealloc];
}

@end

@implementation GANTCPSocket (origMethod)

- (int)mySend:(const char *)arg1 length:(int)arg2
{
    NSString* string = [(UAGANTracker*)[UAGANTracker sharedTracker] changeUserAgent:arg1];

    return [self mySend:[string UTF8String] length:[string length]];
}

@end

2011年02月11日

WiFi位置情報で位置詐称対策は本当にできないのか?についての思考実験

前々記事でWiFiで位置ゲーできないはずはない!と当初書いたんですが、@netartjpさんから可搬式のWiFi APが詐称に使われる可能性を指摘されました。
「WiFi設定オフでないと動かないのは可搬式WiFi対策かも」の追記はそれを受けて書いたんですが、これに関しては本当に、WiFiのPC接続混入や通信路脅威だけを考えてしまっていて、WiFiそのものが位置同定の手段になるという視点が抜け落ちてしまってました。
これは我ながらかなり恥ずかしい。
しばらく離れていて現場におらず、思考実験だけで書いているがゆえに、少し勘が鈍ったような気はします。
追記前に書いていたような内容は、Android版発売直後からTwitterで考えを垂れ流してたんですが、某所で今の中の技術陣から「見当違いのこと書いてんじゃねーよ」とDISられてしまってました。
その時は「なんだとー。撃つぞー。(としちゃん調で)」と思っちゃったんですが、今考えると実に恥ずかしいですね。

しかしまあそこでコケないのが私でして、前記事で書いたように『普通に考えて「できない」じゃなくて、「できる」ようにするために、何をするかを考え』るのが位置詐称対策なんですね。
もちろん、『何をするかを考え』た結果、WiFiオフ強制でもいいんですが、その辺はバランス感覚として、現時点でWiFiに繋がってるわけでもないのにWiFiオフを常に強制させるというのは、ユーザビリティとして非常に厳しいものがある。
個人的には受け入れたくないですね。
なので、WiFiオンでも位置詐称対策が何かできないか、考えてみました。

普通に考えると、これまでの『位置情報を受け入れる時点で、信頼度をクリーンナップし、その関門を受け入れたデータについては後から信用度を問わない』やり方だと、絶対に無理というのは判ります。
可搬式APから取る位置情報と、固定式APから取る位置情報には、それを見分けるフラグは一切ないのですから。
しかし、位置データに位置取得手段やその水際クリーンナップの信頼度等を付帯させて残し、データを取得時の一瞬で見るのだけでなく履歴として管理し、またこれまで特にユーザ情報を紐付けず一体として見てきた位置情報を、ユーザの履歴としてクラスタさせて統計的に見るような形にパラダイム変換してやれば、対処できないという事はおそらくないような気がするのです。

というか、『統計的に見る』という手段を導入する時点で、分散解析処理とかのシステムは大変になるのだけれども、それを導入する覚悟さえできれば、これまでの脅威と比べても、そこまで高くはない印象も受けます。
なぜかというと、これまでの脅威は、簡単に言うと、サーバにたとえばhttp://example.com/hoge?lat=35.0000&lng=135.0000のような情報を送られたとして、この部分をユーザに書き換えられる事によりどこにでも行けてしまう、それをどうやって防ぐか、という問題でした。
このデータ書き換えによる脆弱性は、放置しておくとユーザにどこにでも行かれてしまうんですね。
北海道、沖縄、韓国、アメリカ、極端な話北極、南極、どこにでも行った事にされてしまう。
そして、対策をしておかないと、それを受け入れた後で「この情報は嘘だ」と見分ける方法はないのです(いやもちろん、日本のケータイサービスから返ってくる位置情報で、外国や極域が返ってくると偽情報と判りますが、日本国内である限りは絶対に見分けられない)。

  • しかし、可搬式WiFi基地局による詐称は違います。
    ユーザが好きな場所を指定して位置ゲーシステムに詐称情報を送れるのではなく、飽くまで持っているAPに紐づいた位置情報しか送れないわけです。
  • APに紐づいた位置情報は、そう簡単にはユーザによって完全に自由に変更できるわけではなさそう(と、思う。これは飽くまで前提なので、SkyhookなんかAPの位置情報修正フォーム用意してるみたいだけど、あれがもし修正要求⇒内部での妥当性審査とかなく即修正、しかも同じAPに対して何度でも修正しまくり可能、とかだと話は変わってくる。が、その情報がないので、飽くまで仮定の前提として)。
  • 特定のAPによって与えられる位置情報は、普通に考えて大きく揺らぐことはないでしょう(一つの可搬APから得られる位置情報が、数?とか大きく揺らぐ事はなさそう。GeoHexレベル9で1ヘクス分、の誤差も出ないのではないでしょうか。極端な話、常に同じ経緯度が返ってくるならば、クリーニングも簡単ですね)。
  • 特定の可搬APは、特定の少数ユーザに圧倒的集中して取得されるでしょう(特にAndroidのようにMACアドレスが取れる環境だと、確実に特定のMACアドレスと特定のユーザの紐付けもできそう)。
  • 特定のユーザはそれほど多くのAPを持てるわけではないと思うし、また多く持っていたとしても、それ全てに嘘の位置情報を紐付け、それをさらに維持するのは、割と至難の業なのではないでしょうか。
  • 可搬式APを悪意をもって虚偽長距離移動申請に使おうとするユーザは、その前後の移動を必ずかなりの長距離にするでしょう(時間間隔関係なく。時間間隔が短いと、ロケットでもないと行けないような移動になってしまい明らかにバレバレなのですが、逆にそれでバレないようにと時間間隔を取っても、WiFi APだと特定の狙った位置情報を送る事の困難さから、現在地と可搬APの持つ位置情報との間を往復するだけの移動になるでしょう。徳島が現在地で東京の位置を送るAPを持っていたとしたら、詐称しているとひたすらその間を往復するだけの位置情報になる。徳島から東京まで、途中で静岡や京都で一度も位置をとらずに、何度も往復?一回だけなら怪しくないですが、何度もそれが続くと不自然ですよね。そういったあたりも解析ヒントになるのではないかと)。

そういったあたりを考えると、特定のユーザに対して、特定の場所や、Androidの場合APまで特定して得られた位置情報の場合、かなり信頼度が落ちる、というのを割り出すのは、可能な事ではないかと思います。
この記事を書いている間に、PlaceEngineの末吉さんからも情報をいただきましたが、

はい、移動AP問題について、時間的近傍でGPS情報をベースにフィルタすれば、ある程度無線LAN基地局の精度の妥当性を見極めることができます。あと基本的には、SSIDではなくMACアドレスですね。

という事なので、今位置取得処理はユーザが位置取得処理をした際にしかしてないと思うけど、怪しい位置情報を取得した前後ではユーザが処理しなくてもバックグラウンドで位置を採るような処理をしてやれば、こういったフィルタリングも容易になるのではないかと思います。
そして怪しい位置情報を送っているユーザに対しては、いきなり落とさなくても、警告文を出したりするだけでも、大分詐称をしようという悪意は減らせるのではないでしょうか。

 

もちろん、WiFi位置情報による以上位置懸念は可搬APによる問題だけでなくて、可搬APを持ち歩いているユーザのMACアドレスをたまたま拾った通りがかりのユーザがいれば、可搬APの所有者でなくても不可抗力で偽位置情報を送ってしまう事もありますし、また最初の@netartjpさんからの指摘で書かれていたように、『沖縄の人がヤフオクで北海道からWifiルーター買ったら距離ゲーは大儲け』みたいな話もあります。
ただ、今度は技術的な話ではなく総合的判断の話になるのですが、それってどの程度のリスクなの?と思います。
確かに沖縄の人が北海道のAPを落とせば位置ゲー大儲けでしょうが、それってどのくらい狙ってやれるの?もしできたとしても、Skyhookなんかも馬鹿じゃないからいずれは位置情報修正されるだろうし、そうでなくても位置ゲーの方も本記事で書いたような対策打ってれば、どの程度の間甘い汁が吸えるの?それは不要なAPをわざわざ探して買う事とコストパフォーマンス的に見合うの?あたりを考えると、そこまでの脅威ではない、という判断もあると思います。

 

いずれにせよ、ここに書いたような事はしょせん思考実験でしかなくて、実際にはもっと多種多様な攻撃法が考え得ると思うし、そしてどんな攻撃をしてくるかは、開放してみないと判らないところもあるんですよね。
何か対策方法を思いつくまで、WiFi接続を開放しないというのも手ではあるのですが、しかし多様な攻撃パターンの存在をつかむためにも、(もちろん攻撃パターンをつかむための布石は十分に打った上で)わざと解放するというのも手だと思うんですよ。
実際、ガラケーの位置詐称対策も、十年近くの歴史(最初アンテナ奪取とかできたの2002年頃なので、もうその位にはなるよね)の中、公開して攻撃されたから対策してを繰り返した結果、ここまでのものになった、というところはあるので。
これまでの水際防御パラダイムでなんとかできていた間は、ある程度定石もできてきていたのでなんとかなっていたわけですが、それが崩れようとしている今となっては、『まず攻撃させてみる』事なしには次の段階に進むことは不可能ではないかと思えます。
最近もコロプラの中の人にちょっとだけ反応してもらったのですが、さすがに今実際どういう事をやってるかは教えてもらえませんでしたが、ただ一言、『覚悟は決めた』という事は言っておられました。
これは、位置詐称対策に対して、パラダイム変換をしないと先はない、しかし先を見ようと思うと一時的に攻撃を受けまくりサンドバック状態になる事に対しての、『覚悟を決めた』発言だったのではないかと思ってます。

2011年02月09日

何度も言うけど、位置詐称対策「技術」なんて本来の意味の技術じゃなくて大道芸だよ

これ、何度も言ってるけど、位置詐称対策「技術」なんて本来の意味の技術じゃなくて大道芸です。
でも大道芸であるがゆえに、「技術」を「スポーツ」に例えるなら、スポーツならその競技に特化した身体能力だけ鍛えてればすむところを、「心理学」や「話術」も駆使しないといけないような、総合的な能力が要求されます。
身体的能力=物理的能力だけじゃ絶対に無理な、トリックを使って空中に浮いて見せる、みたいなのもこなさないといけないわけです。

先のエントリブクマコメントがつきましたが、

weboo 残念ながら無駄な努力と言わざるを得ない

そうなんですよね。
純粋な技術者視点だとそうとしか言いようがないんですよ。
私も、iPhone版をどうやって実現するか考えていて、JavaScriptの知識あまりなかったんで前社で一番のJavaScriptマスターに相談した時、即答で「無理だ」と言われましたもん。
JavaScriptでできる事を突き詰めたら、そりゃ「防げるわけはない」と答えるしかないわけです。
別にiPhone版でなくても、今までのガラケーでの位置詐称ノウハウだって、「純技術者的視点」から見れば穴はいっぱいありました。
でも、そこで「できるわけねーじゃん」で背を向けてしまってたら、今160万人が遊び、全国を巻き込んで数億円の経済効果を生み、ケータイキャリアとも手を組んだ位置ゲー業界の存在はないわけで。
普通に考えて「できない」じゃなくて、「できる」ようにするために、何をするかを考えないといけないんですよね。
で、3G接続に限定すればPCから詐称されるリスクは最小限にできるとか、iPhoneからの接続だけだと逆にAppStoreの審査を通過したアプリだけをほぼ想定すればいいから解析されるリスクはかなり抑えられるとか、JailBreakされればもう何も防ぎようがないけど、JailBreakするユーザってそうそういないよね、リスクはビジネス的に許容できる範囲だよねとか、そういう純粋技術以外の要素も考慮/加味しまくって、純粋技術的には防げないのは判り切った上でとにかくリスクを下げられるところまで下げて、その上でそのリスクを受け入れた範囲内で企画/ビジネスモデルを作るというところまで含めて、位置詐称対策ノウハウなわけです。
純粋に技術だけで済む話じゃなくて、企画やビジネススキームまで含めての総合的な話なのです。

そこでは、たとえばJailBreakの脅威は低いと最初見積もったけど、いざ公開してみたらJailBreakらしき挙動をするユーザが予想以上にいたとしたら、JailBreakに対しては無力だけど、せめてJailBreak -> FakeLocationを入れて偽位置情報垂れ流しているだけレベルのスクリプトキディ程度ならはじけるような施策を打ってリスクを下げるとか、或いはこれまでのアプローチではどうしてもリスクを一定以上に下げれないなら、思い切ってアプローチのパラダイム変換を行ってリスクの受け入れ方を変容させ、企画やビジネスモデルにも微修正をかけるとか、そういうやり方もあるわけです。
実際、今スマホの隆盛で、従来の不正位置情報を受け入れるリスクを水際でシャットアウトするやり方はかなり無理が出てきているので、(もちろん水際は限界まで絞った上でですけど)不正位置情報は結構入ってくる事実は受け入れたうえで、内部でデータを統計的に処理して後から怪しい挙動を検出するような、パラダイムの変換を今コロプラなんかはやっているように、外から見ていると感じます。

或いは、もう位置ゲーを一個人が趣味で運営してるような時代は終わって、先に書いたようにケータイキャリアとも対等に手を組めるような存在になった今なら、先の記事の追記で書いたような、「Androidは3G基地局とWiFi基地局を見分けられないから、WiFi可搬位置局による詐称対策ができない」みたいな話は、別の解決策アプローチだってあり得ます。
技術者コミュニティからのアプローチがいいのか、協業するケータイキャリアからのビジネス的アプローチがいいのか判りませんが、Androidの仕様策定に働きかけて、3G基地局とWiFi基地局を見分けられるような仕様を提案して採用してもらう、というアプローチだって位置詐称対策としてあり得ます。
技術的視点だけに閉じずに、企画からビジネススキームからあらゆるものを総動員して、総合力として発揮するものが位置ゲーの位置詐称対策なので、「無駄な努力」どころか、無駄な努力にはなり得ない類のものだと思います。
だって、これまでのやり方が技術的に無理なら、自分たちのあり方の方を変えちゃえばいいようなものなのだから。
コラボレータに説明するなら、「位置を絶対ユーザに詐称されずに取る事を保証する事は無理です。これこれこれだけのリスクはあります。でも、このリスクは、間違いなく業界の中で一番うちが低いです。」と胸を張って言うために取り組むのが、位置ゲーの位置詐称対策だと思います。

※位置ゲーの位置詐称対策は技術に閉じた話でなくビジネススキームまで含めた総合力だと書いたけど、それゆえに、トップであるプロデューサが位置詐称対策技術など評価に値しないと言って恥じない、位置詐称対策とそのリスク管理がビジネスモデルの核であるという事を理解していない某位置ゲーの企画陣は、どうしようもないと言わざるを得ない。
コアコンピタンスである詐称対策の重要性を理解するどころか、位置ゲーが位置ゲーである根本のところを自ら否定して回ってるなど、完全に自ら滅びに向かって突き進んでいる。
技術陣の忠告も聞かず、ハッカー/エンジニアレベルとかではなくごく普通のユーザがURLを書き換えるだけで、誰でもお手軽に詐称できるような仕様をわざわざ自ら作りこみ、あっという間に詐称されて恥をかき、コラボレータに胸を張るどころか同情され許してもらう始末、挙句の果てにやるべき責務もやらずに「詐称するユーザが悪い」と逆切れするなど、何がどう位置ゲー老舗か、どこの素人集団だという話(実際、素人集団だが、位置詐称対策に関しては)。
位置ゲーを名乗るのすらはばかられる。
ああ、位置ゲーじゃなくてジオゲーだっけ...するとアレだな、ジオゲーと位置ゲーの関係は、妖怪人間と人間みたいな関係だな、「早く位置ゲーになりたーい」みたいな。

また、某位置ゲーの技術陣も、技術者としてはすごく頑張ってるとは思うのだが、位置詐称技術は総合力である以上、企画にも物が言えないと、企画が馬鹿な暴走始めたら、何を差し置いても止められなければ位置詐称技術者としては失格だろう。
危険性は公開前から判ってたし忠告もしたんだけど、プロデューサが押し通しちゃいましたじゃダメなんだ、なんでそこで刺し違えてでも止めないのか。
馬鹿が馬鹿を貫いたとき、一番迷惑がかかるのは自分達ではなくてユーザとコラボレータであり、結果事業の首を絞めるのだという事は判ってるだろうに。
これがSSL不整備とか世間一般に知られている品質基準で、問題があればどんな事情があろうと技術陣が叩かれるような問題だったら、企画がどんなに無理解だろうと死ぬ気で止めるだろうに、同じことができなかった理由は、どこかで位置詐称対策は外部から品質が判りにくいからとか甘く見る気持ちがあったのではないのか。

なんにせよ、コロプラが真摯に、かつての私と同様に、事情を知らない外野からは「無駄な努力」としてすら見えるストイックな努力を継続しているのを知っているだけに、外部から判りにくい品質であるのをいい事にそういう努力をしもしないで同じような品質があるように見せかけたり、或いは努力をしてきた人間から上澄み成果だけ奪い取って甘い汁を吸ってるような連中の事は許せないので、コロプラと某位置ゲーの品質の違いについては、今後も折あるごとに取り上げていきたい。

閑話休題。
でも、いろいろ偉そうに言ったところで、やっぱり大道芸なんだよね。大道芸に過ぎないんだよね。
私にしろコロプラの中の人にしろ電波の杜さんにしろ、位置詐称対策に嬉々として取り組む類の人間は、みんなどっか人間としてちょっとズレたというか、自分たちが特殊な類の人種だという事は判ってます。
普通の人が興味も持たない、普通に考えてできない、無駄な努力としか思わないようなことを追及するのが大好きな変態でキチガイで、他人のサイトに穴があれば突っ込んで穴を試してみたくなる根性のねじまがった人種です。
そういう人間にしか位置詐称対策は担当できないのは判っているんだけど、そういう類の人間が作った位置ゲーが必ずしもおもしろいとは限らない(今のところ、位置詐称対策に熱心な位置ゲーの方がそうでない位置ゲーより面白い傾向があるみたいだけど、それはたまたまで常に真ではない事は当然だと考えています)。
位置詐称対策には興味は持てないけど、企画としておもしろい位置ゲーを作る才能のある人はたくさんいるんじゃないかと思ってます。
なので、位置詐称対策なんかに興味を持てない人でも、そんな大道芸を気にせずに企画だけで勝負できるような環境は作ってみたいと位置ゲー企画者ならみんな一度は思ってきたし、それがついに形として結実したのがコロプラ+プラットフォームだと思ってます。
位置ゲーに位置詐称対策は大事だけど、誰もがそんな大道芸にわずらわされるようなところはみたくない、もっと誰もが自由に位置ゲーを企画したり作ったりできるようになってほしい、そういう位置ゲー企画者としての夢を、私はコロプラ+に託しています。
面白い位置ゲーのアイデアが浮かんだ人がいれば、でも位置詐称対策とかややこしいらしいみたいだし、とか思わずに、みな一度、コロプラ+を試してみたらいいと思います(すみません、無責任に書いてますが、法人でない一般個人開発者向けにコロプラ+が開放されてるかどうかは把握してないですけど)。
位置詐称対策みたいな(大切だけど)どうでもいい努力についてはそれが好きな変態に任せて、誰もがアイデアだけで位置ゲー勝負できるような、そんなふうになればいいなと思っています。

2011年02月06日

ケータイ国盗り合戦Androidアプリのダメなところ

私が身銭を削って対応したiPhone版から遅れる事1年、ケータイ国盗り合戦がようやく昨年の12/21にAndroidに対応した。
私もちょうどIS03に機種変した後だったので、乗り換えを試してみたが、1/5までどうやっても乗り換え作業に失敗したため、機種変更ロジックすらまともに作れてないダメアプリとしてつぶやいてしまった。
が、これに関してはどうも私が中にいた時代に、自分のアカウントにごみデータを突っ込んでいたために、私だけうまく変更できなかっただけのようだった。
具体的には、ガラケーのRFC違反メアドの処理関連ロジックをテストするため、自分のメアドにわざとダブルクオーテーションを仕込んで、うまくメールが送れるか否かのテストをしたまま、放置していたのだった。
メアドが本人確認のキーになるので、そりゃキーにごみデータが含まれていれば処理も失敗するわなと。
これに関しては、自分のミスで起きた問題を不具合だとデマを流して非常に申し訳なかった。

が、その件を除いたとしても、この国盗りアプリ、少し前に出たコロプラのAndroid版と比較しても、かなりダメな仕様、私ならこんな仕様で出すのは許さなかったような点がが多すぎる。
今は外部から国盗りを楽しんでいる1ユーザとしても、この先の改善を期待して、そのような点の指摘と改善法を挙げていきたい。

欠点1:スマートフォンアプリなのにWiFiから使えない

国盗りAndroidアプリはネイティブアプリなのだが、しかしスマートフォンの売りであるはずのWiFi接続の時にアプリが使えないというのは、片手落ちというしかない。
確かに、私が開発したiPhone版でもWiFiには非対応で、3G接続時しか遊べないのだが、しかしiPhone版はブラウザアプリという事情があった。
ブラウザアプリだと、すべてがオープンなだけにユーザの位置詐称攻撃等からゲームを守るために採れる方策も限定的になり、WiFiを許すと極端な話何でもやり放題のPCを繋げられ、UserAgentを詐称されてしまえば、それをサーバ側で偽iPhoneだと見破るのは不可能なため、3Gに限定せざるを得ないという事情があった。

しかしネイティブアプリであれば、いくらでも詐称からゲームを守る方策は採れる。
実際、コロプラのAndroid版アプリは、WiFiに対応している。

Wifiでも遊べるコロプラAndroid版 Wifiでも遊べるコロプラAndroid版
▲ WiFiでもちゃんと遊べているコロプラAndroid版 ▲
上のステータスバーを見ると、WiFi接続環境で動作している事が判る。

国盗りもコロプラも、ネイティブアプリと言いつつ、その実は中身はWebViewパーツを用いたブラウザアプリにネイティブアプリの皮をかぶせているだけだ。
それ自体は、日々内容が更新されるモバイルソーシャルゲームの性質上、更新の容易なWebインタフェースを用いるのは当然の事だと思うが、しかしだからといって、工夫もなくブラウザアプリの時と全く同じ制限をネイティブアプリ化しても解消せずそのままというのは、そりゃ独自の施策を考えなくてもよい分開発の手間はかからないが、ユーザの利便性に無頓着過ぎだしあまりに芸がなさすぎる。

それでは、WiFiでも使えるような位置ゲーアプリの設計は、どうすればいいのか。
それを書く前に、次の欠点もWifi絡みなので、まずそちらを述べる。

欠点2:WiFiで遊べないだけでなく、そもそもWiFiがONになっていると今がWiFi接続でなくても起動できない

2/7追記1:本節で、「コロプラのiPhoneはブラウザアプリアプローチ」と書いたが、今年1/17から、コロプラ+のiPhone版ネイティブアプリが公開され、コロプラはiPhoneもネイティブアプリ化したようだ。
もちろんWiFi回線にも対応している他、URLスキーマによるURLからのアプリ起動にもきっちり対応している。
調査不足で知りませんでした。すみません。

2/7追記2:本節で採り上げているWiFiがONになっているだけで国盗りアプリが起動しない問題は、Androidは明示的にWiFi基地局と3Gアンテナ基地局からの位置情報を分けて取り扱えない事(http://amay077.posterous.com/37798086)に対応するためである可能性が出てきた。
WiFiは可搬な基地局の移動によりおかしな位置情報を返す事があるから(
http://blogger.dansyakusama.jp/2010/09/android-ver-111.html)、明示的に3G基地局だけを取り扱うためにWiFiオフを強制しているのかもしれない。
WiFiオンでの対策は思考実験レベルでは考えられない事もないが、位置情報信頼度の導入(これまでの水際シャットアウトによる位置詐称対策の考え方を根本から考え直す必要がある)やSSIDの管理(自分たちでPlaceEngine並みのWiFi-DB作る必要がある上に、そこまでやってもAndroidしか使えない)等、システムの大幅な見直しが必要となりそうだ。
ビルの屋内等、明らかにWiFiでしか位置が採れないところでは、コロプラのAndroidアプリは場合によっては数分かけて異様に慎重に位置を採るので、コロプラも何らかの対策はやっているのだと思うが、それ(数分かけて位置を採る)はそれでユーザビリティ的にどうかなとも思うので、簡易に対策する事を考えるならば、WiFi設定オフも止むを得ないのかもしれない。
こちらも、WiFiを通信手段/詐称手段としてしか考えておらず、位置取得手段として考える視点が抜け落ちていて、ちょっと調査不足でした。

WiFiだと遊べないのは、明らかに手抜きだがまだ許せるとしよう。
iPhone版のブラウザアプリと同様なのだから(ちなみに、コロプラでもiPhoneはブラウザアプリアプローチなので、WiFiでは遊べない)。
しかし、国盗りアプリは恐ろしい事に、今現在の回線接続に関係なく、WiFiの接続設定がONになっているだけで、アプリが起動できないという謎仕様になっているのだ。

WiFiがオンなだけで遊べない国盗りアプリ
▲ WiFi設定がオンなだけで、実際にWiFiに接続していなくても ▲
起動できない国盗りアプリ。この後、落ちる。

設定でWiFi接続がオンになっていても、実際には大半の時間が3G接続というのが一般的ユーザの利用状況だと思うが、そのユーザにいちいち国盗りアプリを起動するたびに、その時の接続回線状況に関係なく強制的にWiFiオフを実行させるというインタフェースは、狂気の沙汰としか思えない。
普通位置ゲーで遊ぶのが通勤や旅行など屋外移動中である事を考えると、家でWiFiに接続⇒WiFiに繋がらない移動中に位置ゲーで遊ぶ⇒会社やホテルでWiFiに接続、というのがよくあるパターンだと思うし、その間WiFi接続設定が常にオンであったとしても、実接続の回線さえWiFiでなければ別に困らないはずなのだが、そのような場合でも、このアプリはいちいち設定をオフにする(&、WiFiが必要になればいちいちオンにする)事をユーザに強要するのだ。
ユーザ利便性を全く考慮していないとしか言いようがない。

好意的に見ると、WiFiをONにしてるだけで起動できなくしているのは、WiFi経由のパケットキャプチャでUserAgentを盗まれる事による不正を警戒していると判断できなくもない。
普通に考えれば、WiFiがONでもアプリは起動でき、サーバ側で接続してきている回線を判定して3GかWiFiかを判定すれば済む話なのに、接続している回線に関係なくWiFiがONなだけで一切アプリの機能を動作させない=WiFi回線でサーバとの通信が発生する可能性を完全に排除したがっていると考えられるので、すなわちWiFi回線での通信パケットの発生を隠蔽しようとしているのではないか?と思われるためだ。
ネイティブアプリながらWebViewを使っているコロプラや国盗りアプリは、普通のブラウザからのアクセスとアプリのアクセスを見分ける方法として、異なるUserAgentを使うことで判定していると思われるが、そのUserAgentが判ってしまえば、アプリを模したアクセスができてしまう。
端末からテザリングしてPC等をつなぎ、3G回線から偽装アプリでアクセスされる危険性は、iPhoneよりAndroidの方が格段に高いと思われるので、UserAgentを盗まれてしまえば、偽装される危険性もあると言えなくはない。
とは言え、もしWiFiで起動できなくしている理由がそれだとすると、実は起動時にWiFiがオフだと、途中で裏でWiFiをオンにすると一回だけ通信を発生させてしまう事を確認しているので、ひどく片手落ちとしかいえないけれど。

後からWiFiオンにすれば1アクセスだけWiFiで通信が発生。 後からWiFiオンにすれば1アクセスだけWiFiで通信が発生。 後からWiFiオンにすれば1アクセスだけWiFiで通信が発生。
▲ 国盗りアプリ起動後、本体のWiFiをオンにすると、落ちずに1アクセスだけ通信が発生する。 ▲
国盗りアプリがWiFiオン時に動作しないようにしている理由は判らないが、もしパケットキャプチャに
よるUA流出を警戒しているのだとすると、ここに穴がある。

ひとつ全くわからない事があるのだけど、国盗りのAndroidアプリは、PlaceEngineと連携して屋内位置情報で遊べるようになってるはずなのだが、PlaceEngineはWiFiを使った位置同定技術なので、本体のWiFiがONになっていなければ絶対に機能しないはずなのだ。
どういうマジックを使っているのか、興味はつきない。

解決策1:位置ゲーネイティブアプリを、WiFi経由で遊べるようにする技術

欠点1も2も、WiFiで遊べるようになっていないが故の問題点だ。
では果たして、位置ゲーのネイティブアプリは、WiFi経由で遊べるようにする事はできないのか。
そんなはずはない、ライバルサービスのコロプラのアプリは、WiFi経由で遊べるのだから。
国盗りの位置情報詐称対策をはじめとするノウハウは、私が個人的に確立・開発し国盗りサービスに提供したものだが、その私が、国盗り退職後コロプラの中の人とこの辺の技術について議論した結果、そのレギュレーションの高さに頭を垂れたくらいなのだから、私はこの辺の技術に関しては、国盗りの現技術陣よりコロプラを信頼する。
穴があったとしてその穴を国盗りが見逃すことはあっても、コロプラが見逃すことはまずないだろう。
だから、コロプラがWiFi可能にしてきているという事は、WiFi可能にする方法がちゃんとあるという事だ。

ではどうやって、WiFiで位置ゲーアプリを可能にするか。
その前に、なぜiPhone版コロプラや国盗りのようなブラウザアプリでは、3G回線を許可できないか考えてみる。
ブラウザアプリでは、一切の情報をユーザから隠蔽できない。
UserAgentを偽装されれば、本物のブラウザなのか悪意ある偽スマホアクセスなのか判定する事はサーバ側ではできないし、独自のUserAgentに変更する事もできない。
平文の通信は当然通信路で情報を盗まれる可能性があるし、SSLで通信しても、UID代わりに使っているセキュアクッキーや位置詐称検出のために使っているハッシュキー等も、ブラウザ面からJavaScriptで抜かれてしまう。
或いは、JavaScriptを使わなくても、PC等で偽スマホアクセスできれば、簡単に解析されてしまう。
こういった情報がユーザに取得されてしまうと、簡単に位置詐称されてしまう事になるので、WiFi回線を許す事はできない。

ブラウザ面からは、セキュアクッキーも抜ける
▲ ブラウザ面からは、セキュアクッキーも抜けるため、 ▲
3G接続だけに限らないと、PCからの接続でも容易に
偽アクセスが可能になる。

ここで、「通信路での盗聴」と「ブラウザ面からのデータ盗用」の2つを脅威として挙げたが、このどちらがより脅威なのだろうか?
言うまでもなく、後者だ。
前者は、普通のブラウザアクセスでも存在する脅威だが、別にそんなものをものともせず、位置ゲー等よりよほどクリティカルなセキュリティを必要とするECサイトや銀行決済Webシステムは稼働している。
無論、SSLが存在しているからだ。
通信路の脅威は、基本守るべきところ(ログイン処理やユーザの個人情報処理部分、および位置詐称検知のためのハッシュキー発行等)でSSLを適切に使えば、ちゃんと守る事が出来る。
でないと、ECサイトや銀行決済サイトなんて、危なっかしくて使えない。
なので、ブラウザ位置ゲーサイトの本来の脅威は、すべてブラウザ面から情報を盗まれる事の方にある。
以前、「位置ゲーの位置詐称対策で検討すべき事」 というのをまとめた事があるが、そこで「...普通のサービスなら、アカウントの漏洩=自分の不利益なので、ユーザが積極的に自分のアカウント情報(ID/PW)を漏らす事はあり得ない。しかし、位置ゲーだとそれがあり得る。...」と書いたように、普通のサイトだと、正規ユーザとサイトは基本信頼し合ってるので、SSLで守るような情報は悪意ある第三者に渡らないように通信路だけ守れば基本問題ないが、位置ゲーだと、ユーザが自分の情報を盗み出して嘘の位置情報を送ったり自分を分身させたりするインセンティブが存在する。

つまり、ブラウザ版位置ゲーアプリでWiFiを禁止して3G接続だけを許しているのは、通信路の盗聴問題ではなくて、ブラウザ面や生HTTP通信でどうしてもユーザに漏れてしまう情報を使って、ユーザが嘘のアクセスをしてくるのを防ぐ事の方がメイン。
とりあえず3G回線だけであれば、JailBreak等でテザリングを解放した端末でない限り、その帯域からPCが入ってくることはない。
接続をiPhoneだけに限れば、JailBreakや開発環境等を駆使されない限り、基本的にはブラウザ上で人間ができる操作でしか詐称のための努力ができないため、たとえばJSONP的な通信やリダイレクト等をうまく使えば、HTTP/ブラウザ仕様からの理論的には一切の情報は隠せなくても、事実上隠蔽できるか解析の難易度をかなりのところまで上げる事はできる。

一方、ネイティブアプリの場合はどうか。
通信路はもちろん、SSLで守ることができるし、ブラウザ面も、直接アクセスできないので情報を抜く事はできない。
表と裏の両方が防がれている以上、適切に設計すれば情報を盗まれることはないし、よってWiFiでも位置ゲーアプリができないわけがないのである。
もちろん、単純に作っているだけなら、簡単に攻撃を受けるのは当然。
UserAgentを変えていても、WiFiだと非SSLアクセス時にそれを盗まれる可能性があるし、UID代わりにセキュアクッキーを埋め込んでいても、普通のブラウザからのSSLアクセス時に同じサーバへのアクセスを許してしまうと、簡単にセキュアクッキーは抜ける。
ならどうする?

UserAgentは、SSLアクセス時と非SSLアクセス時で変えてしまえばいいのだ。
ネイティブアプリならば、それができるのだから。
SSLアクセス時に非SSLアクセス時と違うUserAgentを使い、SSLアクセス時のUserAgent以外でSSLアクセスが来ると不正として判定してやれば、非SSLアクセス時のUserAgentをいくら盗まれても、痛くも痒くもない。
或いは、UserAgentは変えなくても、SSLアクセス時のUID的情報の伝え方を、セキュアクッキーではなく独自HTTPヘッダにしてやっても構わない。
いくら通信路を盗聴しても、UID情報をどうやってサーバに伝えているのかが判らなければ、攻撃のやりようがない。
別に上記をやるだけでも十分なんだが、もっと心配性なら、そもそもSSLで伝えないといけないような情報は、WebViewではなくiPhoneでいうところのNSURLConnectionのようなHTTP通信コンポーネントを使って通信してやってもいい。
これなら、WebViewを使っていないのだから、ユーザがブラウザを使っても、そこから情報が漏れる事は絶対ない。

実際、コロプラのサーバにブラウザでSSLアクセスして、セキュアクッキーを盗もうとしても、出てこない。
セキュアクッキーを抜かれないように、異なるUserAgentでアクセスされればクッキーを共有しないドメインに転送しているのか、或いはUID的情報を独自ヘッダかHTTP通信コンポーネントを使ってやり取りしているかのどちらかだろう。

コロプラへのブラウザアクセスでは、セキュアクッキーが表示されない
▲ コロプラへのブラウザアクセスでは、 ▲
セキュアクッキーは表示されない。

このように、きちんとやる事をやれば、ネイティブアプリならWiFiで位置ゲーを可能にすることは十分に可能だ。

欠点3:URLでアプリ起動できないので、QRコードリーダやメール等と連携できない

さて、欠点に戻る。
国盗りというと、コロプラと比べても外部のURLから叩かれてサイトに入ることが多い。
メールアドレスを取らないコロプラ(最近はコロプラ+で取ってるみたいだけど)と違い、メールアドレスを登録させる国盗りは、ユーザ登録時や機種変更時も空メールを送付させて、返答されてきたメールに書かれているURLにアクセスさせる事でメールの有効性を確認し、入会/機種変更手続きを行う。

国盗りガラケー版機種変手順 国盗りガラケー版機種変手順 国盗りガラケー版機種変手順
▲ 国盗りガラケー版の機種変更手順。 ▲
メーラー起動ボタン(一番左)を押して空メールを送ると、確認メールが戻ってくるので、
そのメール中のリンク(中央)を押して、アクセス先のページで旧メアドとPWを入力(一番右)。
写りが悪くてすみません。写したディスプレイ上ではもう少しましに見えてたのだけど。

この他にも、スリープユーザを起こすためのメルマガでは、ユーザに再アクセスさせるためにボーナスコバンがもらえるURLが載っていたりするし、キャンペーン等でユーザを特定の地域に誘導する際も、シリアル番号付きカード(コロカ)を利用するコロプラと違い、国盗りはQRコード+位置情報で訪問検知する形を採る事が多い(この辺で昨年末国盗りはでっかいセキュリティ事故とその後に最悪と言っていい対応をしてるのだけど、その件はまた後日、別記事で採り上げる)ので、コロプラと比較してもゲームのあらゆるところでURLを叩いてサイトにアクセスさせる要素が多く、それなくしてはゲームが成立しないと言っても過言ではない。

ところがAndroid版国盗りアプリでは、URLを叩いてもアプリと連携できないのだ。
国盗りのURLをブラウザから叩いたり、メール上のリンクからたどったりしても、「アプリを使ってください」とアナウンスが出るだけ。

URLでアクセスできない国盗りアプリ URLでアクセスできない国盗りアプリ
▲ ブラウザでURLを入力しても、アプリを使ってくれと出てくるばかり。 ▲
メールリンクやQRコードとも連携しないし、メルマガのボーナスコバンの
URLを知っていても、アプリの方ではURLを入力する場所がないので、
他機種のユーザがボーナスをもらえるのを指をくわえて見ているばかり。

おまけにアプリの方はというと、URLを入力するインタフェースがないので、もしメルマガ等からボーナスコバンをもらえるURLを知っていても、アクセスする方法がないので特典がもらえない。
そのせいか、どうもAndroidに機種変してから、メルマガが送られてきていないような気がする。
URLからアクセスさせられないのを事務局側も知ってるので、送ってもアクセスさせようがないメルマガは、Androidユーザには送らないようにしているのだろう。

では、メールアドレス登録のために空メールを送らせている入会フォームや機種変フォームはどうしているのか?
メールに書かれたURLにアクセスさせないと、メールの有効性が確認できないのではないか。
それを解決するために、わざわざ面倒な手順をユーザに踏ませている。

面倒なAndroid版国盗りの機種変フォーム 面倒なAndroid版国盗りの機種変フォーム
▲ Android版国盗りの機種変フォーム。 ▲
空メールを送ると4文字のコードが送られてくるので、これを入力させることで
メールの有効性を確認するという独自機構をわざわざAndroid版のために
作りこんでいる。
どうでもいいけど、メール下の署名欄にあるURLにアクセスしても、エラーになるだけだね。

解決策2:ガラケーのWebアプリをネイティブアプリ化でスマホ対応させるのならば、URLスキームやインテントを使え

国盗りのURLを叩くとブラウザじゃなく国盗りアプリを開くようにさせる事なんて、できないんじゃないの?と思われるかもしれないが、やる方法はある。
Androidだと、インテントという機能を使えばよい。
インテントというのは、Androidでアプリ間連携をさせるための仕様で、iPhoneのURLスキームにも似てるが、もっといろんな事ができる。
httpスキームのうち、特定のドメインのものだけに対応するアプリなんてのも指定できる。
実際、コロプラアプリはインテントに対応しているので、コロプラのURLにアクセスしようとすると、ブラウザで起動するかコロプラアプリで起動するかの選択肢が出てくる。
国盗りと比較してURLからの直接アクセス比率が低いコロプラの方が、ちゃんとインテントを設定してURLからの起動をしっかりサポートしているのは皮肉な話だ。

インテントで起動できるコロプラアプリ Androidの重要な機能、インテント
▲ コロプラはブラウザにURLを入れても、アプリで起動するか ▲
ブラウザでアクセスするかの選択肢が出る。
国盗りと同様の「アプリで起動してください」メッセージが出るのは、
ここでユーザがブラウザでのアクセスを選択した時のみ。

国盗りがインテントを知っていて、あえて使わない事を選択したとは思えないので、単に調査不足だろうと思う。
誰でも知らない事、指摘されて初めて気付く事もあるので仕方ないっちゃあ仕方ないが、URLと連携できる事が自社サービスにとってどの位重要かという認識がきちんとあれば、もうちょっと悪足掻きしただろうしそしたらちゃんと気付く事もできただろう。

ちなみにiPhoneは、インテントのように「httpスキームだけど特定のドメインだけ対応するアプリ」みたいな指定はできないが、独自スキームで起動するアプリ、みたいな事はできる。
たとえば「kntr:」というスキームをiPhoneアプリに紐付けておくと、http://kntr.jp/にアクセスした瞬間にアプリ起動、みたいな事はできないが、アクセスされたサーバ側でkntrスキームにリダイレクトしてやれば、アプリを起動させる事は可能だ。
もっとも、Locationヘッダでリダイレクトしてしまうと、ユーザがまだアプリ未インストールだった場合に迷子になってしまうので、アプリをインストールしてくれというページを出しつつ、JavaScriptでkntrスキームにリダイレクトをかけてやるのがいいだろう。
これなら、アプリインストール済みならアプリが起動するし、 未インストールなら「対応アプリがありません」のエラーは出るが、ちゃんと「アプリをダウンロードしてください」の案内は出すことができる。
アプリインストール済みの環境で全自動でアプリが起動することよりも、アプリ未インストールの環境でエラーを出さない事の方に美学を感じるなら、リダイレクトではなく「アプリインストール済みの方はこちら」という感じのリンクでもよいかもしれない...あるいは、アプリで起動された際に特別なクッキーを埋め込んでやって、それの有無で出しわけるというのもアリだろう。

欠点4:エリア地図が使えない

正直、ガラケー版国盗りからAndroid版国盗りに変わって、一番困ってるのがこれだ。
iPhone版も対応していないのだが、いい加減対応しろという話。
これは技術の問題じゃなくて、純粋に企画/マーケティング側の判断の怠慢だ。

ガラケー版国盗りには、地図上で国盗りエリアの範囲と現在地、および周辺のエリアとその取得済み/未取得が確認できる地図機能がある。
無料で使える機能ではなく、各ガラケーでの公式サイトとして存在する地図サイト「マピオンモバイル」(キャリア毎に違うが月額350円程度)に加入していないと使えないサービスだが、便利なのでそれだけの価値はある機能だ。

有料だけど使える国盗りエリア地図
▲ 有料だけど使える国盗りエリア地図。 ▲
どこからが違うエリアかすぐわかるし、その攻略状況も色分けでわかる。
数字キーで地図の拡大/縮小/移動もできるし、隣接エリア中心への移動も可能。

一方のコロプラだと、エリア分けは大雑把には分かるのだが正確な切れ目は分からないし、詳細地図も見られて移動や拡縮もできるのだけど、その上ではエリアは確認できない。
ただ、無料で使えるのであまり文句は言えないが。

コロプラのエリア地図 コロプラの一般地図
▲ コロプラの地図群。 ▲
エリア地図と通常地図に分かれていて、
エリア地図ではおおまかな分割イメージしかわからない。
通常地図では、現在地表示や移動拡縮はできるが、エリアは判らない。
ただし、誰でも無料で使える標準機能。

しかし、問題はスマホの国盗りでの地図だ。
現在地は判るのだが、エリアも取得状況も判らなければ、移動も拡縮もできない。
これは要するに、ガラケーでのマピオンモバイル非会員のユーザに見せている地図画面と同じで、ガラケーなら「有料機能に金払ってないからねえ」で済む話なのだけれども、スマホはマピオンモバイル非対応で会員になれないために、どこをどうひっくり返しても便利な地図が使えず、周辺エリアのクリア状況をグラフィカルに把握する手段さえ一切ないのだ。
地図会社のサービスなのに、地図でコロプラに負けているのだ。

スマホ版国盗りの動かない地図
▲ スマホ版国盗りの動かない地図。 ▲
エリアも全くわからないし、これ以上ピクリとも動きません。

あ、書いていて気付いたが、Androidに乗り換えて使えなくなったからマピオンモバイル退会すべきなのにしてなかったわ。
ちゃんと退会しなきゃ。

解決策3:国盗り地図はマピオンモバイルの機能ではないのだから、クニポでも使えるはず

読んでる人は思うかもしれない。
「マピオンモバイル会員しか使えない=マピオンモバイルの機能なのだから、マピオンモバイルが非対応のスマホでは使えなくても仕方がないんじゃないの?」
ところがどっこい。
国盗りで地図を表示させてURLを見てもらえば一目瞭然だが、国盗り地図は国盗りサーバの上で動いている機能で、マピオンモバイルで動いている機能ではない。
むしろ、公式サイトでない国盗りが、公式サイトでのユーザのサービス加入状況データを検知するために、若干グレー(追記2/7:グレーという表現が悪意あって見られるとあれなので、はっきり書いちゃうと、DoCoMoの公式サイトでしか使えない公式サイトIDと、勝手サイトでも使えるDoCoMoIDの紐付けを行っているんだな。別に法律違反とかではないが、高木先生なんかは怒らせるやり方だろう)な事もやってるぐらいだ。
機能設計して実装もした私が言うのだから間違いない。
国盗り地図は、マピオンモバイル加入しないとダメという縛りさえなくせば、スマホ環境でも間違いなくそのまま動く(スマホの上で動く地図サービスで、Ajaxで動かないようなのがいいかどうかは別として。そりゃAjax対応地図の方がいいに決まってるが、国盗り地図の場合エリアや攻略状況が判るという付加価値があるから、Ajax対応してなくても国盗りユーザなら100人が100人欲しいというだろう)。

結局、国盗り独自の機能であるはずの国盗り地図が、マピオンモバイルに加入しないと動かない理由は、マピオンモバイルで地図を動かせるようにするためにお金を取っているのに、国盗り側の地図が無料で動くと商売上よくないよねーとか、少額決済するプラットフォームがキャリアの公式プラットフォームしかないよねーとか、マピオンモバイルの部署でも売り上げ立てたいよねーとか、そういう大人の理由。
特に、少額決済手段が公式サイトしかなかったというのが一番大きいと思う。
なので、国盗りが独自の少額決済手段を持たなかった間は、マピオンモバイルに加入しないと動く地図を使わせない、スマホでは使えないという判断は、ある意味仕方なかった。

しかし、今は国盗りはクニポという少額決済手段を持っている。
ならば、なぜそれを使って、スマホユーザにも国盗り地図を使わせる施策を打たないのか。
昔のようにガラケー一辺倒ではなく、スマホユーザも増えている中、彼らからクニポで金を取って国盗り地図を使わせないというのは、怠慢とかいう以前に機会損失以外の何物でもないと思うのだが。
公式サイトのユーザ課金はキャリアにいくらかマージン取られる代わりに、いわゆる退会忘れ=スリープユーザが発生(まさに俺だ)して旨みがあるので、ガラケーはこれまで通り公式サイト課金でいいとしても(逆にキャリアのマージンをなくすために、ガラケーでもクニポに切り替えるという考え方もあるが、どっちがいいかはよく判らん)、スマホユーザにはクニポで払わせればいいではないか。
俺は今までクニポ一切使ったことないが、国盗り地図のためなら喜んでクニポ買うけどな。
これからどんどんスマホユーザが増えていって、(俺のようにズボラな奴でなければ)どんどん公式サイトを退会して、マピオン側の売り上げも減るわスマホユーザも国盗り地図が使えなくなってどっちも不幸になるくらいなら、クニポで国盗り地図を解放した方が、よほどみんなが幸せになるだろう。
そこになぜ考えが至らないのか、不思議でならない。

同様に公式サイトへの加入を条件にしている国盗りの機能として、協業先のJR東日本企画のトラベルナビゲータへの加入を条件としている、国盗り探索という機能(鉄道の路線検索で、取得していない国のクリアできる状況が判る)がある。
こちらもURLを見れば一目瞭然だが、国盗り地図と違い本当に向こうのサーバで動いている機能なので、国盗り地図のように単純にクニポ化してスマホにも解放しろ、とは言えないところがあるものの、これにしたって、相手サーバ上で動かすからスマホ対応が難しいのであって、機能をAPI化してもらって国盗りサーバ側で動かすか、或いはもっと、コロプラ+のようにプラットフォーム化して国盗りサーバを介しつつバックエンドは先方で動く、みたいな機構を形にすれば、クニポを使ってスマホにも開放できるはず。
そうなれば、これまでお金を取れなかったスマホユーザからもお金がとれるようになって協業先も喜ぶのみならず、本来キャリアに払っていたマージン分を国盗りがもらえるようになって、国盗りもうれしいはず。
コロプラはこれまで協業したこともないようなところと連携できるようなプラットフォーム(コロプラ+)を既に完成させているというのに、なぜ国盗りは今までずっと協業してきたところすら、プラットフォーム化して中に取り込めていないのか。

最後に

今は外部の1ユーザ、まさに今回批判したAndroidアプリのユーザとして国盗りを楽しんでいるので、上に挙げたような欠点を修正して、楽しく遊べるサイトにして欲しいというのは、本心としてある。
(個人的事情があるだけに、素直にそうも言えない部分もあるのだが、その辺はチラ裏的になるので、またコメント欄ででも書くかもしれないけどメイン記事では書かない)
ほとんどの欠点が、ライバル?のコロプラでは見られない欠点な訳だけれども、6億もの資本金で10年以上も仕事してるような大企業が、 数千万の資本金で出来て数年の会社に、技術でも施策でもマーケティングでも、何をいいようにやられてるのかという話だわね。
ユーザが楽しく遊べるように、ちゃんと頭を使って、しっかりやってもらいたい。

2010年10月16日

教えてください...軍事ド素人の目から見た斬首戦略対抗の海兵隊配置について判らない点

Posted by nene2001 at 19:30 / Tag: 軍事 / 104 Comments / 0 TrackBack / Google Maps このエントリーを含むはてなブックマーク

過去、普天間問題について2件の記事を書いてきましたが、

いずれも、『中国の台湾への斬首戦略に対抗するための対抗として、沖縄海兵隊は不可欠』という論は正しいと「仮に」受け入れたうえで、一方で考えなければならない『沖縄の民心離れ、日本離れ』を防ぐために、こういう事を考えなければならないよね、という視点で書いてきました。
この視点では、あともう一つ別の視点から書こうと思っています。

 

が、そもそも先にも「仮に受け入れ」と書いたように、『斬首戦略対抗として海兵隊必要論』自体、多くの反論が出ているので、素人にとってはどっちが正しいのかよく判りません。
そして素人ゆえに、斬首戦略対抗での海兵隊という説明に判らないところがたくさんあります。
軍事に詳しい方はそういったところをクリアされて納得されているのでしょうが、判らない身には不安があるので、是非教えていただければ幸いです。
これは『反論』ではなく『疑問』なので、答えていただける方も攻撃的にならずに教えていただければ幸いです。

 

不明点1:台湾有事に即座に介入という手札もあるのならば、台湾を国家承認しておいた方がよいという事はないのでしょうか?

台湾有事が起きた場合、米軍が介入するというオプションはあるとは思っていましたが、表面的には1つの中国を支持している以上、外交で国際的なコンセンサスを得た上での行動かと思っておりました。
しかし、有事発生後国際的コンセンサスを得ることもなく即座に、米軍単独で介入するという手札もあるのならば、公式には1つの中国を支持している以上、それは『明らかに政治介入だ、侵略だ』と中国側に宣伝される材料をみすみす与えるように感じます。
そうすると、強襲作戦が成功すればまだいいのですが、もし失敗でもすれば、その後の介入について国際社会への説明が難しくなるような気もします。
即時介入という選択肢もあり得るのであれば、アメリカ、そして(もし、自動的に交戦国として巻き込まれる可能性があるのであれば)日本は、平時から1つの中国支持を破棄して、台湾を国家承認しておき、台湾に中国が兵を出せばこちらの方が『侵略だ』と言える環境を整えておいた方がよいような気がするのですが、どうなのでしょう。

不明点2:海上で航続距離ギリギリの強襲作戦って可能なのでしょうか?

私は本当にゲームの大戦略程度の軍事知識しかありませんので、ヘリというと、敵の航空戦力や対空戦力を黙らせた後に前進させないと、七面鳥撃ちにあってしまうようなレベルの印象しかありません。
JSFさんの記事では、CH-53Eというヘリを使って沖縄本島-台北-下地島までの航続距離いっぱいの強襲作戦を行うとの事なのですが、行き650km強、帰り350?強、速度は280km/hくらいだそうなので(150KIASとWikipediaには書かれていますが、1KIAS=1.852km/hらしいです) 、行きに2時間半、帰りに1時間半くらい、着陸する事も困難な洋上に機体を晒すことになってしまうと思うのですが、敵の航空戦力や対空戦力の餌食になってしまう事はないのでしょうか?
特に、行きは大半日本領空内なのでともかく、帰りは建前上相手国の領内とこちらも認めている領域への強襲なので、こちらの領空内だろうと追撃に来るのではと思えます。
航続距離ギリギリなので、攻撃を受けても回避行動も難しいのでは?とか素人としては思ってしまいます。
嘉手納や航空自衛隊の援護があれば問題ないのでしょうか。

不明点3:強襲作戦中、ヘリってどこで待機しているのでしょう?

無事台北に着いたとして、海兵隊を降下させて要人救出作戦に移ると思います。
作戦のイメージが湧かないので、救出作戦がどの程度の規模で、数十分なのか数時間なのか日単位なのか、どの位の時間を費やすものなのか判らないのですが、その間ヘリってどこで待機しているのでしょう?
ヘリ1機の作戦とは思えないので、複数機のヘリを協調して降下できる場所をどこかに確保し、降下させ、敵支配下の土地で救出作戦完了/離脱するまでヘリを敵の攻撃から守りきらないといけないと思うのですが、そのような事は可能なのでしょうか?

不明点4:下地島まで無事たどり着いても、爆撃されれば危険なのでは?

もし下地島まで無事たどり着いたとしても、下地島は民間施設なので、まともな防衛設備もないと思うのですが、到着から補給する間もなく間髪入れずに爆撃されれば、要人もろとも全滅という事はないのでしょうか?
艦船や航空機に乗り換えればよいのかもしれませんが、艦船だと追撃に追いつかれますし、航空機だと運べる員数が限られるので、要人は逃せても救出部隊は逃がせない気がします。
これも、嘉手納の支援があれば大丈夫なのでしょうか?

不明点5:かなり危ない橋の作戦のように見えるのですが、損耗率はアメリカ世論を納得させられるレベルで収まるのでしょうか?

そもそも普天間に何機くらいのCH-53Eがあって、とかが判らないので、どの位の機数のヘリと海兵隊員何人くらいが参加する作戦なのか想像がつかないのですが、長距離の洋上を駆って敵地内での潜入作戦となると、すごい損耗率になりそうな印象を受けます。
CH-53Eは1機で55人の兵員を輸送できるという事ですが、そうするとたった2機撃墜されただけで、100人を超える犠牲者が出る可能性がありそうです。
たった半日や1日の戦闘で、それだけの損耗の発生は、今のアメリカ世論が納得する範囲なのでしょうか?

不明点6:そもそも、シナリオの中で、日本はどの段階から戦争の当事国になるのでしょうか?またその場合、戦争を仕掛けた側になる?攻撃を受けた側になる?

シナリオの中に下地島が入っている事に関して、こういう記事もあります。

台湾有事に米軍ヘリが下地島で給油というおとぎ話

だって下地島は民間空港。通常の訓練や移動時に「燃料が足りないのでどうしても」とお願いされれば補給するでしょうけど、アメリカがガチンコで中国と戦争を始めている時に、その戦闘行動中のヘリコプターに補給なんてできる訳ないでしょ。
そんなことすれば、日本が自らの意志で中国と戦端を開くってことですよ。

これが日本への武力攻撃が起きている、またはそれが十分予測される事態なら、有事法の一つである武力攻撃事態法によって、下地島空港での補給が可能となります。しかしながら台湾有事は建前上は中国の内戦です。台湾を国として承認せず、軍事同盟すら結んでいない日本が、その状況で台湾に一方的に肩入れするような行動を取れるはずもありません。

もちろん、台湾有事をもう一段階下の周辺事態に認定するということは有り得るでしょう。戦闘の結果、どちらかが日本の領域内に逃げ込む、それを追うもう一方が攻撃を仕掛け、その結果として日本の国土や人命が傷つけられるという可能性も十分にありますから。

でも、周辺事態法に則って民間空港で補給できるのはあくまでも武力行使を伴わないもの。戦闘行動中のアメリカのヘリコプターにはそれはできません。
結局、周辺事態の余波で日本が被害を受けたとしても、それは偶発的な事故なのであり、意志を持った武力攻撃ではないということ。台湾側が日本を傷つける場合だってあるのですから。よって、日本が求められるのはあくまでも中立の立場。どちらか一方への肩入れは「周辺事態」の枠組みから外れます。

素人で民間人の私としては、一連のシナリオの中で何時日本が戦争の当事国として、相手国、或いは国際的に見做されるのかが気になります。

  • 米軍の強襲部隊やその掩護部隊が展開し、実攻撃を行った時点で、同盟国である日本もその一翼を担う(かつ、国際的には戦争を起こした側として?)と見做されるのでしょうか。
  • それとも、同盟の存在有無ではなく、日本国内の普天間基地や嘉手納基地が作戦元になっている事実によって、日本も攻撃側紛争当事国として扱われるのでしょうか。
  • 日本国内の米軍基地が策源になっているだけでは日本は当事国としては扱われず、民間空港であるはずの下地島利用の便宜を米軍に提供した時点で、攻撃側紛争当事国として扱われるのでしょうか。
  • それとも、一連のシナリオではまだ日本は当事国にはなっておらず、米軍の作戦の結果、中国側が下地島や普天間/嘉手納への攻撃を行ってきたりしたら、その時点で防衛戦争としての当事国になるのでしょうか。

その辺の、シナリオの中でいつ日本が紛争当事国として扱われるのか、また攻撃側の当事国になるのか防衛側の当事国になるのかについて、知識がないので教えて欲しいです。

不明点7:台湾有事時の米軍の即応強襲作戦で自動的に日本が当事国になるのであれば、その事は国民に周知されておくべきではないでしょうか?

まあ日本国民も、平均的な感覚の話でいえば、政治家やマスコミが敵対心を煽る『ならず者国家』が突然暴発してミサイルぶっ放してきたりして、突然戦争になる事に対する覚悟は、あるとは思うんですよ(本当に煽っているほどの蓋然性があるのか、は別として)。
或いは、周辺国家との国交が悪化して、数年レベルのサイクルで、戦争状態になる可能性はあり得ないことではないと思ってると思う。
また或いは、朝鮮半島や台湾なんかの有事に、難民が渡ってきたりで影響に巻き込まれたり、世論の間で議論が発生して、その結果として一方の側に与し参戦する可能性もある、くらいまでは、何とかギリギリ覚悟があるのでは?と思う。

が、まさか、国内でもないし、同盟国どころか国家承認すらしていない台湾に対し、武力侵攻があればたった数日でアメリカが参戦し、その結果国内世論もクソもなく、まるでピタゴラ装置のように自動的に日本も当事国になり、中国からミサイルが飛んできてもおかしくない状態になる、というのはさすがに大半の国民が想定も覚悟もしてないし、納得もしていないと思う。
もしそのように、イザという時に世論の喚起を待つ暇もなく自動的に紛争当事国になる、というシナリオがあらかじめ判っているのであれば、それは国民に周知されておくべきではないでしょうか?

不明点8:JSFさんが『普天間の海兵隊は台湾有事の強襲用』とネット上で明かしてしまった時点で、その意図は中国側に伝わっており、採り得ない作戦になってしまった可能性はないのでしょうか?

私は何度も書きますが、軍事の素人なので、普天間のヘリ部隊がどれだけの圧倒的兵力を持っているのかは知りませんし、少々敵に意図を知られたところで、失敗しようのない圧倒的兵力を投射できるのかどうかも知りません。
なので、沖縄の海兵隊は斬首戦略対抗で存在する、とネット上で明かしてしまっても、圧倒的兵力で無問題!なのかもしれない。

でも、まだここまでの不明点に答えていただけてない状況で素人が感じる印象としては、すごい危ない橋の作戦のような気がするのです。
実行前に意図を知られてしまえば、対処されて大損害出して失敗しておしまい、というレベルのような気がします。
それを、JSFさんがネット上で明かしてしまった時点で、その意図は中国側に筒抜けになってしまい、結果的に採り得ない選択肢になってしまった、という可能性はないでしょうか?

私は前々職が某国の諜報担当官庁の情報収集システム構築業務だったんですが、普通に諜報活動の中に、インターネット上での情報収集が機能要件にありました(私はシステム構成検討とその結果としての見積額の先方との交渉役(要するにソロバン弾いて『勉強しまっせ引越しのサカイ』役)だったので、具体的な機能とその実現方法は全然知りませんが)。
平和ボケとかなんとか言われてる某国ですらちゃんとそういう事やってるんですから、軍事大国である中国であれば、ネット上の仮想敵国情報監視くらい普通にやってるでしょう。
そうすれば、(私は素人なので判りませんが)JSFさんが普段から軍事的に正しい事を言っていれば言っているほど、その存在は中国側にマークされているはずであり、そこで『普天間の海兵隊は斬首戦略が行われた際にヘリで強襲し、下地島に帰還するための部隊』と明かしてしまえば、その意図は中国にも伝わって、その米軍の意図を実現させないように対策をした上での斬首戦略を実行されてしまわないでしょうか?

 

以上、素人すぎて知らない事が多く恥ずかしい限りですが、軍事に詳しい方、教えていただければ幸いです。

2010年10月11日

海兵隊基地を沖縄定着させるならば、過去へ頭を下げる事と抑止力の詳細についての説明が不可欠

沖縄基地問題についてです。
読もうとする多くの人が、おそらく「今更の話題かよ...」と思うかもしれませんが、沖縄にとっては今までもずっと、これからも下手するとずっと目の前に突き付けられる現実であり、「今更」という捉え方自体が傲慢な視点だと言えると思います。

 

現状、鳩山政権後半から、「抑止力」というキーワードが出てきて政治的には県外移設ありえない、県内移設の方向で動いているようです。
で、私のスタンスですが、以前紫苑さんのところでも書いた通り

本結論では県外と位置づけられたようですが、こういう多角的な視点から考慮したうえで、それでもなお県内しか考えられない、というのであれば、nagonaguさんあたりには怒られてしまうかもしれませんが、それはそれで仕方ないと思うのです。
ただ、その場合でも、今の議論で徹底的に欠けているのが、紫音さんもおっしゃられるとおり、

> もっとも重要なのは、日本民族が関心を高め、理解に努め、その上で、なお必要とされる負担があるならば、それは頭を下げ、お願いし、理解してもらうこと

だと思っています。
沖縄の歴史的経緯や現状を考えれば、このような日本側の姿勢の改めがなければ、県内移設など100%あり得ないと考えます。
少なくとも、軍事的帰結だけ考慮して言いっ放し、『沖縄は大規模抵抗が起きていないから押し通してしまえばいい』、『抵抗が起きても暴動鎮圧してしまえばいい、国内問題だし』『基地作らせないならば焦土化してしまえ』というような、チベット政策顔負けの眼差しを持った輩が跋扈している間は、県内移設など100%あり得ないでしょう。

十分な議論を費やしたうえでそれでもなお県内となってしまうのであれば、それは仕方がないと思っています。
ですが、それには本土側が過去の経緯について頭を下げ、十分納得のいく説明をし、理解してもらうことが不可欠だとも書いています。
それが為されない、為されていないのであれば、県内移設は絶対あり得ない。

 

さて、「抑止力」ゆえに県内移設しかないそうですが、それ自体が正しいかどうかは私は判断できるだけの知識はありません。
が、仮に正しいとしても、それを押し通すために必要不可欠な十分な説明を、政治は、本土側は行ったでしょうか。
答えはノーとしか言いようがありません。

「んなもん、国境傍の境界領域なんやから、軍隊置いて守るんは当たり前やんけ。それが抑止力や。説明十分や。」と多くの人が思っているのでしょう。
でも、それでは沖縄の人はまず納得しません。
なぜなら、議論の前提として持っている知識が本土と沖縄では違いすぎるからです。

本土の人間は、問題が取り上げられなければ興味も持てない他人事ですから、基地ができてきた経緯に関する知識も、基地負担が本土と比べてどの位不均衡かという事に対する肌感覚もありません。
ただ、話題に上ったその時の感覚だけで、「国境/辺境地帯に兵力があるのは当たり前だろう、抑止力だよ抑止力、抑止力がなければ平和が保てないだろう、抑止力不要なんて脳みそお花畑じゃないの?」という認識なのでしょう。
実際、そんな感じの発言をされている人を多くみかけます。
が、実際に当事者として基地問題に直面し、これまでの経緯も知っている沖縄の人の認識は違います。

メモ:沖縄に米軍基地が75%ある歴史
1950年に朝鮮戦争が起こり、アメリカは日本全土に米軍基地を置いて参戦しますが、日本の物資を利用したため、日本は膨大な経済的利益を得ました。朝鮮戦争によってお互いの利益関係が確認されたのです。1952年に日米安全保障条約が成立し、アメリカは日本全土に基地を置く権利を得ました。しかし、このことが日本国民の反米感情を刺激することになり、条約は改定されます。その結果、本土の米軍基地は4分の1に減り、その分が沖縄に移り、沖縄の米軍基地は2倍に増えました。

1972年に沖縄が日本に返還された時、本土の米軍基地は約3分の1に減らされましたが、沖縄の米軍基地は減らされなかったため、現在でも沖縄へ多大な影響を及ぼしています。

【普天間移設】反基地闘争が激化した岐阜と山梨から沖縄に移駐した史実がある
「米海兵隊を岐阜に引き取ってよ」―沖縄県の地元紙記者はこう言った。少しく酔いも手伝って冗談まじりだったが、目は笑ってはいなかった。岐阜県の人は在沖海兵隊の歩みを知っているね、と念を押しているようだった。
在沖米海兵隊は1956年2月、岐阜県各務原市と山梨県から移転してきた史実を知っておかないと、冒頭発言は理解できない。米軍基地は戦後ずっと沖縄にあるが、駐留部隊の多くは日本本土や韓国から集められた。

というふうに、「沖縄海兵隊は最初から辺境地沖縄に駐留していたわけではなく、日本本土での反基地闘争での煽りを受けて、日本本土から移転した分が沖縄に来た」米海兵隊の沖縄駐留経緯の歴史を知っており、その結果として、

沖縄県『沖縄の米軍基地の現状と課題』
*【国土面積の0.6%に過きない】狭あいな沖縄県に全国の米軍施設の約25%が存在する。
*【米軍専用施設面積は全国の約75%
本土の基地がほとんど国有地(約87%)であるのに対し、沖縄は市町村有地(約30%)、私有地(約33%)が多い。(国有地約33%、県有地約3%)
*特に基地が集中する沖縄本島中部地域では、約76%が私有地

という状況になっているというのを肌感覚で持っています。
このような前提がある状態では、最初は元々沖縄にはなかったものを本土側のエゴで押し付けておきながら、今になって「それはそこにないといけないもんなんだよ、抑止力だよ、当然だろ」と言ったって、沖縄の人達に対してはまったく説得力はなく、むしろ本土は自分達が負担したくないから言い訳をしているに過ぎない、と考えるのは当然です。
この前提に対する意識の違いを無視して、「抑止力だよ」と念仏のように唱えていれば、いつかは沖縄の人達も折れるだろう等と夢想しているのは、それこそ「脳みそお花畑」な連中と言って問題ないと思います。

この状態を打開したいのであれば、最低限、沖縄と同じ前提を共有しなければいけないし、もし「今現在は、確かに不可欠な抑止力として機能している」のだと仮にしても、過去においては「単に本土が嫌がった厄介者を沖縄に押し付けた」ところから始まっているのだ、という事実を真摯に受け止め、それを前提にしての筋を通した説明をしないといけないでしょう。
すなわち、

  • 過去は確かに、厄介者を押し付けてしまったところから始まっている事を認め、その事に対して頭を下げる事
  • 現状は抑止力として機能しているのだと仮にしても、それは何時から、どのような情勢の変化によってそうなったのか、筋道立てて説明する事
  • また、実際に海兵隊が存在する事による抑止力とは一体何なのか、それを説明する事

最低限以上が、ネット上の言説とかでなくちゃんと政府の口から沖縄に対して説明がなければ、県内移設で納得してくれと要求するのは無理な話でしょう。
もちろん、説明しても納得してもらえるかは不明ですが、説明もせずに納得しろというのは、沖縄の人が持つ歴史的経緯からの前提からは絶対にあり得ないと思えます。

 

で、具体的な沖縄海兵隊の抑止力の内容ですが、私は軍事の知識が弱いので正しいのかどうかはよく判らないのですが、ネット上で信頼できるとされている軍事研究ブロガーの人の分析によると、

なぜ普天間基地移設先は沖縄県内でなければならないのか
台湾海峡有事の際、開戦初頭に中国の特殊部隊が台湾行政府・軍指揮施設を占拠し、台湾軍の指揮系統を麻痺させ、本隊の侵攻を助けようとする手段に出て来た場合、もし自力で特殊部隊を排除できなければ組織的抵抗を行う事すら困難になります。そういった場合に外から介入できる戦力が用意されていれば、指揮系統を回復できる可能性が生まれるので、手札の一つとして「沖縄の米海兵隊ヘリコプター部隊」の即時介入能力が必要となってきます。

台湾有事の際の中国の斬首戦略というものに対抗して、即応展開するための存在なようで、日本領土自体、沖縄自体を守るための部隊ではないようです。
その事は、同じ記事中に、

沖縄の海兵師団は台湾防衛用で、ハワイの陸軍師団が日本防衛用であるという事は、基本事項として抑えておくべき事実です。

と書かれていますし、また同じ筆者のTwitterでも、

はっきり言うと現状の戦力比なら離島奪還は自衛隊単独で可能です。

と言われていますので、間違いないと思います。

もちろん、唇破れれば歯寒し、と言いますから、台湾がやられれば次は沖縄が危ない、だから台湾を守るのは抑止力、というのは判らないでもないです。
が、歴史的に本土にあった厄介者を押し付けられた挙句、今は抑止力として必要だ、と言われると思えば、その正体は自分達ではなく外国を守る兵力、しかも国民を犠牲にしてまで守る国の正体はというと、そこまで大切ならちゃんと承認して国交結んで同盟国になればよいのに、何に腰が引けてるのかは知らないが国家承認もせず国交もない国、これで沖縄の人が納得するでしょうか。
なかなか難しい気はしますが、それが本当に必要だというのであれば、ちゃんと上記を政府の言葉として、沖縄に説明しなければならない、させなければならない。
脳内お花畑な人でない限り、県内移設を主張するならば政府にそれを行わせなければいけないし、そのプロセスなくしての県内移転は、筋としてあり得ないでしょう。

 

もちろん、本当に必要ならば、沖縄の人の納得等必要なしとして、移設を強行するという手もあるでしょう。
国家にはそれをする力があるのですから。
が、それを行うことで、物理的に基地ができたはいいが、それこそ中国あたりが介入しかねない、より不安定な政治的状況をあの領域に生じさせてしまう可能性も考えるべきではないかと思います。
ただでさえ、琉球王国等近代まで歴史を異にしてきた領域であり、独立運動等が起こってもおかしくない地域であるのに、今現地の納得なく県内移設を強行すると(今回、納得を得られず/得ようとせずに強行するという事は、すなわち「抑止力等というのは方便で、本音では本土は自分達が引き受けたくない厄介者を沖縄に押し付けているだけだ」という沖縄側の認識を解消できない、という事を意味する事に留意)、そのような不安定な政治的状況が発生する蓋然性はかなり高いのではないかと感じます。

2010年10月09日

アイヌ語は将来公用語にする事を前提とした施策を打つべき

Posted by nene2001 at 23:30 / Tag: アイヌ語 民族 / 78 Comments / 0 TrackBack / Google Maps このエントリーを含むはてなブックマーク

Mukkeさんの記事経由で今更知ったんだけど、

2008年、ここまで明確な提言がすでに出てたのね。
アイヌ語を公用語に、というのは誰でも思いつくし言ってる人もたくさん見たけど、ここまで明確な提言が過去あったのは、恥ずかしながらチェック漏れで気付いてなかった。
本当にアイヌ語の公用語化については、日本はもうちょっと真剣に考えた方がいい。

けど、アイヌ語を公用語にという話をすると、アイヌ語の現状が公用語にできるレベルでない事を以て公用語などアホか、という人がいる。
確かにアイヌ語の現状は、カナ表記かローマ字表記かで正書法も確立していないし、そもそも標準語にあたるものが存在しないし、現代に通用させるうえで語彙も足りないのだから、公用語として用いるのであればその辺を確立しないといけない。
が、そのようなものの成立を待ってから公用語化をするのであれば、いつまで経っても公用語化は進まないだろう。
鶏が先か卵が先か的なところはあるが、むしろ公用語化を前提にする事によって、社会の中の需要を作り出し、それによって周辺条件の充実を図る手法をとらないと、いつまで経っても無理だろう。

もともと文字を持っていた日本語ですら、明治までは標準語も正書法もなかったのだ。
もともと文字がなかったアイヌ語でそれを成し遂げるとすれば、日本語以上の労力が必要だろう。
日本語の場合はそれを明治後、国家事業としてやったからこその現在があるのだから、同じ国の国民であるアイヌのアイヌ語に対しても、同等以上の労力を費やすのが筋だろう。
日本語は国の力でやっておいて、アイヌ語はアイヌ民族で勝手にやれば、というのは明らかにおかしい。

そもそも、中央の権力が地方を間接的に統治していた時代と異なり、国語や教育の制度が国家規模で制定された国民国家の時代においては、国家そのものがメディア化しており、標準とされた言語は無償で身につける事ができ、それを操れれば生活にも困らないし職にも困らないという特権的な地位を与えられており、その他の存在を駆逐している。
その意味ではアイヌ語と同様に、各地の方言も消滅の危機に瀕しているというのは、よく語られる話だと思う。
しかしそれでも方言は、日本語の一類型であって多少の訛りや語彙の差以外は標準語と相互乗り入れ可能であるし、何より国全体ではマイノリティでも地域ではマジョリティの立場を保てている分、活きた言語として地域では流通しているし、その消滅の度合いは緩やかだと言えると思う。
しかし、日本語と全く異なる文法や語彙体系で相互乗り入れ不可能で、かつ地域ですらマイノリティであるアイヌ語は、既に地域ですら活きた言語として流通していないし、その消滅の速度は急激だ。
それをもう一度活きた言語として流通できるレベルに引き上げるのに、マイノリティのアイヌ民族だけで実現するのは不可能だし、国による介入が必要だ。
公用語化するのを前提にする、というのは、その介入として機能するのではないか、と思う。

公用語化されるとなれば、そのために正書法やアイヌ標準語の制定も行わないといけないし、語彙も充実させないといけない。
そうなるとアイヌ語関連の研究も急速に進むだろうし、その後は公用語である以上、法律や条例等の公的文書類はアイヌ語でも記述されないといけなくなるし、また日常生活でも最低限役所等公的機関の手続き等はアイヌ語でも受け付けないといけなくなる以上、そこに社会でのアイヌ語需要が発生するし、するとアイヌ語を学ぼう、身に着けようという人も増えてくる。
いわば、「アイヌ語で食える」ようになる。
そうして初めて、国家そのものがメディア化している現代社会では、活きた言語として息を吹き返す事ができるだろう。

こういう事を書くと、また「アイヌ利権を作るのか」という人が出てくるだろう。
そうじゃなくて、現時点での日本語が、既にアイヌ語を押しのけて「利権化」しているのだ。
同じ国民の言語なのだから、アイヌ語を日本語と同じ利権レベルまで高めるだけの話で、それは利権化でもなんでもない。
むしろ、「日本は日本文化でアイヌ文化へのエスニッククレンジング等行っていない、同化政策などしていない」と主張するのであれば、絶対に必要な事だと言える。

2012年04月
Su Mo Tu We Th Fr Sa
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30          

About Me

Navigation

Search
Google
Web
kokogiko.net
Archives
Recent Entries
Recent Comments
Recent Trackbacks
ここギコ!: tokuhiromの書き方、頭悪りい()
tokuhiromの書き方、頭悪りい
ここギコ!: はじめてPlagger使ってみた。()
はじめてPlagger使ってみた。
さよなら初代ケータイ国盗り合戦プラットフォーム&オープンソースにできないですかねマピオンさん(ここギコ!)
自分で産んだ全体最適化ソリューションに自分でトドメさした...合掌
さよなら初代ケータイ国盗り合戦プラットフォーム&オープンソースにできないですかねマピオンさん(ここギコ!)
ケータイ国盗り合戦で使ってるケータイ絵文字対応表
WiFi位置情報で位置詐称対策は本当にできないのか?についての思考実験(ここギコ!)
ケータイ国盗り合戦Androidアプリのダメなところ
何度も言うけど、位置詐称対策「技術」なんて本来の意味の技術じゃなくて大道芸だよ(ここギコ!)
ケータイ国盗り合戦Androidアプリのダメなところ
コロプラのビジネスについて追記(767676764のJimdoページ)
コロカの詳細が判りました&店舗誘導における来店検知の方法について
「米国海兵隊の台湾派遣を法的に義務付けさせよ」という反論 小川和久『ヤマトンチュの大罪』(3)(もちつけblog(仮))
海兵隊基地を沖縄定着させるならば、過去へ頭を下げる事と抑止力の詳細についての説明が不可欠
教えてください...軍事ド素人の目から見た斬首戦略対抗の海兵隊配置について判らない点(ここギコ!)
普天間基地移設が軍事的に見て県外移設はあり得ないとかの議論について
教えてください...軍事ド素人の目から見た斬首戦略対抗の海兵隊配置について判らない点(ここギコ!)
海兵隊基地を沖縄定着させるならば、過去へ頭を下げる事と抑止力の詳細についての説明が不可欠
Hatena bookmarked
My Hatebu

Banners

Syndication
Powered by
Get it!!