学術情報処理研究 No.22
2018年9月

原著論文

徳島大学における安否確認サービスの設計・開発と訓練結果
Design, Development and Training Results of Safety Confirmation
Service in Tokushima University
板東 孝文, 松浦 健二, 八木 香奈枝, 佐野 雅彦
Takafumi BANDO, Kenji MATSUURA, Kanae YAGI, Masahiko SANO
{bandou.takafumi, ma2, yagi.kanae, sano}@tokushima-u.ac.jp
徳島大学 情報センター
Center for Administration of Information Technology, Tokushima University概要
徳島大学（以下，本学）の所在する徳島県は発生確率が高いとされる東南海・南海地震の被害が懸念されており，大規模災害を想定した事業継続計画（BCP）の策定と，その実施が重要である．その一環として，情報センターでは，本学における安否確認プロセスの統括的立場である総務課と連携し，構成員安否確認サービスを見直し，再設計，開発を行った．また，平成 28 年度および平成 29年度に全学構成員を対象とした安否確認訓練を実施した．これらは，被災時に本学構成員の安否確認が，迅速かつ簡潔に実施される事により，事業継続性が向上されることを目的としている．本論文
では，サービスの概要，安否確認訓練の実施結果と改善課題について述べる．

キーワード

BCP，安否確認，防災訓練

1

はじめに

究の事業継続性のためには，情報システムのみならず，構成員の状況を適切に把握するための安否確認の仕組

平成 23 年に発生した東日本大震災以降，BCP の重要みが必要である．

性はより高まっている．本学の所在する徳島県において一方で，従前の安否確認プロセスにはいくつかの懸念は，南海・東南海地震による大きな被害が予想されてい点が存在した．安否確認の手段が学生・教職員で分離しる．そのような背景の下，本学では，南海・東南海地震ており，一括した仕組みが存在しなかったことに加え，による被災を想定した BCP が策定されている [1]．ま安否情報の収集は外部のアンケートサービス，その集計た，情報センターでは BCP 対策の一環として，本学のは Microsoft Access，OneDrive など，複数の外部サー情報システム全体の可用性の向上を目的とし，基幹系情ビスに依存しており，一連の工程が煩雑であった．よっ報システムの整備 [2] を行った．加えて，整備した設備て，訓練時の応答率も低く，安否確認プロセス自体の認の有効性を確認するため，情報センターで運用している知度も低い状態であった．さらに，外部サービスへの依ISMS（ISO/IEC 27001）に従い，有効性測定のテスト存度の高さから，プロセス単位での改善も難しい状況で[3] を行った．

あった．そのような状況により，統括的な観点からの再このように，情報センターでは情報システムの設備面設計による，安否確認プロセスの整備が本学の大きな課での BCP 対策を実施してきた．これらの取組みは，主題であった．そして，そのプロセスは情報システム面でに被災時または被災直後の情報システムへの影響を低の BCP を十分に考慮して検討されるべきであり，情報減するためのものである．加えて，大学における教育研センターにおける BCP 対策の一部として位置づけ，対- 111 -ウェア品質を上げるとともに，情報センターの組応することが適当である．

織としての保守性を向上させることを目的とした．

そこで，情報センターでは平成 28 年度に，安否確認プロセスを統括する総務部総務課と協議し，本学独自の安否確認サービスの設計・開発を行った．また，同じく(2) 操作性

総務部総務課と連携し，平成 28 年度および平成 29 年

被災時に，操作手順を参照する物理的・心理的な余度に全学を対象とした訓練を実施した．実際に全学対裕を持つことは困難であると想定される．よって，象の訓練を行う事により，机上の想定や課内の訓練で発安否確認サービスには各担当者，構成員に対して生しなかった問題が発現した場合には，その対応策を検複雑な操作手順を要せずとも直感的かつ簡潔に使討する事もできる．また，安否確認対象の各構成員に対用できる，簡潔な操作性が要求される．そのため，しても，安否確認サービスそのものの認知度の向上や，安否確認サービスは，一般的な情報端末から Web操作手順の周知につながることにより，被災時におけるアクセスし，極力少ない工程で利用できる設計と安否確認プロセスがより適切に行われる事が期待でき，した．利用できる情報端末は，PC，スマートフォ

