Amazon Bedrockを使用して、 運用対応を楽にしてみた

イベント
DifyとAmazon Bedrockで業務改善！生成AI活用LT発表会 NIFTY Tech Talk #24
https://nifty.connpass.com/event/346459/

登壇者
ニフティ株式会社
小林 雅幸

Transcript

1. Copyright © NIFTY Corporation All Rights Reserved.
 Amazon Bedrockを使用して、 運用対応を楽にしてみた NIFTY Tech Talk #24 小林　雅幸 ニフティ株式会社
2. Copyright © NIFTY Corporation All Rights Reserved.
 2
 自己紹介 小林 雅幸 担当業務 @nifty光など プロバイダーサービスの開発/運用 kobayashi masayuki 趣味 スノボ、写真撮影、配信視聴
3. Copyright © NIFTY Corporation All Rights Reserved.
 3
 目次 01 現在の課題 02 解決策の提案 03 実装後の効果 04 実装詳細 05 開発時に直面した壁 06 まとめと今後の展開 提案した解決策を実装した結果を共有
4. Copyright © NIFTY Corporation All Rights Reserved.
 4
 現在の課題 改善前の連携フローと課題 チケットが起票されるまで チケットが起票された後（運用対応） エラー対応着手から対応完了までの工数が大きい 人為的ミスの可能性がある 対象の手順書ページを検索する工数がかかる + 実施する手順が多いことも要因
5. Copyright © NIFTY Corporation All Rights Reserved.
 5
 解決策の提案 課題の分析と、ＡＩによる解決アプローチ エラー対応着手から対応完了までの工数が大きい 人為的ミスの可能性がある 状況に応じて手順が分岐されている エラーメッセージには複数の対象が存在するため、 SQLによる調査時に漏れが発生する 手順書とエラーメッセージから自動的に解析し、 必要な手順書を生成する 複数の対象を調査しやすいように情報を集約する 対象の手順書ページを検索する工数がかかる 既存の連携フローだと自動で特定がしづらい エラーコードが記載されているものとそうではない メッセージが存在する エラーメッセージからNotionに保存されている 手順書のタイトルを自動的に判別する
6. Copyright © NIFTY Corporation All Rights Reserved.
 6
 解決策の提案 2つのLambdaを用意 2つのBedrockを用意 Notion上の手順書を S3に一時保存する処理 提案するフロー 右図の通り ②:メイン処理 ①:手順書ページ特定用 ②:手順書生成用 ①:Zapier連携用
7. Copyright © NIFTY Corporation All Rights Reserved.
 7
 実装後の効果 課題に対する実施後の効果① 対象の手順書ページを検索する工数がかかる エラーメッセージからNotionに保存されている 手順書のタイトルを自動的に予測する エラーコード形式（例：ERR001） ではない手順書も含め、予測することが可能に 新規アラートの場合は「特定不可」等の旨を記載 し、後続の生成された手順書は不要とした Notion URLを付与することで1クリックで ページに飛べるように
8. Copyright © NIFTY Corporation All Rights Reserved.
 8
 実装後の効果 課題に対する実施後の効果② 手動で実施する際の手順と同じ流れで、手順書が自動的に生成される エラー対応着手から対応完了までの工数が大きい 人為的ミスの可能性がある 手順書とエラーメッセージから自動的に解析し、必要な手順書を生成する 複数の対象を調査しやすいように情報を集約する 複数の対象に関しては、SQLのWHERE句に自動的に記載してくれる 追加作業はコメント編集のみとなり、対応工数が大幅に削減 生成された条件をコピーしWHERE句に貼り付けるのみとなり、 抽出作業の工数が削減
9. Copyright © NIFTY Corporation All Rights Reserved.
 9
 実装詳細 4分割して説明 ① ② ③ ④ Zapier⇔Lambda① →Lambda②→GitHub EventBridge → Lambda → Notion → S3 Bedrock① → S3 → GitHub Bedrock② → S3 → GitHub ③ ④ ① ②
10. Copyright © NIFTY Corporation All Rights Reserved.
 10
 実装詳細 ① 　　　Zapier⇔Lambda①→Lambda②→GitHub ① Zapier：Lambda①を呼び出す Lambda① 　・ZapierにOK返却する 　・非同期でLambda②を呼び出す Lambda② 　・メイン処理 　・チケット（GitHub Issue） を起票する 　・後続のBedrock処理を実施する 仲介役のLambda①を導入することにより、 メイン処理で30秒以上掛かった際のZapier時間制限を解消 Bedrock処理実施前にチケットを起票することにより、 処理中のエラーによる失敗時でも追跡が容易で、 問題発生時の手動対応がスムーズに 仲介役のLambda①を導入することにより、 メイン処理で30秒以上掛かった際のZapier時間制限を回避
