AXIES Trajectory vol.1 2024

DXによる学内事務連絡の業務効率化を目指してDXによる学内事務連絡の業務効率化を目指して

Improving Operational Efficiency of Administrative Communications among
Faculty and Staff Members with Digital Transformation
香川大学情報化推進統合拠点

松永 貴輝

Integrated Center for Informatics, Kagawa University Takateru Matsunaga
ORCID ID : https://orcid.org/0000-0003-3153-4120［紹介論文］
香川大学のポータルシステム「Digi-ONE」の学内教職員向けお知らせ機能の開発
松永 貴輝，末廣 紀史，武田 啓之，藤本 藍，米谷 雄介，八重樫 理人（香川大学）
学術情報処理研究 , Vol. 27, No. 1, pp. 65-72, 2023.

されていた．その運用方法は，それぞれの担当部署で事1．
はじめに務連絡の電子メールを作成，各部署の連絡担当者宛にそこのたびは，機関誌「AXIES Trajectory」創刊，心れを送信し，各部署の連絡担当者が部署のメンバーに電よりお祝い申し上げるとともに，今回，論文誌「学術情子メールでそれを転送する，というものであり，連絡担報処理研究」に掲載された我々の論文について，紹介の当者の事務連絡転送に費やされる工数増大が課題であっ機会を与えていただき，関係者の方々に深く感謝申し上た．それに加え，事務連絡の受信側では，1 日に何通もげる．の事務連絡メールが届くことにより，その確認のため業務中断の回数が増え，電子メール閲覧に費やされる時間

本論文は，香川大学におけるデジタルトランスフォーが増加する課題もあった．

メーション（DX）推進の一環として，従来の電子メールによる事務連絡を置き換えるお知らせ機能を，香川大開発したお知らせ機能では，事務連絡の発信者が，お学のポータルシステム「Digi-ONE（デジ・ワン）」に知らせ機能に事務連絡を登録し，ユーザが，「Digi-ONE」開発し，その効果を評価したものである．
「Digi-ONE」にアクセスして事務連絡を閲覧する．これにより，連絡のお知らせ機能における事務連絡手法は，業務効率化お担当者による事務連絡の転送業務が不要となるだけでな

よび円滑な情報共有に対して有益な情報と考えられるた

く，1 日に何通もの事務連絡メールが届くことはなくなめ広く読者に知っていただきたく，ここに紹介したい．

る．しかし，この方法では，ユーザが「Digi-ONE」に開発したお知らせ機能の技術ポイントは，「Digi-ONE」

アクセスしないと，どのような事務連絡が登録されていのお知らせ機能に新規登録された事務連絡を 1 日 1 回るかわからないことに加え，ユーザが業務を一次中断しのサマリーメールに集約してユーザに配信することであて「Digi-ONE」にアクセスしたとしても，新規の事務る．これにより，事務連絡確認のための業務中断回数が連絡が登録されていないこともある．そこで，新規に登減ることに伴い，事務連絡の閲覧に費やされる時間の削録された事務連絡を，1 日 1 回のサマリーメールに集約減が可能となる．

させて電子メールでユーザに配信する仕組みを構築した．

香川大学では，学生・教職員をデジタルの世界で繋ぐためのシステム基盤として，学内情報のターミナルとし大学内に飛び交う事務連絡メールのお知らせ機能へのて利用者が 1 日の始まりに訪れる WEB サイト上のポー置き換えとサマリーメールへの集約の実現は，言葉で言タルシステム「Digi-ONE」を開発した．
「Digi-ONE」は，うほど容易ではなく，業務プロセスの見直しを含めた株式会社 Siba Service の大学ポータルシステムである

様々な導入の検討・苦労があった．一例を挙げると，事「Knowledge Portal」

務連絡の配信カテゴリの整理では，給与改定や訃報のほ［1］をカスタマイズして開発されか，企業の社名変更など多種多様な内容の連絡について，たものである．
大学から教職員への事務連絡手段については，電子受信者の属性や影響度などを議論した上で情報の重要度

