UTokyo Azure: クラウドコンピューティングサービスの学内展開

Abstract

本稿では，東京大学において全学向けに展開しているMicrosoft Azureの研究利用に関して，そのサービスの設計と運用状況について報告する．2023年8月に東京大学とマイクロソフトコーポレーションとの間で締結された基本合意書に基づき，東京大学に対してMicrosoft Azureを研究目的で利用するためのギフトクレジットが寄付された．このギフトクレジットを学内の幅広い研究者に分配し，研究に活用できる仕組みとして，我々はUTokyo Azureを構築し2024年12月よりサービスを開始した．UTokyo Azureの実現にあたっては，学内に数千人規模のAzure利用者が存在しうる状況を想定して，学内の構成員アカウントとAzureにおけるリソース分離をマッピングする設計を導入し，さらに利用者による申請からデプロイまでを自動化するWebアプリケーションを開発して運用を行っている．本稿ではこのMicrosoft Azureの学内展開を担う一連のサービスであるUTokyo Azureの基本方針，設計，そして運用開始から約半年が経過した現在の運用状況について述べる．

1　  はじめに

2023年8月に東京大学とマイクロソフトコーポレーションとの間で締結されたGX，D&I，AI研究の推進に向けた連携に関する基本合意書に基づき^[1]，2024年10月，マイクロソフトコーポレーションより，同社のクラウドコンピューティングサービスであるMicrosoft Azureを利用するためのギフトクレジット（総額1,000万ドル，提供期間5年間）が本学に寄付された．今日の研究活動では様々な分野において計算資源の利用は不可欠であり，生成AIの利用領域も急速に広がっている^{[2, 3]}．Microsoft Azureは一般的な仮想マシンに加え，幅広いクラウドサービスを提供しており，本ギフトクレジットは分野を問わず幅広い研究領域において活用されることが期待される．

本学構成員がギフトクレジットを用いて幅広くMicrosoft Azureを研究に活用できるようにする一連のサービスをUTokyo Azureと名付け，東京大学情報基盤センター，情報システム部，情報システム本部が共同でその運用を担うこととなった．UTokyo Azureの設計および運用にあたって定めた基本方針が以下である:

1．研究・教育目的であれば分野を限定せず，広く利用可能とする．

2．申請の敷居を低くし利用開始までのタイムラグを短くする．

3．ギフトクレジットは有限であるため，なるべく公平に（例えば早い者勝ちにならないように）分配する．

ギフトクレジットの分配に際し，例えば競争的資金のように研究提案書を作成し，審査結果に基づいてギフトクレジットを分配する場合，申請側・審査側の双方に多大な労力がかかり，幅広い分野で活用してもらうことも難しくなる可能性がある．そこでUTokyo Azureでは1と2の方針を定め，申請資格を教職員に限定しつつも，研究目的であれば原則として審査なしで利用を許可する運用とした．一方で，本学の教職員であれば利用申請が可能であることから，利用者に対してある程度公平性を担保した上でギフトクレジットを分配する必要がある．これを実現するため，月ごとにUTokyo Azure全体の目標消費量をあらかじめ設定し，実際の消費量が目標消費量を超過した場合に限り，利用者が使用量に応じて超過分を負担しクレジット残量に充当する方式を定めた．このように利用者に対して請求が発生する可能性があるため，UTokyoAzureの利用を申請できるのは予算執行権限を有する教職員に限定している．

現在 UTokyo Azureは，（1）本学の教職員が利用を申請，（2）申請ごとに分離された仮想資源を利用，（3）ギフトクレジットは一定の公平性をもって利用者に分配し，全体の利用状況に応じて超過分の費用を利用者が負担するという仕様で学内に展開されている．本稿では，2節でUTokyo Azureの全体的なサービス設計について説明し，3節でギフトクレジットの分配方法について述べる．4節ではMicrosoft Azureにおけるギフトクレジット利用に起因する課題について整理する．5節では開発環境について説明し，最後にサービス開始から約半年が経過した時点での運用状況を報告する．

