まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

タグ:analytics

以前に紹介した SaaS 型のデータ解析サービス IBM Watson Analytics は強力な解析エンジンが安価で使えて、面白いサービスだと思っています:
2017040501



ただちょっと不便に感じたのは、データのインポート方法でした。手元に CSV などのファイルがあれば Watson Analytics 側に用意された機能でインポートできます。またデータが Box や Twitter などのクラウドに公開されたものであれば、やはり Watson Analytics に用意された機能で取り込むことができました:
2017040502


しかし現実的にはデータベースサーバーから直接取り込むことができると便利です。更に言うと、インターネットに公開されたデータベースサーバーではなく、プライベートネットワーク内にあるデータベースのデータを簡単に取り込むことができると、プライベートデータを(いちいち CSV にしてから手動インポートする必要がなくなって)便利なのですが、現在 Watson Analytics 単体にそこまでの機能は提供されていません。


しかし、単体では提供されていなくても、IBM Bluemix から提供されるいくつかの機能を組み合わせることで上記の要件は可能になります。具体的には Secure Gateway サービスと Data Connect サービスを使います。Secure Gateway でプライベートネットワークのデータベースに対してセキュアなトンネリングを貼った上で Data Connect を使い、そのプライベートデータベースと Watson Analytics との間での自動データマイグレーションが実現できます(そのマイグレーションを定期的に実行するようなスケジューリングまで含めて可能になります)。






以下に実際の手順を紹介しますが、実際にこの手順を行うにはプライベートネットワーク内のデータベースに加えて、IBM Bluemix および IBM Watson Analytics 両方のアカウントが必要です。そして IBM Bluemix では Secure Gateway と Data Connect の2つのサービスインスタンスが有効になっている必要があります。無料版にサインアップするなどして、あらかじめご用意ください。


まずプライベートネットワーク内のデータを確認しておきます。今回対象とするのはプライベートネットワーク内のデータベースサーバーで管理されている(仮想の)人事情報とします。名前(name)や年齢(age)、収入レベル(income)、容姿(looking)、血液型(blood_type)、出身地(prefecture)といった情報が格納されているものです(注 乱数で生成した偽データです)。これは認証は当然ですが、現時点ではプライベートネットワーク内からのアクセスしか許可していないものです。目的はこれらのデータを(一度 CSV ファイルにして取り出して手動アップロードしたりするのではなく)Watson Analytics で解析可能なデータとしてシステマチックにインポートすることとします:
2017040513


では実際の手順を紹介します。まずは Secure Gateway でこのプライベートネットワーク内のデータベースを IBM Bluemix 環境からアクセスできるようにします。その手順はこちらを参照してください。
SecureGateway で Bluemix とプライベートネットワークをセキュアに接続する


次に Secure Gateway で参照できるようになったプライベートデータを Data Connect のデータセットとして定義します。この手順についてはこちらを参照してください。
Data Connect サービスでデータベースをマイグレーションする


ここまで完了したら、次は Data Connect の接続先として利用できるよう、Watson Analytics を追加します。Data Connect サービスのダッシュボード画面左メニューから "Connections" を選択し、画面右上の "Create New" をクリックします:
2017040501


接続先のデータベースタイプの選択画面では "IBM Watson Analytics" を選択します:
2017040502


詳細設定画面に移動しますが、ここで設定する項目は接続名称を入力するだけです。最後に画面右上の "Create Connection" をクリックします:
2017040503


この接続情報が保存される際に IBM Watson Analytics への認証が行われます。IBM Watson Analytics を利用している IBM ID とパスワードを指定してログインしてください:
2017040504


正しく有効な ID が確認されると、Data Connect の接続情報として IBM Watson Analytics が追加されます:
2017040505


では作成した Watson Analytics にプライベートデータベースからデータをマイグレーションします。引き続き Data Connect ダッシュボードの画面左メニューから "Activities" を選び、右上の "Create New" をクリックします:
2017040506


まずマイグレーション元を指定します。あらかじめ作成してある Secure Gateway 経由の(プライベートデータベースの)データセットを選択します。選択したら画面右上の "Copy to Target" をクリックします:
2017040507


