報道発表資料 : 「ドコモ ケータイ送金」の提供開始について | お知らせ | NTTドコモ (2009/7)

「ドコモケータイ送金」は、新たな口座の開設や事前登録などの手続きをすることなく、送り手となるお客様が相手（受け手）の携帯電話番号を指定することで送金などが可能となるサービスです。受け手となるお客様は、送金された金額を任意の銀行口座で受け取るか、または毎月の携帯電話料金に充当する方法で受け取ることができます。 送金金額についてはサービス利用料と一緒に、毎月の携帯電話料金に合算して送り手のお客様に請求させていただきます。 お客様は、本サービスをご利用いただくことにより、飲み会代の精算など、友人・知人間でのお金の受け渡しを簡便に行うことができるようになります。

まだドコモ内に閉じてしまっているし、受け取り限度額20万円／月ということはあくまで個人間取引向けで事業者向きではないんだが、それでも大きな前進だと思う。

最近のJava界隈はほんとわからん。まああんまし気にせず好きなコード書きゃいんじゃね的な方向で。

結局、ここ二年のネット関連ビジネスで黒字化しているのは、ヤフーとか除けば物販依存かゲームのようにパッケージに対して相対的に安価なコンテンツぐらいしか利益が出ていないわけですよ。そうでなければ、クリック誘導もどきで顧客騙して広告クリッコさせるコンテンツあたりでしか利益は出ないでしょう。

だから、どうやって稼ぐか、つまりマネタイズをどうすればいいのかに関心が集まるんだろうけれども、大枠で言うならば、サービスは赤字でもいいから受託開発で稼ぐというカヤックの貧相な社長が言っていたようなアプローチしか考えられないだろう中堅以下は、というのが実情だ。だって一番利益率の高いところは受託開発なんだもの。しょうがないよね。それの営業をするには人を雇うか知名度を上げざるを得ないわけで、話題になるサービスをやって、それを名刺代わりに利益率の取れるビジネスを受注するという以外にどういう利益拡大策があるのかという話だ。

で、「結局、ネットとかwebとかはツールでしかないのよ」という書き出しでなんか書こうかと思ったんだが書き出しの一文の時点でなんか面白みがなさげだし、疲れたんで寝る。

F's Garage：そろそろモバツイがEC2に移転した話でも書くとするか。　(2009/6)

以下、読者としての感想など。

あるイベントで、EC2を活用されているHeartRailsの方にモバツイの構成をEC2に移転したらどうなるか？みたいな話をお伺いしたら、すぐ8万円/月ぐらいに構成になってしまう、と言われたのですが、大体、どんぴしゃな感じでした。

やっぱりなんだかんだいってそうなりますか。なるよなあうん。 それでも、性能比を加味したうえで同等のブツを一般的なハウジング環境などで組んだときの初期投資はもちろんいろんなコスト＝固定資産がどうとか減価償却だとかそういう会計処理コスト含め＝と照らすと、「買い」だと思えた。 もちろん、elasticなインフラ環境であるという点も大いに含めて。

また、DBサーバに共有エリアを儲けて、PHPのセッションファイルの共有を、WebサーバからNFS経由で読み込んでいます。経験上、セッションの共有にNFSを使って、あまり幸せになったことがないので躊躇しましたが、EC2のロードバランサー（筆者注：Elastic Load Balancingサービスのこと）が、L4レベルのものらしく、Stickyセッションなど同一のWebサーバに振り分けるような処理ができないようなので、モバツイのセッションはシンプルなので、まぁいいか、と。

NFSって安定してるんだか安定してないんだかわからないところが嫌ですよね。結局そこが単一障害点になりがちだし。かといってNFSをクラスタ構成でとか言い出すとキリないし。金かかるし。

そこで、mod_proxy_balancerってのはどうだろう。こいつのセッション維持も含めたロードバランシング機能はJava/JSP仕様向けではあるけど別にPHPやperlであっても普通に使えるはず。つまり、

Elastic Load Balancingサービス（によるL4レベルロードバランシング）
↓
apache+mod_proxy_balancer 1号機、2号機（どっちかに振られる）
↓
apache+perl/php（またはTomcat単体）1号、2号、3号、、、以下必要なだけ。
↓
DBサーバ群

みたいな。ただしこれをAmazon EC2上で組むと確実にインスタンス2個追加になる諸刃の刃。

どう考えても会社規模に比べて多すぎ。 いかに簡単に人が辞めていく会社かってのがわかる気がする。 某リ○○○○みたいに辞めるのが当たり前に近い風土かつ辞めたあとのキャリアパスがわかりやすい（広告系とか）かつそれだけの給料やら準備金（退職金）やらが積まれてる、とも思えないし。Webってそこまで飯食えるほど裾野の広い業界じゃない。 中途半端に入って中途半端に辞めて起業！とかいったところでこのへんのページに並んで楽天の店舗のページ作り続ける側にまわるだけ、に30カノッサ。