メールやグループウェアの掲示板機能の利用等，各大学について検討した．また，これまで広報部門では，学内で工夫をされていることと思う．香川大学では，大学かから広報依頼が寄せられるたびに事務連絡の電子メールら教職員への事務連絡には，これまで電子メールが使用を発信していたが，お知らせ機能における毎日 15 時の19

AXIES Trajectory vol.1 2024

サマリーメール配信に合わせるため，広報の運用についに記載された事務連絡のリンクをクリックすることによて議論・検討がなされ，業務プロセスが見直された．

り「Digi-ONE」にアクセスして事務連絡を確認する．
このとき，ユーザは気に入った事務連絡に対して「いいね！」を付けることができる．

2．
「Digi-ONE」のお知らせ機能と業務削減時間の評価

図 2 は，「Digi-ONE」のお知らせ機能を利用した場合の，業務削減時間の評価結果を示している．大学全体

図 1 は，ポータルシステム「Digi-ONE」のホーム画

で 1 ヶ月間に事務連絡に費やされる時間を，従来の電面を示している．大学から発信される事務連絡を伝える

子メールを用いた事務連絡と「Digi-ONE」のお知らせ「お知らせ」
機能は，ホーム画面に表示される．また，ホー機能とでそれぞれ概算した．
「Digi-ONE」のお知らせ

ム画面には，大学の公式イベントを表示する「学年暦」

機能では，連絡担当者による事務連絡の転送作業が不要機能，個人宛の親展通知を表示する「親展通知」機能，になることに伴い，事務連絡の配信に費やされる時間は報道・放送予定のカレンダーを表示する「報道情報カレ減少した．さらに，事務連絡が 1 日 1 回のサマリーメーンダー」機能，学内の各種 Web システムへのリンクをルに集約されたことによる電子メール閲覧回数の減少に表示する「厳選リンク集」機能も表示される．

伴い，事務連絡の閲覧に費やされる時間は減少した．

「Digi-ONE」のお知らせ機能への事務連絡の登録で「Digi-ONE」のお知らせ機能を利用することで，配信は，事務連絡のタイトル，内容，通知対象者，公開期間と閲覧を合わせた事務連絡全体に費やされる時間は，を入力する．このとき，あらかじめ登録された「人事・749 時間から 198 時間に大幅に削減されることが示さ給与関係」「研究関係」等の選択肢の中から配信カテゴれた．

リを指定することができる．事務連絡を閲覧可能なユー
ザは，通知対象者に指定されたユーザに限定されており，通知対象者は，あらかじめ登録されている学内のユーザ3．
むすびまたは学内の部門の中から選択して指定する．
このため，「Digi-ONE」のお知らせ機能は，2023 年 4 月から送信先に誤って学外のメールアドレスを指定し学外へ誤実運用された．お知らせ機能の運用を踏まえ，事務連絡送信されてしまう事態は起こらない．の発信者から，「『いいね！』が付くと，反応がもらえて新規に登録された事務連絡へのリンクが付与されたタポジティブになった」，「事務連絡の業務を自分たちで変イトルは，「サマリーメール」
として 1 日に 1 回，電子メーえられることに気づき，タイトルを見やすくすることや，ルで学内全教職員に配信される．
「サマリーメール」には，不要な冒頭あいさつを省くなど，ユーザ目線で改善をすメールを受け取る本人が通知対象者として指定されているようになった」などの意見が寄せられた．さらに，今る事務連絡のみのタイトルが記載される．ユーザは，「サ回のお知らせ機能は，大学本部から発信される事務連絡マリーメール」に記載された事務連絡のタイトルを確認を対象としているが，学部からは「学部内のお知らせもし，自身に関係する事務連絡があれば，「サマリーメール」同様に整理したい」といった要望が寄せられている．こ図 1 「Digi-ONE」ホーム画面出所）松永貴輝，末廣紀史，武田啓之，藤本 藍，米谷雄介，八重樫理人：
香川大学のポータルシステム「Digi-ONE」の学内教職員向けお知らせ機能の開発，学術情報処理研究，Vol. 27, No. 1, pp. 6572, 2023.

図 2 事務連絡に費やされる時間の比較
出所）松永貴輝，末廣紀史，武田啓之，藤本 藍，米谷雄介，八重樫理人：
香川大学のポータルシステム「Digi-ONE」の学内教職員向けお知らせ機能の開発，学術情報処理研究，Vol. 27, No. 1, pp. 6572, 2023.