次にマイグレーション先を指定します。今回のマイグレーション先は IBM Watson Analytics なので、Connections から上記で定義した IBM Watson Analytics の接続名を選択します。このままマイグレーション実行スケジュールの指定("Schedule Activity")も可能ですが、まず1回手動で実行してみることにします。画面右上の並んだボタンから "Run" をクリックします:
2017040508


指定したとおりの(プライベートデータベースから Watson Analytics への)マイグレーション処理が実行され、アクティビティとして記録されます。なお、このアイコンから実行スケジュール(定期実行など)を編集することも可能です:
2017040509


実際にマイグレーションが行われたかどうかを確認してみます。改めて IBM Watson Analytics にログインすると、元々は存在していなかったデータセットが作られているはずです。これをクリックして、実際に解析してみます:
2017040510


解析テンプレートが表示されます。いくつかありますが、"What is the trend of looking over age by blood_type?"(血液型別に年齢と容姿にどういったトレンドがあるか?)が面白そう(笑)なので選択してみます:
2017040511


この解析用の画面に移動します。画面左側に年齢ごとの容姿の推移が血液型ごとの折れ線になって表示されます。また画面右にはこれらの分析からの発見として、「43歳の収入が一番高い」とか「年収をトータルすると AB 型が一番低い」といったインサイトも併せて表示されています(※繰り返しますが、乱数を使って生成した偽データです):
2017040503


特別何もしなくてもデータを与えるだけでここまで分析してくれる Watson Analytics もすごいのですが、その Watson Analytics に直接プライベートデータや社内データをセキュアにマイグレートしてくれる Secure Gateway や Data Connect と併せて利用することで、より便利に大事な情報を簡単に解析できるようになると感じます。


普段は IBM Bluemix の関連で IBM Watson の API を紹介する機会があります(このブログでも何度か扱っています)。これらの多くは Watson Cognitive と呼ばれる言語や画像などを対象にした認識/分類を行うタイプのエンジンです。

一方で、Cognitive 以外の Watson もあります。その1つが Watson Analytics と呼ばれるもので、これは「データ分析」を目的としたエンジンです。現在では API というよりも、クラウド上のツールとしてその機能が提供されています:

http://www.ibm.com/software/jp/cmp/watsonanalytics/
2017020100


この Watson Analytics ツールは、誰でも申し込みから 30 日間は無料で使うことができます。というわけで自分も申し込んで、どんなものなのかを試しに使ってみました。

まず上記ページの「無料トライアルを試す」から申し込みを行います。しばらくすると以下のようなメールが送られてくるので、「ログインする」をクリックして、申込み時に指定したメールアドレスとパスワードで Watson Analytics サービスにログインしてください:
2017020201


Watson Analytics サービスにログインした直後はこのような画面になります:
2017020201



さて、今回このサービスを試用するにあたって、どんなデータで何を試すかを考えました。そこまでアナリティクスに詳しいわけでもなく、そこまで詳しい人を対象に紹介するつもりもないので、自分の守備範囲の中で試すことにします。 というわけで、以前にこのブログで紹介したことと同様のことを Watson Analytics サービスで挑戦してみることにします:

dashDB の R Studio を使ってデータの相関関係を調べる
http://dotnsf.blog.jp/archives/1047597688.html


ここで紹介しているのはセンサーとみなしたラズベリーパイから3種類(CPU 温度、CPU 負荷率、サインカーブを描く値)のデータを1秒おきに取り出したものです(取得済み)。そしてこの3つのデータの相関関係有無を調べてみることにします。同ブログエントリ内でも紹介されていますが、取得済みのデータは CSV で公開しているので、同じものをそのまま使うことにします。ここからダウンロードしておいてください:
https://raw.githubusercontent.com/dotnsf/RPDATA/master/RPDATA.csv


なお、この CSV ファイルをそのままエクセルで開くと、最初の方はこんな感じになります。1行目はヘッダでデータは2行目以降。B列が CPUTEMP(CPU温度)、C列がCPULOAD(CPU負荷率)、そしてD列がSINE(サインカーブを描く値)になっています。A列のIDはユニーク文字列ですが、今回は使いません:

2017020211


ちなみに CPUTEMP と CPULOAD を折れ線グラフにするとこんな感じ。途中でわざと負荷をかけたので、山が1つ出来ていることが見てとれます:

