京都大学安否確認システムの開発と訓練結果
宮部 誠人，戸田 庸介，荒谷 裕美，渥美 紀寿，古村 隆明，永井 靖浩
京都大学 情報環境機構
e-office@mail2.adm.kyoto-u.ac.jp
Development and training results of“Safety Confirmation System, Kyoto University”
Makoto Miyabe，Yosuke Toda，Hiromi Araya，Noritoshi Atsumi，Takaaki Komura，Yasuhiro Nagai
Institute for Information Management and Communication, Kyoto Univ.
概要
京都大学では，自然災害や，パンデミック発生等の緊急時に，大学構成員の安否状況を円滑に，かつ迅速に把握することを目的とした安否確認システムの構築を 2016 年度に行った．本稿では，安否確認システムの開発と 2017 年度に行った全学訓練の結果について紹介し，今後の展開について報告する．

はじめに
京都大学（以下，「本学」という）では自然災害や，パンデミック発生等の緊急時に，大学構成員の安否状況を円滑に，かつ迅速に把握することを目的とした安否確認システム（以下，「本システム」という）の構築を 2016 年度に行った．
また，2017 年度には，実際の災害を想定して，教職員，学生を対象にした全学訓練を行った．
本稿では，本システムの概要，安否確認の流れ，各種機能，全学訓練の結果について紹介し，

図 1 安否確認システムの構成

現状の課題と今後の展開について報告する．
安否確認システムについて
2.1 システム概要
本システムは，緊急事態の発生時に，本学構2.2 安否確認の流れ
本システムは本学の学生・教職員（派遣職員は除く）が利用者として登録されており，以下の5 つのロールを割り当てることが可能である．
 システム管理者（情報環境機構の担当教成員の安否状況を大学側が迅速に把握することを職員）目的としたシステムである．災害が発生すると，

 全学管理者（総務課の担当掛職員，危機本学構成員はスマートフォン，タブレット，PC対策本部要員）

等の Web ブラウザから本システムへログインし，安否状況を登録する．全学・各部局の担当者

 部局管理者（主に部局長，部局の総務・は，PC の Web ブラウザから本システムの管理画防災担当等の職員，部局対策室要員）

面へログインし，構成員の安否状況を確認・集 部局作業者（主に部局の教職員）計・代理入力することが可能である．また，安否 構成員（教職員・学生等）状況の登録を依頼するために構成員へメールを一斉送信する機能を有している．

基本的な安否確認作業手順は下記のとおりである．
1.

全学管理者は安否イベントを起動し，安否状況の登録・確認作業を可能な状態にする．

2.

全学管理者が通知メールの文面を作成し，構成員へ一斉送信する

3.

構成員は，スマートフォン，タブレット，PC 等の端末から本学 Web サイト，教職員ポータルサイト，学生ポータルサイト等を経由して本システムへアクセスする

4.

構成員は，全学 ID を用いて本システムに認証し，安否状況登録を行う

5.

部局管理者は，何らかの理由でシステムから

図 2 安否状況登録画面（PC）

入力ができない構成員から連絡があった場合に，安否状況の代理登録を行う
6.

全学管理者・部局管理者・部局作業者は安否状況の確認・集計を行う

7.

状況に応じて，全学管理者は安否状況が未登録の構成員に対して通知メールを再送信する

8.

安否確認が終了したら，全学管理者は安否イ
ベントを停止する

2.3 主な仕様
2.3.1 認証
本システムは，Shibboleth SP（ServiceProvider）として稼働しており，本学が運用している Shibboleth IdP（Identity Provider）に全学 IDで認証することで利用可能である．
2.3.2 安否状況登録画面
構成員が安否状況を登録する画面で，PC，スマートフォン，タブレットから登録が可能である（図 2，図 3）．登録する安否情報は下記のとおりである

安否情報（安全・健康，負傷/病気の程度《軽度，中度，重度》）



通学・出勤が可能か（はい，いいえ）



どこで登録作業をしているか（キャンパス，自宅，その他）

状況説明（自由記述）
なお，安否イベント起動中はすでに登録した情報の更新が可能である．

図 3 安否状況登録画面（スマートフォン）
2.3.3 安否状況一覧画面
安否状況一覧画面では，部局管理者，部局作業者が構成員の安否登録状況を閲覧可能である（図4）．入力された安否状況により，セルの色が変わるため，一目で全体の状況を把握可能である．部
局管理者は，部局構成員の安否状況を一覧画面から直接編集可能である．また，一覧を Excel 形式のファイルとしてダウンロード，編集，アップロードすることで，複数人の情報を一括更新することができ，部局の規模に配慮した設計になっている．
なお，全学管理者は上記の全機能を全学構成員に対して行うことが可能である．

2.3.7 イベント履歴表示システム管理者・全学管理者は，過去に起動していた安否イベントの安否状況，メール送信状況等が確認可能である．
2.3.8 部局マッピング
本システムの構成員情報は，本学が運用している全学 LDAP から取得しており，教職員の人事給
図 4 安否状況一覧画面

与システムと，学生の教務情報システムがデータソースとなっている．両システムは組織コードが2.3.4 権限変更画面異なっているが，実際の運用では，教職員も学生権限変更画面では，特定の構成員に対してローも同じ部局配下の構成員として扱うため，マッピルを割り当てることが可能である．なお，登録作

ングテーブルを準備し，教職員と学生の情報をマ業者の権限により登録可能なロールが異なる（表ージした構成員 DB を新たに構築した．

1）．
表 1 登録可能なロール一覧
登録作業者

登録可能なロールシステム管理者

システム管理者，全学管理者，部局管理者，部局操作者

全学管理者

全学管理者，部局管理者，部局操作者

部局管理者

部局管理者，部局操作者

2.3.5 通知メール送信