• 【完了・連絡事項あり】6/7 22:00からモバツイッターのメンテナンスを行います。 | MovaTwitter開発者blog (2009-06-07)
• EC2環境におけるモバツイッターの現状説明 | MovaTwitter開発者blog (2009-06-08)
• Amazon EC2に移転した件と、モバツイのURL、イマココについて。 | MovaTwitter開発者blog (2009-06-14)

本家twitterの公開APIを使って日本のケータイからついったーできる派生Webサービスを提供しているのがモバツイッター。開発者はpaperboyでカラメルというショッピングサイトを担当しているf-shinさん。いままで自宅サーバでやってたのをAmazon EC2へ移行を試みているらしい。（もう作業完了？）

クラウド、クラウド、って言うけれど、実際のところは使ってみなきゃわからない。 なのに出てくる事例といえばニューヨークタイムズで大量の過去記事のPDF化作業のためにAmazon EC2を使って数日でこなしたとかいう話だったりする（情報古いね、すいません、自分がそれほど情報追ってないだけかも）。それって一時的な作業の話であって、たとえばWebサイトのような恒常的なサービス提供の事例じゃないのでWeb屋としては参考になりにくい。

そういや、昨日のseasarカンファレンスでもひがやすお氏のGoogleAppEngine上でJavaでBigTable使って云々という発表を見るために教室の前の長蛇の列に並んでたそこのおまえ！、情報集めばっかしてないでまず自分でクラウドしてみたらどうなのよ。おかげであのあと大ホールのほうで比嘉さんに同じ発表をもう一回やらせることになったらしいじゃねえか。ご苦労様です。（自分はBigtabelは特に興味なかったので他の発表見てた）

とか言ってる間にモバツイッターがAmazonEC2に移行しようかなとのこと。 さっそく性能問題にぶち当たったらしいし、ナイス人柱。いや、そう言ってしまうのは若干失礼なのは承知だが、でも本当にこういう話はありがたい。月間100万PV単位の規模のWebサービスでEC2を使ってみたという事例はまだあまり聞かない（公開されてない）から貴重な実験体である。 まだ移行したばかり（作業中？）らしいので、落ち着いたら、どんな感じの構成、性能、使い勝手かなんて話が聞けたらうれしい。といっている俺がいちばん他力本願。すいません。

9割以上がID・パスワードを複数サイトで併用、野村総研調べ (InternetWatch 2009/6)

ID・パスワードの設定方法では、「いくつかのID・パスワードの中から選んで設定する」が66.7％を占め、「ひとつに統一する」（25.8％）と合わせると、9割以上の回答者がID・パスワードを複数のサイトで併用していることがわかった。

• 俺は悪くないYahooが悪いんだ返金しろ、とか言う人はこれを読んで胸に手を当ててよく考えてね (2008/9)
• パスワードをハッシュ化（暗号化）保存することを法律で義務化するくらいのことが必要だと思う (2008/10)
• パスワードによるログイン管理の陳腐化と 制度整備の検討 - 雑種路線でいこう (2008/10)
• サイトごとに違うパスワードを！ - Yahoo!セキュリティセンター

• 「楽天」が抱えている10個の問題点まとめ - GIGAZINE
• GIGAZINE対楽天　ぼくらの7日間戦争: 切込隊長BLOG（ブログ） Lead‐off man's Blog
• 何がGIGAZINEをここまで突き動かすのか？　予想の斜め上を行くGIGAZINEの反論 ｜デジタルマガジン
• 楽天のサポートに問い合わせた - 最速転職研究会

  問題になりそうなのって、その（顧客と楽天の店舗の間の）取引に必要な範囲にメールアドレスが含まれるのかどうかということですよね。利用規約の解釈としては連絡手段として必要ってことになるんでしょうけども、楽天が出店者と注文者のメールアドレスを知ってるんだから、取り引きの間だけ有効 or その店舗からしか送れない転送メールアドレスを作ってやればいい話で、そういう予定だったのだけども、未だに開発できていないか、開発コストと個人情報流出のリスクを天秤に掛けて見合わないと判断されたとか、店側からの反発があったとか、そんなんで未だに実現できていないのではないですかね。元々店舗側は個人情報の目的外利用を禁止されているはずですし生メールアドレスだろうと転送アドレスだろうと関係ないはずで、商取引に生メールアドレスが必須かどうかとか、そういうくだらないことで言い争うのは、技術者をバカにしてんのかと思いますね。
  （途中省略）
  （転送メールアドレス≒楽天が過去言ってたメールフォワーディング機能が）技術的に可能か不可能かだけが重要だし、根拠もないのに安心してくださいとかナメてんのか。
  
  （いずれもカッコ内は筆者が追加させていただいております）