20

AXIES Trajectory vol.1 2024

DXによる学内事務連絡の業務効率化を目指してれらユーザの意見・要望から，開発したお知らせ機能は，大学間で DX 推進の取り組みやノウハウを共有して単なる業務工数の削減にとどまらず，ユーザ自ら業務をいくことが，日本全体の DX 推進には大事である．本

変革し新たな価値を創出するという DX 本来の目的に論文の成果が，業務効率化に取り組む他大学・機関のつながっていることがうかがえる．

DX 推進に少しでも寄与できるならば幸甚である．

「Digi-ONE」のお知らせ機能には，ここで紹介した機能に加え，事務連絡の開封者数・未開封者数を確認で参考文献きる機能や，各通知対象者の開封状況を確認できる機能［1］ 株 式 会 社 Siba Service：Knowledge Portal. https://www.siba-service.jp/service/knowledge-portal/（2024年 1 月 5 日参照）等があり，それに伴う効果も期待できる．詳細は論文を参照されたい．

【著者略歴】

松永 貴輝
2007 年神戸大学大学院自然科学研
究科博士後期課程修了，博士（工学），シャープ株式会社を経て，現在，香川大学情報化推進統合拠点特命准教授．業務データ分析および BI ツールを用いた可視化に関する研究に従事．

21AXIES Trajectory vol.1 2024

「認証統合に対応したウェブホスティングサービスの構築と運用」に至る道程
Road to Construction and Operation of Web Hosting Service Supporting Single
Sign On
豊橋技術科学大学 情報メディア基盤センター教授

土屋 雅稔

Toyohashi University of Technology, Information and Media Center, Professor, Masatoshi Tsuchiya
ORCID ID : https://orcid.org/0000-0003-1862-8149［紹介論文］
認証統合に対応したウェブホスティングサービスの構築と運用
土屋 雅稔，中村 純哉，小林 真佐大，下條 詠司
学術情報処理研究 , Vol. 27, No. 1, pp. 73-81, 2023.

端末システムのアカウントの統合である．タイミング良

1．
はじめに

く，情報処理センターが運用していた教育用端末システ

現代のネットワーク社会において業務を遂行するにムの更新が 2006 年 3 月に予定されていた．そのユーは，安定したサーバ資源が必要不可欠である．インターザ認証基盤として LDAP サーバを構築するよう仕様を

ネット黎明期においては，そのようなサーバ資源は，専指定した上で，マルチメディアセンターが運用していた門外の職員や学生のボランティア的活動によって維持さ教育用端末システムおよび無線 LAN からは，新システれてきた．しかし，近年，これらのサーバの運用に興味ムの LDAP サーバを参照するよう設定変更した．加えを持ち，自発的に技術研鑽を行う職員や学生は確保困難て，アカウント管理システムを独自に作成し，ようやく，になりつつある．また，サーバを維持するために必要な入学時に全構成員を対象としてアカウントを配布できる技術は高度化する一方であり，十分なメンテナンスが行体制が整った．
次に取り組んだのが，ホスティングサービスの開発でわれていないサーバは少なくない．
この問題に対応するため，各地の大学付属情報基盤セある．当時は，研究室や学科で個別にウェブサーバやメーンターでは，ホスティングサービスを提供することが広ルサーバを運用している体制が当たり前だったが，管理く行われている．筆者が所属する豊橋技術科学大学情報できる職員や学生の確保が困難になり，セキュリティ的メディア基盤センターも，2008 年からウェブ・メール・な脆弱性を抱えているサーバが問題になり始めていた．

DNS のホスティングサービスを提供している．ただし，アカウント管理システムが完成していなかった時期でも豊橋技術科学大学は，学生約 2000 人の小規模単科大学あり，そんな大変な仕事をやりたくなかった筆者がごねであり，センターの規模も極めて小さい．そのような小ていたところ，某先生に「がたがた言わずにとっととや規模センターにおいてホスティングサービスを実現するれ」と雷を落とされて，しぶしぶ開発を始めることになっには，様々な工夫を必要とした．表向きの工夫についてたのも，今となっては懐かしい思い出である．