2.3.9 その他補完機能
本システムの補完機能として，データ集計を簡便に行うための Excel マクロを開発した．構成員の安否状況一覧を Excel 形式でダウンロードし，そのデータを別途用意した Excel ファイルのシートに貼り付けてマクロを起動すると，各種集計が行われる．
A. 安否状況の集計マクロ

安否状況と死傷者数等一覧



構成員の来学可否，登録場所一覧



負傷／病気の程度が「重度」な構成員

全学管理者は，安否状況の登録依頼や通知をメールで全構成員に対して配信可能である．通知メールの内容はテンプレートとして複数作成しておくことができ，送信対象者として，全学構成員，一覧


構成員の状況説明一覧

B. 特定の構成員の安否状況抽出マクロ

指定した構成員の安否状況一覧

もしくは部局単位の構成員を選択可能である．また，安否状況の未登録者のみを対象にして再通知も可能である．
メール送信機能は，一定の人数に送信した後に全学訓練の実施
平成 29 年 6 月 29 日に，本システムの全学訓練を行った．訓練内容とその結果について下記の一定の間隔を空けて送信することができ，メールとおりである．

サーバの負荷軽減に配慮した設計になっている．

3.1 訓練想定

2.3.6 操作ログ履歴
全学管理者は，システム管理者・全学管理者・部局管理者・部局作業者が行った作業ログの閲覧が可能である．

「7 時 50 分頃に京都市域を震源とする震度 6弱の地震が発生した」という想定で，主に下記の 3 つの訓練を行った．
(1)

全構成員の安否状況登録訓練(2)

危機対策本部の運用訓練

(3)

部局対策室（部局管理者，部局作業

1,150 通が送信完了した後，残りの 22,000 通が学生メールサーバ側で受信拒否された．

者）の運用訓練

本学では学生メールシステムとして Microsoft

3.2 実施結果(1)

全構成員の安否確認登録訓練

社のパブリッククラウドサービスである

 全学管理者による安否登録依頼メール送

Office365 を利用している．しかし，過去に，本信学システムから大量のメールを送信した際に送信時間: 8:06 から 10:11

Office365 側で受信拒否されたことがあった．そ

対象: 35,264 人の経験を活かし，今回の訓練では事前対策とし 全学管理者による安否状況未登録者へのて，本システムが送る通知メールの From アドレ

登録依頼メール送信

スをスパム判定されないように，Office365 の送信時間: 12:06 から 13:21

SCL(Spam Confidence Level) の設定を実施して対象: 21,355 人いた．
しかし，今回の送信失敗の原因は Office365 の 全学構成員による安否登録
実施期間:

EOP(Exchange Online Protection) という機能

6 月 29 日 8:05 から 7 月 3 日 12:00による受信拒否であった．EOP は，過去に送信全構成員のうち約 60%（教職員約 80%，学実績が無いホストから大量のメール送信を検知す生約 50%）が登録作業を行った（表 2）．
表 2 安否登録状況

ると，メール配送を拒否する仕組みである．そのため，事前に少量のメールでも本システムから登録者対象者

登録率

Office365 へ送っていれば問題が発生しなかった

数数（％）

可能性がある．今回の訓練時は，Office365 の設

（人）

（人）

教職員

9,320

11,73879.4

追加することで，この問題を回避した．

学生

11,84623,366

50.7



総計

21,16635,10460.3

定で，送信元 IP アドレスを組織内サーバとして全学メール転送先でのスパム判定
全学メールには配信されたが，全学メールの転送先に学外のメールアドレスを設定している場合(2) 危機対策本部（全学管理者）の運用訓練に，転送先側のメールサーバでスパム判定された危機対策本部要員約 30 名が全学構成員のという問合せがあった．この対策として，一斉送リアルタイムな安否登録状況を本システムで信時の送信間隔を長くする等の対応を検討してい確認した．
(3) 部局対策室（部局管理者，部局作業者）の運用訓練

る．


研究所やセンターの研究室に配属された学生の対応

部局に部局対策室を設置し，部局管理者

本システムは当初，学生の安否状況の把握は約 60 名が構成員の代理入力，安否状況の集本所属の部局が行うことを前提としていた．しか計を行った．

し，研究所やセンターに配属された学生について3.3 発生した問題は，本所属が各研究科であるため，本所属以外の

部局が安否状況を把握できないという問題があっ学生メールに対する送信失敗
全学訓練実施の数日前に，本システムのメール通知機能を使用して，訓練実施依頼メールを全構成員に対して配信した．教職員に対するメールは全員に送信完了したが，学生に対するメールはた．今回は，先述の「特定の構成員の安否状況抽
出マクロ」の利用，もしくは，部局管理者の権限を他部局へ払い出す運用対処をお願いした．今後は，ロールの見直しを検討していく．
 サーバ負荷の問題

一回目の通知メール送信後にアクセスが集中し，一時的にサーバが高負荷になった．サービス停止は無かったが，アクセス時にタイムアウトしたというユーザの声もあったため，サーバのチューニングを検討していく．
現状の課題と今後の展開
現状の課題として主に次の事項があり，改善を検討している．
本システムへのアクセス方法の改善



安否状況の設問の見直し



ロールの見直し

学生の国籍など必要な情報の拡充



サーバ・チューニング



その他運用上の課題
今後の展開としては，本学危機管理委員会の承認を経て，公式なサービスとして継続運用する予定となっている．
おわりに
本稿では，本学の安否確認システムの現状ならびに今後の展開について報告した．今後も教職員および各所のご意見を集約し，改善を行いながらも安定した運用を行っていく所存である．
謝辞

総務部総務課リスク管理掛の皆様，並びに安否確認システムの運用に日頃ご協力頂いている皆様に，謹んで感謝の意を表します．