上の最後の引用の「技術的に可能かどうかだけが重要」ってのは、わかるんだけど、でも個人的にはやや同意しかねるところ。というのはメールアドレス秘匿の技術的可否は重要だが、それと同じくらい「そもそも顧客のメールアドレスは誰のものか？」っていうビジネス的側面も重要だから。

• 「お客様の情報としてのメールアドレス」を楽天市場の出店店舗には所有も閲覧も許さないままで、注文／受注／決済／在庫引き当て／梱包／発送／到着確認／その間のトラブル対処（誤注文とか在庫切らしたとか）、という一連の流れをすべての店舗がこなせるようなサービス／システムを楽天市場が店舗に提供することが技術的に可能かどうかという問題。
• そもそも「お客様の情報としてのメールアドレス」は誰のものなのか」という問題（ビジネス的な意味での情報の所有権/利用権/管理責任の所在）
• 技術的にどうかというところに戻ると、SMTPのしばりのなかでどこまでできるんだろう。メールアドレスをコロコロ変える人多いけどそんときのエラー処理はどうなるんだろ。それに店舗側は店舗側で楽天謹製ではない通販管理システムみたいなの（たとえばこんなの）を使ってたりするから、楽天市場側で「楽天市場側のシステムの範囲内では技術的に可能だから」という理由だけで無茶されると店舗側のオペレーションがガタガタに崩れかねなかったりする。これって単なる技術的問題の側にもくくれるし、ビジネス的な問題の側ともいえなくもない。

こういう風に書くと論点がずれ気味になってしまうんだが、それでも、技術面以外を無視すべきじゃないと思う。いまだ発展途上のこの業界では特に。

ここでちょっと視点を変えて、ここ数日間ではなく数年間の長いスパンでの流れをものすごくざっくりとまとめると、次のような感じだろうか。

1. 業界トップであるがゆえに完全には達成できそうにないことを約束せざるをえなかった組織
2. しかしそれを求めたのは一般ピープルによる空気感
3. 時間が経ったところで「やっぱりできない（できてない）んじゃん」と無駄に煽る人々（←いまココ）
4. 「1件10円で販売してるんだ！」とウソ大げさ紛らわしいタイトルで釣るGIGAZINE（←論外）

こんなんで誰が幸せになるんだろうなあ。 そういえば、「宙に浮いた年金」と「数ヶ月でクリアにします」大臣発言とやっぱりできてない今現在、という状況と似てる。

「とにかく自分のメールアドレスを守りたい（何からだ？）」ということであればそれは「インターネットで買わなきゃいい」ってことでファイナルアンサーだと思う。サザエさんに出てくる三河屋に来てもらおうよ。「御用ないですか」「今週は無いわ」「御用ないですか」「ビールひとケースとお醤油が切れそうよ」「御用ないですか。あと先月切らしてた旨い日本酒が入荷しましたけど」「じゃあそれ頂戴」みたいな酒屋さん、平成の世でもまだいるよ。少なくなったけど。いつも家にいるサザエさんみたいな主婦の存在という前提がなくても、ネットでなら非同期にこんなやりとりもできるよね新しいマーケティングだよねって話が何年も前にあったはずなのになあ、どこいっちゃったんだろ。夢だったんだよともうあきらめちゃう？

振り込め詐欺が怖いなら電話線を切るべきだし、それが嫌ならある程度の間隔で息子／娘と話をする機会を持つことで気持ち的な予防線を張るべきだし、それもできないなら自分の子育てが失敗したのだと諦めるべき。同様に、日曜の朝っぱらからやってくる新興宗教の勧誘と換気扇のお掃除の営業を軽くいなせるレベルの「断る力」がないのってヒトとしてどうなのよ。

同様に、スパムが嫌ならメールアドレスを変えるか、今日び3000円もしないウィルスチェッカーに付属してる迷惑メールフィルタをしかるべくセットすれば意外と相当数防げるはずだし、Webメール使ってるなら月額数百円のオプション料金で迷惑メールフィルタがあるわけだし、しかし友人からのメールが迷惑メールフィルタに誤検知されて困るのであれば「これは迷惑メールではありませんボタン」を押しつつも、ときどきその友人と電話で話すべき。ここまでの全てのアクションが嫌だというならもはやパソコンなど叩き壊して街に出て友人とコーヒーでも飲んで買い物したほうがいい。健康的だよ。