2　  UTokyo Azureの設計

本節ではMicrosoft Azureのギフトクレジットを学内に展開するための一連の仕組みであるUTokyo Azureの設計について述べる．UTokyo Azureを設計する上でとくに検討を要したのが以下の3点である．

1．利用者ごとのAzure上の仮想資源の分離方法

2．申請から承認およびデプロイプロセスの自動化

3．ギフトクレジットの分配方法

本節ではAzureの利用と密接に関連する1と2について説明する．

2.1  Azure上の権限管理と仮想資源の分離

UTokyo Azureを利用する研究者は，個人または複数人によるプロジェクトで研究を遂行する．そのため，Azureの利用にあたっては，当然それらのプロジェクトごとにAzure上の仮想資源を分離する必要がある．Azureにおいて資源を分離する箱となる仕組みはいくつかあるが，UTokyo Azureでは最終的にサブスクリプション単位で資源を分離する構成を採用した．

図1に，UTokyo Azureにおける利用者ごとの仮想資源の分離の概要を示す．Azureでは，サブスクリプションと呼ばれる単位に対して課金情報が紐づけられており，仮想資源の管理権限が分離されている．具体的な仮想資源（仮想マシン，IP アドレス，ストレージ，生成AIモデルなど） は，リソースグループと呼ばれる単位でまとめられ，ひとつのリソースグループは必ずひとつのサブスクリプションに紐づく．あるサブスクリプションに対して閲覧や操作の権限を持つアカウントは，そのサブスクリプションに紐づくリソースグループに対しても同様の操作が可能である．誰がどのサブスクリプションやリソースグループに対してどのような操作を実施できるかは，Azure Role-Based Access Control（RBAC）と呼ばれる仕組みで，Entra ID で識別されるアカウントごとに細かく制御することができる．

図1　 UTokyo Azureにおける権限及び仮想資源の分離の概要．UTokyo Azureを利用したい教職員は新規のサブスクリプションをフォームから申請する．教職員は自身のサブスクリプションを利用させたい者（例えば研究室の学生など）の学内アカウントにAzure上で適切なロールを割り当てることで，利用者を管理することができる．

サブスクリプション単位で資源を分離するということは，利用者ごとに専用のサブスクリプションを割り当てることを意味し，利用者はそのサブスクリプション内で自由にAzureのサービスを利用できると同時に，そのサブスクリプションの費用に対する責任を負うことになる．サブスクリプション単位で分離する以外にも，複数のサブスクリプションを一元管理する管理グループ^[4]や，ひとつのサブスクリプション内で資源を分けるリソースグループ単位での分離も検討されたが，サブスクリプションが請求の単位であること，また一人の利用者が複数のサブスクリプションを利用したり，逆にひとつのサブスクリプションを複数人で利用したりすることも可能であることから，最もシンプルかつ管理しやすい方法としてサブスクリプション単位での分離を採用するに至った．

図1に基づいて，利用者の申請から利用開始までの流れを説明する．東京大学では構成員が持つ学内アカウント（UTokyo Account）の管理にMicrosoftのEntra IDを用いており，Azureにおける利用者のアカウンティングにもUTokyo Accountをそのまま用いている．❶UTokyo Azureの利用を希望する教職員（申請者/利用者）は申請フォームから新しいサブスクリプションを申し込む．❷UTokyo Azure管理者は申請を受けて新規のサブスクリプションを作成し，❸申請者のUTokyo Accountに対して作成したサブスクリプションの所有者ロールを割り当てる．所有者ロールはAzureの組み込みロールのひとつであり^[5]，RBACによる権限の再割り当てを含む全操作が可能である．所有者ロールの割り当てが完了した時点で，申請者はAzureポータル（https://portal.azure.com/）から作成されたサブスクリプションに紐づく形で，任意のAzureのサービスを利用できる状態となる．