11. Copyright © NIFTY Corporation All Rights Reserved.
 11
 実装詳細 　　　EventBridge → Lambda → Notion → S3 ① EventBridge：毎日22:00起動 Bedrock処理中に手順書ページを解析する処理に比べ、 事前に解析して保存しているため、 処理中において1秒程度で取得が可能に ② ② Lambda 　・Notionの手順書を解析しS3に保存する（ファイル名：手順書名.md） 　・メタデータとして、NotionページのURLと最終更新日時を保持 最終更新日時を保持しているため、 ページに更新が行われていない場合は解析されず、 処理時間の短縮を実現
12. Copyright © NIFTY Corporation All Rights Reserved.
 12
 実装詳細 　　　Bedrock① → S3 → GitHub ① Amazon Bedrock① 　・S3に保存された手順書のファイル一覧を取得し、 　　発生したエラーメッセージと合致しそうな 　　手順書名をBedrockにより特定してもらう 　・保存されているメタデータよりURLを抽出し、 　　GitHubのコメントに特定手順書としてリンク付与 　・手順書が特定出来ない場合はその旨をコメント 以前まではエラーコード形式（例：ERR001）を 正規表現により特定し完全一致する手順書のみし か取得できなかった ③ ③ エラーコード形式以外も類似度が高い手順書を 特定してくれるように
13. Copyright © NIFTY Corporation All Rights Reserved.
 13
 実装詳細 　　　Bedrock② → S3 → GitHub ① Amazon Bedrock② 　・Amazon Bedrock①にて特定された手順書データを　　　 取得し、エラーメッセージを併せてBedrockに読み込　　 むことで、エラー解決に特化した手順書を生成する 　・出力形式が決まっている項目は前処理により抽出し、 　　情報として与えている（例「ERROR_CODE:10」） ④ エラーメッセージに付与されているエラーコード や関連情報を解析し、 適切な対応手順を自動的に決定して提示 ④ コード例 以下のアラートメッセージと手順書テンプレート、および抽出された情報に基づい て、実行すべき具体的な手順を生成してください。 エラーメッセージ:{error_content} 抽出された情報:{extracted_info} 手順書テンプレート:{file_content} 前処理により抽出した情報を元に、 手順書内SQLのWHERE句に対応するカラム位置 に、関連データが自動的に挿入
14. Copyright © NIFTY Corporation All Rights Reserved.
 14
 開発時に直面した壁 ①Zapierの30秒制限 右図において、最初はLambda①で全て完結させようとしていた ① しかし、以下の処理のためZapierの30秒制限を大幅に超過 　・Notion API から手順書内容を解析する 　　・構造分析に多くの処理が必要 　　・APIの頻繁な呼び出し自体も適切ではない 　・解析した手順書内容とエラーメッセージからBedrockにより手順書を予測 以下とすることで、制限の解消と処理時間の短縮を図った 　・非同期前処理として、前もってNotionページを解析し、S3へ保存 　・Zapier連携用のLambdaと、メイン処理用Lambdaを分離することで、Zapierの30秒制限を回避
15. Copyright © NIFTY Corporation All Rights Reserved.
 15
 開発時に直面した壁 ②Notionページ解析後S3保存処理において、かなりの時間が掛かる LambdaでのNotionページ解析とS3保存に時間がかかる 　・手順150個の場合、処理に約300秒を要する 　　・都度、150個全て取得し解析、保存している 　　・メモなど、手順とは関連の無い情報が存在する 以下の対策により、更新が1,2個の場合処理時間を300秒から20秒に削減 　・S3のメタデータにNotionページの最終更新日時を保持 　　・保存処理の際、ページ内部を解析する前に最終更新日時を比較し、一致する場合は解析処理を実施しない 　・手順とは関係の無い情報に関しては、ページ内に新規ページを作成し転記 　　・新規ページに対して、設定のConnectionsからAPI連携用botを排除すれば読み込まれなくなる ②
16. Copyright © NIFTY Corporation All Rights Reserved.
 16
 まとめと今後の展開 まとめ Amazon Bedrock による手順生成自動化処理により、手動における抽出ミスや対応工数の削減を期待 今後の展開 Notionページ解析処理の精度向上 ・手順書の内容として、過去エラーや小さなメモが顕在化しており、不要な情報まで保存されている ・コンテンツの抽出精度に問題がある 　・SQL文がコードブロックとして正しく認識されていない 　・箇条書きリストのインデントを含む構造が適切に抽出できていない Amazon Bedrock による手順書特定処理により、全手順から検索する際の工数削減を実現 前処理に汎用的な情報抽出機能を追加 ・運用手順を特定するために必要な情報が、エラーメッセージごとに異なる
17. Copyright © NIFTY Corporation All Rights Reserved.