なんだか話がごっちゃごちゃだな。二日酔いなんだ。 そんなことよりせっかく今月末から誰でも使えるようになったYahoo!アクセス解析がいま障害発生中らしくてレポートがまったく見れん。待つしかない。

see also:

• 顧客リストは誰のものか (2005/8)
• 個人情報「過」保護が日本を破壊する (2007/3)

1. 楽天、利用者のメールアドレスを含む個人情報を「1件10円」でダウンロード販売していることが判明 - GIGAZINE
2. GIGAZINEが「楽天が個人情報を1件10円で販売している」と全力で飛ばし記事 ｜デジタルマガジン
3. 巨大帝国楽天に挑む、孤高のレジスタンスGIGAZINEの戦い: 切込隊長BLOG（ブログ） Lead‐off man's Blog
4. GIGAZINEの嘘、大げさ、紛らわしい（楽天が個人情報を売っていると言う誤報について） - ヌメのメモ帳（略してヌメモ）＠楽天 - 楽天ブログ（Blog）

まあ俺も酔っ払いブログ書くことはよくあるので人のことは言えんが。

see also:

• 痛いテレビ : ツヨシがやらかしましてね - livedoor Blog（ブログ）(2009/5)

追記

• 楽天に直撃インタビュー！　GIGAZINEの「個人情報1件10円販売」報道によるユーザーの疑問とその答えを聞いた ｜デジタルマガジン (2009/5/29)

• 難局物語：クロサカタツヤの情報通信インサイト - CNET Japan (2009/5/23)

  要はそんな代物が丸裸でシロウトに売られるということ。いかにもアコギな商売だが、これまでファイナンスの面倒を見てきた銀行が急に冷たくなったので、個人に頼み込もうとしているということだろう。

• ソフトバンク、総額600億円の個人向け社債を6月発行:ニュース - CNET Japan (2009/5/26)

とは言っても、この話はたとえば2008年の秋ぐちごろにも「．．．年を越せないんじゃないか」なんてな話がまことしやかに流れたものの結局いまがあるわけで、どうなんでしょうねえ。 でも結局はそう遠くない未来に「ドコモとそれ以外の1社」のような形で集約と業界再編が進むのであろう、に40カノッサ。

ascii.jpの記事ではGoogleが突然リリースした彗星もとい黒船のように扱われているが、実際は

1. 2008年6月には米国で招待制の形ですでに始まっていて、
2. 2008年11月には公開型に移行しており、
3. 最近見てみたら*.jpなど日本のドメインのサイトについてもデータが充実していて

というのが実際のところじゃなかろうか。ともあれ、「うちのサイトは月間何百万ＰＶでっす！」という媒体資料抱えてスポンサーへの売り込みに日々いそしんでいるネット広告の営業マンが戦々恐々とするかもしれない、という話はわからなくもない。

一方で最近の話題としては

1. 「アメーバブログってPV数の多さを誇ってるけどロボットのアクセスやRSSへのアクセスまでPVに含めちゃってるから実数の数倍になってるだけでそれなんて界王拳？」とか、
2. 「そんなこといったってPV数の定義なんてぶっちゃけ無いからねえ」とか、
3. 「さっそくGoogle Ad PlannerでアメブロのPV数を見てみたんだが、やっぱり公称値の数分の一しかないじゃんプププ」

みたいなこともありまして。

で、Google Ad Plannerに対する筆者の個人的感想を1行にまとめると、「今の段階ではデータの信頼性に若干の問題を感じるよ、alexaほどひどくはなさそうだけどさ」と思う。

ascii.jpの記事にもあるとおり、データの出所が不明瞭すぎて信頼感が無いのが問題だ。 「Google Ad Palnnerがどこからどういうデータを拾ってきてどう集計しているのか？」の概略すらよくわからないのだ。

Google Ad Plannerは、Googleツールバーからデータを集めているのか？(Techcrunch 2008/6)という記事では、
Googleの回答＝「極秘情報源の構成要素については明かさない」
記事執筆者の推測＝「ここから私は、ツールバーのデータが使われて〈いる〉と考えるに致った。」
てなことになっているが、Google公式ページのツールバーに関するヘルプには

プライバシー : 使用統計情報 - ツールバー ヘルプ

Google ツールバーで、使用統計情報を Google に提供するオプションを有効にして、Google のサービス向上にご協力ください。使用統計情報には、氏名、メール アドレス、Google アカウント情報などの個人情報は含まれず、閲覧したページの URL 情報も含まれません。