2017020212


一方、同じ期間中の CPULOAD と SINE とを比較したのがこちら。SINE は CPU の負荷とは無関係に、一定のリズムでサインカーブを描いていることがわかると思います:
2017020213


ここまで見た上で意識していただきたいのは以下のことです:
・ CPUTEMP が上がると CPULOAD も上がり、CPUTEMP が下がると CPULOAD も下がる
・ SINE にはそういった相関関係が CPUTEMP にも CPULOAD にもない
・ いまグラフの形を見たからそういうことに気付くことができた
・ また CPUTEMP は CPU 温度で CPULOAD は CPU 負荷率だった。つまりどちらも CPU に関連するセンサー値だった。そこまで理解した上でこの数値やグラフを見ているから、これらには関係があるように推測できた


つまり、人間の目でグラフの形を見比べた上で、なんとなく「形が似ている」と気づけたわけです。また「同じ CPU に関する値だったと分かっていたから、それらには関係があるだろう、と推測できた、ということです。

では同じことを目で判断せずに、加えて事前に同じ CPU の情報であることを知らない Watson が、数値データの羅列を与えただけで気付くことができるでしょうか? ということを今回の調査テーマとしてみることにします。


改めて、この CSV ファイルを Watson Analytics にロードします。新規データとして追加するので "+ New data" と書かれた箇所をクリックします:
2017020201


Watson Analytics には標準でサンプルデータが用意されているのでそれを使うことも出来る上、Box や OneDrive、Twitter などのソーシャルサービスから条件を指定してデータを取り出すことも可能になっています。今回は手元にある CSV ファイルを元にデータを生成したいので、"Local file" タブを選択します:
2017020202


このような画面になったら「Browse」をクリックして、先程ダウンロードした RPDATA.csv ファイルを指定します:
2017020203


こんな感じの画面になって RPDATA.csv ファイルがアップロード候補に加えられている状態になりました。このまま「Import」をクリックしてアップロードします:
2017020204


元の画面に戻りますが、いまアップロードした RPDATA.csv が分析データとして追加されていることが分かります。この画面では "Processing..." と表示されています。これはアップロードは完了しているのですが、分析するための処理を行っている途中であることを意味しています。このままもうしばらく待ちます:
2017020205


下図のような状態になると分析処理も完了したことになります。このアイコンをクリックして、実際の分析結果を確認してみます:
2017020206


(RPDATA に対して)どんな分析をするのか、という選択画面が表示されます。上述したように、今回は値の相関関係を調べたいので、"What drives SINE?"(何が SINE に影響しているのか?)を選びます。SINE との影響だけを調べたいわけではないのですが、この "SINE" の部分を切り替えて調べることができるので、今回はこの観点で各種データの影響要素を調べることにします:
2017020207


"What drives SINE?" をクリックすると、しばらく画面構成の処理で時間がかかるのですが、ロードが完了するとこのような画面になるはずです。結論として、"SINE" に関しては "No key drivers were found."(特に影響要素は存在しない)と表示されています。まあ答をわかっている立場からすると当然の結果なのですが、解析結果としても同じ結論になっていることが分かります:
2017020208


もともとの目的にもよるのですが、例えばこのセンサーモジュールの故障やエラー、利用不可になる予防保全をしたい場合などは CPU 利用率があまり高くない状態をキープしていてほしいものです。センサーが PC などと直結していれば、その PC からセンサーの CPU 状態を把握できることもありますが、そうでないケースも珍しくありません。そうなると「センサーの CPU 状態を直接モニタリングする」ことは簡単ではないことになります。これをどうにかできないでしょうか?

では今度はこの "SINE" を "CPULOAD(CPU 負荷率)" に変更して、CPULOAD に影響を与えている要素があるかどうかを調べてみましょう。画面左下の "SINE" と書かれた箇所をクリックし、"CPULOAD" を選択します:
2017020209


同様にして少し処理時間で待つことになりますが、画面のロードが完了するとこんな結果になりました。"CPULOAD" は "CPUTEMP" の影響を受けている、という解析結果が表示されています!
2017020210


