ビッグデータの歴史

　操作可能な情報の増大が一定の閾値を跨ぐと制御不能になるのではないか？　という論点は目新しい考え方ではない。筆者の知る範囲でも『情報制御性爆発』（The Information Controllability Explosion.Koenig, Michael E. D. Library Journal）という論文は、1982年時点で既に図書館ネットワークの事例を使って情報ハンドリング不能な事態について論じている。1989年に発表された論文、『情報爆発』（The information explosion. E. J. Huth Bull N Y Acad Med.）を読むと、図書館員を悩ませていた問題が図書館利用者（の一部）である医療関係者をも悩ますようになっていたことが分かる。さらに、ヒトゲノム計画を推進した分子生物学や粒子加速器を利用する素粒子物理学など、大規模な科学プロジェクトは増大するデータに悩まされる専門家を増やしていった。これら大規模プロジェクトによって生み出され、増大し続けるデータをコントロールする必要に迫られ、さまざまな取り組みがなされた。日本でも東京大学生産技術研究所の喜連川優教授が中心となって2005年から情報爆発時代に向けた新しいIT基盤技術の研究プロジェクトなど一連のプロジェクトが実施されていた。

　かつて、マンハッタン計画が管理工学の発達を促し、アポロ計画がマネジメント対象の規模の問題に直面し後年のMOT（Management of Technology）誕生のきっかけを作ったように、情報爆発問題も新たな技術分野誕生の苗床になったといえるだろう。

　情報爆発という情報量増大そのものが問題だという認識に対しては2004年に発表された米GoogleのMapReduce論文（MapReduce: Simplified Data Processing on Large Clusters）や続く2006年のBig Table論文（Bigtable: A Distributed Storage System for Structured Data）をきっかけに、分散ファイルシステムによる解決の可能性が示唆されオープンソースソフトウェア（OSS）実装であるHadoopの公開と、続くさまざまなNoSQL実装が発表されていく中で対処可能との認識が広がってきた。

　筆者はそれまで情報爆発と呼ばれていた増大する情報量の問題をビッグデータと呼ぶようになったきっかけを作った論文は、2009年に公開された『ビッグデータの病理』（The Pathologies of Big Data Adam Jacobs Communications of The ACM）なのではないかと考えている。この論文はRDBMSやデスクトップで動作する可視化ソフトウェアの類いでは取り扱いが困難な規模のデータの存在と、その処理基盤として分散コンピューティングの有用性を説いている。今日的な意味でのビッグデータ定義の規模の側面について、実装制約の面から具体的な例証を積み上げることで丁寧に迫っていて、エンジニアに理解しやすい構成になっているので一読をお勧めする。

　ここまで、クラウドガバナンス上の課題にも直結するビッグデータのデータ規模と統治可能性の関係を紹介してきた。しかし今日的なビッグデータ定義は今までたどってきたデータ規模の問題だけを取り扱っているわけではない。再度時間を巻き戻してみよう。

　2001年にMETA Groupのアナリスト、Doug Laneyがデータウェアハウス利用推進の立場から発表した3Dデータマネジメント（3D Data Management: Controlling Data Volume, Velocity, and Variety Application Delivery Strategies META Group）は、当時活発化していた企業の買収や合併の増加、組織間コラボレーションの強化を図るための触媒としてデータモデル相互のマッピングの重要性を指摘し、3Dデータマネジメントと命名してデータ量（Volume）、速度（Velocity）、多様性（Variety）の三次元軸を利用したコントロールが有効だと指摘していた。ちなみにMETA Groupは2005年にGartnerに買収されている。なお、著者のDoug Laney氏はMETA Groupから米Deloitte Tohmatsu Consultingを経て1年前にGartnerのVPに就任している。

　どうやら3DデータマネジメントというコンセプトはGartner自身もかつて買収したMETA Groupの資産から再発見したものらしい。3Dデータマネジメントは、有益な知見を発見する切り口として、量、速度、多様性（いずれも頭文字がVであるところから3Vと呼ばれる）を軸として重視し、単純に“大きな”データと“極端な”データの違いを際立たせる点に特徴がある。この考え方は、そのまま2011年にGartnerが発表したビッグデータ定義でも踏襲され、現在に至っている。

ビッグデータの正体

　ここまで歴史を振り返るとビッグデータという概念が含む課題はビジネスインテリジェンス（BI）とよく似た構図だと誰でもすぐ気付くだろう。もともとBIという概念自体が1989年にGartnerが発表したものなのだから当然だ。

　Gartnerの定義に基づいてビッグデータを論じているように見せて実は、「分散ファイルシステムを利用して従来構築されていたデータウェアハウスよりも巨大なデータプールを構築し、OLAP的な多元解析を行うことによって今まで見逃していた事業機会を発見する取り組み」という従来と何ら変わらない話をする人を見掛ける。