大学の事業継続性の向上に繋がる．本論文では，設計・ンのほか，フィーチャーフォンも想定している．

開発した安否確認サービスの仕様・構成とその訓練結果について述べる．

2安否確認サービス

2.1

目的

2.2

概要
਍౯નੳ૿ਊ঻ϱ͘ๅࠄ

安否確認サービスは，災害発生時もしくは，災害発生৖ଂ૿ਊ঻

ઈ৷૿ਊ঻ϰ͘҈൳৚ๅॄ‫ܯ‬ϭ͘҈൳֮೟ϟʖϩૻ৶ࣰߨ

から一定時間の経過後や防災訓練時など必要と認められた際に，担当者が本学構成員の安否状況を迅速に把握し，集計することを目的としている．ここでの安否状਍౯નੳ崝嵤崻崡

況とは，各構成員の身体的状況，所在場所を想定する．
その目的のため，以下に挙げる観点からシステム設計をϯ͘҈൳৚ๅ೘ྙ

行うことにした．

(1) 可用性Ϯ͘҈൳֮೟ϟʖϩૻ৶ଡਛ৩

安否確認サービスは，大規模災害発生時に利用する．そのような状況下でも安定して稼動する，高い可用性がシステム，サービスレベルで要求され

図- 1: 安否確認サービス概略図

る．システムレベルでの可用性を実現するため，外部業者が管理するデータセンター内に設置している，仮想化基盤上の仮想サーバとして実装していサービスの概略図を図-1 に示す．安否確認サービスにる．サービスレベルでの対策としては，当サービス

おいて，安否情報の収集は本学構成員に付与されているは Nagios[4] による外部からの監視を行っている． アカウントに紐付くメールアカウントを利用して行う．
また，サーバにインストールされたログ監視ツー 災害発生時，図-1 における運用担当者が安否確認サー
ルがアプリケーションレベルでのレポートメール

ビスに Web アクセスし，安否確認メールの送信を実行を日次で送信し，それを情報センターの共通メーする．各構成員は，受信したメールの本文に記載されてルアドレスで受け取っており，異変を察知しやすいいる，構成員ごとに一意な URL より安否確認サービス環境となっている．また，安否確認サービスが構築に Web アクセスし，自身の安否情報を入力する．入力

された仮想サーバと同一機能を持ったミラーサー

された情報は安否確認サービスのデータベースに蓄積バを作成しており，ホットスタンバイさせている． され，担当者が任意のタイミングで参照できる．なお，メインサーバに不具合が起こった際に，切り替えて 担当者は，運用担当者，部局担当者の 2 種類に分類され運用できる仕組みとした．加えて，開発時や改修時る．それぞれの実行権限を以下に示す．には，有識者数名によるコードレベルのレビューを行った．これは，安否確認サービスに対し，ソフト• 運用担当者– 安否確認メール送信- 112 -

– 安否情報照会（全件）

事務システム，人事給与システムが保有する学生・教職– 部局担当者の集計対象部局編集員の構成員データを取得する．また，安否確認サービス
は Web サーバ機能，データベースサーバ機能，メール– マスタメンテナンス

サーバ機能を全て同一のサーバ上に構築している．加• 部局担当者

えて，そのサーバと同じ機能を有するミラーサーバをホットスタンバイする事により，可用性を高めている．

– 安否情報照会（対象部局）

また，週次の処理としてサーバログを，日次の処理とし部局担当者は，運用担当者によって設定された自身のてデータベースデータをバックアップサーバに保存して担当部局の安否情報を集計し，運用担当者に報告する． いる．
なお，部局担当者からの運用担当者への報告は，現状では試験的な運用を行っており，今後改善を検討する予定である．部局担当のアカウントは，運用担当者が任意で2.4