は，
文献および紹介論文［1］［2］

第 1 期システムの開発においては，開発と運用に関に記述済みであるから，［3］わる人員は筆者ただ 1 人しかいなかったため，サービ本稿では裏向きの事情について述べたいと思う．

スを運用する工数を許容できる範囲に収めることが非常に重要な課題となった．他大学のサービス内容を比較検2．
第1期システム（2008年～2015年）

討したところ，サービスを提供するセンターが，少数の筆者が，情報処理センターに採用されたのは 2004 年

管理用アカウントを利用部局に対して発行し，利用部局である．翌年には，情報処理センターとマルチメディアの管理者は，その管理用アカウントを使って様々な作業センターが統合され，情報メディア基盤センターに改組を行うという形態が一般的だった．しかし，この形態でされた．最初に課題になったのは，情報処理センターとは，管理用アカウントの引継やパスワード再設定などのマルチメディアセンターで別個に運用されていた教育用サポート業務が発生することが容易に想像できたため，
22

AXIES Trajectory vol.1 2024

「認証統合に対応したウェブホスティングサービスの構築と運用」に至る道程

管理用アカウントを使わない方法はないだろうか？と考は順調に拡大し，2014 年には運用スタッフが 2 人に増えたことが，第 1 期システムの主題となる．

員された．これによって，ドメイン毎の変更履歴の記録

先に述べた通り，ホスティングサービスを開発する直が不十分という問題が顕在化する．第 1 期システムでは，前に LDAP サーバを用いた認証統合に着手していたた

ドメイン固有の設定変更は，当該ドメインのディレクトめ，利用部局の管理者といっても，ユーザ認証基盤上でリツリー内のファイルを直接修正し，作業メモを WiKi

は単なる 1 人の利用者として認証が可能であることは，に記録するという形で作業を行っていた．この形では，すぐに気がついた．この着想に基づいて，管理者の認証あるドメインの設定内容が正しいかどうかを確認するにと管理行為の認可の分離を徹底したホスティングサービ

は，作業メモを全て目視で確認しなければならない．作

スとして実現したシステムが，第 1 期システムである．

業メモのどのあたりにどういう記述があるか，熟知して2008 年から 2015 年まで運用した第 1 期システムのいた筆者にとっては容易い確認作業も，新規に加わった構成を，図 1 に示す．第 1 期システムでは，仮想化機構運用スタッフにとっては非常に困難だったわけである．

として Linux VServer を採用した．
Linux VServer は、更に，Linux VServer の運用コストが問題化する．

FreeBSD jail とよく似たカーネルレベル仮想化機構でLinux VServer を実行するには，プロセス ID 空間の分ある．各ドメインのプロセスは同一のカーネルを共有す離を実現する修正パッチを適用したカーネルが必要であるが，ドメイン毎に異なるプロセス ID 空間で動作する．

る．第 1 期システム開発時は，上流ディストリビューショ

図 2 に示す通り，OS イメージやウェブサイトのデータン（Debian GNU/Linux）から修正パッチ適用済みカー

は NFS サーバ上に用意された各ドメイン用の領域（ディネルが配布されていたが，第 1 期システム運用中に配レクトリ）に配置され，ドメイン毎にルートディレクト布されなくなった．第 1 期システムは物理サーバ上にリを chroot することによって，ドメイン間のファイル構築されていたため，ハードウェアの寿命によるリプ名空間の分離が実現される．つまり，ドメイン分離のたレースが必要になったが，単純にハードウェアを置き換めにハードウェアによる仮想化支援機能を必要としない

えて Linux VServer の利用を継続するという方針は運し，かつ，ドメインを切り替えるコストも極めて小さい．

用コストの観点から困難になった．

［4］

よって，安価な物理サーバで多数のドメインを収容する2011 年から教育用システムの各種サーバをオンプレことができ，厳しい予算制約を満たすために適していた．

ミス仮想化基盤に収容していたため，第 2 期システム

第 1 期システムの詳細は，文献［1］［2］の各種サーバも仮想化基盤上に構築することを選択しに記載の通りでた．とにかく，ホスティングサービスのための独立したある．

