平成 25 年度

文部科学省

科学技術試験研究委託事業
次世代 IT 基盤構築のための研究開発（ビッグデータ利活用のためのシステム研究等）『アカデミッククラウド環境構築に係るシステム研究』

コミュニティで紡ぐ次世代大学 ICT 環境としてのアカデミッククラウド
成果報告書

平成２６年 5 月
国立大学法人九州大学

本報告書は、文部科学省の科学技術試験研究委託事業による委託業務として、国立大学法人九州大学、が実施した
平成２５年度「コミュニティで紡ぐ次世代大学 ICT 環境としてのアカデミッククラウド」の成果を取りまとめたもの
です。

2

目

次

Ⅰ. 委託業務の目的 ··········································································· 4
Ⅱ. 実施計画 ···················································································· 5
Ⅲ. 実施内容（成果） ········································································ 12① コンテンツ、大学経営およびシステムアーキテクチャに係るアカデミッククラウド
システムの調査検討 ·········································································· 12② セキュリティに係るアカデミッククラウドシステムの調査検討················ 44③ 事務支援に係るアカデミッククラウドシステムの調査検討 ····················· 74④ 教育支援に係るアカデミッククラウドシステムの調査検討 ····················· 85⑤ 認証連携に係るアカデミッククラウドシステムの調査検討 ····················· 124⑥ データプライバシーに係るアカデミッククラウドシステムの調査検討 ······· 151⑦ ネットワークに係るアカデミッククラウドシステムの調査検討················ 197⑧ 研究支援に係るアカデミッククラウドシステムの調査検討 ····················· 221⑨ 事業の総合的推進 ········································································· 239
Ⅳ. 参考文献 ···················································································· 240
Ⅴ. 成果の外部への発表 ····································································· 242
Ⅵ. 活動（運営委員会等の活動等） ······················································· 244
Ⅶ. 実施体制 ··················································································· 247
資料 1. アンケート集計結果 ································································· 249
資料 2. アカデミッククラウドに関する事例調査 ······································ 444
資料 3. 本事業に係る調査，報告書等資料 ··············································· 484
資料 4. キックオフシンポジウム・パネルディスカッション議事録 ··············· 485
資料 5. 中間報告会パネルディスカッション議事録 ··································· 487
資料 6. 最終報告会ディスカッションセッション議事録 ····························· 494
資料 7. アドバイザリー名簿 ································································· 502
用語集···························································································· 503

別添資料 1. クラウドサービス利用ガイドラインチェックリスト.PDF
3

Ⅰ. 委託業務の目的
本事業では、大学において ICT に関わる様々な立場の人々が集うコミュニティに依拠しながら全国の国公私立大学 783 校（平成 24 年度現在）を対象にした調査を行い、研究・教育・管理運営等に関わるデータの量・分布を明らかにする。そして、調査結果をもとに、アカデミッククラウドシステムのあるべき方向性と実現手段を検討し、複数の標準仕様を策定する。
現在、大学におけるクラウド化は、集約化・共有化によるサーバ管理コストの圧縮を主眼として大きな潮流になりつつある。大学間連携により地域での ICT 基盤の共有を実現する場合も、集約化・共有化により効率化を目指す側面が強い。しかしながら、教育研究の質的向上や事務・大学経営の高度化のためには、各種サーバ群の集約化・共有化
を通じて形成される巨大なデータの利活用を可能とする革新的な枠組みが必要である。
これこそが、アカデミッククラウドシステムが備えるべき要件であり、ビッグデータ時
代の大学間連携の姿である。このため、事業の実施に際しては、国立大学法人九州大学
を中核機関として、参画機関である国立大学法人広島大学、国立大学法人大阪大学、国立大学法人京都大学、大学共同利用機関法人国立情報学研究所、学校法人慶應義塾大学、
国立大学法人東北大学、国立大学法人北海道大学と密接に連携し、再委託により本事業を推進する。

4

Ⅱ. 実施計画
アカデミッククラウドシステムの構築においては、情報通信技術の移り変わりが激しい中で、各大学に共通するニーズを的確に見極め、実際に使われる様々なクラウドサー
ビスを継続的に開発していく必要がある。このためには、国公私立あるは研究大学・教育大学など、様々な形態・機能の大学の中で生じる多様なニーズを的確に掴み、小さな成功を積み重ねながら継続的かつ建設的にクラウドサービスを開発・運用可能なアカデ
ミッククラウドシステムを構築することが必要である。この観点から、本事業では、大学 ICT 推進協議会と連携して国内外の様々なコミュニティエンゲージメントを明確に行いながら、事業代表機関を中核とした事業推進グループと研究・教育・コンテンツ・
事務・大学経営・システムアーキテクチャ・セキュリティ・プライバシ・ネットワーク・
認証連携の 10 分野を担当する参画機関の研究者で構成されるシステム研究グループを構成し、調査内容作成フェーズ・調査実施フェーズ・調査結果分析フェーズを通じてコ
ミュニティエンゲージメントを明確にしながらアカデミッククラウドシステムのあるべき方向性とその実現手段の可能性について調査する。
調査内容作成フェーズでは、文部科学省学術情報基盤実態調査や EDUCAUSE Core
Data Service などの国内外の大学 ICT に関わる既存調査結果や、「ビッグデータ時代におけるアカデミアの挑戦」などのアカデミッククラウドシステムに関わる既存の知見をもとに、各分担分野における研究者の知見を加味しながら、アカデミッククラウドシス
テム構築に向けて想定される課題を事前に明確化し、調査内容を整理する。そして、大学 ICT 推進協議会会員大学 61 校や全国共同利用情報基盤センター長会議に対する照会や個別インタビュー、CIO 部会での議論を通じて調査内容に対する意見聴取や外部有識者からの意見聴取を行うとともに、国内・海外事例調査を実施し、国内外の最新の状況も考慮しながら調査内容の確定を行う。また、並行して、基盤・サービスの両観点か
ら技術標準に関する仕様検討を行い、その一部を調査内容にも反映させるとともに、海外事例調査等を通じて標準仕様策定に向けた準備を行う。
調査実施フェーズでは、国立大学法人九州大学に設置する本事業の事務局を窓口として、外部業者に委託して全国の国公私立大学 783 校（平成 24 年度現在）に対して大規模調査を実施・集計する。調査は、文部科学省学術情報基盤実態調査に準じた要領（平成24 年度: 対象は国公私立の計 778 大学、回収率は 100%、大学長宛に依頼）で 100%に近い回収率が得られるよう文部科学省の協力も得ながら実施する。
調査結果分析フェーズでは、調査結果に基づき、各分担分野においてアカデミッククラウドシステム構築に向けた課題を具体化・明確化するとともに、事業推進グループの技
術標準担当を中心に、アカデミッククラウドシステム構築に向けた複数の標準仕様案を
策定する。

5

なお、標準仕様は、少なくとも次の①～③の異なる構成のクラウド基盤について作成する。①特定の拠点を設けず、個々の大学がクラウド基盤を構築した上で連携する個別連
携型、②拠点大学を地域別に複数設定し、その拠点大学が周辺の大学等と連携してクラウド環境を構築する地域別拠点連携型、③特定の機関を全国の中核拠点と位置付け、その中核拠点にクラウド基盤を構築した上で、他の大学等と連携する全国中核拠点型。
また、上記の異なる構成のクラウド基盤の構築において、想定される定量的・定性的な波及効果の検討・試算、実現のためのプロセスについて検討する。
これらをまとめて、中間報告書を事業推進グループが中心となり作成し、12 月 18 日～
20 日に幕張メッセ国際会議場で開催される 2013 年度大学 ICT 推進協議会年次大会において公表する。年次大会では、本委託調査に関わる企画セッションを分担分野それぞれで企画する。このようなコミュニティエンゲージメントを通じて得られたフィードバックを反映しながら、分担分野ごとに報告書を執筆し、事業推進グループが取りまとめて最終報告書を作成する。
以下に、各分野における具体的な業務項目を示す。
① コンテンツ、大学経営およびシステムアーキテクチャに係るアカデミッククラウドシ
ステムの調査検討
教育支援、研究支援、事務系情報システム支援のためのセキュリティやプライバシーを考慮したアカデミッククラウドシステムの将来像を提案する。そのため、アンケート調査の実施、参画機関と連携した調査内容の整理・検討および仕様策定を以下にしたがって実施する。また、コンテンツの収集／管理・編集環境・検索／公開・利用環境の各項
目に関する仕様策定と大学経営・システムアーキテクチャに関する仕様策定を以下にしたがって実施する。各大学が個別に保有する電子化された教材や研究資料ならびに教職員の業績データや大学の財務データをデータベース化し、各大学が相互に利用可能とするアカデミッククラウドシステムを提案する。教育活動、研究活動、事務業務を通して生成されるすべての電子データを蓄積管理可能とするアカデミッククラウドのシステ
ム構成を提案する。大学が個別に管理運用するのではなく、同種・同分野のデータを仮想的に一元管理し、異なる分野のデータも含めすべての大学が相互利用可能とすること
により、複数分野および複数大学間での横断的な教育・研究活動、事務業務の効率化が図られ、新しい学問分野の創出も可能になると考えられる。
(a) 現状調査
本事業の事務局を設置する。参画機関と調査内容を検討した後、事務局が中心となって、外部委託によるアンケート調査の実施および調査内容の整理を行う。大学の情報システ
ムの物理的インフラおよび具体的なサービス、利用状況、データの種類と量、問題点等を明らかにする。
(b) 将来像の提案
6

現状の各大学の情報システムの物理的インフラと具体的なサービス等に関して調査した内容を担当分野ごとに整理・検討し、既存情報システムとの連携を考慮しつつ、かつ計算機リソースを有効かつ効率良く使用して上記の問題を解決するアカデミッックク
ラウドシステムを提案する。
(c) 技術課題の抽出と解決策の検討および仕様策定(b)で提案するアカデミッッククラウドシステムを実現するための、技術課題の抽出と、評価システムの開発等によるそれら課題の解決策を参画機関と連携して検討し、少なくとも個別連携型、地域別拠点連携型、全国中核拠点型についてそれぞれ仕様を策定する。
これらの異なる構成のクラウド基盤の構築において、コンテンツ、大学経営およびシス
テムアーキテクチャに係り想定される定量的・定性的な波及効果の検討・試算、実現のためのプロセスについても検討する。容易に解決できない多くの技術課題が明らかとなった場合には、研究課題として提案する。また，参画機関と連携し、再委託によって、以下の②～⑧の調査研究に取り組む。
② セキュリティに係るアカデミッククラウドシステムの調査検討（再委託先：国立大学
法人広島大学）以下に示す事項を実施し、アカデミッククラウドシステムに求められるセキュリティ要件に関し、少なくとも個別連携型、地域別拠点連携型、全国中核拠点型についてそれぞれ標準仕様を取りまとめる。これらの異なる構成のクラウド基盤の構築において、セキュリティに係り想定される定量的・定性的な波及効果の検討・試算、実現のためのプロセスについても検討する。
(a) 現状調査参画機関を含め、すでにいくつかのアカデミックな組織においてアカデミッククラウドが導入されている。アンケート調査等により、導入に至った経緯や導入前の検討項目、構築時の問題点や運用上の課題、BCP/DR 対策の検討状況等を調査する。
(b)課題の洗い出しと解決策の検討
前項において収集した問題点や課題を整理し、技術的課題については解決策の検討を行い、関連分野に対して提言を行う。一方、ポリシー的課題についてはセキュリティ評価を行って、推奨する対応策を提案する。
(c)ガイドラインおよびチェックリストの策定
前項の検討結果を踏まえ、アカデミックな組織自らが構築し、あるいは他組織が提供するサービスを利用してクラウドシステムを構築する際に確認すべきセキュリティ要件についてのガイドラインを策定する。またガイドラインへの対応状況を確認するためのチェックリストを作成する。

7

③ 事務支援に係るアカデミッククラウドシステムの調査検討（再委託先：国立大学法人
大阪大学）
以下の実施項目に沿って、事務分野のデータやシステムに関して調査内容、分析結果を取りまとめ、少なくとも個別連携型、地域別拠点連携型、全国中核拠点型のアカデミッ
ククラウドシステムについて、それぞれ標準仕様を策定する。これらの異なる構成のク
ラウド基盤の構築において、事務支援に係り想定される定量的・定性的な波及効果の検討・試算、実現のためのプロセスについても検討する。
(a) 調査内容の検討：事務分野全般に関連するデータの蓄積・運用状況やデータ特性に関する調査内容を検討するとともに、データ連携やシステム連携・統合によって効果が期待される対象を絞り込んだ上で、データ特性や課題に関する詳細な調査内容の検討を行い、事業推進チームを中心に実施する調査に反映する。また、国内外での事務分野におけるアカデミッククラウド構築事例を調査し、その状況を加味して調査内容を検討する。
(b) 調査結果の分析：調査結果をもとに、事務分野から見たアカデミッククラウド環境構築の課題や効果を明確化し、課題解決のための方策を検討する。また、他分野での分析・検討とも連携協力して、アカデミッククラウド環境としてあるべきシステムアーキ
テクチャを検討し、標準仕様へ反映する。
(c) 報告書の作成：上記 2 つの実施項目の内容をもとに、事務分野におけるアカデミッ
ククラウドの調査・分析・検討内容、および、標準仕様への提案を取りまとめ、報告書を作成する。
④ 教育支援に係るアカデミッククラウドシステムの調査検討（再委託先：国立大学法人
京都大学）
本事業では、コース管理システム・e ポートフォリオシステム・教務システムを通じて蓄積されつつある教育学習活動に係る現状と将来を調査するとともに、ビッグデータやクラウドに関する新しい潮流も対象にしながら、教育分野におけるアカデミッククラウ
ドシステムの構築に係るデータを調査する。調査結果に基づき、利活用のための方策を検討し、少なくとも個別連携型、地域別拠点連携型、全国中核拠点型についてそれぞれ標準仕様を策定する。これらの異なる構成のクラウド基盤の構築において、教育支援に関し想定される定量的・定性的な波及効果の検討・試算、実現のためのプロセスについても検討する。
(a) 教育学習活動に関するデータの現状調査とクラウドに関する潮流をもとにした今後の予測、及び、教育分野を対象としたアカデミッククラウドの標準仕様を策定する。
(b) 大阪大学における教務システムの導入・運用の経験を中心に、コース管理システ
ム・オープンコースウェア等に関する知見を活用した調査の検討・分析を行う。

8

(c) 東京大学におけるコース管理システムの構築・運用の経験を中心に、システムソフ
トウェアなどに関する知見を活用した調査の検討・分析を行う。
(d) 熊本大学における e ポートフォリオシステムの構築・運用の経験を中心に、コース
管理システム・教務システムなどに関する知見を活用した調査の検討・分析を行う。
(e) 名古屋工業大学における IC カードによる学生行動履歴分析の経験を中心に、コース管理システム・教務システムなどに関する知見を活用した調査の検討・分析を行う。
(f) オープンソース、オープンコンテンツ、オープンナレッジに関する知見を活用した調査の検討・分析を行う。
⑤ 認証連携に係るアカデミッククラウドシステムの調査検討（再委託先：大学共同利用機関法人国立情報学研究所）
アカデミッククラウド利用における認証機能について、以下のトピックについて調査・検討を行ったうえで、少なくとも個別連携型、地域別拠点連携型、全国中核拠点型についてそれぞれケーススタディや標準仕様を取りまとめる。これらの異なる構成のクラウド基盤の構築において、認証機能に関し想定される定量的・定性的な波及効果の検討・
試算、実現のためのプロセスについても検討する。
(a) セキュリティ分野とともに、アカデミッククラウド上のサービス利用に関するリス
ク分析を行った上で、そのレベルに応じた ID／パスワード・多要素認証・IC カードな
どの認証強度の使い分け。
(b) 上記に基づき、サービス種別に応じた認証連携のためのトラストフレームワークを構築するために、認証基盤を提供する大学側が順守すべき運用基準。
(c) 認証基盤から送信され、サービス側での認可判断に利用されるユーザ属性に関して、ユーザからの同意取得、ならびに、サービスの種別に応じた送信属性カテゴライズ。
(d) サービス側でのアクセスコントロール、すなわち、認可判断に利用されるユーザ属
性に関して、大学の認証基盤では管理が困難なグループ情報等の取扱い。
(e) アカデミッククラウドを利用する上で起点となる認証基盤の BCP/DR 対策。
上記の内容については、調査内容作成フェーズにおいて、連携分野との調整のもと更に内容を精査する。また、必要に応じて海外における事例も交えて報告書を取りまとめる。
⑥ データプライバシーに係るアカデミッククラウドシステムの調査検討（再委託先：慶應義塾大学）
アカデミッククラウドシステムにおけるデータプライバシーに係るガイドラインを策定する上での課題点・ポイントとなる事項の明確化を行い、少なくとも個別連携型、地域別拠点連携型、全国中核拠点型のそれぞれについてガイドラインを策定する。これらのクラウド基盤の構築において、データプライバシーに係る定量的・定性的な波及効果の検討・試算、実現のためのプロセスについても検討する。
9

(a) アカデミッククラウドにおいて扱われうるデータの種類に関する調査(b) 国内、国外におけるアカデミック分野におけるデータに関するプライバシーの取り扱い基準の現状調査。
(c) 上記調査結果から、ガイドラインに含まれるべき項目・留意点の洗い出し(d) 調査結果を踏まえたガイドラインのテンプレートのあり方に関する考察と提言⑦ ネットワークに係るアカデミッククラウドシステムの調査検討（再委託先：国立大学
法人東北大学）
以下の実施項目に沿って大学ネットワーク基盤に係るアカデミッククラウドシステムの現状の調査・分析を実施し、少なくとも個別連携型、地域別拠点連携型、全国中核拠点型のそれぞれについてアカデミッククラウドシステムの標準仕様を策定する。これらのクラウド基盤の構築において、ネットワーク基盤に係り定量的・定性的な波及効果の検討・試算、実現のためのプロセスについても検討する。
(a) 課題の明確化・調査内容検討：大学等におけるネットワーク基盤の整備・運用状況
等の既存調査データ収集、及び、関連組織へのインタビューによる最新状況調査により、ネットワークに係るアカデミッククラウドシステムの要件や課題を明確化し、調査内容を検討する。特にネットワークの分野では、キャンパスの規模、構成、特性を反映する
ことによりネットワーク構成が多種多様であるため、ケースを分類しつつ、セキュリテ
ィ、事業継続の観点も含めて課題の深堀を行い、調査内容に反映する。
(b) 標準仕様の提案：調査結果をもとに、ネットワーク基盤から見たアカデミッククラウド環境構築の課題や効果を分析し、課題解決の方策やシステム要件を検討するとともに、ネットワークに係るアカデミッククラウド構築に向けた指針を検討する。また、他分野での分析・検討とも連携協力して、アカデミッククラウド環境としてあるべきシス
テムアーキテクチャを検討し、ネットワーク基盤の視点から標準仕様を策定する。
⑧ 研究支援に係るアカデミッククラウドシステムの調査検討（再委託先：国立大学法人
北海道大学）(a) 研究 支援に 係る アカ デミッ クク ラウド に関 する検 討に ついて 、 HPCI (High
Performance Computing Infrastructure)において求められる要求要件を参考に、大規模並列処理に関連する研究プロジェクトの実施を加速するために求められるシステムの条件について検討を行い、それらをまとめた標準仕様を作成する。大規模データベースに係る研究支援については、さまざまな実験・観測データやライフサイエンスなどの大規模なデータベースを活用した研究開発に求められる要求要件を整理し、そのために必要となるシステムの条件ついて検討し、それらをまとめた標準仕様を作成する。
(b)

情報システム研究に係る研究支援に関する検討については、複数のクラウドシス

テムを連携させたインタークラウド基盤や大規模分散データベースの実現を含め、それ10

ら必要とされる要求要件を整理し、関連する研究プロジェクトの実施に必要となるシス
テムの条件について検討し、それらをまとめた標準仕様を作成する。
上記に基づき、少なくとも個別連携型、地域別拠点連携型、全国中核拠点型についてそ
れぞれ標準仕様を作成する。これらの異なる構成のクラウド基盤の構築において、研究支援に係り想定される定量的・定性的な波及効果の検討・試算、実現のためのプロセスについても検討する。
⑨ 事業の総合的推進
事業全体の連携を密とし円滑に運営していくため、国立大学法人九州大学を中心とする事業推進グループを形成し、システム研究グループに属する各分野を担当する参画機関のエキスパートを活用することで、外部コミュニティエンゲージメントを強力に推し進める。また、国立大学法人九州大学に事業推進のための事務局をおき、専任の学術研究員を配置することで、調査実施フェーズにおける外部業者委託によるアンケート調査等を円滑に進める。
大学におけるデータの活用イメージとユーザを具体化し、利用状況を各段階でモニターするなど将来的にアカデミッククラウドシステムを継続的に運用する場合の条件等を可能な範囲で調査検討する。
さらに、事業全体の進捗状況を確認しつつ、必要に応じて外部有識者を招聘して意見を聞くなど事業の推進に資する。

11

Ⅲ. 実施内容（成果）① コンテンツ、大学経営およびシステムアーキテクチャに係るアカデミッククラウ
ドシステムの調査検討（概要）本業務では、まず、コンテンツ分野として、大学図書館や総合研究博物館等の学術情報リポジトリや収蔵品データベース等のコンテンツサービスとそのデータ、ICT
サービス部署等が行っているメールサービスやSNS、各種ホスティング等のサービスとそのデータを対象にしてアカデミッククラウドシステム構築に向けた調査・検討および標準仕様の策定を行った。大学経営分野としては、大学評価情報室等がもつシステムやデータを対象とした。システムアーキテクチャ分野では、データセンターの配置として考えられる個別連携型、地域別拠点連携型、全国中核拠点型についてそれぞれ標準仕様を検討した。具体的には、以下の通り実施した。全体的なスケジュールおよび本業務の内容確認の後、2013年8月9日開催のキックオフシンポジウムにおいて本業務内容について報告した。次に、2013年10月中旬から11月にかけて実施した全国の高等教育研究機関
を対象にしたアカデミッククラウドに係る大規模アンケート調査の調査項目の検討を行った。その後、アンケート調査の集計についての途中経過および今後の方針について、2013年12月18日に開催された大学ICT推進協議会年次大会の企画セッション（中間報告会）において報告を行った。引き続き、アンケートの集計と分析および標準仕様の検討を行い、2014年2月13日に開催された最終報告会において報告を行った。全体で検討した最終報告書の構成にしたがって、当該分野の報告書をまとめた。
以下では，コンテンツ分野，大学経営分野，システムアーキテクチャに係るアカデミ
ッククラウドについて，個々にアンケート調査結果の概要，検討結果と標準仕様（要求要件）について報告する。
①‐① コンテンツ分野

本分野では，ICT サービス（メールサービス，ストレージサービス，SNS，グループ
ウェアサービス，各種ホスティングサービス）とその他コンテンツサービス（機関リポ
ジトリ(JAIRO Cloud 含)，その他リポジトリ，図書館システム，OPAC，その他検索シス
テム，データベース，WEB ページ，CMS，動画システム，教育システム，その他システム）等 ICT サービス部署および大学図書館，総合研究博物館等のコンテンツ提供等のコンテンツサービスに係る部署へのアンケート調査を行った。
1. アンケート調査結果
1) コンテンツ分野アンケート（当該部署向け，システム毎）
12

国立大学には、附属図書館、総合研究博物館等があり、図書館システム，学術情報リ
ポジトリ，各種データベースサービス，ウェブページによる情報発信等を行っている。
コンテンツ分野アンケートは、次に報告する ICT サービス分野アンケートで対象としているシステム以外のサービスおよびデータに関する調査項目からなるアンケートである。以下に示すように，項番 1.は，所属・部署に関する質問である。項番 2.が具体的なシステム毎の質問項目である。
２．１

システム名と業務内容

２．２

ユーザ数

２．３

利用資源量（計算資源，記憶量ークラウド利用状況含む）

２．４

パブリッククラウド利用計画

２．５

アカデミッククラウド利用計画

２．６

保有するデータ総量

２．７

利用者認証

２．８

データのバックアップ先

２．９

当該サービスのソフトウェアの状況

２．１０

SaaS 等パブリックサービス利用計画

２．１１

BCP(Business continuity planning)対策状況

２．１２

２．１１の詳細質問

２．１３

データや計算機資源（システム）の管理状況

２．１４

アカデミッククラウドへの要望

以下では，アンケート項目毎の回答結果について順番に報告する。ここでは，コンテ
ンツサービスのシステム全体に関するアンケート集計結果について報告する。機関リポ
ジトリ(JAIRO Cloud 含)，その他リポジトリ，図書館システム，OPAC，その他検索シス
テム，データベース，WEB ページ，CMS，動画システム，教育システム，その他システ
ム毎のアンケート集計結果については，資料１にまとめている。
コンテンツサービスを実施していると回答した機関数は 399 であり、回答数は 594 であった。機関別のデータは、図Ⅲ-①-①-1)-1 に示す通りである。594 回答のうち複数のサービスをしている回答をそれぞれのサービスに分けた結果 602 サービスシステムとなった。したがって、1 機関当たりのサービスシステムの平均は 1.5 である。コンテン
ツ分野サービス分類を図Ⅲ-①-①-1)-2 に示す。各大学には附属図書館があるため、図書館システムと附属図書館が管理することが多い機関リポジトリ(NII サービスの
JAIRO Cloud 含む)の数値がそれぞれ 213 システム(35%)、145 システム(24%)と高い。

13

図 Ⅲ-①-①-1)-1 コンテンツサービスを実施している機関数

図 Ⅲ-①-①-1)-2 コンテンツ分野サービス分類i) システムの規模と計算機資源量
利用者総数 1,000 人以下のシステムが 49%と多いが、10,000 人以上のシステムも 24%とユーザ数が多いシステムの傾向がある。一方、ピーク時利用者数は 500 人以下が 91%であり、システム規模は大きくない傾向がある。(図Ⅲ-①-①-1)-3 参照)

図 Ⅲ-①-①-1)-3 利用者数区分システム数

14

表 Ⅲ-①-①-1
資源種別

平均資源量

総資源量

備考

サーバ(台)

2.23

1,465.00

CPU コア数(コア)8.06

4,273.00

メモリ容量(GB)35.17

18,779.19

データ量(GB)

988.8

504,301.3 設問 2.6

サーバ総数は 1,465 台(658システム)、1 システム当たりの平均 2.23 台で、1 サー
バ当たりの平均計算資源量
は CPU8.06 コ ア 、 メ モ リ
35.17GB とサーバ規模の計算機が利用されていることが分かる。(表Ⅲ-①-①-1)-1 参照)ii) システムが保有するデータ量
1 システム当たりの平均総データ量は 988.8GB(510 システム)、トータルで約 504TB である。(表Ⅲ-①-①-1)-1 参照)全高等教育研究機関(約 1,230)は回答があった 399 機関の約 3 倍であり、システム数は、4.5 倍となる。したがって、全高等教育研究機関のコンテンツに係るシステムのトータルデータ量は 4.5PB 程度と推定される。
iii) システムの運用形態と稼働図 Ⅲ-①-①-1)-4 機関分類・運用形態毎のシステム数

回答があったシステム全体の約 40%(266 システム)、国立大学でも約 40%(66 システム)で教職員のみで運用されている。研究機関では、約 60%(16 システム)で事業者のみで運用を行っており特徴的である。システム全体で平均約 1.7 人年の稼働をかけて
おり、国立大学では平均約 1.9 人年の稼働をかけており他より高い値となっている。
（図Ⅲ-①-①-1)-4 参照）iv) クラウドサービスの活用状況
クラウドサービスを活用しているシステムは約 30%(208 システム)で、多くはないが少ないとも言えない。徐々にクラウド化が進んでいる表れと思われる。他機関も含めたパブリッククラウドの利用は約 21%(128 システム)とプライベートクラウドの利
用約 11%(70 システム)より多いのが特徴である。コンテンツ系サービスは公開するデータが多く、パブリッククラウドサービスを活用し易いと言える。
（表Ⅲ-①-①-1)-2
参照）15

表 Ⅲ-①-①-1)-2 クラウドサービス別の計算機資源量v) パブリッククラウド(IaaS、PaaS)の利用意向「今後も利用しない・課題があって難しい」は 18%(104 回答)と少なく、「できれば利用したい」と「積極的に利用したい」の合計は 54%(316 回答)と半数以上であり、パブリッククラウドの利用に前向きである。（図Ⅲ-①-①-1)-5 参照）コンテンツサービ
スは公開データが多く、セキュリティやプライバシィの問題が大きくないためと考えられる。

図 Ⅲ-①-①-1)-5 クラウドの利用意向vi) SaaS の利用意向
パブリッククラウド(IaaS、PaaS)の利用意向と同様の傾向であり、利用に前向きな回答が多い。（図Ⅲ-①-①-1)-6 参照）
サービスソフトウェアの形態

図 Ⅲ-①-①-1)-6 サービスソフトウェア形態毎のシステム分布

16サービスソフトウェアの開発にあたって、全体の約 62%(370 回答)が商用パッケージ
ソフトウェアを利用しており(図Ⅲ-①-①-1)-6 参照)、オープンソースの活用 16%(96回答)やスクラッチでの開発 5%(29 回答)を大きく上回っている。SaaS 等のパブリックサービスの利用も 13%(79 回答)と少なくない傾向である。アカデミッククラウドによる
SaaS 等の利用へ移行する可能性も少なくない。しかし、商用パッケージソフトウェアの種類は多岐に渡り、共通化するには大きな問題がある。機関種別の分布では、国立大学、高専、研究機関でオープンソースの活用の割合が高い傾向にある。アカデミックク
ラウド利用の移行へ向けて、共通利用するためのサービスソフトウェアをオープンソー
スの活用により共同開発することも考えられる。
vii) BCP 対策「災害時でも継続してシステムの稼働が必要」が 18%、「データの保全は最低限必要」
が 74%と、両方で 92%と BCP 対策が必要と考えている。(図Ⅲ-①-①-1)-7 参照)

機関

種別では、高専と研究機関でデータの保全に重きを置いていることが分かる。事務支援、教育支援に係るシステムと比べて、コンテンツサービスは、システム停止しても大きな被害が出ることは少ないが、データの保全も含め BCP 対策の必要性を認識していることが分かる。しかし、BCP 対策が必要と回答したシステムで実施済が 19%、計画中 7%を含
めても 26%であり、対策が遅れているのが現状である。(図Ⅲ-①-①-1)-8 参照) これ
は、どの機関でも同じ傾向である。

図 Ⅲ-①-①-1)-7 BCP 対策の必要性

図 Ⅲ-①-①-1)-8 BCP 対策の実施状況

viii) アカデミッククラウドへの要望等
17

要望の主なものは、コストの削減および安全性と高度のセキュリティが確保されたプラ
ットフォームであるといったものである。

2) ICT サービス分野アンケート（当該部署向け、システム毎）

九州大学では、情報統括本部とよばれる全学に対して ICT サービスを行っている部署がある。ICT サービス分野アンケートは、このような ICT サービスを行っている部署向けのアンケート調査項目である。対象とするシステムは、メールサービス，ストレージサービス，SNS，グループウェアサービス，各種ホスティングサービス，およびその他のシステムである。
２．１

アカウント管理の一元化（認証統合）

２．２

認証情報（LDAP, AD など）の冗長化

２．３

認証統合ありの場合の認証連携

２．４

認証連携（IdP）の冗長化

３．１

システム名と業務内容

３．２

ユーザ数

３．３

利用資源量（計算資源，記憶量ークラウド利用状況含む）

３．４

パブリッククラウド利用計画

３．５

アカデミッククラウド利用計画

３．６

保有するデータ総量

３．７

利用者認証

３．８

データのバックアップ先

３．９

当該サービスのフトウェアの状況

３．１０

SaaS 等パブリックサービス利用計画

３．１１

BCP(Business continuity planning)対策状況

３．１２

３．１１の詳細質問

３．１３

データや計算機資源（システム）の管理状況

３．１４

アカデミッククラウドへの要望

以下では、具体的なアンケート項目と回答結果について順番に報告する。項番 1.は、所属・部署に関する質問である。項番 2.が具体的なシステム毎の質問である。ここでは，ICT サービスのシステム全体に関するアンケート集計結果について報告する。メー
ルサービス，ストレージサービス，SNS，グループウェアサービス，各種ホスティング
サービス毎のアンケート集計結果については，資料１にまとめている。
ICT サービスを実施していると回答した機関数は 526 であり、回答数は 704 であった。
18

機関別のデータは、
図Ⅲ-①-①-2)-1 に示す通りである。総システム数は 1,227 であり、
1 機関当たりの ICT サービスシステムの平均は約 2.3 である。ICT 分野サービス分類を
図Ⅲ-①-①-2)-2 に示す。メールサービスが 43%(528 システム)で半数近くを占めている。次いで、ストレージサービスが 22%(270 システム)、グループウェアが 20%(242 シ
ステム)となり、これら 3 サービスで全体の 85%を占めている。利用者数の多いサービ
スを優先して提供しているのが分かる。

図 Ⅲ-①-①-2)-1 ICT サービスを実施している機関数

図 Ⅲ-①-①-2)-2 ICT 分野サービス分類i) システムの規模と計算機資源量
利用者総数 1,000 人以下のシステムが 63%と半数以上を占めるが、1,001～5,000 人のシステムも 22%と 5,000 人以下のシステムで全体の 85%を占める。ピーク時利用者数は500 人以下では 69%と半数以上を占めるが、501～5,000 人のシステムも 30%とピーク時の利用者数(同時利用者数)が高いシステムが多くあることが分かる。(図Ⅲ-①-①-2)-3
参照)

19

図 Ⅲ-①-①-1)-3 利用者数区分システム数

表 Ⅲ-①-①-2)-1
資源種別

平均資源量

総資源量

備考

サーバ(台)

145.74

217,304.00

CPU コア数(コア)43.70

47,328.60

メモリ容量(GB)142.82

157,105.15

データ量(TB)

5.726506

3069.40737 設問 2.6

サ ー バ 総 数 は 217,304 台(1,491 システム)、1 システ
ム当たりの平均 145.74 台で、1 サーバ当たりの平均計算
資源量は CPU43.70 コア、メ
モリ 142.82GB と非常に大きく、一部データセンター規模の計算機が利用されていることが分かる。(表Ⅲ-①-①-2)-1 参照)ii) システムが保有するデータ量
1 システム当たりの平均総データ量は 5.73TB(536 システム)、トータルで約 3PB である。
(表Ⅲ-①-①-2)-1 参照)全高等教育研究機関(約 1,230)は回答があった 704 機関の約倍であり、システム数は 4.5 倍となる。したがって、全高等教育研究機関のコンテンツに係るシステムのトータルデータ量は約 13.5PB 程度と推定される。
iii) システムの運用形態と稼働図 Ⅲ-①-①-2)-4 機関分類・運用形態毎のシステム数

回答があったシステム全体の約 50%(373 システム)、短大、高専、私立大学、国立大学でも半数以上のシステムが教職員のみで運用されている。機関内で対応している
20

傾向がある。それ以外の研究機関、短大、公立大学では、事業者に任せている傾向がある。システム全体で平均約 2.2 人年の稼働をかけており、どの機関も同じ傾向である。研究機関で平均約 4.0 人年の稼働をかけており他より高い値となっている。（図Ⅲ-①-①-2)-4 参照）iv) クラウドサービスの活用状況
クラウドサービスを活用しているシステムは約 37%(553 システム)で、多くはないが少ないとも言えない。徐々にクラウド化が進んでいる表れと思われる。他機関も含めたパブリッククラウドの利用は約 18%(272 システム)とプライベートクラウドの利用
約 19%(281 システム)とほぼ同数である。コンテンツ分野サービスに比べて、ICT サービスは公開するデータではなく個人データ等が多く、パブリッククラウドサービスを活用し難いと思われる。（表Ⅲ-①-①-2)-2 参照）
表 Ⅲ-①-①-2)-2 クラウドサービス別の計算機資源量v) パブリッククラウド(IaaS、PaaS)の利用意向「今後も利用しない・課題があって難しい」は 21%(145 回答)と少なく、「できれば利用したい」と「積極的に利用したい」の合計は 58%(399 回答)と半数以上であり、パブリッククラウドの利用に前向きである。（図Ⅲ-①-①-2)-5 参照）

図 Ⅲ-①-①-2)-5 クラウドの利用意向vi) SaaS の利用意向
パブリッククラウド(IaaS、PaaS)の利用意向と同様の傾向であり、利用に前向きな回答が多い。（図Ⅲ-①-①-2)-5 参照）
サービスソフトウェアの形態
21

図 Ⅲ-①-①-2)-6 サービスソフトウェア形態毎のシステム分布

サービスソフトウェアの開発にあたって、全体の約 54%(360 回答)が商用パッケージソ
フトウェアを利用しており(図Ⅲ-①-①-2)-6 参照)、オープンソースの活用 21%(143 回答)やスクラッチでの開発 3%(20 回答)を大きく上回っている。SaaS 等のパブリックサービスの利用も 15%(98 回答)と少なくない傾向である。アカデミッククラウドによる
SaaS 等の利用へ移行する可能性が少なくない。コンテンツ分野サービスに比べて、商用パッケージソフトウェアの種類は限られるため、共通化するのが容易である。機関種
別の分布では、国立大学、高専でオープンソースの活用の割合が高い傾向にある。アカデミッククラウド利用の移行へ向けて、共通利用するためのサービスソフトウェアをオープンソースの活用により共同開発することも十分に考えられる。
vii) BCP 対策「災害時でも継続してシステムの稼働が必要」が 34%、「データの保全は最低限必要」
が 60%と、両方で 94%と BCP 対策が必要と考えている。(図Ⅲ-①-①-2)-7 参照)

機関

種別でも同様の傾向となっている。事務支援、教育支援に係るシステムと比べて、ICT
サービスは、システム停止しても大きな被害が出ることは少ないが、データの保全も含
め BCP 対策の必要性を認識していることが分かる。しかし、BCP 対策が必要と回答したシステムで実施済が 22%、計画中 11%を含めても 33%であり、対策が遅れているのが現状である。(図Ⅲ-①-①-2)-8 参照) これは、どの機関でも同じ傾向である。

図 Ⅲ-①-①-2)-7 BCP 対策の必要性

22図 Ⅲ-①-①-2)-8 BCP 対策の実施状況

viii) アカデミッククラウドへの要望等
要望の主なものは、コストの削減および安全性と高度のセキュリティが確保されたプラ
ットフォームであるといったコンテンツ分野と同様のものである。その他、商用サービスの利用を希望するなど個別の要望もいくつかあった。
2. 検討結果
以下に、上記アンケート調査結果に基づき検討した結果をコンテンツ分野および ICT
分野それぞれについて示す。
1)コンテンツ分野
調査対象システム：図書館システム，学術情報リポジトリ，データベース，等
回答機関、システム数：399 機関、594 システム
回答内容等の分析
 各サービスで利用しているリソース（平均）：サーバ 2.2 台、CPU8.1 コア、メモリ
35.2GB、データ総量 988.8GB
 4%のシステムでデータのバックアップをしていない
 ソフトウェアに約 62%がベンダーの商用パッケージを利用している
 92%以上が BCP 対策の必要性を感じているが、82%以上が着手できていない 70 システム（約 11%）がプライベートクラウドを利用している
 他機関も含めたパブリッククラウドの利用は 138 システム（約 21％）と少ないがプライベートクラウドの利用よりも多い／今後の利用については 18%が消極的で、メリットが不明や、セキュリティと信頼性に関する課題が要因となっている
 システムの運用に平均 1.7 人年の稼働をかけている／40%以上のシステムが教職員のみで運用を行っている
2)ICT 分野

23

調査対象システム：メールサービス、ストレージサービス、SNS、グループウェア、各種ホスティングサービス等
回答機関、システム数：526 機関、1,227 システム
回答内容等の分析
 各サービスで利用しているリソース（平均）：サーバ 145.7 台、CPU43.7 コア、メ
モリ 142.8GB、データ総量 5.7TB
 1 割強のシステムでデータのバックアップをしていない
 ソフトウェアに、54%がベンダーの商用パッケージを利用している 94%以上が BCP 対策の必要性を感じているが、77%以上が着手できていない 281 システム（約 18%）がプライベートクラウドを利用している
 他機関も含めたパブリッククラウドの利用については 436 システム（約 29.3％）と少ないがプライベートクラウドの利用よりも多い／今後の利用についても 21%が消極的で、個人情報を含むなどセキュリティに関する課題，メリットが不明，予算の問題が要因となっている
 システムの運用に平均 2.2 人年の稼働をかけている／50%以上のシステムが教職員のみで運用を行っている。

3. 要求要件（標準仕様）
１） コンテンツサービス分野
共通の要求要件
ユーザのアカウントが一元管理されており，教職員の所属移動等においても設定変更が容易であること。他のサービスとの統合認証であること。オンプレミスと同等以上のサービス品質を確保すること。応答速度，セキュリティ対策，プライバシー保護を考慮すること。各種コンテンツサービスに対応すること。時間・場所に制限されることなくコンテンツサービスを利用できること。
DC 配置モデル
統合認証の点から現状のパブリッククラウドは不十分。パブリッククラウドの場合，
プライバシー保護・セキュリティのための SLA と BCP の策定が必須。DC 構築・運用管
理コストの点から全国中核拠点型が好ましいが，負荷分散の点と災害時対策から地域別
拠点連携型が適当。
サービスモデル
どのモデルでもサービス可能な場合，運用管理の点から SaaS によるサービスが好ましい。各種サービスに対応したサービスモデルを適用。
10 年間のロードマップ（初期：1～3 年目，中期：4～7 年目，後期：8 年目以降）
24

初期：いくつかの地域別拠点にて，小規模の DC 構築・運用，地域別のサービス。
中期：地域別拠点の追加，インタークラウドによる拠点連携，サービス範囲拡大。
後期：既設拠点の DC 増強，インタークラウドによる拠点連携，サービス範囲拡大。
共通の課題
既存コンテンツサービスからアカデミッククラウドのサービスへの移行時期・方法。
a) 図書館システム
個別の要求要件
学内の他サービスと連携している場合がある。独自機能を有する場合がある。
DC 配置モデル
DC 構築・運用管理コストの点から全国中核拠点型が好ましいが，負荷分散の点と災害時対策から地域別拠点連携型が適当。
サービスモデル共通サービスあるいは共通システムの場合は SaaS あるいは PaaS。非共通システムの場合は PaaS あるいは IaaS。
10 年間のロードマップ（初期：1～3 年目，中期：4～7 年目，後期：8 年目以降）
初期：いくつかの地域別拠点にて，小規模の DC 構築・運用，地域別のサービス。
中期：地域別拠点の追加，インタークラウドによる拠点連携，サービス範囲拡大。
後期：既設拠点の DC 増強，インタークラウドによる拠点連携，サービス範囲拡大。
個別の課題
独自機能への対応策。学内の他サービスとの連携問題。システムの共通化の方策。データの共有・共通化の方策。
b) 学術情報リポジトリ
個別の要求要件
仮想的に超巨大な学術情報リポジトリを提供。
DC 配置モデル
DC 構築・運用管理コストの点から全国中核拠点型が好ましいが，負荷分散の点と災害時対策から地域別拠点連携型が適当，インタークラウド技術による DC 間連携。NIIの学術機関リポジトリ構築連携支援事業(JAIRO Cloud)と連携，あるいは，当該事業の拡大。
サービスモデル
運用管理の点から SaaS による Web サービスが好ましい。
10 年間のロードマップ（初期：1～3 年目，中期：4～7 年目，後期：8 年目以降）
初期：負荷分散のために，NII 管理による小規模の DC 追加，地域別サービス
中期：小規模 DC の追加，インタークラウドによる拠点連携，サービス範囲拡大
25

後期：既設 DC の増強，インタークラウドによる拠点連携，サービス範囲拡大
個別の課題
NII の JAIRO Cloud の利用校を増やす。
c) 各種データベースサービス
個別の要求要件
各種データに対応すること。DBMS によるサービスであること。学内の他サービスと連携している場合がある。独自機能を有する場合がある。
DC 配置モデル
DC 構築・運用管理コストの点から全国中核拠点型が好ましいが，負荷分散の点と災害時対策から地域別拠点連携型が適当。
サービスモデル共通サービスあるいは DBMS 共通の場合は SaaS あるいは PaaS。DBMS 非共通の場合はPaaS あるいは IaaS。
10 年間のロードマップ（初期：1～3 年目，中期：4～7 年目，後期：8 年目以降）
初期：いくつかの地域別拠点にて，小規模の DC 構築・運用，地域別のサービス
中期：地域別拠点の追加，インタークラウドによる拠点連携，サービス範囲拡大
後期：既設拠点の DC 増強，インタークラウドによる拠点連携，サービス範囲拡大
個別の課題
独自機能への対応策，学内の他サービスとの連携対応。DBMS 共通化，データ移行の方策。
d) 情報発信ウェブページ
個別の要求要件
各種データに対応すること。CMS(Contents Management System)によるサービスであること。学内の他サービスと連携している場合がある。独自機能を有する場合がある。
DC 配置モデル
DC 構築・運用管理コストの点から全国中核拠点型が好ましいが，負荷分散の点と災害時対策から地域別拠点連携型が適当。
サービスモデル共通サービスあるいは CMS 共通の場合は SaaS あるいは PaaS。
CMS 非共通の場合は PaaS
あるいは IaaS。
10 年間のロードマップ（初期：1～3 年目，中期：4～7 年目，後期：8 年目以降）
初期：いくつかの地域別拠点にて，小規模の DC 構築・運用，地域別のサービス
中期：地域別拠点の追加，インタークラウドによる拠点連携，サービス範囲拡大
後期：既設拠点の DC 増強，インタークラウドによる拠点連携，サービス範囲拡大
26

個別の課題独自機能への対応策，学内の他サービスとの連携対応。CMS 共通化，データ移行の方策。
2) ICT サービス分野
共通の要求要件
アカウントが一元管理されており，教職員の所属移動等においても設定変更が容易であること。他のサービスとの統合認証であること。オンプレミスと同等以上のサービス品質を確保すること。応答速度，セキュリティ対策，プライバシー保護が考慮されること。各種 ICT サービスに対応すること。時間・場所に制限されることなく ICT サービスを利用できること。
DC 配置モデル
統合認証の点から現在のパブリッククラウドでは不十分。パブリッククラウドの場合，
プライバシー保護・セキュリティのための SLA と BCP の策定が必須。DC 構築・運用管
理コストの点から全国中核拠点型が好ましいが，負荷分散と災害時対策の点から地域別
拠点連携型が適当。
サービスモデル
どのモデルにてもサービス可能な場合，運用管理の点から SaaS によるサービスが好ましい。各種サービスに対応したサービスモデルを適用。
10 年間のロードマップ（初期：1～3 年目，中期：4～7 年目，後期：8 年目以降）
初期：いくつかの地域別拠点にて，小規模の DC 構築・運用，地域別のサービス
中期：地域別拠点の追加，インタークラウドによる拠点連携，サービス範囲拡大
後期：既設拠点の DC 増強，インタークラウドによる拠点連携，サービス範囲拡大
共通の課題
既存 ICT サービスからアカデミッククラウドのサービスへの移行（データ移動含む）
時期・方法。
a) メールサービス
個別の要求要件
メールアドレスは，当該ユーザの所属大学・部局・部門等が分かる形式等，アドレス
名付けルールが必要。標準的に利用可能な IMAP サービス等が利用できること。安否確認等に利用できること。
DC 配置モデル
DC 構築・運用管理コストの点から全国中核拠点型が好ましいが，災害時対策のための冗長化が必要。
サービスモデル27

どのモデルにてもサービス可能であるが，運用管理の点から SaaS による Web メール
サービスが適当。
10 年間のロードマップ（初期：1～3 年目，中期：4～7 年目，後期：8 年目以降）
初期：全国中核拠点にて，小規模の DC 構築・運用，部分的サービス
中期：既設拠点の DC 増強，インタークラウドによる拠点連携，サービス範囲拡大
後期：既設拠点の DC 増強，インタークラウドによる拠点連携，サービス範囲拡大
個別の課題
メールボックス容量。メールアドレスの形式。ウイルス検査・スパム検査の方式、ユーザからのフィードバックの受け方（検疫等）。サービス対象範囲（卒業生等を含むか否か等）。
b) ストレージサービス
個別の要求要件
可能な限りの必要容量を柔軟に提供できること。期限ありサービスと期限なしサービス。他のサービスとのシームレスなデータ連携が可能であること。データ参照とデータ移動が高速であること。
DC 配置モデル
災害時対策の点からパブリッククラウド利用の冗長化もあり。DC 構築・運用管理コ
ストの点から全国中核拠点型が好ましいが，負荷分散の点と災害時対策から地域別拠点
連携型が適当。
サービスモデル
どのモデルにてもサービス可能であるが，運用管理の点から SaaS による Web サービ
スが適当。
10 年間のロードマップ（初期：1～3 年目，中期：4～7 年目，後期：8 年目以降）
初期：いくつかの地域別拠点にて，小規模の DC 構築・運用，地域別のサービス
中期：地域別拠点の追加，インタークラウドによる拠点連携，サービス範囲拡大
後期：既設拠点の DC 増強，インタークラウドによる拠点連携，サービス範囲拡大
個別の課題
既存サービスからの大容量データの移動。
c) SNS
個別の要求要件
コミュニティ形成が可能であること。チャットの機能があること。
DC 配置モデル
DC 構築・運用管理コストの点から全国中核拠点型が好ましいが，災害時対策のための冗長化が必要。
28

サービスモデル
どのモデルにてもサービス可能であるが，運用管理の点から SaaS による Web サービ
スが適当。
10 年間のロードマップ（初期：1～3 年目，中期：4～7 年目，後期：8 年目以降）
初期：全国中核拠点にて，小規模の DC 構築・運用，部分的サービス
中期：既設拠点の DC 増強，インタークラウドによる拠点連携，サービス範囲拡大
後期：既設拠点の DC 増強，インタークラウドによる拠点連携，サービス範囲拡大
個別の課題
既存サービスからのデータ移動（データフォーマット問題）。
d) グループウェア
個別の要求要件
コミュニティ形成が可能であること。ストレージサービス機能があること。
DC 配置モデル
DC 構築・運用管理コストの点から全国中核拠点型が好ましいが，災害時対策のための冗長化が必要。
サービスモデル
どのモデルにてもサービス可能であるが，運用管理の点から SaaS による Web サービ
スが適当。
10 年間のロードマップ（初期：1～3 年目，中期：4～7 年目，後期：8 年目以降）
初期：全国中核拠点にて，小規模の DC 構築・運用，部分的サービス
中期：既設拠点の DC 増強，インタークラウドによる拠点連携，サービス範囲拡大
後期：既設拠点の DC 増強，インタークラウドによる拠点連携，サービス範囲拡大
個別の課題
既存サービスからのデータ移動（データフォーマット問題）e) ホスティングサービス
個別の要求要件
メールサービス，情報発信サービス以外の各種ホスティングサービスに対応すること，
IaaS 等。
DC 配置モデル
DC 構築・運用管理コストの点から全国中核拠点型が好ましいが，負荷分散の点と災害時対策から地域別拠点連携型が適当。
サービスモデルホスティングサービスの種類により対応するサービスモデルが異なる。
10 年間のロードマップ（初期：1～3 年目，中期：4～7 年目，後期：8 年目以降）
29

初期：いくつかの地域別拠点にて，小規模の DC 構築・運用，地域別のサービス
中期：地域別拠点の追加，インタークラウドによる拠点連携，サービス範囲拡大
後期：既設拠点の DC 増強，インタークラウドによる拠点連携，サービス範囲拡大
個別の課題
既存サービスからの大容量データの移動。既存サービスとの相互データ移動（データフォーマット問題，インンポート側とエクスポート側の対応）。ストレージサービスと
の連携。

30

①－② 大学経営分野（担当：岡田）
例えば九州大学には，認証評価のためのデータを扱う部署として大学評価情報室がある。このような部署が保持する大学経営に係るデータを扱う評価情報システム，その他
事務システム等認証評価のためシステムを対象としてアンケート調査を実施した。
1 アンケート調査結果
経営分野アンケート（当該部署，システム毎）
以下に示すように，項番 1.は，所属・部署に関する質問である。項番 2.が具体的なシステム毎の質問項目である。
２．１

システム名と業務内容

２．２

ユーザ数

２．３

利用資源量（計算資源，記憶量ークラウド利用状況含む）

２．４

パブリッククラウド利用計画

２．５

アカデミッククラウド利用計画

２．６

保有するデータ総量

２．７

利用者認証

２．８

データのバックアップ先

２．９

当該サービスのフトウェアの状況

２．１０

SaaS 等パブリックサービス利用計画

２．１１

BCP(Business continuity planning)対策状況

２．１２

２．１１の詳細質問

２．１３

データや計算機資源（システム）の管理状況

２．１４

アカデミッククラウドへの要望

以下では，アンケート項目毎の回答結果について順番に報告する。ここでは、大学経営分野サービスのシステム全体に関するアンケート集計結果について報告する。大学
評価情報システム、その他システム毎のアンケート集計結果については，資料１にまとめている。
大学経営に係るデータのサービスを実施していると回答した機関数は 140 であり、回答数は 166 であった。機関別のデータは、図Ⅲ-①-②-1 に示す通りである。166 回答のうち複数のサービスをしている回答をそれぞれのサービスに分けた結果 168 サービス
システムとなった。
したがって、1 機関当たりのサービスシステムの平均は 1.2 である。
経営分野サービス分類を図Ⅲ-①-②-2 に示す。大学評価情報室のような部署をもっている大学は少なく、大学経営に係るデータのサービスは、事務支援分野で対象としているシステムの回答と重複しているものがあると予想される。重複があるか否かの判定は
31

不可能なため、得られた回答データをすべて大学経営に係るデータのサービスに関するシステムのものとして取り扱うことにした。事務支援分野で対象としているシステムは、その用途を明確にして回答を依頼しているため、それに含まれない複合した情報システ
ムを評価情報システムとして取り扱っている。その割合は、38%(63 システム)であった。
次に、財務会計システムが 31%(52 システム)と高いが、それ以外は 10%未満と少ない。

図 Ⅲ-①-②-1 経営分野サービスを実施している機関数

図 Ⅲ-①-②-2 経営分野サービス分類i) システムの規模と計算機資源量
利用者総数 1,000 人以下のシステムが 87%とほぼ全部である。業績や個人情報等の重要なデータを含み、機関内の権限のある職域の者のみがシステムを利用できるためと考えられる。5,000 人以上のシステムも 13%程あるが、コンテンツ分野サービスや教育シ
ステムの回答が含まれている影響と考えられる。一方、ピーク時利用者数についても500 人以下が 95%であり、システム規模は大きくない傾向がある。(図Ⅲ-①-②-3 参照)

32

図 Ⅲ-①-②-3 利用者数区分システム数
表 Ⅲ-①-②-1

資源種別

平均資源量

総資源量

備考

サーバ(台)

2.61

261.00CPU コア数(コア)7.13

556.00

メモリ容量(GB)

19.64

15,715.00

データ量(GB)

825.0

117,143.2

サーバ総数は 261 台(100 システム)、1 システム当たりの平均 2.61 台で、1 サーバ
当たりの平均計算資源量は設問 2.6

CPU7.13 コ ア 、 メ モ リ
19.64GB とサーバ規模の計算機が利用されていることが分かる。(表Ⅲ-①-②-1 参照)ii) システムが保有するデータ量
1 システム当たりの平均総データ量は 825.0GB(142 システム)、トータルで約 117TB である。(表Ⅲ-①-②-1 参照)全高等教育研究機関(約 1,230)は回答があった 140 機関の約9 倍であり、システム数は、10.8 倍となる。したがって、全高等教育研究機関の経営に係るシステムのトータルデータ量は 1.3PB 程度と推定される。
iii) システムの運用形態と稼働図 Ⅲ-①-②-4 機関分類・運用形態毎のシステム数

他の分野に比べて、回答なしが多い。回答があったシステム全体の約 68%(104 シス
テム)、国立大学では約 78%(44 システム)で教職員のみで運用されている。研究機関については回答数が 2 と少ないため、参考とはならない。システム全体で平均約 3.7
人年の稼働をかけており、国立大学では平均約 1.4 人年の稼働をかけており他より低い値となっている。逆に、短大および私立大学が大きな値となっており多くの人員を配置していることが分かる。（図Ⅲ-①-②-4 参照）33iv) クラウドサービスの活用状況
クラウドサービスを活用しているシステムは約 32%(32 システム)で、多くはないが少ないとも言えない。徐々にクラウド化が進んでいる表れと思われる。他機関も含めたパブリッククラウドの利用は約 14%(14 システム)とプライベートクラウドの利用
約 16%(18 システム)より少ない。経営分野に係るデータのサービスは事務支援分野サービスと同じように重要度の高いデータが多く、パブリッククラウドサービスを活用し難いと考えられる。（表Ⅲ-①-②-2 参照）
表 Ⅲ-①-②-2 クラウドサービス別の計算機資源量v) パブリッククラウド(IaaS、PaaS)の利用意向「今後も利用しない・課題があって難しい」は 31%(61 回答)と少ないが、「できれば利用したい」と「積極的に利用したい」の回答も合計は 40%(78 回答)と半数以下であり、パブリッククラウドの利用に前向きとは言い難い。（図Ⅲ-①-②-5 参照）経営分野に係るデータのサービスは重要データが多く、セキュリティやプライバシィの問題が大きいためと考えられる。

図 Ⅲ-①-②-5 クラウドの利用意向vi) SaaS の利用意向
パブリッククラウド(IaaS、PaaS)の利用意向と同様の傾向であり、利用に前向きとは言い難い。（図Ⅲ-①-②-6 参照）
サービスソフトウェアの形態34

図 Ⅲ-①-②-6 サービスソフトウェア形態毎のシステム分布

サービスソフトウェアの開発にあたって、全体の約 71%(117 回答)が商用パッケージ
ソフトウェアを利用しており(図Ⅲ-①-②-6 参照)、オープンソースの活用 9%(14 回答)
やスクラッチでの開発 12%(20 回答)を大きく上回っている。SaaS 等のパブリックサー
ビスの利用も 2%(3 回答)と極端に少ない傾向である。アカデミッククラウドによる SaaS等の利用へ移行するためには、その原因を明らかにする必要がある。商用パッケージソ
フトウェアの種類は多岐に渡り、共通化するには大きな問題がある。機関種別の分布では、国立大学でオープンソースの活用の割合が高い傾向にあり、高専ではフルスクラッ
チでの開発をしている傾向がある。アカデミッククラウド利用の移行へ向けて、共通利用するためのサービスソフトウェアをオープンソースの活用により共同開発することも考えられる。
vii) BCP 対策「災害時でも継続してシステムの稼働が必要」が 26%、「データの保全は最低限必要」
が 65%と、両方で 91%と BCP 対策が必要と考えている。(図Ⅲ-①-②-7 参照) 機関種別
では、どの機関も同じ傾向にある。事務支援、教育支援に係るシステムと同様に、経営分野に係るサービスは、機関の運営に大きな支障を来すことから、データの保全も含め
BCP 対策の必要性を認識していることが分かる。しかし、BCP 対策が必要と回答したシ
ステムで実施済が 16%、計画中 7%を含めても 23%であり、対策が遅れているのが現状である。(図Ⅲ-①-②-8 参照)

これはどの機関でも同じ傾向であるが、国立大学では、他に比べて、実施済みの割合が高く、BCP の取り組みが進んでいると言える。

図 Ⅲ-①-②-7 BCP 対策の必要性

35

図 Ⅲ-①-②-8 BCP 対策の実施状況

viii) アカデミッククラウドへの要望等
セキュリティ及び BCP 対策に優れた公的機関のクラウドサービスに期待する等利用に関して前向きな要望が多い。

2. 検討結果
以下に、上記アンケート調査結果に基づき検討した結果を示す。
調査対象システム：評価情報システム，その他事務システム等
回答機関、システム数：140 機関、166 システム
回答内容等の分析
 各システムで利用しているリソース（平均）：サーバ 2.6 台、CPU7.1 コア、メモリ
19.64GB、データ総量 825.0GB
 ソフトウェアは、約 71%がベンダーの商用パッケージを利用している
 90%以上が BCP 対策の必要性を感じているが、83%以上が着手できていない 18 システム（約 9.5%）がプライベートクラウドを利用している
 他機関も含めたパブリッククラウドの利用については 7.4％と少ない／今後の利用についても 31%が消極的で、個人情報を含むなどセキュリティの問題が大きな要因となっている システムの運用に平均 3.7 人年の稼働をかけている／68%以上のシステムが教職員のみで運用を行っている

3. 要求要件（標準仕様）

36a) 大学評価情報システム
個別の要求要件
学内の他サービスと連携している場合がある。独自機能を有する場合がある。
DC 配置モデル
データの特質から個別連携型かプライベートが適当，災害時対策のための冗長化は必須。
サービスモデル共通サービスあるいは共通システムの場合は SaaS あるいは PaaS。非共通システムの場合は PaaS あるいは IaaS。
10 年間のロードマップ（初期：1～3 年目，中期：4～7 年目，後期：8 年目以降）
初期：いくつかの個別の拠点にて，小規模の DC 構築・運用，個別サービス開始
中期：個別 DC の追加，個別サービス開始＋他サービスとの連携
後期：個別 DC の追加，個別サービス開始＋他サービスとの連携
個別の課題
独自機能への対応策，学内の他サービスとの連携問題。システムの共通化の方策，データの共有・共通化の方策。

37

①－③ システムアーキテクチャ分野，全体（担当：岡田）
本分野では、末尾資料に示した事例調査の内容と他の分野における各アンケート調査
結 果 に 基 づ き 、 SaaS(Software as a Service) 、 PaaS(Platform as a Service) 、
IaaS(Infrastructure as a Service)というサービスモデル、プライベートクラウド、商用も含めたパブリッククラウド、コミュニティクラウド等の配備モデル、さらに、全国中核拠点型、地域別拠点連携型、個別連携型という 3 つのデータセンター(DC)配置モ
デルについて検討し、アカデミッククラウドのあるべき姿についてまとめた。特に、大学等を越えてクラウドサービスを利用する必要性の有無、商用のパブリッククラウドを活用することの是非、アンケート調査結果に基づく次世代の学術情報基盤となり得るア
カデミッククラウドの要求要件（標準仕様）を提案するものである。
1. アカデミッククラウドとはまず，アカデミッククラウドの定義を考える必要がある。DC 配置の点から見ると、機関毎のプライベートクラウドを連携して運用することから、アカデミィア（学術機関の連携)をコミュニティとするコミュニティクラウドと捉えることができる。この際、すでに数多くの商用サービスが実現されており，それらを利用している現状から，パブリッククラウドサービスを除外することはできない。アカデミッククラウドは、パブリ
ッククラウドサービスの利用も含めたコミュニティクラウドと位置付けられるべきである。重要なのは、どこがアカデミッククラウドの運用主体となるかである。パブリッ
ククラウドサービスを利用する場合にも、各機関がもつデータの質に対応したセキュリ
ティレベル、個人情報保護基準、BCP(Business Continuity Plan)および SLA(Service
Level Agreement)が保障されている必要がある。これらが保障されていれば、プライベ
ートクラウドであるか商用を含むパブリッククラウドであるかという DC 配置の問題を小さくできる。当然、DC 配置には、物理的な距離による様々な制約も考慮しなければならない。セキュリティレベル、個人情報保護基準、BCP(Business Continuity Plan)
および SLA(Service Level Agreement)の標準を決め運用する主体がアカデミィアである必要がある。したがって、アカデミッククラウドとは、アカデミィアを実施主体とする学術機関の連携によるコミュニティクラウドと言うことができる。アカデミッククラウド実現により、以下のクラウドコンピューティングのメリットを謳うことができる。
Agile(Elasticity)：即応的に様々な計算機環境を構築可能
Quality(Share)：データ共有化，アプリケーション共通化によるサービスの質担保
Innovation：様々な形態での計算機資源提供によるサービスの進化・発展を支える
Collaboration：計算機資源の共有による効率化，共同研究等の支援
すなわち、アカデミッククラウドとは，多様な教育研究活動の進化・発展を効率的に支える学術情報基盤となるものと考えられる。

38

教育支援分野においては、コミュニティ形成（Participatory Design, Learning
Analytics）やコンテンツ管理運用（競争的コンテンツ（独自性、差別化）、非競争的コンテンツ（共有化、効率化）））が重要であるが，アカデミッククラウドによって，教育の質向上と効率化の両面を享受できるようになると考えられる。また，研究支援分野においては、コミュニティ形成（共同研究、共同開発）のほか、超大規模仮想マシンの提供（ビッグデータ処理（競争的データ、非競争的データに柔軟に対応））など、アカデ
ミッククラウドによって、研究開発環境の多様性と進化に対応できるようになると考えられる。さらに、事務支援分野においては、多様なコモディティサービスのための計算機資源の効率運用と管理コストの削減を謳うことができる。
次に、アカデミッククラウドの実施主体はどこになるかを検討する必要がある。デー
タセンターの運用管理とサービス提供のためには、運用管理のための人員が必要であり、大きな大学や研究機関でなければ無理である。候補として、全国共同利用サービスを提供している情報基盤センター等のセンターをもつ機関が考えられる。また、実績がある点も重要であり、すでに JAIRO Cloud 等のクラウドサービスを全国の高等教育研究機関
向けに行っている国立情報学研究所もその候補と考えられる。さらに、データセンターの運用管理を行わずともガバナンスの役割として、情報基盤センター等をメンバーとする協議会を設置する、あるいは、大学 ICT 推進協議会にガバナンスを依頼する等が考えられる。
2. 実現のための要求要件
アカデミッククラウドの共通認識
アカデミッククラウド環境構築を進めるためには、アカデミッククラウドと従来のクラウドサービスとの違いを明らかにする必要がある。アカデミッククラウドは、大学等の機関内の利用者を対象にした閉じたサービスではなく、大学間をまたいで複数の拠点機関にデータセンターを配置し連携して複数の機関の利用者に共通にクラウドサービ
スを提供するものである。これが従来のクラウドサービスと大きく異なる点である。この点を理解してもらいアカデミッククラウドの共通認識を図ることは、アカデミックク
ラウド環境構築を進める上で非常に重要である。この際のデータセンター配置は、セキ
ュリティ、プライバシー、認証等についての要求要件を満たせば商用パブリッククラウ
ドサービスの利用も可能と考えられる。このようなアカデミッククラウドサービスを実現するためには、アカデミッククラウド各拠点機関の DC を連携してシームレスに計算機資源の管理運用と提供を行える必要がある。それが、インタークラウド技術である。
アカデミッククラウド環境構築のためには、インタークラウド技術は不可欠である。
サービスモデルと標準化

39

次に、サービスモデルについて検討した結果を述べる。クラウドコンピューティング
では、SaaS(Software as a Service)、PaaS(Platform as a Service)、IaaS(Infrastructure
as a Service)というサービスモデルがある。SaaS は、上位に位置するサービスで、ア
プリケーションソフトウェアの機能をクラウドシステム上のサーバがインターネット
を介して利用者にサービス提供するサービス形態である。PaaS は、中間に位置するサービスで、オペレーティングシステム等のアプリケーションソフトウェアの実行環境をクラウドシステム上のサーバがインターネットを介して利用者にサービス提供するサービス形態である。IaaS は、さらに下層に位置するサービスで、様々なオペレーティ
ングシステムの実行環境をクラウドシステム上のサーバがインターネットを介して利用者にサービス提供するサービス形態である。下層に位置する程、利用者の自由度は高くなるが、サービス利用の際の負担も大きくなる。したがって、特定のアプリケーショ
ンソフトウェアの機能を利用したい場合には、SaaS としてサービスを受ける方が利用者の負担が小さく便利である。各機関内で様々なアプリケーションソフトウェアが利用されているが、それらをアカデミッククラウドのサービスとして提供する場合には、SaaS として提供することが好ましい。しかし、アプリケーションソフトウェアの共通化の問題がある。事務支援分野や大学経営分野のアンケート調査で明らかになっている
が、各機関で利用されているアプリケーションソフトウェアは商用のパッケージソフト
ウェアが多く、その種類も多岐に渡り、すべてをアカデミッククラウドのサービスとして提供することは難しく現実的ではない。ここで、アプリケーションソフトウェアの共通化の問題が発生する。一つの方法として、幾つかの機関で共通に使われているオープ
ンソースのソフトウェアがあるが、それを共同でカスタマイズしてアカデミッククラウ
ドの SaaS として提供するものである。この場合には、アカデミッククラウドの実施主体となる機関や協議会等がイニシアチィブを取って強力に推し進める必要がある。他の方法として、各個別機関内で利用されているアプリケーションソフトウェアをアカデミ
ッククラウドの PaaS や IaaS を利用して個別に実行するというものである。この場合には、各機関で個別に計算機を管理する（場所と電気の）必要がないというメリットが享受できる。
情報の格付けとクラウドサービスの信頼度
各機関で個別にプライベートクラウド化が進んでいるが、アカデミッククラウドのサービスへ移行するためには、そこで発生する障壁を取り除く必要がある。各支援分野のアンケート調査で明らかっとなっているが、扱うデータに個人情報や重要なデータが含まれており、それらのデータを機関外に保存管理することに不安があるというのがその障壁である。この障壁を取り除くためには、まず、扱うデータとサービスの質と種類を把握し、個人情報保護方針（プライバシー）も含めて情報の格付けを行い、アカデミッ
ククラウドとして提供するサービスにおいて、セキュリティ、認証連携、ネットワーク
40

の観点からその信頼性のためのガイドラインを規定する必要がある。本事業におけるセキュリティ分野、認証連携分野、プライバシー分野は関連するガイドラインを規定することがアカデミッククラウド環境構築における要求要件（標準仕様）を提案することである。
これらのガイドラインを満たすクラウドシステムであれば、当該の信頼度が得られ、対応する情報格付けのデータをそのクラウドシステムで利用してもよいものである。
サービスの種類とデータセンター配置
本事業では、全国中核拠点型、地域別拠点連携型、個別連携型という 3 つのデータセンター(DC)配置モデルについてアカデミッククラウド環境を検討するという当初の計画がある。ここでは、サービスの種類とデータセンター配置について検討した。アカデ
ミッククラウドの利用者の範囲でサービスを分類した。まず、利用者が全国に居る基本
サービスの場合を示したのが次の図Ⅲ-①-③-1 である。Gmail 等のメールサービスをア
カデミッククラウドが全国の利用者に提供するような場合である。図に示すように、この場合のデータセンター配置は、全国中核拠点型と考えられる。次に、利用者が地域に偏って居る地域別サービスの場合を示したのが図Ⅲ-①-③-2 である。単位互換等で近隣の大学が連携して教育サービスをアカデミッククラウドを利用して実施するような場合である。図に示すように、この場合のデータセンター配置は、地域別拠点型と考えられる。

図Ⅲ-①-③-1 アカデミッククラウドの基本サービス

41

図Ⅲ-①-③-2 アカデミッククラウドの地域別サービス

図Ⅲ-①-③-3 アカデミッククラウドのコミュニティサービス

さらに、特定のコミュニティに利用者が偏って居るコミュニティサービスの場合を示したのが図Ⅲ-①-③-3 である。研究プロジェクト等でコミュニティを形成し、そのメンバーが利用できるクラウドサービスを提供するような場合である。図に示すように、
この場合のデータセンター配置は、コミュニティ連携型と考えられる。
以上のように、アカデミッククラウドで対象とするサービスは様々なものがあり、全国中核拠点型、地域別拠点連携型、個別連携型が混在したものとなると考えられる。以42

下の図Ⅲ-①-③-4 は、本事業の成果として提案するアカデミッククラウドのあるべき姿である。

図Ⅲ-①-③-4 アカデミッククラウドのあるべき姿

3. アカデミッククラウド環境構築のロードマップ
基本的な考え方は、小さな成功を積み重ね規模を拡大するとともに、新しいサービスの形を模索することである。
10 年間のロードマップ（初期：1～3 年目，中期：4～7 年目，後期：8 年目以降）
初期：いくつかの拠点にて小規模の DC 構築・運用、バックアップサービス等の実現し易ものから開始、インタークラウド化の試みと既存サービスの拡充
中期：インタークラウドによる拠点間連携の推進、既存サービスとの連携とサービス拡大
後期：拠点追加、既設拠点の DC 増強、インタークラウドによる拠点連携強化、サービス拡大強化43

② セキュリティに係るアカデミッククラウドシステムの調査検討（概要）全体的なスケジュールおよび業務内容の確認の後、キックオフシンポジウムに向けた準備を行った。セキュリティはすべての分野に関係することから、各分野が調査を担当する範囲の調整を行い、セキュリティ分野は情報の保存場所としてのクラウドの標準仕様を担当することとした。大規模アンケート調査に関しては、セキュリティに関する設問は他分野にも多く含まれるため、セキュリティ分野ではアカデミックな機関が保有する情報をクラウド上に保存することを想定して、機関における情報の取扱い規則などの整備状況、クラウドサービスの利用状況、クラウドサービスに求めるセキ
ュリティ面での要件などに関するアンケート項目の検討を行った。セキュリティ分野のアンケートに対して608機関からの回答を得て、集計を行った。集計の途中経過および今後の方針について、大学ICT推進協議会年次大会の企画セッション（中間報告会）において報告を行った。アンケートの集計と並行して結果の分析を行った。分析の結果、情報の格付けや外部委託等に関する諸規則の整備は3割弱の機関に留まっており、ゆえにクラウドサービスの利用に対してコストの低減や利便性の向上への期待はある
ものの、漠然とした不安を抱いていることが明らかとなった。検討の結果、情報の格付けやその格付けに応じたクラウドサービスの選択基準を示す必要があることが分かった。検討結果について、最終報告会において報告を行った。検討結果にしたがい、
クラウドサービスの信頼度を評価するための評価軸を定義し、情報の格付けとそれらとの対応関係を定義した。また、クラウドサービスを利用する際に確認すべき事項の検討を行い、それらを簡単に確認するためのチェックリストの作成を行った。全体で検討した最終報告書の構成にしたがって、上記の業務の経緯および検討結果をセキュリティ
分野の報告としてまとめた。
１．アンケート調査結果
１）セキュリティ分野の位置付け
セキュリティ分野ではまず、本事業全体におけるセキュリティ分野の位置付けの検討を行った。本事業は前述のように 10 の分野で構成されており、アカデミッククラウド
におけるデータフローに対して、セキュリティの観点からこれらが担う役割として次のように分類した。
 安全な流通：ネットワーク分野
 安全な保管：セキュリティ分野
 安全なアクセス（認証）：認証連携分野
 安全な処理：教育支援分野、研究支援分野、事務支援分野、コンテンツ分野、大学
経営分野、プライバシー分野、システムアーキテクチャ分野
このような分類から、セキュリティ分野では「アカデミックな組織が（自組織以外の）44

クラウドサービスをデータの保管場所として利用する際に求められるセキュリティ要件」について、 アンケートに基づく現状調査
 課題の洗い出しと解決策の検討
 ガイドラインおよびチェックリストの策定を行うことを主たる目的とした。
２）アンケート調査の概要
今回アンケートの調査対象となる機関に関する事前情報から、アカデミッククラウドの利用の検討に際して必要となる機関の情報システムの運用に関する諸規則（セキュリ
ティポリシー）の有無、機関が保有する情報の格付けの有無、情報処理を外部に委託する際の諸規則の有無などから調査が必要であることがわかった。
そこでアンケート調査では、以下のような内容について、対象機関の状況の収集を行った。
 情報システムの運用に関する諸規則の整備状況
 整備の際に参考にした資料について
 情報の格付けに関する事項の整備状況
 情報処理を外部委託する場合に関する事項の整備状況
 諸規則を構成員に周知するための教育の実施状況
 情報セキュリティマネジメントシステム（ISMS）認証の取得状況
 セキュリティインシデントの発生状況
 機関によるクラウドサービスの利用状況
 利用しているクラウドサービス
 利用を決定する際の要件
 利用しない理由
 構成員によるクラウドサービスの利用状況
 アカデミッククラウド利用の意向 アカデミッククラウドに求める要件、期待、問題点
セキュリティ分野のアンケート調査に対して、608 機関から回答を得た。回答機関の区分を図 Ⅲ-②-1 および表 Ⅲ-②-1 に示す。ただし設問によっては未回答となっている機関があるため、以下のアンケート結果ではそれぞれの設問ごとに有効回答数が異なっている。特にことわりのない場合はそれぞれの設問の結果は有効回答数に対する割合となっているので、比較の際には注意が必要である。

45

図 Ⅲ-②-1 回答機関の区分（セキュリティ分野）

表 Ⅲ-②-1 回答機関の区分（セキュリティ分野）

国立 A

国立 B

国立 C

国立 D

私立 A

私立 B

私立 C

私立 D

公立 A

公立 B

公立 C

公立 D

高専

短大

研究機関

19

13

24

21

24

52

122

107

1

3

25

25

42

111

19

３）アンケート調査の内容
以下、アンケートの設問番号にしたがって結果を示す。
設問２ 貴機関では、情報システムの運用に関する諸規則（アカウントの運用方法やパスワードの設定方法等のセキュリティに関するポリシー）を定めていますか？
クラウドサービスの利用の可否を判断するに当たり、機関として情報システムの運用に関する諸規則を定めているかどうかは重要な要素である。
本設問に対する有効回答数は 583 であった。結果を図Ⅲ-②-2 に示す。機関全体の66.9%が情報システムの運用に関する諸規則を定めている。区分別では、国立大学の90.9%、公立大学の 77.4%、高等専門学校の 95.2%が平均以上となっており、研究機関は100%である。一方、私立大学は機関の規模が小さくなるにつれて整備率が下がる傾向に46

ある。短期大学の整備率は私立大学 D と同等である。

図 Ⅲ-②-2 情報システムの運用に関する諸規則設問２．１ 規則の作成にあたり、参考にしたものはありますか？
本設問は設問２で「定めている」と回答した 390 機関に対するもので、今後検討を行う際に基準とする規則等を判断するための設問である。
本設問に対する有効回答数は 381 であった。結果を図 Ⅲ-②-3 に示す。機関全体の44.6%が「高等教育機関の情報セキュリティ対策のためのサンプル規程集」を参考にしたと回答している。一方 26.5%の機関は「その他」と回答しているが、自由記述の内容
は
 情報セキュリティポリシーに関するガイドライン（平成 12 年 7 月）
 大学における情報セキュリティポリシーの考え方（平成 14 年 3 月）
 政府機関の情報セキュリティ対策のための統一基準（2005 年 12 月）
 国立高等専門学校機構の情報セキュリティ対策サンプル規程集（平成 20 年 3 月）
 他大学、地方公共団体の諸規則となっており、ほとんどの機関が「高等教育機関の情報セキュリティ対策のためのサン
プル規程集」と起を一とする諸規則を参考としていることから、これを本事業において基準とすることで多くの機関への適用も容易となることが期待できる。

47

図 Ⅲ-②-3 規則の作成にあたり、参考にしたもの

設問２．２ 情報システムの運用に関する諸規則の中で、情報の格付け（重要度に応じた取扱い）に関する事項を定めていますか？
本設問も設問２で「定めている」と回答した 390 機関に対するもので、機関が保有する情報について格付けが行われているかを問う設問である。クラウドサービスに情報を預ける場合、その情報の重要度に応じたセキュリティ対策が必要となる。
本設問に対する有効回答数は 379 であった。結果を図 Ⅲ-②-4 に示す。機関全体の46.2％が情報の格付けに関する事項を定めていると回答しているが、規模が大きい機関
ほど策定率が高い傾向にある。国立大学においては B 区分以上で 88.9%、公立大学では
区分 B 以上で 100％、私立大学では区分 A で 72.2%の策定率となっている。

48

図 Ⅲ-②-4 情報の格付けに関する事項

設問２．３ 情報システムの運用に関する諸規則の中で、情報処理を外部委託する場合（パブリッククラウドサービスを利用する場合を含みます）に関する事項を定めていますか？
本設問も設問２で「定めている」と回答した 390 機関に対するもので、機関が情報処理を外部委託する際の手続きについて定めているかを問う設問である。クラウドサービ
スの利用は処理の外部委託とみなすことができるため、そのための手続きが必要となる。
本設問に対する有効回答数は 378 であった。結果を図 Ⅲ-②-5 に示す。定めていると回答した機関は全体の 36.0%であり、約 2/3 の機関では外部委託のための手続きが未整備であることがわかる。

49

図 Ⅲ-②-5 情報処理を外部委託する場合に関する事項

設問２．４ 貴機関では、情報システムの運用に関する諸規則を構成員に周知するための教育を行っていますか？行っている場合、実施状況（対象者や内容、頻度等）
についてご記入ください。
本設問も設問２で「定めている」と回答した 390 機関に対するもので、機関で定めている情報システムの運用に関する諸規則が構成員に適切に周知されているかを問う設問である。
本設問に対する有効回答数は 378 であった。結果を図 Ⅲ-②-6 に示す。構成員への周知のための教育を行っている機関は全体の 51.5%であるが、国立大学、公立大学、高等専門学校、研究機関はそれぞれ 68.1%、68.3%、73.3%となっており、実施率が高い傾向がある。また対象者や内容、頻度などの実施状況について自由記述形式で回答を求めたところ、おおむね以下のようであった。
 新入生／新人教職員向けの講習会＋e ラーニング
 情報リテラシー教育としてカリキュラム化 情報システムの責任者・担当者向けに年数回の講習会を開催
 構成員向けに年 1 回の自己点検
 構成員向けに年数回の講習会（e ラーニングのみの場合を含む）を開催
これらの結果から、ほとんどの機関では、入学時・着任時の導入教育として実施されており、在籍者に対しては年数回開催される講習会への出席や e ラーニングの受講を指示している。また一部の機関では、カリキュラム化するなど受講を必須としている。今回は実施できなかったが、教育の内容や受講率、教育による効果についてはより時間をか50

けて丁寧に調査を行う必要がある。

図 Ⅲ-②-6 諸規則を構成員に周知するための教育の実施状況

設問２．５ 貴機関では、情報セキュリティマネジメントシステム（ISMS）認証を取得
していますか？あるいは取得を予定していますか？
本設問も設問２で「定めている」と回答した 390 機関に対するもので、情報セキュリ
ティ管理に対する意識を問う設問である。情報セキュリティマネジメントシステム（ISMS）は情報システムのセキュリティ管理についてリスク管理（評価と対策）が適切に行われるよう PDCA サイクルが構築されているかどうかを一定の基準によって認証する制度であり、機関自らが構築・運用している情報システム（の一部）について認証を受けているかどうかは、機関の情報セキュリティに対する姿勢にもつながると考えられる。また、機関が情報システムを調達する際には、多くの場合、同様の認証を取得していることを提案業者に求めていることから、アカデミッククラウドを利用する際の指標となることが予想される。
本設問に対する有効回答数は 384 であった。結果を図 Ⅲ-②-7 に示す。すでに取得済み、あるいは取得予定の機関数はそれぞれ 12 と 6 であり、機関全体に占める割合は3.1%、1.6%であった。ISMS の認証取得と認証の継続には体制作りと実施に向けた強力なリーダーシップが必要となることから、取得済み、あるいは取得予定は比較的規模の大きな機関に偏っている。

51

図 Ⅲ-②-7 情報セキュリティマネジメントシステムの認証の取得、取得予定

設問３ 貴機関で過去 1 年間に発生したセキュリティインシデントの件数と内容について、差し支えのない範囲でご記入ください。
各機関が過去 1 年間に遭遇したセキュリティインシデントの件数とその内容について問う設問である。これらの結果から、機関が構築・運用する情報システムに関するセキュリティ面での脆弱性やそれに対する対応の必要性について検討することが可能となると考えられる。
本設問に対する有効回答数は 562 であった。結果を図 Ⅲ-②-に示す。機関全体の31.0％が過去 1 年間にセキュリティインシデントに遭遇している。規模が大きい機関ほどその傾向が高いことから、知名度やアカウント数が多いことによる効率性から攻撃の対象となりやすいと考えられる。また自由記述形式で、発生件数および具体的な内容の提供を求めた。セキュリティインシデントと判断する際の基準は機関ごとにさまざまであることから、文部科学省や情報処理推進機構（IPA）に報告した件数を回答することを想定した。発生件数の内訳を表 Ⅲ-②-2 に示す。
「発生した」と回答した機関の 69.5%
は 10 件未満であった。一方 50 件以上と回答した機関は 9 機関であり、特に 500 件以上の 3 機関は数値が突出していることから、軽微な事象もセキュリティインシデントとしてカウントしたと思われる。具体的なセキュリティインシデントは次のようなものである。
 ウィルス・マルウェア感染
 情報漏えい（ID・パスワード、個人情報）
 ID・パスワードの不正使用
 メールの不正中継・フィッシングメール送信
52

 Web サーバへの攻撃・改ざん 不正アクセス・侵入 P2P ソフトの使用 PC・USB の盗難・紛失
 サーバ・ネットワーク障害
 SNS・クラウドサービスでのファイル共有設定
 著作権侵害

図 Ⅲ-②-8 過去 1 年間に発生したセキュリティインシデント

表 Ⅲ-②-2 セキュリティインシデント発生件数の内訳

国立大

公立大

私立大

短大

高専

研究機関

合計

10 件未満

28

11

56

12

8

6

121

10～49 件

6

1

5

1

0

1

14

50～99 件

1

0

1

0

0

0

2

100～499 件

2

0

2

0

0

0

4

500 件以上

1

0

2

0

0

0

3

未回答

9

2

15

1

1

2

30

合計

47

14

81

14

9

9

174

設問４ 貴機関では、現在パブリッククラウドサービスを利用していますか？あるいは今後利用する予定がありますか？
53

本設問はアンケート実施時点での機関におけるクラウドサービスの利用状況を問うものである。この回答により、アカデミッククラウドの潜在的な利用機関数を見積もることができる。
本設問に対する有効回答数は 580 であった。結果を図 Ⅲ-②-9 に示す。機関全体、あるいは一部のサービスでクラウドサービスを利用している機関は 41.1%であった。規模が小さな機関ほど利用率が高い傾向が見られる。

図 Ⅲ-②-9 パブリッククラウドサービスを利用中あるいは利用予定がありますか？

設問４．１ 利用している、あるいは利用を予定しているパブリッククラウドサービス
は何ですか。差し支えのない範囲でご記入ください。
本設問は設問４において「利用している」あるいは「利用を予定している」と回答した機関に対するものである。回答の大半は電子メールであり、Web サーバやグループウ
ェア等の情報共有のためのシステムが続いている。
 電子メール（Gmail，Yahoo!メール，etc.）
 Web サーバホスティング
 グループウェア
 e ラーニングシステム，ポートフォリオ，アンケートシステム
 Google Apps，Microsoft Office 365，Live@edu 仮想サーバ（Amazon AWS，IIJ GIO，Nifty，さくら，etc.）
 北大アカデミッククラウド

54

設問４．２ 利用を決めた、あるいは利用を決める際の要件は何ですか。
本設問も設問４において「利用している」あるいは「利用を予定している」と回答した機関に対するものである。クラウドサービスの利用を決める要因、利用を決める際に重要視する条件は何であったか（あるか）を問うものである。
本設問に対する有効回答数は 295 であった。結果を図 Ⅲ-②-10 に示す。回答の結果
から、クラウドサービスを利用中あるいは利用を検討している機関は、１．コスト、２．
利便性、３．セキュリティの順で重要視していることがわかる。

図 Ⅲ-②-10

クラウドサービスの利用を決めた、または利用を決める際の要件

設問５ パブリッククラウドサービスを利用しない、あるいは利用を妨げている理由は何ですか。
クラウドサービスを利用しない理由を問う設問である。この結果から、クラウドサー
ビスに対して抱いている不安要素が明らかとなることが期待される。
本設問は設問４において利用中あるいは利用予定がある機関と利用予定がない機関（未定の機関を含む）について集計した。それぞれの有効回答数は 295 と 285 である。
それぞれの結果を図 Ⅲ-②-と図 Ⅲ-②-に示す。いずれにおいても「情報漏えい」などのセキュリティ面に圧倒的な不安を抱いており、以下コスト、利便性と続く結果となっている。セキュリティに対する不安は利用予定がない、つまり利用経験がない機関において高くなる傾向が見られる。

55

設問６

図 Ⅲ-②-11

クラウドサービスを利用しない理由（利用予定のある機関）

図 Ⅲ-②-12

クラウドサービスを利用しない理由（利用予定のない機関）

貴機関の構成員がパブリッククラウドサービスを利用しているか把握していますか？利用している場合、情報の重要度を考慮した上で利用していると思いますか？

本設問は機関におけるクラウドサービスの利用状況を問う設問４に対して、機関に所属する構成員のクラウドサービスの利用状況を問うものである。機関として構成員がクラウドサービスを利用していることを把握しているか、また構成員が利用する際に情報の格付けに基づいた取扱いをしているかを問うことで、構成員への周知の状況を問う設問２．４の効果を計ることができるとともに、情報セキュリティに関するガバナンスが有効に機能しているかどうかの指標となる。
本設問に対する有効回答数は 575 であった。結果を図 Ⅲ-②-2 に示す。機関全体の51.0%が構成員のクラウドサービスの利用状況を把握していないことが明らかとなった。
利用していないと回答した機関は全体の 14.9%である。利用していると回答した機関の約 2/3 は、構成員は情報の格付けに基づいた取扱いをしているとしているが、そのような考慮をすることなく利用していると考えている機関も全体の 12.3%存在する。

56

図 Ⅲ-②-2 構成員がクラウドサービスを利用していることを把握しているか？

設問７ アカデミッククラウドを利用したいと思いますか。
本設問は将来アカデミッククラウドが利用可能となった際に利用する意思があるかどうかを問う設問である。この設問により、アカデミッククラウドに対する期待や不安、要求などを吸い上げることができると考えられる。
本設問に対する有効回答数は 576 であった。結果を図 Ⅲ-②-3 に示す。肯定的な回答である「すでに利用中」「利用したい」「条件によっては利用したい」の合計は機関全体の 66.0%であり、アカデミッククラウドに対する期待が大きいことがわかる。一方、否定的な回答である「利用したくない」は 2.3%あった。また 31.8%の機関は「わからない、判断できない」を選択していることから、アカデミッククラウドの定義をより明確にする必要がある。

57

図 Ⅲ-②-3 アカデミッククラウドを利用したいか？

設問８ 設問７のように回答した理由は何ですか。設問４．２、設問５の選択肢等を参考に、アカデミッククラウドに求める要件、期待すること、問題点等をご記入ください。
本設問は設問７の回答の理由を自由記述形式で問う設問である。より具体的な理由を得るために設けた。主な回答は次のようなものである。
 現状と同等なレベルのサービスが同等以下のコストで実現できるとうれしい 運用管理コストを教育研究に振り替えることで大学サービスを向上できる アカデミックに特化したサービスにより利便性や信頼性の向上が期待できる
 サービスの継続性が担保されているか？
 インシデント発生時等の連絡体制や責任分担が明確であるか？
 業務の標準化が可能か？サービスはどの程度カスタマイズ可能か？
 どのようなサービスが提供されるか不明なため判断できない
現在情報システムを構築・運用している機関にとって、現状と同等以上のサービスを同等以下のコストで実現できることへの期待が大きい。またその余剰コストを教育研究に振り向けることで機関全体のパフォーマンスの向上に期待していることがわかる。一方、自機関と同様な機関が運用するサービスに対する継続性やインシデント発生時の責任体制に対する不安を挙げる機関も多く見られた。コストと管理運用体制のバランスによるものであるが、自らがコントロールできない点に対する不安であり、「利用したくない」と考える要因の一つ考えることができる。一方、サービスを標準化することに対する拒否反応と考えられる回答も見られた。「わからない、判断できない」と回答した多くの組織は、アカデミッククラウドにおいてどのようなサービスが提供されるのか不明
である点を指摘している。アカデミッククラウドによって提供される、あるいは提供さ58

れるべきサービスは本事業の成果として明確にする必要がある。
2. 検討結果
セキュリティ分野に関するアンケート結果から、66.9%の機関は情報システムの運用に関する諸規則（セキュリティポリシー等）を定めており、そのうち約 7 割の機関は「高等教育機関の情報セキュリティ対策のためのサンプル規程集」またはこの源流あるいは支流に相当する政府機関や地方公共団体、国立高等専門学校機構等のための統一基準やサンプル規程集、他大学等の規則を参考としていた。したがって、本事業における検討の基準を「高等教育機関の情報セキュリティ対策のためのサンプル規程集」とすることで、大半の機関はその成果を自らの機関の諸規則にスムーズに反映させることが可能となると考えられる。
一方、情報の格付けや外部委託する場合に関する諸規則の整備は、情報システムの運用に関する諸規則を定めている機関のそれぞれ 46.2%と 36.0%であり、機関全体に占める割合は 3 割にも満たない状況である。クラウドサービスの利用は情報処理の外部委託とみなすことができることから、アカデミックな機関によるクラウドサービスの利用を推進していくためには、情報処理を外部委託する場合の諸規則を定める必要がある。またその際には、あらかじめ情報の機密性、完全性、可用性に応じた取扱いが定められ、委託先において適切に取り扱われることを確認する必要がある。
情報の格付けについては、「高等教育機関の情報セキュリティ対策のためのサンプル
規程集」の「B2104 情報格付け基準」においてその基準が示されている（表 Ⅲ-②-3）。

59

表 Ⅲ-②-3 情報格付け基準（「高等教育機関の情報セキュリティ対策のためのサンプル規程集」より抜粋）

表 Ⅲ-②-3 のように、「B2104 情報格付け基準」においては機密性 3 段階、完全性 2 段
階、可用性 2 段階に分類されており、その組合せは 12 通りに及び。また機関が保有する情報にはこれらに加えて取扱制限（禁止事項、要許可、暗号化必須、参照者制限など）が設けられるため、その組合せはさらに増大する。
先に述べたように、機関が保有する情報をクラウドに預ける場合、その格付けに応じた取扱いができるよう、基準を満足するクラウドサービスを選択する必要がある。クラウドサービスに預ける情報の格付けおよび取扱制限に幅がある場合、利用者はそれらの中でもっとも厳しい条件に合致するようクラウドサービスを選択する必要がある。しかし、個々のクラウドサービスについて細かく確認・制御することは現実的ではない。そこでセキュリティ分野では、機関が保有する情報を重要度として大きく 4 段階に分類し、情報格付け基準との対応関係を示した表 Ⅲ-②-4 を作成した。

60

表 Ⅲ-②-4 機関が保有する情報の重要度

表 Ⅲ-②-4 において、情報格付け基準での組合せは 3-1-2 のように機密性、完全性、可用性の 3 項組で表現した。基本的には機密性の違いが重要度に反映されるようになっている。ただし 3 項組が同じであっても、その情報の性格や取扱制限によって重要度が異なる場合があるため、対応関係には一定の幅を持たせている。また完全性については、
完全性 2 の情報は完全性 1 の情報よりも重要度が 1 ランク高くなるよう配置している。
クラウドサービスの利用において情報の完全性を保証する方法としては、情報に対するアクセス制限で行うことが一般的であることから、機密性を大分類の、完全性を小分類の要素として扱ったことに寄っている。一方可用性については、その違いによって特別な差異を設けていない。クラウドサービスをはじめとして第三者に情報を預ける場合、
あらかじめ複製（バックアップ）を作成しておく、あるいは預け先で複製を作成し異なる方法で保管させるなどの措置を講じることを原則とすべきであるためである。
4 段階の重要度に分類された情報に対して、セキュリティ分野ではそれらを保存する
クラウドサービスの信頼性を同じく 4 段階の信頼度で定義した。信頼度 n のクラウドサ
ービスは重要度 n の情報を保存できる信頼性を有すると定義する。クラウドサービスの信頼度を表 Ⅲ-②-5 に示す。
表 Ⅲ-②-5 クラウドサービスの信頼度61

表 Ⅲ-②-5 にしたがうと、信頼度 n のクラウドサービスには重要度 n 以下の情報を保存することができる。例えば、信頼度Ⅲのクラウドサービスは重要度Ⅲの情報を保存できる信頼性を有し、重要度Ⅲ以下（重要度Ⅰ～Ⅲ）の情報を保存できることを表している。
次にセキュリティ分野では、機関が機関内に保有する情報をクラウドサービスに預けることを想定し、クラウドサービスの利用シーンを図 Ⅲ-②-4 のようにモデル化した。

図 Ⅲ-②-4 クラウドサービスの利用シーンと評価軸

図 Ⅲ-②-4 では、クラウドサービスを機関の遠隔拠点とみなし、セキュリティ上の脅
威からその拠点そのもの、およびその拠点と情報をやり取りする通信路を保護する措置
および手段をクラウドサービスの信頼性に関する評価軸とした。具体的には以下の 3 点である。
 評価軸①：独立性の高さ（他の利用者からの隔離） 評価軸②：アクセス制御（利用者認証に基づく制御）
 評価軸③：通信路の安全性（暗号化やアクセス区域の制限）
以下、それぞれについて検討する。
評価軸①：独立性の高さ
62

クラウドサービスは、計算資源を仮想化技術によって複数の層（レイヤ）に分割し、それぞれのレイヤを責任分界点とするサービスモデルによって表現される。サービスモ
デルの代表的なものとしては IaaS（Infrastructure as a Service）、PaaS（Platform as
a Service）、SaaS（Software as a Service）などがあり、それぞれ仮想サーバ、基盤
ソフトウェア（Web や DB など）、アプリケーションが責任分界点となる。セキュリティ
分野では、これらのクラウドサービスが持つ構造に着目し、サービスモデルおよびその実装方法によって利用者間の独立性の高さ（隔離の度合い）を定義した。図 Ⅲ-②-5に SaaS の例を示す。

図 Ⅲ-②-5 独立性の高さ（SaaS の例）

図 Ⅲ-②-5 において、クラウド事業者はアプリケーション（薄青色）を提供する（SaaS）
ため、赤い波線が責任分界ラインとなる。したがって、アプリケーション以下のレイヤ
はクラウド事業者の責任において実装および運用が行われることになり、利用者はクラウド事業者が提供するサービス仕様書やヒアリングなどからサービスモデルや実装方法を確認し、SLA（サービス品質保証：Service Level Agreement）やその他の事項に合意した上でサービスの利用を開始することとなる。この確認段階において、自機関の利用者と他機関の利用者との間で共用されるレイヤと占用されるレイヤを確認することで、責任分界ラインからの“溝の深さ”によって独立性の高さを保証できるとした。責任分界ラインよりも下位のレイヤはクラウド事業者の責任においてサービス仕様書等に基づいた構築・運用がなされることを保証の根拠とするものである。この考えに基づ
くと、
IaaS や PaaS はそれぞれ図Ⅲ-②-6 と図Ⅲ-②-7 のように表現することができる。
図Ⅲ-②-6 の IaaS の例では、利用者ごとに独立した仮想サーバが提供され、OS が責任
分界ラインとなることから、独立性はあると判断することができる。一方図Ⅲ-②-7 のPaaS の例では、基盤ソフトウェアを他機関の利用者と共用しているため、独立性がな
いと判断することができる。
63

図Ⅲ-②-6

独立性の高さ（IaaS の例）

図Ⅲ-②-7

独立性の高さ（PaaS の例）

以上を例として、サービスモデルと実装方法に基づいてクラウドサービスの信頼度との対応関係を表したものを図Ⅲ-②-8 に示す。なお、図Ⅲ-②-8 は一例であり、機関における情報の重要度やクラウドサービスの信頼度の定義により調整が必要である。

64

図Ⅲ-②-8

サービス（実装方法）と信頼度の対応

評価軸②：アクセス制御
図 Ⅲ-②-4 で示したように、ここではクラウドサービスを機関の遠隔拠点と位置付けている。そのため、積極的な公開を前提とする重要度Ⅰの情報を除く重要度Ⅱ以上の情報については、機関において保存する場合と同様にファイアウォール等で保護された領域に保存されるべきである。そこでセキュリティ分野においてはアクセス制御の有無を評価軸のひとつとした。
なお、アクセス制御の実現には認証と認可のプロセスの検討が必要となる。認証については、保存する情報の重要度に応じてアクセスできる利用者を限定し、認証強度によってその真正性を確保することが必要である。認証強度に関する検討は認証連携分野によって行われる予定である。一方、認可については、保存する情報の重要度や認証結果
によって領域の保護レベルを設けることが考えられる。保護レベルに関する検討はネッ
トワーク分野によって行われる予定である。
評価軸③：通信路の安全性
前項と同様に、機関の遠隔拠点であるクラウドサービスと機関あるいは情報の発生源を結ぶ通信路についても、重要度Ⅱ以上の情報が通る部分については保護されるべきである。そこでセキュリティ分野においては、前項と同様に通信路の安全対策の有無を評
価軸のひとつとした。
なお、通信路の安全対策には通信路そのものに対する安全対策と通信路の端点に対する安全対策が必要である。通信路そのものの安全対策については、SSL による通信路の65暗号化などが対象となろう。一方、通信路の端点の安全対策については、クラウドサー
ビス側における保護レベルに対応した適切なアクセス環境が定義される必要がある。具体的には、機関内外からのアクセスをどのようにレベル分けするか、VPN による接続を機関内からのアクセスと同様とみなすかなど、アクセス環境のレベル分けとそれに対応する認証強度との対応付けの検討が必要である。これらの検討についてはネットワーク
分野によって行われる予定である。
以上の検討結果から、セキュリティ分野ではクラウドサービスの信頼度と 3 つの評価軸との対応関係をクラウドサービス利用基準としてまとめた。図Ⅲ-②-に示す。

図Ⅲ-②-20 クラウドサービス利用基準

図Ⅲ-②-の見方は次のとおりである。まず、利用を検討しているクラウドサービスのサービス仕様書やヒアリングにより、3 つの評価軸の対応状況を確認する。それぞれの評
価軸について、図の左から右に走査し、縦串（信頼度Ⅳ-1～信頼度Ⅰ-1）と交わる点を確認する。交わる点が太く（丸く）なっている場合は、その縦串の条件を満たすという意味である。そしてすべての評価要件について条件を満たす縦串がそのクラウドサービ
スに対する信頼度の評価となる。例えば評価の結果、以下のようになったとする。
 評価軸①：ハードウェア（仮想マシン）レベル：独立性なし
ソフトウェアレベル：機関単位での独立性あり66

 評価軸②：アクセス制御：制限あり
 評価軸③：通信路の安全性：対策あり
この場合、そのクラウドサービスは「信頼度Ⅲ-1」と判断される。
なお、信頼度Ⅳ-1 と信頼度Ⅳ-2 のクラウドサービスはいずれも信頼度Ⅳと判定されるが、ハードウェア（仮想マシン）レベルでの独立性の有無に違いがある。ソフトウェア
レベルの独立性への依存度が高くなることから、信頼度Ⅳ-2 を選択する場合にはクラウド事業者の運用手順やセキュリティ対策の確認をより慎重に評価するなどの対応が必要である。
以上の検討はクラウドサービスの計画段階での評価である。今回は十分に検討を行うことができなかったが、クラウドサービスを運用する段階においては、さらに次の要件についても検討の余地がある。
 情報の暗号化（個々の情報に対する機密性保護の有無）
 情報の冗長化（個々の情報の複製の有無と保存場所の選択）
これらの要件はクラウドサービスの機能による実現のほか、運用での対策として実施できることから運用段階の基準とした。機関におけるクラウドサービスの運用手順がこれ
らの基準に対応することによって、クラウドサービスの信頼度を向上させることができる可能性がある（図Ⅲ-②-9）。ただし、運用手順が厳密に守られないと信頼度が下がる
ことになるため、運用手順を徹底するための利用者教育などの対策がより一層重要となる。特に情報の暗号化について、アルゴリズムの安全性に関する議論は行われているが、アプリケーションの選択方法や使用方法などのガイドラインはまだ示されていない。そのため、プライバシー分野による検討との連携を図るとともに CRYPTREC による検討状
況にも注意する必要がある。

67

図Ⅲ-②-9

クラウドサービス利用基準（含運用基準）

3. 要求要件（標準仕様）
2.においてセキュリティ分野では、情報の格付けの必要性について述べ、情報の重要度への分類方法を示した。またクラウドサービスが提供する機能に基づいてその信頼性を計る評価軸を定義し、その評価軸にそってクラウドサービスの信頼度を評価する方法を示した。そして、情報の重要度とクラウドサービスの信頼度の対応をクラウドサービス
利用基準として示した。
ここではこれまでの検討内容を含めて、アカデミックな機関が保有する情報をクラウ
ドサービスに保管する場合に確認すべき項目について述べる。
(1) 利用に向けた準備(ア) 取り扱う情報の確認
68 情報の格付け
どの情報をクラウドサービス上に保存するのか（どの業務をクラウドサー
ビスに移行するのか）を検討します。（表 Ⅲ-②-4）
 クラウドサービスの選択
クラウドサービス利用基準（図Ⅲ-②-9）に照らして、情報の重要度に応じたクラウドサービスを選択します。
(イ) 機関側の組織・体制
 クラウドサービス利用責任者
クラウドサービスの利用に関する責任者を決めます。責任者が不明だと、契約事項の確認やインシデント発生時の対応が難しくなります。
 クラウドサービス利用担当者
クラウドサービス事業者との窓口となる担当者を決めます。担当者は、クラウドサービス事業者との連絡のほか、ユーザアカウントの登録や削除、利用マニュアルの整備や指導、ヘルプデスクなどの業務を担当します。
(ウ) 機関の規則・契約
 規則との整合性
機関のセキュリティポリシー、機関が保有する情報の取扱い規則、個人情報の取扱い規則などに準拠していることを確認します。情報の管理者が定められている場合は、クラウドサービス利用責任者は情報の管理者に報告
し、許可を得る必要があります。
 契約の取扱い
クラウドサービスの利用は業務の外部委託と同等です。契約の様式が異なっていても、機関の外部委託契約の基準に準拠している必要があります。
個人情報や機密性の高い情報が含まれている場合、それぞれの取扱い規則との整合性の確認が必要です。約款による契約の場合でもこれらに準じた取扱いが必要です。
(2) 利用範囲の明確化(ア) サービスの品質
 SLA（Service Level Agreement）
クラウドサービスが安定して提供されないと利用者の業務遂行に支障をきたす恐れがあります。サービス停止の頻度や時間、応答時間などの性能、障害による停止時間や復旧時間が、利用を予定している業務の重要度に照らして許容できる範囲かどうかの検討が必要です。
 メンテナンス
障害への対応やバージョンアップなどの定期保守によってサービスが停止する場合があります。特に定期保守は日時が指定できない場合がありま69す。これらが利用者サービスに与える影響を評価し、許容できるかを検討します。
 問い合わせ窓口・サポート体制
定期保守や障害時のクラウド事業者からの連絡方法および利用者からの問い合わせ窓口の確認が必要です。また利用者がサービスの状況を調べる
方法や利用者向けの支援体制の有無と利用可能時間の確認が必要です。問
い合わせや支援の依頼を利用者が個々に行うのか、担当者が取りまとめる
必要があるのかの確認も必要です。
 サービスの継続性
サービスが継続的に提供されるかどうかは、クラウドサービスに移行するかどうかを判断する上で非常に重要です。特にクラウド事業者特有のサービスを利用する場合は、サービスの提供期間と契約終了後の代替手段の検討が必要です。
(イ) 機能とコスト ネットワークサービスの利用に関してはクラウドサービス利用基準に準じていることが必要です。また担当者が管理を行う場合、管理業務を安全に行うことができるよう暗号化された通信路や適切なアクセス制御が行われていることを確認する必要があります。
 管理ツール
利用者の管理、アクセス権の設定、メニューの選択など業務を行う上で必要な管理機能が提供されていることを確認します。一般的な機能であっても、明示されていない機能は提供されていない場合があります。
 ライセンス機関が有しているライセンスをクラウドサービス上で利用することが可能かどうか確認する必要があります。使用機材に紐付けられたライセンス、
実環境と仮想環境で異なるライセンス体系を持つもの、クラウドサービス
上での利用が許可されていないものなどがあります。
 スケーラビリティ
リソース不足によるサービス低下を招くことがないよう、事前に必要な性能やデータ量などを検討しておく必要があります。また利用者数やデータ量の増加に対応できるか、その際の追加費用についても確認しておく必要があります。また時期によって負荷が大きく変動する業務への対応可能性についても確認する必要があります。
 利用料
平常時の費用だけでなく、現行システムからのデータ移行、カスタマイズ
70

にかかる費用などの一時的な費用、認証システムや既存のシステムとの連携のための費用などの追加的な費用が発生する場合があります。
 回線使用料
回線使用料には定額制のものと従量制のものがあります。不正アクセスなどの攻撃により通信量が急増する場合があるので、従量制を選択する場合には費用負担の考え方を確認しておく必要があります。
 ストレージ
ストレージ価格に含まれる上限値の確認が必要です。高性能なストレージに大量のデータを保存するとかえってコストが高くなる場合があります。
用途に応じたストレージを選択する必要があります。
(3) クラウド事業者の選定(ア) データセンター データセンターの場所
データセンターの場所を確認します。データセンターが海外の場合は、準拠法などの確認が必要です。サービスによっては場所が開示されない場合があります。
 堅牢性
データセンターの物理的堅牢性を確認します。建物の耐震性、火災や水害への対策は重要です。また電源や空調の冗長性などについても確認します。
 機密性
情報システムの機密性が高くても、設置場所の物理的な機密性が低ければ、その価値が大きく下がります。入館管理や監視体制などを確認します。
(イ) クラウド事業者の信頼性
 経営状況の確認
安定的なサービス提供がなければ、業務に支障をきたす可能性があります。
クラウド事業者が他の事業者に買収された場合、これまでの同意事項が維持されず、セキュリティ要件に適合しなくなる場合があります。
 委託関係の確認
クラウド事業者は利用者との契約と異なる条件で第三者に外部委託したり、下請け契約を結んだりする場合があります。クラウド事業者が第三者のクラウドサービスを利用していることを明言していない場合、利用者がリスクを適切に評価できない場合があります。また第三者に委託していたクラウドサービスの終了などにより、サービスが継続できなくなったり、契約条件が変更されたりする場合があります。
(4) 契約条件の確認(ア) 責任範囲とペナルティ71

 責任範囲の明確化
障害発生時のクラウド事業者と利用者との責任分界点を確認しておく必要があります。クラウドサービスは多数の顧客に画一的なサービスを提供することで成り立っていることの理解が必要です。そのためサービス内容
が少しずつ変更される可能性があります。変更に際する事前通知の有無や周知期間、不同意の場合の対応などをあらかじめ確認しておく必要があります。
 ペナルティ
クラウド事業者側の過失でサービスの停止、データの喪失や情報漏洩などが発生した場合の賠償の範囲や方法について確認が必要です。被害が甚大であっても、サービス停止・障害の間の料金の減額のみの保証であったり、明示的なペナルティ請求が必要であったりするため、契約条件の確認が必要です。
(イ) データの所有権、返却・消去
 データの所有権
クラウドサービスに保存したデータに対してクラウド事業者に所有権や利用権が発生する場合があります。
 データの返却
契約解約時や終了時にデータが完全な形で返却されない場合があります。
一つひとつのデータは取り出すことができても、まとまった形で取り出すことができない場合があります。他のクラウドサービスに移行する際、移行サービスが受けられない、あるいは多額の費用がかかる場合があります。
 データの消去
契約解約時や終了時にデータの消去を選択する場合、確実に消去されたことを確認できるか確認します。証明書を発行してもらうことができる場合があります。
(ウ) 準拠法と管轄裁判所
 準拠法
クラウドサービスに保存したデータは、サーバの設置場所の法律に準拠する場合があります。日本国内から利用していても、データの管理上の準拠法が異なる場合があります。また捜査機関がデータを差し押さえることを認めている国もあります。
 管轄裁判所
クラウド事業者によっては、本社の所在地を管轄裁判所としている場合があります。係争に発展した場合には多額の裁判費用がかかる場合があります。
72

(5) 運用体制の確認(ア) システムの運用に関する項目
 セキュリティ対策
クラウド事業者側が運用する部分、機関側が運用する部分それぞれについて、セキュリティ対策が適切に行われているか確認します。機関側で疑似攻撃を伴う脆弱性のチェックを行う場合は、クラウド事業者に攻撃とみなされないよう注意が必要です。
 ログの監視
運用ログやセキュリティ・ログが適切に保存されているか確認します。クラウドサービスの評価を行う際にも必要になります。クラウドサービス利用担当者がログを確認できない場合は、クラウド事業者から定期的に利用状況のレポートをもらうなど調整が必要な場合があります。
(イ) データの管理に関する項目
 秘密鍵の管理
クラウドサービスを管理するための秘密鍵は非常に重要です。秘密鍵が紛
失、破壊、漏えいしないよう厳重に管理する必要があります。また、クラウドサービスの利用者や利用担当者のパスワードの再発行手順についても確認が必要です。
 バックアップ
重要度が高いデータは消失に備えてバックアップが必要です。クラウドサ
ービスに障害が発生していなくても、ネットワークの障害によってデータにアクセスできなくなる場合があります。
(ウ) インシデントの管理に関する項目
 インシデントの記録
クラウドサービス上で発生したインシデントについても機関内と同様に管理することが求められます。また、機関側の責任でインシデントが発生した場合のペナルティについて確認しておく必要があります。
以上を確認するためのチェックリストを別添資料 1.に示す。

73

③ 事務支援に係るアカデミッククラウドシステムの調査検討（概要）国内主要大学（北海道大学、東北大学、東京大学、早稲田大学、慶応大学、国士舘大学、信州大学、静岡大学、大阪大学、関西大学、徳島大学、九州大学）における事務支援システムの構築状況やクラウド活用状況をヒアリングし、課題やアカデ
ミッククラウドへの要望について議論した。また、ホームページ等を利用してKuali
等の海外での事務支援分野の取組に関する情報収集を行った。調査結果は、大規模ア
ンケート調査の内容へ反映するとともに、アンケート結果分析やアカデミッククラウ
ド環境の検討に反映した。上記事例調査の内容も加味してアカデミッククラウドのニーズ、課題、及び、アカデミッククラウド構築に必要な基礎データを収集するためのアンケート内容を検討し、アンケートを作成した。アンケート調査結果を集計し、事例調査の結果とともに、事務分野から見たアカデミッククラウド環境構築の課題や効果を明確化し、課題解決のための方策を検討した。また、事務分野から見たアカデミ
ッククラウド環境としてあるべき姿を検討し、アカデミッククラウドの要件として整理するとともに、他分野での分析・検討とも連携協力して標準仕様案へ反映した。事業計画、検討状況、分析結果等をキックオフシンポジウム、中間報告会、最終報告会で報告するとともに、事務分野におけるアカデミッククラウドの調査・分析・検討内
容、および、標準仕様案への提案を報告書としてまとめた。
1. アンケート調査結果
人事給与システム、財務会計システ
ム、学務情報システム、就職支援シス
テム、出退勤システムを対象として・システムの規模、計算機資源量、データ量・システムの保守運用体制、稼働
・クラウドサービス活用等の取組み状
図 Ⅲ-③-1 回答機関数と機関別回答数

況、今後の利用意向、課題
・アプリケーションの開発形態
・BCP（Business Continuity Plan）対策の状況等についてアンケート調査を実施し、530 機関、1013 システムから回答を得た。（図Ⅲ-③-1 参照）
主なアンケート集計結果を以下に示す。

図Ⅲ-③-2 利用者数区分別システム数i) システムの規模と計算機資源量74

表Ⅲ-③-1 １システム当たりの平均資源量と総資源量

利用者総数 1,000 人以下のシステム
が 74%、ピーク時利用者 500 人以下のシステムが 86%と小規模なシステムが大半を占める。
（図Ⅲ-③-2 参照） サ
ーバ総数は 3,927 台(889 システム)、1
システム当たり平均 4.4 台で、1 サーバ
当たりの平均計算機資源量は CPU3.6 コ
ア、メモリ 15.5GB と昨今のパーソナル

図 Ⅲ-③-6

サーバ台数毎のシステム運用稼働

コンピュータと変わらない資源量になっている。
（表 Ⅲ-③-1 参照）また、サーバ 2 台以下のシステムが 51%で、計算機資源の面からも小規模なシステムが多い。（図Ⅲ-③-3 参照）ii) システムが保有するデータ量
1 システム当たりの平均総データ量は 671.8GB（408 機関、776 システム）トータル
で約 521TB。
（表 Ⅲ-③-1 参照）全高等教育機関（約 1,234 機関）は回答があった機関の約 3 倍、アンケート対象外のシステムも含めた事務支援に係るシステムが 2~3 倍として、全高等教育機関の事務支援に係るシステムトータルで 3~5PB 程度と推定される。
事務支援に係るシステムが保有するデータは、画像や映像データが少なく、数値やテキストが中心であることから、研究支援分野や教育支援分野に比べるとデータ量はかなり少ない。
iii) システムの運用形態と稼働回答があったシステム全体の約50%（530 システム）、国立大学の約 75%(167 システム)では、教職員のみで運用を行っており、平均約1.7 人年の稼働かけている。
（図 Ⅲ-③-4、図Ⅲ-③-5 参照）また、業図Ⅲ-③-4 サーバ分類・運用形態毎のシステム数者への委託も行っているシステム
も合わせて、教職員の稼働はトータルで 1207.7 人年（635 システム）と大きな稼働になっている。業者
への委託稼働含めた１システム当たり平均稼働は約 2.1 人年（779システム）で、サーバ台数で比較
すると、サーバ 1 台の平均が 1.5
人年、サーバ 5 台の平均が 2.7 人

図Ⅲ-③-5 機関分類・運用形態毎のシステム当たりの平均運用稼働

年、11 台以上の平均が 4.8 人年と75

サーバ台数の増加に比べて稼働の増加は緩やかになっている。
（図 Ⅲ-③-6 参照）クラウドサービスを活用してシステムを集約することによって、トータルの運用稼働の削減が可能であるとともに、規模の小さなシステムを集約する方が、削減効果が大きいと考えられる。
iv) クラウドサービスの活用状況
クラウドサービスを活用しているシステムは約 11.4%（101 システム）で、パブリッ
ククラウドの利用は約 2.2%（20 システム）と現状はまだ少ない。
（図 Ⅲ-③-7 参照）
プライベートクラウドは全回答機関の約 9.4%、50 機関（76 システム）で利用されているが、国立大学では回答があった機関の 21.3%、16 機関で、規模の大きな大学（分類 A）では 26.8%、11 機関でプ
ライベートクラウドが活用されている。サーバ数が多い大規模機関では、プライベート
クラウド活用によるシステム
集約の効果が大きいことが要因と考えられる。
v) パブリッククラウド（IaaS、 図 サーバ-8 パブリッククラウド（IaaS,PaaS パブリッククラ
PaaS）の利用意向「今後も利用しない・課題があって難しい」（38%）が「できれば利用したい」を含む前向きな回答をやや上回っており（図3.1-8 参照）、
「今後も利用しな
い・課題があって難しい」の理由として、回答者の半数以上がセキュリティの課題を挙げている。（図 Ⅲ-③-9 参照）

図 サーバ-8 パブリッククラウド（IaaS,PaaS パブリッククラvi) SaaS の利用意向
パブリッククラウド（IaaS、PaaS）と同様の傾向であるが、アプリケーションの仕様や移行に関する課題を挙げている回答が増加しており、IaaS、PaaS 同様にセキュリ
ティ対策が重要な課題であるとともに、現行の業務アプリケーションからの移行をどう実現するかが課題になると考えられる。(図 Ⅲ-③-10 参照)
業務アプリケーションソフトウェアの形態

76

業務アプリケーションソフトウェアの開発にあたって、全体の約 75%が業務用パッケージソフトウェアを利用しており（図 Ⅲ-③-11 参照）、
業務用パッケージソフトウェアを利用している中で、80%以上のシステム
で何らかのカスタマイズを実施し、30%以上が大幅なカスタマイズを実施している（図 Ⅲ-③-12 参照）。規
模の大きな機関程、大幅なカスタマ

図 Ⅲ-③-13

業務パッケージ毎の利用システム数イズを実施しているケースが多い。
また、国立、私立等機関の種別や規模によって利用している業務用パッケージソフトウェアが異なる傾向にあるが、73 システムで利用されている業務用パッケージソフトウ
ェアがあるとともに、10 システム以上で利用されているものが 17 あり、

図 Ⅲ-③-10 SaaS 利用意向
利用しない、課題ありと回答した理由等詳細

この 17 業務用パッケージソフト
ウェアはトータルで、432 システム（回答があった 92%）で利用されている。
（図 Ⅲ-③-13 参照）このことから、業務用パッケージソ
フトウェアの共同開発や SaaS 開発の可能性は十分にあると考えられる。

パブリッククラウドアプリケーション形態毎のシステム分布vii) BCP 対策「災害時でも継続してシステムの稼働が必要」（28%）、「データの保全は最低限必要」（59%）合わせ、約87%が何らかの BCP 対策が必要と考えているが、BCP 対策が必要と回答したシステムで実施済が 19%、計画中 9%

図 Ⅲ-③-12

業務パッケージカスタマイズ状況

を含めても 28%で対策が遅れている（図 Ⅲ-③-14 参照）。事務支援に係るシステムの BCP 対策は、大学運営を継続する上で非常に重要であり、BCP 対策が容易に実現できる環境をアカデミッククラウド等に77よって早急に構築すべきと考える。
viii) アカデミッククラウドへの要望等
アカデミッククラウドへの要
望は 35 件で、その内訳は、セキ
ュリティに関する要望が 12 件、コストに関する要望が 9 件あった。
（詳細は資料 1 参照） また、

図 Ⅲ-③-16 サーバ台数とシステム運用稼働の相関と線形回帰直線

その他コメント等から機関をまたがったシステム統合や共同利用について以下の状況が把握できた。
・高専機構では事務支援含む
共同利用サービスを各高専に提供している。
・一部の公立大学では自治体のシステムを利用している。
・一部の系列機関（4 年制大

図 Ⅲ-③-14

BCP 対策の必要性と実施状況

学、短大等）でシステムを共同利用している。
2. 検討結果i) クラウドサービス活用により期待できる効果
事務支援に係るシステムにおけるクラウドサービス活用の効果としては、図 Ⅲ-③-15に示すように、２つの軸が考えられる。
一つは、システム集約の軸で、システムの保守運用コストやハードウェア等への投資コストの低減が期待でき、集約するシステ
ムが多くなるほど効果が大きくなると考えられる。例えば、アン
ケートでサーバ数と運用稼働の両方で回答があった 733 システム
では、3,366 台のサーバを 1,572
人年の稼働をかけて運用してい図 Ⅲ-③-15 クラウドサービス活用により期待できる効果

78

るが、これを集約した場合、図 Ⅲ-③-16 のサーバ台数と運用稼働の相関から単純に試算すると、およそ 383 人年程度で運用できるとことになる。機関やシステム毎に実施しなければならない運用もあるため、単純に 1/4 になる分けではないが、全体の 1/2 が集約できると仮定すると 4 割弱の稼働削減が可能である。また、専門的技術を持った要員が集中的に運用することによる効果も期待できるため、稼働削減に加えて保守運用の質的向上（可用性向上等）も期待できる。さらに、1,572 人年の稼働の内、教職員の稼働が 1,141 人年を占めており、削減できた稼働を本来の機関のミッションである教育や研究にあてることが可能になるため、成果の拡大が期待できる。
もう一つは、サービスレベルの軸で、計算機資源が利用可能な IaaS、ミドルウェア
やパッケージソフトウェア等の部品やツールも利用可能な PaaS、アプリケーションも含めてサービスとして利用可能な SaaS と、利用できる資源の範囲の拡大に従って、開発構築含めたシステム投資コストの削減、システム構築期間の短縮、業務やシステムの運用保守稼働の削減等の効果が拡大すると考えられる。現状は、アカデミック向けの事
務支援業務用 SaaS は殆ど提供されていない状況であるが、同じ業務用パッケージソフ
トウェアを利用している機関やパッケージベンダーが協力して SaaS を開発できれば、より大きな効果が期待できることになる。アンケート回答結果からも、同じ業務用パッケージソフトウェアを利用しているシステムが多数あることから、コミュニティベースのアカデミッククラウド環境が整備されれば十分に実現可能と考えられる。
この 2 つの軸とは別に、クラウドサービス活用により期待できる効果として、システ
ムの可用性向上があげられる。仮想化技術により、物理的な障害に対する可用性が向上
するとともに、システムイメージのバックアップによって短時間にシステム再構築が可能になる。また、大規模災害対策には広域分散型のクラウド環境が必要になるが、アカデミッククラウドによって広域分散型クラウドサービスが利用できるようになれば、対応が遅れている事務支援システムの BCP 対策の促進が期待できる。
ii) データの収集や利活用により期待できる効果
表 Ⅲ-③-2 にアンケート対象とした５つの事務支援システムの特徴等を示す。事務
支援に係るシステムは教職員や学生の活動に関する多様な情報を保有しており、そのデータを収集、分析することにより、経営戦略の策定、教職員の育成、教育内容の充実等、様々な活用が期待できる。例えば、学務情報システムや就職支援システムが保有する学生の活動に関するデータや企業情報は、e ポートフォリオや就職支援サービスの充実に活用が期待できる。また、財務会計システム等が保有する調達、購買に関するデータは、分析や利活用によって価格や稼働の低減、調達処理の迅速化が期待でき、教育研究活動の充実やスピードアップの効果も期待できる。さらに、研究や教育活動に必要な資材を調達するサービスが SaaS として利用できるようになれば、その効果は一層大きなものになると思われる。なお、事務支援に係るシステムのデータは全て収集しても５PB 程79

度であり、比較的小規模な計算機資源でも収集、分析が可能である。
iii) クラウドサービス活用にあたっての課題と解決策
アンケート回答結果では、パブリッククラウド等の機関外のクラウドサービス利用にあたっての最大の課題や不安としてセキュリティが挙げられている。表 Ⅲ-③-2 に示したように事務支援システムは、基本的に個人情報や機密情報に係るデータを数多く保有していることが要因で、以下に示す課題が考えられる。
・クラウドサービス利用において、セキュリティに関するリスク、あるいは、安全性を判断する基準がない、また、個々のクラウドサービスでも判断に必要な仕様等が提示されていない。
・各機関のセキュリティポリシーや運用基準が、機関外のサービス利用を想定していない（規定がない）、あるいは、単純に禁止している。また、判断基準も明確ではない。
これら課題の解決に向けては、情報の格付けとその格付けに対応して必要なセキュリテ
ィ対策要件を明確にし、クラウドサービス提供側と利用側双方で、サービスの条件と要件を規定する必要がある。詳しくは、セキュリティ分野、認証連携分野、プライバシィ
分野で議論される。
セキュリティ以外では、性能や信頼性など含めたサービス品質の課題や不安が挙げられている。セキュリティと同様にサービス品質を判断するための基準がないことが原因と考えられ、SLA の基準策定が必要である。また、事務支援に係るシステムは、長期にわたってシステムを継続維持できることが重要な要件となるが、サービス提供事業者の都合でサービスが終了したり仕様が変更されたりしてサービスが使えなくなるリスクがあるため、事業者の評価方法や選定方法も課題になる。詳細な SLA を規定し、サービ
表 Ⅲ-③-2
システム

主なサービス（機能）

人事給与
システム

人事管理、給与計算、
電子申請、教職員健康
管理

財務会計
システム

予算管理、会計、調達
購買、財産管理、寄付
管理、奨学金支払

学務情報
システム

就職支援
システム

出退勤
システム

事務支援システムの特徴等

データの収集や利活用により期待できる効果
教職員の活動データとして、研修、機関によって人事制度が区々
教職員の人事情報、評価デー キャリアパス、資格、評価等の情報だが、人事制度そのものの大 職員（人事）タ、家族情報など個人情報、 を収集、分析することにより、人材
きな変更は稀。
機密情報が多い。
育成やキャリア設計に生かせる可能性がある。
国公立と私立で会計制度が異
個人情報は利用者管理情報 調達情報の分析や利活用を行うこなるが、会計制度そのものの 職員（会計、購程度だが、予算情報、購買とによって、価格や稼働の低減、調大きな変更は稀。
買）（取引）情報、銀行口座情報な 達の迅速化が期待できる。
寄付の扱いや予算管理の方法 、教職員（予算管 ど機密情報を保有する。（国 予算と教育や研究の成果を分析す
は機関により異なるケースが 理者等）
公立と私立では取引情報に関 ることにより、経営戦略に生かせる多い。
する機密の扱いが異なる。） 可能性がある。
システムの特徴

利用者

保有するデータの特徴

学生基本情報管理、履
カリキュラムや履修情報など
修登録管理、成績管機関によって業務フローが教員（講義担オープンな情報もあるが、学 学生に関する種々の情報を収集、理、入試管理、シラバス 区々で、今後の教育制度改革 当）、職員（教務、生の成績情報や家族情報な 分析することによって、eポートフォ
管理、講義出欠管理、 により要件が大きく変わる可能 総務）、学生、一どの機密性の高い個人情報も リオに活用できる可能性がある。
学費納入管理、奨学金 性がある。
般（入試）
多い。
管理、学生健康管理
企業情報や就職募集情報な
上記に加え、企業情報等も収集、企業情報提供、就職募 企業が掲載する情報を活用すどオープンな情報もあるが、学生、職員（学生
分析することによって、就職支援に集情報提供、就職エント るケースが多く、サービスの範
学生個々のエントリー情報等部）、一般（企業）
効果的にフィードバックできる可能
リーシート作成支援
囲含めて機関で区々。
の個人情報を保有する場合も
性がある。
ある。
出退勤の情報が主なので、出退勤時間の登録、承認方法
教職員の活動データとして、人材勤務登録管理、休暇申
オープンな情報が多い。利用は多様だが、管理する情報は 職員、教員育成やキャリア設計に生かせる可
請管理
者管理情報と休暇申請の理
単純で、本質的な違いはない。
能性がある。
由は個人情報を含む。

80

ス評価や事業者評価を利用機関個々で行うことが難しいと思われるため、サービス認定制度やサービスブローカーの導入が有効と思われる。また、他のクラウドサービスへの移行が容易にできれば、これらのリスクを回避できるため、仮想化基盤やクラウドサー
ビスの標準化も有効と考えられる。なお、仮想化基盤やクラウドサービスの標準化ができれば、複数のクラウドサービスを連携させたシステム構築が可能になるため、BCP 対策も含めた柔軟で可用性の高いシステム構成ができるようになる。
その他、クラウドサービス活用にあったての直接的な課題ではないが、業務アプリケーションソフトウェアの開発に関する課題がある。アンケート回答結果では、多くのシステムで業務用パッケージを利用しているにもかかわらずカスタマイズを実施しているシステムが 80%以上と多く、開発コストの増加を招くだけでなく、SaaS 活用が難しい
要因にもなる。この課題を解決するには業務の標準化が必要であるが、業務フローや帳票形式の変更は業務の混乱を招いたり、業務効率が低下したりする恐れがあるため、性急に進めにくいのが実情である。米国の Kuali Foundation では高等教育機関が連携してオープンソースとして事務支援に係る業務用パッケージの開発を行い、高等教育機関
への普及を進めている。開発方法やプロダクトをそのまま我が国に導入するのは難しいと思われるが、同じ業務用パッケージを利用している機関やパッケージベンダーが大学
ICT 推進協議会等の枠組みを活用して連携し、業務の標準化やパッケージの開発、SaaSの開発を進めるのがよいと思われる。また、開発環境としてアカデミッククラウドが活用できれば、開発や普及を効率よく進めることが可能となる。
iv) アカデミッククラウド環境の在り方
事務支援に係るシステムについては、先に述べた課題の解決は必要であるが、一般企業の業務システムと同様に商用クラウドサービスの活用が進むと考えられる。ただし、機能要件としてアカデミック特有のものがあり、市場規模が一般企業に比べて小さいこともあって、サービス提供者の対応含めて普及速度は遅くなると思われる。そこで、アカデミックがコントロールして推進するクラウド環境ができれば、クラウドサービス活用が促進でき、システム構築運用の効率化や事務サービスの品質向上等の効果が期待できる。なお、アカデミッククラウド環境は、各機関のプライベートクラウド環境、商用
クラウド環境、SINET 等を活用してクラウド環境を構築すればよく、先に述べたクラウ
ドサービス活用にあたっての課題解決に向けて、アカデミックコミュニティが連携や取組みを強化することが重要である。
3. 要求要件（標準仕様）i) 事務支援分野から見たアカデミッククラウドのあるべき姿
アカデミッククラウドのあるべき姿は、情報流通基盤、システム統合基盤、データ収81

集基盤の３つの観点で、以下のように整理できる。
a) 機関相互や企業との間で情報を共有できる情報流通基盤（ex. 調達関連情報、就職関連情報、カリキュラム）
・情報の格付けやセキュリティレベルの明確化がされ、対策の仕組みが実装されている。
・情報を提供、参照するための共通 API が規定されている。
・BCP 対策（データ保管）に活用できる。
b) システムを集約・統合するための基盤
・建物、システム、運用含めたセキュリティ対策基準が明確化されている。
・効率性、信頼性の要件に対する SLA の規定とレベルに合わせたサービス提供されている。
・プライベートクラウド、商用クラウドとの相互運用が可能で、柔軟にトライアルができる。
・システム可用性の面でも BCP 対策に活用できる。
c) ビッグデータ活用のためのデータ収集基盤
・安全に（匿名情報として）データを収集・利用するための仕組みが実装されている。
・教育研究機関に係るあらゆるデータを収集する仕組みが実装されている。
ii) 事務支援分野から見たアカデミッククラウド環境の標準仕様（要件）
IaaS、PaaS、SaaS などサービスレベルによって要件は異なるが、以下、基本となる
IaaS 環境について要件をまとめる。
a) システム要件
アンケート回答結果から必要な計算機資源を試算する。
・図 Ⅲ-③-17 に示すように、1 サーバ当たりの計算機資源量は、クラウド環境を利用している場合は、CPU が約 3 コア、メモリ約８GB となっている。（システム独自の場合
はピーク時の性能等を考慮してサーバの資源量が多く割り当てられていると思われる。） 事務支援システムは通常の CPU 使用率はあまり高くなく、CPU コアについては２~３倍のオーバーアサインが可能なた
め、１物理サーバを CPU24 コア、メモリ
128GB で構成すると、最大で 15 仮想サー
バ程度作成が可能である。
・サーバは 475 機関 889 システムで合計3,927 台であることから、アカデミック
クラウド環境を利用するサーバが約 5 倍の 20,000 台と仮定すると、1,400 台程度の物理サーバが必要になる。
図 Ⅲ-③-17・データ量は 408 機関 776 システムで合82

資源構成サーバーバ資源量

計 512TB であり、データバックアップでの利用も想定されるため、約 10 倍と仮定すると 5PB 程度のストレージが必要になる。また、RAID 等の高可用性の構成になっている必要がある。
b) 機能要件
事務支援システムは、一般的に機関内のネットワークおよびインターネットから安全にアクセスできる必要があり、可用性や効率性の高いシステム構成が求められるため、以下の機能が標準的に利用できる必要がある。
・VLAN、VPN 接続により、学内ネットワークと同様のアクセスができ、クラウド環境上の他のシステムとは分離されていること
・機関の規模にもよるが、1Gbps~10Gbps でのネットワーク接続環境が提供されること・機関個別の認証システムとの認証連携が可能で、利用者管理についても機関内のシス
テムと連携が可能なこと・ファイアウォール、負荷分散装置が標準的に利用可能なこと・プライベートクラウドや商用クラウドと相互運用行うためのクラウド管理機能や移行ツールが提供されること
c) 保守運用要件
システムの可用性とセキュリティの観点から以下の要件が求められる。
・365 日 24 時間の保守運用体制で可用性が保障されていること（大規模災害対策含めて）・システムバックアップやデータバックアップが定期的に実施されること。
・運用要員も含めたセキュリティ対策マネジメントがされていることd) その他
・個別システムやプライベートクラウドと同等以下の利用料金であること
iii) 事務支援分野から見たロードマップ（案）a) １年～３年目（初期目標）
・コミュニティで共同利用できるクラウド基盤の構築（数か所、小規模）・IaaS サービスの提供
・クラウド基盤上に情報流通基盤の構築
・情報共有のトライアル実施
・BCP 対策としてデータ保管のトライアル実施b) 4 年～7 年目（中期目標）
・クラウド基盤の規模拡大
・商用業務パッケージを組み込んだ PaaS サービスのトライアル実施
・プライベートクラウドや商用クラウドとの相互運用のトライアルと BCP 対策のトライ
アル83

・各種システムや学生、教員の行動データの収集（対象限定）と分析のトライアル実施c) 8 年目～ （長期目標）
・SaaS サービスのトライアル
・システム集約、統合の対象拡大と商用サービス活用の推進
・データ収集対象の拡大と新たなサービスの開発・構築・トライアル

84

④ 教育支援に係るアカデミッククラウドシステムの調査検討（概要）本業務では、コース管理システム・eポートフォリオシステム・教務システム
を通じて蓄積されつつある教育学習活動に係る現状と将来を調査するとともに、ビッグ
データやクラウドに関する新しい潮流も対象にしながら、教育分野におけるアカデミッ
ククラウドシステムの構築に係るデータをアンケート調査と海外事例について調査した。調査結果に基づき、利活用のための方策を検討し、個別連携型、地域別拠点連携型、全国中核拠点型についてそれぞれ標準仕様を策定した。これらの異なる構成のクラウド基盤の構築において、教育支援に関し想定される定量的・定性的な波及効果の検討・試算、実現のためのプロセスについても検討をした。具体的には、大阪大学における教務システムの導入・運用の経験からコース管理システム・オープンコースウェア等に関する知見を活用した調査の検討・分析、東京大学におけるコース管理システムの構築・運用の経験からシステムソフトウェアなどに関する知見を活用した調査の検討・分析、熊本大学におけるeポートフォリオシステムの構築・運用の経験からコース管理システ
ム・教務システムなどに関する知見を活用した調査の検討・分析、名古屋工業大学におけるICカードによる学生行動履歴分析の経験からコース管理システム・教務システムなどに関する知見を活用した調査の検討・分析をし、また、オープンソース、オープンコ
ンテンツ、オープンナレッジに関する知見を活用した調査の検討・分析を行い、活動に関するデータの現状調査とクラウドに関する潮流をもとにした今後の予測、及び、教育分野を対象としたアカデミッククラウドの標準仕様を策定した。
1. アンケート調査結果【概要】
1. CMS/LMS は今後 5 年で 2 倍程度の利用拡大が見込まれるが，利用されている機能は従来型の教育スタイルに沿ったものに留まっている
2. e ポートフォリオは全学的な導入よりも，学部・研究科での導入が先行しつつ，今後 5 年で 2〜3 倍程度の利用拡大が見込まれる
3. ビデオ教材の活用の伸びにも依存するが，今後 5 年間で数百 TB の教育ビッグデータが見込まれる
4. 教務システムとの科目・履修・シラバス情報連携は進みつつある
5. CMS/LMS・e ポートフォリオとも，大幅なコストダウンやセキュリティ・プライ
バシに関する懸念払拭されない限り，当面はオンプレミス型での導入・運用が継続
6. 低コスト化，学外接続ネットワークの高速化，セキュリティ・プライバシの強化のための技術整備はクラウド化（ASP 型での CMS/LMS，e ポートフォリオの導入・運用）に向けて必須
7. 学部・研究科単位での調査も行ったが，全学レベルとの大きな矛盾はなく，今85

後は全学レベルの調査で十分と考えられる
8. 学生メールの ASP 化は，セキュリティ・プライバシ上の懸念やカスタマイズ・
ベンダーロックインの問題があるものの，低コストがドライビングフォースとなり進展している
9. 学生端末システムは多くの大学で全学的に導入．国立大学ではデスクトップク
ラウド等のクラウド型への移行の検討を行っているところが多く，ほぼプライ
ベートクラウド型が前提
10. 低コスト化，学内外ネットワーク高速化，セキュリティ・プライバシ強化技術基盤の整備により，学生端末システムのクラウド化が進展する可能性がある
11. BYOD の全学的な検討は進んでおらず，進展したとしても当面は現有学生端末数を維持する大学が多い
12. 複数システム間の ID 連携は進展しており，システムをまたがったユーザデータのトラッキングは期待できる
１−１）アンケート実施概要
高等教育機関における教育学習支援情報環境は，教員の視点から支援するためのコース管理システムや学習支援システム，および，学生の視点から支援するためのｅポー
トフォリオシステムが，教務システムと合わせて，大学における教育学習活動の三位一体システムとして明確になってきている．これらのシステムが，大学ポータルにより統合されたアクセス環境やデータ連携を通じて相互に連携されることにより，「仮想世界における教育学習メディア」を形成するようになってきている．さらに，教室や図書館のような「物理世界における教育学習メディア」も，学生用端末システム，IC カード
による入退室管理や図書貸借の電子化を通じて一部が情報環境に取り込まれることにより，物理世界・仮想世界双方の教育学習活動が徐々に「可観測」になってきている(図Ⅲ-④-1-1 参照)．しかも，最近では「PC 必携化」あるいは BYOD (Bring Your Own Device)も進みつつあり，大学における教育学習活動に関わる様々な活動を通じて教育ビッグデータの蓄積が始まろうとしている．
このような背景の下，本アンケートでは，教育学習支援情報環境の利活用の現状とそのクラウド化に関する調査を行った．

86

各種アクセス手段に合わせた情報提示

学生
大学ポータル
大学
成績表

物理世界
教室
教科書

講義資料

図書館 実験室 eポートフォリオ

システム
学生

教育

仮想世界
講義資料
オンライン
コミュニティ オープンコース
学生端末 ウェア
コース管理
電子図書館
システム

教務システム

レポート

ゼミ室

専門アプリ

教員

大学ポータル

学習指導
学習指導

教育

教員

図Ⅲ-④-1-1: 想定した教育学習情報環境モデル

学生用端末システム

学生用メール

データ連携

科目・履修・
シラバス情報

教務
システム

教務
システム

コース管理システム

Student
Informa on
SystemCourse Management System (CMS)
Learning Management System (LMS)

Student
Informa on
Systemシラバス作成（教員）履修許可（教員）履修登録（学生）

授業期間（15週）

成績入力（教員）
成績確認（学生）

図 Ⅲ-④-1-2: 調査の対象とするシステム

本アンケート調査の実施に際しては，教育学習情報環境モデルのうち，多様な教育
現場の個別事情はできるだけ排除し，15 週で構成される授業期間を中心にどの教育現場においても共通的に見られる次のシステムの利用状況を把握することに注力することにより，全体としての現状や今後が把握できるように配慮した(図Ⅲ-④-1-2 参

照)：1. コース管理システム (Course Management System, CMS) または学習管理システム(Learning Management System, LMS)
2. e ポートフォリオシステム (ePortfolio System)
3. 教務システム (Student Information System, SIS) との連携状況
87

4. 学生メール
5. 学生用端末システム
6. 大学ポータル
これにより，部局・学科・科目に依存しない一般的な教育学習活動に係わる業務支援の現状を明らかにしつつ，e ポートフォリオや学生所有のノート PC 等を大学に持参させる PC 必携化 (Bring Your Own Device, BYOD) のような部局・学科・科目に依存する教
育的支援・教授方法に踏み込んだ支援の取り組み状況の現状についてシステム面からア
プローチすることを試みた．なお，MOOC (Massive Open Online Courses) やアクティ
ブラーニング等，今後必要となると想定されるより教育的な面での現状については同時期に別途行われた「高等教育機関等におけるＩＣＴの利活用に関する調査研究によるアンケート（代表: 京都大学飯吉透教授）」との調整を行いながら実施することで，アンケート実施側および回答者側双方負担が軽減されるよう配慮した (図Ⅲ-④-1-3 参照)．

MOOCs!(edX)!
用に関す
高等教育機関等におけるＩＣＴの利活
Ac. ve!Learning!
る調査研究によるアンケート（2月実施）
e!
（代表: 京都大学飯吉透教授）
BYOD!

!
!

本事業でのアンケート
!

!
!

!
!
!
コース管理システム・eポートフォリオシステム
Student!
Student!
Course!Management!System!(CMS)!
学生用端末システム
Informa. on!
Informa. on!
Learning!Management!System!(LMS)!!
System!
System!
学生メール

図 サーバ-1-3: 同時期に実施されたアンケートととの棲み分け

また，全学的な観点から学部・大学院における教育学習活動を支援している情報部門を対象にしたアンケート調査（以降，「機関向け調査」）および実際の教育プログラムを実施している学部・大学院を対象にしたアンケート調査（以降，「学部・大学院向け調査」）の 2 種類を実施した．これは，次の 2 つの視点に基づいている:
1. 教育プログラムを実際に実施している組織の現状認識と今後を把握するため．
2. クラウド化に向けた動向を把握するためには，学内における教育学習支援情報環境が全学的にどの程度集約されているのか，それらがどうクラウド化されようとしているのかを把握することが重要と考えたため．
なお，研究機構については回答があった事項についてのみ記すこととする．
88１−２）機関向けアンケート調査
本アンケート調査には，国立 76 校，私立 306 校，公立 50 校，高専 43 校，短大 116 校，
研究機構 2 校の合計 593 校から回答を得た（図 Ⅲ-④-2-1 参照）． 規模別に見ると，
国立 A: 18 校，国立 B: 13 校，国立 C: 26 校，国立 D: 19 校
私立 A: 22 校，私立 B:51 校，私立 C: 125 校，私立 D: 108 校
公立 A: 1 校，公立 B: 3 校，公立 C: 24 校，公立 D: 22 校となっており，全体として私立・短大が多いこと，私立・公立に関しては小規模校の数が多くなっている点に注意が必要である．
国立

私立

公立

高専

短大

研究機構

0.3%
12.8%

19.6%
7.3%
8.4%

51.6%

図 Ⅲ-④-2-1：参加大学の概要
全学的に導入し，学部・研究科に提供している
全学的に導入していないが，学部・研究科独自に導入・利用しているところがある
全学的にも学部・研究科としても導入・利用しているところはない
CMS/LMS 全体（n=587）

40.0%

16.5%

CMS/LMS 国立（n=75）

76.0%

CMS/LMS 私立(n=305）
CMS/LMS 公立（n=50）

43.4%

41.3%
20.0%

13.3%
17.7%

41.0%

24.0%

CMS/LMS 高専（n=41）

46.3%

CMS/LMS 短大（n=114）

20.2% 12.3%

10.7%

56.0%
17.1%

36.6%
67.5%

CMS/LMS 研究機構（n=2）0.0%

100.0%

図 Ⅲ-④-2-2：CMS/LMS の導入状況

１−２−１）コース管理システム（Course Management System）/学習管理システム(Learning Management Sysmtem) の利用状況
CMS/LMS の導入状況を図 Ⅲ-④-2-2 に示す．
「全学的に導入している」は国立が圧倒的に多く，私立・高専は「全学的に導入している」が多いものの，「全学的にも学部・89

全学的に導入し，学部・研究科に提供している
全学的に導入していないが，学部・研究科独自に導入・利用しているところがある
全学的にも学部・研究科としても導入・利用しているところはない
CMS/LMS 私立A (n=22)

72.7%

CMS/LMS 私立B (n=51)

18.2%

64.7%

CMS/LMS 私立C (n=124)

19.6%

43.5%

CMS/LMS 私立D (n=108)

21.3%

9.1%

22.6%

15.7%
33.9%

11.1%

67.6%

図 Ⅲ-④-2-3: CMS/LMS の導入状況（私立詳細）
非常によく使われている（目安: 8割以上の科目）

よく使われている（目安: ６割以上，８割未満の科目）

ある程度使われている（目安: 4割以上，6割未満の科目）

あまり使われていない（目安: 2割以上，４割未満の科目）

ほとんど使われていない（目安: 2割未満の科目）

分からない

授業資料の提供（n=244）
課題レポートの提出・採点・返却（n=243）
メール等による教員・学生間のやりとり（n=238）

22.5%

17.6%

7.4%

20.2%

10.5%

14.7%

27.5%
25.5%

19.3%

8.2%

13.6%
8.8%

15.2%

25.2%

テスト（n=245）

5.7% 9.4%
19.2%
22.9%
4.1%
ディスカッション（n=244） 2.5%
13.5%
20.9%
40.2%
6.1%
ビデオ教材の提供（n=244） 2.0% 1.2%
16.8%
56.1%
1.2%
SCORM 教材等のオンライン教材（n=242） 0.8% 4.5% 8.7%
59.5%
3.8% 6.3%
ソーシャルネットワーキング機能（n=239） 0.8%
57.3%
0.8%
Wiki（n=240） 0.8% 5.4%
57.9%
0.4% 3.8%

9.0%

22.2%

11.1%
21.4%

30.6%

12.2%
18.9%
17.6%
25.2%
31.0%
31.7%

図 Ⅲ-④-2-4： CMS/LMS が有する機能の利用状況（全体）

研究科としても導入していない」も多い．一方，公立・短大については「全学的にも学部・研究科としても導入していない」が多くなっている． 私立について規模別にみると，規模が小さくなるにつれて「全学的に導入している」割合は少なくなっている．
「全学的に導入している」と回答した大学について，利用対象総科目数，アクティブな科目数（教員・学生が登録され何らかの利用があることを指す），アクティブなユー
ザ数，総データ量を訊ねたところ，
 利用対象総科目数は 451,093 科目（回答校数は 195 大学）
 アクティブな科目数は 111,716 科目（回答校数は 182 大学）
 アクティブなユーザ数は 916,599 名（回答校数は 206 大学）
 総データ量は 70.7TB （回答校数は 159 大学）であること，その結果，
 アクティブな科目数の割合は 25.8%（回答校数は 182 大学）
 アクティブな科目当たりのデータ量は 751MB（回答校数は 159 大学）であることが分かった．調査方法・対象が異なるため，厳密な比較はできないが，Campus
Computing Project が行っている米国における LMS/CMS の利用状況データ (K. C.
90

利用対象総科目の8割以上
利用対象総科目の2割以上，4割未満
科目情報（全体，n=238）
履修情報（全体，n=237）
シラバス情報（全体，n=236）

利用対象総科目の6割以上，8割未満
利用対象総科目の4割以上，6割未満
利用対象総科目の2割未満
分からない
0.8%
42.4%
2.1%
30.7%
21.4%
2.5%
2.5%
40.9%
0.8%
33.3%
19.8%
2.5%
0.4% 0.8%
28.4%
44.1%
24.6%
1.7%

図 Ⅲ-④-2-5：CMS/LMS の教務システムとのデータ連携（全体）Green, “Campus Computing 2010”, EDUCAUSE2010) と比較すると，現在の状況は米国の 2001 年頃の状況と見なすことができるとすると，今後 5 年で 2 倍程度の利用拡大が見込まれる．
同じく，「全学的に導入している」と回答した大学について，CMS/LMS が有する機能の利用状況について訊ねた結果を図 Ⅲ-④-2-4 に示す．図では，「非常によく使われている」「よく使われている」「ある程度使われている」を合わせた割合が多い，次の順番に並べている:
1. 授業資料の提供（プレゼンテーションファイル，補助教材や自学自習用教材を含む．ビデオ教材は除く）
2. 課題レポートの提出・採点・返却
3. メール等による教員・学生間のやりとり
4. テスト（自学自習用の小テストを含む）
5. ディスカッション
6. ビデオ教材の提供
7. SCORM 教材等のオンライン教材（IMS CommonCartridge に対応したオンライ
ン教材を含む）8. ブログやマイクロブログ等のソーシャルネットワーキング機能
9. Wiki
このうち，上位 4 つは利用されている機能は，知識提供を主とする従来型の教育スタイ
ルに沿ったものであり，「オンラインでのディスカッションを行う」「ビデオ教材を用意する」等，教育スタイルの変更や新たな労力が求められる機能の利用は必ずしも進んでいるとはいえない．この特徴は，大学設置形態にほぼ共通する傾向（資料１参照）であるが，公立では「ソーシャルネットワーキング機能」や「Wiki」，高専では「授業資料の提供」，短大では「メール等による教員・学生間のやりとり」の利用が比較的多い．
さらに，「全学的に導入している」と回答した大学について，教務システムとの連携状況について訊ねたところ，全体として科目情報・履修情報・シラバス情報のいずれも連携する場合は多くの科目が対象となっていること，シラバス情報は科目情報・履修情
報よりは連携しているところが少ないことが分かった (図 Ⅲ-④-2-5)． 大学設置形態
別では，国立・私立・短大は全体傾向と同様であるが，公立は履修情報・シラバス情報について，高専は科目情報・履修情報・シラバス情報すべてについて連携している科目
91

全学的に導入し，学部・研究科に提供している
全学的に導入していないが，学部・研究科独自に導入・利用しているところがある
全学的にも学部・研究科としても導入・利用しているところはない
eP 全体（n=495）

16.6%

eP 国立（n=68）

17.4%

66.1%

26.5%

eP 私立(n=260）

16.9%

eP 公立（n=40）

15.0%

35.3%
16.9%

66.2%

12.5%

72.5%

eP 高専（n=34） 2.9% 8.8%
eP 短大（n=92）

38.2%

88.2%
14.1%10.9%75.0%

eP 研究機構（n=1）0.0%

100.0%

図 Ⅲ-④-2-6 データートフォリオシステムの導入
利用対象総科目の8割以上
利用対象総科目の2割以上，4割未満
科目情報（n=115）
履修情報（n=111）
シラバス情報（n=113）

19.5%

状況

利用対象総科目の6割以上，8割未満
利用対象総科目の4割以上，6割未満
利用対象総科目の2割未満
分からない
3.5%
36.5%
0.9%
31.3%
26.1%
1.7%
0.9%
36.9%
0.9%
35.1%
23.4%
2.7%
0.9%
46.0%
31.0%
0.0% 2.7%

図 Ⅲ-④-2-7：e ポートフォリオシステムの教務システムとのデータ連携（全体）数が少ない傾向にある （資料１参照）．
１−２−２） e ポートフォリオシステムの利用状況
e ポートフォリオシステムの導入状況を図 Ⅲ-④-2-6 に示す．
「全学的に導入している」は，CMS/LMS よりは少ないが，学部・研究科での導入割合は CMS/LMS より多い．
これは， e ポートフォリオシステムは，学生の学びのエビデンスをカリキュラムに沿って科目を越えて串刺し的に行う必要があり，教育プログラム単位での導入が求められるためと推察される．CMS/LMS と同様に Campus Computing Project のデータ (K. C.
Green, “Campus Computing 2010”, EDUCAUSE2010) と比較すると，国立（全学的導入
率 26.5%）の方が私立（全学的導入率 16.9%）より多く，米国の 2003 年頃の状況と酷似しており，今後 5 年で 2〜3 倍程度の利用拡大が見込まれる．
「全学的に導入している」と回答した大学について，利用対象総科目数，アクティ
ブな科目数（教員・学生が登録され何らかの利用があることを指す），アクティブなユ
ーザ数，総データ量を訊ねたところ，
 利用対象総科目数は 128,262 科目（回答校数は 61 大学）
 アクティブな科目数は 63,330 科目（回答校数は 64 大学）
 アクティブなユーザ数は 97,984（回答校数は 44 大学）92

オンプレミス型（大学または学部・研究科が管理する設備にシステムを導入して運用）
ASP型（民間企業等，外部組織が提供する設備やシステムを通じてサービスとして利用）
外部データセンター型（民間企業等，外部組織が提供するデータセンターに大学または学部・研究科が管理するシステムを導入して運用）
CMS/LMS 全体（n=238）
CMS/LMS 国立（n=57）
CMS/LMS 私立（n=127）

85.7%
94.7%
82.7%

CMS/LMS 公立（n=10）
CMS/LMS 高専（n=21）
CMS/LMS 短大（n=23）
eP 全体（n=106）
eP 国立（n=25）
eP 私立（n=58）eP 公立（n=6）
eP 高専（n=2）
eP 短大（n=15）

11.8%
14.2%

70.0%

4.2%
3.5% 3.5%
5.5%

30.0%
100.0%

0.0%
0.0%
0.0%
4.3%

21.7%

73.9%
66.0%

9.4%

27.4%
88.0%

60.3%

31.0%

33.3%

50.0%
100.0%
60.0%

40.0%

8.0% 4.0%
12.1%
16.7%
0.0%
0.0%
6.7%

図 Ⅲ-④-2-8：CMS/LMS および データトフォリオシステムの運用形
態
 総データ量は 16.5TB （回答校数は 44 大学）であること，その結果，
 アクティブなユーザ当たりのデータ量は 177MB（回答校数は 44 大学）であることが分かった．
さらに，「全学的に導入している」と回答した大学について，教務システムとの連携状況について訊ねたところ，CMS/LMS よりは少ないものの，全体として科目情報・履修
情報・シラバス情報のいずれも連携する場合は多くの科目が対象となっていること，シラバス情報は科目情報・履修情報よりは連携しているところが少ないことが分かった(図 Ⅲ-④-2-7)． 大学設置形態別では，国立・私立・短大は全体傾向と同様であるが，公立は履修情報・シラバス情報について，高専は科目情報・履修情報・シラバス情報すべてについて連携している科目数が少ない傾向にある（資料１参照）．これらは，CMS/LMSの場合と同じ傾向である．
１−２−３） CMS/LMS および e ポートフォリオシステムのクラウド化に向けた現状
CMS/LMS および e ポートフォリオシステムを「全学的に導入している」と回答した
大学についてその運用形態を訊いたところ，どちらも大学または学部・研究科が管理する設備にシステムを導入して運用する「オンプレミス型」が圧倒的に多かったが，e ポ
ートフォリオシステムの方が民間企業等，外部組織が提供する設備やシステムを通じてサービスとして利用する「ASP 型」の割合が多かった (図 Ⅲ-④-2-8 参照)．
また，
「オンプレミス型」で CMS/LMS および e ポートフォリオシステムを運用している大学について，今後のクラウド化の可能性を確認するため，「ASP 型」への移行について訊いたところ，CMS/LMS および e ポートフォリオシステム双方とも多くの大学がその計画がないことが分かった (図 Ⅲ-④-2-9 参照)．これは，ASP 化のデメリットとし
93

ASP型に移行することが決まっている

ASP型に移行する計画がある、または、検討を行っている

ASP型に移行する検討は行っていない
1.0%
6.9%
1.9%
CMS/LMS 国立
5.8%
1.0%
CMS/LMS 私立
8.7%

CMS/LMS 全体

92.2%
92.3%
90.3%

CMS/LMS 公立（n=8）0.0%
0.0%
CMS/LMS 高専 0.0%
10.5%
CMS/LMS 短大
0.0%

100.0%
100.0%
89.5%
88.6%

eP 全体（n=88） 3.4% 8.0%

87.5%

eP 国立（n=24）

8.3%
4.9%
eP 私立（n=41） 4.2% 9.8%

85.4%

eP 公立（n=2）0.0% 0.0%

100.0%eP 高専（n=8）0.0% 0.0%

100.0%

eP 短大（n=13）0.0% 7.7%

92.3%

図 Ⅲ-④-2-9：CMS/LMS および e ポートフォリオシステムの ASP 化

図 Ⅲ-④-2-10：ASP 型のデメリット（複数回答あり）て挙げられている以下の事項が大きく影響している (図 Ⅲ-④-2-10 参照)：
 教育学習活動に関わる様々な記録が業者側のシステムに蓄積されるため，セキュ
リティやプライバシー上の懸念が生じやすい (59.4%，全体)
 学部・研究科のニーズに応じたカスタマイズを行うコストが高い (53.1%，全体)
 学部・研究科のニーズに応じたカスタマイズを行いにくい (51.8%，全体)94

図 Ⅲ-④-2-11：ASP 型のメリット（複数回答あり）

 特定の業者にロックインしてしまう（業者変更ができない） (49.9%，全体)
１−２−４） CMS/LMS および e ポートフォリオシステムのクラウド化に向けた方向性
一方で，ASP 化のメリットとして次の事項が注目されている (図 Ⅲ-④-2-11 参照)：
 学部・研究科に技術者がいなくても導入・利用できる (56.4%，全体)
 短期間で導入・利用できる (49.5%，全体)
 低コストで導入・利用できる (43.2%，全体)
 利用のピークに合わせた計算機資源や設備投資が不要になる (40.2%，全体)
このようなメリットを享受することができる CMS/LMS および e ポートフォリオシステ
ムの ASP 型での利用を促進する要因について訊ねたところ以下の項目が上位を占めた(図 Ⅲ-④-2-12 参照)： 低コスト (64.4%，全体)
 学外接続ネットワークの高速化 (28.4%，全体)
 セキュリティやプライバシーを強化する技術整備 (28.2%，全体)
大学設置種別で見ると，国立と私立では「セキュリティやプライバシーを強化する技術
整備」「セキュリティやプライバシーを強化する法整備」「災害対策を強化する技術・運用」に大きな違いが見られる点が特徴的である．

95

図 Ⅲ-④-2-12：CMS/LMS や e ポートフォリオシステムの ASP 型での利用を促進する要因

１−２−５）学生メールの利用状況およびクラウド化に向けた現状
学生メールの導入状況を図 Ⅲ-④-2-13 に示す．学生メールは，短大が全体よりも低いものの，多くの大学が「全学的に導入している」状況である．運用形態は，「オンプレミス型」と「ASP 型」がほぼ同じ割合であり，国立・公立・高専は「オンプレミス型」の割合が多く，私立・短大は「ASP 型」の割合が多い (図 Ⅲ-④-2-14 参照)．
「全学的に導入している」と回答した大学のアクティブなユーザ数（アクティブとは，メールの受信等，何らかの利用があることを指す）および総データ量はそれぞれ以下の通りであった： アクティブなユーザ数: 1,548,007 名 (n=410)
 総データ量: 1.77 PB (n=282)
今後のクラウド化（つまり，ASP 化）については，「検討を行っていない」が多いものの，CMS/LMS および e ポートフォリオシステムと比べると明らかに「移行することが決まっている」あるいは「移行する計画がある，あるいは，検討を行っている」が多い(図 Ⅲ-④-2-15 参照)．クラウド化のメリットとして挙げられているものとしては，
 低コストで導入・利用できる (67.0%，全体)96

全学的に導入し，学部・研究科に提供している
全学的に導入していないが，学部・研究科独自に導入・利用しているところがある
全学的にも学部・研究科としても導入・利用しているところはない全体（n=571）

83.2%

国立（n=70）

3.9%

13.0%

94.3%

私立（n=297）

4.3%
1.4%

85.2%

3.4% 11.4%

公立（n=48）

89.6%

2.1% 8.3%

高専（n=43）

88.4%

7.0% 4.7%

短大（n=111）

67.6%

4.5%

27.9%

図 Ⅲ-④-2-13：学生メールの導入状況
オンプレミス型（大学または学部・研究科が管理する設備にシステムを導入して運用）
ASP型（民間企業等，外部組織が提供する設備やシステムを利用）
外部データセンター型（民間企業等，外部組織が提供するデータセンターに大学 または学部・研究科が管理する設備にシステムを導入して運用）全体（n=477）

47.2%

国立（n=66）
私立（n=252）

68.2%
40.9%

公立（n=44）

3.6%
25.8%

55.6%
65.9%

高専（n=39）
短大（n=76）

49.3%

3.6%
34.1%
48.7%

51.3%
57.9%

36.8%

6.1%

0.0%
0.0%
5.3%

図 Ⅲ-④-2-14：学生メールの運用形態

 学部・研究科に技術者がいなくても導入・利用できる (51.3%，全体)
 利用のピークに合わせた計算機資源や設備投資が不要になる (47.8%，全体)
 短期間で導入・利用できる (36.7%，全体)
 利用のピークに合わせた計算機資源や設備投資が不要になる (40.2%，全体)が多く (図 Ⅲ-④-2-16 参照)，逆にデメリットとしては，
 教育学習活動に関わる様々な記録が業者側のシステムに蓄積されるため，セキュリティやプライバシー上の懸念が生じやすい (64.5%，全体)
 学部・研究科のニーズに応じたカスタマイズを行いにくい (58.8%，全体)97

ASP型に移行することが決まっている

ASP型に移行する計画がある、または、検討を行っている

ASP型に移行する検討は行っていない全体（n=228）

7.5%

国立（n=45）
私立（n=104）

33.8%

15.6%

38.5%

7.1%

54.8%

26.7%

70.0%
47.6%

高専（n=21） 0.0%
短大（n=28）

60.0%

24.4%

6.7%

公立（n=30） 3.3%

58.8%

52.4%
64.3%

28.6%

図 Ⅲ-④-2-15：学生メールの ASP 化

図 Ⅲ-④-2-16：学生メールを ASP 型で利用するメリット

 特定の業者にロックインしてしまう（業者変更ができない） (49.6%，全体)
 学部・研究科のニーズに応じたカスタマイズを行うコストが高い (31.7%，全体)が多い (図 Ⅲ-④-2-17 参照)．クラウド化を促進する要因としては，
 低コスト (67.3%，全体)98

図 Ⅲ-④-2-17：学生メールを ASP 型で利用するデメリット

 学外接続ネットワークの高速化(27.3%，全体)

 セキュリティやプライバシーを強化する技術整備 (26.8%，全体)が多い (図 Ⅲ-④-2-18 参照)．
全体として，CMS/LMS および e ポートフォリオシステムの場合と比べると．すでに
多くの無料の ASP 型メールサービスが提供されているため，クラウド化のメリットや促進要因で取り上げられている「低価格化」がクラウド化を促進している状況がよく分かる．
１−２−６）学生用端末の利用状況およびクラウド化に向けた現状
学生用端末の導入状況を図 Ⅲ-④-2-19 に示す．全体としては，「全学的に導入し，学部・研究科に提供しているが多い」傾向は国立・公立が強い．私立は規模別に見ると，規模が大きい方が「全学的に導入し，学部・研究科に提供しているが多い」の割合が多い (図 Ⅲ-④-2-20 参照)．
「全学的に導入し，学部・研究科に提供している」が多いと回答した大学の端末総数
は 170,144 台 (n=316) で，大学ごとの端末台数は 1,000 台未満が圧倒的に多い (図Ⅲ-④-2-21 参照)．また，総システムデータ量（OS，アプリケーション，ホームディレ
クトリ容量などすべて含む）は 2.29PB (n=223)，1 ユーザ当たりのホームディレクト
リ最大容量は 100MB〜5GB が圧倒的に多い (図 Ⅲ-④-2-22 参照)．
99

図 Ⅲ-④-2-18：学生メールの ASP 型での利用を促進する要因
全学的に導入し，学部・研究科に提供している
全学的に導入していないが，学部・研究科独自に導入・利用しているところがある
全学的にも学部・研究科としても導入・利用しているところはない全体（n=492）

67.3%

国立（n=68）
私立（n=256）
公立（n=45）
高専（n=40）
短大（n=83）

8.7%

24.0%

85.3%

8.8%

65.6%

6.6%

73.3%

27.7%
11.1%

67.5%

10.0%

54.2%

13.3%

図 Ⅲ-④-2-19：学生用端末システムの導入
状況
100

5.9%

15.6%
22.5%

32.5%

全学的に導入し，学部・研究科に提供している
全学的に導入していないが，学部・研究科独自に導入・利用しているところがある
全学的にも学部・研究科としても導入・利用しているところはない
私立A (n=20)

80.0%

私立B (n=46)

10.0%

87.0%

私立C (n=106)

59.4%

私立D (n=84)

58.3%

10.0%
8.7% 4.3%

7.5%
3.6%

33.0%
38.1%

図 Ⅲ-④-2-20：学生用端末システムの導入状況（私立大学規模別）

36

13
37
2,000台以上
1,000台以上，2,000台未満
55

99

500台以上，1,000台未満
250台以上，500台未満
100台以上，250台未満
100台未満76

図 Ⅲ-④-2-21： 学生用端末の台数（数値は大学数）

3
8

14
17

100GB以上
10GB以上，100GB未満

92

5GB以上，10GB未満
1GB以上，5GB未満
100MB以上，1GB未満
100MB未満106

図 Ⅲ-④-2-22： 1 ユーザ当たりのホームディレクトリ最大容量（数値は大学数）

101

今後，仮想マシンをサーバサイドで起動し画面を端末に表示するデスクトップクラウ
ド等のクラウド型に移行する可能性については，全体としては「検討を行っていない」
が多いが，国立や大規模私立において，「すでに移行している」「移行することが決まっている」「移行する計画がある，または，検討を行っている」も多い (図 Ⅲ-④-2-23 参
照)．
すでにクラウド型に移行している
クラウド型に移行することが決まっている
クラウド型に移行する計画がある，または，検討を行っている
クラウド型に移行する検討は行っていない全体（n=414）

10.6% 1.2%

国立（n=60）

23.3%

私立（n=215）

9.8% 0.9%

公立（n=39）

10.3%

0.0%

20.8%

67.4%

5.0%

35.0%

19.5%

69.8%

15.4%

74.4%

高専（n=33）0.0%
21.2%
0.0%
短大（n=67）
7.5%
14.9%
0.0%
私立A

16.7%

私立B

14.0% 0.0%

私立C

9.1% 1.1%

私立D

6.1%
13.6%
0.0%

36.7%

78.8%
77.6%

5.6%

27.8%

50.0%

23.3%

62.8%

20.5%

69.3%
80.3%

図 Ⅲ-④-2-23：学生用端末システムのクラウド型への移行
プライベートクラウド型（大学または学部・研究科が管理する設備にシステムを導入して運用）
パブリッククラウド型（民間企業等，外部組織が提供する設備やシステムを利用）
全体（n=414）

87.3%

国立（n=60）
私立（n=215）
公立（n=39）12.7%

100.0%
78.9%

0.0%
21.1%

72.7%

27.3%

高専（n=33）

100.0%

短大（n=67）

100.0%

図 Ⅲ-④-2-24：学生用端末システムのクラウド型への移行時のユーザ態
102

0.0%
0.0%

「すでに移行している」「移行することが決まっている」「移行する計画がある，または，検討を行っている」と回答した大学の多くは，「プライベートクラウド型」が圧倒的に多いが，私立・公立では「パブリッククラウド型」も検討されている (図 Ⅲ-④-2-24 参照)．また，クラウド型で学生端末システムを提供する場合のメリットとして挙げられているものとしては，
 新しい機能の追加や新しい技術導入が迅速に行われる (36.1%，全体)
 低コストで導入・利用できる (30.5%，全体)
 大学に技術者がいなくても導入・利用できる (30.1%，全体)
 短期間で導入・利用できる (27.6%，全体)
 利用のピークに合わせた計算機資源や設備投資が不要になる (25.3%，全体)が多く (図 Ⅲ-④-2-25 参照)，逆にデメリットとしては，
 教育学習活動に関わる様々な記録が業者側のシステムに蓄積されるため，セキュリティやプライバシー上の懸念が生じやすい (42.6%，全体)
 大学のニーズに応じたカスタマイズを行うコストが高い (40.9%，全体)
 大学のニーズに応じたカスタマイズを行いにくい (37.9%，全体)
 特定の業者にロックインしてしまう（業者変更ができない）(35.4%，全体)が多い (図 Ⅲ-④-2-26 参照)．クラウド化を促進する要因としては，
 低コスト (59.8%，全体)
 学外接続ネットワークの高速化 (34.2%，全体)
 学内の有線ネットワークの高速化 (32.4%，全体)
 学内の無線ネットワークの高速化 (27.3%，全体)が多い (図 Ⅲ-④-2-27 参照)．
学生用端末の将来像としての PC 必携化等の BYOD 施策は，「全学的にも学部・研究科としても推進・利用しているところはない」が全体として多いものの，「全学的に推進
し，学部・研究科に提供している」「全学的に推進していないが，学部・研究科独自に導入・利用しているところがある」を合わせると，全体の 1/4 の大学が PC 必携化等の
BYOD 施策に向けてアクションを起こしている (図 Ⅲ-④-2-28 参照)．しかしながら，全学的に推進していない場合，今後も「全学的に BYOD を推進する検討は行っていない」
が圧倒的に多く，BYOD 施策を積極的に推進する傾向は見られない (図 Ⅲ-④-2-29 参照)．BYOD 施策を推進している場合でも，既存の学生用端末は多くの大学が「維持」または「削減するがゼロにはしない」と回答しており，「PC を購入できない学生のために，端末貸与サービスを検討」している大学もある (図 Ⅲ-④-2-30 参照)．

103

図 Ⅲ-④-2-25：クラウド型で学生用端末システムを提供する際のメリット（複数回答あり）

図Ⅲ-④-2-26：クラウド型で学生用端末システムを提供する際のデメリット（複数回答あり）

104

図 Ⅲ-④-2-27：学生用端末システムのクラウド型での利用を促進する要因（複数回答あり）

105

全学的に推進し，学部・研究科に提供している
全学的に推進していないが，学部・研究科独自に導入・利用しているところがある
全学的にも学部・研究科としても推進・利用しているところはない全体（n=558）

8.8%

国立（n=69）

15.8%

75.4%

15.9%

私立（n=290）

10.7%

公立（n=46）

6.5%

23.2%

60.9%

15.5%

73.8%

8.7%

84.8%

高専（n=41） 2.4%

14.6%

82.9%

短大（n=111） 2.7%

15.3%

82.0%

国立A（n=16）

18.8%

国立B（n=13）

15.4%

国立C（n=23）

17.4%

国立D（n=17）

25.0%

30.8%

13.0%

11.8%

69.6%
76.5%

11.8%

私立A（n=21）0.0%

52.4%

私立B（n=48）

10.4%

私立C（n=118）

9.3%

私立D（n=103）

56.3%
53.8%

47.6%

27.1%

62.5%

11.9%

14.6%

78.8%

6.8%

78.6%

図 Ⅲ-④-2-28：BYOD 施策の推進

全学的にBYODを推進することが決まっている
全学的にBYODを推進する計画がある、または、検討を行っている
全学的にBYODを推進する検討は行っていない全体（n=507）0.4% 13.2%

86.4%

国立（n=59）0.0% 15.3%

84.7%

私立（n=258）0.0%10.5%

89.5%

公立（n=42）0.0%

19.0%

81.0%

高専（n=39） 2.6%

17.9%

79.5%

短大（n=107） 0.9% 15.0%

国立A（n=14）0.0%

84.1%

28.6%

71.4%

国立B（n=11）0.0%9.1%
国立C（n=19）0.0%
国立D（n=15）

90.9%

15.8%

84.2%

6.7%
0.0%

93.3%

私立A（n=21）0.0%9.5%

90.5%

私立B（n=43）0.0% 11.6%

88.4%

私立C（n=107）0.0% 12.1%

87.9%

私立D（n=87）
8.0%
0.0%

92.0%

図Ⅲ-④-2-29：今後の全学的な BYOD 施策の推進

106これまでの学生用端末数は維持する
これまでの学生用端末数は削減するが，ゼロにはしない
これまでの学生用端末はゼロにする
PCを購入できない学生のために，端末貸与サービスを検討している全体（n=391）

72.4%

国立（n=53）

71.7%

私立（n=201）73.6%

公立（n=29）

65.5%

高専（n=30）

70.0%

短大（n=77）

国立A（n=13）

25.8%

1.3% 8.4%

30.2%

1.9% 9.4%

24.9%

1.0%9.5%
0.0%

34.5%

6.7% 10.0%

23.3%

74.0%

0.0% 7.8%

22.1%

53.8%

53.8%

7.7%

15.4%

国立B（n=10）

70.0%

30.0%

0.0% 0.0%

国立C（n=16）

81.3%

25.0%

0.0% 6.3%

国立D（n=14）

78.6%

私立A（n=12）
私立B（n=32）
私立C（n=83）
私立D（n=74）

14.3% 0.0% 14.3%

83.3%
65.6%

16.7% 0.0%
31.3%

68.7%

0.0%
28.9%

81.1%

18.9%

18.8%
2.4% 6.0%
0.0% 10.8%

図Ⅲ-④-2-30：全学的な BYOD 施策の推進後の学生用端末システムのあり方（複数回答可）

１−２−６）大学ポータルを通じたシステム統合
最後に，大学ポータルによる，教員学生に対して LMS/CMS や e ポートフォリオシス
テム，学生メールシステム等に一元的にアクセスできる環境の有無について訊ねたとこ
ろ，全体で 45.5% の大学には大学ポータルはなく，短大・高専・公立の方が国立・私立よりも多い (図 Ⅲ-④-2-31 参照)．また，国立・私立とも，規模が大きい大学の方が大学ポータルを構築している割合が高い．

107

大学ポータルによる一元的なアクセス環境は提供していない

59.3%
52.2%

59.2%

51.4%

45.5%
41.3%

42.3%

41.2%

41.3%

34.2%

34.2%

33.3%
30.8%
25.0%

14.9%
10.5%

全

体

=5
（n

）
54
国

立

3）
=7
（n
私

立

88
=2
（n

）
公

立

=
（n

）
46
高

専

=3
（n

7）
短

大

（n

0
=1

8）

私

立

（全

体

88
=2
，n

）

私

立

）
19
n=
A（

私

立

4）
n=
B（
私

立

C（

9）
11
n=
私

立

1
n=
D（

03

）

国

立

（全

体

，n

=7

3）
国

立

）
16
n=
A（
国

立

n=
B（

13

）

国

立

n
C（

6
=2

）

国

立

n
D（

8）
=1

図 Ⅲ-④-2-31: 大学ポータルによる一元的なアクセス環境を提供していない大学

大学ポータルを通じた利用が可能な場合に利用可能な機能は，
 ID 連携のみ（シングルサインオンはできない） (24.2%，全体)
 シングルサインオンが可能な ID 連携 (24.0%，全体)
 携帯電話，スマートフォン，タブレット等，複数アクセスデバイス対応(22.9%，全体)が多く，国立は ID 連携が，私立は複数アクセスでバイス対応に特徴がある (図 Ⅲ-④-2-32 参照)．また，
 RSS による情報連携 (1.4%，全体)
 ポートレットなどによる情報連携 (0.7%，全体)はほとんど使用されていない (図 Ⅲ-④-2-32 参照)．

108

図 Ⅲ-④-2-32：大学ポータルを通じた利用が可能な場合に利用可能な機能１−３）学部・研究科向けアンケート本アンケート調査には，国立 234，私立 392，公立 52，高専 66，短大 108，研究機構
3 の合計 855 学部・研究科から回答を得た（図 Ⅲ-④-3-1 参照）． 規模別に見ると，
国立 A: 128，国立 B: 47，国立 C: 41，国立 D: 18
私立 A: 80，私立 B:72，私立 C: 126，私立 D: 114
公立 A: 1，公立 B: 6，公立 C: 22，公立 D: 23となっている．
国立

私立

公立

高専

短大

研究機構

0.4%
7.7%

12.6%

27.4%

6.1%

45.8%

図 Ⅲ-④-3-1：参加学部・研究科の概要
109

全学的に導入されているものを学部・研究科として利用している学部・研究科独自に導入し利用している学部・研究科としては導入していないが，全学的に導入されているもの等を教員が利用しているケースがある
学部・研究科として導入する計画がある，または，検討を行っている
学部・研究科として導入する検討は行っていない
CMS/LMS 全体（n=841）

29.6%

CMS/LMS 国立（n=231）

9.8%

39.0%

CMS/LMS 私立（n=387）

30.5%

CMS/LMS 公立（n=50）

12.0%

CMS/LMS 高専（n=64）

11.1%

14.0%

16.0%

1.9% 7.5%

eP 全体（n=841）

13.5%

7.2%

eP 私立（n=387）

13.1%

7.0%
9.2%

7.5%

39.7%

20.3%
14.2%

7.2%

15.6%

6.3%

4.3%

8.4%

7.5%

37.0%

37.5%
67.0%

12.8%
8.2%

26.8%

64.0%

12.5%

CMS/LMS 短大（n=106）

16.9%

6.5%

2.0% 8.0%

28.1%

eP 国立（n=231）

14.4%
9.5%

59.6%

8.2%

57.4%

14.7%

eP 公立（n=50）
21.4%
4.8% 2.4% 11.9%
0.0%
eP 高専（n=64） 6.1%
16.3%
0.0%
eP 短大（n=106）
11.1% 3.7%
13.6%
4.9%

56.3%
59.5%
77.6%
66.7%

図 Ⅲ-④-3-2： CMS/LMS，e ポートフォリオの導入状況

１−３−１）CMS/LMS，e ポートフォリオの利用状況
まず，CMS/LMS，e ポートフォリオの導入状況を図 Ⅲ-④-3-2 に示す．全体として，以下の機関別アンケートと同じ傾向が見られるが，データ数が少ないことには注意が必要である:
 「全学的に導入されているものを学部・研究科として利用している」「学部・研究科としては導入していないが，全学的に導入されているもの等を教員が利用しているケースがある」（以下，「全学的に導入されているものを利用」）
は国立が圧倒的に多い
 私立・高専は「全学的に導入されているものを利用」が多いものの，「学部・研究科として導入する検討は行っていない」も多い 公立・短大については「学部・研究科として導入する検討は行っていない」
が多い
 「全学的に導入されているものを利用」は，CMS/LMS よりは少ないが，「学部・研究科独自に導入し利用している」「学部・研究科として導入する計画がある，
または，検討を行っている」割合は CMS/LMS より多い
「学部・研究科独自に導入し利用している」と回答した学部・研究科について，利用対
象総科目数，アクティブな科目数（教員・学生が登録され何らかの利用があることを指す），アクティブなユーザ数，総データ量を訊ねたところ，CMS/LMS については，
 利用対象総科目数は 214,425 科目（回答数は 119 学部・研究科）
 アクティブな科目数は 26,470 科目（回答数は 119 学部・研究科）
110

非常によく使われている（目安: 8割以上の科目）

よく使われている（目安: 6割以上，8割未満の科目）

ある程度使われている（目安: 4割以上，6割未満の科目）

あまり使われていない（目安: 2割以上，4割未満の科目）

ほとんど使われていない（目安: 2割未満の科目）

分からない

授業資料の提供（n=123）

32.5%

課題レポートの提出・採点・返却（n=122）
メール等による教員・学生間のやりとり（n=121）
テスト（n=123）

13.0%

19.7%
14.9%

13.1%
11.6%

21.5%

9.8%

11.4%
5.7%
ディスカッション（n=123） 6.5%
6.5%
ビデオ教材の提供（n=118） 2.5% 5.1% 10.2%
1.6%
SCORM 教材等のオンライン教材（n=122） 3.3% 5.7% 6.6%
ソーシャルネットワーキング機能（n=122）0.0% 3.3% 0.8%
2.5%
Wiki（n=121） 0.0% 5.8%
2.5% 2.5%

22.8%

20.5%

18.7%

7.4%

16.3%

7.4%
13.2%

39.0%

10.6%

49.6%

15.3%

6.5%

24.6%
31.4%

10.6%

15.4%

8.9%

14.8%

16.3%

52.5%

14.4%

54.1%

28.7%

65.6%
53.7%

27.9%
35.5%

図 Ⅲ-④-3-3： CMS/LMS が有する機能の利用状況（全体） アクティブなユーザ数は 189,151 名（回答数は 111 学部・研究科）
 総データ量は 33.9TB （回答数は 74 学部・研究科）
であること，e ポートフォリオについては，
 利用対象総科目数は 72,378 科目（回答数は 65 学部・研究科）
 アクティブな科目数は 47,426 科目（回答数は 65 学部・研究科）
 アクティブなユーザ数は 95,209 名（回答数は 69 学部・研究科）
 総データ量は 11.9TB （回答数は 28 学部・研究科）
その結果，CMS/LMS については，
 アクティブな科目数の割合は 12.3%（回答数は 119 学部・研究科）
 アクティブな科目当たりのデータ量は 3.4GB（回答数は 74 学部・研究科）
e ポートフォリオについては，
 アクティブな科目当たりのデータ量は 262.5MB（回答数は 28 学部・研究科）
であることが分かった．
「学部・研究科独自に導入し利用している」と回答した学部・研究科について，
CMS/LMS が有する機能の利用状況について訊ねた結果を図 Ⅲ-④-3-3 に示す．図では，「非常によく使われている」「よく使われている」「ある程度使われている」を合わせた
割合が多い，次の順番に並べている:
1. 授業資料の提供（プレゼンテーションファイル，補助教材や自学自習用教材を含む．ビデオ教材は除く）
2. 課題レポートの提出・採点・返却
3. メール等による教員・学生間のやりとり
4. テスト（自学自習用の小テストを含む）
5. ディスカッション
6. ビデオ教材の提供
7. SCORM 教材等のオンライン教材（IMS CommonCartridge に対応したオンライ
ン教材を含む）8. ブログやマイクロブログ等のソーシャルネットワーキング機能111

利用対象総科目の8割以上
利用対象総科目の2割以上，4割未満
科目情報（全体，n=113）
履修情報（全体，n=113）
シラバス情報（全体，n=111）

利用対象総科目の6割以上，8割未満
利用対象総科目の4割以上，6割未満
利用対象総科目の2割未満
分からない
0.9%
32.7%
1.8%
43.4%
19.5%
1.8%
5.3%
29.2%
0.0%
41.6%
23.0%
0.9%
1.8%
25.2%
45.9%
23.4%
2.7% 0.9%

図 Ⅲ-④-3-4：CMS/LMS の教務システムとのデータ連携（全体）
利用対象総科目の8割以上
利用対象総科目の2割以上，4割未満
科目情報（全体，n=77）
履修情報（全体，n=76）
シラバス情報（全体，n=76）

利用対象総科目の6割以上，8割未満
利用対象総科目の2割未満
1.3%
33.8%
1.3%
36.4%
1.3%
0.0%
36.8%
0.0%
39.5%
0.0%
0.0%
28.9%
47.4%
0.0% 0.0%

利用対象総科目の4割以上，6割未満
分からない
26.0%
23.7%
23.7%

図 Ⅲ-④-3-5：e ポートフォリオシステムの教務システムとのデータ連携（全体）9. Wiki
これも機関別アンケートの結果と同じである．
さらに，「学部・研究科独自に導入し利用している」と回答した学部・研究科について，教務システムとの連携状況について訊ねたところ，全体として，以下の機関別アンケートと同じ傾向が見られる (図 Ⅲ-④-3-4 および図 Ⅲ-④-3-5 参照):
 科目情報・履修情報・シラバス情報のいずれも連携する場合は多くの科目が対象となっている シラバス情報は科目情報・履修情報よりは連携しているところが少ない
１−３−２）CMS/LMS，e ポートフォリオのクラウド化に向けた現状
CMS/LMS および e ポートフォリオシステムを「学部・研究科独自に導入し利用している」と回答した学部・研究科についてその運用形態・ASP 化を訊いたところ，全体として，機関別アンケートと同じ傾向が見られる (図 Ⅲ-④-3-6 および図 Ⅲ-④-3-7 参
照): どちらも大学または学部・研究科が管理する設備にシステムを導入して運用する「オンプレミス型」が圧倒的に多い
 e ポートフォリオシステムの方が民間企業等，外部組織が提供する設備やシス
テムを通じてサービスとして利用する「ASP 型」の割合が多い
 CMS/LMS および e ポートフォリオシステム双方とも多くの学部・研究科は ASP化の計画がない112オンプレミス型（大学または学部・研究科が管理する設備にシステムを導入して運用）
ASP型（民間企業等，外部組織が提供する設備やシステムを通じてサービスとして利用）
外部データセンター型（民間企業等，外部組織が提供するデータセンターに大学または学部・研究科が管理するシステムを導入して運用）
CMS/LMS 全体（n=119）

76.5%

CMS/LMS 国立（n=27）

18.5%

63.0%

CMS/LMS 私立（n=66）

80.3%

CMS/LMS 公立（n=11）

0.0%

60.6%

25.4%

68.2%

eP 私立（n=37）

20.0%

14.1%
27.3%

62.2%

eP 公立（n=4）0.0%

0.0%
10.0% 0.0%

80.0%

eP 国立（n=22）

10.6%

27.3%
90.0%

CMS/LMS 短大（n=5）

21.6%

50.0%

4.5%
16.2%

50.0%
100.0%eP 高専（n=3）
eP 短大（n=5）

3.7%

13.6%

72.7%

CMS/LMS 高専（n=10）eP 全体（n=71）

7.6%

33.3%

40.0%

0.0%
0.0%
40.0%

20.0%

図 Ⅲ-④-3-6：CMS データ S および e ポートフォリオシステムの運用形態

これらは，機関別アンケート結果と同様，次の ASP 化のデメリットが影響していると思われる (図 Ⅲ-④-3-8 参照):
 教育学習活動に関わる様々な記録が業者側のシステムに蓄積されるため，セキュリティやプライバシー上の懸念が生じやすい (60.1%，全体)
 学部・研究科のニーズに応じたカスタマイズを行いにくい (50.8%，全体)
 学部・研究科のニーズに応じたカスタマイズを行うコストが高い (50.4%，全体)
 特定の業者にロックインしてしまう（業者変更ができない） (47.7%，全体)113

ASP型に移行することが決まっている
ASP型に移行する計画がある、または、検討を行っている
ASP型に移行する検討は行っていない
CMS/LMS 全体（n=91） 1.1% 11.0%

87.9%

CMS/LMS 国立（n=18） 0.0% 16.7%

83.3%

CMS/LMS 私立（n=49） 2.0% 12.2%

85.7%

CMS/LMS 公立（n=9）0.0% 0.0%
11.1%
CMS/LMS 高専（n=9） 0.0%

100.0%
88.9%
100.0%

CMS/LMS 短大（n=6） 0.0%
0.0%
eP 全体（n=55）0.0% 9.1%

90.9%

eP 国立（n=13） 0.0%
0.0%
eP 私立（n=29）0.0% 13.8%

100.0%

eP 公立（n=3）0.0% 0.0%

100.0%eP 高専（n=6）0.0%

86.2%
16.7%

83.3%

eP 短大（n=4）0.0%
0.0%

100.0%

図 Ⅲ-④-3-7：CMS/LMS および e ポートフォリオシステムの ASP 化

図 Ⅲ-④-3-8：データ型のデメリット（複数回答あり）

１−３−３）CMS/LMS および e ポートフォリオシステムのクラウド化に向けた方向性
ASP 化のメリットとしては次の事項が注目されている (図 Ⅲ-④-3-9 参照)：
 学部・研究科に技術者がいなくても導入・利用できる (61.4%，全体)
 短期間で導入・利用できる (46.4%，全体)114

 低コストで導入・利用できる (40.4%，全体)
 利用のピークに合わせた計算機資源や設備投資が不要になる (33.1%，全体)
ASP 型での利用を促進する要因について訊ねたところ以下の項目が上位を占めた (図Ⅲ-④-3-10 参照)： 低コスト (61.2%，全体)
 セキュリティやプライバシーを強化する技術整備 (28.5%，全体)
 学外接続ネットワークの高速化 (24.7%，全体)
これらも，若干順位が異なるところがあるがほぼ機関別アンケートと同じ結果である．

115

図 Ⅲ-④-3-9：ASP 型のメリット（複数回答あり）

図 Ⅲ-④-3-10：CMS/LMS や e ポートフォリオシステムの ASP 型での利用を促進する要因１−４）より教育的な面での現状
MOOC (Massive Open Online Courses) やアクティブラーニング等，クラウド時代が進116

行するにつれて今後必要となると考えられるより教育的な面での現状については，同時期に別途行われた「高等教育機関等におけるＩＣＴの利活用に関する調査研究によるアンケート（代表: 京都大学飯吉透教授）」において調査・報告されている．以下にその概要をまとめる．詳細は，当該調査の最終報告書を参照されたい．

１−４−１）オープンな教育リソース (OER)・MOOC
OER に関する認識度や将来的な価値については，公立大学や短期大学と比べて国立大
学や高等専門学校で肯定的だが，高等専門学校については 8 割程度，大学事務局・短期大学については 5 割程度に留まっている．全世界的な広まりを見せているオープンエデュケーションの動向を鑑みると，今後も OER を効果的に活用した実践への支援や事例紹介等
を通じて国内の認知度を上げていくことが必要である．

１−４−２）MOOC による講義の提供およびその目的
Coursera，edX，Udacity 等の MOOC の主要プラットフォームにより提供された国内の講義は，2013 年度中は 2 科目（東京大学）のみであったが，次年度に予定している機関が 12，今後 3 年以内については 26 件と多くはなかった．2 割の国立大学が将来的な導入・提供を検討しており，講義提供機関が増加する可能性はある．その質を確保するためにも，講義コンテンツ作成に関わる国内のインストラクショナルデザイン，ICT 技術者，ラーニ
ングアナリティクスなどの専門家を養成することが急務であるとともに，先行する講義提供機関の知識や経験，ノウハウを集約・共有するための環境整備なども重要である．一方，
MOOC で講義を提供する目的としては，「社会貢献」「教育情報の発信」「多様な教育提供の選択肢の拡大」「学生の学習環境の向上」「高校生向けの広報」が多く，「留学生数の増加」「社会人学生の獲得」「大学間の単位互換」等への期待はそれほど高くなかった．

１−４−３）LMS
全学導入率は，国立大学では 8 割弱，公立大学で約 4 割，短期大学で約 2 割となり，前回の放送大学調査と比較して導入率は伸びている．LMS の利用状況については，約 7 割の大学事務局が把握しておらず，短期大学では約 9 割が把握できてなかった．LMS を利用している場合にも，「1〜20%の科目での利用」との回答が最も多く，ラーニングアナリティ
クスや学びのパーソナライゼーションへの対応に向けて，その基盤となる LMS の組織的導入や利用の奨励が必要である．

１−４−４）導入している ICT ツールおよびその目的機関で導入されている ICT ツールとして導入率が比較的高いものは「シラバスの公開」「学生情報システム(SIS)」「キャンパス内の無線 LAN」となっており，「講義教材・ビデオの一般公開 (OCW，YouTube 等)」「電子教科書の作成・提供」「e ポートフォリオ (学習支
117

援)」
「機関の公式 SNS」は導入率が低い．全体的に見て，前者のような情報インフラは整備されつつあるが，後者のような教授学習に直接関わるような ICT 環境の整備が遅れている．一方，最も多い利用目的は「授業に関する教材の提供」「学務情報の伝達」で，いずれも教材・情報の学生への一方方向伝達を目的としているものであった．アクティブラーニ
ング型の授業で想定される「学生間のコミュニケーション」「学習者間のグループ活動による学習」「授業中の投票」は相対的に低く，今後は授業内外での ICT ツールの効果的な利用を促すことが必要である．

１−４−５）教材・コンテンツの作成・共有状況「教員が独力で作成」の回答が支配的で，「教員が同僚と協力して作成」が次点であった．
高等専門学校ではそれらが比較的に高かったが，「1〜25%の科目」に留まっていた．共有については約 9 割が行っておらず，全体的にみて不活性であった．今後，教材や講義ビデオの共同開発や共同利用が広まるような仕掛けや支援が必要である．

１−４−６）ICT 活用教育の導入による効果
最も肯定的な項目として回答が多かったのは「学生に対するより便利な環境の提供」だ
ったのに対し，「教育の質が向上した」「アクティブラーニング型授業が増加した」「PBL 型
授業が増加した」「授業外学習時間が増加した」等はそれほど多くなかった．これらは，現在課題となっている「教育の質の向上」「授業外学習時間の向上」「アクティブラーニングの推進」等が ICT 活用とうまくリンクしていない可能性もあり，両者を結びつけるような教育実践の成功事例の提示等も効果的であろう．

１−４−７）ICT 活用教育の導入・推進に対する阻害要因「システムやコンテンツを作成，維持する人員の不足」「教職員の ICT 活用スキル不足」「教職員への ICT 活用の技術支援体制の不足」「予算の不足」という人的・経済的リソースの不足が阻害要因の上位に挙げられており，その解消に向けた支援のあり方が今後の課題である．

１−４−８）e ラーニング又は ICT 活用教育の推進組織
全学共通組織が存在する場合も多いが，個人や教員グループが推進している場合もある．
学内資金も確保できていない機関も多数存在する．人材も概ね「学内兼任者」「学内専任者」
による場合が多く，学内で人材を調達できていない機関も多数存在する．このように，ICT利用による教授学習を支援する組織が，人的・資金的な不足により十分に機能できていない可能性がある．今後は，機関を越えたネットワーク化・交流も視野に入れ，各機関に支援を担当する組織の設置が必要である．

118

2. 検討結果
今回実施したアンケート調査結果から，教育支援に係るアカデミッククラウド環境の構築に際して重視すべき事項として，(1) 低コスト化，(2) セキュリティ・プライバシの強化のための技術整備，(3) 学外接続ネットワークの高速化，が明確になっている．
中でも，民間事業者による無料メールサービスが提供されるようになった学生メールは，
セキュリティ・プライバシ上の懸念やカスタマイズ・ベンダーロックインの問題がある
ものの，低コスト化がドライビングフォースになって民間企業等，外部組織が提供する設備やシステムを通じてサービスとして利用する ASP 型でのクラウド利用がすでに進んでいる．
一方で，アンケート調査結果からは，
 CMS/LMS・e ポートフォリオシステムとも，大幅なコストダウンやセキュリティ・プ
ライバシに関する懸念払拭されない限り，当面はオンプレミス型での導入・運用が継続すること
 学生端末システムは，デスクトップクラウド等のクラウド型への移行の検討を行っているところが多く，学内の有線・無線ネットワークの高速化を前提にほぼプラ
イベートクラウド型での導入・運用が想定されていることも明確になっている．
これらのことから，教育支援に係るアカデミッククラウド環境は，当面は，大学または学部・研究科が管理する設備にシステムを導入して運用するオンプレミス型の延長としてのプライベートクラウド型が，学内の有線・無線ネットワークの高速化を伴いながら進展すると考えられる．民間企業等，外部組織が提供する設備やシステムを利用する
パブリッククラウド型への移行は，(1) 低コスト化，(2) セキュリティ・プライバシの強化のための技術整備，(3) 学外接続ネットワークの高速化の進展次第と考えてよかろう．
より教育的な観点からのアンケート調査結果からは，授業内外での ICT ツールの効
果的な利用の促進，教材や講義ビデオの共同開発や共同利用が広まるような仕掛けや支援，ICT 活用とうまく結び付けた教育実践の成功事例の提示等が必要になっていることが分かった．特に，大学間の連携をシステムレベルから活用レベルまで深めることにより，講義コンテンツ作成に関わる国内のインストラクショナルデザイン，ICT 技術者，
ラーニングアナリティクスなどの専門家の養成や人的・経済的リソースの不足の解消，各機関の知識や経験・ノウハウを集約・共有する環境整備が必要である．全体として，教育支援のための情報インフラは整備されつつあるが，「教育の質の向上」「授業外学習
時間の向上」「アクティブラーニングの推進」等，現在課題になっている教授学習に直接関わるような ICT 環境の整備や実践が遅れていることが明確になった．

119

3. 要求要件（標準仕様）「学び」が，教育学習活動における教員や教育学習メディアとのインタラクションを通じてなされることを前提とすれば(図 Ⅲ-④-4-1 参照)，そのインタラクションを観測することにより大学における物理世界・仮想世界の様々な「学び」を可観測化することができ，大学における教育学習活動に関わる様々な活動を通じて教育ビッグデータが形成されると考えられる．
物理世界における学習メディア

仮想世界における学習メディア

観測

観測

教材

アクセス
端末
CMS/LMS

インタラク
ション

インタラク
ション

学生

教員

教育ビッグデータ
図 Ⅲ-④-4-1：クラウド時代の教育学習支援のあり方

!

!

!

図 Ⅲ-④-4-2：次世代教育学習環境
120!

この教育ビッグデータを解析し，様々な形で教育学習活動に活かそうする取り組みがラーニングアナリティクスとして立ち上がりつつある．大学における直接的な教育現場ではないものの，現在の MOOC はこの流れを先取りしているとも考えることができる．そして，教育プログラムや大学の枠組みを越えて大規模に観測を行い，学びのコンテキストを揃えて統計的に解析することにより，教育ビッグデータに基づいた気づきと自学自習を促すことができるような「参加型学びの環境」を次世代教育学習環境として整備することもできよう(図 Ⅲ-④-4-2 参照)．

プログラム

月
週
時
分

学習
行動

クラス，学科等のある程度のまとまり

教育プログラムごとの学び
集団（群）

個人

教室
自宅

時間積分

学期

学習環境
特性

学びの
共同体
としての
大学

クラス，学科等のある程度のまとまり

時間積分

時間特性

年

蓄積された
学び

通学中

群特性

図 Ⅲ-④-4-3：観測対象空間
インストラクショナル
デザイン

インストラクショナル
デザイン

コンテンツ

コンテンツ

大学における
ラーニングアナリティクス

大学間における
ラーニングアナリティクス

LMS/CMS

MOOC基盤

オンキャンパス

公開(SPOC: Small Private Online Course)(MOOC: Massive Open Online Course)

図 Ⅲ-④-4-4：次世代授業支援環境としての SPOC-MOOC 統合環境

しかしながら，観測対象の大学教育は非常に多様である．例えば，瞬時的な学習から単位(学期)や学位(年)に至る時間軸，個人からクラス・学科等の教育プログラムまでの
121

群特性の軸，教室・通学途中・自宅など学習場所等の学習環境の軸の 3 つの軸で考えると図 Ⅲ-④-4-3 のような観測対象空間を考えることができるが，明らかに単一の大学や教育プログラムでは密度の高いデータを観測することはできない．これに対応するた
めにも，情報基盤レベル，ラーニングアナリティクス，コンテンツ，インストラクショ
ナルデザインのそれぞれのレベルで大学間連携が必要になる（図 Ⅲ-④-4-4 参照）．現
在，MOOC の活用方法の一つとなっている MOOC の SPOC (Small Private Online
Course) としての活用はその現れでもある．その際，システム的には全国拠点（あるいは地域拠点）では MOOC，各大学はその科目を SPOC として利用するような拠点と各大学をつなぐ分散型アーキテクチャになると考えられる（図 Ⅲ-④-4-5 参照）．
以上，調査結果も踏まえ，教育支援に係るアカデミッククラウド標準仕様をまとめると以下の通りである:
インストラクショ
ナルデザイン

インストラクショナ
ルデザイン
コンテンツ
大学におけるラーニング
アナリティクス

インストラクショナル
デザイン

インストラクショナ
ルデザイン

コンテンツ
大学におけるラーニング
アナリティクス

コンテンツ

コンテンツ

大学におけるラーニング
アナリティクスLMS/CMS

LMS/CMS

大学間における
ラーニングアナリティクス

LMS/CMS

MOOC基盤
インストラクショ
ナルデザイン
コンテンツ
大学におけるラーニング
アナリティクス

インストラクショナ
ルデザイン
インストラクショナ
ルデザイン

コンテンツ
インストラクショ
ナルデザイン

コンテンツ

LMS/CMS

コンテンツ
大学におけるラーニング
アナリティクス大学におけるラーニング
アナリティクスLMS/CMS大学におけるラーニング
アナリティクスLMS/CMS

LMS/CMS

図 Ⅲ-④-4-5：拠点-分散型アーキテクチャ

1. 各大学の CMS/LMS ・e ポートフォリオシステムはオンプレミス型であること
2. 低コスト化，セキュリティ・プライバシ上の懸念を払拭可能な技術基盤を有すること
3. 複数のシステムに一元的にアクセスできるユーザインタフェースを有すること
4. 学内外の高速なネットワーク基盤上に実現すること
5. 学びと教えを可観測にし蓄積・再利用できる技術基盤を有すること最後に，10 年間のロードマップを図 Ⅲ-④-4-6 に例示する．教育支援のための情報インフラは整備されつつあるが，教授学習に直接関わるような ICT 環境の整備や実践が遅れていることから，インフラ的情報サービスを整備しつつ，「教育の質の向上」「授122業外学習時間の向上」「アクティブラーニングの推進」等に直接つながる教育学習支援
サービスを整備する戦略が適当である．

教育学習支援サービス
・ POC-MOOC 統合環境
・パーソナルラーニング情報基盤

インフラ的情報サービス
・Desktop as a ervice
・メール
・ビデオプラットフォーム（日本版 You ube）
2024

2014

図 Ⅲ-④-4-6：10 年間のロードマップ

123

⑤ 認証連携に係るアカデミッククラウドシステムの調査検討（概要）本業務を開始するにあたって、キックオフシンポジウムの準備を進めるとともに、年度末までの事業スケジュールの詳細化や認証連携分野における調査内容の他分野との詳細な調整を実施した。大規模アンケート調査に関しては、認証連携分野の標準仕様をまとめるにあたって必要となる、現状把握を中心としたアンケート内容の確定を進めた。回答者の負担を軽減するために、認証連携分野は、他分野が実施するアンケートの一部分として含める形とした。大学ICT推進協議会年次大会におけるア
ンケート結果暫定報告に合わせて集計を進めた。その後は、最終報告書に掲載する最終的なアンケート集計結果の処理を進めた。アカデミッククラウドと認証連携との海外動向については、インターネットを使っての予備的な調査を進めた。特に詳細な情報の収集が必要とされたイギリス、オランダの動向については、10月23～28日に渡欧し、サービス担当者と直接情報交換を行った。認証連携に係る標準仕様として、他分野と調整を進めながら、アカデミッククラウドを利用する上で必要不可欠な、“格付け、認証強度”、“IDプロビジョニング”、“認証連携システムの冗長化”について、その内容の詳細な検討を行った。最終報告書の構成を全体で調整したうえで、上記の業務成果としての認証連携分野の報告書をまとめた。
1. アンケート調査結果
各機関における統合認証環境の現状と今後の方針についてのアンケート結果は、以下の通りである。回答全数は 547 機関であり、内訳は、研究機関 12、国立 76、公立 52、
私立 277、高専 39、短大 91 となっている。

図 Ⅲ-⑤-1 ICT サービスにログインするためのアカウントの一元化についてのアンケート調査
結果124

図 Ⅲ-⑤-2 SSO を実現するための認証連携システムの導入についてのアンケート調査結果

統合認証環境については、国立大学(約 80%)を中心に整備が進んでいる。その他は、50%前後となっている。SSO 環境整備は、研究機関と国立大学で 60%以上の整備が進んでいる。公立、私立大学、高専、短大についても多くの機関で検討が進められている。
各機関における統合認証環境の冗長化の現状と今後の方針は以下の通りである。認証
情報(LDAP, AD)の冗長化は、約 80%の機関で冗長化を実現済みであるが、複数拠点における冗長化については十分に進んでいない。認証システム(IdP)の冗長化は、約 40%の機関で冗長化を実現済みであるが、複数拠点における冗長化はあまり進んでいない。

図 Ⅲ-⑤-3 認証情報(LDAP,AD)の冗長化についてのアンケート調査結果

125

図 Ⅲ-⑤-4 認証システム(IdP)の冗長化のアンケート調査結果

各サービスにおける認証方式の現状は、以下の通りである。統合認証システムとの直接接続による認証連携(LDAP や AD 接続)については、ICT 関連で 60%台(ストレージは 78%)に達している。SAML、シボレスによる認証連携は、ICT 関連とコンテンツで、10%前後で認証連携ができている。一方、システム観点で事務・経営系を見てみると、何らかの認証連携(アカウント同期、統合認証システム、SAML 等連携)ができているものが、50%前後と低い傾向にある。その中においては、学務情報、就職支援は 65%程度で認証連携ができており、他と比べると高い。研究機関、国立大学、公立大学、私立大学、高専、短大といった機関による大きな違いは見られない。

126

図 Ⅲ-⑤-5 各サービスにおける認証方式についてのアンケート調査結果

127

2. 検討結果
2.1 格付け、認証強度
A．格付け
情報格付けの基準は、「高等教育機関の情報セキュリティ対策のためのサンプル規程集」において、“表 Ⅲ-②-3 情報格付け基準”となっている。格付けの区分は、機密性＝3 区分、完全性＝2 区分、可用性＝2 区分があり、計 12 通りの組み合わせ（例：3-2-2）に区分される。
情報の格付けの問題点は、組み合わせが多いことに加えて、システムで扱う情報に対して格付け自体が難しいことも挙げられる。解り易い例では、ホームページで扱う公開
情報は一般的に機密性 1 情報であり、認証システムで扱う利用者のパスワードは機密性
3 情報である。しかし、学内のシステムで扱う情報の殆どは機密性 2 情報であり、教職員名簿、学生情報、履修情報、財務や総務の事務情報などがそれに相当する。これらの情報は、機密性、完全性、可用性の観点から幅が広く、取扱い制限によって区別される。
また、大学で提供したメールアドレスのようにフィッシング詐欺や標的型攻撃を避ける
ためには機密性 2 情報であるが、内外とのコミュニケーションで必要なため実質機密性
１情報という情報もある。
このような 12 通りの組み合わせと殆どが機密性 2 情報であるという問題などを回避するために、実際の情報の種類、および、各種類の情報が機関に与える影響力を検討、整理することで、セキュリティ分野では情報の重要度 4 段階として再定義し、現実的なレベルに簡素化した。重要度 4 段階の定義(格付けと重要度の読み替え)は“表 Ⅲ-②-4
機関が保有する情報の重要度”の通りです。
重要度との読み替えの際、基本的には機密性との対応になるが、漏えい、紛失、改ざん等による影響によって幅が出てくることに注意すべきである。また、完全性や可用性の要件によっても重要度に幅がでてくる。また、システムが扱う情報が多岐にわたる場
合、その重要度には幅を持たせる必要もある。
B. 認証強度
リスク評価の結果格付けされた情報は適切な方法で保護する必要がある。論理的セキ
ュリティの中核をなすものがアクセス制御や認証である。現在、認証には様々な手法が開発されてきているが、各手法の保証レベルには差がある。また、実現を含めた運用コ
ストについても各手法によって差がある。
LoA は認証の保証レベルを定めるものであるが、認証強度は重要な評価要素である。
ベースとなる文書（NIST SP 800-63, ISO/IEC 29115）において、4 レベルの認証強度が定義されている。
ここでは、高い保証レベルを求めるのに一定のコストをかけるのは許容できるという128

条件のもと、実際に運用可能な認証の手法のうち、認証強度について、NIST SP 800-63
をもとに 4 段階に分類した。
表Ⅲ-⑤-1 認証強度レベル

認証強度

評価項目

レベル
レベル１

パスワードで管理し、発行されたパスワードを安全な形で利用者に届
けること。

レベル２

上記に加え、パスワードポリシー等により、十分複雑なパスワードが使用されていることを保証すること。

レベル３

ワンタイムパスワードのハードトークン、または公開鍵か証明書による認証方式を採用すること。後者の場合、HD 等に格納してもよいが、
パスワード等を設定して二要素認証を実現すること。

レベル４

証明書による認証方式を採用すること。ハード的に保護されたデバイスに格納すること。

パスワード認証に関しては、自分でパスワード変更が可能であることが必須である。
また、レベル 3 以上に関しては、CRL 等を用いたトークンの失効管理がさらに要求される。
代表的な認証手法のうち、パスワード認証はレベル 1 か 2、IC カードに証明書を格納して認証に使用するものはレベル 3 以上に分類される。一部で利用されている二段階認証（たとえばパスワード認証を行ってさらに追加パスワードを要求するもの）は正しく運用することでレベル 2 以上であると考えることができる。
レベル 1 とレベル 2 はパスワード認証を許容している。ここでの差は、レベル 2 が十分コントロールされたパスワード使用を要求することである。特に被発行者の確認の手
順は重要になる。この種のアイデンティティの管理は認証強度の一部を構成すると考えられる。認証強度に要求されるアイデンティティのライフサイクル管理を以下のように定義する。これも、LoA に関する標準的な文書に則っている。

129

表Ⅲ-⑤-2 認証強度に要求されるアイデンティティのライフサイクル管理

認証強度

評価項目

レベル
レベル 1

利用資格を定めていること。

レベル 2

上記に加え、利用資格が何らかの形で保証されていること。大学で言えば、人事の DB や学務の DB と（資格喪失確認も含めて）連動して資格確認が行われること。また、それ以外の人間に対しては、適切なコ
ントロールがなされていること。

レベル≧3

上記に加え、その検証がなされていること。特に資格の取得時に、下の学校の卒業証明、住民票その他の記録を用いて検証可能になっていること。

レベル１は、組織の部局レベルで、ローカルに運用されている認証システムが想定される。一般的な管理手法のもと、アカウントを部局の責任で発行するシステムにおいても、適切な運用を行えばレベル１の強度を主張できる。一方、レベル 2 では、組織の意思を反映したアカウントのライフサイクル管理が必要である。全学規模で管理されている人事 DB や学務 DB と直結したアカウント管理を行う全学認証システムの運用を適切に行うことで、レベル 2 の強度を主張できる。レベル 3 以上は、全学規模で高い強度の認証トークンを運用することを想定する。公開鍵証明書やワンタイムパスワードのためのトークンを運用する場合がこれに相当する。
2.2 ID プロビジョニング
学外のクラウドを利用する際、認証フェデレーションによるシングルサインオンを用いることによって安全に利便性を高くすることが可能となる。しかし、仕様上、利用ユ
ーザのアカウントを保持する必要があるクラウドサービスでは、機関内のアカウント情報をクラウドサービスに対して登録・管理する ID プロビジョニングを行う必要がある。
以下に、各クラウドサービスの種別と、ID プロビジョニングとして必要な機能を分類する。
(1) アカウントを持たないサービス（例. 電子ジャーナル等）：
契約している機関等からのアクセスであることを確認して、許可を行うサービス(2) アカウントを一斉登録するサービス（例. メール等）：
メール受信等、利用者が実際にアクセスをしていない状況においてもサービスが提供されるために、全アカウントの一斉登録、更新が必要なサービス(3) 利用時にアカウントが必要なサービス（例. SNS、ストレージ等）
130

利用者がアクセスする前にはアカウントが無くても良く、利用者がサービスの利用を開始する際にアカウント登録を行うサービス(1) アカウントを持たないサービスでは、ID プロビジョニングは不要であるが、(2)アカウントを一斉登録するサービスでは、事前の全アカウント登録、更新を行う ID プ
ロビジョニングが必要である。この ID プロビジョニングでは、従来、CSV ファイル等
を用いて手作業でクラウドサービスに登録、更新することが一般的であり、運用工数が掛っていた。そのため、クラウドサービス側でこれを自動化する独自の API が提供されるようになり、これを用いて学内 ID 管理システムと接続することで、自動登録、定期更新を行えるようになった。しかし、新たなクラウドサービスを導入する度に、学内システム側での改修、設定が必要となり、クラウドサービスの数に比例して、機関側の改修、設定費用が増加するため、クラウドサービス導入によるコスト削減に対する障害の一つであった。したがって、クラウドサービスの利用普及にとって ID プロビジョニン
グの運用工数削減、改修、設定費用の削減は重要な課題あり、その仕様の統一や普及が望まれる。
(3) 利用時にアカウントが必要なサービスでは、事前の一斉アカウント登録は不要で、利用者が初めてそのクラウドサービスにアクセスした際にアカウント登録を行う。これは、JIT (Just-In-Time) ID プロビジョニングと呼ばれる方法で、事前登録が不要となるメリットがあるが、クラウド上で登録されたアカウントの管理を行うための学内 ID
管理システムとの連携の仕組みが必要となる。SAML2.0 による JIT プロビジョニングとして、アプリケーション側でユーザの自動登録を行うこともあるが、ユーザ情報の変更、削除は別途手動で行う必要がある。そのため、(2)と同様の理由により、ユーザ情報の変更、削除を含めた JIT プロビジョニングの仕様の統一、普及が望まれる。
ID プロビジョニングの標準として、SPML（Service Provisioning markup Language）
が OASIS PSTC(Provisioning Services Technical Committee)により策定されている。
SPMLv1.0 が 2003 年にリリースされ、SPMLv2 が 2006 年にリリースされたが、普及にはいたっていない。これは、汎用的な仕様となっているために複雑であったこと等によると考えられる。
一方、SCIM(System for Cross-domain Identity Management)は、IETF で標準化が進められているシンプルな ID プロビジョニングの標準仕様である。SCIM1.0 が 2011 年 12月にリリースされ、最新版は 2012 年 7 月リリースの SCIM1.1 であるが、現在 SCIM2.0
が Draft として仕様策定中である。なお、SCIM は IETF における標準化が開始されるまでは Simple Cloud Identity Management の略とされていた。
特徴は、下記となっている。
 REST に基づく Web API
 ユーザアカウントの CRUD 操作（Create,Read,Update,Delete）を提供
131 バルク操作を提供
 スキーマ定義
以下に SCIM によるアカウント生成とアカウント削除のシナリオを記載する。
(1) シナリオのアクター
 ECS(Enterprise Cloud Subscriber)： クラウドサービスを利用する組織で、利用者の ID 管理を行う。
 CSP(Cloud Service Provider)： クラウドサービスのプロバイダ。
 CSU(Cloud Service User)： クラウドサービスを利用するユーザで、ESC に所属する。
(2) アカウント生成（Push）のシナリオ

図 Ⅲ-⑤-6

SCIM のシナリオ（アカウント生成-Push）（出典： SCIM scenarios draft-scim-scenarios-04 Figure 1.3.1-1）
このシナリオでは、CSP-1 と CSP-2 が CSU のアカウント情報を共有する何らかの契約を交わしているとする。CSP-1 は ECS-1 からアカウント生成の要求を受信する。CSP-1
は CSU の新規アカウントを生成して、CSP-2 にアカウント生成の要求を送信する。CSP-1
は CSU-2 から新規アカウント生成の完了通知を受信後に、ECS-1 に生成完了の通知を送
信する。

132

図 Ⅲ-⑤-7

SCIM のシナリオ（アカウント削除-Push）（出典： SCIM scenarios draft-scim-scenarios-04 Figure 1.3.3-1）
このシナリオでは、CSP-1 と CSP-2 が CSU のアカウント情報を共有する何らかの契約を交わしているとする。CSP-1 は ECS-1 からアカウント削除の要求を受信する。CSP-1
は CSU のアカウントを使用停止にして、CSP-2 にアカウント削除の要求を送信する。
CSP-2 は CSP-1 の要求に従いアカウントを削除する。CSP-1 は CSU-2 からアカウント削除の完了通知を受信後に、ECS-1 に削除完了の通知を送信する。ここで、CSP-1 はアカ
ウントを使用停止にして、CSP-2 はアカウントを削除している。このように、同じ SCIM
操作においても、CSP の処理は異なる実装としてもよい。
次に、SCIM のスキーマについて以下に記載する。SCIM のスキーマには、コアスキー
マと拡張スキーマがあり、コアスキーマは下記の通りである。
SP(Service Provider)：SCIM プロトコルにより ID 情報を提供する Web アプリケーシ
ョン（ここでは、クラウドサービスと考える）
Consumer：SCIM プロトコルを利用して SP が管理する ID 情報を操作する Web サイト、またはアプリケーション（ここでは機関側の統合 ID システム、または IdP と考える）
Resource：SP が管理するアーティファクトで、１つ以上の属性を含む
id

SP 内で管理 ・SP が設定する ID
さ れ る SCIM ・再定義しない永続的な ID であること
Resource の ・SP 内でユニークであること
ID

externalId

・必ず値を持たなければならない

Consumer が ・Consumer が設定する ID
133

定 義 す る リ ・externalId が空のリソースがあってもよい
ソースの ID・SP は、必ず Consumer のスコープ内で externalId を解釈しなければならない

meta

Resource の ・サブ属性には
メ タ デ ー タ created,lastModified,location,version,attributes
を 含 む 複 数 がある
属性

・全てのサブ属性はオプショナルである

2.3 認証連携システムの冗長化
SAML での認証連携を活用することにより、複数のアカデミッククラウドを使う際の認証アカウントは統合されるが、認証連携サービスを提供する機関側の認証連携サーバ
が災害や停電で停止したら、クラウドサービスが持つ高可用性も活用できない。利便性の高いアカデミッククラウドを実現するためには、各大学が設置する認証連携基盤の可用性の高さが重要である。学術機関における認証情報の冗長化の現状調査、認証システム（IdP） の冗長化方式による可用性評価、認証セッションの同期方式の比較と運用評
価についてまとめ報告する。
2.3.1 学術機関における認証システムの冗長化調査
一般的に、
SLA などを提供するクラウドサービスは十分な可用性を有しているが、各々の学術・研究機関が管理・運用している IdP については、冗長化や可用性についての報告例が少ない。本事業の大規模アンケートでは、LDAP、AD などの認証情報の冗長化および IdP の冗長化について、「複数拠点による地理的な冗長化」、「単一拠点による冗長化」、「冗長化を検討中」、「冗長化の予定はない」の 4 つの選択肢で調査を実施した。
1.節の図 Ⅲ-⑤-3，図Ⅲ-⑤-4 に示した、各機関における統合認証環境の現状と今後の方針についてのアンケート結果について詳細に解説する。認証情報の冗長化は、研究機関では 100%が単一拠点による冗長化、国立大学および公立大学では約 90%が複数または単一拠点による冗長化を実施している。私立大学、高等専門学校および短期大学においても、60～70%の冗長化が実施されており、冗長化を検討している機関も多い。一方、認証システムの冗長化は、単一および複数拠点による冗長化を実施している機関は、全体の 40%程度になっており、認証データベースの冗長化に比べると半分程度になっている。特に、複数拠点による地理的な冗長化は 15%程度であり、可用性の高いアカデミッ
ククラウドを活用するためにも認証システムの冗長化が必要不可欠であるといえる。
2.3.2 認証システムの冗長化方式による可用性評価
表 Ⅲ-⑤-3 に、IdP の冗長化方式による可用性評価を示す。冗長化方式として、地理的負荷分散(Global Server Load Balancing; GSLB)1 、サーバ負荷分散(Server Load
134

Balancing; SLB)2、DNS ラウンドロビン方式(DNS Round-Robin; DNS-RR)、地理的負荷分散装置の共同利用(Joint usage of Global Server Load Balancing; JuGSLB)を取り上げ、各評価項目について調査した。評価項目として、価格、調達の必要性、機関内へのIdP の設置、DC への IdP の設置、地理的な分散配置、冗長化装置の共同利用の可能性、
障害迂回時の停止時間、認証セッションの同期の必要性、優先順位接続の可能性を比較・検討した。
表Ⅲ-⑤-3

技術項目

IdP の冗長化方式の比較

冗長化方式
GSLB 方式1

SLB 方式2

DNS-RR 方式

JuGSLB 方式

価格1,000 万円

150 万円

0円

0円

調達の必要性

必要

必要

不要

不要

機関内の IdP の設置

可能

可能

可能

可能

DC への IdP の設置

可能

困難

可能

可能

地理的な冗長化

可能

不可能

可能

可能

冗長化装置の共同利用

可能

不可能

不要

可能

障害迂回時の停止時間

1 分程度

数秒

1 分程度

1 分程度

認証セッションの同期 優先順位接続 優先順位接続 必要

優先順位接続用ソフトウェア

の場合不要

の場合不要

の場合不要

優先順位接続

可能

可能

困難

可能

技術的な背景として、IdP は認証セッションをクッキーによって保存している。クッ
キーによってユーザを特定しているため、ラウンドロビンなどによる負荷分散技術を導入した場合、認証セッションを同期するソフトウェアが必要となる。認証セッションの同期ソフトウェアの導入は、IdP のソフトウェアである Shibboleth IdP などにプラグインを追加するため複雑な作業を必要する。本節では、IdP を運用する上で、複雑なソフトウェアの導入を避け、できるだけ認証セッションの同期用ソフトウェアを必要としない冗長化方式を模索し、可用性を評価した。すなわち、IdP サーバに障害が生じ、障害迂回を行った場合、再度認証ログインが求められる。だたし、障害迂回の発生確率は非常に小さい（200 日に１回程度）ため、利用者の利便性は確保されると仮定している。
また、西村らは、IdP サーバ内にプリマリーDNS サービスを併用した DNS 委譲による IdP
1

GSLB は，地理的負荷分散(Global Server Load Balancing)であり，GTM(Global Traffic

Manager)とも呼ばれる．
2

SLB は，サーバ負荷分散(Server Load Balancing)であり，LTM(Local Traffic Manager)とも

呼ばれる．

135

死活制御技術を提案しており3、安価で複数拠点による IdP の冗長化が可能であると述べている。
GSLB による冗長化では 1,000 万円程度の地理的負荷分散装置の調達が必要となる。
IdP の設置場所は、機関内外に関わらず可能であり、複数拠点による地理的な冗長化ができる。障害迂回時の停止時間は、クライアント側の DNS キャッシュのリフレッシュ時間が必要となるため、1 分程度である。認証セッションの同期用ソフトウェアは、複数拠点にある GSLB 装置に蓄積されているサーバの死活管理情報の同期機能と優先順位接続によって不要になる。GSLB 装置は、複数拠点による負荷分散機能が主目的の機器であるため、機器の種類によって複数拠点のおける優先順位接続をサポートしない場合もある。
SLB による冗長化では 150 万円程度のサーバ負荷分散装置の調達が必要となる。IdPの設置場所は、単一拠点での設置となり、地理的な冗長化は不可能である。IdP の障害
迂回時の停止時間は、数秒程度であり IdP サーバの高速切り替えが可能である。認証セッションの同期用ソフトウェアは、優先順位接続の場合は不要である。
DNS-RR による冗長化では、負荷分散装置の調達が不要となり、導入コストを軽減できる。IdP の設置場所は、複数拠点による地理的な冗長化ができる。IdP の障害迂回は
DNS 委譲による IdP 死活制御技術を利用することで実現でき、迂回時の停止時間は 1 分程度である。認証セッションの同期用ソフトウェアは、優先順位接続制御が困難である
ため必要である。
JuGSLB による冗長化では、GSLB 装置が、ping や tcp などのサーバが標準で持っているプロトコルを利用してサーバの死活監視を行う特徴を生かし、GSLB 装置の共同利用を検討したものである。GSLB 装置を共同利用するため、調達は不要である。IdP の設置
場所、障害迂回時の停止時間、認証セッションの同期用ソフトウェア、優先順位接続の技術項目については、GSLB と同様である。
以上より、IdP の可用性を向上するには GSLB または SLB 方式を導入することで、優先順位制御ができ、認証セッションの同期のためのソフトウェアは不要である。GSLB
方式は、地理的異なる場所に物理サーバ設置することで高可用性を提供できるが、GSLB装置の導入費用が 1000 万円程度であるため、単独で各機関が導入することは難しい。
全国に存在する SINET のデータセンター（DC）内に GSLB 装置を設置すれば、GSLB 方式の可用性はさらに向上する。次に、これらの GSLB 装置を共同利用すれば、導入コストを軽減し、高い可用性を実現できる。GSLB 装置の共同利用方式である JuGSLB 方式は、
柔軟な制御と高可用性を有するため、アカデミッククラウドの認証連携基盤の冗長化方式として最適である。DNS-RR 方式は、安価かつ複数拠点に設置できるなどの利点も大きいが認証セッションの同期がほぼ必須であり、IdP 側のソフトウェアの導入に高度が3西村健,

認証基盤の冗長化

技術編，学認 CAMP 2013, 2013/9/11.

136

技術を要する。4.7.4.3 節では、IdP 迂回時の再認証ログインが不要になる認証セッシ
ョンの同期方式の比較について述べる。
2.3.3 認証セッションの同期方式の比較と運用評価
認証システムのソフトウェアとして、学認が推奨する Shibboleth IdP を対象として運用評価を行った。表 Ⅲ-⑤-4 に Shibboleth IdP のクラスタ構成時における認証セッション同期方式の比較を示す。同期方式として、Terracotta 方式、Stateless Clustering
方式、Repcached (memcached)方式の 3 を取り挙げ、価格、設定の煩雑さ、tomcat 7 の動作、ログインセッションの同期、認証セッションの同期，SP 側の制約を比較した。
Terracotta 方式は、設定は複雑であるが，ログインセッションおよび認証セッションの同期が可能であり、完全性の高い冗長化が可能である。一方、Java のフレームワ
ークソフトウェアである tomcat 7 では動作しないため、今後の Shibboleth IdP のバー
ジョンアップの対応が難しく将来性に欠ける。認証セッション同期用のプライベート回
線が必要なこと、および、同期通信量が多いなどの理由から、IdP の複数拠点への配置が困難である。
Stateless Clustering 方式は、SAML アサーション内の Principal Connector に暗号化して認証情報を埋め込み、認証セッションの同期を実現している。設定の煩雑さはShibboleth IdP へのプラグインの追加と設定ファイルの変更のみであり、比較的簡単である。また、SAML アサーションの認証セッション同期用プライベート回線は不要であり、IdP の複数サイトへの配置が可能である。しかし、SAML アサーションの Principal
Connector の文字列バッファーサイズが数キロバイト以上必要とし、一部の SP では、
Principal Connector のメモリサイズが少なめに定義されているため、認証エラーが発生している。
Repcached (memcached)方式は、認証セッションを Shibboleth IdP のストレージサー
ビスを介して repcached に記録し、repcached のマルチマスターレプリケーションによって同期している。設定の煩雑さは repcached と Shibboleth IdP の両方に設定を施す必要があり、Stateless Clustering 方式と比較すると複雑である。認証セッション同期用プライベート回線が必要であるが、通信量は Terracotta 方式に比べると少なく、IdP の複数拠点への配置も可能である。
総合的にまとめると、Terracotta 方式は、設定が複雑なこと、および、tomcat7 で動作しないなどの将来性に乏しいなどの理由から非推奨である。Stateless Clustering
方式は、SP で動作しないサービスが存在しないため非推奨である。現時点で、Repcached
方式が将来性や SP 側の制約が無いなどの理由から、総合的に適している。

137

表 Ⅲ-⑤-4

Shibboleth IdP のクラスタ構成時における認証セッション同期方式の比較

認証セッション同期方式
技術項目

Terracotta 方式 StatelessRepcached

Clustering 方式(memcached)方式

価格

無料

無料

無料

設定の煩雑さ複雑

簡単

中間

tomcat 7 での動作

不可能

可能

可能

不可能

不可能
可能

ログインセッションの同 可能
期
認証セッションの同期

可能

可能

SP 側の制約無し

アサーションサイ 無し
ズに制約有

138

3. 要求要件（標準仕様）
3.1 格付け、認証強度
Ａ．格付け
本調査で対象とする各分野における情報システムは、表 Ⅲ-⑤-5 の通りである。
表 Ⅲ-⑤-5 各分野における情報システム

ICT

教育

事務

コンテンツ

大学経営

電子メール
ストレージサービス(ファイル共有など)
SNS

LMS/CMSe ポートフォリオ

人事給与
財務会計

図書館システム機関リポジトリ

履修登録(シラバス)

学務情報

その他リポジトリ

グループウェア

遠隔講義システム

就職支援

ＯＰＡＣ

その他事務システム
大学評価情報システム
IR データベース(データウェアハウ
ス)
研究者総覧
データベース

学生共通ポータル

CALL システム(語学学習システム)

出退勤

その他検索システム

出張旅費申請システム
目標管理・職員人事等評価システム
電子職員録
施設予約
ペーパーレス会議
システム
ソフトウェアライセンス管理
電子掲示板

Ｗｅｂページ

認証局＆登録局
認証データベース＆認証システム
遠隔会議システム
学内クラウド(IaaS)
学内クラウド(PaaS)IC カード発行システム

Ｗｅｂページ（ＣＭＳ）
データベース
動画配信
教育システムオープンコースウェ
ア
セキュリティ
e-Learnming

安否確認“2.1 格付け、認証強度 Ａ．格付け”では、格付け（機密性、完全性、可用性）を重
要度 4 段階として再定義し、また、“2.1 格付け、認証強度 B．認証強度”では、実際に運用可能な認証の手法について、強度をもとに 4 段階に分類した。ここでは、本調査における各分野と連携し、各サービスの重要度とそれに必要な認証強度レベルを策定した。
重要度と認証強度は基本的に対応する。例えば、重要度Ⅳを扱うシステムやサービス
では、その利用の初期段階で行う本人認証を厳格に行い、成りすましなどを抑止すべきである。一方、公開情報を扱うサービスでは、利用者が本人であるということは問題にならない。この場合、認証強度の高さは要求されない。
重要度と情報の機密性は基本的に対応している。そのため、対象となるサービスが持
つ情報の重要度によって、認証強度が選択される。一方、対象となるアクセス権限の観点から、認証強度が強くなる場合がある。以下に考え方を記述する。

139

対象となる情報の扱いによって、認証強度を強くすべきである。例えば、情報を閲覧するだけの利用者と、情報を変更・削除できる管理者は明らかに権限が異なる。具体的には、一般の利用者が情報を閲覧するのみであれば、通常の認証強度レベル 2 で十分であるが、学務情報を登録・編集する部局の学務担当者は認証強度レベル 2 以上が望まれる。また、同様の考えから、対象情報にアクセスする範囲と深さについても、認証強度レベルを強くする必要がある。例えば、本部事務の人事担当者と部局の人事担当者では、範囲や権限が違ってくるので、認証強度を変えられるように設定できることが望ましい。
このような考え方に基づき策定した、各分野の各サービスにおける重要度と認証強度レベルを表 Ⅲ-⑤-6 ～ 表 Ⅲ-⑤-10 に示す。
表 Ⅲ-⑤-6

ICT サービス分野における各サービスの重要度と認証強度レベルの対応

ICT サービス
サービス

重要度

備考

認証強度

電子メール

Ⅱ～Ⅳ

公開を前提としていないため、漏えい等による影響

一般：レベル＝２

は、Ⅱ以上。どの重要度かはメールの内容による。(※
機密性の高いメールは S/MIME 利用などが必要)
ストレージサービス

Ⅱ～Ⅳ(ファイル共有など)

公開を前提としていないため、漏えい等による影響

一般：レベル＝２

は、Ⅱ以上。どの重要度かはストレージ格納データの管理：レベル≧２

内容による。(※機密性１と２以上は論理的に分ける必
要あり)
SNS

ⅠかⅡ

データが公開される場合もある。サービスの特徴から

一般：レベル≧１

機密を保持すべきデータが置かれることはないと考えられる。公開を前提としていない利用の場合には、Ⅱに該当する。
グループウェア

Ⅱ～Ⅳ

公開を前提としていないため、漏えい等による影響

一般：レベル＝２

は、Ⅱ以上。どの重要度かは置かれたデータの内容

管理：レベル≧２による。厳重に機密を保持すべき内容のデータが置かれることはないと考えられるが、ないとも言えない。
(※機密性２以上の情報はアクセス制限が必要な場合
有)
学生共通ポータル

Ⅲ～Ⅳ

学生にとって重要なサービスを集約したサイト、入り口

一般：レベル＝２

でしかなく機密性の高い情報は無いが、停止した場合の影響は非常に大きい。
認証局＆登録局

Ⅳ

認証データベース

Ⅳ

認証強度を高めるために、電子証明書を登録、発行、管理：レベル≧３

失効情報を格納しているシステム。
＆認証システム
遠隔会議システム

全学の認証に必要なデータを保持しているデータベ

管理：レベル≧３

ースとそれらの関連システム。極めて重要。
Ⅱ～Ⅳ

Polycom 等学外との多地点遠隔会議で利用するシス

一般：レベル＝２

テム。会議内容の重要度に依存する？重要な会議では使用しない等のルールが必要
学内クラウド(IaaS)

Ⅱ～Ⅳ

部局や研究室に VM リソースを貸し出しているシステム

一般：レベル＝２

で、その重要度はサービスに依存する。公開を前提と管理：レベル≧２

しないデータがあるのでⅡも含まれる

140

学内クラウド(PaaS)

Ⅰ～Ⅳ

部局や研究室にホスティングしているサービスで、そ一般：レベル＝２の重要度は提供者側の意識にも依存する。サービスと管理：レベル≧２

データ内容に依存し様々な場合が考えられる。
IC カード発行システ

Ⅲ～Ⅳム

基本は学内限定情報、顔写真も含む。入退出に利用

管理：レベル≧２

されるので重要度は非常に高い。

表 Ⅲ-⑤-7 教育分野における各サービスの重要度と認証強度レベルの対応

教育
サービス

重要度

備考

認証強度

LMS/CMSⅡ

講義および自学自習の支援システムであり、講義内容

学生：レベル＝２

および履修プロセスで、機密性は低い。

教員：レベル＝２

e ポートフォリオ

Ⅲ

履修プロセスを集約しているため、個人情報に準じた

学生：レベル＝２

情報が含まれる。

教員：レベル≧２

履修登録(シラバス)

Ⅰ、Ⅲ

教育情報の公表にて公開を要求されているシラバス

学生：レベル＝２

はⅠ。学務情報システムに登録する履修情報や成績

教員：レベル≧２

情報は、学生への影響が大きい。

管理：レベル≧３

機密性の高い情報は扱わない。サービスの停止や中教員：レベル＝２

断は一過性であるが、教員と学生に迷惑をかける。

管理：レベル≧２

機密性の高い情報は扱わない。サービスの停止や中

学生：レベル＝２

断は一過性であるが、教員と学生に迷惑をかける。

教員：レベル≧２

遠隔講義システム
CALL システム

Ⅱ
Ⅱ(語学学習システム)

表 Ⅲ-⑤-8 事務分野における各サービスの重要度と認証強度レベルの対応

事務
サービス

重要度

備考

認証強度

人事給与

Ⅳ

教職員の基本データを保有しているため、個人情報管理：レベル≧３の漏えいは影響が大きいとともに、認証等の基本デー
タとなるため改ざんの影響は非常に大きい。(※部局
総務担当による入力および本部人事担当など管理者が登録・編集・削除を実施)
財務会計

Ⅳ

個人情報として寄付、委託研究、共同研究に関わる情教員：レベル≧２

報を含むとともに、会計情報の改ざんは業務に深刻な

管理：レベル≧３

影響を及ぼす(※一般教職員利用と部局・財務部の管理者が登録・編集・削除を実施)
学務情報

Ⅳ

成績情報等の守秘性の非常に高い個人情報を保有

管理：レベル≧３している(※正規生・非正規生など全ての学生情報を格納。部
局教務担当・学務部の管理者が登録・編集・削除を実
施)
就職支援

Ⅲ～Ⅳ

企業の採用情報を掲載したものから、エントリーシート

検討中作成支援等を行うものまで、提供機能によって異なる
出退勤

Ⅲ

勤務情報の改ざんは業務に影響が大きいとともに、休教員：レベル＝２

暇等の申請に守秘性の高い個人情報を含む
出張旅費申請システム

Ⅲ

業務の IT 化の一環、情報漏えいやシステムダウンは、

教員：レベル＝２

入力した教職員に迷惑をかける。

管理：レベル≧２

141

目標管理・職員人Ⅲ

職員個人を対象とした人事評価に係るシステム。

事

教員：レベル≧２
管理：レベル≧３

等評価システム
電子職員録

Ⅱ

機密性２の学内限定情報の検索システム。

一般：レベル＝２

施設予約

Ⅱ

学内施設に対する予約システム

教員：レベル＝２

ペーパーレス会議

Ⅲ

部局長会議、教授会など重要会議での利用が定着し

教員：レベル≧２

つつあり、重要情報も扱うため、重要度はⅢ。

管理：レベル≧２

ライセンスの不正利用を抑制するための、PC 内ソフト

教員：レベル＝２

ウェアを自動サーチするシステム。

管理：レベル≧２

機密性２の学内限定情報を提供するシステム

教員：レベル＝２

システム
ソフトウェアⅡ

ライセンス管理電子掲示板

Ⅱ

管理：レベル＝２
安否確認

Ⅲ

学内構成員の携帯番号や携帯メールアドレスを登録

一般：レベル＝２

させる場合、個人情報に相当するので漏えいした場

管理：レベル≧２

合、重大な影響あり。

表 Ⅲ-⑤-9 コンテンツ分野における各サービスの重要度と認証強度レベルの対応

コンテンツ
サービス

重要度

備考

認証強度

図書館システム

Ⅰ～Ⅱ

公開を前提としていないデータを含むが、漏えい・改一般：レベル＝１

ざん等による影響は大きくはない。

管理：レベル＝２

データは公開を前提としているため、漏えい・改ざん

一般：レベル＝１

等による影響は小さい。

管理：レベル＝２

データは公開を前提としているため、漏えい・改ざん

一般：レベル＝１

等による影響は小さい。

レベル＝２

蔵書検索のためのシステムで、公開利用を前提として

一般：レベル＝１いるため、漏えい・改ざん等による影響は小さい。

管理：レベル＝２

検索のためのシステムで、公開利用を前提としている

一般：レベル＝１

ため、漏えい・改ざん等による影響は小さい。

管理：レベル＝２

公開を前提としているため、漏えい・改ざん等による影

一般：レベル＝１

響は小さい。

管理：レベル≧２

機関リポジトリ
その他リポジトリ
ＯＰＡＣ
その他検索システム
Ｗｅｂページ

Ⅰ
Ⅰ
Ⅰ
Ⅰ
Ⅰ～Ⅱ

CMS 脆弱性による改ざんなど情報セキュリティインシ
デントの観点からはⅡ
Ｗｅｂページ（ＣＭＳ）

Ⅰ～Ⅱ

公開を前提としているため、漏えい・改ざん等による影

一般：レベル＝１

響は小さい。

管理：レベル≧２

CMS 脆弱性による改ざんなど情報セキュリティインシ
デントの観点からはⅡ
データベース

Ⅰ～Ⅱ

公開を前提としているため、漏えい・改ざん等による影

一般：レベル＝１

響は小さい。改ざんにより、データの信頼性が損なわ

管理：レベル≧２

れることがある。
CMS 脆弱性による改ざんなど情報セキュリティインシ
デントの観点からはⅡ
動画配信
教育システムⅠ
Ⅰ

公開を前提としているため、漏えい・改ざん等による影

一般：レベル≧１

響は小さい。

管理：レベル＝２

公開を前提としているため、漏えい・改ざん等による影

一般：レベル≧１

響は小さい。

管理：レベル＝２

142

オープンコースウェ

Ⅰア
セキュリティ

Ⅰ

e-Learnming

公開を前提としているため、漏えい・改ざん等による影

一般：レベル＝１

響は小さい。

管理：レベル＝２

学内公開を前提としているため、漏えい・改ざん等によ一般：レベル＝２

る影響は小さい。外部コンテンツと学内専用コンテンツ

管理：レベル＝２あり。

表 Ⅲ-⑤-10

大学経営分野における各サービスの重要度と認証強度レベルの対応

大学経営
サービス

重要度

備考

認証強度

その他事務システムⅣ

教職員の基本データを含むため、漏えい等による影管理：レベル≧３

大学評価情報シスⅣ

響は大きい。
テム
IR データベース

教職員の業績・活動データを含むため、漏えい等の影響は大きい。

Ⅳ

教職員の業績・活動データを含むため、漏えい等の影(データウェアハウ

響は大きい。大学評価情報システムに IR（Institutionalス)

Research）データベースを含む場合が多い。

研究者総覧
データベース

管理：レベル≧３

Ⅰ～Ⅲ

管理：レベル≧３

公開情報はⅠ、教員評価を含む場合は、機密性２－３

教員：レベル＝２の情報が吹き生まれるため重要度はⅡ、Ⅲ。

管理：レベル≧２

サービスやシステムの扱う情報によって重要度(格付け)を決定し、その情報の扱いを考慮して認証強度を設定することは重要である。特に、アカデミッククラウドにおいて、各教育機関で扱うサービスやシステムは類似しており、その扱う情報も基本的には同様である。各教育機関が個々の考えで重要度や認証強度を設定すれば、クラウド提供者はそれぞれの教育機関ごとにカスタマイズや設定が必要になり、アカデミッククラウドの最大のメリットであるコスト削減効果が小さくなる。また、各教育機関が最も懸念している情報セキュリティに対して、個別のカスタマイズや設定は脆弱性を残すことにもなりかねない。
以上のことから、アカデミッククラウドの設計や運用について、扱う情報の重要度や認証強度といった基本的な部分の標準化が重要である。
B. 認証強度認証強度レベルを以下のように定義する。
レベル１：（利用者管理）利用資格が定められていること。運用単位が明らかに定められていること。
（認証方式）パスワード認証を許容すること。発行されたパスワードを安全な形で利用者に届ける方法がとられていること。

143レベル２：（利用者管理）利用資格が定められ、そのうち組織の構成員に対しては人事 DB や学務
DB と（資格喪失確認を含めて）連動して利用資格の保証がなされること。また、それ以外の人間に対しては、適切なコントロールがなされていること。
（認証方式）パスワード認証を許容すること。ただし、パスワードポリシー等により、十分複雑なパスワードが使用されていることを保証すること。
レベル３：（利用者管理）上記に加え、その検証がなされていること。特に資格の取得時に、下の学校の卒業証明、住民票その他の記録を用いて検証可能になっていること。
（認証方式）パスワードを許容せず、ワンタイムパスワードのハードトークン、または
公開鍵化証明書による認証方式を採用すること。後者の場合、ハードディスク等に格納してもよいが、パスワード等を設定して二要素認証を実現すること。
レベル４：（利用者管理）レベル３以上の利用者管理方法を行っている人事 DB や学務 DB のデータと対面による本人確認の突合を行うこと。
（認証方式）公開鍵証明書を IC カード等のハード的に保護されたデバイスに格納すること。
要件のそれぞれをまとめて以下の表を得る。
表 Ⅲ-⑤-11

利用者管理と認証方式と認証強度レベルの対応（利用者管理）
認証強度
レベル
レベル１

評価項目
利用資格を定めていること。

レベル２

上記に加え、利用資格が何らかの形で保証されていること。大学で言えば、人事の DB や学務の DB と（資格喪失確認も含めて）連動して資格確認が行われること。また、それ以外の人間に対しては、適切なコ
ントロールがなされていること。

レベル≧３

上記に加え、その検証がなされていること。特に資格の取得時に、下の学校の卒業証明、住民票その他の記録を用いて検証可能になってい
ること。

144

（認証方式）
認証強度
レベル
レベル１
レベル２

評価項目
パスワードで管理し、発行されたパスワードを安全な形で利用者に届けること。
上記に加え、パスワードポリシー等により、十分複雑なパスワードが使用されていることを保証すること。

レベル３

ワンタイムパスワードのハードトークン、または公開鍵か証明書による認証方式を採用すること。後者の場合、HD 等に格納してもよいが、
パスワード等を設定して二要素認証を実現すること。

レベル４

証明書による認証方式を採用すること。ハード的に保護されたデバイスに格納すること。

これ以外の認証方式の強度も、上記要件に対応させて評価することができる。例を２つあげる。
例１）2 段階認証：パスワード認証を行った後で、さらに 2 番目のパスワード等の追加の情報を求める方式である。一般にレベル２相当であるが、tiQr 等、モバイルデバイ
スを用い、（インターネットでない）キャリア自身が運用する網を用いて十分複雑な追加情報を入力する場合は、レベル３に近い強度を持つと考えてよい。
例２）生体認証：認証強度としてはレベル４相当であると考えてよい。ただし、False
Rejection Rate (FRR)や False Acceptance Rate (FAR)を適切に設定すること、利用者管理についてはレベル 3 以上の方式を取っていることが要求される。
3.2 ID プロビジョニング
ID プロビジョニングの標準として、今後 SCIM が普及する可能性が高いと考えられ、SCIM の利用方法について検討を行った。SCIM の利用方法としては下記が考えられる。
(1) ID プロビジョニング（バルク）： 全アカウントの一斉登録、更新(1-1) SCIM の Bulk 操作を利用する。
(2) JIT プロビジョニング：利用者が利用する際の個別登録(2-1) アカウント登録、更新は SAML2.0 を利用して、削除は SCIM を利用する。
(2-2) 全てのアカウント操作に SCIM の CRUD 操作を利用する。
(2-3) SAML2.0 Binding(draft1)を利用して、全て SAML2.0 でアカウント操作を行う。
(2)では、3 つの選択肢がある。まず、(2-3)は SCIM スキーマを SAML プロトコルで利用できるが、利用者ではなく機関側からのアカウント削除等の操作を実現するには SAML
標準への機能追加等の検討項目が多く、また、複雑な機構が必要となることが懸念される。次に、(2-2)では、ログイン時のアカウント登録において SCIM の create 操作を使145

うため、既存の SAML 認証と連携させる機構が新たに必要となり、これも複雑な機構が必要となることが懸念される。最後に(2-1)について、SCIM ワーキンググループのドキュメントではないが、” SCIM Profile For Enhancing Just-In-Time Provisioning”
がインターネットドラフトとして公開されており、既存の SAML 認証を利用して必要な操作を SCIM で行うため、シンプルな機構と言える。
学認で規定する SAML 属性を SCIM プロトコルで扱うためのスキーマ拡張を以下に定義する。
SCIM コアスキーマの値：
id： externalId を元に SP が SP 内で生成する。
SP は externalId のスコープを解釈して SP 内でユニークな id を生成する。
externalId： eduPersonTargetedID or eduPersonPrincipalName
機関内でのユニーク性を保証する値とする。
SAML 属性の SCIM 属性へのマッピング：
SAML 属性

SCIM 属性

備考

mailemails<SCIM User>sn

name:familyName<SCIM User>oorganization<SCIM Enterprise>oudivision<SCIM Enterprise>givenName

name:givenName<SCIM User>

displayName

displayName<SCIM User>

eduPersonAffiliation

eduPersonAffiliation＜新規＞

eduPersonPrincipaName

eduPersonPrincipaName＜新規＞

eduPersonEntitlement

eduPersonEntitlement＜新規＞

eduPersonScopedAffiiation

eduPersonScopedAffiiation＜新規＞

eduPersonTargetedID

eduPersonTargetedID

＜新規＞

jasn

jasn

＜新規＞

jaGivenName

jaGivenName＜新規＞

jaDisplayName

jaDisplayName

＜新規＞

jao

jao

＜新規＞

jaou

jaou

＜新規＞

gakuninscopedPersonalUniq

gakuninscopedPersonalUniq＜新規＞

ueCodeueCode146以下では、拡張したスキーマを使った例を示す。
Bulk 操作による新規アカウント生成の例：
Bulk 操作による新規アカウント生成の要求例
POST /v1/Bulk
Host: sp.sample.ac.jp
Accept: application/json
Authorization: Bearer h90dUk23lsLo
Content-Length: …
{"schemas":["urn:scim:schemas:core:1.0"],"failOnErrors":1,"Operations":[{"method":"POST","path":"/Users","bulkId":"+Lxxl7QLnCkaKguy5xjNLRBkdDc=","data":{"schemas":["urn:scim:schemas:core:1.0","urn:xxx:schemas:extension:1.0"],"eduPersonTargetedID":"https://idp.sample.ac.jp/idp/shibboleth!\https://sp.sample.ac.jp/shibboleth-sp!+Lxxl7QLnCkaKguy5xjNLRBkdDc=""dispayName":"Ninsho Taro"}},{"method":"POST","path":"/Users","bulkId":"m3OD83lsdIDq109OIUdwu83ld0K=","data":{"schemas":["urn:scim:schemas:core:1.0","urn:xxx:schemas:extension:1.0"],"eduPersonTargetedID":"https://idp.sample.ac.jp/idp/shibboleth!\https://sp.sample.ac.jp/shibboleth-sp!m3OD83lsdIDq109OIUdwu83ld0K=""dispayName":"Ninsho Jiro"
}
},
}

147

Bulk 操作による新規アカウント生成の応答例
HTTP/1.1 200 OK
Content-Type: application/json{"schemas": ["urn:scim:schemas:core:1.0"],"Operations": [{"location":"https://sp.sample.ac.jp/v1/Users/+Lxxl7QLnCkaKguy5xjNLRBkd\
Dc=","method": "POST","bulkId": "+Lxxl7QLnCkaKguy5xjNLRBkdDc=","version": "W\/\"eI3i9mw02iEjOWkF\"","status": {"code": "201"}},{"location":"https://sp.sample.ac.jp/v1/Users/m3OD83lsdIDq109OIUdwu83ld\
0K=","method": "POST","bulkId": "m3OD83lsdIDq109OIUdwu83ld0K=","version": "W\/\"uDL9w2in89wqSpkW9\"","status": {"code": "201"}}}
SAML2.0 の JIT プロビジョニングにより生成されたアカウントを削除する例：
アカウント削除の要求例
DELETE /Users/+Lxxl7QLnCkaKguy5xjNLRBkdDc=
Host: example.com
Authorization: Bearer h90dUk23lsL8
If-Match: W/"e180ee84f0671b7"
アカウント削除の応答例
HTTP/1.1 200 OK
以上、SCIM による ID プロビジョニングの標準化の方向性を示したが、実際にこれを利用、普及するには、下記を行う必要がある。
 SCIM で定義されていない、セキュリティ、ポリシーの検討
 実装方法の検討と性能評価

148

3.3 冗長化
表 Ⅲ-⑤-12 に認証システムの冗長化と認証セッション同期システムを組み合わせた
ときの総合比較を示す。表に示す同期ソフトウェアは、認証セッション同期のためのプ
ラグインソフトウェアで、ソフトウェアの名前は repcached である。表 Ⅲ-⑤-12 パタ
ーン a、b は、サーバ負荷分散装置を単一拠点に導入した場合であり、地理的な障害には弱いが単一拠点で安定した認証システム(IdP)を運用するためには有用であり、機器の導入費用も 150 万円程度である。
パターン c は、DNS ラウンドロビン(RR-DNS)方式と認証セッション同期システムを組みたものであり、自己機関の決定のみで導入が可能であり、複数拠点に対応している。
同期ソフトウェアの導入が必須であるため、若干の SE 作業費用が発生する。パターン
d は、他の機関が導入した GSLB 装置を借用する方式(JuGSLB)であり、認証セッション
同期システムも導入しないため、自己機関としての費用負担は 0 円である。パターン e
は、パターン d と同様に他の機関が導入した GSLB 装置を借用し、認証セッション同期システムを導入し、再認証ログインが発生しない。導入費用は、同期ソフトの導入に関わる SE 作業費用が数十万円程度であろう。パターン f、g は、GSLB 装置を自己組織で導入し、認証セッション同期システムを導入しない場合と導入した場合である。GSLB装置の導入費用が 1,000 万円程度となり、一機関として導入するには高額であり，共同利用が妥当であろう。
まず、単一拠点または複数拠点のどちらを選択するかを検討する。単一拠点の場合、
DNS-RR または SLB 装置を使用して冗長化するのが良い。認証セッションの同期プラグ
インソフトウェアは、DNS-RR 方式では必須である。一方、SLB 装置を使用する場合は、
100 日に一回程度の障害迂回であるため不要である。複数拠点の場合は、費用面を考慮
すると DNS-RR 方式を採用し、認証セッションの同期プラグインソフトウェアを導入するのが望ましい。
複数拠点に対応した GSLB 方式は、導入費用が高額になり一組織としての導入は困難である。しかし、優先準備によるサーバプライオリティ制御ができるため、認証セッシ
ョン同期システムは、100 日に一回程度の障害迂回であるため不要だと考えられる。また、GSLB 方式の場合、10 機関程度が共同利用または共同調達することで、１機関あた
り 100 万円となる。GSLB 方式は、優先順位接続もできるので、認証セッション同期シ
ステムの導入が不要である。すなわち、10 機関以上が協力した JuGSLB 方式であれば、複数拠点に IdP を設置して、IdP の地理的負荷分散を安価に実現できる。

149

表 Ⅲ-⑤-12

パタ
ーン

4

冗長化方式と認証セッション同期システムを組み合わせたときの総合比較

認証セッショ
冗長化方式

ン
同期システム

a

SLB

なし

b

SLB

あり

c

RR-DNS

必須d

JuGSLBなしe

JuGSLB

あり

f

GSLB

なし

g

GSLB

あり

再ログイ
4

ン

発生する
発生しな
い
発生しな
い
発生する
発生しな
い
発生する
発生しな
い

同期ソフト

費用

SE 作業費用

複数拠点

150 万円0 円 非対応

150 万円

数十万円 非対応

0円

数十万円 対応0円

0 円 対応0円

数十万円 対応

1000 万円

0 円 対応1000 万円

数十万円 対応

再ログインとは，IdP サーバは障害迂回のために切り替わっときに発生する，発生確率は 100～200 日に１回であり，サーバや回線が安定している場合には利用者への影響は小さい．

150

⑥ データプライバシーに係るアカデミッククラウドシステムの調査検討（概要）本業務を開始するにあたって、キックオフシンポジウムの準備を進めるとともに、事業スケジュールの詳細化や他分野との詳細な調整を実施した。大規模アンケート調査に関しては、アカデミッククラウドにおけるデータプライバシー保護に関する要求要件を検討する上で必要となるアンケートの質問項目の検討を実施した。個人
情報保護のためのリスクマネージメント上の検討事項を精査し、その中でも特に実施・運用体制など、より実務的な観点の質問を設定した。大学ICT推進協議会年次大会における中間報告会に向けて、全体的な傾向に関する集計作業を行い、中間報告資料を作成した。その後、機関区別ごとの特徴などの詳細集計を行い、結果の分析・考察を行った。文献、法律・法例、調査レポート等の資料や、政府関連機関の検討報告
書、インターネットにより収集した情報などを元に、我が国における個人情報保護の特徴や課題点、海外主要国、諸機関との違い、個人情報保護実施の際に必要とされるアプローチなどに関する調査を行った。アンケート集計結果や、国内外の動向調査から導き出される、アカデミッククラウドにおいて考慮すべき個人情報保護の実施のために遵守すべき事項をまとめた。最終報告書の構成を全体で調整したうえで、上記の業務成果としてのデータプライバシー分野の報告書をまとめた。
1.アンケート調査結果
アカデミッククラウドにおけるデータの利活用促進を進めるうえで、プライバシー
保護、すなわち、個人情報保護は非常に重要な要件と考えられるが、その重要性は、ア
カデミッククラウドであるからということではなく、そもそも、個人情報を扱う以上、必ず考慮しなくてはならない事項である。
図 Ⅲ-⑥-1 は、個人情報保護のためのマネジメントシステムのサイクルを表したも
のである。
継続的改善

ACT
個人情報保護方針

代表者による見直し

計

監査

CHECK

画
PLAN

実施及び運用DO

図 Ⅲ-⑥-1 個人情報保護マネジメントシステムの基本モデル

151

個人情報保護マネジメントシステムモデルにおいては、「個人情報保護方針」が最も基本となり、これを制定するところからすべてが始まるといえる。それぞれの機関が定める「個人情報保護方針」に基づいて、「個人情報計画」が策定され、計画に基づいて
個人情報保護が、「実施・運用」される。さらに、方針や計画に基づいて個人情報保護が適切に実施されているかを定期的に「監査」し、必要に応じて「見直し」を行い、さらなる「改善」につなげていくという、ＰＤＣＡサイクル（PLAN－DO－CHECK－ACT というフロー）によって、個人情報保護が実現していくことが望ましい。
また、個人情報保護を実現していく上において、基本となる事項がいくつか挙げられる。
a) 事業者が行う措置の対外的明確化b) 責任体制の確保
c) 従業者の啓発
我が国の高等教育機関、研究機関において、アカデミッククラウドにおけるデータの利活用を図っていく上で、各機関における個人情報保護の実情、特に、リスクマネージメ
ントの観点から必要とされる措置の対応状況を把握するため、下記の項目に関するアン
ケートを実施した。
・個人情報保護方針の整備状況とそこに盛り込まれている内容
・個人情報保護のための組織・体制の整備状況
・個人情報保護のための手続き、手順の整備状況
・個人情報保護のための教育・訓練・監査の実施状況
・委託、第三者提供、共同利用のための手続きの整備状況
・個人情報を扱うシステムのクラウドサービスでの利用状況
以下に、アンケート回答結果の概要を記す。
1-1.個人情報保護方針の整備状況
図 Ⅲ-⑥-2 は、機関全体としての個人情報保護方針の作成状況について確認したものである。全体として８割以上の機関が、個人情報保護方針を作成していることがわかる。公立大学や研究機関で、やや比率が低くなっているが、これは、その機関としては作成していないが、上位機関（公立大学においては自治体、研究機関では機構本部など）の定める個人情報保護方針に従っている、という回答をしている機関があったことによるものであり、「まったく個人情報保護方針を作成していない」という機関は、かなり
少ない。
152

図 Ⅲ-⑥-2 個人情報保護方針の作成状況

また、作成された個人情報保護方針は、内外に広く周知されなくてはいけないとされている。図 Ⅲ-⑥-3 は、個人情報保護方針の周知状況を示したものである。個人情報保護方針を作成している機関は、高い比率で内外への周知もしていることがわかった。

図 Ⅲ-⑥-3 個人情報保護方針を周知している比率

また、個人情報保護方針に含まれるべきとされているいくつかの事項について、それぞれの機関の方針に言及があるかどうかを確認してみたが、「対象となる個人情報が定義されていない（14.6%）」「個人情報保護に関する問い合わせ窓口がない(23.6%)」など、
やや記載内容に不足が見られる例もあった。こうした、記載内容の不足については、国153

立・私立などの機関種別ごとの違いによる傾向が見られた。
1-2.個人情報保護のための組織･体制の整備状況
次に、個人情報保護のための責任体制や緊急時の対応体制についての回答結果を記す。
個人情報保護に対して、責任を持つものとして、「個人情報を扱う情報システムの管理責任者」や「個人情報を実際に利用する側であるユーザ部門における個人情報保護管理責任者」の双方をしっかり定めることが、適切な個人情報保護管理のためには必要である。
図 Ⅲ-⑥-4 は、個人情報を扱いうる情報システムの運用管理責任者の設置関する質問の回答状況である。「情報システム」と一口に言っても、全学的に使うものや、部局単位で使うものなど、様々なものがあるため、一部定められていない部署も存在している
ものの、それを含めると 85％近くの機関が、運用管理責任者を定めている、と回答している。
「各ユーザ部門における個人情報保護管理責任者の設置」についての設問では、こちら
も一部の部署・部門で定められていないものがある、という回答を含めて、77％の機関
が個人情報保護管理責任者を定めていると回答しているが、情報システムの運用管理責
任者の設置に比べると、比率がやや低くなっており、組織で個人情報を利用する際のリ
スクマネージメントの強化が望まれる。

図 Ⅲ-⑥-4 情報システム運用管理責任者の設置状況

154図 Ⅲ-⑥-5 ユーザ部門の個人情報責任者の設置状況

個人情報保護のリスクマネージメントの観点からは、個人情報保護体制と、情報セキュ
リティ管理体制という両軸がしっかりと整っていることが望ましいが、「情報セキュリ
ティのための組織」の設置についてみてみると、運用管理責任者に比して、やや低い傾向がある。
緊急時の対応体制の整備については、国立大学や高専における比率は非常に高くなっているものの、それ以外の機関での整備状況が低く、全体でも６割程度にとどまってしまっている。
こうした、組織・体制の整備状況の機関別の差異を見ると、比較的、国立大学において、体制整備が進んでいる傾向が見られる。
1-3.個人情報取得のための手続き、手順の整備状況
個人情報を収集するための適切な手続き、手順についての整備状況は、運用責任体制の整備に比べるとやや低い比率となっている。組織の整備だけでなく、実運用上の手続
き・手順の整備強化が望まれる。

155

図 Ⅲ-⑥-6 利用目的の特定のための手続きの整備状況

図 Ⅲ-⑥-7 適正な個人情報取得のための手続きの定め

1-4.個人情報保護のための監査、教育・訓練の実施
次に、個人情報保護が適正に行われているかどうか、すなわち、個人情報マネジメントの PDCA サイクルの C（チェック）の実施状況に関する回答について記す。
図 Ⅲ-⑥-8 は、個人情報保護のための監査の実施状況を示したものである。国立大学
や研究機関では、高い率で監査が実施されているものの、ほかの種別の機関では、監査はあまり実施されていないことがわかる。
また、図 Ⅲ-⑥-9 は、個人情報取扱責任者に対する継続的な教育・訓練の実施状況を、
図 Ⅲ-⑥-10 は、情報システム部門に対する個人情報保護の継続的な教育・訓練の実施状況を示している。監査と同様に、国立の機関では高い割合で実施されているが、それ以外の機関での実施率が低く、継続的な個人情報の見直し体制が不足しており、継続的な啓蒙活動や、チェック機能の強化が望まれる。

156

図 Ⅲ-⑥-8 個人情報保護に対する監査の実施状況

図 Ⅲ-⑥-9 個人情報取扱責任者への教育・訓練の実施状況

1-5. 委託・第三者提供、共同利用のための手続きの整備状況
個人情報の学外への提供、利用に関するアンケートに関する回答結果を示す。

図 Ⅲ-⑥-10

個人情報の委託先への提供状況

図 Ⅲ-⑥-10 に示されているように、大学や高等教育機関におけるアウトソーシングが進む流れを受けて、多くの機関において、業務委託先への個人情報の提供が行われてい157る。委託先に個人情報を預けた場合に、委託先も監督することが重要となるが、その実施率は７割弱であった（図 Ⅲ-⑥-11）。

図 Ⅲ-⑥-11

個人情報の委託先に対する監督の実施状況

図 Ⅲ-⑥-12 と図 Ⅲ-⑥-13 は、第三者提供に関する回答結果である。個人情報の第三者提供をする場合、本人の同意確認は比較的しっかりと行われているが、本人が第三者提供を拒否したい場合のオプトアウト措置が用意されていないケースも少なからずみられる。

図 Ⅲ-⑥-12

第三者提供をする場合の事前の本人同意の取得状況

また、図 Ⅲ-⑥-14 は、研究活動などにおいて、データを共同利用する際の手続きの整備状況に関する回答を示している。共同利用をする際には、
 共同で利用される個人情報の項目
 共同利用者の範囲、
 共同で利用する者の利用目的、
 共同で利用する者のうち、個人情報の管理について責任を有する者の氏名又は名称などの法定事項を本人に通知・公表することとされているが、この点については、機関158

の別を問わず、まだ整備が遅れている状況である。アカデミッククラウドで想定される、インタークラウドのような環境での利用への対応は今後の課題と考えられる。

図 Ⅲ-⑥-13

図 Ⅲ-⑥-14

第三者提供に対するオプトアウト措置の提供状況

共同利用の際の法定事項の本人通知の手順の整備状況

1-6.個人情報を扱うシステムのクラウド利用の状況
図 Ⅲ-⑥-15 は、個人情報を扱いうるシステムについて、実際にクラウドサービスを利用しているかという回答結果である。クラウドサービス利用を行っている機関は、３割弱程度にとどまっていることがわかる。
具体的なシステムの例としては、「電子メール」が圧倒的であり、そのほか、「グループウェア、ポータル」「図書館システム」などが続き、一部「教務システム」という回答もあった。
個人情報とクラウドサービスの利用について、自由記入の形式でいくつかコメントが寄せられた。コメントは、大きく４つのポイントにまとめられると考えられる。以下に、代表的な意見を記す。
(1)個人情報保護の重要性
159

 「情報漏えいが最も気になるところなので、情報セキュリティ対策を万全にすることが望まれる。
」
 「クラウドサービスの場合、個人情報は特に厳格に取り扱ってほしい」(2)クラウドサービスのサービスの安全対策
 「クラウド設備にて、個人情報を暗号化したまま蓄積・利用できる仕組みを希望しています。
」(3)ガイドラインへの期待 「データの機密性、個人情報の保護等、クラウドシステム構築の在り方に係る規程を把握し検討したい。」
 「個人情報を保持するシステムを学外の他のシステムにオンライン結合（電磁的結合）する場合、個人情報保護条例の制約がありハードルが高いと考えます。
」(4)国際化対応
 「個人情報保護に関して日本国の国内法規に準拠したクラウドサービスが必要である」
 「現状では、クラウドの特性および係争時の対応上、日本国内にデータがあることが担保され、かつ日本国内法で対応してくれる事業者に依頼せざるを得ない。
」

図 Ⅲ-⑥-15

個人情報を扱うシステムのクラウドサービス利用状況

個人情報とクラウドに関する上述のようなコメントを見る限り、クラウド利用についてセキュリティ面での不安を抱いていることが読み取れるが、それは具体的な事項に関するものではなく、漠然とした不安・不信に起因しているものと想定される。こうした、不安・不信を払拭するためにも、・暗号化など、情報の秘匿性に関する適正な技術対策
・障害や災害などに備えるバックアップの取得などの適正な運用対策
160

・クラウド利用時の個人情報保護に関する適正なガイドラインの作成などが望まれているといえよう。
2. 検討結果
2-1.情報のセキュリティについて
情報管理に関する法規は、情報の取扱全般に渡って様々な法律が適用されるが、社会に存在する組織は、これら様々な情報の管理が重要な課題となっている。一般に、そのための対策を情報セキュリティ対策という。
情報セキュリティ対策は、情報の漏えいや不正利用を防止する上で欠かすことができない対策であり、従業者の故意によって漏洩等が発生することを防止するだけでなく、過失やシステム的な問題が要因となって発生する事案にも対応することが求められている。
その一方で、情報セキュリティ対策は、事業規模などから講ずることができるレベル
が千差万別であり、事業内容に応じてとるべき対応も異なる。よって、一律に一定の法規制を行うことがなじまない領域でもある。
そのため、関連法規としては、個人情報保護法において個人情報取扱事業者が取り扱う個人データの安全管理措置が義務づけられているのをはじめとして、情報の不正利用については、不正競争防止法や知的財産関係の各法令に基づいて対応することとなる。
具体的に、情報の漏えいや不正利用の防止に適用される法律としては、以下の法令があげられる。
ＩＤやパスワードなどでアクセスが制御されているネットワークに接続されているパソコンに、他人の識別符合を用いたり、セキュリティホールを攻撃するなどして不正にアクセスをすると、「不正アクセス行為の禁止等に関する法律（平成 11 年法律第 128号）」に基づいて処罰の対象となる。ただし、本法は、電気通信回線を通じて行われる行為に適用されにすぎず、また、情報の漏えいや不正取得に対して適用されるものではない。よって、無線 LAN を通じて行われる不正アクセスは本法の適用対象とはならず、
アクセスポイントが SSID と WEP のパスワードで暗号化されている場合に、暗号通信の内容を復号して情報内容を知得する行為については、電波法に基づいて暗号通信復元罪として処罰の対象となっている。
続いて、ネットワーク上における本人確認と情報内容の改ざん防止については、「電子署名及び認証業務に関する法律（平成 12 年法律第 102 号）」が適用される。
その他、情報セキュリティ確保のためには様々な基準が策定されている。例えば、システムが適切に稼働しているか否かを監査する際には、「システム監査基準（平成 16 年
10 月公表）」、セキュリティホールの原因となるソフトウェア等の脆弱性については、「ソ161

フトウェア等脆弱性関連情報取扱基準（平成 16 年経済産業省告示第 235 号）」などがある。
2-2. 情報セキュリティ確保のための安全管理措置の内容
情報管理のための技術的安全管理措置には、様々な措置が考えられるが、経済産業分
野における個人情報保護法ガイドラインが定める技術的安全管理措置の内容を参考にすると、以下の事項が含まれる。
(1)情報へのアクセスにおける識別と認証(2)情報へのアクセス制御(3)情報へのアクセス権限の管理(4)情報のアクセスの記録(5)情報を取り扱う情報システムに対する不正ソフトウェア対策(6)情報の移送・通信時の対策(7)情報を取り扱う情報システムの動作確認時の対策(8)情報を取り扱う情報システムの監視(1)情報へのアクセスにおける識別と認証を行う上で望まれる事項としては、情報に対する正当なアクセスであることを確認するためにアクセス権限を有する従業者本人であることの識別と認証（例えば、ID とパスワードによる認証、生体認証等）の実施、
情報へのアクセス権限を有する各従業者が使用できる端末又はアドレス等の識別と認証（例えば、MAC アドレス認証、IP アドレス認証等）の実施があげられる。
(2)情報へのアクセス制御を行う上で望まれる事項については、情報へのアクセス権限を付与すべき従業者数の最小化、識別に基づいたアクセス制御、従業者に付与するア
クセス権限の最少化、情報を格納した情報システムへの同時利用者数の制限、情報を格納した情報システムの利用時間の制限、情報を格納した情報システムへの無権限アクセ
スからの保護（例えば、ファイアウォール、ルータ等の設定）、情報にアクセス可能なアプリケーションの無権限利用の防止（例えば、アプリケーションシステムに認証シス
テムを実装する、業務上必要となる従業者が利用するコンピュータのみに必要なアプリ
ケーションシステムをインストールする、業務上必要な機能のみメニューに表示させる
等）などがあげられる。
(3)情報へのアクセス権限の管理を行う上で望まれる事項としては、情報にアクセスできる者を許可する権限管理の適切な実施、情報を取り扱う情報システムへの必要最小限のアクセス制御の実施などがあげられる。
(4)情報へのアクセスの記録を行う上で望まれる事項としては、情報へのアクセスや操作の成功と失敗の記録、採取した記録の漏えい、滅失及びき損からの適切な保護など
162

があげられる。
(5)情報を取り扱う情報システムに対する不正ソフトウェア対策の実施の上で望まれる事項としては、ウイルス対策ソフトウェアの導入、オペレーティングシステム（ＯＳ）、
アプリケーション等に対するセキュリティ対策用修正ソフトウェア（いわゆる、セキュ
リティパッチ）の適用、不正ソフトウェア対策の有効性・安定性の確認（例えば、パターンファイルや修正ソフトウェアの更新の確認）などがあげられる。
(6)情報の移送（運搬、郵送、宅配便等）
・通信時の対策の上で望まれる事項としては、移送時における紛失・盗難した際の対策（例えば、媒体に保管されている情報の暗号化）、盗聴される可能性のあるネットワーク（例えば、インターネットや無線ＬＡＮ等）で情報を通信する際の、情報の暗号化などがあげられる。
(7)情報を取り扱う情報システムの動作確認時の対策の上で望まれる事項としては、
情報システムの動作確認時のテストデータとして情報を利用することの禁止、情報シス
テムの変更時に、それらの変更によって情報システム又は運用環境のセキュリティが損なわれないことの検証などがあげられる。
(8)情報を取り扱う情報システムの監視を行う上で望まれる事項としては、情報を取り扱う情報システムの使用状況の監視、情報へのアクセス状況（操作内容も含む）の監視などがあげられる。
2-3.個人情報の保護
2-3-1. 個人情報保護制度
個人情報の保護を目的とした我が国の「個人情報保護制度」は、法律の義務規定の適用範囲が、民間部門と公的部門では異なる。
民間部門を対象にした法律は「個人情報の保護に関する法律（平成１５年５月３０日
法律第５７号)」が制定され、一般に「個人情報保護法」と呼ばれている。公的部門については、行政機関と独立行政法人等を対象にした個人情報保護法として、「行政機関の保有する個人情報の保護に関する法律（平成１５年５月３０日法律第５８号）」および「独立行政法人等の保有する個人情報の保護に関する法律（平成１５年５月３０日法
律第５９号）」が制定されている。
2-3-2. 民間部門を対象にした個人情報保護法
個人情報保護法の義務規定の適用を受けるのは、紙又はコンピュータで処理された個
人情報が体系的に検索可能な状態になっている「個人情報データベース等」を事業の用に供している者である。ただし、個人情報データベース等を構成する個人情報によって識別される特定の個人の数が５０００に満たない場合は個人情報取扱事業者の義務が課されない。
163

2-3-3. 定義規定
個人情報保護法は、義務規定の適用が「個人情報」、「個人データ」、及び「保有個人データ」で重層的に適用される仕組みをとっている。そのため、保有個人データを取り扱っている場合には、義務規定がすべて適用され、反面、個人情報のみを取り扱っている場合には、個人情報に関する義務のみが適用される。
「個人情報」とは、「生存する個人に関する情報」であって、特定の個人を識別できる「個人識別性」があるものに限られる。
「個人データ」とは、個人情報データベース等を構成する個人情報のことをいう。
「保有個人データ」とは、個人情報取扱事業者が、開示、内容の訂正、追加又は削除、
利用の停止、消去及び第三者への提供の停止を行うことのできる権限を有する個人デー
タであって、その存否が明らかになることにより公益その他の利益が害されるものとして政令で定めるもの、または６ヶ月以内に消去することとなるもの以外のものをいう。
2-3-4. 個人情報取扱事業者の義務
2-3-4.1. 利用目的の特定
個人情報を取り扱うにあたっては、利用目的をできる限り特定することが義務づけられている。具体的に、どの程度特定するのかは、その利用方法によって個別に検討することになる。ただし、法令に基づく場合、人の生命または財産といったような具体的な権利利益が侵害されるおそれがある場合、公衆衛生の向上や児童の健全な育成のために特に必要な場合、法令に基づく公的事務への協力の四つの適用除外が定められている。
2-3-4.2. 個人情報の取得関係
個人情報を取得するにあたっては、偽りその他不正の手段により個人情報を取得してはならず、個人情報を適正な方法によって取得することが義務づけられている。例えば、
不正競争防止法に抵触するような形で、不正に顧客名簿等を取得することがこれに該当する。
個人情報を取得するにあたっては、直接本人から取得する場合には利用目的を明示し、間接的に取得したときは利用目的を通知・公表しなければならない。
2-3-4.3. 安全管理、従業者・委託先の監督

164

個人情報取扱事業者は個人データを安全に管理する義務を負う。個人情報の漏えいや不正利用に関する事件は後を絶たず、その多くは安全管理面で問題があることが多いといえる。
安全管理にあたって遵守すべき義務は、安全管理と従業者の監督、委託先の監督の３点である。
2-3-4.4. 第三者提供の制限
第三者提供の制限とは、あらかじめ本人の同意を得ないで、個人データを第三者に提供してはならないという原則のことをいう。よって、第三者提供にあたっては、原則本人同意が必要となる。
ただし、委託先への提供、合併等に伴う提供、共同利用はこれに該当しない。
なお、本人同意を取得できない場合は、第三者に提供する個人データを、本人の求めに応じて第三者提供を停止する「オプトアウト」に応ずる手続きを定めていれば提供することが可能である。
2-3-4.5. 保有個人データの取扱い「保有個人データ」を保有している場合には、保有個人データに関する事項の公表と、本人からの開示、訂正、利用停止等の申出（本人関与）に応ずる義務が生じる。
公表事項は、個人情報取扱事業者の氏名又は名称、保有個人データの利用目的である。
その他、本人の求めに応じる手続及び保有個人データの利用目的の通知、保有個人データの開示に係る手続や、手数料を定めた場合は、その額と、苦情の受付窓口の所在などを公表することになる。
2-3-4.6. 本人の関与
保有個人データを保有している場合は、本人から利用目的の通知を求められた場合は、原則通知しなければならない。また、開示、訂正等、利用停止等の申出にも応ずる義務が生じる。ただし、利用停止等に応ずる義務は、「目的外利用」、「不正取得」または「第三者への無断提供」のいずれかの手続違反に該当する場合に限られる。
2-3-4.7.実効性の担保
個人情報の取扱いにあたって問題が生じた場合は、主務大臣からの報告の徴収、助言、勧告及び命令が行われ、その命令に従わないときは罰則が科される。
165

2-4. プライバシー・バイ・デザイン（PbD）によるプライバシー保護への取り組み
PbD とは、プライバシー保護を目的として利用される技術及び対策を、システム設計及びその構築段階から検討・実装し、ライフサイクル全般において体系的かつ継続的に取り組む仕組みである。
その内容は、公正な情報処理（FIPS：Fair Information Practices）を達成するために、プライバシー保護のための取り組みを計画し、それを計画的に実施する上で必要な７つの基本原則と６つのプロセスから構成される。

【PbD の７つの基本原則】
1. リアクティブ（事後）でなくプロアクティブ（事前）；事後の措置でなく事前に予防
2. デフォルト設定でプライバシー保護
3. 設計時に組み込むプライバシー対策
4. すべての機能に対して－ゼロサムではなくポジティブサム
5. エンドツーエンドのセキュリティ；ライフサイクル全体の保護
6. 可視化と透明性；オープンにする
7. 個人のプライバシー尊重；個人を主体に考える
法的な観点からのプライバシー保護への取り組みは、プライバシーの権利侵害に対する事後的な救済が主たる対応となってきた。判例においてはプライバシー侵害に対する不法行為責任を問う事例が一般的であり、法令においても、個人情報保護法は個人情報取扱事業者の義務に違反した場合の制裁を、事後的な対応として主務大臣の権限行使という形で定めているにすぎない。
そこで、事後的な対応にとどまらない個人情報の適正な取扱いと保護を達成するため、企業はリスクマネージメントの観点からマネジメントシステムなどを活用することで事前に必要な対策を講じてきた。
PbD も同様の観点から、(1)「リアクティブ（事後）でなくプロアクティブ（事前）；事後の措置でなく事前に予防」という原則により、事後的な対応ではなく事前対応によってプライバシー侵害が発生する前に、プライバシーへのリスクが発生することを予防することを目的としている。
(2)「デフォルト設定でプライバシー保護」という原則は、初期設定からプライバシ
166

ー保護を実施することにより、何もせずにプライバシーが保護されるようにすることが目的である。プライバシー保護のためにどのような技術を利用することができるのか、
また、どのように設定すれば良いのかといった事柄は、利用者のリテラシーに左右される。そこで、最初からプライバシー保護の仕組みが用意されていれば、利用者にとってプライバシー保護のための対策を考える（悩む）必要がない。それを実現するためには、(3)「設計時に組み込むプライバシー対策」として、システムの仕様を策定する段階か
らプライバシー保護対策を組み込む必要がある。
しかし、プライバシー保護のための対策を講じることは、プライバシー保護とセキュ
リティ対策の関係にみられるように、トレードオフの問題が発生する。例えば、セキュ
リティ対策を講じるために監視カメラを用いると、結果的に監視対象になる人物のプラ
イバシーが制限される問題などが典型である。この問題を解消するため、(4)ゼロサム
ではなくポジティブサムという原則を示している。
これらの取り組みは、事前に計画されるものであるが、それを計画的かつ継続して実施することが重要であることから、(5)個人情報の取扱い（ライフサイクル）全般に渡って適切な保護がなされる必要がある。さらに、どのような取り組みがなされているのか、(6)可視化と透明性を確保することで利用者の信頼を確保するとともに、取り組みの状況を明らかにすることで社会的信用を獲得することができる。
以上の取り組みは、個人情報を取り扱う側の理屈ではなく、個人（本人）の視点から適切なプライバシー保護のあり方を考えることが必要となるため、(7)個人のプライバ
シー尊重に基づいて実施されるべきという理念が最後の原則である。
2-5.

クラウドコンピューティングをめぐる諸外国の機関や団体による検討状況

諸外国の機関や諸団体によるクラウドコンピューティング関連の基準・規格や報告書等は様々なものが公表されている。しかしながら、クラウドの活用が始まってからの年
月が浅いことから、既存の規格に基づきつつクラウドに関する問題への対応を検討する
傾向があり、クラウドに特化した基準や報告書等はそれほど多くはない。また、クラウドの活用にあたって遵守すべき法令や基準が、国境を容易に越えて展開するクラウドコ
ンピューティングの特性ゆえに、適用される法令や手続さえ明確になっていない場合もある。つまり、国内動向だけでなく国際的な動向も注視し状況を把握することが不可欠となっている。
そこで、本章では、クラウドに関する法令や規格等に関し、策定・検討機関および組
織毎に、どのような検討がなされているのかについて整理を行いたい。
2-5-1.

経済協力開発機構（ＯＥＣＤ）

OECD におけるクラウドコンピューティングに関する問題への取り組みは、情報セキ
167ュリティおよびプライバシーに関する問題との関係にける課題として様々な検討がなされている。
2009 年 10 月 14 日開催された、「OECD/ICCP（情報通信政策委員会）技術フォアサイ
トフォーラム*5」においては、クラウドサービスの提供に伴う課題を総合的に検討している。
本フォーラムでは、クラウドベースのサービスによって見込まれるサービスのメリッ
トとデメリットに関し、１．主要概念、技術、ビジネスモデル、２．クラウドサービス：
インフラ、プラットフォーム、ソフトウェア、３．ポータビリティ、競争、イノベーシ
ョン４．セキュリティ、プライバシー、説明責任、に分けて検討が行われた。
４番目の「セキュリティ、プライバシー、説明責任」においては、クラウドサービスの提供に伴い解決しなければならない多くの課題があることが、以下の通り改めて明らかになった。
【図 Ⅲ-⑥-16 OECD/ICCP（情報通信政策委員会）技術フォアサイトフォーラムにおける検討事項】（１）クラウドプロバイダによる顧客の情報の安全管理（機密性、完全性、可用性の確保の顧客への保証）（２）監査及びデューデリジェンスの実施可能性（３）多量の重要データの蓄積とサイバー犯罪対策（４）適切な識別及びアクセスコントロール（５）無料の広告提供サービスとの連携に伴うユーザのプロファイルの販売目的での利用をめぐる問題（６）個人がクラウドベースのサービスを通してオンライン活動を行う場合のＩＤ
管理への影響（７）適用法令の決定（８）法執行機関による情報へのアクセス*5

ICCP Technology Foresight Forum - "Cloud Computing: The Next Computing

Paradigm?"<http://www.oecd.org/document/38/0,3746,en_2649_34223_43921574_1_1_1_1,00.html>(2009/10/14), 本フォーラムの資料については、OECD Cloud Computing
Forum<http://www.oecd.org/dataoecd/32/24/43921917.pdf>(2009/10/14). その後も、OECD ではワークショップを開催して検討を行っている。Internet Governance Forum2010 - OECD workshop on cloud computing - Cloud computing for leaner and greener IT
infrastructures in governments (andbusinesses)<http://www.oecd.org/dataoecd/15/50/45860581.pdf>(Vilnius, Lithuania,
14-17 September Workshop No. 106).
168

（９）クラウドによるデータ処理とデータ移転の問題（１０）データ制御やデータ処理等の法律が定める概念との関係（１１）サーバの設置場所と効率性追求に伴う問題（データの保存場所の変更に伴う地理的条件や的用法の関係における問題）（１２）サービス規約の有効性と遵守義務（１３）クラウドコンピューティングを利用する企業による監査要求への対応（１４）消費者のメリットとデメリット（消費者志向のクラウドアプリケーション
において、事業者が提供する情報に基づいて利用するサービスを選択をする際に、そのリスクや利益を理解することができるか）
2-5-2.
1)

欧州委員会「クラウドコンピューティングの将来」報告書
欧州委員会(European Commission)は、２０１０年１月２６日に専門家グループの報告書として、「クラウドコンピューティングの将来*6」を公表している。本報告書では、
EU におけるクラウドコンピューティングの活用にあたって、（１）研究および技術的発展のための対応、（２）適正な規制の枠踏みの整備（特に検討を要する事項：経済的側面、法的問題、グリーン IT）について分析を行っている。
2)「欧州におけるデジタル・アジェンダ」戦略
２０１０年５月１９日に、欧州における２０２０年までのデジタル経済に関する戦略として、「欧州におけるデジタル・アジェンダ(Digital Agenda for Europe*7)」が公表された。当該戦略における「2.5.1.活動および効率性の促進(Step up efforts andefficiency)」および「2.5.3.オープン・イノベーションのための産業界主導のイニシ
アティブ(Industry-led initiatives for open innovation)」において、欧州連合全域
における戦略として、政府機関および科学技術分野におけるクラウドコンピューティン
グ活用の推進が明記されている。

*6

Lutz Schubert, Keith Jeffery, Burkhard Neidecker, The Future of Cloud

Computing: Opportunities for European Cloud Computing Beyond 2010, European
Commission: Information Society and Media, Expert Group Report Public Version 1.0(2010)<http://cordis.europa.eu/fp7/ict/ssai/events-20100126-cloud-computing_en.html>.
*7 Communication from The Commission to The European Parliament, The Council,
The European Economic and Social Committee and The Committee of The Regions A
Digital Agenda for Europe/ Com/2010/0245
F/2<http://ec.europa.eu/information_society/digital-agenda/index_en.htm>.
169

3)

「クラウド・セキュリティ・プライバシー」報告書
２０１０年１２月には、「クラウドにおけるセキュリティおよびプライバシーに関す

る規制に関する報告書(The Cloud: Understanding the Security, Privacy and Trust
Challenges Final Report)*8」が公表されている。
本報告書は１０章から構成され、クラウドの活用にあたってのセキュリティおよびプ
ライバシーに係る諸問題を、法的側面の観点から適用法令や規則およびケーススタディ
を通じて詳細に分析を行い、今後のクラウドの活用にあたっての展望が示されている。
なお、本報告書はあくまで EU 域内における問題を扱っているが、クラウドコンピュ
ーティングは国境を超えてサービスが提供されることから、ＯＥＣＤガイドラインやＡ
ＰＥＣフレームワークが大きな影響を及ぼしている現状において、国際的な個人データ保護の枠組みでクラウド環境における個人データ保護が十分に達成されるのかは不透明であると指摘しているところは、EU 指令がクラウドサービスの提供にあたって障壁になる可能性が高いことを暗に示したものといえ興味深い。
なお、欧州委員会では、２０１２年に、クラウドコンピューティングに係る欧州連合の戦略を提示する予定となっている。
2-5-3.
1)

欧州ネットワークおよび情報セキュリティ・エージェンシー(ENISA)「クラウド・コンピューティング・リスク・アセスメント」報告書
ENISA（European Network and Information Security Agency）は、２００９年１１月２０日に、「クラウド・コンピューティング・リスク・アセスメント*9」を公表してい*8

Neil Robinson, Lorenzo Valeri, Jonathan Cave & Tony Starkey, Hans Graux, Sadie

Creese & Paul Hopkins, The Cloud: Understanding the Security, Privacy and Trust

Challenges Final Report, TR-933-EC, 30 November 2010(Prepared for Unit F.5,
Directorate-General Information Society and Media, European
Commission)<http://cordis.europa.eu/fp7/ict/security/docs/the-cloud-understanding-sec
urity-privacy-trust-challenges-2010_en.pdf>.
*9 European Network and information Security Agency (ENISA), Cloud Computing
Risk Assessment,<http://www.enisa.europa.eu/act/rm/files/deliverables/cloud-computing-risk-assessment> (Nov 20, 2009). ENISA のガイドラインについては、独立行政法人情報処理推進機構が、「欧州 ENISA のクラウドコンピューティングのセキュリティに関するガイドラインの翻訳」<http://www.ipa.go.jp/about/press/20101025_2.html>（2010 年 10 月 25 日）を公表している。また、本ガイドラインについては、原田要之肋「クラウドコンピューティングのリスクとガバナンスに関する調査・研究について」
情報処理 Vol.51 No.12 (2011)1591-1601
頁において紹介がなされている。
170

る。
ENISA の報告書では、グラウンドコンピューティングサービスを提供するにあたっては、（１）クラウドサービスを採用するにあったでのリスク評価、（２）他のクラウドプ
ロバイダが、提供するサービスとの比較、（３）選択したクラウドプロバイダの保証の取得、（４）クラウドプロバイダの保証負担の軽減、について検討することが必要であるとしている。
また、欧州評議会への法的対応の提案として、（１）個人データ保護指令との関係における問題の検討および２９条データ保護作業部会の勧告への意見、（２）データが漏えいした場合の消費者への告知義務、（３）電子商取引指令第１２条～第１５条が、クラウドプロバイダに適用される場合の媒介者の免責について提案を行っている。
クラウドコンピューティングについては、その特徴として、（１）高度に抽象化されたリソース、（２）即時的な仕組みおよび柔軟性、（３）瞬時のサービス提供、（４）リソースの共有（ハードウェア、データベース、メモリー）、（５）オンデマンドサービス、
従量制（pay as you go）の課金システム、（６）体系的な管理（例：WS API)をあげている。
クラウドコンピューティングにおけるセキュリティ上のメリットについては、（１）場所の多重化（Multiple locations）、（２）ネットワークの利点の活用(Edge networks)、（３）インシデントへの即時的な対応（Improved timeliness of response to incidents）、（４）リスクマネージメント（Threat management）にあるとしている。
これらを踏まえて、リスクアセスメントの内容として、（１）ユース・ケースのシナ
リオ、および（２）リスクアセスメントの過程について、以下の分類により詳細に検討を行っている。
【図 Ⅲ-⑥-17 ENISA 報告書「政策と組織的なリスク」】(1)定化（ロックイン）(2)管理の喪失(3)コンプライアンス対応(4)共同テナントの行為に起因する企業価
値の低下(5)クラウドサービスのサービス途絶又 (6)クラウド・プロバイダーの獲得
は失敗(7)サプライ・チェーンの失敗【図 Ⅲ-⑥-18 技術的なリスク】(8)リソースの消耗(リソース不足又は (9)非隔絶状態の喪失
その過多)(10)クラウドプロバイダ内部の悪意、管 (11)管理インターフェイスの欠陥(操作、理者特権の濫用

インフラストラクチャの可用性)(12)送受信されるデータの傍受(13)データの送受信（アップロード又はダ171ウンロード、イントラ・クラウド）におけるデータ漏洩
(14)データの不確実又は非効果的な消 (15)分散型サービス拒否攻撃(DDoS)への去対応(17)経済サービス拒否攻撃(EDOS)への (18)暗号鍵の紛失
対応(19)悪意的な探査又はスキャンの企図 (20)サービスエンジンの欠陥への対応(21)顧客定着化手続とクラウド環境間の軋轢【図 Ⅲ-⑥-19 ENISA 報告書「法的リスク」】(22)則付召喚令状召喚および電子的証 (23)裁判管轄の変更に伴うリスク
拠開示手続(24)データ保護リスク(25)ライセンスに係るリスク【図 Ⅲ-⑥-20 ENISA 報告書「クラウドに関して特定されていないリスク」】(26)ネットワークの断絶(27)ネットワーク管理(例、輻輳/誤接続/
非最適利用)(28)権限奪取（ローカルの一般ユーザに (29) ソ ー シ ャ ル エ ン ジ ニ ア リ ン グ 攻 撃root 権限を奪われる「権限の昇格」）(例：模倣)(30)操作ログの滅失又は漏洩(31)セキュリティ・ログの滅失又は漏洩(フォレンジック調査の実施）(32)バックアップの毀損、盗難(33)構内への無権限アクセス(装置やその他の施設への物理的アクセスを含む）(34)コンピュータ機器の盗難
2-5-4.
1)(35)天災クラウド・セキュリティ・アライアンス(CSA)「クラウド・セキュリティ・ガイダンス」
CSA(Cloud Security Alliance)は、２００９年４月に「クラウドコンピューティングに係る重要分野におけるセキュリティ・ガイダンス(Security Guidance for Critical172

Areas of Focus in Cloud Computing*10)」を公表し、同年１２月にその第二版も公表されている*11。
クラウド・セキュリティ・ガイダンスは、クラウドコンピューティングの管理・運用
にあたって対応が求められる事項を、以下の構成により体系的に整理したものである。
【図 Ⅲ-⑥-21 「クラウド・セキュリティ・ガイダンス」の構成】
クラウドの構造・クラウドコンピューティングの構造的フレームワーク
クラウドの管理・ガバナンスおよびエンタープライズ・リスク・マネジメント
・法的課題および電子的証拠開示手続
・コンプライアンスと監査・情報ライフサイクル・マネジメント
・ポータビリティと相互運用性
クラウドの運用・伝統的なセキュリティ、ビジネス継続性、および災害復旧
・データセンターの運用
・インシデントレスポンス、通知、および救済
・アプリケーション・セキュリティ
・暗号化と鍵管理
・アイデンティティとアクセス管理・仮想化
2)「クラウド・コントロール・マトリクス」「クラウド・コントロール・マトリクス(Cloud Controls Matrix)」は、コンプライ

アンス・マッピング（法令遵守のための取り組みにおいて参照すべき規格）として、クラウドの導入にあたっての確認事項を一覧で把握できるものとして策定されたものである。
確認事項毎に、適用範囲をサービスプロバイダと利用者に分けた上で、それぞれ SaaS、
PaaS、IaaS への適用の可否について示している。さらに、以下の規格を示しマネジメ*10See, CSA, Guidance<https://cloudsecurityalliance.org/guidance/>.ならびに、IEEE

と共同で、2010 年 3 月 1 日に、Survey by IEEE and Cloud Security Alliance Details
Importance and Urgency of Cloud Computing Security Standards<https://cloudsecurityalliance.org/pr20100301c.html>も公表されている。
*11 CSA については、勝見勉「クラウドセキュリティアライアンスとその活動について」
情報処理 Vol.51 No.12 (2011)1620-1626 頁を参照されたい。
173

ントシステム構築の観点から必要な要求事項の参照先も明示している。
【図 Ⅲ-⑥-22 「クラウド・コントロール・マトリクス」参照規格】
COBIT 4.1*12

HIPPA 164*13

ISO/IEC 27002*14

NIST SP800-53*15

PCI DSS v1.2*16

その他（GAPP, HITECH, AUP
ver.5*17)

3)「クラウドコンピューティングにおける重要な脅威」
２０１０年３月に公表された「クラウドコンピューティングにおける重要な脅威(TopThreats to Cloud Computing V1.0)」は、クラウドを活用した戦略を策定するにあたって、リスクマネージメントの観点から検討が必要な事項を決定する際に参照することを目的として策定されたものである。

*12 Control Objectives for Information and related Technology (COBIT), Version 4.1(2007)<http://www.isaca.org>. COBIT 4.1 の詳細については、本書「クラウド管理と内部統制」を参照。
*13 The Health Insurance Portability and Accountability Act of 1996 (HIPAA) Privacy
and Security Rules, 45 CFR Part 160 and Subparts A and E of Part
164<http://www.access.gpo.gov/nara/cfr/waisidx_07/45cfr164_07.html>.HIPPA については、HHS,Privacy<http://www.hhs.gov/ocr/privacy/>.
*14International Organization for Standardization (ISO) / International

Electrotechnical Commission (IEC) 27002:2005 -- Information technology -- Security
techniques -- Code of practice for Information Security Management.
*15

National Institute of Technology (NIST) Special Publication 800-53 --Recommended Security Controls for Federal Information Systems, Revision 2 (Dec
2007). SP800 とは、米国国立標準技術研究所の Special Publications(800 Series)のことをいう。NIST <http://csrc.nist.gov/publications/PubsSPs.html>.
*16 Payment Card Industry (PCI) Data Security Standard (DSS) Requirements andSecurity Assessment Procedures, Version 1.2 (Oct 2008), Payment Card Industry Data
Security Standards<https://www.pcisecuritystandards.org/>.
*17 Generally Accepted Privacy Principles(GAPP)<http://infotech.aicpa.org/Resources/Privacy/Generally+Accepted+Privacy+Prin
ciples/>, Health Information Technology for Economic and Clinical Health (HITECH)
Act passed as part of the American Recovery and Reinvestment Act of2009(ARRA)<http://www.hhs.gov/ocr/privacy/hipaa/understanding/coveredentities/guid
ance_breachnotice.html>, BITS Shared Assessments Program Agreed Upon Procedures(AUP) Version 5.0 Assessment Guide<http://www.sharedassessment>.
174重要な脅威として示されているのは、以下の脅威であるが、これらの脅威は時宜に応じてアップデートされることとなっている。
【図 Ⅲ-⑥-23 クラウドコンピューティングにおける重要な脅威】
脅威＃１

違 法・不 正な クラウ ドコ ンピュ ーテ ィング の利 用 (Abuse and
Nefarious Use of Cloud Computing)

脅威＃２

安全ではないインターフェイスおよび API(Insecure Interfaces
and APIs)

脅威＃３

従事者の悪意(Malicious Insiders)

脅威＃４

共有技術に係る問題(Shared Technology Issues)

脅威＃５

データの滅失又は漏洩(Data Loss or Leakage)

脅威＃６

ア カ ウ ン ト 又 は サ ー ビ ス の 乗 っ 取 り (Account or Service
Hijacking)脅威＃７

未知のリスクのプロファイル(Unknown Risk Profile)

3. 要求要件（標準仕様）
Ｉ アカデミッククラウドの提供・利用において必要となる要求事項の趣旨、目的、基
本的考え方
１．本要求事項の構成及び基本的考え方
アカデミッククラウド環境を構築するにあたっては、取扱いの対象となる情報に個人に関する情報が多く含まれることとなる。そのため、当該環境の構築にあたっては、個人情報の取扱いに関し、「個人情報の保護に関する法律」（平成１５年法律第５７号）（以
下、「個人情報保護法」という。）第３条において、「個人情報が、個人の人格尊重の理
念の下に慎重に取り扱われるべきものである」とされていることを踏まえ、個人情報を取り扱うすべての者は、その目的や様態を問わず、個人情報の性格と重要性を十分認識し、その適正な取扱いを図らなければならない。
「個人情報の保護に関する法律」（平成１５年法律第５７号）
第３条（基本理念）
個人情報は、個人の人格尊重の理念の下に慎重に取り扱われるべきものであることにかんがみ、その適正な取扱いが図られなければならない。
2.

本要求事項の対象となる「個人情報」の範囲
法令上「個人情報」とは、生存する個人に関する情報であり、個人情報取扱事業者の義務等の対象となるのは、生存する個人に関する情報に限定されている。
175

「個人情報の保護に関する法律」（平成１５年法律第５７号）
第２条（定義）
この法律において「個人情報」とは、生存する個人に関する情報であって、当該情報に含まれる氏名、生年月日その他の記述等により特定の個人を識別することができるもの（他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるものを含む。）をいう。
3.

責任体制の明確化
アカデミッククラウドを実施するにあたっては、個人情報の適正な取扱いを推進し、漏えい等の問題に対処する体制を整備する必要がある。このため、個人情報の取扱いに関し、個人情報を取り扱う関係者全体を統括する組織体制・責任体制を構築し、安全管理措置の計画立案等を効果的に実施できる体制を構築する必要がある。
4.

個人情報が研究に活用される場合の取扱い
個人情報保護法第５０条第１項においては、憲法上の基本的人権である「学問の自由」の保障への配慮から、大学その他の学術研究を目的とする機関等が、学術研究の用に供する目的をその全部又は一部として個人情報を取り扱う場合については、法による義務等の規定は適用しないこととされている。
従って、この場合には法が定める義務は適用されるものではないが、これらの場合においても、個人情報保護法第５０条第３項により、当該機関等は、自主的に個人情報の適正な取扱いを確保するための措置を講ずることが求められている。
アカデミッククラウド環境を構築するためのシステム研究は、大学等の研究機関を中心に実施されるものである。そのため、アカデミッククラウド環境大学その他の学術研究を目的とする機関等が個人情報を取り扱う場合、学術研究の用に供する目的において個人情報を取り扱う場合に該当する場合がある。この場合、個人情報保護法が定める個
人情報取扱事業者の義務が適用されない場合もあるため、法が定める義務を負わないことがある。しかしながら、アカデミッククラウドにおいて取り扱う情報は、個人に関する情報であって個人のプライバシーに関わる情報も多く取り扱われることから、法の義
務を負わない場合であっても、個人のプライバシー保護の観点から個人情報の適正な取扱いと保護を実施することが必要である。
Ⅱ

本要求事項で用いる用語の定義等

１.

個人情報

（個人情報保護法第２条第１項）「個人情報」とは、生存する個人に関する情報であって、当該情報に含まれる氏名、生年月日、その他の記述等により特定の個人を識別することができるもの（他の情報と176

容易に照合することができ、それにより特定の個人を識別することができることとなるものを含む。
）をいう。
「個人に関する情報」は、氏名、性別、生年月日等個人を識別する情報に限られず、個人の身体、財産、職種、肩書き等の属性に関して、事実、判断、評価を表すすべての情報であり、評価情報、公刊物等によって公にされている情報や、映像、音声による情報も含まれ、暗号化されているか否かを問わない。
なお、死者に関する情報が、同時に、遺族等の生存する個人に関する情報でもある場
合には、当該生存する個人に関する情報となる。
2.

個人情報データベース等（個人情報保護法第２条第２項）、個人データ（法第２条第４項）、保有個人データ（法第２条第５項）「個人情報データベース等」とは、特定の個人情報をコンピュータを用いて検索することができるように体系的に構成した個人情報を含む情報の集合体、又はコンピュータを用いていない場合であっても、紙面で処理した個人情報を一定の規則（例えば、五十
音順、生年月日順など）に従って整理・分類し、特定の個人情報を容易に検索することができるよう、目次、索引、符号等を付し、他人によっても容易に検索可能な状態においているものをいう。
「個人データ」とは、「個人情報データベース等」を構成する個人情報をいう。
「保有個人データ」とは、個人データのうち、個人情報取扱事業者が、開示、内容の訂正、追加又は削除、利用の停止、消去及び第三者への提供の停止を行うことのできる権限を有するものをいう。ただし、①その存否が明らかになることにより、公益その他の利益が害されるもの、②６ヶ月以内に消去する（更新することは除く。）こととなるものは除く。
アカデミッククラウドにおいて管理する個人に関する情報は、個人情報データベース
等を構成する個人情報であって、「個人データ」に該当する情報であるとともに、半年以内に消去せずに利用する情報は「保有個人データ」となる。
3.

本人の同意
個人情報保護法は、個人情報の目的外利用や個人データの第三者提供の場合には、原則として本人の同意を得ることを求めている。アカデミッククラウドにおいては、クラウド環境において適切な情報システム環境を構築し当該環境を活用したサービスを提供する目的のために、通常必要と考えられる個人情報の利用範囲を個人情報保護方針やプライバシーポリシーにおいて明らかにしておくことが必要となるとともに、第三者提供を実施する場合には原則として本人同意が必要となる。
なお、アカデミッククラウド参加組織へのアンケート調査においては、当該組織において取り扱われる個人情報について、個人情報保護方針やプライバシーポリシーを掲載し当該方針に基づいて取扱いが行われているか否かを調査した。調査結果は前述の通り
177

であるが、アカデミッククラウドを構築するにあたって定めるべき個人情報保護方針やプライバシーポリシーの内容については、次章の「アカデミッククラウド参加組織の義務等」を参考に適切なポリシー等の公表を実施されたい。
Ⅲ

アカデミッククラウド参加組織の義務等

１.

利用目的の特定等（個人情報保護法第１５条、第１６条）（利用目的の特定）
個人情報保護法第十五条 個人情報取扱事業者は、個人情報を取り扱うに当たっては、その利用の目的（以下「利用目的」という。）をできる限り特定しなければならない。
２ 個人情報取扱事業者は、利用目的を変更する場合には、変更前の利用目的と相当の関連性を有すると合理的に認められる範囲を超えて行ってはならない。
（利用目的による制限）
個人情報保護法第十六条 個人情報取扱事業者は、あらかじめ本人の同意を得な
いで、前条の規定により特定された利用目的の達成に必要な範囲を超えて、個人情報を取り扱ってはならない。
２ 個人情報取扱事業者は、合併その他の事由により他の個人情報取扱事業者から事業を承継することに伴って個人情報を取得した場合は、あらかじめ本人の同意をないで、承継前における当該個人情報の利用目的の達成に必要な範囲を超えて、当該個人情報を取り扱ってはならない。
３ 前二項の規定は、次に掲げる場合については、適用しない。
一 法令に基づく場合
二 人の生命、身体又は財産の保護のために必要がある場合であって、本人の同意を得ることが困難であるとき。
三 公衆衛生の向上又は児童の健全な育成の推進のために特に必要がある場合であって、本人の同意を得ることが困難であるとき。
四 国の機関若しくは地方公共団体又はその委託を受けた者が法令の定める事務を遂行することに対して協力する必要がある場合であって、本人の同意を得ることにより当該事務の遂行に支障を及ぼすおそれがあるとき。

1)

利用目的の特定及び制限
あらかじめ本人の同意を得ないで個人情報保護法第１５条の規定により特定された

利用目的の達成に必要な範囲を超えて個人情報を取り扱ってはならないが（個人情報保護法第１６条第１項）、同条第３項に掲げる場合については、本人の同意を得る必要はない。具体的な例としては以下のとおりである。
178

【法の規定により遵守すべき事項等】
・アカデミッククラウド参加組織は、個人情報を取り扱うに当たって、その利用目的をできる限り特定しなければならない。
・アカデミッククラウド参加組織は、利用目的を変更する場合には、変更前の利用目的と相当の関連性を有すると合理的に認められる範囲を超えて行ってはならない。
・アカデミッククラウド参加組織は、あらかじめ本人の同意を得ないで、特定された利
用目的の達成に必要な範囲を超えて個人情報を取り扱ってはならない。
・個人情報を取得する時点で、本人の同意があったにもかかわらず、その後、本人から利用目的の一部についての同意を取り消す旨の申出があった場合は、その後の個人情報の取扱いについては、本人の同意が取り消されなかった範囲に限定して取り扱う。
・利用目的の制限の例外（個人情報保護法第１６条第３項）に該当する場合は、本人の同意を得ずに個人情報を取り扱うことができる。
【その他の事項】
・利用目的の制限の例外に該当する「法令に基づく場合」等であっても、利用目的以外の目的で個人情報を取り扱う場合は、当該法令等の趣旨をふまえ、その取り扱う範囲を真に必要な範囲に限定することが求められる。
２.

利用目的の通知等（個人情報保護法第１８条）（取得に際しての利用目的の通知等）
個人情報保護法第十八条 個人情報取扱事業者は、個人情報を取得した場合は、
あらかじめその利用目的を公表している場合を除き、速やかに、その利用目的を、本人に通知し、又は公表しなければならない。
２ 個人情報取扱事業者は、前項の規定にかかわらず、本人との間で契約を締結することに伴って契約書その他の書面（電子的方式、磁気的方式その他人の知覚によっては認識することができない方式で作られる記録を含む。以下この項において同じ。
）に記載された当該本人の個人情報を取得する場合その他本人から直接書面に記載された当該本人の個人情報を取得する場合は、あらかじめ、
本人に対し、その利用目的を明示しなければならない。ただし、人の生命、身体又は財産の保護のために緊急に必要がある場合は、この限りでない。
３ 個人情報取扱事業者は、利用目的を変更した場合は、変更された利用目的について、本人に通知し、又は公表しなければならない。
４ 前三項の規定は、次に掲げる場合については、適用しない。
179

一 利用目的を本人に通知し、又は公表することにより本人又は第三者の生命、身体、財産その他の権利利益を害するおそれがある場合
二 利用目的を本人に通知し、又は公表することにより当該個人情報取扱事業者の権利又は正当な利益を害するおそれがある場合
三 国の機関又は地方公共団体が法令の定める事務を遂行することに対して協力する必要がある場合であって、利用目的を本人に通知し、又は公表することにより当該事務の遂行に支障を及ぼすおそれがあるとき。
四 取の状況からみて利用目的が明らかであると認められる場合【法の規定により遵守すべき事項等】
・アカデミッククラウド参加組織は、個人情報を取得するに当たって、あらかじめその利用目的を公表しておくか、個人情報を取得した場合、速やかに、その利用目的を、本人に通知し、又は公表しなければならない。
・利用目的の公表方法としては、組織内等に掲示するとともに、各参加組織のウェブサ
イトへの掲載等の方法により公表しなければならない。
・アカデミッククラウド参加組織は、本人に書類を提出してもらう場合など、本人から直接書面に記載された当該本人の個人情報を取得する場合は、あらかじめ、本人に対し、その利用目的を組織内の掲示等により明示しなければならない。
・アカデミッククラウド参加組織は、利用目的を変更した場合は、変更された利用目的について、本人に通知し、又は公表しなければならない。
・取得の状況からみて利用目的が明らかであると認められる場合など利用目的の通知等の例外に該当する場合は、上記内容は適用されない。
【その他の事項】
・利用目的が、本規定の例外である「取得の状況からみて利用目的が明らかであると認められる場合」に該当する場合であっても、本人・利用者等に利用目的をわかりやすく示す観点から、利用目的の公表に当たっては、当該利用目的についても併せて記載する。
・組織内等への掲示に当たっては、受付の近くに当該内容を説明した表示を行い、初回の本人・利用者等に対しては、受付時や利用開始時において当該掲示についての注意を促す。
・本人・利用者等の希望がある場合、詳細の説明や当該内容を記載した書面の交付を行う。
３.

個人情報の適正な取得、個人データ内容の正確性の確保（個人情報保護法第１７条、第１９条）180

（適正な取得）
個人情報保護法第十七条 個人情報取扱事業者は、偽りその他不正の手段により個人情報を取得してはならない。
（データ内容の正確性の確保）
個人情報保護法第十九条 個人情報取扱事業者は、利用目的の達成に必要な範囲内において、個人データを正確かつ最新の内容に保つよう努めなければならない。

【法の規定により遵守すべき事項等】
・アカデミッククラウド参加組織は、偽りその他の不正の手段により個人情報を取得してはならない。
・親の同意なく、十分な判断能力を有していない子どもから家族の個人情報を取得してはならない。
・アカデミッククラウド参加組織は、適正なアカデミッククラウドサービスを提供するという利用目的の達成に必要な範囲内において、個人データを正確かつ最新の内容に保つよう努めなければならない。
【その他の事項】
・第三者提供により他のアカデミッククラウド参加組織から個人情報を取得したとき、当該個人情報の内容に疑義が生じた場合には、記載内容の事実に関して本人又は情報の提供を行った者に確認をとること。
４.

安全管理措置、従業者の監督及び委託先の監督（個人情報保護法第２０条～第２２条）（安全管理措置）
個人情報保護法第二十条 個人情報取扱事業者は、その取り扱う個人データの漏
えい、滅失又はき損の防止その他の個人データの安全管理のために必要かつ適切な措置を講じなければならない。
（従業者の監督）
個人情報保護法第二十一条 個人情報取扱事業者は、その従業者に個人データを取り扱わせるに当たっては、当該個人データの安全管理が図られるよう、当該従業者に対する必要かつ適切な監督を行わなければならない。
（委託先の監督）
個人情報保護法第二十二条 個人情報取扱事業者は、個人データの取扱いの全部又は一部を委託する場合は、その取扱いを委託された個人データの安全管理が181

図られるよう、委託を受けた者に対する必要かつ適切な監督を行わなければならない。
（１）アカデミッククラウド参加組織が講ずるべき安全管理措置①安全管理措置
アカデミッククラウド参加組織は、その取り扱う個人データの漏えい、滅失又はき損の防止その他の個人データの安全管理のため、組織的、人的、物理的、及び技術的安全管理措置を講じなければならない。その際、本人の個人データが漏えい、滅失又はき損等をした場合に本人が被る権利利益の侵害の大きさを考慮し、事業の性質及び個人デー
タの取扱い状況等に起因するリスクに応じ、必要かつ適切な措置を講ずるものとする。
なお、その際には、個人データを記録した媒体の性質に応じた安全管理措置を講ずるものとする。
②従業者の監督
アカデミッククラウド参加組織は、①の安全管理措置を遵守させるよう、従業者に対し必要かつ適切な監督をしなければならない。なお、「従業者」とは、当該事業者の指揮命令を受けて業務に従事する者すべてを含むものであり、また、雇用関係のある者のみならず、理事、派遣労働者等も含むものである。
（２）安全管理措置として考えられる事項
アカデミッククラウド参加組織は、その取り扱う個人データの重要性にかんがみ、個人データの漏えい、滅失またはき損の防止その他の安全管理のため、その規模、従業者の様態等を勘案して、以下に示すような取組を参考に、必要な措置を行うものとする。
また、同一事業者が複数の施設を開設する場合、当該施設間の情報交換については第三者提供に該当しないが、各施設ごとに安全管理措置を講ずるなど、個人情報の利用目的を踏まえた個人情報の安全管理を行う。
なお、安全管理措置については、別途定める規程に基づくものとする。
① 個人情報保護推進のための組織体制等の整備
・従業者の責任体制の明確化を図り、具体的な取組を進めるため、アカデミッククラウ
ドにおける個人情報保護に関し十分な知識を有する管理者、監督者等を定めたり、個人情報保護の推進を図るための委員会等を設置する。
・アカデミッククラウド参加組織で行っている個人データの安全管理措置について定期的に自己評価を行い、見直しや改善を行うべき事項について適切な改善を行う。

182

② 個人データの漏えい等の問題が発生した場合等における報告連絡体制の整備
・１）個人データの漏えい等の事が発生した場合、又は発生の可能性が高いと判断した
場合、２）個人データの取扱いに関する規程等に違反している事実が生じた場合、又は兆候が高いと判断した場合における責任者等への報告連絡体制の整備を行う。
・個人データの漏えい等の情報は、苦情等の一環として、外部から報告される場合も想定されることから、苦情への対応を行う体制との連携も図る。
③ 雇用契約時における個人情報保護に関する規程の整備
・雇用契約や就業規則において、就業期間中はもとより離職後も含めた守秘義務を課すなど従業者の個人情報保護に関する規程を整備し、徹底を図る。
④ 従業者に対する教育研修の実施
・取り扱う個人データの適切な保護が確保されるよう、従業者に対する教育研修の実施等により、個人データを実際の業務で取り扱うこととなる従業者の啓発を図り、従業者の個人情報保護意識を徹底する。
・この際、派遣労働者についても、「派遣先が講ずべき措置に関する指針」（平成１１年
労働省告示第１３８号）において、「必要に応じた教育訓練に係る便宜を図るよう努め
なければならない」とされていることを踏まえ、個人情報の取扱いに係る教育研修の実施に配慮する必要がある。
⑤ 物理的安全管理措置
・個人データの盗難・紛失等を防止するため、以下のような物理的安全管理措置を行う。
－入退館（室）管理の実施－盗難等に対する予防対策の実施－機器、装置等の固定など物理的な保護＊詳細については、別途定める安全管理に関する規程に基づくものとする。
⑥ 技術的安全管理措置
・個人データの盗難・紛失等を防止するため、個人データを取り扱う情報システムについて以下のような技術的安全管理措置を行う。
－個人データに対するアクセス管理（ＩＤやパスワード等による認証、各職員の業務内容に応じて業務上必要な範囲にのみアクセスできるようなシステム構成の採用等）－個人データに対するアクセス記録の保存－個人データに対するファイアウォールの設置⑦ 個人データの保存
183

・個人データを長期にわたって保存する場合には、保存媒体の劣化防止など個人データが消失しないよう適切に保存する。
・個人データの保存に当たっては、本人からの照会等に対応する場合など必要なときに迅速に対応できるよう、インデックスの整備など検索可能な状態で保存しておく。
⑧ 不要となった個人データの廃棄、消去
・不要となった個人データを廃棄する場合には、焼却や溶解など、個人データを復元不可能な形にして廃棄する。
・個人データを取り扱った情報機器を廃棄する場合は、記憶装置内の個人データを復元
不可能な形に消去して廃棄する。
・これらの廃棄業務を委託する場合には、個人データの取扱いについても委託契約において明確に定める。
（３）業務を委託する場合の取扱い① 委託先の監督
アカデミッククラウド参加組織は、システム管理に係る事務等個人データの取扱いの全部又は一部を委託する場合、個人情報保護法第２０条に基づく安全管理措置を遵守させるよう受託者に対し、必要かつ適切な監督をしなければならない。
「必要かつ適切な監督」には、委託契約において委託者である事業者が定める安全管
理措置の内容を契約に盛り込み受託者の義務とするほか、業務が適切に行われていることを定期的に確認することなども含まれる。
また、業務が再委託された場合で、再委託先が適切な取扱いを行ったことにより、問題が生じた場合は、アカデミッククラウド参加組織や再委託した事業者が責めを負うこともあり得る。
②業務を委託する場合の留意事項
アカデミッククラウド参加組織は、個人データの取扱いの全部又は一部を委託する場
合、以下の事項に留意しなければならない。
・個人情報を適切に取り扱っている事業者を委託先（受託者）として選定する
・契約において、個人情報の適切な取扱いに関する内容を盛り込む（委託期間中のほか、委託終了後の個人データの取扱いも含む。）
・受託者が、委託を受けた業務の一部を再委託することを予定している場合は、再委託を受ける事業者の選定において個人情報を適切に取り扱っている事業者が選定されるとともに、再委託先事業者が個人情報を適切に取り扱っていることが確認できる
よう契約において配慮する
184

・受託者が個人情報を適切に取り扱っていることを定期的に確認する・受託者における個人情報の取扱いに疑義が生じた場合（本人・利用者等からの申出があり、確認の必要があると考えられる場合を含む。）には、受託者に対し、説明を求め、必要に応じ改善を求める等適切な措置をとる（５）個人情報の漏えい等の問題が発生した場合における二次被害の防止等
個人情報の漏えい等の問題が発生した場合には、二次被害の防止、類似事案の発生回避等の観点から、個人情報の保護に配慮しつつ、可能な限り事実関係を公表するとともに、都道府県の所管課等に速やかに報告する。

【法の規定により遵守すべき事項等】
・アカデミッククラウド参加組織は、その取り扱う個人データの漏えい、滅失又はき損の防止その他個人データの安全管理のために必要かつ適切な措置を講じなければならない。
・アカデミッククラウド参加組織は、その従業者に個人データを取り扱わせるに当たっては、当該個人データの安全管理が図られるよう、当該従業者に対する必要かつ適切な監督を行わなければならない。
・アカデミッククラウド参加組織は、個人データの取扱いの全部又は一部を委託する場
合は、その取扱いを委託された個人データの安全管理が図られるよう、委託を受けた者に対する必要かつ適切な監督を行わなければならない。
【その他の事項】
・アカデミッククラウド参加組織は、安全管理措置に関する取組を一層推進するため、安全管理措置が適切であるかどうかを一定期間ごとに検証するほか、必要に応じて外部機関による検証を受けることで、改善を図ることが望ましい。
５.

個人データの第三者提供（個人情報保護法第２３条）（第三者提供の制限）
個人情報保護法第二十三条 個人情報取扱事業者は、次に掲げる場合を除くほか、
あらかじめ本人の同意を得ないで、個人データを第三者に提供してはならない。
一 法令に基づく場合
二 人の生命、身体又は財産の保護のために必要がある場合であって、本人の同意を得ることが困難であるとき。
三 公衆衛生の向上又は児童の健全な育成の推進のために特に必要がある場合

185

であって、本人の同意を得ることが困難であるとき。
四 国の機関若しくは地方公共団体又はその委託を受けた者が法令の定める事務を遂行することに対して協力する必要がある場合であって、本人の同意を得ることにより当該事務の遂行に支障を及ぼすおそれがあるとき。
２ 個人情報取扱事業者は、第三者に提供される個人データについて、本人の求めに応じて当該本人が識別される個人データの第三者への提供を停止することとしている場合であって、次に掲げる事項について、あらかじめ、本人に通知し、又は本人が容易に知り得る状態に置いているときは、前項の規定にかかわらず、当該個人データを第三者に提供することができる。
一 第三者への提供を利用目的とすること。
二 第三者に提供される個人データの項目
三 第三者への提供の手段又は方法
四 本人の求めに応じて当該本人が識別される個人データの第三者への提供を停止すること。
３ 個人情報取扱事業者は、前項第二号又は第三号に掲げる事項を変更する場合は、変更する内容について、あらかじめ、本人に通知し、又は本人が容易に知り得る状態に置かなければならない。
４ 次に掲げる場合において、当該個人データの提供を受ける者は、前三項の規定の適用については、第三者に該当しないものとする。
一 個人情報取扱事業者が利用目的の達成に必要な範囲内において個人データの取扱いの全部又は一部を委託する場合
二 合併その他の事由による事業の承継に伴って個人データが提供される場合
三 個人データを特定の者との間で共同して利用する場合であって、その旨並びに共同して利用される個人データの項目、共同して利用する者の範囲、利用する者の利用目的及び当該個人データの管理について責任を有する者の氏名又は名称について、あらかじめ、本人に通知し、又は本人が容易に知り得る状態に置いているとき。
５ 個人情報取扱事業者は、前項第三号に規定する利用する者の利用目的又は個人データの管理について責任を有する者の氏名若しくは名称を変更する場合は、変更する内容について、あらかじめ、本人に通知し、又は本人が容易に知り得る状態に置かなければならない。

（１）第三者提供の取扱い
アカデミッククラウド参加組織は、あらかじめ本人の同意を得ないで、個人データを第三者に提供してはならない。よって、次のような場合には、本人の同意を得る必要が
186

ある。

法の規定により遵守すべき事項等】
・アカデミッククラウド参加組織においては、あらかじめ本人の同意を得ないで、個人データを第三者に提供してはならない。なお、（２）の本人の同意を得る必要がない場
合に該当する場合には、本人の同意を得る必要はない。
・個人データの第三者提供について本人の同意があった場合で、その後、本人から第三者提供の範囲の一部についての同意を取り消す旨の申出があった場合は、その後の個人
データの取扱いについては、本人の同意のあった範囲に限定して取り扱うものとする。
【その他の事項】
・第三者提供に該当しない情報提供が行われる場合であっても、組織内等への掲示、ホームページ等により情報提供先をできるだけ明らかにするとともに、本人・利用者等からの問い合わせがあった場合に回答できる体制を確保する。
・例えば、業務委託の場合、当該アカデミッククラウド参加組織において委託している
業務の内容、委託先事業者、委託先事業者との間での個人情報の取扱いに関する取り決めの内容等について公開することが考えられる。
６.

保有個人データに関する事項の公表等（個人情報保護法第２４条）（保有個人データに関する事項の公表等）
個人情報保護法第二十四条 個人情報取扱事業者は、保有個人データに関し、次に掲げる事項について、本人の知り得る状態（本人の求めに応じて遅滞なく回答する場合を含む。
）に置かなければならない。
一 当該個人情報取扱事業者の氏名又は名称
二 すべての保有個人データの利用目的（第十八条第四項第一号から第三号までに該当する場合を除く。
）
三 次項、次条第一項、第二十六条第一項又は第二十七条第一項若しくは第二項の規定による求めに応じる手続（第三十条第二項の規定により手数料の額を定めた
ときは、その手数料の額を含む。）
四 前三号に掲げるもののほか、保有個人データの適正な取扱いの確保に関し必要な事項として政令で定めるもの
２ 個人情報取扱事業者は、本人から、当該本人が識別される保有個人データの利用目的の通知を求められたときは、本人に対し、遅滞なく、これを通知しなければならない。ただし、次の各号のいずれかに該当する場合は、この限りでない。
一 前項の規定により当該本人が識別される保有個人データの利用目的が明らか
な場合

187

二 第十八条第四項第一号から第三号までに該当する場合
３ 個人情報取扱事業者は、前項の規定に基づき求められた保有個人データの利用目的を通知しない旨の決定をしたときは、本人に対し、遅滞なく、その旨を通知しなければならない。
（保有個人データの適正な取扱いの確保に関し必要な事項）
令第五条 個人情報保護法第二十四条第一項第四号の政令で定めるものは、次に掲げるものとする。
一 当該個人情報取扱事業者が行う保有個人データの取扱いに関する苦情の申出
先
二 当該個人情報取扱事業者が認定個人情報保護団体の対象事業者である場合にあっては、当該認定個人情報保護団体の名称及び苦情の解決の申出先【法の規定により遵守すべき事項等】
・アカデミッククラウド参加組織は、保有個人データに関し、(ｱ)当該個人情報取扱事
業者の氏名又は名称、(ｲ)すべての保有個人データの利用目的（個人情報保護法第１８条第４項第１号から第３号までに規定された例外の場合を除く）、(ｳ)保有個人データの利用目的の通知、開示、訂正、利用停止等の手続の方法、及び保有個人データの利用目的の通知又は開示に係る手数料の額、(ｴ)苦情の申出先等について、本人の知り得る状態（本人の求めに応じて遅滞なく回答する場合を含む）に置かなければならない。
・アカデミッククラウド参加組織は、本人から、当該本人が識別される保有個人データの利用目的の通知を求められたときは、上記の措置により利用目的が明らかになっている場合及び個人情報保護法第１８条第４項第１号から第３号までの例外に相当する場
合を除き、遅滞なく通知しなければならない。
・アカデミッククラウド参加組織は、利用目的の通知をしない旨の決定をしたときは、本人に対し、遅滞なく、その旨を通知しなければならない。
・法施行前から保有している個人情報についても同様の取扱いを行う。
【その他の事項】
・アカデミッククラウド参加組織は、保有個人データについて、その利用目的、開示、訂正、利用停止等の手続の方法及び利用目的の通知又は開示に係る手数料の額、苦情の申出先等について、少なくとも組織内等への掲示、さらにホームページ等によりできるだけ明らかにするとともに、本人・利用者等からの要望により書面を交付したり、問い合わせがあった場合に具体的内容について回答できる体制を確保する。

188

７.

本人からの求めによる保有個人データの開示（個人情報保護法第２５条）（開示）
個人情報保護法第二十五条 個人情報取扱事業者は、本人から、当該本人が識別される保有個人データの開示（当該本人が識別される保有個人データが存在しない
ときにその旨を知らせることを含む。以下同じ。
）を求められたときは、本人に対し、政令で定める方法により、遅滞なく、当該保有個人データを開示しなければならない。ただし、開示することにより次の各号のいずれかに該当する場合は、その全部又は一部を開示しないことができる。
一 本人又は第三者の生命、身体、財産その他の権利利益を害するおそれがある場
合二 当該個人情報取扱事業者の業務の適正な実施に著しい支障を及ぼすおそれがある場合
三 他の法令に違反することとなる場合
２ 個人情報取扱事業者は、前項の規定に基づき求められた保有個人データの全部又は一部について開示しない旨の決定をしたときは、本人に対し、遅滞なく、その旨を通知しなければならない。
３ 他の法令の規定により、本人に対し第一項本文に規定する方法に相当する方法により当該本人が識別される保有個人データの全部又は一部を開示することとされている場合には、当該全部又は一部の保有個人データについては、同項の規定は、適用しない。
（個人情報取扱事業者が保有個人データを開示する方法）
政令第六条 個人情報保護法第二十五条第一項の政令で定める方法は、書面の交付による方法（開示の求めを行った者が同意した方法があるときは、当該方法）とする。
（１）開示の原則
アカデミッククラウド参加組織は、本人から、当該本人が識別される保有個人データの開示を求められたときは、本人に対し、書面の交付による方法等により、遅滞なく、
当該保有個人データを開示しなければならない。

【法の規定により遵守すべき事項等】
・アカデミッククラウド参加組織は、本人から、当該本人が識別される保有個人データの開示を求められたときは、本人に対し、遅滞なく、当該保有個人データを開示しなけ
ればならない。また、当該本人が識別される保有個人データが存在しないときにその旨知らせることとする。ただし、開示することにより、個人情報保護法第２５条第１項の各号のいずれかに該当する場合は、その全部又は一部を開示しないことができる。

189

・開示の方法は、書面の交付又は求めを行った者が同意した方法による。
・アカデミッククラウド参加組織は、求められた保有個人データの全部又は一部について開示しない旨を決定したときは、本人に対し、遅滞なく、その旨を通知しなければならない。また、本人に通知する場合には、本人に対してその理由を説明するよう努めなければならない。
・他の法令の規定により、保有個人データの開示について定めがある場合には、当該法令の規定によるものとする。
【その他の事項】
・法定代理人等、開示の求めを行い得る者から開示の求めがあった場合、原則として本人・利用者本人に対し保有個人データの開示を行う旨の説明を行った後、法定代理人等に対して開示を行うものとする。
・アカデミッククラウド参加組織は、保有個人データの全部又は一部について開示しない旨決定した場合、本人に対するその理由の説明に当たっては、文書により示すことを基本とする。また、苦情への対応を行う体制についても併せて説明することが望ましい。
８.

訂正及び利用停止（個人情報保護法第２６条、第２７条）（訂正等）
個人情報保護法第二十六条 個人情報取扱事業者は、本人から、当該本人が識別される保有個人データの内容が事実でないという理由によって当該保有個人データの内容の訂正、追加又は削除（以下この条において「訂正等」という。）を求められた場合には、その内容の訂正等に関して他の法令の規定により特別の手続が定められている場合を除き、利用目的の達成に必要な範囲内において、遅滞なく必要な調査を行い、その結果に基づき、当該保有個人データの内容の訂正等を行わなければならない。
２ 個人情報取扱事業者は、前項の規定に基づき求められた保有個人データの内容の全部若しくは一部について訂正等を行ったとき、又は訂正等を行わない旨の決定をしたときは、本人に対し、遅滞なく、その旨（訂正等を行ったときは、その内容を含む。
）を通知しなければならない。
（利用停止等）
個人情報保護法第二十七条 個人情報取扱事業者は、本人から、当該本人が識別される保有個人データが第十六条の規定に違反して取り扱われているという理由又は第十七条の規定に違反して取得されたものであるという理由によって、当該保有個人データの利用の停止又は消去（以下この条において「利用停止等」という。
）を求められた場合であって、その求めに理由があることが判明したときは、違反を是正するために必要な限度で、遅滞なく、当該保有個人データの利用停止等
190

を行わなければならない。ただし、当該保有個人データの利用停止等に多額の費用を要する場合その他の利用停止等を行うことが困難な場合であって、本人の権
利利益を保護するため必要なこれに代わるべき措置をとるときは、この限りでない。
２ 個人情報取扱事業者は、本人から、当該本人が識別される保有個人データが第二十三条第一項の規定に違反して第三者に提供されているという理由によって、当該保有個人データの第三者への提供の停止を求められた場合であって、その求めに理由があることが判明したときは、遅滞なく、当該保有個人データの第三者への提供を停止しなければならない。ただし、当該保有個人データの第三者への提供の停止に多額の費用を要する場合その他の第三者への提供を停止することが困難な場合であって、本人の権利利益を保護するため必要なこれに代わるべき措置をとるときは、この限りでない。
３ 個人情報取扱事業者は、第一項の規定に基づき求められた保有個人データの全部若しくは一部について利用停止等を行ったとき若しくは利用停止等を行わない
旨の決定をしたとき、又は前項の規定に基づき求められた保有個人データの全部若しくは一部について第三者への提供を停止したとき若しくは第三者への提供を停止しない旨の決定をしたときは、本人に対し、遅滞なく、その旨を通知しなけ
ればならない。

【法の規定により遵守すべき事項等】
・アカデミッククラウド参加組織は、個人情報保護法第２６条、第２７条第１項又は第２項の規定に基づき、本人から、保有個人データの訂正等、利用停止等、第三者への提供の停止を求められた場合で、それらの求めが適正であると認められるときは、これらの措置を行わなければならない。
・ただし、利用停止等及び第三者への提供の停止については、利用停止等に多額の費用を要する場合など当該措置を行うことが困難な場合であって、本人の権利利益を保護するため必要なこれに代わるべき措置をとるときは、この限りでない。
・なお、以下の場合については、これらの措置を行う必要はない。
①訂正等の求めがあった場合であっても、(ｱ)利用目的から見て訂正等が必要でない場合、(ｲ)誤りである指摘が正しくない場合又は(ｳ)訂正等の対象が事実でなく評価に関する情報である場合②利用停止等、第三者への提供の停止の求めがあった場合であっても、手続違反等の指摘が正しくない場合・アカデミッククラウド参加組織は、上記の措置を行ったとき、又は行わない旨を決定したときは、本人に対し、遅滞なく、その旨を通知しなければならない。また、本人に191通知する場合には、本人に対してその理由を説明するよう努めなければならない。
【その他の事項】
・アカデミッククラウド参加組織は、訂正等、利用停止等又は第三者への提供の停止が求められた保有個人データの全部又は一部について、これらの措置を行わない旨決定した場合、本人に対するその理由の説明に当たっては、文書により示すことを基本とする。
その際は、苦情への対応を行う体制についても併せて説明することが望ましい。
・保有個人データの訂正等にあたっては、訂正した者、内容、日時等が分かるように行
われなければならない。
・保有個人データの字句などを変える改ざんは、行ってはならない。
９.

開示等の求めに応じる手続及び手数料（個人情報保護法第２９条、第３０条）（開示等の求めに応じる手続）
個人情報保護法第二十九条 個人情報取扱事業者は、第二十四条第二項、第二十五条第一項、第二十六条第一項又は第二十七条第一項若しくは第二項の規定による求め（以下この条において「開示等の求め」という。）に関し、政令で定めるところにより、その求めを受け付ける方法を定めることができる。この場合において、本人は、当該方法に従って、開示等の求めを行わなければならない。
２ 個人情報取扱事業者は、本人に対し、開示等の求めに関し、その対象となる保有個人データを特定するに足りる事項の提示を求めることができる。この場合において、個人情報取扱事業者は、本人が容易かつ的確に開示等の求めをすることができるよう、当該保有個人データの特定に資する情報の提供その他本人の利便を考慮した適切な措置をとらなければならない。
３ 開示等の求めは、政令で定めるところにより、代理人によってすることができる。
４ 個人情報取扱事業者は、前三項の規定に基づき開示等の求めに応じる手続を定めるに当たっては、本人に過重な負担を課するものとならないよう配慮しなければならない。
（手数料）
個人情報保護法第三十条 個人情報取扱事業者は、第二十四条第二項の規定による
利用目的の通知又は第二十五条第一項の規定による開示を求められたときは、当該措置の実施に関し、手数料を徴収することができる。
２ 個人情報取扱事業者は、前項の規定により手数料を徴収する場合は、実費を勘案して合理的であると認められる範囲内において、その手数料の額を定めなければならない。
（開示等の求めを受け付ける方法）
192

令第七条 個人情報保護法第二十九条第一項の規定により個人情報取扱事業者が開示等の求めを受け付ける方法として定めることができる事項は、次に掲げるとおりとする。
一 開示等の求めの申出先
二 開示等の求めに際して提出すべき書面（電子的方式、磁気的方式その他人の知覚によっては認識することができない方式で作られる記録を含む。
）の様式その他の開示等の求めの方式
三 開示等の求めをする者が本人又は次条に規定する代理人であることの確認の方法
四 個人情報保護法第三十条第一項の手数料の徴収方法（開示等の求めをすることができる代理人）
令第八条 個人情報保護法第二十九条第三項の規定により開示等の求めをすることができる代理人は、次に掲げる代理人とする。
一 未成年者又は成年被後見人の法定代理人
二 開示等の求めをすることにつき本人が委任した代理人（１）開示等を行う情報の特定
アカデミッククラウド参加組織は、本人に対し、開示等の求めに関して、その対象となる保有個人データを特定するに足りる事項の提示を求めることができるが、この場合には、本人が容易かつ的確に開示等の求めをすることができるよう、
当該保有個人データの特定に資する情報の提供その他本人の利便を考慮した措置をとらなければならない。
また、保有個人データの開示等については、本人の求めにより、保有個人データの全体又は一部が対象となるが、当該本人の保有個人データが多岐にわたる、データ量が膨大であるなど、全体の開示等が困難又は非効率な場合、アカデミック
クラウド参加組織は、本人が開示等の求めを行う情報の範囲を特定するのに参考となる情報（過去の受診の状況、病態の変化等）を提供するなど、本人の利便を考慮した支援を行うものとする。
（２）代理人による開示等の求め
保有個人データの開示等については、本人のほか、①未成年者又は成年被後見人の法定代理人、②開示等の求めをすることにつき本人が委任した代理人により行うことができる。

【法の規定により遵守すべき事項等】
・アカデミッククラウド参加組織は、保有個人データの開示等の求めに関し、本人に過193

重な負担を課すものとならない範囲において、以下の事項について、その求めを受け付ける方法を定めることができる。
(ｱ)開示等の求めの受付先(ｲ)開示等の求めに際して提出すべき書面の様式、その他の開示等の求めの受付方法(ｳ)開示等の求めをする者が本人又はその代理人であることの確認の方法(ｴ)保有個人データの利用目的の通知、又は保有個人データの開示をする際に徴収する手数料の徴収方法
・アカデミッククラウド参加組織は、本人に対し、開示等の求めに関して、その対象となる保有個人データを特定するに足りる事項の提示を求めることができるが、この場合には、本人が容易かつ的確に開示等の求めをすることができるよう、当該保有個人デー
タの特定に資する情報の提供その他本人の利便を考慮した措置をとらなければならない。
・保有個人データの開示等の求めは、本人のほか、未成年者又は成年被後見人の法定代理人、当該求めをすることにつき本人が委任した代理人によってすることができる。
・アカデミッククラウド参加組織は、保有個人データの利用目的の通知、又は保有個人
データの開示を求められたときは、当該措置の実施に関し、手数料を徴収することができ、その際には実費を勘案して合理的であると認められる範囲内において、手数料の額を定めなければならない。
【その他の事項】
・アカデミッククラウド参加組織は、以下の点に留意しつつ、保有個人データの開示等の手続を定めることが望ましい。
－開示等の求めの方法は書面によることが望ましいが、本人・利用者等の自由な求めを阻害しないため、開示等の求めに係る書面に理由欄を設けることなどにより開示等を求める理由の記載を要求すること及び開示等を求める理由を尋ねることは適切である。
－開示等を求める者が本人（又はその代理人）であることを確認する。
－開示等の求めがあった場合、所長等の意見を聴いた上で、速やかに保有個人データの開示等をするか否か等を決定し、これを開示の求めを行った者に通知する。
－保有個人データの開示に当たり、個人情報保護法第２５条第１項各号に該当する可能性がある場合には、開示の可否について検討するために設置した検討委員会等において検討した上で、速やかに開示の可否を決定することが望ましい。
－保有個人データの開示を行う場合には、日常のアカデミッククラウドサービス提供への影響等も考慮し、本人に過重な負担を課すものとならない範囲で、日時、場所、方法等を指定することができる。
・代理人等、開示の求めを行い得る者から開示の求めがあった場合、原則として本人・利用者本人に対し保有個人データの開示を行う旨の説明を行った後、開示の求めを行っ
194

た者に対して開示を行うものとする。
・代理人等からの求めがあった場合で、①本人による具体的意思を把握できない包括的な委任に基づく請求、②開示等の請求が行われる相当以前に行われた委任に基づく請求が行われた場合には、本人への説明に際し、開示の求めを行った者及び開示する保有個人データの内容について十分説明し、本人の意思を確認するとともに代理人の求めの適正性、開示の範囲等について本人の意思を踏まえた対応を行うものとする。
１０.

理由の説明、苦情対応（個人情報保護法第２８条、第３１条）（理由の説明）
個人情報保護法第二十八条 個人情報取扱事業者は、第二十四条第三項、第二十五条第二項、第二十六条第二項又は前条第三項の規定により、本人から求められた措置の全部又は一部について、その措置をとらない旨を通知する場合又はその措置と異なる措置をとる旨を通知する場合は、本人に対し、その理由を説明するよう努めなければならない。
（個人情報取扱事業者による苦情の処理）
個人情報保護法第三十一条 個人情報取扱事業者は、個人情報の取扱いに関する苦情の適切かつ迅速な処理に努めなければならない。
２ 個人情報取扱事業者は、前項の目的を達成するために必要な体制の整備に努めなければならない。

【法の規定により遵守すべき事項等】
・アカデミッククラウド参加組織は、本人から求められた保有個人データの利用目的の通知、開示、訂正等、利用停止等において、その措置をとらない旨又はその措置と異なる措置をとる旨本人に通知する場合は、本人に対して、その理由を説明するよう努めなければならない。
・アカデミッククラウド参加組織は、個人情報の取扱いに関する苦情の適切かつ迅速な対応に努めなければならない。また、アカデミッククラウド参加組織は、苦情の適切かつ迅速な対応を行うにあたり、苦情への対応を行う窓口機能等の整備や苦情への対応の手順を定めるなど必要な体制の整備に努めなければならない。
【その他の事項】
・アカデミッククラウド参加組織は、本人に対して理由を説明する際には、文書により示すことを基本とする。その際は、苦情への対応を行う体制についても併せて説明することが望ましい。
・アカデミッククラウド参加組織は、本人・利用者等からの苦情対応にあたり、専用の195

窓口の設置や担当職員による相談体制を確保するなど、本人・利用者等が相談を行いや
すい環境の整備に努めること。

196

⑦ ネットワークに係るアカデミッククラウドシステムの調査検討（概要）本業務の開始にあたり、キックオフシンポジウムの準備を進めるとともに、年度末までの事業スケジュールの詳細化や調査内容の初期検討を行った。大規模アン
ケート調査に関しては、ネットワーク分野の標準仕様をまとめるにあたって必要となる、各機関のネットワーク基盤の現状把握を中心としたアンケート項目の検討を行った。大学ICT推進協議会年次大会における中間報告会に向け、アンケート結果の初期集計を実施し、中間段階での集計結果をとりまとめた。その後、最終報告書に掲載する最終的なアンケート集計結果の処理を行った。アカデミッククラウドに資するネッ
トワークに求められるあるべき姿について検討し、標準仕様としての機能要件をとりまとめた。また、アンケート集計結果にもとづき、現状における課題について詳細な検討を行った。最終報告書の構成を全体で調整したうえで、上記の業務成果としてのネットワーク分野の最終報告をとりまとめ、最終報告会で報告するとともに報告書を作成した。
1. アンケート調査結果
ネットワーク分野では、各機関のネットワーク管理部署向けのアンケート調査を行い、大学等のネットワーク基盤の観点から見たアカデミッククラウド環境構築の課題や効果の分析を行った。以下、調査結果とその分析について述べる。アンケート調査の内容
としては、自機関内ネットワーク基盤や提供しているネットワーク接続サービス、および対外接続環境等の整備状況を中心に、以下の項目に関して質問するように設定した。
・ 自機関内ネットワーク基盤に関して
 ネットワークトポロジー、キャンパス間接続方法と帯域
 ネットワーク規模
 バックボーンネットワークの帯域 エッジルータ・スイッチへの接続帯域
 サーバ群、自機関内クラウドとバックボーンの接続帯域
・ 自機関ネットワークの外部への接続に関して
 外部との接続方法と帯域・ ユーザの自機関内ネットワークへの接続サービスに関して
 無線ネットワーク接続サービスの提供
 eduroam 対応
 VPN 接続サービスの提供
・ 自機関外にサーバやクラウドを設置している場合、自機関内ネットワークとの接続に関して
 機関外サーバ・クラウドと自機関内ネットワークとの接続方法と帯域
197

・ 将来的な自機関内ネットワークのあり方に関して
 将来的な拡張計画
 クラウド化に向けた問題点、課題、懸念事項
図 Ⅲ-⑦-1 に、アンケート調査に対して回答を得た機関数の区分別比率を示す。有効
回答数は 582 機関、うち、国立大が約 13%、私立大が約 50%、公立大が約 9%、高専が約 7%、短大が約 17%、研究機関が約 3%という内訳であった。

図 Ⅲ-⑦-1 回答を得た機関数の区分別比率

A) 自機関内ネットワーク基盤に関して
自機関内のネットワーク基盤に関して、ネットワークトポロジーについて質問した。
設問は、ネットワークトポロジーについて、一つの拠点(キャンパス等)のみ、複数拠点間を対等に接続、主たる拠点を中心に複数の副拠点を接続、上記の混在、その他、のうちから一つを選ぶ形式とした。
図 Ⅲ-⑦-2 にネットワークトポロジーの区分別比率を示す。
ネットワークトポロジーは、各機関の拠点(キャンパス)の物理的構成に大きく依存す
るものと考えられる。結果としては、一つのキャンパスのみでネットワークを構成している機関が約 47%と最も多かった。また、主たる拠点を中心に複数の副拠点を接続している機関が次いで多く約 34%であった。その他としてはスター型、系列専門学校と198

対等に接続、自機関で契約のでーたセンターを中心とし複数拠点間を接続、別途独立に拠点を設けている、などの回答があった。

図 Ⅲ-⑦-2 ネットワークトポロジーの区分別比率

図 Ⅲ-⑦-3 に種別ごとの区分別比率を示す。国立大は複数キャンパスで構成されている例が多いためか、複数拠点間を対等あるいは主・副関係で接続している機関が 80%近くで圧倒的に多く、一つの拠点のみで構成している機関は他に比べ極端に少ない。一方、私立大、公立大は半数弱が一つの拠点のみで構成している。

図 Ⅲ-⑦-3 ネットワークトポロジーの区分別比率 (種別区分)

図 Ⅲ-⑦-4 に規模ごとの区分別比率を示す。
規模が大きくなるにつれて、複数拠点での接続が増加する傾向にある。A の規模では199

一つの拠点のみは 0%である。一方、D の規模では一つの拠点のみが 60%近くを占めている。これは、機関の規模が大きくなるにつれて複数キャンパスに物理的に分かれるところが多くなるため、必然的にネットワークトポロジーも分かれる形態になることを示している。

図 Ⅲ-⑦-4 ネットワークトポロジーの区分別比率 (規模区分)

自機関内のネットワーク基盤に関して、複数の拠点を接続している場合の接続方式について質問した。設問は、接続方式について、広域イーサネットサービス、フレッツ等のインターネット接続サービス＋インターネット VPN、専用線接続サービス、専用線(自営ファイバ)を独自に敷設、SINET の L2VPN 等を利用、その他、から複数選択可で選ぶ形式とした。
図 Ⅲ-⑦-5 に拠点間の接続方法の区分別比率を示す。また、表Ⅲ-⑦-1 に各接続方式の帯域別機関数を示す。
フレッツ等のインターネット接続サービスと VPN を組み合わせて接続している機関が最も多く、拠点間接続をしている機関のうちの 47%であった。また、広域イーサネ
ットの利用が比較的多く、拠点間接続をしている機関のうちの 33%であった。
SINET 利用時の DC までの接続方法としては、フレッツ、専用線、光ファイバー芯
線貸しサービス、ダークファイバ、県の専用線サービスなどの回答があった。
またその他としては、県の情報ハイウェイ、ダークファイバの借用、25GHz 無線 LAN
等の回答があった。

200図 Ⅲ-⑦-5 拠点間の接続方法の区分別比率～99Mbps100～499Mbps 500～999Mbps 1～9Gpbs

10Gbps～

広域イーサネットサービス

6

19

0

34

16

インターネット接続サービス＋
インターネットVPN

4

89

0

40

1

専用線接続サービス

6

19

0

34

16

専用線(自営ファイバ)を独自に敷設

1

0

0

13

8

SINETのL2VPN等を利用

0

7

0

18

4

表 Ⅲ-⑦-1 拠点間の各接続方式の帯域別機関数

自機関内のネットワーク基盤に関して、ネットワーク全体のおおよその規模について質問した。具体的には、ネットワーク規模について、VLAN 数を質問する形式とした。
図 Ⅲ-⑦-6 に VLAN 数の区分別比率を示す。
VLAN 数 100 個未満の小規模ネットワークが 67%と最も多い。また、VLAN 数 500
個未満で 90%近くを占める結果であった。一方、VLAN 数を全体として把握できていない機関が 3.7%程度あった。

201

図 Ⅲ-⑦-6

VLAN 数の区分別比率

図 Ⅲ-⑦-7 に VLAN 数の機関種別ごとの比率を示す。
VLAN 数を全体として把握できていない機関が、公立大では 10%と多い結果となった。

図 Ⅲ-⑦-7

VLAN 数の区分別比率 (種別区分)

図 Ⅲ-⑦-8 に VLAN 数の機関規模ごとの比率を示す。
機関の規模に応じて VLAN 数が増加している。

202

図 Ⅲ-⑦-8

VLAN 数の区分別比率 (規模区分)

また、ネットワーク規模について、サブネット数を質問した。
図 Ⅲ-⑦-9 にサブネット数の区分別比率を示す。
VLAN 同様、サブネット数も 100 個未満の小規模構成の機関が 62%と多かった。また、サブネット数を全体として把握できていない機関が 5%弱程度あった。

図 Ⅲ-⑦-9 サブネット数の区分別比率

図 Ⅲ-⑦-10 にサブネット数の機関種別ごとの比率を示す。

203

図 Ⅲ-⑦-10

サブネット数の区分別比率 (種別区分)

図 Ⅲ-⑦-11 にサブネット数の機関規模ごとの比率を示す。
VLAN 同様、機関の規模に応じてサブネット数が増加している。

図 Ⅲ-⑦-11

サブネット数の区分別比率 (規模区分)

自機関内のネットワーク基盤に関して、バックボーンネットワークの性能について質問した。具体的には、バックボーンネットワークの最大帯域について、複数の選択肢によって質問する形式とした。
図 Ⅲ-⑦-12 にバックボーンネットワークの最大帯域の比率を示す。
全体では、1～9Gbps が約 51%で約半数を占めている。また、10Gbps 以上が約 27%と、比較的多い。合わせて 1Gbps 以上は 80%弱であり、自機関内ネットワークのバッ
クボーンの高速化は比較的進んでいる印象がある。

204

図 Ⅲ-⑦-12

バックボーンネットワークの最大帯域

図 Ⅲ-⑦-13 にバックボーンネットワークの種別区分ごとの最大帯域の比率を示す。
国立大では、1Gbps 以上は 95%弱であり、バックボーンの高速化が進んでいる一方、短大では 1Gbps 以上は 65%弱と、高速化が十分進んでいない。また、研究機関では 65%
弱が 10Gbps 以上であり、特に整備が進んでいる。

図 Ⅲ-⑦-13 バックボーンネットワークの最大帯域(種別区分)

図 Ⅲ-⑦-14 にバックボーンネットワークの規模区分ごとの最大帯域の比率を示す。
規模が小さい機関では、ネットワークの集約化が行えるためバックボーンの高速化が比較的容易に実現できると考えられるが、結果としては組織の規模が大きくなるとバックボーンの最大帯域も大きくなる傾向にあり、特に A ランクの組織はすべて 1Gbps 以上となった。
205

図 Ⅲ-⑦-14

バックボーンネットワークの最大帯域(規模区分)

自機関内のネットワーク基盤に関して、エッジルータ・スイッチへの接続について質問した。具体的には、エッジルータ・スイッチへの接続回線の最大帯域について、複数の選択肢によって質問する形式とした。
図 Ⅲ-⑦-15 にエッジルータ・スイッチへの接続回線の最大帯域の比率を示す。
全体では、1～9Gbps が約 51%で約半数を占めている。また、10Gbps 以上が約 27%と、比較的多い。合わせて 1Gbps 以上は 80%弱であり、自機関内ネットワークのバックボーンの高速化は比較的進んでいる印象がある。

図 Ⅲ-⑦-15

エッジルータ・スイッチへの接続の最大帯域

図 Ⅲ-⑦-16 にエッジルータ・スイッチへの接続回線の種別区分ごとの最大帯域の比率を示す。
国立大学では 1Gbps 以上が 94%とかなり高速化が進んでいる。また、研究機関は
206

10Gbps 以上が 67%弱であり、目立って高速化が進んでいる。

図 Ⅲ-⑦-16

エッジルータ・スイッチへの接続の最大帯域(種別区分)

図 Ⅲ-⑦-17 にエッジルータ・スイッチへの接続回線の規模区分ごとの最大帯域の比率を示す。
規模が大きくなるにつれて接続回線の最大帯域が大きくなる傾向にある。特に A ラ
ンクの組織では 97%が 1Gbps 以上であった。規模ランクごと、1～9Gbps の割合が 50%後半から 65%前後までと比較的同程度なのに対し、10Gbps 以上は組織規模が小さくなるにつれて少なくなる傾向であった。

図 Ⅲ-⑦-17

エッジルータ・スイッチへの接続の最大帯域(規模区分)

自機関内のネットワーク基盤に関して、機関共用のサーバ群やクラウドとバックボー
ンネットワークとの接続について質問した。具体的には、バックボーンネットワークとの接続回線の最大帯域について、複数の選択肢によって質問する形式とした。
図 Ⅲ-⑦-18 に共用のサーバ群やクラウドとバックボーンネットワークとの接続回線の最大帯域の比率を示す。
全体では、1～9Gbps が約 58%で約半数を占めている。また、10Gbps も 11%で、計
約 70%が 1Gbps 以上でサーバ等とバックボーンネットワークを接続している。一方で207

100～499Mbps も 19%弱で比較的多く、100Mbps 未満も 6%弱存在する。

図 Ⅲ-⑦-18

サーバ群やクラウドとバックボーンネットワークとの接続の最大帯域

図 Ⅲ-⑦-19 に共用のサーバ群やクラウドとバックボーンネットワークとの種別区分ごとの接続回線の最大帯域の比率を示す。
国立大学では約 41%が 10Gbps 以上となっており、他機関と比較してサーバ群やクラウドのためのネットワーク整備・高速化が進んでいると言える。

図 Ⅲ-⑦-19

サーバ群やクラウドとバックボーンネットワークとの接続の最大帯域(種別区分)

図 Ⅲ-⑦-20 に共用のサーバ群やクラウドとバックボーンネットワークとの規模区分
ごとの接続回線の最大帯域の比率を示す。
A ランクの組織は約 95%、B ランクの組織は約 95%が 1Gbps 以上であり、規模の大208

きい組織でサーバ群やクラウドのためのネットワーク整備・高速化が進んでいると言える。

図 Ⅲ-⑦-20

サーバ群やクラウドとバックボーンネットワークとの接続の最大帯域(規模区分)B) 自機関ネットワークの外部への接続に関して
自機関ネットワークの機関外への接続に関して、接続の方式について質問した。設問
は、接続方式について、SINET に接続、商用 ISP に接続、学術用地域 IXP に接続、その他、から複数選択可で選ぶ形式とした。また、その他については具体的な接続方式についても質問した。
図 Ⅲ-⑦-21 に自機関外との接続方式の区分別比率を示す。
全体的な傾向としてはやはり、国公立大は SINET への接続の比率が高く、私立大は商用 ISP への接続の比率が高かった。また、学術用地域 IXP への接続の比率は小さく、全体で 10%未満であった。

209

図 Ⅲ-⑦-21

自機関外との接続方式の区分別比率

自機関ネットワークの機関外への接続に関して、接続帯域について質問した。具体的には、機関外への接続回線の帯域について、複数の選択肢によって質問する形式とした。
図 Ⅲ-⑦-22 に自機関外との接続回線の帯域の区分別比率を示す。
全体では 500Mbps 未満が 54%であり、学外接続の高速化が遅れている印象がある。
1Gbps は全体で 36%であり比較的多いのに対して 10Gbps は 7%でまだ少ない。国立大
A、B、C では、すべての機関(100%)が 1Gbps 以上で外部と接続していると回答した。
また、国立大 D では、10Gbps も 11%で、計約 70%が 1Gbps 以上でサーバ等とバック
ボーンネットワークを接続している。一方で 100～499Mbps も 19%弱で比較的多く、
100Mbps 未満も 6%弱存在する。

210

図 Ⅲ-⑦-22

自機関外との接続帯域

図 Ⅲ-⑦-23 に自機関外との接続回線の帯域の種別区分ごとの比率を示す。
国立大では、84%が 1Gbps 以上で外部と接続していると回答しており、外部接続の高速化が進んでいると言える。一方それ以外では、1Gbps を超えているのは私立大で38%、公立大で 44%、高専で 28%、短大で 30%と、外部との接続の高速化が遅れている。また、研究機関では 53%が 10Gbps で接続しており、外部接続環境が充実している。

図 Ⅲ-⑦-23

自機関外との接続帯域(種別区分)

図 Ⅲ-⑦-24 に自機関外との接続回線の帯域の規模区分ごとの比率を示す。
組織の規模が大きくなるにつれ外部との接続帯域が大きくなる傾向にあり、A ランクの組織においては約 92%が 1Gbps 以上の接続帯域である。
211

図 Ⅲ-⑦-24

自機関外との接続帯域(規模区分)C) ユーザの自機関内ネットワークへの接続サービスに関してユーザの自機関内ネットワークへの接続サービスに関して、無線ネットワーク接続サ
ービスの整備状況について質問した。設問は、機関規模で管理・運営している無線ネッ
トワーク接続サービスを提供しているか否かを選ぶ形式とした。
図 Ⅲ-⑦-25 に無線ネットワーク接続サービスの提供の有無の区分別比率を示す。
全体の 73%で提供しており、比較的進んでいる。国立大 B と国立大 C では 100%の機関が無線ネットワーク接続サービスを提供していると回答した。それ以外の機関は概ね 70%～80%台の提供率であったが、公立 B が 33%、私立 D が 57%、短大が 60%と若干低めであった。

図 Ⅲ-⑦-25

無線ネットワーク接続サービス212

図 Ⅲ-⑦-26 に無線ネットワーク接続サービスの提供の有無の種別区分ごとの比率を示す。
国立は 93%の機関が無線ネットワーク接続サービスを提供していると回答しており整備が進んでいると言える。それ以外の機関も概ね 70%台の提供率であったが、短大が 60%と若干低めであった。

図 Ⅲ-⑦-26

無線ネットワーク接続サービス(種別区分)

図 Ⅲ-⑦-27 に無線ネットワーク接続サービスの提供の有無の規模区分ごとの比率を示す。
組織の規模が大きくなるにつれてサービス提供率が上がっており、A、B ランクにおいては 87%前後と高くなっている。D ランクの組織は、約 64%と若干低めであった。

図 Ⅲ-⑦-27

無線ネットワーク接続サービス(規模区分)

ユーザの自機関内ネットワークへの接続サービスに関して、eduroam の整備状況について質問した。設問は、eduroam が利用可能か否かを選ぶ形式とした。
図 Ⅲ-⑦-28 に eduroam の利用可能性の区分別比率を示す。
国立大 A が突出しており、約 39%が利用可能となっている。また、国立大 D が 29%と、意外と高い利用可能率となっている。また、研究機関も 27%と比較的高い。
213

図 Ⅲ-⑦-28

eduroam の利用

図 Ⅲ-⑦-29 に eduroam の利用可能性の種別区分での比率を示す。
国立大と研究機関が突出しており、約 26～27%が利用可能となっている。一方、公立大、高専は 0%、短大も 3%と低く、私立大も 5%となっており、国立大以外での普及は進んでいない。

図 Ⅲ-⑦-29

eduroam の利用(種別区分)

図 Ⅲ-⑦-30 に eduroam の利用可能性の規模区分での比率を示す。
A ランクの機関が突出しており、約 27%が利用可能となっている。その他の規模の機関では 5～8%程度と、普及が進んでいない。
214

図 Ⅲ-⑦-30

eduroam の利用(規模区分)

ユーザの自機関内ネットワークへの接続サービスに関して、機関外からの VPN 接続
サービスの整備状況について質問した。設問は、機関外からの VPN 接続サービスを提供しているか否かを選ぶ形式とした。
図Ⅲ-⑦--31 に機関外からの VPN 接続サービスの提供の有無の区分別比率を示す。
国立大 C と私立大 A が、それぞれ 79%と 86%と高い提供率であった。また、国立大の中では国立大 B が 62%と低い率であった。私立大では私立大 A が 86%と、全体で最も高い提供率であった。公立大は低い水準であったが、公立大 C だけは 68%と比較的高い提供率であった。

図Ⅲ-⑦-31

機関外からの VPN 接続サービス

図Ⅲ-⑦-32 に機関外からの VPN 接続サービスの提供の有無の種別区分での比率を示す。
国立大と研究機関が 70%台と高い提供率である一方、高専、短大は 30%台と低い水準であった。
215

図Ⅲ-⑦-32 機関外からの VPN 接続サービス(種別区分)
図Ⅲ-⑦-33 に機関外からの VPN 接続サービスの提供の有無の規模区分での比率を示す。
規模が大きくなるにつれて VPN 接続サービスの提供率が高くなっている。A ランク
では 80%の提供率となっている。

図Ⅲ-⑦-33 機関外からの VPN 接続サービス(規模区分)

D) 自機関外にサーバやクラウドを設置している場合、自機関内ネットワークとの接続に関して
すでに自機関外にサーバやクラウドを設置している場合、自機関内ネットワークとの接続に関して質問した。設問は、機関外のサーバやクラウドと機関内ネットワークとの接続方式について、SINET のネットワークサービスを利用、VPN で接続、専用線で接続、自機関内ネットワークとは接続していない、その他、から複数選択可で選ぶ形式とした。
図Ⅲ-⑦-34 に機関外のサーバやクラウドと学内ネットワークの接続方式の区分別比率を示す。
全般的に、自機関内ネットワークとは接続せずに、直接外部サーバやクラウドのサー216

ビスにユーザが直接接続して利用している機関が約 47%と多かった。自機関内のネッ
トワークと接続している例では、国立大を中心に SINET で接続している機関が比較的多く全体で 18%であったが、私立大では少なかった。一方ソフトウェア VPN またはVPN 装置を利用してインターネット VPN でサーバやクラウドと接続している例は私立大で比較的多く全体では 19%であった。
専用線で接続している際の帯域は、100Mbps 未満が 2 機関、100～499Mbps が 15機関、500～999Mbps が 0 機関、1～9Gpbs が 15 機関、10Gbps 以上が 2 機関それぞれあった。

図Ⅲ-⑦-34

機関外のサーバやクラウドと学内ネットワークとの接続

217

2. 検討結果

1.にて実施したネットワーク管理部署向けアンケート調査結果をまとめると、アカデミッククラウド実現におけるネットワークにおける主な問題点や、今後発生すると考えられる課題等、管理者サイドとして懸念される事項として、以下のものが挙げられていた。
•

クラウド利用増加による外部接続帯域の不足に対する不安 (多数)•

クラウドでのネットワークトラブルの際の対応遅延•

データ漏洩等のセキュリティへの不安•

BYOD的なスマートデバイスの接続をサポートした場合の接続端末数激増への対応•

SINETに接続する専用回線速度アップにかかる費用の高額化•

UTM、IPS、FW等への負荷増大とコスト増大•

多重化、BCP/DR対応とコスト増大•

技術者、管理者等の人材の不足

以上をまとめると、現在の大学等のネットワークにおいてアカデミッククラウドを実現するための課題としては以下のとおりである。
•

全体的に、学内のネットワーク基盤整備は進んできているものの、学外との接続に関しては帯域が不十分•

クラウド化へのネットワーク対応の必要性は認識されているが、コスト面、機能面などメリットが明確でないため、計画が進まない•

コストに見合ったセキュリティレベルの確保•

BYOD、スマートフォン普及、LMS普及など、今後の環境変化による利用者の接続環境への対応•

クラウドを想定した新しいネットワーク技術に関する、管理者、利用者双方
の人材育成

218

3. 要求要件（標準仕様）
アカデミッククラウドの将来像を考慮し、クラウドサービスを支えるネットワーク基盤としての在り方を検討した。その結果、ネットワークのあるべき姿として、以下の項目が必要であると考えられる。
– 高速なバックボーン、接続回線– 全国均一な地域格差のない帯域提供– クラウド間の複数経路構成と柔軟な経路切り換え/多重経路– 機能別、アプリ別、BCP/DR 等の観点でのオーバレイ NW– QoS の確保、ネットワーク利用率の向上– 適切なレベルのネットワークセキュリティ• アカデミッククラウドにおけるネットワークの将来像– 全国的に均一化した超高速ネットワークによる地域差の解消– 柔軟な機能・役割・負荷分散– ネットワーク全体の利用効率向上

クラウドサービス

高等教育，研究機関

図 Ⅲ-⑦-35

アカデミッククラウドにおけるネットワークの将来像

以上のアカデミッククラウドの将来におけるネットワークのあるべき姿をもとにネットワークに係るアカデミッククラウドシステムへの要求要件を以下のようにまとめた。

219

– バックボーン 100Gbps 以上、接続回線 1～10Gbps– 全国的に均一な帯域提供– SDN 等によるオープンで programmable な仮想ネットワーク環境– ネットワークトラフィック状況やクラウド利用状況によるクラウド間の経路切り換え/多重経路– 仮想ネットワーク環境による、機能別、組織カテゴリー別、アプリ別等のオーバ
レイ NW– 多重・冗長化による BCP/DR 等の観点でのネットワークの強靭化– SDN 等で実現される柔軟なネットワーク構成による QoS の確保、ネットワーク
利用率の向上– ネットワーク管理の集中化による管理者負担低減– eduroam の利用拡大による、どこでもクラウド利用可能なネットワークアクセス
環境– 学認との連携によるネットワーク接続認証– クラウド上の個々の情報の重要度に合わせた、必要十分なネットワークセキュリ
ティ提供• 情報の重要度格付けに対応したネットワーク安全性の格付け• 暗号化方式、アクセス可能範囲、セキュリティ対策レイヤ等のセキュリティ
パラメータと、QoS とのトレードオフ調整機能
アカデミッククラウドにおけるネットワークの将来像、あるべき姿をもとに、現状から今後 10 年間の想定ロードマップを以下に示す。
–

１〜３年：現存ネットワーク環境をベースにした基盤整備• 学外接続環境、学内ネットワーク環境の増強• データセンターへの高速接続–

４〜６年：次世代ネットワーク環境をベースにした基盤整備• 広域ネットワークのバックボーンの更なる増強(100Gbps 以上)• 各機関の機関外接続ネットワーク増強に対する支援• 全国規模での超広帯域広域ネットワークの実現–

７〜１０年：ネットワーク仮想化によるクラウド基盤の高度化• 地理的制約にとらわれない論理的なクラウド情報基盤を支えるためのネットワーク仮想化技術• クラウド間の柔軟な通信路制御による性能向上、利用率向上• 次次世代技術の開発

220

⑧ 研究支援に係るアカデミッククラウドシステムの調査検討（概要）本業務を開始するにあたって、キックオフシンポジウムの準備を進めるとともに、年度末までの事業スケジュールに関する検討を行った。大規模アンケート調査に関しては、研究支援に係るアカデミッククラウドシステムの標準仕様をまとめるにあたって必要となる、現状把握や要望事項の収集を目的としたアンケート内容について検討を行った。研究支援に係るアンケート調査においては、部署向けに加えて、研究者個人を対象としたアンケートを実施した。大学ICT推進協議会年次大会におけるアンケート結果暫定報告に合わせて集計を進めた。その後は、最終報告書に掲載する
最終的なアンケート集計結果の処理を進めた。研究支援に係るアカデミッククラウド
に関する海外動向について、インターネットを使っての予備的な調査を進めた。特に詳細な情報の収集が必要とされた米国の動向については、10月5日～13日に渡米し、直接情報交換を行った。さらに、米国以外の動向およびクラウド基盤技術について調査するため、11月4日〜8日に香港で開催されたOpenStack Summitへ参加し、その参加者に対するヒアリングを実施した。アンケート調査の集計結果および海外動向調査の結果を踏まえて、研究支援に係るアカデミッククラウドに必要とされる標準仕様について、その詳細な検討を行った。最終報告書の構成を全体で調整したうえで、上記の業務成果としての研究支援に係るアカデミッククラウドシステムの報告書をまとめた。
1. アンケート調査結果
１−１）サービス部署向け研究支援に係る情報サービス部門向けのアンケート結果について、６８４の組織から回答を得る事ができ、計算資源の共同利用を行っているかどうかについて聞いたところ、
図 Ⅲ-⑧−１に示す通り、行っていると答えたのが全体の約１６％であるが、大規模な国立大学や公立大学では高い割合（国立 A で約６０％、公立 A で１００％）を示している。
さらに、共同利用を行っている組織に対して、利用者数と提供コア数、データ総量について問い合わせたところ、以下の結果となった。
・のべユーザ数合計：42,401 人
・提供コア数：11,634 コア
・データ総量：18.3 PB
共同利用の範囲について問い合わせたところ、図 Ⅲ-⑧−２に示す通り、多くは研究機関内部での共同利用であるが、大規模な国立大学や研究機関においては、国内共同利用（学術機関のみ、企業等民間も含む）をしている割合が高く、さらに１０％程度の組221

織については海外を含む共同利用を実施している。

図 Ⅲ-⑧−１

図 Ⅲ-⑧−２

計算資源の共同利用について

共同利用の範囲について

また、アカデミッククラウドによる集約化の効果を知るため、ピーク利用時と閑散期の資源使用量の違い（ピークを１００％とした場合の閑散期の資源使用量）を問い合わ
222

せたところ、図 Ⅲ-⑧-３に示す通り、大規模な国立大学や研究機関では８０％以上となる組織も多いが、それ以外では４０％未満と答えた組織も多く、集約化による効率化が期待される結果と成っている。

図 Ⅲ-⑧−３

閑散期の資源使用量（ピーク時を１００％とした場合）

データバックアップの現状について問い合わせたところ、図 Ⅲ-⑧−４に示す通り、利用者の責任でバックアップすることとし、原則として対応しない組織が４０％程度存在する。遠隔地へのバックアップについては全体の５％程度の組織しか対応していないが、災害対応など遠隔地へのバックアップへの必要性について問い合わせたところ、全体の 2/3 程度の組織が、可能であれば行いたいとの要望が寄せられた。

223

図 Ⅲ-⑧−４

図 Ⅲ-⑧−５

データバックアップの現状について

災害対応など遠隔地へのバックアップについて

遠隔バックアップを行っている組織に対して、そのバックアップ先について問い合わせたところ、図 Ⅲ-⑧−６に示す通り、自組織で管理運用する遠隔サイトへバックアップしている組織が全体の半数程度、共同利用サービスを利用している組織が１５％程度、
商用データセンターやパブリッククラウドなどを利用している組織が１０％程度とな224

っている。

図 Ⅲ-⑧−６ 遠隔バックアップのバックアップ先について

他組織（他大学、クラウド事業者等）とのシステム連携について問い合わせたところ、
図 Ⅲ-⑧−７に示す通り、現状で行っている組織が全体の 1/4 程度であり、大規模な国立大学や短大で多く見られた。

図 Ⅲ-⑧−７

他組織とのシステム連携について

最後にアカデミッククラウドサービスに対する要望について問い合わせたところ、図Ⅲ-⑧−８に示す通り、特に自組織でクラウドサービスを展開しているような大規模な
225

大学を中心に自組織のシステムで十分であるとの回答も寄せられたが、移行したい、もしくはハイブリッドクラウドとして利用したい、との回答が全体の約半数を占めた。

図 Ⅲ-⑧−８

アカデミッククラウドサービスに対する要望について

自由記述として情報サービス部署から寄せられた意見やコメントについては資料 1.
に示すが、代表的な意見として以下があげられる。
•

資源不足、人員不足、人材確保、運用経費の高騰などが課題•「研究用途の場合，IaaS または PaaS 型のクラウドシステムの提供が望ましい。
それらを利用する場合，自分の研究室にある計算機のように使えると良い。」•「様々なニーズがあがってくると思われますが、クラウドのクラス分けを極力シンプルにして、8 割方のユーザを吸収できる汎用性のあるクラウド展開がよいと思います。
」•「利用データ量が大きいので、データを移動するのがもはや現実的ではなくなってきている。データのあるところに計算資源がないと不便。」•「ビッグデータ解析のために一時的にも大容量の共有ストレージがあるとよい」•「クラウドを構築するのであれば、恒久的な高速学術ネットワークを担保することが必須です。
」•「国内にアカデミッククラウドが整備される事は望ましいが、それによって各
コミュニティに配分されている固有な計算機資源およびそのための予算や人員が削減されることは全く望まれない。」•「2～3 数年で終わる可能性があるなら、現有機器の代替になりにくい。
」

１−２）研究者個人向け
226

研究支援に係る研究者個人向けアンケートについては、科学研究費補助金の全課題（71,755 件）の研究代表者宛に回答を依頼し、その約 1/30 にあたる 2,395 課題の研究
代表者から回答をいただいた。研究種目別の回答数および全体に占める割合（％）は以下の表 Ⅲ-⑧−１の通りとなった。
表 Ⅲ-⑧−１

研究種目別回答数およびその割合（％）

回答数

Q2 研究種目(SA)%（人）

a.特別推進研究3

0.1%

b.特定領域研究

00.0%c.新学術領域研究

53

2.2%

d.基盤研究(S)

17

0.7%

e.基盤研究(A)

83

3.5%

f.基盤研究(B)

257

10.7%

g.基盤研究(C)

1,041

43.5%

185

7.7%

i.若手研究(S)2

0.1%

j.若手研究(A)

54

2.3%

k.若手研究(B)

587

24.5%

l.研究活動スタート支援

72

3.0%

m.奨励研究11

0.5%

n.特別研究促進費

00.0%o.研究成果公開発表

0

0.0%

p.国際情報発信強化

0

0.0%

q.学術定期刊行物

00.0%

r.学術図書00.0%s.データベース

4

0.2%

t.特別研究員奨励費

24

1.0%

u.その他

0

0.0%

v.行政政策研究分野

0

0.0%

w.厚生科学基盤研究分野

1

0.0%

x.疾病・障害対策研究分野

1

0.0%

y.健康安全確保総合研究分野

0

0.0%

z.その他

0

0.0%

h.挑戦的萌芽研究

227

計

2,395

100.0%

当該課題に関するデータの総量について問い合わせたところ表 Ⅲ-⑧−２に示す結果となった。これによると、100TB 以上となる課題が 1%程度、10TB 以上となる課題が 2.5％と割合としては少ないものの、単に文房具的にパソコンを利用するなど、研究に際して情報資源をほとんど使用しない課題も含まれると判断される（100MB 未満が 12％程度を占めている）ことから、課題数としては 10TB 以上のものが 80 件程度の課題がパソコンに収まらない量のデータを取り扱っており、回答割合が 1/30 であることを考えると2,000 件以上の課題ではクラウドシステムによる対応が求められることが分かる。
表 Ⅲ-⑧−２

課題に対するデータ総量

回答数

Q5 課題に関するデータ総量(SA)（人）%a) 100MB 未満,

288

12.0%

b) 100MB 以上 1GB 未満

271

11.3%

c) 1GB 以上 10GB 未満

759

31.7%

d) 10GB 以上 100GB 未満

405

16.9%

e) 100GB 以上 1TB 未満

324

13.5%

f) 1TB 以上 10TB 未満

270

11.3%

g) 10TB 以上 100TB 未満

59

2.5%

h) 100TB 以上

18

0.8%

2,394

100.0%

計

さらにデータ増加量の見込みについて問い合わせたところ、表 Ⅲ-⑧−３の結果となり、毎年 100TB 以上の増加を見込んでいる課題が 10 件以上存在する。
表 Ⅲ-⑧−３

データ増加量の見込み

Q6 データの増加見込み量の推定値(SA)

総量（GB）（年換算）%a) 100MB 未満,

388

16.2%

b) 100MB 以上 1GB 未満

379

15.8%

c) 1GB 以上 10GB 未満

752

31.4%

d) 10GB 以上 100GB 未満

364

15.2%

e) 100GB 以上 1TB 未満

270

11.3%

f) 1TB 以上 10TB 未満

200

8.4%

228

g) 10TB 以上 100TB 未満

27

1.1%

h) 100TB 以上

13

0.5%

2,393

100.0%

計

データ量およびその増加量の見積もりについて、その総量を集計すると以下の結果となった。
・ データ量の合計：7.5 PB （回答数が全体の約 1/30 であることを考慮すると 230
PB）
・ データ増加量の見積もり：3.1PB / 年（上記を考慮すると 93PB / year）
次に、データの主な利用者、およびデータのセキュリティレベルについて調べたとこ
ろ、図 Ⅲ-⑧−９、図 Ⅲ-⑧−１０に示す結果を得た。この結果によると、研究者個人での利用が６割を占めているが、研究機関内部、そのグループ内での利用が約 1/4、コミュニティで共同利用も１０％以上を占めている。データのセキュリティレベルについては、非公開情報が含まれるが個人情報等の重要情報が含まれないという回答が半数以上を占めており、個人情報などの重要情報が含まれる場合は２割程度に留まっている。

図 Ⅲ-⑧−９

データの主な利用者

229

図 Ⅲ-⑧−１０

データのセキュリティレベル

利用者のニーズに関する集計結果は図 Ⅲ-⑧−１１となり、アカデミッククラウド
システムが提供されれば利用したい、パブリッククラウドと組み合わせて使いたい、の両者を合わせると４５％であり、科研全体の件数が 71,755 件であることから、
71,755 x 0.45 = 32,290 と３万件以上の課題での利用が見込まれる。一方、パソコ
ンで十分であるとの回答がほぼ同数存在するが、単に文房具的にパソコンを利用するなど研究に際して情報資源をほとんど使用しない課題も含まれることや、実際にはパブリッククラウドなどのサービスを意識せず使用している場合もあることを考慮す
ると、多くの研究課題でクラウドサービスが実際に使われ、今後さらに利用が進んでいくものと判断される。

230

図 Ⅲ-⑧−１１

アカデミッククラウドに関する利用者のニーズについて

アカデミッククラウドを利用したいと回答した研究者について、その要求資源量を問い合わせたところ、表 Ⅲ-⑧−４の結果を得た。計算資源としては、全体の合計で 10 万
コア以上、ストレージに関しては 118 PB との結果であったが、回答数が全体の 1/30 であるため、単純に 30 倍すると（ランダムサンプリングではないため、理論的に正しい推定でないものの）、コア数で 300 万コア、ストレージで 3.5EB となる。
表 Ⅲ-⑧−４

アカデミッククラウドに対する要求資源量

要求資源量

回答数（人）

平均

最大

合計

計算性能（コア）89

1,187.8

80,000105,718

主記憶 （GB 換算）

113

5,085.6

200,000

574,677

ストレージ（GB 換算）

124957,874.2

100,000,000

118,776,406

研究者個人からのコメントについては、公開を許可したものについて資料 1.にまとめているが、代表的なものを要約すると、以下のような意見が寄せられた。
・ 計算サービスとして、高性能なサーバを利用できるクラウドサービスを求める声が多い。スパコンなど共同利用している計算機の資源が埋まっていることが231

度々あるため、少ない資源でも占有できるサービスを求めている。
・ データがどんどん増えているが、適切な管理方法が分からず、エクセルファイル
でいくつものファイルを保存している。
・ データはそのものは基本的に無料で公開されているものが多いが、必要データのダウンロードに、数ヶ月要し、ボトルネックとなる場合が多い、との指摘あり。
・ 証拠能力のある「研究ノートの電子化」（研究データの保全・を担えるシステム）や、情報漏洩を防止する、高度に暗号化されたファイルシステムの要望あり。
・ Dropbox など商用のオンラインストレージは便利だが、不安も有り、容量制限や料金、転送速度の問題もあるため、高速、大容量、安価で、セキュアなオンラ
インストレージサービスを求める声が多い。
・ データのバックアップについて課題を抱えている例が多い、大容量のデータを簡単かつ安価にバックアップできるようにしてほしいとの要望が多い。特に災害対応まで手が回らず不安を抱えている・ データの中に個人情報等が有るため、守秘性に関する不安あり。
・ 公的なクラウドであれば信頼できるだろうが、私的なクラウドは、情報秘匿に関して信用できるかどうか確証が持てない、との意見あり。
・ 計算機環境の構築に、導入、設置、設定の負担が大きく、管理に関しても、特に外部から不正アクセス対策や、停電などの障害対策に多くの時間が費やされており、負担軽減についてクラウドの期待が大きい。
・ 定常運用を研究室サーバ、非定常運用をクラウドでというハイブリッド運用の要望あり。
・ すべてをクラウド上に構築すると、研究費の切れ目が研究の終了につながってし
まうリスクが大きいとの懸念あり。
・ コラボレーションが促進されるような仕掛けがあるべき、との要望あり。

232

2. 検討結果
研究支援に係るアカデミッククラウドにおいては、効率や経済性に配慮しつつも、研究者から求められる多様なニーズに対応した、最先端の情報環境を提供することを目的にシステム整備を進めるべきである。さらに、アカデミッククラウドは学術分野の研究者や学生に対するサービス提供という側面だけではなく、特に研究については民間や海外との共同研究を促進するとともに、得られた成果を広く国民に公開、還元するなど、社会全体のイノベーションを実現するための基盤となる情報システムとして重要な役割が期待される。
ここでは、研究支援に係るアカデミッククラウドについて、研究支援部署および科学研究費に採択をされている研究者全体に対するアンケート調査の結果および分析、海外におけるアカデミッククラウドやビッグデータ関連の動向調査の結果および分析を行い、求められるシステムの要件、アーキテクチャ、運用体制等について議論する。
アンケート調査のまとめ
アンケート調査の結果、現時点ではパソコンなどでそれぞれの研究者が個別にデータを管理している事例が大半を占めており、データの共有、活用が十分図られていない可能性が高く、アカデミッククラウドにより、研究関連データの蓄積、共有、処理、活用、公開等を積極的に支援していく必要がある。データ処理においてシステム上の制約が研究上の制約とならないよう、クラウドコンピューティングによるスケーラビリティ（規模拡張の容易性）を活用して、研究がパソコンレベルに留まらないよう、バーチャルマ
シンやストレージなどのシステム資源を必要に応じて大規模に利用できるシステム整備が求められる。
現状においても、北海道大学アカデミッククラウドなど、一部の大学においてサービスが提供されているが、数千 VM 程度の規模に留まっていること、既に多くの利用者に利用されていること、今後のビッグデータ処理に多くの資源が必要とされること、海外において大規模なクラウドシステム基盤の整備が進んでおり、それと比較した国際競争力を確保する必要が有ること、等を考慮すると、大規模なクラウド資源により学術研究を支援するシステム環境を整備することが求められる。
さらに、サービス面では、セキュアなストレージや証拠能力のある研究ノートの電子化、研究者間のコラボレーションを促すしくみ、など SaaS や PaaS としてのサービス展
開についても期待が寄せられた。
要求資源量の見積りおよびサービス提供形態について

233

求められる資源量については、特に研究分野の場合には、利用できる資源量の上限まで利用される傾向があり、システム上の上限が実施できる研究内容を制約するという側面もあるため、規模の経済により大規模化するほど効率・経済性が向上することも考慮
すると、可能な限り大規模なものとすることが望ましい。
現状、科学研究費補助金を受領している研究者に限った調査でも 23PB のデータを有すると推定され、今後毎年 9.3PB は増加していくことが予想されるが、通常、データ量が指数関数的に増加していくことを考慮すると、毎年 1.4 倍の増加と見込まれるため、5 年後には 7.5 倍の 173PB となるものと推測される。要求量としても回答全体の合計値
で 118PB となった。今回のアンケートでは科研全体の約 1/30 の課題から回答を得た事を考慮すると、5 年後の推定値では 173PB x 30 = 5.19EB となり、要求量についても 118PB
x 30 = 3.5EB となる。さらに運営費交付金や他省庁の研究費、民間との共同研究など
科学研究費以外の研究費による研究も考慮すると、エクサバイト超級のストレージが必
要になることが容易に想定される。
求められる計算資源の要求量としては、アンケート調査では全体の合計で 10 万コア
以上との結果だったが、回答数が全体の 1/30 であるため、単純に 30 倍するとコア数で300 万コアとなる。これらの資源は計算処理が主流で、現状ではビッグデータ処理で用いられる割合は少ないものと考えられるが、ビッグデータ処理に用いられる Hadoop を前提として推定すると、標準的な環境において 1 コアあたり 1MB/s 程度の処理能力を有するものと判断されるため、エクサバイトのデータを１週間で処理するためには、ビッグデータ処理システムのみで 100 万コアを超える計算資源が必要となる。
以上の推定にあたっては、スパコンなどハイパフォーマンスコンピューティングやゲ
ノム解析など、特定用途の超大規模アプリケーションを含んでいない。アンケート調査においても「様々なニーズがあがってくると思われますが、クラウドのクラス分けを極力シンプルにして、8 割方のユーザを吸収できる汎用性のあるクラウド展開がよいと思います。」とのコメントが寄せられていることも考慮すると、汎用的なアカデミックク
ラウドとしては一般的な利用シナリオをカバーし、特定大規模の用途についてはその用途に最適化されたシステムを整備しつつ一部を共通化し、汎用的なアカデミッククラウ
ドシステムと密に連携可能とすることが現実的である。
システムの整備方針およびパブリッククラウドとの連携について研究支援に係るアカデミッククラウドのシステム整備にあたっては、オープンソース
やオープンコンピュートなどオープンクラウド技術を採用するとともに、システム資源の適度な集約化により経済性を確保するとともに、地理的、技術的の両面である程度の多様性をもったシステム基盤を構築することで、研究者の多様なニーズに応えるとともに、地震など自然災害のリスクや、単一技術に依存するリスクを軽減する必要がある。
234

HPC 分野において、米国ではスパコンセンターが分散配置されており、日本の HPCI(High Performance Computing Infrastructure) や JHPCN (Joint Usage/Research Center
for Interdisciplinary Large-scale Information Infrastructures) においても同様のアプローチがとられている。海外事例においても、CERN やオーストラリアの NeCTAR
ではオープンソースによるクラウド基盤ソフトウェアによりシステムを整備するとともに、ジュネーブとブダペストにデータセンターを分散配置させ高速ネットワークで接続、連携させており、オーストラリアの NeCTAR においても複数の大学に分散配置されたクラウドシステムを相互連携している。また、facebook ではオープンコンピュート技術を採用したデータセンターを分散配置したインフラを構築することで大幅なコスト削減を実現している。
以上の例に見られるように、ある程度の集約化を図りつつ、分散配置したインターク
ラウドシステムとして実現することが現実的な解決策であり、災害対応など物理的なメリットだけではなく、それぞれの拠点毎に特徴的なシステムとすることで様々な利用者のニーズに応えることができる。さらに地域毎の研究者コミュニティを広げる効果が期
待 さ れ 、 MOC (Massachusetts Open Cloud) ・ MGHPCC (Massachusetts Green High
Performance Computing Cloud) に見られるように、地域におけるクラウド拠点データセンターとして、民間も含めたクラウド関連コミュニティを支援する基盤システムとして、地域の情報関連技術の発展に寄与する効果も期待される。
パブリッククラウドとの連携について、定常的に利用される場合にはプライベートク
ラウドで処理した方が経済的であることが多く、パブリッククラウドに大量のデータを保存する場合には、それを取り出すために必要となるネットワーク転送速度やネットワーク帯域課金が問題となるため、定常的に必要とされる計算処理やデータの保存については大学等のプライベートクラウドや共同利用のアカデミッククラウドにおいて実施
し、負荷変動が大きい部分や、単純な Web ホスティング等についてはパブリッククラウ
ドに任せるなど、資源利用の最適化を実現する必要がある。
論点のまとめ・ 現状、パソコンに制約されたデータ処理、情報環境を一新し、クラウドコンピューテ
ィングによる経済性や柔軟性、スケーラビリティ（規模拡張の容易性）を活用することで、ビッグデータやデータサイエンスに係る研究を支援する情報環境を整備すべき。
・ スパコンやゲノム解析など特定用途に関する大規模アプリケーションについては、それぞれのニーズに応じて整備するともに、それ以外の分野を幅広くカバーするシス
テムとして汎用のアカデミッククラウドとして整備し、特定用途向けのシステムと連携できるよう、設計すべきである。
235

・ 数年後をめどに、国内全体でストレージとしてはエクサバイト超級、ビッグデータ処
理システムとしては 100 万 VM 超、ネットワークとしては 100Gbps 超のインフラを整備する必要がある。
・ 災害などのリスク対応や多様性確保などの観点から、地域拠点の連携による全国規模のインタークラウドシステムが必要である。運用にあたっては、大学や研究所の情報センターなど既存組織の運用体制を活用して二重投資を避けつつ、全国共同利用システムとして相互連携することで、それぞれの組織の特徴を生かしたシステム整備を行うべきである。さらに、民間事業者も含めた地域連携により社会全体のイノベーションを促進すべきである。
・ オープンクラウド技術を活用することで効率的かつ経済的なインフラを整備するとともに、用途に応じて国内外のパブリッククラウドサービスも併用するなど、経済性のみならず、研究に必要とされる要求要件やコミュニティへの波及効果も考慮した全体最適の観点からシステムを構築、実現するべきである。
・ 国際連携についても積極的に行い、世界規模のインタークラウドシステムの整備を通した国際競争力の確保に努めるべき。
・ その他、研究者間のコラボレーションを促す仕組みなど、研究活動を支援するサービスやシステムについては、事務分野、教育分野、認証、セキュリティなどとも連携して整備すべき。

236

3. 要求要件（標準仕様）
共通の要求要件
研究支援分野においては、クラウドシステム基盤およびその運用体制等について、以下の要件を満たす必要がある。
•

数年後をめどに必要とされる資源量：エクサバイト超級のストレージ、100 万コ
ア超規模のビッグデータ処理インフラ、100Gbps 超のネットワーク•

スケーラブルなストレージと大規模並列データ処理システムが密に接続され、ビッグデータの連携処理が容易であること。さらに、スパコンやゲノム解析など特定用途向けの大規模システムと密に連携できることが望ましい。

•

オープンクラウド技術を活用することで効率的かつ経済的なインフラを整備するとともに、用途に応じてパブリッククラウドサービスも併用するなど、経済性のみならず、研究に必要とされる要求要件やコミュニティへの波及効果も考慮した全体最適の観点で実現すること。

•

運用体制については、既存組織の体制を活用して運用の継続性を担保しつつ整備し、研究支援体制なども含めた総合的な全国共同利用サービスとして提供すること。また、認証、セキュリティなど管理面では統一的な仕様やポリシーを整備し、準拠すること。

DC 配置モデル
データセンターの配置モデルとして、以下の要件を満たす必要がある。
•

効率化のための資源の集約と、リスク分散・災害対応のための分散化、のバランスをとった地域拠点型の配置を基本として、100Gbps 超の高速ネットワークで相互接続されていること。

サービスモデル
サービスモデルおよびその提供にあたり求められる体制として、以下の要件を満たすこと•

IaaS として研究に必要とされる計算資源の提供を基本とするが、インフラを整備するだけではなく、それを最大限活用するためのプラットフォームやアプリ
ケーションを開発し、PaaS や SaaS として提供するための研究開発を支援する体制を有すること。さらに、民間や国際的な連携を含めた研究者の人的交流を促237

進する体制を整備し、サービスを提供することが望ましい。
10 年間のロードマップ（初期：1～3 年目，中期：4～7 年目，後期：8 年目以降）
初期：投資・構築・システム基盤整備
・ 全国規模でのアカデミッククラウド基盤を大胆な投資により整備し、共同利用
サービスとして展開する。合わせて、全国規模のインタークラウドとして、国際連携や民間との連携も視野に入れつつ、技術開発および人的交流を促進する。
中期：運用・活用・ビッグデータ基盤整備
・ ほぼ全ての学術研究において活用される情報基盤としてアカデミッククラウ
ドを位置づけ、科研等での利用を推奨する。
・ 研究開発に係るほぼ全てのデータを蓄積、処理、活用するビッグデータ基盤として、学術データの相互連携を図る。
長期：技術移転・次世代技術の開発
・ コモディティ部分の民間への技術移転し、展開する。
・ 次世代技術の開発を推進する。

238

⑨ 事業の総合的推進
本委託事業を遂行するに当たり、2013年8月9日にキックオフシンポジウムを開催し、全体的なスケジュールおよび各分野の業務内容等の紹介およびゲストパネリストを招聘しアカデミッククラウドに関する多方面からの意見を聴取した。2013年10月中旬から11月にかけて全国の高等教育研究機関を対象としたアカデミッククラウドに係る大規模アンケート調査を実施した。アンケート調査実施に向け、遠隔会議を開催し各分野の調査項目をとりまとめ検討するとともに、Webアンケートシステムの外部委託を行った。
実施したアンケート調査の集計結果とアカデミッククラウド構築に向けた要求要件（暫定版）について、産業界等多方面からの意見を聴取する目的で2013年12月18日に大学ICT推進協議会年次大会の企画セッションとして中間報告会を開催した。また、産業界から意見を聴取するためのアドバイザリー(資料7. アドバイザリー名簿を参照)の募集を行った。その後、遠隔会議を開催し、各分野におけるアンケート集計および分析結果の取り纏めを行い、標準仕様について全体で検討した。検討結果については、2014年2月13日に開催した最終報告会において報告を行った。全体で検討した最終報告書の構成にしたがって報告書のとりまとめを行った。

239

Ⅳ. 参考文献
セキュリティ分野）[1] ENISA, Cloud Computing: Information Assurance Framework (Nov. 2009).

 http://www.enisa.europa.eu/act/rm/files/deliverables/cloud-computing-inf
ormation-assurance-framework http://www.ipa.go.jp/security/publications/enisa/documents/Cloud%20Infor
mation%20Assurance%20Framework.pdf（日本語訳）[2] ENISA,

Cloud Computing: Benefits, risk and recommendations for information

security (Nov. 2009).
 http://www.enisa.europa.eu/act/rm/files/deliverables/cloud-computing-ris
k-assessment
 http://www.ipa.go.jp/security/publications/enisa/documents/Cloud%20Compu
ting%20Security%20Risk%20Assessment.pdf（日本語訳）[3] NIST, Guidelines on Security and Privacy in Public Cloud Computing, SP 800-144(Dec. 2011).
 http://csrc.nist.gov/publications/nistpubs/800-144/SP800-144.pdf
 http://www.ipa.go.jp/files/000025365.pdf（日本語訳）[4] NIST, The NIST Definition of Cloud Computing, SP 800-145 (Sep. 2011).



http://csrc.nist.gov/publica
tions/nistpubs/800-145/SP800-145.pdf



http://www.ipa.go.jp/files/0
00025366.pdf（日本語訳）[5] NIST, Cloud Computing Synopsis and Recommendations, SP 800-146 (May 2012).

 http://csrc.nist.gov/publications/nistpubs/800-146/sp800-146.pdf
 https://www.ipa.go.jp/files/000025367.pdf（日本語訳）[6] 経済産業省，
クラウドサービス利用のための情報セキュリティマネジメントガイドラインの公表～クラウドサービスの安全・安心な利用に向けて～（2011 年 4 月）．
 http://www.meti.go.jp/press/2011/04/20110401001/20110401001.html[7] 独立行政法人情報処理推進機構，「中小企業のためのクラウドサービス安全利用の手引き」、および「クラウド事業者による情報開示の参照ガイド」（2011 年 4 月），
 http://www.ipa.go.jp/security/cloud/tebiki_guide.html[8] 国立情報学研究所，
国立大学法人等における情報セキュリティポリシー策定について「高等教育機関の情報セキュリティ対策のためのサンプル規程集」（2013 年 7 月）．
 http://www.nii.ac.jp/csi/sp/[9] 高橋健志，Gregory Blanc，門林雄基，Doudou Fall，櫨山寛章，松尾真一郎，マルチ

240

テナントクラウドコンピューティング：セキュリティ上の課題とアプローチ，電子
情報通信学会技術報告，ICSS2011-36，pp.25-32（2011 年 11 月）．
[10] 次世代電子商取引推進協議会，ECにおける情報セキュリティに関する活動報告書

2009 「秘密分散に関する技術ガイドラインおよび秘密分散技術利活用に関するガ
イドライン」（2010 年 3 月）．
 http://www.jipdec.or.jp/archives/ecom/results/h21seika/H21results-10.pdf[11] 広島大学情報セキュリティ推進機構，広島大学クラウドサービス利用ガイドライン

チェックリスト（2013 年 3 月）．
 http://www.media.hiroshima-u.ac.jp/news/cloudguide/[12] サイエンティフィック・システム研究会 移行期にあるネットワークサービスのセキュリティ WG，中間まとめ「高等教育機関・研究機関のためのパブリッククラウド
利用ガイド」（2013 年 9 月）．
 http://www.ssken.gr.jp/MAINSITE/download/wg_report/net-sec/public_cloud/index.html
その他）[1] アカデミッククラウド調査報告書 2012
吉岡 信和 (著), 棟朝 雅晴 (著), 本橋 賢二 (著), 西村 一彦 (著),
谷沢 智史 (著), 横山 重俊 (著)[2] 大学情報システムの再構築に向けて
公益社団法人私立大学情報教育協会 大学情報システム研究委員会[3] アカデミッククラウドに関する海外技術動向調査
国立情報学研究所[4] 大学における最新情報基盤への取り組み ～クラウド導入の手引き書～
国立情報学研究所

241

Ⅴ.

成果の外部への発表

1. 学会等における口頭・ポスター発表(発表題目(口頭・ポスター発表の別、国内・外の別)、発表者、発表した場所(学会名等)、
時期)
1)「コミュニティで紡ぐ大学 ICT 環境としてのアカデミッククラウド」(口頭、国内)、
岡田義広、Cloud Week 2013、平成 25 年 9 月 5 日
2)事務支援に係るアカデミッククラウドの調査と展望(口頭、国内)、柏崎礼生、SINET
及び学認説明会、平成 25 年 11 月 20 日
3)文部科学省委託事業-アカデミッククラウド環境構築に係るシステム研究-「コミュニティで紡ぐ次世代大学 ICT 環境としてのアカデミッククラウド」事業中間報告：認証連携に係るアカデミッククラウドシステムの中間報告(口頭、国内)、山地一禎、
大学 ICT 推進協議会 2013 年度年次大会、平成 25 年 12 月 19 日
4)クラウド時代の認証基盤：アカデミッククラウドに係る認証連携・全体説明(口頭、国内)、山地一禎、大学 ICT 推進協議会 2013 年度年次大会、平成 25 年 12 月 20 日
5)クラウド時代の認証基盤：京都大学の格付けと認証レベルの事例について(口頭、国内)、永井靖浩、大学 ICT 推進協議会 2013 年度年次大会、平成 25 年 12 月 20 日
6)クラウド時代の認証基盤：アカデミッククラウドにおける認証：学認側の TODO(口頭、国内)、佐藤周行、大学 ICT 推進協議会 2013 年度年次大会、平成 25 年 12 月
20 日
7)「アカデミッククラウドの標準仕様と学認」(口頭、国内)、岡田義広、Japan Identity& Cloud Summit (JICS) 2014、平成 26 年 1 月 14 日
8)「アカデミッククラウドが必要とするセキュリティレベル」(口頭、国内)、西村浩二、
Japan Identity & Cloud Summit (JICS) 2014、平成 26 年 1 月 14 日
9)ID パスワードの限界から多要素，IC カード認証の可能性(口頭、国内)、佐藤周行、Japan Identity & Cloud Summit (JICS) 2014、平成 26 年 1 月 14 日
10) アカデミッククラウド(口頭、国内)、山地一禎、関東甲信越ブロック国立大学図書
館協会セミナー、平成 26 年 2 月 20 日
11) 「広島大学クラウドサービス利用ガイドライン説明会」(口頭、国内)、西村浩二、
広島大学クラウドサービス利用ガイドライン説明会、平成 26 年 2 月 5 日
12) 「アカデミッククラウドの標準仕様～「コミュニティで紡ぐ次世代大学 ICT 環境としてのアカデミッククラウド」成果報告～」(口頭、国内)、 岡田義広、大学等におけるクラウドサービス利用シンポジウム 2014、平成 26 年 3 月 31 日
13) 「広島大学事務支援におけるパブリッククラウド活用事例紹介」(口頭、国内)、宮原俊行、大学等におけるクラウドサービス利用シンポジウム 2014、平成 26 年 3 月
31 日

242

2. 学会誌・雑誌等における論文掲載なし
3. 特許・その他
なし

243

Ⅵ.

活動（運営委員会等の活動等）

1. 大規模アンケート調査の実施
以下の図に示すアンケート調査の実施図に従って，全国の国公私立大学並びに公的研究
所(1230 機関)を対象にした大規模調査「アカデミッククラウド環境構築に係るシステム調査」を実施した。

図 アンケート調査の実施図
アンケート調査は以下の日程で実施した。
８月中旬：アンケート内容を検討開始した。Educause CoreData サービス調査，学術基盤
実態調査，学校基本調査，国立大学法人情報系センター協議会調査等を参照しアンケート
調査項目を検討した。
９月中旬：アンケート調査項目（案）を作成した。
９月１９～２５日：アンケート調査項目（案）に対する意見聴取を実施した。産業界からの募集メンバーと AXIES クラウド部会，AXIES CIO 部会に依頼を行った。
９月末～１０月１日：アンケート調査項目を最終決定した。
１０月４日～：業務委託して Web アンケートシステムのデータ入力を開始した。
１０月１５日（火）～１１月１５日（金）：アンケート調査回答期間，延長し 11 月 29 日（金）まで受け付け，12 月 6 日（金）にシステムを閉鎖した。
１２月～：アンケート集計作業，分析等
2. クラウドコンピューティングに関する現状調査244

現状のクラウドコンピューティングに関する技術および事例の調査を 10 月と 11 月に渡り実施した。ヒアリングを行った企業等は以下の通りである。これらのヒアリング結果は，
資料 2.にまとめた。
○10 月実施
ビッグデータ関連（IEEE BigData, Hadoop）, クラウド管理運用（CloudStack）, スト
レージインフラ（facebook）, 大学データセンター連携（Harvard-MIT Data Center），ア
カデミッククラウド構築・運用関連（イギリス：JISC, オランダ：SURFnet），学内クラウド利用関連（Imperial College of London, University of London）○11 月実施分
クラウド管理運用（OpenStack Summit），事務系オープンソース動向（Kuali Days），
ラーニングアナリティクス（Marist College），研究助成団体動向（NSF）
3. シンポジウム等のイベント開催
本事業の紹介および，産業界等からの情報提供を目的として，いくつかイベントを実施した。実施したイベントは以下の通りである。これらのイベントにより，ゲストパネリス
ト等から得られた意見は，資料 4.～6.にまとめて記載している。
○キックオフシンポジウムの開催
日時：平成 25 年 8 月 9 日(金) 13:00～17:00
場所：早稲田大学
内容：事業紹介（各参画機関代表者）
パネルディスカッション「ビッグデータ時代のアカデミッククラウド」（ゲストパネ
リスト：相原玲二，北川源四郎，喜連川優）
参加者：96 名○Cloud Week 2013 での講演発表
日時：平成 25 年 9 月 5 日(木) 10:00～11:30
場所：北海道大学
内容：「コミュニティで紡ぐ次世代大学 ICT 環境としての アカデミッククラウド」 岡田義広（九州大学）「教育学習支援とアカデミッククラウド」 梶田将司（京都大学）「研究支援のためのアカデミッククラウド」 棟朝雅晴（北海道大学）
参加者：約 100 名○本事業の中間報告（於：大学 ICT 推進協議会年次大会・企画セッション）245日時：平成 25 年 12 月 18 日(水)～20 日(金)場所：幕張メッセ国際会議場「コミュニティで紡ぐ次世代大学 ICT 環境としてのアカデミッククラウド」中間報告( 18 日(水) 12:30～15:50 )「学術インタークラウド基盤の実現に向けて」( 12 月 19 日 10:00-11:30 )「クラウド時代の認証基盤」( 12 月 20 日 11:00-12:30 ）参加者：約 100 名○本事業の最終報告会
日時：平成 26 年 2 月 13 日(木) 10:00～16:40
場所：学術総合センター
参加者：約 120 名

246

Ⅶ. 実施体制
別表１

平成２５年度に於ける実施体制

業務項目

担当機関等

①コンテンツ、大学経営およびシステムアーキテクチ 九州大学附属図書館付設教材開発セ

研究担当者
◎○岡田

義広

九州大学理事・副学長

安浦寛人

早稲田大学理事・理工学研究院

深澤良彰(2) コンテンツに係る要素についての調査検討・仕 九州大学大学院芸術工学研究院

藤村

直美

井上

仁

伊東

栄典

筑波大学図書館メディア系

逸村裕

放送大学教育支援センター

山田恒夫

九州大学附属図書館付設教材開発セ

平原

孝明

◎○西村

浩二

佐賀大学総合情報基盤センター

只木進一

神戸学院大学経営学部経営学科

小川賢

ャに係るアカデミッククラウドシステムの調査検討(1) 大学経営・システムアーキテクチャに係る要素についての調査検討・仕様策定の統括

様策定

ンター

九州大学情報基盤研究開発センター(3) コンテンツおよびシステムアーキテクチャに係る要素についての調査検討・仕様策定

〃

〃

ンター
②セキュリティに係るアカデミッククラウドシステム 広島大学情報メディア教育研究セン
の調査検討

ター

③事務支援に係るアカデミッククラウドシステムの調 大阪大学情報推進機構

◎○森原

一郎

柏崎

礼生

玉造

潤史

◎○梶田

将司

査検討
(1) 調査内容の検討、調査結果の分析、報告書の作
成〃〃東京大学情報システム本部④教育支援に係るアカデミッククラウドシステムの調 京都大学学術情報メディアセンター
査検討(1) オープンエデュケーションの観点からの調査・ 京都大学高等教育研究開発推進セン
検討

飯吉

透

ター
大阪大学サイバーメディアセンター

竹村治雄

東京大学情報基盤センター

柴山悦哉

熊本大学総合情報基盤センター

中野裕司

名古屋大学情報基盤センター

松尾啓志⑤認証連携に係るアカデミッククラウドシステムの調 国立情報学研究所学術認証推進室

◎○山地

一禎

中村

素典

京都大学学術情報メディアセンター

永井靖浩

東京大学情報基盤センター

佐藤

周行

査検討
(1) 属性情報の送受信、ユーザ同意に関する調査検
討

247

〃

〃

山形大学大学院理工学研究科⑥データプライバシーに係るアカデミッククラウドシ 慶應義塾大学環境情報学部

伊藤 智博

◎○中村

修

ステムの調査検討(1) 調査内容の検討、課題点の抽出

慶應義塾大学総合政策学部

新保史生

慶應義塾大学法学部

青木淳一

慶應義塾大学法務研究科

磯部哲

慶應義塾大学インフォメーションテ

塚原康仁

慶應義塾大学政策メディア研究科

五味

健太郎

慶応義塾大学環境情報学部

金子康樹⑦ネットワークに係るアカデミッククラウドシステム 東北大学サイバーサイエンスセンタ ◎○菅沼拓夫

(2) 資料収集、整理、調査データの集計・分析

クノロジーセンター本部

の調査検討

ー

（１）分担実施

〃

〃

曽根

秀昭

〃

〃

水木

敬明

〃

〃

阿部

亨

⑧研究支援に係るアカデミッククラウドシステムの調 北海道大学情報基盤センター
査検討

◎○棟朝

雅晴

国立情報学研究所先端ICTセンター

横山重俊

国立情報学研究所GRACEセンター

吉岡信和

東京大学地球観測データ統融合連携

根本

利弘

◎○岡田

義広

平原

孝明

研究機構
⑨事業の総合的推進

九州大学附属図書館付設教材開発センター(1)事業全体の研究補助

九州大学附属図書館付設教材開発センター

注. ◎：業務主任者、○：実施責任者

248

資料 1.

アンケート集計結果

1.1 各アンケート調査項目
ここでは，各分野について，アンケート調査項目の一覧を示す。

コンテンツ分野アンケート（コンテンツサービス部署向け，システム毎回答）
本アンケートは、文部科学省からの委託事業である平成 25 年度国家課題対応型研究開発推進事業・アカデミッククラウド環境構築に係るシステム研究「コミュニティで紡ぐ次世代大学 ICT 環境としてのアカデミッククラウド」におきまして、コンテンツサ
ービスに係るアカデミッククラウドが備えるべき要求要件を明確化し、標準仕様を策定する参考とする目的で、コンテンツサービスに係るデータとサービス状況について調査するものです。本コンテンツ分野に係るアンケートは、コンテンツサービスに係るデー
タとサービスを提供している大学等の図書館や総合研究博物館、広報室等を調査対象としています。教育支援情報サービス部署、研究支援情報サービス部署、ICT サービス部
署、大学評価情報室等を含む事務支援情報サービス部署は対象としていません。
コンテンツサービスに係るデータの収集・蓄積・運用、データ特性とその量および変化の状況やサービス状況等について、データのセキュリティやプライバシーおよびユーザの認証等の状況も含めて、アカデミッククラウド構築における課題や効果を明確化するために必要となる情報を取集するものです。
（注）アカデミッククラウドとは、パブリッククラウドのうち、高等教育機関（全国共同利用情報基盤センター等）が高等教育機関向けに運用するクラウドサービスを指します。
※アンケートの回答は，特に指定がない限り今年度の状況をご記入下さい。
1 ご回答いただく方の所属機関、部局名等をご記入ください。必須
所属機関※大学等の名称［

］

部局

］

［

※補足・伝達事項等ございましたら、設問 3 にお書きください。
2 ICT サービス（データベースを含む）のシステム毎に、以下の問いにお答えください。
※利用者数や構成等が異なるシステムを他に使用されている場合は、別の情報として受付いたしますので、お手数でございますが、設問 3 終了後、あらためて同テー
マアンケートにご回答くださいますようお願い申し上げます。既存データは上書き
249

されることなく、新しいレコードが登録されます。
2.1 該当するシステム名称とそのサービス内容をご記入ください。
システム名称： ［］サービス内容： ［］2.2 システムの利用者の範囲と数はどの程度でしょうか。
 自機関内利用者数☐～1,000 ☐～5,000 ☐～10,000 ☐10,001 以上■ 自機関外利用者数☐～1,000 ☐～5,000 ☐～10,000 ☐10,001 以上
 ピーク時の同時利用者数☐～100 ☐～500 ☐～1000 ☐～5,000 ☐5,001 以上
2.3 システムが利用している計算機資源の構成はどうなっていますか。
 システムで独自に管理するサーバ（独自にサーバ仮想化を行っている場合
は仮想サーバでお答えください）
サーバ数[

]台

]個 総メモリ量[

総コア数[

]GB

 自機関内のクラウドサービス等が提供する仮想サーバ
サーバ数[

]台

]個 総メモリ量[

総コア数[

]GB

 パブリッククラウドサービスが提供する仮想サーバ
サーバ数[

]台

]個 総メモリ量[

総コア数[

]GB

 他機関の情報基盤センター等のアカデミッククラウドサービスが提供する
仮想サーバ
サーバ数[

]台

]個 総メモリ量[

総コア数[

 その他 [
サーバ数[

]GB
]

]台

]個 総メモリ量[

総コア数[

]GB

2.4 今後、パブリッククラウドサービスが提供する仮想サーバ等の計算機資源(IaaS
or PaaS)を利用する計画、あるいは、意向がありますか。
☐既に利用していて、今後も継続して利用したい☐既に利用していて、今後さらに拡大したい☐既に利用しているが、今後は縮小、または、利用をやめたい
理由：［☐利用する計画がある [］]年後☐積極的に利用したい☐できれば利用したい☐今後も利用しない、あるいは、課題があって利用するのは難しい
理由：［

］
250

☐その他 ［］2.5 今後、アカデミッククラウドサービスとして仮想サーバ等の計算機資源(IaaS or
PaaS)が提供された場合、利用する意向がありますか。
☐積極的に利用したい☐できれば利用したい☐今後も利用しない、あるいは、課題があって利用するのは難しい
理由：［］☐その他 ［］2.6 システムで保有するデータの総量は現状でどの程度でしょうか。
※回答欄の左側 BOX には数字を記入、その右隣の BOX では単位を選択下さい。
[]□GB □TB

2.7 当該サービスにログインするためのアカウント管理について該当するものをお選びください（複数回答可）。
☐自機関内の統合認証情報（LDAP やアクティブディレクトリなど）と直接接
続☐バッチ処理などにより自機関内の統合認証情報からアカウント情報を同期☐SAML（学認と同じ認証プロトコル）あるいはシボレスによる認証連携☐その他：［］2.8 データのバックアップ先について該当するものをお選びください（複数選択可）。
☐バックアップを取得していない☐自部署で管理するハードディスクやバックアップメディア等☐自機関内のクラウドサービスを利用☐パブリッククラウドサービスを利用☐NII や他機関の図書館が提供する共同利用サービスを利用☐他機関の情報基盤センター等が提供する共同利用サービスを利用
☐その他［

］

2.9 当該サービスのソフトウェアについて、該当するものを選択し、関連する情報を記入、あるいは、選択してください。
☐フルスクラッチで開発している☐オープンソースを活用して開発している
 利用しているオープンソース名称（できればお答えください）［］☐商用パッケージソフトウェアを利用している
 商用パッケージ名称（できればお答えください）［］ カスタマイズの度合い（一つ選択してください）251☐殆どカスタマイズせずに利用している☐業務に合わせて少しカスタマイズを行っている☐業務に合わせて大幅にカスタマイズを行っている☐SaaS 等のパブリックサービスを利用している
 利用しているサービス名称（できればお答えください）［］☐その他 ［］2.10 今後、SaaS 等のパブリックサービス（NII や他機関の図書館が提供するサービスおよび他機関の情報基盤センター等が提供するサービスも含めて）を利用する計画、あるいは、意向がありますか。
☐既に利用していて、今後も継続して利用したい☐既に利用しているが、今後は利用をやめたい
理由：［☐利用する計画がある

］
[

]年後

☐積極的に利用したい☐将来的にも利用しない、あるいは、課題があって利用するのは難しい
理由：［］☐その他 ［］2.11 BCP 対策の必要性、状況、計画について、該当するものをお選びください。
☐

A. 災害発生時でも継続してシステムが稼働可能なレベルで BCP 対策が
必要である

☐

B.データが維持でき、数日～1 週間程度でシステムを再構築可能なレベ
ルで BCP 対策が必要である（データが維持できれば、システムが数
日～1 週間程度停止することは許容できる）☐☐

C. BCP 対策は必要ない
理由：
［

］

D. その他 ［］2.12 設問 2.11 で A または B を選んだ場合にお答えください。
☐既に BCP 対策を実施している☐現在は対策できていないが、実施する計画がある[]年後☐計画はないが将来実施したい◆実施に当たっての課題や要望がありましたら記入してください：［］

2.13 データや計算資源の管理運用について該当する項目を選び、１年間にかけている大よその稼働量（人年：小数可）を記入してください。
☐専任の教職員を配置して管理している：[
252

] 人年

☐クラウド事業者や管理委託業者に管理を任せている：[

] 人年

☐その他
[

]：[

] 人年

2.14 その他、アカデミッククラウドに対する要望事項がありましたらご記入ください。
［］

3 その他、ご意見等ございましたらお書きください。
[]

質問は以上です。
ご協力、ありがとうございました。

Ver1018

253

ICT サービス分野アンケート（ICT サービス部署向け，システム毎回答）
本アンケートは、文部科学省からの委託事業である平成 25 年度国家課題対応型研究開発推進事業・アカデミッククラウド環境構築に係るシステム研究「コミュニティで紡ぐ次世代大学 ICT 環境としてのアカデミッククラウド」におきまして、ICT サービスに係るアカデミッククラウドが備えるべき要求要件を明確化し、標準仕様を策定する参考とする目的で、ICT サービスに係るデータとサービス状況について調査するものです。
本 ICT サービス部署向けアンケートは、ICT サービス（メールサービス，ストレージサービス，SNS，グループウェア，各種サーバのホスティングサービス、その他）を機関全体に対して提供している大学等の情報基盤センターや情報統括本部等を調査対象としています。教育支援情報サービス部署、研究支援情報サービス部署、大学評価情報室等を含む事務支援情報サービス部署は対象としていません。
ICT サービスに係るデータの収集・蓄積・運用、データ特性とその量および変化の状況やサービス状況等について、データのセキュリティやプライバシーおよびユーザの認証等の状況も含めて、アカデミッッククラウド構築における課題や効果を明確化するために必要となる情報を取集するものです。
（注）アカデミッククラウドとは、パブリッククラウドのうち、高等教育機関（全国共同利用情報基盤センター等）が高等教育機関向けに運用するクラウドサービスを指します。
※アンケートの回答は，特に指定がない限り今年度の状況をご記入下さい。

1 ご回答いただく方の所属機関、部局名等をご記入ください。

必須

所属機関※大学等の名称[

]

[

]

部局

※補足・伝達事項等ございましたら、設問 4 にお書きください。

2 ICT サービスのシステムに係らず一度だけ以下にお答えください。
2.1 自機関内の ICT サービスにログインするためのアカウント管理の一元化（認証統合）を行っていますか。
☐認証統合を実現している☐認証統合を検討中☐認証統合の予定はない
254

2.2 認証統合を実現している場合、認証情報（LDAP、AD など）の冗長化を行っていますか。
☐単一の物理的な場所におけるサーバサイドの冗長化済み☐複数の物理的な場所やサイトによる地理的な冗長化済み☐冗長化を検討中☐冗長化の予定はない
2.3 認証統合を実現されている場合、シングルサインオンを実現するための認証連携システムを導入していますか。
☐導入して自機関内のみで利用☐導入して自機関内に加え、学認のサービスにも利用☐学認のサービスにのみ利用☐導入を検討中☐導入する予定はない
2.4 認証連携システム（IdP）の冗長化は行っておりますか。
☐単一の物理的な場所におけるサーバサイドの冗長化済み☐複数の物理的な場所やサイトによる地理的な冗長化済み☐冗長化を検討中☐冗長化の予定はない
3 ICT サービス（メールサービス，ストレージサービス，SNS，グループウェア，各種
サーバのホスティングサービス、その他）のシステム毎に、以下の問いにお答えください。
3.1 該当する ICT サービスは以下のどれに相当しますか。これから回答されるサービスが、複数に相当する場合は複数選択してください。
※利用者数や構成等が異なるサービスを他に使用されている場合は、別の情報として受付いたしますので、お手数でございますが、設問 4 終了後、あらためて同テーマのアンケートにご回答くださいますようお願い申し上げます。
既存データは上書きされることなく、新しいレコードが登録されます。
☐メールサービス☐ストレージサービス☐SNS☐グループウェア☐各種サーバのホスティングサービス
]

☐その他[

255

3.2 システムの利用者数はどの程度でしょうか。
 自機関内総利用者数☐～1,000 ☐～5,000 ☐～10,000 ☐10,001 以上
 自機関外総利用者数☐～1,000 ☐～5,000 ☐～10,000 ☐10,001 以上
 ピーク時の同時利用者総数☐～100 ☐～500 ☐～1000 ☐～5,000 ☐5,001 以上
3.3 システムが利用している計算機資源の構成はどうなっていますか。
 システムで独自に管理するサーバ（独自にサーバ仮想化を行っている場合
は仮想サーバでお答えください）
サーバ数[

]台

]個 総メモリ量[

総コア数[

]GB

 自機関内のクラウドサービス等が提供する仮想サーバ
サーバ数[

]台

]個 総メモリ量[

総コア数[

]GB

 パブリッククラウドサービスが提供する仮想サーバ
サーバ数[

]台

]個 総メモリ量[

総コア数[

]GB

 他機関の情報基盤センター等のアカデミッククラウドサービスが提供する
仮想サーバ
サーバ数[

]台

]個 総メモリ量[

総コア数[

]GB

 その他 [
サーバ数[

]
]台

]個 総メモリ量[

総コア数[

]GB

3.4 今後、パブリッククラウドサービスが提供する仮想サーバ等の計算機資源（IaaS
or PaaS）を利用する計画、あるいは、意向がありますか。
☐既に利用していて、今後も継続して利用したい☐既に利用していて、今後さらに拡大したい☐既に利用しているが、今後は縮小、または、利用をやめたい]

理由：[☐利用する計画がある []年後☐積極的に利用したい☐できれば利用したい☐今後も利用しない、あるいは、課題があって利用するのは難しい
理由：[]☐その他 []

3.5 今後、アカデミッククラウドサービスとして仮想サーバ等の計算機資源(IaaS or
PaaS)が提供された場合、利用する意向がありますか。
☐積極的に利用したい☐できれば利用したい256☐今後も利用しない、あるいは、課題があって利用するのは難しい
理由：[

]

☐その他[

]

3.6 システムで保有するデータの総量は現状でどの程度でしょうか。
[] ☐ GB □TB

3.7 当該サービスにログインするためのアカウント管理について該当するものをお選びください（複数回答可）。
☐自機関内の統合認証情報（LDAP やアクティブディレクトリなど）と直接接
続☐バッチ処理などにより自機関内の統合認証情報からアカウント情報を同期☐SAML（学認と同じ認証プロトコル）あるいはシボレスによる認証連携]☐その他：[

3.8 データのバックアップ先について該当するものをお選びください（複数選択可）。
☐バックアップを取得していない☐自部署で管理するハードディスクやバックアップメディア等☐自機関内のクラウドサービスを利用☐パブリッククラウドサービスを利用☐他機関等の情報基盤センター等が提供する共同利用サービスを利用
]

☐その他[

3.9 当該サービスのソフトウェアについて、該当するものを選択し、関連する情報を記入、あるいは、選択してください。
☐フルスクラッチで開発している☐オープンソースを活用して開発している
 利用しているオープンソース名称（できればお答えください）：[]☐商用パッケージソフトウェアを利用している
 商用パッケージ名称（できればお答えください）：[] カスタマイズの度合い（一つ選択してください）：☐殆どカスタマイズせずに利用している☐業務に合わせて少しカスタマイズを行っている☐業務に合わせて大幅にカスタマイズを行っている☐SaaS 等のパブリックサービスを利用している
 利用してサービス名称（できればお答えください）：[]☐その他 []
257

3.10 今後、SaaS 等のパブリックサービス（他機関の情報基盤センター等が提供するサービスも含めて）を利用する計画、あるいは、意向がありますか。
☐既に利用していて、今後も継続して利用したい☐既に利用しているが、今後は利用をやめたい]

理由：[☐利用する計画がある[]年後☐積極的に利用したい☐将来的にも利用しない、あるいは、課題があって利用するのは難しい
理由：[]☐その他 []

3.11 BCP 対策の必要性、状況、計画について、該当するものをお選びください。
☐

A. 災害発生時でも継続してシステムが稼働可能なレベルで BCP 対策が

必要である
☐

B. データが維持でき、数日～1 週間程度でシステムを再構築可能なレベ

ルで BCP 対策が必要である（データが維持できれば、システムが数日～1 週間程度停止することは許容できる）☐

C. BCP 対策は必要ない
]

理由：[
☐

D. その他 []3.12 3.11 で A または B を選んだ場合にお答えください。
☐既に BCP 対策を実施している☐現在は対策できていないが、実施する計画がある[]年後☐計画はないが将来実施したい◆実施に当たっての課題や要望がありましたら記入してください：[]

3.13 データや計算資源の管理運用について該当する項目を選び、１年間にかけている大よその稼働量（人年：小数可）を記入してください。
☐教職員を配置して管理している：[] 人年☐クラウド事業者や管理委託業者に管理を任せている：[

] 人年

☐その他
[ここをクリックしてテキストを入力してください。]：[] 人年

3.14 その他、アカデミッククラウドに対する要望事項がありましたらご記入くださ]い。[
4 その他、ご意見等ございましたらお書きください
258

[

]

質問は以上です。
ご協力、ありがとうございました。

Ver1018259

経営分野アンケート（経営に係る情報サービス部署向け，システム毎回答）
本アンケートは、文部科学省からの委託事業である平成 25 年度国家課題対応型研究開発推進事業・アカデミッククラウド環境構築に係るシステム研究「コミュニティで紡ぐ次世代大学 ICT 環境としてのアカデミッククラウド」におきまして、経営に係る情報サービスにおいてアカデミッククラウドが備えるべき要求要件を明確化し、標準仕様を策定する参考とする目的で、経営に係るデータとサービス状況について調査するものです。本経営分野に係るアンケートは、認証評価のためのデータや IR 等機関経営に係るデータとサービスを提供している大学等の評価情報室、企画部等を調査対象としています。
経営に係るデータの収集・蓄積・運用、データ特性とその量および変化の状況やサー
ビス状況等について、データのセキュリティやプライバシーおよびユーザの認証等の状況も含めて、アカデミッッククラウド構築における課題や効果を明確化するために必要となる情報を取集するものです。
（注）アカデミッククラウドとは、パブリッククラウドのうち、高等教育機関（全国共同利用情報基盤センター等）が高等教育機関向けに運用するクラウドサービスを指します。
※アンケートの回答は，特に指定がない限り今年度の状況をご記入下さい。

1 ご回答いただく方の所属機関、部局名等をご記入ください。

必須

所属機関※大学等の名称［

］

部局

］

［

※補足・伝達事項等ございましたら、設問 3 にお書きください。
2 業務で使用しているシステム毎に、以下の問いにお答えください。
※利用者数や構成等が異なるシステムを他に使用されている場合は、別の情報として受付いたしますので、お手数でございますが、設問 3 終了後、あらためて同テーマアンケートにご回答くださいますようお願い申し上げます。既存データは上書
きされることなく、新しいレコードが登録されます。
2.1 該当するシステム名称と業務内容をご記入ください。
システム名称： ［

］

業務内容：

］

［
260

2.2 システムの利用者数はどの程度でしょうか。
 総利用者数☐～1,000 ☐～5,000 ☐～10,000 ☐10,000 以上
 ピーク時の同時利用者総数☐～100 ☐～500 ☐～1000 ☐～5,000 ☐5,001 以上
2.3 システムが利用している計算機資源の構成はどうなっていますか。
 システムで独自に管理するサーバ（独自にサーバ仮想化を行っている場合
は仮想サーバでお答えください）
サーバ数[

]台

]個 総メモリ量[

総コア数[

]GB

 自機関内のクラウドサービス等が提供する仮想サーバ
サーバ数[

]台

]個 総メモリ量[

総コア数[

]GB

 パブリッククラウドサービスが提供する仮想サーバ
サーバ数[

]台

]個 総メモリ量[

総コア数[

]GB

 他機関の情報基盤センター等のアカデミッククラウドサービスが提供する
仮想サーバ
サーバ数[

]台

]個 総メモリ量[

総コア数[

 その他 [
サーバ数[

]GB
]

]台

]個 総メモリ量[

総コア数[

]GB

2.4 今後、パブリッククラウドサービスが提供する仮想サーバ等の計算機資源（IaaS
or PaaS）を利用する計画、あるいは、意向がありますか。
☐既に利用していて、今後も継続して利用したい☐既に利用していて、今後さらに拡大したい☐既に利用しているが、今後は縮小、または、利用をやめたい
理由：［☐利用する計画がある [］]年後☐積極的に利用したい☐できれば利用したい☐今後も利用しない、あるいは、課題があって利用するのは難しい
理由：［］☐その他 ［］2.5 今後、アカデミッククラウドサービスとして仮想サーバ等の計算機資源（IaaS
or PaaS）が提供された場合、利用する意向がありますか。
☐積極的に利用したい☐できれば利用したい☐今後も利用しない、あるいは、課題があって利用するのは難しい
理由：［

］
261

☐その他［］2.6 システムで保有するデータの総量は現状でどの程度でしょうか。
[] ☐ GB □TB

2.7 当該サービスにログインするためのアカウント管理について該当するものをお選びください（複数回答可）。
☐自機関内の統合認証情報（LDAP やアクティブディレクトリなど）と直接接
続☐バッチ処理などにより自機関内の統合認証情報からアカウント情報を同期☐SAML（学認と同じ認証プロトコル）あるいはシボレスによる認証連携☐その他：［］2.8 データのバックアップ先について該当するものをお選びください（複数選択可）。
☐バックアップを取得していない☐自部署で管理するハードディスクやバックアップメディア等☐自機関内のクラウドサービスを利用☐パブリッククラウドサービスを利用☐他機関の情報基盤センター等が提供する共同利用サービスを利用
☐その他［

］

2.9 当該サービスのソフトウェアについて、該当するものを選択し、関連する情報を記入、あるいは、選択してください。
☐フルスクラッチで開発している☐オープンソースを活用して開発している
 利用しているオープンソース名称（できればお答えください）：［］☐商用パッケージソフトウェアを利用している
 商用パッケージ名称（できればお答えください）：［］ カスタマイズの度合い（一つ選択してください）：☐殆どカスタマイズせずに利用している☐業務に合わせて少しカスタマイズを行っている☐業務に合わせて大幅にカスタマイズを行っている☐SaaS 等のパブリックサービスを利用している
 利用しているサービス名称（できればお答えください）：［］☐その他 ［］2.10 今後、SaaS 等のパブリックサービス（他機関の情報基盤センター等が提供するサービスも含めて）を利用する計画、あるいは、意向がありますか。
262☐既に利用していて、今後も継続して利用したい☐既に利用しているが、今後は利用をやめたい
理由：［☐利用する計画がある

］
[

]年後

☐積極的に利用したい☐将来的にも利用しない、あるいは、課題があって利用するのは難しい
理由：［］☐その他 ［］2.11 BCP 対策の必要性、状況、計画について該当する項目をお選びください。
☐

A. 災害発生時でも継続してシステムが稼働可能なレベルで BCP 対策が

必要である
☐

B. データが維持でき、数日～1 週間程度でシステムを再構築可能なレベ

ルで BCP 対策が必要である（データが維持できれば、システムが数日～1 週間程度停止することは許容できる）☐

C. BCP 対策は必要ない
理由：
［

☐

］

D. その他 ［］2.12 2.11 で A または B を選んだ場合にお答えください。
☐既に BCP 対策を実施している☐現在は対策できていないが、実施する計画がある[]年後☐計画はないが将来実施したい◆実施に当たっての課題や要望がありましたら記入してください：［］

2.13 データや計算資源の管理運用について該当する項目を選び、１年間にかけている大よその稼働量（人年：小数可）を記入してください（複数回答可）。
☐教職員を配置して管理している：[] 人年☐クラウド事業者や管理委託業者に管理を任せている：[

] 人年

☐その他
［

］：[

] 人年

2.14 その他、アカデミッククラウドに対する要望事項がありましたらご記入してく
ださい。
［

］

3 その他、ご意見等ございましたらお書きください
[

]

263

質問は以上です。
ご協力、ありがとうございました。

Ver1018264

セキュリティ分野アンケート（セキュリティに係る機関代表部署向け）

本アンケート調査は、文部科学省からの委託事業である平成 25 年度国家課題対応型研究開発推進事業・アカデミッククラウド環境構築に係るシステム研究「コミュニティで紡ぐ
次世代大学 ICT 環境としてのアカデミッククラウド」において、セキュリティ分野に係るアカデミッククラウドに対する要求仕様を策定する参考とさせていただくため、貴組織において情報セキュリティを担当されている部局等の担当者に対して、規則等の整備・運用
状況やクラウドサービスの利用状況、アカデミッククラウドに対する要望事項等についてお伺いするものです。
セキュリティ分野では、アカデミックな組織がパブリッククラウドサービス（自組織以外が運用するクラウドサービスで、アカデミッククラウドを含みます）を利用する際に確認すべき事項をまとめ、これからパブリッククラウドサービスを利用しようとする組織または個人が、それらを簡単に確認できるようにするためのガイドラインおよびチェックリ
ストを作成します。このガイドラインおよびチェックリストは、逆の見方をすればパブリッククラウドサービスに対する要求要件であるとも言えます。
本アンケートにより、アカデミックな組織やその構成員の情報セキュリティおよびパブリッククラウドサービスの利用に対する意識や対策に関する現状の問題点を明らかにすると同時に、アカデミッククラウドに求められる要件を調査することで、上記と合わせてア
カデミッククラウドが備えるべき機能等（標準仕様）を明確にすることを目指します。
ご協力のほど、よろしくお願いいたします。
（注）アカデミッククラウドとは、パブリッククラウドのうち、高等教育機関（全国共同利用情報基盤センター等）が高等教育機関向けに運用するクラウドサービスを指します。
※アンケートの回答は，特に指定がない限り今年度の状況をご記入下さい。

1. ご回答いただく方の所属機関、部局名等をご記入ください。 必須

所属機関※大学等の名称[

]

[

]

部局

※補足・伝達事項等ございましたら、設問 9 にお書きください。

2. 貴機関では、情報システムの運用に関する諸規則（アカウントの運用方法やパスワードの設定方法等のセキュリティに関するポリシー）を定めていますか。（いずれかひとつ）
265☐ 定めている☐ 定めていない → 3 にお進みください
2.1. 規則の作成にあたり、参考にしたものはありますか。（いずれかひとつ）☐ 高等教育機関の情報セキュリティ対策のためのサンプル規定集（参考 URL：http://www.nii.ac.jp/csi/sp/）☐ 特に参考にしたものはない☐ その他[]

2.2. 情報システムの運用に関する諸規則の中で、情報の格付け（重要度に応じた取扱い）に関する事項を定めていますか。
（いずれかひとつ）☐ 定めている☐ 定めていない
2.3. 情報システムの運用に関する諸規則の中で、情報処理を外部委託する場合（パブリック
クラウドサービスを利用する場合を含みます）に関する事項を定めていますか。（いずれかひとつ）☐ 定めている☐ 定めていない
2.4. 貴機関では、情報システムの運用に関する諸規則を構成員に周知するための教育を行っていますか。行っている場合、実施状況（対象者や内容、頻度等）についてご記入ください。
（いずれかひとつ）☐ 行っている
実施状況[]☐ 行っていない2.5. 貴機関では、情報セキュリティマネジメントシステム（ISMS）認証を取得していますか。あるいは取得を予定していますか。
（いずれかひとつ）（参考 URL：http://www.isms.jipdec.or.jp）☐ 取得している☐ 取得を予定している☐ 取得する予定はない☐ 検討中☐ 未定、わからない266

3. 貴機関で過去 1 年間に発生したセキュリティインシデントの件数と内容について、差し支えのない範囲でご記入ください。
（いずれかひとつ）☐ 発生した
件数[

]

内容[

]

☐ 発生していない
4. 貴機関では、現在パブリッククラウドサービスを利用していますか。あるいは今後利用する予定がありますか。
（いずれかひとつ）☐ 機関全体で利用している☐ 一部のサービスで利用している☐ 利用していないが、今後利用する予定がある☐ 利用する予定はない → 5 へお進みください☐ 未定、わからない → 5 へお進みください
4.1. 利用している、あるいは利用を予定しているパブリッククラウドサービスは何ですか。
差し支えのない範囲でご記入ください。

[]

4.2. 利用を決めた、あるいは利用を決める際の要件は何ですか。
（複数選択可）☐ 既存システムよりコストが安いこと☐ 初期導入コストが安価であること☐ 資産、保守体制を持つ必要がないこと☐ システムの構成変更が迅速に対応できること☐ システムの拡張性（スケーラビリティ）が高いこと☐ サービスの信頼性が高いこと☐ システムベンダーに提案されたから☐ ライセンス管理が楽であること☐ 情報漏洩等に対するセキュリティが高くなること☐ 安定性、可用性が高くなること☐ サービスのラインアップが充実していること☐ 導入スピードが速いこと☐ どこでもサービスを利用できること☐ 機器を選ばずに同様のサービスを利用できること☐ いつでも利用停止できること☐ 所属機関の諸規則を満たしていること
267

☐ ISMS 認証（2.5 参照）等を取得していること☐ その他[]・・

5. （設問 4 で「機関全体で利用している」以外を選択された方にお尋ねします。
）
パブリッククラウドサービスを利用しない、あるいは利用を妨げている理由は何ですか。
（複数選択可）☐ クラウドの導入に伴う既存システムの改修コストが大きい☐ クラウドの導入によって所属機関の諸規則との整合性に支障をきたす☐ 通信費用がかさむ☐ ニーズに応じたアプリケーションのカスタマイズができない☐ ネットワークの安定性に対する不安がある☐ 情報漏洩などセキュリティに不安がある☐ 法制度が整っていない☐ 必要がない☐ メリットが分からない、判断できない☐ その他[]

6. 貴機関の構成員がパブリッククラウドサービスを利用しているか把握していますか。 利用している場合、情報の重要度を考慮した上で利用していると思いますか。
（いずれか
ひとつ）

☐ 考慮した上で利用している☐ 考慮せず利用している☐ 利用していない☐ 把握していない
7. アカデミッククラウドを利用したいと思いますか。
（いずれかひとつ）☐ すでに利用している☐ 利用したい☐ 条件によっては利用したい☐ 利用したくない☐ わからない、判断できない
8. 設問 7 のように回答した理由は何ですか。設問 4.2, 設問 5 の選択肢等を参考に、アカデ
ミッククラウドに求める要件、期待すること、問題点等をご記入ください。

[]

9. その他、ご意見等ございましたらお書きください
[

]
268

質問は以上です。
ご協力、ありがとうございました。

Ver1018

参考資料
貴機関の構成員(教職員等)への情報システムの運用に関する諸規則の周知状況(設問 2)や、構成員によるパブリッククラウドサービスの利用状況(設問 6)を調査することを想定したアンケート例を作成しました。ご自由にお使いください。

参考資料 セキュリティに関する構成員向けアンケート調査
第1版

2013.09.18-2

1 ご回答いただく方の部署・お名前をご記入ください。
[

]

お名前 [

]

部署

2 あなたの所属機関では、情報システムの運用に関する諸規則（セキュリティポリシー）を定めていますか？（いずれかひとつ）☐ はい☐ いいえ → 5 にお進みください☐ わからない → 5 にお進みください
3 あなたの所属機関の情報システムの運用に関する諸規則の中で、情報の格付け（重要度に応じた取扱い）に関する事項を定めていますか？（いずれかひとつ）
☐ はい
☐ いいえ
☐ わからない
4 あなたの所属機関の情報システムの運用に関する諸規則の中で、情報処理を外部委託する
場合（クラウドサービスを利用する場合を含みます）に関する事項を定めていますか？
269

（いずれかひとつ）
☐ はい
☐ いいえ
☐ わからない
5 あなたはクラウドサービスを利用していますか？利用している場合、情報の重要度を考慮した上で利用していますか？（いずれかひとつ）☐ 考慮した上で利用している☐ 考慮せず利用している☐ 利用する予定がある☐ 利用していない → 8 にお進みください。
6 利用している、あるいは利用を予定しているクラウドサービスは何ですか？差支えのない範囲でご記入ください[]

7 利用を決める要因は何ですか？（複数選択可）☐ 既存システムよりコストが安いこと☐ 初期導入コストが安価であること☐ 資産、保守体制を持つ必要がないこと☐ システムの構成変更が迅速に対応できること☐ システムの拡張性（スケーラビリティ）が高いこと☐ サービスの信頼性が高いこと☐ システムベンダーに提案されたから☐ ライセンス管理が楽であること☐ 情報漏洩等に対するセキュリティが高くなること☐ 安定性、可用性が高くなること☐ サービスのラインアップが充実していること☐ 導入スピードが速いこと☐ どこでもサービスを利用できること☐ 機器を選ばずに同様のサービスを利用できること☐ いつでも利用停止できること]☐ その他[
8 （5 で「利用していない」と回答された方にお尋ねします。
）
クラウドサービスを利用しない理由は何ですか？（複数選択可）
270

☐ クラウドの導入によって諸規定との整合性に支障をきたす☐ 通信費用がかさむ☐ ニーズに応じたアプリケーションのカスタマイズができない☐ ネットワークの安定性に対する不安がある☐ 情報漏洩などセキュリティに不安がある☐ 法制度が整っていない☐ 必要がない☐ メリットが分からない、判断できない]☐ その他[

9 アカデミッククラウド（*注）を利用したいと思いますか？（いずれかひとつ）（*注）アカデミッククラウドとは、高等教育機関（全国共同利用情報基盤センター等）が高等教育機関向けに運用するクラウドサービスを指します。
☐ 利用したい☐ 条件によっては利用したい☐ 利用したくない☐ わからない、判断できない
10 9 のように回答した理由は何ですか？アカデミッククラウドに求める要件、期待すること、問題点等をお書きください。
[]

質問は以上です。
ご協力、ありがとうございました。

271

事務支援分野アンケート（事務支援情報サービス部署向け，システム毎回答）

本アンケートは、文部科学省からの委託事業である平成 25 年度国家課題対応型研究開発推進事業・アカデミッククラウド環境構築に係るシステム研究「コミュニティで紡ぐ次世代大学 ICT 環境としてのアカデミッククラウド」におきまして、事務支援に係るシステムやサービスに対してアカデミッククラウドが備えるべき要件を明確化し、標準仕様策定のための参考とする目的で実施するものです。本事務支援部署向けアンケ
ートは、人事給与システム、財務会計システム、学務情報システム、就職支援システム、出退勤システム、あるいは、これらと同等のサービスを提供するシステムを対象として、システムの運用管理やサービス提供を担当している学務部、教務部、総務部、事務部、情報基盤センター等の部署に回答をお願いするものです。（教育支援部署，研究支援部署，
ICT サービス提供部署及び大学評価情報室等については，別のアンケートをお願いすることといたします。）（注）アカデミッククラウドとは、パブリッククラウドのうち、高等教育機関（全国共同利用情報基盤センター等）が高等教育機関向けに運用するクラウドサービスを指します。
※アンケートの回答は，特に指定がない限り今年度の状況をご記入下さい。

1 ご回答いただく方の所属機関、部局名等をご記入ください。

必須

所属機関※大学等の名称[

]

[

]

部局

※補足・伝達事項等ございましたら、設問 4 にお書きください。

2 事務支援システム毎に、以下の問いにお答えください。
2.1 該当するシステムは以下のどれに相当しますか。これから回答されるシステム
が、複数に相当する場合は複数選択してください。
☐人事給与システム☐財務会計システム☐学務情報システム☐就職支援システム☐出退勤システム※利用者数や構成等が異なるシステムを他に使用されている場合は、別の情報
272

として受付いたしますので、お手数でございますが、設問 3 終了後、あらためて同テーマアンケートにご回答くださいますようお願い申し上げます。既存データは上書きされることなく、新しいレコードが登録されます。
2.2 システムの利用者数はどの程度でしょうか。
 総利用者数☐～1,000 ☐～5,000 ☐～10,000 ☐10,001 以上
 同時利用者数（ピーク時）☐～500 ☐～1,000 ☐～5,000 ☐～10,000 ☐10,001 以上
2.3 システムが利用している計算機資源の構成はどうなっていますか。
 システムで独自に管理するサーバ（独自にサーバ仮想化を行っている場合
は仮想サーバでお答えください）
サーバ数[

]台

]個 総メモリ量[

総コア数[

]GB

 自機関のクラウドサービス等が提供する仮想サーバ
サーバ数[

]台

]個 総メモリ量[

総コア数[

]GB

 パブリッククラウドサービスが提供する仮想サーバ
サーバ数[

]台

]個 総メモリ量[

総コア数[

]GB

 他機関等の情報基盤センター等のアカデミッククラウドサービスが提供する仮想サーバ
サーバ数[]台]個 総メモリ量[

総コア数[

]GB

 その他 [
サーバ数[

]
]台

]個 総メモリ量[

総コア数[

]GB

2.4 今後、パブリッククラウドサービスが提供する仮想サーバ等の計算機資源（IaaS
or PaaS）を利用する計画、あるいは、意向がありますか。
☐既に利用していて、今後も継続して利用したい☐既に利用していて、今後さらに拡大したい☐既に利用しているが、今後は縮小、または、利用をやめたい]

理由：[☐利用する計画がある []年後☐積極的に利用したい☐できれば利用したい☐今後も利用しない、あるいは、課題があって利用するのは難しい
理由：[]☐その他 []
273

2.5 今後、アカデミッククラウドサービスとして仮想サーバ等の計算機資源(IaaS or
PaaS)が提供された場合、利用する意向がありますか。
☐積極的に利用したい☐できれば利用したい☐今後も利用しない、あるいは、課題があって利用するのは難しい
理由：[

]

☐その他[

]

2.6 システムで保有するデータの総量は現状でどの程度でしょうか。
[] ☐ GB □TB

2.7 当該サービスにログインするためのアカウント管理について該当するものをお選びください（複数選択可）。
☐自機関の統合認証情報（LDAP やアクティブディレクトリなど）と直接接続☐バッチ処理などにより学内の統合認証情報からアカウント情報を同期☐SAML（学認と同じ認証プロトコル）あるいはシボレスによる認証連携]☐その他：[

2.8 データのバックアップ先について該当するものをお選びください（複数選択可）。
☐バックアップを取得していない☐自部署で管理するハードディスクやバックアップメディア等☐自機関のクラウドサービスを利用☐パブリッククラウドサービスを利用☐他機関の情報基盤センター等が提供する共同利用サービスを利用☐その他 []

2.9 業務アプリケーションソフトウェアについて、該当するものを選択し、関連する情報を記入、あるいは、選択してください。
☐フルスクラッチで開発している☐オープンソースを活用して開発している
 利用しているオープンソース名称（できればお答えください）：[]☐業務パッケージソフトウェアを利用している 業務パッケージ名称（できればお答えください）：[] カスタマイズの度合い（一つ選択してください）：274

☐殆どカスタマイズせずに利用している☐業務に合わせて少しカスタマイズを行っている☐業務に合わせて大幅にカスタマイズを行っている☐SaaS 等のパブリックサービスを利用している
 利用してサービス名称（できればお答えください）：[]☐その他 []

2.10 今後、SaaS 等のパブリックサービス（大学等の情報基盤センター等が提供するサービスも含めて）を利用する計画、あるいは、意向がありますか。
☐既に利用していて、今後も継続して利用したい☐既に利用しているが、今後は利用をやめたい]

理由：[☐利用する計画がある[]年後☐積極的に利用したい☐将来的にも利用しない、あるいは、課題があって利用するのは難しい
理由：[]☐その他 []

2.11 BCP 対策の必要性、状況、計画についてお答えください。
☐災害発生時でも継続してシステムが稼働可能なレベルで BCP 対策が必要
である→

こちらを選択された方は、設問 2.11.1 を回答ください。

☐データが維持でき、数日～1 週間程度でシステムを再構築可能なレベルでBCP 対策が必要である（データが維持できれば、システムが数日～1 週間程度停止することは許容できる）→

こちらを選択された方は、設問 2.11.1 を回答ください。

☐BCP 対策は必要ない
]

理由：[
→

こちらを回答された方は、設問 2.12 に進んでください。

☐その他 [→]

こちらを回答された方は、設問 2.12 に進んでください。

275

2.11.1☐既に BCP 対策を実施している☐現在は対策できていないが、実施する計画がある[]年後☐計画はないが将来実施したい◆実施に当たっての課題や要望がありましたら記入してください[]

2.12 データや計算資源の管理運用について該当する項目を選び、１年間にかけている大よその稼働量（人年：小数可）を記入してください（複数選択可）。
☐教職員を配置して管理している：[] 人年☐クラウド事業者や管理委託業者に管理を任せている：[

] 人年

☐その他
[

]：[

] 人年

2.13 アカデミッククラウドに対する要望事項がありましたら記入してください。
[]

3 その他、ご意見等ございましたらお書きください[]

質問は以上です。
ご協力、ありがとうございました。
Ver1018276

教育支援分野アンケート(教育支援情報サービス部署向け)
本アンケート調査は，文部科学省からの委託事業である平成 25 年度国家課題対応型研究開発推進事業・アカデミッククラウド環境構築に係るシステム研究「コミュニティで紡ぐ
次世代大学 ICT 環境としてのアカデミッククラウド」におきまして，教育支援に係るアカ
デミッククラウドに対する要求仕様を策定する参考とさせていただくため，全学的な教育
学習支援システムを導入・運用する組織（例: 情報基盤センター，情報関係の本部組織等）
に対して，貴学における教育学習支援サービスの現状や要望事項をお伺いするものです．
高等教育機関における教育学習支援情報環境は，教員の視点から支援するためのコース
管理システムや学習支援システム，および，学生の視点から支援するためのｅポートフォ
リオシステムが，教務システムと合わせて，大学における教育学習活動の三位一体システ
ムとして明確になってきています．これらのシステムが，大学ポータルにより統合された
アクセス環境やデータ連携を通じて相互に連携されることにより，「仮想世界における教育
学習メディア」を形成するようになってきています．さらに，教室や図書館のような「物理世界における教育学習メディア」も，学生用端末システム，IC カードによる入退室管理や図書貸借の電子化を通じて一部が情報環境に取り込まれることにより，物理世界・仮想世界双方の教育学習活動が徐々に「可観測」になってきています(図参照)．しかも，最近では PC 必携化に代表される BYOD (Bring Your Own Device) も進みつつあり，大学における教育学習活動に関わる様々な活動を通じて教育ビッグデータの蓄積が始まろうとしてい
ます．

277

このような背景の下，本アンケートでは，教育学習支援情報環境の利活用の現状把握と今後のクラウド化に関する以下の設問にご回答いただければ幸いです．
（注）アカデミッククラウドとは、パブリッククラウドのうち、高等教育機関（全国共同利用情報基盤センター等）が高等教育機関向けに運用するクラウドサービスを指します。
※アンケートの回答は，特に指定がない限り今年度の状況をご記入下さい。

1 ご回答いただく方の所属機関、部局名等をご記入ください

所属機関※大学等の名称［ここをクリックしてテキストを入力してください。］
部局［ここをクリックしてテキストを入力してください。］※補足・伝達事項等ございましたら、設問 30 にお書きください。

2 : コース管理システム/学習支援システム (CMS/LMS)，e ポートフォリオシステムを全学的に導入し，教育学習支援サービスを学部・研究科に提供していますか？
2.1 CMS/LMS□A1: 全学的に導入し，学部・研究科に提供している（次は設問 3 をご回答ください）□A2: 全学的に導入していないが，学部・研究科独自に導入・利用しているところがある（次は設問 8 をご回答ください）□A3: 全学的にも学部・研究科としても導入・利用しているところはない （次は設問 8 をご回答ください）
2.2 e ポートフォリオシステム□A1: 全学的に導入し，学部・研究科に提供している（次は設問 3 をご回答ください）□A2: 全学的に導入していないが，学部・研究科独自に導入・利用しているところがある（次は設問 8 をご回答ください）□A3: 全学的にも学部・研究科としても導入・利用しているところはない（次は設問 8 をご回答ください）
3 : 設問 2 で A1 を選択した場合，どの程度利用されていますか?
3.1 CMS/LMS : アクティブな科目数: [ ] 科目 （アクティブとは，教員・学生が登録され,何らかの利用があることを指します）
278

 : 利用対象総科目数: [ ] 科目
 : アクティブなユーザ数:[
 : 総データ量:[

]ユーザ

] GB

3.2 e ポートフォリオシステム
 :アクティブな科目数: []科目 （アクティブとは，教員・学生が登録され何らかの利用があることを指します）
 : 利用対象総科目数: [ ]科目
 : アクティブなユーザ数:[
 : 総データ量: [

]ユーザ

]GB

4 : 設問 2 で A1 を選択した場合，運用形態は次のいずれですか? （複数可）
4.1 CMS/LMS□ B1: オンプレミス型（大学または学部・研究科が管理する設備にシステムを導入して運用）□B2: ASP 型（民間企業等，外部組織が提供する設備やシステムを通じてサービスとして利用）□B3: 外部データセンター型（民間企業等，外部組織が提供するデータセンターに大学または学部・研究科が管理するシステムを導入して運用）
4.2 e ポートフォリオシステム□C1: オンプレミス型（大学または学部・研究科が管理する設備にシステムを導入
して運用）□C2: ASP 型（民間企業等，外部組織が提供する設備やシステムを通じてサービスとして利用）□C3: 外部データセンター型（民間企業等，外部組織が提供するデータセンターに大学または学部・研究科が管理するシステムを導入して運用）
5 : 設問 2 で A1 を選択した場合，CMS/LMS が有する機能はどの程度利用されていま
すか?
5.1 授業資料の提供（プレゼンテーションファイル，補助教材や自学自習用教材を含む．
ビデオ教材は除く）□ 非常によく使われている（目安: 8 割以上の科目）□ よく使われている（目安: ６割以上，８割未満の科目）□ ある程度使われている（目安: 4 割以上，6 割未満の科目）279

□ あまり使われていない（目安: 2 割以上，４割未満の科目）□ ほとんど使われていない（目安: 2 割未満の科目）□ 分からない
5.2 ビデオ教材の提供□ 非常によく使われている（目安: 8 割以上の科目）□ よく使われている（目安: ６割以上，８割未満の科目）□ ある程度使われている（目安: 4 割以上，6 割未満の科目）□ あまり使われていない（目安: 2 割以上，４割未満の科目）□ ほとんど使われていない（目安: 2 割未満の科目）□ 分からない
5.3 SCORM 教材等のオンライン教材（IMS Common Cartridge に対応したオンライ
ン教材を含む）□ 非常によく使われている（目安: 8 割以上の科目）□ よく使われている（目安: ６割以上，８割未満の科目）□ ある程度使われている（目安: 4 割以上，6 割未満の科目）□ あまり使われていない（目安: 2 割以上，４割未満の科目）□ ほとんど使われていない（目安: 2 割未満の科目）□ 分からない
5.4 課題レポートの提出・採点・返却□ 非常によく使われている（目安: 8 割以上の科目）□ よく使われている（目安: ６割以上，８割未満の科目）□ ある程度使われている（目安: 4 割以上，6 割未満の科目）□ あまり使われていない（目安: 2 割以上，４割未満の科目）□ ほとんど使われていない（目安: 2 割未満の科目）□ 分からない
5.5 テスト（自学自習用の小テストを含む）□ 非常によく使われている（目安: 8 割以上の科目）□ よく使われている（目安: ６割以上，８割未満の科目）□ ある程度使われている（目安: 4 割以上，6 割未満の科目）□ あまり使われていない（目安: 2 割以上，４割未満の科目）□ ほとんど使われていない（目安: 2 割未満の科目）□ 分からない
5.6 ディスカッション□ 非常によく使われている（目安: 8 割以上の科目）□ よく使われている（目安: ６割以上，８割未満の科目）□ ある程度使われている（目安: 4 割以上，6 割未満の科目）
280

□ あまり使われていない（目安: 2 割以上，４割未満の科目）□ ほとんど使われていない（目安: 2 割未満の科目）□ 分からない
5.7 メール等による教員・学生間のやりとり□ 非常によく使われている（目安: 8 割以上の科目）□ よく使われている（目安: ６割以上，８割未満の科目）□ ある程度使われている（目安: 4 割以上，6 割未満の科目）□ あまり使われていない（目安: 2 割以上，４割未満の科目）□ ほとんど使われていない（目安: 2 割未満の科目）□ 分からない
5.8 Wiki□ 非常によく使われている（目安: 8 割以上の科目）□ よく使われている（目安: ６割以上，８割未満の科目）□ ある程度使われている（目安: 4 割以上，6 割未満の科目）□ あまり使われていない（目安: 2 割以上，４割未満の科目）□ ほとんど使われていない（目安: 2 割未満の科目）□ 分からない
5.9 ブログやマイクロブログ等のソーシャルネットワーキング機能□ 非常によく使われている（目安: 8 割以上の科目）□ よく使われている（目安: ６割以上，８割未満の科目）□ ある程度使われている（目安: 4 割以上，6 割未満の科目）□ あまり使われていない（目安: 2 割以上，４割未満の科目）□ ほとんど使われていない（目安: 2 割未満の科目）□ 分からない
6 設問 2 で A1 を選択した場合，CMS/LMS や e ポートフォリオシステムは，教務システ
ムが有する次の情報についてどの程度連携していますか?
 CMS/LMS
6.1 : 科目情報
□ 利用対象総科目の 8 割以上□ 利用対象総科目の 6 割以上，8 割未満□ 利用対象総科目の 4 割以上，6 割未満□ 利用対象総科目の 2 割以上，4 割未満□ 利用対象総科目の 2 割未満□ 分からない
6.2 : 履修情報281

□ 利用対象総科目の 8 割以上□ 利用対象総科目の 6 割以上，8 割未満□ 利用対象総科目の 4 割以上，6 割未満□ 利用対象総科目の 2 割以上，4 割未満□ 利用対象総科目の 2 割未満□ 分からない
6.3 : シラバス情報□ 利用対象総科目の 8 割以上□ 利用対象総科目の 6 割以上，8 割未満□ 利用対象総科目の 4 割以上，6 割未満□ 利用対象総科目の 2 割以上，4 割未満□ 利用対象総科目の 2 割未満□ 分からない e ポートフォリオシステム
6.4 : 科目情報
□ 利用対象総科目の 8 割以上□ 利用対象総科目の 6 割以上，8 割未満□ 利用対象総科目の 4 割以上，6 割未満□ 利用対象総科目の 2 割以上，4 割未満□ 利用対象総科目の 2 割未満□ 分からない
6.5 : 履修情報
□ 利用対象総科目の 8 割以上□ 利用対象総科目の 6 割以上，8 割未満□ 利用対象総科目の 4 割以上，6 割未満□ 利用対象総科目の 2 割以上，4 割未満□ 利用対象総科目の 2 割未満□ 分からない
6.6 : シラバス情報□ 利用対象総科目の 8 割以上□ 利用対象総科目の 6 割以上，8 割未満□ 利用対象総科目の 4 割以上，6 割未満□ 利用対象総科目の 2 割以上，4 割未満□ 利用対象総科目の 2 割未満□ 分からない282

7 : 設問 4 で B1、C1 のいずれかを選択した場合，ASP 型に移行する可能性はありますか?
7.1 CMS/LMS□: A1: ASP 型に移行することが決まっている [年後]□: A2: ASP 型に移行する計画がある，または，検討を行っている□: A3: ASP 型に移行する検討は行っていない
7.2 e ポートフォリオシステム□: A1: ASP 型に移行することが決まっている [年後]□: A2: ASP 型に移行する計画がある，または，検討を行っている□: A3: ASP 型に移行する検討は行っていない
8 : 民間企業等，外部組織が提供する設備やシステムを利用する ASP 型で CMS/LMS や
e ポートフォリオシステムを利用する場合，次のうちでメリットになると思うものを挙げてください （複数選択可）．
□: 低コストで導入・利用できる□: 短期間で導入・利用できる□: 新しい機能の追加や新しい技術導入が迅速に行われる□: 学部・研究科のニーズに応じたカスタマイズを迅速に行える□: 学部・研究科に技術者がいなくても導入・利用できる□: 利用のピークに合わせた計算機資源や設備投資が不要になる□: その他 []9 : 民間企業等，外部組織が提供する設備やシステムを利用する ASP 型で CMS/LMS や
e ポートフォリオシステムを利用するデメリットを挙げてください.（複数選択可）□: 特定の業者にロックインしてしまう（業者変更ができない）□: 新しい機能の追加や新しい技術導入が迅速に行われない□: 学部・研究科のニーズに応じたカスタマイズを行いにくい□: 学部・研究科のニーズに応じたカスタマイズを行うコストが高い□: 教育学習活動に関わる様々な記録が業者側のシステムに蓄積されるため，セキュ
リティやプライバシー上の懸念が生じやすい□: 業者側のシステムに蓄積された教育学習活動に関わる様々な記録を再利用しにくい□: その他 （）

10 : CMS/LMS や e ポートフォリオシステムの ASP 型での利用を促進する要因について
283

挙げてください．
（複数選択可）□: セキュリティやプライバシーを強化する技術整備（具体的に:□: セキュリティやプライバシーを強化する法整備（具体的に:□: 災害対策を強化する技術・運用（具体的に:）））□: 学内の有線ネットワークの高速化□: 学内の無線ネットワークの高速化□: 学外接続ネットワークの高速化□: PC 必携化等の BYOD (Bring Your Own Device)□: 低コスト□: エビデンスベースによる教育の質向上の取り組み□: 大学 ICT 推進協議会のような大学が組織として加盟するコミュニティの介在□: その他 （）

11 : 学生メールシステムを全学的に導入し，学部・研究科に提供していますか？
□A1: 全学的に導入し，学部・研究科に提供している（次は設問 12 をご回答ください）□A2: 全学的に導入していないが，学部・研究科独自に導入・利用しているところがある（次は設問 22 をご回答ください）□A3: 全学的にも学部・研究科としても導入・利用しているところはない（次は設問 22 をご回答ください）
12 : 設問 11 で A1 を選択した場合，どの程度利用されていますか?
アクティブなユーザ数:[]ユーザ （アクティブとは，メールの受信等，何らかの利用があることを指す）
総データ量:[] GB

13 設問 11 で A1 を選択した場合，運用形態は次のいずれですか?
□ B1: オンプレミス型（大学または学部・研究科が管理する設備にシステムを導入して運用）□ B2: ASP 型（民間企業等，外部組織が提供する設備やシステムを利用）□ B3. 外部データセンター型（民間企業等，外部組織が提供するデータセンターに大学または学部・研究科が管理する設備にシステムを導入して運用）
14 設問 13 で B1 を選択した場合，ASP 型に移行する可能性はありますか?
A1: ASP 型に移行することが決まっている （年後）

A2: ASP 型に移行する計画がある，または，検討を行っている
284

A3: ASP 型に移行する検討は行っていない
15 : ASP 型で学生メールシステムを提供する場合，次のうちでメリットになると思うものを挙げてください （複数選択可）．
□: 低コストで導入・利用できる□: 短期間で導入・利用できる□: 新しい機能の追加や新しい技術導入が迅速に行われる□: 大学のニーズに応じたカスタマイズを迅速に行える□: 大学に技術者がいなくても導入・利用できる□: 利用のピークに合わせた計算機資源や設備投資が不要になる□: その他 []16 : ASP 型で学生メールシステムを提供するデメリットを挙げてください．
（複数選択可）。
□: 特定の業者にロックインしてしまう（業者変更ができない）□: 新しい機能の追加や新しい技術導入が迅速に行われない□: 大学のニーズに応じたカスタマイズを行いにくい□: 大学のニーズに応じたカスタマイズを行うコストが高い□: 教育学習活動に関わる様々なメールが業者側のシステムに蓄積されるため，セキュリティやプライバシー上の懸念が生じやすい□: その他 （）

17 : 学生メールシステムの ASP 型での提供を促進する要因について挙げてください．（複数選択可）。
□: セキュリティやプライバシーを強化する技術整備（具体的に:□: セキュリティやプライバシーを強化する法整備（具体的に:□: 災害対策を強化する技術・運用（具体的に:）））□: 学内の有線ネットワークの高速化□: 学内の無線ネットワークの高速化□: 学外接続ネットワークの高速化□: PC 必携化等の BYOD (Bring Your Own Device)□: 低コスト□: エビデンスベースによる教育の質向上の取り組み□: 大学 ICT 推進協議会のような大学が組織として加盟するコミュニティの介在□: その他 （）

18 : 学生用端末システムを全学的に導入し，学部・研究科に提供していますか？
285□A1: 全学的に導入し，学部・研究科に提供している（次は設問 19 をご回答ください）□A2: 全学的に導入していないが，学部・研究科独自に導入・利用しているところがある（次は設問 22 をご回答ください）□A3: 全学的にも学部・研究科としても導入・利用しているところはない（次は設問 22 をご回答ください）
19 : 設問 18 で A1 を選択した場合，どの程度の規模のシステムですか?
端末数: []台

総システムデータ量:[] GB （OS，アプリケーション，ホームディレクトリ容量などすべて含む）
1 ユーザ当たりのホームディレクトリ最大容量: [] GB

20 仮想マシンをサーバサイドで起動し画面を端末に表示するデスクトップクラウド等のクラウド型に移行する可能性はありますか?
□ A1: すでにクラウド型に移行している□ A2: クラウド型に移行することが決まっている （年後）□ A3: クラウド型に移行する計画がある，または，検討を行っている□ A4: クラウド型に移行する検討は行っていない
21 設問 20 で A1〜A3 を選択した場合，運用形態は次のいずれですか?
□ B1: プライベートクラウド型（大学または学部・研究科が管理する設備にシステムを導入して運用）□B2: パブリッククラウド型（民間企業等，外部組織が提供する設備やシステムを利用）
22 : クラウド型で学生端末システムを提供する場合，次のうちでメリットになると思うものを挙げてください （複数選択可）．
□: 低コストで導入・利用できる□: 短期間で導入・利用できる□: 新しい機能の追加や新しい技術導入が迅速に行われる□: 大学のニーズに応じたカスタマイズを迅速に行える□: 大学に技術者がいなくても導入・利用できる□: 利用のピークに合わせた計算機資源や設備投資が不要になる□: その他 []286

23 : クラウド型で学生端末システムを提供するデメリットを挙げてください．
（複数選択可）□: 特定の業者にロックインしてしまう（業者変更ができない）□: 新しい機能の追加や新しい技術導入が迅速に行われない□: 大学のニーズに応じたカスタマイズを行いにくい□: 大学のニーズに応じたカスタマイズを行うコストが高い□: 教育学習活動に関わる様々な情報が業者側のシステムに蓄積されるため，セキュ
リティやプライバシー上の懸念が生じやすい□: その他 （）

24 : 学生端末システムのクラウド型での提供を促進する要因について挙げてください．（複数選択可）□: セキュリティやプライバシーを強化する技術整備（具体的に:□: セキュリティやプライバシーを強化する法整備（具体的に:□: 災害対策を強化する技術・運用（具体的に:）））□: 学内の有線ネットワークの高速化□: 学内の無線ネットワークの高速化□: 学外接続ネットワークの高速化□: BYOD (Bring Your Own Device) 等，パソコン必携化□: 低コスト□: エビデンスベースによる教育の質向上の取り組み□: 大学 ICT 推進協議会のような大学が組織として加盟するコミュニティの介在□: その他 （）

25 PC 必携化等の BYOD 施策を現在，推進していますか?
□A1: 全学的に推進している （次は設問 27 をご回答ください）□A2: 全学的には推進していないが，学部・研究科独自に推進しているところがある（次は設問 26 をご回答ください）□A3: 全学的にも学部・研究科としても推進しているところはない（次は設問 26 をご回答ください）26 設問 25 で A2・A3 を選択した場合，PC 必携化等の BYOD 施策の今後についてお聞かせ下さい．
□A1: 全学的に BYOD を推進することが決まっている （年後）□A2: 全学的に BYOD を推進する計画がある，または，検討を行っている□A3: 全学的に BYOD を推進する検討は行っていない
287

27 設問 25 で A1 を，設問 26 で A2・A3 を選択した場合，当てはまるものを選んで下さい．
（複数選択可）□ A1：これまでの学生用端末数は維持する□ A2: これまでの学生用端末数は削減するが，ゼロにはしない．
□ A3: これまでの学生用端末はゼロにする□ A4: PC を購入できない学生のために，端末貸与サービスを検討している
28 : 大学ポータルを通じて，教員学生に対して CMS/LMS や e ポートフォリオシステム，
学生メールシステム等に一元的にアクセスできる環境を提供していますか? 大学ポー
タルを通じた利用が可能な場合，どのような機能が利用可能ですか? （複数選択可）□: シングルサインオンが可能な ID 連携□: ID 連携のみ（シングルサインオンはできない）□: IC カード認証等，複数認証手段の提供□: 携帯電話，スマートフォン，タブレット等，複数アクセスデバイス対応□: ウェブリンクによる連携□: RSS による情報連携□: ポートレットなどによる情報連携□: その他 []□: 大学ポータルによる一元的なアクセス環境は提供していない
29: 貴学における教育学習支援サービスの現状や将来に関して，期待や要望事項があれば，ご記入下さい．
[]

30:アカデミッククラウドに対する期待や要望（求められるシステムの内容や条件，要求資源量等）について，ご記入下さい．
[]

31:その他、ご意見等ございましたらお書きください[]
Ver1018288

教育支援分野アンケート(学部・研究科向け)本アンケート調査は，文部科学省からの委託事業である平成 25 年度国家課題対応型研究開発推進事業・アカデミッククラウド環境構築に係るシステム研究「コミュニティで紡ぐ
次世代大学 ICT 環境としてのアカデミッククラウド」におきまして，教育支援に係るアカ
デミッククラウドに対する要求仕様を策定する参考とさせていただくため，各大学における教育を行っている学部・研究科等（共通教育担当部局を含む）に，教育学習支援サービ
スの現状や要望事項をお伺いするものです．
高等教育機関における教育学習支援情報環境は，教員の視点から支援するためのコース
管理システムや学習支援システム，および，学生の視点から支援するためのｅポートフォ
リオシステムが，教務システムと合わせて，大学における教育学習活動の三位一体システ
ムとして明確になってきています．これらのシステムが，大学ポータルにより統合された
アクセス環境やデータ連携を通じて相互に連携されることにより，「仮想世界における教育
学習メディア」を形成するようになってきています．さらに，教室や図書館のような「物理世界における教育学習メディア」も，学生用端末システム，IC カードによる入退室管理や図書貸借の電子化を通じて一部が情報環境に取り込まれることにより，物理世界・仮想世界双方の教育学習活動が徐々に「可観測」になってきています(図参照)．しかも，最近では PC 必携化に代表される BYOD (Bring Your Own Device) も進みつつあり，大学における教育学習活動に関わる様々な活動を通じて教育ビッグデータの蓄積が始まろうとしています．

このような背景の下，本アンケートでは，教育学習支援情報環境の利活用の現状把握と今289

後のクラウド化に関する以下の設問にご回答いただければ幸いです．
（注）アカデミッククラウドとは、パブリッククラウドのうち、高等教育機関（全国共同利用情報基盤センター等）が高等教育機関向けに運用するクラウドサービスを指します。
※アンケートの回答は，特に指定がない限り今年度の状況をご記入下さい。

1 ご回答いただく方の所属機関、部局名等をご記入ください

所属機関※大学等の名称［ここをクリックしてテキストを入力してください。］
部局［ここをクリックしてテキストを入力してください。］※補足・伝達事項等ございましたら、設問 13 にお書きください。
2 : コース管理システム/学習支援システム (CMS/LMS)，e ポートフォリオシステムを学
部・研究科として利用していますか?
2.1 CMS/LMS□ A1: 全学的に導入されているものを学部・研究科として利用している（次は設問 8をご回答ください）□ A2: 学部・研究科独自に導入し利用している（次は設問 3 をご回答ください）□ A3: 学部・研究科としては導入していないが，全学的に導入されているもの等を教員が利用しているケースがある（次は設問 8 をご回答ください）□ A4: 学部・研究科として導入する計画がある，または，検討を行っている（次は設問 8 をご回答ください）□ A5: 学部・研究科として導入する検討は行っていない（次は設問 8 をご回答ください）
2.2 e ポートフォリオシステム□ A1: 全学的に導入されているものを学部・研究科として利用している（次は設問 8をご回答ください）□ A2: 学部・研究科独自に導入し利用している（次は設問 3 をご回答ください）□ A3: 学部・研究科としては導入していないが，全学的に導入されているもの等を教員が利用しているケースがある（次は設問 8 をご回答ください）□ A4: 学部・研究科として導入する計画がある，または，検討を行っている（次は設問 8 をご回答ください）□ A5: 学部・研究科として導入する検討は行っていない（次は設問 8 をご回答ください）
3 : 設問 2 で A2 を選択した場合，学部・研究科内でどの程度利用されていますか?
3.1 CMS/LMS
290

 : アクティブな科目数: [ ] 科目 （アクティブとは，教員・学生が登録され,何らかの利用があることを指す）
 : 利用対象総科目数: [ ] 科目
 : アクティブなユーザ数:[
 : 総データ量:[

]ユーザ

] GB

3.2 e ポートフォリオシステム
 :アクティブな科目数: []科目 （アクティブとは，教員・学生が登録され何らかの利用があることを指す）
 : 利用対象総科目数: [ ]科目
 : アクティブなユーザ数:[
 : 総データ量: [

]ユーザ

]GB

4 : 設問 2 で A2 を選択した場合，運用形態は次のいずれですか? （複数選択可）
4.1 CMS/LMS□ B1: オンプレミス型（大学または学部・研究科が管理する設備にシステムを導入して運用）□B2: ASP 型（民間企業等，外部組織が提供する設備やシステムを通じてサービスとして利用）□B3: 外部データセンター型（民間企業等，外部組織が提供するデータセンターに大学または学部・研究科が管理するシステムを導入して運用）
4.2 e ポートフォリオシステム□C1: オンプレミス型（大学または学部・研究科が管理する設備にシステムを導入
して運用）□C2: ASP 型（民間企業等，外部組織が提供する設備やシステムを通じてサービス
して利用）□C3: 外部データセンター型（民間企業等，外部組織が提供するデータセンターに大学または学部・研究科が管理するシステムを導入して運用）
5 : 設問 2 で A2 を選択した場合，CMS/LMS が有する機能はどの程度利用されていま
すか?
5.1 授業資料の提供（プレゼンテーションファイル，補助教材や自学自習用教材を含む．
ビデオ教材は除く）□ 非常によく使われている（目安: 8 割以上の科目）□ よく使われている（目安: ６割以上，８割未満の科目）□ ある程度使われている（目安: 4 割以上，6 割未満の科目）291

□ あまり使われていない（目安: 2 割以上，４割未満の科目）□ ほとんど使われていない（目安: 2 割未満の科目）□ 分からない
5.2 ビデオ教材の提供□ 非常によく使われている（目安: 8 割以上の科目）□ よく使われている（目安: ６割以上，８割未満の科目）□ ある程度使われている（目安: 4 割以上，6 割未満の科目）□ あまり使われていない（目安: 2 割以上，４割未満の科目）□ ほとんど使われていない（目安: 2 割未満の科目）□ 分からない
5.3 SCORM 教材等のオンライン教材（IMS Common Cartridge に対応したオンライ
ン教材を含む）□ 非常によく使われている（目安: 8 割以上の科目）□ よく使われている（目安: ６割以上，８割未満の科目）□ ある程度使われている（目安: 4 割以上，6 割未満の科目）□ あまり使われていない（目安: 2 割以上，４割未満の科目）□ ほとんど使われていない（目安: 2 割未満の科目）□ 分からない
5.4 課題レポートの提出・採点・返却□ 非常によく使われている（目安: 8 割以上の科目）□ よく使われている（目安: ６割以上，８割未満の科目）□ ある程度使われている（目安: 4 割以上，6 割未満の科目）□ あまり使われていない（目安: 2 割以上，４割未満の科目）□ ほとんど使われていない（目安: 2 割未満の科目）□ 分からない
5.5 テスト（自学自習用の小テストを含む）□ 非常によく使われている（目安: 8 割以上の科目）□ よく使われている（目安: ６割以上，８割未満の科目）□ ある程度使われている（目安: 4 割以上，6 割未満の科目）□ あまり使われていない（目安: 2 割以上，４割未満の科目）□ ほとんど使われていない（目安: 2 割未満の科目）□ 分からない
5.6 ディスカッション□ 非常によく使われている（目安: 8 割以上の科目）□ よく使われている（目安: ６割以上，８割未満の科目）□ ある程度使われている（目安: 4 割以上，6 割未満の科目）292

□ あまり使われていない（目安: 2 割以上，４割未満の科目）□ ほとんど使われていない（目安: 2 割未満の科目）□ 分からない
5.7 メール等による教員・学生間のやりとり□ 非常によく使われている（目安: 8 割以上の科目）□ よく使われている（目安: ６割以上，８割未満の科目）□ ある程度使われている（目安: 4 割以上，6 割未満の科目）□ あまり使われていない（目安: 2 割以上，４割未満の科目）□ ほとんど使われていない（目安: 2 割未満の科目）□ 分からない
5.8 Wiki□ 非常によく使われている（目安: 8 割以上の科目）□ よく使われている（目安: ６割以上，８割未満の科目）□ ある程度使われている（目安: 4 割以上，6 割未満の科目）□ あまり使われていない（目安: 2 割以上，４割未満の科目）□ ほとんど使われていない（目安: 2 割未満の科目）□ 分からない
5.9 ブログやマイクロブログ等のソーシャルネットワーキング機能□ 非常によく使われている（目安: 8 割以上の科目）□ よく使われている（目安: ６割以上，８割未満の科目）□ ある程度使われている（目安: 4 割以上，6 割未満の科目）□ あまり使われていない（目安: 2 割以上，４割未満の科目）□ ほとんど使われていない（目安: 2 割未満の科目）□ 分からない
6 設問 2 で A2 を選択した場合，CMS/LMS や e ポートフォリオシステムは，教務システ
ムが有する次の情報についてどの程度連携していますか?
 CMS/LMS
6.1 : 科目情報
□ 利用対象総科目の 8 割以上□ 利用対象総科目の 6 割以上，8 割未満□ 利用対象総科目の 4 割以上，6 割未満□ 利用対象総科目の 2 割以上，4 割未満□ 利用対象総科目の 2 割未満□ 分からない
6.2 : 履修情報
293□ 利用対象総科目の 8 割以上□ 利用対象総科目の 6 割以上，8 割未満□ 利用対象総科目の 4 割以上，6 割未満□ 利用対象総科目の 2 割以上，4 割未満□ 利用対象総科目の 2 割未満□ 分からない
6.3 : シラバス情報□ 利用対象総科目の 8 割以上□ 利用対象総科目の 6 割以上，8 割未満□ 利用対象総科目の 4 割以上，6 割未満□ 利用対象総科目の 2 割以上，4 割未満□ 利用対象総科目の 2 割未満□ 分からない e ポートフォリオシステム
6.4 : 科目情報
□ 利用対象総科目の 8 割以上□ 利用対象総科目の 6 割以上，8 割未満□ 利用対象総科目の 4 割以上，6 割未満□ 利用対象総科目の 2 割以上，4 割未満□ 利用対象総科目の 2 割未満□ 分からない
6.5 : 履修情報
□ 利用対象総科目の 8 割以上□ 利用対象総科目の 6 割以上，8 割未満□ 利用対象総科目の 4 割以上，6 割未満□ 利用対象総科目の 2 割以上，4 割未満□ 利用対象総科目の 2 割未満□ 分からない
6.6 : シラバス情報□ 利用対象総科目の 8 割以上□ 利用対象総科目の 6 割以上，8 割未満□ 利用対象総科目の 4 割以上，6 割未満□ 利用対象総科目の 2 割以上，4 割未満□ 利用対象総科目の 2 割未満□ 分からない294

7 : 設問 4 で B1、C1 のいずれかを選択した場合，ASP 型に移行する可能性はありますか?
7.1 CMS/LMS□: ASP 型に移行することが決まっている [年後]□: ASP 型に移行する計画がある，または，検討を行っている□: ASP 型に移行する検討は行っていない
7.2 e ポートフォリオシステム□: ASP 型に移行することが決まっている [年後]□: ASP 型に移行する計画がある，または，検討を行っている□: ASP 型に移行する検討は行っていない
8 : 民間企業等，外部組織が提供する設備やシステムを利用する ASP 型で CMS/LMS や
e ポートフォリオシステムを利用する場合，次のうちでメリットになると思うものを挙げてください （複数選択可）．
□: 低コストで導入・利用できる□: 短期間で導入・利用できる□: 新しい機能の追加や新しい技術導入が迅速に行われる□: 学部・研究科のニーズに応じたカスタマイズを迅速に行える□: 学部・研究科に技術者がいなくても導入・利用できる□: 利用のピークに合わせた計算機資源や設備投資が不要になる□: その他 []9 : 民間企業等，外部組織が提供する設備やシステムを利用する ASP 型で CMS/LMS や
e ポートフォリオシステムを利用するデメリットを挙げてください （複数選択可）．
□: 特定の業者にロックインしてしまう（業者変更ができない）□: 新しい機能の追加や新しい技術導入が迅速に行われない□: 学部・研究科のニーズに応じたカスタマイズを行いにくい□: 学部・研究科のニーズに応じたカスタマイズを行うコストが高い□: 教育学習活動に関わる様々な記録が業者側のシステムに蓄積されるため，セキュ
リティやプライバシー上の懸念が生じやすい□: 業者側のシステムに蓄積された教育学習活動に関わる様々な記録を再利用しにくい□: その他 （）

10 : CMS/LMS や e ポートフォリオシステムの ASP 型での利用を促進する要因について挙295

げてください．
（複数選択可）□: セキュリティやプライバシーを強化する技術整備（具体的に:□: セキュリティやプライバシーを強化する法整備（具体的に:□: 災害対策を強化する技術・運用（具体的に:）））□: 学内の有線ネットワークの高速化□: 学内の無線ネットワークの高速化□: 学外接続ネットワークの高速化□: PC 必携化等の BYOD (Bring Your Own Device)□: 低コスト□: エビデンスベースによる教育の質向上の取り組み□: 大学 ICT 推進協議会のような大学が組織として加盟するコミュニティの介在□: その他 （）

11: 貴学における教育学習支援サービスの現状や将来に関して，期待や要望事項があれば，ご記入下さい．
[]

12: アカデミッククラウドに対する期待や要望（求められるシステムの内容や条件，要求資源量等）について，ご記入下さい．
[]

13 その他、ご意見等ございましたらお書きください[]

Ver1018296

個人情報保護分野アンケート（個人情報保護に係る機関代表部署向け）
本アンケート調査は、文部科学省からの委託事業である平成 25 年度国家課題対応
型研究開発推進事業・アカデミッククラウド環境構築に係るシステム研究「コミュニティで紡ぐ次世代大学 ICT 環境としてのアカデミッククラウド」におきまして、個
人情報保護のために必要とされる要件を策定する際の参考とさせていただくために、
各大学・研究機関における個人情報保護のための方針、実施体制や行動計画についての実情をお伺いするものです。
本調査におけるアカデミッククラウドは、大学・研究機関が、学外ネットワーク上に存在する計算機やサーバ、ストレージ、データベース、ソフトウェア等の情報関連資源を安価に使用できるものを想定しており、各機関における物理的な機器の管理コ
ストを削減することが可能となるものを想定しておりますが、その実現のためには、
適切な個人情報保護のためガイドラインが必須となります。そのために、各機関における個人情報保護の実情を把握し、アカデミッククラウドを活用する際に留意すべき事項の検討に役立てたいと考えております。
つきましては、以下のアンケート項目にご回答をいただければ幸いです。
（*注）アカデミッククラウドとは、パブリッククラウドのうち、高等教育機関（全国共同利用情報基盤センター等）が高等教育機関向けに運用するクラウドサービスを指します※アンケートの回答は，特に指定がない限り今年度の状況をご記入下さい。

1 回答機関に関して、下記にお答え下さい。
1.1 ご回答いただく方の所属機関、部局名等をご記入下さい。 必須
所属機関※大学等の名称[

]

[

]

部局

※補足・伝達事項等ございましたら、設問 6 にお書き下さい。
1.2 学校基本調査に準じて、貴機関の学部、研究科（専門職大学院を含む）毎の教員
数、学生数をすべてお答えください。（科目等履修生・聴講生・研究生を含む）
学部・研究科符号: []、教員（本務）数: []、学生数: 昼間[

]

夜間[

]

学部・研究科符号: []、教員（本務）数: []、学生数: 昼間[

]

夜間[

]

学部・研究科符号: []、教員（本務）数: []、学生数: 昼間[

]

夜間[

]

学部・研究科符号: []、教員（本務）数: []、学生数: 昼間[

]

夜間[

]

297

学部・研究科符号: []、教員（本務）数: []、学生数: 昼間[

]

夜間[

]

学部・研究科符号: []、教員（本務）数: []、学生数: 昼間[

]

夜間[

]

学部・研究科符号: []、教員（本務）数: []、学生数: 昼間[

]

夜間[

]

学部・研究科符号: []、教員（本務）数: []、学生数: 昼間[

]

夜間[

]

学部・研究科符号: []、教員（本務）数: []、学生数: 昼間[

]

夜間[

]

学部・研究科符号: []、教員（本務）数: []、学生数: 昼間[

]

夜間[

]

学部・研究科符号: []、教員（本務）数: []、学生数: 昼間[

]

夜間[

]

学部・研究科符号: []、教員（本務）数: []、学生数: 昼間[

]

夜間[

]

学部・研究科符号: []、教員（本務）数: []、学生数: 昼間[

]

夜間[

]

学部・研究科符号: []、教員（本務）数: []、学生数: 昼間[

]

夜間[

]

学部・研究科符号: []、教員（本務）数: []、学生数: 昼間[

]

夜間[

]

学部・研究科符号: []、教員（本務）数: []、学生数: 昼間[

]

夜間[

]

学部・研究科符号: []、教員（本務）数: []、学生数: 昼間[

]

夜間[

]

学部・研究科符号: []、教員（本務）数: []、学生数: 昼間[

]

夜間[

]

学部・研究科符号: []、教員（本務）数: []、学生数: 昼間[

]

夜間[

]

学部・研究科符号: []、教員（本務）数: []、学生数: 昼間[

] 夜間[

]

学部・研究科符号: []、教員（本務）数: []、学生数: 昼間[

]

夜間[

]

学部・研究科符号: []、教員（本務）数: []、学生数: 昼間[

]

夜間[

]

学部・研究科符号: []、教員（本務）数: []、学生数: 昼間[

]

夜間[

]

学部・研究科符号: []、教員（本務）数: []、学生数: 昼間[

]

夜間[

]

学部・研究科符号: []、教員（本務）数: []、学生数: 昼間[

]

夜間[

]

学部・研究科符号: []、教員（本務）数: []、学生数: 昼間[

]

夜間[

]

学部・研究科符号: []、教員（本務）数: []、学生数: 昼間[

]

夜間[

]

学部・研究科符号: []、教員（本務）数: []、学生数: 昼間[

]

夜間[

]

学部・研究科符号: []、教員（本務）数: []、学生数: 昼間[

]

夜間[

]

学部・研究科符号: []、教員（本務）数: []、学生数: 昼間[

]

夜間[

]

学部・研究科符号: []、教員（本務）数: []、学生数: 昼間[

]

夜間[

]

学部・研究科符号: []、教員（本務）数: []、学生数: 昼間[

]

夜間[

]

学部・研究科符号: []、教員（本務）数: []、学生数: 昼間[

]

夜間[

]

学部・研究科符号: []、教員（本務）数: []、学生数: 昼間[

]

夜間[

]

学部・研究科符号: []、教員（本務）数: []、学生数: 昼間[

]

夜間[

]

学部・研究科符号: []、教員（本務）数: []、学生数: 昼間[

]

夜間[

]

2 貴機関の「個人情報保護方針」について下記にお答えください。
2.1 貴機関では、全学的な「個人情報保護方針」を作成していますか？

☐はい
298

☐いいえ
（
「はい」の場合は 2.2 へ、「いいえ」の場合は 3 へ）
2.2 貴機関の「個人情報保護方針」には、個人情報の利用目的が明示されていますか？

☐はい
☐いいえ
2.3 貴機関の「個人情報保護方針」には、取扱いの対象となる個人情報が明確に定義されていますか？

☐はい☐いいえ
2.4 貴機関の「個人情報保護方針」には、個人情報の漏えい、滅失またはき損、不正利用の防止など安全管理措置について記されていますか？

☐はい
☐いいえ
2.5 貴機関の「個人情報保護方針」には、個人情報保護に関する問い合わせ及び苦情の受付窓口が明記されていますか？

☐はい
☐いいえ
2.6 貴機関の「個人情報保護方針」は、関係者に周知し、一般に公開されていますか？

☐はい
☐いいえ
3 貴機関の個人情報保護のための組織・体制、行動計画について下記の質問にお答えください。
3.1 個人情報を扱う情報システムの運用管理責任者は定められていますか？

☐すべてのシステムで定められている☐一部定められていないものもある☐定められていない
3.2 個人情報を扱う情報システムの情報セキュリティ対策のための組織はありますか？

☐すべてのシステムに対策組織がある
299

☐一部定められていないものもある☐情報セキュリティ対策組織はない
3.3 個人情報を扱う情報システムの適用業務に関する利用者側である各部門の個人情報責任者は明確になっていますか？

☐すべてのユーザ部門において個人情報責任者が定められている。
☐一部定められていない部門もある☐個人情報責任者は定められていない
3.4 個人情報保護のための監査を実施していますか？

☐はい
☐いいえ
3.5 個人情報取扱責任者・担当者ための教育・訓練を実施していますか？

☐はい
☐いいえ
3.6 情報システム部門に対する個人情報保護に係る教育・訓練を実施していますか？

☐はい
☐いいえ
3.7 個人情報の漏えい等に伴い発生する損害や影響を事前に検討し、そのようなリスクが顕在化した時の緊急時対応のための体制を整備していますか？

☐はい
☐いいえ
3.8 個人情報を取得するにあたり、利用目的を特定するための手続を定めていますか？

☐はい
☐いいえ
3.9 個人情報を適正な方法により取得するための手続を定めていますか？（適正な方法による取得とは、個人情報保護法において定められている手続に基づく取得のことをいいます。
）

☐はい
☐いいえ

300

3.10 個人情報を委託先に提供することがありますか？

☐はい
☐いいえ
（
「はい」の場合は 3.11 へ、「いいえ」の場合は 3.12 へ）
3.11 個人情報を委託先するにあたって、委託先の監督を実施していますか？

☐はい
☐いいえ
3.12 個人情報を第三者に提供する場合は、あらかじめ本人の同意を得ていますか？

☐はい
☐いいえ
3.13 個人情報を第三者に提供するにあたり、本人の同意を得られない場合、オプトア
ウトの措置を講じていますか？（「オプトアウト」：第三者に提供される個人デー
タの項目、提供の手段・方法等を、あらかじめ、本人に通知し、又は本人が容易に知り得る状態に置くとともに、本人の求めに応じて第三者への提供を停止することをいいます。
）

☐はい
☐いいえ
3.14 共同利用を行う際には、共同利用にあたって法定事項を本人に通知・公表する手続きを定めていますか？（法定の通知事項は、共同で利用される個人情報の項目、
共同利用者の範囲、共同で利用する者の利用目的、および共同で利用する者のうち、個人情報の管理について責任を有する者の氏名又は名称となっています。）

☐はい
☐いいえ
4 個人情報を含むシステムのクラウドサービス利用について、下記の質問にお答え下さい。
4.1 貴機関では、個人情報を扱うシステムで、クラウドサービスを使用しているものはありますか？

☐はい☐いいえ
4.2 設問 4.1 で「はい」と答えた方は、具体的なシステム内容を差支えない範囲でご記入下さい。※文字数制限はありません。
301

[

]

5 クラウドサービスと個人情報について、なにかご意見等あれば自由にご記入下さい。

[]

6 その他、ご意見等ございましたらお書き下さい。
[]

質問は以上です。
ご協力、ありがとうございました。

Ver1018302

ネットワーク分野アンケート（ネットワークに係る機関代表部署向け）
本アンケート調査は、文部科学省からの委託事業である平成 25 年度国家課題対応型
研究開発推進事業・アカデミッククラウド環境構築に係るシステム研究「コミュニティ
で紡ぐ次世代大学 ICT 環境としてのアカデミッククラウド」におきまして、ネットワ
ークに係るアカデミッククラウドに対する要求仕様を策定するための参考とさせていただく目的で、各機関の自機関内ネットワーク基盤の管理・運用を担当している部署の方々に、貴組織のネットワーク基盤整備状況等についてお伺いするものです。
自機関内ネットワーク基盤は、アカデミッククラウドが提供する各種サービスの利便性、安全性、快適性等の確保・向上を下支えする重要なインフラであり、その整備状況
がサービス品質に与える影響・効果は小さくありません。本調査では、各組織のネット
ワーク基盤の現状を把握することでアカデミッククラウド構築のためのネットワークの側面からの課題を明確化し、その調査結果をもとに、今後の整備・拡張計画の指針となるネットワークに関する要求仕様を策定する予定です。現状の整備状況に加え、具体的な問題点や今後の整備計画などについても可能な限りお答えいただけますと幸いです。
（注）アカデミッククラウドとは、パブリッククラウドのうち、高等教育機関（全国共同利用情報基盤センター等）が高等教育機関向けに運用するクラウドサービスを指します※アンケートの回答は，特に指定がない限り今年度の状況をご記入下さい。

1 ご回答いただく方の所属機関、部局名等をご記入ください。

必須]

所属機関※大学等の名称[
部局

[

]

※補足・伝達事項等ございましたら、設問 7 にお書きください。
2 自機関内ネットワーク基盤に関して、以下の問いにお答えください。
2.1 自機関内ネットワークのトポロジーは以下のうちどれでしょうか。
□一つの拠点(キャンパス等)のみ□複数拠点間を対等に接続□主たる拠点を中心に，複数の副拠点が接続□上記の混在□その他
2.2 設問 2.1 で「その他」を選択された場合、具体的なトポロジーについてご記載
ください。
303

[

]

2.3 複数の拠点(キャンパス等)を接続している場合，拠点間の接続方法は以下のうちどれでしょうか(複数選択可)。またその帯域はどの程度でしょうか。
□広域イーサネットサービス[ ] [Mbps/Gbps]□フレッツ等のインターネット接続サービス＋インターネット VPN[] [Mbps/Gbps](インターネット接続サービスには[□専用線接続サービス []を利用)] [Mbps/Gbps]□専用線(自営ファイバ)を独自に敷設 [ ] [Mbps/Gbps]□SINET の L2VPN 等を利用 [ ] [Mbps/Gbps](SINET DC までの接続には[

]を利用)

□その他
2.4 設問 2.3 で「その他」を選択された場合、具体的な拠点間接続方法や帯域についてご記載ください。
[]

2.5 自機関内ネットワーク全体のおおよその規模はどの程度でしょうか。わかる範囲でお答え下さい。
■ VLAN 数□1～99 □100～499 □500～999 □1,000～3,999 □4,000 以上□不明■サブネット数□1～99□100～199 □200～499□500～999 □1,000 以上 □不明

2.6 バックボーンネットワークの最大帯域はどの程度でしょうか。
☐～99Mbps □100～499Mbps □500Mbps～999Mbps□1～9Gbps □10Gbps 以上
2.7 バックボーンネットワークのエッジルータ・スイッチへの接続の最大帯域はどの程度でしょうか。
☐～99Mbps □100～499Mbps □500Mbps～999Mbps□1～9Gbps □10Gbps 以上
2.8 自機関内共用のサーバ群やクラウドとバックボーンネットワークとの接続の最大帯域はどの程度でしょうか。
□～99Mbps☐100～499Mbps ☐500Mbps～999Mbps□1～9Gbps □10Gbps 以上
2.9 今後の自機関内ネットワークの構成変更，接続方式変更，帯域拡大等の計画などございましたら自由にご記入ください。
[

]
304

3 自機関ネットワークの機関外への接続に関して、以下の問いにお答えください。
3.1 自機関外との接続はどのように行っていますでしょうか(複数選択可)。
□SINET に接続□商用 ISP に接続□学術用地域 IXP に接続☐その他
3.2 設問 3.1 で「その他」を選択された場合、具体的な学外との接続方法についてご記載ください。
[]

3.3 自機関外との接続帯域はどの程度でしょうか。
□～99Mbps □100～499Mbps ☐500Mbps～999Mbps□1～9Gbps □10Gbps 以上
3.4 今後の自機関外ネットワークへの接続先変更，帯域拡大等の計画などございま
したら自由にご記入ください。
[]

4 ユーザの自機関内ネットワークへの接続サービスに関して、以下の問いにお答えくだ
さい。
4.1 機関全体規模で管理・運営している無線ネットワーク接続サービスを提供されていますでしょうか。
□提供している□提供していない
4.2 eduroam が利用可能でしょうか。
□利用可能□利用できない
4.3 機関外からの VPN 接続サービスは提供されていますでしょうか。
□提供している□提供していない
4.4 今後の自機関内ネットワークへの接続サービスの強化計画などございましたら
自由にご記入ください。
[]

5 すでに自機関外にサーバやクラウドを設置している場合、自機関内ネットワークとの接続に関して、以下の問いにお答えください。
5.1 機関外のサーバやクラウドと学内ネットワークとの接続はどのように行ってい305

ますでしょうか(複数選択可)。
□SINET のネットワーク接続サービス(L2VPN 等)を利用□VPN で接続 (ソフトウェア VPN または VPN 装置を利用)□専用線で接続

専用線の帯域: [ ] [Mbps/Gbps]□自機関内ネットワークとは接続していない□その他
5.2 設問 6.1 で「その他」を選択された場合、具体的な接続方法についてご記載く
ださい。
[

]

6 将来的な自機関内ネットワークのあり方に関して、以下の問いにお答え下さい。
6.1 近々に新規導入、更新、拡張等を計画している場合、可能な範囲でその内容についてご記載ください。
[]

6.2 今後のクラウド利用を想定して、トラヒックの増加、ネットワーク品質の安定化、ネットワーク機能の高度化などに関し、現在の自機関内ネットワークの問題点や、今後発生すると考えられる課題等、懸念される事項があれば自由にご記載ください。
[]

7 その他、ご意見等ございましたらお書きください[]

質問は以上です。
Ver1018

ご協力、ありがとうございました。

306

研究支援分野アンケート（研究支援情報サービス部署向け，システム毎回答）
本アンケート調査は、文部科学省からの委託事業である平成 25 年度国家課題対応型
研究開発推進事業・アカデミッククラウド環境構築に係るシステム研究「コミュニティ
で紡ぐ次世代大学 ICT 環境としてのアカデミッククラウド」におきまして、研究支援に係るアカデミッククラウドに対する要求仕様を策定する参考とさせていただくため、大学等において、研究支援向けの情報関連資源やサービスを提供している部署（情報基盤センター、情報処理センター等）に対して、資源やサービスの提供状況や、アカデミ
ッククラウドに対する要望事項等についてお伺いするものです。対象とするシステムとしては、自機関内共同利用、全国共同利用を想定しており、部署内向け専用システムは
今回の調査の対象外となります。
本調査におけるアカデミッククラウドの位置づけとしては、研究者向けに計算機やサーバ、ストレージ、データベース、ソフトウェア等の情報関連資源を、ポータルからの申請により直ちに使えるサービスを、電気料金程度の安価な使用料で提供する事を主な役割として想定しております。ご協力のほど、よろしくお願い申し上げます。
（注）アカデミッククラウドとは、パブリッククラウドのうち、高等教育機関（全国共同利用情報基盤センター等）が高等教育機関向けに運用するクラウドサービスを指します。

1 ご回答いただく方の所属機関、部局名等をご記入ください。
所属機関※大学等の名称［ここをクリックしてテキストを入力してください。］
部局［ここをクリックしてテキストを入力してください。］※補足・伝達事項等ございましたら、設問 4 にお書きください。
2 研究支援に係る計算資源の共同利用を行っていますか
a. 行っている
b. 行っていない※b.を選択された方は、ここでアンケートは終了です。ありがとうございました。
3 質問 2 で a を選択した場合、システム毎に以下にご回答ください。
3.1 該当するシステム名称と支援する業務内容をご記入ください。
■ システム名称： [ここをクリックしてテキストを入力してください。]■ 主な利用目的： [ここをクリックしてテキストを入力してください。]
例①スパコン（運用毎）
307

②クラウド、ホスティング・大容量ストレージ③データベース（①、②とは別システムとして運用している場合）※異なるシステムを他に利用されている場合は、別の情報として受付いたしますので、お手数でございますが、設問 4 終了後、あらためて同テーマアン
ケートにご回答くださいますようお願い申し上げます。既存データは上書きされることなく、新しいレコードが登録されます。

3.2 共同利用の範囲について
a. 研究機関内部
b. 国内共同利用（学術機関のみ）
c. 国内共同利用（企業等民間も含む）
d. 海外を含む共同利用
e. その他
3.3 質問 3.2 で e を選択した場合、その対象範囲[ここをクリックしてテキストを入力してください。]
3.4 当該システム全体として提供可能な総資源をお知らせください■ 計算性能 [ ] TFlops, コア[ ] MB, GB, TB■ 主記憶■ ストレージ[ ] GB, TB, PB■ その他 [ここをクリックしてテキストを入力してください。]（ソフトウェア、データベースなどその他の提供資源についてご記入ください）
3.5 当該システム全体の資源使用状況について、どの程度変動するでしょうか。ピーク時を 100%とした場合、閑散期の資源使用量をお知らせください。
a. 80% 以上
b. 60% 以上 80％ 未満
c. 40% 以上 60% 未満
d. 40% 未満
3.6 現在利用されているユーザ数と、データの総量、主なフォーマット
■ ユーザ数 [] 名■ データの総量 [] GB, TB, PB■ 主なフォーマット [ここをクリックしてテキストを入力してください。]（複数記述可）3.7 今後のデータ量の増加見込みについて■ [] GB, TB, PB / 年

3.8 データバックアップの現状について
308

a. 原則として行っていない（利用者の責任でバックアップ）
b. 当該部署内でバックアップを取っている。
c. 遠隔バップアップを行っている。
3.9 データバックアップの頻度■ [] 回 / 日, 月, 年

3.10 バックアップデータの保管期間（特に期限が無い場合は「０」としてください）■ [ ] 日, 月, 年
3.11 質問 3.8 で a, b を選択した場合、災害対応など遠隔地へのバックアップについて
a. 可能であれば行いたい
b. 必要ではない
3.12 質問 3.8 で c を選択した場合、そのバックアップ先について
a. 自身で管理運用する遠隔サイト
b. 共同利用サービス等他機関が管理運用する遠隔サイト
c. 商用データセンター、パブリッククラウドサービス等
3.13 組織外へのネットワーク接続について、その接続先および帯域幅■ 接続先 []

■ 帯域幅 [

] Mbps, Gbps

3.14 ネットワーク接続の帯域幅の要求量についてお知らせください。
■ [] Mbps, Gbps

3.15 他組織（他大学、クラウド事業者等）のシステムとの連携について
a. 行っている
b. 行っていない
3.16 質問 3.15 で a を選択した場合、その詳細（連携先、連携対象、連携方式等）
についてお知らせください。
[ここをクリックしてテキストを入力してください。]
3.17 質問 3.15 で b を選択した場合、今後の他組織とのシステム連携について
a. 必要であり、可能であれば行いたい
b. 必要ではない
3.18 質問 3.17 で a を選択した場合、その詳細（連携先、連携対象、連携方式等）
についてお知らせください。
[ここをクリックしてテキストを入力してください。]
3.19 システムの運用にあたり、利用者サポートとして実施していることがあればお願いします。
[ここをクリックしてテキストを入力してください。]
3.20 システムの運用にあたり、抱えている課題、問題点がありましたらお願いしま309

す。
[ここをクリックしてテキストを入力してください。]
3.21 アカデミッククラウドサービス（研究者向けに計算機やストレージ、ソフトウ
ェア等の資源をポータルからの申請により、直ちに使えるサービス）に対す
る要望についてa. 自組織のシステムで十分である
b. アカデミッククラウドサービスが提供されれば移行したい
c. 自組織のシステムと連携したハイブリッドクラウドとして利用したい（負荷が集中した場合やストレージ容量をオーバーした場合の補完など）
3.22 その他アカデミッククラウドに対する期待や要望事項（求められるシステムの内容や条件、要求資源量等）がありましたらお願いします。
[ここをクリックしてテキストを入力してください。]
4 その他、ご意見等ございましたらお書きください[]

質問は以上です。
ご協力、ありがとうございました。

Ver1018310

研究支援分野アンケート（研究者個人向けアンケート）
本アンケート調査は、文部科学省からの委託事業である平成 25 年度国家課題対応型
研究開発推進事業・アカデミッククラウド環境構築に係るシステム研究「コミュニティ
で紡ぐ次世代大学 ICT 環境としてのアカデミッククラウド」におきまして、研究支援に係るアカデミッククラウドに対する要求仕様を策定する参考とさせていただくため、科学研究費補助金の代表者となっている研究者に対して、情報関連資源やクラウドサー
ビスの利用状況や要望事項をお伺いするものです。
本調査におけるアカデミッククラウドの位置づけとしては、研究者向けに計算機やサーバ、ストレージ、データベース、ソフトウェア等の情報関連資源を、ポータルからの申請により直ちに使えるサービスを、電気料金程度の安価な使用料で提供する事を主な役割として想定しております。
現在実施中の課題毎に以下のアンケート項目にご回答をいただければ幸いです。
（注）アカデミッククラウドとは、パブリッククラウドのうち、高等教育機関（全国共同利用情報基盤センター等）が高等教育機関向けに運用するクラウドサービスを指します。
（＊の質問項目につきましては必須となります。その他については任意ですが、可能な範囲で、できるだけご回答をいただければ幸いです。）※科学研究費の代表者になっていらっしゃる方が対象です。
※アンケートの回答は，特に指定がない限り今年度の状況をご記入下さい。

1 科学研究費課題番号＊
2 研究種目＊（文部科学省科学研究費）
a. 特別推進研究
b. 特定領域研究
c. 新学術領域研究
d. 基盤研究 (S)e. 基盤研究 (A)f. 基盤研究 (B)g. 基盤研究 (C)h. 挑戦的萌芽研究
i. 若手研究 (S)311j. 若手研究 (A)k. 若手研究 (B)l. 研究活動スタート支援
m. 奨励研究n. 特別研究促進費
o. 研究成果公開発表
p. 国際情報発信強化
q. 学術定期刊行物
r. 学術図書s. データベース
t. 特別研究員奨励費
u. その他（厚生労働省科学研究費）
v. 行政政策研究分野
w. 厚生科学基盤研究分野
x. 疾病・障害対策研究分野
y. 健康安全確保総合研究分野
z. その他
3 細目番号（＋分類番号）もしくは研究領域番号（新学術領域研究ほか）＊
4 機関番号＊
5 課題に関するデータの総量について、その推定値で結構ですのでお知らせください[] MB, GB, TB, PB ＊6 データの増加見込み量の推定値 [] MB, GB, TB, PB / year, month, day, hour＊

7 データの主な利用者（複数回答可）＊
a. 本人（個人）
b. 研究機関内部
c. 研究機関内部でのグループ
d. 共同利用（特定の関係者、コミュニティでの利用）
e. 委託（共同研究機関の関係者や委託先、アルバイト従事者等）
f. 第三者利用（他機関）
e. 一般公開
8 データに求められるセキュリティレベル（複数回答可） ＊a. 公開情報b. 非公開情報が含まれるが、個人情報等の重要情報は含まれていない
c. 個人情報等の重要情報が含まれている
9 質問 7, 8 で複数回答を選択した場合、それぞれの情報毎の違いについて、その詳細を
312ご記入ください[ここをクリックしてテキストを入力してください。]
10データ処理や計算等に使用している計算機システムの現状について（複数回答可）＊
a. パソコンを使用
b. 研究室、研究課題用のサーバ環境を構築して使用
c. 大学情報基盤センター等が提供するスーパーコンピュータやクラウドサービス等の共同利用サービスを利用
d. 民間データセンターやパブリッククラウドサービスを利用
e. その他
11質問 10 で b.を選択した場合、その資源量についてご記入ください■ 計算性能 [ ] TFlops, コア■ 主記憶[ ] MB, GB, TB■ ストレージ[ ] GB, TB, PB
12質問 10 で b.を選択した場合、その管理について該当するものを選択してください
a. 専任の職員を配置して管理している
b. 教員が研究活動の一環として管理している
c. センターやクラウド事業者、管理委託業者に管理を任せている
d. 学生に管理をまかせている
e. 特に管理していない
13質問 10 で b.を選択した場合、当該システムの構築（調達、設置、設定を含む）にどの程度の期間を要していますか■ [] 日, 月, 年

14質問 10 で c. を選択した場合、その利用資源量についてご記入ください■ 利用センター等 [ ]■ 計算性能：[ ] TFlops, コア■ 主記憶： [ ] MB, GB, TB■ ストレージ：[ ] GB, TB, PB
15質問 10 で d. を選択した場合、その利用資源量についてご記入ください■ 利用サービス名称 [ ]■ 計算性能 [ ] TFlops, コア■ 主記憶[ ] MB, GB, TB■ ストレージ[ ] GB, TB, PB
16質問 10 で e. を選択した場合、その詳細についてご記入ください[ここをクリックしてテキストを入力してください。]
17アカデミッククラウドサービス（研究者向けに計算機やストレージ、ソフトウェア等の資源をポータルからの申請により、直ちに使えるサービス）に対する要望につい313

て（a.を除き複数回答可）＊
a. パソコンによる処理で十分である
b. クラウドサービスではなく自身や自組織内で研究室、研究課題用のサーバ環境を構築したいc. アカデミッククラウドサービスが提供されれば利用したい
d. ハイブリッドクラウドサービス（自身のサーバ、アカデミッククラウド、
パブリッククラウドを相互連携したサービス）が提供されれば利用したい
18質問 17 で b.を選択した場合、その理由についてご記入ください[ここをクリックしてテキストを入力してください。]
19質問 17 で c.を選択した場合、その要求資源量についてご記入ください■ 計算性能 [ ] コア
■ 主記憶

[ ] MB, GB, TB■ ストレージ[ ] GB, TB, PB
20データバックアップの現状について該当するものを選択してください（a.を除き複数回答可）＊
a. バックアップを行っていない
b. CD, DVD, USB メモリ, テープ等のバックアップメディアに取っている
c. 物理的に別のハードディスクや NAS 等にバックアップしているd. 専用のバックアップシステムを自身で構築している
e. 大学情報基盤センター等が提供するスーパーコンピュータやクラウドサービス等の共同利用サービスを利用
f. パブリッククラウドサービスを利用
21質問 20 で e, f を選択した場合、その詳細（サービス提供機関、サービス名称、サービス内容の説明等）をご記入ください[ここをクリックしてテキストを入力してください。]
22データバックアップの頻度はどの程度になりますか■ [ ] 回 / 日, 月, 年
23災害対応のため遠隔地へのバックアップを行っていますか ＊a. 行っている
b. 行っていないが必要性はある
c. 行っておらず、必要性もない
24災害対応のため遠隔地でのバックアップシステムの運用を行っていますか
a.行っていない
b.自身で遠隔システムを構築して運用している
c. パブリッククラウドや商用データセンターで運用している
25バックアップデータの保存期間はどの程度になりますか314

■ [ ] 日, 月, 年
26ネットワークの利用について＊

a. Web ブラウジングなど一般的な利用しか行わない
b. 大容量ファイルの転送等、高速なネットワーク接続が必要である
c. ネットワークや情報システムに関する研究等で、研究内容に応じた環境構
築や設定が必要である
27データ転送量について、その推定値で結構ですので、お知らせください■ [] MB, GB, TB / 日, 月

28ネットワーク接続のセキュリティレベルについて
a.通常のグローバルインターネット接続で十分
b.VPN 等で暗号化通信が必要である
c. 物理的な専用線が必要である
29質問 26 で c.を選択した場合、その詳細（研究内容、システムに対して要求される条件や設定内容）についてご記入下さい[ここをクリックしてテキストを入力してください。]
30研究実施のために利用している PaaS（プラットフォーム）や SaaS（ソフトウェア）のクラウドサービスがあればご記入ください。
[ここをクリックしてテキストを入力してください。]
31研究の実施にあたり、計算処理、データ処理、バックアップ、クラウドサービスの利用など広く情報システムに関連して、現在抱えている課題や問題点について、ご記入ください[ここをクリックしてテキストを入力してください。]
32研究データやコンテンツの共有・利活用に関して、その効果や期待、要望事項がありましたら、ご記入ください。
[ここをクリックしてテキストを入力してください。]
33アカデミッククラウドに対する期待や要望事項（求められるシステムの内容や条件、要求資源量等）について、ご記入ください[ここをクリックしてテキストを入力してください。]
34本アンケートに関する情報の取り扱い、特に自由記述欄の取り扱いについて
a. 課題番号や電子メールアドレスの情報を元に、調査グループ側からのコンタクトにより、自由記述欄などの記述についてヒアリングすることを許可する。
b. データについて統計的に処理することに限定し、ヒアリングについては許可しないが（課題番号や電子メールアドレスについては回答の重複や不正入力の防止にのみ使用する）自由記述欄の情報を公開する事は許可する
c. データについて統計的に処理することに限定し、ヒアリングや自由記述欄
315＊

の公開を許可しない。
（課題番号や電子メールアドレスについては回答の重複や不正入力の防止にのみ使用するとともに、自由記述欄については報告
書作成の参考情報にとどめる）
5 その他、ご意見等ございましたらお書きください[]

質問は以上です。
ご協力、ありがとうございました。

Ver1018316

1.2 各アンケート回答結果
ここでは，以下の各分野について，本文で提示した以外の集計データを示す。
１）コンテンツ分野(当該部署)
コンテンツ分野のアンケートは、ICT サービス分野とそれ以外のコンテンツサービス分
野に分かれている。
コンテンツサービス分野(設問 1)
機関別回答数317

(設問 2)
2.1

2.2

318

2.3

319

320

2.4 と 2.5

2.6(単位:GB)321

2.7 と 2.8

2.9

322

2.10 と 2.11

2.12 と 2.13

323

2.14
 安全性と高度のセキュリティが確保されたプラットフォームであることが望ましいです。また、拡張性にも優れ、独自に開発したプログラムの適用も可能であることと、セキュリティやプラットフォームの標準的な運用・保守のサービスが選択可能であること等が挙げられます。
 データ量の増大にともない、個々の大学での維持管理が困難になってきているので期待したい。
 "・市販（Amazon 等）のクラウドとの機能／価格等の比較でリーズナブルなものを提供して頂きたい。アカデミックである強み（シボレス認証等や、精算方法）を生かし、市販のものとのギャップを埋めてほしい。"
 コスト削減 今後において、本学の全学的情報基盤システムのクラウド環境構築の動向とも関係しますが、時期の図書館システム更新時の導入仕様には、クラウド環境を想定したシステム構成の検討を予定している。
 聴覚・視覚障害者の利用に対する配慮を希望します。
 "・利用料金がパブリッククラウドよりはるかに安価であること。利用料金を含め、ユーザ側が負担するコストを明示すること。データセンターが国内に有り、セキュ
リティレベルが高いこと。個人情報等の取扱い要件を明示し、情報漏洩の防止策が十分にとられていること。一定基準以上の性能のマシンを使用し、既存のシステムが提供するサービスの品質を維持すること。"
 "・利用料金等ユーザ側が負担するコストを明示すこと。データおよび個人情報の取り扱い要件を明示し、情報漏洩防止への対策が十分にとられていること。一定基準
以上の性能マシンを使用し、既存のシステムが提供するサービスの品質を維持すること。"
 研究者が安心して利用できるシステムを構築して頂きたい。
 積極的に展開してほしい 教員の研究成果公開や研究内容の紹介など、教員単位で独自に Web サイトを構築したいという要望が多い。ただスキル格差によるニーズの違いがある（Public
IaaS,CMS,単純な Web サーバ）。自由度とセキュリティが相反する状況で、サポート体制を含めてサービス内容を検討していただきたい。
 研究者、教職員が気軽に使用できるモデルが提供されることを期待します。
 大学間のコンテンツ共有のしくみを希望します 学内で完全なクラウドへの移行にはデータの保全の観点からの反対が多いため、ローカルでもバックアップが取れる様なオプションは必要かと思われます。
 中小規模の機関にとっては独自で動く事が非常に難しいため、NII 等の機関が積極的にサービスを提供してくださることを希望します。
324 長期間安定してサービスを提供していただけないと安心して利用できない
 NII の JAIRO Cloud の拡大を期待しています。
（既存のリポジトリからの参加）
 データの保持性、セキュリティに関して不安が残る。
 規模に関わらず、提供サービス・コスト・導入体制等、柔軟な内容なもの
 "・JAIRO Cloud へのリポジトリ構築済み期間の参加を受け入れていただきたい・ 使用料が無料または安価で継続的にサービス提供していただきたい" 各学校のホームページサービスはアカデミッククラウドで Web サービスを提供してもらいたい。
 積極的に展開してほしい "NII で共通サービスが提供されることが望ましい。"
 NII 等でのクラウドシステムに利用者として期待するのは、システム運用の負担を軽減し、その分コンテンツの充実に注力できることだと考える。現在 NII で運用されている機関リポジトリの JAIRO クラウドはこれを実現しており、このようなクラウドシステムの充実を望む。

325

ICT サービス分野(設問 1)
機関別回答数326

(設問 2 から)
2.1 と 2.2

2.3 と 2.4

327

3.1

3.2

328

3.3

329

3.4 と 3.5

3.6（単位：TB）

330

3.7 と 3.8

3.9

331

3.10 と 3.11

3.12 と 3.13

332

3.14
 あるサービスを Dos 攻撃された場合に，他のサービスが影響を受けることがなければ，
魅力はあります。
 SaaS で提供してほしい。
 現状ではアカデミッククラウド自体のイメージが曖昧な部分がありますが、コストやセキュリティ、柔軟性等の面でパブリッククラウドに対する優位性が提示されれば具体的な検討ができるのではないかと思います。
 遠隔バックアップが一番の課題です。データセンターや商用サービスを借りることは簡単ですが費用的に大変厳しいですので、そうした部分に注力していただきたいと思っています。
 市販（Amazon 等）のクラウドとの機能／価格等の比較でリーズナブルなものを提供して頂きたい。
 アカデミックである強み（シボレス認証等や、精算方法）を生かし、市販のものとのギャップを埋めてほしい。
 セキュリティ対策の観点から、データセンター側のユーザデータをセンター側の管理者でも閲覧できないような仕組み（暗号化等）を整備してほしい。
 コスト削減 アカデミッククラウドに関しては期待しています。当大学としても情報基盤サーバの全面仮想化やオープンソースの積極的な活用など、クラウドサービスに移行しうる体制を整えつつあります。
 ウイルス対策はもちろん、違法ソフト置き場にならないようなシステムを望みます 機器費用低減等のため，クラウドへの期待は大きいのですが，商用クラウド（特にフリーサービス）については学外への機密データ保存やサービス中止等が懸念されるため，大学等学術機関専用共通基盤のようなクラウドが設立になりますと，学内の理解も得やすいかと思われます。また，学外クラウドの場合，通信量も増加するた
め，回線調達についても配慮した形での提供があると敷居が下がるかと思われます。
 Amazon S3 もしくは，Amazon Glacier のようなストレージサービスが欲しい 知識として抽出できるようなデータの取り扱い
 日本の国内法規に準拠するアカデミッククラウドサービスの実現を望みます DNS、認証サーバ、監視用サーバ etc ICT 基盤を運用する為に必要なリソースとしても利用できるクラウド基盤にして欲しい。
 運用コストが低いこと
 "全国的な認証基盤の統合(JMOOC 等のオンライン学習の認証等も含める)、ストレー
ジの継続(大学→大学院、教員の異動時の引き継ぎ)、パブリッククラウドとの連携"
 低価格での提供
333 個人情報が扱えるセキュリティレベルのサービスがあれば利用したい アカデミッククラウド運用管理の視察・見学会に参加したい。
 予算、人員の確保とセキュリティ対策
 機能制限を設けた外部ゲストアカウントを設けてカウンセラーなども参加できるよ
うになるとよい（OpenPNE にはそのような機能はない） 学生（卒業生含む）や教職員のメールアドレスや、課題保存用の領域を提供して頂きたい。課題の自動的分類機能も重要。これができるのは NII だけです。
 IaaS,PaaS はよいが、SaaS は固定化した運用ではなく、自由な構想を持って運用して欲しい。
 ウイルス対策はもちろん、違法ソフト置き場にならないようなシステムを望みます サービスの安定性、サービスの保証（サービスが何かの利用で、提供されなくなることがないようにして欲しい。）

334

２）経営支援分野（当該部署）(設問 1)
機関別回答数335

(設問 2) 注）情報システムは本文では、評価情報システムとしている。
2.1

2.2

2.3

336

2.4 と 2.5

2.6(単位:GB)337

2.7 と 2.8

2.9

338

2.10 と 2.11

2.12 と 2.13

339

2.14
 セキュリティ及び BCP 対策に優れた公的機関のクラウドサービスに期待します。
 機密性や利便性が整備されていること
 クラウドサービスの利用検討にあたっては、以下について保障されていることが前提となります。１．データおよび個人情報の取り扱い要件の明示、情報漏洩防止への対策が十分にとられていること。２．利用料金等の利用者側の負担コストが明示されていること。３．既存のシステムが提供するサービスの品質が維持可能な、システム環境が提供されるていること。
 コスト削減 学内で使用している業務システムも今後はクラウドサービスを利用したい 導入コストの削減

340

３）事務支援分野（当該部署）（設問 1）機関情報a) 回答機関数、回答数（システム数）

機関種別
分類
国立
A
国立
B
国立
C
国立
D
国立小計
公立
A
公立
B
公立
C
公立
D
公立合計
私立
A
私立
B
私立
C
私立
D
私立小計
短大
高専
研究機関
合計

機関数
19
12
23
21
75
1
2
21
22
46
21
44
109
96
270
100
32
7
530

回答数 機関母数
55
19
35
16
72
26
59
25
221
86
4
1
5
6
41
36
26
39
76
82
72
30
89
70
203
269
150
241
514
610
143
355
46
57
13
44
1013
1,234

（設問 2.1）回答システム種別a) 機関種別毎の回答システム数（重複あり）
機関種別 分類 人事給与システム 財務会計システム 学務情報システム 就職支援システム
国立
A
17
19
19
3
国立
B
13
10
10
7
国立
C
23
23
18
9
国立
D
21
21
19
4
国立小計
74
73
66
23
公立
A
1
1
0
1
公立
B
1
2
2
0
公立
C
16
17
17
10
公立
D
10
17
18
4
公立小計
28
37
37
15
私立
A
19
20
22
17
私立
B
32
39
45
35
私立
C
67
84
109
64
私立
D
57
68
86
37
私立小計
175
211
262
153
短大
55
68
80
39
高専
9
12
30
6
研究機関
5
5
0
0
合計
346
406
475
236

341

出退勤システム
7
2
5
1
15
1
0
1
1
3
16
19
35
29
99
17
1
3
138

b) 重複数別のシステム数
重複回答数 合計 人事給与システム 財務会計システム 学務情報システム 就職支援システム
1
697
139
183
234
75
2
136
56
57
83
63
3
76
59
73
66
15
4
61
60
61
60
51
5
32
32
32
32
32

出退勤システム
66
13
15
12
32

（設問 2.2）利用者総数、ピーク時利用者数
利用者総数
人事給与システム 財務会計システム 学務情報システム 就職支援システム
ピーク時利用数～1,000
301
339
298
128
～500
287
319
282
121
～1,0003
8
7
2～5,000
22
40
104
59
～500
12
29
57
42
～1,0007830
9～5,0002
2
14
6～10,000
11
12
32
20
～500
6
6
13
9
～1,0001
1
7
4～5,000
4
5
8
6～10,000
00
3
1
10,001以上
7
10
37
22
～500
1
1
10
4
～1,000
4
4
6
7～5,0001
4
17
8～10,000
00
2
2
10,001以上
0
0
1
0
合計
341
401
471
229

出退勤システム

合計

102
99
1
22
13
6
2
6
3
0
3
0
2
0
1
1
0
0
132

1168
1108
21
247
153
60
26
81
37
13
26
4
78
16
22
31
4
1
1574

115
8
6
0
0

1314
116
83
8
1

a) システム種別毎の利用者総数・ピーク時利用者数別システム数～500～1,000～5,000～10,000
10,001以上

306
15
7
0
0

355
21
11
0
0

362
50
39
5
1

176
22
20
3
0

b) 機関種別毎の利用者総数・ピーク時利用者数別システム数
利用者総数
ピーク時利用数～1,000～500～1,000～5,000～500～1,000～5,000～10,000～500～1,000～5,000～10,000
10,001以上～500～1,000～5,000～10,000
10,001以上
合計

国立

公立
134
128
2
47
31
9
7
16
7
4
2
2
23
8
4
7
2
1
220

私立
59
58
1
13
8
4
1
1
1
0
0
0
2
2
0
0
0
0
75

短大
373
349
10
90
59
19
11
20
9
4
6
1
21
3
8
8
1
0
504

342

高専
115
106
3
15
10
3
0
1
1
0
0
0
4
1
0
3
0
0
135

研究機関
38
33
2
1
1
0
0
2
0
0
1
0
0
0
0
0
0
0
41

合計
10
10
0
2
2
0
0
1
1
0
0
0
0
0
0
0
0
0
13

729
684
18
168
111
35
19
41
19
8
9
3
50
14
12
18
3
1
988

（設問 2.3）システムが利用している計算機資源 ＋ （設問 2.6）データ総量a) 構成種別毎の各システム平均計算機資源量
構成種別
システム独自プライベートクラウド
パブリッククラウド
アカデミッククラウド
その他
全平均

サーバ数

コア数
4.3
3.9
3.4
1.0
1.6
4.4

メモリ
15.7
9.2
10.4
2.0
2.6
15.5

データ量
69.2
27.5
26.3
8.0
5.9
67.0

671.8

b) 計算機資源の構成（トータル）
サーバ数の回答数 475 機関 889 システム
構成種別
システム独自プライベートクラウド
パブリッククラウド
アカデミッククラウド
その他
合計

サーバ数
3,535
296
62
5
29
3,927

CPUコア数
11,313635
146
436
12,134

メモリ
50,136.8
1,900.0
342.3
16.0
65.0
52,460.1

データ量

521,286.2

サーバ1台当たりCPUコア数
メモリ
3.6
16.2
2.8
8.7
2.7
6.5
2.0
8.0
1.6
3.6
3.6
15.5

c) 機関種別毎の各システム平均計算機資源量
機関種別
国立
国立
国立
国立
国立
公立
公立
公立
公立
公立
私立
私立
私立
私立
私立
短大
高専
研究機関

分類

サーバ数

A
B
C
D
平均
A
B
C
D
平均
A
B
C
D
平均

コア数
8.2
3.8
3.4
3.1
4.6
2.5
3.2
3.1
3.9
3.4
9.9
5.4
3.9
2.9
4.8
4.2
1.5
3.1

メモリ
37.2
20.4
12.9
10.9
20.0
9.5
12.0
11.6
11.5
11.5
18.0
25.2
12.1
10.3
14.9
13.6
9.0
10.5

105.3
38.4
25.2
61.5
58.3
22.5
17.2
39.2
84.4
50.2
156.1
56.8
76.1
24.6
69.3
97.5
48.2
24.7

データ量
1,775.0
501.3
228.9
605.7
776.6
61.5
241.7
354.1
276.6
299.8
983.7
329.9
597.4
657.9
616.4
1,040.2
163.3
511.8

68.8
78.7
81.4
76.0
50.6

データ量
924.5
1,000.2
989.0
1,109.3
447.2d) 業務システム毎の平均計算機資源量
業務システム
人事給与システム
財務会計システム
学務情報システム
就職支援システム
出退勤システム

サーバ数

コア数
5.4
5.7
6.1
7.0
6.3

メモリ
18.0
19.9
19.9
21.6
19.9

343

e) 機関種別毎の計算機資源構成別システム数
機関種別
分類
国立
A
国立
B
国立
C
国立
D
国立
合計
公立
A
公立
B
公立
C
公立
D
公立
合計
私立
A
私立
B
私立
C
私立
D
私立
合計
短大
高専
研究機関
合計

システム独自 プライベートクラウド パブリッククラウド アカデミッククラウド
50
6
2
0
31
4
0
0
59
11
0
0
53
5
0
0
193
26
2
0
2
0
1
0
5
0
0
0
29
7
0
1
23
1
0
0
59
8
1
1
59
12
2
0
72
4
2
0
180
7
4
1
108
10
2
1
419
33
10
2
107
9
6
2
27
0
1
0
13
0
0
0
818
76
20
5

その他
1
0
1
0
2
2
0
0
1
3
1
1
3
5
10
1
2
0
18

f) システム種別毎の計算機資源構成別システム数
機関種別
人事給与システム
財務会計システム
学務情報システム
就職支援システム
出退勤システム

システム独自 プライベートクラウド パブリッククラウド アカデミッククラウド
280
26
9
3
332
32
8
3
410
28
12
2
172
17
7
4
106
14
6
0

その他
10
8
6
5
4

g) 機関種別毎のサーバ台数別システム数
機関種別
分類
国立
A
国立
B
国立
C
国立
D
国立
合計
公立
A
公立
B
公立
C
公立
D
公立
合計
私立
A
私立
B
私立
C
私立
D
私立
合計
短大
高専
研究機関
合計

1

2

3

7
4
19
16
46
1
1
10
3
15
12
25
62
57
156
32
17
4
270

4

11
6
16
11
44
1
2
9
7
19
11
11
37
25
84
27
10
3
187

3
9
8
11
31
1
0
6
4
11
9
13
26
7
55
17
3
2
119

5以上10未満
13
10
17
12
52
0
1
6
5
12
8
12
32
14
66
18
0
4
152

10以上

5
4
2
7
18
1
1
4
5
11
7
5
17
11
40
14
0
0
83

5以上10未満
45
77
106
54
14

10以上

20
26
61
22
8

15
0
2
1
18
0
0
1
1
2
19
12
11
7
49
9
0
0
78

h) システム種別毎のサーバ台数別システム数
機関種別
人事給与システム
財務会計システム
学務情報システム
就職支援システム
出退勤システム

1

2
108
83
80
33
37

3
54
67
79
27
25

344

4
42
58
48
23
17

36
43
60
30
15

i) 計算機資源その他の内容の分類
分類番号

分類
1 ASP・外部クラウド
2 独自・ローカル
3 国立高専機構
4 不明
5 その他

回答数
19
7
5
2
1

j) 利用者数別の計算機資源量
ピーク時利用者数～500～1,000～5,000～10,000
10,001以上

サーバ数

利生者総数
～1,000～5,000～10,000
10,001以上

サーバ数

3.9
5.5
9.6
7.2
11.0

3.5
5.3
7.3
12.7

CPUコア数
13.3
20.6
35.2
56.4
61.0

メモリ容量
65.2
42.5
95.4
83.6
112.0

データ量
569.1
818.7
538.9
1,916.4
2,130.0

CPUコア数
11.3
19.5
33.3
42.6

メモリ容量
62.2
61.2
59.1
154.2

データ量
572.6
540.6
1,013.3
2,106.8k) 利用者数別の 1 サーバ当たりの計算機資源量

ピーク時利用者数～500～1,000～5,000～10,000
10,001以上

サーバ数

利生者総数
～1,000～5,000～10,000
10,001以上

サーバ数

CPUコア数

3.9
5.5
9.6
7.2
11.0

3.5
3.7
3.4
7.8
5.5

メモリ容量
17.2
7.5
9.4
11.6
10.2

3.5
3.5
4.5
3.3

メモリ容量
19.2
11.1
8.1
12.0

CPUコア数

3.5
5.3
7.3
12.7

l) 利用者数毎の構成別サーバ数
ピーク時利用者数～500～1,000～5,000～10,000
10,001以上

システム独自
2,700
327
319
26
11

プライベートクラウド
208
30
47
10
0

パブリッククラウド
40
6
15
0
0

345

アカデミッククラウド
4
1
0
0
0

その他
25
0
4
0
0

利生者総数～1,000～5,000～10,000
10,001以上

システム独自
2,096
643
275
507

プライベートクラウド
163
78
11
44

パブリッククラウド
12
29
0
21

アカデミッククラウド
4
1
0
0

その他
25
4
0
0

（設問 2.4）パブリッククラウド IaaS/ PaaS 利用意向
a) 機関種別毎のパブリッククラウド IaaS/PaaS 利用意向
機関種別 分類
国立
A
国立
B
国立
C
国立
D
国立
合計
公立
A
公立
B
公立
C
公立
D
公立
合計
私立
A
私立
B
私立
C
私立
D
私立
合計
短大
高専
研究機関
合計

既に利用、継続

既に利用、拡大

1
1
1
1
4
2
0
0
0
2
1
2
5
5
13
3
0
0
22

既に利用、縮小

1
0
0
0
1
0
0
0
0
0
0
1
0
1
2
0
0
0
3

利用計画あり

0
0
0
0
0
0
0
0
0
0
0
0
1
0
1
0
0
0
1

積極的に利用したい できれば利用したい 利用しない、課題あり

1
0
1
0
2
0
0
0
0
0
0
3
5
1
9
1
0
0
12

1
2
0
0
3
0
0
0
0
0
7
0
8
3
18
7
2
0
30

11
6
18
15
50
0
1
9
7
17
17
23
64
45
149
44
11
4
275

その他

23
9
34
26
92
1
1
11
12
25
22
41
87
50
200
47
13
5
382

回答なし

16
17
16
16
65
1
3
20
7
31
21
14
28
35
98
35
13
4
246

計画年後(平均）

1
0
2
1
4
0
0
1
0
1
4
5
5
10
24
6
7
0
42

1.0
0.0
3.0
0.0
2.0
0.0
0.0
0.0
0.0
0.0
0.0
1.7
2.2
1.0
1.9
2.0
0.0
0.0
1.9

b) 業務システム毎のパブリッククラウド IaaS/PaaS 利用意向
業務システム
人事給与システム
財務会計システム
学務情報システム
就職支援システム
出退勤システム

既に利用、継続

既に利用、拡大

既に利用、縮小

7
5
10
7
6

2
3
1
1
2

1
1
1
1
1

利用計画あり積極的に利用したい できれば利用したい 利用しない、課題あり

4
4
10
3
2

8
8
10
7
7

103
127
158
80
35

その他

133
148
172
76
50

回答なし

76
97
99
49
25

計画年後(平均）

12
13
14
12
10

1.8
1.1
2.0
1.7
1.5

c) 既に利用しているが、今後は縮小、または、利用をやめたい理由
機関種別
私立
私立

理由
分類 業務システム種別
コスト面と運用の手間を考慮した結果
C
全システム複合D
学務情報システム 特にその必要性がない。

d) 今後も利用しない、あるいは、課題があって利用するのは難しい理由回答数

268e) 機関種別毎のパブリッククラウドを今後も利用しない、あるいは、課題があって利用するのは難しい理由内訳
機関種別 分類 セキュリティ不安、課題あり
国立
A
13
国立
B
5
国立
C
11
国立
D
8
国立
合計
37
公立
A
0
公立
B
0
公立
C
9
公立
D
6
公立
合計
15
私立
A
9
私立
B
12
私立
C
38
私立
D
9
私立
合計
68
短大
11
高専
3
研究機関
1
合計
135
50.4%

コスト・予算なし

0
0
11
3
14
0
0
0
1
1
2
4
6
4
16
6
0
0
37
13.8%

信頼性不安

0
0
0
0
0
0
0
0
1
1
2
0
3
1
6
0
0
1
8
3.0%

性能・ネットワーク不安

仕様制約・移行課題あり

必要なし／必要度低い

0
0
3
3
6
0
0
0
0
0
2
0
3
1
6
0
0
0
12
4.5%

0
2
1
2
5
0
0
0
0
0
4
5
7
2
18
0
0
0
23
8.6%

6
2
9
4
21
1
0
0
0
1
2
12
9
14
37
5
3
0
67
25.0%

346

未検討／計画なし

1
0
0
0
1
0
0
1
2
3
0
0
4
2
6
3
0
0
13
4.9%

メリットが不明

0
0
1
0
1
0
0
0
1
1
0
0
0
0
0
0
0
0
2
0.7%

回答なし

2
0
8
9
19
0
1
1
3
5
4
9
30
18
61
22
5
2
114
42.5%

f) 務システム毎のパブリッククラウドを今後も利用しない、あるいは、課題があって利用するのは難しい理由内訳
業務システム
人事給与システム
財務会計システム
学務情報システム
就職支援システム
出退勤システム

セキュリティ不安、課題あり

コスト・予算なし

49
41
64
24
14

12
13
16
7
7

信頼性不安

性能・ネットワーク不安

仕様制約・移行課題あり

必要なし／必要度低い

3
4
4
0
1

6
7
11
7
3

18
29
21
9
6

2
3
4
0
0

未検討／計画なし

メリットが不明

2
5
7
2
1

0
2
1
0
0

回答なし

47
49
57
31
19

g) 利用者数に対するパブリッククラウドを今後も利用しない、あるいは、課題があって利用するのは難しい理由内訳
ピーク時利用者数 セキュリティ不安、課題あり～500
116～1,00012～5,0001～10,000
1
10,001以上
0

コスト・予算なし

利用者総数～1,000～5,000～10,000
10,001以上

セキュリティ不安、課題あり

コスト・予算なし

103
21
4
7

26
7
2
1

信頼性不安

28
3
4
0
0

性能・ネットワーク不安

仕様制約・移行課題あり

必要なし／必要度低い

未検討／計画なし

メリットが不明

9
1
2
0
0

17
3
2
1
0

62
2
1
0
1

11
1
1
0
0

1
1
0
0
0

性能・ネットワーク不安

仕様制約・移行課題あり

必要なし／必要度低い

未検討／計画なし

メリットが不明

9
3
0
0

17
3
3
0

50
13
2
2

10
2
0
1

1
1
0
0

7
1
0
0
0

信頼性不安

8
0
0
0

回答なし

97
10
1
0
0

回答なし

93
11
6
3

h) パブリッククラウド利用意向のその他詳細回答数

239i) 機関種別毎のパブリッククラウド利用意向その他の内訳
機関種別 分類
国立
A
国立
B
国立
C
国立
D
国立
合計
公立
A
公立
B
公立
C
公立
D
公立
合計
私立
A
私立
B
私立
C
私立
D
私立
合計
短大
高専
研究機関
合計

未検討・不明・計画なし

検討中／検討予定

13
5
11
8
37
0
0
9
6
15
9
12
38
9
68
11
3
1
135

0
0
11
3
14
0
0
0
1
1
2
4
6
4
16
6
0
0
37

課題有／不安

要件に合えば

0
0
0
0
0
0
0
0
1
1
2
0
3
1
6
0
0
1
8

必要なし／必要度低い

0
0
3
3
6
0
0
0
0
0
2
0
3
1
6
0
0
0
12

0
2
1
2
5
0
0
0
0
0
4
5
7
2
18
0
0
0
23

j) 業務システム毎のパブリッククラウド利用意向その他の内訳
業務システム
人事給与システム
財務会計システム
学務情報システム
就職支援システム
出退勤システム

未検討・不明・計画なし

検討中／検討予定

49
41
64
24
14

12
13
16
7
7

347

課題有／不安

要件に合えば2
3
4
00

必要なし／必要度低い

3
4
4
0
1

6
7
11
7
3

（設問 2.5）アカデミッククラウド IaaS/ PaaS 利用意向
a) 機関種別毎のアカデミッククラウド IaaS/PaaS 利用意向
機関種別
分類
国立
A
国立
B
国立
C
国立
D
国立
合計
公立
A
公立
B
公立
C
公立
D
公立
合計
私立
A
私立
B
私立
C
私立
D
私立
合計
短大
高専
研究機関
合計

積極的に利用したい できれば利用したい
1
15
0
6
0
28
1
17
2
66
0
0
0
1
0
11
0
9
0
21
3
25
3
22
13
71
3
54
22
172
6
49
1
13
0
4
31
325

利用しない

その他

20
8
21
23
72
1
1
9
11
22
12
42
73
41
168
41
10
5
318

回答なし
18
21
22
17
78
3
3
20
6
32
28
15
34
42
119
39
15
4
287

1
0
1
1
3
0
0
1
0
1
4
7
12
10
33
8
7
0
52

b) 業務システム毎のアカデミッククラウド IaaS/PaaS 利用意向
業務システム
人事給与システム
財務会計システム
学務情報システム
就職支援システム
出退勤システム積極的に利用したい できれば利用したい
11
125
12
149
14
189
6
93
10
51

利用しない
109
121
136
61
40

その他

回答なし
88
110
115
60
29

13
14
21
16
8

c) 今後も利用しない、あるいは、課題があって利用するのは難しい理由回答数

216d) 機関種別毎のアカデミッククラウドを今後も利用しない、あるいは、課題があって利用するのは難しい理由内訳
機関種別 分類 セキュリティ不安、課題あり
国立
A
6
国立
B
4
国立
C
8
国立
D
8
国立
合計
26
公立
A
0
公立
B
0
公立
C
7
公立
D
5
公立
合計
12
私立
A
4
私立
B
12
私立
C
35
私立
D
3
私立
合計
54
短大
10
高専
2
研究機関
1
合計
105

コスト・予算なし

0
0
5
0
5
0
0
0
1
1
1
5
4
4
14
5
0
0
25

信頼性不安

性能・ネットワーク不安

0
0
0
0
0
0
0
2
1
3
0
0
2
1
3
0
0
1
7

0
0
4
0
4
0
0
2
0
2
0
0
2
1
3
0
0
0
9

348

仕様制約・移行課題あり 必要なし／必要度低い

0
2
1
0
3
0
0
0
0
0
3
4
6
2
15
0
0
0
18

9
2
5
4
20
1
0
0
0
1
1
12
8
13
34
4
2
0
61

未検討／計画なし

1
0
0
0
1
0
0
0
1
1
0
0
4
1
5
2
0
0
9

メリットが不明

回答なし

1
0
1
0
2
0
0
1
1
2
0
0
2
0
2
0
0
0
6

2
0
5
11
18
0
1
1
5
7
3
10
22
17
52
19
4
2
102

e) 業務システム毎のアカデミッククラウドを今後も利用しない、あるいは、課題があって利用するのは難しい理由内訳
業務システム
人事給与システム
財務会計システム
学務情報システム
就職支援システム
出退勤システム

セキュリティ不安、課題あり

コスト・予算なし

44
36
47
19
11

信頼性不安

7
9
11
2
8

性能・ネットワーク不安

1
2
4
1
0

仕様制約・移行課題あり 必要なし／必要度低い

2
2
3
1
1

6
6
7
7
4

未検討／計画なし

17
26
18
8
5

2
2
6
2
1

メリットが不明

回答なし

2
4
3
0
1

34
39
48
24
11

f) アカデミッククラウド利用意向のその他詳細回答数

279g) 機関種別毎のアカデミッククラウド利用意向その他の内訳
機関種別 分類
国立
A
国立
B
国立
C
国立
D
国立
合計
公立
A
公立
B
公立
C
公立
D
公立
合計
私立
A
私立
B
私立
C
私立
D
私立
合計
短大
高専
研究機関
合計

未検討・不明・計画なし

検討中／検討予定

11
13
12
8
44
2
0
14
3
19
17
8
18
20
63
20
3
1
150

3
5
8
7
23
0
3
2
2
7
0
3
2
2
7
4
0
1
42

課題有／不安

要件に合えば

3
4
4
0
11
0
0
2
0
2
2
0
3
4
9
0
0
0
22

必要なし／必要度低い

4
1
8
0
13
0
0
3
0
3
9
5
8
12
34
10
1
2
63

0
0
0
0
0
1
0
0
0
1
0
1
0
1
2
0
1
0
4

h) 業務システム毎のアカデミッククラウド利用意向その他の内訳
業務システム
人事給与システム
財務会計システム
学務情報システム
就職支援システム
出退勤システム

未検討・不明・計画なし

検討中／検討予定

45
50
59
29
18

13
27
13
8
2

（設問 2.6）システムで保有するデータの総量a) 利用者別、データ量別システム数349

課題有／不安

要件に合えば

68
6
4
1

必要なし／必要度低い

20
23
29
17
7

1
2
2
2
0

利用者総数ピーク時利用数～1,000～500～1,000～5,000～500～1,000～5,000～10,000～500～1,000～5,000～10,000
10,001以上～500～1,000～5,000～10,000
10,001以上
合計

～5GB

～10GB

107
100
3
23
13
7
3
3
1
1
1
0
6
4
1
1
0
0
139

～50GB

43
41
2
11
8
1
1
3
3
0
0
0
1
1
0
0
0
0
58

105
101
2
25
15
6
4
3
0
2
0
0
10
6
1
3
0
0
143

～100GB～500GB

66
64
1
8
7
1
0
5
1
3
0
1
2
0
0
2
0
0
82

140
132
5
36
24
8
4
9
4
1
3
1
11
2
2
6
1
0
198

～1TB

～5TB
58
52
1
14
10
3
1
3
2
0
1
0
6
0
3
2
1
0
81

～10TB
35
33
0
12
10
1
1
10
8
1
1
0
5
1
1
2
0
1
62

10TB～
4
4
0
0
0
0
0
1
0
0
0
1
1
0
1
0
0
0
6

5
5
0
1
0
1
0
0
0
0
0
0
1
0
0
0
0
0
7

b) 業務システム種別毎のデータ量別システム数
機関種別
人事給与システム
財務会計システム
学務情報システム
就職支援システム
出退勤システム

～5GB
32
43
47
22
35

～10GB
13
18
27
11
6

～50GB
45
47
57
25
18

～100GB
29
28
42
20
5

～500GB
74
76
97
37
20

～1TB

～5TB
34
41
48
22
8

～10TB
26
39
40
26
12

10TB～
4
5
5
3
0

2
3
5
3
0

(設問 2.7)ログイン認証のためのアカウント管理方法a) 機関種別毎のログイン認証のためのアカウント管理方法
機関種別

分類

国立
A
国立
B
国立
C
国立
D
国立
小計
公立
A
公立
B
公立
C
公立
D
公立
小計
私立
A
私立
B
私立
C
私立
D
私立
小計
短大
高専
研究機関
合計

統合認証情報と直接接続

バッチで統合認証情報と同期

28
16
27
24
95
1
4
13
15
33
46
51
97
68
262
71
11
5
477

SAML等による認証連携

6
0
2
2
10
0
0
3
1
4
6
5
16
11
38
11
3
1
67

その他

4
3
1
4
12
0
0
1
0
1
1
1
1
2
5
2
1
0
21

25
21
45
34
125
3
1
23
7
34
20
34
78
58
190
40
21
7
417

b) 業務システム毎のログイン認証のためのアカウント管理方法
業務システム

人事給与システム
財務会計システム
学務情報システム
就職支援システム
出退勤システム

統合認証情報と直接接続

バッチで統合認証情報と同期

150
189
284
131
73

19
25
39
24
11

350

SAML等による認証連携

8
10
16
8
1

その他

164
164
137
73
50

c) アカウント管理方法その他の分類

分類
1 独自・ローカル
2 AD・ASP・IaaS
3 不明
4 その他

回答数

分類番号

336
13
52
16

d) アカウント管理方法その他の内容一覧
分類 業務システム種別

その他内容

国立
国立
国立
公立

D
D
D
C

人事給与
就職支援
学務情報
人事給与

私立

C

財務会計

私立
私立
私立
私立
私立
私立
私立
私立
短大
国立
国立
国立

B
D
D
B
D
D
D
C

出退勤
就職支援
出退勤
出退勤
学務情報
就職支援
出退勤
就職支援
出退勤
学務情報
就職支援
人事給与

ＵＮＩＸユーザ管理
ＵＮＩＸユーザ管理
ＮＩＳ
ユーザーADPSにパスワードにより入る
会計システムはログイン画面のユーザー名とパスワードをデータベースで管理。ＷＥＢ予算
システムはＷＥＢデータベースサーバで管理。通信はＳＳＬを使用。
独自実装＋ＣＡＳ
IaaS側の認証による磁気カードによる認証
ICカードによる認証
POP認証
POP認証
ICカード認証専用端末からログイン
磁気カードによる認証
ＮＩＳ
ＵＮＩＸユーザ管理
ＵＮＩＸユーザ管理

機関種別

D
D
D

（設問 2.8）データバックアップ先a) 機関種別毎のデータバックアップ先
機関種別

分類

国立
国立
国立
国立

A
B
C
D
国立小計
公立
A
公立
B
公立
C
公立
D
公立小計
私立
A
私立
B
私立
C
私立
D
私立小計
短大
高専
研究機関
合計

バックアップ取得なし

自部署のストレージ

プライベイトクラウド

1
0
1
1
3
0
0
0
0
0
0
3
2
4
9
1
2
0
15

47
32
61
56
196
2
5
35
26
68
62
73
178
124
437
115
27
12
855

2
0
6
5
13
0
0
3
0
3
6
5
2
1
14
5
2
0
37

パブリッククラウド

2
1
1
0
4
0
0
0
0
0
1
6
5
6
18
6
0
0
28

アカデミッククラウド

その他

0
2
0
4
6
0
0
1
0
1
0
3
3
2
8
1
0
0
16

7
8
8
1
24
2
0
3
0
5
7
6
21
11
45
9
9
1
93

b) 業務システム毎のデータバックアップ先
業務システム

人事給与システム
財務会計システム
学務情報システム
就職支援システム
出退勤システム

バックアップ取得なし

自部署のストレージ

プライベイトクラウド

パブリッククラウド

アカデミッククラウド

1
4
5
3
3

295
351
426
180
112

12
15
12
10
6

12
12
14
12
4

3
6
9
5
1

351

その他

36
40
34
29
15

c) データバックアップ先その他の分類

分類内容
1 回答なし・不明
2 学内メディア3 学外メディア・クラウド
4 その他

分類番号

回答数
12
28
51
2

352

d) データバックアップ先その他の内容一覧
機関種別
国立
国立
国立
国立
国立
国立
国立
国立
国立
国立
国立
国立
国立
国立
国立
国立
国立
国立
国立
国立
国立
国立
国立
国立
公立
公立
私立
私立
私立
私立
私立
私立
私立
私立
私立
私立
私立
私立
私立
私立
私立
私立
私立
私立
私立
私立
私立
私立
私立
私立
私立
私立
私立
私立
私立
私立
私立
私立
私立
私立
私立
私立
私立
私立
私立
私立
私立
私立
私立
私立
私立
短大
短大

分類
A
B
C
C
A
C
C
C
B
B
A
A
A
B
B
B
B
B
A
A
D
C
C
C
A
A
D
D
D
C
C
C
A
B
B
B
C
C
D
D
C
C
C
C
A
A
A
A
A
C
C
A
C
C
B
B
B
C
D
C
C
C
D
C
D
D
D
D
C
C
C

業務システム種別
人事給与
就職支援
人事給与
財務会計
財務会計
就職支援
財務会計
人事給与
財務会計
人事給与
学務情報
学務情報
人事給与
人事給与
財務会計
学務情報就職支援
学務情報就職支援
人事給与
就職支援
学務情報
学務情報
人事給与
財務会計
学務情報
人事給与
出退勤
財務会計
人事給与財務会計
人事給与財務会計学務情報就職支援
学務情報
就職支援
就職支援
財務会計
学務情報
学務情報
就職支援
財務会計
人事給与財務会計学務情報就職支援出退勤
学務情報
学務情報
人事給与財務会計学務情報就職支援出退勤
人事給与財務会計学務情報就職支援出退勤
人事給与財務会計学務情報就職支援出退勤
人事給与財務会計学務情報就職支援出退勤
人事給与財務会計学務情報就職支援出退勤
人事給与
財務会計
就職支援
出退勤
出退勤
人事給与財務会計
財務会計
財務会計学務情報
就職支援
人事給与
財務会計学務情報就職支援出退勤
財務会計
学務情報就職支援
人事給与財務会計出退勤
就職支援
人事給与財務会計学務情報
学務情報
人事給与
学務情報
人事給与
財務会計
学務情報
就職支援
人事給与財務会計出退勤
人事給与財務会計出退勤
人事給与財務会計学務情報就職支援
学務情報
就職支援

短大

人事給与財務会計就職支援出退勤

短大
短大
短大
短大
短大
短大
高専
高専
高専
高専
高専
高専
高専
高専
高専
研究機関
公立
公立
公立

就職支援
財務会計学務情報就職支援
人事給与財務会計学務情報就職支援
人事給与財務会計学務情報
就職支援
人事給与財務会計出退勤
学務情報
就職支援
人事給与財務会計
人事給与
財務会計
学務情報
財務会計
学務情報
人事給与財務会計
財務会計
財務会計
人事給与
人事給与

C
C
C

その他内容
不明
バックアップしたメディアを一定期間他キャンパスに保存
バックアップメディアを一定期間他キャンパスで保存
パブリッククラウド利用について検討中
他機関で管理するバックアップメディア
民間業者にバックアップデータの管理を委託
システム部門で管理するバックアップメディア
自機関で管理するNASを利用
自機関で管理するNASを利用
他部署のハードディスク
他部署のハードディスク
情報担当部署で実施するバックアップシステムに依存
バックアップしたメディアを県外施設へ移送・保管
バックアップしたメディアを県外施設へ移送・保管
バックアップメディアを県外の施設に移送・保管
バックアップメディアを県外の施設に移送・保管
バックアップメディアを県外の施設に移送・保管
契約企業内でバックアップ
業者（株式会社●●●によりバックアップを行っている）
APS型のサービスを利用
他大学との相互バックアップ
他大学との相互バックアップ
他大学との相互バックアップ
プライベートクラウドサービスを利用
プライベートクラウドサービスを利用
USBメモリ他システムとは異なるアカウントを使用
自機関のバックアップサーバー
保守業者によるバックアップ
外部ASPサービス
外部ＡＳＰサービス
遠隔地へのデータ保管を開始予定
コールドスタンバイ環境へのバックアップ（同期）コールドスタンバイ環境へのバックアップ（同期）
外部ASPサービス
大学構内にある総合情報管理ｾﾝﾀｰにて別途バックアップをしている。
バックアップサーバを学内に設置してそこにバックアップ
パブリックサービス内で実現
パブリックサービス内で実現システムを運用しているデータセンター
システムを運用しているデータセンター
システムを運用しているデータセンター
システムを運用しているデータセンター
独自に契約している民間のBCPサイト
独自に契約している民間のBCPサイト
独自に契約している民間のBCPサイト
独自に契約している民間のBCPサイト
ＤＢﾃﾞｰﾀのみ保守管理会社のリモートバックアップを利用
ＤＢﾃﾞｰﾀのみ保守管理会社のリモートバックアップを利用
ASPのため不明
外部へのメディアでの預け入れ
外部ＡＳＰサービス
データーセンター内の自組織用バックアップメディア
データーセンター内の自組織用バックアップメディア
法人内の別大学にて保管
外部記憶装置（LTO）
キャンパス間バックアップ他
キャンパス間バックアップ他
コールドスタートデータベースサーバーを構築している。
業務パッケージ会社
サーバ室内で管理するNAS
サーバ室内で管理するNAS
サーバ室内で管理するハードディスク
サーバ室内で管理するハードディスク業者によるバックアップ（APS)
勤怠管理はクラウド業者
外付HDDを利用
保守業者によるバックアップ
外部ＡＳＰサービス
システムは、学校法人●●●にて導入しており、それを１事業所として運用していますので、詳細は不明です。
特になし
学校法人本部で集中バックアップ
遠隔地保管サービスを利用
キャンパス間バックアップ他
キャンパス間バックアップ他
勤怠管理はクラウド業者
ホスティングサービスが提供するサーバ内（毎日）。保守業者サーバ内（週1回）。メディアへのバックアップ（月1回、保守業者が学校に提出）
機構本部で管理しているため、詳細は不明である。
サーバ本体を高専機構本部が管理し、全高専が共通利用
サーバーセンター格納サーバーにてバックアップ
契約企業
国立高専機構本部が運営しているため各高専では不明。
システムは高専機構本部で構築している
システム保守業者が委託管理しているバックアップサーバ
月に一度、ｼｽﾃﾑのﾊﾞｯｸｱｯﾌﾟﾃﾞｰﾀを遠隔地の大阪に輸送・管理[バックアップテープを使用
委託先データセンターにてバックアップを取得

353

（設問 2.9）業務アプリケーションの状況
a) 機関種別毎の業務アプリケーションの状況
機関種別

分類

フルスクラッチ

国立
国立
国立
国立

A
B
C
D
国立小計
公立
A
公立
B
公立
C
公立
D
公立小計
私立
A
私立
B
私立
C
私立
D
私立小計
短大
高専
研究機関
合計

7
5
5
2
19
0
0
7
1
8
19
14
27
22
82
14
4
3
130

オープンソース活用

業務パッケージ利用

0
1
0
0
1
1
0
0
1
2
0
1
2
2
5
2
1
0
11

45
24
62
55
186
3
5
33
24
65
45
66
156
108
375
101
26
9
762

SaaS

その他

0
1
1
0
2
0
0
0
0
0
2
4
2
6
14
2
0
0
18

回答なし

1
1
2
2
6
0
0
0
0
0
0
2
8
2
12
5
2
0
25

カスタマイズなし

2
3
2
0
7
0
0
1
0
1
6
2
8
10
26
19
13
1
67

6
3
9
9
27
0
1
8
4
13
4
10
24
26
64
24
0
1
129

カスタマイズ少

10
11
32
34
87
2
3
13
12
30
12
25
61
32
130
29
12
8
296

カスタマイズ大

20
7
13
3
43
1
1
5
5
12
22
26
34
19
101
22
10
0
188

b) 業務システム毎の業務アプリケーションの状況
業務システムフルスクラッチ

オープンソース活用

業務パッケージ利用

28
45
66
34
17

3
3
7
1
5

278
318
360
157
96

人事給与システム
財務会計システム
学務情報システム
就職支援システム
出退勤システム

SaaS

その他

4
6
6
10
3

回答なし

10
14
8
15
7

23
20
28
19
10

カスタマイズなし

カスタマイズ少カスタマイズ大

58
44
51
27
24

115
144
129
62
31

54
71
107
41
18

c) オープンソース名称回答数

8d) オープンソース一覧とカスタマイズ状況
分類番号

1
2
3
4
5
6
7

オープンソース名称
MySQL
TimePro-XG
MOSP（MIND社）
Apache HTTPD,Tomcat,PostgreSQL、Sｔruｔｓ2、Spring3、Hibernate3,dojotoolkit
PHP、ZendFramework、Apache、postgresql
OpenStackRuby on Rails354

利用システム数
2
1
1
1
1
1
1

e) 業務アプリケーションパッケージ名称回答数

535f) 業務アプリケーションパッケージ一覧と利用状況
分類番号

06
16
08
01
02
12
11
10
18
17
21
15
23
33
19
20
22
25
14
05
26
27
29
07
13
28
30
35
24
31
32
34
36
37
38
03
04
09
99

利用システム数 なし
73
25
64
3
50
14
41
5
31
2
21
15
18
1
17
1
16
0
15
7
15
0
14
1
13
6
12
0
11
0
11
6
10
2
9
0
8
0
6
0
5
0
4
0
4
0
3
0
3
0
3
0
3
0
3
1
2
0
2
1
2
0
2
0
2
1
2
0
2
2
1
0
1
0
1
0
67
8

少
28
29
11
25
19
2
4
12
4
5
6
11
3
7
4
3
5
2
3
3
3
1
1
3
0
2
0
1
0
0
2
0
1
0
0
1
1
1
25

対象業務
学務、教務、学生支援、財務会計、人事給与818 学務、教務
17 学務、教務、就職支援、財務会計、人事給与
6 人事給与、就業管理
7 財務会計2 人事給与12 学務情報
3 財務会計、人事給与
7 人事給与、就業管理、学務
0 財務会計、人事給与、学務情報
6 給与、会計、学務、就職
1 学務、教務、学生支援、財務会計、人事給与
1 出退勤
3 給与、財務
2 給与、財務
1 給与、会計
1 給与
4 財務、学務、就職
2 学務情報0 財務会計0 就職
1 学務
1 財務、学務
0 財務会計
3 財務会計
0 学務
1 学務
0 出退勤
2 学務
0 出退勤
0 財務
2 学務、就職
0 就職支援2 財務、学務、就職
0 給与
0 人事給与
00 財務会計21

大355g) SaaS サービス名称回答数

10h) SaaS サービス名称一覧
分類番号

1
2
3
4
5
6
7
8

利用システム数
1
1
1
3
1
1
1
1

i) その他詳細回答数

24j) その他詳細分類
分類番号

1
2
3
4

利用システム数
5586k) 利用者総数毎のカスタマイズ度合別システム数

利生者総数～1,000～5,000～10,000
10,001以上

カスタマイズなし

カスタマイズ少

109
13
2
4

233
50
9
3

356

カスタマイズ大

120
37
14
17

l) パッケージ毎・機関種別毎のシステム数（利用システム数の降順）
分類番号

06
16
08
01
02
12
11
10
18
17
21
15
23
33
19
20
22
25
14
05
26
27
29
07
13
28
30
35
24
31
32
34
36
37
38
03
04
09
99

合計
73
64
50
41
31
21
18
17
16
15
15
14
13
12
11
11
10
9
8
6
5
4
4
3
3
3
3
3
2
2
2
2
2
2
2
1
1
1
67

国立
A

国立
B
0
0
2
6
9
8
5
3
0
0
1
0
0
0
1
0
0
0
2
0
0
0
0
0
2
0
0
0
0
0
1
0
0
0
0
0
1
0
3

国立
C

国立
D

合計

2
0
4
13
7
4
0
6
0
0
3
0
0
0
3
0
0
0
4
2
0
0
0
0
0
0
0
0
0
1
0
0
1
0
0
0
0
0
9

5
0
3
12
5
0
0
5
0
0
4
0
0
0
2
0
0
0
1
1
0
0
0
1
0
0
0
0
0
1
0
0
0
0
0
0
0
1
1

9
0
9
37
25
15
6
16
1
0
10
0
0
0
6
0
0
0
8
3
0
0
0
1
2
0
0
0
0
2
2
0
1
0
0
0
1
1
14

2
0
0
6
4
3
1
2
1
0
2
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
1

公立
A

公立
B
0
0
0
0
1
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1

公立
C
1
0
0
0
0
0
1
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
2
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0

公立
D
3
2
1
0
3
0
1
1
2
0
0
1
0
0
1
0
0
3
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
0
3

私立
A

合計
1
2
3
0
0
0
1
0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
5

5
4
4
0
4
0
3
1
2
0
0
1
1
0
2
0
0
4
0
0
0
0
0
2
0
0
0
0
0
0
0
0
0
0
0
1
0
0
9

私立
B
1
4
7
0
0
2
1
0
5
0
0
0
2
1
0
0
3
0
0
0
1
0
1
0
0
0
0
1
1
0
0
1
0
0
0
0
0
0
1

6
8
7
0
0
3
2
0
1
1
0
1
2
5
0
0
1
1
0
0
3
0
1
0
0
0
0
1
1
0
0
0
1
2
0
0
0
0
3

私立
私立
短大
高専 研究機関
C
D
合計
26
12
45
14
0
0
18
15
45
15
0
0
10
6
30
6
1
0
0
0
0
0
2
2
0
1
1
0
0
1
0
0
5
1
0
0
5
0
8
1
0
0
0
0
0
0
0
0
2
1
9
4
0
0
8
3
12
3
0
0
3
2
5
0
0
0
7
3
11
2
0
0
5
0
9
2
0
1
3
1
10
2
0
0
3
0
3
0
0
0
4
6
10
1
0
0
3
2
9
1
0
0
3
1
5
0
0
0
0
0
0
0
0
0
0
0
0
0
3
0
0
1
5
0
0
0
0
0
0
0
4
0
0
1
3
1
0
0
0
0
0
0
0
0
0
0
0
0
1
0
1
2
3
0
0
0
3
0
3
0
0
0
0
0
2
1
0
0
0
0
2
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
2
0
0
0
0
0
1
0
0
0
0
0
2
0
0
0
0
1
1
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
11
9
24
8
11
1

A

B
1
4
9
6
10
10
6
3
5
0
1
0
3
1
1
0
3
0
2
0
1
0
1
0
2
0
0
1
1
0
1
1
0
0
0
0
1
0
5

C
9
8
7
6
4
6
4
2
2
1
2
1
2
5
1
0
1
1
1
0
3
0
1
2
0
0
0
1
1
0
1
0
1
2
0
0
0
0
4

D
31
20
15
13
10
4
6
7
4
8
6
8
5
3
7
4
3
6
4
2
0
0
0
0
0
1
3
0
0
1
0
1
1
0
0
1
0
0
23

対象業務
18 学務、教務、学生支援、財務会計、人事給与
17 学務、教務
12 学務、教務、就職支援、財務会計、人事給与
12 人事給与、就業管理
6 財務会計
0 人事給与1 学務情報5 財務会計、人事給与
1 人事給与、就業管理、学務
3 財務会計、人事給与、学務情報
6 給与、会計、学務、就職
3 学務、教務、学生支援、財務会計、人事給与
0 出退勤
1 給与、財務
2 給与、財務
6 給与、会計
2 給与
2 財務、学務、就職
1 学務情報1 財務会計
1 就職
0 学務
1 財務、学務
1 財務会計
0 財務会計
2 学務
0 学務
0 出退勤
0 学務
1 出退勤
0 財務
0 学務、就職
0 就職支援0 財務、学務、就職
1 給与
0 人事給与0
1 財務会計15m) パッケージ毎、利用者総数別のシステム数（利用システム数の降順）
分類番号

06
16
08
01
02
12
11
10
18
17
21
15
23
33
19
20
22
25
14
05
26
27
29
07
13
28
30
35
24
31
32
34
36
37
38
03
04
09
99

合計
73
64
50
41
31
21
18
17
16
15
15
14
13
12
11
11
10
9
8
6
5
4
4
3
3
3
3
3
2
2
2
2
2
2
2
1
1
1
67

～1,000
40
51
33
37
20
16
2
14
14
15
3
10
13
11
11
11
9
7
0
4
1
4
4
3
1
2
3
1
1
2
2
1
0
0
1
1
1
1
55

～5,000
25
12
13
4
9
3
6
3
1
0
6
4
0
0
0
0
1
2
5
1
3
0
0
0
0
1
0
2
0
0
0
1
1
0
0
0
0
0
8

～10,000
6
1
2
0
1
0
3
0
0
0
4
0
0
0
0
0
0
0
2
0
0
0
0
0
0
0
0
0
1
0
0
0
1
0
0
0
0
0
1

10,001以上
対象業務
2 学務、教務、学生支援、財務会計、人事給与
0 学務、教務
2 学務、教務、就職支援、財務会計、人事給与
0 人事給与、就業管理
1 財務会計2 人事給与
7 学務情報0 財務会計、人事給与
1 人事給与、就業管理、学務
0 財務会計、人事給与、学務情報
2 給与、会計、学務、就職
0 学務、教務、学生支援、財務会計、人事給与
0 出退勤
1 給与、財務
0 給与、財務
0 給与、会計
0 給与
0 財務、学務、就職
1 学務情報0 財務会計
1 就職
0 学務
0 財務、学務
0 財務会計2 財務会計
0 学務
0 学務
0 出退勤
0 学務
0 出退勤
0 財務
0 学務、就職
0 就職支援2 財務、学務、就職
0 給与
0 人事給与
00 財務会計2357

（設問 2.10）SaaS 利用意向
a) 機関種別毎のパブリッククラウド SaaS 利用意向
機関種別
分類
国立
A
国立
B
国立
C
国立
D
国立
合計
公立
A
公立
B
公立
C
公立
D
公立
合計
私立
A
私立
B
私立
C
私立
D
私立
合計
短大
高専
研究機関
合計

既に利用、継続
0
0
2
0
2
0
0
0
0
0
5
6
9
7
27
7
1
0
37

既に利用、縮小
0
0
0
1
1
0
0
0
0
0
0
0
0
0
0
0
0
0
1

利用計画あり
0
0
0
2
2
0
0
0
0
0
1
3
3
5
12
2
1
0
17

積極的に利用したい
7
10
13
9
39
0
1
11
5
17
10
13
50
38
111
32
8
1
208

利用しない

その他

23
8
33
23
87
1
3
9
12
25
18
41
79
39
177
46
13
6
354

回答なし
24
17
20
23
84
3
1
20
9
33
33
19
51
50
153
44
14
6
334

計画年後(平均）

1
0
4
1
6
0
0
1
0
1
5
7
11
11
34
12
9
0
62

0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
2.0
2.0
2.2
2.0
2.0
2.0
6.0
0.0
2.3

b) 業務システム毎のパブリッククラウド SaaS 利用意向
業務システム
人事給与システム
財務会計システム
学務情報システム
就職支援システム
出退勤システム

既に利用、継続
13
14
15
13
4

既に利用、縮小
100
00

利用計画あり791153

積極的に利用したい
81
96
117
56
35

利用しない
119
133
150
65
50

その他

回答なし
103
128
155
79
32

計画年後(平均）

22
26
27
18
14

2.0
1.8
2.6
2.5
1.7

c) 既に利用しているが、今後は縮小、または、利用をやめたい理由
機関種別
国立

D

理由
分類 業務システム種別
人事給与システム 可能であれば、教育研究用とは別のクラウドで運用したいd) 今後も利用しない、あるいは、課題があって利用するのは難しい理由回答数354e) 機関種別毎のパブリッククラウド SaaS を今後も利用しない、あるいは、課題があって利用するのは難しい理由内訳
機関種別
分類
国立
A
国立
B
国立
C
国立
D
国立
合計
公立
A
公立
B
公立
C
公立
D
公立
合計
私立
A
私立
B
私立
C
私立
D
私立
合計
短大
高専
研究機関
合計

セキュリティ課題

コスト・予算なし

7
4
8
5
24
0
0
7
6
13
6
6
32
3
47
9
2
1
96

1
0
7
1
9
0
0
0
2
2
2
6
2
4
14
3
0
0
28

信頼性不安

2
0
0
3
5
0
0
0
1
1
2
0
2
0
4
0
0
1
11

性能・ネットワーク不安

仕様制約・移行性課題 必要なし／必要度低い

0
0
4
4
8
0
0
0
0
0
0
1
0
0
1
1
0
1
11

358

2
3
5
0
10
0
0
0
1
1
1
1
11
1
14
3
0
0
28

7
0
8
3
18
1
0
1
0
2
1
8
4
10
23
7
1
2
53

未検討／計画なし

1
1
1
2
5
0
0
0
2
2
1
3
8
4
16
3
1
0
27

メリットが不明

2
0
1
0
3
0
0
0
0
0
1
0
5
1
7
1
0
0
11

回答なし

3
0
7
11
21
0
3
1
4
8
6
18
30
17
71
22
9
3
134

f) 業務システム毎のパブリッククラウド SaaS を今後も利用しない、あるいは、課題があって利用するのは難しい理由内訳
業務システム
人事給与システム
財務会計システム
学務情報システム
就職支援システム
出退勤システム

セキュリティ課題

コスト・予算なし

40
27
42
16
9

8
13
14
4
8

信頼性不安

性能・ネットワーク不安

5
3
3
1
1

仕様制約・移行性課題 必要なし／必要度低い

6
5
2
0
1

9
7
14
8
3

未検討／計画なし

14
26
11
7
10

メリットが不明

8
11
11
2
4

回答なし

0
2
5
1
3

45
57
63
30
18

g) パブリッククラウド SaaS 利用意向のその他詳細回答数

322h) 機関種別毎のパブリッククラウド SaaS 利用意向その他の内訳
機関種別 分類
国立
A
国立
B
国立
C
国立
D
国立
合計
公立
A
公立
B
公立
C
公立
D
公立
合計
私立
A
私立
B
私立
C
私立
D
私立
合計
短大
高専
研究機関
合計

できれば利用したい

未検討・不明

2
0
1
4
7
0
0
0
0
0
9
2
6
1
18
1
0
0
26

検討中・検討したい

12
13
14
14
53
3
0
14
5
22
18
13
23
24
78
27
14
3
197

セキュリティ課題

7
3
3
5
18
0
1
4
3
8
0
1
8
17
26
7
0
1
60

コスト課題

2
1
1
3
7
0
0
2
0
2
0
3
5
0
8
1
0
0
18

AP課題

0
0
0
4
4
0
0
2
0
2
2
1
4
2
9
4
0
0
19

4
1
2
0
7
0
0
2
0
2
6
3
6
2
17
4
0
2
32

i) 業務システム毎のパブリッククラウド SaaS 利用意向その他の内訳
業務システム
人事給与システム
財務会計システム
学務情報システム
就職支援システム
出退勤システム

できれば利用したい

未検討・不明671184検討中・検討したい

55
67
85
42
20

セキュリティ課題

22
32
30
13
2

コスト課題

6
9
12
5
0

AP課題

7
8
12
5
1

12
15
12
8
3

（設問 2.11）BCP 対策意向a) 機関種別毎の BCP 対策必要性、実施状況等
機関種別
分類
国立
A
国立
B
国立
C
国立
D
国立
合計
公立
A
公立
B
公立
C
公立
D
公立
合計
私立
A
私立
B
私立
C
私立
D
私立
合計
短大
高専
研究機関
合計

継続稼働レベル
13
7
28
21
69
3
1
9
3
16
11
27
65
34
137
43
8
5
278

データ維持レベル
36
24
40
36
136
1
3
27
19
50
49
52
121
93
315
69
24
8
602

必要なし
0
0
0
0
0
0
0
1
0
1
1
2
2
2
7
5
0
0
13

その他
4
2
0
1
7
0
1
2
4
7
3
5
6
6
20
6
6
0
46

回答なし
2
2
4
1
9
0
0
2
0
2
8
3
9
15
35
20
8
0
74

359

既に実施
9
10
10
8
37
3
0
6
3
12
26
17
32
23
98
20
3
3
173

計画あり
7
5
9
4
25
0
0
2
0
2
12
10
18
5
45
6
1
0
79

将来実施したい
28
16
51
43
138
1
4
28
17
50
24
52
130
99
305
92
28
9
622

回答なし
6
0
1
2
9
0
0
0
2
2
0
1
10
4
15
4
1
1
32

計画年後(平均）

1.2
1.0
3.4
1.0
1.6
0.0
0.0
0.0
0.0
0.0
2.1
1.2
2.6
1.3
1.8
1.1
1.0
0.0
1.1

b) 業務システム毎の BCP 対策必要性、実施状況等
業務システム
人事給与システム
財務会計システム
学務情報システム
就職支援システム
出退勤システム

継続稼働レベル
102
108
151
66
42

データ維持レベル
207
247
279
141
76

必要なし
1
2
4
1
6

その他
14
25
17
10
2

回答なし
22
24
24
18
12

既に実施
56
70
79
50
27

計画あり
29
28
48
25
7

将来実施したい
219
246
298
135
88

回答なし
15
19
12
4
1

計画年後(平均）c) BCP 対策が必要ない理由回答数

9d) BCP 対策が必要ない理由一覧
機関種別
私立
私立
私立
私立
私立
私立
短大
短大
短大

分類
B
B
C
D
C
D

業務システム種別
出退勤
就職支援
学務情報
出退勤
学務情報
出退勤
人事給与財務会計
学務情報
出退勤

理由
手作業代行で対応可能
外部委託のため、部局としては不要
紙（原紙）あり
災害時に出退勤を考えなければいけないほどではない。
必要ない
代替手段があるため業者に委託
紙（原紙）あり代替手段があるため

e) BCP 対策必要性その他詳細回答数

41f) BCP 対策必要性その他詳細の分類

要望分類
1 外部委託2 そのほか
3 不明
4 検討中・計画がない

分類番号

回答数
13
1
5
22

360

1.7
1.5
1.8
1.6
2.3

g) BCP 対策必要性その他詳細一覧
理由
今後検討の余地あり
月に一度、ｼｽﾃﾑのﾊﾞｯｸｱｯﾌﾟﾃﾞｰﾀを遠隔地の大阪に輸送・管財務会計
理
人事給与財務会計学務情報
検討中
人事給与財務会計学務情報
検討中
人事給与財務会計学務情報
BCP対策の必要性等について検討を行っていない。
財務会計学務情報
検討していない
人事給与財務会計学務情報就職支援
計画していない
就職支援
IaaS側の仕様による
出退勤
学内で各業務のBCP対策の指針がない
財務会計
学内で各業務のBCP対策の指針がない
人事給与
学内で各業務のBCP対策の指針がない
就職支援
SaaS側の対策に依存している
就職支援
回答できない
人事給与財務会計機構本部の意向に従うことになる。
財務会計学務情報
未検討
学務情報
よく分からない
就職支援
現在のところ計画はありません
人事給与
未検討
財務会計
国立高専機構本部が運営しているため各高専では不明。
財務会計
管理委託業者に任せている
財務会計
管理委託業者に任せている
財務会計
管理委託業者に任せている
財務会計
管理委託業者に任せている
財務会計
管理委託業者に任せている
財務会計
ASP側で実施
財務会計
サーバ自体が高専機構本部にあり高専が共通利用
人事給与
サーバ本体を高専機構本部が管理し、全国高専が共通利用
学務情報
検討には至っていないため不明
学務情報
検討していない
就職支援
十分な検討が必要
学務情報
十分な検討が必要
財務会計
十分な検討が必要
財務会計学務情報
検討していない
学務情報
想定する災害の規模による学務情報
未検討
システムは、学校法人●●●にて導入しており、それを１事業
人事給与財務会計就職支援出退勤所として運用していますので、詳細は不明です。
就職支援
不明
就職支援
不明
学務情報
検討していない
人事給与財務会計学務情報就職支援
検討中
人事給与財務会計
システムは高専機構本部で構築している

機関種別 分類 業務システム種別
公立
C
人事給与
公立

C

私立
短大
公立
国立
私立
短大
国立
国立
国立
私立
短大
高専
短大
高専
私立
国立
高専
私立
私立
私立
私立
私立
私立
高専
高専
国立
私立
私立
私立
私立
公立
公立
国立

D
D
D
C
A
A
A
D

D
A
B
B
B
B
B
C

B
C
A
A
A
D
D
B

短大
短大
私立
私立
公立
高専

C
C
D

h) BCP 対策実施にあたっての課題や要望等回答数

49i) BCP 対策実施にあたっての課題や要望の分類

要望分類
1 費用が課題
2 規則整備が課題
3 遠隔地（場所）が課題
4 そのほか・不明

分類番号

回答数
14
5
7
23
361

（設問 2.12）運用体制と稼働
a) 機関種別毎の運用形態と稼働
機関種別
分類
国立
A
国立
B
国立
C
国立
D
国立
合計
公立
A
公立
B
公立
C
公立
D
公立
合計
私立
A
私立
B
私立
C
私立
D
私立
合計
短大
高専
研究機関
合計

教職員のみ
38
23
54
52
167
1
0
18
8
27
27
33
113
83
256
61
19
0
530

システム数
委託業者のみ 教職員＋委託業者
3
10
5
1
4
12
4
2
16
25
1
2
5
0
13
5
10
4
29
11
13
18
31
12
40
25
18
22
102
77
33
23
7
5
5
3
192
144

その他
0
3
0
1
4
0
0
0
0
0
3
3
1
2
9
6
4
1
24

回答なし
4
3
2
0
9
0
0
5
4
9
11
10
24
25
70
20
11
4
123

教職員のみ
2.6
1.0
1.4
1.8
1.7
2.0
0.0
1.3
1.6
1.5
1.7
2.5
3.7
2.5
1.9
2.1
1.7
0.0
1.8

平均稼働（人年）
委託業者のみ 教職員＋委託業者
1.0
3.3
1.0
3.0
1.0
1.5
1.1
5.2
1.1
2.5
0.2
2.5
0.7
0.0
1.4
1.8
1.2
6.7
1.2
3.4
2.3
7.6
1.4
3.3
1.1
3.8
0.9
2.0
1.8
4.3
2.3
3.5
1.0
1.2
0.7
2.3
1.7
3.7

その他
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0

トータル平均
2.7
1.1
1.4
1.9
1.8
1.8
0.7
1.4
2.2
1.6
3.7
3.0
2.1
1.8
2.4
2.4
1.5
1.5
2.1

その他

回答なし 教職員のみ
44
1.9
41
2.1
44
2.2
30
2.1
26
1.7

平均稼働（人年）
委託業者のみ 教職員＋委託業者
2.0
4.5
2.1
4.1
1.9
4.0
2.0
4.6
2.0
5.5

その他
0.0
0.0
0.0
0.0
0.0

トータル平均
2.4
2.5
2.5
2.7
2.5

その他
回答なし 教職員のみ
18
77
1.7
1
18
1.7
0
3
2.2
3
4
3.9

平均稼働（人年）
委託業者のみ 教職員＋委託業者
1.5
3.7
2.0
2.7
1.5
4.2
4.0
5.1

その他
0.0
0.0
0.0
0.0

トータル平均
2.0
2.0
2.5
4.2

b) 業務システム毎の運用形態と稼働
業務システム
人事給与システム
財務会計システム
学務情報システム
就職支援システム
出退勤システム

システム数
教職員のみ 委託業者のみ 教職員＋委託業者
180
67
47
198
91
66
262
86
77
108
45
46
72
17
20

8
10
6
7
3

c) 利用者総数毎の運用形態と稼働
利生者総数～1,000～5,000～10,000
10,001以上

システム数
教職員のみ 委託業者のみ 教職員＋委託業者
389
144
101
92
30
27
24
7
7
24
10
9

d) 機関種別と運用形態毎の平均サーバ数
機関種別
分類
国立
A
国立
B
国立
C
国立
D
国立
合計
公立
A
公立
B
公立
C
公立
D
公立
合計
私立
A
私立
B
私立
C
私立
D
私立
合計
短大
高専
研究機関
合計

教職員のみ
9.1
3.4
3.3
3.1
4.6
1.0
0.0
3.0
4.4
3.4
4.2
7.2
3.3
2.8
3.8
3.6
1.6
0.0
3.9

平均サーバ数
委託業者のみ 教職員＋委託業者
5.0
7.7
4.7
6.0
1.5
3.8
2.8
4.5
3.6
5.5
3.0
3.0
3.2
0.0
3.1
4.0
3.0
5.0
3.1
4.2
7.7
20.8
3.3
6.5
3.3
8.2
3.9
3.4
4.0
9.9
4.2
6.3
1.1
2.0
3.4
3.3
3.7
7.6

362

その他
0.0
4.0
0.0
2.0
3.5
0.0
0.0
0.0
0.0
0.0
4.7
1.0
0.0
3.5
3.0
3.8
0.0
2.0
3.2

回答なし
2.0
4.7
0.0
0.0
3.3
0.0
0.0
2.8
4.0
3.3
8.0
5.5
2.6
2.2
3.7
3.0
1.0
2.8
3.5

e) 業務システムと運用形態毎の平均サーバ数
業務システム
人事給与システム
財務会計システム
学務情報システム
就職支援システム
出退勤システム

教職員のみ
5.1
5.6
5.4
6.3
4.9

平均サーバ数
委託業者のみ 教職員＋委託業者
3.7
10.7
3.8
9.5
4.9
10.8
4.1
11.5
2.9
16.3

f) サーバ台数毎の平均稼働
サーバ台数
1台
2台
３台
４台
5台
6台以上

平均稼働（人年）
1.19
1.50
1.80
1.85
2.47
2.66

g) 教職員の全運用稼働
1,207.7 人年（635 システム）h) サーバ数と運用稼働両方の回答がったシステム
733 システム、3,366 サーバ、運用稼働 1,571.7 人年（2.13）アカデミッククラウドに対する要望
a) 機関種別毎の要望数
機関種別 分類
国立
A
国立
B
国立
C
国立
D
国立小計
公立
A
公立
B
公立
C
公立
D
公立小計
私立
A
私立
B
私立
C
私立
D
私立小計
短大
高専
研究機関
合計

要望数
10
1
11
7
29
0
0
1
2
3
6
4
5
7
22
3
3
0
60

363

その他
3.2
2.8
3.0
6.3
2.0

回答なし
3.3
4.2
4.3
4.8
3.8

b) 業務システム種別毎の要望数
業務システム
人事給与システム
財務会計システム
学務情報システム
就職支援システム
出退勤システム

要望数
22
27
33
14
5

c) 要望分類
分類番号

1
2
3
4
5
6

要望分類
特になし
コスト
セキュリティ
SaaS、クラウド
性能、ネットワーク
その他

回答数
25
9
12
6
2
8

364

d) 要望一覧
機関種別 分類
公立
D
国立
D
国立
D
国立

A

私立

B

私立

C

私立

C

私立
国立
国立
国立
国立
私立
私立
私立

C
C
C
C
C
A
A
A

国立

C

国立
私立

A
B

要望
業務システム種別
人事給与財務会計学務情報
信頼できるPaaS, IaaSを安価に提供してほしい。
学務情報
告知して欲しい。
財務会計
0
財務会計などの業務システムでは、教職員全体で利用することになるが、その動作に関しては十分なレスポンスが求められる。また、個人情報を取り扱うため
財務会計
セキュリティが確保されている必要がある。
SaaSやASPｻｰﾋﾞｽを基本としているため現段階ではIaaSやPaaSの環境を事務
人事給与財務会計学務情報就職支援
支援ｼｽﾃﾑで利用することは難しい。今後の展開に期待する。
出退勤
財務と会計を統合したクラウドシステムを期待いたします
文科省への統計調査などが自動集計され個々の大学での集計作業を不要とす
学務情報る方向を実現していただきたい
人事給与財務会計学務情報
セキュリティ・独自性・ＢＣＰ（災害時のスタンドアロン）
就職支援
コスト削減
学務情報
コスト削減
財務会計
コスト削減
人事給与
コスト削減
学務情報
強固なセキュリティと大容量のサービス提供。
財務会計
強固なセキュリティと大容量のサービス提供。
人事給与出退勤 強固なセキュリティと大容量のサービス提供
大学の所在地の災害時にでも対応できる方策を考えていく必要があり、そのよ
学務情報
うな面でクラウド化に期待する。
学務情報
バックアップも含め、安価で柔軟な運用が可能なサービスを期待する
財務会計学務情報就職支援
応答時間と可用性に優れたもの
私立大学では、国立大学と会計基準が異なるため、大学全体のSaaSにはなりえない。私立大学は、規模の大小のバリエーションが大きいため、大規模大学と小規模大学が同じサービスをノンカスタマイズで使用することはなかなか難し
いのではないか。こうした規模の違いをどう救うかが、アカデミッククラウドに求められるひとつの要因だと思われる。

私立

A

財務会計

国立
国立
私立
公立
私立

A
A
A
C
A

国立

A

国立
国立

A
A

国立

C

財務会計
SaaSで提供してほしい。
人事給与
SaaSで提供してほしい。
財務会計学務情報 教職協働で使用可能なストレージやグループウェアの作成
財務会計
現行運用の維持と費用対効果が最大の課題になると思います。
学務情報
カスタマイズは可能でしょうか。
人給システムでは扱うデータのほとんどが個人情報であり、それらに対するセキュリティ強化やリクスマネジメントが強く求められます。特にアカデミッククラウ
ドでは国立大学の研究データ等も含め非常に多くのデータが集約されると思い
人事給与財務会計学務情報
ますが、それらを狙った標的型攻撃が予想されますので、より強固なセキュリ
ティであることを期待いたします。また、各利用機関の担当者がシステムメンテ
ナンスのためサーバーへアクセスする際には、迅速に接続が行える環境であると良いと思います。
出退勤
セキュリティ対策やサービスレベルの維持が担保されること。
人事給与
明確なセキュリティ対策やサービスレベルの維持が担保されること。
○セキュアな環境構築。○障害発生が少なく、ストレスなく業務が行える通信
学務情報
環境の維持。

私立D

セキュリティ対策やシステム障害に関する対策が十分であり、そのことによって
人事給与財務会計学務情報就職支援
各大学が被害を受けることがないこと

短大
私立
高専

D

学務情報就職支援 導入コストの削減
学務情報
データの機密性が担保できれば利用を検討したい
財務会計
既に高専機構本部のサーバー上のサービスを利用している。

国立

A

各大学の独自性を損なわないように柔軟に対応できる環境を構築していただき
人事給与財務会計学務情報
たい

短大
私立

D

人事給与財務会計学務情報就職支援
低コストで利用できるようにしてほしい
人事給与財務会計学務情報就職支援
低コストで利用できるようにしてほしい（その他ご意見等）
a) その他ご意見分類
意見分類
1 特に無し2 再提出、修正
3 該当機関ではない
4 アンケートの回答に対する特記事項
5 一部不明、回答不可能な箇所あり
6 ご意見
7 その他

回答数

分類番号

23
21
3
40
18
3
4

365

b) その他ご意見一覧
意見機関種別 分類
業務システム種別
私立
D
人事給与財務会計学務情報●●●大学が所属する学校法人名
私立
C
学務情報
●●●大学が所属する学校法人名
公立
D
人事給与財務会計学務情報
OS, DBを自由に選べるようにしてほしい。
短大
人事給与財務会計学務情報就職支援出退勤設問2は●●●大学との合計数値
高専
学務情報
本アンケートの設問の多くは、専門的知識を必要とするため、回答できません。
同一敷地内で先に設立された●●●大学と共通事務・システム運用を行ってお
短大
就職支援
りますので申し添えます。
同一敷地内で先に設立された●●●大学と共通事務・システム運用を行ってお
短大
学務情報
りますので申し添えます。
同一敷地内で先に設立された●●●大学と共通事務・システム運用を行ってお短大
財務会計りますので申し添えます。
同一敷地内で先に設立された●●●大学と共通事務・システム運用を行ってお短大
人事給与りますので申し添えます。
公立
C
財務会計
2.6. システムで保有するデータ＝バックアップ対象データとしています。
公立
C
人事給与
（当該業務は，アウトソーシングしております。）
私立
C
学務情報
学務情報システムは大学と短大で共用。
高専
人事給与財務会計学務情報就職支援
システムは高専機構本部の運用
高専で使用している事務支援システム（人事給与システム、財務会計システム）は機構本部で管理・運営されており、詳細はセキュリティ等の関係で各高専
高専
人事給与財務会計に伝えられておりません。また、今後の計画についても機構本部で検討した結果に従って実施されることになります。
人事給与システムと財務会計システムも導入されているが全国高専が共通のシステムを利用しており、導入・管理等については国立高等専門学校機構本部
高専
学務情報が一元的に行っているため、回答出来ない。
短大
出退勤
大学と短期大学部での切り分けが不可能なため、同じ回答となっています。
短大
人事給与
大学と短期大学部での切り分けが不可能なため、同じ回答となっています。
未回答の設問については、設問内容が該当しない又はわからないため回答を短大
人事給与財務会計
控えます。
未回答の設問については、設問内容が該当しない又はわからないため回答を
短大
学務情報
控えます。
未回答の設問については、設問内容が該当しない又はわからないため回答を
私立
C
人事給与財務会計
控えます。
未回答の設問については、設問内容が該当しない又はわからないため回答を
私立
C
学務情報
控えます。
人事給与・財務会計システムは高専機構本部で管理しているため、２ ２.２以降
高専
人事給与財務会計は不明。なお、分かる範囲で回答していますので、回答内容に矛盾等がございましたらご容赦願います。
高専
私立

A

学務情報

私立
短大
国立

B

出退勤
学務情報就職支援
出退勤

短大

A

学務情報

国立高等専門学校は機構本部による運用であるため、各校対象の調査はなじみません。したがって上記について回答はいたしません。
設問2.3・2.6・2.12については、●●●大学および●●●大学短期大学部で切り分けた回答ができないため同一内容を記載しています。
出退勤のシステムは利用しておりません
小規模学校の為、質問される程の、データ化、システム化は行われていない。
回答内容は、グループウェアの回答に含まれています。
●●●大学短期大学は、●●●大学●●●キャンパスの敷地内にあり、施設
は大学とほぼ同じものを利用しています。回答は短大のみのものではなく、●●●大学●●●キャンパスのものと同様となります。

366

（つづき）
機関種別 分類
短大

私立

C

研究機関

私立
私立
私立
私立

C
C
C
B

高専
短大
短大
短大
私立
私立

A
A

国立

A

私立

D

公立

D

短大
短大
短大
短大
公立

C

私立
C
私立
C
私立
C
私立
C
私立
C
短大
研究機関
短大
短大
短大
私立
私立
私立
私立
高専
高専
私立
私立
私立

C
C
C
C

D
D
C

意見
●●●大学短期大学は、●●●大学●●●キャンパスの敷地内にあり、施設
は大学とほぼ同じものを利用しています。短大のみのものではなく、回答は●学務情報●●大学●●●キャンパスのものと同様となります。
2.2システム利用数 同時利用者（ピーク時）については、当初の回答欄に～１０
人事給与財務会計学務情報就職支援０という選択肢が有ったが、現時点では無くなっているので、～５００を選択しました。
IaaSやPaaSは民間では既にAmazon、Microsoft等で稼動しているところであり、実績もある。客観的かつ正確にアカデミッククラウドの優位性・必要性などを検証する事が必要ではないか。そして、下手をすると使いにくく、高コストになるのではないかという事が懸念される。よって、各機関に費用負担が生じるとなる
財務会計と、民間業者との競争も視野に入れる程の覚悟が必要ではないか。
最も好ましいのは、民間業者とタイアップし、個人情報や法的な問題により現在不足している部分（センターを国内に冗長配置するなど）を行ったものを提供して頂く事であると思料する。
学務情報就職支援
2.2同時利用者数(ピーク時)の箇所「～100」で回答する。
財務会計
2.2同時利用者数(ピーク時)の箇所「～100」で回答
人事給与2.2の同時利用者数(ピーク時)は「～100」で回答致します。
就職支援
可能な範囲での回答とさせていただいております。
高専のシステム管理、企画立案は高専機構本部が担っておりますので、本クラ人事給与ウド環境にっかる事業を高専本部にもご提供いただけますと幸いです
学務情報就職支援●●●大学・●●●大学短期大学部を合わせた数となっております。
人事給与財務会計●●●大学・●●●大学短期大学部を合わせた数となっております。
大学/中高等法人全体で共有しているシステムでもあり短大独自の情報ではな
人事給与財務会計学務情報
いものが含まれます。
就職支援
就職支援システムは、外部システムを利用しているため、確認できません。
出退勤
諮問2-2以降は不明
学外に個人情報を保管することの是非については非常に慎重な意見が多いところですが、アカデミッククラウド環境ということであれば理解も得られやすく、学内でのサーバー管理や更新の手間も減りますのでシステム内容について期待
人事給与財務会計学務情報をしております。しかし、外部業者がサーバーメンテナンスをリモートで対応する場面が多々あるのですが、そういった場合の接続先管理などが気になるところです。
本学は株式会社立の大学院大学（株式会社の一部）ですので、人事給与及び財務システムは株式会社のシステムを利用しております。詳細については回答
人事給与財務会計出退勤を控えさせていただきます。
本学は●●●県の一機関であり、人事給与システム・財務会計システムは●学務情報●●県のシステムを基本的に使用している。
就職支援
就職支援システムは大学と短大で共用。
財務会計
財務会計システムは大学と短大で共用。
出退勤
出退勤システムは大学と短大で共用。
人事給与
人事給与システムは大学と短大で共用。
●●●県の出先機関なので、人事給与システム、財務会計システムについて
学務情報
は、県のシステムとなっている。
人事給与財務会計学務情報就職支援出退勤Saasについても積極的に増やす方針はない
就職支援
就職支援システムは大学と短大で共用。
財務会計
財務会計システムは大学と短大で共用。
出退勤
出退勤システムは大学と短大で共用。
人事給与
人事給与システムは大学と短大で共用。
本学では事務システムはございません。
出退勤●●●統合事務センターのみで運用しています。
学務情報
学務情報システムは大学と短大で共用。
同一敷地内で先に設立された●●●大学と共通事務・システム運用を行ってお出退勤りますので申し添えます。
就職支援
当部署では回答できない項目が多い調査依頼である。
就職支援
当部署では回答できない項目が多い調査依頼である。
出退勤
一部の設問につき回答が困難なため回答しておりません。
財務会計
一部の設問につき回答が困難なため回答しておりません。
学務情報
一部の設問につき回答が困難なため回答しておりません。
出退勤
当機関は該当しません。
就職支援
当機関には該当しません。
就職支援
業者に委託しているため、詳細は不明
出退勤
当機関は該当しません。
人事給与財務会計出退勤
システム専門担当者をおいていないので、詳細が不明なところがあります。
業務システム種別

367

コンテンツサービス分野、ICT サービス分野、経営分野、事務支援分野における主な
商用サービス一覧
1. コンテンツ分野で利用している主な商用サービス (サービス/商品名
LIMEDIO

リコー

E-Cats Library

日本コンピュータシステム

iLiswave-J

富士通株式会社

情報館

ブレインテック

NALIS

NTT データ九州

2. ICT 分野で利用している主な商用サービス
Google app グーグル
Active mail トランスウエア
サイボウズシリーズ サイボウズ
デスクネッツ ネオジャパン
Deep mail ディープソフト
Office 365 日本マイクロソフト

3. 経営分野で利用している主な商用サービス
DB-Spiral
CampusPlan

SRA 東北システムディ

サイボウズシリーズ サイボウズ
GAKUEN日本システム技術

SharePoint

日本マイクロソフト

4. 事務支援分野で利用している主な商用サービス
GAKUEN日本システム技術

CampusPlan

システムディ

Campusmate-J

富士通

U-PDS

サイエンティア

NC くんシリーズ

ニッセイコム368

提供会社)

４）教育支援分野（当該部署，部局等）
４−１）機関向け
非常によく使われている（目安: 8割以上の科目）

よく使われている（目安: ６割以上，８割未満の科目）

ある程度使われている（目安: 4割以上，6割未満の科目）

あまり使われていない（目安: 2割以上，４割未満の科目）

ほとんど使われていない（目安: 2割未満の科目）

分からない

授業資料の提供（n=55）

27.3%

課題レポートの提出・採点・返却（n=56） 5.4%
メール等による教員・学生間のやりとり（n=55）

21.8%

19.6%

9.1%

テスト（n=56） 1.8% 8.9%
3.6%
ディスカッション（n=56） 1.8%

26.8%

7.3%

25.5%

ビデオ教材の提供（n=56） 1.8% 1.8%
0.0%
SCORM 教材等のオンライン教材（n=56）0.0% 8.9% 5.4%
3.6% 5.5%
ソーシャルネットワーキング機能（n=55）0.0%
0.0%
9.3%
Wiki（n=54） 0.0%
0.0%3.7%

1.8% 14.5%

8.9%
7.3%

16.1%
19.6%
8.9%

21.8%

21.4%

19.6%

19.6%

19.6%

16.4%

17.9%

12.7%

34.5%

30.4%

21.4%

37.5%

19.6%

46.4%

21.4%

60.7%

25.0%

43.6%

47.3%

46.3%

40.7%

図： CMS/LMS が有する機能の利用状況（国立）

非常によく使われている（目安: 8割以上の科目）

よく使われている（目安: ６割以上，８割未満の科目）

ある程度使われている（目安: 4割以上，6割未満の科目）

あまり使われていない（目安: 2割以上，４割未満の科目）

ほとんど使われていない（目安: 2割未満の科目）

分からない

授業資料の提供（n=132）

20.5%

15.9%

課題レポートの提出・採点・返却（n=131）

8.4%

20.6%

メール等による教員・学生間のやりとり（n=128）

10.2%

17.2%

28.0%
22.1%
19.5%

12.1%
17.6%

7.8%

テスト（n=133）

15.9%

7.6%

24.4%
28.1%

7.5% 8.3%
22.6%
21.8%
3.8%
12.8%
22.6%
42.9%
5.3%
ビデオ教材の提供（n=131） 2.3% 1.5%
16.8%
58.0%
2.3%
SCORM 教材等のオンライン教材（n=129） 1.6% 4.7% 10.9%
56.6%
2.3% 7.0%
ソーシャルネットワーキング機能（n=128）0.8%
60.9%
0.8%
Wiki（n=130） 0.8% 3.8%
63.8%
0.8% 2.3%

6.9%
17.2%

32.3%

7.5%

ディスカッション（n=133） 3.0%

図： CMS/LMS が有する機能の利用状況（私立）

369

15.0%
16.0%
24.0%
28.1%
28.5%

非常によく使われている（目安: 8割以上の科目）

よく使われている（目安: ６割以上，８割未満の科目）

ある程度使われている（目安: 4割以上，6割未満の科目）

あまり使われていない（目安: 2割以上，４割未満の科目）

ほとんど使われていない（目安: 2割未満の科目）

分からない

授業資料の提供（n=12）
課題レポートの提出・採点・返却（n=12）

33.3%
8.3%

メール等による教員・学生間のやりとり（n=12）
テスト（n=12）

8.3%

16.7%

8.3%

0.0%

41.7%

16.7%

ディスカッション（n=12）

25.0%

16.7%
16.7%
16.7%

8.3%

16.7%

25.0%

25.0%

25.0%

16.7%

25.0%

8.3%
8.3%
ビデオ教材の提供（n=12） 8.3% 0.0%
8.3%
0.0%
0.0%
SCORM 教材等のオンライン教材（n=12）0.0%
0.0%
25.0%
ソーシャルネットワーキング機能（n=12）0.0%
0.0%
8.3%
Wiki（n=12） 0.0%
0.0%
16.7%

8.3%

0.0% 16.7%

0.0% 16.7%

0.0%

25.0%

25.0%

16.7%

33.3%

50.0%

25.0%

66.7%

33.3%

8.3%

41.7%

25.0%

25.0%

50.0%

図： CMS/LMS が有する機能の利用状況（公立）

非常によく使われている（目安: 8割以上の科目）

よく使われている（目安: ６割以上，８割未満の科目）

ある程度使われている（目安: 4割以上，6割未満の科目）

あまり使われていない（目安: 2割以上，４割未満の科目）

ほとんど使われていない（目安: 2割未満の科目）

分からない

授業資料の提供（n=20）
課題レポートの提出・採点・返却（n=20） 5.0%
メール等による教員・学生間のやりとり（n=19） 5.3%

25.0%

15.0%

40.0%

20.0%
15.8%

45.0%
10.5%

テスト（n=20）0.0%
5.0%
20.0%
0.0%
ディスカッション（n=20）0.0%
5.0% 10.0%
5.0%
ビデオ教材の提供（n=20）0.0%0.0% 5.0%
0.0%
0.0%
SCORM 教材等のオンライン教材（n=20）0.0%
0.0%
5.0% 5.0%
ソーシャルネットワーキング機能（n=20） 5.0%
0.0%
5.0%
Wiki（n=20） 0.0%
0.0% 10.0%

10.5%

10.0% 5.0%5.0%
0.0%

31.6%

20.0%

20.0%

10.0%
26.3%

45.0%
55.0%

10.0%
30.0%

80.0%
80.0%

20.0%
70.0%

60.0%

図： CMS/LMS が有する機能の利用状況（高専）

370

10.0%

15.0%
25.0%

非常によく使われている（目安: 8割以上の科目）

よく使われている（目安: ６割以上，８割未満の科目）

ある程度使われている（目安: 4割以上，6割未満の科目）

あまり使われていない（目安: 2割以上，４割未満の科目）

ほとんど使われていない（目安: 2割未満の科目）

分からない

授業資料の提供（n=25）

16.0%

課題レポートの提出・採点・返却（n=24）

8.3%

メール等による教員・学生間のやりとり（n=24）

24.0%

28.0%

20.8%

16.7%

16.7%
16.7%

テスト（n=24）

8.3%
16.7%
4.3%
ディスカッション（n=23）0.0%
17.4%
4.0%
ビデオ教材の提供（n=25）0.0%0.0%
24.0%
0.0%
0.0%
SCORM 教材等のオンライン教材（n=25）0.0%
16.0%
0.0%4.2%
ソーシャルネットワーキング機能（n=24）0.0%
4.2%
Wiki（n=24） 4.2% 4.2%
0.0% 0.0%

4.0%

20.8%
20.8%

16.0%
20.8%

12.5%

12.5%

33.3%

26.1%

12.0%
12.5%

25.0%

8.3%

16.7%

12.5%

30.4%

21.7%

52.0%

20.0%

52.0%

32.0%

66.7%

25.0%

66.7%

25.0%

図： CMS/LMS が有する機能の利用状況（短大）利用対象総科目の8割以上

利用対象総科目の6割以上，8割未満

利用対象総科目の4割以上，6割未満

利用対象総科目の2割以上，4割未満

利用対象総科目の2割未満分からない

科目情報（全体，n=238）

42.4%

科目情報（国立，n=55）

40.0%

科目情報（私立，n=127）

48.0%

科目情報（公立，n=11）

36.4%
0.0%
0.0%
5.3%

科目情報（高専，n=19）

15.8%

科目情報（短大，n=26）

42.3%

履修情報（全体，n=237）

40.9%

履修情報（国立，n=55）

履修情報（公立，n=10）
履修情報（高専，n=19）

47.2%
0.0%
0.0%

20.0%
0.0%
10.5% 0.0% 0.0%

履修情報（短大，n=26）

シラバス情報（全体，
シラバス情報（国立，n=54）
シラバス情報（私立，シラバス情報（公立，n=10）
シラバス情報（高専，n=18）
シラバス情報（短大，n=26）

30.7%

2.5%
2.5%
2.4%
0.8%3.6%
1.6%

27.6%

31.6%
19.2%

19.8%

29.1%

18.9%

40.0%

20.0%
36.8%
23.1%

7.7%

44.1%

24.6%

44.4%

25.9%

41.4%

24.2%
40.0%
27.8%

53.8%

図: CMS/LMS の教務システムとの連携状況

371

23.1%

21.8%

3.8% 7.7% 3.8%

0.4% 0.8%
1.7%
27.8%
0.0%1.9% 0.0%
0.8%
32.0%
0.8% 0.8%
0.0%
0.0%
20.0%
40.0%
0.0%
11.1% 0.0% 11.1%
0.0%
50.0%
0.0%
26.9%
0.0%
3.8%

20.5%
27.3%

52.6%

28.4%

18.2%

40.0%

20.0%

53.8%

21.4%

36.4%

33.3%

0.0%0.8%
0.0%

34.5%

履修情報（私立，n=127）

0.8%
2.1% 2.5%
1.8%
1.8%
1.8%
1.6% 1.6%
0.8%
0.0% 0.0%
36.4%
0.0%
47.4%
0.0%
7.7%
7.7%

15.4%

利用対象総科目の8割以上

利用対象総科目の6割以上，8割未満

利用対象総科目の4割以上，6割未満

利用対象総科目の2割以上，4割未満

利用対象総科目の2割未満分からない

科目情報（全体，n=115）

36.5%

科目情報（国立，n=26）

30.8%

科目情報（私立，n=63）

36.5%

科目情報（公立，n=6）
科目情報（高専，n=5）

50.0%
0.0%
0.0% 0.0%

20.0%

科目情報（短大，n=15）

履修情報（全体，n=111）
履修情報（国立，n=26）
履修情報（私立，n=62）
履修情報（公立，n=5）
履修情報（高専，n=4）

46.7%

0.9%
0.9% 2.7%
0.0%
3.8%
30.8%
3.2%
40.3%
0.0%
0.0%
0.0%
20.0%
0.0% 0.0%
0.0%
25.0%
0.0% 0.0%
36.9%

履修情報（短大，n=14）

シラバス情報（全体，
シラバス情報（国立，n=26）
シラバス情報（私立，n=62）
シラバス情報（公立，n=6）
シラバス情報（高専，n=4）
シラバス情報（短大，n=15）

3.5%
0.9% 1.7%
31.3%
0.0%
3.8%
30.8%
0.0%
1.6%
0.0%
34.9%
4.8%
0.0%
0.0% 16.7%
0.0%
40.0%
6.7%
6.7%
0.0%

22.2%
33.3%
40.0%
20.0%

20.0%

35.1%

23.4%

30.8%
0.0%

34.6%
35.5%

21.0%

60.0%

0.0%
7.1%

42.9%

26.1%
34.6%

20.0%
25.0%

50.0%
7.1%

0.0%2.7%
46.0%
0.9%
11.5% 0.0% 0.0%
46.2%
0.0%
3.2%
24.2%
0.0% 0.0%
43.5%
0.0%
0.0%
16.7%
50.0%
0.0%
25.0%
0.0% 0.0%
50.0%
6.7%
13.3% 0.0%
53.3%
6.7%

28.6%

14.3%

19.5%

31.0%
42.3%
29.0%
33.3%
25.0%
20.0%

図: e ポートフォリオシステムの教務システムとの連携状況

CMS/LMS や e ポートフォリオシステムを ASP 型で利用する場合のメリット（その他）（抜粋） ASP 型での利用は想定していない
 サーバセキュリティの維持が期待できる。
 サーバのメンテナンスが不要 サーバのメンテナンスが不要 サーバ管理が不要
 サーバ等のハードウェアの管理が必要なくなる システムを利用していないので回答できない
 セキュリティ、管理コスト
 セキュリティ対策が施される、障害対策が施される
 ハード保守満了に伴う機器更新やそれに伴うデータ移行等の考慮が不要になる
 可能性の向上（学内停電等の際も継続して利用できる）
 可用性などの向上に係るコストの削減
372

 機器の故障の心配をしなくてもよい 巨額な初期投資を必要としない。段階導入が可能。
 計算機やソフトウェアのメンテナンスが不要になる 哲学系のみの研究科であるためメリットがわからない
 本学では、ハードウェア等を外部に出すことを検討しており、システム（ソフトウェア）
は同じものを使用する。
 本学では本設問の利用形態を現在のところ検討していないため，上記選択肢からの回答
はできない 夜間休日の対応が可能。設備の維持管理監視が不要
CMS/LMS や e ポートフォリオシステムを ASP 型で利用するデメリット（その他）（抜粋） 障害に対する耐性と障害復旧の迅速さ
 コスト
 コストが高い システムに想定外の問題が生じたとき解決不能なかたちで継続的利用が絶たれる点 システムを利用していないので回答できない
 トータルコストが高い ネットワーク帯域を集中的に使用する可能性がある 学外にサーバを置いた際の通信コスト
 技術者がいなくなる・ネットワーク回線の問題
 教務システム（成績）との連携が難しい
 現状ではオンプレミスより高価
 上記の通りであるためデメリットがわからない
 数年後、新しいシステムがある他社に乗り換えがしにくいデータ移行等
 導入費用が高価
 本学では、ハードウェア等を外部に出すことを検討しており、システム（ソフトウェア）
は同じものを使用する
 本学では本設問の利用形態を現在のところ検討していないため，上記選択肢からの回答
はできない

CMS/LMS や e ポートフォリオシステムの ASP 型での利用を促進する要因（その他）（抜粋） 障害に対する耐性と障害復旧の迅速さ
 ASP 型での利用に対する教員の理解
 ASP 型での利用は想定していない
 コンテンツで使用するの著作物への対応
 コンテンツの充実
373

 サーバの保守が不要 サービスの普遍性・安定性の証明、大学での導入実績の増加
 ネットワークの切りわけ 安全性に関して、上層部が納得できる平易な説明資料
 学生の利便性向上
 学内検討機関の整備（委員会等）
 管理者の負担軽減
 教員・学生に対する利用支援 教員の意識改革
 業社モラル 障害や問題が発生したときの具体的な対処法の合理性と明確化、および責任・弁済・保障関係の明確化 著作権法関連の柔軟な運用（または法改正）
 補助金
 補助金の整備、教育コンテンツに関する著作権 本学では促進していない
 本学では本設問の利用形態を現在のところ検討していないため，上記選択肢からの回答はできない 利用サポートの充実 利用する民間企業等がすでに設備を整えているので、導入期間が短くて済む。

CMS/LMS や e ポートフォリオシステムの ASP 化を促進するセキュリティやプライバシを強化する技術整備（抜粋） 2 段階認証
 ASP 型であっても、信頼できる業者と適切な契約ができれば、相手先企業に対するセキ
ュリティ上の懸念は小さいと考えられるが、システムのアクセス方法や途中の通信回線に関するセキュリティ上の懸念が残るため、十分な通信速度を維持しつつ、セキュ
アなアクセス方法が確立されることが必要と考えられる。
 ＩＤ、パスワード漏洩による不正アクセスが発生した場合にでも、個人情報漏洩が発生しない仕組み SSL
 システムに蓄積された情報が外部に漏洩しないようにするための仕組み ソーシャルハッキング
 データの暗号化など
 データベース自体が暗号化されていて利用する大学毎に解読キーが異なる ベンダー側で最新技術の管理・設定をおこなってくれる374

 ユーザ認証
 暗号化技術の利用の推進 確実な情報漏洩対策
 学習履歴や個人情報の漏洩対策がされているか
 学内からの情報漏えいを防げる
 危機管理体制とシステムの整備強化
 個人情報や評価情報が漏洩するリスクを 0 にする 個人情報をクラウド上に置かなくても良いようにするなど
 授業に関する個人情報の保護
 成績情報の管理
 専門家によるセキュリティ保障
 蓄積データそのものを暗号化して保存する
 通信の暗号化、不正アクセス防止、アクセスログ管理、ファイアウォールハードウェア
機器・OS・アプリケーションにおける脆弱性への対策
 認証、VPN 等 認証システム 本人認証・なりすましの防止・外部からの侵入対策
 本人認証の強化等
CMS/LMS や e ポートフォリオシステムの ASP 化を促進するセキュリティやプライバシを強化する法整備（抜粋） IT-BCP セキュリティポリシー策定
 セキュリティポリシーが未整備 暗号化保存や侵入監視の義務付けなど
 業者は蓄積したデータを一切利用してはいけない 現行の個人情報保護法では曖昧 情報セキュリティの整備が必要
 著作権や個人情報保護に関する法整備
 著作権保護法の学術利用における整備 著作権保護法の学術利用における整備 特に不正ログインへの対応
 米国 FERP A のような法律の整備
CMS/LMS や e ポートフォリオシステムの ASP 化を促進する災害対策を強化する技術・運用
（抜粋）

375

 2 重化やバックアップ
 IT-BCP
 サービス提供先までのネットワーク経路の確保
 データセンターの分散
 データのバックアップ
 データ保全のため
 ノンストップサービス ハードウェア不良時の即時対応等
 バックアップ技術等
 バックアップ体制
 バックアップ体制の強化等
 ベンダー側で最新技術の管理・設定をおこなってくれる 遠隔の複数サイトへのサーバ分散・冗長化などいわゆるクラウド的な運用
 遠隔地でのバックアップ
 外部にデータを蓄積することにより、有事の際のバックアップを果たす目的もある。
 学外でシステムを共有することで災害時、復旧を容易にする
 学外にサーバを設置する事により、災害発生時における障害の規模を最小限に抑えられる。
 学内障害時にも利用できる
 簡単にＢＣＰ対策を強化できることが経営サイドからも理解を得られやすい 広域大規模災害時は通学が困難な場合が多いため,災害時でも利用可能になる手立てはできるだけ行いたい 災害時でもノンストップ運用
 災害時にもノンストップ運用
 災害時等学内システムが利用できない場合でもサービスを利用できる。
 災害発生時に学外からでも講義を受講することができる技術
 事業継続ができる。
 事業所の拠点と離れ他場所に設置できる
 対外接続安定して使用できる筈 大規模災害時にデータ喪失を防ぐための広域冗長化ストレージ 津波
 停電時の対応
 停電時等においても支障なく運用できること
 複数拠点で相互バックアップ等の BCP 対策
 複数個所で運用している場合、１箇所が災害等でダウンしても他方で運用できる。
 分散化
376

ASP 型で学生メールシステムを提供する場合，次のうちでメリットになると思うもの（その他，抜粋） 365 日 24 時間の運用が可
 ASP 型での利用は想定していない
 BCP に有効
 BCP 対策
 インターネット上でメールが利用できる
 システムのバックアップが不要になる。
 セキュリティ、プライバシーの強化
 セキュリティ対策が施される、障害対策が施される
 ハードウェアの管理・維持をしなくともよい メールサービス停止の時間を低減できる
 維持管理コストが低減できる
 稼働率
 外部からの利用をしやすい。ストレージ容量を気にしなくて済む。卒業後、学内でアカ
ウントを残さずとも利用できる。
 学内の都合に左右されず利用できる
 学内メンテナンス時でもサービスを停止することなく、学外からでも利用できる。
 管理運用・技術者の業務が軽減する
 計算機やソフトウェアのメンテナンスが不要になる
 検討していない
 災害時のＢＣＰ／ＤＲに対応するため
 災害時の緊急連絡が可能となる
 災害時の連絡網として使える。
 災害対策及び TCO の削減
 信頼性の向上 卒業後もメールアカウントを使い続けられ、その設備を維持しなくても良いこと 大学を卒業しても使用し続けられる可能性がある
 特に夜間など、障害復旧時間が短い 保守・管理の手間が削減できる
 無停止でサービスを提供可能
ASP 型で学生メールシステムを提供するデメリット（その他，抜粋）

 GoogleApps を使用している。ポリシーなどが頻繁に変更されたり、質問など問合せしにくいなどの問題がある。
377

 オンプレミス型のような管理運用ができない こちらの要望とは関係なくシステムや UI のアップデートが行われる
 システム上の障害が発生した場合、システム面の原因切り分けが十分に出来ない恐れがある。また、サービス提供元の障害の場合、障害復旧に要する時間の目途がつかめず、障害原因や復旧時間等をユーザに告知できない
 データの流用、漏えいが頻繁に行われており重要システムには使用できない バージョンアップに半強制的に追随する必要がある
 ブラウザのバージョンが合わない場合に利用できない。
 メールの送受信履歴が残らない。システムダウンや不具合が多い。
 メール不達・未達に対する原因分析が行い難く、大学として責任を持った状況報告をユーザに行えない心配がある
 ログが残らず不調時の原因究明がしにくい ログの追跡が出来ない/手間がかかる 一度 ASP に移行してしまうと二度と大学での運営に戻れない。メールシステム運用のノ
ウハウが大学から失われる。
 学生の利用統計が取得できない(YahooAD)
 学内の理解が十分に得にくい
 管理コストの増加
 業社モラル 検討していない
 検討していないため回答できません 誤用によるデータ消失の危険性がある
 仕様変更が激しく対応が追いつかないことがある
 仕様変更の内容、タイミングが制御できない。
 障害時の対応がとりにくい
 条件が業者主導になる。
 設備の維持管理監視が不要
 相手の都合で仕様が変更されてしまう
 送受信ログの確認が困難
 卒業後も利用できるとよい。データ領域がある程度大きくレポート提出にも利用できるとよい。
 他システムとのユーザ認証の連携
 大学として技術を蓄積できなくなる
 評価できない 予期せず仕様変更が発生する。

378

学生メールシステムの ASP 型での提供を促進する要因（その他）（抜粋） OS のアップデート等管理作業軽減
 サーバの保守が不要 サービスの普遍性・安定性の証明、大学での導入実績の増加
 システムダウンやメール喪失が起こらないこと。
 システム運用に大学側が責任を負わない スパム対策 スマートフォンで直接受信できる スマートフォンの普及によるネットワークの拡散 スマートフォン対応
 メール保存領域の大きさ
 モラルの向上
 ユーザのニーズにあったカスタマイズが可能なこと
 運用管理インターフェイスの充実
 学外からのアクセス
 学内認証基盤との連携
 技術者育成の手間
 教職員、学生は共通のメールシステムを使用している。セカンドメールシステムはフリーメールを活用開始予定
 検討していない 現状促進する要因はない。
 個人情報の取扱い
 高専学生にメールアドレスを配布することの必要性の検討
 最新のＵＩベースのシステムによる学生への利便性と価値提供
 事件・事故対応のためのメールログ保存
 守秘義務条項を特記した契約が締結できるか。
 新しい機能の追加や新しい技術導入が迅速に行われれば
 生涯メールなど増え続けるユーザ数
 卒業後もアドレス変更無く利用できる生涯メールアドレスサービス
 卒業生とのつながりを重視する大学の方針
 大学のニーズに応じたカスタマイズの容易さ
 当機関は、本アンケートの設問に該当しませんので、回答を控えます。
 当機関は、本アンケートの設問に該当しませんので、回答を控えます。
 本学では促進していない 利用サポートの充実 利用できるメールボックスの容量がオンプレミス型に比べ顕著に大きい。機器障害やメ379

ンテナンス等による年間のサービス停止時間がオンプレミス型に比べ短い

学生メールシステムの ASP 化を促進するセキュリティやプライバシを強化する技術整備（抜粋）

 2 段階認証
 ＩＤ、パスワード漏洩による不正アクセスが発生した場合にでも、個人情報漏洩が発生しない仕組み SSL
 SSL 通信及びメールボックスの暗号化 メールの暗号化等
 暗号化・情報の取扱 危機管理体制とシステムの整備強化
 拠点を国内に限ること 等 個人情報保護
 個人認証、暗号化
 脆弱性対応
 蓄積データそのものを暗号化して保存する
 蓄積メールデータの暗号化
 通信の暗号化
 通信の暗号化、セキュリティソフト、ファイアウォールハードウェア機器の脆弱性への対策
 電子メールは、歴史的経緯により、全くセキュアではない通信手段がそのまま利用され続けている部分があり、本質的な解決が求められる。
 認証システム
学生メールシステムの ASP 化を促進するセキュリティやプライバシを強化する法整備（抜粋） BCP 対策 セキュリティ実施書の対応改訂
 セキュリティポリシーが未整備 セキュリティポリシーが未整備 セキュリティポリシー策定
 業者は蓄積したデータを一切利用してはいけない 個人情報の取扱い（特に海外にサーバを置く場合）
 国内法での対応、守秘義務上の取扱い
 国内法準拠
 国内法準拠 情報漏えい等の情報セキュリティリスクがオンプレミス型に比べ、少ないと判断できる
380

法整備がある 特に海外サーバ利用の場合
 日本の法律が適用される
 日本国内の法律で扱える
 両者とも具体的なことは書きにくいですが、ASP の業者が示す利用規約が完全に大学等で受け入れられるものではない気がします。精査していないのでどの点が、というのは具体的に指摘できません。ある業者の場合は、中身を触る可能性を示唆しているみたいですし。

学生メールシステムの ASP 化を促進する災害対策を強化する技術・運用（抜粋） BCP 対策 BCP 対策が不要
 IT-BCP
 サーバが遠隔地にある サービス停止の回避 データのバックアップ
 データの冗長化・設備の堅牢性
 ノンストップサービス
 安否確認機能の実装
 学外にメールデータを置くことで災害時の復旧を容易にする 学内サーバの停止による連絡ルート喪失回避
 学内のサーバがダウンしても使用可能
 学内の基盤システムに障害が発生してもインターネット上で使用できる
 学内障害時にも利用できる
 簡単にＢＣＰ対策を強化できること
 緊急時の情報提供
 学外にサーバを設置する事により、災害発生時における障害の規模を最小限に抑えられる。
 高い可用性を有する技術・運用
 災害時でもノンストップ運用
 災害発生時にサービスが継続できる
 守秘義務契約の締結が可能であること、日本の国内法に準じて問題の解決にあたれること。
 対外接続安定して使用できる筈 大規模災害が発生した際にもデータ等が失われることなく、継続的にサービスを提供可能な環境とできれば、その利用価値は高いと予想される。
381

 大規模災害時でも維持できる
 大規模災害時にデータ喪失を防ぐための広域冗長化ストレージ 停電時の対応
 停電時外部からﾒｰﾙ送受信可能 停電時等においても支障なく運用できること
 複数拠点でのバックアップ体制 等
 複数拠点での相互バックアップ等の BCP 対策
 連絡手段の確保
クラウド型で学生端末システムを提供するメリット（その他）（抜粋） OS のアップデート等管理作業軽減 あまりメリットはない イメージの管理が容易
 システムの集中管理、端末のコストダウン、BYOD への対応
 セキュリティの向上、管理コストの低減
 セキュリティ対策
 データストレージ どこからでも、どの PC からでも同じ環境で学習できる どこにいても同じ環境が利用できる
 ない メリットがわからない メリットを感じない メンテナンスの軽減 一定年度毎のＨＷ更改費用が不要または削減される
 運用・管理コストの低減、環境の標準化
 運用・管理の作業軽減
 運用コストの低減
 運用管理が楽になる 学外からも共通に利用可能となるのであれば、メリットになり得る
 学習機会の拡大
 学生に対してのサービス
 管理・メンテナンスが容易になる
 管理・設定・更新等が容易
 管理のしやすさ
 管理運用・技術者の業務が軽減する
 管理運用コストが安い382

 現時点ではメリットを感じない
 故障時の復旧コストが低い
 更新反映が楽 高額なソフトウェアの有効利用 在宅(教室外)学習が可能になる
 自宅から特殊なソフトウェアが利用できる（CAD，DTM など）
 質問の意味がよくわからない。
 授業で使用する教室の割り当てが柔軟になる 集中管理ができる
 集中管理による管理負荷の軽減
 省電力、省スペース
 脆弱性対応、ソフトの更新が容易
 端末のデスクトップ環境を一元管理できる
 端末のメンテナンス業務の負担軽減
 端末の管理負担軽減
 端末の更新頻度の減少
 端末の種類や利用場所によらない利用が可能 端末メンテナンスがしやすい。クライアントの H/W 障害発生率を下げられる。
 端末室を別途設ける必要がなくなる
 端末設定を統一できる 特定のメリットを期待しているわけではなく、実現方式の一つとして検討している。
 複数のシステムを用意できる
 保守管理コストの低減 保守作業が容易
 様々な稼動イメージを用意することで、利用環境の多様化が図れる
 利便性が向上するだろうが、特にメリットは感じていない 利用状況に応じたテンプレートで起動できる。
クラウド型で学生端末システムを提供するデメリット（その他）（抜粋） BYOD を主としており、大学が負担するものではない。
 アプリケーションの稼働保障が無いものがあり採用しにくい
 イニシャルコストが高く、費用対効果が見込めない
 クラウドが故障すると全て使用できないリスク
 クラウド型での学生端末提供は、大学での授業対応に技術的に未熟な面があり、保守管理の面で問題が多い。
 クラウド上では利用できないソフトウェアや周辺機器がある
383

 コスト コストがかさむ コストが高い
 コスト増の懸念
 サーバ側で障害が起きると影響が大きい サービス側が利用不能な場合に影響範囲が大きい システム上の障害が発生した場合、原因箇所の切り分けが十分に出来ず、サービス復旧が遅れる恐れがある ソフトウェアのコストが高い ネットワークがボトルネックになる。
 ネットワークトラブル時のシステム停止が大規模
 ネットワークへの依存度が大きくなりすぎる点
 ネットワーク回線に依存、回線トラブル、スピードによる影響が懸念される
 ハードウェア依存のアプリケーションや動画系アプリケーションを利用した授業ができない。
 ハイコスト パフォーマンス。FAT 型に比べて性能がでるかどうか。
 パフォーマンスおよびコストに関する懸念がある
 パフォーマンスが悪い。不安定。
 パフォーマンスに関する懸念 パフォーマンスに不安がある パブリッククラウドの場合、障害発生時の対応が不明
 ピーク時の接続トラブルが懸念される。
 モラル
 レスポンスが悪くなる
 安定運用に問題
 運営管理技術的スキルが必要となる
 回線の能力増強が必要。
 回線速度で利用が制限される
 学外との通信回線に依存するシステムになる
 学外にサーバを置いた際の通信コスト
 学内、学外のＮＷの整備が必要
 学内停電時・ネットワーク障害時に操作が一切できなくなる 機能面での制約が大きい
 規模の小さな場合はコスト高になる 教育・研究で使われるアプリケーションの仮想環境での動作確認が大変である
384

 経費
 軽快に動作するかどうかが不安。正常に動作しないアプリケーションがある可能性がある。
 検討していないため回答できません 現時点ではコストが高い 現状ではクラウド自体が成熟していない
 現状のクライアント数ではコストが高い 高コスト 高価 高価な割に性能が低い
 質問の意味がよくわからない。
 処理速度 小規模な大学では高コストとなる
 障害対応の難しさ
 新しい技術のため、運用のノウハウが蓄積されていない
 端末のプロセッサパワーを要求するので適用しづらい。医療系大学間評価実施機構が実施する教養試験 CBT の要求環境に合わない。
 通信回線の負荷が大きい 通信断によるすべて停止状態
 当機関は、本アンケートの設問に該当しませんので、回答を控えます。
 動作の安定 導入コストが高い 導入のための初期費用、利用時のネットワークトラフィックの増大
 特にデメリットはない 特定のアプリケーションが動作しない場合がある
 費用
 必要なハードウェアやライセンス等コストが高い 不具合が全員に影響すること 利用可能アプリケーションの多様化に対応できない
 利用可能なアプリケーションに制約が生じる
学生端末システムのクラウド型での提供を促進する要因（その他）（抜粋） BYOD を主としており、大学が負担するものではない。
 S/W ライセンス等の構築環境整備
 サーバと端末間の応答速度
 サービスの普遍性・安定性の証明、大学での導入実績の増加
385

 システム管理者の負担軽減。学生の自宅の PC 等、学外の PC でも大学が提供している環境が利用できる スマートフォンなどのデバイスの普及によるネットワークの拡散 ソフトウェアのコストの削減
 パフォーマンス。FAT 型に比べて性能がでるかどうか。
 パフォーマンスに関する情報がもっと必要 メンテナンスの効率化 ユビキタスコンピューティングの実現
 医・薬学関係の CBT での制約の排除
 一元管理、ハードトラブルの減少
 運用計画
 演習室確保なしに ICT を授業活用できる 学生の利便性向上
 学内検討機関の整備（委員会等）
 管理者の手間の軽減
 機能面での制約が減る
 検討していないため回答できません 質問の意味がよくわからない。
 授業で頻繁に利用するマルチメディア資料及び各種マルチプラットホームへの対応が必要。
 初期設定値の維持
 新技術への挑戦
 促進しない 促進する要因がない
 促進はしていない
 端末の一括管理および運用
 端末の故障対応が俊足に行われるか
 通信の秘匿性（暗号化） 通信回線の冗長化および高速化 動画等も円滑に再生できること
 特定のアプリケーションが複数のパソコン教室から利用できるため、受講者数に応じた教室配置・変更が容易になる
 必要なソフトウェアの動作保障
 保守作業が容易 本学では促進していない 利用サポートの充実
386

 利用可能アプリケーションの多様化 利用可能なアプリケーションの制約の削減
 利用可能なアプリケーションの制約の制限
学生端末システムのクラウド化を促進するセキュリティやプライバシを強化する技術整備（抜粋） ウイルスやハッカーに対するもの
 クライアント PC 本体に重要資料が残らない
 ソフトウェアライセンスの利用状況管理の厳格化
 なりすましの防止等
 バイオ認証
 暗号化
 暗号化・情報の取扱 危機管理体制とシステムの整備強化
 個人情報保護
 脆弱性対応
 通信の暗号化
 通信の暗号化、不正アクセス防止、アクセスログ管理、ファイアウォールハードウェア
機器・OS・アプリケーションにおける脆弱性への対策

学生端末システムのクラウド化を促進するセキュリティやプライバシを強化する法整備（抜粋） セキュリティポリシーが未整備 セキュリティポリシーが未整備 セキュリティポリシー策定
 業者は蓄積したデータを一切利用してはいけない 著作権法 米国 FERPA のような法律の整備
学生端末システムのクラウド化を促進する災害対策を強化する技術・運用（抜粋） IDC の活用
 IT-BCP
 システムネットワークの２重化
 データのバックアップ
 データの冗長化・設備の堅牢性
 データを一元管理しているサーバの可用性と信頼性
 教育環境の維持
387

 大規模広域災害時に本学学生が暫定的に利用できるデスクトップクラウドがあるとよい 大規模災害が発生した際にもデータ等が失われることなく、物理的にも任意の場所から利用可能な環境を継続的に提供可能とできれば、その利用価値は高いと予想される。
 大規模災害時にデータ喪失を防ぐための広域冗長化ストレージ
 端末システムをクラウドで利用することで災害時の復旧を容易にする 地震等の災害時
 地震等の自然災害によって大学の建物が損傷してもデータが保全される。
大学ポータルの機能（その他）（抜粋） ＩＣカードによる出欠席管理。
 クラウドテレビジョンの積極的運用
 全学で学生ポータル導入を検討している
 大学ポータルによる一元的なアクセス環境を提供している
 認証方法は端末認証を利用
教育学習支援サービスの現状や将来に関しての期待や要望事項（抜粋） BYOD に対するセキュリティや利用を展開し、考えていく必要がある
 BYOD を順次導入する環境を整える
 BYOD 推進のための動産保険に関してモデルを研究していただきたい e ポートフォリオシステムの利用が、セキュリティの都合で学内に限定しているのが現状であるが、学外利用（在宅時や卒業後の利用）が可能になると、学生側の利便性や蓄積する情報量・質の向上が期待できる
 ICT を活用した教育に費用が掛かりすぎる。
 iPad を利用した学習環境を構築中である
 LMS システム,ポートフォリオシステム等個別のシステムではなく,１つのシステムで実現可能なシステムを導入したい LMS や CMS は年々目覚ましく発展してきてはいるようであるが、オープンソースソフ
トウェアによるシステムも、また、プロプライエタリソフトウェアによるシステムも、単科大学から多様な学部から構成されるような総合大学までへの適用や、異なる大学同士の単位互換制度への対応、MOOCs や地域貢献等、現在の大学に求められている
通常の大学教育以外の教育プログラムへの適用等々で必要となるスケーラビリティ、
カスタマイザビリティ、相互接続性などにおいて満足ができるものがない。さらに、教務情報との連携まで含めると特定のベンダーに限定され、益々利便性に欠くこととなる。このため、当大学では、総合大学として多様な教育に適用できるよう、独自に設計した LMS を運用しているが、その場合、その継続的な維持、管理、発展が難しいという課題も抱えている。PaaS や SaaS 等のクラウド型の実装も重要であるかもし
388

れないが、それと同時に、多様な大学で柔軟かつ相互に利用可能なオープンなシステ
ム、ないしはその仕様を開発し、これをクラウド上で利用可能としていく必要があると考えられる。
 Moodle 開発支援機関があるとうれしい NII として、全学生（卒業後も含む）の e-mail アドレス発行及び、ある程度のデータ蓄積空間を提供して頂きたい。教員もレポートの受け取りができるようにして頂きたい。
その際に、メールタイトルやメールアドレス等から自動選別されることが望ましい。
また、このようなことを未来永劫提供する気がない場合には、その事を早く明言して欲しい（でないと期待してしまう）。
 すべてのことを加速度的に導入は非常に難しいので、徐々に使い慣れてもらいながら進んでいます。サービスによってあまりにも高機能すぎるところがありますが、だからといって簡単に利用できるものではないため、利用者の立場に立った開発などをしてもらえるとありがたいです。
 スマホ・タブレットの利活用向上
 ポートフォリオの導入を検討を行い学習のエビデンス管理をし目標値の達成など学習意
欲を向上させたい。
 ますますの高度活用が見込まれる
 メディア教材作成部署の設置、教室の準備
 もっと安定した環境を構築したい より高度化する必要はあるが，その進め方は慎重に行う必要があると考えている。
 安価で安全な ASP サービス
 一部には、BYOD が困難な学生もいるので、ある程度の台数を大学で確保するあるいは、貸与するなどのしくみを作り、不公平感を無くす術を講じたのち、全学的な対応を検討中。
 運用費の低コスト化
 学校間の連携
 学習支援の充実を図るため，教務システムに授業支援機能を導入した。平成２２年度導入後，平成２３年度に教員の利用状況を検証したところ，メール等の「連絡通知」以外は，ほとんど利用していなかった。平成２４年度に授業支援機能の改善と利用促進の方策を検討し，平成２５年度に教務システムのカスタマイズを行った。これにより，教員の利用が促進されることを期待する。
 学生と教員が双方向でやり取りできるシステム。学生の到達度や達成度を可視化できるシステム。
 学生の能動的な学習を促進するため、教育学習支援サービスを推し進めることは重要な課題である。そのための学内の環境整備が急がれる。携帯電話、スマートフォン、タ
ブレット等への対応も必要となる。
389

 学生数が少ないため有効であるとわかっていても導入費用などの面で利用しにくい面がある。
 学認などを通じて、他大学との相互連携ができていけばと思う。
 管理コストの低減を期待する
 関連部署との連携強化
 教育改善、経営改善に資する ICT 活用の拡大 教育学習支援サービスの現状は学内に閉じた形となっているが、将来的には部分的に学外への配信やＭＯＯＣへの参画なども含めた大学の教育学習支援の質向上および基盤強化を図ること
 教育学習支援サービスは今後必要になってくると思われるが、学生に必ず利用させる体制や仕組みが必要と思われる。
 学生に関する各種システムの統合が必須であると思われる。
 教員の情報スキルに差があるため、システムの導入時に要望が二極化してしまう（高機能 LMS と簡易 LMS）
。ユーザのレベルに応じて画面カスタマイズができるシステムがあるとよい。
 教員の利用意識の高まりと学生のリテラシー向上
 教科書と同じ手続きで電子教材を学生各自負担で購入できるようになるとよい 教職員の意識改革が必要 現在、学生の学修時間確保に向けて、クラウド型 LMS の導入を検討中である。
 現状に特に不満はありません。 SNS 的要素を加味した LMS に興味があります。
 現状は予算の確保は難しいところにあり、なるべく早く導入できるよう努めたい。
 限りないＩＴ投資が必要とされ、求められる今後に不安である。
 在学生が多いため、すべての学生に PC を携帯させ平等に WEB サービスを提供することは現状では難しい。
 財政的支援がないと導入は困難な状況です。
 時代のニーズに適応した ICT 教育環境を整えていきたい。
 授業のオンデマンド配信 小規模校であるため、設備投資において一人あたりの導入単価が嵩む
 小規模大学ではスケールメリットがないため、導入に関してはハードルが高い。補助金などの制度がないと導入はほとんど不可能である
 情報教育研究センターとして学生の学習環境は柔軟であるべきだと考えており、近い将来のクラウド化、ＢＹＯＤか、マルチデバイス化は避けて通れないものと考えている。
 大学ポータルの実現には、教育関連システムの運用・管理を一体的に議論し取り組む体
制と、資金面を含めた学内の強力なサポートが望まれる
 地理的要因で、専用回線費用が高額でインターネット回線の高速化が困難である。クラウド化推進には、インターネット回線の高速化が必須なので配慮を希望する。
390 著作権処理の体制整備やガイドラインが必要である。
 動画配信サーバと moodle を連携して e-Learning の充実を図る
 予算枠の安定化
その他、アカデミッククラウドに対する期待や要望（抜粋） 2011 年の私情協において「アカデミッククラウドは可能か」とプレゼンをした。高等教
育に利用できるクラウドを使った授業実践を行ったが、地方の体力もない高等教育機
関には国家予算でアカデミッククラウドを立ち上げて提供してほしい。
 5.3 SCORM 教材等のオンライン教材について、掲載された教材が該当するか不明である。
 5.6 ディスカッションについて、ログを取る方法が不明。
 5.7 メール等による教員・学生間のやりとりについて、科目単位で集計を取るすべがない。
 5.8 Wiki について、システム上機能がない。
 5.9 ブログやマイクロブログ等のソーシャルネットワーキング機能について、システム上機能がない。
 IaaS などにおいて、VM-Ware などの仮想環境の選択ができるとよい。
 ID・PW だけの連携ではまだセキュリティ的に十分とはいえない。証明書認証等、さらに１ランク高いセキュリティ対策が求められる。
 LMS や e-ポートフォリオシステムは大学毎に大きく要求が異なる為、カスタマイズが容易で安価なものが望ましいと考えます。
 OS やアプリケーションのパッチなど、セキュリティを向上させる仕組みが必要と考える
 ＶＰＮを利用した商用クラウドへの移行を進めています。経費負担が大きいことがネックになっています。大学でシェアできるクラウドを期待します。
 アベイラビリティが十分であること。個人の環境との同期が容易であること。データ転送等に支障がないこと。
（特にビデオ形式のコンテンツが多いため）遠隔会議等の他の活用方法との連携も視野に入れたい。
 インターフェイスの簡素化
 オンプレミスサーバよりもコストのメリットが無ければならない。またクラウドとの通信料が増えるので、通信回線の維持費を見直す必要がある。
 クラウドなので、容量やユーザなどは無制限というイメージでいます。また、どこからでもどんな端末からでも同じ様につながることが出来ればと思います。
 クラウド化できることとできないことを明確にし，人件費や回線経費等も含めたトータ
ルな検討を行って，導入を判断する必要がある。
 コストダウンと可用性 コストの削減が必須となります。
 サービスの継続性と学内事情に合ったシステムのカスタマイズの柔軟性391

 サービスの保証をしてほしい。
（何かの都合で、短期間で終了することのないようにしてほしい。
）
 システムの条件がどれほど必要なのか、内外での利用で負荷なく使用できるのかライセ
ンスの問題、個人利用の問題など。
 セキュアで低コストなアカデミッククラウドの更なる普及を望んでいる。
 セキュリティの強化
 ソフトウェア、ハードウェア、データベースのそれぞれについて、安全性や可用性に加え、用途に応じ柔軟な構成ができるようにするとともに、ぜひ多くの大学の参加を促し、スケールメリットを活かしたリーズナブルなシステムを提供してほしい マイクロソフト社の Office365 クラウドサービスをひとつの手本として研究していただ
きたい リソースの変更が Web で簡単に可能。サーバ無停止で出来ればなお良い。利用用途に対応してリソース、OS、アプリケーション等がパッケージ化されて提供される。細かく個々のリソースの調整も可能。
 安価でかつ安全なものであれば将来的に利用したい。
 一般向けのクラウドサービスのような ID 単位の課金制度だと、学生数分の費用がかさみ現実的ではない費用が発生してくる。アカデミッククラウドでは、サイトライセンスのような課金制度が必要だと思われる。
 学習支援の自動化率向上
 学内インフラを構築運用する上でのコスト削減やセキュリティの強化。使いやすいもの。
 学内のデータのバックアップ
 管理コストの削減
 管理権限を個別に設定できるのがあると学科ごとの管理が行いやすいと思います。
 管理者ユーザのみ二重アカウント認証にするべき（Gmail のように）
 簡単な手続きでできること。
 教職員間の情報リテラシーに差があるので、これが一つの障壁になっている。ある程度のスキルを持った教職員が増えれば、クラウドの利活用は大いに進むと予想している。
 教務システムのクラウド化と CMS の連携を安価で実現させて欲しい。
 現況、まさに「雲」を掴むような話で魅力よりだいじな部分での曖昧さがあって、期待を抱く段階にない。実用化されている世界的クラウドサービスの最先端について政府筋から警告が発せられている一方でこのような取組が推進されようとしていることの関係が了解しがたく感じる。そもそもクラウド概念に適度な合意はとれているのだろうか。
 現在のところクラウドへ移行するメリットはあまり感じておりません。
 個別の学科の要望に沿ったカスタマイズを行えるシステム。学生・教員・職員の操作性（使いやすさ）。通信インフラの低コストでの導入。
392

 高速なネットワーク，情報の機密性
 質問 29 に対する回答でも示したが、まだ、日本の大学教育に適用可能な十分満足のいく
教育支援システムはなく、結果的に、大学が負担するコストの増加や、小規模大学における導入障壁となり、日本におけるメディアを活用した教育の普及の障害となっていると考えられる。教育支援の観点からは、先ずは、このような問題を解決することが必要であると考えられる。
 小規模、手軽、安全にシステムの利用ができるのであれば期待したい。
 小規模な私立大学では情報基盤を充実させることがコスト的に難しい。アカデミックク
ラウドにより、大学として必要な情報基盤（サービス）を安価に取り揃えることができれば、国内の大学の底上げに大きくプラスになると考える。
 情報基盤として各データのフォーマットの統一がされることに期待。
 専門家の育成が必要
 他大学との連携によるコスト削減
 大学の所在地の災害時にでも対応できる方策を考えていく必要があり、そのような面でクラウド化を期待する。
 大学間連携によるデータ変有化の推進と活用
 知識が浅く，どの程度の経費が必要なのか推測できない 低コストであることを望む。複数の大学がお互いの教育資源を共有できるような仕組みであるとよいと思う。
 低コストであることを望む。 複数の大学がお互いの教育資源を共有できるような仕組みであるとよいと思う。
 低コストでの導入が可能となることを期待する。
 統一的なシステムが使用できるのは魅力 複数アクセスデバイスに対応させた場合のセキュリティ対策に不安を感じる。攻撃に対する防護や、障害対応への検討を並行して進めることをお願いします。
 無料なら利用します。
その他、ご意見等（抜粋） NII が中心になって、本学の様な小規模大学でも導入可能なクラウドコンピューティン
グシステムを構築してほしい。
 クラウドコンピューティング導入事例について検証を進めていただきたい クラウド化が進展するほど障害時の影響が大きい。障害対策やサポート体制の充実を望む。
（各校の管理要員の負担増大にならないことを望む。
）
 サーバ管理者が技術職員の場合、授業を行っていないので授業コンテンツ編集の実践ス
キルを身につけにくい システム的に把握できない部分があり、未回答の項目があります。用語の理解が不正確
393

のため、不明確な回答があります。
 学生の住所や成績データなどの個人情報は、本学個人情報保護ガイドラインにより最高度のクラスに指定されているため、学外のクラウドシステムでの運用は現行では難しいと思われる。
 近年、情報システムは教育においてもその重要性が一層増大しているが、同時に、シス
テムやソフトウェアも、益々大規模化、複雑化してきている。一方、昨今の大学運営の効率化の影響もあり、システムの構築、運用、管理、利用者サポートについて、大学教員が担わざると得ない状況が拡大しており、これにより大学教員の本来の役割である教育、研究にかける時間を過度に圧迫していることも事実である。とりわけ若手
教員の場合、プロジェクト予算等による任期付きで採用され、そのようなシステム運用を任され、十分な教育、研究機会を得られないことも多いと予想される。大学運営の効率化は致し方ない課題ではあるが、教育の情報化に必要なヒドゥン・コストをヒ
ドゥン・コストとしてではなくしっかり捉え、現代の情報化社会に則した形で技術職員を配置し、その上で金銭的コスト、人的コストの双方を抑制できるよう、システム
ならびに制度の両方において大学間で共通化可能な部分を共通化するなどした仕組み作りが必要であると考えられる。
 経年変化が追えるよう，継続的な調査を行って欲しい.
 効率化だけを目指した安易なクラウド化は，大学運営に大きな支障をきたす可能性があると考えている。なんのためにどこまでやるのか。大学業務や教育・研究方法等の違いも視野に入れながら，考えていく必要がある。
 私学の財政状況で新しい技術導入やメンテナンスは非常に厳しいのが現状です。ますま
す格差が広がるように思います。
 非常に意義のある調査だとは思いますが、「一時保存ができない」「該当する選択肢がな
い」「各アンケートで重複感がある」「ヘルプデスクに電話してもその場でわかることがほとんどない」等、実施にあたって改善していただきたいことが多々あるように感じました。
 本学では、これらのシステムの導入が有効と思われる、ごく限られた特別な履修コースにのみ、CMS/e-ポートフォリオを導入しています。
 本学では、学生ポータルとして履修登録システムを導入しており、ＬＭＳ的な要素も多少含まれておりますが、ＬＭＳ／ＣＭＳという位置づけではないため、設問 2.1 については「否」と回答しました。
 本学は、栄養士及び保育士、幼稚園教諭の養成校であり主として講義は、教員と学生の体面において実施することが最も多くＰＣ環境を利用する授業は、数科目しかありません。そういった趣旨の学部では、本件のような環境の導入は優先順位として低くならざるを得ません。
 本学は定員３５名の小規模短期大学で、現状では、上記問い合わせにあるようなシステ
394

ムを導入・構築する計画はありません。学内 Lan すら未導入の状況ですので、今回のアンケートについては、回答を遠慮させていただきます。

395４−２）学部・研究科向け
非常によく使われている（目安: 8割以上の科目）

よく使われている（目安: 6割以上，8割未満の科目）

ある程度使われている（目安: 4割以上，6割未満の科目）

あまり使われていない（目安: 2割以上，4割未満の科目）

ほとんど使われていない（目安: 2割未満の科目）

分からない

授業資料の提供（n=30）
50.0%
10.0%
課題レポートの提出・採点・返却（n=30）
23.3%
16.7%
13.3%
16.7%
メール等による教員・学生間のやりとり（n=30）
10.0%
16.7%
6.7% 6.7%
33.3%
テスト（n=30）0.0% 13.3%
13.3%
10.0%
46.7%
ディスカッション（n=30） 6.7%3.3%3.3% 6.7%
53.3%
ビデオ教材の提供（n=29）0.0% 6.9% 3.4%
17.2%
62.1%
SCORM 教材等のオンライン教材（n=30） 3.3% 6.7% 3.3%3.3%
46.7%
ソーシャルネットワーキング機能（n=29）0.0% 3.4% 0.0%
65.5%
0.0%
Wiki（n=28） 0.0% 0.0%
60.7%
0.0%0.0%

23.3%
0.0% 10.0% 6.7%
13.3%
16.7%
26.7%
16.7%
26.7%
10.3%
36.7%
31.0%
39.3%

図： CMS/LMS が有する機能の利用状況（国立）

非常によく使われている（目安: 8割以上の科目）

よく使われている（目安: 6割以上，8割未満の科目）

ある程度使われている（目安: 4割以上，6割未満の科目）

あまり使われていない（目安: 2割以上，4割未満の科目）

ほとんど使われていない（目安: 2割未満の科目）

分からない

授業資料の提供（n=66）
21.2%
16.7%
25.8%
13.6%
18.2%
4.5%
課題レポートの提出・採点・返却（n=65）
18.5%
7.7%
26.2%
16.9%
26.2%
4.6%
メール等による教員・学生間のやりとり（n=64）
14.1%
7.8%
29.7%
6.3%
32.8%
9.4%
テスト（n=66）
16.7%
7.6%
24.2%
9.1%
34.8%
7.6%
ディスカッション（n=66） 7.6% 6.1% 9.1%
18.2%
47.0%
12.1%
ビデオ教材の提供（n=63） 3.2% 6.3% 14.3%
12.7%
47.6%
15.9%
SCORM 教材等のオンライン教材（n=65） 1.5% 9.2%
9.2%
52.3%
26.2%
1.5%
ソーシャルネットワーキング機能（n=66）0.0% 1.5% 1.5%
63.6%
28.8%
4.5%
Wiki（n=66）
0.0% 3.0% 7.6%
45.5%
39.4%
4.5%

図： CMS/LMS が有する機能の利用状況（私立）

非常によく使われている（目安: 8割以上の科目）

よく使われている（目安: 6割以上，8割未満の科目）

ある程度使われている（目安: 4割以上，6割未満の科目）

あまり使われていない（目安: 2割以上，4割未満の科目）

ほとんど使われていない（目安: 2割未満の科目）

分からない

授業資料の提供（n=11）
45.5%
9.1%
課題レポートの提出・採点・返却（n=11）
18.2%
36.4%
メール等による教員・学生間のやりとり（n=11）
27.3%
9.1%
18.2%
テスト（n=11）
9.1%
27.3%
9.1%
9.1%
18.2%
ディスカッション（n=11） 9.1%
0.0% 18.2%
ビデオ教材の提供（n=10） 10.0% 0.0% 10.0%
20.0%
SCORM 教材等のオンライン教材（n=11） 0.0% 0.0%
72.7%
0.0%
0.0%
18.2%
0.0%
ソーシャルネットワーキング機能（n=11）0.0%
63.6%
0.0%
Wiki（n=11） 0.0% 9.1% 9.1%
63.6%
0.0%

図： CMS/LMS が有する機能の利用状況（公立）396

9.1% 0.0%
27.3%
9.1%
9.1% 0.0%
36.4%
0.0%
9.1%
36.4%
0.0%
36.4%
9.1%
36.4%
18.2%
50.0%
10.0%
27.3%
18.2%
18.2%

非常によく使われている（目安: 8割以上の科目）

よく使われている（目安: 6割以上，8割未満の科目）

ある程度使われている（目安: 4割以上，6割未満の科目）

あまり使われていない（目安: 2割以上，4割未満の科目）

ほとんど使われていない（目安: 2割未満の科目）

分からない

授業資料の提供（n=10）
40.0%
課題レポートの提出・採点・返却（n=10）
10.0% 10.0%
メール等による教員・学生間のやりとり（n=10）
20.0%
テスト（n=10）0.0% 10.0%
20.0%
0.0% 20.0%
ディスカッション（n=10）0.0%
0.0%
0.0% 0.0% 20.0%
ビデオ教材の提供（n=10）0.0%
SCORM 教材等のオンライン教材（n=10）0.0% 0.0%10.0%
0.0%
ソーシャルネットワーキング機能（n=10）0.0% 0.0%0.0%
0.0%
10.0%
Wiki（n=10） 0.0%
0.0% 0.0%

20.0%
20.0%

0.0%10.0%
20.0%
20.0%
10.0%
20.0%
60.0%
70.0%
60.0%
60.0%
80.0%
70.0%

20.0%
40.0%
20.0%

10.0%
0.0%
10.0%
10.0%
10.0%
20.0%
30.0%
20.0%
20.0%

図： CMS/LMS が有する機能の利用状況（高専）

非常によく使われている（目安: 8割以上の科目）

よく使われている（目安: 6割以上，8割未満の科目）

ある程度使われている（目安: 4割以上，6割未満の科目）

あまり使われていない（目安: 2割以上，4割未満の科目）

ほとんど使われていない（目安: 2割未満の科目）

分からない

授業資料の提供（n=6）
33.3%
16.7%
33.3%
0.0%
0.0%
課題レポートの提出・採点・返却（n=6）
33.3%
16.7%
16.7% 0.0% 16.7%
メール等による教員・学生間のやりとり（n=6）
16.7%
16.7%
33.3%
0.0% 16.7%
16.7%
テスト（n=6）0.0%
33.3%
16.7%
16.7%
ディスカッション（n=6）0.0% 0.0%
16.7%
50.0%
16.7%
0.0%
16.7%
ビデオ教材の提供（n=6）0.0%
16.7%
50.0%
SCORM 教材等のオンライン教材（n=6）0.0%
66.7%
0.0% 0.0%
16.7%
ソーシャルネットワーキング機能（n=6）0.0% 0.0%0.0%
66.7%
33.3%
0.0%
Wiki（n=6） 0.0% 0.0%
66.7%
33.3%
0.0% 0.0%

図： CMS/LMS が有する機能の利用状況（短大）

397

16.7%
16.7%
16.7%
16.7%
16.7%
16.7%
16.7%

利用対象総科目の8割以上

利用対象総科目の6割以上，8割未満

利用対象総科目の4割以上，6割未満

利用対象総科目の2割以上，4割未満

利用対象総科目の2割未満分からない

科目情報（全体，n=113）

1.8%
1.8% 0.9%

32.7%

43.4%

科目情報（国立，n=25）

24.0% 0.0% 0.0% 0.0%

44.0%

科目情報（私立，n=62）

41.9%

科目情報（公立，n=11）

41.9%

1.6% 3.2%
1.6%
1.6%
3.2%
11.1% 1.6%
0.0% 0.0% 33.3%
0.0%
0.0%
50.0%
0.0%

科目情報（高専，n=9）
科目情報（短大，n=6）

履修情報（全体，n=113）

33.3%
33.3%

5.3%

履修情報（国立，n=25）

29.2%
4.0%
0.0%
16.0%

履修情報（私立，n=62）

37.1%

33.3%

履修情報（短大，n=6）

シラバス情報（全体，
シラバス情報（国立，n=25）

14.5%
22.2%
16.7%

23.0%
32.0%

35.5%

21.0%
18.2%
22.2%

33.3%
0.0%16.7%

25.2%

シラバス情報（私立，n=60）
33.3%
0.0%
シラバス情報（公立，n=11）0.0% 0.0%
0.0%
シラバス情報（高専，n=9）
22.2%
0.0%
シラバス情報（短大，n=6）
16.7% 0.0%
0.0%

14.5%

37.1%

41.6%

50.0%
1.8% 0.9%
2.7%
20.0% 0.0% 0.0% 0.0%

37.1%

48.0%
0.0%

0.0% 0.0%
6.5%
81.8%
11.1%
0.0% 0.0%

0.0%
履修情報（公立，n=11）0.0% 0.0% 0.0%
履修情報（高専，n=9）

0.9%

0.0%

19.5%
32.0%

0.0%

16.7%

16.7%

45.9%

23.4%

44.0%

1.7%
1.7% 3.3%

36.0%
41.7%

18.3%

81.8%
11.1%

11.1%

18.2%
0.0% 33.3%

50.0%

図: CMS/LMS の教務システムとの連携状況

398

22.2%
33.3%

利用対象総科目の8割以上

利用対象総科目の6割以上，8割未満

利用対象総科目の4割以上，6割未満

利用対象総科目の2割以上，4割未満

利用対象総科目の2割未満分からない

科目情報（全体，n=77）
科目情報（国立，n=21）

科目情報（高専，n=5）

31.6%
14.3% 0.0% 0.0%
0.0%

科目情報（短大，n=6）

2.6%
2.6%
60.0%

33.3%

履修情報（全体，n=76）

42.9%

履修情報（私立，n=37）

37.8%

0.0%
履修情報（公立，n=7）0.0% 0.0% 0.0%
履修情報（高専，n=5）
33.3%

0.0%
0.0%
0.0%

28.9%

0.0% 0.0% 0.0%

シラバス情報（国立，n=21）

28.6%

0.0% 0.0% 0.0%

シラバス情報（私立，n=38）
0.0%
シラバス情報（公立，n=6）0.0% 0.0%
0.0%
シラバス情報（高専，n=5）
16.7%

31.6%

31.6%

0.0%
0.0% 0.0% 0.0%

14.3%
40.0%

50.0%

16.7%

39.5%

23.7%
42.9%

14.3%

32.4%
0.0%
0.0% 0.0% 0.0%

29.7%
14.3%
40.0%

50.0%

16.7%

47.4%

23.7%

57.1%

0.0% 0.0% 0.0%
83.3%

0.0%
0.0%
0.0%

19.0%

28.9%

0.0% 0.0% 0.0%

シラバス情報（全体，n=76）

26.0%

42.9%

71.4%

60.0%

履修情報（短大，n=6）

シラバス情報（短大，n=6）

2.6%

0.0%
0.0%
0.0% 0.0%
0.0%
0.0%
0.0% 0.0%
0.0%
85.7%

36.8%

履修情報（国立，n=21）

36.4%

0.0% 0.0% 0.0%

38.1%

科目情報（私立，n=38）
科目情報（公立，n=7）

1.3%
1.3% 1.3%

33.8%

60.0%

14.3%

39.5%
0.0%
0.0% 0.0% 0.0%

28.9%
16.7%
40.0%

66.7%

図: e ポートフォリオシステムの教務システムとの連携状況

399

16.7%

５）研究支援分野（当該部署，研究者個人）
A. 研究支援分野（個人）自由記述欄のまとめ（ヒアリング、公開を許可した回答のみ）
自身でシステムを構築している・したい理由 セキュリティや通信速度の問題
 コアを占有した状態でプログラムを実行する必要があるため．キャッシュミスによる性能低下が著しい．
 機微な医療情報を外部で処理できる環境がない。
 研究データの流出が心配 必要なアプリケーションのラインセンスの問題とセキュリティ(情報漏洩)が心配なため
 安全性を考慮した場合、研究課題ごとのサーバの方が良いと思われる。
 外部に頼るのはおかしい 実験系研究室では科研費では支出可能な程度の安価な PC しか支出が難しい
 大学メールを IMAP にしたい．データは NAS で十分．計算等はいらない 素粒子物理学に必要なソフト群を専門の方が管理している状況で、同様のサービスがクラウドで構築できるか不明
 情報の流出の心配からできるだけスタンドアロン環境での作業を希望する
 ある程度自分の慣れた環境がある場合が好ましいことがあるため
 一時的にたくさんの計算機を使いたい グーグルや商用サービスのクラウドサービスはセキュリティ面、著作権の面で問題
 データ量が大きいことによる利便性
 現在所属する大学で提供されている計算サーバは待ち時間が長すぎて実用的で無い．
 共同研究者の所有する、持ち出しを禁止されているデータが一部含まれている為。
 電子カルテそのものの利用を伴う研究であり、データ分析が目的ではないので、分析対象となるデータの生成は想定されない。また、データを利用する場合は、カルテ情報となるため外部持ち出しが基本的に不可能である。
 使い勝手次第
 施設外にデータを出すことに対するセキュリティ上の不安がある 自身の研究がクラウド基盤なので．
 個人情報の管理、セキュリティについての不安が少ない。
 さほど容量がないから。
 セキュリティ上の理由
 セキュリティ
 データ量が多いため、クラウドでは計算よりデータ転送に時間がかかってしまうから
 クラウドで個人認証や手続きが面倒になりそう400 十分な性能があればどれでもよい。
 データ管理が容易である．外部のサーバに頼らなくても十分にデータのバックアップが可能である．
 必要な記憶容量が少なく，情報の管理が容易。
 研究環境が限られている
 安全性と使用の容易さ
 情報が外部に置かれることに対して抵抗感がある．
 情報の漏洩を防ぐため、外部と、データが関わる様な通信をしない。
 扱うデータの伝送自体が課題になっている
 専門内での解析ツールはクラウドサービスではカバーできない データ構造の急な変更が可能
 計算機，ソフトウェアの性能，使用料，即ち，コストパフォーマンスが高いと思えないから セキュリティが不安 便利そう データの共有
 必要な計算資源量が大きくないから
 既にサーバが研究室にある。ソフトウェアが専門性が高いものが多い。
 環境や設定を自由に行いたい。場合よれば教育目的に学生に管理させたい。
 セキュリティの問題
 データ量の大きさ、プログラムのチューニング等からオンプレミスを希望 外部に情報が漏れると困るので
 利用しやすい。アカデミッククラウドサービスを理解していない。
 データや研究成果に一定のプライオリティを保持する為。
 解析ソフト環境がすでに構築されている
 所属機関にスーパーコンピュータがあるので、これを利用したい 公的クラウドだとどうせ研究期間終了後は直ちにデータ全て消すような愚かな運用をするだろうから，その後のデータ移動を考えると最初から自組織で管理したほうがマシ．
 やはり外部となると情報のもれなどが気になるので
 特許申請があるので、チーム内での共有にとどめたい データファイルサイズがが少なく研究室レベルでハンドリング可能
 過去の資産を利用しやすく，サーバを多重化することで信頼性も確保できる．
 研究室内のデータ共有
 共同研究の契約上の問題
 特に巨大なデータを頻繁にやり取りするわけではない 通常のクラウドだとメモリが足りない、レンタル期間の問題があると長期のデータ保存に401

向かない、緊急時の対応が必ずしも思うようにいかない 個人管理のサーバも欲しい 使用形態の自由度が大きい
 安全性についての危惧がある。
 容易なセキュリティ管理，低い情報消失の危険性，取扱手続きの容易さ
 ネットワークへの負荷が心配
 クラウドの安定性等がまだ不安
 転送スピード
 データへの頻繁なアクセスが必要なため
 既に研究所内で利用可能なクラウド環境が存在 情報セキュリティ・安全性の対策の問題
 高速で容量制限が無いため。
 クラウドサービスと比較することにより適切なものを選ぶため
 患者情報等が含まれている場合，ハッキング等によるデータの流出を最小限に抑えるために，物理的に外部と遮断されていた方が良い。
 アカデミッククラウドが必要なほど大容量のデータを扱う研究ではなため。
 本来の研究遂行のほかソフトの購入や維持に資金を回さなくてはならないから
 クラウドのセキュリティに未だ信頼が置けないから
 既に利用しているので、新たなサービスは不要
 利便性、コストの効率化、安全性（セキュリティ面、保管面（特に災害対策））
 セキュリティが心配だから
 クラウドサービスも利用したいが、インターネット環境が不安定なときに対応するためには、自室での研究環境に研究を進められる環境は確保しておきたい。
 サーバをいずれ学内に公開することが必要だから
 学部教育における基礎データとなりうるから
 データの所有権に関する問題や通信インフラに依存した研究環境は望ましくない．
 リモートドライブで充分
 実験データが外部にから簡単に見られないのか不安であるため
 本研究成果は自治体単単位での利用を想定している。現段階ではクラウド利用は想定していない。
 クラウドはセキュリティ面において不安があるため。
 性能測定などの実験が必要なため，限界まで資源を使うことがあり，共有環境は適さない
 応答速度、信頼性、自由度が重要である。クラウドサービスである必要性がない。
 データの共有や情報処理等が行えるから。
 入力および出力のデータは大容量（数 GB～数十 GB）になるためデータ転送に時間がかかりすぎると思われる。
402

 データの転送に時間がかかりそう 個人情報保護の点からローカルで管理するのが適当である．
 学生が windows のファイル共有に慣れている サーバが手元にあった方が、環境構築やデータの管理が行いやすい(自由に行える)。
 アカデミッククラウドの利便性が十分にわからないから
 地震などで研究室のサーバが壊れる危険性もあるし、また、公開ソフトウェアの資源を共有できるのはありがたい 計算コードが自前のため、適切なコンパイラが必要 自由にカスタマイズ設定ができない．
 データの流出が心配 個人のゲノム情報が含まれる可能性があるため
 クラウドのセキュリティが不明であるため

403

研究の実施にあたり、広く情報システムに関連して、現在抱えている課題や問題点について 高性能なサーバを提供するクラウドサービスが限られている。例えば、コア数が多い共有メモリ型のバーチャルマシンや大規模なクラスタシステムのサービスを提供してほしい。
 現在主にひとりで研究を行っているため、共同研究者との共有などの必要性は少ないが、今後そのような場合に情報共有を行う場合に媒体を郵送するなどしなくてすむ方法があればよいとは考える。
 ３０と同じく計算機の運用維持が負担．
 現在、どちらかというと理論的な研究が中心であるので、情報システム上の困難に直面したことはない。現在クラウドサービスは使っていないが、情報システム関連の資源を直ちに使える点は魅力的であるので、詳細を把握したうえで、利用を検討したい。
 データは、基本的に無料で公開されているものが多いが、必要データのダウンロードに、数ヶ月要する。この部分がボトルネックとなる場合が多い。
 主成分分析、多変量解析などを簡単で安価に行うことができるシステムを探している。
 脳波測定システムをネットワークから物理的に分離していますが、ウイルスへの対処が十分ならば、アカデミッククラウドサービスにつないでみたいと思います。
 必要とする計算資源量が不定期に大きく変動する．必要となったときに素早く利用したい．
 各種商用ソフトウェアを利用したい．主要なものについては，システムに既にインストー
ルされており，直ちに利用できることが望ましい．
 一部特殊なソフトウェアについては，システムへのインストールが可能であること，自前のライセンスサーバーの利用が可能であること，が望ましい．
 数値計算を専門としない研究者が計算ソフトをツールとして利用することを前提として，各種利用の手引の初心者向け充実を図ってほしい．"
 CPU を専有できる多数の計算機によるクラスタが利用できれば，研究が著しく進捗すると考えている．現状では，新しいアイデアを実装しても，結果が得られるまでに数日あるいは 1 週間程度を必要とする．海外の大学では，クラスタを利用し，数時間程度で実験を行っている．同様の環境が必要とされている．
 PC の OS が数年毎に更新され、そのたびにデータの移行を行う必要がある。
 医療情報を処理するために、VPN+プライベートクラウド的なホスティングができるものがあればよいが、それが出来ないので、ダミーデータを生成しての仮説検証や、院内に設置できるサーバの計算機資源の範囲内で進めているのが現状。
 データ容量が大きいため，ネット等を介した現状のクラウドサービスでは扱いにくい．
 計算処理に時間がかかる。膨大なデータの保存場所に困る。
404

 遠隔地の研究者が分析装置を用いて測定したデータを安全に取得できるよう、サーバを介したデータ管理を行おうとしている。また分析装置の遠隔監視システムも構築している。
 統計処理ソフトの利用が学内に制限されており，出張先での使用ができない．
 計算処理速度、コンピュータの設置場所(空調を含む)、定期的な買い替え等が問題です。
 無料のクラウドサービスの容量が少ないので、ポータブルの HD を持ち歩かねばならな
いことに不便を感じている。
 ハードの更新、維持費の確保。
 大規模並列計算システムが手軽に使える環境があれば使用したい．
 研究室など複数人が使用できるサーバを構築したいが、専任のスタッフがいないため維持管理の目処が立たず実現できていない。
 他科，附属病院との情報共有が出来ない。
 患者のデータベースが，電子カルテから必要な情報抽出ができない。"
 科研費や民間助成金などで PC やソフトウェア，バックアップ用 NAS の購入ができないものが多いため整備が難しい。クラウドスペースは，学内規定で契約が禁止されている大学もある。
 バックアップは手作業で行っており、頻繁にもできないので、データが全部失われるような事態となれば、研究遂行への影響がある。ただし、このようなことは見越して研究を先に進めておくべきである。自身で抱えている課題ではないが、放射光施設のデータな
ど、世界中から解析のための共用される目的のデータのバックアップ体制などが確立されるべきではないかと思われる。研究機関相互の信頼にも関することであるように思う。
 学外機関などとの情報共有．特に，情報系スキルの異なる利用者間における情報共有．
 データ転送速度が遅い。エクセル、ワードはあるが、PPT ファイルのブラウザでの表示機能がない
 計算機環境の構築に、導入、設置、設定までにかなりのエフォートを割かなければならないのが問題であり、この部分の負担軽減につながる方法があれば、ありがたいと存じます。また、計算機環境のシステム稼働中の管理に関しては、特に外部から不正アクセス対策や、停電などの障害対策に某大な時間が費やされております。
 メールの IMAP へ移行したい．
 他研究機関に所属する研究者とのデータのやりとりにおいて、大学等のセキュリティのために利用できない転送システムがある。研究者個人によって利用しているクラウドサー
ビスやそれらの利用に関する知識が一元化されていないため、研究課題ごとに調整が必要になる。
 統計処理や数値計算に市販のソフトウェアを使用したくても，研究費を圧迫するので購入したくてもできない．バックアップは常に PC の処理資源（と人手）を占有しており，顕在化しない効率の低下を招いている．
 実験で得られるデータが 500 TB/年に近い量で、バックアップディスクの確保が難しい状
405

況である。
 疫学研究で、データがどんどん増えていますが、データベースソフトの選び方や、適切な管理方法が分からず、エクセルファイルでいくつものファイルを保存しています。クラウドサーピスとはどのようなものか分かっていませんが、これらが解決できると有難いです。
 アドビ社のデザインツールを使用しているが、クラウド化になるとスタンドアロンでのパソコン使用が煩雑になる。最新のものを買い取り購入し、後は長く使うのみと考えるが、不安である。また、宅ファイル便でのデータ送付を使用していますが、著作権にかかわるデータですので、こちらも不安を抱えつつ使用している状況です。
 画像処理ソフトが利用できるとありがたい。現在使っているソフトは Image-Pro Plus というもので、Windows XP のパソコンでしか作動しないので、新しいコンピュータでの使用ができずに不自由している。
 DropBox は容量に制限があり、研究グループ内で共有したいすべてのデータが共有できない。機能や作動に不安がある。
 特定の研究者間での大量データの共有
 頻繁に行われるソフトウェアのバージョンアップに対してその費用が嵩む。 将来にわたって信頼できる、データのストレージサービスなどバックアップシステム。
 文字データを扱った処理をしえいるため、計算能力の高い（速い）コンピュータ、カスタマイズができる環境、定期的なバックアップ、ネットワーク経由でどこからで入れる環
境を整えるのは自力では大変なので、メンテナンスを含め、その環境を提供していただ
けるのであれば理想的です。
 病院患者データを解析する必要があるが、セキュリティの問題があり、取出できる場所が限られ、転送速度もかなり遅く、研究に支障を来している。
 研究開発の実施にあたって、自由にプログラムを実行可能な専用のサーバシステムを要するが、その設定、維持管理が煩わしいのは確かである。
 また、研究用データのバックアップだけであればクラウド上でも構わないが、教育用デー
タに関しては、災害等の危険性もあるため、むしろこちらのパックアップをクラウド上に行いたいが、パブリッククラウドはセキュリティの不安があるため、利用していない。
"
 出張が多いので、ノートＰＣに最新データを常に移しておく必要がある。
 面倒な上、個人情報が含まれるものは持ち出しできない。"
 遺伝子配列解析ソフトのバージョンが古くなり、古いＰＣでしか使えない。新しいＰＣで使用可能なものは高価で購入不可能です。共有ソフトのようなものをダウンロードして使えたら是非利用したい。
 クラウドストレージには興味があるが、経費がかかるのが難点（Dropbox の無償ストレージなどは活用している）
406

 大容量の画像データを最近扱うようになってきたので、課題は今後見えてくると思う。"
 他大学の共同研究者とのデータのやり取り、大容量のデータの加工などで困る場合がある。
 バックアップが機関内ではない別の場所で行えれば、災害時等安心だが、セキュリティが心配
 バックアップを定期的に行うことが可能な仕組み
 データというより研究成果を効果的に発信したいが、そのための公開リポジトリ（いわゆる機関リポジトリ）の運営体制が、ほとんど機能していない。現大学のリポジトリはもっぱら紀要等の公開のみを想定しており、研究者独自の事情に応じた研究成果の公開（特に科研の成果公開については各大学等での体制整備が求められるはずだが）には対応できていない。研究成果公開はもとより、データ処理等については小規模の大学・研究機関ほど、クラウド的システムが求められるのではないだろうか（要するに各大学等でのマンパワー不足への対処）。
 心理学の個人情報データを扱うため，とくに守秘性に関して，インターネット環境での不安を払拭できない．
 民間のクラウドサービスを利用するための問題点として，現在所属する部署が遠隔地であるため回線が細いことと，セキュリティポリシー遵守の観点から積極的な利用ができな
いことがある．
 災害時のバックアップについては考えおらず、確かに必要だと感じました。
 1job の最小限度の CPU_time が最新の PC を利用して、数十万 sec となり、3 日程度かかる。並列処理のプログラムへ個人で変換することも困難です。もっと早いコンピュータを利用したい。
 複数のマシン（据え置き、ノートＰＣ、タブレットなど）を状況に応じて使わけるので民間のクラウドストレージを通常のデータ保存に利用する（バックアップにも利用する）
が、容量不足でどうしても有料契約を行わざるを得ないこと。また個人情報を含むデー
タ（インタビューや写真など）は、セキュリティを考えると、どうしても民間のクラウ
ドストレージにはアップできず不便を感じる。
 アカデミックで閉じたサービスが提供されても、機関外との共同研究には使いづらい。パブリッククラウドをアカデミックで契約すべきである。
 ファイル保守料が高額なので、ローカルなディスクへバックアップしたり、ローカルなディスクから必要なデータをリストアしたりする必要が生じる点が不便である。
 可能な限り多くの場所で WiFi 接続できるような環境を手に入れられていません．情報シ
ステムをいつでもどこでも利用するための基盤が不十分です．
 VTR による映像データが多いため、バックアップ等に時間がかかる
 HDD へのバックアップに時間がかかる。
 OS やアプリケーションソフトのバージョンアップに伴いファイルの互換性が失われることがある。互換性確保環のための旧機種の維持、もしくはデータ変換・メディア移行作
407

業が負担となっている。
 十分なデータセキュリティやバックアップに充てるべき予算や人的余裕がないこと。
 研究成果を長期間公開できる無料の web サイトがあるとありがたい。
 現時点でも多くのクラウドサービスを利用しているが，個人情報や研究の生データのバッ
クアップ等はできない（セキュリティ的に）．そのため，Dropbox レベルで簡単に利用可能でかつ個人情報等もセキュリティを確保した上で利用できるストレージサービス
や計算機資源の利用を希望する．
 また，自分の研究テーマは教育に関わるものであるが，教育向け演習環境をパブリックク
ラウド上に構築するのは，まだまだ非常にコストがかかる．AWS 並に容易に利用でき
る IaaS 環境が使えることと，その IaaS 環境へのネットワークに余裕があり（複数人数が同時にアクセスするため），ストレージに余裕がある（詳細なログ情報の収集を行う
ため）状態が望ましい．
 サービスだけを使いたいが、サーバ管理やセキュリティ管理など、付帯する負担が大きい。
 計算機の設置場所の電源、空調の制限が厳しい。かといって遠隔地にサーバを設置すると、データ転送においてネットワークがボトルネックになる。商用クラウドの利用もデータの転送と蓄積に難がある。大規模データを利用した分散システムについて、まだよい解がない。
 ファイルの安全管理 研究代表者は、全く分からず、研究分担者に依存している。
 災害対策は必須だと思う。
 予備調査中で、本調査がどれだけのデータ量になるか分からない。"
 種々異なる研究ニーズに対応する計算機資源を適切に確保するのが難しい。
 データベースのバックアップについては自力で自分研究費で捻出せざるを得ず、ある程度のものを提供してくれるとありがたい。
 Dropbox の利用は便利ですが、セキュリティの観点から不安もあります。
 データ処理ソフトが毎年のごとく，バージョンアップしているが，これについていくほど経費がない。
 データの漏洩
 パブリッククラウドサービスを利用しているが，費用の問題があり，満足できる規模の環境を構築できない．費用の問題が解決されれば，より大規模な環境を構築したい．
 Matlab をクラウドで複数走らせて実験を効率化をしたかった．北大では CPU に応じた利用ができるが，Matlab をクラウドサービスで利用できるのは北大関係者のみであったので利用をあきらめた．
 自身は病院内に長くいます。その間は病院の方針として無線 LAN の利用ができません。
自前のルータを準備するかしかないありません。
 データフォーマットが異なる場合、各フォーマットについて処理システムを設定する必要
408

があるのが、面倒。
 現在使用しているプログラムには計算に必要な時間が非常に長いもの (1 週間以上) があり、そのために作業効率が低くなっているのが課題である。
 使用しているプログラムに計算に長時間 (1 週間以上) かかるものがあり、作業効率を低下させているのが課題である。
 パブリッククラウドサービスでは、個人の経費がかさむうえに、容量も限られている。
 プロジェクトごとにクラウドを構築し、データの整理、特定の共同研究者だけがアクセスできるなどの制限を設けることが出来れば便利。
 複数台のコンピュータで同じのアプリケーションを使いたいが、ライセンス数の制約で使用できない。台数分のライセンス数を確保するのはコスト面で負担である。
 環境を購入・準備するリードタイムが長い。
 バックアップが手間。"
 ストレージの不足 自分で行っているバックアップには不安があり、どこかに保管できると安心に思います。
 安全なバックアップシステムの構築を期待します。
 個人情報や類似のデータについて、クラウドサービスを活用できるような安全なシステ
ム・サービスがほしい。
 開発途上国との通信を行っており，共同研究先の通信環境の制約が強い。
 各研究所や大学が VPN 接続を要求するようになり、他大学、複数研究機関にまたがる共同研究者間での情報共有方法は dropbox を使用しているが、セキュリティとともに容量の制限があり困っている。アカデミッククラウドのようなシステムができれば、研究遂行上非常にありがたい。
 シミュレーション研究を行うために、高速で計算できる計算機が必要であるが，購入する資金がない．また学生の使用するパソコンは，個人のものに頼らざるをえない．
 ネットワーク接続が不安定な環境（とくに海外出張時）があり、そのためクラウドシステ
ムへの移行を躊躇している。
 どんな施設でも停電が必ずあり、そのたびにトラブルに見舞われる。
 クラウドサービスは誰かが盗聴している恐れがぬぐえない。
 バックアップシステム構築が面倒。コストも高い。
 個人情報が含まれている可能性があるため、外（クラウド含む）には出せない。
 データ処理等は個人レベルの PC で十分であるが、将来の研究の参考のためにも過去のデータも長期にわたって安全に保存できるようなクラウド環境が必要と思いますが、現時
点では活用できるものはありません。
 dropbox 以外のクラウドサービスはことごとく使いにくい。フォルダのように使えて自動でバージョン保存、バックアップされていることが必須。
 dropbox 以上のサービスでないと乗り換える気は全く起きない。"
409

 セキュリティと使用上の簡便性の両立
 自分の個人研究室に置かれているパソコン及び NAS に保管しているファイル類は、研究科内のネットワークから見られたくないのだが、そういう場合の設定に関する情報提供がほとんど行われていない。ほとんどが企業のオフィスにおける設定ばかりで、そうい
う場合は社員のパソコンは会社のネット管理者が自由に覗けるようになっていたりす
るので、参考にならない。
 大容量データの研究者間での転送、共有が容易ではない。
 今後、大学のセキュリティ対策で、システム構築の自由度が減る可能性がある
 研究費が削減されている現状では，速い計算機．十分な機能のシミュレーションソフトウ
ェア共に高価と感じる．
 画像データが多いので、現在はハードディスクで保存しているが、近い将来は大容量記録装置が必要になる可能性がある。
 データのバックアップについてはいつも不安を感じているが，手が回っていないので，安全なクラウド上に簡単にバックアップができればありがたい．
 別の研究施設にてデータ測定を行っているので，データを別の保存媒体に保存し損なった
場合は当該施設に赴いて取得する必要がある．
 通信速度の向上，利用価格，メンテナンス ネットワークのデータ転送スピードが速いといいなぁというのはよく感じます。自分の思考速度より遅いと、能率が悪い。
 計算機の処理速度の高速化とメモリの大容量化
 学内 LAN のトラフィックが小さい データバックアップが基本的に人海戦術になっており，そのためのアルバイトなどを雇用している．
 本研究の場合はパブリッククラウドで機能的には十分であるが予算等の手続きが面倒である。
 セキュリティパッチの適用，OS バージョンアップへの対応等に手間がかかっている テープシステムの運用や、計算機システムのメーカによるサポートなど、ハードウェア以外のコストが高い。計算機システムを集約することで運用コストを下げられると良いと思う。
 テープシステムの運用や、計算機システムのメーカによるサポートなど、ハードウェア以外のコストが高い。計算機システムを集約することで運用コストを下げられると良いと思う。
 職場に据え置きの自分専用パソコンで、データの整理・処理・分析をおこない、物理的に別のＨＤＤ等へバックアップを実行しているが、仮に甚大な災害に見舞われた場合、全てが失われる可能性がある。
 クラウドへのバックアップも検討したが、取り扱うデータ量が多いため、転送速度がネッ
410

クとなっている。また、研究期間内のみでの契約を原則と考えると、クラウドサービスの契約は研究期間満了とともに終了すべきであることから、将来的な研究展開や経年変化検証等を見込む可能性がある場合、馴染みにくい。
 利便性に魅力はあるが、セキュリティが不安で踏み出せない 要員が確保できないので運用管理を学生任せにせざるを得ない。学生は卒業で入れ替わり、毎年適切な人材が確保できるとは限らない。
 問題という訳ではないが、専用サービスは使い方がよくわからないイメージがある。（ある程度のプログラミングのスキルが必要とか）。
 google のストレージサービスのような感じで、何も考えずに簡単に計算等が利用できる
ようであれば使いたい。現状では、クラウドとか言葉では知っていても実際のとこどういう風に使うのかよくわからないので、多少時間がかかる計算でもパソコンで行っている（時間がかかると言っても一晩ぐらい動かし続ければ事足りる程度ですが。）"
 セキュリティ
 学外のサーバにバックアップもしくはクラウドを利用を希望しているが大学のネットワ
ークが貧弱なため，仕様がためらっている。
 バックアップの必要性を感じているが、まだ簡便なバックアップ体制を整えてない。研究室の PC 入れ替えのたびに、データ移動が面倒。そういう意味で、クラウドの意味はあると思う。
 データ発生場所が複数個所にあり、今は専用線が無いため、データの集約が面倒 計算機の維持管理に時間をとられる。
 研究所のセキュリティポリシーによりクラウドサービスへのアクセスは原則不可なのが不便。
 バックアップを兼ねたクラウドサービスがあればよい。
 研究室内でのデータ共有等が簡単に行えるようにしてほしい。"
 何れも研究者個人に最終責任があるものとして対応を余儀なくされているのが実情だと思われ、課題研究に対して集中されるべき時間的・経済的・身体的・心理的なエネルギーが多くが本来の目的以外に費やされてしまっている現状は残念である。
 バックアップ用 HDD の必要容量が年々増加し、HDD の購入や保管が面倒である。
 科研費を利用した研究にのみ該当する懸案ではありませんが、昨今、多数の研究者による共同研究が盛んです。これまで、共同研究者との論文作成において、共同研究先とのフ
ァイルの共有が重要な懸案になりつつあります。これまでは、google や dropbox 等のファイル共有サービスを、情報の漏えいを気にしつつ利用するしかない場合がありまし
たが、このようなファイル共有サービスを、日本の研究者コミュニティに閉じた形で利用できれば良いのではないかと思っております。
 データ処理、バックアップ、クラウドサービス等の必要性や利点は感じているが、研究代表者のみでの管理運用には無理があるため、個々のバックアップ等の対応しかできてい
411

ない。
 クラウドサービスの安全性が保障されていない点が心配であり、個人情報等を含むデータを載せられないため、複数の PC 間で作業するうえでの不便を感じている。
 大量かつ高速な計算処理ができない。専門ソフトでの操作性や output data が複雑であると、その後の処理が煩雑になり、total では長時間を要することになる。それらの簡便性の必要性を感じる。
 共同利用している計算機（高性能演算サーバー）の資源が埋まっていることが度々あるため，少ない資源でも占有サービスを利用すべきかも知れないと思っている．その申込み（および利用終了）のタイミング・期間が比較的自由に設定されていれば嬉しい．
 アプリケーションや OS のバージョン管理などを考えると Thin-client なシステムは魅力的であるが，構築するためのマンパワーや，トラブル時の信頼性などの点で移行できない．
 災害対応がない．管理を個々の教員で行うしかない．
 災害時のデータのバックアップは年々データ量が肥大化していることも有り心配 今の情報量では時に問題なし
 普通の大学では研究用の高度な統計処理ソフト（エクセルなどではなく）などが無償で支給されるが、当大学ではないのが非常に不満である。
 最新の情報に対応していない．
 データ処理は、個人のコンピュータで行っているが、OS やソフトのバージョンアップは頻回にあり、それはセキュリティに関する件も含まれているため、出来るだけ最新の環境にすべきと考えている。そのためには、研究費のみだけでは不十分なので、自己で投資しなければならない。クラウド上で、常に最新のソフトが使用できればと考えます。
 計算処理にパソコンを使用しているが、個人所有の PC の処理能力の限界があるが、スーパーパソコンなどの高額な費用が必要なサービスが使用できない。データ処理のソフトも個人で使用しているものを流用しているが、大学などのクラウド型ソフトを使用した
い。災害時のバックアップは個人的には必要であると思われるが、費用の関係もあり、利用できない。またデータそのものが個人情報なのでセキュリティを個人でいかに担保するのか、どうしたらいいかが分からない。
 研究者向けに安く，安全で便利なデータ保管（バックアップ）サービスが必要．当方が抱えているデータの総容量は 10TB 程度．
 リアルタイム処理に関して、利用できるリソースが技術開発途上である。
 フィールドワークで録音・録画した，編集前の wav データの長期的な保管場所が欲しい バックアップのための容量が不足するため，改善が必要である．しかし，使い勝手の問題も同時に発生する．
 ソフトウェアのアップデータによるシステム管理の負荷がやや問題と感じることがある（最近は，サーバ用途のディストリビューションを利用しているため，その負荷も軽減
412

されているが）．基本的にはバッチ処理で動作するため問題はない．
 研究室内のデータ共有を行いたいが，管理者の負担が大きくなることが予想され手付かずになっている．
 大学が提供している計算機はネットワークへのアクセスに制限がある（学外から利用できないなど）ので不便
 データ処理をパソコンで行っていますので、時間がかかります。
 人文系の研究なので、国会図書館やアジア歴史資料センターなどで提供しているサービス
で対応できる。ただ、人文系の総合的な検索システムがないような気がしている。
 個人契約によりクラウドサービスを使用中だが、金銭面や使い勝手などで不満が多い。機
関ごと、あるいはアカデミックの世界全体でクラウドを共有出来た方がいい。機器のアップデートやバックアップも自動化出来るとうれしいが、セキュリティを確保することは難しいので、現実的ではなさそうだ。
 大量の情報処理が出来なくなっており、新たなより処理能力が高い PC が必要になっていること。
 メモリやディスク容量の問題から、ハイブリッド環境で所内クラウドと自前サーバを共有している。公開・デモ用のウェブサイトについては自前のサーバを用いているが、セキ
ュリティや保守面での問題から、クラウドに移行できるものがあればそうしたいと考えている。
（ただ、ウェブ上のデモで使っているソフトがいろいろあり、業者開発の場合はバージョンもある、現行のサーバからの引っ越しにコストがかかる、等々で、それほど簡単ではない。
）
 研究進展に伴ってデータ量の増大が避けられず局所的には数十 TB 単位で変動するデー
タが発生することが直ぐ先に見えている状況にあります。HDD の単純な増設を超えて、安定したデータ保管・転送・処理が出来ることを期待したいと考えています。
 バックアップは現在月 1 程度で手動で行っているが, クラウドの利用などにより自動化,
もしくはサービス側に任せられれば助かる．
 遠隔地バックアップのための記憶媒体を高等教育機関として公的な形で安全に運用できるとありがたい。
 大きなサイズのデータなどを共同研究者へ送るときは、DropBox などウェブ上のフリーのシステムを利用していますが、安全性など不安があります。バックアップは外付 HDで行っていますが、将来データを取り出せなくなるかもしれないと考えると不安です。
 バックアップ時の転送速度、保存容量にまだまだ制限がある
 ネットワークの不安定さ=自分以外のトラフィックが原因でサーバレスポンスが低下したり通信が途絶えてしまい，その間作業が進まない場合に困る．
 セキュリティへの不安=クラウドサービスを利用した場合のデータの漏えいなどの問題への不安が大きい．自分で制御できない事象によって，自分に責任が及ぶ可能性があるのが大きな不安．
（サーバ管理者のミスによるデータ漏えいや損失などを含む）"
413

 パソコンからでーたセキュリティと利便性のバランスが撮りいくい 計算処理やデータ処理が研究の主要部ではないので，複雑なシステムの構築・利用のために時間を割かれるのは避けたい。セキュリティ，信頼性の高いバックアップ，クラウドサービスが有れば利用したい。
 統計処理、遺伝子配列解析、配列デザインなど研究者が共有できるサービスとその活用について個人差がある。
 動画などの大容量データのバックアップコスト
 セキュリティレベルの程度、個人情報をどこまで含めることができるか 学内外の研究分担者との情報共有のために、大容量のバックアップ、クラウドサービスがあれば便利である。
 データの中に個人情報が含まれることもあるので、個人情報が含まれない形に処理した後でないとクラウドサービスは利用しづらい。また、ルール作りが追いつかない。
 全て 1 人で行っているので負担が大きい。進捗速度はマイペース。サービスの変化に追従できない点もある。
 研究機関の異動に伴う研究データの移転が大変
 サーバ群を自分で構築して利用しているが、機器の更新に関して時間的・資金的な不安がぬぐえない。
 ＨＤやパソコンの故障の不安があるので，個人のＨＤでないアカデミック利用のサーバに保存できれば安心です．
 以前の機関では計算ソフトなど利用者数は限られていたが、毎年更新されたものが無料で使用できたが、移動した先にはなく、個人での購入が余儀なくされている。研究環境によって差があるのは残念。
 小規模な研究室(構成人数 10 名くらい)であれば、市販の NAS で対応できると思われるが、
バックアップの多重化を行うことが望ましい。もしそのニーズに応えられてかつ信頼性のある組織が実績のある運用会社の協力の下で、研究者のための安価な情報システムを構築できるのであれば、価値のある施策になると思われる。
 個人的にハードディスクや大学のファイルサーバにバックアップを取っているが後者についてはセキュリティに不安を感じることがある。アカデミッククラウドに関して言え
ば、さらに心配であり、利用をためらわせる要因となる。
 そもそもパソコンなどの機器を研究費とは別に支給してもらわないと、研究に支障が出る。
 たまにデータの書き換えミスがありますが、大きな問題点はありません。
 当課題は生化学実験や動物の行動解析、およびそれらの数値データを統計的に解析することが主となっています。主に画像データやエクセルデータの形でデータが取れます。容量としては数百 KB から数 MB くらいのデータが主で、研究用 PC での処理で間に合っています。
 不足しているわけではないけれど、統計処理、画像解析、DNA などの配列情報の処理ソ414

フトがオンラインで共有でき、自分の PC で処理できれば便利だと思います。"
 教員が片てまで管理しているために、十分に管理ができずに効率が悪い。
 図像データの容量が大きく、クラウドの契約容量をオーバーしてしまっていたところ、パソコンが壊れ、クラウドにアップできていなかったデータを失ってしまった。
 ネット環境が無い場合に非常に不便
 職場や家で共通したデータの作業を行なうため、様々な計算機(Windows や Linux)で利用できるクラウドサービス(google, Dropbox)を利用する機会が増えてきた。
 より保全性の高い専用サーバを利用したいが、コスト等で難しいので安全なクラウドサー
ビスがあると大変ありがたい。
 機密情報の流出
 シミュレーション実験を行うにあたり、研究室内の計算機でしか実験が行えないライセンス形態のソフトウェアを利用しており、コーディング・デバッグ・実験の実行等が円滑に行えない。
 バックアップ等の最低限のことは行っているつもりだが、情報処理に明るくないため、不本意に個人情報や重要情報を漏えいしないか心配。
 定期的に自動バックアップしている 海外の図書館の史料のデジタルファイルは、圧縮されたかたちでダウンロードするケースが多いが、長い時間がかかり、処理スピードの高速化ができればと感じる。
 バックアップサービスがまず必要。
 クラウドサービスによる遠隔でのバックアップの必要性は感じているがサービスについての情報不足，セキュリティの不安から使用していないのが実情．公的に研究支援のためのサービスがあれば利用検討したい．
 計算機環境の維持・管理コスト（人的・経済的コスト）をなるべく減らしたい。
 個人情報保護の観点から、セキュリティのしっかりした 100GB ほどのクラウドサービス
を有料でもよいので使用したい（現在はセキュリティを考えて CANON の Home を使用しているが、高額なために 10GB 契約私費契約のみ）。
 科学研究費からクラウドサービスの契約料を払うなど書類手続きが可能であればなおよい。
 現時点ではパソコン使用でほぼ問題無いし、バックアップも自動的に HD に保存はしている。しかしながら上記に指摘があったように災害時の対応などを考えるとクラウドサービスの利用に関しては検討すべきかとは考えている。
 データ処理に時間がかかる。現在は、夜間のみ複数の PC を借りて処理を分担させ実施している。
 動画，写真，CAD 図面などを共同研究者とやり取りする際，メール添付ではデータが大きすぎるため，各先生が使っているファイル転送サービスを使って 1GB 以上のファイ
ルをやり取りしている．都度にやり取りするのは手間である．
415

 所属する研究所のシステム管理室が広範にわたって支援体制を組んでいるため、とくに問題は感じていません。
 各研究者のローカルにあるデータを確実にバックアップするシステムが必要．
 計算機の管理をしてくれていた博士課程の学生が、今年度で学位を取って修了する。来年
度は修士の学生しかおらず、管理を任せられるかどうか不安である。
 現在は、表計算ソフトやグラフソフトでの計算で可能な範囲であるため、特に問題は感じていない。
 データの性格上，オフラインのパソコン上で，特定の解析ソフトを用いてデータ解析を行うため，クラウドサービス等は利用できない．
 高速シーケンシングで数 GB/file のデータが得られるが、共同研究者間でオンラインでやりとりする方法がないため、やむなくハードディスクや USB メモリを行き来させている。
 バックアップについて、個人で USB メモリや外付け HD に保存し、研究室内に保管しています。安全なクラウドサービスなど他に確実な方法で保存できると安心だと思います。
 データ処理に必要なソフトが多すぎて（容量が大きすぎて），パソコンの容量がすぐにいっぱいになってしまう。
 無料版では５ＧＢと容量が少ない。
 特にパソコンの使用のみだけですが，バックアップが大変です。
 バックアップデータの定期的な取得が結構めんどくさいが、実際にトラブルに見舞われた
ときに、かなりのデータを失い、大変な目にあったこともある。
 手元にバックアップを置いているため、災害時に不安がある。出先で作業を行う場合に、環境やデータが持ち運べない。
 現在，分析機器に付属しているコンピュータの個人のデータは，それぞれのコンピュータに分散してしまっています．特に顕微鏡の画像データなど，移動に時間がかかるデータ
は，解析と同時に一カ所に保存し，共有できるシステムがあればと思います．
 データのバックアップ先としてセキュリティの観点でクラウドサービスに不安がある。
 既存のマニュアルがわかりにくい パソコンで mpich2 により自分で MPI を構築しているが，構築の際，知識不足のためつまらないトラブルの解決に時間をとられてしまう。
 クラウドサービスやオンラインストレージサービスが昨今注目を集めているが外部に研究リソースを補完するのに不安がある。国などが保証するような信頼性の高いクラウド
サービスが今後ますます普及することを期待します。
 公的なクラウドであれば信頼できるだろうが、私的なクラウドは、情報秘匿に関して信用できるかどうか確証が持てない。
 共同研究者とのデータ共有をより効率的に行いたい．現在は dropbox などを利用している．
416

 個々の PC で行っており、共有データベースが求められるところではあるが、研究室単位では構築が難しい。費用などよりも、セキュリティなどテクニカルな問題。
 クラウドサービスは無料のものを利用しているが、容量制限があって大量の画像データ同期には不向き。この点をなんとかしたい（してほしい）。
 TB クラスの主記憶を必要とする．
 研究施設外にデータをバックアップ出来る環境を構築できていないため，研究施設が全損する災害が発生した際には，全ての研究成果が損なわれるおそれがある。扱うデータには，部外秘のものも含まれているため，一般の無料ストレージなどの利用は困難である。
研究費等で独自に構築することは可能であるが，管理に時間を割く必要が有るため現実的ではない。ある程度のセキュリティが確保された信頼できるバックアップサービスがあれば利用したいと考えている。
 外部に持ち出す場合にいちいち違うメディアに移す作業などは，無駄な作業だと感じています．一括でどこかのストレージにアクセスできればとても便利だと思います．
 バックアップを忘れることがあるため、パソコンに故障が生じた際は困る。
 40 万セルという（500Hz サンプリングで一人当たり 800 秒）大規模データの下処理に時間がかかるため、短縮したい。
 データのバックアップの効率化、自動化
 Dropbox に代表されるサービスは特にバックアップを意識せずに変更の生じたファイルを自動的に即座にクラウドストレージに上げてくれるので便利であるが、一部の外国政府がのぞき見しているという報道もあり、一部のパーソナルな用途を除いて使用を躊躇している。
 その点、研究に特化されたものでもかまわないので同様な利便性を持つクラウドサービス
が日本国政府から提供される（トラブルフリーな）ものであれば是非とも利用したい。
 クラウドサービスの横断的な利用
 大規模災害に備えたバックアップの必要性を感じている 計算結果は再計算すれば復元できるものもあるが，地震観測データ等が失われると同じ自然現象は二度とは起きないことから復元は無理" 計算機の更新時に過去のデータを移動するのに要する時間が膨大である．
 ヘテロな計算機環境(Windows, Linux, Unix)の一元的な自動バックアップ体制ができていない．
 上りが遅いのが面倒です。
 バックアップやセキュリティ対策に十分な手がまわらない 学術用に用意されるなら，そのバックアップ領域や情報システムはぜひ利用したい．
 ソフトウェアのバージョン管理が面倒。
 大学内の電気設備点検などが、年間複数回あり、しっかり把握しておかないと、突然の電源断となる。
417

 バックアップ電源は準備しているが、バックアップ時間はシャットダウン時間程度である。
 統計ソフトが高額であること
 管理ができる研究者が激減している．
 データのバックアップについて：実験室の電気容量が少なくブレーカーが落ちることがある．遠隔地バックアップなどの前に，無停電装置などの導入が必要であると考えている．
 システムの安定性の問題、転送速度の低さ、バックアップの煩雑さ。
 リテラシー Web サービスに関する研究のため，研究室で所有しているサーバの運用コストが大きくなっている．また，分散システムの運用に伴いログも蓄積しており，日々の他のサーバとの同期に時間がかかるようになっている．
 研究における情報システムに対し、特段の課題はない。
 プロジェクトの協同研究者との間で、大容量の研究資料を共有すること、一つのドキュメ
ント等に複数人がアクセスし、更新し、各人の手元のものと同期させるための方法の確立に悩んでいます。
 気軽に使えて確実に 2TB 程度のデータをバックアップするシステムが無いため，自分で手作業で行っている．脆弱であり，危機管理が弱いと感じている．
 気軽に使えて確実に 2TB 程度のデータをバックアップするシステムが無いため，自分で手作業で行っている．脆弱であり，危機管理が弱いと感じている．
 特に抱えている課題や問題点とまではいきませんが、研究に関しての様々な情報システムのサービスが利用できれば、便利だと感じています。
 大学のグループウェアやメールシステムより，民間（例えば Google のサービス）のそれが使い勝手がよく，高速・容量制限もないため，これらを利用した，あるいはこれらと連携可能なアカデミッククラウドがあればありがたい。
 ネットワーク（主にインターネット）環境の不安定な地域（中国など）に出張中や国内でも比較的速度の遅い無線ラン環境などにおいて、クラウド式のサービスは安定して使用できない場合が多いことが時々問題になる。
 データの遠隔地でのバックアップやクラウドサービスを利用したいが、価格や使い勝手などを考えると二の足を踏んでしまう。
 「ものづくり」における多目的設計問題の解決のため、多数のケースのパラメトリックス
テディが必要であり、そのための計算資源が不足している（以下の図面参照）

418

• 「ものづくり」における設計問題は複数の設計指標をもつ多目的設計最適化問
題であることが多い• 多目的設計最適化問題を解く手法として多目的進化計算が普及しつつあるが，パラメトリックスタディのケース数が設計指標の数が増えるにつれて指数関数的に増加するため，適用先が非常に制限されている• よって，ものづくりを革新するためには，多数のケースのパラメトリックスタディを効率的に行うことができる大型の計算機資源が必要とされている
設計指標数

3

4

5

6

必要ケース数

O(10K)

O(100K)

O(1,000K)

O(10,000K)

評価
1

設計
2

設計
3

設計
N

日陰時間(時間）

多目的進化計算による新設計生成

それぞれの解の設計指標値
高度20,000kmに達するまでの時間(単位:時間）419

研究データやコンテンツの共有・利活用に関して、その効果や期待、要望事項
 アルゴリズム系のベンチマークに必要となるテスト問題のライブラリやその性能評価結果のデータ等の共有ができると有り難い。
 美術史が専門で作品の写真データや文献史料のデジタルデータなどを大量に用いるが、手持ちの外付けハードディスク等に入れて持ち歩くのではなく利用できるのであれば便利だと思う。また、授業や講演会などで安全かつ迅速にデータを呼び出せるようなら活用してみたい。
 現在は学内サーバを活用している。現在の研究課題の水準では特に新たな要望や期待はない。ただ今後の研究の進展によっては要望等が出てくる可能性はある。
 主成分分析、多変量解析などが簡単で安価に行うことができる公共のシステムがあればぜひ利用したい。
 未発表の研究データ等も共同研究者とやり取りする必要性があるため，商用ではない，アカデミック専用のクラウド共有サービスを望む．
 研究者会議を web 会議で行うための共有システムが構築されるとありがたいです。
 将来的にはデータを一般公開することも考えているが，データ容量が大きいため，どのよ
うに公開するべきかを考え実施することが研究室単位では難しい．
 研究データの共有は知財の関係で困難だと思います。しかし実験方法(装置の使用方法)、
ソフトの使用方法などのノウハウの共有ができれば良いと思います。
 データベース公開の支援をしてくれるサポートサービスがあるとありがたい 学生とデータを共有しながら、ディスカッションができる。検索などによりデータの拾い出しができる。紙媒体のようにデータななくなることが少ない。
 理想的にはすべての学術論文（邦語、外語）のコンテンツを、研究者には等しくどこからでも見れるようになると、かなり研究が楽になる。大学図書館としても、小さいところは予算の大部分が、学内では読まれる頻度のそれほど多くない論文の購入予算に当てられている現状があり、学部教育との矛盾が大きくなっている。また、所属する大学の予算によって、研究者の有利不利が決まる現状も、日本全体で考えれば、あまり喜ばしい
ことではない。したがって、研究者番号を持っていれば、論文はすべて見れるという状態になって、この予算を番号をもつ人数分にしぼってまとめてとれれば、実際のところ、各大学で個別に当てている予算の総額よりも、かなり小さいものになるのではないかと予想される。この場合、大学院生など研究者番号を持っていないものの閲覧をどうするかという問題が生じるが、これに関しては、大学の予算で別箇対応するということはできないだろうか。理系と文系だと考え方に相違があるかもしれないが。"
 科研などの大学発のコンテンツは、研究者の所属機関から提供されることが多いと思います。一元的に配布する仕組みがあれば、研究者が、他機関のデータ利用も検討しやすく420

なりますし、自身の課題の成果の普及もスムーズに行えるようになると考えております。
成果公表はしたものの某大なネットワーク情報に埋もれがちになり広報が難しいという課題も、一元的に配布する仕組みを整備することで、解決に向かうのではないでしょうか。
 資料館や図書館のデジタル・アーカイブの質量の充実．また検索の容易さを希望．
 デザインに関する作業を行っています。データの遠隔保存はせずに、耐水・耐加熱金庫での保管をしています。私どもの県は海に接していませんのでそれでもいいかと。コンテ
ンツの共有利用に関しては著作権ガードをどのようにかけるかを苦慮しているところです。
 また研究機関から公開されている古代品写真画データは解像度がパソコンでの閲覧を見据えたものになっており、研究としては使いづらい荒画素です。高画質保存のものが学
術データベースとして閲覧履歴が残るシステムとして、研究者用に公開されてほしいと願っています。"
 容量の大きなデータのネットワークを介した共有が難しい 現在観測されている生態系長期観測データは，日本の研究者のみならず世界中の研究者が長期間（数十～数百年）にわたって利用する性質を持つが，安定したサーバ環境が確保できていない。日本生態学会の英文誌 Ecological Research では，メタデータ情報をデータペーパとして出版しているが，データ本体の管理状況については，各個人あるいは団体に依存している不安定な状況であり，改善が望まれている。
 セキュリティを厳しくするとデータ解析までにデータ取得の時間がかかり過ぎる。
 研究データの多くは漏えいしたとしても問題とならないデータではあるが、機密性の高いデータも一部存在し、それらを別領域に分けることは困難なため、プライベートネット
ワーク上でのみ、研究者同士で共有する形としている。ただし、共同研究者は、同一機関に所属するものの異なる部局のため、ネットワークセグメントを別にする必要があり、データにアクセスするためには VPN 等を利用する必要があるが、1 つのデータが数 GBと大きいものも多いため、セグメントをまたいだデータ共有はあまり便利ではなく、結果的に常時共有できる環境とはできていない。安全で高速なネットワークによるデータ共有を行えれば、より円滑な研究の実施が期待される。
 全国的・世界的な共同研究が盛んになっているので、参画メンバーのＩＴレベルが一緒であれば、データ・ファイルのクラウドでの共有は研究促進に効果があると思う。
 クローズドの環境でデータを共有できるのは便利。また、高性能 WS をローカルから使用できるのも便利と思うが、やったことがないのでピンと来ないのが正直な感想。
 研究成果の共有に関しては大学の repository のみならず、日本学術振興会、文部科学省などの組織の中で共有 system を構築するべき。
 逆に一元管理することによるリスクがあるように感じます．そのサーバがサイバー攻撃に会うと多くの貴重な研究データが台無しになってしまうのでは？
421

 GoogleDrive や DropBox などよく利用しているのですが，セキュリティの面で不安がある．同様のサービスを信頼のおける日本の公的機関が無料で実施してくれるなら喜んで使用したい．
 アカデミックで閉じたサービスが提供されても、機関外との共同研究には使いづらい。パブリッククラウドをアカデミックで契約すべきである。
 論文等のグラフの元データが、引用・二次利用できる形で提供されると便利。
 プロジェクト内でのデータ共有やアノテーション、その後データベースとしての公開のために、柔軟で使いやすい CMS を提供していただけると有り難いです。
 現時点でも多くのクラウドサービスを利用しているが，個人情報や研究の生データのバッ
クアップ等はできない（セキュリティ的に）．
 そのため，Dropbox レベルで簡単に利用可能でかつ個人情報等もセキュリティを確保した上で利用できるストレージサービスや計算機資源の利用を希望する．
 また，自分の研究テーマは教育に関わるものであるが，教育向け演習環境をパブリックク
ラウド上に構築するのは，まだまだ非常にコストがかかる．AWS 並に容易に利用でき
る IaaS 環境が使えることと，その IaaS 環境へのネットワークに余裕があり（複数人数が同時にアクセスするため），ストレージに余裕がある（詳細なログ情報の収集を行う
ため）状態が望ましい．"
 クラウド上で計算したデータのうち，指定したものを他大学や企業の研究者にそのまま（できれば長期間にわたって）提供できるような仕組みがあるとうれしい．
 利用者にはサービスだけが見えるように、情報基盤をインフラ化してほしい。
 研究成果公開において商用クラウドを利用すると、従量サービスのため人気が出れば出るほど破産するという構造になる。研究本来のインセンティブは人気が出れば出るほど評価が上がるというものであり、人気に比例して収入が増えない研究成果公開に適した制度設計ができるとありがたい。
 他研究者との情報共有利便性の向上・検索能力の向上・重複ファイルなどの発見など不要
ファイルの管理のしやすさ
 "容量、転送速度の制限がなくなれば、ビデオ画像を増やすことができる。
 現在はファイルサーバとしてしか使っていないが、計算もサーバで可能となれば、それに対応した形に発展させたい。"
 経済学で必要とされるデータベースは商業利用を前提としたもので、研究者個人で負担するには非常に高いものとなっている。ある程度共通して使うデータは共同購入してアカ
デミック専用で安い負担できるようにしてもらうと非常にありがたい。
 必要なデータを、見知らぬ研究者同士でも、連絡を取り合ってシェアできるシステムがあれば研究が発展すると思います。
 データの安全で、かつ迅速な共有は、研究の推進に大変重要です。
 自分のデータは自分で管理すべき422

 遠隔的にデータアクセスでき、ファイル共有・同期されることから研究効率が飛躍的に上昇すると思われる。
 研究が始まったらすぐに使える計算機環境があるとよい 個人の研究のため必要ないが、今後は共同研究者との交流も予想されるため、
 安全でわかりやすい操作であれば、研究にも役立つと思う" 情報セキュリティの観点から，学生が研究で使うパソコンは，個人所有のものではなく大学としてそろえたいが，予算的に厳しい．
 Dropbox を使用している。他の研究者と共有しているフォルダ内のファイルを編集する
際、同時に他者が編集している場合に気が付くことができない。その結果、競合するコ
ピーが生成されてしまう。誰かが編集中のファイルにはアクセス制限をかけられるようにしたい。
 個人情報（医療情報含む）を保管し、特定目的での利用が可能となるシステム（クラウド含む）が構築されると良いと考える。
 画像データなどは大容量なものが多いので、共同研究者間で双方向にアクセスできるようなクラウド環境のようなものができれば、将来的には利用したいと思います。
 他の研究者とのセキュアなデータ共有(https 接続)による読み書きができること。
 新規な共同研究の開拓に繋がるような、データーベース（あるいはシステム）があれば嬉しい 文献管理や統計解析などの研究支援プログラムが安価で利用できれば利用したい。
 研究者情報や研究成果にアクセスできるデータベースを構築してほしい。"
 アンケート調査や聞き取り調査のデータを長期に安全に保存することができると嬉しいです。
 分野的に、都市空間の３次元情報データが必要ですが、今のところ主要都市の主要市街地
しか民間での詳細データ提供はされていません。もし様々な研究機関でそれぞれ整備された３次元データ等が提供されて相互利用できるなら、ずいぶんと利活用が広まるように思います。
 安価（可能であれば無料）で，且つ高い暗号化の技術により完全な外部漏洩対策が施された信頼性の高い接続方式が確立された場合は，クラウドサービスもより一般的に使用できるようになるかと期待しています．
 研究データとして、特に文献資料などがもう少し安価に手に入るといい。研究資源として、安価に利用できるデータベースやそれらの検索システムを充実させて欲しい。
 アカデミッククラウドには研究もさることながら、管理運営教育等のサービスへの利用や、SaaS による共同利用や共同管理が望まれる。
 各種の分析において、色彩を活用した結果の表示が必須の状況が生じたり、理解を助ける役割も大きいこともあり、一般的になってきている。
 研究分野によって偏りがあると思われるが……、紙ベースの時代を引きずって単にデジタ
423ル化することから脱却し、色彩も自由なデジタルの環境で研究データやコンテンツにアクセスできるようになってほしい。また、目的とするコンテンツ等に、簡便かつ適切に到達できる検索システムの更なる発展に期待したい。"
 研究成果は研究期間終了後も長期に利用したいので、科研費の研究期間が終っても継続的に利用できる仕組みが不可欠。
 研究データやコンテンツの共有環境が整備されれば、研究や教育の現場における業務の効率化や発展が期待される。
 セキュリティが確保されれば使用したい コストダウン、研究の効率化の両面から必要だと思います。
 お互いに Win-Win になるような提供、利用が出来れば続くと期待される。
 いずれにしても「安心」の元でのみ、研究計画の完全遂行が可能になると確信する。研究者が培ってきた「専門性」をその「専門分野」で存分に発揮できる環境を切に要望します。
 収集データに個人情報を含むのでその取扱いが難しいが、データ自身の共有は有効だと考えている。
 一つのファイルを同時に複数の研究者が編集できると良いと思う。
 研究者間のデータの共有化は、もっと進める必要がある。研究室全体としてデータのバッ
クアップにも取り組みたい。
 ある同じ研究テーマで、そのデータに関して共同利用できれば有意義だと考えます。
 自分の取り扱ったデータが見ず知らずの研究者に利用されることには、心理的に不快感が残る。ただし、研究開始前から役割を明確に分担した研究者同士が共同利用するのは必然のことであるから、そのためのサーバ構築などを公的機関がバックアップしていただ
けると助かります。
 他者による研究データ等の共有・利活用は、データに直接責任を持つ研究者の学会発表や論文などによる公表後に、発表の引用によって進めることが基本になると存じます。
 数年までは出身大学のサーバを利用できたりして，バックアップに有用だったが，ここ数年はセキュリティ上アカウントを持てなくなった．もし，オフィシャルな外部サーバを利用できればバックアップには有用と思う．
 本課題は単独で実施しているので，それほど必要性を感じませんが，一般論として共同研
究者と素データを安全に共有するための手段の確保は重要と思います。民間のサービス
ではなく，もう少し公的なものが欲しいとは感じています。
 セキュリティが確保されないと活用しにくいと考えている。
 多くの研究者が参考にしている論文の情報やデータ、モデル図、模式図などは共有できたほうがいい。新規性の高いデータについては、クラウドを使わない方が(使うとしても物理的な制限をかけたほうが)いいとおもう。
 とても重要なこととして、共有・利活用が加速されることが期待される。
424 シミュレーションデータなどを持ち運ぶことなく, どこからでもアクセスできたり, グ
ループメンバーで共有できると効率が上がることは間違いない．
 バイオインフォマティクス関連他のソフトウェアを安全に、また公的にクラウド利用でき
ればありがたい。
 共同研究などにおけるデータのやりとりがスムーズになることに期待しています。大きなデータの解析が高速でできるようになると助かります。
 現在は特にデータやコンテンツを共有していないが、共同研究などで必要な場合は是非利用したい。
 国際学術雑誌等の閲覧システムを国家の方で一括化できれば助かります。とくに、地方大学では、電子ジャーナルの閲覧に限界を感じます。
 データ形式によらない共有
 学内外の研究分担者との情報共有のために、大容量のバックアップ、クラウドサービスがあれば便利である。
 データやコンテンツの共有・利活用は重要。ただし、著作権、セキュリティは確保すべき。
 研究データの共有・利活用（公開）は考えていない。（必要性が無い。
）
 研究グループ毎に閉じたデータの共有が必須。ローカルに存在するデータと区別がつかな
いほどの転送速度が必須。バーチャル PC のホスティングシステムが存在していればありがたい。
 コンテンツの共有・利活用に資する情報を研究者登録者に配信して欲しい．例えば NICB
が生物系の多くの情報のハブとなっているような機構があると便利である．
 研究データの共有・利活用というのは、(1)他研究機関の共同研究者とのデータの共有(現在はメールへの添付などで対応)、(2)一般市民への情報の公開のどちらがメインでしょうか？おそらく(1)だと思いますが、今では海外の研究者とのやり取りもありますので、システムの構築時には少なくとも表示言語の多言語化(英語、中国語など)が望ましいと思われます。また、民間のクラウドサービスのようにローカルとの同期をとる形式で、データの転送を行うとすると、データ転送速度がボトルネックになって使い勝手が悪くならないよう余裕が求められる。
 データ転送のスピード，バックアップに数日を要するため。
 アカデミッククラウドのシステムが統計解析ソフトや DNA などの配列情報処理ソフトが共有できれば助かります。
 研究データのバックアップの場として利用できれば便利だと思いますが、未公表の研究データは論文や学会で発表するまでは秘密にすべきものなので、バックアップを外部のシステムに保存するに当たっては不安があります。"
 簡単に情報公開できるシステムがあると助かる。
 日本語の文献、研究情報のデータベース構築や利用システムの形成が他言語（英語、中国語、韓国語）に比して大変遅れているため、日本語の人文学の研究が衰退する危機感を425

持っています。
 一般論ですが、縦断データや政府機関等による調査データなど、公共性・公開利点の高い
データは共同利用できるシステムが、日本でも増えることが必要と感じております。
 研究室内で卒研生グループでデータを共有、蓄積（自動バックアップ有り）できる使い勝
手の良いストレージサービスがあれば利用したい。
 クラウドも将来の可能性、選択肢として考慮する
 画像ファイルの共有については著作権の問題があり限定がされているので、広く研究を公開したり、データベースを共有することが難しい。共有できるようにするためには、史料利用の費用に対して、補助がなければとても無理である。
 研究に限定せず，また，サイズの大きさにも関係なく，大学で生産されたあらゆるデータ
やコンテンツは，可能な限り，学内外で共有されることが望ましい。
 論文・図書などの電子化した情報、研究データなどを研究者限定で共有できるクラウドサービス。
 あるいは、科学研究費などのグループに特化して期間内＋１・２年使用できる公的クラウ
ドサービスなど。
 大容量記憶域とその共有、メールなどの同報サービスを含めたグループウェア
 文科省が研究グループ毎にクラウドサービスを構築してくれれば，ファイル共有が円滑に進み，研究効率が上がり，大変ありがたい．
 海外を含め共同研究を進めやすくなる。
 無制限なデータの流通は研究成果が誤用されるリスクを伴う。データ活用についてのガイ
ドラインなどをいかに構築していくかが課題と考える。
 それほどデータを共有する必要がない。
 研究対象としているトランスポーター分子に関する in vitro, in vivo 情報のまとめられた
データベースの共有が可能であれば、非常に研究を円滑に進められる可能性がある。
 研究速度の向上
 一カ所にデータを保存することで，データの共有が可能になり，データそのものを活用する機会が増えると思います．
 複数の研究者による個別研究データのメタ分析を行う際などには非常に便利で有効と考える。
 修学データの分析可視化を研究しておりますが、各大学等で蓄積されているそれらのデー
タを集約してビックデータとして大規模に解析することができれば、興味深い研究が可能ではないかと考えております。
 あくまでも私的に利用し処理するので共有は考えていない。
 共有し，成果の発表の場になれば良いと思います．
 セキュリティ性が高く，大容量の共用が可能であれば利用したい．
 特定のグループの中で安全にデータ共有できる仕組みが必要とされていると思う426

 近年臨床データの取得が非常に難しくなっているので，個人情報を含まないデータについては，安全性が確保されたうえで，できるだけ公開できる環境が整うのが望ましい．もしそのようなデータベースができれば，研究が飛躍的に進展すると考えられる．
 回線の問題は、大学内のことなので申し上げてもしょうがないことですが、現状ではできることに限界があります。
 シーケンスデータをクラウドに保存するだけでなく、解析もクラウドで出来るようになると有用だと思う 写真や映像や音声などの共有可能な情報は，学術用として一カ所にまとまめられるようにしてほしい（立命館大学アートリサーチセンターなどがやっているようなデータベース
システムなど．
．
．
） 海外出張時に、計算した raw data にアクセスしたいことがあるが、現在、自前のサーバはセキュリティの問題のため、外部からのアクセスを一切遮断している。セキュアなク
ラウドサービス等により、データがオンラインで参照できるのであれば、非常にありがたい。
 データ処理のため外部からは接続できないサーバにはデータを置くが、有料使用権契約のデータがあるので、外部にからの攻撃にさらされるシステムには置きたくない。
 実データの利用
 研究データにはこれまでの運用ログが含まれており，データを消失すると，これまでの利用統計などが分析できなくなるため，データのバックアップを自動的に実施してもらいたい．
 例えば研究機関が所蔵し、電子化した古文書などの資料を、研究者のグループ内部で自由にアクセスできるシステムやそのためのルール作りがなされれば、資料の活用の幅が飛躍的に広がるのではないかと期待しています。
 先行研究のデータの詳細を閲覧することや、統計的な処理の手続きが参考にできれば便利だと感じます。
 課題ごとに共有範囲が異なるため，そうした設定が可能でクラウドで共有できるサービス
がほしい。

427

アカデミッククラウドに対する期待や要望事項について
 できる限り安価で高性能な計算資源を自由に使える環境の整備が必要である。
 そのようなシステムやサービスを提供する事で、研究室レベルで高価なクラスタを購入する必要がなくなり、これまで基盤 B ぐらいでないとできなかった研究が、基盤 C でも可能となることが期待できる。これにより日本全体での研究費の大幅な効率化に資する事が期待される。
 全ての分野を網羅するようなものが出来れば、素晴らしいが、少々非現実的な気もする。
 主成分分析、多変量解析、アンケート解析などが簡単で安価に行うことができる公共のシステムがあればぜひ利用したい。
 暗号化などの機密性，安定性．
 使用料金によりますが、利用してみたいと思います。高いセキュリティを備え、機密性の高いデータの退避先に使用できることを希望します。
 データバックアップの容量増加。安全性。
 iCloud や Dropbox のようなクラウド環境が、データのバックアップのために無償提供していただければありがたいです。
 セキュリティの高さ（不特定多数がダウンロードできないような確かな仕組みと保証）
 科研費の取得の有無を問わず，長期間にわたってデータを保管できるような配慮が必要である．
 文科省、厚労省、経産省の出している各種ガイドラインに合致しており、このインフラを適切に利用している限りにおいては、機微な個人情報を含むデータの処理については一定の保護がついている、といったような研究者が安心して使えるインフラを提供して頂く価値があると思う。そうでなければ、対費用効果の高い Amazon などの民間 SaaS 等
で十分。
 データベースやリソースに対して検索性が高く，アクセスが容易であれば使うようになると思う．
 バックアップシステムとしてのクラウドが構築されれば助かります。
 決まった領域でのセキュリティの高さが必要。
 ハッキングや入り込まれた際にアラートでわかるような仕組みが必要。"
 科研費などで支出できること。システム管理者（他の研究者）から閲覧できないように，こちら側で暗号化してから送信する仕組みの整備。
 セキュリティの問題。使いやすい専用ブラウザがあるとなお良い。
 率直に、現時点では計算処理に対する期待はございません。大容量ストレージとしての期待が大きく、セキュリティ対策、バックアップ業務を安心してクラウド側に任せられる程度に環境が整い、数年運用してみた時点で、初めて、計算処理に対する要求や希望が428

明確になっていくものと考えております。
 大学の情報部が，IMAP と NAS を導入管理して頂きたい．電算は，研究そのものが大した計算ではないので不必要．
 信頼できるクラウドサービスが提供されれば，バックアップやデータの共有などにかかる
手間・資源を大幅に削減でき，作業の効率化とデータの共有化による生産性向上をはかることができると期待しています．資源量としては 100GB 程度が欲しいですが，有効に活用するためには通信速度の向上は欠かせないでしょう．
 我々の実験の立場からであると、バックアップ用のディスクが欲しい。
 1 PB レベルまで到達する量なので、この量を保存可能で、転送のための回線があれば有意義となる。
 ただし、実験データは専門的で、共有して意味のある物ではなく、あくまでバックアップの目的となる。
 アカデミッククラウドとは何か、というところから、実際の使い方までサポートがあれば、活用してみようという方が増えると思います。
 アカデミック向けの無料ストレージ、データ共有サービスがあると良い 専門的な知識無しに扱えるもの。最低でも１０GB 程度のスペースが提供されると、他機関の共同研究者とのデータ共有に便利。海外にも共同研究者がおり、海外調査も頻繁に行うので、国外からでも国内と同様にアクセスできること。
 レスポンスを高速になるとありがたいです パブリッククラウドしか試していないが，MySQL サーバへのクエリに対するレスポンス
が数秒かかる場合があります" 現在は患者データを病院外に持ち出すことはできない。そうすると病院内で研究を行うか、データを暗号化して自宅に持ち帰る必要がある。この問題を新システムで解決できないか。
 十分な計算速度や通信速度が確保でき、かつ安全な利用環境とできるのであれば、継続的な研究遂行のためにも、できるだけクラウド環境を利用したい。
 先日もＪＳＴで申請書が外部公開されるトラブルがあったが、未発表データの流出は致命的なので、セキュリティが心配。もし、大学の入試情報（作成中の入試問題など）を取り扱えるくらいのセキュリティがあれば、ぜひ利用したい。
 大容量（10GB～）のクラウドストレージの無償供与
 最近まで運用されていた MyOpenArchive（http://myopenarchive.org/）に相当するような、研究者自身がスムーズに成果公開でき、かつ、Google などにも検索されやすい（例：OAI-PMH 対応）システムができないだろうか。
 セキュリティポリシーの遵守ができるようなシステムが望ましい．
 十分なセキュリティ
 使用資格が気になる。科研を受給していない間でも使えるといい。おそらく利点は研究機
429

関を移っても使える点だろう。データを蓄積するサブの場所として期待したい。
 GoogleDrive や DropBox などと同じユーザインタフェース機能 アカデミッククラウドを各機関ごとに用意するのは無駄である。また、日本国内に閉じたシステムを用意されても共同研究には使えない。広く世界的に使われているパブリック
クラウドがベースとなるべきである。
 抽象的な表現ですが，ある方面の方々のためのクラウドであるならば，コラボレーションが促進されるような仕掛けがあるべきだとは思います．そうでなければ，民間のクラウドと差別化できないと考えます．田舎の大学の人間としては，そういうものを利用するための基盤を整備する方が先ではないかという気がします．
 データの散逸を避けるため恒久的保存に利用したい。
 研究者間のデータ交換に利用できるとよい。"
 少なくとも 10 年以上は安定して公開できる web サイトが望ましい。
 現時点でも多くのクラウドサービスを利用しているが，個人情報や研究の生データのバッ
クアップ等はできない（セキュリティ的に）．
 そのため，Dropbox レベルで簡単に利用可能でかつ個人情報等もセキュリティを確保した上で利用できるストレージサービスや計算機資源の利用を希望する．
 また，自分の研究テーマは教育に関わるものであるが，教育向け演習環境をパブリックク
ラウド上に構築するのは，まだまだ非常にコストがかかる．AWS 並に容易に利用でき
る IaaS 環境が使えることと，その IaaS 環境へのネットワークに余裕があり（複数人数が同時にアクセスするため），ストレージに余裕がある（詳細なログ情報の収集を行う
ため）状態が望ましい．"
 自分の研究テーマや興味ある分野から考えると、アカデミッククラウドと呼ばれるものには特に関心がありません。参考にならずすみません。
 並列/分散計算の特定のフレームワークに限定したもので良いので，基本設定がなされた計算ノードが提供されるなど，利用時の設定の手間がかからないものにしてほしい．
 定常運用を研究室サーバで行い、非定常運用をクラウドで行うというハイブリッド運用ができれば、研究室設備を抑えられるためメリットが大きい。一方、すべてをクラウド上に構築すると、研究費の切れ目が研究の終了につながってしまうリスクが大きい。この点に関する対応が望まれる。
 公開している内容では、１０００ノード程度の並列計算が使えると、シミュレーション計
算をリアルタイムにすることが可能となる。
 主記憶 256GB、ストレージ 10TB、32 コア程度のリソースを自由に使える環境が容易に得られれば大変助かる。
 安く利用できること
 調査研究ありがとうございます。
 外部研究者とデータ共有が簡単・廉価にできるサービスを望みます。現状では「Dropbox」
430

が使いやすいですが、6 名で共有すると高価になってしまいます。容量は 50G バイト程度がいいです。"
 データ転送速度が外付けハードディスクより遅いならメリットはあまりない。
 自組織の計算資源とアカデミッククラウドの計算資源間を高速かつセキュアに接続してハイブリッドクラウドを手軽にかつ安価に構築できるサービスがあれば利用したい．
 通常は研究室の PC で十分だが，色々な実験条件で走らせる場合，研究室の PC 台数以上の PC が必要になることがある．このような時にクラウドコンピューティングを利用したいが，応用ソフト（Matlab など）の場合ライセンス数の関係で利用できないことが多い．この点が解決されれば利用機会はぐっと増えると思う．
 露中韓モンゴルなどの東北アジア地域の研究機関から日本のアカデミッククラウドにアクセスして、出張時大容量データを共同利用可能にしたい。メモリを持ち運ぶのは不安である。
 大容量であれば、ファイル共有・同期サービスだけでも便利。
 スパコンを用いた数値計算等は私には無縁だが、将来的に使用する可能性も否定出来ないため、事業を進めて欲しい。
 大学をまたがる共同研究で便利に使える環境があるとよい クラウドを利用するとすれば、高速通信が前提となります。
 動画を研究に使用し，必要なデータ量が多く大変ではあるが，十分な容量を確保できれば心強い．
 現状のクラウドストレージは研究費からの支払いが難しいので，その活用も困難である．
研究費からの支払いが容易になれば，有料でも活用したい．
 現状，大災害への備えはできておらず，データ損失の恐れがあるため，分散して保管できる試みがあれば，ぜひ利用させて頂きたい．"
 安全なバックアップシステムの構築を期待します。
 そもそもアカデミッククラウドを公共機関が公費を投じて構築する必要は無いと考える。
頓挫は目に見えており、民業圧迫でもある。むしろオープンデータの推進と研究費の増額をこそ考えるべきであろう。
 セキュリティを最も重要視する。
 研究者や学生の個人負担とならないようにして，データ処理やデータの共有，管理がスムーズにできるクラウドシステムが欲しい．
 可能であれば、将来是非利用したい。
 データベース科研費では入力費用しか使えないので、維持管理への支出が不可能。データ
ベースのためのクラウドサービスがあったら構築の費用で支出できると思われるので、是非使いたい。
 既存のシステム（Google 等）に頼らない、国内独自のシステム構築を求める。
 個人情報を格納出来る、認証された人・機関が特定の目的で利用出来る仕組み
431

 個人 ID 番号の突合の上手な仕組み。
（国民背番号を使わない）
 情報レベル設定（公表、共有、専用、秘密等）"
 acrobat connect のような多地点ウェブベースの遠隔会議システムを備え、
 google docs のようにオンライン同時編集ができ、参加者は簡単なウェブ上のアンケートに応えるだけで会議の自動スケジューリングができ、
 ファイルサービスはこれらと連携していると望ましい。"
 一般的な統計解析（PCA 解析、簡単な多変量解析）、遺伝子統計、疫学統計などのソフト
ウェアが、研究機関の共有クラウド空間にあると大変ありがたいと思います。
 パブリッククラウドより安価でセキュリティやバックアップなどのサービスは同等であることが望まれる。
 Cinii や科研費のサイトの異常な使いにくさを考えた時に、日本の役所がらみのサービスには全く期待できないのは明らかだと思います。セキュリティ上の不安を差し引いても、
Dropbox や Evernote 等、外資系の民間クラウドサービスをの圧倒的な使いやすさは素晴らしいと思います。安全でかつ使いやすいアカデミッククラウドがあれば良いと思いますが、使いやすさという点では、日本発のサービスには、残念ながら、全く期待していません。（研究用ではありませんが、本学で学生用に導入されているマナバフォリオなども、ひどいものです。
）結局のところ、裁量権を持っているお年寄りの方々が IT 全
般に関心がなく、実際の利用者のことを全く考えていないというのが一番の問題のように思います。しかし、この高齢少子化の時代に、一体どうやってこの難問を解決すれば良いのかというのは私には分かりません。
 安全性の高い、ストレージを希望します。
 検索等，使い勝手のいいファイル管理システムが導入されていると，データのバックアップや共有に使いたくなります．
 本取り組みについて多くは知りませんが，単なるデータの処理やファイルサーバなどだけではなく，様々な研究者が情報共有や意見交換をしたり，共同研究をその中で募集するなどの仕組みができてくるとおもしろいかと思います．あと，研究補助の募集なども一括して取り扱うことができる研究者用の国家公認の総合サービスとして構築されますと，研究を潤滑に進める一つの仕組みになるのかと妄想します．ただ，研究課題が盗まれる危険性がありますので，色々と考慮する必要はあるかと思います．
 パブリッククラウドを利用しているがサービスの継続性について不安がある。アカデミッ
ククラウドサービスには継続性を期待している。
 クラウドサービスを利用した計算，クラウドを経由した情報公開 データ転送の高速化
 共同開発や共同研究を是非推進して欲しい。
 科研費の採択期間に限定せず、科研が取れなかった年も継続的に利用できるようにして頂きたいです。また、科研費取得の実績のない研究者や研究チームにも利用できるように、
432

それによって、次年度の科研費取得を目指して遠隔地の研究者が互いにデータを交換したり蓄積したりできるようになると助かります。
 国際共同研究においては、それぞれの国で独自の計算機資源を使いたいという要望が出てくることがあり、その場合異なる計算機施設で同じ計算機環境を構築する必要が生じる。
そのため、計算機の仮想化（VPS）などによって、OS、コンパイラ、ライブラリのバー
ジョン等、ユーザが出来る限り自由に環境を構築できるようにして欲しい。
 国際共同研究においては、それぞれの国で独自の計算機資源を使いたいという要望が出てくることがあり、その場合異なる計算機施設で同じ計算機環境を構築する必要が生じる。
そのため、計算機の仮想化（VPS）などによって、OS、コンパイラ、ライブラリのバー
ジョン等、ユーザが出来る限り自由に環境を構築できるようにして欲しい。
 日々、様々なデータが蓄積されていくので、容量的にもセキュリティの面でも安心して常時バックアップできるストレージを確保したい。
 その際、通信の安定性と充分な速度が必要となる。"
 利便性＋セキュリティ
 研究データやコンテンツの共有環境を伴うアカデミッククラウド環境が整備されれば、研究活動や教育活動における効率化や多角的な発展が期待される。
 そもそもアカデミッククラウドとな何ですか？大学等限定の google ドライブのようなス
トレージサービス？" セキュリティが確保されれば使用したい 大きなデータであってもストレスの掛からない転送速度
 研究情報の保管処理・管理責任等に煩わされず、収集した情報を活用し尽すことにのみ専念できる環境を期待しています。
 データ保持に関しては高い信頼性と十分な要領、出張先からのアクセスの利便性、さらに情報漏えいに対する防護 上記のファイル共有に含め、データのバックアップにも使えるようなクラウドシステムに対する潜在的なリクエストがあります。
 大切な情報ほど、手元だけに置いておきたいと思っています。現時点では、アカデミック
クラウドを全く使用したくありません。将来の発展具合によっては、考え方を改める可能性はありますが。
 アカデミッククラウドについては期待するが、やはり扱うデータへのセキュリティに不安がある。その点が問題なければぜひ使用したい。
 基本的には既存のクラウドサービスで十分であるが、要望としては「セキュリティ」「大容量（100GB 程度）」「高速化」に特化した機能を持つアカデミッククラウドがあれば、導入を検討したい。
 大いに期待したいが、所管する施設・研究所が大きく占有して、外部利用者には一部しか開放しないようであれば、作る意味が薄い。
433

 無秩序な利用を避けるためにも、利用登録と共に、安価で良いので、多少なりと利用料を課したほうが良い。
 セキュリティのため、ＵＳＢなどの持ち運びに注意しているが、クラウドサービスが向上
し、どこでもデータにアクセスできるようになると助かる。
 今のところ必要としていない 安全，安心で費用がかからない（少なく済む）サービスがあれば利用したい。
 使用者に負担のかかるシステムを強制されることの無いようにしてほしい．
 新たにアカデミッククラウドを構築する必要はない．民間で提供されているものを個々の研究者が利用すればよい．
 研究期間内に限定せず，日本の研究機関に所属する限り継続して同じ環境を使用し続けられるクラウドで無ければ意味が無い．
 Dropbox のようなソフトは非常に良いですが、セキュリティはもっと高いクラウドがほしいです。
 データ保存容量が可変的に変化させられるようになっているとデータ量を心配する必要がなくなるので、利用しやすい。
 セキュリティの高さは通常以上のものを要求されると思います。情報の漏洩は、個人情報保護の観点だけでなく、研究の独創性や新規性の上でもあってはならないと考えています。そうした点がクリアできなければ、アカデミッククラウドを利用することを前向きに検討できないと感じています。
 今後、必要になるかも知れません。
 汎用性
 ドロップボックスの大容量板があれば便利 研究者間での共有はし易いであろうが、情報管理の問題など気になる skydrive のようなクラウドサービスを大学内の枠内でおさえることができると研究デー
タを外部に置く必要がなくなるのでぜひ利用したい．
 科研費での研究を行い、そのデータをクラウド上で保存した場合、科研費の獲得が終了しても一定期間アクセスできること、或いは、先にのべましたが、画像処理、統計処理等の最新のソフトをクラウド上で使用できればと考えます。
 アクセスに対するセキュリティの柔軟性がなければ、利用しづらいものとなる。
 B/C を十分に検討いただきたい．
 研究室の学生、教員とで共用できる、アカデミッククラウド（特にデータストレージ機能）があればありがたい。現在は、民間の有料デジタルアーカイブサービスを利用。
 クラウドとサーバとの違いが明確にされてないような気がする．個人的には，クラウドコ
ンピューティングとしての利用はしていない．外部サーバなら，バックアップシステム
として利用するかもしれない．その場合には，バッチ処理のできるシステムで，計算処理よりも，ネットワークの速さ，十分な記憶容量（1TB）ぐらいあれば利用したい．
434

 将来，他大学に異動する場合においても，データをそのまま使えるようになっていると有難いです．
 ワープロ、画像処理、画像解析、プレゼンテーションソフトを無料で使用できるシステム
であれば大変有用である。
 雑多な内容・形態のデータを扱うことが予想されるので、セキュリティの設定を内容に応じていくつかのレベルに分けて設定できるようにしてほしい。
 どの程度セキュリティが保障されるのかが、不安。
 クラウドとともにネットワークの安定化も重要だと思う。
 セキュリティの高い情報でも利用でき、豊富で高機能の計算・データ処理のできるクラウ
ドサービスがあればと思っています。（高度で使いやすい遺伝子解析ソフトなど）
 日本のサイエンスのレベル向上につながることを期待しています。また、特許などの知的財産も守られ、産業界にも貢献できると素晴らしいと思います。
 メンテナンス人員のスキルの確保が大変重要かと思います．．いい加減な管理者によるいい加減な管理が行われるサーバ・サービスは，使えないです．
 アカデミッククラウドサービスというのがどのようなものか分かりません。専門的なデー
タ処理などを必要としない学問領域の人にも分かりやすい説明がほしいです。
 CPU 資源についてはシステムの性能向上が早く、短期間で陳腐化する可能性がある。
CPU が常に更新されているようなクラウド的なものがあるとよいかも知れないが、継続して利用出来るような料金設定でない限り利用は困難。
 セキュリティ，信頼性の高いバックアップ，クラウドサービスが有れば利用したい。
 10 GB 以上でセキュリティがある程度確保されていれば使いたい セキュリティ面が信頼できるようになると、もう少し活用の幅が広がり、遠隔地の研究者とネットワークを介して情報交換や分析についてのディスカッションが可能になると考えます。
 著作権の監視システムを運用する事が必須。
 今あえてアカデミック向けとしてクラウドサービスが提供されるのであれば、確かな証拠能力のある「研究ノートの電子化」（研究データの保全・を担えるシステムを期待した
い。また、情報漏洩を防止する、高度に暗号化された（管理者でもデータの内容までは閲覧できないような）ファイルシステムを期待したい。
 自由にグループの共有サーバを作成できる。自由にグループの共有バーチャル PC を配置できる。それらのセキュリティが保障される。それらの継続性が保障される。
 些細な内容であっても，共同研究者を見つけられる多方向の環境があるとよいと思う．ただ，セキュリティや個人情報・知的財産権の問題が生じるので，現実的かどうかはわからない．
 大学であれば、各部局でコンテンツの公開によって研究データの公開が行われていると思われるが、運用のリスク(不法侵入など)とコストなどで不安がある。アカデミッククラ435

ウドで、専門家が集中的に管理運用することで、ネットの外部からの攻撃など右側の事態に対して適切な防御を期待することができる。また、当然トラブルがあってもダウン
タイムは最小であることが期待される。
 あると便利なように思いますが、今のところ具体的にはわかりません。
 未発表の研究データが外部から保護でき、共同研究者からはパスワードなどでアクセスできるようになること
 比較的多方面で利用されるような例えば統計解析ソフトなどの共同利用ができるようになること"
 多言語環境で使用できること。特殊な言語でもファイル名等が文字化けしないこと。
 遺伝情報に関しては様々なクラウドサービスが既にあるが、ネットワークの速度が問題で、より早いアカデミッククラウド等専用ネットワークの構築が望まれる。
 私のような小規模のデータ管理のためには、Dropbox のような安価で効率的なサービス
は、正直なところ大学に期待できないと思っている。
 アカデミッククラウドがあればありがたいが、大学または研究機関からのみアクセス可能
では使いにくい。個人のパソコンからアクセスできるようでなければならない。
 セキュリティの確保は必須と考える。また、日本の法的規制が及ぶ運営形態であることが求められると思う。Google などのサービスを利用している研究者が多いが、米企業であり、日本の裁判所命令等が及ばないことがある。"
 是非研究用クラウドを構築下さい 日本語のすべての論文が所蔵されていて、自由にアクセスできる、データベースの構築が早急に望まれます。
 小中学校で小中学生が回答できるシステムで、web をつかった調査を頻繁に安全にできるとありがたいです。
 用途に応じて適切な資源が柔軟に提供されることを期待。
 セキュリティの絶対的強化と、ユビキタスな利用環境の構築
 セキュリティ、アクセスの安定化。
 HPCI とアカデミッククラウドとの違いが不明瞭である。２つの異なるシステムが稼働し、特にアカデミッククラウド側はストレージが中心で計算に重きがないのであれば、利用する必要は必ずしもない。
 TB 単位のバックアップスペースを安価に提供してもらいたい。
 アカデミッククラウドには，大学に対する社会からのさまざまな期待に応えるためにも，今日の大学の多様性を包含しつつ，個別の大学が独自性を発揮するための基盤環境となることが望まれる。
 研究の進展に応じて、また、実験規模の大きさに応じて、柔軟に計算資源を増減できるとともに、そのための利用手続きおよび初期設定のコストが十分小さくなることを期待します。
436

 課題ごとに，研究者 1 人あたり，ストレージが 10GB あれば，大変に助かる．
 使用できるようになるための説明会を開催してほしい。
 日本の大学は計算機を管理する技術スタッフがいない。これは欧米の研究機関に比べて大きく遅れている点の一つである。アカデミッククラウドがどこまでの性能を想定しているかわからないが、なんらかの共同利用計算機ができれば利用したい。しかし、従来からある共同利用機関の計算機の運用をみていると、研究分野によって必要なスペック、マシンタイム、ソフトが多岐にわたる。アカデミック一般を対象とし、かつ使い勝手のよいシステムを構築するのはかなり難しいのではないかと危惧する。
 セキュリティが万全であること。
 アカデミック用の電子メールアカウントがあると便利。これまでメールシステムの変更等
で２回ほどアドレス変更になっており，論文等に記載したメールアドレスではメール不着の可能性があるので。
 情報はある程度の根拠に基づいて絞られたものの方が好ましい サーバとして利用可能な環境があれば、バックアップおよび出先で作業を行う場合に使用したい。
 十分なセキュリティと情報漏洩時の補償対策があれば部分的に利用を検討したい セキュリティの問題が一番だと思います．個人で使用する分にはかまわないのですが，共同研究者のとデータ共有を考えた場合，特に未発表データはどこまでの閲覧を許すか微妙な線引が求められます．いくつかのプロジェクトを抱えた場合，共同研究者それぞれで異なった共有設定が必要なので，そのことを考慮できるシステムが必要ではないでしょうか．
 まだよく理解できていないが、セキュリティに問題がなければ利用したい
 災害対応による学外へのバックアップデータの保存手段として期待します。
 パソコンでは構築が難しい並列度が 128 くらいまでの MPI を使いたい。
 信頼性の保証をだれがどのように担保するか。特定業者に機関が運用を任せた場合、それは保証されない。あるいは外部に漏れないようにデータ自体の暗号化などが容易に安全に利用できるしくみも同時に提供するなど工夫が必要。心理性が保証されれば、その有用性は高いと期待しています。
 公的クラウド資源が低廉価格もしくは無料で利用できればありがたい。
 無料で使えるストレージがあれば助かります．
 大学における研究や教育において、大学間でできるだけリソースを共有できるようにしていただけるとよい。
 セキュリティの信頼性。アクセスの容易さ。
 公開が望まれる情報からセキュリティの高い情報まで，セキュリティ上，様々な学術上のデータを一個人が所有していることに配慮してほしい．
 データの改ざん、未発表研究データの盗用防止
437

 バックアップ用途としてであれば検討する価値はある。メインの環境には応答速度、安定稼働、設定自由度等が重要であり、クラウドを利用する必要性、メリットが感じられない。
 dropbox のようにローカルディスクのデータが自動的にクラウド側で同期されるようなタイプもあることが望ましい。いちいちアップロードの操作をするのではけっきょく使
わなくなりそう。
 パブリッククラウドではデータの秘匿性が保証されているか検証が困難なので、学内メー
ルなどのデータは置かないようにしている。アカデミッククラウドが秘匿性を保証してくれるのならば利用を検討する余地はある。しかし安全性のため利便性が削がれる（例
えば学外ネットワークからはアクセス不可 or 面倒）となると、メールデータのバックア
ップ以外にはあまり使いたいとは思わないだろう。クラウドは、ネットさえあればいつでもどこでもお気軽に、でないと意味がないので。
 活用方法、可能性やセキュリティなどの面で、その分野に詳しくない研究者にも安心して活用しやすくなるよう、広報や技術面の進展を期待します。
 データの損失がないこと。接続不能時間が限りなく少ないこと。情報の意図しない漏洩がないこと。十分な転送速度を有すること。（以上、使えないものであれば意味がない）。
容量については類似の民間サービスと同程度あること。
 遠隔地の共同研究者との間で大きなデータをやり取りするサービスが欲しい 学内のセキュアなネットワークから接続できるようになることが望ましいと思います。
 横断的かつシームレスに使用できるようになると良い データバックアップ，データの相互利用などに使用したい．
 絶対の欲しいのですが、上記の通り、大学内の問題があるので、ぜひ全国の大学に研究者用の回線を充実させる推奨をお願いしたいです。
 結局はネットワークの転送速度の問題が最も大きいと思われる．
 Dropbox のようなシステムだとローカルにコピー領域が必要で容量を喰う。NFS のようにファイルシステムをマウントするシステムだと、通信に不安がある。必要なファイル
はローカルに持ち、残りは随時取出すようなファイルシステムが必要。
 24 時間 365 日の稼働が保証されていれば、使用したい。
 現在、自費で Dropbox のサービス(100GB)を利用しているが、データのアップロード、
ダウンロードが非常に遅い。1TB くらいの容量を安価かつ高速で利用できれば非常にありがたい。
 メインシステムとしての利用は実績を見てからになるが、大容量（数 TB）のバックアプ
システムとしてみる場合は利用したい。
 安く！
 ハードウェアの提供だけでなく，OS のセキュリティアップデートなどプラットフォームの保守までアカデミッククラウドで実施してもらえると，対外的にサービスを提供する
438

研究では安心．
 実験用の計算資源などだけではなく，バージョン管理（subversion/git）や Wiki など，
汎用的，典型的なソフトウェアサービスを提供して欲しい．
 スポット（短時間に大量の計算リソースを使う）での利用がしやすい環境していただければ、ありがたく思います。
 物理的な移動が多い人間にとっては，クラウドは欠かせない。途上国などの出先でネットが遅いことも多いので，最低限の情報をデータ量少なくやりとりできるモードと，デー
タ量は多く高速通信が必要だが使いやすいモードと，時に応じて使い分けられるシステ
ムが望ましい。
 クラウドの必要性・利便性は承知しているつもりだが、31（前の質問への回答）に書いた理由から、クラウドへの完全移行は、非常にリスキーであると考えている。少なくともソフトウェアのサービスについては、今後ともクラウド式と従来の形式、両方でのサービスを維持してほしいと考えている。

439

B. 研究支援分野（情報サービス部署）自由記述欄のまとめシステムの運用にあたり、抱えている課題、問題点
 利用者対応増による人員不足
 運用経費（電気料金単価、サーバの使用電力量）の高騰
 むしろ、研究用ソフトウェアの充実を求められている
 メーラーで対応がほとんどなので、情報共有が難しい。ＷｅｂシステムによるＦＡＱサイトなどがクラウドで提供されるとうれしい。
 ストレージ不足、相手組織とのネットワークの維持、予算不足、人手不足
 人材確保 最先端研究特有の著しい非定型業務に対応するため、項目の追加や変更が頻繁に発生し、それに対応する必要があるが、実験装置と密接に関連し、実験遂行にも必須のため、サービス停止のタイミングがほとんどないため、運転しながらデータベースの項目や構成の変更、ワークフローの追加などができることが必要である。 セキュリティ確保のため、外部からのアクセスは、共同研究者から申請された自組織の IP アドレスに限定している。
 クラウドサーバ借用者(サーバ管理者)のスキルレベルの高低差がある。
 利用者数に対するコストパフォーマンスが悪い。
 資源量の不足・余剰。講義期間および卒論締切時には利用が多いが，それ以外は利用が少ない。予算の裏付けが無いため長期運用に不安があり，利用者が本気で使わない。
 システムの陳腐化の速度が早い バックアップ量の増大
 対外接続回線が細いこと。また，冗長性がないこと。
 利用率の向上
 プログラム相談に十分に対応できていない Windows および各種ツールに由来する細かいバグや障害，想定外の動作
 利用者間(研究者間)での情報，ノウハウの共有
 求められるスペックを有するハードウェアやソフトウェアライセンスのための予算確保が難しい 導入コストがかかる割りには利用者が少ない、しかし、利用者はよりハイスペックな性能を求めている 当設備が共同利用設備という性格上、特定の利用者のニーズに合わせたシステム設計が難しい 退職等により構成員以外となった方のファイルの整理 利用期間後のデータ削除のタイミング、利用停止作業
440

 ストレージ使用量の増加による将来的な資源不足
 費用が高い OSS による作りこみのため持続性が懸念される
 利用率が低い。
（よく利用されていた教員が退職した。）
 サーバ OS とユーザ PCOS との Ver がかけ離れているため、提供可能ソフトの Ver に制約が生じる
 ユーザの利用頻度がとても少ない 利用者の多様な要求にいかに応えるか 予算の確保が課題である
 運用費、リプレース費用を確保するのが難しい 省力化
 利用者の計算資源需要は常に供給側を上回る。限られた資源をどのようにうまく運用して最大限の研究成果を上げてもらうか。
 データが増大し、システム移行時のデータ移行に時間がかかるようになってきた。
 データ増加量の推定が容易ではないので、毎年度システムの増強を少しずつ行う必要があること。
 維持管理コストが高い ストレージ装置の容量スケーラビリティ、災害対策用遠隔ストレージ ユーザへの教育，ストレージ資源の将来的な枯渇

441

アカデミッククラウドに対する期待や要望事項、コメント
 ハードウェア資源は自組織のシステムで十分と考えるが、研究用ソフトウェアは自組織だ
けでは十分に提供できない
 純粋に研究用したばあい利用用途が絞られる。ＥＭＳや研究室ＷＥＢサーバなどへの活用も許容して頂きたい。
 SaaS、IaaS、遠隔バックアップの３点です。
 本学では高速計算機の利用ニーズがほとんどないため、費用削減のためにも費用負担がな
く（少なく）利用できるようにしていただきたい サポート、十分なネットワーク、十分な容量で高信頼性のストレージ、アクセスの容易性
 ストレージの単価が下がると利用しやすい。
 研究用途の場合，IaaS または PaaS 型のクラウドシステムの提供が望ましい。それらを利用する場合，自分の研究室にある計算機のように使えると良い。
 統合基盤を利用したアカウント情報の共通化、ジョブ管理システムのポータル化など。自組織システムに連携のための改良が必要であっても、ユーザがシームレスに利用しやすい環境を提供したい。
 低コストで利用できるもの,自大学との高速なネットワーク回線で接続できること,自大学では導入が難しい超並列（1000 以上）ジョブが実行できること,MPI や OpenMP は
もちろん,自動並列化機能があること
 計算機系アカデミッククラウドと連携し、計算結果の保存先にできること
 セキュリティの確保、保証 サービスの安定性、サービスの保証（サービスが何かの利用で、提供されなくなることがないようにして欲しい。
）
 お試し契約があるとよい 利用価格が低いこと。
 ビッグデータ解析のために一時的にも大容量の共有ストレージがあるとよい 国内にアカデミッククラウドが整備される事は望ましいが、それによって各コミュニティに配分されている固有な計算機資源およびそのための予算や人員が削減されることは全く望まれない。各コミュニティにはそれぞれ固有な計算資源配分方式があり、汎用的なアカデミッククラウドはその代替にはなり得ない。そこが削減対象となるようであればそのようなクラウドには加わらない。
 定期メンテナンスなどによるサービス停止時のバックアップサービスとしても利用してみたい 海外にある機関から利用可能であること。
 中核大学や大学共同利用機関などでは自前で対応できると思われますが、基盤センターの442

規模が小さい地方大学などからの需要は大いにあると思います。
 利用データ量が大きいので、データを移動するのがもはや現実的ではなくなってきている。
データのあるところに計算資源がないと不便。
 PB 級ストレージを商用価格や自前持ちより安価に提供すること、大規模ストレージ・ビ
ッグデータに最適設計・開発された専用アプリケーションサーバをクラウドストレー
ジ上に導入・稼働できることも必要。
 大容量のストレージと，大容量のデータを通信するための太い回線，安価な使用料金
 共同利用者のプログラム・データのバックアップ先として使えることは望ましい。大規模
データの場合の通信のバンド幅が確保できるかどうかが問題である。また認証の問題
をどのように解決するのかが課題と考える。
 様々なニーズがあがってくると思われますが、クラウドのクラス分けを極力シンプルにして、8 割方のユーザを吸収できる汎用性のあるクラウド展開がよいと思います。2 割のエキスパートユーザのクラウドは別物として扱う。コモディティとエキスパート分けされたサービスを展開することで、利用層が広がると思います。地方大学ではコモデ
ィティで手いっぱいですので、エキスパート部分を展開する優位性もあるとは思いま
すが、コモディティの充実も期待しています。
 2～3 数年で終わる可能性があるなら，現有機器の代替になりにくい。
 研究者が個人用で使えるストレージサービス（データ置き場）が欲しい。"
 アカデミッククラウドに全国的で機関間の共同研究等に資する研究支援システムの提供を期待します。
 利用料金が低廉であること。要求資源量への柔軟な対応。大学内のアカウントとの連携が容易であること。利用者サポート体制がしっかりとしていること
 クラウド型バックアップは予算が確保出来次第導入していきたいと考えている。
 大容量のストレージが電気代程度の負担で利用可能になるのであれば、それはたいへんあ
りがたいです。１Gbps 程度でのデータ書き込みができると申し分ないです。
 クラウドを構築するのであれば、恒久的な高速学術ネットワークを担保することが必須です。
 生命系はデータ量が大きいので I/O バウンドな計算が多い。それに対応して下さい。

443

資料 2.

アカデミッククラウドに関する事例調査ア) データセンターおよびクラウド連携関連
1) 大 学 間 デ ー タ セ ン タ ー 連 携 ： MGHPCC (Massachusetts Green High Performance
Computing Center),Harvard-MIT Data Center (HMDC) (アメリカ)

Massachusetts Green High-Performance Computing Center (HMDCC)
マ サ チ ュ ー セ ッ ツ 州 に お い て は 、 Massachusetts Green High-Performance
Computing Center (MGHPCC) として、Boston University, Harvard University, MIT,
Northeastern University, the University of Massachusetts の５大学による共同データセンターが 2012 年 11 月に構築されている。本データセンターはマサチュ
ーセッツ州郊外の Holyoke 市に設置され、約９万平方フィート（約 8,300 平方メー
トル）で、10MW の電力が利用できる施設となっている。本データセンターは大学のデータセンターとしては初めて LEED Platinum Certificate を取得したグリーン
データセンターであり、水冷式の冷却方式を採用する等、先端的なデータセンター
構築技術を導入した施設を整備している。
さらに、Massachusetts Open Cloud (MOC) として、地域連携にも力を入れており、民間企業や地域社会との連携や教育についても様々なプロジェクトを推進している。

MGHPCC の外観（http://www.mghpcc.org/ より）444

HGHPCC のホームページ（http://www.mghpcc.org/）

Harvard-MIT Datacenter (HMDC)Harvard-MIT Datacenter (HMDC) は Institute for Quantitative Social Science(IQSS)の一部であり、1960 年にハーバード大学における政治学および社会科学に関するデータを収集するセンターとして発足した。現在では、MIT とハーバード大学との共同データセンターとして、研究向けの計算機環境、クラスタ（クラウド）システムなどのサービスを提供するとともに、統計学に関するワークショップなども主催している。
HMDC はスパコンセンターとは異なり、計算資源については小規模のクラスタシス
テムが中心となっているが、社会科学系のデータを中心に収集、管理を行っている”The Dataverse Network Project” (http://thedata.org) など、長期間にわたって収集、保存し、研究者がデータを共有し、活用するためのインフラとして機能している点が特徴的である。

445

Harvard-MIT DataCenter (HMDC)

HMDC のホームページ（http://projects.iq.harvard.edu/hmdc）

446

The Dataverse Network のホームページ（http://thedata.org/）

2) クラウドシステムインフラ：Facebook, オープンコンピュートプロジェクト(Open
Compute Project, OCP) (アメリカ)
Facebook では、300PB 以上となる大量のデータを保存し、活用するために複数のデータセンターに分散配置されたインフラを自社で構築しており、定常的な運用に加えて、Hadoop や Hive などによるビッグデータの解析システムを活用し、新サービスの提供に向けた研究開発を推進している。
自社でのクラウドインフラ構築にあたり、そのコストパフォーマンスを最大化する
た め 、 オ ー プ ン コ ン ピ ュ ー ト プ ロ ジ ェ ク ト (Open Compute Project, OCP)
( http://www.opencompute.org/ ) を推進しており、効率的かつ経済的なクラウド
インフラを自身で構築するために必要となる技術を、オープンソースなどと同様の公開情報としてコミュニティに提供している。
公開されている情報としては、サーバ、ストレージ、ネットワークなどのハードウ
ェアに関する共通仕様だけではなく、ラックやデータセンター全体としての設計なども含まれており、クラウドシステムを構築、提供するために必要となる物理的な資源全体について、Facebook を中心とする世界全体の参加企業や個人の知見を共有している。
さらに、OCP 対応の認証に必要となる体制についても整備されつつあり、 OCP
Compliance & Interoperability (C&I) project により、その認証手続きや必要と447

される検証ソフトウェアについて検討が進められている。

Open Compute Project（左）および Open Compute Project Japan（右）の HP（ http://www.opencompute.org/ ）（ http://opencomputejapan.org/ ）3) CERN （スイス）
欧州原子核研究機構（CERN’）の IT 部門は、2011 年の後半に OpenStack の利用を開始した。その目的は、物理学の研究のためのテストベッドを構築するためにクラ
ウドコンピューティング技術の可能性を探り、CERN が求める仕様にあわせてカス
タマイズすることにあった。実際には、RedHat Linux をベースに開発されたScientific Linux を利用している。
CERN のこの取り組みの特徴を以下にまとめる。
 運用管理チームの従事者の人数が限られている。
専従は 4 名のエンジニアである。
 設備予算が年々縮小傾向にある
 CERN の設備を利用するユーザは増加傾向にあり、HPC への要求が高い
 既存ツールの保守費が高い。また、動作も不安定である
 11,000 サーバが実際に動いている ブタペストに新設したデータセンターが稼働し、サーバ数はこれまでの 2 倍におよぶ。ただし、電力不足など問題を抱えている 中長期で安定したインフラとするため、オープンソースを活用し、コミュニティ
クラウドを中核に展開する計画である
448

なお、Geneva とブタペストのデータセンターと合わせると 25,000 コアが提供されており、毎週 100 サーバ（ハイパーバイザー）が追加されている。最終的には 2015
年までに 200,000 から 300,000 コアまでを予定している。また、CERN では、44,000のユーザが ID 管理システムに登録されており、毎月 400 以上のユーザが追加ある
いは削除されていることから、ユーザ登録の自動化が大変重要と言われている。
図 10 は OpenStack を中核としたインフラの概要を表している。

図 10 CERN

クラウドの概要（https://wiki.systemsx.ch/download/attachments/75305706/academic+cloud+e
xperiences+cern+v4.pdf?version=1&modificationDate=1368607184602 より）2013 年 4 月時点では以下の仕様となっている。
 KVM と Hyper-V（Windows Server 2008）上に 500 のハイパーバイザーを実行
 Compute 、 Image Service 、 Identity 、 Dashboard の 設 定 に Puppet Labs のOpenStack モジュールを使用
 ロードバランシングを用いて高可用性を実現
 1 日あたり 75 ユーザが 50VM を新規に作成
 CMS は Essex を用いて、50,000 コアのもとで 1,300 ハイパーバイザーが稼働
 ATLAS も同様なサイズ

449

CERN は 単独でこのプロジェクトを進めず、民間企業と共同体制をとっている。実際、大きなパブリッククラウドは Rackspace や HP のようなプロバイダから提供される。Rackspace や HP といった民間企業と連携する理由は次の通りである。
 CERN が必要としている大きさ以上のサイズの Cloud を運用している
 大規模計算の問題をデバックすることができる。
 ユーザからの要求のうち 8 割は CERN 自身で対応することができるものだが、残りは CERN 自身が行うよりも、安価で利用できるパブリッククラウドでも十分なものである。ただし、個別に利用者がユーザ登録、イメージのアップロードを行うにはそれなりの手間と時間もかかる。そこで、予め主なクラウドベンダーと連携することでこの問題にも対応することができる■参考資料
 OpenStack 事例紹介
 http://www.openstack.org/user-stories/cern/ http://dream.daynight.jp/openstack/openstack-ops/content/cern.html
 Overlay opportunistic clouds in CMS/ATLAS at CERN: The CMSooooooCloud indetail, Speaker: Jose Antonio Coarasa Perez, CERN, OpenStack Summit 2013Apr
 http://www.youtube.com/watch?v=jRkTVh27XBQ
 Rackspace and CERN Partner On Hybrid Cloud Computing System http://openlab.web.cern.ch/sites/openlab.web.cern.ch/files/press-coverage/Y/M/pulse2.com%20-%20Rackspace%20and%20CERN%20Partner%20On%20Hybrid%20Cloud%20Computing%20System.pdf
 Tim Bell , Clouds at CERN, Academic Cloud Experiences, 2013
 https://wiki.systemsx.ch/download/attachments/75305706/academic+clo
ud+experiences+cern+v4.pdf?version=1&modificationDate=13686071846
024) NeCTAR（オーストラリア）
オーストラリア政府の支援のもとで、The University of Melbourne (UoM)が中心になって進められている NeCTAR は、オーストラリアの研究者を対象に、いつでもどこでも研究に必要な IT リソースにアクセスし、研究データやアプリケーション
を他の研究者と容易に共有できることを目的として、ICT を活用したインフラ構築
450

を目指している。NeCTAR は、以下の 4 プロジェクトから構成される。
 バーチャルラボラトリ：国内の研究コミュニティと技術パートナーによって構成される。2013 年 12 月現在で 11 のラボが活動している
 研究者向けソフトウェア：研究コミュニティや技術パートナーによって構築された研究用のツール。10 数種類のツールが用意されている。
 National Server

Program：セキュアで堅牢なホスティングサービス。2 箇所のデ ー タ セ ン タ ー に プ ー ル さ れ た リ ソ ー ス を 利 用 で き る 。 Citrix
CloudPlatform で構築されている。
 研究クラウド：国内 8 つのサイトで稼働する連合型クラウド。24 時間 365 日運用
し、OpenStack ベースで構築されている。1 サイトあたり 4000 コア程度の計算能力を、今後は 30,000 コアまで増やす予定である。
研究クラウドの基盤となるクラウドソフトウェアには、OpenStack の Essex バージ
ョンが採用されている。利用者は、3 ヶ月間 2 コアを利用することができ、それ以上の計算能力が必要な場合は、アロケーションリクエストをすることで利用できるようになる。複数の利用者でリソースやプロジェクトを共有することができる。
表 6 NeCTAR Research Cloud 仮想マシンの種類（ http://nectar.org.au/sites/default/files/DRAFT%20NeCTAR%20Research%20Cl
oud%20Node%20Implementation%20Plan%20-%202.5.pdf

より）

種類

コア数

メモリ(GB)

ストレージ（GB）

Small

1

4

30

Medium2

860

Extra-Large

8

32

240

2012/1/31 から始まった本プロジェクトは、同年 2 月に研究クラウドの最初のノードが構築され、2013 年には Monash 大学と Queensland Cyber Infrastructure
Foundation(QCIF)が参画した。2014 にかけてさらに参画するサイトが増える予定である。主なサイトのハードウェア仕様を以下に示す。
 The University of Melbourne
 336 cores – 48 core Dell R815s
 3840 cores – 160 x 24 Core, 128GB, 10Gbit/s Xenon Quad2U
 195TB – HP DL180G6 w/ DL2000 @ 24TB/node 146TB – Dell R715 w/ MD1200 @ 24TB/node451

 100TB – Hitachi HNAS/BlueARC
 10Gbit/s – CISCO Nexus (2232, 5596, …)
 Queensland Cyber Infrastructure Foundation
 512 cores – 64 core, 256GB, SGI H2106-G7
 180TB – SGI 3112 @ 36TB/node
 10Gbit/s – CISCO Nexus (2232, 5548, …)
 Monash University
 2304 cores – 96 x 48 core, 192GB, 10Gbits, Dell C6145
 192TB – Dell R720xd @ 24TB/node
 10Gbit/s – CISCO Nexus (2248, 5596, …)
NeCTAR では、2013 年 12 月現在、気象、海洋、バイオインフォマティクスなど 33
プロジェクトが進行している（https://nectar.org.au/projects）。ビッグデータ
解析を伴うプロジェクトも複数存在する。
NeCTAR は単にインフラやツールを提供するだけでなく、研究者同士がコラボレー
ションするための仕組みづくりも目指している。また、自らがクラウドや研究ツー
ルを開発することで研究者のニーズをすぐに反映できるようにという意図もそこに見ることができる。
■参考資料
 公式サイト http://nectar.org.au/home OpenStack 事例紹介
 http://www.openstack.org/user-stories/nectar/
 Tom Fifield, 13 Months of Operations - a Federated Cloud Serving the Broader
Research Community, OpenStack Summit 2013 APR
 http://www.youtube.com/watch?v=_23xnFqRjvU
 http://docs.huihoo.com/openstack/summit/2013/13-months-of-operations-a-federated-cloud-serving-the-broader-research-community.pdf

5) Magellan（アメリカ）
Magellan プロジェクトは 2009 年 9 月にスタートし、U.S. Department of Energy(DOE)と Argonne Leadership Computing Facility を中心とするメンバーではじま452

った 2 年間の研究開発プロジェクトである。国家レベルで分散コンピューティング
環境とデータ分析のテストベッドを開発することを目的としている。目的達成のため、クラウドコンピューティングがどのように利用できるかを探り、DOE が利用する研究向けアプリケーションにおける適用可能性が探られた。
Magellan クラウドは、約 750 ノードから構成される。うち、500 がコンピュート
ノード、200 がストレージノード、いくつかの大容量メモリのノード（１テラバイト）、12 の管理用ノードから構成される。
Magellan プロジェクトの要件は DOE が示す以下の質問に答えることにあった。
 DOE の HPC プロジェクトでオープンソースのクラウド管理ソフトウェアは利用できるか？
 DOEno サイバーセキュリティ要件はクラウドにマッチしているのか？
 新しいクラウドプログラミングの有効性
 DOE の HPC のアプリはクラウド上で効率よく動くのか？
 科学アプリケーションはクラウド環境でどのように使えるのか？
 DOE の HPC アプリをクラウド上で実行することの費用効果が見えるのはいつごろか？

図 11 Argonne Magellan Hardware（http://datasys.cs.iit.edu/events/ScienceCloud2011/s07.pdf より）453

図 12 NERSC Magellan Hardware（http://datasys.cs.iit.edu/events/ScienceCloud2011/s07.pdf より）
表 7 プロジェクトのスケジュール（ http://www.nitrd.gov/subcommittee/lsn/jet/material/Magellan-Coghlan-Can
on-20110517.pdf より）
Activity

NERSC

ArgonneSep 2009

Project startCore System Deployed

Jan 2010 – Feb 2010

Dec 2009 – Jan 2010

User AccessMar 2010 (Cloud)April 2010 (Cluster)Oct 2010 (Cloud)AcceptanceFeb 2010

May 2010

Hadoop User Access

Dec 2010

May 2010
June 2010

Joint Demo (MG-RAST)
Nimbus DeployedJun 2010

NA

OpenStack Deployed

Dec 2010

NA

Eucalyptus 2.0 Deployed

Jan 2011

Feb 2011
Apr 2011-Dec 2011

ANI research projects on
Magellan cloud ends

Sep 2011

ANI 100G active

Oct 2011

Magellan ANI ends

Dec 2011

以上の要件に対して、実際に構築されたテストベッドは次の通りである。
454 コンピュート：IBM iDataPlex: 504 ノード（Argonne）＋720 ノード（NERSC）
 ストレージ：ディスク、アーカイブ、Flash ストレージ
実際に評価されたクラウドソフトウェアは、OpenStack 以外にも Eucalyptus、
Nimbus、Open Nebula がある。評価項目としては、性能評価、クラウドに適したア
プリケーション例、障害発生時の対策、コスト分析もあわせて行われている。コストに関しては、パブリッククラウドの利用に比べて、1/2 から 1/7 という試算も出
ている。
■参考資料
 Algonne National Laboratory 公式ページ
 http://www.anl.gov/
 OpenStack 事例紹介
 http://www.openstack.org/user-stories/argonne-national-laboratory-us-department-of-energy/building-high-performance-clouds/ プロジェクトの概要
 http://computerbecamecloud.blogspot.jp/2009/11/hpccloud-computing-doe.html http://www.mcs.anl.gov/articles/magellan-project-building-high-performance-clouds http://casc.org/meetings/12feb/Shane_Canon.pdf6) San Diego Supercomputer Center（アメリカ）
米国の San Diego Supercomputer Center (SDSC)は、2011 年に研究者間で大規模な研究データを共有するための環境整備にのりだした。利用者は研究者のみならず、
学生、産業界の利用者も想定しており、安定した費用対効果の良いストレージシス
テムを目指している。
図 13 は、SDSC Cloud のシステム構成を表している（2011 年 11 月時のもの）。5.5PBのストレージは、100PB にスケールアップが可能である。冗長化された Arista
Networks 7508 スイッチ、10 gigabit (Gb) イーサネット、ピーク性能は 8GB/秒までを想定している。また、CENIC、ESNet、XSEDE への直接接続も可能となってい455

る。ストレージシステムは、OpenStack の swift を利用して構築されている。
Rackspace/Swift API と AWS の S3 API を一部サポートする。

図 13 SDSC Cloud システム構成（https://cloud.sdsc.edu/hp/system.php より）
ストレージの利用料は、100GB に対して、月額 3.25 ドル（1TB の場合月額 32.5 ドル）としている。データは安全に管理されており、データのオーナーによってアクセス制限をかけることも可能である。また、SDSC Cloud Explorer という専用の Web
インターフェイスを介して、データにアクセスすることができる。
課金体系は大学等研究機関、NPO、民間企業それぞれで異なっている。表は大学等研究機関の場合の利用料金を表している。
表 8 システム構成の詳細（https://cloud.sdsc.edu/hp/system.php より）
Component
Proxy/Authnodes

Features

Node Details
2 quad-core X5660 2.80GHz(16) Dell R610 nodes 48 GB memory
2 X 10Gb ethernet456

2 quad-core E5520 2.27GHz
Storage(14) Aberdeen x539 24 GB memory

nodeA

storage servers

Areca RAID controller
24 X 2TB drives (48TB RAW) capacity.
2 quad-core X5660 2.80GHz
48 GB memory
PERC H800 RAID adapter

StoragenodeB

Advanced HPC JBOD (direct attached to(35) Dell R610 nodes Dell Storage nodes)
Mercury

RM436-SB01

in

JBOD

configuration
45 x 3TB Seagate drives (135TB RAW)capacity.
表 9 課金体系（https://cloud.sdsc.edu/hp/pricing.php より）
On Demand Single Site On

DemandRedundancy

Redundancy

帯域幅による課金

なし

なし

基本料金

$3.25/月

検討中ストレージサイズ（初
期）

Dual

Site

100GB
$0.0325/ GB/月

追加コスト($32.50/TB/ 月 ま た は$390/TB/年)■参考資料
 SDSC サイト
 http://www.sdsc.edu/
 SDSC Cloud https://cloud.sdsc.edu/hp/index.php
 その他
 http://www.openstack.org/user-stories/sdsc/
 http://www.sdsc.edu/News%20Items/PR092211_sdsccloud.html
 http://www.digitalpreservation.gov/meetings/documents/storage12/7-D
avidMinorSDSCcloud.pdf

457

7) Red Cloud（アメリカ）
Red Cloud は、米国コーネル大学で提供される「on-demand research computing
service」である。同大学の Center of Advanced Computing(CAC)という組織が開発、運営を行っている。
 中長期にわたって、比較的少ない計算資源を必要とした研究者
 短期間に膨大な計算資源を必要とする研究者という 2 つのタイプの研究者を対象として、現在 2 つのサービスが提供されている。
 Red Cloud：Eucalyptus で構築された IaaS。登録者は仮想サーバや仮想ディスク
に対してルート権限でアクセスできる。
 Red Cloud with MATLAB：MATLAB 分散コンピューティングサーバと NVIDIA GPU を利用することが可能な SaaS。登録者は、Parallel Computing Toolbox というツールを使って自分のデスクトップマシン上でアプリ開発を行うことができる。また、MATLAB 分散コンピューティングサーバを利用してスケールアップも可能である。
なお、コーネル大学に所属する研究者以外にもこのサービスは開放されている。
Red Cloud のシステム構成を以下に示す。
 8 サーバ (96 コア、メモリ 384GB)。サーバは Xeon E5650(2.7GHz)
 10 Gb Ethernet
 KVM hypervisor 5 つのインスタンスタイプを用意（1 から 12 CPU コア, 4GB から 48GB メモリ）
 7.5TB ストレージを利用可能
 Eucalyptus 3
 CentOS 5/6, Ubuntu 12, Windows Server 2008 Windows Server 2012 を利用可能。
カスタマイズも可能
マシンタイプは、表 10 に示すように 5 種類が用意されている。
表 10 マシンタイプ（http://www.cac.cornell.edu/RedCloud/start.aspx より）
458

タイプ

仕様

M1.small1 core, 4GB RAM, 100GB ephemeral disk

C1.medium2 cores, 8GB RAM, 200GB ephemeral disk

M1.large

4 cores, 16GB, 400GB ephemeral disk

M1.xlarge

8 cores, 32GB, 800GB ephemeral disk

C1.xlarge

12 cores, 48GB, 1000GB ephemeral disk

課金体系はサブスクリプションに基づいており、
1 サブスクリプションは 8,585 コ
ア時間（1 年間で 1 コアを利用することに相当）として計算される。概念的にはプリペイドカードのようなものであり、利用するマシンタイプと利用時間に応じて減額され、残高がゼロになるまで利用することができる。マシンタイプの小さいもの
を長期間で使うことやマシンタイプの大きいものを短期間で一気に利用する場合でも対応できる。また、同時に複数のサブスクリプションを申請することもできる。
表 11 料金体系（http://www.cac.cornell.edu/RedCloud/start.aspx より）

1“Red Cloud” Subscription
1“Red Cloud with

MATLAB”

Subscription
Training service

Cornell

Other

University

Institutions

$400

$640

$600

$960

$63.12/hour$130.84/hour

Academic

最初のサブスクリプションでは 50GB のストレージがデフォルトで提供される。追加のストレージは、コーネル大学に所属するものは$0.50/GB/年、外部の機関は$0.80/GB/年で利用可能である。
システム利用状況は公式サイトで公開されている。

459

図 14 Red Cloud System Status(https://www.cac.cornell.edu/RedCloud/status/default.aspx より）■参考資料
 公式サイト http://www.cac.cornell.edu/redcloud/ https://www.cac.cornell.edu/services/cloudServices.aspx
 http://www.cac.cornell.edu/wiki/index.php?title=Red_Cloud その他
 http://www.slideshare.net/eucalyptus/eucaday-nyc-2012-cornell-red-c
loud-and-eucalyptus http://www.eucalyptus.com/sites/all/files/cs-redcloud.en.pdf8) OpenCirrus（アメリカ）
2008 年 7 月に HP（HP Labs）、インテル（Intel Research）、Yahoo!の 3 社を中核にして、イリノイ大学（UIUC）、シンガポール情報通信開発庁（IDA）、独カールスルーエ工科大学（KIT）の支援を仰ぐ形で、研究や教育利用に向けたクラウドコンピューティングのテストベッド「Open Cirrus」を共同で開設した。このテストベッ
ドでは、グローバル規模のクラウドコンピューティングに関するソフトウェア、データセンター管理、ハードウェア上の課題について研究を進めるほか、データセン
ターワークロードのトレースなど大規模な実験データの提供、クラウド向けアプリ
ケーションやサービスの開発も支援する。
460

2009 年には、ロシア科学アカデミー（RAS）、韓国電子通信研究院(ETRI)、マレー
シアマイクロ電子システム研究所(MIMOS)の 3 組織が加わり、2010 年にはカーネギ
ーメロン大学(CMU)が参加し、その後も中国電信や中国移動通信などが加わった。
本プロジェクトは 4 つの目的がある。
 クラウドコンピューティングによってシステムレベルでの研究を可能とする
 新しいクラウドアプリケーション、アプリケーションレベルの研究を促進する
 実験データ、データセットを整備する
 オープンソースを活用する
OpenCirrus は、システムレベルの研究を可能にするため、仮想マシンに加えて物理サーバも利用者に提供している。HP 主導で開発された Zoni と呼ばれるソフトウ
ェアによって、ベアメタルのプロビジョニングやルート権限の提供、ネットワークの分離を行う。利用者によっては、カーネル変更などシステムレベルの環境を必要としない場合もあるため、IaaS（Tashi、Eucalyptus）や PaaS（Hadoop など）をPrimary Domain Services として提供している。
各サイトの管理を容易にするため、Ganglia を用いたモニタリングや消費電力管理、使用状況管理などの機能を Site
Utility Services として提供している。
OpenCirrus は、サイト毎に異なるハードウェアが使用された複数のデータセンタ
ーをフェデレーションしており、集中管理しているシステムと異なり、サイト毎に環境の差異が存在する。こうした環境において、OpenCirrus テストベッド全体を効率よく管理するため、共通的に必要な機能のみを Global Services として提供している。Global Services には、単一のログイン情報で全てのサイトにアクセスできる Global Sign On や、全サイトのモニタリングを実現する Global Monitoringなどの機能が実現されている。
80 以上の研究プロジェクトが利用しており、たとえば、カーネギーメロン大学はOpen Cirrus を新薬開発のプロジェクトで利用している。

461

Global Services
Global Sign
On

GlobalUser
Monitoring Directories

GlobalStorage

Scheduling

Resource
Tracking

図 15 OpenCirrus サービスアーキテクチャー（https://www.cs.cmu.edu/~droh/papers/opencirrus-ieeecomputer.pdf より）
表 12 OpenCirrus ハードウェア（https://www.cs.cmu.edu/~droh/papers/opencirrus-ieeecomputer.pdf より）
サイト

コア数

サーバ数

メ

モ

リ ス ト レ ー ジ ネットワーク

(TB)

(TB)

CMU

1,165

159

2.40

892

1Gbps

ETRI

1,024

256

0.50

128

1Gbps

HP

1,024

256

3.30

632

10Gbps, ラ ッ
ク間 1Gbps

IDA

2,400

300

4.80

59+

1Gbps

Intel

1,364

198

1.77

610

1Gbps

KIT

2,656

232

10.00

280

40Gbps

MIMOS

1,024

167

0.50

36

1Gbps

UIUC

1,024

128

2.00

500

サーバ 1Gbps,
ス ト レ ージ
10Gbp

RAS

1,136

142

9.10

36

1Gbps

Yahoo!

3,200

480

2.40

1,200

1Gbps

KIT は、インフィニティバンドを採用し、40Gbps でサーバ間を接続し、他のサイトと比べて高速なネットワーク環境を実現している。
■参考資料
 OpenCirrus：A Global Cloud Computing Testbed, IEEE Computer Society 出版,
2010
462

 https://www.cs.cmu.edu/~droh/papers/opencirrus-ieeecomputer.pdf
 HP, Intel and Yahoo expand Open Cirrus cloud computing test bed, TechWorld,2010 Sept http://news.techworld.com/data-centre/3241580/hp-intel-and-yahoo-ex
pand-open-cirrus-cloud-computing-test-bed/
 Christian Baun, Elastic Cloud Computing in the Open Cirrus Testbed
implemented via Eucalyptus，International Symposium on Grid Computing 2009 http://event.twgrid.org/isgc2009/abstract/Grid%20Computing%20&%20Cl
oud%20Computing/Christian_Baun_Eucalyptus_in_OpenCirrus_v1.8.pdf

9) Sky Computing（アメリカとフランス）
米国の FutureGrid とフランスの Grid’5000 という 2 つのプロジェクトが協力し、国境を越えた複数のクラウド連携を実現する上でのテストベッドを実現したプロジェクトである。2009 年に論文が発表され、具体的なプロジェクトの内容が示されている。

図 16 Sky Computing プロジェクト（http://archive.is/eLJKy より）
Sky Computing プロジェクトの目的は、
 エンドユーザがフルコントロールで Sky Computing が提供するクラウド環境（マルチクラウド）を構築できることを示す
 その環境が実用的なアプリケーションを動かす上で十分な性能を持っているこ
463

とを示す
ことにあり、複数のクラウド間での相互運用性と信頼できるネットワークの構築を目指している。
実際のテストベッドは次に示す構成となっている。
 FutureGrid 側は Nimbus がインストールされた 3 サイト（UCSD、University of
Florida、University of Chicago、5000 コア相当）
 Grid’5000 側は 9 サイト（Lille、Rennes、Sophia、Nancy など、1500 ノード、
5500CPU）
 Sky Computing Toolkit（Nimbus、ViNe：ネットワーク接続、Hadoop）
ViNe とはフロリダ大学で開発された高性能な仮想ネットワークの技術である。
800mbps 以上のスループットをわずかな遅延で実現する。

MapReduce App

Distributed
Application

Hadoop
ViNe

IaaS Software

IaaS Software
図 17 Sky Computing Toolkit（http://www.nimbusproject.org/files/riteau_HPACG2011.pdf より）

図 18 FutureGrid 側のテストベッドの構成（http://www.nimbusproject.org/files/Sky_Computing.pdf より）

464

Server level agreement and instances at each cloud provider
University of Chicago (UC)

University of Florida (UF)Purdue University (PU)Xen version

3.1.0

3.1.0

3.0.3

Guest kernel

2.6.18. x 86_64

2.6.18-i686

2.6.16-i686

Nimbus version

2.2

2.1

2.1

CPU architecture

AMD Opteron 248

Intel Xeon Prestonia

Intel Xeon Irwindale

CPU clock

2.2 GHz

2.4 GHz

2.8GHzCPU cache

1 Mbyte

512 Kbytes

2 Mbytes

22

2

3.5 Gbytes

3.5 Gbytes

1.5 Gbytes

PublicPrivatePublicVirtual CPUs per node
MemoryNetworking

実験は、Hadoop クラスタを FutureGrid から Grid’5000 へと拡張していく過程（動的プロビジョニング）が円滑に行えるか、また性能面での評価が行われた。また、一つのクラウド内での処理と複数クラウドをまたいだ処理も性能面で大きな差がなかった。大規模な計算リソースを必要とするアプリケーションの実行において、あるクラウドで十分な計算リソースが得られない場合、連携している他のクラウドから入手することが十分に可能であることが実証されたことになる。
■参考資料
 発表論文 http://www.nimbusproject.org/files/Sky_Computing.pdf
 http://www.manjrasoft.com/ccgrid2010/ccgrid-keynote-final-jose.pdf
 http://www.ijecce.org/535/show/publication
 その他
 http://ercim-news.ercim.eu/en83/special/large-scale-cloud-computing-research-sky-computing-on-futuregrid-and-grid5000

10) Purdue University Research Repository （アメリカ）
Purdue University Research Repository(PURR)とは、米国パデュー大学が提供する研究プロジェクト向け環境とデータ管理のソリューションである。具体的には研究データのリポジトリとして機能する。PURR は、オンライン上に、共同作業スペースやデータ共有用のプラットフォームを提供し、大学に所属する研究者あるいはその協力者が必要とするデータ管理を支援する。大学の主要機関（図書館、情報基
盤部など）からメンバーは構成されている。その構想は、2006 年の「Libraries’
465

Strategic Plan」に遡る。2007 年には「Data Curation Profiles Community」という活動が始まり、その後、NSF のサポートも受けながら、2011 年に PURR ワーキ
ンググループとして新たな構想をたて、2012 年に PURR プロジェクトを開始するに至っている。
PURR は HUBzero（http://hubzero.org/）と呼ばれるオープンソースの研究および教育環境構築用のプラットフォームに利用して構築されている。データセットのみ
ならず、ドキュメント、教材、各種ドキュメント、ソフトウェアツールを有しており、ソーシャルネットワーク機能や協調作業を支援する機能を提供する。
PURR が提供する利用者サポート機能には、以下のものがある。
 ナレッジベース（FAQ）
 データ管理計画の共通情報
 データ管理計画のためのアセスメントツール
 チュートリアル
 ワークショップおよびビデオ
 Q&A 対応
 データセットの一覧
2012 年 4 月の時点で、62 のプロジェクトが作られ、167 人がユーザとして登録されている。なお、2013 年 12 月の時点では、35 のデータセットが公開されている。
■参考資料
 公式サイト https://purr.purdue.edu/
 The Responsible Stewardship of Research Data - UC Merced Library http://docs.lib.purdue.edu/cgi/viewcontent.cgi?article=1002&context=lib_fspres

11) University of Pennsylvania（アメリカ）
米国ペンシルバニア大学の Information Systems & Computing 部門（ISC）では、全学に対してクラウドコンピューティングサービスを提供している。ISC では大学
独自のサービスに加えて、いくつかの商用ベンダーと連携しており、その代表的な
466

ベンダーとして、アマゾン、Google、Box がある。大学に所属する教員、職員および学生すべてが対象となる。
IaaS として大学独自で提供されているサービスの一つに「PennCloud Computing
Service（PennCloud）」がある。次の表は提供されるサーバのサイズと利用料金を表している。
表 13 料金体系（http://www.upenn.edu/computing/isc/cloud/usage.html より）InstanceType
Small
Medium
Large

CPU
1

Memoryvirtualcore
2virtualcores
4virtual

cores

Base

Monthly

Storage

Rate

Annual Rate

2GB

100GB

$60

$495

4GB

200GB

$120

$990

8GB

400GB

$240

$1,980OS は CentOS と Windows Server 2008 を選択することができる。
一般の商用サービスのうち主なものは以下の通りである。
Amazon Web Service
AWS と大学間で Master Services Agreement が交わされており、この規約のもとで
AWS のサービスを利用することができる。Agreement の内容はたとえば、セキュリ
ティポリシーは大学のものにそったものであるとか、データリカバリーの保証、ト
レーニングサポート等が含まれる。
Penn+Box
ファイルやフォルダの共有をオンラインで行うサービスである。研究者間でデータを共有したり共同作業を行うために用いられる。2012 年 11 月 1 日より提供されている。一アカウントあたり 50GB がデフォルトで与えられている。次の表はストレージのサイズと料金の関係を表したものである。
表 14 Penn+Box の料金体系（http://www.upenn.edu/computing/isc/cloud/usage.html より）
Penn+Box Storage

FY'14

FY'15
467

50 GB (Default)$0.00/month$0.00/month

500 GB*$50.00/month$50.00/month

750 GB$75.00/month$75.000/month

1 TB$100.00/month$100.00/month

Google Apps
Google Apps for Education を利用することができる。このサービスには、メール、
カレンダー、ドキュメント共有、チャットなどの機能が含まれる。
提供されている主なサービスを次表に示す。
表 15 サービス内容（http://www.upenn.edu/computing/isc/cloud/usage.html より）
カテゴリー
Compute / Processing/ High Performance
Computing (HPC)
Storage
Collaboration /Communication /Productivity / Office
Platform Services
Single Purpose
Solutions

クラス

推奨ベンダー、サービス例

Infrastructure as a

Amazon Web Services

Service(IaaS)(AWS), ISC Penn Cloud

Infrastructure as a

Amazon Web Services

Service(IaaS)(AWS), Box, Nasuni

Software as aService (SaaS)
Platform as aService (PaaS)

GoogleApps, Penn+Box, Office 365,
SocialCast, Yammer
Oracle, Microsoft Azure
SAP, Learning Management

Multiple

Systems, Travel Expense
Management

主な用途（ユースケース）： Compute / Processing / HPC
 天体観測データの処理 言語パターンのための大量テキストの分析
 短期間でのシステム開発やテスト
 Storage468

 研究データの保管、災害対策
 部門間で共有されるデータの保管スペース
 Collaboration / Communication
 地理的に離れた研究者に対して、コラボレーション、掲示板を介したデータの共有、電子メール等の機能を提供
 異なる場所にいる複数の医師同士のビデオ会議によって患者の診断を支援したり、複数の場所でリアルタイムに講師が授業を行う オンラインのディスカッションやコラボレーション用のフォーラムを作る
ことによって特定の目的をもったユーザーコミュニティを形成
 Productivity / Office ユーザは特定のソフトウェアをインストールすることなく、任意のデバイスからオンラインでドキュメントを表示、編集、および、共有することができる Platform Services
 Web サーバ、ロードバランサ、コンテンツ管理、大きな研究施設のウェブサ
イトでコンテンツを管理する機能を提供
 異なるデータセンターで提供される Oracle データベースクラスタ
 その他
 Automatic Call Distribution (ACD) Travel Expense Management
 Learning Management Services (LMS)
特に外部サービスを利用にあたっては、データやプライバシー保護を目的として、
以下のようなガイドラインが発行されている。
 Cloud Computing: Opportunities Used Safely
 Data Sensitivity and Review Framework
 SPIA for Vendors tool Box Data Sensitivity and Usage Statement■参考資料
 公式サイト http://www.upenn.edu/computing/isc/cloud/usage.html
 http://www.upenn.edu/computing/security/cloud/index.php
 http://www.upenn.edu/computing/isc/penncloud/compute/index.html

469イ) アカデミッククラウド構築・運用関連
海外のアカデミッククラウドと認証連携に関する動向を調査することで、日本における今後の展開に活用できる情報を収集した。
1) アメリカ： Internet2、NET+、NSF、Kuali Foundation、Marrist College(1) Internet218の概要：
Internet2 は、米国内 250 以上の高等教育機関をメンバーとする非営利コンソーシアム
であり、下記の３つを主要なサービスとして提供している。
 Advanced Network：教育、研究コミュニティ向け 100Gb のネットワークであるInternet2 R&E Network の構築、運用
 Cloud Services & Applications：Internet2 NET+イニシアティブを中心とした、様々なクラウドサービスを提供
 Trust & Identity：米国認証フェデレーションである InCommon や、Shibboleth、Grouper、
COmanage といったミドルウェアを開発、提供(2) Internet2 NET+プログラム：
Internet2 NET+はクラウドサービスのブローカーであり、技術的ソリューションではなく、教育・研究コミュニティが新たな方法で働くことを可能とするソリューションのポートフォリオである。プログラムの趣意は、「グローバルな研究・教育コミュニティに有益な、連携したクラウドサービスの広範な利用に寄与する。他の Internet2 のサービスと連携して、NET+プログラムは全ての参加機関に、最善の契約で提供される価値の高いクラウドサービスへの簡単で、着実で、合理的なアクセスを提供する。」となっており、参加機関にコストメリット、簡単なアクセス、容易な管理、共通の特殊なニーズへの対応、といったソリューションを提供するために下記を行っている。
 Internet2 コミュニティのための新たな価値あるサービスを定義
 性能、ユーザビリティ、セキュリティといった要求を満たすソリューションをメンバーと提供者で協力して開発
 一括した契約と提供の実施
 より良い価格と契約のためにコミュニティのスケールを活用
 Internet2 R&E Network と InCommon 等のサービスを活用
Internet2 NET+の対象は世界の K-20 教育研究機関としており、Internet2 メンバーの250 機関、RNP（地域のネットワークパートナー）を通した他の 4,200 機関、RNP を通し

18Internet2 公式サイト： http://www.internet2.edu/

470

た K-12 組織、および、Internet2 のグローバルパートナーを通した世界の高等教育機関である。

図 3.2.1.1 Internet2 NET+のサービス（ 出 展 ： Internet2 Addressing R&E challenges through community –developed
technology19）
サービスプロバイダには、2014 年 3 月の段階で 44 社が参加している。サービス状況
は、提供中＝22 社、評価中＝21 社、終了済み＝1 社となっており、IaaS、SaaS、スト
レージ、セキュリティツール、コラボレーションツール等のクラウドサービスが提供さ
れている。

19

http://www.internet2.edu/media/medialibrary/2013/08/16/about-internet2-netplus.pdf

471

図 3.2.1.2 Internet2 NET+のフェーズ（出展： Internet2 公式サイト）
それぞれのクラウドサービスは、4 つのフェーズを経た後に利用可能となる。
 要求フェーズ： 参加機関が Internet2 NET+へ追加したいサービスのスポンサー機関となり、Internet2 NET+に追加要求を行う。
 評価フェーズ： Internet2、提供者、スポンサー機関が協力して NET+のサービスとしての適合性について調査、評価を行う。
 検証フェーズ： スポンサー機関といくつかの参加機関が提供者、Internet2 と協力して NET+サービスとしての検証を行う。
 先行導入フェーズ： いくつかの参加機関がサービスを先行導入して、Internet2、提供者と協力して、NET+の一般利用に向けた準備を行う。
 一般利用フェーズ： NET+のサービスとして一般利用を開始する。
ここで、スポンサー機関は、検証フェーズにおける提供者の支援や、検証に興味を持
つ他の機関との会議開催を行うもので、さらにスポンサー機関の CIO は Internet2 NET+
スタッフ、提供者と共に会議に参加してサービスアプローチ、候補となる機関、各フェーズの移行計画等について検討を行うこととなっている。
サービスの検証は、下記 5 点の観点で行われる。
 機能評価： 現有機能とロードマップのレビュー、参加機関が構成するサービス評価472

グループが要求機能の優先付けを行う。
 技術（ネットワーク、ID）：

Internet2 R&E network との接続、InCommon への対応を確認。
 セキュリティ、コンプライアンス：

Cloud Security Alliance の Cloud Controls

Matrix （ CCM) を カ ス タ マ イ ズ し た セ キ ュ リ テ ィ 評 価 を 実 施 す る と と も に 、FERPA,HIPAA,への対応状況を確認。
 ビジネス： サービス評価にあたり、Internet2 とサービス提供者が MOU を契約し、評価フェーズにおいて、契約書の調整を行う。また、コミュニティのアセット活用、集積効果による価格調整を行う。
 展開： サービス評価グループの参加機関は事例のためのテスト実施と資料作成を約束する。
契約方法は、下記の 3 種類が用意されている。
TypeA： 機関と SP が直接契約して、Internet2 は支援。
TypeB： SP は Internet2 と全体契約を行い、機関は NET+契約に基づきサービス
を追加、利用する。（もっとも多いアプローチ）
TypeR： 機関とリセラーが直接契約して、Internet2 は支援。
課金方法は、下記の 4 種類が用意されている。
TypeA： サービスのメンバー価格を決定＝＞Intenet2 は SP から管理費用を割掛
けでもらう
TypeB1： サービスの原価を合意して決定＝Internet2 は大学に（管理費用を上乗せした）メンバー価格を提示。
TypeBJ： TypeA と同じ
TypeR： リセラーはメンバー価格を提示。Internet2 はリセラーから管理費を徴
収また、全世界の NREN に向けた Global NET+も展開中で、このための契約方法、課金方
法についても検討が進められている。
(3) NFS：NFS (National Science Foundation) は米国政府の科学研究費に関する機関で，我が国における文部科学省（政策）と日本学術振興会（研究費配分）を合わせた役割を果たしている．年間 6.9 B US ドルの予算を有しており，メリットおよび査読ベースの研究
費配分を行っている．スタッフは研究者・技術者で構成され，各大学から研究者が一定期間在職する形で，各大学の研究者コミュニティとの強い連携を保っている．
今回訪問した Directorate for Computer & Information Science & Engineering(CISE) は， 全体の 70% を占める以下の 4 つ Core Program を有するとともに，それらをまたがった Cross-Cutting Programs が残り 30% を占めている:473

 Computing and Communication Foundations (CCF) Algorithmic Foundations
 Communication and Information Foundations
 Software and Hardware Foundations
 Computer and Network Systems (CNS) Computer Systems Research Networking Technology and Systems
 Information and Intelligent Systems (IIS) Human-Centered Computing Information Integration and Informatics
 Robust Intelligence Advanced Cyberinfrastructure (ACI)
クラウドに関しては，2010 年に議会に対して “NFS Report on Support for Cloud
Computing”と題する報告書を提出した．その結果，次世代インターネットに関する研
究開発プログラムである Global Environment for Networking Innovations (GENI) の成果をベースに，国内に点在するテストベッドやリソースをつなげるとともに，公的分
野におけるギガビットアプリケーション開発を立ち上げ，公的機関と私的機関のパート
ナーシップを強化するための US Ignite がホワイトハウスにより 2012 年 6 月に立ち上げられた．また，GENI Rack により構成される仮想ネットワーク上に構築する NFS Cloudの提案募集を行っており（2013 年 12 月提出期限），フェーズ 1 ではスケーラビリティのある基盤デザインと初期活動を行い，フェーズ 2 において実際に研究コミュニティで利用可能なアプリケーションを募集することになっている．フェーズ 1 では，20M US
ドルの資金が 2 つ程度のプロジェクトに提供される予定である．
（参考資料）
 NFS Report on Support for Cloud Computing http://www.nsf.gov/pubs/2012/nsf12040/nsf12040.pdf
 CISE Research Infrastructure: Mid-Scale Infrastructure - NSFCloud (CRI:
NSFCloud) Program Solicitation
 http://www.nsf.gov/pubs/2013/nsf13602/nsf13602.htm(4) Kuali Foundation：
Kuali では，財務会計システム，教務情報システム，研究費管理システム，図書館シ
ステム等の事務系のエンタープライズアプリケーションソフトウェアをオープンソー
スとして大学や企業が共同開発しており， Boston College, Cornell University,
Indiana University, Marist College, MIT, University of Michigan, rSmart 社など，
474

70 を越える大学や企業等が Kuali Foundation の有料会員になっている．
毎年 11 月には Kuali Days と称する開発者・利用者が一堂に集う会合を行っており，
今回は San Diego で開催された．会議への参加を通じて，財務会計システム Kuali
Financial System や研究費管理システム Kuali Coeus，図書館システム Kuali Open
Library Environment (OLE) の開発や利用が進んでいる一方で，教務情報システム
Kuali Student については Curriculum Management のみのリリースとなっており，開発・利用が遅れていることが分かった．クラウドに関しては，財務会計システムや研究費管理システムの運用を Amazon AWS で行うサービスを rSmart 社が行っていることも分かった．
(参考資料)
 Kuali Foundation
 http://www.kuali.org
 Lance Speelmon (rSmart Inc.), "Kuali in the Cloud" https://www.youtube.com/watch?v=s-XO1Wq4MTc(5) Marist College：
Marist College はニューヨーク州ポーキプシーにある私立大学で，学生は約 6 千人である．Marist College は，Bill & Melinda Gates Foundation が EDUCAUSE とともに実施している Gates Next Generation Learning Challenges (NGLC) により研究費を獲得し，Open Academic Analytics Initiative (OAAI) を牽引している．今回，AssistantDean, School of Computer Science and Mathematics の Mary Ann Hoffmann 氏のコー
ディネーションにより，Vice President for Information Technology/CIO の BillThirsk 氏，Lead for Learning Analytics Research の Eitel Lauria 博士，Learning
Analytics Specialist の Sandeep Jayaprakash 氏などへのインタビューを通じて以下のことが明らかになった:
1. CMS/LMS として利用している Sakai CLE により取得された学習活動に関するデー
タを活用し，実際の学生に対する学習状況のフィードバックおよび指導を行っていること
2. 解析に際しては Sakai 内部コードで匿名化されたデータとして扱われていること
3. ラーニングアナリティクスに関するオープンモデルを提案していること
4. コンピュータサイエンスの研究者と強い連携の下で OAAI を実施していること
5. Sakai や Kuali 等，オープンソースプロジェクトに対して大学としての参加の意
義を明確にしながら戦略的に関わっていること
6. IBM と連携し，OpenFlow を活用した SDN (Software Defined Network) Lab を構
築，SDN を用いた大学間データ共有に関する検討を行っていること（参考資料）
475

 Open Academic Analytics Initiative (OAAI) https://confluence.sakaiproject.org/x/8aWCB2) オランダ： SURF、SURFconext（SURF 担当者への現地調査報告）(1)SURFnet の概要：
SURFはオランダの高等教育機関の共同体であり、2012年に設立25年目を迎える。具体的なサービスの提供は、以下の4つの傘下組織を通して行っている。

図 3.2.1.3 SURF の構成
 SURFnet：高等教育機関に対してネットワークおよびICTサービスを提供
 SURFmarket：ICT、ソフトウェア、コンテンツなどのライセンシングとベンダー管理
 SURFsara：ハイエンドの利用者に高性能コンピューティング（High Performance
Computing）を提供するためのコンピューターセンタ
 SURFshare：共同プロジェクトから生まれたサービスを引き継ぎ、継続的に運営
SURFnetはネットワークとコラボレーションのためのインフラ提供が主な目的であり、認証フェデレーション、コラボレーションのインフラ、クラウドサービスのショップ等のサービスであるSURFconextを提供している。
(2)SURFconext：
オランダの認証フェデレーションは、2009年に運用を開始した。現在、2011年のSURF
Cloud Taskforceのポジションペーパ「Into the cloud with SURF」を受けてCloud Firstを実践中である。SURFconextは、オランダ国内の高等教育機関・研究機関のコラボレー
ションのためのインフラである。クラウドサービスのポータルのようなもので、ユーザは、SURFmarketがクラウドブローカとして調達したクラウドサービスの中から、自分の好きなツールを自由に選択・組み合わせて使うことができる。使いたいツールを
SURFconextに申請すると、接続できるようになり、認証フェデレーションによる認証の476

後にSURFconextの利用を開始する。SURFconextではグループ管理機能も提供しており、グループとして利用可能なツールの設定もできる。これはアプリケーションごとの管理ではなく、各ツールに共通のグループ管理となっている。高等教育機関・研究機関がシステムの更新などを行う際には、パブリッククラウドを優先的に利用するという基本方
針を打ち出している。パブリッククラウドにサービスが存在しないか、法的な要件を満たしていない場合は、コミュニティクラウドでの開発も検討が進められている。

図 3.2.1.4 SURFconext と SURFmarket の役割

 SURFconextへの参加状況：
 IdPは94機関、高等教育機関、研究機関の90％が接続
 SPは150以上（商用、HE・研究機関、オープンソースを含む）。うち、商用は今のところ36件だが、増加中。

 2013年9月時点のトランザクション（Transaction）は330万件／月で、急増中。
 ほぼ全てのサービスにSAMLログイン、またはグループAPIが利用可能
 クラウドサービスの提供方法について：

SURFconextを介して１つのポイントで技術的な接続を行うのみでなく、
SURFmarketを介して１つのライセンスで契約を実施（サービスごとに標準ライセンスを設定）キャッシュフロー（請求書の発行、決済等）は、SURFmarketが仲介して実施(3) SURFmarket：
SURFmarketは1991年設立のNPO団体。もともとはソフトウェアの契約・配給を行う目的で設立された。職員数は約40名で、ソフトウェア、コンテンツ、ハードウェアおよびク
ラウドサービスの調達・管理・販売・配給を行っている。ベンダー管理チーム（6名）
477

が契約などのビジネスサイドと、利用に関する技術面を担当しており、SURFconextと連携してクラウドサービスブローカとして活動している。

図 3.2.1.5 SURFconext Cloud Service Broker の概要
SURFmarketは、クラウドプロバイダとユーザの間にブローカーとして入ることにより、
 契約条件の交渉を一括して行い、ユーザによりよい条件でサービスを提供
 SURFconext上でログインすることにより、ユーザのログイン情報を保護することが可能（SURFconextから属性のみを送信） ソフトウェアのライセンスは永久ライセンスで１回の決算ですむが、クラウドサービ
スでは短期間かつ利用毎の支払いとなることによる調整
 請求書作成や決済など財政面も担当
 ベンダーから利用統計を取り、スプレットシートにして大学に提供
クラウドサービスには、36のサービスプロバイダが参加しているが、ベンダーと高等教育機関などとのB to Aのみでなく、学生や教員などとのB to Cにもスムーズにサービスを提供することを目指している。運営は政府からの助成金は一切なく、高等教育機関、研究機関から支払われる手数料（商品・サービスの価格の6％）で行われており、収入
は5～6,000万ユーロ程度である。そのうち、クラウドビジネスは20万ユーロであり、今後は手数料を0％にして会費を取ることも検討されている。
 クラウド導入のステップ；
1. 2011年：アメリカへ視察（上述）と最初のクラウド戦略の作成（視察の結果、ク478

ラウドの導入による国内の高等教育機関・研究機関への影響が明確化）
2. 2012年：ベンダー管理の開始。まずは大手の商用サービス（Google Apps、
Office365、Sakai、Liferay、Greencloud）との接続完了
3. 2013年：SUFRmarketのクラウドサービスブローカとしての活動開始。需要主導型（demand driven）のアプローチで、高等教育機関からのリクエストのあったサービスに対してベンダーと交渉し、SUFRmarket上で提供。SUFRがよいと思ったサービスを導入するケースや、ベンダー側から売込みがあるケースもある。
 サービスの選定ステップ；2.

クラウドプロバイダ候補のリストを作成：a．SURFが関心のあるもの、b．ベンダーからの売り込み、c．HE・研究機関からのリクエスト

3.

スクリーニングプロセス：SUFR内部の選定基準（SSO対応の有無、プライバシ
ー保護のリスク、需要の有無など）。この基準は非公開。

4.

正式な「Go」サイン

契約面：契約書の作成は、テンプレートをもとにライセンスマネジャーが調整。必要に応じて弁護士にアドバイスを求める事もあり。

5.

技術面：SURFのシステム上で作動するか検証・調整

Production：SURFmarket／SURFconextのポータル上で利用可能にする

価格・契約情報なども記載

News letterなどを通してサービス追加を通知

選定に際しては、ツールのタイプごとに、数種類の選択肢は提供できるようにバランスを取っている（同じタイプのツールばかり何種類もあったり、あるタイプのツールで選択肢が一つしかなかったり、ということのないようにするため）。



クラウド購入のポータル

ポータルでは、下記の機能を提供している。


購入機関のデータベースとつながっており、購入する権利があるかどうか、予算額、過去に購入したものなどのデータに参照できる



予想利用数を元に、3年間の利用料金の見積りが計算される。計算の結果、EUの競争法に基づいて一定額以上になる場合は、入札でベンダーを決定しなければならない

クラウドサービスのプライバシーとセキュリティに関して、法律面では、データ保護法などEU・国内で求められる法的要件を満たす必要がある。また、契約面では、準拠（compliance）を必要とする項目を設定した枠組みをつくり、必要とされる項目をチェ
ックして「データセンターが国外にある」などを確認している。チェックされている項目が少ないほどトラストレベルが低いということであり、契約書はその分長くなる。契約書は過去２年間修正を繰り返しており、かなり詳細なものになっている。

479

図 3.2.1.4 SURFconext の Legal Framework3) イギリス： janet、Janet Brokerage（jisc, janet 担当者への現地調査報告）(1) janet の概要：
janet は、”Jisc Collections and Janet Limited”と jisc company の一部で、政府費用により主に研究機関と高等教育機関向けの janet network の運用と開発を行っている。
janet は下記のサービス提供や開発を行っている。
 janet cloud services：クラウドサービスを提供
 janet collaborate：ビデオ会議やメッセージサービスを提供
 janet for research：最先端研究プロジェクト向けにネットワークサービスを提供
 janet futures：ID管理やネットワーク系の開発
 janet connect：Janet6、eduroamや証明書発行やネットワーク管理サービス等を提供
100Gb の Janet6 を 2013 年 11 月に提供開始。また、janet は英国内閣府（Cabinet Office）の定めるリスク評価に関するインパクトレベル 2~4 を認定済みで、情報セキュリティ戦略を策定してストレージサービスの提供を検討している。
(2) Janet Brokerage：
janet がブローカ（Janet Brokerage）となり、調達の枠組み（ワークフローなども含
む調達のプロセス）を作成し、契約条件など各機関に代わって janet が一括交渉を行う
480

仕組みである。現在、下記のクラウドサービスを提供している。
 Financial X-ray
 Dropbox for Business Amazon AWS
 Data Archiving Framework：janetが提供するデータアーカイブサービス
 Cloud and Data Centre Framework：8社の認定企業が提供するクラウドサービスとデータセンター
 Cloud Services for Education Agreements：Google Apps for Education、MS Office
365の学術向け利用条件をjanetが一括で交渉・締結して提供
 Shared Data Centre Space：研究機関、高等教育機関の間でのデータセンターの貸し出しを支援するサービスを提供
これら調達の枠組みは、欧州内の規定に従って設定している。例えば、欧州内の競争法の規定に従い、大学を含む公共機関が一定額（14 万ユーロ）以上の購入を行う際は、入札をしなければならない。また、ニーズに反応する形で対応している。つまり、交渉の対象となるサービスは janet が積極的に開拓するのではなく、購買コンソーシアム（地域毎に存在するコンソーシアムで、高等教育機関は必ず地域のコンソーシアムに所属して、その規定に従って購買する）からの希望があった場合に対応する。
(3) 英国の高等教育機関・研究機関におけるクラウド利用の現状について パブリッククラウドの利用にはメリットとデメリットがある。例えば、クラウドをス
トレージとして利用する場合、コストの削減にはなるかもしれないが、プライバシーとセキュリティの観点からのリスクが大きい。大学はクラウドの利用には興味はあるが、その利用には躊躇している状況にある。

 クラウドの利用では情報保護法（Data Protection Act）などの国内法にも関わってくるため、その点も利用の足止めになっている。先進的でクラウドに興味のあった大学では、弁護士費用を投じて法的な側面の調査を行ったところもある。そこで、個別大学の費用を削減するため、jisc として交渉することになった。


商用サービスの法律アドバイザーと利用条件を交渉し、欧州標準を作成した。
現在、EU 圏内の大学・研究機関では、jisc が交渉したこの利用条件が標準として利用されている。ただし、利用条件は毎年更新されるので、jisc が毎年更新作業を行う必要がある（それでも各高等教育機関や継続教育機関（Further
Education）が各自で行う事を考えれば、かなりのコストと労力の削減である）。

 英国の大学がクラウドを利用するのであれば、解決策はハイブリッドクラウドであると考えられるが、現時点では、パブリッククラウドのセキュリティレベルが低いことから、英国の大学の大部分がパブリッククラウドに移行する可能性は低いと考え
られる。
481



英国政府はある商用クラウドにインパクトレベル 2 の認定を行ったが、条件としてデータの保存先はオフショア（off-shore）しない（＝データの物理的な保存先は欧州域内にとどめる）ものとした。ちなみに、インパクトレベル 2 は比較的セキュリティレベルの低い、ビジネスに最低限求められる標準。

 キーマネジメント（Key management）を提供するパブリッククラウドも出てきているので、それを行う第三者組織、および物理的な保存先が英国内あるいは欧州内に存在しているという前提であれば、パブリッククラウドのストレージを利用するということも考えられる。

482ウ) 国内大学におけるクラウド活用事例のまとめ483

資料 3.

本事業に係る調査，報告書等資料

１）「コミュニティで紡ぐ次世代大学 ICT 環境としてのアカデミッククラウド」
キックオフシンポジウム発表資料
http://www.icer.kyushu-u.ac.jp/topics_20130711
２）「コミュニティで紡ぐ次世代大学 ICT 環境としてのアカデミッククラウド」
中間報告会発表資料
http://www.icer.kyushu-u.ac.jp/ac_axies2013
３）「コミュニティで紡ぐ次世代大学 ICT 環境としてのアカデミッククラウド」
最終報告会発表資料
http://www.icer.kyushu-u.ac.jp/topics_ac_20140213
その他資料
文部科学省 学術情報委員会 配布資料
第 6 回：平成 25 年 10 月 25 日(金曜日)開催
http://www.mext.go.jp/b_menu/shingi/gijyutu/gijyutu4/031/shiryo/1340830.htm
第 8 回：平成 26 年 1 月 17 日(金曜日)開催
http://www.mext.go.jp/b_menu/shingi/gijyutu/gijyutu4/031/shiryo/1343470.htm
第 9 回：平成 26 年 3 月 7 日(金曜日)開催
http://www.mext.go.jp/b_menu/shingi/gijyutu/gijyutu4/031/shiryo/1345076.htm

484

資料 4.

キックオフシンポジウム・パネルディスカッション議事録
平成 25 年 8 月 9 日
コミュニティで紡ぐ次世代大学 ICT 環境としてのアカデミッククラウド
キックオフシンポジウム「ビッグデータ時代のアカデミッククラウドシステム」パネルディスカッション要旨
出席者：
ゲストパネリスト
相原

玲二

北川

源四郎 情報・システム研究機構 機構長

喜連川 優

広島大学情報メディア教育研究センター長 教授
国立情報学研究所 所長

パネリスト
安浦

寛人

九州大学 理事 副学長 産学連携センター長 知的財産本部長

深澤 良彰

早稲田大学

理事 理工学術院 教授

梶田 将司

京都大学 学術情報メディアセンター

棟朝 雅晴

北海道大学

教授

情報基盤センター 教授

司会：
岡田

義広

九州大学 附属図書館付設教材開発センター

教授

主なコメント大学の ICT 基盤に最新の技術を大学に取り組むことは重要で、クラウド化を考えることはよいことだ。大学の情報システムには季節ものがあり、WEB による合格発表の時は、ネットワークへの負荷は 50 倍に跳ね上がる。これらを解決する手段として、システムを短期的に利用できるクラウドは魅力的だが、全国の大学で同じ時期に同じ目的のサービス
利用頻度が増えるので、負荷の掛かる時期が異なる業界との連携を検討してみてはどうか。また、アカデミッククラウド構築を検討する際には、商用クラウドとの連携が必要と考えるので、使い分けの課題や利点も整理しておく必要がある。なお、クラウド基盤とネットワークがシームレスにつながり、運用も連携していることが重要なので、SINET
側もアカデミッククラウドを意識した構成が必要と考える。

485

経営的な観点からだと、クラウドシスムは一見コストパフォーマンスがよいように思われているが、長期的にみて合理性があるか、コストセーブできているのか、計算効率が上がっているのかを検証することが課題だ。クラウドにより一元的にサービスを纏め、情報を集約することで、国が要求してくる課題に対して、敏速に対処できるようになればいい。
いろんなファンクションを共有化/標準化していただくことは、ものすごく国益に続くことになるので、この事業に強く期待している。根本的に学術 IT インフラを刷新することは、MUST と考える。
大学の IT ファンクションは 2 つに分けられる。非競争力領域で共有しても構わない分野と、競争領域で大学の個性を示す 2 つの分野に分けられる。しかし、ほとんどの大学では、共通領域に関しては個々で対処しており、コストが掛り疲弊しているのが現状だ。
クラウドを活用し実体的なコストダウンをつくることで、日本を元気にすることができると思う。また、クラウド化によるバルク調達で大きなコストダウンが行えると考えるので、本事業で調達についても考えていただきたい。
オープンソースを用いてクラウド化にすると夢のような環境を手に入れるように思われがちだが、実際は落とし穴だらけで、運用を始めた時にはいろんな問題が起こると思う。
そこでお願いしたいのは、アカデミッククラウドだけの研究/運用技術開発ではなくて、
商業クラウド利用/運用にも活用できるような意気込みで研究/運用技術開発していただ
きたい。幅広い分野について知識と経験が持てるような人材育成の仕組み作りが大切で、将来は日本発の独自技術を世界に向けて提供できるようになってほしい。わが国には、システム系の人材が極端にすくなく、この分野の人材を強く育成することが必要だ。本
事業を通じてこの人材育成が実現できると、運用面でも高い技術を持った魅力的なクラウド基盤が構築でき、大学関係者に取って安心して、安定的に活用できる ICT 環境が整備されることに繋がると思う。

－ 以 上 －

486

資料 5.

中間報告会パネルディスカッション議事録
2013 年 12 月 18 日
『アカデミッククラウド環境構築に係るシステム研究』提案「コミュニティで紡ぐ次世代大学 ICT 環境としてのアカデミッククラウド」
中間報告会 第二部ディスカッション要旨（大学 ICT 推進協議会 年次大会）

出席者：
事業メンバー
岡田 義広 九州大学 附属図書館付設教材開発センター 教授
梶田 将司 京都大学 学術情報メディアセンター 教授
棟朝 雅晴 北海道大学 情報基盤センター 教授
森原 一郎 大阪大学 情報推進機構 特任教授
西村 浩二 広島大学 情報メディア教育研究センター 教授
山地 一禎 国立情報学研究所 学術認証推進室 准教授
菅沼 拓夫 東北大学 サイバーサイエンスセンター 教授
中村 修

慶応義塾大学 環境情報学部 教授

安浦 寛人 九州大学 理事 副学長 産学連携センター長 知的財産本部長
深澤 良彰 早稲田大学 理事 理工学術院 教授
アドバイザリー伊賀野康生 ベライゾンジャパン合同会社
北瀬 公彦 シトリックス・システムズ・ジャパン株式会社
桑原しん子 株式会社日立製作所
滝島繁則

伊藤忠テクノソリューションズ株式会社林

NTT コミュニケーションズ株式会社雅之

藤田 正典 三菱商事株式会社
望月悟

日本電気(株)山下克美

ファルコンシステムコンサルティング株式会社

吉荒祐一

アマゾンデータサービスジャパン株式会社

アドバイザリーの発言
このアカデミッククラウド事業は、研究ではなく永続的に続けていく事業と理解している。
事業は、目的があってなされるもので、それがしっかりしていないと、求心力が続かない場合が多い。つまり、事業を始めるには、目的と実現方法をクリアにしておく必要がある
487

と思うがいかがお考えか。
事業メンバーの発言
研究分野と教育分野、事務分野で全く同じアーキテクチャが使えるとは思っていないが、お互いの連携は必要と考える。教育分野や事務分野と共通できるクラウド基盤を活用することで、研究分野で利用できるインフラ領域の拡大が図られ、効率化、コスト削減ができて、研究分野の向上に繋がると思う。
仕様を「一つに、これに決める」ということは難しいと感じている。各分野のアプリケー
ションを分けて、連携を進めていくことで、全体を網羅していくことを考えていきたい。
教育は、従来の教育の在り方をデジタル化していくことで、効率化を図りたい。既に、この分野では、企業でビジネス展開しているところもあるので、協調・共存していきたい。
教育は、事務系と少し違い、R&D も必要と考えており、我々としてはここに注力し、ベーシックな部分を整理していきたい。
事務での業務内容は、企業と大学とではあまり変わりがないと思っている。その意味からして、商用ベースを活用していくことが効率的ではないかと個人的には考えている。また、セキュリティや SLA 的なところを、アカデミックな要素に合わせてどう決めていくかが肝心だ。
アドバイザリーの発言
最終的なアウトプットは、どのようなイメージをもっているのか？また、インタークラウ
ドはどのこのレイヤの連携を想定しているのか？

事業メンバーの発言
我々がアウトプットする報告書が、どこまでアカデミッククラウド実現において反映されるかは正確にはわからないが、学術情報委員会でも参考にされるので、今後の学術情報基盤を検討するにおいて影響を与えることは間違いないと思う。
今年仕様書を作り、来年以降実現に向けた活動にリンクしていくと思っている。
この質問は、重要なポイントである。文科省の縦割り行政の中で、高等教育局と研究振興
局では若干アカデミッククラウドに関する考えが違う。今回の委託事業は、研究振興局からの委託事業で研究的な色合いが強い。しかしながら、教育自身が ICT の波にさらされて488

きており大きく変わろうとしているので、既に境界線はないと思う。
また、先日運営交付金の 3 割(3000 億程)を大学改革に使うとのメッセージが文部科学省からだされた。これは、お金の使い方を変えるという事だ。これらを各大学が行うには、今までのやり方では対応できないので、まずは業務と教育の在り方を変える必要があると考える。このような国からの動きが既に始まるので、この事業で作成する報告書・仕様書は、今後の日本の高等教育・研究を支えるインフラのあり方を議論するにおいて、かなり影響力のある資料となる。
アドバイザリーの発言
アカデミッククラウドを構築した後の利用に関する「強制力」に関しては「目的」をしっかりと決め、利用者も提供者も理解しておくことが重要だ。作りっぱなしではなく、利用者、提供者の両面において継続したケアが必要である。また、利用に関して「任意利用」と「必須利用」では大きくコストが変わってくるので、この点をあらかじめ整理しておくことも重要である。

事業メンバーの発言
仕様書に書くガイドラインで、利用者への強制力についてご意見はありますか？
私が勤めている大学でも、クラウドで使う時のセキュリティ分野でのガイドラインを決めて学内に通知している。今はガイドラインレベルであるが、今後問題が発生すれば、強制力のあるものに変えることを想定している。ますは、何が問題でその問題にどう対処していくべきか、はっきりわからないところが多いのでガイドラインでの提案になると思うが、活用していくことでこの辺りがはっきりしてくれば改善し、整えていきたい。
認証連携においては、学内で使う場合は学内で決めてもらえばいいが、大学間連携を行う
場合の認証は強制力を持つものになると思う。
事業メンバーの発言
インタークラウド連携ではどのレイヤを想定しているのか？との質問があったが、この点について意見はないか。
低いレイヤ、研究支援の分野から意見を述べると、現在は「京」をトップにスパコンの連携を行っているし、十数年前の大型計算機の時代から各大学間のインフラ連携は取れているので、研究支援分野におけるアカデミッククラウド利用については、あまり心配はしていない。すでに「やるか、やらないか」の決めの問題だと思っている。
489

個人的には、共有化はネットワークレベルでも、その上のレイヤでも行うべきと考えてい
るし、技術的な対応は可能となっている。特に、大学全体で BCP・DR を考えていく上では、個々の IDC 環境の効率化だけではなく、全体的な効率を考える必要があるので、ネットワ
ークのクラウド化やサービス品質の向上は必要である。また、提供側と利用側をいかにう
まく連携させていくことも重要だ。
教育支援のために、LMS とか CMS などの使用が増えてきているが、各大学間のシステムは繋がっていない。これまでの教育スタンスをどのようにデジタル化していくか十数年前から進んできたが、これからはどのような教材を効率的に開発していくかが課題。
業務の統一が一番の課題。大きな大学の中では部局間でも統一できていないのが現状。しかしながら、先ほどの大学改革の話に触れるが、お金がなくなると業務改革が必須になると思うので、このアカデミッククラウド構想を基にして議論を続けることが重要だ。
事務分野に関して私立大学は経営の合理化が進んでいると思う。国立大学は、法人化 10 年を得ているが、合理化が進んでいるとは思えない。IT 化も部分的なところが多い。
全国で同じような業務を行っているある国の機関のクラウド化はうまくいっていないようだが、アカデミッククラウドはうまく連携をはかり、大学だからクラウド化ができたと言われるような、よいケーススタディを作りたいと考える。

事業メンバーの発言
運営交付金を大学改革のためにお金を使うという話が先程あった。改革には、新しいインフラが必要になるので、その意味でも我々が推進しているアカデミッククラウドが必要になると改めて感じた。この点に関してご意見等はないか。
米国政府は、クラウドを活用するメリットとしては、Efficiency Agility Invention と説明している。効率化は当たりまえだが、Agility つまりスピードアップが図れることが非常に重要としている。今あることをシュリンクするだけではなく、クラウドというある種のきっかけを利用して、あらたなイノベーションを起こすことが可能だ。
アカデミッククラウドについて、皆さんの中でのイメージが合っているのかが心配だ。アカデミッククラウドについて、よく知らない人には、大学で抱えている問題を全部解決してくれるとのイメージになっているようで、情報系の方々が考えている話とはだいぶ違った方向に進んでいるのではないかと危惧している。まずは、アカデミッククラウドのビジ
490

ョンをきちんと整理してもらい、普段から ICT を使っていない人にもわかりやすく説明す
ることが必要だ。アカデミッククラウドについては効率化だけをアピールするだけでは不十分で、それ以上のことを言わないとダメだと思う。クラウドの話をすると、人減らしのために推進しているのかとの話になり議論が噛み合わない場合もある。報告書は、これからの大学連携のやり方・在り方の中でアカデミッククラウドは必要だという点をポイント
において書くのが良いと思う。
アカデミッククラウドへの認識は、いろんなレベルの方がいらっしゃるので、わかりやすく説明する必要があることは理解しているが、我々の中でも効率化以外で何が変わるのかという議論のところではいろんな意見があり、中々旨く意見を纏めるところまでいっていないのが現状である。しかしながら、各大学のクラウド基盤を連携すれば、ものすごい数のコア数やストレージを仮想的に構築でき、これからの研究や教育支援にも柔軟に対処できる可能性があると思う。
事業メンバーの発言
次の課題として、実際にこのアカデミッククラウドを始めるとした場合、運用面をどうするのかとの課題が出てくると思うが、その点について何かご意見を頂きたい。
オペレーションをどうするのかとの問題は、ハード、ソフトを誰が持っているのかなどのライセンスや、利用する際の認証やセキュリティについてはどうするのかの組み合わせで、それらに対してどう運用するのかだと考える。正直、商用のクラウドサービスを利用して大学が欲する SLA に対応してくれれば、それで対応可能なのではないかと思う。先ほどの大学改革の話と関連して考えると、商業サービスをみんなで経済的な価格で利用することも検討してみていいのではないかと思う。また、既に大学は大型計算機センターやスパコンの横連携による運用経験があるので、そこに投資をしてクラウド基盤を作り、今までの経験を活かすことで対応できるのではないかとも考えている。あとは、文部科学省の方で、未来の情報基盤作りを行うために投資をしてもらえばいいと思う。
MIT とハーバード大学がそれぞれ 30 億円出し合い edX という無料オンライン教育サービスを始めた。社会実験の意味合いが強いプロジェクトだと思うが、関係者は 3 年ぐらいでどこまで事業レベルまでもってこられるか真剣に考えながら取り込んでいる。日本で同じよ
うなことができるような国の支援を期待したい。
今日の話を聞いていて気になっているところは、「削減」のキーワードが先行しているように思える。
「削減」の為のアカデミッククラウド実現で議論を続けてもいい結果にならないと思う。まずは目的や効果を示して、投資してもらい、その結果として削減ができたとい491

うストーリではないと旨く行かないと思う。高等教育機関の研究・教育・事務を次世代の情報基盤にステップアウトするためにアカデミッククラウドへの投資が必要で、それを行った場合、コスト削減も期待できるみたいな報告書にする必要がある。つまり、大学に「付加価値を付けるのでアカデミッククラウドが必要」というロジックで行くほうが旨くいくと思う。
マサチューセッツ州では、5 大学が共同でデータセンターを作って運用している。ここでは、大学間連携をするだけではなくて、民間企業も交えてマサチューセッツ州の IT を盛り上げる取組を行っている。大学 IT 基盤、商業 IT 基盤がシームレスにつながってお互いサービスがロックインされない環境が構築されている。人材の流れも、大学、企業と柔軟に行き来ができ、キヤリアップに繋げることができる。国の予算でプロトタイプを作り、まずは初めて見て、それから適材適所に民間のサービスも含めて利用し、実績を重ねていくことも検討したい。
既に、既存のサービスを提供している公的機関との連携も必要であり、可能だと思う。
また、大学の中で独自に事を進めていくよりも、民間と協調・共有していくことも重要と考えるし、ガラパゴスにならないように、国内だけでなく、海外動向も見つつ進めていくことが必要だと思う。
標準化というキーワードで少しコメントしたい。クラウドになるとすべてがソフトウェアだ。我々が、アカデミッククラウドを行うということは、ソフトウェア開発をすることだと認識している。我々が作ったものもオープンソースにして、世界の大学と共有していくことが非常に重要と考える。これは標準化やコスト削減にも繋がっていく。

標準化は日本の中でやっていても不十分で、海外も意識して取り組むことが必要だ。また、標準化が進んでも、技術は自分たちの中でしっかりと押さえておくことが重要で、自分たちでコントロールできる状況を常に設けておくべきだ。
文部科学省関係者
文部科学省としては、ICT を進めていくうえで、クラウドは非常に重要なものと思っている。
このクラウド化を考える上で、コスト削減の為ということは全く考えてない。アカデミッ
ククラウドが大学の在り方をすべての局面に置いて高度化に導き、ICT を共有化し、それを活かすことで、各大学の個性を見出すことに貢献できることに期待している。アカデミッ
ククラウドは、このような可能性があることを、各大学の皆様が認識してくださることが
492

必要だ。
日本は世界最高水準の IT 社会だと言っておきながら、大学の ICT 分野には十分に投資が行われていない。これから我々がアカデミッククラウド実現への予算を取るには、先生方が一枚岩になって皆で声をあげて、アカデミッククラウドが実現すると、これだけのことができるのだと言い続けることが大切である。
ICT をあまり理解していない方々に、アカデミッククラウドは、グローバルな社会で大学の機能強化を促し、競争力をつけることに貢献できる事を報告書で説明することが重要と考えている。
この委託事業で、事例も含めてお纏めていただくことによって、多く方との情報共有、共通理解が得られると思う。これからは、社会全体へ、アカデミッククラウドの必要性を働
きかけ、しつこいぐらい声をあげていただくことが重要だ。
高機能化の必要性、目的を伝えるしっかりとした報告書を作成し、我が行っている審議会も含めて幅広くアピールすれば、アカデミッククラウド実現に動いていくことが期待できると思う。
貴重な後押しのご意見、ありがとうございます。期待していただいているということで我々もがんばって行きます。それでは、時間となりましたので、これで本セッションは終了させていただきます。皆様、ありがとうございました。

493

資料 6.

最終報告会ディスカッションセッション議事録
2014 年 2 月 13 日
『アカデミッククラウド環境構築に係るシステム研究』提案
コミュニティで紡ぐ次世代大学 ICT 環境としてのアカデミッククラウド」
最終報告会 <参加者の方々も交えた、質問・意見交換会> 要旨

事業メンバー等:
岡田 義広 九州大学 附属図書館付設教材開発センター 教授
梶田 将司 京都大学 学術情報メディアセンター 教授
棟朝 雅晴 北海道大学 情報基盤センター 教授
森原 一郎 大阪大学 情報推進機構 特任教授
西村 浩二 広島大学 情報メディア教育研究センター 教授
山地 一禎 国立情報学研究所 学術認証推進室 准教授
菅沼 拓夫 東北大学 サイバーサイエンスセンター 教授
中村 修

慶応義塾大学 環境情報学部 教授

漆谷重雄

国立情報学研究所 教授 学術ネットワーク研究開発センター長

安浦 寛人 九州大学 理事 副学長 産学連携センター長 知的財産本部長
深澤 良彰 早稲田大学 理事 理工学術院 教授

最終報告会開催前に頂いた質問を読み上げた。
「大学関係機関のお客様で、例えば、外資系のクラウドインフラについて検討する
際に、セキュリティ面が不安なので利用を躊躇しているなどの話を伺いますが、
このセキュリティ面の不安を払拭するには、何をクリアすれば良いでしょうか？何かアドバイスを頂けると幸いです。」
事業メンバー等
外資系のクラウドサービスの利用を検討する際に、準拠法と管轄裁判所の取り扱いについて心配される方が多いと思う。例えば、米国企業のクラウドサービスを利用する際に、何かトラブルがあった時には、アメリカの法律に基づいて裁判を行うと契約書に明記されている場合が多い。サービスを利用する際に、交わす取り決め事が約款の承諾で済むサービ
スでも、組織として大多数の方が利用する場合、サービス提供側が取り決めについて相談に応じると謳っているものもあるので、まずサービス提供側に相談（交渉）してみることを勧める。また、チェックリストを作成して、客観的にそのサービスを評価し、何が足りていて不足しているかを把握することも不安払拭に繋がるのではないか。最終報告書では、
494

これらのチェックリストも表記する予定なので、参考にしてくださればと思っている。
ベンダーからは、今まで顧客と裁判をやったとこがないので、安心してくださいと説明を受けたこともある
国立大学は法人後 10 年経ったが、理事会等で大学に係るデータを海外におくことや、海外サービスの利用を検討したいなどの話をした場合、監事がどのようなコメントを出してくるかがキーになっている。監事は、文部大臣から任命されて来ているので、大学はその方の意見を重視する傾向が強い。監事から、「クラウドなどの新しいサービスを利用して、何かあった時に皆さんは責任を取れるのですよね？」と言われると、ブレーキを掛けられたような雰囲気になる。上層部は、新しいことを取り入れて、何か問題が発生した場合に、国立大学の信用を壊したくないとの思いが強く、考えが保守的になっているのが現状だ。
国として、クラウドを積極的に導入することなど方針を決めてもらえるとスムーズに事が進むと思う。
一般的に外資系のサービスは、なんとなく不安と思っているところがある。日本人の島国根性が根幹にあるのではないか。
今まで、我々は多くの海外製品やサービスを購入してきている。クラウドになったからといって海外ベンダーと契約する際に、躊躇する必要はないと思う。裁判をどこの国でやるのかは、割り切って考えてもいいと思う。先程のプレゼンの中で、海外では、ある機関が各サービスのブローカーとなり、契約窓口になっている事例の紹介があったが、日本でも知見ある方が、ブローカーとなって、大学にサービスの紹介や契約に係るお手伝いを行え
ば、安心・安全に海外のサービスでも利用できる環境が構築されていくのではないかと思う。
やはり契約事項は大切なので、アメリカもイギリスもオランダも、この仕組みでは弁護士関係の費用に一番お金を掛けているそうだ。日本でも、海外と同じような仕組みを作れば、安心・安全にコスト効果の高いサービスが使えるようになると思う。
外資系企業 1
我々の基本的な契約はワシントン州になっているが、日本では、日本の SI 事業社の方が我々の代理店となって販売して頂いているスキームが多い。つまりこのスキームでは、我々のサービスを利用するユーザは日本の SI 事業社との契約となり問題が発生した場合でも、ユーザは、日本の法律・裁判所を使うことができる。また、直接契約する場合には、個別の相談も受け付けているので、ご相談くださればと思う。
495

外資系企業 2
我々も日本でビジネスを行う際は、日本の法律の中で事業展開している。まずはご安心く
ださいと言いたい。外資はなんとなく不安？聞きなれない会社だから、というのがあるのが、そこを払拭していければ、グローバルな観点からアカデミッククラウド実現への様々な貢献ができると考えている。
事業メンバー等
次の質問です。
「アカデミッククラウドでは、ハードもアプリも国の予算で一から準備するのですか。民間で、良いアプリやサービスがあれば、民間と協業し、それらを採用することは考えられないのですか。すでに、民間でリリースしているいいサービスもありますので。」
まずお話しておきたいことは、この事業は今回の調査事業で終わります。この事業のミッションは、アカデミッククラウドを実現するには、どんな仕様が必要なのかを調査し、報告書にまとめることで、その後の予定は現時点ではございません。その理由からして、この事業終了後、アカデミッククラウドがどのような形で実現できるかは、我々のところではコメントはできないというところがありますのでご理解ください。そして、民間企業との協業との件ですが、私の考えとしては民間企業のクラウドであれ、我々がコントロール
できるのであれば、我々がインフラやアプリを所有しなくてもよいと考えています。良いものがあれば、民間のパブリッククラウドでも積極的に採用していいと思っています。
私のプレゼン資料では、既存のクラウド基盤を活用していると書いているのは、大学のイ
ンフラだけではなく、民間のインフラも含めた形で書いている。当然の事ながら、大学だ
けでクラウド基盤を組んで運用していくのは、絶対無理と思っている。
アカデミッククラウドは、大学の中で閉じた世界でなくて、民間の方にも是非加わって頂
いて、いっしょに立ち上げていく枠組みを構築するのが必要だと思う。是非、民間の方々の協力を頂きたい。
教育支援からみると、教育に係るサービスは 10 数年前にはいろいろなものがあったが、教育分野はニッチなマーケットというところもあり、独占・寡占化が進んでいった過去の経緯がある。コストメリットのある良いサービスを使用するには、民間の方々の協力が必要だと考えているが、民間企業に丸投げではいけないと思う。大学がそれらのサービスに係
り、いろんな側面からコントロールできるかが、カギだと考えている、そのためには、どのような協調関係を作っていけばいいかが課題だと思う。

496

事務支援については、アプリやパッケージにおいては民間のシステムやパッケージを使っているアンケート結果がでているので、それらを活かすために民間企業と協調しあって進めていくことが必要だと思う。規模や規定が似たような大学が集まって仕様を共有で確認し合い、教育機関向けにチューニングされたパッケージソフトなどを作り、うまく使ってやっていくのも良いのではないか。その際には、国立向け、私大向け、大小規模向けなど
複数のタイプのパッケージが必要になると思う。
大学関係者で商業クラウドをコントールすることが必要との話があったが、1 セキュリティ分野のチエックシートを作る。
2 認証連携で学認を運用していくポリシーを作る。
などの確認事項や規定を作るりそれに応じたサービスを活用していくことが、クラウドをコントロールしていることになると思う。
コース管理システム等の過去と歴史から語ると、商業のサービスを利用していると、メーカーの倒産や合併等で、サービスや商品が継続して使えないことが幾つかあった。我々も、民間もオープンソースで開発することでリスクヘッジが取れるので、開発にはオープンソースを活用することが良いと思う。
SINET でも、民間企業のサービスと VPN 接続し、セキュアな環境で大学が利用できる枠組みを設けているので、これらを利用頂くとアカデミッククラウドの幅ができてくると思う。
事業メンバー等
最後の質問ですが、「本プロジェクトは、とても有意義なプロジェクトと思いますが、今後の将来的な取り組
みの方向性等があれば教えてください、宜しくお願い致します。
」
先程も説明さしあげたが、我々のこの事業でのミッションは、アカデミッククラウドを実現するにあたり、課題と要求条件は何かを調査することです。我々としては、アカデミッ
ククラウド事業が今後も継続して、検討されていくことを期待はしてはいますが、ここで継続することに関してコメントを出すことは控えさせて頂きます。
ブローカーの話が「ありましたがこの事について、何かコメントはありませんか。
今回の調査は、今後 AXIES が高等教育の発展のために行うべき具体的なアクションアイテ
ムをクリアにしてくださったと思う。ブローカー的な動きを AXIES が行う、または民間の企業さんと手を組んで行う、どちらが良いかという構造的なところは、これから整理が必要だが、そこで発生する費用を、会員機関と共に負担していくことは可能だと思う。また、497

この活動を通じて、高等教育の未来を自分たちでコントロールしていく場を作っていくということにも繋がり、非常に高いアクティビティになるのではないかと思っている。

このようなサービスを検討するにあたり、最初にやらなくてならないことは国の支援なしにできるかというところだと思う。幾つかの大学の負担だけでできるのか疑問だし、やりたいサービスを一斉に始めることも難しいと思う。そうなると検討サービスについて優先順位をつける必要があるが、皆様はどのサービスから始めた方がよいと考えているのか。
同じような質問をある委員会でも受けた。私は、研究分野だと回答した。研究分野は、各大学間の連携ができて、今まで以上のコミユニケーションが取れることで、良質な研究成果が期待でき、クラウドのメリットを活かせると考えるためだ。
オーストラリアでの事例だが、（彼らは、ハニーポットエフェクトと表現している）クラウ
ドのインフラを揃えることが目的ではなくて、クラウドを作ることで研究者が集まってコ
ラボレーションするようなきっかけができ、それが新しいコミユニティー形成に繋がり、今後の研究やその他のところで良い波及効果が発生することがクラウドを行う本質だと思う。
インタークラウドのようなコンセプトが必要だと思う。大学でアカデミッククラウドを検討する時に、大手の商業クラウドサービスを使えばいいんじゃないのとの話になる。商業
クラウドを使う前にはテストをする必要があるので、その前段階でのトレーニングも含めてクラウドが使える環境を我々が整備することが必要だと思う。インタークラウドの中で要求事項が完結するのであればそのまま使えばいいし、足りないところがあれば、スケー
ラブルに商業クラウドと連携できる環境（インターフェース）を作ることが重要だと思う。
参加者 1
コミュニティ形成という観点から述べると、スパコンもクラウド同じだと思うが、基本的にスパコンとアカデミッククラウドの役割分担は違うと思う。研究室で少規模なデータで運用している研究は、個人レベルで運用やセキュリティを万全にしておくことは難しいところもあるから、きちんとセキュリティも運用も確保しているアカデミッククラウド基盤を将来提供していくべきだと思う。
参加者 2
ビッグデータ（オープンデータ）的な活用がいろんな形で話があった。ボリュームの大きさについては、幾つか言及があったが、Variety や Velocity については定量的に述べられ
498

ていなかったと思う。この辺りについてどのように考えているのか？
事業メンバー等
オープンデータの活用は、これから政府をはじめ進んでいくと思う。問題は、それらのデータをちゃんと使い、意味のあるものに解析できるのですかというところだと思う。アカデミッククラウドの最初のユーザは、社会学的な研究者の方々に使って頂くことがいいのでではないかと思っている。昔の大型計算機センターのイメージで、システムやセキュリティの運用は気にしなくて、抱えている本質的な研究テーマに没頭して頂けるような環境を提供できるようにするのがよい。
教育学習に係るデータを教育ビッグデータと呼んでいる。それらのデータを完全にオープンにはせずに、大学の垣根を越えてある特定のコミュニティの中でオープンデータとして扱うことによっていろんな分析ができ、そこからいろんな分野に広げていくことはできると思う。
社会科学系の方々の利用が重要だということだが、まさにそう思う。今回の委託調査で、ハーバード MIT データセンターというところを訪問してきた。そこはインフラのデータセンターでなく、社会科学の生のデータを集めて公開し、研究に活かすセンターという位置づけの組織だ。私も単なるオープンデータの取り扱いであれば、パブリッククラウドで十分だと思う。先程の話になるが、私の大学でもクラウドを運用している。しかしながら、なかなか文系の方々は、利用してもらっていない。文系の方々は、研究データが自分らの組織の中に存在することで安心感を覚えているところもあり、クラウドの利用には心理的なバリヤがあるようだ。将来、彼ら自身がデータをコントロールできるように、明示でき
れば、利用してくれる可能性が高まると思う。
競争的データと非競争的データというのがあって、これらの扱いを分けて考える必要があると思う。
Variety や Velocity を考慮しながら考えていかなくてはならないと思うが、今回のアンケートでその辺りも含めて各大学にアンケートを取っても、きちんと回答くださるか疑問に思い、アンケートには盛り込まなかった経緯がある。この辺りのデータをいかにして取得し、整理していくかは課題だと思う。
アンケートデータの経年変化については、これからも継続して掴んでいく必要がある。今後、AXIES の中で対応ができれば良い。

499

参加者 1
アカデミッククラウドならではの要素技術が出てきて、将来別の業界にも波及するような事を期待したい。少なくともスパコン・HPC の分野では、ベンダーとアカデミアの相互連携
は、次世代のスパーコンピューティングにとって欠かせない部分で。その観点から考えると、クラウド関連企業もアカデミッククラウドに携わることで、それらの経験、ノウハウ、技術を活かして何か他のビジネスに繋がってゆけるようになるのが良いのではないか。アカデミッククラウドを行うことで、産学官の相乗効果で良い効果が持てるようにしないと、全部商用クラウドを利用すればいいのではないかとの議論にいつかなってしまうことが危惧される。そのため、（繰り返しになりますが）波及効果のあるアカデミッククラウドならではの大局的なビッグピクチャーを描いておくことが肝要かと思われる。
事業メンバー等
アルゴリズム、マシーンラーニング、人工知能等の分野で貢献できるのではないかと思っている。
教育支援の立場からだと、大学の一番のミッションは人材育成だと思っている。人材育成のところで、どの様に IT が効果敵に使えるのか、追及していくのがわかるようにすることが、アカデミッククラウドを使うポイントだと思っている。
ネットワーク屋の意見としては、SDN でオープンにプログラマブルに設定できる環境や、QOSの確保や、高速にバックアップを取る仕組みなどのネットワーク的な分野で貢献したいと考えている。これらの予定している新しい取り組みでインタークラウド等を支えていき、
良い相乗効果を出していきたい。
お時間となりました。本日は、お忙しいところ多くの方にお集まりいただきまして、まことにありがとうございました。
閉会挨拶 九州大学・理事・副学長 安浦 寛人
現在の日本の大学において IT がどのような時に使われていて、それらを今後アカデミック
クラウドで、どのように纏めていくべきかの方向性を見極めるベースとなる、非常に貴重なデータを、ここにいる先生方が中心になり、かなり厳しい仕事をしてくださっている。
今回の調査データは、今後の学術基盤の方向性を決めていくにおいて貴重なデータになるのは言うまでも無いが、まだまだ足りない部分もあると思う。その辺は、今後 AXIES 等で引き続き作業を続けていき、より精度の高いデータにしていきたいと思っている。最終的には、1 年か 2 年の間に国民の皆様にもわかりやすい形で、アカデミッククラウドを提示す500

ることが一つのミッションだと思っている。
国の施策の中に、世界のトップ 100 大学の中に日本の大学を 10 校入れる目標があるが、それを実現するにはいろんな分野の研究基盤としてアカデミッククラウドをいい形で整備していく必要があると考えている。
教育分野では、これからきわめて急速に高等教育のあり方が変わってくることを予想しており、MOOCs などに代表されるような、新しいコンテンツを使った教育に、このアカデミッ
ククラウドが使われるようになると、ネットワーク分野にも今までと違った要求が出てくると考えられる。この日本の高等教育を支える上では、財政問題という大きな課題があるが、少なくても国立大学の業務の効率化においては民間に比べてかなり遅れており、そこに対して、支援していくことがアカデミッククラウドの役割として重要だとの確認が、今日の報告会の中で出来た。
一般企業とは違う教育・研究という業務を行っている大学が IT をいかによく活用していけばいいのか、大変お忙しい中、大変ご苦労されて、いろいろな角度から調査していただいた、先生方に心から敬意を表したい。是非、多くの方々に道しるべを示すような報告書にしていただきたい。

501

資料 7.

アドバイザリー名簿

お名前

組織名

部署

林 雅之

NTT コミュニケーションズ株式会社

クラウドサービス部

望月 悟

日本電気株式会社

滝島繁則

伊藤忠テクノソリューションズ株式会社

公共システム第２部

山下克美

ファルコンシステムコンサルティング株式会社

営業本部

吉荒祐一

アマゾンデータサービスジャパン株式会社

技術統括本部

藤田 正典

三菱商事株式会社

システム総括部

伊賀野 康生

ベライゾンジャパン合同会社

プロダクト企画部

桑原 しん子株式会社日立製作所

川口 洋

株式会社ラック

文教・科学ソリュー
ション事業部

公共システム営業統
括本部
JSOC 事業部

本事業の推進において、上記アドバイザリー委員の方々から数多くの貴重なご意見等をいただきました。お名前を挙げさせて頂くとともに、感謝の意を表します。

502

用語集

503