ソフトウェア構成追加・削除が可能となっている．

2.3

表- 1: ソフトウェア構成
OS
Ubuntu 16.04

システム構成崕嵋嵛崹崡$崕嵋嵛崹崡%'&崕嵋嵛崹崡&Web

Apache/2.4.18

ScriptDatabase

PHP 7.0
PostgreSQL 9.5.8

Mail

Postfix 3.1.0

安否確認サービスのソフトウェア構成図を表-1 に示যহஔଖ崟崡崮嵈ઇਜহਜ崟崡崮嵈

す．コスト面，カスタマイズ性を考慮し，OSS での実崸崫崗崊崫崿崝嵤崸装とした．また，開発言語である PHP 7.0 においてはଡਛ৩ੲਾ‫ق‬ઇ૙৩‫ك‬ਗ৖'&ଡਛ৩ੲਾ‫৾ق‬ে‫ك‬

構成員管理システム

メンテナンス性や継続性を考慮し，特定のライブラリや崕嵋嵛崹崡ੲਾ੦ೕ崟崡崮嵈

フレームワークは使用していない．

2.5/'$3崝嵤崸

対象

安否確認サービスの対象である本学構成員とは，前述

ଡਛ৩ੲਾ
ෘ୳৲੦ೕ

した安否確認サービスの最上位連携システムである教務事務システム，もしくは人事給与システムに構成員データが存在する人物を示す．教務事務システムとは本学に'%崯嵤崧
崝嵤崸嵕崘

おける学生の最上位構成員管理システムであり，本学の਍౯નੳ崝嵤崻崡

情報システムを利用できる全ての学生の構成員データを保持している．すなわち，正規学生に加えて，科目等ম崟崡崮嵈ใோ崟崡崮嵈

履修生などの非正規学生なども対象とした．また，人事給与システムとは教員，職員の最上位構成員管理システムである．その管理対象は一般的な常勤の教職員以外も図- 2: 安否確認サービス システム構成図

含め，本学の情報システムを利用できる全ての教職員である．よって，これらのシステム上での登録者を安否確認サービスの対象者とする事で，本学が安否を確認する
安否確認サービスのシステム構成図を図-2 に示す．安

べき構成員を網羅的に対象とすることができる．

否確認サービスでは，連携対象システムから構成員デー

ただし，教職員については，本務が本学以外にある方タを定期的に取得している．直接の連携元は，情報セや，退職者のうち称号のみを有している方などは対象ンターが所掌している，本学の教育・業務環境の基盤と外とするため，節 3.1.2 で述べるように除いて運用してなるキャンパス情報基盤システムである．加えて，キャいる．

ンパス情報基盤システムの上位の連携対象として教務事務システム，人事給与システムが存在する．安否確認サービスは，キャンパス情報基盤システムを介し，教務- 113 -2.6

他大学における安否確認システム

テムにおける相違点をまとめる．本学の安否確認シス

他大学においても，BCP の観点から災害時における安否確認は重要課題であり，各大学に適応したシステムが開発・運用されている．本節では，他大学の安否確認システムと，本学の安否確認サービスにおける相違点，その見解について述べる．
静岡大学では，統合認証システムとの認証連携や，構テムは，他システムとの連携を行う設計となっているた
め，独立型の静岡大学 [5] や組込型の名古屋大学 [6] と比較すると，設計・開発のコストは高くなる傾向にあると言えるが，安否確認システムに要求される可用性，機密性，操作性に配慮し，なおかつ既設の情報システムを適切に利用した設計が実現できている．

成員情報の取得・蓄積など，学内設置の他のシステムと表- 2: 安否確認システムの比較
タイプ
構成の連携を排除した安否確認システムが提案されている[5]．そのため，安否情報を収集するための構成員情報

静岡を所有せず，各構成員が自身の安否情報をサービスへ自大学発的に入力することで稼動する，プル型のシステムとし名古屋て構成されている．また，他のシステムとの連携を考慮大学する必要が無いため，可用性確保のためのシステムの遠