　しかし、それではロングテールに埋没していた逸失機会の発見が関の山であるし、3Vのうち、量（Volume）と速度（Velocity）しか取り扱えていない。実のところビッグデータで最も特徴的な要素は残る多様性（Variety）だと筆者は考える。Gatnerのリリースから多様性についての定義を引用してみよう。

* 多様性：

ITリーダーは常に、大量のトランザクション情報を解釈し判断に生かすという課題と向き合っていますが、現在は主にソーシャルメディアとモバイルに由来する分析すべき情報のタイプが増加しています。これには、表形式データ（データベース）、階層型データ、ドキュメント、電子メール、メータリングデータ（センサーなどから得られる測定データ）、動画、静止画、オーディオ、株価データ、会計トランザクションをはじめとする数多くのタイプが含まれます。

　Gartnerの定義はビッグデータとして取り扱う対象として明示的に非構造化データを含めている。これではOLAPはお手上げだ。

　そうなると、ビッグデータを取り扱うためにはOLAPとは異なるアプローチが必要だ。そこではまず非構造化データのパターン認識技術が必要になるし、構造化データと非構造化データを統合的に取り扱うための操作体系も必要だろう。筆者はこれまで非構造化データを含むデータプールを統合的に操作するための体系としてオントロジーを想定していたが、早稲田大学 名誉教授の丸山 不二夫先生から2002年に発表されたナレッジグラフ論文（Knowledge Graph Theory and Structural Parsing Lei Zhang）の存在を教わり、意見が変わった。

　Zhang論文（Lei Zhang氏は現在、西北大学教授）は、考え方の基礎に生成文法を置き、特定の実装に依存しない形でKnowledge graph theoryを記述しており、知識構造生成が自律的に行える可能性を示している。2006年からマックス・プランク研究所が取り組んでいるYAGO-NAGAプロジェクトは、Zhang論文の文脈の延長に位置付けられるように思う。YAGO-NAGAプロジェクトでは、機械処理可能な知識ベースの構築を目標に、WikipediaやWordNet（プリンストン大学が開発している英語の語彙データベース）、GeoNames（オープンな地名・地理データベース）をナレッジグラフとして構造化している。これらの研究を見渡すと将来的に3Vを統合的に取り扱う手法としてナレッジグラフは非常に有望な考え方といえるだろう。

　参考まで、2012年5月17日に米国で発表されたGoogle Knowledge Graphも基本的な考え方はKnowledge Graph Theoryに基づいているようだ。基準参照系としてCIA World Fact BookとWikipediaを利用して速度計測系としてFreebaseを利用し、恐らく量の計測系として従来のGoogle検索を利用しているだろう。Google knowledge graphは、Zhang論文の持つ繊細な優美さからはほど遠いマッチョ感にあふれた、いかにもGoogleらしい実装だと感じる。筆者の好みで申し訳ないが、利用できる知見の範囲が理科年表的な領域に限られるものの、Wolfram Research（Mathematicaの開発元として有名）が提供しているWolfram Alphaをナレッジグラフ的なるものの実用に供されている祖型として挙げておきたい。

　どうやらビッグデータの正体がおぼろげながら見えてきたのではないだろうか？　究極的にはビッグデータとはInternet of Thingsを目や耳、皮膚として実世界の無数の切片を収集し、ゆらぎ制御して現実世界の写像を浮き上がらせるものといえるだろう。さらに、クラウドに集積されていくさまざまな機能の相互作用によって発生する膨大なログから、Knowledge graphをガイドにデータのネットワーク構造を自律生成し、現実世界の写像と仮想システム上の相互作用の相関を描き出し、システムに接続された経済活動の総体を表す言葉となるだろう。2001年に慶應義塾大学 総合政策学部 伊庭 崇准教授が描いたBoxed Economyの巨大な子孫ともいえるかもしれない。もっと分かりやすく言うと、2009年に公開された映画『サマーウォーズ』に登場したOZのバックエンドシステムと言ってもいいかもしれない。

　現時点で筆者の理解している範囲から推論すると、ビッグデータ利用を前提とした競争とは、

1. より大きなデータカバレッジ（構造化・非構造化を問わず、かつ、時空間の広がりを持つ）を得て
2. より小さく多様な変動から効率よく高い精度で結果を推論するKnowledge graphモデルを持ち
3. より高速に動作する分散プラットフォームを保有する

ことで競合に対して先手を取り、比較競争優位を得ることを図るものになりそうだ。

　実にエキサイティングなテーマではないだろうか？　実際の社会は複雑適応系的に振る舞う、言い換えると社会は非線形に振る舞うので、局所最適化の総和が全体最適を実現するとは限らない。全体最適化を常に意識していないと競争優位を得られない市場が現れようとしているといえるだろう。実のところ、局所最適、全体最悪とまで言われた日本には少々分の悪い市場のようにも思えるが、まだチャンスはあると信じたい。

