原著論文
九州工業大学におけるMicrosoft Teamsの全学展開
2024 年 28 巻 1 号 p. 98-105
詳細
2024 年 28 巻 1 号 p. 98-105
九州工業大学では，電子メールに代わる効率的なコミュニケーション手段として，2022年度よりMicrosoft Teamsの全学展開を行った．Microsoft Teamsの稼働基盤であるMicrosoft 365テナントの初期設定では，全てのユーザがチーム作成権限を持つことや，ファイル共有が組織外を含め自由に行える状態にある．初期設定での運用は，Microsoft 365のサービス提供への影響やガバナンスの観点で懸念があると判断し，適切な設定値を検討・変更することとした．加えて，チームの作成や年次更新については電子申請に基づく承認制を採用し，統制の取れたチーム運用を実現した．
九州工業大学（以下，本学）では，既存の情報システムのあり方の問題点を洗い出し，更なる最適化を目指す方針ならびに，対象のサービス更新内容や時期等をマスタープランとして定め，情報基盤の更新を行っている．
情報システムの最適化の観点では，メールシステム（電子メール）からの脱却は重点的な課題と捉えている．電子メールは時代の要求に応じて機能向上がなされてきたが，セキュリティ上の問題が絶えず生じることや，プル型のサービスであるためタイムラグが多く，細かなやり取りは電話を併用する等の運用が必要である．
メールシステムからの転換として，チャット機能・ファイル共有機能を備えたコミュニケーションツールは有力な選択肢である．本学は全学的にMicrosoft 365（以下，M365）を導入しており，M365が有するコミュニケーションツールであるMicrosoft Teams（以下，Teams）を学内向けの連絡手段として適用可能であるか検討した．
TeamsはM365の初期設定において，全てのユーザが自由にチームを作成でき，ファイルの共有範囲については，組織外（匿名公開）を含め自由に設定できる状態にある．初期設定での運用は他のM365サービス提供への影響が生じる可能性やガバナンス上の懸念があると判断し，Teamsを構成するM365上のシステム設定値を調整した後に運用を開始することとした．また，統制の取れた運用するチームには責任者を設定すること，責任者の退職等に伴う交代，チームの休眠状態を抑制するための棚卸し等が重要であることから，本学においてはチームの作成と年次更新は電子申請に基づく承認制を採用することとした．
上記の運用方針に基づき，2021年度中にM365の設定値変更を完了させ，設定値変更と一部並行し承認システムを整備することにより，2022年5月よりTeamsの全学展開を開始した．2024年5月現在において約200チームが稼働している．その運用範囲は事務部・技術部・本部内の室・タスクフォース・研究室・授業用等と多岐にわたっている．本稿において，本学におけるTeams運用に要したM365の設定値変更や，チーム作成・年次更新の仕組み等について詳細を述べる．
本学で稼働する情報システムは，部局やプロジェクト単位で調達がなされ，国からの指針や法律への準拠に応じて個別最適させる方針であった．対して，利用者視点での利便性等の考慮は優先度が低く，レガシーな情報システムが林立している状況であった．本学では，このような既存の情報システムのあり方の問題点を洗い出し，更なる最適化を目指す方針（Kyutech-DXビジョン2023）の定義[1]ならびに，対象のサービス更新内容や時期等をマスタープランを定義した．
情報システムの最適化の観点から，本学ではメールシステム（電子メール）からの脱却は重点的な課題と捉えている．電子メールは本学において依然として重要なコミュニケーションツールであり，全学メールサービスを用いたメール送受信数は，一日平均7万通程度の流量を有している．時代の要求に応じて継続的に機能向上がなされているが，根底は設計が古い情報システムであるため，セキュリティや利便性の観点で多くの課題を有する．
利用者視点で顕在化しているセキュリティ上の問題点としては，機微情報の誤送信，受信者リストの露出（BCCとTOの指定ミス），送付先ミスによる添付ファイルの流出，転送設定ミスによるドッペルゲンガードメインへの情報流出等が顕在化しており，一部は本学においても報告されている．これらの問題点に対応するセキュリティ製品は存在するが，電子メール基底の脆弱さであるため根本的な対策は困難である．
加えて，電子メールにおけるメッセージの受信は，メールサーバへ受信要求を出すプル型となるため，コミュニケーションにタイムラグが生じる．したがって，短時間での細かなメッセージのやり取りが困難であり，場合によっては電話等を併用したコミュニケーションへ発展させる必要性が生じる．
これらの問題点が，本学がメールシステムからの脱却を検討すべきと捉えている事由となる．
2.2 新たなコミュニケーションツールの検討前述のマスタープランの策定がなされる以前となる2020年度より，本学においては電子メールからの脱却の手段として，コミュニケーションツールの導入検討に着手していた．
理由としては，2020年度に筆者らが所属する組織が改組され，より利便性の高いクラウドサービスの導入を推進する方針となった事に加え，2020年代に入り，メッセージの送受信にチャットツール，ファイルの共有にオンラインストレージを利用し，電子メールや添付ファイル運用からの転換を図るパターンが増えつつあった事である．
システム構築やメンテナンスのコストを抑えるためにはSaaSの活用が有力であり，具体的なシステムの候補としては，Slack + Boxや，Teams等が考えられる．本学は，学生・教職員・卒業生を含む全学的な電子メールサービス運用のため，2015年度にM365を導入していた[2]．Teamsは本学が契約するM365ライセンス（2015年当時はA1，2020年度よりA5）に含まれる機能である[3]．追加投資なく展開できることが期待されることから，学内向けのコミュニケーションツールとしての導入に向けて検討を行った．
ここで，本学におけるM365のテナント構成について説明する．本学においては「全学向けM365テナント（全学テナント）」と「事務職員向けM365テナント（事務テナント）」2つのM365が存在する．図1にテナント構成とテナント間の関係性を示す．
全学テナントは本学に所属する全ての学生・教職員がアカウントを有し，利用するテナントである．学生・事務職員を除く教職員はA5アカウントが付与されるが，事務職員は後述の事務テナントを主として利用するため，全学テナント上ではA1アカウントが付与される．本学の様々な構成員を含めたチームやOneDriveを用いたデータの共有を行う際は，全学テナントを利用する．全学テナントはTeamsやファイル共有の適切な運用を可能とするため，初期状態からの設定変更を実施している．詳細は後述する．
事務テナントは事務職員のみがアカウントを有するテナントであり，A5アカウントが付与される．事務職員が取り扱うデータは機微性が高いため，全学テナントとは別構成としている．事務職員が所属する部課のチームや事務職員間のデータの共有は，事務テナントを利用する．事務テナントについては全学テナントど同様の設定変更に加え，ファイル共有の共有範囲の制限を更に強化している．
本学においては，2つのテナント間の連携は行っておらず，全く独立した構成を取る．したがって事務職員は全学テナント向け，事務テナント向けの2つのアカウントを有し，複数テナントを使い分ける運用となる．このようにテナントを分けることにより，事務職員が有する機微情報の誤共有の抑制，テナント間の連携設定ミスによる情報流出を抑制することを目的としている．
2.3 Teamsを構成するシステム，システム設定初期値に起因する懸念点Teamsは単体のシステムではなく，M365上のシステムの組み合わせにより構成されている．チームを作成すると，Entra ID（チームやそのメンバー管理），SharePoint Online（メッセージ管理等），OneDrive for Business（ファイル共有），Exchange Online（電子メールとの連携）等のシステムが連携して動作し，利用者にチームの形でサービスが提供される．
これらTeamsと連携するM365上のシステムは，Teamsでの利用向けに分離されている設計ではなく，M365テナントの運用に影響が及ぶ可能性がある．加えて，M365の各システムの設定値は初期状態では利用者にとっての自由度が高い傾向にあり，Teamsの導入前に学内の運用ポリシーに合致するものであるかの判断を要する．以下にて，本学が認識する懸念点について述べる．
Teamsにおけるチームの作成権限は，Entra ID上のグループの一種であるM365グループの作成権限に依存する．本学がM365テナントを展開した時期である2015年4月におけるM365グループの作成権限の初期値は，M365に登録されたゲストを除くメンバーであった．
この当時，TeamsはM365上の正式サービスではなかったが，学生・教職員・卒業生を含む全てのユーザが自由にグループを生成できることにより，Exchange Online上のメーリングリストに相当する機能である配布リストの作成を許してしまうことに大きな懸念があると判断し，グループの作成権限は管理者ロールを除き無効化していた．
グループの作成権限無効化については，後のTeamsの正式サービス開始後，ユーザが自由にチームが作れてしまう挙動が抑制されることに繋がり，正しい判断であった．グループ作成権限の初期値は，Teamsの運用に限らず悪影響が懸念される．筆者らは，M365テナントの展開後，ユーザアカウントを追加する前に無効化することを推奨する．
チーム名の命名規則Teamsにおけるチーム名は，初期値では制約のない任意の名称が指定できる．
チーム名は，Entra ID内のM365グループ内の属性値にて管理され，グループの論理的な名称がM365グループのIdentity属性値に対応する．Entra IDでは，Identity属性値はドメイン名内で一意であるため，命名規則を設けない場合，ユーザ名とチーム名が競合し，M365上でのアカウント作成に支障が生じる．
ゲストユーザの取扱いTeamsでは，組織外のユーザをゲストとしてチームメンバーに追加することが可能である．初期値ではゲストの追加は許可されている．
ゲスト追加により，組織外のメンバーを加えた情報交換が実現できる半面，Teamsのゲストは与えられるアクセス許可範囲が広く，加えて個別にアクセス許可の制御が出来ないことが懸念となる．例として，チーム内にアップロードされたファイルの共有が可能であり，後述のファイル共有範囲の設定によっては，ファイルの情報流出を誘発する．
加えて，ゲストユーザの追加はチーム内のゲストを除くメンバーであれば可能であるため，同様に情報流出のリスクが懸念される．
ファイルの共有範囲M365上のオンラインストレージであるOneDrive for Businessは，SharePoint Onlineを用いて実装されている．オンラインストレージの機能として，アップロードされたファイルの公開範囲・編集権限等の共有制御が可能であるが，初期値では制約が少ないことが問題となる．例として，初期値ではファイルアクセス用のURLを生成し，組織外ユーザが無認証でアクセスできる設定が可能である．
Teamsのファイル共有はOneDrive for Businessの機能を用いており，テナント上の共有設定と同一の振る舞いとなるため，チームに公開されたファイルが組織外に公開されるリスクが懸念される．加えて，本学は学生と教員が同一テナントに所属するため，学生に機微情報が共有されることのないよう，適切なアクセス設定が必要である．
上述した懸念点は，M365の他のサービス提供に影響を及ぼすものや，チームの乱立や休眠化等の無秩序を招くものであり，M365の設定値変更や運用を支援するシステム化が必要である．ただし，極端に自由度の低い設定とすると，コミュニケーションツールとしての機能が不足し，Teamsの利用が促進されない危惧があるためバランスの良い設定値変更を実施する．
2.4 チーム提供に関するルール作成，作成手順・有効期限等の策定本学においてはTeamsの提供に先立ち，チーム提供に関する最低限のルール「Microsoft Teams利用ガイドライン」を全学方針として定めることとした．
ガイドラインには，申請可能な構成員の範囲（本学においては教職員のみを申請者とする），申請者の権限（申請したチームの所有者となり，チャネルやメンバーの追加が可能），目的外利用の禁止事項（営利的利用の禁止等），機微情報の取り扱いに関する注意事項，有効期限の導入（年度末が利用期限，更新により延長可能）等を条項として含んでいる．
チームの作成手順ユーザによるチームの作成権限を無効化することにより統制の取れたチームの作成が可能となる．対して，チームの作成を受け付け，内容に従って作成を進める必要があり，希望者・管理者共に負担は増大する．チームの作成に関するルールを定めることに加え，効率的にチームの作成を行うシステムが必要となる．
チームの有効期限部局・係向け等のチームは長期にわたる利用が見込まれる．対して，時限措置されたタスクフォース等のチームは短期利用が見込まれる．利用後のチームをそのまま存在させると，休眠化や情報流出のリスクが生まれる．また，チームの所有者が退職となり，変更となる可能性を考慮する必要がある．これらの理由より，作成したチームの有効期限を定め，棚卸し等の措置が必要となる．
本学においては，2.3節で述べたM365の設定初期値に起因する問題に対して，本節にて述べる以下の設定値変更を実施した．こられの変更は，2021年度までに適用を完了した．
グループの作成制限全てのユーザが自由にチームを作れる状況に制限を加えるため，Entra IDの設定を変更し，グループ作成が可能なユーザを限定化する．本学においては，グループ作成可能なユーザを追加していない（グローバル管理者は本制限によらず，グループ追加が可能となる）．
設定変更は，対象とするM365テナントのEntra ID上のGroup.Unified設定内の，EnableGroupCreation属性値をFalseとし，GroupCreationAllowedGroupId属性値に，グループ作成可能なユーザを管理するセキュリティグループ等のグループIDを指定する[4]．
Listing 1は，グループ作成が可能な範囲を特定のセキュリティグループに限定化するEntra ID制御用のPowerShellスクリプトとなる．
グループ名と通常のアカウント名との重複を防ぐため，本学においてはM365グループには名称の先頭にgrpを付けることとした．管理者の運用方針として規定するのみでは操作ミスによる名称の付け忘れが想定されるため，本学においてはMicrosoft 365グループに対する名前付けポリシー[5]を適用し，入力したグループ名に対して自動的にgrpが付く設定としている．なお，名前付けポリシーでは，グループ名の末尾に自動的に名称を付ける設定や，禁止用語の定義も可能である．
Listing 2は，作成されたグループ名に接頭辞としてgrp_を追加する名前付けポリシーを定義するPowerShellスクリプトとなる．
本学のM365テナントにおけるEntra ID上のGroup.Unified設定値は以下となる．グループ作成が指定したセキュリティグループメンバー以外不可であり，グループ名にgrpが自動的に付与される設定値であることがわかる（Listing 3）．
ゲストユーザの取扱いは，Teams上でゲスト追加を不可とする方法と，M365テナントにおいてEntra IDのレベルでゲストユーザの追加を制限する方法が利用できる．
本学においては，Teamsのみならず，OneDrive for Business等のファイル共有等を含めたアクセス制限を加える方針とするため，Entra IDレベルで追加制限を付加する．Entra管理センター上の「外部コラボレーションの設定」において，「ゲスト招待の設定」を「特定の管理者ロールに割り当てられているユーザー」以上とすることで，一般ユーザによるゲスト追加を制限できる（図3）．
SharePoint OnlineならびにOneDrive for Businessにおけるコンテンツ共有の初期設定は「すべてのユーザ」に設定されており，サインインが必要ないURLリンクを生成できる水準となる．また，ダウンロードリンクの有効期限や確認コード（メール認証）要求も非適用である．本学においては，全学テナントにおける外部共有レベルを「新規および既存のゲスト」に設定し，加えて外部公開時に確認コード入力を要求するレベルに変更している．また，共有リンクの有効期限は60日としている．この共有範囲の制限については，学生・教職員を区別せず同様としている．
なお，本学の事務職員向けM365テナント（事務テナント）においては，外部共有レベルをもっとも制限の強いテナント内ユーザのみと設定している．事務テナント上のファイルは事務職員以外には共有が行えない挙動となるが，機微情報の取り扱いも可能な運用形態となる（図4）．
2.4節で述べたチームの作成・有効期限や棚卸を実現するシステムを整備する．これらシステムの整備は，3節で述べたM365の設定値の変更と一部並行する2021年度に着手し，2022年4月までに整備を終えた．
4.1 チーム作成のオンライン申請，自動化前述の通り，本学においては，利用者による申請に基づきチーム提供を行う方針とした．チームの利用者（＝申請者）と管理者双方にとって効率的にチームの作成を行うシステムが必要となる．本学においては，Microsoft Power Platform[6]を活用したオンライン申請・チーム作成システムを構築した[7]（図5）．以下の機能群により，オンライン申請・チーム作成の自動化を実現する．
新規チーム登録手続きは，（a）チーム名や利用目的を記載するオンライン申請フォーム（Formsによる利用者ユーザインタフェース），（b）申請内容の承認，データ管理，新規チーム登録処理等のワークフロー定義（Power Automateによるワークフロー定義），（c）申請内容，新規チーム登録結果等のデータ記憶（SharePoint Listsによるデータ管理）（d）申請内容に基づき，PowerShellによるチーム登録処理の実施（オンプレミス側の連携処理）の機能群で構成される．
上記の手順により，Formsを用いた申請後に承認者がTeams上で決裁処理を実行するのみで，新規チームの作成と申請者への通知が完了する．決裁処理承認後のPowerShellによるチーム登録処理に関する所要時間については3分程度で完了するため，即日でのチーム利用が可能である．これらの処理を手作業で実施する場合，申請内容の確認・チーム作成のパラメータ生成，生成実行・登録結果の記録を実施することとなるため数時間を要し，加えて複数の申請が同時になされた場合は数営業日を要すると考えられる．
なお，本システムにおいて作成されるチームはプライベートチームとして作成するため，テナント全体への公開は抑制される．
4.2 チーム年次更新のオンライン申請申請内容や新規チーム登録結果はSharePoint Listsに蓄積しているため，Listsを活用し，チームの年次更新の確認を実施する．年次更新システムは，申請者に承認された利用中のチームに関する情報をListsのビュー機能により提示し，次年度の継続利用についてオンライン上で回答が収集可能な構成としている（図6）．
本学においては，チームの作成と年次更新を承認制とするため，申請システムを構築し，申請者情報等の管理データを保有する構成としている．
本学のM365の設定においては，ユーザによるチームの作成は抑制しているものの，削除は可能であることから，管理データとの不整合が生じる可能性がある．
この問題への対処として，年次更新時に，管理データ上と実際に存在するチームの比較を行い，管理データの更新を実施している．また，年次更新時にチームの申請者（所有者）が退職となっている場合は，年次更新の回答がなされない事が問題となる．現在は手作業にて後任の所有者への更新を実施する運用となるが，自動化を要する課題となる．
本節では，2022年5月からのチームの利用状況ならびに，本学が採用したM365の運用手法と他機関の手法を比較する．
5.1 本学における利用状況M365の設定値変更については，グループ作成権限の変更については2016年度に既に実施していたが，その他の制限付加については，2021年度に適用を完了した．その後，手作業でチームを作成し，ゲストアクセスやファイル共有の制御が有効に機能していることを確認し，2022年5月より正式にオンライン申請によるTeamsの展開を開始した．
開始年度である2022年度に，合計78件の新規チーム申請について承認した．翌年度の2023年度には，合計63件の新規チーム申請について承認した．2024年5月末現在では約200チームが稼働している．申請されたチームの割合は，研究室向けが最も多く，事務（係単位）・技術部・本部内室等の長期利用が見込まれるチーム，時限付きと見込まれるタスクフォースやプロジェクトと利用範囲は多岐にわたる．
年次更新については，2022年度末である2023年1月ならびに2023年度末である2023年2月に更新に関する通知を実施し，それぞれ年度末月となる3月までに回答を要求した．こちらも，前述のSharePoint Listsのビューを活用したオンラインシステムにより，Excel形式等によらない回答収集が可能であった．
2022年度の年次更新対象となる78件のチームのうち，70件が継続回答となった．また，2023年度の年次更新対象となる133件のチームのうち，118件が継続回答となった．継続を希望しないチームを調査したところ，チームの名称に年度が付された研究室向け用途が主であった．
ここで一例となるが，Teamsに移行後の電子メールの利用率の変化について考察する．筆者が所属する本学情報基盤センターにおいては，日常の業務連絡や調整に専用のメーリングリストを利用していた．2022年5月のTeams正式運用後，チーム上のチャネルを作成し，業務連絡や調整に関するチャネルへの投稿が進んだ．図7に，2021年から年次のMLへの投稿数とチャネルへの投稿数の推移を示す．
Teams導入前においては，MLへの投稿数は月平均167通であった．投稿先をTeamsに切り替える強い要請は行っていないものの，急速にチャネルへの投稿へ変化し，現在ではMLの投稿数は月平均16通（チーム作成前の0.096倍）である．
チャネルへの投稿数は月平均224通と，ML利用時の1.34倍となっている．チャネルへの投稿は短い文書での返信等が気軽に行えるため，投稿数が増加していると推察される．このように，電子メールからの脱却が順調に進んでいると考えられる．
5.2 他機関におけるTeamsの運用方針に関する事例M365およびTeamsの運用方針について，他機関の事例と本節で述べた本学の手法について比較を行う．他機関の事例として，本稿では独立行政法人国立高専専門学校機構（高専機構）における事例を対象とする．
高専機構はコミュニケーションツールとしてM365を採用し，各高専向けに提供を行っており，グループ，Teams利用，ファイル共有時の運用方法や注意点が文書として通達されている[8]．高専機構においては，チームやSharePointサイトの作成は利用者が自由に行う事が可能である．また，一年間アクティビティがないチームを自動削除する運用により，チームの棚卸しが自動化されている．対して，チームやSharePointサイトの作成時に公開範囲をパブリック設定にすることが可能であることや，共有範囲に制限がないファイル公開が可能であることなど，アクセス権限の設定が利用者の裁量に任されている．なお，文書により，アクセス権限の設定については留意することや，情報流出やインシデントへの注意喚起が通達されている．
本学においては，利用者に対する制限を強めるM365の設定を適用し，利用者の操作や判断ミスによる情報流出をシステム側で抑制する手法を採用している．また，チームの棚卸しについては，年次更新システムにより利用者の意思を確認する運用としている．本学の手法は，これらの点が比較対象とした他機関と異なり，新規性を有するものである．
本論文では，本学におけるTeamsの全学展開について，経緯や導入の際の検討事項を中心に述べた．メールに代わるコミュニケーションツールの導入検討を行う際，チャットツール・オンラインストレージ・会議ツール等を組み合わせたシステムが必要となる．M365を導入する機関においては，必要な機能が全て包含されるTeamsは有力な選択肢となる．
しかし，M365テナントの初期設定においては，ゲストユーザの取り扱いや権限，ファイル共有の権限について自由度の高い設定値が採用されており，そのままの状態でのTeams展開は懸念がある．本稿では，ガバナンスを強化した状況でのTeams展開が可能な状況とする設定値の変更について述べた．
加えて，利用者からの申請に基づくチーム作成と休眠状態を防ぐための棚卸となる年次更新の必要性ならびに，それらの自動化・オンライン化手法について述べた．本学においては，Power Platformを用いたオンライン申請と自動化，SharePoint Listsを用いた年次更新のオンライン化について実装し，利用者へ提供している．
2022年度にTeamsの正式運用開始後，既に200以上のチームが稼働している．加えて本学においては，2024年度より構内電話のMicrosoft Teams電話[9]への全面移行を進めており，係・事務室等の窓口となる電話については，対応するチームに電話着信する運用方針とした．本運用方針により，2024年度は窓口数となる215以上のチームが追加稼働する計画である．また，本学では授業用を含めたビデオ会議ツールに関して，2025年度よりZoomからTeamsへの全面移行が計画されており，会議用のチーム申請の増加が見込まれる．
今後は，教職員向けのメール通知，学内メーリングリスト，機材からのアラート通知等，メールでの運用が残っている部分のTeamsへの転換に関する検討を進める．
