各種サービスの集合体で成り立ち、他社クラウドサービスとは根本的に発想を異にするGoogleクラウドは、良質なサービスと高度なインフラを安価で提供する。本稿では、企業利用の視点でGoogleクラウドの構成要素を解説する。
本連載「企業向けシステムを構築するパブリッククラウド」ではさまざまなパブリッククラウドを、エンタープライズの業務システムで利用する観点で解説している。今回は「クラウド」というタームを最初に使い始めたといわれるGoogleを（再度）取り上げる。六本木の華やかなオフィスを訪問して取材をした内容をベースに、筆者の私見を交えながら解説を試みる。なお、Googleの成り立ちなどについては、過去の記事を参照していただきたい（過去の記事はこちら：「Google App Engine」の企業利用におけるさまざまな課題）。
連載インデックス：企業向けシステムを構築するパブリッククラウド
取材してあらためて分かった（確認できた）ことだが、Googleはこれまで紹介してきたクラウドサービスとは根本の発想が大きく異なっている。従って、今回の記事もこれまでのスタイルをかなぐり捨てて、全く違うアプローチで書き進めてみたい。
さて、いきなり個人的な話で恐縮だが、筆者は次のようなWebアプリケーションのモックアップを作ったことがある。数年前、あるお客さまの業務に関して提案を検討した際に利用した。実際に提案するまでには至らなかったが、面白いという評価（？）はいただいた。稚拙なデザインなので本当はここで披露するのもお恥ずかしい限りなのだが、解説を進める上でよいサンプルになりそうなので、まずは画面イメージをご紹介する。
業務としては、お客さまの依頼に応じて社内スタッフを訪問させるサービスを想定している。オフィス機器の保守をするフィールドエンジニアのディスパッチをイメージしていただけるとよいだろう。上記の例では候補となった2人のスタッフのどちらを訪問先（東京タワー付近）に送り込むべきかを検討している。検討に当たっては2人それぞれのスケジュールと移動ルート、移動の所要時間を見比べる。従来はアサイン担当者の勘と経験と記憶と紙情報に頼っていた業務がシステム化される、というもくろみである。
図1に表示される「候補者のスケジュール」「移動経路」「所要時間」は、実はGoogleから引っ張ってきたものだ（ここでは担当者は日頃のスケジュールを全てGoogle Appsで管理することを前提としている）。「目的地」や「1つ前の予定の訪問先の位置情報」をテキスト入力すれば、移動経路や所要時間が再計算され、誰を派遣するのがベストなのかという判断がやりやすくなる。
筆者自身は、プログラミングから完全に離れてしまっており経験が乏しい。それでも見よう見まねで数日間の夜なべ仕事で上記のようなモックアップができてしまい、部分的とはいえ画面が動くという点は自分でも興味深かった。通常の企業が自前でゼロからこのようなシステムを構築しようと考えたら、かなりのコストと深い知識、開発体制が必要なことは想像がつく。ところが、ややこしそうな部分（カレンダーと地図と経路計算）をGoogleのAPIで処理させることで開発が一気に平易になる。これがGoogleをエンタープライズで利用する典型的なパターンと言えそうだ。
そういう意味ではGoogleを単なるIaaS、PaaS、SaaSと捉えたり、他のクラウドと比較することは適切ではないのだろう。Googleは、Google AppsというSaaSと、多数の良質なAPI、そしてそれらを補完するサービスから成る集合体なのだ。これらの個々の要素は「ややこしいことをあっさりとやってくれる」便利な部品と理解するとよいかもしれない。これらの部品が複雑な処理を行うに当たって膨大なコンピュータリソースを必要としたとしても、それらは見えないところ、つまり雲（クラウド）の中でGoogleが管理していて、ユーザーは何ら気にする必要はない。部品を使いこなして自分のビジネスに活用することだけに集中すればいいのだ。この考えを念頭に置いた上で、以降では、集合体の個々の要素（下記のリスト）について解説を加えることとしたい。
Google Appsを実際に使っておられる方も多いだろう。あらためて説明するのも気が引けるくらいだ。メール（Gmail）、スケジューラ、簡易ファイルサーバ、グループ管理機能などがGoogle上の（＝Webの）アプリとして利用できる。特に個人については無料で使えるという点も見逃せない。許可を出し合った利用者同士、スケジュールを共有することも可能であり、小さな組織であれば、無料でも十分に役に立つ。法人向けの有償サービスもあり、1ユーザー当たり年間6000円で利用できる。
Google App Engine（以下、GAE）は、前述のGoogle Appsと名前を混同しやすいが、別物である。Google Apps自体は単純なSaaSであり、ロジックの組み込みなどは困難であるが、これを打破するのがGAEの主な役割だ。Webの開発プラットフォーム（PaaS）の形をしており、PythonやJavaの開発環境からGoogle上にデプロイができる。デプロイ後は、「Google上のWebアプリ」として可用性の高いインフラの上で動作する。WebアプリがGoogle AppsのAPIを呼び出すことでGoogle Appsのラッパーとすることも可能だし、Google Appsからアプリを呼び出す形で機能追加を実装することもできる。このとき、後述するAPIライブラリを上手に使うと、本稿の冒頭で例示したようなアプリを組み立てることが可能になる。
Copyright © ITmedia, Inc. All Rights Reserved.
ハロウィーンの口コミ数はエイプリルフールやバレンタインを超える マーケ視点で押さえておくべきことは？
ホットリンクは、SNSの投稿データから、ハロウィーンに関する口コミを調査した。
なぜ料理の失敗写真がパッケージに？ クノールが展開する「ジレニアル世代」向けキャンペーンの真意
調味料ブランドのKnorr（クノール）は季節限定のホリデーマーケティングキャンペーン「#E...
業界トップランナーが語る「イベントDX」 リアルもオンラインも、もっと変われる
コロナ禍を経て、イベントの在り方は大きく変わった。データを駆使してイベントの体験価...
ITmediaはアイティメディア株式会社の登録商標です。
図1 サンプルWebアプリの画面イメージ