もともとは CPU 負荷率の状態をなんとか調べることができないか、という課題があったわけですが、今回の結果によって、このセンサーモジュールでは CPU 温度と CPU 負荷率との間に相関関係があることが統計的にもわかったことになります。そして CPU の温度は直接外部から測定することもできるものなので、CPU の温度を測定していれば、CPU の負荷が高くなっているのかどうかを判断することができる、という可能性がでてきたことになるわけです!


くどいようですが、我々のように事前にグラフの形を見比べたわけではなく、またこれらがどちらも CPU に関する値である、という情報が事前に与えられたわけでもない中での自動解析結果であることを考慮すると、「ここまで簡単に分かっちゃうのか・・」という印象でした。

今回のデータは ID を除けば3種類しかなく、人間の目や脳でもわかりやすいものでした。ただこれが数10種類ものデータを含むもので、その中から存在するかどうかもわからない相関関係を見つけ出すというのはなかなか大変なんだろうなあ・・・と思うのですが、このツールはその作業負担を大幅に軽減できるものだと思います。


というわけで、このような IBM Watson Analytics サービスが無料で試せるというのはなかなかすごいのではないかと思っています。皆様も興味があれば是非試していただいて、手元にある数値データを使って簡単に解析できるという体験をしていただきたいです。



今年もマンホーラー実態調査の結果発表の季節がやってまいりました! 2016/Jan/01 から 2016/Dec/19 までのマンホールマップと連携した Google Analytics とアクセスログ、そして実データを使って、2016 年のマンホーラー(注 マンホールが好きな人)の実態と傾向を浮き彫りにする、というビッグデータ解析企画です。ちなみに昨年と一昨年の結果はこちらから参照ください:
 2014 マンホーラー実態調査
 2015 マンホーラー実態調査


2016 マンホールマップ利用動向

2016122002

1回のセッションでの平均ページ数は 4.69、直帰率は 53.53% 、平均セッション時間は 4 分 43 秒でした。昨年は 4.65 と 56.77%、4分22秒だったので全ての数字が改善の方向で推移しています。昨年と比較して、マンホールマップを訪れたユーザーが、より多くのページに移動して長く楽しんでいただいている、ということになります。直帰率 50% 切りも視野に入ってきました。

なお、アクセス数は非公開ですが、昨年比で倍近いページビュー数があった、ということを報告しておきます。


利用者の国、言語

今年は 62 の国/地域からマンホールマップをご利用いただきました(昨年は 65):
2016122012


国別のアクセス数1位はダントツで日本ですが、2位以下は毎年変化しています。さて 2016 年はというと・・・
2016122003


2位は UK(イギリス)からのアクセスでした。なんでだろう?ポンド安でみんな旅行してた?3位アメリカ、4位ロシアあたりは上位の常連国です。 今年目立って高かったのは8位イラク、11位タイ、14位ミャンマーあたりでしょうか。水道関係者やインフラ整備で派遣されている皆様がこれらの国々で活躍されている姿が目に浮かんできます。。



日本国内の市区町村別アクセスランキング

では日本国内の市区町村別ではどのようなランキングだったかを調べてみました:
2016122004


見やすいように日本語で表にして、昨年からの順位推移を含めてみました:
1大阪市
2横浜市
3加古川市
4港区
5新宿区
6名古屋市
7(取得不可) -
8さいたま市
9札幌市
10市川市
11(東京都)中央区
12京都市
13新潟市
14千葉市
15福岡市
16世田谷区
17渋谷区
18神戸市
19船橋市
20江東区


アクセス記録一位は大阪市の2連覇。関西マンホールサミットの影響なのでしょうか?そしていわゆる「大都市」が軒並みランクを下げる中で加古川市や船橋市、市川市といった衛星都市が順位を挙げています。マンホール界では地方分権が進んでいるようです。


利用環境

利用しているブラウザ環境を同様の表にまとめてみるとこんな感じです:
1Chrome34.26%
2Internet Explorer23.34%
3Safari17.13%
4モバイル Safari11.47%
5Edge6.18%
6FireFox4.20%
7モバイル Chrome2.74%
8(クローラーボット)0.24% -
9Opera 0.17%
10Mozilla 互換0.09%