徳島

隔地への設置や，クラウドサービスへの移転が比較的容大学易である．一方，名古屋大学では，高度な統合認証環境

プル型

独立型

プッシュ型

組込型

プッシュ型

連携型

特徴

構築環境への依存性が低い
一定の可用性・機密性が担保されている
可用性・機密性・操作性に配慮し設計されているや学内ポータルサイトなど，情報連携のための基盤を活かした安否確認システムが提案されている [6]．名古屋
大学の安否確認システムは，大学ポータルが所有する構成員情報を利用し，各構成員に応答を促すメールを送信する，プッシュ型のシステムとして構成されている．
また，安否確認システムが大学ポータルに組み込まれることにより，ＩＤ管理や個人情報保護への対策など，適3

安否確認サービス実装機能

3.1

構成員情報取得

3.1.1

取得項目

切なシステム基盤の下での安否確認が実現されており，可用性，機密性が担保されていると言える．

サービスに必要な構成員情報を取得する．この処理は，日次処理として行われる．図-2 で示したように，安本学での安否確認サービスにおいては，サービスから否確認サービスの構成員情報取得処理において，安否構成員に応答を促す，プッシュ型のシステムとすること確認サービスが直接参照するのは LDAP サーバである．

が望ましいと考えた．それは，本学においては安否確認

ldapsearch コマンドで取得されたエントリを文字列解の仕組みが根付いておらず，より迅速な安否情報の集計析し，データベースに格納する．取得する情報の一覧をを行う上で，プル型の実装は適切ではないと判断したた

以下に示す．

めである．プッシュ型の実装を実現するため，図-2 のように構成員管理システムと連携し，構成員情報を取得
項目名している．また，外部のデータセンターにサービスを構

表- 3: 構成員情報
説明

築することにより，他のシステムとの連携を行いつつ，アカウント ID

ユニーク ID可用性に配慮した．

職種

教員，職員，学生の分類加えて，安否確認サービスは，既存の情報システムか部コード所属大分類ら独立したシステムとして設計されている．これは，安課コード

所属小分類

否確認サービスは被災時に利用するサービスであり，可名前（日）日本語名

用性，完全性，機密性の重要度が，平常時に使用するシ

名前（英）

英語名

ステムとは異なり，独立設計とするのが適当と考えたためである．また，情報セキュリティの観点からも，サービスに必要な最低限の情報のみを取得することにより，個人情報にも配慮した設計となっている．例えば，安否

3.1.2

除外リスト

確認サービスは構成員のメールアドレスを必要とする

安否確認サービスが取得する構成員情報の大もとでが，本学管理のメールアドレスは，ユーザ ID からも生ある人事給与システム，教務事務システムにアカウント成可能なため，私的なメールアドレスなどは取得する必が存在するが，安否確認サービスの対象とならない構成要がない．

員に関しては，安否確認サービス用の除外リストを作成

表-2 に，本節で述べた他大学と本学の安否確認シスし対応している．例えば，非常勤講師や一部の名誉教授- 114 -

がこれに該当する．この除外リストは，情報センター職各災害ごとに独立した集計を行うことができる．なお，員が月次の作業としてメンテナンスを行っている．安否ここでの削除は論理削除であり，データベースには過去

確認サービスは，構成員情報取得時に除外リストに含まの安否情報が蓄積されている．
画面中央部のテキストボックスに送信されるメールれるアカウント情報を取得しない．のテンプレートが表示されている．運用担当者がこの

3.2

安否確認メール送信

3.2.1

認証

テキストボックスを編集する事により，送信内容を任意で変更できる．また，メールの本文中に一定期間有効な，構成員ごとに一意な応答用 URL を挿入する．応答

運用担当者，部局担当者は安否確認サービスにログインするため，ID・パスワードを入力し，認証を行う．

用 URL はメールを送信するタイミングで無作為な 64バイトの英数字による文字列によって生成される．

運用担当者の権限を有するアカウントでログインする
ことにより，Web インターフェースから安否確認メー

3.3