予算は存在しなかったのである．ただし，ドメイン毎に別個に仮想マシンを割り当てることは，サーバ資源と運3．
第2期システム（2015年～2021年）

用コストの 2 つの観点から現実的ではない．そのため，仮想マシン上でコンテナ環境を実行することによって，

図 3 に示す通り，ホスティングサービスの利用部局ドメイン毎の分離を実現することにした．2015 年から2021 年まで運用した第 2 期システムの構成を，図 4 に示す．第 2 期システムでは，コンテナ型仮想化機構として Docker［5］を採用した．Docker は Linux 標準カー

図1

第 1 期システムの構成

図2第 1 期システムのデータ配置

図323

利用ドメイン数の推移

AXIES Trajectory vol.1 2024

図4

第 2 期・第 3 期システムの構成

図5

第 2 期システムのデータ配置

う設定する

ネルに統合されたコンテナ実行機能に基づいて構成されており，Linux VServer で生じた運用コストの問題が設定後に，MySQL サーバを利用している全てのドメイ発生しにくいと判断したためである．

ンに対して設定変更が必要となった場合には，全てのドDocker で は， コ ン テ ナ イ メ ー ジ の 作 成 手 順 をメインの Dockerfile を grep して対象ドメインを列挙

Dockerfile と呼ばれるテキストファイルに記述し，そして対応していた．つまり，Dockerfile を参照すれば，れを docker コマンドに渡すとコンテナイメージを作成

各ドメインの構成定義も機械的に判定できるはずというできる．また，既存のコンテナイメージを継承して新し考え方である．しかし，Dockerfile の記述方法は一意いイメージを作成できるため，コンテナイメージを階層ではない．運用スタッフが 2 人しかいなかった時期は，的に管理することも可能である．第 2 期システムでは，記述方法のバリエーションも限定されていたが，運用ス

図 5 に示す通り，この仕組みを利用して，全ドメインタッフが 3 人に増員されると，バリエーションが一気に共通する設定と各ドメインの個別設定を分離し，かつに増えて，構成定義が機械的に判定できない事例が続発全体を網羅的にバージョン管理することを試みた．具体するようになり，運用コストが急激に悪化した．

的には，全てのドメインで利用するプログラムや設定をこの問題を解決するため，第 3 期システムでは，各行う Dockerfile を用意して，共通コンテナイメージをドメインの構成定義の管理方式を図 6 のように改めた．

作 成 す る． 次 に， 各 ド メ イ ン の 固 有 設 定 を 行 う

まず，ドメイン毎の構成は，宣言的に記述した構成定義

Dockerfile を用意して，ドメイン個別のコンテナイメーファイルにまとめて，バージョン管理する．次に，ドメジを作成する．その上で，全ての Dockerfile の変更履

イン毎に個別のコンテナイメージを用意するのではな

歴を Git を用いて記録すると，変更履歴が確実に保存さく，全てのドメインが共通のコンテナイメージを用いる．

れるという仕組みである．

この共通コンテナイメージは，コンテナ実行時に構成定義ファイルを読み込み，必要な設定をコンテナに施す．
この方式によって各ドメインの構成が明確になり，また4．
第3期システム（2021年～現在）設定変更も容易になった．

2018 年には運用スタッフが 3 人に増員された．これ

近年，セキュリティ上の要請に基づき，一般に広く使によって，各ドメインのコンテナイメージを生成する

わ れ て い る ウ ェ ブ ブ ラ ウ ザ（Google Chrome やDockerfile は，各ドメインの構成定義という観点からApple Safari など）は，TLS 化されていないウェブサーは不十分であるという問題が顕在化する．例として，第バにアクセスすると警告を出力したり，アクセスを拒否

2 期システムにおいて，あるドメインで MySQL サーバするようになっている．そのため，第 2 期システムにを利用したいという要望があった場合を考える．この場

おいては，TLS 化が必要な一部のドメインだけを対象合， 運 用 ス タ ッ フ は，以下の内容を当該ドメイ ン のとして，UPKI によって発行された証明書を設定して対Dockerfile に書き加えた上で，当該ドメインのコンテ応していたが，第 3 期システムにおいては，全てのドナイメージを再作成・実行する．