1位は推奨環境でもある PC の Chrome、非推奨環境と明確に言っているにも関わらず2位が IE、3位は Safari、ここまでは昨年と同順位です。変わったのはその下でモバイル Safari が伸びているのは iPhone 利用者が増えていることを意味しています(逆にモバイル Chrome が落ちているので Android 利用者は減っている)。このあたりはグローバルスタンダードを逆行しています(苦笑)。また昨年は 0.55% だった Edge が FireFox を抜いている点も見逃せません。。

なお、10位の "Mozilla 互換" というのは、ネットテレビだったり、ゲーム機だったりが考えられます。まだまだ少ないのですが、いずれこういう環境も増えていくのでしょうか?テレビだと画面が広くて便利そうではありますよね。



まとめ

以上の内容から 2016 年のマンホーラーの実態は以下のようなものであったと推測されます:
・イギリスが EU から分離して、ポンド安に笑いが止まらない人がいる
・マンホーラーは昨年以上に世界中に広まっている。そして日本では地方分権が進んでいる
・マンホーラーは iPhone 派
・大阪熱い!
・Internet Explorer は不滅



さて、次回のブログでは 2016 年マンホールマップ蓋別アクセスランキングを発表します。2016年の MVM(Most Variable Manhole) の行方は!? やなぽんさん、3連覇なるか!? お楽しみに。


昨年、一部の皆様の熱狂的支持を受けたマンホーラー実態調査、2015 年の今年もやります! 世界最大の位置情報付きマンホール画像サービス「マンホールマップ」の 2015 年分の利用実態を調べました。

以下のデータは Google Analytics を使った 2015/Jan/01 から 2015/Dec/19 までのアクセスデータを元に作成しています。信じられない人がいるかもしれませんが、かなりのビッグデータ解析です。


2015年 マンホールマップ利用概要

マンホールサミットとマンホールナイト、2つの大きなイベントとその直後にアクセス数のスパイクが見られます。ある意味で「想定通り」の利用結果になりました:
2015122001


なお、1回のセッションで平均 4.65 ページが参照されています。直帰率は 56.77% で、平均セッション時間は4分22秒。つまり「1回見に来た人は、その後4分22秒間滞在して、その間に4~5ページ見てくれる」ようなサイトになっています。ウェブサービスページとしてはなかなかの滞在時間と近隣ページへの誘導が実現できている方だと思っています。


利用者の傾向

グーグルのプロフィール予測に基づいたマンホールマップ利用者の推定年齢はこのようになりました:
2015122002


↑順位は昨年と変わっていません。意外と(?)若い層がマンホールマップを使っていると見るべきか、マンホールマップを使っている人は(グーグル的に)「若い!」と推測・分類されるような行動プロフィールなのか、その辺りは謎ですが、マンホールマップおよびマンホーラーの将来は明るいと言えます。

次に利用者の性別です:
2015122003


↑性別に関しても若干男性が多いままで、「合コンが成立するくらいの男女比」になっています。非常にバランスよく推移しています。ただし、出会いの場になっているかどうかは知りません。

既存ユーザーと新規ユーザーとのバランスもいい感じでした:
2015122007


↑既存ユーザー 41.3% に対して、新規ユーザーが 58.7% 。この差は昨年よりも開きました。新しいユーザーの開拓にも成功し続けていることが分かります。

最後に利用者の趣味・興味分野を見てみましょう:
2015122004


↑これは先程の推定年齢にも関係しているかもしれませんが、マンホールマップ利用者の趣味・興味分野が比較的アクティブなものになっています。それもあって、実年齢はともかく若いと判断される人の趣味になっているのかもしれません。加えて、マンホーラーの IT 率は相変わらず高いようです。


利用者の国、言語

マンホールマップのアクセスログに残されたユーザーエージェント情報を元に、この一年間でどのような国から利用されているのかを図示しました。1回でもアクセスが記録されていた国には青っぽい色が付けられています:
2015122005


主要国はほぼ含まれているといっても過言ではありません!

実は日本を含めて65ヶ国からのアクセスが記録されていました。国別アクセス数では日本がダントツですが、では2位以下はどのようになっていたのでしょうか?

2015122006


↑2位はアメリカ(昨年7位)でした。3位は(おそらくクローラーボットなど、ヘッダ情報のないアクセスだったため)国名が取得できないアクセスだったので無視します。昨年2位のロシアは実質3位でした。 なんというか、世界中から参照されていることを実感します。