安否情報入力ルの送信を行える仕組みとなっている．安否確認サービスの ID は，情報センター管理の情報システム全般で利用されているアカウントとは異なり，独立した固有のアカウント管理構成となっている．これは，運用担当者，部局担当者の異動・交代による引継ぎを考慮しているためである．独立したアカウント構成とすることで，任意のタイミングでのアカウントのメンテナンスを実現している．

3.2.2

メール送信

図- 4: 安否情報入力画面

安否情報入力画面を図-4 に示す．構成員が受信したメールに記載されている URL にアクセスした場合，安否情報入力画面に遷移する．その際，URL を解析して，構成員を特定する．URL が不正な値だった場合や，該当する構成員が存在しない場合，応答期限を過ぎていた場合は，エラー画面へ遷移し，安否情報の入力を行うこ
図- 3: メール送信画面の例とはできない．なお，URL より個人を識別できることに加え，本人以外からの代理応答も想定に含めているた

メール送信画面を図-3 に示す．
『安否確認メール送信』
ボタンを押下すると，確認のダイアログが表示され，安否確認メールの送信が開始される．また，メールの送信処理中に新たにメール送信がされないように制御されている．
『システムリセット』ボタンを押下すると，現時点で入力されている安否情報が削除される．これは安否情報の集計が完了した際に押下する事を想定しており，め，応答時に別途クレデンシャル入力を要する認証は行わない．なお，安否確認サービスにおける Web のイン
ターフェースは，原則，HTTPS プロトコルによるアクセスのみを許可しているが，SHA-2 のサーバ証明書に対応できないフィーチャーフォンからの応答も想定しているため，安否情報入力画面のみ HTTP プロトコルによるアクセスも許可している．

- 115 -

安否情報を入力し，『入力内容の確認』ボタンを押下することにより，確認画面を経由して安否情報がサービスへ登録される．なお，必須入力項目は安否状況のチェックボックスのみであるため，最短では『入力内容の確認』ボタン押下のみで登録できる．これらの登録作
業は応答期限内であれば何度でも可能であり，管理者は登録された安否情報の時間的な変化を追跡可能である．

3.4

安否情報照会画面

3.4.1

CSV 出力図- 6: 集計部局編集

4.1.1
図- 5: 安否情報照会画面

平成 28 年度訓練計画• 条件– 実施日：平成 28 年 12 月 16 日（金）安否情報照会画面を図-5 に示す．運用担当者，部局– 17 時以降に安否確認メールを全学構成員に担当者は，安否情報照会画面から入力された安否情報を送信照会できる．
『安否情報出力』ボタンから入力された安否情報の一覧を，『安否情報未入力者一覧出力』から安– 集計期間は 1 週間

否確認情報が入力されていない構成員の一覧をそれぞ– 実施時刻の全学周知

れ CSV ファイルで出力できる．

3.4.2• 訓練内容– 安否確認メールの送受信

集計対象部局編集– 構成員による安否情報入力

2.2 節で示したとおり，安否情報照会画面の CSV 出– 運用担当者による集計

力機能は運用担当者アカウント，部局担当者アカウントを問わず利用可能だが，照会の対象となる部局は運用担当者が各アカウントに設定した集計対象の部局の構成員のみとなる．運用担当者は，図-6 に示すとおり，アカウント管理画面の『集計部局編集』ボタンより，選択したアカウントの集計対象となる部局をチェックボック
スで制御できる．集計部局編集画面では，一覧表示されている部局から対象の部局を選択しやすくなるように，選択した部局が着色される仕組みを実装している．

平成 28 年度の訓練は，安否確認サービスの初期開発が完了後，全学を対象とした初めての安否確認サービスの訓練となった．訓練前には，日程の全学周知を行った．これは，安否確認サービスの運用が開始されたことの認知度向上も目的としている．また，業務時間外の応答も可能とするため，本学管理のメールアドレスから，業務時間外にも参照可能な本学管理外のメールアドレスへの安否確認メールの転送設定の方法の周知を併せて行った．業務時間外に安否確認メールを受信した場合