と明確にうたっている。TechCrunchの記事が憶測過ぎるのかGoogleがウソをついているのか？は、ブラウザにGoogleツールバーを入れた状態で2,3日パケットキャプチャして中身を精査すればわかるだろう。オレは試してないが。先述のとおりGoogle Ad Plannerのリリースからもう1年も経っている。Googleがウソをついてるなら既に証拠が突きつけられて炎上済みでもおかしくないはずだ。

ブラウザのツールバーで思い出したんだが、一時期（今も？）流行った、Alexa.comのアクセス数統計データのときも、問題の本質は一緒だった。

• Alexa（アレクサ）とは何か - 第1回：MarkeZine（マーケジン） (2007/3)
• Alexa(アレクサ)の統計データの問題点～さまざまな要因に翻弄されるトラフィック集計～：MarkeZine（マーケジン） (2007/10)
• 秋元@サイボウズラボ・プログラマー・ブログ: Alexa ランキング―どれだけ信頼できるか―

  訪問者のかなり多いサイトであれば、あなた自身やあなたのチームによるアクセスが Alexa ランキングに与える影響は割合としてそれほど多くないだろう。
  しかし、訪問者が少ないサイト、元々の Alexa ランキングが10万位よりも低いようなサイトの場合には、社内や関係者のブラウザに上記のツールバーを入れて、日常的にアクセスするだけで、大きくデータが変動してしまう。

  ↑特にコレに関しては筆者も大いに同意。どことは言えないが、とあるWebサイトをいろいろやってる企業のオフィスに行って、すべての業務用のPCのブラウザにalexaのツールバーが入っているのを見て正直「これはひどい」と思ったのをよく覚えている。

話をGoogle Ad Plannerに戻すが、データの出所がGoogleツールバーじゃないとすれば一番可能性が高いのがGoogle AnalyticsやGoogle Adsenseだ。しかし両者ともすべてのサイトで採用されてるわけでもないしなあ。

とにかく、筆者が得られる範囲の正確なサンプルとして月間450万PV程度の手ごろなサイトのGoogleAnalyticsデータとGoogleAdPlannerのデータをざっとつきあわせてみたのだが、PV数では10%程度の差だったが、UU数では30%以上、平均滞在時間は2倍くらいの差が出ていた。これってどうなのよ。

追記

ネタフルさん、PV数で3倍のひらき。「そんなにない！　ナイナイナイ！　ナイナイシクスティーン！」とのこと。

[N] 「Google Ad Planner」で見るとネタフルは月間380万PV (2009/5)

で、ちょっと探してみたらネタフルも出ていたんです。「ちょwwwなにやってんのwww」みたいな驚きがありつつPVを見たらなんと、3.8Mと。さんびゃくまちじゅうまん！？　イスからずり落ちましたよ！ そんなにない！　ナイナイナイ！　ナイナイシクスティーン！ 最近のネタフルは月間120万PVで推移しているので、明らかに自分の感覚と違う数字なのですが、もしかしたらと思ったのはRSSフィードの広告です。 ということで、ちょっとGoogle AdSenseから4月の数字を引っ張りだしてみると、確かに「コンテンツ向け AdSense」と「フィード向け AdSense」を足してみると、380万PV弱になるのですね。 じっちゃん、謎が解けた！ ということで、モバイルの数字は入っていないけれど、RSSフィードのAdSenseの表示回数は含まれている、ということのようです。

• 医薬品通販規制、「離島」「継続使用」のみ認める経過措置実施へ　(Internet Watch 2009/5/22)
• パブコメも効果なく議論終了、医薬品ネット販売規制へ - 楽天は訴訟検討も(マイコミジャーナル 2009/5/22)
• 時事ドットコム：薬ネット販売、２年間容認へ＝パブコメ８割が「規制反対」－厚労省 (時事通信 2009/5/22)
• 「このままではPSE法の二の舞」　医薬品ネット販売継続求め国会議員と有識者らアピール (ITmedia 2005/2/21)
• J-CASTニュース : 楽天、三木谷社長が暴露した薬剤業界の大口献金　「医薬品ネット販売規制」と関係はあるのか？ (J-CAST 2009/5/8)

とりあえずケンコーコムの株価チャートでも貼っておくか。今後どうなるんだろね。

それにしても、年金問題やら医薬品のネット販売禁止やら逆に登録販売業者制度やらそのたもろもろ多忙を極め、とどめがこの新インフルエンザ。舛添さんはそろそろ過労で倒れるんじゃないかってのはもう誰もが薄々感じてると思うんだがとにかく誰かどうにかしてくれよと。

ASCII.jp：“満足度日本一”の講師が教えるECサイト繁盛の極意 (ascii.jp 200905)

で、現物のサイトを見てみたんだが、 どうみても最近よく見かけるページ構成でしかありません。 「一息ついたところでなぜか必ず自己紹介」とかそういうの。 本当にありがとうございました。

