生成AI活用によるガバメントクラウド運用管理補助業務の効率化

1. 生成AI活用による ガバメントクラウド運用管理補助業務の効率化 久保田 亨 株式会社大崎コンピュータエンヂニアリング ガバメントクラウドワークショップ
2. 生成AIを使用したアプリケーションを 作成することが出来るサービスです。 Amazon Bedrock
3. そもそもガバメントクラウドの環境で 利用出来るんでしたっけ？？ Amazon Bedrock
4. 生成AIは本番環境導入の ハードルが高いと聞きます。 Amazon Bedrock
5. 自己紹介 久保田 亨 株式会社大崎コンピュータエンヂニアリング 最近の業務内容 地方公共団体のガバメントクラウド案件 生成AI活用 AWS Community Builder 2024 Japan AWS All Certifications Engineers
6. 本セッションの内容 ・ 生成AI導入の背景 ・ 基盤モデル？？ Amazon Bedrock？？ ・ どのようにガバメントクラウド環境へ導入したか ・ 導入した機能①（アラート要約） ・ 導入した機能②（ログ要約） ・ PoC実施時の導入効果
7. 本セッションの内容 ・ 生成AI導入の背景 ・ 基盤モデル？？ Amazon Bedrock？？ ・ どのようにガバメントクラウド環境へ導入したか ・ 導入した機能①（アラート要約） ・ 導入した機能②（ログ要約） ・ PoC実施時の導入効果
8. ネットワーク運用管理補助者 ASP ネットワーク運用管理補助者環境の導入 ガバメントクラウドで良く出てくる登場人物は自治体、ASP＆運用管理補助 者、そしてASPと自治体を接続するネットワーク運用管理補助者があります。 自治体 A市環境 B市環境 ASP A市環境 B市環境 ASP A市環境 B市環境
9. ネットワーク運用管理補助者 ASP ネットワーク運用管理補助者環境の導入 弊部門では複数自治体のネットワーク運用管理補助環境、データ連携基盤 環境の設計、構築を実施しております。 自治体 A市環境 B市環境 ASP A市環境 B市環境 ASP A市環境 B市環境
10. 構築フェーズから運用フェーズへ ネットワークアカウントとASPアカウントを接続。順次本番運用が開始していきます。 2024年 2025年 Now 2026年 A市 B市 C市 設計・構築 システム稼働 設計・構築 設計・構築 システム稼働 システム稼働 ※スケジュールはイメージです。
11. 構築フェーズから運用フェーズへ 弊部門では主にデータセンター、オンプレミスの運用保守業務を行っています。 シフト：2名（交代制） 監視グループ 運用グループ 日勤：4名 監視業務：監視・定常業務など 運用業務：変更作業・障害対応など 環境：データセンター・オンプレミス
12. 構築フェーズから運用フェーズへ 監視・運用業務では 150 以上の顧客対応 監視業務（統合監視サービス） 監視ホスト数は 1500 以上、監視項目数 10,000 以上 運用業務（シェアードホスティングサービス） ホスティングサービスとして 200 以上の仮想マシンを提供 ・・・・・・・・さらにAWS経験者少数
13. 構築フェーズから運用フェーズへ 限られた人数で対応するため 運用効率化が必要
14. 本セッションの内容 ・ 生成AI導入の背景 ・ 基盤モデル？？ Amazon Bedrock？？ ・ どのようにガバメントクラウド環境へ導入したか ・ 導入した機能①（アラート要約） ・ 導入した機能②（ログ要約） ・ PoC実施時の導入効果
15. 生成AIを使用したアプリケーションを 作成することが出来るサービスです。 Amazon Bedrock
16. 基盤モデルとは 基盤モデルとは、大量のデータを用いて事前学習された大規模なAIモデルで あり、さまざまなタスクに適応できるのが特徴です。 基盤モデル AWSのことは良く知っています！！ AWSエラーログ、解決方法 AWSのマニュアル、ブログ記事 ・・・・・・・・ 大量のデータで事前学習
17. Amazon Bedrockとは アプリケーション側からAPIを通じて簡単に基盤モデルを使用することが可能です。 Amazon Bedrock AWS Lambda Amazon EC2 基盤モデル ①このAWSのログを要約して欲しい アプリケーション 生成AI 利用者 ③ログを要約しました ②Amazon Bedrock呼出
18. 本セッションの内容 ・ 生成AI導入の背景 ・ 基盤モデル？？ Amazon Bedrock？？ ・ どのようにガバメントクラウド環境へ導入したか ・ 導入した機能①（アラート要約） ・ 導入した機能②（ログ要約） ・ PoC実施時の導入効果
19. そもそもガバメントクラウドの環境で 利用出来るんでしたっけ？？ Amazon Bedrock
20. ガバメントクラウド環境での生成AIの利用 ガバメントクラウド環境では ・ 東京・大阪以外のリージョンは原則使用不可 ・ AWSマーケットプレイスは原則使用不可 基盤モデル例 説明 Claude Amazon以外の3rd Partyのモデルであるため、マーケットプレイスの利 用が必要。 Amazon Nova Amazonのモデルであるが、クロスリージョン推論を使用するため、国内 リージョンに閉じた通信が出来ない。 Amazon Titan Amazonのモデルであるが、期待した推論結果が出ない。
21. 調整を続けたものの難しそう。。
22. 新しいアイデア デジタル庁様・AWS様ありがとうございます
23. ガバメントクラウドのアカウントと ガバメントクラウドアカウント 事業者アカウント（ガバメントクラウド外） Amazon Bedrock 接続 ガバメントクラウド外のアカウントを接続する
24. ガバメントクラウドアカウント ガバメントクラウド環境から生成AIを利用する方法 事業者アカウント側でAmazon Bedrockを準備 ガバメントクラウド側からクロスアカウントアクセスで接続 事業者アカウント（ガバメントクラウド外） Amazon Bedrock AWS Lambda IAM Role B ①一時クレデンシャルを要求 ②IAM Role Bの権限を持つ 一時クレデンシャルを発行 ③一時クレデンシャルでアクセス IAM Role A
25. ガバメントクラウド環境から生成AIを利用する方法 本環境での事業者アカウント側の条件 プロジェクト側での判断に基づき、下記のような準備・対策を実施する ①自治体が了承していること ②任意のIAM Roleへスイッチロールできないよう、IAM Policy等で 制限をかけること ③その他、必要なセキュリティ対策を講じること 例: ガバメントクラウドと同一水準のセキュリティ対策を講じる
26. ガバメントクラウドアカウント 事業者アカウントに実施したセキュリティ対策 ガバメントクラウドアカウントのセキュリティ水準の確認 事業者アカウントのセキュリティ設計の実施 事業者アカウント（ガバメントクラウド外）
27. ガバメントクラウドアカウント テンプレート ガバメントクラウドアカウントのセキュリティ水準 AWS Organizations AWS Control Tower AWS Security Hub Amazon GuardDuty AWS Config 予防的統制 発見的統制 ※上記は使用するサービス、設定項目の一例です。記載以外のサービスも使用されます。 例）CloudShellの利用禁止 原則として東京/大阪リージョン以外禁止 例）Security Hubベストプラクティスチェック GuardDutyを使用した監視
28. 事業者アカウント AWS BLEA 事業者アカウントのセキュリティ AWS Security Hub Amazon GuardDuty AWS Config 予防的統制 発見的統制 ※上記は使用するサービス、設定項目の一例です。記載以外のサービスも使用されます。 例）CloudShellの利用禁止 原則として東京/大阪リージョン以外禁止 例）Security Hubベストプラクティスチェック GuardDutyを使用した監視 IAMポリシー等
29. ガバメントクラウドアカウント Amazon Bedrockの導入準備が完了 事業者アカウント（ガバメントクラウド外） 前提条件 セキュリティ設計 前提条件 自治体の了承 プログラムの作成 前提条件 IAMロールのセキュリティ設計
30. 本セッションの内容 ・ 生成AI導入の背景 ・ 基盤モデル？？ Amazon Bedrock？？ ・ どのようにガバメントクラウド環境へ導入したか ・ 導入した機能①（アラート要約） ・ 導入した機能②（ログ要約） ・ PoC実施時の導入効果
31. 必須テンプレート適用後 セキュリティグループを変更すると アラートメールが通知されます。 どのような仕組みでしょうか？？
32. セキュリティ関連アラート発報の例 ガバメントクラウドアカウント AWS Security Hub Amazon SNS Mail Amazon EventBridge AWS Config AWS Health AWS CloudTrail Amazon GuardDuty Alarm ログ証跡用バケット アクセスログ用バケット Logs AWS KMS Automation Amazon EventBridge Amazon EventBridge Amazon EventBridge ① ①操作ログが記録 ②特定操作が記録された 際にイベント検知 ③メール通知 ② ③ ②イベント検知→③に連携
33. ツール導入前のアラート {"version":"0","id":"***","detail-type":"AWS API Call via CloudTrail","source":"aws.ec2","account":"***","time":"2024-12-**T00:**:45Z","region":"ap-northeast- 1","resources":[],"detail":{"eventVersion":"1.10","userIdentity":{"type":"IAMUser","principalId":"***","arn":"* **","accountId":"***","accessKeyId":"***","userName":"***","sessionContext":{"attributes":{"creationDate": "2024-12-**T23:**:48Z","mfaAuthenticated":"false"}}},"eventTime":"2024-12- **T00:**:45Z","eventSource":"ec2.amazonaws.com","eventName":"AuthorizeSecurityGroupIngress","awsRe gion":"ap-northeast-1","sourceIPAddress":"***","userAgent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36","requestParameters":{"groupId":"***","ipPermissions":{"items":[{"ipProtocol":"icmp","fromP ort":-1,"toPort":- 1,"groups":{},"ipRanges":{"items":[{"cidrIp":"0.0.0.0/0"}]},"ipv6Ranges":{},"prefixListIds":{}}]}},"responseEle ments":{"requestId":"***","_return":true,"securityGroupRuleSet":{"items":[{"groupOwnerId":"***","groupId": "***","securityGroupRuleId":"***","isEgress":false,"ipProtocol":"icmp","fromPort":-1,"toPort":- 1,"cidrIpv4":"0.0.0.0/0","securityGroupRuleArn":"***"}]}},"requestID":"***","eventID":"***","readOnly":false, "eventType":"AwsApiCall","managementEvent":true,"recipientAccountId":"***","eventCategory":"Managem ent","tlsDetails":{"tlsVersion":"TLSv1.3","cipherSuite":"TLS_AES_128_GCM_SHA256","clientProvidedHostH eader":"ec2.ap-northeast-1.amazonaws.com"},"sessionCredentialFromConsole":"true"}} ※Amazon EventBridgeの入力トランスフォーマーなどを使用して整形することは可能です。
34. メール送信前にアラート要約の処理を追加する Amazon EventBridge Amazon Simple Notification Service (Amazon SNS) Amazon Bedrock AWS Lambda
35. ツール導入後のアラート ▪要約 この Finding は、IAMユーザー「***」が、セキュリティグループ「***」に対して、ICMP通信を許可する規則 を追加したことを示しています。この変更により、セキュリティグループのセキュリティが低下する可能性が あります。 ▪対応方法 1. 該当のセキュリティグループの設定を確認し、ICMP通信を許可する必要があるかどうかを確認する。 2. ICMP通信を許可する必要がない場合は、当該規則を削除する。 3. ICMP通信を許可する必要がある場合は、許可する範囲を最小限に制限する。 4. 不要なセキュリティグループ規則は定期的に見直し、不要なものは削除するよう社内の運用基準を定める。 5. IAMユーザー「***」の権限を確認し、セキュリティグループの変更を行う必要のない権限に見直す。 ▪検出内容 { "version**", "detail-type": "AWS API Call via CloudTrail", "source": "aws.ec2", "account": "***", "time": "2024-12-**T00:**:45Z", ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
36. 事業者アカウント アラート要約機能のアーキテクチャ ガバメントクラウドアカウント AWS Security Hub Amazon SNS Mail Amazon EventBridge AWS Config AWS Health AWS CloudTrail Amazon GuardDuty Alarm ログ証跡用バケット アクセスログ用バケット Logs AWS KMS Automation AWS Lambda Amazon Bedrock Amazon EventBridge Amazon EventBridge Amazon EventBridge IAM Role A IAM Role B SNS連携前にLambda、 Bedrockを使用してアラート 内容を整形
37. アラートデータを取得して プロンプトを作成して Bedrockにお願いする
38. 運用担当者の声 今までぐちゃぐちゃなアラート を受信すると心が折れそうでしたが 整形されたアラートを受信すると 心理的な負担が軽減されました。
39. 本セッションの内容 ・ 生成AI導入の背景 ・ 基盤モデル？？ Amazon Bedrock？？ ・ どのようにガバメントクラウド環境へ導入したか ・ 導入した機能①（アラート要約） ・ 導入した機能②（ログ要約） ・ PoC実施時の導入効果
40. ログ要約機能 インシデント 検知 １次判断 エスカレーション 調査 対応 アラート要約機能 インシデント発生時の判断をサポート 対応可能か？ エスカレーションが必要か？ ログ要約機能 インシデント調査をサポート 発生した事象は？ 発生した原因は？
41. 勝手にVPC内にサブネットを作成したのは誰ですか？ こちらのツールでログを検索下さい。 対象期間を入力後、「ログ分析」をクリックしてみます。
42. すみません、自分で作成してました。
43. ▪要約時間 2025-**-** **:**:** ～ 2025-**-** **:**:** ▪キーワード ▪ログ要約内容 - このログエントリは、2025年*月*日*時*分*秒にAWSアカウントID **********で発生した「CreateSubnet」操作を記録しています。 - 操作を行ったユーザは、"administrators_role"ロールを引き受けた"***@****.cloud.**.jp "アカウントです。 - 操作は、VPC vpc-********内に172.20.106.0/26のサブネットを作成するものです。 - サブネットID は subnet-********で、タグ名は "subnet-test-01" です。 ▪ログ確認用クエリ CloudWatchログインサイトで下記クエリを実行して上記ログの内容を確認できます。 fields eventName,eventTime,userIdentity.principalId,eventSource | filter @message like " ***@ lgid.cloud.go.jp" | filter @message like /(?i)CreateSubnet/ | filter readOnly == 0 | limit 10 （入力文字数：2932） ▪ログファイル https://***-***-bedrock-log.s3.amazonaws.com/*******_output.csv?AWSAccessKeyId=*******&Signature=*******&*-amz-security- token=**** 自動的にクエリを実行してログ取得 取得したログをCSVでダウンロード可能
44. ガバメントクラウドアカウント ログ要約機能のアーキテクチャ AWS Security Hub Amazon SNS AWS Config AWS Health Amazon GuardDuty Automation Amazon EventBridge Amazon EventBridge Amazon EventBridge 事業者アカウント Amazon SNS Mail Amazon EventBridge AWS CloudTrail Alarm ログ証跡用バケット アクセスログ用バケット Logs AWS KMS AWS Lambda③ AWS Lambda② AWS Lambda① User Amazon Bedrock IAM Role B IAM Role A AWS Lambda④ ① UI画面生成用関数 ② ログ取得用関数 ③ ログ要約用関数 ④ ログ保存用、メール通知用関数 ① ② ③ ④
45. 工夫した点 アプリケーションや端末に依存せず利用可能 ネットワーク環境に依存せず利用可能 AWS Lambda Lambda関数内に HTML/CSSを記述 CloudWatchダッシュボードからの利用 サーバレスのためコストが安い
46. 本セッションの内容 ・ 生成AI導入の背景 ・ 基盤モデル？？ Amazon Bedrock？？ ・ どのようにガバメントクラウド環境へ導入したか ・ 導入した機能①（アラート要約） ・ 導入した機能②（ログ要約） ・ PoC実施時の導入効果
47. PoC実施概要 ・ 下記要領でPoCを約1か月間実施 ・ 1つの自治体環境にアラート要約機能、ログ要約機能を導入 ・ 評価指標を決定し、PoC実施前、実施中の値を比較
48. 構築フェーズから運用フェーズへ 弊部門では主にデータセンター、オンプレミスの運用保守業務を行っています。 シフト：2名（交代制） 監視グループ 運用グループ 日勤：4名 監視業務：監視・定常業務など 運用業務：変更作業・障害対応など 環境：データセンター・オンプレミス 再掲
49. PoC実施前の運用フロー 課題： ・ 現状、監視グループは「記録」「エスカレーション」のみ ・ 運用グループには調査に多くの時間がかかっている 監視 グループ 運用 グループ アラート 受信 記録 エスカレー ション 受領 調査 対応
50. PoC実施中の運用フロー 評価： ・ 監視グループに「判断」のプロセスを追加 ・ 「一次対応率（％）」 「対応時間/件（分）」を測定 監視 グループ 運用 グループ アラート 受信 記録 判断 エスカレー ション 受領 調査 対応 一次対応率（%） 対応時間/件（分）
51. 導入効果 ・ アラート要約機能の導入でほとんどのアラートを監視グループで判断可能 ・ ログ要約機能で運用グループの判断時間短縮 ・ 複数自治体環境に導入した際にさらなる導入効果が見込める 指標 PoC実施前 PoC実施中 監視Gr：一次対応率（％） 0% 84.6% 運用Gr：判断時間/件（分） 27.5分 8.3分
52. まとめ 目的 限られた運用リソースで、効率的かつ高品質な運用の実現 実装した機能 アラート要約機能、ログ要約機能の導入 得られた効果 監視Grの一次対応率の上昇と運用Grの判断時間の短縮 環境の工夫 事業者アカウントとガバメントクラウドアカウントの接続
53. 導入しないとこうなるところでした 自治体Aの環境 自治体Cの環境 自治体Bの環境
54. 今後Amazon Bedrock活用による さらなる運用業務効率化に取り組んでいきます。
55. Thank You !!