ということはマンホールマップの国際対応を意識する必要が出てきます。マンホールマップはリリース当初から英語対応されていますが、更なる国際化を急ぐ必要があるのでしょうか? ではどの言語に対応すべきか、という問題をアクセスログに残された言語設定から見てみると、こんな結果になりました。ロケールの設定方法が統一されていないので少し見にくいかもしれませんが、生データだとこんな感じです:

1ja-jp日本・日本語
2ja日本語
3en-us米国・英語
4(取得不可) 
5en英語
6pt-brブラジル・ポルトガル語
7zh-tw台湾・中国語
8ruロシア語
9zh-cn中国・中国語
10cCロケール(英語)
11en-gb英国・英語
12esスペイン語
13de-deドイツ・ドイツ語
14en-au豪・英語
15es-esスペイン・スペイン語
16frフランス語
17fr-frフランス語
18it-itイタリア・イタリア語
19ko-kr韓国・韓国語
20sv-seスウェーデン・スウェーデン語


↑1位と2位は日本語、3位と5位は対応済みの(米)英語、4位は取得できないものだったので無視します。 残りの順位を見ると次はポルトガル語、中国語、ロシア語対応が必要なのでしょうか? ヤバい、知らない言語ばかりだ・・・


日本国内の市区町村別アクセスランキング

次は日本国内の市区町村別アクセスランキングです:

1大阪市
2港区
3新宿区
4横浜市
5名古屋市
6京都市
7(東京都)中央区
8札幌市
9千代田区
10千葉市
11渋谷区
12さいたま市
13(取得不可)
14福岡市
15世田谷区
16川崎市
17神戸市
18新潟市
19加古川市
20相模原市


なんと1位は昨年はベスト10圏外だった大阪市! 関西マンホールサミットの影響なのでしょうか?今回のデータで、これが個人的に一番驚きました。

なお上記表では20位まで載せていますが、21位は私の家がある船橋市でした。家からも結構見ていたつもりだったのですが、20位にも入ってなかったとは・・・ マンホーラーが東京周辺に集中する傾向が少しずつ崩れて、全国的に広まりつつある感触を感じます。


利用環境

次にマンホーラーの利用環境です。まずはブラウザから。実質的に上位6つまでが順位といえる結果でした:

1Chrome30.08%
2Internet Explorer28.01%
3Safari16.08%
4Firefox8.49%
5モバイルSafari7.55%
6モバイルChrome7.14%
7(不明)0.90%
8Opera0.87%
9Edge0.55%
10Amazon Silk0.06%


1位は推奨環境でもある Chrome でした。昨年は(非推奨環境の)Internet Explorer が1位だったのですが、地道な啓蒙活動が実りつつあるとポジティブに解釈させていただきます。とはいえまだ2位。あと Edge も9位に顔を表しています。10位のは知らないな・・・

そして OS 別だとこんな感じです。実質は上4つが順位で、5位以下は1%未満です:

1Windows49.26%
2iOS21.39%
3Android17.61%
4Macintosh9.75%
5(不明)0.96%
6Linux0.90%
7Nintendo Wii0.04%
8Chrome OS0.02%
9NTT DoCoMo0.02%
10BlackBerry0.01%


ある意味想像通りで、上位4つは昨年と変わっていません。ただ Linux デスクトップからのアクセスが思っていたよりも少なかった印象です。あとは Wii やドコモのガラケーから使っている人もいるんですね。ちゃんと見れてるのかな・・・

※BlackBerry のアクセスログはたぶん自分です


まとめ

以上の内容から、2015 年のマンホーラーの実態はこのようなものであったと推測されます:

・相変わらず女性に人気があり、新規ユーザーも増え続けている
・「若いですねぇ」とか「そんな歳に見えませんよぉ」と言われているような人がマンホーラー
・マンホーラーは世界中にいるし、日本国内でも東京一極集中から分散しつつある
・マグロが止まったら死ぬように、InternetExplorer を使ってないと死ぬ人がいる



さて、次回のブログでは 2015 年のマンホール蓋別年間アクセスランキングを発表します! 2015 MVM(Most Variable Manhole) に選ばれるのはあの人気蓋なのか!?それとも昨年のような伏兵が現れるのか!? そして期待の新人賞の行方は!!??  お楽しみに!