• 現物のサイト
• 比較対象の例

ついこないだ、こんな記事がでた。

日本気象協会など、「天気予報API」を非営利目的限定で無償提供 (Internet Watch 2009年5月)

これは要するに、

1. 本来なら月額数万円で提供している天気予報情報のXML形式での提供サービスを、
2. 販売促進のため（？）に限定的に無償で提供するので希望者は応募してね

さっそく、APIを使ったサンプルウィジェットを試してみた。 ウィジェットの見た目のクオリティはどうでもよくて（サンプルだし）、 問題は、APIの中身である。

ウィジェットを稼動させつつパケットを観測してみたら、こんな通信がなされていた。 （一部省略＆伏字してます）

（HTTPリクエスト）
GET http://w001.tenkiapi.jp/dc05a986240dd621e2d695a3a89f11906dbcd807/daily/?p1=4410&p2=today HTTP/1.1
Referer: app:/Weather.swf
x-flash-version: 10,0,22,87
User-Agent: Mozilla/5.0 (Windows; U; ja-JP) AppleWebKit/526.9+ (KHTML, like 
Gecko) AdobeAIR/1.5.1
Host: w001.tenkiapi.jp

（レスポンス）
HTTP/1.1 200 OK
Date: Mon, 18 May 2009 **:**:** GMT
Content-Length: 484
Content-Type: application/xml
Server: Apache
X-Powered-By: PHP/5.2.9

