Amazon Web Services ブログ
東京大学 松尾・岩澤研究室主催の AI エンジニアリング実践講座にて、1400 名を超える受講者に AWS 上でのクラウド開発を体験していただきました [ 演習、運用編 ]
本ブログは、東京大学松尾・岩澤研究室が主催する AI エンジニアリング実践講座において、AWS を活用した講座の取り組みをご紹介する、AWS との共同寄稿です。
はじめに
本ブログシリーズでは、2025 年 4 月から 7 月にかけて実施した東京大学 松尾・岩澤研究室の AI エンジニアリング実践講座において、 AWS クラウドを活用した実践的な学習環境を用意し、1400 名を超える受講申し込み者に対して、個別のAWSアカウントを提供する大規模なオンライン講義を開講した取り組みを全 3 回に分けてまとめたものです。
- [準備、構築編] 講義に参加する受講生に AWS アカウントを準備し、受講者情報と紐づける
- [演習、運用編] それぞれの AWS アカウントに適切な権限を配布し、提供期間中管理/運用する(本ブログ)
- [後片づけ編] 講義終了後に、適切にアカウントをクリーンアップする
[準備、構築編]では、AWS Organizations と IAM Identity Center を使って、講義用の AWS アカウントを作成し、以下の図のように申し込みがあった受講者のメールアドレスと 1 対 1 で紐づける設定についての解説を行いました。
図 1: マルチアカウント管理構成
今回は、各受講生に割り当てる AWS アカウントに対する権限の適用と管理方法について詳しく説明します。
ユーザー権限と管理
前述したように今回は SCP によるサービス単位の制限と、許可セットによる細かな権限管理の2段階での権限管理を行なっています。ここでは設定した具体的な権限について紹介いたします。今回の演習環境では多数の利用者がアプリケーション開発を経験することを目的としたため、Amazon CloudFront、Amazon Cognito、Amazon API Gateway、AWS Lambda、Amazon Bedrock などのサーバレスサービスを中心としたチャットボットシステムを開発することをゴールとしました。利用者の権限設定では、AWSのソリューションアーキテクトとともに、利用者に不要な権限を可能な限り与えず、特に Amazon EC2 や Amazon RDS など意図しないコスト増につながるサービス利用を停止する形でSCPを設定しました。
具体的な設定ポリシー
SCP ではサービス単位で Deny をしました。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyListedServices",
"Effect": "Deny",
"Action": [
"ec2:*",
...
]
}
]
}
許可セット側では必要最小限の権限にさらに制限しています。ただし今回の演習の中で AWS CloudFormation を利用したり、AWS IAM Role を作成したりする関係上、権限的には自身で Role を作成して新たな権限を使用することも可能な設定としています。これによりユーザーは比較的自由な開発ができるようになるものの、不要なサービスについては SCP 側で制御していることで意図しない高額利用を防げる設計にしました。権限の内容についてはAWSのソリューションアーキテクトと演習内容に即した権限になるように綿密に擦り合わせを行い設定しました。具体的な設定ポリシーについては割愛しますが、IAM 周りの権限だけ抜粋して記載しておきます。
{
"Effect": "Allow",
"Action": [
"iam:CreateRole",
"iam:DeleteRole",
"iam:GetRole",
"iam:GetPolicy",
"iam:GetPolicyVersion",
"iam:CreatePolicy",
"iam:CreatePolicyVersion",
"iam:DeletePolicy",
"iam:DeletePolicyVersion",
"iam:PutRolePolicy",
"iam:DeleteRolePolicy",
"iam:AttachRolePolicy",
"iam:DetachRolePolicy",
"iam:TagRole",
"iam:UntagRole",
"iam:ListRolePolicies",
"iam:ListAttachedRolePolicies",
"iam:UpdateAssumeRolePolicy",
"iam:GetRolePolicy"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::*:role/*",
"Condition": {
"StringEquals": {
"iam:PassedToService": [
"cloudformation.amazonaws.com",
"lambda.amazonaws.com",
"ec2.amazonaws.com",
"bedrock.amazonaws.com",
"cloudwatch.amazonaws.com",
"ssm.amazonaws.com"
]
}
}
}
下記に設計/運用時のポイントをいくつか示します。
- AWS Managed Policy の付与制限とインラインポリシーの利用
許可セット (というよりも Role 自体) の制約として Managed Policy がデフォルトでは 10 個までしか付与できないというものがあります。こちらはクォータ申請で引き上げることが可能ですが、許可セットで定義した権限は Role として各アカウントに作成される仕組みのため、許可セットで 10 を超える Managed Role を付与した場合、各アカウント全てで制限を引き上げる必要が出てきます。今回は多数のアカウントのクォータ申請を行うのは大変であるため、インラインポリシーを利用して、そちらでいくつかの Managed Policy の内容を直接記述することで回避しました。インラインポリシーの内容が煩雑になるというデメリットはありますが、1000 を超えるクォータ申請とそのトラッキング/フォローアップ (そもそも申請が拒否される可能性もある) の手間を考えると、インラインポリシーでの対応の方が安全な対応と判断しました。 - 許可セット変更時は時間がかかる/ SCP の反映は即時
今回の講義/演習では事前に設定した許可セットで問題なく実施することができたため問題にはならなかったのですが、追加で、講義後の最終課題においても今回の演習環境を利用し、受講者にアプリケーションを作成していただくために、その際に元々の演習環境より権限を一部広げる (例: Amazon DynamoDB の権限を追加する) 対応を実施しました。そのために SCP および許可セットの両方を変更したのですが、許可セットの変更はAWS側の内部処理として、対象のすべてのアカウントにシリアルで Role の更新を行っていくため、かなりの時間を要しました。具体的には 1 アカウント 3 ~ 4 秒程度の時間を要するため、変更する度に全体で 1.5 時間近くかかりました。一方で、SCP の場合は変更後、即座に全アカウントの挙動に反映されるため、その点を理解した上で設計をしておくと、管理運用をより効率的に実施できるようになると思います。
図 2: マルチアカウント設定画面
講義:Amazon クラウドを使ったデプロイメント/デプロイメント戦略 ( 4 月 23 日)
講義では前週の講義内容を踏まえてオンプレミス環境と比べて、クラウド環境を活用した開発・運用のメリットについて解説し、IaC を用いたクラウド環境構築の演習を通じて、基本的な知識とスキルを習得することを目標とし、以下の内容を説明しました。
- クラウドによる Web アプリケーション開発 : 活用方法や従来手法との比較
- AWSクラウドアーキテクチャ入門 : EC2 /コンテナ/サーバレス / AIML / 生成AI
- 効率的な運用管理の方法 : モニタリング・セキュリティ・コスト最適化
- 実践演習 : Simplechat の構築と実装
- クラウド利用の実践 : 開発から運用までの考慮点
演習では、生成 AI サービスである Amazon Bedrock のモデルの一つである Amazon Nova を用いたチャットボットシステムを作成するコンテンツを用意しました。チャットボットシステムは CloudFormation を用いて自動で構築できるように設定しています。CloudFormation は AWS の Infrastructure as a Code (IaC) のサービスです。演習では IaC で構築したチャットボットを利用できることを確認した後に、Bedrockの別のモデルを呼び出すように、Python コードを変更を行いました。
図 3: データサイエンス講義で構築したチャットボットの設定
宿題は、前週の講義で構築したローカル環境の生成 AI モデルを、クラウドに構築した環境から呼び出すように仕様を変更することを、宿題として提出していただきました。
図 4: 宿題で仕様変更したチャットボットの設定
東大松尾・岩澤研究室の講師チームは 4 月 20 日 にユーザー向けにAWS環境へのアクセスを許可し、5 月 6 日までに宿題を提出するように期日を設けました。最終的に 4 月 23 日の講座をリアルタイムで受講したユーザーは 243 名参加、オンデマンドの受講者も含めて、第二回目のアンケート提出者は 743 名でした。アンケートの結果、満足度 (5 段階) : 4.51、NPS® (Net Promoter Score®) : 61.37 という非常に高い評価を得ることができました。具体的には「幅広くクラウドおよびAWSについて学ぶことができた」「実際に手を動かしてデプロイを経験することで理解が深まった」などの好評をいただく事ができました。一方で、「内容が多い/難易度が高いので複数回に分ける、もしくは予習回を作って欲しい」、「より抽象的な概念や全体像を理解するパートを増やしてほしい」等の改善点のご指摘もいただきました。初回の取り組みであったため、ボリュームや難易度については手探りの部分もあったため、今後の改善としていく予定です。また、演習環境の接続と利用については問題が発生することなくスムーズに提供することができました。
コスト管理と実績
今回は多数の受講者が演習と課題でクラウドサービスを利用するという特性上、想定外にコストが爆発するリスクを考慮しないといけませんでした。その対策として今回は下記を実施しています。
- コストが大きく発生するサービスは利用不可とする、演習等は可能な限りリクエスト課金型のサーバーレスサービスを前提とした構成を利用する
- 定期的なコストモニタリングを実施する
1 の対策にて、可能な限りサーバーレスサービスに利用を限定したことで、演習および宿題の費用を劇的に抑えることができ、結果として非常に少ないコストで今回の講座を提供することができました。より具体的には、今回の演習/宿題では 1 ユーザーあたり $0.01 ~ $0.5 の利用にとどめつつ、chatbot の機能をインターネット経由で公開し、そのアプリを改善するフローをクラウド上で実現するという開発体験を提供することができています。この事自体はクラウドサービスを用いてスモールスタートができるという実感を受講者側にも理解していただくとても良い事例であったと考えています。
2 のコストモニタリングについては、1 で基本的に大きなコストの発生が抑えられていることを加味して、管理アカウントのコストエクスプローラ上で全アカウントの毎日の費用状況の確認を行う形で運用しました。個別アカウントごとに予算アラートを設定することも検討はしたものの、1 の対応を行なっており短期間での大量使用リスクが軽減されていたため今回は設定していません。追加で最終課題でも環境を開放したため、最終的には数十ドルの利用をするユーザーも出ましたが、結果として費用が暴発したアカウントもなく予算内で安全に環境提供をすることができました。
まとめ
今回は、1400 名を超える受講者に対する権限管理と実際の講義運用について紹介しました。SCP によるサービス単位の制限と許可セットによる詳細な権限管理の2段階構成により、受講者は比較的自由な開発が可能でありながら、高額サービスの利用は制限されるセキュアな環境を実現しました。4 月 23 日の講義では、クラウドサービスを活用したチャットボットシステム構築の演習を実施し、243 名がリアルタイム参加、743 名がアンケートに回答し、高評価を獲得しました。サーバーレスサービス中心の構成により低コストでの提供を実現し、定期的なコストモニタリングによって予算内での安全な環境提供に成功しました。
第三回では、講義終了後のアカウント管理、環境のクリーンアップ方法、そして今回の取り組みを通じて得られた知見と今後の展開について解説します。
松尾・岩澤研究室では、今回ご紹介したAIエンジニアリング実践講座だけでなく、様々な先進的な講座を開講しています。年間を通じて受講生を募集しており、 2014 年から提供するAI講座の累計受講者数が 75,000 人を突破しました( 2025 年 6 月時点)。各講座はオンライン講義が中心なので、全国どこからでも参加可能です。大学生・大学院生だけでなく、中学生・高校生・高専生・専門学校生・短大生でも無料で参加できます。また、社会人の方が募集できる講座も用意しております。現在募集中の講座一覧はこちらとなりますので、ぜひご確認ください。
執筆者
Hideaki Masuda 増田 英晃
東京大学大学院 工学系研究科 松尾・岩澤研究室
Saori Yagyu 柳生 さおり
アマゾン ウェブ サービス ジャパン合同会社
パブリックセクター教育事業本部 アカウントエグゼクティブ
Naoya Funazashi 篙 直矢
アマゾン ウェブ サービス ジャパン合同会社
パブリックセクター技術統括本部 ソリューションアーキテクト
Kei Sasaki 佐々木 啓
アマゾン ウェブ サービス ジャパン合同会社
パブリックセクター技術統括本部 シニアソリューションアーキテクト



