前回の記事では、GAEがデータをハンドリングする際の大きな制約について述べた。いわゆるRDBが使えず、「データストア」とよばれるKVS型のサービスを使うしかないというものだが、この点が大きく改善された。2011年11月にサービスとして使えるRDBが仮リリースされ、2012年5月に正式リリースされた。Amazon RDBや、MicrosoftのSQL Azureと同様に、管理とセットアップが不要のRDBサービスである。中身は、MySQLのようであるが、Googleの複数のデータセンターでリアルタイムにレプリケーションが取られており、可用性は極めて高い。ただ、遠距離レプリケーションで一貫性を保とうとするので、レスポンスには難がありそうだ。やはり王道はデータストアとし、Google Cloud SQLは当面、補完的な位置付けと考えた方がよさそうだ。

※　取材後にGoogle Cloud SQLについて機能強化の発表があった。容量の増大（10倍）、非同期レプリケーションによるI/Oの高速化、Google Appsとの連携強化などがうたわれている。無料のお試し枠も用意された（2013年6月1日まで、最長半年間、0.5Gバイトまで）。興味のある方は、「Google Developers／Google Cloud SQL」からサインアップしてみるとよいだろう。

Google Compute Engine

　GAEを使い倒しても、Google Cloud SQLを駆使しても、まだ自由度が足りないとき、最後の砦となり得るのがこのサービス……なのではないか。いわゆるIaaSに該当し、Linuxインスタンスを平易に調達して自由に使える、ということのようだ。Amazon EC2相当のサービスと思われる。などといちいち語尾を濁した曖昧な書き方ばかりで申し訳ないが、本稿の執筆時点で、まだ仮リリース（Limited Preview）の状態であり、あまり深い話は聞けなかった。正式リリースの日程もアナウンスされていない。仮リリースの発表時には、数万台を並列稼働させて遺伝子解析をさせるデモンストレーションもあったようだが、IaaSは競合も多い分野で、強力な先行者も存在している。このサービスも前述のGoogle Cloud SQL同様、単独で使うものではなく、Googleのサービスを使いこなす中で、開発するアプリの自由度を高めるための補完的な存在なのではないかと想像する。

Google Cloud Storage

　いわゆるオブジェクトストレージである。Amazon S3に相当すると思われる。これも単独で利用する意味は薄いのではないか。GAEやGoogle Compute Engineが扱うデータを保持する際や、後述するサービスの中で間接的に利用することになりそうである。

APIライブラリ

　前述のAPIだが約60種類用意されている。詳細はURL（https://code.google.com/apis/console/）を参照されたい（Googleアカウントでのログインが必要）。仕様はオープンで、前述のGAEから呼び出すことも、イントラのWebアプリから呼び出すことも可能である。検索APIのようになじみ深いものもあれば、実験的な位置付けのものもあり、統廃合もあり得るので注意が必要だ。これらの中からエンタープライズ向けとしてSLAが定められたAPIが出てきている。法人向けの契約書や価格表も定められ、サービスが統廃合される心配もない。今般、新たに幾つかのAPIが正式版として追加発表され、可能性が広がった。新旧併せて主要なAPIを以下で紹介していこう。

• Google Maps API

　冒頭で例示したWebアプリの中で利用したAPIである。表示サイズや位置情報をパラメータとして渡せば、Web画面上に適切な地図を適切な縮尺で表示してくれる。渡す位置情報は緯度・経度でもよいし、住所（例：東京都港区港南2丁目）や、ランドマーク（例：東京タワー）でもよい。2つの地点を指定して、移動ルートの表示もできる。このとき距離や所要時間の計算もしてくれる。表示された地図は普通のGoogleマップとしてのインタフェースを備えているので、中心点の移動や縮尺の変更、移動ルートの変更もできる。単純な地図であれば表示のリクエストは1日当たり2万5000回までは無料である（それ以上はリクエスト1000回当たり数ドルの費用が発生する）。業務で本格的に利用するのであれば有償サービスを利用するのがよいだろう（有償／無償に関するこの考え方は全てのサービスでほぼ同様である）。

