クラウドをめぐるリアルな戦い（経済ジャーナリスト 深川孝行）

※『IT批評 0号 特集：システム×ストーリー』（2010年6月刊行）より深川孝行さんの「クラウドをめぐるリアルな戦い」を転載。

クラウドをめぐるリアルな戦い

ＩＴ事業を支えているのはインフラである。このインフラをめぐって、２つの大きな戦いが起きている。１つはデータセンター建設、もう１つは携帯電話のアンテナ建設である。仮想空間の覇権を目指し、リアルな駆け引きが繰り広げられている。

「コンテナ型」で後塵を拝す日本

　
　世界のコンテナ取扱港ランキングで、大きく順位を下げる日本の港湾。「物流のハブ」は釜山やシンガポールに先を越され、このままでは「辺境」にもなりかねない。

　しかし、クラウド・ビジネスの「キモ」ともいうべき、「情報」の集散地、「データセンター」についても、日本のスタンスはこのままでは「物流の二の舞」となりかねない状況で、しかもキーワードがまたしても「コンテナ」なのだから皮肉というほかない。

　ＩＴで先頭を走る米国では、データセンターといえば今や「コンテナ型」が主軸となりつつある。これは、まさに「コンテナの中に数百〜1千強ものサーバと、付属する配線類やストレージ、冷却装置など必要機材を丸々詰め込み、データセンターの最小単位を構築したもの」と定義すればいいだろうか。

　まさに「モジュール化」だ。筐体には国際標準であるＩＳＯ６６８の「20フィートコンテナ（1TEU）。６ｍ×２・４ｍ×２・６ｍ」や、この2倍の「40フィート（全長約12ｍ）／２TEU」を流用するのが主流。サーバ収容能力はメーカーや冷却方式などでばらつきがあるものの、２TEU の場合で１５００〜１７００Ｕ（サーバーユニット）といったところ。

「コンテナ型」の最大の「ウリ」は2つ。１つは、「コスト」、そしてもう１つは「機動性」だ。まず前者だが、既存の「建物型」の場合、鉄筋コンクリート製上屋の建設には莫大なコストと時間・手間が掛かる。だが「コンテナ型」ならば極端な話、敷地さえ確保できれば、数週間で巨大なデータセンターを持つことが可能だ。生き馬の目を抜くＩＴ界において、「工期1年」などという悠長な施設建設はもはや「リスク」以外の何ものでもない。瞬時にデータセンターを立ち上げ、ビジネスチャンスを逃さない。「コンテナ型」が支持される所以がここにある。

　実際米国では、地下駐車場やビルの屋上、既存の倉庫など、空きスペースを有効活用する形でコンテナを敷き詰めた即席のデータセンターが活躍している。

　また「建物型」の場合、サーバの設置や増強のたびにＳＥや配線業者など技術者の応援を必要とする。一方「コンテナ型」は工場で量産されるので、その後内部をいじくる必要はない。予定地に「ポンポン」と並べて、配線や冷却水用のホースを繫げれば増設・更新は完了。まさに「フルターンキー」そのものの発想である。ちなみに冷却方法には水冷式、空冷式の２方式があるが、昨今の環境配慮の風潮とランニングコストの面から、外気を使った空冷式へと主軸が移りつつある。

　また電力消費量に関しても、「コンテナ型」は「建物型」に比べて秀でているという。コンテナという必要最小限の空間だけを重点的に冷やせばよく、またコンテナの筐体を通じて直接外に放熱される部分もあるため、結果的にエネルギーロスが少ないという。

　一方後者だが、これは1にも2にも「国際標準の１／２TEU コンテナに、データセンターを収納した」という発想が秀逸だ。国際標準コンテナならば、世界中の船舶や鉄道、トレーラー、港湾のクレーンなど既存の物流システムにそのまま載せることができる。そのメリットは計り知れないだろう。