4

安否確認メール送受信訓練

4.1

訓練計画

でも応答することを意識づけるため，金曜日の業務終了時間以降を実施時刻とした．

総務課主導の下，平成 28 年度，平成 29 年度に安否4.1.2確認メールの送受信訓練を行った．それぞれの訓練実施計画を以下に示す．

平成 29 年度訓練計画• 条件– 実施日：平成 30 年 1 月 26 日（金）- 116 -

– 17 時以降に安否確認メールを全学構成員に送信– 集計期間は 1 週間– 実施期間の全学周知 (1 月下旬)
• 訓練内容– 安否確認メールの送受信– 構成員による安否情報入力– 部局担当者による集計・報告

図- 7: 平成 28 年度 1 時間あたりの応答数と累計応答率– 運用担当者による集計(144 時間以内)

平成 29 年度の訓練は，平成 28 年度の訓練時に運用担当者から挙がった追加要望の一部（節 3.1.2，節 3.4.2）に関する機能追加を行い，その試験を兼ねて行った．平成 28 年度の訓練が具体的な日時を周知して実施したのに対し，平成 29 年度の訓練はおおよその日程のみを周知して実施した．実際に訓練を行った日時は，平成 28年度と同様に金曜日の業務時間以降である．よって，平成 28 年度の結果と平成 29 年度の結果を比較することにより，実施する日時の周知の影響を確認すると共に，より実運用に即したケースでの応答数が集計できると考えた．また，構成員の安否情報入力に関しては，入力

図- 8: 平成 28 年度 1 時間あたりの応答数と累計応答率（24 時間以内）

画面の文言の修正等を行ったが，昨年度と大きな相違点は無い．加えて，平成 29 年度の訓練より，各部局の担当者による部局毎の集計と報告を試験的に行うため，各部局の担当者に安否確認サービスの利用アカウントとパスワードを配布し，集計のマニュアルを作成，周知した．

4.2

訓練結果

4.2.1

平成 28 年度訓練結果

図- 9: 平成 28 年度 1 時間あたりの応答数と累計応答率（24 時間-144 時間）

表- 4: 平成 28 年度 応答数
応答数
総数
応答率
教員

589

1,026

57.4 %

職員

1,305

3,583

36.4 %(2,486)(52.5 %)

学生

1,811

7,832

23.1 %

全体

3,705

12,44129.8 %(11,344)(32.7 %)

表-4 に平成 28 年度訓練時の応答数を，図-7 から図-9に 1 時間あたりの応答数と累計の応答率を示す．なお，
次節 4.2.2 で詳細を述べるとおり，平成 28 年度の訓練
では，本来対象外となるべきアカウントが構成員情報に含まれていた．よって，そのアカウントを手動で削除した集計結果を，表-4 の括弧内で示す．
教員，職員に関しては過半数からの応答があったが，学生に関しては四半に満たない結果となった．全体としては，32.7%の応答率となった．
安否確認メールの受信時刻は，メールサーバの処理順序により最大 1 時間程度のばらつきがあったと考えられるが，訓練開始直後の応答数が最も多かった．しかし，休日である訓練翌日 0 時 00 分〜翌々日 23 時 59 分
においても，全体応答数の 1 割程度である 354 件の応- 117 -答があった．また，訓練の次業務日以降にも，一定の応答数が得られた．特に，職員においてその傾向が顕著であった．これは，各職員の業務における，メール処理のタイミングと一致した結果ではないかと考える．これらの構成員に関しては，業務時間外に安否確認メールを受け取った場合の対応に関して，改善の余地があると言える．

4.2.2

平成 28 年度訓練における課題

