Amazon Web Services ブログ
Amazon Bedrockを活用したAWS サポート問い合わせ内容の自動集約ソリューションの実装
本稿は、JALデジタル株式会社システムマネジメント本部ハイブリッドクラウド基盤部クラウド基盤運営グループの梅本様、北様からご寄稿いただきました。
はじめに
JALデジタル株式会社のプラットフォームチームでは、JALグループのITシステムとして必要な設計・運用を満たすためのAWSアカウントを「CIEL/S」(※1)として提供しています。
今回私たちのチームでは、複数のAWSアカウントにおける AWS サポートとのやり取りを組織全体で効率的に活用するため、Amazon Bedrock を活用したナレッジ集約のソリューションを開発しました。
本記事では、AWS サポート問い合わせ内容の自動収集、AI要約、ServiceNow(※2)への連携を実現したアーキテクチャについて解説します。
※1:リンク先の資料内におけるJALインフォテックは2025年4月、JALデジタルに社名変更しています。
※2:JALグループではITSMツールとしてServiceNowを利用しています。
導入背景
現在JALグループで利用しているAWSアカウント数は数百アカウントあり、エンタープライズサポートを活用して24時間365日の運用を実現しています。しかし、利用していく中でいくつかの課題が発生しました。
- アカウントの制約
各アカウントから行った問い合わせ内容は、そのアカウントでしか閲覧もできません。そのため、複数のAWSアカウントでのサポート問い合わせ内容が分散することになり、組織全体での知見共有が困難となっていました。また、私たちのチームに「○○という内容で過去に問い合わせしているアカウントはいないか」と質問があっても、一元管理できていないため探すのが困難でした。 - ナレッジ共有の壁
問い合わせした内容をドキュメント化して共有する場合、CIEL/SのAWSアカウント全体で平均60件/月の問い合わせが発生しており、それらを手動でナレッジとして作成することはコストがかかりすぎてしまいます。また問い合わせ履歴が多くなってしまったサポートケースをそのまま転記するだけでは、読み手の負担も大きいためある程度要約をする必要がありますが、要約作成もナレッジ化のハードルとなっていました。 - AWS サポートケース保管期限の制約
解決から2年経過した問い合わせはAWSコンソール上から削除されるため、それ以上過去に遡って探すことができませんでした。
ソリューション概要
上記課題を解決するために、自動的にAWS サポートケース の集約と Amazon Bedrock を活用した問い合わせ内容の要約作成を行うソリューションの開発を行いました。開発したソリューションは、2種類のAWSアカウントと、3つの主要なコンポーネントで構成されています。
AWSアカウントの種類
- 集約実行アカウント
問い合わせ内容を集約し、ServiceNowに連携するAWSアカウント - 集約対象アカウント
問い合わせを集約させたいAWSアカウント
コンポーネント
- 既存の AWS サポートケース の集約(集約実行アカウント)
- 本ソリューション導入前に解決済みとなっている AWS サポートケース を集約させるための処理
- Amazon Bedrockを利用して問い合わせ内容の要約を作成
- 新規の AWS サポートケース の集約(集約実行アカウント)
- 本ソリューション導入後に解決済みとなった AWS サポートケース を自動で集約させるための処理
- Amazon Bedrockを利用して問い合わせ内容の要約を作成
- 集約した問い合わせをServiceNowに連携する処理
- AWS サポートケース の ResolveCase を検知(集約対象アカウント)
- 集約対象AWSアカウントで解決済みとなった AWS サポートケース を集約実行アカウントに連携する処理
- AWS Cloudformation StackSets を利用して複数AWSアカウントに Amazon EventBridge Rule を展開
- AWS サポートケースの検索と表示(ServiceNow)
- 集約実行アカウントから連携された問い合わせの表示
- AWSサポートケースの内容検索
アーキテクチャ詳細
既存の AWS サポートケース の集約の処理については、一度のみの処理となるため、メインとなる新規の AWS サポートケース の集約について詳細を解説します。
Step 1: サポートケースが解決したイベント検知(集約対象AWSアカウント)
- 集約実行アカウントの Event Bus をターゲットとした Amazon EventBrige Rule を作成します
- AWS サポートの解決処理をトリガーとして、Amazon EventBridge Ruleのイベントパターンに定義します
{
"detail-type": ["Support Case Update"],
"source": ["aws.support"],
"detail": {
"communication-id": [""],
"event-name": ["ResolveCase"]
}
}
Step 2: Step 1 の検知を元にLambdaを実行(集約実行AWSアカウント)
- 集約対象AWSアカウントに対して、AWS Support API (DescribeCases、DescribeSeverityLevels、DescribeServices、DescribeCommunications)を実行してサポートケース情報を取得
- Amazon Bedrock API (Converse) を実行し サポートケース会話情報を要約
- Amazon DynamoDB に登録
Step 3: ServiceNow連携(集約実行AWSアカウント)
- DynamoDB Stream から AWS Lambda 関数を実行
- ServiceNow への認証処理
- ServiceNow への記事の登録処理の実行
①AWS サポートケースとServiceNow上のナレッジとのマッピング
②ServiceNow上でナレッジ検索する際イメージ
実装ポイント
- Amazon EventBridgeのリージョン制約対応
AWS サポートは us-east-1 リージョンのグローバルリソースであるため、EventBridge Rule の配置および Lambda 関数のデプロイも us-east-1 にまとめることが推奨されます。 - セキュリティ権限の最小化
各AWSアカウントに必要な IAMロール・ポリシーは最小権限の原則に従い、AWS サポートケースの読み取り権限や EventBridge Rule の作成権限だけに限定することで安全性を確保してください。 - システムプロンプトの設計
読み手が短時間で問題の本質と解決策を把握できるよう、要約生成のためのプロンプトは、以下のポイントを押さえて設計しています。- ユーザーが直面した問題、サポートの具体的な解決策、成功のための考慮事項を明確に区別して要約させる
- 日本語で簡潔に300文字以内に収める文字数制限を設定し、不要な情報を排除
- 「問い合わせ内容」「解決策」「考慮事項」という出力フォーマットを厳格に指定し、一貫性のある要約を実現
- ナレッジ格納先にServiceNowを選定
- 本ソリューション実装前から、プラットフォームに関するナレッジを ServiceNow 上に乗せていた
- 標準となるナレッジの型があり、UI を一から作成する必要が無い
- 検索機能も ServiceNow 標準のものを利用できる(AIを用いた検索等は今後実装予定)
※AWS Support APIの利用条件
AWS Support APIの利用にはビジネスサポート以上のサポートプラン(ビジネス、エンタープライズ On-Ramp、エンタープライズ)が必要です。JALグループではエンタープライズサポートを利用しているため、本ソリューションで必要となるAWS Support APIの全機能を活用することができます。
導入効果
本ソリューションの導入により、以下の効果を実現しました。
- ナレッジ共有の効率化
複数アカウントの問い合わせ内容を一元管理することで、組織全体の知見を活用できるようになりました。またAI要約を入れることで、すべてのやり取りを読む前に自分たちが探している情報かどうか判断することができるようになりました。 - 運用工数の削減
手動でのドキュメントや要約作成が不要になることで、ナレッジ作成に伴う運用コストを大幅に削減させることができました。また ServiceNow への自動連携により転記作業を削減した上で、解決済みになった問い合わせをリアルタイムでナレッジ化することが可能になりました。 - 問題解決の迅速化
一元管理により、各アカウントの担当者が組織全体の知見を活用して、調べたい情報や類似事例を直接検索-閲覧できるようになりました。これにより、プラットフォームチームやAWSサポートに問い合わせて回答を待つ時間を省略し、素早い問題解決が可能になりました。
まとめ
AWS Support APIを利用した問い合わせ内容の取得と、Amazon Bedrock を活用した問い合わせ内容の要約作成を組み合わせることで、組織全体のナレッジマネジメントを大幅に改善することができました。AWS Lambda、 Amazon EventBridge、Amazon DynamoDB などAWSのマネージドサービスを最大限に活用、AWS利用料を最小限に抑えるアーキテクチャを実現しました。
今後は、要約精度の向上や、より高度な分析機能の追加を検討しており、継続的な改善を進めていく予定です。