ビッグデータの応用事例

　それでは、既に存在するビッグデータの実用化事例を見て見よう。あまりに身近なツールなのでこれがビッグデータ応用例であることを忘れてしまいがちだがGoogle Maps Traffic layerを利用したDirections（ルート案内）は立派なビッグデータ事例だ。

　Internet of Thingsの祖形としてAndroid端末の位置と移動量の情報を利用して交通量を推定し、最も空いているルートを提示してくれる。シンプルかつパワフルなビッグデータ活用事例といえる。日本でもNTTドコモがモバイル空間統計というよく似たテーマでの研究に取り組んでいる。

　筆者はスウェーデンEricssonのDynamic Discount SolutionはInternet of Thingsを支える無線インフラにも着目している。移動体通信網の基地局稼働率の繁閑を利用して通信料金を動的に決定することで、コスト制約条件を制御し需要抑制を狙っている。IaaS（Infrastructure as a Service）でもAWS（Amazon Web Services）などがスポット料金を設定することで同様の需給調整機能の実現に取り組んでいるのでご存じの方も多いだろう。

　さらに通信システムの内側に入ってみる。通信の秘密に厳格な日本とは異なり、中国の情報通信法制において検閲は電気通信事業者に課された義務だ。中華人民共和国電信条例の5章、ことに57条を中心に検閲義務を明示的に定義している。禁止事項類型が9項目挙げられ、明らかに該当する場合には、通信遮断、記録、国家機関への届け出が義務付けられている。よくいわれるが、この検閲はかなりの部分で人海戦術に拠っているようで、また、その適用基準も揺らぎがあって傾向がつかみにくい。2012年6月15日からは中国国内から.co.jpドメインへのアクセスが規制されて在中国日本企業が大混乱に陥ったのは記憶に新しい。

　この中国政府による検閲実態を把握するために、香港大学のKing Wa Fu助教授が開発したWeiboScopeは中国のTwitterに当たるWeiboで影響力を持つ30万アカウントを観測することで検閲傾向を分析している。利用しているデータ量はまだ小規模だが速度に着目したビッグデータ利用事例の祖形とはいえるだろう。

　一方、人力一辺倒かと思いきや、中国政府もハーバード大学のGary King教授が開発したソーシャルメディア分析技術を効率的な検閲実現のために利用しているという。

　さて、巨人Googleやキャリア、国家といったモンスタープレーヤーの事例ばかりを挙げてきたが、個人によるビッグデータ利用例もある。Fernanda ViegasとMartin WattenbergによるユニットHINT.FMが作成したWind Mapだ。

　Wind Mapは米国海洋大気庁（NOAA）が運営するNDFD（National Digital Forecast Databese）が無償で提供している気象データを利用して、ほぼリアルタイムの風向きと風力の地図を提供している。日本の気象庁もGPVと呼ばれる数値予報データや観測データを作成しているが、技術仕様、データともに気象業務支援センターなる公益法人を通じて有償でしか提供されていない（参考）。

　これらの事例を見て筆者はつくづくビッグデータとはインフラストラクチャだ、との思いを強くしている。ビッグデータとは一種の公共財として整備されるべき分野なのではないだろうか？　誰もがアクセス可能なオープンなプラットフォームがあり、そこに接続するさまざまなデータソースを重層的にマッシュアップすることによって価値が逓増する、言い換えるとネットワーク外部性を発揮していく情報財なのではないだろうか？

　その観点から、NDFDやUSA TODAY Census APIなど無償で莫大な量の基礎データをオンラインで提供している米国と、有償で気象データを非公開データ形式で気象業務支援センターを介して提供している気象庁や、政府統計利用に事前相談や審査を要する上に有償で統計センターを通して提供（統計センター：匿名データの利用）している総務省の例を引き比べてみると、ビッグデータ利用で大きな差がつくのも仕方がないと思えてくる。このような公共データ提供しかされていない国でビッグデータを活用するマッシュアッププラットフォームが育つとは考えにくい。2012年7月4日に日本でも遅まきながら電子行政オープンデータ戦略が発表され、4項目からなる基本原則が示された。2012年度からニーズ調査などに着手するとしているが、政府関係者にはInternet of Thingsの一般化する時代を見据え、社会インフラとしてのPublic BigData整備の視点で既存有償公開データの取り扱い改善を含めた取り組みをお願いしたい。