サブスクリプションの所有者ロールを持つ者は，❹自身のサブスクリプションにおいて資源を操作できる別の利用者をRBACで追加することができる．これは例えば，教員がサブスクリプションを申請し，研究室の学生にAzureを利用させる場合などに有用である．教員が学生のUTokyo Accountに対して，RBACの割り当て変更以外全ての操作を実行できる共同作成者ロールを割り当てることで，学生は任意のAzureのサービスを利用することができる．また所有者ロールを他の研究者に割り当てることでサブスクリプションを他者に引き継ぐことも可能である．この引き継ぎ機能は，構成員が頻繁に入れ替わる大学においては重要であり，サービス設計段階から考慮された．なお，一人の教職員が複数のサブスクリプションを申請することも可能である．

2.2  サブスクリプション作成の自動化

利用者による新しいサブスクリプションの申請にはじまり，サブスクリプションの作成，申請者のUTokyo Accountへの所有者ロールの割り当て，そして申請者への準備完了通知にいたる一連のプロセス（図1中 ❶から❸）は内製のプログラムによって自動化されている．図2は，Webアプリケーションとして実装した新規サブスクリプションの申請フォームである．利用者はUTokyo Accountによる認証を経てこのページにアクセスし，サブスクリプションを申請する．申請に際して入力する項目は，申請者の情報と簡単な利用目的，そして分野の選択のみとし，UTokyo Azureの利用開始にかかる敷居をなるべく低くし，様々な分野の研究者に対して広く利用を促す仕組みとしている．

図2　 新規サブスクリプションの申請フォーム

申請が送信されてから利用開始に至るまでの一連の処理フローを図3に示す．図3中，黒い四角で示されているのは申請されたサブスクリプションのステートであり，定期的に実行されるバッチプログラムの中で管理される．新しい申請はまずINITステートとしてデータベースに保存される．バッチプログラムはINITステートの申請があると，対応するサブスクリプションをAzure上に作成し，ステートをCREATEDに進める．続いてバッチプログラムは，CREATEDステートのサブスクリプションをUTokyo Azureでギフトクレジットを消費する全てのサブスクリプションが含まれている管理グループに追加し^1），UTokyo Azure管理者に新しいサブスクリプションが作成されたことを通知して，ステートをNOTIFIEDに進める．この時点では当該サブスクリプションはまだギフトクレジットの消費が有効化されておらず，通常のサブスクリプションと同様に課金・請求が行われる状態である．

図3　 申請されたサブスクリプションの処理フロー．黒字で示された操作はプログラムによって自動化されている．

UTokyo Azure管理者は，NOTIFIEDステートの通知をメールで受け取り，申請内容を確認する．この確認作業は稀に発生しうる何らかの間違い，例えば学生による申請や明らかに研究目的ではない利用などを未然に防ぐためのものであり，基本的には研究目的であれば申請は承認される．申請の承認とは，具体的には当該サブスクリプションに対するギフトクレジット消費を有効化する操作をさす．Microsoft Azure Sponsorshipsの専用のページ^2）で，Azure組織契約（Enterprise Agreement）に含まれるサブスクリプションとして，ギフトクレジットの消費を有効化するかどうか選択することができる．ここでギフトクレジットの消費が有効化されたサブスクリプションは，Offer IDと呼ばれるフィールドの値が0136Pに変更される．バッチプログラムはAzureのREST APIから取得するOffer IDの値をサブスクリプションごとに確認し，0136Pの場合に該当サブスクリプションのステートをSPONSOREDへと進める．バッチプログラムはSPONSOREDステートのサブスクリプションについて申請者のUTokyo Accountに所有者ロールを付与し，最後に申請者に対して準備完了通知をメールで送信する．

以上のように，サブスクリプションの申請から利用準備完了に至るプロセスの大部分は自動化されており，UTokyo Azure管理者の作業は，通知メールの確認とサブスクリプションごとのギフトクレジット消費の有効化のみとなっている．UTokyo Azureが運用を開始した 2024年12月から2025年6月現在，教職員が新しいサブスクリプションを申請してから利用開始までのリードタイムは概ね1営業日以内となっている．

