注：使いやすさや機能の豊富さ、問い合わせや事例の多さなどを念頭に筆者の主観で概観した。詳細は本文を参照
　　表記は次の通り。◎：特に優れている、○：優れている

ロケーション

　「そのIaaSは物理的にどこにあるのか？」という問題である。多くのクラウド事業者が（セキュリティ上の観点から）データセンターの住所は公開していないが、目安として都市名などを開示している。ここでは次のようなポイントが重要となる。

日本国内

　利用環境とIaaS間の通信回線のレスポンスや、専用線の敷設などを考えると、データセンターは国内にあることが要件となろう。あるいは業務に関わるさまざまな規制などにより、国外にはデータを保管できないということもある。国産クラウドが日本国内にあるのは当然として、海外資本のクラウド事業者に対して「国内にあるのか」というのはよく聞かれる質問だ。「Amazon Web Services」（AWS）は東京近郊にあることを開示している。「Windows Azure」はまだ日本にはないが、近々日本にサービス拠点を設置すると発表している。「Google Cloud Platform」は日本にはなく、また、日本上陸の予定もなさそうだ。

東日本と西日本

　東日本大震災発生からしばらくの間、東京近郊のデータセンターを利用しているユーザーが、西日本にIaaSを求める動きが相次いだ。当時ほどではないが、今でもしばしば同様の要望を聞くことがある。社内ルールや業界基準などによって、遠隔地に待機系システムの設置が求められているケースが多いようだ。遠隔地の定義として「500キロ以上離れていること」という基準すらあった（この社内ルールを持つ当の本人たちが一番困惑していたようだが）。これほど極端ではないにせよ、東京近郊のデータセンターのユーザーは、「西日本」に解を求める傾向が強い。

　実は筆者は、「500キロ以上離れていること」「西日本にデータセンターを置くこと」といったニーズは心理的なもの（気持ちの問題）にすぎず、実質的にはあまり意味がないのではないかと考えている。現実には東京近郊に適切な距離を置いたデータセンターが複数あれば十分だ。地盤や電力系統が別になるので、全てのデータセンターが同時に壊滅したり長期停電に巻き込まれたりすることはまずあり得ない。「東京全部が壊滅したらどうするのか」とか「同じ東京電力管内だから全域が長期停電する可能性はある」という声もあるが、そのような事態はそもそも極めて起こりにくいし、もし起こったとすれば、そのときはユーザー自身のオフィスも自宅も壊滅ないし停電しており、ビジネス自体が機能しないことに気が付くべきだろう。業務の継続性よりもユーザー自身の生命の安全確保を長期にわたって務めるべき事態である。

　実質的な意味はなくとも、前述のような「社内ルール」などによって、どうしても東日本、西日本の両方でサービスを受けたいというユーザーもいるのは事実だ。これが可能なクラウド事業者として、インターネット・イニシアティブ（IIJ）、「ニフティクラウド」、IDCフロンティアなどがあるので検討すると良いだろう。

海外

　ここまで日本国内の拠点の話をしてきたが、逆に海外に拠点を求めるケースもある。例えば、ユーザー企業がインターネット経由で顧客にサービス提供している場合で、かつ、グローバル展開している場合がこれに当たる。世界中に顧客がいるので、できるだけ顧客に近い拠点にサービスを構えたいという要望があるようだ。

　DR（災害復旧）の観点で海外拠点を検討しているユーザーも散見される。日本のバックアップをアジアで、米国のバックアップを欧州でという発想だ。現時点では遠隔データ保管に近いイメージだが、ゆくゆくは業務システム自体も国境を超えて保持されるようになるのかもしれない。

　AWS、Windows Azure、「IBM SmarterCloud」などは、米国、欧州に拠点を持っており、この観点から利便性が高い。「Bizホスティング Cloudn」（Cloudn）は日本と米国でサービスを提供している。

移行の平易さ

　既存のシステムをクラウドに移行させる場合の「やりやすさ」について考える。既存システムとしては、オンプレミスの物理（P）サーバ、仮想（V）サーバ、あるいは別のクラウド（C）のインスタンスの上にあるアプリケーション類を考える。