(追記 2015/Dec/22)
続きはこちら


IBM Bluemix を通じて提供されているコグニティブサービス(認識型人工知能)API の1つに Tradeoff Analytics があります:
2015051800


この API を理解するにはデモサイトを参照していただくのがいいと思います:
http://tradeoff-analytics-demo.mybluemix.net/

このデモサイトでは「一覧の中で、自分にあったスマホはどれか?」という命題を、その人が重要視するスペックポイントを明確にした上で候補を上げていく、というものです。

スマホはメモリは多い方がいいし、バッテリーは多い方がいいけど、そうすると重量が重くなります。でも重量は気にする人もいればいない人もいます。また価格は安い方がいいに決まっていますが、メモリやバッテリー、重量などの要素と比べて重要度が高いのか低いのか、は人によって異なってきます。 全てを満たすパーフェクトなスマホはそうそう出てこないでしょうから、結局はどの要素を重要視するかでトレードオフを考えることになると思いますが、どの要素を重要視した場合はどのような結果になるか、を判断してくれる、そんな API です。

例えば上記デモサイトを開くと、デフォルトでは以下の様な表が表示されます:
2015051801


一番上の列がヘッダで、2行目からがスマホの候補リストになっています。表の3列目以降がスペックになっていて、3列目は価格(小さい方がいい)、4列目はRAMメモリ量(多い方がいい)、5列目はスクリーンサイズ(意見が別れるところですが、ここでは大きい方がいい)、6列目はカメラの画素数(多い方がいい)、7列目はメモリ量(多い方がいい)、8列目はバッテリー容量(多い方がいい)、そして9列目は重量(少ない方がいい)となっています。このうちデフォルト状態では価格、スクリーンサイズ、重量の色が緑になっていて、今はこの3点を重要視する人にとってのトレードオフを解析する指定になっています。

もしもこれら以外の点を重要視したい場合は表右下の "View/Edit JSON" と書かれた箇所をクリックして JSON の内容を変更します。例えば「スクリーンサイズは気にしないけど、バッテリー容量は重要!」という場合は以下のように値を変更します。 まずスクリーンサイズは今回意識しなくていいので、JSON 内の columns の中で "key" 値が "screen_size" になっている項目の "is_objective" 値を true から false に変更します。この "is_objective" の値が true のものはトレードオフの考慮に含めて、false のものは含めない、という指定です。なお "goal" 値が "MAX" のものは「(メモリ量など)大きい方がいい」という値、"MIN" のものは「(価格など)小さい方がいい」という値だという指定です:
{
  "key": "screen_size",
  "full_name": "Screen size (inch)",
  "type": "NUMERIC",
  "is_objective": false,
  "goal": "MAX"
},

続いてバッテリー容量はトレードオフに新たに含めたいので、同様にして "key" 値が "battery" になっている項目の "is_objective" 値を false から true に変更します:
{
  "key": "battery",
  "full_name": "Battery (mAh)",
  "type": "NUMERIC",
  "is_objective": true,
  "goal": "MAX"
},

この状態で編集エリア右下の "Back to table" をクリックすると、価格とバッテリー容量と重量の3点が重要視指定された状態の表が表示されるはずです。なお、これら以外でも JSON を変更することで候補スマホの名称や各数値を変更することもできます。全て JSON フォーマットで指定されていることを確認しておいてください:
2015051802


重要視する項目が決まったら、画面右下の "Analyze Sample Data" と書かれたボタンをクリックして、トレードオフを計算します:
2015051803


すると画面下に以下のようなグラフが表示されて、指定した3項目でのトレードオフを考えた結果が表示されます。各スマホアイテムがそれぞれの要素を意識した時にどの位置にあるのか、ということが視覚化されています:
2015051804


例えば、ここでバッテリー項目の下限のスライダーを 1000 から 1500 近くまで移動させると、「バッテリー容量が指定値(1500)以下のものは考慮しない」という指定をしたことになり、画面上部付近にあったいくつかのバッテリー容量の少ないスマホが画面から消えます。これで更に絞込みやすくなります:
2015051805