「まさに広大な国土を誇る米国ならではの発想。内陸の長距離輸送は貨物鉄道、最寄りの貨物駅から目的地まではトレーラー、さらに海外展開にはコンテナ船と、積み替えが容易。加えてコンテナの筐体そのものを〝入れ物〞として使うので、空になったコンテナを『通い箱』よろしく持ち返る手間もない。また戦略上データセンターを移動させたい時は、短期間で撤収できるし、さらに不必要になったデータセンターをコンテナごと転売するのも楽。『建物型』ではこうはいかない」

　と、某物流企業の幹部も舌を巻く。

　一方、某大手電機メーカー幹部も、「米国で『コンテナ型』が支持されているということは、早晩これが世界のデファクトスタンダードとなることを意味する」と、「コンテナ型」への早急なる対応を示唆する。

対日進出を図る米国の巨人たち

　
　さて、｢コンテナ型｣を最初に具体化したのは米サン・マイクロシステムで、２００６年10月に「ブラックボックス」というコードネームで公表、周囲をあっと言わせた。（現在は「サンＭＤシリーズ」という商品名）

　これを契機に、米ＩＢＭ（ＰＭＤＣ＝ポータブル・モジュール・センター）、ＳＧＩ（ＩＣＥキューブ）、ＨＰ（ＰＯＤ）、マイクロソフト、ＨＰ、グーグルなど並み居る「ＩＴの巨人たち」も怒涛のように「コンテナ型」市場に参戦。ラッカブル・システムズやヴェラリー・システムズなど、あまり聞きなれない米ベンチャーたちも同市場の成長性に目をつけて参入しているが、とりわけ前者は注目だろう。インテル製プロセッサーを搭載したサーバなどを大中規模データセンター向けに販売するベンダーとして旗揚げ。その後急成長を遂げ、なんと先に挙げたＳＧＩを２００９年に買収した実力派。つまりＳＧＩがリリースした「ＩＣＥキューブ」とは、実は「ラッカブル仕込み」というわけで、今年春から日本への売り込みもスタート。国内でも定評のある「ＳＧＩ」ブランドで勝負に臨む。

　もちろん日本進出を図っているのはＳＧＩだけではない。むしろ先鞭をつけたのは〝先駆者〞サンであり、ＩＢＭやＨＰなども続々と橋頭堡を築きつつある。

ＩＩＪの〝孤軍奮闘〞

　では対する日本側の状況はどうか。結論から言って周回遅れの感は否めない。

　米国勢の「コンテナ型」に相当するものは、今のところインターネットイニシアティブ（ＩＩＪ）が推進するモジュール型データセンター計画で、東芝やＮＬＭエカル（日本軽金属系）、能美防災、河村電器産業の協力のもと今年2月から実証試験を開始、6月からはいよいよ来年の商用化に向けた施設建設に着手した。外気冷却方式を採用したコンテナユニットとしては本邦初で、節電・省エネにこだわり、既存のものに比べ消費電力を40％ほど削減した点が特徴。この辺りは「エコ大国」である日本らしい味付けだ。

　施設の概要としては、電源・空調関係を集中制御する「コア・サイト」を中心に、独自サイズのコンテナ５コを最小単位（1基）として計４基、合計20コのコンテナを配すというもの。日本の道路法規を踏まえ独自サイズを採用したようだが、汎用性を念頭に置くならば、むしろＩＳＯ規格を採用すべきではなかっただろうか。「ガラパゴス」的発想に一言、苦言を呈しておきたい。

　その収容するサーバは全体で5千台規模を見込むが、実は常に実動するのはこのうちの３基のみで残りの1基＝コンテナ５コ分はローテーション用の予備となっている。つまりコンテナ15コで５千台のサーバとなり、1コ平均約３３０台のサーバ収容能力となる。この値は米国勢と比べて遜色ない。

　第1期として5モジュール（サーバ１６００台。１コンテナ当たり３２０台）分を約11億円掛けて〝建設〞する見込みで、その後も需要に応じて増築していくようで、当座は同社が展開するクラウドサービス「ＩＩＪ ＧＩＯ」のインフラとして供されるという。

　ＩＩＪの試みは、わが国の「コンテナ型データセンターの夜明け」として意味深く、また完全露天型で費用対効果にも優れている点などが注目される。