3　  ギフトクレジットの分配

ギフトクレジットは有限であるため，誰でも無制限に無料で利用できるわけではない．利用者に対して何らかの指針に基づいて公平に分配する必要がある．UTokyo Azureでは，なるべく多くの人にAzureを利用してもらいつつ，一時的に大量の計算資源を必要とするケース（＝大量のギフトクレジットの消費）も許容するため，次のようなルールを定めた．

1．ギフトクレジット（1,000万ドル）を寄付期間（60 ヶ月）で均等に消費した場合のクレジット残量を目標残量として定める．

2．月初時点のギフトクレジット残量と，翌月開始時点の目標残量の差分を，当月の全体無料分とする．

3．月末に，月初に決定された全体無料分を各サブスクリプションの重みに基づいて分配し，当月の使用量を相殺する．

4．使用量が分配された無料分の範囲内であれば，利用者の支払いは発生しない．超過した場合は，超過分を支払う（支払われた分は翌月開始時点のギフトクレジット残量として充当される）．

図4は，目標残量と全体無料分の関係を視覚的に表したものである．月末時点で実際のクレジット残量が目標残量を上回る場合，全サブスクリプションの使用量が分配された無料分で相殺され，利用者に請求は発生しない．UTokyo Azure全体でギフトクレジット残量が目標残量を上回る月が続けば，その差分は翌月へ繰り越され，次月の全体無料分が大きくなる．一方，月末のクレジット残量が目標残量を下回った場合，無料分を超過したサブスクリプションに対して請求が発生し，翌月のクレジット残量に充当される．以上のように，月単位でUTokyo Azure全体で使用量が少なければ無料で使える全体無料分が増えてゆき，使用量が多くなる（実際の残量が目標残量を下回る）と，超過分を回収する仕組みとなっている．なおサブスクリプションの重みは，各月の初めにそのサブスクリプションにロールを持つUTokyo Accountの数$n$と係数$a$に対して$a\frac{n}{1+lo{g}_{10}n}$で決定される．つまり，サブスクリプションを利用している人数に応じて緩やかに重みも増加する．係数$a$は基本的に1であるが，全学的に重要なプロジェクトなど，特別な事情がある場合には特定のサブスクリプションの$a$の値を例外的に大きくすることで多くの無料分を割り当てることができる．

図4　 ギフトクレジットの目標残量とある月の無料分の決定方法

これまでに述べた月ごとの無料分と分配に加えて，よりUTokyo Azureを利用しやすくするための仕組みとして無料保証枠と超過分の繰越がある．無料保証枠とは，月初の時点で各サブスクリプションに分配することが確定している無料分のことである．利用者は，使用量が無料保証枠を超えない範囲であれば支払いが発生しないことが保証されている．これは利用者がより気軽にUTokyo Azureを試用できることを目的としている．一方，超過分の繰越とは，月末時点で発生した超過分を翌月の使用量に繰り越すことである．実際には半期単位（4月～9月，10月～翌年3月）の中で超過分を翌月に繰り越し，実際の請求は9月末と3月末の年2回実施する．この仕組みにより，例えば5月に一時的に大量の資源を利用して超過分が発生したとしても，その後9月末まで使用を控えれば，超過分をその間の無料分で相殺することができる．

利用者は，2.2節で述べたサブスクリプション申請用のWebアプリケーションから，自身が所有者ロールを持つサブスクリプションの過去から現在までの月毎の使用量と無料分および無料保証枠（図5），そして図4に相当するUTokyo Azure全体のギフトクレジット残量と目標残量のグラフを随時確認することができる（図6）．利用者はUTokyo Azure全体の無料分を確認しながら，必要に応じてAzureの資源を利用する．

図5　 サブスクリプションの過去から現在までの月毎の使用量と無料分および無料保証枠

図6　 UTokyo Azure全体のギフトクレジット残量と目標残 量のグラフ