　受け入れ側のクラウド（C）のインスタンスは仮想化されているので、既存システム側も仮想化されていると比較的やりやすい。仮想化されていないなら、いったんオンプレミス環境下でP2Vの移行と動作確認を行い、その後にV2Cの移行と動作確認を行うことがベストだろう。2段階（P2V2C）の手間ではあるが、安全といえる。なお、IDCフロンティアは、物理サーバからクラウドへの移行を専任スタッフがワンストップで代行してくれる「クラウド移行おまかせサービス（VMインポート）」を提供している。

　オンプレミスの仮想化された環境からクラウドへ（つまりV2Cの）移行を行う際には、ツールを使いながら、動作確認を行いつつ実施することになる。オンプレミス側の仮想基盤とクラウド側の仮想基盤が同一である場合には、移行がしやすそうだ。ニフティクラウドや「BIGLOBEクラウドホスティング」はVMware ESX／ESXiベース、Windows AzureはHyper-Vベースである。AWSは独自の仮想基盤を使っているが、VM Import/Exportという機能で、VMware ESX／ESXiやHyper-Vのイメージの取り込みと書き出しを可能にしている。

　まれに「C2C」（クラウドから別のクラウドへ）の移行のしやすさを質問されることがある。これからクラウド基盤を本格的に使っていこうというユーザーが、ベンダーロックインを心配し、将来より良いクラウド基盤へ平易に乗り換えられるようにしておきたいという要望のようだ。「結婚する前から離婚の相談ですか」などと冗談を言ってしまうが、オンプレ時代にはあり得なかった相談である。白状すると現時点で筆者には明確な回答がない。クラウドは技術進歩も早く価格競争も激しいので、どのベンダーにおいてもサービスレベルは常に向上していくものと期待され、特定のベンダーから大規模に引越しをしなければならない事態が想定しにくいのが正直なところだ。とはいえ技術進歩の一環として、移行ツールの利便性／カバレッジの拡大も予見される。C2Cはその気になればいつでもできるものになるのではないだろうか。

　付記ながら、ここで述べた議論は、移行すべき台数が多い（十数台以上）場合に限った方がよい。古臭い意見であることを承知の上で言うと、一番確実なのは「手作業でクリーンインストールする」ことだ。急がばまわれではないが、筆者なら、台数が少ない場合はツールに依存しない移行計画を立てると思う。

セキュリティ

　ひところ「パブリッククラウドには大事なデータやシステムは預けられない」という議論があったが、そろそろ終息に向かっているようだ。大事なものだからこそ「クラウドを一番に考える」（クラウドファースト）という企業が増えている。個人の場合に照らすと、大切な資産を銀行に預けるか、タンス預金にするか、どちらが安全かは考えるまでもない。同様の考え方が、企業システムにおいても一般化しつつある。クラウド業者はセキュリティに最大限の配慮をしているのだ。私自身、半ば暴言承知で、「ユーザーさんの手元にオンプレミスで抱えておくより、パブリッククラウドの方が1000倍安心ですよ」と言い放つことがあるが、最近は同調していただけることが増えている。

　さて、このとき、クラウドサービスのセキュリティレベルの高さを、どのように確認したらよいだろうか。従来であれば、ユーザーがベンダーに対して山のように質問を投げたり、実際に現地訪問するなどして確認していたケースもあるだろう。しかし、数千から数十万のユーザーがいるといわれるクラウド事業者が、個別にこのような相談に対応していくことは現実的ではない。全て対応していればコストも掛かり、それは最終的なサービス価格の上昇につながってしまうだろう。また、ユーザー側も決してセキュリティの専門家ではないという点に留意したい。チェック事項には漏れがあるかもしれないし、回答を精査するノウハウも、プロには劣るという点は自覚しておきたい。

　この点をカバーするのが、クラウドベンダーが第三者機関から取得しているセキュリティ認証である。詳解は避けるが、いわゆる「86号監査証明書」や「SSAE16」などを取得しているかどうかは1つの目安になる。「ISO27001」や「PCI-DSS」の取得状況も参考にするとよいだろう。当然、それぞれの認証の趣旨をよく理解しておく必要はある。

