Amazon Web Services ブログ
東京大学 松尾・岩澤研究室主催の AI エンジニアリング実践講座にて、1400 名を超える受講者に AWS 上でのクラウド開発を体験していただきました [ 準備、構築編 ]
本ブログは、東京大学松尾・岩澤研究室が主催する AI エンジニアリング実践講座において、AWS を活用した講座の取り組みをご紹介する、AWS との共同寄稿です。
はじめに
本ブログシリーズでは、2025 年 4 月から 7 月にかけて実施した東京大学 松尾・岩澤研究室の AI エンジニアリング実践講座において、 AWS クラウドを活用した実践的な学習環境を用意し、1400 名を超える受講申し込み者に対して、個別のAWSアカウントを提供する大規模なオンライン講義を開講した取り組みを全 3 回に分けてまとめたものです。
- [準備、構築編] 講義に参加する受講生に AWS アカウントを準備し、受講者情報と紐づける（本ブログ）
- [演習、運用編] それぞれのAWSアカウントに適切な権限を配布し、提供期間中管理/運用する
- [後片づけ編] 講義終了後に、適切にアカウントをクリーンアップする
講義概要
東京大学 松尾・岩澤研究室では、最新の AI（人工知能）・データサイエンスに関心のある幅広い層に向けた公開授業を開催しています。これらの講座は全国の学生（大学院生、大学生、短大生、専門学校生、高校生、中学生）や一般の社会人の方も受講可能です。AI 基礎知識からディープラーニング、アントレプレナーシップまで幅広いテーマを扱います。
最大の特徴は松尾・岩澤研究室の研究員や学生、卒業生が教材開発・指導を担当し、最新の基礎研究成果を直接講義に反映している点です。オンラインを中心としながらも一部対面ワークショップを取り入れ、実践的なプログラミング技術習得を重視しています。講義は質の高い AI 教育を広く提供し社会変革につなげることを目的としており、若手研究者・エンジニア・起業家の育成を通じて日本の IT 競争力向上を目指します。
クラウド活用講義 ＋ アプリケーション構築演習
今回開催したのは「AI エンジニアリング実践講座 2025」です。本講座はAIを実践的に活用するためのエンジニアリングや AI システムの改善方法について講義と演習を通して学ぶ内容で、2025 年 4 月から 5 月の全 6 回のカリキュラムで開催されました。AI の活用には、モデル理解だけでなくWebアプリ開発、クラウド、データ処理、CI/CD など幅広いエンジニアリング知識が必要です。本講座では、座学に加えて AI アプリケーション構築を通じて実践的なスキルを習得することをゴールと設定しました。全 6 回の講座は演習・ハンズオンを重視し、要件定義から MVP 開発、デプロイ、改善までのサイクルを体験できる構成で、実務に近い環境で機械学習エンジニアリングを学び、課題対応力や運用スキル、プロジェクト推進力を養うことを目的としています。
講義では座学と演習を通じて AI 活用に必要な様々なエンジニアリング知識を習得でき、要件定義から評価セット作成、システムデプロイまでの開発プロセス全体を体験できます。さらに、MLOps やモデル劣化など AI 実務上の問題とその対処法についてもコンテンツとして学ぶことができました。
本講座の特徴の一つとして、アプリケーション開発を知識として習得するとともに演習・宿題を通して実体験として理解を深めるコンテンツとなっています。AI アプリケーションの開発ではプロトタイプ / MVP の作成から商用レベルのシステム開発までを迅速かつ継続的に改善のループを回しながら開発していくことが多く、その際にスモールスタート可能で規模に応じたインフラを準備することができるクラウドサービスを活用することはとても親和性の高いものであり、必須の知識として今回の講座の内容に含めています。そのため特に今回の講座では、演習用のデモ環境等ではなく、実際の開発と可能な限り近い形の演習を用意することを重要な要件の一つとしていました。
これまでにも、クラウドサービスの環境を活用した講義を実施することはありましたが、小規模かつ単発での講義がほとんどで、加えてこちらの用意した仮想的なインターフェース経由での利用にとどまっており、今回のように1000名を超える参加者が、リアルタイムにクラウド環境に直接アクセスして操作することや、講義後のオンデマンドで環境にアクセスするようなコンテンツは存在しませんでした。そこで、松尾研究室の担当者である増田氏が、AWS の大学担当のアカウントチームと複数回のディスカッションを持ち、どのような方策が最適か検討を始めました。クラウドが持つ柔軟性やサーバレスで構成された開発環境に、学生が別環境で作成したコードを当てはめるような、クラウド開発と CI/CD の両方を経験できるコンテンツを行いたいということを勘案し設計しました。
マルチアカウント環境の設計方針
今回の講座では、より実践的な内容を学んでいただくことを重視しており、可能な限り実際に受講者が今後クラウドを利用する際と同じ状況を体験いただきたかったため、AWS コンソールを直接触っていただけるように設計しています。また、受講者側の習熟度も大きく差があるため、ユーザー間の影響を最小限にし、可能な限り安全かつ自由に利用してもらえるような環境を作りたいという要件のもと相談しながら設計していきました。選択肢としては、大きく分けて、
- シングルアカウントにそれぞれのユーザーの権限を絞って提供する
- マルチアカウントで複数ユーザーをある程度まとめて提供する
- マルチアカウントで 1 ユーザーに 1 アカウントを提供する
がありました。今回は最もユーザー側の自由度が高い 1 ユーザーに 1 アカウントを提供するというマルチアカウント方式を選択しました。短期間での 1000 を超えるアカウントの作成や管理は、AWS側にも実績がありませんでしたが、 AWS 側のサポートを受けることで最終的に1ユーザーに 1 アカウント提供するという最もユーザー側の自由度が高いマルチアカウント方式で提供することができました。AWS は通常の開発においても目的に応じたマルチアカウントの運用が推奨されており、 AWS Organizations や AWS IAM Identity Center などの複数アカウントの権限管理を効率化するサービスが提供されています。今回はそれらの機能を活用することで、リスク管理や運用管理の効率化を実現しました。
AWS Control Tower を使わない判断
AWS のマルチアカウント環境のガバナンス管理では、 AWS Control Tower が広く活用されています。このサービスは、セキュリティとコンプライアンスのベストプラクティスに基づいた LandingZone を設定し、安全なマルチアカウント環境をセットアップおよび管理できます。しかし本プロジェクトでは以下の制約や要件がありました。
- 決められた期間内に、大量の AWS アカウントの作成をする必要があったが、Control Tower 適用時に同時操作可能なアカウント数の上限 (Concurrent account operations quota ：デフォルト: 5 アカウント同時操作、申請による上限緩和で最大: 10 アカウント同時操作) があった。加えて、Control Tower 配下で AWS アカウント作成すると、初期処理に一定の時間を要するため、大量の AWS アカウントを短期間に作成することができない。
- これらのアカウントは、一時的な利用と利用後のアカウントのリセットを予定しており、全体をシンプルに統制したい。
これらの個別要件を考慮し、AWS のソリューションアーキテクトと相談した結果、Control Towerを断念し、AWS Organizations と IAM Identity Center のセットアップを行うことで、短期間で確実に大規模なマルチアカウント環境を構築する方針を採用しました。
演習環境の事前準備
全体構成
図 1: マルチアカウント管理の全体構成
マルチアカウント管理
マルチアカウント管理を実現するために AWS Organizations の管理アカウントを作成し、管理アカウント上で Organization を作成しました。Organization を作成後、演習用のメンバーアカウントを作成しましたが、1400 以上のアカウントをコンソール上で作成するのは大変なため、AWS Command Line Interface (CLI) を用いて作成を行いました。Organization のメンバーアカウントは aws organizations create-account コマンドを利用することで簡単に作成が可能です。実際にはスクリプトで大量のアカウントを 1 アカウントあたり数秒程度で作成を完了しました。作成の際のポイントをいくつかご紹介します。
- クォータ増加申請
AWS Organizations の初期値として組織内のアカウント数 (Default maximum number of accounts) が 10 となっていたため、これを引き上げました。新規に作成した実績なしの組織でいきなり 1000 以上の数値での申請になりましたが、 AWSとの連携によりスムーズに増加処理が実施されました。作成に関わるクォータとして 同時に作成できるメンバーアカウントの数 (Member accounts you can concurrently create) の値 (初期値 5) の増加も検討しましたが、作成時のスクリプトに失敗しても数秒待ってリトライをする処理を入れることで、初期値のままで大量のアカウントを作成することができたため今回は増加申請をしていません。 - アカウント用の root メールアドレスの用意
それぞれの AWS アカウントには一意のメールアドレスを紐づける必要があります。これらは重複が不可なため結果として 1400 以上の異なるメールアドレスが必要となります。こちらについては東大松尾・岩澤研究室では Google Workspace を利用していたためメールアドレスに+を利用した Gmail のエイリアス機能を利用することで大量のメールアドレスを擬似的に用意し、それぞれのアカウントの root メールアドレスとして利用しました。 - Organizational Unit の作成とサービスコントロールポリシー (SCP) の適用
AWS Organizations の配下で Organizational Unit (OU) というAWSアカウントをまとめるグループを作成した上で、そのグループに対してサービスコントロールポリシー (SCP) を設定する事により、AWSアカウント内で実行できる事、できない事を一つのポリシーとして定義し、大量のユーザーに対しても適切な権限を管理する事ができます。今回は多数の受講生にアカウントをお渡しするため、リスク管理のため SCP を利用し、受講に必要ない高コストサービスについては一律で利用できないように設定を行いました。作成した OU 配下へはaws organizations move-accountコマンドを利用して移動を行いました。また、今後別の講座でAWSを利用する場合 AWS サービスは同一ではない可能性があるため、個別に統制ルールを適用するために講座ごとに OU およびSCP を作成/設定することを想定しています。
ユーザー作成とアカウントへの紐付け
本年度の講義の申し込みは 3 月中旬から 4 月 3 日まで行われました。参加者はメールアドレスを入力しますので、メールアドレスをキーに登録しているアカウントと紐づけることが最適だと考えました。
IAM Identity Center は、ユーザー認証を行う為に参加者のメールアドレスに紐づくアイデンティティ情報を作成し認証機能を提供するとともに、AWS アカウントへのアクセス時の権限を定義した「許可セット」の紐付けによる AWS アカウントへアクセス時の権限の付与(認可)を行う事ができます。今回は前述した SCP によるサービス単位の制限と、許可セットによる細かな権限管理の 2 段階での権限管理を行なっています。
今回の演習では、1400 人を超える参加申し込みがありましたので、松尾・岩澤研のAWSアカウントに IAM Identity Center を設定し、アカウントの作成を行いました。アカウントの作成はスクリプトを作成し、1400 のアカウントを各利用者に紐づけて自動化することで作成しました。作成の際に利用したスクリプトはこちらです。
create_user.sh
#!/bin/bash
# 環境依存のパラメータ(要設定)
AWS_ORG_PROFILE="your-profile-name"
IDENTITY_STORE_ID="d-xxxxxxxxxx"
USER_LIST_CSV="ai_eng_all_member.csv"
# CSVファイルの存在チェック
if [ ! -f "${USER_LIST_CSV}" ]; then
echo "Error: CSV file '${USER_LIST_CSV}' not found."
exit 1
fi
for LINE in $(cat ${USER_LIST_CSV})
do
FAMILY_NAME=$(echo $LINE | awk -F, '{print $1}')
GIVEN_NAME=$(echo $LINE | awk -F, '{print $2}')
EMAIL=$(echo $LINE | awk -F, '{print $3}')
DISPLAY_NAME="${GIVEN_NAME} ${FAMILY_NAME}"
echo "Create a user: ${EMAIL}"
# ユーザー作成関数
create_user() {
aws identitystore create-user \
--profile "${AWS_ORG_PROFILE}" \
--identity-store-id "${IDENTITY_STORE_ID}" \
--user-name "${EMAIL}" \
--emails "Value=${EMAIL},Type=Work,Primary=true" \
--name "FamilyName=${FAMILY_NAME},GivenName=${GIVEN_NAME}" \
--display-name "${DISPLAY_NAME}"
}
# 1回目の試行
if ! create_user; then
echo "Sleep 1 & try again to create a user: ${EMAIL}"
sleep 1
# 2回目の試行
if ! create_user; then
echo "Sleep 5 & try again to create a user: ${EMAIL}"
sleep 5
# 3回目の試行
if ! create_user; then
echo "Failed to create user: ${EMAIL}"
fi
fi
fi
done
echo "User creation process completed."
attach_policy_to_user.sh
#!/bin/bash
# 環境依存のパラメータ(要設定)
AWS_ORG_PROFILE="your-profile-name"
IDENTITY_STORE_ID="d-xxxxxxxxxx"
INSTANCE_ARN="arn:aws:sso:::instance/ssoins-xxxxxxxxxxxxxxxx"
STUDENT_PERMISSION_SET_ARN="arn:aws:sso:::permissionSet/ssoins-xxxxxxxxxxxxxxxx/ps-xxxxxxxxxxxxxxxx"
USER_LIST_CSV="ai_eng_all_member.csv"
# CSVファイルの存在チェック
if [ ! -f "${USER_LIST_CSV}" ]; then
echo "Error: CSV file '${USER_LIST_CSV}' not found."
exit 1
fi
for LINE in $(cat ${USER_LIST_CSV})
do
EMAIL=$(echo $LINE | awk -F, '{print $3}')
TARGET_AWS_ACCOUNT_NAME=$(echo $LINE | awk -F, '{print $4}')
TARGET_AWS_ACCOUNT_ID=$(echo $LINE | awk -F, '{print $5}')
echo "Get a user principal-id: ${EMAIL}"
USER_ID=$(aws identitystore get-user-id \
--profile ${AWS_ORG_PROFILE} \
--identity-store-id ${IDENTITY_STORE_ID} \
--alternate-identifier "{\"UniqueAttribute\":{\"AttributePath\":\"userName\",\"AttributeValue\":\"${EMAIL}\"}}" \
--query "UserId" | jq -r)
# アカウント割り当て関数
create_assignment() {
aws sso-admin create-account-assignment \
--profile ${AWS_ORG_PROFILE} \
--instance-arn ${INSTANCE_ARN} \
--target-id ${TARGET_AWS_ACCOUNT_ID} \
--target-type "AWS_ACCOUNT" \
--permission-set-arn ${STUDENT_PERMISSION_SET_ARN} \
--principal-id ${USER_ID} \
--principal-type "USER"
}
echo "Attach a user ${EMAIL} to an account: ${TARGET_AWS_ACCOUNT_NAME}(${TARGET_AWS_ACCOUNT_ID})"
# 1回目の試行
if ! create_assignment; then
echo "Sleep 1 & try again to attach user: ${EMAIL}"
sleep 1
# 2回目の試行
if ! create_assignment; then
echo "Sleep 5 & try again to attach user: ${EMAIL}"
sleep 5
# 3回目の試行
if ! create_assignment; then
echo "Failed to attach user: ${EMAIL}"
fi
fi
fi
done
echo "Account assignment process completed."
作成の際のポイントをいくつかご紹介します。
- 初回登録を促すメールが送信されない
作成にはaws identitystore create-userコマンドを利用しました。GUI でユーザーを作成した場合はユーザーに Email で初回登録を促すメールを送付することができるのですが、AWS CLI (SDKも同様) 利用の場合は初回登録メールを送信できない仕様となっていました。発覚当初は個別にパスワードをメール連絡しなければいけないかと焦りましたが、結論として、ユーザー自身が直接アクセスポータル上でパスワードリセットを行ってもらう運用とすることで利用できるということがわかり、問題なく提供できました。
なお、ユーザーの作成自体は 1 ユーザーごとに 1 – 2 秒程度かかり、1 時間程度で完了できました。 - 演習日前にユーザーによる事前接続確認を実施
今回はたくさんの方に受講いただいているため、演習当日のオンラインのトラブルなどは対応が難しくなることが予想されました。したがって可能な限り事前のログイン確認などを行なっていただけるように準備を行いました。ただし、演習前に環境にログインできるようにするのはリスク管理の観点で良くないため、ステップとしては- アクセスポータルへの登録と確認 (1 週間前)
- 権限設定の付与 (当日)
という形で実施しました。これによりユーザー側の Email アドレスの申請ミスや手順の読み違いなどのサポートを事前に実施でき、当日の接続関連の問題を極小化することができました。権限設定の付与自体は当日
aws sso-admin create-account-assignmentコマンドにて CLI で実施し、1 時間以内で完了しました。
まとめ
東京大学 松尾・岩澤研究室の「AI エンジニアリング実践講座 2025」では、1400 名を超える受講者に実践的なクラウド演習環境を提供するため、1 ユーザーに1AWSアカウントを割り当てるマルチアカウント方式を採用しました。AWS Organizations と IAM Identity Center を活用し、AWS CLI とスクリプトによる自動化で効率的に大量のアカウント作成とユーザー紐付けを実現しました。SCP と許可セットによる 2 段階の権限管理でセキュリティを確保しつつ、事前接続確認の実施により当日のトラブルを最小化し、受講者が実務に近い環境でAI開発の全プロセスを体験できる環境構築に成功しました。次回以降では、実際の演習内容や運用で得られた知見について紹介していきます。
松尾・岩澤研究室では、今回ご紹介した AI エンジニアリング実践講座だけでなく、様々な先進的な講座を開講しています。年間を通じて受講生を募集しており、2014 年から提供するAI講座の累計受講者数が75,000人を突破しました（2025 年 6 月時点）各講座はオンライン講義が中心なので、全国どこからでも参加可能です。大学生・大学院生だけでなく、中学生・高校生・高専生・専門学校生・短大生でも無料で参加できます。また、社会人の方が募集できる講座も用意しております。現在募集中の講座一覧はこちらとなりますので、ぜひご確認ください。
執筆者
Hideaki Masuda 増田 英晃
東京大学大学院 工学系研究科 松尾・岩澤研究室
Saori Yagyu 柳生 さおり
アマゾン ウェブ サービス ジャパン合同会社
パブリックセクター教育事業本部 アカウントエグゼクティブ
Naoya Funazashi 篙 直矢
アマゾン ウェブ サービス ジャパン合同会社
パブリックセクター技術統括本部 ソリューションアーキテクト
Kei Sasaki 佐々木 啓
アマゾン ウェブ サービス ジャパン合同会社
パブリックセクター技術統括本部 シニアソリューションアーキテクト