本学における安否確認手順上，本来は非常勤講師は対象外とするべきであったが，メールの送信対象に職図- 10: 平成 29 年度 1 時間あたりの応答数と累計応答率 (144 時間以内)員として含まれている事が分かった．安否確認サービ
スが参照する LDAP サーバにおける構成員の属性情報
では，非常勤講師を区別することが困難となっている．
来年度以降の課題とした．なお，平成 29 年度の訓練時
では 3.1.2 節にて述べた機能により，実現している．また，安否確認メールの対象となるのは個人アカウントであり，役職アカウントには送信されない．その周知が徹底されていなかったため，平時に役職アカウントを利用し，個人アカウントを利用していない構成員から安否確認メールが届いていないという問い合わせや，普段利用していない個人アカウントのパスワード有効期限が切
図- 11: 平成 29 年度 1 時間あたりの応答数と累計応答れてしまっているという問合せがあった．
安否確認情報の入力においては，入力内容確認画面率（24 時間以内）の表示で入力フローが終了したと勘違いし，結果，安否確認サービスに情報が送信されなかったケースが報告された．このようなケースに対して，実画面の文言の変更と，強調文字により注意書きを追加することで対応した．さらに，本学では平成 28 年度末に，教職員のメールサービスがオンプレミスの Exchange Server から Oﬃce365 Exchange Online にリプレース予定であった．そのため，メールの転送設定のマニュアルを改訂し，周知を再度行う必要があった．

4.2.3

平成 29 年度訓練結果

図- 12: 平成 29 年度 1 時間あたりの応答数と累計応答率（24 時間-144 時間）

表- 5: 平成 29 年度 応答数
応答数
総数
応答率
教員

627

1,026

61.1 %

職員

1,440

2,474

58.2 %

学生

1,448

7,733

18.7 %

全体

3,515

11,23331.3 %

表-5 に平成 29 年度訓練時の応答数を，図-10 から図-12 に 1 時間あたりの応答数と累計の応答率を示す．平成 29 年度の訓練は，具体的な実施日を通知せずに行ったが，平成 28 年度と同様に訓練開始直後の応答数が最も多い結果となった．しかし，平成 28 年度と比較すると翌業務日の回答が増加しており，これは実施日の通知の有無に起因していると考えられる．全体的な傾向としては，前年度から大きな変化は無かった．

- 118 -

4.2.4

本学においても，サービスの機能や全学周知による応答

平成 29 年度訓練における課題

Oﬃce365 Exchange Online 側のフィルタリングによの督促に関する方法を検討したい．

り，迷惑メールとして判定され，配信されないケースが3 件あった．こちらは発生件数からは稀であると言えるが，原因を含め対応を検討中である．また，各ユーザの5おわりにメーラーが迷惑メールと判定するケースもあった．この

本論文では，安否確認サービスと設計・開発，実際に場合は，メーラー毎の設定変更方法を周知することで対安否確認サービスを稼動した訓練とその結果について応予定である．

述べた．

また，安否確認サービスが送信したメールが，受信し実施された訓練で，安否確認サービスは計画通りにた構成員にフィッシング詐欺と誤認されたケースがあっメールを送信し，構成員からの応答を収集することがでた．これに対し，送信されるメールに電子署名を付与きた．訓練時，平時共にトラブルは起こっておらず，現し，その署名をもってメールを真正なものと判断可能と時点では高い可用性を実現できているといえる．また，する対応を検討中である．しかし，電子署名を検証でき運用担当者，部局担当者や構成員からは操作方法が不明

るかどうかはメーラーの機能に依存するため，全ての構瞭であるといった意見は出ておらず，容易な操作性を実成員をフォローすることはできず，別途の対策も検討す現できていると考える．
さらに，訓練の実施によって発見された安否確認サーる必要がある．

ビスの具体的な課題に関しても，一部（4.2.2 節）につ

4.2.5

いては，機能の追加によって対応できた．平成 30 年 5応答率の比較月時点で対応できてない課題（4.2.4 節，4.2.5 節）に関しては，対応の可否も含め今後の検討課題である．

表- 6: 応答率の変化
平成 28 年度 平成 29 年度

導入当初からの継続的な課題として，応答率の改善が増減挙げられる．繰り返し訓練を行う事により認知度をあげ

教員

57.4%

61.1%