<?xml version="1.0" encoding="UTF-8"?>
<forecast areaCode="4410" date="2009-05-18" time="11:00:00">
 <daily dateName="today" date="2009-05-18">
  <wDescription telop="111"><![CDATA[晴]></wDescription>
  <temp min="" max="27" />
  <probPrecip time="00-06" precipCode="" prob="" />
  <probPrecip time="06-12" precipCode="" prob="" />
  <probPrecip time="12-18" precipCode="0" prob="10" />
  <probPrecip time="18-24" precipCode="0" prob="10" />
 </daily>

RESTでXMLを取得するタイプの、最近よく見かける一般的なAPIのようだ。 URLの途中の40バイトの16進数がいわゆる「API利用キー」なのだろう。 別なネットワーク上で別のマシンにインストールしてみたけど APIキーは変わらなかったので、インストール単位ではなく 開発者側の利用申請の単位で割り当てられるキーと思われる。

なお、「サンプルソフトの逆アセンブルとかはすんなよ」的なことが注意書きに書いてあったが、 サンプルソフト自体を触った覚えはまるでない。途中のスイッチで通信をキャプチャしただけなので念のためご了承ください。

なんのこたあない。「晴れ」「雨」とか、最高気温、最低気温、6時間ごとの降水確率。つまり、気象庁のホームページや局番なしの117で聞けるのと同じレベルの、気象庁予報部という行政機関が広く公表した情報そのものにすぎないじゃないか。

こんなもののどこに、1契約あたり月額数万円の付加価値があるというのだろう？
（地震速報とかナントカ指数とかそういう特殊モノは除く。ここで言っているのはあくまでも「今日／明日／週間の一般的な天気予報の情報」です）

むしろ、「非営利なお試し」でよければお天気の森田さんがやってる会社が出しているXML形式の天気予報（の一部）を使うほうが、意味不明な審査などがまったく無くて、お勧めである。いやまじで。

天気予報をRSSでお届けする「ひとくち予報 in Feed」
http://feedproxy.google.com/hitokuchi_4410
（↑FirefoxやIE7で見ると、Atomフィードとしてレンダリングされて見えてしまうので、ブラウザの「ソースを見る」で見てみましょう。上のAPIとほとんど変わらない形式で天気予報の情報が載っている部分が見えます。下記参照）

（天気予報のXMLの部分は最初に紹介したAPIとほとんど変わらないの図。
タグ名しか変わらん。日付が違うのはこれを取得した日が少し違うだけです。）

<wm:forecast term="kyo_asu" announce="2009-05-19 17:00:00">
  <wm:area>
    <wm:prefecture>東京都</wm:prefecture>
    <wm:region>東京地方</wm:region>

    <wm:city>東京</wm:city>
  </wm:area>
  <wm:content date="5/20" wday="Wed">
    <wm:weather>晴れ</wm:weather>
    <wm:temperature unit="℃">
      <wm:max>27</wm:max>
      <wm:min>18</wm:min>

    </wm:temperature>
    <wm:rainfall unit="%">
      <wm:prob hour="00-06">10</wm:prob>
      <wm:prob hour="06-12">0</wm:prob>
      <wm:prob hour="12-18">0</wm:prob>
      <wm:prob hour="18-24">10</wm:prob>
    </wm:rainfall>

  </wm:content>
</wm:forecast>

それにしても、初期費用10万円からでリクエスト数制限のあるこのAPIの利用料金って、サーバー運用費用？回線費用？アプリの開発費？ それとも、利益？まさか。財団法人という立場で必要以上の利益を取るのはまずいっていうのは漢字検定協会の件がいい例なわけで。

FeedBurner使えばいいじゃんとか言いたいのではない。膨大な量の気象衛星画像の解析データとか言うんならいざしらず、天気予報のAPI(XML)が提供する情報は、1地点あたり数百バイトのXMLにすぎない。それが1都道府県あたり2地点か多くて4,5地点の計200地点にも及ばない程度。今日明日の天気予報＆週間天気予報という一定のフォーマット。更新頻度は日に数度の決まった時間。そして情報の中身を考えるのは自分じゃなく気象庁。

そんな程度の要件の情報配信システムに「月額数百万の運用費がかかかるんですよ奥さん」とか言ってると、楽天やYahooやはてなやmixiやニコニコ動画その他各種のポータルサイトをやってるようなレベルの連中の失笑を買うんじゃなかろうか。実際本当に、システム規模、複雑さ、運用面、すべてからみてもたいした額にはなるまい。

長々と傍証を挙げてしまったが、要するに、気象庁のWebサイトで出ているHTML形式の天気予報を、XML形式でもそこに配置し、それにあわせて必要に応じてサーバー増設するだけのことで、それは税金でまかなえないような額ではまったくないはずってことでファイナルアンサー。（or サーバ増設ではなくCDN業者にアウトソーシングでも可）

なお、受益者負担の考え方があるべきだとか言ってる人は、いまだにオープンリールの磁気テープをバイク便で運んでいたり、64KのINS回線を速い！とか言いながらありがたがって使っていたりするのだろうか。その時代ならば「受益者側が少なくともそういう実費ぐらい負担しろ」という話はわかるけどな。それから受益者負担に関するよくあるたとえが「高速道路だって利用料払うのが当然」というやつだが、このGWで絶賛大渋滞の「ETC/休日/1000円」によって失った高速料金と得られた経済効果とどっちが大きいと考えるのかと。それがインフラってもんだろ。 そういえば、高速道路は中途半端な値下げより無料化が一番経済効果が高いという試算結果を国土交通省が握りつぶしていたのを察知したのは民主の馬渕議員だったそうで相変わらずＧＪ。 dankogaiのこの書評でも同様のことになっている。

農作業と天気予報は密接に関係している。だからこそヤンマーディーゼルは「ヤン坊マー坊 天気予報」としていつまでたってもＣＭを出し続けている。 さっき行ったコンビニでお兄さんが首からぶら下げていた分厚いタッチパネルは発注端末である。商品ごと直近の売り上げ状況とともに天気予報が表示される。 天気と客足は密接に相関するから商品の注文数の見極めに天気予報は欠かせない。 スーパーマーケットでもやはり天気予報が重宝される。日持ちしない肉や魚を扱う業種では雨で客足が鈍ることによる商品廃棄ダメージを無視できない。この悩みは外食産業も同じである。 トラックなども天気によって配達スピードが変わってしまいがちなので予報に応じた調整が必要だ。寒冷地ではスタッドレスタイヤやチェーン等の準備を怠るとと事故ってしまう。逆に天気がいいのにそんなのつけてると燃費が悪くなる。

このように、今日、明日、向こう1週間の天気予報というものは、世の中の身近な経済活動と意外なくらい密着しているインフラサービスである。

んなこたぁ誰でもわかっているからこそアメダスだの衛星だの気象台だのスパコンだので一生懸命予報を作っているわけだ。それが天気予報というサービスのＱＣＤで言うところのクオリティとコストの部分。税金でまかなわれている貴重なＣ（コスト）で気象庁がなんとかがんばっている。 がしかし、Ｄ（デリバリー）の部分で、なぜか変な財団法人が2個ほど挟まっている。なんなのこいつら？

そんな奴ら無視して、気象庁（の予報部）は、自分の出す予報のうちのせめて「今日明日の天気と週間天気」といった一般的な予報は、HTMLはもちろんXMLで自分のWEBサイトで何の制限も無く即時公表すべきである。その使われ方が営利目的か非営利目的かは問題ではなく、どんな形で使うかはユーザーが決め、工夫し、より広い範囲の競争原理を働かせるべきだろう。それが情報インフラというものだ。法律的、技術的、経済的にみてこれが不可能な理由はどこにもない。なんでやらないのってそりゃ、財団法人日本気象協会や財団法人気象業務支援センターや既存の民間の気象情報会社に気を使っていらっしゃるのがミエミエすぎる。 なお、既存の気象情報企業は気象庁のWebサイトでHTMLで天気予報を流そうとしただけで「民業圧迫」と騒いだ前科もある。

1. 財団法人日本気象協会は、生き残りたければ、いち民間気象会社と同様に自前の気象予報やあるいは気象庁発表の天気予報になんらかの付加価値をつけたうえで商売することに専念すべきだろう。ただし財団法人の立場での利潤の追求ってのは漢字検定協会の一件からみてもかなり微妙だけどな。 とにかく、どうにかして税金で作られたはずの気象庁発表の情報を右から左にそのまんま流すだけのことで金取れる状況を当たり前の既成事実にしたいのだろうが、それは税金でやってる気象庁が無料でやれちゃう（やるべき）ことなのでジタバタせずにご退場いただきたい。
2. 財団法人気象業務支援センターは、気象予報士の資格試験の取り回しとかそういうのだけをやってればいいんじゃないの？気象情報の配信業務そのものは、通信技術の進歩によって支援センターのような専門組織の必要性を失っている。役目を終えたのだ。おつかれさん。
3. その他もろもろの、気象庁の予報を再販するだけのビジネスに頼っている民間気象情報会社は、今後も独自の付加価値を生み出せないのであれば、業界再編なり淘汰なりされるべきだろう。それは電気冷蔵庫の普及によって衰退した氷屋や、携帯電話の普及によって消えた公衆電話みたいなものである。

話がとぶが、既存の財団法人＆民間気象情報会社＆気象庁という行政機関のトライアングルがかもしだすナアナアな関係は、例の、医薬品のネット販売禁止の状況と似ているところがある。

• 「ネットで薬が買えなくなる？」～厚労省に聞く改正薬事法問題 (Internet Watch 2009/4)
• 厚労省のへたくそな後出しジャンケンに後藤氏（ケンコーコムの社長）と三木谷氏（楽天）が激怒 (2009/5)

薬剤師団体と厚生労働省は、「医薬品は専門家（薬剤師）が対面で販売するものである」という「もうそういう路線で決まった既成事実」を錦の御旗にして勝てば官軍モード。対する楽天とかケンコーコムとかは負ければ賊軍。っていうか飯が食えなくなりかねない。そのくせコンビニでは薬剤師でもないのに「登録販売業者」としてパブロンもバファリンも買えるようになるそうだ。しかし登録のための試験を受けるのは店長くらいで実際に客に応対するのはただのバイトの高校生という現場が眼に浮かぶ。要するに客と薬剤師の対面でも客とネコの対面でもそれは「対面販売」なのだというオチ。

一方、気象関係の財団法人＆吹けば飛びそうな民間気象会社は、「気象庁が出す天気予報をコンピュータ的に使いやすい形＝XML＝で得るには金がかかるものなのだ」という「そういうものなんだよ的な既成事実」を作り出そうとしている。実際はHTMLもXMLも大差ないどころかXMLのほうが作りも見た目も単純ですらあるのにね。

日経ビジネスの記事に 対立の構図は、「薬剤村」vs「ネット村」。無論、薬剤村には、法令を作った厚労省も含まれる。 というのがあったが、これを天気予報に関する構図にあてると、

「わかってて傍観する気象庁と、気象庁の予報を再販する既得権を守りたい財団法人と、策も発展も無くやはり気象庁の予報を再販するだけの民間気象情報会社」
ｖｓ
「．．．．」（Web、ＩＴ系、その他気象情報のユーザー業界の人が誰もいない。笑）

という状況。医薬品ネット販売禁止の是非の一件はネット側の「出遅れ」があったことは業界の誰もが認めることだろう。どこか似たような歴史が、また、繰り返されようとしている気がしてならない。

• もしも天気予報がXMLだったら − その１ XMLとは？ (2004年3月)
• もしも天気予報がXMLだったら − その２ できない理由 (2004年3月)
• 気象庁の天気予報情報をメタデータ化→XML 形式にしてみた :: Drk7jp (2005年7月)
• 天気予報のXMLはFTPでGETできる。ただし月額10万円超 (2005/8)

• 性犯罪被害者名も裁判員候補に開示、情報流出懸念の声 （読売新聞 2009/5）
• 裁判員制度による深刻なプライバシー侵害 (雑種路線でいこう2005/5)

追記：
性犯罪被害者の氏名開示問題について（事実確認とお詫び） - キリンが逆立ちしたピアス(2009/5)
なるほど。でもやっぱり運用にたよる面があってグレーな感じだよなあ。