• Google Translate API

　2012年8月に正式版になった新顔である。 Googleで検索をしていて海外のWebサイトに行き当たった場合、Googleが日本語に翻訳するか否かを問うてくる場合がある（PCの環境に依存する）。ここで実際に翻訳をしてくれるサービスがGoogle Translateであり、それをAPI化したものがGoogle Translate APIである。引数としてオリジナルのテキストを渡し（言語は自動判定される）、どの言語に翻訳するかを指定すれば、翻訳後のテキストが実行結果として返ってくる。何ともシンプルである。

　翻訳の精度は（体験された方も多いと思うが）、必ずしも完璧ではない。オリジナルの文の「素直さ」にも依存するが、何とか原文の趣旨が読み取れるレベルといえる。「それでは使えない」というご意見もあろうが、ある程度分かれば何とかなるという用途もある。特に共通の関心を持つ者同士で、意見交換をしようとする熱意があれば、Google Translate APIによる簡易翻訳は言語を超えたディスカッションを加速していくだろう。例えば、ユニクロは「Clothes for Smiles」というプロジェクトで世界中から意見を募っているが、ここではこの簡易翻訳が一助となっている。この他にもグローバル企業において、世界中の従業員を巻き込んでアイデアコンテストをするような場合にも応用が期待できる。費用は投入したテキスト100万文字当たり20ドルである。

• Google Prediction API

　Prediction（予言、予測）をするAPIである。神秘的な響きがあって興味をそそられるが、中身は機械学習である。単純に言えば、入力（データ）を与えると、出力（判定や、標語）が返ってくるという仕組みだ（全然説明になっていない気がするが）。次のような応用例を見ていただくと分かりやすいかもしれない。

　利用に際しては、事前にシステムに対して学習（トレーニング）を行う必要がある。できるだけ大量に、「入力データ」と、それをあらかじめ「判定」した結果のセットを用意し、システムに読み込ませておく。これを済ませておけば、以後、システムに入力を与えると、学習したパターンから近い判定結果を推計して出力してくれる。判定が間違っていれば、これを指摘することでまた学習が進み、判定の精度が徐々に向上していく、という仕組みである。なお、上記の例では入力／出力ともにテキスト型の例を挙げたが、数値型（連続値）も扱えるらしい。良い例を思いつかないが、判定結果に確率を付与するような使い方がありそうだ。月間1万判定までは月額10ドルの基本料金だけで利用できる（超過分は、1000判定当たり50セント）。

　機械学習に興味はあっても実際に構築したり試してみたり、となると、軽々に着手できるものではない。シンプルではあるが、機械学習システムをこのコストで使えるのは魅力といえる。

Google BigQuery

　Gバイト～Tバイト級のデータを一気になめて、集計・検索結果を得ることができるサービスである。ユーザーはデータをCSV／JSON形式で前述のGoogle Cloud Storageに乗せる。APIを通じてSQL文を投げると、このファイルを（RDBでいう）テーブルと見なし、集計・検索処理をして結果を戻してくれる。一般のRDBでは、「全件サーチ」というと、「結果を得るまでに膨大な時間がかかる」こととほぼ同義だが、本サービスではその心配はない。サーチしたデータ量に応じて（見えないところで）勝手にCPUリソースが調達され、分散処理・集計が行われ、短時間で結果が返ってくる。リソースの予約や特殊なコーディング、機器障害を想定した作り込みなどは考える必要がない。また、稼働したリソースの課金について心配する必要もない。課金は「SQL文が処理したデータ量（カラム単位）」によって算出され、1Gバイト当たり、2～3.5セントである（最初の100Gバイト／月は無料）。これとは別にデータ保持料として1Gバイト当たり月間12セントがチャージされる。

　定型データしか扱えないので、Hadoopの事例にあるような非定型データは不得手である。逆に高度なプログラミングなどは不要なのでHadoopよりも圧倒的に平易に使える。Hadoopで非定型データを定型化してBigQueryに読み込ませ、後はSQLで一発集計……などという事例があるようだ。