メインを対象として TLS 化する必要がある．さらに，●

MySQL パッケージをインストールする

サーバ証明書の有効期限短縮化によって，証明書の更新●

MySQL の設定ファイルを配置する作業がきわめて頻繁に発生するため，更新の自動化も重●MySQL サービスをコンテナ実行時に起動するよ

要 で あ る． 以 上 よ り， 第 3 期 シ ス テ ム に お い て は，
24

AXIES Trajectory vol.1 2024

「認証統合に対応したウェブホスティングサービスの構築と運用」に至る道程

関係者の尽力に感謝するとともに，実運用に関する知見を広く扱う論文誌として存続されることを期待する．
さて，運用スタッフの変化がシステムのリファクタリングを要請するという経験則が正しいならば，近い将来，第 4 期システムが必要になることが予想される．と言うのも，筆者の異動に伴って，本サービスに対する筆者図6のエフォートが低下しつつあるからである．どのような

第 3 期システムのデータ配置

第 4 期システムが実現されることになるか，今から楽しみである．

Let’s Encrypt によって発行された証明書を基本的に用最後に，ホスティングサービスの開発と運用に協力しいることにした．UPKI によって発行される証明書はてくださったセンタースタッフの皆様に，深く感謝しま

OV 証明書であるのに対して，Let’s Encrypt によってす．また，サービス開発のきっかけを作ってくださった発行される証明書は DV 証明書であるから，証明書の廣津登志夫先生（元豊橋技術科学大学情報メディア基盤

信頼性という観点では UPKI の方が好ましい．しかし，センターネットワーク部長．法政大学教授），知見を論UPKI の証明書発行システムは自動化に対応していない文化するよう励まし続けてくださった稲垣康善先生（元ため，第 3 期システムでは採用できなかった．

豊橋技術科学大学副学長兼情報メディア基盤センター長．名古屋大学名誉教授）に感謝します．

第 2 期システムおよび第 3 期システムの詳細は，紹介論文［3］に記載の通りである．
参考文献［1］ 土屋雅稔：「認証基盤と連携したメールホスティング環境の構築」，学術情報処理研究，Vol.13, pp.5-16（2009）

5．
おわりに
本稿は，
「小規模センターにおいて，10 年以上の長期［2］ 土屋雅稔：「管理者が安全に交代できる学内ホスティングサービス」，電子情報通信学会論文誌，Vol.J95-B，No.10,pp.1264-1272（2012）

にわたってホスティングサービスを提供できた秘訣は何だろうか」という質問を編集委員氏から受けて書き始め［3］ 土屋雅稔，中村純哉，小林真佐大，下條詠司：「認証統合に対応したウェブホスティングサービスの構築と運用」，学術
情報処理研究，Vol.27, pp.73-81（2023）

たものである．本サービスの運用経験を振り返ってみると，運用スタッフの変化がトリガーとなって問題が顕在［4］ B. Des Ligneris: Virtualization of Linux based
computers: The Linux-VServer project. Proceedingsof the 19th International Symposium on High
Performance Computing Systems and Applications（HPCS’05）, pp.340-346（2005）

化し，その問題を解決するためにシステムのリファクタリングを行い，そのプロセスを論文化するという過程を繰り返していることが分かる．おそらく，リファクタリングをきちんと実践できたことが，サービスを維持できた秘［5］ Dirk Merkel: Docker: lightweight linux containers forconsistent de velopment and deployment. Linux
Journal, Vol.239, No.2, pp.2（2014）

訣ではないだろうか．とすると，そのような実運用の知見を投稿できる場所として「学術情報処理研究」が用意されていたことは，大きな助けになっていたと考えられる．

【著者略歴】

土屋 雅稔
2004 豊橋技術科学大学情報処理セン タ ー 助 手．2007 同 大 学 情 報 メ
ディア基盤センター助教．2014 同大学情報メディア基盤センター准教
授．2023 同大学情報・知能工学系教授（情報メディア基盤センター兼務）．自然言語処理に関する研究に従事．博士（情報学）．言語処理学会，情報処理学会，人工知能学会 各会員．
25