4　  ギフトクレジットの利用にかかる事象

ギフトクレジットはMicrosoft Enterprise Agreement（EA）用Azureスポンサープランとして提供されており，このAzure EAスポンサープランにおける利用形態には通常のAzure利用とは異なる点がある．そのひとつが2.2節で述べたMicrosoft Azure Sponsorshipsページにおけるサブスクリプションごとのギフトクレジットの有効化である．ギフトクレジットが有効化されたサブスクリプションは，その使用量（ギフトクレジットの消費量）を確認できるのはSponsorshipsページ上のみであり，通常のAzureポータルの課金画面では使用量が表示されなくなる．こうした仕様を補完するため，UTokyo Azureでは内製のWebアプリケーションおよびバッチアプリケーションで，以下の機能を利用者に提供している．

・使用量と内訳の表示機能：Sponsorshipsページから取得した使用量データをもとに，Webアプリケーション上で利用者がロールを持つ各サブスクリプションの使用量とその内訳を表示する．

・使用量アラート機能：使用量が一定の割合を超えたサブスクリプションについて，その所有者にアラートをメールで通知する．これは，Azure EAスポンサープランではCost Managementのアラート機能が利用できないため，内製のプログラム側にアラート機能を実装している．

・サブスクリプションの自動停止機能：Azure EAスポンサープランでは，使用量に対して事前にクォータを設定することができない．そのためUTokyo Azureでは，あるサブスクリプションの使用量がそのサブスクリプションの無料保証枠を超えたことをバッチプログラムが検知すると，該当サブスクリプションを自動的に停止する．利用者はWebアプリケーション上で支払いに用いる予算を登録することで，このサブスクリプションの自動停止を無効にすることができる．

5　  Webアプリケーションの開発・運用

サブスクリプションの申請や作成を行うWebアプリケーションは表1に示す環境などを用いて開発したものであり，UTokyo Azure上のLinux VMで動作している．主な機能は約8000行のpythonプログラムとして実装されており，ウェブフロントエンドやバッチプログラムはそれぞれpodmanを用いてコンテナ化してデプロイされている．保存するデータの量はサブスクリプションの数に比例するが，全体のサイズ自体は大きいものではないため，必要なデータの格納にはSQLiteを用いた．2025年現在アプリケーションの開発とサーバ運用は教職員4名で実施している．

表1　Webアプリケーションの開発・実行環境

構成要素	使用したプログラムやサービス
プログラミング言語	python 3.12
Webフレームワーク	Flask
認証	Flask-Dance
フロントエンド	Bootstrap
グラフ描画	Chart.js
メール送信	Azure Logic Apps
OS	Ubuntu 24.04
コンテナ管理	podman
データベース	SQLite
コード管理	GitHub private repository

6　  2025年6月現在の運用状況

UTokyo Azureは2024年12月より学内向けサービスとして運用を開始し，2025年6月時点で305個のサブスクリプションが存在している．図7はサブスクリプション申請時に申請者が入力した，科研費の審査区分^[6]に基づく分野ごとのサブスクリプション数の割合を示す．情報科学，情報工学分野がもっとも多く全体の24%を占める．一方で，サブスクリプションは全体で57分野に渡っており，理学分野（惑星科学，天文学など）や工学分野（電気電子，原子力，航空宇宙など）にとどまらず，文学，法学，心理学といった人文，社会科学系の分野においてもAzure の利用が試行されていることが分かる．こうした多彩な分野からの申請は，今日の学術研究において計算資源の重要性が高まっていることの証左であると同時に，UTokyo Azureの設計において定めた，分野を問わず，研究・教育目的であればすぐに利用を開始できることを重視した方針が奏功しているものと考えられる．

図7　 2025年6月までに申請されたサブスクリプションの分野ごとの割合． 分野は科研費審査区分の中区分^[6]に基づく．