立ちはだかる建築基準法

　
　このように国産化もなんとか軌道に乗りつつあるようだが、わが国における「コンテナ型」ビジネスには、さまざまな障壁が立ちはだかる。実はこうした規制の網が日本での普及・開発を阻害した、とも言われているのだ。

　その最大のカベとは「建築基準法」で、「コンテナ型」が現状では「建築物」として扱われるもようで、「建築物」となれば、コンテナ内に消防・消火設備などの設置が義務付けられるのだという。また設置の仕方にも、例えば基礎工事や通路の構築、耐震基準、果てには建蔽率といった問題も出てくるだろう。なんともし難い「お役所仕事」で、これではクラウド大国を目指すわが国は自縄自縛そのものだ。しまいには、こうした建築基準法を奇貨として捉え、立体駐車場風な構造物を提案する企業までもが現れている。大手ゼネコンなどである。

　またわが国の道路事情にも問題が多い。１TEU は問題がないのだが、２TEU を牽引するトレーラーともなると、その重量や長大さから、必然的に通過できる道路が限られてくる。一般的には高速道路やバイパスのような高規格道路などに制限される。加えて２TEU のなかでも少々背の高いサイズのものがあるのだが、これに準拠した「コンテナ型」では、トンネルや立体交差で頭がつかえてしまうため、さらに通過できる道路が制限されてしまう。この辺になるともはやわが国の「鎖国的道路・物流行政」の弊害、というほかない。

　また、地震大国ニッポンであるため、地震に対する耐久性・安全性について懸念する声もある。地面に「コンテナ型」を直接置いただけで、果たして安全なのか、という懸念だ。

　しかし、事情通はこう断言する。

「例えば、広大な農地の遊休地を利用して、設置場所に特殊なゴム製シートや線路の敷石などを敷き詰め、そこに『コンテナ型』を置き、後はワイヤーなど簡単な固定具で安定させれば、相当揺れてもまず倒れることはない。要は〝いかに安く上げるか〞が『コンテナ型』のキモ。コンテナ自身にもある程度の耐震装置が施されており、内部のサーバが破壊されることは少ないだろう。『それでも倒れたらどうするのだ』との指摘もあるが、逆にそれほど強力な地震の場合、果たして『建物型』であれば１００％大丈夫というのだろうか。建物自体が無事でも、インフラ部分が寸断され使用不能ならば結果は同じだ」

　こうした議論は、新ビジネスが起こるたびに巻き起こる「規制緩和」論議と一緒で、監督官庁の一つである総務省の原口一博大臣も業を煮やしたかのようにTwitter 上で「何のためのコンテナか」と、憤りを呟いている。

　また、これを受けてか総務省は水面下で「データセンター特区」の構想を練っているとの報道が今年4月、一部報道で持ちあがった。それによれば建築基準法や消防法を緩和し、「コンテナ型」を導入しやすい特区を北海道か東北に設けることを主眼とした内容らしく、整備には５００億円を投じるという。

　一部には、「クラウドという名を借りた公共事業、『箱モノ行政』の復活か」と批判的な声もすでにあがっているが、「現に今年はじめ、グーグルの幹部がお忍びで北海道の帯広を訪れた、とのうわさが地元で広く囁かれている。おそらくデータセンターの物色ではないか」（事情通）
　との情報もある。

　仮にこの話が事実だとすれば、〝天下〞のグーグルがデータセンターの戦略的拠点として十勝を重要視している、ということになる。事実、米国の巨大ＩＴ企業は北海道・東北地方を「アジアのデータセンター拠点」として近年注目しているのだ。

　その理由は主として２つ。１つは成長センター、とくに中国に近い箇所に拠点を構えたい、という戦略的理由からと、もうひとつは前述したように冷却コストが安く済むということである。前者の場合、先に起きた中国政府によるグーグルサイト検閲の〝暴挙〞を考えても分かるように、データセンターの拠点を中国本土に置くのは、あまりにも危険すぎる、という認識が急速に高まったからである。また日本と北米大陸の間には太い海底ケーブルが何本も通っているため、ネットワーク構築にもなんら問題はない、とも見ているようだ。