・・・と、なんとなく「トレードオフ解析」の意味がお分かりいただけたでしょうか? IBM Bluemix で用意されているのは、このような解析を行うための(与えられた条件から、上記の結果グラフを書くための)API が用意されている、という点が特徴です。つまり上記デモサイトのようなことを皆さんの作るアプリケーションの中でも実現できるようになる、ということです。

実際にこの API を利用するには、IBM Bluemix で上記の Tradeoff Analytics サービスをランタイムアプリケーションにバインドして資格情報を確認し、利用のための username と password を取得しておく必要があります
2015051801


ここまで準備できれば API そのものは単純です。取得した username と password を使って Basic 認証を行い、https://gateway.watsonplatform.net/tradeoff-analytics-beta/api/v1/dilemmas に対して、解析させたい JSON(上記の Edit JSON をクリックして編集したもの)をポストするだけです。

成功すると、以下の様な JSON が結果として返ってきます:
{
  "problem": {
    "columns" : [ {
      "key" : "price",
      "format" : "",
        :
        (ポストした JSON の内容)
        :
  },
  "resolution" : {
    "solutions" : [ {
      :
      :
    } ],
    "map" : [ {
      "nodes" : [ {
        "coordinates" : { "x":0.0, "y":0.0 },
        "solution_refs" : []
      }, {
        "coordinates" : { "x":1.0, "y":0.0 },
        "solution_refs" : []
      }, {
        "coordinates" : { "x":2.0, "y":0.0 },
        "solution_refs" : []
      }, {
        "coordinates" : { "x":3.0, "y":0.0 },
        "solution_refs" : []
      }, {
        "coordinates" : { "x":4.0, "y":0.0 },
        "solution_refs" : []
      }, {
        "coordinates" : { "x":5.0, "y":0.0 },
        "solution_refs" : []
      }, {
        "coordinates" : { "x":6.0, "y":0.0 },
        "solution_refs" : [ "5" ]
      }, 
        :
        :
      } ],
      "anchors" : [ {
        "name" : "price",
        "position" : { "x":0.0, "y":0.0 }
      }, {
        "name" : "battery",
        "position" : { "x":4.5, "y":7.8 }
      }, {
        "name" : "weight",
        "position" : { "x":9.0, "y":0.0 }
      } ],
        :
        :
    }
  }
}

結果の JSON の細かい内容は以下のリファレンスを参照していただきたいのですが、大きく3つの箇所を参照することになります。 1つ目は "problem" で、この中にポストした JSON がそのまま記述されているはずです。つまり「この問題に対する実行結果である」ことを示しています。

2つ目は "resolutions" の中の "map" で、ここに散布図を書いた時の各点の座標(x,y)が示されており、またその座標位置に相当するアイテムがあった場合は "solutions_refs" という配列値で示されます。例えば上の例ですと ( 6.0, 0.0 ) の位置に "key" 値が "5" に相当するアイテムがある、ということになります。

最後の3つ目は "resolutions" の中の "anchors" で、これが指定した各トレードオフ要素(この例では価格とバッテリー容量と重量)が散布図上のどの位置にあるかを示しています。


後はこの結果を受け取った側でどのように見せるか、という問題になります。チャート描画の API を使ってもいいし、Canvas を使って自分で記述してもいいと思います。ここから先は開発者やデザイナーの腕の見せ所と言えます。そういう意味ではここのデモサイトはなかなか良くできてますよね。


というわけで、これまでにこのブログで紹介してきたコグニティブサービスとは少し(特に実行方法の面で)毛色が違うサービスと言えます。API 実行時に指定フォーマットの JSON を作る必要があるのが少し面倒ですが、トレードオフを意識する要素と、それらの値は大きい方が嬉しいのか小さい方が嬉しいのかの情報、そしてアイテムの一覧を JSON にしてポストすれば結果が返ってくる、というものです。REST API そのものはシンプルなのでエクセルのような表計算からも実行できると思っています(エクセルだと逆に結果の視覚化が難しいかも・・)。


なお、ここで紹介した Watson Tradeoff Analytics API について、詳しくは API リファレンスを参照してください:
http://www.ibm.com/smarterplanet/us/en/ibmwatson/developercloud/apis/#!/tradeoff-analytics
 

このページのトップヘ