図8にサービス開始からの累計サブスクリプション数の推移を示す．サービス開始から概ね単調にサブスクリプションの数は増加している．2025年2月後半に大きな増加が見られるのは，同時期に開催された学内向けのUTokyo Azure利用説明会の影響と考えられる．今後も学内におけるサービスの認知度が上がるにつれ，サブスクリプション数はさらに増加することが予想される．

図8　 UTokyo Azureでこれまでに作成されたサブスクリプションの累計

UTokyo Azureをより多くの構成員に使ってもらうため，ウェブサイトでの情報提供や，Slack上でのコミュニティワークスペースの設置，そしてオンライン説明会などを実施している．ウェブサイト^[7]では，Infrastructure as aService（IaaS）型のクラウドとして代表的なサービス（仮想マシンの作成方法，生成AI関連のサービス，ストレージの利用方法など）について，簡単なチュートリアルを掲載している．また2.1節で述べた仮想資源の分離とRBACによる権限の移譲・操作方法についてもウェブページ上で解説している．RBACの権限モデルなどはクラウドサービス特有の仕組みであり，情報系以外の研究者にとっては時として難解である．今後も利用者からのフィードバックを踏まえつつ，必要に応じて利用者をサポートするコンテンツを拡充していく予定である．

7　  むすび

本稿では，ギフトクレジットを活用したMicrosoft Azureの利用を学内に展開するサービスであるUTokyo Azureについて，その設計と運用状況を報告した．UTokyo Azureの設計にあたっては，幅広く研究・教育での利用を促進するため，研究目的であれば学内の教職員が誰でも簡単に申請できる仕組みとし，申請から利用開始までのリードタイムも概ね1営業日以内と，プロセスの自動化による迅速なサービス提供を実現した．また Entra IDで管理される学内構成員のアカウントを活用して，サブスクリプションとRBACを用いた権限管理と資源の分離を行っている．2024年12月のサービス開始から約半年間で，すでに57の分野において300以上のサブスクリプションが作成された．今後もUTokyo Azureでは，本学の多くの構成員に，簡易な手続きで始められ，小規模な研究プロジェクトでも迅速にスタートアップできる環境を提供し，研究・教育の加速に貢献することを目指していく．

最後に，本稿ではMicrosoft Azureの利用に特化した内容を報告したが，多くのIaaS型クラウドサービスが資源分離やRBACといった同様の仕組みを備えている．大学において学内向けに広くIaaSサービスを提供する際の参考事例として，本稿がその一助となることを期待するものである．

注

1）  管理運用上，全ての サブスクリプションをひとつの管理グループにいれているが，ギフトクレジットを使用する上で必須の操作ではない．

2）  https://www.microsoftazuresponsorships.com/

参考文献

• [1]  東京大学とマイクロソフト，基本合意書を締結 ～GX・D&I・AI研究の推進に向けて連携～. https://www.u-tokyo.ac.jp/focus/ja/articles/z1701_00012.html.
• [2]   T. L.  McIntosh,  E.  Verleye,  J. K.  Balch, et al.: Cyberinfrastructure deployments on public research clouds enable accessible environmental data science education. In Practice and Experience in Advanced Research Computing 2023: Computing for the Common Good, PEARC ’23, pp. 367–373, New York, NY, USA, 2023, Association for Computing Machinery.
• [3]   J.  Boyko,  J.  Cohen,  N.  Fox, et al.: An interdisciplinary outlook on large language models for scientific research, 2023.
• [4]  管理グループを使用してリソースを整理する - Azure Governance - Azure governance— Microsoft Learn. https://learn.microsoft.com/ja-jp/azure/governance/management-groups/overview, 2024.
• [5]  Azure 組み込みロール - Azure RBAC — Microsoft Learn. https://learn.microsoft.com/ja-jp/azure/role-based-access-control/built-in-roles, 2025.
• [6]  審査区分表（中区分，大区分一覧）. https://www-kaken.jsps.go.jp/kaken1/daichukubunList.do.
• [7]  UTokyo Azure — utelecon. https://utelecon.adm.u-tokyo.ac.jp/research_computing/utokyo_azure/.