　なお、これらの認証は排他的なものではないことは注意したい。実際、重複している部分も多いといわれており、取得している認証の数の大小を議論してもあまり意味がないように思われる。取得している認証の数では、AWSが間違いなくトップだろう。他のクラウドベンダーも追従する姿勢を見せている。

機器の持ち込み

　パフォーマンスの確保や、独自のセキュリティポリシー上の要請により、特殊な機器（ハードウェア）を用いなければならないシステムがまれに存在する。クラウド上の仮想インスタンス＋ソフトウェアで、同等の機能や性能が確保できないとなると、機器の持ち込みを検討せざるを得ない。

　ネットワーク構成上、当該機器をオンプレミス側（ユーザー側）環境に置き、クラウドとハイブリッド運用することも不可能ではないが、クラウド側に置いた場合と全ての点において同等になることを保証することは難しい。特にパフォーマンス面では不安が残る。

　この時、クラウド側に、ユーザー独自の機器の持ち込みが前提となることがあり、筆者もシステムインテグレーター（SI）の立場で、そのような事案（複数）の提案に関わったことがある。

　機器の持ち込みが可能なクラウドは限られている。いわゆる洋物クラウド（AWS、Windows Azure、Google Cloud Platform）では100％不可能だ。国産クラウドの幾つか（IIJ-GIO、BIGLOBEクラウドホスティングなど）は対応している（関連記事：ユニークなサービスで差別化を図る「BIGLOBEクラウドホスティング」）。大手ベンダー系クラウド（IBM SmarterCloud Enterprise）も相談は可能なようだ。

　機器の持ち込みは、そもそものパブリッククラウドの趣旨からは逸脱している感もあり、筆者の好みではないが、当面、一定の需要があることは確かである。逆に、「クラウド移行を契機に、独自機器の利用を止めたい」という相談もあり、全体的なニーズとしては徐々に減少していくのではないかと推察している。

事例

　実は一番多い問い合わせは「事例」だ。クラウド導入を検討しているユーザー企業と「同業種で、類似システムの事例はないか？」という問い合わせは非常に多い。先進的なユーザーはこのような質問はしてこないので、クラウド活用がマジョリティ化してきた1つの証左ともいえるだろう。同業他社が活用しているとなれば、社内の検討が進むという事情もありそうだ。

　クラウドベンダー各社のWebサイトを注視すれば、必ず事例紹介のページがあるので、確認するところから始めたい。AWSは、内外のケーススタディが豊富に掲載されている。米国ならではのNASAの巨大システムの件や、2012年の大統領選挙での活用（関連記事：【技術解説】オバマ再選に学ぶ、巨大なシステムをクラウドで運用するには？）も日本語で公表されており、同社が事例公開に並々ならぬパワーを注いでいることが伺える。ニフティクラウドは事例集を冊子の形で配布している（Webで取り寄せができる）。IIJも長いWebページ（インデックスだけ。ここから個々の事例詳解ページにジャンプできる）を用意している。

　ここで掲載されている事例は、公開に関してユーザーの合意が得られたものだけなので、網羅的でないという点は留意すべきだろう。システムの用途（DRや個人情報管理）やユーザーの業界（金融、保険など）によっては、情報公開に消極的にならざるを得ず、事例として少なく感じられることもありそうだ。必要に応じてベンダーやパートナーSIerに質問してみるのもよいだろう。また、ユーザー会や情報交換イベントなどが盛んなクラウドサービスがある。このような場はユーザー同士のカジュアルな情報交換も活発に行われる機会でもあるので、積極的に活用したい。

　とはいえ、しょせんはITインフラの用途の話である。本質的にはサーバ＋データセンター＋インターネット接続であり、使い道は無制限、ユーザーも多種多様だ。類似事例の有無にこだわって利用をためらうことは、むしろビジネスチャンスを喪失しているのではないかと思われてならない。クラウドはこれから普及が本格化するテクノロジーでありビジネストレンドでもある。事例がないからこそ面白いのであり、他人が使っていない用途であるからこそ得られるメリットも大きいといえるのではないか。クラウドを全面的に採用すると宣言する大手企業も出始めている。読者各位におかれても、積極的な活用を検討するとよいだろう。本稿がそのための一助となれれば幸いである。