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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Copyright © NIFTY Corporation All Rights Reserved.  5  解決策の提案課題の分析と、ＡＩによる解決アプローチエラー対応着手から対応完了までの工数が大きい人為的ミスの可能性がある状況に応じて手順が分岐されているエラーメッセージには複数の対象が存在するため、 SQLによる調査時に漏れが発生する手順書とエラーメッセージから自動的に解析し、必要な手順書を生成する複数の対象を調査しやすいように情報を集約する対象の手順書ページを検索する工数がかかる既存の連携フローだと自動で特定がしづらいエラーコードが記載されているものとそうではないメッセージが存在するエラーメッセージからNotionに保存されている手順書のタイトルを自動的に判別する

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Copyright © NIFTY Corporation All Rights Reserved.  7  実装後の効果課題に対する実施後の効果① 対象の手順書ページを検索する工数がかかるエラーメッセージからNotionに保存されている手順書のタイトルを自動的に予測するエラーコード形式（例：ERR001）ではない手順書も含め、予測することが可能に新規アラートの場合は「特定不可」等の旨を記載し、後続の生成された手順書は不要とした Notion URLを付与することで1クリックでページに飛べるように

Slide 8

Slide 8 text

Copyright © NIFTY Corporation All Rights Reserved.  8  実装後の効果課題に対する実施後の効果② 手動で実施する際の手順と同じ流れで、手順書が自動的に生成されるエラー対応着手から対応完了までの工数が大きい人為的ミスの可能性がある手順書とエラーメッセージから自動的に解析し、必要な手順書を生成する複数の対象を調査しやすいように情報を集約する複数の対象に関しては、SQLのWHERE句に自動的に記載してくれる追加作業はコメント編集のみとなり、対応工数が大幅に削減生成された条件をコピーしWHERE句に貼り付けるのみとなり、抽出作業の工数が削減

Slide 9

Slide 9 text

Slide 10

Slide 10 text

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時間制限を回避

Slide 11

Slide 11 text

Copyright © NIFTY Corporation All Rights Reserved.  11  実装詳細　　　EventBridge → Lambda → Notion → S3 ① EventBridge：毎日22:00起動 Bedrock処理中に手順書ページを解析する処理に比べ、事前に解析して保存しているため、処理中において1秒程度で取得が可能に ② ② Lambda 　・Notionの手順書を解析しS3に保存する（ファイル名：手順書名.md）　・メタデータとして、NotionページのURLと最終更新日時を保持最終更新日時を保持しているため、ページに更新が行われていない場合は解析されず、処理時間の短縮を実現

Slide 12

Slide 12 text

Copyright © NIFTY Corporation All Rights Reserved.  12  実装詳細　　　Bedrock① → S3 → GitHub ① Amazon Bedrock① 　・S3に保存された手順書のファイル一覧を取得し、　　発生したエラーメッセージと合致しそうな　　手順書名をBedrockにより特定してもらう　・保存されているメタデータよりURLを抽出し、　　GitHubのコメントに特定手順書としてリンク付与　・手順書が特定出来ない場合はその旨をコメント以前まではエラーコード形式（例：ERR001）を正規表現により特定し完全一致する手順書のみしか取得できなかった ③ ③ エラーコード形式以外も類似度が高い手順書を特定してくれるように

Slide 13

Slide 13 text

Copyright © NIFTY Corporation All Rights Reserved.  13  実装詳細　　　Bedrock② → S3 → GitHub ① Amazon Bedrock② 　・Amazon Bedrock①にて特定された手順書データを　　　取得し、エラーメッセージを併せてBedrockに読み込　　むことで、エラー解決に特化した手順書を生成する　・出力形式が決まっている項目は前処理により抽出し、　　情報として与えている（例「ERROR_CODE:10」） ④ エラーメッセージに付与されているエラーコードや関連情報を解析し、適切な対応手順を自動的に決定して提示 ④ コード例以下のアラートメッセージと手順書テンプレート、および抽出された情報に基づいて、実行すべき具体的な手順を生成してください。エラーメッセージ:{error_content} 抽出された情報:{extracted_info} 手順書テンプレート:{ﬁle_content} 前処理により抽出した情報を元に、手順書内SQLのWHERE句に対応するカラム位置に、関連データが自動的に挿入

Slide 14

Slide 14 text

Copyright © NIFTY Corporation All Rights Reserved.  14  開発時に直面した壁 ①Zapierの30秒制限右図において、最初はLambda①で全て完結させようとしていた ① しかし、以下の処理のためZapierの30秒制限を大幅に超過　・Notion API から手順書内容を解析する　　・構造分析に多くの処理が必要　　・APIの頻繁な呼び出し自体も適切ではない　・解析した手順書内容とエラーメッセージからBedrockにより手順書を予測以下とすることで、制限の解消と処理時間の短縮を図った　・非同期前処理として、前もってNotionページを解析し、S3へ保存　・Zapier連携用のLambdaと、メイン処理用Lambdaを分離することで、Zapierの30秒制限を回避

Slide 15

Slide 15 text

Copyright © NIFTY Corporation All Rights Reserved.  15  開発時に直面した壁 ②Notionページ解析後S3保存処理において、かなりの時間が掛かる LambdaでのNotionページ解析とS3保存に時間がかかる　・手順150個の場合、処理に約300秒を要する　　・都度、150個全て取得し解析、保存している　　・メモなど、手順とは関連の無い情報が存在する以下の対策により、更新が1,2個の場合処理時間を300秒から20秒に削減　・S3のメタデータにNotionページの最終更新日時を保持　　・保存処理の際、ページ内部を解析する前に最終更新日時を比較し、一致する場合は解析処理を実施しない　・手順とは関係の無い情報に関しては、ページ内に新規ページを作成し転記　　・新規ページに対して、設定のConnectionsからAPI連携用botを排除すれば読み込まれなくなる ②

Slide 16

Slide 16 text

Copyright © NIFTY Corporation All Rights Reserved.  16  まとめと今後の展開まとめ Amazon Bedrock による手順生成自動化処理により、手動における抽出ミスや対応工数の削減を期待今後の展開 Notionページ解析処理の精度向上・手順書の内容として、過去エラーや小さなメモが顕在化しており、不要な情報まで保存されている・コンテンツの抽出精度に問題がある　・SQL文がコードブロックとして正しく認識されていない　・箇条書きリストのインデントを含む構造が適切に抽出できていない Amazon Bedrock による手順書特定処理により、全手順から検索する際の工数削減を実現前処理に汎用的な情報抽出機能を追加・運用手順を特定するために必要な情報が、エラーメッセージごとに異なる