　事実グーグルが構想するグローバル・ネットワーク戦略「グーグル・スパナー」では、世界5カ所にサーバ拠点を構築、ここに投入されるサーバ数は実に１００万〜１０００万台というとてつもない規模のようで、その内アジアには１拠点を構える目算だ。仮に日本にこれが舞い込むとすれば、場合によっては最大２００万台を擁するデータセンターの出現となる。これを「コンテナ型」（２TEU で1０００台収容）に換算すると、実に2０００コにも及ぶ。

「これを集中配置するのか、さらにある程度、分散配置するのかは分からないが、仮に2０００コものコンテナを集中配置するともなれば、これだけで地域活性化が図れるだろう。仮に十勝平野だと仮定すれば、平坦で広大な土地はいくらでもあるし、降雪もそれほど酷くはない。青森県の八戸地域もいいだろう。問題は付近にコンテナ港や空港があるかだが、前者は釧路港と帯広空港が、また後者には八戸港と三沢空港がある」（事情通）

　米系企業からの熱い視線にデータセンター特区構想。「クラウド大国」を目指す日本としてはコンテナ型データセンターをキーワードに「アジアの情報ハブ」を構築する絶好の機会だ。

　後は彼らが進出しやすいように最大限のお膳立てをする努力をすべきだろう。

スマートフォン市場が主戦場

　さて、データセンターにまつわる話から打って変わり、お次は「携帯電話」をめぐる熱き戦いの話である。主人公はソフトバンク（ＳＢ）とケータイの巨象・ＮＴＴドコモ。

　現在、両者は「スマートフォン」で火花を散らしているが、一昨年放った米アップル製iPhone の大人気で、国内スマートフォンシェアの実に７割を確保したＳＢにまずは軍配が上がるだろう。その勢いは周知のとおりだ。だがドコモも巨象の沽券を懸けて、米グーグル製の携帯端末向けＯＳ「アンドロイド」を搭載した「エクスペリア」を投入、ジリジリとシェアを伸ばしてきている。

　さて、これだけだと単なる新型携帯の販売合戦にしか思えないが、両社がこれほどまでスマートフォンに力を入れるのには理由がある。

　クラウドが進展すれば、そのインターフェース、とりわけパーソナルな情報端末として携帯が浮上することが明らかだからだ。しかもその主軸は間違いなくスマートフォンとなる。

　今年末ドコモはＬＴＥサービス化を開始する。いわゆる「３・９世代（３・９Ｇ）」と呼ばれるもので、通信速度（下り）は最大で１００Ｍ。つまり現行の光回線に匹敵する速度だ。現行の３Ｇ携帯の通信速度（最高7Ｍ程度）と比べても10倍以上のスピードとなる。この高速通信を使えばクラウドサービスはおろか、フルハイビジョン動画などリッチコンテンツのやり取りもストレスなく行えるはずで、iPad をはじめとするタブレット型端末の普及にも拍車が掛かる、と両者は目論む。

　ただし、ドコモの３・９Ｇ開始が今年末であるのに対し、ＳＢのサービス開始は翌年以降と少々タイムラグがある。この間ドコモが「高速通信」を武器に攻勢をかけた場合、ＳＢは苦戦を強いられる。同社の〝総帥〞孫正義氏にとっては気が気でないシナリオだ。

　当面はiPhone、iPad 人気で乗り切れるかもしれないが、敵もさるもの、現行のエクスペリアでは利用できなかった「ｉモード」の利用を可能にしたり、ＧＰＳ機能を駆使して地域情報などを提供するサービス「ｉコンシェル」を展開したりなど、ＳＢの「スマートフォン快進撃」に逆襲を図っているのが現状だ。

アンテナ論争

　こうしたなか、孫氏は最近「アンテナ」に関する発言がとみに多くなってきた。今年春に行われた同社の２０１０年３月期決算説明会でも、会場に映し出されたパワーポイント全１０６ページのうち、なんと24ページをアンテナや基地局に割くほどの熱の入れようだ。