　一方、利用者の立場に戻ると、個々の事業体がそれぞれに「おらがビッグデータ」を囲い込んでも競争力の源泉にはならないと肝に銘じるべきだ。他者のデータと組み合わせ多角的に分析することで初めて新しい機会を見つけることができる、くらいに考えた方がよい。むしろ知恵を絞るべきは相互のデータ提供条件を調整する機構のモデリングだろう。より多くの情報を提供したデータ保有主体が、見返りとなる他者由来データを得られるような市場環境作りと、データに対するミニマムアクセス保障の実現こそテーマとなると考える。＠IT自分戦略研究所の記事「クラウドが普及した市場で、生き残るエンジニアと組織」で言及したOpen Innovationの文脈で考えてみてもよいだろう。

環境の成熟と道具の発達が欠かせない。まだ機会はある

　2012年7月4日にヒッグス粒子である可能性を持つ新粒子発見が伝えられた（ロイター：ヒッグス粒子発見か、確定にはさらなる分析必要）。あの発見を支えたCERN LHC Computing Grid（2010年時点で20万コア、150PBストレージを34か国に分散）などのHPC（High Performance Computing）が、巨大な、しかも成長し続けるデータと格闘する伝統を持つ素粒子物理学などの発展の基礎となり、膨大な計算需要や記憶需要を賄ってきた。しかし、HPCは誰でも所有できるほど安価なものではない。

　HPCの所有はコスト面で折り合わない企業が大半だろうが、既にAWSのHPCインスタンスをはじめ、大量の計算資源や記憶資源の利用は可能な時代となっている。米MicrosoftもWindows AzureをLinux対応させ、GoogleもGoogle Compute Engineを発表してIaaS事業参入を果たした。

　持ち上げておいて落とすのもなんだが、実はAWS HPCインスタンスですら2012年6月のTop500 Listでは72位と、HPCとしては凡庸な性能（それでも240TFLOPsをたたき出す）にとどまる。筆者は常々クラウドはHPCを模倣すると考えているので、このランキングを見るにつけ、まだまだIaaSには発展の余地が大いにあると楽しみになっている。

　トップをひた走る海外クラウド勢から見ると周回遅れではあるが、日本でもNTTコミュニケーションズのCloudnが複数の国に跨ったDC展開を果たし、GMO Cloudは本連載でも以前紹介したcloud sleuthのインターネットイニシアティブに続いて国内2社目となるパートナーとなった（関連記事：クラウドの応答性能とサポート品質を客観的に比較するには）。徐々にではあるが世界市場を意識した動きが広がりつつある。計算資源に占めるクラウド比率がいまだ数パーセントにとどまる現状を考えれば、競争はまだ序盤戦といって差し支えない。巻き返すチャンスはあると考えてよいだろう。

　2012年6月20日にはファーストサーバのレンタルホスティングサービスで不幸な事故が起きたが、筆者も繰り返し主張してきた事業者を跨いだ冗長性確保の一般化推進の立場からすると苦い教訓を得たと位置付けられるだろう。これまでのところ、ファーストサーバは事故の実態解明に誠実に取り組んでいるように見え、筆者はこの点は評価している。

　さらに、PaaS（Platform as a Service）層を見てもAmazon Elastic MapReduceに加えてGoogle BigQueryも選択できるようになり、OSSパッケージでもTalend Open Studio for Big Dataなどが公開されている。総合的に見て、データの量（Volume）、速度（Velocity）を取り扱う条件は整いつつある。今後この領域では前回「クラウドの資源量で考える、単一IaaS事業者への依存リスク」で扱ったCAP定理制約を考慮したアシンクロナス処理を基本として、利用者の要求に応じて遅延制約を調整することでスケールアウト性を調整できるアプリケーション実行環境構築が進むだろう。Java EE7や続くJava SE8に期待している。

　今後は残る多様性（Variety）に対処するため、上述したスケール制御可能なアプリケーション実行環境上にナレッジグラフ利用に向けた環境整備が進んでいくだろう。もちろん、ナレッジグラフを操作するための前提となる、パターン認識（この分野もGoogleが一歩先んじているように思える）やグラフデータベース、Rに代表される統計分析パッケージの利用環境整備など下ごしらえしなければならない課題が数多いが、それ故にチャンスも大いにある。全体最適を意識しOpen Innovationを実現すれば、拡大する世界市場で日本が重要なプレーヤーとして存在感を放つことも可能だろう。

　せんじ詰めるとクラウド化した市場における競争とは、自社に有利な全体最適を達成する競争であり、言い換えると自社に有利なナッシュ均衡（ナッシュ均衡はあらゆるゲームにおいて1つ以上ある）に誘導する競争だといえる。局所最適ばかり目指すプレーヤーは全体最適を描けるプレーヤーに隷属するか市場から退出するしかなくなる。そう考えるとクラウドの進化にとってビッグデータは手段であると同時に目的ともなる重要な要素であることが見えてくる。