Amazon Bedrock を用いた障害対応報告書とポストモーテム文書自動作成
~ ペアーズ における生成 AI 実装解説
Author : 成川 聖(株式会社エウレカ)
Pairs (ペアーズ) は、株式会社エウレカが運営する恋活・婚活のマッチングアプリで、プロフィール情報だけでなく、価値観や人柄、相手に求める本音まで考慮し、理想の相手を見つけることができるサービスです。
ペアーズは、大規模なユーザーベースを持つマッチングサービスであり、システムの安定稼働が非常に重要です。多くのユーザーにとって、マッチングしたあと、ペアーズが実際に会うときの唯一の連絡手段となっており、障害が発生するとユーザー同士連絡が取れなくなるという重大なデメリットがあります。
過去には、障害発生時の対応に多大な時間とリソースを費やしてきました。特に、障害対応の指揮を取るコマンダーの責務が多すぎることで、新任のコマンダーが対応に苦労する場面が多々ありました。そこで、Amazon Bedrock を活用して障害対応の一部を自動化・効率化し、コマンダーの負担を軽減することで、誰でも対応しやすい環境を整えるプロジェクトを開始しました。
ペアーズでの障害発生時には、社内チャットツールに専用の対応チャンネルが自動で作成され、関係する社内ステークホルダーが招集されて、そこにやりとりが集約されます。そのやりとりのメッセージを活用して中間報告書とポストモーテム文書を自動作成する機能を提供することを、上記プロジェクトの手始めとして取り組むこととしました。
技術選定
Amazon Bedrock選定の理由
他の LLM 系サービスではなく、Amazon Bedrock を選定した理由は以下の通りです:
- Amazon Elastic Kubernetes Service との統合 :
弊社のアプリケーションをホスティングしている環境が Amazon EKS で構築されているため、IAM Roles for Service Accounts (IRSA) などを駆使してきめ細かい権限設計が可能であること。 - Managed RAG 機能 :
Knowledge base for Amazon Bedrock などの Managed RAG 機能が利用可能であり、弊社の LLM Chat Bot での利用にも活用できること。 - LLMOps のサポート :
モデル評価やプロンプトマネジメントなど、LLMOps で必要な要素が網羅的に提供されていること。
モデル選定
Amazon Bedrock のモデル選定に関して、今回の社内利用のユースケースではコストやレスポンス速度はあまり問題にはならないため、性能を重視して Claude 3 Haikuではなく Claude 3.5 Sonnet を選びました。
報告書作成シーケンス
ペアーズの報告書作成シーケンスは、以下のようになっています。(ポストモーテム文書作成も同様)
従業員が社内チャットツールにて報告書作成依頼コマンドを実行し、それを Incident Bot が受け付け、LLM API を呼び出します。
クリックすると拡大します
LLM API は、Amazon Bedrock を利用して、報告テンプレートと社内チャットツールのメッセージ・障害情報から障害の要約を生成します。 生成された要約を駆使して報告書が作成され、社内のドキュメント、チャットツールに投稿されます。
以下、作成される報告書のサンプルです。(※実際の報告書ではありません)
クリックすると拡大します
システムアーキテクチャ
従業員からの報告書作成依頼コマンドを受け付け、ハンドリングする Incident Bot Server が 、Amazon API Gateway と AWS Lambda で構築されています。そこからリクエストを受け付ける LLM API が Amazon EKS 上に構築されており、Amazon Bedrock を用いた障害情報の要約処理が行われております。
LLM を利用した API 処理の工夫点
データ前処理
社内チャットツールのメッセージデータから Bot の発言などを取り除き、必要なメッセージに絞る処理をしています。また、メッセージデータに含まれるタイムスタンプは、対応時系列の項目などで使用したい形式にあらかじめ変換しています。
このように、LLM に任せる必要のない単純なデータ処理は事前に済ませておくことで、LLM を本質的なタスクに集中させ、生成の精度を上げることにつながります。
また、Claude のモデルは命令プロンプトを XML 形式で記述すると生成の精度が上がる傾向にあるため、メッセージデータを XML 形式に変換して Amazon Bedrock への命令プロンプトの一部として埋め込んでいます。(参考ドキュメント »)
リトライ機構
使用しているドキュメントツールの制約により、Amazon Bedrock を用いて XHTML 形式のデータを生成する必要があります。そのため、プロンプトで XHTML 形式のデータ生成を指示します。その際、プロンプトの最後にアウトプットが有効な XHTML かどうかを LLM 自身に再度バリデーションさせるとより効果的です。さらに、有効な XHTML であることを後処理でもバリデーションし、もし有効な XHTML でない場合は生成処理をリトライするように実装しています。LLM の出力はどんなにプロンプトを工夫しても必ずしも命令を守ってくれるとは限らないので、このようなリトライ機構は非常に重要です。
LLMに全てを生成させない
状態が遷移しがちでハルシネーションや処理ミスが起こりやすいテンプレート項目 (障害深刻度など) は、別で保存されているデータを取得しテンプレートに埋め込み、LLM に生成させないようにしています。また、静的なテンプレート部分 (注意事項など) は、生成データに後処理で結合するようにしています。LLM が生成する必要がない/不得意な部分は、LLM に生成させないという考え方はどのタスクでも有効です。
以下、データ前処理・プロンプト生成とプロンプトのサンプルです。(※実際の処理とは異なります)
def create_prompt(prompt_template: str, posts: list, severity: str) -> str:
processed_posts = __preprocess_posts(posts)
prompt = __assemble_prompt(prompt_template, processed_posts, severity)
return prompt
def __preprocess_posts(posts: list) -> str:
filtered_and_processed_posts = [
__post_to_xml(post, __convert_to_jst(post['timestamp']))
for post in posts
if __is_target_post(post)
]
return "\n".join(filtered_and_processed_posts)
def __assemble_prompt(prompt_template: str, posts_xml: str, severity: str) -> str:
return prompt_template.format(posts_xml, get_postmortem_template(severity))
You will be acting as an incident response assistant bot to generate a incident interim report based on provided Slack posts.
Here are the Slack posts to analyze:
<slack_posts>
{}
</slack_posts>
Please carefully read through the Slack posts and extract only information that is relevant to the incident response.
Then, use that information to fill in the placeholders marked with {{GENERATE_CONTENT}} in the following interim report template:
{}
When filling in the template, please adhere to the following rules:
- In the 'Timeline' section, organize the events in strict chronological order based on the provided timestamps. Ensure no event is listed out of order. Use the format 'YYYY-MM-DD HH:MM' for all dates and times, listing them from top to bottom.
- Do not modify items related to SEV(Incident Severity).
- Exclude any text not following the specified template format from the generated text, and do not add items not specified.
- Ensure the output is in valid XHTML format, adhering to XML syntax rules like closing all tags and using lowercase for elements and attributes.
- Generate all text content in Japanese.
- After generating the content, validate it against XHTML requirements to ensure full compliance. Correct any non-compliant structures.
- Emphasize accuracy in representing times and sequences to ensure the document reflects the true course of events.
Output the completed post-mortem document with all {{GENERATE_CONTENT}} placeholders filled in. Remember, the output must be in valid XHTML format with all content in Japanese.
導入効果
Amazon Bedrock を導入した結果、ペアーズでは以下の成果を得ることができました:
- 対応時間/コストの短縮 :障害対応報告書とポストモーテム文書の自動生成により、報告や振り返りにかかる工数が約 60 % 削減され、対応時間/コストが大幅に短縮されました。
- 障害対応の心理的負担軽減 :コマンダーの役割の一部を自動化することで、対応負荷と心理的負荷を下げ、新任のコマンダーをアサインしやすくなりました。
今後の展望
ペアーズでは、今後も LLM を活用した自動化の取り組みを進め、さらなる効率化とコスト削減を目指していく予定です。特に、障害発生時のログを自動で収集し、RCA (根本原因分析) のサポートを行う機能を提供することを計画しています。これにより、障害対応の精度とスピードがさらに向上し、対応時間とコストをより削減していくことが期待されています。
本記事が、Amazon Bedrock を用いた障害対応の効率化に興味を持つ方々の参考になれば幸いです。ペアーズの事例を通じて、他の企業でも同様の取り組みが広がり、システム運用の効率化が進むことを期待しています。
筆者プロフィール
成川 聖 (@fukubaka0825)
株式会社エウレカ MLOps Engineer
2020 年に株式会社エウレカに入社。Site Reliability Engineer としてペアーズのシステム開発・運用を担当。その後、MLOps Engineer として AI チームに異動。機械学習システム基盤の開発・運用に従事しながら、LLM を活用した社内ツールにより開発生産性と運用効率の向上を図り、さらにプロダクション環境での LLM 活用も推進している。最近は筋トレとボルダリングに熱中しているらしい。
AWS を無料でお試しいただけます