3.7%

るとともに，周知の方法も考慮していかなければなら

職員

52.5%

58.2%

5.7%

ない．また，サービス単独での訓練ではなく，情報セン

学生

23.1%

18.7%

−4.4%

ターが取り組む他の BCP 施策 [1][2] と併せた訓練を行

全体

32.7%

31.3%

−1.4%

い，より実践的な形で，情報センターとしての BCP の改善に取り組む必要がある．

表-6 に，平成 28 年度と平成 29 年度の応答率の比較表を示す．平成 28 年度の結果は，4.2.1 節で述べたように，一部のアカウントを集計対象から手動で削除した結果である．教員，職員に関しては応答率が上昇しているが，学生の応答率は減少しており，全体としては悪化している．これは，教員，職員の応答数の増加分よりも，人数が支配的な学生の応答数の減少分の影響を大きく受けているためである．また，前述しているとおり，平成 28 年度は具体的な日程を，平成 29 年度はおおよその日程を周知していた．そのため，2 回目の訓練である事を考慮しても，応答率は減少すると考えていたが，教また，今後の発展的な課題としては，安否確認サービスを本学の情報資産としてどのように応用していくかという事も挙げられる．本論文では，安否確認サービスは大規模災害時の利用を想定して設計されているが，機能としては汎用的な緊急連絡応答サービスである．他大学の文献では，緊急時連絡システムを地震のみならず，洪水やインフルエンザなど，多用途に利用する実例がある [7]．本学の安否確認サービスにおいても，メール本文や安否情報入力画面のテンプレート差替え機能を実装することにより，よりサービスを有効活用する方法を検討していきたい．

員，職員に関しては予想に反する結果とった．よって，教員，職員に関しては安否確認サービスの周知，訓練結果の広報などが一定の成果を得ていると言えるだろう．

謝辞

学生の応答率の減少に関しては，要因を分析し，適切な安否確認サービスの設計・開発と訓練実施にあたり，対策を行う必要がある．平成 30 年度現在，その対策の徳島大学総務部総務課の皆様には多大なご助言，ご助力

1 つとして，学生支援課と連携し，学生生活の手引きにを頂きました．深く感謝申し上げます．

安否確認サービスに関する項を追加している．また，他
大学の文献より，応答率の上昇のためには未応答者への定期的な応答の督促が有効であるという結果がある [7]．

- 119 -参考文献

[5] 長谷川 孝博，井上 春樹，八卷 直一 “低コスト運用でユーザフレンドリな安否情報システム，” 学術情[1] 粕淵 義郎，中野 晋， “国立大学法人における巨大報処理研究 Vol.13, pp.91–98, 2009．

災害時事業継続のあり方，” 土木学会論文誌 F6(安[6] 林 能成，梶田 将司，太田 芳博，若松 進，木村 玲全問題)，Vol.68, No.2, pp.58–65, 2012．

欧，飛田 潤，鈴木 康弘，間瀬 健二 “組織特性を考[2] 松浦 健二，上田 哲史，佐野 雅彦，関 陽介，松村慮した大学向け災害時安否確認システムの開発，”

健，八木 香奈枝 “徳島大学における情報システム

安全問題研究論文集 Vol.3, pp.203–208, 2008．

BCP 及び非常時のワイヤレスアクセスラインの整備，” 学術情報処理研究 Vol.18, pp.99–107, 2014．

[7] 二木 恵，東 昭孝，村田 記，笠原 禎也，高田 良宏，[3] 佐野 雅彦，松浦 健二，上田 哲史，八木 香奈枝 “徳島大学における情報システムの BCP テスト結果と課題，” 学術情報処理研究 Vol.20, pp.119–127, 2016．

[4] Nagios - The Industry Standard In IT Infrastructure Monitoring, https://www.nagios.org/- 120 -

森 祥寛，松平 拓也，大野 浩之 “金沢大学における緊急時連絡システム (C-SIREN) の整備と運用，” 大学情報システム環境研究 Vol.19, pp.55–66, 2016．