　データ連携やSQL投入なども全てAPI経由なので、直に感覚的に使うことはできないが、このあたりを上手にラッピングするサードパーティーのアプリケーションやツールも出回っている。うまく組み合わせれば業務系のバッチ処理にも使えそうだ。

課題

　以上、駆け足でGoogleクラウドの主要なコンポーネントについて解説した。サービス利用に際し、幾つか課題があるので列挙しておきたい。

　まず、Googleのデータセンターは日本にはない。その上、拠点をまたいだ冗長性を自動的に確保しているので、自分のデータがどこにあるのかを特定することは困難である。「特定できないからこそ安全である」（従って特定しようとすることは無意味だ）という考え方は、クラウドの普及に伴い徐々に一般的になりつつあるが、企業によっては既存のセキュリティガイドラインをクリアできないだろう。これはGoogleの課題というよりもユーザー企業側の課題かもしれないが、もしも保存されたデータが「日本国内に保持されており、国外には出ない」ことが明確に保証されているとしたら、日本企業の利用は格段に進むことが予想される。現時点ではクラウド慣れした（先進的な）ユーザー企業の利用にとどまるだろう。

　次に、本稿で紹介したサービス、特にAPI系のものは、言うまでもなく「そのまま」利用することができない。何らかのアプリを作成し、その中でAPIをコールするというカタチで利用することになる。「お試し」を含めこのようなことを自由自在に実現できる開発者は、そう多くない。当然、Googleに依頼しても開発をやってくれるわけではない。経験豊富なSIerに相談するしかないだろう。

　そのAPIだが、非常にパラメータはシンプルである。サービスそのものの仕様が単純である以上、当然のことなのだが、逆にカスタマイズを行おうとすると困難を極め、場合によっては現実的ではないかもしれない。機能の追加や性能の向上はGoogleのサービス自体のバージョンアップに期待するしかない。アプリケーションや業務自体をサービスの仕様に合わせるような割り切りが必要になるだろう。

　決定的な点だが、ドキュメントの大半が英語のままである。「使い方の例」という俯瞰的なものから「APIの仕様」という厳密性を要するものまで、日本語化されているドキュメントは少ない。エンタープライズにおける採否を左右し得るGoogleのセキュリティポリシーを説明した白書（PDF）ですら英語のままだ。また、サービスごとにSLAがあり、別々に申し込みが必要（そのたびに英語で参照すべきドキュメントが増える）という点も分かりにくさを加速させている。これらの点は急速に改善することを希望したい。

イマジネーションへの挑戦

　冒頭で述べたように、Googleのサービスは「ややこしことをあっさりとやってくれる」強力で便利な部品と解するとよい。大量の計算リソースや、大容量のデータ、複雑なロジックを必要とする処理を安価に実行してくれる。荒削りではあるが、見方によっては前項で列挙した課題など問題にならないほどのパワフルさだ。一説によるとGoogleは数百万台のサーバを世界中で保持しているという。ユーザーは瞬間的かつ一時的にそのリソースの一部を高度なロジック付きで借りられることになる。

　これらをエンタープライズの業務でどのように生かしていくことができるのか。超先進IT企業Googleは、残念ながら個々の企業の実情に合わせて具体的な用途を手取り足取り示してくれることはなさそうだ。活用方法はユーザーたるわれわれのイマジネーションに委ねられている。せっかくこれだけ興味深いサービスがインターネット上に無造作に置かれているのだ。面白い使い道を考え、今までにない業務システムを考案し、自社の情報資産活用を新しいステージに導いていく気概が求められていると言ってよいだろう。これはGoogleからの挑戦ともいえる。本稿が読者各位において良い刺激となれば幸いである。

加藤 章（かとう あきら）

電通国際情報サービス　ビジネス統括本部　クラウドビジネス開発部　ストラテジスト

システム開発のPMやビジネスコンサルタントなどを経て、現在は自社内のビジネス企画に従事。クラウドに軸足を置いて調査、企画、情報発信、営業支援および社外とのアライアンスを担当する。