クラウドコンピューティングの社会インフラとしての特性と緊急時対応における課題に関する調査- 調査報告書 -2012 年 9 月

［改訂履歴］
日付

改訂内容

2012 年 9 月 28 日

報告書初版発行

2012 年 10 月 9 日

東日本大震災におけるクラウドの利活用の実態と課題 事例の追加

調査実施者：

株式会社野村総合研究所
独立行政法人情報処理推進機構
技術本部セキュリティセンター
情報セキュリティ分析ラボラトリー

目次
調査の背景と目的 .............................................................................................. 1
I. クラウドが社会インフラとして浸透している実態とその機能停止が社会経済に与える影響の定性的評価 .................................................................................. 3
1. クラウドの社会インフラとしての浸透の実態と課題（実態調査その１） ................... 3
1.1. 個人間の通信・情報共有手段のサービス基盤としてのクラウド .......................... 4
1.2. 消費者向け電子商取引のシステム基盤としてのクラウド ................................. 19
1.3. 企業の生産販売、企業間情報連携等の情報インフラとしてのクラウド .............. 36
1.4. 重要インフラ等の情報インフラとしてのクラウド ................................................ 58

2. 東日本大震災におけるクラウドの利活用の実態と課題（実態調査その２） .......... 73
2.1. 調査の概要 .................................................................................................... 73
2.2. 調査の方法 .................................................................................................... 73
2.3. 調査の結果 .................................................................................................... 73
2.4. 東日本大震災に関するクラウドサービスの有効性の検証結果 ........................114

3. 東日本大震災におけるデータセンターの緊急対応の実態と課題（実態調査
その３）............................................................................................................ 116
3.1. 調査の概要 ................................................................................................... 116
3.2. 調査の方法 ................................................................................................... 116
3.3. 大規模災害時におけるデータセンターの対応と課題 ......................................117

4. クラウドの機能停止が社会に与える影響の定性的評価 ...................................139
4.1. 実態調査のまとめ ........................................................................................ 139
4.2. クラウド停止の影響 ...................................................................................... 140
4.3. 最近発生したクラウドの大規模障害とそこから抽出されるセキュリティ課題 .... 141

II. クラウドが備えるべきレジリエンシ及びディペンダビリティを実現するためにクラウド事業者ならびに社会システムが満たすべき要件の調査 ............................. 143
1. 問題認識 ........................................................................................................143
2. 現状の取り組みと課題 ....................................................................................144
2.1. 対応の前提となる想定リスクの考え方を見直す必要性 .................................. 144
2.2. データ・システムのバックアップの確保に関する現状 ..................................... 145
2.3. BCP（事業継続計画）による準備の現状 ....................................................... 147i2.4. 平常時からのファシリティ面の対策 ............................................................... 147
2.5. 平常時におけるライフラインの冗長性確保 .................................................... 148
2.6. 緊急･災害時における代替ライフラインの確保 ............................................... 149
2.7. 緊急･災害時における代替ライフライン確保のための二次的サプライの要件 .. 149
2.8. データセンターの運転ならびに保安のための要員に関する要件 .................... 149
2.9. 緊急・災害時におけるセキュリティ対策、ならびに意図を持って行われるサイバー攻撃に対する防衛または回避 ............................................................... 150
2.10. 中小事業者、ベンチャー等の提供するクラウドサービスのリスクへの対応 ..... 151

3. クラウド事業者ならびに社会システムが満たすべき要件 ..................................152
3.1. 想定外のリスクならびに動的なリスクへの対応.............................................. 152
3.2. トリアージの枠組みにおける考え方の例 ....................................................... 157
3.3. 個別の取り組みで満たすべき要件 ................................................................ 162

III.システムやベンダーの枠を越えたデータセンター間連携やクラウド間マイグレーシ
ョンを可能にするために必要な諸要素の調査 .............................................. 164
1. 問題認識 ........................................................................................................164
1.1. 欧米の動向 .................................................................................................. 164
1.2. 日本の動向 .................................................................................................. 165

2. 現状の取り組みと課題 ....................................................................................167
2.1. 事業者の認識 .............................................................................................. 167
2.2. 先行的な取り組み事例 ................................................................................. 167

3. クラウド間連携等の実現に向けた諸要素.........................................................169
3.1. クラウド間連携がスムーズに実現するための技術的要件 .............................. 169
3.2. クラウド間連携における契約や取り決め等の要件 ......................................... 175

IV. 今後官民が取り組むべき課題の提起 .......................................................... 180
1. クラウド事業者およびその他の事業者、社会システムが満たすべき要件の全体像 ............................................................................................................180
2. 官民が取り組むべき課題 ................................................................................181
2.1. 基本的な考え方 ........................................................................................... 181
2.2. 具体的な施策............................................................................................... 183

おわりに ......................................................................................................... 185

ii

調査の背景と目的
クラウドコンピューティング 1の社会への普及が進んでいる。従来はオンプレミス 2で運用されてきた企業や行政機関の業務システム、水道などのライフラインの管理システム、電子カルテなどの医療に関するシステムなど様々な重要インフラに属するシステムにおいてもクラウドコンピューティングが用いられるようになってきている。また、様々な消費者向けクラウドサービス 3の出現により、一般国民が生活で利用する電子商取引やエンターテインメン
ト、個人のコミュニケーションやデータの格納などでの利用も活発に行われている。それらが震災等の非常時対応に役立つ要素があることを踏まえると、クラウドコンピューティング
はもはや「社会インフラ」になりつつあると言え、その利用はさらに拡大すると予想される。
しかし、地震、津波、風水害などの様々な自然災害による、クラウド 4を担うデータセンタ
ーの被災、通信回線の不通、電源喪失または電源不足等の原因や、近年著しいサイバー
攻撃によってクラウドコンピューティングが停止した場合に、社会経済や国民生活に及ぼす影響の規模と範囲ならびに被害の深刻さが、従来考えられていたよりも広がっていることが想定される。
このように、クラウドコンピューティングがさらに普及し、社会インフラとしての役割の重さが増すことに伴って、これらの災害や情報セキュリティリスクに対する耐性が強く求められることになる。特に、ITシステム等が外部環境の変化による障害等に遭っても所期の機能・状態に一定程度回復する能力「高回復力性＝レジリエンシ（resiliency） 5」や構成要素の一部の不具合による影響を排除して、外部に対して所期の機能やサービスを提供し続ける能力「機能保障能力＝ディペンダビリティ（dependability） 6」の向上が必要であると考えられる。
本調査においては、上記の視点からクラウドコンピューティングが社会インフラとして浸透していく中で、その役割を果すために充足すべき課題を明らかにすることを目的として、以下の内容について調査検討を行った。


クラウドコンピューティングの社会インフラとしての普及実態の把握

社会インフラとして求められるの高回復力性、機能保障能力の視点からの事業継続
ならびに情報セキュリティ・緊急時対応に関する課題の抽出



緊急時対応における課題を解決し、社会インフラとしてのサービスを継続していくた

1 大規模データセンターにおいて仮想化等の技術を用いてコンピュータの機能を用意し、それをインターネット経由で自由に柔軟に利用する仕組みの総称。
2 情報システムにおいて自社で用意した設備でソフトウェアなどを導入・利用する自社運用のこと。
3 クラウドコンピューティングに基づいてサービスの形で提供される IT の機能。
4

クラウドコンピューティングおよび／またはクラウドサービス。

5 広義には、「インシデントに影響されることに抵抗する組織の能力」（事業継続マネジメントシステム
6

BS25999）とされる。
「実行された仕事 (service) がどの程度正しく行われているかを明らかにするための品質 (quality)を示すもの」（J.C. Laprie, 1985）という定義を参考とした。

1

め、システムやクラウド事業者 7の枠を越えた連携やマイグレーションを可能とするために必要な諸要素の把握

これら社会インフラとして求められる特性を実現していくために官民が取り組むべき
課題の抽出

7

クラウドコンピューティングまたはクラウドサービスを提供する事業者。

2

I. クラウドが社会インフラとして浸透している実態とその機能停止が社
会経済に与える影響の定性的評価
1.

クラウドの社会インフラとしての浸透の実態と課題（実態調査その１）
本節では、クラウドが社会インフラとして広範に浸透している実態を把握するとともに、大規模災害やサイバー攻撃等によって機能停止に陥った場合の影響の度合いを明らかにするため、文献調査、インタビュー、ならびにアンケート調査を行った。
対象分野は以下の 4 つの領域における情報システム基盤である。
• メールやソーシャルネットワーキングサービス（SNS）等の個人間の通信・情報共有手段
これらのサービスは、先の東日本大震災において固定電話や携帯電話などに並んで、被災状況や救援依頼、安否確認等に大きな力を発揮した。そのため、今後も個人間の有力な通信・情報共有手段として成長していくものと考えられる。また、スマートフォン等の端末機器の発達と相まって、「つぶやき」や写真投稿による個人の情報発信や、「チェックイン」による位置情報等の情報収集を容易に行えるようになっており、緊急時に現場末端の生の情報を収集するプラットフォームとしても重要となってきている。
• 消費者向けの電子商取引（BtoC EC 8）
ネット通販やネットスーパーに代表される BtoC EC は、過疎化が進む地方等において日常生活を支える商店が失われた状況においても、住民の生活を支える大きな役割を担っている。今回の震災の被災地においても仮設店舗や移動販売等と並んで住民のライフラインを支えたとみられている。
• 企業の生産販売や企業間情報連携（BtoB 9）
企業の生産活動はIT 10に大きく依存している。また生産販売活動における企業間の分担・連携、いわゆるサプライチェーンは高度に複雑に発達している。先の震災において、東北地方に所在する製造業が被災し生産が停止したことで、ここから出荷される部品の供給が停止したことから、国内の他地域のみならず海外においてもサプラ
イチェーンに大きな影響を及ぼした。このことから、企業の受発注や生産販売管理等のサプライチェーンマネジメントに用いられるコンピュータシステムが停止した場合には、経済社会に対して与える影響も大きいものと考えられる。
• 重要インフラ等の社会基盤
内閣官房情報セキュリティセンター（NISC 11）では、情報通信や金融等の 10 分野
8

Business to Consumer Electronic Commerce

Business to BusinessInformation Technology 情報技術
11 National Inforamtion Security Center
9

10

3

を「重要インフラ」として指定している。これらの重要インフラが、情報システムの停止によりサービスを停止するとすれば、社会に与える影響は非常に大きいと考えられる。
次項からは、上記の 4 分野それぞれについて調査結果を述べる。

1.1. 個人間の通信・情報共有手段のサービス基盤としてのクラウド
1.1.1. 調査の概要
本項では、個人間の通信・情報共有手段の代表的サービスであるソーシャルネ
ットワーキングサービス（以下、SNS）やメールサービスにおける、同サービス運営
上でのクラウドへの依存度について、図表 1 に示した SNS・メールサービス事業者への聞き取りや文献などにより把握した。
SNS およびメールサービスを運営する企業は、データセンターを自社で所有しているケースが多く、内部のシステムではクラウドコンピューティングを採用していない例もあると考えられるが、サービスのエンドユーザが情報等を外部ネットワークに保存できる、という意味ではクラウドサービスの定義に該当すると考え、調査を行った。

図表 1 調査対象事例
事例名称

概要

Google• Web 検索サービスを母体としたポータルサイト

mixi• ソーシャルネットワーキングサービス（日記、メッセージなど提供）

Windows Live

• 電子メールを含む Web サービスとクライアントソフトウェア（アプリケーション）

Yahoo! Japan• Web ディレクトリサービスを母体としたポータルサイト@nifty• 電子メールやブログを含む Web サービスを母体としたポータルサイト

地域 SNS• 地域コミュニティに根付いたソーシャルネットワーキングサービス

41.1.2. 対象事例
（1） Google （米 Google Inc./グーグル株式会社）① サービスの概要
Google は 1998 年に米国で創業された、ウェブ検索サービスを母体にしたポー
タルサイトである。近年では、メールサービス Gmail を初め、多様な個人向けの無料サービスを提供しているほか、スマートフォン用 OS の Android やウェブブラウ
ザの Chrome などのソフトウェアプロダクトも発表し、無償配布している。
② サービスの普及度
Googleは全体のユーザ数を体系的には明らかにしていないが、いくつかのサービスにおいて、利用者数が断片的に発表されている。Gmailの利用者数は2012 年 4 月の同社からの発表 12によれば全世界で 3.5 億アカウント、Google+
では、2012 年 3 月の発表 13によれば月間アクティブユーザ数は 1 億人超、1 日のアクティブユーザ数は 5,000 万人である。
なお、これらのユーザ数には個人だけではなく法人ユーザも含まれている。
③ Google のクラウド利用の状況
Google のサービスにはポータルサイトを中心とした個人向けサービスの他、業務向けクラウドサービスである Google Apps for Business / Education が存在するが、本項では個人向けサービスについて述べる。
日本国内で利用できる個人向けのコミュニケーションサービスの主なものは以下の通りである。これらはいずれも Google の構築したクラウド上での SaaS として提供される。
• Gmail：電子メールサービス• Google ドキュメント：文書、スプレッドシート、プレゼンテーションの作成アプリ
ケーションの SaaS
• Google カレンダー：予定表、連絡先、To-Do 管理等の SaaS
• Google グループ：グループウェアの SaaS
• Google+：ソーシャルネットワーキングサービス• Google ドライブ：オンラインストレージサービス
内部システムから見ても、Google のサービスの大半は数ペタバイトにも及ぶ大12

Googel Inc. “2012 Update from the CEO”
http://investor.google.com/corporate/2012/ceo-letter.html
13 発表の原文は入手できないが、インプレス社「InternetWatch」（http://internet.watch.impress.co.jp/docs/news/20120307_517083.html）等で報道されている

5

規模データを、世界中に設置している数十万台のサーバに格納した巨大分散データストアである Bigtable を運用基盤として提供されている。
④ 障害事例とその影響2012 年 4 月 18 日午前 1 時頃（日本時間）、Gmail にアクセスできないという障害が発生した。全ユーザの 10%弱に影響があったとされる。メールの消失等は発表されていないが、障害に巻き込まれたアカウントではメールの配送が遅延する可能性があるとしている。この障害は、発生して約 1 時間後にすべての影響アカウントで復旧している。先に述べた Gmail のユーザ数 3.5 億人から推定すると、2012 年 4 月の障害によって、日本の首都圏の人口に匹敵する 3,500 万人程度が、約 1 時間電子メールの利用ができなかったことになる。
Gmail では 2011 年 2 月にもストレージソフトウェアのアップデートの際にソフトのバグによる障害を起こしている。このときにはユーザの 0.02%に影響があり、一部のユーザのメールが消失する問題が発生している。このときにはバックアップデ
ータなどからのメールの復旧を行っている。
このようにクラウドサービスの利用が普及したため、障害の影響が大規模に及ぶようになったことが、実例でも改めて明らかになったと言える。
⑤ 東日本大震災時の対応・利用状況
東日本大震災においては、個人の安否確認や被災地支援のために「Crisis
Response」を提供した。同サービスは 2005 年にハリケーン・カトリーナが米国を襲った際に被災者とその周辺が必要な情報を常に取得できるように提供を開始し、専用のサービスチームを配置する事で 24 時間体制での対応を可能にしている。
震災発生から 2 時間後には同サービスの日本語版を公開し、被災者の検索および情報取得の機能をもつ「パーソンファインダー」の利用を可能にした。「パーソンファインダー」は安否情報をユーザが簡単に登録・閲覧できるもので、登録件数
は開始直後には約 3,000 件だったが、翌月には 60 万件超を記録した。グーグル
社は各自治体やメディアとの連携を早め、情報公開用のファイルフォーマットも公開フォーマットであるPFIF 14を使用するなど、データ統合を容易にしている。震災発生の翌月である 2011 年 4 月には、「パーソンファインダー」のペット版である「アニマルファインダー」も公開している。
また、動画配信サービスである「Youtube」において、発災直後から TV ニュース
番組のライブストリーミングを提供した。それ以外にも、「Google マップ」による被災
地の衛星および航空写真の提供、交通遅延情報およびそのタイムテーブルの提供、東北地方のビジネスを支援するサイト・チャンネルの提供なども行い、積極的
14

PeopleFinder Interchange Format 被災者情報共有のための XML ベースのデータフォーマット

6

に震災後の情報整理や復興支援に寄与している。
このように日常だけではなく、大規模災害時においても個人のコミュニケーショ
ン手段を確保するとともに、状況に応じた柔軟なサービスの提供が可能であることが確認された。

（2） mixi（株式会社ミクシィ）① サービスの概要
mixi は日本における SNS（ソーシャルネットワーキングサービス）で最大規模を誇っている。主なサービス内容は、以下のようなものがある。
•

ユーザ個人の投稿を起点とし、コメントや「いいね!」ボタンの反応等でコミュニケーションを図るもの：日記、mixi ボイス、フォト、動画、レビュ
ー、mixi チェックなど•ユーザの 1 対 1 のコミュニケーション：メッセージ•

ユーザが開設したグループでのコミュニケーション：コミュニティ•

ソーシャルアプリケーションやソーシャルゲームを仲介としたコミュニケーション：mixi アプリ② サービスの普及度
2012 年 3 月時点での登録ユーザ数は 2,711 万人、うち月に 1 回でもログインしたユーザが 1,512 万人である。サービス開始以来、ユーザの投稿数は 7 億回を超える。
ユーザ属性を見ると、年齢では 20 代と 30 代が中心になっており、性別で見ると、男性が 47%、女性が 53%となっている。地域別に見ると、首都圏が全ユーザ中40%と圧倒的に多く、近畿の 17%がそれに続く。
利用実績は、2012 年 3 月の総ページビュー（PV）が 200 億 PV 程度であった。

7

図表 2 mixi の会員属性

出所）株式会社ミクシィ 2011 年度 通期決算説明資料
http://v4.eir-parts.net/DocumentTemp/20120731_111436874_es4zxjmccblpfgylylkx2a45_0.pdf（2012 年 6 月現在）

③ クラウドの利用状況
mixi のサービスのうち、mixi アプリと呼ばれるソーシャルアプリケーションは、外部のクラウドサービス（Microsoft、ニフティ、Amazon、Google など）と連携して提供されている。mixi アプリは、サードパーティでも開発・提供が可能であり、サード
パーティは mixi が持つ顧客基盤や課金プラットフォームなどを利用して、mixi 会員を対象としたサービス提供とビジネス展開が可能となっている。
mixi アプリの公開後のユーザ数の増加が急激であること、ユーザ数の伸びが鈍化してからもリクエストが多いことがアクセスの特徴として上げられており、mixi
アプリ提供者にはサービスを停止させないためにサーバ等の能力の整備が求められている。なかでもクリスマス等のイベント時におけるキャンペーンと連動したソーシャルアプリにおいては、短期間に大容量のアクセスが発生し、時限的に終了
するといった特徴があり、クラウドが多く利用されている。これは、クラウドサービスの特徴であるサービス立ち上げの速さやスケーラビリティ確保の容易さなどを活かした利用方法と言える。
たとえば毎年クリスマスシーズンに提供される「mixi クリスマス」は、アプリケーシ
ョンに表示されたクリスマスベルを鳴らすことで、キャンペーンの当選確率が上がるなどの特徴を持ったアプリである。2011 年は 11 月 30 日から 12 月 25 日まで公開された。12 月 20 日の時点で 250 万人の登録があった。期間中は 1 日平均 110
万人以上がアクセスし、約 1.8 億回以上もベルが鳴らされるなど、膨大なアクセスがあったことがうかがえる。

8

この mixi アプリのサービス基盤はマイクロソフトが提供する Windows Azure
Platform を用いている。ユーザの急激な伸びに対する、インフラの迅速な拡張などの対応が、円滑に行われたとされている。
なお、この他のサービスの内部システムについては、クラウドコンピューティングの技術を用いていないとのことであった。
④ 障害事例とその影響mixiでは 2010 年 8 月 10 日に断続的にアクセスがしづらくなる障害が発生した。
同社の発表 15によると、データキャッシュシステムの不具合により、8 月 10 日と翌 11日の 2 度にわたって障害が発生し、サービス閲覧を中止して復旧作業を行った。最終的に問題が解消したのは 31 時間後であった。
1 日以上のサービス停止によって、単純計算で月間利用の 3～4%程度に影響が出たと考えられる。前述した月間 200 億 PV から推定すると、6～8 億 PV に相当す
るトラフィックが失われたことになる。このことは、ユーザ側から見ると、情報入手ある
いはコミュニケーションの機会が、6～8 億回分失われたことになるとも考えられる。
⑤ 東日本大震災時の対応・利用状況
東日本大震災では、全体ユーザの 5.4%を占める東北のユーザとその周辺を中心に、「mixi」の各種機能を用いた被災地・被災者についての情報交換が活発に行われたことが報告されている 16。
mixi の SNS としての本来の機能が、ユーザの創意工夫によって安否確認に活用されている。その代表的な例は以下の通りである。
• mixi 上の友人「マイミクシィ」のログイン時間表示の確認• 日記や一言メッセージ「mixi ボイス」投稿の確認• 位置情報公開サービス「mixi チェックイン」の確認
このうち 1 番目は、マイミクシィのリスト表示において、それぞれのマイミクシィが最後にログインした時刻を「1 時間以内」「1 日以内」のように表示できるため、これを安否確認に用いたものである。すなわち、最近にログインが行われている表示があれば、生存が確認できることになる。運営側でもこのような利用に応えるため、2011 年 3 月 16 日には、マイミクシィ登録しているユーザのログイン履歴が一覧で閲覧できるウェブページを設置し、各ユーザがより簡単に被災者の状況を把握できるようにした。また、2 番目はユーザが書き込める日記やより短いメッセージであ15

株式会社ミクシィ報道発表資料（2010 年 8 月 12 日）
http://mixi.co.jp/wp-content/uploads/2010/08/20100812.pdf （2012 年 6 月現在）
16 総務省「大規模災害等緊急事態における通信確保の在り方に関する検討会 インターネット利用ワー
キンググループ」 第 3 回 資料 3-5 株式会社ミクシィ説明資料
http://www.soumu.go.jp/main_content/000120217.pdf （2012 年 6 月現在）

9

るボイスの書き込みを見て、そのユーザの安否を確認するものである。これらの書
き込みはスマートフォンや通常の携帯電話からも容易に行えるため、個人の安否確認には有用であった。さらに 3 番目のサービスは、携帯電話ならびにスマートフ
ォンから位置情報を付して mixi に簡単なメッセージを投稿するもので、通常はレストランなどの街情報に関する情報などが書き込まれる。これを現在位置登録に使う例が見られ、mixi 上の友人に自らの安全と所在を明らかにするために用いられた。
また、震災関連情報を交換できるコミュニティを地域別（市町村、自治体など）や目的別（救援物資、炊き出しなど）に分けて作成し、情報の整理を行った。そのうちの大きなコミュニティでは約 35 万ユーザの参加が確認されている。
このような利用によって mixi へのアクセスが増加した。mixi ボイスでは、平常時の利用に比べ震災直後は投稿数が 8 倍に増加し、その後数日にわたり平常時の2 倍程度の投稿が行われた。写真などと合わせて投稿できる日記は、被災地である東北エリアからの投稿数が平常時に比べ 44%増加した。
これに対応して運営者側もサーバを平常時よりも数台多く設置し、急激なアクセス増加に備えた。他の設備面も確認し、電力供給などインフラ面での問題がない
限り非常時におけるサービスの継続も平常時と変わらず行えるように対応を行った。

（3） Windows Live （Microsoft Corp./日本マイクロソフト株式会社）① サービスの概要
Windows Live はマイクロソフトがユーザに無償で提供する Web サービスとア
プリケーションを総称したサービスブランドである。その主なサービス内容は以下の通りである。
Web サービス• Hotmail：Web メールサービス• SkyDrive：オンラインストレージサービス• カレンダー：メールクライアント同期が可能な予定表サービス• フォト：オンラインフォトアルバムサービス
クライアントソフトウェア• メール：電子メールクライアント• Writer：ブログ編集• ムービーメーカー：動画編集、共有• フォトギャラリー：写真、動画の管理、編集、共有• Messenger：テキスト、音声、ビデオチャット
10

② サービスの普及度
Hotmail は公称 3 億 6 千万人のユーザを有しており、Gmail 以上の規模を持つ。
国内ユーザのプロファイルは、日本マイクロソフトが発行する広告主向け媒体資料によると、男性 48%、女性 52%であり、性・年代別には女性 20～34 歳（約25%）、男性 20～34 歳、同 50 歳以上、同 35～49 歳（いずれも 15%台）の順に多い。
③ クラウドの利用状況
電子メール、オンラインストレージ、カレンダー、フォトアルバムから成る Web サービスは、クラウドサービスによって提供されている。クライアントソフトウェアと呼ばれるアプリケーションは、それら Web サービスを利用するためにマイクロソフトから提供されている。ユーザは自身の情報端末からこれらアプリケーションにアクセスすることでサービスを利用できる。
このほかに、マイクロソフトのデスクトップアプリケーションをクラウドで提供する有料サービス「Office365」があり、個人や中小企業のユーザを獲得している。
④ 障害事例とその影響
2011 年 9 月 8 日、HotmailとSkyDriveを含むWindows LiveサービスとOffice
365 サービスに 2 時間半にわたってアクセス障害が発生した。マイクロソフトでは代替サービスを立ち上げたが、DNS 17の書き換えを伴ったため、ネットワーク全体への波及に時間を要し、全ユーザがアクセス可能になるまでにはさらに相当の時間を要した。このトラブルの原因は、米国内における停電の影響と言われている。
Hotmail では 2010 年 10 月 31 日（日）午前 7 時～11 月 4 日（木）午前 11 時
頃にも日本国内ユーザ（当時のアクティブアカウント約 510 万）のうち、最大 9.4 万アカウントにアクセス障害と一部のユーザのメール消失が発生している。この原因は日本国内におけるサーバのハードウェア障害であったと言われている。
このように、クラウドを利用する際には、リスクが複数の場所に分散することにも留意する必要がある。

（4） Yahoo! Japan （ヤフー株式会社）① サービスの概要
Yahoo! Japan は、ウェブディレクトリサービスを起源に持つポータルサイトであ17

Domain Name Service11る。メールやオークション、ショッピングなど多様なサービスを提供している。本節の対象となる個人のコミュニケーションに関わるサービスは以下の通りである。
▪

Yahoo! Japan メール：Web メールサービス▪

カレンダー：予定表の SaaS▪

アドレス帳：住所録の SaaS▪

掲示板：ユーザが自由にテーマを設定し、ディスカッションを行う
BBS（Bulletin Board System）サービス▪

グループ：グループウェアの SaaS▪

ブログ：日記などを記入、公開できるサービス▪

メッセンジャー：チャットなどを提供する IM（Instant Messenger）
サービス▪

Yahoo!ボックス：オンラインストレージサービス▪

Yahoo! Japan オークション：個人でも出品できるオークションサー
ビス② サービスの普及度
Yahoo! Japanでは無料会員と有料のプレミアム会員が存在している。無料・有料会員を合わせた月間のアクティブユーザ数は 2012 年 1～3 月の平均で 2,640
万人、プレミアム会員は 2012 年 3 月末で 780 万人となっている 18。全国民の 20%に当たるユーザがアクティブにアクセスしている計算になる。
また、Yahoo! Japanメールのアクティブユーザ数は 2010 年 11 月末現在 1,750
万人 19、Yahoo!ボックスのユーザ数は 2012 年 1 月現在 100 万人 20である。
③ クラウドの利用状況
Yahoo! Japan の個人のコミュニケーション手段として提供されているサービスのうち、クラウドを利用しているのは Yahoo! Japan メールと Yahoo! ボックスが代表的なものである。
他のサービスについても、SaaS として提供されており、エンドユーザから見た姿はクラウドサービスと見ることができる。

18

ヤフー株式会社 2011 年度第 4 四半期および通期決算説明会プレゼンテーション資料
http://i.yimg.jp/i/docs/ir/archives/present/2012/jp0424present-all.pdf（2012 年 6 月現在）
19 総務省「利用者視点を踏まえた ICT サービスに係る諸問題に関する研究会」迷惑メールの対応の在り方に関する
検討 WG（第 4 回会合） （2010 年 12 月 20 日） 資料 1「迷惑メール報告機能」について（ヤフー株式会社）

http://www.soumu.go.jp/menu_sosiki/kenkyu/riyousya_ict/39449.html（2012 年 6 月現在）
20 Yahoo! Japan 広報からのお知らせ（2012 年 1 月 20 日）
http://blogs.yahoo.co.jp/yj_pr_blog/22069576.html（2012 年 6 月現在）

12

④ 障害事例とその影響
Yahoo! Japan では 2010 年 10 月 13 日 23 時 30 分ごろから同サイトのトップページに接続できない障害が発生した。他のサービスのページは機能していたが、トップページが接続不可だったため、各サービスのページに接続しにくい状態になっていた。約 2 時間後に復旧した。後日、原因はロードバランサーのハードウ
ェア障害であることが明らかとなった。
Yahoo! Japan では同様のシステム障害が各サービスにて小規模に発生して接続しにくくなることはあったが、この場合は全てのサービスの入り口となるトップページの接続障害であり、全サービスへの接続に影響を及ぼした。本事例は、ウェブサービスの起点となる部分の影響力がいかに大きいかを示した事例と言える。
⑤ 東日本大震災時の対応・利用状況
ヤフー株式会社からの報告 21によれば、Yahoo! Japanでは大規模災害等の非常時における対応について準備を進めていた。震度 3 以上の地震が発生するとヤフー内の震災関連サービスの担当者全員にメールで通知が届き、震度 6 以上の場合は担当者が時間に関わらず出社して対応にあたる。2005 年からは、それまで東京オフィスのみで行っていたウェブサイトの更新・編集機能を大阪オフィスにも設置して二重化を図っていた。
このような準備もあり、東日本大震災が発生した際も迅速な対応が可能であった。震災直後の 2011 年 3 月 14 日には、サイト開設以来最高となる 23 億 6500
万 PV のアクセス数を達成している。被災地からのアクセスは通常の 40%程度だ
ったものの、インターネットによる災害情報の受発信に大きく役立ったと言える。
コンテンツにおいても災害対応を行った。災害関連情報をまとめた特設ページを開設し、災害関連の情報を一元的に閲覧できるようにしたほか、「Yahoo! ボランティア」ページでは震災直後から被災地・被災者向けの募金受付を開始し、「Yahoo! 天気情報」ページでは NHK のニュース映像のライブ配信を行った。こうした複数のページにわたる同時対応にあたっては、各ページの担当者間でのYahoo!メッセンジャーによる連絡が活用された。
震災の経験を踏まえ、2011 年 7 月に「Yahoo!メッセンジャー」上で各種災害情報を受け取れるサービスである「防災速報」を開始するなど、災害時の情報提供機能を強化している。

21

総務省「大規模災害等緊急事態における通信確保の在り方に関する検討会 インターネット利用ワー
キンググループ」 第 3 回 資料 3-2 古閑構成員（ヤフー株式会社）説明資料
http://www.soumu.go.jp/main_content/000120214.pdf （2012 年 6 月現在）

13

（5） @nifty （ニフティ株式会社）① サービスの概要@nifty はパソコン通信の nifty-serve を起源に持つ、接続事業者系のポータル
サイトサービスである。接続会員向けに始められたメールや情報サービスから発展して、現在では接続サービスを利用しなくても有料または無料でサービスを利用することができる。本節の対象となる個人のコミュニケーションに関わる主要なサービスは以下の通りである。
▪

mail@nifty：メールサービス▪

@nifty ココログ：日記などを記入、公開できるブログサービス▪

@nifty マイキャビ：オンラインストレージサービス▪

@nifty バックアップ：PC のクラウドへのバックアップサービス▪

@nifty ホームページサービス：Web ページのホスティング② サービスの普及度
ISP接続サービス会員を含めた会員数は 2012 年 3 月現在で 1,170 万人である。
このうちISP接続会員（174 万人）を除いた、各種サービスのみを利用している会
員は 996 万人である 22。
③ クラウドの利用状況
Web サービスの一環として、個人向けメールと法人向けのビジネスメールを提供している。ニフティ自身の認識は Web サービスであるが、Gmail と同様のクラウ
ドベースのメールサービスである。以前よりサーバは仮想化技術を用いている。
このほかにニフティクラウドとして IaaS サービスを行っている。
④ 障害事例とその影響2012 年 6 月 7 日、個人向けメールおよび法人向けのビジネスメールサービス、
ブログサービス「ココログ」、ニフティクラウドにアクセスおよび利用がしにくい状況が発生した。影響を受けた全てのサービスが障害から復旧するまでには 12 時間以上を要した。この原因は同社の発表 23によるとデータセンターの電源装置の故障とされている。
この際、ブログサービス「ココログ」にてハードウェアの数を減らした縮退運用を一時的に行わざるを得なかった結果、ユーザによる日記投稿などに遅延が生じる
2 次障害が 24 時間以上に渡って発生した。
22 ニフティ株式会社「2011 年度通期決算説明会プレゼンテーション資料」
23

http://www.nifty.co.jp/ir/pdf/20120426_01.pdf（2012 年 6 月現在）
ニフティ株式会社「6 月 7 日に発生した大規模障害の復旧について」
http://www.nifty.co.jp/release/2012/pdf/nifty20120608.pdf （2012 年 6 月現在）

14

⑤ 東日本大震災時の対応・利用状況
ニフティでは過去に阪神淡路大震災でも支援活動を行った経験を活かし、ボラ
ンティアサイトの認証システムを開発・提供したほか、被災地で見つかった写真をクリーニングしてクラウド上で公開し、所有者を探すシステムの「思いでサルベージ
オンライン」など、複数のサービスの提供を行っている。また、自社サーバを所有している大企業に対して、計画停電や地震の再発に備え、システムの DNS を一時的にニフティのシステムに切り替えてデータの安全性、業務の継続性を担保する「メールの保険サービス」も、発災後数ヶ月に渡って提供を行った。詳細は、「2．
東日本大震災におけるクラウドの利活用の実態と課題（実態調査その 2）」で述べる。

（6） 地域 SNS① サービスの概要
地域 SNS は、ICT を活用し地域社会の「人のつながり」を作り強化することで地
域社会の活性化を目指す取り組みの一環として、2004 年の末に熊本県八代市で始まり、全国で急速に拡大している。地域 SNS は地元で開催されるイベントの掲載をはじめ、地元住民による日記や掲示板への投稿など、地元住民とそこへ訪れる観光客のコミュニケーションの場になっており、平時の利用以外にも、近年は災害発生時など非常時における活用に対する期待度が高くなっている。2008 年に発生した岩手・宮城内陸地震の際には、盛岡市の地域 SNS「モリオネット」で行われていたユーザ間の自発的な情報交換が、住民間での情報共有に役立った。
② サービスの普及度
国際大学 GLOCOM の調査では地域 SNS の事例は 2006 年 2 月には 21 事例だったのに対し、2010 年 2 月の 519 事例まで拡大したが、これををピークに減少を続けている。
代表的な地域 SNS プラットフォームの一つ、兵庫県のインフォミームが開発・運用する「OpenSNP」は、2011 年 2 月時点で以下のような規模となっている。これは、OpenSNP を利用して構築されている地域 SNS サービスの合計値である。
• 地域ＳＮＳ登録者数:約 6,000 名• アクセス数:101,400 件/月• ページビュー:2,289,000PV/月• データ転送量:60.54GB/月• コミュニティ書き込み数:1,000 件/月• ブログ書き込み数:15,800 件/月• メッセージ数:14,000 件/月
15図表 3 地域 SNS の運営数の推移

出所）地域 SNS 研究会 Web ページ
http://www.local-socio.net/2012/03/snssns354.html（2012 年 7 月現在）

③ クラウドの利用
地域 SNS は So-net 提供の ASP サービスを使った運用で 2006 年以来増加傾向にあったが、2010 年 6 月の So-net のサービス終了に伴い、閉鎖する SNS
や、運営者が所有するサーバでの運用に移行する SNS が増えていた。このことが上述の減少傾向をもたらしたと考えられる。
しかし、東日本大震災発生時に、仙台市の河北新報社において自社の Web サイトが被災し情報発信ができなくなった際、クラウドサービス上で運営していた東北地域 SNS「ふらっと」に携帯電話回線で接続し、「ふらっと」を活用して情報発信を継続した事例が注目され、それをきっかけに地域 SNS が見直されている。
「ふらっと」などの事例を受け、「OpenSNP」など SNS プラットフォームを提供するクラウドサービスへの移行による、非常時に備えた対策を講じる地域 SNS が増加している。三重県松阪市の地域 SNS「松阪ベルネット」では、2011 年 6 月にそれまで設置していた自己保有サーバ上での運用から ASP 型に切り替えている。

1.1.3. クラウドの浸透実態と課題
本項で見てきた、SNS やメールサービス等の個人間の通信・情報共有手段におけるクラウドの利用状況、および障害事例とその影響等について、図表 4 にまとめた。個人向けに提供されているサービスにおけるクラウドの利用は、量的な拡
大のみならず、提供されるサービスの種類も拡大しており、利用の範囲と態様が多16

様化していることがわかる。
まず、量的な側面の拡大について見る。今回取り上げたサービスにおけるユー
ザ数はグローバルなサービスでは億人単位、国内中心のサービスであっても千万人単位に上っている。このことから、クラウド停止の影響は従来考えられていたより
も広範囲にわたることが予測される。実際に起こった障害事例においても数万人（homail の国内サービスの例）から数千万人（Gmail の例）と、多くのユーザに影響を与えている。
次に、適用サービスの多様化について見る。初期のクラウドサービスはメールサービスから始められていることが多かったと考えられる。その後、Google カレンダ
ー、Google グループ等の個人・グループ向けの SaaS へと発展し、Yahoo!ボック
ス等のオンラインストレージやオンラインバックアップが提供されるに至っている。
近年では、オンラインストレージサービスが発展して Instagram や YouTube 等の画像や動画を共有するサービスなども出てきている。
このことは、クラウドの障害の影響を受けるデータの種類が増えたことを意味する。以前であれば、影響を受けるのはメールであり、多くは着信時に目を通してし
まえば用が済んでしまうような情報である。また必要があれば再送してもらうことも可能であった。ところが、オンラインストレージや共有サービス上に画像、動画、書類など多様なデータが置かれるようになれば、データが消失してしまうと再生不可
能な情報も少なくないと考えられる。また、バックアップとしてクラウドを使った場合には、障害によってバックアップの機能を果たさないケースも考えられる。
一方、多くのサービスでメールアドレスを起点とするログイン認証を行っている。
このことは、メールアドレスによるログインが障害を起こしてしまうと、あらゆるサービ
スにアクセスできなくなる可能性があることを示している。このように、一つのクラウ
ドサービスの障害が、他のクラウドサービスの障害に連鎖していく可能性は、従来考えられていなかったリスクである。
以上のように、クラウドサービス利用の量的拡大と多様化によって、影響ユーザ数の増大、影響を受けるサービスやデータの拡大、さらにはクラウド障害の連鎖の恐れが高まっており、クラウドのサービス継続に対する要求がより高まってきているものと考えられる。

17

図表 4 調査対象事例のまとめ
サービス名
主要な
サービス内容Googlemixi

Windows Live
メール
カレンダーSaaS
オンラインストレージ
オンラインフォトアルバム
チャット

メール
ドキュメント作成 SaaS
カレンダーSaaS
住所録 SaaS
グループウェア SaaS
SNS
オンラインストレージSNS（日記、メッセージ、画像・動画共有、コミュニティ等）

サービスの普及度Gmail：3.5 億アカウント(2012 年 4 月）
Google＋ユーザ：
１億人/月、5000 万人/日(2012 年 3 月)

登録ユーザ：2700 人
ログインユーザ数：
1512 万人/月（2012 年 3 月）

Hotmail：3.6 億アカウント

クラウドの運用状況

電子メール、ドキュメント作
成、カレンダー、グルー
プ、ＳＮＳ などをクラウドで運用
Gmail で 障 害 、利 用 者 の10％に影響（2012 年）

イベント開催時にスケーラ
ビリティ確保を目的として運用

電子メール、カレンダー、
オンラインストレージ、オン
ラインフォトアルバムをクラウドで運用
日本国内の hotmail ユーザ
940 万 人にア ク セス障 害（2010 年）

災害支援サービスを複数提供

災害関連情報交換を mixi
コミュニティ上でユーザが自主的に実施、運営側もサーバを平常時よりも多く設置して急激なアクセス増加に対応

障害事例と影響

震災時の対応1 日以上のサービス停止（2010 年）Yahoo! Japan
メール
カレンダーSaaS
住所録 SaaS
BBS
グループウェア SaaS
ブログ
チャット
オンラインストレージ
アクティブユーザ：2600 万人/月
有料会員：780 万人（2012 年 3 末）
メールユーザ数：1,750 万人（2010 年 11 月末）
オンラインストレージ：
100 万人（2012 年 1 月）
電子メールおよびオンライ
ンストレージをクラウドで運用

ウェブサイトの更新を 2 拠点で可能にし、震災特設ページで震災関連情報を発信

18@niftyメール
ブログ
オンラインストレージ
オンラインバックアップ
ホームページ作成

地域 SNSSNS（日記、メッセージ、コミュニ
ティ等）

登録ユーザ：1170 万人（2012 年 3 月）

登録ユーザ：6,000 人（プラットフォーム OpenSNP
を利用している地域ＳＮＳに限る）

電子メール、ブログ、ベー
シックホスティングなどほぼ全てのサービスをクラウドで運用
ココログに障害、縮退運用のため一部ユーザに 24 時
間以上にわたってサービスの一部を制限
災害支援サービスを複数提供

一部地域ＳＮＳがクラウドで運用

大きな障害の事例はない

震災直後に各コミュニティの情報 交換の場と し て機能

1.2. 消費者向け電子商取引のシステム基盤としてのクラウド
1.2.1. 調査の概要
消費者向け電子商取引におけるクラウドコンピューティングの現状と課題の把握を行うために、アンケートを実施した。アンケートは、インターネットにより行い、モニターの中から電子商取引に知見を有する人（例：IT 担当、販売担当、マーケ
ティング担当の方など）向けに依頼した。
• 実施日時：2012 年 3 月 1 日～6 日• 調査方法：インターネット上の調査母集団に対して回答資格の有無を判別するスクリーニング設問を行い、該当者のみに本調査を実施した。
• 回答数：70 サンプル
• 質問内容○消費者向け電子商取引の状況• 店舗形態• 売上規模、推移• ユーザの状況 等○

消費者向け電子商取引を支える技術、とりわけクラウドサービス• システムの保有・利用形態• クラウドを利用する理由• クラウドを利用しない理由 等○

クラウド停止の影響• クラウド停止の影響• 停止等のリスクへの対策 等

19

1.2.2. アンケート集計結果（1） 回答者の属性
70 の有効回答を得た。回答者の内訳としては、57%が製造業（消費者向け電子商取引は直販ビジネスとして展開）、小売業はインターネット専業、通信販売、店舗併営合わせて 29%であった。
図表 5 回答者の業種分布
0.0%

2.9%

4.3%

小売業（インターネット専業）

0.0%
小売業（通信販売）
小売業（店舗併営）

24.3%
卸売業

57.1%

製造業（消費者向け電子商取引は直販ビ
ジネスとして展開）
インターネットモール運営

11.4%

その他

（2） 消費者向け電子商取引の状況① 店舗形態
全体で見ると 80%が自前のサイト運営、EC モールは 33%である。業種別には
小売業では EC モールでの出店が多く、製造業では自前のショッピングサイトでの販売が多い。

図表 6 インターネット上の店舗形態（n=70）
0%

20%

40%

100%

55.0
20.0
40.0

全体
80.0

自前のショッピング
サイトでの販売

その他

80%

32.9

ECモール
での販売

キオスク端末
上での販売

60%

小売業

65.0
87.5
80.0

製造業
その他

0.0
0.0
0.0
0.0
2.5
10.0

20

② 売上規模
売上規模は 1 千万円未満が 21%、1 億円以上は 19%である。
図表 7 消費者向け電子商取引の売上規模

21

③ 取り扱い品目
取り扱いが多い品目は、その他物品（41%）、食料品・飲料、家電品・PC・PC 関連製品（いずれも 37%）である。
図表 8 消費者向けに電子商取引を行っている品目（n=70）
0%20%

衣料品・アクセサリー

60%

25.7

家電品・PC・PC関連製品
書籍・音楽・エンター
テイメント系ソフト

40%

74.3

37.1

62.9

12.9

87.1

食料品・飲料

37.1

62.9

健康・美容関係品

25.7

74.3

家具・雑貨

24.3

75.7

趣味

17.1

その他の物品

80%

82.9

41.4

58.6

旅行・イベントチケット

8.6

91.4

金融

5.7

94.3

その他のサービス

8.6

91.4

デジタルコンテンツ

12.9

87.1

扱っている

22

扱っていない100%

④ 売上の推移、背景
全体で見ると直近 3 か年では売上が増加している事業者が合わせて 33%、おおむね横ばいが 20%、減少しているは 9%であり、市場は拡大傾向にあると言える。
売上増加の背景は、顧客層拡大を指摘した回答者が最も多い。その要因としては、
時間短縮や品質、価格重視の顧客増が多く指摘されている。
図表 9 消費者向け電子商取引の直近 3 カ年の推移
0%

20%

全体
（n=70）

4.3 5.7

小売業（n=20）

10.0

製造業（n=40）

7.5

12.5

その他
（n=10）

10.0

10.0

60%

40%

22.9

20.0

7.1

20.0

100%

38.6

50.0

20.0

80%

20.0

5.0

10.0

15.0

47.5

10.0

50.0

非常に大きく増加

大きく増加

やや増加

おおむね横ばい

やや減少

大きく減少

非常に大きく減少

わからない

図表 10 電子商取引の売上増加の背景・要因（n=23）
0%

20%

40%

顧客層が
広がった

80%

100%

82.6

顧客の購入
頻度が増加した

39.1

顧客の1回当たりの購入額が増加した

その他

60%

8.7

4.3

23

図表 11 電子商取引の売上増加の背景となった顧客層（n=23）
0%

10%

20%

30%

実際の店舗での買い物に出るのが難しい人

40%

26.1

時間を短縮したい人

39.1

重いものなどを運びたくない人

17.4

品質を重視する人

30.4

価格を重視する人

30.4

品ぞろえを重視する人や限定・希少品を探している人
その他

50%

26.1
4.3

⑤ ヘビーユーザーの認識
ヘビーユーザー 24の考えについて、回答者の認識を聞いたところ、ヘビーユー
ザーにとって自社の商品・サービスが「日常的な生活に不可欠である」ととらえている回答者は約 16%、「衣食住ほどの基礎的なものではないもののユーザにとってなくてはならない」ととらえている回答者は約 27%と、43%が必需性について肯定的回答であった。
図表 12 ヘビーユーザーの認識（N=70)
0%20%

ユーザーの衣食住などの日常的な生活において、
2.9 12.9
貴社の商品・サービスはなくてはならないものである。
衣食住ほどの基礎的なものではないものの、ユーザーの生活にとって、貴社の商品・サービスは 4.3
なくてはならないものである。
他社の商品・サービスでは代替は難しい。
もしくは、ユーザーは他社の商品・サービスは 2.9
使いたくないと考えている。
大いに当てはまる

40%

15.7

22.9

14.3

15.7

どちらかと言うと当てはまる

80%

18.6

22.9

21.4

どちらかと言うと当てはまらない 全く当てはまらない

60%

17.1

21.4

100%

27.1

0.0

12.9

27.1

0.0

10.0

30.0

0.0

どちらとも言えない
分からない

無回答

⑥ 今後の売上の見込み
自社の電子商取引について、44%以上の事業者が今後売上は増加すると回答しており、減少するとの予測は 5%程度である。とりわけ小売業において増加するとの回答は多い。
今後 3 年程度の電子商取引市場の売上の見込みについては、全体のうち約半
数が日用的な食料品や介護・医薬品の EC 販売は増加すると予測している。また、
24

ヘビーユーザーとは、ここでは、顧客単価もしくは利用頻度が平均的な水準よりも高い顧客を指す。

24

電子商取引市場の売上が増加すると考えた理由としては、高齢化の影響、また調べてから消費するユーザが増える傾向を指摘する回答が多かった。
これらのことから、現状では利用者にとっての重要度が高いとは言えないものの今後は利用の規模や重要度が高まっていくものと考えられる。
図表 13 今後 3 年程度の自社の電子商取引の売上の見込み
0%20%

全体(N=70) 2.9 10.0

40%

31.4

18.6

小売業(N=20) 5.0 5.0

10.0

27.5

10.00.0

100%

31.4

10.0 5.0 5.0
0.0 15.0

20.0

30.0

80%

4.31.40.0

55.0

製造業(N=40) 0.0 12.5

その他(N=10)

60%

2.5
0.0

10.00.0

37.5

40.0

①非常に大きく増加(年率20％以上)②大きく増加(年率10％以上20％未満)③やや増加(年率3％以上10％未満)④おおむね横ばい(年率－3％～3％未満)⑤やや減少(年率－3％以上－10％未満)⑥大きく減少(年率－10％以上－20％未満)⑦非常に大きく減少(年率－20％以上)⑧わからない25

図表 14 今後 3 年程度の電子商取引市場の売上の見込み（n=70）
0%20%

日用的な食料品・飲料の販売

7.1

日用的な衣料品の販売

5.7

60%

44.3

27.1

12.9

34.3

38.6

100%

25.7

28.6

21.4

7.1

80%

22.9

37.1

介護用品、医薬品の販売

その他の日用品、生活雑貨の
販売

40%

31.4

25.7

27.1

大きく増加する

ゆるやかに増加する

横ばいで推移する

ゆるやかに減少する

大きく減少するわからない

図表 15 電子商取引の市場の売上が増加すると考えた理由（n=49）
0%

20%

40%

60%

80%

高齢化の進展により、実際の店舗での買い物に出るのが難しい
人の利用が増えるから

67.3

過疎化や都市部の団地老朽化の進展により、いわゆる買い物
弱者の利用が増えるから

38.8

品質や価格、品ぞろえをイン
ターネットにより調べるユーザーが増えるから61.2

事業者の競争や工夫により、魅力的な商品の増加やサービスの高度化が進むから

24.5

スマートフォンなどの通信環境の高度化と普及によりECでの買い物が行いやすくなるから
その他

分からない

26.5

2.0

0.0

26

（3） 電子商取引を支える技術・クラウドについて
以下では、業務の種類別およびシステムのレイヤーごとにシステムの運用形態を質問し、クラウドの利用の傾向について把握する。
業務の種類は、電子商取引の業務を図表 16 のように分類し、またシステムのレイヤーを図表 17 のようにデータセンター、ハードウェアおよびネットワーク、OSおよびプラットフォーム、アプリケーションと 4 つに分解した。
図表 16 本アンケートで用いた電子商取引の業務の分類(1)商品・サービスの
案内・陳列
販売事業者
（＝貴社）

消費者

(2)商品・サービスの受注(3)代金の支払い・ 決済(4)顧客データの管理・分析

（商品の配送、サービスの提供）(5)販売促進

図表 17 本アンケートで用いたシステムレイヤーの分類

アプリケーション
OS、プラットフォーム
ハードウェア、ネットワーク
データセンター27

① システムの保有・利用形態
商品サービスの案内・陳列でのアウトソース・外部利用が比較的多い。
顧客データの管理・分析はアウトソース・外部利用が少ない。クラウドを利用した
くない業務（後述）としても、もっとも多い（約 25%が利用したくないと回答）。
小売業のほうが製造業と比べると、アウトソース・外部利用との回答割合がおおむね高い傾向にある。
図表 18 システムの保有・利用形態
全体①自社保有
アプリケーション
OS、プラットフォーム(1) 商品・サービスの案内・陳列
ハードウェア、ネットワーク
データセンター
アプリケーション
OS、プラットフォーム(2) 商品・サービスの受注
ハードウェア、ネットワーク
データセンター
アプリケーション
OS、プラットフォーム(3) 代金の支払い・決済
ハードウェア、ネットワーク
データセンター
アプリケーション
顧客データの管理・分析（ロOS、プラットフォーム(4) グ解析、顧客の声の分析なハードウェア、ネットワーク
ど）
データセンター
アプリケーション
販売促進（ITシステムを活用
OS、プラットフォーム(5) した広告、レコメンデーション
ハードウェア、ネットワークなど）
データセンター

52.9
51.4
52.9
30.0
50.0
50.0
48.6
31.4
42.9
40.0
41.4
28.6
50.0
44.3
44.3
34.3
32.9
32.9
35.7
25.7

②アウトソース・
外部利用
20.0
20.0
18.6
32.9
18.6
20.0
18.6
25.7
18.6
18.6
15.7
22.9
10.0
15.7
15.7
15.7
12.9
14.3
12.9
18.6

①②の併用
7.1
5.7
8.6
5.7
10.0
7.1
10.0
8.6
5.7
5.7
7.1
5.7
7.1
8.6
8.6
4.3
11.4
8.6
7.1
5.7

（n=70）
利用していない・
わからない
20.0
22.9
20.0
31.4
21.4
22.9
22.9
34.3
32.9
35.7
35.7
42.9
32.9
31.4
31.4
45.7
42.9
44.3
44.3
50.0

小売業
①自社保有
アプリケーション
OS、プラットフォーム(1) 商品・サービスの案内・陳列
ハードウェア、ネットワーク
データセンター
アプリケーション
OS、プラットフォーム(2) 商品・サービスの受注
ハードウェア、ネットワーク
データセンター
アプリケーション
OS、プラットフォーム(3) 代金の支払い・決済
ハードウェア、ネットワーク
データセンター
アプリケーション
顧客データの管理・分析（ロOS、プラットフォーム(4) グ解析、顧客の声の分析なハードウェア、ネットワーク
ど）
データセンター
アプリケーション
販売促進（ITシステムを活用
OS、プラットフォーム(5) した広告、レコメンデーション
ハードウェア、ネットワークなど）
データセンター

30.0
30.0
30.0
25.0
30.0
30.0
25.0
25.0
25.0
20.0
20.0
15.0
35.0
25.0
20.0
25.0
15.0
10.0
20.0
20.0

28

②アウトソース・
外部利用
30.0
25.0
30.0
25.0
25.0
20.0
25.0
20.0
25.0
20.0
25.0
20.0
10.0
20.0
25.0
10.0
15.0
20.0
15.0
10.0

①②の併用
10.0
10.0
15.0
10.0
15.0
15.0
15.0
10.0
10.0
15.0
10.0
10.0
15.0
15.0
15.0
10.0
15.0
15.0
10.0
10.0

（n=20）
利用していない・
わからない
30.0
35.0
25.0
40.0
30.0
35.0
35.0
45.0
40.0
45.0
45.0
55.0
40.0
40.0
40.0
55.0
55.0
55.0
55.0
60.0

製造業
①自社保有
アプリケーション
OS、プラットフォーム
ハードウェア、ネットワーク
データセンター
アプリケーション
OS、プラットフォーム(2) 商品・サービスの受注
ハードウェア、ネットワーク
データセンター
アプリケーション
OS、プラットフォーム(3) 代金の支払い・決済
ハードウェア、ネットワーク
データセンター
アプリケーション
顧客データの管理・分析（ロOS、プラットフォーム(4) グ解析、顧客の声の分析なハードウェア、ネットワーク
ど）
データセンター
アプリケーション
販売促進（ITシステムを活用
OS、プラットフォーム(5) した広告、レコメンデーション
ハードウェア、ネットワークなど）
データセンター

62.5
60.0
62.5
37.5
65.0
62.5
62.5
40.0
57.5
52.5
55.0
40.0
65.0
57.5
60.0
45.0
45.0
45.0
45.0
32.5

(1) 商品・サービスの案内・陳列②アウトソース・
外部利用
15.0
20.0
15.0
30.0
12.5
17.5
15.0
22.5
12.5
15.0
10.0
20.0
5.0
10.0
10.0
12.5
12.5
12.5
12.5
20.0

①②の併用
5.0
2.5
5.0
5.0
5.0
2.5
5.0
7.5
0.0
0.0
2.5
2.5
0.0
5.0
2.5
0.0
5.0
2.5
2.5
0.0

（n=40）
利用していない・
わからない
17.5
17.5
17.5
27.5
17.5
17.5
17.5
30.0
30.0
32.5
32.5
37.5
30.0
27.5
27.5
42.5
37.5
40.0
40.0
47.5

② クラウド利用の理由
システムコスト（開発・運用）の節減が最も強い理由であり、次いで、安定したシステム稼働との回答が多い。クラウドを利用したくない業務としては顧客データの管理・分析が最も多く、これはセキュリティへの不安が大きく影響している。サービスの安定性に不安との回答も 28%弱に上る。
図表 19 クラウドを利用した理由
将来の業
システムコ 務量増加 高度なシスト（開への対応 ステム機
発・運用） （スケーラ 能への対の節減
ビリティの 応確保）
商品・サービスの(1) 案内・陳列（n=38)

商品・サービスの(2) 受注（n=35)

代金の支払い・決(3) 済（n=28)
顧客データの管理・分析（ログ解(4) 析、顧客の声の分
析など）（n=25)
販売促進（ITシス
テムを活用した広(5) 告、レコメンデー
ションなど）（n=24)

システム
の利用開
始までの
時間の短
さ

自社のIT
人材の不 安定した足を外部 システム
サービス 稼働
で補う

自社シス
テムより情
災害時等
報セキュリ 取引先のの業務継
その他
ティが確 要請
続が容易
保しやす
い

クラウド導入の理由

63.2

21.1

15.8

23.7

21.1

34.2

15.8

23.7

2.6

7.9

もっとも強い理由

52.6

5.3

0.0

5.3

2.6

15.8

2.6

7.9

0.0

7.9

クラウド導入の理由

65.7

28.6

17.1

25.7

28.6

22.9

14.3

14.3

5.7

8.6

もっとも強い理由

42.9

8.6

2.9

8.6

8.6

14.3

2.9

0.0

2.9

8.6

クラウド導入の理由

64.3

17.9

21.4

21.4

17.9

25.0

10.7

14.3

7.1

7.1

もっとも強い理由

46.4

0.0

3.6

7.1

7.1

17.9

0.0

7.1

0.0

7.1

クラウド導入の理由

72.0

40.0

16.0

12.0

20.0

24.0

12.0

12.0

4.0

4.0

もっとも強い理由

60.0

8.0

4.0

4.0

4.0

8.0

4.0

4.0

0.0

4.0

クラウド導入の理由

75.0

29.2

33.3

33.3

8.3

33.3

8.3

16.7

4.2

0.0

もっとも強い理由

54.2

0.0

12.5

8.3

0.0

20.8

0.0

4.2

0.0

0.0

29

図表 20 クラウドなど他社保有のシステム・サービスを利用できない・したくない業務、
その理由

30

（4） クラウド停止の影響① 停止時の業務への影響
各業務について、事業者の約 50～60%が継続できると回答している。有効回答数（N）が少なく、また業務により異なるため、単純に比較はできないものの、停止期間 1 日程度の場合、小売業では約半数が「代替手段はなく業務の継続は困難となる」または「業務の一部に継続できないものが生じる」と回答しているのに対して、製造業では同回答の割合は 30～40%前後である。
図表 21 大規模災害等で仮にクラウドが停止してしまった場合の、自社業務への影響
全体【停止期間１日程度】

商品・サービスの案内・陳列

すべての業務はすべての業務は
代替手段はなく 業務の一部に継継続できるが代 大きな支障なくす
継続できるが業業務の継続は困 続できないものが替手段確保に経 べての業務が継務処理の能力が
難となる
生じる
続できる
済的な負担が発低下する
生する（n=38）
15.8
21.1
34.2
2.6
26.3

商品・サービスの受注（n=35）

17.1

28.6

31.4

2.9

20.0

0.0

代金の支払い・決済（n=28）

14.3

35.7

25.0

7.1

17.9

0.0

顧客データの管理・分析（n=25）

8.0

40.0

32.0

8.0

12.0

0.0

販売促進

（n=24）

12.5

25.0

33.3

8.3

20.8

0.0

その他

0.0

【停止期間３日程度】

商品・サービスの案内・陳列

すべての業務はすべての業務は
代替手段はなく 業務の一部に継継続できるが代 大きな支障なくす
継続できるが業業務の継続は困 続できないものが替手段確保に経 べての業務が継務処理の能力が
難となる
生じる
続できる
済的な負担が発低下する
生する（n=38）
18.4
23.7
28.9
7.9
21.1

商品・サービスの受注（n=35）

14.3

37.1

20.0

14.3

14.3

0.0

代金の支払い・決済（n=28）

17.9

28.6

17.9

21.4

14.3

0.0

顧客データの管理・分析（n=25）

16.0

36.0

20.0

16.0

12.0

0.0

販売促進

（n=24）

16.7

29.2

20.8

12.5

20.8

0.0

その他

0.0

小売業
【停止期間１日程度】

商品・サービスの案内・陳列

すべての業務はすべての業務は
代替手段はなく 業務の一部に継継続できるが代 大きな支障なくす
継続できるが業業務の継続は困 続できないものが替手段確保に経 べての業務が継務処理の能力が
難となる
生じる
続できる
済的な負担が発低下する
生する（n=13）
7.7
38.5
38.5
0.0
15.4

商品・サービスの受注（n=11）

9.1

54.5

18.2

0.0

18.2

0.0

代金の支払い・決済（n=10）

0.0

50.0

20.0

0.0

30.0

0.0

顧客データの管理・分析

（n=9）

0.0

44.4

33.3

11.1

11.1

0.0

販売促進

（n=7）

0.0

57.1

28.6

0.0

14.3

0.0

その他

0.0

【停止期間３日程度】

商品・サービスの案内・陳列

すべての業務はすべての業務は
代替手段はなく 業務の一部に継継続できるが代 大きな支障なくす
継続できるが業業務の継続は困 続できないものが替手段確保に経 べての業務が継務処理の能力が
難となる
生じる
続できる
済的な負担が発低下する
生する（n=13）
23.1
38.5
23.1
0.0
15.4

商品・サービスの受注（n=11）

9.1

63.6

0.0

9.1

18.2

代金の支払い・決済（n=10）

10.0

50.0

10.0

0.0

30.0

0.0

顧客データの管理・分析

（n=9）

11.1

55.6

11.1

11.1

11.1

0.0

販売促進

（n=7）

14.3

57.1

14.3

0.0

14.3

0.0

31

その他

0.0
0.0

製造業
【停止期間１日程度】

商品・サービスの案内・陳列

すべての業務はすべての業務は
代替手段はなく 業務の一部に継継続できるが代 大きな支障なくす
継続できるが業業務の継続は困 続できないものが替手段確保に経 べての業務が継務処理の能力が
難となる
生じる
続できる
済的な負担が発低下する
生する（n=16）
12.5
12.5
31.3
6.3
37.5

商品・サービスの受注（n=16）

18.8

12.5

37.5

6.3

25.0

代金の支払い・決済（n=11）

18.2

27.3

27.3

18.2

9.1

0.0

顧客データの管理・分析

（n=9）

11.1

33.3

33.3

11.1

11.1

0.0

販売促進

（n=11）

18.2

9.1

27.3

18.2

27.3

0.0

その他

0.0
0.0

【停止期間３日程度】

商品・サービスの案内・陳列

すべての業務はすべての業務は
代替手段はなく 業務の一部に継継続できるが代 大きな支障なくす
継続できるが業業務の継続は困 続できないものが替手段確保に経 べての業務が継務処理の能力が
続できる
難となる
生じる
済的な負担が発低下する
生する（n=16）
6.3
18.8
25.0
18.8
31.3

商品・サービスの受注（n=16）

12.5

25.0

25.0

25.0

12.5

代金の支払い・決済（n=11）

18.2

9.1

18.2

54.5

0.0

0.0

顧客データの管理・分析

（n=9）

11.1

22.2

22.2

33.3

11.1

0.0

販売促進

（n=11）

18.2

18.2

9.1

27.3

27.3

0.0

32

その他

0.0
0.0

② 停止等のリスクへの対策
クラウド停止等のリスクへの対策としては、SLA、代替手段への切り替え、自社システム温存が多い。
対策を取っていない事業者も全体の約 30%に上っている。対策をとっていない
理由としては、コストの問題やクラウド事業者に任せきりとの回答が多い。
図表 22 クラウド利用において、サービス停止等のリスクに対応するための対策

図表 23 対策をとっていない理由（n=12）
0%

20%

40%

コストがかかるから

50.0

クラウドサービスを利用している取引の範囲が限られているから

33.3

サービス停止をそもそも想定してい
ないから

16.7

クラウドサービス提供事業者に任せきりにしているから
その他

60%

33.3

8.3

33

1.2.3. クラウドの浸透実態と課題
アンケート調査から明らかになったことを整理する。まず、クラウドに限らないが、消費者向け電子商取引は拡大している。図表 9 に示したように、直近 3 か年で売上高が増加していると認識する事業者が 33%、おおむね横ばいが 20%、減少しているは 9%であった。
この傾向は経済産業省「電子商取引に関する市場調査」（平成 23 年 2 月）においても確認できる。
図表 24 EC市場規模の推移 25

30.0%

4,000,000

3,500,000

3,000,000

20.8%

21.2%

2,533,970

2,495,890

23.7%

25.0%

2,563,100

20.0%

21.5%

2,500,000

2,000,000

1,500,000

2,310,520

12.6%
1,478,750

13.3%

13.5%

1,616,510

1,588,600

2,048,550
13.7%

15.6%
15.0%
1,685,170

1,310,610

EC化率

EC市場規模(億円)

19.8%

10.0%

1,000,000
5.0%
500,000

0

0.0%
2006年
2007年
2008年
広義EC市場規模
狭義EC市場規模

2009年
広義EC化率

2010年
狭義EC化率出所）経済産業省「電子商取引に関する市場調査」（平成 23 年 2 月）

本調査のアンケートでは、40%以上の事業者が今後売上は増加すると回答、減少するとの予測は 5%程度であった。日用的な食料品や介護・医薬品を中心に、
今後 EC の利用は増加することが予想される。
このように EC の市場が増大するなか、EC のシステムにもクラウドが活用されているところは多く、クラウドの社会への浸透が B2C においても徐々に広がっているということができる。アンケートでは、システム開発・運用コストの縮減などを目的に、商品サービスの案内等においてアウトソース・外部利用があることがわかった。
25

広義の EC：コンピューターネットワークシステムを介して商取引（受発注）が行われ、かつその成約金額が捕捉されるもの。
狭義の EC：インターネット技術を用いた、コンピューターネットワークシステムを介して商取引（受発注）が行われ、かつその成約金額が捕捉されるもの。

34

他方、顧客データの管理・分析という業務については、アウトソース・外部利用が少ない。クラウドを利用したくない業務としても、もっとも多く、約 25%の事業者が「利用したくない」と回答している。顧客データ関係のクラウド利用がない理由としては、「情報セキュリティに不安がある」が約 80%に上り、他の業務や他の理由と比べても特徴的である。B2C においては、大量の顧客データとその活用が企業の競争力を左右したり、企業に対する顧客の信頼性の観点からクリティカルであったりすることが多く、クラウド化すると、場合によっては自社のコントールが効きにくくなる可能性が生じることに慎重な事業者も多いことが推察される。
クラウドが万一停止してしまった場合については、50～60%の事業者が「継続できる」と回答しているものの、「一部の顧客に深刻な影響がある」との回答も 45%に上り、クラウドの停止が社会に対して大きな影響を与える可能性が高いことが示唆された。
クラウド停止等のリスクに備えては、SLA、代替手段への切り替え、自社システ
ム温存という対策を講じている事業者が多い半面、対策を取っていないという事業者も約 30%に上る。クラウド事業者に任せきりとしているユーザ企業も多いことが
伺われる。

35

1.3. 企業の生産販売、企業間情報連携等の情報インフラとしてのクラウド
1.3.1. 調査の概要
企業の生産販売ならびに受発注を初めとするサプライチェーンマネジメントを支える情報インフラとしてのクラウドコンピューティングの現状と課題の把握を行うために、アンケートを実施した。アンケートは、インターネットにより行い、モニターの中から、製造業、卸売業ならびに小売業に勤務し、かつ生産販売またはそれに関わる情報システムに知見を有する人（例：IT 担当、生産販売管理業務等の従事者）に回答を依頼した。
• 実施日時：2012 年 3 月 1 日～6 日• 調査方法：インターネット上の調査母集団に対して回答資格の有無を判別するスクリーニング設問を行い、該当者のみに本調査を実施した。
• 回答数：126 サンプル
• 質問内容○ 回答者の属性•

回答者勤務先の属性：業種、規模（資本金、従業員、売上）•

勤務先で行っている業務種類○ 勤務先企業が行っている業務ごとのクラウドの利用実態•行っている業務種類ごとのコンピュータ利用の有無•行っている業務種類ごとのクラウド利用の有無と利用形態•行っている業務種類ごとのクラウド利用の動機•

クラウド利用ができない業務とその理由○ クラウド停止の場合に想定される影響とそれに向けた対応•

クラウド停止に伴う業務への影響（停止期間 1 日及び 3 日を想定）•

クラウド停止リスクへの対応の有無と種類•

クラウド停止リスクへの対応に対する懸念•

クラウド停止リスクへの対応を行っていない理由

36

1.3.2. アンケート集計結果（1） 回答者の属性
回答者の所属企業は、「50 億円以上」が 27%、「10 億円以上 50 億円未満」を含めると 40.5%となっており、比較的大手企業に勤務する回答者からの情報が多く得られた。
図表 25 回答者の勤務先企業の属性

37

業種としては、「最終製品を製造する製造業」や「卸売業」など、サプライチェーンの下流に位置する企業に勤務する回答者が多く、サプライチェーンの中間に位置すると考えられる「中間製品を仕入れ、別の中間製品を製造する製造業」は 7.1%と少なかった。
図表 26 回答者の勤務先企業のサプライチェーンにおける位置

38

（2） 行っている業務
勤務先の企業が行っている業務を企業の生産販売等の機能によって下図（ア）～（ク）の 8 種類に分類した。
図表 27 業務分類

以下の設問では、この区分に従って業務の詳細やクラウドの利用について尋ねている。
勤務先の企業が行っている業務を上げてもらったところ、販売管理、財務会計、
販売計画、調達管理、生産管理の順に多くなっている。ただし最も重要な業務を一つ選んでもらうと、販売管理が 30%以上と最も多く、次いで生産計画（22.8%）となっている。
取り組む業務は当然幅広いが、生産計画や販売の実情を知ることが重要な業務であると考えられている。

39

図表 28 回答者が勤務する企業で行っている業務および重要と考える業務（N=126）
％
0.0

5.0

10.0 15.0 20.0 25.0 30.0 35.0 40.0 45.0 50.0 55.0 60.0
47.6

販売計画

10.9
43.7

生産計画

22.8
42.9

調達計画

2.2
33.3

進捗管理

1.1
47.6

調達管理

6.5
44.4

生産管理

14.1
56.3

販売管理

32.6
53.2

財務会計

9.8

いずれも行なっていない・わ
からない
無回答

27.0
行っているもの0.0
0.0

最も重要な業務

最も重要な業務を回答者の業種別に見てみると、小売業・卸売業では販売管理、製造業では一般に生産計画が多くなっている。ただし、製造業もサプライチェーン
上の位置によって傾向が異なっており、原材料を仕入れて中間製品を製造する製造業では生産計画よりも生産管理が最も重要とする回答が多かった。
図表 29 業種ごとの「重要と考える業務」

小売業
卸売業
最終製品を
製造する製
造業
中間製品を
仕入れ、別の
中間製品を
製造する製
造業
原材料を仕
入れ、中間製品を製造する
製造業
その他

回答
者数
10

販売
計画
20.0

生産
計画
0.0

調達
計画
0.0

進捗
管理
0.0

調達
管理
0.0

生産
管理
0.0

販売
管理
80.0

財務
会計
0.0

無回
答
0.0

20

10.0

10.0

0.0

0.0

5.0

5.0

65.0

5.0

0.0

39

7.7

30.8

5.1

0.0

10.3

12.8

15.4

17.9

0.0

6

0.0

50.0

0.0

0.0

16.7

16.7

16.7

0.0

0.0

17

17.6

23.5

0.0

5.9

0.0

35.3

11.8

5.9

0.0

0

0.0

0.0

0.0

0.0

0.0

0.0

0.0

0.0

0.0

40

（3） 業務へのコンピュータ利用の有無と利用形態
業務ごとにコンピュータ利用の有無を尋ねたところ、ほとんどの業務において「ホストやサーバとパソコン等の端末とで構成される情報システムを利用している」としているものが最も多くなっている。
業務別の特徴は以下の通りである。
• 販売計画や生産計画ではコンピュータを利用しないとするものが少数ながら残っている。また、「パソコンと汎用ソフトのみ」「パソコンまたはオフコンと業務用の専用ソフト」の利用も比率としては大きい。
• 調達管理、販売管理では「パソコンまたはオフコンと業務用の専用ソフト」の利用の比率が大きく、「パソコンと汎用ソフトのみ」は少ない。
• 生産管理、財務会計では「パソコンと汎用ソフト」「パソコンまたはオフコンと業務用の専用ソフト」の利用が多い。
図表 30 業務へのコンピュータ利用の有無と利用形態
0%

20%

40%

60%

80%

100%

販売計画(N=60) 1.7 10.0

15.0

73.3

0.0

生産計画(N=55) 1.8

9.1

76.4

0.0

12.7

調達計画(N=54) 0.0 9.3

7.4

83.3

0.0

進捗管理(N=42) 0.07.1

11.9

81.0

0.0

83.3

0.0

調達管理(N=60) 0.0
3.3

13.3

生産管理(N=56) 0.0 8.9
販売管理(N=71) 0.0
2.8
財務会計(N=67) 0.0

14.3

76.8
83.1

14.1
14.9

14.9

0.0
0.0

70.1

0.0

この業務にはコンピュータは使っていない
パソコンと汎用ソフトのみを利用している
パソコンまたはオフコンと業務用の専用ソフトを利用している
ホストやサーバとパソコン等の端末とで構成される情報システムを利用している
無回答（4） 業務別のクラウド利用の傾向
以下では、図表 27 に示した業務の種類別およびシステムをデータセンター、
ハードウェアおよびネットワーク、プラットフォーム、アプリケーションと 4 つのレイヤーに分解し、そのレイヤーごとにシステムの運用形態を質問し、クラウドの利用の傾向について把握する。

41

① 販売計画
データセンターでは 41%が完全に外部化、25%が併用になっており、自社で運用しているものは 34%にとどまる。しかしながら、アプリケーション、プラットフォーム、
ハードウェア・ネットワークにおいては、60～70%が自社保有となっている。その中でも、アプリケーションについてはやや自社保有の比率が小さくなっている。
今回調査対象とした 8 業務の中では、データセンターの自社保有比率が最も低くなっている。
図表 31 システム利用形態・販売計画（N=44）
0%

20%

40%

60%

63.6

アプリケーション

80%
18.2

70.5

プラットフォーム

100%
18.2

18.2

① 自社保有11.4② アウトソース・外部利用③ ①②の併用

68.2

ハードウェア、ネットワーク

データセンター

34.1

13.6

40.9

18.2

25.0

また、クラウド導入の理由として最も多いのは、「システムコストの節減」、次いで「安定した稼働」、「業務継続」、「高度システム機能への対応」であった。そのうち最も強い理由は「システムコストの節減」で、「将来の業務量増加への対応」がそれに次ぐ。
図表 32 クラウド導入の理由（販売計画）
0

5

10
11
9

将来の業務量増加への対応（スケーラビリティの確保）

510

高度なシステム機能への対応

1
3
0
5

自社のIT人材の不足を外部サービスで補う

1
13

安定したシステム稼働

210

災害時等の業務継続が容易

48

自社システムより情報セキュリティが確保しやすい

2
2
2

取引先の要請1
1

その他

導入理由(N=29)
無回答

42

20
19

システムコスト（開発・運用）の節減

システムの利用開始までの時間の短さ

15

0
0

最も強い理由(N=29)

② 生産計画
全体的な傾向は、データセンターでは外部利用や自社保有との併用が多いものの、ハードウェア・ネットワーク、プラットフォーム、アプリケーションにおいては 60～70%が自社保有している。これは販売計画と傾向が類似している。販売計画と比較すると、全体に自社保有の比率が高く、アウトソース・外部利用の比率が低くなっている。
図表 33 システム利用形態・生産計画（N=42）
0%

20%

60%

プラットフォーム

ハードウェア、ネットワーク

80%
9.5

66.7

アプリケーション

データセンター

40%

100%

23.8

76.2

9.5 14.3

76.2

9.5 14.3

40.5① 自社保有② アウトソース・外部利用③ ①②の併用

21.4

38.1

クラウド導入の理由は、「システムコストの節減」、「安定したシステム稼働」、「災害時の業務継続が容易」という順番に多い。「将来の業務量増加への対応」、「高度なシステム機能への対応」が他の業務に比べて多くなっていることが特徴的である。
最も強い理由は「システムコストの節減」、次いで「災害時等の業務継続が容易」が続く。
図表 34 クラウド導入の理由（生産計画）
ラウ 導

(

産

)

5

0

10

14

システムコスト（開発・運用）の節減

88

将来の業務量増加への対応（スケーラビリティの確保）

3
8

高度なシステム機能への対応
システムの利用開始までの時間の短さ

15

1
3
0
6

自社のIT人材の不足を外部サービスで補う

2
10

安定したシステム稼働

310

災害時等の業務継続が容易

46

自社システムより情報セキュリティが確保しやすい

2

取引先の要請

1
1

その他

1
1
導入理由(N=25)

無回答

43

0
0

最も強い理由(N=25)

③ 調達計画
アプリケーション、プラットフォームにおける、アウトソース・外部利用の比率が今回対象とした 8 業務の中で最も低く、自社保有の比率が最も高くなっている。
図表 35 システム利用形態・調達計画（N=45）
0%

20%

40%

アプリケーション

68.9

プラットフォーム

73.3

60%

80%
8.9

100%
22.2

8.9

17.8

15.6

17.8

① 自社保有② アウトソース・外部利用③ ①②の併用

66.7

ハードウェア、ネットワーク

データセンター

37.8

22.2

40.0

クラウドの導入理由も他の業務と同様、「システムコストの節減」、「安定したシステ
ム稼働」、「災害時等の業務継続が容易」の 3 点が多く指摘されており、最も強い理由は「システムコストの節減」である。
図表 36 クラウド導入の理由（調達計画）
ラウ 導

(調

)

0

5

10

20
16

システムコスト（開発・運用）の節減

117

将来の業務量増加への対応（スケーラビリティの確保）
高度なシステム機能への対応

15

2
8
0
2

システムの利用開始までの時間の短さ

1
7

自社のIT人材の不足を外部サービスで補う

3
13

安定したシステム稼働

413

災害時等の業務継続が容易

3
6

自社システムより情報セキュリティが確保しやすい

3
2

取引先の要請1
1
1

その他

導入理由(N=29)
無回答

0
0

44

最も強い理由(N=29)

④ 進捗管理
今回対象の 8 業務の中では併用の比率が高くなっている半面、自社保有の比率は低くなっている。
•
図表 37 システム利用形態・進捗管理（N=34）
0%

20%

40%

60%

80%
17.6

100%

アプリケーション

61.8

20.6

プラットフォーム

67.6

14.7

17.6

67.6

11.8

20.6

① 自社保有② アウトソース・外部利用③ ①②の併用

ハードウェア、ネットワーク

データセンター

38.2

26.5

35.3

クラウド導入の理由についても、他の業務の傾向と同様に、「システムコストの節減」、「安定したシステム稼働」、「災害時等の業務継続が容易」という理由が多く、最も強い理由は「システムコストの節減」であった。
図表 38 クラウド導入の理由（進捗管理）
(

)

0

5

10
12

システムコスト（開発・運用）の節減

85

将来の業務量増加への対応（スケーラビリティの確保）

1
3

高度なシステム機能への対応
システムの利用開始までの時間の短さ

15

1
1
0
4

自社のIT人材の不足を外部サービスで補う

1
11

安定したシステム稼働

59

災害時等の業務継続が容易

2
5

自社システムより情報セキュリティが確保しやすい

1

取引先の要請

1
1

その他

1
1
導入理由(N=21)

無回答

45

0
0

最も強い理由(N=21)

⑤ 調達管理
他の業務と同様、データセンターの外部利用は多いものの、アプリケーション、
プラットフォーム、ハードウェア・ネットワークについては自社保有となっている。
データセンターについては、対象 8 業務の中でアウトソース・外部利用が最も多かった。
図表 39 システム利用形態・調達管理（N=34）
0%

20%

40%

60%

80%

100%

アプリケーション

68.0

18.0

14.0

プラットフォーム

74.0

12.0 14.0

70.0

14.0

① 自社保有② アウトソース・外部利用③ ①②の併用

ハードウェア、ネットワーク

データセンター

42.0

16.0

42.0

16.0

クラウド導入の理由については、上位 3 位に「システムコストの節減」、「安定したシステム稼働」、「災害時の業務継続が容易である」、が来ることはは他の業務と変わらない。
図表 40 クラウド導入の理由（調達管理）
(

)

0

5

10

15
13

6

将来の業務量増加への対応（スケーラビリティの確保）

システムの利用開始までの時間の短さ

25
21

システムコスト（開発・運用）の節減

高度なシステム機能への対応

20

1
4
0
1
0
5

自社のIT人材の不足を外部サービスで補う

1
13

安定したシステム稼働

410

災害時等の業務継続が容易

58

自社システムより情報セキュリティが確保しやすい

2
3
3

取引先の要請1
1

その他

導入理由(N=30)
無回答

46

0
0

最も強い理由(N=30)

⑥ 生産管理
今回対象とした 8 業務の中ではすべての項目について自社保有の比率が最も高かった。生産管理については、企業や生産ラインごとに独自のノウハウがあるととらえられる傾向にあり、また生産現場で直接使われるものであることから、クラウドの利用が低いと考えられる。
図表 41 システム利用形態・生産管理（N=34）
0%

20%

40%

60%

100%

80%

アプリケーション

74.4

11.6 14.0

プラットフォーム

76.7

9.3 14.0

74.4

11.6 14.0① 自社保有② アウトソース・外部利用③ ①②の併用

ハードウェア、ネットワーク

データセンター

51.2

32.6

16.3

クラウド導入の理由では、「システムコストの節減」と「災害時等の業務継続」が最も多くなっており、他の業務に比べて災害時等の業務継続に対する期待が高い。
最も強い理由については、他の業務同様である。
図表 42 クラウド導入の理由（生産管理）
(
)
0

5

10

15

21

システムコスト（開発・運用）の節減

136

将来の業務量増加への対応（スケーラビリティの確保）
高度なシステム機能への対応
システムの利用開始までの時間の短さ

25

20

1
4
0
1
0
5

自社のIT人材の不足を外部サービスで補う

1
13

安定したシステム稼働

410

災害時等の業務継続が容易

58

自社システムより情報セキュリティが確保しやすい

2
3
3

取引先の要請1
1

その他

導入理由(N=30)
無回答

47

0
0

最も強い理由(N=30)

⑦ 販売管理
他の業務と同様、データセンターの外部利用は多いものの、アプリケーション、
プラットフォーム、ハードウェア・ネットワークについては自社保有が主となっている。
図表 43 システム利用形態・販売管理（N=59）
0%

20%

40%

60%

80%

100%

アプリケーション

67.8

15.3

16.9

プラットフォーム

69.5

16.9

13.6

① 自社保有② アウトソース・外部利用③ ①②の併用

データセンター

11.9

67.8

ハードウェア、ネットワーク

47.5

32.2

20.3

20.3

クラウド導入の理由は「安定したシステム稼働」が最も多く、他の業務とは異なっている。ただし、「システムコストの節減」、「災害時等の業務継続」についても多く指摘されており、上位 3 位は変わらない。最も強い理由は「システムコストの節減」であった。

48

図表 44 クラウド導入の理由（販売管理）
0

5

10

15

20
16

システムコスト（開発・運用）の節減

97

将来の業務量増加への対応（スケーラビリティの確保）

3
10

高度なシステム機能への対応

4
4

システムの利用開始までの時間の短さ

2
5

自社のIT人材の不足を外部サービスで補う

1
18

安定したシステム稼働

614

災害時等の業務継続が容易

57

自社システムより情報セキュリティが確保しやすい

0

取引先の要請

1
1

その他

1
1
導入理由(N=32)
0
0

無回答

最も強い理由(N=32)⑧ 財務会計他の業務と同様、データセンターの外部利用は多いものの、アプリケーション、プ
ラットフォーム、ハードウェア・ネットワークについては自社保有が多い。アプリケーシ
ョンの自社保有比率も 8 業務の中では高い方である。財務会計はパッケージソフトなども豊富でクラウドの利用が進んでいるのではないかと想定していたが、逆に自社保有が多いとの結果となった。
図表 45 システム利用形態・財務会計（N=47）
0%

20%

40%

アプリケーション

68.1

プラットフォーム

72.3

60%

80%
14.9

14.9

100%
17.0

12.8

① 自社保有② アウトソース・外部利用③ ①②の併用

68.1

ハードウェア、ネットワーク

データセンター

44.7

12.8

34.0

19.1

21.3

クラウド導入の理由についても、他の業務と同様に「システムコストの節減」、「安定したシステム稼働」、「災害時の業務継続が容易」というものが多かった。
49

図表 46 クラウド導入の理由（財務会計）
0

5

10
10

4

将来の業務量増加への対応（スケーラビリティの確保）

2
5

高度なシステム機能への対応

自社のIT人材の不足を外部サービスで補う

20
15

システムコスト（開発・運用）の節減

システムの利用開始までの時間の短さ

15

1
3
0
4
0
12

安定したシステム稼働

69

災害時等の業務継続が容易

3
6

自社システムより情報セキュリティが確保しやすい

2

取引先の要請

1
1

その他

1
1
導入理由(N=26)

無回答

0
0

最も強い理由(N=26)（5） クラウドを利用できない・利用したくない業務① クラウドを利用できない業務
63%の回答者が「クラウドを利用できない・クラウドを利用したくない業務はない」と回答しており、クラウドを BtoB の情報インフラとして利用することの抵抗感は基本的には少ない。利用できない・したくない業務として指摘が多かったのは以下のものである。
• 財務会計• 生産計画• 販売管理50

図表 47 クラウドを利用できない・利用したくない業務② クラウドを利用できない・したくない理由
いずれの業務でも「情報セキュリティに不安があるから」が過半を占めており、特に財務会計では使いたくないとする回答者のうち 94%がその理由として挙げている。「利用できない・したくない」とする回答が多かった業務を見ると、その理由には
以下のような特徴がある。
財務会計• 圧倒的に「情報セキュリティへの不安」が挙げられている• 次いで、「サービスの安定性」、及び「現行システムで十分だから」
 生産計画• 情報セキュリティに続く理由が「現行システムからの移行が困難」である。生産
計画策定には独自のノウハウがあるといわれているため、移行が難しいという意見があるものと考えられる。
 販売管理• セキュリティ以外の理由は「サービスの安定性」、「現行システムで十分」、「移行の困難さ」が横並びとなっている。

51

図表 48 クラウドを利用できない・利用したくない理由52

（6） クラウドサービスが停止した場合に業務が受ける影響
続いて、クラウドサービスが停止した場合に、業務が受ける影響について、停止
期間 1 日および 3 日程度の 2 つのケースに分けて質問した。それぞれ回答は以下のような傾向が見られた。
① 停止期間 1 日程度の影響「継続困難になる」とするものが多い(40%前後)のは、生産計画及び生産管理である。生産に関わるところは、クラウドサービスの停止による影響が大きい。
「業務の一部に継続できないものが生じる」業務は販売計画と調達管理である。
「すべての業務は継続できるが業務処理の能力が低下する」が多い業務は、進捗管理と販売管理、また調達計画である。
「すべての業務は継続できるが代替手段確保に経済的な負担が生じる」という指摘が多かったのは調達管理、生産管理、販売計画の 3 つである。
一方、「大きな支障なくすべての業務が継続できる」が多かったのは財務会計である。
このことから、クラウドが停止した場合に最も影響を受けるのは生産そのものであって、次いで影響が大きいものは販売計画、調達管理となる。
その一方で内部処理が中心の財務会計は影響を受けにくいとの認識である。
② 停止期間 3 日程度の影響
おおむねどの業務でも停止期間 1 日程度の場合の回答と比べて深刻度が増している。全体の傾向は 1 日程度の場合とほぼ同様ではあるが、進捗管理業務や財務会計業務では「業務の一部に継続できないものが生じる」が急増しており、半面「すべての業務は継続できるが業務処理の能力が低下する」という回答が減少
している。

53

図表 49 クラウドサービスが停止した場合の影響
0%
販売計画(N=29)

10%

20%

停止期間1日程度

33.3
26.7

生産管理(N=21)25.0

財務会計(N=26)

23.1

販売計画(N=29)

24.1

停止期間３日程度

34.5
42.9

23.3

30.0

進捗管理(N=21)

27.6
19.0

33.3

生産管理(N=21)

20.0

38.1
25.0
19.2

30.0

19.0
25.0

28.6
37.5

19.2

23.1

23.1

業務の一部に継続できないものが生じる
すべての業務は継続できるが業務処理の能力が低下する
すべての業務は継続できるが代替手段確保に経済的な負担が発生する

54

8.0
10.3

4.0
6.9

9.5

4.8

10.0

3.3

14.3
9.4

代替手段はなく業務の継続は困難となる

大きな支障なくすべての業務が継続できる

13.8

24.0

23.8

3.1

19.2
10.3

24.1

0.0

14.3

15.4

20.0

4.8
3.3

12.5

24.1

4.0
6.9

16.7

37.5

38.1

調達管理(N=30)

10.3

38.5

27.6

8.0

28.6

27.6

100%

13.8

9.5

19.0

3.8

90%

28.0

9.5

40.0

調達計画(N=29)

80%
13.8

20.7

21.9

生産計画(N=25)

70%

27.6

38.1

販売管理(N=32)

60%

20.0

27.6

進捗管理(N=21)

財務会計(N=26)

50%

40.0

調達計画(N=29)

販売管理(N=32)

40%

24.1

20.7

生産計画(N=25)

調達管理(N=30)

30%

15.4

0.0
3.1

（7） クラウドサービス停止に備えた対策① 対策の内容
対策で多かったものは「自社システムの温存」、「システムを利用しない業務手順の温存」、「SLA による停止回避を事業者に義務づけ」が多かった。一方、未対応の回答者も 18.4%存在する。
図表 50 クラウドサービス停止に備えた対策② 未対応の理由
未対応の理由の半数近くはコストが限られていることを挙げており、また、サービス事業者に任せきりにしているからという回答も多い。
図表 51 クラウドサービス停止に備えた対策を取っていない理由③ 対策に対する懸念「SLA」「同じ事業者の別サービスの確保」「別の事業者による代替サービス」で55

は、対策にかかる費用が高額、対策が実際に有効に機能するかがわからないというものが多い。また、「自社システムの温存」「システムを利用しない業務手順の温存」では対策にかけられる人がいない・限られているという課題が多い。
図表 52 クラウド停止対応策に対する懸念

56

1.3.3. クラウドの浸透実態と課題
以上のアンケート結果より、企業の生産販売活動や企業間情報連携等において、クラウドは次のように利用されていることが明らかとなった。
クラウドの利用は業務別の傾向には大きな差は見られず、どの業務においても、
社外のデータセンターを利用しているものが半数弱と比較的多いものの、それより上位のハードウェア、プラットフォーム、アプリケーションは 60～70%程度が自社保有となっている。すなわち、外部のデータセンターにハウジングを依頼している
ものの、それより上位のレイヤーにおけるクラウド利用は 20～30%程度に留まっている。
また、クラウドを利用する動機は構築・運用コストの削減、スケーラビリティの確保、安定運用の実現に加え、災害時対応が多く見られたが、最も強い動機は構築・運用コストの削減であった。ユーザ企業から見て、クラウドは「安く情報システムを利用できるもの」という認識があることがうかがえる。
一方、クラウド化できない業務は 63%が「ない」と答えている一方で、クラウド化ができない業務で比較的多かったものは財務会計、生産計画の 2 業務であった。
クラウド化できないとする理由はほとんどがセキュリティへの懸念であり、クラウドの情報セキュリティに対するユーザの疑念が依然として根強いことがうかがえる。
一方、何らかの形でクラウドを利用しているユーザにおけるクラウドの停止時の業務への影響については、クラウドへの依存度によって「業務継続不可」「すべて継続できるが処理能力が低下」の二つに分かれた。停止期間が長いほど深刻度は上がる傾向にはあるが大きな差異は見られなかった。
最後に停止リスクへの対応については、クラウド以外の自社システムや手運用を温存しているという回答が多かった。また、SLA によってクラウド事業者に可用性を担保させている例が多かった。その後のリスク対応への回答結果とも合わせると、クラウド事業者側に一任している傾向もうかがえる。

57

1.4. 重要インフラ等の情報インフラとしてのクラウド
1.4.1. 調査の概要
内閣官房情報セキュリティセンター（NISC）によって重要インフラに指定されている、情報通信や金融等の 10 分野においてクラウドの導入事例を調査し、クラウドの普及状況とその特徴について把握した。

図表 53 調査対象事例
NISC の分類

クラウドの利用例

概要

情報通信

－

－

金融

• BeSTA（NTT データ）

鉄道－• 地方銀行の勘定系共同利用型センター。
7 行参加、1 行が稼働中。
• これ以外にも NTT データが運営する共同利用型センターがある• 全国の信用金庫 271 金庫のうち 90％が利用。
• LCC(Low Cost Carrier： 低 コスト航 空会社）向けの BPO、IT アウトソースサービス。
業務全般を ASP として提供
－

電力

－

－

ガス

－

－

政府・
行政サービス• 共同アウトソーシング（山形県・置賜広域行政事務組
合）• 奈良県市町村基幹システムクラウ
ド化（奈良県）• CIMA Chart SaaS
（テクノプロジェクト）• ポケットカルテ（NPO 法人日本・サスティナブル・
コミュニティ・センター）• からだカルテ（株式会社タニタ）• 水神システム（小松電機産業）• ウォータービジネスクラウド（メタウォーター）－• 3 市 5 町が参加する行政基幹業務の共同利用型システム。
• 12 業務でサービスを利用• 市町村の基幹業務をクラウド化（共同または単独）• 電子カルテを SaaS として提供

航空

医療

水道

物流

• しんきん共同システム（NTT データ）• Navitire（アクセンチュア）

58• PHR（Personal Healthcare Record）サービス• 体組成計等のデータを元に健康管理を行う PHR サービス（有料会員 20 万名）• 上下水道施設管理システムの ASP/SaaS。
• 上下水道施設管理システムの ASP/SaaS。
－

1.4.2. 対象事例
（1） 金融「BeSTA」
NTT データが運用する地方銀行・第二地方銀行向けの基幹系システムの共同利用サービスである。下図に示すように、提供中のサービスは「地銀共同センター」「3 行共同利用」「STELLA CUBE」の 3 つに分かれる。また、「BeSTAclud」サー
ビスを近日提供予定である。これらのサービスを利用している銀行は 2012 年 2 月
現在で 25 行、利用開始予定が 11 行である。NTT データによると、地方銀行・第二地銀の基幹系システムの約 30%のシェアを占めているとのことである。
この背景として、地方銀行においては、業務効率化の必要性や経営統合などに伴って、情報システムについても共同利用化を進めていることがある。クラウド型サービスの活用によって、システム投資やコストを少しでも抑えられることが期待されている。

図表 54 BeSTA

出所）NTT データ IR Information Appendix（2012 年 2～3 月）
http://www.nttdata.com/jp/ja/corporate/ir/library/tool/presentation/pdf/2012/ap1202j_all.pdf（2012 年 6 月現在）

59

（2） 金融「しんきん共同システム」
前項と同様に、NTT データが運用する信用金庫向けの勘定系、情報系の基幹業務システムの共同利用サービスである。全国の信用金庫 271 金庫のうち、243
金庫が加盟し、シェアは 90%に達する。
NTT データは 7 センターを東西 2 センターに集約すると同時に次世代システムを稼働させており、コミュニティクラウドサービスを用いた新サービスも運用を開始している。ユーザ側でもシステム運営組織に加え、事務センター機能の統合を図ろうとしており、信用金庫の BPO サービスに発展している。

図表 55 しんきんシステムの概要

出所）NTT データ IR Information Appendix（2012 年 2～3 月）
http://www.nttdata.com/jp/ja/corporate/ir/library/tool/presentation/pdf/2012/ap1202j_all.pdf（2012 年 6 月現在）

60

（3） 航空「Navitiare」
アクセンチュアの子会社が提供する航空業務の BPO およびクラウドサービスである。主な機能を下表に記すが、チケット発券、予約管理、顧客ステータス管理な
どの営業関係の機能に加え、遅延・欠航等の異常運航時における機材・乗員運用の最適化のような基幹業務の機能も有している。

図表 56 Navitiare の主な機能
機能

予約、インターネット
および直接販売説明 Web 直接販売
 業界標準販売チャネル・バイパス
 大手販売業者への直接アクセス・サービス
 ダイナミック一括サービス・パッケージ

売上管理と価格最適化

 RMS 26（複雑で付帯条件の多い料金体系を維持している航空会社向け）
 SkyPrice™（自由な料金体系をとっている航空会社向け）

航空業務と業務リカ
バリー

 異常運航時の予想コストおよび航空機、乗員、乗客への影響など、様々なリカバリーの可能性を数分以内で提示
 日々の乗員、航空機の稼働を最適化
 乗務時間等の管理により法規制の遵守

バックオフィス

 Revenue Protection はチケット販売の合法性を幅広く監査し、関税法を遵守
 売上会計：按分や乗継運賃の決済、仕訳記入など
 チケットレスな予約環境下での財務管理、財務・売上報告を行う
ための情報収集
出所）Accenture 日本法人 Web サイト

http://www.accenture.com/jp-ja/outsourcing/bpo/airline/Pages/navitaire-index.aspx（2012 年 6 月
現在）から NRI 作成

全世界 85 社以上の航空会社が導入しており、エアアジア等の LCC（Low Cost
Career：低コスト航空会社）では約 3 分の 2 のシェアを有する。また、LCC だけではなく、QANTAS オーストラリア航空、エアカナダなどの在来型の大手航空会社にも採用されている。

26

Revenue Management System61

（4） 行政「共同アウトソーシング」（山形県・置賜広域行政事務組合）
山形県南部置賜地域の 3 市 5 町の事務組合が運用する基幹業務システムである。基幹業務として提供されているのは下記の 12 種類であるが、参加団体によってシステム更改時期や個別ニーズに合わせて導入機能は異なっている。
①住民情報
④福祉
⑨財務会計

②税
⑥介護保険
⑩人事給与

③国保年金
④選挙投票
⑦医療費助成⑧学齢簿⑪上下水道料金 ⑫後期高齢者医療

図表 57 共同アウトソーシングの概要

出所）地方自治情報センター「電子自治体ベストプラクティス」
https://www.lasdec.or.jp/its/bestpractice/22saiteki/a04.html（2012 年 6 月現在）

ネットワークは県が整備した基幹ネットワークを活用しており、専用ネットワーク
敷設は不要であったため、構築コストの圧縮に役立っている。仙台市内の民間データセンターに共同サーバを設置しており、VLAN を用いてセキュリティを確保している。
図表 58 利用ネットワークの概要

出所）総務省 自治体クラウド推進本部 有識者懇談会（第 4 回）（2011 年 1 月 20 日）資料
http://www.soumu.go.jp/main_content/000099229.pdf（2012 年 6 月現在）

62

前述したように参加自治体はシステム更改時期に合わせて段階的に導入することができ、コスト削減効果は年間 2 億円程度とみられている。
一方、法律の規定上共同化できない戸籍システムを独自に更新する自治体が出現したことも効果の一つである。すなわち、共同化によってシステムコストが最適化され、節減されたシステム開発費を必要なものへ回せるようになったことの表れと考えられる。
このようにクラウドのスケーラビリティや機能の柔軟性を活かして、システム投資の最適化が実現されている。
図表 59 参加自治体ごとの導入スケジュール

出所）地方自治情報センター「電子自治体ベストプラクティス」
https://www.lasdec.or.jp/its/bestpractice/22saiteki/a04.html（2012 年 6 月現在）

63

（5） 行政「奈良県市町村基幹システムクラウド化」
奈良県内の市町村においては、任意団体としての「奈良県基幹システム共同化検討会」が共同クラウド化を推進している。地域の事情により一部事務組合ではなく、任意団体として身軽な形態で取り組んでおり、2011 年以降、7 団体が順次 22
業務をクラウド化しているところである。
クラウドを利用するうえでの課題として、停電や通信遮断時において業務が継続できないことがあるが、本システムにおいてはクラウドにデータを預けるだけではなく、各自治体の庁舎内にバックアップサーバを設置している。前日のバックアッ
プデータを取得し、ネットワーク切断時の縮退運用を可能としていることが特徴である。
図表 60 奈良県市町村クラウド化・共同化事業の実施状況

出所）ジャパン・クラウド・シンポジウム（2012 年 3 月 8 日開催）奈良県情報システム課 野田氏
講演資料 http://www.japan-cloud.org/consortium/sympo2012/index.html（2012 年 6 月現在）

（6） 医療「CIMA Chart SaaS」
島根県のシステムベンダー㈱テクノプロジェクトが提供する電子カルテのASP/SaaS である。2012 年 2 月現在、電子カルテの ASP/SaaS に取り組んでいるベンダーは 2 社であり、その 1 社であるテクノプロジェクトのサービスにおいては、
電子カルテ（院内、在宅診療用）、検査機器連動機能を提供している。ユーザである医療機関側は、インターネットの VPN でサーバにアクセスし、電子カルテの情報を取得する。
64

図表 61

SaaS 型電子カルテサービスの例（CIMA Chart SaaS）

出所）㈱テクノプロジェクト Web ページ
http://product.tpj.co.jp/cima_chart/concept11.html（2012 年 6 月現在）

電子カルテを ASP/SaaS で提供する上では信頼性の確保が重要と同社では認識しており、電子カルテを運用するデータセンターやデータセンターからインター
ネットアクセスポイントまでのバックボーン回線には二重化などの対策を施している。
しかしエンドユーザ側には二重化を推奨してはいるものの、コストの関係で二重化が行われるケースは少なく、この部分におけるネットワーク障害にリスクを感じている。
また、アプリケーションの構造に工夫を加え、データの一部をユーザ側にバックアップすることで、縮退運用を行うことを可能としている。さらに在宅医療などでモバイル環境での利用が進んでいるため、通信回線の速度に懸念を持っているという。しかしながら、同社では電子カルテで ASP 化不可能な業務はないと考えている。

65

（7） 医療「ポケットカルテ」
京都市及び京都府南部の市町において、17 病院、14 クリニックが参加する
PHR(Personal Health Record)ネットワークである。運営は特定非営利活動法
人（NPO 法人）日本サスティナブル・コミュニティ・センターである。特定健診の結果、投薬記録、医療費などの情報をクラウド上で管理するとともに、患者と医療機
関、医療機関同士で情報を共有することにより効果的・効率的な地域医療サービスを提供することを目指している。利用している患者数は 2011 年 2 月時点で約 2万人である。
•

主な提供機能は以下の通りである。

•

特定健診結果の管理（作成→登録→閲覧）•

紹介状（診療情報提供書）の管理（作成→登録→閲覧）•

入退院サマリーの管理（作成→登録→閲覧）•

電子版お薬手帳•

ヘルスケア家計簿•

地域共通診察券を利用した医療情報連携

図表 62 ポケットカルテを中心にした医療情報連携の概要

出所）ジャパン・クラウド・シンポジウム（2012 年 3 月 8 日開催）北岡氏講演資料
http://www.kantei.go.jp/jp/singi/it2/iryoujyouhou/dai8/siryou4.pdf（2012 年 6 月現在）

PHR をクラウドで提供する場合には、厚生労働省「医療情報の安全管理に関するガイドライン」をはじめ、ＳａａＳ事業者が医療情報を取り扱う際のガイドライン等に準拠する必要があり、本サービスにおいても同ガイドラインに準拠している。また、66個人情報保護については、事業主体は府及び NPO 法人とし、公的な事業として位置づけたほか、データベースを管理するサーバを国立病院機構京都医療セン
ターに設置しており、医療関連情報が民間サイドにおかれないような工夫を行っている。また、地域中核病院であれば災害時等にライフラインが確保されるため、サーバを京都医療センターに設置することは緊急時におけるサービスの継続にも役立っている。
さらに、ネットワーク上の情報セキュリティに関しては、患者サイドで情報閲覧は携帯電話等のネットワークやインターネット VPN を用いており、オープンなネットワークで情報をやりとりしないような工夫を施している。

（8） 医療「からだカルテ」㈱タニタが提供する PHR サービスである。同社が製造販売する体組成計や歩数計などの計測結果をクラウド上で管理し、PC 等から可視化するサービスである。
また、糖尿病管理などでの専門家の指導などのサービスメニューもある。加入者は総数で 20 万人である。
体組成計、歩数計、血圧計での計測データを専用の通信機器、または対応携
帯電話でクラウドに送信し、データベースに格納する。
格納したデータを閲覧するいくつかのサービスメニューが用意されており、ハードウェアの利用料とセットで、24 ヶ月契約で月 580 円から 1,800 円までのプランが存在する。通常はこれらのメニューを通じて自己管理のために情報を用いる。専門メニューとして、糖尿病の管理のために専門家の指導付きのコースが用意されており、4 ヶ月 8,400 円の料金を必要とする。
データのアップロードはリレーキーまたはレシーバーと呼ばれる専用機器を用いており、経路上インターネットを利用するがセキュリティ対策は取られているという。閲覧は大手ポータルサイトなどの複数のサービスが対応しており、一定程度の汎用化が図られている。

67

図表 63 からだカルテを中心にした医療情報連携の概要

出所）株式会社タニタ「からだカルテ」サイト
http://www.karadakarute.jp/info/connect/index.html（2012 年 6 月現在）

（9） 水道「水神システム」
島根県の小松電機産業㈱が提供する、上下水道施設の遠隔監視システムの
ASP/SaaS である。全国の 293 自治体 6,000 施設に導入（2012 年 4 月現在）されており、比較的広く普及している。
浄水場、配水場、下水処理施設などの上下水道施設に設置された監視装置が計測したデータを遠隔地で監視するシステムである。通常は専用通信網の整備が必要なところ、インターネットや NTT ドコモの FOMA 網でも利用可能なことから運用コストが低く、全国に広がっている。
集中管理をすることで、一般には施設管理の人員の集約・削減が図れるが、異常を検知した場合に詳細がわからないまま出動するケースがあり、結果的に無駄足になることも多い。しかしこのシステムを用いることにより、緊急時の対応と判断が迅速に行え、効果的な対応と、無駄な対応の削減が図れている。
データの送受信にインターネットを利用することでセキュリティが懸念されるが、制御系ではなく監視系のデータが主であることや、上下水道施設の設備操作は職員がオンサイトで行うことが多いことから、不正アクセスなどの被害は少ないと考えられる。よって、コスト面の優位性を維持するために通常のインターネットを利用
している。

68

図表 64 水神システムの構成

出所）小松電機産業㈱ Web ページ
http://www.komatsuelec.co.jp/komatsuelec/Products/suishin/suishinmainset.html（2012 年 6 月現在）

（10） 水道「ウォータービジネスクラウド」
水環境のエンジニアリング企業、メタウォーター㈱が 2011 年 4 月より提供する
上下水道事業者向けのクラウドサービスである。上下水道事業の民間委託の進展
や設備老朽化、事業者の技術者の高齢化や退職に伴う技術力の低下に対応することで「持続可能な上下水道事業」を実現することを目的としている。提供されるサービスは以下の通りである。
• 広域監視サービス：広域にわたる上下水道施設の稼動状況や、水位・水質・圧力等の計測値モニタリング• アセットマネジメントサービス：上下水道の事業者が保有している施設設備の仕様、運転・稼動情報、故障情報、保守情報などの各種情報をデータセンタ
ーで一元管理し、資産管理の最適化を図る• 遠隔支援サービス：専門の技術者がテレビ会議を用いて遠隔地から現場作
業員の判断や業務を支援する
2012 年 3 月現在、16 自治体で採用されている。

69

図表 65 ウォータービジネスクラウドのサービスイメージ

出所）メタウォーター㈱Web サイト
https://www.water-biz-c.com/about/service.html（2012 年 6 月現在）

70

1.4.3. クラウドの浸透実態と課題
内閣官房情報セキュリティセンター（NISC）に定義された 10 分野の重要インフラにおいて、基幹業務に関わるクラウドまたはシステムの共同利用が分野によっては進んでいることが明らかになった。以下のような分野において顕著に見られる。
• 金融：勘定系の共同利用センターサービスを信用金庫の 90%以上、地方銀行の 30%以上が利用• 航空：航空会社の運航管理を含む基幹業務システムのクラウドサービスを
世界 85 社以上が導入• 医療：地域医療機関間の PHR ネットワークに 2 万人、民間企業が運営する
PHR の有料サービスに 20 万人が加入• 水道：遠隔監視の SaaS を 293 自治体の 6,000 施設が利用
この他にも、「3 東日本大震災におけるデータセンターの緊急対応の実態と課題（実態調査その３）」 で行ったクラウド事業者インタビューの結果において、大手銀行のセキュリティ・キー・サービス、大手金融業の確定拠出型年金（いわゆる401k）の Web システム、大手食品メーカーの物流系基幹システム、県庁が中核の病院と連携して構築した救急医療情報システムなど、重要インフラに関連する多くのシステムがクラウドコンピューティングで運用されていることが明らかとなった。
以上のことから、重要インフラの基幹業務を支える情報システムのクラウド利用
や共同利用は特定の分野の特定の領域ではかなりの程度進展しているものがああることが明らかとなった。
一方、セキュリティの課題と対応については、以下のようなことが明らかとなった。
まず、データセンターについては、当該分野の法規制やガイドラインに従い、一定以上のセキュリティ対応は取られている。また、PHR システムなどでは非常時におけるライフラインと平常時の情報セキュリティを確保するために、一般のデータセンターではなく地域中核病院にサーバを設置している例も見られる。
ネットワークに関しては、金融や行政などのミッションクリティカルなものについて
はプライベートネットワークが利用されており、セキュリティの確保についての責任の所在がはっきりしている。しかし、インターネット VPN や携帯電話網などのオー
プンな通信回線を用いているサービスも多い。たとえば医療分野における EHR（Electronic Health Record）、PHR など重要性の高い情報を扱うシステムであっても、コスト削減や利用環境の確保のためにオープンな通信回線を利用している例があり、ネットワークの切断によるサービス中断のリスクは認識されている。このことへの対応は大別して以下のような考え方があり、サービスごとに異なる対応を取っている。

71

第一に、ローカルにバックアップを保有し、縮退運用が可能になっているサービスがある。たとえば、電子カルテの CIMA Chart SaaS や奈良県における自治体
システムなどが該当する。
第二に、サービスが中断したり、情報セキュリティが破られたりしても、業務に大きな影響をきたしにくい情報収集系の業務のみをオープンな通信回線で行っているサービスがある。水道分野における水神システムがこれに当たる。
第三に、非常時におけるライフライン途絶によるサービスの中断に対して、災害時における業務実態を検討した上で、センターサーバーに情報を集中させ、あえて縮退運用を前提としていないサービスもある。これは、PHR サービスのポケット
カルテなどがそれに該当している。
これらの考え方は、各サービス事業者において、クラウドサービスの特性である
サービス立ち上げの簡便さと構築コストの低廉さと情報セキュリティやサービス継続性のバランスを取った上で選択されているものと考えられる。

72

2.

東日本大震災におけるクラウドの利活用の実態と課題（実態調査その２）

2.1. 調査の概要
東日本大震災に際して、被災者・被災企業やその救援・支援にあたる行政やボランティ
ア組織に対して、安否確認、情報共有、行政情報発信や被災者支援の情報基盤の用途に、多岐にわたる無償のクラウドサービスが提供された。このことにより、クラウドが緊急時に社会を支える一翼を迅速、広域、かつ効率的に担えるインフラであることが示された。
本節では、東日本大震災に際して活用されたクラウドサービスの具体事例をとりあげて、どの程度役に立ったのかについて定性的に評価するため、支援の提供者、利用者、利用者の IT をサポートする立場の者等へヒアリングを行って検証した。

2.2. 調査の方法
2.2.1. クラウドサービスの事例分析（独）情報処理推進機構による「東日本大震災に際して提供されたクラウドサービスの事例集」（2011 年 6 月 20 日）に掲載されている事例 27の中から、典型的な事例を 21 件抽出
し、文献調査や聞き取り調査を通じて、サービスの概要、サービスの利用実態、クラウドの有効性を整理した。
抽出に当たっては、同事例集の中で用いられている次の 4 つの用途区分に基づき、偏りのないように、配慮した。
① 情報共有・流通基盤② 被災者救援活動の情報インフラ③ 行政情報提供サイトの拡張④ 被災企業等の緊急情報発信・業務処理
2.2.2.

被災団体の対応実態の分析 28
被災した地方公共団体における情報システムの復旧・復興に向けた取り組みを整理し、利用者及び利用者の IT をサポートする立場の視点から、クラウド活用の実態を分析した。

2.3. 調査の結果
2.3.1.

クラウドサービスの事例分析
分析の対象として抽出したクラウドサービスの事例を図表 66 に示す。

27
28

http://www.ipa.go.jp/about/press/20110620.html
本項は、本調査着手前に、野村総合研究所が自主的に実施した調査結果に基づく。

73

図表 66 分析対象としたクラウドサービスの概要
用途区分

活用事例

クラウド事業者

岩手県の安否情報 Web サイト 日本 IBM
在宅勤務による事業継続

日本 IBM

被災地医療に生かされた在宅
富士通
医療クラウド

利用形態
利用目的
ホスティング

HOPS

在宅勤務

立山システム研究所

在宅医療

祐ホームクリニック①
情報共有・ 被災した企業の企業活動、安 NEC ビッグロー
ホスティング
流通基盤 否確認、情報発信等のための ブ
ホスティング
情報提供サイト（sinsai.info）のホスティング

Amazon

利用者

負荷分散
代替サイト

情報発信を必要とする組織・団体OSMJ 及び有志

携帯メールと位置情報の蓄積・ 日本マイクロソフ
安否情報検索・提供「J!ResQ」
ト

日本デジタルオフィス

救援情報共有システム「SAHANA」構築

日本 IBM

ホスティング

ひょうごんテック

輸血用血液製剤の安定供給
支援

日本 IBM

ホスティング

日本赤十字社

情報共有

宮城県緊急災害時被災動物救援本部

支援需給の
マッチング

つなプロ

②
被災動物救護支援サービス
富士通
被災者救援
活動の情報 被災者と NPO をマッチングす富士通
インフラ
るクラウドサービス
農山漁村被災者受入れ情報シ
富士通
ステム
震災復興支援システム

情報共有・マッ農林水産省
チング

日本マイクロソフ
情報収集・共有 ページワン
ト

クラウド環境にミラーサイトを構
サーバ
日本 IBM③
築し、アクセス集中に対応
ミラーリング
行政情報提供サイトの 「東日本大震災 子どもの学び 日 本 ユ ニ シ ス 支援需給の支援ポータルサイト」にクラウド （ ユ ニ ア デ ッ ク
拡張
マッチング
型情報基盤サービスを提供
ス）

浦安市
各地方公共団体、教育委員会、学校、企業、NPO 等

アクセス急増した震災情報シス
富士通
テムに IaaS 環境で迅速に対応

ホスティングESRI japan

被災地向け安否確認・Web 会
富士通
議の提供

Web 会議SaaS

自治体、企業、非営利団体等④
大学連携高度教育基盤システ ニフティ （CA 教材の
被災企業等
Technologies） 相互活用の緊急情報 ム
発信・業務
処理
取引先企業の被災状況や工日本ユニシス
情報収集・共有
場稼働状況の確認
サーバ、PC の重要データを保存し共有できる場所を提供

日立システムズ74

大学 e ラーニング協議会/各大学
震災や停電の影響で資材や部品調達が難航し、取引先の状況確認が必要な企業や団体

データ保管・共自治体、企業等
有

用途区分

活用事例
仮想デスクトップ提供

クラウド事業者

利用形態
利用目的

利用者

日立システムズ 情報保存・共有 自治体、企業等

仮想サーバのリソースを無償で ソフトバンクテレ
ホスティング
提供コム

助けあいジャパン

各事例における利用実態やその効果についての詳細を以下に示す。

① 情報共有・流通基盤活用事例： 岩手県の安否情報 Web サイト



クラウド事業者

日本 IBM(株)サービス名／サービス種類

IBM Smart Business Cloud

有償／無償

無償

利用者

(株)HOPS

利用形態・利用目的

ホスティング

利用内容

被災者情報共有の情報サイト構築

期間（開始時期）2011 年 3 月 15 日 から開始

サービスの概要
岩手県の安否情報 Web サイトを、IBM Smart Business Cloud 上に構築し、早期に県内被災者の安否情報を提供した。
• 岩手県の若者達で成り立つ NPO から Web サイト立ち上げの話が持ち上がり、Web サイト
制作会社である HOPS が構築した。
• 岩手県内限定の情報開示用にクラウドのインフラを探していた HOPS が、IBM の無償提供プログラムをニュースで知り、3/14 午前 0 時過ぎメールで申請。翌 9 時 15 分頃、双方担
当者が直接電話で会話。日本 IBM は案件の緊急性を考慮し、数分でクラウドのインスタンスを提供。
• 結果として、岩手県の被災者の安否情報は IBM Smart Business Cloud 上でどこよりも早く発信された。

75

サービスの利用実態(株)HOPS代表取締役社長によるコメント 29
今回の経験から、パブリッククラウドにはホスティングサービスにはない「手軽さ」があると感じました。今回日本 IBM を選んだ理由は「手軽さ」を意識したところにあります。「手軽さ」と「スピード」はクラウドの大きな役割であると感じます。



クラウドの有効性
日本IBM(株)によるコメント 30
岩手県の被災者の安否情報をどこよりも早く発信。迅速な安否情報を提供が多くの被災者の方々に安堵感を与えることができた。
• インターネットを経由して、リモートのデータセンター上にわずか数分で仮想サーバを立ち上げることができたこと、サービスを提供するデータセンターが海外であったため、地震の影響を全く受けることがなかったこと、によって迅速性、耐災性の面で、クラウドの有効性が発揮された。

活用事例： 在宅勤務による事業を継続



クラウド事業者

日本 IBM(株)サービス名／サービス種類

LotusLive

有償／無償

有償（震災以前に導入済みの企業の事例）

利用者(株)立山システム研究所

利用形態・利用目的

在宅勤務

利用内容

在宅勤務による事業継続

期間（開始時期）2011 年 1 月から導入

サービスの概要
LotusLive は、社内外の情報共有を円滑に進めるコミュニケーション基盤をクラウド型で提供するサービス。場所を問わず働ける環境を実現でき、東日本大震災後も社外の関係者を含めて早期に業務を復旧し事業を継続可能とした。
• 「メール/カレンダー＆スケジュール機能」、「コラボレーション・スペース機能」、「Web 会議

2930

http://www-06.ibm.com/ibm/jp/provision/no70/pdf/70_interview3.pdf （2012 年 3 月現在）
日本 IBM への照会結果による。

76

機能」の 3 種類のサービスから構成され、必要な機能を単体で利用することも、統合的に組み合わせて利用することも可能。
• また、社内にかぎらずインターネットに接続可能な環境があれば場所を問わず利用でき、取引先に対しても無償のゲスト・アカウントを発行できるため、不測の事態に備えて取引先も含めた事業継続性を確保する上でも有効。
図表 67 LotusLive におけるゲスト・アカウントの考え方

出所）http://www-06.ibm.com/software/jp/cloud/casestudies/tateyama.html（2012 年 7 月確認）

サービスの利用実態(株)立山システム研究所 東京営業所セクションマネージャーによるコメント 31•「自宅から 3G 回線で LotusLive にアクセスして、必要な資料を参照・更新したり、パー
トナーとコミュニケーションを取ることができたので、在宅勤務期間も普段、会社で仕事をしている時とさほど変わらずスムーズに業務を遂行することができました。」•「実は震災当日、ちょうど LotusLive のアクティビティー上でやり取りしていた取引先のご担当者が帰社も帰宅も困難になり、ある案件を完全にストップせざるを得ない状況でした。その際、最寄の公共施設に一時避難されたそうなのですが、そこからノート PC で
LotusLive にアクセスしてアクティビティーに参加して下さったので、ごく短期間で業務を復旧することができました。」



クラウドの有効性• 発災後も、通常のように、場所を問わずに柔軟に働ける環境が提供されており、耐災性の面においてクラウドの有効性が発揮された。

31

http://www-06.ibm.com/software/jp/cloud/casestudies/tateyama.html（2012 年 3 月現在）

77

活用事例： 被災地医療に生かされた在宅医療クラウドクラウド事業者

富士通(株)

サービス名／サービス種類

在宅医療クラウド

有償／無償

無償

利用者

祐ホームクリニック （医療法人社団 鉄祐会）

利用形態・利用目的

在宅医療

利用内容

東日本大震災で被災した高齢者の在宅医療をクラウドで提供

期間（開始時期）2011 年 9 月 3 日から分院開設

サービスの概要 32
祐ホームクリニック（東京都文京区）は、「被災地で十分な医療サービスを受けられない高齢者への対応や心のケアが、これまで以上に必要になる」と考え、2011 年 9 月 3 日、特に甚大な被害を受けた地域の一つである宮城県石巻市に分院「祐ホームクリニック石巻」を開所。医療のサービスと、それを核とした高齢者の生活を支えるコミュニティづくりに向け活動を始めた。
祐ホームクリニックの取り組みに賛同した富士通は、生活/健康情報などの管理をクラウド上で行うシステムを提供し、取り組みを ICT 分野から全面的に支援。在宅医療時の課題であった、
医師や看護師、介護士間での情報共有を ICT で行う支援から開始し、現在は生活/健康情報
や訪問スケジュールなどの管理をすべて行う「在宅医療クラウド」を構築している。

＜背景＞
東日本大震災では、多くの医療機関も甚大な被害を受けた。その後、診療を再開する医療機
関も徐々に現れてはいるが、まだ十分な医療サービスを提供できていないのが実情である。
復旧の目途が全く立たない医療機関に通院していた高齢者の方も多く、避難所や仮設住宅から遠く離れた都市部の医療機関に通院するのは、容易なことではない。



サービスの利用実態 33
医療機関の被災等により、被災地で十分な医療サービスを受けられない高齢者を支援する
在宅医療において、医師と看護師、介護士等での情報共有や、訪問診療の支援等をクラウドサービスによって提供し、非常に役に立った。

32
33

http://jp.fujitsu.com/about/csr/recovery/episode3/（2012 年 3 月現在）
富士通への照会結果による。

78

クラウドの有効性 34
迅速性（短期間で構築、サービス開始が可能）、拡張性（利用実態に合わせて能力を拡張することが可能）の面でクラウドの有効性が確認された。

活用事例： 被災した企業の企業活動、安否確認、情報発信等のためのホスティング

クラウド事業者

NEC ビッグローブ(株)サービス名／サービス種類

BIGLOBE クラウドホスティング

有償／無償

無償

利用者

被災者、復興支援のため情報発信を必要とする組織・団体

利用形態・利用目的

ホスティング利用内容

被災した企業の企業活動に必要なシステム利用のためのサービス基盤や、安否確認情報、交通情報、鉄道の運行状況など被災地に必要な情報の情報発信

期間（開始時期）2011 年 3 月～12 月

サービスの概要• 仮想サーバによってリソースをオンデマンドで利用できるクラウドサービス（IaaS）。
• サーバ仮想化技術には、VMware 社の「VMWare」を利用。
• 東日本大震災に際し、被災した企業における通常の企業活動に必要なシステム利用のためのサービス基盤として、また安否確認情報、交通情報、鉄道の運行状況など被災地に必要な情報を迅速に届けるための情報発信を行う組織・団体向けに、「BIGLOBEクラウド
ホスティング」の無償IDが提供された 35。



サービスの利用実態 36• 東北地方の大学の緊急用 Web サイト： 東北地方の大学において、大学 Web サイト用サーバの機能停止による緊急対応として「BIGLOBE クラウドホスティング」上に大学 Web サ
イトを立ち上げ、大学関係者の安否確認や、卒業式や、入学式の連絡用に活用。
• 都内の水道水に含まれている放射能調査： 都内の浄水場が公表している水道水に含まれている放射能の量をグラフ化して、浄水場ごとにまとめたサイトを公開。

34

富士通への照会結果による。
http://www.biglobe.co.jp/pressroom/2011/03/17-3（2012 年 6 月現在）
36 NEC ビッグローブへの照会結果による。
3579

図表 68 BIGLOBE クラウドホスティングの概要

出所）総務省「東日本大震災に関するクラウドサービス活用事例集」（2011 年 11 月 4 日）

クラウドの有効性
短期間で、クラウドホスティングの無償 ID を発行してサービスを提供しており、迅速性の面でクラウドの有効性が発揮された。

活用事例： 情報提供サイトのホスティング

クラウド事業者

Amazon Data Services Japan(株)サービス名／サービス種類

Amazon Web Service

有償／無償

無償

利用者

一般社団法人オープンストリートマップ・ファウンデーショ
ン・ジャパン(OSMFJ)および有志

利用形態・利用目的

負荷分散、代替サイト

利用内容

情報提供サイトのホスティング
情報提供サイトの開発環境の提供

期間（開始時期）2011 年 3 月～6 月

80



サービスの概要
発災後、安否確認や救護や物資の要請などの情報を位置情報とひもづけて地図上で共有することのできる Web サイト：sinsai.info を、一般社団法人オープンストリートマップ・ファウンデー
ション・ジャパン(OSMFJ)及び有志が、立ちあげた。sinsai.info は多数の利用者がアクセスしたため、リソースが逼迫した。このため、Amazon Web Service による代替サーバでホスティングを行った。sinsai.info はサービスを安定的に提供でき、多くのユーザに利用された。
また、このプロジェクトはオープンソースの仲間のボランタリーな参加による共同作業を行うことで、短期間にサービスを立ち上げるとともに、長期間、データの吸い上げや翻訳作業といった地味な作業を継続的に実施している。この共同作業にも、AWS から提供された開発環境が役立てられ、遠隔からの参加や各自の空き時間を利用しての参加を可能にし、効率、協働、遠隔参加、持続といったクラウドならではの効果を享受できている。



サービスの利用実態
sinsai.info開発責任者のコメント 37•

震災翌日というタイミングで、こちらのリソースも非常に圧迫されている中、インフラを無償で提供いただき、またインフラ構築をサポートいただいた方々の存在はとても頼りになりました。

•

おそらくあのサポートがなければ sinsai.info はもっと小さなスケールのサービスになっていたと思われます。
図表 69 sinsai.info の画面（2011 年 5 月 24 日頃）

クラウドの有効性
知識さえあればすぐに利用可能なサーバが何台でも作成できた、利用状況に合わせ柔軟に使われたことから、迅速性、拡張性の面でクラウドの有効性が発揮された。
また、全てホスティングするよりは安かった、あの災害時でも使えていた、ホストが各地に分散できるという点から、経済性、耐災性の面でも評価できる。

37

sinsai.info 開発責任者への照会結果による。

http://www.sinsai.info/
81

活用事例： 携帯メールと位置情報の蓄積・検索・提供「J!ResQ」



クラウド事業者

日本マイクロソフト(株)サービス名／サービス種類

Microsoft Windows Azure Platform

有償／無償

無償

利用者

日本デジタルオフィス(株)利用形態・利用目的

安否情報

利用内容

被災時の緊急連絡に、ボイス対応被災時緊急連絡用アプ
リ「J!ResQ」を無償提供

期間（開始時期）

2011/3/18 からシステム提供

サービスの概要
携帯電話およびスマートフォン向けの被災時緊急連絡用アプリ「J!ResQ」を開発し、無償提供を行った。
被災者の方が、携帯電話やスマートフォンを利用して、自分の位置情報と音声を、あらかじめ登録したメールアドレスに自動送信できる。これにより、自分の無事をご家族やご友人に容易に知らせることができる。
J!ResQ で被災者が送信した位置情報と音声のデータは、日本マイクロソフトのクラウドプラッ
トフォームである Microsoft Windows Azure Platform に自動的に蓄積されるため、J!ResQのメール送信先に入っていない方でも、発信者のメールアドレスで検索することで知人の消息を確認できる。
図表 70 J!ResQ の概要

出所）http://www.do-cat.com/kinou_jresq/index.htm（2012 年 7 月 31 日）

82

クラウドを利用することで、各種スマートフォンや携帯電話に対応したアプリの迅速な開発・提供や、今後の多言語対応による世界各国での利用が可能となった。


サービスの利用実態
日本デジタルオフィス代表取締役社長のコメント 38•

震災から 3 日でアプリを完成させることができました。マイクロソフト様のご協力により、
震災翌日から無料のクラウド環境で開発できたことが非常にありがたく、従来のオンプ
レミスでは不可能であったと考えています。

•

今回のアプリではデータベースも利用しているのでその構築にも手間がかからず、早期構築を実現できました。

J!ResQ のダウンロード数は累計 78,000（iPhone、Android の合計）で、継続利用ユーザ数
は約 1,700 人。


クラウドの有効性
発災後数日でサービスを提供できたことから迅速性の面でクラウドの有効性が発揮された。
海外に立地するデータセンターであることによる耐災性、アクセスが集中してもリソースを拡張できる拡張性も評価できる。

② 被災者救援活動の情報インフラ

活用事例： 救援情報共有システム「SAHANA」構築

38

クラウド事業者

日本 IBM(株)サービス名／サービス種類

IBM Smart Business Cloud

有償／無償

無償

利用者

ひょうごんテック（ひょうご NPO 情報通信技術支援ネットワーク）

利用形態・利用目的

ホスティング

利用内容

災害時の救援情報共有パッケージ・ツール SAHANA を
IBM Cloud 上に構築

期間（開始時期）

2011/3/17 クラウド利用開始、5/31Sahana 公開

日本デジタルオフィスへの照会結果による。

83

サービスの概要
救援情報共有システム「SAHANA」を IBM Cloud 上に構築。東日本大震災において、岩手県と山形県に採用された。
図表 71 救援情報共有システム（SAHANA）の概要

出所）総務省「東日本大震災に関するクラウドサービス活用事例集」（2011 年 11 月 4 日）

＜SAHANA について＞• 2004 年に発生したスマトラ島沖地震の際に、スリランカのボランティアによって開発された
オープンソースソフトウェア。
• その後も各被災地における救援情報の共有で成果をあげていたが、関係者が独自にサーバを構築して活用する仕組みだった。


サービスの利用実態
ひょうごんテックによるコメント 39
今回の経験を通じて、危機的状況でスピードを求められるときに、すぐ立ちあげられ自由に設定できるクラウドは、危機管理・事業継続において最適の形態だと強く感じました。特にシステムが必要だがあまり投資できないという企業にとって、クラウドは相性がいいのではないでしょうか。

39

http://www-06.ibm.com/ibm/jp/provision/no70/pdf/70_interview3.pdf（2012 年 3 月現在）

84

SAHANAに関する報道記事 40•

岩手県では、5 月末から陸前高田市の全避難所を対象に、避難者人数、通所避難者の人数、災害弱者の方の人数、各避難所のライフライン復旧情報の把握といった、被災状況や被災者の情報を一元的に管理。さらに、それぞれの避難所から、NTT ドコモ
が設置したタブレット端末「GALAXY Tab」を利用して、必要物資の要望を把握できるようにした。

•

山形県では、SAHANA を活用することで、福島県からの避難者の所在情報を一元管理したという。山形県は避難者に対して、当初の一次避難所からホテルやアパートへの二次避難を推進しているが、避難者の転居のたびに、担当者が所在を把握する必要があった。これを SAHANA によって、避難者の所在情報を、避難場所別、出身地別などからも常に把握できるようになったという。



クラウドの有効性
日本IBM(株)によるコメント 41
危機的状況で、スピードを求められるときに、すぐに立ち上げることができ、自由に設定できるクラウドは危機管理・事業継続において最適だった。
• インターネット経由を経由して海外のデータセンターからサービスを利用可能だったこと、
本番運用環境のみではなく、開発やテスト用の環境も迅速に提供できたこと、インターネッ
ト上に開発環境を構築したため、離れた場所での共同開発が可能であったこと等から、様々な観点でクラウドの有効性が認められた。

活用事例： 輸血用血液製剤の安定供給支援

クラウド事業者

日本 IBM(株)サービス名／サービス種類

LotusLive

有償／無償

無償

利用者

日本赤十字社

利用形態・利用目的

ホスティング

利用内容

輸血用血液情報共有

期間（開始時期）

2011/3/16 から利用開始

40

大河原克行「東日本大震災で活躍した救援情報共有システム「SAHANA」」（2011 年 6 月 29 日）
http://www.asahi.com/digital_sp/cloud_exp/TKY201106280146.html
41 日本 IBM への照会結果による。

85

サービスの概要
全国で献血から供給までを支援する「血液事業統一システム」を運用し、血液製剤の医療機関への安定供給を継続。
• 日本赤十字社の「血液事業」にかかわる効率的な情報共有の仕組みを、日本 IBM の提供する LotusLive 環境にて、無償特別プログラムとして早期実現。
• 被災地また社内外の関係者とのコラボレーションを即座に開始することで、震災直後に大量発生した課題を効率的に解決し、関係者との情報共有・仮題の履歴管理などができるよ
うになり、血液製剤の医療機関への安定供給を継続。
図表 72 血液事業統一システムの概要

出所）総務省「東日本大震災に関するクラウドサービス活用事例集」（2011 年 11 月 4 日）

サービスの利用実態
日本赤十字社によるコメント 42•

日本赤十字社が行う血液事業では、全国を 1 つのシステムでつないで輸血受付から輸血用血液製剤の供給までを管理しています。東日本大震災では被災地におけるネットワーク切断や施設被災状況の把握、資材調達など、解決すべき課題が日を追うにつれて明らかになりました。

•

その中でも、社内外の関係者との情報共有は、当初メールでのやり取りをメインにしていましたが、数日後には整理しきれない状況になっていました。そのようなさなかに

42 日本赤十字社 血液事業本部システム管理課 支援係長によるコメント（2012 年 3 月現在）
http://www-06.ibm.com/ibm/jp/provision/no70/pdf/70_interview3.pdf

86LoutusLive のニュースを知り、申し込みをさせていただきました。
•

その後は、関係者との情報共有・課題の履歴管理などに活用し、被災地に対する効果的なバックアップを行うことが可能になりました。



クラウドの有効性
日本IBM(株)によるコメント 43
危機的状況で、スピードを求められるときに、すぐに立ち上げることができ、自由に設定できるクラウドは危機管理・事業継続において最適だった。
• コラボレーションに必要となる一連の機能が SaaS としてすぐに利用可能であったこと、それらをインターネット経由で Web ブラウザから利用できるため、利用者に特定の環境を準備する必要がなく、社外のスタッフにも使用することが可能であったことから迅速性、経済性の面でクラウドの有効性が確認された。また、耐災性、安全性の面からも有効であったと評価できる。

活用事例： 被災動物救護支援サービス

クラウド事業者

富士通(株)

サービス名／サービス種類

Fujitsu Global Cloud Platform FGCP/S5（オンデマンド仮想システムサービス）

有償／無償

無償

利用者

宮城県緊急災害時被災動物救援本部

利用形態・利用目的

情報共有

利用内容

東日本大震災で被災した保護動物の情報公開を支援する
取り組み

期間（開始時期）2011 年 5 月 2 日から開始

サービスの概要
宮城県緊急災害時被災動物救援本部が保有する保護動物のデータ（保護された場所、個体の特徴、写真など）を、富士通のクラウド基盤から提供する「被災動物救護支援サービス」に集約したうえで、日本マイクロソフトがポータルサイト MSN®上で公開している「MSN ペットサーチ」とシステム連携させた。

＜MSN ペットサーチ＞
43

日本 IBM への照会結果による。

87• 日本マイクロソフトが緊急災害時動物救援本部との連携により、2011 年 4 月 14 日より運営しているサービス。
• 東日本大震災の影響によって飼い主と離れ離れになった動物の情報を、各動物保護団
体より集約して公開することにより、元の飼い主との再会や、新しい飼い主探しを支援している。
• PC もしくはインターネットが閲覧可能な携帯電話などから無料で利用可能。
• 日本マイクロソフトのクラウドサービス「Windows Azure™」を基盤としている。
＜被災動物救護支援サービス＞• 富士通が宮城県獣医師会向けに、2011 年 5 月 2 日より提供しているサービス。
• 被災した動物の情報を独自のクラウド基盤に集約し、救援本部による公開を支援している。
• 富士通のクラウドサービス「FGCP/S5」を基盤としている。

システム連携に際しては、富士通のクラウドサービスを支えるコンポーネントである
セキュア情報共有基盤技術が用いられている。
図表 73 被災動物救援情報システムの概要

出所）総務省「東日本大震災に関するクラウドサービス活用事例集」（2011 年 11 月 4 日）

88

サービスの利用実態
緊急災害時動物救援本部 本部長によるコメント 44•

現在、動物保護団体などが保護した動物の情報は、各団体が独自に所有・公開されることが多く、元の飼い主にとっては、自分のペットが無事に保護されているかどうかを確認することが非常に困難でした。また保護団体側も、人員不足などの理由から、保護した動物の最新情報を公開したり、元の飼い主や新しい飼い主を探したりといった「保護した後」の取り組みに十分対応しきれていない現状がありました。
IT やクラウドを活用することにより、元の飼い主や、新しい飼い主探しが容易になること•

は、被災地の動物や、被災者の方々の一助となるばかりでなく、動物の殺処分件数の低減という観点からも非常に意義のあることだと考えます。


クラウドの有効性 45• 迅速性（短期間で構築、サービス開始が可能）、拡張性（利用実態に合わせて能力を拡張することが可能）の面でクラウドの有効性が確認された。

活用事例： 被災者と NPO をマッチングするクラウドサービス

クラウド事業者

富士通(株)

サービス名／サービス種類

SaaS 型 CRMate

有償／無償

無償

利用者

「被災者を NPO とつないで支える合同プロジェクト」（つなプロ）

利用形態・利用目的

支援需給のマッチング

利用内容

被災者のニーズと NPO をマッチングするクラウドサービス。

期間（開始時期）

3 月 28 日からシステム稼働

サービスの概要「被災者を NPO とつないで支える合同プロジェクト（つなプロ）」は、避難所の“実態・実際”を把握するアセスメントを実施し、判明したニーズや課題を、介護・医療・
障がい者・外国人・難病患者支援などの分野で高い専門性をもつ NPO 活動とマッチングすることで課題解決をめざすプロジェクト。

44
45

http://pr.fujitsu.com/jp/news/2011/07/25-2.html（2011 年 7 月 25 日
富士通への照会結果による。

89

富士通プレスリリース）アセスメントにより得た情報をデータベース化する仕組みとして SaaS 型アプリケー
ションサービス「CRMate」を提供。
＜つなプロ＞
東日本大震災において、複数の NPO と日本財団などが連携して「災害関連死」を防ぐことを目的に設立された。
• 今回の大震災は、被害が極めて甚大であり、避難生活の長期化が予想された。避難所では、妊産婦、軽度の要介護者、精神的要支援者、外国人、障がい者、アレルギー疾患や難病の患者等、様々な配慮、細かな支援を必要とする人々も避難している。
• 救援活動においては、こうした人たちに配慮した支援が必要であり、各分野の専門性を持
つ NPO の連携が重要になる。そこで、東北地域の NPO ネットワークの中核的存在である「せんだい・みやぎ NPO センター」と、全国の NPO が連携し、被災者を NPO とつないで支えようという目的で立ち上げられた。
• 被災地において、こうした特別な配慮を必要とする方々のニーズを把握し、専門的支援へとつなげる活動を実施。これまで地域社会において、困難を抱える人たちに様々な社会サービスを開発・提供し、阪神・淡路大震災でも活躍してきた NPO が、それぞれの専門性を活かした支援を行うことで、避難先での死亡や状況悪化の防止・回避を進めている。

図表 74 つなプロの概要（「つなプロクラウド」を使った被災者支援の仕組み）

出所）：http://jp.fujitsu.com/about/csr/feature/earthquake/casestudy/90

サービスの利用実態
富士通/クラウド戦略統括部担当課長によるコメント 46
3 月 28 日のシステム稼働から 4 月末までに、つなプロクラウドにはメンバーが足で集め•た 443 件の避難所情報と、966 件のニーズ情報が蓄積された。
•

挙がってくる情報はそれぞれのボランティアによって、質の濃淡がある。あらかじめ統一したフォーマットを用意したことで、そうした質のバラつきをなくすことができた。また、クラウド（SaaS）のシステムを使うことで、多数の人間が物理的な距離を超えて、同時に入力することができた。

•

現在は宮城県に限定した活動だが、活動領域が広がってデータ量が増えた場合も、容易にサーバ容量を増設できる。アクセスするユーザの権限管理も自由自在。どちらもクラウド技術の大きなメリット。

•「サーバの立ち上げなどから始めていたら、半年はかかっただろう。ネット接続さえできればどこからでも開発作業に加われるので、時には名古屋のメンバーに遠隔サポート
してもらった」



クラウドの有効性 47• 迅速性（短期間で構築、サービス開始が可能）、拡張性（利用実態に合わせて能力を拡張することが可能）の面でクラウドの有効性が確認された。

活用事例： 農山漁村被災者受入れ情報システム

クラウド事業者

富士通(株)

サービス名／サービス種類

SaaS 型 CRMate

有償／無償

無償

利用者

農林水産省

利用形態・利用目的

情報共有・マッチング

利用内容「農山漁村被災者受入れ情報システム」の運用により、全国各地の農山漁村に存在する空き家、廃校舎、農林水産業体験施設など受入れ可能な住まい情報、雇用などの受入れ情報を、自治体を通じ被災者に提供。

期間（開始時期）

2011/4/19 に運用開始

46

富士通/クラウド戦略統括部担当課長によるコメント：日本経済新聞電子版『被災地の「声」を拾うクラウド 奮闘するエンジニアたち』（2011 年 5 月 13 日）より引用
47 富士通への照会結果による。

91

サービスの概要
被災者受入れ側の地方公共団体や農林水産業関係団体等が提供する、住まい、雇用の情報、活用できる農地や耕作放棄地の情報等に、被災地域の地方公共団体がインターネ
ットを通じてアクセスできるシステム。
• 農山漁村における住まいおよび雇用などの受入れ情報を収集、管理する農林水産省に協力し、被災者の意向にあわせてスピーディな情報収集、管理を可能とする SaaS 型「CRMate（シーアールメイト）」を提供。
• 受入れ側の地方公共団体、農林水産業・食品産業関係団体等は、随時情報の入力・更新を行う。
図表 75 農山漁村被災者受け入れ情報システムの概要

出所）総務省「東日本大震災に関するクラウドサービス活用事例集」（2011 年 11 月 4 日）

サービスの利用実態
農林水産省プレスリリース 48
 受入れ側の地域では、地方公共団体、農林水産業・食品産業関係団体、NPO 法
人、民間団体等の協力の下、空き家等の住まいの情報、農林水産業関係の雇用の情報、活用できる農地や耕作放棄地の情報等の情報を、より速く、より確実に被災地域へ提供することが可能となります。
 被災地域の地方公共団体では、被災者の多様な意向を踏まえ、知りたい情報を迅速に把握することができ、効率的できめ細かなマッチングが可能となります。
 このシステムにより、被災者が被災地域の地方公共団体に受入れ側の地域等の意
向を相談した際、意向を踏まえた迅速な情報の提供が可能となります。

48

農林水産省プレスリリース「農山漁村における被災者受入れ支援の充実について」より引用 （平成 23 年 4 月
19 日） http://www.maff.go.jp/j/press/nousin/tiiki/110419.html

92富士通によるコメント 49
NPO 様等と連携し、被災者のニーズマッチングや健康調査等、様々な用途で利用された

クラウドの有効性 50• 迅速性（短期間で構築、サービス開始が可能）、拡張性（利用実態に合わせて能力を拡張することが可能）の面でクラウドの有効性が確認された。

活用事例： 震災復興支援システム



クラウド事業者

日本マイクロソフト(株)サービス名／サービス種類

Microsoft Dynamics CRM

有償／無償

無償

利用者

(有)ページワン

利用形態・利用目的

情報収集・共有

利用内容

避難者の情報管理、避難所で必要となる物資の管理期間（開始時期）2011 年 3 月

サービスの概要
避難所および避難者の情報管理、避難所で働くボランティアの管理、緊急支援物資の管理などの情報を体系的に整理し、避難所の運営をスムーズにできるソリューション「震災復興支援システム」を無償提供。企業で使われている CRM（顧客関係管理）のクラウ
ドサービスである「Microsoft Dynamics CRM Online」というソリューションを利用することで、被災地域の避難所運営に最適化して活用することができる。



サービスの利用実態 51
避難所の状況の移り変わりが激しかったため、避難所から情報の管理者への情報伝達が十分に行われず、システムへの情報登録があまり行われなかった。この結果、活発に利用されるに至らなかった。

49

富士通への照会結果による。
富士通への照会結果による。
51 (有)ページワン代表取締役への照会結果による。
50

93



クラウドの有効性
避難所で情報伝達に係る人手不足という運用上の問題のために、実際に十分に活用されることはなかったが、迅速にサービスが開始されたことはクラウドの有効性として評価できる。
図表 76 震災復興支援システムのサンプル画面：支援物資一覧

出所）マイクロソフト Web サイト http://www.microsoft.com/japan/presspass/detail.aspx?newsid=3978③ 行政情報提供サイトの拡張活用事例： クラウド環境にミラーサイトを構築し、アクセス集中に対応

クラウド事業者

日本 IBM(株)サービス名／サービス種類

IBM Smart Business Cloud

有償／無償

無償

利用者

浦安市

利用形態・利用目的

サーバミラーリング

94



利用内容

災害情報

期間（開始時期）

2011/3/18 からクラウド上で稼働

サービスの概要
災害対策 web サイトのミラーサイトをクラウド環境に構築することにより、アクセス集中に対応。災害情報の提供を行った。
• 震災に伴い液状化現象で甚大な被害を受けた浦安市では、迅速に災害対策 Web サイトを立ち上げ、日々の生活に直結するガス、水道、下水道、道路の復旧見込みなどの情報をタイムリーに提供していた。
• しかし日を追うごとにアクセスが増え、レスポンスの遅延、あるいは一部アクセス不能という事態が発生し、災害対策ページを継続的に運用するための対策の必要に迫られた。
• そこで、日本 IBM が無償提供していた IaaS のホスティングサービスの利用を相談した。
• 日本 IBM 側では事前にクラウド環境にミラーサイトの稼働環境を整備し、正式申し込みと同時にミラーサイトをオープンした。
図表 77 ミラーサイトの構築

出所）：http://www-06.ibm.com/ibm/jp/provision/no70/pdf/70_interview3.pdf



サービスの利用実態
浦安市 総務部 CIO補佐によるコメント 52「被災自治体へのボランタリーな提案を迅速に受けたことにより、混乱に至る前にミラーサイトを構築できました。このたびパブリッククラウド環境を活用したことで、対応システムの早期構築も実現できるなど意義を実感できました。今回の震災を通して、震災当初の市民への情報提供、罹災証明の発行など、災害への対応において情報システムが不可欠であることが再認識されました。事業継続という点から、災害体制

52

http://www-06.ibm.com/ibm/jp/provision/no70/pdf/70_interview3.pdf（2012 年 3 月現在）

95

をさらに高めて継続的な情報システム運用を実現したいと考えます。
」


クラウドの有効性
日本IBM(株)によるコメント 53
ミラーサイトの迅速な稼働により、市民の方々に対して刻々と変化する情報をタイムリーに発信し続けることが可能になった。クラウドの持つ利便性や有効性が証明された。
• インターネットを経由して、リモートのデータセンター上にわずか数分で仮想サーバを立ち上げることができたこと、サービスを提供するデータセンターが海外であったため、地震の影響を全く受けることがなかったこと等から、迅速性、耐災性の面でクラウドの有効性が確認された。

活用事例： 「東日本大震災 子どもの学び支援ポータルサイト」にクラウド型情報基盤サービスを提供

クラウド事業者

日本ユニシス(株)サービス名／サービス種類

U-Cloud™ IaaS、NeXtCommons

有償／無償

無償

利用者

各地方公共団体、教育委員会、学校、企業、NPO 等

利用形態・利用目的

支援需給のマッチング

利用内容

文科省 東日本大震災 子どもの学び支援ポータルサイト

期間（開始時期）2011 年 4 月開始

サービスの概要
日本ユニシス(株)とユニアデックス(株)は、被災地域の復興支援の一環として、文部科
学省の「東日本大震災 子どもの学び支援ポータルサイト」にクラウド型情報基盤サービスを提供。
• 「教職員を派遣してほしい」、「学用品が足りない」といった被災地域からの支援要請に対し、人的支援や物的支援が可能な申し出を相互に結びつけるマッチングサイト。
• 被災地域で現在どのような支援を必要としているのかを各地方公共団体や教育委員会などを通じて掲載。また、支援の検討をしている地方公共団体・教育委員会・学校・企業・
NPO などが、どのような支援を提供することができるのかについて登録。

53

日本 IBM への照会結果による。

96• ユニアデックスのクラウド型情報基盤サービス「NeXtCommons®（ネクストコモンズ）」、日本ユニシスのクラウドサービス「U-Cloud™ IaaS」を利用して、サイトの開設・立ち上げを無償で支援
図表 78 子どもの学び支援ポータルサイトの概要

出所）総務省「東日本大震災に関するクラウドサービス活用事例集」（2011 年 11 月 4 日）

サービスの利用実態
文部科学省による発表記事 54「多くの方に子どもの学び支援サイトにアクセスいただく中で、多数の支援が実現してまいりました。
」（参考）ポータルサイトの実績（平成 24 年 3 月 18 日現在）
 累計ページビュー：1,211,396 ページ
 累計訪問件数：342,709 件
 支援の提案件数：917 件
 支援の要請件数：402 件
 総マッチング件数：2,257 件



クラウドの有効性 55• 震災発生後(3 月 11 日)に被災地支援の内容を検討し、ポータルサイトを運用することを決めてから開始(4 月 1 日)までの短期間で、サイト構築およびサービス開始に至ったことから、迅速性の面で有効であった。
• また、ネクストコモンズというシステムを使用し、デザイン変更や、ツィッターやグーグルマッ
プなどとの連動など、多種多様な機能をもったモジュールがあらかじめ用意されていたの54文部科学省『東日本大震災における「子どもの学び支援」に関する Web サイトを通じた情報発信等について』（平成 24 年 3 月 19 日）http://www.mext.go.jp/b_menu/houdou/24/03/1318834.htm
55 文部科学省担当者への照会結果による。

97

で、新たな機能追加についてストレスを感じることなく実現できたため、拡張性の面からも評価できる。

④ 被災企業等の緊急情報発信・業務処理

活用事例： アクセス急増した震災情報システムに IaaS 環境で迅速に対応•

クラウド事業者

富士通(株)•

サービス名／サービス種
類

Fujitsu Global Cloud Platform FGCP/S5（オンデマンド仮想システムサービス）

•

有償／無償

無償

•

利用者

ESRI ジャパン(株)•利用形態利用目的

ホスティング•

利用内容

アクセス急増した震災情報システムに対応•

期間（開始時期）

2011/3/18 申し込み（2011/3/20 から運用）

 サービスの概要
急増するアプリケーションユーザからのアクセスに、クラウドサービスによる
FGCP/S5 で対応。複数のサービスにクラウドサービスを組み合わせ、予測できない負荷
急増のリスクを回避した。
＜導入の経緯＞
 ESRI ジャパンは、米国 ESRI 社の地理情報システム（GIS）製品の日本における総販売代理店。2011 年 3 月 11 日の東日本大震災直後、同社は EMT（東北地方太平洋沖地震緊急地図作成チーム）の一員として地図作成活動を支援し、また同社ホームページ上で震災関連の各種地図やソーシャルメディアマップを公開するなど、震災復興への積極的支援を続けている。
 とりわけソーシャルメディアマップの一般向け無償公開がネット上で大きな反響を呼んだ。震災後、このソーシャルメディアマップを公開したことがメールマガジンなどにより広く紹介され、それまで利用している Amazon に加えて、急増するアクセスに余裕を持たせる対応を迫られた。
 震災 1 週間後に富士通のクラウドサービス選定、「東日本大震災クラウド／保守サー
ビス特別ご支援プログラム（無償）」を利用。その 2 日後には複数のクラウド上に復興支援の無償 GIS アプリケーションを載せたシステムが動き始めた98

図表 79 ESRI Japan への提供システム

出所）http://jp.fujitsu.com/solutions/cloud/casestudies/esrij/?inside=top-news

 サービスの利用実態
ESRIジャパン システムソリューション推進第 1G部長によるコメント 56
・とくに富士通のクラウドにはデータのバックアップも担っていただくことになりました。一定のスペックを保証するなど性能重視の富士通クラウドは『今後、どれくらい負荷が高まるか見通せない』という状況において高く評価できました。また仮想サーバの管理画面が分かりやすく使いやすい点、データセンター
が地震・津波リスクを抱える国内だけでなく海外 5 拠点で展開している点も選定の大きな理由でした
・GIS のアプリケーションは、それを動作させるハードウェアのスペックを慎重に見積もる必要がありますので、それをクラウドの柔軟性でフォローする有効性については、頭では理解しているつもりでした。その上で今回、2 日間でクラウドサービスの新規展開を経験し、弊社スタッフ全員があらためてその威力を実感しました

http://jp.fujitsu.com/solutions/cloud/casestudies/esrij/?inside=top-news（2012 年 3 月確認）56

99

富士通によるコメント 57•

地理情報システム等、震災関連サービスを提供される企業様を中心に、ある程度、活用戴いた。

 クラウドの有効性 58
 迅速性（短期間で構築、サービス開始が可能）の面でクラウドの有効性が確認された活用事例： 被災地向け安否確認・Web 会議の提供•

クラウド事業者

富士通(株)•

サービス名／サービス種類

Web 会議 SaaS

•

有償／無償

無償

•

利用者

自治体、企業、非営利団体等•

利用形態利用目的

Web 会議•利用内容

企業等の災害対応のための情報インフラ•期間（開始時期）

2011/3/17～2011/7/31

 サービスの概要
被災した商工会議所、商工会連合会・商工会、団体中央会及びその会員企業向けに、
Web 会議を活用した支援アプリケーションをクラウド環境に搭載、提供。
＜システム概要＞
Web 会議サービス（SaaS 型、パッケージ）「JoinMeeting」
 いつでも、どこからでも、インターネットを経由して簡単に Web 会議を行なえる
SaaS 型サービス。
 パソコン、ヘッドセットなどの会話ツール、Web カメラだけで手軽に利用できる。
 サービスの利用実態
富士通によるコメント 59•

被災された商工会議所・商工会等で利用戴いた。

•

非常に役だった。

57

富士通への照会結果による。
富士通への照会結果による。
59 富士通への照会結果による。
58100

図表 80 Web 会議 SaaS の概要

出所）：http://fenics.fujitsu.com/networkservice/joinmeeting/
http://fenics.fujitsu.com/casestudies/2010/nidec-copal/?from=bottomMenu

 クラウドの有効性 60
 迅速性（短期間で構築、サービス開始が可能）の面でクラウドの有効性が確認された。

活用事例： 大学連携高度教育基盤システム



クラウド事業者

ニフティ(株)サービス名／サービス種類

ニフティクラウド

有償／無償

無償

利用者

大学 e ラーニング協議会/各大学

利用形態・利用目的

教材の相互活用

利用内容

クラウド上で各大学の講義コンテンツを共有。クラウド上のe-ラーニング環境も活用。

期間（開始時期）2011 年 4 月 22 日開始

サービスの概要
被災地支援の取り組みとして、e ラーニングによる大学向けの講義、教材および大学の単位認定の支援などを行う高度教育基盤の提供を行った。

60

富士通への照会結果による。
101

＜経緯＞
• 被災地の大学では、校舎等の損壊や計画停電・交通機関の制限等により、開講時期の遅れや授業回数の確保が困難になるなど、新年度以降の学生の学習に支障が出ることが懸念されている。
• この状況を踏まえ、大学 e ラーニング協議会、ニフティ、住商情報システム(株)（SCS：当時。
現 SCSK）は、被災学生に質の高い教育機会を提供するため、各団体、各社の持つ技術・ノウハウを集約し、全国の大学で相互に活用可能な e ラーニングによる高度教育基盤を構築。
＜システム＞• 大学 e ラーニング協議会が全体の取りまとめを行い、参加大学が保有する既存講義コン
テンツ、授業用の教材およびクラウド上の e ラーニング環境自体を自由に利用できる仕組みを構築する。また、問い合わせに応じて e ラーニングを活用した授業実践手法、学
生の自学自習支援手法などのノウハウを提供。
• ニフティは、e ラーニングのシステム基盤として『ニフティクラウド』を提供。『ニフティクラウド』のネットワーク、ストレージ、サーバーリソースを活用することで、全参加大学に安定した講義を実施するための環境を整えた。
• SCS は、ユーザの認証や管理などを一元化し、「なりすまし受講」や「不正利用」を防ぐ仕組みとして、SCS の持つクラウド統合認証サービス「SCS CLIP IAS」および、自社で培ったセキュリティ技術・ノウハウを提供。
＜SCS CLIP IAS について＞
CA Technologies の「CA Arcot WebFort」をベースとした SCS のクラウド統合認証サービス。CA Technologies の協力のもと、大学 e ラーニング協議会に提供。
• 今回の無償提供では、CA Technologies の「復興支援 Arcot 無償プログラム」を活用し、1 年間、被災大学や援助大学に対して提供。
• “多要素認証”機能である「ArcotID」を備えており、これを PC やスマートフォン、iPadなどの端末にインストールすることにより、ハードウェア・トークン等の機器の配布・管理・持ち運びの負荷を負うこと無く、強固なセキュリティに保護されたリモート・アクセスが可能になる。
• クラウド型サービスであるため、運用負荷を軽減し、ユーザ数の増減にも迅速に対応でき
る。

102



サービスの利用実態 61「大学連携高度教育基盤システムは、4 月 15 日に関係者が東京に集まり構築を開始し、4 月 22 日にオープンしました。1 週間もない準備時間のなかで、多くの教材があつまり、また骨太のクラウド環境が動きだし、強力な認証システムも準備が完了しました。
」



クラウドの有効性 62• 迅速性、拡張性、耐災性、安全性の面でクラウドは有効であった。ただし、耐災性、安全性の面では資料を一定基準に基づいて公開するなどの対策が必要である。
• 経済性については、安いクラウドほど障害を起こしやすい傾向があることに留意が必要である。

活用事例： 取引先企業の被災状況や工場稼働状況の確認

クラウド事業者

日本ユニシス(株)サービス名／サービス種類

購買部門向け SaaS サービス「eSupplierStation」

有償／無償

無償

利用者

震災や停電の影響で資材や部品調達が難航し、取引先の状況確認が必要な企業や団体

利用形態・利用目的

情報収集・共有

利用内容

取引先企業の被災状況や工場稼働状況の確認。

期間（開始時期）

最大 3 ヶ月間（平成 23 年 8 月末日まで）
受付期間：平成 23 年 4 月 26 日より 7 月末日まで

サービスの概要
購買部門が実施している取引先への調査やアンケートを効率的に実施し、サプライヤー（供給者）からの情報を有効活用するための取引先情報共有サービス。
• 取引先企業の被災状況や復旧時期の確認、計画停電による工場稼働状況の確認や部品供給能力の調査、事業継続計画（BCP）の内容確認などの情報収集を効率的に行うことができ、生産活動の予測が可能になる。

61

信州大学教授「大学高度教育基盤システムの導入について」より引用（2012 年 3 月現在）
http://www.uela.org/htdocs/pdf/NewsLetter/no3.pdf
62 ニフティへの照会結果による。

103

図表 81 eSupplierStation の概要

出所）総務省「東日本大震災に関するクラウドサービス活用事例集」（2011 年 11 月 4 日）

サービスの利用実態 63
サプライヤ企業向けのアンケートシステムとして、震災の影響を確認することなどに利用された。



クラウドの有効性• 迅速性、拡張性、耐災性、安全性の面で、クラウドは有効であると日本ユニシスの担当者は評価している。

活用事例： クラウド型データ保管・共有サービス

クラウド事業者(株)日立システムズ

サービス名／サービス種類

クラウド型データ保管・共有サービス「セキュア保管庫」

有償／無償

無償

利用者

自治体、企業等

利用形態・利用目的

データ保管・共有

63日本ユニシスへの照会結果による。

104



利用内容

サーバ、PC の重要データを保存し共有できる場所を提供。

期間（開始時期）

2011/4/7 開始

サービスの概要• パソコンやサーバで保管するデータを、データセンター内に安全に一時保管・共有。
• Web ブラウザがあれば利用可能。
• パソコンの故障などによるデータ消失への対策として利用可能。



サービスの利用実態 64• クラウド上でファイルの一時的な保存が可能になり、自治体や企業等で、ある程度利用された。
図表 82 セキュア保管庫の概要

出所）総務省「東日本大震災に関するクラウドサービス活用事例集」（2011 年 11 月 4 日）

クラウドの有効性
日立システムズ(株)によるコメント
クラウド上でデータ共有することで、万が一再被災があったとしてもデータの消失を防げる。
• データの保全が図られることから、耐災性の面でクラウドの有効性が評価できる。

64

日立システムズへの照会結果による。

105

活用事例： 仮想デスクトップ提供 Dougubako（どうぐばこ）

クラウド事業者(株)日立システムズ

サービス名／サービス種類

DaaS サービス「Dougubako（どうぐばこ）」

有償／無償

無償

利用者

自治体、企業等

利用形態・利用目的

情報保存・共有

利用内容

インターネットを通じて、日立情報データセンターに設置したサーバのハードディスク、メモリを利用できるクラウド型のサービス。情報保存・共有ための臨時システムとして利用。

期間（開始時期）

2011/4/7 開始

サービスの概要• データセンター内に構築された顧客専用の仮想デスクトップ空間を提供。
• 作成したデータはデータセンター内の「データ金庫」にてセキュアに保管。
• 顧客の利用したいアプリケーションを選択して利用可能。

図表 83 DaaS サービス「Dougubako」の概要

出所）総務省「東日本大震災に関するクラウドサービス活用事例集」（2011 年 11 月 4 日）

106



サービスの利用実態 65• パソコン本体と共にシステムを提供し、提供から即業務の再開が可能となったことから、大いに利用された。



クラウドの有効性
日立システムズ(株)によるコメント•

クラウド側でオフィス系ソフトが準備されているため、提供からすぐに利用できる点が評
価が高かった。

•

また万が一再被災があったとしても、データはクラウド上に保管されるため、パソコン・端末の損壊にも耐えられる他、事務所が倒壊しても自宅などからデータ・システムへのアクセスが可能。

• 上記のコメントから、迅速性、耐災性の面からクラウドの有効性が確認された。

活用事例： 仮想サーバの無償提供•

サービス提供者

ソフトバンクテレコム(株)•サービス名／サービス種
類

ホワイトクラウド シェアード HaaS スタンダード

•

有償／無償

無償

•

利用者

助けあいジャパン

•利用形態利用目的

ホスティング•

利用内容

仮想サーバのリソースを無償で提供•

期間（開始時期）

2011/3/14～

 サービスの概要
 復興支援等の情報発信サイトの新規構築や、既存の公的情報提供サイトのアクセス集
中対策目的に、「ホワイトクラウドシェアード HaaS スタンダード」を 3 月 14 日から無償で提供開始。
 義援金募集活動サイト、ボランティア支援ポータルサイト、輪番停電情報発信サイト、
安否確認情報サイトなど、19 団体様、33VM(仮想マシン)が被災者支援・災害情報提供に利活用。

65

日立システムズへの照会結果による。

107

図表 84 ホワイトクラウド シェアード HaaS の概要

出所）総務省「東日本大震災に関するクラウドサービス活用事例集」（2011 年 11 月 4 日）

 サービスの利用実態
助けあいジャパン担当者によるコメント 66
非常に役だった。発災後、迅速に支援決定、導入でき、用途拡大に応じた拡張が容易だった。災害時向け支援として、無償で利用させていただけた。
ソフトバンクテレコム担当者によるコメント 67
非常に公益性の高い通信事業者として広くかつ迅速に情報共用の場を提供することは使命の一つでもありました。クラウドプラットフォームを、この目的のために無償提供できたこと
は社会貢献の意味も込め、弊社にとって非常に役立った事例でした。
 クラウドの有効性 68
 迅速性、拡張性をはじめ、様々な面で、クラウドの有効性が発揮された。

66

助けあいジャパンへの照会結果による。
ソフトバンクテレコムへの照会結果による。
68 助けあいジャパン及びソフトバンクテレコムへの照会結果による。
67

108

2.3.2. 被災団体の対応実態の分析
被災した地方公共団体における情報システムの復旧・復興に向けた取組を整理し、利用者及び利用者の IT をサポートする立場の視点から、クラウド活用の実態を分析した。
図表 85 東北 4 自治体の危機的事象と被害状況の事例
国見町
（福島県）

多賀城市
（宮城県）

陸前高田市
（岩手県）

山田町
（岩手県）

・震度 6 強・震度 5 強・津波 4.6m

・震度 5 強～6 弱・津波 21.5m

・震度 5 弱
・津波
・火災

庁舎

使用不能→移転
地震動で一部損壊、周囲の液状化で使用不能

被害なし

使用不能→移転
津波で４階まで浸水

使用不能→修復
津波で大破

電力

当日は停電
翌日から復旧

三日間停電

三日間停電

3/15 から発電機で庁内へ給電開始

データ

被害なし

被害なし

被災
一部被災ディスクから復旧

被災
一部被災ディスクか
ら復旧

外部ネッ
トワーク

3/22 に移転庁舎で利用可能に

3/17 まで
インターネット不通

3/29 に 衛 星 携 帯 で 、
3/31 に通信衛星でアクセス可能に

4/14 に庁内からイン
ターネットへのアクセ
スが可能に

人材

被害なし

被害なし

被災。前々任が引き継ぎ。市外から支援受入

負傷するも数日後に
復帰。

危機的事象

被
害
状
況

出所）東日本大震災被災地自治体 ICT 担当連絡会「東日本大震災と自治体 ICT」セミナー資料及び公開情報をもとに作成

図表 86 東北 4 自治体の位置関係

109対応事例： 国見町



危機的事象・被害状況• 震度 6 強。
• 庁舎が損壊、周囲は液状化（庁舎の耐震補強計画は 22 年度に策定され、工事が 23 年度に予定されていた）。
• ホームページはデータセンターにハウジングしていたため被害なし。



復旧に向けた対応• 文化センターへ、役場機能の移転を決定（電源工事の業者、部材の確保に奔走）。
• 翌々日（3/13）からシステム復旧に向け本格始動。
• 2 週間後（3/25）から、全業務を再開。



復興に向けた対応• 基幹系システムのクラウド化。
• 庁舎とすべての主要施設を、光ケーブルに加え、無線で接続。

図表 87 国見町役場の被害と復旧
当日(3/11)

移転後（3/25）

出所）東日本大震災被災地自治体 ICT 担当連絡会「東日本大震災と自治体 ICT」セミナー資料

110対応事例： 多賀城市



危機的事象・被害状況• 震度 5 強。津波で市域の 3 分の 1 が浸水。死者 188 名。
• 情報システムは仙台のデータセンターで運用していたため、被害なし。庁内のサーバも免震床で被害なし。
• NTT 基地局被災により、インターネットが数日不通。ホームページの運用が途絶。



復旧に向けた対応• ネットの通じる個人宅からホームページの情報を更新。支援物資が届くようになる。
• 被災者向け相談窓口設置に伴って、業務横断的に、相談履歴を一元管理するシステムを
職員が 5 日間で構築。
• 市民対応窓口の環境に、無線 LAN を導入。
※3/11 時点の住民記録データを隔離保存しなかったことは反省点。



復興に向けた対応• ホームページの更新もできる衛星携帯電話を調達。
• データの遠隔地保存を検討中。

図表 88 多賀城市で稼働している震災関連システム等

出所）東日本大震災被災地自治体 ICT 担当連絡会「東日本大震災と自治体 ICT」セミナー資料

111

対応事例： 陸前高田市



危機的事象・被害状況• 震度 5 強～6 弱。倒壊はなし。津波で庁舎 4 階まで浸水。
• 情報システム、データは津波で被災。データは一部被災ディスクから復旧できた。
• NTT 局舎が津波で被災し、電話、インターネットが不通。



復旧に向けた対応• 情報システムの現任が被災したため、前の前の職員が引き継ぎ。また、名古屋市の情報シ
ステム職員が長期サポート• 衛星携帯電話 2 台を職員 2 名が 24 時間はりついて外部と交信。事実上のライフライン。
• 仮庁舎におけるサーバルームを、情報システム担当一人で設計、調達、構築。
• システム不具合が頻発。ほとんどが電源が不安定なことに起因。自家発の併用、UPS や
CVCF の増設で対応。



復興に向けた対応• データバックアップの拡充（クラウド活用など）

図表 89 被災後のサーバルーム（ここから可能な限りデータを取り出した）出所）東日本大震災被災地自治体 ICT 担当連絡会「東日本大震災と自治体 ICT」セミナー資料

112

対応事例： 山田町



危機的事象・被害状況• 震度 5 弱。津波、火災で壊滅的被害。
• 庁舎地下に設置していた情報システム、発電機等はすべて破壊。
• データは一部被災ディスクから復旧できた。



復旧に向けた対応• 「電気がないなら、電気を作れ！」の課長の指示で、担当者が自家用車で盛岡に行き、大型発電機を調達。
• 6 台の発電機を調達し、18 リッター缶を毎日 20 缶給油。
• 電源不足で、昼は被災者支援、夜は内部業務を稼働。3 ヶ月この状態が続く。
• 衛星通信、3G 回線でインターネット接続• データは二次利用できるように USB メモリで保存。外部とのデータ交換に、オンラインスト
レージを利用。

図表 90 山田町_役場庁舎被害（情報システム、自家発は地下にあったため破壊された）出所）東日本大震災被災地自治体 ICT 担当連絡会「東日本大震災と自治体 ICT」セミナー資料

113

2.4. 東日本大震災に関するクラウドサービスの有効性の検証結果
 東日本大震災に際して、被災者・被災企業やその救援・支援にあたる行政やボランティア
組織に対して提供された様々なサービスにおいて、クラウドが有効活用されていた。
• 情報共有・流通基盤• 被災者救援活動の情報インフラ• 行政情報提供サイトの拡張• 被災企業等の緊急情報発信・業務処理 東日本大震災に際して利用されたクラウドサービスでは、特に「迅速性」の面で有効性が確認された。また、「拡張性」や「耐災性」についても有効性が評価できる事例が多数みられた。
［有効性の観点］• 迅速性（短期間で構築、サービス開始が可能）• 拡張性（利用実態に合わせて能力を拡張することが可能）• 経済性（必要なリソースだけ利用することができる、供給側のコスト負担が限定的）• 耐災性（災害に強い）• 安全性（情報セキュリティに優れている）

図表 91 分析対象としたサービスの観点別の有効性評価
有効性の観点安全性

耐災性

岩手県の安否情報 Web サイト

経済性

活用事例

拡張性

迅速性

用途区分

○

○

在宅勤務による事業継続○

被災地医療に生かされた在宅医療クラウド①
情報共有・ 被災した企業の企業活動、安否確認、情報
流通基盤 発信等のためのホスティング

○

○

○

情報提供サイト（sinsai.info）のホスティング○○

携帯メールと位置情報の蓄積・検索・提供「J!ResQ」

○

○

○

○

救援情報共有システム「SAHANA」構築②
被災者救援 輸血用血液製剤の安定供給支援

114

○

○
○
○

○

○

○

○

○

有効性の観点○

農山漁村被災者受入れ情報システム○○

震災復興支援システム○

クラウド環境にミラーサイトを構築し、アクセス③
行政情報提 集中に対応
供サイトの 「東日本大震災 子どもの学び支援ポータル
拡張サイト」にクラウド型情報基盤サービスを提供○○

アクセス急増した震災情報システムに IaaS
環境で対応

○

被災地向け安否確認・Web 会議の提供○

大学連携高度教育基盤システム④
被災企業等
取引先企業の被災状況や工場稼働状況の
の緊急情報
確認
発信・業務
サーバ、PC の重要データを保存し共有で
処理

安全性

○

活動の情報
被災動物救護支援サービス
インフラ
被災者と NPO をマッチングするクラウドサービ
ス

耐災性

拡張性
○

活用事例

経済性

迅速性
○

用途区分

○
○

○

○

○

○

○

○

○

○

○

きる場所を提供

仮想デスクトップ提供○

仮想サーバのリソースを無償で提供

○

○
○

○

○

○

 他に抽出された知見• データセンターそのものは被害なし。しかし、ほとんどのネットワークが途絶し、データセ
ンターを利用できなかった。ネットワークの多重化、ネットワーク途絶時に運用できる縮退運用環境の確保及びネットワーク復旧時にデータの同期を図れる仕組みが必要である。
• 停電時の運用継続のため、燃料の確保が課題として認識されていた。
• 被災した地方公共団体では、データセンター活用への移行を前向きに検討している。

115

3.

東日本大震災におけるデータセンターの緊急対応の実態と課題（実態調査その３）

3.1. 調査の概要
東日本大震災に際しては、被災地ならびに関東地域にあるデータセンター（DC）およびクラウドサービスにおいて、震災による直接の被害や、電力その他のユーティリティの供給制約の中で、サービスを維持するために非常時対応の対策が実施され、有効に機能した。
本節では、データセンターならびにクラウドサービスを提供している事業者を対象に、東
日本大震災時の実態について調査し、緊急時に機能やサービスを維持するための要件を抽出した。

3.2. 調査の方法
東日本大震災の影響を受けたと想定される、東北・関東地域に立地するデータセンタ
ーおよびクラウドサービスを運営する事業者を 9 社選定し、インタビューを実施。インタビュ
ーが難しい事業者については、既存資料の調査を実施し、緊急時に機能やサービスを維持するための要件を抽出すべく、分析を実施した。
分析に当たっては、以下の要件が含まれていることに留意して実施した。
① 平常時におけるライフラインの冗長性確保② 緊急･災害時における代替ライフラインの確保③ 緊急･災害時における代替ライフライン確保のための二次的サプライの要件④ 通信回線に関する平常時ならびに緊急時の要件⑤ データセンターの運転ならびに保安のための要員に関する要件⑥ 意図を持って行われるサイバー攻撃に対する防衛または回避
東日本大震災時の対応だけでなく、大震災発生前の対策、どの対策が上手く機能したか、震災時には表面化しなかったが、東日本大震災以上の震災が発生した際に表面化すると想定される課題事項についても言及する。
【インタビュー実施対象会社】


通信系事業者• KDDI 株式会社
• 株式会社インターネットイニシアティブ• NTT コミュニケーションズ株式会社

SI 系事業者• 富士通株式会社• 日本 IBM 株式会社• 日本ユニシス株式会社

116

• 株式会社野村総合研究所【既存資料調査対象会社】• ソフトバンク株式会社• Amazon Web Service(AWS)※ ソフトバンクおよび AWS は既存資料より東日本大震災時のサービス実態のみ調査。
【主なインタビュー項目】


災害等の緊急時に対する対策状況について• ハード面における対策状況

データセンター設備（電気・水道・ガス等のライフライン、自家発電設備など）

クラウドサービス基盤の対策状況• ソフト面における対策状況

運転要員の確保状況



緊急対応マニュアル準備状況



各種データ保管状況

東日本大震災発生時における緊急対応の実態について• 震災発生直後• 震災発生後のライフライン途絶時• 震災発生より一定期間後• 震災による特殊事例発生時• 震災時における緊急対応の反省点、今後検討すべき課題

クラウドサービスおよびデータセンターにおける情報セキュリティへの対応状況

クラウドサービスの利用事例

3.3. 大規模災害時におけるデータセンターの対応と課題
インタビュー結果の詳細は図表 91 にまとめたが、各社の対応と明らかになった課題について、項目別に紹介する。

117

3.3.1. 平常時における緊急事態対応の準備状況（1） ハード面における対策状況① データセンター設備
データセンターのハード面における対策、「データセンターの躯体構造」、「ライフラインの確保状況」、「緊急時の仮移転準備」の 3 点の取り組みについて把握した。
データセンターの躯体構造
データセンターの躯体構造については、各事業者とも耐震構造であり、制震・免震構造（装置）を備えているものも多い。立地についても活断層の有無を事前に調査していると回答する事業者もあった。
ライフラインの確保状況
ライフラインに関しては、商用電源、非常用電源について調査を行った。商用電源に関しては各社とも冗長化を図っている。具体的な対応としては、少なくとも 2 箇所の変電所から受電している。その上で 1 変電所から 2 系統の受電を行っている例や、さらには電力会
社 2 社から受電している例もあり、商用電源の冗長化については各社とも十分な取り組み
がなされているとみられる。
停電時の電源については、各事業者ともUPSならびに非常用自家発電装置を備えているが、自家発電装置の燃料備蓄については、データセンターの立地条件に応じた消防法の規制やデータセンターのティア 69等によって基準が異なっている。但し、複数の燃料供給元との優先供給契約は各社とも締結している。
緊急時の仮移転等の準備の有無
調査対象の各社とも、国内の他地域もしくは国外にデータセンターを保有しており、必要に応じて緊急時にバックアップや仮移転が可能であった。なお、国内においては、東日
本と西日本にそれぞれ 1 拠点というように、距離や電力供給区域を考慮してデータセンタ
ーの配置が行われている。
② クラウドサービス基盤の対策状況
データセンター設備の上にクラウドサービス基盤が運用されるため、基本的には前項の対策状況はカバーすることになるが、クラウドサービス基盤側で行う対策として「通信回線の冗長化」およびクラウドサービスにおける事業継続計画（BCP）つまり「ディザスタリカバリー（DR）サイト」の準備が挙げられる。
通信回線については、各事業者とも異なる通信キャリアの有線回線による冗長化を図っ
69

データセンターに求められるパフォーマンスのレベルごとに定められた施設要件の階層。ティア 1 から 4 まで規定されている。数字が大きいほど求められるサービス継続性の要件が高くなる。

118

ている。通信事業者系クラウドの場合でも、ユーザニーズが多いためか、自社回線＋他社回線による冗長化を図っている。また、緊急連絡用に衛星電話の設置を行っている事業者も多い。
また、調査対象の各社とも複数のデータセンターを運用しているため、そこにクラウドサ
ービス基盤の DR サイトを構築する形態であった。ただ、DR サイトを利用するには各社とも
別途オプション費用が必要になる。オプション費用を払うことで、他地域（場合により国外）のデータセンターでリカバリー可能となる。

（2） ソフト面における対策状況
ソフト面における対策として、「運転要員の確保」、「緊急対応マニュアルの準備」、「各種データ保管」の 3 点について現状の取り組みを把握した。
① 運転要員の確保状況
緊急時の運転要員については、各社とも通常のシフト要員で対応可能であるとの回答が多かった。その中で、大手通信系事業者は、緊急時に必要であればデータセンターの要員以外に通信局舎の運転要員を追加招集することが可能という回答であった。これは、データセンター、局舎を含め設備ならびに運転要員を多く所有する通信系事業者の特徴と言える。
次に、運転要員の食料と飲料水については数日分を確保しているという回答が大半を占めた。一般的に被災時に孤立した場合、最低 3 日間の食料と飲料水の備蓄が推奨されている。これは、3 日後には被災地外からの救援が届くという前提で推奨されているものであり、この観点からは問題はないものと考えられる。ただし、正確な日数については把握していないとのコメントが多かったことから、正確な備蓄数の把握が求められる。合わせて鮮度（消費期限）の管理を徹底しておくことが必要と考えられる。
② 緊急対応マニュアルの準備状況
緊急対応マニュアルについても各社とも作成済みであり、災害対応訓練も定期的に実施している。訓練の規模により間隔は異なっているものの、最短毎月、長くとも半年に 1 回
程度何らかの訓練を行っている。ただし、東日本大震災時に有効に機能したマニュアルとそうでないものとが混在しており、各社見直しを実施している。
③ 各種データ保管状況
ここでは、クラウド事業者とユーザが管理するデータが混在し、管理の役割分担が複雑になる IaaS を前提に、クラウド事業者のデータ保管状況について把握した。
把握した項目は、「クラウド事業者のデータ保管対象（デフォルト）」、「クラウド事業者のデータ保管対象（ユーザ管理範囲の代行保管）」、「保管データのバックアップの有無」、「保管データ量及び増加スピード」、「保管期間」、「復旧方法」の 6 項目である。
119

クラウド事業者のデータ保管対象（デフォルト）
IaaS における事業者の管理範囲はホスト OS レイヤー以下にあたるが、その部分の各
種運用ログ（アクセスログ、イベントログ等）およびシステムバックアップを保管対象とする回答が大半を占めた。
クラウド事業者のデータ保管対象（ユーザ管理範囲の代行保管）
IaaS におけるユーザの管理範囲はゲスト OS レイヤーより上にあたるが、クラウド事業者
によっては、ユーザ管理範囲のデータについて、ユーザから委託を受けてデータバックアップを取得・保管している事業者も多くみられた。これは、今回ヒアリングしたクラウド事業者の大半が SIer を兼ねているためだと推測される。また、ユーザ管理範囲データの代行保管を実施する担当者はクラウドサービス管理者とは別組織になることが一般的であることも分った。セキュリティ・プライバシーへの配慮の現われと考えられる。
保管データのバックアップの有無
各社とも当然ながら管理範囲データについてはバックアップを取得している。バックアッ
プデータの保管先として、遠隔地バックアップは 2 社にとどまり，大半は同一センター内の別筺体へ保管している。
保管データ量及び増加スピード
保管データ量の正確な数値はほとんど明らかにされなかったが、大半の事業者からは保管データが今後も増大していくとの見通しが示されている。
保管期間
保管期間について、「上限を設けていない」事業者から「5 年程度」の事業者に至るまで、まだ混在している状況である。
復旧方法
各社とも復旧方法として標準的なリストアによる復旧方法を採用している。
④ その他
ソフト面における対策の中で大規模災害以外に実施しているものとして、パンデミック（感染症の爆発的流行）への対応を取っている事業者も見られた。

120

3.3.2. 東日本大震災における対応
基本的には、今回調査対象となった事業者においてはサービス停止等の大きな影響を受けていない。また、日本データセンター協会に対するインタビューにおいても、事業としてデータセンターを運営している事業者に関しては、甚大な影響を受けたという報告はな
いとのことであった。
（1） 地震の検知からサービスの状況確認までの対応
地震の検知とサービス継続確認に至る対応については以下のようなものであったという。
地震の感知については、オペレータからの連絡、一般的な緊急地震速報システムの他、事業者によってはNPO法人リアルタイム地震情報利用協議会 70から提供される高度な地
震速報を活用しているケースもあった。各社とも東日本大震災時には地震の感知・検知から 10 分～1 時間程度でサービス継続の確認に至っている。
（2） ライフライン途絶への対応
ライフラインの途絶については、東日本大震災時は多くの事業者で停電を経験している。
今回は各データセンターとも自動で商用電源から自家発電に切り替えを実施している。その後、データセンターの設置エリアにより差があるが、8 時間～24 時間後に商用電源が復旧した。商用電源復旧後、多くの事業者で手動手順により自家発電から商用電源への切り戻しを実施しており、切り替えについては問題は生じていない。
自家発電装置への燃料補給は、停電が長時間にわたった 3 社で実施されている。このうち 1 社では近隣の供給元からの補充調達が難しかったため、遠隔地の燃料供給元から調達せざるを得ないという問題に直面した。それでも今回は商用電源の復旧が比較的早かったため、多くの事業者では燃料補給の問題は深刻化しなかったものの、今後の燃料確保について課題であると認識している。
（3） 東日本大震災で初めて直面したリスクへの対応
東日本大震災による原子力発電所の緊急停止や事故の影響で電力の供給能力が不足し、計画停電が行われた。この計画停電の対象となった事業者もあったが、数時間程度であり、事前の対応手順に従って大きな問題なく対応が可能であった。
（4） 緊急対応の反省点と今後の課題
このように、サービスが途絶しなかった理由は、建物自体が堅牢であったこと、緊急時対応マニュアルが機能したこと、自家発電燃料供給会社との優先供給契約や複数の供給会社と契約していたことが機能したことがあげられる。しかしながら、半数以上の事業者から
は「自家発電燃料が切れた場合の対応方法」を課題として挙げられた。これは、今回の東日本大震災以上の災害が発生し、商用電源停止時間がさらに長時間になった場合に、現在の備蓄量や優先供給契約だけでは対応が困難になると多くの事業者は考えているため
70

同協議会の Web サイト http://www.real-time.jp/

121

である。
たとえば、燃料優先供給契約を結んでいたにもかかわらず、実際には供給が滞り、代替供給元の探索と実際の補充調達に時間がかかった事例が見られたことから、優先供給契
約だけでは安全とは言い切れないという認識がある。また、日本データセンター協会も「非常用発電機の燃料確保」を東日本大震災における最大の教訓に挙げ、燃料調達先の複数化（可能であれば異なる石油元売り）を推奨し、加えてデータセンターのファシリティ基
準のうち自家発電装置の燃料確保量について、優先供給契約によって確保した分を除外する変更を行った 71。
ただし、コストはもとより、設備面の制約や消防法の規制により無限に備蓄量を増やすことはできない。このため、技術的にはデータセンターの消費電力を抑えることと、自家発電
装置の燃料効率を高めることが望まれる。具体的には、冷却効率の改善、省電力 IT 機器の適用などのエネルギー効率化ソリューションや、石油以外の代替エネルギーを活用した
ソリューションなどが出てきているため、各データセンターの置かれている状況に合わせ、このようなソリューションを検討していく必要がある。一方で、燃料供給の優先順位を高められるよう、社会的なコンセンサスを得ていくことも求められよう。
また、事業者とのヒアリングでは出てこなかったが、燃料だけでなく、運用者向けの水・食料の確保も同様と考えられる。一般的な備蓄量としては、1 人あたり 3 日分と言われている。
データセンター事業者へのヒアリングでは数日～10 日分という回答が大半であったため一般的な水準はクリアしている。しかし、仮に備蓄量を超えて水・食料が必要になった場合を考えると、近隣の自治体との協力が考えられる。各自治体で非常食を備蓄しているため、有事の際にどうするか事前に協議する必要がある。
（5） 震災の経験を踏まえた今後の対応
各社とも上述したように自家発電用燃料の確保について課題を感じている。また、発災時の社員との連絡等の通信手段の確保についても、今後見直しを進めるとしている事業者もある。さらに、今回の経験を踏まえ、マニュアルや訓練の見直しを計画している事業者もあった。
また、データセンターの被害はなかったものの、沿岸部埋め立て地等での地盤液状化とそれによる建造物ならびにライフラインの被害が報告されており、立地選定やデータセンタ
ーの躯体の設計においては今後考慮することが必要となると考えられる。
3.3.3. クラウドサービスのセキュリティ対策について
セキュリティ対策については、以下の項目について把握した。
•

OS やアプリケーション等のシステムに関するセキュリティ対策•

データ管理対策

71日本データセンター協会「東日本大震災を踏まえたデータセンター（ダイジェスト版）

122

ファシリティ スタンダードの検証と見直し•ネットワークと通信に関するセキュリティ対策•

物理的アクセス管理に関するセキュリティ対策•

運用要員に関するセキュリティ対策（1） システムおよびデータ管理におけるセキュリティ対策
各社とも、多少の差異はあるものの同様の対策ができている。システムそのもののアップ
デートによるセキュリティ向上は事業者の管理範囲では適切なタイミングで行っている。また、ユーザ管理範囲のシステムについては、基本的にユーザ判断となるが、事業者からの情報提供を行ったり、サービスとして受託して実施したりする例がある。
また、事業者管理部分のハードウェア（サーバ、ストレージ、ネットワーク）については各社とも冗長化を実施している。
データ管理に関するセキュリティ対策について、サイバー攻撃対策の考え方で、攻撃を防御する対策と仮にデータが盗まれたとしても改ざん・漏えいまでには至らないようにする対策がある中で、後者の対策としてストレージ暗号化メニューを提供するクラウド事業者が数社あった。
（2） ネットワークと通信に関するセキュリティ対策
ファイアウォール、IPS 72やIDS 73による不正侵入防止、検知、遮断は各社とも実施しているほか、ウィルスチェックソフトの提供、アップデートなども行っている。サイバー攻撃に対する監視、検知、解析についてもオプションとして提供している事業者が多い。
特徴のある取り組みの一つとして、あるゲストバーチャルマシンで通信中のパケットに不審な挙動が発見された場合、当該ゲストバーチャルマシンを停止して他のユーザの保護を図ることを選択肢に入れている事業者がある。
（3） 物理的アクセス管理に関するセキュリティ対策
物理的アクセス管理については、入退館管理等のデータセンター施設に対するもの、
およびデータセンター内においてクラウド基盤を構成する各機器（サーバ、ストレージ、ネットワーク等）に対するものの 2 点について把握した。
まず、データセンター施設へのアクセス管理については、入退館管理、持ち出し管理などは当然実施されており本人認証のための生体認証設備や、持ち出し管理のためのスキャニング装置などの高度な設備を設置している事業者もある。
機器に対するアクセス管理については、ラックの施錠管理、各機器のログインＩＤ・パスワ
ード設定などの対策を各事業者とも実施している。
（4） 運用要員に関するセキュリティ対策
直接的なセキュリティ対策ではないが、運用要員に対する情報倫理・非行対策について、
72
73

Intrusion Prevention System：不正侵入を検知した場合に通信を遮断する装置
Intrusion Detection System：不正侵入検知装置

123

「身元・履歴確認」、「服務規律・就業倫理教育」、「システムとデータへのアクセス権・特権管理」の 3 点を調査した。
身元・履歴確認について、各社とも自社もしくはグループ会社で運用要員を採用する際は、身元・履歴確認を実施している。また、運用要員を外部委託している事業者では、契約で担保するようにしている。
服務規律・就業倫理教育は各社とも自社で策定したポリシーに則り、運用業務におけるルールや情報倫理に関する教育を実施している。
また、システムとデータへのアクセス権・特権管理について、運用要員と管理者などの役
割の違いによりアクセス権限や管理者特権を設け、役割以外のシステムを操作できないよ
うにしている。
これらの対策が有効に働いているか確認するために、運転要員の作業や業務に関するモニタリングを行っている。具体的には、操作ログを取得したり、モニター越しに管理者が運用要員の監視を実施している。また事業者によっては内部監査なども行って、万全を期している。
（5） セキュリティに関する情報開示
セキュリティマネジメントという観点でセキュリティに関する情報開示についてのヒアリングも実施したので、参考までに記載する。大きく 2 つの観点があり、一定の基準を満たしていることを外部に示すために事業者が取得した第三者認証を開示するものと、利用者側の監査等で必要な場合に実際の取り組み内容を開示するものがある。各社とも両方の開示を実施していた。ヒアリングの際に出てきた主な第三者認証は、一般財団法人日本情報経済社会推進協会（JIPDEC）が認定する情報セキュリティマネジメントシステム適合性評価
制度（ISMS）やプライバシーマーク、AWSが取得したことで話題になった、クレジット業界におけるグローバルセキュリティ基準であるPCI 74 データセキュリティスタンダード（PCI
DSS）などがある。
（6） セキュリティに関する今後の課題
これまで見てきたとおり、各社とも必要と考えられるセキュリティ対策を実施しており、現状の対策でセキュリティインシデントの発生というようなトラブルに関する話はなかった。ただし、質的に改善させるという意味合いで、「ハイパーバイザーレイヤーの脆弱性対策の改善」、「データセンターへの機器持込持出管理の改善」を今後の課題として挙げている事
業者があった。

74

Payment Card Industry124

図表 92 各事業者のインタビュー結果
DC・クラウド事業者回答

インタビュー項目
大項目

中項目

A

小項目

B

C

D

E

F

G

• 震災影響を受けたクラウ • 震災に関する項目につ • 震災に関する項目につ • 震 災 に 関 す る 項 目 に • 震 災 に 関 す る 項 目 に • 震災に関する項目につ • 関東地方にある DC にクラウ
ド基盤、DC なし。

震災の影響範囲にあったクラウド基盤もしくはDC の所在地

ライフライン冗長化の有無

いては、東北地方に所

いては、東北地方に所ついては、東北地方については、関東地方にいては、東北エリアのドサービスを展開しており、在する DC を対象に回在する DC を対象に回所在する DC を対象に所在する DC を対象にDC を対象に回答する。

計画停電の対象となってお

答する。

答する

回答する。

回答する。

り、その DC に関して回答す※クラウド基盤がある※クラウド基盤がある※クラウド基盤がある※クラウド基盤がある DC※ ク ラウド基 盤があ る※ 同 所 に あ るク ラウド

DC は東日本と西日本に

DC は３箇所（関東、関DC は関西と中国の２箇は東日本と西日本の２箇

DC は関東と関西の２基盤は震災後にサー展開

西、北海道）

所

所

箇所

ビス開始

• 電力のみ冗長化• 電力のみ冗長化• 電力のみ冗長化• 電力のみ冗長化• 電力のみ冗長化• 電力のみ冗長化る。

• 電力のみ冗長化※２箇所の変電所から※電力会社 2 社から引

※2 箇所の変電所から 2 系

電力供給

込み

統＋１系統の計３系統を引込み

無停電設備設置の• 各事業者とも「UPS、自家発電有り」
有無

DC 設備

• 72 時間分備蓄• DC により 24 時間もしく • DC により 24 時間もしく • DC により 48 時間もしく • 社内基準にもとづき数 • DC により 24、48、72 時 • 自家発電設備燃料につい• 複数の燃料供給会社とは 48 時間分備蓄

優先契約• 残量が 50％切った場合 • 自家発電稼働する度に • 自家発電稼働する 度 • 補 充 条 件 も 社 内基 準 • 自家発電稼働する度にいる範囲内で備蓄してい

に補充

る。

自家発電設備燃料の備蓄状況と補充する際の条件クラウド・DC
サービスにおける緊急時の対策状況

は 48 時間分備蓄は 72 時間分備蓄補充している。

に補充している。

日分備蓄。

間分備蓄

て、消防法上で定められてにもとづき補充してい補充している。

• 複数の燃料供給会社と • 複数の燃料供給会社と • 複数の燃料供給会社

る。

• 複数の燃料供給会社と • 社内基準にもとづき補充し優先契約• 複数の燃料供給会社

優先契約

と優先契約

• 電源車を所有している。 • 複数の燃料供給会社と優先

優先契約

と優先契約

ている。
契約

• 東 京 ・ 関 西 ・ 北 海 道 の • 他地域 DC にて DR 可 • DR についてはファイル • 他地域の DC へ移行を • 国内含め全世界に 6 • 他地域の DC にて DR • 他地域（関西）の DC にて

緊急時に仮移転等の準備の有無DC にてマルチ運用（オ能サーバサービスのみ

計画

が可能

DR が可能プション）が可能。

※オプション• 他サービスはバックアッ※グループ内の DC 間

※クラウドサービスとして※オプション

プとって、サイト復旧時

でリングを組むなど

はオプションにサービス復旧となる。

・コンテナタイプの DC拠点がある。

も今後作る予定。

通信回線

DC 側回線冗長化の有無
回線冗長化の組合
せ各事業者とも「異キャリアによる冗長化」
各事業者とも「有線による多重化」
各事業者とも「オプションで DR 対応可能」

DR サイトの有無
保守要員• 状況により、追加招集す • 計画停電時やセンター単体• 追加要員はない。
• 追加招集あり。
• 追加要員はない。
• 追加要員はない。
緊急時に追加要員 • 追加要員はない。
招集するか• 通常のシフト要員で運用 • 通常のシフト要員で運用 ※緊急時は他地域の局 • 通常のシフト要員で運 • 通常のシフト要員で運 る。
の緊急時は別途要因招集125

DC・クラウド事業者回答

インタビュー項目
大項目

中項目

A

小項目

B

C

D

舎、センターから追加召用集※当該 DC には要員 • 状況により、マネージャが 200 名いる

緊急時の食料備蓄
状況

E

用

F

G

※計画停電時に念のたする想定でいるが、昨年のめ招集した

東日本大震災規模の場合

ー に つい ては追加 招だと、追加招集は現実的で集する。

ないと考えている。

• 1 人当たり 7 日分の乾パ • 1 人当たり約 10 日分の • 数日分の食糧備蓄有り• 数日分の食糧備蓄有 • 数日分の食糧備蓄有り • 正確に把握してないが、 • 数日分の食糧備蓄有り

ンを備蓄

り

食料を備蓄

数日分の食糧備蓄有り※震災前は 3 日分だっ

※食料・飲料の備蓄は 120～130 食分ある。

た• 震災前にマニュアル準 • 震災前に以下準備済み • 震災前に以下準備済み • 震災前にマニュアル準 • 震災前にマニュアル準 • 震災前にマニュアル準 • 震災前に以下準備済み。
備済み

備済み。

備済み。

備済み。

※ 災 害 対 応 フロ ー 、緊※ 全 体 フロ ー 、安 否 確※大規模障害時のノウ※安否確認システム、地震急対応マニュアル、安否認システム、初期損害チ

ハウは溜まっており、そ発生時の確認リスト。

確認システムなどェックリスト。

れを元にしたマニュアルがある。

• コンピュータ稼働のために
以下の対策を実施。

震災前準備の有無

・電源冗長化
・発電機のクラスタ化
・UPS、空調機、冷凍機の
予備

緊急対応マ
ニュアル

→損害レベル別に４段階に分け。LV4 になるとコンピュータに影響あり• 安否確認テストを 2 カ月 • 災害訓練は、定常的（半 • 災害訓練は、定常的（月 • 災 害 訓 練 は 、 定 常 的 • 災 害 訓 練 は 、 定 常 的 • 災害訓練は、定常的（年 • 災害訓練は、定常的（週１に１回実施。

年に１回）に実施してい１回）に実施している。

る。

（月１回）に実施してい（月１回）に実施してい数回）に実施している。

る。

る。

※会社と して大規模 障※震災前は 3 カ月に１回災害訓練の有無回）に実施している。

害時想定した対策本※毎回被害個所を変えて、部、エスカレーションの訓練実施。

安否確認は年に数回、大規模障害を想定した
災対フロー訓練も実施。
• ホスト OS レイヤーのシス • ホスト OS レイヤーのシス • ・データの保管対象は、 • ホスト OS レイヤーのシ • 当社管理部分並びに データ保管対象
各種データ（事業者範囲）保管※デフォルトテムバックアップ、各種

テムバックアップ、各種

ファイルサーバの DR オ

ステムバックアップ、各ユーザ作成分も含めた運用ログが対象

運用ログが対象

プション契約分

種運用ログ、課金デー

VM のイメージをバック• 各種運用に必要なログ

タが対象

アップしている。

（ 監 視 ロ グ 、 ア ク セ ス ロ • ゲスト OS 以上のレイヤ

126• ホスト OS レイヤーの各種運用ログが対象DC・クラウド事業者回答

インタビュー項目
大項目

中項目

A

小項目

B

C

D

E

グ）

ー が対 象で ユー ザに• 仮想サーバのスナップシてバックアップ

F

G

ョット（IaaS,PaaS 系以外）。
データ保管対象（ユーザ管理範囲の代行保管）※オプション• ゲスト OS 以上のレイヤ • ゲスト OS 以上のレイヤ • 代行取得しない
ーの各データ• ユーザ管理の DB• 代行取得しない

ーの各データ• ゲスト OS 以上のレイヤ • ゲスト OS 以上のレイヤーのーの各データ

各データ• 北海道 DC に遠隔地バ • 遠隔地バックアップ• ファイルサーバの DR • 別

ックアップ

オプション契約分についDisktoDisk によるバッについては、別筺体にDisk2Disk、テープ、遠ては DR サイトへバック

クアップ。

Disk to Disk でバック

隔 地 バ ッ ク ア ッ プ が 可 • 今後遠隔地バックアップ予

アップ（遠隔地バックアッ

アップ

能。

プ）。

• 自 社管理 分につい て• その他データについて

は、外部媒体へバックは、同一センター内の裏アップしている。

保管データバックアップの有無筺体への • ユーザバックアップ分 • ユ ー ザ 指 定 で • データバックアップについて、同サイト内に保管。
定サーバへ Disk to Disk
でバックアップ。
• 回答差し控え保管データ量及び増加スピードについて• 保管データは数ペタバ • 保管データ量について • ビッグデータソリューシ • 保管しているデータ量 • 回答差し控え
イトのレベル。スピード感は開示できないが、増加

ョンの引き合いもあり、および増加スピードにとしては年ごとに倍増。

スピードは、昨年から１

データ量はかなりあ

ついては、クラウドサー

年間で 6 倍増えている。

る。テラバイトクラス。

ビス全体では数ペタバ• 回答差し控え

イト、当該ＤＣだけでも数百テラバイトが利用されている。
• 回答差し控え• データ保管期間の制限 • データ保管期間につい • 明 確 に 決 ま っ て な い • 回答差し控え
は現状設けていない。

保管期間て、ファイルサーバのが、大体 5 年間。

• オプションにて、ユーザ • ユーザデ ータ分 は契約 期
指定可能

間中ずっと保管。事業者側

DR オプション契約分はの構成情報について、サー

ユ ー ザ契 約 期間 まで 。

ビス提供中は保管し、世代運用ログの保管期間は管理を実施。

定めていない。VM のス
ナップショットは１世代分。
• NW 越しにバックアップ • データ復旧はリストア
復旧方法• データ復旧はリストア

データ送信し、リストア

127• データ復旧はリストア• 事 業 者 管 理 デ ー タ の • データ復旧はリストア• データ復旧方法について、復旧方法については、

ユーザデータ分はユーザが回答差し控えリストアできるように API、画• ユーザ管理範囲のゲス面を提供。事業者分はリスト

DC・クラウド事業者回答

インタビュー項目
大項目

中項目

小項目

A

B

C

D

E

F

トＶＭのデータのバックG

アにて復旧。

アップとリカバリーはユーザ責任で行う必要があり、そのための手段として専用ソフトを提供• 鳥インフルエンザ等のパ • 特になし

• 衛星携帯電話を各デー • DC 敷地内に衛星アン • 毒性の強弱問わず、パ • 衛星電話を準備してい • 衛星電話を準備している。

ンデミック対策としてのタセンター、各局舎に配テナがあり、衛星電話

ンデミック対応を実施。

訓練も実施

備

等の衛星を利用した通非接触型の体温計な信手段を準備。

どの準備物を整え、被

その他

る。

害 想定 を要員の稼 働率に設定し、稼働率に応じた対策を講じている。

災害発生探知シス
テムの仕組み• 影響を受けた DC はなか • 中央監視装置で監視を • リアルタイム地震情報利 • 地震検知システムにて • 震度計• 電源等各装置のアラー • 地震感知器あり。また、LV4ったため、割愛

実施。オペレータからの用協議会から通知される検知できるようになってムは 24 時間 365 日監視の災害については中央監連絡により検知。

ようになっている。これはいる。

しており、データセンタ

視で検知。

全国の震度計を元にしー設備の異常はそこでており、一般的な地震速検知できる。

報よりも速くて確実。
震災発生
前

災害発生を予防する仕組み（免震構
造等）

東日本大震
災時の対応
状況

• DC の構造について、東 • DC の 構 造に つ い て、 • 当該 DC は免震構造• 当該 DC のラックのある • DC の耐震構造は、ビル • DC の構造については免震

北地方の DC は制震構

DC によって様々だが、フロアについては床面

によって様々。最近は免構造。

造。他センターは免震構

東北地方の DC は耐震

免震、それ以外は全社

震構造が多い。

• 立地について、活断層がな

造、耐震構造あり。

構造。

共通の耐震構造。

• 当該 DC は耐震構造。

いなどの調査を実施。官公• DC 建設時に立地条件

庁１類基準に合わせる形でを設けている。

梁の太さや鉄骨の筋かいを※ハザードマップ上災害用いている。

が少ないところ、活断層がないところなど。
• 検知から確認までで約 • 当該 DC は通信の基地 • ・時系列は現場担当が • 検知から確認までで約 • クラウドサービスは監視 • 検知から確認までで約 30

震災発生時

災害探知してからサービス継続確認に至るまでの対応（時系列含め）

10 分程度。

局も兼ねていたので、確

詳しいが、利用者への※地震発生→NW 監視

認に多少時間がかかっ第一報（影響の有無の • 並 行 し て 対 策 本 部 設

で全断検知→停電→非た。

みを連絡）は 30 分以置（発生から数時間内にできていた。

後）常用電話で自家発電切 • ※地震発生→揺れを検り替えを確認。

知→停電→自家発電に自動切替→サービス継

128

※確認項目

１時間程度。

• 海外 DC を利用して日システムでアラーム監視分程度。

している。クラウドサービ •スではお客様システムに ※時系列影響のあるにアラームは • 停電発生し、自家発電切替確認まで約 6 分無かったと聞いている。

本のお客様のミラーサ • コロケーションサービスと • 中央監視モニターで停電等DC・クラウド事業者回答

インタビュー項目
大項目

中項目

小項目

A

B

C

D

E

F

G

続確認（各ラックへの巡 • 管制塔にてセンター内

イトを立ち上げるなどのして、当該 DC は自家発の目視確認完了：約１５分

回確認含む）。

支援を実施。

電エンジンを監視してい • 各マシン室に巡回しラックの共用設備（NW 等）に異常ないか確認て、震災の影響を確認。

状況の確認：約３０分• 温度、空調管理システ
ムにて異常ないか確認• ラックや大型機器等の床置き機器に影響な
いか巡回して確認• 有人にて対応。自家発 • 有人で対応。自家発電 • 有 人 に て 対 応 。 停 電 • 有 人 に て 対 応 。 停 電 • 有人にて対応。震災時 • 有 人 に て 対 応 。 停 電 後 、

震災発生
後のライフ
ライン途絶
時

発生直後のライフライン断絶時（停電等）の対応（どの程度の期間か、有人/無人など）

電に自動切替、自家発に自動切替、自家発電

後、UPS/自家発電に後、UPS/自家発電には、自家発電燃料の有UPS/ 自 家 発 電 に 自 動 切

電で 21 時間稼働後、商で約 24 時間稼働後、商自動切替、約８時間経自動切替、商用電源

無、給油調達確認など

替、商用電源復旧し、手動用電源が復旧し、手動用電源が復旧 し、手動

過 後 、商 用 電 源 復 旧復旧し、手動戻し実

電話会議 などを 駆使 し戻し実施。

で切り戻し。商用電源復で切り戻し。

し、手動戻し実施。

施。

て現地と対応。

旧前に１回燃料補給を • 燃料補充について、燃• 自家発電は自動切り替実施。

料確保が一般的に困難

え 、巡 回 確 認 はオ ペ レ• また、オペレータ自身のだった状況から、燃料をーションで実施。

住居等も被災し、家族の金沢の燃料供給先から安否確認や周辺の交通補充してもらった。震災

機関がマヒするなどの事の影響で近辺の供給先情もあり、2 日後に福岡よりも金沢が一番速かっからの遠隔運用に切たため。

替。（福岡から遠隔で入退館管理を実施）
震災発生直後の対応策に時間的制約があった場合、その制限を迎えてからシステムはどう対処しましたか（自家発電の燃料切れ
等）
震災発生よ
り一定期間
後

• 震災時は時間的制約（燃料切れ）を迎える前に商用電源が復旧した• 仮に燃料が切れた場合 • 仮に燃料が切れた場合 • 現在はシステム停止後 • 現在はシステムが万が • 万が一、発電機の燃料 • 現在はシステムが万が一停システムが万が一停止してしまった
場合、どう対処していましたが（システ
ムの復旧にかかる
期間）

は、どう対処すればいいは、どう対処すればいい

どうするかよりも停止し一停止する事態までは供給などが間に合わなく止する事態までは想定してか、課題となっている。

か、課題となっている。

ないようにどうするかを想定していない。それなり、電源断の予定がでいない。それよりもいかに燃検討している。自家発

よりもいかに燃料補給た場合は、ユーザ周知と料補給を切らさないようにす

電燃料を切らさずに、を切らさないようにする

ともにサーバシャットダウ

るかを検討している。

燃料補給のシミュレー

かを検討している。

ンして DR へ切り替える

ションを綿密に練って129ことが考えられる。

DC・クラウド事業者回答

インタビュー項目
大項目

中項目

A

小項目

B

C

D

E

F

G

いる。
• 関東地方所在の DC が • 3 回ほど計画停電の対 • １，２回計画停電の対 • 当該 DC は計画停電 • 計画停電対応は、自家 • 計画停電の対象に２回ほど

計画停電等の特殊事例が震災発生か
ら数ヶ月経過して震災による も続いた際、事業者としてどのように特殊事例対応したか。
発生

計画停電対象になり、２象となった DC があった象になったが、自家発による影響は発生して発電へ切り替え、プロセ該当したが、想定プロセス

回 実 施 され た が 、想 定が、想定通り自家発電へ電への切替対応で問いない。

スに沿って確認、商用電に従って対応。

通り、自動で自家発電切の 切 替に よる 対 応 を実

題なくサービス維持し源 に 戻 してか らは燃 料

り替え、計画停電終了後

施

ている。

補給を実施。

手動切り戻しを実施。

• 一部ユーザからは補給のタイミングや残運転時間を教えてほしいという要望あり

結果どのようにサービスは維持されたか• サービス影響なし• 自家発電用燃料が切れ • 自家発電用燃料が切れ • 自家発電用燃料が切 • 震災時に安否リスト確 • 震災時対応や計画停電 • 燃料優先供給契約先の拡た場合の対応方法が課た場合の対応方法が課れた場合の対応方法

認で確認が取れない

時対応は想定よりもスム

題。

題。

が課題。

社員がおり、その場合ーズに対応できており、 • マニュアル類、訓練方法のどうすべきか課題とな

今のところ課題は少ない見直し。全体フローにおけっている。

と思っている。

る優先順位の見直してもっ• 燃料供給先は複数契約 • 自家発電用の燃料の問 • そのために、燃料補給

緊急対応の反省点、今後の課題大しているが、大規模災害

題がある。停電が長引いをどのタイミングで実施

で道路寸断など物理的た場合を考えると、緊急するかのシミュレーショ • ネットワーク断絶時に、と効率いいやり方を模索しに燃料運搬が難しい状

時の燃料供給先を増やンを綿密に練ってい衛星電話設備の設置ている。（震災時は中央監況になった場合にどうすさないといけないと考る。

など、連絡系どうするか

視のアラームが大量に出てるかが課題。

え、複数の業者からの供課題となっている。

判別するのに時間かかっ• 備蓄を増やすという選択給体制を整備した。（備肢もあるが、特にビル型

蓄 量 を増 や す こと は建DC では備蓄量を増や築基準法に抵触することすことができず、課題ともあり、時間がかかるたしている。

め、対策としては現実的• 2 点目に電力会社から

ではない）

た）

優先的に情報を入手できるようなパスがないことが課題としてある。

クラウドサー
ビスにおける
セキュリティ
対応

OS やアプリケーシ
ョンのアップデー
システムに ト、セキュリティ修
関する対策 正パッチやサービ
スパックの適時適用等• ユーザ要望に応じて OS • 事業者管理範囲（ホスト • 事業者管理範囲（ホスト • 事業者管理範囲（ホス • 事業者管理範囲（ホス • 事業者管理範囲（ホスト • 事 業 者 管 理 範 囲 （ ホ ス トのセキュリティ修正パッOS）については、サービ

OS） に つい ては、毎月ト OS）は適時適用してト OS）は、社内セキュリ

OS）は、クリティカル度OS）は、サービス影響与え

チやサービスパック適用

ス影響与えないように、のメンテナンス時間に随いる。

ティ基準に従い、重要が高いパッチは検証のないように、クリティカルなもを実施

クリティカルなもののみ時実施。緊急性の高い※IaaS はホスト OS、

度に応じて修正パッ

上、事業者側で実施。

ののみ事前検証した上でセ• アプリについては、機能事前検証した上でセキュ

パッチは緊急借用をとっ

SaaS の場合はアプリ

チ、サービスパックを適 • ユーザ管理範囲（ゲスト130

キュリティパッチを適用して

DC・クラウド事業者回答

インタビュー項目
大項目

中項目

A

小項目

追加等で随時対応

B

C

D

E

F

G

用している。

OS 以上）はユーザにている。

• ユーザ管理部分（ゲス対策。事業者としては、 • ユーザ管理範囲（ゲスト OS• ユーザ管理範囲（ゲストト OS 以上）はユーザにパッチ情報の連絡のみ。

OS 以 上 ） は ユ ー ザ 判て対策。

リティパッチを適用してて、実施している。

ケーション部分までいる。
以上）はユーザにて対策。ク
リティカルなパッチで、把握断。

している分はユーザに通知※なお、ユーザ管理範

している。

囲のセキュリティ対策を
個別 SI として受託することがある。
システムの可用性・信頼性を確保するための対策※事業者範囲分

ストレージ暗号化
データ管理 の自動実施、また対策
は暗号化機能の提供• サーバ、ストレージ、NW • サーバ、ストレージ、ネッ • サーバ、ストレージ、ネッ • サーバ、ストレージ、ネ • サーバ、ストレージ、ネ • サーバ、ストレージ、ネッ • サーバ、ストレージ、ネットワの冗長化実施。

トワークの冗長化実施。

トワークの冗長化実施。

※物理サーバの冗長化

ットワークの冗長化実ットワークの冗長化実トワークの冗長化実施。

施。

施。

※サーバ、ストレージ冗

はオプションークの冗長化実施。

長化はオプション• データ暗号化サービス • 秘密分散サービスメニュ • 暗号化メニュー未提供• ストレージは自社分、 • セキュリティ上の理由 • データ暗号化サービス • グループ会社に暗号化ソリ（センター内秘密分散／

ユ ーザ分問 わず 全 てから、一度プロビジョニ

は事業者として提供してューション（シークレットシェ

自動で暗号化実施ングされた後のゲストＶいない。

ア（秘密分散））があり、要望

ー提供

センター外秘密分散）を提供

Ｍの内容にアクセスしあれば紹介している。

ないことを「ノータッチ・
ポリシー」として定めている。

ウイルス・マルウェ • オプションとして、IPS・ • メール含め、GW、FW、 • ウィルスチェック等のバ • ウイルス・マルウェア感 • FW、IPS/IDS 等にて • ウィルスチェック、FW、 • デフォルトで FW、オプショ
ア感染への対策、
IDS サービスおよびセキ IPS/IDS によ り対策 済 ンドルタイプをデフォルト 染への対策、不正アク 対応実施している。
IPS/IDS を提供。デフォ ンで IPS/IDS、監査証跡サ
不正アクセスへの対策、ネットワーク
ュリティ監視サービスを み。セキュリティ攻撃に で提供。
セスへの対策、ネットワ • ゲストＶＭに出入りする ルトでの提供は FW の ーバサービスを提供、ユー
障害対策 等提供。

対 す る 監 視 、 検 知 、 解 • IaaS も FW、IPS 機能をーク障害対策について

パケットに不審な挙動み。依頼にもとづいて設ザでウィルスファイル購入条• タグ VLAN によるテナン

析、報告も実施済み

は、対策済み。

がある場合、ユーザ保定作業実施。FW は仮件で、ウィルスパターンファ

セキュリティ攻撃に対す • VM はデフォルトでウィ護のために当該ゲスト

想 FW で提供し、自由イルの配布は事業者側で提る監視、検知、解析、報ルスソフト提供。またマＶＭを停止することが

度は高い。

供可能。

告も実施済みルウェア、不正アクセスある。

• セキュリティインシデント • セキュリティ攻撃に対する監ト間分離を実施。
NW と通信
に関するセ
キュリティ
対策
障害や攻撃に対す
る監視、検知、解析、防御対策等

オプションで提供。また、等については IDS で • セキュリティ攻撃に監

に関する監視、検知、解視、検知、解析については対策済み。これも利用

視、検知、解析、防御

析、対策については、セオプションにて対応。

者にデフォルト提供。

対策も実施済み。

キュリティオプションとし• セキュリティ攻撃に監て提供。社内のセキュリ

視、検知、解析、防御

ティオペレーションセン対策も実施済み。

ターと連携して提供している。デフォルトは防131

DC・クラウド事業者回答

インタビュー項目
大項目

中項目

A

小項目

B

C

D

E

F

G

御。
装置の保守、各種ケーブル（通信、電機器装置
に関する対 源）が傍受又は損傷から保護されて
策
いるか。

保護済み

• ※1 に記載されている対 • 入口は一か所で、入退 • ※1 に記載されている対 • ※1 に記載されている • ※1 に記載されている • ※1 に記載されている対 • ※1 に記載されている対策策を実施。

館管理は実施済み。

策を実施。

入退館申請管理、• その他、手の形（掌形） • 持込・持出物管理につ • 当社のクラウドは通信局
持込・持出物管理、外部からの侵による本人認証を実施。 いて大型機器の管理は 舎内にある特性からエン入への対策、セキ
DC 設備に
ュリティ区域内作できているが、PC やメモ ドユーザが入れないよう関する対策
業におけるルール
リについては一部管 理 になっている。
策定等の環境的な
セキュリティ対策
できていないところがあ（※１）

対策を実施。

対策を実施。

策を実施。

を実施。
• 持込・持出物管理について
は、３D ボディチェックで実施済み。
• 維持管理者がクラウド基盤
へアクセスする際の端末室る。

について、施錠等による入退館管理ができている。

• 運転要員にセキュリティ • 運転要員の採用時確認 • 運転要員にセキュリティ • 運 転要員 は採 用す る • 運転要員は外部へ委 • ISMS の範囲内で運用 • 運転要員は外部へ委託して教育実施。

するのと採用後のセキュ• 運転要員はグループ会
社の人間のみで構成。

際に資質調査を実施託しているが、会社間リティ教育を実施してい • 運転要員は社員。

し、随時教育を実施しの契約事項により信頼

により信頼性担保しており、る。

• アクセスログ、作業ログている。

性担保している。また、また運転要員のセキュリティのチェック実施。

• 要員については、主に運転要員へのセキュリ教育を実施している。

社の人間のみで構成。

本社の人間（一部グル

ティ教育も実施してい• 運転要員の勤務状況・作業• 運用マネージャーがモープ会社）。

る。

内容については、社員であニターで運転要員を監• 管理ルームが３つ（管る運用マネージャーが管視している。

制室、システム監視ル理。

• 物理的に運用ルームを • 運転要員はグループ会
監視運用体制、運転要員の信頼性確認、勤務状況・作
業内容のモニタリ
ング等

教育実施。

分けている。

者に教育を実施。

いるが、会社間の契約事項

ーム、災害対策ルー
DC 運用に関する対策

ム）あるが、全てモニタリングできるようになっている。
-

システムへのアクセス権限や管理者
特権の管理、操作
ログの管理等-• アクセス権限や 管理者 • システムへのアクセス • システムへのアクセス -• システムへのアクセス権限

特権の管理、操作ログの権限や管理者特権の権限や管理者特権のや管理者特権の管理、操作管理を実施。

管理、操作ログの管理

管理、操作ログの管理

ログの管理については、監等も対策済み。管理者については、全て実施

査証跡サーバにて対応。権とオペレータで権限をしている。また、厳しい限も分けている（維持管理

分けている。操作ログ

社内セキュリティ基準

者とオペレータで分けていも管理している。

に則った内部監査

る、オペレータは本番アクセ（Audit）を実施していスできない）

132

DC・クラウド事業者回答

インタビュー項目
大項目

中項目

A

小項目

B

C

D

E

F

G

る。
• ISMS 取得等、情報開 • 質 問 されれ ば 、機 密に • ISMS 取得。また、問い • 情報セキュリティ格付 • ISO27000 台 を 取 得 • ISMS 取得含め第三者 • P マーク取得。また、質問さセキュリティ対策に関する情報開示の有無示実施している。特に関触 れ ない 程度 で でき る

合わせについて、管理け「AAAis」や P マーク

し、第三者からの監査認証を取得。また、個別

れれば、機密に触れない程

係省庁に対して実施済範囲で開示している。

項目レベルでは開示す取得を実施している。また、の問い合わせについて度でできる範囲で開示してみ。

• また、セキュリティレポーる。

ユーザ側監査で必要もできる範囲での開示をいる。

ト（年１、２回）発行し、トに応じて情報開示を実実施。18 号対応も行っ • 今 後 、 FISC

レンド発信や啓発活動施している。

ている。

対 応 、

ISO27000 台、PCIDSS を取得する活動始める予定。

を実施• セキュリティサービス未 • 持込・持出物管理につ • FW・IPS については、ラ • 現 時 点 で は特 に ない • レガシーシステムとの • ハイパーバイザーの脆 • 第三者認証の取得が課題と今後検討、改善すべきと感じた
課題

利用者の振る舞いを抑いて大型機器の管理はインナップ強化により、ユが、強いて言うなら、融合など、今後の環境

弱性対策含めた仮想サえる（踏み台対策等）たできているが、PC やメモーザの選択肢を増やし

DDoS 攻撃等のセキュ変化に応じたセキュリ

ーバ環境向けのセキュリ

めに、利用者によってはリについては一部管 理てもいいのではと、考え

リティアタック発生時

ティ対 策を講 じてい く

ティ対策を今後検討してコスト増になるかもしれな

できていないところがあている。また、秘密分散に、IDS/IPS で防御し必要があると感じていいく。

いが、半分標準化を検るのが課題。これは全面などの暗号化サービスをているが、ユーザへのる。

討している。

管理するようにしている。

今後提供していきたいと報告をもう少しわかりや

考 え て い る 。 IaaS 、すく、きめ細やかにしPaaS についてはデフォていくことが一つ課題

ルトで自動バックアップ

としてある。

感じている。

も検討している。
• 利 用 前 は、廉 価 型 、利 • まずはコスト。我々の競 • 大企業：システム全てを • 柔軟性（利用形態、オ • クラウド専業ではなく、 • コスト削減が求められ、 • 安価かつ高信頼、高付加価

クラウドサー
ビス内容について

顧客からクラウド事業者として何を求められていると感じているか用型というのを求めて来合はユーザのオンプレミ

クラウドに任せるとまではン プ レミ スとの 連 携 な

企業ユースに応じ、ク

一方では、アウトソース

値なクラウドサービスを求めるが、利用後は、継続

ス環境ないし、ユーザ自

いかないが、70％程度

ど）と高信頼性（安定稼

ラウドとオンプレミスのに必要な高信頼性、オられている。

性 、安定性を求めて来社クラウド環境。国内のをクラウドに預け、またク

働）

ポートフォリオが可能でンプレミス並みの高品質る。

IT 市場全体が今度右肩ラウドにつながる NW 部

あることを求められていが求められている。それ※継続性はクラウド事業

上がりではなく横ばいに分も含め当社に任せてると感じている。

ぞれの要望に応えるべ

継続性も含めて。

なっていく中で、ファシリも安心であるように求め

く、パブリッククラウド・プ

ティマネジメント、アセッ

られている。

ライベートクラウドというトを持たないでいいとこ • 中小企業：クラウドだけ

形でメニューを提供し、ろ、ネットワークメニュー

でなく周辺の携帯、NW

対応している。

の柔軟性の３点が求めら部分含め、当社がユーれているし、提供できて

ザ企業の情報システム

いるところが強みとなっ部のようにカバーできるている。

ことを求められている。

クラウドサービスで強みとしてい • ベンダロックインがなく、 • 上記の通り
る部分
ハウジングのイメージで• NW 部分が強み。SI の • 高信頼性（SLA の稼 • オンプレミスとクラウド • 通信キャリアとしてのクラ • 既存のオンプレミスからのマ
方向性よりは、回線、携133

働率 99.99％）の ハ イブ リ ッ ド 利 用がウドを強みとしている。海イグレーションがしやすいよDC・クラウド事業者回答

インタビュー項目
大項目

中項目

A

小項目

B

C

D

E

F

G

可能なところが強み。

外にある DC 基盤、通信

うなソリューション提供であ提供できる。

帯・スマホなどの NW レ • オンデマンド性（アジ• 具体的には、既存のオイヤーを海外含め幅広く

リティと利用時間に応基盤含め、ネットワークとったり、新規システム構築に

ンプレミスからのマイグレ提供できるところが強じた課金体系）

クラウドを融合させたメニ対して当社が PaaS の標準ーションがしやすいようみ。

• セルフサービス（利用ューが強み。たとえば、PF を提供し、アジリティ、全に、多くの選択肢を準備者が Web ブラウザ上

クラウド利用者にはセン体のコスト最適化が図れるしている。そこが SIer ででシステム配備、運

ター側の VPN 回線は無部分が強み。これにより、従ある当社が提供するクラ用、保守まで実施可

料で提供するなど。運用

来の基盤コストの３～４割削

ウドの強み。

能。システム稼働状況についても、回線・クラウ

減が図れる。

も ダッシュ ボー ドで 表

ドのオペレーションを融示）合することで、強みが発• 設計の簡易化（クラウ揮できる。

ド側でテンプレート用意）• ベンダロックインがない。 -• スモールスタート可能、 • 2 点ある。「柔軟に利用 • 当初はコストメリットだっ • コスト面がメリット。ユー • 新規システム構築に対してハウジングのイメージ。ク

拡張性あり、運用負荷軽できる」と「スケールメリ

たが、震災以降はコスザＳＩでシステム構築する

当社が PaaS の標準 PF を

ラウド利用において、新減、仮想化技術を自社ットを生かし、安価に利トだけではなく、災害対よりも NTT コムのクラウド提供し、アジリティ、全体のたに勉強する必要がな

で取り込む際の工数が用できる」の２つ。前者

策としてメリットがでてきサービスを利用したほう

コスト最適化（従来の基盤コ

い。

軽減できる、自社で購入

はシステム稼働のピー

た。

が TCO３割以上は削減

ストの３～４割削減）が図れ

するよりはシステム化がク時、ピーク外に合わ • あとは、アジリティやス可能と考える。

る部分が利用者にとってメリ速い。

せて規模を増減できる

モールスタート可能な • また、グローバル展開の形 態であ った り、スモ面、システム全体で考柔軟性というメリットもあールスタートやオンプ

えたときにオンプレミス

る。

レミスとのハイブリッドなとのハイブリッド運用な

ど、ユーザの要望に応

どの柔軟性がメリットとじ、クラウドを柔軟に利してあると思われる。

クラウドサービス事
業者が考えるクラ
ウド利用のメリット（コスト、運用性、可用性等）

クラウドサー
ビス事業におメリット
けるメリットとリスク用できるのがメリット。

クラウドサービス事
業でメリットを生んだ実際の事例• 大手食品メーカーの基 -• 機械メーカーの事例：ク • プ ラント メー カーの 事 • 印刷業界のお客様事 • 大手小売業の基幹シス -幹システム移行（保守サ

ラウドにフルアウトソース

例：新たなビジネスモ

例：アジリティの部分でテム：高信頼、かつグロ

ポート切れによる）：カット

することで、運用管理とデル立ち上げにクラウメリットがあり、競合他

ーバル対応できる点がオーバーまで 3 か月間しコスト負担の抑制が実現

ドが寄与。稟議通さず

社よりも先に新サービ

大きく評価された。

かない中、一部試行から（紹介資料あり）にクラウド利用でき、事スを展開できた。

始め、逐次全面移行し、業拡大に応じたシステ

か つ TCO36 ％ 削 減 し

ム課金体系で、スモーた。その間、目立ったトラ

ルスタートができたこと

ブルはない。

がメリットであった。

134

ット。

DC・クラウド事業者回答

インタビュー項目
大項目

中項目

A

小項目
-

B

C

D

E

F

G

• 事業ポートフォリオという • 新規領域拡大と同時に • ユ ー ザ へ の 新 た な 付 • クラウドサービスは、グ • 通信キャリアとして、もと • 当社のクラウドサービスは、クラウドサービス事
業にあたって考えられる経営的なメ
リット

ロー バルストラテジー

もとお客様の通信設備

他社 IaaS との価格競争と約 期 間 は長 く 、 回 線 解 • クラウドを起点に派生の１つにも挙げられてのアウトソーシングを請

一線を画し、SI・アウトソー

約抑止にもつながる）

ビジネス（コンサルティいるほど重要な事業だ

け負っており、クラウドサ

シング案件のシステム基盤時代になり事業者側でング等）が生まれていと考えており、経営的ービスもその一環として部分に標準化されたクラウド

ある程度汎用的に設計る。

なメリットは顧客満足度展開できるので、全社シサービスを組み込む方針でしたものをユーザが利用向上と新規顧客開拓

ナジーが生かせる。

進めている。

するような環境になり、業（LOB）の２つと考えて• これにより、これまでのスクラ

務内容を拡大しやすくないる。クラウドによりそッチ型 SI から標準化クラウっている。

れまでリーチしづらいドへ変換することができ、低顧客ともコンタクト取れ

コストで高信頼性・高付加価

るようになった。

値のシステム提供ができる。

観点でメリットあり。

本業へプラス（クラウド契• 当社はずっと NW 事業をやってきたが、クラウド

加価値提供• また、顧客開拓、サービスを利用することによって自前主義からの体質改善ができる。これにより高付加価値分
野に資源注力できる。
• 大規模障害時の利用ユ • ク ラウドは端的に言 うと • 投資リスクがある。ただ、 • 投資リスクあるのと、既 • 現 状の技術動 向を考 • クラウド事業は通信事業 • 当社クラウドは適正規模なーザへの対応。数百社

投資事業なので、投資リ

アマゾン・ウェブ・サービ

存 SI 事業のシュリンク

える と取 り組まない 方の延長上と考えており、ので投資的なリスクや、SI と利用しており、各社担当

スクがある。今回の震災

ス（AWS）のようにコンシもリスクとしてある。既がリスク。当社は 2009

投資リスクやシステムののシュリンクも少ないと考え者への連絡、対応のたで DC は安全という認識ューマー向けクラウドサ

存事業のシュリンクに

年にクラウド推進チー

大規模障害対応リスクはる。

め、工数が膨大になる。

がユーザには広がってービスとハードを共有す

ついては、クラウドの派

ムを立上げ、入念に準

これまでの経験上、ノウいるが、震災の影響でユることで、リソースの最適

生ビジネス で補うこと備をしてきた。SI とのカハウを持っている。

ーザが本社を国外に移化が図れないか検討しを考えている。

ニバリする 部分もある

転する動きがあり、国内ている。

クラウドサービス事
業にあたって考えられる経営的なリスク
リスクが、バランスとってやっだけでやっていくにはリている。

スクがある。当社はそれ• 財務的リスクよりも、顧に追従して海外にクラウ

客満足度低下のリスク

ド拠点 を構築 する計 画が高いと考えている。

でいる。

クラウドサービス事
業にあたって考えられる災害やアクシデント等のリスク• リ ソ ー ス の 準 備 に つ い • 大規模障害時の対応工 • データ消失リスクがある • パブリッククラウドなの -• ただ、免責事項などは契 • クラウドよりもどちらかというとて、常に余裕を持って準数の増加、損害賠償リスと考えており、現在３重で、大規模障害時に影約 書で 制限 はしてい る

データセンターの方が、アク備すべきだが、時としてクあり。クラウド事業規模

でバックアップを実施。

響範囲が大きいのと、が、ユーザのデータ管理

シデント等のリスクが大きい

顧客の需要予測を超えはまだそれほど大きくな

セキュリティアタックのについて、クラウドになると考えており、震災時の対た利用が発生することがいが、IT 保険に入るなど影響も複数ユーザへと管理レイヤーが上がる

応を経験したことにより、さら135DC・クラウド事業者回答

インタビュー項目
大項目

中項目

A

B

あ り、リ ソー スの枯渇のの対応は必要だと考え恐れがある。

ている。

小項目

C

D

E

F

G

波及するリスクがあるとため、リスクがあると個人により良い災害対策を検討考えている。

的に感じている。保険会

している。

社とリスクシェアしていくなど対策を検討していかなければいけないと感じている。
• クラウドの価格について -その他、リスクだと考えている事項--• クラウドサービスはＩＴ -誤 解が生 じや すい 。自サービス調達の新しい前構築と当社のクラウド手段であり、利用技術

サービスを比較する際

は発展段階のため。ベ

に、忘れやすい電力代、ストプラクティスが業界

スペース代等が自前構で確立していない。

-

築に含まれておらず、クラウドサービスが高いという印象を持たれることが多い。
• 大手銀行のセキュリティ・ • EC サイト、ゲームなど直 • 現時点では情報系がメ • ユーザ名は公表できな • コラボレーションクラウ • 製造・流通業のお客様 • オンラインバンキングと損保

クラウドサー
ビス事例

顧客の重要システム事例

キー・サービス、大手金接コンシューマーにサーインで重要システム事例

いが、会計、販売管

ド、デスクトップクラウド

で基幹システムのクラウ

融業の 401k の Web シ

ビス提供するシステムもは少ない

理、ERP 等の重要シは金融等で利用されてド化事例は少しずつ出

ステム、大手食品メーカ

停止すると、規模によっステムを当社のクラウドいる。

てきている。ファーストリ

ーの物流系基幹システては億単位の損害が出

で 運 用 す る 事 例 は出テイリング様など。

ム、県庁が中核の病院とるため、これも重要シスてきている。

• グローバル規模でサー連携 して構築 した救 急

テムに該当すると思ってバ基盤として使いたいと

医療情報システム等、公いる。

いうニーズもある。製造・表できないのも含めると • そういう意味で事例とし

流通は自前で DC を持重要システムの事例はては、ゲー ム 会 社 の 事

っ てない 企 業 も 多 い の多くある。

例が該当する。

で、基幹システムにクラ※活用事例の資料を受 • その他 SaaS 型で金融ウドを利用したいユーザ

事業社向けのサービス

はでてくると考える。一

基盤も提供しており、フ方で、金融は顧客が自ロントサービスからバック

前で DC をもっている点

オフィス含めた領域も範と、そもそものセキュリテ

囲となっている。コア事ィポリシーの関係で、シ業の直結はこれからも進ステムをクラウドで運用とむと見ている。

いう話は少ない。

領。

136

ASP の事例がある。

DC・クラウド事業者回答

インタビュー項目
大項目

中項目

小項目

A

B

C

D

E

F

G

• グループ会社にシステム • 端的に言うと、ユーザの • 一つは当社のサービスと • データを外部に預ける • 金融も利用し始めてい • お客様にとって専用機 • 顧客が重要システムに求め会社があるところは自前

IT カルチャにつきる。

して、瞬断も許されないことへのユーザの心配る。あとは共用度をどう

器でのクラウド利用はハる価値によるが、超高信頼、主義。あとは、食わず嫌 • 他社クラウド事業者の担ようなアプリ向けの設計が障壁となっているのするか。ユーザのセキ

ードル低いが、共有型は超高性能を求められるシス

い・様子見。

当者も話していたが、信をメインとしていない部

では。企業のセキュリュリティレベルに応じた

心理的な面でまだハー

テムは、クラウドは Fit しない→技術開発に関わる部頼されるには、時間がか分がある。

ティポリシー上、情報をメニュー作りが鍵なの

ドルがあるように感じる。

（ビジネス上成り立たない）。

分が当社のクラウドサー

かる。まずは重要でない • 情 報 系 や メー ル等 、短外部へ預けてはいけなではないかと思う。

• 共有型はコスト競争力をまた、金融庁のお墨付きがビスにのらないのは、理情報系システムの運用時間（再起動程度）であいとなっているユーザ高めるために信頼性やないと困るという業態はまだ系の人間が多く、自前主

からはじまり、信頼を得れば通信断が出てもいに対し、安心感を与えカスタマイズ対応など専

クラウド利用には至ってない

義の傾向が強いため。

ながら徐々に重要システ

いようなシステムに利用られていない。

用型に比べてお客様のと考える。

ムの運用を任せてもらう

してもらうようにしている。

ニーズに対応しきれないものではないかと実感し • もう一つはクラウドにする

面はあると考える。共有と責任の所在の問題が型 サ ービ スでも稼 働 率

出て来る。当社に全て任99.99%と謳っているが、せ られ る の かユ ー ザ が

たとえば病院だとそのレ決めきれない。

ベルでは駄目で、ほぼクラウド提供事業者からみて、顧客が重要システムを外部のクラウド上で運用しない理由をている。

100％に近いものをお客様に求められる。そうす
ると、現状は専用型のオ
ン プ レミ スに なる 。ただし、バックアップとしてクラウドを利用するという可能性は現状でも十分あると思う。
• クラウドの特徴であるア • クラウド利用は今までノ • 足もとでユーザ数が増加 • インフラ技術としてクラ • 足下の商談状況からも • 今後クラウドサービスが • 時代の流れとして、所有か

今後のクラウドサービスについてクラウドサービス事業の提供拡大の可能性とその理由

ジリティが認められ、またンコアの情報系がメインしていることもあり、今後ウドがグローバル標準

今後拡大すると感じてますます展開していくこ

ら利用へという流れがあり、

自然災害対策機運も高であったが、我々のユーも拡大すると考えていとなっており、クラウドいる。

とを睨み、当社ではグロ

既存 SI と組み合わせたハイ

まり今後も提供拡大する

ザの中では SAP に代表る。

であればグローバル展

ーバルクラウドビジョンをブリッド型クラウドという利用と見込んでいる。

されるような会計、会社

開しやすく、ユーザの打ち出している。通信キ

形態が今後進むと思われる

管理系の基幹システム

ビジネス展開に連携しャリアの強み生かし、ため、当社のクラウド事業もをクラウドに移行する話

やすく、拡大していくの

OpenFlow 等の新たな拡大していくのではないかとも出てきており、今後もではないかと考える。

ネットワーク仮想化技術考えている。

拡大すると思っている。

を使ってグローバルセン
ター間で仮想 NW を導入。それにより、グローバ
ルな DC 間でリソース連

137

DC・クラウド事業者回答

インタビュー項目
大項目

中項目

A

小項目

B

C

D

E

F

G

携、運用連携を実施していく。

• 今後クラウドサービスが • 今後クラウドサービスが • クラウドを意識させないこ • クラウドサービスがコン • 当社では新しいエンタ • 今後クラウドサービスが • 今後クラウドサービスがより今後クラウドサービスがより深く
社会インフラへ浸透する上での展望および懸念よ り深く社 会イン フラに

よ り深く社 会イン フラにとが今後深く社会インフ

シューマーに直接サーープライズ向けのイン社会インフラとして浸透

深く社会インフラへ浸透す

浸透するには、電力・通浸透するには、クラウド

ラに浸透する上で必要ビス提供できるようにな

フラのコンセプトを打ちす るに は、利用 実 績がるかどうかについて、現状で信等の他の社会インフラ

サービスに国がもう少しだと考える。

ると、もっと浸透してい出している。今後日本必要。

はクラウドに対する安心・安の提供価格を意識する

注力する必要がある（補※NW の先、スマホの先くと思う。スマートシティ

企業は海外進出が促 • 情報系を皮切りに、ここ全の部分が、利用者に浸透必要があると思ってい助金を設けるなど）と思にクラウドがあるようなイなど

進され、その際に上手１，２年で素地がでてきしていない。

る。

っている。

メージを持っている。

• 懸念は、いま無数あるくクラウドを活用できれたが、まだ基幹業務にお • 展望として、クラウドは社会• IT グローバル化の流れ • その際の懸念は大規模

クラウド事業者が今後ば、さらにクラウドサー

いて活用されるレベルでインフラになっていくものとで 、製 造 業 等 、海 外 依

トラブル時。大きい流れ淘汰されていくこと。当

ビスが浸透するのでははない。

考えているので、利用者が存度が高い企業がどんではクラウド利用になっ社が淘汰されないようないかと思っている。

• ユーザ間で情報交換が早くクラウドのようなサービス

どん AWS を利用するよていると思うが、クラウドに強みを発揮していか • 近 頃 イン ター ネ ット ベ

進み、もっと利用されて利用に慣れていく必要があうになると、AWS 内の情のトラブルが多発するとないといけない。

ースでの安心・安全のいけば、クラウドはますまる。

報が米国に渡るリスクを自社構築に流れが戻る

バランスが崩れており、す浸透していくのではな

懸念している。

と思われるため。

それがクラウドに波及いか。基幹系はこれから• 国策としてフォローすべすることを懸念していだと感じている。

き。電気代にしても海外る。同じリソース共用サの方が安価で、クラウドービスである し。利 便

事業者も海外に拠点を性とルールのバランス

作らざるを得なくなり、国が重要（IPS/IDS のト

内空洞化が一層進むこレードオフなど）。今後とを懸念している。

のクラウドサービスは、
価格競争よりも総合力
なのではないかと考え
ている。

138

4.

クラウドの機能停止が社会に与える影響の定性的評価

4.1. 実態調査のまとめ
本章の実態調査で明らかになったことを図表 92 に要約した。
まず、クラウドは個人・企業・社会のそれぞれにとって、重要なサービスの基盤を担いつつあるということである。そのことは裏返せばクラウドサービスが停止した場合の影響は、従来考えられていたよりも大きくなる可能性がある。
その一方で、東日本大震災の災害対応に際してのクラウド利活用の実態やデータセン
ターの緊急対応の状況から判断すると、大規模災害等における情報システムの可用性の確保や代替システム・機能の提供、復旧・復興に向けたシステム再構築に対して、クラウドが持つ特性が十分に役立つことが明らかとなった。情報セキュリティやデータ保存などの点からもクラウドが有利であったことも確認されている。
図表 93 実態調査から明らかになったこと
社会への浸透状況

東日本大震災におけるクラウド利活用

東日本大震災における DCの緊急対応

 E-mailやSNSなど、個人のコミュニケーション
手段として使われているサービスの基盤はクラウドサービスや技術が多く用いられている
 日常生活を支えるようになったネッ トスーパー
やネット通販でも、インターネッ トモールなどでクラウドが用いられている
 企業の生産販売活動を支える業務システムにおいても DCへのハウジングを始め、コストの優位性から PaaSやSaaSの利用が増えてきて いる 重要インフラにおいても、地方行政、地方金融機関や上下水道において共同利用やクラウドサービスの利用が増えている

 従前のシステムが利用不可能になったための代替システムとして、また被災者 検索・救援物資供給等緊急対応の ために、クラウドサービス を用いた様々な情報システムが提供され、活用された
 地域によってはデータの消失などの問題も発生したが、クラウド上のデータは無事であった
 業務の復旧 、再開に当たってクラウド上に残されたデータが活用された 東日本大震災でクラウドサービスを提供しているDCは基本的には大きな被害を 受けなかった
 ユーザー環境が被災したり、停電によって通信回線の遮断やユーザー環境の利用ができない例が見られた 東日本大震災でクラウドサービスを提供しているDCは基本的には大きな被害を受けなかった 長時間停電や計画停電、帰宅（出勤）困難など
既存の BCPでは想定していなかった事態が発
生 自家発電装置の燃料確保に苦心

従来活用されている分野だけではなく、企業や社会の重要な分野でクラウド利用が進む
サービス停止の影響は想像以上に大きい可能性が確認された

大規模災害時において、クラウドがデータの可用性の確保や緊急対応機能の迅速な提供に有効である
ことが明らかになった

クラウドサービスを支える DCは大規模災害においても強靱であることが確認されたが、二次的サプ
ライや人的資源の確保に課題が残された（ＤＣ：データセンター）

以下では、クラウドの社会への浸透、東日本大震災におけるクラウド利活用、東日本大
震災におけるデータセンターの緊急対応の 3 つの視点から、実態調査で明らかになったことを述べる。
4.1.1. クラウドの社会への浸透
クラウドや ASP/SaaS、共同利用など、情報システムの構築・運用に当たって外部リソー
ス提供サービスを利用することは、データセンターのスペースを借用して機器類をハウジン
グすることを除くとあまり進んではいない。アンケート調査の結果によれば、消費者向け EC
では Web サイトにおける商品陳列などでも 25～30%であり、CRM 等の重要業務では 10～20%にとどまっている。また企業間取引においては、いずれの業務でもデータセンター
139

利用は 40%あるが、ハードウェアから上位の OS、プラットフォーム、アプリケーションのレイ
ヤーになると 10～20%程度にとどまっているのが現状である。
ただし、重要インフラに関する事例調査で見たように、業界や業務によっては、外部リソース提供サービスの利用が大きなシェアを占めるものがある。具体的には以下のようなものである。
• 信用金庫の勘定系システムの共同化（90%）• 地方銀行の勘定系システムの共同化（30%）• 航空会社の業務システムのクラウドサービス利用（約 85 社）• 上下水道遠隔監視クラウドサービス（293 自治体、6,000 施設に導入）
4.1.2. 東日本大震災におけるクラウド利活用
被災地を中心に、被災で利用が不可能になった既存の業務システムの代替や被災者支援・救援などを目的として、クラウドを用いた情報システムのサービスが発災直後から様々な主体によって提供された。このことにより、緊急時における迅速なシステムの立ち上げにはクラウドの活用が有効であることが改めて明らかとなった。
また、地域によっては既存システムに格納されていたデータが消失した例も報告されているが、一部のデータはクラウド上に保管されており、データの復旧に役立ったとされている。
一方、震災による主要なデータセンターへの被害はほとんど報告されておらず、機能を全うしたとされている。このことから、クラウドがサービスの可用性の確保に役立つことが確認された。ただし、停電による通信回線の遮断やユーザ環境の被災によって、サービスが利用できないケースが存在し、サービスの供給から消費までの全体としての継続性の確保が課題と言える。
4.1.3. 東日本大震災におけるデータセンターの緊急対応
前述したように、今回の震災においてはデータセンターに大きな被害はなかったとされる。ただし、被災による長時間の停電や関東における計画停電などの影響で、自家発電装置およびその燃料に対する課題がクローズアップされた。具体的には、自家発電装置の運転耐用時間の問題や緊急時における燃料の確保の困難さが指摘されている。
また、広範囲に及ぶ交通混乱によって保守運用要員の確保が困難になった事例もあり、今後の課題として認識されるようになった。

4.2. クラウド停止の影響
アンケート調査によれば、クラウドを利用している企業の企業間取引において、クラウドが停止した場合の影響は、調達の 40～45%、販売の 30～40%の取引（件数、金額、取引先数）に及ぶと回答されており、非常に大きいと考えられる。

140このように、前述したクラウド利用のシェアが非常に大きい業務や業界では深刻な影響を受ける恐れがある。特に、金融機関、消費者向け EC 等ではクラウドに依存するサービスが停止することによって、決済、現金の引き出し、日常必需品の買い物ができなくなる恐れがあり、国民の日常生活に非常に大きな影響を及ぼすことが想定される。
また、企業間の取引システムや情報共有システムなどにおいては、1 社の生産管理シス
テムが停止して生産が止まるだけではなく、当該企業の下流のサプライチェーン全体に影響が及ぶ可能性も否定できない。東日本大震災では、システムが原因ではないものの、被災地の部品工場の生産が停止したことで、世界中の自動車生産に影響を与えた例が報告されており、情報システムの停止によっても同様のことが発生する恐れがある。

4.3. 最近発生したクラウドの大規模障害とそこから抽出されるセキュリティ課題
本調査の期間中に、災害以外の原因でクラウドサービスが停止する事例が複数発生している。ここではそれらの事例から社会システムとしてのクラウドに求められる課題を抽出する。
まず、構築したクラウドサービスのシステムが期待した性能を発揮できなかった結果、サービス直後から障害が多発した事例を取り上げる。この事例では、ストレージおよびストレージネットワークが原因でユーザデータの読み書きに障害が断続的に発生したうえ、復帰
手順に人為的ミスが生じるなどが重なったため、ユーザデータを消去してしまい、復旧が不可能になるなどの問題が発生した。このストレージが正常に動作しない障害は発生以来半年以上にわたって断続的に発生し、根本的な解決までに非常に長い時間を要している。
第 2 の事例は、プログラム更新時のバグによってサーバ内の全データを消去してしまい、
6,000 近くのユーザが保有する Web サイト、電子メール、グループウェア等のデータが復旧不可能になった事象である。また、バックアップを同一サーバ内の別ディスクに取っていたため、プログラムのバグによるデータ消去を防げず、バックアップの意味をなさなかった。
このサービスは低価格で高いサービスレベルを売り物にしていたため、中小企業等の利用が多かった。これらの中小企業は IT リテラシーも相対的に低く、ユーザ側でのバックアップ
がない場合も多かったという。そのためクラウドの障害によってデータがすべて失われてしまい、業務に大きな支障が出ているとの報告がある。これら 2 つの事例は、技術的に未熟な事業者のサービスによって、ユーザが期待する性能が提供できないばかりか、障害を引き起こし、ユーザの業務を停止もしくは大きく阻害する可能性があることを示している。
事例から抽出される課題は、「そのクラウドサービスの品質が優良なものであるかどうかをユーザが判断できる材料をどのように提供するのか」あるいは「サービスの品質を社会としてどのように確保していくのか」ということである。すなわち、最初の事例では、サービスを支えるインフラの質が不十分でサービスが断続的に停止してしており、これを外部から判141

断することは難しく、また 2 番目の例では SLA では「100%稼働、外部バックアップ」を謳っていたものの、実態としてはそうではなく、障害時に対応が不可能になってしまっているた
め、SLA での判断は難しい。このような事例が引き続き起こるような状況が続けば、品質基準の策定と外部監査等の品質担保と表示のための仕組み作りが必要になってくる可能性がある。
第 3 の事例は、データセンターで電源トラブルによる障害が発生したため、ホスティング
サービスが停止し、その上で提供されていた金融機関やクラウドサービス等のサービスが停止したものである。サービス停止の際、データセンター事業者はユーザ企業との責任分界点を考慮して、ユーザに対して停止を通知したものの、一般に向けてのアナウンスは行われなかった。ユーザであるサービス事業者ごとに、障害に関する説明内容やサービスの再開時期が異なるという問題があった模様である。しかし、今後緊急事態に近いレベルの障害が発生した場合の情報開示がそれだけでよいのかについては、検討の余地がありそうである。この事例から抽出される課題は、今後クラウド利用が拡大する中で影響範囲の広い大規模障害が発生した際の、時宜を得た情報開示の在り方とその方法の確立と考えられる。
以上のように、最近発生した障害事象から新たな課題が提起された。その課題とは、今後クラウドサービスは電力、水道、電話等と同等の社会基盤サービス（ユーティリティ）となっていくにあたって、「品質の保証はどのように行うべきか」「それはどのように担保されるべきか」「異常時におけるクラウド事業者の情報開示、すなわちリスクコミュニケーションはどのようにあるべきか」というものである。すなわちクラウドが社会に浸透して行くにつれて、クラウド事業者の供給者責任および、社会システムとしての担保の在り方はどのようにあるべきかを考えていく必要がある。
他の社会基盤サービス、たとえば電力事業などではある程度の独占性を事業者に認めた上で、品質管理責任を事業者に負わせている。また、運送事業では事業者の適格性を審査した上で免許を与え、必要に応じて監査を行う制度をとることによって品質の保証を行っている。さらに水道事業では国民の生命に直接関わることから、原則として市町村が経営すること 75とされている。
同時に、各々の事業におけるサービス等の提供については、標準的な約款が用意され、供給側の供給責任の範囲、賠償等の限度や免責事項も規定されている。このことにより、
生活必需サービスが異常な高コストとならないような安全弁も設けられている。クラウドサー
ビス自体が生活必需の要素を持つケースはそれほど多くないとも考えられるが、それを利用する生活必需サービスは今後増加すると考えられ、そのコストとの兼ね合いで、この点も検討課題となろう。
このような事例も参考にしながら、クラウド事業の成長と両立する品質管理や供給者責任の在り方を検討することが求められる。
75

水道法第六条 2

142II. クラウドが備えるべきレジリエンシ及びディペンダビリティを実現するためにクラウド事業者ならびに社会システムが満たすべき要件の調査
1.

問題認識
これまで述べてきたように、クラウドが社会に相当程度浸透していること、また東日本大
震災においてもクラウドが果たした役割・機能が大きかったことが明らかになった。本章では、社会において少なからず重要な位置を占め、大規模災害時にも役立つクラウドの、大規模災害やセキュリティ障害に際してのサービス継続性を、どのように担保するかについて検討する。このために必要な要件や行うべき対策・取り組みは、一義的にサービスを提供しているクラウド事業者と利用者であるユーザ、さらには両者をつなぐ通信環境を提供している通信事業者が、その各々の責任において果たすことが求められるものと考えられる
が、クラウドに電力等を供給しているライフライン事業者等に求められるものも考えられる。
さらに、個々の事業者では取り組みが困難なものについては、行政の施策や社会全体の仕組みや制度として整備すべきものもあると考えられる。
調査の中では、東日本大震災級の災害状況を想定し、以下の要素について必要と考えられる対策ならびに要件を検討した。
・ 平常時におけるライフラインの冗長性確保
・ 緊急･災害時における代替ライフラインの確保
・ 緊急･災害時における代替ライフライン確保のための二次的サプライの要件
・ 通信回線に関する平常時ならびに緊急時の要件
・ データセンターの運転ならびに保安のための要員に関する要件
・ 意図を持って行われるサイバー攻撃に対する防衛または回避

143

2.

現状の取り組みと課題
1.で述べた問題意識をもとにクラウドの事業継続の観点から、現状の取り組みの状況と課題について整理する。

2.1. 対応の前提となる想定リスクの考え方を見直す必要性
東日本大震災では、従来は十分に想定していなかったリスクが数多く顕在化した。地震動や津波の直接の影響による施設の破壊・流失だけではなく、地盤液状化による施設の被害や長時間にわたる停電による影響も大きかった。その結果、通信回線が長時間にわたって遮断されたり、長時間にわたる停電に対応するための非常用電源用燃料の供給が十分に行き届かなかったりといった事態が生起した。また、南海トラフ巨大地震と首都直下地震の同時発生の可能性が排除できない 76など、従来の想定を大きく越えたリスクの存在も具体的なものとなってきている。この教訓を踏まえて、従前の前提を疑い、リスクの洗い出しを再検討し、準備を充実させることは当然重要である。
しかしながら、そのようなアプローチのみでは、リスクや対策は言わば無限に広がり、大変複雑なものとなる。準備や対策に要するコストや手間も大きなものとなる。クラウド利用は
IT の開発・運営のコストを縮減することが大きな目的となっていることを踏まえると、現実的には、準備・対応できることには限りがあることも確かである。
このような一定の制約条件がある中では、リスクの洗い出しと対策の立案においても、対応の考え方を変革していくことが重要ではないかとの有識者の指摘があった。
クラウドの利用目的や利用対象者は多様であり、それらに応じて平時におけるセキュリ
ティ対策や災害時等の対策は異なる点に留意することや、リスク要因を網羅的に洗い出すのではなく様々な要因により共通して生じうる事象（たとえば、電源喪失）を想定した上で、そうした中間的な事象から BCP を検討すべきとの指摘がある。これらの指摘からの示唆は、想定外の状況があり得ることを想定して事業継続性を議論すべきであるということである。
また、実際に災害が起こった際には、被災状況や活用可能なリソースが刻々と変化する
ため、対応すべきリスクが絶えず変化する。このような状況においては、前もって定められた手順での対応だけでは限界があり、動的なリスクへの対応を図ることが重要になる。

762012 年 6 月現在、内閣府では、東海、東南海、南海等の連動型巨大地震災害に対する地震被害想定の見直し等を行っている。

144

2.2. データ・システムのバックアップの確保に関する現状
実態調査その 3 の調査対象の大手クラウド事業者については、図表 90 に示すように、
デフォルト、オプションを合わせるとデータのバックアップ範囲は広く、別筐体のストレージや外部媒体、遠隔地バックアップも実施することが可能となっている。

図表 94 大手クラウド事業者のバックアップ対応（再掲）事業者A
B
ホスト OS レイ ホスト OS レイ
ヤーのシステ ヤーのシステ
ムバックアッ ムバックアップ、各種運用 プ、各種運用
ログが対象
ログが対象

C
D
E
F
G
ホスト OS レイ
・データの保管 ホスト OS レイ 当社管理部分 ヤーの各種運対象は、ファイ ヤーのシステ 並びにユーザ
作成分も含め用ログが対象
ルサーバのムバックアッDR オプション プ、各種運用 た VM のイメー
契約分
ログ、課金デ ジをバックアッ
データ保管対プしている。
各種運用に必 ータが対象
象（事業者範要なログ（監視 ゲスト OS 以上
囲）
ログ、アクセス のレイヤーが※デフォルト
対象でユーザログ）
仮想サーバの にてバックアッスナップショッ プト（IaaS,PaaS
系以外）。
データ保管対 ゲスト OS 以上 ゲスト OS 以上 代行取得しな 代行取得しな ユーザ管理の ゲスト OS 以上 ゲスト OS 以上のレイヤーの のレイヤーの象（ユーザ管 のレイヤーの のレイヤーの い
い
DB
各データ
各データ
理範囲の代 各データ
各データ
行保管）
※オプション
ファイルサー 別筺体への
ユーザバック ユーザ指定で データバックア
北海道データ 遠隔地バック
バの DR オプシ DisktoDisk に アップ分につ Disk2Disk、テ ップについて、センターに遠 アップ
ョン契約分に よるバックアッ いては、別筺 ープ、遠隔地 同サイト内に隔地バックアッ
ついては DR サ プ。
体に Disk toプ
バックアップが 保管。
イトへバックア
今後遠隔地バDisk でバックア 可能。
ップ
ップ（遠隔地バックアップ予定
保管データバ
自社管理分にックアップ）。
ックアップの
その他データ
ついては、外有無については、
部媒体へバッ
同一センター
クアップしてい内の裏サーバる。
へ Disk to Disk
でバックアップ。
回答差し控え 保管データは 保管データ量 ビッグデータソ 保管している 回答差し控え 回答差し控え
数ペタバイトの については開 リューションの データ量およレベル。スピー 示できないが、 引き合いもあ び増加スピー
ド感としては年 増加スピード り、データ量は ドについては、ごとに倍増。 は、昨年から１ かなりある。テ クラウドサービ
保管データ量年間で 6 倍増 ラバイトクラス全体では数及び増加スピえている。
ス。
ペタバイト、当ードについて
該データセンターだけでも数百テラバイトが利用されている。
回答差し控え データ保管期 データ保管期 明確に決まっ 回答差し控え オプションに
ユーザデータ間の制限は現 間について、フ てないが、大て、ユーザ指 分は契約期間状設けていな ァイルサーバ 体 5 年間。
定可能
中ずっと保管。
保管期間い。
の DR オプショ
事業者側の構ン契約分はユ成情報についーザ契約期間て、サービス提

145

事業者

A

B

NW 越しにバッ データ復旧はクアップデータ リストア
送信し、リストアC
D
まで。運用ログの保管期間は
定めていな
い。VM のスナ
ップショットは１
世代分。
データ復旧は データ復旧は
リストア
リストア

復旧方法

E

F

事業者管理デ データ復旧はータの復旧方 リストア
法について
は、回答差し控え
ユーザ管理範囲のゲストＶＭのデータのバックアップとリカバリーはユーザ責任で行う必要があり、
そのための手段として専用ソ
フトを提供

G
供中は保管
し、世代管理を実施。

データ復旧方法について、
ユーザデータ分はユーザがリストアできる
ように API、画面を提供。事業者分はリストアにて復旧。

出所）実態調査（その 3）によるインタビュー結果から NRI 作成

しかしながら、中小、新規事業者の中には大規模障害事例で見られたように、十分なバックアップ体制を取っていない可能性は否定できず、適切な情報開示が求められる。情報開示に関しては、総務省と NPO 法人 ASP・SaaS・クラウドコンソーシアム（ASPIC）が2011 年 12 月に「データセンターの安全・信頼性に係る情報開示指針（第 2 版）」および「IaaS・PaaS の安全・信頼性に係る情報開示指針」を策定している。
「データセンターの安全・信頼性にかかる情報開示指針（第 2 版）」の 118 項、「IaaS・
PaaS の安全・信頼性に係る情報開示指針」の 41 項で「バックアップ・リストアサービス：バックアップ、障害時のリストアサービスの内容」を定義しており、今後バックアップに関する情報の開示が期待される。
また、一般財団法人マルチメディア振興センターが「ASP・SaaS 安全・信頼性に係る情報開示指針（第 1 版）」（2007 年 11 月総務省）に基づく認定制度を行っており、同センターのサイトで、認定を受けたサービスの情報開示を行っている。ASPIC へのインタビュー
では、上記の「データセンターの安全・信頼性に係る情報開示指針（第２版）」および「IaaS・
PaaS の安全・信頼性に係る情報開示指針」による情報開示適合認定も検討中とのことであり、外部認証による品質保証の強化も期待される。

146

2.3. BCP（事業継続計画）による準備の現状
前項と同様、インタビューを行ったデータセンター事業者については、各社とも緊急対
応マニュアルを用意しており、一定程度の対応は行われていた。具体的には、災害対応フ
ロー、緊急対応マニュアル、安否確認システム、初期の損害チェックリストなどが含まれている。
図表 95 大手データセンター事業者の BCP 対応状況（再掲）
A
B
C
D
E
F
G
震災前にマニ 震災前に以 震災前に以 震災前にマニ 震災前にマニ 震災前にマニ 震災前に以ュアル準備済 下準備済み 下準備済み ュアル準備済 ュアル準備済 ュアル準備済 下準備済み。
み。
み。
み。
み
※大規模障 ※安否確認※災害対応フ ※全体フロ
害時のノウハ システム、地ロー、緊急対 ー、安否確認
ウは溜まって 震発生時のシステム、初応マニュア
おり、それを 確認リスト。
ル、安否確認 期損害チェッ
元にしたマニ
システムなど クリスト。
ュアルがある。
出所）実態調査（その 3）によるインタビュー結果から NRI 作成

また、前項と同様に総務省および ASPIC が策定した 2 種類の情報開示指針において、「事業継続に関する規程等の整備」として「事業継続に関する基本方針、計画、マニュア
ル等の文書類の有無と、有りの場合は文書類の名称」（28 項）および「上記の文書類の経営陣による承認の有無」（29 項）が定義されており、これに沿った情報開示が期待される。

2.4. 平常時からのファシリティ面の対策
日本データセンター協会（JDCC）では、図表 95 に示すように「JDCC データセンター
ファシリティスタンダード」を制定し、データセンターの重要度（ティア）別に、建物、セキュリ
ティ、電気設備、空調設備、通信設備ならびに設備運用について満たすべき基準を定めている。 法令で定められた建築基準においては、データセンターに特別の厳格な基準や規制が加えられているわけではないものの、各事業者において、上記のファシリティスタ
ンダードに基づいて、堅牢性を確保している。前述したように、東日本大震災ではデータセンターは、ほとんど無傷で、事業継続できたことが確認されており、ファシリティスタンダ
ードが有効であったことが改めて確認された。
しかしながら、いくつかの課題が認識されている。まず、件数は少ないものの、サーバ室の天井が剥がれ落ちたケースと免震構造のサーバーキャビネットが倒れたケースが見られた。また、データセンターには被害が及ばなかったものの、津波による浸水・流失や埋め立て地等における地盤液状化によって建築に大きな被害がもたらされた。従来のデーターセ
ンターファシリティスタンダードではこれらの点については十分考慮しておらず、今後対策を強化すべき課題として認識された。

147

図表 96JDCC ファシリティスタンダード（基準項目一覧）

出所）JDCC データセンターファシリティスタンダード（概要）2.5. 平常時におけるライフラインの冗長性確保
東日本大震災では仙台の変電所が水没、停止したため、電力の復旧に時間を要した。
データセンターのファシリティ面よりは、ライフラインに対する準備がボトルネックとなる可能性が改めて認識されている。
慶応義塾大学の大林厚臣教授によると、情報システムは BCP による平常時の準備の効
果が現れやすい領域である。BCP では代替性がポイントとなるが、代替機やデータバック
アップなど、情報システムは代替性を前もって確保しやすい領域であるためである。
ただし、現状ではクラウドサービスすべてにわたって代替性や冗長性が確保されているとは限らない。たとえば今回の震災においてもクラウドを運用するデータセンターとユーザ間の通信回線に冗長性がなく、サービスは提供されていたがユーザが利用できない例が見られた。しかし、冗長性の確保にはコストがかかるため、東京電機大学の佐々木良一教
授へのインタビューで指摘されたように、ユーザのクラウド利用の動機で最も強いものは情148

報システムのコスト抑制であり、コストと冗長性の確保をいかに両立させるかが課題である。

2.6. 緊急･災害時における代替ライフラインの確保
非常用の自家発電機は累積運転時間が一定の時間に達すると耐用時間を越えるため、オーバーホールを行う必要がある。JDCC によると、長時間に及ぶ電力供給の停止は、以前はデータセンターの多くは全く想定していなかったが、今後は想定すべきではないか、とのことである。
また、緊急・災害時には通信回線の確保に加えて、その容量も問題となる可能性がある。
陸前高田市では Web サーバを市外のデータセンターで運用していたため、Web ページ
自体は稼働を続けていたものの、サーバまでの通信回線が断絶し、衛星電話を用いたダイヤルアップで情報更新を行った。このため、大容量のコンテンツを更新することはできなかったという。
通信回線の多重化と容量の確保や非常用電源の強化など、緊急・災害時における代替
ライフラインの確保に向けた対策については、クラウド事業者、通信事業者等が一義的に行うべきことである。また、これらの対策を取っていることをユーザに適切に開示することが求められる。

2.7. 緊急･災害時における代替ライフライン確保のための二次的サプライの要件
東日本大震災の教訓のひとつは、データセンターのファシリティとしての堅牢さだけでは対策は十分ではなく、非常用電源を動かすための燃料が重要であるという点である。
JDCC によると、被災地のデータセンターは燃料の備蓄が一定程度あり、補給でなんとか稼働し続けたが、一部銀行の電算センターでは 3 時間程度の燃料備蓄しかなく、停止した。
これは、リスクの想定として、電力の供給が停止する可能性があることを見越して準備していたかどうかによる差であった可能性がある。
また、燃料の優先供給契約があまり機能しなかったことも判明した。石油連盟によると、タンクローリーの不足、交通遮断、被災地への優先的供給などが要因であった。また、燃料供給者の視点からは、各所から要望が殺到する中で優先順位を付けて供給することは民間では無理がある。先の震災では内閣府防災担当からの要請順位に基づいて供給を行ったという経緯であった。ただし、供給先の輸送条件（タンク容量・形式、道路条件等）がわからないまま行ったために空振りも多数発生したとのことであり、事前の情報共有・把握が重要であると考えられ、石油業界においても取り組み 77が始められつつある。

2.8. データセンターの運転ならびに保安のための要員に関する要件
佐々木教授、大林教授、JDCC、各データセンター事業者へのヒアリングによると、データセンターの建物がいくら強固であっても、システムを動かす要員が緊急・災害時に集まる
77

石油連盟「災害時の重要施設に係る情報共有に関する覚書の締結について」(2012 年 3 月 29 日)
http://www.paj.gr.jp/paj_info/press/2012/03/29-000565.html（2012 年 6 月現在）

149

ことができるかという点は大きな課題である。今般の震災では金曜の昼間であったため深
刻な問題とならなかったものの、夜間や休日であった場合の要員参集の困難が懸念される。また、交通寸断により要員確保が難しくなるケースも想定される。
3.11 のときは大きな問題とならなかったが、大規模な自然災害の後にインフルエンザな
どの感染症が広がるリスクもある。大林教授によると、東日本大震災では医療や福祉関係者が相当感染症の予防に気を付けていたとのことである。仮に感染症が広がった場合、要員確保は一層困難となる。
このようなリスクを踏まえると、緊急・災害時においては平時よりも大幅に少ない要員でクラウドの継続、または早期復旧に向けた対策を講じなければならない事態が想定される。
しかしながら、企業等のBCPでは要員参集に関する前提や想定に課題が残る事例も見られる 78。少ない要員での事業継続、ないし要員参集を前提としない事業継続の方法等を準備することが課題である。
東日本大震災においても、あるクラウド事業者が東北地方のデータセンターにおいて、要員の住居の被災、家族の安否確認に加えて、交通機関の麻痺などが起こり、要員の確保が困難となったため、発災後数日以内に西日本のデータセンターの要員による遠隔運用に切り替えている。このように、遠隔運用を行えるような設備、要員の訓練等の備えが求められよう。

2.9. 緊急・災害時におけるセキュリティ対策、ならびに意図を持って行われるサイバ
ー攻撃に対する防衛または回避
緊急・災害時には厳重なセキュリティチェックが難しくなるケースがある。たとえば、自家発電装置への燃料補給のためにデータセンターへの入館を比較的容易に認めるといったケースも想定される。この際に、緊急対応のためのデータセンターへのアクセシビリティの確保とセキュリティの確保を、どのように両立させるのかを、クラウド事業者は前もって考えておかねばならない。
一方、災害発生時には、平常時のセキュリティレベルを下げる必要のあるデータも存在する。たとえば、医療における患者データの共有がクラウドで円滑に進むと、人命救助等の点で効果的である。これについては、データを保有するユーザが決定してクラウド事業者に指示することで可能になると考えられるが、緊急時に個別判断を集めること、複数患者の合意形成を図ることは現実的でない。個人情報や機微な情報に関してセキュリティレ
ベルを下げることについて、社会的なコンセンサスの形成が必要になることを想定しておく必要がある。また、緊急事態が収束して平常状態に復するときには、緊急対応で拡大した
開示範囲に残存するデータの回収や抹消も行わなければならない。緊急対応で拡散したデータのトレーサビリティは低いことも想定され、一定条件下での一斉消去等、その方策や判断基準も予め整えられていることが必要になる。またそのような緊急対応とその収束に78

浅野憲周「事業継続計画（BCP）再考－大震災から企業は何を学ぶべきか」知的資産創造 2012 年 2 月号

150

際しての、開示･回収･消去の手続きや判断結果に関する、セキュリティ監査や監視を誰がどのような手順で行うのかについてもユーザ、クラウド事業者および社会全体で合意を形成する必要がある。
クラウドにおいてもサイバー攻撃等に備えた対策としての基本的な事項は、アクセス制
限やデータの暗号化など通常の情報システムの場合と同様であるとの有識者の指摘がある。システム運用の視点で見た場合、複数のシステムを集約的に運用するクラウドでは、個別分散的にシステムを運用する場合に比べて高度な情報セキュリティ対策を集約的に導入できるため、セキュリティレベルが高くなるとも考えられる。しかしながら、セキュリティが破られた場合の影響範囲が大きくなるため、クラウド事業者の情報セキュリティ確保への不断の努力が求められる。と同時に、ユーザの以下のような懸念への対応も必要となる。
第 1 に、データ/システムをクラウドに置いた場合、自社のシステム内で閉じている場合よりも攻撃の対象となりえる可能性が増えるということを意味する。
第 2 に、クラウド事業者にデータやシステムの運用を任せるため、ユーザの IT リテラシ
ー、とりわけセキュリティに対するものが低下する可能性が高い。また、クラウド化されると、ユーザにとってはその先では何がどのように行われているか見えないため、セキュリティ管理の経験や学びの機会が減る。したがって、ユーザに対するセキュリティ教育は重要な課
題のひとつである。
さらに、大規模災害時の混乱に乗じたサイバー攻撃等も視野に入れる必要がある。災害対応でシステムが脆弱になり、要員が手薄になったところで攻撃された場合の対応など、複合的なリスクへの対応を検討しておく必要があると考えられる。

2.10. 中小事業者、ベンチャー等の提供するクラウドサービスのリスクへの対応
最近のクラウドの大規模障害事例では、中堅企業が提供するサービスに重大なトラブルが起き、ユーザに甚大な影響を及ぼしたことが報告されている。今後もクラウドサービスに新規に参入してくる事業者が増えるものと思われ、その中には中小企業やベンチャーなど
企業体力が必ずしも強くない事業者も増えてくると考えられる。新規参入は市場や経済の活性化のために歓迎すべき事象ではあるが、インフラ的性格を持つクラウドにおける品質の確保との両立が課題となる可能性も否定できない。今後は、これらの企業の技術面での未熟さなどのリスクばかりではなく、財務面でのリスクも考慮する必要が出てくる。
たとえば、このようなクラウド事業者が大規模な障害を起こして損害賠償に応じなければならないケースや、経営が行き詰まって倒産するケースを想定し、責任の所在を明確にしておく必要がある。大林教授、佐々木教授によると、契約（SLA 等）でどれだけリスクに備えた対策を盛り込めるかがポイントとなる。
これに備えた保険等の経済的セイフティネットの整備や、サービスの利用継続に向けてのユーザの救済方法の検討も求められよう。たとえば、旅行業においては、中小事業者の倒産リスクを業界全体で負担するため、旅行業法に基づく「弁済業務保証制度」や日本旅151

行業協会の独自の制度である「ボンド保証制度」によって消費者の保護を図っている。このような取り組みを行うことによって、ユーザの信頼感を高めていくことが可能になるとも考
えられる。

3.

クラウド事業者ならびに社会システムが満たすべき要件

3.1. 想定外のリスクならびに動的なリスクへの対応
前節で抽出した課題では、個別の取り組みもさることながら、想定外のリスクや動的なリ
スクへの対応の考え方の整理が重要であることが明らかになった。この点につき、佐々木教授、大林教授らの指摘を踏まえて整理したものが図表 96 である。
以下、この流れの要点についての詳細を記述する。
3.1.1. 一定の条件設定に基づいたリスクの洗い出しと対策の立案
従来の BCP の枠組みでは、想定されるリスクを網羅的に洗い出し、対策を準備するというアプローチが多かった。しかしながら、そのようなアプローチのみでは、リスクや対策は言
わば無限に広がり、大変複雑なものとなる。準備や対策に要するコストや手間も大きなものとなる。クラウド利用は IT の開発・運営のコストを縮減することが大きな目的となっていることを踏まえると、現実的には、準備・対応できることには限りがあることも確かである。
リスク要因を網羅的に洗い出そうとするよりは、様々な要因により共通して生じうる事象を起点に BCP を策定することも必要である。たとえば、電源供給遮断や運用要員が参集できないなどの中間的な状況から対応を検討する。もちろん、その電源供給遮断の原因が送電網の被災か、受電施設の浸水かなどによって対応は変わってくるが、検討するリスクを無限に広げないために、一定の枠を決めることは重要であると考えられる。
3.1.2. 優先的に稼働させるシステムの選定とステークホルダー間の合意形成（1） 基本的な考え方
長期間にわたって電力が復旧しない、あるいは十分な要員が参集しないなど、クラウドの運用に必要なリソースが極端に制約された条件下において、大幅な縮退運用を余儀なくされるケースが想定される。その結果、クラウド事業者やユーザが運用継続を優先させるべきシステムの選択を迫られる可能性がある。
また、東日本大震災でクラウドサービスが数多く提供された例に見られるように、緊急時にはその対応のために、新たな情報システムのニーズが多数・多様に発生すると考えられ、その多くが平常時のシステムより高い緊急度・優先度をもつ可能性が高い。

152

図表 97 事業継続の観点からのクラウド事業者等が準備・対応すべき対策の流れ（例）東日本大震災での教訓を踏まえ、従来の想定外を含めたリスクの洗い出しと対策の検討

リスクに対してすべて対策を手当てしているとクラウドのコストメリットが失われる可能性も。

一定の条件設定に基づいたリスクの洗い出しと対策の立案①クラウド化する対象、クラウドの利用場面
別のリスクと対応策の整理②共通する事象を起点とした対策の検討（例）
・電源喪失のリスク要因を細かくあげるのではなく、電源喪失という共通事象を想定した上での対策立案に重点を置く（例）
・通常時から利用
・災害時等のバックアップ用
・災害時等のみ利用

トリアージのような経営判断、ないし社会的な優先順位付けを求めれる場面の想定
 緊急・災害時におけるリソース等の制約条件下において、優先させるべきシステム・データの選択や対応策の選択を迫られる可能性がある。
（例）
・災害時において交通寸断等により要員が参集できない場合、他のシステムを止めて、重要性の高いシステムの代替要員を確保するといった経営判断が求められるケース
・非常用電源の確保のための燃料供給の総量が不足している場合、社会全体として重要性の高いシステムへの優先供給を確保する仕組みづくり

 クラウド事業者やユーザーにおいては、IT部門に閉じたBCPではなく、経営判断を伴うことを想定したBCPや対策の準備が必要。さらには災害時における社会全体としてのコスト負担や優先順位付けのための仕組み（ルールや保険等）が必要。
災害の発生
事業者・ユーザーにおける動的リスクに応じた対応
 活用可能なリソース（ライフラインの復旧状況、人員の参集状況等）が刻々と変化し、リスクが変化する中での対応
 データ/システムの共有範囲・セキュリティ設定を災害状況や対策に応じて変化させるなどの対応が必要となる可能性が高い。

モニタリング・監査の仕組み
 緊急時の対応、ならびに緊急時を脱した後の対応が適切に行われていることをチェックする仕組み

緊急・災害時対応を支援する社会システム
 トリアージのような判断を求められる場面に応じた社会としてのコスト負担、優先順位付け（例）
・電力供給や燃料供給などの社会全体または地域全体としての優先順位付け
・社会的なインフラとして重要性の高いクラウドの継続・早期復旧に向けて、クラウド事業者ないしユーザーのみで負担しきれないコストに関する保険や災害時補助の整備

医療においては災害時等に治療の優先順位付けを行う「トリアージ 79」という概念があるが、これと同様に前もって判断基準のみを策定しておき、事象が発生した際にはその判断基準によって優先順位付けを行うことが考えられる。それにより、たとえば重要インフラを支えるクラウドの復旧を優先させたり、緊急度の低いサービス（たとえば音楽配信など）向け

79

triage：フランス語で「選別」「優先割当」の意。医療において、大規模災害が発生したときに、負傷の度合い等
から治療の優先度の高い患者を判別すること。通常は、判別する医療従事者が結果をタグなどで表示し、救急隊や治療する医療従事者に容易に引き継げるようにする。

153

のリソースを絞って、被災者支援情報システムや救援物資物流管理システムを緊急に立ち上げたりするなどの対応が可能になる。このようなシステムの「トリアージ」においては、共用サービスであるクラウドならではの問題が発生する可能性がある。すなわち、オンプレミ
スのシステムであれば、当該ユーザのみの判断で「トリアージ」を行うことが可能であるが、一つのインフラを共用している複数のユーザのサービスにまたがる問題であるため、ユー
ザ間の調整が必要になると考えられる。

（2） 優先順位を判断する手順
具体的には図表 97 で示すような手順で、優先して稼働させるシステムを抽出し、リソースを配分する。前もって、リソース配分のルールを策定しておき、災害や障害が発生した際には、システムの被害・被災状況を勘案して、クラウド上のシステムの継続利用について優先度の判断を行う。
同時に、配分できるリソースの把握を行って、前もって策定したルールに従ってリソース配分を行うこととなる。
図表 98 リソース制約下におけるリソース配分の手順の例
被害・被災状況に基づくシステムの継続利用の優先度の判断リソース配分の必要がある
システムの抽出

配分できるリソースの把握

リソースの配分

リソース配分ルール（3） 配分できるリソースの把握とリソース配分の必要があるシステムの抽出
このうち、配分できるリソースの把握については、図表 98 に示すようなステップで行うことができる。当該システムの通常系、バックアップ等の代替手段の利用可能性を順次検討して行き、次いでその手段を運用するのに必要なリソースが通常系で確保できるか否かを判断する。停電している、通常シフトの運転要員が出勤できないなど、リソースが通常系で確保できない場合に、代替リソースの配分対象の候補となる。
なお、リソースが通常系で確保できるか否かについて把握する方法は平常時から定めておく必要があり、クラウド事業者へのインタビューでも、非常用発電機の燃料や飲料・食料の備蓄量の確認はもちろん、事業者によっては運転要員の安否・出社可否等を把握するシステムを導入するなどの方策をとっている。

154

図表 99 システム利用継続性の判断フローの例
スタート

当該システムは
通常系で運用可能か？

N定められたRTO以内で N
通常系運用が復帰可能か

Y

Y

Y
運用に必要なリソースは通常系で確保可能か？

N

Y

N

バックアップ系は利用可能か？

他のサービスにマイグレーション可能か？

Y

N

手運用、ローカル運用など代替手段での運用は可能か？

N運用に必要なリソースは
バックアップ系で確保可能か？

Y

通常系システムを復旧するという判断

Y

N

システム間の優先順位づけによる復旧リソース配分

運用に必要なリソースは N
他のサービス系で確保可能か？

Y

代替リソースを用いて運用するという判断運用に必要なリソースは N
代替手段で確保可能か？

Y
通常系で運用バックアップシステム
で運用

マイグレーション

代替手段

システム間の優先順位づけによる運用リソース配分（4） リソース配分ルールの策定
一方、事前に定めておくリソース配分ルールの検討に当たっては、図表 99 に示す業
務とシステム両面にわたる事項を考慮する必要があるものと考えられる。
業務面においては、当該システムが支援する業務の優先度を考慮する必要がある。。
発生した事態への応急・緊急対応が必要である業務や、人命に関わる業務、法令等で定められている業務などが優先度の高い業務と考えられる。このような業務の優先度を把握する指標として、業務そのものの RTO（Recovery Time Objective）などを参照することが望まれる。
また、システムの不稼働による業務停止や処理能力低下の影響度を考慮に入れる必要がある。影響度の指標として関係者数や関連する業務数、あるいはその業務の内容などを参照する。たとえば生産管理システムであれば業務が停止してしまうことでサプライチェー
ンの下流に大きな影響を与える。同時に業務停止や能力低下に対して、関係者がどれだ
け受容できるかも考慮に入れる必要がある。
システム面については、個別システムの重要度とそのシステムが存在するクラウド基盤の重要度を合わせて考慮する必要がある。個別システムの重要度では、当該システムを利用している業務数など、そのシステムの共通性の高さや、重要な情報システムが当該シス
テムに強く連携しているなど、プラットフォームとしての重要性を合わせて検討すべきである。
クラウド基盤の優先度を考える上では、重要インフラや重要システムが稼動しているクラ155

ウド基盤の回復と継続が優先される必要がある。同じクラウド基盤から提供されるサービスを絞る必要がある場合は、同一基盤を共有している他のサービスやシステムへの影響度を考慮に入れる必要がある。
図表 100 リソース配分ルールの策定に当たって考慮すべき事項
業務

システム

業務の優先度• そのときの事態において応急/緊急対応が必要• 人命に関わる業務• 法令等で定められている業務• 業務のRTOの短さ

業務停止や処理能力低下の影響度• 影響範囲の広さ（関係者数、関連する業務の数など）• 停止・能力低下に対する関係者の
許容度

個別
システムの
重要度

クラウド基盤の重要度• 当該システムを利用している業務の数（共通性の高さ）• 重要情報システムに必要な基盤シ
ステム等、プラットフォーム性の高さ• 同じクラウド基盤を共有している他のサービスへの影響度（サービス数や重要度）（5） 配分するリソースの把握
配分するリソースがどこにどれだけ存在するのかを的確に把握することが必要だが、非常時に初めて情報収集をするのでは混乱する可能性が高い。そのため、平常時から情報ルートを定めておくことが望ましい。
本章 2.7. において触れた非常用発電機の燃料確保について、石油連盟は東日本大
震災の経験を踏まえ、石油元売り各社の備蓄量の把握だけではなく、地方自治体と協定を結び、供給の必要が想定される施設について、タンクの容量や供給口の形状など輸送要件についても事前に情報の集約を図ろうとしている。このように、リソースの所在・量だけではなく、OS やユーティリティの種類、API やデータフォーマットの互換性など、緊急利用や代替提供に必要な要件についても事前の情報収集を進めておくことが望ましい。
（6） ルールの策定やリソース配分の主体
以上述べてきたような優先順位の決定やリソース配分の調整は、クラウド事業者で完結できる場合もあれば、そうでない場合もある。
他のデータセンターからの要員や燃料の融通などクラウド事業者で完結できる場合は、
クラウド事業者の判断でリソース配分できる。しかしながら、電力や非常用電源の燃料など、他の業界と共用しているリソースについてはクラウド事業者のみでは行いきれず、クラウド事業者およびリソースの供給事業者・業界団体、行政なども含めて検討していくことが有益であると考えられる。たとえば、非常用電源の確保のための燃料供給の総量が不足している場合、社会全体として重要性の高いシステムへの優先供給を確保しなければならない。
東日本大震災の事例では、石油連盟および全国石油商業組合連合会が業界として供給責任を担ったが、優先順位の判断は民間では行いきれないため、政府の指示による優先
順位従って供給を行っている。
このように、トリアージを行うに当たっては「誰が」「どのような条件で」「どんな情報に基づ
156

いて」「どんな権限によって」優先順位を判断し、「誰が」「どのように」実行を指示するのかがあらかじめ決められてあり、共通認識になっていることが重要である。そのための社会的な仕組みづくりや合意形成を平時から進めておくことが必要となる。判断、指示の体制は、混乱を拡大しないためできるだけシンプルにしておく必要があると考えられるが、判断・指示をする担当者に事故があった場合に備え、権限委譲の順位を定めるなどの対応も必要である。
（7） その他の要件
この判断基準について、柔軟性をもった判断やトリアージとも言える場面での経営判断が適切に行われているかどうかについては、モニタリングあるいは監査を受けることも必要ではないか、という点が佐々木教授からは指摘された。とりわけクラウドにおいては、ユー
ザにとってはシステムの状況やクラウド事業者の対応の状況は見えにくいため、クラウド事
業者の対応をチェックする仕組みの構築は通常の情報システムと比べても大きな課題である。現行の情報開示制度をさらに充実させることも必要と考えられる。
また、必要なコストについてはユーザへの料金に転嫁されるものと考えられるが、ユーザニーズである低廉なシステム利用コストとのバランスを考慮する必要がある。保険のような仕組みを組み入れることが有効である可能性もある。今後の検討課題と言える。

3.2. トリアージの枠組みにおける考え方の例
ここでは、3.1 で考察した緊急時におけるデータセンター機能の維持・提供に関する「トリアージ」的アプローチの例示を試みる。医療における緊急時の救急治療の優先度を判断する仕組みの概念を援用して、ここでは「前もって判断基準のみを策定しておき、事象が発生した際にはその判断基準によって優先順位付けを行うこと」の意味を持つものとして使用する。その考え方の枠組みは、図表 97 のように表わされる。
図表 101 データセンター機能に関するトリアージ的判断枠組み［需要サイド］［供給サイド］

発電
鉄道
道路網

通信
運転要員

クラウドサービス

救援物資配給救急医療
救援行政対応救援情報提供トリアージ

行政情報提供
医療

水道

水道
金融

生活物資

行政
一般のシステム157

重要インフラ

生産

避難所管理運営

補充燃料

石油備蓄
物流

安否情報確認

データセンター機能

緊急対応・緊急支援

電力緊急時にリソースの供給サイドの情報を把握してクラウドサービスの供給可能量を量り、また緊急時対応を含む需要側の量を把握して、予め決めておいたプロセスと判断基準に基づく優先順位付けを行いながら、リソースの配分を行うプロセスである。
データセンターの機能がどの程度維持・提供できるのか、の供給サイドの判断と、緊急対応や重要インフラの機能維持のために緊急に必要とされるシステムニーズの把握、ならびに、そのデータセンターが平常時に担っているサービスとの優先度に関する、需要サイドの判断の両方を、平行して行わなければならない。
この情報収集と判断のプロセス（「トリアージ」）は、一例として、図表 98 のように表わせる。
図表 102 クラウドの「トリアージ」の判断プロセス・フローの例
START

サービス提供 Ｙ

緊急時対応のサービス需要の把握

平常時提供サービスのたな卸し

緊急時サービス需要の優先順位付け

平常時提供サービスの優先順位付け（
平常時に行っておくのが理想的）

データセンター機能を維持するための供給（電力、通信、燃料、運転要員）確保について情報を収集

可能？
Ｎ
平常時需要のうち緊急度･優先度の高いシステムを他のデータセンターに移管

Ｎ

終了？
Ｙ
END

状況変化の継続的観察、情報
収集・集約

：情報収集

総合優先順位に基づいてサービスを提供

他のデータセン
ターからの需要受け入れを検討：優先度判断緊急時提供サービスの総合優先順位リスト

Ｙ
更に余力あり？

：サービス実行

Ｎ「トリアージ」の優先順位付け判断基準：データセンター間連携

この例では、トリアージの考え方に基づき、平常時においてそのデータセンターが提供しているサービスのリストが把握されており、かつその間の優先順位付けも行われていることを想定している。緊急事態が発生したときは、1)データセンター機能を維持するための供給（電力、通信、燃料、運転要員）確保について情報を収集するとともに、2)緊急時対応のために発生する IT サービスに対する需要の把握を行う。
次に、緊急時需要について優先順位付けを行う。この際も、予め設定された判断基準に基づき行うことが、混乱を避け迅速性と効率性を担保するために必要である。この順位付けられたリストと予め優先順位付けられた平常時のサービスリストをマージして、総合優
先順位リストを作成する。このために判断基準も予め定めておく必要がある。一例として、
以下のような優先順位付けが用意されているとよいのではないかと考えられる。

158

1. 人命・生命の維持に関すること（救急、緊急医療、飲食料の供給）
2. 緊急支援・緊急対応に直接関すること（避難生活を支える情報管理、救援物資配給）
3. 重要インフラ等社会基盤のうち重要性の高いシステム（ライフライン、物流、金融）
4. 緊急支援・緊急対応に二次的に関すること（地域行政対応、避難者の心身ケア、支援者のサポート）
5. 企業の生産活動に関するもの（在庫のない生活必需品、サプライチェーンの長い工業品）
6. 都道府県･国レベルの広域行政対応 （通常システムでまかないきれない部分）（ただし、1～3 の順位は状況に応じて変える）
データセンターを稼動させるために利用可能なリソースの把握が行われると、サービスの供給が可能か、どの程度サービスを提供できるかの情報が得られる。サービス提供が可能であれば、その能力に応じて、需要側の優先順位リストに対して、順次サービスを提供する。
もしそのデータセンターの能力が需要に対して十分大きく、余裕がある場合には、他のデータセンターで対応できない需要を引き受けることも検討されるべきである。
また逆に、当該データセンターのサービス提供が不可能な場合や、重要度の極めて高い需要を満たすには能力不足であるような場合は、当該データセンターが抱える優先度の高い需要を他のデータセンターに振り向けることを行わなければならない。
災害時等には、状況は刻々と変化するので、一定時間のインターバルで、あるいは状況に大きな変化が生じる都度、この判断サイクルをまわす必要がある。
この考え方で重要なのは、、予め判断プロセスのフローと基準を用意しておくことである。
事態が発生したときに現場において用意するべきものとしておくと、緊急事態で情報と状況が錯綜する中で、体系だった判断が困難になり、不適切な判断基準や矛盾した、あるいは首尾一貫性のない判断に陥りがちである。したがって、平時において基本枠組みを定めておく必要がある。それによって初めて、いざというときに実際の現場で起こる不確定要
素を、予め定めた枠組みに組み込みながら、的確な判断が実施できるようになる。
逆に、緊急時における発生事象を考えうる限り想定し、その組合せを幾通りも用意して、各々に対して最適解を設計しておく考え方は、緻密な計画のようでいて、いざというときに機能しない恐れがある。なぜなら、非常時に生起することは平常時の想定どおりにいかな
いことが多い上、余りに精緻で複雑に分岐した状況想定では、適用条件の照合に手間を取られ、細部の相違を吸収するための応用問題に頭を悩ますことになり、効率を著しく阻害する恐れが強いからである。
個別状況でなく判断プロセスと判断基準を整備することにより、緊急時にクラウドがその159

機能を維持し、あるいは早期に回復し、緊急対応のために必要なサービスを、優先順位をつけながら供給し、社会インフラとして機能することが期待される。
より具体的には、図表 99 に示すようなフレームワークを用意し、これに沿って準備を行った上で、緊急時対応にも活かすといったことが考えられる。クラウドのレジリエンシのための「トリアージ」的アプローチにおける考え方や判断ポイントの一例として示す。

160

図表 99 クラウドのレジリエンシのための「トリアージ」的考え方・判断ポイントの例
データセン
ター

内訳項目

前提となる平時の準備

基本

緊急時対応の考え方
バリエーション

通常商用電力＜コンピュータ電源＞
供給系統の二重化（ただし広域停電時には＜コンピュータ室空調用電力源確保を最優先に対応
役に立たない）電源＞＜オペレータ室電源＞

電力

UPS

非常用発電機

非常用発電機燃料

非常用発電機燃料
ガス

・一定時間空調を維持できるだけの冷却水の備蓄コンピュータ室空調用冷却・水冷を避け空冷を選択する考えもある。
水
一部空冷にして冷却水不足をヘッジする方法もある。
非常用発電機用冷却水
トイレ用水
常用データ通信回線

一定時間運転継続できるだけの備蓄・貯水槽等での対応
・簡易トイレ等の備蓄
通信回線の冗長化
複数通信事業者との契約
複数中継局との接続
無線通信手段の確保

通信回線

非常時の縮退運転用デー
タ通信回線

衛星通信手段の確保

必要に応じて運転要員に提供

泊り込み要員のための生 ・必要量の想定（人数×想定日数）
運転・保守 活備蓄（水、食料、寝具、 ・備蓄品の消費期限の管理要員
トイレ、熱源）・備蓄場所の選定と周知、鍵管理

常用システムコンピュータシステム

HA構成
システム・バックアップ

常用系の重要システム

確保すべき
サービスの
選択
非常時対応のために緊急に必要なシステム･サービス

非常時対応・緊急対応の主体
利用主体（緊急時デー
タセンター
被災主体または緊急対応
サービスの
の副次主体
受益者）の
選択
重要インフラおよび重要イ
ンフラを支える二次供給系

必要に応じ、店頭または救援源か
ら追加調達

・備蓄補充の手配を行う
・冷却水を補給せずに運転可能な時間の把握
冷却水なしで運転できる範囲（稼動させるシステ
ム）を決める
非常用発電機の運転ニーズに合わせて供給

冷却水の補充を必要としない予備電源の設置が基本

必要に応じて運転要員に提供

近隣施設の利用も・通信回線確保は電源に次ぐ優先確保項目
・利用の優先付けに対応した選択・運用
・中継局の死活に応じた使い分け・バッテリ容量を考慮
・連絡・業務のための予備通信手段
・原則としてサービス提供手段としては利用しな
い・携帯電話（3G+LTE）
・中継局の死活に応じた使い分け
非常時の連絡用通信手段 ・衛星電話
・バッテリ容量を考慮
・データ通信用モデム
非常時シフト（泊り込み含 ・複数のバリエーションによる班・シフト編成
緊急対応計画に基づく召集・シフト体制の発令
む）編成
・非常時召集（安否確認含む）の定期的訓練

通勤・交通手段

緊急時にコンピュータ室内でのオ 電力会社の復旧見
ペレーションに移行する代替策も 通し公表が重要

電力の瞬断・瞬低対策と、停電時の予備電
電源切り替え時の短時間の代替補償であり、補源への切り替えのつなぎ目的であり、代替完的役割以上のものを期待しない
電源と位置づけない。
・予備電源・自家発電装置の設置
長時間連続運転に・定期点検により、いつでも稼動できる状態 商用電源喪失時に自動起動・自動切換え実施 給電範囲を細かく区分
耐えないことを考慮を維持・適法の範囲で最大量の備蓄
備蓄補充の手配を行う
・近隣への二次備蓄の検討（輸送手段含む）
非常用発電機のための燃料補給契約：優先
二次補給源を用意することも視野
定期的供給・補充を確保するに供給契約および契約先の二重化
・耐震性の確保
地震被害の場合都LPGを燃料とする場合、LPGの定期的供給・補充
・複数供給ルートの確保
市ガスの供給は当を確保する・LPGの貯蔵を選択肢として持つてにならない？

非常時運転（泊り込み）要
カセットコンロ・ボンベの備蓄員の生活熱源水道

備考

必要に応じて運転要員に提供

実現可能性チェック
暗号化への考慮

バッテリ充電電源の確保

出勤・帰宅困難者の状況に応じてシフト編成を臨機に変更
・必要に応じ、店頭または救援源から追加調達・余裕がある場合、避難民への提供を考慮・組織として、各要員の常用交通手段、迂・通勤経路の利用可能性・安全把握
データセンターから徒歩圏内で住回・代替交通手段の把握
・危険のない範囲で出勤できる要員を優先確保 宅を確保することも検討対象
・徒歩ルートの確認と実況検分・信頼性に関する評価（自己評価、第三者評価）
・経産省「情報システムの信頼性向上に関す ・電源容量、運転要員量に応じて縮退。
るガイドライン」、同「情報システムの信頼性 ・アプリケーション（用途）に基づく優先選択
向上に関する評価指標」、IPA「信頼性自己診断ツール」の活用
冗長化構成、常用予備切り替え機能の確保 主システムの停止に伴い自動起動･自動切換え
・設定の保存・マシンイメージの保存
コールドスタンバイシステムの場合、リストアを実・リストア作業手順の作成・周知徹底と定期 施
的訓練
・重要インフラを中心に非常時に確保すべき機能を確保
・緊急対応の高優先事項との比較で、優先度の低いサービスを抑制
以下のものを第一優先と位置づける。
①救援・救急の中核システム
住民の把握、移動把握、状態把②救援・復旧物資の集荷・物流・配備のための基 握のためのシステムを第二次優幹システム
先で用意する。
③被災者管理の情報システム
時系列で追随できる機能や、情報④行政の非常時対応のための基幹システム
をタイムリーに定常的に吸い上げ⑤被災者への医療・医薬等供給のための情報シ られる機構も併せて整える。
ステム
以下のものを第一優先と位置づける。
国は別途独自に非①市区町村
常対応機能を確保②市町村の出先機関
することを前提とし、③都道府県・政令指定都市
支援対象の優先順
現場判断が困難な場合、国や都④被災者支援のボランティア組織
位には含めないこと
道府県の指示を仰ぐ可能性も考とする
慮
以下のものを第二優先と位置づける。
①被災者
②被災企業
③支援企業
重要インフラは第一優先の対象となるが、多くが重要インフラに準じるものとして、 現場判断が困難な
独自のシステムを持って運用している実態から、非常用電源の燃料の供給事業者 場合、国や都道府
別途、要請に応じて対応する。
（石油製造・流通事業者）を優先 県の指示を仰ぐ可能
対象としては、電力、通信、水道、ガス、物流、金対応対象とする。
性も考慮
融が中心となる。

161

3.3. 個別の取り組みで満たすべき要件
今まで述べたような基本的な考え方に基づくと、クラウド事業者や社会全体で満たすべ
き具体的な要件は、次の図表 102 のように整理される。
図表 103

事業継続の観点からのクラウド事業者等が満たすべき要件

項目

要件

関連する事例、有識者からの指摘等

平常時からのファシリテ
ィ面の対策

 3.11 前から講じられてきた堅牢性を確保するファシリティ基準の
継続的な遵守 3.11 時にデータセンターはほとんど無傷で、事業継続できた。もっとも、件数は少ないものの、サーバ室の天井が剥がれ落ちたケースと免震構造のサーバーキャビネットが倒れたケースが見られた。これらはこれまで想定していなかったため、ハード面の基準として見直す必要がある。

 津波・液状化をはじめ、3.11 前に想定が弱かった対策の強化

 液状化の影響は 3.11 前までは、十分考慮したデータセンターのファシリティ基準となっていなかった。津波への対策も同様である。これらについて、対策を強化する必要がある。
平常時におけるライフラインの冗長性確保

 電力・通信等のバックアップ手段確保 また、現状では通信回路が単一であるところ
が緊急・災害時には問題となる可能性がある。とはいっても、エンドユーザに対してはコスト等の関係で推奨するに留まらざるを得ない。
 緊急・災害時には通信回路の確保に加えて、その容量も問題となりえる。

緊急･災害時における代替ライフラインの確保
緊急･災害時における代替ライフライ
ン確保のための二次的サプライの要件

 電力の復旧に時間を要したほか、計画停電もおこなわれた。ライフラインに対する準備が平常時から重要であった。

 非常用の自家発電機は耐用時間が短く、長期間の停電には耐えられない。
 緊急・災害時の燃料等の社会全体での最適配分の仕組みづくり

 非常用電源を動かすための燃料が重要である。データセンターは備蓄と補給でなんとか稼働し続けたが、一部銀行の電算センターでは 3 時間程度の燃料備蓄しかなく、停止した。
 燃料の優先供給契約は 3.11 ではほとんど機能しなかった（タンクローリーの不足、交通遮
断、被災地への優先的供給など）。
 燃料供給者の視点からは、要望が殺到する
中で優先順位を付けて供給することは民間では無理がある。公的な指示が必要。

データセンタ
ーの運転な
らびに保安
のための要
員に関する

 緊急・災害時において少ない要員での稼働、ないし要員参集を前提としない稼働に向けた準備 3.11 は金曜の昼間であったから深刻な問題とならなかったものの、夜間の場合であったら要員確保は懸念される。
 交通寸断により要員確保が難しくなるケース

162

項目

要件

関連する事例、有識者からの指摘等要件も想定される。
 3.11 のときは大きな問題とならなかったが、大規模な自然災害の後にインフルエンザなどの感染症が広がるリスクもある。

緊急・災害時におけるセキュリティ対策、ならびに
意図を持っ
て行われる
サイバー攻
撃に対する
防衛または
回避

 緊急・災害時の状況に応じたセキュリティ基準緩和の手続き、監査・監視に向けた準備 サイバー攻撃等に備えた対策の厳格な運用

 緊急・災害時には厳重なセキュリティチェック
が難しくなるケースがある。たとえば、電力補給のためにデータセンターへの入館を比較的容易に認めるといったケースも想定される。
 医療における患者のデータ共有がクラウドで円滑に進むと、災害時の人命救助等の点で効果的である。ただし、その際の個人情報保護を含めたセキュリティ対策をどこまで緩めるのか、また誰がどのような手順でセキュリティ
を監査・監視するのかという課題は残る。
 クラウドにおいてもサイバー攻撃等に備えた対策としての基本的な事項は、通常の IT の場合と同様である（アクセス制限をかけることやデータの暗号化を進めることなど）が、クラウド化すると攻撃を受けうる対象が増えるた
め、より厳格な対策が必要とされる。

その他

 契約におけるトラブル対策の責任の所在、手続きの明確化
 中小事業者等のサービス途絶リ
スクに対する社会としてのセイフ
ティネットの構築

163

 南海トラフ地震など、現状の BCP で想定している以上の災害リスクにどのように対応すべきか。
 平常時、緊急・災害時を問わず、クラウド事業者が倒産したり、トラブルが起きたりした際の責任の所在を明確にしておく必要がある。

III. システムやベンダーの枠を越えたデータセンター間連携やクラウド間マイグ
レーションを可能にするために必要な諸要素の調査
1.

問題認識
クラウド事業者間連携に関する欧米と日本の問題認識の違いに触れながら、日本としてクラウド事業者間連携に対してどう取り組むべきかを検討する。なお、クラウド事業者間連携の実現に必要な要素としてクラウドの標準化があり、クラウド標準化も含めた形で動向を整理する。

1.1. 欧米の動向
欧米においては、米国国立標準技術研究所（NIST）、Distributed Management
Task Force（DMTF）、Open Data Center Alliance(ODCA)等の標準化機関や業界団
体がクラウドの標準化やクラウド事業者間連携に関するフレームワークを議論し、積極的に進めようとしている。しかしながら Amazon、Google などの大手クラウド事業者側は、ユー
ザ企業が他クラウド事業者サービスに取り込まれるのを避けるべく、独自仕様を実装し、自社サービスから簡単に他サービスへ移行できないようにするために、標準化には消極的であるとの見方もある。また自社で複数データセンターにクラウドサービスを展開し、かつデータセンター間の連携ができていることから、事業者間連携に対する意識はない。このことから、クラウドの供給サイドにおいては、クラウド標準化、クラウド事業者間連携に関する議論は進んでいない状況であると言える。
一方、ユーザ企業は、クラウド事業者から囲い込まれることなく、むしろクラウド事業者をコントロールできるように、自らクラウドサービスおよびクラウド技術に関するリテラシー（正しい理解と使いこなす能力）を高め、クラウドサービスをうまく組み合わせたサービスモデル
やベストプラクティスを議論する傾向にある。たとえば、ODCA に UBS（スイスの大手銀行）、
ドイツ銀行、BMW（ドイツの高級自動車メーカ）等のユーザ企業が参加し、クラウド標準化、
クラウド事業者連携に関するフレームワークを議論していることから、その一端は覗える。
また、そのようなクラウドサービスをマッシュアップ的に組み合わせるサービスを提供する
クラウドブローカービジネスも出てきている。NIST 80によるとクラウドブローカーは以下の 3つに定義される。
1. Service Intermediation（クラウドサービスの仲介）
クラウド事業者が提供するサービスに対して、特定の機能を改良したり付加価値を付け加えたりして強化したサービスを、クラウド利用者に提供する。改良項目としては、クラウドサービスへのアクセス管理、ID 管理、性能レポート、セキュリティの強化などがある。

80

NIST SP800-292 Cloud Computing Reference Architecture による
164

2. Service Aggregation（クラウドサービスの統合）
１つまたは複数のクラウドサービスを組み合わせることにより、新たなクラウドサービスを利用者に提供する。その際、クラウドブローカーは、データの統合や利用者と複数のクラウ
ド·プロバイダー間の安全なデータ転送を提供する。
3. Service Arbitrage（クラウドサービスの裁定取引）「クラウドサービスの裁定取引」は「クラウドサービスの統合」と似ているが、違いは「クラウドサービスの裁定取引」の方が、集約するサービスを固定していない点である。つまり、クラウドブローカーが複数のクラウドサービスから選択する柔軟性を持っていることを意味する。例えば、スコアリングサービスを使ってクラウドサービスを評価し、最高の評価を持つサービスを選択するといったことを行う。
1.～3.において共通するブローカーの主な提供機能としては、「セルフサービスの契約
手続きおよびプロビジョニング」「複数サービスにまたがるアクセスコントロール」「SLA に応じたパフォーマンス監視」「利用状況に応じた料金算出と課金処理」「ヘルプデスク」など、ユーザが利用したい機能をひとまとめに用意しているのが特徴である。このような機能はク
ラウドサービス側の API を通じて提供できるようになっており、ユーザから実際に利用するクラウドサービス仕様が見えるようにしている。また、重要なデータについてはクラウドサー
ビス側で保存される。
ただし、1.～3.全体において、ブローカーは複数のクラウドサービス利用の入り口を一つにしているが、クラウドサービスの機能を組み合わせたり、あるクラウドサービスが停止した
場合に他クラウドサービスにリソースを移してサービス継続性を図る BCP の要素は含まれていない。
背景として、欧米においては、ユーザ企業自らクラウドに対するリテラシーを身につけ、クラウドサービス毎の機能、価格、可用性、既存システムとの連携を吟味し、リスクがある部
分については、複数のクラウドサービスを利用することで、クラウドサービス事業者の冗長化を図り、クラウド導入後、よりよいサービスが出てくれば柔軟にクラウド事業者を乗り換えていくなど、クラウドサービスの継続性を自ら確保するという共通理解ができつつあるのではないかと考えられる。また、そのようなユーザニーズを受けて、クラウドサービスを組み合わせる手助けとなるべく、クラウドブローカービジネスが今台頭してきているのではないかと推測できる。

1.2. 日本の動向
日本においては、グローバルクラウド基盤連携技術フォーラム（GICTF）がクラウド事業者間連携について、積極的にユースケースを規定し、標準化を進めるべく活動している。
その考え方は、広範囲にわたる大規模災害やデータセンター内設備等の大規模故障が165発生した際に、ユーザ企業に対してクラウド事業者がサービスを継続させるためにクラウド間連携を実施する状況を想定し、クラウド間の監視・死活の確認、代替リソースの発見･確
保、リソース管理やサービスセットアップ及びサービスのマイグレーション、認証連携等の要件について検討し共通認識やインターフェイスを形成しようとするものであり、DMTF な
ど標準化団体に働きかけて国際的な標準としての開発を目指している。
ただし、現状では、国内の大手クラウド事業者側は、欧米同様、自社サービスにユーザ企業を囲い込めないこともあり、あまり積極的ではない状況がうかがえる。
ユーザ企業の動きとしては、欧米と違いユーザ自らというよりは、今までの IT パートナー
であるシステムインテグレータに、初期導入におけるクラウド事業者の選定や、場合によっては複数クラウドサービスの機能連携、ユーザの既存システムとの連携の実現を依存する傾向にある。さらに、クラウドサービス側でトラブルが発生した場合はその対応責任をもシス
テムインテグレータに負担させるケースが多い。
システムインテグレータがこのように複数クラウド事業者を束ねる点については、欧米のクラウドブローカーに似ているといえる。しかしながら、システムインテグレータは単純な仲介ではなく、複数のクラウドサービス機能を連携させて新たなクラウドサービスとして提供している点がクラウドブローカーと異なっている。また、ユーザに対してクラウドサービス仕様を直接見せずに、システムインテグレータのサービスとして見せている点ででも違いがある。
クラウド事業者側のインタビューの中では、事業者間連携に対して否定的な意見が多く見られた。しかしながら実際には事例や証言を総合してみると、国内のクラウド事業者においては、規模に関係なく事業者間連携に対するニーズがあった。
その第一は他の事業者へのリソース提供である。たとえば、中小のクラウド事業者が一時的な需要増への対応として大手クラウド事業者のリソースを借りたいというニーズがあるという。第二は自社のクラウド事業の差別化要因として、事業者間連携サービスを提供している事業者がある。第三には大手クラウド事業者の中にもクラウドサービスの DR サイトを用意しているものの、収支面からメインサイトと同じリソースを DR サイトでは準備できないた
め、状況によっては他の事業者が保有するクラウドサービスからリソースを借り受けたいというものである。
以上をまとめると、日本におけるクラウド間連携に対するニーズには以下のような特徴があることがわかった。
まず、東日本大震災に見るように災害が多い国であり、欧米と比較してクラウド事業者間連携の必要度は高い。また、ユーザ企業はクラウドとの連携を含めたシステム全体の継続性確保をシステムインテグレータに求め、システムインテグレータは自社のサービスの一部としてクラウドサービスを提供する傾向にある。一方、クラウド事業者側の自身の事業継続性において全てがしっかり準備できているとは限らず、ユーザはもとより、システムインテグ
レータもその事に気付いているのか疑問が残る。

166

したがって、クラウド事業者にとっては自身の事業継続性の観点からも、まずはクラウド事業者、システムインテグレータ双方が、クラウド事業者間連携に関する議論を深め、国内ユーザに発信し、ひいては日本から世界に発信することが望ましい。

2.

現状の取り組みと課題

2.1. 事業者の認識
いくつかのクラウド事業者に、クラウド事業者間連携への取り組み状況について、インタビューした結果、「積極的に取り組んではいない」事業者と「関心はあるがアイデアの域から出ない」事業者の 2 つに分かれた。
積極的ではない理由としては、主に「自社で複数サイトを持っており、他社と連携の必要がない」という理由だった。また、アイデアの域から出ない理由としては、下記のようないく
つかの問題点が挙げられた。
•

事業者ごとのセキュリティポリシーや SLA の差異をどうするか。

•

クラウド事業者間の契約形態をどうするか。

•

重要データを扱うシステムほど、再委託を嫌がる点をどうするか。

•

仮想化環境の差異を吸収できるか。

•

仮想マシンイメージ移行をネットワーク越しでやる場合は、回線帯域、遅延の影響を考える必要がある。

•

クラウドをまたがるデータコピーは事前に準備しておかないと、転送に時間を要する。

2.2. 先行的な取り組み事例
上記の通り、異なるクラウド事業者間連携に関して、否定的な見方が多い。しかし、広域災害を想定してサービス継続を実現するために、事業者間連携を行うという考え方が出てきている。以下に、国内ではまだ少数と考えられる、事業者をまたいだクラウド間の連携事
例を紹介する。前述したとおり、他社との連携を必要としているクラウド事業者は存在するため、今後も取り組み事例が増えてくるものと想定される。
2.2.1. 取り組みの背景
東日本大震災とその後の電力の供給状況を踏まえると、配電系統が異なっていたとしても同一電力事業者の管内では電力の完全な安定供給は保障されないとの判断の下、電力事業者の枠を越えた場所での災害復旧サービスを行うことが望まれた。また、ユーザから「30 メートルの津波がきたら大丈夫か」と聞かれるようになり、データセンター事業者として選択され続けるには、1 社における堅牢性の追求では限界があり、地方のデータセンタ
ー事業者として全国にアピールするために、連携を行うことを決断したという。

167

2.2.2. 取り組みの内容
新潟市の BSN アイネットと富山市の北陸コンピュータ・サービスは 2012 年 3 月 5 日、
VMware 社のソリューション、vCenter Service Recovery Manager（SRM）を使った災害復旧（DR）サービスを提供開始したと発表した。異なる事業者が SRM で連携し、DR サービスを双方向で提供するのは、これがおそらく国内では初めてと考えられる。先に述べた電力事業者の管轄は、BSN アイネットが東北電力（周波数 50Hz）、北陸コンピュータ・
サービスが北陸電力（周波数 60Hz）と、異なる電力会社の供給区域にあるため、大規模
な停電、計画停電の影響を受けにくいと考えられる。
データセンター間の距離は 200km。単一の災害で同時に被災する、少なくとも同時に機能停止に陥る可能性が極めて小さい距離である。このサービスの 1 つのポイントは、データセンター間で対称的なシステムとなっており、各機種を同一にしている。復旧時間のめどは 30 分で、復旧状態を顧客に確認してもらう。
この事業者間連携の上に乗って運用されているシステムの例としては、歯科医院向けレ
セプトシステム、公立病院向け経営分析・財務会計システム、自治体向け財務会計業務シ
ステム、ガス上下水道料金・公営企業会計、総合行政情報ネットワーク、民間向け販売シ
ステムがある。 重要インフラに該当するシステムが多く乗っている点が注目される。
図表 101 クラウド基盤連携サービスのイメージ

出所）株式会社ＢＳＮアイネット、北陸コンピュータ・サービス株式会社ニュースリリース (2012 年 3 月 5 日)
http://www.bsnnet.co.jp/news/news20120305/（2012 年 6 月現在）

168

この事例は、大手事業者にはない、地域に密着した中堅事業者ならではの取り組みとして注目される。今後、地方自治体などのシステムを預かる地方中堅事業者が大手の進出に対抗するビジネス上の要求からも取り組みが増えていくことが期待される。

3.

クラウド間連携等の実現に向けた諸要素
本節では、クラウド間の連携の実現に向け、解決が必要となる課題を技術および制度の面から検討を行った。その概要は以下の通り。

3.1. クラウド間連携がスムーズに実現するための技術的要件
3.1.1. 検討の進め方
異なるプラットフォーム間で、仮想マシンインスタンスもしくは仮想マシンモニタのレイヤ
ーで移行・移転（いわゆるフェイルオーバまたはマイグレーション）をスムーズに実現するために必要な技術的要件について、NIST の定義や各標準化団体で規定している共通仕様、有識者・クラウド事業者へのインタビュー結果などを元に検討を進める。
3.1.2. 各標準化団体で規定している共通仕様
クラウド間連携に必要な技術的要件を洗い出す前に、クラウド間連携視点で、各標準化団体で規定している共通仕様のうち、主だったものについて触れていく。（略称のフルスペ
ル等は図表 101 参照）（1） DMTF の OVF
仮 想 マ シ ン （ VM ） の デ ィ ス ク イ メ ー ジ の 標 準 フ ォ ー マ ッ ト で あ る OVF （ Open
Virtualization Format）を DMTF にて策定。仮想マシンイメージのポータビリティを考える上で、現在非常に利用されている共通フォーマットである。
（2） SNIA の CDMI
データパスだけでなく、クラウド環境に保存されたデータに対するサービスレベル管理、
データ移動や関連データとのやり取りにおける共通フォーマットなどを定義。保存するコン
テンツのメタデータを保持するように設計されている。これにより、異なるクラウド間にて、ス
トレージの機種や様々なファイルシステム（NFS、CIFS、WebDAV など）を意識せずに、
CDMI で規定している API 経由でデータの移動が可能となる。ただ、EMC や日立など主だったストレージベンダからの対応製品の提供はほとんどなく、まだ普及はしていない模様である。
（3） OGF の OCCI2009 年にOGF内で立ち上がったOCCI-WGにて、IaaS管理用インターフェイスAPIの

169

共通仕様となるOCCIを策定。RESTful API 81に準拠していることが特徴で、プロビジョニ
ング等のIaaS管理が遠隔から可能である。「OpenNebula 82」、「OpenStack 83」など主要なオープンソースのクラウド基盤構築ソフトに実装されている。
主要な標準化団体とその提唱する共通仕様を図表 103 にまとめた。
図表 104 クラウドに関する標準化団体一覧
団体名
OGF(Open Grid
Forum)

概要
1999 年設立、400 以上の機関が参加。
Open Cloud Computing Interface Working
Group (OCCI-WG)においてクラウドコンピューティングインフラの遠隔管理を可能とする API を検討
企業やインターネットにおける IT 環境のシステム管理のための標準を策定・保守する標準化団体。
1992 年設立。43 カ国以上から 160 以上の機関が参加。クラウド基盤上にアプリケーションを実装するための規約策定に向け、2010 年に作業チーム
Open Cloud Standards Incubator により 白書を作成、その実現に向けた活動
1997 年 12 月設立、参加社数 250 以上
クラウドとのデータ読み書きに関するインターフェ
イ ス CDMI （ Cloud Data Management
Interface）の策定とその導入に向けた活動である
Cloud Storage Initiative を運営

共通仕様
IaaS の管理インターフェイス API である
OCCI （ Open Cloud Computing
Interface）を策定

OASIS(Organization for
the Advancementof Structured
Information
Standards)

1993 年に SAML Open として発足（1998 年に
OASIS に改称）100 カ国以上から 600 以上の機関が参加。
クラウド上の ID 管理・相互運用性の課題検討のための技術委員会を設立

IDCloud
TOSCA

Open ID
Foundation/
KantaraInitiative

2007 年設立。著作権管理、商標管理、仕様を自由に使うことができるようにするための標準化プロ
セスの管理、OpenID 財団の標準化プロセスで標準化された各種規格についての普及啓蒙を実施。

OMG(Object
Management
Group)

1989 年設立、参加社・機関数数百。組み込みソフ
トからビジネスアーキテクチャーなど幅広い分野の標準化団体。2011 年 4 月にクラウド導入に向けた
ア ド ボ カ シ ー グ ル ー プ Cloud Standards
Customer Council を設立。多様なクラウドインフ
ラ上のアプリケーションのモデル化などを検討。
トラステッドコンピューティングを実現するためのオープンスタンダードの検討、策定そしてその普及を促進するための非営利団体。

次世代の認証・連合アイデンティティシステ
ムの標準である「OpenID Connect」を策定クラウドサービスにおけるアイデンティティ・
プロビジョニング・インタフェースの共通仕様 （ SCIM （ Simple Cloud Identity
Management））を策定―

DMTF(Distributed
Management
Task Force, Inc.)

SNIA(Storage
Networking
Industry
Association)

TCG(Trusted
Computing
81

IaaS の管理インターフェイス API である
CIMI
（
Cloud
InfrastructureManagement Interface）を策定
VM のディスクイメージの標準フォーマット
で あ る OVF （ Open Virtualization
Format）を策定
クラウド管理インターフェイス仕様（CDMI）
を策定

プラットフォームの正当性証明機能、データの暗号化機能、電子鍵および電子証明書の安全な保管機能などを提供するオン

2000 年に Roy Fielding 氏が提唱した、分散システムにおいて複数のソフトウェアを連携させるのに適した設計
原則を Web に適用したソフトウェアの設計様式に基づいて作成されたアプリケーションインターフェイス。パラメータを指定して特定の URL に HTTP でアクセスすると、XML で記述されたメッセージが送られてくるような呼び出しインターフェイスである。
82 2008 年 3 月に OpenNebula Community によって初版がリリースされたオープンソースの IaaS 構築ソフトウ
ェア。
83 Rackspace Cloud 社と NASA（米国航空宇宙局）の共同プロジェクトで開発され、2010 年 10 月に初版がリリースされたオープンソースの IaaS 構築ソフトウェア。

170

Group)GICTF （ グ ロ ー バ
ルクラウド基盤連携
技術フォーラム）2009 年設立。クラウドシステム利用技術等の開発・標準化の推進を目的に、クラウドシステム間連携を実現する標準インターフェイスの提案を行っている我が国の団体。2007 年 7 月に米 DMTF と提携した。

ボ ー ド チ ッ プ で あ る TPM(Trusted
Platform Module)の規格を策定―

3.1.3. 基本的な考え方
ユースケースとして、広範囲にわたる大規模災害やデータセンター内設備等の大規模故障が発生した際に、ユーザ企業に対してクラウド事業者がサービスを継続させるために
クラウド間連携を実施する場合を想定する。
その場合、クラウド間連携を実現させるための技術的な方式は、以下の 2 つに大別されると考えられる。
① 大規模災害発生時に、連携先クラウドサービス内のリソース調整（発見・確保）を行い、仮想マシンおよびデータを移行させる。
② 予め、連携先クラウドサービスの仮想マシン、ストレージ、NW におけるリソースを確保しておき、平常時に定期的にデータ同期を実施。
これまでの調査結果から、クラウド上で運用するシステムの規模が大きくなればなるほど、大規模災害が発生してから他クラウドサービスに仮想マシンを移行させるのは、不確定要素がいくつかあり、RTO/RPO 84を守ることが難しく、現実的ではないと考えられる。具体的な不確定要素は以下の通り。
• 移行先リソースの発見・確保が想定通りの時間でできるか• 仮想マシンイメージをネットワーク越しに転送するのは、その時の回線状況に依存するため、想定通りに行かない場合も考えられる• データ領域を移行させる場合は、ストレージ間コピーが有効だが、各サイトのストレージが異機種であるとコピーが難しい場合がある。
• 通常ストレージは内部の管理ネットワーク上に配置されているため、ストレージ間をつなぐ場合はネットワークセキュリティを予め考慮に入れておく必要がある。
それよりも、平常時に連携元クラウドサービスと連携先クラウドサービスの双方に必要な仮想マシン、ストレージ領域、回線帯域を確保しておき、一定の間隔で両サービス間のデータ同期を実施し、大規模災害発生に備えておく方が、予め決められた RTO/RPO を守ることが可能であり、特に重要インフラ・業務における事業継続を前提とする場合は、この②の方式が妥当だと考える。以下では②の方式をベースに、クラウド間連携がスムーズに
84

RTO:Recovery Time Objective（復旧目標時間）障害発生前の状態に回復するまでに許容される時間。シス
テム停止が許容される時間。
RPO:Recovery Point Objective（復旧目標地点）障害発生前の「いつ」の状態に復旧するかという目標。RPO
以降障害発生までのデータ等は復旧できないため、失われるデータ等の許容される範囲を定めることとなる。

171

実現するための技術的要件について述べる。
3.1.4. 具体的な技術要件
前項の②の方式を前提におき、具体的な技術要件についてまとめる。検討対象として、単一の IaaS における主な構成要素である、「リソース」、「サービスマネジメント」、「セキュリティ」について、以下の要素を取り上げた。
＜リソース＞
・クライアント向け回線（インターネットなど）
・仮想マシン・ハイパーバイザー
・ネットワーク（LAN）
・ストレージ＜サービスマネジメント＞
・運用
・セキュリティ
また、クラウド事業者間連携に必要な要件として、「ポータビリティ」、「相互運用性」が挙げられる 85。これらの組合せによる技術的要件は図表 104 のようにまとめられる。

図表 105 クラウド間連携実現のための具体的な技術要件
クラウド単体の構成要素
クライアント向け
ネットワーク（インターネットなど）

サーバ（仮想化技術）

ネットワーククラウド間連携に必要な要素
ポータビリティ

相互運用性（プロビジョニング含む）―

 災害時、利用者から他のクラウドサービスへのアクセスが動的に切り替わること
 災害復旧時、利用者が元のクラウドサービスにアクセスできるよう動的に切り戻ること

 クラウドサービス間の仮想化
環境の差異を吸収すべく、OVF のような標準化された
フォーマット及びインターフ
ェイスを用いること

 連携元クラウドサービスから連携先クラウド事業者へサービス提供に必要なリソースの構成情報とサービスのデータを、自律的に転送できること
 連携元クラウドサービスにて、上記リソースの構成情報とサービスのデータの更新が発生した際は、適宜差分を連携
先クラウドサービスへ自律的に転送できること

 クラウドサービス間で仮想マシンの移行ができるよう、プライベートアドレスが重複しないようにすること
 プライベートアドレスが重複する場合でも、中間で IP ア
ドレス変換するなど、問題な
くクラウドサービス間でルー
ティングができ、移行先に問題なく、仮想マシンイメージ

 異なるクラウド事業者間で、ストレージ内データ、仮想マシ
ンデータをスムーズに移行できるよう、遅延を考慮した回線
帯域を、クラウドサービス事業の成長に合わせ、双方の事業者で随時検討すること
 クラウドサービス間通信において、圧縮技術等を用いて、データ通信時間を短縮すること クラウドサービス間にてある程度大容量のデータ転送が発生する。ネットワークの負荷状況によって、重要度の高い通信は優先して転送できるようにしておくこと

85

GICTF 副会長の後藤厚宏情報セキュリティ大学院大学教授資料「インタークラウド時代に向けて～GICTF と国際標準化～」より

172

クラウド単体の構成要素

クラウド間連携に必要な要素
ポータビリティ

相互運用性（プロビジョニング含む）

含めデータ転送できること

ストレージ 異なるクラウド事業者間で、ストレージ内データをスムーズに移行できること

 連携元クラウドサービスから連携先クラウド事業者へサービス提供に必要なリソースの構成情報とサービスのデータを、自律的に転送できること
 連携元クラウドサービスにて、上記リソースの構成情報とサービスのデータの更新が発生した際は、適宜差分を連携
先クラウドサービスへ自律的に転送できること―

 連携するお互いのクラウドサービスの各種監視（死活・サービス・リソース・設定）を定期的にできるように、監視プロトコ
ルや各種パラメータを統一しておくこと クラウドサービス間にてデータ同期が正常に行われているか監視できるようにすること
 クラウドサービス間のネットワーク遅延状況を監視できるよう
にすること

―

 連携するクラウドサービス間において、クラウド間連携に支障をきたす障害については、適宜情報交換できるようにす
ること― 連携するクラウドサービス間において、最低限必要な構成情報についてお互い管理できるようにすること
 連携するクラウドサービス間において、時刻同期を実施し
ておくこと

―

 切替指示後、速やかに他クラウドサービスへ切替できるように、必要な作業については、ある程度自動化しておくこと
 切戻し指示後、速やかに元のクラウドサービスへ切り戻しできるように、必要な作業については、ある程度自動化しておくこと― リソースを利用開始した際に起動した仮想マシンやアプリケーションなどの停止やリソース管理情報の更新、移行した
データの完全消去もしくは回収を行えること―

 認証情報のやりとりが可能なこと(シングルサインオン）
 初回認証においては、ワンタイムパスワードや二要素認証などセキュリティ強度の高い認証方式を用いること― 利用者～クラウドサービス間通信において、安全にデータ通信が行われること（双方向で安全性確認）
 利用者～クラウドサービス間通信において、不特定多数か
らのサイバーアタックを防ぐこと
 連携するクラウドサービス間通信において、通信要件のある通信のみ許可すること

監視

障害管理
運
用

構成管理

切替、
切戻し

リソース解
放

認証
セキュリティ

ネットワー
ク出所）GICTF の WhitePaper「インタークラウドのユースケースと機能要件」、インタビュー等より NRI 作成

同図表の各項目について検討された、相互運用性およびポータビリティの確保に必要な主要な技術的要件は以下の通りとなる。
（1） クライアント向け回線（インターネットなど）
災害時、災害復旧時にクライアントから各クラウドサービスにスムーズにアクセスする方式を検討する必要がある。具体的には、DNS バランシングや CDN（Contents Delivery

173

Network）などを用いて、利用者から異なるクラウドサービスへのアクセスに関して動的に切り替え/切り戻しが可能であることが必要となる。
（2） サーバ（仮想化技術）
ポータビリティの確保については、異なるクラウド事業者の仮想化環境であっても、スムーズに仮想マシンイメージを移行できる環境が望ましい。その場合、標準化され現場での利用が多い OVF の利用が想定される。
また、相互運用性の確保については、災害時は運転要員の操作・処理が的確に行えな
いことも考えられるので、必要なデータ（仮想マシンイメージ等）が自動的に転送されることが望ましい。また、仮想マシンの構成情報は随時更新されるため、平常時に定期的にバックアップを取得し、連携先クラウドサービスへ同期を行う必要がある。
（3） ネットワーク
クラウド間をつなぐネットワークにおけるポータビリティの確保にあたっては、「IP アドレス」
が各ネットワーク部分において重複しないことが望ましい。仮に重複する場合は、クラウド
間ネットワークの中間で IP アドレス変換するなど、クラウドサービス間でルーティングを問
題なく行い、移行先に問題なく、仮想マシンイメージを含めたデータ転送できることが必要となる。
また、各クラウドサービス内ネットワーク（LAN）とクラウド間をつなぐネットワークにおける相互運用性の確保にあたっては、仮想マシンおよびストレージ内のデータ転送が発生するため、RTO を順守するために遅延を考慮した回線帯域を、クラウドサービス事業の成長に合わせ、双方の事業者で随時検討することが求められる。
また、クラウド間で大容量のデータを送信する場合は、データを圧縮して、回線帯域を抑える方式も考えられる。圧縮にあたっては、専用装置導入等、費用が別途発生するが、回線帯域を抑えることにより、回線費用の削減も見込むことができる。両方を比較し、中長期で考えた時に安価になるのであれば、データ圧縮も検討に入れてもいいのではないかと考える。
（4） ストレージ
ポータビリティの確保については、異なるデータセンター間での転送であっても、スムー
ズにストレージ内データを移行できる環境が望ましい。
また、相互運用性の確保に当たっては、ストレージ内データが自動的に転送されることが望ましい。さらに、ストレージ内データは適宜更新されるため、平常時に定期的にバックアップを取得し、連携先クラウドサービスへ同期を行う必要がある。
（5） 運用GICTF の WhitePaper「インタークラウドのユースケースと機能要件」に記載されている
10 の機能のうち、「監視」「切り替え、切り戻し」「リソース解放」の 3 機能に加え、「障害管理」

174

「構成管理」についても、各々クラウド間連携を実現し運用するための要件が整っている必
要がある。
（6） セキュリティ
セキュリティの相互運用性について、「認証」および「ネットワークセキュリティ」の観点か
ら、以下の確保が必要となる。
「認証」について、ユーザの利便性を考えると、異なるクラウド間で ID・パスワード情報を共有し、かつ複数回の認証を避けるため、シングルサインオンの適用が考えられる。その際に、初回の認証対象となるアプリケーションあるいは OS に関するセキュリティ強度が求められる。そのため、ワンタイムパスワードもしくは二要素認証などセキュリティ強度を挙げる方式を合わせて検討する必要がある。
「ネットワークセキュリティ」について、クラウド間をインターネットで繋ぐことを想定した場
合、インターネット通信部分の暗号化や、インターネットから各クラウドサービスへのサイバ
ー攻撃への対策が必要となる。
3.1.5. クラウド間連携におけるセキュリティを阻害する可能性のある要素
クラウド間連携におけるセキュリティの阻害要素は、2 種類があると考えられる。
まず、クラウド間連携によって本来はデータセンター内で保護されているデータが外部
ネットワークで伝送されることに起因するものである。これは、外部ネットワーク伝送中におけるデータ漏洩、盗聴、毀損が考えられる。これらは、リソース確保、発見時、データ同期のためのデータ転送時、相互サービス監視時、認証連携時の各段階で発生する恐れがある。
もう一つのセキュリティ阻害要素として、保護されているデータを外部ネットワークに伝送する際に、本来保護されている機器（主にストレージ）を外部ネットワークに接続する場合があり、その際にセキュリティ設定の不備により、外部からの攻撃を受ける可能性があるということが考えられる。

3.2. クラウド間連携における契約や取り決め等の要件
3.2.1. クラウド間連携における事業者間の取り決めや契約条件
本章 2 節において各事業者のクラウド間連携に対する認識を把握したが、そこからうかがえる課題をまとめると、「事業者間で異なる契約、サービス価格、サービス仕様（セキュリ
ティポリシー含む）、クラウド構成（データモデル、各種 API 等）の差異をどう解決するか」である。裏返すと、課題と思われる差異の部分について、予め事業者間で取り決めをしておくことで、異なるクラウド事業者間連携がスムーズに行われるのではないかと考えられる。契約、サービス価格、サービス仕様について、何かガイドライン的なものがあるわけではなく、それよりも競争原理による差別化志向が出てくるため、当然内容は違うものになる。また、175

構成面において、前に述べた各クラウド標準化団体が策定した共通仕様を各クラウド事業者が採用していれば問題ないが、実際には事業者に受け入れられているものと、そうでな
いものと、まだ混然としている状態であり、構成面においても事業者間の取り決めが必要となってくる。
一方、事業者からのインタビューでは出てこなかったが、事業者間連携を具体的に考えた時に、災害時の切り替えトリガをどうするかという取り決めが必要と考えられる。重要システムである場合は、事業者ではなく、行政による切り替えの発動も検討する必要がある。
以上の理由から、クラウド間連携を行う際に事業者間で取り決める必要のある内容は以下のようにまとめられる。それぞれ事業者間で前もって確認しておくことが重要である。
図表 106 クラウド間連携における事業者間の取り決めとその内容例
項目内容

クラウド間連携の発動• どのような場合に連携先に切り替えるかを定めておく必要がある。
• 重要インフラの管理システムの場合は、事業者間で定めるだけではなく、行政によって発動タイミングが決定される可能性がある。
• 連携するクラウドサービス間の SLA およびサービス仕様（外部向け、内部向けともに）の差

SLA および異がわかるように、お互いに開示するとともに、差異がわかるように標準的な様式を利用しサービス仕様• SLA およびサービス仕様取り決め後に変更があった場合は、変更したことが速やかに連携て示す必要がある。
先にわかるようにする必要がある。
• 連携元と連携先のセキュリティポリシーを完全に一致させるか、最低ラインのみを適合させセキュリティ
ポリシー

るか定める。
• 連携のためにセキュリティポリシーを開示することにより、連携先クラウド事業者からのセキュ
リティアタックが発生した場合に備えて、別途契約を取り交わしておく。

ビジネスモデル
データモデル
各種 API• 連携を行った場合の費用と収益の配分ルールを前もって定めておく必要がある。
• 連携するデータ構造やデータの配置場所等（ローカルディスク、NAS など）を取り決める必要がある• クラウドサービス切り替え時に必要なアクション（VM 起動やデータ転送等）を自動化するために、各サービスで設定されている API 情報を相互に公開する必要がある。

3.2.2. データセンター間連携やクラウド間マイグレーション実施時に、クラウドサービスの利用契約が事業者間で移転することもしくは再委託の構造が発生することに関する利用契約上の条件や規定事項
前項の取り決めを事業者間で確認するのみならず、クラウド間連携を行う予定のあるシ
ステムのユーザに対しても告知する必要がある。そのために、利用契約や約款等をデータセンター間連携やクラウド間マイグレーションを行う前提で取り交わす必要がある。
ユーザに提示する必要があると思われる項目は以下のものである。
• クラウド間連携を実施することに関する基本的な合意の規定

176• 実施の条件（どのような条件で実施するのか）（例） 法令で定める「激甚」に相当する大規模災害の発生した場合
安定的な電力供給が確保できない場合

等• 連携先（再委託先）の条件（例） 契約時に指定した事業者に限定する。
有事において、クラウド事業者と利用者の合意に基づき決定する。
• 連携時におけるサービス水準• 個人情報、知的財産等の機密情報の取扱いに関する規定• 料金に関する規程（サービスの範囲内か、追加料金が発生するのか、その場合どのような料金体系となるのか）
なお、もとの利用契約がライセンス契約、業務請負契約、準委任契約、といった契約形態のどれに該当するかによって、条件や規程事項は変わりうることに留意が必要である。
すなわち、ライセンス契約や業務請負契約の場合、事前にすべて規定しておく必要がある
一方、準委任契約の場合は、状況に応じた対応が可能で、柔軟に運用することが可能とされている。
図表 107 契約形態別の留意事項
請負契約

準委任契約

特徴
（関連法規）

根拠法：民法
委託先の特定個人ではなく組織としての総合力を期待しての契約。

根拠法：民法完成責任はないが、進捗報告義務、終了報告義務、善管義務がある。

業務内容

受託者が一定の業務を完成してその結果に対して発注者が報酬を支払う。完成の判断は、成果物の検査合格または報告書の確認。

発注者が一定の業務処理を一任し、受託者がそれを承諾し、善管義務をもって業務を処理
する。

瑕疵担保責
任

受託者は期限内で補修や損害賠償などの担
保責任を負う。ただし契約により変更可能である。

善良なる管理注意義務をもって遂行すればよく、瑕疵担保責任はない。

出所）長尾清一「先制型プロジェクト・マネジメント」ダイアモンド社より、NRI 作成

3.2.3. データセンター間連携やクラウド間マイグレーションの際に障害となりうる民法その他の法令上の制約と、その回避のために整えられるべき条件
データセンター間連携やクラウド間マイグレーションの際に法制度上障害となり得るのは民法では「瑕疵担保責任」と「緊急避難」の条項であると考えられる。業務請負契約の場合、クラウド間連携を実施したが、期待したレベルのサービスを提供できなかった場合、どこまで瑕疵担保責任が問われるかが不明確になる恐れがある。このため、事前にサービスレベ
ル契約等で、明示的に条件設定をしてリスクを回避することが必要であると考えられる。
また、有事の際にクラウド間連携を行うことが、緊急避難に該当するかどうかは、事案ご

177

とに状況が異なるため、一律に該当・被害等を決定することができない。その結果判断基
準や結果責任が曖昧になる可能性がある。そのため、契約でクラウド間連携をする場合の条件を明示することで、曖昧さを回避することが求められる。
民法以外の法令においては、個人情報保護法、著作権法、不正競争防止法、消費者契約法がデータセンター間連携やクラウド間マイグレーションの際の制約条件となる可能性がある。以下その可能性の概要について記す。86
個人情報保護法
個人情報保護法においては、第三者提供の禁止規定が存在するため、個人データを含んだ情報を事後的に第三者の管理下に置くことが困難と考えられる。そのため、事前に、クラウド間連携を行うことを、ユーザ企業だけでなく、エンドユーザにも利用契約の中で包括的に同意を取得しておく必要があるものと考えられる。
著作権法
著作権法では、著作権者に「複製」と「公衆送信」を行う権利を与えているため、著作権者の許諾無くコンテンツを複製したり、インターネットを通じて不特定多数の者に当該コンテンツを配信したりする行為は禁じられている。クラウドに格納するデータが著作物性を持つかどうか事前に確認が必要である。
不正競争防止法
不正競争防止法では、秘密として管理され、非公知、かつ有用な情報を「営業秘密」と定義し、同情報を不正に取り扱う行為を不正競争としている。クラウド間連携等の際にはセキュリティを確保して、同法に抵触しないよう留意が求められる。
消費者契約法
消費者契約法では、消費者との契約において、事業者の損害賠償の責任を免除する条項の無効が規定されている。すなわち消費者保護の観点から、利用規約で免責事項を定めていても、同法によって無効とされることがありうるということである。Web メールのように、消費者に直接提供しているクラウドサービスに適用されることが想定される。

3.2.4. 異なる司法管轄にあるデータセンターまたは事業者間で行われるときに、移行・移転の前と同等の、利用者にとっての法令上の権利義務等が確保されるために必要な国際連携に関する要件

86

岡村久道「クラウドコンピューティングの法律」民事法研究会（2012 年 2 月）を参考に作成

178

データセンターの位置によって一義的に準拠法が定まることは通常ないと考えられるので、国際司法・国際裁判管轄の規程については、契約によって明示することが必要である。
このことにより、準拠法の指定を明確にして移行・移転前と同等の権利義務等を確保することが求められる。
しかしながら、準拠法、管轄裁判所の指定を契約書上で合意しても、データセンターが外国に所在する場合、同所在国の警察等の執行機関による捜索・差し押さえリスクは残る。
そのため、捜索・差し押さえリスクを受容できる国に所在するデータセンターへ移行・移転することが望ましい。
クラウドにおいては、データの所有権、データの管理責任、サービスの提供・利用契約、設備の貸与・利用契約等、権利や契約の関係が複雑になる。これらが複数の司法管轄にまたがって締結され、存在する状態も容易に想定される。クラウドの円滑な利用、緊急時の柔軟なマイグレーションや総合運用を考えた場合、国際的に一律な法的解釈や取り扱いがなされれば、事業者もユーザもその提供・利用をより積極化でき、クラウドの信頼性を高めるのに資することになる。このような国際的取り決めの実現に向けた取り組みが提起され、推進されることが期待されるところである。

179

IV.
1.

今後官民が取り組むべき課題の提起
クラウド事業者およびその他の事業者、社会システムが満たすべき要件の全体像
今まで見てきたように、クラウドは人々のコミュニケーションや企業活動の基盤、あるいは社会の重要なインフラストラクチャーを管理・運営する情報システムの基盤として多くの場面で使われるようになった。また、先の東日本大震災においても被災したシステムの代替サービスや刻々と変化するニーズに対応した情報サービスの提供を迅速に行うことができ、クラウドの持つ特性が緊急時において有効であることが明らかとなった。
さらに、今回の災害においては、一部で小規模な被害はあったものの、主要なクラウド
データセンターではサービスの継続ができたことで、大規模災害におけるクラウドの可用性の高さが改めて示されている。
しかしながら、併せて課題も明らかとなった。クラウドのデータセンターそのものは被害が少なかったものの、長時間の停電や計画停電の実施で自家発電燃料の確保が難しくなるケースも見られた。また、ユーザ環境やユーザからのアクセス回線が被災または停電したりすることによって、データセンターは稼働しているもののサービスが利用できないケースがあった。
以上のことから、分散的に処理されるために本来は災害等のインシデントに強いクラウドの可用性を高めるために次のことが必要になるものと考えられる。
まずクラウド事業者・データセンター事業者の対応としては、クラウドのサービス維持能力の強化を図ることが望まれる。具体的にはデータセンターの BCP、ライフラインの強化等を行うことである。次に、通信事業者の対応としては、データセンターとユーザ間の通信回線の可用性の確保であり、そのための通信網の耐災性の強化が求められる。さらにユーザの取り組みとして求められるのは、利用場所の安全性の確保やデータバックアップ等である。
また、これらの施策を講じたとしても、クラウドサービスそのものが利用できなくなる事態も想定される。その場合にはクラウドをまたがったシステムやデータのバックアップ、さらには他のクラウドでのシステム稼働なども想定しなければならない。
しかし、これらを進めていく上では、社会全体としてクラウドサービスが重要な位置を占めていることを認知した上で、災害や異常事態に対する対応の中で一定程度の優先度をもって対応することへのコンセンサスを得る必要があるものと考えられる。
これらのことを図示すると図表 107 のように示される。

180

図表 108 クラウドのサービス継続・障害対応を強化するための全体像
クラウドサービス
アクセス回線

クラウドサービス

クラウドサービス事業者の連携•事業者をまたぐクラウド
連携• マイグレーション• データバックアップ• クラウド間の接続• サービスレベル•情報セキュリティ
• ウイルス、不正アク
セス等

ユーザ環境

ユーザの対応クラウドサービス事業者／DC事業者の対応•DCのサービスレベル確保、BCP• 建屋の安全性• ライフライン向け電源、空調等• オペレータ：召集、食料・飲料水等• データバックアップ•緊急時のサービス提供／トリアージ•情報セキュリティ
• ウイルス、不正アクセス等

通信事業者の対応•BCP• 通信経路の確保• 局舎、基地局等の機能確保• ライフライン：電源、空調等• BCP•情報セキュリティ
• ウイルス、不正アクセス等•BCP• 利用場所の安全性• ライフライン：電源、空調、通信等• ユーザ：召集、食料・飲料水等• データバックアップ•情報セキュリティ
• ウイルス、不正アクセ
ス等

社会システムとしての対応
上記要件を満たすためのルール・基準
社会全体のリソースマネジメントの観点からのクラウドサービスの位置付け
技術的標準・基準 緊急時優先対応のための判断基準のコンセンサス

2.

官民が取り組むべき課題

2.1. 基本的な考え方
事業者、利用者等の個別の取り組みを促進するために、社会全体として取り組まねばな
らないことは以下の 3 つであると考えられる。

2.1.1. クラウドの社会インフラとしての明確化
クラウドが社会に徐々に浸透していることは実態調査で明らかになった。しかしながら、クラウドはユーザからは見えにくい。そのため、社会全体から見たときに、クラウドが担っている役割が過小評価される可能性がある。現状においても、事業継続性の確保が事業者やユーザなどの民間企業の努力のみに委ねられている状態にあると見られる。
そのため、クラウドが国民生活を支えており、社会システムや重要インフラの運用を担っている、社会のインフラであるとの位置づけを明確化することがまず重要であると考えられる。
たとえば、重要インフラを支えるクラウドや国民の生活やコミュニケーションに不可欠なクラウドなどについては、電力、上下水道や電話ネットワークと同様に、防災計画など、緊急181

事態に備えた計画に盛り込み、そのサービス確保を社会全体として行うべき課題と位置づけていくことなどの方策が考えられる。
また、今後参入事業者が増加するにつれて高まるサービス停止リスクに備え、現行の情報開示制度をさらに充実させるとともに、保険や供託金、代替サービス紹介などの社会的なセイフティネットの整備も望まれる。
2.1.2. 多様な災害・障害に対応するためのサービスの優先順位付け
今回の東日本大震災でも、事前の被災想定を越える規模の災害が発生した。今回は、クラウドを支えるデータセンターに大きな被害はなかったものの、地震だけではなく、水害、
火災、サイバー攻撃等の多様な災害・障害要因が発生しうる。また、その大きさも発生地点も様々であると考えられる。
これらすべてのリスクについて、あらかじめ対応計画を立案することは非現実的である。
そこで、前もってどのサービスをどの程度まもる必要があるか、守るべきかについて優先順
位とサービスを確保する範囲を定め、それについて社会的な合意を得ておくことが望まれる。
具体的には、社会インフラ、企業の業務インフラ、国民のコミュニケーション等を支えるク
ラウドそれぞれについて、最低限維持すべきサービスレベルを規定するとともに、必要最小限までに縮退させる順位付けとそれぞれのサービスにおける BCP の強化を図ることが望ましい。
2.1.3. クラウド間連携に向けた社会制度の確立
クラウド間連携は、まだ国内でも先進的な取り組みが始まったところであるが、BCP や災害対応を考えたときに有力な手段であると考えられる。また、オンプレミスのシステムのバッ
クアップとしてクラウド連携を用いる考え方も徐々に出てきている。
欧米ではビジネス上の制約から、クラウド間連携の取り組みが進んでいない中、日本の被災経験などを活かして、国際的な取り組みに貢献し、たとえば標準化活動を牽引していくことには大いに意義があると考えられる。
また、クラウド間連携の技術的な側面のみならず、事業者間の契約、取り決めやユーザと事業者間の契約、さらには現状で障壁になる恐れのある個人情報保護法、著作権法、
不正競争防止法、消費者契約法等の見直しを行って、クラウド間連携を前提とした制度設計を進めていくべきである。
図表 109 クラウドのサービス継続性確保に向けて官民が取り組むべき課題

社会インフラとしての位置づけの明確化

課題

取り組みの方向性• 行政の防災担当者がクラウドコンピュー
ティングが重要インフラを担っていることをあまり認知していない• 事業継続性が民間企業の努力にのみ委ねられている• 重要インフラを担うクラウドの「防災計画」
等への組み込み• 社会インフラとして重要度を増すクラウドの一部を重要インフラと位置付けて、然るべき対応を組み込むこと182

多様な災害・障害に対応するためのサー
ビスの優先順位づけ• あらゆるリスクに対応して前もって対策を立案することは不可能• 「想定外」の事態に備える必要がある• クラウドサービス全体としての BCP の確立• 災害・障害発生等緊急時の対応に関する優先順位付けの考え方の確立と社会のコンセンサス獲得（トリアージ）

クラウド間連携に向けた社会制度の確立• クラウド間連携については日本以外での検討は進んでいない• 国際規格策定に向けた日本のリーダシッ
プの発揮• SLA、契約、個人情報保護制度などを、
クラウド間連携を前提として見直し

2.2. 具体的な施策
最後に、クラウドサービス継続やデータセンター間連携、クラウド間マイグレーションの実現のためにそれぞれの主体が行っていくべきことをまとめる。

2.2.1. サービス継続のための施策
サービス継続のためには、クラウド事業者は自らの BCP の強化を行っていくとともに、通信事業者等の関連事業者と協力して、エンドユーザ環境まで視野に入れたサービス継続手段の検討を進めるべきである。特に、中小企業等で IT 管理力の高くないユーザに対しては、サービスベンダーとして積極的に提案していくことが望ましい。このことは提供するサービスの価値を高めることにもつながるが、ユーザ側のコスト低減ニーズとのバランスを考える必要がある。
ライフライン事業者等の関連事業者についても、自らの BCP を強化するとともに、二次サプライのサプライヤを中心に、特に重要インフラを担うクラウドに対して、優先的にライフラインの確保を行うことを検討すべきである。優先順位づけに当たっては、関係ステークホ
ルダーの合意形成が必要となるため、行政からもサポートが提供される中で進めていくことが望まれる。
ユーザ企業においてもクラウド事業者と協力の上、BCP を強化すべきである。
一方、社会全体については前述したように、クラウドを防災やリスク対応の枠組みに位置づけ、たとえば行政が策定する防災計画の中でサービス確保のための支援方策について検討していくべきであると考えられる。また、セイフティネットの整備にあたっても行政に期待される役割は大きいものと考えられる。
2.2.2. データセンター間連携、クラウド間マイグレーション実現のための施策
クラウド事業者自ら、または業界団体が標準規格を整備したり、データセンター間連携、
クラウド間マイグレーション（移転）に当たっての SLA、契約ならびに規約等の整備を進めていくことが望ましい。また、技術的な適用可能性を検証するため、技術実証を行って実運用の早期の実現を目指すことが期待される。
また、行政は業界が行う上記の取り組みを支援するとともに、実現の阻害要因となり得る

183

個人情報保護等の法制度について、クラウドならびにその連携を前提としたものに見直しを行ったり、商習慣等を同様に変革していくに際しての先導的な役割を担ったりすることが望まれる。
図表 110 サービス継続、クラウド間連携のための具体的な施策
データセンター間連携
クラウド間マイグレーション（移転）サービス継続クラウド事業者•

BCP の強化•

エンドユーザ環境まで視野に入れたサー
ビス継続の検討•
関連事業者（ライフライン
等）
通信事業者
ユーザ

行政
社会全体

情報開示の強化•

BCP の強化•

重要インフラを担うクラウドに対する優先度•

BCP の強化•クラウド向け通信サービスの優先提供•

標準規格の制定・採用•

SLA／契約／規約の整備•

技術検証と実運用の実現

－

の向上
•

•

BCP の強化•

防災、リスク対応の枠組みへのクラウドの通信路の確保・優先提供
－

位置づけ
•

クラウド間マイグレーション（移転）のための情報開示、セイフティネット構築等の業界の取り組みの支援•

技術規格化、標準化等の業界の取り組みの支援•

個人情報保護等の第三者提供禁止規定などの法制度について、クラウド間連携を可能にすることを視野に入れて見直す

184

おわりに
以上見てきたように、クラウドコンピューティングは社会に浸透しつつあり、今後電力や電話、水道、交通のような社会基盤サービスとして位置づけられていくものと予測される。
また、分散処理、仮想化という特性を活かして大規模災害時の対応でも威力を発揮することが明らかとなった。
しかしながら、クラウドコンピューティングは発展途上の技術であり、技術開発の面およ
びそれをサービスとして社会に適用していく面の双方において、解決すべき課題が存在することも明らかとなっている。たとえば、災害時におけるクラウドサービスの運用継続性においては電源を中心としたライフラインやその代替サプライにおいて課題を残しているし、
クラウド事業者をまたがったシステムやデータの連携、マイグレーションについても検討の途上である。特にデータセンター間連携やクラウド間マイグレーションについては我が国での検討が先行していると考えられ、国際的な貢献も期待される。
また、社会的な合意形成や制度構築も求められる。災害や障害時におけるリソース制約
下では、ある程度の縮退運用を行う必要がある。個別のサービスでの事前の条件設定はもちろん必要だが、大規模災害等では複数のユーザ、サービスのうちどれを優先的にサービス継続させるかについて、社会的な合意形成が必要である。これにあたっては行政が主導となって優先順位を検討していくことが望まれる。
さらに、中小事業者等を含めた品質保証、品質管理の在り方についても社会システムの整備が求められる。ユーザが安心してサービスを選択するための事前情報開示はもちろん、品質を保証するための認証等の制度の創設や、サービス停止や事業者の破綻などの際のセイフティネット構築等、業界や行政等が連携して検討を進めていくことが求められる。
このように、技術面、社会制度面の両面からクラウドを安心、安全に利用できる環境を整備していくことで、クラウドが社会に普及するとともに、IT による効率化や付加価値の向上
等の恩恵を広く享受できるようになると期待される。クラウドは、社会インフラを担い、緊急時には平時の機能を維持・回復するだけでなく、緊急時に新たに発生するニーズへの対応が期待できる。これは、クラウドの耐災性、拡張性、迅速性などの特性によって可能になる社会的機能と言える。
同時に、社会を支えるインフラの一環を担うクラウドコンピューティングの、万一の事故や停止が社会に及ぼす影響はそれだけ大きくなる。それを最小限にできるような技術や仕組みの構築、進化が進むことを期待したい。
本報告書がその検討の端緒となり、条件・環境整備の一助となれば幸いである。
以上

185