　そして孫氏はここで「フェムトセル」の効用を力説して見せた。「フェムトセル」とは手の平サイズのミニ基地局のことで、家庭で普及している無線ＬＡＮ用の基地局と似たようなものだ。

　これとWi-Fi との組み合わせが、これからのモバイルインターネット時代のネットワークには最適、と孫氏は断言するのである。

　一体どういうことか。既存の携帯無線インフラは、一般的に広域をカバーする巨大なアンテナ「マクロセル」を主軸にし、さらにこれを補完する形で、ビルの屋上などに設置されている中型のアンテナ「マイクロセル」がエリア内に数カ所構築されている。ドコモのネットワークはその典型だ。

　しかし後発であるＳＢにとって、ドコモと競う形でマクロセルを林立させるのはあまりにも分が悪い。というのも携帯ユーザーが多く存在する場所は大都市の中心部であるため、大きなアンテナはおろか、マイクロセルといえども場所確保が至難の業だからだ。いい場所はすでに先発のドコモやＫＤＤＩ（ａｕ）が確保済みで、互いの電波干渉を考えれば、あまり接近して設置もできない。しかも都会ともなれば〝場所代〞も馬鹿にならず、巨額なコストとして経営を圧迫しかねない。しかしだからといって「つながりにくい」ではユーザーは離反してしまう。それでなくてもＳＢは、ドコモやＫＤＤＩが有する周波数帯「８００Ｍヘルツ帯」を有していないため、かなりのハンディを負わされているのである。

「８００Ｍヘルツ帯」はいわゆる「回り込み」ができる電波で、例えば建物の陰やちょっとしたビルのなかにでも十分電波が行き渡る。対してＳＢは「１・５Ｇヘルツ帯」が主軸で、「回り込み」に乏しい電波に甘んじているのが実情だ。つまりあまねくカバーするにはドコモやＫＤＤＩよりもアンテナを多く立てなければならないのだが、前述のとおり立地場所は少なく、またコストも掛かる。

孫氏の秘策

　このジレンマを断ち切るために孫氏が編み出した秘策が「フェムトセル」の〝ばら撒き作戦〞である。マクロセルやマイクロセルをさらに補完する形で、市井に無数のフェムロセルを設置すれば、「つながりにくさ」を解消できるという発想である。

　この戦略を実行すべくすでにＳＢは今年５月からＳＢモバイルユーザーを対象にフェムトセルの無料提供を実施、加えてＡＤＳＬサービスも「タダ」で供与するという〝大盤振る舞い〞で臨む。各家庭や店舗・事業所にくまなく設置されれば、来るべき３・９Ｇにも十分対応できる、という読みだ。

　しかし、このフェムトセル、下りの無線速度は最大14Ｍ程度に過ぎない。「これで一体高速通信が可能なのか」と考えてしまうが、孫氏の理論ではこうだ。例えばマクロセル１基のカバーエリア内に、仮に５００人のユーザーが一斉に高速通信を利用するとした場合、１００Ｍの通信速度を誇ったとしても1人あたりの通信速度は２００Ｋにまで落ちてしまう。しかし、これをフェムトセル40基で補えば、理論上40倍までアップする。実際は前述のとおりフェムトセルの能力以上には上がらないのだが、それでも「マイクロセル」一辺倒よりも、フェムトセルによる補完のほうが高速通信をより安定的に確保できる、と孫氏は訴えるのである。

　ちなみに孫氏が「ダメだ」と暗に訴える「マクロセル至上主義」を唱える相手とは、ご承知のとおりドコモである。

「携帯事業でもっとも大変なのはアンテナ確保。まさに土木事業」
　と、強調する孫氏。

　クラウド・ビジネスのカギを握るもう1つの領域、携帯では、キャリア間のアンテナをめぐる泥臭い「陣地取り合戦」が繰り広げられている。

※『IT批評 0号 特集：システム×ストーリー』（2010年6月刊行）より深川孝行さんの「クラウドをめぐるリアルな戦い」を転載
『IT批評』
http://shinjindo.jp/contents/it.html [リンク]